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?
_______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
