Hybridcast: Technical Specifications and Recent Progress NHK launched Hybridcast in September, 2013. Hybridcast, which uses HyperText Markup Language 5 (HTML5) as an application language to combine broadcast and broadband functionalities channels, currently provides the latest news, weather, and sports to televisions supporting this system. Moreover, we are planning on starting other Hybridcast services, such as interactive programs and video on demand (VoD). In this article, we discuss the technical specifications of Hybridcast and possible extensions to enable it to support new services. 1. Hybridcast Technical Specifications The first version (Ver. 1.0) of the Hybridcast Technical specifications is defined by the IPTV Forum Japan (hereinafter, IPTVFJ) *1 and Association of Radio Industries and Businesses (ARIB) standards 1)2)3). The technical specifications of IPTVFJ stipulate the system model, application model, receiver functions, and HTML5 *1 IPTV Forum Japan: The standardization body setting IPTV related domestic standards in Japan. extension APIs *2 and deal mainly with the functionalities and models of the broadband part. The ARIB standards stipulate the application control signal formats and deal with the parts related to broadcast signals. 2. Hybridcast System Model Hybridcast provides services that combine broadcasting and broadband functions. In order to promote and diversify the services that can be offered over broadband network, its service model (Figure 1) is one in which service providers are not limited to broadcasters. In Figure 1, a broadcaster provides control signals for starting or stopping Hybridcast applications (called App. in the figure). They are multiplexed into the normal broadcast signal. Service operators who have *2 An application programming interface (API) defined to implement functions needed in Hybridcast, in addition to the standard HTML5 APIs. An API is a set of commands and functions used when developing software to run for a given OS or run-time environment. Broadcast content Information added to broadcast signal (standardized) Broadcast station Service Provider Receiver Station server Security functions App. App. App. management/ distribution Per-service servers Stream server server Transport format App. API 1 Broadcast and communications linking functions Security functions API Basic functions Partly standardized Repository 2 App. Linked terminal 1 Programming Interface 2 Function providing application list to receivers Figure 1: Hybridcast system model (from IPTVFJ STD-0010) 10
Feature signed contracts with the broadcaster are then able to control their applications with these signals. Service providers play a major role in a service chain of Hybridcast. They distribute their applications to the viewers receivers and control the data streamed to the applications. The receiver runs Hybridcast applications, provides the functionality that enables users to receive services linking broadcasting and communications, and communicates with external devices such as tablet computers over a home network for second screen usage. Hybridcast system model illustrated in Figure 1 is a logical model, and a variety of form of operation is allowed to implement the functions in the model. 3. Hybridcast s s are the means for realizing individual services in Hybridcast, and the way they work depends on the service being provided. In order to support a wide range of services, various application types have been defined, as shown in Table 1. In Table 1, managed applications refers to reliable applications approved by broadcaster(s) that are allowed for simultaneous presentation with a broadcast program, and these are further categorized into broadcast-oriented managed and non-broadcast -oriented managed applications. Broadcast-oriented managed applications are launched by application control signals (see Section 4) within the broadcast signal. s are coded in HTML5, so they can include links to other sites. On the other hand, an application can also be given a domain scope by using the control signals multiplexed on the broadcast signal. The application keeps its status of broadcast-oriented managed application as long as all transitions remain within this scope, and even transitions to sites of other service providers are allowed while keeping its status if they are approved by the broadcaster. In such cases, the service provided by the other party can use broadcast functions within the scope permitted by the broadcaster. Also, as long as the application remains broadcast-oriented managed, the application can be stopped by using application control signals in the broadcast even if an application of a third party is being displayed. If the application exceeds this scope, the application is converted to general application and can no longer use broadcast functions and be exhibited with a broadcast program. Once the application becomes a general application, it cannot become a broadcastoriented managed application again. The user must select the channel again to restart the application. Non-broadcast managed applications are applications that can operate in the same manner as broadcast managed applications, but whose legitimacy is preserved by some means other than the broadcast signal, such as code signing. Because of this, the user is able to select, start, or stop the application at any time, independently of the broadcast signal. The application continues to run even if the channel is changed. This allows services that span multiple channels to be provided. General applications are applications that are not managed. These are comparable to accessing an ordinary Web site. Note that Ver. 1.0 of the Hybridcast technical specifications standardized by the IPTVFJ in March, 2013, covers only broadcast managed applications; nonbroadcast managed applications are to be studied in the future. 4. Hybridcast Control Signals control signals control the launching and terminating of applications, the scope of broadcast functions available to various network domains (called the application boundary ), the execution priority of data broadcasts, and other factors 3). Two formats are specified for the application control signal: the Moving Pictures Experts Group (MPEG) section format *3, and Extensible Markup Language (XML) notation. And, three methods are specified for transmitting these signals: transmission in a dedicated elementary stream (ES), transmission in a data carousel *4, and by retrieving a control signal file placed on a server over broadband network. A Hybridcast receiver retrieves applications from a site specified by uniform resource locators (URLs) in the application control signal and performs the necessary controls, such as staying within the application boundary, by executing the commands in the application control signals. 5. Receivers The Hybridcast receiver model is shown in Figure *3 A generic data description format defined in the MPEG2 Transport Stream (MPEG2-TS) specification. *4 A transmission scheme that transmits the same data repeatedly. Table 1: Hybridcast application types Managed s Unmanaged s type Broadcast-oriented managed Non-broadcast-oriented managed General Launch command Broadcast signal Non-broadcast signal Access to broadcast resources (broadcast video, sound, SI 1 ) Allowed Not allowed examples Multi-language captions, Channel spanning Other program recommendations, etc EPG 2, etc. 1 Service Information 2 Electronic Program Guide 11
HTML5 Launcher 1 Resident 2 Engine Receiver Functions Broadcast reception/play back function Broadband content reception/play back function control function Security management function Device linking and control function Hardware Communications Interface Tuner DeMux 3 Video Decoder Audio Decoder 1 Receiver function allowing the user to select an application to run. 2 s built into the receiver. 3 Function that extracts the video, audio and other data multiplexed in the broadcast signal. Figure 2: Organization of Hybridcast receiver (from IPTVFJ STD-0010) 2. An HTML5 browser with extension APIs to support Hybridcast is provided as the application engine *5. It also includes functionalities particular to Hybridcast, including ones to receive and play-back VoD and other content sent through broadband channels, functions to control applications based on the control signals described in the previous section, security management functions, and functions for linking with and controlling tablets and other external terminals. 6. Extension APIs The HTML5 browser specifications defined by IPTVFJ 2) encompass the application engine described above. In addition to this basic HTML5 functionality, extension APIs enabling various application behaviors are defined. The major extension APIs and extension objects *6 are shown in Table 2. 7. Device Linking Age Besides remote controls, easy-to-operate devices such as tablets and smart phones are good means of performing interactive operations. They can also act as a second screen on which to present information. For these reasons, functionalities for linking with such terminals *5 *6 The application run-time environment provided for excution Collections of extension APIs classified by function. of applications in a receiver. Table 2: Main extension APIs and extension objects object Information table object Receiver Device object EIT 1 related object Stream-Event-Target object BMLCompatObject object Device linking functions Broadcast Video Object Object for controlling application launch and other application state. Object representing application control information. This enables applications to obtain information related to the application boundary. Object representing the receiver device. This object provides access to channel selection information, information about the program currently being viewed, and other information specific to the receiver device. Object representing EPG information. Object for handling trigger signals from the broadcast signal (event messages). Object for handling functions particular to data broadcasts. A subset of the Receiver Device object functions such as, for passing the initial URL to the linked terminal, and for exchanging messages. The object for handling broadcast video. With Hybridcast, broadcast video is not handled by the HTML5 Video element 2. This object is defined as an alternative. 1 Event Information Table: A Table (or series of Tables) containing EPG information multiplexed on the broadcast signal. 2 Introduced in HTML5, functions for handling video (tags). 12
Feature has been incorporated into Hybridcast. Linking with such devices is achieved by communication between Hybridcast application running on the receiver and an application running on the device. A device discovery function is needed to find and identify the device to communicate with. In Hybridcast, such discovery functions and communication between the receiver and terminal are accomplished by a remote-control application on a tablet or smartphone by using proprietary methods defined by the receiver manufacturer. For this reason, the device discovery and communication protocols between the receivers and linking terminals are outside of the scope of the Hybridcast specifications. Instead, an enhanced remote-control application released by the receiver manufacturer (called a companion application) provides standardized functions for communication between an application on the receiver and an application on the companion application, as well as an application runtime environment for the tablet and smartphone applications used by the individual Hybridcast services. Users install the companion application on their tablet or smartphone. The software architecture for device linking is shown in Figure 3. The communication indicated by the red line is for device discovery and for establishing communication between the receiver and device. Once communication is established, applications running on the receiver and the linked terminal are able to communicate with each other. 8. Example Services of Hybridcast Examples of Hybridcast services were exhibited at the 2013 NHK STRL Open House. Figure 4 is an example of a menu application. The menu on the left is for selecting other applications, whereas news and a weather forecast are displayed in the middle. The dedailed news and weather forecasts are displayed by pressing a button to launch the news and weather forecast application. The menu displayed on the right contains various settings and is for selecting widget-like applications. The menu itself is an application, so various techniques Linked terminal application engine Hybridcast application Companion application engine Basic functions for device linking Basic functions of receiver Device discovery (+ receiver control) Text transmission Mobile terminal Receiver Figure 3: Structure of device linking software (from IPTVFJ STD-0010) Figure 4: Menu application example 13
News article is displayed after selecting a headline Figure 5: News application example (Ticker-tape news) TV screen Tablet screen Figure 6: Example application for selecting VoD content using device linking functions such as animation can also be used to display them. Figure 5 is an example of a news application called Ticker-tape News. As its name suggests, it shows news on a ticker-tape scrolling along the bottom of the broadcast video screen. If a headline is selected with the remote control, the NHK Web site (NHK ONLINE) is accessed, 14
Feature and detailed articles are retrieved and displayed on the TV screen. The example application in Figure 6 is for selecting video on demand (VoD) content. Available and recommended content is displayed in response to requests from each receiver. This user interface is displayed on the tablet screen, in the same way as it is shown on the TV screen. Device linking functions bring the same result on the TV screen as that on the tablet, in response to manipulation on the tablet. HTML5 capabilities imbue the application user interface with a new set of intuitive operations that complement the functions found on normal remote controls. References 1) IPTVFJ STD-0010, Broadcast and Communications Linking System Specifications Ver. 1.0 2) IPTVFJ STD-0011, HTML5 Browser Specifications Ver. 1.0 3) ARIB STD-B24, Data Coding and Transmission Specification for Digital Broadcasting 4th Edition (Ver. 5.8) 9 International Standardization and Future Prospects The work toward international standards for systems combining broadcasting and broadband is being done by the International Telecommunication Union (ITU) and the World Wide Web Consortium (W3C). Standards created at the ITU include ITU Radiocommunications Sector (ITU-R) Recommendation BT.2037, which defines general requirements for systems, ITU Telecommunications Sector (ITU-T) Recommendation J.205, which defines technical requirements, and ITU-T Recommendation J.206, which specifies a reference architecture *7. The Hybridcast technical specifications Ver. 1.0 conform to these Recommendations. ITU-R has also issued the Report, BT.2267, which summarizes information related to systems combining broadcasting and broadband. This Report describes three systems, including HbbTV *8 from Europe, Hybridcast, and Broadcast Markup Language (BML) Type 2 *9. On the other hand, HTML5 is a candidate recommendation at W3C, who handles Web standards, and it is expected to become a recommendation in 2014. 10. Conclusions As mentioned in Section 3, the current Hybridcast technical specifications Ver. 1.0 defines only broadcastoriented managed application. In the future, the Ver. 1.0 functions will be extended to include nonbroadcast-oriented managed application, synchronized presentation of multiple streams, digital video recorder (DVR), and other functions. We also anticipate studies of Hybridcast services on 8k Super Hi-Vision, which has sixteen times the resolution of current digital broadcasts, and eventual standardization of such services. *7 A reference for system structure and configuration. *8 A system for combining broadcasting and broadband, standardized in Europe. *9 An extended data broadcasting specification enabling VoD content playback and simple services combining broadcasting and broadband. 15