Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite


Gary Thomas <samoht.yrag@...>
 

On 2015-05-19 09:09, Carlos Rafael Giani wrote:
It is strange that gtk-play isn't picking this one. Anyway, if you explicitely pick it, you should have windowed output.
I tried forcing this via:
gst-launch-1.0 playbin uri=file:///some_file.mp4

It starts up, then fails with:
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
[INFO] Product Info: i.MX6Q/D/S
[INFO] bitstreamMode 1, chromaInterleave 0, mapType 0, tiled2LinearEnable 0
CODEC: BLN_MAD-MMCODECS_AACD_ARM_03.09.00_CORTEX-A8 build on Jun 19 2014 18:30:32.
Attempt to unlock mutex that was not locked

Using GDB, I tracked this down to
#4 0xb685d318 in gst_imx_egl_viv_sink_egl_platform_expose (platform=0xa93ff460)
at ../src/eglvivsink/egl_platform_x11.c:497

The code in question looks pretty simple:
gboolean gst_imx_egl_viv_sink_egl_platform_expose(GstImxEglVivSinkEGLPlatform *platform)
{
EGL_PLATFORM_LOCK(platform);
gst_imx_egl_viv_sink_egl_platform_send_cmd(platform, GSTIMX_EGLX11_CMD_EXPOSE);
EGL_PLATFORM_UNLOCK(platform);
return TRUE;
}

It's failing on the EGL_PLATFORM_UNLOCK() call.

I did have some debug messages show up about this time (many of these):
mxc_vpu 2040000.vpu: VPU interrupt received.
Could this be involved?

Any ideas? I'm running this version of that code:
git log recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb
commit 1e5f8cea6a779c0dc374cdc3a9a6e2d0bdabbd32
Author: Otavio Salvador <otavio@...>
Date: Wed Apr 8 11:39:19 2015 -0300


Am 2015-05-19 um 13:54 schrieb Gary Thomas:
On 2015-05-19 05:23, Carlos Rafael Giani wrote:


Am 2015-05-19 um 13:17 schrieb Gary Thomas:
On 2015-05-19 05:11, Carlos Rafael Giani wrote:

Thanks for the explanation, perhaps it can help someone fix this. My
guess is that the FSL plugin doesn't handle those dynamic elements and
thus is not equipped to set up the render in the appropriate window on
the screen.




Also the full-screen behavior depends the videosink configuration, so
hard to give universal answer, as none will fit all cases.
I doubt that the issue is caused exactly by the GstImxVpuDec or GstOverlaySink, as by looking at your pipeline they seem to have static pads. So it's more of how the
playbin/decodebin bins handle the pipeline creation process...
All I know is that it does work correctly on other platforms, e.g. a
native x86 (intel-corei7-64), as well as when there are no i.MX plugins
installed, so it's definitely tied to the FSL plugin.
The issue here is that the IPU sink does not know anything about windows. It directly overwrites the framebuffer's pixels. One way I am trying out is to create an empty window in
the sink and let the IPU overwrite its pixels, but this is not exactly clean, and can cause artifacts. If you want to render to a window, I recommend using the imxeglvivsink
instead. In fact, this should be the default one. How did you get the plugins?
Nothing special, I simply included gst1.0-fsl-plugin in my image.
I'm building my own X based image, which includes these packages:
gst-player-bin
gstreamer1.0-libav
gst1.0-fsl-plugin
gstreamer1.0-plugins-imx
What do you get when you run "gst-inspect-1.0 imxeglvivsink" ?
Output attached.

Note: based on my capture of the gstreamer info (.dot), that plugin
is not what is being used by gtk-play/gst-play. You can find the .dot
file in a previous reply on this thread (yesterday) or I'll send it
again if you need.




Join meta-freescale@lists.yoctoproject.org to automatically receive all group messages.