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

[wm4]

On Fri, 23 Sep 2016 19:46:16 +0200
Stefano Sabatini <stefasab at gmail.com> wrote:

> On date Friday 2016-09-23 09:34:19 +0200, wm4 encoded:
> > On Thu, 22 Sep 2016 18:50:27 +0200
> > Stefano Sabatini <stefasab at gmail.com> wrote:  
> [...]
> > > Ping. I'd like to commit this if there are no objections. Also,
> > > possibly add a muxer to generate output directly readable by the
> > > demuxer (this way we don't need ffprobe for generating the output, and
> > > we avoid the ordering issue).  
> > 
> > I'm sorry to jump in as a nay-sayer, but it looks like a quite fishy
> > concept and I still don't get why it's supposed to be needed. The
> > documentation also doesn't say what this is supposed to be useful for.  
> 
> I'll extend the documentation to add some possibly useful use cases.
> 
> 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.

> Also, if coupled with a muxer it allows to create an output, tweak it
> (e.g. to change the timestamps) and feed it to FFmpeg, which might be
> useful from time to time to test/debug specific features.
> 
> The alternative might be to build a tool for converting to
> custom-format to a "binary" format accepted by FFmpeg, but I want
> to avoid the need for an additional tool.
> 
> This format is my second attempt after the fftextdata format, which
> was regarded too limited. This one is based on the ffprobe default
> output (although it's simplified).
> 
> > It's also potentially a security issue (lots of text parsing, and can
> > construct inputs which might be tricky for API users).
> > 
> > I probably can't stop you from pushing this, but at least it shouldn't
> > be enabled by default.  
> 
> I understand the security concerns, and I have no objections against
> disabling this by default if developers prefer this way.