Thanks for your comments. VBI data is, for alot of people, a mundane topic. But, because it allows you to associate data with a video stream on legacy analog video standards, and because of the emergence of internet-enabled devices, there is huge potential for it. > IMO VIDIOC_QUERYCAP is already overloaded with context dependant > information we don't need here, it should focus on the kernel interface > capabilities and not rough hardware hints. Other device types have > VIDIOC_ENUM ioctls to enumerate formats, shouldn't we follow the major > design principle? We could name the available formats, if only to tell > there's a format the application fails to interpret because it's a > custom format or has been defined at a later date. Also space for > additional per format details we want to know, eg. hardware limitations. > (I wonder why v4l2_format has a union and v4l2_fmtdesc hasn't?) Yes, VIDIOC_ENUMSTD is probably a good way to go. The driver could return a string (e.g., "CC525" or "US Closed Caption") with the number of bytes per read() (in this case, 2). This way the standard would not need to hard-code (pre-determine) the expected number of bytes per sample by data type. This would also reduce the bloat that you also mentioned. > A remarkable versatile device. Is bit/byte-endianess across devices an > issue? Probably not. How about DMA, advantageous to store payload in > adjacent locations? Difficulties because DMA writes additional > information, padding necessary? How about output devices? The ones I'm > familiar with are SAA 7111A and 7125 (output), they both only support > CC525 polling via i2c. We can either use this /dev/vbi as both VBI-in and VBI-out, or, use /dev/vbi for VBI-in and /dev/vout for VBI-out. The /dev/vout interface is odd, to me, because it appears to have been written around an MPEG encoder and primarily used for DVD playback. This is good, but the notion of /dev/vout should include all video encoder applications. Chrontel , Conexant (formerly Rockwell Semiconductor, formerly Brooktree, and soon to be an entirely different company) and Geode each have encoders that can take your VGA desktop and put it on a TV. This is popular for computer games, classroom instruction, set-top boxes, and other applications. >From http://www.thedirks.org/v4l2/v4l2out.htm : "Video output devices can take digitized images from computer memory, such as those captured from a capture device, and convert them into a video signal. A video signal is a standard analog signal such as a PAL or NTSC signal, or a digital video signal such as an ITU-R601, or DV signal. A video output device can also output video to a graphics display frame buffer or overlay device." For the driver that I am working on (Geode chipset), we will support /dev/video, /dev/vbi, and /dev/vout. The practical application for this will be a 'set-top box'. That is, the TV set will be for watching television and surfing the web. Currently, we use /dev/vout for overlay (and alpha blending). I seems to me that since video overlay exists in video controller memory that it should belong in /dev/video and not /dev/vout. The notion of /dev/vout should be for what comes off of the composite or S-video connector: analog video with embedded VBI data. Anyway, we have this all in one driver which advertises itself as all 3 devices. > It should be safe to assume all video data services are, and will be, > line oriented and deliver in small units, or has anyone other news? How > about DVB, is it something to consider or not? (Judging from the current > pace, by the time v4l2 will make it into a stable kernel I have no hope > any analogue device will still remain in use... :-) The data services traditionally handled through the VBI of analog signals will become special streams within the MPEG standard. So, it would be a completely different animal. I don't think analog TV sets will go away in my lifetime. So, this API will be around. Thoughts? -- Peter
