a
Designing IPTV Set-top Boxes Without Getting Boxed In
Scot Robertson and Russell Rivin
Emerging Internet Protocol TV (IPTV) set-top boxes constitute a rapidly evolving and fluid product category.
Market forces and available technologies are driving multiple variations on the concept. Some business
models call for video on demand (VoD) and multicast TV; others bundle TV with voice over IP (VoIP); many
require Internet browsing.
Set-top box designers are also being asked to support an array of new audio, video and image formats as
their products take on the attributes of more open, network-connected appliances. IPTV set-top boxes may
be enabled with the functions of personal video recorders (PVR), digital media adapters (DMA), voice over
IP (VoIP), videophones and more.
While based on a shared foundation of media processing and network processing, each type of additional
functionality layers on different requirements. Entertainment services such as IPTV and VoD depend on
streaming media over a wide area network (WAN). Localized media applications such as PVR and DMA add
a media source in the home, which requires that streaming and digital rights management be applied to local
area network (LAN) environments. Communications-intensive applications like VoIP and videophone need to
run independently and in parallel with streaming media.
What’s more, service providers may use IPTV set-top boxes for a base set of services now, with plans to
expand into interactive games and other offerings in the future.
Deployment in the real world imposes further engineering challenges. Conditions tend not to live up to their
billing: Broadband data rates are variable. Latencies and delays impair two-way communications. Changes
in head-end video encoders produce interoperability problems with set-top decoders. Your device may be
installed on networks the service provider doesn’t control, or in parts of the network that perform below
standard, subjecting it to uneven and unoptimized quality of service (QoS).
Added features and future requirements aside, today’s IPTV set-box boxes typically have a set of
demanding requirements in common. These tasks must be performed in hard real time to provide a
desirable user experience:
• receive streaming compressed audio/video over a network
• process the stream containers
• decode the streams
• present a synchronized audio/video output to the listener or viewer
Digital rights management (DRM) protection and conditional access (CA) (which ensures that only
authorized subscribers have access to content) are likewise necessary, in order to satisfy media companies
and other content owners.
Careful design and architecture choices must be made from the beginning to engineer an IPTV set-top box
capable of handling known requirements along with the unknowns that await. A processor that works best
with constant and uninterrupted data sources--as in DVD and cable set-top box applications--will prove
inadequate and limiting. Starting with a processor competent at both streaming media and network
processing will allow you to meet performance and cost targets.
To develop a design that appeals to more potential customers, look for the flexibility to reallocate processor
capacity to perform a wider range of functions. A processor that also has low power consumption may even
permit extending your base design beyond the set-top, to devices such as portable media players or
automotive entertainment units.
After that, a capable and flexible IPTV set-top box depends on informed design choices across three
interdependent areas: media processing, network communications and application processing. Doing so
significantly improves performance, cost and extensibility.
Do
1
•
Design for multicast. Although the network uses IP technology, two-way communications between the
set-top and servers on the network is not a given. Multicast TV applications are predicated on the ability
of the set-top box to decode what comes, when it comes, without a back channel of communication.
And no back channel will be available when your “set-top” is an in-car or portable system that provides
satellite TV.
•
Size for peak network load. Many of today’s media processors have limited capacity and efficiency for
network processing. The drawbacks include dropped video frames and voice breakup on VoIP calls.
Experience shows that what may not be apparent in the lab can become all too clear in deployment,
when unhappy subscribers return their set-top boxes because network processing did not keep up with
what the WAN dishes out.
•
Predict the unpredictable. Order and predictability are rare in the field. Network congestion delays
content streams, for example. Wireless connections drop. Streaming video, VoIP and bulk data transfers
vie for bandwidth, and the user may decide to push each service to its limit simultaneously. When such
conditions are unavoidable, the ability to handle interruptions and service degradations gracefully as
possible will help differentiate your design from the competition’s.
•
Allow a customizable interface. To allow the set-top box to be widely deployed and accepted, its
design must allow the service provider to customize the user interface. Look and feel is key to fitting in
with the rest of a product line.
•
Enable field upgradeability. It’s not possible to release a product that includes every existing and
future variation of audio and video codec, DRM scheme, media server protocol, and audio/video
transport capability. New services must be deployed. Rolling out trucks to perform these upgrades is
costly for service providers. Eliminate this deal breaker with software upgrades that can be
accomplished remotely over the network.
Don’t
•
Assume a constant data rate. The nature of traffic on an IP network is bursty and backup-prone.
Upstream and downstream data rates may not be symmetric, as with ADSL. Judicious use of memory
buffers lets you compensate for network jitter, handle audio/video synchronization and separate media
from control processing.
•
Assume you’ll get all the data. Though packet loss is characteristic of the network, dropped video
frames and sound problems will mar the user experience. Many media systems are designed primarily
for a constant, uninterrupted data source environment and can’t perform the loss concealment that is a
must for both audio (silence insertion, audio signal interpolation) and video (bad packet detection and
removal).
•
Expect broadband throughput as advertised. Counting on a network’s best throughput invites trouble
because most broadband networks were built for intermittent traffic such as Web browsing, not to carry
streaming media. Another rule of thumb is that different segments of the network may perform at
different data rates. Encoding content at a lower bit rate than the network’s claimed throughput
compensates for variations across the network.
•
Use a decoder designed for fixed media. IPTV set-tops require a decoder designed for
communications systems that will inevitably change. Head-end video encoders improve their
compression over time by adding new techniques or tweaking current ones, but these changes often
cause visual effects in the set-top box decoder depending on the type of content. Remote software
upgrades are the only economical way that service providers can reconcile these errors. And new
services, such as videophones or Internet-downloaded content, will require new audio and video
decoders; software-based decoding provides the best compatibility.
•
Partition processing too rigidly. Usage scenarios for set-box boxes are evolving. Avoid partitioning
your system such that new applications can’t use processing power in new ways. For example, a
service provider may opt to move from an electronic program guide (EPG) style of information bar to a
highly interactive Internet browser. Inflexible partitioning may result in a design that performs well for
IPTV, but leaves Internet browsing slow and weak.
2
Scot Robertson is director of networked media products (scot.roberston@analog.com) and Russell Rivin is
eMedia systems architect (russell.rivin@analog.com) at Analog Devices, Inc. in Norwood, Mass.
###
3