> On May 13, 2022, at 5:43 PM, Andreas Rheinhardt
> <andreas.rheinha...@outlook.com> wrote:
>
> Zhao Zhili:
>> has_b_frames should be output_reorder_delay field in AVS3 sequence
>> header and larger than 1. The parser implementation doesn't parse
>> that field. Decoder can set has_b_frames properly, so use FFMAX
>> here to avoid resetting has_b_frames from output_reorder_delay to 1.
>> ---
>> libavcodec/avs3_parser.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/avs3_parser.c b/libavcodec/avs3_parser.c
>> index d04d96a03a..0d2e940d1e 100644
>> --- a/libavcodec/avs3_parser.c
>> +++ b/libavcodec/avs3_parser.c
>> @@ -114,7 +114,7 @@ static void parse_avs3_nal_units(AVCodecParserContext
>> *s, const uint8_t *buf,
>> // bitrate_high(12)
>> skip_bits(&gb, 32);
>>
>> - avctx->has_b_frames = !get_bits(&gb, 1);
>> + avctx->has_b_frames = FFMAX(avctx->has_b_frames, !get_bits(&gb,
>> 1));
>>
>> avctx->framerate.num = avctx->time_base.den =
>> ff_avs3_frame_rate_tab[ratecode].num;
>> avctx->framerate.den = avctx->time_base.num =
>> ff_avs3_frame_rate_tab[ratecode].den;
>
> FFMAX can evaluate its arguments more than once which is not intended here.
Good catch, thanks! Here is v2:
http://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296396.html
Use a variable low_delay to fix the FFMAX issue and serve as document.
>
> - Andreas
> _______________________________________________
> 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".
_______________________________________________
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".
