Transcript Interactive Content Format Issues in ATSC (US Digital TV Standards)

Interactive Content Format Issues in
ATSC (US Digital TV Standards)
Aninda DasGupta
Philips Research
Briarcliff Manor, NY
[email protected]
Technology, Business and Politics
2

The best technology will not succeed in the
marketplace unless it is designed with due attention
to the businesses that it seeks to address

In whatever we do to enable “Web for Television,”
we must pay due attention to the three major players
along the broadcast chain:
– Content authors and Broadcasters
– CE manufacturers
– Computing industry members
Types of Data-enhanced Receivers




3
Type 0: Plain audio and video
Type 1: DTV receivers that do not surf the Web, but allow
interactivity; plus A/V
– May handle subset of content formats from the Web
Type 2: Receivers that surf the Web; plus A/V
– DTV counterpart of WebTV™ product; WebDTV
– Serves viewers who want to surf the Web and watch
TV
Type 3: Receivers that surf the Web, do interactivity;
plusA/V
– Capable of handling any content format
CE Manufacturer Interests




4
Keep Type 2 and Type 1 receivers distinct in product
line
– Do not choose technologies that bring Type 1 and
Type 2 close in cost and features
If Type 2 and Type 1 products merge:
– Manufacturers must either compete with or use
technologies from incumbents of Type 2 market
CE companies want multiple sources for
technologies used in Type 1 receivers
IPR royalties for chosen technologies will cut into
already small margins
Broadcaster/Content Author Interests






5
Must not make existing content made for WebTV™
and PC-based analog receivers obsolete
New content must also serve existing WebTV™ and
PC-based analog receivers
Author content once for Web, and broadcast
Reuse authoring tools and personnel for Web and
broadcast
Availability of authoring tools and broadcast servers
from multiple sources
Availability of authoring personnel
Computing Industry Interests






6
Enter the DTV market
Try to bring low-end of interactive DTV product line
close to low-end of PC-based DTV receivers
Encourage CE companies to use technologies from
computing industry
Ensure survival of WebTV™ and PC-based receivers
Encourage broadcasters to use authoring tools and
servers from computing industry
Leverage the rapid pace of innovation on the Web for
broadcast applications
ATSC Interests



7
Not concerned with Type 2 receivers (except for A/V
standards)
Find solutions that allow evolution to future
technologies
– TV standards don’t change as fast as Web
standards
Find solutions that do not prohibit any party from
deploying services on a class of receivers
Proposals in ATSC


8
MHEG
– Small footprint
– Lack of popularity, authoring tools
– What to do with existing Web content and
receivers?
HTML, CSS, DOM, SMIL, JavaScript
– Big footprint
– Shown to work on PCs; what about STB?
– Brings the Web and broadcast channels together
– Authoring tools and personnel easily available
Proposals in ATSC (2)
9

VRML, HTML, XML, MPEG4 and JavaScript
– Big footprint
– Some parts not available yet; not standardized
– May be good solution for the future

Java Media Framework and pJava AWT
– Accepted in ATSC as a graphics and presentation
API set
Compromise Solution



10
Java Media Framework, subset of pJava AWT,
Broadcast HTML (BHTML)
Allows any content format decoder to work with
JMF
Broadcast HTML:
– Profile HTML 3.0, remove parts that are not
pertinent for broadcast (e.g., tables)
– Add parts of CSS1, and perhaps pieces of SMIL
– Add tags for
• Accurate positioning of elements on screen
• Tight temporal synchronization between
Audio, Video and Data
Compromise Solution (2)




11
DOM/XML may not be needed with JMF, or
DOM/XML parsers in Java are tiny in footprint
JavaScript is no longer needed if BHTML interpreter
exposes interface to JVM
– BHTML interpreter class exposes methods for
tight integration with JMF, JVM and applications
SMIL no longer needed if BHTML pays attention to
accurate positioning and temporal synchronization
Paves way for evolution to newer technologies in the
future
– New decoders and parsers can be brought into
JMF
Compromise Solution (3)






12
Broadcasters can send BHTML decoder written in
Java along with content
CE manufacturers may make available BHTML
decoder written in the receiver’s native code
BHTML decoder footprint must be small
New BHTML tags will be ignored by existing
receivers
Existing content using tags removed from HTML 3.0
can be converted to BHTML using automated scripts
Much existing content is generated dynamically, and
can be easily formatted with BHTML
Where W3C Can Help




13
W3C pedigree is important for acceptance of
BHTML by all players in ATSC
W3C can define BHTML; ATSC(or members) may
help
W3C can help define how BHTML fits into JMF and
define interface between BHTML interpreter and
JMF/JVM/applications
W3C should pay attention to business and political
issues when making a decision