(57)【要約】マルチメディアストリーミングにおいてパケット転送遅延の補償を可能にする方法および装置。ストリーミングサーバを動作可能にし、そのレート制御とレート整形アルゴリズムとを最適に動作して、パケット転送遅延の変動補償を可能にするために、ストリーミングクライアントのジッタバッファリング能力を示す情報がストリーミングサーバへ伝送される。この情報にはクライアントの選択した前置復号用パラメータが含まれ、クライアントの選択した前置復号用パラメータと、ストリーミングサーバが提供する前置復号用バッファリングパラメータとに基づいて、サーバはクライアントのジッタバファリングの能力を決定できるようになる。
2006500797.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディア・ストリーミングシステムにおいてパケット転送遅延の変動補償を可能にするクライアント／サーバによる協同方法であり、ストリーミングサーバが前置復号用バッファリングパラメータを示す信号をストリーミングクライアントへ供給する方法であって、一定遅延の信頼性を有するチャネルを介してパケットストリームを伝送する場合、前記サーバによって示される前記前置復号用バッファリングパラメータを選択して、前記クライアントがクライアントバッファ違反を犯さずに前記ストリームを再生できるようにすることを保証するように為す方法において、
前記クライアントの選択したバッファパラメータに関する情報を前記サーバへ提供し、前記クライアントが信号伝送する前記前置復号用バッファリングパラメータと前記ストリーミングサーバが供給する前記前置復号用バッファリングパラメータとの間の差によって前記クライアントのジッタバファリング能力を示すことを特徴とする方法。
【請求項２】
前記伝送パケットストリームの可変ビットレート特性と前記サーバが適用する前記バッファリングとに基づいて、前記サーバが前記クライアントへ示す前記前置復号器バッファパラメータを前記サーバが選択することを特徴とする請求項１に記載の方法。
【請求項３】
前記クライアントが特定のストリーミングセッションに使用するバッファリングパラメータを決定するとすぐに、前記クライアントが、該クライアントの選択したバッファパラメータに関する前記情報を前記サーバへ提供することを特徴とする請求項１または２に記載の方法。
【請求項４】
新たなストリーミングセッションの開始時に、前記クライアントが該クライアントの選択したバッファパラメータに関する前記情報を前記サーバへ提供することを特徴とする請求項１、２または３に記載の方法。
【請求項５】
ストリーミングセッション中に前記クライアントが該クライアントのバッファリングパラメータを動的に変更する方法であって、前記クライアントが、前記ストリーミングセッション中に該クライアントの変更したバッファパラメータに関する情報を前記サーバへ提供することを特徴とする請求項１乃至４のいずれか１項に記載の方法。
【請求項６】
前記ストリーミングサーバが、前記クライアントの前記バッファリングパラメータに関する前記情報を利用するレート制御および／またはレート整形アルゴリズムを適用して、パケット転送遅延とチャネルレート変動とを補償することを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項７】
前記ストリーミングサーバが、レート制御時および／またはレート整形時に、前記クライアントの前記バッファリングパラメータに関する情報をオプションとして考慮することを特徴とする請求項１乃至５のいずれか１項に記載の方法。
【請求項８】
前記クライアントの前記バッファリングパラメータに関する情報が、前記クライアントの前置復号器バッファのサイズに関する情報、前置復号器バッファリング時間に関する情報、および後置復号器バッファリング時間に関する情報のすべてまたはいくつかを含むことを特徴とする請求項１乃至７のいずれか１項に記載の方法。
【請求項９】
前記ストリーミングクライアントが、前記クライアントの前記バッファリングパラメータに関する前記情報をＲＴＳＰオプション要求メッセージの形で前記ストリーミングサーバへ提供することを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１０】
前記ストリーミングクライアントが、前記クライアントの前記バッファリングパラメータに関する前記情報をＲＴＳＰ再生要求メッセージの形で前記ストリーミングサーバへ提供することを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１１】
前記ストリーミングクライアントが、前記クライアントの前記バッファリングパラメータに関する前記情報をＲＴＳＰピング要求メッセージの形で前記ストリーミングサーバへ提供することを特徴とする請求項１乃至８のいずれか１項に記載の方法。
【請求項１２】
前記ストリーミングサーバがクライアントバッファリングパラメータの信号伝送をサポートしているかどうかを前記ストリーミングクライアントが判定することを特徴とする請求項１乃至１１のいずれか１項に記載の方法。
【請求項１３】
ストリーミングサーバからパケットストリームを受け取り、前記パケットストリームを再生するようになっている、少なくとも１つのバッファを備えるストリーミングクライアント装置であって、前記ストリーミングクライアント装置が、該装置の選択したバッファパラメータに関する情報を前記サーバへ提供するようになっていることを特徴とするストリーミングクライアント装置。
【請求項１４】
前置復号器バッファと遅延ジッタバッファとを具備する請求項１３に記載のストリーミングクライアント装置。
【請求項１５】
前置復号器バッファと、遅延ジッタバッファと、後置復号器バッファとを具備する請求項１３に記載のストリーミングクライアント装置。
【請求項１６】
前記前置復号器バッファと遅延ジッタバッファとが単一ユニットとして組み込まれていることを特徴とする請求項１４または１５に記載のストリーミングクライアント装置。
【請求項１７】
前記ストリーミングサーバから前置復号器バッファリングパラメータの指示を受け取るようになっていることを特徴とする請求項１３乃至１６のいずれか１項に記載のストリーミングクライアント装置。
【請求項１８】
特定のストリーミングセッションに使用するバッファリングパラメータを決定するとすぐに、前記ストリーミングクライアント装置の選択したバッファパラメータに関する前記情報を前記サーバへ提供するようになっていることを特徴とする請求項１３乃至１７のいずれか１項に記載のストリーミングクライアント装置。
【請求項１９】
新たなストリーミングセッションの開始時に、前記ストリーミングクライアント装置の選択したバッファパラメータに関する前記情報を前記サーバへ提供することを特徴とする請求項１３乃至１８のいずれか１項に記載のストリーミングクライアント装置。
【請求項２０】
ストリーミングセッション中に前記ストリームクライアント装置のバッファリングパラメータを動的に変更するようになっていて、さらに、該装置の変更したバッファパラメータに関する情報を前記ストリーミングセッション中に前記サーバへ提供するようになっていることを特徴とする請求項１３乃至１９のいずれか１項に記載のストリーミングクライアント装置。
【請求項２１】
前記クライアントの前記バッファリングパラメータに関する情報が、前記クライアントの前置復号器バッファのサイズに関する情報と、前置復号器バッファリング時間に関する情報と、後置復号器バッファリング時間に関する情報とのうちのすべてまたはいくつかを含むことを特徴とする請求項１３乃至２０のいずれか１項に記載のストリーミングクライアント装置。
【請求項２２】
前記ストリームクライアント装置の選択したバッファパラメータに関する前記情報をＲＴＳＰオプション要求メッセージの形で前記ストリーミングサーバへ提供するようになっていることを特徴とする請求項１３乃至２１のいずれか１項に記載のストリーミングクライアント装置。
【請求項２３】
前記ストリームクライアント装置の選択したバッファパラメータに関する前記情報をＲＴＳＰ再生要求メッセージの形で前記ストリーミングサーバへ提供するようになっていることを特徴とする請求項１３乃至２２のいずれか１項に記載のストリーミングクライアント装置。
【請求項２４】
前記ストリームクライアント装置の選択したバッファパラメータに関する前記情報をＲＴＳＰピング要求メッセージの形で前記ストリーミングサーバへ提供するようになっていることを特徴とする請求項１３乃至２３のいずれか１項に記載のストリーミングクライアント装置。
【請求項２５】
前記ストリーミングサーバがクライアントバッファリングパラメータの信号伝送をサポートしているかどうかを判定するようになっていることを特徴とする請求項１３乃至２４のいずれか１項に記載のストリーミングクライアント装置。
【請求項２６】
ストリーミングクライアント装置へパケットストリームを伝送するようになっているストリーミングサーバ装置であって、前記ストリーミングクライアント装置の選択したバッファパラメータに関する情報を受け取るようになっていることを特徴とするストリーミングサーバ装置。
【請求項２７】
前置復号用バッファリングパラメータを示す信号を前記ストリーミングクライアントへ提供するようになっているストリーミングサーバ装置であって、一定遅延の信頼性を有するチャネルを介して前記ストリームを伝送する場合、前記サーバが示す前記前置復号用バッファリングパラメータを選択して、前記クライアントがクライアントバッファ違反を犯さずに前記パケットストリームを再生できるようにすることを保証するように為すことを特徴とする請求項２６に記載のストリーミングサーバ装置。
【請求項２８】
前記クライアントの前記選択したバッファパラメータに関する情報を利用して、前記サーバ装置から前記ストリーミングクライアントへの前記パケットストリームの伝送中に生じるパケット転送遅延と、チャネルレート変動とを補償するレート制御および／またはレート整形アルゴリズムを適用するようになっていることを特徴とする請求項２６または２７に記載のストリーミングサーバ装置。
【請求項２９】
レート制御および／またはレート整形の際に、前記クライアントの前記選択したバッファパラメータに関する情報をオプションとして考慮するようになっていることを特徴とする請求項２６、２７または２８のいずれか１項に記載のストリーミングサーバ装置。
【請求項３０】
前記サーバにより受信された前記クライアントの前記バッファリングパラメータに関する前記情報が、前記クライアントの前置復号器バッファのサイズに関する情報、前置復号器バッファリング時間に関する情報、後置復号器バッファリング時間に関する情報のうちのすべてまたはいくつかを含むことを特徴とする請求項２６乃至２９のいずれか１項に記載のストリーミングサーバ装置。
【請求項３１】
請求項１３に記載のストリーミングクライアント装置と、請求項２６に記載のストリーミングサーバ装置とを具備するデータストリーミングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般にマルチメディアストリーミングに関し、特に、３ＧＰＰパケット交換ストリーミングサービス（ＰＳＳ）に関する。
【背景技術】
【０００２】
３ＧＰＰ（第３世代パートナープロジェクト）パケット交換ストリーミングサービス（ＰＳＳ）には、符号化および、ＶＢＲ（可変ビットレート）ビデオ圧縮とビデオ伝送とに固有のサーバ特有の遅延を補償することをターゲットとする規範的ビデオバッファ要件が規定されている（以後ＴＳ２６.２３４と呼ぶ３ＧＰＰ  ＴＳ２６.２３４  Ｖ５.１.０“透過的終端間パケット交換ストリーミングサービス（ＰＳＳ）；プロトコルおよびコーデック（リリース５）”（２００２年６月）、および、ノキア社“連続メディア用ＰＳＳバッファ要件”（３ＧＰＰ  ＴＳＧ−ＳＡ  ＷＧ４会議＃１８寄稿論文Ｓ４−０１０４９７、２００１年９月）を参照のこと）。同様の規範的“ビデオバッファリング検証装置”がＭＰＥＧ−４について規定されている（ＩＳＯ／ＩＥＣ_ＩＳ１４４９６-２、“情報技術−オーディオ・ビジュアルオブジェクトの一般的符号化（ＭＰＥＧ−４）、第２部：ビジュアル”、１９９８年１０月の添付資料Ｄを参照のこと）。
【０００３】
ストリーミングサーバとクライアントの双方がバッファ要件に従う場合、もしサーバからのストリームが、一定遅延の信頼性を有する伝送チャネルを介して伝送されるのであれば、クライアントがクライアントバッファ違反を犯さずに（すなわち、クライアント側でバッファのアンダーフローやオーバーフローが生じることなく）、サーバにより伝送されたストリームを再生できることが保証される。しかし、リアルタイムのストリーミングシステムでは、クライアントは、伝送路上での可変パケット転送遅延とビットレート変動との調整も行わなければならない。一般に、パケット転送遅延の変動補償はストリーミングクライアント側でのジッタバッファリングを介して行うことが可能である。
【０００４】
３ＧＰＰ規格では、３Ｇ無線ネットワークを介する透過的なサービスとしてパケット交換ストリーミングサービスが規定されてはいるが、トランスポートネットワークの欠陥および／または特徴を処理するためにクライアントが利用できる具体的なアルゴリズムは何も仕様化されてはいない。したがって、パケット転送遅延の変動を補償する手段としてのジッタバッファリングは、ＰＳＳビデオバッファ要件の範囲内には含まれないことになる。ＰＳＳバッファ要件とは、ストリーミングクライアント側で指示される“前置復号器バッファ”と“後置復号器バッファ”とに関する要件である。
【０００５】
３Ｇ無線アクセスネットワークでのベアラビットレート変動などの時間経過に伴う伝送路上でのパケット転送に利用可能なビットレートの変動が、パケット転送遅延の変動の実際の原因である。変動する伝送路ビットレート条件に対するパケットレートとメディアレートの適合化がストリーミングサーバ側で実行され、（前置復号器バッファアンダーフローに起因して生じる不必要な再生休止を避けるために）リアルタイムのパケットトランスポートの維持が図られる。このようなレート適合化システムの１例は、Ｈａｓｋｅｌｌら（米国特許第５，５６５，９２４号、“可変チャネル用符号器／復号器バッファ制御”）に記載されている。
【０００６】
レート適合化の目的は、伝送されたパケットの着信を該パケットの再生時刻前に保証することである。この再生時刻は、パケットのサンプリングタイム＋所定の一定の“終端間遅延”によって決定される。上記終端間遅延は、“サーババッファリング遅延”と、“転送遅延”（“チャネルバッファ”としても知られている）と、“クライアントバッファリング遅延”とから成る遅延である。転送遅延を推定し、次いで、サーババッファリング遅延を受けた後、総終端間遅延時間内にストリーミングクライアントに着信できる伝送用パケットの選択を行うことがサーバの役割である。セッション中、サーバは転送遅延とこの転送遅延の変動とをモニタし、次いで、サーバ自身のサーババッファリング遅延を適合させてクライアントバッファ違反が生じないようにすることが望ましい。ストリーミングクライアントは、サービスの規範的バッファ要件に従う必要があるが、最大のクライアントバッファリング遅延を選択する自由がある。
【０００７】
ＰＳＳでは、リアルタイム・ストリーミングプロトコル（ＲＴＳＰ）を用いて、ストリーミングサーバからストリーミングクライアントへクライアントバッファリングの推奨パラメータが信号伝送される（ＩＥＴＦ  ＲＦＣ２３２６“リアルタイム・ストリーミングプロトコル（ＲＴＳＰ）”（１９９８年４月）を参照のこと）。ＭＰＥＧ−４では、バッファリングパラメータは、ビデオビットストリーム構成情報ヘッダの一部として信号伝送される。サーバ側のレート制御および／またはレート整形アルゴリズムの選択時に、サーバ推奨の当該パラメータがクライアントにより正確に使用されるものとサーバは想定している。
【０００８】
一定遅延の信頼性を有する伝送チャネルを介して伝送されるパケットに基づいて推奨パラメータが選択されることに留意されたい。上記チャネルの信頼性が高くない場合、すなわち、遅延が一定でない場合、サーバ推奨のバッファリングパラメータをクライアントが正しく使用しても、クライアントバッファ違反を犯さない再生を保証することはできない。この問題を解決するために、ストリーミングクライアントはある追加のジッタバッファリングを実施する必要がある。このジッタバッファリングは一般に、前置復号器バッファリングと同じ物理クライアントバッファ空間で実施される。これは、ストリーミングサーバ推奨の前置復号器バッファリングよりもルーズなクライアントバッファリングパラメータの適用により、追加のジッタバッファリングを実施することを意味するものである。例えば、クライアントは、前置復号器バッファリング用として推奨されるものよりも長い初期のクライアントバッファリング遅延と、さらに大きなバッファサイズ（さらに多くのバイトを記憶することができる）とを適用することができる。クライアントは、パケット転送遅延の補償を助ける試みを行ってバッファリングパラメータの動的調整を行うことも可能である。
【０００９】
Ｈａｓｋｅｌｌらによる前述の米国特許では、サーバとクライアントバッファリングパラメータ（すなわちバッファサイズと初期のバッファリング遅延）はサーバとクライアントの双方により事前に知られていると仮定されているが、これがどのように達成されるかについては考慮されていない。
【００１０】
Ｃｌａｒｋらの“ＩＰメトリック報告に関する音声用ＲＴＣＰ拡張”（IETF draft-clark-avt-rtcpvoip-01.txt）では、ＲＴＣＰ報告（すなわちＲＴＣＰ拡張の定義）の形で“終端システム遅延”パラメータの伝送を行うことが提案されている。本例では、終端システム遅延は、報告用エンドポイントで決定される総体としての符号化、復号化、ジッタバッファ遅延として規定される。これは、着信するＲＴＰフレームのバッファリング、復号化、“アナログ”形式への変換の結果生じる遅延時間としての規定であり、ローカルな“アナログ”インタフェースでループバックし、符号化し、ＲＴＰフレームとして伝送するために利用できるようになっている。実際には、マルチメディアストリーミング用アプリケーションでこのように規定されたメトリックの利用は不可能であるように思われる。
【００１１】
一定遅延の信頼性を有するチャネルに基づいて推奨パラメータを信号伝送する代わりに、サーバ側は、ルーズな推奨の前置復号器バッファリングパラメータをクライアントへ信号伝送して、クライアント側が、一定遅延チャネル用の実際に必要なパラメータの代わりに、実際にはルーズなバッファリングパラメータを使用することを保証するようにしてもよい。どの程度ルーズなパラメータを信号伝送できるかを推定するために、サーバは、クライアントが通常パケット転送遅延とチャネルレート変動補償に利用する割り増しのバッファリング遅延やバッファサイズのような係数について考慮する。しかし、クライアント側は、サーバが信号伝送したパラメータが予め調整されたものであり、パケット転送遅延補償を含むものであることを知らないため、クライアント側のバッファリングを行う必要上さらにルーズなパラメータを使用する可能性がある。この結果、割り増しのクライアントバッファリングが、サーバによって１回、および、クライアントによって１回の２回係数化が行われるため、過度のバッファリングが生じることになる。
【００１２】
クライアント／サーバとが協同してクライアントバッファリングの最適選択を行い、これを利用して、クライアントバッファがオーバーフローやアンダーフローしないように保証する解決方法の発見に対する要望が長い間感じられてきた。従来この要望が満たされることはなかった。
【発明の開示】
【発明が解決しようとする課題】
【００１３】
ストリーミングサーバのレート制御とレート整形アルゴリズムとの最適動作を可能にして、所定のパケット用終端間遅延の分布のモニタと制御とを行うことにより、パケット転送の遅延変動を補償することが本発明の第１の目的である。このセクションで、並びに、以下の発明の詳細な説明のセクションで、“所定のパケット用終端間遅延の分布”という用語は、終端間遅延を形成するサーババッファリング遅延、転送遅延、ジッタバッファリング遅延、および前置復号用バッファリング遅延のそれぞれの量を意味するものとする。
【課題を解決するための手段】
【００１４】
ストリーミングクライアントのバッファリング能力についてストリーミングサーバに通知することにより上記目的の達成が可能となる。ストリーミングクライアントのジッタバッファリング能力をサーバに対して示すことは、新たな物理特性となる。マルチメディア・ストリーミングシステムでは、ストリーミングサーバに対するストリーミングクライアントのジッタバッファリング能力のこのような指示を利用して、サーバのレート制御および／またはレート整形アルゴリズムを補助することが可能であり、システムは、このアルゴリズムを適用して、パケット転送遅延とチャネルレート変動との補償を行う。例えば、クライアントの最大ジッタバッファリング遅延に関する情報がある場合、サーバは、クライアントバッファ違反の発生を減らすレート制御アルゴリズムを選択することが可能となる。
【００１５】
したがって、本発明の第１の態様によれば、マルチメディア・ストリーミングシステムにおいてパケット転送遅延の変動補償を可能にするクライアント／サーバによる協同方法が提供され、上記方法では、前置復号用バッファリングパラメータを示す信号がストリーミングサーバによりストリーミングクライアントへ供給され、さらに、サーバにより示される前置復号用バッファリングパラメータが選択されて、ストリームが一定遅延の信頼性を有するチャネルを介して伝送される場合、クライアントは、クライアントバッファ違反を犯さずにパケットストリームを再生することが可能になる。前記方法は、クライアントの選択したバッファパラメータに関する情報をサーバへ供給し、クライアントが信号伝送する前置復号用バッファリングパラメータとストリーミングサーバが供給する前置復号用バッファリングパラメータとの間の差によって、クライアントのジッタバファリング能力を示すことを特徴とする。
【００１６】
好適には、伝送パケットストリームの可変ビットレート特性と、サーバが適用するバッファリングとに基づいて、サーバがクライアントへ示す前置復号器バッファパラメータをサーバが選択することが望ましい。
【００１７】
好適には、クライアントが特定のストリーミングセッションのために使用する上記バッファリングパラメータを決定するとすぐに、クライアントはその選択したバッファパラメータに関する前記情報をサーバへ提供することが望ましい。
【００１８】
好適には、クライアントが、新たなストリーミングセッションの開始時に、クライアントの選択したバッファパラメータに関する前記情報をサーバへ供給することが望ましい。
【００１９】
好適には、クライアントが、ストリーミングセッション中にクライアントのバッファリングパラメータを動的に変更し、上記ストリーミングセッション中に、上記変更したバッファパラメータに関する情報をサーバへ供給することが望ましい。
【００２０】
好適には、ストリーミングサーバが、クライアントのバッファリングパラメータに関する情報を利用するレート制御および／またはレート整形アルゴリズムを適用して、パケット転送遅延とチャネルレート変動との補償を行うようにすることが望ましい。
【００２１】
好適には、オプションとして、ストリーミングサーバが、レート制御および／またはレート整形時にクライアントのバッファリングパラメータに関する情報について考慮することが望ましい。
【００２２】
好適には、クライアントのバッファリングパラメータに関する情報が、クライアントの前置復号器バッファのサイズに関する情報と、前置復号器バッファリング時間に関する情報と、後置復号器バッファリング時間に関する情報とのうちのすべてまたはいくつかの情報を含むことが望ましい。
【００２３】
好適には、ストリーミングクライアントが、ＲＴＳＰオプション要求メッセージの形でクライアントのバッファリングパラメータに関する前記情報をストリーミングサーバへ供給することが望ましい。
【００２４】
好適には、ストリーミングクライアントが、ＲＴＳＰ再生要求メッセージの形でクライアントのバッファリングパラメータに関する前記情報をストリーミングサーバへ供給することが望ましい。
【００２５】
好適には、ストリーミングクライアントが、ＲＴＳＰピング要求メッセージの形でクライアントのバッファリングパラメータに関する前記情報をストリーミングサーバへ供給することが望ましい。
【００２６】
好適には、ストリーミングサーバが、クライアントバッファリングパラメータの信号伝送をサポートしているかどうかをストリーミングクライアントが判定することが望ましい。
【００２７】
特に、ストリーミングクライアントのバッファリングパラメータのストリーミングサーバへの信号伝送は、ＴＳ２６.２３４バッファリング検証装置のコンテキスト（環境）で行われる（ＴＳ２６.２３４の添付資料Ｇを参照のこと）。
【００２８】
本発明の第２の態様によれば、少なくとも１つのバッファを備えるストリーミングクライアント装置が提供され、ストリーミングサーバからパケットストリームを受け取り、前記パケットストリームを再生するようになっている前記装置は、その選択したバッファパラメータに関する情報を上記サーバへ供給するようになっていることを特徴とする。
【００２９】
上記クライアント装置は、さらに、前置復号器バッファと、遅延ジッタバッファと、後置復号器バッファとを特徴とする。
【００３０】
好適には、前置復号器バッファと遅延ジッタバッファとが単一ユニットとして組み込まれることが望ましい。
【００３１】
好適には、クライアント装置が、ストリーミングサーバから前置復号器バッファリングパラメータの指示を受け取るようになっていることが望ましい。
【００３２】
好適には、特定のストリーミングセッションに使用するバッファリングパラメータを決定するとすぐに、クライアント装置はその選択したバッファパラメータに関する前記情報をサーバへ供給するようになっていることが望ましい。
【００３３】
好適には、新たなストリーミングセッションの開始時に、クライアント装置がその選択したバッファパラメータに関する前記情報をサーバへ供給するようになっていることが望ましい。
【００３４】
好適には、クライアント装置が、ストリーミングセッション中にそのバッファリングパラメータを動的に変更するようになっていて、ストリーミングセッション中にその変更したバッファパラメータに関する情報をサーバへさらに供給するようになっていることが望ましい。
【００３５】
好適には、クライアントのバッファリングパラメータに関する情報が、クライアントの前置復号器バッファのサイズと、前置復号器バッファリング時間に関する情報と、後置復号器バッファリング時間に関する情報とに関する情報のうちのすべてまたはいくつかの情報を含むことが望ましい。
【００３６】
好適には、クライアント装置が、ＲＴＳＰオプション要求メッセージの形でその選択したバッファパラメータに関する前記情報をストリーミングサーバへ供給するようになっていることが望ましい。
【００３７】
好適には、クライアント装置が、ＲＴＳＰ再生要求メッセージの形で、その選択したバッファパラメータに関する前記情報をストリーミングサーバへ供給するようになっていることが望ましい。
【００３８】
好適には、クライアント装置がＲＴＳＰピング要求メッセージの形でその選択したバッファパラメータに関する前記情報をストリーミングサーバへ供給するようになっていることが望ましい。
【００３９】
好適には、ストリーミングサーバがクライアントバッファリングパラメータの信号伝送をサポートしているかどうかをクライアント装置が判定するようになっていることが望ましい。
【００４０】
本発明の第３の態様によれば、ストリーミングクライアント装置へパケットストリームを伝送するようになっているストリーミングサーバ装置が提供され、該サーバ装置は、上記ストリーミングクライアント装置の選択したバッファパラメータに関する情報を受け取るようになっていることを特徴とする。
【００４１】
好適には、上記サーバ装置が前置復号用バッファリングパラメータを示す信号をストリーミングクライアントへ供給するようになっていて、一定遅延の信頼性を有するチャネルを介してストリームを伝送する場合、クライアントがクライアントバッファ違反を犯さずに前記パケットストリームを再生できることを保証するように、上記サーバにより示される前記前置復号用バッファリングパラメータを選択することが望ましい。
【００４２】
好適には、上記サーバ装置が、クライアントの選択したバッファパラメータに関する情報を利用するレート制御および／またはレート整形アルゴリズムを適用して、上記サーバ装置から上記ストリーミングクライアントへの前記パケットストリームの伝送中に生じるパケット転送遅延とチャネルレート変動とを補償するようになっていることが望ましい。
【００４３】
好適には、レート制御および／またはレート整形時に、サーバ装置がクライアントの選択したバッファパラメータに関する情報についてオプションとして考慮するようになっていることが望ましい。
【００４４】
好適には、上記サーバにより受信された上記クライアントのバッファリングパラメータに関する情報が、クライアントの前置復号器バッファのサイズと、前置復号器バッファリング時間に関する情報と、後置復号器バッファリング時間に関する情報とのうちのすべてまたはいくつかの情報を含むことが望ましい。
【００４５】
本発明の第４の態様によれば、ストリーミングクライアント装置とストリーミングサーバ装置とを備えたデータストリーミングシステムが提供され、上記ストリーミングサーバ装置は、ストリーミングクライアント装置へパケットストリームを伝送するようになっていて、上記ストリーミングサーバ装置は、上記ストリーミングクライアント装置の選択したバッファパラメータに関する情報を受け取ることを特徴とする。
上記ストリーミングクライアント装置は、少なくとも１つのバッファを備え、ストリーミングサーバからパケットストリームを受け取り、前記パケットストリームを再生するようになっていて、さらに、上記ストリーミングクライアント装置は、前記クライアント装置がその選択したバッファパラメータに関する情報を上記サーバへ供給するようになっていることを特徴とする。
【発明を実施するための最良の形態】
【００４６】
図１は本発明に基づくマルチメディア・ストリーミングシステム１を示すブロック図であり、この図にはストリーミングクライアント６０からストリーミングサーバ１０へのバッファリングパラメータの信号伝送手段が示されている。
【００４７】
ストリーミングサーバ１０は、アプリケーションレベルのシグナリングエンジン２０と、レートコントローラ３０と、サーババッファ４０とを具備する。ストリーミングクライアント６０は、アプリケーションレベルのシグナリングエンジン７０を具備するが、このエンジン７０は、ストリーミングサーバ１０内のアプリケーションレベルのシグナリングエンジン２０に対応するものであり、エンジン２０と通信するようになっている。ストリーミングクライアント６０は、図１に例示の本発明の実施形態で、単一ユニットとして組み込まれたジッタバッファ８２と前置復号用バッファ８４とを有するクライアントバッファ８０をさらに備える。本発明の別の実施形態では、ストリーミングクライアント６０は別々に実装されるジッタバッファと前置復号用バッファとを含むものであってもよい。ストリーミングクライアントはメディアデコーダ９０と、後置復号器バッファ１００と、バッファコントローラ１１０と、表示／再生装置１２０とをさらに備える。
【００４８】
図１に描かれているシステムは、ストリーミングサーバ１０とストリーミングクライアント６０との間に配置されている“チャネルバッファ”５０を備えたシステムとして示されている。上述した発明の背景で説明したように、これは、ストリーミングサーバからクライアントへのデータパケット伝送中に生じる変動する転送遅延を表すものである。
【００４９】
ストリーミングサーバのアプリケーションレベルのシグナリングエンジン２０は、図１の参照番号２００で示されるように、推奨のバッファリングパラメータをストリーミングクライアントへ伝送するようになっている。本発明の好ましい実施形態では、上記パラメータは、第３世代ＰＳＳサービスを規定する規格に準拠して実装されていて、例えば、初期の前置復号器バッファリング時刻の指示や前置復号器バッファサイズを含み、リアルタイム・ストリーミングプロトコル（ＲＴＳＰ）を用いてマルチメディアストリーミングサーバ１０からクライアント６０へ伝送される。本発明の別の実施形態では、異なるメカニズムがＭＰＥＧ−４などの別の仕様に従って実現され、これらの異なるメカニズムを利用することが可能である。
【００５０】
ストリーミングサーバからメディアデータを伝送するレートに適合するようにサーバのレートコントローラ３０は動作する。サーバのレートコントローラ３０は、クライアントバッファリングパラメータを考慮に入れながら、伝送チャネルで変動するビットレートに従って伝送データレートの調整により動作し、それによって、前置復号器バッファのアンダーフローに起因して生じるクライアント側での再生時の休止を避けるように努める。
【００５１】
データパケットが伝送チャネルの両端にわたってストリーミングサーバからストリーミングクライアント６０へ伝送される前に、サーババッファ４０はこれらのデータパケットを一時的に記憶する。データパケットがリアルタイムでサンプルされる“ライブの”ストリーミングシナリオでは、サーババッファは全く物理的バッファであり、データパケットがサンプリング時刻に配置され、転送時刻に取り出される。しかし、データパケットがリアルタイムでサンプルされずに、前置符号化されたファイルに記憶され、転送時刻にファイルから読み出される“前置符号化された”ストリーミングシナリオでは、サーババッファは、（前置符号化されたファイルの最初のデータパケットが伝送されるとき、ストリーミングサーバ側で起動されるサンプリングクロックと関連する）サンプリング時刻とデータパケットの転送時刻との間の差分を表すバーチャルバッファである。
【００５２】
ストリーミングクライアント側では、メディアデータは伝送チャネルから受信され、クライアントバッファ８０に一時保存される。前置復号器バッファ８４とジッタバッファ８２とのパラメータはバッファコントローラ１１０によりセットされる。パラメータはサーバ推奨の前置復号器バッファリングパラメータと、クライアントが推定する追加バッファリングとの合計として選択される。クライアントは、利用可能な伝送チャネルで予想されるパケット転送遅延の変動（すなわちジッタ）を大目に見るために必要な変動値の推定を行う。このような総計はクライアントの最大バッファリング能力により制約を受ける。メディアデコーダ９０はクライアントバッファからメディアデータを取り出し、当該媒体タイプ用の適切な方法でメディアデータの復号化を行う。上記メディアデータは一般に、複数の異なる媒体タイプを含むものであると理解すべきである。例えば、サーバから伝送されるメディアデータがビデオシーケンスを表す場合、ビデオデータに加えて少なくともオーディオ成分を含む傾向がある。したがってメディアデコーダ９０は、図１に示すように、実際には、特定のビデオ符号化規格に準拠して実装されたビデオデコーダと関連する対応するオーディオデコーダなどの２以上の復号器を含むものであってもよい旨を理解されたい。メディアデータは、メディアデコーダ９０にる復号化を受けるために、後置復号器バッファ１００へ出力され、そのスケジュールされている再生時刻までこのバッファに一時的に保存され、その再生時刻に後置復号器バッファから再生装置１２０へ渡される。
【００５３】
本発明によれば、バッファコントローラ１１０は、クライアントのバッファリングパラメータの指示をアプリケーションレベルのシグナリングエンジン ７０へ与えるようになっている。次いで、図１の参照番号３００により示されるように、アプリケーションレベルのシグナリングエンジンは、クライアントのバッファリングパラメータの指示をストリーミングサーバへ伝送するようになっている。本発明の好ましい実施形態では、クライアントのジッタバファリング能力は、クライアントが使用する、信号伝送された実際のバッファリングパラメータと、ストリーミングサーバが提供する推奨の前置復号用バッファリングパラメータとの間の差分として、ストリーミングサーバに対して暗黙のうちに指示されるにすぎない。好適には、上記指示は、ストリーミングクライアント内のアプリケーションレベルのシグナリングエンジン７０から、伝送チャネルを介して、ストリーミングサーバ内のアプリケーションレベルのストリーミングエンジン２０へ伝送される信号メッセージにより与えられることが望ましい。このようにして、ストリーミングクライアントのバッファリング能力についてストリーミングサーバに通知するメカニズムが提供される。このメカニズムは、このような指示を提供しないシステムと比べて複数の重要な技術的利点を提供するものである。特に、ストリーミングサーバ１０が、ストリーミング中に使用される実際のクライアントバッファリングパラメータを知っている場合、サーバは、実際のクライアントバッファリングパラメータを利用するレート制御および／またはレート整形アルゴリズムを適用して、パケット転送遅延とチャネルレート変動との補償を行うことができる。本発明は、前置復号器バッファリングとジッタバッファリングとの組み合わせを利用し、単一セットのバッファリングパラメータの信号伝送を利用して、クライアントのパケット転送遅延補償能力をストリーミングサーバへ示すものである。
【００５４】
クライアント６０が使用するために選択した実際のバッファリングパラメータの信号伝送を知って、ストリーミングサーバ１０は、最初に、偽りなく、一定遅延の信頼性を有するチャネル用の推奨パラメータである前置復号器バッファリングパラメータをクライアントへ信号伝送することが可能となる。したがって、サーバからクライアントへの前置復号用バッファリングの信号伝送の誤用はなくなり、それによって、マルチメディアストリーミングサーバはさらに正確で、明確なレート制御を行うことが可能となる。
【００５５】
図２はマルチメディア・ストリーミングシステムの異なるバッファにおける遅延例を示す図である。図２で、（Ｘ軸）は時間を秒で示し、縦軸（Ｙ軸）は累積データ量をバイトで示す。サンプリング曲線（Ｓ）は、あたかもメディアエンコーダがリアルタイムで機能しているかのようにデータ作成の進行状態を示す。伝送側曲線（Ｔ）は所定時にサーバが送り出す累積データ量を示す（直線は固定ビットレート伝送を示すことに留意されたい）。受信側曲線（Ｒ）は、受信され、所定時にクライアントバッファの中へ入れられる累積データ量を示し、一方、再生曲線（Ｐ）は所定時に、前置復号器バッファから取り出され、復号器により処理される累積データ量を示す。サンプリング曲線（Ｓ）は再生曲線（Ｐ）の対の片方であり、再生曲線のタイム・シフトされたバージョンである。
【００５６】
図２で、異なるバッファの遅延を容易に理解することができる。サンプリング曲線（Ｓ）と再生曲線（Ｐ）との間のＸ軸差分により“終端間”遅延が表される。サンプリング曲線（Ｓ）と伝送側曲線（Ｔ）間のＸ軸差分は“サーババッファリング遅延”を示す。この変動する“転送遅延”は受信側曲線（Ｒ）と伝送側曲線（Ｔ）間のＸ軸差分により表され、一方、“クライアントバッファリング遅延”は再生曲線（Ｐ）と受信側曲線（Ｒ）間のＸ軸差分により示される。したがって、“終端間遅延”は、再生曲線（Ｐ）とサンプリング曲線（Ｓ）間のＸ軸差分により表されものであるが、“サーババッファリング遅延”と、“転送遅延”と、“クライアントバッファリング遅延”との合計となることを理解すべきである。
【００５７】
累積データ軸に沿ってグラフを見ると、受信側曲線（Ｒ）と再生曲線（Ｐ）との間のＹ軸差分は、所定時におけるクライアントバッファ内のデータ量を示す。伝送側曲線（Ｔ）と受信側曲線（Ｒ）間のＹ軸差分は、所定時にすでに伝送されているが、受信側（ストリーミングクライアント）ではまだ受信されていないデータ量である。
【００５８】
シフトされた送信側（ＳＴ）曲線は、ストリーミングクライアントにおける前置復号器バッファリングとジッタバッファリングの分離を示すものである。ゼロ累積データにおける再生曲線（Ｐ）とシフトされた送信側曲線（ＳＴ）との間のＸ軸差分（図２の（ｔ（Ｐ０）−ｔ（ＳＴ０））により示される）は、推奨された初期の前置復号器バッファリング遅延を示し、この遅延は、一定遅延チャネルを介して伝送されたストリームを適用して復号化するのに十分な遅延である。ゼロ累積データにおけるシフトされた伝送側曲線（ＳＴ）と受信側曲線（Ｒ）間のＸ軸差分（図２で（ｔ（ＳＴ０）−ｔ（Ｒ０））として示される）は、パケット転送遅延の変動補償用としてクライアントが適用する初期のジッタバッファリング遅延である。
【００５９】
受信側曲線がクライアントのバッファアンダーフローを引き起こすことなくシフトされた伝送側曲線を数回横切るという事実は、本発明に基づいて、ジッタバッファリング遅延と共に前置復号器バッファ遅延をまとめて処理することの有用性を示すものである。ＲＴＣＰ報告を通じて、サーバがさらに大きなパケット転送遅延の変動を検出できることを仮定している。また、サーバは、レート制御および／またはレート整形を適用して、該パケット転送遅延の変動を補償することも可能となる。図２の例では、クライアントバッファリングがパケット転送遅延の変動を補正できるほど十分なものであるため、サーバは実際には補正用レートの適合化を何も適用する必要はない。もしサーバがクライアントバッファリングパラメータを認識していなければ、サーバはレート制御および／またはレート整形を不必要に適用することになるであろう。
【００６０】
クライアントバッファリングパラメータを信号伝送するための規定
クライアントバッファリングパラメータを含む信号メッセージの伝送はいつでも可能であるが、クライアントが所定のストリーミングセッション用として実際に使用しているバッファリングパラメータを正確に知っているときはいつでも、この信号メッセージを直ちに伝送するのが最も有効である。この信号メッセージは遅延上決定的に重要なメッセージではなく、あるいは、サーバ時間と同期をとる必要があるメッセージというわけでもない。というのは、クライアントバッファリングパラメータは通常、より長期間の間一定であり、非常にまれにしか変化しないからである。例えば、通常、新たなメディア再生の開始後（すなわち新たなＲＴＳＰ再生要求後毎回）、新たなクライアントバッファリングパラメータを信号伝送する必要が生じるにすぎない。
【００６１】
ストリーミングクライアントが、バッファリングパラメータのうちのいずれかのパラメータを再生中に動的に変更する場合（クライアントがしばらくの間再生を休止したり、遅延させたりし、それによって初期のバッファリング遅延を変更する場合など）、ストリーミングクライアントは、新たなバッファリングパラメータ値と共に新たな信号メッセージをストリーミングサーバへ伝送することができる。
【００６２】
実施構成
ストリーミングサーバが再生要求に対して伝送するＯＫ応答メッセージに関連するＴＳ２６.２３４“添付資料Ｇ．２ＰＳＳバッファリングパラメータ”に定められているように、本発明に基づいて、同じＲＴＳＰ拡張パラメータを用いて信号メッセージの伝送を行うことができる。ＴＳ２６.２３４に定められているように、ＲＴＳＰ拡張パラメータは以下のようなものとなる：
- x-predecbufsize：＜仮説の前置復号器バッファサイズ＞
（このサイズは、添付資料のＧ仮説の前置復号器バッファの提案されたサイズをバイトで示すものである）
- x-initpredecbufperiod：＜初期の前置復号器バッファリング時間＞
（このバッファリング時間は、添付資料Ｇに従って指定された初期の前置復号器バッファリング時間を示すものである。値は９０ｋＨｚクロックの計時チクタク刻みと解釈される。すなわち、値は１／９００００秒毎に１だけ増分される。例えば、値１８００００は２秒の初期の前置復号器バッファリング時間に対応する）。
- x-initpostdecbufperiod：＜初期の後置復号器バッファリング時間＞
（このバッファリング時間は、添付資料Ｇに従って指定される必要な初期の後置復号器バッファリング時間を示すものである。値は９０ｋＨｚクロックの計時チクタク刻みと解釈される。
【００６３】
上記パラメータのすべてまたはほんのいくつかをクライアントからサーバへの信号メッセージの中に含むことが可能である。クライアントからサーバへの信号メッセージ用として上記パラメータとは異なるパラメータを定めることも可能である。
【００６４】
クライアントはＲＴＳＰオプション要求時に上記ＲＴＳＰパラメータを伝送することができる。したがってサーバは、このような要求に応答し、セッションタイムアウトタイマのリセットを行う必要がある。これが行われなかった場合、上記のようなオプション要求はサーバ状態に影響を与えないことになる。
【００６５】
例えば、実際の初期のクライアントバッファリング時間が１／２秒である旨をクライアントが要求時に信号で伝送した場合、“初期の前置復号器バッファリング時間”パラメータは再使用される（下記に記載の例示のＲＴＳＰオプション要求）。
C->S:  OPTIONS *RTSP/1.0
CSeq: 833
Session: 12345678
x-initpredecbufperiod: 45000
S->C:  RTSP/1.0 200 OK
CSeq: 833
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
【００６６】
クライアントは、アクティブな再生状態（すなわち、休止の入らない再生状態）のままで、空のＲＴＳＰ再生要求の形で（すなわち、ストリーミングクライアントからストリーミングサーバへの“範囲”ヘッダなしで）上記ＲＴＳＰパラメータの伝送を行うことも可能である。ＩＥＴＦ  ＲＦＣ２３２６に準拠するストリーミングサーバは、アクティブな再生状態にある間（すなわち、サーバが、要求された再生範囲からのパケットの伝送をまだ終了していない場合）受信した空の再生要求に対してアクションを行う必要はないが、生じる可能性のある誤解釈に関して注意を払う必要があり、したがって再生要求もキューを受ける場合がある。その場合、再生要求によって、現在の再生範囲が終了するとすぐに、ストリーミングの停止位置からストリーミングを再開すべき旨が示される。以下の例は、空のＲＴＳＰ再生要求を用いて、前置復号器バッファリングパラメータの信号伝送を可能にする本発明に基づく方法を示すものである：
C->S： PLAY rtsp://audio.example.com/twister.en RTSP/1.0
CSeq: 833
Session: 12345678
x-initpredecbufperiod: 45000
S->C:  RTSP/1.0 200 OK
CSeq: 833
【００６７】
クライアントはＲＴＳＰピング要求の形でこれらのＲＴＳＰパラメータの伝送を行うことも可能である。
【００６８】
サーバは、クライアントバッファリングパラメータ拡張子を理解した場合、一般に、現在アクティブな再生状態の信号伝送された実際のクライアントバッファリングパラメータ（すなわち、ストリーミングセッションの範囲内の最後に要求された再生範囲に対してのみ適用）について考慮すべきである。
【００６９】
本発明が、ストリーミングクライアントとサーバとによる協同的アルゴリズムと関係するものであることに留意されたい。本発明は、クライアントとサーバの双方がストリーミングの協同的アルゴリズムを実現する場合、有効なものとなる。すなわち、クライアントがストリーミング時刻にバッファリングパラメータを伝送する場合、サーバはそのレート制御時にこの情報を実際に利用する。ストリーミングサーバとクライアントの双方は、能力／交換を用いて、信号伝送方法をサポートすることが可能となる。この特徴の名称を規定する多くの可能性が存在することに留意されたい。当該可能性のうちの１つの可能性として、例えば、“クライアント・バッファリング・パラメータ・シグナリング（client-buffering-parameters-signaling）”が挙げられる。以下のように最初の設定要求時に上記名称を信号伝送することができる。
C->S:  SETUP rtsp://audio.example.com/twister.en/video RTSP/1.0
CSeq: 3
Require: client-buffering-parameters-signaling
サーバは、上記特徴をサポートしていない場合、下記の例のように“サポートなし（unsupported）”フィールドを返送する必要がある：
S->C:  RTSP/1.0 200 OK
CSeq: 3
Unsupported: client-buffering-parameters-signaling
＜他の設定関連パラメータ＞
【００７０】
クライアントは、上記特徴がサポートされていない旨を理解するとすぐに、オプション要求でこのようなパラメータを伝送しないことになる。“unsupported”ヘッダが存在しない場合（これは、サーバが上記特徴をサポートしていることを示すものであるが）、クライアントはクライアントバッファリングパラメータをストリーミングサーバへ安全に信号伝送することが可能となる。クライアントは、上記特徴がサポートされていることが解るとすぐに、クライアントバッファリングパラメータ（オプション要求時に、範囲ヘッダのない再生要求か、PING（ピング）要求かのいずれか）を安全に信号伝送することが可能となる。
【００７１】
本発明の好ましい実施形態と関連して本発明について説明したが、本発明の範囲から逸脱することなく、形態および細部における本発明の上述の種々の変更、省略および逸脱並びにその他の種々の変更、省略および逸脱を行うことが可能であることは当業者の理解するところであろう。
【図面の簡単な説明】
【００７２】
【図１】本発明に準拠するシステムマルチメディアストリーミングを示すブロック図である。
【図２】マルチメディア・ストリーミングシステムにおける異なるバッファでの遅延の１例を示すチャートである。
【図１】
2006500797.tif 000003
【図２】
2006500797.tif 000004
【国際調査報告】
2006500797.tif 000005
2006500797.tif 000006