> 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
For digital video (MPEG), these data streams will be separate data
packets.
Analog video won't be going away anytime soon. Alot of people thought
HDTV would have reached critical mass last Fall, but much of it failed to
materialize. This is blamed for some of these stocks (e.g., HAUP) taking
a hit. Here in the US Monday Night Football looks great on HDTV, but
I don't have the money to fork over for an expensive TV -- especially
when there is not alot of content out there made for it. I think even MNF
stopped broadcasting in HD.
-- Peter
> 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
>
>
>
> _______________________________________________
> Video4linux-list mailing list
> Video4linux-list@xxxxxxxxxx
> https://listman.redhat.com/mailman/listinfo/video4linux-list
>
