HYBRIDCAST: A NEW MEDIA EXPERIENCE
`BY INTEGRATION OF BROADCASTING AND BROADBAND
`
`Hisayuki Ohmata, Masaru Takechi, Shigeaki Mitsuya, Kazuhiro Otsuki,
`Akitsugu Baba, Kinji Matsumura, Keigo Majima, and Shunji Sunasaki
`
`Science & Technology Research Laboratories
`NHK (Japan Broadcasting Corporation), Japan
`
`ABSTRACT
`
`Broadcasting has a role for the public service. Providing
`the same information to a large number of people at the
`same time has benefitted modern society in many ways,
`including presenting the forefront of lifestyle trends,
`offering dependable media during disasters and cost-
`effective transmissions. On the other hand, services over
`the Internet satisfy the individual’s needs as seen in
`customization for each, interactive communication and
`user-generated media. NHK is developing “Hybridcast”, a
`service platform integrating broadcasting with the Internet.
`This platform can enhance broadcasting programs and
`provide other various services by the best mix of features of
`both media. This paper describes the system and examples
`of service on Hybridcast for the general public including
`minority viewers. The next-generation media
`for a
`sustainable society will emerge from Hybridcast which is
`expected to be launched in 2013.
`
`Keywords— Hybridcast, Interactive Broadcast Broadband
`System, Multi-screen Service, HTML5
`
`1. INTRODUCTION
`
`The digitization of broadcasting and the rapid spread of
`broadband environment have
`led
`to an
`information
`infrastructure
`that
`provides
`high-quality
`digital
`broadcasting and a variety of Internet services. A new era
`will soon dawn when broadcasting and the Internet will
`work together seamlessly to provide new services. NHK is
`developing “Hybridcast”[1] for a new era expected to
`launch in 2013.
`Broadcasting guarantees a quality of service (QoS) and an
`efficient delivery of content to a large number of viewers,
`whereas Internet systems afford the flexibility to deliver
`personalized content that meets an individual viewer’s
`preferences. NHK has been contributing to both technical
`and service developments for combining broadcast and
`Internet for a
`long
`time,
`taking
`into account
`their
`complementary characteristics, i.e., the efficient delivery of
`high-quality content on a large scale and the delivery of
`services tailored to a user’s preferences, respectively.
`Hybridcast is one of the hybrid broadcasting systems to
`combine
`broadcasting
`and
`network
`functionalities
`seamlessly. A hybrid broadcasting system accepts wide
`range of services. In general,
`the services can be
`categorized into following two types;
`
`a) Broadcast-related services
`These are services strongly tied with broadcasting
`programs or content. For example, the services are
`intended to add more information to broadcasting
`content to enhance it. Though interactive TV services
`and data broadcasting have provided similar features,
`hybrid broadcasting
`systems offer much wider
`flexibility because network
`connectivity
`allows
`handling much more data than broadcasting channels
`and offering what individuals need, such as video-on-
`demand.
`
`b) Independent services
`Like services on a smartphone such as Social Network
`Services (SNS) or games, independent services are not
`related to broadcast programs or content.
`
`In hybrid broadcasting systems, the flexibility of the
`systems allows, for broadcast-related services, to provide
`additional content elements to make the broadcasting
`programs or content understandable better for every kind of
`people including the elderly, people with disabilities and
`minorities. The
`flexibility
`also
`allows
`important
`independent services to take care of every kind of people
`such as e-health.
`Hybridcast is the service platform to enable such services
`and to bring new TV experience for all viewers. This paper
`describes the examples of services, its system concept and
`its architecture.
`
`2. SERVICES ON HYBRIDCAST
`
`Some example services on Hybridcast have been developed
`to verify system functionalities. Accessibility improvement,
`provision of better presentation of the event from many
`aspects, and protection of life and properties of people are
`taken into account for the examples. In this chapter, such
`broadcast-related example services are described.
`
`2.1. Multilingual Closed-captioning Service
`
`According to Japanese digital broadcasting standard, closed
`caption can be provided for up to two languages within a
`broadcast channel. Two languages may not be enough for
`some people including minority or foreign travelers.
`Broadcasting service will target majority in language firstly
`because broadcasting system is a system to deliver the same
`information to mass viewers very efficiently. If a viewer
`would like to watch closed caption in a language not
`
`Authorized licensed use limited to: McGill University. Downloaded on November 09,2023 at 17:17:04 UTC from IEEE Xplore. Restrictions apply.
`
`978-92-61-14061-8/CFP1338E-ART © 2013 ITU
`
`Kaleidoscope
`
`Genius Sports Ex. 1026
`p. 1
`
`

`

`delivered over the broadcast channel, the Internet can be
`used to deliver closed caption data in the preferred language.
`Hybridcast has a broadcast-broadband synchronization
`mechanism which enables the synchronization of various
`types of streams from multiple sources. The closed caption
`server feeds time-stamped caption data in the requested
`language and they are presented synchronously with the
`broadcast program.
`Figure 1 shows an example image of this service. In Figure
`1, seven languages are available. A viewer selects the
`preferred language by using a remote controller, and closed
`caption in selected language is on the screen. Under some
`conditions, the service provider may offer “user generated
`closed caption” which can extend the language selection.
`By this service, closed caption service even in minor
`languages can be available without buying a dedicated
`receiver so that the people can get information through TV
`set in understandable or preferred language.
`
`
`
`
`Language
`selection menu
`
`Closed captions delivered
`from broadband
`
`
`
`Figure 1. Multilingual closed-captioning service
`
`
`2.2. Sign Language Animation Service
`
`Closed caption is provided with many TV program in Japan.
`Although this is a useful service for the deaf, there is a need
`to provide another type of the service to them. For some
`people, textual representation is something like a foreign
`language and the so-called mother-tongue is the sign
`language. In case of an emergency, provision of sign
`language interpretation to broadcasting program is a critical
`issue for such people. Reflecting the situation, there is a
`strong demand from the deaf community for sign language
`interpretation to broadcasting programs. However, few TV
`programs are broadcast with a sign language service for the
`deaf. The reason of being is the insufficient number of sign
`language interpreters. And probably they will not be
`available for an emergency broadcasting program at
`midnight. Considering that the availability of sign language
`interpreter will not be improve soon, it is important for the
`deaf community to make sign language interpretation
`available at all times even in alternative ways.
`For this purpose, NHK is developing a technology to
`generate sign language Computer Graphics (CG) animation
`by using TVML (TV program Making Language)[2]. The
`combination of this technology and Hybridcast can provide
`sign language animation services.
`It is important for broadcasting service compatibility of
`sign language interpretation for people who want and who
`don’t want the service. Sign language interpretation should
`
`be switchable at the receiver side, and video image of sign
`language interpretation should not be overlaid at the
`broadcast stations. So, video image of sign language should
`be delivered independently from the broadcasting video
`image. However, normally broadcast channel is fully
`occupied by regular broadcasting data and there is no space
`in broadcast channel to provide switchable animation video
`images.
`When using Hybridcast, sign language animation video
`images can be delivered over the Internet. The Hybridcast
`application for CG sign language running on a receiver
`requests additional video
`images of sign
`language
`interpretation, and by using
`the broadcast–broadband
`synchronization mechanism, a sign language animation is
`presented synchronously with broadcast program (Figure 2).
`Because TVML technology can generate sign language
`animation from textual scripts, emergency information can
`be provided in sign language even at a time when human
`sign language interpreters are not available. This will help
`the deaf to evacuate or take an appropriate action in case of
`an emergency.
`
`
`Broadcast Program
`
`
`
`Sign Language Animation from Internet
`Figure 2. Sign language animation service
`
`2.3. Multiangle Camera Service
`
`Many of the TV programs use multiple cameras during
`production and each camera shoots different objects or the
`same object from different angles. It is quite normal for
`broadcasters to select one of the images as a part of the
`program production process. On the other hand, viewers
`may sometimes want to watch the image from another
`camera. Sports or music program may be typical programs
`for such needs. For example, during watching a jazz live
`program, a viewer is interested in each player, on piano,
`drum, bass, sax and so on. Watching the object on a TV set
`from multiple angles helps viewers to understand the
`ongoing event better. Hybridcast with the application for
`multi-angle satisfies the needs.
`This service provides videos of multiple cameras over the
`Internet. Basic mechanism for synchronization of two video
`images is the same as for the two services above. The
`Hybridcast application running on a receiver allocates
`multiple video images and, in some cases, the selected
`image can be enlarged by the application. Figure 3 shows
`an example of a screen image for the service.
`
`
`Authorized licensed use limited to: McGill University. Downloaded on November 09,2023 at 17:17:04 UTC from IEEE Xplore. Restrictions apply.
`
`2013 ITU Kaleidoscope Academic Conference
`
`Genius Sports Ex. 1026
`p. 2
`
`

`

`Broadcast Program
`
`Synchronized
`in frame-rate
`accuracy
`
`Video of Multiangle Camera
`(via broadband)
`
`
`
`Figure 3. Multiangle camera service
`
`
`2.4. Language Study Service
`
`Providing an educational broadcasting program is one of
`the important elements of a public service. A language
`study program is a typical example of this. Hybridcast can
`provide a language study service with a secondary screen
`device (Figure 4), which contributes an efficient and
`effective education. An application on a tablet is used to ask
`questions about conversation in the program. Viewers can
`answer the questions using touch controls.
`Synchronization of the application on the tablet is achieved
`by using a trigger signal within a broadcast channel and
`multiple-device linkage function in the Hybridcast receiver.
`A broadcaster sends the trigger signal when asking a
`question. Once the application on a TV set receives the
`trigger, it tells the application on the tablet to acquire data
`of the question over the Internet and to start asking it.
`Such a mechanism and user interface of a tablet may
`introduce viewers to new experience of language learning.
`Especially, touch interface makes learning fun and viewers
`may not get tired quickly.
`Use of the secondary screen device as an interactive text
`book can be applied to other subjects of education. It will
`allow reviewing the matters of wrong answers later very
`easily, and help effective learning.
`
`
`Language Program
`(Broadcast)
`
`Secondary Screen Device
`
`WiFi
`
`Hybridcast Receiver
`
`Application for
`Language Study
`(from Internet)
`
`Figure 4. Language study service
`
`
`
`
`
`
`
`
`
`2.5. Social TV Service
`
`One of the highlights of TV viewing is to spend time and
`discuss with family or friends while watching TV programs,
`especially in live broadcasts. It is quite natural to do so
`when a family shares the single TV set and watches the
`same program together. By integrating with an SNS,
`Hybridcast enables people who are not in the same location
`to share the feelings as if they were nearby. It is so-called
`Social TV[4].
`Figure 5 shows a chat application example. It lists friends
`who are watching the same program on top-right of the
`screen by icon. On the bottom-right, chat messages are
`displayed.
`The Hybridcast application manages the login status of
`SNS and watching status of the program. The application
`obtains
`the ID of program from
`the receiver. The
`application then sends the ID of program to the server for
`the SNS. The friends or family who are logged in and have
`registered the same ID of program become chat members.
`Thus, Social TV service can create a virtual space for TV
`experience and overcomes physical distance among friends
`or family.
`
`
`Other Viewers Watching TV Simultaneously
`
`Viewer’s Comment
`Figure 5. Social TV service
`
`
`
`
`2.6. Prioritized Presentation of Important Information
`
`One of the important roles of broadcasting service is
`providing emergency information to viewers accurately and
`quickly as much as possible. This is one of the primary
`functions of broadcast to communities in case of an
`emergency. In Japan, the government deployed alert
`systems against large earthquakes and tsunamis. When
`broadcasters receive emergency information from the
`authorities, they have to provide this information to viewers
`as quickly as possible[5][6]. These systems greatly helped
`to escape from the disaster when the Great East Japan
`Earthquake occurred in March, 2011.
`This characteristic of broadcast has to be maintained in
`Hybridcast as well. However, in Hybridcast, two kinds of
`media share on one TV screen: broadcast video and
`applications from the Internet, which may be independent
`each other. If emergency information is broadcast and
`overlaid information onto the broadcast video hides some
`pieces of information provided by the broadcasters, there is
`a risk that viewers may miss the important information.
`
`Authorized licensed use limited to: McGill University. Downloaded on November 09,2023 at 17:17:04 UTC from IEEE Xplore. Restrictions apply.
`
`Building Sustainable Communities
`
`Genius Sports Ex. 1026
`p. 3
`
`

`

`3.2.1. Compatibility with existing broadcasting system
`
`Hybridcast system should be compatible with existing
`broadcasting systems. In Japan, total shipments for DTV
`(Digital Television) receiver are over one hundred million.
`It is impractical to introduce new incompatible broadcasting
`systems dedicated to Hybridcast. In addition, coexistence
`with a data broadcasting service
`is required. Data
`broadcasting services are widely used and popular. In some
`cases, it is necessary to start Hybridcast service from a data
`broadcasting service, and vice versa.
`
`3.2.2. Application management
`
` viewer can experience various services through the
`Hybridcast application. This means methods to start and
`stop the application is essential to the Hybridcast system.
`For example, when a viewer wants to participate in a quiz
`show using a Hybridcast application, the application should
`start at the time of the broadcast program automatically,
`and stop at the end of the program automatically. On the
`other hand, there is an application which is independent
`from a broadcast program such as weather forecast
`application. This kind of applications should start under the
`instruction by the viewers at any time, and stop similarly.
`The application management mechanism in Hybridcast
`should satisfy these different start and stop scenarios.
`
`3.2.3. Broadcast resource access
`
`The close combination of broadcast and application enables
`the creation of a new TV experience. Hybridcast
`applications should be able to access broadcast resources
`such as video, audio and metadata and to use them TV
`functions such as tuning to new channel. However, access
`to those resources should not affect the content integrity of
`the broadcast.
`
`3.2.4. Receivers
`
`The receiver is one of the key equipment to build the
`services on the Hybridcast platform. The receiver finally
`makes presentation, provides interactivity for viewers,
`handles various control signals, and offer functionalities to
`the application. If the receiver provides multiple video
`decoders, it will allow the service to combine multiple
`video images on the same screen.
`Various smart devices such as tablets and smartphones
`using user-friendly interface have become popular. On
`Hybridcast, these devices should be available as a remote
`controller and a screen for displaying information. To use
`such devices as ‘companion devices’, it is essential for a
`receiver to equip link and communication mechanism to
`them.
`
`3.2.5. Security
`
`Introduction of the third-party service providers will make
`the range of services wider. Service expandability is a
`fundamental factor of the system concept of Hybridcast as
`
` A
`
`Especially, earthquake alert is broadcast a few seconds
`before the quake hits. There is no time to manipulate
`something by the viewers. The time remaining may be
`comparable to watching the screen and understanding what
`is going to happen.
`A presentation control in Hybridcast will be engaged to
`reduce
`such
`risks[7]. Figure 6
`shows prioritized
`presentation of broadcast program which conveys
`emergency information. A receiver continuously monitors
`broadcasting signal to detect emergency signal information
`embedded in it. As soon as such a signal is detected, the
`receiver controls to enlarge the broadcast video to full-
`screen and removes the application which is running from
`view. After the signal is turned off, the former layout is
`resumed.
`
`
`Signal of Emergency Information
`!
`
`Application
`From the Internet
`
`Emergency Information
`from Broadcasting
`
`緊急地震速報
`
`Application is made invisible to give space to emergency information
`Figure 6. Use case of the presentation control
`
`
`
`
`
`3. PLATFORM DESIGN
`
`
`3.1. System Concept
`
`These services are just the tip of the iceberg and so many
`services that we cannot count will emerge on Hybridcast.
`Provision of flexibility and service expandability to build a
`variety of services is the most important characteristics for
`the Hybridcast platform. Application-oriented approach and
`introduction of various players, not only broadcasters but
`also third-party service providers, into the overall system
`are keys to offering a diversity of services .
`
`3.2. System Requirements
`
`As a first step for system development, the system
`requirements are determined based on an analysis of the use
`cases. Most of the requirements derived as a result of the
`analysis
`are
`consistent with
`those
`defined
`in
`Recommendation ITU-T J.205, “Requirements for an
`application control framework using integrated broadcast
`and broadband digital television”. Among the requirements
`of Hybridcast system, five of the most fundamental
`requirements are described below.
`
`
`Authorized licensed use limited to: McGill University. Downloaded on November 09,2023 at 17:17:04 UTC from IEEE Xplore. Restrictions apply.
`
`2013 ITU Kaleidoscope Academic Conference
`
`Genius Sports Ex. 1026
`p. 4
`
`

`

`described in chapter 3.1, and Hybridcast welcomes third-
`party service providers. However, security level of third-
`party application or services may vary for the each
`application or service. From this viewpoint, security feature
`of Hybridcast
`is more
`important
`than for existing
`broadcasting systems.
`The security mechanism in Hybridcast platform should
`protect interests of stakeholders including broadcasters and
`viewers. For viewers, unintended access to personal
`
`
`
`information by the application is one of the risks. For
`broadcasters, unauthorized overlaying of graphics or text
`onto broadcast video by the application breaks content
`integrity. The security mechanism to take control of access
`to the information or behavior of the application in proper
`manner will bring safety and comfort to stakeholders, so
`that more service providers will offer the services, or more
`viewers enjoy the services.
`
`Broadcasting
`(high-quality, high-reliability, simultaneity)
`
`Ensuring backward
`compatibility
`
`Broadcast
`Station
`
`Broadband communication
`（responds to individual viewer request）
`
`Enriched program
`for viewers
`Hybridcast receiver
`Application
`Broadcast
`execution
`program
`
`Additional program-related
`content
`
`
`
`Network (cloud)
`Providing additional
`content and functionalities
`
`Request, SNS,
`UGC
`
`Synchronized
`presentation
`Security
`Management
`Home
`Figure 7. Conceptual diagram of Hybridcast
`
`
`Device linkage
`
`
`
`4.2. APIs – Interfaces between Three Entities –
`
`One of the main features of Hybridcast platform design is a
`structure of the three entities: broadcaster, service provider
`and receiver (Figure 8). Each entity provides a specific
`function
`to other entities via APIs
`(Application
`Programming Interfaces). In other words, among these
`three entities, API is a “grew” to exchange information and
`request processing information or media content.
`APIs in broadcaster side makes it easy to access to them by
`service providers. Authorized service providers, including
`third-party, will access broadcast data through the APIs,
`creating their services, and offer them to the viewers. APIs
`in broadcaster side can be defined by broadcasters
`themselves; Common APIs at broadcasters for services
`providers will reduce complexity and required investment
`to provide actual services by service providers. The
`common APIs will be effective when many service
`providers offer broadcast-related services. Opportunity for
`the third-party service providers to offer their services on
`the platform is expected to expand the range of services as
`well as those by broadcasters. Hybridcast may not only
`encourage developing new business models for public, but
`also support to provide various services for minority.
`APIs in a receiver have to be standardized to offer built-in
`functionalities of a receiver to all Hybridcast applications.
`Standardization of receiver APIs and a format of
`application signaling is carried out at IPTV FORUM
`JAPAN for the Hybridcast system.
`
`
`4. SYSTEM ARCHITECTURE
`
` A
`
` conceptual diagram of the Hybridcast is shown in Figure
`7. The platform consists of the existing broadcasting system,
`additional servers in the cloud, and Hybridcast receivers.
`The receiver functionalities include application execution,
`the handling of broadcasting resources, multi-device
`linkage, content synchronization and security management.
`
`4.1. System Overview
`
`To build such a platform, we designed a simple system
`architecture. The Hybridcast system utilizes the existing
`broadcast system as much as possible. Figure 8 shows the
`network part of Hybridcast’s basic system architecture. The
`system consists of three blocks: broadcaster servers, service
`provider servers, and receivers. The broadcaster servers
`provide broadcast content and content-related information,
`which only the broadcasters hold, to the service provider
`servers. The service provider servers provide applications,
`content, and relevant information to the services or end
`users. Hybridcast receivers execute applications to realize
`various services. Such an application-oriented approach
`enables a rather simple receiver-side implementation.
`Hybridcast applications running on a Hybridcast receiver
`process the content and relevant information obtained from
`the service provider servers. The applications on a receiver
`can access to required information from broadcast and the
`network, and call functions. Service providers are not only
`broadcasters but also third-party service providers.
`
`Authorized licensed use limited to: McGill University. Downloaded on November 09,2023 at 17:17:04 UTC from IEEE Xplore. Restrictions apply.
`
`Building Sustainable Communities
`
`Genius Sports Ex. 1026
`p. 5
`
`

`

`Broadcast Station
`
`Broadcast program
`・Application signaling
`
`Receiver
`
`App
`API
`Receiver’s
`functions
`OS / HW
`API
`Link
`
`Hybridcast
`receiver
`
`Service provider
`servers
`
`Download
`
`API
`
`App. repository
`AppAppApp
`App-related
`service
`Content
`delivery
`DB
`・User info.
`・Content info.
`・service-related info.
`・etc.
`
`Broadcaster servers
`
`API
`
`・Content Management
`・Content delivery
`・Security
`・etc.
`
`DB
`・Content info.
`・program-related info.
`・etc.
`
`Common platform
`(to be defined as
`a common specification)
`Service dependent system
`(to be created for each service)
`
`Transport
`format
`
`App
`
`App
`
`PC
`
`Mobile
`
`
`
`Figure 8. System overview
`
`
`5. APPLICATION MODEL
`
`
`Using Hybridcast, viewers can experience various types of
`services
`through Hybridcast applications. Considering
`services offered in Hybridcast, there are several types of
`applications which execute on the receiver.
`Hybridcast applications are categorized as either broadcast-
`related or independent. For example, the application used
`for a quiz show should work together with the broadcast
`program. On the other hand, a weather forecast application
`is used independently from a broadcast program. As seen in
`these examples, there are several different application
`lifecycles, i.e. when to start and when to stop the
`application, depending on
`the application
`type. The
`lifecycle of a broadcast-related application should be
`controlled by a broadcast signal to associate with the
`program, while that of independent applications should be
`controlled by the viewer. A receiver provides an application
`launcher that creates an application catalogue for choice of
`independent applications. If a viewer wants to use such an
`application, all he or she needs to do is to start the launcher
`and choose the desired application.
`
`
`6. HYBRIDCAST RECEIVER
`
`
`The utilization and management of the application are
`directly linked to the user experience, because Hybridcast is
`application-oriented system. In this chapter, the basic
`architecture of the receiver, application management the
`mechanism and unique functions of Hybridcast are
`described.
`
`6.1. Architecture
`
`is chosen as application environment
`HTML5[8]
`Hybridcast. There are three reasons to use HTML5.
`
`in
`
`(1) Easy implementation. A number of TVs and portable
`devices provide
`a Web browser. So, basic
`functionalities to handle HTML5 are naturally built-in
`these devices.
`(2) High functionality and high efficiency. Using CSS3
`(Cascading
`Style
`Sheets,
`level3)
`and Ajax
`(Asynchronous JavaScript + XML), applications with a
`rich interface and functionality can be easily developed.
`(3) There are significant support to use HTML5 from many
`broadcasters and TV manufacturers.
`
`
`By these reasons, HTML5 is adequate for Hybridcast on
`consumer electronics devices such as TV sets.
`
`
`Extension for Hybridcast
`
`Data
`Broadcasting
`
`BML
`Browser
`
`Hybridcast Applications
`APIs
`HTML5 Browser
`
`Application
`Manager
`
`Middleware
`Broadcast Resources
`(with TV functions)
`
`Hybridcast Functions
`Synchronization
`Multiple-device Linkage
`Access Broadcast Resources
`Presentation Control
`
`Hardware (Tuner, Decoder, I/O, …), OS
`
`
`
`Figure 9. Architecture of a Hybridcast receiver
`
`
`Figure 9 shows the layer architecture of the Hybridcast
`receiver.
` The receiver consists of four layers: the
`application, browser, middleware, and hardware. A typical
`Japanese DTV receiver supports data broadcasting services
`using BML (Broadcast Markup Language). A Hybridcast
`
`Authorized licensed use limited to: McGill University. Downloaded on November 09,2023 at 17:17:04 UTC from IEEE Xplore. Restrictions apply.
`
`2013 ITU Kaleidoscope Academic Conference
`
`Genius Sports Ex. 1026
`p. 6
`
`

`

`broadband shall provide time-stamp information so that the
`receiver can determine a synchronization point of the
`broadcast stream. By comparing time stamps of both
`streams, the receiver can adjust the time of presentation
`properly.
`For a live broadcast program, larger buffers in a receiver
`are required since the additional data to be transmitted
`through broadband cannot be prepared ahead of time. The
`size of the buffer should be long enough to compensate for
`a lag in the broadband-delivered content. Actual buffer size
`will be determined by investigation of network latency.
`
`
`Broadcast program
`(MPEG-2 TS)
`
`CL
`
`PTS
`
`PTS
`PTS
`
`
`
`or
`Additional content
`(MPEG-2 TS)
`(streaming video/audio etc.)
`
`Tuner
`
`Buffer Decoder
`
`Video
`
`PTS
`Re-synchronization
`by matching PTS
`PTS
`IP
`reception Buffer Decoder
`
`
`
`Audio
`
`Shared System clock
`
`
`
`Broadcast
`Station
`Figure 10. Synchronization mechanism
`
`Receiver
`
`
`6.4.2. Multiple-device linkage
`
`As the number of functionalities of broadcasting services
`and TV sets is increasing, remote controllers become more
`complicated. Instead of enhancing the functions or buttons
`on existing remote controller, use of alternative devices
`with user-friendly interface is one of the practical solutions
`for advanced services. Touch devices such as tablets or
`smartphones are typical devices for the usage and have
`emerged and spread rapidly. These devices have not only
`user-friendly interface, but also enhanced functionality of
`presentation of information, which contributes to the
`improvement of accessibility to all the viewers. Hybridcast
`provides multiple-device linkage function for this purpose.
`Figure 11 shows how the applications on the secondary
`screen devices interact with the application on TV set
`through WiFi or a home network. The underlying
`mechanism of API’s on a TV set and the secondary screen
`devices controls communication across the devices and
`allows communication between
`the applications. For
`example, when a viewer changes the channel using an
`application on secondary screen device, the application
`sends the message to the application on TV set. The
`application on the TV calls the API to tune to the new
`channel.
`
`
`receiver is equipped with a BML browser in parallel to a
`HTML5 browser. The middleware layer handles broadcast
`resources. Application manager
`is
`introduced
`for
`controlling applications on an HTML5 browser. Various
`functions are also
`implemented
`in middleware
`for
`broadcast-broadband combination and presentation control
`for emergency broadcasting. In case of emergency, the
`HTML5 browser is controlled by presentation control
`function to stop exhibition of the applications. Standardized
`APIs are prepared between an HTML5 browser and a
`Hybridcast application so that Hybridcast applications can
`use these functions easily.
`
`6.2. Application Manager
`
`The application manager controls the start and stop of
`applications. To allow program-related applications to work
`together accurately with a broadcasting program, the
`manager consistently monitors
`the control signal
`in
`broadcast channel. On the other hand, the manager also
`starts and stops independent applications at any time by
`viewer’s manipulation. When starting an application, the
`manager
`instructs
`the HTML5 browser
`to
`load
`the
`application from the location represented in URL in the
`control signal. When stopping an application, the manager
`also instructs the HTML5 browser to terminate it.
`
`6.3. Security Control
`
`Hybridcast is an open platform where third-party service
`providers offer their services. As discussed in 3.2.5, open
`platforms have potential security risks such as application
`tampering and leakage of privacy[9]. Improper access to
`broadcast resource is another potential security risk, which
`may break copyright. It is important to make the system
`compliant to fixed rules to protect rights of each entity.
`In Hybridcast receiver, many functional blocks provide
`their own security features. These features work together to
`satisfy the system requirements for security. According to
`execution context of the application, each block is designed
`to consult other relevant blocks for eligibility of access to
`security sensitive resources such as broadcast signal or non-
`volatile memory potentially containing user information.
`
`6.4. Unique Functions of Hybridcast
`
`6.4.1. Broadcast-broadband synchronization
`
` broadcast–broadband synchronization function allows an
`application
`to
`present
`timed
`content
`elements
`synchronously[10]. Figure 10 shows the typical mechanism
`of this function. This function synchronously presents
`timed components delivered from different channels, such
`as video, audio, and closed captioning. A broadcast signal
`can be considered as a stable and acc