[linux-dvb] DVB API update

Felix Domke tmbinc at elitedvb.net
Tue Sep 18 17:10:53 CEST 2007

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

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),
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.


More information about the linux-dvb mailing list