This app will not feature remote control interaction (e.g. show / hide itself on red button press) or other features and will showcase a minimum HbbTV app skeleton. Hello world! message is shown on screen immediately without the need for any user action. The application consists of:
hello-world.html HTML document holding the application scene
hello-world.css CSS document holding the application scene styling
hello-world.js JavaScript file holding the application logic
The Content-Type is also set as defined in standard to “application/vnd.hbbtv.xml+xhtml; utf-8”. Within <head> we include our CSS and JS.
Body section:
The onload attribute calls our app entry function sayHello(). The <body> should always include the application/oipfApplicationManager embedded object which we will use within our application logic to acquire the Application object, as set by standard.
Each application has an associated DOM Window object by default. This Window object is initially marked hidden to avoid screen flicker during application start-up. Once loaded, the application then typically calls the show() method of the Application object.
It is good practice for application scene to use a container <div>, which in our example is <div class=”safe_area” id=”app_area”> to define a graphic safe area for content authoring as recommended in chapter 10.1.3 Graphic safe area (informative) of the standard. We put our Hello world! Message in the center of the graphics safe area.
Now, let’s start inspecting the hello-world.css document.
We set the body to be transparent, so we see the live broadcast going on in the background. We also set the body size as defined in standard.
We then set the style for the application/oipfApplicationManager embedded object:
We choose to define the graphic safe area for content authoring as recommended in chapter 10.1.3 Graphic safe area (informative) of the standard. The background colour is set to better distinguish the Hello world! message on screen:
Finally, we set the Hello world! message style:
Observe that the font-family set is a font which is supported by the standard.
Finally, let us dive into application logic:
We only have one function defined, which is our app entry function sayHello(). It attempts to acquire the Application object, which should always be possible on a HbbTV terminal. The Application object is acquired using the getOwnerApplication() method of the application/oipfApplicationManager embedded object as described in the Annex A (normative): OIPF DAE Specification Profile of the standard. Once the Application object is acquired its show() method can be called in order to make our application visible on screen.
This example will build on our Hello world example and will demonstrate the interaction of HbbTV applications with remote control. Remote control keys supported within applications are set within the ETSI TS 102 796 V1.1.1 standard document, chapter 10.2.2 User input:
Button (for conventional remote controls)
Key event
Status
4 colour buttons (red, green, yellow, blue)
VK_RED, VK_GREEN, VK_YELLOW, VK_BLUE
Mandatory
4 arrow buttons (up, down, left, right)
VK_UP, VK_DOWN, VK_LEFT, VK_RIGHT
Mandatory
ENTER or OK button
VK_ENTER
Mandatory
BACK button
VK_BACK
Mandatory
Number keys
VK_0 to VK_9 inclusive
Mandatory
Play, stop, pause
VK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSE
Mandatory
Fast forward and fast rewind
VK_FAST_FWD VK_REWIND
Mandatory
TEXT or TXT or comparable button
Not available to applications
Mandatory
2 program selection buttons (e.g. P+ and P-)
Not available to applications
Optional
WEBTV or comparable button
Not available to applications
Optional
EXIT or comparable button
Not available to applications
Optional
Beware that the applications themselves define which key events they request to receive. This is done by setting the KeySet object to a bitwise mask constructed from the constants in the following table:
Constant name
Numeric Value
Use
RED
0x1
Used to identify the VK_RED key event.
GREEN
0x2
Used to identify the VK_GREEN key event.
YELLOW
0x4
Used to identify the VK_YELLOW key event.
BLUE
0x8
Used to identify the VK_BLUE key event.
NAVIGATION
0x10
Used to identify the VK_UP, VK_DOWN, VK_LEFT, VK_RIGHT, VK_ENTER and VK_BACK key events.
VCR
0x20
Used to identify the VK_PLAY, VK_PAUSE, VK_STOP, VK_NEXT, VK_PREV, VK_FAST_FWD, VK_REWIND, VK_PLAY_PAUSE key events.
SCROLL
0x40
Used to identify the VK_PAGE_UP and VK_PAGE_DOWN key events.
INFO
0x80
Used to identify the VK_INFO key event.
NUMERIC
0x100
Used to identify the number events, 0 to 9.
ALPHA
0x200
Used to identify all alphabetic events.
OTHER
0x400
Used to indicate key events not included in one of the other constants in this class.
Implemented functionality
The example application, once started, shall demonstrate a typical red button scenario, when the application at first only reacts to the red button which, when pressed, invokes the full application that requests to receive more key events. To keep this example minimal, we will not use an image for the call-to-action banner:
In this state, the app receives only the red button event and reacts to it by showing the full application scene:
When full application scene is active, the app will react to all coloured RC buttons as follows:
RED BUTTON to hide the scene and go back to call-to-action scene
GREEN BUTTON to enable / disable reception of playback RC buttons (PLAY / PAUSE / STOP / FFWD / RWD) by the app
YELLOW BUTTON to enable / disable reception of numeric RC buttons (0 … 9) by the app
BLUE BUTTON to prevent reception of all RC buttons by the app for 10 seconds
When the full application scene is active, the app will also show the last RC button pressed on screen.
rc-buttons.js which defines global variables for RC button events and 2 utility functions
rc-interaction.js which contains the application logic
The onload attribute of the body tag calls the app entry function start(). Document body also includes the application/oipfApplicationManager embedded object which is used within application logic in order to acquire the Application object, as set by standard.
The rest of the rc-interaction.html document contains main application scene within the safe area as recommended by the standard and a separate div outside of safe area containing the red button call to action notification:
In order to keep this example as simple as possible the call-to-action banner (Press the red button on the RC to start!) is implemented as text.
rc-interaction.css
The rc-interaction.css starts with HbbTV specifics explained in the Hello world example.
The difference in this example is that initial visibility state of safe area (containing main application scene) is set to hidden since on application start only red button call-to-action notification is visible:
Red button call-to-action notification div and text style (contains nothing specific for HbbTV):
Main scene and bottom legend style concludes the CSS (contains nothing specific for HbbTV):
rc-buttons.js
The rc-buttons.js defines global variables for RC button events:
Key events for different RC buttons are defined in KeyEvent class, but we choose to define global variables, since we want to add support for key events on emulators running on computer browsers which receive input from a computer keyboard, which we do like so:
This approach ensures that we always have a global variable defined for every key event. The rest of rc-buttons.js defines 2 utility functions:
setKeyset(app, mask), which is used to set a KeySet mask (this is how applications define which key events they request to receive). This example application is built for maximum compatibility, so in order to support terminals implementing version 1.1.1 of the ETSI TS 102 796 standard the setKeyset(app, mask) function has to compensate for a change in OIPF DAE Application class private property name change to privateData (OIPF DAE specification version 1.1 to version 1.2);
registerKeyEventListener(), which is used to invoke the callback function for processing RC button events (in our case it is the handleKeyCode(kc) function);
rc-interaction.js
The rc-interaction.js starts of with scene initialization implementation:
Followed by utility function used to show / hide main scene and retrieve the KeySet mask relevant for current state of main scene (numeric / playback RC buttons enabled or disabled):
Main application scene is rendered using the render() function:
When a user presses the BLUE RC button, all user input is disabled for 10 seconds. This is a demonstration of controlling the RC button events application will receive when setting the keyset value to different button masks. The waiting is implemented in timerTick() function like so:
RC button events handling is implemented in handleKeyCode(kc) function:
Observe that the key handler function code ends with returning true to suppress the default behaviour of the terminal for the pressed RC button.
The rc-interaction.js ends with app entry function:
This function tries to acquire the Application object and, when successful, initializes and shows it’s user interface (initial state set by CSS is app_area hidden, red button call-to-action banner visible).
IMPORTANT: It is highly recommended that prior to reading this article one consults the ETSI TS 102 796 V1.1.1 standard document, especially the chapters considering the video/broadcast object (e.g. 10.1.2 Interaction with the video/broadcast object and A.2.4 Extensions to the video/broadcast object).
Introduction
This example will build up on our Hello world example and will demonstrate interaction with broadcast video and audio using the video/broadcast object. The following figure shows the states that a video/broadcast object may be in. Dashed lines indicate automatic transitions between states. The video/broadcast object will be in the unrealized state when it is instantiated.
Applications can use the playState property of the video/broadcast object to read its current state. Possible playState values are:
Value
Meaning
0
unrealized; the application has not made a request to start presenting a channel or has stopped presenting a channel and released any resources. The content of the video/broadcast object is transparent.
1
connecting; the terminal is connecting to the media source in order to begin playback. Objects in this state may be buffering data in order to start playback. Control of media presentation is under control of the application. The content of the video/broadcast object is transparent.
2
presenting; media is currently being presented to the user. The object is in this state regardless of whether the media is playing at normal speed, paused, or playing in a trick mode. Control of media presentation is under control of the application. The video/broadcast object contains the video being presented.
3
stopped; the terminal is not presenting media, either inside the video/broadcast object or in the logical video plane. The logical video plane is disabled. Control of media presentation is under control of the application. The application is still granted access to broadcast resources.
Example application
The example application will:
Initialize the video/broadcast object so it displays the current channel in „windowed“ (not full screen) mode in bottom right part of the screen;
Attach an event listener to video/broadcast object which will display current state of the object (playState variable)
Show info on current channel being displayed on terminal
Show info on channels available on terminal
Observe the application scene post startup (FireHbbTV emulator):
broadcast-object.html HTML document holding the application scene
broadcast-object.css CSS document holding the application scene styling
broadcast-object.js JavaScript file holding the application logic
broadcast-object.html
We start with:
as is required by chapter A.2.6.2 MIME type and DOCTYPE of the ETSI TS 102 796 V1.1.1 standard.
In head section we load our CSS and JS:
In body tag we set our onload function:
And we follow with our embedded objects:
The application/oipfApplicationManager embedded object is used within our application logic to acquire the Application object, as set by standard and explained in Hello world example. The video/broadcast is our broadcast a/v object that we will use to control the display of broadcast video.
We follow with our application scene, contained in safe area as recommended by the standard:
The scene contains three status fields:
Initialization status (shows status of initialization)
video/broadcast object playState (updated by PlayStateChange event handler)
Current channel info (shows info on channel currently displayed within video/broadcast object)
which are followed by a list of channels available to the terminal (which is acquired using functions / properties available with the video/broadcast object).
broadcast-object.css
Document defines style for body:
Style for the embedded objects:
The video/broadcast object is positioned to the lower-right part of the screen, at coordinates 890, 530 with set width to 250px and height to 140px. When setting width & height please observe limitations set by ETSI TS 102 796 V1.1.1 standard, Table 14: Minimum terminal capabilities. Z index is set to make sure that the video/broadcast is on top OSD graphics. The HbbTV graphics planes model is described in the chapter 10.1.1 Logical plane model of the standard.
Style for safe area:
Then we finish by setting style for status fields and channel list:
broadcast-object.js
Application logic is implemented in broadcast-object.js:
We define a broadcastObject which shall be used for all things regarding broadcast video and audio and the initialization function. The initialization function retrieves the video/broadcast object using DOM and adds the PlayStateChange event listener. Then it calls bindToCurrentChannel() as defined by the state machine described in the beginning of this article followed by a call to setFullScreen(false) function which should put the broadcast a/v in “windowed” mode. The video/broadcast object method void setFullScreen( Boolean fullscreen ) sets the rendering of the video content to full-screen (fullscreen = true) or windowed (fullscreen = false) mode. If a change in mode is indicated, it results in a change of the value of the video/broadcast object property fullScreen. Changing the mode does not affect the z-index of the object.
Finally, the initialization function obtains the currentChannel property and stores it to broadcastObject.currentLiveChannel.
After the initialization function other utility functions are defined:
The getChannelList() function retrieves the channelList property which contains a list of channels available to the terminal. The getChannelInfo(ch) function returns a text representation of a Channel object containing channel name and identifiers for that particular broadcast service within the broadcast network where it’s carried. Finally, the playStateChangeEventHandler() function implements the event listener for the PlayStateChange event.
The remainder of our code is the app entry function start(). It starts with Application object acquisition:
Once the Application object is acquired we initialize our broadcastObject and display corresponding initialization status and current channel information:
Then we retrieve and display the list of available channels:
We finish with the remainder of our app entry function:
Hybrid broadcast broadband TV (HbbTV) is a global initiative dedicated to providing open standards for the delivery of advanced interactive TV services through broadcast and broadband networks for connected TV sets and set-top boxes.
HbbTV ® is
HbbTV ® is NOT
Business neutral technology platform Applicable to terrestrial, cable and satellite broadcast and broadband networksAllows to combine broadcast and broadband service elementsMaintains integrity of broadcast services, including all related elementsIntegrates an application managementBroadband link recommended, broadcast only mode possibleSpecifies only device (terminal) behavior
Completely specified ecosystem, e.g. including implementation rulesSolely applicable to over-the-air (OTA)broadcast or broadcast in general
The key building blocks
Important components provided by HTML5 (W3C) include:
The HTML markup language itself.
The <video> element for presenting broadband delivered video in an HTML page.
The APIs for manipulating the contents of an HTML page from JavaScript.
Important components provided by the Open IPTV (OIPF DAE) specification include:
JavaScript APIs for applications running in a TV environment
(e.g. broadcast video presentation, channel change).
Definition of embedding linear audio and video (A/V) content in an application.
Integration with content protection/DRM technologies
DVB (ETSI TS 102 809) provides the following components:
Application signalling.
Application referencing via HTTP
Transport of applications via broadcast.
The audio and video formats are defined in the OIPF Media Formats specification.
System overview
A hybrid terminal has the capability to be connected to two networks in parallel. On the one side it can be connected to a broadcast DVB network (e.g. DVB-T, DVB-S or DVB-C). Via this broadcast connection the hybrid terminal can receive standard broadcast A/V (i.e. linear A/V content), non-realtime A/V content, application data and application signalling information. Even if the terminal is not connected to broadband, its connection to the broadcast network allows it to receive broadcast related applications. In addition, signalling of stream events to an application is possible via the broadcast network.
In addition the hybrid terminal can be connected to the Internet via a broadband interface. This allows bi-directional communication with the application provider. Over this interface the terminal can receive application data and non linear A/V content (e.g. A/V content streaming on demand). The hybrid terminal may also support non-real time download of A/V content over this interface. The broadband interface may also connect to Companion Screen Devices or other HbbTV® terminals on the same local network as the hybrid terminal.
Via the Broadcast Interface the terminal receives AIT data, linear A/V content, application data and stream events. The last two data streams are transferred by using a DSM-CC object carousel. Therefore a DSM-CC Client is needed to recover the data from the object carousel and provide them to the Runtime Environment.
The Runtime Environment can be seen as a very abstract component where the interactive application is presented and executed. The Browser, an Application Manager and the Companion Screen Interface form this Runtime Environment. The Application Manager evaluates the AIT to control the lifecycle for an interactive application. The Browser is responsible for presenting and executing an interactive application.
Linear A/V content is processed in the same way as on a standard non-hybrid DVB terminal. This is included in the functional component named Broadcast Processing which includes all DVB functionalities provided on a common non-hybrid DVB terminal. Additionally some information and functions from the Broadcast Processing component can be accessed by the Runtime Environment (e.g. channel list information, EIT p/f, functions for tuning). These are included in the “Other Data” in the figure above. Moreover an application can scale and embed linear A/V content in the user interface provided by an application. The Media Player provides these functionalities.
Via the Broadband Interface the hybrid terminal has a connection to the Internet. This connection provides a second way to request application data from the servers of an application provider. Also this connection is used to receive A/V content (e.g. for Content on Demand applications). The component Internet Protocol Processing comprises all the functionalities provided by the terminal to handle data coming from the Internet. Through this component application data is provided to the Runtime Environment. A/V content is forwarded to the Media Player which in turn can be controlled by the Runtime Environment and hence can be embedded into the user interface provided by an application. In combination with the Media Player, the Synchronization Manager can synchronize content delivered to the hybrid terminal via the Broadband Interface and content delivered to the hybrid terminal via either the Broadband Interface or the Broadcast Interface.
The Companion Screen Interface enables the hybrid terminal to discover Companion Screen Devices and other hybrid terminals and to be discovered by Companion Screen Devices. Through it, interactive applications running in the Browser can request an application be installed or started on a Companion Screen Device and an application running on a Companion Screen Device can request the Browser to start an interactive application. It provides a WebSocket server to enable an interactive application in the hybrid terminal and an interactive application on either a Companion Screen Device or a different hybrid terminal to communicate. In combination, the Companion Screen Interface and the Media Player together enable synchronization of content delivered to the hybrid terminal via either interface with content delivered to a Companion Screen Device or another hybrid terminal.
Via the CI Plus interface, the hybrid terminal requests application data from the Auxiliary File System offered by the CICAM.
Broadcast-independent and broadcast-related applications
There are 2 types of HbbTV applications:
A Broadcast-independent application (i.e. not associated with any broadcast service). This type of application is downloaded via broadband and accesses all of its associated data via broadband.
A Broadcast-related application (i.e. associated with one or more broadcast services or one or more broadcast events within a service) that may be launched automatically (“autostart”) or explicitly upon user request. This type of application may be downloaded via broadband or broadcast and may access its data via either method.
In the above example Quiz and TV guide are broadcast-related HbbTV applications (launched from broadcast services using the red RC button), while Portal, VoD and Weather are broadcast-independent HbbTV applications. Portal application is launched by the terminal using a dedicated RC button, while VoD application and Weather application are launched from Portal application.
HbbTV application development and testing can be performed using different emulators, e.g. RedOrbit HbbTV Emulator or HybridTV Dev Environment (please note that other emulator alternatives exist). However, no emulator environment emulates 100% functionality of a hybrid terminal. Therefore it is quintessential to validate any HbbTV application on a hybrid terminal before rolling it out to the end users.
System overview
A hybrid terminal (e.g. a smart TV set) can be connected to two networks in parallel. On the one side it can be connected to a broadcast DVB network (e.g. DVB-T, DVB-S or DVB-C). Via this broadcast connection the hybrid terminal can receive standard broadcast A/V (i.e. linear A/V content).
In addition the hybrid terminal can be connected to the Internet via a broadband interface. This allows bi-directional communication with the application provider. Over this interface the terminal can receive application data and non-linear A/V content (e.g. A/V content streaming on demand).
Figure below depicts the system overview with a hybrid terminal connected to both of these networks in parallel:
In this scenario the broadcast signal also holds the AIT (Application Information Table) data. The Application Manager of the Hybrid terminal evaluates this AIT data. AIT data holds the URL (Uniform Resource Locator) of the HbbTV application. The Browser of the Hybrid terminal is responsible for downloading, presenting and executing the HbbTV application singalled within the AIT data of the Broadcast signal.
Checklist
In order to run a HbbTV application on a smart TV set the following is needed:
A broadcast a/v stream that also includes custom AIT data (AIT data holds the URL of the HbbTV application that one wishes to run)
A DVB modulator that can modulate the broadcast a/v stream so it can be demodulated and decoded by the hybrid terminal (e.g. DVB-T modulator)
A web server hosting the HbbTV application that one wishes to run
A hybrid terminal (a smart TV set or a Set Top Box that supports HbbTV)
The hybrid terminal must be connected to a network that enables bi-directional communication with the Web server which hosts the HbbTV application (HTTP/HTTPS communications protocol is used)
The European Broadcasting Union hosts the hbbtv-dvbstream project on GitHub that leverages other open source software in order to facilitate launch of HbbTV applications on hybrid terminals: https://github.com/ebu/hbbtv-dvbstream. This project can be used to generate the Broadcast stream in TS (Transport Stream) file format.
DVB modulator
Possible examples of a DVB modulator device include:
Other modulator alternatives may exist. Listed are examples provided by HbbTV members. HbbTV itself is not recommending or endorsing usage of any particular modulator products.
Web server hosting the HbbTV application
IMPORTANT NOTE:
For HbbTV applications authored for versions 1.1.1 and 1.2.1 of the ETSI TS 102 796 standard all XHTML documents of an application should be served with the MIME content type “application/vnd.hbbtv.xhtml+xml”, since terminals supporting these versions of the standard are not required to load or run documents which are served with a MIME type other than “application/vnd.hbbtv.xhtml+xml”.
Terminals supporting later versions of the standard support the MIME types defined for HTML5 but should also support the “application/vnd.hbbtv.xhtml+xml” MIME type in order
to run applications authored for previous versions of the standard.
The HbbTV application must be hosted on a web server, for example Apache (https://httpd.apache.org/) or nginx (https://www.nginx.com/). The application URL must be accessible by the hybrid terminal device. If the hybrid terminal can access the public internet then this could be hosted anywhere in the cloud. If the hybrid terminal is limited to only accessing the network in your office then you will need to host it locally somehow.
Hybrid terminal
Any smart TV set or a STB (Set Top Box) that supports HbbTV can be used as a receiver device which can run HbbTV applications.
A practical example
This step-by-step tutorial explains how to launch the Hello world application presented in the Guidelines section of the portal.
Step 1: On the web server which will be used to serve the application clone the application source code using command:
Step 3: Edit the create-metadata-ts.py script so the created AIT table holds the Hello world application URL. This is done via the appli_root and appli_path variables within the create-metadata-ts.py script. Once the variables are set run the make-stream.sh script to generate the TS (Transport Stream) file with the broadcast stream.
Step 4: Use the TV modulator and accompanying software to playout the generated TS file and modulate it to a modulation supported by the hybrid terminal (e.g. DVB-T).
Step 5: Perform channel scan on the hybrid terminal (channels EBU-CPA1 and EBU-CPA2 as defined in create-metadata-ts.py script should be found by the Hybrid terminal). Make sure that the Hybrid terminal is connected to the network so it can reach the Hello world application installed on the web server.
Step 6: Tune to the channel which holds the AIT signalling for the application and the Hello world application should start automatically.
This section starts collecting typical pitfalls when developing HbbTV applications. New issues can be added to the tracker to and will be published on this page.
HbbTV applications cannot rely on any specific behaviour for objects where CSS display is set to “none”. Some HbbTV implementations will not initialise these objects while others will. Setting CSS display to “none” in an HbbTV application should be considered an error in the application.
2. Missing CORB support
Many devices do not implement CORB properly and allow requests that should be blocked.
The HTML5 browser in an HbbTV device is typically derived from a desktop browser version between 2 and 4 years old. This results in new web security features starting to appear in HbbTV devices ahead of any requirement in the specification. If something fails on a desktop browser due to a new web security feature, developers should expect it to also fail in some HbbTV TV sets.
One example of this is Cross-Origin Read Blocking (CORB, see HbbTV A.3.14) which will be enforced on some TV sets but not on others.
3. Using new web technologies when not necessary
Many HbbTV TV sets in consumer’s home will be 4-6 years old and will probably include browsers at least 2 years older than that. You can refer to caniuse to see when a particular feature was widely implemented in desktop browsers.
In order for an app to reach the largest number of consumers, developers should be cautious in their choice of web technologies, sticking to CSS2. Avoiding CSS3 (e.g. not using features like flexbox) and limiting themselves to ES3 is encouraged. Some technologies may have polyfills to bridge the gap between a modern app and an older browser.
4. Not explicitly stopping broadcast video before playing broadband
HbbTV applications wanting to play broadband video with the HTML5 video element need to explicitly ensure that any broadcast video that might already be in progress is stopped. Some implementations (mistakenly) stop broadcast video when not done explicitly which is the opposite of what is required.
Some applications assume this mistaken behaviour and fail on correct implementations. For an application to work on as many devices as possible, any broadcast video needs to be explicitly stopped before using the HTML5 video element.
HbbTV specs have a formal name and an informal name
Informal Name
Formal Name
HbbTV 2.0.2
TS 102 796 V1.5.1
HbbTV 2.0.1
TS 102 796 V1.4.1
HbbTV 2.0
TS 102 796 V1.3.1
HbbTV 1.5
TS 102 796 V1.2.1
HbbTV 1.0
TS 102 796 V1.1.1
New in HbbTV version 2.0.2
In the version 2.0.2 of the specification following changes have been made (compared to version 2.0.1):
HDR (High Dynamic Range) video support added (both PQ10 and HLG formats)
HFR (High Frame Rate) video support added (e.g. 100Hz or 120Hz)
NGA (Next Generation Audio) audio support added
Fixes for bugs discovered in version HbbTV 2.0.1 of the specification
IMPORTANT NOTE: HDR, HFR, NGA support is not mandatory. It is left up to national, broadcaster or operator specifications to require them.
HDR
Builds on DVB selection of technologies: HLG and PQ10
Both of these are just extra data carried in an HEVC BT.2020 bitstream
No additional work needed on the bitstream by HbbTV or DVB
For broadband
Builds on 2 MPEG-DASH mechanisms
Essential Property descriptors define extra information essential to decoding the content – i.e. players need to ignore content if there’s one of these that they don’t understand
Supplemental Property descriptors define extra information useful to decoding the content – i.e. players can still present the content if there’s one of these they don’t understand
Common to both HLG and PQ10 are Essential Property descriptors to identify BT.2020 video
PQ10 also identified by an extra Essential Property descriptor
HLG is backwards compatible so also identified by a Supplemental Property descriptor
DVB-DASH defines a new 2017 profile and PQ10 must be in this profile & not the old 2014 profile
Existing 2014 profile DASH players cannot be relied on to respect Essential Property descriptors so without this might attempt to present PQ10 video as SDR
For broadcast
Apps can test if a device can decode a HDR/HFR/NGA broadcast and show that instead of a regular one
HFR
Broadcast and broadband HFR have different optimisations:
Both enable delivery of a single elementary stream of 100Hz / 120Hz video
Broadcast optimisation:
Content coded at 100Hz/120Hz can be delivered as:
one stream for 50Hz/60Hz devices &
a second enhancement stream for 100Hz/120Hz devices to combine with the 1st stream
Broadband optimisation:
Enable producing in 100Hz/120Hz & extracting a 50Hz/60Hz subset without re-encoding
Relies on a feature of HEVC that has not been widely used so far
NGA
A lot in common between AC-4 and MPEG-H audio around integration with HbbTV and DASH:
Audio for a content is built up of multiple components
e.g. background music, effects & several language tracks
Content provider can define a number of preselections – combinations of components
e.g. 1) background music + effects + language A, 2) background music + effects + language B, 3) effects + language A without background music
Can be used in 3 possible modes:
Single Representation Single Preselection (SRSP)
A DASH Representation contains a single preselection & all necessary audio components
Changing language or accessibility choice means changing Adaptation Set
Single Representation Multiple Preselection (SRMP)
A DASH Representation contains >=1 preselection and the union of all necessary audio components across all of them
Audio components not used by the currently presented preselection are downloaded & then discarded
Changing language or accessibility choice means staying within the same Adaptation Set
Audio components can be distributed across multiple DASH Adaptation Sets
e.g. each component in its own Adaptation Set or some combinations
Potential to avoid downloading and discarding unused audio components
Optional in DVB-DASH and HbbTV
Device capabilities extensions
Existing HbbTV device capabilities mechanism is extended in order to allow apps to test which HDR, HFR, NGA technologies are supported by the terminal.
For broadband, list of combinations of supported codecs is extended to include HDR, HFR, NGA:
For broadcast, a new <broadcast> element is added to list supported broadcast technologies:
HDR capabilities are based on URNs so there is no barrier to including non-DVB HDR technologies.
New <video_display_format> element was added in order to give applications visibility of the UHD capabilities of the display (whether built-in or connected).
Significant selected fixes for bugs
Bug / Issue
Fix description
deviceID (#7598)
Renamed to distinctive identifier and clarified circumstances and options for when it may not be accessible to apps for privacy reasons.
Approval and pre-approval of companion screen app launching HbbTV app (#7970)
Clarified that TV / STB must support some mechanism to approve / pre-approve apps to be launched & that this must allow future apps to be launched (either by asking the user or by the manufacturer updating a some sort of white-list).
Relative file names accessing a carousel after channel changing (#7697)
Added explanation of issue around using relative file names to access files in a carousel after channel changing & use of the HTML <base> element to solve this.
W3C Encrypted Media Extensions (#7607)
Updated to refer to W3C Recommendation and not a Working Draft.
MPEG common encryption with conventional DRM and W3C clear key (#6215)
Clarified choice between EME and oipfDrmAgent APIs if content would use common encryption with both conventional DRM and clear key.
Sharing cookies between apps from the same broadcaster on different services (#7323)
User preferences set on one broadcast service were not available on another service from the same broadcaster due to the DVB-SI service_idbeing included in the origin of an HTML page loaded from the broadcast. The origin used for such HTML pages has been changed to permit this.
SHA-1 sunset date has passed (#7162)
The SHA-1 signature algorithm is now forbidden in HbbTV as it is in the web.
Enable apps to prioritise which DRM is used (#7088)
Extra method added to allow apps to prioritise which DRM is used when a TV/STB supports more than 1.
DASH players for HTML5 video element and A/V control object (#7046)
TVs and STBs are required to use the same DASH player regardless of the API used hence avoiding duplication of tests and testing between the two APIs.
Including or not including data services in the service list (#7045)
Explain that there are reasons why data services with non-supported apps may still be relevant to include in the channel list.
Spec version of an app in the AIT signalling and in the DOCTYPE (#6915)
Reinforced existing requirements that HbbTV 2.0.1 TVs and STBs run apps for earlier versions of the spec according to HbbTV 2.0.1 regardless of the (minimum) spec version signalled in the AIT or the DOCTYPE.
Clarify video/broadcast object behaviour when a/v object is playing and channel is changed (#6211)
Clarified behaviour around channel changing while a broadcast-related app is presenting broadband delivered video.
Ignoring unsupported AIT descriptors (#5583)
TVs and STBs are required to ignore unsupported AIT descriptors in order to avoid problems in the future should HbbTV need to use additional ones.
CSS3 nav-* properties (#5385)
Support for these has been dropped from web browsers. They are deprecated in HbbTV and will be removed in a future HbbTV specification.
Permit use of DVB security solution for “man in the middle” attacks onbroadcast.
Updated version of TS 102 809 to the one including this solution. It is up to broadcasters, operators and national specifications to require this be supported.
Avoid leaking “secret” stream URLs via Media Synchroniser (#6049)
For some broadcasters’ VoD services, the URL of the broadband media stream or manifest includes sensitive information, such as authentication tokens. Additional contentIdOverride property is added to the mediaSynchroniser object to allowapps to override the contentID used for inter-device sync.
UPnP version to be used with DIAL (#5910)
UPnP v1.1 was required but 1.0 is more common and there is no benefit from requiring 1.1 so 1.0 is now also allowed.
#9623: language in clause 9.6.2 about hardware video resource management and HTML5 video elements
#10181: Releasing resources from HTML media elements
#10195: media decoders and the seeked event
Compatibility with modern soft text input (virtual keyboards)
#10007: Section 10.2.1: incompatibility with modern soft input (virtual keyboards) that operate on words or phrases (turns out that this also enables some forms of voice input)
Future evolution and maintainability of the XML capabilities mechanism
#9487: Error in XML capabilities example and XSD
Media synchronisation requirements may be unrealistic for some implementers
#9325: Unreasonably demanding a/v sync timing requirement (relaxed from -10ms/+10ms to -35ms/+50ms)
#10435: Unreasonable demanding of synchronization between A/V and subtitles (tests assume 40ms, market expects frame accuracy at scene cuts, may not be achievable on some hardware)
Media synchronisation (video via broadcast and audio via broadband)
#8810: behaviour of multi-stream sync API at times when no content exists in a slave media synchroniser
#10719: stopping multi-stream sync and disposing of a MediaSynchroniser object
#10722: successful completion of initMediaSynchroniser and addMediaObject
DASH
#9315: DASH – MPD events (SCTE-35 ad insertion events crash some HbbTV implementations)
#10447: Errata to DVB-DASH (update to newest version to get bug fixes – optional features remain optional, features added by DVB are all optional)
New features
Web standards updated from 2013 to 2018
Why 2018 and not 2020? To allow time for code to be ported and optimised for constrained systems.
Why not 2016? Public disclosure of security bugs in desktop browsers means that shipping TVs based on old browsers may be unwise.
New standards implemented by 2018 browsers:
Media Source Extensions (MSE)
Note that MSE already widely implemented in deployed HbbTV terminals
Service workers (enable more responsive and adaptable apps)
A well defined profile of ISOBMFF (no new features)
Believed to be compatible with existing devices (there are no obvious reasons why it wouldn’t be)
Low latency streaming
Defined constraints to enable MSE to be used for delivery of low latency live services based on DVB-DASH requirements (low latency not required for native DASH player)
Enabled querying which AES encryption modes are supported
Industry is moving to adopt Apple’s flavour of CBCS instead of CENC as previously used (Widevine already moved, PlayReady 4.0 supports Apple flavour of CBCS)
May allow encode, package & encrypt once for Android, Apple, PC & media devices
Querying physical screen size (extension to HbbTV XML capabilities mechanism):
Removed features
Dropped immediately:
CI+ host player mode
HbbTV app launching an app on a companion screen (phone)
Teletext Subtitles in OTT content
3 aspects of media sync (optional SYNC_SLAVE mode, optional sync buffer, use of A/V control object in media sync)
Candidates to be dropped at some time in the future:
Geneva, August 31, 2021 – The HbbTV Association is pleased to announce the publication of a new version of the HbbTV Conformance Test Suite.
The new version, developed by the HbbTV Testing Group, is called v2021-2. It is the second and the most important major release of the Test Suite in 2021. Notably, the release includes all 234 tests developed for the new HbbTV specification for Targeted Advertising (HbbTV-TA) as well as 77 new tests created for the new HbbTV specification v2.0.3, approved by ETSI in April 2021.
“With this new release, HbbTV crosses a new benchmark, as our Test Suite now contains a total of 3,000 test cases and our approval rate is rising from 73% to 79%. This is the result of the substantial efforts made by the HbbTV Association to fund and develop a powerful Test Suite enabling a reliable industrial implementation of its specifications in the market,” said Vincent Grivet, Chair of the HbbTV Association.
The HbbTV Conformance Test Suite is an important tool for device manufacturers to verify compliance of their products with the most current HbbTV specifications, ensuring that existing and new features quickly and smoothly reach HbbTV-compliant TV sets and set-top boxes.
The Test Suite is available through one of the registered HbbTV test centres and, as a convenience, to HbbTV members for use in their own facilities.
For more information on the v2021-2 Test Suite, please visit www.hbbtv.org.
Geneva, July 20, 2021 – The HbbTV Association is pleased to announce the publication of the second phase of its solution for Targeted Advertising (TA). This enables substitution of broadcast adverts with targeted adverts in situations where the broadcast TV signal is received by a set-top box (STB) and passed to the HbbTV TV set via a connection such as HDMI.
The HbbTV Application Discovery Over Broadband (ADB) specification already defines how broadcasters can add signalling to video and audio which survives the HDMI connection and can be used by a TV set to launch an HbbTV app. This specification has now been updated to enable broadcaster apps to use the HbbTV TA API to schedule a precise switch from HDMI to an advert and back again when the TV set is connected via a STB.
The combination of ADB and TA will enable broadcasters to reach more of their audience with targeted advertising, and also to offer targeted inventories to advertisers in a homogeneous manner – two aspects which are very important to preserve revenues and realise new growth opportunities in the face of competition from other advertising categories and chiefly from the native digital inventories such as web and mobile.
HbbTV’s work on Targeted Advertising has been done in cooperation with the DVB Project. DVB developed the original requirements and their own related specifications for signalling when broadcast adverts can be replaced. Both HbbTV ADB and DVB TA employ the ATSC 3.0 video and audio watermark solutions to enable signalling to survive carriage over an HDMI connection.
“The release of the TA solution for STB markets is a perfect example of how HbbTV adjusts its specifications to the needs of industry players, enabling them to adjust to real market circumstances and grow their business through new revenue sources,” said Vincent Grivet, Chair of the HbbTV Association.
Geneva, May 10, 2021 – The HbbTV Association is pleased to announce the simultaneous release of the 2021-1 version of the HbbTV Conformance Test Suite and the Test Assertions Repository (TAR).
About the 2021-1 Test Suite release
The new version is called v2021-1; it is the first major release of the Test Suite in 2021. The release contains 2,963 test cases in total, an increase by 142 test cases since the v2020-3 release.
The new release includes new tests developed for the HbbTV specification for Targeted Advertising (HbbTV-TA) and the first test cases for the new version 2.0.3 of the HbbTV specification. The remaining test cases will be delivered during 2021 and should form part of the Test Suite release v2021-2.
The HbbTV Conformance Test Suite is an important tool for device manufacturers to verify compliance of their products with the most current HbbTV specifications, ensuring that applications and content from broadcasters and content owners can work flawlessly across TVs and set-top boxes from all manufacturers. The Test Suite is available to all HbbTV members and also through the registered HbbTV test centres.
A new tool published by HbbTV to support conformance: The Test Assertion Repository
HbbTV is also releasing a set of test descriptions (“Test Assertions”) which can be referred by any organisation running a conformance regime for HbbTV compliance when a definition of compliance is needed.
The test assertions are publicly available through a Test Assertion Repository (TAR) which can be found on the HbbTV website, accompanied by explaining notes.
“The release of the new HbbTV Compliance Test Suite version, covering our new Targeted Advertising specification, and the release of the Test Assertions Repository illustrates the commitment of the HbbTV Association to facilitate the design and production of reception devices which fully comply with the HbbTV specification. This is a major expectation from all market players at a moment where HbbTV specifications play an increasingly central role in the deployment of business-critical innovative services, and we want to meet this expectation,” said Vincent Grivet, Chair of the HbbTV Association.
For more information on the v2021-1 Test Suite and on the Test Assertions Repository, please visit www.hbbtv.org.
Geneva, October 27, 2020 – The HbbTV Association has completed work on an update to its core specification (HbbTV 2.0.3).
For the first time, and based on the experience garnered through millions of receivers and hundreds of services worldwide, HbbTV has removed some features and is announcing the intention to remove others in the future. For example, never used parts of the media synchronisation, companion screen and CI Plus features have been removed as has been support for teletext subtitles in OTT content. A full list of the features concerned can be found in the HbbTV 2.0.3 explainer on the HbbTV website.
Some existing HbbTV features will be updated in line with the changes in the market place. The web standards included in HbbTV 2 will be updated from the original selection that was defined in 2013. Support for W3C Media Source extensions will be added. The MPEG DASH support will be extended to include CMAF. It is believed that many recent HbbTV devices already support these. Also relating to MPEG DASH, applications will be able to query if an implementation supports the ‘cbcs’ encryption mode originally used by Apple, but now becoming widespread in many DRM systems.
“The HbbTV specification is now a mature specification, as it is now used to a large scale in many commercial real-life situations,” said Vincent Grivet, Chairman of the HbbTV Association. “With this maturity of deployment, the market has a better view of what is really important and what is not so important in the end. Keeping the specification ‘lean’ and focused on the important things is key to make it implementable in a reasonable manner by manufacturers and other market players. This does not mean that the specification is frozen or does not meet new use cases, as demonstrated for instance with our recently published Application Discovery over Broadband phase 2 (ADB2) and Targeted Advertising (HbbTV-TA) additions.”
Commenting on the new release, Jon Piesing, HbbTV Vice-Chairman and Chairman of the Specification Group who spearheaded the specification development process, said: “Over the years, our core HbbTV 2 specification has accumulated a number of things that have never been used or which have been superseded. It’s now time to ‘spring clean’ our specification. Some things that we believe are not used will be removed in this update. Where things are used but superseded, we will send a clear message to the users of our specification that they need to plan a transition. While HbbTV does not aim at moving as fast as the web, equally it cannot keep adding technologies and features indefinitely without removing anything.”
The HbbTV Association welcomes feedback from users of its specifications at any time. Feedback is particularly invited if anyone is using – or has serious plans to use – an element to be removed in HbbTV 2.0.3. Email contact: communications@hbbtv.org
While such casual and direct input from specification users is welcomed by the HbbTV Association, market players using HbbTV are advised that the best way to influence and contribute to the HbbTV specification is by becoming a member and participating in the working group activities such as the Requirements Specification Group which discusses the requirements capture and the Specification Working Group where the specifications are generated.
The HbbTV Association aims to support version 2.0.3 in the July 2021 release of its Test Suite – the release aimed at products entering the market in 2022.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Important components provided by HTML5 (W3C) include:
Important components provided by the Open IPTV (OIPF DAE) specification include:
DVB (ETSI TS 102 809) provides the following components:
