I agree HDTV is a long way off, but not digital TV, which is the same picture size as analog (~ 640x480 for NTSC) but digital. DirectTV is digital TV, at roughly 4-5 Mbits / second. AT&T is offering digital TV all over the place, or at least claims to be - I'll see when they offer it to me, since they now own my cable provider (Cablevision in Central MA US). Some estimate that within two years more US homes will have digital TV than will have broadband Internet access. There are already digital cable-ready TVs, but you won't need one of them; just a new cable box, with an MPEG decoder in it. That's what you get when you buy DirectTV, so it's not a major capital investment. Cable companies want to go to (non-HDTV) digital because they can get more digital than analog channels on the same wire, and they are running out of analog channel space. I can see doing the CC/XDS decode from analog. That's where closed-captions are, and the info that WebTV uses. I find it hard to believe that analog ATVEF will catch on. By the time ATVEF content is present in "broadcasts" most people who would use it will be using digital cable or satellite. Note I say "most people who would use it", rather than "most people". Many people will stay with analog (assuming their cable company continues to even support it!), but those people will probably never use ATVEF. Don't forget, around 40% of US homes don't currently have a PC or Internet access, and don't plan on getting either. It's hard to imagine those homes using ATVEF any time soon. Peter Kaczowka Peter Lohmann 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? 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 > > > > _______________________________________________ > Video4linux-list mailing list > Video4linux-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/video4linux-list
