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

James Almer jamrial at gmail.com
Mon Oct 31 19:41:05 EET 2016


On 10/31/2016 1:54 PM, Nicolas George wrote:
> Le decadi 10 brumaire, an CCXXV, James Almer a écrit :
>> Someone will come up with an hexdump demuxer next and call hexdump output
>> a multimedia file, if we follow your views. Or an XML parser for a similarly
>> arbitrary custom format they happened to devise. Or maybe oggz-dump's output.
>>
>> While for the former we can tell them to go away, we wouldn't have many
>> arguments against the latter two if this patch goes in. Because telling them
>> we don't want their custom format after this one was committed would be
>> hypocritical, biased, and a decision as arbitrary as the actual hypothetical
>> format.
> 
> If these formats are useful, they should be accepted. This should be the
> main criterions: usefulness and drawbacks.
> 
> Your argument seem to assume that someone will maliciously try to get a
> crappy demuxer accepted that way. Seems a bit paranoid.

It's an scenario that could happen, like it or not. I'd rather not open the
doors for it.

> 
>> Aside from the "arbitrary markup format" argument, the fact it's disabled by
>> default for security reasons doesn't exactly inspire confidence.
>> It would afaik be a first for an internal module that doesn't depend on
>> external factors.
> 
> Disabled by default was a concession to someone (Paul, IIRC) raising the
> concern of security. It seems very feeble to me: why this format and not
> the many others?

"why this format and not this other" is coincidentally the argument that
will be used after this thing gets committed to justify adding others.

> 
> If this is giving you pause, then let us review all this carefully, fuzz
> it, add regression testing, and enable it by default.
> 
>> Besides, nothing even /muxes/ this format to begin with. The doxy states you
>> should take the ffprobe standard output and edit it by hand or with a script
>> until it looks like something this demuxer can digest.
> 
> Stefano has promised to implement a corresponding muxer (rather easy,
> actually, but a bit of code duplication with ffprobe) and has also
> tried to get ffprobe to output the exact format.

If something is to create these files, it should be ffprobe itself and
not some unrelated muxer that's going to duplicate a lot of code.

> 
>> Which so happens to be what every libav* user has to do for their projects.
>> Write a program using the libraries' public API to read and write files.
>>
>> We have plenty of times refused code people wanted to dump into libavformat
>> and libavcodec because it was the easiest way for them to get what they
>> needed done. There was this absolutely insane youtube-dl "demuxer" that still
>> gives me the chills.
>> We have also plenty of times let things go in, even with several developers
>> against it. Lets try to not do it again.
> 
> This argument mixes a whole lot of different cases together. Each case
> has its own specifics that should be used to judge whether it should
> have been accepted or not.
> 
> Once again: usefulness and drawbacks.
> 
> Having one demuxer of this kind, as powerful as possible, is useful. Do
> you not agree with that?

It might, hence why i suggested this being implemented as a standalone tool
and not that you should drop the whole thing.

> 
> (Having several of them would be less useful.)
> 
> What are the drawbacks you see?

You presented an scenario and use case to dump media streams into a text
file to easily alter them, analyze them and reconstruct them. You then
declared said dumps to be an actual format so they could qualify for an
avformat module that could digest them.

There are no technical drawbacks for this demuxer. This is a concept and
design issue. It's a very specific need so far a single person or two
that's being forced into the libraries because it's the easiest way to
implement it.

This should be written as a standalone tool that uses lavf API to rebuild
the custom xml-like dump with the hex formatted packets as created by
ffprobe. Basically, write ffmpeg's own, more powerful and versatile
version of oggz-dump that uses lavf instead of libogg, meaning the dumps
can be created and rebuilt from and into any lavf supported format.



More information about the ffmpeg-devel mailing list