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

[Clément Bœsch]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160817/56981916/attachment.sig>