From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 6BDC8E008EC; Tue, 18 Nov 2014 03:07:50 -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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-HAM-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Greylist: delayed 382 seconds by postgrey-1.32 at yocto-www; Tue, 18 Nov 2014 03:07:46 PST Received: from mailext0.televes.com (mailext0.televes.com [212.163.42.140]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id B37C3E008D7 for ; Tue, 18 Nov 2014 03:07:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailext0.televes.com (Postfix) with ESMTP id 6CFDE9A4029; Tue, 18 Nov 2014 12:01:22 +0100 (CET) X-Virus-Scanned: by amavisd-new at mailext0.televes.com Received: from mailext0.televes.com ([127.0.0.1]) by localhost (mailext0.televes.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqUZIZEwXbbn; Tue, 18 Nov 2014 12:01:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mailext0.televes.com (Postfix) with ESMTP id 33B859A4033; Tue, 18 Nov 2014 12:01:22 +0100 (CET) Received: from tves0.televes.com (tvesbackup0 [212.163.42.137]) by mailext0.televes.com (Postfix) with ESMTP id 1E5DA9A4029; Tue, 18 Nov 2014 12:01:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by tves0.televes.com (Postfix) with ESMTP id BE068F8DA2121; Tue, 18 Nov 2014 12:01:21 +0100 (CET) Received: from arantia1.arantia.com (ARANTIA0.televes.com [192.168.178.2]) by tves0.televes.com (Postfix) with ESMTP id B8A99F8DA2120; Tue, 18 Nov 2014 12:01:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by arantia1.arantia.com (Postfix) with ESMTP id 9328517CDF37; Tue, 18 Nov 2014 12:01:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by arantia1.arantia.com (Postfix) with ESMTP id 70FEC161DCAF; Tue, 18 Nov 2014 12:01:21 +0100 (CET) Received: from arantia1.arantia.com ([127.0.0.1]) by localhost (arantia0 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24764-05; Tue, 18 Nov 2014 12:01:20 +0100 (CET) Received: from [192.168.178.108] (unknown [192.168.178.108]) by arantia1.arantia.com (Postfix) with ESMTP id 02E4F17CDF37; Tue, 18 Nov 2014 12:01:19 +0100 (CET) Message-ID: <546B2700.2020300@arantia.com> Date: Tue, 18 Nov 2014 12:01:20 +0100 From: Marco Trillo User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Nikolay Dimitrov References: <54664E1A.50009@mail.bg> <5467DB7F.1000604@mail.bg> In-Reply-To: <5467DB7F.1000604@mail.bg> 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 11:07:50 -0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. 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. Also, RTP streaming worked much better for us than raw UDP. > > 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. > >> 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. Kind regards, Marco.