WO2015107786A1

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

Info

Publication number: WO2015107786A1
Application number: PCT/JP2014/081715
Authority: WO
Inventors: 山岸　靖明
Original assignee: ソニー株式会社
Priority date: 2014-01-17
Filing date: 2014-12-01
Publication date: 2015-07-23
Also published as: US10178417B2; CA2936164C; KR102103054B1; US10820024B2; EP3096533A1; US20160330491A1; US20210029388A1; JP2015136059A; US11284135B2; MX2019009888A; CA2936164A1; KR20160111021A; CN105900446B; EP3096533B1; MX2016008985A; US20190075334A1; CN105900446A; EP3096533A4

Abstract

通信パケットの格納符号化データが、ランダムアクセス可能な符号化データに基づくデータであるか否かをパケット単位で判別可能とした構成を提供する。送信装置が、符号化データの構成要素であるＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、付加情報として、パケット格納データの元データであるＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定して送信する。受信装置はパケット付加情報を参照してパケット格納データが、ランダムアクセス可能な符号化データに基づいて生成されたデータであるか否かを判別する。

Description

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

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

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

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

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

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

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

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

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

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

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

　本開示の第１の側面は、
　符号化データを格納したパケットを生成するデータ処理部と、
　前記データ処理部の生成したパケットを送信する通信部を有し、
　前記データ処理部は、
　符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、
　パケットに対する付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定したパケットを生成して前記通信部を介して送信する通信装置にある。

　さらに、本開示の通信装置の一実施態様において、前記アクセスポイント情報は、パケット格納データが、ＳＡＰ（Ｓｔｒｅｅｍｉｎｇ　Ａｃｃｅｓｓ　Ｐｏｉｎｔ）によって指定される符号化データを含むＮＡＬユニットに基づいて生成されたデータであるか否かを示す情報である。

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

　さらに、本開示の通信装置の一実施態様において、前記データ処理部は、ＧＯＰを構成するＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを生成して、ＮＡＬユニットフラグメントを格納した複数のパケットと、前記ＮＡＬユニットに対応するメタデータを格納したパケットを生成する。

　さらに、本開示の通信装置の一実施態様において、前記データ処理部は、送信対象の符号化データを、通信経路上で規定される最大データ転送単位（ＭＴＵ：Ｍａｘｉｍｕｍ　Ｔｒａｎｓｆｅｒ　Ｕｎｉｔ）以下のデータに分割して生成した分割データを格納したパケットを生成する。

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

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

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

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

　さらに、本開示の第２の側面は、
　送信装置が送信した符号化データ格納パケットを受信する通信部と、
　前記通信部の受信したパケットを入力して処理を実行するデータ処理部を有し、
　前記通信部の受信する前記符号化データ格納パケットの各々は、
　符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットであり、付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報が設定されたパケットである通信装置にある。

　さらに、本開示の通信装置の一実施態様において、前記データ処理部は、受信パケットに記録された付加情報である前記アクセスポイント情報を参照して、受信パケットに格納されたデータが、ＳＡＰ（Ｓｔｒｅｅｍｉｎｇ　Ａｃｃｅｓｓ　Ｐｏｉｎｔ）によって指定される符号化データを含むＮＡＬユニットに基づいて生成されたデータであるか否かを判定する処理を実行する。

　さらに、本開示の通信装置の一実施態様において、前記データ処理部は、受信パケットに記録された付加情報である前記アクセスポイント情報を参照して、アクセスポイントを含むデータを選択取得して、復号、再生処理を実行する。

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

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

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

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

　さらに、本開示の第３の側面は、
　データ送信装置において実行する通信データ生成方法であり、
　データ処理部が、
　符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、
　パケットに対する付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定したパケットを生成して通信部を介して送信する通信データ生成方法にある。

　さらに、本開示の第４の側面は、
　データ受信装置において実行する通信データ処理方法であり、
　通信部が、送信装置が送信した符号化データ格納パケットを受信するステップと、
　データ処理部が、前記通信部の受信したパケットを入力して処理を実行するデータ処理ステップを実行し、
　前記通信部の受信する前記符号化データ格納パケットの各々は、
　符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットであり、付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報が設定されたパケットであり、
　前記データ処理ステップは、前記通信部の受信したアクセスポイント情報が設定されたパケットを入力して処理を実行するステップである通信データ処理方法にある。

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

　本開示の一実施例の構成によれば、通信パケットの格納符号化データが、ランダムアクセス可能な符号化データに基づくデータであるか否かをパケット単位で判別可能とした構成が実現される。
　具体的には、送信装置が、符号化データの構成要素であるＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、付加情報として、パケット格納データの元データであるＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定して送信する。受信装置はパケット付加情報を参照してパケット格納データが、ランダムアクセス可能な符号化データに基づいて生成されたデータであるか否かを判別する。
　本構成により、通信パケットの格納符号化データが、ランダムアクセス可能な符号化データに基づくデータであるか否かをパケット単位で判別可能とした構成が実現される。
　なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　［７．パケットに格納したＮＡＬユニットがＳＡＰ（ストリームアクセスポイント）を含むか否かを識別可能としたアクセスポイント情報を付加した構成について］
　次に、受信装置の処理効率化を実現する構成例として、パケットに格納したＮＡＬユニットフラグメントの分割元であるＮＡＬユニットにＳＡＰ（アクセスポイントデータ）を含むか否かを識別可能とした識別情報を付加した構成について説明する。

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

　受信装置側では、ＳＡＰの示すデータ位置の符号化データを取得して、その取得データから復号処理を実行して再生を行なうことが可能となる。
　従って、コンテンツの途中から再生するなどの特殊再生処理を行う場合、ＳＡＰは重要な必須データとなる。例えば、ＧＯＰデータの全てを揃えることなく、ＳＡＰにによって指定される符号化データを取得し復号することでランダムアクセスポイントの画像を再生可能となる。

　また、受信装置は、例えば配信遅延などによってＧＯＰ単位の全符号化データのパケット受信が間に合わない場合などに、ＳＡＰによって指定されるランダムアクセスポイントデータを優先して処理を行なうことも可能である。ランダムアクセスポイントデータを選択して復号、再生することで、表示部の画像表示を継続可能となる。このように、処理優先度を判定する場合にもＳＡＰは重要なデータとなる。

　１つのＧＯＰ単位データの中には、確実にランダムアクセスポイントが存在する。しかし、図５～図１０を参照して説明したように、１つのパケットの格納データを１ＧＯＰ単位のデータではなく、１ＧＯＰを細分化して、１つまたは複数のＮＡＬユニットを格納したパケットは、パケットに格納したＮＡＬユニットにランダムアクセスポイントが含まれる場合と含まれない場合がある。

　図５～図１０を参照して説明した構成では、例えば図７に示すように、サブＧＯＰメディアセグメントＨＴＴＰパケットにメタデータである「ｓｉｄｘ」を含むパケットと含まないパケットを設定している。
　サブＧＯＰメディアセグメントＨＴＴＰパケットに格納されたＮＡＬユニットにランダムアクセスポイント対応のデータが含まれればＳＡＰを記録した［ｓｉｄｘ］が設定される。
　しかし、［ｓｉｄｘ］は、メディアデータのランダムアクセスポイント情報であるＳＡＰのみならず、その他のデータの境界情報等も含むメタデータであり、［ｓｉｄｘ］の有無のみによってパケット格納データにアクセスポイントとなるデータが含まれるか否かを判定することはできない。

　従って、上述したサブＧＯＰメディアセグメントＨＴＴＰパケットを利用した符号化データ配信構成では、受信装置側は、受信パケット単位でパケットにアクセスポイントデータが含まれるか否かを判定することが困難になる。
　以下、このような問題を解決し、受信装置側で、受信パケット単位で、パケットにアクセスポイントデータが含まれるか否かを判定可能とした構成について説明する。

　図１３以下を参照して、上述したサブＧＯＰメディアセグメントＨＴＴＰパケットを利用した符号化データ配信構成において、パケット単位で各パケットにアクセスポイントデータが含まれるか否かを判定可能とした構成について説明する。
　図１３は、先に説明した図５、図７と同様、１つのＧＯＰデータを３つのサブＧＯＰメディアセグメントに分割格納したＨＴＴＰパケットの構成例を示している。

　これら３つのＨＴＴＰパケットのＨＴＴＰヘッダには、先に図７を参照して説明した以下の付加情報が記録される。
　（１）セグメント識別子（Ｃｏｎｔｅｎｔ－Ｌｏｃａｔｉｏｎ）
　（２）ＧＯＰ内位識別情報（Ｘ－（Ｓｔａｒｔ／Ｍｉｄｄｌｅ／Ｅｎｄ）ｏｆＧＯＰ）
　さらに、図１３に示す例では、ＨＴＴＰヘッダに以下の付加情報を追加記録する。
　（３）アクセスポイント情報（Ｘ－ＳＡＰ）
　これらの３つの情報を記録する。

　（３）アクセスポイント情報（Ｘ－ＳＡＰ）は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）に含まれる符号化データにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。
　受信装置は、このアクセスポイント情報（Ｘ－ＳＡＰ）を参照することで、そのＨＴＴＰパケットに格納されたメディアデータ内のＮＡＬユニットがアクセスポイントデータを含むか否かを即座に判別することができる。
　従って、例えばアクセスポイントデータのみを優先して復号、再生を行なう場合には、ＨＴＴＰヘッダに記録されたアクセスポイント情報（Ｘ－ＳＡＰ）を参照して、処理対象パケットを選択することができる。すなわち、ＨＴＴＰヘッダに記録されたアクセスポイント情報（Ｘ－ＳＡＰ）が、パケット格納データ（ＮＡＬユニット）にアクセスポイントが含まれることを示すパケットのみを選択して処理を行なうことが可能となる。

　なお、図１３に示す例では、図１３（ｂ１）～（ｂ３）のすべてのＨＴＴＰパケットにアクセスポイント情報（Ｘ－ＳＡＰ）を設定し、アクセスポイント情報（Ｘ－ＳＡＰ）が、各ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）に含まれる符号化データにランダムアクセスポイントとなるデータが含まれるか否かを示す構成としている。
　このような構成の他、例えば、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）に含まれる符号化データにランダムアクセスポイントとなるデータが含まれる場合にのみ、そのＨＴＴＰパケットのＨＴＴＰヘッダにアクセスポイント情報（Ｘ－ＳＡＰ）を記録する構成としてもよい。すなわち、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）に含まれる符号化データにランダムアクセスポイントとなるデータが含まれない場合は、ＨＴＴＰヘッダにアクセスポイント情報（Ｘ－ＳＡＰ）を記録しない。例えば、図１３（ｂ２），（ｂ３）に示すＨＴＴＰパケットにランダムアクセスポイントとなるデータが含まれない場合は、ＨＴＴＰヘッダにアクセスポイント情報（Ｘ－ＳＡＰ）を記録しない。
　この設定の場合、受信装置は、ＨＴＴＰヘッダにアクセスポイント情報（Ｘ－ＳＡＰ）が記録されているか否かに応じて、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）に含まれる符号化データにランダムアクセスポイントとなるデータが含まれるか否かを判定する。

　このアクセスポイント情報（Ｘ－ＳＡＰ）は、ランダムアクセス可能なデータの有無をパケット単位で識別可能とする情報である。受信装置側では、各パケットのアクセスポイント情報（Ｘ－ＳＡＰ）を参照して、ランダムアクセス可能なデータの格納されたパケットを選別することが可能となる。受信装置は、例えばランダムアクセス可能なデータの格納されたパケットをを優先処理することで、ランダムアクセスポイントからのデータ再生処理等を迅速に行うことが可能となる。

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

　上記のＨＴＴＰヘッダ情報中、
　セグメント識別子「Ｃｏｎｔｅｎｔ－Ｌｏｃａｔｉｏｎ：　ｈｔｔｐ：／／ａ．ｃｏｍ／ｘ．ｍｐ４」
　ＧＯＰ内位識別情報「Ｘ－ＳｔａｒｔＯｆＧＯＰ」、
　これらについては、先に図８を参照して説明したと同様の情報である。
　すなわち、セグメント識別子は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）の属するＧＯＰの識別情報として機能するＧＯＰデータの位置情報（アクセス情報）である。
　ＧＯＰ内位識別情報は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータである。
　先頭領域の場合は、「Ｘ－ＳｔａｒｔＯｆＧＯＰ」、
　中間領域の場合は、「Ｘ－ＭｉｄｄｌｅＯｆＧＯＰ」、
　末尾領域の場合は、「Ｘ－ＥｎｄＯｆＧＯＰ」、
　ＨＴＴＰヘッダにはこれらのいずれかのデータがＧＯＰ内位識別情報として記録される。

　また、図１４に示すＨＴＴＰヘッダ情報中、
　アクセスポイント情報「Ｘ－ＳＡＰ」は、そのＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）に含まれる符号化データ（ＮＡＬ）にランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。

　受信装置は、アクセスポイント情報（Ｘ－ＳＡＰ）を参照することで、受信パケット単位でパケット格納メディアデータ内のＮＡＬユニットにアクセスポイントが含まれるか否かを即座に判別することができる。

　受信装置は、アクセスポイントが含まれるパケットのみを選択して、これらのパケットの格納データを優先して復号し、再生することが可能となる。例えば配信遅延などによってＧＯＰ単位の全符号化データのパケット受信が間に合わない場合などに、ランダムアクセスポイントデータを優先して復号、再生することで、表示部の画像表示を継続させるといった処理が可能となる。

　　［８．ＮＡＬユニットをさらに分割したＮＡＬユニットフラグメント格納パケットを利用した通信処理構成について］
　上述したように、ＧＯＰの分割データである１つのＮＡＬユニット、または複数のＮＡＬユニットを含むパケットを利用したデータ送受信を行うことで、ネットワーク上の１つの転送パケットのデータ量の削減が実現される。

　しかし、例えば高画質の画像データである４Ｋコンテンツや８Ｋコンテンツなど、データ量が多い画像データについては、これらの大容量画像データの符号化処理によって生成するＮＡＬユニットのデータ量が増大する。すなわち、１つのＮＡＬユニットそのもののデータ量が非常に大きくなる場合が想定される。

　ＩＰレイヤにおけるデータ転送処理において、例えばイーサネット（登録商標）を介したデータ転送を行う場合、ＩＰパケットをイーサネット（登録商標）で規定される最大データ転送単位（ＭＴＵ：Ｍａｘｉｍｕｍ　Ｔｒａｎｓｆｅｒ　Ｕｎｉｔ）以下のＭＡＣフレームを生成して転送することが必要となる。
　すなわち最大データ転送単位（ＭＴＵ）の規定されたネットワークを介してパケットを転送する場合には、ＭＴＵ以上のデータ量を持つＩＰパケットについて、ＭＴＵで規定するデータ量以下に分割するフラグメント処理を実行し、各分割データを格納した複数のＭＡＣフレームを生成して転送する処理が必須となる。

　例えばイーサネット（登録商標）の規定するＭＡＣフレームのフレーム単位の最大データ転送量（ＭＴＵ）は約１５００バイトである。
　ＭＡＣフレームは、例えば図１５に示す構成を有し、先に図１０を参照して説明したＩＰパケットの先頭にＭＡＣヘッダを設定した構成である。例えば図１５に示すＭＡＣフレームでは、ＭＡＣフレームのペイロードとなるＩＰヘッダ～ｍｄａｔまでのデータ量をＭＴＵ＝１５００バイト以下に設定することが必要となる。

　送信装置２０から受信装置３０にパケット送信を行う場合、送信装置２０や受信装置３０側の各デバイス間通信や、送信装置２０と受信装置３０間の中継装置等において、このＭＴＵに応じたフラグメンテーション、すなわちパケット分割処理と、分割データの再構成処理が繰り返し実行される可能性がある。
　このような事態が発生すると、送信装置２０におけるコンテンツ入力から受信装置３０におけるコンテンツ再生までの時間に遅延が発生し、受信装置３０におけるコンテンツの再生遅延が発生する可能性が高まることになる。

　以下では、このような事態を防止する構成について説明する。
　以下に説明する実施例において、送信装置２０は、パケット生成処理段階におけるＨＴＴＰレイヤにおいて、パケットのデータサイズを所定サイズ以下に設定する。具体的には、通信路において想定される最大データ転送単位（ＭＴＵ：Ｍａｘｉｍｕｍ　Ｔｒａｎｓｆｅｒ　Ｕｎｉｔ）以下の小さなデータサイズとする。具体的には、例えば１つのＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成して送信する。

　前述したように、例えばイーサネット（登録商標）の規定するＭＡＣフレームのフレーム単位の一般的な最大データ転送量（ＭＴＵ）は約１５００バイトである。
　送信装置２０のデータ処理部はＨＴＴＰパケットの生成段階で、このＭＴＵを考慮したパケット生成を行う。例えば、ＨＴＴＰパケットを格納したＭＡＣフレームのフレームサイズが１５００バイト以下になるようにパケット生成を実行する。

　送信装置２０のデータ処理部において、通信経路における最大データ転送量（ＭＴＵ）を考慮したパケット生成処理を実行することで、送信装置や、中継装置、あるいは受信装置のＩＰレイヤにおいてＭＴＵに従ったパケット分割処理であるフラグメンテーションが不要となり、データ転送をスムーズに実行することが可能になる。

　このように、送信装置２０のデータ処理部はＨＴＴＰパケットの生成段階で、パケット格納データを通信経路において規定されるＭＴＵ以下の小さなフラグメントに設定する処理を実行する。この処理により、例えば、通信路のＩＰレイヤにおけるフラグメンテーション処理よるオーバーヘッドが低減される。

　先に図５他を参照して説明した例では、１つまたは複数のＮＡＬユニットをメディアデータ（ｍｄａｔ）とし、さらにその属性データであるメタデータ（ｍｏｏｆ）と組み合わせて１つのフラグメントを生成し、このフラグメントを持つサブＧＯＰメディアセグメントを格納したＨＴＴＰパケットを生成していた。

　以下に説明する実施例では、１つのＮＡＬユニットを分割したＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したＨＴＴＰパケットを生成する。
　なお、ＮＡＬユニット対応の属性データである（ｍｏｏｆ）は、メディアデータ（ｍｄａｔ）格納パケットと異なる別の独立したＨＴＴＰパケットに格納して配信する。

　図１６を参照して、本実施例におけるＨＴＴＰパケットの構成例について説明する。
　図１６（ａ）は、先に図５～図７等を参照して説明したサブＧＯＰメディアセグメントである。すなわちＧＯＰを分割したデータである１つ以上のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したセグメントである。
　ただし、図１６（ａ）に示すサブＧＯＰメディアセグメントはメディアデータ（ｍｄａｔ）として１つのＮＡＬユニットのみを格納した例である。ＮＡＬユニットは１に限らず複数のＮＡＬユニットとしてもよい。

　本実施例では、この図１６（ａ）に示すようなサブＧＯＰメディアセグメントをさらに分割して複数のＨＴＴＰパケットを生成する。分割処理は、通信経路における最大データ転送量（ＭＴＵ）を考慮して実行する。例えば、分割後のＨＴＴＰパケットを格納したＭＡＣフレームを生成した場合に、ＭＡＣフレームに許容される最大データ転送単位（ＭＴＵ：Ｍａｘｉｍｕｍ　Ｔｒａｎｓｆｅｒ　Ｕｎｉｔ）以下となるように行う。

　なお、分割処理に際しては１つまたは複数のＮＡＬユニットを分割するＮＡＬユニット分割処理を行なうことになる。以下では、ＮＡＬユニットの分割後のデータをＮＡＬユニットフラグメント（ＮＡＬｆ）として説明する。
　また、サブＧＯＰメディアセグメントの構成データを分割して生成したＨＴＴＰパケットをＮＡＬユニットフラグメント対応ＨＴＴＰパケットと呼ぶ。

　図１６に示す例では、図１６（ａ）に示すサブＧＯＰメディアセグメントの構成データを４つのＨＴＴＰパケット（ｂ１）～（ｂ４）に分割した例を示している。
　（ｂ１）～（ｂ４）に示す４つのＮＡＬユニットフラグメント対応ＨＴＴＰパケットの各々は、このＨＴＴＰパケットを図１５に示すＭＡＣフレーム構成とした場合、ＭＡＣヘッダ以外のデータ部のデータ量が１５００バイト以下になるようなデータ量に設定する。

　図１６の（ｂ１）に示すＮＡＬユニットフラグメント対応ＨＴＴＰパケットは、（ａ）に示すサブＧＯＰメディアセグメントのメタデータ領域、すなわち、ｍｓｄｈ（ｓｔｙｐｅ）、ｓｉｄｘ、ｍｏｏｆ、これらのメタデータを格納したＨＴＴＰパケットである。すなわちメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットである。

　また、図１６（ｂ２）～（ｂ４）に示すＮＡＬユニットフラグメント対応ＨＴＴＰパケットは、（ａ）に示すサブＧＯＰメディアセグメントのメディアデータ（ｍｄａｔ）領域のＮＡＬユニットを分割して生成したＮＡＬフラグメント（ＮＡＬｆ）を格納したＨＴＴＰパケットである。すなわちメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットである。

　なお、図１６（ａ）に示すサブＧＯＰメディアセグメントに格納されたＮＡＬユニットは１つのみであるが、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットは図１６（ａ）に示すように１つのＮＡＬユニットである場合と、２つ以上の複数のＮＡＬユニットである場合がある。ＮＡＬユニットフラグメントの構成データは、１つのＮＡＬユニットのみに限らず、複数のＮＡＬユニットに跨ったデータとしてもよい。例えば先行するＮＡＬユニットの後半部分と、後続のＮＡＬユニットの先頭部分をあわせて１つのＮＡＬユニットフラグメントを設定するといった構成も可能である。

　送信装置２０は、このように１つのサブＧＯＰメディアセグメントを分割して複数のＨＴＴＰパケットを生成して、これらのＨＴＴＰパケットからさらにＩＰパケットを生成し、順次送信する。

　しかし、このように本来の１つのＮＡＬユニットやその属性情報が分割されて配信されると、受信装置３０側で復号、再生処理を行うためには、ＮＡＬユニットとその属性情報を再構築する必要がある。
　このために必要となる情報を付加情報としてＨＴＴＰヘッダに記録する。

　図１６（ｂ１）に示すメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのＨＴＴＰヘッダには、以下の付加情報を記録する。
　＊ＮＡＬユニットフラグメントヘッダ［Ｘ－ＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔＨｅａｄｅｒ］
　＊ムービーフラグメントシーケンス番号［Ｘ－ＭｏｖｉｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ］
　＊アクセスポイント情報［Ｘ－ＳＡＰ］

　ＮＡＬユニットフラグメントヘッダは、そのＨＴＴＰパケットが、
　メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであるか、
　メディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであるか、
　を識別するための識別情報である。

　ムービーフラグメントシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号であり、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。このシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号をそのままコピーして記録する。

　アクセスポイント情報は、このＨＴＴＰパケットの生成元となったサブＧＯＰセグメント（図１６（ａ）のサブＧＯＰメディアセグメント）に格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。
　受信装置は、このアクセスポイント情報（Ｘ－ＳＡＰ）を参照することで、そのＨＴＴＰパケットが、ランダムアクセスポイントとなるＮＡＬユニットを含むサブＧＯＰセグメントの構成データに基づいて生成されたデータであるか否かを即座に判別することができる。

　なお、この図１６（ｂ１）のメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのＨＴＴＰヘッダに記録されたアクセスポイント情報（Ｘ－ＳＡＰ）が、パケット生成元のサブＧＯＰセグメントにアクセスポイントデータを含むことを示す場合、メタデータである［ｓｉｄｘ］を参照することで、ＳＡＰ、すなわちランダムアクセスポイントの符号化データの位置を取得することが可能となる。

　一方、図１６（ｂ２）～（ｂ４）に示すメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのＨＴＴＰヘッダには、以下の付加情報を記録する。
　＊ムービーフラグメントシーケンス番号［Ｘ－ＭｏｖｉｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ］
　＊ＮＡＬユニット内位置識別情報［Ｘ－ＮＡＬＵＦｒａｇｍｅｎｔＩｎｄｉｃａｔｏｒ］
　＊アクセスポイント情報［Ｘ－ＳＡＰ］

　ムービーフラグメントシーケンス番号は、上述したように、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号であり、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。このシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号をそのままコピーして記録する。

　ＮＡＬユニット内位置識別情報は、パケットに格納したＮＡＬユニットフラグメント（ＮＡＬｆ）が、分割前のＮＡＬユニットのどの位置に対応するフラグメントであるかを示す情報である。
　ＮＡＬユニット内位置識別情報＝Ｘ－ＳｔａｒｔＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔであるパケットは、分割前のＮＡＬユニットの先頭領域のＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したパケットである。
　ＮＡＬユニット内位置識別情報＝Ｘ－ＭｉｄｄｌｅＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔであるパケットは、分割前のＮＡＬユニットの中間領域のＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したパケットである。
　ＮＡＬユニット内位置識別情報＝Ｘ－ＥｎｄＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔであるパケットは、分割前のＮＡＬユニットの末尾領域のＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したパケットである。

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

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

　図１７に、メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットの構成とＨＴＴＰヘッダのデータ構成例を示す。
　図１７に示すようにＨＴＴＰヘッダには、例えば以下のＨＴＴＰヘッダ情報が記録される。
　「・・・
　ＨＴＴＰ／１．１　２０６　Ｐａｒｔｉａｌ　Ｃｏｎｔｅｎｔ
　Ｄａｔｅ：　Ｆｒｉ，　０４　Ｏｃｔ　２０１３　１１：１４：２０　ＧＭＴ
　Ｃｏｎｔｅｎｔ－ｔｙｐｅ：　ａｐｐｌｉｃａｔｉｏｎ／ｍｐ４
　Ｘ－ＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔＨｅａｄｅｒ
　Ｘ－ＭｏｖｉｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ：２３４５６７
　Ｘ－ＳＡＰ
　　・・・」

　上記のＨＴＴＰヘッダ情報中、
　ＮＡＬユニットフラグメントヘッダは、
　「Ｘ－ＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔＨｅａｄｅｒ」
　である。
　このＮＡＬユニットフラグメントヘッダは、このＨＴＴＰパケットが、メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであることを示す情報として記録される。

　また、上記のＨＴＴＰヘッダ情報中、
　ムービーフラグメントシーケンス番号は、
　「Ｘ－ＭｏｖｉｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ」
　である。
　このムービーフラグメントシーケンス番号は、上述したように、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号であり、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。このシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号をそのままコピーして記録する。

　また、上記のＨＴＴＰヘッダ情報中、
　アクセスポイント情報は、
　「Ｘ－ＳＡＰ」
　である。
　このアクセスポイント情報は、このＨＴＴＰパケットの生成元となったサブＧＯＰセグメントに格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。

　次に、図１８を参照して、メディアデータを格納するメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットの構成とＨＴＴＰヘッダのデータ構成例について説明する。
　図１８に示すようにＨＴＴＰヘッダには、例えば以下のＨＴＴＰヘッダ情報が記録される。
　「・・・
　ＨＴＴＰ／１．１　２０６　Ｐａｒｔｉａｌ　Ｃｏｎｔｅｎｔ
　Ｄａｔｅ：　Ｆｒｉ，　０４　Ｏｃｔ　２０１３　１１：１４：２０　ＧＭＴ
　Ｃｏｎｔｅｎｔ－ｔｙｐｅ：　ａｐｐｌｉｃａｔｉｏｎ／ｍｐ４
　Ｘ－ＳｔａｒｔＯｆＧＯＰ
　Ｘ－ＭｏｖｉｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ：２３４５６７
　Ｘ－ＳｔａｒｔＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ
　Ｘ－ＳＡＰ
　　・・・」

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

　また、上記のＨＴＴＰヘッダ情報中、
　ＮＡＬユニット内位置識別情報は、
　「Ｘ－ＳｔａｒｔＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ」
　である。
　このＮＡＬユニット内位置識別情報は、パケットに格納したＮＡＬユニットフラグメント（ＮＡＬｆ）が、分割前のＮＡＬユニットのどの位置に対応するフラグメントであるかを示す情報である。

　ＮＡＬユニット内位置識別情報＝Ｘ－ＳｔａｒｔＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔであるパケットは、分割前のＮＡＬユニットの先頭領域のＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したパケットである。
　ＮＡＬユニット内位置識別情報＝Ｘ－ＭｉｄｄｌｅＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔであるパケットは、分割前のＮＡＬユニットの中間領域のＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したパケットである。
　ＮＡＬユニット内位置識別情報＝Ｘ－ＥｎｄＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔであるパケットは、分割前のＮＡＬユニットの末尾領域のＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したパケットである。

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

　まず、図１９に示すフローチャートを参照して送信装置２０の実行する処理シーケンスについて説明する。
　図１９に示すフローは、図１６を参照して説明した例えば図１６（ａ）に示すサブＧＯＰメディアセグメントに基づいて生成するメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット、あるいはメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットの生成と送信処理のシーケンスを説明するフローである。
　この処理は、送信装置２０のデータ処理部において実行する。データ処理部は、プログラム実行機能を有するＣＰＵを備え、例えば記憶部に格納されたプログラムに従って、図１９に示すフローに従った処理を実行する。
　以下、各ステップの処理について、順次、説明する。

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

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

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

　　（ステップＳ１０４）
　次に、送信装置は、サブＧＯＰメディアセグメントに対応するメタデータであるｍｓｄｈ、ｓｉｄｘを生成する。先に図５他を参照して説明したサブＧＯＰメディアセグメントに格納するメタデータである。

　　（ステップＳ１０５）
　次に、送信装置は、サブＧＯＰメディアセグメント格納用のメタデータ（ｍｄａｔ）を分割してＮＡＬユニットフラグメント（Ｎａｌｆ）を生成する。なお、分割処理は、例えばＭＡＣフレームの一般的なＭＴＵに従い、ＭＡＣフレームとした場合のペイロードが約１５００バイト以下となるように分割処理を実行する。

　　（ステップＳ１０６）
　次に、送信装置は、メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットと、ＮＡＬユニットフラグメントを格納したメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのパケットヘッダを生成する。
　これは、先に図１６、図１７、図１８を参照して説明したＨＴＴＰヘッダ情報の生成処理である。

　メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのＨＴＴＰヘッダには、以下の情報を記録する。
　まず、このＨＴＴＰパケットがメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであることを示すＮＡＬユニットフラグメントヘッダを記録する。
　さらに、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報に相当するムービーフラグメントシーケンス番号を記録する。このシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号をそのままコピーして記録する。
　さらに、アクセスポイント情報「Ｘ－ＳＡＰ」を記録する。
　このアクセスポイント情報は、このＨＴＴＰパケットの生成元となったサブＧＯＰセグメントに格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。

　一方、メディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのパケットヘッダには以下の情報を記録する。
　ＧＯＰ内位識別情報：ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータであり、
　先頭領域の場合は、「Ｘ－ＳｔａｒｔＯｆＧＯＰ」、
　中間領域の場合は、「Ｘ－ＭｉｄｄｌｅＯｆＧＯＰ」、
　末尾領域の場合は、「Ｘ－ＥｎｄＯｆＧＯＰ」、
　これらのいずれかのデータを記録する。

　ムービーフラグメントシーケンス番号：上述したように、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号であり、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。このシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号をそのままコピーして記録する。

　ＮＡＬユニット内位置識別情報：パケットに格納したＮＡＬユニットフラグメント（ＮＡＬｆ）が、分割前のＮＡＬユニットのどの位置に対応するフラグメントであるかを示す情報である。

　アクセスポイント情報「Ｘ－ＳＡＰ」：アクセスポイント情報は、このＨＴＴＰパケットの生成元となったサブＧＯＰセグメントに格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。

　送信装置は、ステップＳ１０６において、上記のように、メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットと、ＮＡＬユニットフラグメントを格納したメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのパケットヘッダを生成する。

　　（ステップＳ１０７）
　次に、送信装置は、ステップＳ１０７においてステップＳ１０６で生成したＨＴＴＰヘッダを設定した以下のＨＴＴＴＰパケットを生成する。
　メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット
　メディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット
　これらの各ＨＴＴＰパケットを生成する。

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

　なお、図１９に示すフローは、メディアセグメントに基づいて生成するパケットの生成と送信処理シーケンスを説明するフローである。初期化セグメントに基づくパケット生成に際しては、初期化セグメントの構成データの生成の後、ＨＴＴＰヘッダに初期化セグメントであることを示すセグメント識別子を記録する処理などを行なうことになる。

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

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

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

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

　　（ステップＳ２０４）
　次に、受信装置は、ステップＳ２０１で選択した選択コンテンツに対応するサブＧＯＰメディアセグメントの分割パケットである以下のパケットを受信する。
　メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットを格納したＩＰパケット、
　メディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットを格納したＩＰパケット、
　これらの各パケットを受信する。

　　（ステップＳ２０５）
　次に、受信装置は、受信パケットのＨＴＴＰヘッダからパケットに格納されたデータの以下の属性情報を取得する。
　＊ＮＡＬユニットフラグメントヘッダ
　＊ＧＯＰ内位置識別情報
　＊ムービーフラグメントシーケンス番号
　＊ＮＡＬユニット内位置識別情報
　＊アクセスポイント情報

　上述したように、ＮＡＬユニットフラグメントヘッダは、ＨＴＴＰパケットがメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであることを示す情報である。
　ＧＯＰ内位識別情報は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータである。
　ムービーフラグメントシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号であり、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。
　ＮＡＬユニット内位置識別情報は、パケットに格納したＮＡＬユニットフラグメント（ＮＡＬｆ）が、分割前のＮＡＬユニットのどの位置に対応するフラグメントであるかを示す情報である。
　アクセスポイント情報「Ｘ－ＳＡＰ」は、このＨＴＴＰパケットの生成元となったサブＧＯＰセグメントに格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。

　　（ステップＳ２０６）
　次に、受信装置は、ステップＳ２０６において、アクセスポイントデータを優先して復号、再生を行なう特殊再生を実行するか否かを判定する。
　例えば、ランダムアクセス再生処理などのコンテンツ途中からの再生処理などの特殊再生処理を実行するか否かを判定する。この判定処理はユーザの入力情報等に基づいて決定する。
　特殊再生処理を実行する場合は、ステップＳ２０７に進む。通常再生処理を実行する場合はステップＳ２０８に進む。

　　（ステップＳ２０７）
　ステップＳ２０６において、ランダムアクセス再生処理などの特殊再生処理を実行すると判定した場合ステップＳ２０７に進む。ステップＳ２０７では、パケットのＨＴＴＰヘッダに記録されたアクセスポイント情報［Ｘ－ＳＡＰ］が、アクセスポイントありのデータを示すパケットを選択する。すなわち、ＨＴＴＰパケットの生成元となったサブＧＯＰセグメントに格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれることを示すパケットを復号対象として選択して、復号処理を実行して再生処理を行なう。
　この場合、ＧＯＰ全体を揃えることなく復号再生することが可能となる。
　ステップＳ２０７の処理の後、ステップＳ２１１に進む。

　　（ステップＳ２０８）
　一方、ステップＳ２０６において、ランダムアクセス再生処理などの特殊再生処理を実行せず、通常再生処理を実行すると判定した場合ステップＳ２０８に進む。ステップＳ２０８では、受信装置は、ＨＴＴＰヘッダから取得した識別情報に従って、受信した複数のメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットに格納されたＮＡＬユニットフラグメントを再配列し、ＧＯＰ単位データ再構築する。

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

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

　なお、例えばランダムアクセス再生等、特定の再生位置の画像のみを再生する場合には、メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットにランダムアクセスポイント情報であるｓｉｄｘデータを参照し、ｓｉｄｘデータから算出される１以上のＮＡＬユニットフラグメント（ＮＡＬｆ）のみを処理対象として処理を行なうことができる。すなわち例えばＩピクチャに相当する符号化画像データのみを選択して、これを復号して再生する処理を実行する。
　この場合、ＧＯＰ全体データを再配列する処理を行なうことなくランダムアクセスポイントのデータのみを選択して再生することが可能である。

　　［１０．拡張ヘッダに付加情報を記録した実施例について］
　上述した実施例では、ＮＡＬユニットフラグメント（ＮＡＬｆ）の配列やＧＯＰ再構成処理に適用する情報、さらにアクセスポイント情報等、受信装置側における処理をスムーズに実行させるための付加情報をＨＴＴＰパケットに設定した実施例について説明した。
　しかし、付加情報の記録先はＨＴＴＰヘッダに限らず、様々な記録先とすることが可能である。
　以下、拡張ヘッダに付加情報を記録した実施例について説明する。

　図２２、図２３を参照して、拡張ヘッダに付加情報を記録した実施例について説明する。
　図２２、図２３に示す例は、ＨＴＴＰヘッダに後続するパケット領域に新たな拡張ヘッダを挿入し、この拡張ヘッダに付加情報を記録した例である。

　図２２には、
　拡張ヘッダに記録する付加情報のリストを示しており、図２３には、拡張ヘッダを有する３種類のＨＴＴＰパケットの例を示している。
　図２３には、
　（１）初期化セグメントＨＴＴＰパケット、
　（２）メディアセグメントベースのメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット、
　（３）メディアセグメントベースのメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット、
　これらの３種類のＨＴＴＰパケットの例を示している。
　各パケットのＨＴＴＰヘッダの次に拡張ヘッダを設定している。

　この拡張ヘッダに、図２２に示すリストに従った付加情報を記録する。記録する付加情報の例について、図２２を参照して説明する。図２２に示すように付加情報は以下の情報から構成される。
　（ａ）セグメント識別情報（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ　Ｓｅｇｍｅｎｔ　Ｉｄｅｎｔｉｆｉｅｒ）、
　（ｂ）ＧＯＰ内位置識別情報（Ｓｕｂ　ＧＯＰ　Ｉｎｄｉｃａｔｏｒ）、
　（ｃ）ムービーフラグメントシーケンス番号（Ｍｏｖｉｅ　Ｆｒａｇｍｅｎｔ　Ｓｅｑｕｅｎｃｅ　Ｎｕｍｂｅｒ）、
　（ｄ）ＮＡＬユニットフラグメントヘッダ（ＮＡＬＵ　Ｆｒａｇｍｅｎｔ　Ｓｕｂ　Ｓｅｇｍｅｎｔ　Ｈｅａｄｅｒ）、
　（ｅ）ＮＡＬユニット内位置識別情報（ＮＡＬＵ　Ｆｒａｇｍｅｎｔ　Ｉｄｅｎｔｉｆｉｅｒ）
　（ｆ）アクセスポイント情報（ＳＡＰＩｎｄｉｃａｔｏｒ）

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

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

　（ｃ）ムービーフラグメントシーケンス番号は、３２ビットデータとし、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号を記録する。サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。

　（ｄ）ＮＡＬユニットフラグメントヘッダは、８ビットデータとしテ、メタデータ格納型ＮＡＬユニットフラグメント対応パケット＝１、その他のパケット＝０として記録する。

　（ｅ）ＮＡＬユニット内位置識別情報は、８ビットデータとして、パケットに格納したＮＡＬユニットフラグメント（ＮＡＬｆ）が、分割前のＮＡＬユニットのどの位置に対応するフラグメントであるかを示す情報を記録する。
　分割前のＮＡＬユニットの先頭位置（ＳｔａｒＮＡＬＵｎｉｔＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ）＝１、
　分割前のＮＡＬユニットの中間位置（ＭｉｄｄｌｅＮＡＬＵｎｉｔＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ）＝２、
　分割前のＮＡＬユニットの末尾位置（ＥｎｄＮＡＬＵｎｉｔＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ）＝３、
　この設定で各ビット値を記録する。

　（ｆ）アクセスポイント情報（ＳＡＰＩｎｄｉｃａｔｏｒ）は、ＨＴＴＰヘッダの記録情報として説明した［Ｘ－ＳＡＰ］と同様のデータであり、８ビットデータとする。パケットが、アクセスポイントを含むＮＡＬユニット格納セグメントから生成したパケットである場合は［１］、その他のパケットである場合は［０］を記録する。

　図２３には、
　（１）初期化セグメントＨＴＴＰパケット、
　（２）メディアセグメントベースのメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット、
　（３）メディアセグメントベースのメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット、
　これらの３種類のＨＴＴＰパケットの拡張ヘッダに、図２２に示す（ａ）～（ｆ）の各付加情報を設定した例を示している。

　送信装置は、このような拡張ヘッダを設定して受信装置に送信する。一方、受信装置は、この拡張ヘッダのセグメント識別情報を参照して、パケットに格納されたセグメントが初期化セグメントを格納したＨＴＴＰパケットであるか、メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであるか、メディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであるかを判別する。

　さらに、受信装置は、パケットがメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであると識別した場合、拡張ヘッダのＧＯＰ内位置識別情報や、ＮＡＬユニット内位置識別情報を参照することで、各ＮＡＬユニットフラグメント（ＮＡＬｆ）の再配列、さらにＧＯＰの再構築を行うことが可能となる。

　さらに、アクセスポイント情報（ＳＡＰＩｎｄｉｃａｔｏｒ）を参照することで、パケットが、アクセスポイントを含むＮＡＬユニット格納セグメントから生成したパケットであるか否かを判定することができる。

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

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

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

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

　同様に、ＮＡＬユニットフラグメント（ＮＡＬｆ）の配列情報についても上記のＴＯＩを参照して、データ送信順を確認して再配列を行うことが可能である。例えばＨＴＴＰヘッダ等に記録する付加情報であるＮＡＬユニット内位置識別情報を、先頭位置のＮＡＬユニットフラグメントを格納したパケットのみ、ＨＴＴＰヘッダに記録する。後続のＮＡＬユニットフラグメント配列は、ＬＣＴヘッダのＴＯＩからパケットシーケンスを解析して配列することが可能である。

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

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

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

　図２５（２）に示す記録情報の長さが固定されたフォーマットを利用して、ＮＡＬユニットフラグメントの再配列や、ＧＯＰ再構成処理に適用する情報等、受信装置側における処理をスムーズに実行させるための付加情報を記録する場合の記録データの構成例を図２６に示す。

　図２６に示すように、
　（ａ）拡張ヘッダ識別情報（ＨＥＴ）は、８ビットデータとして、新たな情報の識別値として、例えば［２００］を記録する。
　さらに、拡張情報記録部（ＨＥＣ）に、
　（ｂ）セグメント識別情報、
　（ｃ）ＧＯＰ内位置識別情報、
　（ｄ）ムービーフラグメントシーケンス番号、
　（ｅ）ＮＡＬユニットフラグメントヘッダ、
　（ｆ）ＮＡＬユニット内位置識別情報、
　（ｇ）アクセスポイント情報
　これらの各識別情報を記録する。

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

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

　（ｄ）ムービーフラグメントシーケンス番号は、３２ビットデータとし、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号を記録する。サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。

　（ｅ）ＮＡＬユニットフラグメントヘッダは、８ビットデータとしテ、メタデータ格納型ＮＡＬユニットフラグメント対応パケット＝１、その他のパケット＝０として記録する。

　（ｆ）ＮＡＬユニット内位置識別情報は、８ビットデータとして、パケットに格納したＮＡＬユニットフラグメント（ＮＡＬｆ）が、分割前のＮＡＬユニットのどの位置に対応するフラグメントであるかを示す情報を記録する。
　分割前のＮＡＬユニットの先頭位置（ＳｔａｒＮＡＬＵｎｉｔＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ）＝１、
　分割前のＮＡＬユニットの中間位置（ＭｉｄｄｌｅＮＡＬＵｎｉｔＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ）＝２、
　分割前のＮＡＬユニットの末尾位置（ＥｎｄＮＡＬＵｎｉｔＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ）＝３、
　この設定で各ビット値を記録する。

　（ｇ）アクセスポイント情報（ＳＡＰＩｎｄｉｃａｔｏｒ）は、ＨＴＴＰヘッダの記録情報として説明した［Ｘ－ＳＡＰ］と同様のデータであり、８ビットデータとする。パケットが、アクセスポイントを含むＮＡＬユニット格納セグメントから生成したパケットである場合は［１］、その他のパケットである場合は［０］を記録する。

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

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

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

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

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

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

　図２７に示すように、ＨＥＶＣ符号化処理によって生成される符号化データにも符号化処理単位としてのＧＯＰが設定され、このＧＯＰは、さらに複数のＮＡＬユニットに分割される。
　先に図５を参照して説明したサブＧＯＰメディアセグメントに、ＨＥＶＣ符号化データにおいて設定されるＧＯＰ構成データであるＮＡＬユニットを１つ、または複数、格納する構成とする。

　さらに、先に図１６他を参照して説明したようにＮＡＬユニットをさらに分割したＮＡＬユニットフラグメント（ＮＡＬｆ）を生成して、ＨＴＴＰパケットに分割格納することが可能である。

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

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

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

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

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

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

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

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

　なお、本明細書において開示した技術は、以下のような構成をとることができる。
　（１）　符号化データを格納したパケットを生成するデータ処理部と、
　前記データ処理部の生成したパケットを送信する通信部を有し、
　前記データ処理部は、
　符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、
　パケットに対する付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定したパケットを生成して前記通信部を介して送信する通信装置。

　（２）前記アクセスポイント情報は、パケット格納データが、ＳＡＰ（Ｓｔｒｅｅｍｉｎｇ　Ａｃｃｅｓｓ　Ｐｏｉｎｔ）によって指定される符号化データを含むＮＡＬユニットに基づいて生成されたデータであるか否かを示す情報である前記（１）に記載の通信装置。

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

　（４）前記データ処理部は、ＧＯＰを構成するＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを生成して、ＮＡＬユニットフラグメントを格納した複数のパケットと、前記ＮＡＬユニットに対応するメタデータを格納したパケットを生成する前記（１）または（２）に記載の通信装置。

　（５）前記データ処理部は、送信対象の符号化データを、通信経路上で規定される最大データ転送単位（ＭＴＵ：Ｍａｘｉｍｕｍ　Ｔｒａｎｓｆｅｒ　Ｕｎｉｔ）以下のデータに分割して生成した分割データを格納したパケットを生成する前記（１）～（４）いずれかに記載の通信装置。

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

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

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

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

　（１０）送信装置が送信した符号化データ格納パケットを受信する通信部と、
　前記通信部の受信したパケットを入力して処理を実行するデータ処理部を有し、
　前記通信部の受信する前記符号化データ格納パケットの各々は、
　符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットであり、付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報が設定されたパケットである通信装置。

　（１１）前記データ処理部は、
　受信パケットに記録された付加情報である前記アクセスポイント情報を参照して、受信パケットに格納されたデータが、ＳＡＰ（Ｓｔｒｅｅｍｉｎｇ　Ａｃｃｅｓｓ　Ｐｏｉｎｔ）によって指定される符号化データを含むＮＡＬユニットに基づいて生成されたデータであるか否かを判定する処理を実行する前記（１０）に記載の通信装置。

　（１２）前記データ処理部は、受信パケットに記録された付加情報である前記アクセスポイント情報を参照して、アクセスポイントを含むデータを選択取得して、復号、再生処理を実行する前記（１０）または（１１）に記載の通信装置。

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

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

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

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

　（１７）データ送信装置において実行する通信データ生成方法であり、
　データ処理部が、
　符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、
　パケットに対する付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定したパケットを生成して通信部を介して送信する通信データ生成方法。

　（１８）データ受信装置において実行する通信データ処理方法であり、
　通信部が、送信装置が送信した符号化データ格納パケットを受信するステップと、
　データ処理部が、前記通信部の受信したパケットを入力して処理を実行するデータ処理ステップを実行し、
　前記通信部の受信する前記符号化データ格納パケットの各々は、
　符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットであり、付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報が設定されたパケットであり、
　前記データ処理ステップは、前記通信部の受信したアクセスポイント情報が設定されたパケットを入力して処理を実行するステップである通信データ処理方法。

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

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

　以上、説明したように、本開示の一実施例の構成によれば、通信パケットの格納符号化データが、ランダムアクセス可能な符号化データに基づくデータであるか否かをパケット単位で判別可能とした構成が実現される。
　具体的には、送信装置が、符号化データの構成要素であるＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、付加情報として、パケット格納データの元データであるＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定して送信する。受信装置はパケット付加情報を参照してパケット格納データが、ランダムアクセス可能な符号化データに基づいて生成されたデータであるか否かを判別する。
　本構成により、通信パケットの格納符号化データが、ランダムアクセス可能な符号化データに基づくデータであるか否かをパケット単位で判別可能とした構成が実現される。

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

Claims

　符号化データを格納したパケットを生成するデータ処理部と、
　前記データ処理部の生成したパケットを送信する通信部を有し、
　前記データ処理部は、
　符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、
　パケットに対する付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定したパケットを生成して前記通信部を介して送信する通信装置。
　前記アクセスポイント情報は、パケット格納データが、ＳＡＰ（Ｓｔｒｅｅｍｉｎｇ　Ａｃｃｅｓｓ　Ｐｏｉｎｔ）によって指定される符号化データを含むＮＡＬユニットに基づいて生成されたデータであるか否かを示す情報である請求項１に記載の通信装置。
　前記データ処理部は、
　ＧＯＰの構成データであるＮＡＬユニットを１つ以上含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成する請求項１に記載の通信装置。
　前記データ処理部は、
　ＧＯＰを構成するＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを生成して、ＮＡＬユニットフラグメントを格納した複数のパケットと、前記ＮＡＬユニットに対応するメタデータを格納したパケットを生成する請求項１に記載の通信装置。
　前記データ処理部は、
　送信対象の符号化データを、通信経路上で規定される最大データ転送単位（ＭＴＵ：Ｍａｘｉｍｕｍ　Ｔｒａｎｓｆｅｒ　Ｕｎｉｔ）以下のデータに分割して生成した分割データを格納したパケットを生成する請求項１に記載の通信装置。
　前記データ処理部は、
　ＨＴＴＰパケットを生成し、前記付加情報を生成パケット内のＨＴＴＰヘッダに記録する請求項１に記載の通信装置。
　前記データ処理部は、
　前記付加情報を生成パケット内の拡張ヘッダに記録する請求項１に記載の通信装置。
　前記データ処理部は、
　前記付加情報を生成パケット内のＬＣＴヘッダに記録する請求項１に記載の通信装置。
　前記通信部は、
　前記データ処理部の生成したパケットを、放送波を介してブロードキャスト配信、またはマルチキャスト配信する請求項１に記載の通信装置。
　送信装置が送信した符号化データ格納パケットを受信する通信部と、
　前記通信部の受信したパケットを入力して処理を実行するデータ処理部を有し、
　前記通信部の受信する前記符号化データ格納パケットの各々は、
　符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットであり、付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報が設定されたパケットである通信装置。
　前記データ処理部は、
　受信パケットに記録された付加情報である前記アクセスポイント情報を参照して、受信パケットに格納されたデータが、ＳＡＰ（Ｓｔｒｅｅｍｉｎｇ　Ａｃｃｅｓｓ　Ｐｏｉｎｔ）によって指定される符号化データを含むＮＡＬユニットに基づいて生成されたデータであるか否かを判定する処理を実行する請求項１０に記載の通信装置。
　前記データ処理部は、
　受信パケットに記録された付加情報である前記アクセスポイント情報を参照して、アクセスポイントを含むデータを選択取得して、復号、再生処理を実行する請求項１０に記載の通信装置。
　前記通信部は、
　前記付加情報をＨＴＴＰヘッダに記録したＨＴＴＰパケットを受信し、
　前記データ処理部は、
　受信パケットのＨＴＴＰヘッダから前記付加情報を取得する請求項１０に記載の通信装置。
　前記通信部は、
　前記付加情報を拡張ヘッダに記録したパケットを受信し、
　前記データ処理部は、
　受信パケットの拡張ヘッダから前記付加情報を取得する請求項１０に記載の通信装置。
　前記通信部は、
　前記付加情報をＬＣＴヘッダに記録したパケットを受信し、
　前記データ処理部は、
　受信パケットのＬＣＴヘッダから前記付加情報を取得する請求項１０に記載の通信装置。
　前記通信部は、
　前記パケットを、放送波を介して受信する請求項１０に記載の通信装置。
　データ送信装置において実行する通信データ生成方法であり、
　データ処理部が、
　符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、
　パケットに対する付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定したパケットを生成して通信部を介して送信する通信データ生成方法。
　データ受信装置において実行する通信データ処理方法であり、
　通信部が、送信装置が送信した符号化データ格納パケットを受信するステップと、
　データ処理部が、前記通信部の受信したパケットを入力して処理を実行するデータ処理ステップを実行し、
　前記通信部の受信する前記符号化データ格納パケットの各々は、
　符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットであり、付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報が設定されたパケットであり、
　前記データ処理ステップは、前記通信部の受信したアクセスポイント情報が設定されたパケットを入力して処理を実行するステップである通信データ処理方法。