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

["Tomas Härdin" <git@haerdin.se>]

ons 2025-06-18 klockan 05:55 +0200 skrev Michael Niedermayer:
> What you suggest or hint toward to me, in plain english sounds like,
> drop the ffmpeg command line tool because it would otherwise need to
> have NLE support.

I am not suggesting that. As many others have been pointing out
recently, we don't have to support literally every use case. We can say
that we will transcode essence and expose/map relevant metadata/side
data. We can say that it is up to users to implement the relevant
business logic. melt again serves as a useful example. Another way
could be writing a Python program that parses edit list data supplied
by ffprobe, building an ffmpeg command line that it then executes to
effect the desired rendering


> My way is forward,
>     a streaming server (IF there are people who want to work on it),
>     NLE (IF there are people who want to work on it)
>     anything else multimedia related (IF there are people who want to
> work on it)

You should know by now that a significant fraction of developers
disagree with the kind of scope creep this implies


> If we dont implement full edit list support, then we should not
> pretend
>     1. ffmpeg even supports mov or mp4 (and thats the end of ffmpeg.)

FFmpeg does not support Flash or 3D meshes in mov files either. Despite
this, the world has not ended

> 3. a way to apply a edit list, so
>    mov (with edit list) ->  mpeg-ts (no edit lists) works

There is no "correct" way to do this that satisfies every user. This is
why I say this kind of stuff is business logic. It could be handled by
a small shell script. Or Python. Either way, it does not belong in lavf

>    also another example for "apply" is a player, which also needs to
> apply
>    the edit lists to be able to present a file to a human
>    thats ffplay but also many other players that use libavcodec &
> format

Yes, such as melt. Which already exists and does all the stuff
necessary for NLE work, so there's no need for us to reimplement it

In order to unblock work on fragmented indexes, which is important for
both mov and mxf, I need to be absolutely certain that the change in
behavior that this entails can be effected. I'm already working on the
assumption that it can be guarded by a major version bump. I can put
the API in place, after which someone else can implement the necessary
rendering if they really want to. It is not reasonable at all that an
already complicated task (opening .mov without having to parse the
entire damn file) is predicated on implementing a whole damn NLE
framework as well. Especially when such code already exists (libmlt)

The upside of a proper API is that we can export edit lists from other
formats as well, such as:

* IMF
* MKV
* MXF

Sharp minds should have realized back in 2016 that any hack that
"implements" edit lists in mov.c would also have to be duplicated in
demuxers for other formats with similar functionality. Which is just
silly. It was wrong then and it is wrong now

/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-request@ffmpeg.org with subject "unsubscribe".