cards like the Digital Devices DuoFlex S2, cineS2 and upcoming 
hardware (octuple, network, etc.) have independent CA devices.
This means that instead of having the stream routed from the frontend 
through the CI and only then into memory a stream can be sent from
memory through the CI and back. So, the current device model does not
fit this hardware.

One could hide this fact inside the driver and send the stream from
the frontend through the CI transparently to the API but this would
prevent people from implementing new features like decoding a stream from 
a different DVB card, decoding streams from hard disk or even decoding
several sub-streams from different transponders.
The latter works with the current Windows driver but I have not
implemented it in Linux yet. It also has to be supported by the CI
modules. Some can decode 12 streams (6 times video/audio) at once.

But decoding single streams already works fine. Currently, I am 
registering a different adapter for the CI.
On a CineS2 with CI attached at the IO port I then have

/dev/dvb/adapter[01] for the two DVB-S2 frontends and
/dev/dvb/adapter2 just for the ca0 device.

I am abusing the unused sec0 to write/read data to/from the CI module.
For testing I hacked zap from dvb-apps to tune on adapter0 but 
use adapter2/ca0 to talk to the CI module.
I then write the encrypted stream from adapter0/dvr0 into 
adapter2/sec0 and read the decoded stream back from adapter2/sec0.
The encrypted stream of course has to contain all the PIDs of the

So, I would like to hear your opinions about how to handle such CA devices 
regarding device names/types, the DVB API and user libraries.


To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to