Hi Again,
[EMAIL PROTECTED] writes: > > > Both, one section filter for several PIDs and several filters on one > > > PID, would be useful to have on one file descriptor in some special > > > cases. But both make the demuxer more complicated and only move > > > complexity from user space into the kernel. It is not too hard to > > > implement but I would really like to throw it out again ... > > > > As I understand the current API version 3 implementation allows you to > > attach multiple section filters to a single fd, so I think we should keep > No, that is not possible. I am not sure if the documentation mentions > it explicitely, but a DMX_SET_FILTER will overwrite previous settings > and not add to them. My mistake, sorry. ; ) I agree now that having multiple section filters on a single fd is nonsense and just makes the driver too complicated. Having multiple section filters on a single PID is fine and having each of those "attached" to a separate fd is what we want. Having multiple PES filters per fd would be useful for recording to a HDD. > > this in V4. Can I ask in what cases would you have one section filter on > > several PIDs? I have never seen this requirement before, but maybe you > > have come across this. > You could set one filter e.g. for PMTs but on all PMT PIDs from the > PAT. You can still keep them apart by reading the SID from the packet. > But I do not think this is worth adding all the complexity to the > driver. Agreed. > > OK, I just wanted to make sure that this was the correct method to use. I > > like the idea of having a separate logical demux device for each > > simultaneous input source. : ) > It depends on how closely you want to stay to the actual hardware > capabilities. The hardwares I know about have N demuxes and M inputs > and each demux can choose one input. So, it makes sense to have separate input > and demux devices and then tell the demux which one to use. > If each input has its own demux this would be a special case and if > e.g. it is not possible to use input 1 with demux 2 you just return > -EINVAL if the app tries to set that. Agreed. > > What about leaving the demux device alone and allowing it to choose say > > front_end x = C/A module input. Then we > > need a C/A device that can set it's source to say external demod #1. In > > this case, h/w that does have the ability to route an input TS from say an > > external demod to a C/A module and then into the logical demux device is > > covered. Also, h/w that does not have a C/A or C/I router will still > > function the same i.e. demux selects the required front_end. > That would be one possible way. > Btw., I have a question regarding the new CI devices and how to differentiate > several CI adapters (not that I know receivers with more than one). > If you have one CI device for each slot, you might want to call > them ci0_0, ci0_1, ci1_1 etc. where the first number is the CI adapter > unit and the second the slot. Your source setting calls to ciN_0 would > be valid for all ciN_X and so on. I have no problems with the adapter/slot method. Any more comments/suggestions folks? Rob : ) -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
