[FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer
Andreas Cadhalpun
andreas.cadhalpun at googlemail.com
Fri Nov 25 03:33:55 EET 2016
On 24.11.2016 12:36, Stefano Sabatini wrote:
> I think the most important controversy points revolve around these facts:
>
> * developers do not want to add support for an internal only format,
> which adds to the maintainance burden with no clear benefit, since
> there are no clear use cases outside the scope of internal debugging
> and specific tasks. Let's call this argument "maintainance burden".
>
> * the second argument is about the fact that such new format is not a
> "standard" format, so it's not really interoperable. Let's call this
> argument "non interoperability".
>
> The two facts combine so that some developers claim that there is an
> added maintainance burden for a non interoperable format.
>
> I'm not able to read more technical/design arguments. I suppose this
> cannot really be discussed more, since one hardly accepts more burden
> if he has no apparent benefits from the burden, so I'd expect that
> only the developers who see the gain will agree with adding the new
> format.
I think a significant reason for people objecting to this format is
the experience with the ffmpeg-specific ffm format, which unfortunately
wasn't very well designed and thus caused security issues as well as
incompatibilities between different versions of ffmpeg.
However, the ffprobe demuxer code looks a lot better in both regards,
because it neither uses ffmpeg internal stuff like codec_id numbers
(which breaks compatibility, when these change), nor allows setting
arbitrary AVOptions from the file (which can cause security issues).
By the way, the gain I see in this demuxer is that it would be rather
useful for fuzz-testing, as it supports all codecs.
> We can mitigate the burden effect by reducing the impact of the
> revelant code (for example making it disabled by default),
I think a better idea would be to require '-strict experimental',
as code disabled by default does neither get build- nor FATE-tested
much.
Best regards,
Andreas
More information about the ffmpeg-devel
mailing list