Peter Lohmann wrote: > > You can have a look at the v4l2 vbi spec available from > > http://www.thedirks.org/v4l2 . This is the api that seems (from the > > header files at least), to be used in the new kernel series. It also > > explains how to get what data from the driver (ie. raw vbi, or just > > teletext/cc). > > Yes, I used this document when planning my driver. BTW, I wrote > a V4L2 driver for the Geode processor. We use a Philips SAA7114, > which can slice CC data or pass along raw VBI data. Unfortunately, > the spec does not appear to have a flag in the set format IOCTL to > specify how the user wants to receive the data. My temporary hack is > to say if the user wants 2 bytes per line, then give them sliced CC. > This is not a good solution for many reasons. But, it works. You're right sliced data services aren't in scope of the v4l2 vbi spec. It was planned but didn't get in due to lack of expertise (amongst RDS and who knows what else). The idea was to pass sliced data as small packets including the data type, field number, line number and payload. Data type is a bit mask, you could request more than one type and mix the packets (of constant length?), eg. Teletext plus VPS for country and network identification. Field and line number tell where the bit slicer found the data, a crop window makes less sense here. I don't really have a brilliant idea how this could fit nicely with streaming i/o. On a historical note, I didn't expect many apps to open the raw vbi interface directly except for special purposes. The late libv4l2 would provide a module opening raw or sliced devices, transcoding (or not) the raw vbi data, and broadcasting (the same) data packets to any number of listeners. It eliminates duplicate decoding efforts and reduces app and driver complexity, so actually the sliced interface would have become the main v4l2 vbi interface. Well, today I wonder if traditional Unix plumbing with standard DV stream formats, such as ETS 300 472 (DVB TTX), isn't better suited. Your idea sounds not completely off, which reasons against did you have in mind? Michael
