[FFmpeg-devel] [PATCH] Vulkan hwcontext and filters

Anton Khirnov anton at khirnov.net
Wed Feb 5 00:17:48 EET 2020


Quoting Lynne (2020-02-02 18:23:43)
> Jan 22, 2020, 16:44 by anton at khirnov.net:
> 
> > Quoting Lynne (2020-01-21 21:52:52)
> >
> >> Jan 21, 2020, 18:22 by anton at khirnov.net:
> >> >> Its size too? Didn't know that.
> >> >> I do think its a good idea to be able to append fields to it, so I've
> >> >> added a av_vk_frame_alloc() function. I've followed what
> >> >> av_frame_alloc is called, though I'm not sure if its too close to that
> >> >> one's name.
> >> >>
> >> >
> >> > My original intent with this API was that calles are allowed to provide
> >> > their own pools. Not sure if that's still allowed or works though. But
> >> > if it is, the caller needs to be able to allocate/free AVkFrame.
> >> >
> >>
> >> They are of course. The first wip of the cuda interop exploited that IIRC.
> >> But I think the issue is that in order for API users to make their own
> >> pools they need to know the size in bytes of AVVkFrame since that's
> >> what av_buffer_create() accepts.
> >> I could make a function to return that, but I'm wondering if its
> >> somewhat too big of a mess already.
> >> I could instead reserve some memory in the struct, a few hundred bytes
> >> would be enough since every Vulkan object has to be allocated on heap.
> >>
> >
> > The requirement for av_buffer_create() is just formal here, we shouldn't
> > let it guide our API design (ideally we'd make a standalone refcount
> > type and stop abusing AVBuffer for it). You can just pass sizeof(void*)
> > to it. Or make av_vk_frame_alloc() write sizeof(AVVkFrame) into a
> > supplied pointer, if you want to be really proper about it.
> >
> 
> So is the API good now?

Mention how it's to be freed in the doxy, otherwise ok.

-- 
Anton Khirnov


More information about the ffmpeg-devel mailing list