[FFmpeg-devel] [PATCH v5 00/25] Subtitle Filtering 2022

[Nicolas George]

Ronald S. Bultje (12022-07-25):
> We still do this, but currently outside FFmpeg (dav1d). So sadly, it's a
> bit more out of the sphere of this mailinglist. So we take risks, and if
> AV2-9 comes around, we might again. But we still consider ourselves part of
> the FFmpeg community, and I still try to review ffvp9 patches when they
> come up every once in a while. Don't lose hope, just find the positive
> things and work on them. Ignore the rest. I know I did. I'm having fun
> again.
> 
> I don't know if I should offer advice, but my $.02: maybe adding tests (I
> don't mean ffmpeg invocations; some people would call this desired
> outcomes) might help here. You probably remember how Michael tested patches
> pre-FATE: for a particular patch, he'd send an FFmpeg commandline that
> either A) gives (undesirable) different output before vs. after patch, or
> B) should give some correct/desired output after the patch but (still)
> doesn't (and this second would be what I'm inviting you to do). Tests don't
> have to be scripted, they can simply be a list of features or behaviors
> desired in the new design. It's true that perfection is the enemy of
> progress, but I think you're right that we should try to strive for further
> improvement if it is within reach, especially for base design or things
> with API implications. (FFmpeg's API is a testament to poor design in some
> places.) You're likely better at making a comprehensive list than anyone
> else. Making the list public/explicit means other people can help
> accomplish the full list of features.

Thank you for these kind and encouraging words.

The fact that the new developments happen in separate project kinds of
confirms my impression that the project has become afraid of taking
risks.

It makes me think of these artists who found a rich patron and, dazzled
by the money and luxury, become afraid of offending them and have their
art lose its edge. FFmpeg is so eager to please our corporate users, to
look “serious”, to look “professional” that sometimes it almost feels
like grovelling, and it stifles novelty.

Another symptom of this I see is that Michael spends most of his time
managing releases and fuzzing and fixing trivial bugs, tasks that are
way below his skills and talent, instead of writing new code. Or maybe I
am just wrong and that is what he likes to do most.

As for me… I am not good at shaving cycles from inner loops, which is
the heart of FFmpeg's superiority, I cannot contribute to it. What I
think I can contribute (and thank you for suggesting I am not wrong) is
in areas of API and architecture.

Unfortunately, while support for a new codec or optimization on an
existing one will receive no objection on principle, work on API or
architecture affect everybody and therefore is subject to much more
discussion, possibly to the point of deadly bikeshedding or outright
rejection.

That makes it hard to invest time in it without some kind of a-priori
assurance. Unfortunately my attempts to spark discussions have been met
with indifference:

https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/274167.html
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-December/thread.html#274167

(I realize I could probably work on internal error messages. As for
event loop, the other one that has received positive feedback, I was
trying to find a more efficient way out of a small quandary, I should
probably go back to it.)

Or even worse:

https://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/290226.html
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/thread.html#290226

(A good string API is a pre-requisite for several other projects.)

What I think this project need is a leader, or a leading committee:
somebody who can decide beforehand if a change in API or architecture is
worth it, and therefore worth the time of the developer, with a decision
that is binding to the project: when the code is written, other
developers may discuss technical details but not reject the change
itself.

Maybe the technical committee could endorse this role, even though it
was not exactly why it was elected.

Thanks,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220725/5f935188/attachment.sig>