[meta-freescale] imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas]

On 2015-05-21 08:52, Gary Thomas wrote:
> On 2015-05-21 08:46, Carlos Rafael Giani wrote:
>> Are you starting this from SSH or minicom? If so, make sure you call this first:
>>
>> export DISPLAY=:0
>>
>> Otherwise, it will not be able to connect to the X display. This might explain why the eglvivsink wasn't being picked.
>> As for the double mutex unlock, this might already have a fix. I'll check.
>
> Yes, I have DISPLAY set.  playbin without any video-sink option works
> fine to my device, but it goes in an overlay (whole screen).  I'm trying
> to investigate how to make it work correctly when rendered into a window,
> e.g. called from gtk-play/gst-play
>
>>
>>
>> On 05/21/2015 03:53 PM, 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
>>>
>>> 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
>>>

Any ideas on how to get this to work (i.e. fix the broken locking)?

>>>
>>>> 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.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------