JP2004312713A - データ送信装置 - Google Patents

Abstract

【課題】 データ受信装置に対してコンテンツデータの適切な再生処理を実行させるデータ送信装置を提供する。
【解決手段】 データ送信装置１００は、データ受信装置に対してコンテンツデータの適切な再生処理を実行させるものであって、そのデータ受信装置との間でコンテンツデータの伝送路の確立及び初期化を行い、その後、再生制御情報をＭＰ４ファイルから取り出して、データ受信装置に送信するファイル解析部１１０及びＲＴＳＰ処理部１０１と、ファイル解析部１１０を介してＭＰ４ファイルからコンテンツデータを取得してパケット化するＲＴＰ作成部１０２と、ＲＴＰ作成部１０２によりパケット化されたコンテンツデータを送信するＲＴＰ送出部１０３とを備える。
【選択図】 図１

Description

本発明は、動画像や音声、テキストなどのデジタルコンテンツデータをパケット化して伝送するデータ送信装置に関する。

近年、通信ネットワークの大容量化および伝送技術の進歩により、インターネット上でのＰＣ（Personal Computer）向け動画配信サービスが普及してきた。また、無線網における受信端末の規格を定める国際標準化団体である３ＧＰＰ(Third Generation Partnership Project)における規格としてＴＳ２６．２３４(Transparent end-to-end packet switched streaming service)が定められるなど、携帯端末においても動画配信サービスの拡大が見込まれる。音声、動画、静止画、およびテキストなどのメディアデータが蓄積及び配信される際には、メディアデータの再生および配信に必要なヘッダ情報とメディアデータとが多重化される。そのための多重化ファイルフォーマットとしてＭＰ４が標準化された。ＭＰ４は、ISO/IEC JTC1/SC29/WG 11 (International Standardization Organization/International Engineering Consortium)において標準化された多重化ファイルフォーマットであり、３ＧＰＰのＴＳ２６．２３４においても採用されている。ＭＰ４を用いた動画配信サービスには２種類ある。

上記２種類の動画配信サービスのうちの１つの種類は、ＭＰ４ファイルを直接送受信するダウンロード型と呼ばれる方式である。現在のところ、無線端末上の動画配信ではこの方式が主流である。しかし、この動画配信サービスには、ファイルサイズが大きい長時間コンテンツの配信には適さない、また、早送りなどの特殊再生ができないといった欠点がある。

上記２種類の動画配信サービスのうちの他の１つの種類は、ストリーミング型と呼ばれる方式であり、ダウンロード型における問題点を解決する方式として、無線端末上でのサービスが開始されようとしている。ストリーミング型で使用されるＭＰ４ファイルは、ダウンロード型のＭＰ４ファイルにおいて多重化されるメディアデータに加えて、メディアデータをパケット化するためのヒントデータと呼ばれる情報が格納される。

ストリーミング型の動画配信サービスでは、ＭＰ４ファイル自体が配信されるのではなく、サーバ側がヒントデータを参照してメディアデータをパケット化し、パケット化されたメディアデータが端末に向けて配信される。なお、ヒントデータの枠組みについては、アップル社より開示されている（例えば、特許文献１参照。）。このように、ストリーミング型の動画配信サービスは、メディアデータ（コンテンツデータ）をパケット化して配信するため、長時間コンテンツの配信に適している。さらに、この動画配信サービスは、サーバがコンテンツの任意時間のデータを選択して配信することができるため、早送りや飛び込み再生などの特殊再生にも適している。

以下に、ＭＰ４ファイルを使用したストリーミング型の動画配信サービスについて詳細に説明する。
ＭＰ４では、ヘッダやメディアデータはＢｏｘと呼ばれるオブジェクト単位で格納される。

図１０は、Ｂｏｘの構造を説明するための図である。Ｂｏｘは、ｓｉｚｅフィールドと、ｔｙｐｅフィールドと、ｖｅｒｓｉｏｎフィールドと、ｆｌａｇｓフィールドと、データフィールドとを含む。

ｓｉｚｅフィールドには、そのｓｉｚｅフィールドも含めたＢｏｘ全体のサイズが格納される。
ｔｙｐｅフィールドには、Ｂｏｘの識別子（通常はアルファベット４文字）が格納される。フィールド長は４バイトである。ＭＰ４ファイル内でのＢｏｘの検索は、連続する４バイト分のデータがｔｙｐｅフィールドの識別子と一致するかどうかを判定することにより行われる。

ｖｅｒｓｉｏｎフィールドには、Ｂｏｘのバージョン番号が格納される。ｆｌａｇｓフィールドには、Ｂｏｘ毎に設定されるフラグ情報が格納される。データフィールドには、ヘッダ情報やメディアデータが格納される。なお、ｖｅｒｓｉｏｎフィールドとｆｌａｇｓフィールドは必須でないため、Ｂｏｘによってはこれらのフィールドは存在しない。

以後、Ｂｏｘの参照にはｔｙｐｅフィールドの識別子を使用することとし、例えばその識別子が‘ｍｏｏｖ’であるＢｏｘをｍｏｏｖと呼ぶ。
図１１は、ＭＰ４ファイルの構造を示すデータ構成図である。

ＭＰ４ファイルは、図１１の（ａ）に示すように、ｆｔｙｐ，ｍｏｏｖ，及びｍｄａｔの３つのＢｏｘから構成され、ｆｔｙｐがファイルの先頭に配置される。ｆｔｙｐは、ＭＰ４ファイルを識別するための情報を含む。ｍｄａｔはメディアデータおよびヒントデータを格納する。ヒントデータとは、メディアデータをＲＴＰ（Real Time Transmission Protocol）パケット化して伝送するために必要な情報である。サーバはヒントデータを参照してメディアデータをＲＴＰパケット化して配信する。なお、ｍｄａｔに含まれる各メディア及びヒントデータはそれぞれ、トラックと呼ばれ、各トラックはトラックＩＤにより識別される。

また、ＭＰ４では、サンプルと呼ばれる単位でデータが取り扱われる。メディアトラックでは、ビデオやオーディオの１枚又は複数のフレームがサンプルに相当し、ヒントトラックでは、１つ以上のＲＴＰパケットを作成するための情報がサンプルに相当する。

ｍｏｏｖにはｍｄａｔの各トラックに含まれるサンプルについてのヘッダ情報が格納される。ＭＰ４ファイルにおいてｍｏｏｖの使用は必須であり、その個数は１つである。図１１の（ｂ）に示すように、ｍｏｏｖ内にはＢｏｘが階層的に配置されており、ファイル全体に共通なヘッダ情報はｍｖｈｄに格納される。さらに、オーディオ、ビデオ、および各メディアのトラックに関連するヒントトラックのヘッダ情報は、それぞれ別々のｔｒａｋに格納される。ここで、トラックの識別情報であるトラックＩＤはｔｒａｋ内のｔｋｈｄによって示される。ｔｒａｋは、図１１の（ｃ）に示すように構成され、サンプルのサイズや復号時間、表示開始時間などの情報がｓｔｂｌ内の各Ｂｏｘに格納される。

ｓｔｔｓには、サンプルの復号時間が格納される。即ち、ｓｔｔｓには、連続する２つのサンプル間における復号時間の差分値が格納されている。したがって、この差分値を加算することにより、各サンプルの復号時間を取得することができる。さらに、復号時間と表示時間が異なる際には、復号時間と表示時間との差分を格納するｃｔｔｓと呼ばれるＢｏｘが使用される。例えば、双方向予測を用いて符号化されたフレームでは復号時間と表示時間が異なるため、表示時間を求めるためにｃｔｔｓが使用される。

また、トラックの途中から再生が開始（ランダムアクセス）されるときには、復号化の開始可能なサンプルを示す情報が必要になる。このためのＢｏｘとしてｓｔｓｓがあり、ｓｔｓｓにはランダムアクセス可能なサンプル（以降、シンクサンプルと呼ぶ。）の一覧が格納される。なお、ｓｔｓｓが存在しない場合は、トラック内の全サンプルがランダムアクセス可能であることを示す。ここでは説明を省略するが、ｓｔｂｌには、上記Ｂｏｘの他にもサンプルのサイズを示すｓｔｓｚなど複数のＢｏｘが格納される。

次に、ヒントデータの使用方法について図１２を参照して説明する。
図１２は、ヒントデータの使用方法を説明するための図である。
ここでは、サーバがビデオトラックの途中のサンプル（表示時間Ｔ）からＲＴＰパケットを作成するときの手順について説明する。
（１） サーバはビデオのヒントトラック用のｔｒａｋを参照し、表示時間がＴと一致、あるいはＴ近傍であるビデオトラックのサンプルに対するＲＴＰパケット化情報が格納されたシンクサンプルを取得する。シンクサンプルの特定は、ｓｔｔｓおよびｓｔｓｓを参照し、表示時間を取得することにより行う。取得したシンクサンプルには、１つ以上のＲＴＰパケットを作成するために必要な情報が格納される。

なお、シンクサンプルの表示時間は、先頭ＲＴＰパケットにより伝送が開始されるビデオトラックのサンプルの表示時間を示す。シンクサンプルは、それぞれのパケットがビデオトラックのどの部分のデータを伝送するかを、ビデオトラックのサンプル番号及びサンプル内のバイト位置により示す。例えば、ｉ番目のＲＴＰパケットは、Ｋ番目サンプルのＬバイト目から、Ｍ番目サンプルのＮバイト目までを伝送する。
（２） サーバは、ビデオトラック用のｔｒａｋを参照して、Ｋ番目からＭ番目までのサンプルの格納位置を取得する。
（３） サーバは、（２）で取得した格納位置を元に、Ｋ番目サンプルのＬバイト目から、Ｍ番目サンプルのＮバイト目までのデータを取得する。サーバは、その取得したデータに、ＲＴＰパケット化に必要な他の情報を設定してＲＴＰパケットを作成する。

図１３は、サーバから端末にメディアデータ（コンテンツデータ）がＲＴＰパケットとして配信される手順を説明するための図である。
ここでは、ＭＰ４ファイルは蓄積装置に格納され、サーバと端末との間の再生制御にはＲＴＳＰ（Real Time Transmission Protocol）が使用される。なお、蓄積装置はサーバの内部にあってもよいし、外部にあってもよい。
（１）まず、端末は、サーバに対して、ＲＴＳＰを使用してコンテンツデータ（ｎｅｗｓ．ｍｐ４）の送信を要求する。
（２）サーバは、ｎｅｗｓ．ｍｐ４が利用できるかどうか確認し、利用できる際にはｎｅｗｓ．ｍｐ４にアクセスする。
（３）サーバは、ｎｅｗｓ．ｍｐ４のヒントトラックを解析し、端末へ送信するコンテンツデータを取得して、そのコンテンツデータからＲＴＰパケットを作成する。
（４）サーバは、コンテンツデータを格納したＲＴＰパケットを端末に対して送信する。

次に、サーバと端末の間で行われる再生制御の詳細について説明する。
図１４は、サーバと端末と間の再生制御において交換されるＲＴＳＰメッセージの一例を示す図である。図中のｃ−＞ｓは端末からサーバへのメッセージを示し、ｓ−＞ｃはサーバから端末へのメッセージを示す。
（１）端末は、サーバに対してＤＥＳＣＲＩＢＥ命令を用いてｎｅｗｓ．ｍｐ４のコンテンツデータを要求する。
（２）サーバはｎｅｗｓ．ｍｐ４が利用可能であると応答し、ＳＤＰ（Session Description Protocol）によりｎｅｗｓ．ｍｐ４に関する情報（ｎｅｗｓ．ｍｐ４へのアクセス情報など）を送信する。ここで、ＳＤＰの内容の一部は、ＭＰ４ファイルのヒントトラック用ｔｒａｋ及びｍｏｏｖ直下のｕｄｔａと呼ばれるＢｏｘに格納されている。そこで、サーバは、上記一部の内容に残りの情報を付加することにより、ＳＤＰの内容を作成する。
（３）端末はサーバに対して伝送時のパラメータ設定を行う。
（４）サーバは端末に対して伝送時のパラメータを通知する。

このような（１）〜（４）に示すＲＴＳＰメッセージの送受信により、サーバと端末との間の伝送路の確立及び初期化が行われる。
（５）端末はサーバに向けてＰＬＡＹ命令を発行し、ｎｅｗｓ．ｍｐ４のコンテンツデータの送信開始を要求する。
（６）サーバはＰＬＡＹ命令の応答として、送信を開始する旨のメッセージを返し、その後ＲＴＰパケットの送信が開始される。なお、サーバは、ＰＬＡＹ命令の応答を、ＲＴＰパケットの送信開始後に発行しても良い。

ここで、オーディオやビデオのメディアデータ（コンテンツデータ）は、メディア毎に異なる識別子を持ったＲＴＰパケットにより伝送される。識別子には、ＲＴＰパケットのヘッダに含まれるＳＳＲＣ（Synchronization Source）が使用される。また、オーディオやビデオのメディアデータを伝送するＲＴＰパケットは、端末のそれぞれ異なるポートに送信されるため、ポート番号によりＲＴＰパケットが伝送するメディアデータを識別しても良い。なお、オーディオのデータが２種類あるなど、同一メディアの複数のデータを送信する際にも、同様の方法によりＲＴＰパケットが伝送するデータを識別することができる。

図１４の（７）〜（１０）は、ランダムアクセスが行われる際の手順を示す。この（７）〜（１０）に挙げるメッセージは、端末のユーザがコンテンツデータの１０秒目を視聴しているときに３０秒目までスキップする場合の内容を示す。
（７）端末はサーバに対してデータの送信停止を要求する。
（８）サーバはデータの送信を停止する。
（９）端末は、ＰＬＡＹ命令の発行により、ｎｅｗｓ．ｍｐ４の３０秒目からのデータを要求する。
（１０）サーバは、３０秒から最後（６０秒）までを送信する旨のメッセージをＰＬＡＹ命令の応答として送信する。この後、３０秒目からのコンテンツデータが端末に送信される。
（１１）端末は、サーバに通信の終了手続きを促す。
（１２）サーバは、通信の終了手続きを行う。

図１５は、従来のデータ送信装置（サーバ）の構成を示すブロック図である。
データ送信装置は、ファイル解析部８０１と、ＲＴＰ作成部８０２と、ＲＴＰ送出部８０３と、ＲＴＳＰ処理部８０４とを備える。

ＲＴＳＰ処理部８０４は、データ受信装置（端末）に送信メッセージｄ８０６を送信するとともに、データ受信装置から受信メッセージｄ８０７を受信することにより、データ受信装置との間でＲＴＳＰを用いた再生制御を行う。ＲＴＳＰ処理部８０４は、受信メッセージｄ８０７を解析し、ＭＰ４ファイルのファイル名、格納場所、及び送信要求されている表示時間位置を含むＲＴＳＰ要求データｄ８０８をファイル解析部８０１に出力する。

ファイル解析部８０１は、図示しない蓄積装置から、ＲＴＳＰ要求データｄ８０８に示されるＭＰ４ファイルｄ８０１を取得する。次に、ファイル解析部８０１は、送信要求された表示時間位置に対応するサンプルを、ヒントトラックを解析することにより取得する。ファイル解析部８０１は、その取得したサンプルを、ＲＴＰパケットのヘッダの作成に必要な情報とともにパケット作成データｄ８０２としてＲＴＰ作成部８０２へ出力する。さらに、ファイル解析部８０１は、ＳＤＰ、又は送信開始時の先頭ＲＴＰパケットに含まれるメディアデータの表示時間情報、を含むＲＴＳＰ送出情報ｄ８０５をＲＴＳＰ処理部８０４に出力する。

ＲＴＰ作成部８０２は、ファイル解析部８０１からパケット作成データｄ８０２を取得するとともに、図示しない装置から、ＲＴＰパケットのヘッダ情報であるパケットヘッダ情報ｄ８０９を取得する。そして、ＲＴＰ作成部８０２は、そのパケット作成データｄ８０２とパケットヘッダ情報ｄ８０９とに基づいて、ＲＴＰパケットｄ８０３を作成してＲＴＰ送出部８０３に出力する。

ＲＴＰ送出部８０３は、ＲＴＰ作成部８０２から出力されたＲＴＰパケットデータｄ８０３を取得し、これをＲＴＰパケットｄ８０４としてデータ受信装置（端末）に送信する。

図１６は、データ送信装置のファイル解析部８０１の動作を示すフロー図である。
ここでは、データ送信装置は、ビデオトラックのデータを、表示時間がＴである部分のデータからＲＴＰパケット化して送信する。また、ビデオトラックのトラックＩＤは１であり、ビデオトラック用のヒントトラックのトラックＩＤは３である。即ち、ファイル解析部８０１は、トラックＩＤ＝３であるヒントトラックを参照することにより、トラックＩＤ＝１であるビデオトラックのデータをＲＴＰパケット化して送信する。

まず、ファイル解析部８０１は、トラックＩＤ＝３であるトラックのｓｔｓｓおよびｓｔｔｓを解析する（ステップＳ８０１）。この解析によりファイル解析部８０１は、表示時間がＴと一致する、あるいはＴ以前で最もＴに近いシンクサンプルを特定する（ステップＳ８０２）。なお、ファイル解析部８０１は、表示時間がＴ以降で最もＴに近いシンクサンプルを特定しても良い。また、オーディオなどでは通常全てのサンプルがシンクサンプルであるためｓｔｓｓが存在しない。このようにｓｔｓｓが存在しない場合は、ファイル解析部８０１は、全てのサンプルをシンクサンプルとして扱う。

次に、ファイル解析部８０１は、ｓｔｂｌ内の他のＢｏｘを参照して、特定されたシンクサンプルのデータを取得する（ステップＳ８０３）。
さらに、ファイル解析部８０１は、取得したシンクサンプルを解析することにより、そのシンクサンプルにより作成されるＲＴＰパケットで伝送されるトラックＩＤ＝１のビデオトラックのサンプルを特定する（ステップＳ８０４）。

次に、ファイル解析部８０１は、トラックＩＤ＝１であるトラックのｔｒａｋを解析し、ステップＳ８０４においてＲＴＰパケット化の対象として特定されたサンプルのデータを取得する（ステップＳ８０５）。

また、ファイル解析部８０１は、ステップＳ８０２で特定したシンクサンプル以降にヒントトラックのサンプルがある場合には、そのサンプルを取得して、そのサンプルに基づいてステップＳ８０４，Ｓ８０５と同様の動作を行う。

以上では、単一のメディアデータを取得する手続きについて述べたが、オーディオとビデオなど複数のメディアを扱う際には、各メディアについて同様の処理が行われる。なお、各メディアトラックと、対応するヒントトラックとは、トラックＩＤにより関連付けられている。

データ受信装置は、上述のデータ送信装置から出力されたＲＴＰパケットｄ８０４（符号化データ）を取得し、その符号化データをバッファと呼ばれるメモリに保持しながら、メモリ内の符号化データの復号化を行う。

ここで、バッファモデルと呼ばれるモデルが規定されている。このバッファモデルは、所定のレートで符号化データが流入する際に、所定のサイズのバッファを用意すれば、バッファが空になる（アンダーフロー）、あるいは溢れる（オーバーフロー）ことなしに復号化が行えることを保証する。

バッファモデルは、ＭＰＥＧ−４ ＡＶＣ（Advanced Video Coding）やＭＰＥＧ−４（Moving Picture Expert Group Visual）などの符号化方式ごとに定められており、符号化データはこのバッファモデルに従って符号化される。

図１７は、符号化データの流入開始からの経過時間（横軸）と、データ受信装置のバッファの占有量（縦軸）との関係を示す図である。
バッファ占有量とは、ある時間にバッファに存在する符号化データのデータ量である。例えばこの図１７に示すように、傾きＲを持つビットレートによりバッファに符号化データが流入する。データ受信装置は、時刻ｔ１にピクチャＰ１に対して復号化処理を開始し、続くピクチャをそれぞれｔ２，ｔ３，…の時刻で復号化する。即ち、それぞれのピクチャの復号化時刻（ｔ１，ｔ２，…）において、復号化対象のピクチャに相当するデータがバッファから引き抜かれる。例えば、時刻ｔ２において復号化対象のピクチャのデータがバッファから引き抜かれることにより、その復号化対象ピクチャのデータ量Ｐｓ２だけバッファ占有量が少なくなる。

ここで、バッファへの符号化データの流入が開始されてから復号化が開始されるまでの時間をプリバッファリング時間と呼ぶ。図１７に示す動作をデータ受信装置が行う場合、プリバッファリング時間はｔ１である。データ受信装置は、バッファモデルに基づき、符号化時に定められたプリバッファリング時間を守って復号化を開始すれば、バッファ占有量がビデオ符号化規格（ＭＰＥＧ−４など）により規定されたバッファサイズを超えることなく、且つ、ピクチャの復号化時刻において復号化対象ピクチャのデータが完全に揃っている状態で、符号化データの復号化を継続することができる。つまり、図１７に示すように、バッファ占有量は常にゼロ以上バッファサイズ以下の状態に保たれる。
特開２００１−１９７１２０号公報

しかしながら、上記従来のデータ送信装置では、データ受信装置に伝えるべき、ＲＴＰパケットｄ８０４の再生に必要な情報が不足しているため、ＲＴＰパケットｄ８０４により伝送される符号化データを、データ受信装置に対して適切に再生させることができないという問題がある。

データ受信装置は、符号化データの途中のピクチャ（５枚目のピクチャＰ５）から復号化を開始する場合、バッファのアンダーフロー及びオーバーフローを防ぐため、ピクチャＰ５のデータをバッファから引き抜いた後に、バッファ占有量をオフセットｏｓ５にしておく必要がある。ところが、データ受信装置は、プリバッファリング時間として常に一定時間の経過後に復号を開始するため、ピクチャＰ５のデータの引き抜き後、バッファ占有量をオフセットｏｓ５よりも少なくしてしまう場合がある。

図１８は、プリバッファリング時間に応じて異なるバッファ占有量の時間的な変化を示す図である。
データ受信装置は、図１８の（ａ）に示すように、プリバッファリング時間ｄｂの経過後にピクチャＰ５の復号化を開始すると、バッファ占有量がオフセットｏｓ５となるため、ピクチャＰ６以降のピクチャも復号化時刻において正常に復号化することができる。

ところが、データ受信装置は、図１８の（ｂ）に示すように、プリバッファリング時間ｄａの経過後にピクチャＰ５の復号化を開始すると、バッファ占有量がゼロとなるため、ピクチャＰ６の復号化時刻においてピクチャＰ６のデータが揃っておらず、ピクチャＰ６を復号化することができない。このため、データ受信装置は、ピクチャＰ６のデータが揃うまで復号化動作を停止したり表示を停止したりする。

このように、バッファのオーバーフロー及びアンダーフローを防ぐ適切なプリバッファリング時間は、復号化の開始対象となるピクチャによって異なる。データ受信装置は、このようなピクチャごとに適切なプリバッファリング時間など、適切な再生に必要な情報を得ることができないため、再生中にピクチャの表示を停止したり、復号化開始までの待ち時間を必要以上に長くしてしまう。

本発明は、かかる問題に鑑みてなされたものであり、データ受信装置に対してコンテンツデータの適切な再生処理を実行させるデータ送信装置を提供することを目的とする。

上記目的を達成するために、本発明のデータ送信装置は、デジタル著作物たるコンテンツデータをファイルから取り出して受信装置に対して送信するデータ送信装置であって、前記ファイルは、前記コンテンツデータと、前記コンテンツデータの再生処理に用いられる再生制御情報とを多重化して構成され、前記データ送信装置は、前記受信装置との間でコンテンツデータの伝送路の確立及び初期化を行う前置処理手段と、前記前置処理手段による伝送路の確立及び初期化の後、前記再生制御情報の少なくとも一部を前記ファイルから取り出して、前記受信装置に送信する制御送信手段と、前記ファイルからコンテンツデータの少なくとも一部を取得してパケット化するパケット生成手段と、前記パケット生成手段によりパケット化されたコンテンツデータの少なくとも一部を送信するコンテンツ送信手段とを備えることを特徴とする。

これによって、前置処理手段による伝送路の確立及び初期化の後、再生制御情報の少なくとも一部がファイルから取り出されて受信装置に送信されるため、受信装置は、コンテンツ送信手段から送信されたコンテンツデータ、及び制御送信手段から送信された再生制御情報を受信すると、その再生制御情報を用いてコンテンツデータを適切に再生処理することができる。

また、前記ファイルに多重化された再生制御情報は、前記コンテンツデータに含まれる複数のデータ単位ごとに、当該データ単位からの再生に用いられる再生制御単位情報を含んでテーブル状に構成され、前記制御送信手段は、前記受信装置からの要求に応じたデータ単位に関連する前記再生制御単位情報を、前記ファイルの再生制御情報から取り出して送信し、前記パケット生成手段は、前記受信装置からの要求に応じたデータ単位からの前記コンテンツデータを取得してパケット化することを特徴としても良い。

これにより、受信装置からの要求に応じたデータ単位からのコンテンツデータがパケット化されて送信されるとともに、そのデータ単位に関連する再生制御単位情報も制御送信手段から送信されるため、受信装置は、自らが要求したコンテンツデータの一部分を、再生制御単位情報を用いて、その一部分に含まれる先頭のデータ単位から適切に再生処理することができる。

また、前記再生制御単位情報は、前記コンテンツ送信手段から送信されて前記受信装置に受信されるコンテンツデータに対して、復号処理を開始すべきタイミングを知らせる内容を示すことを特徴としても良い。例えば、前記再生制御単位情報は、前記タイミングを知らせる内容として、前記受信装置によるコンテンツデータの受信開始から前記復号処理の開始までの時間を示す。又は、前記再生制御単位情報は、前記タイミングを知らせる内容として、前記受信装置によって蓄積されるコンテンツデータのデータ量を示す。

これにより、コンテンツデータを受信してバッファへの蓄積を開始した受信装置は、再生制御単位情報を用いることで、そのバッファに蓄積されるコンテンツデータに対して復号処理を開始すべきタイミングを知ることができ、バッファのオーバーブローやアンダーフローの発生を防いで、その蓄積されるコンテンツデータの再生処理を適切に行うことができる。また、再生制御単位情報が時間を示すときには、受信装置は受信開始からの時間を計時することにより上記タイミングを知ることができ、再生制御単位情報がデータ量を示すときには、受信装置はバッファに蓄積されるデータ量に基づいて上記タイミングを知ることができる。

また、前記制御送信手段は、前記再生制御単位情報の示すデータ量を、前記受信装置によるコンテンツデータの受信開始から前記復号処理の開始までの時間に変換し、前記変換された再生制御単位情報を送信することを特徴としても良い。ここで、前記制御送信手段は、前記再生制御単位情報を、前記コンテンツ送信手段においけるコンテンツデータの伝送状況に応じて変換する。

これにより、再生制御単位情報の示すデータ量が時間に変換されて受信装置に通知されるため、バッファに蓄積されるデータ量を把握不可能な受信装置であっても適切に上記タイミングを知ることができる。また、コンテンツデータの伝送状況に応じて上記変換が行われる場合には、その伝送状況に影響されることなく適切な時間を受信装置に通知することができる。例えばコンテンツデータの送信速度が低下したときには、その時間が長くなるように変換し、適切な時間を受信装置に通知することができる。

また、前記コンテンツ送信手段は、伝送路の状況に基づいて、コンテンツデータの送信速度を変化させることを特徴としても良い。
これにより、受信装置は安定した品質でコンテンツデータを再生することができる。

また、前記コンテンツデータは、複数の画像を含んで構成される動画像データであって、前記再生制御単位情報は、当該データ単位の先頭の画像から正しい復号処理結果が得られるか否かを示すことを特徴としても良い。又は、前記コンテンツデータは、複数の画像を含んで構成される動画像データであって、前記再生制御単位情報は、当該データ単位の先頭の画像から復号処理が開始された場合に、最初に正しい復号処理結果が得られる部位を示すことを特徴としても良い。

これにより、データ送信装置からコンテンツデータを受信した受信装置は、不完全に復号処理される画像からコンテンツの内容を出力するか、正しく復号処理される画像からコンテンツの内容を出力するかを選択することができる。

また、前記コンテンツデータは、連続する複数の画像から構成されるシーンを前記データ単位として含む動画像データであって、前記再生制御情報は、前記各シーンを構成する画像を復号化する際の初期化に要する情報を示すことを特徴としても良い。

これにより、例えばクリップ再生のように異なるシーンの画像を順に受信装置が要求したときには、データ送信装置は各シーンとともに、それらに関連する再生制御単位情報を送信するため、受信装置は再生制御単位情報を用いて各シーンごとに適切に初期化を行い、各画像を表示することができる。

また、前記コンテンツデータは、複数の画像を含んで構成される動画像データであって、前記再生制御情報は、前記複数の画像のうちのランダムアクセス可能な画像の周期を示すことを特徴としても良い。

これにより、再生制御情報を受信した受信装置は、その再生制御情報に基づいてコンテンツデータのランダムアクセス可能な部位を特定することができ、受信装置はそれらの部位から適切に再生処理を行うことができる。

なお、本発明は、上記データ送信装置によってコンテンツデータを送信するデータ送信方法やプログラム、そのプログラムを格納する記憶媒体として実現することもできる。

本発明のデータ送信装置は、データ受信装置に対してコンテンツデータの適切な再生処理を実行させることができるという作用効果を奏する。

（実施の形態１）
以下、本発明の第１の実施の形態におけるデータ送信装置について、図面を参照しながら説明する。

図１は、本発明の実施の形態１に係るデータ送信装置の構成を示すブロック図である。
本実施の形態に係るデータ送信装置１００は、例えばプリバッファリング時間などの適切な再生に必要な情報（再生制御情報）をＭＰ４ファイルから取り出してデータ受信装置に送信することにより、そのデータ受信装置に対して適切な再生処理を実行させるものである。本実施の形態に使用されるＭＰ４ファイルは、オーディオ、ビデオ、又はテキストのメディアデータと、ヒントデータとが多重化されたものであって、上記再生制御情報はそのヒントデータのヘッダに多重化されている。なお、本実施の形態において使用されるＭＰ４ファイルは、ＭＰＥＧ−４ ＡＶＣや、ＭＰＥＧ−４ Ｖｉｓｕａｌ、Ｈ．２６３などの符号化方式で符号化されるビデオデータを示す。

このようなデータ送信装置１００は、ファイル解析部１１０と、ＲＴＳＰ処理部１０１と、ＲＴＰ作成部１０２と、ＲＴＰ送出部１０３と、ファイル作成部１０４とを備える。
ファイル作成部１０４は、コンテンツデータのストリームを取得して、ＭＰ４ファイルを作成し、そのＭＰ４ファイルを蓄積装置に格納する。

ＲＴＳＰ処理部１０１は、データ受信装置に送信メッセージｄ１０７を送信するとともに、データ受信装置から受信メッセージｄ１０８を受信することにより、データ受信装置との間でＲＴＳＰを用いた再生制御を行う。ここで送信メッセージｄ１０７には、ファイル解析部１１０から取得したＲＴＳＰ送出情報ｄ１０５及び再生パラメータ情報ｄ１１０の少なくとも一方が含まれる。ＲＴＳＰ処理部１０１は、受信メッセージｄ１０８を解析し、ＭＰ４ファイルのファイル名、格納場所、及び送信要求されている表示時間位置を含むＲＴＳＰ要求データｄ１０１をファイル解析部１１０に出力する。

ファイル解析部１１０は、ＭＰ４ファイルを解析してＲＴＰパケットの作成に必要なデータや、ＲＴＳＰの通信に必要なデータを作成するものであって、ＲＴＰ解析部１１２と、情報取得部１１１と、再生解析部１１３と、変換部１１４とを備える。

ＲＴＰ解析部１１２は、情報取得部１１１を介してＲＴＳＰ要求データｄ１０１を取得し、ＭＰ４ファイルのヒントトラックを解析することにより、そのＲＴＳＰ要求データｄ１０１に対応するサンプルを含むサンプルデータｄ１０２を取得する。さらに、ＲＴＰ解析部１１２は、その取得したサンプルデータｄ１０２を情報取得部１１１に出力し、サンプルデータｄ１０２の先頭にあるサンプルのサンプル番号を含むサンプル番号情報ｄ１０３を再生解析部１１３に出力する。サンプル番号とは、サンプルを識別するための番号である。例えば、トラックの各サンプルに対して、先頭のサンプルから順にサンプル番号１，２，３…が割り当てられる。なお、サンプル番号情報ｄ１０３は、ヒントトラックやメディアトラックのトラックＩＤを含んでいても良い。

情報取得部１１１は、ＲＴＰ解析部１１２からサンプルデータｄ１０２を取得する。情報取得部１１１は、その取得したサンプルデータｄ１０２と、ＲＴＰパケットのヘッダの作成に必要な情報とを、パケット作成データｄ１０４としてＲＴＰ作成部１０２に出力する。さらに、情報取得部１１１は、サンプルデータｄ１０２に基づいて、シーケンス番号、タイムスタンプ、ＳＤＰ、又はＲＴＰパケットの送信開始時に先頭に含まれるメディアデータの表示時間情報、などを含むＲＴＳＰ送出情報ｄ１０５を作成してＲＴＳＰ処理部１０１に出力する。

再生解析部１１３は、ＲＴＰ解析部１１２からサンプル番号情報ｄ１０３を取得する。再生解析部１１３は、その取得したサンプル番号情報ｄ１０３の示すサンプル番号のサンプル以降の各サンプルに関する再生制御情報ｄ１０９を、ＭＰ４ファイルのヒントトラックから取得する。そして、再生解析部１１３は、取得した再生制御情報ｄ１０９を変換部１１４に出力する。再生制御情報ｄ１０９は、サンプル番号情報ｄ１０３の示すサンプル番号のサンプルからの再生処理がデータ受信装置側での適切に行われるための情報である。例えば、この再生制御情報ｄ１０９は、データ受信装置のバッファでオーバーフローやアンダーフローが生じないような適切なプリバッファリングが行われるためのプリバッファリング情報である。

変換部１１４は、再生解析部１１３から取得した再生制御情報ｄ１０９をＲＴＳＰのパラメータに変換して再生パラメータ情報ｄ１１０を生成し、これをＲＴＳＰ処理部１０１に出力する。

ＲＴＰ作成部１０２は、ファイル解析部１１０からパケット作成データｄ１０４を取得するとともに、ＲＴＰパケットのヘッダ情報であるパケットヘッダ情報ｄ１１１を図示しない装置から取得する。なお、このパケットヘッダ情報ｄ１１１は、シーケンス番号の初期値などを含む。そして、ＲＴＰ作成部１０２は、パケット作成データｄ１０４及びパケットヘッダ情報ｄ１１１に基づいて、ＲＴＰパケットｄ１１２を作成する。

ＲＴＰ送出部１０３は、ＲＴＰ作成部１０２で作成されたＲＴＰパケットｄ１１２をデータ受信装置に送信する。
このような本実施の形態のデータ送信装置１００は、例えばビデオの途中からのデータを送信するようにデータ受信装置から要求されたときには、ヒントトラック用のｓｔｓｓを参照する。そしてデータ送信装置１００は、ヒントトラックのシンクサンプルの中から、データ受信装置の要求に対して最も適当なサンプルを特定し、その特定したサンプル以降のサンプルに基づいて、ビデオデータのＲＴＰパケットを生成して送信する。表示時間Ｔの部分からのデータ（ＲＴＰパケット）がデータ受信装置から要求された場合には、データ送信装置１００は、表示時間がＴと等しい、又はＴ以前で最もＴに近いヒントトラックのシンクサンプルを特定する。なお、データ送信装置１００は、表示時間がＴ以降で最もＴに近いシンクサンプルを特定しても良い。

さらに本実施の形態に係るデータ送信装置１００は、ヒントトラックのシンクサンプルに基づいて１つ以上のＲＴＰパケットを作成するときには、先頭のＲＴＰパケットにより最初に伝送されるビデオトラックのサンプルに対する再生パラメータ情報ｄ１１０を、送信メッセージｄ１０７としてデータ受信装置に送信する。このようなデータ送信装置１００からＲＴＰパケットを受信したデータ受信装置は、その再生パラメータ情報ｄ１１０（再生制御情報ｄ１０９）に基づいて、その受信したＲＴＰパケットに対して適切な再生を行うことができるのである。

ここで、本実施の形態のデータ送信装置１００が取り扱うＭＰ４ファイルの構造について説明する。
ＭＰ４ファイルは、再生制御情報としてプリバッファリング情報を含む。再生制御情報は、各サンプルからの再生処理がデータ受信装置によって適切に行われるための情報である。プリバッファリング情報は、各サンプルからのプリバッファリングが適切に行われるための情報であって、ヒントトラック用のｔｒａｋのｓｔｂｌの直下に配置されるｓｔｓｐ（SyncSample To Prebuf Box）に、テーブル構造となって格納される。具体的にプリバッファリング情報は、各サンプル（ピクチャ）に応じて、受信開始から復号開始までのプリバッファリングに必要な時間（プリバッファリング必要時間）や、受信開始から復号開始までのプリバッファリングに必要なデータ量（プリバッファリング必要データ量）を示す。

図２は、ｓｔｓｐに格納されたプリバッファリング情報の内容の一例を示すデータ内容表示図である。
プリバッファリング情報Ｄ１０９は、図２の（ａ）に示すように、ヒントトラックのシンクサンプルのサンプル番号（シンクサンプル番号）と、そのサンプル番号のシンクサンプルに対応するプリバッファリング必要データ量とを含む。プリバッファリング必要データ量は、これに対応するシンクサンプルに基づいて作成されたＲＴＰパケットからデータ受信装置による受信が開始された場合に、その受信開始から復号開始までにデータ受信装置のバッファに蓄積が必要なデータ量を示す。

例えば、データ受信装置は、サンプル番号１のシンクサンプルに基づいて作成されたＲＴＰパケットｄ１１２から受信を開始するときには、ＲＴＰパケットｄ１１２を１５０００バイトまで受信してから復号化を開始する。なお、プリバッファリング必要データ量が、ＲＴＰなどの伝送プロトコルに依存することがないように、そのプリバッファリング必要データ量を、パケットに含まれるビデオやオーディオの符号化データの量としても良い。

図２の（ｂ）は、上述のようなプリバッファリング情報Ｄ１０９を格納するｓｔｓｐのシンタックスの一例を示す図である。図２中のsync _sample _numberはシンクサンプルのサンプル番号を示し、prebuf_data _byteは、プリバッファリング必要データ量を示す。

図３は、ｓｔｓｐに格納されたプリバッファリング情報の内容の他の例を示すデータ内容表示図である。
プリバッファリング情報Ｄ１０９は、図３の（ａ）に示すように、ヒントトラックのシンクサンプルのサンプル番号（シンクサンプル番号）と、そのサンプル番号のシンクサンプルに対応するプリバッファリング必要時間とを含む。

例えば、データ受信装置は、サンプル番号１のシンクサンプルに基づいて作成されたＲＴＰパケットｄ１１２から受信を開始したときには、その受信開始から１．８７５（ｓ）経過後にＲＴＰパケットｄ１１２の復号化を開始する。言い換えれば、送信レートが６４０００（ｂｐｓ）である場合、データ受信装置は、６４０００×１．８７５/８＝１５０００バイトのデータがバッファに蓄積されたときに、ＲＴＰパケットｄ１１２の復号化を開始する。

図３の（ｂ）は、上述のようなプリバッファリング情報Ｄ１０９を格納するｓｔｓｐのシンタックスの一例を示す図である。図３中のsync _sample _numberはシンクサンプルのサンプル番号を示し、prebuf_periodはプリバッファリング必要時間を示す。

なお、シンクサンプルのプリバッファリング情報を示すことができるのであれば、そのプリバッファリング情報を他の方法によりＭＰ４ファイルに格納してもよい。例えば、サンプルが参照するサンプルエントリのインデックス番号をSample to Chunk Box（’ｓｔｓｃ’）を用いて示すのと同様に、プリバッファリング情報をｓｔｂｌ内のＢｏｘにおけるテーブルデータのエントリとして格納し、シンクサンプルと前記エントリのインデックス番号とを関連付ける。

図４は、データ送信装置１００のファイル解析部１１０の動作を示すフロー図である。なお、再生制御情報ｄ１０９をプリバッファリング情報として以下説明する。
ここでは、データ送信装置１００は、ビデオトラックのデータを、表示時間がＴである部分のデータからＲＴＰパケット化して送信する。また、ビデオトラックのトラックＩＤは１であり、ビデオトラック用のヒントトラックのトラックＩＤが３である。即ち、ファイル解析部１１０は、トラックＩＤ＝３であるヒントトラックを参照することにより、トラックＩＤ＝１であるビデオトラックのデータをＲＴＰパケット化して送信する。なお、ここではビデオデータについて説明するが、オーディオ、あるいはテキストデータについてもプリバッファリング情報を使用しても良い。

まず、ファイル解析部１１０は、トラックＩＤ＝３であるトラック（ヒントトラック）のｓｔｂｌ（ｓｔｓｓおよびｓｔｔｓ）を解析する（ステップＳ１０１）。この解析によりファイル解析部１１０は、表示時間がＴと一致する、又はＴ以前で最もＴに近いシンクサンプルを特定する（ステップＳ１０２）。次に、ファイル解析部１１０は、ｓｔｂｌ内の他のＢｏｘを参照して、特定されたシンクサンプルのデータを取得する（ステップＳ１０３）。さらに、ファイル解析部１１０は、取得したシンクサンプルを解析することにより、そのシンクサンプルにより作成されるＲＴＰパケットによって伝送されるトラックＩＤ＝１のビデオトラックのサンプルを特定する（ステップＳ１０４）。

次に、ファイル解析部１１０は、トラックＩＤ＝３であるヒントトラックのｓｔｓｐを参照することにより、ステップＳ１０３で特定したシンクサンプル（トラックＩＤ＝３）に基づいてＲＴＰパケット化される先頭のＲＴＰパケット（ピクチャ）に対するプリバッファリング情報ｄ１０９を取得する（ステップＳ１０５）。

プリバッファリング情報ｄ１０９を取得したファイル解析部１１０は、そのプリバッファリング情報ｄ１０９をＲＴＳＰのパラメータに変換して、再生パラメータ情報ｄ１１０を生成する（ステップＳ１０６）。

その後、ファイル解析部１１０は、トラックＩＤ＝１であるビデオトラックのｔｒａｋを解析し、ステップＳ１０４においてＲＴＰパケット化の対象として特定されたサンプルを取得する（ステップＳ１０７）。

また、ファイル解析部１１０は、ステップＳ１０２で特定したシンクサンプル以降のヒントトラックのサンプルについては、そのサンプルのデータを取得し、続いてステップＳ１０４，Ｓ１０７と同様の動作を行う。

なお、データ送信装置１００は、プリバッファリング情報の取得処理（ステップＳ１０５）を、シンクサンプルの取得（ステップＳ１０３）前に行っても良く、ビデオトラックのサンプルの取得（ステップＳ１０７）後に行っても良い。

図５は、プリバッファリング情報の取得処理（図４のステップＳ１０５）の詳細な動作を示すフロー図である。
なお、ｓｔｓｐは、図２の（ｂ）に示すシンタックスで表され、図４のステップＳ１０３で特定されたヒントトラックのシンクサンプルのサンプル番号がＮであると想定する。

まず、ファイル解析部１１０は、データを読み出すためのポインタを、ｓｔｓｐのentry_countフィールドの先頭にセットし、カウント値を０にセットする（ステップＳ２０１）。

次に、ファイル解析部１１０は、ｓｔｓｐに含まれるエントリ数Ｍを取得し（ステップＳ２０２）、ポインタを４バイト分進める（ステップＳ２０３）。
その後、ファイル解析部１１０は、カウント値に１を加算し（ステップＳ２０４）、シンクサンプルのサンプル番号（sync_number）を取得する（ステップＳ２０５）。ファイル解析部１１０は、さらにポインタを４バイト分進める（ステップＳ２０６）。

ファイル解析部１１０は、ステップＳ１０５で取得したシンクサンプルのサンプル番号（sync_number）がＮと等しいか否かを判定する（ステップＳ２０７）。Ｎと等しければ（ステップＳ２０７のＹｅｓ）、ファイル解析部１１０は、サンプル番号がＮであるシンクサンプルに対応するプリバッファリング情報ｄ１０９を取得する（ステップＳ２０８）。等しくない場合は（ステップＳ２０７のＮｏ）、ファイル解析部１１０は、カウント値がエントリ数Ｍよりも小さいか否かを判定する（ステップＳ２０９）。ここで、ファイル解析部１１０は、カウント値がエントリ数Ｍよりも小さければ（ステップＳ２０９のＹｅｓ）、ステップＳ２０４〜Ｓ２０７の処理を繰り返し実行する。一方、カウント値がエントリ数Ｍ以上であるときには（ステップＳ２０９のＮｏ）、ファイル解析部１１０は、サンプル番号Ｎのシンクサンプルに対応するプリバッファリング情報ｄ１０９を取得することができず、予め設定されたデフォルト値を取得し、そのデフォルト値をプリバッファリング情報ｄ１０９として使用する（ステップＳ２１０）。

図６は、本実施の形態におけるデータ送信装置１００とデータ受信装置との間で交換されるＲＴＳＰメッセージの一例を示す図である。
データ送信装置１００は、（１）〜（５）に示すように、データ受信装置との間の伝送路の確立及び初期化を行った後、プリバッファリング情報ｄ１０９を再生パラメータ情報ｄ１１０に変換し、これをＲＴＳＰのＰＬＡＹ命令の応答としてデータ受信装置に送信する。例えば図６に示すように、データ送信装置１００は、プリバッファリング必要時間を示すプリバッファリング情報ｄ１０９を、3GPP TS 26.234規格により規定されたx-initprebufperiodといった再生パラメータ情報ｄ１１０に変換し、その再生パラメータ情報ｄ１１０を送信メッセージｄ１０７に含めて送信する。

図６の（６）で送信される再生パラメータ情報ｄ１１０について、具体的に説明する。
例えば、図２の（ａ）に示すプリバッファリング情報Ｄ１０９がｓｔｓｐに格納されている場合、データ送信装置１００は、サンプル番号１のシンクサンプルに対応するプリバッファリング情報ｄ１０９として「プリバッファリング必要データ量１５０００バイト」を取得する。データ送信装置１００は、ＲＴＰパケットの伝送レートが６４０００ｂｐｓであって、タイムスケールが９００００であると、その取得したプリバッファリング情報ｄ１０９を９００００×１５０００×８/６４０００＝１６８７５０の再生パラメータ情報ｄ１１０（x-initprebufperiod）に変換する。

図６の（１０）で送信される再生パラメータ情報ｄ１１０について、具体的に説明する。
例えば、データ送信装置１００は、ビデオトラックの表示時間が３０秒の位置にあるサンプルから送信を開始する場合、サンプル番号３００のシンクサンプルに対応するプリバッファリング情報ｄ１０９として「プリバッファリング必要データ量９０００」を取得する。データ送信装置１００は、ＲＴＰパケットの伝送レートが６４０００ｂｐｓであって、タイムスケールが９００００であると、その取得したプリバッファリング情報ｄ１０９を９００００×９０００×８/６４０００＝１０１２５０の再生パラメータ情報ｄ１１０（x-initprebufperiod）に変換する。

なお、図６に示す例では、データ送信装置１００は、ＰＬＡＹ命令の応答として再生パラメータ情報ｄ１１０（プリバッファリング情報）を送信したが、コンテンツ（例えばビデオ）の先頭からＲＴＰパケットの送信を開始する場合、再生パラメータ情報ｄ１１０をＳＤＰに格納して送信しても良い。また、データ送信装置１００は、ＰＬＡＹ命令の応答としてではなく、ＲＴＳＰ規格における別の命令や、新規に作成された命令などに対する応答として再生パラメータ情報ｄ１１０を送信しても良い。

ここで、上述のようにデータ送信装置１００がｓｔｓｐからプリバッファリング情報を取得する代わりにデフォルト値を用いる場合、そのデフォルト値は、プリバッファリング必要データ量として、例えばバッファサイズの３分の２に相当するデータ量を示す。

例えば、ＭＰＥＧ−４ Ｖｉｓｕａｌの場合には、ＶＯＬ（Video Object Layer）内にプリバッファリング情報が示されない際には、規格により決められたバッファサイズの３分の２に相当するデータ量の符号化ビデオデータをプリバッファリングしてから復号化を開始することが規定されている。そこで、データ送信装置１００は、バッファサイズの３分の２に相当するデータ量をデフォルト値として使用する。

このように本実施の形態のデータ送信装置１００は、プリバッファリング情報ｄ１０９を再生パラメータ情報ｄ１１０に変換し、データ受信装置に対して送信するため、データ受信装置はその変換されたプリバッファリング情報ｄ１０９に基づいて、ＲＴＰパケットの適切な復号開始時間を特定することができる。その結果、データ受信装置は、例えば、データ送信装置１００からＲＴＰにより送信されたビデオデータを途切れなく再生することができる。

ここで、ＭＰＥＧ−４ ＡＶＣ及びＭＰＥＧ−４ Ｖｉｓｕａｌのそれぞれの場合におけるファイル作成部１０４の動作について詳細に説明する。
ＭＰＥＧ−４ ＡＶＣでは、ビデオデータのストリーム内に、ＳＥＩ（Supplemental Enhancement Information）と呼ばれる復号化のための補助情報を入れることができる。ＳＥＩは、復号化において直接必要はないが、復号化を行う際の手助けとなる情報であり、例えばプリバッファリング必要時間やランダムアクセスに関する情報を示すことができる。

特にプリバッファリング情報を示すＳＥＩは、Buffering period SEIと呼ばれ、Buffering period SEI直後のピクチャのデータがＭＰＥＧ−４ ＡＶＣの復号化バッファに流入開始してから、そのピクチャの復号化を開始するまでの時間長が格納される。

即ち、ファイル作成部１０４は、ストリームに含まれるBuffering period SEIを参照して、上述のようなｓｔｓｐを有するＭＰ４ファイルを作成する。
例えば、Buffering period SEIが、ピクチャＮの復号化開始までの時間長として１秒を示し、復号開始まで時間の算出基準となるレートが６４０００ｂｐｓである場合について、以下説明する。

この場合、６４０００×１/８＝８０００バイト分のＭＰＥＧ−４ ＡＶＣのビデオデータを受信してからピクチャＭの復号化が開始される。ここで、８０００バイト分のビデオデータを伝送するために必要なＲＴＰパケットの個数はＭＰ４ファイルのヒントトラックを作成する際に決定されるため、ファイル作成部１０４は、８０００バイトに、ＲＴＰパケットのヘッダのサイズの総和を加算する。そしてファイル作成部１０４は、その加算結果を、プリバッファリング必要データ量（プリバッファリング情報）としてｓｔｓｐに格納する。例えば、２０個のＲＴＰパケットで８０００バイトのビデオデータが伝送され、ＲＴＰパケットのヘッダサイズが１２バイトとすると、ＲＴＰパケットのヘッダのサイズの総和は１２×２０＝２４０バイトとなる。その結果、８０００＋２４０＝８２４０バイトがプリバッファリング必要データ量となる。

なお、ＭＰＥＧ−４ ＡＶＣのビデオデータのストリームにBuffering period SEIが使用されない場合には、ファイル作成部１０４は、ピクチャのプリバッファリング情報をストリームとは別に取得する。又は、ファイル作成部１０４は、そのストリームに含まれる各ピクチャのサイズ及び復号化時間などからプリバッファリング情報を算出する。

一方、ＭＰＥＧ−４ Ｖｉｓｕａｌでは、ビデオデータのストリームのＶＯＬ（Video Object Layer）内のパラメータが、ＶＯＬ直後のＶＯＰ（Video Object Plane）データをバッファから引き抜く直前のバッファ占有量を示す。即ち、このバッファ占有量は、プリバッファリング必要データ量を示す。そこで、ランダムアクセス可能なピクチャの前にＶＯＬが配置されていれば、ファイル作成部１０４は、そのＶＯＬ内のパラメータから、ＶＯＬ直後のピクチャに対するプリバッファリング必要データ量（プリバッファリング情報）を算出する。

以上、本発明に係るデータ送信装置１００ついて上記実施の形態を用いて説明したが、本発明に係るデータ送信装置１００はこれらに限定されるものではない。
例えば、本実施の形態では、図３に示すように、プリバッファリング必要時間を示すプリバッファリング情報のみをｓｔｓｐに含めたが、送信レートが変化する場合があるため、そのプリバッファリング必要時間を導出するための基準とした送信レートをｓｔｓｐ内に格納しても良い。またＭＰ４ファイルの別の場所に格納しても良い。

ＲＴＰパケットなどのパケットデータがネットワークを介して送信される場合、ネットワークにおける送信レートは必ずしも一定とならず、揺らぎが生ずる。例えば、データ送信装置１００が６４０００ｂｐｓの送信レートでＲＴＰパケットを送信したとしても、ネットワークが混雑してくると、その送信レートが６００００ｂｐｓに下がることがある。

このような状況でＲＴＰパケットを受信したデータ受信装置は、プリバッファリング必要時間が１秒として設定されていると、プリバッファリングに必要なデータ量が６４０００ビットでありながら、バッファ占有量が６００００ビットに達した時点で復号化を開始してしまう。

そこで、上述のように送信レートがｓｔｓｐに格納されていれば、データ送信装置１００はその送信レートもデータ受信装置に伝えることで、データ受信装置に適切なプリバッファリング必要時間を特定させることができる。

また、本実施意の形態では、ｓｔｓｐにシンクサンプル番号のフィールドを設けたが、これを省いても良い。
また、本実施の形態では、ＲＴＰパケットの送信レートを一定にしたが、コンテンツが送信されている最中に、ネットワークの輻輳、又はパケットロスの発生頻度など伝送路の状況が変化する場合には、その状況の変化に応じてＲＴＰパケットの送信レートを積極的に変化させても良い。この場合、データ送信装置１００は、ｓｔｓｐに格納されているプリバッファリング情報Ｄ１０９からプリバッファリング必要データ量を取得し、送信時の送信レートに応じてプリバッファリング必要時間を計算する。

例えば、データ送信装置１００は、ＰＬＡＹ命令により要求されたビデオデータに対するプリバッファリング情報ｄ１０９として「プリバッファリング必要データ量１５０００バイト」を取得すると、送信レート６４０００ｂｐｓに基づいて、プリバッファリング必要時間は１５０００×８/６４０００＝１．８７５秒であると判断する。ところが、データ送信装置１００は、ネットワークが混雑しているため、ＰＬＡＹ命令により要求されたビデオデータの送信開始時に、主体的又は必然的に、上記送信レートを６００００ｂｐｓに変更する。これにより、データ送信装置１００は、プリバッファリング必要時間が１５０００×８/６００００＝２．０秒であるとして上記判断を改める。そして、データ送信装置１００は、ＰＬＡＹ命令への応答として、「プリバッファリング必要時間２．０秒」を示すプリバッファリング情報ｄ１０９を再生パラメータ情報ｄ１１０に変換してデータ受信装置に送信する。

ただし、伝送路においてパケットロスが発生したときには、上述のようにデータ受信装置に伝えるプリバッファリング必要時間を単に変更しただけでは、データ受信装置側でのバッファのオーバーフロー及びアンダーフローを防ぐことができない場合がある。

例えば、復号化の開始時には１〜Ｎ番目のＮ個のＲＴＰパケットが必要とされるにも関わらず、パケットロスの発生により、データ受信装置は、データ送信装置１００から通知されたプリバッファリング必要時間内において、１からＮ−２番目のＲＴＰパケットしか受信しないことがある。このとき、データ受信装置がプリバッファリング必要時間を経過した時点で復号化を開始すると、Ｎ−１およびＮ番目のＲＴＰパケットが不足しているため、バッファのアンダーフローが発生する。

そこで、データ送信装置１００は、復号化開始までに受信することが必要なＲＴＰパケットを特定するための情報、例えばシーケンス番号を、プリバッファリング情報ｄ１０９としてデータ受信装置に送信しても良い。ＲＴＰパケットのヘッダには、シーケンス番号と呼ばれるパケットの識別番号が含まれる。ＲＴＰパケットのヘッダに含まれるシーケンス番号は、データ送信装置１００から送信された直前のＲＴＰパケットのヘッダに含まれるシーケンス番号に１を加算した値である。そこで、１番目〜Ｎ番目のＲＴＰパケットの受信が復号化開始までに必要な場合、それらのＲＴＰパケットのシーケンス番号を１〜Ｎとすると、データ送信装置１００は、プリバッファリング情報ｄ１０９として、シーケンス番号１〜Ｎを示す情報をデータ受信装置に伝える。

また、本実施の形態では、ＭＰ４ファイルのヒントトラック（ヒントトラック用のｔｒａｋ）にプリバッファリング情報Ｄ１０９を再生制御情報として含めたが、それ以外にも、ピクチャの復号化を終了してから表示するまでの待ち時間を示す情報や、コンテンツの特定の区間を復号化する際に必要となるバッファサイズ、送信時の暗号化に関する情報を含めてもよい。さらに、ＲＴＰパケットにおいて符号化データをインタリーブして送信する場合には、（１）インタリーブの深さを示す情報、（２）１ピクチャ分のデータの受信開始から終了までにかかる時間、あるいは受信開始時刻と復号時刻との差分値などインタリーブに起因する遅延時間の情報、あるいは（３）インタリーブしてＲＴＰパケット化された符号化データを受信及び再構成して１ピクチャずつ分離するために必要なバッファのサイズを示す情報など、データ受信装置におけるデータ受信、復号化、又は表示の際に有効な情報を、再生制御情報として含めても良い。この場合、データ送信装置１００は、そのような再生制御情報をＭＰ４ファイルのｔｒａｋから取得して再生パラメータ情報ｄ１１０に変換し、データ受信装置に送信する。

また、連続する複数の画像から構成されるシーン単位でビデオデータの復号化処理の初期化に要するシーン初期化情報を、シーンのインデックス番号あるいはシーンの先頭サンプルのサンプル番号などのシーンを識別するための情報と関連付けて、再生制御情報としてＭＰ４ファイルに含めておいても良い。ＭＰＥＧ−４ ＡＶＣでは、シーケンス・パラメータセット（Sequence Parameter Set）とピクチャ・パラメータセット（Picture Parameter Set）がシーン初期化情報に相当する。この場合、例えばクリップ再生のように異なるシーンの画像を順にデータ受信装置が要求したときには、データ送信装置１００は要求された各シーンの画像データをＲＴＰパケットとして送信するとともに、それらに関連するシーン初期化情報をＲＴＳＰのＰＬＡＹ応答などに含めて送信するため、データ受信装置はシーン初期化情報を用いて各シーンごとに適切に初期化を行い、各画像を復号して表示することができる。なお、受信を開始する先頭シーンのシーン初期化情報については、そのシーン初期化情報をＳＤＰに含めることができるため、ＰＬＡＹ応答に含めなくてもよい。

また、ビデオデータに含まれるランダムアクセス可能な画像の周期を示す画像周期情報を、再生制御情報としてＭＰ４ファイルに含めておいても良い。この場合、画像周期情報を受信したデータ受信装置は、その画像周期情報に基づいてビデオデータのランダムアクセス可能な部位を特定することができ、それらの部位から適切に再生処理を行うことができる。例えば、データ受信装置は、その特定結果から約３０秒先の時間位置の画像にランダムアクセスできるか否かを事前に判別することができ、いきなり５分先の時間位置の画像にランダムアクセスしてしまうことを防ぐことができる。

また、本実施の形態では、ＲＴＳＰを用いてプリバッファリング情報ｄ１０９（再生パラメータ情報ｄ１１０）をデータ受信装置に送信したが、ＲＴＳＰ以外のプロトコルを用いて送信しても良い。

また、本実施の形態では、ビデオに対応するプリバッファリング情報Ｄ１０９をｓｔｓｐに格納したが、ビデオ以外のコンテンツ（メディア）、例えばオーディオやテキストなどに対応するプリバッファリング情報を格納しても良い。

また、本実施の形態では、プリバッファリング情報Ｄ１０９をＭＰ４ファイルに多重化するためにｓｔｓｐを用いたが、このｓｔｓｐは、ＭＰＥＧ−２ ＴＳ（Transport Stream）などＲＴＰ以外の伝送方式においてパケットを作成するための情報をＭＰ４ファイルに多重化する場合にも使用される。

また、本実施の形態では、ｓｔｓｓによって示されるシンクサンプルに対するプリバッファリング情報のみをｓｔｓｐに格納したが、それ以外のサンプルに対するプリバッファリング情報も格納しても良い。例えば、シンクサンプル以外のIピクチャを格納するサンプル、又は全てのサンプルに対するプリバッファリング情報をｓｔｓｐに格納しても良い。また、Recovery Point SEIが付加されたIピクチャを格納するサンプルに対するプリバッファリング情報をｓｔｓｐに格納しても良い。

なお、プリバッファリング情報などの再生制御情報をビデオトラックのヘッダ情報に格納してもよい。例えば、ビデオトラックについてもｓｔｓｐのようなＢｏｘを定義することで、ビデオトラックのシンクサンプルについてのプリバッファリング情報をそのＢｏｘに含めることができる。具体的には、ヒントトラックのシンクサンプルから参照されるビデオトラックのサンプルは、シンクサンプルあるいはシンクサンプル以外のランダムアクセス可能なサンプルであるため、そのビデオトラックのサンプルについてのプリバッファリング情報をビデオトラックのヘッダ情報に格納する。ＭＰＥＧ−４ ＡＶＣでは、Recovery Point SEIを含むサンプルについてのプリバッファリング情報をヘッダ情報に格納してもよい。

ここで、上述のRecovery Point SEIについて説明する。
ＭＰＥＧ−４ ＡＶＣでは、ｓｔｓｓにより示されるシンクサンプルは、ＩＤＲ（Instantaneous Decoder Refresh）ピクチャを示す。ＩＤＲピクチャとは、復号順でＩＤＲピクチャ以降のピクチャは、復号順でＩＤＲピクチャ以前のピクチャを参照せずに復号できるというピクチャであり、ＭＰＥＧ−２におけるｃｌｏｓｅｄ ＧＯＰの先頭Iピクチャと同様の特徴をもつ。ＭＰＥＧ−４ ＡＶＣでは、ＩＤＲピクチャ以外にもランダムアクセス可能なピクチャがあり、これらのピクチャは上述のRecovery Point SEIにより識別される。

Recovery Point SEIは、本ＳＥＩ直後のピクチャから復号化を開始した際に、何枚のピクチャを復号化すれば元の画像と同等品質のピクチャが得られるかを示す情報、又はブロークンリンクの識別情報を含む。つまり、Recovery Point SEIが付加されたIピクチャは、ＭＰＥＧ−２におけるｏｐｅｎ−ＧＯＰの先頭Iピクチャと同様の特徴をもつ。そこで上述のように、Recovery Point SEIが付加されたIピクチャのサンプルに対するプリバッファリング情報もｓｔｓｐに格納しても良いのである。

また、データ送信装置１００は、上述のRecovery Point SEIにより示される情報を再生制御情報として扱っても良い。これにより、Recovery Point SEIが付加されたIピクチャからビデオデータを受信したデータ受信装置は、その受信の事前に取得した再生制御情報により、不完全な復号画像を表示するか、正しい復号画像が得られるようになってから表示を開始するかを選択することができると共に、正しい復号画像から表示するために予め復号しておくことが必要なピクチャの枚数を取得することができる。

また、本実施の形態では、プリバッファリング情報Ｄ１０９をＭＰ４ファイルのｔｒａｋのｓｔｓｐに格納したが、ｔｒａｋ又はｍｏｏｖの直下にＳＤＰデータとして格納しても良い。また、ヒントトラックにおけるサンプルの定義を拡張し、ヒントトラックのサンプルとしてｍｄａｔにプリバッファリング情報Ｄ１０９を格納しても良い。

（実施の形態２）
以下、本発明の第２の実施の形態におけるデータ受信装置について、図面を参照しながら説明する。

本実施の形態におけるデータ受信装置は、実施の形態１のデータ送信装置１００からＲＴＳＰに基づいて受信した再生制御情報（再生パラメータ情報）を用い、メディア（コンテンツ）データの適切な再生を行う。

なお、このデータ受信装置がメディアデータとして受信するビデオデータは、ＭＰＥＧ−４ ＡＶＣにより符号化されたデータであっても、ＭＰＥＧ−４ ＶｉｓｕａｌやＨ．２６３など他の符号化方式のビデオデータであってもよい。

図７は、本実施の形態におけるデータ受信装置の構成を示すブロック図である。
データ受信装置２００は、ＲＴＰ受信処理部２０１と、復号部２０２と、表示部２０３と、ＲＴＳＰ処理部２０４と、指示部２０５とを備える。

ＲＴＳＰ処理部２０４は、再生パラメータ情報を含む受信メッセージｄ２０５をデータ送信装置１００から受信するとともに、データ送信装置１００に送信メッセージｄ２０７を送信することにより、データ送信装置１００との間でＲＴＳＰを用いた再生制御を行う。ここでは、再生パラメータ情報は、プリバッファリング情報を示すものとして以下説明する。

ＲＴＳＰ処理部２０４は、受信メッセージｄ２０５に含まれるプリバッファリング情報を取得すると、そのプリバッファリング情報からプリバッファリング必要時間を特定する。例えば、ＲＴＳＰ処理部２０４は、ＲＴＰパケットがＲＴＰ受信処理部２０１に受信されると、その受信開始から、プリバッファリング情報に基づいて特定されたプリバッファリング必要時間だけ経過したときに復号化を開始すべきであると判断する。

さらに、ＲＴＳＰ処理部２０４は、メディア（コンテンツ）毎のＲＴＰパケットの同期情報を含むＲＴＰ制御データｄ２０６をＲＴＰ受信処理部２０１に出力するとともに、指示部２０５に対して、上記プリバッファリング必要時間を含む復号化開始情報ｄ２０９を出力する。

また、ＲＴＳＰ処理部２０４は外部命令ｄ２０８を取得する。この外部命令ｄ２０８は、データ受信装置２００のユーザの操作によって生じる情報であって、コンテンツの受信の開始や終了、一時停止、コンテンツ中の特定時間位置へのジャンプなどを指示する内容を示す。

ＲＴＰ受信処理部２０１は、ＲＴＰパケットｄ２０１を受信し、ＲＴＰパケットｄ２０１から例えばビデオの符号化データｄ２０２を取得した後、その符号化データｄ２０２を復号部２０２に出力する。なお、ＲＴＰ受信処理部２０１は、ＲＴＰパケットｄ２０１の受信から符号化データｄ２０２の出力までの処理を瞬時に行う。また、復号化の開始の対象となるＲＴＰパケットは、ＲＴＰ制御データｄ２０６に基づいて決定される。

また、ＲＴＰ受信処理部２０１は、ＲＴＰパケットｄ２０１の受信を開始した時点で、受信開始信号ｄ２１０を指示部２０５に出力する。
指示部２０５は、受信開始信号ｄ２１０および復号化開始情報ｄ２０９に基づいて復号化を開始するタイミングを決定し、復号化開始を指示する開始指示信号ｄ２１１を復号部２０２に出力する。

復号部２０２は、開始指示信号ｄ２１１を指示部２０５から取得すると、符号化データｄ２０２の復号化を開始し、復号化データｄ２０３を表示部２０３に出力する。
即ち、本実施の形態の復号部２０２は、ＲＴＰ受信処理部２０１にＲＴＰパケットｄ２０１が受信されてからプリバッファリング必要時間だけ経過したときに復号処理を開始する。

表示部２０３は、復号部２０２から復号化データｄ２０３を取得すると、その復号化データｄ２０３の内容を表示する。
図８は、本実施の形態におけるデータ受信装置２００の指示部２０５の動作を示すフロー図である。

まず、指示部２０５は、ＲＴＰ受信処理部２０１から受信開始信号ｄ２１０と、ＲＴＳＰ処理部２０４から復号化開始情報ｄ２０９とを取得する（ステップＳ４０１）。例えば、受信開始信号ｄ２１０は、トラックＩＤ＝１であるビデオトラックに関するＲＴＰパケットｄ２０１の受信が開始されたことを示す。

指示部２０５は、その受信開始信号ｄ２１０の受信をトリガーに、ＲＴＰパケットｄ２０１の受信が開始されてからの経過時間を計時する（ステップＳ４０２）。
次に、指示部２０５は、ステップＳ４０２で計時した経過時間が、復号化開始情報ｄ２０９に含まれるプリバッファリング必要時間と等しいか否かを判別する（ステップＳ４０３）。例えば、ＲＴＰ受信処理部２０１に受信されたＲＴＰパケットｄ２０１がトラックＩＤ＝１のビデオトラックのデータであって、ＲＴＳＰのＰＬＡＹ命令の応答である受信メッセージｄ２０５に「プリバッファリング必要時間Ｍ秒」というプリバッファリング情報が含まれている場合を想定する。この場合、指示部２０５は、トラックＩＤ＝１のビデオトラックのＲＴＰパケットｄ２０１が受信開始されてからＭ秒経過したかどうかを判定する。

指示部２０５は、プリバッファリング必要時間と等しいと判別したときには（ステップＳ４０３のＹｅｓ）、開始指示信号ｄ２１１を復号部２０２に出力し（ステップＳ４０４）、プリバッファリング必要時間と異なると判別したときには（ステップＳ４０３のＮｏ）、再びステップＳ４０２からの動作を実行する。

以上、本発明に係るデータ受信装置２００ついて上記実施の形態を用いて説明したが、本発明に係るデータ受信装置２００はこれらに限定されるものではない。
例えば、本実施の形態では、ＲＴＳＰのＰＬＡＹ命令の応答である受信メッセージｄ２０５からプリバッファリング情報を取得したが、ＲＴＳＰにおけるＰＬＡＹ命令以外の既存の命令、又は新規に規定された命令に対する応答である受信メッセージｄ２０５からプリバッファリング情報を取得しても良い。また、ＲＴＳＰ以外のプロトコルによるメッセージからプリバッファリング情報を取得しても良い。

また、本実施の形態では、プリバッファリング必要時間を示すプリバッファリング情報を取得したが、プリバッファリング必要データ量を示すプリバッファリング情報を取得しても良い。

この場合、ＲＴＰ受信処理部２０１は、メディア（コンテンツ）ごとに受信したＲＴＰパケットｄ２０１の総データ量を示す総量情報を、そのパケットを受信するたびに又は一定時間ごとに、指示部２０５に対して出力する。指示部２０５は、その総量情報に基づいて、ＲＴＰパケットｄ２０１の総データ量とプリバッファリング必要データ量を比較し、それらのデータ量が一致したときに、開始指示信号ｄ２１１を出力する。なお、データ量の比較は、総量情報を取得するごとに、又は一定時間ごとに行っても良い。

また、本実施の形態では、再生パラメータ情報に変換されたプリバッファリング情報を再生制御情報として取得したが、受信、復号化、又は表示処理に関連する情報を再生制御情報として取得しても良い。この場合、指示部２０５又はＲＴＳＰ処理部２０４は、取得した情報に基づいて復号部２０２及び表示部２０３を制御する。

また、本実施の形態では、プリバッファリング情報としてプリバッファリング必要時間を取得したが、シーケンス番号をプリバッファリング情報として取得しても良い。この場合、データ受信装置２００は、取得したシーケンス番号により示されるＲＴＰパケットが全て受信されたときに、復号化処理を開始する。データ受信装置２００は、ＲＴＰパケットを全て受信できなかったときには、受信できなかったＲＴＰパケットをデータ送信装置１００に要求する。または、データ受信装置２００は、復号化開始前に、ユーザに対して警告をした上で、予め設定された条件に基づいて復号化を開始する。この警告は、復号化処理の途中で発生するアンダーフロー又はオーバーフローのため、コンテンツの表示が停止する可能性があることをユーザに知らせるものである。

（実施の形態３）
さらに、上記各実施の形態で示したデータ送信装置１００及びデータ受信装置２００を実現するためのプログラムを、フレキシブルディスク等の記憶媒体に記録するようにすることにより、上記各実施の形態で示した処理を、独立したコンピュータシステムにおいて簡単に実施することが可能となる。

図９は、実施の形態１，２のデータ送信装置１００及びデータ受信装置２００をコンピュータシステムにより実現するためのプログラムを格納する記憶媒体についての説明図である。

図９中の（ｂ）は、フレキシブルディスクＦＤの正面及び側面からみた外観と、記録媒体の本体であるディスク本体ＦＤ１の正面からみた外観とを示し、図９中の（ａ）は、ディスク本体ＦＤ１の物理フォーマットの例を示している。

ディスク本体ＦＤ１はケースＦ内に内蔵され、ディスク本体ＦＤ１の表面には、同心円状に外周からは内周に向かって複数のトラックＴｒが形成され、各トラックは角度方向に１６のセクタＳｅに分割されている。従って、上記プログラムを格納したフレキシブルディスクＦＤでは、上記ディスク本体ＦＤ１上に割り当てられた領域に、上記プログラムが記録されている。

また、図９中の（ｃ）は、フレキシブルディスクＦＤに上記プログラムの記録再生を行うための構成を示す。
上記プログラムをフレキシブルディスクＦＤに記録する場合は、コンピュータシステムＣｓが上記プログラムをフレキシブルディスクドライブＦＤＤを介して書き込む。また、フレキシブルディスクＦＤ内のプログラムをコンピュータシステムＣｓ中に構築する場合は、フレキシブルディスクドライブＦＤＤによりプログラムがフレキシブルディスクＦＤから読み出され、コンピュータシステムＣｓに転送される。

なお、上記説明では、記録媒体としてフレキシブルディスクＦＤを用いて説明を行ったが、光ディスクを用いても同様に行うことができる。また、記録媒体はこれに限らず、ＩＣカード、ＲＯＭカセット等、プログラムを記録できるものであれば同様に実施することができる。

本発明に係るデータ送信装置は、データ受信装置に対してコンテンツデータの適切な再生処理を実行させることができ、例えば携帯端末向けの動画像配信サービスに利用されるサーバなどに有用である。

本発明の実施の形態１に係るデータ送信装置の構成を示すブロック図である。 ｓｔｓｐに格納されたプリバッファリング情報の内容の一例を示すデータ内容表示図である。 ｓｔｓｐに格納されたプリバッファリング情報の内容の他の例を示すデータ内容表示図である。 データ送信装置のファイル解析部の動作を示すフロー図である。 プリバッファリング情報の取得処理（図４のステップＳ１０５）の詳細な動作を示すフロー図である。 データ送信装置とデータ受信装置との間で交換されるＲＴＳＰメッセージの一例を示す図である。 本発明の実施の形態２に係るデータ受信装置の構成を示すブロック図である。 同上のデータ送信装置の指示部の動作を示すフロー図である。 本発明の実施の形態３における、実施の形態１又は２のデータ送信装置及びデータ受信装置をコンピュータシステムにより実現するためのプログラムを格納する記憶媒体についての説明図である。 ＭＰ４ファイルのＢｏｘの構造を説明するための図である。 ＭＰ４ファイルの構造を示すデータ構成図である。 ヒントデータの使用方法を説明するための図である。 サーバから端末にメディアデータ（コンテンツデータ）がＲＴＰパケットとして配信される手順を説明するための図である。 サーバと端末と間の再生制御において交換されるＲＴＳＰメッセージの一例を示す図である。 従来のデータ送信装置（サーバ）の構成を示すブロック図である。 同上のデータ送信装置のファイル解析部の動作を示すフロー図である。 符号化データの流入開始からの経過時間（横軸）と、データ受信装置のバッファの占有量（縦軸）との関係を示す図である。 プリバッファリング時間に応じて異なるバッファ占有量の時間的な変化を示す図である。

符号の説明

１００ データ送信装置
１０１ ＲＴＳＰ処理部
１０２ ＲＴＰ作成部
１０３ ＲＴＰ送出部
１０４ ファイル作成部
１１０ ファイル解析部
１１１ 情報取得部
１１２ ＲＴＰ解析部
１１３ 再生解析部
１１４ 変換部
ｄ１０１ ＲＴＳＰ要求データ
ｄ１０２ サンプルデータ
ｄ１０３ サンプル番号情報
ｄ１０４ パケット作成データ
ｄ１０５ ＲＴＳＰ送出情報
ｄ１０７ 送信メッセージ
ｄ１０８ 受信メッセージ
ｄ１０９ 再生制御情報
ｄ１１０ 再生パラメータ情報

Claims (19)

1. デジタル著作物たるコンテンツデータをファイルから取り出して受信装置に対して送信するデータ送信装置であって、
   前記ファイルは、前記コンテンツデータと、前記コンテンツデータの再生処理に用いられる再生制御情報とを多重化して構成され、
   前記データ送信装置は、
   前記受信装置との間でコンテンツデータの伝送路の確立及び初期化を行う前置処理手段と、
   前記前置処理手段による伝送路の確立及び初期化の後、前記再生制御情報の少なくとも一部を前記ファイルから取り出して、前記受信装置に送信する制御送信手段と、
   前記ファイルからコンテンツデータの少なくとも一部を取得してパケット化するパケット生成手段と、
   前記パケット生成手段によりパケット化されたコンテンツデータの少なくとも一部を送信するコンテンツ送信手段と
   を備えることを特徴とするデータ送信装置。
2. 前記ファイルに多重化された再生制御情報は、前記コンテンツデータに含まれる複数のデータ単位ごとに、当該データ単位からの再生に用いられる再生制御単位情報を含んでテーブル状に構成され、
   前記制御送信手段は、前記受信装置からの要求に応じたデータ単位に関連する前記再生制御単位情報を、前記ファイルの再生制御情報から取り出して送信し、
   前記パケット生成手段は、前記受信装置からの要求に応じたデータ単位からの前記コンテンツデータを取得してパケット化する
   ことを特徴とする請求項１記載のデータ送信装置。
3. 前記再生制御単位情報は、前記コンテンツ送信手段から送信されて前記受信装置に受信されるコンテンツデータに対して、復号処理を開始すべきタイミングを知らせる内容を示す
   ことを特徴とする請求項２記載のデータ送信装置。
4. 前記再生制御単位情報は、前記タイミングを知らせる内容として、前記受信装置によるコンテンツデータの受信開始から前記復号処理の開始までの時間を示す
   ことを特徴とする請求項３記載のデータ送信装置。
5. 前記再生制御単位情報は、前記タイミングを知らせる内容として、前記受信装置によって受信されるコンテンツデータのデータ量を示す
   ことを特徴とする請求項３記載のデータ送信装置。
6. 前記制御送信手段は、前記再生制御単位情報の示すデータ量を、前記受信装置によるコンテンツデータの受信開始から前記復号処理の開始までの時間に変換し、前記変換された再生制御単位情報を送信する
   ことを特徴とする請求項５記載のデータ送信装置。
7. 前記制御送信手段は、前記再生制御単位情報を、前記コンテンツ送信手段におけるコンテンツデータの伝送状況に応じて変換する
   ことを特徴とする請求項６記載のデータ送信装置。
8. 前記コンテンツ送信手段は、伝送路の状況に基づいて、コンテンツデータの送信速度を変化させる
   ことを特徴とする請求項７記載のデータ送信装置。
9. 前記コンテンツデータは、複数の画像を含んで構成される動画像データであって、
   前記再生制御情報は、前記コンテンツデータに含まれる全ての画像ごとに、前記再生制御単位情報を含んで構成されている
   ことを特徴とする請求項２記載のデータ送信装置。
10. 前記コンテンツデータは、複数の画像を含んで構成される動画像データであって、
    前記再生制御情報は、前記コンテンツデータに含まれる画面内符号化された画像ごとに、前記再生制御単位情報を含んで構成されている
    ことを特徴とする請求項２記載のデータ送信装置。
11. 前記コンテンツデータは、複数の画像を含んで構成される動画像データであって、
    前記再生制御単位情報は、当該データ単位の先頭の画像から正しい復号処理結果が得られるか否かを示す
    ことを特徴とする請求項２記載のデータ送信装置。
12. 前記コンテンツデータは、複数の画像を含んで構成される動画像データであって、
    前記再生制御単位情報は、当該データ単位の先頭の画像から復号処理が開始された場合に、最初に正しい復号処理結果が得られる部位を示す
    ことを特徴とする請求項２記載のデータ送信装置。
13. 前記コンテンツデータは、連続する複数の画像から構成されるシーンを前記データ単位として含む動画像データであって、
    前記再生制御情報は、前記各シーンを構成する画像を復号化する際の初期化に要する情報を示す
    ことを特徴とする請求項２記載のデータ送信装置。
14. 前記コンテンツデータは、複数の画像を含んで構成される動画像データであって、
    前記再生制御情報は、前記複数の画像のうちのランダムアクセス可能な画像の周期を示す
    ことを特徴とする請求項１記載のデータ送信装置。
15. 前記ファイルに多重化された再生制御情報は、前記コンテンツデータに含まれる所定の１つのデータ単位からの再生に用いられる再生制御単位情報であって、
    前記制御送信手段は、前記受信装置からの要求に応じて前記再生制御単位情報を前記ファイルから取り出して送信し、
    前記パケット生成手段は、前記受信装置からの要求に応じて前記データ単位からの前記コンテンツデータを取得してパケット化する
    ことを特徴とする請求項１記載のデータ送信装置。
16. デジタル著作物たるコンテンツデータをファイルから取り出して受信装置に対して送信するデータ送信方法であって、
    前記ファイルは、前記コンテンツデータと、前記コンテンツデータの再生処理に用いられる再生制御情報とを多重化して構成され、
    前記データ送信方法は、
    前記受信装置との間でコンテンツデータの伝送路の確立及び初期化を行う前置処理ステップと、
    前記伝送路の確立及び初期化が行われた後、前記再生制御情報の少なくとも一部を前記ファイルから取り出して、前記受信装置に送信する制御送信ステップと、
    前記ファイルからコンテンツデータの少なくとも一部を取得してパケット化するパケット生成ステップと、
    前記パケット生成ステップでパケット化されたコンテンツデータの少なくとも一部を送信するコンテンツ送信ステップと
    を含むことを特徴とするデータ送信方法。
17. 前記ファイルに多重化された再生制御情報は、前記コンテンツデータに含まれる複数のデータ単位ごとに、当該データ単位からの再生に用いられる再生制御単位情報を含んでテーブル状に構成され、
    前記制御送信ステップでは、前記受信装置からの要求に応じたデータ単位に関連する前記再生制御単位情報を、前記ファイルの再生制御情報から取り出して送信し、
    前記パケット生成ステップでは、前記受信装置からの要求に応じたデータ単位からの前記コンテンツデータを取得してパケット化する
    ことを特徴とする請求項１６記載のデータ送信方法。
18. 前記再生制御単位情報は、前記コンテンツ送信ステップで送信されて前記受信装置に蓄積されるコンテンツデータに対して、再生処理を開始すべきタイミングを知らせる内容を示す
    ことを特徴とする請求項１７記載のデータ送信方法。
19. デジタル著作物たるコンテンツデータをファイルから取り出して受信装置に対して送信するためのプログラムであって、
    前記ファイルは、前記コンテンツデータと、前記コンテンツデータの再生処理に用いられる再生制御情報とを多重化して構成され、
    前記データ送信方法は、
    前記受信装置との間でコンテンツデータの伝送路の確立及び初期化を行う前置処理ステップと、
    前記伝送路の確立及び初期化が行われた後、前記再生制御情報の少なくとも一部を前記ファイルから取り出して、前記受信装置に送信する制御送信ステップと、
    前記ファイルからコンテンツデータの少なくとも一部を取得してパケット化するパケット生成ステップと、
    前記パケット生成ステップでパケット化されたコンテンツデータの少なくとも一部を送信するコンテンツ送信ステップと
    をコンピュータに実行させることを特徴とするプログラム。

Images