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

[Kieran Kunhya]

On Fri, 13 Jun 2025, 12:56 Tomas Härdin, <git at haerdin.se> wrote:

> Hi
>
> In my fiddling with fragmented indexes in mov.c I ran cross
> mov_fix_index(), which has been in the codebase since September 2016.
> The intent of this function is to implement limited support for edit
> lists (elst). More rudely one could say it implements half-assed
> support for edit lists. Besides the way it's implemented being
> incredibly cursed, I feel strongly that this is not something that a
> demuxer should do, partly because it's not something a demuxer *can*
> do. There are a number of reasons why:
>
> 1) demuxers are not part of the presentation layer
> 2) the demuxer must lie about what the file actually contains
> 3) the ISOBMFF spec mandates being able to cut on samples, not just
> frames. for audio, there is no way to do that from a demuxer
> 4) similarly, there is no way (I think) to implement "dwell" segments
>
> The second point becomes painfully clear when one looks at
> mov_fix_index(). FFStream.index_entries is completely replaced. The
> function is not idempotent. For the kind of work I'm doing right now
> this is a huge problem.
>
> As I see it, the way forward is:
>
> 1) introduce API for edit lists, so that users can decide themselves
> what to do
> 2) implement basic support for edit lists in the ffmpeg CLI
> 3) remove edit list hacks from all demuxers, especially mov.c
>
> The main issue I see with this is that it risks turning ffmpeg into an
> NLE tool, which would be a waste of developer effort better spent on
> melt and related tools (kdenlive, shotcut etc). The present level of
> edit list support could be reimplemented by just fiddling with the -ss
> and -t options. That is, the ffmpeg CLI could automatically derive -ss
> and -t from the edit list extracted by lavf.
>
> If this stuff is done correctly then it should be possible to remux MOV
> to MXF while keeping the edit lists and the original uncut essence. And
> of course back again to MOV if so desired.
>
> I haven't sketched out any API yet, but it would probably closely
> mirror how elst works in MOV. Care should be taken that MXF operational
> pattern 3a can also fit into this API. Possibly even OP3c.
>
> Thoughts?


Derek did this in 2018:

https://ffmpeg.org/pipermail/ffmpeg-devel/2018-March/227437.html

Kieran