Message ID | 4DECD4E0.8010509@libertysurf.fr |
---|---|
State | New |
Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.69) (envelope-from <fce.valeins@libertysurf.fr>) id 1QTZmq-00056I-5i for vdr@linuxtv.org; Mon, 06 Jun 2011 15:24:08 +0200 X-tubIT-Incoming-IP: 193.50.104.34 Received: from othello.rmsb.u-bordeaux2.fr ([193.50.104.34]) by mail.tu-berlin.de (exim-4.75/mailfrontend-2) with esmtp for <vdr@linuxtv.org> id 1QTZmp-0002eT-Ij; Mon, 06 Jun 2011 15:24:08 +0200 Received: from othello.rmsb.u-bordeaux2.fr (localhost [127.0.0.1]) by othello.rmsb.u-bordeaux2.fr (Postfix RMSB) with ESMTP id 9EBFB12CCB2 for <vdr@linuxtv.org>; Mon, 6 Jun 2011 15:24:03 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on Othello.rmsb.u-bordeaux2.fr X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.0 X-Sagator-Scanner: 1.2.0-1 at Othello; log(status(report(drop(quarantine(ParseMail(file_type()), alternatives(clamd()))))), status(drop(quarantine(SpamAssassinD())))) X-Sagator-ID: 20110606-152403-0001-05290-oY73dH@Othello Received: by othello.rmsb.u-bordeaux2.fr (Postfix RMSB, from userid 12461) id 9165312CCB8; Mon, 6 Jun 2011 15:24:03 +0200 (CEST) Received: from [192.168.10.103] (echo.rmsb.u-bordeaux2.fr [193.50.104.33]) by othello.rmsb.u-bordeaux2.fr (Postfix RMSB) with ESMTP id 7033C12CCB2 for <vdr@linuxtv.org>; Mon, 6 Jun 2011 15:24:03 +0200 (CEST) Message-ID: <4DECD4E0.8010509@libertysurf.fr> Date: Mon, 06 Jun 2011 15:23:44 +0200 From: Senufo <fce.valeins@libertysurf.fr> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10 MIME-Version: 1.0 To: vdr@linuxtv.org References: <mailman.5.1307181601.28750.vdr@linuxtv.org> In-Reply-To: <mailman.5.1307181601.28750.vdr@linuxtv.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.6.6.131216 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' FROM_NAME_ONE_WORD 0.05, MSGID_ADDED_BY_MTA 0.05, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __SANE_MSGID 0, __SUBJECT_ENDING_IN_LATIN_OR_NUMERALS 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_PATH 0, __URI_NS , __URI_NS_NOANSWER , __USER_AGENT 0' X-LSpam-Score: -4.8 (----) X-LSpam-Report: No, score=-4.8 required=5.0 tests=AWL=1.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4 autolearn=ham Subject: Re: [vdr] Weird recording problem X-BeenThere: vdr@linuxtv.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: VDR Mailing List <vdr@linuxtv.org> List-Id: VDR Mailing List <vdr.linuxtv.org> List-Unsubscribe: <http://www.linuxtv.org/cgi-bin/mailman/options/vdr>, <mailto:vdr-request@linuxtv.org?subject=unsubscribe> List-Archive: <http://www.linuxtv.org/pipermail/vdr> List-Post: <mailto:vdr@linuxtv.org> List-Help: <mailto:vdr-request@linuxtv.org?subject=help> List-Subscribe: <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>, <mailto:vdr-request@linuxtv.org?subject=subscribe> X-List-Received-Date: Mon, 06 Jun 2011 13:24:08 -0000 Status: O X-Status: X-Keywords: X-UID: 24804 |
Commit Message
Senufo
June 6, 2011, 1:23 p.m. UTC
Hi, It's the same problem I had in France with the channel TNT "France 4". I proposed this dirty patch in May 2010, without understanding why : I use it since without problem. Senufo > Date: Fri, 03 Jun 2011 22:33:53 +0200 > From: Johan Andersson<jna@jna.pp.se> > Subject: Re: [vdr] Weird recording problem > To: vdr@linuxtv.org > Message-ID:<4DE94531.2010103@jna.pp.se> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > Klaus, > > I got a new reply from Teracom, where they had looked into this and > could not see any problem on their end. They did say they had recently > changed coding platform for TV6 though but it produced correct codes. > > So, I did some further analysis of this, and I believe now the error is > in vdr/remux.c. > > It seems the 'new coding platform', before an I-frame, always puts the > picture startcode, ie '00000100' at the end of the TS packet. This means > that the code: > > independentFrame = ((Data[i + 2]>> 3)& 0x07) == 1; // I-Frame > > looks at the wrong byte, as i+2> TS_SIZE > > For non-I frames it can appear anywhere in the packet. The idea seems to > be that an I-frame is always at the start of a TS-packet, do not ask me why. > > So, your instinct of rejecting my suggestion for a patch was correct. > > I have sample TS data of this stream, or dvbsnoop output of the relevant > PID, if you are interested. > > /Johan > > > Johan Andersson skrev 2011-05-29 19:14: >> [...] >> I got a very positive sounding response from Teracom. I got the >> impression they are really going to fix this. For anyone else interested >> I simply mailed their support address on their homepage >> http://www.teracom.se, ie: kundtjanst@teracom.se >> >> >> /Johan >> >> >> Klaus Schmidinger skrev 2011-05-28 23:55: >>> On 28.05.2011 10:57, Johan Andersson wrote: >>>> >>>> I sent off a question to customer support at Teracom and got a reply >>>> indicating that they do have an error relating to these channels in >>>> their 'coding platform'. >>> >>> Thanks for actually doing this - finally a broadcaster who at >>> least admits *they* have a problem ;-) >>> >>>> 'Your problem seems to relate to the error we have', was their >>>> statement. They had no due date for fixing it though. >>> >>> Maybe they would give this more priority if more people contacted >>> them about this. Once replying to inquiries takes up a considerable >>> amount of their time, they might consider doing something about it. >>> Perhaps you should post here how to contact them, so other viewers >>> of their channels could also bother them ;-) >>> >>> Klaus >>> > >
Comments
Yes, I have a similar patch and it works nicely too. It's just that it does not work for the reason I thought, namely that the stream held an illegal code. I think it works because it detects that the starting code is at the end of a packet and this stream always starts an I-frame in the next packet when the '00000100' is at the end of this packet. That is 'i+2 > TS_SIZE' meaning Data[i+2] is before the payload of the next packet. This is what I currently believe. /Johan Senufo skrev 2011-06-06 15:23: > Hi, > > It's the same problem I had in France with the channel TNT "France 4". I > proposed this dirty patch in May 2010, without understanding why : > > --- remux.c 2010-05-04 14:55:50.000000000 +0200 > +++ remux.c.orig 2010-05-04 21:57:38.000000000 +0200 > @@ -960,6 +960,7 @@ > return Processed; // flush everything before this new frame > newFrame = true; > independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1; // I-Frame > + if (((Data[i + 2] >> 3) & 0x07) == 0) { independentFrame = 1;} > if (synced) { > if (framesPerPayloadUnit <= 1) > scanning = false; > > I use it since without problem. > > Senufo > >> Date: Fri, 03 Jun 2011 22:33:53 +0200 >> From: Johan Andersson<jna@jna.pp.se> >> Subject: Re: [vdr] Weird recording problem >> To: vdr@linuxtv.org >> Message-ID:<4DE94531.2010103@jna.pp.se> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >> >> Klaus, >> >> I got a new reply from Teracom, where they had looked into this and >> could not see any problem on their end. They did say they had recently >> changed coding platform for TV6 though but it produced correct codes. >> >> So, I did some further analysis of this, and I believe now the error is >> in vdr/remux.c. >> >> It seems the 'new coding platform', before an I-frame, always puts the >> picture startcode, ie '00000100' at the end of the TS packet. This means >> that the code: >> >> independentFrame = ((Data[i + 2]>> 3)& 0x07) == 1; // I-Frame >> >> looks at the wrong byte, as i+2> TS_SIZE >> >> For non-I frames it can appear anywhere in the packet. The idea seems to >> be that an I-frame is always at the start of a TS-packet, do not ask >> me why. >> >> So, your instinct of rejecting my suggestion for a patch was correct. >> >> I have sample TS data of this stream, or dvbsnoop output of the relevant >> PID, if you are interested. >> >> /Johan >> >> >> Johan Andersson skrev 2011-05-29 19:14: >>> [...] >>> I got a very positive sounding response from Teracom. I got the >>> impression they are really going to fix this. For anyone else interested >>> I simply mailed their support address on their homepage >>> http://www.teracom.se, ie: kundtjanst@teracom.se >>> >>> >>> /Johan >>> >>> >>> Klaus Schmidinger skrev 2011-05-28 23:55: >>>> On 28.05.2011 10:57, Johan Andersson wrote: >>>>> >>>>> I sent off a question to customer support at Teracom and got a reply >>>>> indicating that they do have an error relating to these channels in >>>>> their 'coding platform'. >>>> >>>> Thanks for actually doing this - finally a broadcaster who at >>>> least admits *they* have a problem ;-) >>>> >>>>> 'Your problem seems to relate to the error we have', was their >>>>> statement. They had no due date for fixing it though. >>>> >>>> Maybe they would give this more priority if more people contacted >>>> them about this. Once replying to inquiries takes up a considerable >>>> amount of their time, they might consider doing something about it. >>>> Perhaps you should post here how to contact them, so other viewers >>>> of their channels could also bother them ;-) >>>> >>>> Klaus >>>> >> >> > > > _______________________________________________ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > . >
--- remux.c 2010-05-04 14:55:50.000000000 +0200 +++ remux.c.orig 2010-05-04 21:57:38.000000000 +0200 @@ -960,6 +960,7 @@ return Processed; // flush everything before this new frame newFrame = true; independentFrame = ((Data[i + 2] >> 3) & 0x07) == 1; // I-Frame + if (((Data[i + 2] >> 3) & 0x07) == 0) { independentFrame = 1;} if (synced) { if (framesPerPayloadUnit <= 1) scanning = false;