The HbbTV.org website contains a FAQ section with useful information on various topics.

HbbTV application development requires specific knowledge about the HbbTV application stack and terminal limitations. Developers are advised to consult common mistakes to avoid, as well as other developer tutorials.


Full HbbTV specifications documents can be found here, while the online version of the full HbbTV API reference is available on this portal.


HbbTV application development and testing can be significantly simplified and accelerated by using publicly available resources.

The HbbTV Test Suite provides a set of test material to enable implementers to test receivers against the HbbTV specifications and other associated specifications (such as OIPF). National certification schemes, that usually award a locally commercially relevant logo for devices that are tested using formal lists of HbbTV and additional platform specific tests, often also list the certified compatible models.

A few examples are provided here:












Kaip pradėti – HiTV (telecentras.lt)

PlayReady security level is a property of a PlayReady client, and every license delivered to a client has a property indicating the minimum security level required from a client to allow binding to this license. More information on PlayReady security levels can be found here.


HbbTV service implementers should be aware that dash.js PlayReady implementations won't use security level SL3000 if KID and encryption keys are not distinct on all tracks. The issue is discussed here: https://github.com/Dash-Industry-Forum/dash.js/discussions/3869#discussioncomment-3528752


Note the comment from Microsoft:

One last thing to keep in mind: You will not actually get SL3000 security unless the actual AES content keys used to encrypt the content are different between streams (not just the KID). It's technically possible for a license server to issue licenses with different KIDs with the same content key.


So, HbbTV service implementers always need to use different distinct KID and encryption key for video track and audio tracks, if encryption key is identical then implementations will drop to security level SL2000 and not use the SL3000.

HbbTV® targeted advertising enables the delivery of digital video adverts over broadband that replace part of linear TV services received by terminals via DVB-T(2)/C(2)/S(2) and perhaps IPTV when based on MPEG-2 transport streams. Thereby, digital video adverts are shown on targeted terminals instead of the original broadcast adverts, which will be seen by viewers on all non-targeted terminals.

It is possible to deliver a targeted advertising experience using the standard features of HbbTV standard (ETSI TS 102 796), e.g. for a broadcast to broadband switch, calling the stop method on a video/broadcast object, waiting for the state change to complete and then calling play on an HTML5 video element, however the HbbTV® targeted advertising standard (ETSI TS 103 736-1) aims to enable a more seamless viewing experience.

For this purpose, HbbTV® targeted advertising defines the Fast Media Switch API and the corresponding switchMediaPresentation method:


The switchMediaPresentation method belongs to a non-visual embedded object of type "application/hbbtvMediaSwitcher", class MediaSwitcher. Applications seeking to use the Fast Media Switch API should first check XML device capabilities for one or more <ta> elements (the xmlCapabilities property of the "application/oipfCapabilities" embedded object) and then obtain the "application/hbbtvMediaSwitcher" embedded object either by fetching it from the DOM or by using MediaSwitcher createMediaSwitcher() method of the Object Factory HbbTV API, as specified in the Annex A1 of the HbbTV® targeted advertising standard (ETSI TS 103 736-1).

For example:

// ... the embedded object
<object id="mediaSwitcher" type="application/hbbtvMediaSwitcher" width="300" height="150"></object>
// ... obtain the object from the DOM
let theMediaSwitcher = document.getElementById("mediaSwitcher")