Re: [FFmpeg-devel] [RFC] Moving edit list handling out of demuxers - Kieran Kunhya via ffmpeg-devel

From: Kieran Kunhya via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Cc: Kieran Kunhya <kieran618@googlemail.com>
Subject: Re: [FFmpeg-devel] [RFC] Moving edit list handling out of demuxers
Date: Fri, 13 Jun 2025 14:51:45 +0200
Message-ID: <mailman.3176.1749819125.1384.ffmpeg-devel@ffmpeg.org> (raw)
In-Reply-To: <19ff1126f1e93cdb4fdcf50fee499c02c5e85ea7.camel@haerdin.se>

[-- Attachment #1: Type: message/rfc822, Size: 5657 bytes --]

From: Kieran Kunhya <kieran618@googlemail.com>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [RFC] Moving edit list handling out of demuxers
Date: Fri, 13 Jun 2025 14:51:45 +0200
Message-ID: <CABGuwEkEw7NZHMST3-_a6Gx_+A3ERHtbdA2mxnSDE-Q2fh43hQ@mail.gmail.com>

On Fri, 13 Jun 2025, 12:56 Tomas Härdin, <git@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

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