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

[Ralph Metzler <rjkm@metzlerbros.de>]

Johannes Stezenbach writes:
 > Ralph Metzler wrote:
 > > Rob.McConnell@Zarlink.Com writes:
 > >  > 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.).
 > > 
 > > The whole input handling has to be worked on.
 > > The DVR device does not properly map on any newer hardware. One TS
 > > ouput usually has nothing to do with any specific input.
 > > Calls for all the things you mention will have to be added.
 > 
 > Could you be more specific?
 > 
 > For input we already have four dvr devices in dmx_source_t.
 > IMHO we could use similar definitions for the sinks in dmx_output_t,
 > or maybe use a different approach for output routing.

I think it is problematic to use the dvr devices for input and
output.
If they are a source then for the hardware they are just another
input just like the other real frontends. 
If they are an output it depends on the hardware. For some hardware
they are connected to the filters of one specific demux channel, for 
other hardware they are completely independent and only share the
input of one demux channel.
In general the output of dvrN has little to do with the input of dvrN.
Having them mixed in one device is confusing.

What I propose is: 

- Move the memory frontends to separate devices.
  Either also call them frontend with type memory frontend
  or call them memfrontend, mfrontend, dvrin, ... whatever
  They should offer mmap, write, etc. maybe even a software controlled
  rate control (some chips have it in hardware) to allow for decent 
  non-blocking writing.
  Each demuxN can select which frontend (no matter if real or memory)
  to use as input.

- Keep dvr for output only. 
  Do not allow dvr as output for demux device filters but use separate
  calls. Here it is enough to use a PID bitmask to select PIDs.
  dvrN should still be associated with demuxN since even on hardware with 
  separate "DVR filters" they usually share the input with one demux
  channel.
  On hardware where filters of demuxN have to be used to create the dvrN 
  output the driver hides it and uses them internally. The number of 
  selectable PIDs is restricted by hardware and can be asked via ioctl.
  With software filters one could even allow to have several opens
  of dvrNs and feed different PID arrays to each dvrN. 


Ralph


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