[FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer

[wm4]

On Thu, 29 Sep 2016 01:21:01 +0200
Stefano Sabatini <stefasab at gmail.com> wrote:

> On date Monday 2016-09-26 18:55:47 +0200, wm4 encoded:
> > On Sun, 25 Sep 2016 19:32:37 +0200
> > Stefano Sabatini <stefasab at gmail.com> wrote:  
> [...]
> > > > > My use case: I need to build a data stream with scripting/manual
> > > > > editing. Since I don't want to have to rely on a binary format (which
> > > > > is not ideal for that use case) I needed a format simple enough to be
> > > > > written and analysed without special tools, but with a simple text
> > > > > editor.    
> > > > 
> > > > I still don't get it. Your description makes me think of something like
> > > > EDL, but that doesn't seem to have anything to do with it.    
> > > 
> > > EDL as "Edit Decision List"? No I don't think this is related at
> > > all.
> > > 
> > > Suppose you want to inject a data stream, you have the data and you
> > > know where to insert it given its PTS. With this muxer you can
> > > handcraft a textual file in the ffprobe_default format and use ffmpeg
> > > to inject the new data stream.  
> >   
> 
> > What's a "data stream"?  
> 
> A stream consisting of generic data, that is a stream with type
> AV_MEDIA_TYPE_DATA.
> 
> > Inject into what?  
> 
> Interleave the stream with other media streams (audio, video,
> etc.). This can be done via remuxing (no need for transcoding).
> 
> > And why?  
> 
> Data stream could be used to insert custom information for
> post-processing (e.g. they might contain advertising information).

This seems like a rather special use case. Why does it have a demuxer,
and can't be in your own C code using libavcodec/libavformat?

In addition, I think using the ffprobe "format" is an overcomplication,
and will justify adding even more stuff to the demuxer, until it's a
similarily complex mess like the ffm demuxer/muxer.