hbbtv specifications and related activities · 2019. 11. 22. · – test assertions to fill gaps...

HbbTV Specifications and Related Activities 2019

Consolidating HbbTV Technology

2019 - A Year of Consolidation for HbbTV

Specification Activities

• HbbTV 2.0.2 published in Sept. 2018– No core specification update in 2019

• 4 independent specifications– Application Discovery over Broadband

• Phase #1 published September 2016

• Phase #2 added in September 2019

– IPTV services and signalling published August 2017• No update in 2019

– Operator apps spec published May 2018• No update in 2019

– Targeted Advertising• Stable draft developed in 2019 but not yet published

2

HbbTV 2

• HbbTV 2.0.2 published in Sept. 2018– Stable in 2019

• Main focus in 2019 has been the test suite– Adding tests for HbbTV 2.0.2

• HDR video, HFR video, AC-4 audio, MPEG-H audio, other

– Fixing tests where someone found a problem

– Catching up on 2.0/2.0.1 backlogs ..• Tests which are delivered but not yet approved

• Tests which haven’t been ordered yet

HbbTV Association | Copyright © HbbTV 3

Application Discovery over Broadband Phase 2 ;

Watermarks


MUX

TERMINAL

APPTIMECODE

AUDIO+WM

VIDEO+WM

AIT

BROADBAND AIT SERVER

TIMECODEAUDIO+WMVIDEO+WM

AIT

BROADBAND APP SERVER

WM DATA

TIMECODE

AUDIO+WM

VIDEO+WM

AITEVENTS

EVENTS

EVENTS

• Enables HbbTV apps linked to services received by HDMI & other non-DVB interfaces– Also supports synchronisation to a timeline and stream events

• For more details see https://www.hbbtv.org/wp-content/uploads/2019/09/HbbTV-SPEC-

00446-000-Application-Discovery-over-Broadband-Explained-2019-09-09.pdf

APPLICATION URL

APPLICATION

AIT

AIT URL

DIS

TRIB

UTI

ON

DV

BIP

TVH

DM

I

WATERMARK EMBEDDERAUDIO

VIDEO

https://www.hbbtv.org/wp-content/uploads/2019/09/HbbTV-SPEC-00446-000-Application-Discovery-over-Broadband-Explained-2019-09-09.pdf

Operator Apps

• Operator apps spec published May 2018– Stable in 2019

• Focus in 2019 has been the test suite– 300 test cases delivered from the suppliers

– About half have been reviewed so far

• For more information– https://www.hbbtv.org/wp-content/uploads/2017/12/HbbTV-

SPEC-00200-003-Operator-Applications-Explained.pdfand

– the panel on "The HbbTV value for Operators“ later today


https://www.hbbtv.org/wp-content/uploads/2017/12/HbbTV-SPEC-00200-003-Operator-Applications-Explained.pdf

Why Develop a TA Spec?

• TA with HbbTV 1.5 is good enough to start an ecosystem but not good enough to sustain one

– Some advertisers want a 100% guarantee that ad playback will only start if it's certainthat it play to the end without stalling, buffering or cutting back to the broadcast ad

• Can only be achieved if the ad is loaded into RAM & played without any network access

– TA stresses parts of HbbTV 1.5 that haven't been stressed before• Can be variable between different implementations

• Requires white-listing or at least black-listing

– On many TVs• does not meet user expectations on transitions from broadcast to broadband and (particularly)

back to broadcast

• Does not comply with traditional broadcast quality standards

– "Landing period" requirements limit where & how often HbbTV 1.5 TA can be used• Not possible and/or acceptable to include several seconds of black or sacrificial content

everywhere it might be desirable to substitute an ad or to do it several times per hour


Primary TA Use-Cases

• Replace a single 30s ad in the broadcast– Either at the end of an ad break

– Or in at the start / middle of an ad break

– More opportunity for a "landing period" at the end of an ad break so timing requirements are more relaxed

• Also variations where replacing consecutive ads is done by combining the replacements into a single stream– Can be combined into a single stream in the cloud

– Can be combined into a single stream by the HbbTV app running in the terminal

– In both of these only one switch from broadcast to broadband and one switch back again


Step by Step TA Walkthrough

1. Broadcaster sends message to app announcing that 'placement opportunity' is near– Existing HbbTV mechanisms can be used

• Some additional testing / clarifications required for reliability

– Perhaps new mechanism based on SCTE-35

2. App asks ad server for an add that could be played– Response uses existing web advertising standards ("VAST")

3. App preloads ad– Preload may be 100% if there's enough RAM / depending on broadcaster / advertiser requirements

• 100% preload uses Web "Media Source Extensions" API – new in HbbTV TA spec

4. App tells TV /STB when to switch from broadcast to ad– New "fast media switch API“ in the TA spec

5. App reports back on playback of ad– Critical otherwise nobody gets paid

6. App switches back from ad to broadcast– Also using new "fast media switch API"


2 TA Profiles for Switching Performance


Profile #1 Profile #2

Target implementation Single decoder Dual decoder

Target use-case Replace ad(s) at the end of an ad break

Replace ad(s) anywhere in an ad break

Broadcast to broadband switching duration

<= 240ms <=120ms

Broadband to broadcast switching duration

<= 240ms <=120ms

Switching accuracy 40ms 40ms

Decoding broadcast while ad is playing No Yes

Typical landing period(with 1.5s GOP in the broadcast)

2.06s = 1.5s + 2*(240ms+40ms) 320ms = 2*(120+40)

Inter-operability

• DASH content validator - https://github.com/Dash-Industry-Forum/Conformance-Software– For more details, see https://www.hbbtv.org/wp-content/uploads/2018/11/DVB-HbbTV-DASH-

Validation-Tool_explained_v1.0.pdf

• HbbTV-DASH-DRM reference app– Created in 2018 to address concerns about lack of HbbTV+DASH+DRM examples & reports of

inter-op problems• https://github.com/HbbTV-Association/ReferenceApplication

• For more details see https://www.hbbtv.org/wp-content/uploads/2018/11/HbbTV-MG-00472-002-DRM-Reference-Application-Explained.pdf

– 2019 focus on consolidation• Small functional extensions

Multiple audio tracks

A first small step towards low-latency DASH

• More formal & stable Separate production and staging instances

• Checked against a receiver zoo Basic DASH+DRM works almost everywhere


https://github.com/Dash-Industry-Forum/Conformance-Software

https://www.hbbtv.org/wp-content/uploads/2018/11/DVB-HbbTV-DASH-Validation-Tool_explained_v1.0.pdf

https://github.com/HbbTV-Association/ReferenceApplication

https://www.hbbtv.org/wp-content/uploads/2018/11/HbbTV-MG-00472-002-DRM-Reference-Application-Explained.pdf

DASH-DRM Reference Application

11

0,00

50,00

100,00

150,00

200,00

Jan Feb Mar Apr May Jun Jul Aug Sep Oct

Tx (GiB)

GiB

0

2000

4000

6000

8000

10000

12000

14000

16000

Jan Feb Mar Apr May Jun Jul Aug Sep Oct

Visitors

Visitors

HbbTV Association | Copyright © HbbTV

HbbTV Interop Events (“Plugfests”)

• 2 HbbTV sponsored interop events this year– #33: July 1st+2nd

– #34: October 30-31

• Also a number of national interop events– Spain

– UK

– …

• These events enable face to face discussions between app / tool providers and device implementers

– Problems often get more attention during an interop event

• HbbTV open to sponsor national interop events if they are opened to everyone

– Reduce the number of events to attend


Looking Forwards – HbbTV 2

• Work is just starting on two specification updates:– HbbTV 2.0.3, (what will be proposed to ETSI as TS 102 796 V1.6.1).

• The main new element of this update is removing unused features (“spring cleaning”)

• No big new features – just updates to existing features Update basic web standards from 2013 to 2018

W3C Media Source Extensions incl. support for low-latency DASH via dash.js or similar

Update OTT streaming to include CMAF and indicating if Apple ‘cbcs’ encryption

– An update to the OpApp spec• Fix bugs

• A few new requirements incl. adding support for loading an OpApp from a CI+ module

• There is a backlog of activities that will only happen when there are enough contributors:– Test assertions to fill gaps and check that errata are implemented

– Investigation of how DVB-I and HbbTV could fit together.

– Identification of which parts of the HbbTV 1.0/5 A/V control object could be replaced by a web "polyfill" and if those that could not be replaced in this way could be deprecated or dropped.


Deprecating Unused and Duplicated Features

• Candidates to be dropped immediately– CI+ host player mode aka "DRM in a

CAM”

– HbbTV app launching an app on a companion screen

– 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 move to the OpApp spec– Push VoD incl. download manager

– CI+ CICAM player mode

• Re-consider in next requirements cycle– PVR

• Candidates to be dropped at some time in the future

– DOM-0 events / event listeners

– A/V Control Object

– OIPF DRM Object

As these are used by apps today, plenty of notice will need to be given!

Also stop growing these features or rewind additions made in HbbTV 2


Looking Forwards – Independent Specs

• TA– Create and reviewing unit test descriptions

– After publication, in parallel;• Develop early receiver implementations

• Develop unit tests

– Run unit tests on early receiver implementations• Iteratively improve both

• OpApps– Now updating spec

• Integrating improvements from early experiences & bug fixes

• One new feature – launching OpApp from CI+ module

• Simplify the “bilateral agreement” process


Looking Forwards – Testing and Interoperability

• Testing– Further improving the coverage of the 2.0.1/2 specification

– Further reducing the 2.0/2.0.1 backlog

– Reducing the backlog of OpApp tests to be approved

– Tests for HbbTV 2.0.3

– Tests for independent specs (tbc) – TA, ADB #2

• DASH validator– Perhaps co-operate with DVB and DASH-IF to address what’s new - low

latency? HDR dynamic mapping?

• DASH DRM reference app– Simulate results of server-side ad insertion – multiple periods


Opportunities for Contributors

HbbTV Association | Copyright © HbbTV

17

Requirements Group

SteeringGroup

SteeringGroup

Approvesa specification

activity

Developsrequirements

Approvesrequirements

SupplierEvaluation

WG

Writesspecificationand unit testdescriptions

SteeringGroup

Approvesspecification

for publicationand sending to

ETSI

SpecificationGroup

Obtainsquotations

for test Suite,evaluates andrecommends

to SG

TestingGroup

Organisesreview andacceptance

of tests

SteeringGroup

Approvestest suiterelease

ImprovingInteroperability

Task Force

Collectsfeedback on

interoperabilityin the market

SteeringGroup

Decides onrecommendation

From SEWG

hbbtv specifications and related activities · 2019. 11. 22. · – test assertions to fill gaps...

Documents