[linux-dvb] State of the API?

[Ismo.Peltonen@iptime.fi]

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?

Small note about my use of the term "device": I use it both to refer to
a component of the Linux kernel, and a hardware device that may consist
of several components. I don't use "DVB-card" but "DVB-device" because
not every DVB-receiver is a PCI-channel card for PCs. Should be clear in
the context, though.


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?

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

As I haven't worked with DVB-S devices or such devices which incorporate
a smartcard reader, I'm not truly familiar with SEC or CA uses. However,
even if SEC isn't a core component in the API, it should probably be
kept in, as it's quite important in DVB-S receiver implementations.
Also, even if CA isn't needed (nor required hardware implemented) in
all devices, it's an important optional API component.

The core components are, of course fe, and dmx. Without a frontend, the
device isn't capable of receiving DVB-T/C/S signal, and thus isn't a
DVB-receiver device. Also, demux is pretty much required, and in cases
where a hardware demux isn't available, can be implemented completely in
the driver.


In such case where one receiver device with one fe, one dmx, and a
single vdec/adec pair is present, things are easy. The fe feeds dmx,
which again feeds decoders, the output of which can be tapped to using
v4l2 drivers. The fe may or may not be capable of feeding the full TS to
the driver (allowing multiplex-level vdr functionality), and so on.

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.


I'll have to stop now, and could as well send this already. I'll
continue my opinions later, going over the current API and what I think
should be done about the different API components, as well as additions
and removals.

-- 
-----------------------------------------------------------------
Ismo Peltonen                   Axel Digital Oy
Senior Software Architect       Yliopistonkatu 25 A
tel.dir. +358 2 512 8898        FIN-20100 Turku, Finland
mobile   +358 50 539 8697       tel. +358 2 512 8800
Ismo.Peltonen@axeldigital.fi    fax  +358 2 512 8811

-- No attachments (even text) are allowed --
-- Type: application/pgp-signature



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