Thierry Lelegard wrote: >> What do you do about devices having HW filters ? Then you will need >> to implement them in userland, in your view, which brings in inconsistent >> userspace interfaces. > > I addressed this in a previous mail of this thread. The device driver > should report capabilities in a standard way: able to demux PIDs, > able to demux PES packets, etc. The public API of the userland > library offers a standard demux API to the application. Internally, > the library checks if the frontend device can do hardware demux. > It it can, the library invokes it. If it can't, the library > reads the TS and does software demux. > Agreed, although this moves part of the hardware specific information such as how many filters a device can provide etc etc to the userspace. It will look a bit more cleaner (in kernel) if done that way. Also for newer devices there would be routable filters for some specifc things and so on. Now (suppose that we have moved out to userspace) that we have filtering in userland, now all the hardware specific ugliness comes to userspace. > This is more or less what is done now, except that everything is > in the kernel. ACK. > > But I agree that this is a theoretical discussion. The reality is > different. Linux-dvb is entirely in the kernel and we have to live > with that. Starting a new incompatible dvb framework would we create > more trouble than solving problems. > :) Although that said, for some delivery systems, we will need the vanilla TS out. ie there is no straight away demux (practically possible) in kernel So it might not be completely theoretical, some amounts we can apply it. ie the only concept is we shouldn't break the existing behaviour of the old devices. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
