Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Stefano Sabatini]

On date Tuesday 2016-08-30 12:31:27 +0200, Stefano Sabatini encoded:
[...]
> I rebased the patch, and performed two simple changes in ffprobe (see
> attachment), and it's almost working.
> 
> I think supporting the show_compact_data mode should simplify the
> format in case the format is generated programmatically/through
> scripting.

In other words, I see these options: the demuxer should support both
compact and non-compact data formats, or only one format - in this
case the easiest format, that is the compact one.

Anyway no need to reply, will send the related patches soon.
-- 
FFmpeg = Faithless Free Mystic Power Easy Gymnast
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Stefano Sabatini]

On date Tuesday 2016-08-23 16:53:28 +0200, Nicolas George encoded:
> Le septidi 7 fructidor, an CCXXIV, Stefano Sabatini a écrit :
> > Bump.
> > 
> > So, basically, what are the features that you want to add?
> > I can list a few:
> > 
> > - have multiple streams (with media type and optionally encoding,
> >   assumes base64 by default) in a dedicated header
> > 
> > - specify codec parameters: this could be done serializing
> >   AVCodecParameters. This is the part which would be less robust.
> > 
> > The important point to keep in mind is that this is meant to be an
> > internal format, so it should be used internally (e.g. to mux data)
> > coming from an external source, and we give no guarantee that the
> > format will be robust to changes in libavformat/libavcodec (e.g. in
> > case AVCodecParameter is extended).
> > 
> > My main objection to the ffprobe format is that it's not easily
> > parseable, but I can reconsider it in case there is a strong request
> > for that.
> 

> Sorry for the delay. Here is the patch; as you can see it is two and a half
> years old. IIRC, it used to work with the output of "ffprobe -show_format
> -show_streams -show_packets -show_data", provided the output was edited to
> put the sections in the required order.
> 

> The benefit from using ffprobe instead of a custom format is to not have yet
> another variant of text format.

Sure.

I rebased the patch, and performed two simple changes in ffprobe (see
attachment), and it's almost working.

I think supporting the show_compact_data mode should simplify the
format in case the format is generated programmatically/through
scripting.
>From e0a698f1877c52df13158f3f0744f2e5430c75f3 Mon Sep 17 00:00:00 2001
From: Nicolas George 
Date: Sat, 11 Jan 2014 19:42:41 +0100
Subject: [PATCH] lavf: add ffprobe demuxer

Signed-off-by: Nicolas George 
---
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   2 +
 libavformat/ffprobedec.c | 341 +++
 3 files changed, 344 insertions(+)
 create mode 100644 libavformat/ffprobedec.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index b68c27c..d222ac2 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -162,6 +162,7 @@ OBJS-$(CONFIG_FFM_DEMUXER)   += ffmdec.o
 OBJS-$(CONFIG_FFM_MUXER) += ffmenc.o
 OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
 OBJS-$(CONFIG_FFMETADATA_MUXER)  += ffmetaenc.o
+OBJS-$(CONFIG_FFPROBE_DEFAULT_DEMUXER)   += ffprobedec.o
 OBJS-$(CONFIG_FFTEXTDATA_DEMUXER)+= fftextdatadec.o
 OBJS-$(CONFIG_FFTEXTDATA_MUXER)  += fftextdataenc.o
 OBJS-$(CONFIG_FIFO_MUXER)+= fifo.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index e58e41d..2e10e26 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -123,8 +123,10 @@ void av_register_all(void)
 REGISTER_MUXER   (F4V,  f4v);
 REGISTER_MUXDEMUX(FFM,  ffm);
 REGISTER_MUXDEMUX(FFMETADATA,   ffmetadata);
+REGISTER_DEMUXER (FFPROBE_DEFAULT,  ffprobe_default);
 REGISTER_MUXDEMUX(FFTEXTDATA,   fftextdata);
 REGISTER_MUXER   (FIFO, fifo);
+REGISTER_MUXDEMUX(FFTEXTDATA,   fftextdata);
 REGISTER_MUXDEMUX(FILMSTRIP,filmstrip);
 REGISTER_MUXDEMUX(FLAC, flac);
 REGISTER_DEMUXER (FLIC, flic);
diff --git a/libavformat/ffprobedec.c b/libavformat/ffprobedec.c
new file mode 100644
index 000..28e4e66
--- /dev/null
+++ b/libavformat/ffprobedec.c
@@ -0,0 +1,341 @@
+/*
+ * Copyright (c) 2013 Nicolas George
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with FFmpeg; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/bprint.h"
+#include "avformat.h"
+#include "internal.h"
+
+enum SectionType {
+SEC_NONE = 0,
+SEC_FORMAT,
+SEC_STREAM,
+SEC_PACKET,
+};
+
+const char *const section_names[] = {
+[SEC_NONE]   = "NONE",
+[SEC_FORMAT] = "FORMAT",
+[SEC_STREAM] = "STREAM",
+[SEC_PACKET] = "PACKET",
+};
+
+typedef struct {
+AVClass *class;
+enum SectionType section;
+AVBPrint data;
+} FFprobeContext;
+
+static int ffprobe_probe(AVProbeData 

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Nicolas George]

Le septidi 7 fructidor, an CCXXIV, Stefano Sabatini a écrit :
> Bump.
> 
> So, basically, what are the features that you want to add?
> I can list a few:
> 
> - have multiple streams (with media type and optionally encoding,
>   assumes base64 by default) in a dedicated header
> 
> - specify codec parameters: this could be done serializing
>   AVCodecParameters. This is the part which would be less robust.
> 
> The important point to keep in mind is that this is meant to be an
> internal format, so it should be used internally (e.g. to mux data)
> coming from an external source, and we give no guarantee that the
> format will be robust to changes in libavformat/libavcodec (e.g. in
> case AVCodecParameter is extended).
> 
> My main objection to the ffprobe format is that it's not easily
> parseable, but I can reconsider it in case there is a strong request
> for that.

Sorry for the delay. Here is the patch; as you can see it is two and a half
years old. IIRC, it used to work with the output of "ffprobe -show_format
-show_streams -show_packets -show_data", provided the output was edited to
put the sections in the required order.

The benefit from using ffprobe instead of a custom format is to not have yet
another variant of text format.

Regards,

-- 
  Nicolas George
From cd7324e34e876365249b66a9cb096020ee8a88b9 Mon Sep 17 00:00:00 2001
From: Nicolas George 
Date: Sat, 11 Jan 2014 19:42:41 +0100
Subject: [PATCH] lavf: add ffprobe demuxer.

Signed-off-by: Nicolas George 
---
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/ffprobedec.c | 341 +++
 3 files changed, 343 insertions(+)
 create mode 100644 libavformat/ffprobedec.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 383f82f..0bf4ed2 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -133,6 +133,7 @@ OBJS-$(CONFIG_FFM_DEMUXER)   += ffmdec.o
 OBJS-$(CONFIG_FFM_MUXER) += ffmenc.o
 OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
 OBJS-$(CONFIG_FFMETADATA_MUXER)  += ffmetaenc.o
+OBJS-$(CONFIG_FFPROBE_DEFAULT_DEMUXER)   += ffprobedec.o
 OBJS-$(CONFIG_FILMSTRIP_DEMUXER) += filmstripdec.o
 OBJS-$(CONFIG_FILMSTRIP_MUXER)   += filmstripenc.o
 OBJS-$(CONFIG_FLAC_DEMUXER)  += flacdec.o rawdec.o \
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index f1039dd..b9843d1 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -117,6 +117,7 @@ void av_register_all(void)
 REGISTER_MUXER   (F4V,  f4v);
 REGISTER_MUXDEMUX(FFM,  ffm);
 REGISTER_MUXDEMUX(FFMETADATA,   ffmetadata);
+REGISTER_DEMUXER (FFPROBE_DEFAULT,  ffprobe_default);
 REGISTER_MUXDEMUX(FILMSTRIP,filmstrip);
 REGISTER_MUXDEMUX(FLAC, flac);
 REGISTER_DEMUXER (FLIC, flic);
diff --git a/libavformat/ffprobedec.c b/libavformat/ffprobedec.c
new file mode 100644
index 000..28e4e66
--- /dev/null
+++ b/libavformat/ffprobedec.c
@@ -0,0 +1,341 @@
+/*
+ * Copyright (c) 2013 Nicolas George
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with FFmpeg; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/bprint.h"
+#include "avformat.h"
+#include "internal.h"
+
+enum SectionType {
+SEC_NONE = 0,
+SEC_FORMAT,
+SEC_STREAM,
+SEC_PACKET,
+};
+
+const char *const section_names[] = {
+[SEC_NONE]   = "NONE",
+[SEC_FORMAT] = "FORMAT",
+[SEC_STREAM] = "STREAM",
+[SEC_PACKET] = "PACKET",
+};
+
+typedef struct {
+AVClass *class;
+enum SectionType section;
+AVBPrint data;
+} FFprobeContext;
+
+static int ffprobe_probe(AVProbeData *probe)
+{
+unsigned score;
+
+if (!av_strstart(probe->buf, "[FORMAT]\n", NULL))
+return 0;
+score = !!strstr(probe->buf, "\nnb_streams=") +
+!!strstr(probe->buf, "\nnb_programs=") +
+!!strstr(probe->buf, "\nformat_name=") +
+!!strstr(probe->buf, "\nstart_time=") +
+!!strstr(probe->buf, "\nsize=");
+return score >= 3 ? AVPROBE_SCORE_MAX : AVPROBE_SCORE_MAX / 2;
+}
+
+static int ffprobe_read_close(AVFormatContext *avf)
+{
+   

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Stefano Sabatini]

On date Saturday 2016-08-20 15:51:46 +0200, Stefano Sabatini encoded:
> On date Tuesday 2016-06-28 11:42:42 +0200, Nicolas George encoded:
> > Le decadi 10 messidor, an CCXXIV, Stefano Sabatini a écrit :
> > > +The fftextdata bytestream consists of a sequence of packets. Each
> > > +packet starts with a timestamps expressed in a format recognized by
> > > +FFmpeg (see
> > > +@ref{time duration syntax,,the Time duration section in the 
> > > ffmpeg-utils(1) manual,ffmpeg-utils})
> > > +followed by a sequence of spaces and the base64 encoded data for the
> > > +packet, terminated by ";". The data representation may contain
> > > +interleaved space characters (a space, a tab, or a newline) which are
> > > +ignored.
> > > +
> > > +At the moment a single stream can be represented by an fftextdata
> > > +bytestream.
> > 
> > I like the idea very much, but I feel the format is not very sympathetic to
> > future extensions.
> > 
> 
> > I had implemented a similar feature in the past, but I did not go to the
> > end. My idea was to use the default output format of ffprobe (thus,
> > hexadecimal rather than base64). The parser works, but I was stuck with the
> > problem that ffprobe outputs -show_format after -show_packets. I can post
> > the old patch on the list if you want.
> 
> The output of show_format is shown after since there are some
> information (e.g. number of read packets) which are available only
> after we process the packets. It might be possible to introduce a flag
> to show format before the packets (in this case the information could
> be missing or inconsistent).
> 
> Please send the patch so that I can see your approach.

Bump.

So, basically, what are the features that you want to add?
I can list a few:

- have multiple streams (with media type and optionally encoding,
  assumes base64 by default) in a dedicated header

- specify codec parameters: this could be done serializing
  AVCodecParameters. This is the part which would be less robust.

The important point to keep in mind is that this is meant to be an
internal format, so it should be used internally (e.g. to mux data)
coming from an external source, and we give no guarantee that the
format will be robust to changes in libavformat/libavcodec (e.g. in
case AVCodecParameter is extended).

My main objection to the ffprobe format is that it's not easily
parseable, but I can reconsider it in case there is a strong request
for that.
-- 
FFmpeg = Freak Faithless Marvellous Powered Elastic Ghost
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Stefano Sabatini]

On date Tuesday 2016-06-28 11:42:42 +0200, Nicolas George encoded:
> Le decadi 10 messidor, an CCXXIV, Stefano Sabatini a écrit :
> > +The fftextdata bytestream consists of a sequence of packets. Each
> > +packet starts with a timestamps expressed in a format recognized by
> > +FFmpeg (see
> > +@ref{time duration syntax,,the Time duration section in the 
> > ffmpeg-utils(1) manual,ffmpeg-utils})
> > +followed by a sequence of spaces and the base64 encoded data for the
> > +packet, terminated by ";". The data representation may contain
> > +interleaved space characters (a space, a tab, or a newline) which are
> > +ignored.
> > +
> > +At the moment a single stream can be represented by an fftextdata
> > +bytestream.
> 
> I like the idea very much, but I feel the format is not very sympathetic to
> future extensions.
> 

> I had implemented a similar feature in the past, but I did not go to the
> end. My idea was to use the default output format of ffprobe (thus,
> hexadecimal rather than base64). The parser works, but I was stuck with the
> problem that ffprobe outputs -show_format after -show_packets. I can post
> the old patch on the list if you want.

The output of show_format is shown after since there are some
information (e.g. number of read packets) which are available only
after we process the packets. It might be possible to introduce a flag
to show format before the packets (in this case the information could
be missing or inconsistent).

Please send the patch so that I can see your approach.
-- 
FFmpeg = Fundamentalist and Fanciful MultiPurpose Enhancing Genius
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Stefano Sabatini]

On date Tuesday 2016-06-28 11:42:42 +0200, Nicolas George encoded:
> Le decadi 10 messidor, an CCXXIV, Stefano Sabatini a écrit :
> > +The fftextdata bytestream consists of a sequence of packets. Each
> > +packet starts with a timestamps expressed in a format recognized by
> > +FFmpeg (see
> > +@ref{time duration syntax,,the Time duration section in the 
> > ffmpeg-utils(1) manual,ffmpeg-utils})
> > +followed by a sequence of spaces and the base64 encoded data for the
> > +packet, terminated by ";". The data representation may contain
> > +interleaved space characters (a space, a tab, or a newline) which are
> > +ignored.
> > +
> > +At the moment a single stream can be represented by an fftextdata
> > +bytestream.
> 

> I like the idea very much, but I feel the format is not very sympathetic to
> future extensions.
>
> I had implemented a similar feature in the past, but I did not go to the
> end. My idea was to use the default output format of ffprobe (thus,
> hexadecimal rather than base64). The parser works, but I was stuck with the
> problem that ffprobe outputs -show_format after -show_packets. I can post
> the old patch on the list if you want.

Sorry, I missed the reply. Sure, post the patch here if you can find
it.

Another possibility I'm exploring is using option serialization to
specify the input format options - but this also will add a dependency
on the FFmpeg version.

In my use case, I don't care about compatibility issues, since the
format is only used to inject data into other containers, so it's not
used for archiviation (given the base64 encoding it would not be very
efficient for that purpose).
-- 
FFmpeg = Faithful and Foolish MultiPurpose Ecumenical Gangster
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Nicolas George]

Le decadi 10 messidor, an CCXXIV, Stefano Sabatini a écrit :
> +The fftextdata bytestream consists of a sequence of packets. Each
> +packet starts with a timestamps expressed in a format recognized by
> +FFmpeg (see
> +@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
> manual,ffmpeg-utils})
> +followed by a sequence of spaces and the base64 encoded data for the
> +packet, terminated by ";". The data representation may contain
> +interleaved space characters (a space, a tab, or a newline) which are
> +ignored.
> +
> +At the moment a single stream can be represented by an fftextdata
> +bytestream.

I like the idea very much, but I feel the format is not very sympathetic to
future extensions.

I had implemented a similar feature in the past, but I did not go to the
end. My idea was to use the default output format of ffprobe (thus,
hexadecimal rather than base64). The parser works, but I was stuck with the
problem that ffprobe outputs -show_format after -show_packets. I can post
the old patch on the list if you want.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Stefano Sabatini]

On date Tuesday 2016-06-14 19:36:04 +0200, Stefano Sabatini encoded:
> On date Sunday 2016-06-05 12:59:48 +0200, Stefano Sabatini encoded:
> > On date Thursday 2016-05-19 18:50:17 +0200, Stefano Sabatini encoded:
> > > On date Thursday 2016-05-19 18:45:22 +0200, Stefano Sabatini encoded:
> > > > This format is useful to inject custom user data into streams.
> > > > ---
> > > >  doc/demuxers.texi   |  40 +
> > > >  doc/muxers.texi |  31 +++
> > > >  libavformat/Makefile|   2 +
> > > >  libavformat/allformats.c|   1 +
> > > >  libavformat/fftextdatadec.c | 212 
> > > > 
> > > >  libavformat/fftextdataenc.c | 103 +
> > > >  6 files changed, 389 insertions(+)
> > > >  create mode 100644 libavformat/fftextdatadec.c
> > > >  create mode 100644 libavformat/fftextdataenc.c
> > > 
> > > Short explanation: I needed some way to inject serialized data packets
> > > through stream-copy, so I implemented this format. The other patches
> > > are related (since I needed to inject timed ID3 data).
> > > 
> > > I'm fine with extending it with other options, or to use an
> > > alternative solution (if exists).
> > 
> > Please tell if you consider this format acceptable.
> > 
> > One obvious limitation is that it can't store codec properties (nor
> > the codec name, nor more than one stream). One possibility would be to
> > dump the serialization of AVCodecContext/AVCodecParameters, even if
> > these would require a serious limitation on the format (since that
> > means it would require to use it only as intermediary format, for
> > muxing and demuxing using the same version of FFmpeg, which is fine in
> > my use case).
> 
> Ping. Any hope to get this integrated, or there is someone against it?

Reping with updated patch.
-- 
FFmpeg = Fostering and Fast Multimedia Philosofic Eretic Gospel
>From a22253ea6831fbb3560a6275141df0bab969d3fc Mon Sep 17 00:00:00 2001
From: Stefano Sabatini 
Date: Sun, 20 Mar 2016 15:51:30 +0100
Subject: [PATCH] lavf: add textdata virtual demuxer and muxer

This format is useful to inject custom user data into streams.
---
 doc/demuxers.texi   |  40 +
 doc/muxers.texi |  31 +++
 libavformat/Makefile|   2 +
 libavformat/allformats.c|   1 +
 libavformat/fftextdatadec.c | 212 
 libavformat/fftextdataenc.c | 103 +
 6 files changed, 389 insertions(+)
 create mode 100644 libavformat/fftextdatadec.c
 create mode 100644 libavformat/fftextdataenc.c

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e34f8b3..9fc58eb 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -254,6 +254,46 @@ This demuxer is used to demux FLV files and RTMP network streams.
 Allocate the streams according to the onMetaData array content.
 @end table
 
+@anchor{fftextdata}
+@section fftextdata, fftd
+
+FFmpeg text data demuxer.
+
+This special demuxer allows to read serialized data base64-encoded and
+remux it. It is especially useful for injecting opaque data streams.
+
+The fftextdata bytestream consists of a sequence of packets. Each
+packet starts with a timestamps expressed in a format recognized by
+FFmpeg (see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) manual,ffmpeg-utils})
+followed by a sequence of spaces and the base64 encoded data for the
+packet, terminated by ";". The data representation may contain
+interleaved space characters (a space, a tab, or a newline) which are
+ignored.
+
+At the moment a single stream can be represented by an fftextdata
+bytestream.
+
+If an input filename is "fftextdata" or "fftd" then the file format is
+recognized as fftextdata.
+
+@subsection Options
+@table @option
+@item codec_name
+Set the codec name for the packets data.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Inject timed_id3 packed data stored into the data.fftd file into the
+output file.
+@example
+ffmpeg -i input.mp4 -codec_name timed_id3 -f fftextdata -i data.fftd -y -map 0 -map 1 -c copy output.ts
+@end example
+@end itemize
+
 @section libgme
 
 The Game Music Emu library is a collection of video game music file emulators.
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c2ca0ba..0697728 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -129,6 +129,37 @@ and the input video converted to MPEG-2 video, use the command:
 ffmpeg -i INPUT -c:a pcm_u8 -c:v mpeg2video -f crc -
 @end example
 
+@section fftextdata, fftd
+
+FFmpeg text data muxer.
+
+The fftextdata bytestream consists of a sequence of packets. Each
+packet starts with a timestamps expressed in a format recognized by
+FFmpeg (see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) manual,ffmpeg-utils})
+followed by a sequence of spaces and the base64 encoded data for the
+packet, terminated by ";". The data representation may contain
+interleaved 

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Stefano Sabatini]

On date Sunday 2016-06-05 12:59:48 +0200, Stefano Sabatini encoded:
> On date Thursday 2016-05-19 18:50:17 +0200, Stefano Sabatini encoded:
> > On date Thursday 2016-05-19 18:45:22 +0200, Stefano Sabatini encoded:
> > > This format is useful to inject custom user data into streams.
> > > ---
> > >  doc/demuxers.texi   |  40 +
> > >  doc/muxers.texi |  31 +++
> > >  libavformat/Makefile|   2 +
> > >  libavformat/allformats.c|   1 +
> > >  libavformat/fftextdatadec.c | 212 
> > > 
> > >  libavformat/fftextdataenc.c | 103 +
> > >  6 files changed, 389 insertions(+)
> > >  create mode 100644 libavformat/fftextdatadec.c
> > >  create mode 100644 libavformat/fftextdataenc.c
> > 
> > Short explanation: I needed some way to inject serialized data packets
> > through stream-copy, so I implemented this format. The other patches
> > are related (since I needed to inject timed ID3 data).
> > 
> > I'm fine with extending it with other options, or to use an
> > alternative solution (if exists).
> 
> Please tell if you consider this format acceptable.
> 
> One obvious limitation is that it can't store codec properties (nor
> the codec name, nor more than one stream). One possibility would be to
> dump the serialization of AVCodecContext/AVCodecParameters, even if
> these would require a serious limitation on the format (since that
> means it would require to use it only as intermediary format, for
> muxing and demuxing using the same version of FFmpeg, which is fine in
> my use case).

Ping. Any hope to get this integrated, or there is someone against it?
-- 
FFmpeg = Fiendish & Faithful Magnificient Pure Everlasting Gladiator
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Stefano Sabatini]

On date Thursday 2016-05-19 18:50:17 +0200, Stefano Sabatini encoded:
> On date Thursday 2016-05-19 18:45:22 +0200, Stefano Sabatini encoded:
> > This format is useful to inject custom user data into streams.
> > ---
> >  doc/demuxers.texi   |  40 +
> >  doc/muxers.texi |  31 +++
> >  libavformat/Makefile|   2 +
> >  libavformat/allformats.c|   1 +
> >  libavformat/fftextdatadec.c | 212 
> > 
> >  libavformat/fftextdataenc.c | 103 +
> >  6 files changed, 389 insertions(+)
> >  create mode 100644 libavformat/fftextdatadec.c
> >  create mode 100644 libavformat/fftextdataenc.c
> 
> Short explanation: I needed some way to inject serialized data packets
> through stream-copy, so I implemented this format. The other patches
> are related (since I needed to inject timed ID3 data).
> 
> I'm fine with extending it with other options, or to use an
> alternative solution (if exists).

Please tell if you consider this format acceptable.

One obvious limitation is that it can't store codec properties (nor
the codec name, nor more than one stream). One possibility would be to
dump the serialization of AVCodecContext/AVCodecParameters, even if
these would require a serious limitation on the format (since that
means it would require to use it only as intermediary format, for
muxing and demuxing using the same version of FFmpeg, which is fine in
my use case).
-- 
FFmpeg = Fabulous and Furious Multimedia Philosofic Excellent Gadget
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Moritz Barsnick]

On Tue, May 24, 2016 at 19:50:26 +0200, Stefano Sabatini wrote:
> What warnings?
> 
> > [fftextdata @ 0xaf687a0] Using AVStream.codec to pass codec parameters to 
> > muxers is deprecated, use AVStream.codecpar instead.

Yes, that one.

> This one is currently shown in every conversion.

Ah, I missed that.

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Stefano Sabatini]

On date Monday 2016-05-23 15:31:33 +0200, Moritz Barsnick encoded:
> On Thu, May 19, 2016 at 19:29:40 +0200, Stefano Sabatini wrote:
> > > > +ffmpeg -i INPUT -codec copy -map 0 -an -vn data.fftd
> 
> BTW, is this possibly the first and only muxer which can actually remux
> timed_id3? I have been trying to *extract* timed_id3, but haven't
> figured out into which format I can dump data streams.
> 
> > Something like this should work:
> > ffmpeg -i INPUT -codec copy -map 0 -an -vn data.fftd
> 
> It turns out that my timed_id3 streams are either empty, or are not
> being read. AFAICT, the information I was hoping to find in there was
> apparently actually provided by Icy-metadata. (I was expecting either
> track information for radio programs or subtitles for video streams in
> the timed_id3.)
> 
> (I had been dumping HLS's MPEG-TS segments to MPEG-TS files, and they
> were showing timed_id3 data streams.)
> 
> So, no testing possibly from me, at least until I know for sure what's
> in those streams of mine.
> 
> Moritz
> 

> P.S.: Does the patch trigger deprecation warnings due to its own
>   nature, or due to something earlier in the chain? ffmpeg-cli
>   even?

What warnings?

> 
> barsnick@sunshine:~/Downloads/Radio/NRK/Amund/2015-12-28 > ffmpeg -i 
> nrk-outputfile-NzyUCD.ts -map 0:d -c copy nrk-outputfile-NzyUCD.fftd
> ffmpeg version N-80066-g566be4f Copyright (c) 2000-2016 the FFmpeg developers
>   built with icc (ICC) 14.0.3 20140422
>   configuration: --prefix=/usr/new/tools/video/install/ffmpeg/2016-05-22 
> --cc=icc --cxx=icpc --enable-gpl --enable-version3 --enable-nonfree 
> --disable-shared --enable-gnutls --enable-libcdio --enable-libfreetype 
> --enable-libx264 --enable-libvpx --enable-libmp3lame --enable-openal 
> --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtwolame 
> --enable-libopenjpeg --enable-librtmp --enable-libass --enable-libv4l2 
> --enable-libvidstab --enable-libfdk-aac --enable-libsmbclient 
> --enable-libzvbi --enable-libtesseract --enable-libzmq
>   libavutil  55. 24.100 / 55. 24.100
>   libavcodec 57. 43.100 / 57. 43.100
>   libavformat57. 37.100 / 57. 37.100
>   libavdevice57.  0.101 / 57.  0.101
>   libavfilter 6. 46.100 /  6. 46.100
>   libswscale  4.  1.100 /  4.  1.100
>   libswresample   2.  0.101 /  2.  0.101
>   libpostproc54.  0.100 / 54.  0.100
> [mpegts @ 0xaf60900] start time for stream 1 is not set in 
> estimate_timings_from_pts
> Input #0, mpegts, from 'nrk-outputfile-NzyUCD.ts':
>   Duration: 02:56:59.75, start: 10.099667, bitrate: 176 kb/s
>   Program 1
> Stream #0:0[0x100]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, 
> stereo, fltp, 175 kb/s
> Stream #0:1[0x101]: Data: timed_id3 (ID3  / 0x20334449)

> [fftextdata @ 0xaf687a0] Using AVStream.codec to pass codec parameters to 
> muxers is deprecated, use AVStream.codecpar instead.

This one is currently shown in every conversion.

[...]
-- 
FFmpeg = Fundamental and Fostering Minimalistic Philosophical Ecumenical Ghost
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Moritz Barsnick]

On Thu, May 19, 2016 at 19:29:40 +0200, Stefano Sabatini wrote:
> > > +ffmpeg -i INPUT -codec copy -map 0 -an -vn data.fftd

BTW, is this possibly the first and only muxer which can actually remux
timed_id3? I have been trying to *extract* timed_id3, but haven't
figured out into which format I can dump data streams.

> Something like this should work:
> ffmpeg -i INPUT -codec copy -map 0 -an -vn data.fftd

It turns out that my timed_id3 streams are either empty, or are not
being read. AFAICT, the information I was hoping to find in there was
apparently actually provided by Icy-metadata. (I was expecting either
track information for radio programs or subtitles for video streams in
the timed_id3.)

(I had been dumping HLS's MPEG-TS segments to MPEG-TS files, and they
were showing timed_id3 data streams.)

So, no testing possibly from me, at least until I know for sure what's
in those streams of mine.

Moritz

P.S.: Does the patch trigger deprecation warnings due to its own
  nature, or due to something earlier in the chain? ffmpeg-cli
  even?

barsnick@sunshine:~/Downloads/Radio/NRK/Amund/2015-12-28 > ffmpeg -i 
nrk-outputfile-NzyUCD.ts -map 0:d -c copy nrk-outputfile-NzyUCD.fftd
ffmpeg version N-80066-g566be4f Copyright (c) 2000-2016 the FFmpeg developers
  built with icc (ICC) 14.0.3 20140422
  configuration: --prefix=/usr/new/tools/video/install/ffmpeg/2016-05-22 
--cc=icc --cxx=icpc --enable-gpl --enable-version3 --enable-nonfree 
--disable-shared --enable-gnutls --enable-libcdio --enable-libfreetype 
--enable-libx264 --enable-libvpx --enable-libmp3lame --enable-openal 
--enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtwolame 
--enable-libopenjpeg --enable-librtmp --enable-libass --enable-libv4l2 
--enable-libvidstab --enable-libfdk-aac --enable-libsmbclient --enable-libzvbi 
--enable-libtesseract --enable-libzmq
  libavutil  55. 24.100 / 55. 24.100
  libavcodec 57. 43.100 / 57. 43.100
  libavformat57. 37.100 / 57. 37.100
  libavdevice57.  0.101 / 57.  0.101
  libavfilter 6. 46.100 /  6. 46.100
  libswscale  4.  1.100 /  4.  1.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc54.  0.100 / 54.  0.100
[mpegts @ 0xaf60900] start time for stream 1 is not set in 
estimate_timings_from_pts
Input #0, mpegts, from 'nrk-outputfile-NzyUCD.ts':
  Duration: 02:56:59.75, start: 10.099667, bitrate: 176 kb/s
  Program 1
Stream #0:0[0x100]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 48000 Hz, 
stereo, fltp, 175 kb/s
Stream #0:1[0x101]: Data: timed_id3 (ID3  / 0x20334449)
[fftextdata @ 0xaf687a0] Using AVStream.codec to pass codec parameters to 
muxers is deprecated, use AVStream.codecpar instead.
Output #0, fftextdata, to 'nrk-outputfile-NzyUCD.fftd':
  Metadata:
encoder : Lavf57.37.100
Stream #0:0: Data: timed_id3 (ID3  / 0x20334449)
Stream mapping:
  Stream #0:1 -> #0:0 (copy)
Press [q] to stop, [?] for help
size=   0kB time=00:00:00.00 bitrate=N/A speed=   0x
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing 
overhead: unknown
Output file is empty, nothing was encoded (check -ss / -t / -frames parameters 
if used)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Moritz Barsnick]

On Thu, May 19, 2016 at 18:45:22 +0200, Stefano Sabatini wrote:

> [FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

demuxer and *muxer* !?

> +Store a data stream to an output file:
> +@example
> +ffmpeg -i INPUT -codec copy -map 0 -an -vn data.fftd

Would this mean it could also dump timed_id3 to fftd, or would that not
work because timed_id3 cannot be demuxed yet? (I will just try, I don't
have the time right now though.)

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf: add textdata virtual demuxer and demuxer

[Stefano Sabatini]

This format is useful to inject custom user data into streams.
---
 doc/demuxers.texi   |  40 +
 doc/muxers.texi |  31 +++
 libavformat/Makefile|   2 +
 libavformat/allformats.c|   1 +
 libavformat/fftextdatadec.c | 212 
 libavformat/fftextdataenc.c | 103 +
 6 files changed, 389 insertions(+)
 create mode 100644 libavformat/fftextdatadec.c
 create mode 100644 libavformat/fftextdataenc.c

diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index e34f8b3..9fc58eb 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -254,6 +254,46 @@ This demuxer is used to demux FLV files and RTMP network 
streams.
 Allocate the streams according to the onMetaData array content.
 @end table
 
+@anchor{fftextdata}
+@section fftextdata, fftd
+
+FFmpeg text data demuxer.
+
+This special demuxer allows to read serialized data base64-encoded and
+remux it. It is especially useful for injecting opaque data streams.
+
+The fftextdata bytestream consists of a sequence of packets. Each
+packet starts with a timestamps expressed in a format recognized by
+FFmpeg (see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils})
+followed by a sequence of spaces and the base64 encoded data for the
+packet, terminated by ";". The data representation may contain
+interleaved space characters (a space, a tab, or a newline) which are
+ignored.
+
+At the moment a single stream can be represented by an fftextdata
+bytestream.
+
+If an input filename is "fftextdata" or "fftd" then the file format is
+recognized as fftextdata.
+
+@subsection Options
+@table @option
+@item codec_name
+Set the codec name for the packets data.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Inject timed_id3 packed data stored into the data.fftd file into the
+output file.
+@example
+ffmpeg -i input.mp4 -codec_name timed_id3 -f fftextdata -i data.fftd -y -map 0 
-map 1 -c copy output.ts
+@end example
+@end itemize
+
 @section libgme
 
 The Game Music Emu library is a collection of video game music file emulators.
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c62d4b5..df5ec08 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -129,6 +129,37 @@ and the input video converted to MPEG-2 video, use the 
command:
 ffmpeg -i INPUT -c:a pcm_u8 -c:v mpeg2video -f crc -
 @end example
 
+@section fftextdata, fftd
+
+FFmpeg text data muxer.
+
+The fftextdata bytestream consists of a sequence of packets. Each
+packet starts with a timestamps expressed in a format recognized by
+FFmpeg (see
+@ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1) 
manual,ffmpeg-utils})
+followed by a sequence of spaces and the base64 encoded data for the
+packet, terminated by ";". The data representation may contain
+interleaved space characters (a space, a tab, or a newline) which are
+ignored.
+
+At the moment only a single stream can be represented by an fftextdata
+bytestream.
+
+This muxer can be used to reinject the stream (e.g. a data stream) in
+a different output, or to provide serialized data of the encoded data.
+
+The output can then be read using the fftextdata demuxer.
+
+@subsection Examples
+
+@itemize
+@item
+Store a data stream to an output file:
+@example
+ffmpeg -i INPUT -codec copy -map 0 -an -vn data.fftd
+@end example
+@end itemize
+
 @anchor{framecrc}
 @section framecrc
 
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 742aff5..4effccd 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -162,6 +162,8 @@ OBJS-$(CONFIG_FFM_DEMUXER)   += ffmdec.o
 OBJS-$(CONFIG_FFM_MUXER) += ffmenc.o
 OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
 OBJS-$(CONFIG_FFMETADATA_MUXER)  += ffmetaenc.o
+OBJS-$(CONFIG_FFTEXTDATA_DEMUXER)+= fftextdatadec.o
+OBJS-$(CONFIG_FFTEXTDATA_MUXER)  += fftextdataenc.o
 OBJS-$(CONFIG_FILMSTRIP_DEMUXER) += filmstripdec.o
 OBJS-$(CONFIG_FILMSTRIP_MUXER)   += filmstripenc.o
 OBJS-$(CONFIG_FLAC_DEMUXER)  += flacdec.o rawdec.o \
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index e6ee8d6..7657f94 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -124,6 +124,7 @@ void av_register_all(void)
 REGISTER_MUXER   (F4V,  f4v);
 REGISTER_MUXDEMUX(FFM,  ffm);
 REGISTER_MUXDEMUX(FFMETADATA,   ffmetadata);
+REGISTER_MUXDEMUX(FFTEXTDATA,   fftextdata);
 REGISTER_MUXDEMUX(FILMSTRIP,filmstrip);
 REGISTER_MUXDEMUX(FLAC, flac);
 REGISTER_DEMUXER (FLIC, flic);
diff --git a/libavformat/fftextdatadec.c b/libavformat/fftextdatadec.c
new file mode 100644
index 000..9516559
--- /dev/null
+++ b/libavformat/fftextdatadec.c
@@ -0,0 +1,212 @@
+/*
+ * Copyright (c) 2016 Stefano Sabatini
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you