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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
