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

[Tomas Härdin]

fre 2025-06-13 klockan 18:19 +0200 skrev Michael Niedermayer:
> 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

Sounds like you're not opposed to removing the hacks from the demuxer
then, even if this results in a change in behavior, assuming it is done
after a major version bump. Very good.

> > > > 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

*We* shouldn't necessarily be attracting them. Libre multimedia is more
than just FFmpeg. It is better to focus NLE efforts on melt. We can
explicitly declare that FFmpeg's task is to carry the necessary
timeline metadata, and the essence, unmolested between formats. When
this is not possible, such as remuxing OP3c MXF to MOV, the ffmpeg CLI
should complain loudly. The present state of things is bad, because
essence is silently discarded by default. I'm sure Google's use case
can be accommodated with a small shell script combining ffmpeg and melt
(the elst hack appears to originate from Google)

Exposing this metadata on the other hand is highly useful to projects
like melt, because it allows proper handling of MOV-elst and higher
operational pattern MXF in tools like kdenlive. kdenlive can already
generate "scripts" that can be used to render timelines on the terminal
via melt. There is no need for us to reimplement such functionality.

FFmpeg's architecture is wholly unsuitable for NLE work. That way lies
madness. This becomes apparent when looking at melt. I suggest more
devs take a look at it.

/Tomas