mhp-guide
TRANSCRIPT
The MHP-Guide A comprehensive Guide to the Multimedia Home Platform,
the underlying technology and possible uses
Document / Version number: D16 / 1.0
Date: 30.03.2006
Issued by: The MHP Knowledge Project (MHP-KDB)
This document is available at: http://www.mhpkdb.org
Visit the MHP Knowledge Database: www.mhpkdb.org
Document Information: Document Type: Deliverable Document No.: D16 Title: The MHP Guide Version No.: 1.0 Related to work package: WP4 Type of the Deliverable: Report Dissemination level: Public Author: The MHP Knowledge Project Due date: January 2006 Delivery date (Ver. 0.9): 13th February 2006 (Stable Draft) Delivery date (Ver. 1.0): 30th March 2006
As we are interested to continuously improve the quality of our documents, we kindly ask you to report back any error you find in our documents or any improvement you are able to suggest. This can be done via writing comments into the database or by an email to [email protected].
This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
© 2006 Institut für Rundfunktechnik GmbH on behalf of The MHP Knowledge Project. This work is reproduced and distributed with the permission of the Institut für Rundfunktechnik GmbH. No other use is permitted without the express prior written permission. For permission, contact [email protected].
This work may be reproduced and redistributed, in whole or in part, without alteration and without prior written permission, provided all copies contain the following statement:
Copyright notice © 2006 Institut für Rundfunktechnik GmbH on behalf of The MHP Knowledge Project
30th March 2006
The MHP-Guide Version: 1.0
Page 3 of 215
Table of Content
Table of Content.......................................................................................................................3
List of Tables ..........................................................................................................................11
List of Figures.........................................................................................................................12
1 Purpose of the MHP-Guide .............................................................................................14
1.1 General ...................................................................................................................14
1.2 Target Groups ........................................................................................................14
2 What is interactive television?.........................................................................................19
2.1 Types of applications..............................................................................................19
2.1.1 Available Interactive Applications .......................................................................19
2.1.2 Information Services ...........................................................................................20
2.1.3 Communication Services ....................................................................................22
2.1.4 Entertainment Services.......................................................................................23
2.1.5 T-Commerce.......................................................................................................25
2.1.6 T-Government.....................................................................................................26
2.1.7 T-Learning ..........................................................................................................27
2.1.8 T-Health/T-Care..................................................................................................28
2.1.9 Business TV........................................................................................................28
2.2 Levels of interactivity ..............................................................................................29
3 Introduction to MHP ........................................................................................................31
3.1 The DVB Project .....................................................................................................31
3.2 The need for MHP as an open API standard..........................................................31
3.2.1 Market developments and DVB activities ...........................................................31
3.2.2 EU policy.............................................................................................................32
3.3 MHP activities in DVB.............................................................................................33
3.4 MHP: Current status and new developments .........................................................33
3.5 Ensuring the interoperability of MHP ......................................................................34
3.5.1 The MHP Test Suite ...........................................................................................35
3.5.2 The MHP Knowledge Project..............................................................................36
3.6 MHP in the markets ................................................................................................37
3.6.1 Austria.................................................................................................................37
3.6.2 Denmark .............................................................................................................38
3.6.3 Finland................................................................................................................38
30th March 2006
The MHP-Guide Version: 1.0
Page 4 of 215
3.6.4 France.................................................................................................................39
3.6.5 Flandern..............................................................................................................39
3.6.6 Germany.............................................................................................................40
3.6.7 Italy .....................................................................................................................41
3.6.8 Norway................................................................................................................42
3.6.9 Spain...................................................................................................................43
3.6.10 Sweden...........................................................................................................44
3.6.11 United Kingdom ..............................................................................................45
3.6.12 Switzerland .....................................................................................................45
4 MHP iTV Applications .....................................................................................................46
4.1 MHP application .....................................................................................................46
4.1.1 Why Java? ..........................................................................................................46
4.1.2 Extensions added from other standards .............................................................46
4.1.3 New TV Specific functionality .............................................................................47
4.2 MHP applications and the broadcast chain ............................................................51
5 MHP end-to-end architecture ..........................................................................................53
5.1 Introduction.............................................................................................................53
5.2 MHP end-to-end reference model ..........................................................................53
5.2.1 Program Content Playout ...................................................................................54
5.2.2 MHP Application Authoring & Production Tools .................................................54
5.2.3 Content Management System (CMS).................................................................54
5.2.4 Download server & firmware upgrade ................................................................54
5.2.5 Public Key Infrastructure MHP PKI.....................................................................55
5.2.6 PSI/SI..................................................................................................................55
5.2.7 DSM-CC .............................................................................................................56
5.2.8 Conditional Access System ................................................................................57
5.2.9 Network Equipment ............................................................................................58
5.2.10 MHP terminal ..................................................................................................58
5.2.11 Return Channel...............................................................................................58
5.2.12 Application specific backend servers..............................................................59
5.3 Actors of the MHP end-to-end system and their roles ............................................59
5.3.1 MHP authoring tool vendor .................................................................................61
5.3.2 MHP application developer.................................................................................61
5.3.3 MHP service provider .........................................................................................61
5.3.4 Broadcaster ........................................................................................................61
30th March 2006
The MHP-Guide Version: 1.0
Page 5 of 215
5.3.5 Network operator ................................................................................................62
5.3.6 MHP playout vendor ...........................................................................................62
5.3.7 CAS provider ......................................................................................................62
5.3.8 ISP......................................................................................................................62
5.3.9 MHP Backend operator ......................................................................................63
5.3.10 MHP terminal vendor ......................................................................................63
5.3.11 DVB Services SARL .......................................................................................63
5.3.12 MHP Certification Authority.............................................................................64
5.3.13 End-user .........................................................................................................64
5.3.14 MHP SW stack provider..................................................................................64
6 Organization of the MHP knowledge...............................................................................65
7 Basic Architecture ...........................................................................................................67
7.1 Introduction.............................................................................................................67
7.2 DVB-J .....................................................................................................................67
7.2.1 Introduction .........................................................................................................67
7.2.2 DVB-J Constraints ..............................................................................................67
7.3 DVB-HTML .............................................................................................................68
7.4 Principle of scarce resources .................................................................................69
7.4.1 Memory...............................................................................................................69
7.4.2 Persistent storage...............................................................................................69
7.4.3 Tuning Interface..................................................................................................73
7.4.4 Return Channel...................................................................................................74
7.5 Migration.................................................................................................................75
7.5.1 Migration from previous legacy middleware to MHP ..........................................75
7.5.2 Migration from older to more recent MHP versions ............................................76
8 Broadcast Protocols ........................................................................................................79
8.1 Introduction.............................................................................................................79
8.2 Transport Stream Elements....................................................................................79
8.2.1 A note on naming................................................................................................79
8.2.2 MPEG-2 Transport Stream.................................................................................79
8.2.3 DVB Transport Stream .......................................................................................82
8.2.4 MHP....................................................................................................................82
8.3 DSM-CC .................................................................................................................82
8.3.1 DSM-CC Object Carousel...................................................................................83
8.3.2 Object carousel optimization...............................................................................84
30th March 2006
The MHP-Guide Version: 1.0
Page 6 of 215
8.4 Synchronization ......................................................................................................85
8.4.1 Do-It-Now stream events ....................................................................................85
8.4.2 Scheduled stream events ...................................................................................86
8.4.3 Creating stream events.......................................................................................86
8.5 Section Filtering......................................................................................................87
8.5.1 What is a section? ..............................................................................................87
8.5.2 MHP....................................................................................................................88
8.5.3 Capacity and performance..................................................................................88
8.5.4 Examples ............................................................................................................89
8.6 Tuning and service selection ..................................................................................89
8.7 Principles of conditional access (smart card, CI content protection) ......................90
9 MHP Applications and Application Lifecycle ...................................................................92
9.1 Applets and Xlets....................................................................................................92
9.2 Xlet Application.......................................................................................................92
9.3 Resident applications .............................................................................................94
9.4 Stored applications .................................................................................................94
9.4.1 Restrictions of stored applications ......................................................................95
9.4.2 Extensions to MHP 1.0 APIs...............................................................................95
9.4.3 Signaling of stored application............................................................................96
10 Service Signaling........................................................................................................97
10.1 Introduction.............................................................................................................97
10.2 Introduction to SI / PSI............................................................................................97
10.2.1 Information independent from transport stream..............................................98
10.2.2 Optional “other” tables ....................................................................................98
10.2.3 Tuning to other streams..................................................................................99
10.2.4 Accessing Service Information .......................................................................99
10.2.5 Usage of the SI overview tables .....................................................................99
10.3 Introduction to AIT and application change ..........................................................100
10.4 Application Loading over Return Channel ............................................................101
11 Security.....................................................................................................................102
11.1 Security in interactive television environments .....................................................102
11.1.1 Integrity .........................................................................................................102
11.1.2 Confidentiality ...............................................................................................103
11.1.3 Availability.....................................................................................................103
11.2 Signing MHP Applications ....................................................................................104
30th March 2006
The MHP-Guide Version: 1.0
Page 7 of 215
11.2.1 Hash files (dvb.hashfile) ...............................................................................104
11.2.2 Signature files (dvb.signature.*)....................................................................104
11.2.3 Certificate files (dvb.certificates.*) ................................................................105
11.2.4 Example of a signed MHP application ..........................................................106
11.3 DVB MHP Public Key Infrastructure (PKI) ............................................................107
11.3.1 Actors in the MHP PKI ..................................................................................107
11.3.2 DVB Services Hierarchy ...............................................................................107
11.3.3 DVB MHP PKI for MHP terminal Manufacturers...........................................109
11.3.4 DVB MHP PKI for Application Developers....................................................109
11.3.5 DVB MHP PKI for Broadcasters ...................................................................109
11.3.6 Certificate Management................................................................................110
11.4 Authenticating applications in the MHP Terminal .................................................110
11.5 Application Rights Model ......................................................................................111
11.6 Other aspects .......................................................................................................111
12 Graphics, Text Presentation, Audio, Video...............................................................113
12.1 Introduction...........................................................................................................113
12.2 Layers and composition concept ..........................................................................113
12.3 Playable media .....................................................................................................114
12.3.1 Java Media Framework 1.0 .........................................................................114
12.3.2 Java Media Framework 2.0 .........................................................................114
12.3.3 Java Media Framework on MHP terminals ..................................................115
12.3.4 Media flow....................................................................................................115
12.3.5 Media player and available controls ............................................................115
12.3.6 Obtaining a player and controls ...................................................................118
12.3.7 Selection of audio components with AudioLanguageControl .......................119
12.3.8 Selection of subtitles with SubtitlingLanguageControl .................................120
12.3.9 Selection of media with MediaSelectControl ...............................................122
12.4 UI components overview/main HAVI components................................................123
12.4.1 Main HAVI components ................................................................................123
12.4.2 HComponent and HContainer ......................................................................123
12.4.3 HVisible and HLook ......................................................................................125
12.4.4 Other considerations using HAVI..................................................................126
12.4.5 Input events and exclusive registrations on input event ...............................126
12.5 Displayable graphics formats and restriction........................................................127
12.5.1 PNG ..............................................................................................................128
30th March 2006
The MHP-Guide Version: 1.0
Page 8 of 215
12.5.2 JPEG ............................................................................................................128
12.5.3 GIF................................................................................................................128
12.6 Color Table ...........................................................................................................129
12.7 Differences between TV and computer screens...................................................130
12.7.1 Calculation (PAL).........................................................................................132
12.7.2 Loss of sharpness.........................................................................................132
12.7.3 Calculation (NTSC).......................................................................................133
12.7.4 Overview of scale factors.............................................................................133
12.8 Color conversion...................................................................................................133
12.9 Double buffering ...................................................................................................134
12.10 Fonts.....................................................................................................................135
12.10.1 Generating fonts ...........................................................................................135
12.10.2 Generating the font index file........................................................................136
12.10.3 Using external fonts ......................................................................................137
13 Return Channel ........................................................................................................138
13.1 Introduction...........................................................................................................138
13.2 Types of return channels ......................................................................................138
13.2.1 Always-on return channels ...........................................................................138
13.2.2 Connection-based return channels...............................................................139
13.2.3 Detailed example ..........................................................................................139
13.3 Protocol overview .................................................................................................139
13.3.1 UDP ..............................................................................................................139
13.3.2 TCP...............................................................................................................139
13.3.3 HTTP ............................................................................................................140
13.3.4 DNS ..............................................................................................................140
13.3.5 Protocol support............................................................................................140
13.4 MHP as client for Internet services & Integration of contents received via return channel .............................................................................................................................141
13.5 Security on the Return Channel ...........................................................................142
14 Equipment ................................................................................................................143
14.1 Playout systems ...................................................................................................143
14.2 MHP Terminal architecture ...................................................................................144
14.2.1 Hardware requirements ................................................................................146
14.2.2 Conceptual view for Software architecture ...................................................147
14.3 Test equipment.....................................................................................................148
30th March 2006
The MHP-Guide Version: 1.0
Page 9 of 215
14.3.1 IRT MHP Application analyzer......................................................................148
14.3.2 Return Channel analysis tool ........................................................................149
14.3.3 AIT / DSM-CC Analyzer and Compliance Tool .............................................150
14.3.4 Loading Time Analyzer .................................................................................151
15 Usability ....................................................................................................................152
15.1 Layout and Design................................................................................................153
15.1.1 As much as necessary, as little as possible .................................................154
15.1.2 Consistency ..................................................................................................154
15.1.3 Screen Layout...............................................................................................154
15.2 Navigation.............................................................................................................156
15.2.1 Remote Control Units ...................................................................................156
15.2.2 Interaction Design.........................................................................................158
15.3 Legibility of Text....................................................................................................159
15.3.1 Legibility Examples .......................................................................................159
15.4 Recommendations for Using Colors .....................................................................162
15.5 Usability Studies and User-Centered Design .......................................................163
16 MHP Outlook ............................................................................................................166
16.1 Technical aspects.................................................................................................166
16.1.1 DVB over IP / IP tuner ..................................................................................166
16.1.2 IP over DVB ..................................................................................................167
16.1.3 Personal Digital Recorder (PDR)..................................................................168
16.1.4 HDTV ............................................................................................................169
16.1.5 MPEG4 / H.264.............................................................................................169
16.1.6 DVB-S2.........................................................................................................170
16.1.7 Object Tracking.............................................................................................170
16.2 Commercial aspects .............................................................................................171
16.2.1 DVB-MHP in Europe.....................................................................................171
16.2.2 DVB-MHP in the rest of the world.................................................................173
17 Glossary and abbreviations ......................................................................................175
18 Literature ..................................................................................................................191
18.1 General DVB ........................................................................................................191
18.2 General TV ...........................................................................................................191
18.3 General User Interaction ......................................................................................191
18.4 Other.....................................................................................................................192
19 Annex A - How to use the MHP KDB .......................................................................193
30th March 2006
The MHP-Guide Version: 1.0
Page 10 of 215
19.1 Organization of the Database Content .................................................................193
19.1.1 Rights and Roles ..........................................................................................194
19.1.2 Reviewing Process .......................................................................................194
19.2 Using the KDB ......................................................................................................195
19.3 Licensing conditions .............................................................................................198
19.3.1 Licensing conditions for documents in the static part of KDB.......................199
19.3.2 Licensing conditions for Java source code ...................................................199
20 Annex B – Develop your first Xlet with MHP-KDB....................................................201
20.1 Build an application ..............................................................................................201
20.2 Download an application: .....................................................................................202
20.3 Debug an application:...........................................................................................202
20.4 Source code of basic application: .........................................................................203
21 Annex C - Presentation of the MHP APIs.................................................................206
21.1 “Core” APIs...........................................................................................................206
21.2 JMF APIs ..............................................................................................................207
21.3 JavaTV APIs.........................................................................................................207
21.4 DAVIC APIs ..........................................................................................................208
21.5 HAVi (Home Audio Video Interoperability) APIs ...................................................209
21.6 DVB APIs..............................................................................................................209
22 Annex D – Migration .................................................................................................212
30th March 2006
The MHP-Guide Version: 1.0
Page 11 of 215
List of Tables Table 1-1: Chapters and their potential target group relevance............................................................ 18 Table 2-1: Levels of interactivity in relation to types of applications ..................................................... 30 Table 5-1: Elucidation of actors in the MHP end-to-end reference model ............................................ 60 Table 11-1: Actors in the MHP Public Key Infrastructure.................................................................... 107 Table 12-1: Palette construction rules................................................................................................. 130 Table 13-1: MHP 1.0.x Protocol Support............................................................................................. 141 Table 13-2: MHP 1.1.1 Protocol support ............................................................................................. 141 Table 14-1: Hardware resource requirements..................................................................................... 146 Table 15-1: Mandatory keys in MHP ................................................................................................... 158 Table 19-1: Rights and Roles Model of the MHP-KDB ....................................................................... 194 Table 20-1: Authoring Tools vendors .................................................................................................. 202 Table 21-1: Java Core APIs ................................................................................................................ 207 Table 21-2: JavaTV APIs..................................................................................................................... 208
30th March 2006
The MHP-Guide Version: 1.0
Page 12 of 215
List of Figures Figure 2-1: EPG of the ARD Portal ....................................................................................................... 20 Figure 2-2: Simple STB-EPG (TechniSat)............................................................................................. 20 Figure 2-3: News Service with ¼ scaled video (Mediaset, Italy)........................................................... 21 Figure 2-4: Weather Service (RTL TV interaktiv, Germany) ................................................................. 21 Figure 2-5: Traffic Service (Prototype, rbb, Germany) .......................................................................... 22 Figure 2-6: Interactive multimedia teletext (Pro7, Germany) ................................................................ 22 Figure 2-7: TV mail client (Alticast) ....................................................................................................... 22 Figure 2-8: Arcade Game on TV screen (sofia digital) .......................................................................... 23 Figure 2-9: Interactive TV Game (ZDF, Germany)................................................................................ 23 Figure 2-10: Video on Demand Selection (gist) .................................................................................... 24 Figure 2-11: Tracking ebay auctions on the TV screen (Nionex).......................................................... 25 Figure 2-12: Sofa Shopping with OTTO’s interactive MHP Shop ......................................................... 25 Figure 2-13: Regional Information Portal for the city of Tampere (Finland).......................................... 26 Figure 2-14: Voting application related to News Show (SkyTV, UK) .................................................... 27 Figure 2-15: Kids’ Edutainment: Goosebumps (FoxKids, Germany) .................................................... 27 Figure 2-16: Customer Information at Housing Society “ewt” (GIST,
Germany) ....................................................................................................................................... 28 Figure 3-1: Profiles of the MHP standard .............................................................................................. 34 Figure 3-2: The MHP Logo.................................................................................................................... 35 Figure 3-3: DGTVi Logo ........................................................................................................................ 42 Figure 4-1: HScene in the UI model ...................................................................................................... 50 Figure 4-2: Display structure ................................................................................................................. 51 Figure 4-3 MHP applications in broadcast chain................................................................................... 52 Figure 5-1: MHP E2E Reference Model................................................................................................ 53 Figure 5-2: Detailed view of Conditional Access System...................................................................... 57 Figure 6-1: Mapping of the MHP-KDB Categories in the MHP End-to-End
Reference Model ............................................................................................................................ 66 Figure 7-1 Plug-in implementation options............................................................................................ 75 Figure 8-1 Transport Stream ................................................................................................................. 80 Figure 8-2 Example building blocks of an MPEG-2 encoder ................................................................ 80 Figure 8-3 MPEG-2 Packet Header ...................................................................................................... 81 Figure 8-4 Example of object carousel in DVB service ......................................................................... 83 Figure 8-5: DSM-CC Object Carousel Layering.................................................................................... 84 Figure 8-6: Encrypting and decrypting content...................................................................................... 90 Figure 8-7: Encryption and decryption process..................................................................................... 91 Figure 9-1: Xlet lifecycle state machine diagram................................................................................... 92
30th March 2006
The MHP-Guide Version: 1.0
Page 13 of 215
Figure 11-1: Example of a signed application [Hetzer 2001] .............................................................. 106 Figure 11-2: The DVB Services Hierarchy .......................................................................................... 108 Figure 12-1: Graphic Planes in MHP................................................................................................... 113 Figure 12-2: Porter-Duff Alpha Composition Rules............................................................................. 114 Figure 12-3: HComponent and HContainer (a) ................................................................................... 123 Figure 12-4: HComponent and HContainer (b) ................................................................................... 124 Figure 12-5: HVisible and HLook ........................................................................................................ 125 Figure 12-6: Example of a color table ................................................................................................. 129 Figure 12-7: Opaque CLUT................................................................................................................. 130 Figure 12-8: Comparison of pixel aspect ratios................................................................................... 131 Figure 14-1: Typical MHP playout server interfaces ........................................................................... 143 Figure 14-2: The MHP Logo................................................................................................................ 144 Figure 14-3: MHP terminal hardware architecture ............................................................................. 145 Figure 14-4: MHP terminal software architecture............................................................................... 147 Figure 15-1: Typical Screen Structure of an MHP Application............................................................ 153 Figure 15-2: Basic Formal Structure of a Screen Surface .................................................................. 153 Figure 15-3: Layout of a TV Screen .................................................................................................... 154 Figure 15-4: Screen Organization ....................................................................................................... 155 Figure 15-5: Remote Controls of MHP Terminals ............................................................................... 156 Figure 15-6: Functions of a Remote Control ....................................................................................... 158 Figure 15-7: Legibility Example 1 ........................................................................................................ 160 Figure 15-8: Legibility Example 2 ........................................................................................................ 160 Figure 15-9: Legibility Example 3 ........................................................................................................ 161 Figure 15-10: Legibility Example 4 ...................................................................................................... 162 Figure 15-11: Examples of color combinations with poor legibility...................................................... 163 Figure 16-1: Example of an IP STB..................................................................................................... 167 Figure 16-2: HD Ready logo defined by EICTA for HD equipment..................................................... 169 Figure 16-3: Example for object tracking............................................................................................. 170 Figure 16-4: MHP situation in the world in August 2005 [MHP_ORG]................................................ 171 Figure 19-1: Simplified Data Model of the KDB .................................................................................. 193 Figure 19-2: Searching an Issue in the KDB....................................................................................... 195 Figure 19-3: Adding an Issue to the KDB............................................................................................ 196 Figure 19-4: Editing a Document......................................................................................................... 198 Figure 20-1: Developing application steps .......................................................................................... 201
30th March 2006
The MHP-Guide Version: 1.0
Page 14 of 215
1 Purpose of the MHP-Guide
1.1 General DVB MHP, the DVB Multimedia Home Platform, is a major standard for interactive TV today. This document is a free guidebook that offers comprehensive knowledge on all fundamental aspects of MHP for all those involved along the end-to-end chain of interactive TV: those who are simply interested in MHP and want a quick overview and those who want to dig deeper into the subtleties of the standard, those who plan to enter the world of MHP practically and those who already work with MHP and need specific information on certain issues.
MHP-KDB Project:The MHP-KDB project is co-funded by the EU as an "IST project. Its main aim is to improve the interoperability of MHP implementations and MHP applications.
The MHP-Guide is generated from practical experience of European actors in broadcasting, IT manufacturing and technology research who are familiar with MHP in their every day work and who joined forces in the MHP knowledge project mainly to improve interoperability of MHP implementations and applications. As one major result of this project, the online MHP-Knowledge Database was established. This database offers a continuously growing number of solutions including MHP reference application modules as "Open Source" code available for free usage. Additionally a virtual online test center for testing interoperability on standard hardware MHP terminals.
The MHP-Guide complements the resources offered by the MHP-Knowledge Database. While the MHP-Guide provides a comprehensive yet concise overview of the basic applications and technologies of the MHP End-to-End chain, the online database leads on to deeper levels of knowledge and to the practical dimension, be it for offering your own solution, retrieving a solution or testing your applications.
The document layout features a broad text column with an extensive margin. This margin highlights special information such as the depth of information (NOVICE/EXPERT LEVEL), brief definitions of relevant terms and references to related entries in the database for more specific knowledge and practical solutions.
1.2 Target Groups The MHP-Guide supports fundamental research needs of all sorts of interest groups. The following table will help readers to see which chapters and sections are particularly interesting for them. It lists all document chapters and their potential target groups.
30th March 2006
The MHP-Guide Version: 1.0
Page 15 of 215
Chapter
Bro
adca
ster
s
Dec
oder
Man
ufac
ture
rs
App
licat
ion
Prog
ram
mer
s
Aut
horin
g To
ol P
rovi
ders
Bro
adca
st E
quip
men
t M
anuf
actu
rers
Expe
rt/ N
ovic
e Le
vel
Chapter 2: What is interactive television?
2.1 Types of applications N
2.2 Levels of interactivity N
Chapter 3: Introduction to MHP
3.1 The DVB Project N
3.2 The need for MHP as an open standard N
3.3 MHP activities in DVB N
3.4 MHP: Current status and new developments
N
3.5 Ensuring the interoperability of MHP N
3.6 MHP in the markets N
Chapter 4: MHP iTV Applications
4.1 MHP application N
4.2 MHP applications and the broadcast chain
N
Chapter 5: MHP End-to-End Architecture
5.1 Introduction N
5.2 MHP end-to-end reference model N
5.3 Actors of the MHP end-to-end system and their roles
N
Chapter 6: Organization of the MHP knowledge
6 Organization of the MHP knowledge N
Chapter 7: Basic Architecture
7.1 Introduction N
7.2 DVB-J N
7.3 DVB-HTML N
7.4 Principle of scarce resources N / E
7.5 Migration E
30th March 2006
The MHP-Guide Version: 1.0
Page 16 of 215
Chapter
Bro
adca
ster
s
Dec
oder
Man
ufac
ture
rs
App
licat
ion
Prog
ram
mer
s
Aut
horin
g To
ol P
rovi
ders
Bro
adca
st E
quip
men
t M
anuf
actu
rers
Expe
rt/ N
ovic
e Le
vel
Chapter 8: Broadcast Protocols
8.1 Introduction N
8.2 Transport Stream Elements N
8.3 DSM-CC N / E
8.4 Synchronization N / E
8.5 Section Filtering N
8.6 Tuning and service selection N
8.7 Principles of conditional access (smart card, CI content protection
N
Chapter 9: MHP Applications and Application Lifecycle
9.1 Applets and Xlets N
9.2 Xlet Application N
9.3 Resident Applications N
9.4 Stored Applications N / E
Chapter 10: Service Signaling
10.1 Introduction N
10.2 Introduction to SI /PSI N / E
10.3 Introduction to AIT and application change
E
10.4 Application Loading over Return Channel
N
Chapter 11: Security
11.1 Security in interactive television environments
N
11.2 Signing MHP applications E
11.3 DVB MHP Public Key Infrastructure (PKI)
E
11.4 Authenticating applications in the MHP terminal
E
30th March 2006
The MHP-Guide Version: 1.0
Page 17 of 215
Chapter
Bro
adca
ster
s
Dec
oder
Man
ufac
ture
rs
App
licat
ion
Prog
ram
mer
s
Aut
horin
g To
ol P
rovi
ders
Bro
adca
st E
quip
men
t M
anuf
actu
rers
Expe
rt/ N
ovic
e Le
vel
11.5 Application Rights Model N
11.5 Other Aspects E
Chapter 12: Graphics, Text Presentation, Audio, Video
12.1 Introduction N
12.2 Layers and composition concept N
12.3 Playable media N / E
12.4 UI components overview/main HAVI components
N
12.5 Displayable graphics formats and restriction
N
12.6 Color Table N
12.7 Differences between TV and computer screens
N / E
12.8 Color conversion E
12.9 Double buffering E
12.10 Fonts N
Chapter 13: Return Channel
13.1 Introduction N
13.2 Types of return channels N
13.3 Protocol overview N
13.4 MHP as client for internet services & integration of content received via return channel
N
13.5 Security on the return channel N
Chapter 14: Equipment
14.1 Playout systems N
14.2 MHP terminal architecture E
14.3 Test equipment N / E
Chapter 15: Usability
30th March 2006
The MHP-Guide Version: 1.0
Page 18 of 215
Chapter
Bro
adca
ster
s
Dec
oder
Man
ufac
ture
rs
App
licat
ion
Prog
ram
mer
s
Aut
horin
g To
ol P
rovi
ders
Bro
adca
st E
quip
men
t M
anuf
actu
rers
Expe
rt/ N
ovic
e Le
vel
15.1 Layout and Design N
15.2 Navigation N
15.3 Legibility of Text N
15.4 Recommendations for using colors N
15.5 Usability studies and user-centered design
N
Chapter 16: MHP Outlook
16.1 Technical aspects N / E
16.2 Commercial aspects N
Chapter 17: Glossary and abbreviations
17. Glossary and abbreviations N
Chapter 18: Literature
18. Literature N
Annex A
19. How to use the MHP KDB N
Annex B
20. Develop your first Xlet with MHP KDB N
Annex C
21. Presentation of the MHP APIs N
Annex D
22. Migration E
Table 1-1: Chapters and their potential target group relevance
30th March 2006
The MHP-Guide Version: 1.0
Page 19 of 215
2 What is interactive television? NOVICE LEVEL
With the dawn of digital television a whole new spectrum of opportunities has arrived. We were used to the introduction of new technical elements in television during the years of analogue television, but they were all the results of long-term processes. In those days, new functionalities were realized by introducing new hardware in the television set (e.g. teletext and stereo chips). Today enhancements are incomparably more rapid and far-reaching in their impact because they are software-based: the digital TV contains an “engine” for running applications, like we have become accustomed to in the context of PCs. This technological basis of interactive TV should lead to the introduction of new applications for many years to come. It can significantly reduce the time to market for new applications. Similar applications coming from different broadcasters will potentially have a different look and feel. It will be possible to bring new applications into use for just a limited time and scrap them afterwards since they do not cause additional costs for the consumer. Interactive television (iTV) applications will have an impact beyond the traditional broadcasting world. There will be extended commercial potential for these applications and, as a consequence, applications will also be developed by non-broadcasters.
The great advantage of interactive TV is that all services are running in a controlled environment (unlike on the internet). Via DVB-T/S/C broadcast large audiences may be addressed without the need of scaling the server capacity or network connection.
But what is it that interactive TV can bring? The following paragraphs will give an overview of the types of applications and the types of interactivity that iTV can actually provide. While chapter 2.1 describes various types of already available interactive applications, chapter 2.2 aims at a broader classification of interactivity.
2.1 Types of applications
2.1.1 Available Interactive Applications Interactive TV-Applications lead the way out of pure “lean-back” consumption of TV. The first group of applications consists of so-called program related applications that accompany the actual TV broadcast of certain programs. These can be classified as follows:
Ahead of a certain program they can be instrumental in attracting viewers by offering applications in advance promoting this program;
During a broadcast, they allow for the consumers’ active involvement like participation in quizzes or voting, and/or provide additional information that in its depth cannot be covered by the TV program itself, as for example on the occasion of large TV events like the Olympics or Elections, as well as on service programs, science magazines, or entertainment programs;
After a program, additional services might offer yet more related information and service or interaction offers that can be dealt with by the consumer independent of the original program time slot.
The second large group of applications consists of program-independent applications offering general information services, communication,
30th March 2006
The MHP-Guide Version: 1.0
Page 20 of 215
entertainment, video-on-demand, or T-commerce services, and, finally, TV-based front-ends for e-Government, e-Learning or e-Health.
The following sections offer a classification of these listed types of services. They do not refer specifically to the different types of program related services as outlined above. However, elements of the described services often form part of program enhancement. Furthermore, all the application types described may be combinations of various subsets, e.g. digitext encompassing extensive news service or T-Learning combined with T-Chat, etc. Thus, the explanations and classifications merely serve to describe types of applications and their general concepts.
2.1.2 Information Services
EPG The Electronic Program Guide is a common application that should be available in all countries and on all STBs. In many cases there are even individual EPGs for different services on offer. The EPG lists available TV channels and the TV programs that run on these channels. Frequently, the EPG is a 7-day program guide. The program data is usually obtained by reading Service Information (SI) data from the broadcast services. Thus it can inform the user on what is currently on air, what will be broadcast next, etc. While STBs usually offer this information in their individual look and feel (defined by the STB manufacturer), most broadcasters offer their specific, more extensive EPGs. This is especially interesting if they operate more than one channel, because an attractive EPG may draw users to certain programs on additional channels.
Figure 2-1: EPG of the ARD Portal
Figure 2-2: Simple STB-EPG (TechniSat)
30th March 2006
The MHP-Guide Version: 1.0
Page 21 of 215
News Service / Event Service There are various kinds of News Services; most of them are portal-like listings of current affairs, some with sophisticated categorization, and others with very simple structures. News Applications range from simple Live-Tickers provided via a small overlay band (in most cases at the bottom part of the screen) to extensive (program related) information portals on big events such as championships, Olympic Games or the Grand Prix Eurovision de la Chanson1.
Figure 2-3: News Service with ¼ scaled video (Mediaset, Italy)
Weather Forecast Weather Forecast Services are usually of the type “broadcast only”. Interactivity lies mainly in the fact that users can choose detailed views of certain regions for a certain day. Various services throughout Europe offer a selection of regional, national and international forecasts and current information.
Figure 2-4: Weather Service (RTL TV interaktiv, Germany)
Traffic Service Similarly, Traffic Services can offer users a choice of detailed information on a certain region at a certain time. rbb’s prototype of an interactive traffic service highlights construction sites, traffic jams and other road blocks for any selected region in Berlin and Brandenburg. Traffic information may also include information and schedules of public transport services, train stations and airports.2
1 Examples can, among others, be found at http://www.mediaset.it/digitaleterrestre/ or
http://www.ard-digital.de/index.php?id=282&languageid=1.2 For a video presenting the user scenario visit
http://www.rbb-online.de/_/unternehmen/beitrag_jsp/activeid=254/key=teaser_300427.html
30th March 2006
The MHP-Guide Version: 1.0
Page 22 of 215
Figure 2-5: Traffic Service (Prototype, rbb, Germany)
Digitext / teletext iTV offers the opportunity to deliver all sorts of extra information related to the TV program much in the way it is done on the Internet. In addition to regular, i.e. the currently usual, text-based pages, broadcasters or service providers can offer pictures, audio and video in interactive portals, mostly relying on bi-directional interactivity especially for video delivery.
Figure 2-6: Interactive multimedia teletext (Pro7, Germany)
2.1.3 Communication Services
T-Mail / T-Chat Various companies on the MHP market offer MHP-based mail clients. These can be integrated in special community services by broadcasters, i.e. in program enhancement, but they can as well be implemented in the STB directly, just like an EPG (see section 2.1.2). Mail and Chat applications are clearly of the bi-directional type as they involve actual communication among end-users. It goes without saying that these applications require the use of the return channel to connect to a mail server on the Internet and a keyboard, physical or virtual on screen.
Figure 2-7: TV mail client (Alticast)
30th March 2006
The MHP-Guide Version: 1.0
Page 23 of 215
2.1.4 Entertainment Services
T-Games Interactive Games for the TV screen may range from “broadcast only” to “bi-directional”. “Broadcast only” style would include so-called Arcade Games like Tetris, Black Jack and the like. These games are mostly TV compatible as interaction here only requires very few keys on the remote control and can be handled very easily. Applications are relatively small and quite well-received by customers. As they usually are not related to specific TV programs they are provided by middleware or STB developers rather than broadcasters3, so that, similar to the mobile phone market, these applications would be delivered with the STB or downloaded from a website of a software provider directly to the iTV Terminal.
T-Games Interactive Games to play on the TV screen.
Figure 2-8: Arcade Game on TV screen (sofia digital)
Beyond basic Arcade gambling, some providers also offer traditional board games transferred to iTV applications, e.g. Sky’s version of Cluedo, Soccer (penalty) games or even more program related offers like BBCi’s CBeebies (amongst others an interactive Big Brother game).4
Figure 2-9: Interactive TV Game (ZDF, Germany)
Broadcasters have also built quiz games applications related to specific shows and enabling users to participate in these shows. Multiple choice games are especially applicable as there is a finite number of selectable options, so that users can even use the color-, arrow- or number keys on the remote control to select the correct answer. Figure 2-95 shows a kids’ quiz which has been broadcast in Germany since the 1970s; kids in the 3 See, for example, http://www.broadbandbananas.com/, SofiaDigital at
http://www.digitv.fi/sivu.asp?path=9;1239;3392;3928, or http://www.digeo.com/prodserv/digeoitv.jsp.4 All applications listed in this paragraph can be found at www.broadbandbananas.com/ with screenshots,
scenario videos and background information. 5 For a use scenario of this iTV game see
http://www.zdf.de/ZDFmediathek/inhalt/16/0,4070,2173552-6-wm_dsl,00.html
30th March 2006
The MHP-Guide Version: 1.0
Page 24 of 215
studio see a short video and hear a question. After that they get some 30 seconds to choose the right answer by jumping back and forth between the possible statements. With the new interactive version, kids at home can also make a choice. Via the color keys (blue, green, yellow) they can select one out of three cartoon figures jumping between the three available choices. They score a point if the figure ends up on the correct spot. (For more edutainment examples, cf.
62.1.7 T-Learning). The same is, of course,
possible with quiz shows for grown-ups like the two ARD Quiz Shows (Germany) or “Who Wants To Be a Millionaire?” (France, Germany, Italy and the UK)7.
For more and other ways of interactive TV Games the reader is also recommended to take a look at BBC’s Channel 4 Games:
http://www.broadbandbananas.com/
Video on Demand Services iTV can also function as a distribution interface for Video on Demand (VoD) Services. Via such a portal customers select films from a range of available movies. In hotel rooms of the world this portal will be more a transaction interface where a time slot is ordered that will later be charged on the hotel room bill – the movies are transmitted or delivered by a fixed schedule and the customers’ actions on the portal will merely allow access. As the schedule would be kept even without interaction by a single user this way of selling access rights is also called Near-VoD. “True” VoD, e.g. at home would offer the possibility to choose a film that would actually be delivered because of this transaction. The TV program is available “on demand”, whenever the end-user chooses. Usually, the STB would have broadband access and the selected movie would be delivered via ADSL or a similar connection.8
VoD / Video on Demand: Films can be ordered and started individually by request of the customer, independent of broadcast program schedules.
Figure 2-10: Video on Demand Selection (gist)
6 For the Edutainment program “Kopfball” see http://www.ard-digital.de/index.php?id=2670&languageid=1,
for “Das Quiz mit Jörg Pilawa” see http://www.ard-digital.de/index.php?id=280&languageid=17 There may be more iTV applications on this quiz format in other countries. For France and UK see
http://www.broadbandbananas.com/, for Germany http://www.rtl.de/tv/743540.php, for Italy: http://www.mediaset.it/news/scheda/9109.shtml
8 The screenshot shows a VoD Service by German developer company GIST (http://www.gist.de/). See also http://www.digeo.com/prodserv/moxi_ondemand.jsp for a concrete VoD service.
30th March 2006
The MHP-Guide Version: 1.0
Page 25 of 215
2.1.5 T-Commerce Analogue to the term e-Commerce T-Commerce covers all sorts of “commercial “ applications and transactions that are delivered and performed on the TV screen.
T-CommerceInteractive TV offers a number of possibilities for T-Commerce, from interactive advertising to triggering actual purchase transactions via the TV set (also called “transactive TV”).
Tele-Shopping A number of T-Commerce applications have been developed/ proto-typed already.
With an extra feature of the pontegra browser (www.nionex.de) users can track current eBay auctions and be informed as soon as the auction status changes.9
Figure 2-11: Tracking ebay auctions on the TV screen (Nionex)
There are also a number of iTV Shopping portals using different iTV standards: Nionex offers a “pontegra T-Commerce shopping solution10
which appears to be transactive and bi-directional. German Mail-Order company OTTO also created an interactive shopping portal where customers can see, select and order all sorts of goods from the TV screen-adapted catalogue just like they would on the Internet.
Figure 2-12: Sofa Shopping with OTTO’s interactive MHP Shop
Interactive Advertising There have also been a number of prototypes for interactive advertising, e.g. an MHP-based ad for Daimler-Chrysler in 200211. Beyond merely attaching further information that is made available through interactive navigation menus, optimum impact is expected from an emotional contextualization of the product [DUREAU 2004]. There have been various prototypical applications that connected certain products to TV programs 9 Brochure available at the site of the application developer, Nionex:
http://www.nionex.de/downloads/Images/29_3463.pdf/download_pontegra_eBay_tracking.pdf10 http://www.nionex.de/downloads/Images/29_3462.pdf/download_T-commerce.pdf11 For more information see http://www.mhp-forum.de/content/applikat/daimler.htm
30th March 2006
The MHP-Guide Version: 1.0
Page 26 of 215
through object tracking and interactive menus for background information.12
2.1.6 T-Government
Regional Information Portals Despite strong efforts - e.g. in Italy - to push iTV as a prime medium for e-Government there are not yet many relevant T-Government Services. Especially regarding interactivity the available services seem rather meager to date. Some network providers and especially STB developers have made first tests on the use of chip cards in STBs to enable maximum data security. Currently, a number of regional information portals in Finland and Italy are on offer as “T-Government” services; however, they often merely combine tourist information with local news and announcements.
Figure 2-13: Regional Information Portal for the city of Tampere (Finland)
The ‘Italia Utile’ (‘Useful Italy’, also called “Utile T-Gov”) DTV portal is planned to make available public information and services currently on offer via the web based e-government portal Italia.gov.it also via terrestrial digital TV. Its interface will be similar to that of classic teletext information services, however, it will be faster and offer two-way interaction.13 Availability is forecast for autumn 2006 or later.14 Piemont already has a basic portal with regional information, apparently broadcast only. T-Government is said not to be as useful for bi-directional services, mainly due to the fact that consumers are not used to writing with a Remote Control device. However, this might change with the current generation of SMS writing youths who will easily adopt to writing with such a device which is even slightly bigger than a mobile phone. Currently, according to rumors and vague forecasts authorities test technical and legal preconditions to transfer actual transactions from the Internet to the iTV platform(s), like submitting tax calculation forms or even voting.
12 See for example www.fun-tv.de/content/dokumente/ditv_anga_2005e.ppt#295 or
http://www.joanneum.at/en/informatik/bibliothek_detail.php?p_iid=IIS&p_typ=PUB&p_id=2193.13 Taken from http://europa.eu.int/idabc/en/document/3648/571814 Find out more about the current status of fat http://www.raiutile.rai.it/articolo.jsp?id=437
Analogue to the term e-Government
T-Government covers all sorts of information services and (ideally) communication and actions with the relevant authority, delivered and performed on the TV screen.
T-Government
30th March 2006
The MHP-Guide Version: 1.0
Page 27 of 215
Voting
As an interactive instrument for the democratic society iTV already can be used for opinion polls15. Voting applications, of course, can be used for all sorts of entertainment programs as well.16.
Figure 2-14: Voting application related to News Show (SkyTV, UK)
2.1.7 T-Learning
T-Learning covers all sorts of educational applications that are delivered and performed on the TV screen. In various publications this ranges from providing program related (educational) background material to interactive learning applications which check and track learners’ progress.
T-LearningAnalogue to the term e-Learning
An example for the potential of iTV for T-Learning in a program related context is a kids’ edutainment format of German Pay TV channel FoxKids. In this case the MHP application is not only used to offer extra information on the program, but involves the kids in what they see and hear, giving them an interactive learning experience. Learning and teaching experts say that learners remember 30% of what they see, 20% of what they hear, 50% of what they read and hear and up to 90% of what they do themselves17. Some others also stress the power of narrative teaching18. This example complies with both ideas, telling stories in English and asking questions in German to check understanding. Examples like Goosebumps and “1-2 oder 3” (ZDF, Germany, see section 2.1.4 Entertainment) may give an idea of how iTV can be used for T-Learning, not only for children but also for grown-ups in Business TV (cf. section 2.1.5 T-Commerce) as well as T-Health (cf. the following section) or “pure” T-Learning environments.
Figure 2-15: Kids’ Edutainment: Goosebumps (FoxKids, Germany)
15 Example from SkyTV; see http://www.broadbandbananas.com/ 16 For entertainment-motivated voting applications visit http://www.mediaset.it/news/scheda/14888.shtml .17 Common understanding in Learning Theory, quoted in Margit Hertlein. Mind Mapping – Die kreative
Arbeitstechnik. Spielerisch Lernen und Organisieren, Hamburg 2001 18 For a comprehensive overview and bibliography see Rossiter, Marsha: Narrative and Stories in Adult Teaching
and Learning, available at http://www.ericdigests.org/2003-4/adult-teaching.html
30th March 2006
The MHP-Guide Version: 1.0
Page 28 of 215
2.1.8 T-Health/T-Care
T-Health covers all sorts of information services related to health and well-being that are delivered and performed on the TV screen.
T-Care Analogue to the term e-Care
T- Care covers all sorts of communication services that connect patients and health care personnel in (bi-directional) TV-based communication applications.
T-Health Analogue to the term e-Health
The term T-Health covers basically every kind of TV based information on health, wellness and medical topics. A special variant of health applications is “T-Care”: T-Care is a truly interactive and bi-directional way of connecting patients and care persons or health institutions via iTV. Basically, this sort of information exchange is based on T-Mail and T-Chat facilities (cf. 2.1.3 Communication). In some cases19, however, this involves dedicated applications for exchanging current data on blood pressure (Patient enters figures with the Remote Control after taking the blood pressure) or other medical data. The application also stores patients’ information on the correct medication for patients and care personnel to see and check. An example for such a TV-based interactive healthcare platform is a system called Philips Motiva that was implemented and tested in the US in 2005. Chronically ill patients are connected directly to their care providers in order to motivate them to modify their behavior – to follow their doctor’s guidelines, eat right and exercise more. They receive a combination of tailored educational content, timely reminders and positive reinforcement around personal goals. In addition, patients are able to track their own vital signs – such as weight, heart rate, heart rhythm, and blood pressure. 20
2.1.9 Business TV Business TV is more a use case scenario than a type of application of its own. However, the idea of combining Information Services, (Internal) Communication, T-Commerce, T-Government-like applications (to communicate with the Human Resources Department) and T-Learning for Further Education is worth considering especially for application developers and network providers. Organizations may use these types of interactive applications to provide all sorts of information and communication facilities to their employees (Intranet-style) and, to a smaller extent, to business partners and customers. A German housing society, for instance, offers all sorts of information to its tenants and potentially interested persons.
Figure 2-16: Customer Information at Housing Society “ewt” (GIST, Germany)
19 Unfortunately, there were no screenshots available. For more information on one possible application scenario
and the respective success story contact www.ortikon.com (Finnland). 20 For details see: http://www.medical.philips.com/us/news/content/file_804.html
30th March 2006
The MHP-Guide Version: 1.0
Page 29 of 215
2.2 Levels of interactivity Roughly speaking, ”interactivity” in iTV may be categorized along three basic levels:
Broadcast only: Broadcast only applications, such as digital teletext and personal video recording (PVR), obtain required data from the broadcast stream. They only support “local interactivity” where the consumer may interact locally with data stored on the end device.
Unidirectional Interactivity: Unidirectional interactive applications, such as online voting and advertisement response, allow users to provide response data in a single direction, with no direct reply from a return path server.
Bi-Directional Interactivity: Bi-directional interactive applications, such as email, web browsing, and online gaming, allow users to acquire data from sources outside of the broadcast stream, such as a return-path server.
The table below shows how these technical levels of interactivity relate to certain types of applications.
Level of interactivity
Type
Application
Broadcast only
Unidirectional Interactive
Bi-Directional Interactive
EPG ∗
News ∗
Weather Forecast ∗
Traffic Service ∗
Information
Teletext/digitext ∗
T-Mail ∗ Communication
T-Chat ∗
T-Games ∗ ∗ ∗
Video On Demand (VOD) ∗
Entertainment
Betting ∗
T-Banking ∗
Promotion application ∗
T-Commerce
Interactive Advertising ∗
30th March 2006
The MHP-Guide Version: 1.0
Page 30 of 215
T-Government Information Portals ∗ ∗ ∗
T-Learning Edutainment games ∗
Professional Further Education ∗ ∗ ∗
T-Health Information portals ∗
T-Care ∗
Table 2-1: Levels of interactivity in relation to types of applications
30th March 2006
The MHP-Guide Version: 1.0
Page 31 of 215
3 Introduction to MHP This chapter gives an overview of the background of MHP development as seen from the perspective of the relevant market players and also provides a look into the aspect of EU wide regulation.
It lines out the current state of MHP as well as planned new developments (which are discussed in more detail in chapter 16.
Additionally it presents an overview of the MHP activities in some European countries.
3.1 The DVB Project Around 1990, the technologies of video coding, channel modulation and chip integration had - after decades of research - reached a status which indicated that digital TV broadcasting could be commercially realized in the nearer future. In 1991, a "European Launching Group" was established which started to coordinate with all interested players the basic technology issues required for the introduction of digital TV. Since the official foundation of the DVB project emerging from this group in 1993, this initiative has successfully bundled all relevant technical developments in the area of digital television. It has developed specifications for digital television systems, which are fed into international standards bodies such as ETSI. These DVB/ETSI standards are world-wide adopted and they provide the basis for hundreds of cable, satellite and terrestrial networks and the markets related to these networks.
Within Europe, the success of DVB has brought a degree of interoperability that is much wider than ever before in history. Today, this has hindered an open and community-wide TV distribution and TV market.
DVB currently has some 250 member companies from all over the world covering all technical and service aspects related to digital TV.
3.2 The need for MHP as an open API standard
3.2.1 Market developments and DVB activities In the first phase of standardization, DVB concentrated on the fundamentals like channel coding for cable, satellite and terrestrial transmission, service information, teletext transmission and the basic encryption mechanisms. This was very helpful to achieve a successful early start of the digital TV market in around 1995.
Soon, however, discussions in some markets came up concerning API systems. It became clear that the potential of digital TV could considerably be enhanced by interactivity but at the same time different API solutions appeared in the market which were proprietary and incompatible. Both aspects of these solutions, being proprietary as well as being incompatible caused many worries to most market partners and only in some vertically oriented markets different APIs were introduced. In these markets usually one Pay TV operator decided which API to use and subsidized corresponding decoders. Other service providers were blocked from making their content visible on these decoders. Consequently, no broad market development took place.
30th March 2006
The MHP-Guide Version: 1.0
Page 32 of 215
Therefore, in 1997, the DVB project started to extend the scope of its successful work from pure digital TV to interactive digital TV and to develop a single API standard.
3.2.2 EU policy "Interoperability of digital interactive television services and enhanced digital television equipment, at the level of the consumer, should be encouraged in order to ensure the free flow of information, media pluralism and cultural diversity. It is desirable for consumers to have the capability of receiving, regardless of the transmission mode, all digital interactive television services, having regard to technological neutrality, future technological progress, the need to promote the take-up of digital television, and the state of competition in the markets for digital television services. Digital interactive television platform operators should strive to implement an open application program interface (API) which conforms to standards or specifications adopted by a European standards organization." (Recital 13 of the Directive 2002/21/EC)
This quotation from the EU regulatory framework for electronic communications networks and services clearly shows the political desire for open markets and standardized APIs in the area of digital interactive television.
This framework requires Member States to recommend service providers and equipment providers to use an open API. Competition in digital interactive TV is seen in the context of interoperability: if interoperability and freedom of choice for users have not been adequately achieved in one or more Member States, the Commission is allowed under the framework to take action in the area of digital interactive TV and even mandate a standard (Article 18 of Directive 2002/21/EC).
Consequently, the EU Commission welcomes the introduction of MHP as European iTV standard. EU commissioner Erkki Liikanen stated at the 4th EBU conference (March 2001) in Brussels:
“The Commission welcomes in particular the development of the Multimedia Home Platform (MHP) standardized by the Digital Video Broadcasting Group (DVB). The MHP platform has been developed by the industry, for the benefit of the industry. The Commission considers that this voluntary, industry led standardization is the best process to reach interoperability, and to guarantee widespread implementation of the standard.“
In their latest “Communication ... on reviewing the interoperability of digital interactive television services” dated 02.02.2006 (COM(2006) 37 final) the EU Commission states:
“The demand for interactive TV applications has proved to be less than many forecast some years ago, and the commercial success of interactive television remains limited. The most successful applications have been in the area of quiz shows, sport, gambling and reality television; governments have yet to find ways to exploit the technology successfully as a means of communicating with citizens.”
“Developments in the market, particularly in Italy, have shown that interoperability can be achieved when stakeholders act together with a common aim to implement a technical standard like MHP, but that this in
30th March 2006
The MHP-Guide Version: 1.0
Page 33 of 215
itself is not sufficient to ensure the emergence and growth of interactive digital television services; further business and technical developments are needed.”
The resulting conclusions of the Commission in this communication contain the following statements:
“The Commission’s priorities are now to work with Member States to ensure the successful switchover to digital TV, which is a pre-requisite for having interactive digital services, and to support open standards and the ongoing cooperation on interoperability and exchange of best practice between Member States and between stakeholders.”
“The Commission considers ... that mandating EU-wide standards under Article 18(3) of the Framework Directive would not contribute significantly to the growth of interactive digital television in Europe, and could have significant negative effects.”
“The Commission ... considers that the market is best served at the present time by continuing to rely on industry-led voluntary standardisation initiatives.”
By this communication the Commission plays back the main responsibility to successfully introduce an open interoperable API system to the market.
3.3 MHP activities in DVB Very soon after the take-up of the API standardization efforts in DVB in 1997, it became clear that, technologically, the new standard could not be based on any of the proprietary APIs as they existed in the market by then. Subsequently, and with far-sightedness, the decision was made to use Java technology as a basis for new common APIs. Every MHP compliant product manufacturer will target a broader market without depending on a particular broadcaster, and multiple service providers will be able to develop interactive applications without depending on a particular manufacturer, the only requirement they have to fulfill is to be MHP compliant. The strength of this standardization is its open approach.
Also this standard relies on existing and proven standards that have already been deployed (e.g. DAVIC). A first ETSI version of the standard (DVB-MHP 1.0) became available in July 2000. Already in August 1999, a public "over-the-air" demonstration of MHP applications and MHP decoders took place at the Internationale Funkausstellung IFA (International Broadcasting Exhibition) in Berlin. This first version of the MHP standard had a number of shortcomings, e.g. certain technical aspects had not been covered precisely enough. Consequently, the next version of the standard (MHP 1.0.1) was created. It was published by ETSI in October 2001 and was published by the Commission as European Standard on 31st December 2002 (OJ 2002/C 331/04). In June 2002, MHP 1.0.2 was introduced. This, in turn, was followed by MHP version 1.0.3.
3.4 MHP: Current status and new developments While the work outlined above primarily improved the basic profile of the standard, a new profile with additional features like HTML, extended back-channel usability or smart card API was published by ETSI (MHP 1.1). MHP 1.1, was published by ETSI in November 2001 as TS 102 812 v1.1.1 One major change with regard to MHP 1.0 is the inclusion of DVB–HTML,
30th March 2006
The MHP-Guide Version: 1.0
Page 34 of 215
based on the W3C specification. DVB-HTML is optional within the Enhanced Broadcasting Profile and the Interactive Broadcast Profile, but is an integral part of the Internet Access Profile. MHP 1.1 also provides a lifecycle model for plug-ins and includes support for application downloads via the return channel.
All valid DVB-MHP standards can be obtained from the ETSI website.
From a service and application point of view currently three profiles and one option called DVB-HTML have been defined allowing manufacturers to develop a range of products that provide different functionalities. Each profile can co-exist with others offered on the market.
Enhanced broadcast profile combines digital broadcast of audio/video services with download applications, which enable local interactivity. This profile does not support an interaction channel.
Interactive broadcast profile enables a range of interactive services associated or independent from broadcast services. This profile requires an interaction channel.
Internet access profile is intended for the provisioning of Internet services. It also includes links between those Internet services and broadcast services.
Options
Enhanced broadcast profile
Interactive broadcast profile
Internet access profile
DVB-HTML +
+ DVB-HTML
Prof
iles
Figure 3-1: Profiles of the MHP standard
There are a number of new technological developments beyond the internet access profile. They cover technologies like PDRs, IP delivery, HD and new video coding standards. All of them are in one or another aspect related to MHP as MHP can be seen a central control instance for DVB decoders. More insight in these developments is given in chapter 16.
3.5 Ensuring the interoperability of MHP Since first practical experiences with MHP were gained it has become evident that the interoperability of applications and decoders at a technical detail level would be a challenging issue for this complex standard. Enabling interoperability is enabling several systems (the components of the MHP end-to-end value chain) to interact with one another and to exchange data according to a prescribed method in order to achieve predictable results. In order to deal with these interoperability issues, a lot of testing has already been performed, basically checking all available applications on the emerging decoder implementations. IRT’s
30th March 2006
The MHP-Guide Version: 1.0
Page 35 of 215
interoperability workshops provided the organizational framework and technical basis for many of these tests. Today, there are still unresolved issues. In addition, the findings of the tests have not been systematically and completely documented. Interoperability, performance and ease of use are the responsibility of the actors of the complete MHP value chain. Solving the described problems is the prerequisite for MHP’s large-scale market success, which will be dependent on stable interactive services with a good performance.
Both, creation of the MHP Test Suite and the MHP Knowledge Database are initiatives to cope with the question of interoperability.
3.5.1 The MHP Test Suite DVB has taken into account the interoperability issue by releasing an official MHP Test Suite for Conformance Testing of receivers. Every MHP device on the market which aims at carrying the official MHP logo (see below) must have passed this Test Suite in a self-certification process applied by the manufacturer.
Figure 3-2: The MHP Logo
The strength and quality of the official Test Suite directly influences interoperability of systems in the market and is an ideal means to ensure that MHP support all features as defined in the MHP specification.
The MHP Test Suite is made available to decoder manufacturers via ETSI. It consists of thousands of test cases written as Java Xlets which can be run in an automated testing environment (ATE).
Test Suite versions 1.0.2a and 1.0.2b have been made available in September 2002 (1.0.2.a) and January 2003 (1.0.2b). Both versions of the Test Suite are related to the MHP standard version 1.0.2. Early March 2003 the DVB Technical Module approved version 1.0.3 of the MHP specification and is further working on advanced versions of MHP, such as the internet access profile (MHP 1.1.2 and PVR extensions). As a result, additional work is required to update the Test Suite to comply with these recent versions of the MHP standard.
Huge effort both financially and in manpower has already been invested by several companies, amongst them the partners who have in 2004 joined in the EC funded MHP-CONFIDENCE project.
Main activities of MHP-CONFIDENCE are to identify areas where MHP interoperability can be strengthened by additional Conformance Tests, to setup specifications for programming related tests, to implement these tests and to verify them in a quality acceptance process to such an extent that they match the quality criteria imposed for DVB’s Official MHP Test Suite.
30th March 2006
The MHP-Guide Version: 1.0
Page 36 of 215
3.5.2 The MHP Knowledge Project In order to actively support and accelerate MHP take-up throughout Europe, the MHP KNOWLEDGE PROJECT has been launched. Initiated by core members of the MHP Alliance, the EC co-funded research project combines the competence of some of the Alliance’s key players with that of notable partners from technology research.
By establishing the MHP Knowledge Database (MHP-KDB), a dynamically updated single "point of call" for all MHP related issues, the project sets out to tackle exactly the issue of interoperability of MHP implementations and applications. The knowledge database is designed to store all questions and issues that arise during the process of implementing MHP decoders and MHP applications.
MHP-KDB does not only rely on internal expertise but encourages the whole MHP community to contribute to the project by sharing practical experience on interoperability issues. This guarantees that the most pressing problems are addressed. The project ensures that useful information is available on all components within the entire value chain. It provides know-how and best practice solutions to all companies and organizations active in this field.
By July 2005 the MHP Knowledge Project made their MHP Knowledge Database available for online access to the whole MHP community.
The database is accessible via the project website http://www.mhpkdb.org. All interested users from companies and organizations active in the field of MHP are invited to benefit from the offered MHP knowledge and to actively make use of this new platform for information exchange. For the relevant MHP issues, the database presents a continuously growing number of solutions including reference application modules as "Open Source" code which is available for free usage by any MHP-developer. The know-how in the database addresses all components within the entire value chain of MHP-based applications. Annex A provides detailed information on how the MHP Knowledgebase works.
The project website also gives access to a "virtual test centre" which presents the unique possibility to test MHP applications online on standard hardware MHP decoders, without the need for physical access to a testing laboratory. More information on the online test centre can be found on the project’s website http//www.mhpkdb.org.
The MHP-KDB partners are in detail: Institut für Rundfunktechnik GmbH, München, Germany (Co-ordinator)
Bayerische Medien Technik, München, Germany
Danish Broadcasting Corporation, Søborg, Denmark
Deutsche Welle, Bonn, Germany
Instituto Tecnológico de Aragón, Zaragoza, Spain
Rundfunk Berlin-Brandenburg/ARD Digital Play Out Center, Potsdam, Germany
Panasonic AVC Networks Germany GmbH, Peine, Germany
Philips CE/STB, Suresnes, France
Telenor, Fornebu, Norway
30th March 2006
The MHP-Guide Version: 1.0
Page 37 of 215
tComLabs, Ghent, Belgium
Universität Duisburg-Essen, ICB, Essen, Germany
3.6 MHP in the markets This section describes in short the current status of the MHP deployment in some European countries. More in-depth information on MHP in various markets can be found in the document “Analysis of the Current Situation” at http://www.mhpkdb.org/publ/mhp-kdb_d1-ver-2.pdf.
As many of the described activities still are in experimental stage, some of the information given may be outdated soon. Nevertheless it provides a short documentation of the efforts made.
3.6.1 Austria In the Austrian city of Graz a DVB-T test, including the broadcast of MHP based interactive content, ran for 3 months starting in June 2004. This test run was provided by a number of public and private broadcasters.
In addition to the three regular TV services ORF 1, ORF 2 and ATV+ an interactive service called „!TV4GRAZ“ was distributed via DVB-T. 150 MHP-enabled DVB-T set top boxes, including a return channel, were provided to households for using the broadcast interactive service. The interactive content was accessible to the consumers via an MHP-Portal. It contained enhanced applications, like EPG or news ticker as well as interactive applications using the return channel, like a quiz and an interactive advertisement that included the possibility of requesting further information.
Also Austrian cable network operators are testing MHP via DVB-C and cable-based return channel. The cable network operator Salzburg AG ran test applications, including news ticker, SMS/email applications, games and ticket ordering, until February 2005.
On Feb. 23 2006 the Austrian regulator granted a license to operate two nation wide DVB-T multiplexes to the “Österreichische Rundfunksender GmbH&Co KG” (ORS). The ORS will serve as a platform operator for these two multiplexes.
Part of this license is the obligation to use MHP for interactive applications. This license explicitly refers to Art. 18 of the framework directive and the obligation of the EU member states to encourage open API standards in its MHP argumentation.
The ORS has published a receiver specification (to be found at www.ors.at) which requires the implementation of MHP 1.1.2 for compliant receivers. This specification is also valid for the satellite market as the relevant services are also distributed via DVB-S – including the MHP applications.
It is planned to add on the first multiplex a MHP bitrate of 600 kbit/s to each service. Besides an MHP EPG also commercial MHP applications are foreseen.
30th March 2006
The MHP-Guide Version: 1.0
Page 38 of 215
3.6.2 Denmark Denmark currently has digital cable (TDC) and satellite (Canal Digital and Viasat) networks. At present, there is not too much interactivity on air. Existing offers are either based on OpenTV (TDC and Viasat) or MediaHighway (Canal Digital). The construction of a DTT network has just started in 2004. This network will be based on MHP.
DR has been supporting MHP from the very beginning – through participation in MHP Alliance, MHP Action Group, and through NorDig. In June 2001, DR initiated an analysis project with the purpose of preparing DR technically to develop and broadcast MHP applications. It is the result of this work that we now see being used in the development of the DR Portal application and its supporting infrastructure.
As DR launches the DR Portal, it will be made available in the satellite networks in proprietary APIs as well as in MHP. This, however, refers only to the migration period. After that it will be MHP only. The MHP-portal will also be made available in the DTT network, and, most probably, also in the cable network as part of the 'must carry legislation'.
The DTT network is currently under construction and will be put into operation by in early 2006. The channels that will be available initially in the DTT network will be DR and TV2-DK channels and a common EPG service is also planned. The market for set top boxes will be horizontal with no subsidizations. The DR interactive 24/7 information service was launched in the fall of 2004 and is broadcast on satellite and later also on DTT.
3.6.3 Finland A total of 16 television broadcasting stations and ten television sub-transmitters in northern Finland will be digitalized during the third phase of the extension of the digital television network.
Digital television will make numerous new channels available to the consumers. Until now, three television channels have been broadcast via the terrestrial television network in these areas. The extension of the network will increase the number of channels to ten. The channels available in the digital television are the channels TV1, TV2, YLE24, YLE Teema (YLE Theme) and YLE FST of the Finnish Broadcasting Company. In addition, the selection includes MTV3, MTV3+, Subtv, Channel Four Finland and Channel Four Plus.
In addition to new channels, the digital television offers several additional services, such as a television program guide, digital text television and channel-specific additional services. The services are available using MHP (Multimedia Home Platform) compatible receivers.
Digita DTT has defined some network rules of operation including special requirements for MHP terminals in Finland.21
Current MHP applications on air as a regular service in the DTT networks are:
21 These rules can be found at
http://www.digita.fi/digita_dokumentti.asp?path=1841;2081;3640;2113 http://www.digitv.fi/digiProEtusivu.asp?path=9;1826
30th March 2006
The MHP-Guide Version: 1.0
Page 39 of 215
YLE offer: Supervideotext, Memory game, NE-spelet, News ticker, Government facts
MTV offer: Real estate finder, TV-bank (and Hockey score ticker, Weakest Link and Formula 1 as prototypes).
Digita, the Finnish Broadcasting Company, MTV3 and Channel Four Finland have agreed on extending the broadcasting network of digital television to cover the whole of Finland during 2005.
3.6.4 France DTT was launched officially on 31st March 2005. The coverage concerned 35% of population at start and was extended to 50% until 1st of September 2005, date of the Pay TV services launch, which have the particularity to be mandatory MPEG-4 video codec compliant. The assumption was that interactive TV services are closely linked to pay TV offers.
No consensus could be found between the different players concerning interactivity: whereas the public broadcasters support MHP, commercial broadcasters are generally in favor of proprietary solutions.
No clear choice on interactivity can be made until the commercial distribution has taken up.
A regulatory text called “Paquet Telecom” (including standard recommendations from the European Commission toward MHP) has been adopted in France in July 2004.
According to two technical arrests, describing the signal content compliance as well as the legal obligation for DTT receivers, were promulgated by the Ministry of Industry:
Receiver: the receiver must be compliant with IEC/CENELEC 62216-1 norm.
Signal: signaling and securing information must be compliant with TS 102 812 (MHP 1.1). If any broadcaster uses another standard, it has to be a non-proprietary open standard and it must be made known to the CSA (French regulatory board).
3.6.5 Flandern In Belgium, media (TV, Radio) is within the power of the communities (Flemish speaking, French speaking and German speaking). In the Flemish community, about 97.5% of the homes can be connected to the cable network and more than 90% of these homes are actually connected to the cable network to receive analogue cable television. In September 2003, the public Flemish broadcaster VRT, the commercial broadcasters VMMa, VT4 and afterwards MTV and the owners of the cable network Interkabel and Telenet signed a cooperation treaty called “Vlaanderen Interactief” (Flanders Interactive). Within this cooperation, they will do research on the technological and the social scientific side of iDTV. This cooperation will also prepare the introduction of iDTV in Flanders. The project is supported and funded for 12.4 million euros by the Flemish government. “Vlaanderen Interactief” has chosen one standard: MHP.
In September 2005 Telenet started its commercial deployment of interactive digital television. In addition to a number of digital television channels, Telenet offers different types of applications: a TV portal, an EPG, interactive applications like voting, VOD, shopping and will launch a
30th March 2006
The MHP-Guide Version: 1.0
Page 40 of 215
PVR with MHP middleware in March 2006. The government is also interested in offering access to different e-government services and in the near future everyone will be able to authenticate himself by putting his electronic identity card in the smart card reader of the set-top box.
Belgacom, the incumbent national telephony operator and a competitor of Telenet, offers since the summer of 2005 also digital TV, but over xDSL. Besides digital TV, video on demand, web access and Interactive TV will be offered. The middleware is produced by Myrio, which was recently taken over by Siemens (the system integrator for the Belgacom TV project). For strategic reasons, not much technical information is made public.
In the meantime Flanders is fully covered by DVB-T. Only the TV (2) and Radio (9) channels from the public broadcaster VRT are available. No interactive services are offered and the VRT doesn’t make any promotion for that network.
On the cable networks from Interkabel, people are now also able to receive digital TV (DVB-C) without any interactive services.
3.6.6 Germany The major German market players have considered the introduction of digital television including interactivity via APIs since 1995. Due to the lack of standards, original planning had been based on proprietary systems. It became clear soon, however, that these systems were not suitable for open, horizontal mass markets. German partners have consequently contributed very actively to the development and deployment of MHP.
MHP was first demonstrated publicly in Germany at IFA 1999, the first regular services were started in mid 2002.
Meanwhile several broadcasters (all of them free TV) offer a number of regular MHP services.
In addition to the MHP activities of established TV broadcasters, some new players have entered the stage: The big German mail order company "Otto" has started to offer its products via TV, using an interactive MHP application. Furthermore, "Hörzu", a well established TV print magazine, now broadcasts an MHP version via TV.
Even though in 2003 more digital satellite receivers than analogue satellite receivers were sold in Germany for the first time, MHP has not yet developed into a market success.
The start of DTT and the analogue switch-off on 4. August 2003 in the region Berlin/Brandenburg was accompanied by the introduction of enhanced TV services based on MHP. Since then a number of regions followed and some are already preparing DVB-T. Due to the fact that terrestrial analogue TV will be switched off by 2010, it can be assumed that the purchase of DVB-T boxes will increase continuously in the next years in Germany. Since the beginning of 2005, three DVB-T boxes enabling MHP are available on the German market (see also section 2.4.3). The sales prices of the MHP DVB-T boxes range from 225 € to 800 €, while prices for DVB-T boxes not supporting MHP start at 70 €.
The higher costs and the lacking of a good promotion of MHP terminals might constrain their powerful impact on the German TV market. If these
30th March 2006
The MHP-Guide Version: 1.0
Page 41 of 215
problems will be overcome and the broadcasters will offer more interactive services, MHP will have a bright future in Germany.
In January 2005 some German cable operators decided to support MHP in their networks; no regular services, however, have been implemented up to now. The majority of the cable operators, however, is not interested in MHP.
T-Online intended to introduce an MHP set-top-box with hard disc at IFA in September 2005. This terminal integrates DSL which guarantees a high-speed return channel suited for MHP applications. Value-added services such as Video on Demand (VoD), games, ring tones, video clips are offered and can be invoiced via T-Online.
3.6.7 Italy On December 1st 2003, Mediaset and RAI have started digital terrestrial TV broadcast aiming at coverage of 50 % of the population with a plan to have a fast extension to the entire country.
By end of 2004 the coverage already exceeded the 50% threshold.
The Italian national broadcasters (RAI, Mediaset, La 7) have adopted DVB MHP as the standard for interactive applications for the Italian DTT.
The Telecommunication authority defines the broadcast licenses for network operators and authorizations for the TV content suppliers for an antitrust system. As a component of the regulation, the Italian government has allocated a budget for a contribution of initially 150 euros per interactive DTT receiver for 900,000 receivers.
Italy is now by far, thanks to Government subsidies for interactive receivers, the country with the highest number of MHP set-top boxes actually deployed in consumers' houses. In 2003 and 2004 actually 730,000 MHP terminals have been deployed into the households.
In 2005 the subsidies have been lowered to 70 Euros per MHP decoder, but an additional deployment of more than 1,000,000 MHP terminals is expected.
In Italy there are already 15 to 30 analogue programs available. In fact, DTT contents rely on interactivity more than quantity and in the Italian DTT networks interactive MHP applications play a very important role.
The overall interactive offering per DTT provider is:
Mediaset 26 applications
LA7/MTV 10 applications
LA7 6 applications
RAI 8 applications
According to the deployments encouraged by the subsidies there is a quite huge number of MHP terminals available in the Italian market.
To allow an optimum interoperability between the various networks carrying MHP applications and the available decoders the DGTVi has generated a "D-Book" (http://www.dgtvi.it/stat/Industry/D-Book/Page1.html).
DGTVi is an association (composed of RAI, Mediaset, La7, MTv, and the Fondazione Ugo Bordoni) working to enable the deployment of digital TV.
30th March 2006
The MHP-Guide Version: 1.0
Page 42 of 215
On its web site, one can find the coverage of the operators for DTT (www.dgtvi.it).
DGTVi proposes to the manufacturers to conform their products to D-Book on a voluntary basis. A DGTVi logo (cf. Figure 3-3) has been created and will be released for certified receivers that will pass a test procedure. These tests are performed in a self certification process by the vendor itself.
Figure 3-3: DGTVi Logo
3.6.8 Norway On 26th February 2004 the Parliament approved that a DTT network can be established in Norway. When the transmission will start is not published, and is dependent on who is going to be implementer of the infrastructure. Some conditions are the most important part of the approval:
The network shall have coverage of at least 95 % of the population.
All households in Norway shall, after the analogue switch-off, have a digital TV offer with all the programs from NRK and TV2, and hopefully the other Norwegian channels. This is related to total coverage, independent of the distribution platform.
The most popular Nordic and other foreign channels are to be included in the offer.
The analogue switch-off will be implemented region by region, and expected to be finalized by the end of 2008. There will be no funding from the Government.
The cost for the set-top box is expected to be NOK 1300 –1500 (EUR 165-190).
There is one company ”Norges Televisjon AS” (NTV), which is owned 50 % by NRK and 50 % by TV 2, that has got an advanced commitment for the license to be responsible for the DTT transmissions. They will also be responsible for the selection of programs, establishing and running the multiplexes and they will possibly pay for the distribution.
The government has reopened the possibility to apply for license on DTT due to new license period. Telenor by Telenor Broadcast has signalized that they will be one of the appliers for license in addition to Norges Television. The Telenor owned company Norkring AS will then build the network. They own most of the infrastructure that is expected to be used.
NTV has planned to distribute two multiplexes from the start; one with public service broadcasters’ programs and one with some Pay TV channels, the program package has, however, not been finally decided upon. A third multiplex is planned for a later stage. Ahead of the analogue switch-off there are currently only frequencies for three multiplexes.
The set-top box offer to the consumers will be based on re-tail, with some kind of support from NTV to a few set-top box vendors. A specification for
30th March 2006
The MHP-Guide Version: 1.0
Page 43 of 215
the set-top box, mainly based on the NorDig (cf. below) spec., has been the basis for discussions with some vendors, and the set-top boxes shall be prepared for MHP services. (NorDig All transmissions will be encrypted. The set-top box shall have one embedded CA solution, but the CA vendor is still not decided.
Telenor Broadcast, including Satellite Broadcasting, Norkring and Canal Digital, have promoted MHP since 2000. In 2000, Satellite Broadcasting started developing an MHP 1.0 platform (play out) which was presented at IBC2000. The reason for starting this development was that at the time no playout platform with the wanted functionality was available. As a satellite network operator Telenor wanted a multi-user playout to be also used for cable and terrestrial. Several customers were to use the playout/ object carousel while the broadcaster was to control its own applications. A web interface was developed where the pilot customers could upload their applications, and the Thor II satellite was used for distribution. The pilot service started with seven customers, on satellite in 2001 and had MHP 1.0 (enhanced broadcast) on air until October 2003. The main aim was to collect experience, to promote the use of an open API on interactive digital TV and to stimulate the horizontal market and third party application development. Telenor also started an MHP Forum in the Nordic countries in 2002 together with broadcasters and application developers. The forum had meetings where all the partners could discuss the use of MHP and how to launch MHP in the TV market.
In 1998, broadcasters and network operators in the Nordic countries started NorDig to specify a common standard IRD for the Nordic countries. In 2000 NordigII was specified with MHP Interactive Broadcast profile, and the Nordic broadcasters all promote MHP in DTH when the market is ready both with set-top boxes and applications. All the broadcasters want to use MHP in DTT when it is launched.
In late 2004 NRK started an MHP service on satellite and in spring 2005 they started a forum for development and usage of MHP together with the other public Nordic broadcasters.
3.6.9 Spain The current situation of digital television in Spain shows a panorama broadly dominated by the satellite platform. In the case of the cable platform estimations say that 60% of the TV cable clients received digital television in 2004.
In the year 2004 the number of homes having a terrestrial digital decoder begins to be of some importance, there is an estimation of about 130,000 homes with terrestrial digital decoders (mainly from the disappeared QuieroTV). After the crash of the platform Quiero TV, the DTT was restricted to the transmissions in digital of the operators that transmit free, and to the very limited offer of the other two operators that obtained also licenses (VeoTV and NetTV). During 2005 the Government has initiated a set of actions in order to get ready for the analogue switch-off before 2010. Thus, since November 2005, more than 20 free DTT channels are available, some of them including MHP interactive services (EPG, enhanced teletext, etc.)
The satellite technology is more extended and it has adopted faster the digitalization process due to its lower update cost. But the growing
30th March 2006
The MHP-Guide Version: 1.0
Page 44 of 215
competition of the cable sector and a business model based on maintaining a high entrance price, have caused a continuous descent of the clients of this platform from the year 2001.
Although initially the cable platform deployed in Spain was analogue, the different operators are involved in the digitalization process of their networks to be able to transmit a greater number of channels and to introduce other services. The big Spanish cable operators, ONO and AUNA, concluded the year 2004 almost reaching 100% the digitalization process. All the new clients receive digital television.
Television broadcast through a broadband connection is the latest option incorporated in the market of digital TV. Telefónica has launched its television service Imagenio, using ADSL technology, having at the end of 2004 about 5000 clients.
Some field trials and deployment tests (projects which include MHP services) have been carried out; among these initiatives we can find the projects ACTUA TV and MICROMARKETS.
ACTUA TV project (performed during 2003/04) consisted of a series of demonstrations, carried out in diverse commercial centers, dedicated to show to the public the technological capacities of DTT and of the MHP interactive applications. The demonstrations were carried out in stands with STB and iDTV. The base of the demonstrations was the programming of TELEMADRID and laOtra, acting as an interactive portal and enhanced TV.
The project MICROMARKETS consisted of a group of tests of the operation of DTT, framed in a project based on adding a channel to the digital emissions of Televisió de Catalunya. This project was developed during 2003 and 2004. The interactive contents were based on MHP applications (including the possibility to use the return channel) offering news tickers, weather forecast, chat, text messaging and interactive advertisements.
The continuation of the project MICROMARKETS will be “Maresme digital” which involves the deployment of the required infrastructure of DTT in the area of the Maresme. This area was chosen as a first sample territory (to be extended to other cities in the future) because of the poor signal reception due to the complicated geography. The project has been developed along the year 2005.
RTVE, the Spanish public broadcaster, launched initially some MHP applications on a trial basis in November 2004, and nowadays offers on its 5 channels in DTT a set of basic MHP applications such as enhanced teletext and an EPG.
3.6.10 Sweden The public service broadcaster (SVT) initiated broadcasting of MHP services on all digital platforms in 2004. These services consist of advanced text information services. A 500 user trial will soon begin in Gävle using the DVB-T platform to trial a MHP-based community information service.
30th March 2006
The MHP-Guide Version: 1.0
Page 45 of 215
3.6.11 United Kingdom Broadcasters in the United Kingdom are providing a lot of interactive content, starting with simple enhanced applications displaying additional information up to interactive applications which are using a return channel. However, all these applications aren’t based on MHP but on OpenTV (Sky Digital, BBC), MHEG-5 (terrestrial digital TV) or other platforms. The interactive content is quite successful and the consumers are used to press the red button for activating interactivity, e.g. in a sports bidding application.
MHP is currently only a topic for the BBC, which is doing some research projects answering questions like, which possibilities are provided by MHP 1.0 and MHP 1.1 or how can MHEG-5 content be migrated to MHP? However, it is most likely that the success of the available interactive content, implemented with MHEG-5/OpenTV, and the number of devices in the market will avoid a short term introduction of MHP services and devices in the United Kingdom.
This legacy situation including the usage of different APIs causes a problem for broadcasters like the BBC which deliver their services in parallel via networks using OpenTV and networks using MHEG-5. Interactive content therefore has to be adopted for both systems which either means giving up optimum usage of any of the systems by using meta formats covering both systems or having additional effort for individually optimizing the content for each system.
3.6.12 Switzerland In January 2006 the SRG (the swiss public broadcaster) has announced to launch interactive services using MHP by 2007. MHP will then be used via DVB-S and DVB-T. The SRG intends to use MHP also via DVB-C; the swiss cable operators, however, have partly introduced OpenTV and would like to keep this system.
One specific aspect of SRGs service concept for MHP is the support of disabled people by the optional transmission of additional information.
Starting in March 2006 the terrestrial transmission will be migrated to DVB-T. This process will be completed in 2009. Via satellite, SRG will open in May 2006 a second DVB-S transponder to broadcast their programs. HDTV is announced by SRG in 2010.
30th March 2006
The MHP-Guide Version: 1.0
Page 46 of 215
4 MHP iTV Applications NOVICE LEVEL
Xlet Xlet is the interface used for execution engine application lifecycle control in MHP.
iTV (Interactive Television) A capability in digital TV offering interactive services (e.g. information, communication, transaction, etc.) often directly related and synchronized with the broadcast content.
This chapter presents the concept of the MHP iTV applications. It also analyses the choice of the Java programming language and the specificity of Java in the TV context. It also gives an overview of the link between MHP applications and the various components in the broadcast chain.
4.1 MHP application An MHP application is an interactive application written in the Java-programming language. The Java MHP applications are called “Xlets”; they run on top of the MHP middleware. The Xlets have a specific lifecycle and are controlled by the broadcaster or user via the middleware. The Xlets can be started, stopped, paused and resumed.
4.1.1 Why Java? DVB has adopted the Java programming language for MHP interactive applications and has created a lightweight version suitable for broadcast applications called DVB-J or DVB-Java. Consensus was reached by all partners involved in DVB to adopt Java as language for MHP interactive applications due to its maturity, quality of tools and development skills available.
Whereas MHP is based on a subset of Personal Java 1.2, several major elements were removed; some to save space, others because their functionality is not needed in the TV context. Below the main changes in MHP are listed:
API (Application Programming Interface) The publicly accessible surface of software classes through which applications operate upon the specific functions contained within the MHP.
Several major parts have been added in MHP, such as additional APIs for STB-specific functions (DVB MHP API).
Where the functionality needed was too different from standard Java the code was modified
The UI model reflects the consumer, TV-centric model rather than the PC/workstation model,
Changes in the core Java classes were made to save memory space.
4.1.2 Extensions added from other standards1 The following extensions were added from other standards:
A worldwide association of bodies concerned to promote interoperability in audio visual equipment of all kinds concentrating on standardized interfaces.
DAVIC (Digital Audio Video Council) JavaTV API
Contained in package javax.tv. * This API comprises:
Xlet classes and infrastructure
Service selection
SI/PSI access
This API was standardized by Sun Microsystems: http://java.sun.com/products/javatv/
1 For more details and description of each API see Annex C.
30th March 2006
The MHP-Guide Version: 1.0
Page 47 of 215
DAVIC API Contained in package org.davic.* This API comprises:
Basic MPEG concepts
Tuning between transport streams
MPEG-2 section filtering
Resource management
Access to CA information
This API was standardized by DAVIC: http://www.davic.org
HAVi API Contained in package org.havi.* This API comprises:
Video/graphics integration
MPEG-2 A digital video and audio compression (encoding) technique defined by the Moving Pictures Expert Group (MPEG).
HAVi (Home Audio Video Interoperability) A vendor-neutral audio-video standard aimed specifically at the home entertainment environment. HAVi allows different home entertainment and communication devices to be networked together and controlled from one primary device, such as a PC or television.
UI widgets for consumer systems and TV screens
Solutions forhardware restrictions related to video and graphics integration on TV screen.
This API was standardized by HAVi: http://www.havi.org/
4.1.3 New TV Specific functionality MHP iTV applications in a TV context needed new functionalities that had to be specified in the MHP standard or to be re-used from other standards. The section below gives a brief overview of all these functionalities.
Service Information Access There are two different APIs that enable the MHP application to access the SI:
org.dvb.si.* a DVB specific API that provides access to all DVB-defined tables (except the AIT).
javax.tv.service.* an API independent from the underlying technology. It supports access to most SI data, but accessing the DVB tables is harder.
Media Control MHP applications sometimes need to control media (video, audio, subtitles, etc.); to do that MHP has defined different APIs.
Media control can be carried out via the Java Media Framework (JMF) that allows control over MPEG-2 media and audio media presentation (play/pause/change content).
Additional controls for broadcast-specific functions are split across several packages: org.davic.media.* + org.dvb.media.* + javax.tv.media.*;
TV-specific functions have been added in JMF:
Subtitles,
Scaling/positioning,
Decoder format conversion,
New content referencing method in URL format to reference DVB services and streams (locator).
30th March 2006
The MHP-Guide Version: 1.0
Page 48 of 215
Service selection The MHP applications can control what service is being presented on the TV screen. For that MHP has defined two APIs:
A JavaTV service selection API (javax.tv.service.selection); this enables the application to change the current service.
A DAVIC tuning API (org.davic.net.tuning); this supports the access by the application to data, also on TS different from the one the current service is in.
File System Access To enable MHP applications to access the file system in the terminal MHP uses the following packages:
java.io, used to access a file system; this includes DSM-CC access and persistent file system access.
org.dvb.dsmcc, added to support DSM-CC functionalities that don’t exist in a normal PC file system:
Stream events, Normal Play Time,
Asynchronous loading of files,
Caching hints,
Notification of object changes.
MHP has some restrictions in the file system access:
No absolute paths, these may vary between implementations.
No write access possible to a DSM-CC object carousel.
User Input A STB usually has no keyboard: the inputs are sent to the STB via a remote control.
The supported key codes from a remote control are defined by MHP and HAVI; other codes may be used, but are not interoperable. A standard set of keys is defined (e.g. arrow keys, OK, exit, digits…). MHP also defines a separate user input event API to support exclusive key access in org.dvb.event package (used for entering PINs, etc).
The Graphics Model Big changes compared to Java 1.2 have been introduced to the UI library and graphics model.
Standard AWT widgets are not available in MHP (Button…); only lightweight components are available. As the AWT windowing model gets changed a lot, the HAVi widgets can be used instead.
MHP applications can build their own widgets; this seems to be the most popular choice amongst implementers and allows a more TV-centric UI experience.
The org.dvb.ui package adds functionalities missing from other UI extensions:
TV-specific text layout support,
Alpha compositing between planes,
Font loading for downloaded fonts.
The HAVi widget set
30th March 2006
The MHP-Guide Version: 1.0
Page 49 of 215
The org.havi.ui package includes some basic widgets:
Buttons, check-boxes and radio buttons,
Text entry fields,
Static text,
Icons,
Dialog boxes,
Animations.
It also contains higher-level concepts (like HContainer, HComponent and others and also enables resource management for graphics-related components).
Window management issues There are several reasons for STBs not to have a full window manager like a PC:
MHP has no need for all functionalities,
An MHP application cannot use an AWT frame as the top-level component,
The HW may impose limitations not found in a PC environment.
Instead, MHP uses HScene (a HAVi replacement for frames).
HScene An HScene solves the problems with frames the from org.havi.ui package and implements the java.awt.container package.
HScene controls:
Which application has input focus,
How applications are laid out on screen,
Which applications currently are visible.
HScene 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 canot interfere with one another.
30th March 2006
The MHP-Guide Version: 1.0
Page 50 of 215
Frame
HScene HScene
ComponentHContainerComponent
Component
Figure 4-1: HScene in the UI model
Display devices A TV has different display characteristics than a PC monitor; this needed to be included this in the display model. The HScreen class represents a physical display device; it ties together all MPEG decoding, graphics and backgrounds; it models the use of graphics planes in the STB hardware.
Each HScreen consists of several lower-level devices; an example therefore is given in Figure 4-1.
Modeling graphics hardware In MHP the interactive TV display is split into three independent layers: the background layer, the video layer and the graphic layer, see Figure 4-2. HAVi defines a physical device for each layer:
HbackgroundDevice used to display either a still image or a plain color;
HvideoDevice used to present video from MPEG decoder;
HgraphicDevice used for application graphics and cursors.
All of these objects are subclasses of HscreenDevice.
30th March 2006
The MHP-Guide Version: 1.0
Page 51 of 215
HScreen
HBackgroundDevice
HVideoDevice
HGraphicDevice
Figure 4-2: Display structure
Being familiar with Java is not sufficient to develop MHP applications; developers have to assimilate the differences in the TV environment and the HW constraints set by STBs.
Which API for which application? To implement information applications such as a news application or a weather forecast application one needs to present this information in a user-friendly way. All the graphics APIs are important in that case (HAVI, AWT, DVB UI).
To implement an EPG the SI data must be accessed. The Service Information contains metadata necessary to locate, tune to and display services on a terminal. An EPG relies mainly on information displayed in the EIT (Event Information Table), the SDT (Service Description Table) and the BAT (Bouquet Allocation Table). Thus, to implement an EPG mainly the APIs are needed that enable the terminal to access the SI and to tune on a specific service. MHP has defined two APIs for that purpose:
JavaTV
Org.dvb.si
On the other hand also graphic presentation APIs are needed such as HAVI that enable the presentation of graphics and text on the screen.
T-commerce applications need the return channel functionality. Hence, all APIs that control the return channel are needed (org.dvb.net.rc) in addition to all other basic ones (graphic and UI).
Generally, every type of application has its specific API requirements, based on the functionalities needed. It is therefore important that application developers define all specific functionalities before starting the actual implementation.
4.2 MHP applications and the broadcast chain To play out an application, it has to be included into the transmitted transport stream and some additional signaling in the PSI/SI signals (cf. chapter 10) needs to take place (AIT table). The inclusion in the transport stream is done via an DSM-CC object carousel, which is input to a
30th March 2006
The MHP-Guide Version: 1.0
Page 52 of 215
multiplexer, where it is combined with other components in the broadcast stream to form the final transport stream to be transmitted, see Figure 4-3.
MHP applications need the addition of AIT tables in the SI that defines the broadcast interactive applications (specific to MHP applications) and the behavior of the application once downloaded in the terminal. The content and the source code of the application are broadcast using the DSM-CC object carousel that represents a specific kind of MPEG private sections.
Once the MHP application has been received by the terminal, the application manager (specific part of the MHP middleware) will control the lifecycle of the application according application signaling provided by broadcaster, or by user requests. It also handles requests from other applications. Only the middleware can directly control the application state; other parts of the system (other applications, user and broadcasters) can request application state change only via the application manager.
MHP Authoring & Production tools
PSI/SI
Network
MHP Terminal
MUX
AIT
Application
Application specific
backend server
Return channel
DSM-CCObject
carousel
PSI/SI tables
Program Content Playout
(Audio/Video/subtitle)
Network equipment
Figure 4-3 MHP applications in broadcast chain
The MHP applications can be transmitted by an external provider to broadcaster; also the application can be signed to avoid non-signed applications to access critical resource of the terminal. The next chapter will present all the end-to-end broadcast chain elements.
30th March 2006
The MHP-Guide Version: 1.0
Page 53 of 215
5 MHP end-to-end architecture NOVICE LEVEL
5.1 Introduction This chapter presents the typical architecture and infrastructure of the MHP end-to-end chain. It also list the actors of the MHP end-to-end value chain and their roles in this chain and presents guidelines/ recommendations for all actors.
5.2 MHP end-to-end reference model This section presents the MHP end-to-end system. It defines and describes the components that contribute to the architecture and infrastructure of the MHP end-to-end chain. The reference model is depicted in Figure 5-1; the components are elaborated in the following sections.
BroadcastContent
ProgramContent Playout
(1)
NetworkEquipment
(10)
Applicationspecific backend
server (13)
Program Clock
PSI/SI (6)
Network
Return Channel (12)
DSM-CC (7)
Object
Stream Events(8)
MHP Authoring &Production Tools
(2)
Billing System(14)
Billing Information
A/V Data
Subtitle/Teletext
(Signed) Application
MHP Terminal (11)
Smartcard(9)
ReturnChannel
(12)
MassStorage
OSDGraphics
Rootcertificates
(5)
AIT
Download server(4)
New firmware
Newfirmwaredownload
CA System(9)
ContentManagementSystem (3)
Application data
Keys
MHP Specific Non MHP Specific
Figure 5-1: MHP E2E Reference Model
30th March 2006
The MHP-Guide Version: 1.0
Page 54 of 215
5.2.1 Program Content Playout Program Content Playout (1) is not specific to MHP systems.
Program Content Playout is a function needed in most broadcast networks regardless of MHP. Program content is sent from a content provider to the broadcast system; here it enters the Program Content Playout that feeds it to the Network Equipment (10). The actual implementation of this component is dependent on the format of the Program Content when it enters a particular system. Typically the Program Content Playout is implemented as video servers that store and play out content streams or as encoders that convert uncompressed source material into a DVB compliant transport stream.
The main issue in this context is that the component can extract the program clock reference from the Program Content and that the content playout can be synchronized to the rest of the broadcast system.
5.2.2 MHP Application Authoring & Production Tools Creation and broadcasting of an MHP application (2) can be divided in 2 steps:
Authoring/Developing of MHP application
Signing and creation of broadcast data
Systems deployed to realize these steps, could be linked to a Content Management System (CMS) that manages the content handled by MHP applications (cf. next section).
5.2.3 Content Management System (CMS) A CMS (3) is a system that separates the content from the framework (layout, design, logic). It is a system that supports the creation, management, publishing and distribution of combined information. A CMS provides the possibility to create or pre-process (improve) existing data.
Within the MHP E2E architecture, the CMS (3) would be responsible for content generation and content delivery.
The software that isembedded onto a piece of hardware in order to control that hardware device.
Firmware
5.2.4 Download server & firmware upgrade Download server (4) & firmware upgrade process are not specific to MHP systems.
A download server provides necessary software utilities to prepare a system software binary image file for any target digital broadcast receiving device.
Receiver manufacturers who want to upgrade firmware of their already deployed receivers provide software binary image files to the appropriate broadcaster or network operator who allocates specific bandwidth for this purpose. DVB System
Software Update
DVB-SSU
Each time a new firmware update is broadcasted, the MHP terminal is able to move in a special operational mode in order to receive and upgrade its firmware.
30th March 2006
The MHP-Guide Version: 1.0
Page 55 of 215
Broadcast format of a new firmware update depends on both MHP terminal manufacturers and broadcasters but generally the DVB-SSU specification is followed [MHP 1.0.2; MHP 1.0.3].
5.2.5 Public Key Infrastructure MHP PKI The DVB MHP PKI relies on the integrity of certificates that verify the identity of the entity that has signed an application’s file tree. The highest-level certificate, known as the “root certificate” is embedded into each MHP receiver by its manufacturer, and this is used to authenticate a certificate at the next level in the hierarchy. This authentication process is repeated through each level of the certificate hierarchy until a leaf (or end-entity) certificate is encountered and authenticated. Thus users can be sure that application has not been modified and is only using the intended resources.
A system that enables users of a public network to exchange data securely and privately through the use of a public and private cryptographic key pair that is obtained and shared through a trusted authority.
PKI
5.2.6 PSI/SI PSI/SI (6) are not specific to MHP systems, but an additional table (AIT) is defined for MHP systems.
Video, audio and other data are all interleaved (multiplexed) when transmitted on a single Transport Stream (TS). Within the DVB standards of distributions these separate sources of data are identified with a unique packet identifier (PID). In order to navigate between all PIDs received by a client, the PSI/SI set of tables is used as a table of contents. Further, the tables provide descriptions of the content available. Because of the broadcast nature of the TS, tables have pre-defined minimum repetition intervals during broadcast to ensure a maximum access time.
A multiplex of several program streams that are carried in packets.
Transport Stream
Program Specific Information (PSI) is defined as part of the MPEG-2 standard. PSI defines four different tables, including Private tables. The remaining three table definitions are:
Program Allocation Table (PAT), which can be considered the root of a hierarchical structure of television programs;
Program Map Table (PMT), defines the individual components of a single program and
Conditional Access Table (CAT), indicating conditional access (CA) properties for any CA system utilized by programs within this TS.
The PAT and CAT table have fixed positions within the TS, while all PMTs are referenced in the PAT.
Service Information (SI) is an addition to the PSI specification. Defined by the DVB, it is also referred to as DVB-SI. It defines a series of mandatory and optional tables, providing both extra information about the data in the TS and information relating to external data and properties of the TS. The mandatory tables are
Network Information Table (NIT), containing physical properties of this and possibly other TS
Service Description Table (SDT), giving extra information on DVB-services, comparable to MPEG-2 programs
Event Information Table (EIT), distributing event information for DVB-services, comparable to program information for television channels. Updates of the EIT should be synchronized to the actual content
30th March 2006
The MHP-Guide Version: 1.0
Page 56 of 215
being played out in the program content playout (1) component, but in many operational systems this may not be the case at all times.
Time and Date Table (TDT), broadcasting time to the MHP Terminal
The optional tables are
Bouquet Association Table (BAT), provides logical grouping of services across TS;
Running Status Table (RST), sent only once to update the client of a status change;
Time Offset Table (TOT) and
Stuffing Tables (ST).
There are optional variations of all the mandatory tables. All tables except ST are anchored at fixed positions in the TS and can be accessed without parsing other tables first.
Part of the DVB-MHP specification is the Application Information Table (AIT). Although not part of the PSI/SI set of tables, the table is referenced from one or more PMTs. The AIT contains information about the available applications within a given service.
5.2.7 DSM-CC MHP applications, data and events are broadcasted using a DSM-CC playout system (7). The application and data are sent on an object carousel, while events are sent as stream events.
A format for transmission of data and control information in an MPEG-2 private section.
DSM-CC (Digital Storage Media Command and Control) 5.2.7.1 DSM-CC Files and Directories 22
DSM-CC offers, among other things, a mechanism to broadcast objects (like files and directories) in a carousel-like fashion.
A DSM-CC object carousel consists of three layers. At the top layer (called the object carousel layer), the DSM-CC User-to-User objects (like files and directories) are visible. These objects are transported in so-called modules. These modules represent the middle layer and this layer is called the data carousel layer. At this layer, the modules are just a container for data. The User-to-User objects are not interpreted here; this is done at the top layer. The modules are broadcast as a sequence of DownloadDataBlocks, which are MPEG-2 private sections with added semantics. These DownloadDataBlocks form the lowest layer.
DAVIC has specified how to refer to DSM-CC UU objects using java.io: it is the same way MHEG refers to those objects. The MHP specification has included this part of DAVIC and thus also uses java.io to access files and directories in a DSM-CC object carousel.
5.2.7.2 DSM-CC Stream Events Interactive applications sometimes require synchronization with TV programs. A quiz show is a good example. During this show, the
22 This section is a slightly adapted copy of chapter 12 from: Report on ongoing standardization efforts,
Deliverable #15, SMASH, by Ivar Miljeteig and Ronald M. Tol. http://www.extra.research.philips.com/euprojects/smash/deliver/del15/del15.pdf
30th March 2006
The MHP-Guide Version: 1.0
Page 57 of 215
quizmaster asks a lot of questions. Certainly, the interactive application has to be synchronized with the running program, to ensure that the display and the duration of the question is the same as for the live viewer. This requires an MHP trigger at the precise time to make the applications react.
Stream Events (SE) (8) are markers embedded in the Transport stream (TS) as private section. The TS must also contain an object carousel (OC) which contains at least one stream event object. This object identifies the matching event.
Within a stream event information (text, digits) can be transmitted. It provides for a real time data transmission.
There are two types of Stream Events (SE). Those are:
“Do it now” event – the event is triggered immediately (as soon as possible) without time preferences
“Scheduled events” – is depending on a time reference (NPT), when the time is reached the event is triggered. The NPT is a frame accurate media time defined by DSM-CC and reconstructed from PCR information present in the MPEG-2 stream.
Scheduled events offer more precision at the cost of increased complexity. The link between Program Content Playout (1) and DSM-CC (7) is only needed if scheduled events (8) are implemented.
In MHP KDB Project, this topic is investigated by the Signal Focus group.
5.2.8 Conditional Access System The Conditional Access System (9) is not specific to MHP systems.
CAS
DVBscrambler
CWgenerator
SAS
EMMgenerator
SMS
ECMgenerator
EMMinjector
Figure 5-2: Detailed view of Conditional Access System
The viewer pays a small fee to the television service provider in order to watch particular movies listed on the on-screen television menu. Similar to pay-per-view.
VOD (Video On Demand) It is an optional part. MHP broadcast may be clear and free-to-air.
A Conditional Access System (CAS) is used to control the access to program content on most platforms including MHP. The CA systems are proprietary, but the basic components are the same. A Control Word (CW) generator generates a CW, which is used to scramble the program content. The CW is also used to generate an Entitlement Control Message (ECM) in an ECM generator, which is located in the Subscriber Management System (SMS) server. The ECM is related to the program content and holds the access criteria. The ECM is used for recovering the CW in the MHP Terminal. On request from the SMS the Entitlement Management Message (EMM) generator in the Subscriber Authorization System (SAS) server
30th March 2006
The MHP-Guide Version: 1.0
Page 58 of 215
generates an EMM. The EMM holds information about the access status/entitlements of the user. The EMM is usually broadcasted in the transport stream, but could also be sent to the MHP Terminal over the return channel for instance when buying VOD movies. When the EMM is sent over the return channel an (MHP) application have to feed the EMM to the CA subsystem (Smart Card) in the MHP Terminal.
5.2.9 Network Equipment The network equipment (10) is not specific to MHP systems.
The network equipment consists of the multiplexers and network adapters needed for the particular network type that is used (terrestrial, cable and satellite). In a real system some of the functions described in the preceding sections may actually be performed in this box, e.g. some of the PSI/SI (6) is often generated by the multiplexer.
From a high-level perspective this component should be irrelevant when implementing MHP applications.
5.2.10 MHP terminal The MHP terminal (11) (e.g. a set top box) is the actual device that executes the MHP applications. It is the MHP terminal that presents the applications to the user, and it is through the MHP terminal that the user interacts with the system.
The MHP terminal can interact with third party devices, usually smartcards (11.1), through a common interface slot. The MHP terminal can also use what is commonly referred to as the return channel (11.2) to interact with external systems.
Mass storage devices (11.3) such as hard drives and DVD writers will most likely be more and more common. This storage can be utilized to store both content and applications.
The on-screen graphic display (11.4) is maybe the most basic component of a MHP terminal. The OSD graphic is the part of the MHP terminal that generates the visual representation of an application. The OSD graphic is either placed on top of the video, it may be blended with the video creating a transparent look or it may cover the entire screen. Most applications will use the OSD.
Refers collectively to all types of digital subscriber lines, the two main categories being ADSL and SDSL. Two other types of xDSL technologies are High-data-rate DSL (HDSL) and Very high DSL (VDSL).
xDSL
5.2.11 Return Channel An important component in the E2E architecture is the return channel (12). It adds the real interactivity to the whole system. The return channel can be classified with regard to the available technologies and with regard to the way how applications use the return channel.
An MHP application typically uses a return channel for having a bi-directional IP link between the MHP receiver and application servers. These servers are application specific and can have an interface to the billing system (14), which is operator specific.
DVB return channel by satellite.
DVB-RCS
With a PSTN modem it is also possible to make drop calls. This can be used by very basic applications, like voting, where only one-way interactivity is needed. In that situation, the MHP receiver just calls a number. The semantics of the user’s response is bind on the dialed phone
30th March 2006
The MHP-Guide Version: 1.0
Page 59 of 215
number itself. On the server side in order to collect users’ responses, it is sufficient to answer the phone call and immediately after drop it without setting up an IP connection.
From technical point of view the return channels can be divided in wired interaction channels and mobile interaction channels. For each category, there are connections that are temporary and connections that are “always on”.
Adaptation of DOCSIS to European cable networks. DOCSIS is a standard for delivering data over cable TV systems, typically for subscriber Internet access services.
Euro-DOCSIS Currently, most MHP terminals with a return channel use a built-in PSTN modem. An advantage of this return channel type is that PSTN is widely available. Some disadvantages are that a time-consuming connection set up phase is needed; the phone line is busy; in most European countries one has to pay per time unit so connection time should be kept as small as possible. More advanced wired interaction channels use broadband return channels standards as Euro-DOCSIS, xDSL or FTTH, which are always on. The special modem needed for these broadband channels can be installed in the receiver or the receiver can be connected with a home gateway by Ethernet (wired or wireless (WiFi)) or by USB.
The installation of Optical fiber from a telephone switch directly into the subscriber’s home.
FTTH (Fiber-To-The-Home): Mobile interaction channels are less common at the moment. The main
technologies in this area are the GSM modem, which is in use comparable with a PSTN modem and a GPRS connection, which is in use comparable with ADSL and 3G technology (UMTS).
Another option is using the satellite as return channel. A common standard here is DVB-RCS.
5.2.12 Application specific backend servers The application specific backend servers (13) are probably the least standardized area of the E2E architecture. This follows naturally from the fact that they are application specific. This also makes it more complicated to give a general description of what they are since they are application dependent.
Some applications need to access or store information in a central repository; this storage may be implemented as an application specific backend server (13). The MHP terminal (11) communicates with the backend servers using the return channel (12). The backend server may respond either through the return channel or through the broadcast stream.
As the backend server has much more resources than the MHP terminal it is often a good design choice to put as much as possible of the application logic into the backend server. The backend server may access other systems to perform the requested operations on behalf of the MHP terminal.
5.3 Actors of the MHP end-to-end system and their roles
This section presents the main roles that actors of the end-to-end chain can play and it highlights their scope and concerns. Table 5-1: Elucidation of actors in the MHP end-to-end reference model
Table 5-1 gives an overview of how the actors relate to the various components in the chain as presented in section 5.2. The identifiers in the table refer to Figure 5-1.
30th March 2006
The MHP-Guide Version: 1.0
Page 60 of 215
Identifier End-to-end system component
Main actors involved
1 Program Content Playout Service provider Broadcaster
2 MHP Application Authoring & Production Tools
Application developer Authoring tool vendor
3 Content Management System
Application developer Service provider
4 Download Server Broadcaster MHP terminal vendor
5 Public Key Infrastructure MHP PKI
Application developer Broadcaster MHP terminal vendor DVB Services SARL
6 SI/PSI Service provider Broadcaster
7 DSM-CC Broadcaster MHP Playout vendor
8 Stream Events Broadcaster Service provider
Application developer
9 Conditional Access System (CAS)
CAS provider Broadcaster MHP terminal vendor
10 Network Equipment Broadcaster Network operator
11 MHP Terminal MHP terminal vendor End-User
12 Return Channel ISP Backend operator MHP terminal vendor
13 Application Specific Backend Server
Application developer Broadcaster Backend operator
14 Billing System Application developer Broadcaster Backend operator
Table 5-1: Elucidation of actors in the MHP end-to-end reference model
30th March 2006
The MHP-Guide Version: 1.0
Page 61 of 215
It shall be noted that, in the broadcasting environment, many actors play more than one role in the end-to-end system. The actors are addressed in more detail in the following sections.
5.3.1 MHP authoring tool vendor The MHP authoring tool vendor provides tools aimed at application developers to ease the creation and development of MHP interactive TV applications. Some tools allow analyzing and testing applications; some also enable to sign applications.
5.3.2 MHP application developer MHP application developers are the creators and providers of the code of MHP interactive TV applications. The application developers may use MHP authoring tools or may develop directly in java code, with standard java development tools.
The MHP Knowledge Project provides a number of open source code samples that the MHP application developers can re-use.
It is interesting to see that anybody could write MHP applications because MHP is a standard and its APIs are public.
5.3.3 MHP service provider It is currently a bit tricky to define the exact role of an MHP service provider in the iTV production chain. There is no accurate definition analogue to ISPs in the Internet world mostly due to the fact that MHP services are not as established as web services are. At the moment broadcasters are often also the service providers.
The most appropriate description probably is that MHP service providers are delivering a service to the iTV user. They might do the MHP programming and maintain the interactive services, they might host a back-end system, they may have a play-out system and they have often a billing system.
As stated before it is difficult to draw the line between application developers on the one side and to the broadcasters on the other side.
5.3.4 Broadcaster To define the role of the broadcaster in the end-to-end chain is not an easy task, mainly because the term is commonly used for entities that cover many different roles in the chain. Some, for instance, are at the same time content provider, application developer, service provider and actual broadcasters.
Though the word is often used metonymically for all these roles, in this chapter it will stand for those actors responsible for the act of transmitting media, including the management and maintenance of the DSMCC object carousel and multiplexing.
Most MHP based services in Europe are provided by Public Service Broadcasters.
30th March 2006
The MHP-Guide Version: 1.0
Page 62 of 215
For more detailed information on the European market, cf. MHP-KDB deliverable D1 “Analysis of the Current Situation” under http://www.mhpkdb.org/publ/mhp-kdb_d1-ver-2.pdf.
5.3.5 Network operator The network operator may have the role of a pure infrastructure operator starting with multiplexers, adding access rights in a CA-system, modulating the TS and sending the RF signal on air either in a DTT network or on satellite. A cable operator will start with a headend for remultiplexing of the received programs and then distribute to their customers.
In some cases the network operator also will offer playout of applications using a multi-user playout platform, where the broadcasters, T-commerce actors, information and betting companies may upload their applications.
5.3.6 MHP playout vendor A playout vendor will support the E2E system with Application server, PSI/SI generator, DSM-CC Object carousel and it may include Authoring and Production tools.
5.3.7 CAS provider The CAS providers are actors of the iTV broadcasting end-to-end chain not specific to MHP. They provide the Conditional Access System that is used by the service providers and broadcasters to securely deploy pay-TV services and protect the TV content with secure technologies, most often by involving smart cards. A company that sells
Internet services to the public.
NAT (Network Address Translation)An Internet standard that enables a local-area network (LAN) to use one set of IP-addresses for internal traffic and a second set of addresses for external traffic.
ISP (Internet Service Provider)
See section 8.7 for a description of the CAS.
5.3.8 ISP In the current system, the role of the Internet Service Provider (ISP) is limited to providing the IP-connectivity between the MHP-terminal and the IP-network. If applications use the return channel, the ISP manages and controls this return channel. Multiple models exist for return channel connectivity (bridging, PPPoX, etc.). For some systems, the MHP-terminal will need to implement the matching protocol to establish this IP-connectivity.
The use of Network Address Translation (NAT) and firewalls might also pose problems when using the return channel. NATs and firewalls are not necessarily under control of the ISP, as also the customer uses these types of devices. It is recommended to write MHP-applications in such a way that they are NAT and firewall traversal friendly.
In alternative architectures, the broadcast channel is also transported over this IP-network. This means that also the MHP-application itself is transported over this IP network. This introduces new problems as the ISP is now involved in the broadcasting side as well. Tight security mechanisms need to be put in place to control access to the MHP-terminals.
30th March 2006
The MHP-Guide Version: 1.0
Page 63 of 215
5.3.9 MHP Backend operator The MHP Backend operator is involved in different aspects of the E2E system. The backend operator needs to connect to the IP-network, as this is the point where information originating from the MHP-receiver is received back by the operator. As this is an interface towards the public IP-network, care must be taken for the security and scalability of this interface and servers. Especially for applications in which financial gains or confidential data is exchanged, this interface and the servers are a very critical component of the system.
The exact functionality of the backend server depends on the applications. It can be assumed that there will be one backend server (or server functionality) for each (interactive) application in the network. Depending on the functionality the backend server needs to interface to the content management system to dynamically update content on the broadcast system.
As a third role, the backend server needs to interface to the billing system. Typically this is a proprietary interface. The exact functionality depends on the applications and the business model behind the application. E.g. for betting games, the backend server needs to make sure the payment information is correctly transferred to the billing system. Note that it might also be necessary to have information flowing from the billing system to the backend server. In the case of betting, it will be the billing system that verifies the payment information.
5.3.10 MHP terminal vendor The MHP terminal vendors are the providers of MHP terminals (iDTV, STB and PC) compliant with DVB MHP specification and hence carrying the MHP logo, proof that the DVB MHP test suite has been successfully passed.
The MHP terminal vendors may use their own MHP software stack or may integrate software from external MHP stack providers.
In the iTV context, MHP terminal vendors are often referred to as manufacturers.
5.3.11 DVB Services SARL DVB Services Sàrl is a limited liability company governed by the Swiss Civil Code and by its Statutes established with the aim of providing certification authority and all other related services to broadcasters, manufacturers, and entities. The main associate of DVB Services Sàrl is the DVB Project. The registered office of DVB Services Sàrl is the registered office of the European Broadcasting Union in Geneva, Switzerland
The DVB Services SARL plays a key role in the security of MHP iTV applications.
See http://www.dvbservices.org/.
30th March 2006
The MHP-Guide Version: 1.0
Page 64 of 215
5.3.12 MHP Certification Authority The MHP Certification Authority provides a Public Key Infrastructure for MHP, called MHP PKI. The Infrastructure provides the backbone for authenticating applications and files that are broadcast to an MHP receiver. This authentication process is designed to ensure that application code has not been modified from that originally developed by its author, is permitted to execute on devices connected to the broadcast network, and that the application only accesses the set of restricted resources that it has been authorized to access.
5.3.13 End-user The end-user is the owner of an MHP terminal, installed in its home environment, usually the living room. It has to be taken into account that potential users of interactive TV do not necessarily have PC knowledge and the user interface is limited to the remote control buttons and the low resolution of the TV screen.
PSTN (Public Switched Telephone Network) The international telephone system based on copper wires carrying analog voice data.
Return channel can only be used if the MHP terminal is connected to a PSTN or Internet. As this has to be done by the end-user and is thus not guaranteed, every application has to ensure proper function in case the return channel is not available.
Among the main concerns of the end-user are the ease of use, loading time, reactivity, speed, graphics, video and audio performance of the interactive applications.
5.3.14 MHP SW stack provider The MHP SW stack provider is a software vendor who licenses an MHP stack implementation to an MHP terminal vendor.
30th March 2006
The MHP-Guide Version: 1.0
Page 65 of 215
6 Organization of the MHP knowledge The MHP-KDB project tackles one of the most pressing issues in the field of digital interactive television: the harmonized usage and implementation of DVB-MHP by establishing a single “point of call” for all MHP-related technical issues: the MHP Knowledge Database. In short the so called MHP-KDB contains the know-how and best practice solutions for all companies and organizations active in this field. EU co-funded IST
project (lifetime: December 2003 – March 2006) that established a public database for all relevant MHP issues and a virtual test centre for checking MHP applications.
www.mhpkdb.org
MHP-KDB (Multimedia Home Platform – Knowledge DataBase)
The prime focus of MHP-KDB is to improve the interoperability of MHP implementations and MHP applications.
The MHP-KDB project has identified more than one hundred issues to be published in the database that are regarded as being crucial for MHP application development. These issues deal with important topics all along the MHP end-to-end architecture (cf. chapter 5). These issues can be allocated to following categories:
1. Basic Architecture
2. Broadcast Protocols
3. Application Lifecycle
4. Application Signaling
5. Security
6. Graphics, Audio and Video
7. Text Presentation
8. Return Channel
9. Equipment
10. Usability
11. Other aspects
Beside some general Basic Architecture (Chapter 7) issues, this chapter handles scarce resources of MHP terminals and the two kinds of MHP applications, DVB-J and DVB-HTML.
The category Broadcast Protocols (Chapter 8) looks at DSM-CC stream events related issues, both, from the play-out side and the terminal side. It also addresses topics such as section filtering, SI and service selection.
The Application Lifecycle focus area (Chapter 9) deals with a range of aspects and issues that are essential for the optimum deployment of MHP applications.
The Application Signaling area (Chapter 10) takes a look at signaling and lifecycle control of broadcast applications with the AIT table.
The focus area on Security (Chapter 11) covers issues regarding certification, signing and MHP Security in general.
Displaying Graphics, Audio and Video (Chapter 12) comes along with several problems that are tackled in this category. The concept of layers and composition is explained. Additionally, Text Presentation issues such as using and generating fonts as well as the use of external fonts are addressed.
30th March 2006
The MHP-Guide Version: 1.0
Page 66 of 215
The focus area on Return Channel (Chapter 13) covers issues regarding the communication based on the return channel offered in the interactive broadcast and Internet access profiles,.
The Equipment focus (Chapter 14) mainly addresses aspects of authoring tools and play-out systems.
The Usability focus (Chapter 0) area deals with all aspects regarding man-machine-interaction in MHP. It gives an outlook what an MHP designer has to consider with regard to layout, navigation and the presentation of text and images.
Other aspects deal with any other issue that cannot be allocated to one of the before mentioned focus groups.
The following figure shows where in the end-to-end MHP architecture the categories can be located.
Figure 6-1: Mapping of the MHP-KDB Categories in the MHP End-to-End Reference Model
30th March 2006
The MHP-Guide Version: 1.0
Page 67 of 215
7 Basic Architecture
7.1 Introduction
Basic Architecture
MHP applications can be classified into two types:
DVB-J: DVB-J (DVB-Java) applications are written in Java using the MHP API.
DVB-HTML: applications which depend on an implemented conformant browser.
However, the latter variant is to date not used or deployed.
Applications have to be designed to meet the specific constraints of the terminal (and playout) architecture. Only a fixed subset of JAVA / HTML is available, many functions for advanced data processing and storage have been cut down to a minimum. Usually only one application at a time will be visible on the screen. It may have to share the user’s attention with the running TV program, but not with another application. Scarce resources play a vital role in application development, as in an MHP terminal virtually any resource is scarce, restricting access to one application at a time. The installation and start procedure for applications is designed to work fully automatically, without user interference. MHP applications must not crash.
This chapter will outline the basic principles and constraints of DVB-J, general issues about dealing with scarce resources and about migrating to higher versions of the MHP standard, which may result in changes to the DVB-J definition.
7.2 DVB-J
7.2.1 Introduction DVB-J (DVB-Java) applications are written in Java using the MHP API set and consist of a set of class files that are broadcast with a service. DVB-Java applications are known as "Xlets". This is a concept similar to applets for Web pages that have been introduced by Sun in the JavaTV specification. Like applets, the Xlet (cf. 9.2 Xlet Application) interface requires an external source (the application manager in the case of an MHP receiver) to start and stop an application.
7.2.2 DVB-J Constraints MHP 1.0.x is based on the PersonalJAE specification23. PersonalJAE is short for PersonalJava Application Environment Version and in the following section referred to as PersonalJava. PersonalJava is a Java software development platform for mobile and embedded systems. It has been superseded by the J2ME CDC and CLDC, but still exists in many products.
PersonalJava is closely equivalent to Java 1.1.8 regarding the libraries and features it contains. This means that application developers are not allowed
23 Part of ISBN: 1-892488-25-6. The OEM PersonalJava Application Environment
Version 1.2a specification - http://java.sun.com/products/specformhp
DVB-Java applications are known as "Xlets".
Xlet
NOVICE LEVEL
DVB-J (DVB-Java)DVB-J applications are written in Java using the MHP API set and consist of a set of class files that are broadcast with a service.
30th March 2006
The MHP-Guide Version: 1.0
Page 68 of 215
to use java classes and methods form later Java Software Development Kits (SDKs).
Modern development tools such as Eclipse (http://www.eclipse.org/) have features for method auto completion and real-time syntax check. These features use the code libraries to operate. So by specifying correct MHP class libraries and API documentation in such tools, developers are forced to use correct methods and objects.
The MHP Knowledge database provides APIs and stub libraries developers can use for this purpose. Further information can be found in Annex B.
DVB-J is an environment different from desktop PCs and this different environment causes deviations in the Java environment when compared to PersonalJava. One example: the MHP specification Version 1.0.324 chapter 11.2.1 states “Each DVB-J application instance is considered to logically run in its own virtual machine instance”. This fact has consequences for the usage of finalizers. Chapter 11 of the MHP specification Version 1.0.3 specified in details deviations from PersonalJava including classes not required and deviations in functionality and methods.
MHP 1.1.x continues to refer to PersonalJava and not the subsequent specification Connected Device Configuration (CDC).
The classes used for MHP must be delivered in the Java 1.1.x compatible format25. Compilers provided by SUN in subsequent Java SDKs are capable of outputting class files that are Java 1.1.x compatible. This is done by using the compiler parameters source and target. E.g.:
javac -source 1.2 -target 1.1 <source files>
It is important to remove the standard java API from projects to prevent that objects that are not part of the MHP Specification are referenced and later failing when executed in an MHP environment.
7.3 DVB-HTML DVB-HTML is not very popular now, partly because the specification for DVB-HTML was only completed with MHP 1.1 and partly because many broadcasters, terminal manufacturers and content developers find it too complex and difficult to implement. DVB-HTML applications are a set of HTML pages that are broadcast as part of a service. The spec is based around a modularized version of XHTML 1.1 and also includes CSS 2.0, DOM 2.0 and ECMAScript. Up to date there is no test suite available for DVB-HTML, so the DVB-HTML support in MHP terminals cannot be certified.
24 ETSI ES 201 812 V1.1.1 - http://pda.etsi.org/pda/home.asp?wki_id=NQi7pkU'e9@_22@@TK7My25 The Java VM Specification section 4.1 states that the version numbers encoded in the class files are defined by
Sun, and that 1.0.2 supports class file format versions 45.0 through 45.3 inclusive; 1.1.X can support class file formats of versions in the range 45.0 through 45.65535 inclusive; and 1.2 of the Java 2 platform can support class file formats of versions in the range 45.0 through 46.0 inclusive. There are several tools available for presenting information about java class files including version number. One example is Class editor http://sourceforge.net/projects/classeditor/
DVB-HTMLDVB-HTML applications are a set of HTML pages that are broadcast as part of a service. The specification is based around a modularized version of XHTML 1.1, and also includes CSS 2.0, DOM 2.0, and ECMAScript.
CDC (Connected Device Configuration) A Java profile for mobile Devices that aims towards J2SE compliance with moderate resource requirements. For low performance devices the Connected Limited Device Configuration (CLDC) is available as a subset of CDC.
30th March 2006
The MHP-Guide Version: 1.0
Page 69 of 215
7.4 Principle of scarce resources Generally, MHP terminals offer only limited resources for applications. Thus, these resources must be shared in a very efficient way between the terminal middleware and concurrent MHP applications. Accordingly, effective resource management is a crucial aspect for decoder developers and MHP application programmers who tackle this issue frequently in the MHP APIs.
7.4.1 Memory It is mainly to save costs why many MHP terminals tend to have rather little memory. The MHP standard does not directly mandate a minimum memory size, but names a number of short test procedures the terminal has to pass. From these procedures a minimum memory requirement of estimated 4 megabytes can be derived. Luckily most terminals on the market have more memory, still it can be considered as a scarce resource. Unlike other scarce resources the memory cannot be blocked by just one application, but the amount and size of concurrently running applications influences the overall box performance.
Managing Memory as a scarce resource There are three major rules for efficient memory use on MHP terminals:
Adhere to the Xlet application lifecycle model and send temporary inactive applications into the “paused” mode to free memory.
Avoid very large files such as large images and long audio files.
Mark applications as “service bound” and ensure that not too many applications are allowed to run concurrently on the same service.
In general, MHP terminals are not built for real multitasking. Only one application should be active and visible on the screen at any given time. Further applications, like a general portal application, may run in paused mode in the background to get restarted when the user decides to leave the current application. The paused mode was introduced to keep applications running in the background in a kind of hibernate mode with very little resource usage. When an application is sent to pause mode, all memory consuming objects, like images, should be destroyed, whereas they will be built up again when the application is restarted. This way, applications that are used frequently have to be loaded from the object carousel only once while the user is viewing the current service.
It may happen that there is not enough memory available to start further applications. In this case the MHP terminal may reject any try to do so. However the way the terminal reacts is implementation specific.
The valid applications for a service are listed the Application Information Table (AIT). It is important to make sure that these applications could run simultaneously on the minimum MHP terminal configuration that is going to be used to consume this service.
7.4.2 Persistent storage NOVICE LEVEL The MHP environment allows authorized applications to use an area of the local file system for persistent storage. Such signed applications that have
30th March 2006
The MHP-Guide Version: 1.0
Page 70 of 215
been granted file access permission are able to read, write and delete files on a persistent area of the device memory.
To signal a signed application the application id value must be in the range of 0x4000 to 0x7FFF. Otherwise, the permissions for file access cannot be granted. By default, signed applications have access to the same resources as unsigned applications. Signed applications can request additional permissions through the use of a signed "Permission Request File". The permission request file is an XML file conforming to the DTD described in section 12.6.2 Permission request file [MHP 1.0.3]. This file must reside in the same folder as the main class of your application, and is named with the following format: dvb.<application name>.perm where “application name” is the fully qualified class name of the initial class for the application. (e.g. “org.mhpkdb.app.MainClass”)
EXPERT LEVEL
More details about the values range for application_id can be found in section 10.5.1 Encoding [MHP 1.0.3].
Range of app_ID
Each element in the permission request file corresponds to a specific resource requested for the application. From an application standpoint, permissions are represented by subclasses of java.security.Permission. Each subclass represents a different resource that an application must gain permission to access. The permission class representing the persistent storage is java.io.FilePermission.
The file access request in the permission file would look like <file value=”true”></file>. Below is an example of requesting access to use the persistent storage. The permission file would contain the following contents:
<?xml version="1.0"?>
<!DOCTYPE permissionrequestfile PUBLIC "-//DVB//DTD Permission Request File
1.0//EN" "http://www.dvb.org/mhp/dtd/permissionrequestfile-1-0.dtd">
<permissionrequestfile orgid=0x00499602d3 appid="0x4002">
<file value=”true”>
</file>
</permissionrequestfile>
If permission is granted, the application is able to use the java.io package to interact with the local file system. Buffered in- and output has to be preferred during file access.
As long as there is no standardized signing procedure, MHP terminals may behave differently when an application tries to access the persistent storage. Tests in the laboratory show highest interoperability under following conditions:
Application id must be in the range of 0x4000 to 0x7FFF.
Access persistent storage without permission check.
30th March 2006
The MHP-Guide Version: 1.0
Page 71 of 215
The root of the persistent storage area can be retrieved from the dvb.persistent.root system property. Applications are constrained to this directory and its subdirectories. Trying to access its parent directory will result in a java.lang.SecurityException being thrown. Applications have read-only access to this directory.
The MHP implementation will automatically create the following subdirectories for each application under the persistent root directory:
<organization_id>
<organization_id>+<file.seperator>+<application_id>
The organization_id and application_id values are hexadecimal text encoding (without leading zeros) of the values specified in the AIT. These can be retrieved from the XletContext using the getXletProperty method with parameters of dvb.org.id and dvb.app.id respectively.
The persistent root directory is not the root of the file system on the STB, but the directory the STB reserved for persistent storage.
The file separator value can be retrieved from the system properties. According to section 11.3.1.1 [MHP 1.0.3] the following properties are required to be supported for java.lang.System.getProperty():
file.separator
path.separator
line.separator
dvb.persistent.root
StringBuffer sBuffer = new StringBuffer();
// Create a new file name (including complete path).
sBuffer.append(System.getProperty("dvb.persistent.root"));
sBuffer.append(System.getProperty("file.separator"));
sBuffer.append(xletContext.getXletProperty("dvb.org.id"));
sBuffer.append(System.getProperty("file.separator"));
sBuffer.append(xletContext.getXletProperty("dvb.app.id"));
sBuffer.append(System.getProperty("file.separator"));
sBuffer.append("testFile.txt");
// Creating a new file object.
java.io.File testFile = new java.io.File(sBuffer.toString());
30th March 2006
The MHP-Guide Version: 1.0
Page 72 of 215
The organization directory is owned by the platform and shall have organization read / write access and world read access. The application directory is owned by the application and has application read / write access, but no access for other applications unless explicitly granted by the owning application. Below is an example of referencing a file in the application directory. This example assumes that the application is signed and has been granted access to persistent storage.
Applications can specify attributes (expiration date, priority, and permissions) for a particular file using the org.dvb.io.persistent. FileAttributes class. These attributes are used to control access to a file and control the lifecycle of a file.
The following listing shows how to set permissions and how to check them. Here the file obtains the read and write permission. The permissions “read”, “write”, “delete” and “execute” for a file are the standard permissions given by the Java API. The parameter is always a comma-separated string containing no white spaces.
java.io.FilePermission testPermission =
new java.io.FilePermission(sBuffer.toString(), "read,write");
try{
java.security.AccessController.checkPermission(testPermission);
}catch(AccessControlException ace){
System.out.println("checkPermission throws: " + ace);
}
Although checkPermission() appeared with Java 1.2 the first time, it is already part of the MHP API. The file access itself works like described for Java 1.1.8.
The persistent storage is actually not persistent. Some rules are defined in the MHP specification when files in the persistent storage will be removed:
There is not enough free persistent storage available to satisfy the persistent storage needs of a running application.
The file stored in persistent storage expires.
The file is cleared (i.e. deleted) by the creating application or an application with appropriate permissions.
The file is cleared as a result of an explicit request by the end user.
The persistent storage used by MHP applications exceeds 75% of its overall size.
One last thing the application developer has to be aware of; The MHP specification defines the minimum size of the complete persistent storage with 4096 bytes. Attempts to store data above this size may fail.
30th March 2006
The MHP-Guide Version: 1.0
Page 73 of 215
7.4.3 Tuning Interface One terrestrial or cable channel or satellite transponder carries one MPEG2 transport stream. Each transport stream carries a couple of services. Tuning means adjusting the terminal’s network interface so that it can provide all information necessary to consume a certain service. If a target service to tune to is part of the same transport stream as the current service, tuning consists only in filtering different packets out of the stream. If a target service is part of another transport stream, tuning does include adjusting the network interface to a different frequency, which requires a certain effort of terminal resources.
Tuning should not be mixed up with service selection, because tuning does not include the update of the application information table (AIT).
The network interface is a scarce resource as obviously only one application at a time can be allowed to perform tuning operations. Furthermore tuning to another transport stream may cause the disconnection of an application’s object carousel. This is why all applications possibly running in parallel on the same service with an application that performs tuning operations should be built robust enough to withstand tuning. The terminal middleware has always priority on accessing the network interface. Applications that rely on the tuning interface should be able to deal with user events such as channel switching by remote control.
Issue #106 in the MHP-KDB provides an example on how to perform tuning in contrast to service selection.
Network Interface Controller The network interface controller represents a controller that is used for tuning a network interface. Applications may create a NetworkInterfaceController object and use it to attempt to reserve a network interface for exclusive access. The network interface controller acts as a resource proxy for this resource.
Objects of the public class NetworkInterface represent physical network interfaces that can be used for receiving broadcast transport streams. Normally only one network interface is available in an MHP terminal. Twin-receivers and other advanced terminals may offer more than one network interface, e.g. to record one programme while displaying another one.
Classes and important methods
NetworkInterfaceManager The network interface manager keeps track of broadcast network interfaces that are connected to the receiver. There is only one instance of the network interface manager in a receiver and here the tuner is selected.
static NetworkInterfaceManager getInstance(): The method returns the singleton instance of the NetworkInterfaceManager.
NetworkInterface[] getNetworkInterfaces(): This returns an array of available network interfaces.
30th March 2006
The MHP-Guide Version: 1.0
Page 74 of 215
NetworkInterface This class offers information about a particular network interface.
int getDeliverySystemType(): The method returns an integer value that identifies the type of network that this interface accesses.
TransportStream getCurrentTransportStream(): This returns the transport stream to which the network interface is currently tuned. Returns null if the network interface is not currently tuned to a transport stream, e.g. because it is performing a tune action.
Locator getLocator(): Returns the locator of the transport stream to which the network interface is currently connected. Returns null if the network interface is not currently tuned to a transport stream.
boolean isLocal(): This method was intended to allow a unified interface to tuners both in the receiver and in other devices, i.e. whether the respective network interface is built into the terminal or connected externally.
boolean isReserved(): This method tells the applications whether the network interface has been reserved by an application for tuning.
NetworkInterfaceController This class provides a mechanism for applications to actually control a network interface and to use it to tune to a new transport stream. Once a NetworkInterfaceController has been successfully bound to a network interface, an application can actually start tuning.
reserve(NetworkInterface ni, Object requestData): Tries to reserve the given network interface for exclusive access by the calling instance of NetworkInterfaceController.
release(): After the tuning operation the network interface has to be released again by calling this method.
tune(Locator locator): Tunes to the given locator.
7.4.4 Return Channel The return channel provides the IP-connectivity for the MHP terminal. To use the return channel, the interactive broadcast and internet access profile need to be supported by the terminal. The quality (speed) of the return channel depends on the type of return channel offered by the terminal and potentially also on the type of subscription for internet access a user has (e.g. with xDSL or cable bandwidth up to 40 MBit/s can be offered, but this is typically not the speed offered to the residential user).
xDSL or cable modems provide an always-on connection and as such there are no specific needs to first establish the IP-connectivity, as they are not considered as a scarce resource. These types of modems are not likely to be integrated into the MHP terminal, which will rather have an Ethernet interface for connection with a home network or external modem.
When using PSTN (dial-up) connectivity, the MHP-receiver first has to establish the telephony connection (dial-in) and then the IP-path using PPP-protocols, as it has to be considered as a scarce resource. For establishing this IP-connectivity the application has to provide the telephony number used for the dial-in process. Also, only one connection can be active at a time. A PSTN return channel is a scarce resource that an application should not use unless it is really necessary. As using the dial-up
30th March 2006
The MHP-Guide Version: 1.0
Page 75 of 215
modem also involves extra costs, only signed applications are allowed to access the dial-up modem. An MHP-receiver will also ask for a users’ permission ahead of the attempt to establish this dial-up connection; the allowed numbers might also be stored in a “white list” so the user is not always being interrupted when a dial-up connection needs to be made.
In general, return-channel interfaces are described in the class RCInterface; for connection-based (e.g. PSTN) the class ConnectionRCInterface defines the different procedures for getting access and releasing the return channel.
Access to the return channel is managed by the class RCInterfaceManager.
7.5 Migration This sub-section provides an overview of all MHP-migration aspects. Part one covers migration from legacy applications to MHP applications. Part two deals with migrating to an updated version of MHP (e.g. from MHP 1.0.2 to MHP 1.0.3).
7.5.1 Migration from previous legacy middleware to MHP
Plug-inA "plug-in" is a set of functionality that can be added to a generic platform in order to provide interpretation of application and content formats not specified by MHP specification to be included in MHP terminals.
The main goal of DVB-MHP is to reach a horizontal market by providing an open standard. For the moment, however, many interactive applications deployed around the world only work on proprietary systems and are based on legacy middleware. Migration to the MHP platform is a crucial issue for all broadcasters changing from proprietary middleware solutions to MHP. Importantly, migration costs should be kept as low as possible by making use of existing proved solutions. There are two basic options for migrating existing applications:
Re-authoring all existing applications;
Using a plug-in to enable older applications to run on the new MHP middleware. The figure below illustrates the position of the two types of plug-ins defined by the MHP architecture.
Ressources
System Software Plug-in BApplicationManager
MHP Applications
MHP API
Plug-in A
Legacy app.Type A
Legacy app.Type B
Figure 7-1 Plug-in implementation options
30th March 2006
The MHP-Guide Version: 1.0
Page 76 of 215
They are two possible types of plug-in implementations:
In native code provided for MHP implementation (Plug-in B).
As an MHP application (Plug-in A).
The plug-in solutions require to have implemented the respective plug-in for the legacy middleware. This is efficient if we have a lot of legacy applications to migrate. On the other hand, the plug-ins demand additional implementation effort and, for type A, also higher processing power in the decoders.
Re-authoring, on the other hand, can require more effort if we have a lot of applications to migrate but it results in truly portable applications which are better designed. If the proprietary decoder populations have to be supported as well for a certain time, re-authoring also requires simulcasting of applications in both API versions.
Alternative migration approaches are described in more detail in the document “Guidelines on Migration” [MHPKDB-1MHPKDB] which can be found on the MHP-KDB website.
7.5.2 Migration from older to more recent MHP versions In order to correct bugs or bad behavior and to enrich the standard with novelties, new versions are introduced putting a focus on backward compatibility.
Sometimes, however, backward compatibility is not granted, and, as a result, an MHP application compliant with an earlier version of the standard (e.g. MHP 1.0.2) will have to be reworked to be compliant with the subsequent versions of MHP (such as MHP 1.0.3 errata 2).
Generally they are five types of changes, each with a different impact:
Editorial: A change concerning the formal aspect of the specification but not the definition (typo in description, specific formatting...). Such a modification should not have an impact on the backward compatibility;
Clarification: A change that clarifies, gives more precision, rephrases a specific specification item in order to improve reader understanding. Such modification should not raise backward compatibly issues but rather interoperability issues;
System: A change concerning the signaling part, system behavior. Such modification may raise interoperability issues if not hidden by playout system or MHP terminal;
API Behavior: A change in the behavior of the MHP API. Such modification will raise backward compatibility issues;
API Definition: A change concerning the java definition of MHP API. Such modification will also raise backward compatibility issues.
Some modifications affect the backward compatibility so that applications based on an older version cannot run on a more recent version.
In order to help application developers to migrate from an older MHP version to a new one, we have analyzed the evolution from MHP 1.0.2 to
30th March 2006
The MHP-Guide Version: 1.0
Page 77 of 215
MHP 1.0.3 specifications. The graphs below represent overviews of the modifications that have been added in the new version. Also DVB-MHP has been working on some modifications in version 1.0.3 that are defined in errata (the last is number 3).
Change type
21%
5%
22%
44%
8%
Editorial API Behaviour API change Clarification System
Figure 7-1 Different type of changes
Most of the changes between the two versions are due to clarifications.
Modification type
55%
42%
3%
ChangeAddDelete
Figure 7-2 Different type of modifications
Among all modifications the most important type are changes and additions, very little from previous version was deleted.
30th March 2006
The MHP-Guide Version: 1.0
Page 78 of 215
Changes per domain
16%
9%
5%
18%
17%
11%
1%
2%
0%9%
8%4%
Application DVB-J APIMediaDSMCC-IOGraphicsSecurityEventHaviMpegSIReturn ChannelOther
Figure 7-3 Changes per domain
As we see in this graph a lot of changes concern several domains of MHP. The most concerned domains are DSMCC-IO, Graphics and Application.
Backward compatibilty
28
12
0
ChangeAddDelete
Figure 7-4 Number of backward compatibility issues
Lots of problems of backward compatibility are due to changes and to additions from the previous version to the new one.
For more details concerning migration issues see Annex D – Migration.
30th March 2006
The MHP-Guide Version: 1.0
Page 79 of 215
8 Broadcast Protocols NOVICE LEVEL
Broadcast Protocols
8.1 Introduction There are several different protocols that can be used for broadcasting data and applications. This chapter will go through these, from the most basic overview through to detailed technical descriptions on some subjects. In most cases you will find the information you need here, but in some cases you may be directed to external sources to perform further studies.
8.2 Transport Stream Elements A good understanding of the transport stream concept is a great advantage when developing or broadcasting MHP applications. This section will give an introduction to the relevant standards and building blocks that form a transport stream.
8.2.1 A note on naming Channel = Service = Program
Ordinary people, DVB and ISO have different names for the same concept. Most people refer to a service provided by a broadcaster as a channel. That is a service that usually consists of a sequence of audio/visual content. The service can be accompanied by additional components such as applications and data.
In DVB a “channel” is named a “service” while the “channel” was named “program” by ISO.
Program = Event
To confuse things further, DVB has also renamed the concept that ordinary people refer to as programs. In DVB terms a service consists of a sequence of events. An event corresponds to what usually is referred to as a program; i.e. a piece of audio-visual content that has a defined start and duration. Typically the 9 o’clock news could be an example of an event.
The following text will interchangeably use program or service when referring to “channel”.
8.2.2 MPEG-2 Transport Stream MPEG-2 is a standard issued by the International Organization for Standardization (ISO). The systems [mpeg2systems] part is the most interesting part from an MHP applications viewpoint. This document describes how audio, video and data from different services are combined into a transport stream.
A transport stream is a sequential stream of 188 bytes packets.
Conceptually you could also say that a transport stream is a collection of one or more services.
Each service is a collection of one or more elementary streams.
An elementary stream is a sequence of packets containing video, audio or some other type of data.
30th March 2006
The MHP-Guide Version: 1.0
Page 80 of 215
Service 1
Service 2
Application 1
Service n
Video 1
Audio 1
Audio 2
Data 1
ECM
Transport Stream 1
Elementary Streams
Figure 8-1 Transport Stream
The MPEG-2 packets of the elementary streams consist of 4 bytes header and 184 bytes payload. Before broadcasting, the different elementary streams are merged into a single stream of packets in a process called multiplexing. The unit that performs this process is called a multiplexer. This unit may very well be an integrated part of other devices, which is in fact very often the case for devices that do the compression of the service content, i.e. encoders.
Video Compression
Audio Compression
Program Clock
Video
Audio
Mux
Figure 8-2 Example building blocks of an MPEG-2 encoder
Typically, a device called MPEG-2 encoder will have a video input and a number of audio inputs. The video and audio is uncompressed before it is fed to the encoder. The encoder will then compress the video and audio
30th March 2006
The MHP-Guide Version: 1.0
Page 81 of 215
and multiplex the streams into a transport stream that contains all the elementary streams of a service.
The use made of the “Program Clock” is explained in section 8.2.2.4.
The resulting transport stream will contain packets of all the underlying elementary streams.
8.2.2.1 MPEG-2 Packets Each 188 bytes MPEG-2 packet belongs to exactly one elementary stream. The elementary stream is identified by a packet identifier (PID). The PID is a 13 bits number located in the MPEG-2 packet header (the first 4 bytes of the packet). The PID can in principle have any value between 0 and 8191 but some of the PID values are reserved for special uses. Values below 32 are reserved for metadata (see next section and chapter 10 for details) and 8191 is reserved for a special type of packets called null packets.
Null packets are commonly used to pad a transport stream with empty packets to keep a constant bit rate.
payload header
188 bytes
sync byte
transport error
indicator
payload unit start indicator
transportpriority
PID transport scrambling
control
adaptation field
control
continuitycounter
8 1 1 1 13 2 2 4
payload headerpayloadheader
Figure 8-3 MPEG-2 Packet Header
The figure above shows the fields of the MPEG-2 packet. The first byte is a sync byte that is used to identify the beginning of a packet in a continuous stream of bytes. It always has the value of 0x47.
The transport scrambling control field indicates if the packet is scrambled (see section on scrambling for more information on scrambling). The last field is a counter to field that is primarily used to detect packet loss. The continuity counter is incremented for each packet sent for each elementary stream. This way it is very easy to detect that a packet is missing at the receiver if the continuity counter skips a number. See the MPEG-2 Systems specification for a detailed explanation of the remaining fields.
8.2.2.2 MPEG-2 packet payload MPEG-2 packets can be divided into two main types: Packetized Elementary Stream packets (PES Packets) and Data packets (usually MPEG2 sections). PES packets are packets containing compressed audio or video data. They include timing information. The data packets are packets containing data that is not critical in timing, often metadata that provides information on what information can be found in the transport stream.
PSI, SI, EMM and ECM data all use a table format defined in the MPEG-2 systems specification as MPEG2 sections.
30th March 2006
The MHP-Guide Version: 1.0
Page 82 of 215
8.2.2.3 Program Specific Information (PSI) In addition to the audio and video packet that we discussed in the previous section, there will also be packets that contain metadata about the elementary streams. MPEG-2 defines a set of tables that provides information about what is sent on the different streams. This meta-data is called PSI/SI (chapter 10 gives more details about PSI/SI).
8.2.2.4 Synchronization The encoder will puts time codes, called Presentation Time Stamp (PTS) in all the audio and video packets that will be used by the decoder to correctly synchronize the audio and video. The PTS is relative to the Program Clock Reference (PCR). The PCR is derived from a clock that is either internal to encoder or external, this depends on the make and model of the encoder, but in any case it is a clock that is used to enable the decoder to correctly present synchronized audio and video. The PCR is used as a reference for all program content of a given service; also MHP applications can be synchronized to the PCR. This is done using a mechanism called ‘normal play time’ (NPT), which in turn is synchronized to the PCR.
The PCR is sent in a separate elementary stream or as part of one the other elementary streams embedded in the packets. Again this depends on setup, make and model of the encoder.
8.2.3 DVB Transport Stream A DVB transport stream is an MPEG-2 transport stream that is constrained by some more rules in addition to the MPEG-2 specification. Most important in this setting is that the DVB has defined some more tables that are termed Service Information (SI). The SI tables extend and add to the information found in PSI. See chapter 10 for details.
8.2.4 MHP MHP makes use of the standard DVB transport stream protocols and DVB service specifications. There is a new table added to the services if they carry an MHP application. This is the Application Information Table (AIT). See chapter 10 for details. The application is then broadcasted using the DSM-CC format, which is described in detail in a following section of this chapter.
NOVICE LEVEL 8.3 DSM-CC DSM-CC is part of the MPEG-2 specification [mpeg2DSM-CC] and covers network session and resource management, configuring of clients, downloading to a client, video management, service interactive applications and service, data and user-to-user (U-U) object carousel for broadcast applications.
DSM-CC transport is based on MPEG2 sections as defined in the MPEG2 systems layer [mpeg2systems].
In MHP DSM-CC is used to broadcast MHP applications and data as well as stream events (covered in chapter 8.4). As broadcast systems are one-way, the client has no way of telling the broadcast system which data it wants. Thus the data is organized in carousels, i.e. one file is broadcasted after the other and then the first is broadcasted again and the second etc.
30th March 2006
The MHP-Guide Version: 1.0
Page 83 of 215
This means that the client may have to wait a full lap to access a specific file unless the file is repeated several times during one lap. The longest access time for a file is defined by the bandwidth of the carousel and the size of the data on the carousel.
MHP applications and data are broadcasted in object carousels. DSM-CC also supports data carousels that are the simplest form of carousel.
EXPERT LEVEL 8.3.1 DSM-CC Object Carousel26 DSC-CC object carousels extend the data carousel and add the concept of files, directories and streams providing functionality close to a standard file system. Object carousels are also based on the Object Request Broker (ORB) framework defined by CORBA. I.e. all objects in the object carousel are broadcasted as BIOP (Broadcast Inter-ORB Protocol) messages as defined by CORBA and these messages are contained within a DSM-CC data carousel.
The following message types can be carried in an object carousel:
DSM::File: representing files.
DSM::Directory: representing logic containers for a set of file messages/reference to files in a directory
DSM::Stream: reference to MPEG-2 stream; to a single program, or to one or more elementary streams.
DSM::ServiceGateway: identifies the root directory of the object carousel, thus there is only one present in every object carousel.
BIOP::StreamEvent: describes a set of synchronization points (stream events) in the stream.
Figure 8-4 Example of object carousel in DVB service
26 Part of this section is a slightly adapted copy of chapter 12 from: Report on ongoing standardization efforts,
Deliverable #15, SMASH, by Ivar Miljeteig and Ronald M. Tol.
http://www.extra.research.philips.com/euprojects/smash/deliver/del15/del15.pdf
30th March 2006
The MHP-Guide Version: 1.0
Page 84 of 215
A DSM-CC object carousel consists of three layers. At the top layer (called the object carousel layer), the DSM-CC User-to-User objects (like files and directories) are visible. These objects are transported in so-called modules. These modules represent the middle layer and this layer is called the data carousel layer. At this layer, the modules are just a container for data. The User-to-User objects are not interpreted here; this is done at the top layer. The modules are broadcasted as a sequence of DownloadDataBlocks, which are MPEG-2 private sections with added semantics. These DownloadDataBlocks form the lowest layer.
Figure 8-5: DSM-CC Object Carousel Layering
Each module cannot be larger than 64 Kbytes, but a single file cannot be divided into several modules. Thus files that are larger than 64 Kbytes27 have to be contained as the only file within one module.
DAVIC has specified how to refer to DSM-CC UU objects using java.io: it is the same as how MHEG refers to those objects. The MHP specification has included this part of DAVIC and thus also uses java.io to access files and directories in a DSM-CC object carousel (cf. Annex C - Presentation of the MHP APIs)
For more information on DSM-CC see [GuidelinesDataBroadcasting].
NOVICE LEVEL 8.3.2 Object carousel optimization When you write MHP applications you probably want the application to be perceived as fast and smooth as possible. This might be achieved by optimizing the object carousel.
There are two basic ways of optimizing the object carousel; either by organizing and grouping the files wisely in the modules or by repeating critical files several times in the object carousel. The first method is quite difficult and requires detailed knowledge about how the application is designed.
The latter is probably easier, but has its disadvantages as well. When you start to repeat files in the object carousel this will affect the size of the object carousel. When the size of the object carousel is increased, the access time of other files (those that aren’t repeated) increases, potentially 27 The broadcaster/developer should be aware that broadcasting too large files may cause the application to not
function correctly on all MHP terminals as they often have limited resources and may not be able to handle a file if it is too large.
30th March 2006
The MHP-Guide Version: 1.0
Page 85 of 215
slowing down other parts of the application. A bigger object carousel also increases the cost of deploying an application as the required bandwidth increases. This is a trade off that has to be taken into consideration when optimizing the object carousel.
NOVICE LEVEL 8.4 Synchronization For MHP applications it is often necessary to be synchronized with media content like audio or video. To enable MHP applications to run synchronized to the media content, the so-called stream events are used by MHP. A stream event is a small data-packet that will be sent by the broadcaster to the MHP terminal to hand it over to the MHP application. These stream events can contain a limited amount of application specific content, which can be used to provide additional information like the text of a question for a quiz show application.
Stream events are sent along the content to the MHP terminal and will be handed over to the Xlet by the middleware. The Xlet itself only needs to register a listener for a specific stream event and will be informed by the MHP terminal, if the according stream event was received. All necessary actions like filtering the transport stream as well as extracting and parsing the data will be done by the MHP terminal. If a stream event is available for the MHP application, then the middleware will create a StreamEvent object which it provides to the registered Xlet’s StreamEventListener object.
There are two kinds of stream events defined in MHP: Do-It-Now as well as scheduled stream events. While Do-It-Now stream events will be provided to the Xlet’s listener right after the MHP terminal receives the event, the scheduled stream events are delayed by the MHP terminal until the time of the event matches the normal play time of the service.
The difference of these two kinds of stream events has no impact to the MHP application. The subscription of a stream event is independent of the stream event type.
8.4.1 Do-It-Now stream events A Do-It-Now stream event can be used to provide a signal as fast as possible from the headend to the MHP application. If an MHP terminal receives a Do-It-Now stream event, then it will hand over the stream event and its payload immediately to the MHP application.
Do-It-Now stream events are single shot events which won’t be repeated if an MHP terminal missed it – therefore the MHP terminal has to make special efforts to ensure a high probability that they can be reliably received.
The benefit of Do-It-Now stream events is that they can be easily used to synchronize an MHP application with a live program. If something happens in the live program that needs to be signaled to the MHP application shortly, a Do-It-Now stream event can be created and sent to the MHP application. It is defined that such a stream event must be transmitted from the headend to the MHP application as fast as possible.
A problem of Do-It-Now stream events is that the runtime from headend to the MHP application isn’t known and therefore it isn’t reliable that it is constant. If problems introduced by this unknown delay and jitter should be avoided, then scheduled stream events will be the better choice.
30th March 2006
The MHP-Guide Version: 1.0
Page 86 of 215
Do-It-Now stream event must have an event identifier in the range 0x0001 to 0x3fff.
8.4.2 Scheduled stream events Scheduled stream events are created prior to the time the event is to occur and are handed over once or several times to the MHP terminal in a bunch. The MHP terminal takes these scheduled stream events and stores them until the normal playtime reaches the scheduled time of an event. If a scheduled event for the current normal playtime is found, this event will be provided to the MHP application’s registered StreamEventListener object.
The benefit of scheduled stream events is that they can be created and also be provided to the MHP terminal in a bunch. Especially the transmission of the scheduled stream events prior to their planned signaling to the MHP application can be used to avoid delays and jitter introduced by the broadcast chain.
Scheduled stream events can only be used for pre-recorded content, because the correct time of the media content must be known for creating the timestamps for the stream event scheduling. For live events the exact time of the planed events isn’t known and therefore the timestamp of the event can’t be given.
The early transmission of the scheduled stream event is problematic for MHP application which wants to provide the payload just in time. If, for example, an MHP application for a quiz show provides the information about the correct answer by a scheduled stream event, then it is possible to catch the payload of the stream event even before the question occurred in the game and extract the information about the correct answer. A player who can get access to the information has an advantage in answering the question correctly and can win the game more easy. To avoid such problems, Do-It-Now stream events should be used in such a case.
Scheduled stream event must have an event identifier in the range 0x8000 to 0xbfff.
8.4.3 Creating stream events EXPERT LEVEL A stream event must be signaled in the object carousel as well as a normal
playtime signal for scheduled stream events or the broadcast of StreamEventDescriptors for Do-It-Now stream events. It is not possible to provide a detailed “how to” for configuring the playout, because every playout equipment is different to use. The following steps are necessary on the headend side for broadcast stream events:
Configure the MHP playout software to contain a stream event object in the DSM-CC.
Add at least one event name and identifier to the stream event object in the DSM-CC. For Do-It-Now stream events the identifier must be in range 0x0001 to 0x3fff, for scheduled stream events the identifier must be in range 0x8000 to 0xbfff. An event identifier 0x0000 isn’t allowed.
Use the API of the MHP playout software to create a stream event with the previously added event name and/or identifier as well as the optional payload. If the stream events are of type Do-It-Now, it is necessary to
30th March 2006
The MHP-Guide Version: 1.0
Page 87 of 215
invoke the stream event creation on the API at the time the event should be received by the Xlet (please take into account the little delay, which the stream event needs from the headend to the MHP terminal).
For scheduled stream events also the normal play time must be provided.
In the Xlet a listener must subscribe to a defined stream event. This is done by creating a DSMCCStreamEvent object, which points to the stream event object contained in the DSM-CC. With the DSMCCStreamEvent all available event names/identifier can be retrieved as well as one or more listeners registered for an event.
For further information see also issue KDB issue identifier 9 “Stream events in MHP” in the KDB.
8.5 Section Filtering NOVICE LEVEL
8.5.1 What is a section? Sections are logical data containers transmitted over TS packets. They are defined in the MPEG2 systems specification [MPEG2Systems]. A section is usually used to transmit metadata for already existent audio and video elementary streams in the TS, but their use is not limited to this. A section has an upper size limit of 4 Kbytes. Since data easily can exceed this limit, section tables are used to divide data into manageable section sizes. The practical limit to a table’s size lies in the capabilities of the STB receiving it, i.e. its caching capability.
A few standardized tables are defined through MPEG and DVB. Broadcasters are also able to distribute their own proprietary tables using private sections.
Sections will in most cases contain static data; i.e. the data can change at any time, but there should only be one instance of it. This data should ideally be available to any STB at all times. Since STBs have limited resources for caching of data and users can enter a broadcast stream at any time, sections need to be repeated to ensure their availability. There are of course endless possibilities of doing this, but the simplest and most frequently used method is to just start transmitting a table from the beginning once it has reached its end on the TS. I.e. use a data carousel.
Both MPEG and DVB have defined specifications for special tables transmitted in sections. These are specified as PSI and SI, respectively, and are described in more detail in chapter 10. Sections for these tables are limited to a maximum size of 1 Kbyte, not 4 Kbytes as other private sections. The MPEG specific tables are elementary to the navigation of a TS, i.e. how to find available content in the stream. These give information about Services in a stream and what elements these consist of. The DVB specific tables extend this information to include descriptive information of both programs and events and information of other TS in a broadcasters network.
The section header is either of standard or free format type, where the latter is a subset of the former. The free format header is 3 bytes long and includes an 8-bit table id and a 12-bit section length. The extended standard header adds a 16-bit user defined table id extension, a 5-bit
30th March 2006
The MHP-Guide Version: 1.0
Page 88 of 215
version number and 8-bits section and last section number. Whenever the standard header is used a 32-bit CRC is expected at the end of the section.
Section filters are used to extract a specific section or a series of sections from the TS. The filter specifies a table id and a specific bit pattern for the section to be identified with. The first section matching the filter in the TS is copied and returned. There are also special versions of filters for getting complete tables or other series of sections.
8.5.2 MHP Section filters in MHP are 8 bytes long and consist of both values and mask. The mask will determine which bits to include in the filter while the values will dictate a possible match. The filter can start between the 3rd and 31st byte of the section, excluding the header. Both positive and negative filters are available; positive filters will trigger when the bit pattern defined match a section, while negative filters do the opposite. The latter is useful when monitoring changes in a section, e.g. a version number different than the current.
8.5.2.1 API In MHP the section filtering is contained within the org.davic.mpeg.sections package. A filter is defined through the startFiltering method of the SectionFilter class.
startFiltering(java.lang.Object appData, int pid, int table_id, int offset, byte[]
posFilterDef, byte[] posFilterMask, byte[] negFilterDef, byte[] negFilterMask)
In summary, this method is asynchronous and will notify an already registered listener object. The event will be identified with the appData object reference. There are several versions of the startFiltering method and the simplest one will only require a PID to be defined.
There are three types of filtering operations defined in MHP, all extending SectionFilter. First, SimpleSectionFilter returns a single section, the first match found. Second, TableSectionFilter retrieves the complete table of which the first matched section belongs to. Third, RingSectionFilter will continuously store matched sections in an array of predefined size, terminating when an existing section is found in the next step of the array. E.g. if sections are set to empty as they are retrieved this function will indefinitely cycle through the array on a FIFO basis.
Handling several section filters is made easier through the SectionFilterGroup class. Several filters can be created and turned on and off in a single operation. This helps manage the scarce resource section filters, across multiple independent applications.
8.5.3 Capacity and performance Section filtering is a scarce resource in a STB, and MHP has defined that a minimum of 2 section filters for each TS will be available for MHP applications. There are not any performance requirements for MHP section filtering.
A section filter can be performed in both hardware and software, and in many cases as a combination of the two. Software filtering is more processing power consuming and can slow down other applications on the
30th March 2006
The MHP-Guide Version: 1.0
Page 89 of 215
STB while running. Hardware filtering will usually not affect any other operation.
There are few implementations that do all filtering in software. In the simplest form this will only include PID hardware filtering. In those cases where some of the filtering is performed in software, this is most likely to be the bit-masks, and then maybe just a subset of these. E.g. it is possible that only the positive mask will be filtered in hardware or otherwise only the very first bytes in a section.
Any hardware filtering will always be performed first and only after this will a software check verify a match or not. For implementers it can therefore be useful to filter on as many early bits in a section, and leave out later bits and possibly negative filters if not absolutely necessary.
8.5.4 Examples For further information see entries below in the MHP KDB database:
“Private section for up-to-date text data?” http://mhp-kdb.s3.uni-essen.de/nukes/?module=issue_view&op=FillData&id=20
“What is the fastest way to download files? MPEG or DSMCC?” (http://mhp-kdb.s3.uni-essen.de/nukes/?module=issue_view&op=FillData&id=26)
“Read private sections from transport stream” (http://mhp-kdb.s3.uni-essen.de/nukes/?module=issue_view&op=FillData&id=27)
8.6 Tuning and service selection The MHP terminal provides the viewer with a simple, intuitive user interface for all basic tuning and service selection functions. Simultaneous decoding of several services (video, audio and data at different protection levels) and service selection which is based on the service information are made possible.
NOVICE LEVEL
Applications must allow for tuning happening (javax.tv.service.selection) in parallel with the execution of their destroy Xlet method. Hence, implementations of that method should not rely on being able to load classes while executing, because the old carousel which the application was using may not be available any longer.
If you are receiving a not tuned application, your implementation is not tuned to the right transport stream for playing the media. Even if you are playing it from a file, the MHP implementation will treat this as tuning to a new transport stream, simply because it is the easiest and most accurate way to simulate a real input.
The middleware of the MHP-Box will not automatically tune to a different transport stream in order to play a piece of media - this is a deliberate decision in MHP. So you cannot have access to A/V content of other services without using the service selection or tuning APIs.
All channel decoder output data is available on the MHP interface. This makes a superb platform for experimenting with data broadcast applications. Nevertheless, the applications also run without using the service selection API or Tuning API.
30th March 2006
The MHP-Guide Version: 1.0
Page 90 of 215
8.7 Principles of conditional access (smart card, CI content protection) NOVICE LEVEL
Conditional Access - or CA - is as the wording implies a way of controlling who can watch, listen to or otherwise use the distributed content. The means to do this is by encrypting the content in the transmitting end in a way that can only decrypted in the receiving end if the user is entitled to do so.
The need to encrypt content All pay-TV operators rely on the existence of a CA system for their business models and with the dawn of satellite distributed television also public service broadcasters may need to encrypt their programming if they have not acquired rights to distribute in a large geographic area (e.g. Northern Europe) that the satellite footprint permits.
Reason for including conditional access CA systems have been used also in the analogue world with the main functionality of being the central component in pay TV systems. With the dawn of digital television the encryption of the services was a commercial requirement in the specification process. It is being used in many networks.
In the simplest interpretation, this looks like:
Figure 8-6: Encrypting and decrypting content
This is of course more complicated in the real world, where protection against hacking is a big (and for many broadcasters/gatekeepers also an economical) issue.
To be able to control who can access what content, the CA system is closely related to a customer registration system called SMS (Subscriber Management System). The SMS database keeps the customer related information together with information on what permissions the individual customers have.
On the consumer side the users possess a unique smartcard, which is addressed over air with the correct entitlement data, and which in cooperation with the CA system provides the decrypting of the services. In the set top box end, there are 2 possible ways, which are both DVB compatible:
1) The CA system can be present in an external unit called CA module, which fits into an interface specified by DVB called Common Interface (or in short CI) - the smart card can be fitted into this module.
2) The CA system can be build into the set top box with a smart card reader as the interface for the customer to use.
Encryption and decryption process The actual scrambling algorithm used is not public and is only revealed to authorized license holders on a need-to-know basis only. The terms of the
30th March 2006
The MHP-Guide Version: 1.0
Page 91 of 215
license makes requires that the algorithm can only be implemented in hardware. However, the real security of conditional access lies not within the semi-secret scrambling algorithm (source code software implementations have been and most likely still are available for download from the internet).
The scrambling algorithm uses a key called control word (CW). The security of the scheme lies in a secure transfer of the key to the authorized receiver. The keys are encrypted and sent in special elementary streams called entitlement control message (ECM) streams. The systems used to encrypt the CW and package it into an ECM is not standardized. These systems are called conditional access (CA) systems.
The encrypting algorithm of the ECM and its content format is CA system specific and secret. To decrypt the ECM and extract the CW in the MHP terminal a smartcard from the appropriate CA system vendor for the services is needed. The PSI tables should not be scrambled, but except for these most elementary streams can be scrambled if the broadcaster chooses to do so.
In addition to ECM streams the transport stream will also contain Entitlement Management Message (EMM) streams if there are scrambled services in the stream. The EMM’s are used to send messages to the smartcard itself. These messages usually control different settings on the smartcards such as updating of subscription information like adding/removing access to scrambled services.
This is illustrated in Figure 8-7.
Figure 8-7: Encryption and decryption process
30th March 2006
The MHP-Guide Version: 1.0
Page 92 of 215
9 MHP Applications and Application Lifecycle
NOVICE LEVEL
HTML (Hypertext Markup Language): Language to describe content for the world wide web. It is possible to create links between HTML content and to integrate in addition to texts and graphics also interactive content.
Applet: An Applet is a partial Java application program designed to run inside the womb of a web browser, with help from some predefined support classes.
NOVICE LEVEL
Application LifecycleThis chapter deals with the application lifecycle management of an MHP terminal. Both the MHP application states and the state transition model will be considered. Furthermore the relationship between resident applications and broadcasted MHP applications, and, finally, an outlook on stored applications, to be introduced by MHP 1.1, will be provided.
9.1 Applets and Xlets Applets were designed for use with Internet browsers and a full set of Java classes as included in standard Java Runtime Environments.
Xlets are geared towards consumer device applications, such as a television-broadcasting environment. They use a well-defined lifecycle of Loaded, Paused, Active, and Destroyed states, particularly tailored to environments like television.
Applets are significantly linked to a mouse controlled GUI, but most consumer electronics devices are operated by a remote control. Applets are typically linked to HTML pages and AWT. An application that allows keyboard navigation and operation can be suitably run as an Xlet, when the used AWT components will be replaced by HAVi controls.
Due to the fact that an Xlet might originate from an unknown or not trustworthy system and the security restraints safeguards the system resources, applets and Xlets use a similar security model. Xlets should not be able to access system-critical resources or interfere destructively with the operation of other Xlets.
9.2 Xlet Application Xlets have a well-defined lifecycle with Loaded, Paused, Active, and Destroyed states.
Loaded ActivePaused
Destroyed
(not loaded)
destroyXlet destroyXlet destroyXlet
initXlet startXlet
pauseXlet
The basic programming interface for graphical user interfaces in Java. All other graphical user interfaces available in Java (like Swing) are based on AWT.
AWT (Abstract Windowing Toolkit):
Figure 9-1: Xlet lifecycle state machine diagram
Loaded: the DVB-J application instance is loaded but not initialized.
Paused: the application instance minimizes its usage of resource.
Active: the application instance is working and providing service.
Destroyed: the application instance has released all its resource and terminated.
The reason of having these different application states can be found in two MHP inherent restrictions:
30th March 2006
The MHP-Guide Version: 1.0
Page 93 of 215
• Applications have to run in low performance environments: On an average MHP Terminal system resources might be used by one application up to a level where no further application may be started. Instead of continuously destroying the first application it is possible to just release scarce resources and have it running in a paused mode. Thus, basic multitasking is possible while using terminal resources efficiently.
• Applications must not crash: In order to keep the terminal system clean it is necessary that the applications clean up after being terminated. This is done by introducing a destroyed mode before changing into the not loaded state again. This also allows for introducing a superior management instance to control all applications through a well-defined interface. Each of the states has typical tasks that are performed when the application enters the state.
Software used to isolate the application to run from the real hardware and operating system. Applications developed for a virtual machine are hardware independent and can run without changes on any hardware as long as the virtual machine for that hardware is available.
VM (Virtual Machine)Multiple Xlets are allowed per Xlet Manager, which is a resident application. The Inter-Xlet Communication mechanism allows Xlets to communicate and cooperate with each other. A single application is allowed per its own VM instance.
The initial class of the MHP application must implement the interface javax.xlet.Xlet and all of the defined methods, which will be used by the Xlet manager to signal the applications state changes like they are shown in Figure 9-1. When the application manager of an MHP terminal is asked to launch an application, it will first call initXlet(XletContext ctx) and then startXlet(). The method pauseXlet() will send the Xlet into background and startXlet() may be used again to resume the Xlet.
To finally terminate MHP application, destroyXlet(boolean unconditional) is called by the Xlet manager, returning the Xlet into not loaded state. The boolean switch is used to tell the Xlet if it is obliged to terminate or if it has the choice to deny the request for termination.
If an Xlet want to change the current application lifecycle state by itself, it must inform the Xlet manager about the change. The signaling of the state change to the Xlet manager is done by invoking the according methods on the XletContext, which the Xlet was provided by the initXlet(XletContext ctx) invocation. There are three methods for inform the Xlet manager about the change:
• void resumeRequest(): If the Xlet want to change its state from paused to active, it has to invoke the resumeRequest() method of its XletContext object. But note that the Xlet manager need not set the Xlets state to active.
• void notifyPaused(): As soon as the Xlet enters the paused state by itself, it must use this method to signal the paused state to the Xlet manager. This is not necessary, if the Xlet manager invoked the pauseXlet() method.
• void notifyDestroyed(): When the Xlet enters the destroyed state by itself without the initiation of the Xlet manager (invocation of destroyXlet(boolean unconditional)), then the Xlet manager is informed about this self-destruction of the MHP
30th March 2006
The MHP-Guide Version: 1.0
Page 94 of 215
application by invoking the notifyDestroyed() method of the XletContext.
The XletContext object provides access to environment settings of the Xlet with the method getXletProperty(java.lang.String key). Similarly to the getProperty(java.lang.String key) method of the javas System object, a predefined string is used to access the settings. Currently there are the following properties are accessible (see also chapter 11.7.1.1 of MHP 1.0 specification) :
• dvb.org.id“: The organization identifier of the Xlet this XletContext belongs to, like it is signaled in the broadcast. Value is returned as organization identifier encoded as String (defined in chapter 14.5 of MHP 1.0 specification).
• dvb.app.id“: The signaled application identifier of the Xlet. Value is returned as application identifier encoded as String (defined in chapter 14.5 of MHP 1.0 specification).
• dvb.caller.parameters“: Provided Parameters when the Xlet was started by an AppProxy. Parameters are returned as String[]. If no parameters are available, then the String[] has zero length.
• XletContext.ARGS: Parameters as signaled in the broadcast. Parameters are returned as String[]. If no parameters are signaled, then the String[] has zero length.
NOVICE LEVEL
NOVICE LEVEL
Service bound DVB-Table describing all available MHP applications of that service. Used to signal and control the MHP applications of a service.
AIT (Application Information Table)
9.3 Resident applications Unlike broadcast MHP applications, a resident application is stored in a non-volatile storage memory of the MHP terminal on part of the manufacturer. Consequently, a resident application does not have to be implemented as an MHP application. Examples are the navigator, tools for configuration of the MHP terminal, games or the Xlet manager.
As such resident applications are manufacturer specific additions it is not defined which have to be included in an MHP terminal. Broadcasted MHP applications are not capable of interacting with resident applications. Indirect communication may happen when broadcast applications access MHP functions like service selection, which is also observed by the navigator application of the MHP terminal and thus could influence the behavior of the navigator.
9.4 Stored applications MHP 1.1 introduces “stored applications” as a third application type in addition to the currently existing broadcast and resident applications. A stored application is a broadcast MHP application that can be stored on the MHP terminal for later usage. This can be useful if the application is reloaded from the faster local storage instead of the broadcasted data carousel. A stored application associated with a broadcast service can only be started when it is currently signaled in the AIT of a broadcast service, even if it is already stored on the MHP terminal.
In addition to stored applications related to a specific service, also stand-alone stored applications can be developed, like, for example, a game.
30th March 2006
The MHP-Guide Version: 1.0
Page 95 of 215
The lifecycle of a stored application is not any different to the lifecycle of a broadcast application. It can only be started if the application is signaled in the AIT of the currently selected service. This is also valid for stand-alone stored applications, because they are bound to a stored service which contains an AIT with the signaling.
The AIT is described in more detail in section 10.3.
9.4.1 Restrictions of stored applications Stored applications related to a broadcast service are behaving like any other broadcast application. There are no differences despite of the fact, that stored applications can be loaded faster than broadcast applications on the data carousel.
EXPERT LEVEL
EXPERT LEVEL A stand-alone stored application is not associated to a broadcast service and therefore its ServiceContext has no access to a ServiceContentHandler which deals with audio or video, like a Player object. Despite of a related ServiceContentHandler, the application can create its own Player that receives a higher priority for resources than any previously existing presentations.
Furthermore, the behavior of the SIDatabase is undefined for stand-alone stored applications. Either no service information objects are returned at all, or SIDatabase returns service information of the last tuned service. Therefore stand-alone stored applications should not deal with service information that is related to the actual service.
A stored application consists of objects downloaded from the broadcast data carousel. These stored objects can be of the type directory or file (see also chapter 9.4.3 - Signaling of stored application). Therefore all other object types in the data carousel cannot be stored on the MHP terminal, so that for instance DSMCCStreamEvent objects of the data carousel are not available in the storage of a stored application. A stored application needing access to stream events has to mount a currently broadcasted data carousel that contains an assigned DSMCCStreamEvent to listen to.
9.4.2 Extensions to MHP 1.0 APIs The service filter is extended to support the filtering of stored applications. If such a filter is used, the returned ServiceList object contains a list of all currently installed stored applications as Service objects of type StoredApplicationService. Depending on the implementation of the MHP middleware also manufacturer specific resident applications may be included in the filtered ServiceList. An MHP application cannot rely on the possibility of retrieving manufacturer specific resident applications.
With ServiceContext.select(Service) it is also possible to select a StoredApplicationService object. According to the AIT associated to the service the signaled stored applications are available and if an autostart stored application is available, it will be started.
All files of a stored application are accessible as if they were actually broadcast. The only differences are, that asynchronous loading can be expected to complete immediately and that no ObjectChangeEvents are generated. An ObjectChangeEvent cannot occur as the stored files are not connected to any broadcast and can therefore not be updated. It is also
30th March 2006
The MHP-Guide Version: 1.0
Page 96 of 215
not possible for the MHP application to selectively remove files from the storage of the stored application like it is not possible to delete files in the data carousel.
Despite the MHP 1.0 definition of filename restrictions for persistent storage (see chapter 14.6.1 of MHP 1.0 specification), the MHP 1.1 defines an exception for the filenames of a stored application. Stored applications can therefore contain files in the storage of the MHP terminal, the names of which exceed the restriction of MHP 1.0. This exception is only valid for the files downloaded from the data carousel to the MHP terminal’s storage. Files that are created by the stored application in the persistent storage are still limited to the filename restriction of MHP 1.0.
EXPERT LEVEL 9.4.3 Signaling of stored application A stored application is signaled in the AIT like any other broadcast MHP application. In addition to the signaling of normal MHP applications, stored applications contain an Application Storage Descriptor in the common descriptors loop or application descriptors loop of the AIT. This descriptor contains information about the kind of storable applications (broadcast related or stand-alone) and the versions of the application. If any file of the stored application changes, the version number must be increased by one. The version numbering should be unique and if no version number was available anymore, a new application identifier should be used.
To enable the MHP terminal to store the necessary files of the MHP application, an Application Description File must be supplied in the data carousel of the application. The Application Description File has an XML structure and is described in the MHP 1.1 specification, chapter 10.14.3 Application description file. In chapter 9.1.9.1 Version management, some more information about the versioning and updating of a stored application will be given. If an application updates too often, the MHP terminal can refuse to perform these updates. A good advice is to avoid the storage of frequently updated files by not listing such files in the Application Descriptor File.
Last but not least, the permission request file is related to stored applications. With the element application storage in the permission request file the right for controlling stored applications can be obtained.
30th March 2006
The MHP-Guide Version: 1.0
Page 97 of 215
10 Service Signaling
10.1 Introduction
NOVICE LEVEL
Application Signalling
Applications often require aligning with other instances or timings. After applications have been developed, there are some additional steps that need to be taken. They need to be transmitted - i.e. included in the transport stream, and their presence and nature needs to be signaled. The signaling serves different purposes:
to give notice to the receiver that an application is available
to give notice to the receiver what the application contents
to provide eventual signaling from the broadcaster to the application
This chapter provides information on how the signaling is happening as defined in the MHP standard.
10.2 Introduction to SI / PSI Service Information contains metadata necessary to locate, tune to and display services on a terminal. Some is fairly network-oriented, like the mapping of streams to a certain service; other is even human-readable in-formation, e.g. the program service information.
Service Information is divided into tables structuring information related to different aspects of DVB transmission. These tables have entries called Descriptors, which is the smallest unit in Service Information data.
Strictly speaking there is “Program-Specific Information” (PSI) as de-fined by MPEG-2 as well as additional “Service Information” (SI) as defined by the DVB-Project and the resulting ETSI standards [ETSI EN 300 468].
In the following the available SI/PSI tables are described in brief:
Program Allocation Table (PAT) This table contains information on where to find the Program Mapping Tables (PMT) for each program (service) available on the current MPEG-2 stream. This is a table that would not normally be accessed from an Xlet.
Program Mapping Table (PMT) The Program Mapping Table contains information about which elementary streams belong to a certain service. Each service has allocated one PMT, where the PID (Packet Identifier) numbers of the respective audio, video and data streams are listed, as well as a reference to the Program Clock Reference (PCR).
Conditional Access Table (CAT) This table contains private data with information on conditional access restrictions. The main purpose of the CAT is to tell the terminal where to find the EMM stream, i.e. the PID of the EMM stream (cf. section 2.4.4.6 of the MPEG-2 systems specification): “The Conditional Access (CA) Table provides the association between one or more CA systems, their EMM streams, and any special parameters associated with them.
30th March 2006
The MHP-Guide Version: 1.0
Page 98 of 215
The following additional tables were defined by the DVB-Project:
Bouquet Association Table (BAT) The BAT contains a list of services that form a bouquet. It offers information on the provider and the name of the bouquet. This information can be used for displaying an EPG sorted by different bouquet providers.
Service Description Table (SDT) The service description table describes all services available on the current transport stream and may contain information on services on other streams as well. It contains the names and provider of the services.
Network Information Table (NIT) This table contains information on the network the current transport stream is running on, like network name, orbit position and transponder number whereas the latter two are only applicable for satellite networks.
Event Information Table (EIT) The EIT is a large table with a lot of different descriptors. It contains information on the program events within the services. As a minimum, the name of the currently running and the upcoming program is listed for each service. But some providers also give information on the program schedule for a day or week in advance. When building an EPG application, this is the core table to look at.
Running Status Table (RST) Any event has a running status, i.e. it is either currently running or not. The concurrently updated information on the RST allows to automatically switching to a certain event as soon as it starts.
Time and Date Table (TDT) This table contains the current UTC time and is concurrently updated.
Time Offset Table (TOT) This table contains the local time as UTC time plus the local time offset.
Furthermore the Stuffing Table (ST), the Selection Information Table (SIT) and the Discontinuity Information Table (DIT) are defined, but they are less relevant for MHP application programming at the moment.
10.2.1 Information independent from transport stream NOVICE LEVEL
NOVICE LEVEL
Obviously it should make no difference from which transport stream the Time and Date Table (TDT) and the Time Offset Table (TOT) are read.
The Network Information Table (NIT) from the actual network is also identical on all transport streams that belong to this network.
The Bouquet Allocation Table (BAT) may as well group services of different transport streams and even networks, though on different networks there probably will be different BATs.
10.2.2 Optional “other” tables Some transport streams, e.g. such that belong to a broadcaster or provider that offers multiple programs on different transport streams, may include information on all of their programs on all their streams. There may be NITs
30th March 2006
The MHP-Guide Version: 1.0
Page 99 of 215
of other networks, SDTs of other transport streams and pre-sent/following EITs of other transport streams signaled on the current stream.
10.2.3 Tuning to other streams NOVICE LEVEL
EXPERT LEVEL
If a specific piece of information is not broadcast in any way on the current transport stream, there is no way to avoid tuning. On terminals with one network interface this could mean losing the TV stream, so it is not always applicable. Tuning can be done with the org.davic.net.tuning API. Details and examples are available in the MHP Knowledgebase.
10.2.4 Accessing Service Information Service Information can only be accessed through asynchronous method calls to the org.dvb.si or javax.tv.service APIs. This is because the MHP terminal is not required to cache all available information on the terminal, but much of the information has to be read directly from the transport-stream. Depending on the kind of information requested it may take several seconds till the desired information is received from the stream. To avoid blocking the application during this time, SI request methods have been designed to be asynchronous.
The first request is always to an org.dvb.si.SIDatabase or javax.tv.service.SIManager object. By adding a listener the application receives the desired SI-table object. That object then offers own methods to request more detailed information (single descriptors) from the respective table. Basically any kind of information may be requested through both mentioned APIs. The advantage of org.dvb.si is that its objects mirror exactly the Service Information available on a DVB-S/C/T stream, whereas javax.tv.service is more generic and might need to address certain Service Information Descriptors by filtering for its id number. On the other hand the generic approach of javax.tv.service offers a more comfortable access on EPG related information. Both APIs are identical regarding the performance aspect, because the MHP stack will most likely use the same underlying implementation.
10.2.5 Usage of the SI overview tables In order to explore the vast amount of available SI data accessible via the two APIs, we provide two tables that give an overview which steps to follow in order to retrieve a certain piece of information. The documents are called “DVB SI API overview.pdf” and “JavaTV SI API overview.pdf”.
The first column lists the retrieval methods that can be issued on the base object, such as SIDatabase or SIManager. The second column lists the type of object that will be returned with methods that can be invoked on those objects in the third column.
In order to obtain a specific piece of information, locate it at the table of the desired API and track the way back to the base object. The tables are extensive, but may simplify in some cases. Thus, if any information cannot be found in the tables, please refer to the API documentation.
30th March 2006
The MHP-Guide Version: 1.0
Page 100 of 215
10.3 Introduction to AIT and application change Unlike other Service Information tables, the AIT cannot be accessed via any of the SI-APIs. It is managed by the terminal and represented by the AppsDatabase class. This database holds information on all the applications available on a service and gets quickly updated in the case of a ser-vice change.
EXPERT LEVEL
EXPERT LEVEL
In the AIT each application is unambiguously identified within a certain service by a combination of an organization ID and an application ID. In Java these are combined in a class called AppID. Each service has its own AIT. The applicationID and the organisationID have to be configured in the carousel playout server. For each application there are attributes to influence the lifecycle behavior:
service bound: Applications that are service bound can only run when the service they are bound to is running
Visibility: The visibility flag determines whether the application can be seen by other applications in the AIT.
Autostart: Autostart applications start automatically when the service they are signaled on is started.
According to the MHP-standard service selection seriously affects running applications. Depending on the application attributes the following does happen on service selection:
All applications that are marked as “service bound” on the old service will be terminated instantly.
Applications that are service unbound will be killed as soon as the AppsDatabase has been updated with the applications available on the new service. This takes place about some seconds after the service change itself.
Only applications that are service-unbound AND signaled on the new service as well continue to run.
Autostart services are launched. If the service was already launched on the old service, it will be relaunched.
Applications that are not running in a ServiceContext are not affected, like terminal resident applications (Navigator).
Applications can be used to launch and control other applications, e.g. to build a portal application for a service bouquet (cf. chapter 9). It is also possible to launch applications that are signaled on other services. The new service with the target application has to be selected, with all consequences mentioned above. Mere tuning is not sufficient, because tuning does not affect the AppsDatabase, as it does not search the stream for a new AIT. I.e. when tuning the AppsDatabase content remains the same with the result that all running applications keep running, but new applications can only be launched if they are by chance also available on the new stream we tuned to. Also the DSM-CC object carousel will get disconnected, so a running application might not have access to its data anymore. This should always be considered before tuning. The conclusion is also, that portal applications have to be signaled on all services where there are applications available that should be startable from the portal.
30th March 2006
The MHP-Guide Version: 1.0
Page 101 of 215
10.4 Application Loading over Return Channel With the advent of a return channel, which by nature is point-to-point, new possibilities arise. The return channel can be used bi-directionally and may therefore be of advantage to use under certain circumstances - e.g. on-demand data, individually adapted data/applications.
HTTP (Hyper Text Transfer Protocol) The standard protocol used for browsing the internet. MHP 1.1 has support for loading data and applications over the return
channel using HTTP. As such this is only applicable when the Interactive Broadcast and Internet Access Profile are used. Firewalls are typically configured to transparently allow HTTP-traffic, so problems related to the IP-transport are avoided.
A receiver will attempt to download a data file or application if it is signaled in the AIT by using the transport protocol descriptor that it has to attempt to use the interaction channel. This is described in details in 10.8.1 of the MHP 1.1 specification [MHPKDB-1].
The receiver has to search for the required file in the directories and zip files signaled in the AIT tables.
In the case that the MHP-terminal detects that the server uses https (the secure version of http) the terminal shall use https.
The advantages of loading applications over the return channel could be that an application is loaded faster. The load on the broadcast carousel can be reduced by having receiver load applications using the return channel. E.g. this could be used for those applications that are used by a limited number of people, by loading them over the return channel, they do not take up bandwidth in the carousel, freeing up space for other more used applications, or to increase general loading time.
30th March 2006
The MHP-Guide Version: 1.0
Page 102 of 215
11 Security This section gives a brief theoretical background of the security problem, the identified security goals and the nature of possible security threats. In the following, the MHP security framework and the application rights model are described.
NOVICE LEVEL
Security
11.1 Security in interactive television environments In theory, the security problem is often separated into different aspects also called security goals. The security goals that are seen as relevant in the context of interactive television are Integrity, Confidentiality and Availability [Hetzer 2001]. These are shortly described in this section and lead over into security requirements for iTV systems.
11.1.1 Integrity Integrity is given when a certain piece of information is not tampered in an unauthorized manner. In general it can be said that any modification that happens against the intention of the owner of the information violates its integrity.
When looking closer at an execution environment for interactive applications, two kinds of information can be identified: data and code, or in more detail: data, application code and system code. Hence, integrity comprehends integrity of those three parts.
System code (MHP implementation on a MHP terminal) can be considered as static and its integrity (in particular of its security relevant parts) has to be permanently ensured by the manufacturer. If this is not the case any security model collapses. The integrity of the system code therefore has to be presumed by broadcasters and developers.
Application code is transmitted together with according data to the user terminals via the broadcast channel. Because the source of the application is firstly not known, the integrity of a received application code can not be assumed. The MHP-terminal has therefore to be provided with possibilities
to check, if the source of an application is trustworthy,
to recognize if code has been tampered before receiving it and
to ensure that already received code cannot be tampered within the terminal by other applications.
Integrity of data is the actual goal behind the integrity aspect. However, in every computer system data is processed and modified by code. Therefore the integrity of code (as described above) is one of the necessary conditions for the integrity of data.
Data are either received via the broadcast channel together with the appropriate code or created and stored on the user terminal by applications. In this respect, further conditions for data integrity are therefore
the prevention (or at least the recognition) of unauthorized modification of data before or during broadcast and
the prevention of unauthorized modification of data within the terminal by other than the native code.
30th March 2006
The MHP-Guide Version: 1.0
Page 103 of 215
11.1.2 Confidentiality Confidentiality is given, if a piece of private information cannot be accessed by third party without authorization of the owner. Relating to iTV systems the security aspect of confidentiality covers two issues.
The first case concerns private information (data and code), that a broadcaster (owner) distributes via the broadcast channel and that therefore can be received by all user terminals. However, normally due to their business models (e.g. pay-TV), broadcasters might want to restrict access to their content for example to certain users who have subscribed and paid for a certain service TV service. Confidentiality can here be achieved by conditional access systems (CA) through content encryption by the broadcaster and the appropriate distribution of keys for decryption to authorized users. Since MHP provides the usage of CA systems, the confidentiality condition can be fulfilled also for MHP applications by encrypting object carousels. Hence, this possibility is not further elaborated here in the context of security.
The second case concerns private information of the user (e.g. credit card information, passwords, etc.) generated by user interactions and then stored on the user terminal by an application. The confidentiality of user information is only endangered if the user terminal is connected to a return channel; otherwise the private information cannot be transferred or viewed by another party than the user. However, if the return channel exists, also the possibility is given that an application (either accidentally or deliberately) transmits private information from the user terminal to unauthorized thirds. Therefore the MHP-terminal has to ensure
NOVICE LEVEL
NOVICE LEVEL
that only trustworthy applications are granted access to user information stored on the terminal.
11.1.3 Availability Availability is given, if it is possible to use the different services of a system. On the MHP-terminal, the applications and the system code itself have to share the available resources of the system. If one application manages to consume a certain resource to a disproportional extent, the availability of other applications or even of the system is endangered.
Application code that was willfully written to destroy the balanced resource distribution within a system is called “denial of service attack”. But also code that simply contains bugs can accidentally lead to a denial of service. A problem in this context are Deadlocks that occur when at least two processes within a system block each other by awkward allocation and request of resources. The system therefore needs a possibility to dissolve deadlocks if they occur. In every case, the MHP system has to control the access to system resources and it has to control the consumption of resources after it has granted an application access to them.
However, loss of service availability of is not the only danger that occurs when applications from an unknown source get access to the resources of a MHP terminal. Thinking to the abusive use of the modem by dialing a premium rate phone number makes clear that access to certain system resources can only be given to trustworthy applications.
Therefore, it can be stated as a security requirement for an MHP-terminal,
30th March 2006
The MHP-Guide Version: 1.0
Page 104 of 215
that applications only can make use of system resources they are allowed to use and
that certain resources can only be used by trustworthy applications.
11.2 Signing MHP Applications The MHP standard provides a signature procedure that can be used to digitally sign files in a directory, complete directory trees or even whole object carousels. The aim of such procedure is, to provide the MHP terminal with a possibility to verify if an application was signed by a trustworthy entity and, to check if a received application has been modified after signing.
EXPERT LEVEL
This process uses three different authentication messages (hash codes, signatures and certificates) and works as follows:
11.2.1 Hash files (dvb.hashfile) On the broadcaster side, the integrity of the application files is verified and hash values are created and stored in hash files that always have the name “dvb.hashfile”. Each directory in the tree to be signed has finally to contain one hash file. The hash file itself contains one or more sections that are structured as follows:
Hash algorithm identifier
List of filenames
Hash value
For creation of the Hash values MHP allows the algorithms MD5 (128 bit) and SHA-1 (160 bit), whereas the SHA-1 algorithm has to be considered safer due to its significantly longer hash word. The hash values are created by hashing all files in the directory as well as the hash files of the subdirectories (if available). This hierarchical creation of hash codes allows for processing large directory trees with comparable little effort since the “dvb.hashfile” contained in the root directory contains the checksum (hash total) for the complete directory tree. This hash however does not provide security against unauthorized modification on its own, but it allows detecting if anything (filenames, file content) in the underlying file structure has been changed – preconditioned the hash file itself has not lost its integrity.
11.2.2 Signature files (dvb.signature.*)
Secure asymmetric encryption algorithm using a key pair of private and public key.
RSA (Rivest-Shamir-Adelman-algorithm)
The signature files are stored in the root directory and have two functions:
To protect the highest hash file (contained in the root directory)
To specify the originator of the application
By signing, the signing entity assures that the signed application will not cause any damage and is therefore safe to run on the user terminals.
In MHP all signature files have the name “dvb.signature.*”, whereas “*” stands for consecutive id-numbers in case of more than one signature files in the directory. The digital signatures contained in the signature files are created by hashing the “dvb.hashfile” in the root directory and then encrypting this hash value by using the RSA method: The broadcaster uses
30th March 2006
The MHP-Guide Version: 1.0
Page 105 of 215
its private key for encryption and stores the public key (necessary to verify the signature) in the corresponding certificate file.
11.2.3 Certificate files (dvb.certificates.*) For every entity that signs an application (directory tree) two files have to be provided in the root directory: the signature file and the certificate file. The “*” in both filenames represent the id-number of the entity, so that it is clear which certificate file corresponds to which signature file.
As already mentioned, the certificate file contains the certificate whose public key allows for confirming the signature of the corresponding signature file.
The MHP-standard uses X.509-certificates and for this reason defines a new profile thereof.
The certificate that a broadcaster uses for signing is usually a leaf certificate standing at the end of a chain of trust. MHP defines, that all certificate files have to contain all certificates that are necessary to authenticate the leaf certificate used for signing: The complete chain from the leaf certificate up to the root certificate.
The root certificate authority has to be well known to the receiver i.e. the root certificate has to be stored on the MHP terminal. For more information on root certificates please refer to the KDB entry ”DVB Root Certificates, costs and rights” (solution 85).
30th March 2006
The MHP-Guide Version: 1.0
Page 106 of 215
11.2.4 Example of a signed MHP application Figure 11-1 shows an example of a signed directory tree that contains a MHP application realizing a new sticker. The application itself consists of Java class files and data files.
The example shows that all directories in the tree contain the hash file whereas the hash file in the root directory checksums the complete directory tree. As explained in the sections above, the signature file secures the root hash file and specifies the originator of the application. The corresponding certificate file provides the chain of trust that connects the signing entity with the root certificate known to the MHP terminal. In this case only one entity has signed the application.
Figure 11-1: Example of a signed application [Hetzer 2001]
A system that enables users of a public network to exchange data securely and privately through the use of a public and private cryptographic key pair that is obtained and shared through a trusted authority.
PKI
In practice, signing of an application respectively a certain directory tree within an object carousel is accomplished by software tools.
The signing entity, usually the broadcaster, has to take this into account when considering additional costs for signing. However, the major costs that arise in the context of application signing are related to subscribing at an appropriate certificate authority. Further information can be found in the next sections.
30th March 2006
The MHP-Guide Version: 1.0
Page 107 of 215
11.3 DVB MHP Public Key Infrastructure (PKI)
11.3.1 Actors in the MHP PKI This table provides a summary of the actors in the MHP security part and the roles they play in the PKI.
EXPERT-LEVEL
Actor Role
DVB Services SARL (cf. 5.3.11)
It implements the DVB-MHP PKI:
It issues certificates and keys in particular root certificates
It provides the CRL and RCMM management messages.
Certification Authority (cf. 5.3.12)
= CA
It creates, issues and manages the certificates.
Root CAs are part of the DVB-MHP PKI.
Application developer
(cf. 5.3.2)
= DVB-MHP PKI subscriber
Application developers can sign their applications using the key and certificates obtained at DVB Services.
Broadcaster
(cf. 5.3.4)
= DVB-MHP PKI subscriber
A broadcaster can sign the applications delivered over its network using the key and certificates obtained with DVB Services.
It broadcasts management messages (CRL and RCMM) provided by DVB Services.
MHP terminal vendor
= DVB-MHP PKI Root Embedding
The vendor embeds the set of root certificates, provided by DVB Services, in the MHP terminal.
The vendor processes the management messages.
Table 11-1: Actors in the MHP Public Key Infrastructure
11.3.2 DVB Services Hierarchy Figure 11-2: The DVB Services Hierarchy gives a good overview on how the Public Key Infrastructure (PKI) that was developed for MHP is intended to work. Certificate Authorities (CA) have been defined for the issuance of the Root Certificates and of Certificates linked to MHP applications.
MHP Terminal manufacturer have to embed Root Certificates in their MHP Terminals. Application Developers and Broadcasters will receive Subscriber Certificates entitling them to digitally sign MHP applications and attach Certificates to such applications for delivery to Terminals.
30th March 2006
The MHP-Guide Version: 1.0
Page 108 of 215
The DVB MHP PKI hierarchy is resilient because at each level the Certification Services Provider operates two signing Certification Authorities, each of which issues Certificates. A recipient receives one from each Signing CA, an Active and a Substitute. In the case of Manufacturers, the Root Certificates for the DVB MHP PKI hierarchy are embedded in the MHP Terminals they manufacture. If one is compromised or otherwise revoked, the Application Developer would be provided with the necessary authorization to make use of the Substitute Root Certificate, which would activate the Substitute hierarchy. The revoked Root Certificate is replaced by a delivery of a new Root Certificate authenticated by one DVB MHP Root CA and by the RCMM Signing CA which only uses its Certificate for this purpose.
The DVB Services Infrastructure describes those entities under the direct responsibility of DVB Services Sarl. These include the DVB MHP Root CAs, the RCMM Signing CA and the DVB MHP Signing CAs. The DVB MHP Signing CAs issue Certificates to entities outside the infrastructure, Certificate Subscribers and Subordinate Signing CAs. These Subordinate Signing CAs operate under their own Certification Practice Statements, which must be however consistent with this CPS. The DVB Services Infrastructure, together with these extensions, comprises the DVB MHP PKI.
DVB MHP Root CA #1 Signing CA
DVB MHP Root CA #2 Signing CA
DVB MHP Root CA #3 RCMM signing CA
Certificates & keys
Additional level DVB MHP Signing CA
Certificate Subscribers
Root certificates
Broadcasters Application Developers
MHP Terminal Vendors
CRL, RCMM Signed applications
MHP E2E Broadcast
Chain
MHP Terminal
Figure 11-2: The DVB Services Hierarchy
CA: Certificate Authority
CRL: Certificate Revocation List (cf. 11.3.6)
RCMM: Root Certificate Management Messages (cf. 11.3.5)
30th March 2006
The MHP-Guide Version: 1.0
Page 109 of 215
11.3.3 DVB MHP PKI for MHP terminal Manufacturers Manufacturers need to install a set of root certificates into their terminals in order provide them with the possibility to authenticate the certificate hierarchy files that are delivered with applications. Without these root certificates the receiver is unable to run signed applications.
Currently there are three certificates that need to be installed, namely:
An active root certificate currently used to authenticate certificates.
A substitute root certificate that could be used to authenticate certificates at a future date.
A special root certificate used to authenticate changes to the set of root certificates stored in the receiver.
The process of updating these root certificates is triggered by information delivered in a broadcast stream and the manufacturer should not need to be involved in the update process.
Manufacturers need to obtain the set of root certificates from DVB Services SARL by entering into the DVB MHP PKI Root Embedding Agreement.
11.3.4 DVB MHP PKI for Application Developers Application developers need to sign applications that access restricted resources in MHP terminals or which need to verify the integrity of the application file tree for any other reason. The signing process for an application requires the use of an asymmetric key pair (also known as a public/private key pair) where the private key is securely managed under the control of the authenticating end-entity. The DVB MHP PKI uses cryptographic hardware tokens (usually a USB device or a SmartCard) to protect the private key and these keys are normally generated by DVB Services SARL as part of the certificate subscription process. This certificate subscription process also associates the identity of the private key owner with a certificate that contains the corresponding public key part.
Once application developers have received their private key token and associated certificate, they can use these in conjunction with an appropriate application-signing tool to create the additional security files that authenticate their application on the receiver.
Application developers who need to sign applications need to obtain keys and certificates from DVB Services SARL by entering into the DVB MHP PKI Certificate Subscriber Agreement. As part of this subscription process, the application developers need to provide proof of their identity and of their right to broadcast applications over their chosen network(s). The subscription agreement also requires the key owner to take appropriate precautions to ensure the security of their keys and to inform DVB Services SARL if the key is lost, stolen or otherwise compromised.
Note that only organizations that have been assigned MHP Organization IDs may apply for subscription to DVB MHP PKI.
11.3.5 DVB MHP PKI for Broadcasters Broadcasters take responsibility for the content that they deliver over their network and, as such, may decide to take responsibility for signing applications that they broadcast. In this case a broadcaster may need a key
30th March 2006
The MHP-Guide Version: 1.0
Page 110 of 215
pair and associated certificate of their own to sign applications in the same manner as described for an application developer.
Broadcasters also have a responsibility to include management messages to MHP receivers with each application that is delivered. These management messages include lists of certificates that are considered invalid (Certificate Revocation Lists) and changes to the root certificates stored in receivers (Root Certificate Management Messages). The files that contain these messages are available to broadcasters from DVB Services SARL.
Contains a list of certificates that have been revoked prior to their date of expiration.
CRL (Certificate Revocation List) 11.3.6 Certificate Management
X.509 certificates may be revoked by the issuing certificate authority prior to their regular expiration date. Possible reasons for that are that a broadcaster’s private key has been compromised or a broadcaster stops using a certificate authority. Each certificate authority publishes a list of revoked certificates, called a Certificate Revocation List (CRL).
The CRLs are transmitted to the MHP terminals usually within the object carousel. The possibility of using the interaction channel for the distribution of the CRL files is also given but is in most cases not favorable due to the limited availability of return channels in the user terminals.
When authenticating an application, MHP-terminals have to inspect the set of CRL files periodically and cache the revocation information for future use. During the validation process of a certificate chain, the CRL of each certificate authority on the certification path is checked.
EXPERT LEVEL 11.4 Authenticating applications in the MHP Terminal
In order to authenticate an application, the MHP terminal has to carry out the following steps:
Verification that the files contained in a directory are listed in the hash file (located in the same directory)
Verification that the file contents and corresponding hash values in the directory are consistent
Verification of all directories in the tree (ascending in the directory structure), up to the directory that contains one or more signature files
Verification of the signature provided in the signature file by using the public key provided in the corresponding certificate file
Following the certificate chain contained in the certificate each certificate in the chain has to be verified until the link to the root certificate is found
If the certificate chain could be verified by using the root certificate stored on the MHP terminal and none of the provided certificates were found to be revoked, the application can be accepted as authenticated.
After going through this process, the MHP terminal has verified that the application comes from a trusted entity and has not been modified after signing.
30th March 2006
The MHP-Guide Version: 1.0
Page 111 of 215
It has to be noted that it is not necessary and also not desirable to sign all files in a directory tree. This however means that the MHP-terminal has to take care that in particular the class files whose code contains security relevant instructions, are authenticated before execution.
11.5 Application Rights Model As shown above, the rights that broadcast applications need to access different resources in the MHP terminal have to be restricted in order to protect the users and the MHP terminal against unauthorized behavior.
NOVICE LEVEL
Based on the application policy model defined in PersonalJava and J2SE [Morris 2005], MHP defines a number of new permissions that applications need to use many features and resources of the receiver.
The MHP specification rules that the MHP terminal shall assign permissions to applications by taking into account two sources of information (compare chapter 12.6 of the standard [MHP 1.0.3]:
Permissions granted by the user in the preferences in the MHP terminal
Permissions explicitly requested by the broadcaster within the permission request file (PRF)
This principle distributes the power among the broadcaster and the user and hence reduces the danger that an application carries out unauthorized actions. The application is only permitted to carry out actions that fulfill both conditions.
The third factor that influences the permissions an application is given is the fact, if an application is signed or not. Only if an application is properly signed – i.e. the permission request file can be authenticated by the terminal – the permissions requested in the permission request file will be assigned the application.
Unsigned applications or signed applications that cannot be authenticated (e.g. because one of the certificates in the chain has been revoked) are only given the default rights. The MHP-specification defines in section 11.10.1 [MHP 1.0.3] some default permission and restrictions.
In addition to permissions, the permission request file may also request credentials. A credential is a right owned by a third entity and therefore has to be certified by this entity. Credentials are therefore necessary e.g. if an application wants to access data stored in the persistent storage that is owned by another application.
The MHP terminal must decide if an application can be given a particular permission in the moment the application queries the presence of this permission for the first time or when the an application invokes an action that requires the permission for the first time.
11.6 Other aspects Since authentication of whole applications within the MHP terminal may be time and resource intensive, it should be considered which parts of an application have to be signed to ensure the desired level of security. As a general rule it can be stated that media files should not be signed.
30th March 2006
The MHP-Guide Version: 1.0
Page 112 of 215
Handling of signed applications may get complicated in the case of content updates. A news-ticker application like the example in Section 11.2.4 has to be provided with regularly updated data files. But if one component of the signed directory structure is modified, the overall checksum provided in the “root-hash file” is not valid any more. The MHP terminal is no longer able to authenticate the application when this is required (e.g. for a certain method call). For further considerations on this problem please refer to the following KDB entry: Solution 86 - “How to update content without resigning?”
30th March 2006
The MHP-Guide Version: 1.0
Page 113 of 215
12 Graphics, Text Presentation, Audio, Video
Graphics, Audio, Video
Text Presentation
12.1 Introduction The provision of graphics, text audio and video is a substantial addition to the traditional video/audio components. It provides various possibilities but also adds complexity. In this chapter several of these possibilities are examined with respect to MHP. Initially the concept of layers and composition is introduced to give a better understanding of the abstraction methods used in MHP.
12.2 Layers and composition concept MHP terminals are hybrids between desktop computers and traditional TV-receivers. Each screen on MHP compliant hardware provides three graphic planes. These are from back to front, background plane, video plane and graphic plane.
Video plane
Graphic plane Background plane
TV Viewer
Figure 12-1: Graphic Planes in MHP
The MHP platform allows these planes to be blended using some of the Porter-Duff alpha composition rules. Figure 12-2 illustrates the Porter-Duff alpha composition rules.
30th March 2006
The MHP-Guide Version: 1.0
Page 114 of 215
Figure 12-2: Porter-Duff Alpha Composition Rules28
In addition to alpha composition MHP has optional support for HAVi mattes.
As briefly explained, the MHP Platform provides a good foundation for building applications with advanced graphic layout, look and functionality.
12.3 Playable media
12.3.1 Java Media Framework 1.0 The Java Media Framework 1.0 was published 1998 by Sun, Silicon Graphics and Intel for enabled Java applications to manage time-based media content. It provides interfaces and classes to access media content in a standardised and platform independent way.
It provides classes for providing the content (DataSources), for rendering (Player) and for controlling the playback of the media (Controls). The Player is also responsible for fetching the data from the source, synchronising the media (audio and video) by a clock and provides a visual component which contains the decoded video.
An application has only to create a Player object by specifying the URL of the media source, add a ControllerListener and start the playback. The ControllerListener is necessary, because the JMF itself is working asynchronous and sends events if a state change (e.g. player is ready for rendering) occurs.
12.3.2 Java Media Framework 2.0 In 1999 the Java Media Framework [SUNJMF] was extended by Sun and IBM to provide also features like manipulating media content in a Java application. Therefore also the rendering of the content is encapsulated into a DataSink as well as the access to the media stream in a Processor.
Even if the media content playback is as easy as in JMF 1.0, the new technique enables the application developer to connect a DataSource
28 http://en.wikipedia.org/wiki/Alpha_compositing
NOVICE LEVEL
NOVICE LEVEL
30th March 2006
The MHP-Guide Version: 1.0
Page 115 of 215
with an own Processor for changing a part of the content and providing that to a DataSink.
To access the media data by Java it is necessary to decode, stream and rendering the complete media information in Java. This slows down the processing speed of media content on small devices. For Java applications that playback time-based media content completely with in Java, a powerful device like a PC is currently necessary.
NOVICE LEVEL
NOVICE LEVEL
NOVICE LEVEL
A PVR is a receiver equipped with storage for recording digital media and an appropriate user interface that also allows scheduling automatic recordings.
PVR (Personal Video Recorder):
12.3.3 Java Media Framework on MHP terminals MHP implements only Java Media Framework 1.0, because the DataSink and Processor concept of JMF 2.0 is too heavy for today’s MHP terminals. Normally the main source of media is the media content in the DVB stream. The media cannot be rewind or fast-forward – except the MHP terminal implements the special PVR extension. Also the media can be delivered by files in the DSM-CC.
On MHP terminals the implementations of the Control interface need not to return a Component for the graphical user interface. Also the visual component of a Player may return null if no such component is available on the MHP terminal. But if a MHP terminal returns a Player, then it must support it completely. In addition, the Player must not return a GainControl, which is used to change the audio volume.
In addition to the standard JMF there are some extensions like controls for accessing MHP specific features (e.g. selecting another language for the subtitling) or special events for signaling the Player’s state of a DripFeedDataSource.
12.3.4 Media flow The media processed by JMF on a MHP terminal will be provided from a DataSource and processed as well rendered by a Player. Normally the necessary source and player objects for the selected service are created automatically.
If the creation of an own DataSource is necessary, the Manager class can be used by specifying a MediaLocator or an URL. The MediaLocator or URL describes the requested source and the Manager tries to return a DataSource object that can handle the referenced media.
To create a Player object for a DataSource constructed by a MediaLocator/URL, the Manager provides a method that returns a Player depending on the specified DataSource or MediaLocator/URL, if a MediaLocator/URL is specified instead of a DataSource.
If a Player is available, then it can be started, stopped and closed. For Player created by the MHP terminal itself, these methods shouldn’t be invoked, because they can result in undefined behavior of the displayed video content.
12.3.5 Media player and available controls The Player object is a MHP terminal specific implementation of the Player interface. It provides possibility to add listeners to the Player but
30th March 2006
The MHP-Guide Version: 1.0
Page 116 of 215
the access to all Control objects available for the currently selected media is most important function. With the method for getting the Controls of the Player, the media content can be accessed and modified, for example the size of the displayed video can be altered or the selected language of the audio can be changed.
The Control classes which are supported or introduced by MHP are listed in the sections below. But all instances of Player support all Control classes. If a Player only supports a subset of the Control classes available by MHP, then the Player only returns the Control classes it supports itself.
12.3.5.1 LanguageControl This is the base interface for all Control classes dealing with language related content. It allows retrieving the available languages for the content as well as the selection of a specific language content or the default language content. A Control doesn’t implement this interface directly, but one of its sub-interfaces: AudioLanguageControl or SubtitlingLanguageControl.
For selecting a language, the ISO 639 code must be used. If the service contains more than one component with the same ISO 639 language identifier, then the first signaled component with the requested identifier will be selected. To select another component with the multiple used ISO 639 identifier the MediaSelectControl must be used.
12.3.5.2 AudioLanguageControl The AudioLanguageControl is responsible for select the audio language. If a service contains more than one audio component with different languages, then the audio can be changed through this Control by using the language ISO 639 specification.
12.3.5.3 SubtitlingLanguageControl To control the language of the service’s subtitling, this Control can be used like the other LanguageControl classes. In addition to the selection of the language to display, the SubtitlingLanguageControl also allows the retrieval of the subtitling state as well as a method to switch the subtitling on or off.
12.3.5.4 SubtitlingEventControl SubtitlingEventControl is a sub-interface of the SubtitlingLanguageControl and therefore it inherits the functionality of the SubtitlingLanguageControl. But it extends it by the possibility to observe the state-changes of the subtitling. If the subtitling is switch on or off, the subtitling status changed method of the listener is invoked which itself has to check the current state of the subtitling by retrieving the information from the Control’s isSubtitlingOn() method.
12.3.5.5 VideoPresentationControl The VideoPresentationControl is used for retrieving information about the capability of the video positioning, scaling factors for video resize, check for support of scaling and clipping as well as the possibility to modify the clipping region. Changing the video’s size is possible with either
30th March 2006
The MHP-Guide Version: 1.0
Page 117 of 215
BackgroundVideoPresentationControl – which is a sub-interface of VideoPresentationControl – or AWTVideoSizeControl.
12.3.5.6 BackgroundVideoPresentationControl As a sub-class of VideoPresentationControl it inherits the retrieval as well as the clipping functionality but extends it by the possibility to retrieve and alter the video’s location and size. The new location and size of the video is specified as a VideoTransformation, which itself uses float values in the range 0.0 up to 1.0 for representation. So, the VideoTransformation is independent of the TV’s real pixel-resolution.
A MHP terminal needn’t to support any location or size of the video. MHP terminals are allowed to support only the video to location on even lines for interlaced video or to only support as video sizes a quarter as well as full size. For MHP applications it is possible to check how the video will be changed for a specific VideoTransformation by using the method getClosesMatch().
12.3.5.7 AWTVideoSizeControl With AWTVideoSizeControl the location and size of the video can be changed, like it is possible with the BackgroundVideoPresentationControl. The only difference is, that the AWTVideoSizeControl uses the screen's co-ordinate system instead of the normalised co-ordinate system of the BackgroundVideoPresentationControl. Also the AWTVideoSizeControl has the possibility for retrieving the location and size a video on the screen for the location and size the application want to set. Like it is described for BackgroundVideoPresentationControl, the MHP terminal needn’t to support any location and size but at least the location on even lines as well as quarter and full size of the video.
12.3.5.8 VideoFormatControl For video content different video formats are supported. The aspect ratio of the MPEG-2 video can either be 4:3 or 16:9. To enable the MHP application to retrieve the video format of the Player, the VideoFormatControl can be used. This Control is only available for retrieving information, the manipulation of the video format isn’t supported by the Control.
12.3.5.9 MediaSelectControl The MediaSelectControl used for selecting the components of the service, like the video and audio, to be processed by the Player. It allows the selection and deselection of service components as well as the retrieval of the currently selected components. A listener can be registered to observe the result of the selection process.
With the MediaSelectControl it is possible to select other than the default video and audio components by the application.
12.3.5.10 DVBMediaSelectControl To enable a MHP application to select a different kind of content into a running Player, the MediaSelectControl is extended to the DVBMediaSelectControl.
30th March 2006
The MHP-Guide Version: 1.0
Page 118 of 215
12.3.5.11 FreezeControl With FreezeControl it is possible to stop the decoding of the media content. After freezing the content the last decoded video frame is still visible and the audio is stopped but the time base of the media isn’t stopped. When the media playback is resumed, it isn’t defined at which point of the video and audio transmission the presentation of the content restarts. For broadcasted content on MHP terminals without a PVR functionality most likely the currently received media content will be presented. On MHP terminals with PVR functionality this could be different, because the media content received while the Player was frozen can be stored.
12.3.5.12 GainControl (optional) The GainControl needn’t be supported by a MHP terminal, but if a MHP implementation returns the GainControl for a Player, then it must be supporting the control of the volume. It is possible to change the volume between mute and, as maximum 1.0, the volume level when application was started.
12.3.5.13 CachingControl (optional) An MHP implementation needn’t to contain the CachingControl, but it is allowed to support it. If an MHP terminal returns a CachingControl, then it must support it as described in the JMF specification. The CachingControl is available for media content, that is downloadable, which for broadcasted content in a normal MHP terminal isn’t possible. Therefore MHP application must be in aware of the fact, that this class doesn’t exists on the MHP terminal.
12.3.5.14 MediaTimePositionControl (for audio clips only) For playback of audio clips the MediaTimePositionControl is supported to control the timeline of the audio clip. If the MHP application sets another media time position, then the audio clip will as soon as possible start the playback at the specified timeline position.
The MediaTimePositionControl is not supported for broadcasted audio.
NOVICE LEVEL 12.3.6 Obtaining a player and controls Access to the Controls is only possible by getting the Player first. The Player can be retrieved from the service context of the Xlet. As soon as the Xlet has it’s service context, it can get an array of all ServiceContentHandlers bound to the Player and check if one ServiceContentHandler in that array is an instance of Player.
Player p = null;
try {
ServiceContextFactory scf = ServiceContextFactory.getInstance();
ServiceContext sc = scf.getServiceContext(xletContext);
30th March 2006
The MHP-Guide Version: 1.0
Page 119 of 215
if (sc != null) {
ServiceContentHandler[] sch = sc.getServiceContentHandlers();
for (int i=0;i<sch.length;i++) {
if (sch[i] instanceof Player) {
player = (Player) sch[i];
break;
}
}
}
}
catch (SecurityException e) {
e.printStackTrace();
}
After the Player is found in the ServiceContentHandler array of the service context, the getControl(String) method must be used for obtaining a specific Control from the Player. As parameter the fully qualified class name of the requested Control must be specified. If the Player doesn’t support the requested Control, null will be returned, otherwise a reference to the Control will be returned.
if (player != null) {
AWTVideoSizeControl vsc = (AWTVideoSizeControl) play-
er.getControl(“javax.tv.media.AWTVideoSizeControl”);
if (vsc != null) {
...
}
}
12.3.7 Selection of audio components with AudioLanguageControl
First action is to retrieve the AudioLanguageControl from the Player like it is described in 12.3.6. When the Xlet has the AudioLanguageControl object, then the list of available audio languages can be acquired from the control. If no audio language is available, then an array with length 0 is returned.
NOVICE LEVEL
30th March 2006
The MHP-Guide Version: 1.0
Page 120 of 215
To select one audio language, the method selectLanguage(String) of the AudioLanguageControl can be used. The parameter is the ISO 639 representation of the language to select, as it is included in the above array.
If more than one audio language stream with the same ISO 639 identifier is available, then the first signaled audio stream of the network is chosen. To select an audio language stream which has the same identifier as another audio stream and is therefore perhaps not selectable by the AudioLanguageControl, the MediaSelectControl must be used.
if (player != null) {
AudioLanguageControl alc = (AudioLanguageControl) play-
er.getControl("org.davic.media.AudioLanguageControl");
if (alc != null) {
String[] availableLanguages = alc.listAvailableLanguages();
if (availableLanguages.length == 2) {
try {
alc.selectLanguage(availableLanguages[1]);
}
catch (LanguageNotAvailableException e) {
e.printStackTrace();
}
catch (NotAuthorizedException e) {
e.printStackTrace();
}
}
A more generic way of selecting audio streams – and therefore audio languages – can be performed with the MediaSelectControl (see also chapter 12.3.9).
NOVICE LEVEL 12.3.8 Selection of subtitles with
SubtitlingLanguageControl To get access to the SubtitlingLanguageControl the according Player object must be retrieved first (for further details see 12.3.6). The SubtitlingLanguageControl can be used to get the list of available subtitling languages as String array with ISO 639 identifier. Also the
30th March 2006
The MHP-Guide Version: 1.0
Page 121 of 215
wanted subtitling language can be selected, the status of the visibility of the subtitles retrieved as well as the subtitles switch on or off.
The selection of a subtitling language won’t change the visibility state of the subtitles. So if the subtitle is switched off, then the selection of a subtitling language won’t switch it on. This must be performed additionally by using the setSubtitling(boolean) method.
To select one subtitling language, the method selectLanguage(String) of the SubtitlingLanguageControl can be used. The parameter is the ISO 639 representation of the language to select, as it is included in the array of available languages.
If more than one subtitling languages with the same ISO 639 identifier is available, then the first signaled subtitling of the network is chosen. To select a subtitling language which has the same identifier as another subtitling and is therefore perhaps not selectable by the SubtitlingLanguageControl, the MediaSelectControl must be used.
if (player != null) {
SubtitlingLanguageControl slc = (SubtitlingLanguage-Control) play-
er.getControl("org.davic.media.SubtitlingLanguageControl");
if (slc != null) {
String[] availableLanguages = slc.listAvailableLanguages();
if (availableLanguages.length == 2) {
try {
slc.selectLanguage(availableLanguages[1]);
slc.setSubtitling(true);
}
catch (LanguageNotAvailableException e) {
e.printStackTrace();
}
catch (NotAuthorizedException e) {
e.printStackTrace();
}
A more generic way of selecting audio components – and therefore audio languages – can be performed with the MediaSelectControl (see also chapter 12.3.9).
30th March 2006
The MHP-Guide Version: 1.0
Page 122 of 215
12.3.9 Selection of media with MediaSelectControl EXPERT LEVEL
To select specific media content –video, audio or subtitles – the MediaSelectControl can be used. It can be used to select a bunch of service components to a Player object. If a service contains more than one component per media type (e.g. video or audio), then only the signaled default component of the media type will be automatically selected by the MHP terminal. When this control is used the combination of service components to select can be different to the signaled default.
As first action the MediaSelectControl must be obtained from the Player. The MediaSelectControl provides a method for retrieving the current selection, which returns an array of Locators identifying the selected service components. It is possible to remove, add or replace components of the current selection.
if (player != null) {
MediaSelectControl msc = (MediaSelectControl) play-
er.getControl("javax.tv.media.MediaSelectControl");
if (msc != null) {
Locator[] selectedLocators = msc.getCurrentSelection();
if (selectedLocators.length > 1) {
msc.remove(selectedLocators[0]);
try {
synchronized (this) {
wait(10000);
}
}
catch (InterruptedException e) {
e.printStackTrace();
}
msc.add(selectedLocators[0]);
}
}
In the above example the first component of the current selection will be removed so that the playback of the media – video, audio or any other component which is at index 0 in the array – stops. The rest of the selected
30th March 2006
The MHP-Guide Version: 1.0
Page 123 of 215
components are still running and won’t be stopped. After 10 seconds the removed component will be added to the current selection, so that the removed content reappears.
12.4 UI components overview/main HAVI components The scope for this section is the HAVi29 Level 2 GUI API. The HAVi Level 2 GUI API is the section of the HAVi Specification that is adopted by the MHP Specification. The HAVi Level 2 GUI API is only a part of the full HAVi Specification that defines a full APIs for Home Audio-Video devices.
12.4.1 Main HAVI components In a well designed and factored Java API it is important to understand the base classes, abstract classes and interfaces. Most design patterns in Java involve some or all of these abstractions. It is this abstraction that provides the structure and flexibility that the API designers have chosen for the API.
This section will explain some of these abstractions and provide an overview of the core components in the HAVi Level 2 GUI API. Some concepts will be visualized using UML30 class diagrams. Because the UML notation might be unfamiliar to some readers, introduction notes are used to explain the notation elements when first introduced in the diagrams. The notation follows the guidelines from book “UML for Java™ Programmers”31 chapter 3 “class diagrams”.
12.4.2 HComponent and HContainer
Figure 12-3: HComponent and HContainer (a)
29 HAVi - Home Audio-Video Interoperability. See http://www.havi.org30 Unified Modeling Language. See http://en.wikipedia.org/wiki/Unified_Modeling_Language31 ISBN: 0131428489
30th March 2006
The MHP-Guide Version: 1.0
Page 124 of 215
HComponent is the base class for all MHP classes that paints on the screen. HComponent is an abstract class specializing the class java.awt.Component. HComponent extends the java.awt.Component with features for alpha compositing32 trough the HMatteLayer interface. In addition to this, HComponent implements the TestOpacity interface. TestOpacity is a simple interface that allows all HComponents to be queried for opacity.
Figure 12-4: HComponent and HContainer (b)
HComponent participates with HContainer in a composite design pattern33. This means that HContainers can be composed by HComponents and since HContainers are HComponents (see figure above) nested component structures can be constructed. This composition mechanism is provided by Java AWT because HComponent extends the AWT Component class and similarly the HContainer extends the AWT Container class.
Because HComponent and HContainer are subclasses of the normal Java Container and Component classes, they can be used anywhere the normal Java Container or Component can be used. In fact any instances of Container or Component returned by the MHP middleware will be instances of HContainer and HComponent.
In addition to the interfaces HMatteLayer and TestOpacity, which the HComponent also implements, HContainer implements the HComponentOrdering interface. HComponentOrdering is an interface that supports the manipulation of the z-ordering of the composed HComponents and/or HContainers.
32 In computer graphics, alpha compositing is often useful to render image elements in separate passes, and then
combine the resulting multiple 2D images into a single, final image in a process called compositing. See http://en.wikipedia.org/wiki/Alpha_compositing
33 http://en.wikipedia.org/wiki/Composite_pattern
30th March 2006
The MHP-Guide Version: 1.0
Page 125 of 215
12.4.3 HVisible and HLook
Figure 12-5: HVisible and HLook
The API states “The HVisible class is the base class for all non-interactive components”.
As shown above the HVisible has an association that allows zero or one reference a HLook object. The idea is that certain layout and presentation logic can be delegated to a HLook object. The bright reader might have noticed that HLook is an interface, and interfaced it is not allowed to contain anything besides method definitions and static constants. So HVisible will contain a reference to a class that implements the HVisible interface and thereby meet the requirement by HVisible. HAVi comes with several classes implementing the HLook interface, just ready to be plugged into Hvisibles. Developers that need a specific customized Look can implement their own classes that implements the HVisible interface. There are two Interfaces that specializes the HLook interface by defining additional methods. The two sub interfaces are HAdjustableLook and HExtendedLook. For more information on these interfaces see the MHP Specification. The concept presented here, where presentation logic can be changed at runtime, is an example of the strategy design pattern34.
Layout of HVisible can be controlled by LayoutManagers. If a layout manager is associated with the Container into which a HVisible component is placed, the size and location of the component will be controlled by the layout manager. The HLook interface also plays a role when it comes to the layout mechanism.
This is because the HLook interface specified the methods:
java.awt.Dimension getMinimumSize(HVisible hvisible)
34 http://en.wikipedia.org/wiki/Strategy_pattern
30th March 2006
The MHP-Guide Version: 1.0
Page 126 of 215
java.awt.Dimension getMaximumSize(HVisible hvisible)
java.awt.Dimension getPreferredSize(HVisible hvisible)
These methods are also implemented by the java.awt.Component class. Exactly these methods are used by LayoutManagers when the component layout computed. The reason for their presence in HLook is that a new look may require other dimensions for proper presentation. E.g. a border may be added to components requiring the HLook implementation to add the extra with necessary to paint the border. In that case the HLook implementation will implement methods listed above and return a java.awt.Dimension object with the appropriate size. So these methods participate in the strategy design pattern mentioned above.
The HState interface does not define any methods, but encapsulates constants for component states which are used in the various HVisible setContent and getContent methods to indicate which state the specified content is to be set. HState is therefore not a usual interface in that it is merely a utility container for static constants.
HVisibles can be in different states and component behaviour changes with the state. For more information, see the HAVi [HAVI] and MHP Specifications e.g. [MHP 1.0.3].
12.4.4 Other considerations using HAVI In general it can be recommended using the GUI Widgets available on the MHP Platform. The reason is that fewer classes need to be in the broadcast stream providing faster start uptimes for applications. But since the MHP middleware implementations are interpretations of the MHP Standard, there can be deviances in the HAVI component default values across different implementations. Solution 13 in the MHP KDB “Careful use of HAVI widgets” explains this issue in greater detail, but the conclusion is to explicitly specify default values in the code instead of relying on the implicit values. A middle course to common behavior across set-top boxes is to extend the HAVi base classes as explained in the previous sections.
12.4.5 Input events and exclusive registrations on input event
The MHP GUI event model is based on the Java AWT event model. The Java AWT event model has been designed to suit GUI environments where a window manager35 exists. This does not directly suit the MHP Platform where no window manager exists. So the task managed by the window manager needs to be managed by the MHP middleware. In Java AWT the focused window has the input focus from the keyboard. In MHP the typical user input device is a remote control. Therefore the MHP middleware provides a mechanism allowing applications to request input events focus.
35 A window manager is software that controls the placement and appearance of applications on modern
computers with graphical user interfaces (GUI). See http://en.wikipedia.org/wiki/X_window_manager
30th March 2006
The MHP-Guide Version: 1.0
Page 127 of 215
12.5 Displayable graphics formats and restriction36 The picture formats JPEG and PNG can be represented in MHP by default. The support of pictures in the GIF format is left to the equipment manufacturer. The support of further formats isn't provided by the specification. Depending on the used format mentioned above, the representation possibilities are restricted.
NOVICE LEVEL
All images transmitted shall be within the gamut encompassed by the sRGB color space. Where possible this should be coded so that the terminal does not have to translate. Where this is impractical, the sRGB image may be transcoded into a different color space provided the gamut assumption is not violated (q.v. JPEG).
Note: A picture is loaded asynchronously under MHP. This can have the consequence that the picture and the picture information, such as the picture measurements, aren’t confessed on time. The problem can be avoided if the picture was already loaded before showing.
Below, a small code example is given for synchronous image loading:
public class LoadingImage extends Component{
…
//Produce instance of a picture.
Image image = this.getToolkit().getImage("image.png");
//Using the MediaTracker to check loading up process.
MediaTracker tracker = new MediaTracker(this);
//Registering the Image at the MediaTracker (ID=0)
tracker.addImage(image, 0);
try{
//Waiting until the image is loaded.
tracker.waitForID(0);
} catch (InterruptedException e){
//Image wasn't loaded completely.
}
…public void paint(Graphics g){
// The image can be immediately shown now.
g.drawImage(image,0,0,this);
}
36 ETSI TS 101 812 V1.3.1 (2003-06); Technical Specification, http://www.etsi.org (12/02/2005)
Wikipedia, http://www.wikipedia.de (12/02/2005)
30th March 2006
The MHP-Guide Version: 1.0
Page 128 of 215
12.5.1 PNG NOVICE LEVEL
NOVICE LEVEL
ChromaticityContains hue and color repletion
Low-Pass Filtering This function enabling low frequencies to pass through but cutting out high frequencies.
Color Difference Signal Results of the coding of the RGB signal from difference formation between the color signals red, green and blue and the signal of luminance. It doesn't contain information about the brightness but only about the hue and the color.
Alpha ChannelAn alpha channel is additional information in a picture file that determines the transparency for every pixel
PNG was designed as a free substitute for the older proprietary format GIF. Unlike the JPEG format PNG uses a lossless compression. PNG can process up to 256 colors from a color table (cf. 12.6). Furthermore, the storage of grey level pictures is possible with 1, 2, 4, 8 or 16 bits and color pictures (RGB) with 8 or 16 bits per channel (therefore 24 or 48 bits per pixel). PNG files can contain transparency information either in form of an alpha channel or for every color of the color table. PNG supports alpha channels of 8 or 16 bits, what corresponds to 256 or 65536 graduations of the transparency strength.
The restrictions for the PNG format under MHP are described in section 15.1 of [MHP 1.0.2]. MHP terminals are required to support the entire PNG color types define in PNG Specification Version 1.0. MHP terminals are responsible for mapping these colors to those used by the terminal's OSD. Where PNG graphics use colors defined in the minimum color table these colors shall be reproduced correctly. Other colors shall be reproduced on a "best effort" basis.
In addition, the MHP terminal will usually ignore gAMA (gamma) and cHRM (chromaticity) chunks in PNG files. This may cause that the chrominance and the brightness are not displayed correctly.
12.5.2 JPEG JPEG is a method to the coding of digitized, colored images. Several compression methods are in use whereas the following two are lossy:
Low-pass filtering of the color difference signal: The color difference signals are stored most in reduced dissolving. The signals are deep passport filtered and lower felt (in the simplest case by an averaging). The fact, that the place dissolving of the human eye for colors is less sensitive compared to black-and-white transitions is also used for the data reduction. Through this, the amount of data can be usually reduced by factor two.
Quantization: The real data reduction is reached by the quantization. This is the case at all lossy data reductions. By the quantization, a high information precision is changed by a reduced number of values into some less exact information.
These quality losses should be taken into account just like the following one.
Color information lying in the RGB color space is transferred by the JPEG compression into the YUV color space. This color conversion leads to color purity errors if the origin color value does not have a comparable color value in the YUV color space.
12.5.3 GIF GIF is a graphic format with a good lossless compression for pictures with low color depth. This format supports animations in which per frame 256 colors can be used. The PNG format should be used instead of the GIF format, because the support of this format is optional and GIF animations are also not supported.
30th March 2006
The MHP-Guide Version: 1.0
Page 129 of 215
12.6 Color Table It is the most natural way to encode the color information of a pixel to indicate the values of the individual color channels directly in the data structure of every pixel. This manner of the color addressing has, however, a high storage requirement. There is a less memory-intensive method at graphical data with 256 or less different colors which make use of a so-called color table or color lookup table (CLUT).
All colors used in the picture are listed in the color table. Every entry de-fines the values of the color channels of a color. The color table is saved independent from the pixel data. The data of each pixel does not contain the color itself, but it contains an index pointing to a entry in the color table. The amount of the used storage for the index limits the maximum number of usable table entries. For example: if the index storage is limited on two bits, at most four colors can be indexed (cf. Figure 12-6).
0 0 1 2 3
0 1 2 3 2
1 2 3 2 1
2 3 2 1 0
3 2 1 0 0
Index Value
0
1
2
3
a) b) c)
a) This is the information of an indexed image.
b) This is the classification between the index and the color.
c) This is the image after the color assignment.
Figure 12-6: Example of a color table
The color depth of a grid graphic is often reduced to 256 or less colors in order to save memory. The process of reducing the number of colors in a picture by mapping them to a color table is called color quantization.
The color table used under MHP contains 139 opaque colors, 48 colors with a transparency of 30% and 1 color with a transparency of 0% (see figure below: Palette construction rules).
30th March 2006
The MHP-Guide Version: 1.0
Page 130 of 215
Transparency Alpha Additional
Grey Levels
(R=G=B)
Red Green Blue Number of colors
0% 255 42, 85, 170, 212
0, 63, 127, 191, 255
0, 31, 63, 95, 127,
159, 191, 223, 255
0, 127, 255 139
30% 179
(*)
- 0, 85, 170, 255
0, 51, 102, 153,
204, 255
0, 255 48
100% 0 - - - - 1
Total 188
(*): Where the MHP terminal cannot implement this "ideal" value of semi-transparency it shall replace it with the nearest value of semi-transparency it can implement. Note: semi-transparency shall not be approximated as either 0 % or 100 % transparency.
Table 12-1: Palette construction rules
Figure 12-7: Opaque CLUT
12.7 Differences between TV and computer screens NOVICE LEVEL Interactive TV draws from both worlds – computer and television. This results in a few problems, foremost about the pixel aspect ratio. Without proper conversion the prepared images on a computer system are being distorted on the TV screen. This is due to the different picture format used by television, which employs rectangular pixels instead of square ones. This applies for both NTSC and PAL systems, but in a different fashion.
PAL frames have a size of 720 by 576 Pixels which would equal a relation of 4:3.2, not matching the TV screen aspect ratio of 4:3. NTSC frames are 720 by 486 in size, which comes out as 4:2.7. The resulting pixel aspect ratios needed to compensate this effect are shown in Figure 12-8.
30th March 2006
The MHP-Guide Version: 1.0
Page 131 of 215
Figure 12-8: Comparison of pixel aspect ratios
Here are some examples on what happens when a computer image is displayed on TV screens without prior conversion.
Computer screen (Original)
PAL 4:3
NTSC 4:3
PAL 16:9
30th March 2006
The MHP-Guide Version: 1.0
Page 132 of 215
EXPERT LEVEL
NOVICE LEVEL
EXPERT LEVEL 12.7.1 Calculation (PAL) The widespread approach to convert computer images for interactive TV is to squeeze the image by a factor of roughly 0.95:
A 4:3 aspect ratio image would equal 768x576 square pixels. To have 720 horizontal rectangular pixels covering the same width as the square ones, they have to be 768/720 = 1.067 times wider than the square pixels. Thus the pixel aspect ratio on the TV screen would be 1.067:1. This equals to the amount that a square pixel gets stretched horizontally on a TV screen. To compensate this stretching, we have to divide 1.067, equaling a scaling by the factor 0.95.
The result is close, but it still is an approximation. This is due to the fact that in digital video the active line width was increased meaning that we have more pixels to the right and to the left which show actual image content. A digital horizontal line has 720 pixels; an analogue line has only 702. The TV screen aspect ratio of 4:3 holds true only for 702x576 pixels. When converting an analogue PAL video to PAL D1, the additional 18 pixels can be seen at the edges as black vertical stripes. True digital equipment records full 720x576 pixel images, which equals a screen aspect ratio of about 4.1:3.
So the final horizontal scaling factor is 702/768 = 0.914 for preparing images for TV screens. Vice versa we have to use a factor of 768/702 = 1.094 for scaling TV images for computer editing (in case a correct aspect ratio on the computer is needed).
12.7.1.1 Scaling for PAL 16:9 PAL 16:9 is calculated likewise. The 702 x 576 image is stretched to this aspect ratio. 16:9 in square pixels would be 1024 x 576. This results in a scale factor of 1024 / 702 = 1.46. Or vice versa, to prepare computer images for 16:9 TV they have to be horizontally squeezed by 702 / 1024 = 0.69.
Undoubtedly there is a loss of picture sharpness because of this procedure. This is why the scaling should always be the last step of image preparation.
12.7.2 Loss of sharpness The following images show the loss of sharpness due to pixel aspect ratio conversion. We assume that the image has the same vertical resolution and a content image aspect ratio on all screens. Luckily the viewing distance with TV sets is often large enough so that the human eye cannot tell the difference; still this is a fact screen designers must be aware of.
Computer screen
30th March 2006
The MHP-Guide Version: 1.0
Page 133 of 215
PAL 4:3 screen
PAL 16:9 screen
12.7.3 Calculation (NTSC) Calculations for NTSC are a little bit different. The format of a digital NTSC D1 frame is 720 x 486, but the active area in 4:3 aspect ratio is 711 x 486 in size. With square pixels, the format would be 648 x 486, resulting in a pixel width of 648/711 = 0.911.
We now know that square pixels will shrink on an NTSC TV Screen, so they have to be stretched by 711/648 = 1.097.
EXPERT LEVEL 12.7.4 Overview of scale factors This table shows the scale factors that have to be applied to convert images for the TV screen and back while keeping the image’s aspect ratio.
Source Target Horizontal Vertical
Computer Screen 1:1 PAL 4:3 91.4 % 100 %
Computer Screen 1:1 PAL 16:9 69 % 100 %
Computer Screen 1:1 NTSC 4:3 109.7 % 100 %
Computer Screen 1:1 NTSC 4:3 100 % 91.1 %
PAL 4:3 Computer 1:1 109.4 % 100 %
PAL 16:9 Computer 1:1 146 % 100 %
NTSC 4:3 Computer 1:1 91.1 % 100 %
PAL 4:3 NTSC 4:3 101.3 % 84.4 %
12.8 Color conversion Color conversion is done automatically by MHP terminals. Any image is considered as being in the sRGB color space (the internet standard) and correctly converted into the TV´s color space. The image’s color palette
30th March 2006
The MHP-Guide Version: 1.0
Page 134 of 215
gets mapped onto the minimum color set as described in the MHP standard. However, the result varies greatly between terminals by different manufacturers. Some boxes may implement full true-color support, while others perform a dithering or just a nearest color match. Especially the latter is very susceptible to color mismatch. This may still be acceptable when the aim is to support also more advanced terminals. But if the requirement is to play safe on all terminals, the color conversion should be part of the production process already. An MHP compliant color palette can be either downloaded or assembled by hand. The Color Lookup Table (CLUT) for the minimum color support contains 139 opaque colors, 48 semi-transparent colors and one fully transparent color. Those colors are not evenly spread over the full color spectrum, but there is an emphasis on greenish colors, whereas red colors are weakly represented. Thus plants can be displayed quite authentically, whereas skin colors may be very far from the original tone after conversion. Quite often a mere nearest color match will result in a color that has a close luminance value, but a totally different tone. Original red values are often mapped on grey values that spoil the image. Good photo editing tools generally allow for better conversion than terminal built-in solutions.
The only solution to display near true color images on all devices is to use MPEG-2 video drips. Those are images that are converted to I-frames. This can be done with appropriate MPEG-2 encoding software and some image manipulation programs. MPEG-2 does not use the whole 256 values a byte offers in order to code the r, g and b values, but a range from 12 to 238. It is important to make sure that the encoder matches the RGB black value of 0 to 12 in the MPEG-2 color space, likewise the 256 shall be mapped to 238 and all values in between accordingly. Note that most tools do this conversion by default. This reduction also means a slight but inevitable loss of contrast in the image. When TV footage is used as source for a drip-feed it shall be considered that this is already converted to the MPEG-2 color space, so the automatic conversion has to be turned off. Otherwise the image will again lose contrast.
12.9 Double buffering Double Buffer means that the screen storage of a graphics card is twice available. Through this, the picture of an animation can be rendered in the background which is at first invisible (back buffer). As soon as the picture is requested, the ready picture as a whole is represented in the foreground (frame buffer). Another picture can be rendered in the background and held up for displaying next time. This technique is used to avoid a flickering and a distorting effect on screens. This effect is being caused if the graphic is displayed and will be written at the same time.
Some receivers support double buffering by default. Whether the receiver supports double buffering can be found out with the following code lines at run time:
//Creating of a standard HScene.
HScene hScene = HSceneFactory.getInstance().getDefaultHScene();
//Is the receiver supporting double buffering?
hScene.isDoubleBuffered();
30th March 2006
The MHP-Guide Version: 1.0
Page 135 of 215
If the receiver does not support double buffering, it is possible to try the following resolution method, which creates a double buffering software solution:
public void paint(Graphics g){
bufferDimension = this.getSize();
bufferImage = createImage(bufferDimension.width,
bufferDimension.height);
bufferGraphics = bufferImage.getGraphics();
//Rendering of the image in the back buffer.
bufferGraphics.drawImage(image,x,y,null);
// Showing the image which was already created in the back buffer.
g.drawImage(bufferImage,0,0,this);
}
12.10 Fonts The MHP specification defines one common font for all MHP devices. The font is called Tiresias Screenfont (see http://www.tiresias.org). It is especially designed for the usage on television. No other fonts are supported by default.
To keep the font in a compressed format the MHP member group decided to use the portable font resource format. The format provides dynamic usage. This enables application developers to upload and use own fonts on the MHP device.
12.10.1 Generating fonts In spring 1994 Bitstream announced a new font rendering system called “truedoc”. This system records font shapes and stored them in a much more compressed format. A very compact rasterizer makes the system portable. It began to get very popular. One innovation was that the format could be used to display any type of fonts in a web browser without using images. Because of its portability the format got also famous in the Java community. During the development of the MHP standard truedoc seems to be the appropriate system for MHP terminals.
Bitstream provided a web-font toolset to create and save fonts in their new format. The font format is called portable resource format (pfr). Soon further companies like HexMac offered tools to edit and create fonts in the new format too. Additional font converter, e.g. from the font format “true type” to “truedoc” were available. This is now over 10 years ago.
Today the hype is over, HecMac disappeared from the market and Bitstream doesn’t provide their web-fonts tools anymore. Currently it seems to be nearly impossible to get any tool dealing with the portable resource format, so the only possibility is to retrieve completed fonts directly at Bitstream. However, only small number is offered for free.
30th March 2006
The MHP-Guide Version: 1.0
Page 136 of 215
If you want to create fonts by yourself, you have to develop your own font creator or converter first. Therefore the specification of the portable resource format version 1.0 (this version is used in the MHP terminals) is available on the MHP Knowledge Database website related to the issue “Creation of truedoc fonts”.
The data structure (containing applications, media files, etc.) that is broadcast within a transport stream.
In the context of MHP DSM-CC object carousels are used
Object carousel
12.10.2 Generating the font index file As mentioned it is possible to upload and use own fonts on an MHP terminal. Therefore you have to include the fonts (stored in the truedoc format) and a font index file in the object carousel. The index file has to be placed in the root directory of the application (signaled in the regarding application information table).
The index file includes the description of the font like font name or location of the font file. It provides the mapping between a font face name and the file containing the font data. The file is called dvb.fontindex.. The XML DTD defines the file syntax.
The XML index file contains a loop of all external fonts broadcast with the application. Each font is defined by the following tags:
<name>: Contains the font face name of the font (e.g. "Helvetica")
<fontformat>: The file format of the font. For the PFR format used in the MHP specification, this shall be "PFR".
<filename>: Relative path to the font file. This is relative to the directory containing the font index file. The separator character for directories is "/". As this is a relative path, it shall not begin with a "/" character.
<style>: The style elements contain the names of the styles of the font that are contained in this font file. The possible values are "PLAIN", "BOLD", "ITALIC" and "BOLD_ITALIC". There is one style element included per style contained in the indicated font file, except when all the usable styles of the font are in the same file in which case the style elements can be left out. When different styles of the font are contained in separate files, these are included in the directory as separate font entities with the same name but different style and filename.
Just take a look at an example. It is very easy to generate a font index for signaling own fonts.
<?xml version="1.0"?>
<!DOCTYPE fontdirectory PUBLIC "-//DVB//DTD Font Directory 1.0//EN"
"http://www.dvb.org/mhp/dtd/fontdirectory-1-0.dtd">
<!-- in the following tag all fonts have to be declared. Fonts shall be saved in
the base directory. PFR0 (Portable Font Resource version 0) is defined as in DAVIC
1.4.1p9 as the coding format for fonts. Receivers are only required to provide
support for the outline version of the font.-->
<fontdirectory>
<font>
30th March 2006
The MHP-Guide Version: 1.0
Page 137 of 215
<name>OzHandicraft BT</name>
<fontformat>PFR</fontformat>
<filename>org/mhpkdb/ui/OzHandicraft.pfr</filename>
<style>PLAIN</style>
</font>
<font>
<name>Zurich BT</name>
<fontformat>PFR</fontformat>
<filename>org/mhpkdb/ui/Zurich.pfr</filename>
12.10.3 Using external fonts Using external fonts in a MHP application is quite simple. First of all you have to put the font index file in the root directory of the applications. The fonts, saved in the portable font resource format, have to be placed in the directory given in the filename tag of the index file. The application can now import this font with the FontFactory. The method createFont returns the font object of the requested font. This could be used in the familiar way.
try {
/* load the file dvb.fontindex (mandatory filename) with the information about the
additional fonts by creating a FontFactory */
FontFactory fontbox;
fontbox = new FontFactory();
/* when the file dvb.fontindex was found and all entries were valid a FontFactory
was made above. Now Fonts can be created
Be aware of the following exception: If one font described in the font index file is not in the object carousel the font factory will not work. It is only possible to import fonts if the font index file is free of errors.
30th March 2006
The MHP-Guide Version: 1.0
Page 138 of 215
GSM (Global System for Mobile Communications) Most popular standard for mobile phones in the world. GPRS (General Packet Radio Service): Mobile data service available to users of GSM mobile phones.
Return Channel
NOVICE LEVEL
ADSL (Asymmetric Digital Subscriber Line) Enables faster data transmission over copper telephone lines than a PSTN modem, usually several Mbit/s
UMTS (Universal Mobile Telecommunications System) It is one of the third-generation (3G) mobile phone technologies
13 Return Channel
13.1 Introduction The usage of the return channel allows improvement of the user experience. By using the return channel it is possible to build truly interactive applications in which the user signals information back to the provider of the applications, this can be used e.g. for voting applications or to control Video On Demand servers. With MHP 1.1 the return channel can also be used to download applications; please consult chapter 9.4.3 for further information on this topic.
13.2 Types of return channels There are basically two types of return channels: always on and connection based. Depending on the type of return channel, an MHP terminal and/or applications might have to implement different functionality to cope with the requirements set by the users.
Each interface to a return channel is instantiated by an instance of the class RCInterface. Basic properties (type and speed) of the channel are modeled in this class.
Access to the return channel is managed by the RCInterfaceManager class.
For the moment, a PSTN modem is integrated in most of the MHP terminals. Ethernet is also used when a high speed Internet connection is available. The mobile interaction channels are less common. The main technologies in this area are the GSM modem, which is in use comparable with a PSTN modem and a GPRS connection, which is in use comparable with ADSL. Another option is the use of UMTS technology, which also provides an always-on connection.
Using satellite technology as return channel is also a possibility. DVB-RCS (DVB-Return channel satellite) offers a standardized solution however its use is not common yet.
13.2.1 Always-on return channels
International telephone system based on copper wires carrying analogue voice data.
PSTN (Public Switched Telephone Network)
Always-on return channels are that type of return channels for which the IP-connection is always present; examples include cable modem, xDSL or Ethernet. These technologies provide always-on connections and the user needs to have a subscription to the service from the ISP. An Ethernet return channel will typically be used in combination with xDSL or cable modem, the customer will connect the Ethernet port either using a hub or switch, or directly to the cable or xDSL modem. Typically these types of return channels provide a high bandwidth pipe to the Internet and as such can also be potentially used to stream audio/video. Note of course that the speed depends also on the type of subscription with the ISP that is providing the service. These always-on return channels do not use a dial up modem.
The computer networking protocol used on the Internet
IP (Internet Protocol)
30th March 2006
The MHP-Guide Version: 1.0
Page 139 of 215
13.2.2 Connection-based return channels Connection-based return channels are that type of return channel for which a connection needs to be established before the actual data-transfer can happen. A typical example is a dial-up connection.
NOVICE LEVEL
It is a type of circuit switched telephone network system, designed to allow digital transmission of voice and data over ordinary telephone copper wires, resulting in better quality and higher speeds than available with analogue systems.
DECT (Digital Enhanced Cordless Telecommunications)ETSI standard for digital portable phones, commonly used for domestic or corporate purposes
UDP (User Datagram Protocol) It is one of the core protocols of the Internet protocol suite. UDP does not provide the reliability and ordering guarantees
TCP (Transmission Control Protocol) It is one of the core protocols of the Internet protocol suite. Using TCP, applications on networked hosts can create connections to one another, over which they can exchange data. The protocol guarantees reliable and in-order delivery of sender to receiver data.
ISDN (Integrated Services Digital Network)
Applications need to have the proper right before a connection-based return channel can be used, this is to ensure only “trusty” applications make call attempt.
Only one application can control the dial up modem at a specific time. If an application tries to establish a connection while another application already uses one, the priority level of the application defines which application will get the control.
If there is no activity on the return channel for a configurable amount of time, the connection should be disconnected automatically.
13.2.3 Detailed example There are many possible network configurations covering the return channel technologies such as PSTN, ISDN, cable, GSM, DECT and other interactive channel options.
Issue 6 “How to use a connection based and/or permanently connected return channel?” in the MHP knowledgebase contains a fully worked out example (solution 75) that illustrates the different mechanisms that can be used to establish a connection and how to send data to a backend server using MHP.
13.3 Protocol overview MHP defines the level of support for different IP-protocols. The level of support depends on the profile and standard version.
13.3.1 UDP MHP provides the usage of UDP based communication via the return channel. The communication established is bi-directional where information can be sent and received, this enables UDP based communications with external UDP servers. This capability enables stateless connection oriented communication, which are mainly adequate for example on multimedia data, home control application and service discovery. UDP in itself does not have support for a reliable connection, (e.g. in case of packet loss). If reliability is important for the application, the application has to take care of this. (E.g. retransmission if needed)
Issue 29 “UDP communication” in the MHP knowledgebase provides example code on how to use UDP for sending and receiving data.
13.3.2 TCP MHP provides the usage of TCP based communication via the return channel. The communication established is bi-directional where information can be sent and received, this enables TCP based communications with external TCP servers. This capability enables connection-oriented communication used by most of network application protocols such as HTTP, SSL etc. It can also be used directly for data transmission. TCP
30th March 2006
The MHP-Guide Version: 1.0
Page 140 of 215
It is the primary method used to transfer or convey information on the World Wide Web.
SSL (Secure Sockets Layer) SSL and Transport Layer Security (TLS), its successor, are cryptographic protocols which provide secure communications on the Internet.
DNS (Domain Name System) It is a system that stores information associated with domain names in a distributed database on networks, such as the Internet.
HTTP (Hypertext Transfer Protocol) provides for in-sequence reliable delivery. TCP is the main protocol that is
used for transferring large chunks of data and is also used by other protocols like HTTP.
Issue 24 “TCP connection” in the MHP knowledgebase provides example code on how to use TCP for sending and receiving data.
13.3.3 HTTP MHP provides the usage of the Hypertext Transfer Protocol (HTTP) via the return channel. The communication chain is bi-directional. This facilitates the user to get information from the World Wide Web and to send information to an HTTP Server.
Issue 64 “Possible use of HTTP” in the MHP-knowledgebase discusses how to establish an HTTP connection.
13.3.4 DNS DNS (Domain Name System) is used to resolve Internet names (as www.mhpkdb.org) to IP addresses (as 194.172.230.122). The other way around is also possible, but is not used so often and not mandatory on an MHP terminal. Using Internet names instead of IP addresses allows for more flexibility and readability of server-identifiers. It can also be used to implement specific features (e.g. load balancing).
In order to be able to use DNS in an MHP environment a return channel should be available and provide access to a DNS server. The IP address of the DNS server can be configured automatically into an MHP terminal using DHCP or during PPP connection set-up. Manual configuration using the build in menu system is also possible on most of the MHP terminals.
Issue 3 “DNS Look-Up” in the MHP Knowledgebase shows an example of how to use DNS lookup on an MHP terminal.
Commonly used to establish a direct connection between two nodes.
PPP (Point to Point Protocol)
13.3.5 Protocol support In the MHP standard it is pointed out that the protocols defined provide support for IP over the interaction channel. Which protocols that are supported, depends on the MHP version and the supported profiles. The Enhanced broadcast profile does not provide any support for the IP protocols. The tables below provide an overview of the support by the Interactive Broadcast Profile and Internet Access Profile.
30th March 2006
The MHP-Guide Version: 1.0
Page 141 of 215
Protocol
O = optional M = mandatory
Interactive
Broadcast profile
TCP M
UDP M
HTTP 1.1 O
DNS M
Table 13-1: MHP 1.0.x Protocol Support
Protocol
O = optional M = mandatory
Interactive
Broadcast Profile
Internet
Access Profile
TCP M M
UDP M M
HTTP 1.1 O O
HTTP
(“MHP-HTTP 1.0”)
M M
DNS M M
HTTPS M M
Table 13-2: MHP 1.1.1 Protocol support
13.4 MHP as client for Internet services & Integration of contents received via return channel
MHP 1.0 does not define any Internet services that must be supported by the MHP terminal itself. It is possible to develop MHP applications, that use the return channel for sending and/or receiving data from the Internet by IP and display the content by an own application. By developing an own application, all Internet services based on IP can be brought to a MHP terminal, but it has to be remembered, that such MHP applications can be huge.
For MHP terminals implementing MHP 1.1 with Internet Access Profile 2 there are Internet services defined that must be supported directly by a resident application of the MHP terminal. Such an MHP 1.1 terminal must at least implement and provide an email client, a web browser as well as a Usenet client. These clients must be also accessible and controllable by MHP applications, so that a MHP application can use the email client to
30th March 2006
The MHP-Guide Version: 1.0
Page 142 of 215
create and send emails or embed the web browser to display HTML content.
It is possible to integrate content received from a server via the return channel. To display such content, an MHP application must be developed and broadcasted to the MHP terminal. After the MHP application is started, it can connect the return channel and receive data from a server. As soon as the data has been received by the MHP terminal, the application can render the data and display it on the TV screen.
Return Channel Security
13.5 Security on the Return Channel The use of the return channel of a MHP terminal is restricted. Possible risks are that an application deliberately or due to bugs in the code transmits private data unauthorized to a third party or dials up a premium rate telephone number leading to high cost for the user.
The description of the return channel security in this section builds upon the general security methods of MHP as treated in the Chapter 11.
Unsigned applications may not use the return channel at all. Signed applications also may not access the return channel (by default) unless otherwise specified by the permission request file. The syntax of the return channel permission also provides the phone number that an application may try to dial.
The return channel security in MHP goes one step further and requires user interaction whenever an application – preconditioned it is properly signed and equipped with permissions – builds up a return channel connection: The terminal then has to ask the user to confirm or deny dialing a certain phone number.
General purpose security for the return channel is provided by the Transport Layer Security (TLS) protocol as described in [RFC 2246].
A cryptographic protocol, which provides secure communications on the Internet. The successor of SSL 3.0
TLS (Transport Layer Security)
An MHP application can establish a TLS session. This can be used for sensitive transactions. In such a scenario, the application knows the server to connect to and can check that a given certificate chain contains the expected certificate that it knows and trusts.
One or several TLS root certificates can be optionally broadcast along with the application. The certificate files shall be authenticated members of the same authenticated sub-tree as the application. Before a TLS connection can be established, the MHP terminal has to ensure that the received certificate list contains at least one trusted certificate. When there are no TLS certificates sent with the application, the MHP terminal will authenticate the above-mentioned signature and permissions and then allow a connection to be established to any server.
For more information on return channel security confer to chapter 11 of [MHP 1.0.3].
30th March 2006
The MHP-Guide Version: 1.0
Page 143 of 215
14 Equipment
14.1 Playout systems The Playout system is a vital part of any MHP enabled broadcasting network. The role of the playout system is to convert MHP Xlets and data into a DSM-CC carousel that can be received on MHP terminals.
ManagementConsole
MHP PlayoutServerRemote API
Security
DSM-CCCarousel
PSI
NOVICE LEVEL
Equipment
Figure 14-1: Typical MHP playout server interfaces
There are a multitude of different MHP Playout systems. A very comprehensive list can be found in the MHP-KDB (issue 74 “What DSM-CC Playout Systems are available?”, solution “Report on available DSM-CC playout systems”).
The figure above is an attempt to show a typical MHP playout without being vendor specific. The figure show common functions that may be included, some are required.
The DSM-CC carousel is often a box with a DVB-ASI output and some form of file and/or network based input interface. It can be a hardware “black box” or an application running on a standard workstation architecture utilizing a DVB-ASI PCI card to generate the final DVB-ASI signal.
The DSM-CC carousel is the most service critical part of the system and in most cases it would be recommended to have some form of redundancy of this module. Without the DSM-CC carousel all non-stored MHP application will cease to function correctly. The DVB-ASI is usually connected to a multiplexer to be multiplexed with other service content into the final transport stream. There may be a matrix switch, distribution amplifier or failover switch between the output of the DSM-CC carousel and the multiplexer, this is dependant on the redundancy scheme used.
Some vendors provide a playout server separately from the DSM-CC carousel. This server may provide additional functionality and interfaces in addition to the pure DSM-CC functionality provided by the DSM-CC carousel modules.
30th March 2006
The MHP-Guide Version: 1.0
Page 144 of 215
The role of the playout server will typically be to integrate the other modules of the system. The server may have logic to create the required AIT tables and ensure that the PSI subsystem is updated whenever the AIT changes. It could also ensure that the security subsystem will sign and re-sign applications whenever needed.
The security module is responsible for signing applications and could also include functionality for certificate management. This is an area that seems to be currently less mature than the core DSM-CC playout systems, and the options are more limited in this area.
Most playouts have a configuration and management GUI that is used to operate and supervise the playout.
A remote API (typically Java based) to control all relevant functions is also fairly common.
14.2 MHP Terminal architecture MHP terminal means all devices that fulfill the requirements of the MHP specification. Indeed we can find STBs, but also PCs and IDTVs. Those terminals are designed for reception and presentation of multimedia content (audio/video, subtitles, etc.) and additionally to enable interactivity (user can interact with an interactive applications).
EXPERT LEVEL
STB (Set-top box)MHP Terminal to be connected to a TV set.
This sub-section introduces the Hardware (HW) and Software (SW) architectures of the MHP terminals, and presents each component.
To be MHP compliant the terminals have to pass the MHP test suite provided by DVB group. All MHP compliant terminals have this MHP logo:
Figure 14-2: The MHP Logo
30th March 2006
The MHP-Guide Version: 1.0
Page 145 of 215
Figure 14-3 below represents an abstract view of the MHP Terminal hardware architecture: EXPERT LEVEL
Figure 14-3: MHP terminal hardware architecture
The MHP Terminal selects the appropriate broadcast TV information by tuning to one of many input channels through the <TS selector>. The signal is digitally modulated using Quadrature Phase Shift Key (QPSK) for satellite applications, Quadrature Amplitude Modulation (QAM) for cable and Orthogonal Frequency Division Multiplexing (OFDM) for terrestrial. The information in the selected Radio Frequency (RF) channel is then demodulated to produce a MPEG-2 Transport Stream (TS) containing the audio, video and other information that relates to the selected TV program.
In general, digital TV information in the MPEG-2 Transport Stream may be encrypted to prevent customers who have not paid for a particular service from being able to view it.
The <Demux> filters audio, video and data contents in the MPEG-2 TS according to the users selected service. When the MPEG2 TS is encrypted, the <Demux> also decrypts the content according to special keys provided by the <Conditional Access Unit> (e.g. SmartCard unit, common interface module).
The <A/V Processor> then decompresses the audio and video information and synchronizes them correctly.
Graphical content provided by the <Graphic Processor> and Audio/Video content are then mixed and encoded in a specific displayable signal (e.g. PAL/CVBS, PAL/RGB, HDMI 720p50 etc).
The <Remote Control> allows end users to control the behavior of the MHP Terminal and interact with MHP applications.
MHP Terminals may also include a <Return Channel> access allowing to send and to receive interactive data. Conventional telecommunications modems are typically used in satellite and terrestrial MHP Terminals, while cable ones generally have a cable modem.
30th March 2006
The MHP-Guide Version: 1.0
Page 146 of 215
The <CPU/RAM/ROM> controls the whole operation, performs specific data manipulation functions and provide both volatile and non-volatile memory access. It generally uses a real-time operating system (RTOS) on top of a hardware abstraction layer for the management of the resources and processes of the MHP Terminal.
14.2.1 Hardware requirements INFORMATION This table below represents in function of each profile an approximation of
the hardware resource requirement.
Profile Used Processor (Mips)
Flash / ROM (MB)
RAM (MB) Other Requirements
Enhanced Broadcast
100-150 4-8 8-16
Interactive Broadcast
100-150 ca. 8 16-32 Return Channel
Internet Access
>150 8-16 >32 Return Channel
Table 14-1: Hardware resource requirements
The MHP specifications [MHPKDB-1] define a minimum hardware requirement for each version 1.0 / 1.1. In practice each manufacturer has a specific implementation so that the value presented above gives a range instead of precise values.
30th March 2006
The MHP-Guide Version: 1.0
Page 147 of 215
14.2.2 Conceptual view for Software architecture
EXPERT LEVEL
Figure 14-4: MHP terminal software architecture
In order to build the software architecture of a MHP Terminal, several software components, possibly coming from different software suppliers, are required.
Firstly, the <Hardware Abstraction Layer (HAL)>, the <Driver Layer> and the <Operating System>, providing access to low level resources of the MHP terminal, are generally coming from hardware vendors and/or drivers suppliers.
In most cases MHP terminals include the CAS/DRM vendor specific component <CAS/DRM> allowing to view non Free-To-Air content.
The biggest software part of the MHP terminal, often coming from a specific middleware vendor, includes the <FW Loader>, the <Middleware Implementation>, the <JVM>, the <MHP Implementation>, the <Native Applications> and the <Porting API>.
The <FW Loader> is a crucial part of the MHP Terminal, wherewith the MHP Terminal software can be upgraded later in the field. In particular, it can be used to upgrade MHP 1.0.2 compliant terminals with MHP 1.0.3 upgrade.
The <Middleware Implementation> provides several digital TV services allowing to support native applications (<Native Applications>) like EPGs (i.e. Electronic Program Guide) and the MHP specific middleware (<MHP Implementation>).
Although the <JVM> (i.e. Java Virtual Machine) is integrated with the <MHP Implementation> and the <Middleware Implementation>, this software component is generally coming from specific JVM vendors.
30th March 2006
The MHP-Guide Version: 1.0
Page 148 of 215
Middleware vendors define the <Porting API>. This part provides an abstraction of low-level hardware dependent software parts and allows the <Middleware Implementation> and others upper software components to be portable.
<MHP Applications> represent all MHP applications software code that can be downloaded and executed on the MHP Terminal. These applications are generally designed by specific MHP Application suppliers or directly by broadcast content providers.
You can find more details on the SW and HW requirements on the DVB-MHP web site (http://www.mhp.org) and a list of available MHP terminals on the KDB web site (http://www.mhpkdb.org).
14.3 Test equipment
14.3.1 IRT MHP Application analyzer
Scope INFORMATION The MHP Application Analyzer is a PC-based tool for performing
compliance checks and functional tests on MHP applications. It brings broadcasters and software developers into the position of performing in-depth analysis of their MHP applications.
After running the different Analyzing options, a detailed result protocol is provided that enables to locate bugs or critical areas in the application.
Functionality The Application Analyzer provides four different test analysis and test functions:
Configure and Run: In this mode, the Application Analyzer executes the application on the MHP without intervention. This function offers comfortable configuration and handling options.
Static Checker: The Static Checker analyzes the bytecode by decompiling it and evaluating all available information under the following aspects:
Java Bytecode Verification (Compliance with Java und VM Specification)
Compliance with MHP Standard (used classes, methods, etc.)
Compliance with Security requirements
Evaluation of used resources
Dynamic Checker: The Dynamic Checker analyzes the behavior of the MHP application under runtime conditions. The analysis comprises a manual functional check, compliance check, resource monitoring, stress test, profiling and others.
On Air Analysis: This provided the possibility to examine MHP Application broadcast on a DVB network with regard to DVB SI Data and signaling.
Availability The static checker of the MHP Application Analyzer is available for registered users of the MHP-KDB as a part of the virtual test centre of IRT. The Static Checker performs analysis of the java code with regard to
30th March 2006
The MHP-Guide Version: 1.0
Page 149 of 215
general errors as well as compliance checks against a particular MHP Standard version.
After uploading their bytecode in form of .jar-archives to the MHP-KDB server, users can choose between different MHP standard versions (currently MHP 1.0.2, 1.0.3, and 1.1).
Once started, the static analyzer parses the bytecode and writes the structure of the application (e.g. classes, methods, fields) in a temporary file. After parsing the application, the static analyzer analyses the temporary file for bytecode errors, warnings for unused fields/methods and MHP compliance errors.
The user is then provided with a final result protocol. Details about handling and operation of the Static Checker are given in the “IRT-Test Centre User Guide”.
The full Version of the MHP Application Analyzer can be purchased at Institut für Rundfunktechnik. For further information please visit their website at http://www.irt.de and choose “products”.
14.3.2 Return Channel analysis tool
Scope INFORMATION The Return Channel Analysis Tool is distributed software integrated into ITA’s Testing Environment. It offers MHP application developers reports of the performance of their applications in the return channel.
Functionality Description Once users have uploaded their application and configured the MHP playout via the web, they will be able to configure different test scenarios by selecting among the different alternatives that ITA’s Testing Environment offer:
Broadcast chain: DVB-S, -T or -C (in the first implementation, only DVB-S will be available)
Receivers: commercial STBs, PC based clients.
Return Channel: PSTN, xDSL, Cable or other access networks that may be implemented or emulated. It will also be possible to configure in detail some network parameters, such as downlink and uplink bit rates for xDSL and Cable networks.
ISP & Backbone network: The behavior of the ISP and the backbone network may be also configurable in order to emulate problems such as packet loss, bottlenecks or connection failures, so that the performance of MHP application in such situations can be evaluated.
After defining the test scenario, the user can select the measure points and the parameters to be reported after test execution. Eligible measures will be, among others, bandwidth usage, sent and lost packets.
During test execution, the tool collects the requested information at the selected points of the return channel segment using SNMP, process this information and report a detailed analysis, including graphics and statistics of the application performance in terms of network aspects.
The return channel reports along with other useful information from the testing environment (such as STB debug output) and a stream of the video
30th March 2006
The MHP-Guide Version: 1.0
Page 150 of 215
output of the selected MHP receiver is made available for the user via the web.
Availability The Return Channel Analysis Tool is integrated in the online test centre of ITA and available for registered users of the MHP-KDB website. To obtain return channel reports, users must run their interactive applications in this test centre.
14.3.3 AIT / DSM-CC Analyzer and Compliance Tool
INFORMATION Scope Panasonic provides an AIT and DSM-CC analyzer called Stream-Analyzer. The Stream-Analyzer extracts certain streams and tables of a transport stream and displays them in a tree on screen. The analyzer is able to:
Show the content of the tables PAT, PMT and AIT.
Show the content of the DSM-CC carousels.
Save the content of tables and DSM-CC carousels.
Check whether there are any inconsistencies in the signaling or in the DSM-CC carousels.
The analyzer is written in Java to provide a platform independent tool.
Functionality After program start the user can decide which transport stream he wants to analyze. The transport stream should be compliant with the DVB–S or DVB-T standard. Support of DVB-C is not guaranteed. After selecting the transport stream packets will be loaded and all services including AITs or DSM-CC carousels are shown with their application related tables and elementary streams.
Now the user has two different options. On the one hand, he can select an Application Information Table or a DSM-CC carousel from the list and request the content. In the case of AIT he will get a table that lists all information of the signaled applications like path, name, start modus, etc. In the case of DSM-CC carousel he will get a tree that shows all directories and files including in the carousel. Additional he has the possibility to save the different contents
On the other hand the user can analyze an AIT or a DSM-CC carousel. Among other things analyzing of an AIT will include the following:
Testing if the signaled DSM-CC carousel is available.
Testing if signaled class is available.
Check of the section layer.
Check if a class is auto start.
Check if only one class is auto start.
A DSM-CC carousel will be analyzed with respect to:
Availability of the gateway and all modules
Consistency of the directory structure
Other aspects.
30th March 2006
The MHP-Guide Version: 1.0
Page 151 of 215
Both analyzing an AIT and analyzing a DSM-CC carousel results in a test report stored in a HTML file and shown on the screen.
The user can select again and again AITs or DSM-CC carousels to analyze or to show them until he exits the application.
Availability The Stream-Analyzer is available for download in the tools-section of the MHP-KDB.
14.3.4 Loading Time Analyzer
Scope This tool from tComLabs allows measuring the time to start an MHP application. The start time is the time between the moment the application is asked to run and the moment the application is in the active state.
INFORMATION
Functionality An Xlet is written to do these measurements. The Xlet is in fact a special application launcher. It asks the application manager to load, initialize and start an Xlet and measures the time that the receiver needs to execute these tasks. The logger, written for the MHP-KDB code framework, is used to report the test results.
Availability The tool is accessible from the tools section of the MHP-KDB Portal. The required class files have to be downloaded and put in an object carousel. For detailed information please refer to the user manual that is provided with the tool.
30th March 2006
The MHP-Guide Version: 1.0
Page 152 of 215
15 Usability
Usability
Usability deals with the relationship between services and tools and their users.
The broad acceptance of interactive TV services depends on a variety of factors. A crucial one is that these services were tested with regard to their usability. Usability is to ensure that users understand the created services and users want to make use of them and know how to use them in the best possible way.
Usability is to ensure user-friendliness and –satisfaction, efficiency of use, and error prevention when working with an interactive service.
“Usability is a measure of the quality of the user experience in interacting with something.” (Jakob Nielsen)
Usability
When creating new interactive applications, the developer has to consider that the viewer still focuses on TV and that television is a medium for entertainment, while interactive applications are regarded as additional services. Watching TV is a passive activity, while iTV services require some action from the user. The spectator is not used to interact with his TV set except for switching TV channels and using the EPG and teletext.
In particular the MHP programmer must take into account legibility, layout and navigational aspects as well as the usage of colors in a well-advised and moderate way.
Aspect ratios are dealt with in detail in chapter 12 of this guide.
The Usability and Style Guide in the KDB provides more comprehensive information about these topics.
30th March 2006
The MHP-Guide Version: 1.0
Page 153 of 215
15.1 Layout and Design The basic formal structure of a screen surface is defined by the layout. It defines the different functional areas with respect to their position, size and conciseness as well as the relationship of the areas to each other. Moreover, it defines the arrangement and design of the single functional areas themselves. The layout’s function is to provide a visual system making it easier for the user to understand the application and to be able to find his way through it. Thus the layout is specifically based on the laws of design.
Figure 15-1: Typical Screen Structure of an MHP Application
Figure 15-2: Basic Formal Structure of a Screen Surface
30th March 2006
The MHP-Guide Version: 1.0
Page 154 of 215
15.1.1 As much as necessary, as little as possible The extent of the functional area and the display area to be displayed by the layout depends on the complexity of the application. The goal should always be to use as few elements as possible and to develop a simple layout. The fewer elements the user has to observe, process and learn, the better.
15.1.2 Consistency The developed layout scheme should be applied to all the pages of an application or the bouquet if possible. This is the only way the user can find his way quickly and easily. There can, of course, be an alternative layout in some specific areas or a consciously created interruption of the layout at specific pages. Interruptions of the individual layout scheme should be consciously used as a stylistic device in order to irritate the user, to misbalance him and to gain more attention to some specific pages. These kinds of interruptions only work though if the user was made aware of a stringent and consistent layout scheme until the disruption actually takes place. If this is not the case, the whole page is entirely disruptive and the visitor will sooner or later give up finding his way through the site [Noss 2003].
15.1.3 Screen Layout
Figure 15-3: Layout of a TV Screen
Research indicates that viewers scan television screens from the upper left corner down to the lower right. This behavior is stronger with text heavy interactive applications than with conventional broadcast because reading habits come into play.
Because viewers exhibit the same eye movements in general, we know that the upper left and lower right areas of the screen are privileged - perfect for titles and logos, while the upper right and lower left are dead spaces, in which objects and images are unlikely to be noticed. Combining text, quarter-screen video and photographs can affect the viewer’s interpretation of screen elements. In general, video and text content will be perceived separately. Lengthy text content next to video will be ignored.
Titles and logos should go in the upper left corner for maximum impact.
Video sits most comfortably with text when placed in a dead area upper right or lower left Navigation information related to the title (such as a crumb trail) should ideally be positioned next to the title. Static information such as time and date is least obtrusive in the dead areas of the page.
30th March 2006
The MHP-Guide Version: 1.0
Page 155 of 215
Universal navigational tools should be positioned at the bottom of the page where the eye finishes reading [BBC, 2002].
15.1.3.1 Organize the Screen
Figure 15-4: Screen Organization
The left hand side is always privileged by European reading viewers. For text services, stories should be positioned in the left side. For quarter screen enhancements to video programming, the video should be on the left hand side instead.
Use the top for navigational information about the current page content, such as crumb trails.
Story title and content navigation must be physically part of the content space
This area of the screen is high visibility and should not be used for general or repetitive help instructions
Video tools and navigation can be located in an overlay over the bottom of the video or in the space immediately underneath
Service wide instructions, color key prompts and helpful general tips belong in the bottom of the screen
Instructions to turn the page or scroll through text content or a table should always be placed at the bottom of the text/table, where the eye finishes reading and looks for more
Every service is different and presents unique challenges and layout requirements. The most important rule to remember is consistency.
30th March 2006
The MHP-Guide Version: 1.0
Page 156 of 215
15.2 Navigation Good navigation means building a relationship between a visual interface and the tools a viewer uses. The relationship is good if it supports the viewers’ goals and desires in using a service, and not so good if it creates additional obstacles to the viewer [BBC 2002].
To help the viewer, every navigational interface must aspire to several key objectives:
Tell the viewer where they are, how they got there, and where they can go next at any time
Provide feedback every time a viewer executes a command
Teach the viewer how to use the service in seconds
Relate to larger cultural mental models and metaphors
Present predictable and consistent navigational devices
Encourage freedom of movement rather than limited predetermined paths, and provide quick escape in the form of an exit route, or near-instant access to full screen video.
15.2.1 Remote Control Units
Figure 15-5: Remote Controls of MHP Terminals
Viewers use remote control units (in some cases extensive keyboards) to make choices within interactive television services. Good navigation is about providing a user interface that seems to instinctively teach the viewer how to make the right choices by pressing the right buttons. In an ideal world all viewers would have the same controls available to them and interfaces could develop a standardized visual language. However, controls differ enormously between - and often within - platforms. The layout and
30th March 2006
The MHP-Guide Version: 1.0
Page 157 of 215
labeling of keys on the remote can vary, or keys can be missing entirely [BBC 2002]. Several functional groups of keys are, however, generally available:
Traditional television controls
Number keys
Arrow keys and a select key
Color (Fastext) keys
Additional platform specific controls.
15.2.1.1 Traditional Television Remote Controls Most set-top box remote controls incorporate keys to change television channel, adjust the volume, and turn the power off and on. These keys are not remapped to new functions within interactive applications. Once an interactive application is launched, all of these functions should be available to the viewer as usual. Several keys exist on remote controls for both traditional and digital televisions, with slightly different uses. On analogue televisions, the text key provides access to Ceefax, Teletext and other analogue text services. On digital platforms it launches a digital application which provides a similar but further customized service. Many standard television remotes have an Info key which brings up an on screen display. On digital televisions the Info key can be remapped to bring up relevant additional information [BBC 2002].
15.2.1.2 Platform Specific Controls Several remote controls have useful features that are not universally available across all platforms. In some cases, for applications that are specific to a particular platform and which have guaranteed access to these extra features, the following keys can simplify the interface. Sometimes keys can be remapped to application-specific functions, but generally they can and should be used only as specified by the platform owners. For any applications that are available across several platforms, interfaces must be designed to take advantage of each, while ensuring all content is available to viewers on all platforms. Although some of these keys are useful, user testing indicates that viewers look for controls within the screen interface, or for onscreen prompts. Viewers may not realize that special keys on the remote can be used within an application [BBC 2002].
Common Examples are:
Back Up (Back): can be hierarchical or historical (taking users up a level or back to the previous page), available on most platforms, but not on terrestrial
Help: useful key that satellite viewers are accustomed to pressing for help text across all services
Exit: a key that quits an application and returns the viewer to standard broadcast on terrestrial
Page Up/Down: these keys scroll through content which is too long to fit on a single page standard on cable and with systems for viewing the web on TV
Previous/Skip: these keys move from one item to another and can be used instead of the arrow keys available on cable and with systems for viewing the web on TV
30th March 2006
The MHP-Guide Version: 1.0
Page 158 of 215
Full Keyboards: allow the user to enter text available on most platforms as an option.
15.2.2 Interaction Design
Figure 15-6: Functions of a Remote Control
The MHP specification defines a minimum set of input events. These input events define the MHP mandatory keys that have to be available on the user input device of the MHP terminal (cp. Table 15-1).
Input event Keys on the input device of the MHP terminal
VK_0 to VK_9 10 number keys
VK_UP
VK_DOWN
VK_LEFT
VK_RIGHT
VK_ENTER
4 arrow keys
+
1 select key
VK_TELETEXT 1 key to access teletext
VK_COLORED_KEY_0
VK_COLORED_KEY_1
VK_COLORED_KEY_2
VK_COLORED_KEY_3
4 color keys
Table 15-1: Mandatory keys in MHP
30th March 2006
The MHP-Guide Version: 1.0
Page 159 of 215
Accordingly the MHP environment offers three possible ways of interaction:
by number keys [a]
by four color keys [b]
by four arrows keys and select keys [c]
With the aid of color and number keys, the direct selection of functions can be performed. The navigation via arrow keys is suitable for the indirect selection of functions via menu lists as well as for the skipping between menus and paging. Be careful to apply as little as possible of the three methods on one screen at the same time [BBC 2002].
Readability refers to the comprehensibility and the joy of reading of a text.
LEGIBILITY vs. READABILITY Legibility means that writing can easily be deciphered and read. 15.3 Legibility of Text
Text poses difficult challenges on television screens, as viewers are not accustomed to reading static blocks of text on screen and because the display quality of still images on television is poor [Noss 2003]. Careful attention also has to be paid to character shapes, to help distinguish similar letters (such as upper case, lower case and the numbers) and to help with the characters most commonly misread by the visually impaired (such as 6, 8 and 9).
Several rules can improve legibility on a TV screen:
Body text should generally not be smaller than 24 point
The text should under no circumstances be smaller than 18 point
Light text on a dark background is slightly easier to read on the TV screen
Text on screen needs greater line spacing than in print
A full screen of text should contain a rough maximum of 90 words
A generally accepted practice is not to use more than three different fonts
Be consistent in the use of fonts, e.g. use the same font for every headline, the same font for text blocks, etc.
15.3.1 Legibility Examples Here is a collection of positive and negative legibility examples:
30th March 2006
The MHP-Guide Version: 1.0
Page 160 of 215
Figure 15-7: Legibility Example 1
The font size in this sketch text is too small. The text field is very wide which causes long lines. The line break, causing a change for the eye from the end of one line to the next line, is favored by the large line spacing but it is still difficult for the eye to perform. Thus this sketch text is difficult to read. In order to improve legibility, the font size should first be enlarged. Then, perhaps, line spacing and line length could be corrected.
Figure 15-8: Legibility Example 2
30th March 2006
The MHP-Guide Version: 1.0
Page 161 of 215
In this script text the 18pt font size is well chosen. The text field is very wide but due to the large font the line spacing is agreeable and the line break from the end of one line to the beginning of the next line can be performed very easily. The text is well legible.
Figure 15-9: Legibility Example 3
In this script text the18pt font size is well chosen. The text field is very wide but due to the large font the line lengths are agreeable. The line spacing is too small though. This makes the text look quite packed and the line space is difficult to perform. The text is only legible to a certain extent.
30th March 2006
The MHP-Guide Version: 1.0
Page 162 of 215
Figure 15-10: Legibility Example 4
In this script text the 18pt font size is well chosen. The text field is narrow but the line lengths are acceptable. The line spacing is relatively small but due to the small lines the line skip can be performed easily. The text can be read easily. The text uses almost two thirds of the surface. Thus on the left side a piece of negative space is created meaning that surface is not used. This is used in the upper part for the heading. A very calm and clear overall picture is created. This is also due to the alignment of the text block and the heading with the subtitle at the lower edge of the screen.
15.4 Recommendations for Using Colors Use colors only as a supporting device for highlighting information and not as the only device for coding because correct color reproduction or color perception cannot always be guaranteed. Some people have problems distinguishing between colors. Use little color as to not burden the user with a visually overloaded surface on the one hand and to guarantee that the colors used are sufficiently distinguishable on the other. The more colors you use, the more information the user has to assimilate and the less valuable and concise the single colors become. Certain combinations of extreme colors should be strictly avoided. Television screens have a more limited overall gamut than computer monitors and a much higher gamma value, resulting in a high contrast, high saturation display. To achieve similar intensity of color, images should be toned down and simplified when taken from the computer to the television. Hot reds and oranges cause particularly bad distortion and pure whites and blacks should never be used. The strongest white for display on a television should be around 95 percent, or 240/240/240 in RGB terms. The darkest black conventionally used is 5 percent, or 16/16/16. Strong color changes along scan-lines cause a variety of distortions known as bleed or color shift. The change from one strong color to another can cause overlap-ping strips to appear, or a double exposure ghosting effect. With irregular shapes such as words
30th March 2006
The MHP-Guide Version: 1.0
Page 163 of 215
of text, color shift can cause spots or glows around bright objects. Because these effects occur across the horizontal scan lines they are especially pronounced at the vertical boundaries of objects. Intricate patterns should be avoided as well. Moiré distortion is common on television sets when regular patterns such as grids or dots are rotated away from true vertical. Curves distort less than straight lines, and movement diminishes the impact of all television display problems [SN HESS].
Figure 15-11: Examples of color combinations with poor legibility
15.5 Usability Studies and User-Centered Design Successful services can sometimes be created by using usability rules of thumb and trying to anticipate the user’s behavior. But experience shows that users often do not accept what they are offered, because the user needs were predicted wrongly. Much of the risk that lies in launching a new service can be mitigated by using a user-centered design approach. It is important to incorporate the feedback as well as the creative potential of the later user as early as possible in the service design process.
It is often argued that the user cannot tell what he wants, because he does not know what is possible with the new technology. This holds true only partly. With the use of appropriate questionnaires the user can give us hints:
What he does not want in a service
Which functionality he would add to the service
Which desires he has with respect to mobile communication
User-centered design is an iterative process, which involves several cycles of conception and reworking of the service concept. In most cases, the final result is a good deal away from the original scenario, which should be consequently modified or even replaced according to the user comments. The simplest way to incorporate user comments for every service launch is to perform a usability study on a full-grown prototype and improve the user interface accordingly. However user-centered design from scratch looks different:
1. Invent a scenario
2. Have scenario commented by a user group
30th March 2006
The MHP-Guide Version: 1.0
Page 164 of 215
3. Rewrite or replace scenario
4. Repeat step 2 and three until a satisfying level of agreement is reached
5. Design a clickable prototype
6. Evaluate the prototype with a professional user group not involved in the project
7. Refine the prototype
8. Make usability study with target user group
9. Refine the prototype
10. Repeat step 8 and 9 if necessary
11. Implement service
12. Test service under real life conditions with target user group
13. Refine interface if necessary
14. Repeat 12 and 13 if necessary
15. Final service Launch
This guideline is only an example to emphasize that the user has to be integrated in the process in every phase of the service development. The key principles of User-Centered Design are listed by Gould and Lewis [Gould 1995]:
Early Focus on Users and Tasks First, designers must understand who the users will be. This understanding is arrived at in part by directly studying their cognitive, behavioral, anthropometric, and attitudinal characteristics, and in part by studying the nature of the work expected to be accomplished.
Empirical Measurement Second, early in the development process, intended users should actually use simulations and prototypes to carry out real work, and their performance and reactions should be observed, recorded, and analyzed.
Iterative Design Third, when problems are found in user testing, as they will be, they must be fixed. This means design must be iterative: There must be a cycle of design, test and measure, and redesign, repeated as often as necessary.”
There are various methods to perform user validations, all varying in effort and quality of the result, e.g.:
Thinking aloud method A basic method of usability study where test users use a service prototype or implementation and comment everything they think and do aloud. These comments are recorded, compiled and compared in order to find relevant weaknesses of the service.
Questionnaires and interviews
30th March 2006
The MHP-Guide Version: 1.0
Page 165 of 215
Test users use a service and fill in a prepared questionnaire afterwards. It is important to have some open questions in the end in order to get hints on hidden problem areas the editor of the questionnaire did not consider. This kind of evaluation can also be performed as a guided interview.
Eye-tracking systems Eye-tracking is a very effective method to discover discontinuities in the user interface layout. It tracks eye movements and can reveal even short subconscious irritations that the test user would not remember or find worth mentioning.
Camera recording The test user is given a number of tasks to fulfill while using the service. The success and speed in solving these tasks is measured. The video recording is also a good way to visualize usability problems to all groups involved in the development process.
Heuristic analysis This involves usability experts that examine services according to known usability problems and give recommendations.
For good results especially on usability the user should be given a number of pre-defined tasks. The results such as speed of execution are then used as an empirical base which enhances the individual subjective judgments by the users.
Further information on the topic and state-of-the-art methodology can be found on the website of the Institute for Mobile Markets Research in Atlanta (http://www.immr.org). Different usability guidelines can be found on Jakob Nielsen’s Website http://www.useit.com.
30th March 2006
The MHP-Guide Version: 1.0
Page 166 of 215
16 MHP Outlook This chapter provides an outlook on the future potential of MHP. Part one focuses on technical aspects by describing the relevant current and upcoming updates of the standard. Part two provides a short overview of commercial aspects.
16.1 Technical aspects From the start, MHP has proven that it is fit for the future: Since version 1 came into the market, the standard has been continuously updated with additional functions such as a recording API, reading TV Anytime metadata, or support for SmartCard reader interfaces, to name just a few. It has shown its potential to adopt and integrate new technical components accommodating both upcoming technological and market needs.
Combined with technical integration work, this MHP standardization process has proven that MHP is ideally suited as a means to allow open access to all kinds of new and upcoming decoder components like hard disc, SmartCard reader or broadband Internet access.
By integrating further additional components and offering them to service providers, MHP is currently broadening its service potential far beyond “classical” interactive services like EPGs, news tickers or quiz shows. As described below, this concerns quite a number of new and relevant technical features like IP transmission networks or new coding formats.
The growing technical potential makes interoperability even more urgent and hence increases the need for MHP as the universal interface.
16.1.1 DVB over IP / IP tuner With the developing broadband technology and propelled by a fierce competition in the telecom market, telecom operators have started to deploy TV over IP (Internet Protocol) services on a large scale. DVB standard for the
transport of DVB services over IP networks.
First published in March 2005 as ETSI TS 102 034
DVB-IPI
DVB has consequently anticipated the definition of a standard for broad-cast of DVB services over bi-directional IP networks, resulting in a first standard DVB-IPI available at ETSI. Its current version addresses transport of MPEG2 DVB services encoded with MPEG2 technology and encapsulated in MPEG2 TS, to cover mainly the following services:
Live media broadcast
Content on demand (COD) such as music and video
DVB has already specified in the DVB-IPI standard a mechanism for service discovery and selection (SD&S) for DVB MPEG2 based A/V services over bi-directional IP net-works and is currently continuing work on the broadband content guide (BCG) as and additional standard and on extending the first version of the DVB IPI standard.
MHP has already supported all main broadcast protocols such as DVB-S, DVB-T and DVB-C, but needed an extension to fully support the IP front-end. Therefore commercial requirements were created within the scope of DVB and currently, the DVB technical working groups develop the technical standardization for the ‘MHP IP tuner’.
30th March 2006
The MHP-Guide Version: 1.0
Page 167 of 215
This MHP IP tuner specification will address both devices merely containing a broadband IP interface and also hybrid devices containing a broadband IP network interface as well as a classical DVB interface (cf. Figure 16-1).
Telecom 0perator’s network
IP network (e.g. ADSL)
TV over IP
For hybrid IP STB: Optional DVB-S, DVB-T, DVB-C
Figure 16-1: Example of an IP STB
Key benefits for IPTV network operators will include:
The rise of a competitive market in middleware suppliers while retaining compatibility for content and interactive applications.
The potential to deploy rich and complex applications while minimizing the need to fall back on the original device manufacturer for additional native code extensions.
Taking advantage of an "always on" interaction channel for advanced technical and business potential
The IP tuner specification is expected to be available in the second half of 2006.
16.1.2 IP over DVB INSTINCT ProjectEU funded research project. Committed to realising the commercial provision of convergent services in mobility with a special focus on DVB-T, DVB-H and DVB-MHP. (www.ist-instinct.org)
FLUTE Protocol for File delivery over unidirectional Transport
As IP broadcast emerges, MHP applications and content using this technology are being developed. INSTINCT, an EU-project, offers a current approach as described below (cf. http://www.ist-instinct.org).
The underlying application retrieval mechanism had to be as transparent as possible to the application itself. Therefore the idea was to imitate the carousel realized with DSM-CC over DVB-C/T/S. The IP broadcast protocol of choice was FLUTE which can be used for iterative broadcast of files and file sets. Similar to DSM-CC, it allows altering the frequency and data rate with which distinct files are being sent. In order to allow for “easy” access of the files for the application, received files are just copied into the DSM-CC carousel cache. As INSTINCT uses a Linux-PC platform running IRT’s middleware for iTV, this translates into configuring the terminal’s FLUTE-Client to use a destination directory below the DSM-CC root directory.
Yet, unlike in the case of DSM-CC Object Carousel, here the contents are not visible in the directory until downloading has been finalized. This implies that for content access, the application needs to know from another source which files are to be downloaded. This information can be hard coded into the service or rather be encoded in an electronic service guide (ESG). Letting aside the matter of the service signaling itself, applications can communicate with the FLUTE client on the terminal through an API,
30th March 2006
The MHP-Guide Version: 1.0
Page 168 of 215
which has to be implemented as an extension to an existing MHP stack. The major difference between using DSM-CC or FLUTE is that the FLUTE implementation needs the application to ask for download before accessing any file on the carousel. A listener notifies the application of the completed download. A solution that completely mimics the behavior of the DSM-CC API, however, would also be feasible.
IP-broadcast enables new types of push services. The terminal FLUTE client can be set to a constant listening mode, scanning the FLUTE channel for alert notifications. These notifications are short XML messages in RSS format (any other format would also be possible) that are filtered on the terminal according to content description parameters. The application can add a listener to the FLUTE client in order to get notified of received alerts, which may then be displayed in the desired way. An example of a push service prototype making use of this feature will shortly be available on the website of RBB37.
INSTINCT used a terminal-resident navigator application along with an XML-ESG for signaling and starting services. In a system relying fully on IP-broadcast, a common format of the ESG remains to be agreed upon.
16.1.3 Personal Digital Recorder (PDR) There is an increasing demand for recording programs or parts thereof. Personal Digital Recorders (PDR) based on hard disk video recording have been available on the market for some time now. In order to open the full potential of MHP for that market and to allow new service ideas based on combinations of interactivity and recorded programs such as personalized TV experiences, DVB has prepared a proposal for an extension of the MHP specification for the necessary extensions and interfaces. This proposal takes into account the recording concepts developed by the TV-Anytime forum and it is available as DVB bluebook A087, not yet as an ETSI standard.
The specified interfaces provide the following functions:
Scheduled recording (time, duration and channel)
Time shift recording (recording of current program with “pause” and instant reviewing controlled by MHP “navigator”)
While the specification defines the basic requirements for the recording engine, detailed functionalities will depend on what has been implemented in the respective terminals.
The decoder internal recording application can identify the event to be recorded by the specified TV-Anytime CRID combined with the DVB locator as used in MHP. The application will then:
Search the list of recordings and recording requests
Track and manage the recording
Play complete recordings
It offers time-shift recording and allows interrupting live programs for instant replay.
37 http://www.rbb-online.de/_/unternehmen/beitrag_jsp/activeid=254/key=teaser_300427.htm
www.tv-anytime.org
TV-AnytimeForum to develop specifications supporting local storage of A/V content
30th March 2006
The MHP-Guide Version: 1.0
Page 169 of 215
It furthermore allows for switching the time-shift on/off, checking the size of the time-shift buffer, and also enables random access within the disk buffer.
Application signaling was extended in order to cope with some aspects critical for the recording of applications. This includes marking applications as “critical to store”, “optional to store” or “not to be stored”. Another aspect is how applications shall be dealt with in the case of trick mode playback.
Finally, the specification considers broadcaster security by specifying if and how content may be used by other broadcasters.
16.1.4 HDTV Digital TV user experience is greatly enhanced by High Definition (HD) which is already being deployed: Offering up to five times the spatial resolution of a classical Standard Definition (SD) program, HD content provides the best video image quality ever seen in digital TV. This obviously calls for enhancing rendering of MHP applications for presentation on HD displays in order to keep MHP an attractive tool in the HD market.
However, the design of adaptable MHP applications for different screen resolutions and aspect ratios raises will be a challenge.
Currently deployed MHP 1.0.3 and MHP 1.1.2 applications are dedicated for 720x575 screen size TV sets. HD TV sets support higher resolutions: HD Ready TV sets, identified by the logo depicted in Figure 16-2 provide a displayable area of 1280x720 or 1920x1080.
Figure 16-2: HD Ready logo defined by EICTA for HD equipment
MHP 1.1.2 includes support for HD video and HD graphics. The support for HD graphics as included in the standard may be revisited depending on market feedback, i.e. if the specification should prove too demanding or expensive. It is expected that the MHP 1.1.2 test suite will include tests for basic operation of MHP + HD receivers.
It will be important for HD deployment to limit interoperability issues (applications – MHP terminals – TV sets). Guidelines for application writers would therefore be helpful to have, DVB, however does not plan to provide such guidelines.
16.1.5 MPEG4 / H.264 The new compression standard H.264 is used to reduce bandwidth - as compared to MPEG2 - and is currently being implemented in a number of markets. For standard SD transmission, H.264 is planned to be used in DVB-T networks in France, furthermore H.264 is going to be used for many
30th March 2006
The MHP-Guide Version: 1.0
Page 170 of 215
IPTV networks (e.g. all known ones in Germany) and most HDTV broadcasts. H.264 is also called MPEG4 part 10 / AVC.
In order to facilitate transition to this new codec for broadcast services, DVB has defined new SI/PSI values. The existing MHP 1.1.2 standard version already includes optional support for H.264.
Only MHP applications which intend to make use of the new SI/PSI information in order to provide corresponding video control functions will have to be updated.
Impact on MHP middleware is limited due to the fact that whatever the codec is that is used for compression; a service will still be identified by its DVB Locator.
16.1.6 DVB-S2 Similarly to the video codecs, the DVB-S modulation has been supplemented by DVB-S2 which offers more bandwidth and new degrees of flexibility. Despite from the fact that more bandwidth means also more data capacity that can be used for MHP applications, we expect that this new standard will neither have impact on MHP specification itself nor on already deployed MHP applications. However, new MHP terminals and broadcast equipment need to support this standard if they are to receive DVB-S2 broadcasts.
16.1.7 Object Tracking Object tracking is a feature which allows enhancing quite a number of betting, shopping or gaming services. By tracking and marking one or more objects on the TV screen, specific interaction options can be tied to these objects (e.g. “select the tool you would like to buy”, “guess which player will make the next goal”, etc.).
The objects can be tracked by software or specific hardware extensions in the studio and the positioning data is transmitted via stream events or private sections in near real time.
An example of a commercial implementation of such a system can be found at the TeleClix website38. Figure 16-3 contains a screenshot with an example for object tracking in a sports program.
Figure 16-3: Example for object tracking
38 http://www.teleclix.com/Products_&_Services/TeleClix_LiveLink_system/ENG
General Media Framework for interactive TV
EU funded research project
GMF4iTV
First published in March 2005 as ETSI EN 302 307
DVB-S2 Advanced DVB satellite modulation
30th March 2006
The MHP-Guide Version: 1.0
Page 171 of 215
The project GMF4iTV has developed advanced concepts for interaction with moving objects in normal TV programs extending the existing features of DVB-MHP. The interaction is based on tracking certain objects in an MPEG-2 video and generating dynamic metadata in the MPEG-7 format, describing the actual position and shape of the objects, and broadcasted in sync with the MPEG-2 video. MHP is using these metadata to highlight the objects by graphical rendering, which is done synchronized with the MPEG-2 video. A normal remote control can be used to select the object by pressing the color button, which matches the object. Alternatively a PDA can be used as an advanced remote control, where the object can be selected by touching the highlighted object. Then additional information can be retrieved about this specific object, which may consist of MPEG-4 A/V-clips, MHP-applications, pictures and HTML-pages. This additional content can be presented to the viewer also in personalized form, based on metadata and user profiles.
PDA Personal Digital Assistent
This example shows that there is still room for further technical development and standardization effort as the market and the business models develop over time.
16.2 Commercial aspects
Figure 16-4: MHP situation in the world in August 2005 [MHP_ORG]
16.2.1 DVB-MHP in Europe While a small number of countries have already started to broadcast regular services based on MHP, many countries are running trials or are planning to do so.
DVB-MHP is today the only open standardized API and the implementation of MHP is recommended by the European Commission (EC).
It is not likely that EC will mandate MHP as the only API to be implemented in Europe, but it is the only full API that is noted in the official list of recommended standards. A new EC document on the status on MHP is
30th March 2006
The MHP-Guide Version: 1.0
Page 172 of 215
expected until spring 2006. This will be mostly based on information gained at the meetings in the EU MHP Implementation Group.
One problematic aspect of the implementation of MHP is that the license costs are still not finally approved, and there are still some principle discussions concerning the basis for these costs. Additionally, it is also an issue how to cover the costs for development of the MHP Test Suites.
Both cost aspects have to be solved rather soon.
Another problem is that the full MHP specification is complex and offers different ways to implement certain applications. This leads to the fact that proper testing is required in order to achieve good interoperability between all applications and all versions of MHP terminals. The dynamics of development in the SW and HW domains make this interoperability difficult to manage and maintain in a horizontal business context where content providers / broadcasters and manufacturers policies are driven by interests that may be in conflict and not focused on the business performance of the system.
The main problem so far does not seem to be the technical platform for interactive services itself, but how to get the public attracted to these services so that they will buy the STBs at some higher price than the pure “Zapper” versions, and start to use the services.
It will be an important issue to introduce interactive services and to get the audiences acquainted to them in order to get the related business models working.
Despite these remaining questions it is likely that most of the organizations in Europe, that are going to start with interactive services, will do this based on MHP. As outlined above, MHP is flexible to support many current and future service (and business!) options.
Following the positive experiences made in Italy (cf. 3.6.7) Austria has decided in 2005 to select a very similar business model: MHP shall be the API to be used in the DVB-T market and decoders shall be subsidized. In Germany, broadcasters will use the DVB-IPI standard and MHP to distribute their broadcast services including interactivity via IP DSL networks. Here the DVB system can prove its benefits also in non broadcast IT networks.
Furthermore, the BluRay consortium has chosen MHP as interactivity tool for their HD DVD system. Once more this shows how flexible MHP can be used to open new fields of application and constitute a universal “key” component in many markets still to grow and still to detect.
In order to support markets which still use proprietary APIs, DVB has specified a Portable Content Format (PCF) for a common authoring for different APIs. This standard can help to ease the migration process from one of the other APIs to MHP. More information concerning such migration processes can be found in [].
PCF Portable Content Format
A lot of dedicated companies are now developing MHP based services and these services can be bought for implementation in an open market.
Proprietary iTV platforms in Europe In the early days of interactive TV in Europe a number of proprietary platforms were deployed which are partly still competing with MHP:
30th March 2006
The MHP-Guide Version: 1.0
Page 173 of 215
Open TV is used by BskyB and several other operators in Europe and is also implemented by many operators in the rest of the world. It will therefore be in use for many years ahead.
MediaHighway was developed by Canal Plus Technology, and is now one of the products from NDS. It is not so widely used and there does not seem to be any further development of it.
Liberate is not much used in Europe anymore, mainly by Cable-TV networks in UK. It is not expected to be a competitor to MHP. The Liberate system is based on extensive communication via interaction channel with servers in the network.
NDS has introduced a MHP based API with some proprietary other elements in it. If MHP will be as widely used as expected, it is likely that NDS will leave the old MediaHighway behind and go fully for the MHP based version.
The terrestrial platform in UK is still running MHEG-5, which is open and standardized, but a “Presentation Engine” and not a complete API. Both the MHEG-5 and the MHP specifications are now modified so that a MHP based STB can in the future execute MHEG-5 based services.
16.2.2 DVB-MHP in the rest of the world MHP originally is the standard for interactivity within the DVB system and in several aspects linked to specifities of the DVB-S/-C/-T systems. In order to make MHP more generally applicable, DVB has also produced another version of the MHP standard named Global Executable Multimedia Home Platform, GEM.
Global Executable Multimedia Home Platform
GEM GEM was created to enable organizations (e.g. US CableLabs) to define specifications based on MHP together with DVB. It has the following goals:
To maximize interoperability between GEM based specifications from different organizations.
To maximize the presence of MHP components, enabling economies of scale for the whole interactive broadcast chain.
To take into account local business and technical constraints.
GEM is not a stand alone specification that can be directly implemented, but a framework to be used by those organizations that wish to define specifications based on MHP. Additionally, the design rules of the GEM specification enable content authors to write applications that can be directly interoperable across different GEM based receivers.
The GEM specification lists those parts of the MHP specification that have found to be DVB technology or market specific. It allows these to be replaced where necessary as long as the replacement technology is functionally equivalent to the original.
The set of technologies where functional equivalents are allowed is negotiated as part of the technical dialogue between DVB and each of the organizations wishing to use GEM.
Additionally, the GEM specification contains a list of those other specifications with which it can be used.
Gem 1.0 was published in February 2003 and contains links to “CableLabsOpenCable”.
30th March 2006
The MHP-Guide Version: 1.0
Page 174 of 215
DVB is currently working with ATSC in order to finalize the inclusion of the GEM core into the US system environment of digital television: Advanced Television
Systems Committee. Preparing US TV standards.
ACAP Advanced Common Application Platform
ATSC
ACAP (Advanced Common Application Platform) the middleware specification based on GEM, was recently approved by the ATSC. With trial services already on air in Korea, where the ATSC system is used for digital terrestrial television, this approval clears the way for the growth of interactive services in the USA, with harmonized standards across the cable and terrestrial markets. OCAP developed by CableLabs for the American cable market, is also based around the GEM core.
ATSC previously published a companion Standard A/96, “Interaction Channel Protocols”.
Used in combination with forward broadcast channels from terrestrial, cable and satellite networks, these protocols provide a complete interactive system.
Overall Conclusions There is today no other open standardized API that can be
implemented in Europe. Even though DVB-MHP is not mandated by EC, it is recommended as the API to be implemented in the member countries.
Most of the European countries starting with digital TV and Interactive services are implementing MHP.
In the rest of the world it seems that MHP based solutions will be implemented by use of the GEM standard in many markets.
30th March 2006
The MHP-Guide Version: 1.0
Page 175 of 215
17 Glossary and abbreviations
24/7
Twenty-four-seven. Availability round the clock (Twenty-four hours a day, seven days a week).
3G
Third Generation. Mainly used in the context of mobile communication networks.
ACAP
Advanced Common Application Platform: It is a middleware specification based on GEM.
ADSL
Asymmetric Digital Subscriber Line. Enables faster data transmission over copper telephone lines than a PSTN modem, usually several Mbit/s
AIT
Application Information Table. Table defined by MHP to provide basic information about MHP applications.
Alpha Channel
An alpha channel is additional information in a picture file that determines the transparency for every pixel.
API
Application Programming Interface. The publicly accessible surface of software classes through which applications operate upon the specific functions contained within the MHP.
ATE
Automated Testing Environment. In the context of MHP meaning an environment to automatically run all the many tests included in the official MHP Test Suite.
ATSC
Advanced Television Systems Committee. Preparing US television standards.
A/V
Audio/Video
AWT
Abstract Window Toolkit
30th March 2006
The MHP-Guide Version: 1.0
Page 176 of 215
BAT
Bouquet Association Table. Table defined by the DVB specification for Service Information. Providing information which DVB services belong to a certain bouquet.
BIOP
Broadcast Inter-ORB Protocol
CA
Certification Authority (in DVB MHP PKI context) or Conditional Access
CAS
Conditional Access System
CAT
Conditional Access Table. MPEG2 defined table to provide information on the type of CA system used in a broadcast stream.
CDC
Connected Device Configuration
CLDC
Connected Limited Device Configuration
CI
Common Interface. Interface based on PCMCIA which allows to connect external CA modules to DVB decoders.
CLUT
Color Lookup Table. In the context of DVB a predefined table which maps the true color space of MHP applications to the possibly limited color space of MHP terminals.
CMS
Content Management System
COD
Content On-Demand
CORBA
Common Object Request Broker Architecture
CRC
30th March 2006
The MHP-Guide Version: 1.0
Page 177 of 215
Cyclic redundancy check, a type of hash function used to produce a checksum, in order to detect errors in transmission or storage
CRID
CRID is a concept from the standardization work done by the TV-Anytime forum. A CRID or a Content Reference Identifier closely matches the concept of the Uniform Resource Locator or URL, made famous by the stunning success of the World-Wide Web:
A unit of content, in a broadcast stream, can be referred to by its globally unique CRID in the same way that a webpage can be referred to by its globally unique URL on the web.
Thus, it should come as no surprise that a CRID is specified much like URLs. Typically, the content owner will use their DNS-names in a combination with a product-specific name to create globally unique CRIDs. As an example, let's assume that BBC wants to make a CRID for the upcoming Olympics in China. It may look something like this
crid://www.bbc.co.uk/olympics/2008/
Then, to refer to a specific event - such as the women's shotput finale - they can use the following inside their metadata.
crid://www.bbc.co.uk/olympics/2008/finale/shotput/women
CRL
Certificate Revocation List: Contains a list of certificates that have been revoked prior to their date of expiration.
CPS
Certification Practice Statement
CSS
Cascading Style Sheets
CW
Control Word. In the context of DVB CA systems the bit pattern controlling the scrambling and descrambling algorithm.
DAVIC
Digital Audio Video Council: A worldwide association of bodies concerned to promote interoperability in audio visual equipment of all kinds concentrating on standardized interfaces.
DECT
Digital Enhanced (former European) Cordless Telecommunications: It is an ETSI standard for digital portable phones, commonly used for domestic or corporate purposes.
DFC
Decoder Format Conversion
DGTVi
30th March 2006
The MHP-Guide Version: 1.0
Page 178 of 215
Italian platform for interactive TV using MHP.
DHCP
Dynamic Host Configuration Protocol
DNS
Domain Name System: It is a system that stores information associated with domain names in a distributed database on networks, such as the Internet.
DOM
Document Object Model. A description of how a HTML or XML document is represented in an object-oriented fashion. DOM provides an application programming interface to access and modify the content, structure and style of the document.
DRM
Digital Rights Management
DSM-CC
Digital Storage Media Command and Control: A format for transmission of data and control information in an MPEG-2 private section.
DTD
Document Type Definition
DTT
Digital Terrestrial Television
DTV
Digital Television
DVB-ASI
Digital Video Broadcast-Asynchronous Serial Interface: A standard for how to connect components such as encoders, modulators, receivers, and multiplexers.
DVB-C
Digital Video Broadcasting - Cable
DVB-HTML
DVB-HTML applications are a set of HTML pages that are broadcast as part of a service. The specification is based around a modularized version of XHTML 1.1, and also includes CSS 2.0, DOM 2.0, and ECMAScript.
30th March 2006
The MHP-Guide Version: 1.0
Page 179 of 215
DVB-IPI
DVB standard for the transport of DVB services over IP networks.
DVB-J
DVB-J (DVB-Java) applications are written in Java using the MHP API set and consist of a set of class files that are broadcast with a service.
DVB-RCS
DVB return channel by satellite.
DVB-S
Digital Video Broadcasting – Satellite
DVB-S2
Advanced DVB satellite modulation
DVB-SSU
DVB System Software Update
DVB-T
Digital Video Broadcasting – Terrestrial
DVD
Digital Versatile Disc
E2E
End-to-End
EC
European Commission
ECM
Entitlement Control Message. In the context of DVB CA systems used to broadcast messages to the CA system in the decoder containing information on the rights required for descrambling of a specific service.
ECMAScript
ECMAScript is a scripting programming language, standardized by Ecma International in the ECMA-262 specification. The language is widely used on the web, and is often referred to as JavaScript or JScript, although those two terms have more specific meanings. To understand the relation between ECMAScript, JavaScript, and JScript, knowing the history of ECMAScript is a helpful prerequisite.
30th March 2006
The MHP-Guide Version: 1.0
Page 180 of 215
EIT
Event Information Table. Table defined by the DVB specification for Service Information. Providing detail information on the events of the broadcast schedule.
EMM
Entitlement Management Message. In the context of DVB CA systems used to broadcast messages to the user smart card containing information on the rights of the individual users.
EPG
Electronic Program Guide
ESG
Electronic Service Guide
ETSI
European Telecommunications Standards Institute
EU
European Union
Euro-DOCSIS
Adaptation of DOCSIS to European cable networks: DOCSIS is a standard for delivering data over cable TV systems, typically for subscriber Internet access services.
FIFO
FIFO is an acronym for First In, First Out. This expression describes the principle of a queue or first-come, first-served behavior: what comes in first is handled first, what comes in next waits until the first is finished, etc. Thus it is analogous to the behaviour of persons "standing in a line" (preferred in American English) or "queueing" (preferred in Commonwealth English), where the persons leave the queue in the order they arrive.
FLUTE
Protocol for File delivery over unidirectional transport mechanisms.
FTTH
Fiber-To-The-Home: The installation of Optical fiber from a telephone switch directly into the sub-scriber’s home.
Gamma
Value of the brightness adaptation to the screen.
30th March 2006
The MHP-Guide Version: 1.0
Page 181 of 215
GEM
Global Executable Multimedia Home Platform.
GIF
Graphics Interchange Format. Very common graphics format, optionally supported by MHP terminals.
GPRS
General Packet Radio Service: It is a mobile data service available to users of GSM mobile phones. It is often described as "2.5G"
GSM
Global System for Mobile Communications: It is the second generation for mobile phone technologies.
GUI
Graphical User Interface
H.264
Compression Standard. Also called MPEG4 part 10 / AVC.
HAVi
Home Audio Video Interoperability: A vendor-neutral audio-video standard aimed specifically at the home entertainment environment. HAVi allows different home entertainment and communication devices to be net-worked together and controlled from one primary device, such as a PC or television.
HDTV
High Definition Television
HTTP
Hyper Text Transfer Protocol: It is the primary method used to transfer or convey information on the World Wide Web.
HW
Hardware
IFA
Internationale Funkausstellung: Annual International Broadcasting Fair in Berlin.
IP
Internet Protocol: The computer networking protocol used on the Internet.
30th March 2006
The MHP-Guide Version: 1.0
Page 182 of 215
IPTV
Internet Protocol Television. TV delivered via IP networks.
ISDN
Integrated Services Digital Network: It is a type of circuit switched telephone network system, designed to allow digital transmission of voice and data over ordinary telephone copper wires, resulting in better quality and higher speeds than available with analogue systems.
ISO
International Organization for Standardization
ISP
Internet Service Provider: A company that sells Internet services to the public.
ITV
Interactive Television. A capability in digital TV offering interactive services (e.g. information, communication, transaction, etc.) often directly related and synchronized with the broadcast content.
J2ME
Java 2 Micro Edition
J2SE
Java 2 Platform Standard Edition
JavaTV
It is a Java-based API for iTV applications development.
JMF
Java Media Framework
JPEG
Joint Photographic Experts Group. Commonly used compressed graphics format. Mandatorily supported by MHP terminals.
JVM
Java Virtual Machine
KDB
Knowledge Database: Public database of the MHP-KDB project.
30th March 2006
The MHP-Guide Version: 1.0
Page 183 of 215
Legibility
Legibility means that writing can easily be deciphered and read.
LGPL
Lesser General Public License. Open Source license used by the MHP-KDB project.
MHEG
Multimedia and Hypermedia information coding Expert Group. This Group developed a standard for a presentation engine called MHEG-5 which is used for digital teletext services in the UK.
MHP
Multimedia Home Platform
MPEG-2
A digital video and audio compression (encoding) technique defined by the Moving Pictures Expert Group (MPEG).
MUX
Multiplex
NAT
Network Address Translation: An Internet standard that enables a local-area network (LAN) to use one set of IP-addresses for internal traffic and a second set of addresses for external traffic.
NIT
Network Information Table. Table defined by the DVB specification for Service Information. Providing information on the transport streams/multiplexes available in a DVB network and their technical parameters (frequency, modulation, ...).
NPT
Normal Playtime
NTSC
National Television System(s) Committee: It is the analogue television system in use in Korea, Japan, United States, Canada and some South-American countries.
ORB
Object Request Broker
OC (Object Carousel)
The data structure (containing applications, media files, etc.) that is broadcast within a transport stream. In the context of MHP DSM-CC object carousels are used.
30th March 2006
The MHP-Guide Version: 1.0
Page 184 of 215
OCAP
Open Cable Application Platform: It is a technical standard, which is used in the cable networks of North America.
OFDM
Orthogonal frequency-division multiplexing
OSD
On-screen Display
OSI
Open Source Initiative
PAL
Phase Alternating Line: It is a color encoding system used in analoge broadcast television systems in large parts of the world.
PAT
Program Allocation Table. Table defined by the MPEG2 systems specification. Providing a very basic list of the services in a MPEG2 transport stream and linking to the corresponding PMTs.
PC
Personal Computer
PCF
Portable Content Format. Format specified by DVB to support authoring of interactive applications in an API independent way.
PCI
Peripheral Component Interconnect: A computer bussing architecture that defines electrical and physical standards for electronic interconnection.
PCR
Program Clock Reference. Master clock for each DVB service used to synchronize time critical content (basically video and audio, but optionally also data).
PDR
Personal Digital Recorder
PersonalJAE
Personal Java Application Environment
30th March 2006
The MHP-Guide Version: 1.0
Page 185 of 215
PES
Packetized Elementary Stream. MPEG2 defined protocol layer used for transmission of streamss to be decoded in real time (basically video and audio, but optionally also data).
PFR
Portable Resource Format
PID
Packet Identifier. Identifier for MPEG2 transport stream packets used for identifying different elementary streams.
PIN
Personal Identification Number
PKI
Public Key Infrastructure: A system that enables users of a public net-work to exchange data securely and privately through the use of a public and private cryptographic key pair that is obtained and shared through a trusted authority.
PMT
Program Map Table. Table defined by the MPEG2 systems specification. Providing a basic list of components (video, audio, teletext, data, ...) belonging to a specific and linking to these components.
PNG
Portable Network Graphics. Common graphics format, mandatorily supported by MHP terminals.
PRF
Permission Request File. Information needed in the context of the MHP security model.
PPPoX
PPP over some data link protocol such as Ethernet (PPPoE) or ATM (PPPoA). See also PPP.
PPP
In computing, the Point-to-Point Protocol, or PPP, is commonly used to establish a direct connection between two nodes. It can connect computers using serial cable, phone line, trunk line, cellular telephone, specialized radio links, or fiber optic links. Most internet service providers use PPP for dial-up access to the Internet.
PPP is commonly used to act as a "layer 2" (the "Data Link" layer of the OSI model) protocol for connection over synchronous and asynchronous circuits, where it has largely superseded an older non-standard protocol (known as SLIP), and telephone company mandated standards (such as X.25). PPP was designed to work with numerous "layer3" network layer protocols, including IP, IPX, and AppleTalk.
30th March 2006
The MHP-Guide Version: 1.0
Page 186 of 215
PPP was designed much later than the original HDLC specifications. The creators of PPP included many additional features that had been seen only in various proprietary WAN data-link protocols up to that time.
PSI/SI
Program Specific Information/Service Information. Tables like PAT, PMT, SDT, NIT or BAT defined by MPEG2 and DVB providing various types of metadata related to DVB networks and services.
PSTN
Public Switched Telephone Network: The international telephone system based on copper wires carrying analogue voice data.
PTS
Presentation Time Stamp. Timing information for the presentation of content (video, audio, data) transmitted via DVB streams.
PVR - Personal Video Recorder
A PVR is a receiver equipped with storage for recording digital media and an appropriate user interface that also allows scheduling automatic recordings.
QAM - Quadrature Amplitude Modulation
Modulation scheme used in some DVB networks.
QPSK - Quadrature Phase Shift Keying
Modulation scheme used in some DVB networks.
RC
Return Channel
RF
Radio Frequency
RGB
Red, Green, Blue: Color Model.
RSA
Rivest-Shamir-Adelman (-Algorithm): Secure asymmetric encryption algorithm using a key pair of private and public key.
RSS
Really Simple Syndication
30th March 2006
The MHP-Guide Version: 1.0
Page 187 of 215
RST
Running Status Table. Not commonly used DVB SI table to provide the running status of an event.
RTOS
Real Time Operating System
SARL
DVB Services Sàrl is a limited liability company governed by the Swiss Civil Code established with the aim of providing certification authority and all other related services to broadcasters, manufacturers, and entities.
SAS
Subscriber Authorization System
SDK
Software Development Kit
SDT
Service Description Table. Table defined by the DVB specification for Service Information. Providing detail information on the services contained in the actual (and optionally also in other) DVB transport stream.
SE
Stream Event. Defined as an option of the DSM-CC transmission protocol. Used to transmit time critical information to the MHP terminal.
SMS
Subscriber Management System (broadcasting) or Short Messaging Service (mobile phones)
SNMP
Simple Network Management Protocol
sRGB
Standard RGB Color Space
SSL
Secure Sockets Layer: SSL and Transport Layer Security (TLS), its successor, are cryptographic protocols which provide secure communications on the Internet.
ST
Stuffing Table. DVB table without useful data to be used for stuffing purposes.
30th March 2006
The MHP-Guide Version: 1.0
Page 188 of 215
STB
Set-top Box. MHP Terminal to be connected to a TV set.
SW
Software
T-Care
Analogue to the term e-Care. T- Care covers all sorts of communication services that connect patients and health care personnel in (bi-directional) TV-based communication applications.
T-Commerce
Analogue to the term e-Commerce T-Commerce covers all sorts of “commercial“ applications and transactions that are delivered and performed on the TV screen.
TCP
Transmission Control Protocol: It is one of the core protocols of the Internet protocol suite. Using TCP, applications on networked hosts can create connections to one another, over which they can exchange data. The protocol guarantees reliable and in-order delivery of sender to receiver data.
TDT
Time and Data Table. DVB defined table to carry time information in a DVB transport stream.
T-Games
Interactive Games to play on the TV screen.
T-Government
Analogue to the term e-Government. T-Government covers all sorts of information services and (ideally) communication and actions with the relevant authority, delivered and per-formed on the TV screen.
T-Health
Analogue to the term e-Health. T-Health covers all sorts of information services related to health and well-being that are delivered and performed on the TV screen.
T-Learning
Analogue to the term e-Learning. T-Learning covers all sorts of educational applications that are delivered and per-formed on the TV screen. In various publications this ranges from providing program related (educational) back-ground material to interactive learning applications which check and track learners’ progress.
TLS
Transport Layer Security: A cryptographic protocol, which provides secure communications on the Internet. The successor of SSL 3.0
30th March 2006
The MHP-Guide Version: 1.0
Page 189 of 215
TOT
Time Offset Table. DVB defined table to carry time information containing information on local time in a DVB transport stream.
TS
Transport stream: A multiplex of several program streams that are carried in packets.
UDP
User Datagram Protocol: It is one of the core protocols of the Internet protocol suite. UDP does not provide the reliability and ordering guarantees.
UI
User Interface
UML
Unified Modelling Language
UMTS
Universal Mobile Telecommunications System: It is one of the third-generation (3G) mobile phone technologies.
URL
Uniform Resource Locator
Usability
Usability is to ensure user-friendliness and –satisfaction, efficiency of use, and error prevention when working with an interactive service.
USB
Universal Serial Bus
VM
Virtual Machine
VoD
Video On Demand: The viewer pays a small fee to the television service provider in order to watch particular movies listed on the on-screen television menu. Similar to pay-per-view.
W3C
World Wide Web Consortium
30th March 2006
The MHP-Guide Version: 1.0
Page 190 of 215
WiFi
Wireless Fidelity
xDSL
It refers collectively to all types of digital subscriber lines, the two main categories being ADSL and SDSL. Two other types of xDSL technologies are High-data-rate DSL (HDSL) and Very high DSL (VDSL).
XHTML
Extensible Hypertext Markup Language
Xlet
Xlet is the interface used for execution engine application lifecycle control in MHP.
XML
Extensible Markup Language. Often used when authoring content for MHP applications.
YUV
A color format: Y contains the brightness signal (luminous intensity) and U and V contain the combined color information (chroma).
30th March 2006
The MHP-Guide Version: 1.0
Page 191 of 215
18 Literature [Gould 1995] J.D. Gould, and C. Lewis, “Designing for Usability: Key Principles and What Designers
Think,” Communications or the ACM, Vol. 28, No 3, March 1995, p. 300. Quoted according to: Aftelak, Häyrynen, Kurvinen: User-Centered Design in the course of large and distributed project. 15th Meeting of the World Wireless Research Forum. Paris. December 9th, 2005.]
[Hetzer 2001] Hetzer, Hanno; Sicherheitsanforderungen in digitalen Broadcastmedien am Beispiel der Multimedia Home Platform (MHP)
[MHP 1.0.0] MHP Standard Specification, Version 1.0.0
[MHP 1.0.2] MHP Standard Specification, Version 1.0.2. http://www.mhp.org/documents/mhp_Ts101812.V1.2.1.pdf.zip
[MHP 1.0.3] MHP Standard Specification, Version 1.0.3. http://www.mhp.org/documents/mhp_Ts101812.V1.3.1.pdf.zip
[MHP 1.0.3e] Errata of the MHP Standard Specification, Version 1.0.3. http://www.mhp.org/documents/tm2971r1.tm-tam0801r6.MHP1.0.3.errata2.pdf
[MHP 1.1] MHP Standard Specification, Version 1.1. http://www.mhp.org/documents/Ts102812.V1.2.1.zip
[MHPKDB-1] The MHP Knowledge Project, 2006, “Guidelines on Migration” (Deliverable D18) http://www.mhpkdb.org/publications.html
[Morris 2005] Morris, Steven; Interactive TV Standards A Guide to MHP OCAP and JavaTV Focal Press / Elsevier Inc.; 2005
[Morris 2005a] Steven Morris; “Interactive TV Web”; http://www.interactivetvweb.org/tutorial/mhp/index.shtml (last visited on 05/01/2006)
[Newell 2005] J. C. Newell, “An introduction to MHP 1.0 and MHP 1.1”; http://www.bbc.co.uk/rd/pubs/whp/whp030.shtml (last visited on 05/01/2006)
18.1 General DVB [GuidelinesDataBroadcasting] ETSI TR 101 202 V1.2.1 (2003-01) ”Digital Video Broadcasting (DVB);
Implementation guidelines for Data Broadcasting”
[ETSI] European Telecommunications Standards Institute, http://www.etsi.org
[DVB_ORG] Digital Video Broadcasting, http://www.dvb.org
[MHP_ORG] The official MHP web site, http://www.mhp.org
[HAVI] Home Audio Video Interoperability specification, http://havi.org/technical/specifications.asp
18.2 General TV [Dureau 2004] Dureau, V.: ADDRESSABLE ADVERTISING ON DIGITAL TELEVISION.
(Amsterdam, 2004) In: Broadcast Papers – IBC Papers 2004, available at http://www.broadcastpapers.com/ibc2004/ibc04OpenTVAdvertising.pdf (Last visited on 19/12/2005)
18.3 General User Interaction [BBC 2002] The BBC Styleguide
30th March 2006
The MHP-Guide Version: 1.0
Page 192 of 215
[Noss 2003] Noss, Christian: Lerneinheit, Studienbrief Screendesign für den Online-Studiengang Educational Media der Universität Duisburg-Essen, 2003
18.4 Other [SUNJMF] http://java.sun.com/products/java-media/jmf/index.jsp
[MHPKDB] The MHP Knowledge Project, http://www.mhpkdb.org
[MPEG2Systems] ISO/IEC 13818-1 Information technology - Generic coding of moving pictures and associated audio information: Systems
[MPEG2DSMCC] ISO/IEC 13818-6 "Information technology - Generic coding of moving pictures and associated audio information - Part 6: Extensions for DSM-CC".
[RFC 2246] http://www.ietf.org/rfc/rfc2246.txt?number=2246
[SN HESS] Sozialnetz Hessen, http://www.sozialnetz-hessen.de, 2005
30th March 2006
The MHP-Guide Version: 1.0
Page 193 of 215
19 Annex A - How to use the MHP KDB
19.1 Organization of the Database Content The MHP Knowledge Database (KDB) was created and designed to offer valuable material to all entities in the MHP production chain for free.
The project encourages broadcasters, decoder manufacturers, authoring tool providers, broadcast equipment manufacturers and, in particular, application programmers to make use of the reports, guidelines, best practice recommendations and sample codes provided in the KDB. Special emphasis was laid on a clear, intuitive structure of the contents in the KDB in order to ensure ease of use.
The KDB consists of a static and a dynamic part. The static part contains written documents like reports and guidelines that cover general know-how on MHP and interactive television. The dynamic part offers detailed MHP-related information (sample codes, benchmark applications, design and testing tools, guidelines) that is cross-linked to facilitate the locating of additional information on a certain topic in the KDB.
As the simplified data model shows (see sketch below), the so called Issue is the central data type. An Issue can be any kind of MHP-related question, interoperability problem, etc.
Once an Issue has been placed in the database, related Solutions can be attached to it. Issues and Solutions can be further explained by adding comments, sample code or any other kind of documents (Attachment).
The option to place comments to Issues and Solutions enables to open discussions related to certain questions.
Figure 19-1: Simplified Data Model of the KDB
30th March 2006
The MHP-Guide Version: 1.0
Page 194 of 215
19.1.1 Rights and Roles User roles and their corresponding rights are shown in the following table:
Role Rights
Author
Read all documents
Add comments to documents
Publish his own documents
Modify all his documents
Test Centre User
Author Role PLUS
Use Remote Testing Environments
Reviewer
Test Centre User Role PLUS
Modify all documents
Admin
Reviewer Role PLUS
Delete documents
Table 19-1: Rights and Roles Model of the MHP-KDB
After a regular registration you will be given the role of a Test Centre User. Highly interested users can obtain additional rights.
19.1.2 Reviewing Process Any contribution to the MHP-KDB will be initially published in the state of Not Reviewed.
There is a set of persons who are assigned the role of reviewers. Initially, a set of project members serve as reviewers.
A reviewer can access the pool of all contributions with status Not Reviewed. There, the reviewer can pick and review any contribution. There are no further mechanisms like check-in/check-out etc.
If a reviewer decides that a contribution is not fit for getting this quality mark, the reviewer adds a comment to the contribution in order to record his recommendations and remarks. The document is set to the state Declined until its next modification, which changes the document status back to Not Reviewed, allowing the reviewer to check it again. The author is automatically notified by an email about this step.
The further proceedings in this case are resolved by mutual email exchange between reviewer and author until the author withdraws his contribution or the reviewer is confident and ready that the quality mark Reviewed can be granted.
Only contributions that are clearly not related to MHP are deleted directly. Any other contributions are deleted only if the author withdraws it.
Changes to a document that has already been reviewed will change its status back to Not Reviewed. Reviewers are allowed to edit documents to make them fit the KDB quality criteria.
30th March 2006
The MHP-Guide Version: 1.0
Page 195 of 215
19.2 Using the KDB This chapter delineates how to use the KDB in an effective way, and gives a brief explanation of the license agreements and their consequences for using KDB content.
A more detailed introduction to the usage of the KDB is provided in the “Help” section of the web site.
The database provides three basic functions: adding, modifying and searching for entries.
Users are encouraged to always search for an issue before adding an issue to the database. First of all, the user is required to choose the document type to search for. The KDB provides two ways of searching for issues: a keyword based search and a category based search, both of which can be combined. The search results are displayed as a list of hyperlinks within the search screen. After clicking on one of the links, the Document View form for the chosen document type is displayed.
Figure 19-2: Searching an Issue in the KDB
30th March 2006
The MHP-Guide Version: 1.0
Page 196 of 215
Figure 19-3: Adding an Issue to the KDB
For adding a document the user has to choose Archive Document. A selection of types of documents that can be added appears. Members of the MHP-KDB project are permitted to enter all document types, registered users which are not MHP-KDB members are allowed to enter issues, solutions, comments, attachments and source code. The user has to provide some information about the posted issue:
30th March 2006
The MHP-Guide Version: 1.0
Page 197 of 215
Title of the new issue
Description of the issue
Issue Type (Question, Exception, Performance, Other)
Probable Solution Type (Application Change, Decoder Implementation Change, Recommendation, Standard Modification, Test Suite Modification, Other)
Keywords
Category (one of the main and / or sub-categories in the KDB)
Tool if applicable
Application if applicable
MHP Terminal if applicable
MHP Standard (MHP 1.0.2, MHP 1.0.3, MHP 1.1) if applicable
Additionally, the user has the opportunity to upload appropriate attachments and source code examples.
In order to modify a document, users need to click on the Edit Document tab. This will display a hyperlink list of all the documents that this user has entered into the database, ordered by document type (i.e. only the author of a document is allowed to modify this document). It is displayed whether the issues and solution provided by the author have been reviewed or not. By clicking on the link of the desired document, the Edit Document screen, which almost exactly resembles the Add Document screen, is displayed. The user can then make the desired changes and commit the updated version of the document into the database.
Editing a document does not mean that its former version is lost. Instead, a versioning system is applied that keeps older versions in the database but does not display them. If users then find out that a certain older version of a document needs to be recovered, they can ask the administrator to do that. Only the administrator is able to delete documents. Hence users need to request deletion of documents.
30th March 2006
The MHP-Guide Version: 1.0
Page 198 of 215
Figure 19-4: Editing a Document
19.3 Licensing conditions All documents in the static area of the database can be downloaded, used and distributed as long as they remain unchanged. Parts or even entire documents can be copied and used for other purposes. This offer is free of charge, but the user is obliged to refer to the MHP-KDB project. The wording of the licensing conditions for contents of the static database part can be found in chapter 19.3.1. .
Regarding the usage of source code, one existing license agreement offered by the Open Source Initiative (www.opensource.org) is used. Thus, the source code provided by the MHP-KDB project can be claimed to be "OSI Certified Open Source Software". This procedure allows for easy dissemination of MHP and harmonization of its usage, two of the main goals of the MHP-KDB project.
The project is using the LGPL (Lesser General Public License), because it allows for free usage of the source code and requires
not to change the copyright notice
to inform about any changes of the source code
to make the used source code of the MHP-KDB project available when distributing complete software works.
The LPGL contains also a disclaimer excluding warranty issues.
In addition to the LGPL rules a "code of conduct" is added. It requests for reporting back any improvements of the code and when applications go on
30th March 2006
The MHP-Guide Version: 1.0
Page 199 of 215
air that make usage of our know-how. The wording of the licensing conditions for Java source code is laid down in chapter 19.3.2 of this document.
19.3.1 Licensing conditions for documents in the static part of KDB
The PDF-documents in the static area will contain the project logo, a reference to the project website and a copyright notice as follows:
"© 2006 Institut für Rundfunktechnik GmbH on behalf of The MHP Knowledge Project. This work may be reproduced and redistributed, in whole or in part, without alteration and without prior written permission, provided all copies contain the following statement:
"© 2006 Institut für Rundfunktechnik GmbH on behalf of The MHP Knowledge Project. This work is reproduced and distributed with the permission of the Institut für Rundfunktechnik GmbH. No other use is permitted without the express prior written permission. For permission, contact [email protected].”
This document is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
As we are interested to continuously improve the quality of our documents, we kindly ask you to report back any error you find in our documents or any improvement you are able to suggest. This can be done via writing comments into the database or by an email to [email protected].”
19.3.2 Licensing conditions for Java source code The following notice will identify the software in our database as OSI Certified:
"This software is OSI Certified Open Source Software. OSI Certified is a certification mark of the Open Source Initiative."
The JAVA code in the database is marked as follows:
"[one line to give the library's name and an idea of what it does]
Copyright (C) 2006 by [contributing partner] on behalf of the MHP Knowledge Project.
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
30th March 2006
The MHP-Guide Version: 1.0
Page 200 of 215
[information on how to contact the author by electronic and paper mail]
www.mhpkdb.org"
As a non-binding code of conduct the following rules are added:
"We are interested to continuously improve the quality of our Knowledge Database. Therefore we kindly ask you to report back any bug you find in our software or any improvement you are able to suggest. This can be done via writing comments into the database or by an email to [email protected].
Furthermore we would appreciate if you could inform us (also via [email protected]) about any broadcast MHP application which was developed using our Knowledge Database“.
30th March 2006
The MHP-Guide Version: 1.0
Page 201 of 215
20 Annex B – Develop your first Xlet with MHP-KDB
A basic environment for developing MHP applications consist of three parts:
A set of class libraries that will let you to compile the application. A stub generator that generates MHP stub libraries from MHP javadoc is available for free download in the tools section of the KDB (www.mhpkdb.org). The javadoc files can be downloaded from MHP and Sun web-sites.
A text editor with java compiler, or an MHP authoring tool to edit and compile the application.
An MHP compliant platform to run the application. This may be a PC-based emulator or a development STB. The emulator simulates the behavior of an application on the PC but it is not suitable for estimating the performance on a real STB. Also only commercial emulators support all MHP features. Currently open source emulators offer only subsets of the standard, but allow for decent simple application development for beginners.
Once we have developed an application to be broadcast on a real network, it is important to test it on different STBs with different middleware stacks to check it for interoperability problems.
Download
Build
Run
Debug
Figure 20-1: Developing application steps
20.1 Build an application Authoring tools can be used to facilitate application building. Yet, depending on the individual requirements they may be too limited. Custom-made applications using text editor and java compiler may be the more flexible approach. Some authoring tools offer additional features like analyzing, testing and signing applications.
Below is an (incomplete) list of currently available authoring tools:
Vendors Tools
Actalis MHPSigner tool for signing MHP applications
Aircode The TVPlus I Station authoring tool
Alticast The Alticomposer authoring tool
NOVICE LEVEL
30th March 2006
The MHP-Guide Version: 1.0
Page 202 of 215
Cardinal Information system “Cardinal Studio” authoring tool
Core Media Starter Kit for MHP
Digisoft “DigiHost” Content management system
Emuse “Modelstream® Pro” development tool
Ensequence “on-Q Create” authoring tool
Fraunhofer IMK “JAME Author” authoring tool
Icareus “iTV Suite” authoring tool / DVB-HTML browser
Institut für Rundfunktechnik Dynamic and static MHP-applications analyzer
Mindhouse Content management system and applications
MIT-Xperts iDesigner authoring tool
NDS Value@TV Solutions is a complete application authoring tool
NPTV “iTV Factory suite" authoring tool
Ortikon Interactive Content provider tool and DVB-HTML browser emulator
Panasonic MHP development kit
Sony Professional Broadcast “Media Gateway” authoring tool
TeleIDEA “IdeaPublisher and TeleAuthor” a complete authoring and testing tool.
Unisoft MHP Security File Generator
Zappware “EZTV” Customizable applications
Table 20-1: Authoring Tools vendors
20.2 Download an application: Applications are either resident or downloaded; resident applications enable navigation and configuration of the MHP terminal. Those applications are deployed by manufacturers and can be upgraded by broadcasters. Downloaded applications are broadcasted using the DSM-CC object carousel. Developers who want to test such applications on an MHP terminal can use a play out system to compose and broadcast the DSM-CC object carousel that will include the application. An open source playout server implementation is available from http://krusty.cineca.it/vpweb/cgi-bin/blosxom.cgi
20.3 Debug an application: Manufacturers usually provide developer STBs to ease debugging. These specific STBs enable the output of application print messages via serial port or Ethernet connection. They are more expensive than commercial STBs but make development more efficient. All applications have to be tested on different kinds of MHP terminals to avoid potential interoperability difficulties. The MHP-KDB test center offers remote interoperability testing on a number of common STBs (for more information MHP-KDB web site).
30th March 2006
The MHP-Guide Version: 1.0
Page 203 of 215
20.4 Source code of basic application: The application below will display a text message “Hello MHP World” on the screen.
/*Include all needed package*/
import java.awt.*;
import java.awt.event.*;
import javax.tv.xlet.*;
import org.havi.ui.*;
public class HelloWorld extends Component implements KeyListener, Xlet {
private XletContext context;
private HScene scene;
private String messageToDispalay = "Hello MHP World";
private HStaticText text;
/* Standard Xlet lifecycle methods and constructors */
public HelloWorld(){
super();
}
/* Initialize the Xlet. The context for this Xlet will get passed in to this
method, and a reference to it should be stored in case it's needed later. This is
the place where any initialisation should be done, unless it takes a lot of time
or resources.
*/
public void initXlet(XletContext ctx) throws XletStateChangeException {
setName(string);
this.context = ctx;
HSceneFactory factory = HSceneFactory.getInstance();
HSceneTemplate hst = new HSceneTemplate();
hst.setPreference (HSceneTemplate.SCENE_SCREEN_DIMENSION,
new org.havi.ui.HScreenDimension(1,
1), HSceneTemplate.REQUIRED);
hst.setPreference (HSceneTemplate.SCENE_SCREEN_LOCATION,
30th March 2006
The MHP-Guide Version: 1.0
Page 204 of 215
new org.havi.ui.HScreenPoint(0, 0),
HSceneTemplate.REQUIRED);
text = new HStaticText(messageToDispalay,70 ,120 ,580 ,40);
text.setBordersEnabled(false);
text.setForeground(Color.white);
text.setFont(new Font("Tiresias" ,Font.BOLD , 24));
scene = factory.getBestScene(hst);
scene.setBounds(0,0,720,576);
scene.setLayout(null);
scene.setBackgroundMode(HScene.BACKGROUND_FILL);
scene.add(this);
scene.add(text);
scene.addKeyListener((KeyListener)this);
this.setSize(scene.getSize());
}
public void startXlet()throws XletStateChangeException {
validate();
scene.setVisible(true);
scene.requestFocus();
}
/*
* Pause the Xlet. This method cannot throw any exceptions, since an Xlet MUST
* pause itself when asked. However, exactly what the Xlet should do to pause
* itself is not specified. Doing nothing is allowed, but is not a good idea.
*/
public void pauseXlet(){
scene.setVisible(false);
}
/*
* Destroy the Xlet. This should release all resources, finish all threads and then
* exit. If the argument is false, then this method can refuse to be destroyed by
* throwing an XletStateChangeException.
*/
30th March 2006
The MHP-Guide Version: 1.0
Page 205 of 215
public void destroyXlet(boolean unconditional)
throws javax.tv.xlet.XletStateChangeException{
if(unconditional){
if (scene!= null) {
removeKeyListener(this);
scene.remove(text);
scene.remove(this);
scene.setVisible(false);
HSceneFactory.getInstance().dispose(scene);
scene = null;
}
context.notifyDestroyed();
}
else
{/* We have had a polite request to die, so we can refuse
* this request if we want.
*/
throw new XletStateChangeException("Please don't let me die!");
}
}
/* Key action will be defined in these functions*/
public void keyPressed (KeyEvent key){}
public void keyTyped(KeyEvent ignored) {}
public void keyReleased(KeyEvent ignored){}
}
30th March 2006
The MHP-Guide Version: 1.0
Page 206 of 215
21 Annex C - Presentation of the MHP APIs The APIs used to develop MHP applications are presented in this chapter.
MHP uses a number of already existing standards and also defines some specific additional APIs. The main Java APIs used in MHP are described in this Annex.
21.1 “Core” APIs
API Description
java.awt Build applications with graphical user interfaces. It is separated into two parts:
creating the interface and defining the behavior.
java.awt.event Provides interfaces and classes for dealing with different types of events fired by AWT components
java.awt.image
The java.awt.image package contains classes and interfaces that allow you to create new images from scratch rather than loading them from a file and to modify images that already exist.
java.beans Contains classes related to Java Beans development
java.io Provides for system input and output through data streams, serialization and the file system.
java.lang Provides classes that are fundamental to the design of the Java programming language.
java.lang.reflect Provides classes and interfaces for obtaining reflective information about classes and objects.
java.net Provides the classes for implementing networking applications.
java.security Provides the classes and interfaces for the security framework.
java.security.cert Provides classes and interfaces for parsing and managing certificates.
java.util
Contains the collections framework, legacy collection classes, event model, date and time facilities, internationalization, and miscellaneous utility classes (a string tokenizer, a random-
NOVICE LEVEL
30th March 2006
The MHP-Guide Version: 1.0
Page 207 of 215
number generator, and a bit array).
java.util.zip Provides classes for reading and writing the standard ZIP and GZIP file formats.
Table 21-1: Java Core APIs
21.2 JMF APIs These APIs are used to control how audio and video content is decoded and displayed, and are defined by Sun Microsystems. While this is mostly used for controlling what broadcast video is presented (and how it is presented), applications can also use JMF to play audio files or display a special kind of image format.
JMF 1.0 was originally designed to control streaming video and audio from a disk file either locally or from a “video” file server over a network. In order to address the unique nature of broadcast streams, JMF was extended by DAVIC with its org.davic.media package, discussed later. The JMF 1.0 used for iTV contains the following packages:
javax.media
javax.media.protocol
21.3 JavaTV APIs Java TV (JAVATV) is a transport independent abstraction for access to the MPEG-2 SI (as extended by the transport standards); with additional support for the unique properties of broadcasting traditional data items such as files. It is slightly more favorable to DVB’s SI over the other systems, since that was its first supported model, however in general it is 99% abstract. It contains the following packages:
API Description
javax.tv.graphics Adds some support to AWT for TV-specific issues such as video-graphics blending and discovering the root container of the application
javax.tv.locator Provides the mechanism for URL-like references to broadcast services and broadcast media clips
javax.tv.media Adds support for TV-specific functionality to JMF
javax.tv.media.protocol Adds support for broadcast streaming protocols to JMF
javax.tv.net Provides a mechanism for accessing IP datagrams contained in a broadcast stream
javax.tv.service High-level concepts for describing digital TV services. This package is also provides the basic mechanism for querying service information from the broadcast service.
30th March 2006
The MHP-Guide Version: 1.0
Page 208 of 215
javax.tv.service.guide Support for EPG-type applications, including concepts for describing individual events, program schedules and parental rating information
javax.tv.service.navigation Support for navigating services. This includes support for concepts such as lists of favorite services, components within services (i.e. elementary streams) and service types
javax.tv.service.selection Concepts describing how services are presented to the user, and how a new service can be selected. This also describes the concepts for presenting several services at once (e.g. picture-in-picture)
javax.tv.service.transport Concepts describing the transport mechanism used for a digital TV service, such as transport streams, broadcast networks and bouquets
javax.tv.util Utility classes for JavaTV applications, including management of timers and timer events
javax.tv.xlet Application lifecycle model and supporting classes
Table 21-2: JavaTV APIs
21.4 DAVIC APIs DAVIC, Digital Audio Visual Council was an organization set up to promote audio-visual applications through open standards. It picked up on the issue from MHEG and added a Java API offering better control of a receiver to an application. Many participants in DAVIC later also joined DVB for their MHP work, resulting in the latter incorporating the former.
In MHP today, there are several packages originating from the early DAVIC work. These packages mainly give an application better control of both selection and presentation of both audio and video. DAVIC also provides the framework of scarce resource notification used in consistently in MHP.
org.davic.media includes Java Media Framework extensions relevant to TV content. Most important is the language control for both audio and subtitles.
org.davic.mpeg represents MPEG system concepts through Transport Stream, Service and Elementary Stream classes. This information is partly extracted from the MPEG PSI information carried in a transport stream. The sub package org.davic.mpeg.dvb contains extended versions of these classes with additional DVB specific information. Another sub package, org.davic.mpeg.sections, provides the ability to filter specific MPEG sections from a transport stream.
org.davic.net deals with content referencing through the Locator class. In org.davic.net.dvb this class is extended to be more DVB specific. Explicit tuning between transport streams is handled with the org.davic.net.tuning package. However, this is not necessary when switching services. The last
30th March 2006
The MHP-Guide Version: 1.0
Page 209 of 215
sub package org.davic.net.ca deals with all conditional access system issues.
org.davic.resources holds the framework for resource notification adopted in MHP. Each scarce resource on a device will itself implement the notification regime, but it should be based on the interfaces found in this package.
21.5 HAVi (Home Audio Video Interoperability) APIs The Home Audio Video Interoperability (HAVI) has defined an extensive set of Java-based packages for consumer electronics devices. One part of HAVi that has been adopted by the standards supporting Java includes the user interface (UI) packages. This set of packages requires a subset of the standard java.awt package as more fully defined in (HAVI). The HAVi User Interface contains the following packages:
org.havi.ui
org.havi.ui.event
21.6 DVB APIs The DVB API is custom made APIs for MHP made by DVB. The DVB API is covered in chapter 11.3.2 and appendix H to U in the MHP specification [MHP 1.0.3].
org.dvb.application provides access to lists of applications, which are available in this context and the ability to launch those applications.
org.dvb.dsmcc provides extend access to files carried in the broadcast stream. The API also provides access to objects like streams and stream events, and stream event descriptors and NPT descriptors. One of the most important classes is the DSMCCObject. Instances of this object represents object in a DSM-CC carousel. DSMCCObjects can be used directly or by using the java.io.File methods.
org.dvb.event provides access to user input events before they are processed through the event mechanism of the java.awt package. A class that implements the UserEventListener can receive input events even though that application does not have user input focus.
org.dvb.io provides support for inter-application communication and an extension to the java.io package for access to files held in persistent storage. With the org.dvb.io.ixc.IxcRegistry class you can obtain a reference to a remote object residing in another Xlet on the same MHP terminal. The org.dvb.io.persistent provides access and attributes of files stored in persistent storage.
org.dvb.lang provides those core platform related features not found in the java.lang package. The DVBClassLoader is used to load classes and resources from a search path of URLs referring to locations where Java class files may be stored.
org.dvb.media provides DVB specific extensions to the Java Media Framework. Players that are presenting video in an HVideoComponent to control how the video is clipped use the org.dvb.media.VideoPresentationControl interface. The org.dvb.media.BackgroundVideoPresentationControl is only used with
30th March 2006
The MHP-Guide Version: 1.0
Page 210 of 215
video presented on the video plane. The interface can be used to set size, position, and clipping region. The org.dvb.media.VideoFormatControl provides a way to transform the incoming signal according to the format defined in the decoder format conversion (DFC).
org.dvb.net provides general networking features not found in other packages, extensions to the conditional access API from DAVIC, session management for bi-directional IP connections which are session based from the point of view of an application and extensions to the tuning API from DAVIC. The org.dvb.net.ca package provides the CAPermission that hold permissions for a range of CA system ids. MHP requires support for HTTP. The org.dvb.net.rc package lets the applications set up a return channel if needed for the HTTP/TCP/UDP connection. The org.dvb.net.tuning package holds tuner permissions and associates each SI database with a network interface.
org.dvb.si provides access to DVB service information. The API maps more or less directly onto the underlying SI tables. The SIDatabase class represents the entire database of SI the MHP terminal has access to on a given tuner. When an application issues a request to the SIDatabase, a SIRequest object is returned. Most of the calls to the SIDatabase are asynchronous; when the information requested is available a SISuccessfulRetrieveEvent is sent. This contains references to the SIRequest object. By using the retrieveDescriptors method of the SIInformation interface it is possible to get the descriptors associated with an SI element. It is also possible to monitor changes to a specific SI element using the SIMonitoringListener.
The DVBTest class of the org.dvb.test package allows test applications to log messages during their execution and to indicate their termination condition in a platform independent manner.
org.dvb.ui provides extended graphics functionality. The DVBGraphics class is an adapter class to support alpha compositing in an MHP device. The support for alpha composition allows for rules that say how transparency is applied to that graphics context and how it is blended with any components beneath it in the AWT hierarchy.
org.dvb.user provides access to settings and preferences configured by
the end-user.
As seen above several APIs can be used for the same feature. Below are presented these main features and the available APIs for each.
Graphic control: AWT,
HAVI,
DVB UI
SI access : JavaTv,
DVB SI,
Service selection: Javatv service selection
JMF
30th March 2006
The MHP-Guide Version: 1.0
Page 211 of 215
Return channel: org.dvb.net.rc
Audio/video control: JMF
DAVIC
Resource management by an application: org.davic.resource
Tuner control API: DAVIC
30th March 2006
The MHP-Guide Version: 1.0
Page 212 of 215
22 Annex D – Migration EXPERT LEVEL
This annex presents a synthesis on the migration issues between the versions 1.0.2 and 1.0.3. It gives an overview on the potential backward compatibility problems in each domain.
DSMCC-IO API definition change:
The methods below are not yet synchronized:
public synchronized int subscribe(java.lang.String eventName, org.dvb.dsmcc.StreamEventListener l) throws UnknownEventException, InsufficientResourcesException
public synchronized void unsubscribe(int eventId, org.dvb.dsmcc.StreamEventListener l) throws UnknownEventException
public synchronized void unsubscribe(java.lang.String eventName, org.dvb.dsmcc.StreamEventListener l) throws UnknownEventException
So developers must take care that if application access the same streamevent object from different threads this can cause problems.
APPLICATION This new method is added since version 1.0.3 a:
org.dvb.application.AppAttributes.isVisible():
Applications that have been launched are marked as visible and listed, this method shall return true when application are listed false otherwise. Developers must avoid using method org.dvb.application.AppAttributes.isVisible(), which doesn't exist in MHP 1.0.2 terminal for backward compatibility reason.
Application Listing and launching changes:
org.dvb.application.AppsDatabase.getAppAttributes(AppID):
Returns the properties associated with the given ID. Returns null if no such application is available. Properties of externally authorized applications will be returned from MHP 1.0.3 onwards thru
org.dvb.application.AppsDatabase.getAppAttributes(AppID).
org.dvb.application,.AppsDatabase.getAppAttributes(AppsDatabaseFilter):
This method will return an empty Enumeration if there are no attributes. Properties of externally authorized applications will be returned from MHP 1.0.3 onwards thru
org.dvb.application.AppsDatabase.getAppAttributes(AppsDatabaseFilter).
org.dvb.application.AppsDatabase.getAppIDs(AppsDatabaseFilter)
ID of externally authorized running applications will be returned from MHP 1.0.3 onwards thru
org.dvb.application.AppsDatabase.getAppIDs(AppsDatabaseFilter).
30th March 2006
The MHP-Guide Version: 1.0
Page 213 of 215
MEDIA Method definition change:
public interface VideoFormatListener becomes
public interface VideoFormatListener extends java.util.EventListener
So avoid relying on MHP 1.0.2 to VideoFormatListener definition (use MHP 1.0.3 definition, it will work also on MHP 1.0.2 receiver).
RETURN CHANNEL Method declaration changed:
public interface ConnectionListener becomes
public interface ConnectionListener extends java.util.EventListener
So to be backwards compatible, the developer must assume that an object that implements the connectionListener interface does not implement the EventListener interface.
The target for connection can include character “+” as the first character only to indicate the phone number including international code.
That will affect the following objects:
org.dvb.net.rc.RCPermission;
org.dvb.net.rc.ConnectionRCInterface.
HAVI Behavior change
If byte array don’t contain a valid image constructor HBackgroundImage(byte[]) in version 1.03 “may” return an IllegalImageException so developers that rely on this exception shall not yet rely on it to be backward compatible.
The function getVideoController shall never throw HpermissionDeniedException when an application does not currently have the right to get the VideoPlayer object so that developers shall not yet rely on such exception.
SI Normative Clarification
org.dvb.si.Descriptor: the application don’t sub-class this object Descriptor(). All 1.02 application must not sub-class Descriptor().
Function not supported
getTextualServiceIdentifiers no longer supported. Use getName, getShortServiceName, getProviderName and getShortProviderName instead.
Object moved to new package
ServiceComponent has moved to a new package. Avoid usage of this class if application need to be compatible with both 1.0.2 and 1.03: “javax.tv.service.navigation.ServiceComponent”
30th March 2006
The MHP-Guide Version: 1.0
Page 214 of 215
StreamType has moved to a new package.
Avoid usage of this class if application need to be compatible with both 1.0.2 and 1.03: “javax.tv.service.navigation.StreamType”
Recommendation In the functions
org.dvb.si.SiNetwork.RetrieveSITransportStream(short, Object, SIRetrievalListener, short[])
org.dvb.si.Descriptor.SIBouquet.retrieveSIBouquetTransportStreams(short, Object, SIRetrievalListener, short[]) and
org.dvb.si.Descriptor.SIBouquet.retrieveDescriptors(short, Object, SIRetrievalListener, short[])
the last argument “someDescriptorTags” shall not be null, because the behavior is implementation dependent. So developers shall take care about this case to guarantee the same comportment on each type of implementations.
Most part of the changes define in Errata 2 are mainly clarifications or editorial changes; an Errata 3 is coming soon to fix version 1.0.3.
Application In org.dvb.application.AppProxy a new field is added:
Public static final int INVALID
Security Changes in the minimum to be supported Certificate Revocation List. (8 CRLs instead of 5 CRLs).
DSM-CC In org.dvb.dsmcc the exception ServiceXFRException shall not be thrown if the Service Domain that actually contains the DSMCCObject is already mounted.
Behavior changes:
Delivery of carousel within multiple services delivered over multiple trans-port stream is possible if:
Carousel_id in the carousel_id_descriptor is in the range of 0x100-0xffffffff.
The carousel_id__descriptor for the carousel are identical in both services (so the carousel have the same carousel_id and boot parameters).
Any changes in DSI shall not provoke the unavailability of a carousel. In org.dvb.dsmcc the exception ServiceXFRErrorEvent shall not be thrown if the Service Domain that actually contains the DSMCCObject is already mounted. Take care if you rely on this exception.
The receiver shall deactivate any event listeners dependant on a timebase (and may free resources associated with those listeners) under the follow-
30th March 2006
The MHP-Guide Version: 1.0
Page 215 of 215
ing conditions If a timebase is deleted (reference to it is removed from the set of NPTReferenceDescriptors)
but also If a discontinuity is detected (i.e. NPTDiscontinuityEvent generated) in that timebase;
or If a service selection operation changes the current service, either through the MHP API or through the service selection feature of the MHP navigator ;