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.
