Hi Gary,
On 05/21/2015 05:13 PM, Gary Thomas wrote:
On 2015-05-21 07:53, Gary Thomas wrote:
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
Oops, that should be:
gst-launch-1.0 playbin uri=file:///some_file.mp4
video-sink=imxeglvivsink
I still need to figure out why playbin doesn't chose this element on its
own.
You can see which video-sink element was cherry-picked by playbin and
delete (or move it somewhere, just make sure it's not available as .so
in gstreamer plugins dir).
Now repeat this until playbin doesn't have a choice anymore :D.
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 <[email protected]>
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.
--
_______________________________________________
meta-freescale mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale
