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

Stefano Sabatini stefasab at gmail.com
Thu Nov 24 13:36:26 EET 2016


On date Tuesday 2016-11-01 15:49:12 +0100, Michael Niedermayer encoded:
> On Tue, Nov 01, 2016 at 02:45:00AM -0300, James Almer wrote:
[...]
> > Libavformat is not a dumping ground for code molded by a single person's
> > specific needs, and it is not a library meant to hold your or anyone's
> > debug tools.
> 
> playing devils advocate, why not?
> 
> If a group of developers needs some code to debug and maintain a part
> of FFmpeg it does seem logic to me to dump that in the codebase if it
> doesnt affect anyone else except psycological.
> 
> we can play this thought experiment even more evil.
> Consider a fork
> one where developers dump the code they need to maintain and debug
> in the code base (strictly limited to what does not affect others
> technically)
> and one fork where people cannot do this
> 
> Who of the 2 is more "fit" for survival in a evolutionary / darwinian
> sense ?
> A project where people can just debug and maintain their code or a
> project where its more cumbersome in some way (seperate repo, seperate
> tool that only works in a subset of cases, ...)?

This is a great reply, and I fully agree with this point of view.
 
> I dont want to be offensive but to me one side of this argument is
> completely absurd
> maybe iam an idiot and just dont see it, but i really dont understand
> why we would want to make it harder for ourselfs to maintain and debug
> things.
> 
> Now after writing this, theres somethig i realize
> Is the issue people have with the text/ffprobe demuxer that it is not
> a standarized format ?
> Would writing a formal specification resolve this whole disagreement ?

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.

We can mitigate the burden effect by reducing the impact of the
revelant code (for example making it disabled by default), and
clarifying that it must be used only for internal development or for
introducing features which would be otherwise more difficult to
implement (for example scripting media generation/processing), and
shouldn't be used for archiving purposes.

These are the only counter-arguments I can offer and implement.

> I mean a real actual quality spec from which one could write both
> a muxer and demuxer that can interoperate

I don't think that extending the specification would be really useful
since I don't want to make the format interoperable *at this point*
(since we may not be aware of faults in the format itself) but I plan
to use it only internally, so I'm not very well disposed to pay the
additional time and effort it requires for something which I won't use.

The other more generic argument was explained by Michael, the added
functionality is a bonus from an evolutionary point of view since it
fosters contributions. Said in different words, I remind you the old
saying that "perfect is the enemy of the good", so I don't consider
this new format perfect or fit for all the tasks, but good enough for
what I need to do.

That said, I have really no time and energy to prolong this discussion
ad infinitum, so I'd call for a formal vote (in the case this is not
accepted, I could maintain it externally although I don't think this
is a good idea).
-- 
FFmpeg = Forgiving and Forgiving Most Pitiful Enlightened Gadget


More information about the ffmpeg-devel mailing list