[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