JP7334442B2 - 放送信号処理システム及び放送信号処理方法 - Google Patents

Description

本開示は、放送信号処理システム及び放送信号処理方法に関する。

既存の放送局の多くは、映像、音声及び補助（ancillary）データといった放送素材を局内で伝送するための専用ネットワークを有している。専用ネットワークには、例えば、カメラ及びマイクロフォンといったキャプチャデバイス、コンテンツデータを蓄積するストレージサーバ、コンテンツを再生する再生デバイス、及び伝送される信号の形式を変換するゲートウェイデバイスといった、様々な装置が接続される。専用ネットワーク上での放送素材の伝送のための信号形式として、ＳＤＩ（Serial Digital Interface）がこれまで広く利用されている。

しかし、近年のＩＰ（Internet Protocol）技術の目覚ましい性能の向上の結果、放送事業者は、より汎用性の高いＩＰ技術を活用することにメリットを見出し、局内のネットワークをＩＰネットワークへ更新する取り組みを開始した。ＩＰベースのネットワークアーキテクチャを採用すれば、例えば、汎用のルータ及びスイッチといったネットワーク装置を用いて高速かつ大容量のネットワークを低コストで構築することが可能となる。

放送素材をＩＰ技術を活用して伝送するためのプロトコルの標準化も、現在進められている。例えば、ＳＭＰＴＥ（Society of Motion Picture and Television Engineers）は、映像、音声及び補助データの混成であるＳＤＩイメージをＩＰパケットで伝送するためのプロトコルであるＳＭＰＴＥ ＳＴ２０２２－６を規格化済みである（非特許文献１参照）。さらに、ＳＭＰＴＥは、映像、音声及び補助データを別々のストリームで伝送するためのプロトコル群であるＳＭＰＴＥ ＳＴ２１１０シリーズの規格化も進めている（非特許文献２参照）。中でも、ＳＭＰＴＥ ＳＴ２１１０－１０によれば、放送局システムに参加するノードがＰＴＰ（Precision Time Protocol）の仕組みに基づいて相互に高い精度で同期する。この高精度の同期によって、ＩＰネットワーク上で異なる経路に沿って伝送される異なるストリームを受信側で適切に時間合わせすることが可能となる。

日本国内の標準化団体であるＡＲＩＢ（Association of Radio Industries and Businesses）は、映像、音声及び補助データを単一のストリームで伝送するためのデータ構造の規定として、ＡＲＩＢ ＳＴＤ－Ｂ７３を規格化済みである（非特許文献３参照）。

さらに、多様な装置の間の相互運用性を確保するために、ＡＭＷＡ（Advanced Media Workflow Association）は、装置間のストリームの伝送を管理し及び制御するための制御インタフェース規格の集合であるＮＭＯＳ（Networked Media Open Specifications）規格の策定を進めている。例えば、ＮＭＯＳ ＩＳ－０４は、ネットワークリソースの発見及び登録（Discovery and Registration）のための制御インタフェース規格である（非特許文献４参照）。ＮＭＯＳ ＩＳ－０５は、デバイスの接続管理（Device Connection Management）のための制御インタフェース規格である（非特許文献５参照）。ＮＭＯＳ規格が利用される場合、送信ノードは、自ノードにより送信可能な放送信号ストリームの属性を記述するＳＤＰ（Session Description Protocol）オブジェクトを制御ノードへ提供し、制御ノードは、そのＳＤＰオブジェクトの記述に基づいてストリームの伝送をセットアップする。

特許文献１及び２は、放送コンテンツのストリーミングの際に利用され得るＳＤＰオブジェクトの例を開示している。

Thomas Edwards， "SMPTE ST 2022: Moving Serial Interfaces (ASI & SDI) to IP"， ［online］， 2017年8月17日， SMPTE Standards Webcast Series， ［平成31年2月15日検索］， インターネット＜URL：https://www.smpte.org/sites/default/files/2017-08-17-ST-2022-Edwards-V4-Handout.pdf＞ SMPTE， "SMPTE ST 2110 FAQ"， ［online］， ［平成31年2月15日検索］， インターネット＜URL：https://www.smpte.org/st-2110＞ ARIB， "制作用ＩＰインタフェースにおけるエッセンス独立単一ストリームのＲＴＰデータグラムのデータ構造 標準規格（ARIB STD-B73 1.0版）"， ［online］， 2018年7月26日， ［平成31年2月15日］， インターネット＜URL：https://www.arib.or.jp/kikaku/kikaku_hoso/desc/std-b73.html＞ AMWA， "AMWA IS-04 NMOS Discovery and Registration Specification (Stable)"， ［online］， ［平成31年2月15日］， インターネット＜URL：https://amwa-tv.github.io/nmos-discovery-registration/＞ AMWA， "AMWA IS-05 NMOS Device Connection Management Specification"， ［online］， ［平成31年2月15日］， インターネット＜URL：https://amwa-tv.github.io/nmos-device-connection-management/＞

特開２０１５－７３１９７号公報 特表２００７－５３１３６８号公報

相互に関連する映像、音声及び補助データをＳＭＰＴＥ ＳＴ２１１０のように別々のストリームで伝送すると、トランスポートレイヤでそれらストリームのポート番号が相違することから、受信側でもとのコンテンツを再構築する処理が複雑化する。ポート番号が相違すれば、ＩＰネットワーク上での経路制御の結果として、個々のストリームが辿る伝送経路の違いからストリームごとに異なる遅延を受ける可能性もある。これに対し、ＡＲＩＢ ＳＴＤ－Ｂ７３の映像、音声及び補助データのストリームは、トランスポートレイヤで同一のポート番号を有するために、上述したＳＭＰＴＥ ＳＴ２１１０に固有の問題点を有しない。しかし、ＡＲＩＢ ＳＴＤ－Ｂ７３は、放送局システムに参加するノード間でどのように協調的に動作してストリームを処理すべきかを規定していない。

例えば、ストリームの伝送に関与するノード間で高精度の同期が確立されておらず、パケット間の時間合わせのために使用すべき時刻情報用のフィールドに合意が無ければ、放送局システム内でやり取りされる多様なエッセンスを柔軟に組み合わせて放送コンテンツを構成することができない。

また、ＳＭＰＴＥ ＳＴ２１１０ストリームのために通常利用されるＳＤＰオブジェクトのフォーマットは、フォーマット構造においても、記述される情報の内容においても、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームの特性に必ずしも適していない。

本開示に係る技術は、上述した課題のうちの少なくとも１つを解決することを目的とする。

ある観点によれば、ＰＴＰの時刻源に直接的に又は間接的に同期したデバイス内部クロックにロックされたメディアクロックに対しオフセットを有しないＲＴＰクロックに従ってＲＴＰヘッダへタイムスタンプを付与されたＲＴＰパケットであって、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む当該ＲＴＰパケットを受信する通信部と、受信される上記ＲＴＰパケットの上記ＲＴＰヘッダから取得される上記タイムスタンプ、又は、受信される上記ＲＴＰパケットの上記ＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に基づいて、上記ＲＴＰパケットと他のＲＴＰパケットとの間でエッセンスデータの時間合わせを行うアラインメント部と、を備える放送信号処理システムが提供される。

また別の観点によれば、ＰＴＰの時刻源に直接的に又は間接的に同期したデバイス内部クロックにロックされたメディアクロックに対しオフセットを有しないＲＴＰクロックに従ってＲＴＰヘッダへタイムスタンプを付与されたＲＴＰパケットであって、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む当該ＲＴＰパケットを受信することと、受信される上記ＲＴＰパケットの上記ＲＴＰヘッダから取得される上記タイムスタンプ、又は、受信される上記ＲＴＰパケットの上記ＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に基づいて、上記ＲＴＰパケットと他のＲＴＰパケットとの間でエッセンスデータの時間合わせを行うことと、を含む放送信号処理方法が提供される。

また別の観点によれば、上記放送信号処理方法をプロセッサに実行させるコンピュータプログラムが提供されてもよい。上記コンピュータプログラムを記憶した非一時的なコンピュータ読取可能な記憶媒体が提供されてもよい。

本開示に係る技術によれば、放送局のＩＰネットワーク上で映像データ、音声データ又は補助データといったエッセンスデータを単一のストリームで伝送するプロトコルを利用する際に、エッセンスデータの適切な時間合わせを行うことが可能となる。なお、本開示に係る技術により、当該効果の代わりに、又は当該効果とともに、他の効果が奏されてもよい。

本開示の実施形態に係る放送局システムの構成の一例を示す概略図である。 本開示の実施形態に係る放送局システムのＩＰドメインの論理的な構成の一例について説明するための説明図である。 ＳＭＰＴＥ ＳＴ２１１０－１０により規定されたシステムタイミングモデルについて説明するための説明図である。 図３を用いて説明したシステムタイミングモデルに基づく映像エッセンスと音声エッセンスとの間の時間合わせについて説明するための説明図である。 ＡＲＩＢ ＳＴＤ－Ｂ７３におけるデータグラムの構成について説明するための説明図である。 ＡＲＩＢ ＳＴＤ－Ｂ７３に従った単一ストリームでの映像エッセンス及び音声エッセンスの伝送について説明するための説明図である。 第１の実施形態に係る放送信号処理ノードの構成の一例を示すブロック図である。 図７に示した受信ストリーム処理部の詳細な構成の一例を示すブロック図である。 ２つのＲＴＰパケットの間のエッセンスデータの時間合わせのための手法の第１の例について説明するための説明図である。 ２つのＲＴＰパケットの間のエッセンスデータの時間合わせのための手法の第２の例について説明するための説明図である。 ２つのＲＴＰパケットの間のエッセンスデータの時間合わせのための手法の第３の例について説明するための説明図である。 ２つのＲＴＰパケットの間のエッセンスデータの時間合わせのための手法の第４の例について説明するための説明図である。 第１の実施形態に係るストリーム送信処理の流れの一例を示すフローチャートである。 第１の実施形態に係るストリーム受信処理の流れの一例を示すフローチャートである。 第２の実施形態に係る放送信号処理ノードの構成の一例を示すブロック図である。 第２の実施形態の第１の変形例に係る放送信号処理ノードの構成の一例を示すブロック図である。 第２の実施形態の第２の変形例に係る放送信号処理ノードの構成の一例を示すブロック図である。 エッセンス分離型ストリーム用のＳＤＰオブジェクトの典型的なフォーマット構造について説明するための説明図である。 図１５を用いて説明したフォーマット構造を有する、ＳＭＰＴＥ ＳＴ２１１０ストリームの属性を記述したＳＤＰオブジェクトの一例を示す説明図である。 第３の実施形態においてエッセンス混在型ストリームのために定義されるＳＤＰオブジェクトのフォーマット構造について説明するための説明図である。 図１７を用いて説明したフォーマット構造を有する、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームの属性を記述したＳＤＰオブジェクトの一例を示す説明図である。 第３の実施形態に係る放送局システムの概略的な構成の一例を示すブロック図である。 第３の実施形態に係る送信ノードの構成の一例を示すブロック図である。 図２０に示した送信ノードにより実行され得る送信制御処理の流れの第１の例を示すフローチャートである。 図２０に示した送信ノードにより実行され得る送信制御処理の流れの第２の例を示すフローチャートである。 第３の実施形態に係る制御ノードの構成の一例を示すブロック図である。 図２３に示した制御ノードにより実行され得る送信制御処理の流れの第１の例を示すフローチャートである。 図２３に示した制御ノードにより実行され得る送信制御処理の流れの第２の例を示すフローチャートである。 第４の実施形態に係る送信ノードの構成の一例を示すブロック図である。 第４の実施形態に係る制御ノードの構成の一例を示すブロック図である。

以下、添付の図面を参照して本開示に係る技術の実施形態を詳細に説明する。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。

説明は、以下の順序で行われる。
１．概要
２．第１の実施形態
２－１．放送信号処理ノードの構成例
２－２．受信ストリーム処理部の詳細な構成例
２－３．処理の流れ
３．第２の実施形態
３－１．放送信号処理ノードの構成例
３－２．変形例
４．第１の実施形態及び第２の実施形態のまとめ
５．第３の実施形態
５－１．既存のＳＤＰオブジェクトの例
５－２．ＳＤＰオブジェクトの新たなフォーマット
５－３．放送局システムの構成例
５－４．送信ノードの構成例
５－５．制御ノードの構成例
６．第４の実施形態
６－１．送信ノードの構成例
６－２．制御ノードの構成例
７．第３の実施形態及び第４の実施形態のまとめ

＜＜１．概要＞＞
まず、図１を用いて、本開示のいくつかの実施形態が適用され得る放送局システムの概要について説明する。図１は、本開示の実施形態に係る放送局システム１の構成の一例を示す概略図である。図１を参照すると、放送局システム１は、１つ以上のネットワーク装置１２、カメラ２０ａ、モニタ２０ｂ、ＩＰゲートウェイ２０ｃ、ＩＰゲートウェイ２０ｄ、カメラ２２、マイクロフォン２４、データサーバ２６、統合プレイアウト（Integrated Playout）３２、モニタ３４、ＡＰＳ（Automatic Program control System）４０及び制御端末５０を含む。ネットワーク装置１２、カメラ２０ａ、モニタ２０ｂ、ＩＰゲートウェイ２０ｃ、ＩＰゲートウェイ２０ｄ、ＡＰＳ４０、及び制御端末５０は、ＩＰドメイン１０に属する。

（１）様々な装置の説明
ネットワーク装置１２は、ＩＰネットワークにおけるストリームの転送を担当する装置である。ネットワーク装置１２の各々は、例えばルータ、スイッチ、ブリッジ又はリピータなど、いかなる種類のネットワーク装置であってもよい。ネットワーク装置１２の各々は、低コストで導入可能な汎用品（ＣＯＴＳ（Commercial Off-The-Shelf）ともいう）であってもよい。図１には６つのネットワーク装置１２が示されているが、かかる例に限定されず、放送局システム１はいくつのネットワーク装置１２を含んでもよい。ＩＰドメイン１０は、単一のネットワークで構成されてもよく、又は複数のサブネットワークを含んでもよい。

カメラ２０ａは、放送素材を生成するキャプチャデバイスの一種である。例えば、カメラ２０ａは、何らかの対象を撮影して、映像データを生成する。カメラ２０ａは、内蔵されるマイクロフォンを通じて音声を取得して、音声データを生成してもよい。カメラ２０ａは、ＩＰドメイン１０に属し、映像データ及び音声データのデータストリームを一連のＩＰパケットへパケット化してＩＰネットワークへ送信することができる。

モニタ２０ｂは、放送素材を受信してコンテンツを再生する再生デバイスの一種である。例えば、モニタ２０ｂは、映像データを受信して映像を再生する。モニタ２０ｂは、音声データを受信して音声を再生してもよい。モニタ２０ｂは、追加的に伝送される補助データを受信して、補助データを処理（例えば、字幕を再生）してもよい。モニタ２０ｂは、コンテンツを編集するための編集機能をユーザへ提供してもよい。モニタ２０ｂは、ＩＰドメイン１０へ属し、ＩＰネットワーク上で転送されて来る一連のＩＰパケットを受信することができる。

ＩＰゲートウェイ２０ｃは、ＩＰドメイン１０と他の信号ドメインとの境界に位置するゲートウェイデバイスである。ＩＰゲートウェイ２０ｃは、１つ又は複数のネットワーク装置１２へ接続する。図１の例において、ＩＰゲートウェイ２０ｃには、カメラ２２、マイクロフォン２４及びデータサーバ２６がさらに接続されている。例えば、ＩＰゲートウェイ２０ｃは、映像データを搬送するＳＤＩ信号をカメラ２２から受信し得る。また、ＩＰゲートウェイ２０ｃは、音声データを搬送するＳＤＩ信号をマイクロフォン２４から受信し得る。また、ＩＰゲートウェイ２０ｃは、映像データ、音声データ及び補助データのうちの１つ以上を搬送するＳＤＩ信号をデータサーバ２６から受信し得る。なお、ＩＰドメイン１０の外部で伝送される信号の信号形式は、例えばＳＤ－ＳＤＩ、ＨＤ－ＳＤＩ、３Ｇ－ＳＤＩ、６Ｇ－ＳＤＩ若しくは１２Ｇ－ＳＤＩといったＳＤＩの任意の派生であってもよく、又は、ＳＤＩ以外の信号形式であってもよい。ＩＰゲートウェイ２０ｃは、上述したようにカメラ２２、マイクロフォン２４及びデータサーバ２６から受信される放送素材を搬送する信号を、必要に応じて多重化し又は逆多重化した後、一連のＩＰパケットへパケット化してＩＰネットワークへ送信することができる。

ＩＰゲートウェイ２０ｄもまた、ＩＰドメイン１０と他の信号ドメインとの境界に位置するゲートウェイデバイスである。ＩＰゲートウェイ２０ｄは、１つ又は複数のネットワーク装置１２へ接続する。図１の例では、ＩＰゲートウェイ２０ｄには、統合プレイアウト３２及びモニタ３４がさらに接続されている。例えば、ＩＰゲートウェイ２０ｄは、ＩＰネットワーク上で転送されて来るＩＰパケットを受信し、それらＩＰパケットをＳＤＩ信号（又は他の信号形式の信号）へ変換して、統合プレイアウト３２及びモニタ３４の一方又は双方へ送信することができる。なお、当然ながら、ＩＰゲートウェイ２０ｃがＩＰゲートウェイ２０ｄと同様にＩＰパケットをＳＤＩ信号へ変換する機能を有していてもよい。また、ＩＰゲートウェイ２０ｄがＩＰゲートウェイ２０ｃと同様にＳＤＩ信号をＩＰパケットへ変換する機能を有していてもよい。

ＡＰＳ４０は、予め決定されるスケジュールに従って、テレビジョン番組の放送を進行させるシステムである。例えば、ＡＰＳ４０は、ＩＰネットワークへ制御メッセージを送信して、所定の時刻に所与の送信元（例えば、カメラ及びマイクロフォン、又はデータサーバ）から出力されるデータストリームを統合プレイアウト３２へ伝送させる。データストリームを受信した統合プレイアウト３２は、放送局の回線を通じてアンテナへテレビジョン番組の放送信号を送出する。データストリームは、例えばモニタ２０ｂ又はモニタ３４にも配信され、放送局内でも放送コンテンツが再生され得る。

制御端末５０は、放送局システム１に含まれるノードの管理及び制御に関連するユーザインタフェースをユーザへ提供する端末装置である。制御端末５０は、放送局システム１に専用のユーザ端末であってもよく、又はＰＣ（Personal Computer）若しくはスマートフォンといった汎用的な端末であってもよい。制御端末５０は、例えば、放送局内のネットワーク上でのストリームの伝送に関連する設定情報を、ユーザインタフェースを介して取得してシステム内のデータベースへ登録する。また、制御端末５０は、例えば、ユーザインタフェースを介して所与のノード間のストリームの伝送を求めるリクエストを受け付ける。

（２）ＩＰマルチキャスト
放送局システム１のＩＰドメイン１０内の放送信号ストリームの伝送は、典型的には、マルチキャストで行われる。マルチキャストされるパケットの送信元ＩＰアドレスは送信ノードのＩＰアドレスであり、宛て先ＩＰアドレスは特定のアドレス範囲に属するマルチキャストアドレスである。個々のマルチキャストアドレスを宛て先とするマルチキャストパケットを受信するノードの集合をマルチキャストグループといい、マルチキャストアドレスをグループアドレスともいう。あるストリームを受信することを意図する受信ノードは、そのストリームに対応するマルチキャストグループへの加入（join）を通知するメッセージ（例えば、ＩＧＭＰ（Internet Group Management Protocol） ＪＯＩＮ）を近傍のルータへ送信する。すると、ルータ間でマルチキャストツリーを更新するためのメッセージ交換が行われ、特定の送信ノードから送信されるストリームがＩＰネットワークを介して受信ノードへ配信されるようになる。受信ノードは、マルチキャストストリームの受信を終了する際には、マルチキャストグループからの離脱（leave）を通知するメッセージを近傍のルータへ送信する。なお、上述した例に限定されず、本開示に係る技術は、ストリームがユニキャストで伝送されるケースにも適用可能である。

（３）ＩＰドメインの論理的構成例
図２は、図１に示した放送局システム１のＩＰドメイン１０の論理的な構成の一例を示している（簡明さのために、ここではＡＰＳ４０及び制御端末５０は省略されている）。図２を参照すると、カメラ２０ａに相当する第１ノードは、センダ（sender）６０ａを含む。「センダ」とは、ストリームを送信する能力を有する機能エンティティである。ＩＰゲートウェイ２０ｃに相当する第２ノードは、センダ６０ｂ、６０ｃ及び６０ｄを含む。センダ６０ｂ、６０ｃ及び６０ｄは、ＩＰゲートウェイ２０ｃにより収容される個々のストリームの送信元の装置に相当し得る。モニタ２０ｂに相当する第３ノードは、レシーバ６５ａを含む。「レシーバ」とは、ストリームを受信する能力を有する機能エンティティである。ＩＰゲートウェイ２０ｄに相当する第４ノードは、レシーバ６５ｂ及び６５ｃを含む。レシーバ６５ｂ及び６５ｃは、ＩＰゲートウェイ２０ｄにより収容される個々のストリームの受信先の装置に相当し得る。

上の説明から理解されるように、１つのノード（「カード」と呼ばれてもよい）は、１つの物理エンティティを表現する。図１の例に限定されず、１つのノードは、機能エンティティとして、任意の数のセンダ及び／又は任意の数のレシーバを含んでよい。また、１つのノード内で複数の機能エンティティを包含する論理的な単位（例えば、図中の破線枠参照）が定義されてもよい（例えば、１つのＩＰゲートウェイに収容される１つのデバイスが複数のストリームを送信し又は受信するケース）。例えば、ＡＭＷＡにより検討されているＮＭＯＳは、こうした論理的なシステムモデルを前提として、ＩＰドメインでのストリームの伝送を管理し及び制御するためのアプリケーションプロトコルインタフェース（ＡＰＩ）の仕様を規定している。

なお、本明細書において、ノード２０ａ、２０ｂ、２０ｃ及び２０ｄを互いに区別する必要が無い場合には、符号の末尾のアルファベットを省略することによりこれらをノード２０と総称する。センダ６０ａ、６０ｂ、６０ｃ、６０ｄ（センダ６０）及びレシーバ６５ａ、６５ｂ、６５ｃ（レシーバ６５）、並びに他の構成要素の符号についても同様である。

（４）エッセンスとストリーム
上述したように、テレビジョン番組のコンテンツは、概して、映像データ、音声データ及び補助データという３種類の放送素材のデータから構成される。本明細書では、放送素材の種類を区別してこれらコンテンツの構成要素へ言及するために、「エッセンス」との語を用いる。言い換えると、エッセンスは、データとして表現された放送素材である。エッセンスをＩＰネットワーク上で伝送しようとする場合、エッセンスは、あるＩＰベースのプロトコルに従って、デジタル信号へ変換されパケット化される。エッセンスを搬送する一連のＩＰパケットには、ストリーム単位で共通するポート番号が付与される。即ち、ストリームは、ＩＰアドレス及びポート番号が共通するＩＰパケットのシーケンスであり得る。ＩＰベースのストリーム伝送プロトコルとして、後述するどのプロトコルが使用される場合にも、通常、パケットは、アプリケーションレイヤではＲＴＰ（Real-time Transport Protocol）、トランスポートレイヤではＵＤＰ（User Datagram Protocol）に従って伝送される。

（５）ＩＰベースのストリーム伝送プロトコル
ＩＰベースのストリーム伝送のための代表的なプロトコルの１つは、ＳＭＰＴＥ ＳＴ２０２２－６である。ＳＭＰＴＥ ＳＴ２０２２－６は、ＳＤＩ信号をそのままＩＰパケットへマッピングする。そのため、単一のＳＴ２０２２－６ストリームが、異なる種類のエッセンスとブランキング期間に相当するデータとを含む。ＳＴ２０２２－６ストリームは、ＩＰドメイン及びＳＤＩドメインが混在する過渡期の放送局システムにおいて好適であり得る。

ＩＰベースのストリーム伝送のための代表的なプロトコルの他の１つは、ＳＭＰＴＥ ＳＴ２１１０である。ＳＭＰＴＥ ＳＴ２１１０は、異なる種類のエッセンスをそれぞれ異なるストリームへマッピングする。そのため、単一のストリームは単一の種類のエッセンスのみを含み、どのストリームもブランキング期間に相当するデータを含まない。ＳＭＰＴＥ ＳＴ２１１０－１０は、ＰＴＰの仕組みに基づく、放送局システムに参加するノード間の高精度の同期のための手法を規定している。ＳＭＰＴＥ ＳＴ２１１０－２０は、非圧縮の映像エッセンスの伝送フォーマットを規定している。ＳＭＰＴＥ ＳＴ２１１０－２１は、映像エッセンスのトラフィックシェーピングのための手法を規定している。ＳＭＰＴＥ ＳＴ２１１０－３０は、非圧縮のＰＣＭ音声エッセンスの伝送フォーマットを規定している。ＳＭＰＴＥ ＳＴ２１１０－３１は、ＡＥＳ３音声エッセンスの伝送フォーマットを規定している。ＳＭＰＴＥ ＳＴ２１１０－４０は、補助データエッセンスの伝送フォーマットを規定している。なお、ＳＭＰＴＥ ＳＴ２１１０シリーズでは、映像エッセンスの圧縮はサポートされておらず、誤り訂正符号化／復号も行われない。

（６）ＳＭＰＴＥ ＳＴ２１１０－１０での時刻同期
テレビジョン番組を正確なスケジュールに従って放送するためには、システム内のノードが正確な時刻を認識していることを要する。また、異なる複数のノードから受信されるストリームを多重化し、複数の映像を合成し、又は映像と音声とを同時に再生する場合にも、ノード間で時刻の精細な同期が確立されていることを要する。図３は、こうした時刻同期の目的のための、ＳＭＰＴＥ ＳＴ２１１０－１０により規定されたシステムタイミングモデルについて説明するための説明図である。

図３には、一例として、放送局システム１のノード２０ａ及びノード２０ｂ、並びに共通基準クロック７０が示されている。共通基準クロック７０は、高精度の時刻源（例えば、ＧＰＳ（Global Positioning System）衛星などのＧＮＳＳ（Global Navigation Satellite System）衛星）に同期し、いわゆるＰＴＰグランドマスタとして動作する。共通基準クロック７０は、ＰＴＰの仕組みに従って、システム内のスレーブノードへ同期メッセージを配信する。

ノード２０ａは、ＰＴＰのスレーブノードである。ノード２０ａは、自身のデバイス内部クロック７２ａを共通基準クロック７０に同期させ、共通基準クロック７０から受信される同期メッセージに基づいてその同期を維持（例えば、遅延を調整）する。ノード２０ａの映像用メディアクロック７３ａは、デバイス内部クロック７２ａにロックされ、映像固有の周波数で進行する。音声用メディアクロック７６ａは、デバイス内部クロック７２ａにロックされ、音声固有の周波数で進行する。ＳＭＰＴＥ ＳＴ２１１０－２０により規定された映像固有の周波数は９０ｋＨｚであり、ＳＭＰＴＥ ＳＴ２１１０－３０により規定された音声固有の周波数は４８ｋＨｚである。

通常、ＲＴＰパケットにはメディアクロックに対してランダムに生成されるオフセットを有するタイムスタンプが付与されるが、ＳＭＰＴＥ ＳＴ２１１０－１０ではオフセットはゼロとされる。それにより、何らかの障害に起因してセンダがリスタートした場合のストリーム伝送の迅速な復旧が可能とされる（なぜなら、ランダムオフセットの決定のための処理が省略されるためである）。即ち、ノード２０ａの映像用ＲＴＰクロック７４ａは、映像用メディアクロック７３ａに対してオフセットを有さず、映像用メディアクロック７３ａと同一の時刻を示す。そして、ノード２０ａが送信する映像エッセンスのＲＴＰストリームの各パケットのＲＴＰヘッダには、映像用ＲＴＰクロック７４ａに従ってＲＴＰタイムスタンプが付与される。同様に、ノード２０ａの音声用ＲＴＰクロック７７ａは、音声用メディアクロック７６ａに対してオフセットを有さず、音声用メディアクロック７６ａと同一の時刻を示す。そして、ノード２０ａが送信する音声エッセンスのＲＴＰストリームの各パケットのＲＴＰヘッダには、音声用ＲＴＰクロック７７ａに従ってＲＴＰタイムスタンプが付与される。

概していうと、ＳＭＰＴＥ ＳＴ２１１０－１０において、映像又は音声をキャプチャするデバイスは、キャプチャ時刻をＲＴＰタイムスタンプとして各パケットに付与する。コンテンツをストレージからプレイバックするデバイスは、通信インタフェースからのエッセンスの出力時刻をＲＴＰタイムスタンプとして各パケットに付与する。ＳＤＩ信号をＩＰパケットへ変換するデバイスは、アラインメント時点のＳＤＩ信号のクロック値をＲＴＰタイムスタンプとして各パケットに付与する。

ノード２０ｂもまた、ＰＴＰのスレーブノードである。ノード２０ｂは、自身のデバイス内部クロック７２ｂを共通基準クロック７０に同期させ、共通基準クロック７０から受信される同期メッセージに基づいてその同期を維持（例えば、遅延を調整）する。図には示していないものの、ノード２０ａと同様に、ノード２０ｂも、デバイス内部クロック７２ｂにロックされたメディアクロックと、メディアクロックに対しオフセットを有しないＲＴＰクロックとを有する。ノード２０ｂは、例えばノード２０ａから送信される映像エッセンスのＲＴＰストリーム及び音声エッセンスのＲＴＰストリームをそれぞれ異なるポート番号で受信する。そして、ノード２０ｂは、自身のＲＴＰクロックと、受信したＲＴＰストリームの各パケットのＲＴＰヘッダに付与されたＲＴＰタイムスタンプとに基づいて、パケット間の時間合わせ（time alignment）を行う。ＰＴＰを活用するこうした仕組みにより、放送局のＩＰネットワークへ参加するノード間で、誤差１０μ秒以下という高精度の時間同期が可能とされる。

図４は、図３を用いて説明したＳＭＰＴＥ ＳＴ２１１０－１０のシステムタイミングモデルに基づく映像エッセンスと音声エッセンスとの間の時間合わせについて説明するための説明図である。図４を参照すると、ノード２０ａは、映像エッセンスのＲＴＰストリーム８１及び音声エッセンスのＲＴＰストリーム８２を並列的にネットワークへ送出する。ＲＴＰストリーム８１に含まれるパケット（Ｖ_１、Ｖ_２、Ｖ_３、…）の各々は、映像用ＲＴＰクロックに従って付与されたＲＴＰタイムスタンプとシーケンス番号とをＲＴＰヘッダ内に有する。ＲＴＰストリーム８２に含まれるパケット（Ａ_１、Ａ_２、Ａ_３、…）の各々は、音声用ＲＴＰクロックに従って付与されたＲＴＰタイムスタンプとシーケンス番号とをＲＴＰヘッダ内に有する。ノード２０ｂは、ＵＤＰポートＰ_Ｖにおいて、ＲＴＰストリーム８１の一連のＲＴＰパケットを受信し、受信したＲＴＰパケットをシーケンス番号順に処理する。また、ノード２０ｂは、ＵＤＰポートＰ_Ａにおいて、ＲＴＰストリーム８２の一連のＲＴＰパケットを受信し、受信したＲＴＰパケットをシーケンス番号順に処理する。例えば、ノード２０ｂは、映像及び音声を同期的に再生しようする場合、ＲＴＰストリーム８１の各パケットのＲＴＰタイムスタンプとＲＴＰストリーム８２の各パケットのＲＴＰタイムスタンプとを比較して、映像及び音声の再生時刻（例えば、フレームタイミング）を互いに同期させる。なお、複数の映像エッセンスの間、複数の音声エッセンスの間、及び映像エッセンス又は音声エッセンスと補助データエッセンスとの間の時間合わせも同様に行われ得る。

（７）ＡＲＩＢ ＳＴＤ－Ｂ７３
相互に関連する映像、音声及び補助データをＳＭＰＴＥ ＳＴ２１１０のように別々のストリームで伝送すると、トランスポートレイヤでそれらストリームのポート番号が相違することから、受信側でもとのコンテンツを再構築する処理が複雑化する。ポート番号が相違すれば、ＩＰネットワーク上での経路制御の結果として、個々のストリームが辿る伝送経路の違いからストリームごとに異なる遅延を受ける可能性もある。こうした不都合を解消するために、日本国内の標準化団体であるＡＲＩＢは、映像、音声及び補助データを単一のストリームで伝送するためのデータ構造の規定として、ＡＲＩＢ ＳＴＤ－Ｂ７３を規格化済みである。

図５は、ＡＲＩＢ ＳＴＤ－Ｂ７３ １．０版の第２章に記述されているデータグラムの構成について説明するための説明図である。図５に太線の枠で示したデータグラムは、先行するネットワークヘッダ及び後続するＦＣＳ（Frame Check Sequence）と共に、１つのパケットを構成する。ネットワークヘッダは、例えば、ＭＡＣ（Medium Access Control）ヘッダ（例えば、イーサネットヘッダ）、ＩＰヘッダ及びＵＤＰヘッダを含む。エッセンスデータのためのＲＴＰデータグラムは、ＲＴＰヘッダ及び共通ヘッダを含むトランスポートヘッダと、エッセンスヘッダと、エッセンスペイロードとを含む。エッセンスデータグラムは、エッセンスヘッダと、エッセンスペイロードとを含む。共通ヘッダ、エッセンスヘッダ及びエッセンスペイロードを含む部分をＲＴＰペイロードともいう。一方、図には示していないものの、ＦＥＣデータのためのＲＴＰデータグラムは、エッセンスヘッダ及びエッセンスペイロードの代わりにＦＥＣペイロードを含む。なお、本明細書において、パケット及びデータグラムという用語は、互換可能に使用される。これら用語の意味は、当業者により容易に理解されるであろう。

ＲＴＰヘッダは、例えば、データ項目として「ペイロードタイプ」、「シーケンス番号」及び「タイムスタンプ」を含む。「ペイロードタイプ」には固定的な値（例えば、１１０）が設定される。「シーケンス番号」の値は各伝送で１インクリメントされる。その初期値はランダムに設定され得る。「タイムスタンプ」の値は単調に線形的にインクリメントされるものの、ＡＲＩＢ ＳＴＤ－Ｂ７３ １．０版は本フィールドを同期に使用しないことを規定している。

共通ヘッダは、例えば、データ項目として「フレームカウント」、「データグラムタイプ」及び「シーケンス番号」を含む。共通ヘッダの「フレームカウント」には、対応するエッセンスヘッダの「フレームカウント」と同じ値が設定される。「データグラムタイプ」には、対応するデータグラムがエッセンスデータグラムであるか又はＦＥＣ（Forward Error Correction）データグラムであるかを示す値が設定される。「シーケンス番号」の値は、映像エッセンス、音声エッセンス及び補助データエッセンス（並びにＦＥＣ）で別々に、伝送の都度１インクリメントされる。その初期値はランダムに設定され得る。

エッセンスヘッダは、例えば、データ項目として「ペイロードタイプ」及び「フレームカウント」を含む。「ペイロードタイプ」には、後続するエッセンスペイロードに含まれるエッセンスのタイプを示す値が設定される（０：映像、１：音声、２：補助データ、など）。エッセンスヘッダの「フレームカウント」には、受信側で各エッセンスのデータグラムの同期を取るための値が設定される。ＳＭＰＴＥ ＳＴ２０５９－１で定義されているエポックの時刻が「フレームカウント」の初期値ゼロとして使用される。「フレームカウント」の値は新しい映像フレームの開始の都度１インクリメントされ、同じ映像フレームに属する全てのエッセンスデータグラムに同じ値が設定される。

図６は、ＡＲＩＢ ＳＴＤ－Ｂ７３に従った単一ストリームでの映像エッセンス及び音声エッセンスの伝送について説明するための説明図である。図６を参照すると、ノード２０ｃは、映像エッセンスのためのパケット及び音声エッセンスのためのパケットの双方を含むＲＴＰストリーム８３をネットワークへ送出する。ＲＴＰストリーム８３に含まれるパケット（Ｖ_１、Ａ_１、Ｖ_２、Ａ_２、…）の各々は、フレームカウント値をエッセンスヘッダ内に有する。ノード２０ｄは、単一のポートＰ_Ｍにおいて、ＲＴＰストリーム８３の一連のＲＴＰパケットを受信し、受信したＲＴＰパケットをシーケンス番号順に処理する。上述したように、ＡＲＩＢ ＳＴＤ－Ｂ７３によれば、ＲＴＰヘッダ内のシーケンス番号の順で前後に並ぶ一群のＲＴＰパケットが同じ映像フレームに属し、同じフレームカウント値を有する。そのため、ノード２０ｄは、映像エッセンス及び音声エッセンスを含む当該一群のＲＴＰパケットを同期的に処理することができる。

しかし、ＡＲＩＢ ＳＴＤ－Ｂ７３は、放送局システムに参加するノード間でどのように協調的に動作してストリームを処理すべきかを規定していない。

例えば、ストリームの伝送に関与するノード間で高精度の同期が確立されておらず、パケット間の時間合わせのために使用すべき時刻情報用のフィールドに合意が無ければ、放送局システム内でやり取りされる多様なエッセンスを柔軟に組み合わせて放送コンテンツを構成することができない。そこで、後述する第１の実施形態及び第２の実施形態において、放送局のＩＰネットワーク上で映像データ、音声データ又は補助データといったエッセンスデータを単一のストリームで伝送するプロトコル（例えば、ＡＲＩＢ ＳＴＤ－Ｂ７３）を利用する際に、エッセンスデータの適切な時間合わせを行う仕組みを提案する。

加えて、ＳＭＰＴＥ ＳＴ２１１０ストリームのために通常利用されるＳＤＰオブジェクトのフォーマットは、フォーマット構造においても、記述される情報の内容においても、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームの特性に必ずしも適していない。そこで、後述する第３の実施形態及び第４の実施形態において、放送局のＩＰネットワーク上で映像データ、音声データ又は補助データといったエッセンスデータを単一のストリームで伝送するプロトコルを利用する際に、当該ストリームの伝送を適切にセットアップすることを可能にする手法を説明する。

なお、本明細書において、異なる種類のエッセンスデータが単一のストリームで伝送されるようなストリームを、エッセンス混在型ストリームともいう。エッセンス混在型ストリームの例は、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリーム及びＳＭＰＴＥ ＳＴ２０２２－６ストリームを含む。また、本明細書において、異なる種類のエッセンスデータがそれぞれ異なるストリームで伝送されるようなストリームを、エッセンス分離型ストリームともいう。エッセンス分離型ストリームの例は、ＳＭＰＴＥ ＳＴ２１１０ストリームを含む。

＜＜２．第１の実施形態＞＞
本章で説明する放送信号処理ノード１００は、上述したセンダ６０及びレシーバ６５の双方の機能性を含む。しかしながら、当業者にとって明らかなように、放送信号処理ノード１００において、センダ６０及びレシーバ６５のうちの一方の機能性が省略されてもよい。放送信号処理ノード１００は、放送局システム１において、例えば、図１及び図２を用いて説明したノード２０ａ～２０ｄのいずれかに相当し得る。

＜２－１．放送信号処理ノードの構成例＞
図７は、第１の実施形態に係る放送信号処理ノード１００の構成の一例を示すブロック図である。図７を参照すると、放送信号処理ノード１００は、デバイス内部クロック１１０、メディアクロック１１２、ＲＴＰクロック１１４、ＰＴＰ処理部１１６、通信部１２０、送信ストリーム処理部１３０、受信ストリーム処理部１４０、データ処理部１８０及び制御部１９０を備える。

（１）デバイス内部クロック
デバイス内部クロック（機器内部クロックともいう）１１０は、放送信号処理ノード１００が保持する固有の内部的なクロックである。本実施形態において、デバイス内部クロック１１０は、ＰＴＰの時刻源に直接的に又は間接的に同期する。典型的には、放送信号処理ノード１００がＰＴＰスレーブである場合、デバイス内部クロック１１０は、ＰＴＰグランドマスタを介してＰＴＰの時刻源に間接的に同期する。一方、放送信号処理ノード１００がＰＴＰマスタである場合、デバイス内部クロック１１０は、ＰＴＰの時刻源に直接的に同期する。例えば、後述する制御部１９０は、放送信号処理ノード１００がＰＴＰマスタにならないように自身を設定してもよい。

（２）メディアクロック
メディアクロック１１２は、デジタルメディア信号の処理（例えば、サンプリング及び再構成）のために使用されるクロックである。本実施形態において、メディアクロック１１２は、ＳＭＰＴＥ ＳＴ２０５９－１で定義されているエポックの時刻を初期値ゼロとして使用し、デバイス内部クロック１１０に周波数ロックされて、正確なレートで進行する。放送信号処理ノード１００が共通基準クロックを取得できず、ローカルタイムベース上で動作している場合には、ＳＭＰＴＥ ＳＴ２０５９－１で定義されている上記エポックを前提として、利用可能な時刻源のうち最良のものがメディアクロック１１２及び後述するＲＴＰクロック１１４のために用いられ得る。

本実施形態において、放送信号処理ノード１００は、異なる種類のエッセンスデータを単一のストリームで伝送するための伝送プロトコルであるＡＲＩＢ ＳＴＤ－Ｂ７３をサポートする。ＡＲＩＢ ＳＴＤ－Ｂ７３では、映像エッセンス、音声エッセンス及び補助データエッセンスの各々のタイミングは、映像フレームに関連付けられる。この場合、ＲＴＰタイムスタンプの基礎となるメディアクロックはエッセンスデータの種類によらず単一であってよい。後述するＲＴＰクロック１１４も同様である。

ＳＭＰＴＥ ＳＴ２１１０－２０では、映像エッセンスのためのメディアクロック周波数は、９０ｋＨｚと規定されている。一方、既存の多くの放送用機器は、２７．０ＭＨｚのクロックを有する。ＳＤＩイメージを伝送するＳＭＰＴＥ ＳＴ２０２２－６ストリームをＳＭＰＴＥ ＳＴ２１１０－１０システムへ統合するために検討されているＳＭＰＴＥ ＳＴ２０２２－８では、２７．０ＭＨｚのメディアクロック周波数が規定されている。メディアクロック周波数を９０ｋＨｚとした場合、当該周波数は、映像フレームの周波数として利用されることの多い６０／１．００１Ｈｚの整数倍にならない。一方、メディアクロック周波数を２７．０ＭＨｚとした場合、当該周波数は６０／１．００１Ｈｚの整数倍となる。この点を考慮し、本実施形態では、フレーム期間を正確に一定にして、クロック値を単調増加させる点において取り扱い上有利な２７．０ＭＨｚを、メディアクロック１１２のクロック周波数として利用する。

（３）ＲＴＰクロック
ＲＴＰクロック１１４は、ＲＴＰパケットのＲＴＰヘッダへ付与されるタイムスタンプの基礎となるクロックである。本実施形態において、ＲＴＰクロック１１４は、ＳＭＰＴＥ ＳＴ２１１０－１０の規定に従い、メディアクロック１１２に対しオフセットを有しないものとする。即ち、ＲＴＰクロック１１４は、関連付けられるメディアクロック１１２と同一の値を有する。したがって、本実施形態において、ＲＴＰクロック１１４のクロック周波数は、メディアクロック１１２のクロック周波数と同様に２７．０ＭＨｚに等しい。

（４）ＰＴＰ処理部
本実施形態において、放送信号処理ノード１００は、例えばＳＭＰＴＥ ＳＴ２０５９－２のＰＴＰプロファイルをサポートする。そして、ＰＴＰ処理部１１６は、ＰＴＰマスタ（例えば、図３を用いて説明した共通基準クロック７０）との間で通信部１２０を介して同期メッセージを交換することにより、デバイス内部クロック１１０のＰＴＰ時刻源との同期を維持する。それにより、放送信号処理ノード１００は、同じくＰＴＰ時刻源と同期したクロックを有する他のノードとの間で、高精度で同期的に動作することが可能となる。

（５）通信部
通信部１２０は、放送信号処理ノード１００による他のノードとの通信を仲介するインタフェースである。通信部１２０は、有線通信のための接続端子及び接続回路を含んでもよく、又は無線通信のためのアンテナ、ＲＦ（Radio Frequency）回路及びベースバンド回路を含んでもよい。本実施形態において、通信部１２０は、送信部１２２及び受信部１２４を含む。

送信部１２２には、後述する送信ストリーム処理部１３０により生成される、放送信号ストリームのための一連のＲＴＰパケットが入力される。各ＲＴＰパケットは、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む。各ＲＴＰパケットのＲＴＰヘッダには、デバイス内部クロック１１０にロックされたメディアクロック１１２に対しオフセットを有しないＲＴＰクロック１１４に従ってＲＴＰタイムスタンプが付与されている。送信部１２２は、入力される各ＲＴＰパケットにネットワークヘッダを追加して、各パケットを放送局システム１に参加する他のノードへ送信する。上記ストリームがＡＲＩＢ ＳＴＤ－Ｂ７３ストリームである場合、ネットワークヘッダ内に記述されるポート番号は、映像データを搬送するパケット、音声データを搬送するパケット及び補助データを搬送するパケットで共通的である。

受信部１２４は、一連のＲＴＰパケットからなる放送信号ストリームを、放送信号処理ノード１００の送信ストリーム処理部１３０及び送信部１２２と同様のセンダ機能を有する他のノードから受信する。各ＲＴＰパケットは、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む。上記ストリームがＡＲＩＢ ＳＴＤ－Ｂ７３ストリームである場合、一連のＲＴＰパケットは、共通的なポート番号を介して、単一のストリームとして受信される。各ＲＴＰパケットのＲＴＰヘッダは、送信側のノードのデバイス内部クロックにロックされたメディアクロックに対しオフセットを有しないＲＴＰクロックに従って付与されたＲＴＰタイムスタンプを含む。各ＲＴＰパケットのＲＴＰペイロード内のヘッダは、同じＲＴＰクロックに基づくフレームカウント情報を含む。放送信号処理ノード１００及び送信側のノードは、上述したようにＰＴＰの時刻源に直接的に又は間接的に同期している。したがって、それらノード間のクロックの誤差は、例えば１０μ秒以下であり得る。

受信部１２４は、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリーム以外の放送信号ストリームを他のノードから受信してもよい。例えば、受信部１２４は、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームと同様のエッセンス混在型ストリーム（例えば、ＳＭＰＴＥ ＳＴ２０２２－６ストリーム）を受信してもよい。また、受信部１２４は、ＳＭＰＴＥ ＳＴ２１１０ストリームのようなエッセンス分離型ストリームを受信してもよい。

受信部１２４は、受信した放送信号ストリームの各パケットからネットワークヘッダを除去して、ＲＴＰヘッダ及びＲＴＰペイロードからなるＲＴＰパケットを受信ストリーム処理部１４０へ出力する。

（６）送信ストリーム処理部
送信ストリーム処理部１３０は、データ処理部１８０から入力される映像データ、音声データ又は補助データのシーケンスを処理して、放送信号ストリームのための一連のＲＴＰパケットを生成する。送信ストリーム処理部１３０は、例えば、入力されるデータシーケンスを１つ以上のエッセンスペイロードへセグメント化し、各ペイロードにエッセンスヘッダを追加する。エッセンスヘッダ内のペイロードタイプは、対応するエッセンスのタイプを示す値に設定され、フレームカウントの値は新しい映像フレームの開始の都度１インクリメントされる。送信ストリーム処理部１３０は、さらに、各パケットにトランスポートヘッダ（共通ヘッダ及びＲＴＰヘッダ）を追加する。共通ヘッダ内のシーケンス番号の値は、映像エッセンス、音声エッセンス及び補助データエッセンスで別々に、伝送の都度１インクリメントされる。ＲＴＰヘッダ内のペイロードタイプは固定的な値に設定され、シーケンス番号の値はペイロードタイプによらず各伝送で１インクリメントされる。送信ストリーム処理部１３０は、さらに、ＲＴＰクロック１１４に従ってＲＴＰヘッダへＲＴＰタイムスタンプを付与する。送信ストリーム処理部１３０は、このように生成される一連のＲＴＰパケットを送信部１２２へ出力する。

（７）受信ストリーム処理部
受信ストリーム処理部１４０は、他のノードから受信部１２４を介して受信される放送信号ストリームの一連のＲＴＰパケットを処理して、映像データ、音声データ又は補助データを復元する。そして、受信ストリーム処理部１４０は、復元したデータのシーケンスをデータ処理部１８０へ出力する。とりわけ、本実施形態において、受信ストリーム処理部１４０は、受信されるＲＴＰパケットのＲＴＰヘッダから取得されるＲＴＰタイムスタンプ、又は、受信されるＲＴＰパケットのＲＴＰペイロード内のヘッダ（例えば、エッセンスヘッダ又は共通ヘッダ）から取得されるフレームカウント情報に基づいて、当該ＲＴＰパケットと他のＲＴＰパケットとの間でエッセンスデータの時間合わせを行う。こうした時間合わせのための受信ストリーム処理部１４０のより詳細な構成の一例について、後にさらに説明する。

（８）データ処理部
データ処理部１８０は、映像データ、音声データ又は補助データを生成して、生成したデータのシーケンスを送信ストリーム処理部１３０へ出力する。データ処理部１８０は、例えば、図示しないデータソースから入力される映像データを圧縮して、圧縮済みの映像データを生成してもよい。また、データ処理部１８０は、受信ストリーム処理部１４０により復元される映像データ、音声データ又は補助データを処理する。データ処理部１８０は、例えば、受信ストリーム処理部１４０により復元され、互いに時間合わせされたエッセンスデータに基づいて、複数のエッセンス（例えば、映像エッセンス、音声エッセンス及び補助データエッセンスのうちの２つ以上、又は複数の映像エッセンスなど）を同期的に再生してもよい。また、データ処理部１８０は、受信ストリーム処理部１４０により復元される映像データ、音声データ又は補助データを所定のファイルフォーマットで記録媒体（図示せず）に記録してもよい。また、データ処理部１８０は、受信ストリーム処理部１４０から入力される映像データが圧縮済みの映像データである場合には、当該圧縮済みの映像データを逆圧縮して、もとの映像データを復元してもよい。

（９）制御部
制御部１９０は、放送信号処理ノード１００の上述した動作の全般を制御する。制御部１９０は、例えば、ＡＰＳ４０又は制御端末５０といった外部装置から受信される指示に応じて、放送信号ストリームを送信部１２２から送信させ、又は放送信号ストリームを受信部１２４により受信させる。放送信号処理ノード１００が複数の伝送プロトコルをサポートする場合には、制御部１９０は、例えば外部装置からの指示において選択される伝送プロトコルのための動作を、各処理部に実行させる。制御部１９０は、通信部１２０を介して他のノードへ、放送信号処理ノード１００の機能性（例えば、サポートするプロトコル、送信／受信可能なエッセンスのタイプ、クロック周波数及びその他の属性）を通知してもよい。

本明細書で説明するいくつかの実施形態において、ＲＴＰストリームである放送信号ストリームの属性は、ＳＤＰオブジェクトに記述される。ＳＭＰＴＥ ＳＴ２１１０－１０によれば、１つ以上のセンダを含むデバイスは、ＲＴＰストリームごとに１つのＳＤＰオブジェクトを構築するものとされている。本実施形態においても、センダとしての役割を有する送信ストリーム処理部１３０及び送信部１２２により送信可能なストリームの属性を記述したＳＤＰオブジェクトが、放送信号処理ノード１００の記憶部（図示せず）に予め記憶され得る。そして、制御部１９０は、ストリームの送信の開始に先立って、予め定義される管理用のアプリケーションプロトコルインタフェース（例えば、ＮＭＯＳ ＡＰＩ）を介して当該ＳＤＰオブジェクトを外部装置へ提供する。一方、制御部１９０は、受信部１２４及び受信ストリーム処理部１４０に他の送信ノードから放送信号ストリームを受信させる場合、当該送信ノードにより提供されるＳＤＰオブジェクトの記述に従って、受信される放送信号ストリームを正しく処理できるように受信側の処理を構成する。なお、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームの特性に適したＳＤＰオブジェクトのフォーマットについて、後述する第３の実施形態及び第４の実施形態で詳しく説明する。

＜２－２．受信ストリーム処理部の詳細な構成例＞
図８は、図７に示した受信ストリーム処理部１４０の詳細な構成の一例を示すブロック図である。図８を参照すると、受信ストリーム処理部１４０は、トランスポート処理部１４２、エッセンスデータグラム処理部１５０及びＦＥＣデータグラム処理部１７０を含む。

（１）トランスポート処理部
トランスポート処理部１４２は、トランスポートヘッダ（ＴＨ）除去部１４４を含む。ＴＨ除去部１４４は、受信部１２４から入力される放送信号ストリームのＲＴＰパケットの先頭のＲＴＰヘッダ及び共通ヘッダ（即ち、トランスポートヘッダ）を除去する。そして、ＴＨ除去部１４４は、共通ヘッダ内の「データグラムタイプ」の値に依存して、当該ＲＴＰパケットのデータグラムを、エッセンスデータグラム処理部１５０又はＦＥＣデータグラム処理部１７０へ分配する。例えば、「データグラムタイプ」の値がエッセンスデータグラムを示す場合には、当該エッセンスデータグラムがエッセンスデータグラム処理部１５０へ出力される。一方、「データグラムタイプ」の値がＦＥＣデータグラムを示す場合には、当該ＦＥＣデータグラムがＦＥＣデータグラム処理部１７０へ出力される。

トランスポート処理部１４２からエッセンスデータグラム処理部１５０又はＦＥＣデータグラム処理部１７０へのデータグラムの出力は、ＲＴＰヘッダ内の「シーケンス番号」の順に行われ得る。欠落したシーケンス番号に対応するデータグラムの処理は、スキップされてよい。トランスポート処理部１４２は、エッセンスデータグラムに対応するＲＴＰヘッダ内のＲＴＰタイムスタンプの値を、アラインメント部１６０へ出力する。

（２）エッセンスデータグラム処理部
エッセンスデータグラム処理部１５０は、エッセンスヘッダ（ＥＨ）除去部１５２、映像エッセンス処理部１５４、音声エッセンス処理部１５６、補助データエッセンス処理部１５８、及びアラインメント部１６０を含む。

ＥＨ除去部１５２は、トランスポート処理部１４２から入力されるエッセンスデータグラムの先頭のエッセンスヘッダを除去する。そして、ＥＨ除去部１５２は、エッセンスヘッダ内の「ペイロードタイプ」の値に依存して、当該エッセンスデータグラムのエッセンスペイロードを、映像エッセンス処理部１５４、音声エッセンス処理部１５６、又は補助データエッセンス処理部１５８へ分配する。例えば、「ペイロードタイプ」の値が映像エッセンスを示す場合には、当該映像エッセンスが映像エッセンス処理部１５４へ出力される。「ペイロードタイプ」の値が音声エッセンスを示す場合には、当該音声エッセンスが音声エッセンス処理部１５６へ出力される。「ペイロードタイプ」の値が補助データエッセンスを示す場合には、当該補助データエッセンスが補助データエッセンス処理部１５８へ出力される。また、ＥＨ除去部１５２は、エッセンスヘッダ内の「フレームカウント」の値をアラインメント部１６０へ出力する。

映像エッセンス処理部１５４は、ＥＨ除去部１５２から順次入力される映像エッセンスを処理して、映像データを復元する。例えば、映像エッセンス処理部１５４は、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームが受信された場合には、ＡＲＩＢ ＳＴＤ－Ｂ７３により規定された映像ペイロードのパッキング形式に従って映像エッセンスを逆パッキングして、映像データを復元し得る。映像エッセンスが圧縮済みの映像データを含む場合には、映像エッセンス処理部１５４は、映像エッセンスを逆圧縮して映像データを復元してもよい（逆圧縮は、上述したようにデータ処理部１８０により行われてもよい）。

音声エッセンス処理部１５６は、ＥＨ除去部１５２から順次入力される音声エッセンスを処理して、音声データを復元する。例えば、音声エッセンス処理部１５６は、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームが受信された場合には、ＡＲＩＢ ＳＴＤ－Ｂ７３により規定された音声ペイロードのパッキング形式に従って音声エッセンスを逆パッキングして、音声データを復元し得る。

補助データエッセンス処理部１５８は、ＥＨ除去部１５２から順次入力される補助データエッセンスを処理して、補助データを復元する。例えば、補助データエッセンス処理部１５８は、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームが受信された場合には、ＡＲＩＢ ＳＴＤ－Ｂ７３により規定された補助データペイロードのパッキング形式に従って補助データエッセンスを逆パッキングして、補助データを復元し得る。

アラインメント部１６０は、各ＲＴＰパケットのＲＴＰヘッダからトランスポート処理部１４２において取得されるＲＴＰタイムスタンプ、又は、各ＲＴＰパケットのＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に基づいて、エッセンスデータ間の時間合わせを行う。

本実施形態において、少なくとも第１のＲＴＰパケットは、エッセンス混在型ストリームのためのプロトコルに従って生成されるパケットである。エッセンス混在型ストリームのためのプロトコルは、例えば、ＡＲＩＢ ＳＴＤ－Ｂ７３であってよい。ＡＲＩＢ ＳＴＤ－Ｂ７３が利用される場合、エッセンス混在型ストリームのＲＴＰパケットの各々は、ブランキング期間に相当するデータを含まず、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む。

図９Ａは、２つのＲＴＰパケットの間のエッセンスデータの時間合わせのための手法の第１の例について説明するための説明図である。図９Ａには、第１のＲＴＰパケット１６１ａ及び第２のＲＴＰパケット１６６ａが示されている。第１のＲＴＰパケット１６１ａ及び第２のＲＴＰパケット１６６ａは、共にＡＲＩＢ ＳＴＤ－Ｂ７３に従って生成されたものとする。第１のＲＴＰパケット１６１ａ及び第２のＲＴＰパケット１６６ａは、単一のポートＰ_Ｍを介して受信される。

第１のＲＴＰパケット１６１ａは、ＲＴＰヘッダ１６２ａ内に「タイムスタンプ」を含み、エッセンスヘッダ１６３ａ内に「ペイロードタイプ」及び「フレームカウント」を含む。エッセンスヘッダ１６３ａの「ペイロードタイプ」の値は対応するエッセンスペイロードが映像エッセンスを含むことを示し、「フレームカウント」は値Ｆ１を示す。値Ｆ１は、例えば、ＳＭＰＴＥ ＳＴ２０５９－１で定義されているエポックの時刻をゼロとした場合の、映像エッセンスが属する映像フレームのキャプチャ時刻に対応する。

第２のＲＴＰパケット１６６ａは、ＲＴＰヘッダ１６７ａ内に「タイムスタンプ」を含み、エッセンスヘッダ１６８ａ内に「ペイロードタイプ」及び「フレームカウント」を含む。エッセンスヘッダ１６８ａの「ペイロードタイプ」の値は対応するエッセンスペイロードが音声エッセンスを含むことを示し、「フレームカウント」は値Ｆ１を示す。値Ｆ１は、例えば、ＳＭＰＴＥ ＳＴ２０５９－１で定義されているエポックの時刻をゼロとした場合の、音声エッセンスが属する映像フレームのキャプチャ時刻に対応する。

図９Ａに示した第１の例において、アラインメント部１６０は、これらＲＴＰパケット１６１ａ、１６６ａのエッセンスヘッダ１６３ａ、１６８ａから取得されるフレームカウント情報に基づいて、ＲＴＰパケット１６１ａとＲＴＰパケット１６６ａとの間でエッセンスデータの時間合わせを行う。このようにエッセンスヘッダ内のフレームカウント情報のみに基づいて時間合わせが行われる場合、トランスポート処理部１４２からアラインメント部１６０へタイムスタンプ情報を出力することが不要となり、プロトコルレイヤをまたいだ情報の参照が抑制されることから、受信ストリーム処理部１４０の構成を簡略化することができる。

図９Ｂは、２つのＲＴＰパケットの間のエッセンスデータの時間合わせのための手法の第２の例について説明するための説明図である。図９Ｂには、第３のＲＴＰパケット１６１ｂ及び第４のＲＴＰパケット１６６ｂが示されている。第３のＲＴＰパケット１６１ｂ及び第４のＲＴＰパケット１６６ｂは、共にＡＲＩＢ ＳＴＤ－Ｂ７３に従って生成されたものとする。第３のＲＴＰパケット１６１ｂ及び第４のＲＴＰパケット１６６ｂは、単一のポートＰ_Ｍを介して受信される。

第３のＲＴＰパケット１６１ｂは、ＲＴＰヘッダ１６２ｂ内に「タイムスタンプ」を含み、エッセンスヘッダ１６３ｂ内に「ペイロードタイプ」及び「フレームカウント」を含む。ＲＴＰヘッダ１６２ｂの「タイムスタンプ」は、値Ｔ２を示す。エッセンスヘッダ１６３ｂの「ペイロードタイプ」の値は、対応するエッセンスペイロードが映像エッセンスを含むことを示す。値Ｔ２は、例えば、映像エッセンスが属する映像フレームのキャプチャ時刻に対応する。

第４のＲＴＰパケット１６６ｂは、ＲＴＰヘッダ１６７ｂ内に「タイムスタンプ」を含み、エッセンスヘッダ１６８ｂ内に「ペイロードタイプ」及び「フレームカウント」を含む。ＲＴＰヘッダ１６７ｂの「タイムスタンプ」は、値Ｔ２を示す。エッセンスヘッダ１６８ｂの「ペイロードタイプ」の値は、対応するエッセンスペイロードが音声エッセンスを含むことを示す。値Ｔ２は、例えば、音声エッセンスが属する映像フレームのキャプチャ時刻に対応する。

図９Ｂに示した第２の例において、アラインメント部１６０は、これらＲＴＰパケット１６１ｂ、１６６ｂのＲＴＰヘッダ１６２ｂ、１６７ｂから取得されるＲＴＰタイムスタンプに基づいて、ＲＴＰパケット１６１ｂとＲＴＰパケット１６６ｂとの間でエッセンスデータの時間合わせを行う。このようにＲＴＰタイムスタンプに基づいて時間合わせが行われる場合、同じくＲＴＰタイムスタンプを利用するＳＭＰＴＥ ＳＴ２１１０－１０のシステムタイミングモデルのための実装を再利用して、アラインメント部１６０を簡易に構成することができる。

図９Ｃは、２つのＲＴＰパケットの間のエッセンスデータの時間合わせのための手法の第３の例について説明するための説明図である。図９Ｃには、第５のＲＴＰパケット１６１ｃ及び第６のＲＴＰパケット１６６ｃが示されている。第５のＲＴＰパケット１６１ｃはＡＲＩＢ ＳＴＤ－Ｂ７３に従って生成され、第６のＲＴＰパケット１６６ｃはＳＭＰＴＥ ＳＴ２１１０－３０に従って生成されたものとする。例えば、第５のＲＴＰパケット１６１ｃはポートＰ_Ｍを介して受信され、第６のＲＴＰパケット１６６ｃは音声エッセンスを含むエッセンス分離型ストリームのためのポートＰ_Ａを介して受信される。

第５のＲＴＰパケット１６１ｃは、ＲＴＰヘッダ１６２ｃ内に「タイムスタンプ」を含み、エッセンスヘッダ１６３ｃ内に「ペイロードタイプ」及び「フレームカウント」を含む。エッセンスヘッダ１６３ｃの「ペイロードタイプ」の値は対応するエッセンスペイロードが映像エッセンスを含むことを示し、「フレームカウント」は値Ｆ３を示す。値Ｆ３は、映像エッセンスが属する映像フレームのキャプチャ時刻に対応する。

第６のＲＴＰパケット１６６ｃは、ＲＴＰヘッダ１６７ｃ内に「タイムスタンプ」を含む。ＲＴＰヘッダ１６７ｃの「タイムスタンプ」は、値Ｔ３を示す。値Ｔ３は、例えば、音声エッセンス内の音声データの最も早いサンプリング時刻に対応する。

図９Ｃに示した第３の例において、アラインメント部１６０は、第５のＲＴＰパケット１６１ｃのエッセンスヘッダ１６３ｃから取得されるフレームカウント情報、及び、第６のＲＴＰパケット１６６ｃのＲＴＰヘッダ１６７ｃから取得されるＲＴＰタイムスタンプに基づいて、ＲＴＰパケット１６１ｃとＲＴＰパケット１６６ｃとの間でエッセンスデータの時間合わせを行う。例えば、アラインメント部１６０は、値Ｔ３に対応するサンプリング時刻が値Ｆ３に対応する映像フレームのフレーム期間に含まれる場合には、第６のＲＴＰパケット１６６ｃから復元される音声データが第５のＲＴＰパケット１６１ｃから復元される映像データと同じ映像フレームへ同期されるべきであると判定し得る。このような手法によれば、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームのＲＴＰパケットのＲＴＰタイムスタンプに実効的なタイムスタンプ値が設定されない場合にも、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームとＳＭＰＴＥ ＳＴ２１１０ストリームとの間で適切に時間合わせを行うことができる。

図９Ｄは、２つのＲＴＰパケットの間のエッセンスデータの時間合わせのための手法の第４の例について説明するための説明図である。図９Ｄには、第７のＲＴＰパケット１６１ｄ及び第８のＲＴＰパケット１６６ｄが示されている。第７のＲＴＰパケット１６１ｄはＡＲＩＢ ＳＴＤ－Ｂ７３に従って生成され、第８のＲＴＰパケット１６６ｄはＳＭＰＴＥ ＳＴ２１１０－２０に従って生成されたものとする。例えば、第７のＲＴＰパケット１６１ｄはポートＰ_Ｍを介して受信され、第８のＲＴＰパケット１６６ｄは映像エッセンスを含むエッセンス分離型ストリームのためのポートＰ_Ｖを介して受信される。

第７のＲＴＰパケット１６１ｄは、ＲＴＰヘッダ１６２ｄ内に「タイムスタンプ」を含み、エッセンスヘッダ１６３ｄ内に「ペイロードタイプ」及び「フレームカウント」を含む。ＲＴＰヘッダ１６２ｄの「タイムスタンプ」は、値Ｔ４を示す。エッセンスヘッダ１６３ｄの「ペイロードタイプ」の値は、対応するエッセンスペイロードが音声エッセンスを含むことを示す。値Ｔ４は、例えば、音声エッセンスが属する映像フレームのキャプチャ時刻に対応する。

第８のＲＴＰパケット１６６ｄは、ＲＴＰヘッダ１６７ｄ内に「タイムスタンプ」を含む。ＲＴＰヘッダ１６７ｄの「タイムスタンプ」は、値Ｔ４´を示す。値Ｔ４´は、例えば、映像エッセンスが属する映像フレームのキャプチャ時刻（インターレース方式の第２フィールドの場合には、フレーム期間の半分だけオフセットされた時刻）に対応する。

図９Ｄに示した第７の例において、アラインメント部１６０は、第７のＲＴＰパケット１６１ｄのＲＴＰヘッダ１６２ｄから取得されるＲＴＰタイムスタンプ、及び、第８のＲＴＰパケット１６６ｄのＲＴＰヘッダ１６７ｄから取得されるＲＴＰタイムスタンプに基づいて、ＲＴＰパケット１６１ｄとＲＴＰパケット１６６ｄとの間でエッセンスデータの時間合わせを行う。このような手法によれば、ＲＴＰタイムスタンプを利用するＳＭＰＴＥ ＳＴ２１１０－１０のシステムタイミングモデルのための実装をＡＲＩＢ ＳＴＤ－Ｂ７３ストリームの処理のために再利用して、アラインメント部１６０を簡易に構成することができる。

（３）ＦＥＣデータグラム処理部
上述したように、ＳＭＰＴＥ ＳＴ２１１０シリーズでは、誤り訂正処理は行われない。一方、ＡＲＩＢ ＳＴＤ－Ｂ７３は、ＲＳ（Reed-Solomon）ベースの手法又はＸＯＲベースの手法でのＦＥＣをサポートしている。ＦＥＣデータグラム処理部１７０は、この誤り訂正処理を担当する。即ち、ＦＥＣデータグラム処理部１７０は、トランスポート処理部１４２から入力されるＦＥＣデータグラムについて誤り訂正処理を実行する。

例えば、ＦＥＣデータグラム処理部１７０は、誤り訂正方式としてＲＳベースの手法が選択される場合には、制御部１９０により設定されるデータグラム数（ｎ，ｋ）をＲＳ復号の処理単位として、ＲＳ復号を実行する。ここで、ｎは、ＦＥＣ演算の対象とされるエッセンスデータグラム数と、対応するＦＥＣデータグラム数との合計を表す。ｋは、当該エッセンスデータグラム数を表す。また、ＦＥＣデータグラム処理部１７０は、誤り訂正方式としてＸＯＲベースの手法が選択される場合には、制御部１９０により設定されるサイズ（Ｌ，Ｄ）のＦＥＣブロックを処理単位として、ＸＯＲベースの復号を実行する。ここで、Ｌは、行方向のエッセンスデータグラム数を表し、Ｄは列方向のエッセンスデータグラム数を表す。

＜２－３．処理の流れ＞
次に、図１０及び図１１を用いて、第１の実施形態において実行され得る主な処理の流れについて説明する。

（１）ストリーム送信処理
図１０は、第１の実施形態に係るストリーム送信処理の流れの一例を示すフローチャートである。ここでは、ストリーム送信処理が放送信号処理ノード１００により実行されるものとして説明するが、ストリーム送信処理は、上述したセンダ６０の機能を有するいかなるノードにより実行されてもよい。

まず、ＰＴＰ処理部１１６は、デバイス内部クロック１１０をＰＴＰの時刻源に直接的に又は間接的に同期させる（ステップＳ１０１）。ＰＴＰの時刻源とのデバイス内部クロック１１０の同期は、この後も継続的に維持される。

送信ストリーム処理部１３０は、例えば制御部１９０による制御の下で、データ処理部１８０から入力されるエッセンスデータからエッセンスペイロードを生成する（ステップＳ１０３）。エッセンスデータは、映像データ、音声データ又は補助データのいずれかを含む。エッセンスペイロードは、例えば、ＡＲＩＢ ＳＴＤ－Ｂ７３により規定された映像データ、音声データ又は補助データのパッキング形式に従ってエッセンスデータをパッキングすることにより生成され得る。

次いで、送信ストリーム処理部１３０は、デバイス内部クロック１１０にロックされたメディアクロック１１２に対しオフセットを有しないＲＴＰクロック１１４に従って、フレームカウント値（及び／又はＲＴＰタイムスタンプ）を算出する（ステップＳ１０５）。フレームカウント値は、同じ映像フレームに属するエッセンスデータが処理されている間は、同じ値に維持される。

次いで、送信ストリーム処理部１３０は、フレームカウント値を含むエッセンスヘッダをエッセンスペイロードの先頭に追加して、エッセンスデータグラムを生成する（ステップＳ１０７）。エッセンスヘッダは、エッセンスペイロードに含まれるエッセンスのタイプを示す「ペイロードタイプ」をも含む。

次いで、送信ストリーム処理部１３０は、ＲＴＰクロック１１４に従った値を有するＲＴＰタイムスタンプを含むトランスポートヘッダをエッセンスデータグラムに追加して、ＲＴＰパケットを生成する（ステップＳ１０９）。送信ストリーム処理部１３０は、さらに誤り訂正符号化処理を実行して、ＦＥＣデータグラムを含むＲＴＰパケットを生成してもよい。

次いで、送信部１２２は、送信ストリーム処理部１３０により生成されたＲＴＰパケットにネットワーク（ＮＷ）ヘッダを追加して、ＩＰパケットを生成する（ステップＳ１１１）。ＩＰパケットのＵＤＰヘッダ内のポート番号は、包含されるエッセンスのタイプに関わらず、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームに割り当てられる共通的な値を示す。ＩＰヘッダ内の宛て先ＩＰアドレスは、例えば、当該ストリームに割り当てられるマルチキャストアドレスを示す。

次いで、送信部１２２は、生成したＩＰパケットをネットワークへ送信する（ステップＳ１１３）。送信されたＩＰパケットは、対応するマルチキャストグループへ加入した受信側のノードにより受信される。

上述したステップＳ１０３～Ｓ１１３の処理は、未処理のエッセンスデータが残っている間、反復的に実行され得る（ステップＳ１１５）。全てのエッセンスデータが処理されると、図１０に示したストリーム送信処理は終了する。

（２）ストリーム受信処理
図１１は、第１の実施形態に係るストリーム受信処理の流れの一例を示すフローチャートである。

まず、放送信号処理ノード１００のＰＴＰ処理部１１６は、デバイス内部クロック１１０をＰＴＰの時刻源に直接的に又は間接的に同期させる（ステップＳ１５１）。ＰＴＰの時刻源とのデバイス内部クロック１１０の同期は、この後も継続的に維持される。

次いで、受信部１２４は、図１０を用いて説明したストリーム送信処理と同様の処理を通じて他のノードから送信される放送信号ストリームのＩＰパケットを受信する（ステップＳ１５３）。放送信号処理ノード１００のデバイス内部クロック１１０がＰＴＰの時刻源と同期していることから、放送信号処理ノード１００は、ＩＰパケットの送信元の上記他のノードとも高い精度で同期している。

次いで、受信部１２４は、受信したＩＰパケットのネットワークヘッダを除去することにより、ＲＴＰデータグラムを抽出する（ステップＳ１５３）。そして、受信部１２４は、抽出したＲＴＰデータグラムを受信ストリーム処理部１４０へ出力する。

次いで、受信ストリーム処理部１４０は、ＲＴＰデータグラムのトランスポートヘッダ及びエッセンスヘッダを除去することにより、エッセンスペイロードを抽出する（ステップＳ１５５）。

次いで、受信ストリーム処理部１４０は、エッセンスヘッダ内のペイロードタイプの値に応じて、ＡＲＩＢ ＳＴＤ－Ｂ７３により規定された映像データ、音声データ又は補助データのパッキング形式に従ってエッセンスペイロードを逆パッキングすることにより、エッセンスデータを復元する（ステップＳ１５７）。なお、図１１には示していないものの、受信ストリーム処理部１４０は、エッセンスデータグラムと共にＦＥＣデータグラムが受信される場合には、ＦＥＣデータグラムに基づいて誤り訂正復号を実行して、受信データに含まれるビット誤りを検出してもよい。

次いで、受信ストリーム処理部１４０のアラインメント部１６０は、ＲＴＰヘッダ内のＲＴＰタイムスタンプ、又はＲＴＰペイロード内のフレームカウント情報に基づいて、異なるＲＴＰパケットに由来するエッセンスデータ間の時間合わせを行う（ステップＳ１５９）。

次いで、データ処理部１８０は、アラインメント部１６０により時間合わせされたエッセンスデータに基づく処理を実行する（ステップＳ１６１）。ここで実行される処理は、例えば、複数のエッセンスの同期的な再生、又はエッセンスデータのＳＤＩ信号への変換などであってよい。

上述したステップＳ１５３～Ｓ１６１の処理は、同一のストリームのパケットが継続的に受信されている間、反復的に実行され得る（ステップＳ１６３）。パケットの受信が停止すると、図１１に示したストリーム受信処理は終了する。

＜＜３．第２の実施形態＞＞
次いで、図１２を用いて、第２の実施形態について説明する。上述した第１の実施形態は具体的な実施形態であり、一方で第２の実施形態はより一般化された実施形態である。

＜３－１．放送信号処理ノードの構成例＞
図１２は、第２の実施形態に係る放送信号処理ノード２００の構成の一例を示すブロック図である。放送信号処理ノード２００は、放送信号ストリームを１つ以上の他のノードから受信するノードである。放送信号処理ノード２００により受信されるストリームは、限定ではないものの、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームなどのエッセンス混在型ストリームを含む。図１２を参照すると、放送信号処理ノード２００は、通信部２１０及びアラインメント部２２０を備える。

通信部２１０は、ＰＴＰの時刻源に直接的に又は間接的に同期したデバイス内部クロックにロックされたメディアクロックに対しオフセットを有しないＲＴＰクロックに従ってＲＴＰヘッダへタイムスタンプを付与されたＲＴＰパケットであって、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む当該ＲＴＰパケット（第１のＲＴＰパケット）を受信する。通信部２１０は、さらに他のＲＴＰパケット（第２のＲＴＰパケット）をも受信する。第１のＲＴＰパケットと第２のＲＴＰパケットとは、同一の放送信号ストリームに含まれるパケットであってもよく、又は互いに異なる放送信号ストリームに含まれるパケットであってもよい。

アラインメント部２２０は、受信される上記ＲＴＰパケットの上記ＲＴＰヘッダから取得される上記タイムスタンプ、又は、受信される上記ＲＴＰパケットの上記ＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に基づいて、上記ＲＴＰパケットと上記他のＲＴＰパケットとの間でエッセンスデータの時間合わせを行う。

エッセンスデータの時間合わせのための放送信号処理が、放送信号処理ノード２００の上記動作ステップを含んでもよい。また、それら動作ステップをプロセッサに実行させるコンピュータプログラムが提供されてもよい。また、それら動作ステップをプロセッサに実行させるコンピュータプログラムを記憶した非一時的なコンピュータ読取可能な記憶媒体が提供されてもよい。加えて、第１の実施形態において説明した任意の機能又は処理が本実施形態に適用されてよい。

＜３－２．変形例＞
図１３は、第２の実施形態の第１の変形例に係る放送信号処理ノード２００の構成の一例を示すブロック図である。図１３を参照すると、放送信号処理ノード２００は、図１２を用いて説明した通信部２１０及びアラインメント部２２０に加えて、再生部２３０を備える。

再生部２３０は、アラインメント部２２０により時間合わせされた上記ＲＴＰパケット（第１のＲＴＰパケット）及び上記他のＲＴＰパケット（第２のＲＴＰパケット）の上記エッセンスデータに基づいて、エッセンスを同期的に再生する。例えば、複数のカメラから受信される映像が同時に再生されてもよく、映像及び音声が同期的に再生されてもよく、又は、映像及び／若しくは音声と共に補助データが再生されてもよい。

図１４は、第２の実施形態の第２の変形例に係る放送信号処理ノード２００の構成の一例を示すブロック図である。図１４を参照すると、放送信号処理ノード２００は、第１通信部２１５、アラインメント部２２０、変換部２４０及び第２通信部２５０を備える。

第１通信部２１５は、ＰＴＰの時刻源に直接的に又は間接的に同期したデバイス内部クロックにロックされたメディアクロックに対しオフセットを有しないＲＴＰクロックに従ってＲＴＰヘッダへタイムスタンプを付与されたＲＴＰパケットであって、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む当該ＲＴＰパケット（第１のＲＴＰパケット）を受信する。第１通信部２１５は、さらに他のＲＴＰパケット（第２のＲＴＰパケット）をも受信する。第１のＲＴＰパケットと第２のＲＴＰパケットとは、同一の放送信号ストリームに含まれるパケットであってもよく、又は互いに異なる放送信号ストリームに含まれるパケットであってもよい。

変換部２４０は、アラインメント部２２０による上記ＲＴＰパケット（第１のＲＴＰパケット）と上記他のＲＴＰパケット（第２のＲＴＰパケット）との間のエッセンスデータの時間合わせに基づいて、それらＲＴＰパケットに由来するエッセンスデータをＳＤＩ信号へ変換する。変換部２４０により生成されるＳＤＩ信号の信号形式は、例えばＳＤ－ＳＤＩ、ＨＤ－ＳＤＩ、３Ｇ－ＳＤＩ、６Ｇ－ＳＤＩ又は１２Ｇ－ＳＤＩといった、ＳＤＩの任意の派生であってよい。

第２通信部２５０は、上述した時間合わせに基づいて変換部２４０により生成されるＳＤＩ信号を、ＳＤＩドメインに属する他のノードへ送信する。

＜＜４．第１の実施形態及び第２の実施形態のまとめ＞＞
ここまで、本開示の第１の実施形態及び第２の実施形態について詳細に説明した。上述した実施形態では、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含むＲＴＰパケットと、他のＲＴＰパケットとの間のエッセンスデータの時間合わせが、ＲＴＰヘッダ内のＲＴＰタイムスタンプ、又は、ＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に基づいて行われる。ＲＴＰタイムスタンプは、ＰＴＰの時刻源に直接的に又は間接的に同期したデバイス内部クロックにロックされたメディアクロックに対しオフセットを有しないＲＴＰクロックに従って付与される。かかる構成によれば、放送局のＩＰネットワーク上で映像データ、音声データ又は補助データといったエッセンスデータを単一のストリームで伝送するプロトコルを利用する際に、エッセンスデータの適切な時間合わせを行うことが可能である。

ある例において、上記ＲＴＰパケットは、エッセンス混在型ストリームのためのプロトコルに従って生成されるパケットである。上記エッセンス混在型ストリームは、例えば、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームであってよい。ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームは、ブランキング期間に相当するデータを含まない。こうした例によれば、受信側でもとのコンテンツを再構築する処理を複雑にすることなく、かつエッセンスタイプごとにネットワーク上で異なる遅延を受ける可能性を回避しつつ、エッセンスデータを容易に時間合わせすることができる。

ある例において、上記メディアクロックのクロック周波数は、２７．０ＭＨｚに等しい。かかる構成によれば、メディアクロックのクロック周波数を映像フレーム周波数の整数倍にしてフレーム期間を正確に一定にしつつ、映像データ、音声データ及び補助データを含み得る単一のエッセンス混在型ストリームに、そのメディアクロックのクロック周波数に基づいて共通的なやり方で時間合わせのための情報を付与することができる。

＜＜５．第３の実施形態＞＞
上で既に述べたように、ＳＭＰＴＥ ＳＴ２１１０ストリームのために通常利用されるＳＤＰオブジェクトのフォーマットは、フォーマット構造においても、記述される情報の内容においても、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームの特性に必ずしも適していない。ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームの伝送を適切にセットアップするためには、当該ストリームの特性に適したＳＤＰオブジェクトのフォーマットを定義する必要がある。

＜５－１．既存のＳＤＰオブジェクトの例＞
ＳＤＰは、ストリーミング（又はその他の何らかのセッション）に使用されるパラメータセットをテキスト形式で記述する際のフォーマットを規定するプロトコルである、典型的には、ストリーミングの開始に先立って、ストリームの送信側と受信側との間でＳＤＰオブジェクト（例えば、ＳＤＰ形式で記述されたデータファイル）を送受信することにより、どういったパラメータ値を実際に使用すべきかに関する交渉が行われ、合意が結ばれる。あるいは、ストリームのセットアップに制御ノードが一元的に関与する場合には、ＳＤＰオブジェクトは、当該制御ノードへ提供され得る。

図１５は、エッセンス分離型ストリーム用のＳＤＰオブジェクトの典型的なフォーマット構造について説明するための説明図である。図１５に示したように、ＳＤＰオブジェクトは、セッションレベルの（セッションに属する個々のメディアよりもむしろセッションにとって固有の）属性を記述するためのセッションレベルセクションと、１つ以上のメディアのそれぞれの属性を記述するための１つ以上のメディアレベルセクションとを含む。図１５のＳＤＰオブジェクトは、映像エッセンス用、音声エッセンス用及び補助データエッセンス用のそれぞれのメディアレベルセクションを含んでいる。オプションとして、可用性向上のために映像エッセンスに冗長ＲＴＰストリーム方式が適用される場合には、プライマリの映像エッセンス用のメディアレベルセクションに加えて、セカンダリの映像エッセンス用のメディアレベルセクションがＳＤＰオブジェクトに含められ得る。なお、かかる例に限定されず、冗長ＲＴＰストリーム方式は、映像エッセンス、音声エッセンス及び補助データエッセンスのうちの任意の１つ以上に適用されてよい。各メディアレベルセクションは、対応するエッセンスタイプのストリームの属性を記述する属性フィールド群を含む。即ち、映像エッセンス用のメディアレベルセクションは、映像関連属性フィールド群を、音声エッセンス用のメディアレベルセクションは、音声関連属性フィールド群を、補助データエッセンス用のメディアレベルセクションは、補助データ関連属性フィールド群を含み得る。

図１６は、図１５を用いて説明したフォーマット構造を有する、ＳＭＰＴＥ ＳＴ２１１０ストリームの属性を記述したＳＤＰオブジェクトの一例を示している。

図１６を参照すると、ＳＤＰオブジェクト３０１は、セッションレベルセクション３０２と、４つのメディアレベルセクション３０３、３０４、３０５及び３０６とを含む。セッションレベルセクション３０２は、プロトコルバージョンフィールド（“v=…”）、送信元フィールド（“o=…”）及びセッション名フィールド（“s=…”）など、セッションに固有の情報を記述するためのフィールド群を有する。

個々のメディアレベルセクションの開始は、メディア記述フィールド（“m=…”）により識別される。メディアレベルセクション３０３及び３０４は、映像エッセンスのストリームのためのセクションである。図１６の例では、メディアレベルセクション３０３にプライマリの映像エッセンスのストリームの属性が記述されており、メディアレベルセクション３０４にセカンダリの映像エッセンスのストリームの属性が記述されている。メディアレベルセクション３０５には、音声エッセンスのストリームの属性が記述されている。メディアレベルセクション３０６には、補助データエッセンスのストリームの属性が記述されている。

映像用のメディアレベルセクション３０３の冒頭のメディア記述フィールド（“m=…”）には、メディアタイプ（“video”）、送信ポート番号（“50000”）、トランスポートプロトコル（“RTP/AVP”）、及びフォーマット形式番号（“112”）が記述されている。このメディア記述フィールドに加えて、メディアレベルセクション３０３は、映像関連属性フィールド群３０７を含む。映像関連属性フィールド群３０７は、ソースフィルタ属性フィールド（“a=source-filter:…”）、ＲＴＰマップ属性フィールド（“a=rtpmap:…”）、フォーマット固有パラメータ属性フィールド（“a=fmtp:…”）、基準クロック属性フィールド（“a=ts-refclk:…”）、メディアクロック属性フィールド（“a=mediaclk:…”）、及びマップＩＤ属性フィールド（“a=mid:…”）を含む。これらのうち、ＲＴＰマップ属性フィールド（“a=rtpmap:…”）は、対応するメディア記述フィールドのフォーマット形式番号と同じ値を有するペイロードタイプ番号（“112”）、サブタイプ名（“raw”）及びメディアクロック周波数（“90000”）を示す。フォーマット固有パラメータ属性フィールド（“a=fmtp:…”）には、フォーマット形式番号（“112”）に続いて、フォーマット固有の１つ以上のパラメータのパラメータ名とパラメータ値のペアが列挙される。マップＩＤ属性フィールド（“a=mid:…”）は、冗長ＲＴＰストリームが使用される場合にプライマリストリームとセカンダリストリームとを区別するために使用される。メディアレベルセクション３０４の内容は、メディア記述フィールドの送信ポート番号及びマップＩＤ属性フィールドを除いてメディアレベルセクション３０３と同様であってよいため、図１６では省略されている。

音声用のメディアレベルセクション３０５の冒頭のメディア記述フィールド（“m=…”）には、メディアタイプ（“audio”）、送信ポート番号（“51200”）、トランスポートプロトコル（“RTP/AVP”）、及びフォーマット形式番号（“97”）が記述されている。このメディア記述フィールドに加えて、メディアレベルセクション３０５は、音声関連属性フィールド群３０８を含む。音声関連属性フィールド群３０８は、ＲＴＰマップ属性フィールド（“a=rtpmap:…”）、パケット時間属性フィールド（“a=ptime:…”）、基準クロック属性フィールド（“a=ts-refclk:…”）、メディアクロック属性フィールド（“a=mediaclk:…”）、フォーマット固有パラメータ属性フィールド（“a=fmtp:…”）、及びマップＩＤ属性フィールド（“a=mid:…”）を含む。これらのうち、ＲＴＰマップ属性フィールド（“a=rtpmap:…”）は、対応するメディア記述フィールドのフォーマット形式番号と同じ値を有するペイロードタイプ番号（“97”）、サブタイプ名（“L24”）、メディアクロック周波数（“48000”）及び符号化パラメータ（“6”）を示す。なお、サブタイプ名“L24”は、音声エッセンスが２４ビットのリニアエンコーディングで符号化されることを示す。符号化パラメータ“6”は、音声チャンネル数が６であることを示す。フォーマット固有パラメータ属性フィールド（“a=fmtp:…”）には、フォーマット形式番号（“97”）に続いて、フォーマット固有の１つ以上のパラメータのパラメータ名とパラメータ値のペアが列挙される。

補助データ用のメディアレベルセクション３０６の冒頭のメディア記述フィールド（“m=…”）には、メディアタイプ（“video”）、送信ポート番号（“51300”）、トランスポートプロトコル（“RTP/AVP”）、及びフォーマット形式番号（“98”）が記述されている。このメディア記述フィールドに加えて、メディアレベルセクション３０６は、補助データ関連属性フィールド群３０９を含む。補助データ関連属性フィールド群３０９は、ＲＴＰマップ属性フィールド（“a=rtpmap:…”）、基準クロック属性フィールド（“a=ts-refclk:…”）、メディアクロック属性フィールド（“a=mediaclk:…”）、及びマップＩＤ属性フィールド（“a=mid:…”）を含む。これらのうち、ＲＴＰマップ属性フィールド（“a=rtpmap:…”）は、対応するメディア記述フィールドのフォーマット形式番号と同じ値を有するペイロードタイプ番号（“98”）、サブタイプ名（“smpte291”）及びメディアクロック周波数（“90000”）を示す。

図１６から理解されるように、ＳＭＰＴＥ ＳＴ２１１０ストリーム向けのＳＤＰオブジェクトは、複数のエッセンスタイプのそれぞれのメディアレベルセクションを含み、それらメディアレベルセクションが、対応するエッセンスタイプに依存して異なるフィールドのセットを有する。こうしたフォーマット構造は、ＳＭＰＴＥ ＳＴ２１１０ストリームと同様のエッセンス分離型ストリームには再利用可能であるが、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームのようなエッセンス混在型ストリームの属性を記述するためには適しない。なぜなら、エッセンス混在型ストリームは、単一のストリーム内に複数のエッセンスタイプのデータを含むためである。さらに、映像エッセンスの圧縮をサポートし、かつ誤り訂正符号化／復号も可能なＡＲＩＢ ＳＴＤ－Ｂ７３ストリームをセットアップするために要する情報項目が、図１６に例示したＳＤＰオブジェクトのフォーマットには不足している。

＜５－２．ＳＤＰオブジェクトの新たなフォーマット＞
図１７は、本実施形態においてエッセンス混在型ストリームのために定義されるＳＤＰオブジェクトのフォーマット構造について説明するための説明図である。

図１７に示したように、新たなフォーマットにおいて、ＳＤＰオブジェクトは、セッションレベルの属性を記述するセッションレベルセクションと、複数のエッセンスタイプにとって共通のメディアレベルセクションとを含む。そして、１つの共通的なメディアレベルセクションが、映像エッセンスに関連する属性、音声エッセンスに関連する属性、及び補助データエッセンスに関連する属性を記述するための属性フィールド群を含む。とりわけ、本実施形態では、ＳＤＰの規格において独立した属性フィールドを割り当てられていないパラメータは、フォーマット固有パラメータ属性フィールド内に記述される。このようにして、エッセンス混在型ストリーム（あるいはＡＲＩＢ ＳＴＤ－Ｂ７３ストリーム）の特性にＳＤＰオブジェクトの構造を適合させることで、ストリームに固有の情報を曖昧性無くＳＤＰオブジェクトに記述することができる。

オプションとして、可用性向上のために冗長ＲＴＰストリーム方式が適用される場合には、ＳＤＰオブジェクトは、プライマリのエッセンス共通のメディアレベルセクションに加えて、セカンダリのエッセンス共通のメディアレベルセクションを含み得る。

図１８は、図１７を用いて説明したフォーマット構造を有する、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームの属性を記述したＳＤＰオブジェクトの一例を示している。

図１８を参照すると、ＳＤＰオブジェクト３１１は、セッションレベルセクション３１２と、２つのメディアレベルセクション３１３及び３１８とを含む。セッションレベルセクション３１２は、プロトコルバージョンフィールド（“v=…”）、送信元フィールド（“o=…”）及びセッション名フィールド（“s=…”）など、セッションに固有の情報を記述するためのフィールド群を有する。

メディアレベルセクション３１３及び３１８の開始は、それぞれのメディア記述フィールド（“m=…”）により識別される。メディアレベルセクション３１３及び３１８は共に、複数のエッセンスタイプにとって共通のセクションである。図１８の例では、メディアレベルセクション３１３にプライマリのエッセンス混在型ストリームの属性が記述されており、メディアレベルセクション３１８にセカンダリのエッセンス混在型ストリームの属性が記述されている。

メディアレベルセクション３１３の冒頭のメディア記述フィールド（“m=…”）には、メディアタイプ（“video”）、送信ポート番号（“50000”）、トランスポートプロトコル（“RTP/AVP”）、及びフォーマット形式番号（“110”）が記述される。メディアレベルセクション３１３は、上述したように複数のエッセンスタイプにとって共通のセクションであるものの、本開示に係る技術において、各エッセンスのタイミングは映像フレームに紐付けられることから、ここではメディアタイプの文字列として“video”が選択され得る。送信ポート番号は、例えば、プライベートポート番号の範囲から任意に選択されるＵＤＰポート番号であってよい。フォーマット形式番号は、他の値（例えば、“111”）であってもよい。本実施形態において、フォーマット形式番号は、複数のエッセンスタイプに共通的に付与されるフォーマット識別値としての役割を有する。このメディア記述フィールドに加えて、メディアレベルセクション３１３は、属性フィールド群３１４を含む。とりわけ、図１８の例において、属性フィールド群３１４は、ＲＴＰマップ属性フィールド（“a=rtpmap:…”）３１５、フォーマット固有パラメータ属性フィールド（“a=fmtp:…”）３１６及びパケット時間属性フィールド（“a=ptime:…”）３１７を含む。

ＲＴＰマップ属性フィールド３１５は、フォーマット形式番号と同じ値を有するペイロードタイプ番号（“110”）によって、メディアレベルセクション３１３の冒頭のメディア記述フィールドに関連付けられる。ＲＴＰマップ属性フィールド３１５のサブタイプ名には、例えばプロトコル名称“ARIB_STD-B73”が記述され、この名称から、ＳＤＰオブジェクト３１１を提供するセンダにより送信される放送信号ストリームがＡＲＩＢ ＳＴＤ－Ｂ７３ストリームであることが特定される。ＲＴＰマップ属性フィールド３１５により示されるメディアクロック周波数は、ここでは２７ＭＨｚである。

フォーマット固有パラメータ属性フィールド３１６は、フォーマット形式番号（“110”）によって、メディアレベルセクション３１３の冒頭のメディア記述フィールドに関連付けられる。フォーマット固有パラメータ属性フィールド３１６は、少なくとも、第１のエッセンスタイプのエッセンスデータに関連する第１の属性情報及び第２のエッセンスタイプのエッセンスデータに関連する第２の属性情報を含む。図１８の例においては、フォーマット固有パラメータ属性フィールド３１６は、以下のように分類される情報を含む：
・映像関連属性－映像エッセンスのエッセンスデータに関連する属性情報
・音声関連属性－音声エッセンスのエッセンスデータに関連する属性情報
・補助データ関連属性－補助データエッセンスのエッセンスデータに関連する属性情報
・ＦＥＣ関連属性－誤り訂正方式に関連する属性情報
・トラフィックシェーピング関連属性－トラフィックシェーピングに関連する属性情報

次の表１～表５は、本実施形態においてフォーマット固有パラメータ属性フィールド３１６に記述され得る映像関連属性、音声関連属性、補助データ関連属性、ＦＥＣ関連属性及びトラフィックシェーピング関連属性のパラメータの一覧をそれぞれ示している。

本実施形態では、映像エッセンスデータが圧縮されるかを示す圧縮関連情報が新たに定義される。この圧縮関連情報を含む映像関連属性は、ＳＤＰオブジェクト３１１のメディアレベルセクション３１３のフォーマット固有パラメータ属性フィールド３１６に記述され得る。具体的には、例えば、表１に示したように、圧縮関連情報は、映像エッセンスデータが圧縮されるかを示す圧縮パラメータ“compression”を含む。さらに、映像エッセンスデータが圧縮されることを当該圧縮パラメータが示す場合には、圧縮関連情報は、映像エッセンスデータを圧縮する際に利用されるコーデック（圧縮方式）を示すコーデックパラメータ“codec”を含む。

既存のＳＤＰのフォーマットによれば、音声エッセンスデータに関連する音声チャンネル数情報は、図１６に例示したように、音声用のメディアレベルセクションのＲＴＰマップ属性フィールド（“a=rtpmap:…”）に記述される。しかし、本実施形態のように、複数のエッセンスタイプにとって共通のメディアレベルセクションのみを設け、メディアタイプの文字列として“video”を選択した場合、ＲＴＰマップ属性フィールドに音声チャンネル数情報を記述することはＳＤＰの規格に反する。そこで、本実施形態では、表２に示したように、フォーマット固有の音声関連属性として、音声チャンネル数情報を定義する。この音声チャンネル数情報を含む音声関連属性は、上述した映像関連属性と共に、ＳＤＰオブジェクト３１１のメディアレベルセクション３１３のフォーマット固有パラメータ属性フィールド３１６に記述され得る。具体的には、例えば、音声チャンネル数情報は、音声チャンネル数パラメータ“channel-number”を含む。ＳＭＰＴＥ ＳＴ２１１０－３０では音声チャンネル数は１からレベルに依存して異なる上限値までの範囲内の任意の整数であり得るが、ＡＲＩＢ ＳＴＤ－Ｂ７３では音声チャンネル数は４、８、１２又は１６のいずれかに制約される。

本実施形態では、補助データ関連属性は、映像関連属性（及び音声関連属性）と共に、ＳＤＰオブジェクト３１１のメディアレベルセクション３１３のフォーマット固有パラメータ属性フィールド３１６に記述され得る。具体的には、例えば、表３に示したように、補助データ関連属性は、データＩＤ及びセカンダリデータＩＤ“DID_SDID”並びに映像ペイロードＩＤコード“VPID_Code”を含む。

本実施形態では、エッセンスデータへ適用される誤り訂正方式を示す誤り訂正情報が新たに定義される。この誤り訂正情報は、上述した他の属性と共に、ＳＤＰオブジェクト３１１のメディアレベルセクション３１３のフォーマット固有パラメータ属性フィールド３１６に記述され得る。具体的には、例えば、表４に示したように、誤り訂正情報は、エッセンスデータへ適用される誤り訂正方式を示すタイプパラメータ“FECtype”と、当該タイプパラメータにより示される誤り訂正方式の設定値を示す設定パラメータと、を含む。タイプパラメータがＸＯＲ符号化（“XOR”）を示す場合には、設定パラメータは、誤り訂正ブロックサイズを示すサイズパラメータ“XORsize”を含む。一方、タイプパラメータがリードソロモン符号化（“RS”）を示す場合には、設定パラメータは、リードソロモン符号化の処理単位に相当するデータグラム数を示すデータグラム数パラメータ“RSnum”を含む。

本実施形態では、トラフィックシェーピング関連属性は、上述した他の属性と共に、ＳＤＰオブジェクト３１１のメディアレベルセクション３１３のフォーマット固有パラメータ属性フィールド３１６に記述され得る。具体的には、例えば、表５に示したように、トラフィックシェーピング関連属性は、センダのバッファのタイプを示すバッファタイプパラメータ“TP”を含む。

本実施形態では、パケット時間属性フィールド３１７は、フォーマット固有パラメータ属性フィールド３１６と同一のメディアレベルセクション３１３内に含まれる。これは、図１６の例においてパケット時間属性フィールド（“a=ptime:…”）が映像用のメディアレベルセクション３０３とは異なる音声用のメディアレベルセクション３０５内に含まれていたこととは対照的である。パケット時間属性フィールド３１７は、パケット内のメディアの時間長をミリ秒単位で示す。このフィールドにより示される時間長は、機器のバッファサイズを左右する。本実施形態では、パケット時間属性フィールド３１７により示される時間長は、音声エッセンスのみに適用され得る。

なお、表１～表５に列挙したフォーマット固有パラメータは、一例に過ぎない。複数のエッセンスタイプにとって共通のメディアレベルセクションは、他の追加的なパラメータを含んでもよく、又は表に示したパラメータのうちの１つ以上が省略されてもよい。

メディアレベルセクション３１８の内容は、マップＩＤ属性フィールドなど一部を除いて、メディアレベルセクション３１３と同様であってよい。冗長ＲＴＰストリーム方式が適用されない場合には、メディアレベルセクション３１８はＳＤＰオブジェクト３１１に含まれない。

本項で説明したＳＤＰオブジェクトのフォーマット構造を用いることで、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームのようなエッセンス混在型ストリームの属性を、ストリームの構造に即して適切に記述することが可能となる。さらに、映像エッセンスの圧縮をサポートし、かつ誤り訂正符号化／復号も可能なＡＲＩＢ ＳＴＤ－Ｂ７３ストリームを、当該ストリームの属性に関する情報をＳＤＰオブジェクトの提供を通じて不足なく交換することによりセットアップすることが可能となる。

＜５－３．放送局システムの構成例＞
図１９は、第３の実施形態に係る放送局システム３の概略的な構成の一例を示すブロック図である。図１９を参照すると、放送局システム３は、１つ以上の送信ノード３００ａ～３００ｎと、制御ノード４００と、１つ以上の受信ノード４５０ａ～４５０ｎとを含む。

送信ノード３００ａ～３００ｎの各々（以下、送信ノード３００という）は、放送局システム３において放送信号ストリームを送信可能な放送信号処理ノードである。各送信ノード３００は、少なくとも１つのセンダ６０を有する。送信ノード３００は、自らが送信可能なストリームの属性を記述したＳＤＰオブジェクトを制御ノード４００へ提供する。送信ノード３００により提供されるＳＤＰオブジェクトは、図１７及び図１８を用いて説明した、エッセンス混在型ストリームのための新たなフォーマットに従って記述され得る。

制御ノード４００は、放送局のＩＰネットワークにおける、放送信号ストリームの送信ノードから受信ノードへの送信を制御するノードである。放送局システム３において送信される放送信号ストリームは、異なるタイプのエッセンスデータを単一のポート番号で伝送するエッセンス混在型ストリームを含む。制御ノード４００は、例えば、図１に例示したＡＰＳ４０又は制御端末５０のような外部装置からのリクエストの受信に応じて、指定されるノード間のストリームの伝送をセットアップし、送信ノード３００へ伝送開始を指示する。エッセンス混在型ストリームの伝送のセットアップは、送信元の送信ノード３００から提供される上述したＳＤＰオブジェクトの記述に従って行われ得る。

受信ノード４５０ａ～４５０ｎの各々（以下、受信ノード４５０という）は、放送局システム３において放送信号ストリームを受信可能な放送信号処理ノードである。各受信ノード４５０は、少なくとも１つのレシーバ６５を有する。受信ノード４５０は、制御ノード４００による制御の下で、放送信号ストリームを受信するための受信処理をＳＤＰオブジェクトの記述に従って構成し、放送信号ストリームを送信ノード３００から受信する。受信対象の放送信号ストリームがエッセンス混在型ストリームである場合には、受信ノード４５０は、異なるタイプのエッセンスデータを単一のポート番号で（即ち、単一のストリーム内で）受信する。受信ノード４５０の構成は、第１の実施形態において説明した放送信号処理ノード１００、又は第２の実施形態において説明した放送信号処理ノード２００の構成と同様であってよい。

＜５－４．送信ノードの構成例＞
図２０は、本実施形態に係る送信ノード３００の構成の一例を示すブロック図である。図２０を参照すると、送信ノード３００は、デバイス内部クロック１１０、メディアクロック１１２、ＲＴＰクロック１１４、ＰＴＰ処理部１１６、通信部３２０、送信ストリーム処理部１３０、受信ストリーム処理部１４０、データ処理部１８０、制御部３９０及び記憶部３９５を備える。

（１）通信部
通信部３２０は、送信ノード３００による他のノードとの通信を仲介するインタフェースである。通信部３２０は、有線通信のための接続端子及び接続回路を含んでもよく、又は無線通信のためのアンテナ、ＲＦ回路及びベースバンド回路を含んでもよい。本実施形態において、通信部３２０は、送信部３２２及び受信部３２４を含む。

送信部３２２は、センダ６０としての役割を有し、エッセンス混在型ストリームを放送局システム３のＩＰネットワークへ送信する。当該放送信号ストリームは、例えば、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームであってよい。具体的には、送信ストリーム処理部１３０により生成される、放送信号ストリームのための一連のＲＴＰパケットが送信部３２２へ入力される。各ＲＴＰパケットは、第１の実施形態及び第２の実施形態と同様の時刻情報（ＲＴＰタイムスタンプ及び／又はフレームカウント情報）を含む。送信部３２２は、入力される各ＲＴＰパケットにネットワークヘッダを追加して、各パケットを他のノードへ送信する。

送信部３２２及び受信部３２４は、ストリームの伝送に関連する制御通信にも関与する。具体的には、例えば、受信部３２４は、制御ノード４００（又は受信ノード４５０などの他のノード）からストリームの伝送に関連する様々な制御メッセージを受信する。送信部３２２は、制御ノード４００（又は受信ノード４５０などの他のノード）へ制御メッセージに対する応答メッセージを送信する。

本実施形態において、受信部３２４は、レシーバ６５としての役割を有していてもいなくてもよい。

（２）制御部
制御部３９０は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）又はマイクロコントローラといった１つ以上のプロセッサを含む。制御部３９０は、記憶部３９５により記憶されるコンピュータプログラムを実行することにより、送信ノード３００の動作の全般を制御する。

例えば、制御部３９０は、送信ノード３００が放送局システム３のＩＰネットワークへ接続されると、ｍＤＮＳ（multicast Domain Name System）クエリの発行とその応答の受信を通じて、制御ノード４００を発見する。さらに、制御部３９０は、例えば、受信部３２４を介して、制御ノード４００からＳＤＰオブジェクトの提供を求める制御メッセージを受信する。当該制御メッセージの受信に応じて、制御部３９０は、エッセンス混在型ストリームのための上述した新たなフォーマットに従って放送信号ストリームの属性を記述したＳＤＰオブジェクトを、記憶部３９５から取得する。そして、制御部３９０は、取得したＳＤＰオブジェクトを送信部３２２を介して制御ノード４００へ送信する。

送信ノード３００により提供されるＳＤＰオブジェクトに基づいてストリームの伝送がセットアップされた後、制御部３９０は、制御ノード４００から、ストリームの送信の開始を指示する制御メッセージを受信部３２４を介して受信する。当該制御メッセージの受信に応じて、制御部３９０は、送信部３２２からの放送信号ストリームの送信を開始する。

例えば、送信ノード３００は、ストリームの伝送を管理し及び制御するための制御インタフェース規格の集合であるＮＭＯＳをサポートしてもよい。この場合、上述した制御メッセージの交換は、例えば、ＮＭＯＳ ＩＳ－０４及びＮＭＯＳ ＩＳ－０５において予め定義されるＨＴＴＰ（Hypertext Transfer Protocol）ベースの制御ＡＰＩを介して行われ得る。

（３）記憶部
記憶部３９５は、一時的な及び非一時的なコンピュータ読取可能なメモリを含む。一時的なメモリは、例えばＲＡＭ（Random Access Memory）を含み得る。非一時的なメモリは、例えばＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）のうちの１つ以上を含み得る。記憶部３９５は、送信ノード３００の機能性を実現するためのコンピュータプログラムを記憶する。さらに、本実施形態において、記憶部３９５は、送信ノード３００により送信可能な放送信号ストリームの属性を記述したＳＤＰオブジェクトを記憶する。

ある観点において、上記ＳＤＰオブジェクトは、複数のエッセンスタイプにとって共通のメディア記述フィールドに関連付けられる属性フィールド内に、第１のエッセンスタイプのエッセンスデータに関連する第１の属性情報及び第２のエッセンスタイプのエッセンスデータに関連する第２の属性情報を含む。一例として、第１のエッセンスタイプは、映像エッセンスであってよく、第２のエッセンスタイプは、音声エッセンスであってよい。この場合、ＳＤＰオブジェクトは、複数のエッセンスタイプに共通的な属性フィールド内に、表１に例示したような映像関連属性を第１の属性情報として、表２に例示したような音声関連属性を第２の属性情報として含み得る。他の例として、第１のエッセンスタイプは、映像エッセンスであってよく、第２のエッセンスタイプは、補助データエッセンスであってよい。この場合、ＳＤＰオブジェクトは、複数のエッセンスタイプに共通的な属性フィールド内に、表１に例示したような映像関連属性を第１の属性情報として、表３に例示したような補助データ関連属性を第２の属性情報として含み得る。なお、これらの例に限定されず、送信ノード３００により提供されるＳＤＰオブジェクトは、表１～表５に例示した情報のいかなる組合せを含んでもよい。

他の観点において、上記ＳＤＰオブジェクトは、映像エッセンスデータが圧縮されるかを示す圧縮関連情報、音声エッセンスデータに関連する音声チャンネル数情報、及びエッセンスデータへ適用される誤り訂正方式を示す誤り訂正情報、のうちの１つ以上を、放送信号ストリームのフォーマット固有のパラメータを記述する属性フィールド内に含む。表１を用いて説明したように、上記圧縮関連情報は、映像エッセンスデータが圧縮されるかを示す圧縮パラメータと、映像エッセンスデータが圧縮されることを当該圧縮パラメータが示す場合に、映像エッセンスデータを圧縮する際に利用されるコーデックを示すコーデックパラメータと、を含み得る。また、表４を用いて説明したように、上記誤り訂正情報は、エッセンスデータへ適用される誤り訂正方式を示すタイプパラメータと、当該タイプパラメータにより示される誤り訂正方式の設定値を示す設定パラメータとを含み得る。上記設定パラメータは、例えば、ＸＯＲ符号化のための誤り訂正ブロックサイズを示すサイズパラメータ、又は、リードソロモン符号化のための処理単位に相当するデータグラム数を示すデータグラム数パラメータであり得る。

（４）送信制御処理の流れ－第１の例
図２１は、送信ノード３００により実行され得る送信制御処理の流れの第１の例を示すフローチャートである。

まず、制御部３９０は、送信ノード３００のＩＰネットワークへの接続に応じて、制御ノード４００を発見する（ステップＳ３０１）。

次いで、制御部３９０は、送信ノード３００により送信可能な放送信号ストリームの属性を記述したＳＤＰオブジェクトを記憶部３９５から取得し、取得したＳＤＰオブジェクトを制御ノード４００へ提供する（ステップＳ３０３）。ここで提供されるＳＤＰオブジェクトは、複数のエッセンスタイプにとって共通のメディア記述フィールドに関連付けられる属性フィールド内に、第１及び第２のエッセンスタイプのエッセンスデータに関連する属性情報を含む。

その後、送信ノード３００は、ストリームの送信の開始の指示を待ち受ける（ステップＳ３０５）。そして、制御ノード４００（又は他のノード）からストリームの送信の開始を指示する制御メッセージが受信されると、送信部３２２は、制御部３９０による制御の下で、上記ＳＤＰオブジェクトにより示される属性を有する放送信号ストリームの送信を開始する（ステップＳ３０７）。

（５）送信制御処理の流れ－第２の例
図２２は、送信ノード３００により実行され得る送信制御処理の流れの第２の例を示すフローチャートである。

まず、制御部３９０は、送信ノード３００のＩＰネットワークへの接続に応じて、制御ノード４００を発見する（ステップＳ３０１）。

次いで、制御部３９０は、送信ノード３００により送信可能な放送信号ストリームの属性を記述したＳＤＰオブジェクトを記憶部３９５から取得し、取得したＳＤＰオブジェクトを制御ノード４００へ提供する（ステップＳ３０４）。ここで提供されるＳＤＰオブジェクトは、圧縮関連情報、音声チャンネル数情報、及び誤り訂正情報のうちの１つ以上を、放送信号ストリームのフォーマット固有のパラメータを記述する属性フィールド内に含む。

その後、送信ノード３００は、ストリームの送信の開始の指示を待ち受ける（ステップＳ３０５）。そして、制御ノード４００（又は他のノード）からストリームの送信の開始を指示する制御メッセージが受信されると、送信部３２２は、制御部３９０による制御の下で、上記ＳＤＰオブジェクトにより示される属性を有する放送信号ストリームの送信を開始する（ステップＳ３０７）。

＜５－５．制御ノードの構成例＞
図２３は、本実施形態に係る制御ノード４００の構成の一例を示すブロック図である。図２３を参照すると、制御ノード４００は、通信部４１０、制御部４２０及び記憶部４３０を備える。

（１）通信部
通信部４１０は、制御ノード４００による他のノードとの通信を仲介するインタフェースである。通信部４１０は、有線通信のための接続端子及び接続回路を含んでもよく、又は無線通信のためのアンテナ、ＲＦ回路及びベースバンド回路を含んでもよい。本実施形態において、通信部４１０は、送信部４１２及び受信部４１４を含む。

送信部４１２及び受信部４１４は、放送局システム３内のＩＰネットワーク上でのストリームの伝送に関連する制御通信に関与する。具体的には、例えば、送信部４１２は、送信ノード３００へ、ストリームの伝送のセットアップ、送信の開始又は終了のための制御メッセージを送信し得る。同様に、送信部４１２は、受信ノード４５０へ、ストリームの伝送のセットアップ、受信の開始又は終了のための制御メッセージを送信し得る。受信部４１４は、送信ノード３００及び受信ノード４５０から、制御メッセージに対する応答メッセージを受信し得る。

（２）制御部
制御部４２０は、例えば、ＣＰＵ、ＭＰＵ又はマイクロコントローラといった１つ以上のプロセッサを含む。制御部４２０は、記憶部４３０により記憶されるコンピュータプログラムを実行することにより、制御ノード４００の動作の全般を制御する。本実施形態において、制御部４２０は、情報管理部４２２及びストリーム制御部４２４を含む。

情報管理部４２２は、放送局システム３内の放送信号処理ノードに関する情報のデータベースへの登録及び管理を行う。例えば、情報管理部４２２は、ＩＰネットワークへ接続した送信ノード３００を発見すると、発見した送信ノード３００へ、ＳＤＰオブジェクトの提供を求める制御メッセージを送信部４１２を介して送信する。そして、情報管理部４２２は、送信ノード３００からＳＤＰオブジェクトを受信部４１４を介して受信する。送信ノード３００から受信されるＳＤＰオブジェクトは、送信ノード３００により送信可能な放送信号ストリームの属性を記述している。情報管理部４２２は、受信されるＳＤＰオブジェクトに記述されている情報を記憶部４３０のデータベースへ登録する。情報管理部４２２は、受信ノード４５０からも同様にＳＤＰオブジェクトを取得し、受信ノード４５０により受信可能なストリームの属性などの情報を記憶部４３０のデータベースへ登録し得る。

ストリーム制御部４２４は、放送局システム３内の送信ノード３００から受信ノード４５０へのストリームの伝送を制御する。例えば、ストリーム制御部４２４は、ストリームの伝送を求めるリクエストがＡＰＳ４０又は制御端末５０から受信された場合に、指定された送信ノード３００からの放送信号ストリームの受信をセットアップするように受信ノード４５０に指示する。ストリーム制御部４２４は、例えば、記憶部４３０のデータベースに登録されているストリームの属性を参照することにより、受信処理がどのようにセットアップされるべきかを決定し得る。例えば、次のうちの１つ以上が、ストリームの属性に依存して決定され得る：
・受信される映像エッセンスデータについて逆圧縮を実行すべきか
・逆圧縮を実行する際に利用すべきコーデック
・いくつの音声チャンネルが音声エッセンスデータに含まれるか
・誤り訂正方式としてどの方式を使用すべきか（ＸＯＲ又はＲＳ）
・ＸＯＲ復号により誤り訂正を実行する際のＦＥＣブロックサイズ
・ＲＳ復号により誤り訂正を実行する際の処理単位となるデータグラム数

受信ノード４５０は、ストリーム制御部４２４から受信される上記指示に従って、受信処理を構成し及び対応するマルチキャストグループへ加入することにより、放送信号ストリームの受信をセットアップする。そして、ストリーム制御部４２４は、送信ノード３００へ放送信号ストリームの送信の開始を指示する。それに応じて、送信ノード３００は、放送信号ストリームの送信を開始する。

（３）記憶部
記憶部４３０は、一時的な及び非一時的なコンピュータ読取可能なメモリを含む。一時的なメモリは、例えばＲＡＭを含み得る。非一時的なメモリは、例えばＲＯＭ、ＨＤＤ又はＳＳＤのうちの１つ以上を含み得る。記憶部４３０は、制御ノード４００の機能性を実現するためのコンピュータプログラムを記憶する。さらに、本実施形態において、記憶部４３０は、情報管理部４２２により放送局システム３内のノードからそれぞれ収集されるＳＤＰオブジェクトに記述されている情報をデータベース内に記憶する。

（４）送信制御処理の流れ－第１の例
図２４は、制御ノード４００により実行され得る送信制御処理の流れの第１の例を示すフローチャートである。

まず、情報管理部４２２は、ＩＰネットワークへ接続した送信ノード３００を発見する（ステップＳ４０１）。

次いで、情報管理部４２２は、発見した送信ノード３００により送信可能な放送信号ストリームの属性を記述したＳＤＰオブジェクトを、当該送信ノード３００から受信することにより取得する（ステップＳ４０３）。ここで取得されるＳＤＰオブジェクトは、複数のエッセンスタイプにとって共通のメディア記述フィールドに関連付けられる属性フィールド内に、第１及び第２のエッセンスタイプのエッセンスデータに関連する属性情報を含む。

ストリーム制御部４２４は、ストリームの伝送のセットアップを求めるリクエストを待ち受ける（ステップＳ４０５）。ストリームの伝送のセットアップを求めるリクエストは、例えば、ＡＰＳ４０又は制御端末５０といった外部装置から受信され得る。

ストリーム制御部４２４は、上記リクエストが受信されると、指定された受信ノード４５０に、上記ＳＤＰオブジェクトにより示される属性に従って受信処理を構成し及び対応するマルチキャストグループに加入するように指示する（ステップＳ４０７）。そして、ストリーム制御部４２４は、指定された送信ノード３００に、放送信号ストリームの送信を開始するように指示する（ステップＳ４０９）。

（５）送信制御処理の流れ－第２の例
図２５は、制御ノード４００により実行され得る送信制御処理の流れの第２の例を示すフローチャートである。

まず、情報管理部４２２は、ＩＰネットワークへ接続した送信ノード３００を発見する（ステップＳ４０１）。

次いで、情報管理部４２２は、発見した送信ノード３００により送信可能な放送信号ストリームの属性を記述したＳＤＰオブジェクトを、当該送信ノード３００から受信することにより取得する（ステップＳ４０４）。ここで取得されるＳＤＰオブジェクトは、圧縮関連情報、音声チャンネル数情報、及び誤り訂正情報のうちの１つ以上を、放送信号ストリームのフォーマット固有のパラメータを記述する属性フィールド内に含む。

ストリーム制御部４２４は、ストリームの伝送のセットアップを求めるリクエストを待ち受ける（ステップＳ４０５）。ストリームの伝送のセットアップを求めるリクエストは、例えば、ＡＰＳ４０又は制御端末５０といった外部装置から受信され得る。

ストリーム制御部４２４は、上記リクエストが受信されると、指定された受信ノード４５０に、上記ＳＤＰオブジェクトにより示される属性に従って受信処理を構成し及び対応するマルチキャストグループに加入するように指示する（ステップＳ４０７）。そして、ストリーム制御部４２４は、指定された送信ノード３００に、放送信号ストリームの送信を開始するように指示する（ステップＳ４０９）。

＜＜６．第４の実施形態＞＞
次いで、図２６及び図２７を用いて、第４の実施形態について説明する。上述した第３の実施形態は具体的な実施形態であり、一方で第４の実施形態はより一般化された実施形態である。

＜６－１．送信ノードの構成例＞
図２６は、第４の実施形態に係る送信ノード５００の構成の一例を示すブロック図である。図２６を参照すると、送信ノード５００は、送信部５１０及び制御部５２０を備える。

送信部５１０は、異なるタイプのエッセンスデータを単一のポート番号で伝送する放送信号ストリームを、放送局のＩＰネットワークへ送信する。

制御部５２０は、放送信号ストリームの属性を記述するＳＤＰオブジェクトを他のノードへ提供する。

ある観点において、上記ＳＤＰオブジェクトは、複数のエッセンスタイプにとって共通のメディア記述フィールドに関連付けられる属性フィールド内に、第１のエッセンスタイプのエッセンスデータに関連する第１の属性情報及び第２のエッセンスタイプのエッセンスデータに関連する第２の属性情報を含む。

他の観点において、上記ＳＤＰオブジェクトは、映像エッセンスデータが圧縮されるかを示す圧縮関連情報、音声エッセンスデータに関連する音声チャンネル数情報、及びエッセンスデータへ適用される誤り訂正方式を示す誤り訂正情報、のうちの１つ以上を、上記放送信号ストリームのフォーマット固有のパラメータを記述する属性フィールド内に含む。

ストリームの伝送のセットアップのために実行される送信制御処理が、送信ノード５００の上記動作ステップを含んでもよい。また、それら動作ステップをプロセッサに実行させるコンピュータプログラムが提供されてもよい。また、それら動作ステップをプロセッサに実行させるコンピュータプログラムを記憶した非一時的なコンピュータ読取可能な記憶媒体が提供されてもよい。加えて、第３の実施形態において説明した送信ノード３００の任意の機能又は処理が本実施形態に適用されてよい。

＜６－２．制御ノードの構成例＞
図２７は、第４の実施形態に係る制御ノード６００の構成の一例を示すブロック図である。図２７を参照すると、制御ノード６００は、制御部６１０を備える。

制御ノード６００は、放送局のＩＰネットワークにおける、異なるタイプのエッセンスデータを単一のポート番号で伝送する放送信号ストリームの送信ノードから受信ノードへの送信を制御するノードである。制御部６１０は、上記放送信号ストリームの属性を記述するＳＤＰオブジェクトを上記送信ノードから取得する。そして、制御部６１０は、取得したＳＤＰオブジェクトに従って、上記放送信号ストリームの伝送をセットアップする。

ある観点において、上記ＳＤＰオブジェクトは、複数のエッセンスタイプにとって共通のメディア記述フィールドに関連付けられる属性フィールド内に、第１のエッセンスタイプのエッセンスデータに関連する第１の属性情報及び第２のエッセンスタイプのエッセンスデータに関連する第２の属性情報を含む。

他の観点において、上記ＳＤＰオブジェクトは、映像エッセンスデータが圧縮されるかを示す圧縮関連情報、音声エッセンスデータに関連する音声チャンネル数情報、及びエッセンスデータへ適用される誤り訂正方式を示す誤り訂正情報、のうちの１つ以上を、上記放送信号ストリームのフォーマット固有のパラメータを記述する属性フィールド内に含む。

ストリームの伝送のセットアップのために実行される送信制御処理が、制御ノード６００の上記動作ステップを含んでもよい。また、それら動作ステップをプロセッサに実行させるコンピュータプログラムが提供されてもよい。また、それら動作ステップをプロセッサに実行させるコンピュータプログラムを記憶した非一時的なコンピュータ読取可能な記憶媒体が提供されてもよい。加えて、第３の実施形態において説明した制御ノード４００の任意の機能又は処理が本実施形態に適用されてよい。

＜＜７．第３の実施形態及び第４の実施形態のまとめ＞＞
ここまで、本開示の第３の実施形態及び第４の実施形態について詳細に説明した。これら実施形態では、異なるタイプのエッセンスデータを単一のポート番号で伝送するいわゆるエッセンス混在型ストリームの属性を記述するＳＤＰオブジェクトが、複数のエッセンスタイプにとって共通のメディア記述フィールドに関連付けられる属性フィールド内に、第１のエッセンスタイプのエッセンスデータに関連する第１の属性情報及び第２のエッセンスタイプのエッセンスデータに関連する第２の属性情報を含む。したがって、例えばＡＲＩＢ ＳＴＤ－Ｂ７３ストリームのようなエッセンス混在型ストリームの属性を、ストリームの構造に即してＳＤＰオブジェクト内に適切に記述することができる。その結果、ＳＤＰベースの管理用ＡＰＩを活用してＳＤＰオブジェクトを交換することにより、エッセンス混在型ストリームの伝送を簡易な手続でセットアップすることが可能となる。

例えば、図１５を用いて説明したように、ＳＭＰＴＥ ＳＴ２１１０ストリームのために通常利用される既存のＳＤＰオブジェクトのフォーマットは、映像関連属性が記述されるメディアレベルセクションとは別に、音声関連属性が記述されるメディアレベルセクション及び補助データ関連属性が記述されるメディアレベルセクションを有する。対照的に、第３の実施形態及び第４の実施形態のように、２つ以上のエッセンスタイプにとって共通のメディアレベルセクションにそれらエッセンスタイプのエッセンスデータに関連する属性を記述することで、１つのメディア（ストリーム）に対し１つのメディアレベルセクションというＳＤＰの解釈の一貫性を保つことができる。

追加的に又は代替的に、エッセンス混在型ストリームの属性を記述する上記ＳＤＰオブジェクトが、映像エッセンスデータが圧縮されるかを示す圧縮関連情報、音声エッセンスデータに関連する音声チャンネル数情報、及びエッセンスデータへ適用される誤り訂正方式を示す誤り訂正情報、のうちの１つ以上をフォーマット固有のパラメータを記述する属性フィールド内に含む。したがって、例えばＡＲＩＢ ＳＴＤ－Ｂ７３ストリームのような独自の仕様を有する放送信号ストリームの属性を、ＳＤＰオブジェクトに不足なく記述することができる。その結果、ＳＤＰベースの管理用ＡＰＩを活用してＳＤＰオブジェクトを交換することにより、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームの伝送を簡易な手続でセットアップすることが可能となる。

例えば、図１６を用いて説明したように、ＳＭＰＴＥ ＳＴ２１１０ストリームのために通常利用される既存のＳＤＰオブジェクトのフォーマットは、フォーマット固有パラメータ属性フィールド内に、圧縮関連情報、音声チャンネル数情報及び誤り訂正情報のいずれも有しない。対照的に、第３の実施形態及び第４の実施形態のように、フォーマット固有パラメータ属性フィールド内に、圧縮関連情報、音声チャンネル数情報及び／又は誤り訂正情報を含めることで、ＡＲＩＢ ＳＴＤ－Ｂ７３ストリームの受信側で、ＳＤＰオブジェクトの記述に従って受信処理を適切に構成することができる。

なお、本開示に係る技術は、上述した実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、並びに、本開示のスコープ及び精神から逸脱することなく様々な変形が可能であるということが、当業者に理解されるであろう。

例えば、フローチャートに示した処理ステップは、必ずしも図示した順序通りに実行されなくてもよい。例えば、処理ステップは図示した順序とは異なる順序で実行されてもよく、２つ以上の処理ステップが並列的に実行されてもよい。また、一部の処理ステップが削除されてもよく、さらなる処理ステップが追加されてもよい。

また、本明細書において説明したノードの機能は、ソフトウェア、ハードウェア、及びソフトウェアとハードウェアとの組み合わせのいずれで実現されてもよい。ソフトウェアを構成するコンピュータプログラムのプログラム命令は、例えば、ノードの内部又は外部の非一時的なコンピュータ読取可能な記憶媒体において記憶され、実行時にメモリへ読み込まれてプロセッサにより実行される。

また、本明細書において単一の装置又は単一のノードにより実現されるものとして説明した技術が、複数の装置又は複数のノードが相互に連携することによりシステムとして実現されてもよい。

上記実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

（付記１）
ＰＴＰ（Precision Time Protocol）の時刻源に直接的に又は間接的に同期したデバイス内部クロックにロックされたメディアクロックに対しオフセットを有しないＲＴＰ（Real-time Transport Protocol）クロックに従ってＲＴＰヘッダへタイムスタンプを付与されたＲＴＰパケットであって、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む当該ＲＴＰパケットを受信する通信部と、
受信される前記ＲＴＰパケットの前記ＲＴＰヘッダから取得される前記タイムスタンプ、又は、受信される前記ＲＴＰパケットの前記ＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に基づいて、前記ＲＴＰパケットと他のＲＴＰパケットとの間でエッセンスデータの時間合わせを行うアラインメント部と、
を備える放送信号処理システム。

（付記２）
前記ＲＴＰパケットは、エッセンス混在型ストリームのためのプロトコルに従って生成されるパケットである、付記１に記載の放送信号処理システム。

（付記３）
前記エッセンス混在型ストリームは、ブランキング期間に相当するデータを含まない、付記２に記載の放送信号処理システム。

（付記４）
前記メディアクロックのクロック周波数は、２７．０ＭＨｚに等しい、付記１～３のいずれか１項に記載の放送信号処理システム。

（付記５）
前記アラインメント部は、前記ＲＴＰペイロード内のヘッダから取得される前記フレームカウント情報に基づいて、前記ＲＴＰパケットと前記他のＲＴＰパケットとの間でエッセンスデータの時間合わせを行う、付記１～４のいずれか１項に記載の放送信号処理システム。

（付記６）
前記アラインメント部は、第１の送信装置から受信される第１のＲＴＰパケットのＲＴＰペイロード内のヘッダから取得されるフレームカウント情報、及び第２の送信装置から受信される第２のＲＴＰパケットのＲＴＰヘッダから取得されるタイムスタンプに基づいて、前記第１のＲＴＰパケットと前記第２のＲＴＰパケットとの間でエッセンスデータの時間合わせを行う、付記１～４のいずれか１項に記載の放送信号処理システム。

（付記７）
前記第１のＲＴＰパケットは、エッセンス分離型ストリームのための第１のプロトコルに従って生成されるパケットであり、前記第２のＲＴＰパケットは、エッセンス混在型ストリームのための第２のプロトコルに従って生成されるパケットである、付記６に記載の放送信号処理システム。

（付記８）
前記放送信号処理システムは、前記アラインメント部により時間合わせされた前記ＲＴＰパケット及び前記他のＲＴＰパケットの前記エッセンスデータに基づいて、エッセンスを同期的に再生する再生部、をさらに含む、付記１～７のいずれか１項に記載の放送信号処理システム。

（付記９）
前記放送信号処理システムは、前記アラインメント部による前記ＲＴＰパケットと前記他のＲＴＰパケットとの間の前記エッセンスデータの時間合わせに基づいて、前記エッセンスデータをＳＤＩ（Serial Digital Interface）信号へ変換する変換部、をさらに含む、付記１～７のいずれか１項に記載の放送信号処理システム。

（付記１０）
ＰＴＰ（Precision Time Protocol）の時刻源に直接的に又は間接的に同期したデバイス内部クロックにロックされたメディアクロックに対しオフセットを有しないＲＴＰ（Real-time Transport Protocol）クロックに従ってＲＴＰヘッダへタイムスタンプを付与されたＲＴＰパケットであって、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む当該ＲＴＰパケットを受信することと、
受信される前記ＲＴＰパケットの前記ＲＴＰヘッダから取得される前記タイムスタンプ、又は、受信される前記ＲＴＰパケットの前記ＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に基づいて、前記ＲＴＰパケットと他のＲＴＰパケットとの間でエッセンスデータの時間合わせを行うことと、
を含む放送信号処理方法。

（付記１１）
放送信号処理ノードのプロセッサに、
ＰＴＰ（Precision Time Protocol）の時刻源に直接的に又は間接的に同期したデバイス内部クロックにロックされたメディアクロックに対しオフセットを有しないＲＴＰ（Real-time Transport Protocol）クロックに従ってＲＴＰヘッダへタイムスタンプを付与されたＲＴＰパケットであって、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む当該ＲＴＰパケットを受信することと、
受信される前記ＲＴＰパケットの前記ＲＴＰヘッダから取得される前記タイムスタンプ、又は、受信される前記ＲＴＰパケットの前記ＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に基づいて、前記ＲＴＰパケットと他のＲＴＰパケットとの間でエッセンスデータの時間合わせを行うことと、
を実行させるコンピュータプログラム。

（付記１２）
放送信号処理ノードのプロセッサに、
ＰＴＰ（Precision Time Protocol）の時刻源に直接的に又は間接的に同期したデバイス内部クロックにロックされたメディアクロックに対しオフセットを有しないＲＴＰ（Real-time Transport Protocol）クロックに従ってＲＴＰヘッダへタイムスタンプを付与されたＲＴＰパケットであって、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む当該ＲＴＰパケットを受信することと、
受信される前記ＲＴＰパケットの前記ＲＴＰヘッダから取得される前記タイムスタンプ、又は、受信される前記ＲＴＰパケットの前記ＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に基づいて、前記ＲＴＰパケットと他のＲＴＰパケットとの間でエッセンスデータの時間合わせを行うことと、
を実行させるコンピュータプログラム、を記憶した非一時的なコンピュータ読取可能な記憶媒体。

本開示に係る技術は、限定ではないものの、放送信号を処理するシステムにおいて利用可能である。

１，３ 放送局システム
１０ ＩＰドメイン
２０（２０ａ～ｄ） 放送信号処理ノード
６０（６０ａ～ｄ） センダ
６５（６５ａ～ｃ） レシーバ
７０ 共通基準クロック
７２ａ デバイス内部クロック
７３ａ，７６ａ メディアクロック
７４ａ，７７ａ ＲＴＰクロック
８１，８２ エッセンス分離型ストリーム
８３ エッセンス混在型ストリーム
１００，２００ 放送信号処理ノード
１１０ デバイス内部クロック
１１２ メディアクロック
１１４ ＲＴＰクロック
１１６ ＰＴＰ処理部
１２０，２１０，２１５ 通信部（第１通信部）
１２２ 送信部
１２４ 受信部
１３０ 送信ストリーム処理部
１４０ 受信ストリーム処理部
１４２ トランスポート処理部
１４４ トランスポートヘッダ除去部
１５０ エッセンスデータグラム処理部
１５２ エッセンスヘッダ除去部
１５４ 映像エッセンス処理部
１５６ 音声エッセンス処理部
１５８ 補助データエッセンス処理部
１６０，２２０ アラインメント部
１６１ａ～ｄ，１６６ａ～ｄ ＲＴＰパケット
１６２ａ～ｄ，１６７ａ～ｄ ＲＴＰヘッダ
１６３ａ～ｄ，１６８ａ～ｂ エッセンスヘッダ
１７０ ＦＥＣデータグラム処理部
１８０ データ処理部
１９０ 制御部
２３０ 再生部
２４０ 変換部
２５０ 第２通信部
３００，５００ 送信ノード
３１１ ＳＤＰオブジェクト
３１２ セッションレベルセクション
３１３，３１８ メディアレベルセクション
３１５ ＲＴＰマップ属性フィールド
３１６ フォーマット固有パラメータ属性フィールド
３１７ パケット時間属性フィールド
３２０ 通信部
３２２，５１０ 送信部
３２４ 受信部
３９０，５２０ 制御部
３９５ 記憶部
４００，６００ 制御ノード
４１０ 通信部
４１２ 送信部
４１４ 受信部
４２０，６１０ 制御部
４２２ 情報管理部
４２４ ストリーム制御部
４３０ 記憶部
４５０ 受信ノード

Claims (9)

1. ＰＴＰ（Precision Time Protocol）の時刻源に直接的に又は間接的に同期したデバイス内部クロックにロックされたメディアクロックに対しオフセットを有しないＲＴＰ（Real-time Transport Protocol）クロックに従ってＲＴＰヘッダへタイムスタンプを付与されたＲＴＰパケットであって、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む当該ＲＴＰパケットを受信する通信部と、
   受信される前記ＲＴＰパケットの前記ＲＴＰヘッダから取得される前記タイムスタンプ、又は、受信される前記ＲＴＰパケットの前記ＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に基づいて、前記ＲＴＰパケットと他のＲＴＰパケットとの間でエッセンスデータの時間合わせを行うアラインメント部と、
   を備え、
   前記アラインメント部は、
   第１の送信装置から受信される第１のＲＴＰパケットのＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に対応するフレーム期間に、第２の送信装置から受信される第２のＲＴＰパケットのＲＴＰヘッダから取得されるタイムスタンプが示すサンプリング時刻が含まれる場合には、前記第２のＲＴＰパケットのＲＴＰペイロード内のエッセンスデータを前記第１のＲＴＰパケットから復元されるエッセンスデータと同じフレームに同期させるための時間合わせを行う放送信号処理システム。
2. 前記ＲＴＰパケットは、エッセンス混在型ストリームのためのプロトコルに従って生成されるパケットである、請求項１に記載の放送信号処理システム。
3. 前記エッセンス混在型ストリームは、ブランキング期間に相当するデータを含まない、請求項２に記載の放送信号処理システム。
4. 前記メディアクロックのクロック周波数は、２７．０ＭＨｚに等しい、請求項１～３のいずれか１項に記載の放送信号処理システム。
5. 前記アラインメント部は、前記ＲＴＰペイロード内のヘッダから取得される前記フレームカウント情報に基づいて、前記ＲＴＰパケットと前記他のＲＴＰパケットとの間でエッセンスデータの時間合わせを行う、請求項１～４のいずれか１項に記載の放送信号処理システム。
6. 前記第１のＲＴＰパケットは、エッセンス混在型ストリームのための第１のプロトコルに従って生成されるパケットであり、前記第２のＲＴＰパケットは、エッセンス分離型ストリームのための第２のプロトコルに従って生成されるパケットである、請求項５に記載の放送信号処理システム。
7. 前記放送信号処理システムは、前記アラインメント部により時間合わせされた前記ＲＴＰパケット及び前記他のＲＴＰパケットの前記エッセンスデータに基づいて、エッセンスを同期的に再生する再生部、をさらに含む、請求項１～６のいずれか１項に記載の放送信号処理システム。
8. 前記放送信号処理システムは、前記アラインメント部による前記ＲＴＰパケットと前記他のＲＴＰパケットとの間の前記エッセンスデータの時間合わせに基づいて、前記エッセンスデータをＳＤＩ（Serial Digital Interface）信号へ変換する変換部、をさらに含む、請求項１～６のいずれか１項に記載の放送信号処理システム。
9. ＰＴＰ（Precision Time Protocol）の時刻源に直接的に又は間接的に同期したデバイス内部クロックにロックされたメディアクロックに対しオフセットを有しないＲＴＰ（Real-time Transport Protocol）クロックに従ってＲＴＰヘッダへタイムスタンプを付与されたＲＴＰパケットであって、映像データ、音声データ及び補助データのうちのいずれかに相当するエッセンスデータをＲＴＰペイロードに含む当該ＲＴＰパケットを受信することと、
   受信される前記ＲＴＰパケットの前記ＲＴＰヘッダから取得される前記タイムスタンプ、又は、受信される前記ＲＴＰパケットの前記ＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に基づいて、前記ＲＴＰパケットと他のＲＴＰパケットとの間でエッセンスデータの時間合わせを行うことと、
   を含み、
   前記時間合わせを行うことは、第１の送信装置から受信される第１のＲＴＰパケットのＲＴＰペイロード内のヘッダから取得されるフレームカウント情報に対応するフレーム期間に、第２の送信装置から受信される第２のＲＴＰパケットのＲＴＰヘッダから取得されるタイムスタンプが示すサンプリング時刻が含まれる場合には、前記第２のＲＴＰパケットのＲＴＰペイロード内のエッセンスデータを前記第１のＲＴＰパケットから復元されるエッセンスデータと同じフレームに同期させるための時間合わせを行うことを含む放送信号処理方法。
   

Images