Transcript MHP vs. Java – The Differences

Differences between MHP and pure Java environments
Steve Morris
[email protected]
Copyright © Steven Morris 2005
All Rights Reserved
Downloaded from http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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/
Copyright © Steven Morris 2005
All Rights Reserved
Downloaded from http://www.interactivetvweb.org
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
Copyright © Steven Morris 2005
All Rights Reserved
Downloaded from http://www.interactivetvweb.org
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
Copyright © Steven Morris 2005
All Rights Reserved
Downloaded from http://www.interactivetvweb.org
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
Copyright © Steven Morris 2005
All Rights Reserved
Downloaded from http://www.interactivetvweb.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
Copyright © Steven Morris 2005
All Rights Reserved
Downloaded from http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
HScenes in the UI model
Frame
HScene
Component
HScene
Container
HScene
Component
Component
Copyright © Steven Morris 2005
All Rights Reserved
Downloaded from http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
Display structure
HScreen
HBackgroundDevice
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
Copyright © Steven Morris 2005
All Rights Reserved
Downloaded from http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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 http://www.interactivetvweb.org
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
Copyright
© Steven©
Morris
2002.Morris
All
All Rights Reserved
rights reserved.
2005
Downloaded from http://www.interactivetvweb.org