[FFmpeg-user] "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

[Alexander Strasser]

On 2020-08-19 22:14 -0400, Mark Filipak wrote:
> On 08/19/2020 01:43 PM, Jim DeLaHunt wrote:
> > On 2020-08-19 07:34, Paul B Mahol wrote:
> > > You are deeply confused about our filters.
> > > Any filter can change pixel formats to one that they accepts thus gbrp
> > > is picked instead of packed rgb, this is already documented
> > > implicitly.
> >
> > Wow, "documented implicitly". This is such a classic FFmpeg project
> > statement. The role of documentation is to explain, explicitly, at a
> > suitable level of detail. What does "documented implicitly" even mean?
> >
> > I think this thread points out is that FFmpeg documentation is
> > inadequate. It is hard to prove a negative, but I suspect that the term
> > "pixel format" is not actually defined in the FFmpeg documentation. I
> > suspect that the statement, "Any filter can change pixel formats" is not
> > stated either. Certainly the maskedmerge filter documentation[1] doesn't
> > mention pixel formats at all, much less say what pixel formats the
> > filter sets for its output.
> >
> > I have attempted to improve the documentation, to make it explain
> > explicitly instead of fail to document. I encountered a great deal of
> > resistance to those patches, because they make the documentation more
> > explicit, because they have more words, and because documentation has so
> > little value in this project relative to executable code.
> >
> > And yet "You are deeply confused about our filters". In other words, the
> > documentation has failed to explain to you what FFmpeg does, the project
> > has failed to write or welcome improved documentation, you do not
> > understand how FFmpeg works — and somehow this is your fault.
> >
> > [1] http://ffmpeg.org/ffmpeg-all.html#maskedmerge

There are some good points mentioned above.


> I have a theory, Jim. I think the developers don't document things (or
> comment their code) for 2 reasons: 1, They want to be able to change methods
> and behaviors without having to maintain documentation, and 2, They want to
> make money doing consulting jobs for people who commit ffmpeg for their
> projects, then give up trying to write ffmpeg command lines.

This conclusion however is way to unbalanced.

I will bring up a point that has become clear to me.

Good documentation in general and especially for software is
incredibly hard to write and get right!

In general you have to be a good writer and have sufficient
insight into the tech you are documenting. And this means for
FFmpeg you need to understand C enough, so you can roughly
read the code and are able to ask the right questions.

You need to have enough multimedia knowledge and experience
so you can try things yourself and write things in sufficiently
understood language.

You need to cope with (gradual and sometimes sweeping) change and
especially for projects like FFmpeg that means big restructurings
in the documentation every so often.


  Alexander