[Bug 776927] [PATCH] Accept GLMemory buffers

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=776927

Hyunjun Ko <zzoon at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zzoon at igalia.com

--- Comment #1 from Hyunjun Ko <zzoon at igalia.com> ---
(In reply to Matt Fischer from comment #0)
Hi again. :)

First of all, could you upload the patch again with content-type as "patch"
so that we could see it directly.

> 1. I've had to force the chroma_type to GST_VAAPI_CHROMA_TYPE_YUV420, since
> the video format is of type RGBA and that is not supported by the display. 
> Curiously, however, the colors in the encoded video come out correctly.  It
> looks to me like the chroma type on the surface must be getting used, which
> makes me wonder why we need to bother setting the chroma type on the display
> at all.  I tried removing the VAConfigAttribRTFormat attribute completely in
> config_create() when making the context, and things still seemed to work
> properly.  What is the correct way to handle this case?

Supported format might be different depends on chipset. That's why we need to
find out what formats are supported on the current chipset.
But in this case, I don't know how to handle this case.

> 2. The key mechanism here in transferring a texture into a surface is the
> ability to go Texture -> EGLImage -> DRM handle -> Surface.  All of the
> components of this path already existed in the codebase, so it was
> relatively straightforward to do, however this obviously doesn't work on
> non-EGL platforms.  I don't know enough about GLX to know whether there is
> some equivalent that could be done there.  For the moment, I've set it up so
> that if the texture cannot be converted to a surface, it fails gracefully
> and allows a software download to take place.  This works, but it would be
> better if a mechanism could be implemented to do this on GLX.  Does anybody
> know if that can be done?

I beleive it can be done, but IMHO, it's not necessary.

> 3. In order to create a display which is GL-capable, I added use of
> gst_gl_ensure_element_data()/gst_gl_handle_set_context(), so that the plugin
> works the same way that other GL plugins do.  However, I think this steps a
> bit on the code which already existed in
> gst_vaapi_plugin_base_decide_allocation(), which tried to pull a context out
> of the GLTextureUploadMeta.  Could this code simply be deleted now that the
> plugin does a full context query?

As I said in the mailing list, if your plugin pass gl context via context
query, it should be fine. Because vaapi plugin will create proper display if it
got it via gst_vaapi_plugin_base_find_gl_context.

Here is my test pipeline to test.
GST_GL_PLATFORM=egl gst-launch-1.0 gltestsrc ! vaapih264enc ! vaapih264dec !
glimagesink

I have to use glimagesink to get gl context from it and see what's working.
(There's some hack in vaapih264dec to get gl context)
I guess your own upstream plugin creates gl context, which means you can pass
it.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.