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

[Sasi Inguva]

With the current state of code, we will only encounter    demuxer
outputting non-monotonic DTS  when there are multiple edit lists . Avoiding
non-monotonic DTS for mulitple edit lists will not be possible with how the
edit list support is currently implemented. That would only be possible if
the edit list support is implemented after the decode is done.

The only situation I see where things will break is if a file containing
multiple edit lists is remuxed to another container , and we are not
rewriting timestamps but passing through. In that case the av_write_frame
will fail with non-monotonic DTS  provided.

However consider the alternative. We have demuxer giving monotonic DTS
which does not at all correspond to the timeline that edit lists intend. We
remux successfully, but we have generated a file with AVSync problems, and
which plays wrong.

On Tue, Oct 18, 2016 at 7:31 AM, wm4 <nfxjfg at googlemail.com> wrote:

> On Fri,  5 Aug 2016 17:18:39 -0700
> Sasi Inguva <isasi-at-google.com at ffmpeg.org> wrote:
>
> > In YouTube we have long been receiving MOV files from users, which have
> non-trivial edit lists (Those edit lists which are not just used to offset
> video start from audio start) and multiple edit lists. Recently the uploads
> of such files has increased with the introduction of apps that allow video
> editing and upload like Vine etc. mov.c in ffmpeg does not have edit list
> parsing support i.e. the support for deciding what video/audio packets
> should be output with what timestamps, based on edit lists. For this
> reason, we had built a basic support for edit list parsing in our version
> of ffmpeg, which fixes the AVIndexEntries built by mov_build_index by
> looking at edit lists, and introduces new DISCARD flags in AVPacket and
> AVFrame to signal to the decoder to discard certain packets.
> >
> > For a while our edit list support was broken, as in it didn't properly
> work for multiple edit lists and it had problems with edit-lists ending on
> B-frames. But we've fixed most of these issues in recent times, and we
> think that now it is in a good enough condition so that it can be submitted
> to HEAD. This will not only help the vast userbase of ffmepg, but will also
> help us with staying up-to-date with ffmpeg and also by adding the power of
> ffmpeg developer community to our MOV support. So here's a go at it.
> > What is supported:
> >  - multiple edit lists
> >  - edit lists ending on B-frames
> >  - zero segment duration edit lists
> >
> > What is not supported:
> >  - Changing the rate of playing with edit lists. We basically ignore
> MediaRate field of edit.
> >
> > I have added fate tests too. Here is a no-sign-in required link to the
> test files https://drive.google.com/folderview?id=0Bz6XfEJZ-
> 9N3R3o3QXNHUGRqbms&usp=sharing.
>
> This still makes demuxers output packets with _not_ strictly
> monotonically increasing DTS timestamps. Please fix this - a demuxer
> isn't supposed to do this, and it's completely broken.
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>