On Thu, 4 Oct 2007, 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. > > This is more or less what is done now, except that everything is > in the kernel. There is an advantage to doing software filtering in the kernel. Often a TS has many more programs that one is interested in, and so many frames will be filter out by the demuxer. By doing demuxing in the kernel, one can filter out the uninteresting packets as soon as possible. Now, filtered packets never make it out of the device DMA buffer into the dvr buffer and are never copied out of the dvr buffer into userspace. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb