From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id B2A2CE009DA; Tue, 19 May 2015 04:10:12 -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 EA744E009B6 for ; Tue, 19 May 2015 04:10:10 -0700 (PDT) Received: from [192.168.0.63] (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 E74E26000872; Tue, 19 May 2015 14:10:09 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1432033810; bh=BqkJPP32Si8BG1UgeRMYJ4vbVPkodIxeQCKeFhucNeY=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MZw8dC7TLsNZvhJ+H9AxrZArNMvaNpz3A4E12BRRd41bX9iA0/aj6Rdp191BFEfWJ Mo6eRn9hGo/VaQzbKzkkY8YtMw6/Cx9xGMlHzgAqivl/u/htnGnOpH3GKlJHQoi7Ha sSUZPcjy0MkoQlQwfawSVZk7UMb/c8ngbwHy5PxI= Message-ID: <555B1A11.5000500@mail.bg> Date: Tue, 19 May 2015 14:10:09 +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: <555979FE.50306@satel.pl> <5559A04D.5080500@mail.bg> <5559D536.5030206@mlbassoc.com> <555A0B81.3090905@mail.bg> <555A130C.9060605@mlbassoc.com> <555A7B5B.90906@mail.bg> <555B1634.9050003@gmail.com> <555B18AB.4080403@mail.bg> In-Reply-To: <555B18AB.4080403@mail.bg> Subject: Re: imxipuvideosink in 3.10.53 on Nitrogex6xlite 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: Tue, 19 May 2015 11:10:12 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 05/19/2015 02:04 PM, Nikolay Dimitrov wrote: > Hi Gary, > > On 05/19/2015 01:53 PM, Gary Thomas wrote: >> On 2015-05-18 17:52, Nikolay Dimitrov wrote: >>> Ho Gary, >>> >>> On 05/18/2015 07:27 PM, Gary Thomas wrote: >>>> On 2015-05-18 09:55, Nikolay Dimitrov wrote: >>>>> Hi Gary, >>>>> >>>>> On 05/18/2015 03:04 PM, Gary Thomas wrote: >>>>>> On 2015-05-18 02:18, Nikolay Dimitrov wrote: >>>>>>> Hi Pawel, >>>>>>> >>>>>>> On 05/18/2015 08:34 AM, Paweł Żabiełowicz wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I'm having some problems running video playback on Nitrogen6x-Lite. >>>>>>>> I'm >>>>>>>> using fido with 3.10.53 kernel. Display is running properly as I >>>>>>>> see a >>>>>>>> console after start, but starting any simple video with >>>>>>>> Gstreamer1.0 + >>>>>>>> gstreamer-imx plugins does not give any video output, even though >>>>>>>> the >>>>>>>> decoding looks like it's working. >>>>>>>> >>>>>>>> Gstreamer log: >>>>>>>> gst-launch-1.0 rtspsrc location=rtsp://watch:watch13579 >>>>>>>> 192.168.7.24:554/profile3/media.smp ! rtph264depay ! imxvpudec ! >>>>>>>> imxipuvideosink >>>>>>>> [INFO] Product Info: i.MX6Q/D/S >>>>>>>> Pipeline is live and does not need PREROLL ... >>>>>>>> Progress: (open) Opening Stream >>>>>>>> Progress: (connect) Connecting to >>>>>>>> rtsp://192.168.7.24:554/profile3/media.smp >>>>>>>> Progress: (open) Retrieving server options >>>>>>>> Progress: (open) Retrieving media info >>>>>>>> Progress: (request) SETUP stream 0 >>>>>>>> Progress: (request) SETUP stream 1 >>>>>>>> Progress: (open) Opened Stream >>>>>>>> Setting pipeline to PLAYING ... >>>>>>>> New clock: GstSystemClock >>>>>>>> Progress: (request) Sending PLAY request >>>>>>>> Progress: (request) Sending PLAY request >>>>>>>> Progress: (request) Sent PLAY request >>>>>>>> ^Chandling interrupt. >>>>>>>> Interrupt: Stopping pipeline ... >>>>>>>> Execution ended after 0:00:15.125067669 >>>>>>>> Setting pipeline to PAUSED ... >>>>>>>> Setting pipeline to READY ... >>>>>>>> Setting pipeline to NULL ... >>>>>>>> Freeing pipeline ... >>>>>>>> >>>>>>>> Plugins installed: >>>>>>>> >>>>>>>> gst-inspect-1.0 | grep imx >>>>>>>> imxipu: imxipuvideotransform: Freescale IPU video transform >>>>>>>> imxipu: imxipuvideosink: Freescale IPU video sink >>>>>>>> imxvpu: imxvpudec: Freescale VPU video decoder >>>>>>>> imxvpu: imxvpuenc_h263: Freescale VPU h.263 video encoder >>>>>>>> imxvpu: imxvpuenc_h264: Freescale VPU h.264 video encoder >>>>>>>> imxvpu: imxvpuenc_mpeg4: Freescale VPU MPEG-4 video encoder >>>>>>>> imxvpu: imxvpuenc_mjpeg: Freescale VPU motion JPEG video encoder >>>>>>>> imxg2d: imxg2dvideosink: Freescale G2D video sink >>>>>>>> imxg2d: imxg2dvideotransform: Freescale G2D video transform >>>>>>>> imxaudio: imxuniaudiodec: Freescale i.MX uniaudio decoder >>>>>>>> imxv4l2src: imxv4l2src: V4L2 CSI Video Source >>>>>>>> imxpxp: imxpxpvideosink: Freescale PxP video sink >>>>>>>> imxpxp: imxpxpvideotransform: Freescale PxP video transform >>>>>>>> imxeglvivsink: imxeglvivsink: Freescale EGL video sink >>>>>>>> >>>>>>>> While using imxeglvivsink I'm seeing red flash for few milliseconds >>>>>>>> over >>>>>>>> the console and that's it. >>>>>>>> Any advices will be helpful. >>>>>>> >>>>>>> Please download this file and try a local file playback, to >>>>>>> eliminate >>>>>>> possible networking issues: >>>>>>> >>>>>>> https://download.blender.org/durian/trailer/sintel_trailer-1080p.mp4 >>>>>>> >>>>>>> Also, please check whether an automatically constructed pipeline is >>>>>>> able to play the file above: >>>>>>> >>>>>>> gst-launch-1.0 playbin uri=file:///sintel_trailer-1080p.mp4 >>>>>>> >>>>>>> You can try same tests with Xorg running. >>>>>> >>>>>> What would that pipeline look like (to force the result into a window >>>>>> on the screen)? As is, this simple command takes over the entire >>>>>> screen. >>>>> >>>>> The automatically generated pipeline depends entirely on the media >>>>> itself and the set of plugins you have installed - playbin/decodebin >>>>> and friends are looking at the stream properties and searching for the >>>>> plugin with the highest rank which can be plugged there. The best >>>>> place >>>>> to look at is usually the media graphs (.dot files) after playbin was >>>>> able to play something (I do this regularly, as my pipelines are >>>>> usually worse than the ones created by playbin). >>>> >>>> I tried interpreting these files and since I don't do it all the time >>>> (like you)it was hard for me to see the whole picture. Is it possible >>>> to look at such a graph and write something equivalent that could be >>>> run via gst-launch? >>>> >>>> Here's my graph in case you can make any sense of it. >>> >>> Not sure that the following will help much, but at least I can share >>> what I know, so we can be in the same boat... >>> >>> Please look at the demuxer (qtdemux0), notice that the lower 2 source >>> pads are denoted with dashed lines, which means these pads are dynamic, >>> e.g. doesn't exist all the time (there are more components with dynamic >>> pads in this pipeline). >>> >>> What happens is that after playback start, the demuxer only consumes >>> data for a while and doesn't have any output pads. When the demuxer >>> understands what logical streams are carried over the transport, it >>> dynamically creates a number of source pads, one for each supported >>> content type (usually for video/audio/subs, but can be more). >>> >>> When the demuxer's dynamic pads are created, the pipeline emits events, >>> and the parent element (decodebin0) catches these events, looks for >>> appropriate decoding elements, and attaches them to the pipeline >>> dynamically. >>> >>> The trouble with these dynamic pipelines is that you can't refer to the >>> source/sink pads of the elements before the pipeline is created, which >>> means you can't construct a working dynamic pipeline from the command >>> line. I looked how to do this, but couldn't find a solution. If someone >>> knows how to do this, would be great to share. >>> >>> So the only way I know to create fully custom dynamic pipelines (e.g. >>> driven by the content) is via source code, otherwise we have to use >>> automated bins like playbin/decodebin, and give them some parameters. >> >> Thanks for the explanation, perhaps it can help someone fix this. My >> guess is that the FSL plugin doesn't handle those dynamic elements and >> thus is not equipped to set up the render in the appropriate window on >> the screen. >> >>> >>>> >>>>> >>>>> Also the full-screen behavior depends the videosink configuration, so >>>>> hard to give universal answer, as none will fit all cases. > > I doubt that the issue is caused exactly by the GstImxVpuDec or > GstOverlaySink, as by looking at your pipeline they seem to have static > pads. So it's more of how the playbin/decodebin bins handle the pipeline > creation process... Sorry for this, icedove sent my mail by displaying a pop-up dialog while I was pressing Enter for a new line... Here's a small trick - you can hint playbin about what video sink element you want to use, regardless of the element ranks and capabilities: gst-launch playbin uri=file:///test.mp4 video-sink="myvideosink option=value" So you can enforce you video sink preferences even on automated pipelines. Regards, Nikolay