FEATURE

9

Since the addition of video on demand (VOD) technol-ogy that is compatible with 4K streaming in December 2014, Hybridcast has been used in demonstrations of 4K video streaming that transitioned from broadcast program by multiple broadcasters and has attracted attention as a fundamental technology for the TV streaming of video content in Japan. In this article, we describe the techni-cal elements of the “Hybridcast Video” and “Hybridcast 4K Video” video streaming services based on specifica-tions that clarify the operating method of the system and the technical requirements of the receiver. Demonstration experiments that use Hybridcast Video are also introduced.

1. IntroductionA new VOD technical specification for TV receivers that

are compatible with HyperText Markup Language 5 (HTML 5) was added to version 2.0 of the IPTV Forum Japan Stan-dard IPTVFJ STD-00131) Hybridcast operational guideline in December 2014.2) That specification adopts MPEG Dy-namic Adaptive Streaming over HTTP (MPEG-DASH),3) an international standard for video streaming technology, and assumes that the video player running on the TV receiver is written in JavaScript using Media Source Extensions4)

(MSE) and Encrypted Media Extensions5) (EME), which are extension functions of the HTML 5 video element*1 speci-fied by the World Wide Web Consortium (W3C), a Web technology standards organization. A major feature of the new VOD technical specification is the world’s first adop-tion of MSE and EME as open standards for TV.

The appearance of these new technologies and the en-hancement of internet connectivity have raised expectations

for new services that use network video, and since 2015, multiple broadcasters have conducted field experiments of 4K video streaming based on Hybridcast. 6)-15) In 2017, field experiments of simultaneous broadcasting and 4K stream-ing were performed by a consortium of nine organizations in the “Demonstration experiments of technologies to improve broadcast services using broadband” project16) sponsored by the Ministry of Internal Affairs and Communications.

The objectives of those experiments were to promote new broadcasting services that use 4K TV receivers that are compatible with Hybridcast and to clarify technical and op-erational issues and organize their countermeasures. Also, systems of new VOD technology have been attracting the attention of broadcasters as a platform technology for video streaming for TV, including services that have already be-gun, such as the on-demand viewing of previously broad-cast programs by simple selection from a program guide, without the viewer being aware of the difference between broadcast and on-demand viewing.17)

However, these efforts have raised issues, such as behav-ior that varies from receiver to receiver and uneven compat-ibility with the functions required to implement the desired services, and it is unclear which receivers are compatible with which functions. To deal with this situation, the IPTV Forum organized the service requirements and operating methods of broadcasters and formulated specifications that clarify the technical requirements of all functions that TV receivers should implement. To make it easy to identify the receivers that conform to the specifications of video streaming services, the names “Hybridcast Video” for 2K and “Hybridcast 4K Video” for 4K are used, and the logos shown in Fig. 1 were announced in May 2018.18)

NHK has developed a video player that features stable operation on a TV receiver and compliance with the new

R&D Trends in Video Streaming for TV– “Hybridcast Video,” a video streaming service for Hybridcast –Satoshi Nishimura

*1 HTML document element for embedding video in a Web page

FEATURE

10

VOD technical specification. It has been released as a refer-ence model for members of the IPTV Forum MPEG-DASH Interoperability Study Group. We have also contributed to the formulation of specifications for Hybridcast Video and the preparation of verification content for determining re-ceiver compliance with the specifications.

In this article, we describe MPEG-DASH and a video player that uses MSE and EME as technical elements of Hy-bridcast Video. The characteristic technical requirements of Hybridcast Video are also described and examples of field experiments are introduced.

2. MPEG-DASH2.1 Trends in video streaming technologies

In recent years, the HyperText Transfer Protocol (HTTP), which is used to transfer files of text, images, and other components of Web pages, has also been replacing dedicat-ed protocols as the mainstream video distribution method. This method is referred to as HTTP streaming.

In addition to not requiring a special dedicated server for video distribution, HTTP streaming can use the content de-livery networks (CDNs) that are used to increase the speed and scale of websites, making it possible to implement video distribution at a lower cost and a greater scale than with conventional video streaming technologies. It is also possible to achieve stable streaming that is less susceptible to interruption with adaptive streaming, a function that dy-namically switches between video quality levels according to network congestion conditions.

In addition to the proprietary HTTP streaming technolo-

gies of IT vendors such as Apple HTTP Live Streaming (HLS), Adobe HTTP Dynamic Streaming (HDS), and Mi-crosoft Smooth Streaming, MPEG-DASH has been stan-dardized by the International Organization for Standard-ization/International Electrotechnical Commission (ISO/IEC).19) Of those technologies, MPEG-DASH is being pro-moted for use in broadcasting because it is an international standard and, in addition to being adopted in specifications such as Digital Video Broadcasting (DVB),20) HbbTV, 21) and Advanced Television Systems Committee (ATSC),22 it is being used in large-scale video streaming services such as BBC iPlayer, YouTube, and Netflix.

2.2 Basic MPEG-DASH operation

The MPEG-DASH content comprises video files called ‘segments,’ which are the original video data divided into units of a few seconds in duration, and a Media Presentation Description (MPD), which is a metadata file that contains metadata information required to play the video stream. The MPD contains the video encoder parameters (encoding method, bit rate, etc.) and segment information (segmenta-tion unit and location, etc.).

In the operation of adaptive streaming by MPEG-DASH, the video service provider creates multiple videos that have different quality levels (resolution and bit rate) from a single video source and divides each file into segments, with the cut times aligned across the files. An MPD file that contains all of the video information is also created. These files are then made available on a Web server.

The receiving terminal first gets the MPD file from the

Source: http://www.iptvforum.jp/info/files/180515.pdf

Hybridcast 4K Video Hybridcast Video

Figure 1: Hybdridcast Video logos

FEATURE

11

Web server to obtain the structure of the video segments (Fig. 2, (1)). Next, the segments that have the quality level that is most appropriate to the degree of network congestion and the viewing environment (terminal screen resolution, etc.) are selected and obtained from the server (Fig. 2, (2)), and then concatenated in the correct order to be played (Fig. 2, (3)). This operation is repeated so that viewing continues without interruption, even if sudden network congestion oc-curs.

2.3 MPD structure and services that can be

implemented

In addition to the adaptive streaming function described above, MPEG-DASH enables the description of content as-suming multiple-view video and multilingual audio switch-ing, as well as services such as organized program distribu-tion as is done in broadcasting. The implementation of these functions is explained below, with reference to the MPD presented in Fig. 3.

The MPD has a hierarchical structure with Period, Ad-aptationSet, and Representation. A Period represents one program or chapter. In the example presented in Fig. 3, the structure consists of two concatenated Periods that have

durations of five minutes. Multiple consecutive Periods de-scribed in this way are referred to as a multiperiod structure. Such descriptions make it possible to stream programs in an

Web server

MPD (Media Presentation Description) file

Segment

Encoder

High quality

Medium quality

Low quality

Receiving terminal

Video buffer

Network congestion

Thro

ughp

ut・Bit rate

・Resolution

・Segmentation unit

・Segment source　　

…

1

1’

1”

2

2’

2”

3

3’

3”

4

4’

4”

1”2’34”

Encode a single video with multiple degrees

of quality and divide it into segments(2) Select the quality level for reception for each segment according to

the degree of network congestion

(1) Obtain the MPD file to

understand the segment structure

(3) The received segments are

concatenated according to the MPD

and played

Figure 2: Adaptive streaming with MPEG-DASH

<MPD mediaPresentationDuration=“PT0H10M00S”> <Period id=“p1”　duration="PT5M00S" > <AdaptationSet id=“a1”　mimeType=“video/mp4”> <Representation id=“r1”　bandwidth=“1000000”> <SegmentTemplate duration=“5” media=“video_$Number$.mp4” initialization=“video.init”/> </Representation > <Representation id=“r2”　bandwidth=“3000000”>　　　　 ・・・・・・ </Representation > </AdaptationSet > <AdaptationSet id=“a2”　mimeType=“video/mp4”>　　　　 ・・・・・・ </AdaptationSet > <AdaptationSet id=“a3”　mimeType=“audio/mp4”>　　　　 ・・・・・・ </AdaptationSet > </Period> <Period id=“p2”　duration=“PT5M00S”>　　　　 ・・・・・・ </Period></MPD>

Figure 3: MPD overview (excerpt)

FEATURE

12

organized manner as is done in broadcasting, and it can also be used for inserting advertisements between programs.

A Period comprises multiple AdaptationSets, which hold information on media elements (video, audio, text, etc.). AdaptationSets can contain media elements that have the same format but different representations (video with a different camera angle or audio in a different language, etc.). In Fig. 3, for example, the inclusion of two video files (mimeType= “video/mp4”) enables the implementation of a viewing method in which one of multiple video images can be selected and/or the video being played can be switched during viewing. We use this function to develop multi-view streaming technology that makes it possible for users to smoothly switch between videos taken by multiple cameras while viewing on the web browser of a computer or smart-phone through the internet.23)

Data such as bit rate (bandwidth) and resolution for the media elements described in the AdaptationSet are de-scribed in the Representation. Adaptive streaming can be implemented by having multiple Representations that spec-ify different values for the bit rate and resolution.

The Representation contains information on the seg-ments, which are the actual data that constitute media el-ements (Media and Initialization in Fig. 3). The Media is the segmented video file and the Initialization contains ini-tialization data such as the encoding parameters. The cor-respondence between playback time and segments can be described in a number of ways, but in the example presented in Fig. 3, the correspondence is described by file names that include a sequence number ($Number$) that is incremented by the segment length (duration of 5 seconds). By using this information, it is possible to play the video for the target scene by specifying the uniform resource locator (URL) of the video and audio segment that corresponds to the current playback time.

3. Playing MPEG-DASH content in Hybridcast3.1 MSE and EME HTML 5 video element extension func-tions

HTML 5 specification has introduced the video element for the purpose of playing videos. However, the convention-al video element only provides progressive download tech-nology which plays video progressively as the video file is downloaded from the specified URL. It is therefore difficult

to handle advanced services such as adaptive streaming, live distribution, or playback of content that is protected by digital rights management (DRM).

To overcome these problems, video player plug-ins for web browsers*2 such as Adobe Flash and Microsoft Sil-verlight have been used for video streaming. However, the power consumption and security risk associated with the use of plug-ins are increasingly problematic with smartphones being more frequently used for video playback. As a result, the movement to eliminate plug-ins is gaining momentum.

To address this issue by extending the HTML 5 video element to enable video playback for advanced services such as these described above, W3C has standardized MSE for video playback control and EME for DRM content pro-tection. These standards have already been implemented in many Web browsers. Previously, it was only possible to set the URL of a video file as the video source, and the method of data exchange between the browser and the server was left to browser implementation, which limited the scope of app development on the service provider side. The extended specifications make it possible to set a playback buffer that is generated by MSE as the video source. Doing so makes it possible to use the JavaScript programming language to describe video player functions such as the exchange of vid-eo data that is required for the playback of MPEG-DASH video, insertion of data into the input buffer, and playback control.

3.2 iptvfj-dash video player

The operation profile*3 for VOD services using MPEG-DASH specified by the IPTV Forum in the new VOD tech-nical specification described above is referred to as the IPTV Forum Japan MPEG-DASH Profile (iptvfj-dash). Un-like VOD implemented with the conventional object ele-ment*4 in Hybridcast, the video player is supplied by the service provider as a JavaScript program. When the TV re-ceiver accesses the Web site of a video service, the player is downloaded from the Web server together with the HTML and Cascading Style Sheets (CSS) that constitute the Web

*2 Small-scale programs for adding functions to software*3 The parts of standards and regulations that define the func-

tions for implementing required uses*4 An HTML element for embedding plug-ins and other external

resources in a Web page*5 A language for defining the layout and design of a Web page

FEATURE

13

page.*5 In this way, TV receiver manufacturers need only install an HTML5-compliant Web browser instead of incor-porating a proprietary video player. This approach makes it possible to implement viewing operations that are specific to services and facilitates changes in the user interface, etc., which can be expected to lead to the development of diverse video streaming services.

However, we can expect that much work would be re-quired for each broadcaster or other service provider to develop their own video player, and the need for receiver manufacturers to verify the behavior and performance of many different players on their equipment would increase cost. For these reasons, we developed video player software (“dashNX”) that is equipped with functions for the stable playback of MPEG-DASH content on TV receivers that are compliant with the standard. We also developed an applica-tion programming interface (API) that supports the devel-opment of new services*6 in parallel with the standardiza-tion of the new VOD technical specification.24) Considering the relatively limited processing resources of TV receivers (CPU, memory, etc.), constraints such as the inability to use multiple video elements at the same time, and the require-ments of broadcaster services, we based the video player software “dashNX” on dash.js, a JavaScript player pub-lished by the DASH Industry Forum,25) and enhanced it with functions for TV receivers. In January 2016, we provided

this software to the MPEG-DASH Interoperability Study Group that was established within the IPTV Forum, and the study group published it as a reference model to serve as a common base for use by various service providers.

The overall configuration of a viewer that is compliant with iptvfj-dash is shown in Fig. 4. In addition to the func-tions for implementing MPEG-DASH content reception control and basic video playback operations such as pause and seek video playback control, the software library shown in the figure provides the API that is needed to implement various service requirements and can be used as a common part for all services. The library is called “dashNX”. (“dash-NX” is also sometimes used to refer to the video player as a whole.) The extended app is also a sample of functions that are used with high frequency, which are already imple-mented and built in using the API. Together with the user interface (UI), it is assumed to be a component that is cus-tomized for use according to service requirements.

Although dashNX satisfies the main requirement of sta-ble playback on TV receivers, it can also operate on smart-phones, personal computers, etc., if the terminal is equipped with a Web browser that is compliant with MSE and EME. It can therefore be used to implement a multidevice viewing environment (Fig. 5).

We have described a video player implemented with dashNX as an example here, but because the program is written in JavaScript, a player can be developed indepen-dently and services can be constructed using other software.

Extension app

Playback control library (dashNX)

HTML5 browser (MSE/EME)

Video/Audio decoder

PC UI TV UI Smartphone UI

Prov

ided

from

Web

site

by

serv

ice

prov

ider

Dev

ice

embe

ddin

g

Figure 4: Configuration of iptvfj-dash video player using dashNX

*6 An interface for using functions from other software

FEATURE

14

4. Technical requirements of Hybridcast VideoThe characteristic technical requirements for Hybridcast

Video are described here.

4.1 IPTV Forum Japan MPEG-DASH profile (iptvfj-dash)

iptvfj-dash specifies the audio and video encoding meth-ods and constraints on the MPD description. For video en-coding, H.264|MPEG-4 Advanced Video Coding (AVC) or H.265|MPEG-H High-Efficiency Video Coding (HEVC) is used. For a resolution of 2K or less, H.264 is basically used, but H.265 was also introduced as an option in the Operation-al Standard version 2.5 of July 2017. For 4K, H.265 is used. The ISO Base Media File Format*7 is used for segments, with a range of from 1 to 15 seconds as the segment length. Video and audio are segmented separately. In the MPD, the hierarchical structure described in section 2.3 can include multiple descriptions of each of Period, AdaptationSet, and Representation. It is also possible to describe the switch-ing of programs with multiple periods and the switching of multiple video views and audio in different languages, as well as operation that assumes adaptive streaming, etc. For adaptive streaming, transitions between representations that have different coding rates, different profile/levels,*8 and different vertical and horizontal resolutions are speci-fied. Subtitles using ARIB-Timed Text Markup Language (TTML)26)*9 and DRM handling are also specified.

4.2 Receiving general event messages during VOD

playback

A general event message (EM) can be used for the batch transmission of trigger data from broadcast stations to apps running on TV receivers, etc. It is a very important function for controlling app presentation to ensure viewer safety and security during emergencies. 27)

However, field experiments have shown that currently available TV receiver models that are compatible with re-ceiving an EM during VOD playback are limited. Appar-ently, these functions were not considered essential in the specifications for VOD using the conventional object ele-ment in Hybridcast.

For this reason, the IPTV Forum decided that receiving the EM during VOD playback is an essential requirement for Hybridcast Video, assuming the use case in which VOD playback is forcefully ended by an EM that contains emer-gency information transmitted by a broadcast signal and the receiver is returned to broadcast operation. Furthermore, an EM may be scrambled for transmission, so it is necessary to handle both scrambled and unscrambled EMs.

4.3 Seamless content switching with multiple periods

When dashNX receives an MPD that has a multiperiod format in which multiple Periods are concatenated as de-scribed in section 2.3, it is possible to assemble and play video from various servers according to this description.

An example of an MPD in which different video clips are inserted for different viewers in program editing and these clips are inserted into the video stream according to the viewer is shown in Fig. 6. Use of this function is expected to lead to the development of new businesses such as the insertion of regionally appropriate advertisements into pro-grams for each viewer. The desirable technical requirements for such uses include the seamless switching of Periods and unified receiver operation.

However, the actual media length that results from the MPEG-DASH content generation process may be shorter than that described in the MPD (Fig. 7 (1)). This may result in time gaps between periods in the buffer that may stop playback. Although it is possible to continue playback if the player implementation allows it, the behavior when gaps appear in the buffer is specified as implementation-depen-dent in MSE, so it is difficult to achieve a unified playback

*7 A metadata file format for video, etc., specified by MPEG-4 Part 12 (ISO/IEC14496-12)

*8 A parameter that indicates the performance required for bitstream decoding

*9 An ARIB standard markup language that defines the timing and position for displaying text used for subtitles, etc.

Figure 5: Multidevice playback by dashNX

FEATURE

15

operation for receivers. On the other hand, there is a provi-sion in the specification that later overwriting with inserted media data results in the concatenation of Periods without gaps if there is an overlap of media in the buffer. There-

fore, we consider it possible to achieve seamless switching and unified playback operation by appending an extra cut at the end of the Period, which necessarily creates an overlap with the next Period (Fig. 7 (2)). However, demonstration

Viewer A Viewer B

Clip-A

MPD for each viewer

Program Clip-B

MPD Web server

00:00:00 First part

00:15:00 Clip-A

Last part

First part

00:15:00 Clip-B

Last part

Clip-AWeb server

ProgramWeb server

Clip-B WebWeb server

00:16:00

00:00:00

00:16:00

Figure 6: Insertion or replacement of video clip according to viewer

Playback Period

Video length(metadata in MPD) Video length

Actual media length Actual media length

Next Period

Next Period

Gap

Playback Period

Playback Period

Buffer insertion

Next Period

ex

Next PeriodPlayback Period

Overwrite

Discard

Buffer insertion

(1) A time gap is created in the buffer and playback stops at the Period boundary

(2) Seamless switching by overwriting the overlap with the next Period.

ex

Figure 7: Buffer states at Period boundaries

FEATURE

experiments revealed that the buffer overwrite operation of some receivers differs from the MSE standard, so the IPTV Forum made the implementation of the overwrite operation according to the MSE standard a requirement for Hybrid-cast Video.

Assuming actual operation, it is necessary to handle MPD in which the DRM encryption key is different for each Period or in which there are Periods that have DRM applied together with Periods that do not have DRM applied.

4.4 Organization of the verification content

In addition to the verification items for the technical re-quirements described above, the IPTV Forum has prepared verification content for use in operation tests for the skip operation and other viewing operations that are assumed for general operation, playback tests for long programs, and be-havior tests for the API that is specific to Hybridcast, includ-ing screen transition between broadcasting and VOD. The verification content makes it possible to determine whether or not a receiver complies with the technical requirements of Hybridcast Video.

5. Demonstration experiment examplesAs examples of field experiments that use Hybridcast

Video, 4K streaming in synchronization with broadcasting, replacement of content to match the region, and IP multicast 4K live streaming for a Hybridcast-compatible TV receiver are described here.

5.1 Broadcast-synchronized 4K streaming and region-appropriate content replacement

4K streaming in synchronization with broadcasting makes it possible to watch programs while switching between broadcasting and 4K streaming video on a TV receiver. Experiments with this technology have been performed by many enterprises, including Fuji Television Network, Inc.14), and demonstration experiments have been conducted by the Ministry of Internal Affairs and Communications.28) If a viewer is watching a program on a receiver that is the sub-ject of the experiment, a button for switching to 4K stream-ing video is displayed, and the viewer can use the remote controller to select the button. If the button is selected, it is possible to view a scene in 4K streaming in synchronization with the progress of the broadcast (Fig. 8 (1)). Recently, broadcasters have been actively producing 4K programs, but the programs must be down-converted to 2K for ter-restrial broadcasting. The mechanism shown in Fig. 8 (1) has been attracting attention as a method that enables 4K programming to be viewed at 4K resolution via broadband with the broadcast as the starting point.

The 4K streaming demonstration experiments included a test using the multi-Period content switching function to in-sert commercial advertisements that were partially tailored to specific regions on the basis of the registered postal area code of the receiver and the network_id*10 (Fig. 8 (2)). The

(1) 4K distribution synchronized with broadcast

Synchronization information/�emergency information

Broadcast Broadband Main program Commercials for specific regions

Main program part 1

Region A Region B

CM Main program part 2

Switching

(2) Content replacement suited to region

Broadcast (2K) Broadband (4K)

Emergency informationEmergency information

Figure 8: 4K streaming and content replacement suited to region

16

*10 An ID used to identify the broadcasting network. Each broadcasting station has a different ID for terrestrial digital broadcasting.

FEATURE

results confirmed playback without problems for receivers that comply with the verification items described in section 4.3.

Also, broadcast program content may be changed to a spe-cial emergency program when a disaster occurs, so a mecha-nism for immediately returning the receiver to the broadcast program during 4K streaming was also tested (Fig. 8 (1)). In addition to a method for the notification of emergency infor-mation of a change to an emergency program by a broadcast event message, we compared a method in which the receiver uses HTTP to periodically check for a state of emergency and a method in which Web technology such as push noti-fications from a server using a WebSocket 29)*11 is used. Al-though the limited number of receivers that are compatible with notification by event messages is currently a problem (section 4.2), this method has the important advantages of immediacy and reducing network load, so we hope that more receivers that are compatible with this method will soon be available. The demonstration experiments by the Minis-try of Internal Affairs and Communications also involved a test of reproducing high dynamic range (HDR) content, which revealed problems with the method for determining the HDR compatible receivers and viewer discomfort when a composite of HTML 5 content and HDR video was dis-played. At the time of the demonstration experiment, there

were no clear provisions concerning HDR in the Hybridcast operating specifications, but the issue is being discussed in the current standardization process.

5.2 IP multicast 4K live streaming for Hybridcast receivers

Because the unicast method that is generally used for video streaming distributes content on a one-to-one basis upon request from TV receivers, the network load and dis-tribution cost increase with the number of viewers. This is a particularly important problem for streaming high-bit-rate content such as 4K video. For this reason, 4K live stream-ing experiments in which IP multicasting, which enables one-to-many broadcast-type streaming was used instead of the unicast method, were conducted by Yomiuri Telecasting Corp.10) and the Ministry of Internal Affairs and Communi-cations.28)

A conceptual diagram of the experiment structure is shown in Fig. 9. On the distribution side, the 4K video is encoded in real time and MPEG-DASH segments are gen-erated. The data is converted to User Datagram Protocol (UDP)*13 packet format by File Delivery over Unidirec-tional Transport (FLUTE) 30)*12 processing and delivered by IP multicast over a Fiber to the Home (FTTH) network or a CATV network. On the receiving side, the viewer used the remote control to switch the display between broadcast

17

*11 Technical specifications for two-way Web app communica-tion

4K streaming

Broadcast

4K video

Live encoding/MPEG-DASH generation

FLUTE processing(MPEG-DASH restoration)

IP multicastWeb server

Home gateway

FLUTE processing（MPEG-DASH restoration）

IP multicast receiving

IP multicast receiving

FTTH networkor

CATV network

2K/4K

Distribution side Receiving side

Figure 9: IP multicast 4K live streaming test for Hybridcast receiver

*12 A mechanism for transferring segment files by broadcasting or over a one-way transmission path

FEATURE

and the 4K video stream using the structure of Hybridcast Video. However, HTML 5 on which Hybridcast is based provides no API for handling multicasting, so the viewing of 4K video is implemented by a mechanism in which a dedicated gateway*14 that is installed in the home receives the IP multicast, restores the MPEG-DASH segments, and then streams the video to the receiver by unicast.

Also, assuming the situation in which multiple broad-casters simultaneously distribute 4K video, experiments in which a multicast mechanism was used to switch channels between 4K video streams were conducted. For the direct switching between high-bit-rate 4K video streams, retrieval of the 4K video begins when the channel switching opera-tion is performed, so there is a long delay before playback begins. To address this problem, low-bit-rate 4K video of all channels are sent in advance, and the adaptive streaming function is used to transition seamlessly to the high-bit-rate 4K stream when the preparation is completed. This method has been confirmed to shorten the switching time by the seamless transition from a low bit rate to a high bit rate.

In IP multicasting based on UDP, packet loss due to net-work congestion may result in the loss of some MPEG-DASH segments. Because there is no clear specification of how video players should operate in this case, player behav-ior depends on individual requirements and services.

The MPEG-DASH Interoperability Study Group of the IPTV Forum has established a place for sharing problems and expertise concerning MPEG-DASH video streaming and video players, including events such as those described above. By invigorating the activities of the study group, we can expect to continue contributing to the development of stable video streaming services.

6. ConclusionWe have explained the technical elements and technical

requirements for the Hybridcast Video and Hybridcast 4K Video video streaming services on the basis of specifica-tions that clarify the operation method of the Hybridcast new VOD technical specification and the technical require-ments of the receiver. We have also introduced examples of demonstration experiments of 4K streaming using the struc-

ture of Hybridcast Video.Clarification of the technical requirements and the cre-

ation of logos have facilitated the efforts of broadcasters to provide diverse services and enabled viewers to easily iden-tify compatible receivers. We believe that this will acceler-ate the widespread use of Hybridcast. We hope that these efforts will encourage the participation of many service pro-viders and developers in the creation of many new and ap-pealing services that combine broadcasting and broadband.

References1) IPTVFJ STD-0013, “Hybridcast Operational Guideline”2) IPTV Forum: “A New VOD Technology and System for

Televisions Supporting HTML5,” http://www.iptvforum.jp/info/2014/12191501.html (in Japanese)

3) ISO/IEC 23009-1:2014, “Information Technology — Dy-namic Adaptive Streaming over HTTP (DASH) — Part 1: Media Presentation Description and Segment Formats”

4) Media Source Extensions, https://www.w3.org/TR/media-source/

5) Encrypted Media Extensions, https://www.w3.org/TR/en-crypted-media/

6) M. Ito: “Hybridcast Application: “4K Landscape”, for User-Selectable TV-Viewing of HD Broadcast and UHD Broad-band based on Hybrid Delivery Model,” ITE Journal, Vol.71, No.4, pp.J125-J130 (2017) (in Japanese)

7) Fuji Television Network, Inc.: “Simultaneous distribution of Terrestrial Broadcasts and 4K Video using Hybridcast 4K Video Distribution Technology,” https://www.nagoyatv.com/archives/024/201603/8742e82da7baf4cee8c3b7bdbee1c21e.pdf (in Japanese)

8) Tokyo Metropolitan Television Broadcasting Corp.: “A First for Regular Terrestrial Programming! Full 4K Video Distribu-tion Trials using Hybridcast Start,” http://s.mxtv.jp/company/press/pdf/press2016_120001.pdf (in Japanese)

9) Nikkei New Media: “Kansai Television Successfully Tests Live Distribution of 4K Video using Hybridcast,” http://tech.nikkeibp.co.jp/it/atcl/news/16/062201814/ (in Japanese)

10) Yomiuri Telecasting Corp.: “Trial IP Multicast Distribution of 4K Video using the MPEG-DASH Format,” http://www.ytv.co.jp/fromytv/news/number/page_2002134.html (in Japa-nese)

11) NHK: “Trial Internet Distribution of 4K Video at the Rio Olympics,” https://www.nhk.or.jp/pr/keiei/shiryou/kai-

18

*13 One protocol for data communication on the internet; the processing speed is high, but the reliability of delivery is low

*14 Hardware and software for connecting networks that have different communication protocols

FEATURE

chou/2016/07/003.pdf (in Japanese)12) Nagoya Broadcasting Network Co.,Ltd.: “Metele: Distri-

bution of Broadcast-linked 4K Content using Hybridcast,” https://www.nagoyatv.com/archives/024/201612/7ce1f6d043e9f14b9b4f6d0e634a080f.pdf ( in Japanese)

13) Fuji Television Network, Inc.: “Distribution of 4K Regional Advertisements Simultaneously with Terrestrial Broadcast,” http://www.fujitv.co.jp/fujitv/news/pub_2016/161111-m047.html (in Japanese)

14) M. Ito: “Fuji Television’s Approach to Develop the Broadcast and Online Collaborative Video Service; Switchable HD/4K viewing and addressable TV content on ‘Hybridcast Video’ technology,” ITE Journal, Vol.71, No.6, pp.797-801 (2017) ( in Japanese)

15) D. Hara: “Nagoya Broadcasting Network Challenge Delivery of 4K Video Over Hybridcast,” ITE Journal, Vol.71, No.6, pp.802-805 (2017) (in Japanese)

16) Mitsubishi Research Institute, Inc.: “Adoption of the proj-ect: ‘Demonstration experiments of technologies to improve broadcast services using broadband’,” https://www.mri.co.jp/news/press/public_offering/result/023169.html (in Japanese)

17) SKY Perfect JSAT Corp.: “SKY Perfect! Hybrid Starts De-cember 1,” https://www.sptvjsat.com/load_pdf.php?pTb=t_news_&pRi=1049&pJe=1

18) IPTV Forum: “Design and use of a logo for receivers sup-porting Hybridcast 4K Video,” http://www.iptvforum.jp/info/2018/05151434.html (in Japanese)

19) M. Hirabayashi: “MPEG-DASH Technology Overview for Network Video Service, MPEG Standardization Trends and Related Technology Trends,” ITE Journal, Vol.67, No.2, pp.109-115 (2013) (in Japanese)

20) ETSI TS 103 285, “MPEG-DASH Profile for Transport of ISO BMFF Based DVB Services over IP Based Networks”

21) ETSI TS 102 769 v.1.3.1 (HbbTV 2.0) (2015) 22) A/300:2017, “ATSC 3.0 SYSTEM”23) S. Sekiguchi: “A Development of Multi-View Streaming Sys-

tem Using MPEG-DASH,” ITE Annual Convention, 22D-1 (2017) (in Japanese)

24) S. Nishimura: “Development of a Hybridcast compatible MPEG-DASH player, No.771, 2016, pp.46-47 (2016) (in Jap-anese)

25) DASH Industry Forum, https://dashif.org26) ARIB STD-B62 Volume 1 Part 3[8]27) Ministry of Internal Affairs and Communications: “Sum-

mary of results from the Study Group on Enhancing Broad-

cast Services,” p. 10, http://www.soumu.go.jp/main_con-tent/000230953.pdf (in Japanese)

28) Ministry of Internal Affairs and Communications: “11th Meet-ing of the Committee to Promote production and distribution of Broadcast Content (WG coalition) Reference 11-3 Project to demonstrate enhancements to broadcast services using broad-band,” http://www.soumu.go.jp/main_content/000532910.pdf (in Japanese)

29) The WebSocket API, https://www.w3.org/TR/websockets/30) RFC3926, FLUTE — File Delivery over Unidirectional

Transport, https://tools.ietf.org/html/rfc3926

19