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

[Paul B Mahol]

On 1/22/20, Anton Khirnov <anton at khirnov.net> wrote:
> 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.
>

Are patches now ready for finally being applied to FFmpeg?

Asking because gonna write additional filters for new effects using vulkan.

> --
> Anton Khirnov
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".