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 <[EMAIL PROTECTED] To: [EMAIL PROTECTED] .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: > > [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject. -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.