[Bug 760918] omxvideodec : Use gstglmemoryegl for the RPi

[GStreamer (GNOME Bugzilla)]

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

--- Comment #7 from Gwang Yoon Hwang <yoon at igalia.com> ---
(In reply to Nicolas Dufresne (stormer) from comment #6)
> (In reply to Gwang Yoon Hwang from comment #5)
> > (In reply to Nicolas Dufresne (stormer) from comment #4)
> > 
> > Another nice point of this approach is, glupload don't have to create it's
> > buffer pool because it will share same buffer with OMX video decoder.
> > I'm not sure about a way to implement "converting", but it would means we
> > need to make a additional memory to wrap and refs EGLImage, and synchronize
> > its buffer pool with OMX's buffer, isn't it?
> 
> We need buffer pools for the raw upload and dmabuf upload (at least). For
> the OMX case, we don't you are right, we can just pass-through the read-only
> EGLImage binded textures.
> 
> In the original design, the sink was allocation a pool with EGLImage in it.
> This pool was placed in the propose allocation. This way, the omxdecoder
> would know if it should operated in system memory or using EGL acceleration.
> How do you signal this now without an EGL specific caps feature ?

I'm not sure I understand it correctly, but the omxvideodecoder can check the
memory type whether it has an EGL backend or not via:
checking the proposed pool's allocator with GST_IS_GL_MEMORY_EGL_ALLOCATOR or 
checking the memory type via gst_memory_is_type, isn't it enough?

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