From patchwork Tue Feb 20 23:18:31 2007 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Reinhard Nissl X-Patchwork-Id: 12440 Received: from mail.gmx.net ([213.165.64.20]) by www.linuxtv.org with smtp (Exim 4.50) id 1HJeHT-0008Kx-5a for vdr@linuxtv.org; Wed, 21 Feb 2007 00:20:19 +0100 Received: (qmail invoked by alias); 20 Feb 2007 23:18:55 -0000 X-Provags-ID: V01U2FsdGVkX195iCAYir55KOxIr7cDHZ7CBZFVtvh0kTIkOxz+xM MuvA== Message-ID: <45DB81C7.20503@gmx.de> Date: Wed, 21 Feb 2007 00:18:31 +0100 From: Reinhard Nissl User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20060911 SUSE/1.5.0.9-0.1 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: VDR Mailing List Subject: Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd) References: <45C24A06.60502@kniivila.com> <45C256AF.6@gmx.de> <45C260B6.7070309@kniivila.com> <45C270FA.7040804@gmx.de> <45D8AD0F.50600@kniivila.com> <45D8DD9A.6050602@gmx.de> <45D97DC8.3030505@kniivila.com> <45DA1020.3090901@gmx.de> <45DB6710.1050308@gmx.de> In-Reply-To: X-Y-GMX-Trusted: 0 X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: VDR Mailing List List-Id: VDR Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Feb 2007 23:20:19 -0000 Status: O X-Status: X-Keywords: X-UID: 12259 Hi, Morfsta wrote: > OK, so Karsta and I are suffering dropped TS packets. I know for sure > that my DVB-T signal is not perfect so it is likely to occasionally lose > some TS packets (freeview in the UK is susceptible to all sorts of > interference from cars, motorbikes, DECT, etc) however, saying there is > nothing that we can do about this because you don't have a *perfect* DVB > signal surely isn't the right answer! My TV copes perfectly well with Well, what I wanted to say is that I cannot help you any further at this point. You have to check your hardware/driver whether there is a chance to minimize packet loss. You did this already as you wrote below -- fine. > dropped packets and doesn't go out of sync, as does my freeview box. > Surely if some TS packets are dropped this shouldn't result in a loss of > sync, the system should resync the audio and continue as before?? It > can't be right to say, well we lost some data, so we can't recover until > you change channels up and down, or fastforward/rewind by 1 minute! You are right -- but don't you think that this thread got a bit off topic? I've replied in this thread because there were cAudioRepacker messages and as I've contributed this code to VDR I just wanted to make sure that it works correctly in this case. Let's now come back to the topic and concentrate on the AV sync issue. > I have spent the last 2 weeks trying different combinations, playing > with my kernel settings, trying USB DVB-T devices rather than the PCI > and it makes absolutely no difference. The TS continuity errors do not > go away so I am convinced it is simply that DVB-T is not as robust as > other signals such as DVB-S or DVB-C. However, VDR should be able to > cope and resync with lost data. Well, basically this is not a matter of VDR but of the FF card's firmware. For example, I do not own a FF card and do not see this AV sync issue with xine, even when I intentionally drop TS packets by the attached patch. I'd like users of FF cards to test this patch. If this triggers AV sync issues, firmware developers are invited to fix this issue. Feel free to modify this patch to better simulate real TS packet losses like bursts of 16 frames. BE WARNED: *** do not use this patch on a production system *** Bye. --- ../vdr-1.4.5-orig/remux.c 2006-12-01 15:46:25.000000000 +0100 +++ remux.c 2007-02-21 00:06:03.000000000 +0100 @@ -1805,7 +2278,7 @@ void cTS2PES::instant_repack(const uint8 { if (!Buf) return; - +if ((rand() * 100.0 / RAND_MAX) <= 0.05) return; // cause 0.05 % TS packet loss if (Buf[1] & TS_ERROR) tsErrors++;