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

[Holger Waechtler <holger@convergence.de>]

Hi,

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.

The API documentation you talk about is the one of the 'old' driver. 
This API is pretty stable in the sense that the driver will only get 
bug-fixed, new development is going into an extra branch in CVS, marked 
by the tag NEWSTRUCT.

There you'll find a short HOWTO which describes the API changes.


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

There is no documentation maintainer right now, that's why it is pretty 
outdated. Feel free to contribute!


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

Right now we are using the term "DVB adapter" for similiar reasons. 
"device" was not free anymore because the Nokia boys who designed the 
API mapped linux devices to logical PES and section filters, not to a 
hardware adapter/card/whatever.


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

the DVB API was designed at a time the v4l2 was far from being stable.


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

it's there, check out the NEWSTRUCT branch.


> 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 sec device is now merged into the frontend device, there are a lot 
frontends out there which can generate DiSEqC, so this maps fine to 
current hardware.


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

again, see the NEWSTRUCT branch. There you get for each DVB adapter and 
devfs directory /dev/dvb/adapterX/ with /dev/dvb/adapterX/frontendY and 
/dev/dvb/adapterX/demuxZ entries.

The number of frontends and demuxes per DVB adapter is limited to 4 if 
you don't use devfs, otherwise you can use any number of frontends and 
demux channels.

In our internal drivers this was tested and works fine with DVB receiver 
chipsets with up to 3 demux channels per chip and 2 connected frontends.


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

these routing #defines for frontends are now DMX_FRONTEND_[0...3] and 
for parallel/serial stream inputs of the demultiplexer are called 
DMX_STREAM_[0..3].



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

Suggestions and comments are always welcome
(but please use the current CSV tree;)

Holger



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