I am also happy to fix any breaking files, if they don't fall under the above category.
On Tue, Oct 18, 2016 at 1:08 PM, Sasi Inguva <is...@google.com> 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-9N3R3o3QXNH >> UGRqbms&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