1 / 13

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 add@philabs.research.philips.com. Technology, Business and Politics.

bayard
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Interactive Content Format Issues in ATSC (US Digital TV Standards) Aninda DasGupta Philips Research Briarcliff Manor, NY add@philabs.research.philips.com

  2. Technology, Business and Politics • 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

  3. Types of Data-enhanced Receivers • 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

  4. CE Manufacturer Interests • 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

  5. Broadcaster/Content Author Interests • 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

  6. Computing Industry Interests • 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

  7. ATSC Interests • 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

  8. Proposals in ATSC • 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

  9. Proposals in ATSC (2) • 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

  10. Compromise Solution • 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

  11. Compromise Solution (2) • 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

  12. Compromise Solution (3) • 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

  13. Where W3C Can Help • 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

More Related