[meta-freescale] imxipuvideosink in 3.10.53 on Nitrogex6xlite
Gary Thomas
samoht.yrag at gmail.com
Thu May 21 06:53:36 PDT 2015
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 at ossystems.com.br>
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.
>>
>>
>>
>>
>
>
>
More information about the meta-freescale
mailing list