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

[James Almer]

On 10/31/2016 11:57 AM, Nicolas George wrote:
> Jean-Baptiste Kempf:
>> ffprobe is not a video/audio format.
>> It has no public specification, is made up and completely arbitrary
>> format.
>> It will not be used by the large majority of applications.
> 
> Indeed. The same goes for a lot of obscure formats used to decode game
> cutscene data. At least, with ffprobe, we did not have to
> reverse-engineer the format.
> 
>> I understand very well the need,
> 
> Thanks.
> 
>> 				   I disagree it should go inside the
>> (de)muxing library.
> 
> Why? Is it just a matter of taste for you, or do you see practical
> drawbacks?
> 
> James Almer:
>> Afaics, the cons argumented were that this "demuxer" doesn't fit the
>> criteria of a libavformat module.
> 
> I do not know the criteria of a libavformat module. Can you enlighten
> me?
> 
>> 				    It's not demultiplexing a multimedia
>> file.
> 
> Uh? I think this is exactly what all demuxers do. They can not do
> anything else.
> 
>> It, unless i misread it, is just reconstructing one out of a non-binary
>> dump.
> 
> The "dump" is a file, it contains multimedia data: it is a multimedia
> file.

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.

> 
>> This should be implemented as a separate tool using libavformat, and
>> not as a libavformat module.
> 
> It could be done. But, once again: why? Is it just a matter of taste for
> you, or do you see practical drawbacks?

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.

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.

> 
> Making a tool to build a real file from the text dump allows to get the
> feature without intruding lavf, that is true.
> 
> But it would require exactly the same amount of code to parse the dump,
> plus the code to mux the file: more code, more maintenance.

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.

> 
> Plus, in terms of debugging, it adds three extra points of failure: the
> muxer for the intermediate format (used in the conversion tool), the
> demuxer for the intermediate format (used in ffmpeg.c) and the
> limitations of the intermediate format itself.
> 
> Regards,
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>