From: Mark Thompson <sw@jkqxz.net> To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH v1 1/7] lavc/vaapi_dec: Create VA parameters dynamically Date: Mon, 1 Apr 2024 20:52:08 +0100 Message-ID: <e92c1621-6c3b-4c27-85d5-e796cdf21795@jkqxz.net> (raw) In-Reply-To: <20240328012631.777476-1-fei.w.wang@intel.com> On 28/03/2024 01:26, fei.w.wang-at-intel.com@ffmpeg.org wrote: > From: Fei Wang <fei.w.wang@intel.com> > > Signed-off-by: Fei Wang <fei.w.wang@intel.com> > --- > 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".
next prev parent reply other threads:[~2024-04-01 19:51 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-28 1:26 fei.w.wang-at-intel.com 2024-03-28 1:26 ` [FFmpeg-devel] [PATCH v1 2/7] lavc/vvc_refs: Move definition of VVC_FRAME_FLAG* to h header fei.w.wang-at-intel.com 2024-03-28 1:26 ` [FFmpeg-devel] [PATCH v1 3/7] lavc/cbs_h266: Add SliceTopLeftTileIdx to H266RawPPS fei.w.wang-at-intel.com 2024-03-28 1:26 ` [FFmpeg-devel] [PATCH v1 4/7] lavc/cbs_h266: Add NumSlicesInTile " fei.w.wang-at-intel.com 2024-03-28 1:26 ` [FFmpeg-devel] [PATCH v1 5/7] lavc/vvc_ps: Add alf raw syntax into VVCALF fei.w.wang-at-intel.com 2024-03-28 1:26 ` [FFmpeg-devel] [PATCH v1 6/7] lavc/vvc_dec: Add hardware decode API fei.w.wang-at-intel.com 2024-03-28 2:04 ` Andreas Rheinhardt 2024-04-02 6:24 ` Wang, Fei W 2024-03-28 1:26 ` [FFmpeg-devel] [PATCH v1 7/7] lavc/vaapi_dec: Add VVC decoder fei.w.wang-at-intel.com 2024-04-02 12:48 ` Nuo Mi 2024-04-03 3:31 ` Wang, Fei W 2024-04-06 5:03 ` Nuo Mi 2024-04-01 19:52 ` Mark Thompson [this message] 2024-04-02 6:16 ` [FFmpeg-devel] [PATCH v1 1/7] lavc/vaapi_dec: Create VA parameters dynamically Wang, Fei W
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=e92c1621-6c3b-4c27-85d5-e796cdf21795@jkqxz.net \ --to=sw@jkqxz.net \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git