(57)【要約】【課題】空のフレームバッファと有効データの格納バッファとがランダムな順序で並んでいても、次のデータ格納バッファ、あるいは次のデータ再生バッファを高速に検索可能とする。【解決手段】管理プログラムは、複数のフレームバッファのうちで有効なデータが格納されているフレームバッファの接続を示す有効チェーンのデータと、空のフレームバッファの接続を示す空きチェーンのデータとを格納すべき領域をメモリ上に準備する手順と、有効データがフレームバッファのいずれかに格納されたとき、有効チェーン、空きチェーンのデータを作成／更新してメモリに格納する手順とを計算機に実行させる。【選択図】図１
2007122502.tif 000002
【特許請求の範囲】
【請求項１】
複数のフレームバッファを管理する計算機によって使用されるプログラムであって、
該複数のフレームバッファのうちで有効な画像データが格納されているフレームバッファの接続を示す有効チェーンのデータと、有効な画像データが格納されていないフレームバッファの接続を示す空きチェーンのデータとを格納すべき領域をメモリ上に準備する手順と、
有効な画像データが該複数のフレームバッファのいずれかに格納された時、前記有効チェーン、空きチェーンのデータを作成／更新して、前記メモリに格納する手順とを計算機に実行させることを特徴とするフレームバッファ管理プログラム。
【請求項２】
前記画像データが動画像データであることを特徴とする請求項１記載のフレームバッファ管理プログラム。
【請求項３】
前記複数のフレームバッファのいずれかに格納されている画像データが不要になった時、該画像データを格納するフレームバッファを開放する手順と、
前記有効チェーン、空きチェーンのデータを更新して前記メモリに格納する手順とをさらに計算機に実行させることを特徴とする請求項１記載のフレームバッファ管理プログラム。
【請求項４】
前記画像データが動画像データであるとともに、
前記複数のフレームバッファのほとんどすべてに有効な画像データが格納された時、該複数のフレームバッファのうちで最も古い画像データが格納されているフレームバッファ内のデータを不要として、前記フレームバッファ開放手順を実行させることを特徴とする請求項３記載のフレームバッファ管理プログラム。
【請求項５】
前記プログラムが、圧縮符号化された動画像データの復号によって得られる再生画像データを格納するフレームバッファの管理に用いられることを特徴とする請求項１記載のフレームバッファ管理プログラム。
【請求項６】
前記メモリ上の有効チェーンのデータと空きチェーンのデータとを格納すべき領域が、前記複数のフレームバッファに１対１に対応するブロックのうちで、有効チェーンの先頭を示すブロックの番号と、空きチェーンの先頭を示すブロックの番号とを格納するチェーン先頭ブロック番号格納領域を備えることを特徴とする請求項１記載のフレームバッファ管理プログラム。
【請求項７】
前記メモリ上の有効チェーンのデータと空きチェーンのデータを格納すべき領域が、前記ブロックのそれぞれに対応するフレームバッファに有効なデータが格納されているか否かを示すデータと、前記有効チェーン、または空きチェーン上で前後に接続されるブロックの番号とを格納するブロック個別データ格納領域をさらに備えることを特徴とする請求項６記載のフレームバッファ管理プログラム。
【請求項８】
前記有効チェーンが、前記チェーン先頭ブロック番号格納領域内の有効チェーン先頭ブロック番号を始点として、前記ブロック個別データ格納領域に格納されているブロックデータのうちで、対応するフレームバッファに有効なデータが格納されているブロックのブロック番号をたどることによって、
前記空きチェーンが、前記チェーン先頭ブロック番号格納領域内の空きチェーン先頭ブロック番号を始点として、前記ブロック個別データ格納領域に記憶されているブロックデータのうちで、対応するフレームバッファに有効なデータが格納されていないブロックのブロック番号をたどることによって構成されることを特徴とする請求項７記載のフレームバッファ管理プログラム。
【請求項９】
複数のフレームバッファを管理する計算機によって使用される記憶媒体であって、
該複数のフレームバッファのうちで有効な画像データが格納されているフレームバッファの接続を示す有効チェーンのデータと、有効な画像データが格納されていないフレームバッファの接続を示す空きチェーンのデータとを格納すべき領域をメモリ上に準備するステップと、
有効な画像データが該複数のフレームバッファのいずれかに格納された時、前記有効チェーン、空きチェーンのデータを作成／更新して、前記メモリに格納するステップとを計算機に実行させるプログラムを格納した計算機読出し可能可搬型記憶媒体。
【請求項１０】
複数のフレームバッファを管理する方法であって、
該複数のフレームバッファのうちで有効な画像データが格納されているフレームバッファの接続を示す有効チェーンのデータと、有効な画像データが格納されていないフレームバッファの接続を示す空きチェーンのデータとを格納すべき領域をメモリ上に準備し、
有効な画像データが該複数のフレームバッファのいずれかに格納された時、前記有効チェーン、空きチェーンのデータを作成／更新して、前記メモリに格納することを特徴とするフレームバッファ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動画像データを格納する複数のフレームバッファの管理方式に係り、さらに詳しくは、例えばＭＰＥＧなどの各種の規格に従って圧縮符号化された動画像データの復号システムにおいて、復号処理によって得られた再生画像データを格納する複数のフレームバッファの管理方式に関する。
【背景技術】
【０００２】
動画像圧縮符号化に関する標準規格として、ＩＳＤＮ動画像転送に対応するＨ．２６１、放送メディア動画像に対応するＨ．２６２、既存の電話網テレビ電話に対応するＨ．２６３、蓄積メディア動画像に対応するＭＰＧＥ−１、Ｈ．２６２と同一の規格としてのＭＰＥＧ−２、およびコンピュータ・通信・放送・家電などのマルチメディアに対応するＭＰＥＧ−４などの各種の規格が用いられ、このような規格に基づいて符号化されたストリームデータを復号するシステムにおいては、復号処理によって得られる再生画像データを格納するための多数のフレームバッファを備え、各フレームの画像データをフレームバッファに格納した後に、例えばディスプレイ画面に表示する動作が行われる。
【０００３】
しかしながら一般に動画像データのデータ量は膨大であり、それを格納すべきフレームバッファの数には限りがあることから、フレームバッファの空き状態を適正に管理して画像データの格納を行わなければならないという問題点があった。従来では、例えばフレームバッファに対してそのフレームバッファにデータが格納されているか否かを示すフラグを設け、フレームバッファを全検索して、空いているフレームバッファにデータを格納する動作が行われていたが、フレームバッファの数が多く、かつ空のフレームバッファが検索の最後の付近にある場合には、検索に要する時間が長くなるという問題点があった。
【０００４】
このようにフレームバッファなどのメモリの記憶領域管理方式の従来技術としての特許文献１には、たとえばフレームメモリの作業領域の管理において、メモリ上に要求を満足できるスペースが十分にあっても、要求の形状によっては、領域を割当不可能な場合が生じ、作業領域の利用効率が悪くなるという問題点を解決できる技術が開示されている。
【０００５】
また特許文献２には、矩形単位にメモリ領域を管理する方式において、隣接領域に対応したメモリ管理テーブルに対して左接続ポインタと上接続ポインタとを備え、ユーザに任意の大きさの領域を利用可能とする技術が開示されている。
【特許文献１】特開平３−４４７４７号公報「メモリ管理処理方式」
【特許文献２】特開平３−１５４９７３号公報「メモリ管理方式」
【０００６】
しかしながらこのような従来技術によっても、有効なデータが格納されているフレームバッファと、空のフレームバッファとがランダムに並んでいるような場合に、次にデータ格納、またはデータ再生の対象となるフレームバッファの検索を速くすることはできなかった。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明の課題は、上述の問題点に鑑み、有効データが格納されていない空のフレームバッファと、有効データが格納されている使用中フレームバッファがランダムに虫くい状態で並んでいる場合にも、次のデータを格納すべきフレームバッファ、あるいは次の再生画像を読み出すべきフレームバッファを高速に検索することを可能とするフレームバッファ管理プログラム、および管理方法を提供することである。
【課題を解決するための手段】
【０００８】
図１は、本発明のフレームバッファ管理プログラムの原理的な機能ブロック図である。同図は複数のフレームバッファを管理する計算機によって使用されるプログラムの原理的な機能ブロック図である。
【０００９】
図１において、本発明のプログラムは、まずステップＳ１で、複数のフレームバッファのうちで有効な画像データが格納されているフレームバッファの接続を示す有効チェーンのデータと、有効な画像データが格納されていないフレームバッファの接続を示す空きチェーンのデータとを格納すべき領域をメモリ上に準備する手順を、ステップＳ２で有効な画像データが複数のフレームバッファのいずれかに格納された時、有効チェーンと空きチェーンのデータを作成／更新してメモリに格納する手順を計算機に実行させるものである。
【００１０】
発明の実施の形態においては、複数のフレームバッファのいずれかに格納されている画像データが不要になった時、そのデータを格納しているフレームバッファを開放する手順と、前述の有効チェーン、空きチェーンのデータを更新してメモリに格納する手順とをさらに計算機に実行させることもできる。
【００１１】
また本発明においては、このフレームバッファ管理プログラムが格納された計算機読出し可能可搬型記憶媒体を用いることもでき、さらに本発明のフレームバッファ管理プログラムに対応して、有効チェーンのデータと空きチェーンのデータを格納すべき領域をメモリ上に準備し、有効な画像データが格納された時に有効チェーン、空きチェーンのデータを作成／更新してメモリに格納するフレームバッファ管理方法を用いることもできる。
【発明の効果】
【００１２】
本発明によれば、空のフレームバッファと有効データの格納されているフレームバッファが虫くい状態でランダムに並んでいても、次にデータを格納すべきフレームバッファを高速に検索、あるいは早送り再生や巻き戻し再生において、次に再生すべき画像データを高速に取得することが可能となり、動画像復号システムにおけるフレームバッファの管理を容易にし、制御を高速化することが可能となる。
【発明を実施するための最良の形態】
【００１３】
図２は、本発明のフレームバッファ管理方式が使用される動画像再生システムの構成例である。このシステムは、ＤＶＤ１０に記録されているＭＰＥＧビットストリームを映像、および音声の出力機器に出力するものである。
【００１４】
図２においてＤＶＤ１０に記録されているＭＰＥＧのビットストリームデータは、ユーザインターフェース部１１を介してビデオ・オーディオ分離部１２に入力され、分離されたオーディオデータはオーディオデコーダ１３、ビデオデータはビデオデコーダ１４に与えられ、これらのデコーダによる復号結果はＯＳ／ドライバ部１５を介してスピーカー１６、およびＴＶ１７によって再生される。
【００１５】
本発明のフレームバッファ管理方式は、ビデオデコーダ１４によって復号された動画像データの管理方式に関するものであり、ビデオデコーダの内部構成を図３を用いて説明する。図３においてビットストリーム２０のデータはＶＬＤ２１によって可変長復号され、ＩＱ２２によって逆量子化され、ＩＤＣＴ２３によって逆離散コサイン変換され、加算器２４に与えられる。一方、ＶＬＤ２１の出力に対してはＭＣ２５によって動き補償が行われ、その補償結果は加算器２４によってＩＤＣＴ２３の出力と加算され、動画像データ２６として出力される。
【００１６】
図４は、図２のシステムにおけるビデオデータ再生処理の全体フローチャートである。同図においては再生ボタンが押し下げられ、ビデオデータの再生が行われている途中で、巻き戻しボタンが押し下げられる可能性がある場合の処理について説明するものとする。
【００１７】
まずステップＳ１０で再生ボタンが押し下げられたと判定されると、ステップＳ１１でＤＶＤ１０からビットストリームデータが読み込まれ、ステップＳ１２でビデオ・オーディオ分離部１２によってビデオデータとオーディオデータが分離され、ステップＳ１３でビデオデコーダ１４によってビデオデータが復号されて、ステップＳ１４で復号結果としての動画像データがフレームバッファに登録（格納）されて、ステップＳ１５で復号結果がＴＶ１７に出力される。なおステップＳ１４における復号結果のフレームバッファへの格納に伴う有効チェーンへの登録処理、すなわち、図１のステップＳ２の処理の詳細については後述する。さらに図１のステップＳ１の処理は、図４の処理に先立ってシステムの初期化処理として実行されているものとする。
【００１８】
次にステップＳ１６でバッファがニアフルであるか否か、すなわち複数のフレームバッファのうちのほとんどに復号結果としての動画像データが格納されたか否かが判定され、バッファニアフルである場合にはステップＳ１７で古い復号結果（動画像データ）がフレームバッファから削除された後に、ニアフルでない場合には直ちにステップＳ１８の処理に移行する。ここで復号結果としての動画像データは古いものから削除されているが、後述する巻き戻し中には新しい順に削除が行われるものとする。
【００１９】
ステップＳ１８で巻き戻しボタンが押し下げられたか否かが判定され、押し下げられていない場合にはステップＳ１１以降の処理が続けられ、データ再生が続行される。これに対して巻き戻しボタンが押し下げられたと判定された場合には、ステップＳ１９で未来に再生すべき復号結果としての動画像データがフレームバッファから削除される。
【００２０】
すなわち一般的に、再生中には復号結果の出力に先立ってビットストリームの先読みが行われ、先読みされたデータは復号されてあらかじめフレームバッファに格納されるが、巻き戻しボタンが押し下げられた場合には、そのようなデータは不要なものとしてバッファから削除される。ステップＳ１７におけるデータの削除を含めて、フレームバッファからのデータ削除時における有効チェーンなどの更新処理についても後述する。
【００２１】
ステップＳ１９で未来の復号結果が削除された後に、ステップＳ２０でフレームバッファの内部に表示可能なフレーム、すなわち有効データがあるか否かが判定され、ある場合にはステップＳ１５以降の処理が繰り返される。そのような有効データがない場合にはステップＳ１１以降の処理が繰り返される。これは、巻き戻しボタンが押し下げられている間に有効なデータがなくなった場合にデータの表示を続けるために、ステップＳ１１以降の処理を繰り返すものである。
【００２２】
続いて本実施形態におけるフレームバッファ管理方式について、図５から図１０を用いてその基本動作を説明する。ここではフレームバッファが１からｍまでのｍ個存在するものとして、フレームバッファの管理方式を説明する。
【００２３】
まず図５は初期状態を示す。この初期状態ではｍ個のフレームバッファは、すべて空、すなわち未使用の状態であり、これらのフレームバッファは復号結果が格納されていないフレームバッファに対するデータ格納順序を示す空きチェーンで接続される状態となっている。この空きチェーンは点線で示されており、例えばフレームバッファ１の次を示す変数Ｎ２はフレームバッファ２を指し、フレームバッファ２の次を指す変数Ｎ３はフレームバッファ３を示している。
【００２４】
図６は図５の状態においてフレームバッファ１に復号データが格納された状態を示している。この状態では点線で示される空きチェーンはフレームバッファ２からｍまでを接続するものとなっており、これに対して復号結果が格納されているフレームバッファに対する有効チェーンは、実線で示されるようにフレームバッファ１だけが接続された状態であり、フレームバッファ１の次のバッファを示す変数Ｎ１は自分自身のフレームバッファを指している。
【００２５】
図７は次にフレームバッファ２にデータが格納された状態を示し、フレームバッファ１と２が有効チェーンで接続され、フレームバッファ３からｍが空きチェーンによって接続されている。
【００２６】
図８はフレームバッファ１から３、図９は１から４に復号データが格納された状態を示し、それぞれ有効チェーン、および空きチェーンの接続が変更されている。
図１０は図９の状態からフレームバッファ３に格納された復号データが削除され、フレームバッファ３が開放された状態を示している。このため有効チェーンはフレームバッファ１、２、および４を接続する状態となっており、空きチェーンはフレームバッファ５からｍ、および３を接続する状態となっている。この時、空きチェーンの先頭としてのフレームバッファは、図５の初期状態における本来の復号データ格納順序においてフレームバッファ４の次にデータが格納されるべきフレームバッファ５であり、開放されたフレームバッファ３は空きチェーンの最終位置になるものとして以後の実施形態を説明する。
【００２７】
図５から図１０で説明したように、フレームバッファに復号データが格納されるか、削除されるたびに有効チェーン、および空きチェーンの更新が行われることになるが、これらの更新処理のフローチャートについて説明する前に、その処理に用いられるデータの格納形式について図１１、図１２を用いて説明する。なおこの説明において有効チェーン、および空きチェーンは、図５から図１０ではｍ個のフレームバッファにそれぞれ１対１に対応するブロックを接続するものとし、各ブロックの番号はフレームバッファの番号と１対１に対応するものとする。なお図１１、図１２ではこの番号は０から９の１０個であるものとする。
【００２８】
図１１はチェーン内の各ブロックに対する共通データの格納例である。この例では有効チェーンによって接続されているブロックの数、空きチェーンによって接続されているブロックの数、有効チェーン、および空きチェーンの先頭ブロックの番号が格納されている。そして図５に示すように全てのフレームバッファが空である初期状態から、次にフレームバッファ０にデータが登録された状態、フレームバッファ０と１にデータが登録された状態、・・・・が順次右方向に示され、最も右側に全てのフレームバッファにデータが格納された状態の共通データが示されている。これらのデータの遷移については図１３、図１４のフローチャートに関連して後述する。
【００２９】
図１２は、チェーン内の各ブロックに対するブロック個別データの格納例である。ここではブロック＃０からブロック＃９までの各ブロックに対応して、ブロックのステータスとしての使用中、あるいは未使用、すなわち復号データが対応するバッファメモリに格納されているかいないかを示すデータ、フレームデータ、およびフレームデータに関連する時間情報に加えて、ＰＲＥＶ、およびＮＥＸＴのデータが格納されている。ここでＰＲＥＶは有効チェーン、または空きチェーンにおいてチェーンの前の位置となっているフレームバッファに対応するブロックの番号、ＮＥＸＴはチェーンにおいて次のフレームバッファに対応するブロックの番号を示すものである。これらの値の遷移についても図１３、および図１４のフローチャートに関連して説明する。
【００３０】
図１１と図１２のデータを用いることによって、有効チェーン、および空きチェーンの構成が明らかになる。例えば図５に対応する初期状態においては、有効チェーンのブロック数は“０”であり、有効チェーンは存在せず、空きチェーンのブロック数は“１０”であり、全てのブロックが空きチェーンによって接続される。この空きチェーンの先頭ブロックの番号は“０”であり、図１２のブロック＃０に対するＮＥＸＴが“１”となっていることから、ブロック＃０の次のブロックは＃１であり、ブロック＃１に対するＮＥＸＴの値が“２”であることから、次のブロックが＃２であることが示され、このようにＮＥＸＴの値をたどることによって空きチェーンの順方向の接続状態が明確となる。これに対して各ブロックに対応するＰＲＥＶの値をたどることによって空きチェーンの逆方向の接続状態が明確となる。
【００３１】
図１１において１フレームの登録が行われると、有効チェーンのブロック数は“１”、その先頭ブロックの番号は“０”となる。そこで図１２のブロック＃０に対するＮＥＸＴとＰＲＥＶの値を見るとともに“０”となっており、有効チェーンがブロック＃０だけによって構成されることがわかる。
【００３２】
これに対して空きチェーンのブロック数は“９”となり、先頭ブロックの番号が“１”であることから９個のブロックを接続する空きチェーンに対しては、ブロック＃１を先頭として各ブロックのＮＥＸＴの値をたどることによって順方向の接続が、ＰＲＥＶの値をたどることによって逆方向の接続が明確となる。
【００３３】
以下同様にして１０個のフレームバッファの全てに復号データが格納されると、有効チェーンのブロック数は“１０”、その先頭ブロック番号は“０”であることから有効チェーンの接続状態が明確となり、また空きチェーンのブロック数が“０”であることから空きチェーンが存在しないことが明確となる。なおここで空きチェーンの先頭ブロックの番号は“９”となっているが、これは９個のフレームバッファに復号データが格納された状態における空きチェーンの先頭ブロック番号が更新されていないことを示すだけであり、この先頭ブロック番号は後述するフローチャートの処理において参照されることはないため、未更新の状態で全く問題を生ずることはない。
【００３４】
図１３はフレームバッファへのデータ格納時におけるチェーン更新処理の詳細フローチャートである。同図の処理について図１１と図１２のデータの更新も含め、１０個のフレームバッファのいずれにも有効データが格納されていない初期状態から１つのフレームバッファにデータが格納される時点、およびさらに１つの有効データが他のフレームバッファに格納される時点の処理を例として説明する。
【００３５】
まず図１３において、ステップＳ３０で今回登録しようとするブロック、すなわち空きチェーンの先頭ブロック、図１１ではブロック番号“０”のブロックの前後のブロック番号、すなわちブロック＃０に対するＰＲＥＶとＮＥＸＴの値“９”と“１”が退避される、すなわち処理に用いられる値として、例えば作業領域に格納される、そしてステップＳ３１で有効チェーンのブロック数が“０”であるか否かが判定され、この時点では初期状態であり、有効チェーンのブロック数は“０”であるため、ステップＳ３２で今回データが登録されるブロックの番号、すなわち“０”が今回登録されるブロック、すなわち＃０に対するＮＥＸＴの値とされる。これは図１２において１フレーム登録状態のブロック＃０に対するＮＥＸＴの値となる。
【００３６】
続いてステップＳ３３で同様にブロック番号“０”がブロック＃０の１フレーム登録状態におけるＰＲＥＶの値とされる。すなわちこれらの処理においては右辺の値が左辺の値に代入される。次にステップＳ３４で有効チェーンの先頭ブロック番号の設定が行われる。この状態ではブロック＃０に対応するフレームバッファだけに有効データが格納されており、有効チェーンの先頭ブロック番号は“０”のままとなる。
【００３７】
続いてステップＳ３５で今回登録されたブロックの次のブロック番号、すなわち今回登録されたブロック＃０に対する１フレーム登録前の初期状態におけるＮＥＸＴの値“１”が空きチェーンの最終ブロック、すなわち今回登録されたブロック＃０の１フレーム登録前のＰＲＥＶのブロックであるブロック＃９のＮＥＸＴとして格納され、ステップＳ３６で空きチェーンの最終ブロックの番号、すなわち今回登録されたブロック＃０の以前のＰＲＥＶの値“９”が、空きチェーンの先頭ブロック、すなわち今回登録されたブロック＃０の以前のＮＥＸＴで示されるブロック＃１のＰＲＥＶの値として格納される。
【００３８】
その後ステップＳ３７で今回登録されたブロック番号“０”が空きチェーンの先頭ブロック番号に一致しているか否かが判定され、ここでは初期状態における空きチェーンの先頭ブロック番号が“０”であることから一致しているものと判定され、ステップＳ３８で空きチェーンの先頭ブロック番号を更新する処理が行われる。すなわち初期状態において空きチェーンの先頭から２番目のブロックの番号、ここでは“１”が図１１の１フレーム登録状態における空きチェーンの先頭ブロック番号として格納される。
【００３９】
ステップＳ３７で空きチェーンの先頭ブロック番号の更新が必要ないと判定された場合は直ちに、あるいはステップＳ３８の処理の後に、ステップＳ３９で有効チェーンのブロック数がインクリメントされ、ステップＳ４０で空きチェーンのブロック数がデクリメントされて、初期状態からブロック＃０に対応するフレームバッファだけにデータが格納された場合のチェーン更新処理が終了する。
【００４０】
次に図１１において１フレーム登録の状態から２フレーム登録の状態、すなわちブロック＃１に対応するフレームバッファにデータが格納される場合のチェーン更新処理について説明する。まずステップＳ３０ではブロック＃１に対応するＰＲＥＶとＮＥＸＴの値“９”と“２”が退避され、ステップＳ３１で有効チェーンブロック数が“０”でないと判定され、ステップＳ４１で有効チェーンの先頭ブロック番号、すなわち“０”が今回登録されるブロック＃１に対する２フレーム登録時のＮＥＸＴの値とされる。ステップＳ４２で有効チェーンの最終ブロック番号、すなわち“０”が、今回登録されるブロック＃１に対するＰＲＥＶの値として格納される。そしてステップＳ４３で今回登録されるブロックの番号“１”が、有効チェーンの先頭ブロック、すなわち＃０のＰＲＥＶの値とされ、ステップＳ４４で同様にブロック番号“１”がブロック＃０のＮＥＸＴの値とされる。
【００４１】
続いてステップＳ３５以降で有効チェーンのブロック数が“０”であった時と同様の処理が実行される。まずステップＳ３５で今回登録されたブロックの次のブロック番号“２”が、空きチェーンの最終ブロック＃９のＮＥＸＴの値として格納される。ステップＳ３６で空きチェーンの最終ブロック番号“９”が、空きチェーンの先頭ブロック＃２のＰＲＥＶの値として格納され、ステップＳ３７で空きチェーンの先頭ブロック番号の更新が必要か否かが判定され、ここでは今回登録されたブロック番号と空きチェーンの先頭ブロックの番号がともに“１”であり、一致しているために、ステップＳ３８で空きチェーンの先頭ブロック番号が“２”に更新され、ステップＳ３９で有効チェーンのブロック数のインクリメント、ステップＳ４０で空きチェーンのブロック数のデクリメントが行われ、処理を終了する。
【００４２】
図１４は、フレームバッファからのデータ削除時におけるチェーン更新処理の詳細フローチャートである。同図の処理を、まず図１１において９フレーム登録後にブロック＃０に対応するフレームバッファのデータを削除する、すなわち開放する場合を例として説明する。
【００４３】
まずステップＳ５１で今回開放しようとするブロックの前後のブロック番号、ここではブロック＃１のＰＲＥＶとＮＥＸＴの９フレーム登録時の値“０”と“２”が退避され、ステップＳ５２で空きチェーンのブロック数が“０”でないと判定され、ステップＳ５３で空きチェーンの先頭ブロック番号“９”が今回開放されるブロック＃１のＮＥＸＴの値として、次にステップＳ５４で空きチェーンの最終ブロック番号、やはり“９”がブロック＃１のＰＲＥＶの値として格納される。そしてステップＳ５５で今回開放されるブロック番号“１”が空きチェーンの先頭ブロック＃９のＰＲＥＶに格納され、ステップＳ５６でブロック番号“１”がブロック＃９のＮＥＸＴに格納される。このステップＳ５３からＳ５６の処理によって空きチェーンのつなぎ変えが行われ、ブロック＃９のみによって構成されていた空きチェーンにブロック＃１が追加されて、空きチェーンの接続が行われることになる。
【００４４】
続いてステップＳ５７で今回開放されたブロックの次のブロック番号、ここでは“２”が今回開放されたブロックの前のブロック、すなわちブロック＃０のＮＥＸＴの値として、またステップＳ５８でブロック番号“０”がブロック＃２のＰＲＥＶの値として格納され、続いてステップＳ５９で開放されたブロックの番号、ここでは“１”が有効チェーンの先頭ブロックの番号と一致しているか否かが判定される。この判定は、開放されたブロックが有効チェーンの先頭にある場合には有効チェーンの先頭ブロック番号の更新が必要となるためであり、一致している場合にはステップＳ６０で有効チェーンの２番目のブロックの番号を先頭ブロック番号とする有効チェーンの先頭ブロック番号の更新が行われた後に、ステップＳ６１の処理に移行する。ここでは開放されたブロックの番号は“１”、有効チェーンの先頭ブロック番号は“０”であり、一致しないため、ステップＳ６０の処理は行われることなく、ステップＳ６１で有効チェーンのブロック数のデクリメント、ステップＳ６２で空きチェーンのブロック数のインクリメントが行われて、ブロック＃１に対応するフレームバッファからのデータ削除に対応するチェーン更新処理を終了する。
【００４５】
次にチェーン更新処理のもう１つの例として、１０個のフレームバッファの全てにデータが格納とされた後に、前述と同様にブロック＃１に対応するフレームバッファの開放が行われる場合について説明する。
【００４６】
この場合、ステップＳ５１で前述と同様にＰＲＥＶとＮＥＸＴの値としての“０”と“２”が退避された後に、ステップＳ５２で空きチェーンのブロック数が“０”と判定され、ステップＳ６３の処理に移行する。
【００４７】
ステップＳ６３では今回開放されるブロック番号“１”がブロック＃１のＮＥＸＴの値として、ステップＳ６４でその値“１”がブロック＃１のＰＲＥＶの値として格納される。ステップＳ６５で空きチェーンの先頭ブロック番号が“１”に設定される。これによって空きチェーンがブロック＃１のみによって構成されることになる。
【００４８】
その後ステップＳ５７、Ｓ５８で前述と全く同様の処理が行われ、これによって有効チェーンからブロック＃１が除外されることになる。そしてステップＳ５９で前述と同様に開放されたブロックの番号と有効チェーンの先頭ブロックの番号が異なると判定され、ステップＳ６１で有効チェーンのブロック数のデクリメント、ステップＳ６２で空きチェーンのブロック数のインクリメントが行われて処理を終了する。
【００４９】
以上において本発明のフレームバッファ管理プログラム、および管理方法についてその詳細を説明したが、このプログラムは当然一般的なコンピュータシステムを基本とするデコーダシステムによって使用される。図１５はそのようなコンピュータシステム、すなわちハードウェア環境の構成ブロック図である。
【００５０】
図１５においてコンピュータシステムは中央処理装置（ＣＰＵ）３０、リードオンリメモリ（ＲＯＭ）３１、ランダムアクセスメモリ（ＲＡＭ）３２、通信インタフェース３３、記憶装置３４、入出力装置３５、可搬型記憶媒体の読取り装置３６、およびこれらの全てが接続されたバス３７によって構成されている。
【００５１】
記憶装置３４としてはハードディスク、磁気ディスクなど様々な形式の記憶装置を使用することができ、このような記憶装置３４、またはＲＯＭ３１に図４、図１３、図１４などのフローチャートに示されたプログラムや、本発明の特許請求の範囲の請求項１のプログラムなどが格納され、そのようなプログラムがＣＰＵ３０によって実行されることにより、本実施形態における複数のフレームバッファの管理、有効チェーンや空きチェーンの更新などが可能となる。
【００５２】
このようなプログラムは、プログラム提供者３８からネットワーク３９、および通信インタフェース３３を介して、例えば記憶装置３４に格納されることも、また市販され、流通している可搬型記憶媒体４０に格納され、読取り装置３６にセットされて、ＣＰＵ３０によって実行されることも可能である。可搬型記憶媒体４０としてはＣＤ−ＲＯＭ、フレキシブルディスク、光ディスク、光磁気ディスク、ＤＶＤなど様々な形式の記憶媒体を使用することができ、このような記憶媒体に格納されたプログラムが読取り装置３６によって読取られることにより、本実施形態における複数のフレームバッファの管理の容易化、制御の高速化などが可能となる。
【図面の簡単な説明】
【００５３】
【図１】本発明のフレームバッファ管理プログラムの原理的な機能ブロック図である。
【図２】本発明のフレームバッファ管理方式が用いられる動画像再生システムの構成例である。
【図３】図２におけるビデオデコーダの構成例である。
【図４】図２のシステムにおける動画像再生処理の全体フローチャートである。
【図５】フレームバッファへのデータ格納方式の説明図（その１）である。
【図６】フレームバッファへのデータ格納方式の説明図（その２）である。
【図７】フレームバッファへのデータ格納方式の説明図（その３）である。
【図８】フレームバッファへのデータ格納方式の説明図（その４）である。
【図９】フレームバッファへのデータ格納方式の説明図（その５）である。
【図１０】フレームバッファからのデータ削除方式の説明図である。
【図１１】有効チェーン、空きチェーン内の各ブロックに対応する共通データの格納例である。
【図１２】有効チェーン、空きチェーン内の各ブロックに対応する個別データの格納例である。
【図１３】フレームバッファへのデータ格納時のチェーン更新処理の詳細フローチャートである。
【図１４】フレームバッファからのデータ削除時のチェーン更新処理の詳細フローチャートである。
【図１５】本発明を実現するためのプログラムのコンピュータへのローディングを説明する図である。
【符号の説明】
【００５４】
１０  ＤＶＤ
１１  ユーザインターフェース部
１２  ビデオ・オーディオ分離部
１３  オーディオデコーダ
１４  ビデオデコーダ
１５  ＯＳ／ドライバ部
１６  スピーカー
１７  ＴＶ
２０  ビットストリーム
２１  可変長復号器
２２  逆量子化器
２３  逆離散コサイン変換器
２４  加算器
２５  動き補償部
２６  動画像データ
３０  ＣＰＵ
３１  リード・オンリー・メモリ
３２  ランダム・アクセス・メモリ
３３  通信インターフェース
３４  記憶装置
３５  入出力装置
３６  可搬型記憶媒体の読取装置
３７  バス
３８  プログラム提供者
３９  ネットワーク
４０  可搬型記憶媒体
【図１】
2007122502.tif 000003
【図３】
2007122502.tif 000004
【図４】
2007122502.tif 000005
【図１１】
2007122502.tif 000006
【図１２】
2007122502.tif 000007
【図１３】
2007122502.tif 000008
【図１４】
2007122502.tif 000009
【図１５】
2007122502.tif 000010
【図２】
2007122502.tif 000011
【図５】
2007122502.tif 000012
【図６】
2007122502.tif 000013
【図７】
2007122502.tif 000014
【図８】
2007122502.tif 000015
【図９】
2007122502.tif 000016
【図１０】
2007122502.tif 000017