Manu Abraham wrote: > Felix Domke wrote: >> 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. I'm not against mmap, I'm against using development resources for implementing it. I can't see the big show-stopper in this issue. So, seriously: Is there anybody here who *needs* this, based on his own experience? If yes, I'll might change my mind. > 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. Will older hardware drivers be compatible with a new dvb-core (more than maybe changing some identifiers)? >> (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 ok, let's start: * "The current API doesn't even allow you to properly record more than one channel (unless you do re-filtering in userspace)." This is because we have only this ugly "DVR filter" mechanism. My approach is to add a "DMX_ADD_PID" ioctl, similar to DMX_SET_FILTER. See http://www.spinics.net/lists/linux-dvb/msg09258.html for details (the b.) part of it). * "The current API doesn't allow you to do simple TS filters." Again, in http://www.spinics.net/lists/linux-dvb/msg09258.html I came up with my solution, however people noted that this might break FF cards due. This can probably be avoided by using a better value for DMX_TAP_TS. Note that the dvb-core implementation is trivial, as hardware drivers are already supporting TS filtering. It's just not exposed to userspace. * "The current API doesn't allow you to tune into -S2 transponders." I have to admit that I haven't followed the "multiproto" discussion much (i'm certainly not a frontend guy). My naive approach back then was to implement a "FE_SET_SYSTEM"-ioctl, which would specificy the system ("DVB-S2" for example) for the frontend. The following FE_SET_FRONTEND etc. would operate on the previously set system, with their own structure (not necessarily a union of all supported types anymore). There have been a number of counter arguments of this approach, and it predated the "multiproto" stuff, so this is probably obsolete. I'm happy here with any approach which doesn't break binary compatibility: A *new* application, compiled against new API headers, running on an *old* API should still be able to tune DVB-S, -C, -T (i.e. the currently supported delivery systems). * "The current API doesn't allow you to properly sync against a hardware decoder." We have DMX_GET_STC, but I propose additionally a VIDEO_GET_STC (in case you are playing without a demux, i.e. by writing data into video0), and VIDEO_GET_PTS, to get the PTS of the last displayed frame. * "It doesn't allow you to implement proper trick modes." For this I don't have a solution, and a proper trick mode playback is probably out of scope for this API. It's probably not too interesting for non-embedded platforms with hardware decoders. Take the example of a playing an mpeg stream backwards. This includes parsing the frame types, issuing frames in the correct order together with private instructions for the MPEG decoder on which pictures should be displayed and which one should not. I'm not sure if this can even be handled in a generic, hardware-independent way, so it will be a hard part. Felix _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
