>The changes since version 2.1.2: >- The new function cCamSlot::Decrypt() can be used by derived classes to implement a > CAM slot that can be freely assigned to any device, without being directly inserted > into the full TS data stream in hardware. A derived class that implements Decrypt() > will also need to set the new parameter ReceiveCaPids in the call to the cCamSlot > base class constructor to true, in order to receive the CA pid TS packets that > contain data necessary for decrypting. >- Many member functions of cCamSlot have been made virtual to allow for easier > implementation of derived classes. >- cDvbDevice::GetTSPacket() now calls CamSlot()->Decrypt() in order to allow CAM slots > that can be freely assigned to any device access to the TS data stream. This is very exiting to me.I only watch one channel at a time, but I would like to record multiple channels at the same time. I am investigating if it's possible to move the decryption functionality from recording to playback time. This allows me to run VDR on an underpowered platform that is fast enough to record multiple shows, but only has the CPU power to decrypt one channel. (My NAS would be such a platform) Receiving all caPID's is a big step in that direction. Maybe I can alter VDR so that it produces a recording containing the caPID's, the keys from oscam and the audio /video data. Next, during playback I can then feed it through libdvbcsa. Also, when the CPU has some time available, it can decode TV shows in a low-priority process. This will further reduce the "realtime" CPU load. I wonder if there is a standard-compliant way to store the decryption keys in the resulting .ts file. Thank you for your hard work!. Kind regards, Cedric _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
