> I believe the standard you're referring to is ATVEF-A, see: > > http://www.atvef.com/library/spec1_1a.html > > The ATVEF-A data is on line 21 of the odd frames, along with the CC > data. It's teletext-2 format (so you can differentiate it from CC > data). Try watching some of the mid-afternoon gameshows like Jeopardy > where the CC and T2/ATVEF-A data are very heavily intertwined. > > V4L2 needs a good CC/XDS API standard. I've got three routines I'm > successfully using to extract the data, but I haven't sent them to > Bill Dirks yet for approval. > > When you say "bar code", I think you're talking about the line-21 > signal. It begins with a clock pulse that has seven peaks. This is > followed by a start bit, seven data bits, a parity bit, seven more > data bits, and another parity bit (up to two 7-bit bytes of data per > frame). Watching line 21 (with an analyzer like a Tektronics VM700), > you should always see the clock, the start and the parity bits constant. > > You also may be talking about ATVEF-B or NABTS (which is IP over > video). These use lines 10-20, but I don't know who's using them. > > In either case, you need a hefty processor to do the DSP work in > nearly hard realtime (~2KBytes per scan line per frame to get 2 bytes > of data), or hardware that decodes the data for you. There are a lot > of decoders that do the CC/XDS for you, for example, the BT835 has a > fifo where you can read two bytes at a time across the I2C. Our reference design uses the Philips SAA7114 and the Geode processor. The decoder 'slices' the VBI data and puts it in a special memory region via the video port (VIP). Benchmarking shows that we can get as much as 5MB/second (if that much data is available). The full bandwidth of NABTS would be much less. In the next few years you are going to see alot of new multimedia devices introduced to the market which use the 'live links' that were referred to. Many of these products will be based on Linux and V4L2. -- Peter
