Tutorials

Hello World Application

Interaction with the remote control

Handling the broadcast a/v object

Basic Screen Logger

Overview about HbbTV architecture

Running a HbbTV application on a hybrid terminal

Common mistakes to avoid

HbbTV 2.0.2 Explained

HbbTV 2.0.3 Explained

HbbTV 2.0.2 Explained

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.