[linux-dvb] Re: C/A routing Question

[Johannes Stezenbach <js@convergence.de>]

On Mon, Feb 24, 2003 at 01:40:31PM +0000, Rob.McConnell@Zarlink.Com wrote:
> 
> I agree that as more hardware with PVR capability is becoming available, we
> will have to consider different routing scenarios.  The h/w that I am
> working on allows for parallel/serial TSs from multiple sources as well as
> from C/Is and from a HDD.  Yes, in the HDD case the complete TS that was
> recorded on the HDD can be routed through the C/I.  This allows the TS to
> still be recorded encrypted on the HDD and then decrypted through the C/I
> (keys would have to be stored to prevent them expiring, etc.).

Just to clarify: You want to record a stream containing CATs, ECMs
and possibly EMMs and TDTs, then replay the stream through a CA module which
does all the descrambling? Or do you just want to record the keys/CWs for
the ECD along with the stream and playback through the demux+ECD ?

> I would favour an IOCTL to setup the possible TS sources to the demux and
> then the PID filters should have the choice of which TS source to filter
> on.   For example, if the demux can only handle 2 TS inputs but there are 5
> possible sources, then we need to setup a "router/switch" to implement this
> and each PID filter would have to choose which TS input (#1 or #2).
> 
> Any more thoughts out there?

First we have to define what exactly we mean by "one demux".

Some hardware has a demux unit that takes N-out-of-M input
streams, some of which may possibly be programs streams. Then
you have a number of filters, possibly organized in filter banks,
and you can specify for each filter (or for each bank) what
input stream they apply to.

Or you can have a hardware demux that handles N-out-of-M input streams and
has a number of filters per input stream, which seems to be a simpler
but less flexible model.

(Additionally, the number of filters could vary with the supported
filter features, e.g. length of the section filter mask and support for
negative match.)

Anyway, on the API level we could have one demux device per possible
input stream:
  /dev/dvb/adapter0/demux0
  /dev/dvb/adapter0/demux1
  /dev/dvb/adapter0/demux2

Each demux device can be implemented with a fixed number of filters,
to keep things simple. Then you can use DMX_SET_SOURCE to switch
the input of that demux device. (There's a conceptual difficulty because
we use the same device name to refer to both the whole demux
and to one individual PES or section filter, but that's secondary;
it could be resolved by using O_RDONLY/O_RDWR in the open() call
to distinguish between the intended use, and allow only a single
open with O_RDWR.) In this model, the input parameter in
struct dmx_pes_filter_params is superflous. We still would have to
decide how to route the output of the filter.

What you propose is a single device
  /dev/dvb/adapter0/demux
and an additional parameter for DMX_SET_SOURCE (let's call it
"channel"), and the same additonal parameter in struct
dmx_pes_filter_params and struct dmx_sct_filter_params. Again,
we must decide how to route the output of the filter.


Regards,
Johannes


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.