[FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.
isasi at google.com
Tue Aug 16 05:04:56 EEST 2016
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.
More information about the ffmpeg-devel