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

[Rob.McConnell@Zarlink.Com]

Hi Ralph,

I agree that separating the DVR device from the demux would make it more
sensible to support different h/w architectures.  By having a "DVRin"
device, it may also help with h/w that uses DMA transfers from the HDD as
well as any preprocessing of the data.

On the output side, the demux that I am working on at the moment allows for
you to select which PIDs will correspond to the DVRn device.  This is
simply a register with a bit for each PID for that demux device. Again, DMA
transfers to the HDD should be thought about as well.

I was also having a look at the filter specs and I think we should have
more flexibility for setting other criteria such as the following:

      1) Whether to allow full TS packet or just payload through.
      2) Whether to allow duplicate TS packets or to discard them.
      3) Whether to allow or discard TS packets with error flag set.
      4) Whether to match TS packets with the payload unit start indicator
set (after which all packets would be matched).
      5) Whether to match on TS packet priorities.
      6) Whether to allow/disallow TS packets with adaptation field
through.

I suppose we could add these options to the "flag" field in the filter
structs if we wanted to or just have some other IOCTLs to setup the policy.
What do you think?

That's all for now.

Rob ;-)




                                                                                                                                
                      Ralph Metzler                                                                                             
                      <rjkm@metzlerbros        To:       linux-dvb@linuxtv.org                                                  
                      .de>                     cc:                                                                              
                      Sent by:                 Subject:  [linux-dvb] Re: C/A routing Question                                   
                      linux-dvb-bounce@                                                                                         
                      linuxtv.org                                                                                               
                                                                                                                                
                                                                                                                                
                      24-Feb-2003 06:05                                                                                         
                      PM                                                                                                        
                                                                                                                                
                                                                                                                                




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.








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