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

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 4982 bytes --]

On Sun, Jul 24, 2022 at 05:10:17PM +0200, Nicolas George wrote:
> I hesitated a long time before replying, but all considering, at this
> point expressing what is weighing on my heart cannot make things worse.
> 
> 
> Michael Niedermayer (12022-07-03):
> > What is the timeline for the audio+video merge ?
> 
> I cannot give a timeline because I do not work on FFmpeg on a schedule,
> I work on FFmpeg in my free time, for fun. And lately, working on FFmpeg
> has been really un-fun. Recently, my contributions have been met with

I think many if us, myself included have had un-fun periods in ffmpeg.
This on its own is already bad and we should strive to make project
contributions more fun to all.



> indifference at best (see when I proposed a XML parser six months ago:
> nobody cared), outright hostility at worst. Under these circumstances,
> whenever I am considering working on something FFmpeg-related, I usually
> find something else more fun to do.

If we add a XML parser to FFmpeg. Such a thing would be used by several
bits and we need to ensure it has redundant maintainership.
So i think a xml parser needs broad support by developers otherwise we
run the risk that if it has a single maintainer only and that maintainer
stops maintaining it that could be annoying to more than just the parser
itself.
I cannot remember exactly without re-reading the old thread what the issues
people had with the xml parser. If it was some component of it or in general.
But i think its mostly a question if theres more than one person who wants
to maintain it.


[...]

> It illustrates what it means to be a maintainer. It does not only mean
> the task of reviewing and applying bug fixes. The maintainer holds in
> their head a knowledge of the code that cannot be fully shared in
> writing. The maintainer also holds in their head plans to evolve and
> extend the code.
> 
> I have plans for libavfilter. Not just vague ideas, but precise plans on
> how to reach the goal. I have plans for subtitles filtering, of course.
> But not only.
> 
> I have plans for filtering data packets, so that bistream filters do not
> need to have a separate and redundant API and ffmpeg does not need a
> separate code path for -c copy.
> 
> I have plans for threading, or more precisely integrating filters in a
> global parallelized task and I/O scheduler.
> 
> I have plans for seeking, with the seek target going back from the
> output to the input(s).
> 
> I have plans for partial graph reconfiguration, to accommodate format
> changes mid-stream and let applications alter filtering in the middle.
> 
> All of this is exciting. I am eager to work on any of this.
> 
> Unfortunately, before it can happen, boring things need to be done.
> Parts of the framework of libavfilter are very fragile. Working on any
> of these is likely to break cases that were specifically fixed in the
> past.
> 
> I can work on boring things if they are necessary to reach the exciting
> parts.
> 

> What I cannot do is motivate myself to work on the boring things with
> the threat that the exciting things will be snatched under me by an
> inferior version from somebody who just refuses to engage with the
> boring necessary things.

If you work on libavfilter, noone will snatch it from you. If you
dont work on it, eventually someone else will attempt to take over and
push libavfilter in the direction he feels best which may or may not 
match what you want.
If theres something i can do to make libavfilter work more fun for you
please tell me.

I think it would be best if people worked a bit more together on this.
The current situation where work is split between your vission and this
patchset is kind of a bad thing.
Its a bit unfortunate noone involved seems to have the carismatic leader
skills to pull everyone on his side and then get that side to the point
that everyone is happy with the code 
and neither has a consensus emerged based on technical arguments.
I think maybe more a "what is best for the project to move forward" and a
less "how can i get my hard work in first" approuch might help
but we can also try the technical commiitee of course 
but iam not sure how much that would really help, it would be better if
some consensus would be reached and everyone would then work together on
implementing that
theres of course also the fork and merge approuch. Each side does whatever
they like in their repository and then we at some point compare and merge one
or both into ffmpeg. Iam not sure thats a good idea or not.

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".