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

Abstract

(57)【要約】 【課題】 コード化ビデオ画像のランダム・アクセス・
ソースと、ビデオ・デコーダと、デコードされた画像を
格納するための複数の再構築バッファとを含むビデオ・
デコーディング装置中で圧縮ビデオ画像をデコードする
ための方法を提供すること。 【解決手段】 この方法は、画像のデコーディングの順
序を確立するステップと、画像を再構築バッファの可用
性に基づいてデコードするように前記ビデオ・デコーダ
に命令するステップとを含む。本発明は、本発明の方法
を実現するための装置にも関する。デジタル・ビデオ・
デコーディング装置に適用可能。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、コード化ビデオ画
像のランダム・アクセス・ソースと、ビデオ・デコーダ
と、デコードされた画像を格納するための複数の再構築
バッファとを含むビデオ・デコーディング装置中で圧縮
ビデオ画像をデコードするための方法に関する。

【０００２】

【従来の技術】ＭＰＥＧビデオ・ストリームが記憶装置
（例えばデジタル・ビデオ・デコーダ中に組み込まれる
ハード・ディスク・ドライブ−ＨＤＤ−）に格納され、
ＭＰＥＧデコーダを使用して読み返し、提示することが
できるシステムでは、ユーザは、異なる速度での逆プレ
イバックなどのトリックモード・プレイが可能であるこ
とを当然期待する。

【０００３】ＭＰＥＧビデオ・ストリーム構造では、１
つのコード化画像を表すデータに対応するビデオ・アク
セス・ユニットが、以前に送った画像に依存する可能性
があることを考慮するため、逆方向でのＭＰＥＧエンコ
ード化ビデオ・シーケンスの提示は、難しい問題であ
る。実際、ビデオ・アクセス・ユニットは、順方向への
表示のためのビデオ・アクセス・ユニットのデコーディ
ングを容易にする順序で送られる。したがって、この方
向でストリームをデコードするためには３つの再構築バ
ッファで十分である。

【０００４】逆方向でのプレイバックが必要なとき、そ
れが通常の速度または加速した速度であっても、１つの
解決策は、１群の画像（一般には１２画像）のうちどの
画像も表示しないうちにこのグループに対応する全ての
画像をデコードすることにある。そのようなグループの
最後の画像（順方向の表示順で）は、実際グループの最
初の画像に依存する可能性があり、その画像は、イント
ラ・タイプ画像である。プレイバック速度に依存して、
これらのデコードされた画像のうちの一部だけしか表示
されない可能性がある。

【０００５】通常のビデオ・デコーダは、表示期間（例
えば４０ｍｓ）ごとに１つの画像のデコーディングを実
施する。これは、トリックモード・プレイバックには適
合しない。

【０００６】

【発明が解決しようとする課題】本発明の目的は、コー
ド化ビデオ画像のランダム・アクセス・ソースと、ビデ
オ・デコーダと、デコードされた画像を格納するための
複数の再構築バッファとを含むビデオ・デコーディング
装置中で圧縮ビデオ画像をデコードするための方法であ
り、表示モードに従って画像のデコーディングの順序を
確立するステップと、画像を再構築バッファの可用性に
基づいてデコードするように前記ビデオ・デコーダに非
同期式に命令するステップとを特徴とする。再構築バッ
ファが利用可能になるとすぐに、次の画像がデコードさ
れる。デコーダは、表示期間ごとに１つの画像をデコー
ドするのではなく、所定の順序で画像のデコーディング
を予想する。特に逆トリックモード・リプレイの場合、
所与の画像が、ある場合には事前に全てデコードする必
要のある４つまたはそれ以上の画像に依存する可能性が
あるので、これは重要である。

【０００７】

【課題を解決するための手段】一実施形態によれば、こ
の方法は、さらに以下のステップを含む。表示すべき画
像を含む再構築バッファへのアクセスを、前記画像が表
示されるまでロックするステップ。別の画像のデコーデ
ィングをロックされていない再構築バッファの可用性に
基づいて命令するステップ。

【０００８】したがってデコーディングは、表示プロセ
スによって制御される。再構築バッファへのアクセスを
ロック解除し、したがって次の画像がデコードされる時
を制御するのは、このプロセスである。

【０００９】一実施形態によれば、画像のデコーディン
グに対する順序を確立するステップは、前記ストリーム
中の画像の中から表示すべき画像のリストを決定するス
テップと、表示すべき前記画像に対する予測子の連鎖を
繰り返し決定し、前記予測子に依存する画像の前に予測
子をデコードするために必要な順序で前記予測子を表示
すべき画像の前記リスト中に挿入するステップとを含
む。

【００１０】一実施形態によれば、圧縮ビデオ・ストリ
ームは、デコーディングの順序で画像を含み、この方法
は、両方向画像に対して、最近隣および最遠方予測子を
決定するステップをさらに含む。ただし、前記最近隣予
測子は、ストリーム中で前記両方向画像の最も近くに現
れる画像であり、前記最遠方予測子は、前記最近隣予測
子の前にデコードされる。

【００１１】一実施形態によれば、画像をデコードする
順序を決定するステップは、ビデオ・ストリームの内容
を記述する所定の情報をロードするステップと、前記情
報から画像をデコードする前記順序を選択した表示モー
ドに応じて導出するステップとを含む。

【００１２】一実施形態によれば、この方法は、デコー
ドされた画像を記憶するために利用可能な再構築バッフ
ァの中から再構築バッファを選択するステップにおい
て、前記選択が、表示すべき画像がその中に最も長時間
に渡って格納されていない利用可能な再構築バッファを
選択するように実施されるステップをさらに含む。

【００１３】一実施形態によれば、この方法は、各再構
築バッファにカウンタを割り当てるステップと、画像が
表示されるごとに各カウンタを増分するステップと、バ
ッファの画像が表示されたときそれに関連するカウンタ
をリセットするステップと、デコードすべき画像に対し
てバッファに最高のカウンタ値を割り当てるステップと
をさらに含む。

【００１４】好ましい一実施形態によれば、この方法
は、３つの再構築バッファのみを使用して実施される
が、必ずしもこの数に限定されない。

【００１５】一実施形態によれば、この方法は、画像が
既に再構築バッファのうちの１つに存在するかどうかに
関わらず前記画像のデコーディングの前に検証するステ
ップと、この場合に前記画像の第２デコーディングを回
避するステップとをさらに含む。

【００１６】本発明の別の目的は、コード化画像を含む
圧縮ビデオ・ストリームのランダム・アクセス・ソース
と、デコードすべき画像を選択するための手段と、デコ
ードされた画像を格納するための複数の再構築バッファ
と、コード化画像をデコードするためのビデオ・デコー
ダと、再構築バッファの書込みアクセスについての可用
性をモニタし、選択された画像を再構築バッファの可用
性に基づいてデコードするように前記ビデオ・デコーダ
を制御するための手段であって、再構築バッファの可用
性が前記再構築バッファ中に含まれる画像の表示のステ
ータスによって決定される手段とを特徴とするビデオ・
デコーディング装置である。

【００１７】ランダム・アクセス・ソースは、順次ソー
スに接続された中間記憶領域とすることもできる。

【００１８】本発明の方法および装置により、３つの再
構築バッファのみを使用して、異なる速度で逆方向での
記録されたビデオ・ストリームのプレイバックが可能と
なる。

【００１９】選択された画像をデコードするために、本
発明の方法は、再帰的なプロセスを使用して、表示すべ
き画像の予測子画像を決定し、デコードする。

【００２０】有利には、記録されたストリームを記述す
る所定のトリックモード情報は、予測子画像を決定する
ために使用される。このトリックモード情報は、トリッ
クモードのタイプおよび記録されたストリーム中での関
連するデータの位置を記述する画像予測子のリンクされ
たリストの形をとることができる。

【００２１】特定のバッファ割り振り機構が、どの画像
に対してどの再構築バッファを使用すべきかを決定する
ために使用される。

【００２２】表示すべき画像を含むバッファへの書込み
アクセスは、この画像が表示されるまで禁止される。

【００２３】本発明の他の特徴および利点は、本発明の
非限定的実施形態の説明を通して明らかとなろう。以下
の図面は、実施形態を示す。

【００２４】

【発明の実施の形態】１．全体的なシステムの概要 図１のデジタル・テレビジョン受信機／デコーダ１は、
チューナおよびアナログ／デジタル・コンバータ（示し
ていない）によって供給される順方向誤り訂正回路２を
備える。訂正デジタル信号は、移送ストリーム・デマル
チプレクサおよびフィルタ４に供給される。このデマル
チプレクサおよびフィルタ４は、受信機１の中央伝送バ
ス１１に接続される。その役割は、入りデータ・ストリ
ーム中のある移送ストリーム（ＴＳ）パケットを選択
し、それらを受信機の異なるアプリケーションに送るこ
とである。その目的で、それは、マイクロプロセッサ１
０によってプログラムされたフィルタを備える。

【００２５】ＭＰＥＧストリームを記録する目的で、受
信機は、例えばＥＩＤＥインターフェースなどのインタ
ーフェース１３を介してバス１１にリンクされたハード
・ディスク・ドライブ１２を備える。メモリ５は、ハー
ド・ディスクに情報を格納し、取り出すために使用され
るいくつかのバッファを備える。

【００２６】メモリ５は、環状バッファ１５〜２３を備
える。書込みＦＩＦＯ１５は、ハード・ディスク１２上
に記録するために、ＴＳパケットをデマルチプレクサお
よびフィルタ４からの到着順に格納するために使用され
る。読込みＦＩＦＯ１６は、ハード・ディスクから読み
込まれたＴＳパケットを格納するために使用される。Ｆ
ＩＦＯ１５およびＦＩＦＯ１６は、ＴＳパケットの内容
の性質を無視して、受け取ったデータ・ストリームのサ
ブストリームを記録または読み込むために使用される。
記録するために、プログラムされた基準に対応するすべ
てのＴＳパケットは、ハード・ディスク１２に転送する
前にフィルタにかけられ、書込みＦＩＦＯ１５に書き込
まれる。このモードは、移送ストリーム・レベル・レコ
ーディング・モードと呼ばれ、この説明の残りの部分で
使用されるモードとなることになる。

【００２７】完全を期して、レコーディングは、パケッ
ト化基本ストリーム（ＰＥＳ）レベルでも達成すること
ができることを述べておく。ＦＩＦＯ１８〜２３は、そ
の目的に使用される。メモリ５は、トリックモード・バ
ッファ１７も保持する。このバッファは、トリックモー
ド情報を生成するためにレコーディング中ストリーム・
パーサ３およびマイクロプロセッサによって使用され、
次いでそのトリックモード情報は、ハード・ディスク上
に記録される。このバッファは、ハード・ディスクから
読み込まれたトリックモード情報を格納するためにも再
生中に使用される。

【００２８】これら２つのモードのさらなる詳細は、既
に述べた欧州特許出願中に見つけることができる。

【００２９】ストリームをデコードする目的で、受信機
１は、移送ストリーム・デマルチプレクサおよびＰＥＳ
パーサ６を介して、または直接にＰＥＳパーサ６を介し
て中央バス１１に接続された各音声およびビデオ・デコ
ーダ８および９も備える。レコーディング・モードに依
存して、ＴＳ層は、前もって削除されている、または削
除されない可能性がある。参照１４は、表示可能なアナ
ログ・ビデオ信号を生成するために必要なビデオ処理回
路を示す。

【００３０】ビデオ・デコーダ９宛ての圧縮データは、
入力ビット・バッファ２５中に格納され、圧縮データ
は、その入力ビット・バッファ２５からデコーダ９によ
って適切に読み取られる。再構築された画像は、再構築
メモリ２６中に格納され、その再構築メモリ２６は、読
込みおよび書込み両方のためにデコーダによってアクセ
スされる。本発明による再構築メモリは、それぞれが１
つのデコードされた画像に対応する３つのバッファ
（Ａ、Ｂ、Ｃ）を有する。

【００３１】受信機１は、受信機のオペレーティング・
システム、デバイス・ドライバおよび他のソフトウェア
・モジュールを保持する、再プログラム可能な不揮発性
メモリ２４も備える。

【００３２】本説明の目的のために、トリックモード情
報は、ディスク上に格納されている各ビデオ・アクセス
・ユニットごとに、レコーディング順に画像のタイプ
（Ｉ、Ｐ、またはＢ）と、関連する画像、画像のグルー
プ、および画像をデコードするために必要なハード・デ
ィスク上のシーケンス情報の位置とを含む。トリックモ
ード情報は、３つの異なるタイプのテーブル中にセグメ
ント化される。それらは、時間索引テーブル、ビデオ・
ユニット記述テーブル、およびある数の連続したグルー
プの画像の内容をそれぞれが記述するいくつかのビデオ
記述ユニット（ＶＤＵ）である。

【００３３】そのようなトリックモード情報の例は、
「Method and device for decoding adigital video st
ream in a digital video system using dummy header
insertion」と題し、ＴＨＯＭＳＯＮ ｍｕｌｔｉｍｅ
ｄｉａの名で２０００年４月５日に出願された欧州特許
出願に記載されている。

【００３４】図２は、本実施形態による受信機１のソフ
トウェア・モデルのダイアグラムである。このダイアグ
ラムは、以下の要素を含む。

【００３５】（ａ）全トリックモード制御 このソフトウェア・モジュールは、デコーディング・プ
ロセスの全制御を請け負う。トリックモード（逆方向／
順方向、低速／高速）に従って、このモジュールは、ど
の画像を送り、デコードし、表示すべきかを指定する。

【００３６】例として、選んだトリックモードが通常ス
ピードのＸ倍の高速逆方向再生である場合、このモジュ
ールは、一時索引テーブルおよびＶＤＵを使用して、ど
の画像を表示すべきかということ、この画像のタイプ
（Ｉ、Ｂ、Ｐ）、およびＰまたはＢタイプ画像の場合に
は事前にデコードする必要のある他の画像（予測子）を
判定する。予測子のデコーディングは、それ自体他の予
測子を必要とする可能性があるため、このプロセスは、
繰り返し実施される。

【００３７】トリックモード情報は、トリックモード情
報アクセス・マネージャ（以下を参照）からの全トリッ
クモード制御によって要求される。

【００３８】繰り返しのデコーディング・アルゴリズム
に基づいて、全トリックモード制御は、ストリーム・ア
クセス・マネージャ（以下を参照）に特定のビデオ・ア
クセス・ユニットをＭＰＥＧビデオ・デコーダの入力バ
ッファに転送するように命令する。

【００３９】全トリックモード制御モジュールは、再生
バッファ占有の仮想イメージをどのステップでも維持す
る。

【００４０】３つの再生バッファのうちの特定の１つの
中の画像をデコードするために、全トリックモード制御
は、図５および６のフローチャートと共に後に説明する
再構築バッファ選択プロセスを実行し、圧縮画像を転送
する前にデコーディング・マネージャに通知する。

【００４１】（ｂ）トリックモード情報アクセス・マネ
ージャ 全トリックモード制御モジュールは、記録されたストリ
ームに関するトリックモード情報を必要とする。この情
報は、ハード・ディスク・ドライブ１２上に格納され
る。トリックモード情報アクセス・マネージャは、ハー
ド・ディスク・ドライブから情報を収集し、それを全ト
リックモード制御に供給することを請け負う。

【００４２】（ｃ）ストリーム・アクセス・マネージャ デコードすべき各単一画像は（次々に表示すべきである
かどうかにかかわらず）、ビデオ・デコーダ９に送らな
ければならない。圧縮された内容にアクセスするための
すべての必要な情報は、トリックモード情報テーブル中
に供給される。ストリーム・アクセス・マネージャは、
全トリックモード制御によって識別された画像データを
メモリ５からビデオ・デコーダに転送し、ストリーミン
グ・ドライバによってハード・ディスクから読み取られ
た情報の中から関連する情報だけを転送することを請け
負う。デコードすべき各画像について、ストリーム・ア
クセス・マネージャは、全トリックモード制御から通知
を受けることになる。

【００４３】（ｄ）ストリーミング・ドライバ ストリーミング・ドライバは、ストリーム・アクセス・
マネージャによる処理のためにメモリ５に送達すべきビ
デオ内容を選び出すことを請け負う。一般に、ストリー
ミング・ドライバは、関連するデータおよび他のデータ
を含むハード・ディスク・ドライブから、１つまたは複
数のブロックをロードすることになる。トリックモード
情報がストリームと共に挿入される場合、ストリーミン
グ・ドライバは、トリックモード情報を抽出し、それを
バッファ１７中に格納することも請け負う。

【００４４】（ｅ）ビデオ・デコーディング・マネージ
ャ ビデオ・デコーダは、新しいビデオ・アクセス・ユニッ
トを受け取り、識別したとき、ビデオ・デコーディング
・マネージャに通知する。ビデオ・デコーディング・マ
ネージャは、キューを介して全制御からこの特定の画像
のデコーディングおよび／または表示を命令および指定
する完全なコマンドを先に受け取っている。このコマン
ドに基づいて、ビデオ・デコーディング・マネージャ
は、新しく検出された画像のデコーディングをプログラ
ムし、かつその画像を表示しなければならない場合、こ
の画像は表示すべきものであり、どのように表示しなけ
ればならないか（トップまたはボトム・フィールドを最
初にするか、順方向または逆方向か）をキューを介して
ディスプレイ・マネージャに通知する。

【００４５】各再構築バッファのソフトウェア記述子
は、各バッファの状態を反映する。これらの記述子は、
ビデオ・デコーディング・マネージャおよびディスプレ
イ・マネージャによって共有される。デコーディングを
プログラムする前に、ビデオ・デコーディング・マネー
ジャは、この画像を受け取らなければならない再構築バ
ッファが利用可能かどうかをテストする。利用可能でな
い場合、ビデオ・デコーディング・マネージャは、ディ
スプレイ・マネージャがそのバッファを開放するのを待
つ。次いで、このバッファ中のデコーディングをプログ
ラムすることができ、バッファ・アクセスを再びロック
することができる。

【００４６】（ｆ）ディスプレイ・マネージャ 表示すべき画像がデコードされた場合、ディスプレイ・
マネージャは、ビデオ・デコーディング・マネージャか
ら通知を受ける。ロックされた再構築バッファがもはや
表示用に必要でなくなると、ディスプレイ・マネージャ
は、ロックされた再構築バッファをロック解除し、それ
らを別の画像のデコーディング用に解放する。

【００４７】ビデオ・デコーダ９は、デコーディングお
よび結果として得られる個々の画像の表示に関するある
タイプの制御および操作を可能とするＡＰＩ（アプリケ
ーション・プログラム可能インターフェース）を提供す
ることができる。具体的には、個々の画像をデコード
し、続いてそれを所与の時間およびあるフレーム間隔の
間表示する、または全く表示しないようにデコーダに命
令することができる。

【００４８】画像表示は、同期的プロセスである。５０
Ｈｚのシステムに対しては、ディスプレイ・マネージャ
は、４０ｍｓごとにどの画像を表示すべきかをチェック
する。言い換えれば、ディスプレイ・マネージャは、表
示すべき画像を含む再構築バッファを識別する。

【００４９】ビデオ・デコーディング・マネージャによ
って満たされたディスプレイ・マネージャの通知キュー
が空の場合、表示用に利用可能な画像は存在しない。新
しい画像を表示すべき時まで、表示された最後の画像が
次いで繰り返されることになる。

【００５０】一般に、表示プロセスは、この連鎖中で最
も低速なプロセスである。すべての他のプロセスは、表
示によって課されたリズムに追従することになる。

【００５１】デコーディング・プロセスが非同期的で、
非常に高速にすることができるため、表示すべき画像が
デコードされたとき、その再構築バッファは、その画像
が実際に表示される前は後続の画像によるどんな上書き
も避けるためにロックされる。ディスプレイ・マネージ
ャだけが、画像が表示されたときおよび新しい画像の再
構築が同じバッファ中で開始されたときにロック解除を
することが可能である。ビデオ・デコーディング・マネ
ージャは、全トリックモード制御によって要求されたと
きに新しい画像をデコードするために、ディスプレイ・
マネージャが画像を表示し、バッファを開放するのを待
つ。

【００５２】全トリックモード制御によるデコーディン
グ要求の生成およびストリーム・アクセス・マネージャ
によるデコーダの送りも、一般にデコーディング・プロ
セスより高速である。

【００５３】ビデオ・デコーダのビットバッファが一杯
であり、さらに多くの圧縮データを送ることができない
場合、新しい画像のデコーディングを依頼することはで
きないので、全トリックモード制御と、ストリーム・ア
クセス・マネージャによるコードされた画像供給とが同
期される。全トリックモード制御は、必要なときに新し
い画像の送信を要求し、別の要求を発行する前に完了す
べき送信を待つ。送信の完了はストリーム・アクセス・
マネージャによって全トリックモード制御プロセスに通
知される。

【００５４】ストリーム・アクセス・マネージャおよび
全制御は、ビデオ・デコーダがビット・バッファからデ
ータを取り出すのを待ち、ビデオ・デコーダは、ビデオ
・デコーディング・マネージャの制御の下で、ディスプ
レイ・マネージャがバッファを開放するのを待つ。全体
のシステムは、最終的に表示のリズムに追従することに
なる。

【００５５】ディスプレイ上に表示するために、ＭＰＥ
Ｇ画像は、事前にデコードされていなければならない。
ビデオ・プロセスは、一連の連続した操作に分割するこ
とができる。図３は、所与の画像に対する全体的なビデ
オ・プロセスの概観である。いくつかのそのようなプロ
セスは、実行の異なる段階で並列に実行することができ
る。第１操作は、表示すべき次の画像を識別することに
ある。これは、もちろんトリックモードのタイプに依存
する。この画像が決定されると、それをデコードしなけ
ればならない。この操作は、他の画像の再帰的なデコー
ディングを含むことができる。この操作は、１つまたは
複数の自由再構築バッファの可用性にも依存する。最後
の操作は、デコードされた画像を表示することにある。

【００５６】本実施形態によるトリックモード情報は、
リンクされたアイテムを含むデータ構造である。それ
は、互いにそのストリーム中での順番に従ってリンクさ
れた画像記述子で作成される。受信されたとき（および
この場合は記録されたとき）のストリームは、画像を表
示順ではなく、デコーディング順で含むことを想起され
たい。各画像記述子は、ＭＰＥＧコード化ストリーム中
の画像についての詳細ならびに画像の圧縮材料を記憶ユ
ニット上に位置付けるための十分な情報を与える。スト
リーム中の各画像は、特定の画像ＩＤで識別される。図
３および４では、「Ｎ」がそのような画像ＩＤであり、
関数「Ｎｅｘｔ（Ｎ）」は、画像ＩＤを返す。Ｎｅｘｔ
（Ｎ）関数のプロセッシングは、表示すべきトリックモ
ードのタイプが与えられているとして、トリックモード
情報の解析に基づく。

【００５７】順方向モードでは、Ｎｅｘｔ（Ｎ）は、通
常の表示順（すなわち、一時参照に関して）に従って表
示すべき次の画像のＩＤを返す。逆方向モードでは、Ｎ
ｅｘｔ（Ｎ）は、通常の表示順に従って前の画像のＩＤ
を返す。

【００５８】高速操作（順方向または逆方向）について
は、画像をスキップしなければならず、したがってＮｅ
ｘｔ（Ｎ）は、非連続な画像のＩＤを返す。

【００５９】Ｎｅｘｔ（Ｎ）関数は、Ｎを知って、画像
をデコードするために必要なすべてのデータにアクセス
するために既に述べた特許出願中で定義されるトリック
モード・テーブルを使用する全トリックモード制御モジ
ュールによって実現される。

【００６０】低速動作トリックモード（順方向または逆
方向）は、ディスプレイ・マネージャの制御下にある。
このトリックモードが単に１画像あたり４０ｍｓより低
速の表示レートを暗黙指定するからである。

【００６１】図４は、ＤｅｃｏｄｅＰｉｃｔｕｒｅコマ
ンドの原理を示す。再構築バッファの現状態が、図の左
側に表されている。バッファはそれぞれ、ある画像
（Ｘ、Ｙ、Ｚ）を含む。ＤｅｃｏｄｅＰｉｃｔｕｒｅプ
ロセスは、画像Ｎに適用された場合、他の２つのバッフ
ァの内容が何であっても、バッファのうちの１つが最後
にはこの要求された画像を含むことになることを保証す
る。

【００６２】既に述べた通り、ＭＰＥＧ画像は、他の画
像に依存する可能性があり、そのデコーディングは、既
に再構築した画像の可用性を必要とすることがある。Ｍ
ＰＥＧコード化ストリームは、イントラ画像の形式の下
で常に多数の入口点を含む。そのような入口点に追従す
る画像は、入口点に先行する画像に依存しない。ＤＶＢ
標準は、これらの入口点が少なくとも０．５ｓごとに生
じるように指定する。画像の開グループは、特定のケー
スである。

【００６３】ＤｅｃｏｄｅＰｉｃｔｕｒｅコマンドは、
図５のフローチャートで示されるように繰り返し実施さ
れる。画像のデコーディングが、以前にデコードした１
つまたは２つの画像の存在を必要とする場合、これらの
後者の画像がまずデコードされる。

【００６４】ターゲット画像（ＰｉｃＩＤ）がまだ再構
築バッファ中に存在しない場合、ターゲット画像をデコ
ードする必要がある。ＰｉｃＩＤで識別される画像が
「Ｐ」または「Ｂ」タイプの場合、そのデコーディング
は、順方向および逆方向予測子の存在を必要とする可能
性がある。この情報は、トリックモード・テーブル中で
利用可能である。

【００６５】エンコードすべき画像が依存する予測子を
与える規則は、単純である。ストリームを逆方向に（す
なわち、以前に記録したビデオ・アクセス・ユニットに
向かって）通って、最初に遭遇する「Ｐ」タイプまたは
「Ｉ」タイプの画像が現画像に対する予測子である。こ
の画像は、トリックモード情報を使用して見つけること
ができる。この予測子を図５で「最近隣ＩＤ」と呼ぶ。

【００６６】ＰｉｃＩＤで識別される画像が「Ｐ」タイ
プ画像である場合、最近隣ＩＤは、ＰｉｃＩＤで識別さ
れる画像よりも時間スケールおよび表示順において前に
位置付けられる、という意味で順方向予測子である。

【００６７】ＰｉｃＩＤで識別される画像が「Ｂ」タイ
プ画像である場合、最近隣ＩＤは、逆方向予測子であ
る。次いで順方向予測子は、次の「Ｉ」または「Ｐ」タ
イプ画像をさらに逆方向に探すことによって見つかる。
この順方向予測子を図５で「最遠方ＩＤ」と呼ぶ。

【００６８】画像をデコードするためには、再構築され
た予測子が再構築バッファ中に存在しない場合、再構築
された予測子を構築しなければならない。この場合で
は、ＤｅｃｏｄｅＰｉｃｔｕｒｅコマンドが、これらの
画像に対して再帰的に繰り返される。

【００６９】Ｂ画像の再構築に先立って、既にデコード
され再構築バッファ中に存在しない限り、２つの予測子
をデコードしなければならない可能性がある。図５から
わかる通り、最遠方ＩＤがまずデコードされ、最近隣Ｉ
Ｄがそれに続く。最近隣ＩＤも最遠方ＩＤに依存する可
能性があるので、後者がまずデコードされる。したがっ
てプロセスは最適化され、最遠方ＩＤに対応する画像の
二重デコーディングは回避される。例えば、Ｂ画像が２
つのＰ画像から予測される場合、時間においての第２Ｐ
画像は、第１Ｐ画像に依存する。

【００７０】最遠方ＩＤが再構築バッファ中に構築され
ると、バッファは、最近隣ＩＤの再構築プロセスが一時
的結果として保たれる最遠方ＩＤを上書きするのを防ぐ
ためにロックされる。

【００７１】どのプレイバック・モードであっても、次
に説明するように、３つの再構築バッファのみが使用さ
れる。

【００７２】イントラ画像のデコーディングは、予測子
を必要としないので、１つの自由バッファのみを必要と
する。予測画像のデコーディングは、１つの予測子を必
要とする。予測画像のデコードされた予測子が既に別の
バッファ中に存在するかどうか、すなわち再帰的デコー
ディングを実施すべきかどうかに依存して、１つまたは
２つのバッファを使用しなければならない可能性があ
る。

【００７３】３つのバッファのうち、１つは現在表示さ
れている画像を含む。したがって２つのバッファが、別
の画像をデコードするために利用可能であり−それらが
現画像の後に表示すべき画像を含まないと仮定して−、
したがってどんなＩまたはＰ画像も現画像の表示を妨げ
ることなくエンコードすることができる。

【００７４】一方Ｂ画像は２つの予測子を必要とする。
画像の閉グループでは、２つの予測子の一方（「最近隣
予測子」）が他方（「最遠方予測子」）に依存する。最
遠方予測子をまずデコードし、最近隣予測子がそれに続
くことによって、両方の予測子をデコードするために２
つのバッファだけしか必要ではない。画像の開グループ
では、両方の予測子を独立にすることができるが、これ
らの予測子は、画像の現グループからのＩ画像および画
像の先行するグループのＰ（またはＩ）画像を含むの
で、画像の前のグループのＰまたはＩ画像をまずデコー
ドする限りは、２つのバッファだけしか必要ではない。

【００７５】現在表示されている画像が表示すべき次の
画像についての予測子のうちの１つではないとき、この
次の画像がＢタイプであると仮定して、現在表示されて
いる画像を含むバッファ中にそれを再構築しなければな
らない。現在利用可能なデコーダでは、表示される画像
がすべて表示される前に、表示される画像の上書きを開
始することがしばしば可能である。上書きは、例えば表
示の開始の２０ｍｓ後に開始することができる。画像が
いくつかのフレーム期間に渡って表示される場合、上書
きは、当然最後のフレーム期間の間に行われる。

【００７６】したがって、デコーディング順序が適切に
選ばれたとき、３つの再構築バッファだけしか必要でな
いことは明らかである。

【００７７】すべての必要な予測子がデコードされたと
き、デコードし表示すべき新しい画像を受け取るため
に、利用可能な再構築バッファを選ばなければならな
い。一部の場合では、Ｂ画像をデコードする場合など選
択が存在しない可能性がある。３つのすべてのバッファ
を使用する必要がある。つまり、順方向予測子用の１
つ、逆方向予測子の１つ、Ｂ画像自体のための１つであ
る。

【００７８】他の場合では、２つまたは３つのうちから
バッファを選ばなければならない。

【００７９】表示とデコーディングとの間での３つの再
構築バッファの割り振りは、全体のシステムの性能のた
めに重要である。実際、適切なバッファを選ばなかった
ときは、所与の画像をデコードするために追加の遅延が
導入される可能性がある。ビデオ・デコーダの処理能力
に依存して、次いで画像を表示すべき前に画像が完全に
デコードされないことが生じる可能性がある。

【００８０】デコーディング遅延を回避するために、表
示すべき画像に対して選ぶべきバッファが最も過去に表
示プロセスによって解放された自由バッファであるよう
に発明者は決定した。

【００８１】この割り振り方法を実施するために、カウ
ンタが各バッファ・モデル要素に関連付けられる。表示
すべき画像がバッファ中で再構築されるとき、このバッ
ファのカウンタはリセットされ、他のバッファのカウン
タが増分される。本一実施形態によれば、新しい画像に
割り振られたバッファは、最高のカウンタ値を有するバ
ッファである。

【００８２】図６は、バッファ割り振りプロセスのフロ
ーチャートである。図６は、すべてのバッファを通って
循環し、予測子を含むためにロックされたものを廃棄
し、未ロックのものがあればそれらの中から最大のカウ
ンタ値を有するものを選ぶことから成る。

【００８３】前で説明した通り、画像の再順序付けおよ
びバッファ割り振り問題は、３つの各再構築バッファに
関する以下のデータ構造のような仮想モデルを使用する
ことで解決される。 typedef u_int8 PicID_t; typedef struct{ PicID_t picID_t;＜格納された画像のＰｉｃＩＤを定義する＞ Boolean isFree_b;＜自由／ロック化・ステータスを定義する＞ U_int8 displayCounter_ui8;＜バッファが表示された画像から自由になって いた時間のカウンタ＞ }Buffer_t; Buffer_t DecoderState_t[BUFFER_COUNT];

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

【００８５】各画像の予測子は、表１に示されている。

【表１】

【００８６】図７は、各バッファＡ、Ｂ、およびＣの内
容を示す。「フレーム期間」列は、４０ｍｓ表示期間を
カウントする（図での厚さに関わらず）。期間「０」
は、Ｐ１１の表示期間に対応する。「表示画像」列は、
関連するフレーム期間中にどの画像が表示されるかを示
す。「フレーム期間ごとのデコーディング」は、所与の
４０ｍｓ期間中にデコードされる画像の数を示す。灰色
の領域は、所与のバッファの内容が表示される時を示
す。

【００８７】話を簡単にするために、フレーム期間、デ
コーディング期間、およびバッファ占有期間を並べる。
これは実際にはそうする必要はない。第１に、画像をデ
コードするために必要な時間は、画像に依存する。第２
に、画像が完全にデコードされる前に画像の表示を開始
することができる。例えば、画像Ｂ”１をデコードする
と同時に表示するよう指示された場合、これは、画像の
デコーディングの２０ｍｓ後よりも早く表示を開始する
ことを意味する。

【００８８】画像Ｐ１１〜Ｂ０をこの順序で表示すべき
であることを考えてみる。

【００８９】図７は、前述の再帰的プロセスによって決
定された、全ての画像（表示すべきかどうかに関わら
ず）をデコードする順番でリストする。

【００９０】Ｐ１１は、Ｐ８に依存し、同様にＰ５に依
存し、同様にＩ２に依存する。したがって、Ｉ２は、バ
ッファＡ中で期間−４の間にデコードされ、Ｐ５は期間
−３の間に、Ｐ８も期間−３の間にデコードされる。期
間−４の間に、画像Ｂ”３が表示される。一方期間−３
の間に、画像Ｉ”２が表示される。理解できる通り、期
間−３の間に、３つの画像をデコードする必要がある。
必要な４番目の画像Ｉ２は、バッファＡが利用可能なの
で、その前の期間中にデコードされる。その同じ期間の
間に、バッファＢおよびＣは利用可能ではない。バッフ
ァＢが表示された画像Ｂ”３を含み、バッファＣが表示
すべき次の画像Ｉ”２を含むためにロックされるからで
ある。理解できる通り、画像のデコーディングは、ロッ
クされていないバッファの可用性によって制限され、画
像は、できるだけ早く必要とされる順序でデコードされ
る。

【００９１】この例では画像の開グループを使用してい
るので、Ｐ１１は、この時点では表示のためにデコード
されていないが、画像Ｂ”１およびＢ”０に対する予測
子としての役目を果たすためにデコードされる。これら
の２つの画像の他の予測子は、Ｉ”２であり、この時点
で既にバッファＣ中に存在する。したがってＢ”１およ
びＢ”０は、即時に（すなわちデコーディングが開始し
た２０ｍｓ後）デコードし、表示することができる。

【００９２】Ｐ１１を次いで表示しなければならない。
Ｐ１１は既にバッファＢ中に存在しているので、この画
像に対して新しいデコーディングを実施する必要がな
く、Ｐ１１は、即時に表示される。

【００９３】期間−１の終わりで、Ｂ”０がデコードさ
れ、バッファＢおよびＣ中に格納されているＢ”０の予
測子が無用となるため、バッファＣは利用可能となる。
したがって、Ｉ２、Ｐ５、Ｐ８、およびＰ１１に依存す
るＢ１０のデコーディングに向けての第１ステップとし
て、Ｉ２がデコードされる。他の画像のデコーディング
は、同様のパターンに従う。

【図面の簡単な説明】

【図１】デジタル・テレビジョン・受信機／デコーダの
ブロック・ダイアグラムである。

【図２】トリックモード・システムの動作に対応する、
図１の受信機のソフトウェアの部分のソフトウェア・モ
デルの図である。

【図３】全ビデオ・デコーディングおよび表示プロセス
のフローチャートである。

【図４】「ｄｅｃｏｄｅ ｐｉｃｔｕｒｅ」コマンドの
効果の図である。

【図５】画像のタイプ（Ｉ、Ｐ、またはＢ）に依存した
画像のデコーディング・プロセスを説明するフローチャ
ートである。

【図６】本実施形態による空バッファ選択プロセスのフ
ローチャートである。

【図７】逆プレイバックの例に対するバッファ占有とデ
コーダおよび表示活動とを示すテーブルである。

【符号の説明】

１ デジタル・テレビジョン受信機／デコーダ ２ 順方向誤り訂正回路 ３ ストリーム・パーサ ４ 移送ストリーム・デマルチプレクサおよびフィルタ ５ メモリ ６ ＰＥＳパーサ ７ 移送ストリーム・デマルチプレクサ ８ 音声デコーダ ９ ビデオ・デコーダ １０ マイクロプロセッサ １１ 中央バス １２ ハード・ディスク・ドライブ １３ インターフェース １４ ビデオ処理回路 １５〜２３ 環状バッファ ２４ 不揮発性メモリ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 アラン ヴェルディエ フランス国， 35770 ヴェルン スュー ル セーシュ， アレ ジャク カルティ エ， ６番地 Ｆターム(参考） 5C053 FA23 GB08 GB37 HA25 JA21 KA01 KA04 KA05 KA24 5C059 KK33 MA00 MA01 MA14 PP05 PP06 PP07 RC11 RC26 SS16 SS17 SS18 UA05 UA38 5D044 AB07 BC01 CC05 FG10 FG23 FG24 GK02 GK08

Claims (10)

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