Quoting Lynne (2020-02-02 18:23:43) > Jan 22, 2020, 16:44 by an...@khirnov.net: > > > Quoting Lynne (2020-01-21 21:52:52) > > > >> Jan 21, 2020, 18:22 by an...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
