event-driven interactivity in application-based...
TRANSCRIPT
UPTEC IT 13 001
Examensarbete 30 hpFebruari 2013
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 Hemsida: http://www.teknat.uu.se/student
Abstract
Event-driven interactivity in application-basedTV-programs
Per Moberg
In recent years TVs and set-top boxes has been featured with built-in internetconnectivity which open up doors to new innovations and technologies. This researchhas particularly investigated the possibility of adding event-based interactivity intoapplication based TV-programs and has focused on the hybrid standard HbbTV. Adesign suggestion of a framework to make use of eventdriven interactivity has beencreated and a proof-of-concept prototype has been implemented.
The study has demonstrated that event-driven interactivity can to advantagebe used to enhance the user experience of TV-programs, especially in a livecontext with many concurrent viewers. HbbTV has been shown to be a suitablestandard for connected TV devices and is currently growing in the EuropeanTV market.
Tryckt av: ITC
Sponsor: Accedo BroadbandISSN: 1401-5749, UPTEC IT13 001Examinator: Lars-Åke NordénÄmnesgranskare: Justin PearsonHandledare: Johan Pettersson
0.1 Sammanfattning
TV-industrin ar inne i ett spannande skede dar fler och fler TV-enheter bliruppkopplade mot internet och nya tjanster sa som applikationsportaler, Video-On-Demand(Vod), IPTV och Pay-per-View utvecklas i snabb takt. Tack vareinternet finns nu aven stor mojlighet for okad interaktivitet med TV-tjanstersom inte varit mojlig pa samma satt genom vanliga digitala TV-natet.
Termen interaktiv TV ar inte nagot nytt. Redan under senare delen av 50-talet sande CBS-television ett barnprogram vid namn ”Winky Dink and you”dar tittarna skulle satta pa en speciell plastfilm pa TV-skarmen och rita teck-ningar for att hjalpa Winky losa problem. Programmet overlevde dock intemen var en start pa nya innovationer inom omradet. Exempel pa interaktivaTV-tjanster som har overlevt genom aren ar bland annat telefonsamtal underdirektsandingar och text-tv.
Syftet med rapporten ar att undersoka mojligheten for eventbaserad interak-tion under applikationsbaserade TV-program. For att kunna ge ett proof-of-concept har en prototyp till ramverk implementerats som kan hantera just detta.Beroende pa vilken typ av program som visas kan event vara av olika typer. Detyper som har implementerats i prototypen ar frageevent, statistikevent ochreklamevent.
For att kunna testa och implementera ett ramverk har olika plattformer ochstandarder undersokts. MHP, MHEG och HbbTV blev utvalda att granskasnoggrannare. Den valda standarden blev HbbTV vilket ar en sakallad hybrid-plattform som kan ta emot innehall fran kabel-, luftburen- och satellitsandningarmen aven genom internetbaserade losningar sa som IPTV och WebTV. HbbTVvaldes eftersom det ar en lovande och val etablerad standard i Europa som harstod pa manga olika plattformar. HbbTV ar aven baserad pa redan existerandestandarder och webbteknologier vilket kan snabba pa utvecklingsprocessen avapplikationer.
Baserat pa litteraturstudien och den fardiga prototypen ar mojligheterna attlagga till interaktiva event under TV-program mycket goda. Tack vare upp-kopplingen mot internet finns det redan manga val etablerade webbteknolo-gier tillgangliga och en stor mangd redan existerande data som kan anvandasfor att gora TV-program mer dynamiska och interaktiva. Eftersom HbbTV-applikationer mer eller mindre utvecklas som vanliga webbsidor finns redan enstor kompetens vilket kan reducera utvecklingstid och kostnader.
Viktiga krav pa ett system med manga samtidiga anvandare ar att det ar snabbtoch skalbart samt minimerar mangden data som skickas mellan klienter ochservern. Som exempel har studien visat att en dokumentdatabas sa som mon-goDB ar mer lamplig an en relationsdatabas sa som MySQL eftersom en doku-mentdatabas ar mer skalbar och kan hamta databasposter snabbare. Nackdelenar att mer ansvar laggs pa systemutvecklaren som maste tanka pa att de klas-siska ACID villkoren inte uppfylls i en dokumentdatabas.
1
Studien har aven pavisat att WebSockets ar att foredra som push-teknologijamfort med long-polling och polling. Alla HbbTV-enheter stodjer dock inteWebSockets sa en elegant losning pa det problemet ar att primart anvandaWebSockets och nedgradera till long-polling da stodet saknas.
I framtiden ligger svarigheten i att overtyga innehallsleverantorer att lagga tillmer interaktivt innehall i sina sandningar. Det ar ett krav eftersom de ageralla rattigheter till det som visas pa sandningen inklusive eventuella interaktivaevents. Den andra svara uppgiften ar att overtyga anvandare att faktiskt viljaanvanda och svara pa genererade events.
Den fardiga prototypen har testats pa en HbbTV-kompatibel set-top box. Detimplementerade ramverket har integrerats med en simpel HbbTV applikationsom visar statiska mp4-strommar och en live HLS-strom. Prototypen fungerarsom vantat och illustrerar hur eventbaserad interaktion kan se ut.
2
Contents
0.1 Sammanfattning . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1 Introduction 71.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Problem formulation . . . . . . . . . . . . . . . . . . . . . . . . . 91.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.4 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.5 Previous research . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.1 Event-driven interactivity in IPTV . . . . . . . . . . . . . 121.5.2 Hybrid Broadcast Broadband TV (HbbTV) . . . . . . . . 12
2 Method 132.1 Pre-study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2 Performance Tests . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.1 MongoDB vs MySQL . . . . . . . . . . . . . . . . . . . . 142.2.2 WebSockets vs Long-polling . . . . . . . . . . . . . . . . . 14
2.3 Development method . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4.1 Use case 1 - live entertainment show . . . . . . . . . . . . 152.4.2 Use case 2 - non-live movie . . . . . . . . . . . . . . . . . 162.4.3 Use case 3 - live debate . . . . . . . . . . . . . . . . . . . 16
2.5 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Theory 183.1 Internet technologies . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.1 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.2 AJAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.1.3 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.4 Push technologies . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 DVB technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.1 DVB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.2 DSM-CC . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.3 Stream-events . . . . . . . . . . . . . . . . . . . . . . . . . 21
3
3.3 Considered Hybrid Standards . . . . . . . . . . . . . . . . . . . . 223.3.1 HbbTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.2 MHEG-5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.3.3 MHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Considered databases . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.1 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.4.2 NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Resulting prototype and discussion 264.1 Chosen standard . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2 Final Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3 Management Portal . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.6 Push Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.7 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.7.1 Client framework . . . . . . . . . . . . . . . . . . . . . . . 374.8 Event delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.8.1 Event format . . . . . . . . . . . . . . . . . . . . . . . . . 384.8.2 Events in a non-live context . . . . . . . . . . . . . . . . . 394.8.3 Events in a live context . . . . . . . . . . . . . . . . . . . 39
5 Conclusions, Future work and Improvements 405.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2 Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.1 Graphical improvements . . . . . . . . . . . . . . . . . . . 415.2.2 Optimizations . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.3.1 Receive real video content . . . . . . . . . . . . . . . . . . 425.3.2 Customized push server . . . . . . . . . . . . . . . . . . . 425.3.3 Events through broadcast stream . . . . . . . . . . . . . . 425.3.4 Events on secondary screen . . . . . . . . . . . . . . . . . 42
Appendix A Software and Hardware 46A.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46A.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. Themain problem, and why this problem is of interest is also addressed. The lastpart of this chapter is explaining constraints of this paper and gives a shortsummary 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 inno-vations are developed rapidly. The linear television is on its way to become a fullinteractive entertainment machine and will in similarity with smartphones becustomizable with applications from various kinds of application-stores. Thesekind of features are now possible due to the fact that almost all new televisiondevices have built-in internet connectivity.
Informa1, which is one of the leading providers of business information andservices, predicts that connected TV devices will be one of the most fast-sellingtype of consumer electronics production in history. According to Informa therewill be more than 1.8 billion TV devices with in-built internet connectivity inuse in over 570 million homes by the end of 2016[1]. A more detailed graph ofInforma’s forecast can be seen in figure 1.1. A huge benefit with internet is thatit has a two-way-communication by definition which can be used to enhance userinteraction with the television set.
The term interactive TV is not something new. In the late 1950s CBS televi-sion network broadcasted a children program named “Winky Dink And You”where viewers were suppose to attach a special plastic film on the televisionscreen and do drawings to help Winky Dink solve problems. The series did not
1www.informatandm.com
7
Figure 1.1: Predicted amount of connected-TV devices globally during the period 2011-2016[1]
survive but it was an eye opener for new innovations[9]. Many attempts to intro-duce interactive elements in TV-programs has been done since then, but mosthave been discarded due to high costs. Some have however survived. Phonecalls during TV-programs have been around since 1959 and the teletext tech-nology2, presented by a group of engineers from BBC in 1970, are still presenttoday[20].
During the 21st century, interactive TV has evolved drastically. Users are nowable to watch TV programs anywhere and anytime using Video-on-Demand(VoD) services and purchase content such as movies and applications directlywith their remote control. Viewers are also able to control the TV with gestureand voice commands and the use of a second screen such as a phone or laptopare more commonly used to enhance the TV experience.
User interaction during application based TV-programs is one area that has notgot that much attention. Viewers basically watch videos streamed from a serverand are only able to manipulate the video with commands such as pause, stopand play. One idea to improvement is to make TV-programs more interactive byenabling two-way-communication, which now is possible due to the availabilityof an internet connection. Event-driven interactivity is a good way to structurethe interaction and depending on the content of a video, different types of eventscould be thrown.
Accedo believe that these kinds of features will be present in a near future and
2http://en.wikipedia.org/wiki/Teletext
8
want’s to investigate the possibility of creating a framework available for devel-opers to make use of interactive events during application based TV-programs.The design suggestion should include some way to manage and generate eventsfor a content provider, some way to synchronize events with what the viewersare 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 interactivityduring application-based TV programs and with the assumption that it is pos-sible 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, wherelive is when many viewers watch the same program and non-live is when a vieweralone watch a static video. To be able to do the investigation a suitable targetplatform or standard needs to be chosen since a platform independent solutionis much harder or even impossible to achieve. Depending on the content of aTV program events can be of different types. This research will focus on thefollowing event types:
� Questions
� Betting
� Statistics
� Information
� Advertising(video/images)
By discussions with employees at Accedo and an initial investigation, a set ofinteresting issues were created. Some of the more important issues discussed inthe 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, synchro-nize events, handle events in a live and non-live context, detect events and handle userresponses.
1.3 Purpose
Accedo is the market leading enabler of next generation TV application solu-tions. With a high probability, television interaction during application-basedTV programs will be an expected feature of modern television sets and possiblesolutions needs to investigated and evaluated. With an easy-to-use frameworkavailable for developers to use would really simplify application developmentand also convince content providers to add more interactive content into theirbroadcasts.
A good application where event-driven interaction could enhance the TV ex-perience is for example to replace phone and SMS voting during entertainmentshows by a simple multiple answer question event which a viewer can respondto 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 thesame questions as the competitor and also see statistics of how good you arecompared to other viewers. In live political debates viewers could be able to
3http://en.wikipedia.org/wiki/Who Wants to Be a Millionaire
10
answer questions which is furthered discussed in the TV show. This type ofinteraction would really change the whole user experience and the same conceptcan be used on several types of programs. Event-driven interactivity can alsobe used to show different types of advertising and simplify betting by just usingyour 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 hasits own platform to execute TV applications. To give a proposal that works onall devices at once is more or less impossible. One part of this thesis is to findand use a suitable standard, preferable one that is platform independent andworks with a larger group of TV devices. The framework is then designed andimplemented with respect to the chosen standard.
Also notice that this research is a smaller research to investigate the possibilityof event-based interactivity during application-based TV shows and the pro-posed design and implemented proof-of-concept prototype is just a suggestion.Several experts could work for years to create the perfect solution and for asingle person with a limited amount of time to create such a system is just notreasonable.
Visual presentation is also outside the scope of this paper. A management portaland a example application will however be implemented but the focus will beon functionality, not graphical presentation. There also exists a huge amountof different TV programs and therefore also a high amount of different types ofevents that could be generated. To limit this research, only a few use cases isbeing investigated and the events generated from the prototype is being basedon these.
1.5 Previous research
In recent years there has been a limited amount of published research papersabout interactive television. This is probably because the hard competition withinternal researches not published to a public audience. Of the existing papersmostly are about on how to interact with the TV using speech and your bodyand also how a second screen such as a phone or laptop could be integrated toenhance the TV experience.
Two articles that has been of interest for this paper are summarized in section1.5.1 and 1.5.2.
11
1.5.1 Event-driven interactivity in IPTV
In 2011 Fredrik Hoglin[2] investigated the possibility of event driven interactiv-ity during live sport. The main idea was that it should be possible to watchseveral live football games in parallel in the sense that a user should receivenotifications when something interesting happened in another football game.A limited proof-of-concept prototype with manual event generation was imple-mented and it showed that this kind of feature have great potential. The paperalso makes aware of the lack of standards which makes the development processhard with these kinds of applications. On top of that the implemented proto-type was specific to TeliaSoneras IPTV platform. These kinds of applicationswould 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 asa future standard for connected TV devices. HbbTV tries to harmonize broad-cast, IPTV and broadband delivered content into one user interface. HbbTVapplications are mostly built with regular web technologies, in order to reducelearning times for new HbbTV develpers. During the investigation minor flawswas found such as lack of cookies and DRM support, but these features has beenupdated in later realeases of the standard. Hirsimaa concludes that the standardhas great potential and he recommend it as a future standard for connected TVdevices.
12
Chapter 2
Method
In this chapter the methods used to produce this paper is explained. First somedetailes about the pre-study is presented followed by a description of executedperformance tests. After that the development method used to implement theprototype is being discussed and at the end of this chapter a set of use cases isbeing presented to easier understand what the final product should be able todo.
2.1 Pre-study
The first part of the thesis was to find and read appropriate literature to investi-gate possible solutions to a interactive framework and later be able to design andimplement a prototype. Literature was collected from various article databasesand 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 fellinto 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 thescale of millions, frequently read records from it. Document databases and rela-tional databases are frequently used at Accedo and to be able to choose the mostsuitable database, a performance application has been implemented. Read moreabout SQL and relational databases in section 3.4.1 and more about NoSQL anddocument databases in section 3.4.2. Details about the test application can beseen in section 2.2.1.
One important problem described in section 3.1.4 is how to send events fromserver side to clients in real-time without too much latency. Typically somekind of push technology is used to achieve this kind of behaviour and two of themost common techniques are long-polling and webSockets. A test applicationhas been implemented to compare latencies between these two techniques andmore 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 ap-plication has been implemented. The test application did compare performanceattributes between the document-based database MongoDB and the relationaldatabase MySQL. The application did measure the time it takes to save, findand delete a certain number of database records. The test application has beenexecuted with different number of database records and each test has been exe-cutes several times to get better accurancy. The size of both the databases wasalso noted throughout the tests. The same Java object was used to be stored inboth of the databases. The external frameworks mongoTemplate and Hibernatewas 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 senda message from a server to a certain number of clients using WebSockets andlong-polling. The server and the clients all existed on the same machine and thesystem clock was used to take time stamps. The test has been executed withdifferent numbers of clients and the lowest, avarage and greatest latency hasbeen documented. The test was only done in a small scale since a single browseronly have a limited amount of persistent-http-connections which is needed toestablish a long-polling request.
14
2.3 Development method
This thesis was done at Accedos premises in Stockholm. A variation of softwareprograms and hardwares has been used in the development and a detailed listwith versions can bee seen in appendix A.
To illustrate how event-driven interaction could be presented a prototype hasbeen implemented. The prototype design was based on the literature study andresults from the performance tests. The resulting discussion is based on theprestudy and from observations of the final prototype. The implementation hasbeen done with agile methods focusing on working code. The development pro-cess started with a simple solution with limited functionality and new featureswas added over time. By doing this the requirements could easily be changedthroughout 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 demonstratedusing the prototype. Use cases is a good way to describe what the final productshould 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 inter-active events. A common theme of such shows is that there are a group ofcontenders that is competing for a price. A common scenario is that a competi-tor is doing his/her routine and here is an excellent time to send informationevents about the competitor and a question event to get the viewers thoughtsabout the routine. Another common scenario is that there is a live-voting partat the end of the show and a multiple answer question event could be moreconvenient 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 arriveswith 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 aboutMagnus 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 allthe 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 an-other example application. Advertising events could be appropriate if it is freeto watch the movie. At the end of the movie a question event about yourthoughts about the movie could be generated and after that let you know whatother 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 aboutthe 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 theprogram. Depending on what subjects are discussed, multiple answer questionscould be asked to the viewers and results and statistics could be further dis-cussed 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 event-driven interaction during TV shows. Next chapter is presenting theory neededto understand the results in chapter 4.
17
Chapter 3
Theory
In this chapter, the theory needed to understand the result in chapter 4 ispresented. Depending on knowledge of the reader this chapter may be read asneeded. Internet specific and DVB specific technologies used to send events toa connected TV device is explained in the first half of this chapter. Consideredstandards 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 eventsusing the internet protocol.
3.1.1 JavaScript
Javascript is a scripting language commonly used as a part of a web-browser tobe able to create more dynamic webpages. Since the JavaScript engine is locatedat the client side of a web page it can respond to user interaction rapidly in-creasing responsiveness[8]. JavaScript is often used to communicate with serversusing HTTP requests.
3.1.2 AJAX
AJAX (Asynchronous JavaScript and XML) is a generic name for web technolo-gies used to create asynchronous web applications which are able to communi-cate with servers without changing the state of a web page. CSS is used to styledata, DOM is used to interact with information on the page, XMLHttpRequests
18
provides data exchange between the browser and a server and Javascript is thelanguage that bring all these technologies together.
3.1.3 JSON
JSON (JavaScript Object Notation) is a lightweight data format which is easyto read and write both for humans and machines. The JSON format is languageindependent and there are parsers to most of the well known languages and iswidely used to interchange data between network applications. JSON uses acollection of name/value pairs to describe a single object and it uses brackets torepresent ordered lists of values such as arrays. An example is listed in figure3.1.
1 {
2 "_id" : "508 a8ab4680714f3e4678cc9",
3 "type" : 2,
4 "time" : 100,
5 "question" : "Did you like this episode?",
6 "answers" : ["Yes","No"]
7 }
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 re-quests for content from a server and the server acknowledge this request andsends back a response. This type of communication is applicable when the run-time behavior is known which normally is the case of web pages. A problemwill however arise when the server wants to send messages to the client asyn-chronously without the clients knowledge. Push messages is a common expres-sion for this type of communication and typically uses different types of pollingtechniques to simulate this behavior. This section is explaining a selection ofalternatives to send messages from a server to a client asynchronously.
Polling
Polling in a web context is a technology where a client request for informationfrom a server at regular time intervals using the HTTP protocol. This techniqueis easy to implement and can be used to detect if an event has occurred byfrequently asking the server. Since most of the responses will be empty a lotof 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 thatinstead of responding with an empty request when nothing new has happened,the connection is hold open until new information arrives or a connection time-out 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-communicationusing one single TCP connection. WebSockets is an important part of theHTML5 initiative and is a good alternative for bi-directional communicationcompared to solutions using the HTTP protocol such as polling and long polling.
The WebSocket protocol is an independent TCP-based protocol and its onlyrelation to the HTTP protocol is the initial handshake between two nodes. Thehandshake will upgrade the connection to make use of the WebSocket protocol.The WebSocket protocol is design fit into web development and have much lessheader overhead compared to a HTTP requests reducing network traffic andlatency[27]. The main disadvantage with WebSockets is that the browser in useneed to have HTML5 support.
3.2 DVB technologies
This section is giving an introduction to DVB technologies used to send eventsthrough a broadcast channel.
3.2.1 DVB
“The Digital Video Broadcasting Project (DVB) is an industry-ledconsortium of over 200 broadcasters, manufacturers, network oper-ators, software developers, regulatory bodies and others in over 35countries committed to designing open technical standards for theglobal delivery of digital television and data services”[10].
In 1991, a group containing of broadcasters, CE manufacturers and regulatorybodies in Europe formed a group that would monitor the introduction of digitalTV, and this became the foundation of the DVB project. The first phase wasto establish standards for delivery of digital TV content and the three mainstandards produced were DVB-S for satellite networks, DVB-C for cable net-works and DVB-T for terrestrial networks. These standards mainly describe
20
the technical aspect of digital TV delivery including the physical layer and datalink layer of the distribution system. Over the years many standards have beenpublished including DVB-H for handheld mobile devices and upgraded versionsof 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 ap-plications through a broadcast stream. DSM-CC is a standard[25] for datatransmission over MPEG-1 and MPEG-2 streams and use a so called ”Objectcarousel” to merge application data into the broadcast stream. Clients cannotrequest for data as in internet communication and instead have to wait until arequested object is transmitted in the stream. The time interval until a DSM-CC object is transmitted again depends on the size of a DSM-CC object andthe bandwidth allocated for it. For an overview see the ”Application” sectionin figure 3.2.
Figure 3.2: General concept of merging applications and external data into a broadcaststream[5].
3.2.3 Stream-events
Broadcasters are able to send stream events through a broadcast stream whichcan be used to send interactive events. A stream event is a package containinginformation 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 sentseveral times to guarantee arrival. If a TV device detects the same event morethan once it simply rejects it.
To be able to detect stream events, information about expected events must beregistered in the client application and a JavaScript listener must be declared.Information about expected stream events can be provided in two ways. Eitherthe DSM-CC object contains information about expected requests or an externalApplication Information Table (AIT) XML file is provided. The AIT XML istypically used when an application does not have an DSM-CC object and isreceived from other resources[5]. Stream events and the AIT XML file is partof 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 in-dustry standard platform for signaling, transport, and presentationof enhanced and interactive application design for running on hybridterminals that include both a DVB compliant broadcast connectionand a broadband connection to the Internet”[13]
HbbTV is an open standard, approved and published by ETSI, providing analternative to proprietary TV technologies for broadcasters to deliver interac-tive services to a customer. HbbTV aims to unite broadcast TV, IPTV andbroadband services using one single user interface. HbbTV compatible devicesare able to operate over a normal internet connection and different broadcastingtechnologies including satellite, cable and terrestrial networks[14].
The HbbTV standard is based on existing standards and web technologies in-cluding OIPF1, CEA2, DVB3 and W3C4, see figure 3.3. By using well knowntechnologies the development time and cost could possible be reduced since alot of competence already exists.
The HbbTV standard is making its way through Europe and countries includ-ing Germany, France, Spain, Holland among other has already adopted to useHbbTV as standard for connected TVs. The forcast is that more europeancountries will follow and HbbTV has also been considered outside Europe inUS, Japan, Australia, China, Singapore and Malaysia[24, 15].
1http://www.oipf.tv2http://www.ce.org/3http://www.dvb.org/4http://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 pro-gramme interface (API) designed to allow broadcasters to provideinteractive/hybrid services beyond broadcast video that appeal to awide audience cost-effectively”[11]
MHEG-5 is a open standard developed by the Multimedia and Hypermedia Ex-pert Group and has been approved and published by ETSI. MHEG-5 is designedto allow broadcasters to provide interactive services such as news, weather andcustomized EPGs into their broadcasts. In 2010 the standard was updated toinclude MHEG-IC (MHEG - Interaction Channel) to make use of services deliv-ered by an IP connection. These services include video-on-demand, traditionaltext and graphics, secure transactions among others.
The standard uses a customized object oriented language and MHEG-compatibledevices has to have a MHEG engine or virtual machine to be able to executeMHEG features. The MHEG-5 standard is deployed in United Kingdom, NewZealand, Hong Kong and Germany. The updated version MHEG-IC which isable to receive content from a broadband connection is however only currentlyin use in the UK[11].
23
3.3.3 MHP
The Multimedia Home platform is a collection of open interactive TV middle-ware specifications produced by the DVB project. MHP has been in developingsince 1997 and has been approved and published by ETSI. The latest releasedupdate named MHP 1.2 have support for contet delivered through both broad-cast and broadband channels and are able to offer internet services such asVideo-on-Demand and Pay-Per-View. The standard is based on the platformindependent language Java and all MHP compatible device need to have a Javavirtual machine present[17].
MHP can be considered a mature TV specification since it has been in use sincethe 90s and is developed by the DVB project. The biggest key market countriesare Korea, Finland, Italy, Austria, Spain among others.
3.4 Considered databases
3.4.1 SQL
SQL, or structured query language is a programming language used to manip-ulate and retrieve data from relational database management systems. Therelational database is built on a structured hierarchy using tables and rows.The advantages of SQL and RDBMS are that they are a well established solu-tion 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 describedbelow.
� 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 thedatabase is unchanged.
� Consistency - Only valid data will be stored on the database to preservethe consistency. If a transaction fails to meet the consistency requirementsa rollback must be done.
� Isolation - If transactions is done in parallel, they must not affect eachother.
� Durability - Guarantees that after a change in the database a user canassume 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 withfixed 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 isneeded which often is hard to achieve in a good way. RDBMS often provides ahuge set of functionality which normally is not used and this gives unnecessarycomplexity to simple programs. SQL has also got complaints that it has acomplex syntax which is hard to learn and that different database managementsystems use a slightly different semantic[6].
3.4.2 NoSQL
NoSQL is a fairly new concept and is an alternative to the well established SQLlanguage and relational databases. The big difference is how the data is stored.Instead of storing data in a predefined structure using tables and columns withfixed named and types, NoSQL stores data in “key/value”-pairs where a valuecan be complex and differ from other values with the same key. Attributesis defined dynamically in run-time making NoSQL more flexible compared toSQL. NoSQL databases also lack the guarantee of ACID rules which both is aadvantage and disadvantage.
The main advantage of a NoSQL database is the ability of horizontal scalabil-ity which is becoming a requirement in modern web-applications. Since datais stored without hierarchical structure the data is easily partitioned into sev-eral nodes in a cluster giving a linear scalability. NoSQL databases also offersflexibility in the meaning that database values are stored individually with norelation to each other and types is defined in run time. It also becomes morenatural to map application objects with the same structure in the database.Without complex relations between tables and complex join operations, dataaccess becomes faster than a relational database. The API used to manageand manipulate NoSQL databases is in the most cases easier to learn and usecompared to a SQL language. One would say that NoSQL gives up the ACIDrules 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 modifica-tions at a time. A NoSQL database lack consistency since single data may bestored with custom structure and attribute types. Isolation is not really neededsince data is not related and durability is not guaranteed by default. Moreresponsibility lies at the application developer to give application guaranteesprogramatically[6].
25
Chapter 4
Resulting prototype anddiscussion
In this chapter the chosen standard and why it was chosen is presented. Anoverview of the final design is presented followed by a detailed discussion of allincluding sub parts. How events could be sent in a live and non-live context isdiscussed at the end of this chapter.
4.1 Chosen standard
The new upcoming type of TV standards are so-called hybrid standards whichattempts to merge broadcasts, IPTV and broadband delivered content into asingle user interface on connected TVs and set-top boxes. Today’s TV platformsbarely spans over more than one CE manufacturers devices and a commonstandard that works on a wider audience of platforms would help developers tocreate TV-applications more efficiently and less costly.
The chosen standard is HbbTV due to the fact that it is the most promising andhave been deployed in a larger part of Europe compared to the other standardsconsidered [24, 15, 11, 17]. There have also been a trend that existing MHEGand MHP solutions has been converted into HbbTV solutions. One exampleis NorDig1, which is specifying a common platform for digital television in thenordic market. NorDig has been giving up their previous choice of MHP fortelevision interactivity to make use of the HbbTV standard instead[23].
The HbbTV specification is mainly based on broadly existing standards and webtechnologies. By doing this HbbTV is less hardware dependent than MHEG andMHP since most connected TV devices already has browser support. A MHEG
1http://www.nordig.org/
26
compliant device must have a custom object engine and a MHP compliant devicehas to have a Java virtual machine integrated. HbbTV application developmentis more or less like regular web page development and the time and cost ofapplication development could probably be reduced since a lot of competencealready exists in this area.
Hirsimaa did in 2011 an investigation[5] of how suitable HbbTV is as a futureplatform for connected TV devices and concluded that HbbTV has great po-tential. Minor flaws that was found during the research has been added andupdated into new releases of the HbbTV specification.
4.2 Final Design
The final design is based on tests, research and collaboration with Accedo. Tobe able to handle and generate events a web based management portal has beencreated. The portal is built with regular web technologies including HTML5,CSS and JavaScript. AJAX requests is used to communicate with the mainserver. For more details about the management portal, see section 4.3. Themain server is written in Java and uses a three layer architecture to make itmore modular and maintainable. To get a good structure a framework calledSpring MVC is used which is based on the common structure of models, viewsand controllers. For more details about the main server, see section 4.4. Eventsand user responses is stored in a document database called mongoDB which hasbetter speed and scalability compared to a relational database. For more detailsabout the database see section 4.5.
To be able to send asynchronous events from a server to clients in real-time asecond server has been added which uses WebSockets or long polling to simulatereal-time push messages. This server can easily be scaled horizontally as neededdepending on the number of expected users. For more details about the pushserver, see section 4.6. The client side is written with the HbbTV specification inmind and is implemented in JavaScript. AJAX Requests is used to communicatewith the main server and WebSockets and long polling is used to be able tosubscribe for live events. For more information about the client, see section4.7. All data sent between nodes in the system uses the JSON format and havedifferent structure and content depending on the purpose of the message. Formore 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 systemincluding a media server, a management system, a main server, a database, pushservers and a client.
4.3 Management Portal
To be able to manage and generate events from a content providers point of viewa management portal has been created. The choice was to do a application thathad to be installed locally on the computer or a web based application accessiblefrom a normal web browser. Without major researches the web based solutionwas chosen due to the flexibility with a browser and internet as the only tworequirements.
Safety aspects is important in a web based solution such as this. A final versionshould have a comprehensive log-in procedure using SSL encryption and HTTPSprotocols to ensure safety to the users. Usability and graphical design are twoother important aspects to take into consideration to make customers satisfied
28
with the product. The prototype produced in this paper has not prioritizedthese aspects and has focused on functionality.
The portal is build with standard web technologies including HTML5, CSS andJavaScript and uses AJAX requests to communicate with the main server tostore, 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 contentproviders but due to legal rights and agreements with Accedos customers videoinformation 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 howi could look like.
The portal consists of three types of pages, namely a login page, a list of videosand a detailed view of a single video where events can be managed. For screenshots see figure 4.2.
4.4 Server
The main part of the system is a server written in Java running on an apachetomcat server. The server handles AJAX requests from the management portaland TV clients and communicates with all nodes of the system. The languageJava was chosen based on personal comfort, a server written in .Net, Nodejs orsimilar would have worked just as well.
The server application is built with a modular three tier architecture in mindwhich consists of three layers: the user interface layer, the business layer andthe data layer. The top layer is a interface between the server and clients andis more or less just passing data between clients and the business layer. Thebusiness layer handles all logic and functionality of the server. The data layeris used to abstract away how data is manipulated. A modular structure makesit easier to change, test and maintain the system which is desirable in a largeproject such as this.
4.5 Database
Speed and scalability is two desired characteristics of a database that is storinga huge amount of data and serve data to a lot of users. The framework describedin this paper need to meet these requirements since a lot of events will be storedand a lot of viewers will retrieve and update values from the events. SQL andNoSQL has been considered and can be read more in detail in section 3.4.1 and3.4.2. MySQL and MongoDB has been chosen to represent SQL and NoSQLdue to practical reasons since both is free and well documented.
A test application has been implemented to compare characteristics betweenMySQL and MongoDB and can be read more about in section 2.2.1. Test resultsto 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 recordscompared to MySQL as seen in figure 4.3 and 4.4. If the result depends onMySQL or the widely used framework Hibernate cannot be concluded from thistest but some performance differences where expected since MySQL has muchmore safety features and ACID guarantees. This result was however not criticalin this particular application. The only users that will create and delete events
30
0 2,000 4,000
0
2,000
4,000
6,000
8,000
Number of entries
Tim
e(m
s)MongoDBMySQL
Figure 4.3: Time it takes to save acertain number of entries using mon-goDBwith the MontoTemplate frame-work and MySQL using the Hibernateframework.
0 2,000 4,000
0
0.5
1
1.5
·104
Number of entries
Tim
e(m
s)
MongoDBMySQL
Figure 4.4: Time it takes to delete acertain number of entries using mon-goDB with the MongoTemplate frame-work and MySQL with the Hibernateframework.
is the content providers and the pressure on the database should not be thathigh in that regard.
A more interesting characteristic is the time it takes to retrieve an entry fromthe database since this is where the pressure will be. As seen in figure 4.5, theresult differ by around a factor of 10 between MongoDB and MySQL whichis significant with millions of users requesting for data. In a small scale, suchas in this test, the time difference is in the size of milliseconds which will notbe noticed. To see a difference it has to be in a larger scale with many usersand 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 ina document database with the same data. One reason for this could be thateach document in a collection has to store each name of a name/value pairwhereas in a relational database there are fixed column names which only isstored once.
I have chosen to use MongoDB as database since it has better speed and scal-ability suitable for a applications with many concurrent users. Both theory insection 3.4.2 and performed perfomance tests verifies this.
31
0 2,000 4,000
0
5
10
Number of entries
Tim
e(m
s)MongoDBMySQL
Figure 4.5: Time it takes to find andretrieve an entry from a MongoDB andMySQL using a certain number of en-tries.
0 0.5 1
·104
0
0.5
1
1.5
2
Number of entries
Siz
e(M
B)
MongoDBMySQL
Figure 4.6: The total size of a col-lection in mongoDB and a table inMySQL having a certain number of en-tries.
4.6 Push Server
As discussed in section 3.1.4 there is a problem when the server program wantsto send an asynchronous real-time event to clients. To solve this an externalpush server has been added which will use one of the push technologies describedin section 3.1.4. The push server must in similarity with the database be fastand scalable to be able to serve a huge amount of clients concurrently withouttoo much latency.
Initial thought was to use TCP Sockets to establish a full duplex two-way-communication between the server and a client enabling message transmissionin real-time. TCP sockets are however not supported in JavaScript since it lackssupport to read raw byte streams. A workaround could be to use a Java servletwrapper or a Flash wrapper over the JavaScript which indeed do have TCPsocket support. This however adds complexity, puts more dependencies on theclient 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 hostingto connection handling. PubNub2 and Pucher3 are two popular pushnotification services among others.
� Use a free open source framework and adapt it to the project. Several
2http://www.pubnub.com/3http://www.pusher.com/
32
projects existed including the APE Project4, Nodejs5 with Faye6 andCometD7 among others.
� Develop a customized solution from scratch that is optimized for this par-ticular application.
To begin with the full-featured solution PubNub was tested. PubNub was ex-tremely easy to get started with and the provided framework API was compactand intuitive. The one and only disadvantage was that it was a quite expensivesolution and is billed by the number of messages sent and by daily peak connec-tions. Since it normally during a day is a small amount of viewer during the dayand a lot of viewers at the evening it would not be a beneficial type of billingsince you always get charged for the peak periods during the evening.
Secondly the open source framework Faye was used which is a publish/subscribesolution using WebSockets or long polling as push solution. The Faye frameworkis running on nodejs which is a lightweight server written in JavaScript. For aclient to be able to get live events into a specific video it just sends a subscriptionrequest to the push server including the unique video identification receivedfrom the media server. The push server holds the connection open and whenthe server receives an event message from the main server it sends the event toall client subscribing on that particular video identification.
This solution could easily be scaled horizontally with more servers as seen in fig-ure 4.7. The only new requirement is that the main server sends the publicationmessage to all the including push servers. Servers could be placed geographi-cally to reduce transportation latencies or use a load balancer to balance networktraffic.
Figure 4.7: Shows how the publish/subscribe push message solution easily could bescaled horizontally.
4http://www.ape-project.org/5http://www.nodejs.org/6http://www.faye.jcoglan.com/7http://www.cometd.org/
33
A test application that compares latency between WebSockets and long-pollinghas been implemented and can be read more about in section 2.2.2. It wasquite hard to test the latency in a large scale since browsers only have a smallamount of available persistent-http-connections which is needed to establish along polling connection. But as seen in figure 4.8 and 4.9 a significant differencecan be observed even in a small scale test. WebSockets would without a doubtbe the preferable push solution.
The reason why WebSockets is so mush faster is partially that long polling isusing the half-duplex protocol HTTP which first of all is not design to simulatea full-duplex connection and secondly have alot of unneccessary information inits header data for small messages compared to WebSockets. According to [26]WebSockets can provide a 1:500 or more reduction in unnecessary HTTP headertraffic which decrease network traffic and message latency. Assuming that theavarage value in figure 4.8 is increasing linearly from 5 client and forward, longpolling would be able to serve 310 client with an avarage value of 1 second whilewebsockets would be able to serve 1230 clients with the same assumption infigure 4.9. Keep in mind that this tests has been done on a general purposecomputer and may be different on a dedicated server computer.
0 10 200
50
100
150
Number of clients
Tim
e(m
s)
SmallestAvarageGreatest
Figure 4.8: Greatest, Smallest andAvarage latency to send a messagefrom the push server to a certain num-ber of clients using long polling.
0 10 200
50
100
150
Number of clients
Tim
e(m
s)
SmallestAvarageGreatest
Figure 4.9: Greatest, Smallest andAvarage latency to send a messagefrom the push server to a certain num-ber of clients using WebSockets
WebSockets is a quite new application protocol and do reqire HTML5 supportof the browser and HbbTV does not state anything about HTML5 support inits specification. Many modern browsers used in HbbTV compliant boxes dohowever have HTML5 support8 but the assumption that all HbbTV compliantboxes have that cannot be taken. The HTTP protocol is supported in theHbbTV specification[13] and the assumption that long polling works can be
8e.g. ANT Galio, Opera and NetFront Browser NX
34
taken. A good solution could be to primarily use WebSockets and downgradeto along-polling solution if WebSockets not are supported.
4.7 Client
The client side of the system is basically a small JavaScript module. The modulemust be included into your HbbTV project to be able to make use of the frame-work API. The main purpose of the module is to handle server communicationusing AJAX, Long polling or WebSockets.
Hardware used in connected TV devices is often minimal due to costs. Thereforit is not recommended to use structures and functions that consumes a lot ofCPU 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 ofthe original size by using closure compiler.
The framework API has been designed to be simple and intuitive and do onlyconsists of a small number of functions. The responsibility of presenting eventsin the GUI has been assigned to the application developer since GUI objectsand design often is application specific. The framework do only deliver eventobjects containing raw information about that specific event. It is then upto the application developer to display this content in a good way and callframework function when user interaction occurs. For a description of availableAPI functions see section 4.7.1
To illustrate how it could look like an simple HbbTV application has beencreated which are able to show static mp4 videos and a live HLS stream. Theframework has been integrated into the application and works as expected.Screenshots can be seen in figure 4.10.
9http://www.crockford.com/javascript/jsmin.html10http://dean.edwards.name/packer/11http://code.google.com/p/closure-compiler/
35
Figure 4.10: Screenshots showing a image advertising event, two question events anda statistics event.
36
4.7.1 Client framework
This section explains how to use the framework API and which functions areavailable.
How to include the framework
To use the framework API a JavaScript file has to be included into your HbbTVapplication as follows:
1 <script type="text/javascript" src="accedoEvents.js"></script >
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.getElementById(’video’);
� Declare a callback function that should be called on an event.
1 function myCallbackFunction(event)
2 {
3 //Do something
4 }
To initiate a new AccedoEvent object simply type:
1 var events = new AccedoEvents(video , myCallbackFunction).
Using AccedoEvent Object
Start and stop listening to live events for a specific video:
1 events.live.subscribe(videoId);
2 events.live.unsubscribe(videoId);
Start and stop listening to non-live events for a specific video:
1 events.nonlive.subscribe(videoId);
2 events.nonlive.unsibscribe(videoId);
Voting in a question event with a specific selection
1 events.registerAnswer(eventId , selection);
Generate a statistics event
1 events.getEventStatistics(eventId);
37
4.8 Event delivery
The ambition was to test event delivery through both an internet channel anda broadcast channel. During the pre-study there was proof that it is possibleto send applications and stream events merged into a normal broadcast MPEGstream. A broadcast stream is however not completely reliable and a streamevent is normally sent several times to higher the probability of message delivery.Live events do need a high delivery precisition, especially if there is moneyinvolved such as betting events. Events sent through a broadcast stream ishowever an interesting topic since it would lessen the burden on servers and beable to reach a wider audience which normally don’t use the internet featuresof modern set-top-boxes. Events delivered through a broadcast stream has notbeen tested due to lack of time.
This section is giving a suggestion on how events could be sent in a live andnon-live context using internet technologies and which data format and why thishas been chosen.
4.8.1 Event format
The JSON text format has been chosen to be used to interchange data betweenthe server and clients. JSON is a compact format, easy for both machines andhumans to interpret and is widely used in todays web applications. JSON isdescribed in depth in section 3.1.3.
Depending on the type of event that is transmitted, a JSON object containsdifferent attributes. By doing this the size of transmitted data can be reducedcompared to a universal event object that can hold all types of events. As anexample, 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 appli-cation with many simultaneous clients. By reducing the message size the totalamount of throughput is decreased leading to better latency times. The follow-ing example is to illustrate how small optimizes can make a huge impact.
Example: around 4 million people watched the swedish eurovision song contestin 2012[21]. Lets say that there was an average of 2 people per TV, giving a totalof 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 shorternames. The total amount of reduced network traffic was then:
T = 2 ∗ 106 ∗ 10 ∗ 10B = 200000000B ≈ 190MB
Remember that this is just one program with 10 events. With the full supplyof TV programs and more and more events being added over time, a reductionof 10 characters can be a significant amount of decreased network traffic in thelong run.
4.8.2 Events in a non-live context
In a non-live context event information is known from start and can easily behandled locally at the client side. At the beginning of a static video a simpleAJAX request could be generated to receive all event information for this par-ticular video. Event generation could then be handled locally by synchronizingevents with the time of the video player. This would lead to a reduction ofnetwork 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 contextsince events can be generated asynchronously. A discussion on how this couldbe solved is decribed in section 4.6.
39
Chapter 5
Conclusions, Future workand Improvements
The prototype has shown that event-driven interaction during TV programs canbe used advantageously. This chapter is presenting some final conclusions andlists some potential improvements and future work.
5.1 Conclusions
Based on the prestudy and observations from the prototype, event-driven in-teractivity during application based TV-programs can by advantage be used toenhance the user experience. There are however some practical problems thathas to be solved.
One of the greatest difficulty of TV interactivity is to convince content providersto add more interactive content into their broadcasts and argue how that willgenerate more profit for them. Without this content the interactivity becomesmeaningless since the content providers own all rights to thier broadcasts. Itis also difficult to find a balance and not overhelm viewer with to many eventsmaking them irritated and uninterested. All viewers are probably not interestedin all interactive features and a possibility to disable parts of the interactive ser-vices should be provided. One idea of improvement is to synchronize a secondaryscreen such as a tablet or phone with the TV and let events be generated onthat 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 elimi-nation shows, answers questions that are furthered discussed in a live program
40
among other things. People likes to get involed using social medias and thiscould be an additioan way to get involved.
In a non-live context viewers watch movies and TV-series and would probablynot want to be disturbed while doing that. Potentially events could be generatedafter e.g. a movie but would probably already have been closed by then. Adver-tising events could however be interesting to finance the videos. Several goodframeworks already exists though, such as [29], to enable advertsing featuresand the wheel should not be invented twice.
HbbTV is an easy platform to work with and it has a lot in common with regularweb development. The main difference is the HbbTV API used to make HbbTVspecific tasks more convienient. The firefox plugin FireHbbTV is a good testemulator during the development of an HbbTV application.
It is still obvious that HbbTV is an immature standard. Available example ap-plications are limited and API documentation is more or less non-existent. TheSTB used was HbbTV complient but only had some of all HbbTV functionalityavailable making it hard to rely on HbbTV specific functions. Hopefully thiswill change in the future and Accedo are currently notice a high demand ofHbbTV application solutions especially from the German market. Comparedto similar standards HbbTV predicts a bright future.
5.2 Improvements
5.2.1 Graphical improvements
Both the management portal and the client event presentation must be updatedwith graphical interfaces designed to enhance usability and use a modern style.The managment portal could possibly be redesigned to easier be able to findparticular videos. In a live context it would be advantageous to see the videostreamed in the browser to easier moderate live event handling. A particulartool for image and video manipulation could be added to simplify image andvideo advertising.
5.2.2 Optimizations
More extensive profiling should be done to detect and fix bottlenecks of thesystems. The amount of data sent should be investigated furthered and beminimized to decrease network traffic. Some optimizations has been consideredbut there are still optimizations to be done.
41
5.3 Future work
5.3.1 Receive real video content
The prototype uses only simulated videos and video information to illustratehow a final solution might look like. More interesting would be to get videocontent from a real content provider and build up the management portal us-ing this huge amount of data. This would lead to new requirements includingsearch tools to find specific videos more easily. The security must however beimproved to make use of HTTPS and SSL descryption before real content couldbe 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 differ-ent projects and a customized solution could potentially generate better per-formance. Since the push server is a critical part of the system it would beinteresting 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 aDVB broadcast stream. Hirsimaa[5] has done tests to send stream events intoa HbbTV application. The conclusion was that there was too much latency buthe did not know if it did depend on the DVB channel or if it was bad hardwarein the set-top box. With the motivation that content delivered through thebroadcast stream would reduce network traffic and lessen the burden on serversit 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 soultioncould be to synchronize a secondary screen such as a tablet och phone with theTV and let events be generated that screen instead. A phone or tablet havemuch more CPU power and screen resultion wich can be used to enhance visualeffects. 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 Hoglin, Event-driven interactivity in IPTV, DIVA 2011.
[3] Jon-Henrik Bruksas et al, Push-teknik pa webben, DIVA 2010.
[4] Engine Bozdag, Push solutions for AJAX technology, DIVA 2007.
[5] Christoffer Hirsimaa, HbbTV - The application standard for TV broadcast-ers, DIVA 2012.
[6] Natalia Soderberg, 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/, [On-line; accessed 2012-10-01].
[10] DVB, DVBs official homepage, http://www.dvb.org/, [Online; accessed2012-10-08].
[11] IMPALA, MHEG official website, http://www.impala.org, [Online; ac-cessed 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-10-02].
[16] THM A beginners guide for MPEG-2 standard, http://www.fh-friedberg.de/fachbereiche/e2/telekom-labor/zinke/mk/mpeg2beg/beginnzi.htm, [On-line; 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-10-24].
[21] SVT, Sa manga sag direktsandningen av melod-ifestivalen i SVT1, http://www.svt.se/melodifestivalen/halva-sverige-sag-loreen-vinna-melodifestivalen-2012, [Online; accessed2012-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/, [On-line; accessed 2012-11-14].
[24] Broadband TV news, News article aboutHbbTV, http://www.broadbandtvnews.com/2012/05/24/hbbtv-sweeps-interactive-tv-across-europe/, [Online; accessed 2012-10-02].
[25] ISO Information technology generic coding of moving pictures and associ-ated audio information part 6: Extensions for dsm-cc, http://www.iso.org/iso/iso catalogue/catalogue tc/catalogue detail.htm?csnumber=25039, [On-line; accessed 2012-11-14].
[26] WebSocket.org HTML5 Web Sockets: A Quantum Leap in Scalability forthe Web, http://www.websocket.org/quantum.html, [Online; accessed 2012-11-15].
[27] IETF The WebSocket Protocol, http://tools.ietf.org/pdf/rfc6455.pdf, [On-line; 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 communi-cation
� 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