ping! On Fri, Aug 19, 2016 at 9:49 AM, Sasi Inguva <is...@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 <is...@google.com> wrote: > >> Thanks >> >> On Aug 17, 2016 6:25 AM, "Clément Bœsch" <u...@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@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> >>> > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
