deliverable - 5g-victoritvring.eu/wp-content/uploads/deliverables/tv-ring-d3.1... · 2014-12-11 ·...

1 version 2.1, 18/03/2014

TV-RING D3.1 SERVICE CONCEPTS DESCRIPTION

DELIVERABLE

Project Acronym: TV-RING

Grant Agreement number: 325209

Project Title: Television Ring - Testbeds for Connected TV services using HbbTV

D3.1. Service concepts description

Revision: 2.1

Authors:

Daniel Giribet (TVC)

Joost Negenman (NPO)

Susanne Heijstraten (NPO)

Aylin Vogl (IRT)

David Cassany (I2CAT)

David Pujals (RETE)

Project co-funded by the European Commission within the ICT Policy Support Programme

Dissemination Level

P Public x

C Confidential, only for members of the consortium and the Commission Services

Abstract: This document gathers the analysis of requirements obtained in WP2, compiles service concepts as storyboards and provides video parameters for the execution of the pilots.

2 version 2.1, 18/03/2014


Revision History

Revision Date Author Organisation Description

1.0 20/11/2013 Daniel Giribet TVC Index created & templates added

1.1 29/11/2013 Daniel Giribet TVC Added storyboards & Pilot 3 video service descriptions

1.2 20/01/2014 Joost Negenman/

Susanne Heijstraten

Ammar Tijani

NPO

PPG

Added description & Pilot 1,2,3 video service descriptions

1.3 28/01/2014 Aylin Vogl IRT Integrated IRT components

1.4 28/01/2014 Daniel Giribet TVC Integrated TVC components & added IRT component reference

1.5 29/01/2014 Aylin Vogl IRT Added storyboards & service concepts

1.6 30/01/2014 David Pujals RETE Clarification on CDN usage in Pilot 3

1.7 31/01/2014 David Cassany I2CAT Extra components

1.8 31/01/2014 Joost Negenman/

Susanne Heijstraten

Ammar Tijani

NPO

PPG

Added detailed descriptions, storyboards and applicable user requirements

1.9 11/02/2014 Daniel Giribet TVC Final draft

2.0 24/02/2014 Daniel Giribet TVC Near final version

2.1 18/03/2014 Sergi Fernández i2CAT Final revision and formatting

Statement of originality:

This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.

Disclaimer

The information, documentation and figures available in this deliverable, is written by the TV-Ring (Testbeds for Connected TV services using HbbTV) – project consortium under EC grant agreement ICT PSP-325209 and does not necessarily reflect the views of the European Commission. The European Commission is not liable for any use that may be made of the information contained herein.

3 version 2.1, 18/03/2014


1. Executive Summary

This deliverable presents the results of task T3.1 (“Service and application concepts”) of the TV-RING project. This task has two main goals: firstly, to refine and analyse the concepts and requirements discovered in tasks of WP2 (mainly tasks T2.2 and T2.3) and secondly to have a first iteration and discovery of any MPEG-DASH video services required to deploy the project pilots. Concept and requirement analysis can be done very effectively by converting user and component requisites into user flows and storyboards. Such a technique allows product teams to turn abstract concepts into more specific ideas that greatly ease the transition into full application and system development, seamlessly leading into the integration tasks further along WP3. On top of that, given that video plays such an important role in all pilots, it is also greatly beneficial to materialise details about the video services required for each pilot, by providing an initial list of technical and content details such as expected video sources, formats, encoding and any other technical parameters known at this stage of the project. Mainly, this deliverable details the process of transforming abstract requirements into more specific information in each area of the project.

The analysis process described in this document outlines and expands on the aforementioned WP2 tasks for each pilot. Firstly, the Dutch pilot defines three scenarios, namely content quality differentiation using DRM, personal recommendations and the role of second screen paired with HbbTV. Secondly, the German pilot defines a unified documentary TV proposition with a strong interactive HbbTV component targeted at young audiences. Finally, the Spanish pilot refines the concepts around multicamera high-quality services, where users can seamlessly select across many points of view. Such analysis includes the aforementioned list of identified video services for each pilot and its scenarios.

Finally, at the end of the document a first listing of hardware, software and systems components that have been identified to be needed for the completion of the different pilots. Additionally, within the list some shared components have already been clearly marked, such as common MPEG-DASH test videos and encodings.

Completion of work such as presented in this document is key to completing analysis tasks T3.2 and further advancing the development of T3.3 and T3.4.

4 version 2.1, 18/03/2014


2. Contributors

First Name Last Name Company e-Mail

Daniel Giribet TVC [email protected]

Joost Negenman NPO [email protected]

Aylin Vogl IRT [email protected]

David Cassany i2CAT [email protected]

David Pujals RTV [email protected]

mailto:[email protected]





5 version 2.1, 18/03/2014


Content

Revision History ......................................................................................................................... 2

1. Executive Summary ................................................................................................................ 3

2. Contributors ........................................................................................................................... 4

3. Introduction ........................................................................................................................... 8

4. Dutch Pilot service concepts .................................................................................................. 9

4.1. Compiled service concepts ............................................................................................ 9

4.1.1. Scenario 1 - Quality differentiation by using DRM ................................................ 9

4.1.2. Scenario 2 - In house recommendations for HbbTV ........................................... 11

4.1.3. Scenario 3 - HbbTV as central interface for second screen competition ............ 15

5. German Pilot service concepts ............................................................................................ 22

5.1. Compiled service concepts .......................................................................................... 22

5.1.1. “Abenteuer Liebe” ............................................................................................... 22

5.1.2. TVAppGallery ....................................................................................................... 27

6. Spanish Pilot service concepts ............................................................................................. 31

6.1. Compiled service concepts .......................................................................................... 31

6.1.1. On demand content scenario .............................................................................. 31

6.1.2. Live content scenario .......................................................................................... 35

7. Pilot service parameters ...................................................................................................... 38

7.1. Dutch Pilot video service parameters ......................................................................... 38

7.2. German Pilot video service parameters ...................................................................... 43

7.3. Spanish Pilot Video service parameters ...................................................................... 44

8. System components ............................................................................................................. 50

8.1. IRT ................................................................................................................................ 50

8.1.1. BRAHMS (SW) ...................................................................................................... 50

8.1.2. Second Screen Framework (SW) ......................................................................... 50

8.1.3. TVAppGallery Backend (SW, prototype!) ............................................................ 51

8.1.4. Elemental Server (HW) ........................................................................................ 52

8.1.5. Elemental Live (HW) ............................................................................................ 52

8.1.6. OTT-Server VS7000 (HW) .................................................................................... 52

8.1.7. MPEG-DASH video testing material .................................................................... 53

8.2. TVC .............................................................................................................................. 54

8.2.1. WOWZA Media Server (SW) ................................................................................ 54

8.2.2. Handata Flowserver (SYS) ................................................................................... 54

8.2.3. TV3 ALACARTA HBBTV APP (SW) ......................................................................... 55

6 version 2.1, 18/03/2014


8.2.4. Video Mosaic Generator (SYS) ............................................................................ 55

8.3. i2CAT ........................................................................................................................... 56

8.3.1. MPEG-DASH Media server (SW prototype)......................................................... 56

8.3.2. Media Content Delivery Network (SYS prototype) ............................................. 56

8.4. RTV .............................................................................................................................. 56

8.4.1. Content Delivery Network (SYS) .......................................................................... 56

9. Conclusions .......................................................................................................................... 58

7 version 2.1, 18/03/2014


Table of Figures and other objects

1.(Figure 1) User Logs in to ODM platform ................................................................................. 10

2.(Figure 2) User selects account type (payment is not part of the pilot scope) ........................ 10

3.(Figure 3) To emphasis conversion users will be confronted with options for more content or

better quality ............................................................................................................................... 10

4.(Figure 4) Test group will have to accept usage monitoring once. .......................................... 12

5.(Figure 5) When opening HbbTV Portal, recommendations will appear based on Video

Statistics ...................................................................................................................................... 13

6.(Figure 6) Recommendations can be revealed on every page ................................................. 13

7.(Figure 7) One out of the ten polls you have to answer during the show on your second

screen .......................................................................................................................................... 16

8.(Figure 8) Individual final result second screen app. For 60% you judged like the judge ....... 16

9.(Figure 9) Average results of all the people who participated and the scores of your friends

(who participated with a Facebook or Twitter login).................................................................. 17

10.(Figure 10) Overall results of all players of the second screen app as displayed on the TV

screen .......................................................................................................................................... 17

11.(Figure 11) The overlay acting as a scoreboard ..................................................................... 17

12.(Figure 12) German pilot HbbTV application storyboard ....................................................... 24

13.(Figure 13) German pilot storyboard of interaction during the show ................................... 25

14.(Figure 14) German pilot after the show interaction storyboard .......................................... 26

15.(Figure 15) German pilot TV application gallery storyboard .................................................. 29

16.(Figure 16) On-demand TVC Spanish pilot storyboard .......................................................... 34

17.(Figure 17) Live TVC Spanish pilot storyboard ...................................................................... 37

18.(Figure 18) Device portal logo ................................................................................................ 51

19.(Figure 19) Handata Flowserver TVC testing instance setup interface example ................... 55

20.(Figure 20) TV3Alacarta HbbTV application screenshot ........................................................ 55

21.(Figure 21) CDN basic structure diagram ............................................................................... 57

8 version 2.1, 18/03/2014


3. Introduction

This deliverable presents the results of task T3.1 (“Service and application concepts”) of the TV-RING project. This task has two main goals: firstly, to refine and analyse the concepts and requirements discovered in tasks of WP2 (mainly tasks T2.2 and T2.3) and secondly to have a first iteration and discovery of any MPEG-DASH video services required to deploy the project pilots. Mainly, this deliverable outlines the process of transforming abstract requirements into more specific details in each area of the project.

As it is common in requirement analysis, requirements were broken down into specific ‘scenarios’, containing further details and materialising some design decisions in the shape of storyboards or sorted user activity diagrams. The results of this process are presented in the present document.

On sections 4, 5 and 6, the Dutch, German and Spanish analysis are detailed whereas in sections 7, 7.2 and 7.3, the different video services for each pilot are outlined. While following a common pattern, each pilot focuses on delivering different value-added services within the context of HbbTV applications and MPEG-DASH video delivery.

Completion of work such as described in this document is key to completing analysis tasks T3.2 (Mockups and Intermediate Evaluation) and further advancing the development of tasks T3.3 (Application Implementation) and T3.4 (Backend/platform Implementation).

9 version 2.1, 18/03/2014


4. Dutch Pilot service concepts

4.1. Compiled service concepts

The NPO, together with KU Leuven and PPG, will focus on user experience and engagement in order to expand the video consumption on the HbbTV portal. The Dutch project consists of three main scenarios or areas of work. Firstly, studying content quality differentiation by using DRM techniques, secondly, developing personal recommendations for HbbTV based on content usage by different members in a household and finally investigating HbbTV as central interface for group second screen competition in a home network.

4.1.1. Scenario 1 - Quality differentiation by using DRM

In the first scenario we want to investigate if it is possible to differentiate in stream rate quality

by using DRM technique.

We want to investigate the following questions:

• Can we simplify the encoding process and differentiate the quality of content based on

one key with different statuses (basic, premium and gold)?

• Test user perception of service (objective and subjective). Are people willing to pay more for HQ content?

We create four different profiles that have one key, with different access to the content.

The first user has no key and no access The second user is a member or has a login and has access but limited to 1 mbit The third user has a premium account and pays €5 per month for 2,5 mbit The fourth user is a gold member, pays € 10 per month and has 5 mbit access

We can differentiate in the stream rate quality of the content but also in the supply of various content.

We want to investigate the technical consequences and possibilities of using DRM technique but also the willingness to pay for various types and quality of content. For this scenario we will use the content of the Dutch Catch-up TV service (‘Uitzending gemist’).

We can test in the module if people experience different types of quality and if this is depending on the type of content (drama series or movies can maybe differ from human interest programs). Based on literature study we will also investigate the willingness to pay for different quality of content.

The scenario will produce a new business model and we can investigate if the market is willing to embrace this. Now the user pays for the use anyway, if there is a free version the provider gets a percentage based on the conversion.

10 version 2.1, 18/03/2014


1.(Figure 1) User Logs in to ODM platform

2.(Figure 2) User selects account type (payment is not part of the pilot scope)

3.(Figure 3) To emphasis conversion users will be confronted with options for more content or better quality

Within this scenario we will examine the professional user requirements as defined in the deliverable D2.3 (List of professional requirements):

Req 01: Because of the relatively small number of interactive TV users, applications should be cost effective.

- By using DRM Techniques and one key with different levels of access we only need to encode the content just once and this will be a lot cheaper instead of encoding

email

password

login to ODM service

login Create account

Choose account

ok

BASIC free

PREMIUM SD 4 Euro pm

PREMIUM HD 8 Euro pm

11 version 2.1, 18/03/2014


multiple times. We are going to investigate if DRM parties are open for new business models.

Req. 06: Create a way to share and spread knowledge. - The results of this scenario will be shared with the industry. We will discuss the

outcome and impact with involved parties.

Req. 07: Be aware of scaling issues for bandwidth when developing for large groups of users.

- By using DRM Techniques and one key with different levels of access we need to encode the content just once and this will be using less bandwidth instead of encoding multiple times.

Req.10: To get a good understanding of what users expect from interactive TV more user research is needed.

- Based on literature study we will examine the willingness to pay for various kinds and different quality of content. In this module we can test if people experience different kinds of quality in video content.

Req 44: Make receivers with Mpeg-Dash streaming available for the pilot. - For the scenario we will transcode NPO video’s to mpeg dash with encryption.

Req 52: Deliver the best possible bitrate quality that each user’s connection can afford or receive.

- Adaptive streaming (MPEG DASH /HLS) can offer a variety of qualities and we will apply this in the scenario to offer different stream rate quality.

Req 53: Enable adaptive streaming to maximise the user experience with the service in the most efficient way.

- Meaning that the user gets the highest possible quality it can receive, depending on his internet bandwidth and the willingness to pay for this.

Req 57: Enable segmentation of users by bandwidth for audience analysis. - We have to distinguish different users in the pilot with different types of access.

We investigate their willingness to pay for different quality and supply of content.

In this scenario the following end user requirements from deliverable D2.2 (List of user requirements) apply:

Req.23: Content should be available for a longer period. - In the scenario we will investigate how we can vary with the different levels of

access and the offer of available content.

Req.30: The video quality should be much better and/or selectable. - In the pilot we will examine if people experience different levels of quality as

well as if they are willing to pay for this and if this is depending on the type of content or not.

Expected result

A POC that will lead to a simplified en more cost efficient encoding environment for broadcasters and new business models for DRM delivery and companies.

4.1.2. Scenario 2 - In house recommendations for HbbTV

The goal of this pilot scenario is to scan household video content consumption by a family and present recommendations for individual persons on the central HbbTV set. We want to develop an intelligent recommendation-engine that presents personal recommendations, using variables as time of day, device status and historical data.

12 version 2.1, 18/03/2014


The question we want to answer is as follows:

How can we measure all NPO on-demand usage in a household and how can an HbbTV

app make recommendations with this information, making the TV even smarter?

We need a few families with children (two adults with two children of different ages), who are using different devices within their household to watch VOD content. We want to investigate which content they watch, at what time and with which device. Can we develop a recommendation engine that suggests, on a personal basis, programs based on the information gathered and that are interesting for that particular person? We need permission and access to the IP data to analyse and generate personal recommendations.

In the module there will be one non-personal device, the central TV in a household, and there will be multiple personal devices like tablets, smartphones, etc. Based on IP we can check time of day, which content is being watched (program title, genre), on what device. For this we need permission for the access to IP data for a closed period of time, at least three months. Based on the gathered information and historical usage we are going to generate recommendations. We want to attract about 15-20 families who are willing to participate in the investigation and who are using HbbTV. We have to create different profiles, families with and without children, people who have jobs and who haven’t, etc. (check Nibud/CBS).

The goal is to create recommendations tailored to individuals within a household. For this module we will make use of the existing Dutch Catch-up TV service (‘uitzending gemist’). The module will consist of 2 different phases. We start with paper prototyping, interface design, wireframes and mock-ups, and in a second phase we will create a live environment. For these two different phases we will attract different families to participate so that expectations in the second phase will be excluded. In the live environment we will collect data based on IP address and conduct interviews and observations to examine the results on different moments in time.

4.(Figure 4) Test group will have to accept usage monitoring once.

Do you accept usage monitoring?

Okee

Yes

read more >>

13 version 2.1, 18/03/2014


5.(Figure 5) When opening HbbTV Portal, recommendations will appear based on Video Statistics

Recommendations in this situation are grouped in two parts,

Red for most possible viewer, the particular person we are almost sure is watching at that time of day

Blue for possible viewer, one of the expected members of the household

6.(Figure 6) Recommendations can be revealed on every page

By browsing through content the system can adapt itself live and become more positive on the most possible viewer.

Within the second scenario we will examine the following professional user requirements as defined in D2.3.:

Req. 5: Do user research to broaden the knowledge base. - We are going to investigate how we can track viewing habits and based on this

if personal recommendations fit well enough.

Req. 6: Create a way to share and spread knowledge. - Share the results and knowledge with the industry. We will share the results

with demo’s on events and workshops.

Req 10: To get a good understanding of what users expect from interactive TV more user research is needed.

- We are investigating what people watch with which device on a certain time. Based on these results we are expecting to create personal recommendations. We have to examine if these actually meet the expectations of the users.

14 version 2.1, 18/03/2014


Req. 11 Get younger viewers more involved by offering interactive extras without alienating older viewers.

- Within the pilot we want to offer different recommendations for children and adults.

Req. 13 Whether content is live or on demand, this should not make a difference for users’ experience.

- We should be able to create recommendation based on VOD and live content.

Req 25. Retain viewers by offering interesting interactive TV alternatives after their show ends.

- We can try to do this by offering recommendations that are in line with the program people just watched.

Req. 28: Use interactive TV to offer viewers more personalized experience by allowing them to participate or selecting different items.

- We create a more personalized experience through individual recommendations based on personal preferences.

Req. 32: CMS and use of metadata must be integrated in a way that essence data sets can be maintained easily.

- The system should be able to provide data based on IP and this data must be analysed to create recommendations.

Req. 55: Create an on screen questionnaire to evaluate the user experience with the service.

- It would be nice if we could ask users immediately if the recommended content is satisfying.

Req. 58: Enable segmentation of users by device for audience analysis. - Based on the device we can detect who is watching a certain program.

Req.59: Enable segmentation of users by socio-demographic variables and consumption patterns for audience analysis.

- Based on age, the use of device and time of day we try to track the current consumption pattern.

Req. 60: Enable the tracking of the content consumption of each unique user across multiple devices.

- In the investigation we will enable people in a household to watch via different devices, live and/or VOD content.

Req.61: Enable the collection of all audience related video-start-data in a single system that analysis and on the base of that delivers personal recommendations to HbbTV Portals.

The following end user requirements from D2.2 will apply on this scenario:

Req.02: For continued use, robustness and ease of use are indispensable. - It must be very simple to navigate through the personal recommendations

formulated for each individual.

Req. 24: Notifications on availability of content. - We can investigate how people like to be informed about the recommended

content and how this can be presented the best.

Req. 25: More on demand content for kids. - We are going to compose test groups existing of adults and children. We have

to create special recommendations based on content for kids.

Req.28: Navigation should be made easier and more intuitive. - It must be very simple to navigate through the personal recommendations

formulated for each individual.

15 version 2.1, 18/03/2014


Req. 31: When analysing user patterns of TV watching in the pilot take into account the phenomenon of the ‘always-on TV’.

- We need to investigate if this is indeed the case and we need to take this into account when analyzing the data.

Req.32: When analysing user patterns of TV watching in the pilot take into account the phenomenon of low attention visualisation.

- We need to investigate if this is indeed the case and we need to take this into account when analyzing the data.

Req. 37: Design a content recommendation system that meets the user expectations in terms of usability, degree of personalisation, quality of recommendations and privacy issues.

- This is what the scenario is all about.

Expected result

Creating a new data set for family (network) recommendations based on actual (family) usage. This data can become part of a larger recommendations engine. When this data is delivered to the HbbTV portal, it makes the TV really smart, for it is possible to know who is (or are) watching.

In the second phase of gathering requirements for professional and end users (M13-M16) we can add more requirements regarding recommendations we encounter in the pilots. We can also consider the results of the HbbTV Next project.

4.1.3. Scenario 3 - HbbTV as central interface for second screen

competition

In scenario 3 we want to investigate how an HbbTV App can act as central interface for group second screen play-along, in a home network.

Questions we want answered:

• How to pair all (2nd screen) devices in a household and by social media to one ‘master’

app and how can we synchronize these results with HbbTV?

• How do we keep it scalable (Cloud)

• How do we manage and encourage in-house “real” social interaction and create and

encourage a competition model?

We use an existing second screen app called “De Rijdende Rechter”. A court deals with a case between two people and makes a statement at the end about which of the two parties are within their rights.

People can watch the show and get about ten statements during the show on their second screen where they can indicate for each statement whether they agree or disagree. They can login with Facebook or Twitter and can see who of their friends are playing along. After each statement you see the results of your friends and the rest of the people who are playing. At the end of the show you get an overall result and you can see how much percentage you look like the judge and what are the scores of your friends and the rest of the people who are playing.

Second screen app ‘De Rijdende Rechter’

16 version 2.1, 18/03/2014


7.(Figure 7) One out of the ten polls you have to answer during the show on your second screen

8.(Figure 8) Individual final result second screen app. For 60% you judged like the judge

17 version 2.1, 18/03/2014


9.(Figure 9) Average results of all the people who participated and the scores of your friends (who participated with a Facebook or Twitter login)

10.(Figure 10) Overall results of all players of the second screen app as displayed on the TV screen

(TV-Show ‘De Rijdende Rechter’)

11.(Figure 11) The overlay acting as a scoreboard

In the scenario we want to connect the different devices of all people in a household, playing individually the app, to one ‘quizmaster’ device. This ‘quizmaster’ device must synchronize with HbbTV and show the results of the different players on the central screen. This will encourage competition and live interaction between the people who are playing in the same living room.

For this scenario we will use the existing technology of ‘Angry Bytes’ to connect different personal devices to one main ‘quizmaster’ device. It’s possible to make a direct Wi-Fi connection or a connection through Facebook. The quizmaster device has to aggregate all individual results and on the first screen the overall results of your own score and the scores of your friends will be displayed.

The scenario will be focusing on three different shows of the ‘Rijdende Rechter’, based on video on demand. We will add English subtitles on these three shows so it will be understandable for everyone. In the current second screen app it’s obligatory to create an account. In this pilot we will make it possible to participate without an account.

18 version 2.1, 18/03/2014


In this case we have to create a user test group consisting of 10-15 families using HbbTV. Ideally this will be the same test group as we use in the second scenario.

The concept will be developed in different phases. We start with usability work, mock-ups and paper prototyping based on the second screen app in combination with the first screen based on simulation.

We will gather the results by observation, interviews and short surveys based on social user experience.

The following professional requirements of deliverable D2.3 apply on this scenario:

Req.1: Because of the relatively small number of interactive TV users, applications

should be cost effective.

- The use HbbTV as a aggregator should encourage to more usage of HbbTV.

This will make it more interesting for app developers and program makers to

develop for HbbTV.

Req. 3: It’s essential to have an easy to use CMS system for program-makers to add

content to apps or be able to make the apps themselves.

- This will partly take away a 3d party development and thereby reducing the

cost and enhancing quality because of the direct connection Program maker –

App. In this scenario we will investigate the ease of use of a particular CMS for

second screen apps connected to the TV. We will transform the existing

‘Rijdende Rechter’ app to a second screen system developed by AngryBytes

which makes it possible to display results directly on the first screen.

Req.4: Make sure apps are technically sound.

- The second screen app has to function very smooth and the connection with

the quizmaster tool and TV have to work seamless.

Req.5: Do user research to broaden the knowledge base.

- We will do user research in the scenario based on surveys, observation and

interviews.

Req.6: Create a way to share and spread the knowledge base.

- We will share the results and what has been learnt with the industry. We will share the results with demo’s on events and workshops.

Req.8: When using multiple screens, smooth synchronisation between these screens is

essential.

- There have to be a smooth connection between the different devices and the

quiz master tool so results will be displayed simultaneously and there have to

be a smooth connection between the quiz master tool and the TV to display all

the individual results on the central screen.

Req.9: To stimulate group interaction it is important to allow all participants to

interact on an individual level while showing scores on a shared screen.

- This is what the scenario is all about.

Req.10: To get an understanding of what users expect from interactive TV more user

research is needed.

19 version 2.1, 18/03/2014


- We are going to do user research based on observations, surveys and

interviews.

Req.13: Whether content is live or on demand, this should not make a difference for

the user’s experience.

- We can test this both on VOD content and live content. On VOD content a few

functionalities will not work (like the scores of your Facebook friends).

Req.14: If you want people to watch your programs live, entice them with an

interactive experience.

- People can participate during the show, although it’s not a live program.

Req.18: When developing interactive TV apps it’s important not to intrude (too much)

on the experience of the regular viewer.

- We can observe and investigate people’s experience with this while they are

using the app and watching the show. Are they distracted too much from the

first screen?

Req.19: A good dialogue between program maker and app developer is essential.

- We test if there are enough teasers to the second screen app and how the

interaction between the first and second screen is.

Req. 21: For non-fiction shows, it is possible to create a more content heavy second

screen experience, as these shows does not usually require constant attention.

- We can observe how much people are distracted from the show while playing

the app.

Req.22: Let viewers join in on the competition of a game show.

- That is what it is all about. People can play individually on a personal device

and their scores are presented on the first screen, so they create their own

internal competition.

Req. 23: Ease of use in both discovery and accessibility is crucial for any second screen

app.

- We are going to offer the app with and without the possibility to create an

account. We can also experiment with (shared) codes to enter the app.

Req.24: A way for users to interact with others watching the show is necessary for

most apps.

- In the scenario users can share their scores on the central screen and discuss

about it. We can observe if this indeed creates more discussion and

interaction.

Req.26: A good second screen experience can enhance attention to first screen.

- We can observe if viewers are distracted from the first screen or enhance

attention in this particular case.

Req.28: Use interactive TV to offer viewers more personalized experience by allowing

them to participate or selecting different items.

- Users can play individually and they can compare their scores with the score of

the program but also with the scores of their friends and family. We expect

this will create a more personalized experience.

Req.40: Servers for providing HbbTV applications must be failsafe and run reliable.

- The systems have to work smoothly for a good experience.

20 version 2.1, 18/03/2014


Req.60: Enable the tracking of the content consumption of each unique user across

multiple devices.

- The results of different devices used by individuals have to be gathered by one

‘quiz master’ device.

Finally, end user requirements as defined in deliverable 2.2 that will apply on this scenario:

Req.1: Interactive TV applications should have very low threshold to get users started.

- The goal and operation of the app must be easy and simple to encourage

participation.

Req.2: For continued use, robustness and ease of use are indispensable.

- Experience test users ease of use and robustness? Or do they quit easily?

Req.3: Perfect synching between multiple screens is essential for a good user

experience.

- How do test users participate the synching between the different screens?

Req.4: Make sure interactive TV apps function just as well on delayed viewing.

- We are going to perform the pilots on VOD content within a household.

Req.7: To stimulate interaction in the living room provide polarizing or controversial

topics.

- Does the quiz also stimulate interaction in the living room although it’s not

controversial?

Req.8: The value of social media features in an interactive TV app is dependent on the

show genre.

- Do test users use the sharing buttons? Do they use social media while

watching the show and playing the app?

Req.9: Give a clear indication when new content is available on the second screen as

well as how much time there is before the next update.

- Does this work well in the app? What do people expect when they are playing

the app?

Req.10: If possible use cues on the show to call attention to updates on the second

screen.

- Show updates on the overlay of HbbTV as well.

Req. 16: Provide viewers with easy in app access to info that can be found elsewhere

on the internet.

- In the case of the ‘Rijdende Rechter’ we can experiment for example with

explanation of legal concepts in the app it selves.

Req.18: When asking viewers for input try to have their answers have an impact.

- To show the results on the first screen and compare them to others it will have

impact on the experience of watching the show.

Req.19: Provide viewers with extra info related to the show that would not receive

when watching the show without the interactive app.

- In the second screen app we could add extra information e.g. the explanation

of the judge for the elected ruling and observe if people use this extra

information and investigate if they appreciate it.

21 version 2.1, 18/03/2014


Req.20: When creating info updates for interactive TV apps make sure these updates

are not so complex viewers get distracted from the show if they want to consume

these updates.

- Do we observe people get distracted?

Req. 21: Possibility to vote easily and directly on TV screen.

- We can investigate if it’s also possible to play along directly via the HbbTV app.

Req. 33: Design TV applications so that they support and not inhibit the natural social

interactions that arise during TV watching.

- Does the app create a natural kind of interaction between the people who are

playing together?

Req.42: Explore opportunities for the development of advanced applications.

- This scenario can be a showcase for a lot of other concepts.

Expected result

A powerful add-on for the second screen framework, that allows broadcaster to add an

engaging layer to the Live Broadcast. This way we hope to encourage social interaction within

the household while watching favourite shows.

22 version 2.1, 18/03/2014


5. German Pilot service concepts


The current section describes the service concepts of the two scenarios developed for the German pilot. Both concepts focus on user experience and engagement as well as the quality of the service. The first scenario covers the approach of a transmedia service offering high-quality content items spread over several devices including the exploitation of MPEG DASH video. The second scenario follows the idea of providing an HbbTV application portal for both HbbTV developers and end users. One part of the basis for defining the concepts is the collection of end user requirements as a result of the user interviews in WP2 (D2.2).

5.1.1. “Abenteuer Liebe”

This section describes the unified scenario for the German pilot to be carried out by IRT and

RBB. The concept here is described as a user story from an end user point of view, taking into

consideration all the features to be provided editorial-wise as well as the user requirements

preliminarily gathered in WP2. Each part of the user story is complemented by a list of needed

services functionalities. “Abenteuer Liebe” is a documentation format with 20 episodes, which

tries to cover the topic “love” from a teenagers’ point of view. It is about the search for

teenage actors who should play three movies about love: falling in love, cloud number nine,

break apart. The actors-to-be have to prepare themselves for their roles, have to graze

through Berlin to get input and to do research on the topics. Throughout their work the

protagonists are filmed, before, during and after the production and all their activities.

Using the HbbTV application

Jessi is huge fan of “Abenteuer Liebe” (“Adventure: Love”), the RBB documentation series

about teenagers and their way into the adventure land of teenage love with all its ups and

downs. Right at the beginning she fell in love with Tobi, one of the protagonists of the series.

She wants to know everything about him and so with the help of her remote control she

launches the Abenteuer Liebe HbbTV application, where she can easily select Tobi at the image

panel with all the protagonists. Now Jessi can decide what to look at - an image gallery, a

behind-the-scenes video, a video interview, an audio interview or Tobi’s personal fact sheet.

For now she selects the behind-the-scenes video, just to observe Tobi not “acting for the

camera”. Jessi rates this video by giving a “heart”.

She has never been in Berlin but in the Abenteuer Liebe application she can use a map to

virtually visit places Tobi has been before. For each place there are background info available,

pictures and video. Although she really likes him, Jessie knows very well that Tobi is not in

reach for her. But that special boy in her class is also interesting, very nice and he already

knows her name! So, she browses through the application and selects the topic “Getting to

know” and there the expert’s top ten advice. Very useful!

23 version 2.1, 18/03/2014


24 version 2.1, 18/03/2014


12.(Figure 12) German pilot HbbTV application storyboard

Functional elements:

Full screen application (HbbTV v1.5)

Browsing data (video, audio, image, text)

Filtering data (context: who, where, what, when)

Ordering data (ascending, descending)

Map (visualizing data localisation)

During the show

Today Jessi is watching the 10th episode of “Abenteuer Liebe”, topic “Flirting”. There the boys

and girls are visiting a “Flirt school” in Berlin. As she is used to electronically interact directly

with people and media services she launches the HbbTV application which adds a “chat” panel

to the left side of the screen. Up to now it was for live comments of viewers but today in that

panel Jessi can see an expert chat as a constantly updating list of teenagers’ Tweets (and

Facebook updates) trying to ask a professional expert questions about flirting. At first, while

mainly watching the episode, she only reads questions and answers in the chat randomly, but

all this is not that interesting. So she decides to take up her tablet and where the “Abenteuer

Liebe” website is already running synchronously to the TV-based service, which means every

action Jessie does on one of the two screens is also carried out on the other one. Anyway, Jessi

launches the native Twitter app on the tablet and sends her question, which was apparently

not asked already, to the “Abenteuer Liebe” flirt expert by using the given hashtag “#alflirt”.

And, yes, the expert answers her question; she can read it on both screens now!

But now Jessi wants to keep on watching the show. There is Tobi again. Suddenly a voting pops

up, asking the viewers to vote for their favourite protagonist. Well, that’s easy. She gives her

vote to Tobi and can instantly see the current results – he has the lead already! Jessi simply has

to tell everybody: “Tobi is sooo sweet. Everyone knows that! #alflirt”. That Tweet appears now

on the screens, as others do.

25 version 2.1, 18/03/2014


Now the “Abenteuer Liebe” website on the tablet pushes a question, offering multiple

answers. By answering correctly Jessi can gain a “star”, and by collecting 10 stars she

automatically participates in a lottery where she has the chance to win really fine prizes (bags,

DVDs, CDs or vouchers). Each day a winner is chosen and he or she will be announced the next

day. Maybe Jessi is the lucky one?

13.(Figure 13) German pilot storyboard of interaction during the show


Full screen TV application, TV video scalable (HbbTV v1.5)

Full screen web application

Two screen synchronisation

Pulling social media updates (text & video), filtered by keywords

In-app voting

In-app quiz

26 version 2.1, 18/03/2014


In-app rewards

After the show

After each new episode Jessi checks what new advices or topics can be viewed in “Abenteuer

Liebe”. She loves to browse all the texts, pictures and videos there. And Jessi can watch the

appetiser video for the next episode to be broadcasted tomorrow. Sometimes it happens that

she cannot wait until the end of a show and starts the preview in parallel on her tablet. Or

sometimes Jessi pushes a clip from her tablet to the TV set so that she can watch in full and

glory resolution. However, pretty sure she will be in front of her TV tomorrow again.

14.(Figure 14) German pilot after the show interaction storyboard


Extensive video features, MPEG DASH provision

This scenario “Abenteuer Liebe” takes into account the following requirements found at

deliverable D2.2 (List of user requirements):

Req. 21: Possibility to vote easily and directly on TV screen.

- Given with the functional voting element described in the service concept.

Req. 22: Integration of social media streams.

- Social media streams may be included in the on-screen service.

Req. 24: Notifications on availability of content.

- Notifications for special events (games et al) are included here.

Req. 28: Navigation should be made easier and more intuitive.

- The amount of content aimed for needs a clear and easy way of representation and access within the HbbTV service.

Req. 29: Too much extra information on the TV screen is disturbing and should be displayed on 2nd Screen.

High-quality video provision via MPEG DASH.

27 version 2.1, 18/03/2014


- If the amount of content aimed for is to huge and may be disturbed the on-

screen experience it will be accessible on a second screen.

Req. 30: The video quality should be much better and/or selectable. - Additional video content might be HD, some even UHD.

In addition to that and with regards to the “Abenteuer Liebe” service concept the following requirements from deliverable D2.3 (List of Professional Requirements) can be investigated:

Req.30 For seamless task processing tools and technical environment must be easy to use. Req.34 Tools for maintaining HbbTV services must support quick and easy task performance.

- It must be examined how usability of technical environment can support the production and maintenance of rich HbbTV services.

Req.32 CMS and use of metadata must be integrated in a way that essence data sets can be maintained easily.

- As a rich HbbTV service like “Abenteuer Liebe” will integrate lots of data from different nature easy maintenance of such data should be as easy as possible.

Req.35 HbbTV-enabled devices must offer increased performance.

- Users’ end devices must be able to run advanced HbbTV services.

Req.36 Tools for content creation must, apart from HbbTV, support different provision formats in parallel.

- Content prepared for a HbbTV provision will be coming from a web-only production.

Req.42 Tools for maintaining HbbTV applications must offer functionality to influence DVB signalling if needed.

- The application to be provided for the runtime of the TV show will be considerably different from the variant provided between airing time.

5.1.2. TVAppGallery

In this section the scenario for the TVAppGallery is described also from an end users point of view, like before. Different kinds of users can take an advantage out of the TVAppGallery. Application developers could use this as an opportunity to test their services before publishing them. It’s imaginable to offer a testing application on this platform so that device manufactures could check the functionality of their products. At least end users do gain from this innovation. They could have more direct access to a considerably wider range of applications. Furthermore, users can make recommendations and gather their favorite apps for their TV portal at home.

Using the TVAppGallery

Suzan is a young woman and very interested in new media, that’s why she recently bought herself a new TV. She likes the additional opportunities and information she receives from the different HbbTV portals. Last week she created an account on the TVAppGallery Homepage: http://tv-app-gallery.net/index.php/site/index and now she has a much larger selection of HbbTV applications. She can choose her favourite ones and sort them in her Home Portal.

Now, while sitting in the tube, Suzan leafs through a magazine and finds a very interesting article. At the end of the article she recognizes that there is also an HbbTV application

http://tv-app-gallery.net/index.php/site/index

28 version 2.1, 18/03/2014


available. This application promises a great new TV experience. Suzan wants to try this absolutely and takes out her smartphone to scan the QR code from the page.

Back at home she switches on her notebook and locks into her TVAppGallery account. Then she adds the new application to her portal and switches on her TV. Finally she navigates to her new HbbTV application and enjoys the great opportunities gained from this app.

Later this day Suzan gets a call from her friend Mike. He is an employee of a TV device manufacturer. He tells her about his day at work and his new achievement. He found an HbbTV application on the TVAppGallery that enables him to check if the company’s prototype is able to play MPEG-DASH video content. He found out that they still have some problems with their HbbTV language selection implementation.

Scan QR code from for example the TV-Ring website or paper

Login to „my“ Home TVAppGallery Portal

29 version 2.1, 18/03/2014


15.(Figure 15) German pilot TV application gallery storyboard

Add TV-Ring App to the Home Portal

Testing devices with appropriate video streams

Professional user applications:

Enjoy new cool app!

End user applications:

30 version 2.1, 18/03/2014


The following end-user requirements from deliverable D2.2 matches to the described scenario:

Req.25 More on Demand content for kids. - The Gallery gives the possibility to offer more content in every point of view.

Req.22 Integration of social media streams.

- The Gallery gives the possibility to offer social media streams too.

Req.37 Design a content recommendation system that meets the user expectations in terms of usability, degree of personalisation, quality of recommendations, and privacy issues.

- Every user could create their own account at the TVAppGallery. They can collect apps of their interest and sort them on their home screen.

Furthermore, the scenario covers the following professional user requirements from deliverable D2.3:

Req.04 Make sure apps are technically sound.

- Possibility to test app functionality with the TVAppGallery.

Req.17 Standards like HbbTV are necessary to further interactive TV development.

- TVAppGallery is based on HbbTV standard.

Req.30 For seamless task processing tools and technical environment must be easy to

use.

- To use the TVAppGallery, the only thing you must do is to register. Thereby a

testing and release procedure is required to guarantee best functionality.

Req.43 A dedicated test environment for monitoring results before on-air deployment. - TVAppGallery could be used as a test environment, to see how the app works.

Req.46 Make more productivity tools available to HbbTV application developers.

- Possibility to test app functionality with the TVAppGallery that will help

developers to prove their apps.

Req.63 Produce an interesting supply of contents for HbbTV to enhance its attractiveness.

- The Gallery is broadcaster independent, so the range on applications could

grow.

31 version 2.1, 18/03/2014


6. Spanish Pilot service concepts


This section describes the service concepts of the two scenarios defined for the Spanish pilot after carefully considering the results obtained in WP2. In summary, there is a scenario for distribution of live content and another for on demand content, both integrating the new features in the present HbbTV service that TV3 is broadcasting in Catalonia. The scenarios are described in the form of storyboards and both can be applied to the Internet and managed network deployment cases.

The goal has been the use of the work developed in tasks T2.2 and T2.3 as starting points to define service specific concepts. The end-user requirements collected in D2.2 (List of user requirements) after contextual interviews have revealed some concepts about the expected user experience that have been considered during the designing phase of the scenario. Relevant examples of those concepts are the natural integration of the new features in the present application, the action of playing a default content in multi-camera services without disrupting with a selection menu, and the use of contextual information allowing the user to know what he is watching.

The results of the work in WP2 have been also fundamental to refine the described scenarios. The professional requirements collected in D2.3 (List of professional requirements), after the interviews of the staff involved in the production chain and the following workshop, have carried out a rich list of issues that have shaped the way in which the services proposed for the Spanish Pilot can be implemented. Examples of those concepts are the need of a mosaic video stream for content selection and the desire of changing between different contents as quick as possible.

The proposed storyboards are the result of the first iteration of the Spanish pilot in the user requirements gathering process. That means that there may be some gaps in the work that should be refined during the second iteration of user requirements (from M13 to M16) based on the results from the user evaluation in T3.2, as well as with additional interviews or observations.

6.1.1. On demand content scenario

This storyboard covers the scenario of a viewer accessing On-Demand multi-camera HD content. The key point of this issue is the integration of the new feature into the present HbbTV application in the way that the new functionality is naturally presented to the users with the suitable equipment (TV set with HbbTV1.5 support), and also it is silently hidden for viewers with old HbbTV equipment (TV sets with HbbTV1.1).

The first step for the user is to access the DTT channel and to press the red button to start the application as any other HbbTV application. It should be noted that the appropriate DVB-T application signalling must be inserted into the MPEG-2 Transport Stream[1]. Once the application is started, it detects the TV profile and presents the available items to the viewer in the different sections: CatchUp, Most viewed, Search, etc. In HbbTV1.5 TV sets, items that have multiple stream content are clearly identified by a special logo or UX element. Also a special multiple stream content area could be made available in the application in order to facilitate a direct access to this kind of content, if needed.

For a seamless user experience, after content selection the playback starts straightaway in full screen mode without any intrusive menu for both normal and multiple-stream content. In the second case, the designated default view is played automatically.

32 version 2.1, 18/03/2014


At this point, the viewer can access an overlaid control bar by pressing any key on the remote control, which allows for video control features such as pausing and seeking, etc. Additionally, for multi-camera content, a special selector is clearly available to allow the user to change the video stream. Once pressed, a mosaic video with all the available streams is presented with a focus window that allows the viewer to select the desired content. It should be noted that the mosaic video continues playing at the time code the jump to multi-view was made, to minimise any disruption to the user experience.

Once an alternative stream is selected and displayed, the user experience is the same as the one for the default stream. A way to identify which content is being played has to be introduced in the control bar though further testing needs to be made in upcoming iterations.

When playback of the content is finished, or when the user stops the video and is going to navigate to other section, a simple satisfaction survey could be offered before showing related videos or going to the new section. Further testing is required to improve this area, for instance, the survey could be displayed along extra content displayed at the end (typically related content to the video just viewed). In any case, the survey should be extremely simple and should not contain more than 3 options to avoid user rejection and maximise answer ratios.

A graphical depiction of the refined on-demand storyboard follows.

33 version 2.1, 18/03/2014


34 version 2.1, 18/03/2014


16.(Figure 16) On-demand TVC Spanish pilot storyboard

The described scenario takes into account or explores the following end-user requirements

from deliverable D2.2:

Req. 38 Determine the conditions for user acceptance of multi-camera services.

Req. 41 Explore possibilities for user customisation of news contents.

Req. 42 Explore opportunities for the development of advanced applications.

Req. 43 Enable a mechanism or functionality to collect and elicit user feedback,

especially from lead users.

Conversely, the following professional user requirements from deliverable D2.3 are taken into

account in this scenario:

Req. 03 In order to develop new functionalities such as DASH streaming, receivers

supporting them are necessary.

Req. 05 A work-around is needed for the limitation of only one video at a time in

multicamera HbbTV services, such as the production of a mosaic video composed by

the different views.

Req. 07 There is the desire to provide the best possible video quality to each user.

Req. 08 There is the need of tracking the usage of the new services.

35 version 2.1, 18/03/2014


Req. 11 Promotion of HbbTV services to the end-users.

6.1.2. Live content scenario

This storyboard covers the scenario of a viewer accessing to live multi-camera HD content. The key point of this issue is the integration of the new feature into the present HbbTV application in the way that the new functionality is naturally presented to users using suitable devices (TV set with HbbTV1.5 support), and also it is aligned with the user experience proposed for the On-Demand multi-camera HD content. For viewers with old HbbTV equipment (TV sets with HbbTV1.1), the live content feature is silently hidden.

The first step for the user is to access to the DTT channel and to press the red button to start the application as any other HbbTV application. Once the application is started, it detects the TV’s profile and, if the TV set supports HbbTV1.5 features, presents an access to a live content section added to the other common sections. In that new section, the application presents the available live items to the viewer. These items could contain just a single live stream, but may appear items that have multiple stream content which are clearly identified by a special logo.

Following the lines defined in the previous scenario for a seamless user experience, after live content selection the playback should start straightaway in full screen mode without any intrusive menu for both normal and multiple-stream content. In the second case, the designated default view is played.

At this point, the user can access to an overlaid control bar by pressing any key on the remote control, which in single-stream live content is more limited and usually only allows users to leave full screen mode. Additionally, for multi-camera live content, a selector is shown to allow the user changing the video view. Once pressed, a mosaic video with all the available streams is presented with a focus window that allows the user to select the desired content.

Once an alternative live stream is selected and displayed, the user experience is the same as the one for the default stream. A way for identifying which content is being played could be shown in the control bar.

When live content finishes or when the user navigates to another section, a simple satisfaction survey is offered before showing related videos or going to the new section. As in the case of on-demand content, the survey should be completely optional, really simple and not contain more than 3 options to avoid viewer rejection.

A graphical depiction of the refined storyboard follows.

36 version 2.1, 18/03/2014


37 version 2.1, 18/03/2014


17.(Figure 17) Live TVC Spanish pilot storyboard

38 version 2.1, 18/03/2014


For reference and in the same manner of the on-demand scenario, we take into account the following end-user requirements from deliverable D2.2:

Req. 38 Determine the conditions for user acceptance of multi-camera services.

Req. 41 Explore possibilities for user customisation of news contents.

Req. 42 Explore opportunities for the development of advanced applications.

Req. 43 Enable a mechanism or functionality to collect and elicit user feedback,

especially from lead users.

Conversely, the following professional user requirements from deliverable D2.3 are taken into account as well:

Req. 03 In order to develop new functionalities such as DASH streaming, receivers

supporting them are necessary

Req. 05 A work-around is needed for the limitation of only one video at a time in

multicamera HbbTV services, such as the production of a mosaic video composed by

the different views

Req. 07 There is the desire to provide the best possible video quality to each user

Req. 08 There is the need of tracking the usage of the new services

Req. 11 Promotion of HbbTV services to the end-users

7. Pilot service parameters

In each pilot, requirements analysis and breakdown have identified different components and video services that are needed to deliver the functionality required. Prominent amongst these services are the different video content offerings, which are described in detail in the following subsections. At this stage of project definition it is useful to establish as much information as possible in video content provisioning, encoding, distribution, playback and in general any parameters needed for successful pilot delivery.

7.1. Dutch Pilot video service parameters

List of services and components

Follows, the description for the 3 Dutch scenario: The objective and issues we wish to investigate and the required services and technical components.

Quality differentiation by using DRM (proof of concept)

In the first concept we want to investigate the possibility to differentiate in stream rate quality and scope of content by using DRM technique. Also, does this require encoding advantages and new business models?

The following questions are relevant within this scenario:

• Can the encoding process be simplified and the content differentiated in quality and range, based on one DRM key that accepts different statuses (e.g.: basic, premium and gold)? In the present situation paid and free content delivery are encoded and managed in separate encoding streets.

• The test-user perception of service (Content Quality and Range). Are people willing to create an account (leave information that is valuable for broadcasters) or perhaps to pay for wider range and/or HQ content?

39 version 2.1, 18/03/2014


• Can DRM service providers come up with a cost effective business model that allows such a service? Models are now based on license cost per user, also not paying users. Can this also be differentiated?

Required services and components

MPEG-DASH (or HLS): 1 - 5 Mbit encoding of NPO test video material (20 items)

Common encryption of the video material

CDN play-out server

DRM Play Ready licensing server for max 20 accounts (very small)

CTV NPO framework PPG

“In house” recommendations for HbbTV

The goal of this module is to scan household video content usage by a family and recommend for individual persons on the central HbbTV set. NPO wishes to make the TV set smarter in a HbbTV or App context, as the TV is not a personal device and it doesn’t know who’s watching. How can we achieve this? We want to develop intelligence and a “recommendation-engine entrance” that is capable of personal recommendation, using variables such as time of day, device status and historical data.

The question we want to answer is:

How can we measure all NPO ODM usage in a household and how can a HbbTV app personally recommend by anticipating on the current user(s), making the TV really smarter?


Logging tool CDN / Playout platform (IP / TOD / video strats / device)

Smart Recommendation Query Engine

CTV NPO Framework PPG

15-20 families with HbbTV and different personal devices, who are willing to participate

HbbTV as central interface for second screen “competition model”

In concept 3 we wish to investigate how an HbbTV App can act as central interface for group second screen play-along, in a home network.

Questions we want to be answered:

• How to pair all (2nd screen) devices in a household and by social media to one ‘master’

app and how can we synchronize this results with HbbTV?

• How do we keep it scalable (Cloud)

• How do we manage and encourage in-house “real” social interaction and create and

encourage a competition model?


• CTV NPO framework (PPG) • 2nd Screen Framework IRT (EBU) • Quiz Master framework (to be developed PPG – NPO) • Second screen platform Angry Bytes

40 version 2.1, 18/03/2014


• Five or more families with HbbTV, using different personal devices, who are willing to participate

• Access to IP data

SET OF VIDEO STREAM PARAMETERS FOR Quality differentiation by using DRM POC SERVICE

VIDEO STREAM

PARAMETERS VALUE COMMENTS

PILOT DUTCH

PARTNER PPG / KUL Worldwide rights

VIDEO SERVICE

NAME

Quality differentiation by using

DRM

Proof of concept Small Pilot

SERVICE

DESCRIPTION

Can an single DRM License KEY

be used for content

differentiation

To simplify the encoding process

Can DRM srevice providers come up with a

business model that allows such a service. this

also be differentiated

TOTAL BITRATE(S) 5Mb/s, 1Mb/s

VIDEO BITRATE(S) 5Mb/s, 1Mb/s Format: H.264/MPEG-4 Part 10 (AVC)

Frame Rate: 25f/s, Adaptive

AUDIO BITRATE(S) 192Kb/s AAC-LC (Version 4)

Strereo (2 channels)

Muxing mode: ADTS

Sampling rate: 48 KHz

VIDEO STREAMS 1, 2, 3 1: Standard - Lowest Bitrate

2: SD - Medium Bitrate

3: Near HD - Highest Bitrate

AUDIO STREAMS 0

RESOLUTION (1) 720p, (2) 720p, (3) 1080p Full HD progressive

PIXEL ASPECT

RATIO

(all) 16:9 Square

ENCRYPTION Standard To be recognized

LIVE/ON DEMAND On Demand ODM only in this pilot

DISTRIBUTION TV ring Partner? To be recognized

MPEG-DASH

GENERATION

TV ring Partner? To be recognized

41 version 2.1, 18/03/2014


SET OF VIDEO STREAM PARAMETERS FOR “In-house” recommendations for HbbTV SERVICE

VIDEO STREAM


PILOT DUTCH


VIDEO SERVICE

NAME

In-house recommendations Medium Pilot

SERVICE

DESCRIPTION

Can the TV recognize who is watching

based on historical and device usage

data

Pilot will be executed on 20 – 30

household in the Netherlands. Existing

NPO Play-out will be used

TOTAL BITRATE(S) 1Mb/s, 100Kb/s (audio only)

VIDEO BITRATE(S) 1Mb/s, 100Kb/s (audio only) Format: H.264/ HLS

Frame Rate: 25f/s, Adaptive

AUDIO BITRATE(S) 128Kb/s - -

VIDEO STREAMS - -

AUDIO STREAMS 0

RESOLUTION - - - -

PIXEL ASPECT

RATIO

(all) 16:9 Square

ENCRYPTION None

LIVE/ON DEMAND On Demand ODM only in this pilot

DISTRIBUTION NPO Internal Haps Platform

HLS GENERATION NPO Internal Haps Platform – Digital Rapids

encoders

42 version 2.1, 18/03/2014


SET OF VIDEO STREAM PARAMETERS FOR HbbTV as central interface for 2nd screen SERVICE

VIDEO STREAM


PILOT DUTCH


VIDEO SERVICE

NAME

HbbTV as central interface for

2nd screen

Large - Live Pilot

SERVICE

DESCRIPTION

Can HbbTV be the central

aggregator for 2nd

screen data

coming from a competition model

Pilot will be live broadcasted in 2015 on one of

the Dutch channels

VIDEO NPO Live channel Nederland 1,2,3 To be decided later in this year

Pilot will also be accessible on demand in the

TV Ring HbbTV App. Using Standard NPO

adaptive video files (possibly updated to

2.5Mb/s)

43 version 2.1, 18/03/2014


7.2. German Pilot video service parameters

The following table shows video service parameters to be used in the German pilot. All parameters are based on the guidelines of the audio/video standard of the public broadcasters in Germany (ARD). These guidelines describe workflows, technologies and architectures regarding the processing of video and audio streams offered through the open internet. The shown parameters apply to the HbbTV-Standard, which mandates corresponding to the DVB Standard Annex E of TS 102 796 v1.2.1.

VIDEO STREAM


PILOT German Location: RBB

PARTNER IRT

VIDEO SERVICE

NAME

Adventure Love Multiservice Set

SERVICE

DESCRIPTION

HbbTV-based transmedia

service offering interactive

features

TOTAL BITRATES 800kbps – 20Mbps*

VIDEO FORMATS Stream nr.

Resolution Frame rate [fps]

Video bitrate [kbps]

Profile@Level

1 352x288 i25/p25 768/1024 Main,[email protected]

2 720x576 i25/p25 1536/2500 Main,[email protected]

3 1280x720 p25/p50 3584/5000 Main,[email protected]/3.2

4 1920x1080 i25/p25 6500/8000 [email protected]

Format: H.264/MPEG-4 Part 10 (AVC) Algorithm: CABAC Bitrate mode: VBR Maxrate: Equal to max. bitrate Bufsize: bitrate * 2 sec GOP: Frame rate * 2

Segmentation: 2-5 sec Fragmentation: 2-5 sec / none Colour space: YUV Chroma Subsampling: 4:2:0 Frame rates: 25, 50, progressive, interlaced

ADDITIONAL VIDEO

FORMATS *

Format: 3840x2160p50 Bitrate: ~ 20Mbps Profile: [email protected]

Standardization still in progress. Encoding will follow the requirements of DVB/EBU as far as available

AUDIO BITRATE(S) 96/192/256*/448* kbps AAC-LC (Version 4), E/AC3* (Dolby Digital

Plus)

Channels: 2 or 6*

Muxing mode: ADTS


VIDEO STREAMS 1, 2, 3, 4 1: WebM – low bitrate

2: WebL+ – normal bitrate

3: WebXL – high bitrates

4: WebXXL – highest bitrates

44 version 2.1, 18/03/2014


AUDIO STREAMS 1, 2 German language

1: low bitrate

2: normal bitrate

3: High Bitrate

PIXEL ASPECT RATIO 5:4, 1:1 All 16:9, Anamorphic (SD), Square (HD)

LIVE/ON DEMAND Live and On Demand Live available while streaming the

“Adventure: Love” show; OnDemand

available while the retention period of the

ARD Mediathek

DISTRIBUTION Internet Streams distributed over HTTP

FILE STORAGE AND

DELIVERY

Akamai CDN Edge Caching of all Streams through

Akamai's overlay-network incl. stream-

and bandwidth monitoring

MPEG-DASH

GENERATION

Elemental Server, Thomson VS7000

or open source workflow (ffmpeg,

mp4box, x264 etc.)

Generation of MPEG-DASH fragments and

Manifest files

*depending on capability of decoders, sources, production environment, etc.

7.3. Spanish Pilot Video service parameters

The results obtained in WP2 collects a list of end-user and professional requirements that point out the issues that shape the parameters of the required video streams to be used in the Spanish Pilot, namely multi-camera content services. The most relevant user stories, which are common for both Live and OnDemand content, are:

As a developer I need a live mosaic video for creating a content selection menu in multi-camera services

As an end-user I need the best possible video quality that my network connection can support

As an end-user I would like to switch between multi-camera views as quick as possible

The first user story establishes the streams to be provided for multi-camera content: a mosaic video stream for content selection and one additional stream for each content view available.

The second user story highlights the necessity of adaptive video streaming for each content view to assure a user experience without disruptions produced by the network distribution. The maximum quality available depends on the network through which the end-user is connected. For this reason, two sets of streams are proposed: one focused on HD quality for users connected to i2cat’s Managed network where more bandwidth is available, and another that implements degradation to SD quality for users connected by ADSL or similar means through a non-managed network, in this case the general Internet.

The third user story points out the desire of the user to change between multi-camera views as quick as possible. The present sets of streams propose the starting parameters to be tested in the first iteration of the Spanish Pilot, and they should be refined in the second iteration to achieve the desired targets.

The resulting sets of video stream parameters are represented in the tables on two the following sections.

45 version 2.1, 18/03/2014


SET OF VIDEO STREAM PARAMETERS FOR USERS CONNECTED TO i2CAT NETWORK

VIDEO STREAM


PILOT SPAIN

PARTNER TVC Worldwide rights

VIDEO SERVICE

NAME

High-quality-

managed-network

stream

For users connected to i2cat’s Managed network.

SERVICE

DESCRIPTION

Mosaic stream for

content selection in

multiple stream

service

The mosaic is generated and transcoded at the TVC

premises to be sent directly to receivers in MPEG-DASH

form. This allows the service to remain independent of

Picture-In-Picture or any other limitations in viewing

devices.

TOTAL

BITRATE(S)

10.2Mb/s, 6.2Mb/s

VIDEO

BITRATE(S)

10Mb/s, 6Mb/s Format: H.264/MPEG-4 Part 10 (AVC)

Format Profile: [email protected]

Frame Rate: 25f/s, progressive

Algorithm: CABAC

Bitrate Mode: VBR

GOP: M=1, N=12

Color Space: YUV

Chroma Subsampling: 4:2:0

AUDIO

BITRATE(S)

192Kb/s AAC-LC (Version 4)


Muxing mode: ADTS


VIDEO STREAMS 1, 2 1: HD - Highest Bitrate

2: HD - High Bitrate

AUDIO STREAMS 1 Catalan language

RESOLUTION (1) 1080p, (2) 1080p Full HD progressive

PIXEL ASPECT

RATIO

(1) 1:1, (2) 1:1 Square

LIVE/ON

DEMAND

Live and On Demand Live available while streaming a specific programme,

usually up to 2h in sports events

DISTRIBUTION i2cat Managed

network

Streams distributed over HTTP

MPEG-DASH

GENERATION

Using Wowza Media

Server

Generated MPEG-DASH fragments are about 10s of

duration

46 version 2.1, 18/03/2014


VIDEO STREAM

PARAMETERS

VALUE COMMENTS

PILOT SPAIN


VIDEO SERVICE

NAME

High-quality-

managed-network

stream

For users connected to i2cat’s Managed network.

SERVICE

DESCRIPTION

Content stream of

specific camera from

multi-camera service

Each specific camera view is generated and transcoded at

the TVC premises to be sent directly to receivers in MPEG-

DASH form. This allows the service to play each different

content stream after user selection.

TOTAL

BITRATE(S)

10.2Mb/s, 6.2Mb/s

VIDEO BITRATE(S) 10Mb/s, 6Mb/s Format: H.264/MPEG-4 Part 10 (AVC)

Format Profile: [email protected]

Frame Rate: 25f/s, progressive

Algorithm: CABAC

Bitrate Mode: VBR

GOP: M=1, N=12

Color Space: YUV

Chroma Subsampling: 4:2:0

AUDIO

BITRATE(S)

192Kb/s AAC-LC (Version 4)


Muxing mode: ADTS


VIDEO STREAMS 1, 2 1: HD - Highest Bitrate

2: HD - High Bitrate

AUDIO STREAMS 1 Catalan language

RESOLUTION (1) 1080p, (2) 1080p Full HD progressive

PIXEL ASPECT

RATIO

(1) 1:1, (2) 1:1 Square

LIVE/ON

DEMAND

Live and On Demand Live available while emitting a specific programme, usually

up to 2h in sports events

DISTRIBUTION i2cat Managed

network

Streams distributed over HTTP

MPEG-DASH

GENERATION

Using Wowza Media

Server

Generated MPEG-DASH fragments are about 10s of

duration

47 version 2.1, 18/03/2014


SET OF VIDEO STREAM PARAMETERS FOR USERS USING CONSUMER-GRADE CONNECTIONS

VIDEO STREAM PARAMETERS

VALUE COMMENTS

PILOT SPAIN


VIDEO SERVICE NAME

Internet-network stream Users connected by consumer connections through CDN on Internet.

SERVICE DESCRIPTION

Mosaic stream for content selection in multi-camera service

The mosaic is generated and transcoded at the TVC premises to be sent directly to receivers in MPEG-DASH form. This allows the service to remain independent of Picture-In-Picture limitations in viewing devices.

TOTAL BITRATE(S) 6.2Mb/s, 3.1Mb/s, 1.6Mb/s

VIDEO BITRATE(S) 6Mb/s, 3Mb/s. 1.5Mb/s (1): Format: H.264/MPEG-4 Part 10 (AVC) Format Profile: [email protected] Frame Rate: 25f/s, progressive Algorithm: CABAC Bitrate Mode: VBR GOP: M=1, N=12 Color Space: YUV Chroma Subsampling: 4:2:0 (2), (3): Format: H.264/MPEG-4 Part 10 (AVC) Format Profile: [email protected] Frame Rate: 25f/s, progressive Algorithm: CABAC Bitrate Mode: VBR GOP: M=1, N=12 Color Space: YUV Chroma Subsampling: 4:2:0

AUDIO BITRATE(S) 192Kb/s, 128Kb/s AAC-LC (Version 4) Strereo (2 channels) Muxing mode: ADTS Sampling rate: 48 KHz

VIDEO STREAMS 1, 2, 3 1: HD - Low Bitrate 2: SD - Medium Bitrate 3: SD - Low Bitrate

AUDIO STREAMS 1, 2 Both in Catalan language

RESOLUTION (1) 1080p, (2) 720x576, (3) 720x576

(1) Full HD progressive, (2) (3) SD

PIXEL ASPECT RATIO

(1) 1:1, (2) 64:45, (3) 64:45

LIVE/ON DEMAND Live and On Demand Live available while emitting a specific programme, usually up to 2h in sports events

48 version 2.1, 18/03/2014


DISTRIBUTION RETE CDN Streams distributed over HTTP, with edge server provided by RETE

MPEG-DASH GENERATION

Using Wowza Media Server Generated MPEG-DASH fragments are about 10s of duration

VIDEO STREAM

PARAMETERS

VALUE COMMENTS

PILOT SPAIN


VIDEO SERVICE NAME

Internet-network stream Users connected by consumer connections through CDN on Internet.

SERVICE DESCRIPTION

Content stream of specific camera from multi-camera service

Each specific camera view is generated and transcoded at the TVC premises to be sent directly to receivers in MPEG-DASH form. This allows the service to play each different content stream after user selection.

TOTAL BITRATE(S)

6.2Mb/s, 3.1Mb/s, 1.6Mb/s

VIDEO BITRATE(S)

6Mb/s, 3Mb/s. 1.5Mb/s (1): Format: H.264/MPEG-4 Part 10 (AVC) Format Profile: [email protected] Frame Rate: 25f/s, progressive Algorithm: CABAC Bitrate Mode: VBR GOP: M=1, N=12 Color Space: YUV Chroma Subsampling: 4:2:0 (2), (3): Format: H.264/MPEG-4 Part 10 (AVC) Format Profile: [email protected] Frame Rate: 25f/s, progressive Algorithm: CABAC Bitrate Mode: VBR GOP: M=1, N=12 Color Space: YUV Chroma Subsampling: 4:2:0

AUDIO BITRATE(S)

192Kb/s, 128Kb/s AAC-LC (Version 4) Strereo (2 channels) Muxing mode: ADTS Sampling rate: 48 KHz

VIDEO STREAMS 1, 2, 3 1: HD - Low Bitrate 2: SD - Medium Bitrate 3: SD - Low Bitrate

AUDIO STREAMS

1, 2 All in Catalan language

49 version 2.1, 18/03/2014


RESOLUTION (1) 1080p, (2) 720x576, (3) 720x576

(1) Full HD progressive, (2) (3) SD

PIXEL ASPECT RATIO

(1) 1:1, (2) 64:45, (3) 64:45

LIVE/ON DEMAND

Live and On Demand Live available while emmiting a specific programme, usually up to 2h in sports events

DISTRIBUTION RETE CDN Streams distributed over HTTP, with edge server provided by RETE

MPEG-DASH GENERATION

Using Wowza Media Server

Generated MPEG-DASH fragments are about 10s of duration

50 version 2.1, 18/03/2014


8. System components

At this stage of the analysis of the different services to be deployed in the Pilots, several software (SW), hardware (HW) and systems (SYS) components have already been identified and are listed below.

8.1. IRT

8.1.1. BRAHMS (SW)

Broadcast and HbbTV Media Server for simple and low-cost playout of HbbTV services.

BRAHMS is a good solution for creating and multiplexing MPEG transport streams of the DVB standard family. It is a stand-alone solution for testing, trial and demo purposes. The server allows you to insert all relevant information in your broadcast signal for HbbTV applications. The user interface enables quick configuration and an easy setup of HbbTV services with all required signaling. Automatic configuration assistance and enhanced error detection assure fast and simple handling. The tool is able to re-multiplex several transport streams with DVB content in real-time for DVB-S/S2, DVB-C and DVB-T, and broadcasts them with all required program and service information. The source data can dynamically be modified, completed, or replaced on the fly as well.

System requirements:

Windows 7, Server 2008 R2, Windows 8, Server 2012

dual core processor (x86-based, 2 GHz)

2 GB RAM (4GB recommended)

ASI or RF card. Supported are various Dektec cards (please contact IRT for associated

information)

8.1.2. Second Screen Framework (SW)

Manufacturer independent interaction with HbbTV applications.

The IRTs Second Screen Framework offers a manufacturer-independent integration of second screens into HbbTV applications. The Framework offers a set of functionalities that can be used by the HbbTV device and its second-screen counterpart enabling the communication between the applications on the two devices.

A second-screen-enabled HbbTV application is extended by a menu item to connect a second device. This directly leads the user to a QR code popup on the TV (created by the framework). After scanning this QR code with a smartphone or tablet, a persistent logical connection is established, enabling a communication between the website launched on the second screen and the HbbTV application running on the TV. To establish the connection, the system does not rely on a local device discovery mechanism and is thus robust against peculiarities of local network installations. This also allows the communication between devices in local LAN/Wi-Fi networks and those connected to a 3G network.

51 version 2.1, 18/03/2014


8.1.3. TVAppGallery Backend (SW, prototype!)

The TVAppGallery is a system to provide an open marketplace for HbbTV applications.

The TVAppGallery is a system to provide an open marketplace for HbbTV applications. Generally HbbTV applications are tied to broadcast programs and accessed through the “red button concept”. The current HbbTV standard doesn’t provide any technology to give access to third party applications. It’s the duty of the TVAppGallery to open the HbbTV application market to non-broadcaster companies. Otherwise they have only the opportunity to purchase to proprietary app portals, which are offered by some device manufactures. But the TVAppGallery makes it possible to have equal opportunities and an efficient access to SmartTV devices for all parties.

A first prototype was developed during the EU project FI-Content in 2012. To use this TVAppGallery it’s necessary to register the service on the web interface (http://tv-app-gallery.net/index.php/person /register). Thereby a testing and release procedure is required to guarantee best functionality.

There are a number of options, how the customer could “add” the application to his HbbTV device in practice.

Option A)

An end user GUI version of the TVAppGallery, which is provided by the TVAppGallery project, is attached to a broadcast service. The end user can then select the corresponding broadcast service and launch the GUI of the TVAppGallery offering him a number of access options for the various applications. This option does not require any cooperation with the HbbTV device manufacturer, but is the most inconvenient option for the end customer.

Option B)

The manufacturer of the HbbTV device cooperates to allow the user a more convenient access to applications available in the TVAppGallery. For this option there are some variants, which can be implemented.

“Portal in Portal”

The manufacturer of the HbbTV device lists the end user GUI version of the TVAppGallery as one of many applications in his portal. The end user can then, via the portal of the manufacturer, start the GUI of the TVAppGallery. The URL of the HbbTV version of the TV App Gallery is http://www.tv-app-gallery.net/HbbTV/html/ index.php?devel=1.

In this context this icon can be used on the device portal:

18.(Figure 18) Device portal logo

http://tv-app-gallery.net/index.php/person%20/register

http://tv-app-gallery.net/index.php/person%20/register

http://www.tv-app-gallery.net/HbbTV/html/%20index.php?devel=1

52 version 2.1, 18/03/2014


Manual entry of the TVAppID

The native portal application offers the user to enter TVAppIDs that have been communicated by application providers. The native portal application can then add this ID to a fixed base URL according to this syntax: http://www.tv-app-

gallery.net/appstart/?app_id=[app-ID]. Calling this URL results in a redirect to the real URL of this application.

All applications carry a title and also icons according to the chapter "10.2.3.1 Favourites and bookmarks" of HbbTV 1.5 (ETSI TS 102 796 V1.2.1). It is up to the manufacturer how to allow the end user the managements of apps added this way, i.e. how to move them to favourites or certain categories or delete them again from his app collection.

Scanning QR codes

Another option for the user is to use a mobile app to add apps to the device portal. The mobile app can allow the user to scan a QR code representing the application and extract the TVAppID from the URL coded into the QR code. The URL syntax in these QR codes is: http://www.tv-app-gallery.net/[app-ID]. After extraction of the TVAppID the same principles as before can be applied.

8.1.4. Elemental Server (HW)

Elemental Server is a professional video transcoder for OnDemand encoding.

The Elemental Server is a file-based video processing system that provides fast and reliable transcoding for TV operators, content owners and film studios. The server performs simultaneous conversion of multiple video files to create mezzanine deliverables or adaptive bitrate outputs for delivery to TVs, PCs and mobile devices. It supports content delivery via Adobe Flash, Microsoft Smooth Streaming, Apple HLS, MPEG-DASH, Ultraviolet, QuickTime or traditional broadcast formats. The supported video codecs are VC-1, MPEG-2 and H.264 as well as H.265 (HEVC).

8.1.5. Elemental Live (HW)

Elemental Live is a professional video encoder for live encoding.

The Elemental Live encoder has the same functionality as the Elemental Server, but designed for real-time video and audio encoding for linear TV broadcast and live stream for online platforms. It can encode up to 12 1080p streams or 24 720p streams or some other formats simultaneously in a single appliance.

8.1.6. OTT-Server VS7000 (HW)

VS7000 is a professional video encoder and transcoder for live and OnDemand encoding.

Powered by Thomson’s MediaFlex video operating system, the ViBE™ VS7000 video system is an en VS7000 is a professional video encoder and transcoder for live and OnDemand encoding.

The VS7000 by Thomson features picture quality up to 1920x1080i60 in an all-IP environment with live broadcast-quality encoding and faster-than-real-time file transcoding. It supports the HEVC video codec, MPEG transport streams, Adobe Flash, Apple HTTP Live Streaming, Microsoft Smooth Streaming and MPEG-Dash.

http://www.tv-app-gallery.net/appstart/?app_id=%5bapp-ID

http://www.tv-app-gallery.net/appstart/?app_id=%5bapp-ID

http://www.tv-app-gallery.net/

53 version 2.1, 18/03/2014


Video Encoding

- hevc main profile

- cbr, vbr, capped vbr

- h.264 baseline profile

- h.264 main profile

- h.264 high profile

Resolutions & Frame Rates

- off line: up to 3840x2160p60

- live h.264:

> up to 1920x1080i @ 60fps

> up to 1920x1080p @ 30 fps

> up to 1280x720p @ 60fps

Audio Encoding

- MPEG-1 Layer II

- AAC-LC

- HE-AAC v1.0/v2.0

- Dolby Digital/Dolby Digital Plus

Content Protection

- AES scrambling

- Apple HLS encryption

- Microsoft PlayReady DRM

Live Input

- MPEG-2 TS MPTS/SPTS over IP (CBR&VBR)

- Unicast, Multicast

- IPv4, IPv6 support

- IGMP v2, v3

Live Output

- mpeg-2 ts mpts/spts over ip

- ts/rtp/udp streaming

- adobe flash/rtmp

- apple http live streaming

- microsoft smooth streaming

- mpeg-dash

8.1.7. MPEG-DASH video testing material

At the IRT HbbTV test portal we offer a set of MPEG-DASH encoded video files for testing HbbTV devices or applications. The sets include SD as well as HD formats in both, interlaced and progressive, mode. The video codec that will be used is MPEG-4 AVC (h264) and for the audio coding it will be mainly Fraunhofer aac. For some further audio testing there are also Dolby Digital and Dolby Digital Plus streams available.

Resolution Frame rate

[fps]

Video bitrate

[kbps]

Video codec Audio codec Audio

bitrate

[kbps]

352x288 i50/p25 768/1024 H264 AAC/HEAAC 96

720x576 i50/p25 1536/2500 H264 AAC/HEAAC 192

1280x720 p25/p50 3584/5000 H264 AAC/HEAAC 192

1920x1080 i50/p25 6500/8000 H264 AAC/HEAAC 192

Table 1: Format overview

There are two ways to find our DASH-Streams. First opportunity is to follow the link on pc or mobile device: http://tv-html.irt.de/hbbtv/tests/video/index.php?30. For navigation it’s recommended to use the “TAB” key. During the navigation the MPD-URLs are readable.

http://tv-html.irt.de/hbbtv/tests/video/index.php?30

54 version 2.1, 18/03/2014


To use the video test material on HbbTV 1.5 (User Agent “1.2.1”) devices, it’s necessary to connect to SAT and tune to “BR SÜD HD” on Astra 19.2E. To continue, the red button on the remote control has to be pressed, to enter the HbbTV application. Next step is, to select “BR Text” and press “Play” on the remote control for three times. Now it’s possible to navigate to IRT-Tests and the URL as shown above is loaded.

Every project partner can reassemble the MPDs or create some new MPDs based on the IRT streams, but it would be kind to keep IRT-notice at lease in the comments. TVC will use the same MPEG-DASH video content to perform technical tests on different devices and compare technical results within the Spanish pilot and any other pilots using the same material.

8.2. TVC

8.2.1. WOWZA Media Server (SW)

As possible software to generate MPEG-DASH compliant content, the Wowza Media Server from Wowza Media Systems will be tested by TVC to generate test content for the Spanish pilot. This is to be compared to any other solutions employed in the project (either open source or commercial products) to ensure generating good quality video streams, both the standard and the alternate ones. The software allows MPD generation as well as segment generation partitioning, which will be the ISO base media format (MPEG-4) in the case of the Spanish pilot.

8.2.2. Handata Flowserver (SYS)

Handata Flowserver is a DVB-T play-out system deployed by TVC which is used to signal the current and any necessary parameters for the HbbTV applications deployed within the Spanish pilot. Handata Flowserver is a commercial product which allows broadcasters to fill out DVB Transport Stream AIT tables, and more specifically for TV-RING, the relevant HbbTV app signalling. TVC has an internal network to test all application parameters and signalling to test HbbTV development which will be used to test the Spanish pilot applications.

55 version 2.1, 18/03/2014


19.(Figure 19) Handata Flowserver TVC testing instance setup interface example

8.2.3. TV3 ALACARTA HBBTV APP (SW)

The existing deployed HbbTV on-demand application by TVC will be used as the development basis for the Spanish pilot. The application is currently live and sports several basic on-demand features such as content catalogue, on-demand video playback, content search form, editorial control of displayed content, broadcast catch-up, etc., with content updated several times an hour with the same rate as any other IP-based services offered by TVC.

20.(Figure 20) TV3Alacarta HbbTV application screenshot

8.2.4. Video Mosaic Generator (SYS)

The Spanish pilot requires the generation of composite video sources in the same stream, both for live and on-demand content (see section 6.1). TVC will develop a video ‘mosaic’ generator to create that content which will be rendered and encapsulated into MPEG-DASH form full server-side, to ensure no Picture-In-Picture requirements are made on viewers TV sets. The

56 version 2.1, 18/03/2014


expected number of video sources to be integrated is up to four videos, which means they will be downscaled to SD-equivalent qualities to fit within an HD frame.

8.3. i2CAT

8.3.1. MPEG-DASH Media server (SW prototype)

I2CAT is working on a software solution for MPEG-DASH content generation. A system capable to receive UDP or RTP media flows (in Transport Stream format), transcode them in different bitrates and multiplex again in MPEG-DASH format with HbbTV 1.5v profile for live streams. In the case of on-demand usage, pre-coded files may be considered in order to multiplex them on the fly without having to transcode.

At the moment only H264 AVC and AAC video and audio codecs are considered. This is the software to be tested in Spanish pilot over the i2CAT broadband network.

8.3.2. Media Content Delivery Network (SYS prototype)

The CDN that aims to deploy over its infrastructure consists in bringing the content as close as possible to the users in order to benchmark and study delay reduction techniques in live streaming and verify congestion avoidance in the origin. It will be composed for one redounded server in the content distributor CPD that provides the content to the users through a park of proxy cache servers adapted to MPEG-DASH workflow, which will be located at the ISP facilities. The objective will be to test and validate feasible ways to reach the last mile of the content delivery, which is usually out of the scope of global commercial CDNs.

8.4. RTV

8.4.1. Content Delivery Network (SYS)

In the TV-RING Spanish pilot a Content Delivery Network will be used to distribute the MPEG-DASH content from the TVC Data Processing Center (Content Server) to end users registered in the pilot to test a non-managed network deployment.

The public URL will be a URL where the end users players should connect to request and download all video content. Retevision will provide a different public URL for each delivered stream, which could be any different camera view.

As an example:

- http://abertisdash.abertistelecom.com/content_1.mpd - http://abertisdash.abertistelecom.com/content_2.mpd - http://abertisdash.abertistelecom.com/content_3.mpd

http://abertisdash.abertistelecom.com/content_1.mpd



57 version 2.1, 18/03/2014


21.(Figure 21) CDN basic structure diagram

The requested content in the public URL is immediately requested to the entry point where the content is located, so it is served from the closest EDGE server if they have that content or is directly served from the origin point.

The total bandwidth to deliver the content will be limited to the existing bandwidth between the EDGE server and the end user.

58 version 2.1, 18/03/2014


9. Conclusions

In sections 4, 5 and 6 the scenarios proposed for the pilots are described in detail, refined by input from regular users as described in deliverable D2.2 and professional users as detailed in deliverable D2.3. Areas where further testing and feedback are needed have been clearly identified from the aforementioned deliverables. Moreover, the analysis process has helped identifying and defining video services and other components that are likely to be used in pilot deployments. The following table summarises the services and components detailed in sections 7, 7.2, 7.3 and 8.

Service name Pilot Comments

MPEG-DASH (or HLS)

video encoding NPO

material

Dutch NPO test video material (20 items)

CDN service

Dutch Includes logging, play-out, stream delivery

Encryption of video

material

Dutch Broadcast-quality original footage

DRM Play Ready

licensing server

Dutch Max 20 accounts (very small)

CTV framework Dutch Connected TV development framework

Recommendation

Engine

Dutch Smart recommendation engine

2nd screen

framework

Dutch &

German

Device synchronisation

2nd screen platform Dutch Angry Bytes development platform

Adventure Love

Multiservice Set

German HbbTV-based transmedia service offering interactive

features

BRAHMS German DVB media server

TVAppGallery German App gallery backend prototype

Elemental Server/Live German Video transcoding for live and on-demand

OTT-Server German Video encoding and transcoding

MPEG-DASH test

material

All pilots Reference MPEG-DASH test video material

59 version 2.1, 18/03/2014


Wowza Media Server Spanish Video transcoding for live and on-demand

Handata Flowserver Spanish DVB media server

High-quality-

managed-network

mosaic (1/2)

Spanish Mosaic stream for content selection in multiple stream

service (managed network)

High-quality-

managed-network

stream (2/2)

Spanish Content stream of specific camera from multi-camera

service (managed network)

Internet-network

mosaic (1/2)

Spanish Mosaic stream for content selection in multiple stream

service (Internet)

Internet-network

stream (2/2)

Spanish Content stream of specific camera from multi-camera

service (Internet)

TV3Alacarta Spanish HbbTV prototype application

Video Mosaic

Generator

Spanish Generation of composite mosaic video streams

MPEG-DASH Media

Server

Spanish Live MPEG-DASH encapsulation software

CDN prototype Spanish Managed-network MPEG-DASH optimised test CDN

A lot of emphasis has been made on user facing feature definitions, taking into account the first pilot phase and upcoming implementation tasks T3.2, T3.3 and T3.4. On the other hand, advanced professional features and subtler UX enhancements can be further refined once mock-ups are developed in T3.2. In summary, the storyboard and service definition process has proved a key step in helping define service components and provide a list of components to be integrated in development, as well as established the basis for more detailed mock-up creation.

deliverable - 5g-victoritvring.eu/wp-content/uploads/deliverables/tv-ring-d3.1... · 2014-12-11 ·...

Documents