On 12/15/2019 7:00 PM, Michael Niedermayer wrote:
> Fixes: Ticket7249 (No longer displaying a scary red message)
>
> Signed-off-by: Michael Niedermayer <mich...@niedermayer.cc>
> ---
> libavcodec/h264_ps.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> index e8738d8502..74f12f8979 100644
> --- a/libavcodec/h264_ps.c
> +++ b/libavcodec/h264_ps.c
> @@ -203,6 +203,10 @@ static inline int decode_vui_parameters(GetBitContext
> *gb, AVCodecContext *avctx
> sps->num_units_in_tick = num_units_in_tick;
> sps->time_scale = time_scale;
> }
> + if (get_bits_left(gb) == 0) {
Doing this check here sounds like it's tailored specifically for the
sample in the ticket. What if another file is truncated one bit after
this point? Or one bit before? You will get the scary red message for
it. Will you also add a check for it?
We can't clutter this file with new get_bits_left() checks every time a
user shares their broken samples with us just to get a less scary output
in their terminals.
A better "fix" for this is mapping the AV_EF_IGNORE_ERR err_recognition
avctx flag to the ignore_truncation parameter in
ff_h264_decode_seq_parameter_set(), and removing the fallback call that
hard enables it in the decoder. That way, the user will get warnings
instead of errors when they use that flag to request these truncation
errors to be ignored.
> + av_log(avctx, AV_LOG_WARNING, "Truncated VUI before
> fixed_frame_rate_flag\n");
> + return 0;
> + }
> sps->fixed_frame_rate_flag = get_bits1(gb);
> }
>
>
_______________________________________________
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".
