On Fri, Jun 03, 2016 at 10:08:16AM +0100, Mark Thompson wrote:
> 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").if you want to maintain the code you are author of, please send a patch for the MAINTAINERs file [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
