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

[Sasi Inguva]

ping!

On Fri, Aug 19, 2016 at 9:49 AM, Sasi Inguva <isasi at google.com> wrote:

> I don't know who the owner of MOV demuxer is. If somebody could do a
> deeper review of this patch and approve it that would be great.
>
> Thanks,
> Sasi
>
> On Wed, Aug 17, 2016 at 8:59 AM, Sasi Inguva <isasi at google.com> wrote:
>
>> Thanks
>>
>> On Aug 17, 2016 6:25 AM, "Clément Bœsch" <u at pkh.me> wrote:
>>
>>> On Mon, Aug 15, 2016 at 07:04:56PM -0700, Sasi Inguva wrote:
>>> > Changes done. Also commented in the code about the differences between
>>> the add_index_entry function and teh ff_add_index_entry function.
>>> >
>>> > About stream copy, yes there will be a big behavior difference when
>>> doing "-c copy" for files with edit lists.
>>> > Currently, ignoring edit lists we will copy all packets from input to
>>> output. So for videos with edit lists the current way of stream copy is
>>> already semantically wrong. In summary these will be the changes with this
>>> patch
>>> > i) For videos with no edit lists - no change.
>>> > ii) For videos with one edit list in their streams
>>> >           - Only portion of the video from the closest keyframe before
>>> the edit list begins, to the closest keyframe after the edit list ends will
>>> be copied.
>>> >           - All audio from the start of the audio stream to the end of
>>> the edit will be copied.
>>> >
>>> > iii) For videos with multiple edit lists in their streams
>>> >           - For video, the timestamps can be non-monotonocially
>>> increasing. Keyframe packets might be repeated. etc.
>>> >           - For audio too, timestamps can be non-monotonically
>>> increasing. For each edit list we will output packets from the start of the
>>> audio stream, so audio will be repeated.
>>> >
>>> > Though points (ii) and (iii) might look dangerous, we should keep in
>>> mind that it is very hard, and maybe impossible to implement proper stream
>>> copy of only those portions of streams which are inside edit lists. We need
>>> a way to mark some frames as decode-and-discard, and maybe writing edit
>>> lists in case of MOV container is a way but if we are doing  -c copy to
>>> some other container, it won't be possible mostly. If (ii) and (iii) sound
>>> unacceptable I can gate the mov_fix_index function behind a no-stream-copy
>>> condition, if there is a way to do so.
>>> >
>>>
>>> OK.
>>>
>>> So. I've made some test with a bunch of personal samples from different
>>> different sources and it fixes the playback for all of them. I don't have
>>> much more comment as it seems to work well. I'm not the maintainer of the
>>> MOV demuxer though, so don't take this as a OK.
>>>
>>> Someone should probably do a deeper review (hint: look at mov_fix_index()
>>> in particular)
>>>
>>> Thanks
>>>
>>> --
>>> Clément B.
>>>
>>> _______________________________________________
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel at ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>>
>