Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite

[Carlos Rafael Giani <dv@pseudoterminal.org>]

[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]

Also, when you refer to gtk-play, do you mean libcanberra's gtk play?

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


[-- Attachment #2: Type: text/html, Size: 6200 bytes --]