On 10/12/2018 01:56, myp...@gmail.com wrote:
> On Mon, Dec 10, 2018 at 2:08 AM Mark Thompson <s...@jkqxz.net> wrote:
>>
>> On 06/12/2018 10:39, Jun Zhao wrote:
>>> Fix slice number check logic. Only when the user setting slices
>>> number more than the driver constraints dump the rounded up warning
>>> message.
>>>
>>> Signed-off-by: Jun Zhao <mypopy...@gmail.com>
>>> ---
>>> libavcodec/vaapi_encode.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>>> index eda8a36..3c8a33d 100644
>>> --- a/libavcodec/vaapi_encode.c
>>> +++ b/libavcodec/vaapi_encode.c
>>> @@ -1572,7 +1572,7 @@ static av_cold int
>>> vaapi_encode_init_slice_structure(AVCodecContext *avctx)
>>> , tnereturn AVERROR(EINVAL);
>>> }
>>>
>>> - if (ctx->nb_slices > avctx->slices) {
>>> + if (ctx->nb_slices < avctx->slices) {
>>> av_log(avctx, AV_LOG_WARNING, "Slice count rounded up to "
>>> "%d (from %d) due to driver constraints on slice "
>>> "structure.\n", ctx->nb_slices, avctx->slices);
>>>
>>
>> No? The existing check looks right to me - we warn if the number got
>> increased over what the user specified due to driver constraints. (We don't
>> allow it to decrease unless the supplied number is larger than the number of
>> rows, which gets warned about above there.)
>>
> I think avctx->slices is user setting value and ctx->nb_slices is the
> driver constraints,
This is correct.
> so I think we need to check avctx->slices >
> ctx->nb_slices, then give a rounded up warning. :)
avctx->slice > ctx->nb_slices would mean that the driver constraint number is
/less/ than number the user set; that would be rounding down. This case isn't
allowed by the code above except for the degenerate example where the user
setting is greater than the number of rows, which is already warned about.
What we are actually checking for here is the driver constraint number being
/greater/ than the number the user set (that is, that ctx->nb_slices >
avctx->slices), and then warning the user that their supplied number has been
rounded up to the next available possibility and that the output stream will
therefore contain more slices than expected.
- Mark
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
