37 replies to this topic

[Erik Slagter]

You ask the right questions (= not dumb and I know some answers) I'll do the answering

 

I hope someone will get inspired to get it actually working, from this discussion. I have far too little time for it, unfortunately.

[littlesat]

I’m designing a method when you put the box in standby that the recordings are decrypted. As it starts also timer it also prevents the box going to deep standby aswell.... pieterg’s method isn’t indeed that bad....

[HWTest]

Yesterday I did a new offline decoding test.

I've created a 15 min long test recording, containing 2 encrypted areas:

2:28.440-3:11.120
8:15.200-8:27.960

 

Oscam has a ratelimit set for the used reader:

ratelimitecm                  = 1
ratelimittime                 = 3000
srvidholdtime                 = 3000

 

The ratelimit was tested - recording one channel and trying to watch another gave no matching reader in the log.

 

The decoding delay was set to 9999 (which I think is the upper limit)

 

Here are the ECM times:

17:57:35
17:57:36
17:57:37
17:57:38
17:57:39
17:57:41
17:57:42
17:57:44
17:57:45
17:57:46
17:57:47
17:57:48
17:57:50
17:57:51
17:57:53
17:58:04
17:58:15
17:58:27
17:58:38
17:58:40
17:58:41
17:58:43
17:58:44
17:58:45
17:58:45
17:58:46
17:58:47
17:58:47
17:58:49
17:58:50
17:58:51
17:58:52
17:58:54
17:58:56
17:58:58
17:58:59
17:59:01
17:59:03
17:59:05
17:59:06
17:59:08
17:59:09
17:59:11
17:59:12
17:59:14
17:59:15
17:59:17
17:59:19
17:59:20
17:59:31
17:59:42
17:59:42
17:59:43
17:59:45
17:59:46
17:59:48
17:59:50
17:59:52
17:59:53
17:59:55
17:59:57
17:59:58
18:00:00
18:00:02
18:00:04
18:00:06
18:00:07
18:00:09
18:00:11
18:00:12
18:00:14
18:00:16
18:00:18
18:00:19
18:00:21
18:00:23
18:00:25
18:00:27
18:00:29
18:00:31
18:00:33
18:00:35
18:00:37
18:00:39
18:00:41
18:00:42
18:00:44
18:00:45
18:00:47
18:00:48

 

Why it ignores the set decoding delay in the already descrambled areas?

Why Oscam ignores the ratelimit in this case (or is Streamboard more appropriate for this question?)?

And what can I do, that it behaves correctly?

 

PS I'm aware the ratelimit wouldn't help in reducing the decoding speed.

[Erik Slagter]

Oscam cannot know if a request for an ECM is for recording or offline decoding.

 

The offline decoding delay is measured in milliseconds, so a value of 10000 would be a good starting point.

 

I think you have a flaw in your reasoning, you think that the decrypting is done by the softcam. That is not the case.

 

This is how DVB decryption works:

- provider sends (encrypted) EMM packets to subscriber cards to specify what programs should be decrypted and during which period

- provider scrambles (note the use of this word instead of "encrypts") the streams using a control word (actually 2 of them, but let's keep it simple here)

- provider encrypts the control word and probably adds some metadata to it, into an ECM

- provider sends the ECM frequently, about once a second, that's why it takes some time after zapping before you actually have a picture

- enigma builds and sends a caPMT structure from the PMT to inform the CI and/or softcam of the new service + ECM pid(s)

- with the caPMT the CI can start descrambling the service, enigma doesn't do anything to it, it just instructs the SoC to pass the CI output to the demuxer -> audio/video decoders

- with the caPMT the softcam can start fetching the ECMs, hand them to the subscriber card, the card returns a control word and the control word is sent to the descrambler (in the demuxer); also enigma does nothing here

- both a CI and a descrambler in the demuxer (from SoC) will only descramble packets that have one of the "scrambled" bits active. So that's no problem.

- the problem is that for this to work, the current control word always needs to be in the descrambler, because the softcam can never know which parts of the file are still scrambled and even it would, there would be too much delay having the ECM converted into a control words and setup the descrambler.

 

So, offline decryption of a file that only has parts still scrambled, will only ever work if all ECMs present in the file are handed to the softcam and resolved into control words.

 

I believe I explained that earlier on, but apparently not good enough.

[HWTest]

Thank you very much for the detailed explanation.

But I still have some questions left:

1) what is the maximum of the decoding delay? I've read somewhere that it is 9999 but I have tried 12000 and it worked.

2) why it doesn't honour the delay, when "descrambling" an already descrambled part of a partially scrambled recording? It seems it knows it's already descrambled and ignores the delay.

 

I have also noticed, there is a small glitch in the transition of the already descrambled part and the newly descrambled part, when descrambling a partially scrambled recording. So the transitions in the new file are not seamless.

When descrambling a completely scrambled recording, there is a really small part in the beginning of the recording, which stays scrambled, probably because it has to wait for an ECM first.

[Erik Slagter]

1) I don't think there is a real limit (other than 32 bits unsigned int).

2) No enigma can't know if part of a file is already descrambled

 

I think both experiences you mention come from a control word arriving too late or being honoured too late. Is it on a duo4k? We've had more reports about this.

[littlesat]

It depends.... when you adjust it to the ECM cycle time of your provider (eg 10000 ms) han it decodes on the same speed as live tv...’when you devide it by two (5000 ms) then the encoding has double speed....
And when you watch the same channel live which the recording was coming from and you have to set SID and ECM timing limita for your card offline decoding can also give other odd things.... (it is more a have to when you’re using CIs)

Edited by littlesat, 29 December 2018 - 10:12.

[Erik Slagter]

And when you remove all these "if"'s, your case has gone.

Edited by Erik Slagter, 29 December 2018 - 10:20.

[HWTest]

ad 2) Enigma doesn't know, so it should honor the delay no matter what. But it clearly doesn't. The question is, why and what can I do, that it does?

 

The delay was set to 12000 which is the ECM interval, when watching live.

I didn't watch another channel during decoding, I didn't want to disturb it.

The card can handle at least 4 channels at once, maybe more but I didn't test it.

It's a Skylink ICE card in Irdeto mode, I could test Cryptoworks mode, But I don't think it will make a difference.

Tested on a Ultimo 4k and a Duo2. I noticed another odd thing when testing on the Duo2 - the decoding stopped but the timer was still there and running, after switching to standby, the decoding resumed and after some time finished.

I can do another test and add a Zero 4k to the test bench rule out receiver specific problems?

[HWTest]

I redid the tests.

Sample 5:05.437 long, scrambled areas:

1:05.600-1:18.620

2:27.820-3:10,300

Delay set to 12000

 

Ultimo 4k - the resulting video is 5:01.731 long, no glitches, seamless transitions

Zero 4k - the resulting video is 3:37.039 long, no glitches, seamless transitions but the first part is missing

Duo2 - the resulting video is 4:56.772 long, no glitches, seamless transitions but a small part of the beginning is missing

Only the Ultimo has an internal HDD, maybe the missing parts in the beginning are network related ...

 

None of the boxes honored the delay, here are the ECM times:

 

Ultimo 4
17:28:40
17:28:41
17:28:42
17:28:43
17:28:44
17:28:58
17:28:59
17:29:00
17:29:02
17:29:03
17:29:16
17:29:29
17:29:42
17:29:43
17:29:44
17:29:45
17:29:47
17:29:48
17:29:49
17:29:50
17:29:51
        
Zero 4k
17:59:24
17:59:25
17:59:26
17:59:27
17:59:28
17:59:41
17:59:54
18:00:07
18:00:08
18:00:10
18:00:11
18:00:12
18:00:13
18:00:15
18:00:16
18:00:17
        
Duo2    
18:25:04
18:25:04
18:25:05
18:25:06
18:25:08
18:25:21
18:25:22
18:25:24
18:25:25
18:25:26
18:25:39
18:25:51
18:26:05
18:26:06
18:26:07
18:26:08
18:26:09
18:26:10
18:26:12
18:26:13
18:26:14

[Erik Slagter]

What did you specifiy for delay? Please note it's specified in milliseconds!

[Erik Slagter]

A quick look at the code reveals that the mechanism watches for control word parity changes (changing from odd code word to even and v.v.), which is very easy to spot in the stream. Whenever a parity change occurs, an "usleep(m_parity_switch_delay * 1000)" is done, i.e. microseconds * 1000 = milliseconds. So something like 10000 would be appropriate.

 

It also means that parts of the file that are already descrambled AND which have the control word selection cleared to "off" (not every vendor's drivers do this right) will rush through the file undelayed.

 

I understand why this is interesting for files that only have a few small parts left scrambled, but in the meantime it will burn your card, because all found ECM's are processed (unavoidable).

 

So I guess with the knowledge of today, with request limiting cards, this approach may not be sufficient.

 

On the other hand, as long as the ECM's are coming from the same service, it may very well be that the limiting mechanism of the card doesn't get activated. I am not sure how oscam would react, with it's limiter, that's a completely other story.

[Pr2]

Delayer in OScam has 2 goals:

- when you can use the emu instead of a card it happens that the DW came too fast and unscrambling is not working so a delay must be defined

- when people use cacheex it is sometimes interesting to set a small delay to let time to DW to be in the cache

 

So delay was implemented for live show, not for offline decoding.

 

Delay is not a mechanism to protect the card, it is the ratelimit which must be used for this.

 

Why will you burn your card if you unscramble 1 encrypted file at the time?

Why do you think useful to add a delay for offline decoding?

 

Offline decoding is implemented, if I am right, for people using a CI slot where we can only decode 1 or 2 channels at the same time. Offline decoding is not really useful for normal people using softcam.

[HWTest]

The delay was set to 12000 (12 seconds).

 

So nothing I can do.

 

Oscam ratelimit is ignored but it wouldn't help, so it doesn't matter.

[HWTest]

Pr2:

 

Delay was set in "Offline decode delay" not in Oscam.

 

Ratelimit settings in Oscam:

ratelimitecm                  = 1
ratelimittime                 = 3000
srvidholdtime                 = 3000

 

Offline decoding is useful for partially descrambled recordings.

When using non local servers, then it sometimes happens and when you hammer the server (during offline decoding) you probably get banned ...

[Erik Slagter]

Delayer in OScam has 2 goals:

- when you can use the emu instead of a card it happens that the DW came too fast and unscrambling is not working so a delay must be defined

- when people use cacheex it is sometimes interesting to set a small delay to let time to DW to be in the cache

 

So delay was implemented for live show, not for offline decoding.

 

Delay is not a mechanism to protect the card, it is the ratelimit which must be used for this.

 

Why will you burn your card if you unscramble 1 encrypted file at the time?

Why do you think useful to add a delay for offline decoding?

 

Offline decoding is implemented, if I am right, for people using a CI slot where we can only decode 1 or 2 channels at the same time. Offline decoding is not really useful for normal people using softcam.

We're not talking of Oscam here...

[Pr2]

Sorry but yes we are talking of OScam since the very beginning, HWTest explain the delay he set in its OScam in the 1st post and all the ECM time logs posted by HWtest are, I think, coming from his OScam.

 

Pr2

[Erik Slagter]

That may be true, but I am talking of the "decoding delay" setting in enigma. That is what you'll need to set.