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

[Sasi Inguva]

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