David Kesselring writes: > I have been investigating V4L2 for applicability for a settop device. I > have a couple of concerns that I would like to get some feedback on. > First, I don't see a clear implementation using V4L2 when the > video/audio streams are handled by dedicated chips and the linux driver > just controls those chips. I would like to see V4L2 have the same > interface for manipulating video that is going to a Linux memory as one > going between two chips (i.e. MPEG decoder and video display device). > The other issue I see concerning settops is integration of V4L2 and > LinuxDVB. I don't see much cooperation between the standards at this > point, but I'm new to this. What direction do you think the Linux TV > Alliance will take using these standards? Are there any other projects > that overlap what V4L2 and LinuxDVB are trying to do? > > Looking forward to your comments. I see v4l/v4l2 as an interface for accessing uncompressed video data and displaying it on screen or capturing it. The linux DVB API is concerned with handling compressed streams coming from hardware or memory. We have used v4l in our drivers (Siemens/Haupauge DVBs cards, Margi DVD decoder, em8400 driver (unreleased/ closed source)) for displaying the decoded data on screen when possible. You can also capture the decoded video (not in all cases). For the compressed data handling and especially the tuning and demuxing process we use the new API. It is true that v4l has some tuning ioctls, but only for terrestial analog TV, where you only need to set the frequency. This was not sufficient for DVB. Demuxing (handling the TS stream) is something which was not considered in v4l/v4l2. In a sense you could see the DVB API as an extension of v4l, there is nothing in it that replaces v4l calls (only the frequency call). So if you rename the devices, you have v4l+dvb(dvd). We could also use v4l2 instead of v4l, but there has not been a compelling reason to do so. I you have a look at the tuxzap tools that come with the DVB drivers, you can see that we even use the v4l and the DVB API calls in seperated applications, i.e. tuxzap and ntuxzap for switching channels (DVB API), tuxview for viewing them on the screen (v4l) and even tuxplayer and ntuxplayer for replay and recording (DVB API). They all use different devices. For an in depth description of the DVB API and its devices, have a look at http://www.linuxtv.org/developer/linux_dvb_api.pdf . We have suggested to the Linux TV Alliance to use the DVB API as a starting point. There are still some things missing, like an API for MPEG1/2/4 encoder cards (if you look at the kfir driver you know that we need more than there is in v4l) or some ATSC specific calls, but for DVB we covered all the necessary calls (well maybe user space DMA could be necessary for some applications, but should not pose a problem). Marcus -- --------------------------------------------------------------------- Dr. Marcus Metzler mocm@xxxxxxxxxxxxx http://www.metzlerbros.de mocm@xxxxxxxxxxxxxx http://www.convergence.de Convergence Integrated Media GmbH Rosenthaler Str. 51 D-10178 Berlin ---------------------------------------------------------------------
