You mention "the next few years" - but in the next few years video will be going digital; much of it already is. Isn't all the below discussion relevant only to analog video? With digital video, ATVEF-type information wouldn't be encoded in specific scanlines, would it? Does ATVEF address digital video? Peter Kaczowka Peter Lohmann wrote: > > 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 > > _______________________________________________ > Video4linux-list mailing list > Video4linux-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/video4linux-list