DELIVERABLE - tvring.eu€¦ · The systems deployed in the three pilots, consist in a content...

1 version 2.2, 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.2

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.

2 version 2.2, 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.

Statement of originality:

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

Disclaimer

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

3 version 2.2, 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.

4 version 2.2, 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]

5 version 2.2, 28/04/2015


Content

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

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

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

3. Table of Figures ...................................................................................................................... 7

4. Introduction ........................................................................................................................... 8

5. Generic backend platform structure ..................................................................................... 9

5.1. Pilot platform diagram ................................................................................................ 10

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

5.3. Specific pilot design architecture ................................................................................ 13

5.3.1. Dutch Pilot ........................................................................................................... 13

5.3.2. German Pilot ....................................................................................................... 14

5.3.3. Spanish Pilot ........................................................................................................ 14

6. Application server ................................................................................................................ 18

6.1. Dutch Pilot ................................................................................................................... 18

6.1.1. Application hosting.............................................................................................. 18

6.1.2. Second screen application deployment .............................................................. 19

6.2. German Pilot ............................................................................................................... 19

6.2.1. Application Storage ............................................................................................. 19

6.2.2. Application deployment ...................................................................................... 19

6.3. Spanish Pilot ................................................................................................................ 20

6.3.1. Application Storage ............................................................................................. 20

6.3.2. Application deployment ...................................................................................... 21

6.3.3. Second-screen synchronisation mechanism ....................................................... 21

7. Content Storage ................................................................................................................... 23

7.1. Dutch Pilot ................................................................................................................... 23

7.1.1. Web content ........................................................................................................ 23

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

7.2. German Pilot ............................................................................................................... 23

7.2.1. Web Content ....................................................................................................... 24


7.3. Spanish Pilot ................................................................................................................ 25


7.3.2. Live services ......................................................................................................... 26

8. Content Delivery .................................................................................................................. 28

6 version 2.2, 28/04/2015


8.1. Dutch Pilot ................................................................................................................... 28

8.1.1. Content Delivery Network ................................................................................... 28

8.2. German Pilot ............................................................................................................... 29

8.2.1. Streaming content ............................................................................................... 29

8.2.2. Delivery Network ................................................................................................. 30

8.3. Spanish Pilot ................................................................................................................ 31

8.3.1. Streaming content ............................................................................................... 31

8.3.2. Delivery Network ................................................................................................. 34

9. Demonstrations system setup ............................................................................................. 39

9.1. NPO Demonstration setup .......................................................................................... 39

9.1.1. Recommender and DRM demo ........................................................................... 39

9.1.2. NPO Second screen ............................................................................................. 39

9.2. German Pilot ............................................................................................................... 39

9.3. Spanish pilot Demonstration setup ............................................................................. 40

9.3.1. RF Channel simulation ......................................................................................... 41

9.3.2. Receivers testing ................................................................................................. 43

10. Glosary ............................................................................................................................. 45

11. Bibliography & References .............................................................................................. 46

7 version 2.2, 28/04/2015


3. Table of Figures

Figure 1. System data flow. ........................................................................................................... 9

Figure 2. High Level system diagram .......................................................................................... 12

Figure 3. Spanish pilot content generation and flow scheme..................................................... 15

Figure 4: Backend structure of Spanish TV-Ring project, including network overview. ............. 16

Figure 5. App hosting architecture. ............................................................................................. 18

Figure 6: XML file of launcher bar widget ................................................................................... 20

Figure 7: HbbTV launcher bar including German pilot widget on the left (“verknallt &

abgedreht”, the actual program title. ......................................................................................... 20

Figure 8. Tablet is synchronized with the TV through Firebase using web sockets. ................... 22

Figure 9. Video storage and delivery within the German pilot ................................................... 24

Figure 10. Akamai CDN Content Storage .................................................................................... 25

Figure 11 Live services diagram .................................................................................................. 27

Figure 12. Example of an MPD file used in the German pilot. .................................................... 30

Figure 13: Akamai CDN Edge Server arrangement ..................................................................... 31

Figure 14. Local CDN block diagram. ........................................................................................... 35

Figure 15: Worldwide Level3 CDN nodes interconnection. ........................................................ 35

Figure 16: TV-Ring global CDN network configuration diagram. ................................................ 37

Figure 17: Demonstration setup scheme. ................................................................................... 40

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

Figure 19: Portable low power DVB Modulator ......................................................................... 42

Figure 20. Receivers testing results table ................................................................................... 43

Figure 21: The first of the brand new VESTEL TV sets deployed in the village of Gurb. ............. 44

8 version 2.2, 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.

9 version 2.2, 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.

Figure 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.

10 version 2.2, 28/04/2015


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 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.

11 version 2.2, 28/04/2015


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 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.

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

12 version 2.2, 28/04/2015


Figure 2. High Level system diagram

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.

13 version 2.2, 28/04/2015


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:

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.

14 version 2.2, 28/04/2015


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 :

- 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.

15 version 2.2, 28/04/2015


Figure 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/

16 version 2.2, 28/04/2015


Figure 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

17 version 2.2, 28/04/2015


performance distribution is the communications network among the CDN nodes. Level3 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.

18 version 2.2, 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.

Figure 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.

19 version 2.2, 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:

20 version 2.2, 28/04/2015


Figure 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”.

Figure 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.

21 version 2.2, 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/

22 version 2.2, 28/04/2015


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

23 version 2.2, 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 ¡Error! No se encuentra el origen de la referencia..

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 servers to customers who want their content distributed faster to the user. There are 170 000 Akamai edge

Akamai edge servers in 102 countries which are responsible for 15-30% of the worldwide Internet traffic. Within Internet traffic. Within the German pilot, the Akamai CDN was just used for video content storage and delivery,

storage and delivery, as it is shown in

Figure 10. Akamai CDN Content Storage

below.

24 version 2.2, 28/04/2015


25 version 2.2, 28/04/2015


Figure 9. Video storage and delivery within the German pilot

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.

26 version 2.2, 28/04/2015


Figure 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/

27 version 2.2, 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.

28 version 2.2, 28/04/2015


Figure 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.

29 version 2.2, 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:

30 version 2.2, 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

31 version 2.2, 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>

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

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

32 version 2.2, 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.

Figure 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/

33 version 2.2, 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:

34 version 2.2, 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.

35 version 2.2, 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

36 version 2.2, 28/04/2015


Figure 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.

Figure 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.

37 version 2.2, 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:

38 version 2.2, 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.

Figure 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/





39 version 2.2, 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

40 version 2.2, 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.

41 version 2.2, 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.

Figure 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.

42 version 2.2, 28/04/2015


This URL is embedded in the AIT (Application Information Table) table within the DVB conformed file.

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.

43 version 2.2, 28/04/2015


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

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.

Figure 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.

44 version 2.2, 28/04/2015


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.

Figure 20. Receivers testing results table

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.

45 version 2.2, 28/04/2015


Figure 21: The first of the brand new VESTEL TV sets deployed in the village of Gurb.

46 version 2.2, 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.

47 version 2.2, 28/04/2015


11. Bibliography & 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.

DELIVERABLE - tvring.eu€¦ · The systems deployed in the three pilots, consist in a content...

Documents

Transcript of DELIVERABLE - tvring.eu€¦ · The systems deployed in the three pilots, consist in a content...