Author: domagoj@hbbtv

dfgfdgfd

HbbTV application testing and verification

Posted on by domagoj@hbbtv

Just a Web app, right?

HbbTV apps are essentially Web apps. This enables application developers to leverage Web applications development environments in order to build, test and deploy HbbTV applications. Testing and prototyping process is accelerated by different browser plugins and emulators which (partially) implement HbbTV specifics on the PC. See Resources section for a list of useful tools.

Navigating the specifics of HbbTV

However, there are specific challenges developers need to overcome in order to ensure a good user experience of their HbbTV apps, namely:

Varying hardware and software environments across terminals

HbbTV applications run on a multitude of terminal models, each with varying hardware performance and capabilities, as well as quality of software implementations. This mixture of runtime environments can lead to discrepancies in how a HbbTV application behaves across different devices. 

A key difference between terminals is the hardware performance. The differences observed can be most significant. It is therefore wise to keep one’s apps as simple as possible and with minimum memory footprint. If fast CPU or lots of memory are required to run the envisioned application it can be a good strategy to perform some kind of whitelisting of the terminals that are known to run the application in a satisfactory fashion and abort execution on other terminals in order to avoid terminal crashes and unresponsiveness.

It’s very important to resist the temptation to simply acquire the newest models from the top two manufacturers in your market and develop on those. They will not be representative of the older models from those manufacturers let alone models from other manufacturers. You will be creating a problem for yourself later on when you start testing on a wider set of terminals.

If running on older terminal models is important (see later), specific issues for older products include graphics performance and amount of available memory and, for much older TV sets, versions of TLS.

Identifying terminal manufacturers and models

Since there are many HbbTV terminal manufacturers and models, it is wise to prioritize testing on a number of the most popular or widely used terminal models to cover a significant portion of the user base. Every market is specific in that regard, so it is important to gather information on the installed HbbTV terminal base. This is accomplished by analyzing User-Agent header information sent by the terminals. All outgoing HTTP requests made on behalf of an HbbTV application running on a terminal include a User-Agent header using the following syntax:

The version parameter indicates the HbbTV standard version supported by the terminal. Since there are multiple versions of the standard, with significant differences in capabilities, any application should adopt one of the two following strategies:

  • Require a minimum version and abort execution on older version terminals
  • Dynamically adapt to different versions of the standard supported by the terminal

The capabilities parameter signals optional features implemented on the terminal (e.g. DRM support).

The optional vendorName, modelName, softwareVersion, hardwareVersion parameters which are not always present but commonly, together with full User-Agent string, contain enough information to ascertain the terminal model family. 

Access to a variety of TVs

Developers will need access to a representative terminal base. For many developers, this will be a mixture of having some models in-house combined with use of an external so-called “receiver zoo”. There are a few of these around and at least one of these has some kind of remote access. If you need to test on older products then an external receiver zoo may be the only way of doing this unless you have some available receivers from previous HbbTV or SmartTV projects.

In order to define what would be needed for a representative terminal base, following questions should be answered:

  • Which markets are targeted for the app?
  • Which TV manufacturers have the largest market share in those markets and which product families do they have? (If you are developing the app under contract to a broadcaster then they may be able to help with these. If no data is available, you can measure the data supplied within the User-Agent header as explained above).
  • Which TVs from the leading manufacturers do you already have? How much can you afford to buy more TVs? What are the gaps in what you already have?
  • What percentage of the market does your customer want your app to reach? The higher the proportion of the market, the more you will need to look at TV manufacturers with a smaller market share and/or older products from main manufacturers.
  • If you are developing the app under contract to a broadcaster, what evidence of verification will they want from you? Agreeing the amount of detail and the format required in advance may save both of you time and money later. Do they want a list of the models the app has been successfully tested on?

Generally speaking, in order to run a HbbTV application on a terminal, one should deploy the application in question on a Web server and tune the terminal to a broadcast signal that contains a (TV) service with AIT signaling holding the URL of the deployed application. Easy, right? A lab setup accomplishing the task looks something like this:

Anybody who has developed and deployed a Web application knows how to deploy the application on the Web server. Creating and sending the broadcast signal that contains correct AIT signaling information may prove more difficult to most developers. In order to send the signal to the HbbTV terminal’s RF interface, one needs to modulate it to a modulation scheme supported by the terminal, e.g. DVB-T2. There are plenty of lab modulators out there. Some of them require a source signal in the form of a content file, typically in MPEG2-TS format. The European Broadcasting Union provides a free, open-source tool to generate MPEG2-TS files containing TV services that embed HbbTV AIT signaling information. The tool is called hbbtv-dvbstream and is listed with other useful tools in the Resources section.

Once you’ve worked out what TV sets you want to test the app on, you need to develop a test script or journey – a reproducible sequence of steps through the app that exercise what you believe are the key features and the key steps of the user journey. User journey maps clarify complicated user journeys and ensure that the process is smooth and seamless. They are designed to help us figure out where the pain points are and improve the user experience of the provided service. They make testing reproducible and make it easier to spot regressions. If the app is developed under contract to a broadcaster they may want to review this with you or indeed, you may want them to review it with you.

RC navigation and video interaction

One thing a HbbTV application developer should always keep in mind is that users use the terminal’s remote controller for navigation. Therefore it is quintessential to keep this in mind when designing UX and perform extensive testing on terminals (instead of emulators) using their respective remote controllers. 

Typically, most applications will have some form of video interaction, either with broadcast A/V object or the player object. It is very important to test this interaction on the HbbTV terminals most common on the target market, since same actions or API calls may manifest differently on different terminals. Support for different media formats and protocols can also differ significantly on different terminal models, so it is very wise to test media playback across all available terminals. 

Some applications include interactive functionalities synchronized with the video playback. Due to reasons mentioned above, it is wise to test these functionalities extensively on the HbbTV terminals most common on the target market.

Security

A TV set typically has a much longer lifespan compared to a mobile phone or a PC. More crucially, once it is installed in a customer’s home it seldomly receives software updates. More common than not, a HbbTV terminal will run on the same software stack as delivered from the factory throughout its lifespan. 

This has many unwanted consequences, such as terminals trusting revoked certificates, not supporting new certificate authorities and root certificates etc. As a Web app developer, one can usually expect customers to run up-to-date browsers and put less effort and energy into supporting older versions. A HbbTV developer typically does not have this luxury, as the browser version may not change throughout the lifespan of the terminal.

There are also many other cybersecurity concerns developers should know about before putting HbbTV services in production. It is therefore important for HbbTV developers to get familiar with the relevant material specific for cybersecurity in the HbbTV domain, such as EBU presentation on HbbTV security and EBU recommendations on cybersecurity for connected televisions and services.

Conclusion

Despite the fact that HbbTV applications are essentially Web applications, HbbTV application testing and verification presents a unique set of challenges due to its hybrid nature and varying ecosystems. Navigating these challenges requires a combination of terminal base testing, user journey mapping and analysis, audiovisual media playback and synchronization verification, security assessments etc. By understanding and addressing these challenges, developers can ensure that their HbbTV applications deliver a consistent user experience across a wide range of devices and scenarios. Embracing all the HbbTV specifics and tailoring respective testing strategies enables HbbTV developers to create high-quality HbbTV applications.

A practical guide on handling the broadcast a/v object

Posted on by domagoj@hbbtv

Before you read this post

IMPORTANT: It is highly recommended that prior to reading this post one consults the following tutorial. 

General behaviour of the broadcast a/v object

HbbTV terminals support the video/broadcast embedded object. The MIME type of this object is “video/broadcast”. The behaviour and possible states of the video/broadcast object is described in the following tutorial.

When no video/broadcast object is instantiated within the HbbTV application, or when all video/broadcast objects are in the unrealized state, broadcast video presentation is under the control of the terminal (and not the application). When video is under the control of the terminal:

  • Any broadcast video being presented gets displayed in the logical video plane.
  • The complete logical video plane is filled.
  • The terminal itself may scale and/or position video, for example to remove black bars.

When a video/broadcast object is in any state other than the unrealized state, broadcast video presentation is under the control of the application. When video is under the control of the application:

  • When the video/broadcast object is not in “full-screen mode”, any broadcast video being presented gets scaled and positioned to fit the video/broadcast object.
  • When the video/broadcast object is in “full-screen mode”, presented video gets scaled to fill the logical video plane. The terminal itself may further scale and/or position video, for example to remove black bars.
  • Depending on the Z index of the video/broadcast object with respect to other HTML elements (regardless of whether the object is in “fullscreen mode” or not), presented video may fully or partially obscure other HTML elements with a lower Z index, and may in turn be fully or partially obscured by HTML elements with a higher Z index. As a result of this, video may appear to be presented in a plane other than the logical video plane.

If the release() method is called on a video/broadcast object, or if the object is garbage collected, the control of broadcast video presentation is returned to the terminal and video gets re-scaled and re-positioned (if necessary).

Code snippets for common actions

Before doing any actual HbbTV application development, it is highly recommended to consult the related API documentation. 

Object declaration and instantiation:

It is important to note that the instantiation of the video/broadcast object does not cause tuner resources to be claimed. These resources are only claimed following a call to the setChannel(), bindToCurrentChannel(), nextChannel() or prevChannel() methods on a video/broadcast object:

If the applications wants to return the control of broadcast video to the terminal and release the resources, it should call the release() method:

If the application wants to stop presenting the broadcast video (but maintain control over the playback of broadcast video and tuner resources), it should call the stop() method:

A call to stop() method shall cause a transition of the video/broadcast object to the stopped state. Please note that calling this method from the unrealized state shall have no effect.
State of the video/broadcast object can be programmatically tracked using the event listener listening to PlayStateChange events:

Full code example

A fully working example can be found on the HbbTV Association’s GitHub repo: https://github.com/HbbTV-Association/Tutorials/tree/main/broadcast-object 

The example demonstrates the interaction of a HbbTV application with broadcast video and audio using the video/broadcast object and showcases how to get channel information from the terminal using the API. 

Practical experiences on using MPEG-DASH and ISOBMFF

Posted on by domagoj@hbbtv

This blog post contains practical experiences on using MPEG-DASH streaming protocol and the ISO base media file format (ISOBMFF) with HbbTV terminals.

The following text was contributed by @Murmur 

BTRT box in init.mp4 files:

  • some older HbbTV players may crash if BTRT(bitrate) box is before SINF box.
  • solution is to drop BTRT box or write after SINF box.
  • correct ordering is MOOV/TRAK/MDIA/MINF/STBL/STSD/ENCV/SINF, /BTRT
  • dash and hls players don’t need BTRT so it’s safe to drop from the init segment.
    SENC box in segment.m4s files:
  • some older HbbTV players may crash if SENC(sample encryption) box is before TRUN
    (fragment run) box.
  • solution is to write after TRUN box
  • correct ordering is MOOF/TRAF/TFHD, /TFDT, /TRUN, /SAIZ, /SAIO, /SENC
    SIDX box in segment.m4s files:
  • write one SIDX box at the start of segment file with 1..n references to MOOF/MDAT
    fragments.
  • use single fragment (MOOF/MDAT pair) for best compatibility.
    Segment durations:
    Dash specification allows a small +/- variation in m4s segment file durations. It is relatively easy to split video stream by using an even integer FPS-GOP(Group of Picture) values.
    Audio segments may not 100% match to video segments unless video segmenting is fine tuned to follow the audio codec packet sizes. It is best not to use AAC 44100Hz but always transcode 48000Hz sample rate.
    The following table describes the easy to understand even-integer and less known non-integer durations to have a fully aligned video and audio segment durations. It may not always be possible to use non-integer value in some of the encoder and packager tools.
    H264, H265 Video and AAC Audio (48000Hz, 1024 packet size)
  • use 8 seconds segment duration to fully match both segments
  • align video IDR key frames to 2-8 seconds interval
  • every other even-integer values produce a small +/- variation in audio durations when
    comparing the same $Number.m4s files (video/1..n.m4s = audio/1..n.m4s).
    H264, H265 Video (25fps, 50fps) and AAC Audio (48000Hz, 1024 packet size)
  • use 3.84 seconds segment duration to fully match both segments
  • align video IDR key frames to 3.84 seconds interval
    H264, H265 Video (30fps, 60fps) and AAC Audio (48000Hz, 1024 packet size)
  • use 3.20 seconds segment duration to fully match both segments
  • align video IDR key frames to 3.20 seconds interval

Hello World Application

Posted on by domagoj@hbbtv

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

Full source code is available here: https://github.com/HbbTV-Association/Tutorials/tree/main/hello-world

Let’s dive into hello-world.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.

Head section:

<head>
    <title>Hello world app</title>
    <meta http-equiv="Content-Type" content="application/vnd.hbbtv.xml+xhtml; utf-8" />
    <link rel="stylesheet" href="hello-world.css" />
    <script type="text/javascript" src="hello-world.js"></script>
</head>

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.

Interaction with the remote control

Posted on by domagoj@hbbtv

Introduction

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 eventStatus
4 colour buttons (red, green, yellow, blue)VK_RED, VK_GREEN, VK_YELLOW, VK_BLUEMandatory
4 arrow buttons (up, down, left, right)VK_UP, VK_DOWN, VK_LEFT, VK_RIGHTMandatory
ENTER or OK buttonVK_ENTERMandatory
BACK buttonVK_BACKMandatory
Number keysVK_0 to VK_9 inclusiveMandatory
Play, stop, pauseVK_STOP and either VK_PLAY and VK_PAUSE or VK_PLAY_PAUSEMandatory
Fast forward and fast rewindVK_FAST_FWD VK_REWINDMandatory
TEXT or TXT or comparable buttonNot available to applicationsMandatory
2 program selection buttons (e.g. P+ and P-)Not available to applicationsOptional
WEBTV or comparable buttonNot available to applicationsOptional
EXIT or comparable buttonNot available to applicationsOptional

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 nameNumeric ValueUse
RED0x1Used to identify the VK_RED key event.
GREEN0x2Used to identify the VK_GREEN key event.
YELLOW0x4Used to identify the VK_YELLOW key event.
BLUE0x8Used to identify the VK_BLUE key event.
NAVIGATION0x10Used to identify the VK_UP, VK_DOWN, VK_LEFT, VK_RIGHT, VK_ENTER and VK_BACK key events.
VCR0x20Used to identify the VK_PLAY, VK_PAUSE, VK_STOP, VK_NEXT, VK_PREV, VK_FAST_FWD, VK_REWIND, VK_PLAY_PAUSE key events.
SCROLL0x40Used to identify the VK_PAGE_UP and VK_PAGE_DOWN key events.
INFO0x80Used to identify the VK_INFO key event.
NUMERIC0x100Used to identify the number events, 0 to 9.
ALPHA0x200Used to identify all alphabetic events.
OTHER0x400Used 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.

Source code

Full source code is available here: https://github.com/HbbTV-Association/Tutorials/tree/main/rc-interaction

The code consists of:

  • rc-interaction.html HTML document holding the application scene
  • rc-interaction.css CSS document holding the application scene styling
  • rc-buttons.js JavaScript file which defines global variables for RC button events and 2 utility functions
  • rc-interaction.js JavaScript file holding the application logic

rc-interaction.html

Application HTML document rc-interaction.html starts off as a “usual” HbbTV app (see Hello world example):

<!DOCTYPE html PUBLIC "-//HbbTV//1.1.1//EN" "http://www.hbbtv.org/dtd/HbbTV-1.1.1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>RC interaction demo app</title>
    <meta http-equiv="Content-Type" content="application/vnd.hbbtv.xml+xhtml; utf-8" />
    <link rel="stylesheet" href="rc-interaction.css" />
    <script type="text/javascript" src="rc-buttons.js"></script>
    <script type="text/javascript" src="rc-interaction.js"></script>
</head>
<body onload="start();">
    <div>
        <object type="application/oipfApplicationManager" id="applicationManager"> </object>
    </div>

Observe that 2 JS documents are loaded:

  • 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).

Handling the broadcast a/v object

Posted on by domagoj@hbbtv

Before you read

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:

ValueMeaning
0unrealized; 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.
1connecting; 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.
2presenting; 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.
3stopped; 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):

Full source code is available here: https://github.com/HbbTV-Association/Tutorials/tree/main/broadcast-object

The code consists of:

  • 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:

Overview about HbbTV architecture

Posted on by domagoj@hbbtv

What is HbbTV® – and what is it not?

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 ® isHbbTV ® 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) behaviorCompletely 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.

Running a HbbTV application on a hybrid terminal

Posted on by domagoj@hbbtv

Introduction

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)

Generating the broadcast a/v stream

There are several online tutorials that explain how to generate the Broadcast stream with AIT data included, for example: https://github.com/cta-wave/dpctf-deploy/issues/1#issuecomment-771048901.

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:

DISCLAIMER:

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:

Validate installation by running the application from the web server by using one of the emulators, e.g. RedOrbit HbbTV Emulator or HybridTV Dev Environment. The Hello world application is contained within the hello-world directory.

Step 2: Install hbbtv-dvbstream from https://github.com/ebu/hbbtv-dvbstream following the tutorial available within the project’s README file.

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.

Common mistakes to avoid

Posted on by domagoj@hbbtv

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.

TRACKER

1. DOM element rendering with display:none

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.

5. Assuming HLS support

The HbbTV specification includes DASH and does not include HLS. While some HbbTV products support both HLS and DASH, in some cases this may be an accidental carry-over from Smart TV and not tested in the context of HbbTV. In any case, it’s unsafe to assume HbbTV terminals correctly support HLS.

If use of HLS content is a hard requirement then use of JavaScript HLS players like hls.js on top of MSE is recommended.

Although MSE was only formally introduced in HbbTV with specification version 2.0.3, in fact MSE support is widespread. It was commercially viable to deploy HbbTV applications that rely on MSE as early as 2018, see Kumpel-Tag mit Andy, (slide 18).

HbbTV 2.0.2 Explained

Posted on by domagoj@hbbtv

HbbTV Specification Versions

HbbTV specs have a formal name and an informal name

Informal NameFormal Name
HbbTV 2.0.2TS 102 796 V1.5.1
HbbTV 2.0.1TS 102 796 V1.4.1
HbbTV 2.0TS 102 796 V1.3.1
HbbTV 1.5TS 102 796 V1.2.1
HbbTV 1.0TS 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
    • Multiple Representation Multiple Preselection (MRMP)
      • Content contains multiple preselections
      • 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 / IssueFix 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.

HbbTV 2.0.3 Explained

Posted on by domagoj@hbbtv

HbbTV Specification Versions

HbbTV specs have a formal name and an informal name

Informal NameFormal Name
HbbTV 2.0.3TS 102 796 V1.6.1
HbbTV 2.0.2TS 102 796 V1.5.1
HbbTV 2.0.1TS 102 796 V1.4.1
HbbTV 2.0TS 102 796 V1.3.1
HbbTV 1.5TS 102 796 V1.2.1
HbbTV 1.0TS 102 796 V1.1.1

New in HbbTV version 2.0.3

In the version 2.0.3 of the specification following changes have been made (compared to version 2.0.2):

  • Errata to HbbTV 2.0.1 and 2.0.2
  • Added new features
  • Removal of unused features

Highlights of errata to HbbTV 2.0.1. and 2.0.2

Subject

Related bugs / issues

Improving integration between HTML5 video element and hardware media decoders

#9481: Potential conflict between HbbTV 9.6.2 and HTML5 re HTML5 load() method taking video & audio decoders

Related discussions also in W3C – https://github.com/w3c/media-and-entertainment/pull/34 

#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)
    • Updated web security specifications
    • HTTP/2 protocol support
  • TLS v1.3 protocol support (https://www.caniuse.com/tls1-3)
  • CMAF support
    • 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 if persistent storage of cookies & web storage is disabled (standard web feature, navigator.cookieEnabled, https://www.caniuse.com/mdn-api_navigator_cookieenabled)
  • 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:
    • A/V Control Object
    • OIPF DRM Object
  • Propose to move to the OpApp spec:
    • Push VoD including download manager
    • CI+ CICAM player mode

HbbTV releases Version 2021-2 of the HbbTV Conformance Test Suite

Posted on by domagoj@hbbtv

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.