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 [EMAIL PROTECTED] fax +358 2 512 8811 -- No attachments (even text) are allowed -- -- Type: application/pgp-signature -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
