[opendtv] Re: news: Migrating to advanced video coding; What's the plan?

  • From: "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx>
  • To: <opendtv@xxxxxxxxxxxxx>
  • Date: Mon, 7 Nov 2005 11:33:50 -0500

> > Well, that's amazing, then. Because as recently as
> > 2001 you still hadn't appreciated that there's nothing
> > "locked down" in ATSC, or any other digital scheme
> > based on protocol layers, that can't be "unlocked" with
> > the mere stroke of a pen.

Craig Birkmaier wrote:
>
> You mean like changing the modulation standard to COFDM Bert?

Yes, Craig, even that. The physical layer change, 8-VSB to
COFDM, is analogous to changing an office network from, say,
Token Ring to 100BASE-TX. (I chose those two because they
require a change to every host in the network.) In principle,
sure. ATSC can go to COFDM without changing anything else in
the standard. Just like an office network can migrate from
Token Ring to Ethernet and retain the Windows OS and MS
Office, for example.

In fact, that's the way I would make the switch. I'd retain
the inner interleaver and I'd retain the mandatory HD.

However, this being a one-way broadcast system, a change to
the physical layer affects everyone. Whereas a change to
something further up the protocol stack, such as codec, might
only need to affect a small subset of users. For example,
going to AVC does not necessarily incapacitate all existing
receivers, as long as the MPEG-2 streams are still being
transmitted.

> The article that Bert is spouting off about, suggests that
> it will be very difficult for cable to use H.264 because
> the handful of integrated ATSC receivers that support
> one-way cable would not be able to view channels encoded
> with H.264. Perhaps Bert could send an e-mail to the author
> and tell him that this can easily be corrected with the
> stroke of a pen.

Again, as I already explained, the reason you and the author
of the article make a big deal about the difference is that
DBS users are burdened with the mandatory STB always. So to
them, a new STB which supports AVC is merely a continuation
of the same nuisance they've always put up with. To those
with integrated receivers, instead, it would mean having to
add an STB again, until they buy a new TV set or recording
device. Or, not to discount this competely, some of these
integrated receivers MAY be upgradeable to AVC. Via download
or PROM change.

But fundamentally, the upgradeability is there for all
these schemes, and it's done much the same way. So that
article should have explained these points.

> What is even MORE interesting is the FACT that Bert has
> been the one who has constantly stated the need to define a
> platform and stick with that spec.

Stick with a spec as lomng as possible, sure, until you must
upgrade. No different from what anyone else is doing. You
don't get brownie points for gratuitously making changes to
the network standards.

> > And in 1999, with the simple introduction of A/90, the
> > obvious was accomplished.

> How bizarre. A standard that defines how to encapsulate IP
> data packets and build data carousels, is going to be the
> path to redemption.

It's time you revisit A/90. It addresses the way anything can
be layered above MPEG-2 TS, i.e. above Layer 2. So no, it
won't help for changing the physical layer to COFDM, but it
gives you the way to upgrade codecs, frame rates, pixel
counts, or anything else above Layer 2. These are simply new
applications, like changing from WordPerfect to MS Word.

And, of course, the updates to A/53, to accommodate AVC, were
based on the concepts presented in A/90.

Comments about the supposed inflexibility of ATSC are
meaningless when they don't include an understanding of the
layered protocol model. And layered protocols were
incorporated ay back when, by the Grand Alliance.

Bert

 
 
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:

- Using the UNSUBSCRIBE command in your user configuration settings at 
FreeLists.org 

- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word 
unsubscribe in the subject line.

Other related posts: