[FFmpeg-devel] [PATCH] h264dec: h264_select_output_frame() - fill correctly has_b_frames based on the level

[Hendrik Leppkes]

On Thu, Nov 9, 2017 at 9:38 PM, Jaroslav Kysela <perex at perex.cz> wrote:
> The current code does not handle correctly the situation when sps->num_reoder_frames
> was set using the level. The incorrect has_b_frames results in the wrong DTS guess and
> malformed output (wrong 'Non-monotonous DTS' fixup).
>
> sps->num_reorder_frames is set in the function ff_h264_decode_seq_parameter_set(),
> see comment: 'if the maximum delay is not stored in the SPS, derive it based on the
> level'.
>
> Issue: #6810
> ---
>  libavcodec/h264_slice.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 35dcabd611..04b10656e0 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -1287,6 +1287,7 @@ static int h264_select_output_frame(H264Context *h)
>      h->mmco_reset = 0;
>
>      if (sps->bitstream_restriction_flag ||
> +        sps->ref_frame_count ||
>          h->avctx->strict_std_compliance >= FF_COMPLIANCE_STRICT) {
>          h->avctx->has_b_frames = FFMAX(h->avctx->has_b_frames, sps->num_reorder_frames);
>      }

This behavior has actually been intentional in the past to keep the
decode delay lower.
If this is supposed to be changed (which needs to be discussed first),
the std_compliance value should probably be adjusted to NORMAL instead
of strict, instead of adding the additional condition here
(num_reorder_frames is only set from the profile if ref_frame_count is
> 0 in the first place).

- Hendrik