[meta-freescale] Fido with kernel 3.10.17

Wed May 13 11:46:10 PDT 2015

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 at mlbassoc.com>
>>>>>>> wrote:
>>>>>>>> On 2015-05-12 06:59, Otavio Salvador wrote:
>>>>>>>>>
>>>>>>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas
>>>>>>>>> <gary at mlbassoc.com> wrote:
>>>>>>>>>>
>>>>>>>>>> On 2015-05-12 06:48, Otavio Salvador wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas
>>>>>>>>>>> <gary at mlbassoc.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov
>>>>>>>>>>>>> <picmaster at 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 at nitrogen6x:~# export DISPLAY=:0.0
>>>>> root at 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 at 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 at 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 at 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 at entry=0xb49085e4, mutex=0xb39ff460, mutex at 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.