On Tue, 18 Oct 2016 13:08:07 -0700 Sasi Inguva <isasi-at-google....@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 <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 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. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
