報告 ８Kスーパーハイビジョン衛星放送 システムにおけるMMTによる アプリケーション伝送方式の性能評価 大槻一博 河村侑輝 青木秀一 中村直義 木村武史 Performance Evaluation of MMT−based Application Transmission Scheme in 8K Super Hi−Vision Satellite Broadcasting Systems Kazuhiro OTSUKI，Yuki KAWAMURA，Shuichi AOKI，Naoyoshi NAKAMURA and Takeshi KIMURA 要約 ８Kスーパーハイビジョン衛星放送におけるMMT（MPEG Media Transport）を用いたアプリ ケーション伝送方式に関して，当所の提案内容を含む方式がARIB（Association of Radio Industries and Businesses：電波産業会）の標準規格に採用された。本稿では，提案方式と他 の方式を比較するとともに，シミュレーションによる性能評価を行う。その結果として，MPU （Media Processing Unit）モードのMMTプロトコルがアプリケーションの伝送に適しているこ と，提案方式により現行のデジタル放送と同様の繰り返し伝送が可能であること，２つの管理 テーブルが制作時と伝送時のディレクトリー構成を分離するための機能を果たしていること，伝 送パケットの最大サイズを増やすことでファイルの取得時間が短くなることなどを述べる。 ABSTRACT Our MMTbased application transmission scheme for 8K Super HiVision satellite broadcasting was adopted as an ARIB standard. Here, we compare this scheme with other schemes and evaluate its performance by simulation. As a result, we find that the MPU（Media Processing Unit）mode of the MMT protocol is suitable for the application transmission scheme and is able to transport files like data carousel transmission in current digital broadcasting. We also describe that two management tables function as separate directory layouts for production and transmission and that the acquisition time is shortened by increasing the maximum size of the transport packets. NHK技研 R&D/No.150/2015.3 35 報告 １．はじめに れるデータの種類がどのようなものか，どの伝送路 2016年の試験放送を目指して開発が進められている８ で送られているか，などの情報を，送信側から受信 Kスーパーハイビジョン（以下，８K）衛星放送の多重方 側へ伝える機能である。シグナリングの要件は，伝 式の規格化がARIBで完 了 し た。こ の 方 式 は，MPEG 送するファイルの構成や更新の管理・制御が可能な （Moving Picture Experts Group）で標準化が完了した ことと，アプリケーションの制作時と伝送時のディ １） ２） MMT をベースとし，当所が提案した内容 を含むものと レクトリー構成の分離（5.2節を参照）が可能なこ なっている。８K衛星放送においては，８K解像度による とである。 映像，22.2ch音響による音声だけでなく，大画面・高精細 （２）カプセル化とは，データを，その種類に応じて最適 なディスプレーを有効活用したデータコンテンツによる高 な形式に収める機能である。カプセル化の要件は， 機能なサービス（以下，アプリケーションと呼ぶ）も期待 オーバーヘッド＊１が少ないことと，アプリケー されている３）４）。 ションのファイル単体でカプセル化が可能なことで 現行のデータ放送では，ニュース・気象情報・スポーツ ある。 など一般的な情報や，番組に連動した関連情報のサービス （３）伝送とは，シグナリングの情報およびデータの種類 が行われている。このサービスを実現するために，データ に応じて適切にカプセル化されたデータを，信頼性 放送を構成するテキストファイルや画像・音声データ等 や同期性を確保しながら送る機能である。伝送の要 は，放送波で繰り返し伝送されている。放送波は双方向の 件は，繰り返し伝送が可能なこと，ハイブリッド配 通信とは異なり，所望のデータをリクエストして取得する 信＊２が可能なこと，アプリケーションやフォント ことはできないため，視聴者がどのタイミングで受信して （字体）などのダウンロード伝送が可能なことであ も，一定時間受信し続けることで所望のデータを取得でき る。 るようになっている。また，現行のデータ放送において 上記の要件を満たすシグナリングの機能として，２つ は，アプリケーション制作時のディレクトリー構成と伝送 のテーブルと１つのメッセージから成る制御情報を提案 時のディレクトリー構成が密接に関連しているため，デー した（３章を参照） 。また，カプセル化および伝送の機能 タ放送コンテンツを制作可能な制作者は，伝送時のディレ として，MPUモードの伝送プロトコルを提案した（４章 クトリー構成を把握できる一部の制作者に限られる。 を参照） 。 今回の提案内容により実現されるアプリケーション伝送 方式においては，現行のデータ放送と同様に，8K衛星放 送においても，アプリケーションを構成するファイルを放 ３．アプリケーション伝送のために用いる 制御情報 送波で繰り返し伝送することが可能である。また，アプリ 本章では，ARIBで規格化されたアプリケーション伝送 ケーション制作時のディレクトリー構成と伝送時のディレ 方式で用いられる制御情報について述べる。当所から提案 クトリー構成を分離することができるので，一般のアプリ した制御情報は，ファイルの構成とバージョンに関する情 ケーション制作者が広くコンテンツ制作を行うことが可能 報によりファイルの更新管理を可能とする「データアセッ となる。そのため，８K衛星放送において，現行のデータ ト管理テーブル」 ，アプリケーションの制作時のディレク 放送と同様なサービスを提供できるとともに，柔軟なアプ トリー構成と伝送時のディレクトリー構成とを分離するた リケーション制作の実現が期待できる。 めの「データディレクトリー管理テーブル」 ，これらの 本稿では，提案したアプリケーション伝送方式につい テーブルを格納して伝送するための「データ伝送メッセー て，要件を整理し，具体的な方式の内容を説明する。ま ジ」の３種類である。また，受信機において柔軟で有効 た，他の方式との比較を行い，本方式の有効性を検証す なキャッシュ制御＊３を実現するための「データコンテン る。さらに，シミュレーションによる性能評価を行い，そ ト管理テーブル」が併せて規格化された。 の結果を報告する。 3.1 データアセット管理テーブル データアセット管理テーブルは，アプリケーションを構 ２．アプリケーション伝送方式の要件の整理 成 す る フ ァ イ ル 本 体 が 伝 送 さ れ る 単 位 で あ るMPU MMTが担うトランスポート層において必要となる機能 は，シグナリング，カプセル化，伝送である。以下にその 説明と，それぞれの機能に対する要件を示す。 （１）シグナリングとは，アプリケーション層から出力さ 36 NHK技研 R&D/No.150/2015.3 ＊１ 正味のデータ以外の，ヘッダーやテーブルなどの付加的なデータ。 ＊２ 放送と通信等の複数の伝送路を用いる配信。 ＊３ 頻繁に読み出されるファイルのコピーを，すぐにアクセスできるよ うにメモリーやサーバーに置いておくこと。 （Media Processing Unit）＊４の構成とそのバージョン情報 を，アセット ＊５ ごとに提供するテーブルであり，現行の とで，データ伝送に関連した情報が一度に取得できる構成 となっている。 衛星および地上デジタル放送のデータカルーセル伝送方 式＊６におけるDII（Download Info Indication）の代替と ４．伝送プロトコルの他方式との比較 ARIBで規格化されたアプリケーション伝送方式におい 位置付けられる。 受信機は，このテーブルを常に監視することで，アプリ ては，伝送プロトコル＊９として「MPUモード」が用いら ケーションを構成するファイルが更新されたことを検知 れる。本章では，MPUモードの概要を説明し，他の伝送 し，アプリケーションを常に最新の状態で提示することが プロトコルと比較する。MPUモードと比較する他の伝送 可能となる。このテーブルは，アセット単位，MPU単位， プロトコルとしては，一般的なファイル伝送に用いるプロ ファイル単位と，各段階で更新の検知が可能なテーブル構 ト コ ル と し てMPEG規 格 内 で 規 定 さ れ て い るGFD （Generic File Delivery）モードのMMTプロトコルと， 成となっている。 3.2 データディレクトリー管理テーブル データディレクトリー管理テーブルは，アプリケーショ MMTを用いずにファイルをIP（Internet Protocol）で伝 送する既存の伝送プロトコル（ARIB STDB455）で規定） ンを構成するファイルの最新のディレクトリー構成を受信 について述べる。 機に通知するテーブルである。 4.1 MPUモード（非同期型） このテーブルを参 照 す る こ と に よ り，受 信 機 は， MPUモードにおいては，アプリケーションを構成する HTML5（Hyper Text Markup Language 5）な ど の ア データを，ファイル単位で非同期型＊10MPU（MPU for プリケーションの記述内でパス名を指定されたファイルの Nontimed Media）にカプセル化して伝送する。非同期 ノードタグ値 ＊７ を知ることができる。 型MPUによるカプセル化の構造を１図に示す。蓄積用の ノードタグ値により，前記のデータアセット管理テーブ フォーマットとしてのMPUは，MPUメタデータ＊11と１ ルを参照することで，受信機はアプリケーションが要求す つ以上のMFU（Media Fragment Unit）＊12から構成され るファイルがどのアセットに含まれているかを知ることが る。伝送を行う際には，MPUメタデータは伝送せず， できる。 MFUのみを伝送する。 ＊８ を構成するアセットの情報を提 １図においては，アプリケーションを構成する１つの 供するMPテーブル（MMT Package Table）を参照する ファイルを１つのMFUとする構成を基本とし，伝送の単 ことで，そのアセットがどの伝送路のどのパケットで伝送 位であるMMTP（MMT Protocol）ペイロードの最大サ されるかを示す情報を取得し，所望のファイルを受信する イズに比べてMFUのサイズが小さい場合には，複数の ことが可能となる。 MFUを 結 合（ア グ リ ゲ ー ト）し て１つ のMMTPペ イ 3.3 データコンテント管理テーブル ロードに格納する（１図（a） ） 。一方，１つのMFUのサイ さらに，パッケージ データコンテント管理テーブルは，データコンテンツ内 ズが大きく１つのMMTPペイロードに格納できない場合 で，例えば提示を行う単位（ページなど）をプレゼンテー には，MFUを分割（フラグメント）して複数のMMTP ションユニット（PU：Presentation Unit）と定義して， ペイロードとして伝送する（１図（c） ） 。 あるPUにはどのファイルが関係し，どのPUとリンク関係 になっているかの情報を提供するテーブルである。 このテーブルにより，アプリケーションが要求するファ MMTPペイロードは，８バイトのペイロードヘッダー とデータユニットから成る。１MPU＝１MFUの場合（１ 図（b） ）は，MMTPペイロードには，８バイトのペイ イルと同じPUに含まれる他のファイルを知り，ページ全 体の取得時間の短縮を行い，また，リンク関係にあるPU ＊４ 映像・音声等のデータを処理するときの単位。 ＊５ 符号化されたメディアテータを識別するために，MPUを論理的な グループに分けた単位。MMT規格内で定義される。 の情報を得ることで，次ページの優先的なキャッシュを行 うことが可能となる。 ＊６ 同じデータを繰り返し送信する伝送方式。 3.4 データ伝送メッセージ ＊７ 複数のテーブル間で相互に参照するための，ファイルを識別する値。 ＊８ 番組などのコンテンツの論理的な単位であり，複数のアセットで構 成される。MMT規格内で定義される。 ルを格納するメッセージである。ここで，メッセージと ＊９ 伝送の手順を定めた規約。 は，各テーブルを格納し伝送するためのフォーマットであ ＊10 映像や音声など時刻情報を持つメディアデータと時刻同期しない伝 送のタイプ。 データ伝送メッセージは，データ伝送に関する各テーブ る。１つのデータ伝送メッセージには，上記の管理テー ＊11 MPUの属性を記述したデータ。 ブルが１つずつ格納され，このメッセージを取得するこ ＊12 MPUより小さいデータの処理単位。 NHK技研 R&D/No.150/2015.3 37 報告 ファイル 本体 ファイル 本体 MPU ファイル本体 ファイル本体 MPU MPU メタデータ … ユニット データ MMTPペイロード MPU メタデータ データユニット MMTPペイロード data_unit_length（16ビット） item_id（32ビット） data_unit_length（16） item_id（32） MPU メタデータ MFU データユニット MMTPペイロード item_id（32） item_id（32） （b）1MPU = 1MFUの場合 MFU ペイロード ヘッダー データ ユニット MFU ペイロード ヘッダー … ペイロード ヘッダー ペイロード ヘッダー MFU MPU データユニット MMTPペイロード item_id（32） （c）MFUを分割する場合 データユニットの ヘッダーの構成 （a）MFUを結合する場合 １図 非同期型MPUによるカプセル化 ロードヘッダーに加え，４バイトのヘッダー（item_ ＊13 ）とMFUで構成されるデータユニットが１つ格納さ id れるので，オーバーヘッドは合計で12バイトとなる。 示す制御情報としては，GFDテーブルを用いる。GFD テーブルは，最大伝送長や伝送モードなどの情報を提供す る。伝送モードは，ファイルをそのまま伝送するか，エン １つのMFUのサイズが大きい場合（１図（c） ）は， ティティヘッダー＊16を付加して伝送するかを示す。GFD MFUはN個のデータユニットに分割され，各データユ テーブルの伝送にはGFDT記述子＊17を用いる。この記述 ニットは４バイトのヘッダーとMFUで構成されるので， 子は，MPテーブルにアセット単位で記載される。 オーバーヘッドは合計で12×Nバイトとなる。 4.3 B45データ伝送方式（ARIB STDB45で M個のMFUを結合して１つのMPUとする場合（１図 規定される伝送方式） （a） ）は，MMTPペイロードには，８バイトのペイロード B45データ伝送においては，３図に示すように，ファイ ヘッダーに加え，６バイトのヘッダー（item_idとdata_ ルはデータユニット（DU：Data Unit）と呼ばれる単位に ＊14 ）とMFUで構成されるデータユニットが 分割されて伝送される。DUのヘッダーの長さは８バイト M個格納されるので，オーバーヘッドは合計で８＋６×M なので，オーバーヘッドは，１つのファイルが１個のDU バイトとなる。 となる場合には８バイト，１つのファイルがN個のDU 4.2 GFDモード に分割された場合には８×Nバイトとなる。 unit_length GFDモードは，MMTの規格内で，一般的なファイルの また，B45データ伝送においては，１つのファイルパッ ダウンロード用のモードとして規定されており，MPEG ケージ（メディアファイルやメタデータファイルなどの集 ６） DASH（Dynamic Adaptive Streaming over HTTP） 合）に 対 し て，XML（Extensible Markup Language） のセグメントを伝送する場合などに利用される。 形式で記述された伝送ファイル属性情報を伝送する。この GFDモードにおけるカプセル化の構造を２図に示す。 基本構成においては，１つのファイルを１つのオブジェ クト 報は含まれていない。 ＊15 とし，MMTPペイロードに格納して伝送する。 GFDモードのMMTPペイロードは，12バイトのペイ ＊13 アイテム（１つのファイル）を識別する値。 ロードヘッダーを持つ。１つのオブジェクトのサイズが ＊14 データユニットの長さ。 大きくN個に分割される場合には，オーバーヘッドは合計 ＊15 伝送する際の１つのまとまり。 で12×Nバイトとなる。 GFDモードにおいて，個々のファイルに関する情報を 38 伝送ファイル属性情報には，ファイルごとのバージョン情 NHK技研 R&D/No.150/2015.3 ＊16 伝送するファイルが，どのような内容かを示す情報。ファイルのバー ジョン情報などは含まれていない。 ＊17 GFDテーブルとして必要な情報を記載した記述子。 ファイル 本体 ファイル本体 オブジェクト オブジェクト MMTPペイロード （a）基本構成 ペイロード … MMTPペイロード ペイロード ヘッダー ペイロード ペイロード ヘッダー MMTPペイロード ペイロード ヘッダー ペイロード ヘッダー ペイロード ペイロード MMTPペイロード （b）オブジェクトを分割する場合 ２図 GFDによるカプセル化 データユニット ファイルパッケージ ユニット#N ・メディアファイル 分割 ・メタデータファイル ユニット#N−1 …… ルを全て受信する必要があり，ファイルごとの更新管理を 可能とするという要件を満たさない。 一方，MPUモードは，ファイルの結合の機能を持ち， オーバーヘッドを少なくする伝送が可能で，制御情報のサ イズをコンパクトに保ちつつ，ファイルごとのバージョン ユニット#1 情報も備えているので，アプリケーション伝送の要件に 合ったプロトコルと言える。 伝送ファイル属性情報 ３図 B45データ伝送によるカプセル化 ５．シミュレーションによる性能評価 アプリケーションを構成する実際のファイルを用いて， 提案した伝送方式のシミュレーションを行い，MMTによ 以上の３つの伝送プロトコルを，オーバーヘッドや制 る繰り返し伝送，制作時と伝送時のディレクトリー構成の 御情報などの項目で比較し，アプリケーション伝送の機能 分離，MMTPペイロードサイズの影響の各観点で，それ の面から有効性を評価した。評価結果を１表に示す。 ぞれ性能評価を行った。 放送伝送路におけるアプリケーション伝送の機能として 伝送するアプリケーションとして，現在既にサービスを は，アプリケーションを構成する多種のファイルを伝送 開始しているハイブリッドキャストのトップページを想定 し，その構成やファイルごとの更新情報を管理できる必要 した。このトップページは，主にHTMLファイル，CSS がある。この機能に関して評価すると，ファイルごとの ＊18 ファイル， JavaScript＊19ファ （Cascading Style Sheets） バージョン情報を持たないGFDモードやB45データ伝送 イルなどのコード（符号）関連ファイル，スポーツの結果 は，アプリケーション伝送には適さない。 や株価などリアルタイムに変化するデータ関連ファイル， オーバーヘッドに関しては，１つのファイルのペイロー アプリケーションを構成する映像ファイルおよび音声ファ ドヘッダーの長さを比較するとB45データ伝送方式が有利 イルから構成されている。 であるが，B45データ伝送方式は伝送するファイルごとに 5.1 MMTによる繰り返し伝送 XML形式の伝送ファイル属性情報が必要となり，１つの アプリケーションを構成するファイルのサイズと，それ ファイルをファイルパッケージとして複数のファイルを伝 を伝送するために割り当てられた伝送レートから計算され 送する場合には冗長となる。複数のファイルをまとめて る最小の繰り返し周期と，シミュレーションにより求めた ファイルパッケージとすることでオーバーヘッドは低減さ れるものの，この場合は，ある１つのファイルを更新す る場合でも，ファイルパッケージに含まれる複数のファイ ＊18 HTML文書で詳細な画面表示指定が可能な仕様。 ＊19 HTML文書で動的なコンテンツ表示を記述することが可能なプログ ラム言語。 NHK技研 R&D/No.150/2015.3 39 報告 １表 伝送プロトコルの比較と評価 伝送プロトコル オーバーヘッド 制御 情報 MPUモード（非同期型） GFDモード B45データ伝送 1ファイル △ 12バイト（1MPU＝1MFU） △ 12バイト（1オブジェクト） ○ 8バイト（1DU） 分割 （フラグメント） △ 12×Nバイト（1MPU＝1MFU） △ 12×Nバイト（1オブジェクト） ○ 8×Nバイト（N×DU） 結合 （アグリゲート） ○ 8+6×Mバイト（1MPU＝M×MFU） × 対応しない × 対応しない サイズ ○ （テーブル形式） ○ （テーブル形式） × （伝送ファイル属性情報） （XML形式） 多種のファイル 伝送の影響 ○ MPテーブルにアセット情報記載 （データアセット管理テーブル） × MPテーブルにGFDT記述子 ファイルの バージョン情報 ○ 持つ × 持たない × 持たない アプリケーションの ための情報 △ データディレクトリー管理テーブル データコンテント管理テーブル △ 左記相当のテーブルが必要 △ 左記相当のテーブルが必要 多種のファイルを繰り返し 伝送する場合に適する 同種のファイルを連続的に 伝送するような場合に適する ファイルサイズが大きな 1メディアファイルの ダウンロードなどに適する 評価 ２表 各ファイルの平均取得時間 コンテンツ コード データ 映像 音声 合計サイズ（kByte） 193 101 1,098 438 伝送レート（Mbps） 5 平均取得時間（sec） 3.1 伝送レート（Mbps） 2 3 平均取得時間（sec） 1.3 4.5 伝送レート（Mbps） 1 4 平均取得時間（sec） 2.5 3.4 ３表 MMTPペイロードの最大サイズと 平均取得時間との関係 最大サイズ（kByte） 1.4 3.9 5.9 7.9 コード・データを 1Mbpsで伝送（sec） 2.5 2.4 2.4 2.4 コンテンツ全てを 5Mbpsで伝送（sec） 3.1 3.0 3.0 3.0 れぞれのアセットに割り当てる伝送レートを調整すること により，まとめて１アセットで伝送した場合に比べてよ ファイルの取得時間とを比較することにより，繰り返し伝 り柔軟に取得時間を変更することができる。例えば，コー 送の性能評価を行った。各コンテンツのサイズ，割り当て ドやデータに２Mbps，映像や音声に３Mbpsを割り当て られた伝送レート，シミュレーションにより求めた平均取 ることで，変更の可能性の少ない映像や音声と比べて，更 得時間を２表に示す。 新される可能性の高いコードやデータの取得時間を短くで 全てのコンテンツ（合計サイズは1,830kByte）を５ Mbpsの１アセットで伝送した場合，繰り返し周期の計算 40 きることを確認した。 5.2 制作時と伝送時のディレクトリー構成の分離 値は2.93秒となるが，シミュレーションによる平均取得時 一般のアプリケーション制作者が伝送時のディレクト 間は3.1秒となった。実際の伝送のシミュレーションにお リー構成を意識することなくコンテンツ制作を行えるよう いては，コンテンツの合計サイズにオーバーヘッドが加わ に，アプリケーション制作時のディレクトリー構成と伝送 る分だけ計算値よりも取得時間が余分にかかるものの，ど 時のディレクトリー構成とを分離する目的で，データア のタイミングで取得を開始しても，ほぼ平均取得時間に近 セット管理テーブルとデータディレクトリー管理テーブル い値で取得できており，現行のデータ放送と同等の性能を の２つが規格化されている。これにより，アプリケーショ 確認した。 ン制作者は，伝送時のディレクトリー構成を意識すること また，２表に示すように，更新される可能性の高いコー なく，制作しやすいディレクトリー構成を取ることがで ドやデータと，変更の可能性の少ない映像や音声のよう き，かつ，アプリケーション伝送時には，アプリケーショ に，コンテンツの種類に応じてアセットを複数に分け，そ ンのディレクトリー構成を変更することなく，ファイルを NHK技研 R&D/No.150/2015.3 10kByteのファイル を伝送する例 10kByte ８分割（1.4kByte） ３分割（3.9kByte） ５パケット分のオーバーヘッド削減 ２分割（5.9kByte） ２分割（7.9kByte） 平均取得時間の有意な差にはならず （ ）内はMMTPペイロードサイズ。 ４図 MMTPペイロードサイズの影響 伝送するアセットの構成や送出周期を変更することが可能 ンツに10kByte前後のファイルが多いため，平均取得時間 となる。 に有意な差は表れなかった。今回のシミュレーションで そこで，データディレクトリー管理テーブルはそのまま は，各ファイルのサイズとMMTPペイロードのサイズに として，データアセット管理テーブルのみを変化させて， 応じた適応的なアグリゲートは行っておらず，それを行う 実際の伝送への影響をシミュレーションで確かめた。その ことで，さらなるオーバーヘッドの削減効果が期待でき 結果，アプリケーションのディレクトリー構成を変えるこ る。 となく，伝送時のアセットの構成を簡単に変更することが 可能で，受信機で展開されるファイルのディレクトリー構 成にも影響が無いことを確認した。 5.3 MMTPペイロードサイズの影響 MMTPペイロードの最大サイズに応じて，小さいサイ ズのファイルは結合することが可能であり，大きいサイズ ６．おわりに ８K衛星放送の多重方式として規格化されたMMTによ るアプリケーション伝送方式について，本方式と他の伝送 プロトコルとの比較を行い，有効性を評価し，シミュレー ションによる性能評価を行った。 のファイルは分割することが可能である。MMTPペイ 今後は，アプリケーションの制作システムと配信システ ロード（および想定するIPパケット）の最大サイズを1.4 ムとの連携のために必要となる，番組単位で一元的に管理 kByte（1.5 kByte）， 3.9 kByte （ 4.0 kByte ）， 5.9 kByte 可能なパッケージフォーマットの検討や，アプリケーショ （6.0kByte） ，7.9kByte（8.0kByte）として，コードやデー ンを構成するファイルのリアルタイムの更新検知などの性 タを１Mbpsで伝送する場合と，全てのコンテンツを５ 能評価を行う予定である。 Mbpsで伝送する場合について，平均取得時間をシミュ レーションで求めた結果を３表に示す。 MMTPペ イ ロ ー ド の 最 大 サ イ ズ が1.4kByteか ら3.9 本稿は，映像情報メディア学会技術報告に掲載された以下の 論文を元に加筆・修正したものである。 kByteに増えることで，伝送されるMMTPパケット数が 大槻，河村，青木，竹内，中村，木村： “MMTによるアプリ 減り，オーバーヘッドが少なくなることによって，平均取 ケーション伝送方式の性能評価， ”映像情報メディア学会技術 得時間が少なくなることが確認できた。一方で，４図に 報告，Vol.38，No.35，BCT201478，pp.2528（2014） 示すように，それ以上のサイズでは，今回想定したコンテ NHK技研 R&D/No.150/2015.3 41 報告 参考文献 1）ISO/IEC 230081：2014， “Information Technology High Efficiency Coding and Media Delivery in Heterogeneous Environments Part1：MPEG Media Transport（MMT） ” 2）S.Aoki，K.Otsuki and H.Hamada， “New Media Transport Technologies in Super HiVision Broadcasting Systems， ”International Broadcasting Convention（2013） 3）総務省： “放送サービスの高度化に関する検討会， ” http://www.soumu.go.jp/main_sosiki/kenkyu/bcservice/index.html 4）大槻，青木，竹内，砂崎： “スーパーハイビジョン衛星放送システムにおけるMMTを用いたデータ伝送方式の 検討， ”映像情報メディア学会技術報告，Vol.38，No.14，BCT201454，pp.2932（2014） 5）電波産業会： “デジタル放送におけるダウンロード方式， ”ARIB STDB45 2.2版（2012） 6）ISO/IEC 230091：2012，“Dynamic Adaptive Streaming over HTTP（DASH）Part 1：Media Presentation Description and Segment Formats” 7）IETF RFC 2616， “Hypertext Transfer Protocol HTTP/1.1” （1999） おおつきかずひろ かわむら ゆ う き 大槻一博 河村侑輝 1997年入局。同年から放送技術研究所におい て，多重方式，データ符号化方式，セキュリ ティー技術などデジタル放送システムの研究 開発に従事。現在，放送技術研究所伝送シス テム研究部に所属。 2010年入局。名古屋放送局を 経 て，2013 年から放送技術研究所において，デジタル放 送システムにおける多重化技術の研究・開発 に従事。現在，放送技術研究所伝送システム 研究部に所属。 あ お き しゅういち なかむらなおよし 青木 秀一 中村直義 2003年入局。同年から放送技術研究所におい て，IP技術を用いる放送システムの研究に従 事。現在，放送技術研究所伝送システム研究 部に所属。博士（情報理工学） 。 1987年入局。鳥取放送局を経て，1991年か ら放送技術研究所において，光ケーブルテレ ビ，デジタル伝送方式の研究開発に従事。現 在，放送技術研究所伝送システム研究部上級 研究員。博士（工学） 。 きむらたけし 木村武史 1980年入局。大阪放送局を経て，1983年か ら放送技術研究所において，衛星有料放送， 衛星デジタル放送，地上デジタル放送，高度 広帯域衛星デジタル放送などの研究に従事。 1997年から2000年まで（株）次世代情報放 送システム研究所に出向。現在，放送技術研 究所伝送システム研究部上級研究員。 42 NHK技研 R&D/No.150/2015.3
© Copyright 2024 ExpyDoc
