Felix Domke wrote: > 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 people are against mmap, then i guess we can just abandon it. > > 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. No, not throwing away anything, see my reply to Rainer. The newer features will not be available with the older apps, that's all. You can use the same drivers too. Backward compatibility is achieved by keeping an additional set of ioctl's, so the old stuff will work as it is. Although you will need adjustments for the statistics, but that shouldn't pose a big 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.) Cool Thanks, Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
