Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Differences between MHP and...

Copyright © Steven Morris 2005All Rights Reserved

Downloaded from http://www.interactivetvweb.org

Differences between MHP and pure Java environments

Steve Morris

[email protected]



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



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



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



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



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



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



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.



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



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– http://java.sun.com/products/javatv/



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– http://www.davic.org/down1.htm



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– http://www.havi.org/techinfo/index.html



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– http://www.mhp.org



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



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



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.*



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



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



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



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



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



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.



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



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



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



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



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



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



HScenes in the UI model

HScene

Component

HScene

Component

Component

Container

HScene

Frame

Component

Component

Container

HScene

Component

HScene



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



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



Display structure

HGraphicsDevice HVideoDevice

• 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



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



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



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



Questions?

• For more information:– http://www.mhp.org

– http://www.interactivetvweb.org

– “Interactive TV standards”, S. Morris & A. Smith-Chaigneau(Pub. Focal Press, ISBN 0240806662 )

Copyright © Steven Morris 2002. All rights reserved.

http://www.interactivetvweb.org/

http://www.interactivetvweb.org/

Date post:	28-Dec-2015
Category:	Documents
Upload:	antonia-phelps
View:	216 times
Download:	0 times

Copyright © Steven Morris 2005 All Rights Reserved Downloaded from Differences between MHP and...

Documents