From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 36BF848B07 for ; Mon, 1 Apr 2024 19:51:52 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2688268CF50; Mon, 1 Apr 2024 22:51:50 +0300 (EEST) Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id B717968CDD9 for ; Mon, 1 Apr 2024 22:51:43 +0300 (EEST) Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4156e5c1c7eso2131745e9.1 for ; Mon, 01 Apr 2024 12:51:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jkqxz-net.20230601.gappssmtp.com; s=20230601; t=1712001103; x=1712605903; darn=ffmpeg.org; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=tOp3YSfph0s8BAmhpm2ZVM95s44v31xQ7c04gnATUY8=; b=1JKRMV1OIl+x+PeeRx7bAhgYroj60TSc1UePkg9NemIh6Gj7nmP+7sqY8aOjQrMKoV knw1Enwa1xdiP88KrGhT1I5zdtsCgY2rAQStkzjH1bhoapkFwLsdalWGwgtZ5MZYsrgk BDGQJXjQyyc4MAxYjcEQE+FfiC5A+6P3KcGip7K8WGE/wKi/t4FJa1EXSTXNh4jE+o8u fo34ew8mHl+axSwhKHJ9eIb8otKsche0lrYNrNyiz8eUEx2fIKIq/enSuBPkArdXOLbl 4gYHcGib8lpDtKwBT9gIXUtZP91/z4D9GWxCROKoUP1RtmMw13YxqqBZjWBmGfHnfmOX zZCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712001103; x=1712605903; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tOp3YSfph0s8BAmhpm2ZVM95s44v31xQ7c04gnATUY8=; b=Zp0gvTi+33x1Jj++5annANHFtnzHpncldjjEkElN4dKOgnIpyyfqNpfIJRNFpijVOX c5bs4tyEWtKRoEgf1MzhNX8N0QfynrSbKZLZCd9GTw7UyCIqt8fDggNDzZ/0kEdL0jaH RU7Y4Vg9nBMCKnIE52swjxBXqxmUNrOTusbHLrFl5stVLocw6aBxVik9bIRQVTS0kWq8 BRv89wO9icjdtOR3CkbGMvBWM+z8Wqy3i4JtytjOxxchMfgwkeiw8XtNIjk0swPs41Mu yqqUCaeIeYjcjUo8MH7m2Yc6LLE7fCjVH0DdsZRJFKpeJecNqFbLeLdcf6N60Lu4aRv0 tJcw== X-Gm-Message-State: AOJu0YwG6Pvc7YMH3Dc2lzT9bVfNlXVvNFFdtSmdmz9guJ/adpudtrt3 bCukQ9tmhnL4jkhyDHBC679a3tsgeNdJz1d20jKiJGdzhReRn7I5kohCoGY5/hWOovfhlIO7PuH h X-Google-Smtp-Source: AGHT+IGDoXODsrCh/DBAmkDp4mOPx3OeMA03aS12PWYdPDphUO0pFWnM1MD1YQfEOaolgeMIEJTZPQ== X-Received: by 2002:a05:600c:4f85:b0:415:666e:9355 with SMTP id n5-20020a05600c4f8500b00415666e9355mr2501316wmq.15.1712001102853; Mon, 01 Apr 2024 12:51:42 -0700 (PDT) Received: from [192.168.0.15] (cpc92302-cmbg19-2-0-cust1183.5-4.cable.virginm.net. [82.1.212.160]) by smtp.gmail.com with ESMTPSA id u22-20020a05600c139600b00414906f1ea1sm15532799wmf.17.2024.04.01.12.51.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 01 Apr 2024 12:51:42 -0700 (PDT) Message-ID: Date: Mon, 1 Apr 2024 20:52:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20240328012631.777476-1-fei.w.wang@intel.com> From: Mark Thompson In-Reply-To: <20240328012631.777476-1-fei.w.wang@intel.com> Subject: Re: [FFmpeg-devel] [PATCH v1 1/7] lavc/vaapi_dec: Create VA parameters dynamically X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 28/03/2024 01:26, fei.w.wang-at-intel.com@ffmpeg.org wrote: > From: Fei Wang > > Signed-off-by: Fei Wang > --- > libavcodec/vaapi_decode.c | 29 ++++++++++++++++++++++------- > libavcodec/vaapi_decode.h | 7 ++----- > 2 files changed, 24 insertions(+), 12 deletions(-) This is because the VVC code is going to want to make a lot more of these param buffers - can we just set a slightly larger fixed limit? If you always need 20 buffers (say), then this has turned 1 allocation per picture into 3 and used more memory in the non-VVC case as well because of the overhead of that (but if you might variably need up to 200 then this is completely fair). > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c > index cca94b5336..1b1972a2a9 100644 > --- a/libavcodec/vaapi_decode.c > +++ b/libavcodec/vaapi_decode.c > @@ -38,12 +38,23 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx, > { > VAAPIDecodeContext *ctx = avctx->internal->hwaccel_priv_data; > VAStatus vas; > - VABufferID buffer; > > - av_assert0(pic->nb_param_buffers + 1 <= MAX_PARAM_BUFFERS); > + av_assert0(pic->nb_param_buffers <= pic->param_allocated); > + if (pic->nb_param_buffers == pic->param_allocated) { > + pic->param_buffers = > + av_realloc_array(pic->param_buffers, > + pic->param_allocated + 16, > + sizeof(*pic->param_buffers)); Use av_reallocp_array() to avoid leaking the pointer on failure. > + if (!pic->param_buffers) > + return AVERROR(ENOMEM); > + > + pic->param_allocated += 16; > + } > + av_assert0(pic->nb_param_buffers + 1 <= pic->param_allocated); > > vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context, > - type, size, 1, (void*)data, &buffer); > + type, size, 1, (void*)data, > + &pic->param_buffers[pic->nb_param_buffers]); > if (vas != VA_STATUS_SUCCESS) { > av_log(avctx, AV_LOG_ERROR, "Failed to create parameter " > "buffer (type %d): %d (%s).\n", > @@ -51,14 +62,14 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx, > return AVERROR(EIO); > } > > - pic->param_buffers[pic->nb_param_buffers++] = buffer; > - > av_log(avctx, AV_LOG_DEBUG, "Param buffer (type %d, %zu bytes) " > - "is %#x.\n", type, size, buffer); > + "is %#x.\n", type, size, pic->param_buffers[pic->nb_param_buffers]); > + > + ++pic->nb_param_buffers; > + > return 0; > } > > - > int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx, > VAAPIDecodePicture *pic, > const void *params_data, > @@ -215,6 +226,8 @@ fail: > fail_at_end: > exit: > pic->nb_param_buffers = 0; > + pic->param_allocated = 0; > + av_freep(&pic->param_buffers); > pic->nb_slices = 0; > pic->slices_allocated = 0; > av_freep(&pic->slice_buffers); > @@ -228,6 +241,8 @@ int ff_vaapi_decode_cancel(AVCodecContext *avctx, > ff_vaapi_decode_destroy_buffers(avctx, pic); > > pic->nb_param_buffers = 0; > + pic->param_allocated = 0; > + av_freep(&pic->param_buffers); > pic->nb_slices = 0; > pic->slices_allocated = 0; > av_freep(&pic->slice_buffers); > diff --git a/libavcodec/vaapi_decode.h b/libavcodec/vaapi_decode.h > index 6beda14e52..a41d7ff2ff 100644 > --- a/libavcodec/vaapi_decode.h > +++ b/libavcodec/vaapi_decode.h > @@ -32,15 +32,12 @@ static inline VASurfaceID ff_vaapi_get_surface_id(AVFrame *pic) > return (uintptr_t)pic->data[3]; > } > > -enum { > - MAX_PARAM_BUFFERS = 16, > -}; > - > typedef struct VAAPIDecodePicture { > VASurfaceID output_surface; > > int nb_param_buffers; > - VABufferID param_buffers[MAX_PARAM_BUFFERS]; > + VABufferID *param_buffers; Previously the array was zeroed at allocation but now it isn't. Can you confirm that that isn't a problem? > + int param_allocated; Maybe "nb_param_buffers_allocated" would be clearer. > > int nb_slices; > VABufferID *slice_buffers; Thanks, - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".