JP2012509014A - Ｈｒｄ情報共有およびビット割付け待機を用いたマルチスレッド・ビデオ符号化 - Google Patents

Abstract

ＧＯＰの複数のスレッドをバッファから並列に単一パスで符号化する、ビデオを符号化する方法。バッファ中で、シーンの終端部においてフレーム数が低フレームしきい値未満であるＧＯＰは、以前のＧＯＰとマージされる。各ＧＯＰについて、仮想参照デコーダ（ＨＲＤ）情報がバッファに記憶され、隣接するＧＯＰについてのＨＲＤ情報が、バッファ中でマージされる。

Description

（関連出願の相互参照）
本願は、２００８年１１月１３日出願の米国仮出願第６１／１９９１８０号の利益を主張するものである。

本発明は、ビデオ符号化に関し、より詳細には、仮想参照デコーダ（ＨＲＤ：Ｈｙｐｏｔｈｅｔｉｃａｌ Ｒｅｆｅｒｅｎｃｅ Ｄｅｃｏｄｅｒ）情報共有およびビット割付け待機を用いて、複数のスレッドを有するグループ・オブ・ピクチャ（ＧＯＰ）並列単一パス・ビデオ・エンコーダにおけるＨＲＤコンフォーマンスをサポートすることに関する。

ネットワークを介して符号化ビットストリームを遠隔のクライアント・デコーダに伝送し、それをデコーダがうまく復号して滑らかにビデオを再生する必要がある実際のビデオ・ストリーミング・システムでは、ＨＲＤコンフォーマンスは、符号化ビデオ・ビットストリームをうまく配信するための必要条件である。デコーダが有する復号バッファは、大きさが限られているが、ネットワークから配信されるビデオ・ビットストリームを絶えず受信する。一方で、復号モジュールは、バッファリングした各符号化単位（例えばフレーム）のビットストリームをバッファから取り出し、復号し、再構築したビデオ信号を再生する。実際のビデオ・ストリーミング・システムでは、デコーダのバッファは、現在のネットワークでは避けることができないチャネル伝送速度のジッタリングを吸収し、復号したビデオを途切れずに滑らかに再生するために必要である。

従って、ＨＲＤコンフォーマンスは、符号化ビデオ・ビットストリームに対するデコーダ・バッファ制約を満足させることと、基本的には同じ問題である。

エンコーダにおいて１組のＨＲＤパラメータのセットを想定し、各フレーム（あるいはＨ．２６４では一般にスライス）を符号化するときにこの想定したＨＲＤパラメータに適合するようにすることにより、その結果得られる符号化ビットストリームは、やはり同じＨＲＤパラメータのセットに適合しているデコーダであれば何れのデコーダでもうまく復号することができる。これにより、ビデオ・コーデック関連産業の異なる製造業者のエンコーダおよびデコーダをより容易に協働させることができるようになる。現在では、ＨＲＤコンフォーマンスの重要性は、広く認識されるようになっており、最新のＨ．２６４／ＡＶＣビデオ符号化標準のＡｎｎｅｘ Ｃで標準化されている。

一般に、当該のＨＲＤまたはデコーダ・バッファのパラメータとしては、周知のリーキー・バケット・モデルを規定する、バッファ・サイズ、初期バッファ・レベル、およびチャネル・レートなどがある。ＨＲＤコンフォーマンスは、符号化ビットストリーム・データをバッファに入れるとき、および各符号化単位の復号のためにビットストリームを取り出すときに、バッファ・オーバフローまたはバッファ・アンダフローが起きないことを意味する。従って、ＨＲＤコンフォーマンスをサポートするために、ビデオ・エンコーダは、（ｉ）各単位（例えばフレームまたはフィールド）を符号化した後で現在のバッファ・レベルを正確に把握しておくこと、（ｉｉ）それに基づいて、次の単位の符号化ビットの上限および／または下限を導出すること、および（ｉｉｉ）当該単位の符号化ビットがそれらの限界を超えないことを確実にすることが必要である。実際には、ビデオ・エンコーダのレート制御方式によってバッファ制約問題に対処する。

複数のスレッドを有するＧＯＰ並列（パラレル）単一パス・ビデオ・エンコーダでＨＲＤコンフォーマンスをサポートすることにより、難問が生じる。実時間ビデオ符号化システムで一般に良く用いられるこのアーキテクチャでは、複数のＧＯＰを複数の符号化スレッドによってそれぞれ同時に符号化することができ、各ＧＯＰは１回だけ符号化すればよい。ＧＯＰ並列単一パス符号化は、簡単に符号化プロセスの速度を大幅に上げるが、ＨＲＤコンフォーマンスをサポートすることが、従来のＧＯＰ逐次（シーケンシャル）単一スレッド符号化の場合より、かなり困難な作業になるという副作用がある。ＧＯＰ逐次ビデオ符号化では、ＧＯＰを符号化するときに、それ以前の全てのフレームが既に符号化されているので、その符号化ビットを使用して、現在のバッファ・レベルを正確に把握し、ＨＲＤコンフォーマンス符号化のための正しい限界を導出することができる。しかし、ＧＯＰ並列符号化の場合には、あるスレッドが現在のＧＯＰを符号化しようとしているときに、それ以前のＧＯＰの一部が、依然として他のいくつかのスレッドによる符号化の最中である可能性がある。これを図１に示す。図１では、斜線領域が、ＧＯＰ中の符号化された部分を表している。これらのＧＯＰでは、現在のＧＯＰを符号化するときに、正確な符号化ビットが不明であり、ＨＲＤコンフォーマンス符号化が不可能になっている。

一般に、マルチパス・システムでは、各ＧＯＰが、実際の符号化の前に割り付けられた全てのバジェット・ビットを正確に消費するようにしなければならない。そのようにして、部分的に符号化されたＧＯＰについて、それらに割り付けられたビットがそれらの最終的な符号化ビットであると仮定し、それらを使用してバッファ状態を把握することができる。しかし、単一パス実時間ビデオ符号化の場合には、任意のＧＯＰについて事前に割り付けられたビットを正確に達成することは、レート制御の極めて困難な作業である。なお、マルチパス符号化が可能であれば、正確なＧＯＰビットの達成は、はるかに容易に、且つはるかに直接的になることに留意されたい。その場合には、ＧＯＰの事前に割り付けられたビットが符号化ＧＯＰで正確に達成されない可能性があるが、全てのＧＯＰが１回だけ符号化されると仮定して、ＨＲＤコンフォーマンス検査を行うことができる。ＨＲＤ違反（すなわちバッファ・オーバフローまたはバッファ・アンダフロー）が見られる場合には、エンコーダは、新たに割り付けられたビットを用いて問題のＧＯＰを再符号化して、違反を防止することができる。この第２のパスの符号化後に、エンコーダは、ＨＲＤ検査を再度行うことができ、また、ＨＲＤ違反が生じなくなるまで、同様の動作を行うことができる。ただし、ＨＲＤコンフォーマンスをサポートするための唯一の方法がＧＯＰ割付けビットを正確に達成することである単一パス・ビデオ符号化では、このＨＲＤ調節は不可能である。

このデコーダ・バッファ制約またはＨＲＤコンフォーマンス問題は、長い間、ビデオ・ストリーミング分野のビデオ・エンコーダの実用的なレート制御方式を開発する上での重要な問題と考えられてきた。しかし、現在までに行われている研究の大部分は、バッファ制約を満足することが一般に実際的な難題にならない、ＧＯＰ逐次単一スレッド符号化の場合に集中している。

ＧＯＰの複数のスレッドをバッファから並列に単一パスで符号化する、ビデオを符号化する方法を提供する。バッファ中で、シーンの終端部においてフレーム数が低フレームしきい値未満であるＧＯＰは、以前のＧＯＰとマージされる。仮想参照デコーダ（ＨＲＤ）情報が各ＧＯＰについてバッファに記憶され、隣接するＧＯＰについてのＨＲＤ情報が、バッファ中でマージされる。この方法は、いくつかのビットを各ＧＯＰに割り付けるステップをさらに含むことができ、上記複数のスレッドは、全ての未符号化ＧＯＰのビット割付けを、それらそれぞれの符号化の開始前に待機する可能性があり、符号化の完了時に、各符号化スレッドは、待機スレッドのそれぞれに対して、それぞれの待機終了セマフォを送信する。さらに、各待機スレッドは、符号化スレッドから待機終了セマフォを受信することができる。セマフォ待機デッドロックを防止するために、待機スレッドの１つが待機終了セマフォを受信した後でその待機を終了し、その後直ちにそのＧＯＰより前であるがまだビットを割り付けられていない新たな最も早いＧＯＰのビット割付け結果を待機する新たなセマフォを設定したときには、この新たな待機セマフォは、上記待機終了セマフォとは別個の異なるセマフォである。

バッファと、グループ・オブ・ピクチャ（ＧＯＰ）の複数のスレッドをバッファから並列に単一パスで符号化する符号化モジュールと、シーンの終端部においてフレーム数が低フレームしきい値未満であるＧＯＰをバッファ中で以前のＧＯＰとマージするマージ・モジュールと、各ＧＯＰについての仮想参照デコーダ（ＨＲＤ）情報、ＨＲＤタイプ情報などの情報をバッファに記憶し、バッファ中で隣接するＧＯＰの情報をマージする、ＨＲＤ情報、ＨＲＤタイプなどの情報を監視するモジュールとを備える、ビデオ・エンコーダを提供する。このエンコーダは、いくつかのビットを各ＧＯＰに割り付ける割付けモジュールをさらに備えることができ、上記複数のスレッドは、全ての未符号化ＧＯＰのビット割付けを、それらそれぞれの符号化の開始前に待機する可能性がある。このエンコーダは、符号化スレッドから各待機スレッドにそれぞれ送信される、複数の待機終了セマフォをさらに備えることができる。各待機スレッドは、符号化スレッドから待機終了セマフォを受信することができる。エンコーダにおけるセマフォ待機デッドロックを防止するために、待機スレッドの１つが待機終了セマフォを受信した後でその待機を終了し、その後直ちにそのＧＯＰより前であるがまだビットを割り付けられていない新たな最も早いＧＯＰのビット割付け結果を待機する新たなセマフォを設定したときには、この新たな待機セマフォは、上記待機終了セマフォとは別個の異なるセマフォである。

以下、例示を目的として添付の図面を参照しながら本発明について説明する。

図１は、本発明による実時間ビデオ・エンコーダにおける複数の符号化スレッドによる複数のＧＯＰの並列符号化を示す図である。 本発明によるＧＯＰ並列マルチスレッド単一パス実時間ビデオ符号化のためのＨＲＤコンフォーマンス対応レート制御解決策の全体的な枠組みを示すブロック図である。 本発明によるビット・オーバシュート補償ＭＢレベル・レート制御を示すブロック図である。 ＧＯＰ中の最後のフレームの符号化後のフィラー・ユニット付加を示すブロック図である。

本開示中の少なくとも１つの実施態様は、まさにこのＧＯＰレベルの正確なビットを達成する問題に対処するものであり、この目的を達成するための包括的レート制御方法を提案するものである。提案する方式は、主として、シーン終端部短ＧＯＰマージ、ビット・バジェット丸め、ＧＯＰおよびフレーム・レベルのビット予約、ビット・オーバシュート補償ＭＢレベル・レート制御、フィラー・ユニット付加、ならびに効率的なマルチスレッド符号化情報のバッファリングおよび通信を含む。複数のスレッドを有する実用的な単一パス実時間ビデオ・エンコーダによる広範な試験により、提案する方式が、失敗が常にほとんど見られないＨＲＤコンフォーマンスを常に保証することが分かる。

当該のＧＯＰ並列マルチスレッド・ビデオ符号化の場合には、マルチパスＧＯＰ符号化が可能であれば、ＨＲＤコンフォーマンスをサポートすることにより、直接的且つ容易に実行できる解決策ももたらされる。すなわち、違反が発見されると必ず、符号化ビットストリーム全体が特定のＨＲＤコンフォーマンス検査に合格するまで、関連するＧＯＰをＨＲＤ調整によって再符号化する。従って、この場合には、正確なＧＯＰビットを達成することは有用な技術ではあるが、正確なＧＯＰビットを達成することが不可欠というわけではない。

しかし、本開示の少なくとも１つの実施態様では、発明者等は、実時間ビデオ符号化のための重要且つ効果的なアーキテクチャであるＧＯＰ並列および単一パス・ビデオ符号化を扱う。この場合には、正確なＧＯＰビットの達成が、実際には極めて難問であるＨＲＤコンフォーマンスをサポートするために不可欠である。これは、ビデオ信号が極めて非定常の信号であるからである。しかし、レート制御では、過去の符号化ビデオ・ユニットから推定したモデルに基づいてビット割付けまたはビット達成を行う。従って、過去に符号化されたビデオ・ユニットと現在の符号化ビデオ・ユニットの特徴の不整合または差違により、レート制御が不正確になり、ビット・オーバシュートおよびビット・アンダシュートが生じることが避けられない。効果的にＨＲＤコンフォーマンスをサポートするためには、ビデオ信号の非定常性に対して十分にレート制御をロバストにすることにより、各ＧＯＰ符号化で事前に割り付けられるビットを常に正確に達成する技術を開発しなければならない。

少なくとも１つの実施例は、各ＧＯＰに事前に割り付けられたビットを正確に達成し、それにより上述のように複数のスレッドを有するＧＯＰ並列単一パス実時間ビデオ符号化の場合に効果的にＨＲＤコンフォーマンスをサポートする効果的な包括的レート制御方法を提供する。提案する方法は、主として、後により詳細に説明する以下の技術からなる。
（ｉ）シーン終端部短ＧＯＰマージ。シーン終端部で短すぎるＧＯＰを、その前のＧＯＰとマージして、短すぎるＧＯＰのレート制御が極めて不正確になる可能性を回避する。
（ｉｉ）ビット・バジェット丸め。ＧＯＰの事前に割り付けられたビット・バジェット、および当該ＧＯＰの最後の符号化フレームの事前に割り付けられたビット・バジェットの両方を、ビット・イグザクト（ｂｉｔ−ｅｘａｃｔ）なビット達成のためにバイトに丸める。
（ｉｉｉ）ビット予約。ＧＯＰレベルおよびフレーム・レベルのビット予約により、フレーム・レベルのビット割付けおよびＭＢレベルのビット割付けにおいてビット不足の状況になることを防止する。
（ｉｖ）ビット・オーバシュート補償。ＭＢレベル・レート制御において、ビット・オーバシュート効果を保証して、フレームを符号化する際のビット・オーバシュートを防止する。
（ｖ）フィラー・ユニット付加。最終的に残りのビットを全て使い切るために、ＧＯＰ中の最後の符号化フレームの後に適当な量のフィラー・ユニット・バイトを付加する。
（ｖｉ）マルチスレッド符号化情報のバッファリングおよび通信。符号化情報をバッファリングして、全ての符号化スレッドの間で共有する。バッファ・サイズ削減のための効果的な符号化ＧＯＰマージ、および２つのセマフォを備えるスレッド間待機機構などを含む。提案する方法の詳細を、図２に示す。まず、ステップ２０で、入力フレームを複数のＧＯＰに仕切り、次いで、これらのＧＯＰをＦＩＦＯ（先入れ先出し）待ち行列にバッファリングする。ステップ２２で、第１の利用可能な符号化スレッドが、待ち行列の先頭から、最初の利用可能なＧＯＰを符号化のために取り出す。なお、ＧＯＰを仕切る際には、シーン終端部短ＧＯＰマージが好ましいことに留意されたい。これは、短いＧＯＰは総ビット・バジェットが限られているために、（ｉｉｉ）で述べたようにフレーム・レベルのビット割付けにおいてビット不足を防止するためにＧＯＰレベルで予約されたビットもまた限られているからである。従って、大きなＧＯＰの場合より、ビット・オーバシュートを防止することが困難である。従って、シーンの終端部のＧＯＰが短すぎる（例えば５フレーム未満）場合には、当該ＧＯＰをその前のＧＯＰとマージしてより大きなＧＯＰを形成し、レート制御のための正確なＧＯＰビット達成の負担を軽くする。

次に、ステップ２４で、現在のＧＯＰを符号化しているスレッドは、現在のＧＯＰが当該スレッドによって符号化される最後のＧＯＰの直後に続くＧＯＰであるかどうかを確認する。直後に続くＧＯＰである場合には、当該スレッドは、その最後に符号化されるＧＯＰによって生じるバッファ状態を追跡し続けることができる。そうでない場合には、現在のＧＯＰと最後に符号化されるＧＯＰとの間に、その他のスレッドによってこれから符号化される、または既に符号化されている１つまたは複数のＧＯＰが存在する。この場合には、現在のスレッドは、ＨＲＤ＿ｉｎｆｏ＿ｂｕｆｆｅｒにバッファリングされている全てのスレッドの符号化情報に基づいて現在のバッファ状態を更新する必要があり、これについては後で詳細に説明する。具体的には、中間のＧＯＰに対して、割り付けられたビットまたは実際の符号化ビットをそれらの最終的な符号化ビットであると仮定して現在のバッファ・レベルを導出する。まだビットが割り付けられていないＧＯＰがある場合には、現在のスレッドは、ステップ２５でそれらのＧＯＰのビット割付けが終了するのを待機する。ＧＯＰがスレッドに割り付けられてから当該ＧＯＰのビット割付けが終了するまでの時間は常に無視できるので、この待機によって符号化に深刻な遅延が生じることはない。スレッド間待機に関するもう１つの重要な問題は、待機デッドロックを回避することである。実際には、デッドロックを防止するためには、２つの別個の待機セマフォを有する必要があることが分かっている。図１を考慮して、スレッド２、３および４がそれぞれＧＯＰ＿（ｉ＋１）、ＧＯＰ＿（ｉ＋３）およびＧＯＰ＿（ｉ＋４）を符号化しようとしていると仮定すると、スレッド１は、まだＧＯＰ＿ｉのビット割付けを完了していない。従って、スレッド２、３および４は、スレッド１のＧＯＰ＿ｉのビット割付けを待機しなければならない。実際には、一般に良く用いられるスレッド間通信機構をセマフォと呼ぶ。従って、スレッド１は、ＧＯＰ＿ｉのビット割付けを終了すると、これら３つの待機スレッドに対して３つのセマフォを送る。予期された待機終了セマフォを受信した後で、スレッドは、その待機状態を終了する。しかし、本件の場合には、スレッド３または４が、スレッド２よりも早く待機終了セマフォを受信した場合には、それらのスレッドは、それぞれの処理を継続し、ＧＯＰ＿（ｉ＋１）の割付けビットに対する新たな待機状態に直ちに入る。従って、仮に待機セマフォが１つしか存在しないと、この新たな待機状態がそのまま、ＧＯＰ＿ｉのビット割付けの終了による待機終了セマフォをもう１つ取ることになる。この場合、スレッド２は、スレッド１からの予期された待機終了セマフォを受信することができないので、待機デッドロックになる。従って、２つの別個のセマフォが必要である。そうすれば、スレッド２に対する新たな待機状態が、スレッド１からの待機終了セマフォを取ることはないので、待機デッドロックは起きない。

図２に示すように、スレッドは、次いで、現在のＧＯＰの符号化に進む。まず、ステップ２６で、現在のＧＯＰのビット・バジェットを、ＧＯＰレベル・レート制御によって計算する。本明細書では、正確なＧＯＰ割付けビットを達成するという目的のために、現在の全てのビデオ符号化標準（例えばＨ．２６４／ＡＶＣ）と同様に、割り付けられたビット・バジェットをバイトに丸めなければならず、各符号化単位（例えばスライス）を符号化して、整数バイトのビットストリームにする。従って、ＧＯＰビット・バジェット丸めは、正確なビットを達成するために必要である。同様に、各フレームのビット・バジェットも、図２に示すようにバイトに丸める。

次いで、現在のスレッドは、現在のＧＯＰの割り付けられたビットをＨＲＤ＿ｉｎｆｏ＿ｂｕｆｆｅｒに記録する。上述のように現在のＧＯＰのビット割付け結果を待機しているスレッドが他にもいくつか存在する場合には、現在のスレッドは、それに応じた数の待機終了セマフォを送信して、それらのスレッドに結果を通知し、それらの待機を終了させる（ステップ２８）。

次いで、ステップ３０に進み、ＧＯＰレベルのビット予約を行う。基本的には、ＧＯＰを符号化する前に、一定数のビットを最初に予約して、残りのフレームのビット割付けで起こり得るビット不足の状況が生じることを防止する。レート制御の不正確性のために、あるフレームを符号化するためのビットが十分でない場合には、当該フレームについてビット・オーバシュートが起こる可能性が非常に高く、これにより、ＧＯＰの最終的な正確なビットが達成できない可能性がある。従って、ビット予約は必要である。この実施態様では、ＧＯＰレベルのビット予約および予約ビットの消費は、以下のように行われる。なお、本明細書では、ＧＯＰ内の中間フレームのビット不足状況を防止するためのビット予約と、最後のフレームを符号化するためのビット予約はそれぞれ別個に行われることに留意されたい。これは、ビット・オーバシュートを防止することが、最終的な正確なＧＯＰビットの達成のために極めて重要であり、従って、間違いなくその他の中間フレームよりも重要性がはるかに高いからである。

ＧＯＰレベルのビット予約は、ステップ３０で、以下の数式に基づいて行われる。

ｒｅｓｅｒｖｅｄ＿ｂｉｔｓ＿ｔｏ＿ｐｒｅｖｅｎｔ＿ＦＢＡ＿ｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓ＝Ｒｏｕｎｄ＿ｔｏ＿ｂｙｔｅｓ［０．５＊ｍｉｎ（ｍｉｎ（ｃｕｒｒｅｎｔ＿ＧＯＰ＿ｌｅｎｇｔｈ、５）＊ｔａｒｇｅｔ＿ｂｉｔ＿ｒａｔｅ／ｆｒａｍｅ＿ｒａｔｅ、ｃｕｒｒ＿ＧＯＰ＿ｔａｒｇｅｔ＿ｂｉｔｓ）＊０．１］

ｒｅｓｅｒｖｅｄ＿ｂｉｔｓ＿ｆｏｒ＿ｔｈｅ＿ｌａｓｔ＿ｆｒａｍｅ＝ｒｅｓｅｒｖｅｄ＿ｂｉｔｓ＿ｔｏ＿ｐｒｅｖｅｎｔ＿ＦＢＡ＿ｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓ

ｃｕｒｒ＿ＧＯＰ＿ｔａｒｇｅｔ＿ｂｉｔｓ＝ｃｕｒｒ＿ＧＯＰ＿ｔａｒｇｅｔ＿ｂｉｔｓ−ｒｅｓｅｒｖｅｄ＿ｂｉｔｓ＿ｆｏｒ＿ｔｈｅ＿ｌａｓｔ＿ｆｒａｍｅ−ｒｅｓｅｒｖｅｄ＿ｂｉｔｓ＿ｔｏ＿ｐｒｅｖｅｎｔ＿ＦＢＡ＿ｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓ

ＦＢＡ（フレーム・レベル・ビット割付け）におけるＧＯＰレベル予約ビットの消費は、ステップ３２で管理され、以下の数式および論理に基づいている。

現在のフレームがＧＯＰ中の最後のフレームでない場合、および当該フレームのビット割付けを行っているときにｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓが発生した場合には、現在のフレーム・ビット割付けで、現在残っているｒｅｓｅｒｖｅｄ＿ｂｉｔｓ＿ｔｏ＿ｐｒｅｖｅｎｔ＿ＦＢＡ＿ｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓの半分を使用する。依然としてｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓである場合には、ｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓが起きなくなるまで、または残りの予約ビットがなくなるまで、引き続き残りの予約ビットの半分を消費する。

現在のフレームがＧＯＰ中の最後のフレームである場合には、全ての残りの予約ビット、すなわちｒｅｓｅｒｖｅｄ＿ｂｉｔｓ＿ｆｏｒ＿ｔｈｅ＿ｌａｓｔ＿ｆｒａｍｅに、ｒｅｓｅｒｖｅｄ＿ｂｉｔｓ＿ｔｏ＿ｐｒｅｖｅｎｔ＿ＦＢＡ＿ｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓが残っていればこれも合わせて、そのフレーム目標ビット・バジェットに付加する。

実際には、ＦＢＡ中のｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓを適切に規定して、フレーム符号化で制御されない状態でのビット・オーバシュートが生じるのを防止するのに役立てなければならない。本発明のこの実施態様では、あるフレームのビット割付けについて、全ての残りのビットおよび全ての残りのフレームを考慮して、予測残差符号化の推定残りビットが残りの全てのビットの有意な部分に相当しない、例えば１５％未満であるときに、ｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓであると見なす。予測残差符号化の推定残りビットは、残りの全てのビットから、ＮＡＬまたはＶＣＬユニット・ヘッダ、ピクチャ・ヘッダ、ＭＢ（マクロブロック）ヘッダなどの推定した全てのヘッダ・ビット、および動きベクトルなどを除いたものである。ｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓの場合に備えて、残差符号化のための事前に割り付けられるビットは、実際には許容できる符号化品質を維持するのに十分ではないが、最小限のビット数を残差符号化に使用するので、符号化フレームのビット・オーバシュートは防止される。

ＧＯＰレベルのビット予約の他に、実際に、本発明によるフレーム・レベルのビット予約技術をステップ５０〜６０に示す。この技術は以下の通りである。ＧＯＰ中の最後のフレームについては、ｃｕｒｒ＿ｆｒｍ＿ｔａｒｇｅｔ＿ｂｉｔｓ＝ｃｕｒｒ＿ｆｒｍ＿ｔａｒｇｅｔ＿ｂｉｔｓ＊０．８である。それ以外、短いＧＯＰ、すなわちＧＯＰ＿ｌｅｎｇｔｈ＜５であるＧＯＰ中の第１のＩフレームについては、ｃｕｒｒ＿ｆｒｍ＿ｔａｒｇｅｔ＿ｂｉｔｓ＝ｃｕｒｒ＿ｆｒｍ＿ｔａｒｇｅｔ＿ｂｉｔｓ＊０．９である。

フレームに割り付けるビットは十分であるが、フレーム符号化中のレート制御の不正確性により、依然として、最終的な符号化フレームのビットが当初の目標を超えることがある。そのために、発明者等は、効果的にフレーム・ビットのオーバシュートを防止するための別の技術、すなわち図３に詳細に示すビット・オーバシュート補償ＭＢレベル・レート制御を提案する。この図では、ステップ５０で、関連する変数を初期化し、チェック・ポイント（ステップ５２）で、ＭＢレベル・レート制御中にどの程度の頻度でビット・オーバシュート補償が行われるかを規定する。ステップ５４、５６を参照すると、一実施例では、フレーム中で追加のいくつかのビット（ｃｕｒｒ＿ｆｒｍ＿ｔａｒｇｅｔ＿ｂｉｔｓ＊１０％）が符号化されると必ず、新たなチェック・ポイントに到達したと見なされる。ビット・オーバシュート比率は、この新たに符号化されたｃｕｒｒ＿ｆｒｍ＿ｔａｒｇｅｔ＿ｂｉｔｓの１０％の符号化結果に基づいて推定され、残りの目標ビットに適用されて、推定ビット・オーバシュート効果を保証する。図３に示すように、フレームがＧＯＰ中の最後のフレームでない場合には、最後のフレームの符号化の場合ほどビット・オーバシュートの防止が切実でないので、用いるビット・オーバシュート比率を緩める。

図４を参照すると、最後に、ＧＯＰ中の全てのフレームを符号化した後で、エンコーダのスレッドは、全ての事前に割り付けられたＧＯＰビットがこの時点で使用されているかどうかを確認する。有意な量の割り付けられたビットが依然として残っている場合には、ステップ７３、７４で、全ての残りのビットを消費することになるＧＯＰ中の最後のフレームの符号化ビットストリームの後にフィラー・ユニットを付加して、ＧＯＰの符号化ビット全体がその事前に割り付けられたビットと正確に同じになるようにすることにより、ＨＲＤコンフォーマンスをうまくサポートする。フィラー・ユニットは、Ｈ．２６４／ＡＶＣに規定されるダミー・ユニットであり、例えば全てのビットが１または０であるダミー・コンテンツのみを含む。提案するフィラー・ユニット付加方式を、図４に示す。この図では、Ｈ．２６４に規定されたフィラー・ユニットについて、そのヘッダ・バイト数は６である。なお、本明細書では、ｃｕｒｒ＿ｆｒｍ＿ｔａｒｇｅｔ＿ｂｙｔｅｓは、フレーム・レベル・ビット予約前の、元の現在のフレームの目標バイトを表すことに留意されたい。図３に示すように、ステップ７０で、ｃｕｒｒ＿ｆｒｍ＿ｔａｒｇｅｔ＿ｂｙｔｅｓ自体がＨＲＤの上限および／または下限と衝突する場合には、現在のＧＯＰで正確なビットが達成されても、ＨＲＤコンフォーマンスは失敗する（ステップ７６）。最後のフレームでビット・オーバシュートがある、すなわちｃｕｒｒ＿ｆｒｍ＿ｔａｒｇｅｔ＿ｂｙｔｅｓ＜ｃｕｒｒ＿ｆｒｍ＿ｃｏｄｅｄ＿ｂｙｔｅｓである、あるいはステップ７２に示すように、残っている未使用の割り付けられたバイトが最低フィラー・ユニット・バイトすなわちフィラー・ユニット・ヘッダ・バイト未満である場合にも、ＨＲＤコンフォーマンスは失敗する。

ＧＯＰを符号化した後で、符号化ＧＯＰのビットをＨＲＤ＿ｉｎｆｏ＿ｂｕｆｆｅｒに適切に記録する。なお、割り付けられたＧＯＰビットを記録するときとは異なり、ＧＯＰの符号化は時間がかかるので、スレッドがＧＯＰ符号化ビットを待機することは、実時間ビデオ符号化の場合には非現実的である。

さらに、ＧＯＰ符号化情報をバッファリングして複数の符号化スレッド間で共有する効率的な機構を提案し、導入する。符号化情報バッファを、ＨＲＤ＿ｉｎｆｏ＿ｂｕｆｆｅｒと表す。簡潔にするために、ＨＲＤ＿ｉｎｆｏ＿ｂｕｆｆｅｒの初期化は、図２には示していない。提案するＨＲＤ＿ｉｎｆｏ＿ｂｕｆｆｅｒは、以下の２つの部分からなる。（ｉ）シーケンスの第１のＧＯＰから連結して一体にすることができる全ての符号化ＧＯＰのＨＲＤ情報をバッファリングするための単一のＣｏｄｅｄＳｅｑＨｒｄＩｎｆｏバッファ。（ｉｉ）ＣｏｄｅｄＳｅｑＨｒｄＩｎｆｏバッファ中の最後のＧＯＰと連結することができない全てのこれから符号化される、または既に符号化されているＧＯＰについての符号化情報をバッファリングするための（２＊ｔｏｔａｌ＿ｎｕｍｂｅｒ＿ｏｆ＿ｔｈｒｅａｄｓ）ＣｏｄｅｄＧＯＰＨｒｄＩｎｆｏバッファ。図１に示すように、ＣｏｄｅｄＧＯＰＨｒｄＩｎｆｏバッファは、既に符号化されたＧＯＰ、すなわちＧＯＰ＿（ｉ＋２）またはこれから符号化されるＧＯＰ、すなわちＧＯＰ＿ｉ、ＧＯＰ＿（ｉ＋１）、ＧＯＰ＿（ｉ＋３）、ＧＯＰ＿（ｉ＋４）のそれぞれの、割り付けられたＧＯＰビットおよび符号化ＧＯＰビットを記憶するためのものであり、ＣｏｄｅｄＳｅｑＨｒｄＩｎｆｏバッファは、シーケンスの先頭から始まる全ての過去の符号化ＧＯＰと連続的に連結することができる最後の符号化ＧＯＰまでのバッファ状態情報、すなわち図１の「符号化シーケンス」の情報を記録するものである。

実際には、ＣｏｄｅｄＧＯＰＨｒｄＩｎｆｏバッファを効率的に管理する効果的な技術は、隣接する符号化ＧＯＰのマージである。すなわち、ＣｏｄｅｄＧＯＰＨｒｄＩｎｆｏバッファ中に互いに隣接する２つの符号化ＧＯＰがある場合に、この２つのＧＯＰの符号化情報をマージする。このマージは、図２では「ＧＯＰ符号化ビットを用いてＨＲＤ＿ｉｎｆｏ＿ｂｕｆｆｅｒを更新する」のモジュールに含まれ、提案するＣｏｄｅｄＧＯＰＨｒｄＩｎｆｏバッファのバッファ・サイズを大幅に減少させる。例えば、本発明のこの実施態様では、支障なくバッファ・サイズを（２＊ｔｏｔａｌ＿ｎｕｍｂｅｒ＿ｏｆ＿ｔｈｒｅａｄｓ）に設定することができる。そうでない場合には、バッファ・サイズは、（２＊ｔｏｔａｌ＿ｎｕｍｂｅｒ＿ｏｆ＿ｔｈｒｅａｄｓ＊ｍａｘ＿ＧＯＰ＿ｌｅｎｇｔｈ）となる。ここで、ｍａｘ＿ＧＯＰ＿ｌｅｎｇｔｈは、実際には非常に大きくすることもできる（例えば１５０超）。

最後に、実際のＧＯＰ並列単一パス実時間ビデオ・エンコーダを用いた広範な試験を、提案したＨＲＤコンフォーマンス・サポート方法について行ったことを強調しておくことが重要である。その結果から、提案した方法を用いると、ＨＲＤ失敗が一貫してほとんど見られず、従って、ＨＲＤコンフォーマンスが効果的にサポートされていることが分かる。

具体的な特性および特徴を有する１つまたは複数の実施態様について述べた。しかし、記載した実施態様の特性および特徴は、その他の実施態様に合わせて改変することもできる。本明細書に記載した実施態様は、特定の状況について述べていることもあるが、これらの記述は、いかなる意味においても、本発明の特性および概念をそのような実施態様または状況に限定するものとして解釈すべきではない。

本明細書に記載の実施態様は、例えば、方法またはプロセス、装置、あるいはソフトウェア・プログラムとして実施することができる。単一の実施の形態の状況でしか述べていない場合でも（例えば方法としてしか述べていない場合でも）、記載した実施態様または特性は、その他の形態（例えば装置またはプログラム）で実施することもできる。装置は、例えば、適当なハードウェア、ソフトウェア、およびファームウェアで実施することができる。方法は、例えば、コンピュータなどの処理装置のような装置内で実施することができる。さらに、方法は、処理装置などの装置が命令を実行することによって実施することができ、これらの命令は、例えばＣＤなどのコンピュータ可読媒体またはその他のコンピュータ可読記憶装置、あるいは集積回路に記憶することができる。さらに、コンピュータ可読媒体は、実施により生成されたデータ値を記憶することもできる。

実施により、例えば記憶または伝送することができる情報を搬送するようにフォーマットされた信号を生成することもできることは、当業者には明らかであろう。この情報としては、例えば、方法を実行するための命令や、上述の実施態様の１つによって生成されたデータなどが挙げられる。

さらに、多くの実施態様は、エンコーダ、エンコーダのプリプロセッサ、デコーダ、およびデコーダのポストプロセッサの１つまたは複数で実施することができる。記載または企図した実施態様は、様々な異なる適用分野および製品で使用することができる。こうした適用分野または製品の例としては、セット・トップ・ボックス、携帯電話、携帯情報端末（ＰＤＡ）、テレビジョン、個人記録装置（例えばＰＶＲ、記録ソフトウェアを実行しているコンピュータ、ＶＨＳ記録装置など）、カムコーダ、インターネットなどの通信リンクを介したデータ・ストリーミング、およびビデオ・オン・デマンドなどが挙げられる。

さらに、本開示によりその他の実施態様が企図される。例えば、開示した実施態様の様々な特性を結合、削除、修正、または補足することにより、追加の実施態様を生みだすこともできる。

以下のリストは、様々な実施態様の簡単なリストである。このリストは、全てを網羅したものではなく、多くの可能な実施態様のうちのごく一部を簡単に記載したものに過ぎない。

１．提案した包括的レート制御方法を採用して正確なＧＯＰビット達成によってＨＲＤコンフォーマンスをサポートするＧＯＰ並列マルチスレッド単一パス・ビデオ・エンコーダ。

２．以下の提案する技術のうちの任意の１つまたは複数を含むことにより正確なＧＯＰビットが達成される実施態様１。（ｉ）短いＧＯＰの発生を低減するシーン終端部短ＧＯＰマージ、（ｉｉ）ＧＯＰレベルおよびフレーム・レベルのビット・バジェットのバイトへの丸め、（ｉｉｉ）フレーム・レベルのビット割付けにおけるｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓを防止するためのＧＯＰレベルのビット予約、（ｉｖ）フレーム・レベルのビット予約、（ｖ）ＭＢレベル・レート制御におけるビット・オーバシュート補償、（ｖｉ）ＧＯＰの符号化の終わりのフィラー・ユニット付加、ならびに（ｖｉｉ）隣接するＧＯＰのマージによりバッファ・サイズを減少させ、２つの別個のスレッド間待機セマフォを用いて待機デッドロックを防止する、マルチスレッド符号化情報のバッファリングおよび通信機構。

３．ＧＯＰレベルのビット予約において、フレーム・レベルのビット割付けにおいてｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓ状況を防止するためのＧＯＰの中間フレームに対するビット予約と、ビット・オーバシュートを防止するためのＧＯＰの最後のフレームに対するビット予約とが別々に行われる、実施態様２。

４．フレーム・レベルのビット割付けにおけるｓｈｏｒｔ＿ｏｆ＿ｂｉｔｓが、フレームの予測残差符号化に十分なビットを有していないものとして定義される、実施態様３。

５．ＭＢレベル・レート制御におけるビット・オーバシュート補償が、図３に規定するように、定期的なビット・オーバシュート検査、適応型ビット・オーバシュート比率推定、および残り目標ビット調節を含む、実施態様２。

６．本開示に記載する実施態様の何れかによって生成される信号。

７．本開示に記載の１つまたは複数の実施態様による、ＨＲＤ情報などのビデオ符号化情報の生成、アセンブル、記憶、送信、受信、および／または処理。

８．記載の実施態様の１つに従って、またはそれと通信して動作することができる装置（例えばエンコーダ、デコーダ、プリプロセッサ、ポストプロセッサなど）。

９．本開示に記載する実施態様の１つまたは複数に従って、１つまたは複数のＨＲＤコンフォーマンス・エンジンあるいはＨＲＤコンフォーマンスを実行するための命令セットを記憶する装置（例えばコンピュータ可読媒体など）。

１０．本開示に記載する実施態様の１つまたは複数に従って、ＨＲＤに関連する情報あるいはＨＲＤ出力または動作に関連する情報を含むようにフォーマットされた信号。

１１．信号がディジタル情報を表す、実施態様１０。

１２．信号が電磁波である、実施態様１０。

１３．信号がベースバンド信号である、実施態様１０。

１４．情報が、残差データ、動きベクトル・データ、および参照指標データの１つまたは複数を含む、実施態様１０。

これらの実施態様は、符号化後に、各ＧＯＰが事前に割り付けられたビット・バジェットを過不足なく正確に使用することを保証する包括的な方法であり、単一パス実時間ビデオ符号化システムにおいて効果的にＨＲＤコンフォーマンスをサポートする方法を与えるので有利である。

前述の内容は、本発明の実施の可能性の一部を例示したものである。本発明の範囲および趣旨内で、その他の多くの実施例が可能である。従って、上記の記述は、制限的なものとではなく例示的なものとして見なすべきものであり、本発明の範囲は、添付の特許請求の範囲およびその全ての均等物によって与えられるものとする。

Claims (15)

1. ＧＯＰの複数のスレッドをバッファから並列に単一パスで符号化するステップと、
   前記バッファ中で、シーンの終端部においてフレーム数が低フレームしきい値未満であるＧＯＰを以前のＧＯＰとマージするステップと、
   各ＧＯＰについての仮想参照デコーダ（ＨＲＤ）情報を前記バッファに記憶するステップと、
   前記バッファ中で隣接するＧＯＰについてのＨＲＤ情報をマージするステップと、
   を含む、ビデオを符号化する方法。
2. いくつかのビットを各ＧＯＰに割り付けるステップをさらに含み、前記複数のスレッドが、全ての未符号化ＧＯＰのビット割付けを、それらそれぞれの符号化の開始前に待機する可能性がある、請求項１に記載の方法。
3. 符号化の完了時に、各符号化スレッドが、待機スレッドのそれぞれに対して、それぞれの待機終了セマフォを送信する、請求項２に記載の方法。
4. 各待機スレッドが、前記符号化スレッドから待機終了セマフォを受信する、請求項２に記載の方法。
5. セマフォ待機デッドロックを防止するために、前記待機スレッドの１つが待機終了セマフォを受信した後でその待機を終了し、その後直ちにそのＧＯＰより前であるがまだビットを割り付けられていない新たな最も早いＧＯＰのビット割付け結果を待機する新たなセマフォを設定したときには、この新たな待機セマフォは、前記待機終了セマフォとは別個の異なるセマフォである、請求項４に記載の方法。
6. バッファと、
   グループ・オブ・ピクチャ（ＧＯＰ）の複数のスレッドを前記バッファから並列に単一パスで符号化する符号化モジュールと、
   シーンの終端部においてフレーム数が低フレームしきい値未満であるＧＯＰを前記バッファ中で以前のＧＯＰとマージするマージ・モジュールと、
   各ＧＯＰについての仮想参照デコーダ（ＨＲＤ）情報を前記バッファに記憶し、前記バッファ中で隣接するＧＯＰのＨＲＤ情報をマージするＨＲＤ情報監視モジュールと、
   を備える、ビデオ・エンコーダ。
7. いくつかのビットを各ＧＯＰに割り付ける割付けモジュールをさらに備え、前記複数のスレッドが、全ての未符号化ＧＯＰのビット割付けを、それらそれぞれの符号化の開始前に待機する可能性がある、請求項６に記載のエンコーダ。
8. 符号化スレッドから各待機スレッドにそれぞれ送信される、複数の待機終了セマフォをさらに備える、請求項７に記載のエンコーダ。
9. 各待機スレッドが、前記符号化スレッドから待機終了セマフォを受信する、請求項７に記載のエンコーダ。
10. セマフォ待機デッドロックを防止するために、待機スレッドの１つが待機終了セマフォを受信した後でその待機を終了し、その後直ちにそのＧＯＰより前であるがまだビットを割り付けられていない新たな最も早いＧＯＰのビット割付け結果を待機する新たなセマフォを設定したときには、この新たな待機セマフォは、前記待機終了セマフォとは別個の異なるセマフォである、請求項９に記載のエンコーダ。
11. ＧＯＰの複数のスレッドをバッファから並列に単一パスで符号化するステップと、
    前記バッファ中で、シーンの終端部においてフレーム数が低フレームしきい値未満であるＧＯＰを以前のＧＯＰとマージするステップと、
    各ＧＯＰについてのデコーダ情報を前記バッファに記憶するステップと、
    前記バッファ中で隣接するＧＯＰについての情報をマージするステップと、
    を含む、ビデオを符号化する方法。
12. いくつかのビットを各ＧＯＰに割り付けるステップをさらに含み、前記複数のスレッドが、全ての未符号化ＧＯＰのビット割付けを、それらそれぞれの符号化の開始前に待機する可能性がある、請求項１１に記載の方法。
13. 符号化の完了時に、各符号化スレッドが、待機スレッドのそれぞれに対して、それぞれの待機終了セマフォを送信する、請求項１２に記載の方法。
14. 各待機スレッドが、前記符号化スレッドから待機終了セマフォを受信する、請求項１２に記載の方法。
15. セマフォ待機デッドロックを防止するために、待機スレッドの１つが待機終了セマフォを受信した後でその待機を終了し、その後直ちにそのＧＯＰより前であるがまだビットを割り付けられていない新たな最も早いＧＯＰのビット割付け結果を待機する新たなセマフォを設定したときには、この新たな待機セマフォは、前記待機終了セマフォとは別個の異なるセマフォである、請求項１４に記載の方法。

Images