UPTEC IT 13 001

Examensarbete 30 hp Februari 2013

Event-driven interactivity in application-based TV-programs Per Moberg

Abstract Event-driven interactivity in application-based TV-programs Per Moberg

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00

In recent years TVs and set-top boxes has been featured with built-in internet connectivity which open up doors to new innovations and technologies. This research has particularly investigated the possibility of adding event-based interactivity into application based TV-programs and has focused on the hybrid standard HbbTV. A design suggestion of a framework to make use of eventdriven interactivity has been created and a proof-of-concept prototype has been implemented. The study has demonstrated that event-driven interactivity can to advantage be used to enhance the user experience of TV-programs, especially in a live context with many concurrent viewers. HbbTV has been shown to be a suitable standard for connected TV devices and is currently growing in the European TV market.

Hemsida: http://www.teknat.uu.se/student

Handledare: Johan Pettersson Ämnesgranskare: Justin Pearson Examinator: Lars-Åke Nordén ISSN: 1401-5749, UPTEC IT13 001 Sponsor: Accedo Broadband Tryckt av: ITC

0.1

Sammanfattning

TV-industrin ¨ ar inne i ett sp¨annande skede d¨ar fler och fler TV-enheter blir uppkopplade mot internet och nya tj¨anster s˚ a som applikationsportaler, VideoOn-Demand(Vod), IPTV och Pay-per-View utvecklas i snabb takt. Tack vare internet finns nu ¨ aven stor m¨ojlighet f¨or ¨okad interaktivitet med TV-tj¨anster som inte varit m¨ ojlig p˚ a samma s¨att genom vanliga digitala TV-n¨atet. Termen interaktiv TV ¨ ar inte n˚ agot nytt. Redan under senare delen av 50talet s¨ ande CBS-television ett barnprogram vid namn ”Winky Dink and you” d¨ ar tittarna skulle s¨ atta p˚ a en speciell plastfilm p˚ a TV-sk¨armen och rita teckningar f¨ or att hj¨ alpa Winky l¨osa problem. Programmet ¨overlevde dock inte men var en start p˚ a nya innovationer inom omr˚ adet. Exempel p˚ a interaktiva TV-tj¨ anster som har ¨ overlevt genom ˚ aren ¨ar bland annat telefonsamtal under direkts¨ andingar och text-tv. Syftet med rapporten ¨ ar att unders¨oka m¨ojligheten f¨or eventbaserad interaktion under applikationsbaserade TV-program. F¨or att kunna ge ett proof-ofconcept har en prototyp till ramverk implementerats som kan hantera just detta. Beroende p˚ a vilken typ av program som visas kan event vara av olika typer. De typer som har implementerats i prototypen ¨ar fr˚ ageevent, statistikevent och reklamevent. F¨ or att kunna testa och implementera ett ramverk har olika plattformer och standarder unders¨ okts. MHP, MHEG och HbbTV blev utvalda att granskas noggrannare. Den valda standarden blev HbbTV vilket ¨ar en s˚ akallad hybridplattform som kan ta emot inneh˚ all fr˚ an kabel-, luftburen- och satellits¨andningar men ¨ aven genom internetbaserade l¨osningar s˚ a som IPTV och WebTV. HbbTV valdes eftersom det ¨ ar en lovande och v¨al etablerad standard i Europa som har st¨ od p˚ a m˚ anga olika plattformar. HbbTV ¨ar ¨aven baserad p˚ a redan existerande standarder och webbteknologier vilket kan snabba p˚ a utvecklingsprocessen av applikationer. Baserat p˚ a litteraturstudien och den f¨ardiga prototypen ¨ar m¨ojligheterna att l¨ agga till interaktiva event under TV-program mycket goda. Tack vare uppkopplingen mot internet finns det redan m˚ anga v¨al etablerade webbteknologier tillg¨ angliga och en stor m¨angd redan existerande data som kan anv¨andas f¨ or att g¨ ora TV-program mer dynamiska och interaktiva. Eftersom HbbTVapplikationer mer eller mindre utvecklas som vanliga webbsidor finns redan en stor kompetens vilket kan reducera utvecklingstid och kostnader. Viktiga krav p˚ a ett system med m˚ anga samtidiga anv¨andare ¨ar att det ¨ar snabbt och skalbart samt minimerar m¨angden data som skickas mellan klienter och servern. Som exempel har studien visat att en dokumentdatabas s˚ a som mongoDB ¨ ar mer l¨ amplig ¨ an en relationsdatabas s˚ a som MySQL eftersom en dokumentdatabas ¨ ar mer skalbar och kan h¨amta databasposter snabbare. Nackdelen ar att mer ansvar l¨ ¨ aggs p˚ a systemutvecklaren som m˚ aste t¨anka p˚ a att de klassiska ACID villkoren inte uppfylls i en dokumentdatabas. 1

Studien har ¨ aven p˚ avisat att WebSockets ¨ar att f¨oredra som push-teknologi j¨ amf¨ ort med long-polling och polling. Alla HbbTV-enheter st¨odjer dock inte WebSockets s˚ a en elegant l¨osning p˚ a det problemet ¨ar att prim¨art anv¨anda WebSockets och nedgradera till long-polling d˚ a st¨odet saknas. I framtiden ligger sv˚ arigheten i att ¨overtyga inneh˚ allsleverant¨orer att l¨agga till mer interaktivt inneh˚ all i sina s¨andningar. Det ¨ar ett krav eftersom de ¨ager alla r¨ attigheter till det som visas p˚ a s¨andningen inklusive eventuella interaktiva events. Den andra sv˚ ara uppgiften ¨ar att ¨overtyga anv¨andare att faktiskt vilja anv¨ anda och svara p˚ a genererade events. Den f¨ ardiga prototypen har testats p˚ a en HbbTV-kompatibel set-top box. Det implementerade ramverket har integrerats med en simpel HbbTV applikation som visar statiska mp4-str¨ ommar och en live HLS-str¨om. Prototypen fungerar som v¨ antat och illustrerar hur eventbaserad interaktion kan se ut.

2

Contents 0.1 0.2

Sammanfattning . . . . . . . . . . . . . . . . . . . . . . . . . . . Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 5

1 Introduction 1.1 Background . . . . . . . . . . . . . . . . . . . . . . 1.2 Problem formulation . . . . . . . . . . . . . . . . . 1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . 1.4 Constraints . . . . . . . . . . . . . . . . . . . . . . 1.5 Previous research . . . . . . . . . . . . . . . . . . . 1.5.1 Event-driven interactivity in IPTV . . . . . 1.5.2 Hybrid Broadcast Broadband TV (HbbTV)

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

7 7 9 10 11 11 12 12

2 Method 2.1 Pre-study . . . . . . . . . . . . . . . . . . . 2.2 Performance Tests . . . . . . . . . . . . . . 2.2.1 MongoDB vs MySQL . . . . . . . . 2.2.2 WebSockets vs Long-polling . . . . . 2.3 Development method . . . . . . . . . . . . . 2.4 Use cases . . . . . . . . . . . . . . . . . . . 2.4.1 Use case 1 - live entertainment show 2.4.2 Use case 2 - non-live movie . . . . . 2.4.3 Use case 3 - live debate . . . . . . . 2.5 Chapter summary . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

13 13 14 14 14 15 15 15 16 16 17

3 Theory 3.1 Internet technologies . . . 3.1.1 JavaScript . . . . . 3.1.2 AJAX . . . . . . . 3.1.3 JSON . . . . . . . 3.1.4 Push technologies . 3.2 DVB technologies . . . . . 3.2.1 DVB . . . . . . . . 3.2.2 DSM-CC . . . . . 3.2.3 Stream-events . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

18 18 18 18 19 19 20 20 21 21

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

3

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

3.3

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

22 22 23 24 24 24 25

4 Resulting prototype and discussion 4.1 Chosen standard . . . . . . . . . . 4.2 Final Design . . . . . . . . . . . . 4.3 Management Portal . . . . . . . . 4.4 Server . . . . . . . . . . . . . . . . 4.5 Database . . . . . . . . . . . . . . 4.6 Push Server . . . . . . . . . . . . . 4.7 Client . . . . . . . . . . . . . . . . 4.7.1 Client framework . . . . . . 4.8 Event delivery . . . . . . . . . . . . 4.8.1 Event format . . . . . . . . 4.8.2 Events in a non-live context 4.8.3 Events in a live context . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

26 26 27 28 30 30 32 35 37 38 38 39 39

5 Conclusions, Future work and Improvements 5.1 Conclusions . . . . . . . . . . . . . . . . . . . . 5.2 Improvements . . . . . . . . . . . . . . . . . . . 5.2.1 Graphical improvements . . . . . . . . . 5.2.2 Optimizations . . . . . . . . . . . . . . . 5.3 Future work . . . . . . . . . . . . . . . . . . . . 5.3.1 Receive real video content . . . . . . . . 5.3.2 Customized push server . . . . . . . . . 5.3.3 Events through broadcast stream . . . . 5.3.4 Events on secondary screen . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

40 40 41 41 41 42 42 42 42 42

3.4

Considered Hybrid Standards 3.3.1 HbbTV . . . . . . . . 3.3.2 MHEG-5 . . . . . . . 3.3.3 MHP . . . . . . . . . Considered databases . . . . . 3.4.1 SQL . . . . . . . . . . 3.4.2 NoSQL . . . . . . . .

. . . . . . .

. . . . . . .

Appendix A Software and Hardware 46 A.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 A.2 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4

0.2

Abbreviations

ACID

Atomicity, Consistency, Isolation, Durability

AJAX

Asynchronous JavaScript and XML

CEA

Consumer Electronics Association

CE

Consumer Electronics

CSS

Cascading Style Sheets

DOM

Document Object Model

DRM

Digital Rights Management

DVB

Digital Video Broadcasting

ETSI

European Telecommunications Standards Institute

HbbTV

Hybrid Broadcast Broadband Television

HTML

HyperText Markup Language

HTTP

HyperText Transfer Protocol

IPTV

Internet Protocol Television

ISO

International Organization for Standardization

JSON

JavaScript Object Notation

MHEG

Multimedia and Hypermedia Expert Group

MHP

Multimedia Home Platform

MPEG

Moving Picture Experts Group

OIPF

Open IPTV Forum

PPV

Pay-per-view

PVR

Personal Video Recorder

RDBMS Relational Database Management System SMS

Short Message Service

STB

Set-Top Box

SQL

Structured Query Language

TSP

Transport Service Provider

TV

Television

VHS

Video Home System

VoD

Video on Demand

5

W3C

World Wide Web Consortium

6

Chapter 1

Introduction In this chapter the context, in which this thesis is carried out, is explained. The main problem, and why this problem is of interest is also addressed. The last part of this chapter is explaining constraints of this paper and gives a short summary of previous research which is of relevance for this thesis.

1.1

Background

The television industry is in an exciting phase where new technologies and innovations are developed rapidly. The linear television is on its way to become a full interactive entertainment machine and will in similarity with smartphones be customizable with applications from various kinds of application-stores. These kind of features are now possible due to the fact that almost all new television devices have built-in internet connectivity. Informa1 , which is one of the leading providers of business information and services, predicts that connected TV devices will be one of the most fast-selling type of consumer electronics production in history. According to Informa there will be more than 1.8 billion TV devices with in-built internet connectivity in use in over 570 million homes by the end of 2016[1]. A more detailed graph of Informa’s forecast can be seen in figure 1.1. A huge benefit with internet is that it has a two-way-communication by definition which can be used to enhance user interaction with the television set. The term interactive TV is not something new. In the late 1950s CBS television network broadcasted a children program named “Winky Dink And You” where viewers were suppose to attach a special plastic film on the television screen and do drawings to help Winky Dink solve problems. The series did not 1 www.informatandm.com

7

Figure 1.1: Predicted amount of connected-TV devices globally during the period 20112016[1]

survive but it was an eye opener for new innovations[9]. Many attempts to introduce interactive elements in TV-programs has been done since then, but most have been discarded due to high costs. Some have however survived. Phone calls during TV-programs have been around since 1959 and the teletext technology2 , presented by a group of engineers from BBC in 1970, are still present today[20]. During the 21st century, interactive TV has evolved drastically. Users are now able to watch TV programs anywhere and anytime using Video-on-Demand (VoD) services and purchase content such as movies and applications directly with their remote control. Viewers are also able to control the TV with gesture and voice commands and the use of a second screen such as a phone or laptop are more commonly used to enhance the TV experience. User interaction during application based TV-programs is one area that has not got that much attention. Viewers basically watch videos streamed from a server and are only able to manipulate the video with commands such as pause, stop and play. One idea to improvement is to make TV-programs more interactive by enabling two-way-communication, which now is possible due to the availability of an internet connection. Event-driven interactivity is a good way to structure the interaction and depending on the content of a video, different types of events could be thrown. Accedo believe that these kinds of features will be present in a near future and 2 http://en.wikipedia.org/wiki/Teletext

8

want’s to investigate the possibility of creating a framework available for developers to make use of interactive events during application based TV-programs. The design suggestion should include some way to manage and generate events for a content provider, some way to synchronize events with what the viewers are watching at the moment and some way to handle and process user responses. How this is done practically is not known at the time of this writing.

1.2

Problem formulation

The main problem is to investigate the possibility of event-driven interactivity during application-based TV programs and with the assumption that it is possible also give a design suggestion and implement a proof-of-concept prototype. The framework should be able to handle both a live and non-live context, where live is when many viewers watch the same program and non-live is when a viewer alone watch a static video. To be able to do the investigation a suitable target platform or standard needs to be chosen since a platform independent solution is much harder or even impossible to achieve. Depending on the content of a TV program events can be of different types. This research will focus on the following event types: ˆ Questions ˆ Betting ˆ Statistics ˆ Information ˆ Advertising(video/images)

By discussions with employees at Accedo and an initial investigation, a set of interesting issues were created. Some of the more important issues discussed in the final result are: ˆ How to manage and generate events for a content provider? ˆ How to synchronize these events with what viewers are watching? ˆ Conclude how event generation will differ in a live or non-live context? ˆ Which data format events should have? ˆ Over which transmission media events should be sent over? ˆ How user responses should be processed and stored?

9

ˆ Which type of database to use?

For an overview of the problem formulation see figure 1.2.

Figure 1.2: Overview of problem formulation. Need a way to manage events, synchronize events, handle events in a live and non-live context, detect events and handle user responses.

1.3

Purpose

Accedo is the market leading enabler of next generation TV application solutions. With a high probability, television interaction during application-based TV programs will be an expected feature of modern television sets and possible solutions needs to investigated and evaluated. With an easy-to-use framework available for developers to use would really simplify application development and also convince content providers to add more interactive content into their broadcasts. A good application where event-driven interaction could enhance the TV experience is for example to replace phone and SMS voting during entertainment shows by a simple multiple answer question event which a viewer can respond to with their remote control. Another good example is quiz programs such as “Who wants to be a millionaire”3 where a viewer could be able to answer the same questions as the competitor and also see statistics of how good you are compared to other viewers. In live political debates viewers could be able to 3 http://en.wikipedia.org/wiki/Who

Wants to Be a Millionaire

10

answer questions which is furthered discussed in the TV show. This type of interaction would really change the whole user experience and the same concept can be used on several types of programs. Event-driven interactivity can also be used to show different types of advertising and simplify betting by just using your remote control.

1.4

Constraints

With the business environment that prevails with the spirit of high competition, only a limited amount of standards exists and almost each CE manufacturer has its own platform to execute TV applications. To give a proposal that works on all devices at once is more or less impossible. One part of this thesis is to find and use a suitable standard, preferable one that is platform independent and works with a larger group of TV devices. The framework is then designed and implemented with respect to the chosen standard. Also notice that this research is a smaller research to investigate the possibility of event-based interactivity during application-based TV shows and the proposed design and implemented proof-of-concept prototype is just a suggestion. Several experts could work for years to create the perfect solution and for a single person with a limited amount of time to create such a system is just not reasonable. Visual presentation is also outside the scope of this paper. A management portal and a example application will however be implemented but the focus will be on functionality, not graphical presentation. There also exists a huge amount of different TV programs and therefore also a high amount of different types of events that could be generated. To limit this research, only a few use cases is being investigated and the events generated from the prototype is being based on these.

1.5

Previous research

In recent years there has been a limited amount of published research papers about interactive television. This is probably because the hard competition with internal researches not published to a public audience. Of the existing papers mostly are about on how to interact with the TV using speech and your body and also how a second screen such as a phone or laptop could be integrated to enhance the TV experience. Two articles that has been of interest for this paper are summarized in section 1.5.1 and 1.5.2.

11

1.5.1

Event-driven interactivity in IPTV

In 2011 Fredrik H¨ oglin[2] investigated the possibility of event driven interactivity during live sport. The main idea was that it should be possible to watch several live football games in parallel in the sense that a user should receive notifications when something interesting happened in another football game. A limited proof-of-concept prototype with manual event generation was implemented and it showed that this kind of feature have great potential. The paper also makes aware of the lack of standards which makes the development process hard with these kinds of applications. On top of that the implemented prototype was specific to TeliaSoneras IPTV platform. These kinds of applications would clearly benefit from a standard framework.

1.5.2

Hybrid Broadcast Broadband TV (HbbTV)

In 2012 Christoffer Hirsimaa[5] investigated the new standard called HbbTV as a future standard for connected TV devices. HbbTV tries to harmonize broadcast, IPTV and broadband delivered content into one user interface. HbbTV applications are mostly built with regular web technologies, in order to reduce learning times for new HbbTV develpers. During the investigation minor flaws was found such as lack of cookies and DRM support, but these features has been updated in later realeases of the standard. Hirsimaa concludes that the standard has great potential and he recommend it as a future standard for connected TV devices.

12

Chapter 2

Method In this chapter the methods used to produce this paper is explained. First some detailes about the pre-study is presented followed by a description of executed performance tests. After that the development method used to implement the prototype is being discussed and at the end of this chapter a set of use cases is being presented to easier understand what the final product should be able to do.

2.1

Pre-study

The first part of the thesis was to find and read appropriate literature to investigate possible solutions to a interactive framework and later be able to design and implement a prototype. Literature was collected from various article databases and online pages. Online content was needed due to the fast changing market. News and official homepages is a good way to be kept updated. Each paper fell into one of the following categories: ˆ Topic overview - General knowledge about the topic. ˆ Similar work - Avoid redundant work and to get inspiration. ˆ Choice of platform - To be able to choose a platform or standard. ˆ Framework design - Methods and technologies used in the prototype.

13

2.2

Performance Tests

The database could be a potential bottleneck in a system where clients, in the scale of millions, frequently read records from it. Document databases and relational databases are frequently used at Accedo and to be able to choose the most suitable database, a performance application has been implemented. Read more about SQL and relational databases in section 3.4.1 and more about NoSQL and document databases in section 3.4.2. Details about the test application can be seen in section 2.2.1. One important problem described in section 3.1.4 is how to send events from server side to clients in real-time without too much latency. Typically some kind of push technology is used to achieve this kind of behaviour and two of the most common techniques are long-polling and webSockets. A test application has been implemented to compare latencies between these two techniques and more about the test application can be read about in section 2.2.2.

2.2.1

MongoDB vs MySQL

To be able to choose a suitable database to the implemented framework a test application has been implemented. The test application did compare performance attributes between the document-based database MongoDB and the relational database MySQL. The application did measure the time it takes to save, find and delete a certain number of database records. The test application has been executed with different number of database records and each test has been executes several times to get better accurancy. The size of both the databases was also noted throughout the tests. The same Java object was used to be stored in both of the databases. The external frameworks mongoTemplate and Hibernate was used to map the java object into the database respectively.

2.2.2

WebSockets vs Long-polling

A test application has been implemented to compare the time it takes to send a message from a server to a certain number of clients using WebSockets and long-polling. The server and the clients all existed on the same machine and the system clock was used to take time stamps. The test has been executed with different numbers of clients and the lowest, avarage and greatest latency has been documented. The test was only done in a small scale since a single browser only have a limited amount of persistent-http-connections which is needed to establish a long-polling request.

14

2.3

Development method

This thesis was done at Accedos premises in Stockholm. A variation of software programs and hardwares has been used in the development and a detailed list with versions can bee seen in appendix A. To illustrate how event-driven interaction could be presented a prototype has been implemented. The prototype design was based on the literature study and results from the performance tests. The resulting discussion is based on the prestudy and from observations of the final prototype. The implementation has been done with agile methods focusing on working code. The development process started with a simple solution with limited functionality and new features was added over time. By doing this the requirements could easily be changed throughout the project.

2.4

Use cases

There are a huge number of different events due to the variation of TV programs. To limit this research only three use cases has been evaluated and demonstrated using the prototype. Use cases is a good way to describe what the final product should be able to do.

2.4.1

Use case 1 - live entertainment show

An entertainment show in a live context could take good advantage of interactive events. A common theme of such shows is that there are a group of contenders that is competing for a price. A common scenario is that a competitor is doing his/her routine and here is an excellent time to send information events about the competitor and a question event to get the viewers thoughts about the routine. Another common scenario is that there is a live-voting part at the end of the show and a multiple answer question event could be more convenient compared to regular phone and SMS voting. 1. User starts watching the entertainment show Let’s Dance. 2. At the introduction of Magnus Samuelsson an informative event arrives with content: ’did you know that Magnus...’. 3. User closes event or it disappears after a while. 4. After Magnus routine an question event about what viewers thought about Magnus performance arrives. 5. User chooses one of the alternatives.

15

6. Another event arrives with statistics from the previous asked question. 7. Statistics window closes after a couple of seconds. 8. ... 9. At the end of the show an multiple-answer-question event arrives with all the participants as alternatives. 10. User chooses his favorite competitor. 11. Final result is presented during the live show.

2.4.2

Use case 2 - non-live movie

A movie in a non-live context watched from a video-on-demand service is another example application. Advertising events could be appropriate if it is free to watch the movie. At the end of the movie a question event about your thoughts about the movie could be generated and after that let you know what other viewers thought about the movie. 1. User starts watching a video-on-demand movie. 2. An advertising event arrives. 3. Event window closes after a couple of seconds. 4. At the end of the movie a question event about what you thought about the movie arrives. 5. User chooses one of the alternatives. 6. Another event with statistics from previous question arrives. 7. Movie finishes.

2.4.3

Use case 3 - live debate

A live debate in politics is an example where a viewer could interact with the program. Depending on what subjects are discussed, multiple answer questions could be asked to the viewers and results and statistics could be further discussed in the live debate. 1. User starts watching live debate. 2. A multiple-answer-question event arrives

16

3. User selects one of the options. 4. Result of what other viewer voted is presented. 5. The result is furthered discussed in the live debate.

2.5

Chapter summary

This chapter has described methods used to investigate the possibility of eventdriven interaction during TV shows. Next chapter is presenting theory needed to understand the results in chapter 4.

17

Chapter 3

Theory In this chapter, the theory needed to understand the result in chapter 4 is presented. Depending on knowledge of the reader this chapter may be read as needed. Internet specific and DVB specific technologies used to send events to a connected TV device is explained in the first half of this chapter. Considered standards and databases is explained at the second half of this chapter.

3.1

Internet technologies

This section is giving an introduction to web technologies used to send events using the internet protocol.

3.1.1

JavaScript

Javascript is a scripting language commonly used as a part of a web-browser to be able to create more dynamic webpages. Since the JavaScript engine is located at the client side of a web page it can respond to user interaction rapidly increasing responsiveness[8]. JavaScript is often used to communicate with servers using HTTP requests.

3.1.2

AJAX

AJAX (Asynchronous JavaScript and XML) is a generic name for web technologies used to create asynchronous web applications which are able to communicate with servers without changing the state of a web page. CSS is used to style data, DOM is used to interact with information on the page, XMLHttpRequests

18

provides data exchange between the browser and a server and Javascript is the language that bring all these technologies together.

3.1.3

JSON

JSON (JavaScript Object Notation) is a lightweight data format which is easy to read and write both for humans and machines. The JSON format is language independent and there are parsers to most of the well known languages and is widely used to interchange data between network applications. JSON uses a collection of name/value pairs to describe a single object and it uses brackets to represent ordered lists of values such as arrays. An example is listed in figure 3.1. 1 2 3 4 5 6 7

{ " _id " " type " " time " " question " " answers "

: : : : :

" 508 a 8 a b 4 6 8 0 7 1 4 f 3 e 4 6 7 8 c c 9 " , 2, 100 , " Did you like this episode ? " , [ " Yes " ," No " ]

}

Figure 3.1: An example of a JSON object.

3.1.4

Push technologies

The HTTP protocol is normally used in web communication where a client requests for content from a server and the server acknowledge this request and sends back a response. This type of communication is applicable when the runtime behavior is known which normally is the case of web pages. A problem will however arise when the server wants to send messages to the client asynchronously without the clients knowledge. Push messages is a common expression for this type of communication and typically uses different types of polling techniques to simulate this behavior. This section is explaining a selection of alternatives to send messages from a server to a client asynchronously. Polling Polling in a web context is a technology where a client request for information from a server at regular time intervals using the HTTP protocol. This technique is easy to implement and can be used to detect if an event has occurred by frequently asking the server. Since most of the responses will be empty a lot of unnecessary network traffic and server CPU consumption is being generated, heavily reducing the scalability of the system.

19

Long-Polling Long polling is a technology very similar to regular polling. The difference is that instead of responding with an empty request when nothing new has happened, the connection is hold open until new information arrives or a connection timeout occurs. By doing this the amount of network traffic used can be reduced, making the system more scalable compared to regular polling[28]. Websockets WebSockets is a fairly new protocol enabling a full duplex two-way-communication using one single TCP connection. WebSockets is an important part of the HTML5 initiative and is a good alternative for bi-directional communication compared to solutions using the HTTP protocol such as polling and long polling. The WebSocket protocol is an independent TCP-based protocol and its only relation to the HTTP protocol is the initial handshake between two nodes. The handshake will upgrade the connection to make use of the WebSocket protocol. The WebSocket protocol is design fit into web development and have much less header overhead compared to a HTTP requests reducing network traffic and latency[27]. The main disadvantage with WebSockets is that the browser in use need to have HTML5 support.

3.2

DVB technologies

This section is giving an introduction to DVB technologies used to send events through a broadcast channel.

3.2.1

DVB

“The Digital Video Broadcasting Project (DVB) is an industry-led consortium of over 200 broadcasters, manufacturers, network operators, software developers, regulatory bodies and others in over 35 countries committed to designing open technical standards for the global delivery of digital television and data services”[10]. In 1991, a group containing of broadcasters, CE manufacturers and regulatory bodies in Europe formed a group that would monitor the introduction of digital TV, and this became the foundation of the DVB project. The first phase was to establish standards for delivery of digital TV content and the three main standards produced were DVB-S for satellite networks, DVB-C for cable networks and DVB-T for terrestrial networks. These standards mainly describe

20

the technical aspect of digital TV delivery including the physical layer and data link layer of the distribution system. Over the years many standards have been published including DVB-H for handheld mobile devices and upgraded versions of DVB-S, DVB-C and DVB-T for high definition content[10].

3.2.2

DSM-CC

Digital storage media command and control(DSM-CC) is used to deliver applications through a broadcast stream. DSM-CC is a standard[25] for data transmission over MPEG-1 and MPEG-2 streams and use a so called ”Object carousel” to merge application data into the broadcast stream. Clients cannot request for data as in internet communication and instead have to wait until a requested object is transmitted in the stream. The time interval until a DSMCC object is transmitted again depends on the size of a DSM-CC object and the bandwidth allocated for it. For an overview see the ”Application” section in figure 3.2.

Figure 3.2: General concept of merging applications and external data into a broadcast stream[5].

3.2.3

Stream-events

Broadcasters are able to send stream events through a broadcast stream which can be used to send interactive events. A stream event is a package containing information about itself and some payload with a maximum size of 256 bytes[5]. 21

Since digital broadcasting is not totally reliable, stream events typically is sent several times to guarantee arrival. If a TV device detects the same event more than once it simply rejects it. To be able to detect stream events, information about expected events must be registered in the client application and a JavaScript listener must be declared. Information about expected stream events can be provided in two ways. Either the DSM-CC object contains information about expected requests or an external Application Information Table (AIT) XML file is provided. The AIT XML is typically used when an application does not have an DSM-CC object and is received from other resources[5]. Stream events and the AIT XML file is part of the ”Other broadcast information” in figure 3.2.

3.3

Considered Hybrid Standards

3.3.1

HbbTV

“HbbTV, which stands for Hybrid broadcast Broadband TV, is an industry standard platform for signaling, transport, and presentation of enhanced and interactive application design for running on hybrid terminals that include both a DVB compliant broadcast connection and a broadband connection to the Internet”[13] HbbTV is an open standard, approved and published by ETSI, providing an alternative to proprietary TV technologies for broadcasters to deliver interactive services to a customer. HbbTV aims to unite broadcast TV, IPTV and broadband services using one single user interface. HbbTV compatible devices are able to operate over a normal internet connection and different broadcasting technologies including satellite, cable and terrestrial networks[14]. The HbbTV standard is based on existing standards and web technologies including OIPF1 , CEA2 , DVB3 and W3C4 , see figure 3.3. By using well known technologies the development time and cost could possible be reduced since a lot of competence already exists. The HbbTV standard is making its way through Europe and countries including Germany, France, Spain, Holland among other has already adopted to use HbbTV as standard for connected TVs. The forcast is that more european countries will follow and HbbTV has also been considered outside Europe in US, Japan, Australia, China, Singapore and Malaysia[24, 15]. 1 http://www.oipf.tv 2 http://www.ce.org/ 3 http://www.dvb.org/ 4 http://www.w3.org/

22

Figure 3.3: Show how the HbbTv standard is built on existing standards[13].

3.3.2

MHEG-5

“MHEG-5 is an open standard, TV middleware or application programme interface (API) designed to allow broadcasters to provide interactive/hybrid services beyond broadcast video that appeal to a wide audience cost-effectively”[11] MHEG-5 is a open standard developed by the Multimedia and Hypermedia Expert Group and has been approved and published by ETSI. MHEG-5 is designed to allow broadcasters to provide interactive services such as news, weather and customized EPGs into their broadcasts. In 2010 the standard was updated to include MHEG-IC (MHEG - Interaction Channel) to make use of services delivered by an IP connection. These services include video-on-demand, traditional text and graphics, secure transactions among others. The standard uses a customized object oriented language and MHEG-compatible devices has to have a MHEG engine or virtual machine to be able to execute MHEG features. The MHEG-5 standard is deployed in United Kingdom, New Zealand, Hong Kong and Germany. The updated version MHEG-IC which is able to receive content from a broadband connection is however only currently in use in the UK[11].

23

3.3.3

MHP

The Multimedia Home platform is a collection of open interactive TV middleware specifications produced by the DVB project. MHP has been in developing since 1997 and has been approved and published by ETSI. The latest released update named MHP 1.2 have support for contet delivered through both broadcast and broadband channels and are able to offer internet services such as Video-on-Demand and Pay-Per-View. The standard is based on the platform independent language Java and all MHP compatible device need to have a Java virtual machine present[17]. MHP can be considered a mature TV specification since it has been in use since the 90s and is developed by the DVB project. The biggest key market countries are Korea, Finland, Italy, Austria, Spain among others.

3.4 3.4.1

Considered databases SQL

SQL, or structured query language is a programming language used to manipulate and retrieve data from relational database management systems. The relational database is built on a structured hierarchy using tables and rows. The advantages of SQL and RDBMS are that they are a well established solution that works well in many applications if the amount of data is not to large. RDBMS also have great safety features and follows the ACID rules described below. ˆ Atomicity - A database transaction must follow the rule “all or nothing”. This means that if a transaction succeeds all changes must be committed, but if the transaction fails a rollback must be done to guarantee that the database is unchanged. ˆ Consistency - Only valid data will be stored on the database to preserve the consistency. If a transaction fails to meet the consistency requirements a rollback must be done. ˆ Isolation - If transactions is done in parallel, they must not affect each other. ˆ Durability - Guarantees that after a change in the database a user can assume that the change is available for future operations.

With the benefits of the ACID rules comes the downside with lack of scalability. The structure is very unflexible due to predefined tables and columns with fixed names and types. When the data set gets larger than the confines of a 24

single server a solution with complex clustering and multi-master replication is needed which often is hard to achieve in a good way. RDBMS often provides a huge set of functionality which normally is not used and this gives unnecessary complexity to simple programs. SQL has also got complaints that it has a complex syntax which is hard to learn and that different database management systems use a slightly different semantic[6].

3.4.2

NoSQL

NoSQL is a fairly new concept and is an alternative to the well established SQL language and relational databases. The big difference is how the data is stored. Instead of storing data in a predefined structure using tables and columns with fixed named and types, NoSQL stores data in “key/value”-pairs where a value can be complex and differ from other values with the same key. Attributes is defined dynamically in run-time making NoSQL more flexible compared to SQL. NoSQL databases also lack the guarantee of ACID rules which both is a advantage and disadvantage. The main advantage of a NoSQL database is the ability of horizontal scalability which is becoming a requirement in modern web-applications. Since data is stored without hierarchical structure the data is easily partitioned into several nodes in a cluster giving a linear scalability. NoSQL databases also offers flexibility in the meaning that database values are stored individually with no relation to each other and types is defined in run time. It also becomes more natural to map application objects with the same structure in the database. Without complex relations between tables and complex join operations, data access becomes faster than a relational database. The API used to manage and manipulate NoSQL databases is in the most cases easier to learn and use compared to a SQL language. One would say that NoSQL gives up the ACID rules to offer flexibility, scalability and speed. The greatest disadvantages with NoSQL is the lack of ACID rules guarantees. Atomicity cannot be guaranteed for more than one key/value pair modifications at a time. A NoSQL database lack consistency since single data may be stored with custom structure and attribute types. Isolation is not really needed since data is not related and durability is not guaranteed by default. More responsibility lies at the application developer to give application guarantees programatically[6].

25

Chapter 4

Resulting prototype and discussion In this chapter the chosen standard and why it was chosen is presented. An overview of the final design is presented followed by a detailed discussion of all including sub parts. How events could be sent in a live and non-live context is discussed at the end of this chapter.

4.1

Chosen standard

The new upcoming type of TV standards are so-called hybrid standards which attempts to merge broadcasts, IPTV and broadband delivered content into a single user interface on connected TVs and set-top boxes. Today’s TV platforms barely spans over more than one CE manufacturers devices and a common standard that works on a wider audience of platforms would help developers to create TV-applications more efficiently and less costly. The chosen standard is HbbTV due to the fact that it is the most promising and have been deployed in a larger part of Europe compared to the other standards considered [24, 15, 11, 17]. There have also been a trend that existing MHEG and MHP solutions has been converted into HbbTV solutions. One example is NorDig1 , which is specifying a common platform for digital television in the nordic market. NorDig has been giving up their previous choice of MHP for television interactivity to make use of the HbbTV standard instead[23]. The HbbTV specification is mainly based on broadly existing standards and web technologies. By doing this HbbTV is less hardware dependent than MHEG and MHP since most connected TV devices already has browser support. A MHEG 1 http://www.nordig.org/

26

compliant device must have a custom object engine and a MHP compliant device has to have a Java virtual machine integrated. HbbTV application development is more or less like regular web page development and the time and cost of application development could probably be reduced since a lot of competence already exists in this area. Hirsimaa did in 2011 an investigation[5] of how suitable HbbTV is as a future platform for connected TV devices and concluded that HbbTV has great potential. Minor flaws that was found during the research has been added and updated into new releases of the HbbTV specification.

4.2

Final Design

The final design is based on tests, research and collaboration with Accedo. To be able to handle and generate events a web based management portal has been created. The portal is built with regular web technologies including HTML5, CSS and JavaScript. AJAX requests is used to communicate with the main server. For more details about the management portal, see section 4.3. The main server is written in Java and uses a three layer architecture to make it more modular and maintainable. To get a good structure a framework called Spring MVC is used which is based on the common structure of models, views and controllers. For more details about the main server, see section 4.4. Events and user responses is stored in a document database called mongoDB which has better speed and scalability compared to a relational database. For more details about the database see section 4.5. To be able to send asynchronous events from a server to clients in real-time a second server has been added which uses WebSockets or long polling to simulate real-time push messages. This server can easily be scaled horizontally as needed depending on the number of expected users. For more details about the push server, see section 4.6. The client side is written with the HbbTV specification in mind and is implemented in JavaScript. AJAX Requests is used to communicate with the main server and WebSockets and long polling is used to be able to subscribe for live events. For more information about the client, see section 4.7. All data sent between nodes in the system uses the JSON format and have different structure and content depending on the purpose of the message. For more information about how to send events and data formats see section 4.8. For a complete overview of the system design see figure 4.1.

27

Figure 4.1: A System overview. Shows relations between different parts of the system including a media server, a management system, a main server, a database, push servers and a client.

4.3

Management Portal

To be able to manage and generate events from a content providers point of view a management portal has been created. The choice was to do a application that had to be installed locally on the computer or a web based application accessible from a normal web browser. Without major researches the web based solution was chosen due to the flexibility with a browser and internet as the only two requirements. Safety aspects is important in a web based solution such as this. A final version should have a comprehensive log-in procedure using SSL encryption and HTTPS protocols to ensure safety to the users. Usability and graphical design are two other important aspects to take into consideration to make customers satisfied

28

with the product. The prototype produced in this paper has not prioritized these aspects and has focused on functionality. The portal is build with standard web technologies including HTML5, CSS and JavaScript and uses AJAX requests to communicate with the main server to store, update and receive events.

Figure 4.2: Screen shots of the web-based management portal. Shows the login page, video list page and the event edit page

In a final version all media information is supposed to be provided by content providers but due to legal rights and agreements with Accedos customers video information and content could not be provided into the prototype. Instead video

29

information and content is simulated with fake data to be able to illustrate how i could look like. The portal consists of three types of pages, namely a login page, a list of videos and a detailed view of a single video where events can be managed. For screen shots see figure 4.2.

4.4

Server

The main part of the system is a server written in Java running on an apache tomcat server. The server handles AJAX requests from the management portal and TV clients and communicates with all nodes of the system. The language Java was chosen based on personal comfort, a server written in .Net, Nodejs or similar would have worked just as well. The server application is built with a modular three tier architecture in mind which consists of three layers: the user interface layer, the business layer and the data layer. The top layer is a interface between the server and clients and is more or less just passing data between clients and the business layer. The business layer handles all logic and functionality of the server. The data layer is used to abstract away how data is manipulated. A modular structure makes it easier to change, test and maintain the system which is desirable in a large project such as this.

4.5

Database

Speed and scalability is two desired characteristics of a database that is storing a huge amount of data and serve data to a lot of users. The framework described in this paper need to meet these requirements since a lot of events will be stored and a lot of viewers will retrieve and update values from the events. SQL and NoSQL has been considered and can be read more in detail in section 3.4.1 and 3.4.2. MySQL and MongoDB has been chosen to represent SQL and NoSQL due to practical reasons since both is free and well documented. A test application has been implemented to compare characteristics between MySQL and MongoDB and can be read more about in section 2.2.1. Test results to save, find and delete entries can be seen in figure 4.3, 4.5 and 4.4. The most impressing result was how fast MongoDB stores and deletes records compared to MySQL as seen in figure 4.3 and 4.4. If the result depends on MySQL or the widely used framework Hibernate cannot be concluded from this test but some performance differences where expected since MySQL has much more safety features and ACID guarantees. This result was however not critical in this particular application. The only users that will create and delete events

30

·104 MongoDB MySQL

MongoDB MySQL

1.5

6,000

Time(ms)

Time(ms)

8,000

4,000 2,000

1 0.5 0

0 0

2,000

4,000

0

Number of entries Figure 4.3: Time it takes to save a certain number of entries using mongoDBwith the MontoTemplate framework and MySQL using the Hibernate framework.

2,000

4,000

Number of entries Figure 4.4: Time it takes to delete a certain number of entries using mongoDB with the MongoTemplate framework and MySQL with the Hibernate framework.

is the content providers and the pressure on the database should not be that high in that regard. A more interesting characteristic is the time it takes to retrieve an entry from the database since this is where the pressure will be. As seen in figure 4.5, the result differ by around a factor of 10 between MongoDB and MySQL which is significant with millions of users requesting for data. In a small scale, such as in this test, the time difference is in the size of milliseconds which will not be noticed. To see a difference it has to be in a larger scale with many users and a larger set of data. Another interesting result can be seen in figure 4.6. A table in a relational database is smaller in size compared to collection in a document database with the same data. One reason for this could be that each document in a collection has to store each name of a name/value pair whereas in a relational database there are fixed column names which only is stored once. I have chosen to use MongoDB as database since it has better speed and scalability suitable for a applications with many concurrent users. Both theory in section 3.4.2 and performed perfomance tests verifies this.

31

2 MongoDB MySQL

1.5 Size(MB)

Time(ms)

10

MongoDB MySQL

5

1 0.5

0

0 0

2,000

4,000

0

Number of entries Figure 4.5: Time it takes to find and retrieve an entry from a MongoDB and MySQL using a certain number of entries.

4.6

0.5

1 4 ·10 Number of entries

Figure 4.6: The total size of a collection in mongoDB and a table in MySQL having a certain number of entries.

Push Server

As discussed in section 3.1.4 there is a problem when the server program wants to send an asynchronous real-time event to clients. To solve this an external push server has been added which will use one of the push technologies described in section 3.1.4. The push server must in similarity with the database be fast and scalable to be able to serve a huge amount of clients concurrently without too much latency. Initial thought was to use TCP Sockets to establish a full duplex two-waycommunication between the server and a client enabling message transmission in real-time. TCP sockets are however not supported in JavaScript since it lacks support to read raw byte streams. A workaround could be to use a Java servlet wrapper or a Flash wrapper over the JavaScript which indeed do have TCP socket support. This however adds complexity, puts more dependencies on the client and would most certainly reduce performance. Three larger groups of push server solutions where detected during the prestudy. ˆ Use a full-featured payable solution that handles everything from hosting to connection handling. PubNub2 and Pucher3 are two popular push notification services among others. ˆ Use a free open source framework and adapt it to the project. Several 2 http://www.pubnub.com/ 3 http://www.pusher.com/

32

projects existed including the APE Project4 , Nodejs5 with Faye6 and CometD7 among others. ˆ Develop a customized solution from scratch that is optimized for this particular application.

To begin with the full-featured solution PubNub was tested. PubNub was extremely easy to get started with and the provided framework API was compact and intuitive. The one and only disadvantage was that it was a quite expensive solution and is billed by the number of messages sent and by daily peak connections. Since it normally during a day is a small amount of viewer during the day and a lot of viewers at the evening it would not be a beneficial type of billing since you always get charged for the peak periods during the evening. Secondly the open source framework Faye was used which is a publish/subscribe solution using WebSockets or long polling as push solution. The Faye framework is running on nodejs which is a lightweight server written in JavaScript. For a client to be able to get live events into a specific video it just sends a subscription request to the push server including the unique video identification received from the media server. The push server holds the connection open and when the server receives an event message from the main server it sends the event to all client subscribing on that particular video identification. This solution could easily be scaled horizontally with more servers as seen in figure 4.7. The only new requirement is that the main server sends the publication message to all the including push servers. Servers could be placed geographically to reduce transportation latencies or use a load balancer to balance network traffic.

Figure 4.7: Shows how the publish/subscribe push message solution easily could be scaled horizontally. 4 http://www.ape-project.org/ 5 http://www.nodejs.org/ 6 http://www.faye.jcoglan.com/ 7 http://www.cometd.org/

33

A test application that compares latency between WebSockets and long-polling has been implemented and can be read more about in section 2.2.2. It was quite hard to test the latency in a large scale since browsers only have a small amount of available persistent-http-connections which is needed to establish a long polling connection. But as seen in figure 4.8 and 4.9 a significant difference can be observed even in a small scale test. WebSockets would without a doubt be the preferable push solution. The reason why WebSockets is so mush faster is partially that long polling is using the half-duplex protocol HTTP which first of all is not design to simulate a full-duplex connection and secondly have alot of unneccessary information in its header data for small messages compared to WebSockets. According to [26] WebSockets can provide a 1:500 or more reduction in unnecessary HTTP header traffic which decrease network traffic and message latency. Assuming that the avarage value in figure 4.8 is increasing linearly from 5 client and forward, long polling would be able to serve 310 client with an avarage value of 1 second while websockets would be able to serve 1230 clients with the same assumption in figure 4.9. Keep in mind that this tests has been done on a general purpose computer and may be different on a dedicated server computer. 150

Smallest Avarage Greatest

Time(ms)

Time(ms)

150

100

50

0

0

10

100

50

0

20

Number of clients Figure 4.8: Greatest, Smallest and Avarage latency to send a message from the push server to a certain number of clients using long polling.

Smallest Avarage Greatest

0

10

20

Number of clients Figure 4.9: Greatest, Smallest and Avarage latency to send a message from the push server to a certain number of clients using WebSockets

WebSockets is a quite new application protocol and do reqire HTML5 support of the browser and HbbTV does not state anything about HTML5 support in its specification. Many modern browsers used in HbbTV compliant boxes do however have HTML5 support8 but the assumption that all HbbTV compliant boxes have that cannot be taken. The HTTP protocol is supported in the HbbTV specification[13] and the assumption that long polling works can be 8 e.g.

ANT Galio, Opera and NetFront Browser NX

34

taken. A good solution could be to primarily use WebSockets and downgrade to along-polling solution if WebSockets not are supported.

4.7

Client

The client side of the system is basically a small JavaScript module. The module must be included into your HbbTV project to be able to make use of the framework API. The main purpose of the module is to handle server communication using AJAX, Long polling or WebSockets. Hardware used in connected TV devices is often minimal due to costs. Therefor it is not recommended to use structures and functions that consumes a lot of CPU power and memory usage. This has been in mind during the development. Another good habit is to use a JavaScript compression program such as JSMin9 , Packer10 or Closure compiler11 . The JavaScript module did decrease to 1/3 of the original size by using closure compiler. The framework API has been designed to be simple and intuitive and do only consists of a small number of functions. The responsibility of presenting events in the GUI has been assigned to the application developer since GUI objects and design often is application specific. The framework do only deliver event objects containing raw information about that specific event. It is then up to the application developer to display this content in a good way and call framework function when user interaction occurs. For a description of available API functions see section 4.7.1 To illustrate how it could look like an simple HbbTV application has been created which are able to show static mp4 videos and a live HLS stream. The framework has been integrated into the application and works as expected. Screenshots can be seen in figure 4.10.

9 http://www.crockford.com/javascript/jsmin.html 10 http://dean.edwards.name/packer/ 11 http://code.google.com/p/closure-compiler/

35

Figure 4.10: Screenshots showing a image advertising event, two question events and a statistics event.

36

4.7.1

Client framework

This section explains how to use the framework API and which functions are available. How to include the framework To use the framework API a JavaScript file has to be included into your HbbTV application as follows: 1

< script type = " text / javascript " src = " accedoEvents . js " >

How to initiate a AccedoEvent object Before initiate an AccedoEvent object you have to do two things: ˆ Declare a reference to your DOM video object 1

var video = document . getEl ementByI d ( ’ video ’) ;

ˆ Declare a callback function that should be called on an event. 1 2 3 4

function m y C a l l b a c k F u n c t i o n ( event ) { // Do something }

To initiate a new AccedoEvent object simply type: 1

var events = new AccedoEvents ( video , m y C a l l b a c k F u n c t i o n ) .

Using AccedoEvent Object Start and stop listening to live events for a specific video: 1 2

events . live . subscribe ( videoId ) ; events . live . unsubscribe ( videoId ) ;

Start and stop listening to non-live events for a specific video: 1 2

events . nonlive . subscribe ( videoId ) ; events . nonlive . unsibscribe ( videoId ) ;

Voting in a question event with a specific selection 1

events . registe rAnswer ( eventId , selection ) ;

Generate a statistics event 1

events . g e t E v e n t S t a t i s t i c s ( eventId ) ;

37

4.8

Event delivery

The ambition was to test event delivery through both an internet channel and a broadcast channel. During the pre-study there was proof that it is possible to send applications and stream events merged into a normal broadcast MPEG stream. A broadcast stream is however not completely reliable and a stream event is normally sent several times to higher the probability of message delivery. Live events do need a high delivery precisition, especially if there is money involved such as betting events. Events sent through a broadcast stream is however an interesting topic since it would lessen the burden on servers and be able to reach a wider audience which normally don’t use the internet features of modern set-top-boxes. Events delivered through a broadcast stream has not been tested due to lack of time. This section is giving a suggestion on how events could be sent in a live and non-live context using internet technologies and which data format and why this has been chosen.

4.8.1

Event format

The JSON text format has been chosen to be used to interchange data between the server and clients. JSON is a compact format, easy for both machines and humans to interpret and is widely used in todays web applications. JSON is described in depth in section 3.1.3. Depending on the type of event that is transmitted, a JSON object contains different attributes. By doing this the size of transmitted data can be reduced compared to a universal event object that can hold all types of events. As an example, a regular question event have the following attributes: ˆ id, a unique identifier to distinguish between different events. ˆ type, distinguish between different event types. ˆ question, question to write out. ˆ answers, available answers to the question stored in an array.

It is important to optimize the size if transmitted data in this type of application with many simultaneous clients. By reducing the message size the total amount of throughput is decreased leading to better latency times. The following example is to illustrate how small optimizes can make a huge impact. Example: around 4 million people watched the swedish eurovision song contest in 2012[21]. Lets say that there was an average of 2 people per TV, giving a total of 2 million TV devices. Imagine that there were 10 scheduled events during

38

the show. An optimization of the system led to a reduction of 10 characters, where one character is equal to 1 byte, in each event by giving attributes shorter names. The total amount of reduced network traffic was then: T = 2 ∗ 106 ∗ 10 ∗ 10B = 200000000B ≈ 190M B Remember that this is just one program with 10 events. With the full supply of TV programs and more and more events being added over time, a reduction of 10 characters can be a significant amount of decreased network traffic in the long run.

4.8.2

Events in a non-live context

In a non-live context event information is known from start and can easily be handled locally at the client side. At the beginning of a static video a simple AJAX request could be generated to receive all event information for this particular video. Event generation could then be handled locally by synchronizing events with the time of the video player. This would lead to a reduction of network traffic and also decrease server CPU consumption.

4.8.3

Events in a live context

The same prinicple as in a non-live context cannot be used in a live context since events can be generated asynchronously. A discussion on how this could be solved is decribed in section 4.6.

39

Chapter 5

Conclusions, Future work and Improvements The prototype has shown that event-driven interaction during TV programs can be used advantageously. This chapter is presenting some final conclusions and lists some potential improvements and future work.

5.1

Conclusions

Based on the prestudy and observations from the prototype, event-driven interactivity during application based TV-programs can by advantage be used to enhance the user experience. There are however some practical problems that has to be solved. One of the greatest difficulty of TV interactivity is to convince content providers to add more interactive content into their broadcasts and argue how that will generate more profit for them. Without this content the interactivity becomes meaningless since the content providers own all rights to thier broadcasts. It is also difficult to find a balance and not overhelm viewer with to many events making them irritated and uninterested. All viewers are probably not interested in all interactive features and a possibility to disable parts of the interactive services should be provided. One idea of improvement is to synchronize a secondary screen such as a tablet or phone with the TV and let events be generated on that screen instead. The greatest potential of event driven interactivity is shown in a live context. Viewers could participate in contests, be involved in live betting, vote in elimination shows, answers questions that are furthered discussed in a live program

40

among other things. People likes to get involed using social medias and this could be an additioan way to get involved. In a non-live context viewers watch movies and TV-series and would probably not want to be disturbed while doing that. Potentially events could be generated after e.g. a movie but would probably already have been closed by then. Advertising events could however be interesting to finance the videos. Several good frameworks already exists though, such as [29], to enable advertsing features and the wheel should not be invented twice. HbbTV is an easy platform to work with and it has a lot in common with regular web development. The main difference is the HbbTV API used to make HbbTV specific tasks more convienient. The firefox plugin FireHbbTV is a good test emulator during the development of an HbbTV application. It is still obvious that HbbTV is an immature standard. Available example applications are limited and API documentation is more or less non-existent. The STB used was HbbTV complient but only had some of all HbbTV functionality available making it hard to rely on HbbTV specific functions. Hopefully this will change in the future and Accedo are currently notice a high demand of HbbTV application solutions especially from the German market. Compared to similar standards HbbTV predicts a bright future.

5.2 5.2.1

Improvements Graphical improvements

Both the management portal and the client event presentation must be updated with graphical interfaces designed to enhance usability and use a modern style. The managment portal could possibly be redesigned to easier be able to find particular videos. In a live context it would be advantageous to see the video streamed in the browser to easier moderate live event handling. A particular tool for image and video manipulation could be added to simplify image and video advertising.

5.2.2

Optimizations

More extensive profiling should be done to detect and fix bottlenecks of the systems. The amount of data sent should be investigated furthered and be minimized to decrease network traffic. Some optimizations has been considered but there are still optimizations to be done.

41

5.3 5.3.1

Future work Receive real video content

The prototype uses only simulated videos and video information to illustrate how a final solution might look like. More interesting would be to get video content from a real content provider and build up the management portal using this huge amount of data. This would lead to new requirements including search tools to find specific videos more easily. The security must however be improved to make use of HTTPS and SSL descryption before real content could be provided.

5.3.2

Customized push server

The prototype uses the open source solution Faye running on a nodejs server. This is a general purpose solution which is designed to work on many different projects and a customized solution could potentially generate better performance. Since the push server is a critical part of the system it would be interesting to compare different push implementations more in depth.

5.3.3

Events through broadcast stream

The pre-study shows that HbbTV supports stream events delivered through a DVB broadcast stream. Hirsimaa[5] has done tests to send stream events into a HbbTV application. The conclusion was that there was too much latency but he did not know if it did depend on the DVB channel or if it was bad hardware in the set-top box. With the motivation that content delivered through the broadcast stream would reduce network traffic and lessen the burden on servers it would be interesting to do a deeper investigation.

5.3.4

Events on secondary screen

The final prototype generate events on the TV screen. An alterernative soultion could be to synchronize a secondary screen such as a tablet och phone with the TV and let events be generated that screen instead. A phone or tablet have much more CPU power and screen resultion wich can be used to enhance visual effects. Also the viewer does not get disturbed on the actual TV screen.

42

Bibliography [1] Informa, Connected-TV ans pay-TV operator partnership, 2012. [2] Fredrik H¨ oglin, Event-driven interactivity in IPTV, DIVA 2011. [3] Jon-Henrik Bruks˚ as et al, Push-teknik p˚ a webben, DIVA 2010. [4] Engine Bozdag, Push solutions for AJAX technology, DIVA 2007. [5] Christoffer Hirsimaa, HbbTV - The application standard for TV broadcasters, DIVA 2012. [6] Natalia S¨ oderberg, Jan Eriksson Utredning av NoSQL-databaser, Diva 2011. [7] ITU, International telecommunication unions homepage, http://www.itu. int, [Online; accessed 2012-10-07]. [8] Mozilla Developer Network, JavaScript, https://developer.mozilla.org/ en-US/docs/JavaScript, [Online; accessed 2012-11-15]. [9] IMDB, Winky Dink and You, http://www.imdb.com/title/tt0045456/, [Online; accessed 2012-10-01]. [10] DVB, DVBs official homepage, http://www.dvb.org/, [Online; accessed 2012-10-08]. [11] IMPALA, MHEG official website, http://www.impala.org, [Online; accessed 2012-10-03]. [12] MPEG Overview of the MPEG-4 standard, http://mpeg.chiariglione.org/ standards/mpeg-4/mpeg-4.htm, [Online; accessed 2012-10-09]. [13] ETSI, Hybrid Broadcast Broadband TV Technical Specification, http://www.etsi.org/deliver/etsi ts/102700 102799/102796/01.01.01 60/ ts 102796v010101p.pdf, [Online; accessed 2012-09-14]. [14] mediatvcom, Hybrid broadband broadcast TV V1.1.1 explained, http:// www.mediatvcom.com/download/HbbTVExplained standard overviewWP. pdf, [Online; accessed 2012-10-09].

43

[15] Advanced Television, News article about HbbTV, http://advanced-television.com/index.php/2012/09/19/ spain-gives-green-light-to-hbbtv-standard/, [Online; accessed 2012-1002]. [16] THM A beginners guide for MPEG-2 standard, http://www.fh-friedberg. de/fachbereiche/e2/telekom-labor/zinke/mk/mpeg2beg/beginnzi.htm, [Online; accessed 2012-10-07]. [17] MHP Multimedia Home Platform - Open middleware for Interactive TV, http://www.dvb.org/technology/fact sheets/DVB-MHP Factsheet.pdf, [Online; accessed 2012-10-09]. [18] Wikipedia CE-HTML, http://en.wikipedia.org/wiki/CE-HTML, [Online; accessed 2012-10-09]. [19] W3C CSS, http://www.w3.org/Style/CSS/, [Online; accessed 2013-01-30]. [20] The guardian A short history of interactive TV, http://www.guardian.co. uk/technology/2001/apr/05/onlinesupplement5s, [Online; accessed 2012-1024]. [21] SVT, S˚ a m˚ anga s˚ ag direkts¨ andningen av melodifestivalen i SVT1, http://www.svt.se/melodifestivalen/ halva-sverige-sag-loreen-vinna-melodifestivalen-2012, [Online; accessed 2012-11-01]. [22] JSON official homepage Overview of json, http://www.json.org/, [Online; accessed 2012-11-01]. [23] Broadband TV news, Nordic region commits to HbbTV, http://www. broadbandtvnews.com/2012/04/11/nordic-region-commits-to-hbbtv/, [Online; accessed 2012-11-14]. [24] Broadband TV news, News article about HbbTV, http://www.broadbandtvnews.com/2012/05/24/ hbbtv-sweeps-interactive-tv-across-europe/, [Online; accessed 2012-1002]. [25] ISO Information technology generic coding of moving pictures and associated audio information part 6: Extensions for dsm-cc, http://www.iso.org/ iso/iso catalogue/catalogue tc/catalogue detail.htm?csnumber=25039, [Online; accessed 2012-11-14]. [26] WebSocket.org HTML5 Web Sockets: A Quantum Leap in Scalability for the Web, http://www.websocket.org/quantum.html, [Online; accessed 201211-15]. [27] IETF The WebSocket Protocol, http://tools.ietf.org/pdf/rfc6455.pdf, [Online; accessed 2012-11-22].

44

[28] Wikipedia Push technologies, http://en.wikipedia.org/wiki/ Push technology, [Online; accessed 2012-11-22]. [29] Google Google Interactive Media Ads, https://developers.google.com/ interactive-media-ads/, [Online; accessed 2013-01-30].

45

Appendix A

Software and Hardware A.1

Software

ˆ Windows 7 Ultimate x64 - Main operating system ˆ Netbeans 7.2 - Main IDE ˆ Apache-tomcat 7.0.27.0 - Main server ˆ Java 1.7.0 07 - Main server language ˆ FireBug 1.10.6 - To test JavaScript code and debug network communication ˆ FireHbbTV 1.1.14 - To emulate HbbTV applications in Firefox ˆ Node v0.8.12 - Push message server ˆ MongoDB 2.2.0 - Evaluated database ˆ MySQL 5.5.27.2 - Evaluated database

A.2

Hardware

ˆ LG BlueBerry STB LGTS-B11 - Set-top box

46