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

[Nicolas George]

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.

> 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?

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.

> 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?

(Having several of them would be less useful.)

What are the drawbacks you see?

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20161031/53a67df6/attachment.sig>