On 20/04/12 07:38, Yusuke Nakamura wrote: > 2012年4月18日1:12 Derek Buitenhuis <[email protected]>: > >> On 16/04/2012 10:52 AM, Yusuke Nakamura wrote: >>> The second patch may deny >> http://git.libav.org/?p=libav.git;a=commit;f=libavformat/mov.c;h=26846ba5151b0fe90e21c1a6beb9a3bcb569d1ac, >> while this commit denies splitted files with gradual decoder refresh (not >> marked as a sync sample in 14496-15 spec). >>> So, I prefer the second patch to this commit. >> >> The first patch looks reasonable to me, but I'm unsure of >> whether the second patch is a good idea or not -- key_off >> will always end up being 1, even if sc->keyframes[0] and/or >> sc->stps_data[0] are > 1. Seems like it could break things >> or have unintended consequences. Perhaps someone more >> familiar with mov.c could comment. >> >> - Derek >> _______________________________________________ >> libav-devel mailing list >> [email protected] >> https://lists.libav.org/mailman/listinfo/libav-devel >> > > The gist of the second patch is supporting for AVC-in-MP4 starting at frame > with recovery point SEI. > 14496-15 defines type of frame that can be a sync sample is only IDR, i.e. > a random accessible frame that is such as open-gop I-frame and/or any frame > that is a starting point of certain GDR are not marked as a sync sample. > In this case, obviously stss indexes of the file doesn't start at 1, and > without this patch libavformat won't set up keyframe (IDR-frame) positions > correctly. > So, the focus of the problem is whether we continue to support non-spec > compliant files (0-origin indexes), or discard them and support > spec-compliant files that contain incomplete frames early. > > Does anyone have more comments? >
The second patch seems fine from your explanation. lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
