Sorry to give my two cents, but... Manu Abraham wrote: > The case of a 20Mbps stream getting recorded is not a great thing. when > you have a TS with symbol rate 27.5Msps, (capturing the complete TS) the > normal TS itself is about 27Mbps (in a very crude rounded off case) > So, the situation that you have isn't larger than a situation having a > normal single DVB-S card. The current API doesn't even allow you to properly record more than one channel (unless you do re-filtering in userspace). The current API doesn't allow you to do simple TS filters. The current API doesn't allow you to tune into -S2 transponders. The current API doesn't allow you to properly sync against a hardware decoder. It doesn't allow you to implement proper trick modes. That are all real-world problems. Explain a *user* why he can't record two channels at once, just because the API doesn't let you do that! None of these problems get solved with the current v4 aproach, simply because the API is unfinished, the implementation non-final, and there are, how many?, like *2* hardware devices supported, and not a single real userspace application using that API. Yes, technically it could solve everything, but practically, it doesn't help a bit. And now you try to complicate not only the API but also the device driver layer again, justified by a few percent CPU saving in a highly theoretical scenario? (And I doubt that a zero-copy mmap of DMA buffers fits well together with hardware demuxes, but that's another topic.) If your argument is "embedded processors have less power": Yes, they have. But a normal embedded 300Mhz CPU will still be able to record two complete TS streams to HDD, including all userspace overhead, with a software demux. The problem you're talking about is just not a real world problem, not even on slow systems with a memcpy()-performance <100MB/s. If we solve this problem like we have "solved" it last time (inventing an API which is so complex that nobody implements or uses), we won't ever fix the real world problems stated above. Keep it simple, *please*. Improve it gradually. Don't throw away everything (device support, user base, source/binary compatibility) for fixing a non-issue. The current API is fine. It really needs some tweaks here and there, but otherwise it's ok. (If want to discuss how we could improve the existing API to fix the problems mentioned above, I'd be happy to take part of it. I belive i have some simple, non-intrusive changes which take care of most of this stuff.) Felix _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
