[FFmpeg-devel] [PATCH] lavf/mov: Add support for edit list parsing.

Jan Ekstrom jeebjp at gmail.com
Sun Nov 13 13:26:32 EET 2016


On Fri, Oct 21, 2016 at 6:32 PM, Derek Buitenhuis
<derek.buitenhuis at gmail.com> wrote:
> The design one fist: This approach is fundamentally wrong. Edit lists are
> meant to be applied at presentation level, not packet level. The current
> implementation will cause problems in a number of cases:
>
>     * Audio packets. Especially audio packets with a large number of samples.
>       It's extremely likely that edits will not fall on packet boundaries, and
>       depending on the number of samples per packet, audio sync issues can and
>       will occur, even with smaller packets of e.g. 1024 samples, if there are
>       a large number of entries in the edit list. Gradual loss of sync will
>       occur.
>     * Edit list entries that are out of order, or repeat. This one is obvious;
>       simply dropping packets is not sufficient to create a virtual timeline
>       like edit lists can be used for by various NLEs. I need to look up
>       if these are actually allowed in the ISOBMFF of QT specs, but I know
>       Matroska allows it in its virtual timeline feature.
>     * Returning timestamps that differ from the codec timestamps. I very
>       much disagree with this approach. It's the responsibility of the
>       presentation/render/transcode/app/whatever layer to adjust timestamps
>       based on edits. I absolutely disagree with libavformat changing
>       timestamps from what is coded in the actual file. avformat provides
>       demuxers.

Hi Sasi, Derek,

As I see people having issues with this implementation, is there an
existing structure we can utilize to export the edit list information?
(aka "can something like the chapters structure be utilized") If not,
what would be the requirements based on qtff and ISOBMFF for virtual
timelines? Does the demuxer have such a structure already in place
after which the new metadata for virtual timelines could be based on?

We will have to take baby steps towards getting this stuff right. The
first step IMHO would be to export the edit list from the demuxer so
that the presentation layer can utilize its information. Hints on
where this information should be gathered from now that (I think) we
have the parsing code in the demuxer in place are very welcome as
well.

After we get the edit list export right, we will have to try and
integrate it into the mess that is ffmpeg.c.

Best regards,
Jan


More information about the ffmpeg-devel mailing list