[opendtv] Re: New Sony COO bullish on Blu-ray
- From: "Kilroy Hughes" <Kilroy.Hughes@xxxxxxxxxxxxx>
- To: <opendtv@xxxxxxxxxxxxx>
- Date: Wed, 17 May 2006 13:55:25 -0700
I agree there's no threat of critical mass home networking of CE
devices, etc. soon based on the assumption you're talking about "Media
Networks", but I draw a different conclusion based on IP "Data
Networks".
IP data networks are in around a quarter of US households, and they are
a majority of the households with enough CE toys to network. These data
networks are marginal for compressed realtime SD video delivery, and
worse for compressed HD delivery. Getting a bunch of DLNA devices
sharing a wireless network, transcoding to standard MPEG-2 and audio
codecs, image formats, bitrates, transport muxes, RTP/RTSP protocols,
packet prioritization, doing discovery and negotiation, etc. I would
kindly call a "long term project". =20
That theory of the universe is the "push model", where server devices
generate realtime video streams in a standardized wire format and client
devices are dumb video decoders. Network performance demands are very
high (low latency, no packet retransmission, etc.).
An alternate theory of the universe is the "pull model", where files are
read over the network using either a network file system or the Internet
file system HTTP:GET(URL; byteRange). If there are PVRs with gigabytes
of TV shows, optical disc with movies, music collections, photo
collections, etc. sitting on hard disks, a client device that
understands those file types can find them and read them over the data
network and decode them. If you bring a laptop or PPC phone within range
of your WiFi, it's simple to play the TV shows, songs, and photos
sitting on your home computer(s) as long as they're shared on the data
network. CE devices (like HD DVD-V players, game consoles, dedicated
media terminals) that have the decoders and can join a network can
similarly read and play remote files (LAN, or WAN if HTTP). DRM
permitting, this works today with data networks and has a simple
incremental growth path. Client devices have to be smarter, to be full
"players" for some media format(s), not just Program Stream decoders.
There's little distinction with MP3 audio files or JPG photos, but a
media format like DVD-Video makes a big difference.
In order to play a DVD-Video with menus, subtitles, choice of multiple
audio tracks, different languages, aspect ratios, parental rating
versions, etc.; you need a fairly sophisticated DVD-V player engine that
can randomly access interleaved portions of Program Streams sprinkled
around the disc and demux certain PIDs, execute display commands, etc.
to create a decodable linear video stream; then that needs to be
composited with other graphical overlays in decompressed YUV, scaled,
cropped, etc. and changed interactively in response to user interaction.
In push mode, to accomplish full DVD-V functionality, the server would
have to be the DVD player, generate the composited and interactive video
image, then re-encode it to the standard wire format (elementary stream
encode, Program Stream mux, realtime protocol and encapsulation). In
pull mode, the client device would be the DVD player, and the disc or
disc image would just be a remote disc or disk drive on the data
network. The same principle applies to interactive TV, games, Flash,
Web pages, etc.
Pull mode requires minimal network performance and only TCP/IP and file
system level compatibility. The media types don't need to be understood
by all source and sink devices; only a particular media type on a
particular consumption device. The rest of the system will store and
copy media files they don't understand without any need for
compatibility.
Where you need a totally compatible wire format is between every
consumption device and the "glass" and AVR. Uncompressed digital audio
and video are the best solution for that short one-way trip.
Kilroy Hughes
-----Original Message-----
From: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx]
On Behalf Of Ron Economos
Sent: Tuesday, May 16, 2006 15:34
To: opendtv@xxxxxxxxxxxxx
Subject: [opendtv] Re: New Sony COO bullish on Blu-ray
I'm not really trying to defend 1394. Just pointing out
that Kilroy's alternatives don't exist in the cable STB
world (at least not yet).
As a 1394 developer, I'm well aware of the politics
and sentiment towards 1394. It's amazing how an
inanimate object can generate so much animosity.
Even my co-workers often ask the question "When
will 1394 die?". Reminds me of the Neil Young
lyric "it's better to burn out than to fade away".
However, in my mind, the real question is "Are home
networks even viable?". I was given a nice demo last
night of the I-O Data Avel LinkPlayer home networked
device. It's capabilities are pretty impressive and quite
numerous. But at least to me (and I admit that I'm
not much of a CE consumer even though I work in
the industry), that it only had geek appeal and was
way over the head of the average consumer.
My current thought is that the critical mass for home
networks (using any transport) is quite far in the future,
if ever. Even DLNA (which everyone seems to like)
would seem to have a difficult road ahead. But I
may be wrong.
Ron
Craig Birkmaier wrote:
>At 1:45 AM -0700 5/16/06, Ron Economos wrote:
> =20
>
>>Except that the reality of current cable STB's
>>is that they all have ethernet and USB ports,
>>yet none of these interfaces are actually enabled
>>by cable providers.
>>
>>BTW, I'm the designer (along with my JVC cohorts)
>>of the 1394 interface for the HM-DH40000U,
>>HM-DH5U and HM-DT100 D-VHS decks.
>>
>> =20
>>
>
>You're not going to make any progress with this discussion Ron.=20
>Kilroy is simply parroting the MS company line with respect to=20
>Firewire. They never liked it, never will.
>
>Most of the FUD about 1394 as a display interconnect came out of=20
>Redmond. !394 was never intended as a display interconnect, nor was=20
>it designed for the transport of uncompressed bitstreams, although it=20
>can do this with SD video in a pinch.
>
>The whole idea behind 1394 with HDCP was as a device interconnect for=20
>compressed isochronous streams. in a more perfect world, you could=20
>use the 1394 port on that cable box to add more hard drives to=20
>increase the total storage capacity of the system. But this would=20
>also mean that you could take digital content from the cable moguls=20
>and put it on a hard drive that you could connect to any other=20
>machine and play.
>
>Once again we are getting hung up on what is possible in a technical=20
>sense, versus what is ALLOWED in the REAL techno-political world.=20
>1394 with DTCP was supposed to be the political solution that would=20
>allow us to share media across an in-home network. DTCP provides the=20
>content management layer to support handshaking between devices and=20
>the keys that would make sharing content practical in the home, and=20
>profitable for the members of the DTCP royalty pool.
>
>It is ironic that Kilroy points out that 1394 has been a success as a=20
>professional interconnect for digital camcorders and the world of=20
>professional digital media content authoring; a world that Microsoft=20
>does not dominate. In that world you can buy a wide range of devices=20
>from a wide range of vendors, plug them together and do your job.=20
>This is what SHOULD be expected in the digital world we are trying to=20
>create. There are no political barriers to raising the bar; thus we=20
>have seen the growth of digital media authoring platforms for SD to=20
>HD, and the ability to output your content in whatever format/codec=20
>you want/need. Even Sony and Avid have been forced to open up their=20
>systems and codecs, due to the reality that this involves nothing=20
>more than some simple blocks of plug-in code that can be used across=20
>the diverse devices that are used to author content today.
>
>Unfortunately, the same capabilities do not exist for digital media=20
>consumers today. Rather than a vibrant marketplace where you can buy=20
>components from any vendor and plug them together to create your=20
>in-home digital media entertainment configuration, we have a world=20
>filled with roadblocks, and connectors on the backs of boxes that=20
>simply do nothing, because the companies that reluctantly put those=20
>connectors on the boxes will not enable them.
>
>The CE guys keep building components that only work together if you=20
>buy everything from them. Microsoft keeps designing Media Centers=20
>that support only the "Open Technologies" they wish to support, and=20
>only then with layers of Microsoft proprietary code to keep you=20
>inside THEIR walled garden. By the way, although I appreciate the way=20
>the products i buy from Apple work together, they are no better than=20
>Microsoft in terms of being "open."
>
>As I told Bert when I first responded to this thread, we are not=20
>discussion technical issues here. We are talking about a handful of=20
>oligopolists trying desperately to hold onto archaic business models=20
>that would already have been blown away, were it not for their=20
>ability to impede technical innovation while seeking protection from=20
>the politicians, who are cannibalizing our constitutional rights with=20
>respect to its original intent to proliferate intellectual property=20
>to the masses.
>
>And the beat goes on and on and on...
>
>Regards
>Craig
> =20
>
=20
=20
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org=20
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
----------------------------------------------------------------------
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: