JP2015136057A - 通信装置、通信データ生成方法、および通信データ処理方法 - Google Patents

Abstract

【課題】ＧＯＰを分割したデータ単位でコンテンツ配信を行い、受信装置側でＧＯＰ復元と再生を実行可能とした装置、方法を提供する。
【解決手段】送信装置が、ＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成し、サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録したパケットを生成して送信する。受信装置は、受信パケットに設定されたＧＯＰ内位置識別子を参照して複数のパケットに分割格納されたメディアデータを配列してＧＯＰを再構築して復号する。
【選択図】図７

Description

本開示は、通信装置、通信データ生成方法、および通信データ処理方法に関する。さらに詳細には例えば放送波やネットワークを介したデータの送信または受信を実行する通信装置、通信データ生成方法、および通信データ処理方法に関する。

画像データや音声データ等のコンテンツを各通信事業者のサービス形態に関わらず配信可能としたデータ配信方式としてＯＴＴ（Ｏｖｅｒ Ｔｈｅ Ｔｏｐ）が知られている。ＯＴＴによる配信コンテンツはＯＴＴコンテンツと呼ばれ、また、ＯＴＴを利用した画像（ビデオ）データの配信サービスはＯＴＴビデオやＯＴＴ−Ｖ（Ｏｖｅｒ Ｔｈｅ Ｔｏｐ Ｖｉｄｅｏ）と呼ばれる。

例えばＯＴＴ−Ｖに従ったデータストリーミング配信の基盤技術としてＤＡＳＨ（Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒＨＴＴＰ）が利用される。ＤＡＳＨは、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）プロトコルを使用したアダプティブ（適応型）ストリーミング技術の標準規格である。

アダプティブ（適応型）ストリーミングでは、コンテンツ配信サーバは様々なクライアントで配信コンテンツの再生を可能とするため、複数のビットレートの動画コンテンツの細分化ファイルとこれらの属性情報やＵＲＬを記述したマニフェスト・ファイルを作成し保持する。

クライアントは、マニフェスト・ファイルをサーバから取得して、自装置の表示部のサイズや利用可能な通信帯域に応じた最適なビットレートコンテンツを選択し、選択コンテンツを受信して再生する。ネットワーク帯域の変動に応じてビットレートの動的な変更も可能であり、クライアント側では、状況に応じた最適なコンテンツを随時切り替えて受信することが可能となり、映像途切れの発生を低減した動画コンテンツ再生が実現される。なお、アダプティブ（適応型）ストリーミングについては、例えば特許文献１（特開２０１１−８７１０３号公報）に記載がある。

ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）符号化された動画や音声データを上記のＤＡＳＨに従ってストリーミング配信するための仕様を定めた規格としてＭＰＥＧ−ＤＡＳＨ規格がある。
ＭＰＥＧ−ＤＡＳＨ規格には、以下の２つの規格が含まれる。
（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格。
（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格。
ＭＰＥＧデータをＤＡＳＨに従ってストリーミング配信する場合は、このＭＰＥＧ−ＤＡＨ規格に従った処理が行われる。

しかし、アダプティブ（適応型）ストリーミング技術の標準規格であるＤＡＳＨは１対１の通信処理であるポイントトゥーポイント（Ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ）型のＨＴＴＰストリーミング技術をベースとしている。
このため、例えばスポーツ中継等、多数のクライアントが同時に視聴する可能性のあるコンテンツ（番組）のストリーミング配信に適用する場合にはＣＤＮ（Ｃｏｎｔｅｎｔ Ｄｅｌｉｖｅｒｙ Ｎｅｔｗｏｒｋ）のサポートが必要となる。

しかし、ＣＤＮを適用したポイントトゥーポイントのＨＴＴＰストリーミングを構築するにはコスト的な制約があり、放送配信に匹敵する程のスケーラビリティを実現することは困難である。上述したようにＤＡＳＨはＨＴＴＰをベースのストリーミングプロトコルを利用しており、放送配信のように多数のクライアントが同時に視聴するコンテンツ配信には不向きであるという問題がある。

特開２０１１−８７１０３号公報

本開示は、ＨＴＴＰをベースとするストリーミングプロトコルを利用したコンテンツ配信において、同時に多数のクライアントにコンテンツを提供し、各クライアントにおいて遅延の少ないリアルタイム再生を実現する通信装置、通信データ生成方法、および通信データ処理方法を提供することを目的とする。

本開示の第１の側面は、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成し、
前記サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録したパケットを生成するデータ処理部と、
前記データ処理部の生成したパケットを送信する通信部を有する通信装置にある。

さらに、本開示の通信装置の一実施態様において、前記データ処理部は、ＧＯＰの構成データであるＮＡＬユニットを１つ以上含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成する。

さらに、本開示の通信装置の一実施態様において、前記データ処理部は、パケット格納セグメントが、メディアデータを格納しない初期化セグメントであるか、メディアデータを格納したメディアセグメントであるかを識別可能としたセグメント識別情報をパケット付加情報として記録したパケットを生成する。

さらに、本開示の通信装置の一実施態様において、前記データ処理部は、前記サブＧＯＰメディアセグメントの格納データであるメディアデータが、ＧＯＰの先頭位置、中間位置、末尾位置のいずれの位置の構成データであるかを識別可能としたＧＯＰ内位置識別子をパケット付加情報として生成する。

さらに、本開示の通信装置の一実施態様において、前記データ処理部は、前記付加情報を生成パケット内のＨＴＴＰヘッダに記録する。

さらに、本開示の通信装置の一実施態様において、前記データ処理部は、前記付加情報を生成パケット内の拡張ヘッダに記録する。

さらに、本開示の通信装置の一実施態様において、前記データ処理部は、前記付加情報を生成パケット内のＬＣＴヘッダに記録する。

さらに、本開示の通信装置の一実施態様において、前記通信部は、前記データ処理部の生成したパケットを、放送波を介してブロードキャスト配信、またはマルチキャスト配信する。

さらに、本開示の第２の側面は、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとし、
前記サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録したパケットを受信する通信部と、
前記通信部の受信したパケットを入力して処理を実行するデータ処理部を有する通信装置にある。

さらに、本開示の通信装置の一実施態様において、前記データ処理部は、受信パケットに記録されたＧＯＰ内位置識別子を参照して、複数の受信パケットに分散格納されたＧＯＰ構成データの配列を実行してＧＯＰデータを再構築する。

さらに、本開示の通信装置の一実施態様において、前記通信部は、ＧＯＰの構成データであるＮＡＬユニットを１つ以上含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントを格納したパケットを受信し、前記データ処理部は、受信パケットからＮＡＬユニットを１つ以上含むメディアデータを取得し、受信パケットに記録されたＧＯＰ内位置識別子を参照して、複数の受信パケットに分散格納されたＮＡＬユニットの配列を実行してＧＯＰデータを再構築する。

さらに、本開示の通信装置の一実施態様において、前記通信部は、パケット格納セグメントが、メディアデータを格納しない初期化セグメントであるか、メディアデータを格納したメディアセグメントであるかを識別可能としたセグメント識別情報をパケット付加情報として記録したパケットを受信し、前記データ処理部は、受信パケットに記録された付加情報から、前記セグメント識別情報を取得し、受信パケットに格納されたセグメントの種類を判別して、判別結果に応じた処理を実行する。

さらに、本開示の通信装置の一実施態様において、前記通信部は、前記サブＧＯＰメディアセグメントの格納データであるメディアデータが、ＧＯＰの先頭位置、中間位置、末尾位置のいずれの位置の構成データであるかを識別可能としたＧＯＰ内位置識別子をパケット付加情報として設定したパケットを受信し、前記データ処理部は、受信パケットに記録されたＧＯＰ内位置識別子に基づいて、前記サブＧＯＰメディアセグメントの格納データであるメディアデータが、ＧＯＰの先頭位置、中間位置、末尾位置のいずれの位置の構成データであるかを判別する。

さらに、本開示の通信装置の一実施態様において、前記通信部は、前記パケット付加情報をＨＴＴＰヘッダに記録したパケットを受信し、前記データ処理部は、受信パケットのＨＴＴＰヘッダから前記パケット付加情報を取得する。

さらに、本開示の通信装置の一実施態様において、前記通信部は、前記パケット付加情報を拡張ヘッダに記録したパケットを受信し、前記データ処理部は、受信パケットの拡張ヘッダから前記パケット付加情報を取得する。

さらに、本開示の通信装置の一実施態様において、前記通信部は、前記パケット付加情報をＬＣＴヘッダに記録したパケットを受信し、前記データ処理部は、受信パケットのＬＣＴヘッダから前記パケット付加情報を取得する。

さらに、本開示の通信装置の一実施態様において、前記通信部は、前記パケットを、放送波を介して受信する。

さらに、本開示の第３の側面は、
データ送信装置において実行する通信データ生成方法であり、
データ処理部が、符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成し、
前記サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録した送信パケットを生成する通信データ生成方法にある。

さらに、本開示の第４の側面は、
データ受信装置において実行する通信データ処理方法であり、
通信部が、符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとし、
前記サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録したパケットを受信し、
データ処理部が、前記通信部の受信したパケットを入力して処理を実行する通信データ処理方法にある。

本開示のさらに他の目的、特徴や利点は、後述する本開示の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

本開示の一実施例の構成によれば、ＧＯＰを分割したデータ単位でコンテンツ配信を行い、受信装置側でＧＯＰ復元と再生を実行可能とした装置、方法が実現される。
具体的には、送信装置が、ＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成し、サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録したパケットを生成して送信する。受信装置は、受信パケットに設定されたＧＯＰ内位置識別子を参照して複数のパケットに分割格納されたメディアデータを配列してＧＯＰを再構築して復号する。
本構成により、ＧＯＰを分割したデータ単位でコンテンツ配信を行い、受信装置側でＧＯＰ復元と再生を実行可能とした装置、方法が実現される。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。

本開示の処理を実行する通信システムの一構成例について説明する図である。 送信装置の送信データについて説明する図である。 ＤＡＳＨセグメントの構成例について説明する図である。 フラグメント生成シーケンスについて説明する図である。 フラグメント内のメディアデータ（ｍｄａｔ）を１ＧＯＰ単位のデータではなく、１ＧＯＰを細分化したデータに設定した構成例について説明する図である。 サブＧＯＰメディアセグメントにＨＴＴＰヘッダを設定したＨＴＴＰパケットの構成例について説明する図である。 メディアセグメントＨＴＴＰパケットのＨＴＴＰヘッダの記録情報について説明する図である。 メディアセグメントＨＴＴＰパケットのＨＴＴＰヘッダの記録情報について説明する図である。 初期化セグメントＨＴＴＰパケットのＨＴＴＰヘッダの記録情報について説明する図である。 ＩＰパケットの構成例について説明する図である。 送信装置と受信装置のプロトコルスタックについて説明する図である。 受信装置のプロトコルスタックについて説明する図である。 送信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。 受信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。 拡張ヘッダに付加情報を記録した実施例について説明する図である。 ＦＬＵＴＥプロトコルに従って設定されるＬＣＴヘッダの構成例について説明する図である。 ＬＣＴヘッダのヘッダ拡張部に対するデータ記録構成について説明する図である。 ＬＣＴヘッダのヘッダ拡張部に記録するデータについて説明する図である。 ＨＥＶＣ符号化データの構成について説明する図である。 通信装置のハードウェア構成例について説明する図である。

以下、図面を参照しながら本開示の通信装置、通信データ生成方法、および通信データ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
１．通信システムの構成例について
２．一斉同時配信型のコンテンツ配信における問題点について
３．送信データの細分化処理構成について
４．ＨＴＴＰヘッダに付加情報を記録した実施例について
５．パケットの構成について
６．送信装置と受信装置の構成と処理について
７．送信装置と受信装置の処理シーケンスについて
８．拡張ヘッダに付加情報を記録した実施例について
９．ＬＣＴヘッダに付加情報を記録した実施例について
１０．ＨＥＶＣ符号化データに対する適用例について
１１．各装置のハードウェア構成例について
１２．本開示の構成のまとめ

［１．通信システムの構成例について］
まず、図１を参照して本開示の処理を実行する通信システムの一構成例について説明する。
図１に示すように、通信システム１０は、画像データや音声データ等のコンテンツを送信する通信装置である送信装置２０と、送信装置２０の送信コンテンツを受信する通信装置である受信装置３０を有する。

送信装置２０は、具体的には、例えば放送局２１やコンテンツサーバ２２等、コンテンツを提供する側の装置である。
一方、受信装置３０は、一般ユーザのクライアント装置であり、具体的には、例えばテレビ３１、ＰＣ３２、携帯端末３３等によって構成される。

送信装置２０と受信装置３０間のデータ通信は、インターネット等のネットワークを介した双方向通信、あるいは、放送波等による一方向通信の少なくともいずれか、あるいは両者を利用した通信として行われる。

送信装置２０から受信装置３０に対するコンテンツ送信は、アダプティブ（適応型）ストリーミング技術の規格であるＭＰＥＧ−ＤＡＳＨ規格に従って実行する。
先に説明したように、ＭＰＥＧ−ＤＡＳＨ規格には、以下の２つの規格が含まれる。
（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
送信装置２０から、受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ−ＤＡＳＨ規格に従って実行する。

送信装置２０は、コンテンツデータを符号化し、符号化データおよび符号化データのメタデータを含むデータファイルを生成する。符号化処理は、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って行われる。なお、送信装置２０がＭＰ４形式のデータファイルを生成する場合の符号化データのファイルは「ｍｄａｔ」、メタデータは「ｍｏｏｖ」や「ｍｏｏｆ」等と呼ばれる。
これらの符号化データの詳細については後段で説明する。

送信装置２０が受信装置３０に提供するコンテンツは、例えば音楽データや、映画、テレビ番組、ビデオ、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトウェアなど、様々なデータである。

送信装置２０の送信データについて図２を参照して説明する。
ＭＰＥＧ−ＤＡＳＨ規格に従ってデータ送信を実行する送信装置２０は、図２に示すように、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）５０と、メディアセグメント（Ｍｅｄｉａ Ｓｅｇｍｅｎｔ）６０を、それぞれパケットに格納して受信装置３０に送信する。これらの各セグメントはＤＡＳＨセグメントと呼ばれる。

メディアセグメント６０各々はＭＰＥＧ符号化されたコンテンツデータを分割して格納したセグメントである。
初期化セグメント５０はメディアセグメント６０の格納コンテンツを受信装置３０側で再生する場合に必要となる初期設定情報、例えばコーデックの設定情報などを格納したセグメントである。
なお、送信装置２０は、例えば１つの映画や番組等のコンテンツを、多数のメディアセグメント６０に分割格納して順次送信する。

送信装置２０は、図２に示す初期化セグメント５０、メディアセグメント６０をＨＴＴＰパケットに格納し、さらに、ＨＴＴＰパケットを格納したＩＰパケットを生成して送信する。送信パケットの構成の詳細については後段で説明する。

図２に示す受信装置３０は、まず、１つの初期化セグメント５０を受信し、初期化セグメントに格納された設定情報に従ってコーデック等の設定処理等を実行する。続いて、メディアセグメント６０を順次、受信し、再生順に従ってデコードを行なって再生処理を行なう。

［２．一斉同時配信型のコンテンツ配信における問題点について］
前述したように、アダプティブ（適応型）ストリーミング技術の標準規格であるＤＡＳＨはポイントトゥーポイントのＨＴＴＰストリーミングをベースとしており、多数のクライアントが同時に視聴する一斉同時配信型コンテンツの配信には向かないという問題がある。
しかし、マルチキャストやブロードキャスト（ＭＣ／ＢＣ）を併用することで、コンテンツを同時に多数のクライアント（受信装置）に遅延なく提供することが可能であると考えられる。

マルチキャストやブロードキャスト（ＭＣ／ＢＣ）型のストリーミングに適用可能なトランスポートプロトコルには、例えばＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）やＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）がある。

図３を参照して、ＦＬＵＴＥプロトコルを利用してＨＴＴＰストリーミングベースのＤＡＳＨ規格に従ってコンテンツストリーム配信を行う場合に利用可能なＤＡＳＨセグメントの構成例について説明する。

先に図２を参照して説明したように、ＤＡＳＨセグメントは、
（ａ）初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）、
（ｂ）メディアセグメント（Ｍｅｄｉａ Ｓｅｇｍｅｎｔ）、
これらの２種類に分けられる。

（ａ）初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ Ｓｅｇｍｅｎｔ）は、受信装置３０におけるデコーダの設定等、コンテンツ再生を実行するために必要となる設定情報等の初期化データを格納したセグメントである。
（ｂ）メディアセグメント（Ｍｅｄｉａ Ｓｅｇｍｅｎｔ）は、再生対象となる符号化コンテンツを格納したセグメントである。

図３に示すように（ａ）初期化セグメントは、以下の各情報を含む。
（ａ１）セグメントのファイルタイプ情報等からなるヘッダ情報（ｄａｓｈ）、
（ａ２）メディアセグメントによって送信する符号化コンテンツであるメディアデータ（ｍｄａｔ）のコーデック（符号化態様）情報等の初期化情報を含むメタデータ（ｍｏｏｖ）、

一方、（ｂ）メディアセグメントは、図３に示すように以下の各情報を含む。
（ｂ１）セグメントのファイルタイプ情報等からなるヘッダ情報（ｍｓｄｈ）、
（ｂ２）メディアセグメントに格納された複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）の境界情報や、メディアセグメントに格納された符号化コンテンツであるメディアデータ（ｍｄａｔ）のランダムアクセスポイント等を示すアクセス情報（ｓｉｄｘ）、
（ｂ３）複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）７０、

また、複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）７０は１つまたは複数のフラグメント（Ｆｒａｇｍｅｎｔ）８０で構成される。
フラグメント（Ｆｒａｇｍｅｎｔ）８０は、以下の各データを含む。
再生対象となる符号化コンテンツであるメディアデータ（ｍｄａｔ）、
メディアデータ（ｍｄａｔ）に対応するメタデータ（ｍｏｏｆ）。

なお、（ｂ）メディアセグメントのアクセス情報（ｓｉｄｘ）に記録されるランダムアクセスポイントは、ＤＡＳＨではＳＡＰ（Ｓｔｒｅａｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ）と呼ばれる。
ＳＡＰは、例えばストリームを復号するために必要なすべての状態をリセットすることができる画像シーケンスの先頭ピクチャの先頭バイト位置を示す。具体的には、例えばＭＰＥＧデータのＩピクチャの位置等を示す情報である。

フラグメント（Ｆｒａｇｍｅｎｔ）８０に格納するメディアデータ（ｍｄａｔ）対応のメタデータ（ｍｏｏｆ）には、例えばフラグメント格納メディアデータ（ｍｄａｔ）の再生時間情報としてのプレゼンテーションタイム等が記録される。

１つのフラグメント８０に格納するメディアデータ（ｍｄａｔ）は、現行では、通常、ＤＡＳＨの制御対象となるコンテンツストリームの処理単位（チャンク）に設定される。処理単位（チャンク）とは、例えばＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）符号化の処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）である。
なお、ＧＯＰは再生時間が約０．５〜２秒程度のデータに設定して運用している場合が多い。

しかし、１つのフラグメント８０に格納するメディアデータ（ｍｄａｔ）を１つのＧＯＰ単位のデータとすると、データ配信や再生処理における遅延が発生し、リアルタイム再生に支障が発生する可能性がある。
例えば、ライブ中継画像を配信する場合、送信装置２０は、カメラから入力するライブ画像データの符号化処理を実行してメディアセグメント６０を順次生成する。メディアセグメント６０の各フラグメント８０に格納するメディアデータ（ｍｄａｔ）がＧＯＰ単位の符号化データである場合、送信装置３０は、ＧＯＰ単位の符号化データであるメディアデータ（ｍｄａｔ）を生成し、その後、生成したメディアデータ（ｍｄａｔ）のプレゼンテーションタイム等の属性情報を記述したメタデータ（ｍｏｏｆ）を生成することになる。

従って、このシーケンスで各データの生成を行うと、各ＧＯＰ単位の符号化データのデータ範囲が決定された後でないと、そのＧＯＰのメタデータ（ｍｏｏｆ）の生成ができない。
従って、メタデータ（ｍｏｏｆ）の生成は、メディアデータ（ｍｄａｔ）のデータ範囲が決定後に行うことになり、各メタデータ（ｍｏｏｆ）の生成処理は、１つのＧＯＰ単位の時間（０．５〜２秒）に相当する時間を待って行わざる得ないことになる。

メディアセグメント６０を構成するフラグメント８０に格納するメディアデータ（ｍｄａｔ）をＧＯＰ単位の符号化データとした場合のフラグメント生成シーケンスについて図４を参照して説明する。

なお、図４に示す例は、メディアセグメント６０に格納するメディアデータ（ｍｄａｔ）をＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマット（符号化形式）に従って格納する場合のシーケンス例である。
ＭＰ４ファイルフォーマットのデータ部は、基本格納単位としてのサンプル（ｓａｍｐｌｅ）に区分される。さらに各サンプル（ｓａｍｐｌｅ）は、１以上のＮＡＬユニットによって構成される。ＮＡＬユニットは、ＭＰＥＧ符号化データの例えばスライス単位の細分化データである。
図４（ａ）に示すように複数の１つのＧＯＰに対応する符号化データは複数のＮＡＬユニットによって構成される。

図４には、
上段に（ａ）ＧＯＰを構成するＮＡＬユニット
下段に（ｂ）フラグメント生成処理シーケンス
これらを示している。
（ｂ）フラグメント生成処理シーケンスの最下段には時間軸を示している。左から右に時間が経過し、送信装置２０は、この時間軸に従って、各処理を実行してフラグメントを生成する。
なお、送信装置は、生成したフラグメントを格納したメディアセグメントを生成し、その後、メディアセグメントを格納したＨＴＴＰパケットを生成し、さらにＨＴＴＰパケットを格納したＩＰパケットを生成した後、ＩＰパケットの送信を行う。

図４（ｂ）に示すフラグメント生成処理シーケンスについて説明する。
送信装置２０は、以下のシーケンスでＭＰ４ファイルフォーマットに従った符号化データを格納したフラグメントを生成する。
時間ｔ０〜ｔ１：ＧＯＰを構成する複数のＮＡＬユニットを格納したサンプル１（ｓａｍｐｌｅ１）を生成、
時間ｔ２〜ｔ３：ＧＯＰを構成する複数のＮＡＬユニットを格納したサンプル２（ｓａｍｐｌｅ２）を生成、
時間ｔ４〜ｔ５：ＧＯＰを構成する複数のＮＡＬユニットを格納したサンプル３（ｓａｍｐｌｅ３）を生成、
ここまでで、１ＧＯＰを構成する全てのＮＡＬユニットを格納したサンプルの生成が完了する。
これらのサンプル１〜３（ｓａｍｐｌｅ１〜３）がメディアセグメントのフラグメント内のメディアデータ（ｍｄａｔ）として設定されることになる。

時間ｔ６〜ｔ７：サンプル１〜３（ｓａｍｐｌｅ１〜３）に格納したＧＯＰ符号化データの属性情報であるメタデータ（ｍｏｏｆ）を生成する。
時間ｔ８〜ｔ９：サンプル１〜３（ｓａｍｐｌｅ１〜３）によって構成されるメディアデータ（ｍｄａｔ）と、サンプル１〜３（ｓａｍｐｌｅ１〜３）のメタデータ（ｍｏｏｆ）を組み合わせたフラグメントを生成する。

送信装置２０は、その後、上述した処理に従って生成したフラグメントを含むメディアセグメントを生成し、メディアセグメントをペイロードとして含むパケットを生成して受信装置３０に送信することになる。
送信装置２０は、フラグメントを生成する場合、フラグメントに格納するＧＯＰ単位のメディアデータ（ｍｄａｔ）の再生時間等を確認し、その再生時間に応じたプレゼンテータションタイム等、ＧＯＰデータ単位の属性情報を生成して、メタデータ（ｍｏｏｆ）に記録する必要がある。

現在、データ配信される画像データは主にハイビジョン対応の画像データであるが、今後、さらに高画質化が進み、例えば４Ｋ画像等、データ量の多いデータ配信が増加すると予想される。このような大容量のデータ配信に対応するためストリームのビットレートが大きくなる可能性がある。

高画質化によるデータ量の増大に従って各ＧＯＰ単位のデータ量も増大する。従って、図４を参照して説明したように１つのＧＯＰ単位のフラグメントを順次、生成して送信する構成とすると、送信側での処理間隔が長くなる。また、送信データの単位当たりデータ量も大きくなる。従って、十分な通信帯域が確保できない場合、ネットワーク送信における送信遅延の発生可能性が増加する。

また、受信装置側でのパケット受信間隔が長くなり、１パケットあたりのデータ受信量が増加し、受信装置側に要求されるデータバッファ量も増加する。また、パケットの受信エラーが発生した場合の再送処理を行なうと、遅延量が急激に大きくなり、リアルタイム再生が破たんする可能性が高くなる。

［３．送信データの細分化処理構成について］
上記の問題を解決するため、送信装置２０から受信装置３０に対する送信データを細分化し、１つの送信パケット、すなわち一単位あたりの送信データ量を削減した構成例について、以下説明する。

図４を参照したフラグメント生成シーケンスにおいては、フラグメントに設定するメディアデータ（ｍｄａｔ）を１ＧＯＰ単位のデータとし、この１ＧＯＰ単位のメディアデータ（ｍｄａｔ）に対応するメタデータ（ｍｏｏｆ）を生成する構成としていた。すなわち、各メタデータ（ｍｏｏｆ）を、１ＧＯＰ単位のメディアデータ（ｍｄａｔ）に対応したメタデータとしていた。

図４に示すシーケンスでは、メタデータ（ｍｏｏｆ）の生成タイミングは、１つのＧＯＰのデータ量に応じて決定されてしまう。従って１ＧＯＰに含まれるデータ量が多くなると、メタデータ（ｍｏｏｆ）の生成タイミングも遅れ、その結果、フラグメントの生成処理、メディアセグメントの生成処理、送信パケットの生成処理にも遅れが発生する。また、この結果１パケット当たりのデータ量が増加し、配信遅延の可能性を高めてしまうことになる。

このような事態を防止する構成として、フラグメント内のメディアデータ（ｍｄａｔ）を１ＧＯＰ単位のデータではなく、１ＧＯＰを細分化したデータに設定した構成例について、図５を参照して説明する

図５には、フラグメントに格納するメディアデータ（ｍｄａｔ）を１つのＧＯＰデータではなく、１つのＧＯＰデータを細分化したデータ、具体的には１つのＧＯＰの構成データである１つのＮＡＬユニットまたは複数のＮＡＬユニットとした例を示している。

図５（ａ）は、図４（ａ）と同様、ＧＯＰを構成するＮＡＬユニットを示している。
図５（ｂ１）〜（ｂ３）は、この１つのＧＯＰの構成データであるＮＡＬユニットをメディアデータ（ｍｄａｔ）として分散させて格納した複数のメディアセグメントである。
図５（ｂ１）〜（ｂ３）に示すようにＧＯＰデータを細分化データである１以上のＮＡＬユニットから構成されるメディアデータ（ｍｄａｔ）を格納したメディアセグメントを、以下、サブＧＯＰメディアセグメントと呼ぶ。

図５には、１つのＧＯＰデータを３つのサブＧＯＰメディアセグメントに格納した例を示しているが、１つのＧＯＰデータを格納するためのサブＧＯＰメディアセグメントの数は、２以上の任意数に設定可能である。
また、図５（ｂ１）〜（ｂ３）のサブＧＯＰメディアセグメントは、いずれもメディアデータ（ｍｄａｔ）を複数のＮＡＬユニットに設定した例としているが、メディアデータ（ｍｄａｔ）を１つのＮＡＬユニットのみの設定としてもよい。

送信装置２０は、図５（ｂ１）〜（ｂ３）に示すサブＧＯＰメディアセグメントを生成し、生成したサブＧＯＰメディアセグメントの各々を、それぞれ個別のＨＴＴＰパケットのペイロードに設定してネットワークや放送波を介して送信する。

図５（ｂ１）〜（ｂ３）のサブＧＯＰメディアセグメントに格納するメタデータ（ｍｏｏｆ）は、個々のサブＧＯＰメディアセグメントに格納するメディアデータ（ｍｄａｔ）に対応した属性情報からなるメタデータとする。
このような設定とすることで、ネットワークや放送波を介して送信される１つのパケットのデータ量が小さくなり、送信装置側の１つのパケット生成処理に要する時間が短縮される。またパケット遅延の可能性も低減し、パケットロス等の際の再送処理遅延も小さくなる。結果として、受信装置３０におけるエラーのないリアルタイム再生が実現される。

サブＧＯＰメディアセグメントにＨＴＴＰヘッダを設定したＨＴＴＰパケットの構成例について、図６を参照して説明する。
図６には２つのＨＴＴＰパケット構成例を示している。
図６の（ａ）と（ｂ）に示すパケットの差異は、ランダムアクセス情報等を格納する［ｓｉｄｘ］を有するか否かである。
ｓｉｄｘは、先に図３を参照して説明したように、メディアセグメントに格納された複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）の境界情報や、メディアセグメントに格納された符号化コンテンツであるメディアデータ（ｍｄａｔ）のランダムアクセスポイント等を示すアクセス情報である。ＤＡＳＨではアクセス情報はＳＡＰ（Ｓｔｒｅａｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ）と呼ばれる。ＳＡＰは、例えばストリームを復号するために必要なすべての状態をリセットすることができる画像シーケンスの先頭ピクチャの先頭バイト位置を示す。具体的には、例えばＭＰＥＧデータのＩピクチャ位置に相当する。

図６（ｂ）に示すＨＴＴＰパケットは、ｓｉｄｘを含まないパケットである。図６（ｂ）に示すＨＴＴＰパケットは、このパケットに格納されたメディアデータ（ｍｄａｔ）にアクセスポイントとなるピクチャデータを含まない。
パケット格納メディアデータ（ｍｄａｔ）にアクセスポイントとなるデータを含まない場合、アクセスポイントを示すデータも不要となる。従って図６（ｂ）に示すＨＴＴＰパケットにはｓｉｄｘが設定されていない。
一方、アクセスポイントとなるデータを含むメディアデータ（ｍｄａｔ）を格納したサブＧＯＰメディアセグメントを有するパケットには、図６（ａ）に示すようにｓｉｄｘが設定される。

図５〜図６を参照して説明したように、本実施例では、１つのＧＯＰ構成データを複数のパケットに分割して送信する。
受信装置３０は、これらの複数のパケットを順次、受信し、各パケットに分割して格納されたＧＯＰ構成データを取得する。ＧＯＰ単位の復号処理を行なう場合は、複数のパケットに格納されたＧＯＰ構成データを全て集めて、ＧＯＰの構成データ（ＮＡＬユニット）を正しい順序に並べてＧＯＰデータを再構成することが必要となる。
以下、ＧＯＰ再構成処理に適用する情報等、受信装置側における処理をスムーズに実行させるための付加情報の設定例について説明する。

［４．ＨＴＴＰヘッダに付加情報を記録した実施例について］
まず、ＧＯＰ再構成処理に適用する情報等、受信装置側における処理をスムーズに実行させるための付加情報をＨＴＴＰパケットのＨＴＴＰヘッダに記録した実施例について説明する。

図７、図８を参照してＨＴＴＰヘッダの記録情報について説明する。
図７には、先に図５を参照して説明したと同様、１つのＧＯＰデータを３つのサブＧＯＰメディアセグメントに分割格納したＨＴＴＰパケットの構成例を示している。

これら３つのＨＴＴＰパケットのＨＴＴＰヘッダに、図７に示すように、
（１）セグメント識別子（Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ）
（２）ＧＯＰ内位識別情報（Ｘ−（Ｓｔａｒｔ／Ｍｉｄｄｌｅ／Ｅｎｄ）ｏｆＧＯＰ）
これらの２つの識別情報を記録する。

（１）セグメント識別子は、そのＨＴＴＰパケットに格納されたセグメントのコンテンツ位置情報と、セグメントの種類とパケットに格納されたメディアデータ（ｍｄａｔ）の属するＧＯＰの識別情報を含むデータである。なお、具体的にはＧＯＰデータの位置情報（ＵＲＬ等のアクセス情報）を記録すればよい。

パケットを受信する受信装置３０は、同一のセグメント識別子（Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ）が記録されたＨＴＴＰパケットは同じＧＯＰに属するメディアデータ（ｍｄａｔ）を格納したＨＴＴＰパケットであると判定することができる。

（２）ＧＯＰ内位識別情報は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータである。
ＧＯＰ内位識別情報＝Ｘ−ＳｔａｒｔｏｆＧＯＰであるパケットは、ＧＯＰデータの先頭領域のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したパケットである。
ＧＯＰ内位識別情報＝Ｘ−ＭｉｄｄｌｅｏｆＧＯＰであるパケットは、ＧＯＰデータの中間領域のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したパケットである。
ＧＯＰ内位識別情報＝Ｘ−ＥｎｄｏｆＧＯＰであるパケットは、ＧＯＰデータの末尾領域のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したパケットである。

なお、１つのＧＯＰデータが、４つ以上のサブＧＯＰメディアセグメントに分割された場合、ＧＯＰ内位識別情報＝Ｘ−ＭｉｄｄｌｅｏｆＧＯＰを設定した複数のパケットが生成されることになる。これらのパケットに格納されるメディアデータ（ｍｄａｔ）のＧＯＰデータ内配列は、ＨＴＴＰヘッダ以外のパケットヘッダ情報によって判別できる。
例えばＨＴＴＰパケットを格納するＬＣＴパケットのＬＣＴヘッダに記録されるパケットシーケンス番号を参照することで判別可能である。なお、具体的な送信パケットの構成、およびＬＣＴヘッダ構成については、後述する。

従って、例えばＨＴＴＰパケットをＬＣＴパケットに格納して送信する構成では、ＨＴＴＰヘッダに設定するＧＯＰ内位置識別情報は、ＧＯＰ位置が先頭領域のデータを格納したパケットのみを識別する設定としてもよい。すなわち、ＧＯＰ内位識別情報＝Ｘ−ＳｔａｒｔｏｆＧＯＰのみを記録し、この後に続くＧＯＰデータは、ＬＣＴヘッダのシーケンス番号を参照して配列する構成としてもよい。

図８に、メディアセグメントを格納したＨＴＴＰパケットのＨＴＴＰヘッダのデータ構成例を示す。
図８に示すようにＨＴＴＰヘッダには、例えば以下のＨＴＴＰヘッダ情報が記録される。
「・・・
ＨＴＴＰ／１．１ ２０６ Ｐａｒｔｉａｌ Ｃｏｎｔｅｎｔ
Ｄａｔｅ： Ｆｒｉ， ０４ Ｏｃｔ ２０１３ １１：１４：２０ ＧＭＴ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｍｐ４
Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ： ｈｔｔｐ：／／ａ．ｃｏｍ／ｘ．ｍｐ４
Ｘ−ＳｔａｒｔＯｆＧＯＰ
・・・」

上記のＨＴＴＰヘッダ情報中、
セグメント識別子は、
「Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ：ｈｔｔｐ：／／ａ．ｃｏｍ／ｘ．ｍｐ４」
である。
このセグメント識別子は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）の属するＧＯＰの識別情報を含むものとなる。具体的にはそのＧＯＰデータの位置情報（アクセス情報）である。
同一のセグメント識別子（Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ）が記録されたＨＴＴＰパケットは同じＧＯＰに属するメディアデータ（ｍｄａｔ）を格納したＨＴＴＰパケットであると判定することができる。

また、上記ＨＴＴＰヘッダ情報中、
ＧＯＰ内位識別情報は、
「Ｘ−ＳｔａｒｔＯｆＧＯＰ」
である。このＧＯＰ内位識別情報は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータである。
ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰの、
先頭領域の場合は、「Ｘ−ＳｔａｒｔＯｆＧＯＰ」、
中間領域の場合は、「Ｘ−ＭｉｄｄｌｅＯｆＧＯＰ」、
末尾領域の場合は、「Ｘ−ＥｎｄＯｆＧＯＰ」、
ＨＴＴＰヘッダにはこれらのいずれかのデータがＧＯＰ内位識別情報として記録される。

次に、初期化セグメントを格納するＨＴＴＰパケットのＨＴＴＰヘッダの記録情報について図９を参照して説明する。
初期化セグメントを格納するＨＴＴＰパケットのＨＴＴＰヘッダには、ＨＴＴＰパケットが初期化セグメントを格納したパケットであることを示すセグメント識別情報を記録する。

図９に、初期化セグメントを格納したＨＴＴＰパケットのＨＴＴＰヘッダのデータ構成例を示す。
図９に示すようにＨＴＴＰヘッダには、例えば以下のＨＴＴＰヘッダ情報が記録される。
「・・・
ＨＴＴＰ／１．１ ２０６ Ｐａｒｔｉａｌ Ｃｏｎｔｅｎｔ
Ｄａｔｅ： Ｆｒｉ， ０４ Ｏｃｔ ２０１３ １１：１４：２０ ＧＭＴ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ： ａｐｐｌｉｃａｔｉｏｎ／ｍｐ４
Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ：ｈｔｔｐ：／／ａ．ｃｏｍ／ｘ−ｉｎｉｔ．ｍｐ４」
Ｘ−ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ
・・・」

上記のＨＴＴＰヘッダ情報中、
セグメント識別子は、
「Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ：ｈｔｔｐ：／／ａ．ｃｏｍ／ｘ−ｉｎｉｔ．ｍｐ４」
である。
このセグメント識別子は、初期化セグメントのＵＲＬ等のアクセス情報を記録すればよい。

上記のＨＴＴＰヘッダ情報中、
セグメント識別情報は、
「Ｘ−ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ」
である。
このセグメント識別情報は、ＨＴＴＰパケットに格納されたセグメントが、初期化セグメントであることを示す情報である。
初期化セグメントを格納したＨＴＴＰヘッダにはこのセグメント識別情報が記録される。

［５．パケットの構成について］
次に、送信装置から受信装置に向けて送信されるパケットの構成例について説明する。
図１０には以下の２つのＩＰパケットの構成例を示している。
（１）初期化セグメント格納ＩＰパケット
（２）メディアセグメント格納ＩＰパケット

（１）初期化セグメント格納ＩＰパケットは、以下の構成を有する。
ＩＰヘッダ
ＵＤＰヘッダ
ＬＣＴヘッダ
ＨＴＴＰヘッダ
初期化セグメント構成データ［ｄａｓｈ］
初期化セグメント構成データ［ｍｏｏｖ］

ＩＰヘッダ、ＵＤＰヘッダ、ＬＣＴヘッダ、ＨＴＴＰヘッダは、それぞれＩＰプロトコル、ＵＤＰプロトコル、ＦＬＵＴＥプロトコル、ＨＴＴＰプロトコルの各通信プロトコルに従って設定されるヘッダ情報である。

一方、（２）メディアセグメント格納ＩＰパケットは、以下の構成を有する。
ＩＰヘッダ
ＵＤＰヘッダ
ＬＣＴヘッダ
ＨＴＴＰヘッダ
メディアセグメント構成データ［ｍｓｄｈ］
メディアセグメント構成データ［ｓｉｄｘ］
メディアセグメント構成データ［ｍｏｏｆ］
メディアセグメント構成データ［ｍｄａｔ］

ＩＰヘッダ、ＵＤＰヘッダ、ＬＣＴヘッダ、ＨＴＴＰヘッダは、それぞれＩＰプロトコル、ＵＤＰプロトコル、ＦＬＵＴＥプロトコル、ＨＴＴＰプロトコルの各通信プロトコルに従って設定されるヘッダ情報である。
なお、前述したようにメディアセグメント構成データ［ｓｉｄｘ］は、ランダムアクセスに適用可能なメディアデータ（ｍｄａｔ）を有するパケットには設定されるが、それ以外のパケットには設定不要である。

送信装置２０は、図１０に示すＩＰパケットを生成して受信装置３０に向けて送信する。
受信装置３０は、受信装置２０から受信する図１０に示す各パケットを受信し、各ヘッダ情報を解析して、セグメントを取り出し、セグメント格納データに従って、初期設定やコンテンツ再生を実行する。

［６．送信装置と受信装置の構成と処理について］
次に、図１１以下を参照して送信装置と受信装置の構成と処理について説明する。
まず、図１１を参照して、送信装置２０と受信装置３０の構成とプロトコルスタックについて説明する。

図１０を参照して説明したＩＰパケットを生成して送信する送信装置２０は、図１１に示すようにデータ処理部２１と通信部２２を有する。
データ処理部２１は、送信パケットの生成処理を実行する。
具体的には、例えば前述したように符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータ（ｍｄａｔ）と、メディアデータ対応のメタデータ（ｍｏｏｆ）を格納したサブＧＯＰメディアセグメントをパケット格納データとして生成する。さらに、サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子等のパケット付加情報を生成してＨＴＴＰヘッダに記録したパケットを生成する。

通信部２２は、データ処理部２１の生成したパケットを送信する。
通信部２２は、データ処理部２１の生成したパケットを、放送波、あるいはインターネット等のネットワークを介してブロードキャスト配信、またはマルチキャスト配信する。

データ処理部２１と通信部２２は、以下のレイヤからなるプロトコルスタックに従ってパケット生成処理を実行し、生成したパケットを送信する。以下、送信装置２０のプロトコルスタックのレイヤ構成について説明する。送信装置２０のプロトコルスタックは、上位レイヤから下位レイヤまで、以下に示すレイヤ構成を有する。
（１）ＤＡＳＨ Ｓｅｒｖｅｒ：ＤＡＳＨ規格に従ったセグメント生成等の処理を実行するアプリケーションレイヤ
（２）Ｖｉｄｅｏ／Ａｕｄｉｏ／Ｓｕｂｔｉｔｌｅ ｅｔｃ：送信対象コンテンツの生成、取得を実行するアプリケーションレイヤ
（３）ＦｒａｇｍｅｎｔｅｄＭＰ４：ＭＰ４ファイルフォーマットに従った符号化データを生成しセグメントを生成するアプリケーションレイヤ
（４）ＨＴＴＰ：ＨＴＴＰプロトコルに従ってＨＴＴＰヘッダを有するＨＴＴＰパケットを生成するレイヤ
（５）ＦＬＵＴＥ／ＡＬＣ（ＬＣＴ）：ＦＬＵＴＥプロトコルに従ってＬＣＴヘッダを有するＦＬＵＴＥパケットを生成するレイヤ
（６）ＵＤＰ：ＵＤＰプロトコルに従ってＵＤＰヘッダを有するＵＤＰパケットを生成するレイヤ
（７）ＩＰ：ＩＰプロトコルに従ってＩＰヘッダを有するＩＰパケットを生成するレイヤ
（８）ＰＨＹ：ＩＰパケット、またはＩＰパケットを格納したＭＡＣフレームを生成して送信する通信部等から構成される物理レイヤ

また、図１０を参照して説明したＩＰパケットを受信する受信装置３０は、図１１に示すようにデータ処理部３１と通信部３２を有する。
通信部３２は、送信装置２０の送信するパケットを受信し、データ処理部３１は通信部３１の受信したパケットを入力して、データ処理を行なう。

データ処理部３１と通信部３２は、以下のレイヤからなるプロトコルスタックに従ってパケットの受信、解析を実行する。受信装置３０のプロトコルスタックは、上位レイヤから下位レイヤまで、以下に示すレイヤ構成を有する。
（１）ＤＡＳＨ Ｃｌｉｅｎｔ：ＤＡＳＨ規格に従ったセグメントの解析等の処理を実行するアプリケーションレイヤ
（２）Ｖｉｄｅｏ／Ａｕｄｉｏ／Ｓｕｂｔｉｔｌｅ ｅｔｃ：受信コンテンツの取得、再生処理等を実行するアプリケーションレイヤ
（３）ＦｒａｇｍｅｎｔｅｄＭＰ４：ＭＰ４ファイルフォーマットに従った符号化データの復号処理等を実行するアプリケーションレイヤ
（４）ＨＴＴＰ：ＨＴＴＰプロトコルに従ってＨＴＴＰヘッダを有するＨＴＴＰパケットを解析するレイヤ
（５）ＦＬＵＴＥ／ＡＬＣ（ＬＣＴ）：ＦＬＵＴＥプロトコルに従ってＬＣＴヘッダを有するＦＬＵＴＥパケットを解析するレイヤ
（６）ＵＤＰ：ＵＤＰプロトコルに従ってＵＤＰヘッダを有するＵＤＰパケットを解析するレイヤ
（７）ＩＰ：ＩＰプロトコルに従ってＩＰヘッダを有するＩＰパケットを解析するレイヤ
（８）ＰＨＹ：ＩＰパケット、またはＩＰパケットを格納したＭＡＣフレームを受信する通信部等から構成される物理レイヤ

なお、送信装置２０は、前述したようにＩＰパケットをブロードキャスト、あるいはマルチキャスト送信する際、ネットワークを介した送信、あるいは放送波を介した送信のいずれか、または、これらの双方の通信経路を利用して並列送信する処理を行なう。

受信装置３０は、放送波と、インターネット等のネットワークのいずれかの通信経路、または両通信経路を介したパケット受信処理を行なう。
インターネット等のネットワークを介した送受信パケットの生成および解析は、図１１に示すＦＬＵＴＥ／ＡＬＣ（ＬＣＴ）レイヤとＵＤＰレイヤを、ＴＣＰレイヤに置き換えて行なうことが可能である。

放送波を介して受信するＩＰパケットと、インターネット等のネットワークを介して受信するＩＰパケットを適宜、切り替えて処理を行なう受信装置３０のプロトコルスタックの例について、図１２を参照して説明する。

図１２に示す受信装置３０のプロトコルスタックは、以下の２つの通信系に対応したプロトコルスタックのレイヤ構成を示している。
（１）放送系
（２）ネットワーク通信系

（１）放送系は、図１１を参照して説明したレイヤ構成となっている。
（２）ネットワーク通信系は、放送系レイヤのＦＬＵＴＥ／ＡＬＣ（ＬＣＴ）レイヤと、ＵＤＰレイヤをＴＣＰレイヤに置き換えた構成である。
ＴＣＰレイヤは、ＴＣＰヘッダを有するＴＣＰパケットの解析を実行する。
シグナリング（Ｓｉｇｎａｌｉｎｇ）レイヤは、各通信系の切り替え制御を行うためのレイヤである。

受信装置３０は、放送系とネットワーク通信系の各レイヤを、適宜切り替えて利用することで、放送波を介して受信するパケットと、インターネット等のネットワークを介して受信するパケットを選択的に利用してパケット格納コンテンツを取得して再生処理を実行することができる。

例えば、ネットワークからのパケット受信に遅延が発生した場合、放送系に切り替えて同一コンテンツに対応するパケットを、放送波を介して受信し、コンテンツ再生を継続することができる。
ネットワーク通信系、放送系のいずれの通信系を介した配信パケットにも、前述したセグメント識別子やＧＯＰ内位置識別子が記録されており、これらの識別情報を参照して、ＧＯＰデータの再構築が可能となり、エラーのない復号処理と、コンテンツ再生が実現される。

［７．送信装置と受信装置の処理シーケンスについて］
次に、図１３、図１４に示すフローチャートを参照して送信装置と受信装置の実行する処理シーケンスについて説明する。

まず、図１３に示すフローチャートを参照して送信装置２０の実行する処理シーケンスについて説明する。
図１３に示すフローは、メディアセグメントを格納したＩＰパケットの生成と送信処理のシーケンスを説明するフローである。
この処理は、送信装置２０のデータ処理部において実行する。データ処理部は、プログラム実行機能を有するＣＰＵを備え、例えば記憶部に格納されたプログラムに従って、図１３に示すフローに従った処理を実行する。
以下、各ステップの処理について、順次、説明する。

（ステップＳ１０１）
まず、送信装置のデータ処理部は、送信対象となるコンテンツの符号化処理を実行する。例えばＭＰ４ファイルフォーマットに従った符号化処理を実行する。

（ステップＳ１０２）
次に、送信装置は、メディアセグメントのフラグメントに格納するメディアデータ（ｍｄａｔ）を生成する。この処理は、先に図５他を参照して説明したサブＧＯＰメディアセグメントに格納するメディアデータ（ｍｄａｔ）を生成する処理である。ＭＰ４符号化データであるＧＯＰデータの一部、すなわちＧＯＰを構成する１つ以上のＮＡＬユニットを構成データとするメディアデータ（ｍｄａｔ）を生成する。

（ステップＳ１０３）
次に、送信装置は、ステップＳ１０２で生成したメディアデータ（ｍｄａｔ）に対応する属性情報であるメタデータ（ｍｏｏｆ）を生成する。

（ステップＳ１０４）
次に、送信装置は、ステップＳ１０２で生成したメディアデータ（ｍｄａｔ）と、ステップＳ１０３で生成したメタデータ（ｍｏｏｆ）を格納したフラグメントを生成する。

（ステップＳ１０５）
次に、送信装置は、ステップＳ１０４で生成したフラグメントを格納したメディアセグメントを生成する。これは、先に図５他を参照して説明したサブＧＯＰメディアセグメントである。すなわち、ＧＯＰデータ全体ではなく、ＧＯＰ構成データの一部のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したメディアセグメントである。

（ステップＳ１０６〜Ｓ１０７）
次に、送信装置は、メディアセグメントに格納したメディアデータの属性情報である、
セグメント識別情報、
ＧＯＰ内位置識別情報、
これらの識別情報を記録したＨＴＴＰヘッダを設定したＨＴＴＰパケットを生成する。
これらの識別情報は、先に図７、図８を参照して説明した識別情報である。

（ステップＳ１０８〜Ｓ１０９）
次に、送信装置は、ＨＴＴＰパケットに対して、ＬＣＴヘッダ、ＵＤＰヘッダ、ＩＰヘッダを設定してＩＰパケットを生成して送信する。送信処理は、インターネット等の通信ネットワークまたは放送波のいずれか、または両通信路を介して実行する。

図１３に示すフローは、メディアセグメントを格納したパケットの生成と送信処理シーケンスを説明するフローである。初期化セグメントを格納したパケット生成に際しては、初期化セグメントの構成データの生成の後、ＨＴＴＰヘッダに初期化セグメントであることを示すセグメント識別情報を記録する処理を行なうことになる。その他の処理は、ほぼ図１３に示すフローに記載した手順に従って行われる。

次に、図１４に示すフローチャートを参照して受信装置において実行するパケット受信からコンテンツ再生に至るまでの処理シーケンスについて説明する。
この処理は、受信装置３０のデータ処理部において実行する。データ処理部は、プログラム実行機能を有するＣＰＵを備え、例えば記憶部に格納されたプログラムに従って、図１４に示すフローに従った処理を実行する。
以下、各ステップの処理について、順次、説明する。

（ステップＳ２０１）
まず、ステップＳ２０１において、受信装置は、ユーザによる再生コンテンツの指定情報を入力する。例えば予め送信装置から受信している番組表等のコンテンツ一覧リストを表示部に表示し、この表示情報に対するユーザ入力情報に基づいて再生コンテンツを決定する。

（ステップＳ２０２）
次に受信装置は、再生対象として選択された選択コンテンツに対応する初期化セグメントを含むパケットを受信して初期化セグメントを取得する。
なお、先に図９を参照して説明したように初期化セグメントを格納したＨＴＴＰパケットのＨＴＴＰヘッダには、セグメント識別情報が記録されており、この識別情報を参照することで初期化セグメントを格納したＨＴＴＰパケットであることが確認できる。

（ステップＳ２０３）
受信装置は、受信した初期化セグメントの格納データに従って受信装置の初期化処理を実行する。具体的には初期化セグメントに格納されたコーデック設定パラメータ等を取得し、取得パラメータに従ってコーデックの設定等を行う。

（ステップＳ２０４）
次に、受信装置は、ステップＳ２０１で選択した選択コンテンツに対応するメディアセグメントを格納したパケットを順次、受信する。先に図５他を参照して説明したように、各パケットは１つのＧＯＰデータより小さい単位のデータを格納したサブＧＯＰメディアセグメントをペイロードとして格納したパケットであり、受信装置は、このサブＧＯＰメディアセグメント格納パケットを順次、受信する。

（ステップＳ２０５）
次に、受信装置は、サブＧＯＰメディアセグメントＨＴＴＰパケットのＨＴＴＰヘッダから、
セグメント識別子、
ＧＯＰ内位置識別情報、
これらの各識別情報を取得する。
先に、図７、図８を参照して説明したように、セグメント識別子は、そのＨＴＴＰパケットに格納されたセグメントのコンテンツ位置情報と、セグメントの種類とパケットに格納されたメディアデータ（ｍｄａｔ）の属するＧＯＰの識別情報を含むデータである。
ＧＯＰ内位識別情報は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータである。例えば、ＧＯＰ内位識別情報＝Ｘ−ＳｔａｒｔｏｆＧＯＰであるパケットは、ＧＯＰデータの先頭領域のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したパケットである。

（ステップＳ２０６）
次に、受信装置は、ＨＴＴＰヘッダから取得した識別情報に従って、複数のサブＧＯＰメディアセグメントＨＴＴＰパケットに格納されたＮＡＬユニットを再配列し、ＧＯＰ単位データ再構築する。

（ステップＳ２０７〜Ｓ２０８）
次に、受信装置は、再構築したＧＯＰデータに対する復号処理を実行し、復号データの再生処理を行なう。

（ステップＳ２０９）
次に、受信装置は、データ再生処理が終了したか否かを判定し、終了していない場合は、ステップＳ２０４に戻り、ステップＳ２０４以下の処理を繰り返し実行する。
ステップＳ２０９において再生処理終了と判定した場合は処理を終了する。

なお、例えばランダムアクセス再生等、特定の再生位置の画像のみを再生する場合には、サブＧＯＰメディアセグメントにランダムアクセスポイント情報であるｓｉｄｘデータの設定されたセグメントのみを処理対象として処理を実行してもよい。
この場合、ＧＯＰ全体データを再配列する処理を行なうことなくランダムアクセスポイントのデータのみを選択して再生することが可能である。

［８．拡張ヘッダに付加情報を記録した実施例について］
上述した実施例では、ＧＯＰ再構成処理に適用する情報等、受信装置側における処理をスムーズに実行させるための付加情報をＨＴＴＰパケットに設定した実施例について説明した。
しかし、付加情報の記録先はＨＴＴＰヘッダに限らず、様々な記録先とすることが可能である。
以下、拡張ヘッダに付加情報を記録した実施例について説明する。

図１５を参照して、拡張ヘッダに付加情報を記録した実施例について説明する。
図１５に示す例は、ＨＴＴＰヘッダとサブＧＯＰメディアセグメントの間に新たな拡張ヘッダを挿入し、この拡張ヘッダに付加情報を記録した例である。

図１５には、
（１）初期化セグメントＨＴＴＰパケット、
（２）サブＧＯＰメディアセグメントＨＴＴＰパケット、
これらの２種類のＨＴＴＰパケットの例を示している。
各パケットのＨＴＴＰヘッダの次に拡張ヘッダを設定している。
この拡張ヘッダに、
（ａ）セグメント識別情報、
（ｂ）ＧＯＰ内位置識別情報を格納する。

例えば（ａ）セグメント識別情報は、８ビットデータとし、初期化セグメントの場合は１を設定し、その他のセグメントの場合は０を設定する。
なお、メディアセグメントの場合、ＨＴＴＰヘッダに記録されるコンテンツ位置情報（ＣｏｎｔｅｎｔＬｏｃａｔｉｏｎ）をＧＯＰ単位データの位置情報に設定すれば、このコンテンツ位置情報を参照することで各ＧＯＰデータの区別が可能となる。

（ｂ）ＧＯＰ内位置識別情報は、８ビットデータとして、例えば、ビット値を以下の設定とする。
ＧＯＰの先頭位置のデータ（ＳｔａｒｔｏｆＧＯＰ）＝１
ＧＯＰの中間位置のデータ（ＭｉｄｄｌｅｏｆＧＯＰ）＝２
ＧＯＰの末尾位置のデータ（ＥｎｄｏｆＧＯＰ）＝３

送信装置は、このような拡張ヘッダを設定して受信装置に送信する。一方、受信装置は、この拡張ヘッダのセグメント識別情報を参照して、パケットに格納されたセグメントが初期化セグメントであるか、サブＧＯＰメディアセグメントであるかを判別する。さらに、受信装置は、パケットがサブＧＯＰメディアセグメントパケットであると識別した場合、拡張ヘッダのＧＯＰ内位置識別情報を参照することで、サブＧＯＰメディアセグメントに格納されたメディアデータ（ｍｄａｔ）がＧＯＰ内のとの位置に対応するデータであるかを識別することが可能となる。

［９．ＬＣＴヘッダに付加情報を記録した実施例について］
前述したように、マルチキャストやブロードキャスト（ＭＣ／ＢＣ）型のストリーミングに適用可能なトランスポートプロトコルには、例えばＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）やＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）がある。

ＦＬＵＴＥプロトコルに従って設定されるパケットには、ＦＬＵＴＥプロトコルに従ったヘッダ情報であるＬＣＴヘッダが設定される。
すなわち、先に図１０を参照して説明したＩＰパケット内のＬＣＴヘッダである。
以下、このＬＣＴヘッダに、ＧＯＰ再構成処理に適用する情報等、受信装置側における処理をスムーズに実行させるための付加情報を記録した実施例について説明する。

ＦＬＵＴＥプロトコルに従って設定されるＬＣＴヘッダの構成例を図１６に示す。
ＬＣＴヘッダに設定される主なデータフィールドには、例えば以下のフィールドがある。
ＣＣＩ（Ｃｏｎｇｅｓｔｉｏｎ Ｃｏｎｔｒｏｌ Ｉｎｆｏｒｍａｔｉｏｎ）：各フィールドの長さや輻輳制御情報等を記録するフィールドである。
ＴＳＩ（Ｔｒａｎｓｐｏｒｔ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ）：パケット転送のセッション情報を記録するフィールドである。
ＴＯＩ（Ｔｒａｎｓｐｏｒｔ Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ）：パケット転送のシーケンス等を記録するフィールドである。
ヘッダ拡張部（Ｈｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎｓ）：様々な拡張データを記録することができるフィールドである。

先に、図７を参照して説明したように、ＧＯＰ内位置情報の代用として、上記のＴＯＩを参照して、データ送信順を確認することが可能である。
前述したように、例えばＨＴＴＰヘッダ等に記録する付加情報であるＧＯＰ内位置情報について、先頭位置を示すＸ−ＳｔａｒｔｏｆＧＯＰのみを記録し、その他のＧＯＰ内データの配列順は、ＬＣＴヘッダ内のＴＯＩを参照してパケットシーケンスを取得し、パケットシーケンスに従ってＧＯＰ内のＮＡＬユニットを正しい順に配列する構成としてもよい。

図１６に示すように、ＬＣＴヘッダ内には様々なデータを記録できるヘッダ拡張部（Ｈｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎｓ）が設定される。このヘッダ拡張部にＧＯＰ再構成処理に適用する情報等、受信装置側における処理をスムーズに実行させるための付加情報を記録することが可能である。

ＬＣＴヘッダのヘッダ拡張部に対するデータ記録構成について、図１７を参照して説明する。
ＬＣＴヘッダのヘッダ拡張部に、データを記録する場合のフォーマットには２つの種類がある。
図１７（１）は、記録情報の長さが自由に設定可能なフォーマットである。
図１７（２）は、記録情報の長さが固定されたフォーマットである。

ＨＥＴ（Ｈｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎ Ｔｙｐｅ）には、拡張ヘッダの種類を示す拡張ヘッダ識別情報（数値）を記録する。図１７（１）のフォーマットは１２７までの値が利用可能であり、図１７（２）のフォーマットは１２８以上に設定することが規定されている。
ＨＥＴ（Ｈｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎ Ｌｅｎｇｔｈ）には、拡張ヘッダの長さを記録する。
ＨＥＣ（Ｎｅａｄｅｒ Ｅｘｔｅｎｓｉｏｎ Ｃｏｎｔｅｎｔ）は、拡張ヘッダコンテンツを記録するフィールドであり、任意の拡張情報を記録可能なフィールドである。

図１７（２）に示す記録情報の長さが固定されたフォーマットを利用して、ＧＯＰ再構成処理に適用する情報等、受信装置側における処理をスムーズに実行させるための付加情報を記録する場合の記録データの構成例を図１８に示す。

図１８に示すように、
（ａ）拡張ヘッダ識別情報（ＨＥＴ）は、８ビットデータとして、新たな情報の識別値として、例えば［２００］を記録する。
さらに、拡張情報記録部（ＨＥＣ）に、
（ｂ）セグメント識別情報、
（ｃ）ＧＯＰ内位置識別情報、
これらの各識別情報を記録する。

例えば（ｂ）セグメント識別情報は、８ビットデータとし、初期化セグメントの場合は１を設定し、その他のセグメントの場合は０を設定する。
なお、メディアセグメントの場合、ＨＴＴＰヘッダに記録されるコンテンツ位置情報（ＣｏｎｔｅｎｔＬｏｃａｔｉｏｎ）をＧＯＰ単位データの位置情報に設定すれば、このコンテンツ位置情報を参照することで各ＧＯＰデータの区別が可能となる。

（ｃ）ＧＯＰ内位置識別情報は、８ビットデータとして、例えば、ビット値を以下の設定とする。
ＧＯＰの先頭位置のデータ（ＳｔａｒｔｏｆＧＯＰ）＝１
ＧＯＰの中間位置のデータ（ＭｉｄｄｌｅｏｆＧＯＰ）＝２
ＧＯＰの末尾位置のデータ（ＥｎｄｏｆＧＯＰ）＝３

送信装置は、このような拡張ヘッダ情報を含むＬＣＴヘッダを設定して受信装置に送信する。一方、受信装置は、このＬＣＴヘッダ内の拡張ヘッダ情報のセグメント識別情報を参照して、パケットに格納されたセグメントが初期化セグメントであるか、サブＧＯＰメディアセグメントであるかを判別する。さらに、受信装置は、パケットがサブＧＯＰメディアセグメントパケットであると識別した場合、ＬＣＴヘッダの拡張ヘッダ情報に記録されたＧＯＰ内位置識別情報を参照することで、サブＧＯＰメディアセグメントに格納されたメディアデータ（ｍｄａｔ）がＧＯＰ内のどの位置に対応するデータであるかを識別することが可能となる。

［１０．ＨＥＶＣ符号化データに対する適用例について］
上述した実施例では、ＭＰＥＧ符号化方式に従ったＭＰ４符号化データに対する処理例について説明したが、本開示の処理は、その他の符号化データに足しても適用可能である。例えばＨＥＶＣ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）に従った符号化データに適用することが可能である。

ＨＥＶＣ符号化データの構成について、図１９を参照して説明する。
図１９に示すように、ＨＥＶＣ符号化処理によって生成される１つのＨＥＶＣストリームは、複数のシーケンス（ＣＶＳ：Ｃｏｄｅｄ Ｖｉｄｅｏ Ｓｅｑｕｅｎｃｅ）と、Ｅｎｄ ｏｆ ｓｅｑｕｅｎｃｅ ＮＡＬ ｕｎｉｔ（ＥｏＢ）を有する。

ＨＥＶＣストリームの構成要素であるＣＶＳは、複数のＧＯＰと、Ｅｎｄ ｏｆ ｓｅｑｕｅｎｃｅ ＮＡＬ ｕｎｉｔ（ＥｏＳ）から構成される。
１つのＧＯＰは、ランダムアクセスポイントとなるＩＲＡＰ（Ｉｎｔｒａ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ）アクセスユニットを先頭データとし、複数のＬＰ（Ｌｅａｄｉｎｇ Ｐｉｃｔｕｒｅ）アクセスユニットと、ＴＰ（Ｔｒａｉｌｉｎｇ Ｐｉｃｔｕｒｅ）アクセスユニットを有する。

ＬＰアクセスユニットと、ＴＰアクセスユニットは、何らかの参照ピクチャを参照して復号可能なアクセスユニットである。
ただし、ＩＲＡＰアクセスユニットから復号を開始した場合には、ＴＰＡＵについても正常な復号、再生が可能である。

アクセスユニット（ＡＵ）は、複数のＮＡＬユニット（Ｎｅｔｗｏｒｋ Ａｂｓｔｒａｃｔｉｏｎ Ｌａｙｅｒ Ｕｎｉｔ）から構成され、アクセスユニット（ＡＵ）は、必ず１つ以上のスライスセグメントＮＡＬユニットを含む。

図１９に示すように、ＨＥＶＣ符号化処理によって生成される符号化データにも符号化処理単位としてのＧＯＰが設定され、このＧＯＰは、さらに複数のＮＡＬユニットに分割される。
先に図５を参照して説明したサブＧＯＰメディアセグメントに、ＨＥＶＣ符号化データにおいて設定されるＧＯＰ構成データであるＮＡＬユニットを１つ、または複数、格納する構成とする。
このように、ＨＥＶＣ符号化データについても、ＧＯＰデータを分割したＮＡＬユニット単位のメディアデータ（ｍｄａｔ）を格納したフラグメントの生成が可能である。従って、図５他を参照して説明したサブＧＯＰメディアセグメントの生成が可能であり、本開示の処理を適用することができる。
なお、ＭＰ４、ＨＥＶＣに限らず、ＧＯＰ相当の符号化処理単位を持ち、ＧＯＰデータを分割したユニット（ＮＡＬ）が設定される符号化構成であれば、本開示の処理を適用することが可能である。

［１１．各装置のハードウェア構成例について］
最後に、図２０を参照して、上述した処理を実行する各装置のハードウェア構成例について説明する。
図２０は、送信装置２０、受信装置３０として適用可能な通信装置のハードウェア構成例を示している。

ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２、または記憶部２０８に記憶されているプログラムに従って各種の処理を実行するデータ処理部として機能する。例えば、上述した実施例において説明したシーケンスに従った処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３には、ＣＰＵ２０１が実行するプログラムやデータなどが記憶される。これらのＣＰＵ２０１、ＲＯＭ２０２、およびＲＡＭ２０３は、バス２０４により相互に接続されている。

ＣＰＵ２０１はバス２０４を介して入出力インタフェース２０５に接続され、入出力インタフェース２０５には、各種スイッチ、キーボード、マウス、マイクロホンなどよりなる入力部２０６、ディスプレイ、スピーカなどよりなる出力部２０７が接続されている。ＣＰＵ２０１は、入力部２０６から入力される指令に対応して各種の処理を実行し、処理結果を例えば出力部２０７に出力する。

入出力インタフェース２０５に接続されている記憶部２０８は、例えばハードディスク等からなり、ＣＰＵ２０１が実行するプログラムや各種のデータを記憶する。通信部２０９は、インターネットやローカルエリアネットワークなどのネットワークを介したデータ通信の送受信部、さらに放送波の送受信部として機能し、外部の装置と通信する。

入出力インタフェース２０５に接続されているドライブ２１０は、磁気ディスク、光ディスク、光磁気ディスク、あるいはメモリカード等の半導体メモリなどのリムーバブルメディア２１１を駆動し、データの記録あるいは読み取りを実行する。

なお、データの符号化あるいは復号は、データ処理部としてのＣＰＵ２０１の処理として実行可能であるが、符号化処理あるいは復号処理を実行するための専用ハードウェアとしてのコーデックを備えた構成としてもよい。

［１２．本開示の構成のまとめ］
以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。

なお、本明細書において開示した技術は、以下のような構成をとることができる。
（１） 符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成し、
前記サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録したパケットを生成するデータ処理部と、
前記データ処理部の生成したパケットを送信する通信部を有する通信装置。

（２）前記データ処理部は、ＧＯＰの構成データであるＮＡＬユニットを１つ以上含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成する前記（１）に記載の通信装置。

（３）前記データ処理部は、パケット格納セグメントが、メディアデータを格納しない初期化セグメントであるか、メディアデータを格納したメディアセグメントであるかを識別可能としたセグメント識別情報をパケット付加情報として記録したパケットを生成する前記（１）または（２）に記載の通信装置。

（４）前記データ処理部は、前記サブＧＯＰメディアセグメントの格納データであるメディアデータが、ＧＯＰの先頭位置、中間位置、末尾位置のいずれの位置の構成データであるかを識別可能としたＧＯＰ内位置識別子をパケット付加情報として生成する前記（１）〜（３）いずれかに記載の通信装置。

（５）前記データ処理部は、前記付加情報を生成パケット内のＨＴＴＰヘッダに記録する前記（１）〜（４）いずれかに記載の通信装置。

（６）前記データ処理部は、前記付加情報を生成パケット内の拡張ヘッダに記録する前記（１）〜（４）いずれかに記載の通信装置。

（７）前記データ処理部は、前記付加情報を生成パケット内のＬＣＴヘッダに記録する前記（１）〜（４）いずれかに記載の通信装置。

（８）前記通信部は、前記データ処理部の生成したパケットを、放送波を介してブロードキャスト配信、またはマルチキャスト配信する前記（１）〜（７）いずれかに記載の通信装置。

（９）符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとし、
前記サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録したパケットを受信する通信部と、
前記通信部の受信したパケットを入力して処理を実行するデータ処理部を有する通信装置。

（１０）前記データ処理部は、受信パケットに記録されたＧＯＰ内位置識別子を参照して、複数の受信パケットに分散格納されたＧＯＰ構成データの配列を実行してＧＯＰデータを再構築する前記（９）に記載の通信装置。

（１１）前記通信部は、ＧＯＰの構成データであるＮＡＬユニットを１つ以上含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントを格納したパケットを受信し、前記データ処理部は、受信パケットからＮＡＬユニットを１つ以上含むメディアデータを取得し、受信パケットに記録されたＧＯＰ内位置識別子を参照して、複数の受信パケットに分散格納されたＮＡＬユニットの配列を実行してＧＯＰデータを再構築する前記（９）または（１０）に記載の通信装置。

（１２）前記通信部は、パケット格納セグメントが、メディアデータを格納しない初期化セグメントであるか、メディアデータを格納したメディアセグメントであるかを識別可能としたセグメント識別情報をパケット付加情報として記録したパケットを受信し、前記データ処理部は、受信パケットに記録された付加情報から、前記セグメント識別情報を取得し、受信パケットに格納されたセグメントの種類を判別して、判別結果に応じた処理を実行する前記（９）〜（１１）いずれかに記載の通信装置。

（１３）前記通信部は、前記サブＧＯＰメディアセグメントの格納データであるメディアデータが、ＧＯＰの先頭位置、中間位置、末尾位置のいずれの位置の構成データであるかを識別可能としたＧＯＰ内位置識別子をパケット付加情報として設定したパケットを受信し、前記データ処理部は、受信パケットに記録されたＧＯＰ内位置識別子に基づいて、前記サブＧＯＰメディアセグメントの格納データであるメディアデータが、ＧＯＰの先頭位置、中間位置、末尾位置のいずれの位置の構成データであるかを判別する前記（９）〜（１２）いずれかに記載の通信装置。

（１４）前記通信部は、前記パケット付加情報をＨＴＴＰヘッダに記録したパケットを受信し、前記データ処理部は、受信パケットのＨＴＴＰヘッダから前記パケット付加情報を取得する前記（９）〜（１３）いずれかに記載の通信装置。

（１５）前記通信部は、前記パケット付加情報を拡張ヘッダに記録したパケットを受信し、前記データ処理部は、受信パケットの拡張ヘッダから前記パケット付加情報を取得する前記（９）〜（１３）いずれかに記載の通信装置。

（１６）前記通信部は、前記パケット付加情報をＬＣＴヘッダに記録したパケットを受信し、前記データ処理部は、受信パケットのＬＣＴヘッダから前記パケット付加情報を取得する前記（９）〜（１３）いずれかに記載の通信装置。

（１７）前記通信部は、前記パケットを、放送波を介して受信する前記（９）〜（１６）いずれかに記載の通信装置。

（１８）データ送信装置において実行する通信データ生成方法であり、
データ処理部が、符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成し、
前記サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録した送信パケットを生成する通信データ生成方法。

（１９）データ受信装置において実行する通信データ処理方法であり、
通信部が、符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとし、
前記サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録したパケットを受信し、
データ処理部が、前記通信部の受信したパケットを入力して処理を実行する通信データ処理方法。

また、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。例えば、プログラムは記録媒体に予め記録しておくことができる。記録媒体からコンピュータにインストールする他、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介してプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。

なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。

以上、説明したように、本開示の一実施例の構成によれば、ＧＯＰを分割したデータ単位でコンテンツ配信を行い、受信装置側でＧＯＰ復元と再生を実行可能とした装置、方法が実現される。
具体的には、送信装置が、ＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成し、サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録したパケットを生成して送信する。受信装置は、受信パケットに設定されたＧＯＰ内位置識別子を参照して複数のパケットに分割格納されたメディアデータを配列してＧＯＰを再構築して復号する。
本構成により、ＧＯＰを分割したデータ単位でコンテンツ配信を行い、受信装置側でＧＯＰ復元と再生を実行可能とした装置、方法が実現される。

１０ 通信システム
２０ 送信装置
２１ データ処理部
２２ 通信部
３０ 受信装置
３１ データ処理部
３２ 通信部
５０ 初期化セグメント
６０ メディアセグメント
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２０４ バス
２０５ 入出力インタフェース
２０６ 入力部
２０７ 出力部
２０８ 記憶部
２０９ 通信部
２１０ ドライブ
２１１ リムーバブルメディア

Claims (19)

1. 符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成し、
   前記サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録したパケットを生成するデータ処理部と、
   前記データ処理部の生成したパケットを送信する通信部を有する通信装置。
2. 前記データ処理部は、
   ＧＯＰの構成データであるＮＡＬユニットを１つ以上含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成する請求項１に記載の通信装置。
3. 前記データ処理部は、
   パケット格納セグメントが、メディアデータを格納しない初期化セグメントであるか、メディアデータを格納したメディアセグメントであるかを識別可能としたセグメント識別情報をパケット付加情報として記録したパケットを生成する請求項１に記載の通信装置。
4. 前記データ処理部は、
   前記サブＧＯＰメディアセグメントの格納データであるメディアデータが、ＧＯＰの先頭位置、中間位置、末尾位置のいずれの位置の構成データであるかを識別可能としたＧＯＰ内位置識別子をパケット付加情報として生成する請求項１に記載の通信装置。
5. 前記データ処理部は、
   前記付加情報を生成パケット内のＨＴＴＰヘッダに記録する請求項１に記載の通信装置。
6. 前記データ処理部は、
   前記付加情報を生成パケット内の拡張ヘッダに記録する請求項１に記載の通信装置。
7. 前記データ処理部は、
   前記付加情報を生成パケット内のＬＣＴヘッダに記録する請求項１に記載の通信装置。
8. 前記通信部は、
   前記データ処理部の生成したパケットを、放送波を介してブロードキャスト配信、またはマルチキャスト配信する請求項１に記載の通信装置。
9. 符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとし、
   前記サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録したパケットを受信する通信部と、
   前記通信部の受信したパケットを入力して処理を実行するデータ処理部を有する通信装置。
10. 前記データ処理部は、
    受信パケットに記録されたＧＯＰ内位置識別子を参照して、複数の受信パケットに分散格納されたＧＯＰ構成データの配列を実行してＧＯＰデータを再構築する請求項９に記載の通信装置。
11. 前記通信部は、
    ＧＯＰの構成データであるＮＡＬユニットを１つ以上含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントを格納したパケットを受信し、
    前記データ処理部は、
    受信パケットからＮＡＬユニットを１つ以上含むメディアデータを取得し、受信パケットに記録されたＧＯＰ内位置識別子を参照して、複数の受信パケットに分散格納されたＮＡＬユニットの配列を実行してＧＯＰデータを再構築する請求項９に記載の通信装置。
12. 前記通信部は、
    パケット格納セグメントが、メディアデータを格納しない初期化セグメントであるか、メディアデータを格納したメディアセグメントであるかを識別可能としたセグメント識別情報をパケット付加情報として記録したパケットを受信し、
    前記データ処理部は、
    受信パケットに記録された付加情報から、前記セグメント識別情報を取得し、受信パケットに格納されたセグメントの種類を判別して、判別結果に応じた処理を実行する請求項９に記載の通信装置。
13. 前記通信部は、
    前記サブＧＯＰメディアセグメントの格納データであるメディアデータが、ＧＯＰの先頭位置、中間位置、末尾位置のいずれの位置の構成データであるかを識別可能としたＧＯＰ内位置識別子をパケット付加情報として設定したパケットを受信し、
    前記データ処理部は、
    受信パケットに記録されたＧＯＰ内位置識別子に基づいて、前記サブＧＯＰメディアセグメントの格納データであるメディアデータが、ＧＯＰの先頭位置、中間位置、末尾位置のいずれの位置の構成データであるかを判別する請求項９に記載の通信装置。
14. 前記通信部は、
    前記パケット付加情報をＨＴＴＰヘッダに記録したパケットを受信し、
    前記データ処理部は、
    受信パケットのＨＴＴＰヘッダから前記パケット付加情報を取得する請求項９に記載の通信装置。
15. 前記通信部は、
    前記パケット付加情報を拡張ヘッダに記録したパケットを受信し、
    前記データ処理部は、
    受信パケットの拡張ヘッダから前記パケット付加情報を取得する請求項９に記載の通信装置。
16. 前記通信部は、
    前記パケット付加情報をＬＣＴヘッダに記録したパケットを受信し、
    前記データ処理部は、
    受信パケットのＬＣＴヘッダから前記パケット付加情報を取得する請求項９に記載の通信装置。
17. 前記通信部は、
    前記パケットを、放送波を介して受信する請求項９に記載の通信装置。
18. データ送信装置において実行する通信データ生成方法であり、
    データ処理部が、符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成し、
    前記サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録した送信パケットを生成する通信データ生成方法。
19. データ受信装置において実行する通信データ処理方法であり、
    通信部が、符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとし、
    前記サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子をパケット付加情報として記録したパケットを受信し、
    データ処理部が、前記通信部の受信したパケットを入力して処理を実行する通信データ処理方法。

Images