JP2007089137A - ロバストなストリーミングを行うためのサーバメディア処理による適応型メディアプレイアウト - Google Patents

Abstract

【課題】プレイアウト遅延時間を長くすることなく、プレイアウトロバストネスを高める。
【解決手段】ビデオを送信するためのシステムは、ビデオの一時的時間の間の第１の複数のフレームに基づき、前記ビデオの前記一時的時間の間、第２の複数のフレームを作成する送信機を含む。このフレームの作成は、前記第２の複数のフレームが、前記第１の複数のフレームよりも多い数のフレームを含むように実行される。前記送信機は、受信機が前記第２の複数のフレームをレンダリングするフレームレートよりも大きいフレームレートで、前記第２の複数のフレームを受信機に送信する。
【選択図】図４Ａ

Description

ソースデバイス、例えば、ホームサーバからネットワーク例えばローカルエリアネットワーク（ＬＡＮ）を通して１以上の受信デバイス例えば家庭内のテレビセットへ、オーディオ／ビデオ（ＡＶ）ストリームの高品位でかつロバストな送信を行うことが望ましい。かかるネットワークとして、有線リンク（例えば、イーサネット）、無線リンク（例えば、ＩＥＥＥ８０２.１１無線リンク）またはパワーラインリンク（例えば、ホームプラグ）に基づく相互接続を挙げることができる。アプリケーションは、記憶されたオーディオおよびビデオストリームの送信（ストリーミング）を必要とし、更にアプリケーションは、ライブのオーディオおよびビデオの送信を必要としたり、あるレベルの相互対話、例えばチャネル変更を必要とし得る。従って、エンド−エンドの最大の遅延時間は、通常、１秒または数秒に制限される。

無線ネットワーク（例えば、ＩＥＥＥ８０２.１１に基づくネットワーク）およびその他のタイプのホームネットワークの利用可能なバンド幅は、制限され、時間に対して変化し、種々の理由に起因して予測できない。高品位のＡＶストリームは比較的広いバンド幅を連続的に必要とすること、およびＡＶデータの配信に対する厳密な遅延時間の制約に起因し、かかるネットワークを通して圧縮されたＡＶストリームを送信することは困難である。ネットワーク条件が劣化する結果、ＡＶデータを搬送するパケットが失われたり、遅延することがある。配信デッドラインを経過後に受信機に到達した遅延パケットも失われたものと見なすことができる。失われたか、または受信機に遅れて到達したＡＶデータは、レンダリングされた出力における許容できない歪みを生じさせたり、レンダリングの中断を生じさせたりし得る。

パケットネットワーク（例えば、ストリームメディアシステム）を通してオーディオ／ビデオ送信するためのシステムは、受信機に設けられたバッファ、例えば、送信バッファおよび／またはデコーダバッファを利用できる。ネットワークから受信したＡＶデータを有するパケットは、ＡＶデコーダに送られる前にこれらバッファに一時的に記憶される。これらバッファは、ＡＶデータを有するパケットがネットワークを横断してトランスポートされる際に生じた遅延のばらつき（遅延ジッタ）を吸収する。このようなバッファリングは、デコーダバッファがアンダーフロー状態になる確率−すなわち、送信遅延時間の変動に起因してＡＶデータが受信機に遅れて到達する事象を低減する。かかる事象が生じる結果、受信機でのＡＶストリームの歪みまたはレンダリングの中断が生じる。従って、バッファリングはプレイアウトのロバストネスを高める。

圧縮されたオーディオ／ビデオデータをパケットネットワークを通してストリーミングするためのシステムで共通するプレイアウトの遅延を、受信機側のデータバッファリングに起因して低減することが望ましい。プレイアウトの遅延は、スタートアップ遅延またはスタートアップレイテンシーとも称される。例えば、新しいストリームをスタートするとき、またはストリームを切り換えるときに、ストリーミングメディアシステムのユーザは、この遅延時間を、ＡＶメディアストリームを再生するためのリクエストに対する応答の遅延として経験する。例えば、インターネットを通したメディアストリーミングにおいて、オーディオ／ビデオコンテンツを再生することをリクエストしたユーザは、受信機がＡＶデータをバッファリングしている間、コンテンツがレンダリングされるまで何秒も（例えば、５秒または１０秒）待機しなければならないことがある。しかしながら、テレビ受像機のユーザはチャネル変更のようなリクエストに即座に応答することに慣れているので、特に放送用テレビ受像機としても機能する高品位ディスプレイに、ホームネットワークを介して高品位のオーディオ／ビデオメディアをストリームするシステムには、これに対する解決案が求められている。

プレイアウトロバストネスを高めるための従来の方法は、例えば、デコーダでバッファされるデータ量を多くすることにより、プレイアウトの遅延時間を長くすることであった。しかしながら、これによりユーザのリクエストに対するシステム応答の遅延時間が長くなることによるユーザの満足度が低下するという代償が生じる。プレイアウト遅延時間を長くすることなく、プレイアウトロバストネスを高めるか、またはプレイアウトロバストネスを低下することなく、プレイアウト遅延時間を短縮するか、またはプレイアウト遅延時間を短縮すると共にプレイアウトロバストネスを高めることができることが望まれている。

受信機側でメディアを処理することにより、基本的な適応型メディアプレイアウト（ＡＭＰ：Ａｄａｐｔｉｖｅ Ｍｅｄｉａ Ｐｌａｙｏｕｔ）が実現されるが、この方法は、受信機側でのコストが大きくなるという欠点がある。更に、現存の受信機は、ＡＭＰを実施する能力を有していない。

ＡＭＰの１つの欠点は、オーディオ／ビデオデータを送信スタート前に予め符号化し、サーバに記憶するというシナリオにしか適用されないことである。従って、この方法はライブのオーディオ／ビデオ入力のシナリオには適用できない。

上記の課題を解決するために、本発明は、ビデオの一時的時間の間の第１の複数のフレームに基づき、前記ビデオの前記一時的時間の間、前記第１の複数のフレームよりも多い数のフレームを含む第２の複数のフレームを作成する送信機を含み、前記送信機は、受信機が前記第２の複数のフレームをレンダリングするフレームレートよりも大きいフレームレートで前記第２の複数のフレームを受信機に送信することを特徴としたものである。

このシステムは、適応型メディアプレイアウト（ＡＭＰ）を達成するための１つの技術として理解できる。ＡＭＰでは、メディアプレイアウトレートは、受信機（クライアント）のバッファのフルネスに適合される。特に、ストリームセッションの開始時には、プレイアウトレートは一時的に通常のレート（例えば、ビデオフレームレート）よりも減少され、これによって受信機は、受信機のバッファがフル状態となり続ける間、メディアのレンダリングをスタートすることにより、スタート時のレイテンシーを低減できる。従来は、低下したレートでのビデオのプレイアウトは次の方法のうちの１つによって受信機（クライアント）側で実現されている。すなわち、（ａ）各ビデオフレームを表示する時間の長さを長くし、よって、ディスプレイのフレームレートを低下する方法、（ｂ）ディスプレイのフレームレートを通常のフレームレートに維持しながら、表示すべきフィールド／フレームの数を多くする方法によって実現される。後者の方法（ｂ）は、例えば、フィールドまたはフレームの繰り返しにより、またはフレーム補間により、可能な場合には動き補償フレーム補間により、ビデオフレームレートを変換する方法である。オーディオデータは別個に処理され、好ましくはピッチを変えることなく時間スケーリングすることができる。ＡＭＰは時間スケール変更方法とも称すことができる。

受信機（クライアント）でのＡＭＰの実現には、オーディオおよびビデオの特別な処理が必要であるという欠点があり、これによって受信機のコストが高くなる。代表的な放送用テレビ受像機は、受像機側でＡＭＰを実現する能力を有していないので、ＡＭＰが提供するプレイアウトのロバストネスを改善できるという利点を活用できない。

適応型プレイアウトを実現するためには、受信機（クライアント）側ではなく、送信機側（サーバ側）でフレームレート変換を実行することが好ましい。更に、フレームレートが増加した変換済みのビデオストリームを、高いフレームレートで送信する。すなわち、元の入力ビデオストリームにおけるビデオフレーム数と比較して、１秒当たりの数がより多いビデオフレームを送信する。一秒あたりの数が多いビデオフレームが送信されるので、チャネル条件を適切に検討しながら、ビデオ送信ビットレートを制御するのに、ビデオビットレート適応化法を利用できる。特に、バンド幅が制限されたチャネルの場合、一秒あたりに送信すべき数が多いビデオフレームを部分的に補償するために、ビデオビットレートを低減できる。最後に、受信機（クライアント）側では、通常のフレームレート、すなわち元の入力ビデオストリームのフレームレートでビデオを再生する。受信機（クライアント）のバッファは、バッファから検索されるよりも高いレートでチャネル（ネットワーク）からフレームを受信するので、時間と共にバッファのフルネスが増加する。時間スケール変更に関してこの結果生じる効果は、従来のＡＭＰで得られる効果と同じである。受信機（クライアント）におけるタイムスケーリングを達成するために、送信機（サーバ）はＡＶストリーム内の適切なプレゼンテーションタイムスタンプを変更することができる。更に、送信機（サーバ）でもオーディオストリームのタイムスケール変更が実現される。変更されるオーディオストリームに対して必要な送信ビットレートの潜在的な増加量は小さいと予想されるので、（必要である場合、オーディオビットレート適応方法も適用できるが）更に検討を必要としない。この方法をサーバメディア処理による適応型メディアプレイアウト（ＡＭＰ−ＳＭＰ：Ｓｅｒｖｅｒ Ｍｅｄｉａ Ｐｒｏｃｅｓｓｉｎｇ）と称すことができる。

ＡＭＰの従来のクライアント側の実現例と比較した、本発明の結果得られるＡＭＰ−ＳＭＰシステムの主な利点は、クライアント側からＡＭＰを達成するための特殊な処理および関連する複雑さを取り除くことができることにある。ＡＭＰ−ＳＭＰシステムでは、クライアントは基本的にはＡＭＰを全く有しない従来のシステムにおけるクライアントと同一である。従って、受信機（クライアント）のコストを高めることなく、ＡＭＰの有利な効果を得ることができる。ＡＭＰ−ＳＭＰは、受信機内の基本的なオーディオ／ビデオ処理を変更することなく、放送用受信機に基づくクライアントのためのロバストなプレイアウトの利点を提供できる。ＡＭＰ−ＳＭＰシステムの別の利点は、予め符号化されたオーディオ／ビデオのストリーミングの他に、このシステムをライブのオーディオ／ビデオコーディングシナリオに適用できることにある。このことは基本的なＡＭＰにもあてはまる。

更に、（バンド幅制限に起因し）ビットレートを適用をするＡＭＰシステムと比較した、ビットレートを適用するＡＭＰ−ＳＭＰシステムの利点は、エンコーディング前、またはトランスコーダによりビットレート低減を実施する前に、送信機（サーバ）においてフレームレート変換を元の入力ビデオに実施できることである。エンコーダまたはトランスコーダが入力ビデオのビットレートを低下するシステムにおいて、クライアント側のフレームレート変換を実施することと比較し、サーバ側のフレーム変換を実施する結果、画質変換がより良好となるという結果を得ることができる。

変換されたＡＶストリーム（高いフレームレートを有する）のビットレートを、送信側（サーバ）で適応させることができ、利用できるチャネル（ネットワーク）のバンド幅だけでなく、他のシステムおよびチャネル条件に応じてビットレートを決定してもよい。チャネル条件の限界および変化を考慮することも可能である。リアルタイムのトランスコーディングの使用およびＡＶストリームのビットレートの適応化は、フレームレート変換と共にＡＶの質を最適にし、適応型メディアプレイアウトを達成できる。

更に、遅延時間が制限されたレート適応化方法を使って、ＡＶストリームのビットレートを制御できる。この方法を利用する場合、エンド−エンドの遅延時間に対する制限を決定し、１秒あたりにトランスコードされ、送信されるビデオフレームの数が多くなり、プレイアウトの遅延時間が短縮しているケースでも、ビデオフレームが実質的に時間どおりに到達するようにＡＶストリームのビットレートを適応化する。遅延時間が制限されたレート適応化は、送信中のビデオフレームの予想される遅延時間を考慮してもよいし、またＡＶデータの送信をするために利用できる予想されるバンド幅を考慮してもよい。従って、チャネルバンド幅の限界および変動を考慮できる。遅延時間が制限されたレート適応化は、システムのステータス、例えば、システム内の種々のバッファ、例えばエンコーダバッファ、デコーダバッファおよびその他バッファのフルネスも考慮できる。適応化メディアプレイアウトを達成するために、フレームレート変換と組み合わせて遅延時間制限されたレート適応化を使用することは、本発明の別のユニークな特徴となっている。

別の態様は、送信機／サーバでのフレームレート変換プロセスおよびその後のエンコーディングまたはトランスコーディングプロセスを互いに知り、視覚的な画質を得るために共に最適化できるよう、システムを設計できることである。あるいは、フレームレート変換およびエンコーディング／トランスコーディングを１つのプロセスで共に実現することができる。すなわち、フレームレート変換をエンコーダまたはトランスコーダによって実現し、視覚的な画質を改善できる。

別の態様は、クライアントがＡＭＰを実行できるとき、サーバおよび／またはクライアントの双方によってメディアプレイアウトを適応化できることである。サーバは、自らとクライアントとの間のＡＭＰ処理の分割を共に最適化し、クライアント側で送信するビデオフレームの数および補間するフレーム数を最適に選択できる。

始動時のレイテンシーを低減できるようにプレイアウトレートを低減することは重要な特徴であるが、ＡＭＰは、送信中のエンド−エンドの遅延時間、すなわち、レイテンシーを低減するためにプレイアウトレートを大きくすることも含む。このことは、ライブのオーディオ／ビデオ入力の場合に有効である。その理由は、ライブの事象を表示するときにレイテンシーを大きくすると顕著になるので、制限なくレイテンシーを大きくすることは望ましくないからである。ＡＭＰ−ＳＭＰを用いた場合、送信機におけるフレームレートを低減することによって、受信機でのプレイアウトレートの増加を実現できる。この場合、フレームレートを変換することは、例えば、ビデオストリームからフレームまたはフィールドをドロップすることにより、フレームレートを低減することを意味する。このことは、このケースにおいて、送信機から受信機へ低減された数のフレームを送信するだけで良いことを意味する。更に、このことは、かかる時間インターバル中に、送信機により、高い品位でビットストリームを符号化できることを意味する。従って、基本的ＡＭＰと比較したＡＭＰ−ＳＭＰの別の利点は、ある時間インターバル中に、より高い画質のビデオを受信し、表示できることである。

図１は、従来のプレイアウトと比較してスタート時のより短いプレイアウト遅延時間、または同じプレイアウト遅延時間で、より高いプレイアウトのロバストネスのいずれかを得るために、どのようにＡＭＰを使用できるかを示す。時間ｔ_０でスタートすると、図の左側の実線の曲線で示されるように、送信機／サーバで周期的にビデオフレームが符号化またはトランスコードされる。点線の曲線で示されるように、ランダムな時間インターバルの後で受信機／クライアントでパケット化されたビデオデータが受信される。プレイアウトの前において、受信機にビデオデータが一時的にバッファ化される。従来は、周期的に、すなわち通常フレームレートの固定レートでビデオフレームのプレイアウトが行われていた。図中、点線の曲線によって従来のプレイアウトスケジュールの例が示されており、１つの曲線はｔ_１でスタートし、他方の曲線はｔ_２でスタートしている。ｔ_１の場合、より短いプレイアウト遅延時間（スタート時のレイテンシー）が結果として生じる。しかしながら、この例では、いくつかのフレームのためのビデオデータが遅い時期に到達する。ｔ_２の場合、より長いプレイアウト遅延時間が結果として生じる。しかしながら、この例では、すべてのビデオフレームに対するすべてのデータは受信機に時間どおり到達する。実線の曲線は、ＡＭＰを使用したときの配信／プレイアウトデッドラインを示す。ＡＭＰを用いると、プレイアウトレートはスタート後、一時的に低減する。このような低減されたプレイアウトレートの初期の段階の後で、正常なレートでのプレイアウトがスタートする。ｔ_１でスタートする従来のプレイアウトスケジュールと比較すると、ＡＭＰを用いた場合のプレイアウトスケジュールの結果、スタート段階後にプレイアウトロバストネスがより良好となる。ｔ_２でスタートする従来のプレイアウトスケジュールと比較すると、ＡＭＰを用いたときのプレイアウトスケジュールの結果、スタート時のプレイアウト遅延時間は短縮される。図１では、スタート時の段階は短時間の間しか継続せず、図解のために、プレイアウトレートの低減量は比較的大きくなっていることに留意されたい。実際の実現例では、公称プレイアウトレートに対するプレイアウトレートの変化は、より小さくなり得るが、（プレイアウトレートを低減している間の）スタート段階の時間の長さはより長くなり得る。

図１に示されるように、スタート時にＡＭＰを使用できるが、ＡＭＰはスタート段階後も使用できる。一般的なＡＭＰは、プレイアウトレートを低減することを含むことができるが、プレイアウトレートを大きくすることもできる。現在のシステムでは、ＡＭＰは、各フレームを表示する時間の長さを長くするか、または表示すべきフレーム／フィールドの数を多くすることによって、受信機により実現される。プレイアウトレートの制御は、送信機側または受信機側のいずれかで行うことができる。

図２は、スタート時の適応型プレイアウトを実現するのに、サーバメディア処理による適応型メディアプレイアウト（ＡＭＰ−ＳＭＰ）をどのように使用できるかを示す。説明のために、この効果の大きさは再度強調されていることに留意されたい。ＡＭＰ−ＳＭＰを用いることにより、スタート段階中に受信機（クライアント）の代わりに、送信機（サーバ）側でフレームレート変換を実現する。従って、１秒につき、符号化し送信すべきビデオフレームの数は、この段階中に増加される。送信機（サーバ）は、受信機にて所望するプレイアウトスケジュールに従うよう、現在のビデオフレームおよび新しく発生されたビデオフレームのプレゼンテーションタイムスタンプ（ＰＴＳ：ｐｒｅｓｅｎｔａｔｉｏｎ ｔｉｍｅ ｓｔａｍｐｓ）およびデコーディングタイムスタンプ（ＤＴＳ：ｄｅｃｏｄｉｎｇ ｔｉｍｅ ｓｔａｍｐｓ）を変更することもできる。更に、１秒あたりの多くされた数のビデオフレームを送信しなければならないので、送信機（サーバ）は符号化されたビデオストリームのビットレート（すなわち、符号化されたフレームあたりのビット数）を変更することもできる。ビデオビットレートは、チャネル（ネットワーク）の条件（例えば、バンド幅）に適合できる。受信機は、符号化されたビデオフレームを受信し、通常のディスプレイレートで、すなわち、フレームレート変換前のビデオストリームの公称フレームレートで、ビデオフレームを再生する。フレームレート変換を受けたビデオのセグメントは、元のビデオストリームと比較して、増加した数のフレームを含む。従って、このセグメント内のフレームが通常のディスプレイレートで再生されるとき、このセグメントのプレイアウトの時間の長さは、元のビデオストリームの同じセグメントの時間の長さまで長くなる。この例から明らかなように、このシステムは、受信機で更なる処理をすることなく、受信機にて適応型プレイアウトを達成できる。実際に受信機は、適応型プレイアウトが達成されたということに気が付かないことがあり得る。適応型プレイアウトを達成するのに必要なすべてのビデオ処理は、サーバで実現できる。オーディオ成分のタイムスケーリングに必要な更なるオーディオ処理も、サーバで実現することができる。

図３Ａには、ＡＭＰ−ＳＭＰを有するオーディオ／ビデオ送信システムのブロック図が示されている。送信機の入力端にあるソースオーディオ／ビデオストリームは、記憶媒体で利用できる予め符号化されたストリーム、またはライブの入力ストリームのいずれかでよい。ソースストリームのオーディオおよびビデオ成分は、送信側でタイムスケーリングを受ける。このタイムスケーリングは、ビデオ成分の場合、フレームレート変換（ＦＲＣ：ｆｒａｍｅ ｒａｔｅ ｃｏｎｖｅｒｓｉｏｎ）によって実現される。更に、オーディオおよびビデオコンテンツの対応する部分が実質的に同期状態のままとなるように、送信側でオーディオ成分のタイムスケーリングが実行される。入力がデジタル式に圧縮されたビデオストリームである場合、フレームレート変換はビデオトランスコーダによって適宜実現できる。このビデオトランスコーダは、例えば、タイムスケーリングファクターおよび予想チャネル条件に適合することによって、出力ビットレートを適切に制御することもできる。入力が圧縮されていないビデオデータである場合、フレームレート変換とビデオ符号化とを別個のプロセスにすることができる。いずれのケース（圧縮または非圧縮）においても、フレームレート変換とビデオ符号化とは、ビデオの画質をできる限り最良にするように協働して最適化することができる。符号化されたオーディオ／ビデオデータは、その後チャネルまたはネットワークを横断するようなトランスポートのためのスケジュールが定められる。送信側におけるトランスポートモジュールは、更なる処理、例えばパケット化だけでなく、例えば無線送信機も示している。受信機では、符号化されたオーディオ／ビデオデータが一時的にバッファ化され、その後復号される。図３Ｂに示されるように、受信機はフレームレート変換（ＦＲＣ）をすることも可能であるし、またはしなくてもよい。受信機におけるフレームレート変換能力は、デコーダと統合してもよいし、または別個でもよい。受信機におけるトランスポートモジュールは、別の処理、例えば逆パケット化だけでなく、例えば無線受信機も示す。

図３Ａにおける送信制御モジュールは、送信側におけるオーディオ／ビデオタイムスケーリング、ビデオにいつフレームレート変換を適用するか、フレームレート量をどれだけ増減するか、どのターゲットビットレートを使用するかを制御し、更に、符号化されたオーディオ／ビデオデータを適切なレートで送信するようにスケジューラを制御する。

サーバにおけるフレームレート変換が送信すべき別のビデオフレームを発生するので、チャネル容量に応じてビットレート適応化が必要となり得ることに留意されたい。しかしながら、現在のビデオフレームから別のビデオフレームが発生されるので、サーバはかかるフレームを極めて効率的に符号化できる。

フレームレート変換なる用語は、一般的に使用されていることに留意されたい。フレームレート変換は、フレームまたはフィールド繰り返し、フレームまたはフィールド補間、動き適応補間、動き補償補間などによって実現できる。フレームレート変換は、例えばフレームまたはフィールドをドロップすることにより、フレームレートを低減することもできる。スローダウンする代わりに、プレイアウトのスピードアップを達成するのにフレームレート低減を使用できる。このような能力は、ライブのオーディオ／ビデオ入力のケースで有利である。

サーバにおけるオーディオ／ビデオデータの処理は、入力信号の性質に応じ、またビットレート適応化の必要性に応じて、いくつかの態様で実現できる。２つのメインとなるタイプの実現例を、ピクセル−ドメインフレームレート変換と、圧縮−ドメインフレームレート変換と称すことができる。

ピクセル−ドメインフレームレート変換：
フレームレート変換は通常、ピクセルドメイン内、すなわち圧縮されてないビデオフレーム上で実施される。図４には、ピクセル−ドメインフレームレート変換を行う２つのＡＭＰ−ＳＭＰアーキテクチャの例が示されている。図４Ａでは、サーバへの入力は圧縮されていないビデオであるが、図４Ｂでは、サーバへの入力は圧縮されたビデオである。後者のケースでは、ピクセルドメイン内のフレームレート変換を実行できる前に、まず圧縮されたデータを復号しなければならない。組み合わされたデコーダと変換器とエンコーダとが、１つのビデオトランスコーダを形成している。

第１のケースでは、フレームレート変換を復号化または符号化のいずれかと別個に実施できる。

第２のケースでは、エンコーダは、このエンコーダが受信したビデオフレームのうち、どれが元の入力フレームであるのか、どのフレームが補間されたフレームであるのかを知る。このケースでは、エンコーダはかかる補間されたフレームを極めて効率的に、すなわち、比較的少ないビットで符号化できる。例えば、現在のすべてのビデオ符号化規格、例えばＭＰＥＧ−１、２、４、Ｈ.２６３、Ｈ.２６４などは、１つのフレームをＩフレーム、ＰフレームまたはＢフレームとして符号化するオプションを示している。このケースでは、補間されたフレームをＢフレームとして符号化することが有利である。更に、有効な予測を可能にし、従って、かかるビデオフレームの高度に圧縮された符号化を可能にするこれら符号化規格には種々のオプションが存在する。

第３のケース（図４Ｂに示されたアーキテクチャに適用できる）では、フレームレート変換および／またはエンコーダモジュールには、デコーダによって入力ビデオストリームに関するデータを提供できる。例えば、符号化された入力ビデオストリーム内で利用できる動きベクトルは、フレームレート変換プロセスによって再使用できる。これによって、フレームレート変換器は計算上費用のかかるプロセスである動き予測を必要とすることなく、動き補償されたフレームレート変換を実施できる。このような動き補償された処理によって、画質がより良好となる。別の例は、入力ストリームの符号化の複雑性に関する情報であり、この情報はデコーダによって得ることができ、エンコーダに提供できる。これによって、改良されたビットレート制御が可能となる。

圧縮−ドメインフレームレート変換：
図５には、圧縮−ドメインフレームレート変換を行う２つのＡＭＰ−ＳＭＰアーキテクチャの例が示されている。図５Ａでは、変換の結果得られるビットストリームのビットレートに適応することなくフレームレート変換が実施される。図５Ｂでは、フレームレート変換の後にトランスコーディングが続き、このトランスコーディングは、送信前にビットストリームのビットレートに適応する。図５Ａのアーキテクチャは、チャネル／ネットワークバンド幅が常に変換されたビットストリームの送信に必要なビットレートよりも高いと予想されるときに適用できる。ここで、１秒当たりに送信すべきフレーム数は、ＡＭＰ−ＳＭＰの場合、ＡＭＰ−ＳＭＰを用いないケースと比較して多くなることに留意されたい。チャネル／ネットワークの条件が大幅に変化すると予想されるとき、または変換されたビットストリームのビットレートが所定の値の場合に、チャネルバンド幅が不十分であるときに図５Ｂのアーキテクチャはより適切となる。トランスコーダは、圧縮されたビデオのビットレートを、現在のおよび予想される条件に適応させることができる。

これまで、圧縮されたドメインではフレームレート変換は実行されていない。しかしながら、ビデオビットストリームを直接操作することによって、圧縮されたドメイン内で簡単なフレームまたはフィールド繰り返しを行うことができる。特に、ＧＯＰ内のＢフレームとして符号化されたフレームを繰り返すことは、少ないエクストラビットしか必要としないので有利となり得る。

サーバ側およびクライアント側のメディア処理能力を有するＡＭＰ：
例えば、フレームレート変換または他の手段により、クライアントがＡＭＰを実現する能力を有するケースでは、サーバはフレームレート変換を起動したり、またはクライアントが自らＡＭＰを実現させるように、適応的に決定できる。すなわち、サーバは種々の制限に基づき、次のことを選択できる。
ａ．クライアントによる更なる処理を必要とすることなく、サーバにおいてフレームレート変換によりＡＭＰを実現すること；
ｂ．ＡＭＰを実施する固有のサーバにおける処理を実行せず、クライアントに必要な処理を実行させること；
ｃ．ＡＭＰのために送信すべきフレームの最適な数、およびクライアントにおいて補間すべきフレームの数を適応的に選択すること。

サーバは、次のことを含む種々の要因に応じて、最適な方針を選択できる。
ａ．チャネル／ネットワーク条件。例えば、チャネルバンド幅が広いときに、サーバは自らフレームレート変換を実行し、クライアントと比較して、より高い品位のフレームを処理できるということを活用することを選択できる。クライアントは、圧縮を受けたフレームを処理しなければならないこと、およびあるケースでは、オーディオ／ビデオデータは送信中に失われる可能性があることに留意すべきである。他方、チャネルのバンド幅が狭いとき、サーバは送信するのに必要なフレームの数を最小に選択することができ、クライアントにＡＭＰを行うための処理を実施させる。
ｂ．入力オーディオ／ビデオストリームの符号化の複雑さ。例えば、入力ストリームの符号化が複雑であるとき、サーバにおいてフレームレート変換によって作成される補間されたフレームは、フレームごとのビット数に関して符号化し、送信するのに比較的費用がかかることが予想される。従って、この場合、クライアントがフレームレート変換を実行できるようにすることが好ましい。他方、入力ストリームの符号化が複雑でないとき、補間されたフレームをサーバによって効率的に符号化し、送信することができる。この場合、サーバがフレームレート変換を実行することが好ましい。
ｃ．サーバまたはエンコーダリソース、特に、処理パワーおよびメモリ。エンコーダリソースは、時間経過と共にダイナミックに変化し得る。エンコーダリソースが低く作動しているとき、サーバはクライアントにフレームレート変換を実行させてもよい。エンコーダリソースが高いままのとき、サーバは自らフレームレート変換を実行できる。
ｄ．ユーザの優先順位。サーバ側でフレームレート変換を実行する結果、よりスムーズな動きレンディションのビデオシーケンスが得られるが、フレーム毎の圧縮歪みは多少大きくなる。このことを好むユーザもあるが、動きレンディションが劣化することを代償に、フレーム毎の歪みを少なくすることを好むユーザもある。

サーバがクライアントのＡＭＰに関連した能力を知ることができるようにするためには、かかる能力の信号を送る必要がある。かかる信号送信は、実際のビデオストリーミングをスタートする前に適切なプロトコルを使って実施できる。

毎秒発生し、符号化し、送信するフレームの数の制御：
フレームレート変換プロセスの出力でビデオフレームの数を制御する１つの方法は、元の入力ビデオストリームの公称（フレーム）レートに関するこの数を適応させることである。このことは、毎秒発生し、符号化し、送信するフレームの有効数が、公称フレームレートとスケーリング関数の積であるスケーリング関数によって記述できる。

通常の（公称）フレームレートにおけるプレイアウト中、スケーリング関数は値１.０を有する。

ストリームスタート段階中、このスケーリング関数は、受信機でプレイアウトレートをスローダウンさせるために、１.０よりも大きい値を有する。このことは、１秒当たり大きい数で、すなわち公称フレームレートよりも早く、ビデオフレームが符号化され、送信されることを意味する。

所定のケースでは、フレームレートを低減することも有効である。このことは、通常の値よりも１秒当たりより少ないビデオフレームを符号化し、送信すること、すなわち、公称レートよりも低いレートで符号化し、送信することを意味する。これらケースでは、スケーリング関数は１.０よりも小さい。

適応型メディアプレイアウトを実施するために、固定された時間の間にフレームレート変換を実施できる。あるいは、例えば、所望するシステムステータスが受信されるまで、可変時間の間、フレームレート変換を実施してもよい。例えば、送信側には、デコーダのバッファが所望するフルネスに達したことを受信機によって通知してもよい。

スケーリング関数は、部分的に一定の関数としてもよいし、あるいは、スケーリング関数を時間経過に対して徐々に増減してもよい。また、スケーリング関数はエンコーダのバッファのフルネス（充満度）に応じて変えてもよいし、デコーダのバッファのフルネスに応じて変えてもよい。また、スケーリング関数は、ビデオデータストリームの特性に応じて変えてもよいし、スケーリング関数をビデオフレームの配信またはプレイアウトデッドライン時間に応じて変えてもよいし、更にエンド−エンドの遅延時間に応じて変えてもよいし、送信機によって実質的に制御してもよいし、受信機によって実質的に制御してもよいし、送信機および受信機の双方によって共に制御してもよい。

ビデオストリームのビットレートの制御：
エンコーダまたはトランスコーダの出力において、オーディオ／ビデオストリームのビットレートを制御する１つの方法は、元の入力オーディオ／ビデオメディアストリームのビットレートに対してオーディオ／ビデオストリームのビットレートを適応させることである。この方法では、ＡＭＰ−ＳＭＰを実施しない通常のケースにおいて、チャネルまたはネットワークの利用可能なバンド幅が、元のストリームのビットレートに対して十分であると見なす。

このことは、オーディオ／ビデオストリームのビットレートに対して適用される第２スケーリング関数によって記述できる。エンコーダ出力におけるターゲットビットレートは、入力端におけるビットレートと、ビットレートスケーリング関数との積である。

ストリームのスタート段階中、ＡＭＰ−ＳＭＰを実施しているときのビットレートスケーリング関数は１.０よりも小さい。従って、スタート段階中に、符号化されたビットストリームのビットレートを低減できる。ビットレートスケーリング関数は、第１スケーリング関数に応じて決めることができる。例えば、ビットレートスケーリング関数を第１のスケーリング関数の逆関数とすることができる。ＡＭＰ−ＳＭＰを実施している期間中に、ビットレートスケーリング関数を一定にすることができ、あるいは、ＡＭＰ−ＳＭＰを実施している期間中に、ビットレートスケーリング関数を徐々に変えてもよい。このビットレートスケーリング関数を、ビデオデータストリームの特性に応じて決めてもよい。

エンコーダの出力端におけるオーディオ／ビデオストリームのビットレートを制御する別の方法において、利用できるバンド幅またはチャネルもしくはネットワークのスループットの推定値を考慮してもよい。

エンコーダにおける出力端において、オーディオ／ビデオストリームのビットレートを制御する別の方法は、遅延時間が制限されたレート適応化方法を使用することである。遅延時間が制限されたレート適応化方法を使用することにより、１秒当たりに符号化され、送信されるビデオフレームの数が増加した場合でも、オーディオ／ビデオデータが実質的に時間どおりに到達するように、ビデオストリームのビットレートを適応化させる。遅延時間が制限されたレート適応化方法は、送信中のオーディオ／ビデオデータの予想される遅延時間を考慮したり、またはオーディオ／ビデオデータを送信するための予想される利用可能なバンド幅を考慮してもよい。従って、チャネルバンド幅の制限および変動が必然的に考慮される。遅延時間が制限されたレート適応化方法はシステムのステータス、例えば、システム内の種々のバッファ、例えばエンコーダバッファ、デコーダバッファまたはＭＡＣバッファのフルネスを考慮することもできる。

本願は、２００５年９月１９日に出願された米国仮特許出願第６０／７１８，６２５号に基づく利益を主張するものである。

プレイアウトレートを低減することを示す図である。 適応型メディアプレイアウトを示す図である。 オーディオ／ビデオ送信システムを示す図である。 オーディオ／ビデオ送信システムを示す図である。 ピクセルドメインフレームレート変換を行うＡＭＰ−ＳＭＰを示す図である。 フレームレート変換を示す図である。 圧縮されたドメインフレームレート変換を行うＡＭＰ−ＳＭＰを示す図である。 フレームレート変換を示す図である。

Claims (15)

1. （ａ）ビデオの一時的時間の間の第１の複数のフレームに基づき、前記ビデオの前記一時的時間の間、前記第１の複数のフレームよりも多い数のフレームを含む第２の複数のフレームを作成する送信機を含み、
   （ｂ）前記送信機は、受信機が前記第２の複数のフレームをレンダリングするフレームレートよりも大きいフレームレートで前記第２の複数のフレームを受信機に送信することを特徴とする、ビデオを送信するためのシステム。
2. 前記送信機は、前記送信機と前記受信機との間のチャネルのバンド幅に基づき、前記第２の複数のフレームを送るビットレートを調節することを特徴とする、請求項１記載のシステム。
3. 前記送信機は、前記第１の複数のフレームの予想されるプレゼンテーションレート以外のプレゼンテーションレートに、前記第２の複数のフレームを、前記受信機によるプレゼンテーションのための所望プレゼンテーションレートに変更することを特徴とする、請求項１記載のシステム。
4. 前記第１の複数のフレームが、ライブのビデオであることを特徴とする、請求項１記載のシステム。
5. 前記第１の複数のフレームが、記憶されたビデオであることを特徴とする、請求項１記載のシステム。
6. 前記ビットレートが前記チャネルの狭いバンド幅で低下されることを特徴とする、請求項２記載のシステム。
7. 前記第２の複数のフレームが、前記第１の複数のフレームのフレームレートと異なるフレームレートでレンダリングされるように、前記送信が前記第２の複数のフレームに対するプレゼンテーションタイムスタンプの組を変更することを特徴とする、請求項１記載のシステム。
8. 前記送信機は、前記ビデオをトランスコードすることを特徴とする、請求項１記載のシステム。
9. 前記第２の複数のフレームの前記作成が、その後の送信のために前記ビデオを符号化する前に実行されることを特徴とする請求項１記載のシステム。
10. 前記送信機は、遅延時間制限されたレート適応化を補間することを特徴とする、請求項１記載のシステム。
11. 前記第２の複数のフレームの前記作成とその後の符号化とを共に最適化することを特徴とする、請求項１記載のシステム。
12. 前記送信機と前記受信機とが共に前記作成を最適化することを特徴とする、請求項１記載のシステム。
13. 前記共に最適化するステップが、補間するフレームの数を選択することを含むことを特徴とする、請求項１２記載のシステム。
14. 前記共に最適化するステップが、送信するフレームの数を選択することを含むことを特徴とする、請求項１２記載のシステム。
15. 前記第１の複数のフレームが、前記ビデオのスタートアップであることを特徴とする、請求項１記載のシステム。

Images