From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 04021E007C0; Wed, 19 Nov 2014 13:46:05 -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 5B17CE0071C for ; Wed, 19 Nov 2014 13:45:56 -0800 (PST) Received: from [192.168.0.40] (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 073C560009D5; Wed, 19 Nov 2014 23:45:53 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=mail.bg; s=default; t=1416433554; bh=RGAcsV9tp3HKbJG87jeVdLUs7VqJHdYFtSEnSTvahBw=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Li1cjioPaJJ3erLQ1zj+gCvnfC9HJrqasSYN4Mih+Xnuy3Mns5VsHyom3sz2Y2A/x bGDZQH1hhYoehqXBqnIdEJYyBmzvaGv2nUsTQ0lQxHs77FzBm8FJ834U+9dmP00rzm bjYRqtybBxrsO1QsQ8o2OLICU6qLTz/JW43Csck0= Message-ID: <546D0F91.5050204@mail.bg> Date: Wed, 19 Nov 2014 23:45:53 +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> <546B6071.9060409@mail.bg> <546C4860.2040605@arantia.com> In-Reply-To: <546C4860.2040605@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: Wed, 19 Nov 2014 21:46:05 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Marco, On 11/19/2014 09:36 AM, Marco Trillo wrote: > Hi, > > On 11/18/2014 04:06 PM, Nikolay Dimitrov wrote: >>> 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. > > One small correction: the `qos' property belongs to the video sink (we > are using `mfw_v4lsink'), not to `aiurdemux' as I said in my first > e-mail... Thanks for the clarification. > Regarding the time-to-first-frame you mention, we are also running in a > big show-stopper issue with `aiurdemux': depending on the number of PIDs > present in the program table -- for example if the program contains > subtitles or multiple audio streams --, the demuxer takes a long, long > time to provide the pads. Only in relatively simple programs (one audio > and one video PID) the demuxer seems to behave right. Well, I actually ditched aiurdemux and started using the latest Fluendo's MPEG TS demuxer. I can't say with confidence that it's the best solution, but at least it allows me to go forward. I personally think that the amount of available programs and elementary streams in the MPEG TS is not an issue at all. The PAT is transmitted regularly (at most on 140ms), in order to reduce the "time to 1st acquisition". Also PMTs are sent regularly. The problem is actually how the control packets trigger the additional demuxer logic. For example, I noticed is that the Fluendo MPEG TS demuxer rely for some reason on the regular update of PAT/PMT/CAT tables with the current_next_indicator bit. The streams I have access to doesn't update this bit regularly (if at all), that's why the demuxer waits practically for inifinity before demuxing packets. What I did as an experiment was to force the parsing of PAT/PMT/CAT table disregarding this update bit, and suddenly the demuxer started to work quickly. > It is quite possible this is not an issue for you if you control the > source stream. In any case, more information is available at: > Thanks, this was definitely useful info, and a very good remark - mapping tables just describe relations between children and parent logical streams, but packets of the actual streams (including PMT) can start to arrive much later, so the demuxer should always work with whatever is available *now*, not after 15min when the user is dead from boredom :D. In the end, I still have issues with the Gstreamer pipeline stability with network streams - it sometimes freezes either for a while (1-3s), or fully, begging for Ctrl-C. I plan to look at whether some of the pipeline elements are mutually blocking each other, causing a deadlock. Kind regards, Nikolay PS: Please forgive me if someone feels this is going too off-topic.