JP5106722B2

JP5106722B2 - ビデオ・ストリームをトリック・モードでデコードするための方法および装置

Info

Publication number: JP5106722B2
Application number: JP2001147845A
Authority: JP
Inventors: アベラールフランク; ヴェルディエアラン
Original assignee: Thomson SA
Current assignee: Technicolor SA
Priority date: 2000-05-19
Filing date: 2001-05-17
Publication date: 2012-12-26
Anticipated expiration: 2021-05-17
Also published as: MXPA01004843A; HK1038861B; KR20010106226A; CN1325234A; ES2234729T3; HUP0101843A2; EP1158796B1; AU4388701A; CN1226873C; JP2002027409A; EP1156674A1; ATE286643T1; MY127087A; US20020001458A1; ZA200103672B; HK1038861A1; DE60108199D1; HUP0101843A3; KR100788869B1; AU777957B2

Description

【０００１】
【発明の属する技術分野】
本発明は、コード化ビデオ画像のランダム・アクセス・ソースと、ビデオ・デコーダと、デコードされた画像を格納するための複数の再構築バッファとを含むビデオ・デコーディング装置中で圧縮ビデオ画像をデコードするための方法に関する。
【０００２】
【従来の技術】
ＭＰＥＧビデオ・ストリームが記憶装置（例えばデジタル・ビデオ・デコーダ中に組み込まれるハード・ディスク・ドライブ−ＨＤＤ−）に格納され、ＭＰＥＧデコーダを使用して読み返し、提示することができるシステムでは、ユーザは、異なる速度での逆プレイバックなどのトリックモード・プレイが可能であることを当然期待する。
【０００３】
ＭＰＥＧビデオ・ストリーム構造では、１つのコード化画像を表すデータに対応するビデオ・アクセス・ユニットが、以前に送った画像に依存する可能性があることを考慮するため、逆方向でのＭＰＥＧエンコード化ビデオ・シーケンスの提示は、難しい問題である。実際、ビデオ・アクセス・ユニットは、順方向への表示のためのビデオ・アクセス・ユニットのデコーディングを容易にする順序で送られる。したがって、この方向でストリームをデコードするためには３つの再構築バッファで十分である。
【０００４】
逆方向でのプレイバックが必要なとき、それが通常の速度または加速した速度であっても、１つの解決策は、１群の画像（一般には１２画像）のうちどの画像も表示しないうちにこのグループに対応する全ての画像をデコードすることにある。そのようなグループの最後の画像（順方向の表示順で）は、実際グループの最初の画像に依存する可能性があり、その画像は、イントラ・タイプ画像である。プレイバック速度に依存して、これらのデコードされた画像のうちの一部だけしか表示されない可能性がある。
【０００５】
通常のビデオ・デコーダは、表示期間（例えば４０ｍｓ）ごとに１つの画像のデコーディングを実施する。これは、トリックモード・プレイバックには適合しない。
【０００６】
【発明が解決しようとする課題】
本発明の目的は、コード化ビデオ画像のランダム・アクセス・ソースと、ビデオ・デコーダと、デコードされた画像を格納するための複数の再構築バッファとを含むビデオ・デコーディング装置中で圧縮ビデオ画像をデコードするための方法であり、
表示モードに従って画像のデコーディングの順序を確立するステップと、
画像を再構築バッファの可用性に基づいてデコードするように前記ビデオ・デコーダに非同期式に命令するステップとを特徴とする。再構築バッファが利用可能になるとすぐに、次の画像がデコードされる。デコーダは、表示期間ごとに１つの画像をデコードするのではなく、所定の順序で画像のデコーディングを予想する。特に逆トリックモード・リプレイの場合、所与の画像が、ある場合には事前に全てデコードする必要のある４つまたはそれ以上の画像に依存する可能性があるので、これは重要である。
【０００７】
【課題を解決するための手段】
一実施形態によれば、この方法は、さらに以下のステップを含む。
表示すべき画像を含む再構築バッファへのアクセスを、前記画像が表示されるまでロックするステップ。
別の画像のデコーディングをロックされていない再構築バッファの可用性に基づいて命令するステップ。
【０００８】
したがってデコーディングは、表示プロセスによって制御される。再構築バッファへのアクセスをロック解除し、したがって次の画像がデコードされる時を制御するのは、このプロセスである。
【０００９】
一実施形態によれば、画像のデコーディングに対する順序を確立するステップは、
前記ストリーム中の画像の中から表示すべき画像のリストを決定するステップと、
表示すべき前記画像に対する予測子の連鎖を繰り返し決定し、前記予測子に依存する画像の前に予測子をデコードするために必要な順序で前記予測子を表示すべき画像の前記リスト中に挿入するステップとを含む。
【００１０】
一実施形態によれば、圧縮ビデオ・ストリームは、デコーディングの順序で画像を含み、この方法は、両方向画像に対して、最近隣および最遠方予測子を決定するステップをさらに含む。ただし、前記最近隣予測子は、ストリーム中で前記両方向画像の最も近くに現れる画像であり、前記最遠方予測子は、前記最近隣予測子の前にデコードされる。
【００１１】
一実施形態によれば、画像をデコードする順序を決定するステップは、
ビデオ・ストリームの内容を記述する所定の情報をロードするステップと、
前記情報から画像をデコードする前記順序を選択した表示モードに応じて導出するステップとを含む。
【００１２】
一実施形態によれば、この方法は、デコードされた画像を記憶するために利用可能な再構築バッファの中から再構築バッファを選択するステップにおいて、前記選択が、表示すべき画像がその中に最も長時間に渡って格納されていない利用可能な再構築バッファを選択するように実施されるステップをさらに含む。
【００１３】
一実施形態によれば、この方法は、各再構築バッファにカウンタを割り当てるステップと、画像が表示されるごとに各カウンタを増分するステップと、バッファの画像が表示されたときそれに関連するカウンタをリセットするステップと、デコードすべき画像に対してバッファに最高のカウンタ値を割り当てるステップとをさらに含む。
【００１４】
好ましい一実施形態によれば、この方法は、３つの再構築バッファのみを使用して実施されるが、必ずしもこの数に限定されない。
【００１５】
一実施形態によれば、この方法は、画像が既に再構築バッファのうちの１つに存在するかどうかに関わらず前記画像のデコーディングの前に検証するステップと、この場合に前記画像の第２デコーディングを回避するステップとをさらに含む。
【００１６】
本発明の別の目的は、
コード化画像を含む圧縮ビデオ・ストリームのランダム・アクセス・ソースと、
デコードすべき画像を選択するための手段と、
デコードされた画像を格納するための複数の再構築バッファと、
コード化画像をデコードするためのビデオ・デコーダと、
再構築バッファの書込みアクセスについての可用性をモニタし、選択された画像を再構築バッファの可用性に基づいてデコードするように前記ビデオ・デコーダを制御するための手段であって、再構築バッファの可用性が前記再構築バッファ中に含まれる画像の表示のステータスによって決定される手段とを特徴とするビデオ・デコーディング装置である。
【００１７】
ランダム・アクセス・ソースは、順次ソースに接続された中間記憶領域とすることもできる。
【００１８】
本発明の方法および装置により、３つの再構築バッファのみを使用して、異なる速度で逆方向での記録されたビデオ・ストリームのプレイバックが可能となる。
【００１９】
選択された画像をデコードするために、本発明の方法は、再帰的なプロセスを使用して、表示すべき画像の予測子画像を決定し、デコードする。
【００２０】
有利には、記録されたストリームを記述する所定のトリックモード情報は、予測子画像を決定するために使用される。このトリックモード情報は、トリックモードのタイプおよび記録されたストリーム中での関連するデータの位置を記述する画像予測子のリンクされたリストの形をとることができる。
【００２１】
特定のバッファ割り振り機構が、どの画像に対してどの再構築バッファを使用すべきかを決定するために使用される。
【００２２】
表示すべき画像を含むバッファへの書込みアクセスは、この画像が表示されるまで禁止される。
【００２３】
本発明の他の特徴および利点は、本発明の非限定的実施形態の説明を通して明らかとなろう。以下の図面は、実施形態を示す。
【００２４】
【発明の実施の形態】
１．全体的なシステムの概要
図１のデジタル・テレビジョン受信機／デコーダ１は、チューナおよびアナログ／デジタル・コンバータ（示していない）によって供給される順方向誤り訂正回路２を備える。訂正デジタル信号は、移送ストリーム・デマルチプレクサおよびフィルタ４に供給される。このデマルチプレクサおよびフィルタ４は、受信機１の中央伝送バス１１に接続される。その役割は、入りデータ・ストリーム中のある移送ストリーム（ＴＳ）パケットを選択し、それらを受信機の異なるアプリケーションに送ることである。その目的で、それは、マイクロプロセッサ１０によってプログラムされたフィルタを備える。
【００２５】
ＭＰＥＧストリームを記録する目的で、受信機は、例えばＥＩＤＥインターフェースなどのインターフェース１３を介してバス１１にリンクされたハード・ディスク・ドライブ１２を備える。メモリ５は、ハード・ディスクに情報を格納し、取り出すために使用されるいくつかのバッファを備える。
【００２６】
メモリ５は、環状バッファ１５〜２３を備える。書込みＦＩＦＯ１５は、ハード・ディスク１２上に記録するために、ＴＳパケットをデマルチプレクサおよびフィルタ４からの到着順に格納するために使用される。読込みＦＩＦＯ１６は、ハード・ディスクから読み込まれたＴＳパケットを格納するために使用される。ＦＩＦＯ１５およびＦＩＦＯ１６は、ＴＳパケットの内容の性質を無視して、受け取ったデータ・ストリームのサブストリームを記録または読み込むために使用される。記録するために、プログラムされた基準に対応するすべてのＴＳパケットは、ハード・ディスク１２に転送する前にフィルタにかけられ、書込みＦＩＦＯ１５に書き込まれる。このモードは、移送ストリーム・レベル・レコーディング・モードと呼ばれ、この説明の残りの部分で使用されるモードとなることになる。
【００２７】
完全を期して、レコーディングは、パケット化基本ストリーム（ＰＥＳ）レベルでも達成することができることを述べておく。ＦＩＦＯ１８〜２３は、その目的に使用される。メモリ５は、トリックモード・バッファ１７も保持する。このバッファは、トリックモード情報を生成するためにレコーディング中ストリーム・パーサ３およびマイクロプロセッサによって使用され、次いでそのトリックモード情報は、ハード・ディスク上に記録される。このバッファは、ハード・ディスクから読み込まれたトリックモード情報を格納するためにも再生中に使用される。
【００２８】
これら２つのモードのさらなる詳細は、既に述べた欧州特許出願中に見つけることができる。
【００２９】
ストリームをデコードする目的で、受信機１は、移送ストリーム・デマルチプレクサおよびＰＥＳパーサ６を介して、または直接にＰＥＳパーサ６を介して中央バス１１に接続された各音声およびビデオ・デコーダ８および９も備える。レコーディング・モードに依存して、ＴＳ層は、前もって削除されている、または削除されない可能性がある。参照１４は、表示可能なアナログ・ビデオ信号を生成するために必要なビデオ処理回路を示す。
【００３０】
ビデオ・デコーダ９宛ての圧縮データは、入力ビット・バッファ２５中に格納され、圧縮データは、その入力ビット・バッファ２５からデコーダ９によって適切に読み取られる。再構築された画像は、再構築メモリ２６中に格納され、その再構築メモリ２６は、読込みおよび書込み両方のためにデコーダによってアクセスされる。本発明による再構築メモリは、それぞれが１つのデコードされた画像に対応する３つのバッファ（Ａ、Ｂ、Ｃ）を有する。
【００３１】
受信機１は、受信機のオペレーティング・システム、デバイス・ドライバおよび他のソフトウェア・モジュールを保持する、再プログラム可能な不揮発性メモリ２４も備える。
【００３２】
本説明の目的のために、トリックモード情報は、ディスク上に格納されている各ビデオ・アクセス・ユニットごとに、レコーディング順に画像のタイプ（Ｉ、Ｐ、またはＢ）と、関連する画像、画像のグループ、および画像をデコードするために必要なハード・ディスク上のシーケンス情報の位置とを含む。トリックモード情報は、３つの異なるタイプのテーブル中にセグメント化される。それらは、時間索引テーブル、ビデオ・ユニット記述テーブル、およびある数の連続したグループの画像の内容をそれぞれが記述するいくつかのビデオ記述ユニット（ＶＤＵ）である。
【００３３】
そのようなトリックモード情報の例は、「Method and device for decoding a digital video stream in a digital video system using dummy header insertion」と題し、ＴＨＯＭＳＯＮｍｕｌｔｉｍｅｄｉａの名で２０００年４月５日に出願された欧州特許出願に記載されている。
【００３４】
図２は、本実施形態による受信機１のソフトウェア・モデルのダイアグラムである。このダイアグラムは、以下の要素を含む。
【００３５】
（ａ）全トリックモード制御
このソフトウェア・モジュールは、デコーディング・プロセスの全制御を請け負う。トリックモード（逆方向／順方向、低速／高速）に従って、このモジュールは、どの画像を送り、デコードし、表示すべきかを指定する。
【００３６】
例として、選んだトリックモードが通常スピードのＸ倍の高速逆方向再生である場合、このモジュールは、一時索引テーブルおよびＶＤＵを使用して、どの画像を表示すべきかということ、この画像のタイプ（Ｉ、Ｂ、Ｐ）、およびＰまたはＢタイプ画像の場合には事前にデコードする必要のある他の画像（予測子）を判定する。予測子のデコーディングは、それ自体他の予測子を必要とする可能性があるため、このプロセスは、繰り返し実施される。
【００３７】
トリックモード情報は、トリックモード情報アクセス・マネージャ（以下を参照）からの全トリックモード制御によって要求される。
【００３８】
繰り返しのデコーディング・アルゴリズムに基づいて、全トリックモード制御は、ストリーム・アクセス・マネージャ（以下を参照）に特定のビデオ・アクセス・ユニットをＭＰＥＧビデオ・デコーダの入力バッファに転送するように命令する。
【００３９】
全トリックモード制御モジュールは、再生バッファ占有の仮想イメージをどのステップでも維持する。
【００４０】
３つの再生バッファのうちの特定の１つの中の画像をデコードするために、全トリックモード制御は、図５および６のフローチャートと共に後に説明する再構築バッファ選択プロセスを実行し、圧縮画像を転送する前にデコーディング・マネージャに通知する。
【００４１】
（ｂ）トリックモード情報アクセス・マネージャ
全トリックモード制御モジュールは、記録されたストリームに関するトリックモード情報を必要とする。この情報は、ハード・ディスク・ドライブ１２上に格納される。トリックモード情報アクセス・マネージャは、ハード・ディスク・ドライブから情報を収集し、それを全トリックモード制御に供給することを請け負う。
【００４２】
（ｃ）ストリーム・アクセス・マネージャ
デコードすべき各単一画像は（次々に表示すべきであるかどうかにかかわらず）、ビデオ・デコーダ９に送らなければならない。圧縮された内容にアクセスするためのすべての必要な情報は、トリックモード情報テーブル中に供給される。ストリーム・アクセス・マネージャは、全トリックモード制御によって識別された画像データをメモリ５からビデオ・デコーダに転送し、ストリーミング・ドライバによってハード・ディスクから読み取られた情報の中から関連する情報だけを転送することを請け負う。デコードすべき各画像について、ストリーム・アクセス・マネージャは、全トリックモード制御から通知を受けることになる。
【００４３】
（ｄ）ストリーミング・ドライバ
ストリーミング・ドライバは、ストリーム・アクセス・マネージャによる処理のためにメモリ５に送達すべきビデオ内容を選び出すことを請け負う。一般に、ストリーミング・ドライバは、関連するデータおよび他のデータを含むハード・ディスク・ドライブから、１つまたは複数のブロックをロードすることになる。トリックモード情報がストリームと共に挿入される場合、ストリーミング・ドライバは、トリックモード情報を抽出し、それをバッファ１７中に格納することも請け負う。
【００４４】
（ｅ）ビデオ・デコーディング・マネージャ
ビデオ・デコーダは、新しいビデオ・アクセス・ユニットを受け取り、識別したとき、ビデオ・デコーディング・マネージャに通知する。ビデオ・デコーディング・マネージャは、キューを介して全制御からこの特定の画像のデコーディングおよび／または表示を命令および指定する完全なコマンドを先に受け取っている。このコマンドに基づいて、ビデオ・デコーディング・マネージャは、新しく検出された画像のデコーディングをプログラムし、かつその画像を表示しなければならない場合、この画像は表示すべきものであり、どのように表示しなければならないか（トップまたはボトム・フィールドを最初にするか、順方向または逆方向か）をキューを介してディスプレイ・マネージャに通知する。
【００４５】
各再構築バッファのソフトウェア記述子は、各バッファの状態を反映する。これらの記述子は、ビデオ・デコーディング・マネージャおよびディスプレイ・マネージャによって共有される。デコーディングをプログラムする前に、ビデオ・デコーディング・マネージャは、この画像を受け取らなければならない再構築バッファが利用可能かどうかをテストする。利用可能でない場合、ビデオ・デコーディング・マネージャは、ディスプレイ・マネージャがそのバッファを開放するのを待つ。次いで、このバッファ中のデコーディングをプログラムすることができ、バッファ・アクセスを再びロックすることができる。
【００４６】
（ｆ）ディスプレイ・マネージャ
表示すべき画像がデコードされた場合、ディスプレイ・マネージャは、ビデオ・デコーディング・マネージャから通知を受ける。ロックされた再構築バッファがもはや表示用に必要でなくなると、ディスプレイ・マネージャは、ロックされた再構築バッファをロック解除し、それらを別の画像のデコーディング用に解放する。
【００４７】
ビデオ・デコーダ９は、デコーディングおよび結果として得られる個々の画像の表示に関するあるタイプの制御および操作を可能とするＡＰＩ（アプリケーション・プログラム可能インターフェース）を提供することができる。具体的には、個々の画像をデコードし、続いてそれを所与の時間およびあるフレーム間隔の間表示する、または全く表示しないようにデコーダに命令することができる。
【００４８】
画像表示は、同期的プロセスである。５０Ｈｚのシステムに対しては、ディスプレイ・マネージャは、４０ｍｓごとにどの画像を表示すべきかをチェックする。言い換えれば、ディスプレイ・マネージャは、表示すべき画像を含む再構築バッファを識別する。
【００４９】
ビデオ・デコーディング・マネージャによって満たされたディスプレイ・マネージャの通知キューが空の場合、表示用に利用可能な画像は存在しない。新しい画像を表示すべき時まで、表示された最後の画像が次いで繰り返されることになる。
【００５０】
一般に、表示プロセスは、この連鎖中で最も低速なプロセスである。すべての他のプロセスは、表示によって課されたリズムに追従することになる。
【００５１】
デコーディング・プロセスが非同期的で、非常に高速にすることができるため、表示すべき画像がデコードされたとき、その再構築バッファは、その画像が実際に表示される前は後続の画像によるどんな上書きも避けるためにロックされる。ディスプレイ・マネージャだけが、画像が表示されたときおよび新しい画像の再構築が同じバッファ中で開始されたときにロック解除をすることが可能である。ビデオ・デコーディング・マネージャは、全トリックモード制御によって要求されたときに新しい画像をデコードするために、ディスプレイ・マネージャが画像を表示し、バッファを開放するのを待つ。
【００５２】
全トリックモード制御によるデコーディング要求の生成およびストリーム・アクセス・マネージャによるデコーダの送りも、一般にデコーディング・プロセスより高速である。
【００５３】
ビデオ・デコーダのビットバッファが一杯であり、さらに多くの圧縮データを送ることができない場合、新しい画像のデコーディングを依頼することはできないので、全トリックモード制御と、ストリーム・アクセス・マネージャによるコードされた画像供給とが同期される。全トリックモード制御は、必要なときに新しい画像の送信を要求し、別の要求を発行する前に完了すべき送信を待つ。送信の完了はストリーム・アクセス・マネージャによって全トリックモード制御プロセスに通知される。
【００５４】
ストリーム・アクセス・マネージャおよび全制御は、ビデオ・デコーダがビット・バッファからデータを取り出すのを待ち、ビデオ・デコーダは、ビデオ・デコーディング・マネージャの制御の下で、ディスプレイ・マネージャがバッファを開放するのを待つ。全体のシステムは、最終的に表示のリズムに追従することになる。
【００５５】
ディスプレイ上に表示するために、ＭＰＥＧ画像は、事前にデコードされていなければならない。ビデオ・プロセスは、一連の連続した操作に分割することができる。図３は、所与の画像に対する全体的なビデオ・プロセスの概観である。いくつかのそのようなプロセスは、実行の異なる段階で並列に実行することができる。第１操作は、表示すべき次の画像を識別することにある。これは、もちろんトリックモードのタイプに依存する。この画像が決定されると、それをデコードしなければならない。この操作は、他の画像の再帰的なデコーディングを含むことができる。この操作は、１つまたは複数の自由再構築バッファの可用性にも依存する。最後の操作は、デコードされた画像を表示することにある。
【００５６】
本実施形態によるトリックモード情報は、リンクされたアイテムを含むデータ構造である。それは、互いにそのストリーム中での順番に従ってリンクされた画像記述子で作成される。受信されたとき（およびこの場合は記録されたとき）のストリームは、画像を表示順ではなく、デコーディング順で含むことを想起されたい。各画像記述子は、ＭＰＥＧコード化ストリーム中の画像についての詳細ならびに画像の圧縮材料を記憶ユニット上に位置付けるための十分な情報を与える。ストリーム中の各画像は、特定の画像ＩＤで識別される。図３および４では、「Ｎ」がそのような画像ＩＤであり、関数「Ｎｅｘｔ（Ｎ）」は、画像ＩＤを返す。Ｎｅｘｔ（Ｎ）関数のプロセッシングは、表示すべきトリックモードのタイプが与えられているとして、トリックモード情報の解析に基づく。
【００５７】
順方向モードでは、Ｎｅｘｔ（Ｎ）は、通常の表示順（すなわち、一時参照に関して）に従って表示すべき次の画像のＩＤを返す。逆方向モードでは、Ｎｅｘｔ（Ｎ）は、通常の表示順に従って前の画像のＩＤを返す。
【００５８】
高速操作（順方向または逆方向）については、画像をスキップしなければならず、したがってＮｅｘｔ（Ｎ）は、非連続な画像のＩＤを返す。
【００５９】
Ｎｅｘｔ（Ｎ）関数は、Ｎを知って、画像をデコードするために必要なすべてのデータにアクセスするために既に述べた特許出願中で定義されるトリックモード・テーブルを使用する全トリックモード制御モジュールによって実現される。
【００６０】
低速動作トリックモード（順方向または逆方向）は、ディスプレイ・マネージャの制御下にある。このトリックモードが単に１画像あたり４０ｍｓより低速の表示レートを暗黙指定するからである。
【００６１】
図４は、ＤｅｃｏｄｅＰｉｃｔｕｒｅコマンドの原理を示す。再構築バッファの現状態が、図の左側に表されている。バッファはそれぞれ、ある画像（Ｘ、Ｙ、Ｚ）を含む。ＤｅｃｏｄｅＰｉｃｔｕｒｅプロセスは、画像Ｎに適用された場合、他の２つのバッファの内容が何であっても、バッファのうちの１つが最後にはこの要求された画像を含むことになることを保証する。
【００６２】
既に述べた通り、ＭＰＥＧ画像は、他の画像に依存する可能性があり、そのデコーディングは、既に再構築した画像の可用性を必要とすることがある。ＭＰＥＧコード化ストリームは、イントラ画像の形式の下で常に多数の入口点を含む。そのような入口点に追従する画像は、入口点に先行する画像に依存しない。ＤＶＢ標準は、これらの入口点が少なくとも０．５ｓごとに生じるように指定する。画像の開グループは、特定のケースである。
【００６３】
ＤｅｃｏｄｅＰｉｃｔｕｒｅコマンドは、図５のフローチャートで示されるように繰り返し実施される。画像のデコーディングが、以前にデコードした１つまたは２つの画像の存在を必要とする場合、これらの後者の画像がまずデコードされる。
【００６４】
ターゲット画像（ＰｉｃＩＤ）がまだ再構築バッファ中に存在しない場合、ターゲット画像をデコードする必要がある。ＰｉｃＩＤで識別される画像が「Ｐ」または「Ｂ」タイプの場合、そのデコーディングは、順方向および逆方向予測子の存在を必要とする可能性がある。この情報は、トリックモード・テーブル中で利用可能である。
【００６５】
デコードすべき画像が依存する予測子を与える規則は、単純である。ストリームを逆方向に（すなわち、以前に記録したビデオ・アクセス・ユニットに向かって）通って、最初に遭遇する「Ｐ」タイプまたは「Ｉ」タイプの画像が現画像に対する予測子である。この画像は、トリックモード情報を使用して見つけることができる。この予測子を図５で「最近隣ＩＤ」と呼ぶ。
【００６６】
ＰｉｃＩＤで識別される画像が「Ｐ」タイプ画像である場合、最近隣ＩＤは、ＰｉｃＩＤで識別される画像よりも時間スケールおよび表示順において前に位置付けられる、という意味で順方向予測子である。
【００６７】
ＰｉｃＩＤで識別される画像が「Ｂ」タイプ画像である場合、最近隣ＩＤは、逆方向予測子である。次いで順方向予測子は、次の「Ｉ」または「Ｐ」タイプ画像をさらに逆方向に探すことによって見つかる。この順方向予測子を図５で「最遠方ＩＤ」と呼ぶ。
【００６８】
画像をデコードするためには、再構築された予測子が再構築バッファ中に存在しない場合、再構築された予測子を構築しなければならない。この場合では、ＤｅｃｏｄｅＰｉｃｔｕｒｅコマンドが、これらの画像に対して再帰的に繰り返される。
【００６９】
Ｂ画像の再構築に先立って、既にデコードされ再構築バッファ中に存在しない限り、２つの予測子をデコードしなければならない可能性がある。図５からわかる通り、最遠方ＩＤがまずデコードされ、最近隣ＩＤがそれに続く。最近隣ＩＤも最遠方ＩＤに依存する可能性があるので、後者がまずデコードされる。したがってプロセスは最適化され、最遠方ＩＤに対応する画像の二重デコーディングは回避される。例えば、Ｂ画像が２つのＰ画像から予測される場合、時間においての第２Ｐ画像は、第１Ｐ画像に依存する。
【００７０】
最遠方ＩＤが再構築バッファ中に構築されると、バッファは、最近隣ＩＤの再構築プロセスが一時的結果として保たれる最遠方ＩＤを上書きするのを防ぐためにロックされる。
【００７１】
どのプレイバック・モードであっても、次に説明するように、３つの再構築バッファのみが使用される。
【００７２】
イントラ画像のデコーディングは、予測子を必要としないので、１つの自由バッファのみを必要とする。予測画像のデコーディングは、１つの予測子を必要とする。予測画像のデコードされた予測子が既に別のバッファ中に存在するかどうか、すなわち再帰的デコーディングを実施すべきかどうかに依存して、１つまたは２つのバッファを使用しなければならない可能性がある。
【００７３】
３つのバッファのうち、１つは現在表示されている画像を含む。したがって２つのバッファが、別の画像をデコードするために利用可能であり−それらが現画像の後に表示すべき画像を含まないと仮定して−、したがってどんなＩまたはＰ画像も現画像の表示を妨げることなくデコードすることができる。
【００７４】
一方Ｂ画像は２つの予測子を必要とする。画像の閉グループでは、２つの予測子の一方（「最近隣予測子」）が他方（「最遠方予測子」）に依存する。最遠方予測子をまずデコードし、最近隣予測子がそれに続くことによって、両方の予測子をデコードするために２つのバッファだけしか必要ではない。画像の開グループでは、両方の予測子を独立にすることができるが、これらの予測子は、画像の現グループからのＩ画像および画像の先行するグループのＰ（またはＩ）画像を含むので、画像の前のグループのＰまたはＩ画像をまずデコードする限りは、２つのバッファだけしか必要ではない。
【００７５】
現在表示されている画像が表示すべき次の画像についての予測子のうちの１つではないとき、この次の画像がＢタイプであると仮定して、現在表示されている画像を含むバッファ中にそれを再構築しなければならない。現在利用可能なデコーダでは、表示される画像がすべて表示される前に、表示される画像の上書きを開始することがしばしば可能である。上書きは、例えば表示の開始の２０ｍｓ後に開始することができる。画像がいくつかのフレーム期間に渡って表示される場合、上書きは、当然最後のフレーム期間の間に行われる。
【００７６】
したがって、デコーディング順序が適切に選ばれたとき、３つの再構築バッファだけしか必要でないことは明らかである。
【００７７】
すべての必要な予測子がデコードされたとき、デコードし表示すべき新しい画像を受け取るために、利用可能な再構築バッファを選ばなければならない。一部の場合では、Ｂ画像をデコードする場合など選択が存在しない可能性がある。３つのすべてのバッファを使用する必要がある。つまり、順方向予測子用の１つ、逆方向予測子の１つ、Ｂ画像自体のための１つである。
【００７８】
他の場合では、２つまたは３つのうちからバッファを選ばなければならない。
【００７９】
表示とデコーディングとの間での３つの再構築バッファの割り振りは、全体のシステムの性能のために重要である。実際、適切なバッファを選ばなかったときは、所与の画像をデコードするために追加の遅延が導入される可能性がある。ビデオ・デコーダの処理能力に依存して、次いで画像を表示すべき前に画像が完全にデコードされないことが生じる可能性がある。
【００８０】
デコーディング遅延を回避するために、表示すべき画像に対して選ぶべきバッファが最も過去に表示プロセスによって解放された自由バッファであるように発明者は決定した。
【００８１】
この割り振り方法を実施するために、カウンタが各バッファ・モデル要素に関連付けられる。表示すべき画像がバッファ中で再構築されるとき、このバッファのカウンタはリセットされ、他のバッファのカウンタが増分される。本一実施形態によれば、新しい画像に割り振られたバッファは、最高のカウンタ値を有するバッファである。
【００８２】
図６は、バッファ割り振りプロセスのフローチャートである。図６は、すべてのバッファを通って循環し、予測子を含むためにロックされたものを廃棄し、未ロックのものがあればそれらの中から最大のカウンタ値を有するものを選ぶことから成る。
【００８３】
前で説明した通り、画像の再順序付けおよびバッファ割り振り問題は、３つの各再構築バッファに関する以下のデータ構造のような仮想モデルを使用することで解決される。

【００８４】
逆プレイバックでのデコーディング・プロセスの例を図７に関して説明する。
この例は、画像の開グループの場合に関する。ビデオ・ストリームが以下の構造を有することを考えてみる。
...P'11-B'9-B'10-I2-B0-B1-P5-B3-B4-P8-B6-B7-P11-B9-B10-I"2-B"00-B"1...
ただし、Ｉ、Ｐ、およびＢは、それぞれイントラ、予測、および両方向画像を指定し、各文字に関連する数字は、画像のグループ中での表示の通常の順序を指定する。時間軸は左から右に向かう。すなわち、「最初の」画像のグループが通常はまず表示される。
【００８５】
各画像の予測子は、表１に示されている。
【表１】

【００８６】
図７は、各バッファＡ、Ｂ、およびＣの内容を示す。「フレーム期間」列は、４０ｍｓ表示期間をカウントする（図での厚さに関わらず）。期間「０」は、Ｐ１１の表示期間に対応する。「表示画像」列は、関連するフレーム期間中にどの画像が表示されるかを示す。「フレーム期間ごとのデコーディング」は、所与の４０ｍｓ期間中にデコードされる画像の数を示す。灰色の領域は、所与のバッファの内容が表示される時を示す。
【００８７】
話を簡単にするために、フレーム期間、デコーディング期間、およびバッファ占有期間を並べる。これは実際にはそうする必要はない。第１に、画像をデコードするために必要な時間は、画像に依存する。第２に、画像が完全にデコードされる前に画像の表示を開始することができる。例えば、画像Ｂ”１をデコードすると同時に表示するよう指示された場合、これは、画像のデコーディングの２０ｍｓ後よりも早く表示を開始することを意味する。
【００８８】
画像Ｐ１１〜Ｂ０をこの順序で表示すべきであることを考えてみる。
【００８９】
図７は、前述の再帰的プロセスによって決定された、全ての画像（表示すべきかどうかに関わらず）をデコードする順番でリストする。
【００９０】
Ｐ１１は、Ｐ８に依存し、同様にＰ５に依存し、同様にＩ２に依存する。したがって、Ｉ２は、バッファＡ中で期間−４の間にデコードされ、Ｐ５は期間−３の間に、Ｐ８も期間−３の間にデコードされる。期間−４の間に、画像Ｂ”３が表示される。一方期間−３の間に、画像Ｉ”２が表示される。理解できる通り、期間−３の間に、３つの画像をデコードする必要がある。必要な４番目の画像Ｉ２は、バッファＡが利用可能なので、その前の期間中にデコードされる。その同じ期間の間に、バッファＢおよびＣは利用可能ではない。バッファＢが表示された画像Ｂ”３を含み、バッファＣが表示すべき次の画像Ｉ”２を含むためにロックされるからである。理解できる通り、画像のデコーディングは、ロックされていないバッファの可用性によって制限され、画像は、できるだけ早く必要とされる順序でデコードされる。
【００９１】
この例では画像の開グループを使用しているので、Ｐ１１は、この時点では表示のためにデコードされていないが、画像Ｂ”１およびＢ”０に対する予測子としての役目を果たすためにデコードされる。これらの２つの画像の他の予測子は、Ｉ”２であり、この時点で既にバッファＣ中に存在する。したがってＢ”１およびＢ”０は、即時に（すなわちデコーディングが開始した２０ｍｓ後）デコードし、表示することができる。
【００９２】
Ｐ１１を次いで表示しなければならない。Ｐ１１は既にバッファＢ中に存在しているので、この画像に対して新しいデコーディングを実施する必要がなく、Ｐ１１は、即時に表示される。
【００９３】
期間−１の終わりで、Ｂ”０がデコードされ、バッファＢおよびＣ中に格納されているＢ”０の予測子が無用となるため、バッファＣは利用可能となる。したがって、Ｉ２、Ｐ５、Ｐ８、およびＰ１１に依存するＢ１０のデコーディングに向けての第１ステップとして、Ｉ２がデコードされる。他の画像のデコーディングは、同様のパターンに従う。
【図面の簡単な説明】
【図１】デジタル・テレビジョン・受信機／デコーダのブロック・ダイアグラムである。
【図２】トリックモード・システムの動作に対応する、図１の受信機のソフトウェアの部分のソフトウェア・モデルの図である。
【図３】全ビデオ・デコーディングおよび表示プロセスのフローチャートである。
【図４】「ｄｅｃｏｄｅｐｉｃｔｕｒｅ」コマンドの効果の図である。
【図５】画像のタイプ（Ｉ、Ｐ、またはＢ）に依存した画像のデコーディング・プロセスを説明するフローチャートである。
【図６】本実施形態による空バッファ選択プロセスのフローチャートである。
【図７】逆プレイバックの例に対するバッファ占有とデコーダおよび表示活動とを示すテーブルである。
【符号の説明】
１デジタル・テレビジョン受信機／デコーダ
２順方向誤り訂正回路
３ストリーム・パーサ
４移送ストリーム・デマルチプレクサおよびフィルタ
５メモリ
６ＰＥＳパーサ
７移送ストリーム・デマルチプレクサ
８音声デコーダ
９ビデオ・デコーダ
１０マイクロプロセッサ
１１中央バス
１２ハード・ディスク・ドライブ
１３インターフェース
１４ビデオ処理回路
１５〜２３環状バッファ
２４不揮発性メモリ

Claims

圧縮ビデオ・ストリームのランダム・アクセス・ソースと、ビデオ・デコーダと、デコードされた画像を格納するための複数の再構築バッファとを含むビデオ・デコーディング装置中で圧縮ビデオ画像をデコードするための方法であって、
前記ストリーム中の画像の中から表示すべき画像のリストを決定することにより、画像のデコーディングの順序を確立するステップであって、表示すべき画像のリストの決定が前記画像の再生モードに従う、ステップと、
表示すべき前記画像に対する予測子の連鎖を繰り返し決定し、前記予測子に依存する画像の前に予測子をデコードするために必要な順序で前記予測子を表示すべき画像の前記リスト中に挿入して、デコードすべき画像のリストを獲得する、ステップと、
画像を再構築バッファの可用性に基づいてデコードするように前記ビデオ・デコーダに命令するステップと、
を含み、
前記圧縮ビデオ・ストリームが、デコーディングの順序でコード化画像を含み、
両方向画像に対して、最近隣および最遠方予測子を決定するステップをさらに含み、
前記最近隣予測子が、前記ストリームの後方に向って遭遇する最初のイントラ符号化画像又は最初の予測符号化画像であり、
前記最遠方予測子が、前記最近隣予測子の前にデコードされる
ことを特徴とする方法。
表示すべき画像を含む再構築バッファへのアクセスを、前記画像が表示されるまでロックするステップと、
別の画像のデコーディングをロックされていない再構築バッファの可用性に基づいて命令するステップと
を含む請求項１に記載の方法。
画像をデコードする順序を決定する前記ステップが、ビデオ・ストリームの内容を記述する所定の情報をロードするステップと、
前記情報から画像をデコードする前記順序を選択した表示モードに応じて導出するステップと
を含む請求項１又は２に記載の方法。
デコードされた画像を記憶するために利用可能な再構築バッファの中から再構築バッファを選択するステップにおいて、前記選択が、表示すべき画像がその中に最も長時間に渡って格納されていない利用可能な再構築バッファを選択するように実施されるステップをさらに含む請求項１から３のいずれか一項に記載の方法。
各再構築バッファにカウンタを持たせるステップと、
画像が表示されるごとに各カウンタを増分するステップと、
バッファの画像が表示されたときそれに関連するカウンタをリセットするステップと、
デコードすべき画像に対してバッファに最高のカウンタ値を持たせるステップと
をさらに含む請求項４に記載の方法。
画像が既に再構築バッファのうちの１つに存在するかどうかに関わらず前記画像のデコーディングを判断する前に検証するステップと、
この場合に前記画像の第２デコーディングを回避するステップと
をさらに含む請求項１から５のいずれか一項に記載の方法。
ビデオ・デコーディング装置であって、
前記ストリーム中の画像の中から表示すべき画像のリストを決定することにより、画像のデコーディングの順序を確立する手段であって、表示すべき画像のリストの決定が前記画像の再生モードに従う、手段と、
表示すべき前記画像に対する予測子の連鎖を繰り返し決定し、前記予測子に依存する画像の前に予測子をデコードするために必要な順序で前記予測子を表示すべき画像の前記リスト中に挿入して、デコードすべき画像のリストを獲得する、手段と、
前記確立されたデコーディングの順序でコード化画像を含む圧縮ビデオ・ストリームのランダム・アクセス・ソースと、
デコードすべき画像を選択するための手段と、
両方向画像に対して、最近隣および最遠方予測子を決定するための手段であって、前記最近隣予測子が前記ストリームの後方に向って遭遇する最初のイントラ符号化画像又は最初の予測符号化画像であり、前記最遠方予測子が前記最近隣予測子の前にデコードされる、手段と、
デコードされた画像を格納するための複数の再構築バッファと、
コード化画像をデコードするためのビデオ・デコーダと、
再構築バッファの書込みアクセスについての可用性をモニタし、選択された画像を再構築バッファの可用性に基づいてデコードするように前記ビデオ・デコーダを制御するための手段であって、再構築バッファの可用性が前記再構築バッファ中に含まれる画像の表示のステータスによって決定される手段と
を特徴とするビデオ・デコーディング装置。