(57)【要約】【課題】  トラックを動的に切り替えて送信し、切り替えられた箇所を滑らかに再生することを可能にするコンテンツ配信方法、コンテンツ配信方法を用いたコンテンツ配信サーバ及びコンテンツ受信装置を提供する。【解決手段】  伝送制御部３２は、コンテンツデータのファイル名、トラック番号、およびコンテンツの再生範囲と共にコンテンツの再生要求メッセージを送信し、伝送制御部２２が再生要求メッセージを受信すると、コンテンツ取得部２１はファイル名、トラック番号、およびコンテンツの再生範囲に従って、指定されたトラックのコンテンツ素片を取得する。伝送制御部３２がトラック番号と共にトラックの切替要求メッセージを送信し、伝送制御部２２が切替要求メッセージを受信すると、コンテンツ取得部２１は、トラック番号に従って、送出したコンテンツ素片が有する時刻情報に連続する時刻情報を有する指定されたトラックのコンテンツ素片を取得する。【選択図】  図１
2005173241.tif 000002
【特許請求の範囲】
【請求項１】
複数のコンテンツ素片データを有するコンテンツデータを記憶しているコンテンツ配信サーバと、このコンテンツ配信サーバに対して、ネットワークを介してコンテンツの再生要求を行い、その再生要求に応じてコンテンツ配信サーバからネットワークを介して送信されるコンテンツ素片データを受信し再生するコンテンツ受信装置とを備えたコンテンツ配信システムにおけるコンテンツ配信方法であって、
コンテンツ配信サーバに記憶されているコンテンツデータは、ファイル名と複数のトラックとを有するコンテンツデータであり、前記各トラックのトラックデータは、トラック番号と複数のデータフレームとを有し、前記各データフレームは、フレーム番号、再生のタイミングを示す時刻情報、およびコンテンツ素片データを有するものであり、同一の前記フレーム番号における各トラックの前記データフレームが、同一の前記時刻情報を有するものであり、
前記コンテンツ受信装置から前記コンテンツ配信サーバへ再生を要求する前記コンテンツデータの前記ファイル名を送信し、これに応じて前記コンテンツ配信サーバから送信される少なくとも予め設定されている前記トラック番号、および前記ファイル名のコンテンツデータにおける前記予め設定されているトラック番号のトラックの再生時間長を示す再生時間情報を前記コンテンツ受信装置が受信し、前記コンテンツ受信装置が所望の前記トラック番号を指定して前記コンテンツ配信サーバへ送信することにより、前記コンテンツ受信装置−前記コンテンツ配信サーバ間のセッションを確立するセッション確立工程と、
前記セッションの確立後、コンテンツの再生開始要求を行う際に、
前記コンテンツ受信装置において、当該再生を要求する前記コンテンツデータの前記ファイル名、および再生する時間範囲を示す再生範囲情報を含むコンテンツの再生開始要求メッセージを、前記コンテンツ受信装置から前記コンテンツ配信サーバに送信する工程と、
前記コンテンツ配信サーバにおいて、前記再生開始要求メッセージを受信した場合に、当該再生開始要求メッセージ内の前記再生範囲情報に従って、送信すべき前記コンテンツ素片データを含む前記データフレームの前記フレーム番号を特定し、この特定された前記フレーム番号、当該再生開始要求メッセージ内の前記ファイル名、および前記セッション確立時に前記コンテンツ受信装置が指定した前記トラック番号によって指定される、再生要求された前記コンテンツ素片データを前記記憶されているコンテンツデータから取得し、前記コンテンツ受信装置に送信する工程と、
前記セッションの確立後、再生対象トラックの切替要求を行う際に、
前記コンテンツ受信装置において、再生トラック切替のための切替先トラック番号を含む切替要求メッセージを前記コンテンツ受信装置から前記コンテンツ配信サーバに送信する工程と、
前記コンテンツ配信サーバにおいて、前記再生開始要求メッセージ受信後に前記切替要求メッセージを受信した場合に、当該切替要求メッセージを受信した時点での既送の前記コンテンツ素片データのうち再生順序が最後となっている前記コンテンツ素片データを含む前記データフレームにおける前記時刻情報に基づき、この再生順序が最後となっている前記コンテンツ素片データに連続して再生されるべき前記コンテンツ素片データを含む前記データフレームの前記フレーム番号を特定し、この特定された前記フレーム番号、および当該切替要求メッセージ内の前記切替先トラック番号によって指定される前記コンテンツ素片データを、前記記憶されているコンテンツデータから取得し、コンテンツ受信装置に送信する工程と、
を有することを特徴とするコンテンツ配信方法。
【請求項２】
コンテンツ受信装置からの再生要求に従って、複数のコンテンツ素片データを有するコンテンツデータから再生要求されたコンテンツ素片データを選択し、選択したコンテンツ素片データをネットワークを介して前記コンテンツ受信装置へ送信するコンテンツ配信サーバであって、
ファイル名と複数のトラックとを有するコンテンツデータであり、前記各トラックのトラックデータは、トラック番号と複数のデータフレームとを有し、前記各データフレームは、フレーム番号、再生のタイミングを示す時刻情報、およびコンテンツ素片データを有するものであり、同一の前記フレーム番号における各トラックの前記データフレームが、同一の前記時刻情報を有するコンテンツデータを記憶するコンテンツ記憶手段と、
前記コンテンツ受信装置から再生を要求する前記コンテンツデータの前記ファイル名を受信し、これに応じて少なくとも予め設定されている前記トラック番号、および前記ファイル名のコンテンツデータにおける前記予め設定されているトラック番号のトラックの再生時間長を示す再生時間情報を当該コンテンツ受信装置へ送信し、その後、前記コンテンツ受信装置によって指定された所望の前記トラック番号を受信することにより、前記コンテンツ受信装置との間のセッションを確立し、
前記セッションの確立後、前記コンテンツ受信装置においてコンテンツの再生開始要求がなされた際に、前記コンテンツ受信装置から、再生を要求する前記コンテンツデータの前記ファイル名、および再生する時間範囲を示す再生範囲情報を含むコンテンツの再生開始要求メッセージを受信し、
前記セッションの確立後、前記コンテンツ受信装置において再生対象トラックの切替要求がなされた際に、前記コンテンツ受信装置から、再生トラック切替のための切替先トラック番号を含む切替要求メッセージを受信するための伝送制御手段と、
前記伝送制御手段が前記再生開始要求メッセージを受信した場合に、当該再生開始要求メッセージ内の前記再生範囲情報に従って、送信すべき前記コンテンツ素片データを含む前記データフレームの前記フレーム番号を特定し、この特定された前記フレーム番号、当該再生開始要求メッセージ内の前記ファイル名、および前記セッション確立時に前記コンテンツ受信装置が指定した前記トラック番号によって指定される、再生要求された前記コンテンツの前記コンテンツ素片データを前記コンテンツ記憶手段から取得し、
前記伝送制御手段が前記再生開始要求メッセージ受信後に前記切替要求メッセージを受信した場合に、当該切替要求メッセージを受信した時点での既送の前記コンテンツ素片データのうち再生順序が最後となっている前記コンテンツ素片データを含む前記データフレームにおける前記時刻情報に基づき、この再生順序が最後となっている前記コンテンツ素片データに連続して再生されるべき前記コンテンツ素片データを含む前記データフレームの前記フレーム番号を特定し、この特定された前記フレーム番号、および当該切替要求メッセージ内の前記切替先トラック番号によって指定される前記コンテンツ素片データを、前記コンテンツ記憶手段から取得するコンテンツ取得手段と、
前記コンテンツ取得手段が取得した前記コンテンツ素片データを前記コンテンツ受信装置へ送信する送信手段と、
を備えることを特徴とするコンテンツ配信サーバ。
【請求項３】
複数のコンテンツ素片データを有するコンテンツデータを記憶しているコンテンツ配信サーバに対して、ネットワークを介してコンテンツの再生要求を行い、その再生要求に応じてコンテンツ配信サーバからネットワークを介して送信されるコンテンツ素片データを受信し再生するコンテンツ受信装置であって、
前記コンテンツ配信サーバに記憶されているコンテンツデータは、ファイル名と複数のトラックとを有するコンテンツデータであり、前記各トラックのトラックデータは、トラック番号と複数のデータフレームとを有し、前記各データフレームは、フレーム番号、再生のタイミングを示す時刻情報、およびコンテンツ素片データを有するものであり、同一の前記フレーム番号における各トラックの前記データフレームが、同一の前記時刻情報を有するものであり、
再生を要求する前記コンテンツデータの前記ファイル名を送信し、これに応じて前記コンテンツ配信サーバから送信される少なくとも予め設定されている前記トラック番号、および前記ファイル名のコンテンツデータにおける前記予め設定されているトラック番号のトラックの再生時間長を示す再生時間情報を受信し、その後、所望の前記トラック番号を指定して前記コンテンツ配信サーバへ送信することにより、前記コンテンツ配信サーバとの間のセッションを確立し、
前記セッションの確立後、コンテンツの再生開始要求を行う際に、再生を要求する前記コンテンツデータの前記ファイル名、および再生する時間範囲を示す再生範囲情報を含むコンテンツの再生開始要求メッセージを前記コンテンツ配信サーバに送信し、
前記セッションの確立後、再生対象トラックの切替要求を行う際に、再生トラック切替のための切替先トラック番号を含む切替要求メッセージをコンテンツ配信サーバに送信する伝送制御手段を備えることを特徴とするコンテンツ受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを介して、複数トラックから構成されるコンテンツデータを送信するコンテンツ配信サーバと当該コンテンツデータを受信再生するコンテンツ受信装置からなるコンテンツ配信システムにおいて、トラックを動的に切り替えて送信し、切り替えられた箇所を滑らかに再生することを可能にするコンテンツ配信方法、およびコンテンツ配信方法を用いたコンテンツ配信サーバ、およびコンテンツ受信装置に関する。
【背景技術】
【０００２】
まず、映像・音声等の実時間配信に用いられているストリーミングシステムの非同期モデルについて説明する。
【０００３】
Ethernet（登録商標）（IEEE802.3）を代表とする小さなデータサイズの伝送フレームの相互交換を基調としたデータリンクでは、エンド・ツー・エンド接続された２つの通信装置間に同期クロックは存在しない場合が大半であり、データリンクを下位層として、複数のネットワーク間のパケット交換を可能にするためのIP（Internet Protocol,RFC791,RFC2460）、さらにIPを下位層としてIPパケットを用いてセッション（通信路）管理を行うためのTCP（Transmission Control Protocol,RFC793）やUDP（User Datagram Protocol,RFC768）などのネットワークプロトコルにも同期クロックは存在しない。
【０００４】
そのため、ある通信装置から送信された伝送フレームがいつ何時目的の通信装置へ届くかは保証されない。また、伝送フレームの送信から受信までに発生する時間遅延は一定ではなく、時間揺らぎ（ジッタ）が生じる。また、伝送フレームは伝送路上で消失することもあり、ある時間軸に沿って複数の伝送フレームを送信したとしても、その到着順序は保証されない。
【０００５】
ところで、ストリーミングシステムとは、ネットワークを介してコンテンツを受信し再生するシステムのうち、受信側でコンテンツの全てを蓄積せずに、受信しながら再生が可能となるようなシステムの総称である。映像・音声等は、実時間性を持ったコンテンツであるから、1秒間に所定のコマ数（例えば29.97フレーム／秒）で再生するといった再生同期制御が必須であり、同期クロックの存在は好適であると言える。例えば、ＴＶ放送においては、NTSC_TV信号におけるフレーム同期信号と呼ばれる同期クロックが存在し、受信側は、送信側の同期クロックを用いて非常に高い精度で再生することが可能である。
【０００６】
しかし、IPをベースとしたIPネットワークを介したストリーミングシステムでは、上述のような同期クロックがなく、送信側と受信側を同期させることはできない。必然的に非同期モデルによって再生機構を実現せざるを得ない。非同期モデルとは、各々の機器自身のシステムクロックを基準として動作する構成およびプログラミング手法である。
【０００７】
図８に、コンテンツ配信システム１０１ａ（非同期モデル）におけるコンテンツ配信サーバ１０２ａとコンテンツ受信装置１０３ａの機能ブロック図を示す。コンテンツ配信サーバ１０２ａとコンテンツ受信装置１０３ａは、IPネットワーク１０４によって相互に接続される。
【０００８】
コンテンツ配信サーバ１０２ａは、コンテンツ取得部１０２１、送信部１０２２、システムクロック発振部１０２３、およびコンテンツ記憶部１０２４を有する。
【０００９】
コンテンツ取得部１０２１は、再生するコンテンツのコンテンツデータをコンテンツ記憶部１０２４に記録し、任意のファイルポインタ（コンテンツ上の読み出し位置）を用いてコンテンツ素片を取得する機能を有する。この時、ファイルポインタとは、コンテンツファイル名、トラック番号、フレーム番号の３つのうちいずれか、もしくはそれらのうちいくつかの組み合わせである。また、“コンテンツ素片”とは、任意のデータ長を有するコンテンツの実データのことを指す。
【００１０】
コンテンツ取得部１０２１は、システムクロック信号に従ってコンテンツ素片を読み出す。コンテンツ取得部１０２１は、内部にコンテンツファイル名、トラック番号、フレーム番号等の初期値を持ち、起動時から自動的に読み出しを開始しても良いし、外部入力からコンテンツファイル名、トラック番号、コンテンツ再生開始時刻を得てから読み出しを開始しても良い。また、コマンド入力を受け付ける外部入力を設け、コマンド入力＝再生開始定数（例えば“PLAY”）である場合は再生するようにしても良いし、コマンド入力＝再生停止定数（例えば“STOP”）である場合は停止するようにしても良い。あるいは自動読み出し開始動作と外部読み出し開始動作を自動的に判別するようにしても良い。
【００１１】
また、システムクロック発振部１０２３は、水晶発振子等で実現されたリアルタイムクロック（高精度の時計）であり、システムクロック信号をコンテンツ取得部へ供給する機能を有する。
【００１２】
送信部１０２２は、セッションと呼ぶ仮想的な通信路を確保し、コンテンツ素片を適切なヘッダを付加してパケット化し、そのパケットを、IPネットワーク１０４を介してコンテンツ受信装置１０３ａへ送信する機能を有する。例えば、ヘッダにはネットワークタイムスタンプ（後述）が含まれる。
【００１３】
パケットを送信する際には、送信部１０２２は、コンテンツ受信装置１０３ａへパケットを届けるために送信アドレスを用いる。送信アドレスは、送信アドレスと送信ポート番号の組で構成される。送信アドレスは送信部１０２２内部の定数として予め持っていてもよいし、他のブロックから入力を受け付けてもよい。なお、パケットを送信するためのセッション（通信路）は送信アドレスが確定した時点で動的に確立するものとする。また、コンテンツ素片とパケットが必ずしも一致する必要はない。
【００１４】
また、コンテンツ受信装置１０３ａは、受信部１０３１、バッファ部１０３２、システムクロック発振部１０３３、コンテンツ読取部１０３４、および再生部１０３５を有する。
【００１５】
受信部１０３１は、IPネットワーク１０４からパケットを受信して、ヘッダを解釈して、コンテンツ素片を取り出し、バッファ部１０３２に供給する機能を有する。受信部１０３１は、コンテンツ配信サーバ１０２ａからのパケットのうち自己に必要なパケットのみを受信するために受信アドレスを用いる。受信アドレスは、受信アドレスと受信ポート番号の組で構成される。受信アドレスは受信部１０３１内部の定数として予め持っていても良いし、他のブロックから入力を受け付けても良い。
【００１６】
バッファ部１０３２は、コンテンツ素片をヘッダから得られたネットワークタイムスタンプ（後述）と共に一次的に蓄積記憶する機能を有する。
【００１７】
コンテンツ読取部１０３４は、バッファ部１０３２を監視し、再生に十分なコンテンツ素片が蓄積されたと判断した時点から、システムクロック発振部１０３３からのシステムクロック信号に従ってコンテンツ素片の読み出しを開始し、コンテンツ素片の集合をコンテンツに復元して出力する機能を有する。
【００１８】
再生部１０３５は、入力されたコンテンツ素片に応じた復号化を行い、スピーカ等の所定の出力装置に対して音声信号、映像信号を出力する機能を有する。例えば、コンテンツ素片がMPEGに類する高能率符号化されたデジタル音声データである場合、再生部１０３５は、高能率符号復号器（デコーダ）、D/A変換器、アナログアンプ等を有して構成される。
【００１９】
図８に示すコンテンツ配信システムａ（非同期モデル）の第１の特徴は、コンテンツ配信サーバ１０２ａとコンテンツ受信装置１０３ａが個別にシステムクロック発振部１０２３、１０３３を有する点にある。両者のシステムクロック周波数の精度は相当に高い必要はあるが、伝送路であるIPネットワーク１０４が同期クロックの伝送機構を備えてはいない。
【００２０】
また、第２の特徴は、コンテンツ受信装置１０３ａがバッファ部１０３２を備え、バッファ部１０３２が空にならないようにコンテンツ読取部１０３４を構成することによって、再生部１０３５が映像・音声等の実時間性を持ったコンテンツを再生する場合であっても、IPネットワーク１０４によって生じるパケットの時間遅延や時間揺らぎ（ジッタ）を吸収しつつ、正常な再生を継続する点にある。
【００２１】
以上が、映像・音声等の実時間配信に用いられているストリーミングシステムの非同期モデルの概要である。
【００２２】
次に、ストリーミングシステムにおける再生時刻管理について説明する。
【００２３】
まず、コンテンツの再生時刻の付与方法について説明する。
【００２４】
上述の非同期モデルにおいては、コンテンツが連続メディアとして正しい再生時刻に再生されるためには、コンテンツ再生時刻をコンテンツ素片に関連付けて伝送する必要がある。例えば、図８において、コンテンツ読取部１０３４が、0秒0フレーム目の映像に相当するコンテンツ素片を選び出して、再生部１０３５に出力するためには、そのコンテンツ素片が0秒0フレーム目のデータであることを示すコンテンツ再生時刻が必要である。そうしなければ、ネットワーク上で時間遅延などが生じた場合は、そのまま再生時の時刻がずれてしまうことになる。
【００２５】
ストリーミングシステムにおいては、コンテンツ素片にコンテンツ再生時刻を付与するために、RTP（Real-time Transfer Protocol,RFC1889）を用いることが多い（Audio-Video Transport Working Group, "RTP: A Transport Protocol for Real-Time Applications",RFC1889, Internet Engineering Taskforce, Jan 1996）。RTPでは、コンテンツ素片をペイロード（貨物）とし、また、ペイロードに先立って付与される最低96bitのRTPヘッダを主体とし、そのうち32bitがRTPタイムスタンプと呼ばれるネットワークタイムスタンプ（コンテンツ再生時刻を変形したもの）に割り当てられている。
【００２６】
RTPタイムスタンプは、予めコンテンツの種類によって定められた、RTPタイムスタンプ周波数によって実時間に写像される。RTPタイムスタンプ周波数は、ネットワークタイムスタンプ周波数とも呼ばれる。一般に、MPEG（Motion Picture Experts Group）の定めた高能率符号化方式によってデジタル化されたコンテンツの場合、RTPタイムスタンプ周波数には90000（90KHz）を用いることが多い。これは、1秒分のコンテンツを読み出した時、RTPタイムスタンプは+90000増加されることを意味する。つまり、RTPタイムスタンプに類するネットワークタイムスタンプとネットワークタイムスタンプ周波数とコンテンツ再生時刻には、以下の式が成り立つ。
【００２７】
＜数１＞
コンテンツ再生時刻＝ネットワークタイムスタンプ／ネットワークタイムスタンプ周波数
例えば、29.97fpsのMPEG-2映像の場合、最初の1フレーム目のRTPタイムスタンプが“0”であるとすると、2フレーム目は“3003”、30フレーム目は“90090”となる。
【００２８】
また、MPEG-4 Audio AACの場合、１フレームは1024サンプル固定であり、かつRTPタイムスタンプ周波数は音源のPCMサンプリング周波数を用いる。例えば、PCMサンプリング周波数44100Hz（44.1KHz PCM= CD Audio）の場合、RTPタイムスタンプ周波数は44100であり、1フレーム目のRTPタイムスタンプは“0”、2フレーム目は“1024”、約1秒分に当たる43フレーム目は“44032”となる。
【００２９】
なお、今回はRTPを例示して説明したが、再生時刻に供されるネットワークタイムスタンプと、それに対応したネットワークタイムスタンプ周波数から、受信側でのコンテンツ再生時刻を計算しうるパケットフォーマットは他にもあり、極めて有り触れたものである。例えば、MPEGが規格化した伝送規格MPEG-2 Transport StreamにはPresentation Time Stampと呼ばれる、全く同様の機能を持つタイムスタンプが規格化されている。以上が、コンテンツ再生時刻の付与方法の概要である。
【００３０】
次に、コンテンツ配信サーバ１０２ａが管理しコンテンツ受信装置へ送信するコンテンツを記録したファイル（以下、コンテンツファイルと称す）のデータ構造について説明する。
【００３１】
図９に、コンテンツ取得部１０２１によって管理されるコンテンツデータのデータ構造の一例を示す。図９に示すように、コンテンツデータは、コンテンツファイル名、総トラック数Ｔ、および各トラックのトラックデータから構成され、さらに各トラックのトラックデータは、トラック番号、トラックタイムスタンプ周波数、総フレーム数、およびフレーム番号、時刻情報、コンテンツ素片からなる複数のデータフレームから構成される。
【００３２】
コンテンツファイル名は、コンテンツ記憶部上でコンテンツデータを格納するファイルを一意に特定する名前である。また、総トラック数は１つのコンテンツデータ内に収められたトラック数を記録する。トラックとは、１つのファイル内に格納されている複数のコンテンツのそれぞれを指し、トラック番号によって、任意のトラック（コンテンツ）を選択することができ、ポインタとしての時刻情報によって、任意の位置から取り出すことができる。また、各トラックに記録されるトラックタイムスタンプ周波数は、時刻情報の単位時間当たりの増分を示す。
【００３３】
また、各トラックには、コンテンツ素片の総数である総フレーム数が記録されているが、この総フレーム数は各トラックで一致していなくても良い。また、各コンテンツ素片には、時系列順にフレーム番号が付与され、トラックタイムスタンプ周波数を基準とした時刻情報が付与される。
【００３４】
以上のような複数のコンテンツが多重化されたコンテンツデータのデータ構造は、音声・動画等を格納するファイル形式として極めて有り触れたものである。ファイル形式によっては、トラックタイムスタンプ周波数がシステム定数でデータ内に含まれていない場合や、時刻情報の保存領域を節約するために同一の時刻情報を持つフレーム同士がインデックス化されている場合がある等の細かな違いはあるが、フレーム番号と時刻情報が相互変換可能な状態で保持されているという点は共通である。
【００３５】
このようなファイル形式としては、Microsoft AVIや、Apple Computer QuickTime FormatやISO/IEC 14496-1 MP4 Fileなどが挙げられる。また、Apple Computer QuickTime Format やISO/IEC 14496-1 MP4 Fileにおいては、参照Atom（Data Reference Atom）を使用することによって、複数トラックの全部または一部のコンテンツを、外部のコンテンツデータとして独立することができるが、主となるコンテンツデータにフレーム番号と時刻情報が相互変換可能な状態で記録されているので、コンテンツデータと同等のデータ構造を持つとみなして良い。以上がコンテンツ配信サーバ１０２ａにおけるコンテンツデータのデータ構造の概要である。
【００３６】
次に、コンテンツデータを読み出す際のコンテンツ取得部１０２１の再生時刻管理処理（送信側）について、図１０のフローチャートを用いて説明する。
【００３７】
まず、コンテンツ受信装置１０３ａからコンテンツの再生要求がされると、コンテンツ配信サーバ１０２ａのコンテンツ取得部１０２１は、以下に示す６つの変数の初期化を行う（ステップＳ１０１）。
【００３８】
１：コンテンツファイル名CF＝デフォルトのコンテンツファイル名（例えば“hoge.mp4”）
２：トラック番号TN＝デフォルトのトラック番号（例えば“1”）
３：開始フレーム番号FN＝デフォルトのフレーム番号（例えば“1”）
４：再生開始時刻STS＝システムクロック発振部１０２３から得た現在時刻NTS
５：コンテンツ再生時刻CTS＝“0”
６：再生状態フラグF＝真偽値“Ｎ”
次に、コンテンツ取得部１０２１は、自動的に再生を開始するか否かを示す予め定められた自動モード定数を参照し、自動再生を行うかどうか判定する（ステップＳ１０２）。自動モード定数が真偽値“Ｙ”である場合は、ステップＳ１１０の処理へ移行し、自動モード定数が真偽値“Ｎ”である場合には、ステップＳ１０３の処理へ移行する。
【００３９】
ステップＳ１０２の処理において、定数が真偽値“Ｎ”であった場合には、コンテンツ取得部１０２１は、外部入力（コマンド入力CMD、コンテンツファイル名CF1、トラック番号TN1、コンテンツ再生開始時刻CTS1の４つの変数の組）があるかどうか判定し（ステップＳ１０３）、外部入力がある場合に真偽値“Ｙ”となりステップＳ１０４の処理へ移行し、外部入力がない場合に真偽値“Ｎ”となりステップＳ１０６の処理へ移行する。
【００４０】
ステップＳ１０３の処理において、自動モード定数が真偽値“Ｙ”であった場合には、コンテンツ取得部１０２１は、外部入力のうちコマンド入力CMD＝再生停止定数であるかを判定し（ステップＳ１０４）、コマンド入力CMD＝再生停止定数である場合は真偽値“Ｙ”となり、全体の動作を停止終了し、それ以外の場合は真偽値“Ｎ”となり、ステップＳ１０５の処理へ移行する。
【００４１】
ステップＳ１０４の処理において、真偽値“Ｎ”であった場合には、コンテンツ取得部１０２１は、外部入力（コンテンツファイル名CF1、トラック番号TN1、コンテンツ再生開始時刻CTS1）の３変数を用いて、まず５つの変数の初期化を行う（ステップＳ１０５）。
【００４２】
１：コンテンツファイル名CF＝コンテンツファイル名CF1
２：トラック番号TN＝トラック番号TN1
３：再生開始時刻STS＝システムクロック発振部１０２３から得た現在時刻NTS
４：コンテンツ再生時刻CTS＝コンテンツ再生開始時刻CTS1
５：再生状態フラグF＝真偽値“Ｙ”
続いてコンテンツ取得部１０２１は、コンテンツ再生時刻CTSを用いた開始フレーム番号FNの初期化を行い、前段階として送出開始時刻情報StartTSを算出する。送出開始時刻情報StartTSの算出式を以下に示す。
【００４３】
＜数２＞
StartTS＝CTS×TRS
ここでトラックタイムスタンプ周波数TRSは、コンテンツファイル名CFの中のトラック番号TNが指し示すトラックのトラックタイムスタンプ周波数である。
【００４４】
次に、コンテンツ取得部１０２１は、コンテンツファイル名CFの中のトラック番号TNが指し示すトラックのフレーム番号を１から順にサーチし、時刻情報≧StartTSが成り立つ地点のフレーム番号NFNを得て、フレーム番号NFNを開始フレーム番号FNに設定する。以上がステップＳ１０５の概要である。
【００４５】
また、ステップＳ１０３の処理において、自動モード定数が真偽値“Ｎ”であった場合には、コンテンツ取得部１０２１は、再生状態フラグの値が真偽値“Ｙ”であるかどうか判定し（ステップＳ１０６）、値が真偽値“Ｙ”である場合ステップＳ１０７の処理へ移行し、真偽値“Ｎ”である場合にはＳ１０３の処理へ移行する。
【００４６】
ステップＳ１０６の処理において再生状態フラグの値が真偽値“Ｙ”であった場合、またはステップＳ１０５から継続する処理の場合には、コンテンツ取得部１０２１は、システムクロック発振部１０２３から得た現在時刻NTSと再生開始時刻STSとシステムクロック周波数SSから経過時間を算出し、経過時間とコンテンツ再生時刻CTSとトラックタイムスタンプ周波数TRSから、送出可能時刻情報LastTSを算出することによって、送信可能範囲を検索する（ステップＳ１０７）。送出可能時刻情報LastTSの算出式を以下に示す。
【００４７】
＜数３＞
LastTS＝（NTS−STS）／SS×TRS
ここでシステムクロック周波数SSとは、（現在時刻NTS−再生開始時刻STS）を秒単位に変換するための定数である。例えばシステムクロックが1/1000000秒の精度を持っているとすると1000000である。
【００４８】
次に、コンテンツ取得部１０２１は、コンテンツファイル名CFの中のトラック番号TNが指し示すトラック内の、開始フレーム番号FNからフレーム番号を順にサーチし、時刻情報≧LastTSが成り立つ点のフレーム番号NFNを取得する。条件を満たすフレーム番号NFNが求まらない場合は、コンテンツ取得部１０２１は、フレーム番号NFNに終端定数“−1”を設定する。
【００４９】
次に、コンテンツ取得部１０２１は、開始フレーム番号FNとフレーム番号NFNを比較することによって送信の可否を判定し（ステップＳ１０８）、FN＜NFNが成立する場合には真偽値“Ｙ”となりステップＳ１０９の処理へ移行し、成立しない場合は真偽値“Ｎ”となりステップＳ１０３の処理へ移行する。
【００５０】
ステップＳ１０８の処理において真偽値“Ｙ”であった場合には、コンテンツ取得部１０２１は、  コンテンツファイル名CFの中のトラック番号TNが指し示すトラック内の、開始フレーム番号FNからフレーム番号NFN未満の各フレーム番号に対応するコンテンツ素片それぞれと、それぞれのコンテンツ素片について、対応する時刻情報から下記の算出式に従って生成されたネットワークタイムスタンプPTSを、送信部１０２２へ出力する（ステップＳ１０９）。
【００５１】
＜数４＞
PTS＝時刻情報／TRS×ネットワークタイムスタンプ周波数
出力後、送信済みの位置まで開始フレーム番号FNをずらすため、コンテンツ取得部１０２１は、開始フレーム番号FN＝フレーム番号NFNと設定する。
【００５２】
また、ステップＳ１０２の処理において、自動モード定数が真偽値“Ｙ”であった場合には、コンテンツ取得部１０２１は、再生状態フラグF＝真偽値“Ｙ”と設定し、再生開始時刻STS＝システムクロック発振部１０２３から得た現在時刻NTSを設定し、自動再生開始のための設定を行う（ステップＳ１１０）。以上がコンテンツ取得部１０２１の再生時刻管理処理（送信側）についての概要である。
【００５３】
次に、ネットワークタイムスタンプを用いたコンテンツ読取部１０３４の再生時刻管理処理（受信側）について、図１１のフローチャートを用いて説明する。
【００５４】
コンテンツ読取部１０３４は、コンテンツの再生を開始すると、バッファ部１０３２に一定量コンテンツ素片が蓄積されるまで蓄積量を監視し（ステップＳ１２１）、予め定められた蓄積量のしきい値を超えると、真偽値“Ｙ”となりステップＳ１２２の処理へ移行する。この蓄積量のしきい値は、単純に総バッファ量の半分（Half Full）でも良いし、予めコンテンツのビットレートが既知である場合は適切な計算して、バッファ部１０３２がバッファアンダーフローを起こさないように決定しても良い。
【００５５】
次に、コンテンツ読取部１０３４は、システムクロック発振部１０３３を参照し、再生開始時刻STS＝システムクロック発振部１０２３から得た現在時刻NTSを設定し、読み出し開始のための設定を行う（ステップＳ１２２）。また、コンテンツ読取部１０３４は、タイムアウト変数TOUT＝タイムアウト定数（例えば“10”）に設定する。
【００５６】
次に、コンテンツ読取部１０３４は、システムクロック発振部１０３３を参照して再度現在時刻NTSを更新した上で、下記の算出式に従って読み出すべきネットワークタイムスタンプPTSを算出する（ステップＳ１２３）。
【００５７】
＜数５＞
PTS＝（NTS−STS）／SS×ネットワークタイムスタンプ周波数
次に、コンテンツ読取部１０３４は、ネットワークタイムスタンプPTSに基づいてバッファ部１０３２を検索し、ネットワークタイムスタンプPTSと同じかより小さいネットワークタイムスタンプPTSと関連付けられたコンテンツ素片を取り出す（ステップＳ１２４）。コンテンツ素片が１つも見つからない場合は真偽値“Ｎ”となり、コンテンツ読取部１０３４は、ステップＳ１２５の処理へ移行し、コンテンツ素片が見つかった場合は真偽値“Ｙ”となり、タイムアウト変数TOUTにタイムアウト定数（例えば“10”）をセットして、ステップＳ１２６の処理へ移行する。
【００５８】
ステップＳ１２４で真偽値“Ｎ”であった場合には、コンテンツ読取部１０３４は、一定時間（例えば0.5秒程度）待機した後、タイムアウト変数TOUTを“1”だけ減算し、タイムアウトが発生したか判定する（ステップＳ１２５）。減算したTOUTが0未満になった場合は真偽値“Ｙ”となり、コンテンツ読取部１０３４は、処理を終了し、真偽値“Ｎ”となれば、ステップＳ１２３の処理に移行する。結果的に、5秒（0.5×10）の間パケットが到達しなかった場合には、終了動作を行うことになる。
【００５９】
また、ステップＳ１２４で真偽値“Ｙ”であった場合には、コンテンツ読取部１０３４は、ステップＳ１２４の処理で取り出されたコンテンツ素片を再生部１０３５へ出力する（ステップＳ１２６）。この際、コンテンツ素片を、再生部１０３５の希望に沿うように、適当な手段で並べ替えたり、コンテンツ素片同士を併合したりしても良い。例えば、RTPヘッダ内のシーケンス番号を用いて並べ替えた後に、同一のネットワークタイムスタンプ（RTPタイムスタンプ）を持つコンテンツ素片同士を結合しても良い。
【００６０】
なお、説明の便を考えて、受信パケットに付与されるネットワークタイムスタンプは常に0から始まることを仮定していたが、後述するRTSP等の、他の通信手順によって、予め送信開始時点のネットワークタイムスタンプ初期値OFSが既知である場合は、数５は、数６に変形できる。
【００６１】
＜数６＞
PTS＝（NTS−STS）／SS×ネットワークタイムスタンプ周波数＋OFS
以上がネットワークタイムスタンプを用いた、コンテンツ読取部１０３４の再生時刻管理処理（受信側）の概要である。
【００６２】
次に、ストリーミングシステムにおける伝送制御機構について説明する。
【００６３】
ストリーミングシステムにおいては、利用者の入力処理から任意のコンテンツを選択・再生・停止等の操作を受け付け、操作に応じてTCP／UDP等のセッションを動的に接続・切断する必要がある。これを伝送制御機構と呼ぶ。図１２に、伝送制御機構を備えるコンテンツ配信システム１０１ｂを構成するコンテンツ配信サーバ１０２ｂとコンテンツ受信装置１０３ｂの機能ブロック図を示す。コンテンツ配信サーバ１０２ｂとコンテンツ受信装置１０３ｂは、IPネットワーク１０４によって相互に接続される。
【００６４】
コンテンツ配信サーバ１０２ｂは、コンテンツ取得部１０２１、送信部１０２２、システムクロック発振部１０２３、コンテンツ記憶部１０２４、および伝送制御部１０２５を有し、また、コンテンツ受信装置１０３ｂは、受信部１０３１、バッファ部１０３２、システムクロック発振部１０３３、コンテンツ読取部１０３４、再生部１０３５、伝送制御部１０３６、および入力部１０３７を有する。なお、図８と同じものについては同じ番号を付し、その説明は省略する。
【００６５】
コンテンツ配信サーバ１０２ｂの伝送制御部１０２５は、コンテンツ受信装置１０３ｂからのコンテンツの選択、コンテンツの再生・停止等の指示を含む伝送制御情報を受信すると、この伝送制御情報を、コンテンツ取得部１０２１と、送信部１０２２に通知する機能を有する。また、伝送制御部１０２５は、コンテンツ記憶部１０２４を参照してコンテンツファイル名、トラック番号、コンテンツ再生開始時刻を取得し、それらをコンテンツ取得部１０２１に対して入力し、送信部１０２２に対して送信アドレスを入力する機能を有する。
【００６６】
適用するプロトコルとしては、RFC2326に規定されているRTSP（Real Time Streaming Protocol）に代表される実時間データ伝送制御用プロトコルを想定しており、Setup、Play、 Pause、Teardown、Describe等のメソッドを利用できる（H.Schulzrinne etal, "Real Time Streaming Protocol", RFC2326, Internet Engineering Taskforce, Apr 1998）。
【００６７】
また、コンテンツ受信装置１０３ｂの伝送制御部１０３６は、入力部１０３７からの伝送制御情報をコンテンツ配信サーバ１０２ｂの伝送制御部１０２５へ送信、その応答を受信し、応答を解析した後、受信アドレスを取り出し、受信部１０３１へ入力する機能を有する。
【００６８】
また、コンテンツ受信装置１０３ｂの入力部１０３７は、利用者から、コンテンツの選択・コンテンツの再生・停止等の伝送制御情報の入力処理を受け付ける機能を有する。例えば、ビットマップディスプレイとキーボードを用いて、再生ボタン、停止ボタン、コンテンツ選択ダイヤログなどのＧＵＩ部品を利用者に提供する。
【００６９】
次に、伝送制御情報の送受信時における伝送制御部１０２５および伝送制御部１０３６の動作について、図１３のシーケンス図を用いて説明する。図１３は、RTSPを用いて１つのコンテンツを選択し、伝送のためのセッションを確立し、再生を開始し、停止するまでに行われる処理である。なお、ここでは、コンテンツ配信サーバ１０２ｂのホスト名を“server.jvc-victor.jp”とし、コンテンツを蓄積しているコンテンツファイル名を“hoge.mp4”とし、“hoge.mp4”内部には１つのMPEG-4 AAC音声トラックが存在し、トラック番号は１であるとし、再生時間は235秒であるとする。
【００７０】
RTSPは、コンテンツをネットワーク上で一意に特定するための資源識別子として、コンテンツURI（Uniform Resource Identifier）を適用する（T. Berners-Lee, "Uniform Resource Identifiers （URI）: Generic Syntax", RFC2396, Internet Engineering Taskforce, Aug 1998）。コンテンツ“hoge.mp4”は以下のようなコンテンツURIによって表される。
【００７１】
“rtsp://server.jvc-victor.jp/hoge.mp4”
まず、伝送制御部１０３６は、コンテンツURIを用いて、セッション記述を要求する（ステップＳ１３１）。このセッション記述とは、コンテンツURIに関連付けられたコンテンツデータに対して、どのようなセッション（通信路）が確立できるかを示したテキストデータである。セッション記述形式としては、SDP（Session Description Protocol）が適用される（M. Handley, " SDP: Session Description Protocol ", RFC2327, Internet Engineering Taskforce, April 1998）。RTSPにおいてセッション記述の要求にはDESCRIBEメソッドを使用する。なお、各メソッドおよびその応答メッセージ（その他付随する情報も含めて）は、それぞれリクエストメッセージのヘッダおよびレスポンスメッセージのヘッダに挿入されて送受信される。
【００７２】
“DESCRIBE rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
伝送制御部１０２５は、セッション記述を含んだ応答を送信する（ステップＳ１３２）。セッション記述には、再生時間と、メディア記述が含まれる。この再生時間とは、指定したコンテンツURIに関連付けられた連続メディアの最大の再生時間である。再生時間のフォーマットは多種類あるが、最も簡単なフォーマットは、開始時間と終了時間を、浮動小数点を用いた秒数で表したNPT（Normal Play Time, ISO8601）である。例えば、235秒分のMPEG-4 AAC音声トラックを含んだコンテンツファイルを指し示すコンテンツURIの再生時間を、NPTを用いて表すと以下のようになる。
【００７３】
“a=range:npt=0.0-235.0”
また、メディア記述には、セッションを確立するための事前情報として、コンテンツ種別やネットワークタイムスタンプ周波数などの情報を含む。
【００７４】
“m=audio 0 RTP/AVP/UDP 96”
“a=rtpmap:96 mpeg4-generic/48000/2”
“a=control:rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1”
“a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1190; SizeLength=13; IndexLength=3; IndexDeltaLength=3; Profile=1;”
上記のメディア記述は、MPEG-4 AAC Hi-bitrate符号化方式で符号化された48000Hz（48KHz）PCMサンプル周波数のステレオ音声が含まれていることを表現している。また、セッションを確立する際には、UDPを下位ネットワークプロトコルとし、RTPを適用して伝送しなければならないことが示されている。
【００７５】
また、このセッションの準備要求には以下のコントロールURIを使うことが示されている。コントロールURIは、1つのコンテンツデータ内の複数トラックを識別するためにトラック番号（trackID=1）が付与されている。
【００７６】
“rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1”
セッション記述を解析した伝送制御部１０３６は、MPEG-4 AACステレオ音声を伝送するためのセッションを確立することを決定し、セッションの受信アドレスを決定し、セッション確立準備要求を伝送制御部１０２５へ送信する（ステップＳ１３３）。RTSPにおけるセッション確立準備要求にはSETUPメソッドを用いる。下記の例では、受信アドレスは、伝送制御部１０３６の持つ受信アドレス（136.198.190.100）と受信ポート番号（6668-6669）となっている。
【００７７】
“SETUP rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1 RTSP/1.0”
“Transport: RTP/AVP/UDP;unicast;destination=136.198.190.100;client_port
=6668-6669”
セッション確立準備要求を正しく受信した伝送制御部１０２５は、新たに送信アドレスを決定し、送信アドレスを送信部１０２２へ入力し、あわせて、セッション情報を伝送制御部１０３６へ送信する（ステップＳ１３４）。セッション情報には、配信に用いる配信サーバの送信アドレス（例では136.198.190.1）や送信ポート番号（下記の例では19000〜19001）が含まれる。
【００７８】
“Transport: RTP/AVP/UDP;unicast;source=136.198.190.1;server_port=19000
-19001”
また、伝送制御部１０３６では、セッション情報を受け付けた時点で、先に決定しておいた受信アドレスを受信部１０３１へ入力する。送信部１０２２と受信部１０３１双方の処理が完了した時点で、新たなセッションが確立される。
【００７９】
次に、伝送制御部１０３６は、再生開始要求を送信する（ステップＳ１３５）。再生開始要求では、再生範囲を、NPTを用いて指定することができる。下記の例では、コンテンツの最初（0.0秒）から最後（235.0秒）までの指定している。RTSPにおいて再生開始要求にはPLAYメソッドを用いる。
【００８０】
“PLAY rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
“Range: npt=0.0-235.0”
伝送制御部１０２５は、再生開始要求の応答を送信する（ステップＳ１３６）。再生開始要求を受け付けた伝送制御部１０２５は、既に準備の済んでいる全てのセッション対して、各セッションのコントロールURIと再生開始要求に含まれる再生範囲から、コンテンツファイル名・トラック番号・コンテンツ再生開始時刻を算出し、コマンド入力＝再生開始定数（例えば“PLAY”）と合わせて、コンテンツ取得部１０２１に入力し、RTPパケットの送信を開始する。
【００８１】
また、この応答は、コンテンツ受信装置１０３ｂのコンテンツ読取部１０３４の動作に必要となるRTPパケット情報を含む。例えば、このセッションにおいて、最初に送られてくるRTPパケットのRTPタイムスタンプ（ネットワークタイムスタンプ）などが含まれる（下記の例では0000000）。
【００８２】
“RTP-Info: url= rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1;rtptime
=0000000;”
伝送制御部１０３６は、利用者が停止入力を行った時点で停止要求を送信する（ステップＳ１３７）。RTSPにおいて停止要求はTEARDOWNメソッドである。
【００８３】
“TEARDOWN rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
停止要求を受け付けた伝送制御部１０２５は、送信部１０２２を制御し、RTPパケットの送信を停止、セッションを切断し、送信を停止したことを通知する（ステップＳ１３８）。また、伝送制御部１０２５は、コンテンツ取得部１０２１に対して、コマンド入力＝再生停止定数（例えば“STOP”）を入力し、読み出しを停止する。
【００８４】
なお、説明の簡単化のために、１つのコンテンツデータに1つのコンテンツのみが含まれると仮定していたが、前記の伝送制御機構は容易に複数のコンテンツの同期再生に拡張可能である。例えば、ステップＳ１３２において、複数のコンテンツに関するメディア記述を列挙し、ステップＳ１３３〜ステップＳ１３４の準備要求をメディア記述分繰り返すだけで、複数のコンテンツの同期再生が容易に行うことが可能である。以上がストリーミングシステムにおける伝送制御機構の概要である。
【００８５】
ここで、コンテンツ再生中に、動的に、滑らかに音声や映像の切替を行おうとした場合、非同期モデルを採用したストリーミングシステムと、動的なセッション生成を伴う伝送制御機構を備えたストリーミングシステムとでは、２つ以上のコンテンツを再生途中から滑らかにビットストリーム切り替えの動作を行うことはできない。
【００８６】
例えば、235秒分の再生時間を持つ２つのコンテンツ（トラック番号１および２とする）のうち、トラック番号１のコンテンツを再生しており、利用者がちょうど100秒目でトラック番号２のコンテンツへ切り替える指示を入力部１０３７へ入力したとする。
【００８７】
コンテンツ受信装置１０３ｂは、非同期モデルを採用しているから、利用者から見た100秒目とは、コンテンツ読取部１０３４内部で計算されている時刻差分（現在時刻NTS−再生開始時刻STS）であり、既にバッファ部１０３２には、コンテンツ配信サーバ１０２ｂから送信済みの100秒目以降のコンテンツ素片が、既に蓄積されているか、その一部がIPネットワーク１０４上のルーターやスイッチングハブに滞留していると考えられる。
【００８８】
この状況において、トラック番号１のセッションを切断し（ステップＳ１３７）、トラック番号２のコンテンツに対してステップＳ１３３〜ステップＳ１３５の一連の通信手順を行うことを考えた場合、ステップＳ１３５における再生範囲は以下のような指定せざるを得ない。
【００８９】
“PLAY rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
“Range: npt=100.0-235.0”
ステップＳ１３６の処理直後における、バッファ部１０３２に蓄積されているコンテンツ素片の順列を、図１４に示す。再生時刻100秒のコンテンツの時刻情報をT1とし、時系列順にT2,T3,T4とする。図１４では、トラック番号１のコンテンツはコンテンツ素片４まで蓄積され、続いてトラック番号２のコンテンツがコンテンツ素片１から蓄積されていることが示されている。このコンテンツ素片の順列で利用者が視聴した場合、コンテンツはT4からT1へ戻るため、一瞬巻き戻ったように感じ、滑らかには切り替わらず、激しい違和感が生じることになる。
【００９０】
また、トラック番号１のセッションをステップＳ１３７の処理で切断した時点からトラック番号２のセッション確立準備の要求を受信するまでにかかった時間が、既にバッファ部１０３２に蓄積されているパケットの総再生時間よりも長いとバッファアンダーフローを起こし、コンテンツ読取部１０３４のタイムアウト変数TOUTが満了すれば、再生が停止することになる。 
同様に、トラック番号１のセッションをステップＳ１３７の処理で切断し、トラック番号２のコンテンツに対してステップＳ１３３〜ステップＳ１３５までの一連の通信手順にかかる時間を計測し、ステップＳ１３５の処理におけるトラック番号２のNPTに補正をかけることで違和感を少なくする手法が考えられる。例えば、一連の通信手順に5.5秒かかったとしたら、npt=105.5-235.0に補正する。
【００９１】
しかし、この手法を適用してもトラック番号２の再生開始要求がコンテンツ配信サーバ１０２ｂへ到達して実際にパケット送信が開始されるまでの時間遅延を考慮することができず、バッファ内部の全てのパケットについてコンテンツ再生時刻が完全に連続するように構成することは困難である。
【００９２】
上記の問題に対処する第１の改善方法として、特開２００２−１１８５９２（特許文献１）が開示されている。
【００９３】
これは配信サーバと、クライアント間に、二次配信サーバを設け、二次配信サーバが切り替え後のビットストリームをある程度バッファリングしてから切り替えることで、クライアントのバッファ部が空にならず、コンテンツを途切れなく切り替えることができるというものである。
【００９４】
しかし、特許文献１では、複数の配信サーバから配信されるビットストリームの各々は互いに時間的に独立であって、フレーム境界が同期していない。つまり、バッファアンダーフローは防げるが、コンテンツの巻き戻り感に関しては無力であり、コンテンツ再生時刻を完全に連続するように構成することは困難である。
【００９５】
上記の問題に対処する第２の改善方法として、多くのストリーミングシステムでは、複数トラック同時受信構成を採用している。一例として、２トラック同時受信可能なコンテンツ配信システム１０１ｃを構成するコンテンツ配信サーバ１０２ｃとコンテンツ受信装置１０３ｃの機能ブロック図を、図１５に示す。
【００９６】
コンテンツ配信サーバ１０２ｃは、コンテンツ取得部１０２１Ａ、送信部１０２２Ａ、コンテンツ取得部１０２１Ｂ、送信部１０２２Ｂ、システムクロック発振部１０２３、およびコンテンツ記憶部１０２４を有する。また、コンテンツ受信装置１０３ｃは、受信部１０３１Ａ、バッファ部１０３２Ａ、コンテンツ読取部１０３４Ａ、受信部１０３１Ｂ、バッファ部１０３２Ｂ、コンテンツ読取部１０３４Ｂ、システムクロック発振部１０３３、再生部１０３５、伝送制御部１０３６、入力部１０３７、および切替部１０３８を有する。なお、図１２と同じものについては同じ番号を付し、その説明は省略する。
【００９７】
切替部１０３８は、トラック切替入力に従って、２つのコンテンツ素片のうち、どちらか一方を採用して再生部１０３５へ入力する機能を有する。採用しなかった方のコンテンツ素片は、読み出しはするものの、そのまま破棄される。
【００９８】
なお、入力部１０３７は、利用者が入力するトラック番号１または２を切り替えるためのトラック切替入力を受け付けるものとする。
【００９９】
コンテンツ受信装置１０３ｃでは、複数の同期するトラックがあった場合、ステップＳ１３３〜ステップＳ１３４に相当する一連の準備要求・返答をトラック数分繰り返してから、ステップＳ１３５に相当する再生要求を開始し、全てのトラック分のストリームを受信し、受信側で複数のトラックのうち、１つを再生するような切替部１０３８をコンテンツ受信装置１０３ｃに備えることで対処している。
【０１００】
図１６は、複数トラック同時受信構成を有するコンテンツ受信装置１０３ｃの動作を示したフローチャートである。ステップＳ１４１の処理以外、全ての処理（ステップＳ１４２〜ステップＳ１４６）は、図１１のステップＳ１２２〜ステップＳ１２６と同一なので、その説明を省略する。
【０１０１】
複数のトラックが互いに同期するためには、バッファ部の蓄積量の多少の差異（到着する再生コンテンツ素片の時間揺らぎ）に依存せず、一斉に再生開始する必要がある。そこで、再生を選択されているトラックのコンテンツを受信する側のコンテンツ読取部１０３４（ＡまたはＢ）は、コンテンツ受信装置１０３ｃ内全てのバッファ部１０３２（ＡおよびＢ）を監視し、一定量蓄積されるまで待機し、バッファ部のいずれか一つが予め定められた蓄積量のしきい値を超えると、真偽値“Ｙ”を生成し、次の処理へ移行する（ステップＳ１４１）。これは言い換えれば、複数のトラック間における再生開始時刻STSが全く同一となることを意図している。
【０１０２】
従来は、このようにしてコンテンツを配信していたが、以下に示す問題点を抱えていた。
【０１０３】
まず、特許文献１の二次配信サーバは、複数の配信サーバから送信された複数のコンテンツを伝送するビットストリームを切り替え、クライアントに提供することができるが、各配信サーバが共有する同期クロックを有することなく、同一時刻に同一のネットワークタイムスタンプを付与したパケットによって構成されるビットストリームを送信するのではないため、コンテンツ内のコンテンツ再生時刻の増分を完全に一致させ、滑らかに切り替えることができない。
【０１０４】
また、複数トラック同時受信構成のコンテンツ配信システム１０１では次のような問題点を抱えていた。
【０１０５】
図１２と図１５のコンテンツ配信システム１０１ｂおよび１０１ｃにおいては、各トラックのビットレートの総和を越えるネットワークスループットが必要である。例えば、128KbpsのMPEG-4 AAC音声トラックが20本存在した場合、必要なネットワークスループットは20倍の2.5Mbpsとなる。特に、無線網を利用した比較的低速の通信回線を利用する場合は、スループットが足りずにサービス不能に陥る可能性がある。
【０１０６】
特に図１５のコンテンツ受信装置１０３ｃにおいては、トラック数分のバッファ部（図１５中、１０３２Ａおよび１０３２Ｂ）を備える必要がある。また、コンテンツ受信装置１０３ｃは、非同期モデルを採用しているため、異なるビットストリームを同時に受信し、管理するためには、バッファ部の記憶容量を増やす必要がある。特に、携帯電話やＰＤＡ（Personal Digital Assistant＝携帯情報端末）など、メモリ搭載量に制限のある機器をコンテンツ受信装置として用いる場合は搭載できない可能性がある。
【特許文献１】特開２００２−１１８５９２号公報
【発明の開示】
【発明が解決しようとする課題】
【０１０７】
本発明は、上記事情に鑑みてなされたものであり、ネットワークを介して、複数トラックから構成されるコンテンツデータを送信するコンテンツ配信サーバと当該コンテンツデータを受信再生するコンテンツ受信装置からなるコンテンツ配信システムにおいて、トラックを動的に切り替えて送信し、切り替えられた箇所を滑らかに再生することを可能にするコンテンツ配信方法、およびコンテンツ配信方法を用いたコンテンツ配信サーバ、およびコンテンツ受信装置に関する。
【課題を解決するための手段】
【０１０８】
上記目的を達成するために、請求項１に記載のコンテンツ配信方法は、複数のコンテンツ素片データを有するコンテンツデータを記憶しているコンテンツ配信サーバと、このコンテンツ配信サーバに対して、ネットワークを介してコンテンツの再生要求を行い、その再生要求に応じてコンテンツ配信サーバからネットワークを介して送信されるコンテンツ素片データを受信し再生するコンテンツ受信装置とを備えたコンテンツ配信システムにおけるコンテンツ配信方法であって、コンテンツ配信サーバに記憶されているコンテンツデータは、ファイル名と複数のトラックとを有するコンテンツデータであり、前記各トラックのトラックデータは、トラック番号と複数のデータフレームとを有し、前記各データフレームは、フレーム番号、再生のタイミングを示す時刻情報、およびコンテンツ素片データを有するものであり、同一の前記フレーム番号における各トラックの前記データフレームが、同一の前記時刻情報を有するものであり、前記コンテンツ受信装置から前記コンテンツ配信サーバへ再生を要求する前記コンテンツデータの前記ファイル名を送信し、これに応じて前記コンテンツ配信サーバから送信される少なくとも予め設定されている前記トラック番号、および前記ファイル名のコンテンツデータにおける前記予め設定されているトラック番号のトラックの再生時間長を示す再生時間情報を前記コンテンツ受信装置が受信し、前記コンテンツ受信装置が所望の前記トラック番号を指定して前記コンテンツ配信サーバへ送信することにより、前記コンテンツ受信装置−前記コンテンツ配信サーバ間のセッションを確立するセッション確立工程と、前記セッションの確立後、コンテンツの再生開始要求を行う際に、前記コンテンツ受信装置において、当該再生を要求する前記コンテンツデータの前記ファイル名、および再生する時間範囲を示す再生範囲情報を含むコンテンツの再生開始要求メッセージを、前記コンテンツ受信装置から前記コンテンツ配信サーバに送信する工程と、前記コンテンツ配信サーバにおいて、前記再生開始要求メッセージを受信した場合に、当該再生開始要求メッセージ内の前記再生範囲情報に従って、送信すべき前記コンテンツ素片データを含む前記データフレームの前記フレーム番号を特定し、この特定された前記フレーム番号、当該再生開始要求メッセージ内の前記ファイル名、および前記セッション確立時に前記コンテンツ受信装置が指定した前記トラック番号によって指定される、再生要求された前記コンテンツ素片データを前記記憶されているコンテンツデータから取得し、前記コンテンツ受信装置に送信する工程と、前記セッションの確立後、再生対象トラックの切替要求を行う際に、前記コンテンツ受信装置において、再生トラック切替のための切替先トラック番号を含む切替要求メッセージを前記コンテンツ受信装置から前記コンテンツ配信サーバに送信する工程と、前記コンテンツ配信サーバにおいて、前記再生開始要求メッセージ受信後に前記切替要求メッセージを受信した場合に、当該切替要求メッセージを受信した時点での既送の前記コンテンツ素片データのうち再生順序が最後となっている前記コンテンツ素片データを含む前記データフレームにおける前記時刻情報に基づき、この再生順序が最後となっている前記コンテンツ素片データに連続して再生されるべき前記コンテンツ素片データを含む前記データフレームの前記フレーム番号を特定し、この特定された前記フレーム番号、および当該切替要求メッセージ内の前記切替先トラック番号によって指定される前記コンテンツ素片データを、前記記憶されているコンテンツデータから取得し、コンテンツ受信装置に送信する工程とを有することを特徴とする。
【０１０９】
本発明において“コンテンツ素片データ”とは、コンテンツを任意のデータ長で分割したデータブロックのことを指す。
【０１１０】
また、請求項２に記載のコンテンツ配信サーバは、コンテンツ受信装置からの再生要求に従って、複数のコンテンツ素片データを有するコンテンツデータから再生要求されたコンテンツ素片データを選択し、選択したコンテンツ素片データをネットワークを介して前記コンテンツ受信装置へ送信するコンテンツ配信サーバであって、ファイル名と複数のトラックとを有するコンテンツデータであり、前記各トラックのトラックデータは、トラック番号と複数のデータフレームとを有し、前記各データフレームは、フレーム番号、再生のタイミングを示す時刻情報、およびコンテンツ素片データを有するものであり、同一の前記フレーム番号における各トラックの前記データフレームが、同一の前記時刻情報を有するコンテンツデータを記憶するコンテンツ記憶手段と、前記コンテンツ受信装置から再生を要求する前記コンテンツデータの前記ファイル名を受信し、これに応じて少なくとも予め設定されている前記トラック番号、および前記ファイル名のコンテンツデータにおける前記予め設定されているトラック番号のトラックの再生時間長を示す再生時間情報を当該コンテンツ受信装置へ送信し、その後、前記コンテンツ受信装置によって指定された所望の前記トラック番号を受信することにより、前記コンテンツ受信装置との間のセッションを確立し、前記セッションの確立後、前記コンテンツ受信装置においてコンテンツの再生開始要求がなされた際に、前記コンテンツ受信装置から、再生を要求する前記コンテンツデータの前記ファイル名、および再生する時間範囲を示す再生範囲情報を含むコンテンツの再生開始要求メッセージを受信し、前記セッションの確立後、前記コンテンツ受信装置において再生対象トラックの切替要求がなされた際に、前記コンテンツ受信装置から、再生トラック切替のための切替先トラック番号を含む切替要求メッセージを受信するための伝送制御手段と、前記伝送制御手段が前記再生開始要求メッセージを受信した場合に、当該再生開始要求メッセージ内の前記再生範囲情報に従って、送信すべき前記コンテンツ素片データを含む前記データフレームの前記フレーム番号を特定し、この特定された前記フレーム番号、当該再生開始要求メッセージ内の前記ファイル名、および前記セッション確立時に前記コンテンツ受信装置が指定した前記トラック番号によって指定される、再生要求された前記コンテンツの前記コンテンツ素片データを前記コンテンツ記憶手段から取得し、前記伝送制御手段が前記再生開始要求メッセージ受信後に前記切替要求メッセージを受信した場合に、当該切替要求メッセージを受信した時点での既送の前記コンテンツ素片データのうち再生順序が最後となっている前記コンテンツ素片データを含む前記データフレームにおける前記時刻情報に基づき、この再生順序が最後となっている前記コンテンツ素片データに連続して再生されるべき前記コンテンツ素片データを含む前記データフレームの前記フレーム番号を特定し、この特定された前記フレーム番号、および当該切替要求メッセージ内の前記切替先トラック番号によって指定される前記コンテンツ素片データを、前記コンテンツ記憶手段から取得するコンテンツ取得手段と、前記コンテンツ取得手段が取得した前記コンテンツ素片データを前記コンテンツ受信装置へ送信する送信手段とを備えることを特徴とする。
【０１１１】
また、請求項３に記載のコンテンツ受信装置は、複数のコンテンツ素片データを有するコンテンツデータを記憶しているコンテンツ配信サーバに対して、ネットワークを介してコンテンツの再生要求を行い、その再生要求に応じてコンテンツ配信サーバからネットワークを介して送信されるコンテンツ素片データを受信し再生するコンテンツ受信装置であって、前記コンテンツ配信サーバに記憶されているコンテンツデータは、ファイル名と複数のトラックとを有するコンテンツデータであり、前記各トラックのトラックデータは、トラック番号と複数のデータフレームとを有し、前記各データフレームは、フレーム番号、再生のタイミングを示す時刻情報、およびコンテンツ素片データを有するものであり、同一の前記フレーム番号における各トラックの前記データフレームが、同一の前記時刻情報を有するものであり、再生を要求する前記コンテンツデータの前記ファイル名を送信し、これに応じて前記コンテンツ配信サーバから送信される少なくとも予め設定されている前記トラック番号、および前記ファイル名のコンテンツデータにおける前記予め設定されているトラック番号のトラックの再生時間長を示す再生時間情報を受信し、その後、所望の前記トラック番号を指定して前記コンテンツ配信サーバへ送信することにより、前記コンテンツ配信サーバとの間のセッションを確立し、前記セッションの確立後、コンテンツの再生開始要求を行う際に、再生を要求する前記コンテンツデータの前記ファイル名、および再生する時間範囲を示す再生範囲情報を含むコンテンツの再生開始要求メッセージを前記コンテンツ配信サーバに送信し、前記セッションの確立後、再生対象トラックの切替要求を行う際に、再生トラック切替のための切替先トラック番号を含む切替要求メッセージをコンテンツ配信サーバに送信する伝送制御手段を備えることを特徴とする。
【発明の効果】
【０１１２】
本発明によれば、コンテンツ配信サーバ側で、トラック切替個所におけるデータフレームの再生時間情報の整合を図ってデータフレームを取得送信するので、コンテンツ受信装置では、トラック切替箇所を滑らかに再生することが可能となる。特に、各トラックのコンテンツデータ同士が時間的な推移の関連性の高いコンテンツデータである場合に（例えば同じ楽曲を日本語で歌ったデータと英語で歌ったデータとである場合に）、トラック切替箇所を非常に滑らかに再生することが可能となる。
【０１１３】
また、冗長なデータフレームをコンテンツ受信装置へ送信する必要が無いので、コンテンツ受信装置側で多量のデータフレームを蓄積するバッファメモリを必要とせず、コンテンツ受信装置の製造コストを低減することが可能となる。また、通信回線もデータフレーム送信用に１回線しか専有しないので、低スループットの通信回線でも良好なサービスを提供することが可能となる。
【発明を実施するための最良の形態】
【０１１４】
本発明の実施形態を、図１〜図７を用いて説明する。
【０１１５】
図１に、コンテンツ配信システム１ａ（非同期モデル）におけるコンテンツ配信サーバ２とコンテンツ受信装置３ａの機能ブロック図を示す。コンテンツ配信サーバ２とコンテンツ受信装置３ａは、IPネットワーク４によって相互に接続される。
【０１１６】
コンテンツ配信サーバ２は、コンテンツ取得部２１、伝送制御部２２、送信部２３、システムクロック発振部２４、およびコンテンツ記憶部２５を有する。
【０１１７】
コンテンツ取得部２１は、再生するコンテンツのコンテンツデータをコンテンツ記憶部２５に記録し、システムクロック信号に従って、伝送制御情報に基づいて任意のポインタ（コンテンツ上の読み出し位置）を用いてコンテンツ素片を取得する機能を有する。このポインタとは、コンテンツファイル名、トラック番号、フレーム番号の３つのうちいずれか、もしくはそれらのうちいくつかの組み合わせである。また、“コンテンツ素片”とは、任意のデータ長を有するデータブロックのことを指す。
【０１１８】
コンテンツ取得部２１は、内部にコンテンツファイル名、トラック番号、フレーム番号等の初期値を持ち、起動時から自動的に読み出しを開始しても良いし、外部入力からコンテンツファイル名、トラック番号、コンテンツ再生開始時刻を得てから読み出しを開始しても良い。また、コマンド入力を受け付ける外部入力を設け、コマンド入力＝再生開始定数（例えば“PLAY”）である場合は再生するようにしても良いし、コマンド入力＝再生停止定数（例えば“STOP”）である場合は停止するようにしても良い。あるいは自動読み出し開始動作と外部読み出し開始動作を自動的に判別するようにしても良い。
【０１１９】
伝送制御部２２は、コンテンツ受信装置３ｂからのコンテンツの選択、コンテンツの再生・停止、トラック切替要求等の指示を含む伝送制御情報を受信すると、この伝送制御情報を、コンテンツ取得部２１と、送信部２３に通知する機能を有する。また、伝送制御部２２は、コンテンツ記憶部２５を参照してコンテンツファイル名、トラック番号、コンテンツ再生開始時刻を取得し、それらをコンテンツ取得部２１に対して入力し、送信部２３に対して送信アドレスを入力する機能を有する。
【０１２０】
適用するプロトコルとしては、RFC2326に規定されているRTSPに代表される実時間データ伝送制御用プロトコルを想定しており、Setup、Play、 Pause、Teardown、Describe等のメソッドを利用できる。
【０１２１】
送信部２３は、セッションと呼ぶ仮想的な通信路を確保し、コンテンツ素片を適切なヘッダを付加してパケット化し、そのパケットを、IPネットワーク４を介してコンテンツ受信装置３ａへ送信する機能を有する。例えば、ヘッダにはネットワークタイムスタンプが含まれる。
【０１２２】
パケットを送信する際には、送信部２３は、コンテンツ受信装置３ａへパケットを届けるために送信アドレスを用いる。送信アドレスは、送信アドレスと送信ポート番号の組で構成される。送信アドレスは送信部２３内部の定数として予め持っていても良いし、他のブロックから入力を受け付けても良い。なお、パケットを送信するためのセッション（通信路）は送信アドレスが確定した時点で動的に確立するものとする。また、コンテンツ素片とパケットが必ずしも一致する必要はない。
【０１２３】
システムクロック発振部２４は、水晶発振子等で実現されたリアルタイムクロック（高精度の時計）であり、システムクロック信号をコンテンツ取得部２１へ供給する機能を有する。
【０１２４】
また、コンテンツ記憶部２５は、コンテンツデータを所定のファイル形式で記憶する機能を有する。
【０１２５】
また、コンテンツ受信装置３ａは、受信部３１、伝送制御部３２、バッファ部３３、システムクロック発振部３４、コンテンツ読取部３５、再生部３６、および入力部３７を有する。
【０１２６】
受信部３１は、IPネットワーク４からパケットを受信して、ヘッダを解釈して、コンテンツ素片を取り出し、バッファ部３３に供給する機能を有する。受信部３１は、コンテンツ配信サーバ２からのパケットのうち自己に必要なパケットのみを受信するために受信アドレスを用いる。受信アドレスは、受信アドレスと受信ポート番号の組で構成される。受信アドレスは受信部３１内部の定数として予め持っていても良いし、他のブロックから入力を受け付けても良い。
【０１２７】
伝送制御部３２は、入力部３７からの伝送制御情報をコンテンツ配信サーバ２の伝送制御部へ送信、その応答を受信し、応答を解析した後、受信アドレスを取り出し、受信部３１へ入力する機能を有する。
【０１２８】
バッファ部３３は、コンテンツ素片をヘッダから得られたネットワークタイムスタンプ（後述）と共に一次的に蓄積記憶する機能を有する。
【０１２９】
コンテンツ読取部３５は、バッファ部３３を監視し、再生に十分なコンテンツ素片が蓄積されたと判断した時点から、システムクロック発振部３４からのシステムクロック信号に従ってコンテンツ素片の読み出しを開始し、コンテンツ素片の集合をコンテンツに復元して出力する機能を有する。
【０１３０】
再生部３６は、入力されたコンテンツ素片に応じた復号化を行い、スピーカ等の所定の出力装置に対して音声信号、映像信号を出力する機能を有する。例えば、コンテンツ素片がMPEGに類する高能率符号化されたデジタル音声データである場合、再生部３６は、高能率符号復号器（デコーダ）、D/A変換器、アナログアンプ等を有して構成される。
【０１３１】
入力部３７は、利用者から、コンテンツの選択・コンテンツの再生・停止、トラック切替等の伝送制御情報の入力処理を受け付ける機能を有する。例えば、ビットマップディスプレイとキーボードを用いて、再生ボタン、停止ボタン、コンテンツ選択ダイヤログなどのＧＵＩ部品を利用者に提供し、また、テンキーや数段階のスライドスイッチなどを用いて、トラック番号の入力を受け付ける操作スイッチを提供する。
【０１３２】
次に、本実施形態におけるコンテンツデータのデータ構造について説明する。
【０１３３】
本実施形態におけるビットストリーム切り替え方法の特徴は、トラック切替要求が入力され、トラックを切り替える際に、切り替え前のトラックを走査していた開始フレーム番号FNをそのまま用いることで、切り替え前と切り替え後のコンテンツ再生時刻が完全に連続した形になる点にある（詳細は後述）。
【０１３４】
基本的には、図９に示す従来のコンテンツデータと同様に、本実施形態におけるコンテンツデータは、コンテンツファイル名、総トラック数Ｔ、および各トラックのトラックデータから構成され、さらに各トラックのトラックデータは、トラック番号、トラックタイムスタンプ周波数、総フレーム数、および複数のデータフレームから構成され、さらに個々のデータフレームは、フレーム番号、時刻情報、コンテンツ素片から構成される。
【０１３５】
コンテンツ受信装置３ａの受信部３１、バッファ部３３、コンテンツ読取部３５、再生部３６の各部が、従来のものと何ら変更がない状態で、コンテンツ配信サーバ２から複数トラック分のコンテンツ素片がコンテンツ受信装置３ａへ到達した際、滑らかに再生を継続させるためには、少なくともコンテンツファイル中にトラック切替可能な複数のトラックの相互に、コンテンツ素片が割り当てられている各データフレームにおいて、コンテンツ再生時刻上での時間的な境界が一致している（同じフレーム番号のコンテンツ素片は同じ再生時刻で再生される）必要がある。
【０１３６】
言い換えれば、あるトラックＡとあるトラックＢに、同一のフレーム番号FNAおよびFNBが存在する時、FNAに付随する時刻情報／トラックＡのトラックタイムスタンプ周波数と、FNBに付随する時刻情報／トラックＡのトラックタイムスタンプ周波数とが、一致している必要がある。
【０１３７】
図２に、複数トラックを有するコンテンツデータのデータ構造（時間軸に沿って並べたもの）を示す。横軸をコンテンツ再生時刻（各々の時刻情報／トラックタイムスタンプ周波数）とする。
【０１３８】
図２中、コンテンツ素片、FN1，FN2…FNn，FNm等は、コンテンツ素片に割り当てられたフレーム番号である。１トラックのフレーム番号の総数は一致している必要はなく、図２では、トラック１は総フレーム数がｎ、トラック２は総フレーム数がｍとなっている。また、コンテンツのデータが、MPEG-4 AAC hi-bitrate符号化などの高能率符号化を施されている場合は、１つのコンテンツ素片に、複数の高能率符号化の圧縮パケットを含んでいてもかまわない。
【０１３９】
しかし、１つのコンテンツ素片に含まれる複数の圧縮パケットを再生した際の時間長の合計は、２つ以上のトラックから同一フレーム番号のコンテンツ素片を取り出した時、一致していなければならない。そのため、同一フレーム番号FNxにおける各トラックのコンテンツ素片xの時刻情報xは、各トラックのトラックタイムスタンプ周波数が同じ値であれば、必ず同じ値を有している。
【０１４０】
従って、図２中の矢印（Ａ）で示すように、フレーム番号FN2でトラック１からトラック２へと再生途中で切り替えても、滑らかに再生を継続することができる。
【０１４１】
次に、伝送制御情報の送受信時におけるコンテンツ配信サーバ２の伝送制御部２２およびコンテンツ受信装置３ａの伝送制御部３２の動作について、図３のシーケンス図を用いて説明する。図２は、RTSPを用いて１つのコンテンツを選択し、伝送のためのセッションを確立し、再生を開始し、停止するまでに行われる処理であり、以下に示す送受信されるメッセージは、伝送制御情報に含まれる。
【０１４２】
なお、ここでは、コンテンツ配信サーバ２のホスト名を“server.jvc-victor.jp”とし、コンテンツを蓄積しているコンテンツファイル名を“hoge.mp4”とし、“hoge.mp4”内部には１つのMPEG-4 AAC音声トラックが存在し、トラック番号は１であるとし、再生時間は235秒であるとする。
【０１４３】
RTSPは、コンテンツをネットワーク上で一意に特定するための資源識別子として、コンテンツURIを適用する。コンテンツ“hoge.mp4”は以下のようなコンテンツURIによって表される。
【０１４４】
“rtsp://server.jvc-victor.jp/hoge.mp4”
まず、伝送制御部３２は、コンテンツURIを用いて、セッション記述を要求する（ステップＳ０１）。このセッション記述とは、コンテンツURIに関連付けられたコンテンツデータに対して、どのようなセッション（通信路）が確立できるかを示したテキストである。セッション記述形式としては、SDPが適用される。RTSPにおいてセッション記述の要求にはDESCRIBEメソッドを使用する。なお、各メソッドおよびその応答メッセージ（その他付随する情報も含めて）は、それぞれリクエストメッセージのヘッダおよびレスポンスメッセージのヘッダに挿入されて送受信される。
【０１４５】
“DESCRIBE rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
伝送制御部２２は、セッション記述を含んだ応答を送信する（ステップＳ０２）。セッション記述には、再生時間と、メディア記述が含まれる。この再生時間とは、指定したコンテンツURIに関連付けられた連続メディアの最大の再生時間長である。再生時間のフォーマットは多種類あるが、最も簡単なフォーマットは、開始時間と終了時間を、浮動小数点を用いた秒数で表したNPTである。例えば、235秒分のMPEG-4 AAC音声トラックを含んだコンテンツデータを指し示すコンテンツURIの再生時間を、NPTを用いて表すと以下のようになる。
【０１４６】
“a=range:npt=0.0-235.0”
また、メディア記述には、セッションを確立するための事前情報として、コンテンツ種別やネットワークタイムスタンプ周波数などの情報を含む。
【０１４７】
“m=audio 0 RTP/AVP/UDP 96”
“a=rtpmap:96 mpeg4-generic/48000/2”
“a=control:rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1”
“a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1190; SizeLength=13; IndexLength=3; IndexDeltaLength=3; Profile=1;”
上記のメディア記述は、MPEG-4 AAC Hi-bitrate符号化方式で符号化された48000Hz（48KHz）PCMサンプル周波数のステレオ音声が含まれていることを表現している。また、セッションを確立する際には、UDPを下位ネットワークプロトコルとし、RTPを適用して伝送しなければならないことが示されている。
【０１４８】
また、このセッションの準備要求には以下のコントロールURIを使うことが示されている。コントロールURIは、1つのコンテンツデータ内の複数トラックを識別するためにトラック番号（trackID=1）が付与されている。
【０１４９】
“rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1”
セッション記述を解析した伝送制御部３２は、MPEG-4 AACステレオ音声を伝送するためのセッションを確立するため、セッションの受信アドレスを決定し、セッション確立準備の要求を伝送制御部２２へ送信する（ステップＳ０３）。RTSPにおけるセッション確立準備要求にはSETUPメソッドを用いる。下記の例では、受信アドレスは、伝送制御部３２の持つ受信アドレス（136.198.190.100）と受信ポート番号（6668-6669）となっている。
【０１５０】
“SETUP rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1 RTSP/1.0”
“Transport: RTP/AVP/UDP;unicast;destination=136.198.190.100;client_port
=6668-6669”
セッション確立準備要求を正しく受信した伝送制御部２２は、新たに送信アドレスを決定し、送信アドレスを送信部２３へ入力し、あわせて、セッション情報を伝送制御部３２へ送信する（ステップＳ０４）。セッション情報には、配信に用いる配信サーバの送信アドレス（例では136.198.190.1）や送信ポート番号（下記の例では19000〜19001）が含まれる。
【０１５１】
“Transport: RTP/AVP/UDP;unicast;source=136.198.190.1;server_port=19000
-19001”
また、伝送制御部３２では、セッション情報を受け付けた時点で、先に決定しておいた受信アドレスを受信部３１へ入力する。送信部２３と受信部３１の双方の処理が完了した時点で、新たなセッションが確立される。
【０１５２】
次に、伝送制御部３２は、伝送制御部２２に対して、利用者の入力操作に応じた再生するコンテンツのトラックを指定するトラック切替要求（CHANGEメソッド）を送信する（ステップＳ０５）。トラック番号指定（TrackID=）には、次に切り替えたいトラック番号を設定する。
【０１５３】
“CHANGE rtsp://server.jvc-victor.jp/hoge.mp4/TrackID=2 RTSP/1.0”
伝送制御部２２は、トラック切替要求を受信すると、コンテンツ記憶部２５を参照して、次に切り替えたいトラック番号に対応するトラックがコンテンツhoge.mp4内に存在する場合は、下記の正常応答を送信する（ステップＳ０６）。
【０１５４】
“RTSP/1.0 200 OK”
また、次に切り替えたいトラック番号に対応するトラックがコンテンツhoge.mp4内に存在しない場合は、伝送制御部２２は、下記の異常応答を送信する。
【０１５５】
“RTSP/1.0 404 NOT FOUND”
なお、このトラック切替要求およびトラック切替応答は一例であって、文字列表現の多少の差異によって独自性が失われることはない。今回はRTSPを拡張したが、HTTP（Hyper Text Transfer Protocol）のGETメソッドを用いて、トラック切替要求を以下のように書き替えてもよい（Network Working Group, "Hypertext Transfer Protocol -- HTTP/1.1", RFC2616, The Internet Society, June 1999）。
【０１５６】
“GET /hoge.mp4?TrackID=2 HTTP/1.1”
GETメソッドにはコンテンツ配信サーバ２２のホスト名が含まれないが、コンテンツファイル名と次に切り替えるトラック番号を、RTSPと同様の手法で内包させることができる。
【０１５７】
次に、伝送制御部３２は、再生開始要求を送信する（ステップＳ０７）。再生開始要求では、再生範囲を、NPTを用いて指定することができる。下記の例では、コンテンツの最初（0.0秒）から最後（235.0秒）までと再生範囲を指定している。RTSPにおいて再生開始要求にはPLAYメソッドを用いる。
【０１５８】
“PLAY rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
“Range: npt=0.0-235.0”
伝送制御部２２は、再生開始要求の応答を送信する（ステップＳ０８）。再生開始要求を受け付けた伝送制御部２２は、既に準備の済んでいる全てのセッション対して、各セッションのコントロールURIと再生開始要求に含まれる再生範囲から、コンテンツファイル名・トラック番号・コンテンツ再生開始時刻を算出し、コマンド入力＝再生開始定数（例えば“PLAY”）と合わせて、コンテンツ取得部２１に入力し、RTPパケットの送信を開始する。
【０１５９】
また、この応答は、コンテンツ受信装置３ａのコンテンツ読取部３５の動作に必要となるRTPパケット情報を含む。例えば、このセッションにおいて、最初に送られてくるRTPパケットのRTPタイムスタンプ（ネットワークタイムスタンプ）などが含まれる（下記の例では0000000）。
【０１６０】
“RTP-Info: url= rtsp://server.jvc-victor.jp/hoge.mp4/trackID=1;rtptime
=0000000;”
なおトラック切替要求は、ステップＳ０４の準備要求応答以降かつ停止前であれば、いつでも送信して良い。従って、あるトラックを再生途中でトラック切替が入力されると、伝送制御部３２は、ステップＳ０５で送信されたトラック切替要求を送信し（ステップＳ０９）、伝送制御部２２は、トラック切替要求を受信すると、次に切り替えたいトラック番号をコンテンツ取得部２１へ入力する。コンテンツ取得部２１は、次に切り替えたいトラック番号の存在を確認して、切替結果（＝正常または＝異常）を伝達制御部２２へ入力する。伝達制御部２２は、切替結果が入力されると、トラック切替応答（切替結果＝正常であれば正常応答へ、切替結果＝異常であれば異常応答）を伝達制御部３２へ送信する（ステップＳ１０）。
【０１６１】
また、コンテンツ取得部２１は、指定されたトラックのコンテンツ素片をコンテンツ記憶部２５から取得し、送信部２３を介してコンテンツ受信装置３ａへ送信する（詳細は後述）。
【０１６２】
また、伝送制御部３２は、利用者が停止入力を行った時点で停止要求を送信する（ステップＳ１１）。RTSPにおいて停止要求はTEARDOWNメソッドである。
【０１６３】
“TEARDOWN rtsp://server.jvc-victor.jp/hoge.mp4 RTSP/1.0”
停止要求を受け付けた伝送制御部２２は、送信部２３を制御し、RTPパケットの送信を停止、セッションを切断し、送信を停止したことを通知する（ステップＳ１２）。また、伝送制御部２２は、コンテンツ取得部２１に対して、コマンド入力＝再生停止定数（例えば“STOP”）を入力し、読み出しを停止する。
【０１６４】
なお、説明の簡単化のために、１つのコンテンツデータに1つのコンテンツのみが含まれると仮定していたが、前記の伝送制御機構は容易に複数のコンテンツの同期再生に拡張可能である。例えば、ステップＳ０２において、複数のコンテンツに関するメディア記述を列挙し、ステップＳ０３〜ステップＳ０４の準備要求をメディア記述分繰り返すだけで、複数のコンテンツの同期再生が容易に行うことが可能である。
【０１６５】
次に、コンテンツデータを読み出す際のコンテンツ取得部２１の再生時刻管理処理（送信側）について、図４のフローチャートを用いて説明する。
【０１６６】
まず、コンテンツ受信装置３ａからコンテンツの再生要求がされると、コンテンツ配信サーバ２のコンテンツ取得部２１は、以下に示す６つの変数の初期化を行う（ステップＳ２１）。
【０１６７】
１：コンテンツファイル名CF＝デフォルトのコンテンツファイル名（例えば“hoge.mp4”）
２：トラック番号TN＝デフォルトのトラック番号（例えば“1”）
３：開始フレーム番号FN＝デフォルトのフレーム番号（例えば“1”）
４：再生開始時刻STS＝システムクロック発振部２４から得た現在時刻NTS
５：コンテンツ再生時刻CTS＝“0”
６：再生状態フラグF＝真偽値“Ｎ”
次に、コンテンツ取得部２１は、自動的に再生を開始するか否かを示す予め定められた自動モード定数を参照し、自動再生を行うかどうか判定する（ステップＳ２２）。自動モード定数が真偽値“Ｙ”である場合は、ステップＳ３４の処理へ移行し、自動モード定数が真偽値“Ｎ”である場合には、ステップＳ２３の処理へ移行する。
【０１６８】
ステップＳ２２の処理において、定数が真偽値“Ｎ”であった場合には、コンテンツ取得部２１は、外部入力（コマンド入力CMD、コンテンツファイル名CF1、トラック番号TN1、コンテンツ再生開始時刻CTS1の４つの変数の組）があるかどうか判定し（ステップＳ２３）、外部入力がある場合に真偽値“Ｙ”となりステップＳ２４の処理へ移行し、外部入力がない場合に真偽値“Ｎ”となりステップＳ３０の処理へ移行する。
【０１６９】
ステップＳ２３の処理において、真偽値“Ｙ”であった場合には、コンテンツ取得部２１は、外部入力のうち、コマンド入力CMD＝トラック切替定数（例えば“CHANGE”）であるか判定し（ステップＳ２４）、トラック切替定数であった場合に真偽値“Ｙ”となりステップＳ２５の処理へ移行し、真偽値“Ｎ”の場合は、ステップＳ２８の処理へ移行する。
【０１７０】
また、ステップＳ２４の処理において、真偽値“Ｙ”であった場合には、コンテンツ取得部２１は、外部入力のうち（コンテンツファイル名CF1、トラック番号TN1）を用いて、CFとCF1が等しく、かつ、コンテンツファイル名CFにトラック番号TN1が指し示すトラックが存在するか、トラック切替可能か判定し（ステップＳ２５）、可能であれ真偽値“Ｙ”となりステップＳ２６の処理へ移行し、トラック番号TN＝トラック番号TN1となる代入しトラック切替処理を行った上で、伝送制御部２２へ切替結果＝正常を通知する（ステップＳ２６）。また、トラックが存在せずに切替不可能であれば真偽値“Ｎ”となり、コンテンツ取得部２１は、ステップＳ２７の処理へ移行し、伝送制御部２２へ切替結果＝異常を通知する（ステップＳ２７）。
【０１７１】
また、ステップＳ２４の処理において、真偽値“Ｎ”となった場合には、コンテンツ取得部２１は、外部入力のうちコマンド入力CMD＝再生停止定数であるかを判定し（ステップＳ２８）、コマンド入力CMD＝再生停止定数である場合は真偽値“Ｙ”となり、全体の動作を停止終了し、それ以外の場合は真偽値“Ｎ”となり、ステップＳ２９の処理へ移行する。
【０１７２】
ステップＳ２８の処理において、真偽値“Ｎ”であった場合には、コンテンツ取得部２１は、外部入力（コンテンツファイル名CF1、トラック番号TN1、コンテンツ再生開始時刻CTS1）の３変数を用いて、まず５つの変数の初期化を行う（ステップＳ２９）。
【０１７３】
１：コンテンツファイル名CF＝コンテンツファイル名CF1
２：トラック番号TN＝トラック番号TN1
３：再生開始時刻STS＝システムクロック発振部２４から得た現在時刻NTS
４：コンテンツ再生時刻CTS＝コンテンツ再生開始時刻CTS1
５：再生状態フラグF＝真偽値“Ｙ”
続いてコンテンツ取得部２１は、コンテンツ再生時刻CTSを用いた開始フレーム番号FNの初期化を行い、前段階として送出開始時刻情報StartTSを算出する。送出開始時刻情報StartTSの算出式を以下に示す。
【０１７４】
＜数７＞
StartTS＝CTS×TRS
ここでトラックタイムスタンプ周波数TRSは、コンテンツファイル名CFの中のトラック番号TNが指し示すトラックのトラックタイムスタンプ周波数である。
【０１７５】
次に、コンテンツ取得部２１は、コンテンツファイル名CFの中のトラック番号TNが指し示すトラックのフレーム番号を１から順に検索し、時刻情報≧StartTSが成り立つ点のフレーム番号NFNを得て、フレーム番号NFNを開始フレーム番号FNに設定する。以上がステップＳ２９の概要である。
【０１７６】
また、ステップＳ２３の処理において、自動モード定数が真偽値“Ｎ”であった場合には、コンテンツ取得部２１は、再生状態フラグの値が真偽値“Ｙ”であるかどうか判定し（ステップＳ３０）、値が真偽値“Ｙ”である場合ステップＳ３１の処理へ移行し、真偽値“Ｎ”である場合にはステップＳ２３の処理へ移行する。
【０１７７】
ステップＳ３０の処理において再生状態フラグの値が真偽値“Ｙ”であった場合、またはステップＳ２６、Ｓ２７、Ｓ２９から継続する処理の場合には、コンテンツ取得部２１は、システムクロック発振部２４から得た現在時刻NTSと再生開始時刻STSとシステムクロック周波数SSから経過時間を算出し、経過時間とコンテンツ再生時刻CTSとトラックタイムスタンプ周波数TRSから、送出可能時刻情報LastTSを算出することによって、送信可能範囲を検索する（ステップＳ３１）。送出可能時刻情報LastTSの算出式を以下に示す。
【０１７８】
＜数８＞
LastTS＝（NTS−STS）／SS×TRS
ここでシステムクロック周波数SSとは、（現在時刻NTS−再生開始時刻STS）を秒単位に変換するための定数である。例えばシステムクロックが1/1000000秒の精度を持っているとすると1000000である。
【０１７９】
次に、コンテンツ取得部２１は、コンテンツファイル名CFの中のトラック番号TNが指し示すトラック内の、開始フレーム番号FNからフレーム番号を順にサーチし、時刻情報≧LastTSが成り立つ点のフレーム番号NFNを取得する。条件を満たすフレーム番号NFNが求まらない場合は、コンテンツ取得部２１は、フレーム番号NFNに終端定数“−1”を設定する。
【０１８０】
次に、コンテンツ取得部２１は、開始フレーム番号FNとフレーム番号NFNを比較することによって送信の可否を判定し（ステップＳ３２）、FN＜NFNが成立する場合には真偽値“Ｙ”となりステップＳ３３の処理へ移行し、成立しない場合は真偽値“Ｎ”となりステップＳ２３の処理へ移行する。
【０１８１】
ステップＳ３２の処理において真偽値“Ｙ”であった場合には、コンテンツ取得部２１は、コンテンツファイル名CFの中のトラック番号TNが指し示すトラック内の、開始フレーム番号FNからフレーム番号NFN未満の各フレーム番号に対応するコンテンツ素片それぞれと、それぞれのコンテンツ素片について、対応する時刻情報から下記の算出式に従って生成されたネットワークタイムスタンプPTSとを、送信部２３へ出力する（ステップＳ３３）。
【０１８２】
＜数９＞
PTS＝時刻情報／TRS×ネットワークタイムスタンプ周波数
出力後、送信済みの位置まで開始フレーム番号FNをずらすため、コンテンツ取得部２１は、開始フレーム番号FN＝フレーム番号NFNと設定する。
【０１８３】
また、ステップＳ２２の処理において、自動モード定数が真偽値“Ｙ”であった場合には、コンテンツ取得部２１は、再生状態フラグF＝真偽値“Ｙ”と設定し、再生開始時刻STS＝システムクロック発振部２４から得た現在時刻NTSを設定し、自動再生開始のための設定を行う（ステップＳ３４）。
【０１８４】
このように、伝送制御部２２、２３によって確立されるコントロールラインでトラック切替のメッセージが送受信され、そのメッセージに従って、時刻情報を基に切り替えた先のトラックのコンテンツ素片を取得、送信するので、コンテンツ受信装置３ａでは、トラックが切り替えられても滑らかな再生を行うことができる。
【０１８５】
なお、送信部２３−受信部３１間の通信は、RTP（Real-time Transfer Protocol, RFC1889）の規約に従って行っても良い。
【０１８６】
≪応用例１≫
上記の実施形態の応用例１として、図５に、コンテンツ配信サーバ２とコンテンツ受信装置３ｂ（カラオケ装置）とからなるコンテンツ配信システム１ｂの機能ブロック図を示す。図５に示すコンテンツ配信システム１ｂは、いわゆる通信カラオケシステムである。
【０１８７】
コンテンツ配信サーバ２は、コンテンツ取得部２１、伝送制御部２２、送信部２３、システムクロック発振部２４、およびコンテンツ記憶部２５を有する。
【０１８８】
また、コンテンツ受信装置３ｂは、受信部３１、伝送制御部３２、バッファ部３３、システムクロック発振部３４、コンテンツ読取部３５、再生部３６ｂ、入力部３７、およびマイク入力部３８を有する。なお、上記の実施形態と同じものについては、同じ番号を付し、その詳細な説明を省略する。
【０１８９】
再生部３６ｂは、入力されたコンテンツ素片に応じた復号化を行い、マイク入力部からの音声信号と合成した後、スピーカ等の所定の出力装置に対して音声信号、映像信号を出力する機能を有する。例えば、コンテンツ素片がMPEGに類する高能率符号化されたデジタル音声データである場合、再生部３６は、高能率符号復号器（デコーダ）、D/A変換器、アナログアンプ等を有して構成される。
【０１９０】
ここでいう合成の最低要件は、コンテンツ読取部３５とマイク入力部３８とからの２つの入力をほぼ同時に再生することである。仮にコンテンツ素片の種別が音声である場合は、マイク入力部３８からの音声と不自然でないように適切なミキシング合成や音量調整を行っても良い。
【０１９１】
マイク入力部３８は、マイク等の音声取込装置によって取り込まれた音声信号の入力を受け付け、その音声信号を再生部３６ｂが扱うデータ形式に変換する機能を有する。
【０１９２】
図５の通信カラオケシステムにおいて、あるコンテンツをコンテンツ配信サーバ２からコンテンツ受信装置３ｂへ送信するとする。
【０１９３】
そのコンテンツは、例えば、男性ボーカルと女性ボーカルとのデュエット曲であり、トラック１に曲の伴奏のみのデータを、トラック２に伴奏と男性ボーカルのデータを、トラック３に伴奏と女性ボーカルのデータをそれぞれ記録してあるとする。
【０１９４】
そうすると、利用者の要求に合わせて適切なトラックを提供することで、男性ボーカルまたは女性ボーカルと合わせて一人でデュエット曲を歌唱することができ、多彩なサービスを提供することができる。
【０１９５】
≪応用例２≫
上記の実施形態の応用例２として、図６に、コンテンツ配信サーバ２、コンテンツ受信装置３ｂ（カラオケ装置）、およびオーサリング装置５とからなるコンテンツ配信システム１ｃ（通信カラオケシステム）の機能ブロック図を示す。オーサリング装置５は、コンテンツ配信サーバ２と同一の筐体に収められても良いし、別の筐体に収められても良い。なお、便宜上、オーサリング装置５を利用する利用者のことを、編集者と呼ぶ。
【０１９６】
コンテンツ配信サーバ２は、コンテンツ取得部２１、伝送制御部２２、送信部２３、システムクロック発振部２４、およびコンテンツ記憶部２５を有する。
【０１９７】
また、コンテンツ受信装置３ｂは、受信部３１、伝送制御部３２、バッファ部３３、システムクロック発振部３４、コンテンツ読取部３５、再生部３６ｂ、入力部３７、およびマイク入力部３８を有する。なお、上記の実施形態と同じものについては、同じ番号を付し、その詳細な説明を省略する。
【０１９８】
また、オーサリング装置５は、オーサリング部５１、音程変換部５２、コンテンツ送信部５３、入力部５４、マイク入力部５５、およびコンテンツ一次記憶部５６を有する。
【０１９９】
オーサリング部５１は、入力部５４からの指示入力とマイク入力部５５からの音声データを用いて、コンテンツデータの新規作成・トラック追加・コンテンツデータの削除等、コンテンツデータの作成編集を行う機能、作成編集したコンテンツデータをコンテンツ一次記憶部５６に記録する機能を有する。
【０２００】
音程変換部５２は、コンテンツを構成する原音の音声データ（以降、ソース音声データと称す）に対して、少なくとも半音もしくは全音ごとに音程変換を行う機能（例えば、特開平９−１８５３９２号公報の音程変換装置のような、音声の周波数領域変換を利用した周波数シフトアルゴリズムを用いる）を有する。
【０２０１】
この応用例２では、基準となるソース音声データの音階を“0”とし、上に半音シフトすると“+1”、下に半音シフトすると“-1”となるような整数変数をキー変数kと呼ぶ。一般的なカラオケ装置における音程変換を実現する場合、キー変数kは、少なくとも-6〜0〜+6までの範囲を採り得る。
【０２０２】
例えば、k=+1の場合、短２度の移調に相当し、原曲がハ長調だった場合は移調後の調は変ニ長調となる。また、k=-6の場合は、減５度に相当し、原曲がハ長調だった場合は移調後の調は嬰ヘ長調となる。
【０２０３】
なお、k=-6未満（もしくは+6より大）が用いられない理由は、例えば、半音シフトで-6さげるということは、半音シフトで+6（増４度）してから１オクターブ下げる移調に相当するからである。カラオケの場合、利用者本人が意図している調に合致しさえすれば、演奏のオクターブが異なっても、快適に歌唱することができる。
【０２０４】
コンテンツ送信部５３は、入力部５４からコンテンツファイル移動指示と移動先配信サーバ名が入力されると、コンテンツ一次記憶部５６に保存されているコンテンツデータを、移動先配信サーバ名の指し示す配信サーバ内のコンテンツ記憶部２５へネットワークを介して送信する機能を有する。
【０２０５】
また、コンテンツ送信部５３は、CD-RやDVD-R等の記録媒体にコンテンツデータを記録する機能を有する。ネットワークを介してコンテンツデータの送信を行わない場合は、記録媒体にてコンテンツデータを提供する。
【０２０６】
入力部５４は、編集者が、コンテンツデータ新規作成指示・トラック追加指示・コンテンツデータ移動指示・コンテンツデータ削除指示の各指示入力を受け付ける機能を有する。例えば、ビットマップディスプレイとキーボードを用いて、再生ボタン、停止ボタン、コンテンツ選択ダイヤログなどのＧＵＩ部品を利用者に提供し、また、テンキーや数段階のスライドスイッチなどを用いて、トラック番号の入力を受け付ける操作スイッチを提供する。
【０２０７】
マイク入力部５５は、マイク等の音声取込装置によって取り込まれた音声信号の入力を受け付け、その音声信号を再生部３６ｂが扱うデータ形式に変換してソース音声データを生成する機能を有する。また、マイク入力部５５は、CD-ROMドライブやネットワーク等の外部からソース音声データを受け付けるためのインタフェースを備えても良い。さらに、マイク入力部５５はマイクとメモリを備え、一定時間分の音声信号を録音してソース音声データに変換するようにしても良い。編集者がトラック追加指示を入力すると、同時にソース音声データがオーサリング装置５にマイク入力部５５を通して取り込まれる。
【０２０８】
コンテンツ一次記憶部５６は、オーサリング部５１が作成編集したコンテンツデータを一次的に記憶する機能を有する。
【０２０９】
次に、オーサリング装置５の動作について説明する。
【０２１０】
（１）コンテンツデータの新規作成
オーサリング部５１は、入力部５４からコンテンツデータ新規作成指示と、コンテンツファイル名CF1が入力されると、コンテンツ一次記憶部５６に、トラックの全く含まれないコンテンツデータを、コンテンツファイル名CF1で作成する。
【０２１１】
（２）コンテンツデータの削除
オーサリング部５１は、入力部５４からコンテンツデータ削除指示と、コンテンツファイル名CF1が入力されると、コンテンツ一次記憶部５６に記録されているコンテンツファイル名CF1のコンテンツデータを削除する。
【０２１２】
（３）トラック追加
オーサリング部５１は、入力部５４からトラック追加指示、コンテンツファイル名CF1、トラック番号TN1、キー変数kが入力され、マイク入力部５５からソース音声データが入力されると、まず、キー変数kが“0”か否かを判定し、“0”以外であれば音程変換部５２を用いてソース音声データに音程変換を施す。
【０２１３】
次に、オーサリング部５１は、コンテンツファイル名CF1の指し示すコンテンツデータをオープンし、総トラック数を+1し、トラック番号TN1の指し示すトラックデータを追加し、ソース音声データを適当なサンプル数毎にコンテンツ素片に分割し、必要であれば高能率符号化を施し、フレーム番号と時刻情報を付与して多重化する。トラックタイムスタンプ周波数は、音声データのサンプリング周波数を測定して書き込む。
【０２１４】
このようにして音程の異なるトラックを複数作成し、作成されたコンテンツデータを、オーサリング装置５はコンテンツ配信サーバ２へ供給することで、コンテンツ受信装置３ｂ側に従来あった音程変換部５２を搭載する必要がなく、また、コンテンツのオーサリング時に高品質な音程変換が可能になるため、サービス品質を向上させることができる。
【０２１５】
また、コンテンツ受信装置３ｂ側に従来あった音程変換部５２を搭載する必要が無くても、音程変換部５２を搭載したものと同等のサービスが可能となり、劇的にサービスコストを低減することできる。
【０２１６】
また、音程変換部５２がコンテンツ受信装置３ｂとは独立して存在するため、コンテンツ受信装置のハードウェアの製作時期および出荷時期に依存せず、全てのコンテンツ受信装置３ｂで同等のサービス品質の向上効果が得られる。
【０２１７】
また、コンテンツのオーサリング時に、複数の音程範囲のうち、ある音程分は機械的な処理によって音程変換を行い、ある音程分は移調された楽譜を用いて演奏者・歌唱者が実際に演奏・歌唱した音声データを用いることによって、従来の手法では不可能かつ高品質なサービスの実現といったことも可能となる。
【０２１８】
また、コンテンツの著作者が音程変換等の楽曲加工に承諾しないコンテンツに関しては、オーサリング時に音程変換を行ったトラックを追加しないだけで、コンテンツ受信装置３ｂ全てに特別な情報を送信することなく、容易に特定のコンテンツに対して音程変換再生を禁止することも可能である。
【０２１９】
なお、図６のコンテンツ配信システム１ｃでは、コンテンツ配信サーバ２、コンテンツ受信装置３ｂ、オーサリング装置５が、１つずつしかない構成であったが、図７に示すように、オーサリング装置５に複数台のコンテンツ配信サーバ２を接続し、それぞれのコンテンツ配信サーバ２にコンテンツ受信装置３ｂを接続するようにしても良い。
【０２２０】
これは、多数の利用者にサービスを提供可能な通信カラオケシステムの例として好適である。オーサリング装置５で音程変換処理を行って複数トラックに音程の異なるコンテンツデータが記録されたコンテンツデータを用意することによって、複数のコンテンツ配信サーバ２に同一のコンテンツデータをコピーするだけで、各コンテンツ受信装置３ｂは音程変換を行う手段を搭載せずとも、トラックを変更することで再生中に動的な音程変換を行うことが可能となる。また、利用者が増加し、コンテンツ配信サーバ２とコンテンツ受信装置３ｂの組が増加しても、音程変換処理に必要とされる時間・演算コストは常に一定であり、劇的なコスト削減が可能となる。
【０２２１】
以上、本発明の実施形態について説明したが、本発明はこれらに限定されるものでない。また、コンテンツ配信サーバ２、コンテンツ受信装置３、およびオーサリング装置５の構成要件のうち、全てまたは一部をコンピュータで実行可能なプログラムとして実現し、予めコンピュータ読み取り可能な記録媒体などに記録して提供することも可能である。
【０２２２】
また、物理的に１台のコンピュータで、コンテンツ配信サーバ２に相当するプログラムを複数実行しても良い。さらに、物理的に１台のコンピュータで、コンテンツ受信装置３に相当するプログラムを複数実行しても良い。
【０２２３】
また、物理的に1台のコンピュータで、コンテンツ配信サーバ２に相当するプログラムとコンテンツ受信装置３に相当するプログラムを実行しても良い。さらに、物理的に１台のコンピュータで、コンテンツ配信サーバ２に相当するプログラムとオーサリング装置５に相当するプログラムを実行しても良い。
【図面の簡単な説明】
【０２２４】
【図１】コンテンツ配信システム１ａ（非同期モデル）におけるコンテンツ配信サーバ２とコンテンツ受信装置３ａの機能ブロック図である。
【図２】複数トラックを有するコンテンツデータのデータ構造を示す図である。
【図３】伝送制御情報の送受信時におけるコンテンツ配信サーバ２の伝送制御部２２およびコンテンツ受信装置３ａの伝送制御部３２の動作を示すシーケンス図である。
【図４】コンテンツデータを読み出す際のコンテンツ取得部２１の再生時刻管理処理（送信側）を示すフローチャートである。
【図５】コンテンツ配信サーバ２とコンテンツ受信装置３ｂ（カラオケ装置）とからなるコンテンツ配信システム１ｂ（通信カラオケシステム）の機能ブロック図である。
【図６】コンテンツ配信サーバ２、コンテンツ受信装置３ｂ（カラオケ装置）、およびオーサリング装置５とからなるコンテンツ配信システム１ｃ（通信カラオケシステム）の機能ブロック図である。
【図７】オーサリング装置５に複数台のコンテンツ配信サーバ２を接続した構成例を示す図である。
【図８】非同期モデルにおけるコンテンツ配信サーバ１０２ａとコンテンツ受信装置１０３ａの機能ブロック図である。
【図９】コンテンツデータのデータ構造の一例を示す図である。
【図１０】コンテンツファイルを読み出す際のコンテンツ取得部１０２１の再生時刻管理処理（送信側）を示すフローチャートである。
【図１１】ネットワークタイムスタンプを用いたコンテンツ読取部１０３４の再生時刻管理処理（受信側）を示すフローチャートである。
【図１２】伝送制御機構を備えるコンテンツ配信システム１０１ｂを構成するコンテンツ配信サーバ１０２ｂとコンテンツ受信装置１０３ｂの機能ブロック図である。
【図１３】伝送制御情報の送受信時における伝送制御部１０２５および伝送制御部１０３６の動作を示すシーケンス図である。
【図１４】バッファ部１０３２に蓄積されているコンテンツ素片の順列を示す図である。
【図１５】２トラック同時受信可能なコンテンツ配信システム１０１ｃを構成するコンテンツ配信サーバ１０２ｃとコンテンツ受信装置１０３ｃの機能ブロック図である。
【図１６】複数トラック同時受信構成を有するコンテンツ受信装置１０３ｃの動作を示すフローチャートである。
【符号の説明】
【０２２５】
１ａ、ｂ  コンテンツ配信システム
２  コンテンツ配信サーバ
３ａ、ｂ  コンテンツ受信装置
４  IPネットワーク
５  オーサリング装置
２１  コンテンツ取得部
２２  伝送制御部
２３  送信部
２４  システムクロック発振部
２５  コンテンツ記憶部
３１  受信部
３２  伝送制御部
３３  バッファ部
３４  システムクロック発振部
３５  コンテンツ読取部
３６  再生部
３７  入力部
３８  マイク入力部
５１  オーサリング部
５２  音程変換部
５３  コンテンツ送信部
５４  入力部
５５  マイク入力部
５６  コンテンツ一次記憶部
１０１ａ、ｂ、ｃ  コンテンツ配信システム
１０２ａ、ｂ、ｃ  コンテンツ配信サーバ
１０３ａ、ｂ、ｃ  コンテンツ受信装置
１０４  ネットワーク
１０２１  コンテンツ取得部（Ａ，Ｂ）
１０２２  送信部（Ａ，Ｂ）
１０２３  システムクロック発振部
１０２４  コンテンツ記憶部
１０２５  伝送制御部
１０３１  受信部（Ａ，Ｂ）
１０３２  バッファ部（Ａ，Ｂ）
１０３３  システムクロック発振部
１０３４  コンテンツ読取部（Ａ，Ｂ）
１０３５  再生部
１０３６  伝送制御部
１０３７  入力部
１０３８  切替部
【図１】
2005173241.tif 000003
【図２】
2005173241.tif 000004
【図３】
2005173241.tif 000005
【図４】
2005173241.tif 000006
【図５】
2005173241.tif 000007
【図６】
2005173241.tif 000008
【図７】
2005173241.tif 000009
【図８】
2005173241.tif 000010
【図９】
2005173241.tif 000011
【図１０】
2005173241.tif 000012
【図１１】
2005173241.tif 000013
【図１２】
2005173241.tif 000014
【図１３】
2005173241.tif 000015
【図１４】
2005173241.tif 000016
【図１５】
2005173241.tif 000017
【図１６】
2005173241.tif 000018