On Thu, Nov 9, 2017 at 9:38 PM, Jaroslav Kysela <pe...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
