[linux-dvb] DVB API update

[Manu Abraham]

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.