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
