dropouts when watching hd tv (4 Viewers)

[HomeY]

I noticed the TSBuffer file from previous post isn't playing, so i tried to make it again.-
This time it took about 8 seconds before TV started, then i waited until the 2nd timeshift file was created, before i copied it.
Since the file is too large to be attached, you can download it from my Dropbox.

I'll go see if i can create another 25 secs PES error bufferfile also.

 

[HomeY]

And here you'll find another attempt of the 25 Seconds PES errors TSBuffer file, now copied after the 2nd TimeShift file was created (but it still won't play)

 

[mm1352000]

Unfortunately I don't have enough internet cap available to download the samples at the moment. However I'm still very interested to see if you find anything.

From a TV Server perspective there isn't much that can go better or worse in terms of the decrypt request, because for DD hardware we only submit the service ID (program number) to the driver.

In terms of other stuff: I do wonder if the decryption delay could in any way be "magnified" by TsReader's coping mechanisms (logging, flushing etc.). By that I mean, I wonder whether zapping would be any faster for the same situations if TsWriter were able to detect that the stream were encrypted and hold up the works until the stream came clear (rather than relying on TsReader to detect when the stream clears). We might be able to determine this without server side code changes if we noticed that the problem only happened with certain channels (channels that are encrypted at the PES level), or also happened with channels that are encrypted at the TS packet level (ie. those for which TsWriter should detect the encryption and function as designed)...

 

[Owlsroost]

Attached

While i was trying to make this TsBuffer file, i experienced a crash to desktop (reference to VC++ redist 2013).
(event)logs attached of that case also (MPCrash.zip).

That file ( from 'LongTune_TSBufferLogs') *does* play if you use TsReader.ax as the splitter filter e.g. in GraphStudio.

It has more than 30s of PES errors at the start, which is why LAV and MS splitters can't/won't open it (I've tried).

All of those tests say to me that the file content is encrypted/scrambled at the beginning.

If I run it through the VideoRedo's 'QuickStreamFix' (which removes the junk at the ends of the file) the video content starts at the same place as when playing the raw file using TsReader i.e. VideoRedo also thinks it's got 30s+ of junk at the beginning.....

 

[HomeY]

All of those tests say to me that the file content is encrypted/scrambled at the beginning.

Do i understand you correct that the cause of this then points to the CAM FW (since i ruled out the CAM)?

 

[Owlsroost]

All of those tests say to me that the file content is encrypted/scrambled at the beginning.

Do i understand you correct that the cause of this then points to the CAM FW (since i ruled out the CAM)?

It points to something at the server end not decrypting the stream - I can't tell you any more than that. I have zero knowledge of how decryption works in relation to TV server, but if one version of the FW works OK and another gives problems it *has* to be something to do with the FW I think.....

I'll try and do a bit more debugging of the stream to work out what level of encryption is used (e.g. TS or PES packets).

 

[HomeY]

but if one version of the FW works OK and another gives problems it *has* to be something to do with the FW I think.....

Yeah, i can understand that thought.

What still puzzles me is the fact that your modified TsReader works so much better with latest FW, compared to (for example) current master TsReader.
Meaning:

1. FW 3.25 + master TsReader: tuning works fine, PES errors are showing in my log
2. FW 3.25 + TsReader_v3_0_85_1b_VC2013: tuning works fine and seems to be faster than #1 and 0 PES errors in the log
3. FW 3.28 + master TsReader: Video decryptiong seems to fail in time, PES errors are visible in log, resulting in black screen + audio running fine (zapping in the timeshift buffer doesn't recover video)
4. FW 3.28 + TsReader_v3_0_85_1b_VC2013: At least 75% of the tuning attempts work fine, for the other 25% it takes a longer, but the channels work fine after this 'delay'.

I'll try and do a bit more debugging of the stream to work out what level of encryption is used (e.g. TS or PES packets).

Thanks, let me know if you need anything else.

 

[Owlsroost]

The log when playing the 'LongTune_TSBuffer' file with extra logging of the TS packet headers on every '0-0-1 Fail' message is attached.

As far as I can tell, it's PES-level encryption of the video & audio data (the TS headers look fine, and the PAT/PMT packets are also OK) .

EDIT: Actually, it looks like the entire PES packet is scrambled (including the headers), so have we got TS level encryption but with the TS header 'scrambling control' bits set to 'not scrambled' (00) ?

 

[Owlsroost]

Updated version of TsReader.ax attached with more PES error debug info and some other mods (needs VC2013 x86 installed).

 

[mm1352000]

Actually, it looks like the entire PES packet is scrambled (including the headers), so have we got TS level encryption but with the TS header 'scrambling control' bits set to 'not scrambled' (00) ?

Mmm, great point.

@HomeY
Have you observed any pattern in terms of channels? Channels which seem to cause the problem semi-consistently?
Either way, do you still have TransEdit installed and could you grab a screenshot of a hex view of the video/audio packets for one of the channels that has triggered the problem? Ideally one with the payload unit start indicator set (ie. one in which a PES packet starts)...