(57)【要約】【課題】通信パケットの格納符号化データが、ランダムアクセス可能な符号化データに基づくデータであるか否かをパケット単位で判別可能とした構成を提供する。【解決手段】送信装置が、符号化データの構成要素であるＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、付加情報として、パケット格納データの元データであるＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定して送信する。受信装置はパケット付加情報を参照してパケット格納データが、ランダムアクセス可能な符号化データに基づいて生成されたデータであるか否かを判別する。【選択図】図１３
2015136059.tif 000002
【特許請求の範囲】
【請求項１】
符号化データを格納したパケットを生成するデータ処理部と、
前記データ処理部の生成したパケットを送信する通信部を有し、
前記データ処理部は、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、
パケットに対する付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定したパケットを生成して前記通信部を介して送信する通信装置。
【請求項２】
前記アクセスポイント情報は、パケット格納データが、ＳＡＰ（Ｓｔｒｅｅｍｉｎｇ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）によって指定される符号化データを含むＮＡＬユニットに基づいて生成されたデータであるか否かを示す情報である請求項１に記載の通信装置。
【請求項３】
前記データ処理部は、
ＧＯＰの構成データであるＮＡＬユニットを１つ以上含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成する請求項１に記載の通信装置。
【請求項４】
前記データ処理部は、
ＧＯＰを構成するＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを生成して、ＮＡＬユニットフラグメントを格納した複数のパケットと、前記ＮＡＬユニットに対応するメタデータを格納したパケットを生成する請求項１に記載の通信装置。
【請求項５】
前記データ処理部は、
送信対象の符号化データを、通信経路上で規定される最大データ転送単位（ＭＴＵ：Ｍａｘｉｍｕｍ  Ｔｒａｎｓｆｅｒ  Ｕｎｉｔ）以下のデータに分割して生成した分割データを格納したパケットを生成する請求項１に記載の通信装置。
【請求項６】
前記データ処理部は、
ＨＴＴＰパケットを生成し、前記付加情報を生成パケット内のＨＴＴＰヘッダに記録する請求項１に記載の通信装置。
【請求項７】
前記データ処理部は、
前記付加情報を生成パケット内の拡張ヘッダに記録する請求項１に記載の通信装置。
【請求項８】
前記データ処理部は、
前記付加情報を生成パケット内のＬＣＴヘッダに記録する請求項１に記載の通信装置。
【請求項９】
前記通信部は、
前記データ処理部の生成したパケットを、放送波を介してブロードキャスト配信、またはマルチキャスト配信する請求項１に記載の通信装置。
【請求項１０】
送信装置が送信した符号化データ格納パケットを受信する通信部と、
前記通信部の受信したパケットを入力して処理を実行するデータ処理部を有し、
前記通信部の受信する前記符号化データ格納パケットの各々は、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットであり、付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報が設定されたパケットである通信装置。
【請求項１１】
前記データ処理部は、
受信パケットに記録された付加情報である前記アクセスポイント情報を参照して、受信パケットに格納されたデータが、ＳＡＰ（Ｓｔｒｅｅｍｉｎｇ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）によって指定される符号化データを含むＮＡＬユニットに基づいて生成されたデータであるか否かを判定する処理を実行する請求項１０に記載の通信装置。
【請求項１２】
前記データ処理部は、
受信パケットに記録された付加情報である前記アクセスポイント情報を参照して、アクセスポイントを含むデータを選択取得して、復号、再生処理を実行する請求項１０に記載の通信装置。
【請求項１３】
前記通信部は、
前記付加情報をＨＴＴＰヘッダに記録したＨＴＴＰパケットを受信し、
前記データ処理部は、
受信パケットのＨＴＴＰヘッダから前記付加情報を取得する請求項１０に記載の通信装置。
【請求項１４】
前記通信部は、
前記付加情報を拡張ヘッダに記録したパケットを受信し、
前記データ処理部は、
受信パケットの拡張ヘッダから前記付加情報を取得する請求項１０に記載の通信装置。
【請求項１５】
前記通信部は、
前記付加情報をＬＣＴヘッダに記録したパケットを受信し、
前記データ処理部は、
受信パケットのＬＣＴヘッダから前記付加情報を取得する請求項１０に記載の通信装置。
【請求項１６】
前記通信部は、
前記パケットを、放送波を介して受信する請求項１０に記載の通信装置。
【請求項１７】
データ送信装置において実行する通信データ生成方法であり、
データ処理部が、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、
パケットに対する付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定したパケットを生成して通信部を介して送信する通信データ生成方法。
【請求項１８】
データ受信装置において実行する通信データ処理方法であり、
通信部が、送信装置が送信した符号化データ格納パケットを受信するステップと、
データ処理部が、前記通信部の受信したパケットを入力して処理を実行するデータ処理ステップを実行し、
前記通信部の受信する前記符号化データ格納パケットの各々は、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットであり、付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報が設定されたパケットであり、
前記データ処理ステップは、前記通信部の受信したアクセスポイント情報が設定されたパケットを入力して処理を実行するステップである通信データ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、通信装置、通信データ生成方法、および通信データ処理方法に関する。さらに詳細には例えば放送波やネットワークを介したデータの送信または受信を実行する通信装置、通信データ生成方法、および通信データ処理方法に関する。
【背景技術】
【０００２】
画像データや音声データ等のコンテンツを各通信事業者のサービス形態に関わらず配信可能としたデータ配信方式としてＯＴＴ（Ｏｖｅｒ  Ｔｈｅ  Ｔｏｐ）が知られている。ＯＴＴによる配信コンテンツはＯＴＴコンテンツと呼ばれ、また、ＯＴＴを利用した画像（ビデオ）データの配信サービスはＯＴＴビデオやＯＴＴ−Ｖ（Ｏｖｅｒ  Ｔｈｅ  Ｔｏｐ  Ｖｉｄｅｏ）と呼ばれる。
【０００３】
例えばＯＴＴ−Ｖに従ったデータストリーミング配信の基盤技術としてＤＡＳＨ（Ｄｙｎａｍｉｃ  Ａｄａｐｔｉｖｅ  Ｓｔｒｅａｍｉｎｇ  ｏｖｅｒＨＴＴＰ）が利用される。ＤＡＳＨは、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）プロトコルを使用したアダプティブ（適応型）ストリーミング技術の標準規格である。
【０００４】
アダプティブ（適応型）ストリーミングでは、コンテンツ配信サーバは様々なクライアントで配信コンテンツの再生を可能とするため、複数のビットレートの動画コンテンツの細分化ファイルとこれらの属性情報やＵＲＬを記述したマニフェスト・ファイルを作成し保持する。
【０００５】
クライアントは、マニフェスト・ファイルをサーバから取得して、自装置の表示部のサイズや利用可能な通信帯域に応じた最適なビットレートコンテンツを選択し、選択コンテンツを受信して再生する。ネットワーク帯域の変動に応じてビットレートの動的な変更も可能であり、クライアント側では、状況に応じた最適なコンテンツを随時切り替えて受信することが可能となり、映像途切れの発生を低減した動画コンテンツ再生が実現される。なお、アダプティブ（適応型）ストリーミングについては、例えば特許文献１（特開２０１１−８７１０３号公報）に記載がある。
【０００６】
ＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）符号化された動画や音声データを上記のＤＡＳＨに従ってストリーミング配信するための仕様を定めた規格としてＭＰＥＧ−ＤＡＳＨ規格がある。
ＭＰＥＧ−ＤＡＳＨ規格には、以下の２つの規格が含まれる。
（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格。
（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格。
ＭＰＥＧデータをＤＡＳＨに従ってストリーミング配信する場合は、このＭＰＥＧ−ＤＡＨ規格に従った処理が行われる。
【０００７】
しかし、アダプティブ（適応型）ストリーミング技術の標準規格であるＤＡＳＨは１対１の通信処理であるポイントトゥーポイント（Ｐｏｉｎｔ−ｔｏ−ｐｏｉｎｔ）型のＨＴＴＰストリーミング技術をベースとしている。
このため、例えばスポーツ中継等、多数のクライアントが同時に視聴する可能性のあるコンテンツ（番組）のストリーミング配信に適用する場合にはＣＤＮ（Ｃｏｎｔｅｎｔ  Ｄｅｌｉｖｅｒｙ  Ｎｅｔｗｏｒｋ）のサポートが必要となる。
【０００８】
しかし、ＣＤＮを適用したポイントトゥーポイントのＨＴＴＰストリーミングを構築するにはコスト的な制約があり、放送配信に匹敵する程のスケーラビリティを実現することは困難である。上述したようにＤＡＳＨはＨＴＴＰをベースのストリーミングプロトコルを利用しており、放送配信のように多数のクライアントが同時に視聴するコンテンツ配信には不向きであるという問題がある。
【先行技術文献】
【特許文献】
【０００９】
【特許文献１】特開２０１１−８７１０３号公報
【発明の概要】
【発明が解決しようとする課題】
【００１０】
本開示は、ＨＴＴＰをベースとするストリーミングプロトコルを利用したコンテンツ配信において、同時に多数のクライアントにコンテンツを提供し、各クライアントにおいて遅延の少ないリアルタイム再生を実現する通信装置、通信データ生成方法、および通信データ処理方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
本開示の第１の側面は、
符号化データを格納したパケットを生成するデータ処理部と、
前記データ処理部の生成したパケットを送信する通信部を有し、
前記データ処理部は、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、
パケットに対する付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定したパケットを生成して前記通信部を介して送信する通信装置にある。
【００１２】
さらに、本開示の通信装置の一実施態様において、前記アクセスポイント情報は、パケット格納データが、ＳＡＰ（Ｓｔｒｅｅｍｉｎｇ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）によって指定される符号化データを含むＮＡＬユニットに基づいて生成されたデータであるか否かを示す情報である。
【００１３】
さらに、本開示の通信装置の一実施態様において、前記データ処理部は、ＧＯＰの構成データであるＮＡＬユニットを１つ以上含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成する。
【００１４】
さらに、本開示の通信装置の一実施態様において、前記データ処理部は、ＧＯＰを構成するＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを生成して、ＮＡＬユニットフラグメントを格納した複数のパケットと、前記ＮＡＬユニットに対応するメタデータを格納したパケットを生成する。
【００１５】
さらに、本開示の通信装置の一実施態様において、前記データ処理部は、送信対象の符号化データを、通信経路上で規定される最大データ転送単位（ＭＴＵ：Ｍａｘｉｍｕｍ  Ｔｒａｎｓｆｅｒ  Ｕｎｉｔ）以下のデータに分割して生成した分割データを格納したパケットを生成する。
【００１６】
さらに、本開示の通信装置の一実施態様において、前記データ処理部は、ＨＴＴＰパケットを生成し、前記付加情報を生成パケット内のＨＴＴＰヘッダに記録する。
【００１７】
さらに、本開示の通信装置の一実施態様において、前記データ処理部は、前記付加情報を生成パケット内の拡張ヘッダに記録する。
【００１８】
さらに、本開示の通信装置の一実施態様において、前記データ処理部は、前記付加情報を生成パケット内のＬＣＴヘッダに記録する。
【００１９】
さらに、本開示の通信装置の一実施態様において、前記通信部は、前記データ処理部の生成したパケットを、放送波を介してブロードキャスト配信、またはマルチキャスト配信する。
【００２０】
さらに、本開示の第２の側面は、
送信装置が送信した符号化データ格納パケットを受信する通信部と、
前記通信部の受信したパケットを入力して処理を実行するデータ処理部を有し、
前記通信部の受信する前記符号化データ格納パケットの各々は、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットであり、付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報が設定されたパケットである通信装置にある。
【００２１】
さらに、本開示の通信装置の一実施態様において、前記データ処理部は、受信パケットに記録された付加情報である前記アクセスポイント情報を参照して、受信パケットに格納されたデータが、ＳＡＰ（Ｓｔｒｅｅｍｉｎｇ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）によって指定される符号化データを含むＮＡＬユニットに基づいて生成されたデータであるか否かを判定する処理を実行する。
【００２２】
さらに、本開示の通信装置の一実施態様において、前記データ処理部は、受信パケットに記録された付加情報である前記アクセスポイント情報を参照して、アクセスポイントを含むデータを選択取得して、復号、再生処理を実行する。
【００２３】
さらに、本開示の通信装置の一実施態様において、前記通信部は、前記付加情報をＨＴＴＰヘッダに記録したＨＴＴＰパケットを受信し、前記データ処理部は、受信パケットのＨＴＴＰヘッダから前記付加情報を取得する。
【００２４】
さらに、本開示の通信装置の一実施態様において、前記通信部は、前記付加情報を拡張ヘッダに記録したパケットを受信し、前記データ処理部は、受信パケットの拡張ヘッダから前記付加情報を取得する。
【００２５】
さらに、本開示の通信装置の一実施態様において、前記通信部は、前記付加情報をＬＣＴヘッダに記録したパケットを受信し、前記データ処理部は、受信パケットのＬＣＴヘッダから前記付加情報を取得する。
【００２６】
さらに、本開示の通信装置の一実施態様において、前記通信部は、前記パケットを、放送波を介して受信する。
【００２７】
さらに、本開示の第３の側面は、
データ送信装置において実行する通信データ生成方法であり、
データ処理部が、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、
パケットに対する付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定したパケットを生成して通信部を介して送信する通信データ生成方法にある。
【００２８】
さらに、本開示の第４の側面は、
データ受信装置において実行する通信データ処理方法であり、
通信部が、送信装置が送信した符号化データ格納パケットを受信するステップと、
データ処理部が、前記通信部の受信したパケットを入力して処理を実行するデータ処理ステップを実行し、
前記通信部の受信する前記符号化データ格納パケットの各々は、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットであり、付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報が設定されたパケットであり、
前記データ処理ステップは、前記通信部の受信したアクセスポイント情報が設定されたパケットを入力して処理を実行するステップである通信データ処理方法にある。
【００２９】
本開示のさらに他の目的、特徴や利点は、後述する本開示の実施例や添付する図面に基づくより詳細な説明によって明らかになるであろう。なお、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【発明の効果】
【００３０】
本開示の一実施例の構成によれば、通信パケットの格納符号化データが、ランダムアクセス可能な符号化データに基づくデータであるか否かをパケット単位で判別可能とした構成が実現される。
具体的には、送信装置が、符号化データの構成要素であるＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、付加情報として、パケット格納データの元データであるＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定して送信する。受信装置はパケット付加情報を参照してパケット格納データが、ランダムアクセス可能な符号化データに基づいて生成されたデータであるか否かを判別する。
本構成により、通信パケットの格納符号化データが、ランダムアクセス可能な符号化データに基づくデータであるか否かをパケット単位で判別可能とした構成が実現される。
なお、本明細書に記載された効果はあくまで例示であって限定されるものではなく、また付加的な効果があってもよい。
【図面の簡単な説明】
【００３１】
【図１】本開示の処理を実行する通信システムの一構成例について説明する図である。
【図２】送信装置の送信データについて説明する図である。
【図３】ＤＡＳＨセグメントの構成例について説明する図である。
【図４】フラグメント生成シーケンスについて説明する図である。
【図５】フラグメント内のメディアデータ（ｍｄａｔ）を１ＧＯＰ単位のデータではなく、１ＧＯＰを細分化したデータに設定した構成例について説明する図である。
【図６】サブＧＯＰメディアセグメントにＨＴＴＰヘッダを設定したＨＴＴＰパケットの構成例について説明する図である。
【図７】メディアセグメントＨＴＴＰパケットのＨＴＴＰヘッダの記録情報について説明する図である。
【図８】メディアセグメントＨＴＴＰパケットのＨＴＴＰヘッダの記録情報について説明する図である。
【図９】初期化セグメントＨＴＴＰパケットのＨＴＴＰヘッダの記録情報について説明する図である。
【図１０】ＩＰパケットの構成例について説明する図である。
【図１１】送信装置と受信装置のプロトコルスタックについて説明する図である。
【図１２】受信装置のプロトコルスタックについて説明する図である。
【図１３】メディアセグメントＨＴＴＰパケットのＨＴＴＰヘッダの記録情報について説明する図である。
【図１４】メディアセグメントＨＴＴＰパケットのＨＴＴＰヘッダの記録情報について説明する図である。
【図１５】ＭＡＣフレームの構成について説明する図である。
【図１６】ＮＡＬユニットフラグメント対応ＨＴＴＰパケットについて説明する図である。
【図１７】メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのＨＴＴＰヘッダに記録する付加情報について説明する図である。
【図１８】メディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのＨＴＴＰヘッダに記録する付加情報について説明する図である。
【図１９】送信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。
【図２０】受信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。
【図２１】受信装置の実行する処理シーケンスについて説明するフローチャートを示す図である。
【図２２】拡張ヘッダに記録する付加情報の例について説明する図である。
【図２３】拡張ヘッダに付加情報を記録した実施例について説明する図である。
【図２４】ＦＬＵＴＥプロトコルに従って設定されるＬＣＴヘッダの構成例について説明する図である。
【図２５】ＬＣＴヘッダのヘッダ拡張部に対するデータ記録構成について説明する図である。
【図２６】ＬＣＴヘッダのヘッダ拡張部に記録するデータについて説明する図である。
【図２７】ＨＥＶＣ符号化データの構成について説明する図である。
【図２８】通信装置のハードウェア構成例について説明する図である。
【発明を実施するための形態】
【００３２】
以下、図面を参照しながら本開示の通信装置、通信データ生成方法、および通信データ処理方法の詳細について説明する。なお、説明は以下の項目に従って行なう。
１．通信システムの構成例について
２．一斉同時配信型のコンテンツ配信における問題点について
３．送信データの細分化処理構成について
４．ＨＴＴＰヘッダに付加情報を記録した実施例について
５．パケットの構成について
６．送信装置と受信装置の構成と処理について
７．パケットに格納したＮＡＬユニットがＳＡＰ（ストリームアクセスポイント）を含むか否かを識別可能としたアクセスポイント情報を付加した構成について
８．ＮＡＬユニットをさらに分割したＮＡＬユニットフラグメント格納パケットを利用した通信処理構成について
９．送信装置と受信装置の処理シーケンスについて
１０．拡張ヘッダに付加情報を記録した実施例について
１１．ＬＣＴヘッダに付加情報を記録した実施例について
１２．ＨＥＶＣ符号化データに対する適用例について
１３．各装置のハードウェア構成例について
１４．本開示の構成のまとめ
【００３３】
［１．通信システムの構成例について］
まず、図１を参照して本開示の処理を実行する通信システムの一構成例について説明する。
図１に示すように、通信システム１０は、画像データや音声データ等のコンテンツを送信する通信装置である送信装置２０と、送信装置２０の送信コンテンツを受信する通信装置である受信装置３０を有する。
【００３４】
送信装置２０は、具体的には、例えば放送局２１やコンテンツサーバ２２等、コンテンツを提供する側の装置である。
一方、受信装置３０は、一般ユーザのクライアント装置であり、具体的には、例えばテレビ３１、ＰＣ３２、携帯端末３３等によって構成される。
【００３５】
送信装置２０と受信装置３０間のデータ通信は、インターネット等のネットワークを介した双方向通信、あるいは、放送波等による一方向通信の少なくともいずれか、あるいは両者を利用した通信として行われる。
【００３６】
送信装置２０から受信装置３０に対するコンテンツ送信は、アダプティブ（適応型）ストリーミング技術の規格であるＭＰＥＧ−ＤＡＳＨ規格に従って実行する。
先に説明したように、ＭＰＥＧ−ＤＡＳＨ規格には、以下の２つの規格が含まれる。
（ａ）動画や音声ファイルの管理情報であるメタデータを記述するためのマニフェスト・ファイル（ＭＰＤ：Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）に関する規格、
（ｂ）動画コンテンツ伝送用のファイル・フォーマット（セグメント・フォーマット）に関する規格、
送信装置２０から、受信装置３０に対するコンテンツ配信は、上記のＭＰＥＧ−ＤＡＳＨ規格に従って実行する。
【００３７】
送信装置２０は、コンテンツデータを符号化し、符号化データおよび符号化データのメタデータを含むデータファイルを生成する。符号化処理は、例えばＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマットに従って行われる。なお、送信装置２０がＭＰ４形式のデータファイルを生成する場合の符号化データのファイルは「ｍｄａｔ」、メタデータは「ｍｏｏｖ」や「ｍｏｏｆ」等と呼ばれる。
これらの符号化データの詳細については後段で説明する。
【００３８】
送信装置２０が受信装置３０に提供するコンテンツは、例えば音楽データや、映画、テレビ番組、ビデオ、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトウェアなど、様々なデータである。
【００３９】
送信装置２０の送信データについて図２を参照して説明する。
ＭＰＥＧ−ＤＡＳＨ規格に従ってデータ送信を実行する送信装置２０は、図２に示すように、初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）５０と、メディアセグメント（Ｍｅｄｉａ  Ｓｅｇｍｅｎｔ）６０を、それぞれパケットに格納して受信装置３０に送信する。これらの各セグメントはＤＡＳＨセグメントと呼ばれる。
【００４０】
メディアセグメント６０各々はＭＰＥＧ符号化されたコンテンツデータを分割して格納したセグメントである。
初期化セグメント５０はメディアセグメント６０の格納コンテンツを受信装置３０側で再生する場合に必要となる初期設定情報、例えばコーデックの設定情報などを格納したセグメントである。
なお、送信装置２０は、例えば１つの映画や番組等のコンテンツを、多数のメディアセグメント６０に分割格納して順次送信する。
【００４１】
送信装置２０は、図２に示す初期化セグメント５０、メディアセグメント６０をＨＴＴＰパケットに格納し、さらに、ＨＴＴＰパケットを格納したＩＰパケットを生成して送信する。送信パケットの構成の詳細については後段で説明する。
【００４２】
図２に示す受信装置３０は、まず、１つの初期化セグメント５０を受信し、初期化セグメントに格納された設定情報に従ってコーデック等の設定処理等を実行する。続いて、メディアセグメント６０を順次、受信し、再生順に従ってデコードを行なって再生処理を行なう。
【００４３】
［２．一斉同時配信型のコンテンツ配信における問題点について］
前述したように、アダプティブ（適応型）ストリーミング技術の標準規格であるＤＡＳＨはポイントトゥーポイントのＨＴＴＰストリーミングをベースとしており、多数のクライアントが同時に視聴する一斉同時配信型コンテンツの配信には向かないという問題がある。
しかし、マルチキャストやブロードキャスト（ＭＣ／ＢＣ）を併用することで、コンテンツを同時に多数のクライアント（受信装置）に遅延なく提供することが可能であると考えられる。
【００４４】
マルチキャストやブロードキャスト（ＭＣ／ＢＣ）型のストリーミングに適用可能なトランスポートプロトコルには、例えばＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）やＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）がある。
【００４５】
図３を参照して、ＦＬＵＴＥプロトコルを利用してＨＴＴＰストリーミングベースのＤＡＳＨ規格に従ってコンテンツストリーム配信を行う場合に利用可能なＤＡＳＨセグメントの構成例について説明する。
【００４６】
先に図２を参照して説明したように、ＤＡＳＨセグメントは、
（ａ）初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）、
（ｂ）メディアセグメント（Ｍｅｄｉａ  Ｓｅｇｍｅｎｔ）、
これらの２種類に分けられる。
【００４７】
（ａ）初期化セグメント（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ）は、受信装置３０におけるデコーダの設定等、コンテンツ再生を実行するために必要となる設定情報等の初期化データを格納したセグメントである。
（ｂ）メディアセグメント（Ｍｅｄｉａ  Ｓｅｇｍｅｎｔ）は、再生対象となる符号化コンテンツを格納したセグメントである。
【００４８】
図３に示すように（ａ）初期化セグメントは、以下の各情報を含む。
（ａ１）セグメントのファイルタイプ情報等からなるヘッダ情報（ｄａｓｈ）、
（ａ２）メディアセグメントによって送信する符号化コンテンツであるメディアデータ（ｍｄａｔ）のコーデック（符号化態様）情報等の初期化情報を含むメタデータ（ｍｏｏｖ）、
【００４９】
一方、（ｂ）メディアセグメントは、図３に示すように以下の各情報を含む。
（ｂ１）セグメントのファイルタイプ情報等からなるヘッダ情報（ｍｓｄｈ）、
（ｂ２）メディアセグメントに格納された複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）の境界情報や、メディアセグメントに格納された符号化コンテンツであるメディアデータ（ｍｄａｔ）のランダムアクセスポイント等を示すアクセス情報（ｓｉｄｘ）、
（ｂ３）複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）７０、
【００５０】
また、複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）７０は１つまたは複数のフラグメント（Ｆｒａｇｍｅｎｔ）８０で構成される。
フラグメント（Ｆｒａｇｍｅｎｔ）８０は、以下の各データを含む。
再生対象となる符号化コンテンツであるメディアデータ（ｍｄａｔ）、
メディアデータ（ｍｄａｔ）に対応するメタデータ（ｍｏｏｆ）。
【００５１】
なお、（ｂ）メディアセグメントのアクセス情報（ｓｉｄｘ）に記録されるランダムアクセスポイントは、ＤＡＳＨではＳＡＰ（Ｓｔｒｅａｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）と呼ばれる。
ＳＡＰは、例えばストリームを復号するために必要なすべての状態をリセットすることができる画像シーケンスの先頭ピクチャの先頭バイト位置を示す。具体的には、例えばＭＰＥＧデータのＩピクチャの位置等を示す情報である。
【００５２】
フラグメント（Ｆｒａｇｍｅｎｔ）８０に格納するメディアデータ（ｍｄａｔ）対応のメタデータ（ｍｏｏｆ）には、例えばフラグメント格納メディアデータ（ｍｄａｔ）の再生時間情報としてのプレゼンテーションタイム等が記録される。
【００５３】
１つのフラグメント８０に格納するメディアデータ（ｍｄａｔ）は、現行では、通常、ＤＡＳＨの制御対象となるコンテンツストリームの処理単位（チャンク）に設定される。処理単位（チャンク）とは、例えばＭＰＥＧ（Ｍｏｖｉｎｇ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）符号化の処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）である。
なお、ＧＯＰは再生時間が約０．５〜２秒程度のデータに設定して運用している場合が多い。
【００５４】
しかし、１つのフラグメント８０に格納するメディアデータ（ｍｄａｔ）を１つのＧＯＰ単位のデータとすると、データ配信や再生処理における遅延が発生し、リアルタイム再生に支障が発生する可能性がある。
例えば、ライブ中継画像を配信する場合、送信装置２０は、カメラから入力するライブ画像データの符号化処理を実行してメディアセグメント６０を順次生成する。メディアセグメント６０の各フラグメント８０に格納するメディアデータ（ｍｄａｔ）がＧＯＰ単位の符号化データである場合、送信装置３０は、ＧＯＰ単位の符号化データであるメディアデータ（ｍｄａｔ）を生成し、その後、生成したメディアデータ（ｍｄａｔ）のプレゼンテーションタイム等の属性情報を記述したメタデータ（ｍｏｏｆ）を生成することになる。
【００５５】
従って、このシーケンスで各データの生成を行うと、各ＧＯＰ単位の符号化データのデータ範囲が決定された後でないと、そのＧＯＰのメタデータ（ｍｏｏｆ）の生成ができない。
従って、メタデータ（ｍｏｏｆ）の生成は、メディアデータ（ｍｄａｔ）のデータ範囲が決定後に行うことになり、各メタデータ（ｍｏｏｆ）の生成処理は、１つのＧＯＰ単位の時間（０．５〜２秒）に相当する時間を待って行わざる得ないことになる。
【００５６】
メディアセグメント６０を構成するフラグメント８０に格納するメディアデータ（ｍｄａｔ）をＧＯＰ単位の符号化データとした場合のフラグメント生成シーケンスについて図４を参照して説明する。
【００５７】
なお、図４に示す例は、メディアセグメント６０に格納するメディアデータ（ｍｄａｔ）をＭＰＥＧにおいて規定されるＭＰ４ファイルフォーマット（符号化形式）に従って格納する場合のシーケンス例である。
ＭＰ４ファイルフォーマットのデータ部は、基本格納単位としてのサンプル（ｓａｍｐｌｅ）に区分される。さらに各サンプル（ｓａｍｐｌｅ）は、１以上のＮＡＬユニットによって構成される。ＮＡＬユニットは、ＭＰＥＧ符号化データの例えばスライス単位の細分化データである。
図４（ａ）に示すように複数の１つのＧＯＰに対応する符号化データは複数のＮＡＬユニットによって構成される。
【００５８】
図４には、
上段に（ａ）ＧＯＰを構成するＮＡＬユニット
下段に（ｂ）フラグメント生成処理シーケンス
これらを示している。
（ｂ）フラグメント生成処理シーケンスの最下段には時間軸を示している。左から右に時間が経過し、送信装置２０は、この時間軸に従って、各処理を実行してフラグメントを生成する。
なお、送信装置は、生成したフラグメントを格納したメディアセグメントを生成し、その後、メディアセグメントを格納したＨＴＴＰパケットを生成し、さらにＨＴＴＰパケットを格納したＩＰパケットを生成した後、ＩＰパケットの送信を行う。
【００５９】
図４（ｂ）に示すフラグメント生成処理シーケンスについて説明する。
送信装置２０は、以下のシーケンスでＭＰ４ファイルフォーマットに従った符号化データを格納したフラグメントを生成する。
時間ｔ０〜ｔ１：ＧＯＰを構成する複数のＮＡＬユニットを格納したサンプル１（ｓａｍｐｌｅ１）を生成、
時間ｔ２〜ｔ３：ＧＯＰを構成する複数のＮＡＬユニットを格納したサンプル２（ｓａｍｐｌｅ２）を生成、
時間ｔ４〜ｔ５：ＧＯＰを構成する複数のＮＡＬユニットを格納したサンプル３（ｓａｍｐｌｅ３）を生成、
ここまでで、１ＧＯＰを構成する全てのＮＡＬユニットを格納したサンプルの生成が完了する。
これらのサンプル１〜３（ｓａｍｐｌｅ１〜３）がメディアセグメントのフラグメント内のメディアデータ（ｍｄａｔ）として設定されることになる。
【００６０】
時間ｔ６〜ｔ７：サンプル１〜３（ｓａｍｐｌｅ１〜３）に格納したＧＯＰ符号化データの属性情報であるメタデータ（ｍｏｏｆ）を生成する。
時間ｔ８〜ｔ９：サンプル１〜３（ｓａｍｐｌｅ１〜３）によって構成されるメディアデータ（ｍｄａｔ）と、サンプル１〜３（ｓａｍｐｌｅ１〜３）のメタデータ（ｍｏｏｆ）を組み合わせたフラグメントを生成する。
【００６１】
送信装置２０は、その後、上述した処理に従って生成したフラグメントを含むメディアセグメントを生成し、メディアセグメントをペイロードとして含むパケットを生成して受信装置３０に送信することになる。
送信装置２０は、フラグメントを生成する場合、フラグメントに格納するＧＯＰ単位のメディアデータ（ｍｄａｔ）の再生時間等を確認し、その再生時間に応じたプレゼンテータションタイム等、ＧＯＰデータ単位の属性情報を生成して、メタデータ（ｍｏｏｆ）に記録する必要がある。
【００６２】
現在、データ配信される画像データは主にハイビジョン対応の画像データであるが、今後、さらに高画質化が進み、例えば４Ｋ画像等、データ量の多いデータ配信が増加すると予想される。このような大容量のデータ配信に対応するためストリームのビットレートが大きくなる可能性がある。
【００６３】
高画質化によるデータ量の増大に従って各ＧＯＰ単位のデータ量も増大する。従って、図４を参照して説明したように１つのＧＯＰ単位のフラグメントを順次、生成して送信する構成とすると、送信側での処理間隔が長くなる。また、送信データの単位当たりデータ量も大きくなる。従って、十分な通信帯域が確保できない場合、ネットワーク送信における送信遅延の発生可能性が増加する。
【００６４】
また、受信装置側でのパケット受信間隔が長くなり、１パケットあたりのデータ受信量が増加し、受信装置側に要求されるデータバッファ量も増加する。また、パケットの受信エラーが発生した場合の再送処理を行なうと、遅延量が急激に大きくなり、リアルタイム再生が破たんする可能性が高くなる。
【００６５】
［３．送信データの細分化処理構成について］
上記の問題を解決するため、送信装置２０から受信装置３０に対する送信データを細分化し、１つの送信パケット、すなわち一単位あたりの送信データ量を削減した構成例について、以下説明する。
【００６６】
図４を参照したフラグメント生成シーケンスにおいては、フラグメントに設定するメディアデータ（ｍｄａｔ）を１ＧＯＰ単位のデータとし、この１ＧＯＰ単位のメディアデータ（ｍｄａｔ）に対応するメタデータ（ｍｏｏｆ）を生成する構成としていた。すなわち、各メタデータ（ｍｏｏｆ）を、１ＧＯＰ単位のメディアデータ（ｍｄａｔ）に対応したメタデータとしていた。
【００６７】
図４に示すシーケンスでは、メタデータ（ｍｏｏｆ）の生成タイミングは、１つのＧＯＰのデータ量に応じて決定されてしまう。従って１ＧＯＰに含まれるデータ量が多くなると、メタデータ（ｍｏｏｆ）の生成タイミングも遅れ、その結果、フラグメントの生成処理、メディアセグメントの生成処理、送信パケットの生成処理にも遅れが発生する。また、この結果１パケット当たりのデータ量が増加し、配信遅延の可能性を高めてしまうことになる。
【００６８】
このような事態を防止する構成として、フラグメント内のメディアデータ（ｍｄａｔ）を１ＧＯＰ単位のデータではなく、１ＧＯＰを細分化したデータに設定した構成例について、図５を参照して説明する
【００６９】
図５には、フラグメントに格納するメディアデータ（ｍｄａｔ）を１つのＧＯＰデータではなく、１つのＧＯＰデータを細分化したデータ、具体的には１つのＧＯＰの構成データである１つのＮＡＬユニットまたは複数のＮＡＬユニットとした例を示している。
【００７０】
図５（ａ）は、図４（ａ）と同様、ＧＯＰを構成するＮＡＬユニットを示している。
図５（ｂ１）〜（ｂ３）は、この１つのＧＯＰの構成データであるＮＡＬユニットをメディアデータ（ｍｄａｔ）として分散させて格納した複数のメディアセグメントである。
図５（ｂ１）〜（ｂ３）に示すようにＧＯＰデータを細分化データである１以上のＮＡＬユニットから構成されるメディアデータ（ｍｄａｔ）を格納したメディアセグメントを、以下、サブＧＯＰメディアセグメントと呼ぶ。
【００７１】
図５には、１つのＧＯＰデータを３つのサブＧＯＰメディアセグメントに格納した例を示しているが、１つのＧＯＰデータを格納するためのサブＧＯＰメディアセグメントの数は、２以上の任意数に設定可能である。
また、図５（ｂ１）〜（ｂ３）のサブＧＯＰメディアセグメントは、いずれもメディアデータ（ｍｄａｔ）を複数のＮＡＬユニットに設定した例としているが、メディアデータ（ｍｄａｔ）を１つのＮＡＬユニットのみの設定としてもよい。
【００７２】
送信装置２０は、図５（ｂ１）〜（ｂ３）に示すサブＧＯＰメディアセグメントを生成し、生成したサブＧＯＰメディアセグメントの各々を、それぞれ個別のＨＴＴＰパケットのペイロードに設定してネットワークや放送波を介して送信する。
【００７３】
図５（ｂ１）〜（ｂ３）のサブＧＯＰメディアセグメントに格納するメタデータ（ｍｏｏｆ）は、個々のサブＧＯＰメディアセグメントに格納するメディアデータ（ｍｄａｔ）に対応した属性情報からなるメタデータとする。
このような設定とすることで、ネットワークや放送波を介して送信される１つのパケットのデータ量が小さくなり、送信装置側の１つのパケット生成処理に要する時間が短縮される。またパケット遅延の可能性も低減し、パケットロス等の際の再送処理遅延も小さくなる。結果として、受信装置３０におけるエラーのないリアルタイム再生が実現される。
【００７４】
サブＧＯＰメディアセグメントにＨＴＴＰヘッダを設定したＨＴＴＰパケットの構成例について、図６を参照して説明する。
図６には２つのＨＴＴＰパケット構成例を示している。
図６の（ａ）と（ｂ）に示すパケットの差異は、ランダムアクセス情報等を格納する［ｓｉｄｘ］を有するか否かである。
ｓｉｄｘは、先に図３を参照して説明したように、メディアセグメントに格納された複数のサブセグメント（Ｓｕｂ−Ｓｅｇｍｅｎｔ）の境界情報や、メディアセグメントに格納された符号化コンテンツであるメディアデータ（ｍｄａｔ）のランダムアクセスポイント等を示すアクセス情報である。ＤＡＳＨではアクセス情報はＳＡＰ（Ｓｔｒｅａｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）と呼ばれる。ＳＡＰは、例えばストリームを復号するために必要なすべての状態をリセットすることができる画像シーケンスの先頭ピクチャの先頭バイト位置を示す。具体的には、例えばＭＰＥＧデータのＩピクチャ位置に相当する。
【００７５】
図６（ｂ）に示すＨＴＴＰパケットは、ｓｉｄｘを含まないパケットである。図６（ｂ）に示すＨＴＴＰパケットは、このパケットに格納されたメディアデータ（ｍｄａｔ）にアクセスポイントとなるピクチャデータを含まない。
パケット格納メディアデータ（ｍｄａｔ）にアクセスポイントとなるデータを含まない場合、アクセスポイントを示すデータも不要となる。従って図６（ｂ）に示すＨＴＴＰパケットにはｓｉｄｘが設定されていない。
一方、アクセスポイントとなるデータを含むメディアデータ（ｍｄａｔ）を格納したサブＧＯＰメディアセグメントを有するパケットには、図６（ａ）に示すようにｓｉｄｘが設定される。
【００７６】
図５〜図６を参照して説明したように、本実施例では、１つのＧＯＰ構成データを複数のパケットに分割して送信する。
受信装置３０は、これらの複数のパケットを順次、受信し、各パケットに分割して格納されたＧＯＰ構成データを取得する。ＧＯＰ単位の復号処理を行なう場合は、複数のパケットに格納されたＧＯＰ構成データを全て集めて、ＧＯＰの構成データ（ＮＡＬユニット）を正しい順序に並べてＧＯＰデータを再構成することが必要となる。
以下、ＧＯＰ再構成処理に適用する情報等、受信装置側における処理をスムーズに実行させるための付加情報の設定例について説明する。
【００７７】
［４．ＨＴＴＰヘッダに付加情報を記録した実施例について］
まず、ＧＯＰ再構成処理に適用する情報等、受信装置側における処理をスムーズに実行させるための付加情報をＨＴＴＰパケットのＨＴＴＰヘッダに記録した実施例について説明する。
【００７８】
図７、図８を参照してＨＴＴＰヘッダの記録情報について説明する。
図７には、先に図５を参照して説明したと同様、１つのＧＯＰデータを３つのサブＧＯＰメディアセグメントに分割格納したＨＴＴＰパケットの構成例を示している。
【００７９】
これら３つのＨＴＴＰパケットのＨＴＴＰヘッダに、図７に示すように、
（１）セグメント識別子（Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ）
（２）ＧＯＰ内位識別情報（Ｘ−（Ｓｔａｒｔ／Ｍｉｄｄｌｅ／Ｅｎｄ）ｏｆＧＯＰ）
これらの２つの識別情報を記録する。
【００８０】
（１）セグメント識別子は、そのＨＴＴＰパケットに格納されたセグメントのコンテンツ位置情報と、セグメントの種類とパケットに格納されたメディアデータ（ｍｄａｔ）の属するＧＯＰの識別情報を含むデータである。なお、具体的にはＧＯＰデータの位置情報（ＵＲＬ等のアクセス情報）を記録すればよい。
【００８１】
パケットを受信する受信装置３０は、同一のセグメント識別子（Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ）が記録されたＨＴＴＰパケットは同じＧＯＰに属するメディアデータ（ｍｄａｔ）を格納したＨＴＴＰパケットであると判定することができる。
【００８２】
（２）ＧＯＰ内位識別情報は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータである。
ＧＯＰ内位識別情報＝Ｘ−ＳｔａｒｔｏｆＧＯＰであるパケットは、ＧＯＰデータの先頭領域のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したパケットである。
ＧＯＰ内位識別情報＝Ｘ−ＭｉｄｄｌｅｏｆＧＯＰであるパケットは、ＧＯＰデータの中間領域のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したパケットである。
ＧＯＰ内位識別情報＝Ｘ−ＥｎｄｏｆＧＯＰであるパケットは、ＧＯＰデータの末尾領域のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したパケットである。
【００８３】
なお、１つのＧＯＰデータが、４つ以上のサブＧＯＰメディアセグメントに分割された場合、ＧＯＰ内位識別情報＝Ｘ−ＭｉｄｄｌｅｏｆＧＯＰを設定した複数のパケットが生成されることになる。これらのパケットに格納されるメディアデータ（ｍｄａｔ）のＧＯＰデータ内配列は、ＨＴＴＰヘッダ以外のパケットヘッダ情報によって判別できる。
例えばＨＴＴＰパケットを格納するＬＣＴパケットのＬＣＴヘッダに記録されるパケットシーケンス番号を参照することで判別可能である。なお、具体的な送信パケットの構成、およびＬＣＴヘッダ構成については、後述する。
【００８４】
従って、例えばＨＴＴＰパケットをＬＣＴパケットに格納して送信する構成では、ＨＴＴＰヘッダに設定するＧＯＰ内位置識別情報は、ＧＯＰ位置が先頭領域のデータを格納したパケットのみを識別する設定としてもよい。すなわち、ＧＯＰ内位識別情報＝Ｘ−ＳｔａｒｔｏｆＧＯＰのみを記録し、この後に続くＧＯＰデータは、ＬＣＴヘッダのシーケンス番号を参照して配列する構成としてもよい。
【００８５】
図８に、メディアセグメントを格納したＨＴＴＰパケットのＨＴＴＰヘッダのデータ構成例を示す。
図８に示すようにＨＴＴＰヘッダには、例えば以下のＨＴＴＰヘッダ情報が記録される。
「・・・
ＨＴＴＰ／１．１  ２０６  Ｐａｒｔｉａｌ  Ｃｏｎｔｅｎｔ
Ｄａｔｅ：  Ｆｒｉ，  ０４  Ｏｃｔ  ２０１３  １１：１４：２０  ＧＭＴ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｍｐ４
Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ：  ｈｔｔｐ：／／ａ．ｃｏｍ／ｘ．ｍｐ４
Ｘ−ＳｔａｒｔＯｆＧＯＰ
・・・」
【００８６】
上記のＨＴＴＰヘッダ情報中、
セグメント識別子は、
「Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ：  ｈｔｔｐ：／／ａ．ｃｏｍ／ｘ．ｍｐ４」
である。
このセグメント識別子は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）の属するＧＯＰの識別情報を含むものとなる。具体的にはそのＧＯＰデータの位置情報（アクセス情報）である。
同一のセグメント識別子（Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ）が記録されたＨＴＴＰパケットは同じＧＯＰに属するメディアデータ（ｍｄａｔ）を格納したＨＴＴＰパケットであると判定することができる。
【００８７】
また、上記ＨＴＴＰヘッダ情報中、
ＧＯＰ内位識別情報は、
「Ｘ−ＳｔａｒｔＯｆＧＯＰ」
である。このＧＯＰ内位識別情報は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータである。
ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰの、
先頭領域の場合は、「Ｘ−ＳｔａｒｔＯｆＧＯＰ」、
中間領域の場合は、「Ｘ−ＭｉｄｄｌｅＯｆＧＯＰ」、
末尾領域の場合は、「Ｘ−ＥｎｄＯｆＧＯＰ」、
ＨＴＴＰヘッダにはこれらのいずれかのデータがＧＯＰ内位識別情報として記録される。
【００８８】
次に、初期化セグメントを格納するＨＴＴＰパケットのＨＴＴＰヘッダの記録情報について図９を参照して説明する。
初期化セグメントを格納するＨＴＴＰパケットのＨＴＴＰヘッダには、ＨＴＴＰパケットが初期化セグメントを格納したパケットであることを示すセグメント識別情報を記録する。
【００８９】
図９に、初期化セグメントを格納したＨＴＴＰパケットのＨＴＴＰヘッダのデータ構成例を示す。
図９に示すようにＨＴＴＰヘッダには、例えば以下のＨＴＴＰヘッダ情報が記録される。
「・・・
ＨＴＴＰ／１．１  ２０６  Ｐａｒｔｉａｌ  Ｃｏｎｔｅｎｔ
Ｄａｔｅ：  Ｆｒｉ，  ０４  Ｏｃｔ  ２０１３  １１：１４：２０  ＧＭＴ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｍｐ４
Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ：ｈｔｔｐ：／／ａ．ｃｏｍ／ｘ−ｉｎｉｔ．ｍｐ４」
Ｘ−ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ
・・・」
【００９０】
上記のＨＴＴＰヘッダ情報中、
セグメント識別子は、
「Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ：ｈｔｔｐ：／／ａ．ｃｏｍ／ｘ−ｉｎｉｔ．ｍｐ４」
である。
このセグメント識別子は、初期化セグメントのＵＲＬ等のアクセス情報を記録すればよい。
【００９１】
上記のＨＴＴＰヘッダ情報中、
セグメント識別情報は、
「Ｘ−ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｅｇｍｅｎｔ」
である。
このセグメント識別情報は、ＨＴＴＰパケットに格納されたセグメントが、初期化セグメントであることを示す情報である。
初期化セグメントを格納したＨＴＴＰヘッダにはこのセグメント識別情報が記録される。
【００９２】
［５．パケットの構成について］
次に、送信装置から受信装置に向けて送信されるパケットの構成例について説明する。
図１０には以下の２つのＩＰパケットの構成例を示している。
（１）初期化セグメント格納ＩＰパケット
（２）メディアセグメント格納ＩＰパケット
【００９３】
（１）初期化セグメント格納ＩＰパケットは、以下の構成を有する。
ＩＰヘッダ
ＵＤＰヘッダ
ＬＣＴヘッダ
ＨＴＴＰヘッダ
初期化セグメント構成データ［ｄａｓｈ］
初期化セグメント構成データ［ｍｏｏｖ］
【００９４】
ＩＰヘッダ、ＵＤＰヘッダ、ＬＣＴヘッダ、ＨＴＴＰヘッダは、それぞれＩＰプロトコル、ＵＤＰプロトコル、ＦＬＵＴＥプロトコル、ＨＴＴＰプロトコルの各通信プロトコルに従って設定されるヘッダ情報である。
【００９５】
一方、（２）メディアセグメント格納ＩＰパケットは、以下の構成を有する。
ＩＰヘッダ
ＵＤＰヘッダ
ＬＣＴヘッダ
ＨＴＴＰヘッダ
メディアセグメント構成データ［ｍｓｄｈ］
メディアセグメント構成データ［ｓｉｄｘ］
メディアセグメント構成データ［ｍｏｏｆ］
メディアセグメント構成データ［ｍｄａｔ］
【００９６】
ＩＰヘッダ、ＵＤＰヘッダ、ＬＣＴヘッダ、ＨＴＴＰヘッダは、それぞれＩＰプロトコル、ＵＤＰプロトコル、ＦＬＵＴＥプロトコル、ＨＴＴＰプロトコルの各通信プロトコルに従って設定されるヘッダ情報である。
なお、前述したようにメディアセグメント構成データ［ｓｉｄｘ］は、ランダムアクセスに適用可能なメディアデータ（ｍｄａｔ）を有するパケットには設定されるが、それ以外のパケットには設定不要である。
【００９７】
送信装置２０は、図１０に示すＩＰパケットを生成して受信装置３０に向けて送信する。
受信装置３０は、受信装置２０から受信する図１０に示す各パケットを受信し、各ヘッダ情報を解析して、セグメントを取り出し、セグメント格納データに従って、初期設定やコンテンツ再生を実行する。
【００９８】
［６．送信装置と受信装置の構成と処理について］
次に、図１１以下を参照して送信装置と受信装置の構成と処理について説明する。
まず、図１１を参照して、送信装置２０と受信装置３０の構成とプロトコルスタックについて説明する。
【００９９】
図１０を参照して説明したＩＰパケットを生成して送信する送信装置２０は、図１１に示すようにデータ処理部２１と通信部２２を有する。
データ処理部２１は、送信パケットの生成処理を実行する。
具体的には、例えば前述したように符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）の構成データの一部のみを含むメディアデータ（ｍｄａｔ）と、メディアデータ対応のメタデータ（ｍｏｏｆ）を格納したサブＧＯＰメディアセグメントをパケット格納データとして生成する。さらに、サブＧＯＰメディアセグメントの格納データであるメディアデータのＧＯＰ内位置を示すＧＯＰ内位置識別子等のパケット付加情報を生成してＨＴＴＰヘッダに記録したパケットを生成する。
【０１００】
通信部２２は、データ処理部２１の生成したパケットを送信する。
通信部２２は、データ処理部２１の生成したパケットを、放送波、あるいはインターネット等のネットワークを介してブロードキャスト配信、またはマルチキャスト配信する。
【０１０１】
データ処理部２１と通信部２２は、以下のレイヤからなるプロトコルスタックに従ってパケット生成処理を実行し、生成したパケットを送信する。以下、送信装置２０のプロトコルスタックのレイヤ構成について説明する。送信装置２０のプロトコルスタックは、上位レイヤから下位レイヤまで、以下に示すレイヤ構成を有する。
（１）ＤＡＳＨ  Ｓｅｒｖｅｒ：ＤＡＳＨ規格に従ったセグメント生成等の処理を実行するアプリケーションレイヤ
（２）Ｖｉｄｅｏ／Ａｕｄｉｏ／Ｓｕｂｔｉｔｌｅ  ｅｔｃ：送信対象コンテンツの生成、取得を実行するアプリケーションレイヤ
（３）ＦｒａｇｍｅｎｔｅｄＭＰ４：ＭＰ４ファイルフォーマットに従った符号化データを生成しセグメントを生成するアプリケーションレイヤ
（４）ＨＴＴＰ：ＨＴＴＰプロトコルに従ってＨＴＴＰヘッダを有するＨＴＴＰパケットを生成するレイヤ
（５）ＦＬＵＴＥ／ＡＬＣ（ＬＣＴ）：ＦＬＵＴＥプロトコルに従ってＬＣＴヘッダを有するＦＬＵＴＥパケットを生成するレイヤ
（６）ＵＤＰ：ＵＤＰプロトコルに従ってＵＤＰヘッダを有するＵＤＰパケットを生成するレイヤ
（７）ＩＰ：ＩＰプロトコルに従ってＩＰヘッダを有するＩＰパケットを生成するレイヤ
（８）ＰＨＹ：ＩＰパケット、またはＩＰパケットを格納したＭＡＣフレームを生成して送信する通信部等から構成される物理レイヤ
【０１０２】
また、図１０を参照して説明したＩＰパケットを受信する受信装置３０は、図１１に示すようにデータ処理部３１と通信部３２を有する。
通信部３２は、送信装置２０の送信するパケットを受信し、データ処理部３１は通信部３１の受信したパケットを入力して、データ処理を行なう。
【０１０３】
データ処理部３１と通信部３２は、以下のレイヤからなるプロトコルスタックに従ってパケットの受信、解析を実行する。受信装置３０のプロトコルスタックは、上位レイヤから下位レイヤまで、以下に示すレイヤ構成を有する。
（１）ＤＡＳＨ  Ｃｌｉｅｎｔ：ＤＡＳＨ規格に従ったセグメントの解析等の処理を実行するアプリケーションレイヤ
（２）Ｖｉｄｅｏ／Ａｕｄｉｏ／Ｓｕｂｔｉｔｌｅ  ｅｔｃ：受信コンテンツの取得、再生処理等を実行するアプリケーションレイヤ
（３）ＦｒａｇｍｅｎｔｅｄＭＰ４：ＭＰ４ファイルフォーマットに従った符号化データの復号処理等を実行するアプリケーションレイヤ
（４）ＨＴＴＰ：ＨＴＴＰプロトコルに従ってＨＴＴＰヘッダを有するＨＴＴＰパケットを解析するレイヤ
（５）ＦＬＵＴＥ／ＡＬＣ（ＬＣＴ）：ＦＬＵＴＥプロトコルに従ってＬＣＴヘッダを有するＦＬＵＴＥパケットを解析するレイヤ
（６）ＵＤＰ：ＵＤＰプロトコルに従ってＵＤＰヘッダを有するＵＤＰパケットを解析するレイヤ
（７）ＩＰ：ＩＰプロトコルに従ってＩＰヘッダを有するＩＰパケットを解析するレイヤ
（８）ＰＨＹ：ＩＰパケット、またはＩＰパケットを格納したＭＡＣフレームを受信する通信部等から構成される物理レイヤ
【０１０４】
なお、送信装置２０は、前述したようにＩＰパケットをブロードキャスト、あるいはマルチキャスト送信する際、ネットワークを介した送信、あるいは放送波を介した送信のいずれか、または、これらの双方の通信経路を利用して並列送信する処理を行なう。
【０１０５】
受信装置３０は、放送波と、インターネット等のネットワークのいずれかの通信経路、または両通信経路を介したパケット受信処理を行なう。
インターネット等のネットワークを介した送受信パケットの生成および解析は、図１１に示すＦＬＵＴＥ／ＡＬＣ（ＬＣＴ）レイヤとＵＤＰレイヤを、ＴＣＰレイヤに置き換えて行なうことが可能である。
【０１０６】
放送波を介して受信するＩＰパケットと、インターネット等のネットワークを介して受信するＩＰパケットを適宜、切り替えて処理を行なう受信装置３０のプロトコルスタックの例について、図１２を参照して説明する。
【０１０７】
図１２に示す受信装置３０のプロトコルスタックは、以下の２つの通信系に対応したプロトコルスタックのレイヤ構成を示している。
（１）放送系
（２）ネットワーク通信系
【０１０８】
（１）放送系は、図１１を参照して説明したレイヤ構成となっている。
（２）ネットワーク通信系は、放送系レイヤのＦＬＵＴＥ／ＡＬＣ（ＬＣＴ）レイヤと、ＵＤＰレイヤをＴＣＰレイヤに置き換えた構成である。
ＴＣＰレイヤは、ＴＣＰヘッダを有するＴＣＰパケットの解析を実行する。
シグナリング（Ｓｉｇｎａｌｉｎｇ）レイヤは、各通信系の切り替え制御を行うためのレイヤである。
【０１０９】
受信装置３０は、放送系とネットワーク通信系の各レイヤを、適宜切り替えて利用することで、放送波を介して受信するパケットと、インターネット等のネットワークを介して受信するパケットを選択的に利用してパケット格納コンテンツを取得して再生処理を実行することができる。
【０１１０】
例えば、ネットワークからのパケット受信に遅延が発生した場合、放送系に切り替えて同一コンテンツに対応するパケットを、放送波を介して受信し、コンテンツ再生を継続することができる。
ネットワーク通信系、放送系のいずれの通信系を介した配信パケットにも、前述したセグメント識別子やＧＯＰ内位置識別子が記録されており、これらの識別情報を参照して、ＧＯＰデータの再構築が可能となり、エラーのない復号処理と、コンテンツ再生が実現される。
【０１１１】
［７．パケットに格納したＮＡＬユニットがＳＡＰ（ストリームアクセスポイント）を含むか否かを識別可能としたアクセスポイント情報を付加した構成について］
次に、受信装置の処理効率化を実現する構成例として、パケットに格納したＮＡＬユニットフラグメントの分割元であるＮＡＬユニットにＳＡＰ（アクセスポイントデータ）を含むか否かを識別可能とした識別情報を付加した構成について説明する。
【０１１２】
先に、図３他を参照して説明したようにＳＡＰ（Ｓｔｒｅａｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）は、ランダムアクセスポイントとなるデータの格納位置情報である。ＤＡＳＨではランダムアクセスポイントをＳＡＰ（Ｓｔｒｅａｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）と呼ぶ。ＳＡＰは、例えばストリームを復号するために必要なすべての状態をリセットすることができる画像シーケンスの先頭ピクチャの先頭バイト位置を示す。具体的には、例えばＭＰＥＧデータのＩピクチャ位置等を示す情報である。
なお、先に図３（ｂ）を参照して説明したように、ＳＡＰはメディアセグメントのメタ情報である［ｓｉｄｘ］に格納されている。
【０１１３】
受信装置側では、ＳＡＰの示すデータ位置の符号化データを取得して、その取得データから復号処理を実行して再生を行なうことが可能となる。
従って、コンテンツの途中から再生するなどの特殊再生処理を行う場合、ＳＡＰは重要な必須データとなる。例えば、ＧＯＰデータの全てを揃えることなく、ＳＡＰにによって指定される符号化データを取得し復号することでランダムアクセスポイントの画像を再生可能となる。
【０１１４】
また、受信装置は、例えば配信遅延などによってＧＯＰ単位の全符号化データのパケット受信が間に合わない場合などに、ＳＡＰによって指定されるランダムアクセスポイントデータを優先して処理を行なうことも可能である。ランダムアクセスポイントデータを選択して復号、再生することで、表示部の画像表示を継続可能となる。このように、処理優先度を判定する場合にもＳＡＰは重要なデータとなる。
【０１１５】
１つのＧＯＰ単位データの中には、確実にランダムアクセスポイントが存在する。しかし、図５〜図１０を参照して説明したように、１つのパケットの格納データを１ＧＯＰ単位のデータではなく、１ＧＯＰを細分化して、１つまたは複数のＮＡＬユニットを格納したパケットは、パケットに格納したＮＡＬユニットにランダムアクセスポイントが含まれる場合と含まれない場合がある。
【０１１６】
図５〜図１０を参照して説明した構成では、例えば図７に示すように、サブＧＯＰメディアセグメントＨＴＴＰパケットにメタデータである「ｓｉｄｘ」を含むパケットと含まないパケットを設定している。
サブＧＯＰメディアセグメントＨＴＴＰパケットに格納されたＮＡＬユニットにランダムアクセスポイント対応のデータが含まれればＳＡＰを記録した［ｓｉｄｘ］が設定される。
しかし、［ｓｉｄｘ］は、メディアデータのランダムアクセスポイント情報であるＳＡＰのみならず、その他のデータの境界情報等も含むメタデータであり、［ｓｉｄｘ］の有無のみによってパケット格納データにアクセスポイントとなるデータが含まれるか否かを判定することはできない。
【０１１７】
従って、上述したサブＧＯＰメディアセグメントＨＴＴＰパケットを利用した符号化データ配信構成では、受信装置側は、受信パケット単位でパケットにアクセスポイントデータが含まれるか否かを判定することが困難になる。
以下、このような問題を解決し、受信装置側で、受信パケット単位で、パケットにアクセスポイントデータが含まれるか否かを判定可能とした構成について説明する。
【０１１８】
図１３以下を参照して、上述したサブＧＯＰメディアセグメントＨＴＴＰパケットを利用した符号化データ配信構成において、パケット単位で各パケットにアクセスポイントデータが含まれるか否かを判定可能とした構成について説明する。
図１３は、先に説明した図５、図７と同様、１つのＧＯＰデータを３つのサブＧＯＰメディアセグメントに分割格納したＨＴＴＰパケットの構成例を示している。
【０１１９】
これら３つのＨＴＴＰパケットのＨＴＴＰヘッダには、先に図７を参照して説明した以下の付加情報が記録される。
（１）セグメント識別子（Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ）
（２）ＧＯＰ内位識別情報（Ｘ−（Ｓｔａｒｔ／Ｍｉｄｄｌｅ／Ｅｎｄ）ｏｆＧＯＰ）
さらに、図１３に示す例では、ＨＴＴＰヘッダに以下の付加情報を追加記録する。
（３）アクセスポイント情報（Ｘ−ＳＡＰ）
これらの３つの情報を記録する。
【０１２０】
（１）セグメント識別子は、そのＨＴＴＰパケットに格納されたセグメントのコンテンツ位置情報と、セグメントの種類とパケットに格納されたメディアデータ（ｍｄａｔ）の属するＧＯＰの識別情報を含むデータである。なお、具体的にはＧＯＰデータの位置情報（ＵＲＬ等のアクセス情報）を記録すればよい。
【０１２１】
パケットを受信する受信装置３０は、同一のセグメント識別子（Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ）が記録されたＨＴＴＰパケットは同じＧＯＰに属するメディアデータ（ｍｄａｔ）を格納したＨＴＴＰパケットであると判定することができる。
【０１２２】
（２）ＧＯＰ内位識別情報は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータである。
ＧＯＰ内位識別情報＝Ｘ−ＳｔａｒｔｏｆＧＯＰであるパケットは、ＧＯＰデータの先頭領域のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したパケットである。
ＧＯＰ内位識別情報＝Ｘ−ＭｉｄｄｌｅｏｆＧＯＰであるパケットは、ＧＯＰデータの中間領域のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したパケットである。
ＧＯＰ内位識別情報＝Ｘ−ＥｎｄｏｆＧＯＰであるパケットは、ＧＯＰデータの末尾領域のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したパケットである。
【０１２３】
なお、１つのＧＯＰデータが、４つ以上のサブＧＯＰメディアセグメントに分割された場合、ＧＯＰ内位識別情報＝Ｘ−ＭｉｄｄｌｅｏｆＧＯＰを設定した複数のパケットが生成されることになる。これらのパケットに格納されるメディアデータ（ｍｄａｔ）のＧＯＰデータ内配列は、ＨＴＴＰヘッダ以外のパケットヘッダ情報によって判別できる。
例えばＨＴＴＰパケットを格納するＬＣＴパケットのＬＣＴヘッダに記録されるパケットシーケンス番号を参照することで判別可能である。なお、具体的な送信パケットの構成、およびＬＣＴヘッダ構成については、後述する。
【０１２４】
従って、例えばＨＴＴＰパケットをＬＣＴパケットに格納して送信する構成では、ＨＴＴＰヘッダに設定するＧＯＰ内位置識別情報は、ＧＯＰ位置が先頭領域のデータを格納したパケットのみを識別する設定としてもよい。すなわち、ＧＯＰ内位識別情報＝Ｘ−ＳｔａｒｔｏｆＧＯＰのみを記録し、この後に続くＧＯＰデータは、ＬＣＴヘッダのシーケンス番号を参照して配列する構成としてもよい。
【０１２５】
（３）アクセスポイント情報（Ｘ−ＳＡＰ）は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）に含まれる符号化データにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。
受信装置は、このアクセスポイント情報（Ｘ−ＳＡＰ）を参照することで、そのＨＴＴＰパケットに格納されたメディアデータ内のＮＡＬユニットがアクセスポイントデータを含むか否かを即座に判別することができる。
従って、例えばアクセスポイントデータのみを優先して復号、再生を行なう場合には、ＨＴＴＰヘッダに記録されたアクセスポイント情報（Ｘ−ＳＡＰ）を参照して、処理対象パケットを選択することができる。すなわち、ＨＴＴＰヘッダに記録されたアクセスポイント情報（Ｘ−ＳＡＰ）が、パケット格納データ（ＮＡＬユニット）にアクセスポイントが含まれることを示すパケットのみを選択して処理を行なうことが可能となる。
【０１２６】
なお、図１３に示す例では、図１３（ｂ１）〜（ｂ３）のすべてのＨＴＴＰパケットにアクセスポイント情報（Ｘ−ＳＡＰ）を設定し、アクセスポイント情報（Ｘ−ＳＡＰ）が、各ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）に含まれる符号化データにランダムアクセスポイントとなるデータが含まれるか否かを示す構成としている。
このような構成の他、例えば、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）に含まれる符号化データにランダムアクセスポイントとなるデータが含まれる場合にのみ、そのＨＴＴＰパケットのＨＴＴＰヘッダにアクセスポイント情報（Ｘ−ＳＡＰ）を記録する構成としてもよい。すなわち、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）に含まれる符号化データにランダムアクセスポイントとなるデータが含まれない場合は、ＨＴＴＰヘッダにアクセスポイント情報（Ｘ−ＳＡＰ）を記録しない。例えば、図１３（ｂ２），（ｂ３）に示すＨＴＴＰパケットにランダムアクセスポイントとなるデータが含まれない場合は、ＨＴＴＰヘッダにアクセスポイント情報（Ｘ−ＳＡＰ）を記録しない。
この設定の場合、受信装置は、ＨＴＴＰヘッダにアクセスポイント情報（Ｘ−ＳＡＰ）が記録されているか否かに応じて、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）に含まれる符号化データにランダムアクセスポイントとなるデータが含まれるか否かを判定する。
【０１２７】
このアクセスポイント情報（Ｘ−ＳＡＰ）は、ランダムアクセス可能なデータの有無をパケット単位で識別可能とする情報である。受信装置側では、各パケットのアクセスポイント情報（Ｘ−ＳＡＰ）を参照して、ランダムアクセス可能なデータの格納されたパケットを選別することが可能となる。受信装置は、例えばランダムアクセス可能なデータの格納されたパケットをを優先処理することで、ランダムアクセスポイントからのデータ再生処理等を迅速に行うことが可能となる。
【０１２８】
図１４に、メディアセグメントを格納したＨＴＴＰパケットのＨＴＴＰヘッダのデータ構成例を示す。
図１４に示すようにＨＴＴＰヘッダには、例えば以下のＨＴＴＰヘッダ情報が記録される。
「・・・
ＨＴＴＰ／１．１  ２０６  Ｐａｒｔｉａｌ  Ｃｏｎｔｅｎｔ
Ｄａｔｅ：  Ｆｒｉ，  ０４  Ｏｃｔ  ２０１３  １１：１４：２０  ＧＭＴ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｍｐ４
Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ：  ｈｔｔｐ：／／ａ．ｃｏｍ／ｘ．ｍｐ４
Ｘ−ＳｔａｒｔＯｆＧＯＰ
Ｘ−ＳＡＰ
・・・」
【０１２９】
上記のＨＴＴＰヘッダ情報中、
セグメント識別子「Ｃｏｎｔｅｎｔ−Ｌｏｃａｔｉｏｎ：  ｈｔｔｐ：／／ａ．ｃｏｍ／ｘ．ｍｐ４」
ＧＯＰ内位識別情報「Ｘ−ＳｔａｒｔＯｆＧＯＰ」、
これらについては、先に図８を参照して説明したと同様の情報である。
すなわち、セグメント識別子は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）の属するＧＯＰの識別情報として機能するＧＯＰデータの位置情報（アクセス情報）である。
ＧＯＰ内位識別情報は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータである。
先頭領域の場合は、「Ｘ−ＳｔａｒｔＯｆＧＯＰ」、
中間領域の場合は、「Ｘ−ＭｉｄｄｌｅＯｆＧＯＰ」、
末尾領域の場合は、「Ｘ−ＥｎｄＯｆＧＯＰ」、
ＨＴＴＰヘッダにはこれらのいずれかのデータがＧＯＰ内位識別情報として記録される。
【０１３０】
また、図１４に示すＨＴＴＰヘッダ情報中、
アクセスポイント情報「Ｘ−ＳＡＰ」は、そのＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）に含まれる符号化データ（ＮＡＬ）にランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。
【０１３１】
受信装置は、アクセスポイント情報（Ｘ−ＳＡＰ）を参照することで、受信パケット単位でパケット格納メディアデータ内のＮＡＬユニットにアクセスポイントが含まれるか否かを即座に判別することができる。
【０１３２】
受信装置は、アクセスポイントが含まれるパケットのみを選択して、これらのパケットの格納データを優先して復号し、再生することが可能となる。例えば配信遅延などによってＧＯＰ単位の全符号化データのパケット受信が間に合わない場合などに、ランダムアクセスポイントデータを優先して復号、再生することで、表示部の画像表示を継続させるといった処理が可能となる。
【０１３３】
［８．ＮＡＬユニットをさらに分割したＮＡＬユニットフラグメント格納パケットを利用した通信処理構成について］
上述したように、ＧＯＰの分割データである１つのＮＡＬユニット、または複数のＮＡＬユニットを含むパケットを利用したデータ送受信を行うことで、ネットワーク上の１つの転送パケットのデータ量の削減が実現される。
【０１３４】
しかし、例えば高画質の画像データである４Ｋコンテンツや８Ｋコンテンツなど、データ量が多い画像データについては、これらの大容量画像データの符号化処理によって生成するＮＡＬユニットのデータ量が増大する。すなわち、１つのＮＡＬユニットそのもののデータ量が非常に大きくなる場合が想定される。
【０１３５】
ＩＰレイヤにおけるデータ転送処理において、例えばイーサネット（登録商標）を介したデータ転送を行う場合、ＩＰパケットをイーサネット（登録商標）で規定される最大データ転送単位（ＭＴＵ：Ｍａｘｉｍｕｍ  Ｔｒａｎｓｆｅｒ  Ｕｎｉｔ）以下のＭＡＣフレームを生成して転送することが必要となる。
すなわち最大データ転送単位（ＭＴＵ）の規定されたネットワークを介してパケットを転送する場合には、ＭＴＵ以上のデータ量を持つＩＰパケットについて、ＭＴＵで規定するデータ量以下に分割するフラグメント処理を実行し、各分割データを格納した複数のＭＡＣフレームを生成して転送する処理が必須となる。
【０１３６】
例えばイーサネット（登録商標）の規定するＭＡＣフレームのフレーム単位の最大データ転送量（ＭＴＵ）は約１５００バイトである。
ＭＡＣフレームは、例えば図１５に示す構成を有し、先に図１０を参照して説明したＩＰパケットの先頭にＭＡＣヘッダを設定した構成である。例えば図１５に示すＭＡＣフレームでは、ＭＡＣフレームのペイロードとなるＩＰヘッダ〜ｍｄａｔまでのデータ量をＭＴＵ＝１５００バイト以下に設定することが必要となる。
【０１３７】
送信装置２０から受信装置３０にパケット送信を行う場合、送信装置２０や受信装置３０側の各デバイス間通信や、送信装置２０と受信装置３０間の中継装置等において、このＭＴＵに応じたフラグメンテーション、すなわちパケット分割処理と、分割データの再構成処理が繰り返し実行される可能性がある。
このような事態が発生すると、送信装置２０におけるコンテンツ入力から受信装置３０におけるコンテンツ再生までの時間に遅延が発生し、受信装置３０におけるコンテンツの再生遅延が発生する可能性が高まることになる。
【０１３８】
以下では、このような事態を防止する構成について説明する。
以下に説明する実施例において、送信装置２０は、パケット生成処理段階におけるＨＴＴＰレイヤにおいて、パケットのデータサイズを所定サイズ以下に設定する。具体的には、通信路において想定される最大データ転送単位（ＭＴＵ：Ｍａｘｉｍｕｍ  Ｔｒａｎｓｆｅｒ  Ｕｎｉｔ）以下の小さなデータサイズとする。具体的には、例えば１つのＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成して送信する。
【０１３９】
前述したように、例えばイーサネット（登録商標）の規定するＭＡＣフレームのフレーム単位の一般的な最大データ転送量（ＭＴＵ）は約１５００バイトである。
送信装置２０のデータ処理部はＨＴＴＰパケットの生成段階で、このＭＴＵを考慮したパケット生成を行う。例えば、ＨＴＴＰパケットを格納したＭＡＣフレームのフレームサイズが１５００バイト以下になるようにパケット生成を実行する。
【０１４０】
送信装置２０のデータ処理部において、通信経路における最大データ転送量（ＭＴＵ）を考慮したパケット生成処理を実行することで、送信装置や、中継装置、あるいは受信装置のＩＰレイヤにおいてＭＴＵに従ったパケット分割処理であるフラグメンテーションが不要となり、データ転送をスムーズに実行することが可能になる。
【０１４１】
このように、送信装置２０のデータ処理部はＨＴＴＰパケットの生成段階で、パケット格納データを通信経路において規定されるＭＴＵ以下の小さなフラグメントに設定する処理を実行する。この処理により、例えば、通信路のＩＰレイヤにおけるフラグメンテーション処理よるオーバーヘッドが低減される。
【０１４２】
先に図５他を参照して説明した例では、１つまたは複数のＮＡＬユニットをメディアデータ（ｍｄａｔ）とし、さらにその属性データであるメタデータ（ｍｏｏｆ）と組み合わせて１つのフラグメントを生成し、このフラグメントを持つサブＧＯＰメディアセグメントを格納したＨＴＴＰパケットを生成していた。
【０１４３】
以下に説明する実施例では、１つのＮＡＬユニットを分割したＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したＨＴＴＰパケットを生成する。
なお、ＮＡＬユニット対応の属性データである（ｍｏｏｆ）は、メディアデータ（ｍｄａｔ）格納パケットと異なる別の独立したＨＴＴＰパケットに格納して配信する。
【０１４４】
図１６を参照して、本実施例におけるＨＴＴＰパケットの構成例について説明する。
図１６（ａ）は、先に図５〜図７等を参照して説明したサブＧＯＰメディアセグメントである。すなわちＧＯＰを分割したデータである１つ以上のＮＡＬユニットをメディアデータ（ｍｄａｔ）として格納したセグメントである。
ただし、図１６（ａ）に示すサブＧＯＰメディアセグメントはメディアデータ（ｍｄａｔ）として１つのＮＡＬユニットのみを格納した例である。ＮＡＬユニットは１に限らず複数のＮＡＬユニットとしてもよい。
【０１４５】
本実施例では、この図１６（ａ）に示すようなサブＧＯＰメディアセグメントをさらに分割して複数のＨＴＴＰパケットを生成する。分割処理は、通信経路における最大データ転送量（ＭＴＵ）を考慮して実行する。例えば、分割後のＨＴＴＰパケットを格納したＭＡＣフレームを生成した場合に、ＭＡＣフレームに許容される最大データ転送単位（ＭＴＵ：Ｍａｘｉｍｕｍ  Ｔｒａｎｓｆｅｒ  Ｕｎｉｔ）以下となるように行う。
【０１４６】
なお、分割処理に際しては１つまたは複数のＮＡＬユニットを分割するＮＡＬユニット分割処理を行なうことになる。以下では、ＮＡＬユニットの分割後のデータをＮＡＬユニットフラグメント（ＮＡＬｆ）として説明する。
また、サブＧＯＰメディアセグメントの構成データを分割して生成したＨＴＴＰパケットをＮＡＬユニットフラグメント対応ＨＴＴＰパケットと呼ぶ。
【０１４７】
図１６に示す例では、図１６（ａ）に示すサブＧＯＰメディアセグメントの構成データを４つのＨＴＴＰパケット（ｂ１）〜（ｂ４）に分割した例を示している。
（ｂ１）〜（ｂ４）に示す４つのＮＡＬユニットフラグメント対応ＨＴＴＰパケットの各々は、このＨＴＴＰパケットを図１５に示すＭＡＣフレーム構成とした場合、ＭＡＣヘッダ以外のデータ部のデータ量が１５００バイト以下になるようなデータ量に設定する。
【０１４８】
図１６の（ｂ１）に示すＮＡＬユニットフラグメント対応ＨＴＴＰパケットは、（ａ）に示すサブＧＯＰメディアセグメントのメタデータ領域、すなわち、ｍｓｄｈ（ｓｔｙｐｅ）、ｓｉｄｘ、ｍｏｏｆ、これらのメタデータを格納したＨＴＴＰパケットである。すなわちメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットである。
【０１４９】
また、図１６（ｂ２）〜（ｂ４）に示すＮＡＬユニットフラグメント対応ＨＴＴＰパケットは、（ａ）に示すサブＧＯＰメディアセグメントのメディアデータ（ｍｄａｔ）領域のＮＡＬユニットを分割して生成したＮＡＬフラグメント（ＮＡＬｆ）を格納したＨＴＴＰパケットである。すなわちメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットである。
【０１５０】
なお、図１６（ａ）に示すサブＧＯＰメディアセグメントに格納されたＮＡＬユニットは１つのみであるが、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットは図１６（ａ）に示すように１つのＮＡＬユニットである場合と、２つ以上の複数のＮＡＬユニットである場合がある。ＮＡＬユニットフラグメントの構成データは、１つのＮＡＬユニットのみに限らず、複数のＮＡＬユニットに跨ったデータとしてもよい。例えば先行するＮＡＬユニットの後半部分と、後続のＮＡＬユニットの先頭部分をあわせて１つのＮＡＬユニットフラグメントを設定するといった構成も可能である。
【０１５１】
送信装置２０は、このように１つのサブＧＯＰメディアセグメントを分割して複数のＨＴＴＰパケットを生成して、これらのＨＴＴＰパケットからさらにＩＰパケットを生成し、順次送信する。
【０１５２】
しかし、このように本来の１つのＮＡＬユニットやその属性情報が分割されて配信されると、受信装置３０側で復号、再生処理を行うためには、ＮＡＬユニットとその属性情報を再構築する必要がある。
このために必要となる情報を付加情報としてＨＴＴＰヘッダに記録する。
【０１５３】
図１６（ｂ１）に示すメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのＨＴＴＰヘッダには、以下の付加情報を記録する。
＊ＮＡＬユニットフラグメントヘッダ［Ｘ−ＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔＨｅａｄｅｒ］
＊ムービーフラグメントシーケンス番号［Ｘ−ＭｏｖｉｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ］
＊アクセスポイント情報［Ｘ−ＳＡＰ］
【０１５４】
ＮＡＬユニットフラグメントヘッダは、そのＨＴＴＰパケットが、
メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであるか、
メディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであるか、
を識別するための識別情報である。
【０１５５】
ムービーフラグメントシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号であり、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。このシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号をそのままコピーして記録する。
【０１５６】
アクセスポイント情報は、このＨＴＴＰパケットの生成元となったサブＧＯＰセグメント（図１６（ａ）のサブＧＯＰメディアセグメント）に格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。
受信装置は、このアクセスポイント情報（Ｘ−ＳＡＰ）を参照することで、そのＨＴＴＰパケットが、ランダムアクセスポイントとなるＮＡＬユニットを含むサブＧＯＰセグメントの構成データに基づいて生成されたデータであるか否かを即座に判別することができる。
【０１５７】
なお、この図１６（ｂ１）のメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのＨＴＴＰヘッダに記録されたアクセスポイント情報（Ｘ−ＳＡＰ）が、パケット生成元のサブＧＯＰセグメントにアクセスポイントデータを含むことを示す場合、メタデータである［ｓｉｄｘ］を参照することで、ＳＡＰ、すなわちランダムアクセスポイントの符号化データの位置を取得することが可能となる。
【０１５８】
一方、図１６（ｂ２）〜（ｂ４）に示すメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのＨＴＴＰヘッダには、以下の付加情報を記録する。
＊ムービーフラグメントシーケンス番号［Ｘ−ＭｏｖｉｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ］
＊ＮＡＬユニット内位置識別情報［Ｘ−ＮＡＬＵＦｒａｇｍｅｎｔＩｎｄｉｃａｔｏｒ］
＊アクセスポイント情報［Ｘ−ＳＡＰ］
【０１５９】
ムービーフラグメントシーケンス番号は、上述したように、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号であり、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。このシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号をそのままコピーして記録する。
【０１６０】
ＮＡＬユニット内位置識別情報は、パケットに格納したＮＡＬユニットフラグメント（ＮＡＬｆ）が、分割前のＮＡＬユニットのどの位置に対応するフラグメントであるかを示す情報である。
ＮＡＬユニット内位置識別情報＝Ｘ−ＳｔａｒｔＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔであるパケットは、分割前のＮＡＬユニットの先頭領域のＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したパケットである。
ＮＡＬユニット内位置識別情報＝Ｘ−ＭｉｄｄｌｅＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔであるパケットは、分割前のＮＡＬユニットの中間領域のＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したパケットである。
ＮＡＬユニット内位置識別情報＝Ｘ−ＥｎｄＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔであるパケットは、分割前のＮＡＬユニットの末尾領域のＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したパケットである。
【０１６１】
なお、１つのサブＧＯＰメディアセグメントに格納されたＮＡＬユニットが、４つ以上のメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットに分割された場合、ＮＡＬユニット内位置識別情報＝Ｘ−ＭｉｄｄｌｅＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔを設定した複数のパケットが生成されることになる。これらのパケットに格納されるメディアデータ（ｍｄａｔ）のＮＡＬユニットフラグメント（ＮＡＬｆ）の配列は、ＨＴＴＰヘッダ以外のパケットヘッダ情報によって判別できる。
例えばＨＴＴＰパケットを格納するＬＣＴパケットのＬＣＴヘッダに記録されるパケットシーケンス番号を参照することで判別可能である。なお、具体的な送信パケットの構成、およびＬＣＴヘッダ構成については、後述する。
【０１６２】
従って、例えばＨＴＴＰパケットをＬＣＴパケットに格納して送信する構成では、ＨＴＴＰヘッダに設定するＮＡＬユニット内位置識別情報は、位置が先頭領域のデータを格納したパケットのみを識別する設定としてもよい。すなわち、ＮＡＬユニット内位置識別情報＝Ｘ−ＳｔａｒｔＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔのみを記録し、この後に続くデータは、ＬＣＴヘッダのシーケンス番号を参照して配列する構成としてもよい。
【０１６３】
アクセスポイント情報は、このＨＴＴＰパケットの生成元となったサブＧＯＰセグメント（図１６（ａ）のサブＧＯＰメディアセグメント）に格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。
受信装置は、このアクセスポイント情報（Ｘ−ＳＡＰ）を参照することで、そのＨＴＴＰパケットが、ランダムアクセスポイントとなるＮＡＬユニットを含むサブＧＯＰセグメントの構成データに基づいて生成されたデータであるか否かを即座に判別することができる。
【０１６４】
図１７に、メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットの構成とＨＴＴＰヘッダのデータ構成例を示す。
図１７に示すようにＨＴＴＰヘッダには、例えば以下のＨＴＴＰヘッダ情報が記録される。
「・・・
ＨＴＴＰ／１．１  ２０６  Ｐａｒｔｉａｌ  Ｃｏｎｔｅｎｔ
Ｄａｔｅ：  Ｆｒｉ，  ０４  Ｏｃｔ  ２０１３  １１：１４：２０  ＧＭＴ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｍｐ４
Ｘ−ＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔＨｅａｄｅｒ
Ｘ−ＭｏｖｉｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ：２３４５６７
Ｘ−ＳＡＰ
・・・」
【０１６５】
上記のＨＴＴＰヘッダ情報中、
ＮＡＬユニットフラグメントヘッダは、
「Ｘ−ＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔＨｅａｄｅｒ」
である。
このＮＡＬユニットフラグメントヘッダは、このＨＴＴＰパケットが、メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであることを示す情報として記録される。
【０１６６】
また、上記のＨＴＴＰヘッダ情報中、
ムービーフラグメントシーケンス番号は、
「Ｘ−ＭｏｖｉｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ」
である。
このムービーフラグメントシーケンス番号は、上述したように、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号であり、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。このシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号をそのままコピーして記録する。
【０１６７】
また、上記のＨＴＴＰヘッダ情報中、
アクセスポイント情報は、
「Ｘ−ＳＡＰ」
である。
このアクセスポイント情報は、このＨＴＴＰパケットの生成元となったサブＧＯＰセグメントに格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。
【０１６８】
次に、図１８を参照して、メディアデータを格納するメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットの構成とＨＴＴＰヘッダのデータ構成例について説明する。
図１８に示すようにＨＴＴＰヘッダには、例えば以下のＨＴＴＰヘッダ情報が記録される。
「・・・
ＨＴＴＰ／１．１  ２０６  Ｐａｒｔｉａｌ  Ｃｏｎｔｅｎｔ
Ｄａｔｅ：  Ｆｒｉ，  ０４  Ｏｃｔ  ２０１３  １１：１４：２０  ＧＭＴ
Ｃｏｎｔｅｎｔ−ｔｙｐｅ：  ａｐｐｌｉｃａｔｉｏｎ／ｍｐ４
Ｘ−ＳｔａｒｔＯｆＧＯＰ
Ｘ−ＭｏｖｉｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ：２３４５６７
Ｘ−ＳｔａｒｔＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ
Ｘ−ＳＡＰ
・・・」
【０１６９】
上記のＨＴＴＰヘッダ情報中、
ＧＯＰ内位識別情報は、
「Ｘ−ＳｔａｒｔＯｆＧＯＰ」
である。このＧＯＰ内位識別情報は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータである。
先頭領域の場合は、「Ｘ−ＳｔａｒｔＯｆＧＯＰ」、
中間領域の場合は、「Ｘ−ＭｉｄｄｌｅＯｆＧＯＰ」、
末尾領域の場合は、「Ｘ−ＥｎｄＯｆＧＯＰ」、
ＨＴＴＰヘッダにはこれらのいずれかのデータがＧＯＰ内位識別情報として記録される。
【０１７０】
また、上記のＨＴＴＰヘッダ情報中、
ムービーフラグメントシーケンス番号は、
「Ｘ−ＭｏｖｉｅＦｒａｇｍｅｎｔＳｅｑｕｅｎｃｅＮｕｍｂｅｒ」
である。
このムービーフラグメントシーケンス番号は、上述したように、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号であり、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。このシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号をそのままコピーして記録する。
【０１７１】
また、上記のＨＴＴＰヘッダ情報中、
ＮＡＬユニット内位置識別情報は、
「Ｘ−ＳｔａｒｔＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ」
である。
このＮＡＬユニット内位置識別情報は、パケットに格納したＮＡＬユニットフラグメント（ＮＡＬｆ）が、分割前のＮＡＬユニットのどの位置に対応するフラグメントであるかを示す情報である。
【０１７２】
ＮＡＬユニット内位置識別情報＝Ｘ−ＳｔａｒｔＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔであるパケットは、分割前のＮＡＬユニットの先頭領域のＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したパケットである。
ＮＡＬユニット内位置識別情報＝Ｘ−ＭｉｄｄｌｅＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔであるパケットは、分割前のＮＡＬユニットの中間領域のＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したパケットである。
ＮＡＬユニット内位置識別情報＝Ｘ−ＥｎｄＮＡＬＵＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔであるパケットは、分割前のＮＡＬユニットの末尾領域のＮＡＬユニットフラグメント（ＮＡＬｆ）をメディアデータ（ｍｄａｔ）として格納したパケットである。
【０１７３】
また、上記のＨＴＴＰヘッダ情報中、
アクセスポイント情報は、
「Ｘ−ＳＡＰ」
である。
このアクセスポイント情報は、このＨＴＴＰパケットの生成元となったサブＧＯＰセグメントに格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。
【０１７４】
［９．送信装置と受信装置の処理シーケンスについて］
次に、図１９、図２０に示すフローチャートを参照して送信装置と受信装置の実行する処理シーケンスについて説明する。
【０１７５】
まず、図１９に示すフローチャートを参照して送信装置２０の実行する処理シーケンスについて説明する。
図１９に示すフローは、図１６を参照して説明した例えば図１６（ａ）に示すサブＧＯＰメディアセグメントに基づいて生成するメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット、あるいはメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットの生成と送信処理のシーケンスを説明するフローである。
この処理は、送信装置２０のデータ処理部において実行する。データ処理部は、プログラム実行機能を有するＣＰＵを備え、例えば記憶部に格納されたプログラムに従って、図１９に示すフローに従った処理を実行する。
以下、各ステップの処理について、順次、説明する。
【０１７６】
（ステップＳ１０１）
まず、送信装置のデータ処理部は、送信対象となるコンテンツの符号化処理を実行する。例えばＭＰ４ファイルフォーマットに従った符号化処理を実行する。
【０１７７】
（ステップＳ１０２）
次に、送信装置は、サブＧＯＰメディアセグメント対応のメディアデータ（ｍｄａｔ）を生成する。この処理は、先に図５他を参照して説明したサブＧＯＰメディアセグメントに格納するメディアデータ（ｍｄａｔ）を生成する処理である。ＭＰ４符号化データであるＧＯＰデータの一部、すなわちＧＯＰを構成する１つ以上のＮＡＬユニットを構成データとするメディアデータ（ｍｄａｔ）を生成する。
【０１７８】
（ステップＳ１０３）
次に、送信装置は、ステップＳ１０２で生成したメディアデータ（ｍｄａｔ）に対応する属性情報であるメタデータ（ｍｏｏｆ）を生成する。
【０１７９】
（ステップＳ１０４）
次に、送信装置は、サブＧＯＰメディアセグメントに対応するメタデータであるｍｓｄｈ、ｓｉｄｘを生成する。先に図５他を参照して説明したサブＧＯＰメディアセグメントに格納するメタデータである。
【０１８０】
（ステップＳ１０５）
次に、送信装置は、サブＧＯＰメディアセグメント格納用のメタデータ（ｍｄａｔ）を分割してＮＡＬユニットフラグメント（Ｎａｌｆ）を生成する。なお、分割処理は、例えばＭＡＣフレームの一般的なＭＴＵに従い、ＭＡＣフレームとした場合のペイロードが約１５００バイト以下となるように分割処理を実行する。
【０１８１】
（ステップＳ１０６）
次に、送信装置は、メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットと、ＮＡＬユニットフラグメントを格納したメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのパケットヘッダを生成する。
これは、先に図１６、図１７、図１８を参照して説明したＨＴＴＰヘッダ情報の生成処理である。
【０１８２】
メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのＨＴＴＰヘッダには、以下の情報を記録する。
まず、このＨＴＴＰパケットがメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであることを示すＮＡＬユニットフラグメントヘッダを記録する。
さらに、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報に相当するムービーフラグメントシーケンス番号を記録する。このシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号をそのままコピーして記録する。
さらに、アクセスポイント情報「Ｘ−ＳＡＰ」を記録する。
このアクセスポイント情報は、このＨＴＴＰパケットの生成元となったサブＧＯＰセグメントに格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。
【０１８３】
一方、メディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのパケットヘッダには以下の情報を記録する。
ＧＯＰ内位識別情報：ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータであり、
先頭領域の場合は、「Ｘ−ＳｔａｒｔＯｆＧＯＰ」、
中間領域の場合は、「Ｘ−ＭｉｄｄｌｅＯｆＧＯＰ」、
末尾領域の場合は、「Ｘ−ＥｎｄＯｆＧＯＰ」、
これらのいずれかのデータを記録する。
【０１８４】
ムービーフラグメントシーケンス番号：上述したように、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号であり、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。このシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号をそのままコピーして記録する。
【０１８５】
ＮＡＬユニット内位置識別情報：パケットに格納したＮＡＬユニットフラグメント（ＮＡＬｆ）が、分割前のＮＡＬユニットのどの位置に対応するフラグメントであるかを示す情報である。
【０１８６】
アクセスポイント情報「Ｘ−ＳＡＰ」：アクセスポイント情報は、このＨＴＴＰパケットの生成元となったサブＧＯＰセグメントに格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。
【０１８７】
送信装置は、ステップＳ１０６において、上記のように、メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットと、ＮＡＬユニットフラグメントを格納したメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットのパケットヘッダを生成する。
【０１８８】
（ステップＳ１０７）
次に、送信装置は、ステップＳ１０７においてステップＳ１０６で生成したＨＴＴＰヘッダを設定した以下のＨＴＴＴＰパケットを生成する。
メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット
メディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット
これらの各ＨＴＴＰパケットを生成する。
【０１８９】
（ステップＳ１０８〜Ｓ１０９）
次に、送信装置は、生成したＨＴＴＰパケットに対して、ＬＣＴヘッダ、ＵＤＰヘッダ、ＩＰヘッダを設定してＩＰパケットを生成して送信する。送信処理は、インターネット等の通信ネットワークまたは放送波のいずれか、または両通信路を介して実行する。
【０１９０】
なお、図１９に示すフローは、メディアセグメントに基づいて生成するパケットの生成と送信処理シーケンスを説明するフローである。初期化セグメントに基づくパケット生成に際しては、初期化セグメントの構成データの生成の後、ＨＴＴＰヘッダに初期化セグメントであることを示すセグメント識別子を記録する処理などを行なうことになる。
【０１９１】
次に、図２０、図２１に示すフローチャートを参照して受信装置において実行するパケット受信からコンテンツ再生に至るまでの処理シーケンスについて説明する。
この処理は、受信装置３０のデータ処理部において実行する。データ処理部は、プログラム実行機能を有するＣＰＵを備え、例えば記憶部に格納されたプログラムに従って、図２０〜図２１に示すフローに従った処理を実行する。
以下、各ステップの処理について、順次、説明する。
【０１９２】
（ステップＳ２０１）
まず、ステップＳ２０１において、受信装置は、ユーザによる再生コンテンツの指定情報を入力する。例えば予め送信装置から受信している番組表等のコンテンツ一覧リストを表示部に表示し、この表示情報に対するユーザ入力情報に基づいて再生コンテンツを決定する。
【０１９３】
（ステップＳ２０２）
次に受信装置は、再生対象として選択された選択コンテンツに対応する初期化セグメントを含むパケットを受信して初期化セグメントを取得する。
なお、先に図９を参照して説明したように初期化セグメントを格納したＨＴＴＰパケットのＨＴＴＰヘッダには、セグメント識別情報が記録されており、この識別情報を参照することで初期化セグメントを格納したＨＴＴＰパケットであることが確認できる。
【０１９４】
（ステップＳ２０３）
受信装置は、受信した初期化セグメントの格納データに従って受信装置の初期化処理を実行する。具体的には初期化セグメントに格納されたコーデック設定パラメータ等を取得し、取得パラメータに従ってコーデックの設定等を行う。
【０１９５】
（ステップＳ２０４）
次に、受信装置は、ステップＳ２０１で選択した選択コンテンツに対応するサブＧＯＰメディアセグメントの分割パケットである以下のパケットを受信する。
メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットを格納したＩＰパケット、
メディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットを格納したＩＰパケット、
これらの各パケットを受信する。
【０１９６】
（ステップＳ２０５）
次に、受信装置は、受信パケットのＨＴＴＰヘッダからパケットに格納されたデータの以下の属性情報を取得する。
＊ＮＡＬユニットフラグメントヘッダ
＊ＧＯＰ内位置識別情報
＊ムービーフラグメントシーケンス番号
＊ＮＡＬユニット内位置識別情報
＊アクセスポイント情報
【０１９７】
上述したように、ＮＡＬユニットフラグメントヘッダは、ＨＴＴＰパケットがメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであることを示す情報である。
ＧＯＰ内位識別情報は、ＨＴＴＰパケットに格納されたメディアデータ（ｍｄａｔ）が１つのＧＯＰのどの位置にあるかを示すデータである。
ムービーフラグメントシーケンス番号は、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号であり、サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。
ＮＡＬユニット内位置識別情報は、パケットに格納したＮＡＬユニットフラグメント（ＮＡＬｆ）が、分割前のＮＡＬユニットのどの位置に対応するフラグメントであるかを示す情報である。
アクセスポイント情報「Ｘ−ＳＡＰ」は、このＨＴＴＰパケットの生成元となったサブＧＯＰセグメントに格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれるか否かを示す情報である。
【０１９８】
（ステップＳ２０６）
次に、受信装置は、ステップＳ２０６において、アクセスポイントデータを優先して復号、再生を行なう特殊再生を実行するか否かを判定する。
例えば、ランダムアクセス再生処理などのコンテンツ途中からの再生処理などの特殊再生処理を実行するか否かを判定する。この判定処理はユーザの入力情報等に基づいて決定する。
特殊再生処理を実行する場合は、ステップＳ２０７に進む。通常再生処理を実行する場合はステップＳ２０８に進む。
【０１９９】
（ステップＳ２０７）
ステップＳ２０６において、ランダムアクセス再生処理などの特殊再生処理を実行すると判定した場合ステップＳ２０７に進む。ステップＳ２０７では、パケットのＨＴＴＰヘッダに記録されたアクセスポイント情報［Ｘ−ＳＡＰ］が、アクセスポイントありのデータを示すパケットを選択する。すなわち、ＨＴＴＰパケットの生成元となったサブＧＯＰセグメントに格納されたＮＡＬユニットにランダムアクセスポイントとなるデータが含まれることを示すパケットを復号対象として選択して、復号処理を実行して再生処理を行なう。
この場合、ＧＯＰ全体を揃えることなく復号再生することが可能となる。
ステップＳ２０７の処理の後、ステップＳ２１１に進む。
【０２００】
（ステップＳ２０８）
一方、ステップＳ２０６において、ランダムアクセス再生処理などの特殊再生処理を実行せず、通常再生処理を実行すると判定した場合ステップＳ２０８に進む。ステップＳ２０８では、受信装置は、ＨＴＴＰヘッダから取得した識別情報に従って、受信した複数のメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットに格納されたＮＡＬユニットフラグメントを再配列し、ＧＯＰ単位データ再構築する。
【０２０１】
（ステップＳ２０９〜Ｓ２１０）
次に、受信装置は、再構築したＧＯＰデータに対する復号処理を実行し、復号データの再生処理を行なう。
【０２０２】
（ステップＳ２１１）
次に、受信装置は、データ再生処理が終了したか否かを判定し、終了していない場合は、ステップＳ２０４に戻り、ステップＳ２０４以下の処理を繰り返し実行する。
ステップＳ２１１において再生処理終了と判定した場合は処理を終了する。
【０２０３】
なお、例えばランダムアクセス再生等、特定の再生位置の画像のみを再生する場合には、メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットにランダムアクセスポイント情報であるｓｉｄｘデータを参照し、ｓｉｄｘデータから算出される１以上のＮＡＬユニットフラグメント（ＮＡＬｆ）のみを処理対象として処理を行なうことができる。すなわち例えばＩピクチャに相当する符号化画像データのみを選択して、これを復号して再生する処理を実行する。
この場合、ＧＯＰ全体データを再配列する処理を行なうことなくランダムアクセスポイントのデータのみを選択して再生することが可能である。
【０２０４】
［１０．拡張ヘッダに付加情報を記録した実施例について］
上述した実施例では、ＮＡＬユニットフラグメント（ＮＡＬｆ）の配列やＧＯＰ再構成処理に適用する情報、さらにアクセスポイント情報等、受信装置側における処理をスムーズに実行させるための付加情報をＨＴＴＰパケットに設定した実施例について説明した。
しかし、付加情報の記録先はＨＴＴＰヘッダに限らず、様々な記録先とすることが可能である。
以下、拡張ヘッダに付加情報を記録した実施例について説明する。
【０２０５】
図２２、図２３を参照して、拡張ヘッダに付加情報を記録した実施例について説明する。
図２２、図２３に示す例は、ＨＴＴＰヘッダに後続するパケット領域に新たな拡張ヘッダを挿入し、この拡張ヘッダに付加情報を記録した例である。
【０２０６】
図２２には、
拡張ヘッダに記録する付加情報のリストを示しており、図２３には、拡張ヘッダを有する３種類のＨＴＴＰパケットの例を示している。
図２３には、
（１）初期化セグメントＨＴＴＰパケット、
（２）メディアセグメントベースのメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット、
（３）メディアセグメントベースのメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット、
これらの３種類のＨＴＴＰパケットの例を示している。
各パケットのＨＴＴＰヘッダの次に拡張ヘッダを設定している。
【０２０７】
この拡張ヘッダに、図２２に示すリストに従った付加情報を記録する。記録する付加情報の例について、図２２を参照して説明する。図２２に示すように付加情報は以下の情報から構成される。
（ａ）セグメント識別情報（Ｉｎｉｔｉａｌｉｚａｔｉｏｎ  Ｓｅｇｍｅｎｔ  Ｉｄｅｎｔｉｆｉｅｒ）、
（ｂ）ＧＯＰ内位置識別情報（Ｓｕｂ  ＧＯＰ  Ｉｎｄｉｃａｔｏｒ）、
（ｃ）ムービーフラグメントシーケンス番号（Ｍｏｖｉｅ  Ｆｒａｇｍｅｎｔ  Ｓｅｑｕｅｎｃｅ  Ｎｕｍｂｅｒ）、
（ｄ）ＮＡＬユニットフラグメントヘッダ（ＮＡＬＵ  Ｆｒａｇｍｅｎｔ  Ｓｕｂ  Ｓｅｇｍｅｎｔ  Ｈｅａｄｅｒ）、
（ｅ）ＮＡＬユニット内位置識別情報（ＮＡＬＵ  Ｆｒａｇｍｅｎｔ  Ｉｄｅｎｔｉｆｉｅｒ）
（ｆ）アクセスポイント情報（ＳＡＰＩｎｄｉｃａｔｏｒ）
【０２０８】
例えば（ａ）セグメント識別情報は、８ビットデータとし、初期化セグメントの場合は１を設定し、その他のセグメントの場合は０を設定する。
なお、メディアセグメントの場合、ＨＴＴＰヘッダに記録されるコンテンツ位置情報（ＣｏｎｔｅｎｔＬｏｃａｔｉｏｎ）をＧＯＰ単位データの位置情報に設定すれば、このコンテンツ位置情報を参照することで各ＧＯＰデータの区別が可能となる。
【０２０９】
（ｂ）ＧＯＰ内位置識別情報は、８ビットデータとして、例えば、ビット値を以下の設定とする。
ＧＯＰの先頭位置のデータ（ＳｔａｒｔｏｆＧＯＰ）＝１
ＧＯＰの中間位置のデータ（ＭｉｄｄｌｅｏｆＧＯＰ）＝２
ＧＯＰの末尾位置のデータ（ＥｎｄｏｆＧＯＰ）＝３
【０２１０】
（ｃ）ムービーフラグメントシーケンス番号は、３２ビットデータとし、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号を記録する。サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。
【０２１１】
（ｄ）ＮＡＬユニットフラグメントヘッダは、８ビットデータとしテ、メタデータ格納型ＮＡＬユニットフラグメント対応パケット＝１、その他のパケット＝０として記録する。
【０２１２】
（ｅ）ＮＡＬユニット内位置識別情報は、８ビットデータとして、パケットに格納したＮＡＬユニットフラグメント（ＮＡＬｆ）が、分割前のＮＡＬユニットのどの位置に対応するフラグメントであるかを示す情報を記録する。
分割前のＮＡＬユニットの先頭位置（ＳｔａｒＮＡＬＵｎｉｔＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ）＝１、
分割前のＮＡＬユニットの中間位置（ＭｉｄｄｌｅＮＡＬＵｎｉｔＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ）＝２、
分割前のＮＡＬユニットの末尾位置（ＥｎｄＮＡＬＵｎｉｔＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ）＝３、
この設定で各ビット値を記録する。
【０２１３】
（ｆ）アクセスポイント情報（ＳＡＰＩｎｄｉｃａｔｏｒ）は、ＨＴＴＰヘッダの記録情報として説明した［Ｘ−ＳＡＰ］と同様のデータであり、８ビットデータとする。パケットが、アクセスポイントを含むＮＡＬユニット格納セグメントから生成したパケットである場合は［１］、その他のパケットである場合は［０］を記録する。
【０２１４】
図２３には、
（１）初期化セグメントＨＴＴＰパケット、
（２）メディアセグメントベースのメタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット、
（３）メディアセグメントベースのメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケット、
これらの３種類のＨＴＴＰパケットの拡張ヘッダに、図２２に示す（ａ）〜（ｆ）の各付加情報を設定した例を示している。
【０２１５】
送信装置は、このような拡張ヘッダを設定して受信装置に送信する。一方、受信装置は、この拡張ヘッダのセグメント識別情報を参照して、パケットに格納されたセグメントが初期化セグメントを格納したＨＴＴＰパケットであるか、メタデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであるか、メディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであるかを判別する。
【０２１６】
さらに、受信装置は、パケットがメディアデータ格納型ＮＡＬユニットフラグメント対応ＨＴＴＰパケットであると識別した場合、拡張ヘッダのＧＯＰ内位置識別情報や、ＮＡＬユニット内位置識別情報を参照することで、各ＮＡＬユニットフラグメント（ＮＡＬｆ）の再配列、さらにＧＯＰの再構築を行うことが可能となる。
【０２１７】
さらに、アクセスポイント情報（ＳＡＰＩｎｄｉｃａｔｏｒ）を参照することで、パケットが、アクセスポイントを含むＮＡＬユニット格納セグメントから生成したパケットであるか否かを判定することができる。
【０２１８】
［１１．ＬＣＴヘッダに付加情報を記録した実施例について］
前述したように、マルチキャストやブロードキャスト（ＭＣ／ＢＣ）型のストリーミングに適用可能なトランスポートプロトコルには、例えばＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）やＦＬＵＴＥ（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ  Ｔｒａｎｓｐｏｒｔ）がある。
【０２１９】
ＦＬＵＴＥプロトコルに従って設定されるパケットには、ＦＬＵＴＥプロトコルに従ったヘッダ情報であるＬＣＴヘッダが設定される。
すなわち、先に図１０を参照して説明したＩＰパケット内のＬＣＴヘッダである。
以下、このＬＣＴヘッダに、ＮＡＬユニットフラグメント（ＮＡＬｆ）の再配列や、ＧＯＰ再構成処理に適用する情報等、受信装置側における処理をスムーズに実行させるための付加情報を記録した実施例について説明する。
【０２２０】
ＦＬＵＴＥプロトコルに従って設定されるＬＣＴヘッダの構成例を図２４に示す。
ＬＣＴヘッダに設定される主なデータフィールドには、例えば以下のフィールドがある。
ＣＣＩ（Ｃｏｎｇｅｓｔｉｏｎ  Ｃｏｎｔｒｏｌ  Ｉｎｆｏｒｍａｔｉｏｎ）：各フィールドの長さや輻輳制御情報等を記録するフィールドである。
ＴＳＩ（Ｔｒａｎｓｐｏｒｔ  Ｓｅｓｓｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒ）：パケット転送のセッション情報を記録するフィールドである。
ＴＯＩ（Ｔｒａｎｓｐｏｒｔ  Ｏｂｊｅｃｔ  Ｉｄｅｎｔｉｆｉｅｒ）：パケット転送のシーケンス等を記録するフィールドである。
ヘッダ拡張部（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎｓ）：様々な拡張データを記録することができるフィールドである。
【０２２１】
先に、図７を参照して説明したように、ＧＯＰ内位置情報の代用として、上記のＴＯＩを参照して、データ送信順を確認することが可能である。
前述したように、例えばＨＴＴＰヘッダ等に記録する付加情報であるＧＯＰ内位置情報について、先頭位置を示すＸ−ＳｔａｒｔｏｆＧＯＰのみを記録し、その他のＧＯＰ内データの配列順は、ＬＣＴヘッダ内のＴＯＩを参照してパケットシーケンスを取得し、パケットシーケンスに従ってＧＯＰ内のＮＡＬユニットを正しい順に配列する構成としてもよい。
【０２２２】
同様に、ＮＡＬユニットフラグメント（ＮＡＬｆ）の配列情報についても上記のＴＯＩを参照して、データ送信順を確認して再配列を行うことが可能である。例えばＨＴＴＰヘッダ等に記録する付加情報であるＮＡＬユニット内位置識別情報を、先頭位置のＮＡＬユニットフラグメントを格納したパケットのみ、ＨＴＴＰヘッダに記録する。後続のＮＡＬユニットフラグメント配列は、ＬＣＴヘッダのＴＯＩからパケットシーケンスを解析して配列することが可能である。
【０２２３】
図２４に示すように、ＬＣＴヘッダ内には様々なデータを記録できるヘッダ拡張部（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎｓ）が設定される。このヘッダ拡張部にＮＡＬユニットフラグメントの再配列や、ＧＯＰ再構成処理に適用する情報等、受信装置側における処理をスムーズに実行させるための付加情報を記録することが可能である。
【０２２４】
ＬＣＴヘッダのヘッダ拡張部に対するデータ記録構成について、図２５を参照して説明する。
ＬＣＴヘッダのヘッダ拡張部に、データを記録する場合のフォーマットには２つの種類がある。
図２５（１）は、記録情報の長さが自由に設定可能なフォーマットである。
図２５（２）は、記録情報の長さが固定されたフォーマットである。
【０２２５】
ＨＥＴ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｔｙｐｅ）には、拡張ヘッダの種類を示す拡張ヘッダ識別情報（数値）を記録する。図２５（１）のフォーマットは１２７までの値が利用可能であり、図２５（２）のフォーマットは１２８以上に設定することが規定されている。
ＨＥＴ（Ｈｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｌｅｎｇｔｈ）には、拡張ヘッダの長さを記録する。
ＨＥＣ（Ｎｅａｄｅｒ  Ｅｘｔｅｎｓｉｏｎ  Ｃｏｎｔｅｎｔ）は、拡張ヘッダコンテンツを記録するフィールドであり、任意の拡張情報を記録可能なフィールドである。
【０２２６】
図２５（２）に示す記録情報の長さが固定されたフォーマットを利用して、ＮＡＬユニットフラグメントの再配列や、ＧＯＰ再構成処理に適用する情報等、受信装置側における処理をスムーズに実行させるための付加情報を記録する場合の記録データの構成例を図２６に示す。
【０２２７】
図２６に示すように、
（ａ）拡張ヘッダ識別情報（ＨＥＴ）は、８ビットデータとして、新たな情報の識別値として、例えば［２００］を記録する。
さらに、拡張情報記録部（ＨＥＣ）に、
（ｂ）セグメント識別情報、
（ｃ）ＧＯＰ内位置識別情報、
（ｄ）ムービーフラグメントシーケンス番号、
（ｅ）ＮＡＬユニットフラグメントヘッダ、
（ｆ）ＮＡＬユニット内位置識別情報、
（ｇ）アクセスポイント情報
これらの各識別情報を記録する。
【０２２８】
例えば（ｂ）セグメント識別情報は、８ビットデータとし、初期化セグメントの場合は１を設定し、その他のセグメントの場合は０を設定する。
なお、メディアセグメントの場合、ＨＴＴＰヘッダに記録されるコンテンツ位置情報（ＣｏｎｔｅｎｔＬｏｃａｔｉｏｎ）をＧＯＰ単位データの位置情報に設定すれば、このコンテンツ位置情報を参照することで各ＧＯＰデータの区別が可能となる。
【０２２９】
（ｃ）ＧＯＰ内位置識別情報は、８ビットデータとして、例えば、ビット値を以下の設定とする。
ＧＯＰの先頭位置のデータ（ＳｔａｒｔｏｆＧＯＰ）＝１
ＧＯＰの中間位置のデータ（ＭｉｄｄｌｅｏｆＧＯＰ）＝２
ＧＯＰの末尾位置のデータ（ＥｎｄｏｆＧＯＰ）＝３
【０２３０】
（ｄ）ムービーフラグメントシーケンス番号は、３２ビットデータとし、分割前のサブＧＯＰメディアセグメントのメタデータ（ｍｏｏｆ）に記録されたシーケンス番号を記録する。サブＧＯＰメディアセグメントに格納されたＮＡＬユニットの配列情報である。
【０２３１】
（ｅ）ＮＡＬユニットフラグメントヘッダは、８ビットデータとしテ、メタデータ格納型ＮＡＬユニットフラグメント対応パケット＝１、その他のパケット＝０として記録する。
【０２３２】
（ｆ）ＮＡＬユニット内位置識別情報は、８ビットデータとして、パケットに格納したＮＡＬユニットフラグメント（ＮＡＬｆ）が、分割前のＮＡＬユニットのどの位置に対応するフラグメントであるかを示す情報を記録する。
分割前のＮＡＬユニットの先頭位置（ＳｔａｒＮＡＬＵｎｉｔＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ）＝１、
分割前のＮＡＬユニットの中間位置（ＭｉｄｄｌｅＮＡＬＵｎｉｔＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ）＝２、
分割前のＮＡＬユニットの末尾位置（ＥｎｄＮＡＬＵｎｉｔＦｒａｇｍｅｎｔＳｕｂＳｅｇｍｅｎｔ）＝３、
この設定で各ビット値を記録する。
【０２３３】
（ｇ）アクセスポイント情報（ＳＡＰＩｎｄｉｃａｔｏｒ）は、ＨＴＴＰヘッダの記録情報として説明した［Ｘ−ＳＡＰ］と同様のデータであり、８ビットデータとする。パケットが、アクセスポイントを含むＮＡＬユニット格納セグメントから生成したパケットである場合は［１］、その他のパケットである場合は［０］を記録する。
【０２３４】
送信装置は、このような拡張ヘッダ情報を含むＬＣＴヘッダを設定して受信装置に送信する。一方、受信装置は、このＬＣＴヘッダ内の拡張ヘッダ情報のセグメント識別情報を参照して、初期化セグメント格納パケットであるか、メタデータ格納型ＮＡＬユニットフラグメント対応パケットであるか、メディアデータ格納型ＮＡＬユニットフラグメント対応パケットであるかを判別する。さらに、受信装置は、パケットがメディアデータ格納型ＮＡＬユニットフラグメント対応パケットであると識別した場合、ＬＣＴヘッダの拡張ヘッダ情報に記録されたＮＡＬユニット内位置識別情報や、ＧＯＰ内位置識別情報を参照することで、各パケットに格納されたメディアデータ（ｍｄａｔ）であるＮＡＬユニットフラグメント（ＮＡＬｆ）を正しい配列とする再配列を行い、さらにＧＯＰの再構成を行うことが可能となる。
【０２３５】
さらに、アクセスポイント情報（ＳＡＰＩｎｄｉｃａｔｏｒ）を参照することで、パケットが、アクセスポイントを含むＮＡＬユニット格納セグメントから生成したパケットであるか否かを判定することができる。
【０２３６】
［１２．ＨＥＶＣ符号化データに対する適用例について］
上述した実施例では、ＭＰＥＧ符号化方式に従ったＭＰ４符号化データに対する処理例について説明したが、本開示の処理は、その他の符号化データに足しても適用可能である。例えばＨＥＶＣ（Ｈｉｇｈ  Ｅｆｆｉｃｉｅｎｃｙ  Ｖｉｄｅｏ  Ｃｏｄｉｎｇ）に従った符号化データに適用することが可能である。
【０２３７】
ＨＥＶＣ符号化データの構成について、図２７を参照して説明する。
図２７に示すように、ＨＥＶＣ符号化処理によって生成される１つのＨＥＶＣストリームは、複数のシーケンス（ＣＶＳ：Ｃｏｄｅｄ  Ｖｉｄｅｏ  Ｓｅｑｕｅｎｃｅ）と、Ｅｎｄ  ｏｆ  ｓｅｑｕｅｎｃｅ  ＮＡＬ  ｕｎｉｔ（ＥｏＢ）を有する。
【０２３８】
ＨＥＶＣストリームの構成要素であるＣＶＳは、複数のＧＯＰと、Ｅｎｄ  ｏｆ  ｓｅｑｕｅｎｃｅ  ＮＡＬ  ｕｎｉｔ（ＥｏＳ）から構成される。
１つのＧＯＰは、ランダムアクセスポイントとなるＩＲＡＰ（Ｉｎｔｒａ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）アクセスユニットを先頭データとし、複数のＬＰ（Ｌｅａｄｉｎｇ  Ｐｉｃｔｕｒｅ）アクセスユニットと、ＴＰ（Ｔｒａｉｌｉｎｇ  Ｐｉｃｔｕｒｅ）アクセスユニットを有する。
【０２３９】
ＬＰアクセスユニットと、ＴＰアクセスユニットは、何らかの参照ピクチャを参照して復号可能なアクセスユニットである。
ただし、ＩＲＡＰアクセスユニットから復号を開始した場合には、ＴＰＡＵについても正常な復号、再生が可能である。
【０２４０】
アクセスユニット（ＡＵ）は、複数のＮＡＬユニット（Ｎｅｔｗｏｒｋ  Ａｂｓｔｒａｃｔｉｏｎ  Ｌａｙｅｒ  Ｕｎｉｔ）から構成され、アクセスユニット（ＡＵ）は、必ず１つ以上のスライスセグメントＮＡＬユニットを含む。
【０２４１】
図２７に示すように、ＨＥＶＣ符号化処理によって生成される符号化データにも符号化処理単位としてのＧＯＰが設定され、このＧＯＰは、さらに複数のＮＡＬユニットに分割される。
先に図５を参照して説明したサブＧＯＰメディアセグメントに、ＨＥＶＣ符号化データにおいて設定されるＧＯＰ構成データであるＮＡＬユニットを１つ、または複数、格納する構成とする。
【０２４２】
さらに、先に図１６他を参照して説明したようにＮＡＬユニットをさらに分割したＮＡＬユニットフラグメント（ＮＡＬｆ）を生成して、ＨＴＴＰパケットに分割格納することが可能である。
【０２４３】
このように、ＨＥＶＣ符号化データについても、ＧＯＰデータの分割データであるＮＡＬユニットをさらに分割したＮＡＬユニットフラグメント（ＮＡＬｆ）が生成可能である。従って、図１６他を参照して説明した処理が可能であり、本開示の処理を適用することができる。
なお、ＭＰ４、ＨＥＶＣに限らず、ＧＯＰ相当の符号化処理単位を持ち、ＧＯＰデータを分割したユニット（ＮＡＬ）が設定される符号化構成であれば、本開示の処理を適用することが可能である。
【０２４４】
［１３．各装置のハードウェア構成例について］
最後に、図２８を参照して、上述した処理を実行する各装置のハードウェア構成例について説明する。
図２８は、送信装置２０、受信装置３０として適用可能な通信装置のハードウェア構成例を示している。
【０２４５】
ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）２０１は、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）２０２、または記憶部２０８に記憶されているプログラムに従って各種の処理を実行するデータ処理部として機能する。例えば、上述した実施例において説明したシーケンスに従った処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）２０３には、ＣＰＵ２０１が実行するプログラムやデータなどが記憶される。これらのＣＰＵ２０１、ＲＯＭ２０２、およびＲＡＭ２０３は、バス２０４により相互に接続されている。
【０２４６】
ＣＰＵ２０１はバス２０４を介して入出力インタフェース２０５に接続され、入出力インタフェース２０５には、各種スイッチ、キーボード、マウス、マイクロホンなどよりなる入力部２０６、ディスプレイ、スピーカなどよりなる出力部２０７が接続されている。ＣＰＵ２０１は、入力部２０６から入力される指令に対応して各種の処理を実行し、処理結果を例えば出力部２０７に出力する。
【０２４７】
入出力インタフェース２０５に接続されている記憶部２０８は、例えばハードディスク等からなり、ＣＰＵ２０１が実行するプログラムや各種のデータを記憶する。通信部２０９は、インターネットやローカルエリアネットワークなどのネットワークを介したデータ通信の送受信部、さらに放送波の送受信部として機能し、外部の装置と通信する。
【０２４８】
入出力インタフェース２０５に接続されているドライブ２１０は、磁気ディスク、光ディスク、光磁気ディスク、あるいはメモリカード等の半導体メモリなどのリムーバブルメディア２１１を駆動し、データの記録あるいは読み取りを実行する。
【０２４９】
なお、データの符号化あるいは復号は、データ処理部としてのＣＰＵ２０１の処理として実行可能であるが、符号化処理あるいは復号処理を実行するための専用ハードウェアとしてのコーデックを備えた構成としてもよい。
【０２５０】
［１４．本開示の構成のまとめ］
以上、特定の実施例を参照しながら、本開示の実施例について詳解してきた。しかしながら、本開示の要旨を逸脱しない範囲で当業者が実施例の修正や代用を成し得ることは自明である。すなわち、例示という形態で本発明を開示してきたのであり、限定的に解釈されるべきではない。本開示の要旨を判断するためには、特許請求の範囲の欄を参酌すべきである。
【０２５１】
なお、本明細書において開示した技術は、以下のような構成をとることができる。
（１）  符号化データを格納したパケットを生成するデータ処理部と、
前記データ処理部の生成したパケットを送信する通信部を有し、
前記データ処理部は、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、
パケットに対する付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定したパケットを生成して前記通信部を介して送信する通信装置。
【０２５２】
（２）前記アクセスポイント情報は、パケット格納データが、ＳＡＰ（Ｓｔｒｅｅｍｉｎｇ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）によって指定される符号化データを含むＮＡＬユニットに基づいて生成されたデータであるか否かを示す情報である前記（１）に記載の通信装置。
【０２５３】
（３）前記データ処理部は、ＧＯＰの構成データであるＮＡＬユニットを１つ以上含むメディアデータと、該メディアデータ対応のメタデータを格納したサブＧＯＰメディアセグメントをパケット格納データとして生成する前記（１）または（２）に記載の通信装置。
【０２５４】
（４）前記データ処理部は、ＧＯＰを構成するＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを生成して、ＮＡＬユニットフラグメントを格納した複数のパケットと、前記ＮＡＬユニットに対応するメタデータを格納したパケットを生成する前記（１）または（２）に記載の通信装置。
【０２５５】
（５）前記データ処理部は、送信対象の符号化データを、通信経路上で規定される最大データ転送単位（ＭＴＵ：Ｍａｘｉｍｕｍ  Ｔｒａｎｓｆｅｒ  Ｕｎｉｔ）以下のデータに分割して生成した分割データを格納したパケットを生成する前記（１）〜（４）いずれかに記載の通信装置。
【０２５６】
（６）前記データ処理部は、ＨＴＴＰパケットを生成し、前記付加情報を生成パケット内のＨＴＴＰヘッダに記録する前記（１）〜（５）いずれかに記載の通信装置。
【０２５７】
（７）前記データ処理部は、前記付加情報を生成パケット内の拡張ヘッダに記録する前記（１）〜（５）いずれかに記載の通信装置。
【０２５８】
（８）前記データ処理部は、前記付加情報を生成パケット内のＬＣＴヘッダに記録する前記（１）〜（５）いずれかに記載の通信装置。
【０２５９】
（９）前記通信部は、前記データ処理部の生成したパケットを、放送波を介してブロードキャスト配信、またはマルチキャスト配信する前記（１）〜（８）いずれかに記載の通信装置。
【０２６０】
（１０）送信装置が送信した符号化データ格納パケットを受信する通信部と、
前記通信部の受信したパケットを入力して処理を実行するデータ処理部を有し、
前記通信部の受信する前記符号化データ格納パケットの各々は、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットであり、付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報が設定されたパケットである通信装置。
【０２６１】
（１１）前記データ処理部は、
受信パケットに記録された付加情報である前記アクセスポイント情報を参照して、受信パケットに格納されたデータが、ＳＡＰ（Ｓｔｒｅｅｍｉｎｇ  Ａｃｃｅｓｓ  Ｐｏｉｎｔ）によって指定される符号化データを含むＮＡＬユニットに基づいて生成されたデータであるか否かを判定する処理を実行する前記（１０）に記載の通信装置。
【０２６２】
（１２）前記データ処理部は、受信パケットに記録された付加情報である前記アクセスポイント情報を参照して、アクセスポイントを含むデータを選択取得して、復号、再生処理を実行する前記（１０）または（１１）に記載の通信装置。
【０２６３】
（１３）前記通信部は、前記付加情報をＨＴＴＰヘッダに記録したＨＴＴＰパケットを受信し、前記データ処理部は、受信パケットのＨＴＴＰヘッダから前記付加情報を取得する前記（１０）〜（１２）いずれかに記載の通信装置。
【０２６４】
（１４）前記通信部は、前記付加情報を拡張ヘッダに記録したパケットを受信し、
前記データ処理部は、受信パケットの拡張ヘッダから前記付加情報を取得する前記（１０）〜（１２）いずれかに記載の通信装置。
【０２６５】
（１５）前記通信部は、前記付加情報をＬＣＴヘッダに記録したパケットを受信し、前記データ処理部は、受信パケットのＬＣＴヘッダから前記付加情報を取得する前記（１０）〜（１２）いずれかに記載の通信装置。
【０２６６】
（１６）前記通信部は、前記パケットを、放送波を介して受信する前記（１０）〜（１５）いずれかに記載の通信装置。
【０２６７】
（１７）データ送信装置において実行する通信データ生成方法であり、
データ処理部が、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、
パケットに対する付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定したパケットを生成して通信部を介して送信する通信データ生成方法。
【０２６８】
（１８）データ受信装置において実行する通信データ処理方法であり、
通信部が、送信装置が送信した符号化データ格納パケットを受信するステップと、
データ処理部が、前記通信部の受信したパケットを入力して処理を実行するデータ処理ステップを実行し、
前記通信部の受信する前記符号化データ格納パケットの各々は、
符号化データの処理単位であるＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅｓ）を構成するＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットであり、付加情報として、パケットに格納したＮＡＬユニット、またはＮＡＬユニットフラグメントの分割元のＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報が設定されたパケットであり、
前記データ処理ステップは、前記通信部の受信したアクセスポイント情報が設定されたパケットを入力して処理を実行するステップである通信データ処理方法。
【０２６９】
また、明細書中において説明した一連の処理はハードウェア、またはソフトウェア、あるいは両者の複合構成によって実行することが可能である。ソフトウェアによる処理を実行する場合は、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれたコンピュータ内のメモリにインストールして実行させるか、あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させることが可能である。例えば、プログラムは記録媒体に予め記録しておくことができる。記録媒体からコンピュータにインストールする他、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介してプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることができる。
【０２７０】
なお、明細書に記載された各種の処理は、記載に従って時系列に実行されるのみならず、処理を実行する装置の処理能力あるいは必要に応じて並列的にあるいは個別に実行されてもよい。また、本明細書においてシステムとは、複数の装置の論理的集合構成であり、各構成の装置が同一筐体内にあるものには限らない。
【産業上の利用可能性】
【０２７１】
以上、説明したように、本開示の一実施例の構成によれば、通信パケットの格納符号化データが、ランダムアクセス可能な符号化データに基づくデータであるか否かをパケット単位で判別可能とした構成が実現される。
具体的には、送信装置が、符号化データの構成要素であるＮＡＬユニット、またはＮＡＬユニットをさらに分割したＮＡＬユニットフラグメントを格納したパケットを生成し、付加情報として、パケット格納データの元データであるＮＡＬユニットがランダムアクセスポイントとなるデータを含むか否かを示すアクセスポイント情報を設定して送信する。受信装置はパケット付加情報を参照してパケット格納データが、ランダムアクセス可能な符号化データに基づいて生成されたデータであるか否かを判別する。
本構成により、通信パケットの格納符号化データが、ランダムアクセス可能な符号化データに基づくデータであるか否かをパケット単位で判別可能とした構成が実現される。
【符号の説明】
【０２７２】
１０  通信システム
２０  送信装置
２１  データ処理部
２２  通信部
３０  受信装置
３１  データ処理部
３２  通信部
５０  初期化セグメント
６０  メディアセグメント
２０１  ＣＰＵ
２０２  ＲＯＭ
２０３  ＲＡＭ
２０４  バス
２０５  入出力インタフェース
２０６  入力部
２０７  出力部
２０８  記憶部
２０９  通信部
２１０  ドライブ
２１１  リムーバブルメディア
【図１】
2015136059.tif 000003
【図２】
2015136059.tif 000004
【図３】
2015136059.tif 000005
【図４】
2015136059.tif 000006
【図５】
2015136059.tif 000007
【図６】
2015136059.tif 000008
【図７】
2015136059.tif 000009
【図８】
2015136059.tif 000010
【図９】
2015136059.tif 000011
【図１０】
2015136059.tif 000012
【図１１】
2015136059.tif 000013
【図１２】
2015136059.tif 000014
【図１３】
2015136059.tif 000015
【図１４】
2015136059.tif 000016
【図１５】
2015136059.tif 000017
【図１６】
2015136059.tif 000018
【図１７】
2015136059.tif 000019
【図１８】
2015136059.tif 000020
【図１９】
2015136059.tif 000021
【図２０】
2015136059.tif 000022
【図２１】
2015136059.tif 000023
【図２２】
2015136059.tif 000024
【図２３】
2015136059.tif 000025
【図２４】
2015136059.tif 000026
【図２５】
2015136059.tif 000027
【図２６】
2015136059.tif 000028
【図２７】
2015136059.tif 000029
【図２８】
2015136059.tif 000030