解説03

テレビ向け動画配信技術の 研究開発動向～ハイブリッドキャスト対応テレビ向け動画配信サービス “ハイブリッドキャストビデオ” ～

西村　敏

ハイブリッドキャストは，2014年12月に4K配信にも対応したビデオオンデマンド（VOD：Video on Demand）技術方式が追加されて以来，複数の放送事業者により放送を起点とした4K配信の実証実験に活用されるなど，テレビ向け動画配信の基盤技術として注目されるようになってきた。本稿では，同方式の運用方法や受信機の技術要件を明確化した仕様に基づく動画配信サービス「ハイブリッドキャストビデオ／ハイブリッドキャスト4Kビデオ」の技術要素について解説するとともに，ハイブリッドキャストビデオの仕組みを活用した実証実験の事例を紹介する。

１．はじめに2014年12月，ハイブリッドキャスト運用規定IPTV-FJ STD-0013 1）の2.0版において，

HTML5（HyperText Markup Language 5）に対応したテレビ向けの新しいVOD技術方式（以下，新VOD技術方式）が追加された2）。新VOD技術方式は，国際標準の動画配信方式であるMPEG-DASH（MPEG Dynamic Adaptive Streaming over HTTP）3）を採用するとともに，テレビ受信機上で動作する動画視聴プレーヤーを， MSE/EME（Media Source Extensions 4） / Encrypted Media Extensions 5））を利用してJavaScript言語で記述することを前提としている。MSE/EME は，HTML5のvideo要素＊１の拡張機能であり，Web技術の標準化団体W3C（World Wide Web Consortium）で規格化された。新VOD技術方式の大きな特徴は，テレビ向けのオープンな規格としては，世界で初めてMSE/EMEを採用した点である。

これらの新しい技術の登場と，インターネット接続環境の充実も相まって，ネット動画を積極的に活用する新たなサービス提供への期待が高まり，2015年以降，複数の放送事業者によりハイブリッドキャストを起点とした4K動画配信の実証実験が実施された6）～15）。2017年には，総務省による「ブロードバンドの活用による放送サービスの高度化に向けた技術等検証」事業16）において，９つのコンソーシアムにより，ハイブリッドキャストの活用による4Kコンテンツの放送同時配信の実証実験が行われた。この実証実験は，ハイブリッドキャスト対応4Kテレビを活用した新たな放送サービスの普及促進に向け，技術・運用面での課題や方策案の整理を目的としていた。さらに，放送とオンデマンドの違いを意識せずに，番組表で選択するだけで過去に放送した番組のオンデマンド視聴が行えるサービス17）が開始されるなど，新VOD技術方式は，放送事業者によるテレビ向け動画配信の基盤技術として注目を集めている。

＊１Webページに動画を埋め込むために使用するHTML文書の要素。

20 NHK技研 R&D ■ No.171 2018.9

解 説 03

しかし，このような取り組みを通じて，受信機によって振る舞いが異なること，実現したいサービスに必須な機能への対応状況がまちまちであること，受信機がどの機能に対応しているかが不明瞭であること，などの点が課題として挙げられた。そこでIPTVフォーラムでは，放送事業者のサービス要件や運用方法を整理するとともに，受信機が実装すべき機能等の技術要件を明確化した仕様を策定した。また，同仕様に適合した受信機や動画配信サービスに対し，2K対応の「ハイブリッドキャストビデオ」および4K対応の「ハイブリッドキャスト4Kビデオ」の呼称を用いるとともに，受信機や番組が同仕様に対応していることを分かりやすく判別するためのロゴマーク（１図）を策定し，2018年５月に公表した18）。

NHKはこれまでに，新VOD技術方式に準拠し，テレビ受信機で安定に動作する動画視聴プレーヤーを開発し，IPTVフォーラムのMPEG-DASH相互運用性検討会の会員向けにリファレンスモデルとして公開するとともに，ハイブリッドキャストビデオの仕様策定や，同仕様への受信機の適合性を判定するための検証コンテンツの整備に貢献してきた。

本稿では，ハイブリッドキャストビデオの技術要素として，MPEG-DASHと，MSE/EMEを利用した動画視聴プレーヤーについて解説するとともに，ハイブリッドキャストビデオの特徴的な技術要件について述べる。また，放送事業者による実証実験の事例を紹介する。

２．MPEG-DASH２．１　動画配信方式の動向

近年の動画配信では，動画配信専用のプロトコルによる配信方式に代わり，テキストや画像といったウェブページを構成するファイルの配信と同様に，HTTP（Hypertext Transfer Protocol）により動画を配信するHTTPストリーミング方式が主流となっている。

HTTPストリーミング方式は，動画配信専用の特殊なサーバーを必要としないことに加え，ウェブサイトの高速化・大規模化に利用されるCDN（Contents Delivery Network）をそのまま適用できることから，従来の動画配信システムと比べて低コストかつ大規模な配信を実現できる。また，ネットワークの混雑状況に応じて動的に映像品質を切り替えるアダプティブストリーミングと呼ばれる機能を備えることにより，途切れにくい安定した配信を実現できる。

このような方式としては，ITベンダーの独自方式であるApple HLS（HTTP Live Streaming），Adobe HDS（HTTP Dynamic Streaming），Microsoft Smooth Streamingに加え，国際標準化機関ISO/IEC（International Organization for Standardization ／International Electrotechnical Commission：国際標準化機構／国際電気標準会議）に

１図　ハイブリッドキャストビデオのロゴマーク

（出典）http://www.iptvforum.jp/info/files/180515.pdf

「ハイブリッドキャスト4Kビデオ」アイコン（ロゴマーク）

（Hybridcast 4K Video）

「ハイブリッドキャストビデオ」アイコン（ロゴマーク）（Hybridcast Video）

21NHK技研 R&D ■ No.171 2018.9

より規格化されたMPEG-DASHなどが挙げられる19）。これらの方式の中でも，MPEG-DASHは，国際標準であることから放送での利用が進

んで おり，DVB（Digital Video Broadcasting）20），HbbTV21），ATSC（Advanced Television Systems Committee）22）などの規格で採用されているほか，BBC iPlayer，YouTube，Netflixなどの大手動画配信サービスでも利用が進んでいる。

２．２　MPEG-DASHの基本動作MPEG-DASHのコンテンツは，エンコードした動画を数秒単位に分割した「セグメント」

と呼ばれる動画ファイルと，ストリーミング再生に必要な情報を記述したメタデータファイルであるMPD（Media Presentation Description）とで構成される。MPDには，動画のエンコードパラメーター（符号化方式やビットレートなど）や，セグメントの情報（セグメントの分割単位や取得先など）が記述されている。

ここで２図を基に，MPEG-DASHによるアダプティブストリーミングの動作を説明する。動画サービスの提供者は，あらかじめ１つの映像素材から品質（解像度やビットレート）

が異なる複数の動画を生成し，それらを時刻の切れ目をそろえてセグメントに分割するとともに，すべての動画の情報を含むMPDファイルを生成する。これらのファイルはWebサーバーに供給される。

受信端末は，まずWebサーバーからMPDファイルを取得し，セグメントの構成を把握する（２図①）。続いて，ネットの混雑状況や視聴環境（端末の画面解像度など）に合わせた品質のセグメントを適宜選択して受信し（２図②），分割した順番どおりにつなぎ合わせて再生する（２図③）。この動作を繰り返すことで，突然ネットが混雑しても途切れることなく視聴を継続できる。

２．３　MPDの構成と実現可能なサービスMPEG-DASHでは，前節で述べたアダプティブストリーミング機能に加え，マルチビュー

映像・多言語音声切り替えや，放送のように編成に従った番組配信などのサービスを想定したコンテンツの記述が可能である。これらの実現方法を，３図のMPDの内容を参照しながら簡単に説明する。

MPDはPeriod，AdaptationSet，Representationの順に階層構造で記 述される。

２図　MPEG-DASHによるアダプティブストリーミングの動作概要

１つの映像を複数品質でエンコードし，切れ目をそろえてセグメントに分割

WebサーバーMPDファイル

（Media Presentation Description）

セグメントエンコーダー

高品質中品質低品質

受信端末

動画再生バッファー

②ネットの混雑状況を基に　セグメント単位で品質を選択して受信

ネットの混雑状況

回線速度

③受信したセグメントを　MPDに従って順番どおりに　つなぎ合わせて再生

①MPDファイルを取得し　セグメントの構成を把握・ビットレート

・解像度・セグメントの分割単位・セグメントの取得先　　…

1

1’

1”

2

2’

2”

3

3’

3”

4

4’

4”

1”2’34”

22 NHK技研 R&D ■ No.171 2018.9

解 説 03

Periodは１つの番組やチャプターを表しており， ３図の例では， それぞれの番組尺（duration）が５分の，２つのPeriodを連結した構造を示している。このように時間軸上に複数のPeriodを次 と々連ねて記述することをマルチピリオドと呼ぶ。これにより，放送のように編成に従った番組配信が可能になるとともに，番組の間に広告を挿入する用途にも利用可能となる。

Periodは複数のAdaptationSetから構成される。AdaptationSetはメディア要素（映像，音声，テキスト等）の情報を示し，同じメディア形式であっても表現（別角度の映像や，別言語の音声など）の異なるメディア要素を複数含むことができる。例えば３図では，映像

（mimeType= “video/mp4”）を２つ含んでいる。こうすることで，複数の映像から１つの映像を選択したり，途中で映像を切り替えたりする視聴方法を実現できる。この機能を応用して，当所では，複数カメラの映像をネット配信し，PC（パソコン）やスマートフォンのWebブラウザーでスムーズに切り替えながら視聴できる多視点ストリーミング技術を開発した23）。

AdaptationSetに記載されたメディア要素に関するビットレート（bandwidth）や解像度などの情報はRepresentationに記述される。 ビットレ ートや解像度が異なる複数のRepresentationを用意することで，アダプティブストリーミングを実現できる。

Representationには，メディア要素を構成する実データであるセグメントの情報（３図のmedia，initialization） が記述される。mediaは分割された動画フ ァ イ ル であり，initializationは符号化パラメーター等の初期化情報である。再生時刻とセグメントとの対応関係の記述方法は何通りかあるが，３図の例では，セグメント長（duration=5s）ごとにシーケンス番号（$Number$）がインクリメントされたファイル名となる記述方法を示している。この情報を基に，現在の再生時刻に対応する映像・音声のセグメントのURL（Uniform Resource Locator）を特定して受信することで，目的のシーンの動画を再生することができる。

３図　MPDの概要（抜粋）

<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>

23NHK技研 R&D ■ No.171 2018.9

３． ハイブリッドキャストにおけるMPEG-DASHコンテンツの再生

３．１　MSE/EME（HTML5のvideo要素の拡張機能）の概要HTML5における動画再生機能としては，当初からvideo要素があった。しかし従来の

video要素は，指定したURLの動画ファイルをダウンロードしながら再生するプログレッシブダウンロード方式にのみ対応しており，アダプティブストリーミングや，ライブ配信，あるいはDRM（Digital Rights Management）で保護されたコンテンツの再生など高度なサービスへの対応が困難だった。

したがってPCなどのWebブラウ ザ ー向けの動画配信では， 長らくAdobe FlashやMicrosoft Silverlightに代表されるプラグイン＊２を用いた動画視聴プレーヤーが利用されてきた。しかし，スマートフォンによる動画再生への需要の高まりから，プラグインの利用に伴う消費電力の増加やセキュリティーリスクの増加などが課題となり，プラグインを排除する動きが進行した。

そこで，W3Cでは，HTML5のvideo要素で前述のような高度なサービスに対応した動画再生を可能とする拡張規格として，動画再生の制御を扱うMSEと，コンテンツ保護を扱うEMEの規格化が行われ，すでに多くのWebブラウザーに実装されている。従来は，動画のソースとして動画ファイルのURLを指定できるのみであり，ブラウザーとサーバーの間でデータをやり取りする方法に関してはブラウザーの実装に任せられていたため，アプリケーション開発者が手を入れられる範囲が限定されていた。この拡張規格により，動画のソースとしてMSEによって生成された再生バッファーを指定できるようになった。これにより，MPEG-DASH動画の再生に必要な動画データのやり取りや，再生バッファーへのデータ挿入，再生制御などの動画視聴プレーヤー機能を一通りJavaScript言語のみで記述できるようになったため，開発者による柔軟なカスタマイズが可能となった。

３．２　iptvfj-dash対応動画視聴プレーヤー先に述べたIPTVフォーラムによる新VOD技術方式の中で策定された，MPEG-DASH

を利用してVODサービスを運用するためのプロファイル＊３ を「IPTV Forum Japan MPEG-DASHプロファイル」（以下，iptvfj-dash）と呼ぶ。ハイブリッドキャストにおける従来のobject要素＊４を用いるVOD方式と異なり，iptvfj-dashに対応したVODでは，視聴プレーヤーをサービス提供者がJavaScriptプログラムとして用意する。この場合，視聴プレーヤーは，受信機が動画サービスのWebサイトにアクセスする度に，HTMLやCSS

（Cascading Style Sheets）＊５といったWebページの構成要素とともにWebサーバーから配信される。そのため，テレビ受信機メーカーはテレビ受信機に独自の視聴プレーヤーを組み込む代わりに，HTML5対応Webブラウザーを搭載するだけでよくなった。これにより，サービスに特化した視聴動作の実現や，ユーザーインターフェースの変更などが容易になり，多彩な動画配信サービスの展開に結び付くことが期待された。

しかしながら，放送事業者等の各サービス提供者が視聴プレーヤーを自ら開発することは多大な労力を要することに加え，受信機メーカーにとっても，振る舞いや性能が異なる多様な視聴プレーヤーの動作検証を行うことは逆にコスト高となることが予想された。

そこで当所では，新VOD技術方式の規格化と並行して，同規格に準拠し，テレビ受信機でMPEG-DASHコンテンツを安定に再生する機能や，新たなサービスの開発を支援するAPI（Application Programming Interface）＊６を備えた動画視聴プレーヤーソフトウエ

＊2ソフトウエアに機能を追加するための小規模なプログラム。

＊3規格や規定のうち，必要な用途を実現するための機能を定義したもの。

＊4Webページにプラグインなどの外部リソースを埋め込むために使用するHTML文書の要素。

＊5Webページのレイアウトやデザインを定義するための言語。

＊6ソフトウエアの機能を別のソフトウエアから利用するためのインターフェース。

24 NHK技研 R&D ■ No.171 2018.9

解 説 03

ア「dashNX」を開発した24）。本ソフトウエアは，テレビ受信機のCPUやメモリー等のリソースがPCと比べて少ないこと，一度に複数のvideo要素を利用できないことなどの制約や，放送事業者のサービス要件を考慮して，PC向けのJavaScriptベースの視聴プレーヤーとしてDASH Industry Forum 25）が公開しているdash.jsを基に，テレビ受信機向けの機能を強化したものである。2016年１月にIPTVフォーラム内に発足したMPEG-DASH相互運用性検討会に本ソフトウエアを提供し，同検討会において，さまざまなサービス提供者が共通に利用可能なリファレンスモデルとして公開している。

dashNXを利用したiptvfj-dash対応動画視聴プレーヤーの全体構成を４図に示す。４図の再生制御ライブラリーは，MPEG-DASHコンテンツの受信制御や再生・一時停止・シークといった動画再生の基本動作を実現する機能に加え，多様なサービス要件を実現するために必要なAPIを備えたソフトウエアライブラリーであり，各サービスで共通に利用可能な部分である。本ライブラリーを「dashNX」と呼んでいる（動画視聴プレーヤー全体を指してdashNXと呼ぶ場合もある）。また，拡張アプリケーションは，このAPIを利用して利用頻度の高い機能をあらかじめ組み込んだ実装サンプルであり，ユーザーインターフェース（UI）とともに，サービス要件に応じてカスタマイズして利用することを想定した部分である。

dashNXは，テレビ受信機での安定再生を主な要件としたが，MSE/EMEに対応したWebブラウザーを搭載した端末であれば，スマートフォン，パソコン等でも動作可能なため，マルチデバイスで共通な視聴環境を実現できる（５図）。

なお， ここでは一例としてdashNXによる動画視聴プレーヤーについて述べたが，JavaScriptで記述できるという性質上，独自で開発することや，他のソフトウエアを利用してサービスを構築することも可能である。

４図　dashNXを利用したiptvfj-dash対応動画視聴プレーヤーの全体構成

５図　 dashNXによるマルチデバイスでの再生状況

パソコン用UI テレビ用UI

拡張アプリケーション

再生制御ライブラリー（dashNX）サービス提供者が

Webサイトから提供

デバイス

組み込み HTML5ブラウザー（MSE/EME）

Video/Audioデコーダー

スマートフォン用UI

25NHK技研 R&D ■ No.171 2018.9

４．ハイブリッドキャストビデオの技術要件本章では，ハイブリッドキャストビデオの特徴的な技術要件について述べる。

４．１　IPTV Forum Japan MPEG-DASHプロファイル（iptvfj-dash）の概要iptvfj-dashでは，映像・音声の符号化方式やMPDの記述に対する制約などが規定され

ている。映像の符号化方式については，H.264｜MPEG-4 AVC（Advanced Video Coding）ま

たはH.265｜MPEG-H HEVC（High Efficiency Video Coding）を利用する。2K以下の解像度においては，基本的にH.264を利用するが，2017年７月の運用規定2.5版への改定においてH.265もオプション扱いとして導入された。4K解像度においてはH.265を利用する。セグメントのフォーマットはISO Base Media File Format＊７を利用し，セグメント長は１秒から15秒の範囲としている。また，映像と音声は別々のセグメントとしている。

MPDについては， ２．３ 節で述べた階層構造の中で，Period，AdaptationSet，Representaionのそれぞれを複数個含むことができるようになっており，マルチピリオドによる番組切り替え，マルチビュー映像・多言語音声の切り替え，アダプティブストリーミングなどの運用を想定した記述が可能となっている。

アダプティブストリーミングの運用に関しては，符号化レート，プロファイル・レベル＊8，垂直・水平解像度が異なる映像リプレゼンテーション（Representation）（映像の提示方法）の遷移が可能となっている。

そのほか，ARIB-TTML（Timed Text Markup Language）26）＊9を用いた字幕の運用やDRMの扱いなどを規定している。

４．２　VOD再生中の汎用イベントメッセージの受信汎用イベントメッセージ（以下，EM）は，受信機で動作しているアプリケーションに対し

て放送局から一斉にトリガー情報等を送ることができる手段であり，緊急時におけるアプリケーションの提示制御など，「視聴者の安全・安心の確保」の基本理念27）の観点から非常に重要な機能である。

しかし実証実験等で検証した結果，現在市販されているテレビ受信機では，VOD再生中のEM受信に対応している機種が限定的であることが分かった。これは，ハイブリッドキャストにおける従来のobject要素を用いたVODに関する規定の中で，当該機能への対応を必須としていなかったことが背景にあると考えられる。

そこで，IPTVフォーラムは，視聴者がVODを再生中であっても，放送信号により伝送した緊急情報を含むEMによってVODを強制終了させ，放送に引き戻すといったユースケース等を想定し，VOD再生中のEM受信をハイブリッドキャストビデオの必須要件とした。また，放送局の現状の運用として，EMをスクランブル化して送出する場合もあることから，スクランブル・ノンスクランブル双方のEMに対応することを必須としている。

４．３　マルチピリオドによるシームレスなコンテンツ切り替えdashNXは，２．３節で述べた複数のピリオド（Period）を連結したマルチピリオド形式

のMPDを受信すると，その記述に従ってさまざまなサーバーにある動画をつなぎ合わせて再生することができる。６図にその一例として，番組本編に視聴者ごとに別の動画クリップを挿入したMPDを用意することで，視聴者に応じて動画クリップを差し替える例を示し

＊7MPEG-4の 第12部（ISO/IEC 14496-12）で規定されている動画などのメディアファイルの形式。

＊8ビットストリームをデコードするのに必要な性能を示すパラメーター。

＊9ARIBの標準規格となっているマークアップ言語。テキストの表示タイミングと表示位置などを規定し，字幕などの記述に利用される。

26 NHK技研 R&D ■ No.171 2018.9

解 説 03

ている。この機能を応用することによって，番組の途中に地域属性等に合わせて視聴者ごとに別の広告を挿入するなど，新たなビジネス展開につながることが期待されている。そのための技術要件としては，ピリオド間がシームレスにつながることや，受信機の再生動作が統一されていることが望ましい。

しかし実際には，７図①に示すように，MPEG-DASHコンテンツの生成の過程で，MPDに記載されているピリオド長よりも実際のメディア長が僅かに短くなることがある。この場合，ピリオドのつなぎ目でバッファー内に時間的な隙間が生じ，再生が停止する状況に陥る。動画視聴プレーヤーの実装次第で再生を継続させることは可能であるが，MSE規格ではバッファー内に隙間が生じた場合の振る舞いは実装依存のため，受信機の再生動作の統一が難しい。一方で，バッファー内でメディアデータが時間的に重複した場合は，後からバッファーに挿入したメディアデータで上書きして隙間なくつなげるという規定がある。

そこで，７図②のようにピリオドの最後に捨てカットを付与し，必ず次のピリオドと重複するように運用することによって，シームレスな切り替えと再生動作の統一を図ることが可能と考えられる。

しかし実証実験等の結果から，バッファー内の上書き動作がMSE規格どおりとなって

６図　視聴者に応じた動画クリップの挿入・差し替え

７図　ピリオドのつなぎ目におけるバッファーの状態

Clip-A配信Webサーバー

番組配信Webサーバー

Clip-B配信Webサーバー

視聴者B視聴者A

Clip-A

視聴者ごとのMPD

番組 Clip-B

MPD配信Webサーバー

00：00：00　番組前半00：15：00　Clip-A00：16：00　番組後半

00：00：00　番組前半00：15：00　Clip-B00：16：00　番組後半

再生中のピリオド

ピリオド長（MPD内のメタ情報）

実際のメディア長

①バッファー内に時間的な隙間が生じ，　ピリオドのつなぎ目で再生が停止

次のピリオド

次のピリオド再生中のピリオド

再生中のピリオド

隙間

バッファー挿入

ピリオド長

実際のメディア長

②重複する部分を次のピリオドで　上書きし，シームレスに切り替え

次のピリオドex

次のピリオド再生中のピリオド

上書き

捨てカット

バッファー挿入

27NHK技研 R&D ■ No.171 2018.9

いない受信機が存在することが分かった。そこでIPTVフォーラムは，上記の上書き動作が規格どおり実装されていることをハイブリッドキャストビデオの必須要件とした。

また，現実的な運用を想定し，ピリオドごとにDRMの暗号キーが異なる，あるいはDRMを適用したピリオドと非適用のピリオドが混在するMPDにも対応することを必須としている。

４．４　検証コンテンツの整備IPTVフォーラムは，上記の技術要件を検証するための検証項目に加え，通常の運用

で想定しうるスキップなどの視聴操作の動作テスト，長尺番組の再生テスト，放送・VOD間の画面遷移等のハイブリッドキャスト固有のAPIの挙動テストなどを取りそろえた検証コンテンツを整備した。この検証コンテンツにより，受信機がハイブリッドキャストビデオの技術要件に適合しているか否かの判定が可能となった。

５．実証実験の事例ハイブリッドキャストビデオの仕組みを活用した実証実験の事例として，放送と同期し

た4K配信，地域に合わせたコンテンツ差し替え，およびハイブリッドキャスト対応受信機向けIPマルチキャスト4Kライブ配信について紹介する。

５．１　放送と同期した4K配信と地域に合わせたコンテンツ差し替え放送と同期した4K配信は，テレビ受信機上で放送と4K配信映像を切り替えながら番組

を視聴できる技術であり，フジテレビの事例6）をはじめとして，総務省実証実験28）などで多くの事業者により実験が行われた。視聴者が実験対象機種のテレビで番組を視聴していると，4K配信映像への切り替えボタンが表示され，リモコンで選択することにより，放送の進行と同期した場面から4K配信映像を視聴できる仕組みである（８図①）。昨今，放送事業者は4K番組の制作も盛んに行うようになってきたが，4K番組を地上波で放送する際には，2Kにダウンコンバートする必要がある。８図①の仕組みは，放送を起点として，4K番組を4K解像度のまま通信によって家庭で視聴可能とする手段として注目されている。

また，4K配信の実験の中で，マルチピリオドによるコンテンツ切り替え機能を利用して，受信機に登録されている郵便番号や放送波のnetwork_id＊10を基に，4K配信のCM部分を地域によって異なるCMに差し替える実験が行われ（８図②），４．３節で示した検証項目に対応している機種では問題なく再生されることが確認された。

さらに，災害等の発生時には，放送の番組内容が緊急特番に変更される場合があるため，4K配信の視聴中であっても受信機を直ちに放送映像に引き戻す仕組みについても検証が行われた（８図①）。緊急特番に変更したことを伝える緊急情報を放送波のイベントメッセージによって通知する手法に加え，HTTPにより受信機が定期的に緊急時か否かを確認する手法や，WebSocket 29）＊11によるサーバーからのプッシュ通知などのWeb技術を利用する手法について比較が行われた。４．２節で述べたとおり，現時点ではイベントメッセージによって通知する手法に対応した受信機が限定的であるという課題はあるものの，この手法はネットワーク負荷の低減や即時性の観点から非常に有効であるため，この手法に対応可能な受信機が早期に普及することを期待したい。

そのほか，総務省実証実験ではHDR（High Dynamic Range）方式のコンテンツの再生についても検証が行われ，HDR対応機種の判定方法や，HTML5のコンテンツとHDR動画を合成表示した場合の違和感が課題となった。実証実験当時のハイブリッドキャスト

＊10放送のネットワークを識別するためのID。地上デジタル放送では放送局ごとに異なる。

＊11Webアプリケーションにおいて双方向通信を実現するための技術規格。

28 NHK技研 R&D ■ No.171 2018.9

解 説 03

運用規定では，HDRに対する明確な規定がなかったため，現在規格化に向けて議論が進行中である。

５．２　ハイブリッドキャスト対応受信機向けIPマルチキャスト4Kライブ配信一般的なネット配信で用いられるユニキャストでは，受信機のリクエストに応じて一対一

でコンテンツを配信するため，視聴者数が増加するにつれてネットワークの負荷や配信コストが増加する。特に，4K映像のような高ビットレートの動画を配信する際には大きな課題となる。こうした背景から，ユニキャストに代えて一対多の放送型配信が可能なIPマルチキャストを利用した4Kライブ配信実験が，読売テレビの事例10）をはじめとして，総務省実証実験28）等で行われた。

実験構成の概念図を９図に示す。配信側では，4K映像をリアルタイムにエンコードしてMPEG-DASHセグメントを生成し，FLUTE（ File Delivery over Unidirectional Transport）30）＊12処理によりUDP（User Datagram Protocol）＊13パケット形式に変換してFTTH（Fiber To The Home）網やCATV網を介してIPマルチキャストで配信する。受信側では，ハイブリッドキャストを利用して放送とネット経由の4K映像をテレビリモコンで切り替えて表示する。ただし，ハイブリッドキャストがベースとしているHTML5にはマルチキャストを扱うAPIが存在しないことから，4K映像の視聴は，宅内に設置した専用ゲートウェイ＊14でIPマルチキャストを受信し，MPEG-DASHセグメントを復元したうえで，ユニキャストで受信機に配信する仕組みで実現された。

また，複数の放送事業者が同時に4K配信をする状況を想定し，マルチキャストの仕組みにより，4K配信映像間でチャンネルを切り替える実験が行われた。高ビットレートの4K配信映像同士を直接切り替える場合，チャンネル切り替え操作を行ってから4K配信映像

＊12放送波や片方向伝送路でファイルを分割して転送する仕組み。

＊13インターネットでデータ通信に用いられるプロトコルの一種。処理は高速だが，到達の信頼性は低い。

＊14通信手順が異なるネットワークとネットワークを接続するための機器やソフトウエア。

８図　放送と同期した4K配信と地域に合わせたコンテンツ差し替えの概念図

９図　ハイブリッドキャスト対応受信機向けIPマルチキャスト4Kライブ配信実験の構成概念図

①放送と同期した4K配信

同期情報・緊急情報

放送 ネット 番組本編 地域ごとのＣＭ

番組本編①

地域A 地域B

CM 番組本編②

緊急情報

切り替え

②地域に合わせたコンテンツ差し替え

放送（2K） ネット（4K）

4K配信

【配信側】 【受信側】 放送（2K）

4K映像

ライブエンコード/MPEG-DASH化

FLUTE処理（UDPパケット化）

IPマルチキャストWebサーバー

宅内の専用ゲートウェイ

FLUTE処理（MPEG-DASH復元）

IPマルチキャスト受信

IPマルチキャスト配信

FTTH網or

CATV網

2K/4K

29NHK技研 R&D ■ No.171 2018.9

の取得を開始するため，再生開始までの遅延が大きい。そこで，あらかじめ全チャンネルの低ビットレートの4K映像を配信しておき，チャンネル切り替え直後は低ビットレートの映像から視聴を開始し，高ビットレートの4K映像の準備ができた段階でアダプティブストリーミングの機能によってシームレスに高ビットレートの4K映像に遷移する仕組みにより，切り替え時間を短縮できることが確認された。

なお，IPマルチキャストのようなUDP通信においては，回線の混雑時にパケットロスにより，一部のMPEG-DASHセグメントの欠落が生じることが想定される。そのような場合に，動画視聴プレーヤーがどのように動作すべきかについては，個別の要件やサービスに依存する部分であり，明確な規定はない。

IPTVフォーラムのMPEG-DASH相互運用性検討会では，上記のような事象も含め，MPEG-DASHによる動画配信や動画視聴プレーヤーに関する課題とノウハウを共有する場を設けている。同検討会の活動が活性化することで，安定した動画配信サービスの発展に貢献していくことが期待される。

６．まとめ本稿では，ハイブリッドキャストの新VOD技術方式の運用方法や受信機の技術要件を

明確化した仕様に基づく動画配信サービス「ハイブリッドキャストビデオ／ハイブリッドキャスト4Kビデオ」の技術要素および技術要件について解説した。また，ハイブリッドキャストビデオの仕組みを利用した4K配信の実証実験の事例を紹介した。

技術要件の明確化とロゴマークの策定により，放送局がより手軽に多様なサービスを提供できる環境が整うとともに，視聴者が対応受信機を分かりやすく見分けることができるようになり，ハイブリッドキャストの本格的な普及が加速するものと考えられる。こうした取り組みにより，多くのサービス事業者や開発者が参入し，視聴者にとって魅力的で新しい放送通信連携サービスが創出されていくことを期待したい。

参 考 文 献1） IPTVFJ STD-0013，“ハイブリッドキャスト運用規定”

2） IPTVフォー ラム：“HTML5に対応したテレビ向けの新しいVOD技術方式を公開,” http://www.iptvforum.jp/info/2014/12191501.html

3） ISO/IEC 23009-1:2014，“Information Technology — Dynamic 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/encrypted-media/

6） 伊藤：“現状地上波でHD/4Kサイマル視聴サービスを実現するハイブリッドキャストコンテンツ（4Kランドスケープ）,” 映情学誌，Vol.71，No.4，pp.J125-J130 （2017）

7） 名古屋テレビ：“ハイブリッドキャストの4K動画配信技術を使って地上波と4K動画の同時配信を実 施,” https://www.nagoyatv.com/archives/024/201603/8742e82da7baf4cee8c3b7bdbee1c21e.pdf

30 NHK技研 R&D ■ No.171 2018.9

解 説 038） TOKYO MX：“地上波レギュラー番組で初！ ハイブリッドキャストを利用して4K動画の本格配

信実験を開始,” http://s.mxtv.jp/company/press/pdf/press2016_120001.pdf

9） 日経ニューメディア：“関西テレビがハイブリッドキャストを活用した4K映像のライブ配信実験に成功,” http://tech.nikkeibp.co.jp/it/atcl/news/16/062201814/

10） 読売テレビ：“MPEG-DASH方式による「 4K映像のIPマルチキャスト配信実験 」を実施,” http://www.ytv.co.jp/fromytv/news/number/page_2002134.html

11） 日本放送協会：“リオオリンピックの実験的な4Kネット配信について,” https://www.nhk.or.jp/pr/keiei/shiryou/kaichou/2016/07/003.pdf

12） 名古屋テレビ：“メ～テレ，ハイブリッドキャストによる放送と連動した複数コンテンツの4K配信を実施,” https://www.nagoyatv.com/archives/024/201612/7ce1f6d043e9f14b9b4f6d0e634a080f.pdf

13） フジテレビ：“地上波と同時4K配信で地域ごとにCM配信,” http://www.fujitv.co.jp/fujitv/news/pub_2016/161111-m047.html

14） 伊藤：“フジテレビの取り組み　放送と配信動画の連携,” 映情学誌，Vol.71，No.6，pp.797-801 （2017）

15） 原：“メ～テレのハイブリッドキャスト4Kビデオの取り組み,” 映情学誌，Vol.71，No.6，pp.802-805 （2017）

16） 三菱総合研究所：“「ブロードバンドの活用による放送サービスの高度化に向けた技術等検証」事業の採択について,” https://www.mri.co.jp/news/press/public_offering/result/ 023169.html

17） スカパー JSAT：“スカパー！ハイブリッド，12月１日スタート,” https://www.sptvjsat.com/load_pdf.php?pTb=t_news_&pRi=1049&pJe=1

18） IPTVフォーラム：“ハイブリッドキャスト（ 4K）ビデオ対応の受信機向けアイコン（ロゴマーク）を策定・運用を開始しました。,” http://www.iptvforum.jp/info/2018/05151434.html

19） 平沼：“次世代動画配信技術「MPEG-DASH」技術概要と標準化・関連技術動向,” 映情学誌，Vol.67，No.2，pp.109-115 （2013）

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） 関口：“MPEG-DASHを用いた多視点映像ストリーミング方式の検討,” 映情学年次大，22D-1 （2017）

24） 西村：“ハイブリッドキャスト対応MPEG-DASH動画視聴プレーヤーの開発,” 映画テレビ技術，No.771，2016，pp.46-47 （2016）

25） DASH Industry Forum，https://dashif.org

26） ARIB STD-B62 第一編第３部[8]

27） 総務省：“「放送サービスの高度化に関する検討会 これまでの検討結果取りまとめ」,” p.10，http://www.soumu.go.jp/main_content/000230953.pdf

28） 総務省：“放送コンテンツの制作・流通の促進等に関する検討委員会（第11回）（WG合同）資料11—3　ブロードバンドの利用による放送サービスの高度化に向けた技術等検証事業,” http://www.soumu.go.jp/main_content/000532910.pdf

29） The WebSocket API，https://www.w3.org/TR/websockets/

30） RFC3926，FLUTE — File Delivery over Unidirectional Transport，https://tools.ietf.org/html/rfc3926

西にし

村むら

敏さとし

2000年入局。 広島放送局を経て，2003年から放送技術研究所において，インターネットを利用した動画配信基盤技術の研究に従事。現在，放送技術研究所ネットサービス基盤研究部上級研究員。

31NHK技研 R&D ■ No.171 2018.9