Change the way myth "decides" if a program is encrypted

[anonymous]

I have a whole sat lineup, with almost only pay channels, BUT there is one clear channel that mythtv, most of the time, tries to descramble whereas it is clear, which does not work. The reason is this code in mpegtables.cpp

/ \fn ProgramMapTable::IsEncrypted?(void) const

• \brief Returns true iff PMT contains CA descriptor. */

bool ProgramMapTable::IsEncrypted?(void) const {

bool encrypted = IsProgramEncrypted?();

for (uint i = 0; !encrypted && i < StreamCount?(); i++)

encrypted |= IsStreamEncrypted?(i);

return encrypted;

}

It happens in my case that the PMT of the free program is detected by myth as:

2010-07-09 14:06:41.024 CreatePMTSingleProgram() 2010-07-09 14:06:41.024 PMT in input stream 2010-07-09 14:06:41.024 Program Map Table ver(16) pid(0x509) pnum(9069) len(213)

Stream #0 pid(0xa9) type(video-mpeg2 0x2) Stream #1 pid(0x74) type(audio-mp2-layer[1,2,3] 0x4)

ISO-639 Language: code(fra) canonical(fre) eng(French)

Stream #2 pid(0x35) type(private-data 0x6)

Teletext Descriptor (0x56) length(5)

Stream #3 pid(0xda) type(unknown 0xc0)

Unknown(198) Descriptor (0xc6) length(5) Unknown(194) Descriptor (0xc2) length(40)

Stream #4 pid(0x119) type(unknown 0xc0)

Unknown(194) Descriptor (0xc2) length(8)

Stream #5 pid(0x4e2) type(unknown 0xc1)

Unknown(194) Descriptor (0xc2) length(8)

Stream #6 pid(0x153) type(unknown 0xc1)

Unknown(194) Descriptor (0xc2) length(8)

Stream #7 pid(0x4e3) type(unknown 0xc6) Stream #8 pid(0xcf) type(unknown 0xc1)

Unknown(194) Descriptor (0xc2) length(8) Conditional Access: sid(0x100) pid(0x708) data_size(13) Conditional Access: sid(0x100) pid(0x16a8) data_size(13)

Stream #9 pid(0xce) type(unknown 0xc1)

Unknown(194) Descriptor (0xc2) length(8)

So this is flagged as being encrypted as at least one stream is (the one before the last one). But if you compare with a PMT of a real pay channel like this one: 2010-07-09 15:23:44.986 Program Map Table ver(28) pid(0x514) pnum(9100) len(295)

Stream #0 pid(0xb4) type(video-mpeg2 0x2)

Conditional Access: sid(0x100) pid(0x6a4) data_size(28)

Stream #1 pid(0x9e) type(audio-mp2-layer[1,2,3] 0x4)

ISO-639 Language: code(fra) canonical(fre) eng(French) Conditional Access: sid(0x100) pid(0x6a4) data_size(28)

Stream #2 pid(0xda) type(unknown 0xc0)

Unknown(198) Descriptor (0xc6) length(5) Unknown(194) Descriptor (0xc2) length(40)

Stream #3 pid(0x119) type(unknown 0xc0)

Unknown(194) Descriptor (0xc2) length(8)

Stream #4 pid(0x4e2) type(unknown 0xc1)

Unknown(194) Descriptor (0xc2) length(8)

Stream #5 pid(0x153) type(unknown 0xc1)

Unknown(194) Descriptor (0xc2) length(8)

Stream #6 pid(0xce) type(unknown 0xc1)

Unknown(194) Descriptor (0xc2) length(8)

Stream #7 pid(0x155) type(unknown 0xc1)

Unknown(194) Descriptor (0xc2) length(8)

Stream #8 pid(0x159) type(unknown 0xc1)

Unknown(194) Descriptor (0xc2) length(8)

Stream #9 pid(0x4e3) type(unknown 0xc6) Stream #10 pid(0xcf) type(unknown 0xc1)

Unknown(194) Descriptor (0xc2) length(8) Conditional Access: sid(0x100) pid(0x708) data_size(28)

you can see that here the audio and video streams contain a ca descriptor. So the fix I propose would be to only test the presence of ca descriptors in audio or video streams only, which is what really matters. I cant propose a patch as my system is too fragile right now, but it is a matter of adding isaudio and isvideo calls in the loop. HTH

[anonymous]

I don't know how myth detects whether a stream is encrypted or not. I do know that using the CA descriptors in any way to detect if a stream is encrypted or not is wrong. The only way to reliably tell is a stream is encrypted is to look at the TS Packet for a particular PID within the program. If the scambling bits are set in the TS packet, the stream is encrypted.

[anonymous]

Sorry I did not see your answer sooner. So what you mean is: take the stream whenever we are locked and then on the first (or the first few) packet(s) we can decide if the stream is ecnrypted by looking at the scrambling bit, it that right?

[eallaud@…]

PMT Encryption detection patch

[anonymous]

The attached patch implements what I was talking about: check only the video and audio streams for ca descriptors to decide if the channel is ecnrypted.

[eallaud@…]

Any chance someone takes a quick look at it, or is there a problem with the patch? Thx

[robertm]

This patch makes sense to me, and appears to be the better way of handling things after a casual reading of ETSI EN 300 468, ETSI TR 101 211. Going to do some more reading and bounce it off of those who actually live in DVB countries.

[Github]

DVB: Improve encryption detection by only checking the CA encryption bits for Audio and Video.

This prevents cases where some channels are mistakenly discarded as encrypted in DVB systems. This should help to improve the accuracy of scans.

Patch from eallaud, minor cleanup and verification against the specs by me, secondary code review by Stuart A. Thanks!

Fixes #8645.

Branch: master Changeset: 19a2cc7c3661675faa8f2025bf716ade8becda91