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@xxxxxxxxx>
Subject: Re: Weird recording problem
To: vdr@xxxxxxxxxxx
Message-ID:<4DE94531.2010103@xxxxxxxxx>
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@xxxxxxxxxx
/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@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
.
--
Johan Andersson, jna@xxxxxxxxx
031-263006, 0709-762506
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
