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

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;

[...]

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

On Sat, May 28, 2011 at 1:57 AM, Johan Andersson jna@jna.pp.se 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.

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

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: 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

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

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 '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.

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: 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