It is not necessary to pad to the CTU size. The CB size of 8x8 should be
sufficient, but due to constraints in the Intel driver (the one usable
implementation of this) it has to be padded to 16x16 like in H.264.
---
On 12/08/17 17:02, Anton Khirnov wrote:
> Quoting Mark Thompson (2017-08-11 01:37:06)
>>
>> - priv->ctu_width = FFALIGN(ctx->surface_width, 32) / 32;
>> - priv->ctu_height = FFALIGN(ctx->surface_height, 32) / 32;
>> + // This seems to be an Intel driver constraint. Despite MinCbSizeY
>> + // being 8, we are still required to encode at 16-pixel alignment and
>> + // then crop back (so 1080 lines is still encode as 1088 + cropping).
>> + priv->ctu_width = FFALIGN(ctx->surface_width, 16) / 16;
>> + priv->ctu_height = FFALIGN(ctx->surface_height, 16) / 16;
>
> Is this related to the rest of the patch? Does not seem so.
>
> Otherwise looks ok as far as I can tell.
Split off as enclosing patch.
- Mark
libavcodec/vaapi_encode_h265.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 477065e2c..165b6ffde 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -815,8 +815,11 @@ static av_cold int
vaapi_encode_h265_configure(AVCodecContext *avctx)
if (err < 0)
return err;
- priv->ctu_width = FFALIGN(ctx->surface_width, 32) / 32;
- priv->ctu_height = FFALIGN(ctx->surface_height, 32) / 32;
+ // This is an Intel driver constraint. Despite MinCbSizeY being 8,
+ // we are still required to encode at 16-pixel alignment and then
+ // crop back (so 1080 lines is still encoded as 1088 + cropping).
+ priv->ctu_width = FFALIGN(ctx->surface_width, 16) / 16;
+ priv->ctu_height = FFALIGN(ctx->surface_height, 16) / 16;
av_log(avctx, AV_LOG_VERBOSE, "Input %ux%u -> Surface %ux%u -> CTU
%ux%u.\n",
avctx->width, avctx->height, ctx->surface_width,
--
2.11.0
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
