Felix Domke wrote: > 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. I think it would be nice to have it. >> 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)? As it is, without any change. I think Johannes did the great job of confusing people. >>> (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). This sounds fine to me. > * "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. Mostly USB devices, afaik. Any other devices that you would like to mention ? > > * "The current API doesn't allow you to tune into -S2 transponders." > We have solved this one already, drivers also exists, people watch S2 streams as well > I have to admit that I haven't followed the "multiproto" discussion much > (i'm certainly not a frontend guy). What i pushed out last, is out here: http://jusst.de/manu/04-Jul-07/stb0899.tar.bz2 It is a Hg tree as a tarball, uncompressing it, you can see the changes in there. (There are some changes local on my machine, which i haven't pushed out yet, but basically most of it is there, the complexity hidden in dvb-core.) > 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. I don't have hardware decoders, use a SW decoder over here. > > * "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. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
