Re: [FFmpeg-devel] [RFC] Moving edit list handling out of demuxers

[Michael Niedermayer <michael@niedermayer.cc>]

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

Hi

On Fri, Jun 13, 2025 at 04:53:14PM +0200, Tomas Härdin wrote:
> fre 2025-06-13 klockan 16:21 +0200 skrev Michael Niedermayer:
> > > 3) remove edit list hacks from all demuxers, especially mov.c
> > 
> > +1 (with ABI +2 bump)
> 
> I'm not sure why a (major?) bump would be necessary. Are removal of
> options a major bump, not a minor one?

removial of things is major, it can break user applications


> Either way, we could make the
> options ffmpeg.c ones rather than mov.c ones. There's going to be pain

unless iam missing something, this would still break library users


> either way, partly because doing this in the demuxer was the wrong
> thing to do in the first place.

yes, you are correct!


> Another case of "oh let's just do a
> quick and dirty thing" coming back to bite us.
> 
> Come to think of this, perhaps hiding this behind a major bump is not
> such a bad idea. That allows making more sweeping changes, including
> behavioral ones.

yeah


> 
> > > The main issue I see with this is that it risks turning ffmpeg into
> > > an
> > > NLE tool,
> > 
> > If ffmpeg could do NLE, that would not be a bad thing
> > And a full implementation of edit lists may be equivalent to this.
> > I think thats a win not a loss
> 
> Fair enough. So long as I don't have to implement it or think
> particularly much about it.

it will be needed to think about "if its possible" to implement
during API design

That said if
* proper edit list implementation is bascially NLE support

Then not only is it alot of work, it also allows us to attract a new
group of developers and users

That is either way it will be alot of work, no way around this.

But if we go all the way and implement NLE support, we also get
as reward more developers to help with that work and maintaince
and likely sponsors paying it.

if OTOH, we do it halfway and do edit lists but avoid NLE, its still
going to be about the same "alot of work" but in that case we get
no extra developers and no extra sponsors thus it could be actually more
work per person

Thus i suggest we pick the choice with more sponsors and more developers

[...]

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 

[-- 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".