[meta-freescale] imxipuvideosink in 3.10.53 on Nitrogex6xlite

Carlos Rafael Giani dv at pseudoterminal.org
Tue Jun 2 14:05:27 PDT 2015


Alright, two things:

1) I just made a 0.10.2 release. I'll soon push an update for the 
meta-fsl recipe. This release includes the eglvivsink mutex fix.

2) I replicated your problem. If both gstreamer-imx and 
gst1.0-fsl-plugin are installed, this error occurs. If only 
gstreamer-imx is installed, playback works just fine - eglvivsink is 
used automatically as the video sink. I'll investigate what 
gst1.0-fsl-plugin is doing to override eglvivsink.


Am 2015-06-02 um 19:16 schrieb Gary Thomas:
> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>



More information about the meta-freescale mailing list