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.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
