Re: [vdr] Weird recording problem
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 '0100' 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.0 +0200
+++ remux.c.orig 2010-05-04 21:57:38.0 +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
Subject: Re: [vdr] Weird recording problem
To: vdr@linuxtv.org
Message-ID:<4de94531.2010...@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 '0100' 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: kundtja...@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
.
--
Johan Andersson, j...@jna.pp.se
031-263006, 0709-762506
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Weird recording problem
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.c2010-05-04 14:55:50.0 +0200
+++ remux.c.orig 2010-05-04 21:57:38.0 +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
Subject: Re: [vdr] Weird recording problem
To: vdr@linuxtv.org
Message-ID:<4de94531.2010...@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 '0100' 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: kundtja...@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
Re: [vdr] Weird recording problem
On 03.06.2011 22:33, Johan Andersson wrote: 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 '0100' 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. I am very interested! Can you put the sample data somewhere I can download it? The dvbsnoop output might also be helpful. Klaus 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: kundtja...@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
Re: [vdr] Weird recording problem
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 '0100' 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: kundtja...@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 -- Johan Andersson, j...@jna.pp.se 031-263006, 0709-762506 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Weird recording problem
On 05/29/2011 07:14 PM, Johan Andersson wrote: In a small company like where I work I take the support call and fix the issue. Then your strategy would work. I suspect that in a larger company the only thing that happens is that the people at frontline support gets annoyed. The relevant people will only see one issue in their issue tracking system regardless. It would however be interesting to know if more people in Sweden have seen this. Perhaps everyone but me knew of the french situation and had it fixed long ago. Perhaps recording old Stargate reruns on TV6 is too geekish so noone else noticed :-) 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: kundtja...@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 Hi Johan. Yes, I have seen this too. TV10 has had it all the time but like you said, now TV6 has the same problem. I will send them a mail too and I must say I understand why Klaus doesn't want to make an ugly fix for this. I guess most STB people has, and that's why these problems exist. If everybody could just follow the standards things would be more stable. /Magnus H ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Weird recording problem
In a small company like where I work I take the support call and fix the issue. Then your strategy would work. I suspect that in a larger company the only thing that happens is that the people at frontline support gets annoyed. The relevant people will only see one issue in their issue tracking system regardless. It would however be interesting to know if more people in Sweden have seen this. Perhaps everyone but me knew of the french situation and had it fixed long ago. Perhaps recording old Stargate reruns on TV6 is too geekish so noone else noticed :-) 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: kundtja...@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 -- Johan Andersson, j...@jna.pp.se ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Weird recording problem
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 Johan Andersson skrev 2011-05-26 07:16: Klaus Schmidinger skrev 2011-05-26 00:41: If you can point me to an official standard document that defines 000 as a valid picture coding type... ;-) Just curious: since as you write TV4 works and TV6 doesn't, and both are apparently broadcast by the same provider, is there any chance you could contact that provider and ask why this difference exists? I mean there has to be some rationale for this... Like making channels unrecordable :-) I really have'nt got a clue who to ask. All physical transmission in Sweden is done by 'Teracom AB' but channels in the MUX'es are from mixed sources. TV4 is from 'TV4 AB' and TV6 is from 'Viasat Broadcasting UK' if one looks in channel.conf. All the marketing around DVB-T reception and selling smartcards for watching scrambled channels are done by 'Boxer AB'. I suppose the key question is who is doing the DVB encoding. The change is fairly recent though, I have recorded TV6 without problems for years. This has occured within the last few months. /Johan ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Weird recording problem
VDR User skrev 2011-05-28 11:44: Getting a VDR setup with vdpau is very easy. There's no need to use special repositories, packages, etc. unless you actually want to. If vdpau is the only thing you're after, you might be creating more work for yourself by not just keeping it small& simple. Perhaps. I had a lot of trouble a year or so ago trying to get xineliboutput working with VDPAU under Ubuntu9. It has probably improved since then. Nowadays I simply add a launchpad repos and do 'apt-get install' for vdr, xineliboutput etc. I probably get a lot of stuff I do not need, but it is very simple to install and maintain. /Johan -- Johan Andersson, j...@jna.pp.se ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Weird recording problem
On Sat, May 28, 2011 at 1:57 AM, 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'. 'Your problem seems to relate to the error we have', was > their statement. They had no due date for fixing it though. > > I managed to build the yavdr teams vdr-dev(1.7.17) for Ubuntu Lucid, from > source with my change so I can again record TV6. > > The main reason for using the yavdr stuff is VDPAU, as I use xineliboutput. Getting a VDR setup with vdpau is very easy. There's no need to use special repositories, packages, etc. unless you actually want to. If vdpau is the only thing you're after, you might be creating more work for yourself by not just keeping it small & simple. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Weird recording problem
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'. 'Your problem seems to relate to the error we have', was their statement. They had no due date for fixing it though. I managed to build the yavdr teams vdr-dev(1.7.17) for Ubuntu Lucid, from source with my change so I can again record TV6. The main reason for using the yavdr stuff is VDPAU, as I use xineliboutput. /Johan Johan Andersson skrev 2011-05-26 07:16: Klaus Schmidinger skrev 2011-05-26 00:41: If you can point me to an official standard document that defines 000 as a valid picture coding type... ;-) Just curious: since as you write TV4 works and TV6 doesn't, and both are apparently broadcast by the same provider, is there any chance you could contact that provider and ask why this difference exists? I mean there has to be some rationale for this... Like making channels unrecordable :-) I really have'nt got a clue who to ask. All physical transmission in Sweden is done by 'Teracom AB' but channels in the MUX'es are from mixed sources. TV4 is from 'TV4 AB' and TV6 is from 'Viasat Broadcasting UK' if one looks in channel.conf. All the marketing around DVB-T reception and selling smartcards for watching scrambled channels are done by 'Boxer AB'. I suppose the key question is who is doing the DVB encoding. The change is fairly recent though, I have recorded TV6 without problems for years. This has occured within the last few months. /Johan -- Johan Andersson, j...@jna.pp.se 031-263006, 0709-762506 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Weird recording problem
Klaus Schmidinger skrev 2011-05-26 00:41: If you can point me to an official standard document that defines 000 as a valid picture coding type... ;-) Just curious: since as you write TV4 works and TV6 doesn't, and both are apparently broadcast by the same provider, is there any chance you could contact that provider and ask why this difference exists? I mean there has to be some rationale for this... Like making channels unrecordable :-) I really have'nt got a clue who to ask. All physical transmission in Sweden is done by 'Teracom AB' but channels in the MUX'es are from mixed sources. TV4 is from 'TV4 AB' and TV6 is from 'Viasat Broadcasting UK' if one looks in channel.conf. All the marketing around DVB-T reception and selling smartcards for watching scrambled channels are done by 'Boxer AB'. I suppose the key question is who is doing the DVB encoding. The change is fairly recent though, I have recorded TV6 without problems for years. This has occured within the last few months. /Johan -- Johan Andersson, j...@jna.pp.se ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Weird recording problem
On 25.05.2011 23:47, Johan Andersson wrote: Thank you! It all works if we change the line to: > #609: independentFrame = ((Data[i+2]>>3)& 0x06)==0; For some reason 'picture_coding_type' is set to '000' in this stream, not '001'. So only checkin the upper bits seem to do the trick. As streams like this seem to exist both in Sweden and in France, is there any chance of making this change in the official VDR? If you can point me to an official standard document that defines 000 as a valid picture coding type... ;-) Just curious: since as you write TV4 works and TV6 doesn't, and both are apparently broadcast by the same provider, is there any chance you could contact that provider and ask why this difference exists? I mean there has to be some rationale for this... Klaus Dominique skrev 2011-05-25 22:25: Hi This has been discussed here .. even if the solution is a temporary one, it works nice in France from months http://www.linuxtv.org/pipermail/vdr/2010-June/023193.html Best regards Le mercredi 25 mai 2011 21:57:15, Johan Andersson a écrit : Has anyone seen something similar to this? [...] The relevant line in remux.c is: #609: independentFrame = ((Data[i+2]>>3)& 0x07)==1; > [...] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Weird recording problem
Thank you! It all works if we change the line to: >> #609: independentFrame = ((Data[i+2]>>3)& 0x06)==0; For some reason 'picture_coding_type' is set to '000' in this stream, not '001'. So only checkin the upper bits seem to do the trick. As streams like this seem to exist both in Sweden and in France, is there any chance of making this change in the official VDR? Yours, Johan Dominique skrev 2011-05-25 22:25: Hi This has been discussed here .. even if the solution is a temporary one, it works nice in France from months http://www.linuxtv.org/pipermail/vdr/2010-June/023193.html Best regards Le mercredi 25 mai 2011 21:57:15, Johan Andersson a écrit : Has anyone seen something similar to this? [...] The relevant line in remux.c is: #609: independentFrame = ((Data[i+2]>>3)& 0x07)==1; >> [...] -- Johan Andersson, j...@jna.pp.se 031-263006, 0709-762506 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Weird recording problem
Hi This has been discussed here .. even if the solution is a temporary one, it works nice in France from months http://www.linuxtv.org/pipermail/vdr/2010-June/023193.html Best regards Le mercredi 25 mai 2011 21:57:15, Johan Andersson a écrit : > Has anyone seen something similar to this? > > I have two unscrambled channels on the same MUX where both is watchable > in Live-TV but only one is recordable. The other terminates vdr (video > stream broken). > > The MUX is f=522MHz, se_Gothenburg-BrudareMossen, channels TV4 and TV6. > > After throwing tons of debug prints in recorder.c and remux.c, it seems > for TV6 the cFrameDetector never gets to 'synced' state. > > I am debugging with vdr 1.7.14, but yaVDR teams vdr 1.7.17 release has > the same problem. > > The relevant line in remux.c is: > #609: independentFrame = ((Data[i+2]>>3) & 0x07)==1; > > For TV6 this '(Data[i+2]>>3) & 0x07' is 0,2 and 3 > but not '1' for the 30s before recorder times out > and considers video stream broken. > > For TV4 it gets to be '1' within a couple of seconds. > > Any ideas or debug suggestions are welcome. > > Yours, > Johan ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
