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.
Chris
Sherm Pendley wrote:
> On Tuesday, January 2, 2001, at 12:13 PM, Wandered Inn wrote:
>
>
>> Peter Lohmann wrote:
>>
>>>
>>>
>>>>> Eric Jorgensen wrote:
>>>>>
>>>>>
>>>>>> The data seemed to update a couple times a second, but didn't seem
>>>>>> to be entirely regular. Visually, it resembles a barcode.
>>>>>>
>>>>>> So, I snapped a picture. Anybody know what this is?
>>>>>
>>>>> Good thing you mentioned Arthur, since it made it easier to track down
>>>>
>>> the
>>>
>>>>> likely culprit:
>>>>>
>>>>> http://www.pbs.org/digitaltv/dataNS.html
>>>>>
>>>>> I don't even want to know what they do with the Barney version.
>>>>
>>>> Figures Microsoft would encode data in the viewable area. (Even if
>>>> most folks will never view it)
>>>
>>>
>>> FWIW, this is the WebTV for Windows data -- program guide, etc. With
>>> Win98 you can optionally install this if you have a compatible decoder
>>> card (ATI All-in-Wonder, WinTV).
>>
>>
>> Following the link noted above, it indicates that it is used to interact
>> with M$ interactive toys (Barney, Arthur..) Doesn't say anything about
>> webtv.
>
>
> Better late than never, so here goes... :-)
>
> I work at WGBH Interactive, which produced and supported the server-side programming
>for the Barney and Arthur Actimates. I didn't personally program it, but the guy who
>did is two doors down the hall. I can tell you with reasonable authority that yes,
>the same encoding method is used to send that data as is used to send "enhanced" data
>to WebTV Plus.
>
> The catch is, even though the low-level protocol used to encode the data for
>transmission within a broadcast signal is the same, the data format and
>application-level protocols are incompatible. It's sort of like how HTTP, SMTP, FTP,
>et al are different, even though at a lower level they all share the same transport
>mechanism - TCP/IP.
>
> We use the same method, btw, to encode the web "markers" that you see on Nova. If
>you have a WebTV Plus, those are live links.
>
> sherm--
>
>
>
> _______________________________________________
> Video4linux-list mailing list
> [EMAIL PROTECTED]
> https://listman.redhat.com/mailman/listinfo/video4linux-list
_______________________________________________
Video4linux-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/video4linux-list
