By "below discussion", I meant using a DSP, hardware or significant amounts of
processor time to decode the info in lines 10-20. All that effort addresses
the problem of decoding ATVEF data from an analog video stream. Obviously the
same data could be sent in an MPEG stream.
The other problem is the bandwidth of the analog ATVEF data. I think its
maximum is (please correct me if I'm wrong):
2 bytes per line * 11 lines * 60 fields per second = 1320 bytes / second =
10.5 Kbits / second.
You can't send a lot of web pages in that little data. Compare that to data in
an MPEG stream, where the overall stream is (say) 5 Mbits / second, or around
500x as much data as can be sent in analog. Even if only 2% of the MPEG stream
was allocated to ATVEF data, that would allow 10x as much data to be sent over
digital transport, compared to analog. Content providers would have to: 1)
author two different sets of data (web pages etc.) 2) author only what fits in
the analog bandwidth or 3) author only for digital. My guess is that 3) is
what will happen.
Peter Kaczowka
Chris Worley wrote:
> Peter Kaczowka wrote:
>
> > 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?
>
> Yes and No...
>
> The current ATVEF-A standard is for analog video, but the standard is
> easily separated from it's transport.
>
> >With digital video, ATVEF-type information
> > wouldn't be encoded in specific scanlines, would it?
>
> No. But it would be encoded in private mpeg frames. The ATVEF-A
> standard is a little bit more than just "tell the viewer to refer to
> this URL" one-way broadcast HTMLish data. It nicely encompasses
> everything you'd want to do with interactive TV from the broadcast
> perspective.
>
> In the reference I provided, there's only one small mention of the
> actual transport (it's on teletext-2). Everything else concerns those
> things you might want to setup for a broadcast HTML.
>
> > Does ATVEF address
> > digital video?
>
> Such a digital standard is in the works. Every digital packet has an
> ID. You need a few ID's to represent a channel; at a minimum, one for
> video and two for audio packets. If you want closed captioning or
> subtitles, those too would have unique ID's for the channel. Another
> ID might be for IP data, and another ID might be for ATVEF-A data (no
> need to piggy-back with CC, like with the analog).
>
> Chris
>
> _______________________________________________
> Video4linux-list mailing list
> Video4linux-list@xxxxxxxxxx
> https://listman.redhat.com/mailman/listinfo/video4linux-list
