Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Gary Thomas <gary@mlbassoc.com>]

On 2015-06-02 11:11, Carlos Rafael Giani wrote:
> Also, when you refer to gtk-play, do you mean libcanberra's gtk play?

No, it's a gstreamer-1.0 product.  You get it when you build Yocto (core-image-sato)
from the gst-player recipe.

>
> Am 2015-06-02 um 17:34 schrieb Carlos Rafael Giani:
>> Note that the gst1.0-fsl-plugin are not by me. I wrote gstreamer-imx. gst1.0-fsl-plugin was written by Freescale.
>> I never tried a combination of both. It is possible that this is what is causing your problems. I'll try to replicate that.
>>
>> Am 2015-05-29 um 15:00 schrieb Gary Thomas:
>>> On 2015-05-29 01:25, Carlos Rafael Giani wrote:
>>>> Ah, it is as I suspected. There is a fix for that in gstreamer-imx master (not meta-fsl-arm master).
>>>>
>>>> In the meta-fsl-arm directory, open recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_0.10.1.bb , and replace the line:
>>>>
>>>> SRCREV = "898e51dbdb01926d6423d0d31a9530ec6deb5192"
>>>>
>>>> with:
>>>>
>>>> SRCREV = "50bd7add0b684e966b8a7bdaad47a7e706fc00cc"
>>>>
>>>> then rebuild and reinstall gstreamer-imx, and check if this fixes it.
>>>
>>> This does fix the problem when I run gst-play manually (from the command line), thanks.
>>>
>>> However, I still have no video when gst-play is started from gtk-play
>>> (because playbin is choosing the wrong plugin).  Any ideas about that?
>>>
>>> Finally, there is another problem I've already reported - if you run
>>> gst-play without any specific plugin from the command line, it will
>>> default to a full screen video overlay.  Sadly this fails with the same
>>> error:
>>>   Attempt to unlock mutex that was not locked
>>> This can be fixed using the attached patch (but I'm not sure it's 100% correct)
>>>
>>> The gst1.0-fsl-plugin does not list a maintainer - perhaps it's you (Carlos)?
>>>
>>>>
>>>>
>>>> Am 2015-05-29 um 09:06 schrieb Carlos Rafael Giani:
>>>>> OK, I was able to reproduce this, thanks. Working on it now.
>>>>>
>>>>> Am 2015-05-28 um 14:11 schrieb Gary Thomas:
>>>>>> On 2015-05-28 00:33, Carlos Rafael Giani wrote:
>>>>>>> Interesting. This seems familiar, although I thought it is fixed. I will do a test run here to see if I can reproduce it.
>>>>>>> This happens with gtk-play, right? Please double check if this also happens with gst-play on your end. It would be somewhat easier for me if it is also reproducible with that.
>>>>>>
>>>>>> I'm only using gst-play at the moment (gtk-play doesn't have a way
>>>>>> to force the appropriate videosink yet).  Here's the command I used:
>>>>>>   # GST_DEBUG_NO_COLOR=1 GST_DEBUG='2,*imx*:9' gst-play-1.0 --videosink=imxeglvivsink Vlad\+Louise.mp4 2>/tmp/gst-play.log
>>>>>>
>>>>>>>
>>>>>>> Am 2015-05-27 um 14:05 schrieb Gary Thomas:
>>>>>>>> On 2015-05-26 12:53, Carlos Rafael Giani wrote:
>>>>>>>>> Try to re-run the playbin pipeline with the GST_DEBUG environment variable set to: "2,*imx*:9", and post the log please.
>>>>>>>>
>>>>>>>> Here it is.
>>>>>>>>
>>>>>>>>> Am 2015-05-26 um 16:04 schrieb Gary Thomas:
>>>>>>>>>> On 2015-05-26 07:59, Carlos Rafael Giani wrote:
>>>>>>>>>>> On 05/26/2015 03:50 PM, Gary Thomas wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Any ideas on how to get this to work (i.e. fix the broken locking)?
>>>>>>>>>>>
>>>>>>>>>>> Try if building the current master (not 0.10.1) fixes it.
>>>>>>>>>>
>>>>>>>>>> That's what I'm running:
>>>>>>>>>>   meta-fsl-arm: f52c9106689f33c78b09496f4929ae1e87d13970
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

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