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

[wm4]

On Tue, 18 Oct 2016 13:08:07 -0700
Sasi Inguva <isasi-at-google.com at ffmpeg.org> wrote:

> 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
> >  
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Certainly it could do something better than just returning e.g. the
same DTS for many packets.

I'm still amazed we merged this at all.