On 3/13/2020 7:28 AM, Anton Khirnov wrote: > It represents the relationship between them more naturally and will be > useful in the following commits. > > Allows significantly more frames in fate-h264-attachment-631 to be > decoded.
That sample is odd. It has an SPS/PPS pair in extradata that's wrong for the Buffering Period and Picture Timing SEI messages in-band, but seemingly correct to actually decode all these frames revealed by this patch. The SPS that makes the aforementioned SEI messages parseable, but the frames seemingly undecodeable, is in-band in the second RAP (Which fwiw reports a different bitstream level). So this patch prevents the extradata PPS from using the in-band SPS after it replaced the extradata one in sps_list. There's no PPS in-band. Is this really intended? Is the active PPS' sps_id meant to reference the SPS with that id that's currently "valid" and in sps_list, or the whichever one was valid at the time the PPS was first parsed?. If the latter, then why replace the SPS in-band but never the PPS? The in-band SPS is virtually unused after this change. > --- > libavcodec/h264_ps.c | 29 +++++- > libavcodec/h264_ps.h | 3 + > libavcodec/h264_slice.c | 14 +-- Missing changes to h264_parser.c, and one "h->ps.sps == (const SPS*)h->ps.sps_list[h->ps.pps->sps_id]->data" check in h264dec.c _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
