From patchwork Tue May 3 21:06:06 2005 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Reinhard Nissl X-Patchwork-Id: 11864 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by www.linuxtv.org with smtp (Exim 4.34) id 1DT4bK-0007yX-U9 for vdr@linuxtv.org; Tue, 03 May 2005 23:06:42 +0200 Received: (qmail invoked by alias); 03 May 2005 21:06:11 -0000 Received: from dialin-145-254-231-170.arcor-ip.net (EHLO [192.168.101.15]) [145.254.231.170] by mail.gmx.net (mp025) with SMTP; 03 May 2005 23:06:11 +0200 X-Authenticated: #527675 Message-ID: <4277E7BE.1030003@gmx.de> Date: Tue, 03 May 2005 23:06:06 +0200 From: Reinhard Nissl User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Klaus Schmidinger's VDR Subject: Re: [vdr] xine-vdr NovaT "FIXME: xineDevice.c:1160" References: <1115115214.3406.7.camel@hush> <020701c54fde$f3e19b30$7b95b984@nsctechnology.com> In-Reply-To: <020701c54fde$f3e19b30$7b95b984@nsctechnology.com> X-Y-GMX-Trusted: 0 X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Klaus Schmidinger's VDR List-Id: Klaus Schmidinger's VDR List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2005 21:06:43 -0000 Status: O X-Status: X-Keywords: X-UID: 1905 Hi, Simon Baxter wrote: > I've just setup my WinTV NovaT on a new (2.2Ghz) shuttle PC and built > the xine-plugin components. > > I created a new channels.conf file with scan and ran up VDR > > On some channels I get screens and screens of information like : > FIXME: xineDevice.c:1160 > FIXME: xineDevice.c:970 > FIXME: xineDevice.c:1126 > > I gather each specific XXXX number refers to capability needed on those > specific channels?? > > any ideas? Hhm, each of these locations checks, whether a PES packet starts with the byte sequence 00 00 01, and fails as the packets don't. If you are using a recent VDR (1.3.20 and higher), please have a look at the attached patch. It fixes the so called class cPesAssembler. Does the problem disappear if you record such a channel and then play the 001.vdr file directly with xine? Can you provide me a sample recording (~ 5 MB)? Bye. --- ../vdr-1.3.23-orig/device.c 2005-02-27 14:55:15.000000000 +0100 +++ device.c 2005-05-01 22:59:18.869069399 +0200 @@ -27,6 +27,7 @@ private: uint32_t tag; int length; int size; + bool hasFragment; bool Realloc(int Size); public: cPesAssembler(void); @@ -39,6 +40,7 @@ public: void Put(uchar c); void Put(const uchar *Data, int Length); bool IsPes(void); + bool HasFragment(void); }; cPesAssembler::cPesAssembler(void) @@ -57,6 +59,12 @@ void cPesAssembler::Reset(void) { tag = 0xFFFFFFFF; length = 0; + hasFragment = false; +} + +bool cPesAssembler::HasFragment(void) +{ + return hasFragment || length > 0; } bool cPesAssembler::Realloc(int Size) @@ -67,6 +75,7 @@ bool cPesAssembler::Realloc(int Size) if (!data) { esyslog("ERROR: can't allocate memory for PES assembler"); length = 0; + hasFragment = false; size = 0; return false; } @@ -77,6 +86,7 @@ bool cPesAssembler::Realloc(int Size) void cPesAssembler::Put(uchar c) { if (!length) { + hasFragment = true; tag = (tag << 8) | c; if ((tag & 0xFFFFFF00) == 0x00000100) { if (Realloc(4)) { @@ -985,7 +997,7 @@ int cDevice::PlayPes(const uchar *Data, return 0; } int Result = 0; - if (pesAssembler->Length()) { + if (pesAssembler->HasFragment()) { // Make sure we have a complete PES header: while (pesAssembler->Length() < 6 && Length > 0) { pesAssembler->Put(*Data++);