GNOME Bugzilla – Bug 769436
vaapi: [RFC] remove memory:VASurface caps feature
Last modified: 2018-11-03 15:48:08 UTC
This is an idea: what if we get rid of the memory:VASurface caps feature? The purpose of the caps feature is to restrict the type of caps the element can process. But vaapi element can process as input two types of caps: system memory and GstVaapiVideoMemory. As output, three: system memory, GL texture upload and vaapi memory. Do we need to annotate the vaapi memory? I think we do not need it, since vaapi surfaces can be mapped onto images (not completely, but almost). Opinions?
Created attachment 332565 [details] [review] remove memory:VASurface feature
(In reply to Víctor Manuel Jáquez Leal from comment #0) > Do we need to annotate the vaapi memory? > > I think we do not need it, since vaapi surfaces can be mapped onto images > (not completely, but almost). > I agree with this. IMHO, this change makes vaapi elements flexible during negotiation. and makes source code for negotiation more simple. Probably, this can fix #772457 and this kind of issues also.
In theory, VASurface can be an encrypted (drm protected) too where there is no download possible. How do we support this? may be just mark it as non-mappable memory? But keep in mind that we don't even know the pixel format of these type buffers.
If it's not mappable and can only be used from other Vaapi elements, would it make sense to make it a different caps, like video/x-vaapi-drm or somethign like that?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer-vaapi/issues/42.