[FFmpeg-devel] [PATCH 14/18] h264_ps: make the PPS hold a reference to its SPS
James Almer
jamrial at gmail.com
Wed Mar 18 18:05:38 EET 2020
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
More information about the ffmpeg-devel
mailing list