[linux-dvb] Re: State of the API?

[Johannes Stezenbach <js@convergence.de>]

Hi,

On Tue, Oct 01, 2002 at 07:41:10AM +0300, Ismo.Peltonen@iptime.fi wrote:
> I'd like to know what's the current state of the LinuxDVB API. As it
> is, I'd benefit greatly in my job from having a stable API for DVB
> receiver devices under Linux. However, the current API (0.9.4, dated
> 2002-02-14 - at least I haven't found a newer API document) is still
> somewhat incomplete, at places incoherent, and generally what I'd call a
> draft document. Of course the version number (<1.0) also indicates the
> draft (or possibly proposal - hey, it's already at .9!) -nature of the
> document.
> 
> However, it's over half a year since the latest published revision (in
> which the version number wasn't bumped), so the question about if it's
> being worked on at all arises, as well as who's the maintainer or is
> there one at all?

I think it won't hurt to add a bit of historic information
to this discussion. I only work for Convergence for two years
now, so if I get something wrong and someone on the list knows
better, then please correct me.

I think that an early version of the DVB-S driver existed which
implemented DVB functionality with some ad hoc extensions to
the V4L API.

If you look at http://linuxtv.org/news.xml and scroll to the
end of the page, you still see an entry about our cooperation
with Nokia. In fact, Nokia had already thought up most of the
Linux DVB API (and maybe implemented it in their own, proprietary
driver). What we got from them was a "confidential" API documentation,
and we agreed to implement this API in our GPLed driver for the
Siemens DVB-S card. We also wrote a publicly available version
of the API documentation from scratch. If may find some references
to the "NAPI" somewhere, the "N" is for "Nokia".

Unfortunately, the Nokia guys who thought up the API never
participated in discussions on this mailing list, and also
did not provide us with updates to their API docs, so there
goes the idea of a common "standard" API...
(IIRC their Open Source, Linux based STB project which used to
be at www.ostdev.net, already had a different driver API.)

Anyway, the situation was that our driver developers did not
feel "authorized" to change the API, and thus had to stick with
it. No API changes were made for quite some time.

At some time in the last year some companies created
the TVLinuxAlliance (http://www.tvlinuxalliance.org/), and many
companies which deal with Linux-based set-top-boxes joined.
Convergence joined too, and submitted the then-current version
of the DVB API for standardisation. The good thing about this
was that the API documentation was greatly improved.
Unfortunately, the TVLinuxAlliance seems to be pretty dead now.

The NEWSTRUCT branch was then created for some drastic internal
driver changes, which we knew would bring some instablilities
along with them. We also used the opportunity to make some
API changes, but all were ad hoc and are still open for discussion.
Mostly we created NEWSTRUCT because we had to create (proprietary)
drivers for new STB hardware, and we also recognize that there are
important applications like VDR that rely on the existing API, and
thus we did not want to break the CVS main line.


> OK, to the API itself.
> 
> The API divides itself into fe, dmx, sec, ca, vdec and adec components.
> 
> While I agree that the basic division looks good (reflects the
> underlying hardware components), I'd like to know why vdec and adec are
> needed, considering the existence of v4l2 API? How much DVB-specific is
> there regarding video and audio decoding? Or is it that v4l2 isn't
> general enough to allow for mpeg2 video/audio decoder control? Or that
> v4l2 didn't exist when the DVB API was written, and v4l just doesn't cut
> it?

At the time the API was created V4L2 had no support for DVB. Also,
IIRC Alan Cox said he didn't like V4L2 because they did color space
transformations in the driver instead of in user space. To us it looked
as if V4L2 would not make it into the kernel.

OTOH, "our" API still relies on V4L for frame grabbing and video
overlay control. There's just no need to invent something new here.
The DVB video and audio devices only take care of controlling the
MPEG decoder (trick modes etc.), so the functionality does not
overlap with V4L.

> Also, I think a network device should be added, as it's essential for
> IPDC (datacast) -enabled devices, whether they have IP-networking
> hardware or provide the network service in software. Piping bits through
> userspace just to get them back to the IP stack doesn't sound very
> efficient..

The DVB net device existed for quite some time, it just wasn't
documented.

> However, when more than one of any of the hardware units are present, a
> problem arises regarding whether there are direct hardware datapaths
> from one component to another. Mainly this situation arises where
> multiple DVB-cards are installed on a PC, but there may be other cases
> where multiple similar components exist on hardware.
> 
> Therefore, it must be clear from the user point of view eg. which demux
> components can the selected frontend feed. I don't think it's practical
> to implement at driver level such functionality where the feed from one
> fe (assuming a TS feed can be accessed) is drawn over bus into memory,
> then fed (again over bus) to another hardware demux. Feeding a full TS
> over bus (twice) requires fairly powerful hardware. And yes, modern PCs
> are fairly powerful hardware in this context.

Some of the API changes in NEWSTRUCT try to address this, but the topic
is quite involved and may need to be rethought when we are confronted
with more sophisticated hardware.


Regards,
Johannes


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.