[linux-dvb] DVB API update

Michael Hunold hunold at linuxtv.org
Sat Sep 15 21:33:10 CEST 2007


Hello all,

before taking part of this discussion, please make sure to have read the
v4 wiki page:

http://www.linuxtv.org/wiki/index.php/Linux_DVB_API_Version_4

In particular, please read the most recent Linux DVB API v4 documentation:

http://linuxtv.org/downloads/linux-dvb-api-v4/linux-dvb-api-v4-0-3.pdf

Please pay attention especially to chapter 1 "Introduction" and to the
development history.

Thank you!

on 15.09.2007 18:03 Manu Abraham said the following:
> We have an old V4 API that was supposed to be taking over the V3 API.

The v4 API documentation states that v3 is a subset of v4, so it's
possible to port drivers and applications. But this is not likely to
happen and does not make sense (see below).

In short: for x86 PCs with the usual mix of USB and PCI devices, v4 is
not going to replace v3.

> But V4 is considered almost dead due to lack of modern hardware support
> such as SOC's for STB's.

The v4 API is targetted at System-On-a-Chip (SOC) devices, where a CPU,
data (transport stream) input, demultiplexing, audio and video decoding
(with or without post-processing) and output capabilities are on the
same device. The data flow is either handled in hardware of firmware.
Usally this means that during normal decoding operation the main CPU is
idle.

The v4 API is mainly concerned about data flow through that *one*
device, ie. from the data input, through the demuxer, through decoders
and then to the output.

The typical x86 PC with multiple DVB cards (either PCI or USB) does
*not* fit into the scheme. Most of these setups don't have dedicated
audio and video decoders (the work is done by the x86 CPU) and the data
flow is not freely configurable.

Even if you have a TTPCI card, this does not fit into the scheme. If you
have one TTPCI DVB-S card and one USB DVB-T receiver, then you cannot
route the DVB-T data stream to the TTPCI card internally. The data must
be forwarded by the x86 CPU through userspace. Although an kernel API to
handle this would be possible, the v4 API is *not* concernced about this.

> While being on the V3 frontend API overhaul, i found to much dismay that
> it would be much better to revamp V4 into a newer API version such as
> V5, rather than scratching with V3 for ages together, resulting in just
> unnecessary talks and discussions.

The main problem why v4 did not get much attention is because most
developers and users must not be concerned about it at all (see above).

If you work on x86 hardware, then v3 just works, even if it has certain
design flaws.

v4 is most interesting for companies that produce digital TV SoCs. And
there is just a handful of these companies and some of them are not
intersted in open source. So the feedback on v4 was very low most of the
time.

> What i find interesting with the V4 API
> * A better demuxer
> * ARIB extensions

> With both aspects taken into consideration, i am of the thought that we
> should go ahead with taking the best of what we have as a new
> experimental API altogether.

Let's see. From the past I have learned a few things about certain
devices that would not fit into v4 nicely.

Let's wait for the discussion to start up, I'll try to collect some of
the main concerns I have about v4.

> I had talked with Michael and Ralph on this aspect, they were quite
> happy to proceed in that direction. It would be nice to have your views
> on this aspect of going ahead with the new API.

It would be nice if v4 does not bit-rot completely. I cannot take part
as an active developer any more, but I will help anybody to understand
v4 better and help to take over development.

Most critical for v4 is the data flow handling and making a good API to
circumvent any stupid hardware limitations.

But let's wait for some feedback from other people first.

Best regards
Michael Hunold.



More information about the linux-dvb mailing list