From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 941E5E0095C; Wed, 13 May 2015 11:48:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low * trust * [193.201.172.118 listed in list.dnswl.org] * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mx2.mail.bg (mx2.mail.bg [193.201.172.118]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id CEE83E00820 for ; Wed, 13 May 2015 11:48:57 -0700 (PDT) Received: from [192.168.0.62] (unknown [93.152.143.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx2.mail.bg (Postfix) with ESMTPSA id 4C5226000F82; Wed, 13 May 2015 21:48:56 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1431542936; bh=PcuN6YgTG+fJl9+v9EUDYq4Bv/p+jB5QPZSy2whjIPM=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=7SB4mTqcJg1P0S/8la8OfOdqBS+oEdudI15S333wYkoktRTsyCCjBudcJpaA2v+yR ma3R+XdP/oUTfETEFgseSfJvehLyGjnv9Oy/BqK7PKu/DppvtTidqv5AbVYGNEtTdP PK4nv/S74ZmYWroJGGEI/HvPmHiAFu7qYxJjyB5M= Message-ID: <55539C98.4050001@mail.bg> Date: Wed, 13 May 2015 21:48:56 +0300 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0 MIME-Version: 1.0 To: Gary Thomas , meta-freescale@yoctoproject.org References: <554B7546.8050202@mail.bg> <554B764F.9080206@mlbassoc.com> <554B83B2.3000607@mail.bg> <554B84EF.9080108@mlbassoc.com> <554B8721.6050302@mail.bg> <5551E54E.3060504@mail.bg> <5551E881.6060602@mlbassoc.com> <5551F196.5070401@mail.bg> <5551F65B.8020005@mlbassoc.com> <5551F7CF.6020906@mlbassoc.com> <55534A22.5030900@mlbassoc.com> <5553514A.1030609@mlbassoc.com> <555358E3.7000304@mlbassoc.com> <555378E2.6010402@mlbassoc.com> <55538316.3040901@mlbassoc.com> <555394BC.5000903@mlbassoc.com> <55539867.4090609@mlbassoc.com> <55539BF2.1050200@mail.bg> In-Reply-To: <55539BF2.1050200@mail.bg> Subject: Re: Fido with kernel 3.10.17 X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 18:48:59 -0000 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 >>>>>>>> wrote: >>>>>>>>> On 2015-05-12 06:59, Otavio Salvador wrote: >>>>>>>>>> >>>>>>>>>> On Tue, May 12, 2015 at 9:53 AM, Gary Thomas >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On 2015-05-12 06:48, Otavio Salvador wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Tue, May 12, 2015 at 9:47 AM, Gary Thomas >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2015-05-12 06:43, Otavio Salvador wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, May 12, 2015 at 9:27 AM, Nikolay Dimitrov >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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=) >>>>> 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