[meta-freescale] Fido with kernel 3.10.17
Nikolay Dimitrov
picmaster at mail.bg
Wed May 13 11:48:56 PDT 2015
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 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.
>
> 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
More information about the meta-freescale
mailing list