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 Anderssonjna@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
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 Anderssonjna@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
.