On 03/06/16 09:32, Matthieu Bouron wrote:
> On Thu, Jun 02, 2016 at 10:36:21PM +0100, Mark Thompson wrote:
>> On 02/06/16 22:00, Matthieu Bouron wrote:
>>> On Thu, Jun 02, 2016 at 07:13:39PM +0100, Mark Thompson wrote:
>>>> ---
>>>> ... something like this.
>>>>
>>>> libavcodec/vaapi_encode_h264.c | 6 ++++++
>>>> libavcodec/vaapi_encode_h265.c | 6 ++++++
>>>> 2 files changed, 12 insertions(+)
>>>>
>>>> diff --git a/libavcodec/vaapi_encode_h264.c
>>>> b/libavcodec/vaapi_encode_h264.c
>>>> index 0a99bb1..019ed1f 100644
>>>> --- a/libavcodec/vaapi_encode_h264.c
>>>> +++ b/libavcodec/vaapi_encode_h264.c
>>>> @@ -731,6 +731,12 @@ static av_cold int
>>>> vaapi_encode_h264_init_constant_bitrate(AVCodecContext *avctx
>>>> int hrd_buffer_size;
>>>> int hrd_initial_buffer_fullness;
>>>>
>>>> + if (avctx->bit_rate >= 1u << 31) {
>>>
>>> Wouldn't INT32_MAX be more aproriate ?
>>
>> Hmm. No preference - I went for 1u << 31 to match the 2^31 in the error
>> message, but maybe INT32_MAX makes the code constraint slightly clearer.
>
> IMHO, I think it's clearer to use INT32_MAX but as you are the maintainer
> of those encoders, it's up to you to decide.
While I may be the de facto maintainer (having written all of the code), I am
not the de jure maintainer and I do not have commit access. Please do just
commit this patch, including your change ("> INT32_MAX").
Thanks,
- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
