(57)【特許請求の範囲】
【請求項１】
クライアント側でのストリーミング再生のために、前記クライアントに伝送リンクを介してデータ信号をストリーミングするサーバであって、前記データ信号は、１次データユニットと２次データユニットを含むデータユニットのシーケンスを含み、前記１次及び２次データユニットは、前記クライアント側でのストリーミング再生のためのスケジュールされた再生時間を有し、前記１次及び２次データユニットは、原データユニットの順序に従って、前記データ信号において順序づけられており、前記サーバは、原データユニットの順序では１次データユニットに先行する２次データユニットを、該１次データユニットと交換することにより、データユニットのシーケンスにおける前記１次および２次データユニットの順序を変更して、前記データユニットのシーケンスにおいて前記１次データユニットが前記２次データユニットに先行する、修正されたデータユニットの順序をもつリオーダされたデータ信号を生成するようにするリオーダリングユニットを備え、これにより、１次データユニットがクライアント側で時間通りに受信され、クライアント側でのストリーミング再生中、スケジュールされた再生時間で再生される可能性を増大させることを特徴とするサーバ。
【請求項２】
前記１次データユニットは、ベースレイヤを表し、前記２次データユニットは、少なくとも１つのエンハンスメントレイヤを表す請求項１に記載のサーバ。
【請求項３】
前記データ信号はスケーラブルである請求項１に記載のサーバ。
【請求項４】
前記データ信号は、時間的領域、空間的領域、スペクトル領域およびＳＮＲ領域からなるグループから選択された領域で、スケーラブルであることを特徴とする請求項３に記載のサーバ。
【請求項５】
前記データ信号を出力するエディタを備えることを特徴とする請求項１に記載のサーバ。
【請求項６】
前記データ信号は、動画を生成するピクチャ・シーケンスを表すことを特徴とする請求項１に記載のサーバ。
【請求項７】
前記データ信号は、ビデオ・シーケンスを表すことを特徴とする請求項６に記載のサーバ。
【請求項８】
前記データ信号は、マルチメディアデータを含むことを特徴とする請求項１に記載のサーバ。
【請求項９】
クライアント側でのストリーミング再生のために、サーバから前記クライアントに、伝送リンクを介してデータ信号をストリーミングする該サーバを有するデータ伝送システムであって、前記データ信号は、１次データユニットと２次データユニットを含むデータユニットのシーケンスを含み、前記１次及び２次データユニットは、前記クライアント側でのストリーミング再生のためのスケジュールされた再生時間を有し、前記１次及び２次データユニットは、原データユニットの順序に従って、前記データ信号において順序づけられており、前記システムは、原データユニットの順序では１次データユニットに先行する２次データユニットを、該１次データユニットと交換することにより、データユニットのシーケンスにおける前記１次および２次データユニットの順序を変更して、前記データユニットのシーケンスにおいて、前記１次データユニットが前記２次データユニットに先行する、修正されたデータユニットの順序をもつリオーダされたデータ信号を生成するようにするリオーダリングユニットを備え、これにより、１次データユニットがクライアント側で時間通りに受信され、クライアント側でのストリーミング再生中、スケジュールされた再生時間で再生される可能性を増大させることを特徴とするデータ伝送システム。
【請求項１０】
前記サーバは、スケーラブルデータ信号を出力するエディタを有することを特徴とする請求項９に記載のデータ伝送システム。
【請求項１１】
前記クライアントは、移動体端末であることを特徴とする請求項９に記載のデータ伝送システム。
【請求項１２】
前記クライアントは、移動体電話であることを特徴とする請求項９に記載のデータ伝送システム。
【請求項１３】
伝送の進捗をチェックし、使用している前記データユニットの順序を利用可能な帯域幅によりよく適合する順序へ変更する手段を備えることを特徴とする請求項９に記載のデータ伝送システム。
【請求項１４】
クライアント側でのストリーミング再生のために、サーバから前記クライアントに伝送リンクを介してデータ信号をストリーミングする方法であって、前記データ信号は、１次データユニットと２次データユニットを含むデータユニットのシーケンスを含み、前記１次及び２次データユニットは、前記クライアント側でのストリーミング再生のためのスケジュールされた再生時間を有し、前記１次及び２次データユニットは、原データユニットの順序に従って、前記データ信号において順序づけられており、前記方法は、原データユニットの順序では１次データユニットに先行する２次データユニットを、該１次データユニットと交換することにより、データユニットのシーケンスにおける前記１次および２次データユニットの順序を変更して、前記データユニットのシーケンスにおいて、前記１次データユニットが前記２次データユニットに先行する、修正されたデータユニットの順序をもつリオーダされたデータ信号を生成し、これにより、１次データユニットがクライアント側で時間通りに受信され、クライアント側でのストリーミング再生中、スケジュールされた再生時間で再生される可能性を増大させることを特徴とするデータ信号ストリーミング方法。
【請求項１５】
前記１次及び２次データユニットは、前記伝送リンクを介して伝送されたときには、これらの原データユニットの順序に戻されることを特徴とする請求項１４に記載のデータ信号ストリーミング方法。
【請求項１６】
伝送の進捗をチェックし、前記データユニットの順序を利用可能な帯域幅によりよく適合する順序へ変更する請求項１４に記載のデータ信号ストリーミング方法。
【請求項１７】
コンピュータプログラムが記録されたコンピュータ読み取り可能な記録媒体であって、
該コンピュータプログラムは、クライアント側でのストリーミング再生のために、サーバから前記クライアントに伝送リンクを介してデータ信号をストリーミングするためのものであり、前記データ信号は、１次データユニットと２次データユニットを含むデータユニットのシーケンスを含み、前記１次及び２次データユニットは、前記クライアント側でのストリーミング再生のためのスケジュールされた再生時間を有し、前記１次及び２次データユニットは、原データユニットの順序に従って、前記データ信号において順序づけられているプログラムを有し、
さらに、前記コンピュータプログラムは、原データユニットの順序では１次データユニットに先行する２次データユニットを、該１次データユニットと交換することにより、データユニットのシーケンスにおける前記１次および２次データユニットの順序を変更して、前記データユニットのシーケンスにおいて、前記１次データユニットが前記２次データユニットに先行する、修正されたデータユニットの順序をもつリオーダされたデータ信号を生成し、これにより、１次データユニットがクライアント側で時間通りに受信され、クライアント側でのストリーミング再生中、スケジュールされた再生時間で再生される可能性を増大させるプログラムを有することを特徴とするコンピュータ読み取り可能な記録媒体。
【請求項１８】
前記コンピュータプログラムは、スケーラブルデータ信号を出力するエディタを有することを特徴とする、請求項１７に記載のコンピュータ読み取り可能な記録媒体。
【請求項１９】
前記リオーダリングユニットは、
（１）前記データユニットが伝送チャネルを介して、原データユニットの順序で、前記サーバから前記クライアントへ、前記データ信号の平均ビットレートに等しい十分な伝送速度でストリーミングされる場合、クライアント側での前記データ信号の十分な品質のストリーミング再生のためにクライアント側で必要とされるバッファ時間を計算し、
（２）前記データユニットが伝送チャネルを介して、原データユニットの順序で、前記サーバから前記クライアントへ、前記データ信号の平均ビットレートより低い低減された伝送速度でストリーミングされる場合、クライアント側での前記データ信号の低減された品質のストリーミング再生のためにクライアント側で必要とされるバッファ時間を計算し、
（３）前記データユニットのシーケンスにおいて１次データユニットが２次データユニットに先行されている場合、前記１次及び２次データユニットの位置は交換され、これにより、原データユニットの順序とは異なる修正データユニットの順序をもつリオーダリングされたデータを生成するように、前記データユニットのシーケンスの各１次データユニットの位置を、前記データユニットのシーケンスの先頭に向かってシフトさせ、
（４）前記データユニットは、前記伝送チャネルを介して、前記修正データユニットの順序で、前記サーバから前記クライアントへ、ストリーミングされると仮定して、クライアント側での前記データ信号の十分な品質のストリーミング再生のためにクライアント側で必要とされるバッファ時間を再計算し、
（５）前記データユニットは、前記伝送チャネルを介して、前記修正データユニットの順序で、前記サーバから前記クライアントへ、ストリーミングされると仮定して、クライアント側での前記データ信号の低減された品質の再生のためのバッファ時間を再計算し、
（６）前記クライアント側で前記データ信号の十分な品質のストリーミング再生のために必要とされるバッファ時間が、クライアント側で低減された品質のストリーミング再生のために必要とされるバッファ時間より大きいか又は等しくなるまで、前記データユニットのシーケンスの各１次データユニットの位置を、前記データユニットのシーケンスの先頭に向かってシフトさせるステップと、前記クライアント側で十分な品質および低減された品質のストリーミング再生のために必要とされるバッファ時間を再計算するステップとを繰り返すように配置されることを特徴とする請求項１に記載のサーバ。
【請求項２０】
前記リオーダリングユニットは、
（１）前記伝送チャネルは、前記データ信号の前記平均ビットレートに等しい一定の伝送レートを持つと仮定して、前記データ信号の最初のデータユニットが、クライアント側での再生を準備する時間を決定し、
（２）前記最初のデータユニットがクライアント側に間に合うように受信されて、スケジュールされた再生時間で再生されるかを判定するために、前記最初のデータユニットがクライアント側での再生を準備する時間と、最初のデータユニットのスケジュールされた再生時間とを比較する
（３）前記最初のデータユニットがクライアント側に遅れて受信されて、スケジュールされた再生時間で再生されることができない場合、前記最初のデータユニットが間に合うように受信されるように、前記バッファ時間を増やし、
（４）前記データ信号の各データユニットに対して前述のステップを繰り返すことによって、
前記クライアント側で前記データ信号の十分な品質のストリーミング再生のためのバッファ時間を計算するように配置されることを特徴とする請求項１９に記載のサーバ。
【請求項２１】
前記リオーダリングユニットは、
（１）前記伝送チャネルは、前記１次データユニットについての平均ビットレートに、前記２次データユニットについての平均ビットレートのあるパーセンテージを加えたものに等しい一定の伝送レートを持つと仮定して、前記データ信号の最初のデータユニットが、クライアント側での再生を準備する時間を決定し、
（２）前記最初のデータユニットがクライアント側に間に合うように受信されて、スケジュールされた再生時間で再生されるかを判定するために、前記最初のデータユニットがクライアント側での再生を準備する時間と、最初のデータユニットのスケジュールされた再生時間とを比較し、
（３）前記最初のデータユニットがクライアント側に遅れて受信されて、スケジュールされた再生時間で再生されることができない場合、前記最初のデータユニットが間に合うように受信されるように、前記バッファ時間を増やし、
（４）前記データ信号の各データユニットに対して前述のステップを繰り返すことによって、
前記クライアント側で前記データ信号の低減された品質のストリーミング再生のためのバッファ時間を計算するように配置されることを特徴とする請求項１９に記載のサーバ。
【請求項２２】
前記リオーダリングユニットは、前もって予期される低減チャネル伝送レートを推定するように配置されることを特徴とする請求項１に記載のサーバ。
【請求項２３】
前記リオーダリングユニットは、前記伝送チャネルの挙動から得られる統計値に基づいて予期される低減チャネル伝送レートを推定するように配置されることを特徴とする請求項１に記載のサーバ。
【請求項２４】
前記リオーダリングユニットは、前記データ信号をリオーダリングして、いくつかの代替伝送レートのためのリオーダリングされたデータ信号を生成するように配置されることを特徴とする請求項１に記載のサーバ。
【請求項２５】
前記リオーダリングユニットは、伝送が行われている最中に、前記データユニットのシーケンスを動的に調整するように配置されることを特徴とする請求項１に記載のサーバ。
【請求項２６】
前記リオーダリングユニットはさらに、前記１次および２次データユニットの順序を変更する以前に、前記１次データユニットのいくつかを、２次データユニットで置き換えるように配置されることを特徴とする請求項１に記載のサーバ。
【請求項２７】
前記リオーダリングユニットは、データ信号を送信するには不十分であるデータ伝送帯域幅をもつ伝送チャネルを介する伝送のために、データ信号の前記データユニットをリオーダするように配置されることを特徴とする請求項１に記載のサーバ。
【請求項２８】
前記リオーダリングユニットは、利用可能帯域幅のある部分を、他のデータの伝送に利用可能にするように、伝送チャネルを介してストリーミングするために、前記データ信号のデータユニットをリオーダするように配置されることを特徴とする請求項１に記載のサーバ。
【請求項２９】
前記データ信号は、ディジタルビデオ信号であり、一次データユニットは、ＩＮＴＲＡ符号化ＩフレームとＩＮＴＥＲ符号化Ｐフレームを含み、２次データユニットは、双方向予測Ｂフレームであることを特徴とする請求項１に記載のサーバ。
【請求項３０】
前記リオーダリングユニットは、前記データ信号をリオーダリングして、いくつかの代替伝送レートのためにリオーダリングされたデータ信号を生成し、前記データ伝送システムは、クライアント側でのストリーミング再生の中断によって問題が起こる場合、より低い伝送レートによりよく適合するリオーダリングされたデータ信号に切り替えるように配置されることを特徴とする請求項９に記載のデータ伝送システム。
【請求項３１】
前記データ伝送システムは、クライアント側での少なくとも１つの伝送及び再生の進捗をチェックするように配置され、前記リオーダリングユニットは、伝送が行われている最中に、前記データユニットのシーケンスを動的に調整するように配置されることを特徴とする請求項９に記載のデータ伝送システム。
【請求項３２】
（１）前記データユニットが伝送チャネルを介して、原データユニットの順序で、前記サーバから前記クライアントへ、前記データ信号の平均ビットレートに等しい十分な伝送速度でストリーミングされる場合、クライアント側での前記データ信号の十分な品質のストリーミング再生のためにクライアント側で必要とされるバッファ時間を計算し、
（２）前記データユニットが伝送チャネルを介して、原データユニットの順序で、前記サーバから前記クライアントへ、前記データ信号の平均ビットレートより低い低減された伝送速度でストリーミングされる場合、クライアント側での前記データ信号の低減された品質のストリーミング再生のためにクライアント側で必要とされるバッファ時間を計算し、
（３）前記データユニットのシーケンスにおいて１次データユニットが２次データユニットに先行されている場合、前記１次及び２次データユニットの位置は交換され、これにより、原データユニットの順序とは異なる修正データユニットの順序をもつリオーダリングされたデータを生成するように、前記データユニットのシーケンスの各１次データユニットの位置を、前記データユニットのシーケンスの先頭に向かってシフトさせ、
（４）前記データユニットは、前記伝送チャネルを介して、前記修正データユニットの順序で、前記サーバから前記クライアントへ、ストリーミングされると仮定して、クライアント側での前記データ信号の十分な品質のストリーミング再生のためにクライアント側で必要とされるバッファ時間を再計算し、
（５）前記データユニットは、前記伝送チャネルを介して、前記修正データユニットの順序で、前記サーバから前記クライアントへ、ストリーミングされると仮定して、クライアント側での前記データ信号の低減されたストリーミング品質の再生のためのバッファ時間を再計算し、
（６）前記クライアント側で前記データ信号の十分な品質のストリーミング再生のために必要とされるバッファ時間が、クライアント側で低減された品質のストリーミング再生のために必要とされるバッファ時間より大きいか又は等しくなるまで、前記データユニットのシーケンスの各１次データユニットの位置を、前記データユニットのシーケンスの先頭に向かってシフトさせるステップと、前記クライアント側で十分な品質および低減された品質のストリーミング再生のために必要とされるバッファ時間を再計算するステップとを繰り返す
ことを特徴とする請求項１４に記載のデータ信号ストリーミング方法。
【請求項３３】
（１）前記伝送チャネルは、前記データ信号の前記平均ビットレートに等しい一定の伝送レートを持つと仮定して、前記データ信号の最初のデータユニットが、クライアント側での再生を準備する時間を決定し、
（２）前記最初のデータユニットがクライアント側に間に合うように受信されて、スケジュールされた再生時間で再生されるかを判定するために、前記最初のデータユニットがクライアント側での再生を準備する時間と、最初のデータユニットのスケジュールされた再生時間とを比較する
（３）前記最初のデータユニットがクライアント側に遅れて受信されて、スケジュールされた再生時間で再生されることができない場合、前記最初のデータユニットが間に合うように受信されるように、前記バッファ時間を増やし、
（４）前記データ信号の各データユニットに対して前述のステップを繰り返すことによって、
前記クライアント側で前記データ信号の十分な品質のストリーミング再生のためのバッファ時間が計算される
ことを特徴とする請求項３２に記載のデータ信号ストリーミング方法。
【請求項３４】
（１）前記伝送チャネルは、前記１次データユニットについての平均ビットレートに、前記２次データユニットについての平均ビットレートのあるパーセンテージを加えたものに等しい一定の伝送レートを持つと仮定して、前記データ信号の最初のデータユニットが、クライアント側での再生を準備する時間を決定し、
（２）前記最初のデータユニットがクライアント側に間に合うように受信されて、スケジュールされた再生時間で再生されるかを判定するために、前記最初のデータユニットがクライアント側での再生を準備する時間と、最初のデータユニットのスケジュールされた再生時間とを比較し、
（３）前記最初のデータユニットがクライアント側に遅れて受信されて、スケジュールされた再生時間で再生されることができない場合、前記最初のデータユニットが間に合うように受信されるように、前記バッファ時間を増やし、
（４）前記データ信号の各データユニットに対して前述のステップを繰り返すことによって、
前記クライアント側で前記データ信号の低減された品質のストリーミング再生のためのバッファ時間を計算するように配置されることを特徴とする請求項３２に記載のデータ信号ストリーミング方法。
【請求項３５】
前もって予期される低減チャネル伝送レートを推定することを含むことを特徴とする請求項１４に記載のデータ信号ストリーミング方法。
【請求項３６】
前記伝送チャネルの挙動から得られる統計値に基づいて予期される低減チャネル伝送レートを推定することを含むことを特徴とする請求項１４に記載のデータ信号ストリーミング方法。
【請求項３７】
前記データ信号をリオーダリングして、いくつかの代替伝送レートのためのリオーダリングされたデータ信号を生成し、
前記クライアント側でストリーイング再生中の中断によって、問題が生じる場合、より低いビットレートにより適合したリオーダリングされたデータ信号に切り替えることを含むことを特徴とする請求項１４に記載のデータ信号ストリーミング方法。
【請求項３８】
前記クライアント側での少なくとも１つの伝送及び再生の進捗をチェックし、伝送が行われている最中に、前記データユニットのシーケンスを動的に調整することを含むことを特徴とする請求項１４に記載のデータ信号ストリーミング方法。
【請求項３９】
前記１次および２次データユニットの順序を変更する以前に、前記１次データユニットのいくつかを、２次データユニットで置き換えることを含むことを特徴とする請求項１４に記載のデータ信号ストリーミング方法。
【請求項４０】
データ信号を送信するには不十分であるデータ伝送帯域幅をもつ伝送チャネルを介する伝送のために、データ信号の前記データユニットをリオーダする方法を適用することを含むことを特徴とする請求項１４に記載のデータ信号ストリーミング方法。
【請求項４１】
前記リオーダリングユニットは、利用可能帯域幅のある部分を、他のデータの伝送に利用可能にするように、伝送チャネルを介してストリーミングするために、前記データ信号のデータユニットをリオーダする方法を適用することを含むことを特徴とする請求項１４に記載のデータ信号ストリーミング方法。
【請求項４２】
前記データ信号は、ディジタルビデオ信号であり、一次データユニットは、ＩＮＴＲＡ符号化ＩフレームとＩＮＴＥＲ符号化Ｐフレームを含み、２次データユニットは、双方向予測Ｂフレームであることを特徴とする請求項１４に記載のデータ信号ストリーミング方法。
【請求項４３】
前記データ信号は、バースレイヤと少なくとも１つのエンハンスメントレイヤを有するスケーラブルデータ信号であることを特徴とする請求項１４に記載のデータ信号ストリーミング方法。
【請求項４４】
前記データ信号は、時間的領域、空間的領域、スペクトル領域およびＳＮＲ領域からなるグループから選択された領域で、スケーラブルであることを特徴とする請求項４３に記載のデータ信号ストリーミング方法。
【請求項４５】
コンピュータプログラムが記録されたコンピュータ読み取り可能な記録媒体であって、
該コンピュータプログラムは、
（１）前記データユニットが伝送チャネルを介して、原データユニットの順序で、前記サーバから前記クライアントへ、前記データ信号の平均ビットレートに等しい十分な伝送速度でストリーミングされる場合、クライアント側での前記データ信号の十分な品質のストリーミング再生のためにクライアント側で必要とされるバッファ時間を計算するプログラムと、
（２）前記データユニットが伝送チャネルを介して、原データユニットの順序で、前記サーバから前記クライアントへ、前記データ信号の平均ビットレートより低い低減された伝送速度でストリーミングされる場合、クライアント側での前記データ信号の低減された品質のストリーミング再生のためにクライアント側で必要とされるバッファ時間を計算するプログラムと、
（３）前記データユニットのシーケンスにおいて１次データユニットが２次データユニットに先行されている場合、前記１次及び２次データユニットの位置は交換され、これにより、原データユニットの順序とは異なる修正データユニットの順序をもつリオーダリングされたデータを生成するように、前記データユニットのシーケンスの各１次データユニットの位置を、前記データユニットのシーケンスの先頭に向かってシフトさせるプログラムと、
（４）前記データユニットは、前記伝送チャネルを介して、前記修正データユニットの順序で、前記サーバから前記クライアントへ、ストリーミングされると仮定して、クライアント側での前記データ信号の十分な品質のストリーミング再生のためにクライアント側で必要とされるバッファ時間を再計算するプログラムと、
（５）前記データユニットは、前記伝送チャネルを介して、前記修正データユニットの順序で、前記サーバから前記クライアントへ、ストリーミングされると仮定して、クライアント側での前記データ信号の低減されたストリーミング品質の再生のためのバッファ時間を再計算するプログラムと、
（６）前記クライアント側で前記データ信号の十分な品質のストリーミング再生のために必要とされるバッファ時間が、クライアント側で低減された品質のストリーミング再生のために必要とされるバッファ時間より大きいか又は等しくなるまで、前記データユニットのシーケンスの各１次データユニットの位置を、前記データユニットのシーケンスの先頭に向かってシフトさせるステップと、前記クライアント側で十分な品質および低減された品質のストリーミング再生のために必要とされるバッファ時間を再計算するステップとを繰り返すプログラムと
を含むことを特徴とする請求項１７に記載のコンピュータ読み取り可能な記録媒体。
【請求項４６】
（１）前記伝送チャネルは、前記データ信号の前記平均ビットレートに等しい一定の伝送レートを持つと仮定して、前記データ信号の最初のデータユニットが、クライアント側での再生を準備する時間を決定し、
（２）前記最初のデータユニットがクライアント側に間に合うように受信されて、スケジュールされた再生時間で再生されるかを判定するために、前記最初のデータユニットがクライアント側での再生を準備する時間と、最初のデータユニットのスケジュールされた再生時間とを比較し、
（３）前記最初のデータユニットがクライアント側に遅れて受信されて、スケジュールされた再生時間で再生されることができない場合、前記最初のデータユニットが間に合うように受信されるように、前記バッファ時間を増やし、
（４）前記データ信号の各データユニットに対して前述のステップを繰り返すことによって、
前記クライアント側で前記データ信号の十分な品質のストリーミング再生のためのバッファ時間を計算するプログラムを、さらに含むことを特徴とする請求項４５に記載のコンピュータ読み取り可能な記録媒体。
【請求項４７】
（１）前記伝送チャネルは、前記１次データユニットについての平均ビットレートに、前記２次データユニットについての平均ビットレートのあるパーセンテージを加えたものに等しい一定の伝送レートを持つと仮定して、前記データ信号の最初のデータユニットが、クライアント側での再生を準備する時間を決定し、
（２）前記最初のデータユニットがクライアント側に間に合うように受信されて、スケジュールされた再生時間で再生されるかを判定するために、前記最初のデータユニットがクライアント側での再生を準備する時間と、最初のデータユニットのスケジュールされた再生時間とを比較し、
（３）前記最初のデータユニットがクライアント側に遅れて受信されて、スケジュールされた再生時間で再生されることができない場合、前記最初のデータユニットが間に合うように受信されるように、前記バッファ時間を増やし、
（４）前記データ信号の各データユニットに対して前述のステップを繰り返すことによって、
前記クライアント側で前記データ信号の低減された品質のストリーミング再生のためのバッファ時間を計算するプログラムを、さらに含むことを特徴とする請求項４５に記載のコンピュータ読み取り可能な記録媒体。
【請求項４８】
前もって予期される低減チャネル伝送レートを推定するプログラムを含むことを特徴とする請求項１７に記載のコンピュータ読み取り可能な記録媒体。
【請求項４９】
前記伝送チャネルの挙動から得られる統計値に基づいて予期される低減チャネル伝送レートを推定することを含むことを特徴とする請求項１７に記載のコンピュータ読み取り可能な記録媒体。
【請求項５０】
前記データ信号をリオーダリングして、いくつかの代替伝送レートのためのリオーダリングされたデータ信号を生成するプログラムと、
前記クライアント側でストリーイング再生中の中断によって、問題が生じる場合、より低いビットレートにより適合したリオーダリングされたデータ信号に切り替えるプログラムとを
含むことを特徴とする請求項１７に記載のコンピュータ読み取り可能な記録媒体。
【請求項５１】
前記クライアント側で、伝送の進捗をチェックするプログラムと再生の進捗をチェックするプログラムの少なくとも１つのプログラムと、
伝送が行われている最中に、前記データユニットのシーケンスを動的に調整するプログラムを含むことを特徴とする請求項１７に記載のコンピュータ読み取り可能な記録媒体。
【請求項５２】
前記１次および２次データユニットの順序を変更する以前に、前記１次データユニットのいくつかを、２次データユニットで置き換えるプログラムを含むことを特徴とする請求項１７に記載のコンピュータ読み取り可能な記録媒体。
【請求項５３】
前記１次及び２次データユニットの順序を変更する前記コンピュータプログラムは、データ信号を送信するには不十分であるデータ伝送帯域幅をもつ伝送チャネルを介する伝送のために、データ信号の前記データユニットをリオーダするようにされていることを特徴とする請求項１７に記載のコンピュータ読み取り可能な記録媒体。
【請求項５４】
前記１次及び２次データユニットの順序を変更する前記コンピュータプログラムは、利用可能帯域幅のある部分を、他のデータの伝送に利用可能にするように、伝送チャネルを介してストリーミングする前記データ信号のデータユニットをリオーダするようにされていることを特徴とする請求項１７に記載のコンピュータ読み取り可能な記録媒体。
【請求項５５】
クライアント側での再生のために、サーバから前記クライアントに伝送チャネルを介してストリーミングするためのデータ信号をリオーダするリオーダリング装置であって、前記データ信号は、１次データユニットと２次データユニットを含むデータユニットのシーケンスを含み、前記１次及び２次データユニットは、前記クライアント側でのストリーミング再生のためのスケジュールされた再生時間を有し、前記１次及び２次データユニットは、原データユニットの順序に従って、前記データ信号において順序づけられており、前記リオーダリング装置は、原データユニットの順序では１次データユニットに先行する２次データユニットを、該１次データユニットと交換することにより、データユニットのシーケンスにおける前記１次および２次データユニットの順序を変更して、前記データユニットのシーケンスにおいて、前記１次データユニットが前記２次データユニットに先行する、修正されたデータユニットの順序をもつリオーダされたデータ信号を生成し、これにより、クライアント側でのストリーミング再生中、スケジュールされた再生時間で再生されるように、１次データユニットがクライアント側で時間どおりに受信される可能性を増大させることを特徴とするリオーダリング装置。
【請求項５６】
前記リオーダリング装置は、
（１）前記データユニットが伝送チャネルを介して、原データユニットの順序で、前記サーバから前記クライアントへ、前記データ信号の平均ビットレートに等しい十分な伝送速度でストリーミングされる場合、クライアント側での前記データ信号の十分な品質のストリーミング再生のためにクライアント側で必要とされるバッファ時間を計算し、
（２）前記データユニットが伝送チャネルを介して、原データユニットの順序で、前記サーバから前記クライアントへ、前記データ信号の平均ビットレートより低い低減された伝送速度でストリーミングされる場合、クライアント側での前記データ信号の低減された品質のストリーミング再生のためにクライアント側で必要とされるバッファ時間を計算し、
（３）前記データユニットのシーケンスにおいて１次データユニットが２次データユニットに先行されている場合、前記１次及び２次データユニットの位置は交換され、これにより、原データユニットの順序とは異なる修正データユニットの順序をもつリオーダリングされたデータを生成するように、前記データユニットのシーケンスの各１次データユニットの位置を、前記データユニットのシーケンスの先頭に向かってシフトさせ、
（４）前記データユニットは、前記伝送チャネルを介して、前記修正データユニットの順序で、前記サーバから前記クライアントへ、ストリーミングされると仮定して、クライアント側での前記データ信号の十分な品質のストリーミング再生のためにクライアント側で必要とされるバッファ時間を再計算し、
（５）前記データユニットは、前記伝送チャネルを介して、前記修正データユニットの順序で、前記サーバから前記クライアントへ、ストリーミングされると仮定して、クライアント側での前記データ信号の低減された品質の再生のためのバッファ時間を再計算し、
（６）前記クライアント側で前記データ信号の十分な品質のストリーミング再生のために必要とされるバッファ時間が、クライアント側で低減された品質のストリーミング再生のために必要とされるバッファ時間より大きいか又は等しくなるまで、前記データユニットのシーケンスの各１次データユニットの位置を、前記データユニットのシーケンスの先頭に向かってシフトさせるステップと、前記クライアント側で十分な品質および低減された品質のストリーミング再生のために必要とされるバッファ時間を再計算するステップとを繰り返すように配置されることを特徴とする請求項５５に記載のリオーダリング装置。
【請求項５７】
前記リオーダリング装置は、
（１）前記伝送チャネルは、前記データ信号の前記平均ビットレートに等しい一定の伝送レートを持つと仮定して、前記データ信号の最初のデータユニットが、クライアント側での再生を準備する時間を決定し、
（２）前記最初のデータユニットがクライアント側に間に合うように受信されて、スケジュールされた再生時間で再生されるかを判定するために、前記最初のデータユニットがクライアント側での再生を準備する時間と、最初のデータユニットのスケジュールされた再生時間とを比較する
（３）前記最初のデータユニットがクライアント側に遅れて受信されて、スケジュールされた再生時間で再生されることができない場合、前記最初のデータユニットが間に合うように受信されるように、前記バッファ時間を増やし、
（４）前記データ信号の各データユニットに対して前述のステップを繰り返すことによって、
前記クライアント側で前記データ信号の十分な品質のストリーミング再生のためのバッファ時間を計算するように配置されることを特徴とする請求項５６に記載のリオーダリング装置。
【請求項５８】
前記リオーダリング装置は、
（１）前記伝送チャネルは、前記１次データユニットについての平均ビットレートに、前記２次データユニットについての平均ビットレートのあるパーセンテージを加えたものに等しい一定の伝送レートを持つと仮定して、前記データ信号の最初のデータユニットが、クライアント側での再生を準備する時間を決定し、
（２）前記最初のデータユニットがクライアント側に間に合うように受信されて、スケジュールされた再生時間で再生されるかを判定するために、前記最初のデータユニットがクライアント側での再生を準備する時間と、最初のデータユニットのスケジュールされた再生時間とを比較し、
（３）前記最初のデータユニットがクライアント側に遅れて受信されて、スケジュールされた再生時間で再生されることができない場合、前記最初のデータユニットが間に合うように受信されるように、前記バッファ時間を増やし、
（４）前記データ信号の各データユニットに対して前述のステップを繰り返すことによって、
前記クライアント側で前記データ信号の低減された品質のストリーミング再生のためのバッファ時間を計算するように配置されることを特徴とする請求項５６に記載のリオーダリング装置。
【請求項５９】
前記リオーダリング装置は、前もって予期される低減チャネル伝送レートを推定するように配置されていることを特徴とする請求項５５に記載のリオーダリング装置。
【請求項６０】
前記リオーダリング装置は、前記伝送チャネルの挙動から得られる統計値に基づいて予期される低減チャネル伝送レートを推定するように配置されることを特徴とする請求項５５に記載のリオーダリング装置。
【請求項６１】
前記リオーダリング装置は、前記データ信号をリオーダリングして、いくつかの代替伝送レートのためのリオーダリングされたデータ信号を生成するように配置されることを特徴とする請求項５５に記載のリオーダリング装置。
【請求項６２】
前記リオーダリング装置は、伝送が行われている最中に、前記データユニットのシーケンスを動的に調整するように配置されることを特徴とする請求項５５に記載のリオーダリング装置。
【請求項６３】
前記リオーダリング装置は、データ信号を送信するには不十分であるデータ伝送帯域幅をもつ伝送チャネルを介する伝送のために、データ信号の前記データユニットをリオーダするように配置されることを特徴とする請求項５５に記載のリオーダリング装置。
【請求項６４】
前記リオーダリング装置は、利用可能帯域幅のある部分を、他のデータの伝送に利用可能にするように、伝送チャネルを介してストリーミングするために、前記データ信号のデータユニットをリオーダするように配置されることを特徴とする請求項５５に記載のリオーダリング装置。
【請求項６５】
クライアント装置でのストリーミング再生のためにデータ信号を受信するクライアント装置であって、前記データ信号は、１次データユニットと２次データユニットを含むデータユニットのシーケンスを含み、前記１次及び２次データユニットは、前記クライアント装置でのストリーミング再生のためのスケジュールされた再生時間を有し、原データユニットの順序では１次データユニットに先行する２次データユニットを、該１次データユニットと交換し、原データユニットの順序について、前記データユニットのシーケンスにおける前記１次及び２次データユニットの順序を変更して、前記データユニットのシーケンスにおいて、前記１次データユニットが前記２次データユニットに先行する、修正されたデータユニットの順序をもつリオーダされたデータ信号を生成するようにして、これにより、１次データユニットがクライアント側で時間通りに受信され、クライアント側でのストリーミング再生中、スケジュールされた再生時間で再生される可能性を増大させ、前記クライアント装置は、前記１次及び２次データユニットを、修正されたデータユニットの順序で受信し、前記１次及び２次データユニットを、原データユニットの順序に戻すように配置されたことを特徴とするクライアント装置。
【請求項６６】
ストリーミング再生のためにデータ信号を受信する方法であって、
前記データ信号は、１次データユニットと２次データユニットを含むデータユニットのシーケンスを含み、前記１次及び２次データユニットは、クライアント側でのストリーミング再生のためのスケジュールされた再生時間を有し、原データユニットの順序では１次データユニットに先行する２次データユニットを、該１次データユニットと交換し、原データユニットの順序について、前記データユニットのシーケンスにおける前記１次及び２次データユニットの順序を変更して、前記データユニットのシーケンスにおいて、前記１次データユニットが前記２次データユニットに先行する、修正されたデータユニットの順序をもつリオーダされたデータ信号を生成するようにして、これにより、１次データユニットがクライアント側で時間通りに受信され、クライアント側でのストリーミング再生中、スケジュールされた再生時間で再生される可能性を増大させ、前記方法は、前記１次及び２次データユニットを、修正されたデータユニットの順序で受信し、前記１次及び２次データユニットを、原データユニットの順序に戻すことを含むことを特徴とする方法。
【発明の詳細な説明】
【０００１】
本発明はデータ伝送に関し、他のものを排除するものではないが、特に、ビデオ等のピクチャ列を表すデータの伝送に関する。本発明は、エラーやデータ損失を受けやすいリンクを介する伝送にとって特に好適である。
【０００２】
過去数年の間、インターネットを通じて入手可能なマルチメディア・コンテンツの量は著しく増加している。移動端末装置によるマルチメディア・コンテンツを取り出す（retrieve）ことが可能になるほど移動端末装置へのデータ転送（delivery）レートが高速になりつつあることに起因して、移動端末装置によってインターネットからビデオや他のマルチメディア・コンテンツを取り出せるようになることが望まれている。高速データ転送システムの一例として近い将来出現するＧＳＭフェーズ２＋がある。
【０００３】
本明細書で使用するマルチメディアという用語は音とピクチャの双方及び音のみ及びピクチャのみに対して適用される。音には音声と音楽とを含むことができる。
【０００４】
インターネットを介するネットワーク・トラフィックは、インターネット・プロトコル(ＩＰ)と呼ばれるトランスポート・プロトコルに基づいている。ＩＰは１つのロケーションから別のロケーションへのデータ・パケットのトランスポートに関係する。ＩＰによって、中間ゲートウェイを通るパケットのルート選定が容易になる。すなわち、ＩＰによって、同じ物理ネットワーク内で直接接続されていないマシーンへのデータの送信が可能になる。ＩＰ層によってトランスポートされるデータの単位はＩＰデータグラムと呼ばれる。ＩＰによって提供される転送サービスはコネクションレス形である。すなわち、ＩＰデータグラムの経路選定はインターネットの中で相互に独立に行われる。どのようなリソースもゲートウェイ内でいずれかの特定の接続に永久的に委ねられていないために、バッファ空間やその他のリソース不足に起因して、ゲートウェイが時折データグラムを破棄しなければならなくなることがある。したがって、ＩＰによって提供される転送サービスは、保証されたサービスではなく最善の働きによるサービスである。
【０００５】
インターネット・マルチメディアは、一般に、ユーザー・データグラム・プロトコル(ＵＤＰ)、伝送制御プロトコル(ＴＣＰ)あるいはハイパー・テキスト転送プロトコル(ＨＴＴＰ)を介して流れている。
【０００６】
ＵＤＰはコネクションレス型軽量（lightweight)トランスポート・プロトコルである。ＵＤＰはＩＰによって提供されるサービス以上のサービスをほとんど提供しない。ＵＤＰの最も重要な機能は特定のトランスポート・エンドポイント間でのデータグラムの転送である。したがって送信用アプリケーションはデータグラムに合わせたデータのパケット化方法の処理を行わなければならない。ＵＤＰ内で使用されるヘッダには、データの有効性を受信端のＵＤＰレイヤがチェックできるチェックサムが含まれる。これとは別に、ＵＤＰデータグラムはＩＰデータグラムの劣化による影響を受ける。ＵＤＰは、データグラムが受信されたかどうかのチェックを行わず、紛失データグラムの再送を行わず、また、データグラムが伝送されたときと同順での受信を保証するものではない。
【０００７】
再送が行われないので、遅延の少ない比較的安定したスループットがＵＤＰによって導入される。したがって、ＵＤＰは、ネットワークの輻輳状態の影響を処理し、受信端での遅延(及びジッタ)を少なくする修正用（retrieval)アプリケーションで用いられる。しかし、クライアントは、パケット損失から復元し、紛失コンテンツをできるだけコンシールしなければならない。復元とコンシールメントを行う場合でさえ、復元されるクリップの品質は多少の損害を被る。一方、クリップの再生はうるさい中断なしでリアルタイムで行われることがある。ＵＤＰがコネクションレス形であるという理由で、企業内であれ、その他の場所であれ、ファイア・ウォールによってＵＤＰの使用が禁止される場合がある。
【０００８】
ＴＣＰは接続指向型トランスポート・プロトコルであり、このプロトコルを使用するアプリケーションでは、ＵＤＰの場合のような明白な境界がない一続きのバイトの送信や受信を行うことができる。ＴＣＰレイヤは、バイトから成るストリームをパケットに分割し、ＩＰネットワークを介してこのパケットを送信し、パケットにエラーがなく、パケットがその正しい順序で受信されたことを保証する。ＴＣＰの機能についての基本的考えは以下の通りである。ＴＣＰは、データ・パケットを送信する度にタイマーを始動させる。受信端は、パケットを受信すると即座に送り手へ確認応答を返送する。確認応答を受信して、送り手はすべてが良好であることを認知すると、タイマーを取り消す。しかし、ＩＰレイヤが送出セグメントや返信の確認応答を失った場合、送信端のタイマーは終了する。この時点で送り手はセグメントの再送を行う。この場合、送り手が、次のパケットを送信するまで各パケットに対する確認応答を待っている場合、伝送時間全体は送り手と受け手との間の往復の遅延に対応して比較的長いものになる。この問題を解決するために、ＴＣＰでは、ネットワークに、いくつかの未確認のパケットが存在することを許容するスライディング・ウィンドウ・プロトコルが利用される。このプロトコルでは、確認応答パケットには、クライアントが進んで承認する(現在確認応答が行われているバイト以上の)複数のバイトによって満たされるフィールドが含まれる。このウインドウ・サイズ・フィールドは、到来データを保存するためにクライアント側で利用可能なバッファ・スペースの量を示す。送り手は、最新の受信ウインドウ・サイズ・フィールドによって指示される限度内のデータを伝送することができる。スライディング・ウィンドウ・プロトコルは、ＴＣＰが実際上スロースタート・メカニズムを有することを意味する。接続開始時に、送り手が次のパケットを送らないうちに一番最初のパケットの確認応答が行われなければならない。一般にこの時クライアントはウインドウ・サイズを指数的に増加させる。しかし、ネットワーク内で輻輳状態が生じた場合、(輻輳状態を回避し、バッファ・オーバーフローの受信を回避するために)ウインドウ・サイズは減少する。ウインドウ・サイズがどのように変化するかについての詳細は使用中の特定のＴＣＰの構成に依存する。
【０００９】
マルチメディア・コンテンツ作成／修正システムが図１に図示されている。このシステムはカメラやマイクなどの１以上のメディア・ソースを有する。或いは、自然のメディア・ソースを用いずに、アニメーション・コンピュータ・グラフィックやデジタルで作成された音楽などの合成によるマルチメディア・コンテンツの作成も可能である。ビデオ、オーディオ、テキスト、画像、グラフィック及びアニメーションなどの様々なメディア・タイプから成るマルチメディア・クリップを構成するために、ソースから取得された生データがエディタによって編集される。一般に、生の(未圧縮の)マルチメディア・データによって占められる記憶空間は膨大なものになる。アニメーションなどの様々なメディアの混合物を含むことが可能なビデオ・シーケンスの場合、この記憶空間はメガバイトになる場合もある。２８.８ｋｂｐｓや５６ｋｂｐｓなどの低いビットレート・チャネルを介して魅力的なマルチメディア検索サービスを提供するために、マルチメディア・クリップは編集段階内で圧縮される。これは一般にオフラインで行われる。次いで、これらのクリップはマルチメディア・サーバへ渡される。一般に、幾人かのクライアントが１以上のネットワークを介してサーバにアクセスすることが可能である。サーバはクライアントが示す要求に対して応答することができる。サーバの主要タスクは所望のマルチメディア・クリップをクライアントへ伝送することであり、クライアントはこのクリップを解凍して、再生する。再生中、クライアントはスクリーンやスピーカー等の１以上の出力装置を利用する。状況によっては、データがまだダウンロードされている最中にクライアントは再生を始めることができる。
【００１０】
クリップ全体に同様のサービス品質を提供する単一のチャネルを用いてクリップの転送ができれば便利である。或いは、例えば１つのチャネルで音、別のチャネルでピクチャなどのように、異なるチャネルを用いて１つのクリップの異なる部分の転送を行うことも可能である。異なるチャネルによって、異なる品質のサービスの提供を行うことも可能である。これに関連して、サービス品質には、ビットレート、損失あるいはビットエラーレート及び伝送遅延の変動が含まれる。
【００１１】
十分な品質のマルチメディア・コンテンツの転送を保証するために、マルチメディア・コンテンツは、ＴＣＰ等の信頼性の高いネットワーク接続を介して提供され、この接続によって、受信データにエラーがなく、受信データが正しい順序であることが保証される。紛失したり、破損したプロトコル・データ単位は再送される。したがって、チャネル・スループットが著しく変動する可能性がある。この変動に起因して、紛失データや破損データの再転送中、マルチメディア・ストリームの再生時に中断することさえある。マルチメディア再生中の中断は人をイライラさせるものである。
【００１２】
紛失データの再送がトランスポート・プロトコルによって処理されずに、或る上位プロトコルによって処理されることが時として生じる。このようなプロトコルはマルチメディア・ストリームの最も重要な部分を選択し、その部分の再送を要求することができる。例えば、この最重要部分を用いてストリームの他の部分の予測が可能となる。
【００１３】
本発明をより良く理解するために、修正システムのエレメント(すなわちエディタ、サーバ、クライアント)についての説明を以下行う。
【００１４】
マルチメディア・クリップ・エディタによって行われる典型的な一続きのオペレーションが図２に示されている。生データが１以上のデータ・ソースから取り込まれる。この取込みは、ハードウェアと、そのハードウェア専用のデバイス・ドライバと、ハードウェアを使用するためのデバイス・ドライバを制御する取込み用アプリケーションとを用いて行われる。例えば、取込み用ハードウェアは、ＰＣ用ビデオ・グラバ(video grabber)カードと接続されたビデオカメラから構成されるものであってもよい。取込み段の出力は、通常、未圧縮データか、未圧縮データと比較して無関係の品質劣化を伴うわずかに圧縮されたデータのいずれかである。例えば、ビデオ・グラバ・カードの出力は、未圧縮のＹＵＶ４:２:０フォーマットもしくはモーションＪＰＥＧフォーマットのいずれかとすることができる。ＹＵＶカラー・モデルと可能なサブサンプリング方式が、勧告ＩＴＵ−Ｒ  ＢＴ.６０１-５“標準４:３及びワイドスクリーン１６:９横縦比用デジタルテレビのスタジオ符号化パラメータ”に定義されている。ＣＩＦ、ＱＣＩＦＳ及びＱＣＩＦ等の関連するデジタル・ピクチャ・フォーマットが、勧告ＩＴＵ−Ｔ  Ｈ.２６１“ｐ×６４ｋｂｉｔオーディオ・ビジュアルサービス用ビデオ・コーデック”(セクション３.１“ソース・フォーマット”)に定義されている。
【００１５】
編集中、別個のメディア・トラックが単一のタイムラインでまとめて結びつけられる。例えば、ビデオ・フレーム率を下げるために、様々な方法でメディア・トラックの編集を行うことも可能である。各メディア・トラックの圧縮が行われる場合もある。例えば、低ビットレートのビデオ符号化を行うためにＩＴＵ−Ｔ勧告Ｈ.２６３によって未圧縮のＹＵＶ４:２:０ビデオ・トラックの圧縮を行うこともできる。これらの圧縮されたメディア・トラックは、多重化される場合、単一のビット・ストリームを形成するためにインターリーブされる。次いで、このクリップはマルチメディア・サーバへ渡される。多重化はビット・ストリームの出力にとって本質的なものではない。例えば、パケット・ヘッダ情報を用いて、トランスポート層の中で音と画像等の異なるメディア構成要素の識別を行うことができる。異なるメディア構成要素に対して異なるＵＤＰポート番号の使用が可能である。
【００１６】
マルチメディア・サーバによって行われる典型的な一続きのオペレーションが図３に示されている。一般に、マルチメディア・サーバは、２つのモードのオペレーションを有する。すなわち、マルチメディア・サーバは、予め格納されたマルチメディア・クリップか、ライブの(リアルタイムの)マルチメディア・ストリームのいずれかの転送を行う。第１のモードでは、クリップはサーバ・データベースの中に格納され、次いで、該サーバ・データベースは要求がありしだいサーバによってアクセスされる。第２のモードでは、マルチメディア・クリップは連続したメディア・ストリームとしてサーバへ渡され、該メディア・ストリームはクライアントへ即座に伝送される。クライアントは、少なくとも所望のメディア・クリップを選択できる適切な制御プロトコルによってサーバのオペレーションを制御する。さらに、サーバは、より高度の制御をサポートすることができる。例えば、クライアントは、クリップの伝送停止、クリップの伝送中止と再開が可能で、また、伝送チャネルのスループットを変化させ、サーバが利用可能な帯域幅にぴったり合うようにビット・ストリームをダイナミックに調整しなければならない場合、メディア・フローの制御を行うことができる。
【００１７】
マルチメディア修正クライアントによって行われる典型的な一続きのオペレーションが図４に示されている。クライアントは、圧縮され、多重化されたメディア・クリップをマルチメディア・サーバから取得する。クライアントは、個々のメディア・トラックを得るためにクリップの多重分離を行う。次いで、これらのメディア・トラックは解凍され、復元されたメディア・トラックが提供され、これらのメディア・トラックは出力装置によって再生される。これらのオペレーションに加えて、エンドユーザーとインターフェースを行うための制御ユニットが設けられる。すなわち、エンドユーザーの入力に従って再生が制御され、クライアント・サーバ制御トラフィックの処理が行われる。クリップの後続部分がまだダウンロードされている間、クリップの第１の部分で多重分離−解凍−再生チェーンを行うことが可能であることに留意されたい。これは一般にストリーミングと呼ばれる。ストリーミングの代替として、クリップ全体をクライアントに対してダウンロードし、次いで、それを多重分離し、解凍して再生する方法がある。
【００１８】
チャネルのスループットが変動する問題に対する典型的アプローチは、再生を開始する前にクライアント側のメディア・データをバッファすること、及び／又は、チャネル・スループット統計に従ってリアルタイムで伝送されたビットレートの調整を行うことである。
【００１９】
中断という問題に取り組む１つの方法として、マルチメディア・サーバ内でのダイナミックなビットレート調整を利用する方法がある。しかし、サーバがネットワークの輻輳状態に対して十分迅速に反応せず、クライアント側での中断を回避できない場合もある。さらに、サーバはＴＣＰ(あるいはＩＰ等の他の下位に在るプロトコル)の再送メカニズムを制御することができない。
【００２０】
たとえダイナミックなビットレートの調整が行われたとしても、いずれにせよクライアントは初期バッファリングを行って、再送によって生じた転送遅延の回避を図るようにしなければならない。一定のチャネル・ビットレートが想定されている場合、１つのデータ単位が完全に受信されたと想定される時点の計算が可能である。さらに、データ単位の再生が完了する時点の計算が可能である。これらの２つの時点間の時間差はセイフティ・タイムと呼ばれる。セイフティ・タイムを定義する別の方法として、セイフティ・タイムは、再生時に中断が生じない２つの連続して受信されたデータ単位間の最大時間であるということができる。
【００２１】
あるクリップのセイフティ・タイムを計算する場合、各データユニットを別個のものとして考えなければならない。セイフティ・タイムの計算では、現在処理されているデータユニットの前にスループットの低下が生じないことが仮定されている。チャネルの最大スループットがマルチメディア・クリップの平均ビットレートに等しい場合、スループットの低下後クライアントは受信ビット量の低下から回復することはできない。スループットに対する何らかの保護を保証する唯一の方法は、再生を開始する前にあるデータのバッファを行うことである。チャネルがデータの供給を停止した場合、バッファ内にデータが存在する間、クライアントはストリームをそのまま再生することができる。したがって、平均セイフティ・タイムは初期バッファ時間にほぼ等しくなる。クリップのビットレートが変動する可能性があるため、セイフティ・タイムもまた変動する可能性があり、したがって、最少セイフティ・タイムは初期バッファの遅延と等しいか、それ以下になる。
【００２２】
ＨＴＴＰ(ハイパー・テキスト転送プロトコル)はワールド・ワイド・ウェブ(ＷＷＷ)の基礎をなすものである。これは単純なプロトコルである。クライアントはサーバとのＴＣＰ接続を確立し、要求を出し、サーバの応答をリードバックする。サーバは接続を閉じることによりその応答を示す。プロトコル層の構成は、典型的にはＩＰ上にあるＴＣＰに基づくＨＴＴＰである。
【００２３】
最も一般的なＨＴＴＰ要求はＧＥＴと呼ばれる。ＧＥＴ要求は、要求されたアイテムを一意的に指定するユニバーサル・リソース識別子(ＵＲＩ)と関連づけられる。サーバは指定されたＵＲＩに対応するファイルを返送することによりＧＥＴ要求に対して応答する。サーバによって返送されたファイルには、他のサーバ上に存在する他のファイルへのポインタ(ハイパーテキスト・リンク)が通常含まれる。したがってユーザーはファイルからファイルへ容易にたどって行くことができる。
【００２４】
インターネット・マルチメディア検索用として利用されるサーバはマルチメディア・サーバか通常のＷＷＷサーバのいずれかである。
【００２５】
専用のマルチメディア・サーバでは一般にＨＴＴＰ、ＴＣＰ及びＵＤＰプロトコルを介する伝送が可能である。これらの専用のマルチメディア・サーバはメディア・クリップのコンテンツの再調整をダイナミックに行って、利用可能なネットワークの帯域幅に合わせ、ネットワークの輻輳状態を回避することができる。これらの専用のマルチメディア・サーバは、高速早送り操作と高速巻き戻し操作、並びにライブのマルチメディア・ストリーミングをサポートすることもできる。また、いくつかのストリームを同時に供給することもできる。
【００２６】
通常のＷＷＷサーバをベースとするマルチメディア・サーバはサーバレスまたはＨＴＴＰマルチメディア・ソルーションと呼ばれる。マルチメディア・クリップはＨＴＴＰを介してストリームされる。このタイプのサーバはストリームのコンテンツに対する制御を受けないので、フロー(帯域幅)制御を利用することはできない。また、ネットワークの輻輳状態に対して応答することもできない。したがって、再生時に突然の中断が生じる可能性がある。したがって、このような突然の中断を回避するために、再生を開始する前にクライアント側に相対的に長い初期バッファ遅延が発生せざるを得ない。標準的ＷＷＷサーバからマルチメディア・ストリームの早送り(fast-forwarding)を行うことはできない。ライブのマルチメディア・ストリーミングはＪａｖａプログラミング等の特別のトリックを用いて実現する必要がある。
【００２７】
ストリームされたマルチメディア・クリップが受信されると、好適な独立のメディアプレイヤー・アプリケーションやブラウザ・プラグインを利用してクリップの再生を行うことが可能となる。このようなマルチメディア・プレイヤーはブラウザによって大きく異なる。ごく最近のブラウザには、最もポピュラーなストリーミング用ビデオ・プレイヤー用の統合化されたプラグインが備えられている場合もある。
【００２８】
移動端末装置とそれらのネットワーク間でのデータ伝送に利用可能ないくつかの異なるデータ伝送方法が存在する。もっとも良く知られている方法の中の１つはＧＳＭ(移動体通信のグローバルシステム)である。
【００２９】
回線交換データ(ＣＳＤ)と呼ばれる現在のＧＳＭデータサービスでは、９.６ｋｂｐｓの回線交換型チャネルが提供される。ＧＳＭでは、前進型誤り訂正(ＦＥＣ)と状態情報を持つ１４.４ｋｂｐｓのデータ・チャネルの提供が意図されている。高速回線交換データ(ＨＳＣＳＤ)によって、単独のユーザー用として複数の９.６ｋｂｐｓまたは１４.４ｋｂｐｓのタイムスロットが同時に提供される。対称型接続と非対称型接続とが存在する。対称型接続では、エア・インターフェース・リソースは対称に割り振られ、上り回線と下り回線の両方向で同じデータ伝送レートが与えられる。非対称型接続では上り回線と下り回線に対して異なるデータ転送レートがサポートされる。しかし、非対称型エア・インターフェース接続は非透過型モードでしか利用できない(以下参照)。
【００３０】
回線交換型ＧＳＭデータ・システムであるＣＳＤとＨＳＣＳＤとによって２つの基本接続タイプ、すなわち透過型(Ｔ)と非透過型(ＮＴ)の接続が提供される。これらの接続タイプは伝送エラーの訂正方法によって区別される。透過型の接続では、無線インターフェース伝送方式によって提供される前進型誤り訂正メカニズムによってのみ誤り訂正が行われる。この接続は同期回線と考えられる。利用可能なスループットは一定しており、伝送遅延は固定している。伝送データはビット反転エラーを含む傾向がある。非透過型接続では、エンド・ツー・エンドサービスが回線交換型であったとしても、ＧＳＭ回線接続はパケット(あるいはフレーム)データ・フローと見なされる。受け手側が残存エラーの検出ができるように各フレームには冗長ビットが含まれる。高周波経路での干渉に起因するパケット・ドロップと破損が存在する。後者は冗長度検査により回復が可能である。フレーム内に残存エラーが生じた場合の再伝送のために、無線リンク・プロトコル(ＲＬＰ)が使用される。フレームが正しいものであることが判明した場合、受け手側はこの事実に対する確認応答を行う。フレームが正しいものであることが判明しなかった場合、否認応答が送られ、指示されたフレームの再送が行われる。したがって、非透過型接続にはエラーが生じないが、スループットと伝送遅延の変動が生じる。
【００３１】
ＧＰＲＳ(汎用パケット無線システム)などの他のタイプのネットワークが存在する。ＧＰＲＳでは伝送はパケットベースで正確に行われる。
【００３２】
ビデオ・シーケンスは一続きの静止画像から構成される。ビデオ圧縮方法はビデオ・シーケンスの冗長な、はっきりとそれと判る無関係な部分の削減に基づいている。ビデオ・シーケンス内の冗長性は、空間的冗長性、時間的冗長性およびスペクトル冗長性に類別することができる。空間的冗長性とは隣接ピクセル間の相関を意味する。時間的冗長性とは同じオブジェクトが連続するピクチャ内に現れることを意味する。時間的冗長性を削減することにより、特定の画像シーケンスを表すために必要なデータ量が減少し、したがって、データの圧縮が行われる。現ピクチャと前(基準)ピクチャとの間の動きについて記述する動き補償データの作成により時間的冗長性の削減を達成することができる。実際には現ピクチャは前ピクチャから予測される。スペクトル冗長性とは同じピクチャの異なるカラー成分間の相関を意味する。
【００３３】
単にシーケンスの冗長性を減らすだけでは通常十分な圧縮を行うことはできない。したがって、ビデオ・エンコーダによっては、主観的にもっとも重要でないビデオ・シーケンス部分の品質を落そうとするものもある。さらに、効率的で損失のない圧縮パラメータと係数の符号化によって、符号化されたビット・ストリームの冗長性の削減が図られる。この主要技術は可変長コードを利用することである。
【００３４】
ビデオ圧縮方法では、時間的冗長性の削減を利用できるピクチャと利用できないピクチャとの区別が一般に行われる。時間的冗長性の削減が利用できない圧縮ピクチャは、イントラ（ＩＮＴＲＡ）あるいはＩフレームと呼ばれ、時間的に予測されるピクチャはインタ（ＩＮＴＥＲ）あるいはＰフレームと呼ばれる。インタ（ＩＮＴＥＲ）フレームの場合、予測された(動き補償)ピクチャが十分に正確であることは稀である。したがって、空間的に圧縮される予測エラー・ピクチャは各インタ（ＩＮＴＥＲ）フレームと関連づけられる。
【００３５】
ピクチャ表示レートを大きくすることによって知覚品質の改善を図るメカニズムが時間スケーラビリティによって提供される。一対の連続する参照ピクチャをとり、一対の連続参照ピクチャの一方または双方のいずれかからＢピクチャを両方向に予測することによりこの知覚品質の改善が達成される。次いで、２つのアンカー・ピクチャ(anchor picture)間でＢピクチャを次々に再生することができる。この様子は図５に例示されている。両方向時間予測によって、片方向予測より正確な予測ピクチャが得られる。したがって、同じ量子化レベルの場合、順方向に予測されるＰピクチャと比べてさらに高い圧縮がＢピクチャによって得られる。Ｂピクチャは参照ピクチャとして使用されない。すなわち、Ｂピクチャから他のピクチャが予測されることは決してない。Ｂピクチャは、将来のピクチャのピクチャ品質に影響を与えることなく破棄されることができるから、時間スケーラビリティを与えるものである。Ｂピクチャは、Ｐピクチャより良好な圧縮性能を与えるものではあるが、その構成は複雑であり、より多くのメモリを必要とすることに留意されたい。さらに、両方向補間が双方の参照ピクチャの受信を必要とし、追加計算が必要となるため、追加的遅延が導入される。さらに、Ｂピクチャはビット・ストリーム内のより多くのサイド情報を必要とする。
【００３６】
スケーラビリティという用語は、圧縮されたシーケンスを様々なデータ転送レートで復号化する能力を意味する。言い換えれば、スケーラブル・マルチメディア・クリップは、異なる帯域幅でチャネルを介してストリーミングを行いながら、リアルタイムで復号化と再生とを行うことができるように、圧縮されているにもかかわらず、比較的容易に編集が可能である。
【００３７】
スケーラブル・マルチメディアは階層を成すデータ・レイヤが生じるように一般に秩序づけられている。ベースレイヤにはマルチメディア・クリップの基本表示が含まれ、それに対して、エンハンスメントレイヤには下位レイヤの上に在るリファインメント・データが含まれる。このようにして、上位レイヤによるクリップ品質の改善が図られる。
【００３８】
スケーラビリティは、異質でエラーを生じやすい環境にとって望ましいプロパティである。ビットレートや、ディスプレイの解像度や、ネットワークのスループットや、デコーダの複雑さなどに対する制約のような制限に対抗するためにこのプロパティは望ましいものである。
【００３９】
スケーラビリティを利用して、階層化された符号化がトランスポートの優先順位づけと組み合わされるトランスポート・システムでのエラー復元力の改善が可能となる。本明細書では、トランスポート優先順位づけという用語は、同等ではないエラー保護を含み、トランスポート時の異なるサービス品質を提供し、様々なエラー／損失レートを持つ様々なチャネルを提供する、様々なメカニズムを意味する。データはその性質に応じて様々に割り当てられ、例えば、高いレベルのエラー保護を備えたチャネルを介してベースレイヤの転送を行うこともできれば、よりエラーを受けやすいチャネルを介してエンハンスメントレイヤの伝送を行うこともできる。
【００４０】
一般的には、スケーラブル・マルチメディアの符号化は、スケーラブルではない符号化より圧縮効率が劣るという欠点がある。言い換えれば、すべてのエンハンスメントレイヤを備えたスケーラブル・マルチメディア・クリップとして符号化されるマルチメディア・クリップは、均等な品質を持つスケーラブルではない単一レイヤ・クリップとして符号化される場合よりも大きな帯域幅を必要とする。しかし、例えばビデオ圧縮時の時間スケーラブルＢフレームなどの、この一般的ルールに対する例外が存在する。
【００４１】
以下、ＩＴＵ−Ｔ  Ｈ.２６３ビデオ圧縮標準を参照しながら、スケーラビリティについて説明する。Ｈ.２６３とは、６４ｋｂｐｓ以下のデータ転送レートを一般に意味する低ビットレート通信時のビデオ符号化についてのＩＴＵ−Ｔ勧告である。この勧告ではビット・ストリームのシンタックスおよびビット・ストリームの復号化が指定されている。現在、２つのバージョンのＨ.２６３が存在する。バージョン１は中核となるアルゴリズムと４つのオプションの符号化モードとから構成される。Ｈ.２６３のバージョン２は、新しい、利用可能な(negotiable)符号化モードを提供するバージョン１の拡張版である。
【００４２】
ピクチャは輝度と２つの色の違い(色差)成分(Ｙ、ＣB及びＣR)として符号化される。色差ピクチャは、輝度ピクチャと比較して、２つの座標軸に沿ってピクセルの１／２でサンプリングされる。
【００４３】
Ｈ.２６３のスケーラビリティ・モード(付録Ｏ)によって、時間スケーラビリティと、信号対雑音比(ＳＮＲ)スケーラビリティと、空間スケーラビリティとをサポートするシンタックスが指定される。
【００４４】
空間スケーラビリティとＳＮＲスケーラビリティとは密接に関連しており、唯一の違いは空間スケーラビリティによって与えられる増加した空間分解能である。ＳＮＲスケーラブル・ピクチャの一例が図６に図示されている。ＳＮＲスケーラビリティはマルチレート・ビット・ストリームの作成を意味する。ＳＮＲスケーラビリティは、符号化エラーを回復し、原ピクチャとその復元画像との間の差を回復する。エンハンスメントレイヤ内で差分ピクチャを符号化する、よりきめ細かな量子化装置を利用することにより、これが達成される。この追加情報によって再現ピクチャ全体のＳＮＲが上昇する。
【００４５】
空間スケーラビリティによって、変動する表示要件及び／又は制約を満たすためにマルチ分解能ビット・ストリームの作成することができる。空間スケーラブル構造が図７に例示されている。復元された基準レイヤ・ピクチャのアップ・サンプリングされたバージョンと原ピクチャのより高い分解能をもつバージョンとの間の符号化損失を空間エンハンスメントレイヤが回復しようと試みることを除けば、この構造はＳＮＲスケーラビリティの場合と実質的に同じである。例えば、基準レイヤが１／４共通中間フォーマット(quarter common intermediate format)(ＱＣＩＦ)の分解能を持ち、かつ、エンハンスメントレイヤが共通中間フォーマット(common intermediate format)(ＣＩＦ)分解能を持つ場合、基準レイヤ・ピクチャからエンハンスメントレイヤ・ピクチャを予測できるように基準レイヤ・ピクチャを適宜スケール化しなければならない。ＱＣＩＦ標準によって、垂直方向にのみ、水平方向にのみ、あるいは、垂直と水平の両方向に２倍だけ単一のエンハンスメントレイヤの分解能の上昇が可能になる。複数の上位レイヤの存在が可能であり、各レイヤは前のレイヤのピクチャ分解能よりもピクチャ分解能を上昇させる。基準レイヤ・ピクチャのアップ・サンプリングのために使用される補間フィルタがＨ.２６３標準に明白に定義されている。基準レイヤからエンハンスメントレイヤへのアップ・サンプリング処理は別として、空間スケールされたピクチャの処理とシンタックスは、ＳＮＲスケールされたピクチャの処理とシンタックスと同一である。
【００４６】
ＳＮＲスケーラビリティあるいは空間スケーラビリティのいずれかで、エンハンスメントレイヤ・ピクチャはＥＩピクチャまたはＥＰピクチャと呼ばれる。エンハンスメントレイヤ・ピクチャが基準レイヤ内のピクチャから上方へ予測される場合、エンハンスメントレイヤ・ピクチャはエンハンスメントＩ(ＥＩ)ピクチャと呼ばれる。このタイプのスケーラビリティでは、基準レイヤは現在のエンハンスメントレイヤ“より下位の”レイヤを意味する。場合によっては、基準レイヤ・ピクチャの予測がうまくいかなかった場合、ピクチャの静止部分の過符号化が上位レイヤ内で生じ、不必要に過度のビットレートが引き起こされることがある。この問題を回避するために、順方向予測がエンハンスメントレイヤ内で許可される。前のエンハンスメントレイヤ・ピクチャから順方向に予測可能なピクチャ、或いは、基準レイヤ・ピクチャから上方へ予測されるピクチャは、エンハンスメントＰ(ＥＰ)画像と呼ばれる。上方にかつ順方向に予測されるピクチャの平均値の計算によってＥＰピクチャの両方向予測を行うことが可能となることに留意されたい。ＥＩピクチャとＥＰピクチャの双方について、基準レイヤ・ピクチャから上方の予測は、動きベクトルが必要でないことを示す。ＥＰピクチャの順方向予測の場合、動きベクトルが必要とされる。
【００４７】
マルチ・ポイント放送マルチメディア・アプリケーションでは、ネットワーク・スループットに対する制約を符号化時にあらかじめ知ることができない。したがってスケーラブル・ビット・ストリームの使用が望ましい。図８には、各ルータが、その能力に応じてビット・ストリームのストリップを行うことが可能なＩＰマルチキャスト構成が図示されている。サーバＳが複数のクライアントＣへビット・ストリームを出力することが図８に示されている。ルータＲによりビット・ストリームのクライアントへの経路選定が行われる。この例では、少なくとも３ビットレート、１２０ｋｂｉｔ／秒、６０ｋｂｉｔ／秒および２８ｋｂｉｔ／秒へのスケーリングが可能なクリップがサーバによって出力される。
【００４８】
クライアントとサーバが、通常のユニキャスト(uni-cast)接続を介して接続されている場合、サーバは伝送されるマルチメディア・クリップのビットレートをスループットに従って調整する努力を行うことができる。１つの解決方法として、階層化されたビット・ストリームを利用し、伝送されるエンハンスメントレイヤの数を変えることにより帯域幅の変更に適合させる方法がある。
【００４９】
本発明の第１の態様によれば、請求項１８に記載のデータ信号を伝送する方法が提供される。
【００５０】
本発明の第２の態様によれば、請求項１０に記載のデータ伝送システムが提供される。
【００５１】
本発明の第３の態様によれば、請求項１に記載のサーバが提供される。
【００５２】
好適にはサーバがリオーダリング手段を有することが望ましい。好適にはサーバが、スケーラブル・データ信号を出力するエディタを有することが望ましい。
【００５３】
本発明の第４の態様によれば、請求項２１に記載のコンピュータ・プログラム成果物が提供される。
【００５４】
好適にはコンピュータ・プログラム成果物がサーバを構成することが望ましい。この意味するところは、コンピュータ・プログラムがハードウェアの中へロードされると、このコンピュータ・プログラムに起因してハードウェアがサーバ装置として作動するということである。好適にはコンピュータ・プログラム成果物が、スケーラブル・データ信号を出力するエディタを有することが望ましい。好適にはコンピュータ・プログラム成果物が、データユニットをリオーダ（re-order）するリオーダリング手段を有することが望ましい。
【００５５】
本発明の第５の態様によれば、請求項２５に記載のデータ信号が提供される。
【００５６】
好適には、これらのデータユニットまたはデータユニットからなるレイヤが、これらのデータユニットの原シーケンス以外のシーケンスに順序づけられる場合、本発明が、データユニットまたはデータユニットからなるレイヤを原シーケンスへ戻す手段またはステップも含むことが望ましい。
【００５７】
伝送リンクが、単に、輻輳状態が発生するボトルネックにすぎない場合があり、本発明はこのボトルネックを解決するために利用される。
【００５８】
本発明の利点として、同じ初期バッファリングを備えた従来技術の構成よりさらに大きなセイフティ・タイムの提供が本発明によって可能であることが挙げられる。さらに、低い伝送スループットに対するある程度の保護が本発明によって与えられる。したがって、本発明は圧縮効率を犠牲にすることなく中断が起ることを少くするのに役立つものである。
【００５９】
また本発明は、自動的に再送を行わずに、より高レベルの機能、例えばフィードバックに応答して、選択された脱落部分だけを再送する伝送プロトコルが使用される、信頼できないネットワーク接続を介する伝送の際に役立つ。この場合、本発明では、データ信号の重要部分の再送を行うために従来技術による構成よりも多くの時間が与えられる。したがってストリームの重要部分の伝送が成功する可能性が大きくなり、データ信号の最終的エンドユーザーはより良好な出力品質を感知するであろう。
【００６０】
好適にはデータ信号にとって利用可能な伝送リンクの帯域幅が可変帯域であることが望ましい。その理由として、例えば、紛失データや破損データの再送を行う必要に起因して、リンクを使用するデータ・トラフィック量が可変量である点が挙げられる。
【００６１】
本発明によって、本発明を用いない場合にはデータ信号にとって十分ではない帯域幅をもつ伝送リンク、もしくは、その伝送リンクの帯域幅の或る一定帯域が制御情報などの他のデータ用として利用できるほど十分ではない伝送リンクを介して、データ信号の伝送ができるようにするためのデータ信号の変更方法が提供される。
【００６２】
好適には、本発明の効果は、あるデータユニットのセイフティ・タイムが、他のデータユニットのセイフティ・タイムに比較して、もしくは、他のデータ単位のセイフティ・タイムを犠牲にしても増加することである。
【００６３】
好適にはデータ信号が、ベースレイヤと、少なくとも１つのエンハンスメントレイヤとを有する階層を成すように構成されることが望ましい。ベースレイヤという用語は基礎となる層を意味する。ベースレイヤは、データ信号のリファインが最も少ないバージョンを表す場合がある。各ユニットでは、該(または各)上位レイヤは、ベースレイヤと組み合わされて、ベースレイヤをリファインし、さらにデータユニットにふさわしくする。各エンハンスメントレイヤはより多くのリファインメントをベースレイヤに加えることができる。好適にはベースレイヤのセイフティ・タイムがエンハンスメントレイヤのセイフティ・タイムに対して相対的に増加することが望ましい。
【００６４】
好適にはデータ信号がスケーラブルであることが望ましい。ベースレイヤ及び該または各エンハンスメントレイヤは相互にスケーリングされる関係を持つことができる。信号は、時間領域、空間領域、スペクトル領域あるいはＳＮＲ領域でスケーラブルであってもよい。
【００６５】
好適には、シーケンスをリオーダリングすることにより、これらのレイヤが、階層内のこれらレイヤの位置に対応するセイフティ・タイムを持つことが望ましい。例えば、ある特定のデータユニットのベースレイヤの方がエンハンスメントレイヤより大きなセイフティ・タイムを持つ場合もある。好適には、あるレイヤによって表されるリファインメントのレベルが細かければ細かいほど、そのセイフティ・タイムは短くなる。
【００６６】
好適にはソースがサーバであることが望ましい。或いはソースはエディタである。
【００６７】
好適にはデータ受信装置がクライアントであることが望ましい。受け手が移動電話などの移動端末装置のようなデータ信号の宛先である場合もある。
【００６８】
好適にはデータユニットがフレームであることが望ましい。１つの実施例では、データユニットはピクチャシーケンスを表す。データユニットがビデオ・シーケンスであると好都合である。最も好適にはデータユニットがマルチメディア・データを有することが望ましい。
【００６９】
単数及び複数の“レイヤ”いう用語は、比喩的な意味で使用されており、厳密な位置関係というよりは、相互に適用できるデータ・ブロックを意味すると理解すべきである。
【００７０】
添付図面を参照しながら本発明について以下例を挙げて説明する。
【００７１】
図１から図８については上述した。
【００７２】
本発明に準拠する移動マルチメディア修正システム１０が図９に図示されている。単一のクライアント２２しか示されていないが、好適な実施例では複数のこのようなクライアントの存在が可能であることは理解できよう。サーバ１８とクライアント２２とを接続する伝送リンクの少なくとも一部が無線リンクであることも理解できる。
【００７３】
システム１０は、圧縮クリップを作成するエディタ１２と、圧縮クリップの格納用サーバ・データベース１４と、シーケンスの圧縮クリップのリオーダ用リオーダ手段１６と、リオーダされた圧縮クリップの送信用サーバ１８と、圧縮クリップの一続きの原シーケンスの復元用オーダ復元手段２０を有するクライアントとを有する。クライアント２２は、どのデータを送信するか、及び、そのデータをどのように送信するかを指定することによりサーバのオペレーションの制御を行う。リオーダ手段１６とオーダ復元手段２０とは、後者の手段によって元の順序の復元が可能となるように、適合性が必要であることは明らかである。リオーダ手段１６を配置して、図９に図示の実施例の代わりに、サーバ・データベース１４に達する前にデータに対する処理を行うようにすることも可能である。ライブのストリーム等の或る種のタイプのデータは、データベース１４を迂回して、エディタ１２によってリオーダ手段１６へ直接送信される場合もある。図９には別々に示されているが、エディタ１２、サーバ・データベース１４、リオーダ手段１６及びサーバ１８のすべてを単一のユニット、すなわちエンティティに構成することが可能である。このエンティティもサーバと呼ぶことができる。
【００７４】
図１０は本発明によるエディタのオペレーションを図示する。１以上の未圧縮ストリームの形で取込まれた生データが編集されて、１以上の未圧縮トラックが作成される。これらのトラックは圧縮ステップで圧縮され、圧縮トラックが作成される。これらの圧縮トラックはまとめて多重化され、圧縮されたマルチメディア・クリップが作成される。これらのマルチメディア・クリップはスケーラブルに符号化される。この結果得られるビット・ストリームは、ビデオ圧縮時のフレームのような基本ユニットから構成される。これらの基本ユニットのすべてが必ずしも同等の重要性を持つとはかぎらない。ビット・ストリームの復号化を行うために重要な１次基本ユニットもあれば、ビット・ストリームの品質を改善する２次基本ユニットもある。２次基本ユニットの除去によっても、復号化されたマルチメディア・クリップ中に品質損失が生じるにすぎない。実際上、１次基本ユニットはビット・ストリームのベースレイヤであり、２次ユニットはエンハンスメントレイヤである。
【００７５】
元の伝送順序、すなわち生データの編集と圧縮により基本ユニットが作成される順序に、基本ユニットを編成する代わりに、本発明による方法では、１次基本ユニットを優先させることにより基本ユニットのシーケンスが順序変更され、その結果、伝送順序の中で１次基本ユニットが２次基本ユニットより先行する(pre-empt)。リオーダリングは、システムとデータの性質に対応して多重化処理の前または後に行うことができる。図１０では、リオーダリングが多重化後に起こっているものとして示されている。
【００７６】
シーケンスをリオーダするためにリオーダリングアルゴリズムが用いられる。好適な実施例では、このアルゴリズムによってストリーム分析が行われ、１次及び２次基本ユニットが特定され、ビットレート統計値が収集される。これらの統計値にはフレーム当たりのビット数を含むことができる。次いで、フルチャネル・スループットを伴う完全な品質の再生、及び、低チャネルのスループットを伴う低品質の再生に必要な初期バッファ時間を最少化する反復リオーダリング・ステップを用いてビット・ストリームのリオーダが行われる。このようなリオーダリングアルゴリズムの一例を以下に示す。予想される低チャネルのスループットはアルゴリズムの入力パラメータの中の１つであるため、このスループットの推定を行わなければならないことに留意されたい。この推定は、例えばチャネルの振舞いから得られる統計に基づいて可能である。
【００７７】
基本ユニットのリオーダリングは、たとえチャネル・スループットの低減が生じたとしても、１次基本ユニットがその再生時間内の指示されている時間よりも早めに受信される傾向があることを意味する。しかし、２次基本ユニットは、その指示されている再生時間直前に２次基本ユニットを受信するように本方法によってスケジュールが組まれるため伝送遅延の変動に弱い。このように、クライアントは、たとえチャネル・スループットが著しく減少しても、再生を中断することなく１次基本ユニットの再生をそのまま行うことができる可能性が高い。一方、２次基本ユニットは、そのスケジュールに組まれた再生時刻より後に到来するかもしれず、この場合再生時に使用されない。
【００７８】
図１１は本発明によるクライアントのオペレーションを図示する。ビット・ストリームは、クライアントによって受信され、元の圧縮クリップを作成するためにリオーダされ、圧縮されたトラックを作成するために多重分離され、次いで、そのトラックを復元するために解凍される。(多重分離がコンテント・エディタ内でいつ生じたかに対応して)多重分離の前または後のいずれかにクライアント内での基本ユニットのオーダ復元ステップを適用することができる。図１１には、基本ユニットのオーダ復元ステップが、図１０に記載されている順序に対応するように多重分離前に行われるものとして示されている。このようにしてリオーダとオーダ復元の双方が多重化ビット・ストリームに対して適用される。オーダ復元によって基本ユニットは解凍用として元のその自然なシーケンスに編成され、すべての後から到来する２次基本ユニットは破棄される。
【００７９】
クライアント側で基本ユニットが受信された時、基本ユニットの再生が望ましい或る時間が基本ユニットにタイム・スタンプされる。このタイム・スタンプは現在の再生時間と比較される。このタイム・スタンプが現在の再生時間より大きければ、基本ユニットは解凍されず、破棄される。タイム・スタンプが現在の再生時間以下であれば、基本ユニットは解凍され、解凍後にこれら２つの時間の比較が行われる。タイム・スタンプが現在の再生時間以下の場合、基本ユニットが再生される。そうでない場合には基本ユニットは破棄される。
【００８０】
多重化後にリオーダリングが行われる特別のケースで、使用する多重化／多重分離用フォーマットによって基本ユニットのリオーダリングと元の順序の復元が許可される必要がある。
【００８１】
図１５は、本発明によるマルチメディア・コンテンツの作成および修正システムを示す別の図である。システム５０は、エディタ５２と、サーバ５４と、クライアント５６とを有する。
【００８２】
エディタは、代表的には画像シーケンスの形の生データ・ストリームを伝送に適した形に圧縮する圧縮装置５８と、圧縮されたビット・ストリームを作成するために、他の圧縮されたデータ・ストリームと共に、圧縮された生データ・ストリームをまとめて多重化する多重化装置６０と、ビット・ストリームを復号化するために重要な１次基本フレームと、ビット・ストリームの品質を改善する２次基本フレームとを生成するレイヤ生成手段６２と、を有する。
【００８３】
サーバ５４は、フレームの自然な順序の代わりに、クライアント５６側での生データ・ストリームの復元に役立つようにフレームの重要度に対応する順序にフレームの構成を行うリオーダリング手段６４を有する。
【００８４】
サーバ５４とクライアント５６の各々は、サーバ５４とクライアント５６との間での伝送リンク６８を介するデータ伝送用として送信手段６６／受信手段７０をそれぞれ有する。
【００８５】
クライアント５６は、フレームをその自然な順序に変えるオーダ復元手段７２と、ビット・ストリームを多重分離するデマルチプレクサ７４と、生データ・ストリームを再現するために圧縮されたデータ・ストリームを解凍する解凍装置７６とを有する。クライアントは、生データ・ストリームの再生用、あるいは、出力用として使用する再生／出力手段７８を有する。またクライアントは、サーバ５４に制御信号を印加してクライアント５６側でのフレームの受信に応じてリオーダー手段の制御を行うコントローラ８０を有する。
【００８６】
例
Ｈ.２６３対応エンコーダとフレーム・リオーダリングツールとを用いて本発明の実施例のテストを行った。エンコーダはＢフレームの生成が可能であった。リオーダリングツールは、リオーダリングアルゴリズムを有し、調整されて様々な低いチャネル・データ転送レート用のフレームの順序づけが行われた。
【００８７】
グラスゴー(Glasgow)と呼ばれるビデオ・フレーム標準ＩＴＵ−Ｔの検査用シーケンスが用いられた。このシーケンスは１７６×１４４ピクセルの輝度ピクチャ・サイズと８８×７２ピクセルの色差ピクチャ・サイズであるＱＣＩＦ分解能を有していた。
【００８８】
グラスゴー・シーケンスの第１の２９７フレームが圧縮され、ＩＮＴＲＡ(Ｉ)フレームと、ＩＮＴＥＲ(Ｐ)フレームと、両方向予測(Ｂ)フレームとを有する時間スケーラブル・ビット・ストリームが作成された。ＩフレームとＰフレームは１次フレームと呼ばれ、Ｂフレームは２次フレームと呼ばれる。(デフォルトの)原シーケンスのフレームレートは毎秒１２.５フレーム(ｆｐｓ)であったため、圧縮されたシーケンスは２３.６８秒に対応した。各フレームは圧縮された。第１のフレームはＩＮＴＲＡフレーム、第２のフレームはＩＮＴＥＲフレームであった。その後、ＩＮＴＥＲフレームとＢフレームとを交互にした。定量子化装置により、２８９８４ｂｐｓの１次フレーム用の平均ビットレート及び１２０８９ｂｐｓの２次フレーム用の平均ビットレートから成る４１０７３ｂｐｓの平均ビットレートを持つビット・ストリームを生成した。
【００８９】
説明を単純にするために、この例には別のビット・ストリームとのビット・ストリームの多重化は含まれていない。
【００９０】
フレーム・シーケンスのリオーダリングは、１次フレームのビットレート(Ａ)と、２次フレームのビットレート(Ｂ)の(ｉ)２５％；(ii)５０％；(iii)７５％との和に対応してビットレートについて個別に最適化された。２次ビットレート(Ｂ)の１００％は、完全な品質の再生を得るために必要な平均ビットレートに対応することに留意されたい。上記合計されたビットレートはそれぞれ３２００７、３５０２９及び３８０５１ｂｐであった。便宜上、以下の説明では、これらのビットレートを２５％(Ａ＋０.２５Ｂ)、５０％(Ａ＋０.５Ｂ)および７５％(Ａ＋０.７５Ｂ)と呼び、対応するリオーダーされたシーケンスを２５オーダー、５０オーダー及び７５オーダーと呼ぶことにする。チャネルのフル・レートはシーケンスの平均ビットレートとなることが予期された。
【００９１】
リオーダリングアルゴリズムでは２つの値が使用された：
フル・レート・チャネルを想定して完全な品質の再生を保証する最短初期バッファ時間であるＦＱＦＲ(フル・レートの完全な品質)、及び
(２５％、５０％または７５％の低ビットレートを仮定して)１次フレームを再生し、２次フレームのなかのいくつかあるいはすべてを再生しないようにする、低品質再生を保証する最短初期バッファ時間であるＲＱＲＲ(低速低品質)。
【００９２】
ある特定のチャネルについてＦＱＦＲ及びＲＱＲＲを計算する際、アルゴリズムが固定ビットレートを有することが仮定されている。ビットレート統計等を利用してフレーム当たりのビット数が計算される。特定のフレームの再生を行うべき時間はタイム・スタンプから判っている。ピクチャとしてフレームを表示する準備ができる時間が決定され(言うまでもなく１フレーム用のビットを受信し、それらのビットの作成に必要な時間が許可される)、次いで、この時間はフレームのタイム・スタンプと比較される。フレームを表示すべき時間の後にフレームが受信された場合、バッファ時間が増加し、適時に受信された場合には、次のフレームの処理を行うことができる。フレームのすべての受信に見込みのある時間と、フレームの再生時間とがアルゴリズムによっていったん比較され、フレームのすべてを適時受信するようにバッファ時間が適宜調整されて、最短バッファ時間の計算が行われる。
【００９３】
アルゴリズムが元の順序を持つシーケンスに適用された。この場合、チャネルが低レートの場合、完全な品質を得るために再生開始時により永い間待たなければならないために、ＦＱＦＲはＲＱＲＲより小さくなる。アルゴリズムは、フルチャネル・スループットでの完全な品質の再生、及びその再生と同時に、低チャネル・スループットでの低品質再生に必要な初期バッファ時間を最少化しようと努める。言い換えれば、アルゴリズムはＦＱＦＲとＲＱＲＲとがほぼ等しくなる値を見つけようと努める。このアルゴリズムが最適なものではないこと、すなわち、このアルゴリズムは、必ずしも、最小限の初期バッファ遅延を得るためにシーケンスをリオーダするものではないことに留意されたい。上記アルゴリズムは以下のステップから構成される：
１.  ＦＱＦＲとＲＱＲＲを計算する。
２.  ＦＱＦＲがＲＱＲＲ以上の場合、リオーダリングを停止する。最小限の初期バッファ遅延はＦＱＦＲまたはＲＱＲＲのうちの大きい方とする。ステップ２の条件が満たされない場合には次のステップを続ける。
３.  １フレーム・ステップずつシーケンスの開始点の方へすべての１次フレームをシフトする。例えば、初期シーケンスが以下の場合：
Ｉ０、Ｐ１、Ｐ２、Ｂ３、Ｐ４、Ｂ５、Ｐ６、Ｂ７、Ｐ８、Ｂ９、Ｐ１０、...、
シフトによってシーケンスは以下のように変化する：
Ｉ０、Ｐ１、Ｐ２、Ｐ４、Ｂ３、Ｐ６、Ｂ５、Ｐ８、Ｂ７、Ｐ１０、Ｂ９、...、
但し、Ｉ０は第１のフレームである。シーケンス中で２次フレームの方が隣接する１次フレームより先に在る場合、１次および２次フレームの位置が入れ替わっていることがわかる。
４.  ステップ１へ戻る。
【００９４】
低ビットレート・チャネルの中で中断のない再生行うことを保証するために必要なバッファ時間は、リオーダされたシーケンスの場合より原シーケンスの場合の方が大きい。初期バッファ時間は短い方が望ましい。リオーダリング処理によって、フル・レート・チャネルに必要な最短バッファ時間と、予期される低チャネルに必要な最短バッファ時間との間でトレードオフが行われる。リオーダリングがなければ、フル・レート・チャネルでの完全な品質の再生を行うための初期バッファ時間は、より少なくて済んだかもしれない。しかし、リオーダリングがなければ、低チャネルでの低品質再生を行うためにより多くの初期バッファ時間が必要となったであろう。
【００９５】
本例ではセイフティ・タイムの調査も行われた。２５％の２次ビットレートでリオーダされたシーケンスの低品質再生用として、初期バッファ時間が最短に設定された。図１２は、２５オーダー・シーケンスの再生と元のオーダー・シーケンスと共にセイフティ・タイムがどのように変わるかを図示するものである。再生の間ずっと、(上の線によって表される)２５オーダー・シーケンスが、元のオーダー・シーケンスより長いセイフティ・タイムを有することが図１２に示されている。
【００９６】
５０％及び７５％の２次ビットレートについての結果も得られた。１シーケンス内のすべての１次フレームについて平均セイフティ・タイム(秒)を、すべての３つの低ビットレートについて以下の表に示す。セイフティ・タイムは最短セイフティ・タイムと平均セイフティ・タイムとによって特徴づけられる。
【表１】
0004405689.tif 000002
【００９７】
リオーダされたシーケンスの最短セイフティ・タイムと平均セイフティ・タイムの双方が原シーケンスのセイフティ・タイムより長いことがわかる。
【００９８】
これと対照的に、様々な平均ビットレートで、完全な品質の再生を行うための必要なバッファ遅延を秒で表す表を以下に示す。これは再生時の中断を最少にするためである。
【表２】
0004405689.tif 000003
【００９９】
２次フレームがその自然な順序を変更して伝送され、すべてのフレームをその自然な順序に戻す時間が必要となるため、リオーダーされたシーケンスが完全な品質の再生を行うためには、より長いバッファ遅延を必要とすることがわかる。しかし、本発明によって最低限の初期バッファ遅延での低品質の再生が示されるので、この遅延は重要な問題ではない。これを例示するために、中断のない低品質の再生を保証するために必要なバッファ遅延を以下の表に示す：
【表３】
0004405689.tif 000004
【０１００】
伝送チャネルのビットレートが低下する場合、本発明による方法によって、再生開始が可能となる前に必要とされるバッファ遅延がより短くなることが、上記の結果から示される。
【０１０１】
２５％ビットレート(上記のようにＡ＋０.２５Ｂ)での２５オーダー・シーケンスの再生を示す図１３に本発明の効果が例示されている。再生時間、すなわち視る人に対してフレームの再生を意図あるいは想定している時間が直線として表されている。中断を要することなく、次々に再生を行うためには、各フレームをその再生時間より前に受信する必要がある。再生時間を表す上記直線より下にあるすべての記号はそのスケジュールに組み込まれた再生時間より前に受信されたフレームを表し、再生時間を表す上記直線より上にあるすべての記号はそのスケジュールに組み込まれた再生時間より後に受信されたフレームを表す。図１３の例では、１次フレームはすべて再生用として適時に受信され、２次フレームの受信はすべて遅すぎたため再生できなかった。したがって２次フレームは再生されることなくすべて棄却された。
【０１０２】
シーケンスがリオーダされなかった場合、１次フレームのいくつかは該フレームの再生時刻後に到着し、したがって、(ある１次フレームから予測されるフレームのすべてを破棄することなく当該１次フレームの破棄はできないので)１次フレームの再生を中断する必要が生じたであろうと理解すべきである。
【０１０３】
図１４は、チャネル・スループットが減少しなかった場合、２５オーダー・シーケンスがどのように受信され、再生されるかを示す図である。この図から、すべてのフレームが再生用として適時に受信されることがわかる。再言するが、上の線は２次フレームがいつ受信されたかを表し、下の線は１次フレームがいつ受信されたかを表す。
【０１０４】
言うまでもなく図１３と図１４の正確な様子は、原シーケンスの性質、並びに、ビットレート及び実行されるリオーダリングによって決められる。異なる方法でデータをリオーダリングする他のシステムでは違いがあることが予想できる。
【０１０５】
使用に際して、オンラインで本発明を利用して、将来の或る時点に伝送するビット・ストリームの準備を行うことが可能となる。例えば、所定の伝送チャネルの利用可能な帯域幅に著しい変動が生じ得ることを仮定して、ビット・ストリームにアルゴリズムを適用することができ、２５％、５０％及び７５％等のいくつかの代替の帯域幅についてリオーダされたシーケンスを計算することができる。伝送時に、例えば中断などの問題に遭遇した場合、現在使用中のリオーダされたシーケンスを低い方の利用可能な帯域幅に適したより好適なシーケンスへ変更することができる。同様に、予想以上に良好に伝送が進行している場合、より高い帯域幅用としてより好適なシーケンスを利用することができる。本発明では、伝送及び／又は再生の進捗が伝送中数回チェックされ、それに応じてシーケンスの調整を適宜行うことができる。伝送が行われている間、ダイナミックにこの調整をプログラムできれば好適である。このようにして、間欠的に生じる問題の処理を行うことができる。
【０１０６】
ビット・ストリームをリオーダする本発明の部分はエディタまたはサーバの中に配置される。順序を復元する本発明の部分はクライアント側に配置される。
【０１０７】
１次フレームのいくつかをＢフレームと取り替えることにより１次フレームに属するビット比率が低下するなら、さらなる改善が行われる。これにより、時間的にさらに離れている基準フレーム(Ｐフレーム)からＢフレームが予測されるため、圧縮効率がわずかに低下し、その結果ＢフレームとＰフレームとの類似度が少なくなる。この結果、予測されるＢフレームの質が悪くなり、そのため、対応する予測エラー画像を符号化するためにさらに多くのビットを使用しなければならなくなる。この構成では、破棄の可能性がある２次フレームに属するさらに多くのビットが存在するので、フレームのリオーダリングによって伝送の遅延と中断に対するより良好な保護が与えられる可能性さえある。
【０１０８】
本発明の１つの見方として、２次フレームのセイフティ・タイムを犠牲にして、１次フレームのための最大セイフティ・タイムの維持が図られているといえる。
【０１０９】
本発明は、ストリーミング型のマルチメディア修正に特に適している。
【０１１０】
以上本発明の好適な実施例を示し説明してきたが、このような実施例は単に例として説明したものにすぎないことは理解されるであろう。例えば、時間的にスケーラブルなビット・ストリームに適用されるものとして本発明を説明したが、本発明は、空間スケーラビリティ、スペクトル・スケーラビリティ及びＳＮＲスケーラビリティを含む他のタイプのスケーラビリティへの適用も可能である。本発明の範囲から逸脱することなく、多数の変更例、改変例及び代用例を当業者は思いつくであろう。したがって、本発明の精神と範囲内に入るものとしてこのような変更例のすべてが請求項によってカバーされることが意図されている。
【図面の簡単な説明】
【図１】  図１は、マルチメディア・コンテンツの作成と修正システムを示す図である。
【図２】  図２は、マルチメディア・クリップ・エディタのオペレーションを示す図である。
【図３】  図３は、マルチメディア・サーバのオペレーションを示す図である。
【図４】  図４は、マルチメディア検索クライアントのオペレーションを示す図である。
【図５】  図５は、Ｂピクチャ予測の例を示す図である。
【図６】  図６は、ＳＮＲスケーラビリティの例を示す図である。
【図７】  図７は、空間スケーラビリティの例を示す図である。
【図８】  図８は、ＩＰマルチキャスト・システムで利用されるスケーラブル・マルチメディアを示す図である。
【図９】  図９は、本発明による移動マルチメディア修正システムを示す図である。
【図１０】  図１０は、本発明によるエディタのオペレーションを示す図である。
【図１１】  図１１は、本発明によるクライアント側のオペレーションを示す図である。
【図１２】  図１２は、リオーダーされるシーケンスと原シーケンスのセイフティ・タイムを示す図である。
【図１３】  図１３は、リオーダーされるシーケンスの受信と再生を示す図である。
【図１４】  図１４は、リオーダーされるシーケンスの受信と再生を示す図である。
【図１５】  図１５は、別のマルチメディア・コンテンツの作成と修正システムを示す図である。
【図１】
0004405689.tif 000005
【図２】
0004405689.tif 000006
【図３】
0004405689.tif 000007
【図４】
0004405689.tif 000008
【図５】
0004405689.tif 000009
【図６】
0004405689.tif 000010
【図７】
0004405689.tif 000011
【図８】
0004405689.tif 000012
【図９】
0004405689.tif 000013
【図１０】
0004405689.tif 000014
【図１１】
0004405689.tif 000015
【図１２】
0004405689.tif 000016
【図１３】
0004405689.tif 000017
【図１４】
0004405689.tif 000018
【図１５】
0004405689.tif 000019