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 <nfx...@googlemail.com> wrote: > On Fri, 5 Aug 2016 17:18:39 -0700 > Sasi Inguva <isasi-at-google....@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@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
