iMX6 hardware decode issue on Android

[Eric-BTG]

Hi,

A feedback from my experiments.

So I had 2 possibilities: use imxeglvivsink or use Freescale code path to
glimagesink (or patch myself glupload). I tried both:


*# imxeglvivsink:* I used posted patch. It works but display is not smooth.
CPU is avg 3%. I'm stuck, I don't know where is the bottle neck. I can
provide logs if that helps.

*# Freescale glimagesink patchs:* I tried
"1.4.5-Use-viv-direct-texture-to-bind-buffer.patch" +
"egl-workaround-for-eglCreateContext-isn-t-thread-safe.patch" from Freescale
latest Yocto release.
I can't use it as is because it maps texture from "vpudec" bufs output only
(Freescale's implem only). Mapping is done from memory allocated with
GstAllocatorPhyMem which is part of gst1.0-fsl-plugins. I don't have those
plugins since I use Carlos imxvpudec..


*# Patch glupload in glimagesink:* So I patched glupload (1.4.5) to use
direct Vivante texture binding from imxvpudec's physical buffers. 
(Basically I merged eglvivsink's gles2_renderer with Freescale's patch)

I got physical buffers meta data from GST_IMX_PHYS_MEM_META_GET macro and
used Vivante glTexDirectVIVMap to map incoming buffers to the gl texture.

It works but it is still laggy, (a bit less smooth than imxeglvivsink).


My texture format is I420, could you tell me more about transparent
conversion to RGBA?

Display is laggy but CPU is very low ~3%, do you have a explanation on
what's going on?


I traced eglSwapBuffers execution:
imxeglvivsink: avg 32.5ms, med 30ms
glimagesink: avg 33.9ms, med 30ms

Do you have a experiment to suggest to identify the issue? Any hint is
welcomed :)

Regards,

Eric



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/iMX6-hardware-decode-issue-on-Android-tp4673449p4673691.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.