DELIVERABLE - CORDIS...2.5 29/02/2016 David Pujals RTV Fixing Format issues ICT PSP Statement of...

0 version 2.5, 28/04/2015

TV-Ring D3.4 Description of technical pilot infrastructures

DELIVERABLE

Project Acronym: TV-RING

Grant Agreement number: 325209

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

D3.4. Description of technical pilot infrastructures

Revision: 2.5

Authors:

David Pujals (RTV)

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:

TV-Ring project defined the implementation a pilot in each of the three regions that are composing the project consortium (The Netherlands, Germany and Spain) to present the advances and innovations carried out within the project evaluating them in real environments. This document pretends to describe how these pilots have been planned and implemented with the aim to build a showcase with all the necessary features, platforms and systems, networks and devices required for the end users to be able to use at home these new project applications and services, and finally to be able to evaluate them.

I2Cat

Rectángulo

1 version 2.5, 28/04/2015


Revision History

Revision Date Author Organisation Description

0.1 18/06/2014 David Pujals RTV TOC proposal

1.0 15/07/2014 David Pujals RTV First draft

1.5 15/09/2014 David Pujals RTV Added descriptions

1.8 26/11/2014 David Pujals RTV Some ToC improvements

1.9 01/02/2015 David Pujals RTV Added general and Spanish pilot related content.

2.0 23/03/2015 David Pujals RTV Added received contributions from IRT, RBB and NPO.

2.1 03/04/2015 David Pujals RTV Added preliminary contribution from TVC.

2.2 08/04/2015 David Pujals RTV Added Summary and RTV + i2CAT contributions.

2.5 29/02/2016 David Pujals RTV Fixing Format issues

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.

2 version 2.5, 28/04/2015


1. Executive Summary This document describes the deployed infrastructure of the project to carry out the three TV-

Ring pilots (German, Dutch and Spanish). The infrastructure described will be the basis for any

OTT (Over The Top) platform who wants to deliver video services such as those deployed in the

project.

The platform comprises a system and back-end platform, a delivery network and the final user

setup. Each one of the three pilots is particular, having different configuration that will be

described in order to demonstrate multiple options for different scenarios and requirements.

The systems deployed in the three pilots, consist in a content management and storage system

build upon a distributed hardware infrastructure and different software tools (all of them will

be described in this deliverable); complemented also with the use of new technologies like the

MPEG-DASH standard, used to deliver multimedia content through unmanaged networks in a

more accurate way; and the use of HbbTV applications being developed to offer High Quality

video, interactive services, second screen services and DRM protected HQ video to the end

users.

Moreover, TV-Ring tests different ways to distribute content to the households. TV-Ring is

willing to compare a global CDN versus a local CDN (Content delivery network) to demonstrate

the advantages of each configuration, based on the scale of audience to be reached. This fact is

of special interest for small-medium broadcasters with very specific audiences (e.g. Catalonia)

and the possibility to reduce distribution costs.

3 version 2.5, 28/04/2015


2. Contributors

First Name Last Name Company e-Mail

David Pujals RTV [email protected]

Sven Glaser RBB [email protected]

Aylin Vogl IRT [email protected]

Susanne Heijstraten NPO [email protected]

Daniel Giribet TVC [email protected]

Marc Aguilar I2CAT [email protected]

Ammar Tijani PPG [email protected]

4 version 2.5, 28/04/2015


Content

Revision History ......................................................................................................................... 1

1. Executive Summary ................................................................................................................ 2

2. Contributors ........................................................................................................................... 3

3. Table of Figures ...................................................................................................................... 6

4. Introduction ........................................................................................................................... 7

5. Generic backend platform structure ..................................................................................... 8

5.1. Pilot platform diagram .................................................................................................. 9

5.2. Introducing MPEG-DASH standard protocol ............................................................... 11

5.3. Specific pilot design architecture ................................................................................ 11

5.3.1. Dutch Pilot ........................................................................................................... 11

5.3.2. German Pilot ....................................................................................................... 12

5.3.3. Spanish Pilot ........................................................................................................ 12

6. Application server ................................................................................................................ 16

6.1. Dutch Pilot ................................................................................................................... 16

6.1.1. Application hosting.............................................................................................. 16

6.1.2. Second screen application deployment .............................................................. 17

6.2. German Pilot ............................................................................................................... 17

6.2.1. Application Storage ............................................................................................. 17

6.2.2. Application deployment ...................................................................................... 17

6.3. Spanish Pilot ................................................................................................................ 18

6.3.1. Application Storage ............................................................................................. 18

6.3.2. Application deployment ...................................................................................... 19

6.3.3. Second-screen synchronisation mechanism ....................................................... 19

7. Content Storage ................................................................................................................... 21

7.1. Dutch Pilot ................................................................................................................... 21

7.1.1. Web content ........................................................................................................ 21

7.1.2. VoD/Catch-up services ........................................................................................ 21

7.2. German Pilot ............................................................................................................... 21

7.2.1. Web Content ....................................................................................................... 22


7.3. Spanish Pilot ................................................................................................................ 23


7.3.2. Live services ......................................................................................................... 24

8. Content Delivery .................................................................................................................. 26

5 version 2.5, 28/04/2015


8.1. Dutch Pilot ................................................................................................................... 26

8.1.1. Content Delivery Network ................................................................................... 26

8.2. German Pilot ............................................................................................................... 27

8.2.1. Streaming content ............................................................................................... 27

8.2.2. Delivery Network ................................................................................................. 28

8.3. Spanish Pilot ................................................................................................................ 29

8.3.1. Streaming content ............................................................................................... 29

8.3.2. Delivery Network ................................................................................................. 32

9. Demonstrations system setup ............................................................................................. 37

9.1. NPO Demonstration setup .......................................................................................... 37

9.1.1. Recommender and DRM demo ........................................................................... 37

9.1.2. NPO Second screen ............................................................................................. 37

9.2. German Pilot ............................................................................................................... 37

9.3. Spanish pilot Demonstration setup ............................................................................. 38

9.3.1. RF Channel simulation ......................................................................................... 39

9.3.2. Receivers testing ................................................................................................. 40

10. Glosary ............................................................................................................................. 42

11. References ....................................................................................................................... 43

12. Annex I - Configuration of the cache nodes .................................................................... 44

13. Annex II – Quality of Service of HbbTV Service Streams ................................................. 54

6 version 2.5, 28/04/2015


3. Table of Figures

Image 1: System data flow. ........................................................................................................... 8

Image 2: High Level system diagram. .......................................................................................... 10

Image 3: Spanish pilot content generation and flow scheme. .................................................... 13

Image 4: Backend structure of Spanish TV-RING project, including network overview. ............ 14

Image 5: App hosting architecture. ............................................................................................. 16

Image 6: XML file of launcher bar widget. .................................................................................. 18

Image 7: HbbTV launcher bar including German pilot widget on the left "verknallt & abgedreht",

the actual program title. ............................................................................................................. 18

Image 8: Tablet is synchronized with the TV through Firebase using web sockets. ................... 20

Image 9: Video storage and delivery within the German pilot. .................................................. 22

Image 10: Akamai CDN Content Storage. ................................................................................... 23

Image 11: Live services diagram.................................................................................................. 25

Image 12: Example of an MPD file used in the German pilot. .................................................... 28

Image 13: Akamai CDN Edge Server arrangement. ..................................................................... 29

Image 14: Local CDN block diagram. ........................................................................................... 33

Image 15: Worldwide Level3 CDN nodes interconnection. ........................................................ 33

Image 16: TV-Ring global CDN network configuration diagram. ................................................ 35

Image 17: Demonstration setup scheme. ................................................................................... 38

Image 18: Transport Stream (TS) file containing the TV services to be locally broadcasted. ..... 39

Image 19: Portable low power DVB Modulator. ......................................................................... 40

Image 20: The first of the brand new VESTEL TV sets deployed in the village of Gurb. ............. 41

Image 21: HbbTV service Streams Measurement Concept. ....................................................... 54

Image 22: Beacon management. ................................................................................................ 58

Image 23: Web-interface structure. ............................................................................................ 60

Image 24: Example for a “General Overview” diagram. ............................................................. 61

Image 25: Example for a “Series” diagram. ................................................................................. 61

Image 26: Example for a “Clip” diagram. .................................................................................... 62

Table 1: Receivers testing results table. ...................................................................................... 40

7 version 2.5, 28/04/2015


4. Introduction

This deliverable pretends to focus on the platform structure and components used by the TV-

Ring system where all interactive applications and multimedia content are stored to be offered

to the end users as content consumers.

The system is based in a content platform itself is divided in three well differentiated parts, the

application server, the content storage and the content delivery. These three parts are required

by any OTT (Over the Top) platform wishing to offer an appropriate service to a very large

number of end users.

As a particularity of the OTT platforms the content is not broadcasted to everybody but is

delivered specifically to any end user who establishes a session and requests any piece of

content. The system has to be designed to be able to serve any requested data specifically to

large amounts of requests from end users, with no troubles in the distribution, neither in the

delivery nor with the minimum latency to deliver excellent levels of user experience.

The platform is the pillar of the system performance, so it has to be designed taking into account

what has been described above: potential number of end users, streaming technologies, type of

content (video, audio, etc.) and turnout to be aware of the maximum number of end users

capable to use it at the same time avoiding the system to collapse.

The document will describe the platform used for TV-Ring pilots in order to make use of the

developed applications for second screen, multi camera and high quality video content besides

the delivery of multimedia content both SD and HD using MPEG-DASH standard protocol in

Spanish pilot, UHD over MPEG-DASH in the German pilot and even the use of DRM features in

the Dutch pilot when users access the platform through its connected TV set.

8 version 2.5, 28/04/2015


5. Generic backend platform structure

A generic platform diagram for application and video delivery needs to consider a minimum of some basic elements to allow the end users enjoy the generated interactive multimedia content. First, a WEB server must be running to offer the HbbTV applications to end-users before they request the multimedia content, secondly a CMS (Content Management System) mechanism is needed to manage the content accessibility and distribution, then a Content Storage must be present in order to allocate the multimedia material (video, audio, etc.) and streaming the content. Finally a capable Internet link (output) to deliver the content, where it is important to set up a security isolation mechanism (it can be built through a firewall or other software or hardware tools depending on the security level we would like to have), in order to avoid any non-allowed user to enter the system and to avoid any damage due to malicious software.

Image 1: System data flow.

In the picture red lines indicate the way to end users for both applications from the WEB server and content from the CDN. Blue line indicates the multimedia content (video content) from the source to the storage system and to the CDN Edge servers. Finally the green lines indicates the metadata flow when content is ingested.

With a system like the one described, any broadcaster/content distributor would be almost ready to deliver any multimedia content to a specific amount of simultaneous end users. The bigger the system is, the more end users it can be reached. Therefore, it is obvious that trying to reach a big number (thousands) of end users could become a very expensive task.

When the distribution of multimedia content needs to reach thousands, tens of thousands or hundreds of thousands end users over a country or over the world, people would need a number of servers capable of providing service to all these end users. This could be achieve by installing

9 version 2.5, 28/04/2015


a well dimensioned farm of servers (big amount of computers working in parallel for the same purpose) or using a new mechanism to avoid this great expense in hardware.

The CDNs (Content Delivery Network) are used to allow any distribution system reaching large scale deployments. The CDN avoids all users accessing the identical origin server when requesting the content, and by this, the platform can be much smaller and much cheaper.

Basically the CDN does save due to three reasons:

In a geographically concentrated distribution (e.g. Catalonia) basically it would be savings that you should not have the infrastructure sized for your peak traffic permanently. Savings1 = CDN annual cost – (annual computers depreciation + annual cost of peak bandwidth)

For a dispersal distribution you do save by avoiding to replicate the same infrastructure all over the world. Savings2 = Annual cost CDN - Num of POPs * (POP infrastructure depreciation)

For a distribution using several protocols, besides volume and physical dispersion there is a technological reason. There is no need to dispose specific servers for processing the different protocols requested by end users.

Savings3 = (Annual CDN costs) – (Annual depreciation of Microsoft Infrastructure + Annual depreciation of Adobe Infrastructure + Annual depreciation of DASH Infrastructure + Annual depreciation of Caching Infrastructure).

To evaluate the amount of savings the system can achieve it is needed to know the forecast of the maximum traffic and the number of simultaneous connections.

5.1. Pilot platform diagram

Back-End platform infrastructure (divided in 3 logical parts):

• Application Server: HbbTV apps will be stored in remote WEB servers. Pilot TV channel stations will redirect to their URL when end users want to consume interactive TV-Ring content.

• Content Storage: Video and multimedia content will be stored in the cloud, ready to be consumed by TV-Ring end users. HbbTV apps will link and get these multimedia contents when end users request them.

• Content Delivery: The multimedia content will be streamed directly to any end user who requests it through the CDN network, both global and local.

The logic flow mechanism could be seen following the red dotted lines in Image 2:

1. End users tune the TV-Ring broadcast channel at first. They execute the TV-Ring HbbTV application by pressing “red button” on the remote.

2. HbbTV app coming from the WEB server is loaded in the TV set and then the user is allowed to navigate throughout the menus.

3. Finally end users request the desired multimedia content. The app gives the link to where the content can be downloaded from.

4. The desired content is delivered directly to the requesting TV set through the CDN network using standard MPEG-DASH streaming protocol. The content quality will vary

10 version 2.5, 28/04/2015


depending on some factors; mainly TV set process capacity, network availability and system turnout.

Some premises needed to take into account:

System Managers will have to upload multimedia content (videos, etc.) to the Content Storage and add the required metadata information in the CMS to make the content be found when any user requests it.

It is mandatory that any end user tunes the adequate TV station to take part in the TV-Ring pilots and get content (NPO, RBB and TVC channels).

In TV-Ring pilots where there is no such big amount of content, the WEB Server and the CMS will be running in the same computer, while in other cases they are in separate computer systems.

Hardware requirements are not the same in all pilots. In some scenarios, like in the Spanish pilot, only those end users with at least a connected TV HbbTV v1.21 compliant, will be able to run TV-Ring applications and content.

Image 2: High Level system diagram.

1 The HbbTV protocol delivered by HbbTV forum referred as version 1.5, has been approved by ETSI as HbbTV v1.2

11 version 2.5, 28/04/2015


In the previous picture, blue lines (1, 2 and 3) indicate the content ingestion, green lines (4, 5 and 6) indicate the path for the content consumption. Blue lines indicates the path when system managers ingest the content by uploading multimedia files and the corresponding metadata to the content storage, the CMS executes a process encoding the content, storing the master and forwarding the encoded instances to the CDN. Green lines are the path to follow to acquire content, end users makes requests through the HbbTV app and the content is served through the nearest node in the CDN being delivered directly to end users.

5.2. Introducing MPEG-DASH standard protocol

MPEG-DASH (1) is an adaptive bitrate streaming technique that enables high quality streaming of media content over the Internet delivered from conventional HTTP web servers.

Old transmission protocols built to deliver video content in controlled networks such as broadcast television, are not well adapted to be used in uncontrolled networks like The Internet due to inconsistent latency and jitter allowing the number of packet lost being higher than those protocols could manage to offer a proper video service.

Since video files are being delivered over IP networks other transmission protocols like HLS, RTMP, have raised enabling a better quality of video transmission.

MPEG-DASH has gathered the best features from some of these protocols and has been standardized to be used in Internet video delivery without taking into account the type of device receiver and being independent of the network behaviour. MPEG-DASH will adapt the video quality considering the device and the network quality being used by each end user, avoiding the content provider to interfere.

MPEG-DASH is a very new protocol, or at least it was when the TV-Ring project was proposed, and the HbbTV forum included it in the last released version (v1.5) later standardized by ETSI (2) as v1.2. Under this scenario the project TV-Ring expected to demonstrate the benefits of using this protocol in the delivery of high quality video content over the Internet making use of the created HbbTV applications within the project.

5.3. Specific pilot design architecture

5.3.1. Dutch Pilot

The NPO HbbTV application is a custom built Linux Apache MySQL PHP (LAMP) stack Model View Controller based framework.

It runs on a load balancer cluster. It is connected to 12 API's for all its data which it stores, proxies with or without modification or serves directly to the client.

From here, the rest of the platform setup in the Dutch pilot remains on the software. Server system software and specific mechanisms and tools will configure the environment for one or another application to be executed, like the Recommender and the Second screen.

5.3.1.1. DRM and Recommender pilot

For the pilots DRM and Recommender, considerable extensions and modifications have been made to the following scopes:

12 version 2.5, 28/04/2015


1. Database 2. Cron jobs 3. API abstraction layer 4. Administration panel 5. Frontend

This information is be more in detail explained in the deliverable D3.3.1 application implementation (3).

5.3.1.2. Second screen application

The second screen application is an extension on Angry Bytes existing real time platform that is primarily used for massive real time interaction on companion screens. The platform runs in the Cloud and is very scalable and cost effective, for small (5,000) and big (500,000) audiences. Two Screen Now! is the second screen CMS, in which you can make your own companion screen, with design, translations and script. The created script can either be run manually or fully automated and synced via watermarking. The companion screen runs in all browsers on most desktops, tablets and mobiles in the internet browser. It uses different connection types like web sockets to connect to the real time platform. The HbbTV extension shows all quiz data gathered from the same local network/Wi-Fi. Participants in the living room that selected the Multiplayer option can see what their peers are doing on television.

5.3.2. German Pilot

Based on the three logical parts of the common TV-Ring approach depicted in section 5.1, the German pilot partners have identified dedicated appliances and enhancements of particular systems for their already operating TV, HbbTV and online services. Specific for the German pilot, dedicated functions of application server, content storage and content delivery are introduced here and a detailed description can be found in the following chapters.

In case of the German pilot, a dedicated unmanaged web server of the back-end platform holds the application server, and also text content (metadata) is stored there, as well as a number of JSON files that trigger content loading in the HbbTV application. Image content is located within RBB’s currently running CMS for web services delivering in a managed manner, while video content is stored in a third party CDN, which in parallel caters for a managed video delivery through the application. Pilot phase 1 and 2 made use of that specific architecture.

This structure allows for users with an HbbTV-enabled device to take part in the German pilot, using and consuming the HbbTV application and all of the multimedia content delivered through it. The appliance of a browser switch [see deliverable D3.3.1 (3)] ensures that users can access video files (MPEG-DASH or MP4, UHD or SD) dependent on their end device specification including the HbbTV stack.

5.3.3. Spanish Pilot

A joint work of the three Spanish partners have deployed a specific pilot infrastructure, which includes the backend platform where content and apps are stored, as well as the content is delivered through a specific delivery network, a CDN network :

13 version 2.5, 28/04/2015


- App server - Content Storage - Content Delivery

The HbbTV app is served using Apache HTTP/1.1 to end users that can see the TV-Ring application on a SmartTV.

The content used in the TV-Ring project can be of two types, live or VOD content. The VOD content is stored on a Windows fileserver such as multiple video qualities in MP4 format. The live content can be of two different types, live feed that no need storage and simulated live that are stored on other windows server in .TS format. In this case, to simulate a live streaming, use a VLC player witch an infinite loop. All contents are sent to Wowza server, which deliver the MPEG-DASH content to CDN.

When end users want to play the content and make requests to the portal, they are really asking the CDN to provide them.

Image 3: Spanish pilot content generation and flow scheme.

The backend is structured in one server being responsible for providing live content, direct real live content from multicast services, or simulated live content from a VLC player. Generated streams will then be forwarded to a Wowza2 Dash server for a unicast delivery.

As MPEG-DASH works only from HTTP/1.5 on, communication between HbbTV applications (client) and the server are made using this protocol. Apps are delivered using Apache httpd to end users who can see the TV-Ring applications on their Smart TVs.

In the picture below it can be seen the backend structure of the Spanish pilot. In the picture, it is shown how content is offered to end users of the two different networks: i2CAT network (Local CDN) and RTV network (Global CDN).

2 http://www.wowza.com/

14 version 2.5, 28/04/2015


Image 4: Backend structure of Spanish TV-RING project, including network overview.

Within the premises of TVC, live content is sent to the DASH server in unicast mode. Once the content has reached this server, it is responsible for generating the different qualities to offer adaptive content.

These users can be part of two different networks, on one side there is the i2CAT network and the other side is the internal TVC network. There is a CDN network between end users and the MPEG-DASH generator. This CDN is to serve content to end users with high availability and high performance.

By the Content Delivery Network, which will be described in higher detail in section 7, the Spanish partners are using two different types of networks:

1) The first type is a common CDN carried by a worldwide provider. (a) To set up the current Level3 CDN being used specifically for the TV-Ring

pilot. (b) Level3 has deployed its own fibre network in North America and Europe,

this network carries more than 50% of worldwide Internet traffic. This situation is replied in Spain at a local level.

(c) The Level3 CDN network is based in a level-made content distribution structure (Tiered distribution), this distribution by levels allows to improve its performance by reducing the number of content requests to the origin servers.

(d) In a level-made distribution network when the requested content is not found in the Edge Server Cache, it is recovered from a ‘parent’ cluster instead of the Origin server. With a good distribution level people can reduce significantly the origin server load, making the system being more efficient.

(e) Additionally to the communications between the Origin server and the CDN ‘parent’ clusters, another important feature element for high performance distribution is the communications network among the CDN nodes. Level3

15 version 2.5, 28/04/2015


CDN relies on its own IP backbone to distribute the content to the nodes which serve the final end users.

(f) This advanced technological solution jointly to its own network management allows taking over and monitoring traffic conditions within the network and anticipate potential bottlenecks and congestion situations.

(g) Set up the Level3 CDN network to work also with MPEG-DASH content having the back-end placed in the TVC premises where the content is stored, to deliver this content to the ISPs closest to end users (who have devices capable to connect to this network and having an appropriate receiver to play out the content).

2) The second type is a local CDN. The pilot deployed a set of servers covering a small area near Barcelona under an umbrella of hundreds of households being connected to the Internet by a fibre ISP (Internet Service Provider). Among these internet users a piece of them will be acting as pilot end users and will use the network connection to be connected with TV-Ring local CDN, they will be making use of the TV-Ring HbbTV apps during the pilot execution and will be collaborating with TV-Ring pilot consortium.

16 version 2.5, 28/04/2015


6. Application server

6.1. Dutch Pilot

6.1.1. Application hosting

The NPO has implemented a customised server cluster for hosting of all web applications, including the HbbTV.

A cluster of load balancers redirects all traffic to a cluster of front proxies, which handle all static (cached) content.

Image 5: App hosting architecture.

Dynamic (scripted) content is passed along to a cluster of application servers (back-ends) which in turn are connected to database servers.

A typical LAMP stack has been implemented:

Linux (derivative of Red Hat v4.4.6)

Apache (v2.2)

MySQL (v5.5)

PHP (v5.2)

Specifically for the HbbTV application, a dedicated “MIT-xperts iMux Multiplexer”-server has been added to the infrastructure in order to add the HbbTV application to the AIT of NPO’s DVB signal and provide DSM-CC carousel operations.

17 version 2.5, 28/04/2015


6.1.2. Second screen application deployment

The second screen platform is a framework based on Node.js and a set of standard libraries on top of this framework, deployed as multiple server processes that scale horizontally as a whole. The platform is specifically designed to drive interactive applications, starting with Second Screen applications.

The created script can either be run manually or fully automated and synced via watermarking. Heartbeat takes care of the synchronisation.

The HbbTV extension shows all quiz data gathered from the same local network/Wi-Fi where the application is running (in a TV set). The companion screen uses different connection types like web sockets to connect to the real time platform.

6.2. German Pilot

6.2.1. Application Storage

The application (description see deliverable D3.3.1 (3)) was stored on a 3rd party virtual server hosted by Host Europe Ltd, having the following hardware and software specifications:

CPU Intel Xeon CPU E5-2620 v2 @ 2.10GHz

RAM 16GB

Operating system Ubuntu 12.04 LTS

Web server Apache 2.2.22

Scripting PHP 5.3.10

Database MySQL 5.5.41

The storage was used for holding the application itself and the JSON formatted data files needed for defining and controlling the content allocation within the application, as specifically described in deliverable D3.3.1. (3)

6.2.2. Application deployment

The application was deployed in an unmanaged manner through the storage server described above. It was signalled in the AIT table of

1. KiKA channel via satellite, cable in TV-Ring pilot phase 1 and of 2. RBB’s DVB playout via satellite, cable and terrestrial channels (see AIT snippet below)

in TV-Ring pilot phase 2 Code snippet AIT:

18 version 2.5, 28/04/2015


Image 6: XML file of launcher bar widget.

The AIT defines the calling of a standard HbbTV launcher bar (“Startleiste”), that is started automatically on any HbbTV-enabled device once the channel is tuned-in. In that launcher bar a number of widgets are present, which act as starting points for the dedicated HbbTV applications, so as with the application for “Abenteuer Liebe”.

Image 7: HbbTV launcher bar including German pilot widget on the left "verknallt & abgedreht", the actual program title.

6.3. Spanish Pilot

6.3.1. Application Storage

The code is uploaded to an Apache HTTP server via sftp using a FTP client such as FileZilla when a stable version of the application is available. This server is part of the internal TV3 network and used to offer web content to end users.

19 version 2.5, 28/04/2015


The application is made up of different folders and files. It has an index.html, a folder containing the .js files, another contains the .css files and other with the .html files.

6.3.2. Application deployment

This application was deployed using Yeoman3 structure with AngularJS4 generator.

For compilation it was used Grunt5 which has minimized the automated build and test time. Grunt.js is Node.js applications which through a configuration file (Gruntfile.js) performs tasks such as copying files, minimize the .js, running tests, code coverage, observe changes in scripts, among other functions.

When there is a stable version of the application it can be stored on server as the one described above. That server is used to offer the HbbTV application to end users.

6.3.3. Second-screen synchronisation mechanism

The concept (applied to the second screen of the TV-Ring applications) is meant to synchronise the television content on any mobile device with Internet access. Thanks to this ability to communicate with the TV HbbTV application from any mobile device, the remote control could be replaced.

To implement this function Firebase6 was used, which is a platform specialising in synchronising applications that are using web sockets, to synchronize different devices. Firebase is a multiplatform online service that works by synchronising data between different applications in just a few milliseconds using only front-end code. In TV-Ring project an example of application using second screen synchronisation through Firebase was implemented:

3 http://yeoman.io/

4 https://angularjs.org/

5 http://gruntjs.com/

6 https://www.firebase.com/

20 version 2.5, 28/04/2015


Image 8: Tablet is synchronized with the TV through Firebase using web sockets.

21 version 2.5, 28/04/2015


7. Content Storage

7.1. Dutch Pilot

7.1.1. Web content

All related images are stored on the front proxy servers (within NPO’s own server cluster) which are optimised for delivery of static (cached) assets.

Program information, EPG data and all other relevant metadata are stored on the database servers (within NPO’s own server cluster).

It is described in deeper detail in section 6.1.

7.1.2. VoD/Catch-up services

For the “Recommender” pilot the NPO’s own CDN was utilised while for the “DRM” pilot the CDN of partner “Infostrada” was utilised. Both CDN infrastructures are “live” services, handling storage, load balancing and adaptive play out. It is also described in deeper detail in section 8.1.

7.2. German Pilot

In the German pilot the video storage and delivery was realized by the commercial content delivery network (CDN) Akamai. Akamai is used by every German public broadcaster for video content hosting and delivery. It’s one of the world's largest distributed computing platforms.

The company operates a network of servers around the world and rents capacity on these servers to customers who want their content distributed faster to the user. There are 170 000 Akamai edge servers in 102 countries which are responsible for 15-30% of the worldwide Internet traffic. Within the German pilot, the Akamai CDN was just used for video content storage and delivery, as it is shown below in Figure 10.

22 version 2.5, 28/04/2015


7.2.1. Web Content

The web-based content, e.g. pictures and a small number of videos was hosted on RBB’s web servers and maintained by its CMS running Adobe Experience Manager 5.6.1 software. However, the exact specifications of RBB’s online storage facilities cannot be made public.


The Akamai Storage consists of 26 Geo-distributed locations. The content was uploaded to the designated directory at the Akamai Storage. In a next step, the content is replicated automatically multiple times within each location, at least at two geographic locations. This provides high redundancy and a fast network reaction. Request are routed to the optimal location for availability and performance.

Image 9: Video storage and delivery within the German pilot.

23 version 2.5, 28/04/2015


Image 10: Akamai CDN Content Storage.

7.3. Spanish Pilot


The contents are stored into a Windows fileserver folder in mp4 format. These contents are encoded using ffmpeg7 from .AVI videos. The end result is a series of videos with different qualities (both formats SD and HD could be included) in mp4 format.

This is an example of ffmpeg instruction used to generate mp4 content. In this example the GOP size is fixed to 25 frames to get segments to one second duration, and the aspect ratio to 16:9 using ffmpeg:

ffmpeg -i %1 -vf:0:v yadif -s 1920x1080 -aspect 16:9 -pix_fmt yuv420p -c:v libx264 -g 60 -force_key_frames expr:gte(t,n_forced*1) -keyint_min 26 -sc_threshold 100 -b:v 7000k -flags +aic+mv4 -profile:v %profile% -level:v 4.0 -c:a aac -strict -2 -f mp4 "G:/OHD/26/OHD_26_7M.mp4"

When the CDN needs any content, Wowza streaming server sends the MPEG-DASH content encoded in different qualities videos. The CDN stores the chunks of VOD content in its cache for a specific period of time (up to one week), while the chunks of live content are stored only a few minutes. The mpd files of the all content are only stored on the CDN a few seconds.

Wowza is a specific streaming media server used for the transmission of live and on-demand video content over IP networks to computers, smart TV, game consoles, smartphones and other devices. The server is based on a Java application that runs on Linux, Windows and Mac OS.

Wowza is now compatible with MPEG-DASH and with a wide range of other transmission standard protocols such as HLS, HDS, Smooth Streaming, RTSP, Multicast and RTMP.

7 https://www.ffmpeg.org/

24 version 2.5, 28/04/2015


The Wowza software offers the possibility to easily implement adaptive streaming, while the transcoder module (“Add-on”) running on the same server hardware allows to encode live streams into adaptive bitrate streams.

7.3.2. Live services

Live content is stored in memory using computer buffering, while it is encoded in different qualities to offer DASH streaming and the delivery of the manifest file to end users. This file is an xml document that describes time periods and contains information about the quality representations and codecs used for each component available.

The following is an extract of a manifest file (MPD (1)) with the time periods and information about the video component:

<AdaptationSet id="0" mimeType="video/mp4" maxWidth="1920" maxHeight="1080"

par="16:9" maxFrameRate="25" segmentAlignment="true" startWithSAP="1"

subsegmentAlignment="true" subsegmentStartsWithSAP="1">

<SegmentTemplate timescale="90000" media="chunk_ctvideo_cfm4s_rid

$RepresentationID$_cs$Time$_mpd.m4s" initialization=

"chunk_ctvideo_cfm4s_rid$RepresentationID$_cinit_mpd.m4s">

<SegmentTimeline>

<S t="43281542250" d="180000"/>

<S d="180000"/>

<S d="180000"/>

<S d="180000"/>

<S d="180000"/>

<S d="180000"/>

<S d="180000"/>

<S d="180000"/>

</SegmentTimeline>

</SegmentTemplate>

<Representation id="p0a0r0" codecs="avc1.640028" width="1024" height="576"

frameRate="1" sar="1:1" bandwidth="3500000" />





</AdaptationSet>

For the live streaming, there are two options: the first option is a live feed, which is sent to Wowza server via unicast; the second option is to simulate a live content which is packaged into a TS file using a TS Multiplexer before being sent to the Wowza server.

25 version 2.5, 28/04/2015


Image 11: Live services diagram.

When the content reaches the Wowza server, it encodes that content into MPEG-DASH package to provide the required streams to the CDN.

26 version 2.5, 28/04/2015


8. Content Delivery

8.1. Dutch Pilot

8.1.1. Content Delivery Network

8.1.1.1. VOD

NPO catch-up video content (VOD) is made available through NPO’s own customized content delivery platform, named “HASP” (HTTP Adaptive Streaming Platform). From there the content is distributed through (mostly) private peers with the big network operators and a fallback CDN from KPN. Different streams are offered to different devices and platforms, for the case of content used in HbbTV applications the following specs were observed:

VIDEO

Codec H264 AVC Baseline 1.2

Container M4V Quicktime

Bitrate 180 – 908 kbps

Frame rate 25 fps

Frame size 160×90 – 640x360

AUDIO

Codec AAC-LC

Bitrate 20 – 128 kbps

Sample rate 32 – 44.1 kHz

Channel Stereo (L, R)

8.1.1.2. SVOD

NPO premium catch-up video content (SVOD) is made available through the commercial CDN-services of NPO-partner “Infostrada”.

Specifically for the DRM pilot, the necessary SVOD content was provided via this route. For HbbTV, the following specs were observed:

27 version 2.5, 28/04/2015


Resolution Aspect Ratio Video Codec Video Bitrate Frame rate Container

768x432 16:9 H264 1.2Mb/s 50 MSS-MP4

960x540 16:9 H264 1.9Mb/s 50 MSS-MP4

1280x720 16:9 H264 3.7Mb/s 50 MSS-MP4

1920x1080 16:9 H264 8.5Mb/s 50 MSS-MP4

The necessary mechanisms for license acquisition services were also implemented via a Microsoft PlayReady DRM protection licensing server. The License Server has been provided with a special entry point for the TV-Ring pilot, by which means security tokens can be issued for pilot tv’s without interfering with commercial operations (paid subscriptions) in order to deliver security tokens for license acquisition by the TV-Ring pilot application module(s).

8.2. German Pilot

As described in section 6.2.1 the HbbTV application is running on a 3rd party virtual webserver provided by Host Europe Ltd. If an end user requested a video stream either from the HbbTV application or from the website, the video was delivered by the CDN network in the background. Although the video delivery was triggered by a static link within the application, the file was actually delivered by the nearest edge server of the CDN, depending on the location of the end users device.

8.2.1. Streaming content

8.2.1.1. Content encoding / Use of UHD

The video sources were encoded in a half-automatic workflow at IRT (see deliverable D3.3.1 (3)). Encoding services offered by Akamai were not used, because they did not support MPEG-DASH (1) and UHD encoding during the pilot phase. Afterwards the video encoding, for the different progressive and adaptive streaming formats, was completed, the resulted video files were uploaded to the CDN storage via FTP.

8.2.1.2. MPEG-DASH streaming

Content delivery is done using MPEG-DASH streaming. This adaptive protocol allows switching between different video streams which are hosted at the content storage server. The end user’s video player decides, based on its internal buffer management, which video format is possible at the moment depending on the available channel rate. Prerequisite for this is a segmentation of the video data into several fragments. These fragments are stored at the Akamai streaming server. The fragment size is determined by Group of Pictures (GOP) of the video elementary stream. Finally the player is able to load different kind of segments during the playback and the switching between the segments is seamless and without any interruption of the video or audio.

Within the pilot adaptive streaming is only used for on demand (OD) distribution while the qualities the player could choose are defined in the manifest file (MPD). This file is also stored

28 version 2.5, 28/04/2015


at the Akamai streaming server and will be loaded by the player before the playback of the video starts.

<?xml version="1.0"?>



<MPD xmlns="urn:mpeg:dash:schema:mpd:2011" minBufferTime="PT1.500000S"

type="static" mediaPresentationDuration="PT0H24M3.40S"

profiles="urn:hbbtv:dash:profile:isoff-

live:2012,urn:mpeg:dash:profile:isoff-live:2011">

<ProgramInformation moreInformationURL="http://gpac.sourceforge.net">

<Title>upload/VuA_Folge_03/dash/VuA_Folge_03_hd.mpd generated by

GPAC</Title>

</ProgramInformation>

<Period duration="PT0H24M3.40S">

<AdaptationSet segmentAlignment="true" bitstreamSwitching="true"

maxWidth="1920" maxHeight="1080" maxFrameRate="50" par="16:9">

<SegmentTemplate initialization="VuA_Folge_03_hd_set1_init.mp4"/>

<Representation id="1" mimeType="video/mp4" codecs="avc1.64001f"

width="640" height="720" frameRate="50" sar="2:1" startWithSAP="1"

bandwidth="1488289">

<SegmentTemplate timescale="12800"

media="VuA_Folge_03_640x720_1.5M_dash$Number$.m4s" startNumber="1"

duration="22394"/>

</Representation>

<Representation id="2" mimeType="video/mp4" codecs="avc1.64001f"

width="960" height="720" frameRate="50" sar="4:3" startWithSAP="1"

bandwidth="2483717">

(…)

</Representation>

</AdaptationSet>

</Period>

</MPD>

8.2.2. Delivery Network

On the end-user side there were no restrictions regarding the type of network connection. High-bandwidth networks were obviously necessary for a delivery of HD and UHD content via MPEG DASH. For the German pilot regions this is mostly ADSL and VDSL lines.

On the provision side the intelligent platform of Akamai is used. It consists of a network of 170000 servers deployed in round about 102 countries in more than 2100 locations. The numbers in the table below gives an impression of the daily network traffic of the Akamai network (status as of 2014).

Daily Bit Rate ~ 12,9 Gbps

Daily Request Rate ~ 30 hits/sec

Daily Bytes Delivered ~ 104,7 TB

Daily Requests Delivered ~ 1,57 billion

Image 12: Example of an MPD file used in the German pilot.

29 version 2.5, 28/04/2015


Daily Unique Client IPs ~ 560 million

If end users request some content, the platform directs the request to an edge server which is physically near and logically most available. The edge server fetches the content from the origin server and caches the content with its own recources at the edge. This results in very low latency at the end user side and reduces demand at the origin server.

Image 13: Akamai CDN Edge Server arrangement.

8.3. Spanish Pilot

8.3.1. Streaming content

8.3.1.1. Media Streaming Server (Wowza configuration)

In order to configure Wowza MPEG-DASH services at Wowza Media Server, a new application should be created, at least one for live content and another for on-demand content. Each Wowza application is configured modifying the corresponding ‘Application.xml’ file. It is also need to modify the file VHost.xml to assign port 80 to http requests. The Wowza web page (www.wowza.com) provides some tutorials explaining the concrete steps needed to configure MPEG-DASH applications.

Some considerations and the configuration of some extra parameters are required for getting a suitable MPEG-DASH streaming behaviour. For on-demand applications, it is very important to set some specific parameters.

Wowza specification suggests to set the chunks duration with values being a multiple of the video GOP size. To carry out this, the parameter <mpegdashChunkDurationTarget> with a value of 2 seconds must be set in the container HTTP Streamer/Properties. For example, if having a video with a GOP of 25 frames (1 second), then a value of 2 seconds that corresponds to 50 frames can be used.

As another example, for the live applications Wowza suggests the next parameters to be set with the following values (taken from Wowza configuration guide):

- mpegdashChunkDurationTarget: This parameter controls the duration of the chunk. In

case you want a chunk of 2 seconds you shall set this value to 2000 (temporally values

http://www.wowza.com/

30 version 2.5, 28/04/2015


are expressed in milliseconds). It is important to set the value of this parameter with a

multiple of the video GOP size.

- mpegdashMaxChunkCount: This parameter is used to regulate the maximum number

of available chunks. Value: 16.

- mpegdashPlaylistChunkCount: Number of chunks contained in the MPD file in response

to a request from a client stream DASH. If the value is 8, the server will return a MPD

with 8 chunks.

- mpegdashMinimumUpdatePeriod: Indicates the periodicity with which the client

request a new DASH MPD. This value must never take the value 0. It is recommended to

use the same value as the chunk size. Value: 2000.

- mpegdashStrictSpecComplianceForAST: This Boolean set to true force to put a Wowza

MPD @availabilityStartTime fixed and common to all MPDs, giving a time reference for

synchronisation.

For each live application, multiple quality representations can be generated by activating the Transcoder Add-on option and configuring accordingly the file transrate.xml.

Here is an example with two different qualities, one Pass-through (original quality) and the other with a bit rate of 6Mbps:

31 version 2.5, 28/04/2015


The Pass-through option allows bypassing the video at the same bitrate and codecs present at the source, in this case the source bitrate is 7Mbps. This is an interesting option for saving processing resources at the Wowza server.

The different quality representations can be joined into different groups to provide services that fits on different target devices (PCs, mobiles, TVs…), as you can see below.

32 version 2.5, 28/04/2015


8.3.1.2. MEPG-DASH streaming

For VOD content, the different qualities are grouped into a SMIL8 file that is responsible for making switch between qualities. This file is saved in the same folder that contained MP4.

To offer a live content, Wowza provides a transrate xml file that is used to create the different qualities and which can be used to define the codecs, resolution, bitrate and others. Once the file is created, through Wowza interface the different streams are delivered using MPEG-DASH technique.

A problem that has been identified is that the capacity of the machine with Wowza to encode the different qualities is limited, for example, the machine will not be able to encode multiple streams in HD quality. The solution to this problem has been to provide quality HD using option Pass-through and other qualities that were SD.

8.3.2. Delivery Network

8.3.2.1. Local Delivery Network

A combination of CDN and Transparent Caching has been implemented, where the latter is the last step in the distribution chain. While the CDN caters the service providers with the most extensive, reliable caching of content from participating content owners, the Transparent Caching does its part by caching unmanaged OTT content from the full range of content providers that aren’t participating in the collaborative CDN effort.

Essentially the Transparent Caching intercepts client requests and redirects users to cached content. The system includes a Routing Policy to redirect incoming TCP packets to specific IP and port, and a Proxy Server that acts as a regular server and proxy cache server at the same time. This Proxy Server features are, on one hand differentiate cache configuration as manifests might have very short time while video chunks might last longer, and on the other hand, enable control over HTTP headers to traceability and monitoring.

8 http://en.wikipedia.org/wiki/synchronised_Multimedia_Integration_Language

33 version 2.5, 28/04/2015


Image 14: Local CDN block diagram.

It also has been implemented a Statistics Collector System that runs on the edge node and collects statistic data to be processed in real time and offline. It includes some features like Event Processor to monitor data updates, Dashboard to display the control and management parameters, and a Graph Rendering tool to represent in a comprehensible way the stored data.

8.3.2.2. Global Delivery Network

Level 3 (also L3) is a leading global IP and Ethernet solutions provider with the world's first integrated global IP-based network. As one of only a handful of Tier 1 providers, it operates one of the largest IP networks in the world with over 26.8 TB of global IP and CDN capacity.

Image 15: Worldwide Level3 CDN nodes interconnection.

To support the global network, Level 3 has seven major NOCs located in the United States, South America and Europe. These geographically dispersed centres offer full redundancy between locations ensuring that major network events are addressed around the clock.

34 version 2.5, 28/04/2015


The current Level3 CDN network consists in:

3 PoPs in Spain (Madrid, Barcelona, Valencia)

More than 40 PoPs in EMEA

More than 20 PoPs in USA

8 PoPs in APAC

10 PoPs in LATAM

This network of points of presence (PoP) is supported by the Level3 network infrastructure, with own global connectivity.

The Level3 CDN is based on an active network approach, where the CDN node structure works over an own network infrastructure, which allows the operators TIER 1 like Level3 achieve the rest of Internet networks without the need to acquire IP traffic, avoiding bottle-necks, providing low latency and maximising the content delivery bandwidth to end users.

Level3 CDN network is based in a structure of content distribution by levels (Tired distribution), allowing to improve its performance by reducing the number of content requests to the origin server.

This advanced technology allows a set of mechanisms that makes the network having one of the best performances in worldwide CDNs. The most important of these features are:

Traditional CDN Services Options are:

Everything will be located at the cloud.

OD content will use L3 storage.

Live Content will use 14 pairs of AOS in Cloud (London & Frankfurt). Encoders will work in push mode sending content in HLS to AOS (primary and secondary in Level3 network). The aggregated net publishing bandwidth is approx. = 1,6Gbps to Level3 network.

The customer will need to ensure connectivity to the AOS, in any case.

Features:

Average Throughput per user: 2,58 Mbps (users are equally distributed through the 150 channels)

User concurrency: 1%. (Typical concurrency for similar operator in Spain)

Main Service characteristics: o Services Concurrency %1 o Max Profile HD Mbps 6,50 o Max Profile SD Mbps 1,60 o Nº HD services 30 o Nº SD services 120 o Average throughput/user Mbps 2,58

Configured CDN Properties:

35 version 2.5, 28/04/2015


Within the TV-Ring project, in order to prepare the Spanish pilot, RTV and TVC started making CDN delivery tests using MPEG-DASH transportation standard protocol with High Quality video content at 1, 2, 5 and 10 Mbps.

The deployed pilot infrastructure had an architecture very similar to the common delivery services you can find in the market.

The content is stored and managed in TVC premises, then is sent to the RTV CDN node (Origin Server) where it is at disposal for the end users to be requested.

Image 16: TV-Ring global CDN network configuration diagram.

In this task T3.4 it has been configured two properties especially for the TV-Ring project pilot. A property serving the Live (Catch-up) content and the other property ready for serving the VoD (Video on Demand) content.

The use of these properties http://tv3-live.dash.adaptive.level3.net/ and http://tv3-od.dash.adaptive.level3.net/ connect with the multimedia content through the Wowza Streaming Engine which will serve the requested content thus directly from the origin server or through any other of the Edge servers.

Live (Catch-up):

Property: http://tv3-live.dash.adaptive.level3.net/

URL in the TV-Ring Server:

http://tvring.tv3.cat/live/ngrp:cam_0.stream_global/manifest.mpd

URL of the same manifest used in the CDN:

http://tv3-live.dash.adaptive.level3.net/live/ngrp:cam_0.stream_global/manifest.mpd

Content server

INPUTmediaserver

EDGEserver

EDGEserver

EDGEserver

EDGEserver

CDNInternet

MPEG-DASH request

DASH

1

2

DASH content ORIGIN point

Public URL

Content Origin

CMS

http://tv3-live.dash.adaptive.level3.net/

http://tv3-od.dash.adaptive.level3.net/


http://tv3-live.dash.adaptive.level3.net/





36 version 2.5, 28/04/2015


VoD:

Property: http://tv3-od.dash.adaptive.level3.net/

URL in the TV-Ring Server:

http://tvring.tv3.cat/vod/mp4:el_foraster_no_i_1_GOP.mp4/manifest.mpd

URL of the same manifest used in the CDN:

http://tv3-od.dash.adaptive.level3.net/vod/mp4:el_foraster1_GOP.mp4/manifest.mpd

The global CDN network has been configured in a way that the pilot consumption can be easily observed and later on used for the pilot evaluation.

A monitoring mechanism for the two CDN properties (Live and On Demand) was setup in order to be able to provide a daily evolution of the content consumption (measured in Giga bytes and in number of requests) during the whole pilot execution period. This information will be gathered and used in the task T4.5 final pilot evaluation and included in the deliverable D4.3.

Example of the consumption during the month of December 2014.

Live

- VoD




http://tv3-od.dash.adaptive.level3.net/vod/mp4:el_foraster_no_i_1_GOP.mp4/manifest.mpd

http://tv3-od.dash.adaptive.level3.net/vod/mp4:el_foraster_no_i_1_GOP.mp4/manifest.mpd

37 version 2.5, 28/04/2015


Blue continuous and dotted lines are showing the consumed data, specifically the volume in GB and the number of requests for each of the two properties (Live and On Demand) while red lines (both continuous and dotted) are showing the addition of these two properties. So, it can be seen that in some moments the VoD property is getting high consumption while live content is rounding zero consumption, and some other times is showing the opposite effect, whose behaviour depends on the type of the content that is being broadcasted.

9. Demonstrations system setup

9.1. NPO Demonstration setup

9.1.1. Recommender and DRM demo

Required device: Samsung 2013 model HbbTV enabled.

DVB signal with NPO HbbTV application URL. This was delivered to the TV using a recorded

TS stream as the Dutch HbbTV signal was not available during the demo.

9.1.2. NPO Second screen

Required device: Samsung 2013 model HbbTV enabled.

Second screen devices like mobiles and tablets

Internal Wi-Fi network

9.2. German Pilot

Through the implementation of the browser switch, as described in deliverable D3.1.1 (3), the German demonstration setup, as the actual pilot, is targeting as much end devices as possible, from HbbTV 1.0 to HbbTV 1.2.1 implementations. Therefore, no specific devices are required for a demonstration, unless they do not support high-bandwidth video playback or multi-segment DVB AIT (for safely returning to DVB from IP video playback). A high-bandwidth network connection is certainly needed, when high-quality video is to be demonstrated here.

As the pilot phase 1 and 2 are over, the German pilot TV-Ring application is no longer signalled live in DVB. RBB recorded a transport stream of RBB’s HD channel containing the application signalling from the on-air phase (2), including the URL to the application server. A target device can read the AIT signalling and open the URL through its HbbTV implementation. The mentioned transport stream includes a complete episode of the broadcasted programme “verknallt & abgedreht” and can be played out with the help of any local DVB playout equipment, applying a capable DVB modulator and a coax cable.

38 version 2.5, 28/04/2015


9.3. Spanish pilot Demonstration setup

The pilot consortium deployed a mechanism to be able to play demonstrations in TV-Ring receivers when no broadcast channels nor terrestrial neither satellite are able to be tuned for different reasons.

This mechanism will allow simulating a basic TV-Ring system under these circumstances.

The system is composed by a local broadcasting of a TV channel and an Internet connection. So, it is needed to provide:

Broadcast TV content in DVB format with appropriate SI (Service Information) tables. Laptop where playing out this DVB content. Local DVB modulator DVB-T/S Internet access with a minimum of 10Mbps of data rate. HbbTV 1.2 (2) receiver device (STB or iDTV)

Web portal, HbbTV apps and Video content are stored in the remote platform, as if people were using a common TV-Ring service. So, they will be available for any device that could be connected on Internet and could reach the TV-Ring servers.

The CDN network for content delivery is also reachable if the system can be connected to Internet.

Obviously, it is needed the Internet connection to be faster than the bit rate of the used content files. Or it will be needed to use content at a bitrate lower than the provided Internet connection.

Image 17: Demonstration setup scheme.

In that situation, it will be just needed to simulate the broadcast TV channel in order to be able to provide signalization for the URL where the HbbTV content and applications are located. This URL is embedded in the AIT (Application Information Table) table within the DVB conformed file.

39 version 2.5, 28/04/2015


9.3.1. RF Channel simulation

It will be needed to have the proper content to be modulated in RF at very low power. So, a .TS file will be stored in a computer (laptop) to be ready for playing out.

The .TS file needs to contain at least one complete TS (Transport Stream) with one TV service as detailed in the DVB specification (4). This means that an appropriate service information (SI) (5) plus video, plus audio content will be played in the TV set.

Service Information tables needed for a good receiver performance:

PAT: Program Association Table PMT: Program Map Table SDT: Service Description Table. AIT: Application Information Table.

The SDT table provides basic information like the ‘transport stream id’ and the ‘service id’.

The AIT table carries the URL where the HbbTV application could be found.

Content:

Video component Audio(s) component(s)

A specific software tool like StreamXpress in our case will be in charge of playing out the content from the .TS file stored in the computer.

Image 18: Transport Stream (TS) file containing the TV services to be locally broadcasted.

40 version 2.5, 28/04/2015


The modulator device is connected to the computer through one of the USB ports and gets the generated signal. Then this signal is starting to be modulated and wired directly from the RF source to the receiver.

It can also be really broadcasted in a small room connecting a proper antenna at the modulator RF output. Then, in some cases another antenna at the receiver RF input could even be needed.

Image 19: Portable low power DVB Modulator.

It is recommended to find and use an empty RF channel to avoid interferences with current on air TV stations.

Once the RF channel is broadcasted with the appropriate content, just need to switch on the TV set or STB and tune at the right RF channel.

When the channel is tuned just need to press the red button to run the TV-Ring HbbTV apps.

9.3.2. Receivers testing

Within the work done in this task during first half of the year 2014 the project had been testing the performance of playing out MPEG-DASH content in several brand new receiver models with HbbTV 1.5 capabilities. The manufacturers were still working trying to finish the lasts versions of software development and applying the fine tune in many of their features, specially the performance with MPEG-DASH content. So, they suggest us not to share the results between them and neither with outer people.

It was being used up to 5 different content types.

Table 1: Receivers testing results table.

41 version 2.5, 28/04/2015


1) CDN LIVE HD ABR (TIME BASED MDP) --> HD and SD Live Content streaming Dash adaptive (watermarking).

2) CDN LIVE HD (TIME BASED MDP) --> HD Live content 3) CDN VOD ABR (TIME BASED) --> HD and SD Streaming Dash adaptive (watermarking). 4) CDN VOD HD (TIME BASED MDP) --> Single HD 5) CDN VOD SD (TIME BASED MDP) --> Single SD

None of the tested models worked fine at 100%. By summer of 2014 the pilot consortium was then noticed that to find a set of receivers for the pilots would not be an easy task.

It was finally decided to purchase the VESTEL device (a Turkish manufacturer very well established in Europe especially in Germany and Spain), that would be deployed in the Spanish pilot. It was expected that devices would be meeting some requirements by Mid – Final September 2014.

After some initial delays and malfunctions, the final working software version arrived in early December.

Image 20: The first of the brand new VESTEL TV sets deployed in the village of Gurb.

42 version 2.5, 28/04/2015


10. Glosary

CDN : Content Delivery Network.

CMS : Content Management System. System in charge of managing the ingested multimedia content and its associated metadata.

DASH : Dynamic Adaptive Streaming over Http. An ISO standard for video delivery over IP networks (1).

DRM : Digital Rights Management. A mechanism for content protection.

Edge Server Cache: A server located in the outer part of the network with storage capabilities allowing to act as a buffer or cache memory.

Ffmpeg : A complete, cross-platform solution to record, convert and stream audio and video.

GOP : Group of Pictures. Concept used in MPEG2 and MPEG4 encoding video formats.

ISP: Internet Service Provider.

Load Balancer : Distributes workload between two or more computers in order to balance their loads trying to maximize the throughput.

MPD: Media Presentation Description and segments format. Described in section 5.2 of (1)

NOC: Network Operator Centre. Network Node allocating one of the network control sites.

PoP : Point of Presence. Indicates locations (countries) where CDN is somehow present.

Recommender : Application trying to guess the consumer likes.

SMIL: A W3C recommended eXtensible Markup Language (XML) to describe multimedia presentations. UHD : Ultra High Definition (Video). Currently referred to 3840 x 2160 pixels resolution video.

43 version 2.5, 28/04/2015


11. References

1. Standard, ISO. ISO_IEC_23009-1_2012 DASH. 2012-04-01. 23009-1.

2. ETSI TS 102796 v1.2.1 - Hybrid Broadcast Broadband TV 1.2.

3. TV-Ring. D3.3.1 Service Implementation Report. 2015.

4. ETSI TS 102 809 Digital Video Broadcasting (DVB) Signalling and carriage of interactive applications and services in Hybrid broadcast/broadband environments.

5. ETSI TS 102 809 Digital Video Broadcasting (DVB) Specification for Service Information (SI) in DVB systems.

44 version 2.5, 28/04/2015


12. Annex I - Configuration of the cache nodes

One of the goals in the Spanish pilot has been to test and validate de possibility of using transparent caching techniques in order to provide CDN like features into the last mile. Basically what has been tested is the idea of placing edge nodes at the operator networks edge. This section describes the configuration parameters of the software that has been used. Cache nodes are based on Nginx HTTP server. Nginx has been reported to be a very efficient and robust tool and it is adopted by major OTT companies such as Netflix. Nginx supports also proxy cache features. More concretely and as it can be seen in the following subsections the cache nodes have been based over the following software:

Nginx: is an HTTP and reverse proxy server.

Collectd: is a daemon which collects system performance statistics periodically and provides mechanisms to store the values in a variety of ways.

Riemann: aggregates events from your servers and applications with a powerful stream processing language.

InfluxDB: is an open source database written in Go specifically to handle time series data with high availability and performance requirements.

Graphana: is most commonly used for visualizing time series data for Internet infrastructure and application analytics.

Main pieces are Nginx (the proxy cache) and Collectd (in order to monitor several metrics of the cache). Here metrics collection is defined to work with a granularity of 2 seconds, so with the tool set defined here all edge nodes will be capable to feed (updating data every two seconds) a server that will store, process and display desired metrics (active TCP connections, CPU usage, memory usage, bandwidth savings, etc).

12.1. Configuration of Nginx as a proxy cache

Below there is proxy cache configuration sample for the Nginx:

user www-data;

worker_processes 4;

error_log logs/error.log debug;

pid logs/nginx.pid;

events {

worker_connections 1024;

}

http {

include mime.types;

default_type application/octet-stream;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for"';

log_format cache '|time_local|$time_local |remote_addr|$remote_addr

|upstream_cache_status|$upstream_cache_status

|upstream_response_length|$upstream_response_length '

'|upstream_addr|$upstream_addr

|upstream_response_time|$upstream_response_time |request|"$request"

|status|$status |body_bytes_sent|$body_bytes_sent';

sendfile on;

45 version 2.5, 28/04/2015


keepalive_timeout 65;

proxy_cache_path /mnt/nginx/cache levels=1:2 keys_zone=one:100m

inactive=365d max_size=3500m;

proxy_temp_path /mnt/nginx/tmp_cache 1 2;

server {

resolver 8.8.8.8;

listen 80;

access_log logs/proxy.access.log cache;

location / {

proxy_pass http://appcluster$request_uri;

proxy_set_header Host $http_host;

proxy_http_version 1.1;

location ~* .*\.(m4v|m4a|m4s|ts)$ {

proxy_cache one;

proxy_cache_lock on;

proxy_cache_lock_age 2s;

proxy_cache_lock_timeout 5s;


proxy_cache_revalidate on;


proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_ignore_headers X-Accel-Expires Expires Cache-Control;

proxy_cache_key $host$uri$is_args$args;

proxy_cache_valid any 7d;

}

location ~* .*\.(mpd|m3u8)$ {

proxy_cache one;

proxy_cache_lock on;

proxy_cache_lock_age 2s;

proxy_cache_lock_timeout 5s;


proxy_cache_revalidate on;


proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_cache_key $host$uri$is_args$args;

proxy_cache_valid any 1s;

proxy_ignore_headers X-Accel-Expires Expires Cache-Control;

}

# This is going to be the location to poll for some inner Nginx

metrics

location /basic_status {

access_log off;

stub_status;

}

}

}

upstream appcluster {

ip_hash;

server 84.88.32.105 weight=1 max_fails=2 fail_timeout=10;

server 84.88.32.115 weight=1 max_fails=2 fail_timeout=10;

}

}

46 version 2.5, 28/04/2015


In http directive there is the place to define logging format (we defined a custom format for caching, adding upstream_cache_status information) and proxy storage parameters. Proxy_cache_path defines the folder where to store the cache, sub folders levels, name key storage area (key_zone) and its capacity, time to live (inactive param, 365 days in the example) and maximum size of the cache (max_size). Note that max_size should be defined with a smaller value than the storage capacity, this is done due to the proxy_temp_path. Temporal storage in proxies.

In this example we have three different proxy policies. Under server directive there is a location directive that defines the configuration at root level. Top level location directive defines a generic proxy behaviour, acting just as a bypass, original request is resent to the original destination without any change. This is done using proxy_pass and proxy_set_header directives. $scheme, $http_host and $request_uri are nginx variables taken from the HTTP request headers that might be used to generate the new request. So this $scheme://$http_host$request_uri construction leaves everything as it is, just forwarding to the original request. However we defined two lower level location directives that make use of regex to match incoming urls. In this case we have one rule to match requests to .m4v, .m4a, .m4s or .ts file extensions and another one that matches .mpd and .m3u8 file extensions, obviously this is done for HLS and MPEG-DASH caching. Inside this two locations there is another proxy_pass and proxy_set_header, with the right parameters to redirect requests to a specific IP. Proxy_cache directive sets the proxy storage area, proxy_cache_key defines the id used to identify equal requests, proxy_cache_valid (1 second and 7 days in this example) defines how long it takes the content to expire and finally proxy_cache_revalidate enables the revalidation process of expired content. Expired content is not deleted from the cache, this is determined by the inactive time set in the Proxy_cache_path directive, 365 days in this case. So content from the cache is deleted or overwritten just in three cases: it has been inactive in the cache more than 365 days; the cache is full and drops content starting by the oldest content; and the content is overwritten because the proxy_cache_valid time expired and there is a newer version in the origin server. This means that content considered to be expired (being inactive longer than proxy_cache_valid) it needs to be revalidated; then if a request to such a content arrives the proxy asks to the origin server for a revalidation of the expired content, if this content has been modified it is reloaded and updated from the origin server, if not, the origin server returns a NOT_MODIFIED http response so the proxy can revalidate its own current data. In that last case the inactive timestamp of cached data gets restarted and becomes a valid content for another proxy_cache_valid period. Upstream directive is used to define a round robin load balancing where destinationIP1 and destintionIP2 are the two origin servers. weight=1 defines how much traffic should be directed to this server, both at the same value is 50%, max_fails=2 is the number of fails before considering the server not reachable, fail_timeout is the time in seconds to admit failure.

12.2. Collectd configuration

Collectd is a plugin based daemon, so depending the nature and origin of the metrics to gather different plugins are going to be used. In this case the following ones are used:

Disk Free: It collects metrics about the status of a disk volume.

Tail: It parses certain file line by line, used to collect data from logs, Nginx in this case.

Nginx: It gets certain inner statistics from Nginx, such as number of active or waiting

connections.

CPU: This plugin gathers information of each CPU core of the platform.

Memory: This collects statistics of the system available Random Access Memory.

47 version 2.5, 28/04/2015


Network: It sends all the gathered metrics of all plugins to a remote collected instance,

used for clustering.

Aggregation: Is a plugin that can be used to post process metrics, for instance, making

an average of CPU metrics across of all platform cores.

Filter: It is used to block or redirect metrics.

Interface: It gathers metrics of all network interfaces of the platform.

See below the configuration of the selected plugins:

# We are collecting metrics in a 2 seconds basis

Interval 2

LoadPlugin cpu

LoadPlugin memory

LoadPlugin df

LoadPlugin aggregation

LoadPlugin interface

LoadPlugin network

LoadPlugin nginx

LoadPluing tail

# Filter configuration

PreCacheChain "PreCache"

PostCacheChain "PostCache"

LoadPlugin match_regex

# We stop from being processed some network metrics, in order to keep only

# transmitted and received octets

<Chain "PreCache">

<Rule "only_if_octets">

<Match "regex">

Plugin "^interface$"

</Match>

<Match "regex">

Type "if_octets"

Invert true

</Match>

Target "stop"

</Rule>

</Chain>

# We process all cpu metrics in order to send them to the aggregation pluing

# and produce new average metrics aggregating the values of every single core

<Chain "PostCache">

<Rule>

<Match "regex">

Plugin "^cpu$"

PluginInstance "^[0-9]+$"

</Match>

<Target write>

Plugin "aggregation"

</Target>

Target "stop"

</Rule>

Target "write"

</Chain>

<Plugin df>

MountPoint "/mnt/nginx"

FSType "tmpfs"

48 version 2.5, 28/04/2015


# We include only percentage metrics

ValuesAbsolute false

ValuesPercentage true

</Plugin>

# We aggregate all cpu metrics and caclculate its average across all cpu cores

<Plugin "aggregation">

<Aggregation>

Plugin "cpu"

PluginInstance "/[0-8]$/"

Type "cpu"

SetPlugin "cpu"

SetPluginInstance "all-%{aggregation}"

GroupBy "Host"

GroupBy "TypeInstance"

CalculateNum false

CalculateSum false

CalculateAverage true

CalculateMinimum false

CalculateMaximum false

CalculateStddev false

</Aggregation>

</Plugin>

# We exclude loopback interface metrics from being reported

<Plugin interface>

Interface "lo"

IgnoreSelected true

</Plugin>

# We will send all metrics to the monitor node

<Plugin network>

# Place here the monitoring server IP

Server "192.168.10.254"

ReportStats false

</Plugin>

# This is the URL to poll some inner nginx metrics

<Plugin nginx>

URL "http://localhost/basic_status"

</Plugin>

# It is parsing line by line the normalized Nginx proxy log

<Plugin tail>

<File "/usr/local/nginx/logs/proxy.access.log">

Instance nginx

#Average upstream response time

<Match>

Regex ".*upstream_response_time.([0-9.]+).*"

DSType "GaugeAverage"

Type "response_time"

Instance "AvgRespTime"

</Match>

#Minimum upstream response time

<Match>


DSType "GaugeMin"


Instance "MinRespTime"

</Match>

#Maximum upstream response time

<Match>


DSType "GaugeMax"

49 version 2.5, 28/04/2015



Instance "MaxRespTime"

</Match>

#Each cache status counters

<Match>

Regex ".*upstream_cache_status.EXPIRED.*"

DSType "CounterInc"

Type "counter"

Instance "CacheExpired"

</Match>

<Match>

Regex ".*upstream_cache_status.HIT.*"

DSType "CounterInc"

Type "counter"

Instance "CacheHit"

</Match>

<Match>

Regex ".*upstream_cache_status.MISS.*"

DSType "CounterInc"

Type "counter"

Instance "CacheMiss"

</Match>

<Match>

Regex ".*upstream_cache_status.BYPASS.*"

DSType "CounterInc"

Type "counter"

Instance "CacheBypass"

</Match>

<Match>

Regex ".*upstream_cache_status.STALE.*"

DSType "CounterInc"

Type "counter"

Instance "CacheStale"

</Match>

<Match>

Regex ".*upstream_cache_status.UPDATING.*"

DSType "CounterInc"

Type "counter"

Instance "CacheUpdating"

</Match>

<Match>

Regex ".*upstream_cache_status.REVALIDATED.*"

DSType "CounterInc"

Type "counter"

Instance "CacheRevalidated"

</Match>

<Match>

Regex ".*"

ExcludeRegex ".*upstream_cache_status.-.*"

DSType "CounterInc"

Type "counter"

Instance "CacheAll"

</Match>

</File>

</Plugin>

12.3. Configuration of the monitoring node

The monitoring node is the responsible to collect all the metrics from the cache nodes, process and store them and provide some near real-time visualization tool for time series. For that purpose the tools used are:

Collectd: This service instance will receive all cache nodes metrics thanks to the

network plugin.

50 version 2.5, 28/04/2015


Riemann: It is an events processor daemon. Riemann is the responsible to process all

the data, trigger alarms and send it to the storage database.

Influx: It is a specialized database optimized for time series.

Grafana: A graph and dashboard builder for visualizing time series metrics.

12.3.1. Collectd configuration

Collectd will act just as the receiving point of the data and metrics produced by the cache Collectd instances and resend them to the Riemann service. See below configuration file:

Interval 2

LoadPlugin network

<Plugin network>

# Accept data form any host

Listen “0.0.0.0”

# Do not report inner network plugin metrics

ReportStat false

</Plugin>

LoadPlugin write_riemann>

# We write data to a local instance of riemann by port 5555

<Plugin write_riemann>

<Node "local">

Host "localhost"

Port 5555

Protocol UDP

StoreRates true

AlwaysAppendDS false

TTLFactor 4.0

</Node>

Tag "cache"

</Plugin>

12.4. Riemann configuration

The configuration file of Riemann is based on Clojure language, so it is more like providing the processing script all events and metrics than providing a concrete set of configuration directives. See below the configuration file:

; -*- mode: clojure; -*-

; vim: filetype=clojure

(logging/init :file "/var/log/riemann/riemann.log")

; Listen on the local interface over TCP (5555), UDP (5555), and websockets

; (5556)

(let [host "127.0.0.1"]

(tcp-server :host host)

(udp-server :host host)

(ws-server :host host))

; Expire old events from the index every 5 seconds.

(periodically-expire 5)

; Influx database connection settings

(def influxdb-baseconfig {:host "localhost"

:port 8086

:username "riemann"

51 version 2.5, 28/04/2015


:password "mysecret"

:db "riemann"

:version :0.9

:series #(str (:host %) "." (:service %))})

; Method to identify NaN values

(defn NaN?

"Test if this number is nan"

[x]

; Nan is the only value for which equality is false

(false? (== x x)))

; Method to make the difference of two events which have the same time value

(defn equaltime_difference [[a b]]

(if (= (:time a) (:time b))

(do (reinject (folds/difference [a b])))))

; Method to make the quotient of two events which have the same time value

(defn equaltime_quotient [[a b]]

(if (= (:time a) (:time b))

(do (reinject (folds/quotient [a b])))))

; Keep events in the index for 1 minutes by default.

(let [index (default :ttl 60 (update-index (index)))]

; Inbound events will be passed to these streams:

(streams

; Sum all received bytes of each host and create a new metric with the

result.

(where (service #"^interface.*if_octets/rx$")

(by :host

(coalesce

(smap folds/sum (with :service "received" (scale (/ 1 1024)

reinject))))))

; Sum all transmitted bytes of each host and create a new metric with the

result.

(where (service #"^.*interface.*if_octets/tx$")

(by :host

(coalesce

(smap folds/sum (with :service "transmitted" (scale (/ 1 1024)

reinject))))))

; Make the difference between total sent and received bytes

(by :host

(project [(service "transmitted") (service "received")]

(with :service "tx_rx_difference" equaltime_difference)))

; Make the ratio of each cache status type with the total cache requests

(by :host

(project [(service "tail-nginx/counter-CacheBypass") (service "tail-

nginx/counter-CacheAll")]

(with :service "cacheBypass" equaltime_quotient)))

(by :host

(project [(service "tail-nginx/counter-CacheStale") (service "tail-


(with :service "cacheStale" equaltime_quotient)))

(by :host

(project [(service "tail-nginx/counter-CacheRevalidated") (service

"tail-nginx/counter-CacheAll")]

(with :service "cacheRevalidated" equaltime_quotient)))

(by :host

52 version 2.5, 28/04/2015


(project [(service "tail-nginx/counter-CacheUpdating") (service "tail-


(with :service "cacheUpdating" equaltime_quotient)))

(by :host

(project [(service "tail-nginx/counter-CacheExpired") (service "tail-


(with :service "cacheExpired" equaltime_quotient)))

(by :host

(project [(service "tail-nginx/counter-CacheHit") (service "tail-


(with :service "cacheHit" equaltime_quotient)))

(by :host

(project [(service "tail-nginx/counter-CacheMiss") (service "tail-


(with :service "cacheMiss" equaltime_quotient)))

; Index all events

(where (service #".*") index)

; Send them to influxdb in packs of 500

(where (not (or (service #"^tail-nginx/counter.*") (nil? metric) (NaN?

metric) (service #"^memory/.*")))

(batch 500 1 (influxdb influxdb-baseconfig)))

(where (service #"^memory/.*")

(scale (/ 1 1024 1024)

(batch 100 1 (influxdb influxdb-baseconfig))))

)

)

; Report when any of the caches stops sending metrics by sending an email

(let [email (mailer {:from "[email protected]"})]

(streams

(expired

(where (or (service "received") (service "transmitted"))

(email "[email protected]")))))

12.5. Influx configuration

Influx daemon is a REST based service, so it can be easily integrated other web services. Influx even not being exactly an SQL database it tries to use the same semantics and syntax so creating the specific database looks like a creating a regular database. From the influx client utility type:

$ CREATE DATABASE riemann

$ CREATE USER riemann WITH PASSWORD 'mysecret'

$ GRANT ALL ON riemann TO riemann

$ CREATE RETENTION POLICY riemann_one_week ON riemann DURATION 1w

REPLICATION 1

12.6. Granfana configuration

Grafana is web application for time series visualitzation. Besides regular configuration issues such administrator user password change and regular user management the only important things to configure are the data sources (Influx database in this case) and the specific plots for the dashboard.

To configure the database access and include it as new data source edit the following information from the web user interface (only accessible as an administrator user). Navigate to Data sources and then to the Add new option and insert the following data inside the form:

53 version 2.5, 28/04/2015


Name: riemann

Type: InfluxDB 0.9.x

Url: http://localhost:8086

Database: riemann

User: riemann

Password: mysecret

Validate the data with the Test Connection button.

Then using the web interface it is possible to create dashboards to plot the desired metrics.

54 version 2.5, 28/04/2015


13. Annex II – Measurement of HbbTV Service Streams

During the evaluation phase of the German pilots, two issues regarding the technical evaluation of the pilots appeared. First of all, it was hard to determine the relevant technical parameters, which could be most meaningful for the evaluation. And secondly, it showed that there is a lack of reliable tools to proof and monitor the applications as required for the project. Also, the tools that do exist, do not provide the right level of information to application providers like broadcasters.

Available tools on the market are mainly designed for web services. There is a range of tools analysing the user behaviour and performance of websites. In addition, there are a few, mostly professional and costly tools for monitoring video streams. Unfortunately, it was found that these tools usually are not reliable enough and do not meet all requirements. This lead to the decision to develop and to implement a concept for the analysis of HbbTV applications during the visitor usage. This concept is based on a player plug-in for HbbTV applications, and includes a data analysis frontend as well as a data storage backend.

This plug-in aims to provide reliable analyses of video distribution through HbbTV. In order to show the possibilities, a prototype within TV-RING was developed. This prototype includes the plug-in as well as the front- and backend.

13.1. Measurement Concept

The tool consists of an HbbTV player plug-in, data analysis frontend and data storage backend as depicted in Image 21.

Image 21: HbbTV service Streams Measurement Concept.

The tool is intended to provide information about user behaviour and to monitor the

quality of video streams on the Internet.

Both, on-demand video and live streams should be supported.

Progressive download and MPEG-DASH should be supported.

The measurement should be platform-independent by using HTTP. The requests should

be triggered from the player at particular events like play, pause, buffering, seek, stop.

Additionally, periodic requests had to be send. If there are no further requests during a

determined timeslot the sessions is ended.

55 version 2.5, 28/04/2015


Timeslots between requests should not be fixed throughout the entire duration. At the

beginning of a play event the intervals should be shorter than during a long run of the

video.

The request should not influence the video quality.

To cover the huge amount of data, big data methods like Apache Hadoop and

MapReduce together with NoSQL databases like MongoDB or Elasticsearch are

required.

The statistics should be offered through a web-frontend. Professional users should be

able to choose between different dimensions and metrics to arrange flexible reports.

13.2. Parameter definition

In the context of TV-RING, basic parameters which are relevant for HbbTV service streams, were collected and discussed by project partners. The list contains the resulted parameters:

Date of the play request Time of the play request Session-ID Visit-ID Request-ID Interval (seconds since the last

request) Title of video clip Series Category Subcategory Broadcaster-ID Hostname Duration of connection Time of start (of play request) Stream length Video size (in Bytes) Video containers (e.g. MPEG-DASH,

MP4) Player status: play, pause, stop,

buffering, seek Current play time Duration (Player in play status)

Current bitrate Pause counter Pause duration Seek position Seek counter Buffer duration Cumulated buffer duration

(buffering time over the whole playback)

Buffer counter Dropped frames IP of Edge-Server Internet Service Provider (ISP) Location of user (country, state,

region) CDN (e.g. Akamai, Level3) Player referrer User agent (e.g. Mozilla/5.0 (X11; Linux i686;

rv:17.0 ) U; HbbTV/1.1.1 (; TOSHIBA; 32SL863; 19.2.39.208; 3; ) ; ToshibaTP/1.1.1 () ; en) OPR/20.0.1387.24)

Player version Browser OS of user OS version

13.3. Transmission of parameters

Based on the specified data to be collected and transmitted from the client to the data storage, an example beacon was designed. In this Beacon, the required values can be saved and transferred. The file format JSON was chosen because it is easy to understand, efficient and widely used as an exchange format on the Internet. To reduce the load on the servers that collect and aggregate the beacons, the information is divided into three blocks with different repetition rates:

56 version 2.5, 28/04/2015


Init Beacon: The Init Beacon contains all required data that is collected from the client

at the beginning of a playback session. The size of the Init Beacon is typically around 850

bytes.

{

"init":

[{

// Visit ID: SHA-1 generated hash from Timestamp:ClientIP

// e.g. "2015-02-26T11:29:21Z:193.96.226.18" -> "66f480954355bb1f48c6e8765ca8d8b2b7037a79"

"vi": "66f480954355bb1f48c6e8765ca8d8b2b7037a79",

// Session ID: SHA-1 generated hash from video-URL:Timestamp:ClientIP

// e.g. "http://akamai-progressive.irt.de/tvring/VuA_Folge_01/mp4/VuA_Folge_01.mp4:2015-02-

26T11:29:21Z:193

"si": "0614eb31e4d2fd6980fa93282fb2f7fa16c3daa6",

// Request ID: continuous number of current request

// Could also be counted on server, but will be transmitted to identify if a request got lost

"ri": 0,

// Video Title

"vt": "VuA_Folge_01.mp4",

...

//Player Version if available

"pv" : "1.2"

}]

}

Follow Beacon: The Follow Beacon contains only data relating to the reproduction of the current stream. It is delivered periodically. The size of the Follow Beacon is around 450 bytes.

{

"follow":

[{


"vi": "66f480954355bb1f48c6e8765ca8d8b2b7037a79",




"ri": 1,

// Video Title


57 version 2.5, 28/04/2015


// Startup Time in Seconcs

"sp": 3,

...

// Dropped Frames

"vdf": 0,

}]

}

End-Beacon: The End Beacon contains the same data as the Init Beacon. It is transmitted only once at the end of the playback. The size of the End Beacon is roughly 450 bytes.

{

"end":

[{


"vi": "66f480954355bb1f48c6e8765ca8d8b2b7037a79",




"ri": 26,

// Video Title


// Videolength in Seconds. VoD only

"vl": 1474,

// Videosize in Bytes. VoD only

"vs": 319458395,

// Series

"s": "Verknallt und Abgedreht",

...

//Player Version if available

"pv" : "1.2"

}]

}

The three types of beacons are sent periodically during playback from client to server as follows:

When the user starts the playback, an Init Beacon is transmitted.

58 version 2.5, 28/04/2015


After 30 seconds a Follow Beacon is sent to the server. This is repeated 3 times as long as nothing else happens.

After the last 30 second period, the next beacons will be sent every 60 seconds. If the playback ends or if the user ends it, an End Beacon is pushed to the server. This

beacons again include the complete parameter set and it signals the server that the playback is over and there will be no further data to this set.

In case the transmission of any beacon fails, the client will send the data again, in order to try to complete the data at the server side.

Image 22: Beacon management.

13.4. Data storage

The Web server infrastructure, which receives the beacons from the clients, must be able to accept a high number of requests and, in a next step, also edit or pass the beacons on. Since the processing of the requests requires very high performance, it is recommended to use an infrastructure that can be dynamically scaled up or expanded at runtime and at the same time is able to go on processing the requests. For this purpose, Node.js could be used.

Node.js works event-based and has a "non-blocking I/O model", which is capable to process a large number of quasi simultaneous requests in a short time. Moreover Node.js is dynamically scalable, which makes it possible to react quickly to major request for example with additional hardware resources.

It is recommended to use a database system like NoSQL or some other document-oriented database. Here again it is required that the system is dynamically scalable in short term to respond to fluctuating load volumes. Database systems such as MongoDB or Elasticsearch are suitable. Both database systems are optimized for interacting with Node.js. Therefore, they are able to manage very large amounts of requests, which are passed on from Node.js. They can receive and process big data accordingly.

The information will also be stored in JSON format exactly as the beacons. This means the data can be efficiently saved almost unmodified in MongoDB or Elasticsearch databases.

13.5. Analysis and statistics

The analysis of the user behaviour and the HbbTV service streams quality should be offered through a web interface. It is required to have the possibility to choose between different dimensions and metrics to arrange flexible reports. Therefore, some representatives from various broadcasters were asked about their requirements regarding such an analysis. Responses included:

Traffic Volume

Number of users

Maximal and average number of concurrently users

Maximal load of data

59 version 2.5, 28/04/2015


Average usage duration

Average bitrate that users are served

Error report

Number of reconnects

Start-up time, average value about the time it took from the request of a clip till the

start

13.6. Prototype

The prototype was developed according to the requirements from the QoS Concept. For a first small test the QoS Plug-in was integrated into the “IRT Reference Clips HbbTV player” (available through hbbtv-developer.com). The QoS plugin is automatically activated in the player. It is initialized with the test case parameters (title, bitrate, category, termId…). When the video starts playing, the plugin analyses the video and sends the different information to the server

The prototype uses Elasticsearch as a database to store the beacon-data. Elasticsearch was chosen, because it offers the possibility to query the stored data very fast. Finding the right data at very low searching times is critical in two situations: First, all data associated with one client-session have to be grouped together. Hence, when a beacon needs to be stored, the associated data has to be found quickly. Secondly, when the data needs to be provided for the web-interface, a quick search is necessary

The web interface is based on modern web-technologies like HTML5, JQuery and the visualization library nvd3.js. Nvd3.js offers the possibility to display data in multiple chart-structures, like bar-charts, multiline-charts or pie-charts. These chart-structures are used in the web-interface to order and display the data intuitively. The link to the website is the following: http://tv-html.irt.de/hbbtv/tv-ring/qos/index.html. The structure of the dimensions and metrics is adapted to the requirements of the German broadcasters. There are three dimension:

General Overview

o Monitoring of the complete data from the repository

o E.g.: Number of successful played videos compared with the number of videos

with errors of all delivered streams at this time period.

Series

o Monitoring of the data from one series


with errors of all episodes from that series „V&A“.

Clip

o Monitoring of the data from one clip


with errors of the episode 1 from the series „V&A“.

http://tv-html.irt.de/hbbtv/tv-ring/qos/index.html

60 version 2.5, 28/04/2015


Image 23: Web-interface structure.

13.6.1. Metrics for „General Overview”

Number successful played streams vs number streams with errors (Bar-chart)

Used data rates (Line-chart)

Average Playback duration (Bar-chart)

Number simultaneously users vs CDN/ISP (Multiline-chart)

Used data rates per CDN/ISP (Multiline-chart)

Errors per CDN/ISP (Bar-chart)

Streaming format (Pie-chart)

HbbTV version (Bar-chart)

Errors Geolocation in Germany (Map-chart)

61 version 2.5, 28/04/2015


Image 24: Example for a “General Overview” diagram.

13.6.2. Metrics for „Series“


Top 10: Number views of the different episodes (Bar-chart)


Average Playback duration (Bar-chart)



Geolocation/geoblocking national/abroad (Map-chart)

Image 25: Example for a “Series” diagram.

13.6.3. Metrics for „Clip“



Average Playback duration, percent of the clip length (Bar-chart)

Number simultaneously users vs CDN/ISP (Multiline-chart)

Used data rates per CDN/ISP (Multiline-chart)


62 version 2.5, 28/04/2015



Geolocation/geoblocking national/abroad (Map-chart)

Image 26: Example for a “Clip” diagram.

Date post:	13-Jun-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

DELIVERABLE - CORDIS...2.5 29/02/2016 David Pujals RTV Fixing Format issues ICT PSP Statement of...

Documents