From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 1164BE008CF; Tue, 18 Nov 2014 07:06:33 -0800 (PST) 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.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-HAM-Report: * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (picmaster[at]mail.bg) * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [193.201.172.117 listed in list.dnswl.org] * -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 mx1.mail.bg (mx1.mail.bg [193.201.172.117]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 4F537E007C0 for ; Tue, 18 Nov 2014 07:06:28 -0800 (PST) Received: from [192.168.0.41] (unknown [93.152.132.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.mail.bg (Postfix) with ESMTPSA id 102916001602; Tue, 18 Nov 2014 17:06:25 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1416323186; bh=wyNEV2ZYuNAMtp+Mtwjx/4gHuFiOglZaTmDJKRg7iYs=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=4TedmYOHMb95Xgnd9Ii6BEzBwXgw0RzbFLxH2HHG7KAS/vkCChn2uAvkuZRpl4BFw dsm5pkPNUz3ltCq8ou9EGq4HxEHUJNXWNNlEfFP0VyI5aJjPC2wxn0rmjdfh2P4N5K NMjtW+da3XIzQtNJjsy00h2pCBsioiILatSCTvJ0= Message-ID: <546B6071.9060409@mail.bg> Date: Tue, 18 Nov 2014 17:06:25 +0200 From: Nikolay Dimitrov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.2.0 MIME-Version: 1.0 To: Marco Trillo References: <54664E1A.50009@mail.bg> <5467DB7F.1000604@mail.bg> <546B2700.2020300@arantia.com> In-Reply-To: <546B2700.2020300@arantia.com> Cc: "meta-freescale@yoctoproject.org" Subject: Re: [dizzy] Choppy gstreamer video (MPEG TS over UDP) 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, 18 Nov 2014 15:06:33 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Marco, On 11/18/2014 01:01 PM, Marco Trillo wrote: > Hi Nikolay, > > On 11/16/2014 12:02 AM, Nikolay Dimitrov wrote: >> Playbin was very unstable for most of my tests (either refuses to play >> stream at all, or freezes on 1st or consequent frames). Then I started >> to use decodebin to have more control of the pipeline, and more stable >> results (to some minimal extent). > > We have been doing extensive tests with MPEG-TS streaming over UDP and > RTP with GStreamer 0.10, and we agree with your results. > Playbin2 is unrealible for UDP or RTP streaming. However, I don't think > using "decodebin2" will be an improvement -- it is better to build the > full pipeline manually. Yes. I went to use decodebin just to be able to force the usage of udpsrc in multicast mode, because I was not sure what was actually happening inside playbin2. But tend to agree that custom pipelines (and even C-application) are the way to go. > That way you can configure your elements individually. In particular, we > found that setting the `low-latency' property to true in `vpudec' and > the `qos' property to false in `aiurdemux' provided better results. "low-latency" definitely lowers the time to display 1st frame (< 1s), but need to test whether it affects long-term stability. Hope to be able to test soon "qos" property. > Also, RTP streaming worked much better for us than raw UDP. It's quite possible. Unfortunately, RTP this is not an option for me at the moment. >> Most, if not all of these examples are hard to be applied in my case: >> my customer has already deployed infrastructure for the previous >> product generation, where they use MPEG-TS transport over multicast >> UDP, and I can't deviate from that. Also currently gstreamer-0.10 just >> doesn't support multicast, that's why I'm testing on unicast for now, >> and will have to fix the multicast bug soon. > > gstreamer-0.10 does support multicast perfectly well: consult the > `multicast-group' and `port' properties of `udpsrc' for more information > (with gst-inspect). > > Make sure your kernel has the multicast support enabled: > # zcat /proc/config.gz | grep -i multicast > > For some reason, the default config for some kernels (linux-wandboard > and linux-boundary IIRC) doesn't enable multicast. Yep, I also found this out the hard way. After enabling the CONFIG_IP_MULTICAST it's much better now. I can't remember exactly what was the error message I saw several days ago, but it was something like: "added **something**: -1, Not found" So this is why I said that the multicast didn't worked out of the box. Obviously, I wasn't right and now it works. But I can't reproduce this error message anymore. >>> Another thing, your network does matter, a lot! So start with a local >>> network or even ppp. >> >> Totally agree. I'm using Gigabit LAN, which is dedicated to this >> development. Also, when deployed, the final product will also run on >> dedicated network segments with dedicated media servers, so I don't >> expect issues with that. > > Yes; as said, we found the same choppy playback results and the network > was perfectly fine. An alternative client (FFMPEG or VLC) worked fined > at the same point. Same here, tests performed with ffmpeg & vlc on x86 machines showed that at least the TS stream and LAN network were OK. Regards, Nikolay