[Bug 760918] omxvideodec : Use gstglmemoryegl for the RPi

[GStreamer (GNOME Bugzilla)]

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

Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.dufresne at collabora.
                   |                            |co.uk

--- Comment #6 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Gwang Yoon Hwang from comment #5)
> (In reply to Nicolas Dufresne (stormer) from comment #4)
> > Review of attachment 319477 [details] [review] [review]:
> > 
> > Don't we need to keep a different caps feature to make this work ? glupload
> > can then convert to GLMemory afterward.
> 
> In ideal case, What I want to do is enabling passthrough at the glupload in
> this use case.
> 
> Before this patch, glupload allocates additional GLMemory which has a
> gltexture,
> which is already created by EGLImageMemory.
> It is a waste of memory and memory bandwidth.

Totally agree, it's not just a waste, it also kills the performance.

> 
> 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 ?

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