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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
