[Technology Report]
Get Ready For The Multimedia Mess
Are mixed multimedia machinations possible for the home, or are they just a pipe dream? It all depends on the software infrastructure.
William Wong
ED Online ID #19051
June 19, 2008
Copyright © 2006 Penton Media, Inc., All rights reserved. Printing of this document is for personal use only.
Reprints
The setting sun is a pleasant
sight while driving home. I’m
listening to satellite radio and
a call comes in. At my verbal
request, the car’s media system
switches off the music
and answers the phone. I
continue the conversation as
I pull into the garage and switch the call to my
home line as I exit the car. Continuing to chat,
I move into a room with an HDTV and switch to
video conferencing. The call ends and the radio
program resumes from the point of interruption.
Finally, I use a graphic control panel to
turn off the audio, open the shades, and check
my e-mail.
This sci-fi scenario isn’t too farfetched. But
while the industry moves in this direction, the
coordination and standards necessary for such
a level of support are lacking. We currently
have a Tower of Babel when it comes to device
communication within the home and car.
Pockets of devices can communicate with each
other, but they tend to be isolated islands,
such as security systems or multimedia rooms.
The problem arises because of the many
issues involved, such as bandwidth requirements,
quality of service (QoS), digital rights
management, security, authentication, and
authorization. Groups and standards are growing
and emerging, but there’s still a long way to
go before a truly seamless multimedia communications
network becomes reality, especially
when it involves multiple vendors.
Established standards have set the groundwork
for much of the standardization. TCP/IP
and Ethernet are critical parts of the equation,
though consumers typically are isolated from
these details. For example, Ethernet ports are
common on Blu-ray players, but IEEE-1394b
links are found on HDTV set-top boxes. Both
support TCP/IP protocols.
HDTVs such as Samsung’s large-screen
HL-T5687 DLP model use HDMI (High-Definition
Multimedia Interface) connections (Figure 1
and Figure 2). This high-speed serial interconnect can
be found in all electronic entertainment stores,
but most consumers don’t know that highspeed
switching is occurring in devices such as
HDMI audio amplifier/receivers.
Interestingly enough, HDTVs like Sony’s
Bravia tie together the high-speed communication
via HDMI and low-speed control with an
802.15.4 remote-control protocol based on
Freescale’s 802.15.4 entertainment control
platform (ECP) (see “Remote Controls Go From
IR To IF” at www.electronicdesign.com, ED
Online 16523).
The advantage we have today is that the
acceptable limits have been reached. For
example, HDMI and HDTV standards set an
acceptable limit for most devices that will enter
the market over the next 10 years. They aren’t
the absolute limit, though, because HDMI and
HDTV are defined past the 1080p standard
commonly accepted as the high end for consumer
video.
NETWORKING HARDWARE
Much of the standardization work has centered
around the hardware, usually pushing
performance to the limits. Wi-Fi, Ethernet,
and HDMI are joined by phoneline links from
the 320-Mbit/s HomePNA Alliance to the
200-Mbit/s Homeplug Powerline Alliance.
The Multimedia over Coax Alliance (MoCA)
targets existing in-home cable networks with
175-Mbit/s throughput.
These high-speed links can deliver highquality
video and often HD video in uncompressed
form. The primary limitations occur
when they’re dealing with multiple streams of
HD video, but they usually utilize compression
to handle those streams.
The new HomeGrid Forum was formed to
unify this fragmented hardware market with
a common physical-layer/media-accesscontrol
(PHY/MAC) approach. It supports the
work of the International Telecommunication Union (ITU-T) G.hn committee.
Concentrating on
the hardware and low-end
software levels is useful
and can simplify the job
significantly, but it doesn’t
force interoperability at
the application level. Of
course, resolving currently
inconsistent networking
platforms and protocols
will be a challenge.
Essentially, the homemultimedia
data plane
doesn’t address the control
or management plane. This
is where infrared control
units such as Logitech’s
Harmony 1000 attempt
to control multiple devices, albeit
at a very local and limited level (see “Logitech
Harmony 1000,” ED Online 17953). The result
is quite useful, but it’s a far cry from an integrated
system.
Likewise, the standardization of profiles in
the ZigBee Alliance is enabling interoperability
among control and status devices in a range of
environments, such as lighting control. As with
many other networks, interoperability among
devices within the homogeneous network is
possible and sometimes automatic. However,
transitioning this control and information to or
through other networks generally isn’t possible.
Continue on Page 2
The integration of all types
of networks and control systems
will be required to combine
the islands of devices,
allowing for more general solutions.
A basket of incompatible
remote controls is only the
tip if the electronics iceberg
as networked devices within
homes and autos become
more common. Solving this
problem requires cooperation
at a higher level.
MOVING UP THE FOOD CHAIN
The Universal Plug and
Play (UPnP) Forum addresses
device control protocols.
Its UPnP extensions are
utilized in a range of standards,
including Microsoft’s
Windows and the Digital
Living Network Alliance’s (DLNA’s)
protocols (Fig. 3).
UPnP addresses the discovery, description,
and control of devices on a network without
specifying the hardware interconnect. It rides
on top of protocols like TCP/IP and UDP,
using formats such as XML. Authentication
tends to be a problem, though. And while
UPnP incorporates audio/video standards,
DLNA takes these standards even further
with more detailed support for multimedia
devices and controls.
Like the HomeGrid Forum, DLNA wants to
give devices a common playing field. It targets
the home, primarily entertainment, incorporating
mobile devices into the environment. This
is reflective of the DLNA membership list, as
well as the initial crop of standards coming out
of the organization. Of course, getting these
details requires DLNA membership, which can
be restrictive but not difficult to achieve.
Open-source support for basic DLNA features
is available, but DLNA definitely targets
entertainment and communication vendors.
It appears to be one alternative that can
provide an overarching link between devices.
The competition, or complementary platforms
depending upon your view, comes from
the High-Definition Audio/Video Networking
Alliance (HANA) and Microsoft.
HANA is an entertainment platform initially
based on IEEE-1394b, with HDTV as its target.
The synchronous nature of IEEE-1394b
enables the delivery of multiple HDTV streams.
Supporters point to this ability to deliver QoS
at HDTV speeds when they compare HANA to
DLNA, which is typically found on Wi-Fi and
Ethernet platforms. While Wi-Fi and Ethernet are
now gaining QoS support, they don’t enjoy widespread
availability.
It’s interesting to note that set-top boxes
require IEEE-1394b support. No one really uses
this feature yet. But like DLNA, HANA-based
devices will start showing up soon. The big
question is whether any approach will reach
broad distribution.
Microsoft supports DLNA, but the company
also has a host of technologies that it would
rather have developers use, such as Rally (formerly
“Windows Connect Now”), Web Services
on Devices (WSD), and Device Profile for Web Services (DPWS). Of course, all of these technologies
require .NET, which in turn requires a
Windows operating system. Adoption is great
for Microsoft, though these protocols probably
won’t wind up on other platforms.
As noted, all of these standards can coexist
and will likely do so. The big question is if any
of them will dominate the market or if a new
platform will emerge.
DLNA NETWORKING DEVICES
The potential flood of devices using standards
such as DLNA is just beginning. File services
are the easiest to implement. They generally
include platforms such as NAS (network
attached storage), which store software (music,
video, and other media versus programs) for
streaming to playback devices.
NAS devices are already available, though
you might miss the DLNA logo if you aren’t
looking for it. As with all similar approaches,
products only make sense when they’re used in
conjunction with other devices. A single device
is akin to a network with a single node—not
much to talk to.
This means that most initial devices will
provide services that can be delivered independently
of the DLNA feature. For example,
Nokia’s N95 8GB is a certified DLNA mobile
phone. It has 8 Gbytes of storage and is a multimedia
playback device. The phone includes a
5-Mpixel camera and can operate in standalone
mode from a multimedia perspective, but it gets
more interesting when DLNA is brought into the
equation. It can play back content from other
DLNA devices, as well as deliver stored content
to other DLNA devices.
Continue on Page 3
Buffalo Technology’s LinkTheater High
Definition Digital Media Player offers HDTV via
HDMI outputs (Fig. 4). It supports 720p and
1080i video output in addition to 480i and
480p video modes. The unit includes USB and
10/100 Ethernet ports. Of course, it has audio
and video outputs, too. It can handle a range of
audio, image, video, and multimedia formats,
including JPG, BMP, PNG, and GIF file display
plus MP3, WAV, WMA, Dolby Digital (AC-3), AACLC,
and AAC-HE audio.
Of course, the LinkTheater High Definition
Digital Media Player requires a data source.
Buffalo Technology offers a number of DLNA
options. The technology additionally works with
other DLNA-certified sources, including many
PCs that run the Linux or Microsoft Windows
operating systems.
People will want DLNA-compatible DVRs,
which dredges up some issues that have
slowed down agreements on the standards and
long-term adoption of the technology. At the
top of the list is copy protection, or, depending
on your point of view, customer management.
Digital rights management (DRM) is the
watchword and as much a sticking point as the
multiple protocols and hardware interfaces, if
not more so.
There’s some commonality in certain areas,
such as HDTV HDMI links that employ highbandwidth
digital content protection (HDCP),
but this isn’t something used across streaming
video standards or storage standards. DRM
won’t disappear completely, even though many
designers wish it would. Hopefully, the trend of
decreasing DRM on the audio side will trickle
down to the video arena.
The problem is that DRM uses encryption,
but it has absolutely nothing to do with system
security and authentication from a user’s perspective.
In addition, a tremendous amount of
time and effort has been spent on DRM, with
comparatively little on user management of
system security and authentication. An overarching
system design should really start with
security and management, including making it
easy to use.
The number of remote access links into a
home is increasing, and using only firewall/
gateway-style protection is a sure path to botnets
that are even more massive than those
infesting PCs already. Most standards haven’t
overlooked security, but it should be a unifying—
instead of a secondary—design issue.
Expect the emergence of DLNA devices and
the appearance of HANA devices this year, as
well as the adoption of ZigBee control units and
similar control platforms. Likewise, HDTVs will
be mandatory, leading to a range of potentially
networkable products available to consumers
and as targets for developers.
Unifying this disparate collection of devices
remains a long-term goal using common protocols
and applications. Still, it’s likely to remain
a challenge to developers and consumers for a
number of years to come.
|