Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Differences between MHP and pure Java environments Steve Morris

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from MHP is not Java MHP is based on a subset of personalJava 1.2 Several major elements are removed –Some to save space –Some because the functionality isn’t needed Several major parts added –Additional APIs for STB-specific functions –Places where functionality needed is too different from standard Java Some changed –UI model reflects the consumer, TV-centric model rather than the PC/workstation model

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from MHP is not just Java We can’t forget HTML (added in MHP 1.1) –Allows different types of applications to be mixed (and embedded in each other) Some applications are suited to development in Java –Applications with lots of processing, e.g. games –Applications that need to draw complex graphical displays Some are more suited to HTML –Information services –But, beware of the overhead of using DVB-HTML

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from The main differences There are four major sets of differences Those in the basic Java classes –Removed/changed functionality –Changed application model Changed UI support –To handle TV display environment Additional APIs –Adding extra TV-specific functionality Security –Increased paranoia and more restrictions

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Changes in the core Java classes Some parts of java.lang are not supported –Loading dynamic libraries –Exiting the VM –These make no sense in an STB environment Some classes from java.text not supported –Locales are mostly not included –This saves a LOT of space –STB implementers can add extra locales for specific markets, but these are not standardized by DVB Other bodies may standardize them later, however

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Changes in the core Java classes (2) Filesystem access is changed –java.io is still used, but STBs may not have a local filesystem –Mainly used for DSM-CC access instead –Support for features specific to DSM-CC added as a new API Network access –Most of java.net is not included An MHP receiver need not have a return channel –Only java.net.URL actually supported With heavily modified behavior –More of java.net may be included in the Internet Access profile and in future versions

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from The application model Similar to Java applets –MHP applications are called ‘xlets’ instead –Applications lifecycle is controlled by the middleware Just like an applet in a web browser –Many xlets can run simultaneously in a single service Like multiple applets in the same web page Applications can be started, stopped, paused and resumed –But no-one knows what ‘pausing’ an application really means –Applications should use the least amount of resources (and no scarce ones) when paused –Apps should not claim resources until they are actually started

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from The application model Control of applications is handed by the Application Manager –Part of the MHP middleware, but not a formally defined component –Handles requests from the broadcaster (application signaling) and from the user to change an application’s state –Also handles requests from other applications via the org.dvb.application API –The middleware is always in control of the application state –Other parts of the system (including the user) can only request state changes, not demand them.

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Other application issues MHP specifies that each application is loaded through a separate classloader –This means that an app can’t get references to objects in another app –Improves security –Makes application management much easier Since no external references to application objects –Inter-xlet communication carried out using separate API Native code is NOT supported –JNI may not be used –Interoperable applications can not use native code, for obvious reasons

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Extensions The JavaTV APIs –Contained in javax.tv.* –Xlet classes and infrastructure –Service selection –SI/PSI access –Media control extensions Common DTV functionality that is not limited to DVB systems –Not dependent on compliance with DVB standards, e.g. US cable and satellite markets Standardized by Sun Microsystems –

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Extensions (2) The DAVIC APIs –Contained in org.davic.* –Basic MPEG concepts –Tuning between transport streams –MPEG-2 section filtering –Resource management –Access to CA information Lower-level functionality, mainly related to MPEG decoding and infrastructure issues Standardized by DAVIC –

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Extensions (3) The HAVi APIs –Contained in org.havi.* –Video/graphics integration –UI widgets for consumer systems and TV screens Concerned with graphical issues –Especially with solving the problems of using Java widgets in a TV environment –Also solves issues relating to video and graphics integration Hardware-imposed restrictions that do not apply in a PC Standardized by HAVi –

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Extensions (4) The DVB MHP APIs –Contained in org.dvb.* –Access to SI/PSI –Application management –Access to DSM-CC object carousels –Return channel session management –Inter-Xlet communication Added to provide functionality not supported (or badly supported) by other APIs Standardized by DVB –

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Service information access Two different APIs –One of the few cases of MHP using two different solutions org.dvb.si.* –DVB specific –Provides access to all DVB-defined tables (Except the AIT) javax.tv.service.* –Independent from the underlying technology –Supports access to most SI data, but accessing DVB tables is harder –Designed for commonality with US markets

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Service information access Both APIs are asynchronous –Since filtering SI tables can take time if they’re not cached Most people use org.dvb.si.* for developing MHP apps –It’s closer in structure to DVB SI tables –More natural to use for DVB applications –JavaTV only useful if you’re designing for DVB and non-DVB markets

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Media control Media control via JMF 1.0 –Control over MPEG-2 and audio clip presentation Play/pause/change content Will never tune to a new TS Application must explicitly tune if necessary Some changes in behavior for MHP –Reflect differences between broadcast and non-broadcast applications –These differences can be major e.g. No way of controlling playback of broadcast media Some additional controls for broadcast-specific functions –Split across several packages –org.davic.media.* + org.dvb.media.* + javax.tv.media.*

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Media control New JMF controls add TV-specific functions –Subtitles –Scaling/positioning –Decoder format conversion Some controls not present –Less AWT support because it’s not necessary Most STBs will display video in the background using HW decoding –PC-specific controls dropped New content referencing method + URL format defined to reference DVB services and streams –Locator + its siblings

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Media control Limited support for static media types –MPEG audio files and video ‘drips’ only –Mainly used for accessing broadcast video No support for video from a file –Loading data from file takes too long Video ‘drip’ support adds efficient graphics for STB use –Sequence of MPEG frames –MPEG I-frame as first image –P-frames modify the image without needing to replace the whole image –Efficient control of multi-stage presentation where only some elements change

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Filesystem access java.io is used to access a filesystem –This includes DSM-CC and persistent filesystems –Some extensions to support these –Easy to use for most purposes – just like standard Java org.dvb.dsmcc adds support for DSM-CC functionality –Things that don’t exist (or are less important) in a normal PC filesystem –Stream events, Normal Play Time –Asynchronous loading of files –Caching hints –Notification of object changes

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Filesystem access Restrictions –No absolute paths These may vary between implementations Even relative paths should be used with care –No write access to a DSM-CC object carousel It is possible to use just java.io to access filesystems –But at a price –Some important functionality will not be available –Much more care needs to be taken with latency

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Service selection Java TV service selection API used to control what service is being presented –javax.tv.service.selection –This affects the lifecycle of applications –Any apps not signalled on the new service will die –Changes the whole service, including applications and media Like changing to a different TV channel DAVIC tuning API supports access to different transport streams –org.davic.net.tuning –Allows access to data on a different transport stream –Changes the TS only, no media presentation –Applications will not be killed

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from User input An STB probably has no keyboard –The only interoperable way to get input into the STB is via a remote control –This generates standard Java key events –The supported key codes are defined by MHP and HAVi others may be used, but aren’t interoperable A standard set of remote keys is defined, e.g. Arrow keys, OK, exit, digits MHP also defines a separate user input event API to support exclusive key access –org.dvb.event –Used for entering PINs, etc.

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from The graphics model Big changes to the UI library and graphics model Standard AWT widgets are not available in MHP –Button, etc. –Lightweight components only –AWT windowing model changes a lot The HAVi widgets can be used instead Applications can also build their own widgets –This seems to be the most popular choice –Allows a more TV-centric UI experience

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from The graphics model Transparency & alpha-blending added to AWT –Not supported in Java 1.1 (added in 1.2) –Added by org.dvb.ui.DvbColor class –Allows graphics to be overlayed on video org.dvb.ui package adds functionality missing from other UI extensions –TV-specific Text layout support –Alpha compositing between planes –Font loading for downloaded fonts

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from The HAVi widget set org.havi.ui includes some basic widgets –Buttons, check-boxes and radio buttons –Text entry fields –Static text –Icons –Dialog boxes –Animations Also contains higher-level concepts –HContainer, HComponent and others Replace Java functionality where needed –Resource management for graphics-related components

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Window management issues STBs will probably not have a full window manager –No need for all the functionality –Too complex for most STBs –Need to restrict access to the AWT hierarchy Can’t use an AWT Frame as the top-level component So how can different applications share the screen? –HW may impose limitations not found in a PC environment We use HScenes instead –A HAVi replacement for Frames

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from HScenes An HScene solves the problems with Frames –From org.havi.ui –Implements java.awt.Container –Doesn’t require a window manager But it doesn’t preclude it either –Anything that gets drawn into the HScene gets clipped at the edges of the HScene HScenes control: –Which application has input focus –How applications are laid out on screen –Which applications are currently visible

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from HScenes Acts as the top-level GUI component for any MHP application –Only one HScene is allowed for every application –(Actually one Hscene per display device) The application cannot see higher in AWT hierarchy than its own HScene –HScenes from other applications are not visible to this application –Applications can’t interfere with one another

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from HScenes in the UI model HScene Component HScene Component Container HScene Frame Component Container HScene Component HScene

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Display devices A TV has different display characteristics than a PC monitor –We need to include this in the display model The HScreen class represents a physical display device –This ties together all MPEG decoding, graphics and backgrounds –Models the use of graphics planes in the STB hardware Each HScreen consists of several lower-level devices

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Modelling graphics hardware Three basic types of device in the HAVi display structure –Each models a different graphics plane (or planes) in the display hardware HGraphicsDevice – used for application graphics and cursors HVideoDevice - used to present video from the MPEG decoder HBackgroundDevice - used to display either a still image or a plain colour These are all subclasses of HScreenDevice

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Display structure HGraphicsDeviceHVideoDevice One HScreen for every physical display device Possibly more than one of each type of device for an HScreen –Depends on the underlying hardware –May support multiple HGraphicsDevice instances HScreen HBackgroundDevice

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Communication between apps RMI-like API for inter-xlet communication –Same philosophy but classes are changed to reduce overhead –Does not use TCP/IP Reduces communication overhead –Does not need precompiled stubs –Does not support communication outside the receiver For this, RMI must still be used

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Security MHP is paranoid –Much more so than standard Java –Stops applications doing dangerous/resource-intensive operations unless they are trusted –Only the operator can decide to trust an application Applications need signing to use many APIs –e.g. Return channel access, section filtering –Signature files broadcast as part of the application directory structure –Extra permissions defined by MHP to handle the new functionality

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Summary Java developers will adapt easily to MHP But, some changes are needed to get the most from your application –Improved performance –Increased functionality –Increased reliability Developing for TV needs a different philosophy –And this is reflected in the MHP APIs

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Questions? For more information: – – –“Interactive TV standards”, S. Morris & A. Smith-Chaigneau (Pub. Focal Press, ISBN ) Copyright © Steven Morris All rights reserved.