[opendtv] Re: First look at ATSC HD Broadcast

  • From: Craig Birkmaier <craig@xxxxxxxxx>
  • To: opendtv@xxxxxxxxxxxxx
  • Date: Sat, 11 Jun 2005 07:43:29 -0400

At 11:21 AM -0400 6/10/05, John Shutt wrote:
>Craig,
>
>The PC model is not valid, because as software codecs become more
>sophisticated, more memory and computing power is required.  I cannot run
>WM9 on a 133 MHz Pentium machine.  It is almost impossible to design a
>software updatable STB that anticipates the processor and memory
>requirements of some unknown future codec.

First, I am not talking about the PC model. There is no question that 
many of the components are the same, but the requirements for PCs and 
STBs are NOT the same.

I agree that one cannot fully anticipate future requirements, and 
I'll go further and say that no box is going to last as long as an 
NTSC receiver has lasted. The dynamics of the marketplace are 
completely different today than when analog TV was invented, and it 
is doubtful that ANY industry or company will be able to control 
competition and product evolution for as long as broadcasters have 
enjoyed.

That being said, you completely missed the point in my previous posts.

When is the last time that you had a problem playing an audio file 
because your computer did  not have enough horsepower to decompress 
the file? Audio codecs keep evolving, but their computational 
requirements are well within the grasp of almost any computer built 
in the past decade.

Video is traveling the same road as audio, it is just lagging by a 
decade because the computational requirements are an order of 
magnitude (or more)  greater, But Moore's Law has a way of leveling 
the playing field. A few more turns of the Moore's Law crank and 
there will be enough horsepower to handle anything that comes down 
the road in the future.

Video also has another problem - the bandwidth requirements to 
process uncompressed image  samples is a major bottleneck, especially 
for HD formats. This is not a CPU problem, but rather a graphics 
subsystem issue. That old 133 MHz Windows machine can probably do a 
decent job decompressing video samples, but it struggles to get them 
to the screen. Any STB design is going to be built around a GPU that 
is capable of refreshing the attached display, at the level of 
resolution intended. And yes, there will be boxes designed for SD and 
HD output. at least for a few more years until the cost to output 
both has dropped to the noise level.

>Also, hardware decoders are much faster and cheaper than software decoders,
>and we are talking about a market where saving five cents per unit matters
>most.

  Where do you come up with this stuff?

Hardware decoders are not faster than software decoders, if they are 
both producing the uncompressed samples at the display refresh rate. 
In reality they are the same.

The only difference is that for one, someone invested in the 
development of a chip that pipelines the tasks that are required to 
decode a video stream, while in the other, the tasks are spread 
across a general purpose computational appliance.

It is not realistic to say one is cheaper than the other. It really 
depends on the feature set that the appliance must support. As you 
add more features, you may need more chips to support them with the 
dedicated ASIC approach. On the other hand, the general computational 
approach allows you to support a wider range of features, and to 
upgrade the product after it has been sold. Clearly there are 
tradeoffs, and not every appliance needs the ability to support a 
wide range of functions.

Take Apple's iTunes and iPod for example. iTunes is a software 
application running on a computer. It has a rich set of features 
designed to take full advantage of the platform underneath. For 
example, there is a screen display mode that synthesizes graphics 
based on the  music that is playing at any time. It connects to the 
Internet to access music databases so that tracks can be identified 
when they are digitized. It connects to the iTunes store and handles 
e-commerce transactions so that you can find and buy music. And it 
allows you to organize your music and burn CDs based on playlists 
that you have created. And, it is a jukebox that can be connected to 
the compute's speakers, or to networked devices like Apple's Airport 
Express, to enjoy your music around your home or office.

The iPod is a portable music player that leverages your iTunes music 
collections. It synchronizes with iTunes when the iPod is connected 
to your computer, and it even allows other types of data to be stored 
on the iPod hard disk. But the iPod is not a computer. It has some of 
the same components, but the design has been optimized for the 
purpose of making your music collection portable. It offers only a 
subset of the functionality of iTunes.

So heres the real bottom line.

If all you want is a simple network attach device that only decodes 
video and audio, providing outputs to a display and speakers, then 
the dedicated ASIC approach may be the cheapest rout. An ATSC, cable 
or DBS decoder could be designed in this manner as a little module 
that connects between the "network" and the TV, much like Airport 
express, which is just a WiFi node with audio outputs.

But a more sophisticated STB is going to look much more like a PC. It 
will need multiple network interfaces for the demods needed for 
cable, DBS, or off air, and one or more data network interfaces 
(E-net, WiFi, powerline etc).And it will need a CPU to manage these 
functions.

It will need a graphic subsystem capable of outputting high quality 
video to the screen with graphics overlay capabilities. If the system 
can attach to the Internet it will need to convert HTML and a long 
list of data objects into content that can be presented to the 
viewer. It will need to support an EPG and navigation functions. If 
it offers PVR functionality the box will need more demods (and 
possibly and encoder), a hard disk, user interface and integration of 
local content with the EPG.

I could keep going, but I think you may be getting the point. 
Television and home entertainment computing are traveling down a 
convergent path; within a decade, any computer will be able to handle 
any form of (consumer) video with ease. We are approaching the point 
where video will cease to be a significant computational problem; the 
point where upgrading codecs will be feasible without the need to 
upgrade the underlying hardware.

How long will these new digital media appliances remain useful?

Clearly innovation will continue, and new features will be added to 
products to encourage upgrades. It is already clear that cable and 
DBS (and the telcos too), do not expect receivers to have a very long 
life - five to 7 years is plenty to amortize these boxes.

So the question is simple:

As a broadcaster, do you want to pre-define your future based on a 
platform definition that DOES NOT evolve, while you main competitors 
keep pushing the envelope?

Sounds like a prescription for certain death to me.

On the other hand, this is exactly what is happening today. The media 
conglomerates are pushing the envelope via cable and DBS, letting 
them deal with all the stuff that broadcasters cannot (or choose not 
to) support  - conditional access, billing, customer service, PVRs, 
VOD etc.  And broadcasters are stuck with a platform that is already 
obsolete, that does not work very well to boot.

So if you want broadcasting to die, just keep thinking in terms of a 
platform that is stuck in the last century with no way to evolve.

Regards
Craig

 
 
----------------------------------------------------------------------
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: