How to handle independent CA devices

How to handle independent CA devices

[rjkm]

Hi,

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
ca_pmt. 

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.


-Ralph

Re: How to handle independent CA devices

[Johannes Stezenbach]

Hi Ralph,

On Thu, Sep 09, 2010 at 11:52:25PM +0200, rjkm wrote:
> 
> 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
> ca_pmt. 
> 
> 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.

it looks like there isn't much interest from DVB developers
in that topic...  I'll try...


IMHO there are three sub topics:

1. be compatible with existing applications
   (I guess this means: feed stream from frontend through CI transparently)
2. create an API which would also work for CI-only
   devices like this Hauppauge WinTV-CI USB thingy
3. how to switch between these modes?

This sec0 device is history (unused and deprecated for years), right?
How about the following:
Rename it to ci0.  When ci0 is closed the stream is routed
transparently from frontend through CI, if it's opened one needs to
read/write the stream from userspace.


If you can't get responses here I guess you could talk to
vdr or other application developers.  After all they'll have
to use the API.


Cheers,
Johannes

Re: How to handle independent CA devices

[rjkm]

Hi Johannes,


Johannes Stezenbach writes:
 > > 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.
 > 
 > it looks like there isn't much interest from DVB developers
 > in that topic...  I'll try...
 > 
 > 
 > IMHO there are three sub topics:
 > 
 > 1. be compatible with existing applications
 >    (I guess this means: feed stream from frontend through CI transparently)
 > 2. create an API which would also work for CI-only
 >    devices like this Hauppauge WinTV-CI USB thingy
 > 3. how to switch between these modes?
 > 
 > This sec0 device is history (unused and deprecated for years), right?

Yes, the former DiSEqC, etc. device. I only use it because it is is
unused and I do not have to change anything in dvb-core this way.
But trivial to change it or add ci0.


 > How about the following:
 > Rename it to ci0.  When ci0 is closed the stream is routed
 > transparently from frontend through CI, if it's opened one needs to
 > read/write the stream from userspace.


You still need a mechanism to decide which tuner gets it. First one
which opens its own ca device?
Sharing the CI (multi-stream decoding) in such an automatic way 
would also be complicated.
I think I will only add such a feature if there is very high demand
and rather look into the separate API solution.


 > If you can't get responses here I guess you could talk to
 > vdr or other application developers.  After all they'll have
 > to use the API.

I am in contact with some.
Just wanted to check what people think about it on this list.

Thanks for your comments.


-Ralph

Re: How to handle independent CA devices

[Emmanuel]

rjkm a écrit :
> Hi Johannes,
>
>
> Johannes Stezenbach writes:
>  > > 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.
>  > 
>  > it looks like there isn't much interest from DVB developers
>  > in that topic...  I'll try...
>  > 
>  > 
>  > IMHO there are three sub topics:
>  > 
>  > 1. be compatible with existing applications
>  >    (I guess this means: feed stream from frontend through CI transparently)
>  > 2. create an API which would also work for CI-only
>  >    devices like this Hauppauge WinTV-CI USB thingy
>  > 3. how to switch between these modes?
>  > 
>  > This sec0 device is history (unused and deprecated for years), right?
>
> Yes, the former DiSEqC, etc. device. I only use it because it is is
> unused and I do not have to change anything in dvb-core this way.
> But trivial to change it or add ci0.
>
>
>  > How about the following:
>  > Rename it to ci0.  When ci0 is closed the stream is routed
>  > transparently from frontend through CI, if it's opened one needs to
>  > read/write the stream from userspace.
>
>
> You still need a mechanism to decide which tuner gets it. First one
> which opens its own ca device?
> Sharing the CI (multi-stream decoding) in such an automatic way 
> would also be complicated.
> I think I will only add such a feature if there is very high demand
> and rather look into the separate API solution.
>
>
>  > If you can't get responses here I guess you could talk to
>  > vdr or other application developers.  After all they'll have
>  > to use the API.
>
> I am in contact with some.
> Just wanted to check what people think about it on this list.
>
> Thanks for your comments.
>
>   
You might also want to check on mythtv-dev list, there was a guy (James 
Courtier-Dutton) who wanted to hack exactly this in mythtv. I guess he 
would have the user space point-of-view.
Hope you succeed, because having an independant CI would be perfect to 
enable real multirec for DVB cards by decoding after the fact.
Bye
Manu

Re: How to handle independent CA devices

[Manu Abraham]

Hi Ralph,

On Wed, Sep 15, 2010 at 5:26 AM, rjkm <rjkm@metzlerbros.de> wrote:
> Hi Johannes,
>
>
> Johannes Stezenbach writes:
>  > > 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.
>  >
>  > it looks like there isn't much interest from DVB developers
>  > in that topic...  I'll try...
>  >
>  >
>  > IMHO there are three sub topics:
>  >
>  > 1. be compatible with existing applications
>  >    (I guess this means: feed stream from frontend through CI transparently)
>  > 2. create an API which would also work for CI-only
>  >    devices like this Hauppauge WinTV-CI USB thingy
>  > 3. how to switch between these modes?
>  >
>  > This sec0 device is history (unused and deprecated for years), right?
>
> Yes, the former DiSEqC, etc. device. I only use it because it is is
> unused and I do not have to change anything in dvb-core this way.
> But trivial to change it or add ci0.
>
>
>  > How about the following:
>  > Rename it to ci0.  When ci0 is closed the stream is routed
>  > transparently from frontend through CI, if it's opened one needs to
>  > read/write the stream from userspace.
>
>
> You still need a mechanism to decide which tuner gets it. First one
> which opens its own ca device?
> Sharing the CI (multi-stream decoding) in such an automatic way
> would also be complicated.
> I think I will only add such a feature if there is very high demand
> and rather look into the separate API solution.


It would be advantageous, if we do have just a simple input path,
where it is not restricted for CA/CI alone. I have some hardware over
here, where it has a DMA_TO_DEVICE channel (other than for the SG
table), where it can write a TS to any post-processor connected to it,
such as a CA/CI device, or even a decoder, for example. In short, it
could be anything, to put short.

In this case, the device can accept processed stream (muxed TS for
multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You
can flip some registers for the device, for it to read from userspace,
or for that DMA channel to read from the hardware page tables of
another DMA channel which is coming from the tuner.

Maybe, we just need a simple mechanism/ioctl to select the CA/CI input
for the stream to the bridge. ie like a MUX: a 1:n select per adapter,
where the CA/CI device has 1 input and there are 'n' sources.

Best Regards,
Manu

Re: How to handle independent CA devices

[rjkm]

Manu Abraham writes:

 > > You still need a mechanism to decide which tuner gets it. First one
 > > which opens its own ca device?
 > > Sharing the CI (multi-stream decoding) in such an automatic way
 > > would also be complicated.
 > > I think I will only add such a feature if there is very high demand
 > > and rather look into the separate API solution.
 > 
 > 
 > It would be advantageous, if we do have just a simple input path,
 > where it is not restricted for CA/CI alone. I have some hardware over
 > here, where it has a DMA_TO_DEVICE channel (other than for the SG
 > table), where it can write a TS to any post-processor connected to it,
 > such as a CA/CI device, or even a decoder, for example. In short, it
 > could be anything, to put short.
 > 
 > In this case, the device can accept processed stream (muxed TS for
 > multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You
 > can flip some registers for the device, for it to read from userspace,
 > or for that DMA channel to read from the hardware page tables of
 > another DMA channel which is coming from the tuner.
 > 
 > Maybe, we just need a simple mechanism/ioctl to select the CA/CI input
 > for the stream to the bridge. ie like a MUX: a 1:n select per adapter,
 > where the CA/CI device has 1 input and there are 'n' sources.


It would be nice to have a more general output device. But I have
currently no plans to support something like transparent streaming 
from one input to the output and back inside the driver.



-Ralph

Re: How to handle independent CA devices

[James Courtier-Dutton]

On 18 September 2010 01:47, rjkm <rjkm@metzlerbros.de> wrote:
> Manu Abraham writes:
>
>  > > You still need a mechanism to decide which tuner gets it. First one
>  > > which opens its own ca device?
>  > > Sharing the CI (multi-stream decoding) in such an automatic way
>  > > would also be complicated.
>  > > I think I will only add such a feature if there is very high demand
>  > > and rather look into the separate API solution.
>  >
>  >
>  > It would be advantageous, if we do have just a simple input path,
>  > where it is not restricted for CA/CI alone. I have some hardware over
>  > here, where it has a DMA_TO_DEVICE channel (other than for the SG
>  > table), where it can write a TS to any post-processor connected to it,
>  > such as a CA/CI device, or even a decoder, for example. In short, it
>  > could be anything, to put short.
>  >
>  > In this case, the device can accept processed stream (muxed TS for
>  > multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You
>  > can flip some registers for the device, for it to read from userspace,
>  > or for that DMA channel to read from the hardware page tables of
>  > another DMA channel which is coming from the tuner.
>  >
>  > Maybe, we just need a simple mechanism/ioctl to select the CA/CI input
>  > for the stream to the bridge. ie like a MUX: a 1:n select per adapter,
>  > where the CA/CI device has 1 input and there are 'n' sources.
>
>
> It would be nice to have a more general output device. But I have
> currently no plans to support something like transparent streaming
> from one input to the output and back inside the driver.
>

Could it be handled as a transcode step?

Record the encrypted mux from the DVB card to disk first.
Then do the decrypt step offline or during playback.
During playback, you only wish to watch one channel at a time, and the
CAM will handle that.
Contra to what people think, most CAMs can decrypt the stream some
considerably time after the broadcast of the stream.

Re: How to handle independent CA devices

[Manu Abraham]

On Sat, Sep 18, 2010 at 6:17 AM, rjkm <rjkm@metzlerbros.de> wrote:
> Manu Abraham writes:
>
>  > > You still need a mechanism to decide which tuner gets it. First one
>  > > which opens its own ca device?
>  > > Sharing the CI (multi-stream decoding) in such an automatic way
>  > > would also be complicated.
>  > > I think I will only add such a feature if there is very high demand
>  > > and rather look into the separate API solution.
>  >
>  >
>  > It would be advantageous, if we do have just a simple input path,
>  > where it is not restricted for CA/CI alone. I have some hardware over
>  > here, where it has a DMA_TO_DEVICE channel (other than for the SG
>  > table), where it can write a TS to any post-processor connected to it,
>  > such as a CA/CI device, or even a decoder, for example. In short, it
>  > could be anything, to put short.
>  >
>  > In this case, the device can accept processed stream (muxed TS for
>  > multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You
>  > can flip some registers for the device, for it to read from userspace,
>  > or for that DMA channel to read from the hardware page tables of
>  > another DMA channel which is coming from the tuner.
>  >
>  > Maybe, we just need a simple mechanism/ioctl to select the CA/CI input
>  > for the stream to the bridge. ie like a MUX: a 1:n select per adapter,
>  > where the CA/CI device has 1 input and there are 'n' sources.
>
>
> It would be nice to have a more general output device. But I have
> currently no plans to support something like transparent streaming
> from one input to the output and back inside the driver.


Maybe it wasn't very clear ... (Streaming from one input to the output
and back inside the driver what you are implementing is not what I had
in mind.)

Currently for any independant CA device what you need is a stream to
the bridge where it can route the same to the CI slot.
For a generic device capable of doing any other gimmicks also, what
you need is an input to the bridge.

So, what I was trying to say is that, let's not limit the input path
to CA alone. For explanation sale let's term in as TS_IN

The TS_In interface is a simple interface where an application can
just write to the TS_IN interface, which goes to the DVB_ringbuffer
and hence to the bridge. I think, this is all what it should do.

We have 3 application uses cases here, based on different hardware types.

1. Bridge is reading from TS_IN (from a user space application,
streams from a single TS) for sending stream to CA, the normal way
(All things are fine)

2. Bridge is reading from TS_IN (from a user space application,
streams from multiple TS's) for sending to CA. This is also same as
(1) but just that the user space application is writing a "remuxed"
stream to TS_IN

3. Bridge is reading from TS_IN (from a userspace application) The
bridge has multiple DMA channels. The bridge driver can load page
tables from another channel, whereby the bridge is routing to another
interface itself completely. This is a hardware feature, so we don't
need to get data manually in software from one interface to the other.


All this just needs the input path to be generic. An input interface
such as TS_IN can feed the stream to an onboard decoder or any other
post-processor as described with (3)

Only in the case of (2) the application really needs to do some thing
in real life, ie to "Remux". But you can omit out the application to
handle (2). Where somebody can implement it any later stage of time,
if there's any interest. I guess nGene can do (1) and (2)

So, I wonder whether we should name the interface CA itself, where
otherwise it can suit other application use cases as well. In such a
case it becomes not limited to CA alone, to put short. Implementing a
simple buffering alone (the rest of the necessities with the driver),
will make the interface generic.

Regards,
Manu

Re: How to handle independent CA devices

[Oliver Endriss]

On Saturday 18 September 2010 14:23:29 Manu Abraham wrote:
> On Sat, Sep 18, 2010 at 6:17 AM, rjkm <rjkm@metzlerbros.de> wrote:
> > Manu Abraham writes:
> >
> >  > > You still need a mechanism to decide which tuner gets it. First one
> >  > > which opens its own ca device?
> >  > > Sharing the CI (multi-stream decoding) in such an automatic way
> >  > > would also be complicated.
> >  > > I think I will only add such a feature if there is very high demand
> >  > > and rather look into the separate API solution.
> >  >
> >  >
> >  > It would be advantageous, if we do have just a simple input path,
> >  > where it is not restricted for CA/CI alone. I have some hardware over
> >  > here, where it has a DMA_TO_DEVICE channel (other than for the SG
> >  > table), where it can write a TS to any post-processor connected to it,
> >  > such as a CA/CI device, or even a decoder, for example. In short, it
> >  > could be anything, to put short.
> >  >
> >  > In this case, the device can accept processed stream (muxed TS for
> >  > multi-TP TS) for CA, or a single TS/PS for decode on a decoder. You
> >  > can flip some registers for the device, for it to read from userspace,
> >  > or for that DMA channel to read from the hardware page tables of
> >  > another DMA channel which is coming from the tuner.
> >  >
> >  > Maybe, we just need a simple mechanism/ioctl to select the CA/CI input
> >  > for the stream to the bridge. ie like a MUX: a 1:n select per adapter,
> >  > where the CA/CI device has 1 input and there are 'n' sources.
> >
> >
> > It would be nice to have a more general output device. But I have
> > currently no plans to support something like transparent streaming
> > from one input to the output and back inside the driver.
> 
> 
> Maybe it wasn't very clear ... (Streaming from one input to the output
> and back inside the driver what you are implementing is not what I had
> in mind.)
> 
> Currently for any independant CA device what you need is a stream to
> the bridge where it can route the same to the CI slot.
> For a generic device capable of doing any other gimmicks also, what
> you need is an input to the bridge.
> 
> So, what I was trying to say is that, let's not limit the input path
> to CA alone. For explanation sale let's term in as TS_IN
> 
> The TS_In interface is a simple interface where an application can
> just write to the TS_IN interface, which goes to the DVB_ringbuffer
> and hence to the bridge. I think, this is all what it should do.
> 
> We have 3 application uses cases here, based on different hardware types.
> 
> 1. Bridge is reading from TS_IN (from a user space application,
> streams from a single TS) for sending stream to CA, the normal way
> (All things are fine)
> 
> 2. Bridge is reading from TS_IN (from a user space application,
> streams from multiple TS's) for sending to CA. This is also same as
> (1) but just that the user space application is writing a "remuxed"
> stream to TS_IN
> 
> 3. Bridge is reading from TS_IN (from a userspace application) The
> bridge has multiple DMA channels. The bridge driver can load page
> tables from another channel, whereby the bridge is routing to another
> interface itself completely. This is a hardware feature, so we don't
> need to get data manually in software from one interface to the other.
> 
> 
> All this just needs the input path to be generic. An input interface
> such as TS_IN can feed the stream to an onboard decoder or any other
> post-processor as described with (3)
> 
> Only in the case of (2) the application really needs to do some thing
> in real life, ie to "Remux". But you can omit out the application to
> handle (2). Where somebody can implement it any later stage of time,
> if there's any interest. I guess nGene can do (1) and (2)
> 
> So, I wonder whether we should name the interface CA itself, where
> otherwise it can suit other application use cases as well. In such a
> case it becomes not limited to CA alone, to put short. Implementing a
> simple buffering alone (the rest of the necessities with the driver),
> will make the interface generic.

There is already an implementation for some kind of TS input:
dvb-apps/test/test_dvr_play.c can be used to write a TS stream to the
decoder of the old full-featured card (ttpci driver) through the dvr
device. Wouldn't it make sense to use this feature for TS input?

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
----------------------------------------------------------------

Re: [linux-media] How to handle independent CA devices

[Klaus Schmidinger]

On 09.09.2010 23:52, rjkm wrote:
> Hi,
> 
> 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
> ca_pmt. 
> 
> 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.

Here's my 2ct as viewed from VDR:

VDR already has mechanisms that allow independent handling of CAMs
and receiving devices. Out of the box this currently only works for
DVB devices that actually have a frontend and where the 'ca' device
is under the same 'adapter' as the frontend.
I could easily make it skip adapters that have no actual
'frontend' and set up separate cDvbCiAdapter objects for adapters that
only have a 'ca' device and no frontend.

However, VDR always assumes that the data to be recorded comes out of
the 'dvr' device that's under the same adapter as the 'frontend'.
So requiring that VDR would read from the frontend's 'dvr' device,
write to the ca-adapter's 'sec' (or whatever) device, and finally read
from that same 'sec' device again would be something I'd rather avoid.
Besides, what if some PIDs are encrypted, while others are not? Should
the unencrypted ones be read directly from 'dvr' and only the encrypted
ones from 'sec'? That might mess with the proper sequence of the packets.

As for decrypting data from several frontends through one CAM: I don't
see this happening in VDR. Pay tv channels repeat their stuff
often enough to find a slot where everything can be recorded. Others may,
of course, welcome this ability, but I'd like to keep things simple in VDR.
So I'm not against this, I just won't use it in VDR.

As for recording encrypted and decrypting later: that's also something
I don't see being used in VDR (again, mainly for KISS reasons).

So, the bottom line is: I would appreciate an implementation where,
given the configuration you described above, I could, e.g., tune using
/dev/dvb/adapter0/frontend0, read the data stream from /dev/dvb/adapter0/dvr0
as usual, communicate with the CAM through /dev/dvb/adapter2/ca0 and
(which is the tricky part, I guess) "tell" the driver or some library
function to "assign the CAM in /dev/dvb/adapter2/ca0 to the frontend|dvr
in /dev/dvb/adapter0/frontend0|dvr0).

Please forgive me if this sounds like a crazy request - I'm not a driver
developer ;-)

Klaus

Re: [linux-media] How to handle independent CA devices

[rjkm]

Klaus Schmidinger writes:
 > VDR already has mechanisms that allow independent handling of CAMs
 > and receiving devices. Out of the box this currently only works for
 > DVB devices that actually have a frontend and where the 'ca' device
 > is under the same 'adapter' as the frontend.
 > I could easily make it skip adapters that have no actual
 > 'frontend' and set up separate cDvbCiAdapter objects for adapters that
 > only have a 'ca' device and no frontend.
 > 
 > However, VDR always assumes that the data to be recorded comes out of
 > the 'dvr' device that's under the same adapter as the 'frontend'.
 > So requiring that VDR would read from the frontend's 'dvr' device,
 > write to the ca-adapter's 'sec' (or whatever) device, and finally read
 > from that same 'sec' device again would be something I'd rather avoid.
 > Besides, what if some PIDs are encrypted, while others are not? Should
 > the unencrypted ones be read directly from 'dvr' and only the encrypted
 > ones from 'sec'? That might mess with the proper sequence of the packets.
 > 
 > As for decrypting data from several frontends through one CAM: I don't
 > see this happening in VDR. Pay tv channels repeat their stuff
 > often enough to find a slot where everything can be recorded. Others may,
 > of course, welcome this ability, but I'd like to keep things simple in VDR.
 > So I'm not against this, I just won't use it in VDR.
 > 
 > As for recording encrypted and decrypting later: that's also something
 > I don't see being used in VDR (again, mainly for KISS reasons).
 > 
 > So, the bottom line is: I would appreciate an implementation where,
 > given the configuration you described above, I could, e.g., tune using
 > /dev/dvb/adapter0/frontend0, read the data stream from /dev/dvb/adapter0/dvr0
 > as usual, communicate with the CAM through /dev/dvb/adapter2/ca0 and
 > (which is the tricky part, I guess) "tell" the driver or some library
 > function to "assign the CAM in /dev/dvb/adapter2/ca0 to the frontend|dvr
 > in /dev/dvb/adapter0/frontend0|dvr0).



Sorry, no plans here to support it like this right now.


-Ralph

Re: [linux-media] How to handle independent CA devices

[Jasmin J.]

Hello!

It is now 6,5 years since this eMail ir reply to and a lot of things changed
since then.

As there is currently a lot of effort done to get the newest version of the DD
(Digital Devices) drivers into the Kernel, I want to bring up this topic again.
Yes, this eMail is long but it is necessary to explain all very detailed, so
all people can understand the new concepts.



a) First a description of the current situation:

> VDR already has mechanisms that allow independent handling of CAMs
> and receiving devices. Out of the box this currently only works for
> DVB devices that actually have a frontend and where the 'ca' device
> is under the same 'adapter' as the frontend.
This is still the case and it is good so.
What has been changed is ddbridge. Not in the current Kernel version, but in
the vendor version. Ralph implemented the ddbridge parameter adapter_alloc,
which allows to configure where the caX device is allocated. Moreover, he
implemented a sysFS node (ddbridge?/redirect) to control how the TS stream is
routed through ddbridge.

With both together you can implement all required combinations an application
needs. The Default is a complete independent creation of the caX devices into a
separate adapter$ directory. Also the TS stream is *not* routed through the CI
interface, but to the reused secX device (the DD version uses a new device node
ciX for that instead of secX).

In this setup, VDR doesn't see the caX device and therefore doesn't initialize
it. Which is perfectly OK, because it isn't possible to use it anyway.

> So, the bottom line is: I would appreciate an implementation where,
> given the configuration you described above, I could, e.g., tune using
> /dev/dvb/adapter0/frontend0, read the data stream from /dev/dvb/adapter0/dvr0
> as usual, communicate with the CAM through /dev/dvb/adapter2/ca0 and
> (which is the tricky part, I guess) "tell" the driver or some library
> function to "assign the CAM in /dev/dvb/adapter2/ca0 to the frontend|dvr
> in /dev/dvb/adapter0/frontend0|dvr0).
I guess Ralph implemented the sysFS node (ddbridge?/redirect) and
adapter_alloc because of this request from Klaus and of course that the DD
hardware is usable by any other software, too.

If ddbridge is started with the parameter adapter_alloc=3, then the driver
creates the caX and the secX(ciX) device in the same directory as the frontendX
and dvrX devices. Now VDR will recognize the caX device and initialize the CAM.
Additionally, the user needs to select which caX device shall be used for which
tuner via the mentioned sysFS node (ddbridge?/redirect). With this combination
the DD driver behaves like a DVB card which has the CI interface hard wired to
a tuner. It will route the TS stream through the CAM via the CI hardware before
it can be read out of the dvrX device.
Long time this was the only possibility to use the DD CI with a DD tuner.

> As for decrypting data from several frontends through one CAM: I don't
> see this happening in VDR. Pay tv channels repeat their stuff
In the meantime VDR is able do MTD (multi tuner decoding) by rewriting
the PIDs of the TS stream and feed it into the CAM (connected via a DD CI
hardware) with help of a plugin I wrote.

> However, VDR always assumes that the data to be recorded comes out of
> the 'dvr' device that's under the same adapter as the 'frontend'.
> So requiring that VDR would read from the frontend's 'dvr' device,
> write to the ca-adapter's 'sec' (or whatever) device, and finally read
> from that same 'sec' device again would be something I'd rather avoid.
VDR provides a plugin interface for a CI driver since version 2.1.7. With this
interface it is now possible to connect any CI hardware to VDR, if a plugin
does the caX/secX(ciX) device communication.
As mentioned above the DD driver default is creating the caX/secX(ciX) device
in a dedicated adapter$ directory and the TS stream is available at the dvrX
device in another adapter$ directory (possibly encrypted).

My VDR plugin will now search for adapter$ directories with only caX/secX(ciX)
devices and provide them to VDR. VDR itself will not initialize the CAM
interface, because the caX device is not in the same adapter$ directory as the
dvrX device, although it still searches for them. So VDR would still use the
caX device of a DVB card with a hard wired CI interface.

Moreover, VDR is now able to use the DD CI interface together with a DVB device
from another vendor. It is even possible to use the same CAM for several tuners
from different vendors.



b) Things to do:

>From all of the above we see, that a dedicated CI interface (independent from a
tuner) is a very useful piece of hardware.
Currently DD provides the Octopus CI, the DuoFlex CI (single) and the DuoFlex
CI (dual) (if I forget one, I apologize). The cxd2099 driver is used on the
DuoFlex CI (single) card only (AFAIK). The other cards are handled by ddbrigde
directly. Moreover, ddbridge provides is re-using the secX device (or
implementing the ciX device) and not the cxd2099 driver.

1) From that said I really see *no* reason why the cxd2099 driver is in the
staging directory!
This driver is an i2c driver used for the transport of the caX device data
only. Yes, it is for a dedicated CI hardware, but with the new ddbridge core it
can be used in several modes including a hard wired operation (permanent
attached to a specific tuner).
-- So I plan to move this driver from staging/media to the media/i2c directory.

2) When thew DD CI interface is used in the tuner independent mode, the TS
stream needs to be feed through a device to the CAM and read back. This
requires a new device. The dedicated device is a must to use the new feature
MTD implemented by VDR, because only a user space application can rewrite the
PIDs and CA-PMTs from different TS streams.
The current Kernel version of ddbridge uses the secX device for that. The
vendor version of ddbridge renamed secX to ciX. Yes, this breaks the Kernel
API, but secX is depreciated since really long time and not used anymore.
Implementing a new ciX device additionally is too much effort, but renaming it
is not. I would like to hear some comments on this topic.
-- Is it OK to rename secX to ciX or shall we add a new ciX device and keep the
   unused depreciated secX?

Please comment on the "--" questions.

BR,
   Jasmin