Problem when binding Android Surface to glimagesink

[Sebastian Dröge]

On Di, 2016-09-13 at 04:34 -0700, pedjaman wrote:
> Problem is I'm not sure it is a bug. I believe I'm not using it well and was
> hopping of some direction where to look at :)
> 
> It is the same Surface class like the one used in Player demo in call
> Player.setSurface(). So GStreamer doesn't need separate code.
> I can see that gstreamer internally decode video by using openGL as I can
> see frames in Tracer for openGL ES.
> I also can see some additional context created which is I guess used by
> gstreamer. So it might be something with different contexts affecting this
> for example.

The problem is that the way this works currently, you need a
ANativeWindow backing the Surface that is passed to GstPlayer (or as
the window-handle to glimagesink). Anything else won't work, and AFAIU
you pass something different there (a SurfaceTexture).

The solution to this would be to make an Android specific sink that
directly works with SurfaceTextures, which is not a "bug" but a feature
request... however we track feature requests in Bugzilla too, so
technically it is a "bug" ;)

> Maybe there is a sink which is rendering to opengl texture? That would also
> help.

glimagesink is internally, and you can build something that renders to
a texture with the signals on glimagesink. Nonetheless, a specific sink
that directly works on SurfaceTextures is going to work more reliable
and in the end will be easier.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 967 bytes
Desc: This is a digitally signed message part
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160914/efde8606/attachment.sig>