JP2011512767A - ビデオ・ストリーミング - Google Patents

Abstract

ビデオソースマテリアルから第１のコード化信号を、インターフレームとイントラフレームコーディングの組合せを使用して生成し、イントラコード化画像は連続する第１セットの時間間隔の各々に少なくとも１回強制的に生じさられる。同じソースの第２のコード化バージョンは、ビデオソースマテリアルのシーンの変化を認識することにより決定される全てのとき或いは主なときに生じるイントラコード化画像を有する。ビデオソースマテリアルのストリーミングコマンド、或いはストリーミング続行コマンドに応答して、（多分トリックプレイに従って）、まず第１のコード化信号をストリーミングし、イントラコード化画像を開始する。そして第２のコード化信号のイントラコード化画像に一致する位置で、第１のコード化信号のストリーミングを終了し、代わりに第２のコード化信号をストリーミングし、イントラコード化画像を開始する。
【選択図】 図３

Description

本発明は、ビデオ・ストリーミングに関する。

この１２０年の間に発展したビデオ圧縮技術は動き補償変換コーディングに基づいてきた。基本的概念はあるイメージをエンコードし、このイメージを次のイメージの予測に使用することである。ソース画像から予測値を差し引いて、時間的な余剰分を除去し、予測残差を残し、この残差をブロックを用いた変換コーディング技術でコード化する。

ソース画像はマクロブロックと呼ばれる16x16の領域に通常分割される。エンコーダは、現在のマクロブロックに対して良好なマッチングを取るため或いは予測するために1以上の以前エンコードされ記憶されている画像を検索する。現在のマクロブロックと共通に位置される基準画像のマクロブロックと、現在のマクロブロックを予測するのに使用される画素領域間のずれは動きベクトルとして知られている。

相互コーディング（インターコーディング）として知られている、以前の画像からの予測を使用してマクロブロックをエンコードする方法に対する代替方法は、以前にエンコードされた画像を参照することなくマクロブロックをエンコードすることである。これは内部コーディング（イントラコーディング）と呼ばれている。初期の圧縮スタンダードでは、減算をなくしてソース画像を直接に変換し量子化することにより簡単に達成された。後のスタンダードでは、現在の画像の既にコード化された画素を使用して空間的な予測をする種々の形態は、変換と量子化をする前にソースマクロブロックから余分なものを除去するために使用されている。

予測エラー或いは予測残差として知られているソース画像と予測との差異は、ブロックベース変換を使用して周波数ドメインに通常変換され、そしてスカラー量子化器で量子化され、得られた量子化係数はエントロピーコード化される。スカラー量子化器の範囲は、ある所定のビットレートに束縛させるために、量子化プロセスによって導入される歪みがエントロピーコーディングによって生じるビット数に対してトレードオフされ、一定ビットレートネットワーク上の一定ビットレートでの送信を達成するように通常利用可能である。

ビデオコーディングとデコーディング用の国際標準が多数公表され、特にITUからのＨシリーズ標準とISO/IEC MPEGシリーズがある。既に述べたように、一般に、予測に適した以前コード化されたマクロブロックを見出すことができない場合に、マクロブロックは以前のコード化されたフレームを参照することなくコード化される。また、イントラコーディングが送信エラーの伝播を制限するために周期的に実行される。以前のコード化されたフレームを参照することなく全てのフレームをコード化することもまた可能である。これはイントラフレーム或いはI-フレームと呼ばれている。当然コード化されるべき最初のフレームはこの対応でなければならない。その後Ｉ−フレームを使用することは理論的に必要ではない。しかしながら、あるコードは、シーン（情景）の変化が検出される度にＩ−フレームの生成をトリガーするシーン変化検出器を有している。

ファーバー等(Farber et al.)("Robust H.263 compatible video transmission for mobile access to video servers", Proceedings of the International Conference on Image Processing ICIP 1997, IEEE, US, vol. 2 (26 October 1997) pp. 73-76)は、インターフレームモード(P-frames)にエンコードされたフレームのみから全体がなる第1のストリームを有するサーバーを提案している。また彼らはランダムアクセスに対して、全体がＩ−フレームのみからなる第2のビットストリーム（この第2のビットストリームは全てのＮ番目のフレームのみをエンコードする）をまた提供している。Ｉ−フレームストリームからＰ−フレームストリームにスイッチすることは”第3のＳ−ストリーム”を介してである。

また、あるコーダは、コード化されたシーケンスの先頭以外のあるポイントからデコードを可能にするように、インターバルに規則的なＩ−フレームを挿入している。例えば、ＵＫデジタル放送テレビジョンは最近、少なくとも1秒に１回、しばしば１秒に２回イントラフレームを挿入している。コード化されたビデオは、各ＧＯＰ(Group of pictures)の先頭に"sync フレーム"（同期フレーム）を伴った１秒（或いは０．５秒）ＧＯＰを有するとしばしば呼ばれている。このことにより、デジタル放送に切り替えると、デコーダがビデオのディスプレイをスタートできるようになるまでに非常に短い時間だけ待てばよいことになる。イントラフレームは他の画像タイプに比較してビットをコード化するのにコストがかかり、コード化効率とランダムアクセス機能との間にトレードオフが存在する。

あるビデオ・オン・デマンド（ＶＯＤ）システムもまたこの１秒ＧＯＰ構造を同様の理由でコード化されたフィルムとＴＶ資産に対して使用し、トリックプレイ動作から戻るのを容易にしている。イントラフレームは重要なプロセスによって引き上げられ、巻き戻しや早送りのようなトリックプレイモードを与えるために、種々のレートで独立にストリームされる。観察者はトリックプレイが終わると、必要とされる地点でビデオアセットに戻ることができる。

バンド幅が限られたイントラフレームを頻繁に規則的に挿入するある問題点は、イントラフレームはビットバジェット内に留まるために周りのフレームに比較してより低いビジュアル品質でコード化される必要があることである。結果としての画像品質の低下は、フットボールの画像において特に明らかである。結果は、フットボールゲームでのロングショットで非常に気付かされる脈打つ人工的な同期フレーム（毎秒毎の）である。

本発明によれば、ビデオソースマテリアルをストリームする方法が提供される。その方法では、そのビデオソースマテリアルから第１のコード化信号を、インターフレームとイントラフレームコーディングの組合せを使用して生成し、その第１の信号はインターコード化画像によって点在されたイントラコード化画像を有し、イントラコード化画像は所定の存続期間の連続する第１セットの時間間隔の各々に少なくとも１回強制的に生じさられる。そしてそのビデオソースマテリアルから第２のコード化信号を、インターフレームとイントラフレームコーディングの組合せを使用して生成し、その第２のコード化信号はインターコード化画像によって点在されたイントラコード化画像を有し、イントラコード化画像はビデオソースマテリアルのシーンの変化を認識することにより決定される全てのとき或いは主なときに生じる。そのビデオソースマテリアルのストリーミングコマンド、或いはストリーミング続行コマンドに応答して、（ａ）第１のコード化信号をストリーミングし、イントラコード化画像を開始し、（ｂ）第２のコード化信号のイントラコード化画像に一致する位置で、第１のコード化信号のストリーミングを終了し、代わりに第２のコード化信号をストリーミングし、イントラコード化画像を開始する。

本発明のその他の面は請求項で規定されている。

本発明のある実施態様は添付の図面を参照して説明する。

は、本発明の実施態様に使用されているビデオコーダの第１の形式を示すブロック図である。 は、本発明の実施態様に使用されているビデオコーダの第２の形式を示すブロック図である。 は、ビデオストリーミングサーバのブロック図である。

図１はビデオコーダを示している。通常デジタル形式であるビデオ信号は、入力１で受信される。減算器２は前記入力と予測バッファ３からの予測信号との差を求め、この差は更にコード化される。ここで実行されるコーディングは、例えば、変換コーディング４、ゼロ又はマイナーな差の送信を防止するための閾値化、量子化５、及び／又は可変長コーディング６を含んでいる。予測器記憶部３は、予測値と、参照符号８，９でデコードされたコード化差信号とを加算器７で加算した和である。従ってコーディングとデコーディングプロセスでの情報のロスは予測器ループに含まれている。逆量子化器８、逆変換９と加算器７は、記憶部３と動き補償１０と共にローカルデコーダを形成している。

バッファリングがエンコーダ出力１２とデコーダ出力（図示せず）に設けられて、一定のビットレートチャネル上の送信を可能とする。動き推定器１３もまた含まれている。動き推定器１３は、コード化された画像のフレームを予測器フレームと比較する。動き推定器１３は、画像が分割された現在のフレームの各ブロックに対して、そのブロックが一番似ている以前のフレームの領域を識別する。識別された領域と問題のブロックとの位置のベクトル差は動きベクトルと呼ばれ（動きベクトルはテレビの画像によって描かれるシーン内の物体の動きを通常表しているからである）、動き補償ユニット１０に入力されて、動き補償ユニット１０は、以前のフレームの識別された領域を現在のフレームの関連するブロックの位置にずらせる働きをし、よりよい予測を達成する。これにより減算器２によって形成される差を平均としてより小さくし、参照符号４，５でのコーディングにより、他の場合におけるよりもより低いビットレートを使用して画像をエンコードできるようにする。

しかしながら、このコーダは常にインターフレームコーディングを使用するわけではない。あるスタンダードによれば、コーダは、各マクロブロックに対して、そのマクロブロックが動き補償インターフレーム差分コーディングを使用してコード化されるかどうか、或いはそのマクロブロックに対してイントラフレームコーディングを使用することがよりビット上経済的であるかどうかについて決定を下す。この決定は制御ユニット１４によってなされる。イントラフレームコーディングが使用されるべき場合には、以前の画像はもはや減算器に送られない。これはスイッチ１５によって図１に概略的に示されている。この決定はまた、デコーダに知らされ、デコーダは同様のスイッチを制御する。イントラコーディングは、実際のピクセル値を単にコーディングアップする代わりに、同じ画像内の以前にデコードされたピクセルからの予測を使用してイントラフレーム差分コーディングを実行することができる。しかしながらこの点は図面には示されていない。

図１のコーダは第１のモード或いはフリーモードで動作し、その場合シーン変化検出器１６は、シーン変化を認識して、イントラフレームを強制的に生成するためにスイッチ１５の動作を優先とするように応答する。

図２は、第２のモード或いは固定モードのコーダを示していて、検出器１６の代わりに、タイマー１７を有しており、タイマー１７は１或いは０．５秒間隔でＩフレームを強制的に生成するためにスイッチ１５に対して規則的な優先信号を生成する。Ｉフレーム間の時間を最小にする他の方法は、前のＩフレームから１秒（或いは関連する望ましい期間）が経過したならばＩフレームを生成することである。

図３は、ビデオを、示されているのはたった１つではあるがクライアント端末３０にストリームするサーバ２０を示している。ソースビデオは図１の構造を有するフリーモードコーダ２１と図２の構造を有する固定モードコーダ２１’によってエンコードされて、ビデオの２つのエンコーディングを生成し（１つは固定ＧＯＰ構造を有し、１つはビデオのシーン変化にのみ関連するフリーＧＯＰ構造を有する）、２つのエンコーディングはバッファ１２，１２’にそれぞれ記憶されるかバッファされる。代わりに、検出器１６とタイマー１７を有し２つのモード間で切換可能な単一のコーダが使用可能であり、２つの異なるモードで連続的に２回２つのコーディングを達成でき、その場合バッファは全体のシーケンスを行えるのに十分な大きさを必要とする。第３のバッファ１２”は同じビデオシーケンスの１以上のトリックプレイがエンコードされたバージョンを記憶するためにオプションとして設けられる。これらは、バッファ１２’からＩフレームを選択することにより、或いは第３のコーダを設けることにより生成できる。

制御ユニット２２はビデオをストリーミングするためにクライアント端末３０からユーザコマンドを受信する働きをし、その結果ユーザはストリーミングを開始することができ、フルランダムアクセス機能のために適切にこれらのエンコーディング間をスイッチングすることができる。トリックプレイのシナリオがない場合には、ユーザは”プレイ”を押し、制御ユニット２２へのコマンドをトリガーしてバッファ１２からのフリーモードのコンテンツの最初からストリーミングを開始し、途切れずにコンテンツを見ることができる。この場合、ユーザはフリーＧＯＰ構造のビデオのみ見ることになる（例えば、ひどく或いは人工的なことはなく、或いはそのようなことが非常に低減されていて、同じ品質に対して可能な限り低いビットレートである）。クライアント端末がトリックプレイ用のコマンドを送ると、このコマンドは、その代わりとしてバッファ１２”からのトリックプレイエンコーディング（そのコマンドで特定された早送り／巻き戻しモード）のストリーミングをトリガする。ユーザはトリックモードを見る。クライアント端末がトリックプレイをやめてノーマルモードに戻るためのコマンドに会うと、制御ユニットは、
（ａ）トリックプレイエンコーディングのストリーミングを終了し、
（ｂ）バッファ１２’からの規則的なＧＯＰコード化ビデオに切り換える。しかしながら、ユーザは、バッファ１２のフリーＧＯＰビデオにある次に利用可能な同期フレーム（イントラ）に対応するフレームに到着するまで、必要な限り長くこのストリームに留まるので、トリックモードから戻った後に非常に短期間だけ人工物といわれるものが生じる。

（ｃ）そして、この点に到着すると、制御ユニットはバッファ１２’からの固定ＧＯＰエンコーディングのストリーミングをやめ、バッファ１２からのストリーミングを開始する。

同期フレームの位置はストリーミングの前に制御ユニットに利用可能なように決定される必要がある。このことを実行するある方法は、結果として得られたエンコード化されたビットストリームを解剖して別のインデックスファイルに同期点の位置を記録することである。あるコンテナフォーマット、例えばＭＰ４ファイルはこの情報を特定のテーブルに蓄積している。ＭＰ４ファイルヘッダはｓｔｓｓ（sample table sync samples)ヘッダ構造を有している。

フリーモードコーダ２１において、シーン変化検出器が１０秒毎に少なくとも１つの同期フレームをトリガーしていることは統計的に起こりそうなことである（映画では８秒或いはそれ以下の代表的なシーン持続期間で高い確率で起こる）。しかしながら、望ましくは図１にドットで示されているカウンタ１８を、このことを確かめるために加えることができる。カウンタは、シーン変化が認識される度にゼロにリセットされる。しかしながら、カウンタのカウントが１０秒を超えるとスイッチ１５を優先してＩ−フレームを生成する。

図１と図２のコーダは、望ましくはH.264コーダとして搭載されることができる。多くの商業的に入手可能なコーダは適切なセッティングをサポートできる。例えば、Ateme SA of Bievres, Franceによって作成されたコーダは、固定ＧＯＰサイズ或いは最小及び最大ＧＯＰサイズのどちらかを使用するためにセットされる。上述の１０秒シーリングを有するフリーモード動作は最大ＧＯＰサイズを１０にセットすることにより得られる。１秒レートを有する固定モードは固定ＧＯＰサイズを１秒にセットする必要がある。

通常トリックプレイからフリーモードへ移るには固定モードビデオのストリーミングを短期間介してなされる。しかしながら、望むならば、トリックプレイを終了してノーマルプレイに移るためのコマンドを受けて、まず同期フレームがフリーモードエンコーディングで差し迫って利用可能であったかどうかを決定し、そのような場合、固定モードのエンコーディングのストリーミングを省略して直接フリーモードに切り換えることが可能である。このオプションを実施するための基準は、次のフリーモードのＩ−フレームへの時間間隔が、固定モードエンコーディングにおける同期フレーム間の最小時間以下（或いは多分１．５タイム）であるかどうかである。

本発明の第２の実施態様は、固定モードストリームの使用をやめ、トリックプレイに続くフリーモードストリームに直接切り換えることである。この場合、タイミングの非連続性は、早送りの場合には一番近い同期フレームにジャンプして戻るか、或いは巻き戻しトリックプレイの場合には行き先のフリーモードエンコーディングの一番近い同期フレームにジャンプして進むことによってなされる。より賢い実行は、早送りから出て少し前にジャンプすることである。このアルゴリズムは、トリックプレイストリームの出口地点後のｘフレームのセット期間内に行き先ストリームの同期フレームが存在する場合に、その同期フレームを選ぶか、もしくはその出口地点前の一番近い同期フレームでフリーモードストリームに入ることである。ｘの値は多分１秒以下であり、早送りフレームレートがノーマルプレイのレートのＮ倍であると、１０ｘはＮ又は２Ｎに等しい。

１・・・入力、２・・・減算器、３・・・予測バッファ、４・・・変換コーディング、５・・・量子化、６・・・可変長コーディング、７・・・加算器、８・・・逆量子化器、９…逆変換、１０・・・動き補償、１２、１２’…エンコーダ出力（バッファ）、１２”・・・第３のバッファ、１３・・・動き推定器、１４・・・制御ユニット、１５・・・スイッチ、１６…シーン変化検出器、１７・・・タイマー、１８・・・カウンタ、２０・・・サーバ、２１・・・フリーモードコーダ、２１’・・・固定モードコーダ、２２・・・制御ユニット、３０…クライアント端末。

Claims (9)

1. ビデオソースマテリアルをストリームする方法において、
   前記ビデオソースマテリアルから第１のコード化信号を、インターフレームとイントラフレームコーディングの組合せを使用して生成するステップであって、前記第１のコード化信号はインターコード化画像によって点在されたイントラコード化画像を有し、前記イントラコード化画像は所定の存続期間の連続する第１セットの時間間隔の各々に少なくとも１回強制的に生じさられる、ステップと、
   前記ビデオソースマテリアルから第２のコード化信号を、インターフレームとイントラフレームコーディングの組合せを使用して生成するステップであって、前記第２のコード化信号はインターコード化画像によって点在されたイントラコード化画像を有し、前記イントラコード化画像はビデオソースマテリアルのシーンの変化を認識することにより決定される全てのとき或いは主なときに生じる、ステップと、を含み、
   前記ビデオソースマテリアルのストリーミングコマンド、或いはストリーミング続行コマンドに応答して、
   （ａ）前記第１のコード化信号をストリーミングし、イントラコード化画像を開始し、
   （ｂ）前記第２のコード化信号のイントラコード化画像に一致する位置で、第１のコード化信号のストリーミングを終了し、代わりに前記第２のコード化信号をストリーミングし、前記イントラコード化画像を開始する、方法。
2. 前記第１のコード化信号において、前記イントラコード化画像は前記第１セットの時間間隔に従って、規則的に生じさせられる請求項１に記載の方法。
3. 前記第１セットの時間間隔は１秒以下である請求項1または2に記載の方法。
4. 前記第2のコード化信号において、前記イントラコード化画像は、
   （ａ）前記ビデオソースマテリアルでのシーンの変化を認識することにより決定された回数であって、（ｂ）シーン変化が、以前のイントラコード化フレームからの第2セットの時間間隔の間に認識されない場合にのみ生じ、前記第2セットの時間間隔は前記第1セットの時間間隔より長い請求項1ないし3のいづれか1項に記載の方法。
5. 前記第2セットの時間間隔は前記第1セットの時間間隔の少なくとも5倍である請求項4に記載の方法。
6. 前記第2セットの時間間隔は前記第1セットの時間間隔の少なくとも８倍である請求項５に記載の方法。
7. 前記第2セットの時間間隔は少なくとも5秒である請求項4ないし6のいづれか1項に記載の方法。
8. 前記ビデオソースマテリアルのストリーミングコマンド、或いはストリーミング続行コマンドを受信する前に、
   前記ビデオソースマテリアルから、トリックプレイに対する第3のコード化信号を生成するステップと、
   前記第2のコード化信号をストリーミングするステップと、
   トリックプレイコマンドに応答して、前記第2のコード化信号の代わりに前記第3のコード化信号をストリーミングするステップと、を更に含み、
   前記ビデオソースマテリアルのストリーミングコマンド、或いはストリーミング続行コマンドの受信に応答して、前記第3のコード化信号のストリーミングを終了するステップを更に含む、請求項1ないし7のいづれか1項に記載の方法。
9. ステップ（ａ）における前記第1のコード化信号のストリーミングは、第3セットの時間間隔内に前記第2のコード化信号にイントラコード化画像が存在しないことが条件である、請求項1ないし８のいづれか1項に記載の方法。

Images