[linux-dvb] DVB API update

Felix Domke tmbinc at elitedvb.net
Tue Sep 18 16:24:09 CEST 2007

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 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

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.

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


More information about the linux-dvb mailing list