Fido with kernel 3.10.17

Fido with kernel 3.10.17

[Nikolay Dimitrov]

Hi guys,

I'm updating an imx6d-based project from Dizzy to Fido. I use all Fido
components without changes, a customized u-boot 2014.07 and kernel FSL
3.10.17. My Fido build boots OK, but Xorg segfaults.

Which leads to my question - is the latest Vivante GPU code compatible
with 3.10.17 or I'll have to move to 3.14.28?

Thanks in advance. Regards,
Nikolay

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-07 08:23, Nikolay Dimitrov wrote:
> Hi guys,
>
> I'm updating an imx6d-based project from Dizzy to Fido. I use all Fido
> components without changes, a customized u-boot 2014.07 and kernel FSL
> 3.10.17. My Fido build boots OK, but Xorg segfaults.
>
> Which leads to my question - is the latest Vivante GPU code compatible
> with 3.10.17 or I'll have to move to 3.14.28?

or 3.10.53

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

Re: Fido with kernel 3.10.17

[Nikolay Dimitrov]

Hi Gary,

On 05/07/2015 05:27 PM, Gary Thomas wrote:
> On 2015-05-07 08:23, Nikolay Dimitrov wrote:
>> Hi guys,
>>
>> I'm updating an imx6d-based project from Dizzy to Fido. I use all
>> Fido components without changes, a customized u-boot 2014.07 and
>> kernel FSL 3.10.17. My Fido build boots OK, but Xorg segfaults.
>>
>> Which leads to my question - is the latest Vivante GPU code
>> compatible with 3.10.17 or I'll have to move to 3.14.28?
>
> or 3.10.53

Do you have kernel 3.10.53 working on Fido with Xorg?

Regards,
Nikolay

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-07 09:24, Nikolay Dimitrov wrote:
> Hi Gary,
>
> On 05/07/2015 05:27 PM, Gary Thomas wrote:
>> On 2015-05-07 08:23, Nikolay Dimitrov wrote:
>>> Hi guys,
>>>
>>> I'm updating an imx6d-based project from Dizzy to Fido. I use all
>>> Fido components without changes, a customized u-boot 2014.07 and
>>> kernel FSL 3.10.17. My Fido build boots OK, but Xorg segfaults.
>>>
>>> Which leads to my question - is the latest Vivante GPU code
>>> compatible with 3.10.17 or I'll have to move to 3.14.28?
>>
>> or 3.10.53
>
> Do you have kernel 3.10.53 working on Fido with Xorg?

Yes, many boards such as the ones from Boundary Devices (in
meta-fsl-arm-extra) use this kernel (plus their own enhancements).

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

Re: Fido with kernel 3.10.17

[Nikolay Dimitrov]

On 05/07/2015 06:29 PM, Gary Thomas wrote:
> On 2015-05-07 09:24, Nikolay Dimitrov wrote:
>> Hi Gary,
>>
>> On 05/07/2015 05:27 PM, Gary Thomas wrote:
>>> On 2015-05-07 08:23, Nikolay Dimitrov wrote:
>>>> Hi guys,
>>>>
>>>> I'm updating an imx6d-based project from Dizzy to Fido. I use
>>>> all Fido components without changes, a customized u-boot
>>>> 2014.07 and kernel FSL 3.10.17. My Fido build boots OK, but
>>>> Xorg segfaults.
>>>>
>>>> Which leads to my question - is the latest Vivante GPU code
>>>> compatible with 3.10.17 or I'll have to move to 3.14.28?
>>>
>>> or 3.10.53
>>
>> Do you have kernel 3.10.53 working on Fido with Xorg?
>
> Yes, many boards such as the ones from Boundary Devices (in
> meta-fsl-arm-extra) use this kernel (plus their own enhancements).

OK, thanks!

Regards,
Nikolay

Re: Fido with kernel 3.10.17

[Nikolay Dimitrov]

Hi guys,

On 05/07/2015 06:39 PM, Nikolay Dimitrov wrote:
> On 05/07/2015 06:29 PM, Gary Thomas wrote:
>> On 2015-05-07 09:24, Nikolay Dimitrov wrote:
>>> Hi Gary,
>>>
>>> On 05/07/2015 05:27 PM, Gary Thomas wrote:
>>>> On 2015-05-07 08:23, Nikolay Dimitrov wrote:
>>>>> Hi guys,
>>>>>
>>>>> I'm updating an imx6d-based project from Dizzy to Fido. I
>>>>> use all Fido components without changes, a customized u-boot
>>>>> 2014.07 and kernel FSL 3.10.17. My Fido build boots OK, but
>>>>> Xorg segfaults.
>>>>>
>>>>> Which leads to my question - is the latest Vivante GPU code
>>>>> compatible with 3.10.17 or I'll have to move to 3.14.28?
>>>>
>>>> or 3.10.53
>>>
>>> Do you have kernel 3.10.53 working on Fido with Xorg?
>>
>> Yes, many boards such as the ones from Boundary Devices (in
>> meta-fsl-arm-extra) use this kernel (plus their own enhancements).
>
> OK, thanks!

Just wanted to follow-up on this issue - after updating the kernel to
3.10.53 and rebuilding the product image, Xorg no longer crashes and
works fine. Thanks to everyone who helped!

Regards,
Nikolay

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-12 05:34, Nikolay Dimitrov wrote:
> Hi guys,
>
> On 05/07/2015 06:39 PM, Nikolay Dimitrov wrote:
>> On 05/07/2015 06:29 PM, Gary Thomas wrote:
>>> On 2015-05-07 09:24, Nikolay Dimitrov wrote:
>>>> Hi Gary,
>>>>
>>>> On 05/07/2015 05:27 PM, Gary Thomas wrote:
>>>>> On 2015-05-07 08:23, Nikolay Dimitrov wrote:
>>>>>> Hi guys,
>>>>>>
>>>>>> I'm updating an imx6d-based project from Dizzy to Fido. I
>>>>>> use all Fido components without changes, a customized u-boot
>>>>>> 2014.07 and kernel FSL 3.10.17. My Fido build boots OK, but
>>>>>> Xorg segfaults.
>>>>>>
>>>>>> Which leads to my question - is the latest Vivante GPU code
>>>>>> compatible with 3.10.17 or I'll have to move to 3.14.28?
>>>>>
>>>>> or 3.10.53
>>>>
>>>> Do you have kernel 3.10.53 working on Fido with Xorg?
>>>
>>> Yes, many boards such as the ones from Boundary Devices (in
>>> meta-fsl-arm-extra) use this kernel (plus their own enhancements).
>>
>> OK, thanks!
>
> Just wanted to follow-up on this issue - after updating the kernel to
> 3.10.53 and rebuilding the product image, Xorg no longer crashes and
> works fine. Thanks to everyone who helped!

Does chrome work correctly?  What about the gstreamer-1.0 based
media player?

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

Re: Fido with kernel 3.10.17

[Nikolay Dimitrov]

Hi Gary,

On 05/12/2015 02:48 PM, Gary Thomas wrote:
> On 2015-05-12 05:34, Nikolay Dimitrov wrote:
>> Hi guys,
>>
>> On 05/07/2015 06:39 PM, Nikolay Dimitrov wrote:
>>> On 05/07/2015 06:29 PM, Gary Thomas wrote:
>>>> On 2015-05-07 09:24, Nikolay Dimitrov wrote:
>>>>> Hi Gary,
>>>>>
>>>>> On 05/07/2015 05:27 PM, Gary Thomas wrote:
>>>>>> On 2015-05-07 08:23, Nikolay Dimitrov wrote:
>>>>>>> Hi guys,
>>>>>>>
>>>>>>> I'm updating an imx6d-based project from Dizzy to Fido.
>>>>>>> I use all Fido components without changes, a customized
>>>>>>> u-boot 2014.07 and kernel FSL 3.10.17. My Fido build
>>>>>>> boots OK, but Xorg segfaults.
>>>>>>>
>>>>>>> Which leads to my question - is the latest Vivante GPU
>>>>>>> code compatible with 3.10.17 or I'll have to move to
>>>>>>> 3.14.28?
>>>>>>
>>>>>> or 3.10.53
>>>>>
>>>>> Do you have kernel 3.10.53 working on Fido with Xorg?
>>>>
>>>> Yes, many boards such as the ones from Boundary Devices (in
>>>> meta-fsl-arm-extra) use this kernel (plus their own
>>>> enhancements).
>>>
>>> OK, thanks!
>>
>> Just wanted to follow-up on this issue - after updating the kernel
>>  to 3.10.53 and rebuilding the product image, Xorg no longer
>> crashes and works fine. Thanks to everyone who helped!
>
> Does chrome work correctly?  What about the gstreamer-1.0 based media
> player?

Right now Chromium doesn't start at all (and I'm looking into it).

Gstreamer-1.0 freezes instantly with my test video streams. As I've
invested some time in the past to really force gstreamer-0.10 to work,
I'm quite reluctant to go forward with gstreamer-1.0, especially when
its MPEGTS implementation is, well... half-working. So I'm sticking with
what I've made to work so far.

Regards,
Nikolay

PS: I'm dreaming for the day when I can ditch gstreamer and start using
VLC with imx VPU...

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-12 06:27, Nikolay Dimitrov wrote:
> Hi Gary,
>
> On 05/12/2015 02:48 PM, Gary Thomas wrote:
>> On 2015-05-12 05:34, Nikolay Dimitrov wrote:
>>> Hi guys,
>>>
>>> On 05/07/2015 06:39 PM, Nikolay Dimitrov wrote:
>>>> On 05/07/2015 06:29 PM, Gary Thomas wrote:
>>>>> On 2015-05-07 09:24, Nikolay Dimitrov wrote:
>>>>>> Hi Gary,
>>>>>>
>>>>>> On 05/07/2015 05:27 PM, Gary Thomas wrote:
>>>>>>> On 2015-05-07 08:23, Nikolay Dimitrov wrote:
>>>>>>>> Hi guys,
>>>>>>>>
>>>>>>>> I'm updating an imx6d-based project from Dizzy to Fido.
>>>>>>>> I use all Fido components without changes, a customized
>>>>>>>> u-boot 2014.07 and kernel FSL 3.10.17. My Fido build
>>>>>>>> boots OK, but Xorg segfaults.
>>>>>>>>
>>>>>>>> Which leads to my question - is the latest Vivante GPU
>>>>>>>> code compatible with 3.10.17 or I'll have to move to
>>>>>>>> 3.14.28?
>>>>>>>
>>>>>>> or 3.10.53
>>>>>>
>>>>>> Do you have kernel 3.10.53 working on Fido with Xorg?
>>>>>
>>>>> Yes, many boards such as the ones from Boundary Devices (in
>>>>> meta-fsl-arm-extra) use this kernel (plus their own
>>>>> enhancements).
>>>>
>>>> OK, thanks!
>>>
>>> Just wanted to follow-up on this issue - after updating the kernel
>>>  to 3.10.53 and rebuilding the product image, Xorg no longer
>>> crashes and works fine. Thanks to everyone who helped!
>>
>> Does chrome work correctly?  What about the gstreamer-1.0 based media
>> player?
>
> Right now Chromium doesn't start at all (and I'm looking into it).
>
> Gstreamer-1.0 freezes instantly with my test video streams. As I've
> invested some time in the past to really force gstreamer-0.10 to work,
> I'm quite reluctant to go forward with gstreamer-1.0, especially when
> its MPEGTS implementation is, well... half-working. So I'm sticking with
> what I've made to work so far.

I'm glad that your experience, albeit not pleasant, matches mine on this
hardware - I thought I might be missing something.

>
> Regards,
> Nikolay
>
> PS: I'm dreaming for the day when I can ditch gstreamer and start using
> VLC with imx VPU...

Probably still some time from now - I built VLC and it doesn't
work any better (i.e. at all) on the i.MX6.  At least mplayer
does work, even if it's not accelerated "out of the box"

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

Re: Fido with kernel 3.10.17

[Otavio Salvador]

On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> Gstreamer-1.0 freezes instantly with my test video streams. As I've
> invested some time in the past to really force gstreamer-0.10 to work,
> I'm quite reluctant to go forward with gstreamer-1.0, especially when
> its MPEGTS implementation is, well... half-working. So I'm sticking with
> what I've made to work so far.

Did you try the community plugin? We have been using it with several
customers and in general it is working very well.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-12 06:43, Otavio Salvador wrote:
> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> Gstreamer-1.0 freezes instantly with my test video streams. As I've
>> invested some time in the past to really force gstreamer-0.10 to work,
>> I'm quite reluctant to go forward with gstreamer-1.0, especially when
>> its MPEGTS implementation is, well... half-working. So I'm sticking with
>> what I've made to work so far.
>
> Did you try the community plugin? We have been using it with several
> customers and in general it is working very well.
>

Is that not what you would get when running the media player?

Do you have an example pipeline that does work, e.g. play a
complete movie (H264+mp3) in .mp4 container?

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

Re: Fido with kernel 3.10.17

[Otavio Salvador]

On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2015-05-12 06:43, Otavio Salvador wrote:
>>
>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg>
>> wrote:
>>>
>>> Gstreamer-1.0 freezes instantly with my test video streams. As I've
>>> invested some time in the past to really force gstreamer-0.10 to work,
>>> I'm quite reluctant to go forward with gstreamer-1.0, especially when
>>> its MPEGTS implementation is, well... half-working. So I'm sticking with
>>> what I've made to work so far.
>>
>>
>> Did you try the community plugin? We have been using it with several
>> customers and in general it is working very well.
>>
>
> Is that not what you would get when running the media player?
>
> Do you have an example pipeline that does work, e.g. play a
> complete movie (H264+mp3) in .mp4 container?

gst-play-1.0 works.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-12 06:48, Otavio Salvador wrote:
> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>
>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>> wrote:
>>>>
>>>> Gstreamer-1.0 freezes instantly with my test video streams. As I've
>>>> invested some time in the past to really force gstreamer-0.10 to work,
>>>> I'm quite reluctant to go forward with gstreamer-1.0, especially when
>>>> its MPEGTS implementation is, well... half-working. So I'm sticking with
>>>> what I've made to work so far.
>>>
>>>
>>> Did you try the community plugin? We have been using it with several
>>> customers and in general it is working very well.
>>>
>>
>> Is that not what you would get when running the media player?
>>
>> Do you have an example pipeline that does work, e.g. play a
>> complete movie (H264+mp3) in .mp4 container?
>
> gst-play-1.0 works.
>

Not for me on either of the i.MX6 boards I have here :-(  What board(s)
[and kernel] have you tested with?

What did you play?  What is your display device?  Anything else
you can provide that might help me figure this out...

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

Re: Fido with kernel 3.10.17

[Otavio Salvador]

On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2015-05-12 06:48, Otavio Salvador wrote:
>>
>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>
>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>
>>>>
>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>>> wrote:
>>>>>
>>>>>
>>>>> Gstreamer-1.0 freezes instantly with my test video streams. As I've
>>>>> invested some time in the past to really force gstreamer-0.10 to work,
>>>>> I'm quite reluctant to go forward with gstreamer-1.0, especially when
>>>>> its MPEGTS implementation is, well... half-working. So I'm sticking
>>>>> with
>>>>> what I've made to work so far.
>>>>
>>>>
>>>>
>>>> Did you try the community plugin? We have been using it with several
>>>> customers and in general it is working very well.
>>>>
>>>
>>> Is that not what you would get when running the media player?
>>>
>>> Do you have an example pipeline that does work, e.g. play a
>>> complete movie (H264+mp3) in .mp4 container?
>>
>>
>> gst-play-1.0 works.
>>
>
> Not for me on either of the i.MX6 boards I have here :-(  What board(s)
> [and kernel] have you tested with?
>
> What did you play?  What is your display device?  Anything else
> you can provide that might help me figure this out...

Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
many movies.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Fido with kernel 3.10.17

[Nikolay Dimitrov]

Hi Otavio,

On 05/12/2015 03:59 PM, Otavio Salvador wrote:
> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com>
> wrote:
>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>
>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com>
>>>  wrote:
>>>>
>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>
>>>>>
>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov
>>>>> <picmaster@mail.bg> wrote:
>>>>>>
>>>>>>
>>>>>> Gstreamer-1.0 freezes instantly with my test video streams.
>>>>>> As I've invested some time in the past to really force
>>>>>> gstreamer-0.10 to work, I'm quite reluctant to go forward
>>>>>> with gstreamer-1.0, especially when its MPEGTS
>>>>>> implementation is, well... half-working. So I'm sticking
>>>>>> with what I've made to work so far.
>>>>>
>>>>>
>>>>>
>>>>> Did you try the community plugin? We have been using it with
>>>>>  several customers and in general it is working very well.
>>>>>
>>>>
>>>> Is that not what you would get when running the media player?
>>>>
>>>> Do you have an example pipeline that does work, e.g. play a
>>>> complete movie (H264+mp3) in .mp4 container?
>>>
>>>
>>> gst-play-1.0 works.
>>>
>>
>> Not for me on either of the i.MX6 boards I have here :-(  What
>> board(s) [and kernel] have you tested with?
>>
>> What did you play?  What is your display device?  Anything else you
>> can provide that might help me figure this out...
>
> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
> many movies.

That's correct. I usually make smoke test with the Sintel trailers and
it works fine here.

Unfortunately, stock gst-1.0 and gst-0.10 doesn't work with the DVB-S
stream dumps I made from my customer's infrastructure, and this is what
counts in my specific context.

Regards,
Nikolay

Re: Fido with kernel 3.10.17

[Otavio Salvador]

On Tue, May 12, 2015 at 10:12 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> On 05/12/2015 03:59 PM, Otavio Salvador wrote:
>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
>> many movies.
>
> That's correct. I usually make smoke test with the Sintel trailers and
> it works fine here.
>
> Unfortunately, stock gst-1.0 and gst-0.10 doesn't work with the DVB-S
> stream dumps I made from my customer's infrastructure, and this is what
> counts in my specific context.

So this needs investigation. You can report the issue and provide a
test content in the GitHub project. Someone might be able to help on
this specific case.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Fido with kernel 3.10.17

[Nikolay Dimitrov]

Hi Otavio,

On 05/12/2015 04:14 PM, Otavio Salvador wrote:
> On Tue, May 12, 2015 at 10:12 AM, Nikolay Dimitrov
> <picmaster@mail.bg> wrote:
>> On 05/12/2015 03:59 PM, Otavio Salvador wrote:
>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works
>>> for many movies.
>>
>> That's correct. I usually make smoke test with the Sintel trailers
>> and it works fine here.
>>
>> Unfortunately, stock gst-1.0 and gst-0.10 doesn't work with the
>> DVB-S stream dumps I made from my customer's infrastructure, and
>> this is what counts in my specific context.
>
> So this needs investigation. You can report the issue and provide a
> test content in the GitHub project. Someone might be able to help on
> this specific case.

I've already done this for gstreamer-0.10. I also have working ugly
patches that partially fix some of the issues and work-around the
others, but I don't expect everyone to fall in love with the stuff I had
to do to make things working.

Kind regards,
Nikolay

Re: Fido with kernel 3.10.17

[Otavio Salvador]

On Tue, May 12, 2015 at 10:34 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
> On 05/12/2015 04:14 PM, Otavio Salvador wrote:
>>
>> On Tue, May 12, 2015 at 10:12 AM, Nikolay Dimitrov
>> <picmaster@mail.bg> wrote:
>>>
>>> On 05/12/2015 03:59 PM, Otavio Salvador wrote:
>>>>
>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works
>>>> for many movies.
>>>
>>>
>>> That's correct. I usually make smoke test with the Sintel trailers
>>> and it works fine here.
>>>
>>> Unfortunately, stock gst-1.0 and gst-0.10 doesn't work with the
>>> DVB-S stream dumps I made from my customer's infrastructure, and
>>> this is what counts in my specific context.
>>
>>
>> So this needs investigation. You can report the issue and provide a
>> test content in the GitHub project. Someone might be able to help on
>> this specific case.
>
>
> I've already done this for gstreamer-0.10. I also have working ugly
> patches that partially fix some of the issues and work-around the
> others, but I don't expect everyone to fall in love with the stuff I had
> to do to make things working.

I am referring to here:

https://github.com/Freescale/gstreamer-imx

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Gstreamer issues on Fido (was: Fido with kernel 3.10.17)

[Nikolay Dimitrov]

Hi Otavio,

On 05/12/2015 05:43 PM, Otavio Salvador wrote:
> On Tue, May 12, 2015 at 10:34 AM, Nikolay Dimitrov <picmaster@mail.bg> wrote:
>> On 05/12/2015 04:14 PM, Otavio Salvador wrote:
>>>
>>> On Tue, May 12, 2015 at 10:12 AM, Nikolay Dimitrov
>>> <picmaster@mail.bg> wrote:
>>>>
>>>> On 05/12/2015 03:59 PM, Otavio Salvador wrote:
>>>>>
>>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works
>>>>> for many movies.
>>>>
>>>>
>>>> That's correct. I usually make smoke test with the Sintel trailers
>>>> and it works fine here.
>>>>
>>>> Unfortunately, stock gst-1.0 and gst-0.10 doesn't work with the
>>>> DVB-S stream dumps I made from my customer's infrastructure, and
>>>> this is what counts in my specific context.
>>>
>>>
>>> So this needs investigation. You can report the issue and provide a
>>> test content in the GitHub project. Someone might be able to help on
>>> this specific case.
>>
>>
>> I've already done this for gstreamer-0.10. I also have working ugly
>> patches that partially fix some of the issues and work-around the
>> others, but I don't expect everyone to fall in love with the stuff I had
>> to do to make things working.
>
> I am referring to here:
>
> https://github.com/Freescale/gstreamer-imx

Thanks for pointing this. I need to double-check which exact plugins
I've used during my tests.

Regards,
Nikolay

PS: Carlos have done an impressive work on the imx plugins!

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-12 07:12, Nikolay Dimitrov wrote:
> Hi Otavio,
>
> On 05/12/2015 03:59 PM, Otavio Salvador wrote:
>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com>
>> wrote:
>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>
>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com>
>>>>  wrote:
>>>>>
>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov
>>>>>> <picmaster@mail.bg> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Gstreamer-1.0 freezes instantly with my test video streams.
>>>>>>> As I've invested some time in the past to really force
>>>>>>> gstreamer-0.10 to work, I'm quite reluctant to go forward
>>>>>>> with gstreamer-1.0, especially when its MPEGTS
>>>>>>> implementation is, well... half-working. So I'm sticking
>>>>>>> with what I've made to work so far.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Did you try the community plugin? We have been using it with
>>>>>>  several customers and in general it is working very well.
>>>>>>
>>>>>
>>>>> Is that not what you would get when running the media player?
>>>>>
>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>
>>>>
>>>> gst-play-1.0 works.
>>>>
>>>
>>> Not for me on either of the i.MX6 boards I have here :-(  What
>>> board(s) [and kernel] have you tested with?
>>>
>>> What did you play?  What is your display device?  Anything else you
>>> can provide that might help me figure this out...
>>
>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
>> many movies.
>
> That's correct. I usually make smoke test with the Sintel trailers and
> it works fine here.

What package includes these?  Or [exactly] what file(s) do you use?

I'd like to try to duplicate what you are using explicitly.

Thanks

>
> Unfortunately, stock gst-1.0 and gst-0.10 doesn't work with the DVB-S
> stream dumps I made from my customer's infrastructure, and this is what
> counts in my specific context.

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

Re: Fido with kernel 3.10.17

[Nikolay Dimitrov]

Ho Gary,

On 05/12/2015 04:18 PM, Gary Thomas wrote:
> On 2015-05-12 07:12, Nikolay Dimitrov wrote:
>> Hi Otavio,
>>
>> On 05/12/2015 03:59 PM, Otavio Salvador wrote:
>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com>
>>> wrote:
>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>
>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas
>>>>> <gary@mlbassoc.com> wrote:
>>>>>>
>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov
>>>>>>> <picmaster@mail.bg> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> Gstreamer-1.0 freezes instantly with my test video
>>>>>>>> streams. As I've invested some time in the past to
>>>>>>>> really force gstreamer-0.10 to work, I'm quite
>>>>>>>> reluctant to go forward with gstreamer-1.0, especially
>>>>>>>> when its MPEGTS implementation is, well...
>>>>>>>> half-working. So I'm sticking with what I've made to
>>>>>>>> work so far.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Did you try the community plugin? We have been using it
>>>>>>> with several customers and in general it is working very
>>>>>>> well.
>>>>>>>
>>>>>>
>>>>>> Is that not what you would get when running the media
>>>>>> player?
>>>>>>
>>>>>> Do you have an example pipeline that does work, e.g. play
>>>>>> a complete movie (H264+mp3) in .mp4 container?
>>>>>
>>>>>
>>>>> gst-play-1.0 works.
>>>>>
>>>>
>>>> Not for me on either of the i.MX6 boards I have here :-(  What
>>>> board(s) [and kernel] have you tested with?
>>>>
>>>> What did you play?  What is your display device?  Anything else
>>>> you can provide that might help me figure this out...
>>>
>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works
>>> for many movies.
>>
>> That's correct. I usually make smoke test with the Sintel trailers
>> and it works fine here.
>
> What package includes these?  Or [exactly] what file(s) do you use?

Please check here: https://download.blender.org/durian/trailer/

These are my 3 favorite files for testing, they usually work fine
unless I've totally screwed up something:

https://download.blender.org/durian/trailer/sintel_trailer-480p.mp4
https://download.blender.org/durian/trailer/sintel_trailer-720p.mp4
https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4

> I'd like to try to duplicate what you are using explicitly.

I can also send you my test mpegts files, so you can see gstreamer in
its full glory.

>
> Thanks
>
>>
>> Unfortunately, stock gst-1.0 and gst-0.10 doesn't work with the
>> DVB-S stream dumps I made from my customer's infrastructure, and
>> this is what counts in my specific context.
>

Regards,
Nikolay

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-12 07:24, Nikolay Dimitrov wrote:
> Ho Gary,
>
> On 05/12/2015 04:18 PM, Gary Thomas wrote:
>> On 2015-05-12 07:12, Nikolay Dimitrov wrote:
>>> Hi Otavio,
>>>
>>> On 05/12/2015 03:59 PM, Otavio Salvador wrote:
>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com>
>>>> wrote:
>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>
>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas
>>>>>> <gary@mlbassoc.com> wrote:
>>>>>>>
>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov
>>>>>>>> <picmaster@mail.bg> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Gstreamer-1.0 freezes instantly with my test video
>>>>>>>>> streams. As I've invested some time in the past to
>>>>>>>>> really force gstreamer-0.10 to work, I'm quite
>>>>>>>>> reluctant to go forward with gstreamer-1.0, especially
>>>>>>>>> when its MPEGTS implementation is, well...
>>>>>>>>> half-working. So I'm sticking with what I've made to
>>>>>>>>> work so far.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Did you try the community plugin? We have been using it
>>>>>>>> with several customers and in general it is working very
>>>>>>>> well.
>>>>>>>>
>>>>>>>
>>>>>>> Is that not what you would get when running the media
>>>>>>> player?
>>>>>>>
>>>>>>> Do you have an example pipeline that does work, e.g. play
>>>>>>> a complete movie (H264+mp3) in .mp4 container?
>>>>>>
>>>>>>
>>>>>> gst-play-1.0 works.
>>>>>>
>>>>>
>>>>> Not for me on either of the i.MX6 boards I have here :-(  What
>>>>> board(s) [and kernel] have you tested with?
>>>>>
>>>>> What did you play?  What is your display device?  Anything else
>>>>> you can provide that might help me figure this out...
>>>>
>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works
>>>> for many movies.
>>>
>>> That's correct. I usually make smoke test with the Sintel trailers
>>> and it works fine here.
>>
>> What package includes these?  Or [exactly] what file(s) do you use?
>
> Please check here: https://download.blender.org/durian/trailer/
>
> These are my 3 favorite files for testing, they usually work fine
> unless I've totally screwed up something:
>
> https://download.blender.org/durian/trailer/sintel_trailer-480p.mp4
> https://download.blender.org/durian/trailer/sintel_trailer-720p.mp4
> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4

Thanks

What is your display (size, mode, etc)?  Mine is hdmi 1280x760M60

>
>> I'd like to try to duplicate what you are using explicitly.
>
> I can also send you my test mpegts files, so you can see gstreamer in
> its full glory.

That could be useful, thanks

>>>
>>> Unfortunately, stock gst-1.0 and gst-0.10 doesn't work with the
>>> DVB-S stream dumps I made from my customer's infrastructure, and
>>> this is what counts in my specific context.

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

Gstreamer issues on Fido (was: Fido with kernel 3.10.17)

[Nikolay Dimitrov]

Hi Gary,

On 05/12/2015 04:35 PM, Gary Thomas wrote:
> On 2015-05-12 07:24, Nikolay Dimitrov wrote:
>> Ho Gary,
>>
>> On 05/12/2015 04:18 PM, Gary Thomas wrote:
>>> On 2015-05-12 07:12, Nikolay Dimitrov wrote:
>>>> Hi Otavio,
>>>>
>>>> On 05/12/2015 03:59 PM, Otavio Salvador wrote:
>>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com>
>>>>> wrote:
>>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>>
>>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas
>>>>>>> <gary@mlbassoc.com> wrote:
>>>>>>>>
>>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov
>>>>>>>>> <picmaster@mail.bg> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Gstreamer-1.0 freezes instantly with my test video
>>>>>>>>>> streams. As I've invested some time in the past to
>>>>>>>>>> really force gstreamer-0.10 to work, I'm quite
>>>>>>>>>> reluctant to go forward with gstreamer-1.0, especially
>>>>>>>>>> when its MPEGTS implementation is, well...
>>>>>>>>>> half-working. So I'm sticking with what I've made to
>>>>>>>>>> work so far.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Did you try the community plugin? We have been using it
>>>>>>>>> with several customers and in general it is working very
>>>>>>>>> well.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Is that not what you would get when running the media
>>>>>>>> player?
>>>>>>>>
>>>>>>>> Do you have an example pipeline that does work, e.g. play
>>>>>>>> a complete movie (H264+mp3) in .mp4 container?
>>>>>>>
>>>>>>>
>>>>>>> gst-play-1.0 works.
>>>>>>>
>>>>>>
>>>>>> Not for me on either of the i.MX6 boards I have here :-(  What
>>>>>> board(s) [and kernel] have you tested with?
>>>>>>
>>>>>> What did you play?  What is your display device?  Anything else
>>>>>> you can provide that might help me figure this out...
>>>>>
>>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works
>>>>> for many movies.
>>>>
>>>> That's correct. I usually make smoke test with the Sintel trailers
>>>> and it works fine here.
>>>
>>> What package includes these?  Or [exactly] what file(s) do you use?
>>
>> Please check here: https://download.blender.org/durian/trailer/
>>
>> These are my 3 favorite files for testing, they usually work fine
>> unless I've totally screwed up something:
>>
>> https://download.blender.org/durian/trailer/sintel_trailer-480p.mp4
>> https://download.blender.org/durian/trailer/sintel_trailer-720p.mp4
>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4
>
> Thanks
>
> What is your display (size, mode, etc)?  Mine is hdmi 1280x760M60

I have to support one of 2 LCD panels, selectable in boot-time:
- 1366x768 on 18-bit LVDS
- 1366x768 on 24-bit LVDS, rotated at 180 degrees

Unfortunately this resolution created all kinds of problems, so I've
settled on 1360x768, which works OK. The rotation itself also created
issues with Xorg - slower subjective performance in rotated mode, more
noticeable screen tearing, Firefox calculated wrong coordinates of
html5 widgets. Xorg is also on my ditching list...

>>> I'd like to try to duplicate what you are using explicitly.
>>
>> I can also send you my test mpegts files, so you can see gstreamer in
>> its full glory.
>
> That could be useful, thanks

I'll follow-up.

>>>> Unfortunately, stock gst-1.0 and gst-0.10 doesn't work with the
>>>> DVB-S stream dumps I made from my customer's infrastructure, and
>>>> this is what counts in my specific context.

Regards,
Nikolay

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-12 06:59, Otavio Salvador wrote:
> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>
>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>
>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>
>>>>>
>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Gstreamer-1.0 freezes instantly with my test video streams. As I've
>>>>>> invested some time in the past to really force gstreamer-0.10 to work,
>>>>>> I'm quite reluctant to go forward with gstreamer-1.0, especially when
>>>>>> its MPEGTS implementation is, well... half-working. So I'm sticking
>>>>>> with
>>>>>> what I've made to work so far.
>>>>>
>>>>>
>>>>>
>>>>> Did you try the community plugin? We have been using it with several
>>>>> customers and in general it is working very well.
>>>>>
>>>>
>>>> Is that not what you would get when running the media player?
>>>>
>>>> Do you have an example pipeline that does work, e.g. play a
>>>> complete movie (H264+mp3) in .mp4 container?
>>>
>>>
>>> gst-play-1.0 works.
>>>
>>
>> Not for me on either of the i.MX6 boards I have here :-(  What board(s)
>> [and kernel] have you tested with?
>>
>> What did you play?  What is your display device?  Anything else
>> you can provide that might help me figure this out...
>
> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
> many movies.
>

I found that my kernel was not enabling mxc_v4l2_output.  I've enabled this
and now the result is different, but always failing with:
   mxc_v4l2_output v4l2_out.32: Bypass IC.
   Attempt to unlock mutex that was not locked

Do you have an image where this works correctly?  I'd like to try it with
my kernel on my hardware, etc.

Thanks

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

Re: Fido with kernel 3.10.17

[Otavio Salvador]

On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2015-05-12 06:59, Otavio Salvador wrote:
>>
>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>
>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>
>>>>
>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>
>>>>>
>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Gstreamer-1.0 freezes instantly with my test video streams. As I've
>>>>>>> invested some time in the past to really force gstreamer-0.10 to
>>>>>>> work,
>>>>>>> I'm quite reluctant to go forward with gstreamer-1.0, especially when
>>>>>>> its MPEGTS implementation is, well... half-working. So I'm sticking
>>>>>>> with
>>>>>>> what I've made to work so far.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Did you try the community plugin? We have been using it with several
>>>>>> customers and in general it is working very well.
>>>>>>
>>>>>
>>>>> Is that not what you would get when running the media player?
>>>>>
>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>
>>>>
>>>>
>>>> gst-play-1.0 works.
>>>>
>>>
>>> Not for me on either of the i.MX6 boards I have here :-(  What board(s)
>>> [and kernel] have you tested with?
>>>
>>> What did you play?  What is your display device?  Anything else
>>> you can provide that might help me figure this out...
>>
>>
>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
>> many movies.
>>
>
> I found that my kernel was not enabling mxc_v4l2_output.  I've enabled this
> and now the result is different, but always failing with:
>   mxc_v4l2_output v4l2_out.32: Bypass IC.
>   Attempt to unlock mutex that was not locked
>
> Do you have an image where this works correctly?  I'd like to try it with
> my kernel on my hardware, etc.

http://ci.ossystems.com.br/public/fsl-community-bsp/fido

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-13 07:07, Otavio Salvador wrote:
> On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>> On 2015-05-12 06:59, Otavio Salvador wrote:
>>>
>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>
>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>
>>>>>
>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Gstreamer-1.0 freezes instantly with my test video streams. As I've
>>>>>>>> invested some time in the past to really force gstreamer-0.10 to
>>>>>>>> work,
>>>>>>>> I'm quite reluctant to go forward with gstreamer-1.0, especially when
>>>>>>>> its MPEGTS implementation is, well... half-working. So I'm sticking
>>>>>>>> with
>>>>>>>> what I've made to work so far.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Did you try the community plugin? We have been using it with several
>>>>>>> customers and in general it is working very well.
>>>>>>>
>>>>>>
>>>>>> Is that not what you would get when running the media player?
>>>>>>
>>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>>
>>>>>
>>>>>
>>>>> gst-play-1.0 works.
>>>>>
>>>>
>>>> Not for me on either of the i.MX6 boards I have here :-(  What board(s)
>>>> [and kernel] have you tested with?
>>>>
>>>> What did you play?  What is your display device?  Anything else
>>>> you can provide that might help me figure this out...
>>>
>>>
>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
>>> many movies.
>>>
>>
>> I found that my kernel was not enabling mxc_v4l2_output.  I've enabled this
>> and now the result is different, but always failing with:
>>    mxc_v4l2_output v4l2_out.32: Bypass IC.
>>    Attempt to unlock mutex that was not locked
>>
>> Do you have an image where this works correctly?  I'd like to try it with
>> my kernel on my hardware, etc.
>
> http://ci.ossystems.com.br/public/fsl-community-bsp/fido
>

Thanks.  I tried an image for my SabreLite, but it seems to be missing
important bits.  This is the image I tried:
   http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-multimedia-nitrogen6x.sdcard

It doesn't have gst-play-1.0, nor much of anything as far as I can tell.
X brings up a terminal window, but I don't see how to run anything else,
e.g. chrome?

What am I missing?  Perhaps I chose the wrong image?  How do I play a movie
using this image (as your comment above says should work)?

Thanks again

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

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-13 07:27, Gary Thomas wrote:
> On 2015-05-13 07:07, Otavio Salvador wrote:
>> On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>> On 2015-05-12 06:59, Otavio Salvador wrote:
>>>>
>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>
>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Gstreamer-1.0 freezes instantly with my test video streams. As I've
>>>>>>>>> invested some time in the past to really force gstreamer-0.10 to
>>>>>>>>> work,
>>>>>>>>> I'm quite reluctant to go forward with gstreamer-1.0, especially when
>>>>>>>>> its MPEGTS implementation is, well... half-working. So I'm sticking
>>>>>>>>> with
>>>>>>>>> what I've made to work so far.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Did you try the community plugin? We have been using it with several
>>>>>>>> customers and in general it is working very well.
>>>>>>>>
>>>>>>>
>>>>>>> Is that not what you would get when running the media player?
>>>>>>>
>>>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>>>
>>>>>>
>>>>>>
>>>>>> gst-play-1.0 works.
>>>>>>
>>>>>
>>>>> Not for me on either of the i.MX6 boards I have here :-(  What board(s)
>>>>> [and kernel] have you tested with?
>>>>>
>>>>> What did you play?  What is your display device?  Anything else
>>>>> you can provide that might help me figure this out...
>>>>
>>>>
>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
>>>> many movies.
>>>>
>>>
>>> I found that my kernel was not enabling mxc_v4l2_output.  I've enabled this
>>> and now the result is different, but always failing with:
>>>    mxc_v4l2_output v4l2_out.32: Bypass IC.
>>>    Attempt to unlock mutex that was not locked
>>>
>>> Do you have an image where this works correctly?  I'd like to try it with
>>> my kernel on my hardware, etc.
>>
>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido
>>
>
> Thanks.  I tried an image for my SabreLite, but it seems to be missing
> important bits.  This is the image I tried:
>    http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-multimedia-nitrogen6x.sdcard
>
> It doesn't have gst-play-1.0, nor much of anything as far as I can tell.
> X brings up a terminal window, but I don't see how to run anything else,
> e.g. chrome?
>
> What am I missing?  Perhaps I chose the wrong image?  How do I play a movie
> using this image (as your comment above says should work)?
>
> Thanks again
>

I tried a different image that has more tools:
   http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-machine-test-nitrogen6x.sdcard

Sadly, it's working the same as the image(s) I build myself:

root@nitrogen6x:~# export DISPLAY=:0.0
root@nitrogen6x:~# gst-play-1.0 Vlad+Louise.mp4
mxc_cam_select_input: input(0) CSI IC MEM
mxc_v4l_open: Mxc Camera no sensor ipu1/csi0
mxc_v4l_open: Mxc Camera no sensor ipu1/csi1
Now playing /home/root/Vlad+Louise.mp4
[INFO]liProduct 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
Aborted

Please tell me again how this is working well for your customers?
What am I doing wrong?

Note: I've tried multiple .mp4 files, with the same results.

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

Re: Fido with kernel 3.10.17

[Otavio Salvador]

On Wed, May 13, 2015 at 11:00 AM, Gary Thomas <gary@mlbassoc.com> wrote:
> On 2015-05-13 07:27, Gary Thomas wrote:
>>
>> On 2015-05-13 07:07, Otavio Salvador wrote:
>>>
>>> On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>
>>>> On 2015-05-12 06:59, Otavio Salvador wrote:
>>>>>
>>>>>
>>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov
>>>>>>>>> <picmaster@mail.bg>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Gstreamer-1.0 freezes instantly with my test video streams. As
>>>>>>>>>> I've
>>>>>>>>>> invested some time in the past to really force gstreamer-0.10 to
>>>>>>>>>> work,
>>>>>>>>>> I'm quite reluctant to go forward with gstreamer-1.0, especially
>>>>>>>>>> when
>>>>>>>>>> its MPEGTS implementation is, well... half-working. So I'm
>>>>>>>>>> sticking
>>>>>>>>>> with
>>>>>>>>>> what I've made to work so far.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Did you try the community plugin? We have been using it with
>>>>>>>>> several
>>>>>>>>> customers and in general it is working very well.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Is that not what you would get when running the media player?
>>>>>>>>
>>>>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> gst-play-1.0 works.
>>>>>>>
>>>>>>
>>>>>> Not for me on either of the i.MX6 boards I have here :-(  What
>>>>>> board(s)
>>>>>> [and kernel] have you tested with?
>>>>>>
>>>>>> What did you play?  What is your display device?  Anything else
>>>>>> you can provide that might help me figure this out...
>>>>>
>>>>>
>>>>>
>>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
>>>>> many movies.
>>>>>
>>>>
>>>> I found that my kernel was not enabling mxc_v4l2_output.  I've enabled
>>>> this
>>>> and now the result is different, but always failing with:
>>>>    mxc_v4l2_output v4l2_out.32: Bypass IC.
>>>>    Attempt to unlock mutex that was not locked
>>>>
>>>> Do you have an image where this works correctly?  I'd like to try it
>>>> with
>>>> my kernel on my hardware, etc.
>>>
>>>
>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido
>>>
>>
>> Thanks.  I tried an image for my SabreLite, but it seems to be missing
>> important bits.  This is the image I tried:
>>
>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-multimedia-nitrogen6x.sdcard
>>
>> It doesn't have gst-play-1.0, nor much of anything as far as I can tell.
>> X brings up a terminal window, but I don't see how to run anything else,
>> e.g. chrome?
>>
>> What am I missing?  Perhaps I chose the wrong image?  How do I play a
>> movie
>> using this image (as your comment above says should work)?
>>
>> Thanks again
>>
>
> I tried a different image that has more tools:
>
> http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-machine-test-nitrogen6x.sdcard
>
> Sadly, it's working the same as the image(s) I build myself:
>
> root@nitrogen6x:~# export DISPLAY=:0.0
> root@nitrogen6x:~# gst-play-1.0 Vlad+Louise.mp4
> mxc_cam_select_input: input(0) CSI IC MEM
> mxc_v4l_open: Mxc Camera no sensor ipu1/csi0
> mxc_v4l_open: Mxc Camera no sensor ipu1/csi1
> Now playing /home/root/Vlad+Louise.mp4
> [INFO]liProduct 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
> Aborted
>
> Please tell me again how this is working well for your customers?
> What am I doing wrong?
>
> Note: I've tried multiple .mp4 files, with the same results.

I've been using Framebuffer and Nitrogen6x. We however use O.S.
Systems Embedded Linux internally and this is what we deliver for
customer however it shouldn't impact it. You can try Dizzy as well and
see if it changes something.

Most of our customers didn't migrate for Fido yet so it may have
regressions we don't yet know about.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-13 08:00, Gary Thomas wrote:
> On 2015-05-13 07:27, Gary Thomas wrote:
>> On 2015-05-13 07:07, Otavio Salvador wrote:
>>> On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>> On 2015-05-12 06:59, Otavio Salvador wrote:
>>>>>
>>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>
>>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Gstreamer-1.0 freezes instantly with my test video streams. As I've
>>>>>>>>>> invested some time in the past to really force gstreamer-0.10 to
>>>>>>>>>> work,
>>>>>>>>>> I'm quite reluctant to go forward with gstreamer-1.0, especially when
>>>>>>>>>> its MPEGTS implementation is, well... half-working. So I'm sticking
>>>>>>>>>> with
>>>>>>>>>> what I've made to work so far.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Did you try the community plugin? We have been using it with several
>>>>>>>>> customers and in general it is working very well.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Is that not what you would get when running the media player?
>>>>>>>>
>>>>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> gst-play-1.0 works.
>>>>>>>
>>>>>>
>>>>>> Not for me on either of the i.MX6 boards I have here :-(  What board(s)
>>>>>> [and kernel] have you tested with?
>>>>>>
>>>>>> What did you play?  What is your display device?  Anything else
>>>>>> you can provide that might help me figure this out...
>>>>>
>>>>>
>>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
>>>>> many movies.
>>>>>
>>>>
>>>> I found that my kernel was not enabling mxc_v4l2_output.  I've enabled this
>>>> and now the result is different, but always failing with:
>>>>    mxc_v4l2_output v4l2_out.32: Bypass IC.
>>>>    Attempt to unlock mutex that was not locked
>>>>
>>>> Do you have an image where this works correctly?  I'd like to try it with
>>>> my kernel on my hardware, etc.
>>>
>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido
>>>
>>
>> Thanks.  I tried an image for my SabreLite, but it seems to be missing
>> important bits.  This is the image I tried:
>>    http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-multimedia-nitrogen6x.sdcard
>>
>> It doesn't have gst-play-1.0, nor much of anything as far as I can tell.
>> X brings up a terminal window, but I don't see how to run anything else,
>> e.g. chrome?
>>
>> What am I missing?  Perhaps I chose the wrong image?  How do I play a movie
>> using this image (as your comment above says should work)?
>>
>> Thanks again
>>
>
> I tried a different image that has more tools:
>    http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-machine-test-nitrogen6x.sdcard
>
> Sadly, it's working the same as the image(s) I build myself:
>
> root@nitrogen6x:~# export DISPLAY=:0.0
> root@nitrogen6x:~# gst-play-1.0 Vlad+Louise.mp4
> mxc_cam_select_input: input(0) CSI IC MEM
> mxc_v4l_open: Mxc Camera no sensor ipu1/csi0
> mxc_v4l_open: Mxc Camera no sensor ipu1/csi1
> Now playing /home/root/Vlad+Louise.mp4
> [INFO]liProduct 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
> Aborted
>
> Please tell me again how this is working well for your customers?
> What am I doing wrong?
>
> Note: I've tried multiple .mp4 files, with the same results.
>

I've tracked this down to the gst1.0-fsl-plugin package.
Here's a GDB backktrace from the abort:

(gdb) bt
#0  0xb6b109d4 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0xb6b144d4 in __GI_abort () at abort.c:89
#2  0xb6d537e4 in g_mutex_unlock_slowpath (mutex=mutex@entry=0xb39ff460, prev=<optimized out>)
     at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1326
#3  0xb6d542f8 in g_mutex_unlock (mutex=mutex@entry=0xb39ff460)
     at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1349
#4  0xb6d5441c in g_cond_wait (cond=0xfffffffe, cond@entry=0xb49085e4, mutex=0xb39ff460, mutex@entry=0xb49085f0)
     at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1394
#5  0xb31d3a98 in compositor_compositing_thread (compositor=0xb49085d0)
     at /usr/src/debug/gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c:282
#6  0xb6d34be4 in g_thread_proxy (data=0xb4902a30)
     at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread.c:764
#7  0xb6c27de0 in start_thread (arg=0xb39ff460) at pthread_create.c:338
#8  0xb6bb4fa0 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:89 from /tmp/p0382_root/lib/libc.so.6

The function in question is:

static gpointer compositor_compositing_thread (gpointer compositor)
{
   CompositorHandle *hcompositor = (CompositorHandle*) compositor;

   while (hcompositor->running) {
     COMPOSITOR_WAIT_SURFACE (hcompositor);
     compositor_do_compositing_surface_list (hcompositor);
   }

   GST_DEBUG ("compositor thread exit");

   return;
}

It's failing on the 'COMPOSITOR_WAIT_SURFACE' function, the first time
is is called.

Anyone know why this might be failing?  Does someone have a working
example of this code - from either fido or current master?

Thanks

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

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-13 10:16, Gary Thomas wrote:
> On 2015-05-13 08:00, Gary Thomas wrote:
>> On 2015-05-13 07:27, Gary Thomas wrote:
>>> On 2015-05-13 07:07, Otavio Salvador wrote:
>>>> On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>> On 2015-05-12 06:59, Otavio Salvador wrote:
>>>>>>
>>>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>>
>>>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Gstreamer-1.0 freezes instantly with my test video streams. As I've
>>>>>>>>>>> invested some time in the past to really force gstreamer-0.10 to
>>>>>>>>>>> work,
>>>>>>>>>>> I'm quite reluctant to go forward with gstreamer-1.0, especially when
>>>>>>>>>>> its MPEGTS implementation is, well... half-working. So I'm sticking
>>>>>>>>>>> with
>>>>>>>>>>> what I've made to work so far.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Did you try the community plugin? We have been using it with several
>>>>>>>>>> customers and in general it is working very well.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Is that not what you would get when running the media player?
>>>>>>>>>
>>>>>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> gst-play-1.0 works.
>>>>>>>>
>>>>>>>
>>>>>>> Not for me on either of the i.MX6 boards I have here :-(  What board(s)
>>>>>>> [and kernel] have you tested with?
>>>>>>>
>>>>>>> What did you play?  What is your display device?  Anything else
>>>>>>> you can provide that might help me figure this out...
>>>>>>
>>>>>>
>>>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
>>>>>> many movies.
>>>>>>
>>>>>
>>>>> I found that my kernel was not enabling mxc_v4l2_output.  I've enabled this
>>>>> and now the result is different, but always failing with:
>>>>>    mxc_v4l2_output v4l2_out.32: Bypass IC.
>>>>>    Attempt to unlock mutex that was not locked
>>>>>
>>>>> Do you have an image where this works correctly?  I'd like to try it with
>>>>> my kernel on my hardware, etc.
>>>>
>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido
>>>>
>>>
>>> Thanks.  I tried an image for my SabreLite, but it seems to be missing
>>> important bits.  This is the image I tried:
>>>    http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-multimedia-nitrogen6x.sdcard
>>>
>>> It doesn't have gst-play-1.0, nor much of anything as far as I can tell.
>>> X brings up a terminal window, but I don't see how to run anything else,
>>> e.g. chrome?
>>>
>>> What am I missing?  Perhaps I chose the wrong image?  How do I play a movie
>>> using this image (as your comment above says should work)?
>>>
>>> Thanks again
>>>
>>
>> I tried a different image that has more tools:
>>    http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-machine-test-nitrogen6x.sdcard
>>
>> Sadly, it's working the same as the image(s) I build myself:
>>
>> root@nitrogen6x:~# export DISPLAY=:0.0
>> root@nitrogen6x:~# gst-play-1.0 Vlad+Louise.mp4
>> mxc_cam_select_input: input(0) CSI IC MEM
>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi0
>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi1
>> Now playing /home/root/Vlad+Louise.mp4
>> [INFO]liProduct 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
>> Aborted
>>
>> Please tell me again how this is working well for your customers?
>> What am I doing wrong?
>>
>> Note: I've tried multiple .mp4 files, with the same results.
>>
>
> I've tracked this down to the gst1.0-fsl-plugin package.
> Here's a GDB backktrace from the abort:
>
> (gdb) bt
> #0  0xb6b109d4 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
> #1  0xb6b144d4 in __GI_abort () at abort.c:89
> #2  0xb6d537e4 in g_mutex_unlock_slowpath (mutex=mutex@entry=0xb39ff460, prev=<optimized out>)
>      at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1326
> #3  0xb6d542f8 in g_mutex_unlock (mutex=mutex@entry=0xb39ff460)
>      at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1349
> #4  0xb6d5441c in g_cond_wait (cond=0xfffffffe, cond@entry=0xb49085e4, mutex=0xb39ff460, mutex@entry=0xb49085f0)
>      at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1394
> #5  0xb31d3a98 in compositor_compositing_thread (compositor=0xb49085d0)
>      at /usr/src/debug/gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c:282
> #6  0xb6d34be4 in g_thread_proxy (data=0xb4902a30)
>      at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread.c:764
> #7  0xb6c27de0 in start_thread (arg=0xb39ff460) at pthread_create.c:338
> #8  0xb6bb4fa0 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:89 from /tmp/p0382_root/lib/libc.so.6
>
> The function in question is:
>
> static gpointer compositor_compositing_thread (gpointer compositor)
> {
>    CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>
>    while (hcompositor->running) {
>      COMPOSITOR_WAIT_SURFACE (hcompositor);
>      compositor_do_compositing_surface_list (hcompositor);
>    }
>
>    GST_DEBUG ("compositor thread exit");
>
>    return;
> }
>
> It's failing on the 'COMPOSITOR_WAIT_SURFACE' function, the first time
> is is called.
>
> Anyone know why this might be failing?  Does someone have a working
> example of this code - from either fido or current master?
>
> Thanks
>

BTW, this patch fixes the problem and I can play my videos with gst-play.
Is it correct?

Index: gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
===================================================================
--- gst1.0-fsl-plugins-4.0.3.orig/plugins/overlay_sink/compositor.c
+++ gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
@@ -278,6 +278,7 @@ static gpointer compositor_compositing_t
  {
    CompositorHandle *hcompositor = (CompositorHandle*) compositor;

+  g_mutex_lock(&hcompositor->lock);
    while (hcompositor->running) {
      COMPOSITOR_WAIT_SURFACE (hcompositor);
      compositor_do_compositing_surface_list (hcompositor);

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

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-13 11:00, Gary Thomas wrote:
> On 2015-05-13 10:16, Gary Thomas wrote:
>> On 2015-05-13 08:00, Gary Thomas wrote:
>>> On 2015-05-13 07:27, Gary Thomas wrote:
>>>> On 2015-05-13 07:07, Otavio Salvador wrote:
>>>>> On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>> On 2015-05-12 06:59, Otavio Salvador wrote:
>>>>>>>
>>>>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>>>
>>>>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Gstreamer-1.0 freezes instantly with my test video streams. As I've
>>>>>>>>>>>> invested some time in the past to really force gstreamer-0.10 to
>>>>>>>>>>>> work,
>>>>>>>>>>>> I'm quite reluctant to go forward with gstreamer-1.0, especially when
>>>>>>>>>>>> its MPEGTS implementation is, well... half-working. So I'm sticking
>>>>>>>>>>>> with
>>>>>>>>>>>> what I've made to work so far.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Did you try the community plugin? We have been using it with several
>>>>>>>>>>> customers and in general it is working very well.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Is that not what you would get when running the media player?
>>>>>>>>>>
>>>>>>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>>>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> gst-play-1.0 works.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Not for me on either of the i.MX6 boards I have here :-(  What board(s)
>>>>>>>> [and kernel] have you tested with?
>>>>>>>>
>>>>>>>> What did you play?  What is your display device?  Anything else
>>>>>>>> you can provide that might help me figure this out...
>>>>>>>
>>>>>>>
>>>>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
>>>>>>> many movies.
>>>>>>>
>>>>>>
>>>>>> I found that my kernel was not enabling mxc_v4l2_output.  I've enabled this
>>>>>> and now the result is different, but always failing with:
>>>>>>    mxc_v4l2_output v4l2_out.32: Bypass IC.
>>>>>>    Attempt to unlock mutex that was not locked
>>>>>>
>>>>>> Do you have an image where this works correctly?  I'd like to try it with
>>>>>> my kernel on my hardware, etc.
>>>>>
>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido
>>>>>
>>>>
>>>> Thanks.  I tried an image for my SabreLite, but it seems to be missing
>>>> important bits.  This is the image I tried:
>>>>    http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-multimedia-nitrogen6x.sdcard
>>>>
>>>> It doesn't have gst-play-1.0, nor much of anything as far as I can tell.
>>>> X brings up a terminal window, but I don't see how to run anything else,
>>>> e.g. chrome?
>>>>
>>>> What am I missing?  Perhaps I chose the wrong image?  How do I play a movie
>>>> using this image (as your comment above says should work)?
>>>>
>>>> Thanks again
>>>>
>>>
>>> I tried a different image that has more tools:
>>>    http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-machine-test-nitrogen6x.sdcard
>>>
>>> Sadly, it's working the same as the image(s) I build myself:
>>>
>>> root@nitrogen6x:~# export DISPLAY=:0.0
>>> root@nitrogen6x:~# gst-play-1.0 Vlad+Louise.mp4
>>> mxc_cam_select_input: input(0) CSI IC MEM
>>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi0
>>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi1
>>> Now playing /home/root/Vlad+Louise.mp4
>>> [INFO]liProduct 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
>>> Aborted
>>>
>>> Please tell me again how this is working well for your customers?
>>> What am I doing wrong?
>>>
>>> Note: I've tried multiple .mp4 files, with the same results.
>>>
>>
>> I've tracked this down to the gst1.0-fsl-plugin package.
>> Here's a GDB backktrace from the abort:
>>
>> (gdb) bt
>> #0  0xb6b109d4 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
>> #1  0xb6b144d4 in __GI_abort () at abort.c:89
>> #2  0xb6d537e4 in g_mutex_unlock_slowpath (mutex=mutex@entry=0xb39ff460, prev=<optimized out>)
>>      at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1326
>> #3  0xb6d542f8 in g_mutex_unlock (mutex=mutex@entry=0xb39ff460)
>>      at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1349
>> #4  0xb6d5441c in g_cond_wait (cond=0xfffffffe, cond@entry=0xb49085e4, mutex=0xb39ff460, mutex@entry=0xb49085f0)
>>      at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1394
>> #5  0xb31d3a98 in compositor_compositing_thread (compositor=0xb49085d0)
>>      at /usr/src/debug/gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c:282
>> #6  0xb6d34be4 in g_thread_proxy (data=0xb4902a30)
>>      at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread.c:764
>> #7  0xb6c27de0 in start_thread (arg=0xb39ff460) at pthread_create.c:338
>> #8  0xb6bb4fa0 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:89 from /tmp/p0382_root/lib/libc.so.6
>>
>> The function in question is:
>>
>> static gpointer compositor_compositing_thread (gpointer compositor)
>> {
>>    CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>>
>>    while (hcompositor->running) {
>>      COMPOSITOR_WAIT_SURFACE (hcompositor);
>>      compositor_do_compositing_surface_list (hcompositor);
>>    }
>>
>>    GST_DEBUG ("compositor thread exit");
>>
>>    return;
>> }
>>
>> It's failing on the 'COMPOSITOR_WAIT_SURFACE' function, the first time
>> is is called.
>>
>> Anyone know why this might be failing?  Does someone have a working
>> example of this code - from either fido or current master?
>>
>> Thanks
>>
>
> BTW, this patch fixes the problem and I can play my videos with gst-play.
> Is it correct?
>
> Index: gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
> ===================================================================
> --- gst1.0-fsl-plugins-4.0.3.orig/plugins/overlay_sink/compositor.c
> +++ gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
> @@ -278,6 +278,7 @@ static gpointer compositor_compositing_t
>   {
>     CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>
> +  g_mutex_lock(&hcompositor->lock);
>     while (hcompositor->running) {
>       COMPOSITOR_WAIT_SURFACE (hcompositor);
>       compositor_do_compositing_surface_list (hcompositor);
>

"Working" was a bit premature :-(  gst-play does work when I run it
manually from the command line.  When I run it from the window manager
(i.e. click on 'media player'), it tries to run now (as opposed to
quitting immediately), but there is no video shown, only a progress
bar.

Anyone know what might be the difference when running in these two
modes?

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

Re: Fido with kernel 3.10.17

[Nikolay Dimitrov]

On 05/13/2015 09:15 PM, Gary Thomas wrote:
> On 2015-05-13 11:00, Gary Thomas wrote:
>> On 2015-05-13 10:16, Gary Thomas wrote:
>>> On 2015-05-13 08:00, Gary Thomas wrote:
>>>> On 2015-05-13 07:27, Gary Thomas wrote:
>>>>> On 2015-05-13 07:07, Otavio Salvador wrote:
>>>>>> On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <gary@mlbassoc.com>
>>>>>> wrote:
>>>>>>> On 2015-05-12 06:59, Otavio Salvador wrote:
>>>>>>>>
>>>>>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas
>>>>>>>>>> <gary@mlbassoc.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov
>>>>>>>>>>>> <picmaster@mail.bg>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gstreamer-1.0 freezes instantly with my test video streams.
>>>>>>>>>>>>> As I've
>>>>>>>>>>>>> invested some time in the past to really force
>>>>>>>>>>>>> gstreamer-0.10 to
>>>>>>>>>>>>> work,
>>>>>>>>>>>>> I'm quite reluctant to go forward with gstreamer-1.0,
>>>>>>>>>>>>> especially when
>>>>>>>>>>>>> its MPEGTS implementation is, well... half-working. So I'm
>>>>>>>>>>>>> sticking
>>>>>>>>>>>>> with
>>>>>>>>>>>>> what I've made to work so far.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Did you try the community plugin? We have been using it with
>>>>>>>>>>>> several
>>>>>>>>>>>> customers and in general it is working very well.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Is that not what you would get when running the media player?
>>>>>>>>>>>
>>>>>>>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>>>>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> gst-play-1.0 works.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not for me on either of the i.MX6 boards I have here :-(  What
>>>>>>>>> board(s)
>>>>>>>>> [and kernel] have you tested with?
>>>>>>>>>
>>>>>>>>> What did you play?  What is your display device?  Anything else
>>>>>>>>> you can provide that might help me figure this out...
>>>>>>>>
>>>>>>>>
>>>>>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works
>>>>>>>> for
>>>>>>>> many movies.
>>>>>>>>
>>>>>>>
>>>>>>> I found that my kernel was not enabling mxc_v4l2_output.  I've
>>>>>>> enabled this
>>>>>>> and now the result is different, but always failing with:
>>>>>>>    mxc_v4l2_output v4l2_out.32: Bypass IC.
>>>>>>>    Attempt to unlock mutex that was not locked
>>>>>>>
>>>>>>> Do you have an image where this works correctly?  I'd like to try
>>>>>>> it with
>>>>>>> my kernel on my hardware, etc.
>>>>>>
>>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido
>>>>>>
>>>>>
>>>>> Thanks.  I tried an image for my SabreLite, but it seems to be missing
>>>>> important bits.  This is the image I tried:
>>>>>
>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-multimedia-nitrogen6x.sdcard
>>>>>
>>>>>
>>>>> It doesn't have gst-play-1.0, nor much of anything as far as I can
>>>>> tell.
>>>>> X brings up a terminal window, but I don't see how to run anything
>>>>> else,
>>>>> e.g. chrome?
>>>>>
>>>>> What am I missing?  Perhaps I chose the wrong image?  How do I play
>>>>> a movie
>>>>> using this image (as your comment above says should work)?
>>>>>
>>>>> Thanks again
>>>>>
>>>>
>>>> I tried a different image that has more tools:
>>>>
>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-machine-test-nitrogen6x.sdcard
>>>>
>>>>
>>>> Sadly, it's working the same as the image(s) I build myself:
>>>>
>>>> root@nitrogen6x:~# export DISPLAY=:0.0
>>>> root@nitrogen6x:~# gst-play-1.0 Vlad+Louise.mp4
>>>> mxc_cam_select_input: input(0) CSI IC MEM
>>>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi0
>>>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi1
>>>> Now playing /home/root/Vlad+Louise.mp4
>>>> [INFO]liProduct 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
>>>> Aborted
>>>>
>>>> Please tell me again how this is working well for your customers?
>>>> What am I doing wrong?
>>>>
>>>> Note: I've tried multiple .mp4 files, with the same results.
>>>>
>>>
>>> I've tracked this down to the gst1.0-fsl-plugin package.
>>> Here's a GDB backktrace from the abort:
>>>
>>> (gdb) bt
>>> #0  0xb6b109d4 in __GI_raise (sig=sig@entry=6) at
>>> ../sysdeps/unix/sysv/linux/raise.c:55
>>> #1  0xb6b144d4 in __GI_abort () at abort.c:89
>>> #2  0xb6d537e4 in g_mutex_unlock_slowpath
>>> (mutex=mutex@entry=0xb39ff460, prev=<optimized out>)
>>>      at
>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1326
>>>
>>> #3  0xb6d542f8 in g_mutex_unlock (mutex=mutex@entry=0xb39ff460)
>>>      at
>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1349
>>>
>>> #4  0xb6d5441c in g_cond_wait (cond=0xfffffffe,
>>> cond@entry=0xb49085e4, mutex=0xb39ff460, mutex@entry=0xb49085f0)
>>>      at
>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1394
>>>
>>> #5  0xb31d3a98 in compositor_compositing_thread (compositor=0xb49085d0)
>>>      at
>>> /usr/src/debug/gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c:282
>>>
>>> #6  0xb6d34be4 in g_thread_proxy (data=0xb4902a30)
>>>      at
>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread.c:764
>>> #7  0xb6c27de0 in start_thread (arg=0xb39ff460) at pthread_create.c:338
>>> #8  0xb6bb4fa0 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:89
>>> from /tmp/p0382_root/lib/libc.so.6
>>>
>>> The function in question is:
>>>
>>> static gpointer compositor_compositing_thread (gpointer compositor)
>>> {
>>>    CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>>>
>>>    while (hcompositor->running) {
>>>      COMPOSITOR_WAIT_SURFACE (hcompositor);
>>>      compositor_do_compositing_surface_list (hcompositor);
>>>    }
>>>
>>>    GST_DEBUG ("compositor thread exit");
>>>
>>>    return;
>>> }
>>>
>>> It's failing on the 'COMPOSITOR_WAIT_SURFACE' function, the first time
>>> is is called.
>>>
>>> Anyone know why this might be failing?  Does someone have a working
>>> example of this code - from either fido or current master?
>>>
>>> Thanks
>>>
>>
>> BTW, this patch fixes the problem and I can play my videos with gst-play.
>> Is it correct?
>>
>> Index: gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
>> ===================================================================
>> --- gst1.0-fsl-plugins-4.0.3.orig/plugins/overlay_sink/compositor.c
>> +++ gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
>> @@ -278,6 +278,7 @@ static gpointer compositor_compositing_t
>>   {
>>     CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>>
>> +  g_mutex_lock(&hcompositor->lock);
>>     while (hcompositor->running) {
>>       COMPOSITOR_WAIT_SURFACE (hcompositor);
>>       compositor_do_compositing_surface_list (hcompositor);
>>
>
> "Working" was a bit premature :-(  gst-play does work when I run it
> manually from the command line.  When I run it from the window manager
> (i.e. click on 'media player'), it tries to run now (as opposed to
> quitting immediately), but there is no video shown, only a progress
> bar.
>
> Anyone know what might be the difference when running in these two
> modes?

You can compare the command line arguments and processes' environments,
to look for any difference. Also, you can compare the gstreamer media
graphs.

Regards.

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-13 12:25, Nikolay Dimitrov wrote:
>
>
> On 05/13/2015 09:15 PM, Gary Thomas wrote:
>> On 2015-05-13 11:00, Gary Thomas wrote:
>>> On 2015-05-13 10:16, Gary Thomas wrote:
>>>> On 2015-05-13 08:00, Gary Thomas wrote:
>>>>> On 2015-05-13 07:27, Gary Thomas wrote:
>>>>>> On 2015-05-13 07:07, Otavio Salvador wrote:
>>>>>>> On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <gary@mlbassoc.com>
>>>>>>> wrote:
>>>>>>>> On 2015-05-12 06:59, Otavio Salvador wrote:
>>>>>>>>>
>>>>>>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas
>>>>>>>>>>> <gary@mlbassoc.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov
>>>>>>>>>>>>> <picmaster@mail.bg>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gstreamer-1.0 freezes instantly with my test video streams.
>>>>>>>>>>>>>> As I've
>>>>>>>>>>>>>> invested some time in the past to really force
>>>>>>>>>>>>>> gstreamer-0.10 to
>>>>>>>>>>>>>> work,
>>>>>>>>>>>>>> I'm quite reluctant to go forward with gstreamer-1.0,
>>>>>>>>>>>>>> especially when
>>>>>>>>>>>>>> its MPEGTS implementation is, well... half-working. So I'm
>>>>>>>>>>>>>> sticking
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> what I've made to work so far.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Did you try the community plugin? We have been using it with
>>>>>>>>>>>>> several
>>>>>>>>>>>>> customers and in general it is working very well.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Is that not what you would get when running the media player?
>>>>>>>>>>>>
>>>>>>>>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>>>>>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> gst-play-1.0 works.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Not for me on either of the i.MX6 boards I have here :-(  What
>>>>>>>>>> board(s)
>>>>>>>>>> [and kernel] have you tested with?
>>>>>>>>>>
>>>>>>>>>> What did you play?  What is your display device?  Anything else
>>>>>>>>>> you can provide that might help me figure this out...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works
>>>>>>>>> for
>>>>>>>>> many movies.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I found that my kernel was not enabling mxc_v4l2_output.  I've
>>>>>>>> enabled this
>>>>>>>> and now the result is different, but always failing with:
>>>>>>>>    mxc_v4l2_output v4l2_out.32: Bypass IC.
>>>>>>>>    Attempt to unlock mutex that was not locked
>>>>>>>>
>>>>>>>> Do you have an image where this works correctly?  I'd like to try
>>>>>>>> it with
>>>>>>>> my kernel on my hardware, etc.
>>>>>>>
>>>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido
>>>>>>>
>>>>>>
>>>>>> Thanks.  I tried an image for my SabreLite, but it seems to be missing
>>>>>> important bits.  This is the image I tried:
>>>>>>
>>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-multimedia-nitrogen6x.sdcard
>>>>>>
>>>>>>
>>>>>> It doesn't have gst-play-1.0, nor much of anything as far as I can
>>>>>> tell.
>>>>>> X brings up a terminal window, but I don't see how to run anything
>>>>>> else,
>>>>>> e.g. chrome?
>>>>>>
>>>>>> What am I missing?  Perhaps I chose the wrong image?  How do I play
>>>>>> a movie
>>>>>> using this image (as your comment above says should work)?
>>>>>>
>>>>>> Thanks again
>>>>>>
>>>>>
>>>>> I tried a different image that has more tools:
>>>>>
>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-machine-test-nitrogen6x.sdcard
>>>>>
>>>>>
>>>>> Sadly, it's working the same as the image(s) I build myself:
>>>>>
>>>>> root@nitrogen6x:~# export DISPLAY=:0.0
>>>>> root@nitrogen6x:~# gst-play-1.0 Vlad+Louise.mp4
>>>>> mxc_cam_select_input: input(0) CSI IC MEM
>>>>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi0
>>>>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi1
>>>>> Now playing /home/root/Vlad+Louise.mp4
>>>>> [INFO]liProduct 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
>>>>> Aborted
>>>>>
>>>>> Please tell me again how this is working well for your customers?
>>>>> What am I doing wrong?
>>>>>
>>>>> Note: I've tried multiple .mp4 files, with the same results.
>>>>>
>>>>
>>>> I've tracked this down to the gst1.0-fsl-plugin package.
>>>> Here's a GDB backktrace from the abort:
>>>>
>>>> (gdb) bt
>>>> #0  0xb6b109d4 in __GI_raise (sig=sig@entry=6) at
>>>> ../sysdeps/unix/sysv/linux/raise.c:55
>>>> #1  0xb6b144d4 in __GI_abort () at abort.c:89
>>>> #2  0xb6d537e4 in g_mutex_unlock_slowpath
>>>> (mutex=mutex@entry=0xb39ff460, prev=<optimized out>)
>>>>      at
>>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1326
>>>>
>>>> #3  0xb6d542f8 in g_mutex_unlock (mutex=mutex@entry=0xb39ff460)
>>>>      at
>>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1349
>>>>
>>>> #4  0xb6d5441c in g_cond_wait (cond=0xfffffffe,
>>>> cond@entry=0xb49085e4, mutex=0xb39ff460, mutex@entry=0xb49085f0)
>>>>      at
>>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1394
>>>>
>>>> #5  0xb31d3a98 in compositor_compositing_thread (compositor=0xb49085d0)
>>>>      at
>>>> /usr/src/debug/gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c:282
>>>>
>>>> #6  0xb6d34be4 in g_thread_proxy (data=0xb4902a30)
>>>>      at
>>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread.c:764
>>>> #7  0xb6c27de0 in start_thread (arg=0xb39ff460) at pthread_create.c:338
>>>> #8  0xb6bb4fa0 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:89
>>>> from /tmp/p0382_root/lib/libc.so.6
>>>>
>>>> The function in question is:
>>>>
>>>> static gpointer compositor_compositing_thread (gpointer compositor)
>>>> {
>>>>    CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>>>>
>>>>    while (hcompositor->running) {
>>>>      COMPOSITOR_WAIT_SURFACE (hcompositor);
>>>>      compositor_do_compositing_surface_list (hcompositor);
>>>>    }
>>>>
>>>>    GST_DEBUG ("compositor thread exit");
>>>>
>>>>    return;
>>>> }
>>>>
>>>> It's failing on the 'COMPOSITOR_WAIT_SURFACE' function, the first time
>>>> is is called.
>>>>
>>>> Anyone know why this might be failing?  Does someone have a working
>>>> example of this code - from either fido or current master?
>>>>
>>>> Thanks
>>>>
>>>
>>> BTW, this patch fixes the problem and I can play my videos with gst-play.
>>> Is it correct?
>>>
>>> Index: gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
>>> ===================================================================
>>> --- gst1.0-fsl-plugins-4.0.3.orig/plugins/overlay_sink/compositor.c
>>> +++ gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
>>> @@ -278,6 +278,7 @@ static gpointer compositor_compositing_t
>>>   {
>>>     CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>>>
>>> +  g_mutex_lock(&hcompositor->lock);
>>>     while (hcompositor->running) {
>>>       COMPOSITOR_WAIT_SURFACE (hcompositor);
>>>       compositor_do_compositing_surface_list (hcompositor);
>>>
>>
>> "Working" was a bit premature :-(  gst-play does work when I run it
>> manually from the command line.  When I run it from the window manager
>> (i.e. click on 'media player'), it tries to run now (as opposed to
>> quitting immediately), but there is no video shown, only a progress
>> bar.
>>
>> Anyone know what might be the difference when running in these two
>> modes?
>
> You can compare the command line arguments and processes' environments,
> to look for any difference. Also, you can compare the gstreamer media
> graphs.

If only I could figure out how to get them out - none of the
documented options seem to do much.

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

Re: Fido with kernel 3.10.17

[Gary Thomas]

On 2015-05-13 12:15, Gary Thomas wrote:
> On 2015-05-13 11:00, Gary Thomas wrote:
>> On 2015-05-13 10:16, Gary Thomas wrote:
>>> On 2015-05-13 08:00, Gary Thomas wrote:
>>>> On 2015-05-13 07:27, Gary Thomas wrote:
>>>>> On 2015-05-13 07:07, Otavio Salvador wrote:
>>>>>> On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>> On 2015-05-12 06:59, Otavio Salvador wrote:
>>>>>>>>
>>>>>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>>>>
>>>>>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas <gary@mlbassoc.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov <picmaster@mail.bg>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Gstreamer-1.0 freezes instantly with my test video streams. As I've
>>>>>>>>>>>>> invested some time in the past to really force gstreamer-0.10 to
>>>>>>>>>>>>> work,
>>>>>>>>>>>>> I'm quite reluctant to go forward with gstreamer-1.0, especially when
>>>>>>>>>>>>> its MPEGTS implementation is, well... half-working. So I'm sticking
>>>>>>>>>>>>> with
>>>>>>>>>>>>> what I've made to work so far.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Did you try the community plugin? We have been using it with several
>>>>>>>>>>>> customers and in general it is working very well.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Is that not what you would get when running the media player?
>>>>>>>>>>>
>>>>>>>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>>>>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> gst-play-1.0 works.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Not for me on either of the i.MX6 boards I have here :-(  What board(s)
>>>>>>>>> [and kernel] have you tested with?
>>>>>>>>>
>>>>>>>>> What did you play?  What is your display device?  Anything else
>>>>>>>>> you can provide that might help me figure this out...
>>>>>>>>
>>>>>>>>
>>>>>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia works for
>>>>>>>> many movies.
>>>>>>>>
>>>>>>>
>>>>>>> I found that my kernel was not enabling mxc_v4l2_output.  I've enabled this
>>>>>>> and now the result is different, but always failing with:
>>>>>>>    mxc_v4l2_output v4l2_out.32: Bypass IC.
>>>>>>>    Attempt to unlock mutex that was not locked
>>>>>>>
>>>>>>> Do you have an image where this works correctly?  I'd like to try it with
>>>>>>> my kernel on my hardware, etc.
>>>>>>
>>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido
>>>>>>
>>>>>
>>>>> Thanks.  I tried an image for my SabreLite, but it seems to be missing
>>>>> important bits.  This is the image I tried:
>>>>>    http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-multimedia-nitrogen6x.sdcard
>>>>>
>>>>> It doesn't have gst-play-1.0, nor much of anything as far as I can tell.
>>>>> X brings up a terminal window, but I don't see how to run anything else,
>>>>> e.g. chrome?
>>>>>
>>>>> What am I missing?  Perhaps I chose the wrong image?  How do I play a movie
>>>>> using this image (as your comment above says should work)?
>>>>>
>>>>> Thanks again
>>>>>
>>>>
>>>> I tried a different image that has more tools:
>>>>    http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-machine-test-nitrogen6x.sdcard
>>>>
>>>> Sadly, it's working the same as the image(s) I build myself:
>>>>
>>>> root@nitrogen6x:~# export DISPLAY=:0.0
>>>> root@nitrogen6x:~# gst-play-1.0 Vlad+Louise.mp4
>>>> mxc_cam_select_input: input(0) CSI IC MEM
>>>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi0
>>>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi1
>>>> Now playing /home/root/Vlad+Louise.mp4
>>>> [INFO]liProduct 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
>>>> Aborted
>>>>
>>>> Please tell me again how this is working well for your customers?
>>>> What am I doing wrong?
>>>>
>>>> Note: I've tried multiple .mp4 files, with the same results.
>>>>
>>>
>>> I've tracked this down to the gst1.0-fsl-plugin package.
>>> Here's a GDB backktrace from the abort:
>>>
>>> (gdb) bt
>>> #0  0xb6b109d4 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
>>> #1  0xb6b144d4 in __GI_abort () at abort.c:89
>>> #2  0xb6d537e4 in g_mutex_unlock_slowpath (mutex=mutex@entry=0xb39ff460, prev=<optimized out>)
>>>      at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1326
>>> #3  0xb6d542f8 in g_mutex_unlock (mutex=mutex@entry=0xb39ff460)
>>>      at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1349
>>> #4  0xb6d5441c in g_cond_wait (cond=0xfffffffe, cond@entry=0xb49085e4, mutex=0xb39ff460, mutex@entry=0xb49085f0)
>>>      at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1394
>>> #5  0xb31d3a98 in compositor_compositing_thread (compositor=0xb49085d0)
>>>      at /usr/src/debug/gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c:282
>>> #6  0xb6d34be4 in g_thread_proxy (data=0xb4902a30)
>>>      at /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread.c:764
>>> #7  0xb6c27de0 in start_thread (arg=0xb39ff460) at pthread_create.c:338
>>> #8  0xb6bb4fa0 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:89 from /tmp/p0382_root/lib/libc.so.6
>>>
>>> The function in question is:
>>>
>>> static gpointer compositor_compositing_thread (gpointer compositor)
>>> {
>>>    CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>>>
>>>    while (hcompositor->running) {
>>>      COMPOSITOR_WAIT_SURFACE (hcompositor);
>>>      compositor_do_compositing_surface_list (hcompositor);
>>>    }
>>>
>>>    GST_DEBUG ("compositor thread exit");
>>>
>>>    return;
>>> }
>>>
>>> It's failing on the 'COMPOSITOR_WAIT_SURFACE' function, the first time
>>> is is called.
>>>
>>> Anyone know why this might be failing?  Does someone have a working
>>> example of this code - from either fido or current master?
>>>
>>> Thanks
>>>
>>
>> BTW, this patch fixes the problem and I can play my videos with gst-play.
>> Is it correct?
>>
>> Index: gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
>> ===================================================================
>> --- gst1.0-fsl-plugins-4.0.3.orig/plugins/overlay_sink/compositor.c
>> +++ gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
>> @@ -278,6 +278,7 @@ static gpointer compositor_compositing_t
>>   {
>>     CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>>
>> +  g_mutex_lock(&hcompositor->lock);
>>     while (hcompositor->running) {
>>       COMPOSITOR_WAIT_SURFACE (hcompositor);
>>       compositor_do_compositing_surface_list (hcompositor);
>>
>
> "Working" was a bit premature :-(  gst-play does work when I run it
> manually from the command line.  When I run it from the window manager
> (i.e. click on 'media player'), it tries to run now (as opposed to
> quitting immediately), but there is no video shown, only a progress
> bar.
>
> Anyone know what might be the difference when running in these two
> modes?
>

Sorry for all the [rambling] self-followups, but I'm just writing
this because it seems no one else really knows the answers here.

The problem I'm now having is that 'gst-play' works correctly when
rendering to the entire video screen (i.e. when run manually), but
'gtk-play' (which is what is called from the "media player" icon)
is trying to redirect that video to a window on the screen, not
the whole thing and this is what is failing.

Anyone know how to figure out what gstreamer pipeline 'gtk-play'
is constructing?

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

Re: Fido with kernel 3.10.17

[Nikolay Dimitrov]

Hi Gary,

On 05/13/2015 09:31 PM, Gary Thomas wrote:
> On 2015-05-13 12:15, Gary Thomas wrote:
>> On 2015-05-13 11:00, Gary Thomas wrote:
>>> On 2015-05-13 10:16, Gary Thomas wrote:
>>>> On 2015-05-13 08:00, Gary Thomas wrote:
>>>>> On 2015-05-13 07:27, Gary Thomas wrote:
>>>>>> On 2015-05-13 07:07, Otavio Salvador wrote:
>>>>>>> On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <gary@mlbassoc.com>
>>>>>>> wrote:
>>>>>>>> On 2015-05-12 06:59, Otavio Salvador wrote:
>>>>>>>>>
>>>>>>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas
>>>>>>>>> <gary@mlbassoc.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas
>>>>>>>>>>> <gary@mlbassoc.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov
>>>>>>>>>>>>> <picmaster@mail.bg>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gstreamer-1.0 freezes instantly with my test video
>>>>>>>>>>>>>> streams. As I've
>>>>>>>>>>>>>> invested some time in the past to really force
>>>>>>>>>>>>>> gstreamer-0.10 to
>>>>>>>>>>>>>> work,
>>>>>>>>>>>>>> I'm quite reluctant to go forward with gstreamer-1.0,
>>>>>>>>>>>>>> especially when
>>>>>>>>>>>>>> its MPEGTS implementation is, well... half-working. So I'm
>>>>>>>>>>>>>> sticking
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> what I've made to work so far.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Did you try the community plugin? We have been using it
>>>>>>>>>>>>> with several
>>>>>>>>>>>>> customers and in general it is working very well.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Is that not what you would get when running the media player?
>>>>>>>>>>>>
>>>>>>>>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>>>>>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> gst-play-1.0 works.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Not for me on either of the i.MX6 boards I have here :-(  What
>>>>>>>>>> board(s)
>>>>>>>>>> [and kernel] have you tested with?
>>>>>>>>>>
>>>>>>>>>> What did you play?  What is your display device?  Anything else
>>>>>>>>>> you can provide that might help me figure this out...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia
>>>>>>>>> works for
>>>>>>>>> many movies.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I found that my kernel was not enabling mxc_v4l2_output.  I've
>>>>>>>> enabled this
>>>>>>>> and now the result is different, but always failing with:
>>>>>>>>    mxc_v4l2_output v4l2_out.32: Bypass IC.
>>>>>>>>    Attempt to unlock mutex that was not locked
>>>>>>>>
>>>>>>>> Do you have an image where this works correctly?  I'd like to
>>>>>>>> try it with
>>>>>>>> my kernel on my hardware, etc.
>>>>>>>
>>>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido
>>>>>>>
>>>>>>
>>>>>> Thanks.  I tried an image for my SabreLite, but it seems to be
>>>>>> missing
>>>>>> important bits.  This is the image I tried:
>>>>>>
>>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-multimedia-nitrogen6x.sdcard
>>>>>>
>>>>>>
>>>>>> It doesn't have gst-play-1.0, nor much of anything as far as I can
>>>>>> tell.
>>>>>> X brings up a terminal window, but I don't see how to run anything
>>>>>> else,
>>>>>> e.g. chrome?
>>>>>>
>>>>>> What am I missing?  Perhaps I chose the wrong image?  How do I
>>>>>> play a movie
>>>>>> using this image (as your comment above says should work)?
>>>>>>
>>>>>> Thanks again
>>>>>>
>>>>>
>>>>> I tried a different image that has more tools:
>>>>>
>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-machine-test-nitrogen6x.sdcard
>>>>>
>>>>>
>>>>> Sadly, it's working the same as the image(s) I build myself:
>>>>>
>>>>> root@nitrogen6x:~# export DISPLAY=:0.0
>>>>> root@nitrogen6x:~# gst-play-1.0 Vlad+Louise.mp4
>>>>> mxc_cam_select_input: input(0) CSI IC MEM
>>>>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi0
>>>>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi1
>>>>> Now playing /home/root/Vlad+Louise.mp4
>>>>> [INFO]liProduct 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
>>>>> Aborted
>>>>>
>>>>> Please tell me again how this is working well for your customers?
>>>>> What am I doing wrong?
>>>>>
>>>>> Note: I've tried multiple .mp4 files, with the same results.
>>>>>
>>>>
>>>> I've tracked this down to the gst1.0-fsl-plugin package.
>>>> Here's a GDB backktrace from the abort:
>>>>
>>>> (gdb) bt
>>>> #0  0xb6b109d4 in __GI_raise (sig=sig@entry=6) at
>>>> ../sysdeps/unix/sysv/linux/raise.c:55
>>>> #1  0xb6b144d4 in __GI_abort () at abort.c:89
>>>> #2  0xb6d537e4 in g_mutex_unlock_slowpath
>>>> (mutex=mutex@entry=0xb39ff460, prev=<optimized out>)
>>>>      at
>>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1326
>>>>
>>>> #3  0xb6d542f8 in g_mutex_unlock (mutex=mutex@entry=0xb39ff460)
>>>>      at
>>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1349
>>>>
>>>> #4  0xb6d5441c in g_cond_wait (cond=0xfffffffe,
>>>> cond@entry=0xb49085e4, mutex=0xb39ff460, mutex@entry=0xb49085f0)
>>>>      at
>>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1394
>>>>
>>>> #5  0xb31d3a98 in compositor_compositing_thread (compositor=0xb49085d0)
>>>>      at
>>>> /usr/src/debug/gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c:282
>>>>
>>>> #6  0xb6d34be4 in g_thread_proxy (data=0xb4902a30)
>>>>      at
>>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread.c:764
>>>> #7  0xb6c27de0 in start_thread (arg=0xb39ff460) at pthread_create.c:338
>>>> #8  0xb6bb4fa0 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:89
>>>> from /tmp/p0382_root/lib/libc.so.6
>>>>
>>>> The function in question is:
>>>>
>>>> static gpointer compositor_compositing_thread (gpointer compositor)
>>>> {
>>>>    CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>>>>
>>>>    while (hcompositor->running) {
>>>>      COMPOSITOR_WAIT_SURFACE (hcompositor);
>>>>      compositor_do_compositing_surface_list (hcompositor);
>>>>    }
>>>>
>>>>    GST_DEBUG ("compositor thread exit");
>>>>
>>>>    return;
>>>> }
>>>>
>>>> It's failing on the 'COMPOSITOR_WAIT_SURFACE' function, the first time
>>>> is is called.
>>>>
>>>> Anyone know why this might be failing?  Does someone have a working
>>>> example of this code - from either fido or current master?
>>>>
>>>> Thanks
>>>>
>>>
>>> BTW, this patch fixes the problem and I can play my videos with
>>> gst-play.
>>> Is it correct?
>>>
>>> Index: gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
>>> ===================================================================
>>> --- gst1.0-fsl-plugins-4.0.3.orig/plugins/overlay_sink/compositor.c
>>> +++ gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
>>> @@ -278,6 +278,7 @@ static gpointer compositor_compositing_t
>>>   {
>>>     CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>>>
>>> +  g_mutex_lock(&hcompositor->lock);
>>>     while (hcompositor->running) {
>>>       COMPOSITOR_WAIT_SURFACE (hcompositor);
>>>       compositor_do_compositing_surface_list (hcompositor);
>>>
>>
>> "Working" was a bit premature :-(  gst-play does work when I run it
>> manually from the command line.  When I run it from the window manager
>> (i.e. click on 'media player'), it tries to run now (as opposed to
>> quitting immediately), but there is no video shown, only a progress
>> bar.
>>
>> Anyone know what might be the difference when running in these two
>> modes?
>>
>
> Sorry for all the [rambling] self-followups, but I'm just writing
> this because it seems no one else really knows the answers here.
>
> The problem I'm now having is that 'gst-play' works correctly when
> rendering to the entire video screen (i.e. when run manually), but
> 'gtk-play' (which is what is called from the "media player" icon)
> is trying to redirect that video to a window on the screen, not
> the whole thing and this is what is failing.
>
> Anyone know how to figure out what gstreamer pipeline 'gtk-play'
> is constructing?

$ export GST_DEBUG_DUMP_DOT_DIR=/tmp

...and run gst-launch or whatever in the console, the app will create
.dot files in /tmp, which you can convert to PNG files:

$ dot -Tpng -O file.dot

Gstreamer creates graph dumps on each state transition, so you can get
quite useful info.

Regarding the GUI app - there was an option to assign the DUMP DOT DIR
as a compile-time option, thus enforcing the compiled app to always
dump graphs.

More info on the GST debug topic:

http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html

Regards,
Nikolay

Re: Fido with kernel 3.10.17

[Nikolay Dimitrov]

On 05/13/2015 09:46 PM, Nikolay Dimitrov wrote:
> Hi Gary,
>
> On 05/13/2015 09:31 PM, Gary Thomas wrote:
>> On 2015-05-13 12:15, Gary Thomas wrote:
>>> On 2015-05-13 11:00, Gary Thomas wrote:
>>>> On 2015-05-13 10:16, Gary Thomas wrote:
>>>>> On 2015-05-13 08:00, Gary Thomas wrote:
>>>>>> On 2015-05-13 07:27, Gary Thomas wrote:
>>>>>>> On 2015-05-13 07:07, Otavio Salvador wrote:
>>>>>>>> On Wed, May 13, 2015 at 9:57 AM, Gary Thomas <gary@mlbassoc.com>
>>>>>>>> wrote:
>>>>>>>>> On 2015-05-12 06:59, Otavio Salvador wrote:
>>>>>>>>>>
>>>>>>>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas
>>>>>>>>>> <gary@mlbassoc.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas
>>>>>>>>>>>> <gary@mlbassoc.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov
>>>>>>>>>>>>>> <picmaster@mail.bg>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Gstreamer-1.0 freezes instantly with my test video
>>>>>>>>>>>>>>> streams. As I've
>>>>>>>>>>>>>>> invested some time in the past to really force
>>>>>>>>>>>>>>> gstreamer-0.10 to
>>>>>>>>>>>>>>> work,
>>>>>>>>>>>>>>> I'm quite reluctant to go forward with gstreamer-1.0,
>>>>>>>>>>>>>>> especially when
>>>>>>>>>>>>>>> its MPEGTS implementation is, well... half-working. So I'm
>>>>>>>>>>>>>>> sticking
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> what I've made to work so far.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Did you try the community plugin? We have been using it
>>>>>>>>>>>>>> with several
>>>>>>>>>>>>>> customers and in general it is working very well.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is that not what you would get when running the media player?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Do you have an example pipeline that does work, e.g. play a
>>>>>>>>>>>>> complete movie (H264+mp3) in .mp4 container?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> gst-play-1.0 works.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Not for me on either of the i.MX6 boards I have here :-(  What
>>>>>>>>>>> board(s)
>>>>>>>>>>> [and kernel] have you tested with?
>>>>>>>>>>>
>>>>>>>>>>> What did you play?  What is your display device?  Anything else
>>>>>>>>>>> you can provide that might help me figure this out...
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Did you use the gstreamer1.0-imx? The fsl-image-multimedia
>>>>>>>>>> works for
>>>>>>>>>> many movies.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I found that my kernel was not enabling mxc_v4l2_output.  I've
>>>>>>>>> enabled this
>>>>>>>>> and now the result is different, but always failing with:
>>>>>>>>>    mxc_v4l2_output v4l2_out.32: Bypass IC.
>>>>>>>>>    Attempt to unlock mutex that was not locked
>>>>>>>>>
>>>>>>>>> Do you have an image where this works correctly?  I'd like to
>>>>>>>>> try it with
>>>>>>>>> my kernel on my hardware, etc.
>>>>>>>>
>>>>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido
>>>>>>>>
>>>>>>>
>>>>>>> Thanks.  I tried an image for my SabreLite, but it seems to be
>>>>>>> missing
>>>>>>> important bits.  This is the image I tried:
>>>>>>>
>>>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-multimedia-nitrogen6x.sdcard
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> It doesn't have gst-play-1.0, nor much of anything as far as I can
>>>>>>> tell.
>>>>>>> X brings up a terminal window, but I don't see how to run anything
>>>>>>> else,
>>>>>>> e.g. chrome?
>>>>>>>
>>>>>>> What am I missing?  Perhaps I chose the wrong image?  How do I
>>>>>>> play a movie
>>>>>>> using this image (as your comment above says should work)?
>>>>>>>
>>>>>>> Thanks again
>>>>>>>
>>>>>>
>>>>>> I tried a different image that has more tools:
>>>>>>
>>>>>> http://ci.ossystems.com.br/public/fsl-community-bsp/fido/16/x11/nitrogen6x/fsl-image-machine-test-nitrogen6x.sdcard
>>>>>>
>>>>>>
>>>>>>
>>>>>> Sadly, it's working the same as the image(s) I build myself:
>>>>>>
>>>>>> root@nitrogen6x:~# export DISPLAY=:0.0
>>>>>> root@nitrogen6x:~# gst-play-1.0 Vlad+Louise.mp4
>>>>>> mxc_cam_select_input: input(0) CSI IC MEM
>>>>>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi0
>>>>>> mxc_v4l_open: Mxc Camera no sensor ipu1/csi1
>>>>>> Now playing /home/root/Vlad+Louise.mp4
>>>>>> [INFO]liProduct 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
>>>>>> Aborted
>>>>>>
>>>>>> Please tell me again how this is working well for your customers?
>>>>>> What am I doing wrong?
>>>>>>
>>>>>> Note: I've tried multiple .mp4 files, with the same results.
>>>>>>
>>>>>
>>>>> I've tracked this down to the gst1.0-fsl-plugin package.
>>>>> Here's a GDB backktrace from the abort:
>>>>>
>>>>> (gdb) bt
>>>>> #0  0xb6b109d4 in __GI_raise (sig=sig@entry=6) at
>>>>> ../sysdeps/unix/sysv/linux/raise.c:55
>>>>> #1  0xb6b144d4 in __GI_abort () at abort.c:89
>>>>> #2  0xb6d537e4 in g_mutex_unlock_slowpath
>>>>> (mutex=mutex@entry=0xb39ff460, prev=<optimized out>)
>>>>>      at
>>>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1326
>>>>>
>>>>>
>>>>> #3  0xb6d542f8 in g_mutex_unlock (mutex=mutex@entry=0xb39ff460)
>>>>>      at
>>>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1349
>>>>>
>>>>>
>>>>> #4  0xb6d5441c in g_cond_wait (cond=0xfffffffe,
>>>>> cond@entry=0xb49085e4, mutex=0xb39ff460, mutex@entry=0xb49085f0)
>>>>>      at
>>>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread-posix.c:1394
>>>>>
>>>>>
>>>>> #5  0xb31d3a98 in compositor_compositing_thread
>>>>> (compositor=0xb49085d0)
>>>>>      at
>>>>> /usr/src/debug/gst1.0-fsl-plugin/4.0.3-r0/gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c:282
>>>>>
>>>>>
>>>>> #6  0xb6d34be4 in g_thread_proxy (data=0xb4902a30)
>>>>>      at
>>>>> /usr/src/debug/glib-2.0/1_2.44.0-r0/glib-2.44.0/glib/gthread.c:764
>>>>> #7  0xb6c27de0 in start_thread (arg=0xb39ff460) at
>>>>> pthread_create.c:338
>>>>> #8  0xb6bb4fa0 in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:89
>>>>> from /tmp/p0382_root/lib/libc.so.6
>>>>>
>>>>> The function in question is:
>>>>>
>>>>> static gpointer compositor_compositing_thread (gpointer compositor)
>>>>> {
>>>>>    CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>>>>>
>>>>>    while (hcompositor->running) {
>>>>>      COMPOSITOR_WAIT_SURFACE (hcompositor);
>>>>>      compositor_do_compositing_surface_list (hcompositor);
>>>>>    }
>>>>>
>>>>>    GST_DEBUG ("compositor thread exit");
>>>>>
>>>>>    return;
>>>>> }
>>>>>
>>>>> It's failing on the 'COMPOSITOR_WAIT_SURFACE' function, the first time
>>>>> is is called.
>>>>>
>>>>> Anyone know why this might be failing?  Does someone have a working
>>>>> example of this code - from either fido or current master?
>>>>>
>>>>> Thanks
>>>>>
>>>>
>>>> BTW, this patch fixes the problem and I can play my videos with
>>>> gst-play.
>>>> Is it correct?
>>>>
>>>> Index: gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
>>>> ===================================================================
>>>> --- gst1.0-fsl-plugins-4.0.3.orig/plugins/overlay_sink/compositor.c
>>>> +++ gst1.0-fsl-plugins-4.0.3/plugins/overlay_sink/compositor.c
>>>> @@ -278,6 +278,7 @@ static gpointer compositor_compositing_t
>>>>   {
>>>>     CompositorHandle *hcompositor = (CompositorHandle*) compositor;
>>>>
>>>> +  g_mutex_lock(&hcompositor->lock);
>>>>     while (hcompositor->running) {
>>>>       COMPOSITOR_WAIT_SURFACE (hcompositor);
>>>>       compositor_do_compositing_surface_list (hcompositor);
>>>>
>>>
>>> "Working" was a bit premature :-(  gst-play does work when I run it
>>> manually from the command line.  When I run it from the window manager
>>> (i.e. click on 'media player'), it tries to run now (as opposed to
>>> quitting immediately), but there is no video shown, only a progress
>>> bar.
>>>
>>> Anyone know what might be the difference when running in these two
>>> modes?
>>>
>>
>> Sorry for all the [rambling] self-followups, but I'm just writing
>> this because it seems no one else really knows the answers here.
>>
>> The problem I'm now having is that 'gst-play' works correctly when
>> rendering to the entire video screen (i.e. when run manually), but
>> 'gtk-play' (which is what is called from the "media player" icon)
>> is trying to redirect that video to a window on the screen, not
>> the whole thing and this is what is failing.
>>
>> Anyone know how to figure out what gstreamer pipeline 'gtk-play'
>> is constructing?
>
> $ export GST_DEBUG_DUMP_DOT_DIR=/tmp
>
> ...and run gst-launch or whatever in the console, the app will create
> .dot files in /tmp, which you can convert to PNG files:
>
> $ dot -Tpng -O file.dot
>
> Gstreamer creates graph dumps on each state transition, so you can get
> quite useful info.
>
> Regarding the GUI app - there was an option to assign the DUMP DOT DIR
> as a compile-time option, thus enforcing the compiled app to always
> dump graphs.
>
> More info on the GST debug topic:
>
> http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gst-running.html

Here's how to dump the media graph withing the app itself:

http://www.freedesktop.org/software/gstreamer-sdk/data/docs/2012.5/gstreamer-0.10/gstreamer-GstInfo.html#GST-DEBUG-BIN-TO-DOT-FILE:CAPS

Regards,
Nikolay