(57)【特許請求の範囲】
【請求項１】
予測符号化によるフレーム間圧縮を用いて圧縮符号化されランダムアクセス可能な記録媒体に記録されたビデオデータを、逆方向の１倍速再生から順方向の１倍速再生まで可変速に再生するようにした再生装置であって、
少なくとも、現在の目標再生フレームと、上記現在の目標フレームに対して表示順で前後に隣接するそれぞれのフレームとを格納するフレームバッファと、
上記それぞれのフレームのいずれかが新たな目標再生フレームとされたときに、該新たな目標再生フレームに対する上記フレームバッファの目標パターンを作成する目標パターン作成部と、
上記現在の目標再生フレームが格納されたフレームバッファの状態と上記目標パターンとを比較する比較部と、
上記比較部による比較結果に基づき、新たにデコードが必要な１フレームを抽出すると共に上記現在のフレームバッファの状態で不要になる１フレームを抽出するフレームバッファ制御部とを有する再生装置。
【請求項２】
上記新たにデコードが必要な１フレームは、上記新たな目標再生フレームに対して表示順で前後に隣接するいずれかのフレームとされ、
上記フレームバッファ制御部は、該フレームが上記フレームバッファに既に格納されている場合は、上記フレームバッファに格納されているフレームの内、表示順で最も新しい１フレームまたは表示順で最も古い１フレームを、上記不要になる１フレームとする請求項１に記載の再生装置。
【請求項３】
上記フレームバッファ制御部は、所定のルールにより上記不要になる１フレームを決定し、
上記所定のルールは、上記新たな目標再生フレームに対して表示順で前後に隣接せず、時間的に前および／または後の他のフレームを基準としてデコードされる１フレームを上記不要になる１フレームとして決定する請求項１に記載の再生装置。
【請求項４】
上記フレームバッファ制御部により抽出された上記新たにデコードが必要なフレームの入力を開始し、該入力が開始されたフレームをデコードして上記フレームバッファ上の上記不要になるフレームの領域に対して格納するように制御するデコード制御部をさらに有する請求項１乃至３のいずれか１項に記載の再生装置。
【請求項５】
上記目標パターンは、
予め作成され記憶媒体に記憶されている請求項１乃至４のいずれか１項に記載の再生装置。
【請求項６】
予測符号化によるフレーム間圧縮を用いて圧縮符号化されランダムアクセス可能な記録媒体に記録されたビデオデータを、逆方向の１倍速再生から順方向の１倍速再生まで可変速に再生するようにした再生方法であって、
少なくとも、現在の目標再生フレームと、上記現在の目標フレームに対して表示順で前後に隣接するそれぞれのフレームとがフレームバッファに格納され、
上記それぞれのフレームのいずれかが新たな目標再生フレームとされたときに、該新たな目標再生フレームに対する上記フレームバッファの目標パターンを作成する目標パターン作成ステップと、
上記現在の目標再生フレームが格納されたフレームバッファの状態と上記目標パターンとを比較する比較ステップと、
上記比較ステップにおける比較結果に基づき、新たにデコードが必要な１フレームを抽出すると共に上記現在のフレームバッファの状態で不要になる１フレームを抽出するフレームバッファ制御ステップとを有する再生方法。
【請求項７】
予測符号化によるフレーム間圧縮を用いて圧縮符号化されランダムアクセス可能な記録媒体に記録されたビデオデータを、逆方向の１倍速再生から順方向の１倍速再生まで可変速に再生するようにした再生方法をコンピュータ装置に実行させるための再生プログラムであって、
少なくとも、現在の目標再生フレームと、上記現在の目標フレームに対して表示順で前後に隣接するそれぞれのフレームとがフレームバッファに格納され、
上記それぞれのフレームのいずれかが新たな目標再生フレームとされたときに、該新たな目標再生フレームに対する上記フレームバッファの目標パターンを作成する目標パターン作成ステップと、
上記現在の目標再生フレームが格納されたフレームバッファの状態と上記目標パターンとを比較する比較ステップと、
上記比較ステップにおける比較結果に基づき、新たにデコードが必要な１フレームを抽出すると共に上記現在のフレームバッファの状態で不要になる１フレームを抽出するフレームバッファ制御ステップとを有する再生方法をコンピュータ装置に実行させるための再生プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、順方向または逆方向の可変速再生をより高画質に行うようにした再生装置、再生方法および再生プログラムに関する。
【背景技術】
【０００２】
ディジタルビデオ信号およびディジタルオーディオ信号を記録媒体に記録し、また、記録媒体から再生するようなデータ記録再生装置が知られている。ディジタルビデオ信号およびディジタルオーディオ信号を記録するための記録媒体としては、従来から、磁気テープのようなシリアルアクセスを行う記録媒体が多く用いられてきたが、近年では、光ディスク、ハードディスク、半導体メモリなどといった、ランダムアクセス可能な記録媒体が、ディジタルビデオ信号およびディジタルオーディオ信号の記録再生に多く用いられるようになってきている。
【０００３】
ディジタルビデオ信号は、データ容量が膨大となるため、所定の方式で圧縮符号化されて記録媒体に記録されるのが一般的である。近年では、ＭＰＥＧ２(Moving Picture Experts Group 2)方式が圧縮符号化の標準的な方式として知られている。ＭＰＥＧ２では、ＤＣＴ(Discrete Cosine Transform)と動き補償とを用いてディジタルビデオ信号の圧縮符号化を行い、さらに可変長符号を用いてデータの圧縮率を高めている。
【０００４】
ＭＰＥＧ２のデータストリーム構造について、概略的に説明する。ＭＰＥＧ２は、動き補償予測符号化と、ＤＣＴによる圧縮符号化とを組み合わせたものである。ＭＰＥＧ２のデータ構造は、階層構造をなしており、下位から、ブロック層、マクロブロック層、スライス層、ピクチャ層、ＧＯＰ層およびシーケンス層となっている。ブロック層は、ＤＣＴを行う単位であるＤＣＴブロックからなる。マクロブロック層は、複数のＤＣＴブロックで構成される。スライス層は、ヘッダ部と、１以上のマクロブロックより構成される。ピクチャ層は、ヘッダ部と、１以上のスライスとから構成される。ピクチャは、１画面に対応する。
【０００５】
ＧＯＰ層は、ヘッダ部と、フレーム内符号化に基づくピクチャであるＩ(Intra-coded)ピクチャと、予測符号化に基づくピクチャであるＰ(Predictive-coded)ピクチャＢ(Bi-directionally predictive coded)ピクチャとから構成される。Ｉピクチャは、それ自身の情報のみでデコードが可能であり、ＰおよびＢピクチャは、基準画像として前あるいは前後の画像が必要とされ、単独ではデコードされない。例えばＰピクチャは、自身より時間的に前のＩピクチャまたはＰピクチャを基準画像として用いてデコードされる。また、Ｂピクチャは、自身の前後のＩピクチャまたはＰピクチャの２枚のピクチャを基準画像として用いてデコードされる。最低１枚のＩピクチャを含むそれ自身で完結したグループをＧＯＰ(Group Of Picture)と呼び、ＭＰＥＧのストリームにおいて独立してアクセス可能な最小の単位とされる。
【０００６】
ＧＯＰには１または複数のピクチャから構成される。以下では、便宜上、１枚のＩピクチャのみで構成されるＧＯＰをシングルＧＯＰと呼び、Ｉピクチャと、Ｐおよび／またはＢピクチャとからなる複数のピクチャで構成されるＧＯＰをロングＧＯＰと呼ぶことにする。シングルＧＯＰでは、ＧＯＰをＩピクチャのみから構成することで、フレーム単位での編集が容易とされると共に、フレーム間の予測符号化を行わないために、より高画質を得ることができる。一方、ロングＧＯＰでは、フレーム間の予測符号化を行うために、圧縮効率がよいという利点がある。
【０００７】
なお、ロングＧＯＰにおいて、ＧＯＰ内で完全にデコードが可能な、閉じた構造を持つクローズドＧＯＰと、デコードの際に符号化順で１つ前のＧＯＰの情報を用いることができるオープンＧＯＰとの２種類がある。オープンＧＯＰは、クローズドＧＯＰと比較して、より多くの情報を用いてデコードできるため高画質を得られ、一般的に用いられている。以下では、単に「ＧＯＰ」と記述した場合には、特に記載のない限り、このオープンＧＯＰを指すものとする。
【０００８】
ビデオ信号のフォーマットとして、従来から、ビットレートが２５Ｍｂｐｓ（メガビットパーセカンド）のＳＤ(Standard Definition)フォーマットが知られている。特に放送局などで使用される映像機器においては、ＳＤフォーマットのビデオ信号を上述したシングルＧＯＰで用い、高画質と高精度の編集環境とを実現していた。ＳＤフォーマットのビデオ信号は、フレーム毎のビットレートが固定の固定ビットレートが適用される。
【０００９】
一方、近年では、ディジタルハイビジョン放送などの実施に伴い、ＳＤフォーマットより高解像度とされた、ＨＤ(High Definition)フォーマットが用いられるようになってきた。ＨＤフォーマットは、高解像度に伴いビットレートが高くなっており、シングルＧＯＰでは記録媒体に対して長時間の記録ができない。そこで、ＨＤフォーマットのビデオ信号を上述したロングＧＯＰで用いる。ロングＧＯＰでは、予測符号化を用いたフレーム間圧縮を行うため、フレーム毎にビットレートが異なる可変ビットレートとされる。
【００１０】
ところで、ビデオ信号の編集の際には、ＩＮ点やＯＵＴ点といった編集点を決めるために、フレーム単位での頭出しが行われる。そのためには、順方向および逆方向の再生方向のそれぞれにおいて、再生速度が１倍速以下の可変速再生が必要となる。ＳＤフォーマットのように、シングルＧＯＰを用いている場合には、それぞれのフレームを独立してデコード可能なので、１倍速以下の可変速再生について、特に問題が発生することがない。すなわち、シングルＧＯＰの場合、少なくとも表示するフレームだけをデコードすれば済むからである。
【００１１】
一方、ＨＤフォーマットのように、ロングＧＯＰを用いている場合には、上述のＳＤフォーマットのようにそれぞれのフレームを独立してデコードすることができない。図１６を用いて、ロングＧＯＰの場合のデコード処理について説明する。ここでは、１ＧＯＰが１枚のＩピクチャ、４枚のＰピクチャおよび１０枚のＢピクチャの、計１５枚のピクチャから構成されるものとする。ＧＯＰ内のＩ、ＰおよびＢピクチャの表示順は、図１６Ａに一例が示されるように、「Ｂ0Ｂ1Ｉ2Ｂ3Ｂ4Ｐ5Ｂ6Ｂ7Ｐ8Ｂ9Ｂ10Ｐ11Ｂ12Ｂ13Ｐ14」のようになる。なお、添え字は表示順を示す。
【００１２】
この例では、最初の２枚のＢ0ピクチャおよびＢ1ピクチャは、１つ前のＧＯＰにおける最後尾のＰ14ピクチャと、このＧＯＰ内のＩ2ピクチャを用いて予測されデコードされたピクチャである。ＧＯＰ内の最初のＰ5ピクチャは、Ｉ2ピクチャから予測されデコードされたピクチャである。他のＰ8ピクチャ、Ｐ11ピクチャおよびＰ14は、それぞれ１つ前のＰピクチャを用いて予測されデコードされたピクチャである。また、Ｉピクチャ以降の各Ｂピクチャは、それぞれ前後のＩおよび／またはＰピクチャから予測されデコードされたピクチャである。
【００１３】
一方、Ｂピクチャは、時間的に前後のＩまたはＰピクチャを用いて予測されデコードされるため、ストリームや記録媒体上におけるＩ、ＰおよびＢピクチャの並び順は、デコーダにおけるデコードの順序を考慮して決める必要がある。すなわち、ＢピクチャをデコードするためのＩおよび／またはＰピクチャは、当該Ｂピクチャよりも常に先にデコードされていなければならない。
【００１４】
上述の例では、ストリームや記録媒体上の各ピクチャの配列は、図１６Ｂに例示されるように、「Ｉ2Ｂ0Ｂ1Ｐ5Ｂ3Ｂ4Ｐ8Ｂ6Ｂ7Ｐ11Ｂ9Ｂ10Ｐ14Ｂ12Ｂ13」のようになり、この順でデコーダに入力される。なお、添え字は、図１６Ａに対応し、表示順を示す。
【００１５】
デコーダにおけるデコード処理は、図１６Ｃに示されるように、先ずＩ2ピクチャをデコードし、デコードされたこのＩ2ピクチャと１つ前のＧＯＰにおける最後尾（表示順）のＰ14ピクチャとによりＢ0ピクチャおよびＢ1ピクチャを予測しデコードする。そして、Ｂ0ピクチャおよびＢ1ピクチャをデコードされた順にデコーダから出力し、次にＩ2ピクチャを出力する。Ｂ1ピクチャが出力されると、次にＰ5ピクチャがＩ2ピクチャを用いて予測されデコードされる。そして、Ｉ2ピクチャおよびＰ5ピクチャを用いてＢ3ピクチャおよびＢ4ピクチャが予測されデコードされる。そして、デコードされたＢ3ピクチャおよびＢ4ピクチャをデコードされた順にデコーダから出力し、次にＰ5ピクチャを出力する。
【００１６】
以下、同様にして、Ｂピクチャの予測に用いるＰまたはＩピクチャをＢピクチャより先にデコードし、このデコードされたＰまたはＩピクチャを用いてＢピクチャを予測してデコードし、デコードされたＢピクチャを出力してから、当該Ｂピクチャをデコードするために用いたＰまたはＩピクチャを出力する処理が繰り返される。記録媒体上やストリームにおける図１６Ｂのようなピクチャ配列は、一般的に用いられるもので、デコードに４フレーム分のフレームメモリが必要となる。非特許文献１には、このようにしてＭＰＥＧ２のエレメンタリストリームをデコードする方法が記載されている。
【非特許文献１】藤原  洋、「ポイント図解式・最新ＭＰＥＧ教科書」、初版、株式会社アスキー、１９９４年８月１日、ｐ．１０６
【００１７】
このような、ビデオ信号にロングＧＯＰを用いた場合の順方向への１倍速再生は、１フレーム分の時間で１フレームのピクチャのデコード結果が得られるデコーダ（１倍速デコーダと呼ぶ）を用いて可能である。
【発明の開示】
【発明が解決しようとする課題】
【００１８】
ところで、特に編集作業などの場合、必要なフレームを探すために、再生速度については１倍速以下で可変に、また、再生方向については順方向および逆方向に自在に切り換えられることが求められる。ビデオ信号にロングＧＯＰを用い、順方向および逆方向に１倍速以下の再生速度で可変速再生する場合について考える。
【００１９】
なお、ビデオ信号にシングルＧＯＰを用いた場合は、上述したように、表示するためのフレームを単独でデコードすることができるため、順方向および逆方向の１倍速以下の可変速再生や、順方向および逆方向への再生方向の切り換えを行っても、特に問題は発生しない。
【００２０】
ビデオ信号にロングＧＯＰを用いた場合、上述したように、表示するためのフレームをデコードする際に、時間的に前および／または後のピクチャを１乃至複数枚、必要とする。順方向で１倍速以下の再生速度での再生は、再生速度に応じて入力ストリームを止めてフレームメモリを更新しないようにすると共に、出力されるビデオ信号をフレームメモリから繰り返し読み出すことで、上述の１倍速デコーダを用いて実現できる。
【００２１】
一方、ビデオ信号にロングＧＯＰを用いて逆方向再生を行う場合、１フレームの画像を表示するのに、順方向の再生時に比べ、より多くのピクチャが必要となる場合が多い。
【００２２】
一例として、表示順が図１６Ａに例示されるビデオストリームを逆方向再生する場合、Ｐ14ピクチャを最初に出力しなければならない。上述したように、Ｐ14ピクチャをデコードするためには、Ｉ2ピクチャ、Ｐ5ピクチャ、Ｐ8ピクチャおよびＰ11ピクチャのデコードが必要である。したがって、図１６Ｂのような配列でストリームが入力される場合、少なくとも４フレーム分のデコード処理を行うだけの遅延が生じることになる。また、Ｉ2ピクチャ、Ｐ5ピクチャ、Ｐ8ピクチャおよびＰ11ピクチャは、Ｂピクチャをデコードするために用いられるため、メモリに保持することが必要になる。
【００２３】
さらに、当該ＧＯＰの最後に出力されるべきＢ1ピクチャおよびＢ0ピクチャは、当該ＧＯＰのＩ2ピクチャと、本来の再生方向において１つ前のＧＯＰ、すなわち逆方向再生では１つ後のＧＯＰのＰ14ピクチャとを用いて予測されデコードされるため、当該ＧＯＰのデコード処理中に、さらに逆方向再生における表示順で１つ後のＧＯＰのデコード処理も必要になる。
【００２４】
ここで、再生方向を順方向から逆方向、または、逆方向から順方向に切り換える場合について考える。例えば、ジョグダイヤルなどで再生速度および再生方向を制御できるような編集装置などを想定し、再生速度が０の点を中心に再生速度および再生方向を切り換えながら所望のフレームを探すような場合に相当する。
【００２５】
例えば順方向に再生中の任意のフレームが表示されているときに、再生方向を逆方向に切り換えた場合、再生方向を順方向から逆方向に切り換える直前のフレームの、１フレーム前のフレーム画像がフレームメモリに残っていれば、逆方向に再生方向を切り換えたときの１フレーム目は、フレームメモリに残っている当該フレーム画像を用いて表示することができる。
【００２６】
しかしながら、例えば、再生方向を逆方向に切り換える直前のフレームがＧＯＰの最後に表示されるＰ14ピクチャであった場合、再生方向を逆方向に切り換えた直後に表示されるべきフレームは、当該ＧＯＰのＢ13ピクチャである。このＢ13ピクチャをデコードするためには、Ｐ14ピクチャとＰ11ピクチャが必要であり、さらに、Ｐ11ピクチャをデコードするためには、当該ＧＯＰのＩ2ピクチャ、Ｐ5ピクチャおよびＰ8ピクチャが必要とされる。
【００２７】
したがって、この場合、再生方向を順方向から逆方向に切り換えた瞬間に、少なくとも４ピクチャ分（Ｉ2ピクチャ、Ｐ5ピクチャ、Ｐ8ピクチャおよびＰ11ピクチャ）のデコード時間分の遅延が生じてしまうという問題点があった。特に、順方向と逆方向の切り換えを頻繁に行うような場合では、この遅延が操作感の悪さとなって現れてしまい、問題となる。
【００２８】
すなわち、記録再生装置を編集動作などに適用させるためには、編集装置といった上位のシステムから要求されたコマンド速度に対して、常に一定の遅延で再生出力結果を出す必要がある。順方向から逆方向に再生方向を切り換えた際に遅延が生ずるのでは、編集動作としては適当でないといえる。
【００２９】
この問題を解決するために、幾つかの方法が考えられている。第１の方法としては、デコーダに１倍速よりも十分高速なデコード速度を持つものを用いる方法が考えられる。例えば、上述の例では、１フレーム時間内に４フレーム分以上のピクチャをデコード可能なデコーダを用いることが考えられる。しかしながら、１倍速デコーダに対して、高速なデコード速度を持つデコーダは高価であり、コストが嵩んでしまうという問題点があった。
【００３０】
第２の方法として、所定の表示タイミングに対してデコードの間に合わないピクチャをコマ落ち、すなわちデコードおよび表示しないようにし、見かけ上、再生が継続されるようにする方法が考えられる。しかしながら、この方法は、表示品質の点で問題があった。
【００３１】
第３の方法として、エンコード時に、入力されたビデオ信号に基づき、本来用いられるビデオ信号に対して解像度を落としたより低解像度のデータなど、固定遅延で再生出力可能なデータを作成し、記録媒体に記録しておく。そして、再生時に、本来用いられるビデオ信号のデコードが間に合わない際にこの低解像度のデータを用いて表示を行う方法が考えられる。この方法でも、本来用いられるビデオ信号のピクチャに対して低解像度のピクチャが混在して表示されることになり、表示品質の点で問題があった。
【００３２】
第４の方法として、上位のシステムから要求されるコマンド速度が決まってから、必要なピクチャをデコードし、再生動作が滞らない程度のピクチャがフレームメモリに蓄積されたら、実際の再生を開始する方法が考えられる。しかしながらこの方法では、上位のシステムからコマンド速度が要求されてから再生が開始されるまで、遅延が生じてしまうことになり、上述の問題点を解決できない。
【００３３】
したがって、この発明の目的は、予測符号化によるフレーム間圧縮を行ったビデオ信号の再生を１倍速デコーダを用いて行う場合において、順方向の１倍速再生から逆方向の１倍速再生までの可変速再生を、固定的な遅延で行うことができる再生装置、再生方法および再生プログラムを提供することにある。
【課題を解決するための手段】
【００３４】
この発明は、上述した課題を解決するために、予測符号化によるフレーム間圧縮を用いて圧縮符号化されランダムアクセス可能な記録媒体に記録されたビデオデータを、逆方向の１倍速再生から順方向の１倍速再生まで可変速に再生するようにした再生装置であって、少なくとも、現在の目標再生フレームと、現在の目標フレームに対して表示順で前後に隣接するそれぞれのフレームとを格納するフレームバッファと、それぞれのフレームのいずれかが新たな目標再生フレームとされたときに、新たな目標再生フレームに対するフレームバッファの目標パターンを作成する目標パターン作成部と、現在の目標再生フレームが格納されたフレームバッファの状態と目標パターンとを比較する比較部と、比較部による比較結果に基づき、新たにデコードが必要な１フレームを抽出すると共に現在のフレームバッファの状態で不要になる１フレームを抽出するフレームバッファ制御部とを有する再生装置である。
【００３５】
また、この発明は、予測符号化によるフレーム間圧縮を用いて圧縮符号化されランダムアクセス可能な記録媒体に記録されたビデオデータを、逆方向の１倍速再生から順方向の１倍速再生まで可変速に再生するようにした再生方法であって、少なくとも、現在の目標再生フレームと、現在の目標フレームに対して表示順で前後に隣接するそれぞれのフレームとがフレームバッファに格納され、それぞれのフレームのいずれかが新たな目標再生フレームとされたときに、新たな目標再生フレームに対するフレームバッファの目標パターンを作成する目標パターン作成ステップと、現在の目標再生フレームが格納されたフレームバッファの状態と目標パターンとを比較する比較ステップと、比較ステップにおける比較結果に基づき、新たにデコードが必要な１フレームを抽出すると共に現在のフレームバッファの状態で不要になる１フレームを抽出するフレームバッファ制御ステップとを有する再生方法である。
【００３６】
また、この発明は、予測符号化によるフレーム間圧縮を用いて圧縮符号化されランダムアクセス可能な記録媒体に記録されたビデオデータを、逆方向の１倍速再生から順方向の１倍速再生まで可変速に再生するようにした再生方法をコンピュータ装置に実行させるための再生プログラムであって、少なくとも、現在の目標再生フレームと、現在の目標フレームに対して表示順で前後に隣接するそれぞれのフレームとがフレームバッファに格納され、それぞれのフレームのいずれかが新たな目標再生フレームとされたときに、新たな目標再生フレームに対するフレームバッファの目標パターンを作成する目標パターン作成ステップと、現在の目標再生フレームが格納されたフレームバッファの状態と目標パターンとを比較する比較ステップと、比較ステップにおける比較結果に基づき、新たにデコードが必要な１フレームを抽出すると共に現在のフレームバッファの状態で不要になる１フレームを抽出するフレームバッファ制御ステップとを有する再生方法をコンピュータ装置に実行させるための再生プログラムである。
【００３７】
上述したように、この発明は、次に再生されるべき目標再生フレームに対する、複数フレーム分のビデオデータを一時的に格納可能なフレームバッファの目標パターンを作成し、現在のフレームバッファの状態と目標パターンとを比較した比較結果に基づき、新たにデコードが必要なフレームを抽出すると共に現在のフレームバッファの状態で不要になるフレームを抽出するようにしているため、順方向への１倍速再生から逆方向への１倍速再生までの再生時に、フレームバッファにおける更新フレーム数が常に１フレームとすることができる。またこれにより、フレームの入力からデコードまでの遅延量が固定的とされ、順方向への１倍速再生から逆方向への１倍速再生までの可変速再生を、固定的な遅延量でコマ落ち無しに、１倍速デコーダを用いて行うことができる。
【発明の効果】
【００３８】
この発明は、上述のように、次に再生されるべき目標再生フレームに対するフレームバッファの目標パターンを作成し、作成された目標パターンと現在のフレームバッファの状態とを比較する。そして、比較結果に基づき、新たにデコードが必要なフレームと現在のフレームバッファの状態で不要になるフレームとを抽出するようにしている。そのため、順方向への１倍速再生から逆方向への１倍速再生までの再生時に、フレームバッファにおける更新フレーム数を常に１フレームとすることができると共に、フレームの入力からデコードまでの遅延量が固定的にできる効果がある。
【００３９】
またこれにより、順方向への１倍速再生から逆方向への１倍速再生までの可変速再生を、固定的な遅延量でコマ落ち無しに、１倍速デコーダを用いて行うことができる効果がある。
【発明を実施するための最良の形態】
【００４０】
以下、この発明の実施の一形態を、図面を参照しながら説明する。図１は、この発明による再生制御処理を概念的に示す。ステップＳ１で、次に再生すべき目標再生フレームが指示される。目標再生フレームは、例えば再生速度が順方向または逆方向に１倍速以内であれば、１フレームタイミング前で確定した目標再生フレームに対して表示順で隣接するフレームの範囲となる。目標再生フレームは、例えばより上位のシステムから指定され、フレームタイミング毎に供給される。
【００４１】
目標再生フレームが指示されると、次に、目標再生フレームに対する目標フレームバッファのパターンが作成される（ステップＳ２）。目標フレームバッファのパターンは、目標再生フレームを再生すると共に、逆方向および順方向への再生を継続するために、フレームバッファ上にデコードされた状態で溜め込まれている必要があるフレームのパターンである。次のステップＳ３で、作成された目標フレームバッファパターンと現在のフレームバッファの状態とが比較される。この比較により、現在のフレームバッファの状態に対して新規にデコードが必要なピクチャが抽出される（ステップＳ４）と共に、現在のフレームバッファの状態において不要なピクチャが抽出される（ステップＳ５）。ステップＳ４およびステップＳ５で抽出されるピクチャは、常に１ピクチャである。
【００４２】
ここまでが、実際にデコードを行うためのターゲットを作成する処理となる。次から、実際にデコーダが制御され、デコード処理が開始される。
【００４３】
ステップＳ６では、例えば記録媒体がアクセスされ、ステップＳ４で抽出された結果に基づき所定のピクチャがデコーダに対してストリーム入力される。デコーダでデコードされたピクチャは、フレームバッファ上の、上述のステップＳ５で抽出された不要ピクチャの領域に上書きされる（ステップＳ７）。１ピクチャ分のデコードが完了すると、デコード済みの出力フレーム画像として出力される（ステップＳ８）。
【００４４】
図２は、この発明の実施の一形態に適用可能な再生装置１の一例の構成を概略的に示す。再生装置１は、光ディスク１０を記録媒体として用いる。ＣＰＵ(Central Processing Unit)１４は、ＲＯＭ(Read Only Memory)およびＲＡＭ(Random Access Memory)が接続され（図示しない）、ＲＯＭに予め記憶されたプログラムに従いこの再生装置１の各部を制御する。ＲＡＭは、ＣＰＵ１４のワークメモリとして用いられる。
【００４５】
ディスクドライブ１１は、ＣＰＵ１４の制御に基づき、装填された光ディスク１０の所定のアドレスからデータを読み出す。読み出されたデータは、キャッシュメモリ１２に一時的に溜め込まれる。そして、ＣＰＵ１４の命令に基づき、キャッシュメモリ１２からデコーダ１３に対してビデオストリームが供給され、要求に応じて入力されたビデオストリームをフレームメモリ１３Ａを用いてデコードする。デコード出力は、ベースバンドのビデオ信号として出力される。
【００４６】
操作部１５は、キーやスイッチなどの様々な操作子が設けられ、操作子に対してなされた操作に応じた制御信号を生成し、ＣＰＵ１４に供給する。ＣＰＵ１４は、供給されたこの制御信号に応じて再生装置１の各部に対して命令を送る。操作部１５には、例えばジョグダイヤル１６が設けられる。ジョグダイヤル１６は、回転角に応じた信号が出力されるようになっており、例えば、ジョグダイヤル１６は、ユーザによる操作に応じて、再生方向について順方向および逆方向の指定を行うための制御信号や、再生速度を略リアルタイムで指示する制御信号などを生成し、ＣＰＵ１４に供給する。
【００４７】
なお、再生速度や再生方向などを指示する命令は、操作部１５に対する操作に基づくものに限定されない。例えば、所定の通信手段（図示しない）により再生装置１に接続された、編集装置などの他の装置からこの装置に対して、再生速度や再生方向を命令するコマンドを送信するようにできる。この場合、再生装置１に対してコマンドを送信する他の装置は、この再生装置１に対するより上位の装置となる。
【００４８】
この再生装置１で扱われるビデオストリームは、ＭＰＥＧ２(Moving Pictures Experts Group 2)の規格に準じて圧縮符号化がなされたストリームであって、ＧＯＰ(Group Of picture)の構成は、ロングＧＯＰおよびオープンＧＯＰであるものとする。
【００４９】
図３は、デコーダ１３の一例の構成を概略的に示す。光ディスク１０から読み出され、ディスクドライブ１１から出力されるストリームデータは、例えばＭＰＥＧ−ＥＳ(MPEG Elementally Stream)である。このＭＰＥＧ−ＥＳは、ストリームデコーダ２０に供給される。ストリームデコーダ２０は、入力されたＭＰＥＧ−ＥＳのパケットとヘッダ情報とを解析し、デコード処理に必要な各種パラメータと、圧縮符号化されパケット中のペイロードに格納されたピクチャのデータとを抽出する。各種パラメータは、例えばＣＰＵ１４に供給される。抽出されたピクチャデータは、ストリームバッファ２１に所定に溜め込まれる。
【００５０】
ＭＰＥＧデコーダ２２は、ストリームデコーダ２０に対してストリームバッファ２１に溜め込まれたピクチャデータを要求し、要求に応じてストリームバッファ２１から読み出されたピクチャデータをデコードしてフレームメモリ１３Ａに書き込む。また、ＭＰＥＧデコーダ２２は、フレームメモリ１３Ａに書き込まれたピクチャデータを用いて他のピクチャデータ（例えばＰピクチャやＢピクチャ）をデコードする処理も行う。
【００５１】
なお、詳細は後述するが、フレームメモリ１３Ａは、順方向の再生と逆方向の再生とを固定的な遅延で実行可能とするための必要十分な容量を有する。例えば、フレームメモリ１３Ａは、デコードされたピクチャの９フレーム分を溜め込めるだけの容量を有する。一例として、フレームメモリ１３Ａは、それぞれ１フレーム分のデータを格納可能な９個のバンクに記憶領域が分割され、バンク毎にアクセスが制御される。
【００５２】
出力データ制御部２３は、出力されるビデオデータの管理を行う。例えば、出力データ制御部２３は、操作部１５に対する操作に応じたＣＰＵ１４の命令に基づき、フレームメモリ１３Ａから次に表示するためのフレームデータを読み出す。読み出されたフレームデータは、ベースバンドのビデオ信号として出力される。
【００５３】
図４は、デコーダ１３の一例の構成をより具体的に示す。なお、図４において、上述する図３と共通する部分には同一の符号を付して詳細な説明を省略する。ディスクドライブ１１から出力されたＭＰＥＧ−ＥＳは、デマルチプレクサ（ＤＭＵＸ）３０に供給され、パケットが解析される。パケットから取り出されたＭＰＥＧ  ＥＳおよびヘッダ情報は、ストリームバッファ２１に溜め込まれる。パケットのヘッダ情報は、また、ユーザデータデコーダ３１に供給され、各種パラメータが抽出される。抽出されたパラメータは、ストリームバッファ２１に所定に溜め込まれる。
【００５４】
デコーダ３２は、ストリームバッファ２１に溜め込まれたヘッダ情報やＭＰＥＧ  ＥＳをデコードする。デコーダ３２は、ヘッダ情報のデコードを行いピクチャのデコードに必要なパラメータを取り出す。デコーダ３２は、ヘッダ情報から取り出されたパラメータに基づき、ＭＰＥＧ  ＥＳに対して、可変長符号のデコード、逆量子化および逆ＤＣＴ(Discrete Cosine Transform)を行い、ピクチャ毎のデコードを行う。デコーダ３２でデコードされたピクチャデータは、予測復元部３３を介してフレームメモリ１３Ａに書き込まれる。
【００５５】
予測復元部３３は、フレームメモリ１３Ａに書き込まれたピクチャデータを用いて、予測符号化を用いてフレーム間圧縮をされたピクチャをデコードする。フレーム間圧縮をデコードされたピクチャは、フレームデータとしてフレームメモリ１３Ａに再び書き込まれる。
【００５６】
一方、ユーザの、再生方向および再生速度を指定するためのジョグダイヤル１６に対する操作などにより、操作部１５で、再生速度や再生方向を示す制御信号が所定に生成される。この制御信号は、ＣＰＵ１４に供給される。再生方向や再生速度を示す制御信号は、これに限らず、上述したように、図示されない通信手段を介してより上位の装置からコマンドとしてＣＰＵ１４に供給されるようにしてもよい。
【００５７】
ＣＰＵ１４は、ＲＯＭ３５に予め記憶されたプログラムに従い、操作部１５から供給された制御信号に基づき、ビデオ出力部２３に対して命令を出し、出力すべきフレームを指示する。なお、ＲＡＭ３６は、必要に応じてＣＰＵ１４のワークメモリとして用いられる。ビデオ出力部２３は、この命令に応じてフレームメモリ１３Ａから指示されたフレームを読み出す。
【００５８】
読み出されたフレームは、補助データ重畳部３４に供給され、ストリームバッファ２１に溜め込まれた情報に基づき所定にビデオインデックス情報や補助データなどが重畳され、さらに同期信号を付加されて、出力ビデオ信号として出力される。
【００５９】
次に、この発明の実施の一形態に適用できる記録媒体について説明する。先ず、図５を用いて、ディスク状記録媒体における一例のデータ配置について説明する。この図５に一例が示されるデータ配置は、記録可能な光ディスク、ハードディスクといった、ランダムアクセスが可能なディスク状記録媒体における一般的なデータ配置である。論理アドレス空間は、任意のデータを記録再生可能な領域である。
【００６０】
この実施の一形態では、記録媒体を光ディスクとする。なお、この実施の一形態に適用可能な記録媒体は、光ディスクに限られない。すなわち、この実施の一形態は、ハードディスクドライブや半導体メモリといった、他のランダムアクセス可能な記録媒体にも適用できるものである。
【００６１】
論理アドレスの先端および後端には、ファイルシステムＦＳが配置される。任意のデータは、論理アドレス空間内に一般的にファイルと称される所定の形式で記録される。記録媒体上のデータは、基本的にファイル単位で管理される。ファイルの管理情報は、ファイルシステムＦＳに記録される。記録再生装置のシステム制御部（後述する）のファイルシステム層は、このファイルシステムＦＳの情報を参照および操作することで、多種多様なデータを一つの記録媒体上で管理することができる。ファイルシステムＦＳは、例えばＵＤＦ(Universal Disk Format)が用いられ、２ｋＢ単位でファイルを管理する。
【００６２】
論理アドレス空間の外に、交替領域が配置される。交替領域は、記録媒体の一部が欠陥（ディフェクト）により物理的に読み書きできなくなった場合に代替的に用いることができる領域である。例えば、記録媒体に対するアクセス（特に記録時のアクセス）の際に欠陥領域が認識された場合、通常は交替処理が行われ、当該欠陥領域のアドレスが交替領域内に移動される。
【００６３】
交替領域の使用状況は、所定領域にディフェクトリストとして記憶され、記録再生装置のドライブ制御部や、システム制御部の下位階層により用いられる。すなわち、後述するドライブ制御部やシステム制御部の下位階層では、記録媒体へのアクセスの際にディフェクトリストを参照することで、交替処理が行われている場合にも、適切な領域へのアクセスを行うことができる。交替領域のこの仕組みにより、上位アプリケーションは、記録媒体上の不良記録領域の有無や位置などを考慮することなく、記録媒体に対するデータの記録再生を行うことができる。
【００６４】
ディスク状記録媒体の場合、交替領域は、ディスクの最内周側または最外周側に配置されることが多い。ディスクの回転制御を、ディスクの半径方向に段階的に回転速度を変更するゾーン制御で行っている場合には、ゾーン毎に交替領域を設ける場合もある。記録媒体が半導体メモリなどディスク状記録媒体ではない場合には、物理アドレスが最も小さい側または最も大きい側に配置されることが多い。
【００６５】
オーディオデータおよびビデオデータ（以下、まとめてＡＶデータと呼ぶ）を扱うアプリケーションにおいては、連続同期再生、すなわち実時間再生が保障された再生が必要な単位となるデータのまとまりを、クリップと呼ぶ。例えば、ビデオカメラにより撮影が開始されてから終了されるまでのひとまとまりのデータがクリップとされる。クリップの実体は、単一のファイルまたは複数のファイルからなる。この発明においては、クリップは、複数のファイルからなる。クリップの詳細については、後述する。
【００６６】
論理アドレス空間に対して、例えば先頭側にクリップ以外の任意のファイルが記録できるＮＲＴ(Non Real Time)領域が配置され、ＮＲＴ領域の次から、クリップが順に詰め込まれていく。クリップは、光ディスク１０上のディフェクト位置を避けて配置され、上述した交替処理が行われないようにされる。各クリップには、ヘッダ（Ｈ）およびフッタ（Ｆ）が付加される。この例では、ヘッダおよびフッタは、クリップの後端側にまとめて配置されている。
【００６７】
なお、以下の説明において、光ディスク１０に最初に記録されるクリップを、クリップ＃１とし、以降、クリップ＃２、クリップ＃３、・・・とクリップ番号が増加していくものとする。
【００６８】
論理アドレス空間内において、データが記録されていない領域や、過去にデータが記録されていたが現在では不要になった領域は、未使用領域としてファイルシステムＦＳに管理される。記録媒体上に新たに記録されるファイルに対して、未使用領域に基づき記録領域が割り当てられる。当該ファイルの管理情報は、ファイルシステムＦＳに追加される。
【００６９】
記録媒体として記録可能な光ディスクを用いた場合、この発明では、クリップを年輪構造によって記録媒体に記録する。図６および図７を用いて、年輪構造について説明する。図６Ａは、一つのクリップ１００をタイムライン上に示す例である。この例では、クリップ１００は、ビデオデータ１０１、オーディオデータ１０２Ａ〜１０２Ｄ、補助ＡＶデータ１０３およびリアルタイムメタデータ１０４の７ファイルからなる。
【００７０】
ビデオデータ１０１は、ベースバンドのビデオデータを、例えばビットレートが５０Ｍｂｐｓ（メガビットパーセカンド）の高ビットレートで圧縮符号化したビデオデータである。圧縮符号化方式としては、例えばＭＰＥＧ２(Moving Pictures Experts Group 2)方式が用いられる。オーディオデータ１０２Ａ、１０２Ｂ、１０２Ｃおよび１０２Ｄは、ベースバンドのオーディオデータが用いられ、それぞれ２チャンネルのオーディオデータである。これに限らず、オーディオデータ１０２Ａ、１０２Ｂ、１０２Ｃおよび１０２Ｄは、ベースバンドのオーディオデータを高ビットレートで圧縮符号化したオーディオデータを用いてもよい。ビデオデータ１０１およびオーディオデータ１０２Ａ〜１０２Ｄは、実際の放送や編集の対象とされるデータであって、本線系のデータと称される。
【００７１】
補助ＡＶデータ１０３は、ベースバンドのビデオデータおよびオーディオデータを、本線系のビデオデータおよびオーディオデータに対してより低ビットレートで圧縮符号化して多重化したデータである。圧縮符号化方式としては、例えばＭＰＥＧ４方式が用いられ、本線系のＡＶデータを、ビットレートを例えば数Ｍｂｐｓまで落とすように圧縮符号化して生成する。補助ＡＶデータ１０３は、高速サーチ再生を行うために本線系のデータの代理として用いられるデータであって、プロキシ(Proxy)データとも称される。
【００７２】
メタデータは、あるデータに関する上位データであり、各種データの内容を表すためのインデックスとして機能する。メタデータには、上述の本線系のＡＶデータの時系列に沿って発生されるリアルタイムメタデータ１０４と、本線系のＡＶデータにおけるシーン毎など、所定の区間に対して発生される非時系列メタデータの２種類がある。非時系列メタデータは、例えば図５で説明したＮＲＴ領域に記録される。
【００７３】
クリップ１００は、図６Ｂに一例が示されるように、所定の再生時間（例えば２秒）を基準として分割され、年輪構造として光ディスクに記録される。一つの年輪は、図６Ｃに一例が示されるように、ビデオデータ１０１、オーディオデータ１０２Ａ〜１０２Ｄ、補助ＡＶデータ１０３およびリアルタイムメタデータ（ＲＭ）１０４を、それぞれ再生時間帯が対応するように、トラック１周分以上のデータサイズを有する所定の再生時間単位に分割し、分割された再生時間単位毎に順に配置して記録する。すなわち、クリップ１００を構成する各データは、年輪構造により所定時間単位でインターリーブされ、光ディスクに記録される。
【００７４】
年輪を形成するデータを年輪データと称する。年輪データは、ディスクにおける最小の記録単位の整数倍のデータ量とされる。また、年輪は、その境界がディスクの記録単位のブロック境界と一致するように記録される。
【００７５】
図７は、光ディスク１０に対して年輪データが形成された一例の様子を示す。例えば、図６Ｂを用いて説明したように、光ディスク１０の内周側から外周側に向けて、１つのクリップが所定の再生時間単位に分割された年輪データ＃１、＃２、＃３、・・・が連続的に記録される。すなわち、光ディスク１０の内周側から外周側に向けて、再生の時系列が連続するようにデータが配置される。なお、図示しないが、ＮＲＴ領域は、図７の例では、先頭の年輪データ＃１のさらに内周側に配置される。
【００７６】
ＨＤフォーマットでは、可変長ビットレートでの圧縮符号化が可能とされている。また、ロングＧＯＰを用いた場合、予測符号化を用いたフレーム間圧縮符号化により、Ｉピクチャ、ＰピクチャおよびＢピクチャにより、データサイズが異なる。そこで、ピクチャポインタファイルを用いて所望の位置へのアクセスを実現する。
【００７７】
ピクチャポインタは、クリップ内の各フレーム位置のオフセット情報である。すなわち、例えばＭＰＥＧ２においては、フレーム毎にデータの圧縮率を変える可変ビットレートが可能とされている。例えば、平坦な画面のフレームは、より高圧縮率で圧縮符号化し、粗い画面のフレームは、より低圧縮率で圧縮符号化する。このように、フレームの性質に応じて圧縮率を変えることで、より高解像度のビデオデータをより低いビットレートで伝送および記録することができる。また、ＭＰＥＧ２においては、可変長符号による圧縮符号化もなされる。
【００７８】
このような、ビットレートを可変として圧縮符号化されたビデオデータは、フレーム位置や複数フレームで再生が完結されるＧＯＰの位置がフレーム毎やＧＯＰ毎に異なり、所望の位置へのジャンプなどが難しい。そこで、可変長ビットレートのアクセスを容易とするために、クリップ内の各フレーム位置のオフセット情報をピクチャポイントとしてテーブル化して非時系列メタデータファイルとし、クリップにそれぞれ対応して配置する。例えばドライブにディスクを挿入した際にこのピクチャポイントを所定に読み込んでおくことで、クリップ内の所望位置へのアクセスを高速に行うことができるようになる。
【００７９】
図８および図９を用いて、より詳細に説明する。図８は、ＭＰＥＧ２のロングＧＯＰにおける一例のデータ構造を示す。例えば、図８Ａに示されるように、１つのクリップから１ロングＧＯＰファイルが構成される。ロングＧＯＰファイルは、図８Ｂに示されるように、ビデオＭＸＦ(Material Exchange Format)ファイルＯＰ−Ａｔｏｍと呼ばれる構造を有し、先頭からヘッダパーティションパック（ＨＰＰ）およびヘッダメタデータが配置されてヘッダ情報が構成され、その後ろに、ビデオデータの本体が格納されるエッセンスコンテナが配置される。ファイルの末尾には、フッタパーティションパック（ＦＰＰ）が配置される。
【００８０】
エッセンスコンテナは、図８Ｃに示されるように、ＧＯＰが並んでいる構成となっている。各ＧＯＰの内容は、図８Ｄに示されるように、ピクチャの集合であり、１つのピクチャの内容は、図８Ｅに示されるように、先頭にＫＬ(Key,length)情報が配され、次にＩ、ＰまたはＢピクチャの本体が配され、さらにＫＬ情報が配される。ピクチャの末尾には、必要に応じてフィラーが配され、バイト単位で末尾が揃えられる。
【００８１】
このような構成において、ＭＰＥＧ２のロングＧＯＰでは、各ピクチャの情報量、すなわち図８Ｅに示されるＩ、ＰおよびＢピクチャのサイズの値が不確定となる。したがって、例えばロングＧＯＰビデオファイル中のあるフレームから再生を開始しようとした場合に、ロングＧＯＰビデオファイル中のそのフレームに対応するピクチャの先頭位置を、バイト位置などで指定することができない。
【００８２】
そのため、ロングＧＯＰビデオファイルの先頭位置からバイト単位で示されるファイルアドレス（図８Ｆ参照）を基準として、ロングＧＯＰビデオファイルに含まれる各ピクチャそれぞれについて、ファイルアドレス、サイズおよびピクチャタイプ（Ｉ、ＰまたはＢピクチャ）と、そのピクチャがＧＯＰの先頭のピクチャであるか否かを示す情報を、ピクチャポインタ情報として用意する。このピクチャポインタ情報は、ロングＧＯＰビデオファイル毎に用意される。
【００８３】
なお、図８Ｅに示されるピクチャ末尾に配されるフィラーは、各ピクチャの境界がファイルアドレスで見て例えば２０４８バイトといった所定バイトの倍数になるように調整する。一例として、各ピクチャの境界が光ディスク１０のセクタといった最小アクセス単位の境界に一致するように、フィラーを用いて調整すると、各ピクチャ毎のアクセスが容易となり好ましい。
【００８４】
図９は、ピクチャポインタ情報が記述されるピクチャポインタテーブルのより具体的な例を示す。この例では、ピクチャポインタテーブルは、８バイト単位でデータが記述される。先頭の８バイトは、予約領域およびこのピクチャポインタテーブルのバージョン情報が格納される。以下、１フレームすなわち１ピクチャに対して８バイトが割り当てられ、この８バイトの情報がロングＧＯＰビデオファイルに含まれるピクチャの数だけ並べられる。各ピクチャは、表示フレーム順に並べられている。
【００８５】
各ピクチャ毎のデータについて説明する。先頭の１ビットは、そのピクチャがＧＯＰの先頭のピクチャであるか否かを示すフラグである。例えば、１ＧＯＰ内にＩピクチャが複数枚、存在する場合を想定すると、Ｉピクチャの位置だけではＧＯＰの境界を特定できない。ＧＯＰの境界を特定できないと、ＭＰＥＧ２に規定されるシーケンスヘッダ(Sequence Header)の位置が分からず、デコーダに入力されるストリームの先頭にシーケンスヘッダが無いという状態になるおそれがある。このＧＯＰ先頭のピクチャであるか否かを示すフラグをピクチャ毎に持たせることで、このような状態を回避できる。再生時には、このフラグにもとづきでコーダにストリームを入力させる。
【００８６】
次の２３ビットは、図８Ｅに示される、ピクチャのサイズ情報が格納される。サイズ情報として２３ビットを確保することで、８ＭＢ（メガバイト）までのデータサイズに対応でき、ＭＰＥＧプロファイルの４２２＠ＨＬにも対応可能となる。
【００８７】
次の２ビットでピクチャのタイプが示される。Ｂピクチャについては、参照方向の情報も示される。ピクチャのタイプは、より具体的には、例えば次のように記述される。
００：Ｉピクチャ
１０：Ｐピクチャ
０１：前方（未来）のフレームが参照されて復元されるＢピクチャ。これは、例えばオープンＧＯＰの場合の、ロングＧＯＰビデオファイル先頭のＢピクチャ、または、クローズドＧＯＰの場合の各ＧＯＰの先頭のＢピクチャである。
１１：前方および後方のフレームが参照されて復元されるＢピクチャ。
【００８８】
次の３８ビットは、当該ピクチャのロングＧＯＰビデオファイル内におけるファイルアドレスが示される。ファイルアドレスに３８ビットを割り当てることで、サイズが２５６ＧＢ（ギガバイト）までのロングＧＯＰビデオファイルに対応可能である。例えば、１層で２７ＧＢの記録容量を有する記録層が８層まで形成された光ディスク１０に対応可能である。
【００８９】
このピクチャポインタテーブルは、ピクチャポインタファイルとして、非時系列メタデータと共に例えば記録媒体のＮＲＴ領域に記録される。光ディスク１０がディスクドライブ１１に装填された際に、このＮＲＴ領域に記録された非時系列メタデータとピクチャポインタファイルがディスクドライブ１１により読み出され、光ディスク１０が再生装置１のシステムに対してマウントされる。読み出された非時系列メタデータやピクチャポインタファイルは、例えばＣＰＵ１４が有するＲＡＭに保持される。ＣＰＵ１４は、ＲＡＭに保持されるピクチャポインタテーブルを参照することで、光ディスク１０に記録されるクリップ中の任意のピクチャにアクセスすることができる。
【００９０】
次に、この発明の実施の一形態による再生制御処理について、より詳細に説明する。先ず、図１のステップＳ２で説明した、目標フレームバッファパターンの作成について説明する。最初に、任意の目標再生フレームと、当該目標再生フレームに対して表示順で隣接する前後のフレームとを再生するために必要なフレームバッファサイズを求める。
【００９１】
図１０は、カレントフレーム（例えば目標再生フレーム）に対して表示順で１フレーム後または１フレーム前のフレームをデコードする場合の必要バッファ量の例を示す。図１０において、出力フレーム（カレントフレーム）を「０」で示し、現在より表示順で順方向すなわち未来（後）になるフレームは「＋」を、表示順で逆方向すなわち過去（前）になるフレームは「−」を、それぞれ付して示す。また、図中、「Ｍ」は、間にＢピクチャがある場合の、基準ピクチャから次の基準ピクチャまでのピクチャの移動数、「Ｎ」は、１ＧＯＰ内のピクチャ数を示す。例えば、ＧＯＰが「Ｉ2Ｂ0Ｂ1Ｐ5Ｂ3Ｂ4Ｐ8Ｂ6Ｂ7Ｐ11Ｂ9Ｂ10Ｐ14Ｂ12Ｂ13」の１５枚のピクチャで構成される場合、Ｍ＝３、Ｎ＝１５である。
【００９２】
図１０Ａは、順方向に１フレームだけ再生を進める場合の例を示す。この場合、Ｍ＝３のときに、目標再生フレームが隣り合ったＢピクチャの表示順で前方のＢピクチャの場合に、最もバッファが必要となる。この場合には、次のフレームタイミングで当該目標再生フレームから次のＢピクチャに移動することになる。
【００９３】
すなわち、この場合には、Ｂ4ピクチャおよびＢ5ピクチャは、それぞれＩ3ピクチャおよびＰ6ピクチャを用いてデコードされる。Ｂ5ピクチャのデコードが終了するまで、Ｉ3ピクチャはバッファから破棄できず、且つ、Ｐ6ピクチャはＢ5ピクチャの次に表示されるため、バッファ内に保持される。したがって、Ｍ＋１＝４ピクチャ分のバッファが必要となる。
【００９４】
図１０Ｂは、逆方向に１フレームだけ再生を進める（戻す）場合の例を示す。一般的なＭ＝３およびＮ＝１５のオープンＧＯＰであれば、目標再生フレームがＩ3’ピクチャである場合に、最もバッファが必要となる。この場合には、次のフレームタイミングで当該目標再生フレームから表示順で後方のＢ2’ピクチャに移動することになる。
【００９５】
すなわち、この場合には、Ｂ2’ピクチャをデコードするために、Ｉ3’ピクチャと、Ｂ2’ピクチャの表示順で前のＰ15ピクチャとが必要となり、このＰ15ピクチャをデコードするために、当該Ｐ15ピクチャの属するＧＯＰにおけるＩ3ピクチャ、Ｐ6ピクチャ、Ｐ9ピクチャ、Ｐ12ピクチャが順次、必要となる。したがって、Ｎ／Ｍ＋２＝７ピクチャ分のバッファが必要となる。ここで、Ｎ／Ｍは、ＧＯＰに含まれるＩピクチャおよびＰピクチャの枚数に相当する。
【００９６】
図１０Ｃは、順方向および逆方向の何れかの方向に対する１フレームの移行を考慮した場合の例である。一般的なＭ＝３およびＮ＝１５のオープンＧＯＰであれば、目標再生フレームがＩ3’ピクチャである場合に最もバッファが必要となる。この場合には、次のフレームタイミングで、当該Ｉ3’ピクチャの表示順で次のＢ4’ピクチャまたは表示順で前のＢ2’ピクチャに移動することになる。
【００９７】
すなわち、この場合は、上述の図１０Ａの例と図１０Ｂの例とを組み合わせた状態となり、目標再生フレームであるＩ3’ピクチャの表示順で次のＢ4’ピクチャをデコードするために、当該Ｉ3’ピクチャと、当該Ｉ3’ピクチャの次に現れる基準ピクチャであるＰ6’ピクチャとが必要となる。また、当該Ｉ3’ピクチャの表示順で前のＢ2’ピクチャをデコードするために、当該Ｉ3’ピクチャと、当該Ｉ3’ピクチャの属するＧＯＰの前のＧＯＰにおけるＩ3ピクチャ、Ｐ6ピクチャ、Ｐ9ピクチャ、Ｐ12ピクチャおよびＰ15ピクチャとが順次、必要となる。したがって、Ｎ／Ｍ＋Ｍ＋１＝９ピクチャ分のバッファが必要となる。
【００９８】
このように、目標再生フレームから表示順で隣接する前後のフレームに移動する場合には、９ピクチャ分のバッファが必要となる。
【００９９】
この発明の実施の一形態では、フレームバッファにおいて、目標再生フレームに対して表示順で隣接する前後のピクチャが常に固定遅延で表示可能となるような、バッファの更新パターンを作成する。すなわち、デコードされバッファ上に存在する目標再生フレームに対して表示順で前後に隣接するフレームが常にデコードされバッファ上に存在する状態とする。さらに、逆方向再生を継続するために必要なフレームと、順方向再生を継続するために必要なフレームとを、常に、全てデコードし、バッファ上に溜め込んでおく。このようなバッファ上のパターンを、目標再生フレームを１フレーム毎に移動させた全パターンについて作成する。
【０１００】
この状態において、目標再生フレームが１フレーム分移動し、更新された場合、新たにデコードが必要となるデータは、再生方向が順方向および逆方向によらず常に１フレーム分となる。したがって、再生方向が順方向および逆方向の何れの場合の１倍速以内の再生速度での変速再生が、１倍速デコーダを用いて実現可能となる。
【０１０１】
さらに、この状態において、逆方向の１倍速再生から、順方向の１倍速再生のコマンド速度の間では、固定遅延で再生出力結果を得ることができる。
【０１０２】
図１１は、上述の考えに基づき作成した目標フレームバッファの一例の更新パターンを示す。この図１１の例は、（Ｎ＝１５、Ｍ＝３）であるロングＧＯＰの場合に関する。１ＧＯＰが１５ピクチャ（フレーム）で構成されるため、１５のパターンからなる。図１１中の各行に示されるように、目標再生フレームに対応したフレームがフレームバッファに格納された状態で、目標再生フレームを任意の方向に１フレームずつ移動させた場合に、更新されるフレームがそれぞれ１フレーム分で済み、順方向および逆方向の１倍速以内の可変速再生を、１倍速デコーダを用いて行うことができるようにしている。
【０１０３】
なお、図１１中のＩ、ＰおよびＢは、それぞれＩピクチャ、ＰピクチャおよびＢピクチャに基づくフレームであって、付加される数字は、ＧＯＰ内の表示順を示す。基準となるＧＯＰ（カレントＧＯＰ）に属するピクチャによるフレームは、記号を付加しない。カレントＧＯＰの１つ前のＧＯＰ（ＧＯＰ（−）と呼ぶ）に属するピクチャによるフレームに対して、マイナス記号（−）を付加する。カレントＧＯＰの１つ後のＧＯＰ（ＧＯＰ（＋）と呼ぶ）に属するピクチャによるフレームに対して、プラス記号（＋）を付加する。
【０１０４】
この図１１の更新パターンは、図の上側から下側に向けた方向が順方向の再生を示し、下側から上側に向けた方向が逆方向の再生を示す。すなわち、図１１の上側から下側に１行分進むことで、目標再生フレームが１フレーム進み、下側から上側に１行分進むことで、目標再生フレームが１フレーム戻る。また、この図１１の更新パターンは、循環的とされ、第１行目から目標再生フレームが１フレーム分戻ったときには、第１５行目のフレームバッファの格納パターンに移行される。
【０１０５】
図１１のフレームバッファの更新パターンにおいて、第１行目は、目標再生フレームがフレーム「Ｉ３」の場合のパターンの例である。目標再生フレーム「Ｉ３」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｂ４」およびフレーム「Ｐ６」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｂ２」、フレーム「Ｐ１５−」、フレーム「Ｐ１２−」、フレーム「Ｐ９−」、フレーム「Ｐ６−」およびフレーム「Ｉ３−」である。
【０１０６】
第２行目は、目標再生フレームがフレーム「Ｂ４」の場合のパターンの例である。目標再生フレーム「Ｂ４」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｂ５」およびフレーム「Ｐ６」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｉ３」、フレーム「Ｐ１５−」、フレーム「Ｐ１２−」、フレーム「Ｐ９−」、フレーム「Ｐ６−」およびフレーム「Ｉ３−」である。
【０１０７】
第３行目は、目標再生フレームがフレーム「Ｂ５」の場合のパターンの例である。目標再生フレーム「Ｂ５」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｐ６」およびフレーム「Ｐ９」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｂ４」、フレーム「Ｉ３」、フレーム「Ｐ１２−」、フレーム「Ｐ９−」、フレーム「Ｐ６−」およびフレーム「Ｉ３−」である。
【０１０８】
第４行目は、目標再生フレームがフレーム「Ｐ６」の場合のパターンの例である。目標再生フレーム「Ｐ６」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｂ７」およびフレーム「Ｐ９」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｂ５」、フレーム「Ｉ３」、フレーム「Ｐ１２−」、フレーム「Ｐ９−」、フレーム「Ｐ６−」およびフレーム「Ｉ３−」である。
【０１０９】
第５行目は、目標再生フレームがフレーム「Ｂ７」の場合のパターンの例である。目標再生フレーム「Ｂ７」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｂ８」およびフレーム「Ｐ９」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｐ６」、フレーム「Ｉ３」、フレーム「Ｐ１２−」、フレーム「Ｐ９−」、フレーム「Ｐ６−」およびフレーム「Ｉ３−」である。
【０１１０】
第６行目は、目標再生フレームがフレーム「Ｂ８」の場合のパターンの例である。目標再生フレーム「Ｂ８」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｐ９」およびフレーム「Ｐ１２」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｂ７」、フレーム「Ｐ６」、フレーム「Ｉ３」、フレーム「Ｐ９−」、フレーム「Ｐ６−」およびフレーム「Ｉ３−」である。
【０１１１】
第７行目は、目標再生フレームがフレーム「Ｐ９」の場合のパターンの例である。目標再生フレーム「Ｐ９」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｂ１０」およびフレーム「Ｐ１２」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｐ６」、フレーム「Ｉ３」、フレーム「Ｐ９−」、フレーム「Ｐ６−」およびフレーム「Ｉ３−」である。
【０１１２】
第８行目は、目標再生フレームがフレーム「Ｂ１０」の場合のパターンの例である。目標再生フレーム「Ｂ１０」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｂ１１」およびフレーム「Ｐ１２」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｐ９」、フレーム「Ｐ６」、フレーム「Ｉ３」、フレーム「Ｐ９−」、フレーム「Ｐ６−」およびフレーム「Ｉ３−」である。
【０１１３】
第９行目は、目標再生フレームがフレーム「Ｂ１１」の場合のパターンの例である。目標再生フレーム「Ｂ１１」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｐ１２」およびフレーム「Ｐ１５」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｂ１０」、フレーム「Ｐ９」、フレーム「Ｐ６」、フレーム「Ｉ３」、フレーム「Ｐ６−」およびフレーム「Ｉ３−」である。
【０１１４】
第１０行目は、目標再生フレームがフレーム「Ｐ１２」の場合のパターンの例である。目標再生フレーム「Ｐ１２」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｂ１３」およびフレーム「Ｐ１５」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｂ１１」、フレーム「Ｐ９」、フレーム「Ｐ６」、フレーム「Ｉ３」、フレーム「Ｐ６−」およびフレーム「Ｉ３−」である。
【０１１５】
第１１行目は、目標再生フレームがフレーム「Ｂ１３」の場合のパターンの例である。目標再生フレーム「Ｂ１３」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｂ１４」およびフレーム「Ｐ１５」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｐ１２」、フレーム「Ｐ９」、フレーム「Ｐ６」、フレーム「Ｉ３」、フレーム「Ｐ６−」およびフレーム「Ｉ３−」である。
【０１１６】
第１２行目は、目標再生フレームがフレーム「Ｂ１４」の場合のパターンの例である。目標再生フレーム「Ｂ１４」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｐ１５」およびフレーム「Ｉ３＋」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｂ１３」、フレーム「Ｐ１２」、フレーム「Ｐ９」、フレーム「Ｐ６」、フレーム「Ｉ３」およびフレーム「Ｉ３−」である。
【０１１７】
第１３行目は、目標再生フレームがフレーム「Ｐ１５」の場合のパターンの例である。目標再生フレーム「Ｐ１５」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｂ１＋」およびフレーム「Ｉ３＋」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｂ１４」、フレーム「Ｐ１２」、フレーム「Ｐ９」、フレーム「Ｐ６」、フレーム「Ｉ３」およびフレーム「Ｉ３−」である。
【０１１８】
第１４行目は、目標再生フレームがフレーム「Ｂ１＋」の場合のパターンの例である。目標再生フレーム「Ｂ１＋」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｂ２＋」およびフレーム「Ｉ３＋」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｐ１５」、フレーム「Ｐ１２」、フレーム「Ｐ９」、フレーム「Ｐ６」、フレーム「Ｉ３」およびフレーム「Ｉ３−」である。
【０１１９】
第１５行目は、目標再生フレームがフレーム「Ｂ２＋」の場合のパターンの例である。目標再生フレーム「Ｂ２＋」から順方向に１フレーム進むために必要とされるフレームは、フレーム「Ｉ３＋」およびフレーム「Ｐ６＋」である。また、目標再生フレームから逆方向に１フレーム戻るために必要とされるフレームは、フレーム「Ｂ１＋」フレーム「Ｐ１５」、フレーム「Ｐ１２」、フレーム「Ｐ９」、フレーム「Ｐ６」およびフレーム「Ｉ３」である。
【０１２０】
このように、図１１に一例を示すフレームバッファの更新パターンでは、各フレーム毎の更新パターン間で、１フレーム分のみが更新されるようになっている。幾つかの例を挙げて、より具体的に説明する。
【０１２１】
第１の例として、目標再生フレームがＰピクチャによるフレーム「Ｐ６」の場合について説明する。この場合、順方向および逆方向について１倍速以内の再生速度範囲においては、当該目標再生フレームの１フレームタイミング後に新たな目標再生フレームとなる可能性のあるフレームは、当該フレーム「Ｐ６」と、当該フレーム「Ｐ６」に対して表示順で前後に隣接するフレーム「Ｂ５」およびフレーム「Ｂ７」とである。
【０１２２】
目標再生フレームがフレーム「Ｐ６」の状態において、上述したような、目標再生フレームに基づき作成された目標フレームバッファパターンに従いデコードされたフレームがフレームバッファに格納された状態では（図１１の第４行目のパターン参照）、目標再生フレーム「Ｐ６」と、その前後のフレーム「Ｂ５」およびフレーム「Ｂ７」は、それぞれ既にデコードされた状態でフレームバッファに格納されている。
【０１２３】
この状態から目標再生フレームがフレーム「Ｂ５」またはフレーム「Ｂ７」に移行された場合、移行された目標再生フレームに対する新たな目標フレームバッファパターンに基づいて、新たに必要となるフレームをデコードされた状態でフレームバッファに格納していく。
【０１２４】
これらのデータが格納されたフレームバッファの他の領域は、直前のデータが保持される。すなわち、図１１の例では、第４行目に示されるように、目標再生フレームがフレーム「Ｐ６」のときは、フレームバッファに、当該フレーム「Ｐ６」と、当該フレーム「Ｐ６」と同じＧＯＰに属するフレーム「Ｉ３」、フレーム「Ｐ９」、フレーム「Ｂ５」およびフレーム「Ｂ７」、ならびに、当該フレーム「Ｐ６」が属するＧＯＰに対して１つ前のＧＯＰに属するフレーム「Ｉ３−」、フレーム「Ｐ６−」、フレーム「Ｐ９−」およびフレーム「Ｐ１２−」が格納される。
【０１２５】
この目標再生フレームがフレーム「Ｐ６」の場合、順方向に１フレーム分、目標再生フレームが移行すると、新たな目標再生フレームがフレーム「Ｂ７」となる。また、この新たな目標再生フレームに対して１フレームタイミング後にさらに新たな目標再生フレームとなる可能性があるフレームは、フレーム「Ｂ７」と、当該フレーム「Ｂ７」に対して表示順で前後に隣接するフレーム「Ｐ６」およびフレーム「Ｂ８」となる。
【０１２６】
なお、再生速度が順方向および逆方向に１倍速以内の場合、同一のフレームが２フレームタイミングで連続して出力される場合がある。この場合、次のフレームタイミングに移っても、目標再生フレームが変化しない。
【０１２７】
これらのうち、フレーム「Ｐ６」は、現在の目標再生フレームであるため、既にフレームバッファ上に存在している。また、フレーム「Ｂ８」をデコードするためには、フレーム「Ｐ６」およびフレーム「Ｐ９」が必要となる。フレーム「Ｐ６」およびフレーム「Ｐ９」は、それぞれフレーム「Ｂ７」をデコードするために用いられているので、既にフレームバッファ上に存在している。フレーム「Ｂ８」がこれらフレーム「Ｐ６」および「Ｐ９」を用いてデコードされる。
【０１２８】
一方、目標再生フレームがフレーム「Ｂ７」に移行した場合、目標再生フレームがフレーム「Ｐ６」の状態における逆方向側の表示順で隣接フレームであったフレーム「Ｂ５」は、不要となるため破棄される。フレームバッファ上の、この破棄されたフレーム「Ｂ５」の領域に、新たにデコードされたフレーム「Ｂ８」が格納され、フレームバッファが更新される。
【０１２９】
逆方向に１フレーム分、再生が戻されると、新たな目標再生フレームがフレーム「Ｂ５」となり、この新たな目標再生フレームに対して１フレームタイミング後にさらに新たな目標再生フレームとなる可能性のあるフレームは、フレーム「Ｂ５」と、フレーム「Ｂ４」およびフレーム「Ｐ６」とである。フレーム「Ｐ６」は、現在の目標再生フレームであるため、既にフレームバッファ上に存在している。また、フレーム「Ｂ４」をデコードするためには、フレーム「Ｉ３」およびフレーム「Ｐ６」が必要となる。フレーム「Ｉ３」を、フレームバッファ上に保持する。フレーム「Ｂ４」がこれらフレーム「Ｉ３」および「Ｐ６」を用いてデコードされる。
【０１３０】
一方、目標再生フレームがフレーム「Ｐ６」からフレーム「Ｂ５」に移行した場合、目標再生フレームが「Ｐ６」の状態における順方向側の隣接フレームであったフレーム「Ｂ７」は、不要となるため、破棄される。フレームバッファ上の、この破棄されたフレーム「Ｂ７」の領域に、新たにデコードされたフレーム「Ｂ４」が格納され、フレームバッファが更新される。
【０１３１】
このように、目標再生フレームがフレーム「Ｐ６」の状態から順方向に１フレーム分進んだ場合、フレームの更新は、フレーム「Ｂ５」からフレーム「Ｂ８」への１フレーム分のみ、行われる。目標再生フレームがフレーム「Ｐ６」の状態から逆方向に１フレーム分戻された場合も、フレームの更新は、フレーム「Ｂ７」からフレーム「Ｂ４」への１フレーム分のみ、行われる。
【０１３２】
第２の例として、目標再生フレームがＢピクチャによるフレーム「Ｂ７」の場合について説明する。この場合、順方向および逆方向について１倍速以内の再生速度範囲においては、当該目標再生フレームの１フレームタイミング後に新たな目標再生フレームとなる可能性のあるフレームは、当該フレーム「Ｂ７」と、当該フレーム「Ｂ７」に対して表示順で前後に隣接するフレーム「Ｐ６」および「Ｂ８」とである。
【０１３３】
目標再生フレームがフレーム「Ｂ７」の状態において、上述したような、目標再生フレームに基づき作成された目標フレームバッファパターンに従いデコードされたフレームがフレームバッファに格納された状態では（図１１の第５行目のパターン参照）、目標再生フレーム「Ｂ７」と、その前後のフレーム「Ｐ６」およびフレーム「Ｂ８」は、それぞれ既にデコードされた状態でフレームバッファに格納されている。
【０１３４】
この状態から目標再生フレームがフレーム「Ｐ６」またはフレーム「Ｂ８」に移行された場合、移行された目標再生フレームに対する新たな目標フレームバッファパターンに基づいて、新たに必要となるフレームをデコードされた状態でフレームバッファに格納していく。
【０１３５】
これらのデータが格納されたフレームバッファの他の領域は、直前のデータが保持される。すなわち、図１１の例では、第５行目に示されるように、目標再生フレームがフレーム「Ｂ７」のときには、フレームバッファに、当該フレーム「Ｂ７」と、当該フレーム「Ｂ７」と同じＧＯＰに属するフレーム「Ｉ３」、フレーム「Ｐ９」およびフレーム「Ｂ８」、ならびに、当該フレーム「Ｂ７」が属するＧＯＰに対して１つ前のＧＯＰに属するフレーム「Ｉ３−」、フレーム「Ｐ６−」、フレーム「Ｐ９−」およびフレーム「Ｐ１２−」が格納される。
【０１３６】
この目標再生フレームがフレーム「Ｂ７」の場合、順方向に１フレーム分、目標再生フレームが移行すると、新たな目標再生フレームがフレーム「Ｂ８」になる。また、この新たな目標再生フレームに対して１フレームタイミング後にさらに新たな目標再生フレームとなる可能性があるフレームは、当該フレーム「Ｂ８」と、当該フレーム「Ｂ８」に対して表示順で前後に隣接するフレーム「Ｂ７」およびフレーム「Ｐ９」とである。
【０１３７】
これらのうち、フレーム「Ｂ７」は、現在の目標再生フレームであるため、既にフレームバッファ上に存在している。また、フレーム「Ｂ８」をデコードするためには、フレーム「Ｐ６」およびフレーム「Ｐ９」が必要となる。フレーム「Ｐ６」およびフレーム「Ｐ９」は、それぞれフレーム「Ｂ７」をデコードするために必要なフレームであるので、既にフレームバッファ上に存在している。フレーム「Ｂ８」がこれらフレーム「Ｐ６」および「Ｐ９」を用いてデコードされる。また、フレーム「Ｐ９」も、既にフレームバッファ上に存在している。
【０１３８】
この場合には、目標再生フレームがフレーム「Ｂ７」の状態における逆方向側の表示順で隣接フレームであったフレーム「Ｐ６」は、フレーム「Ｂ８」をデコードするために用いられるため、破棄されない。さらに順方向に１フレーム、再生が進んだ際に用いられるフレーム「Ｐ１２」が、フレーム「Ｐ９」を用いてデコードされる。また、バッファメモリ内に存在する最も前のＧＯＰに属するフレームのうち、バッファメモリ内に存在し最も表示順で新しいフレームであるフレーム「Ｐ１２−」を破棄し、デコードされたフレーム「Ｐ１２」を格納する。
【０１３９】
逆方向に１フレーム分、再生が戻されると、新たな目標再生フレームがフレーム「Ｐ６」となり、この新たな目標再生フレームに対して１フレームタイミング後にさらに新たな目標再生フレームとなる可能性のあるフレームは、フレーム「Ｐ６」と、フレーム「Ｂ５」およびフレーム「Ｂ７」とである。フレーム「Ｂ７」は、現在の目標再生フレームであるため、既にフレームバッファ上に存在している。また、フレーム「Ｂ５」をデコードするためには、フレーム「Ｉ３」およびフレーム「Ｐ６」が必要となる。フレーム「Ｉ３」をフレームバッファ上に保持する。フレーム「Ｂ５」がこれらフレーム「Ｉ３」およびフレーム「Ｐ６」を用いてデコードされる。
【０１４０】
一方、目標再生フレームがフレーム「Ｂ７」からフレーム「Ｐ６」に移行した場合、目標再生フレームが「Ｂ７」の状態における順方向側の隣接フレームであったフレーム「Ｂ８」は、不要となるため、破棄される。フレームバッファ上の、この破棄されたフレーム「Ｂ８」の領域に、新たにデコードされたフレーム「Ｂ５」が格納され、フレームバッファが更新される。
【０１４１】
このように、目標再生フレームがフレーム「Ｂ７」の状態から順方向に１フレーム進んだ場合、フレームの更新は、フレーム「Ｐ１２−」からフレーム「Ｐ１２」への１フレーム分のみ、行われる。目標再生フレームがフレーム「Ｂ７」の状態から逆方向に１フレーム分戻された場合も、フレームの更新は、フレーム「Ｂ８」からフレーム「Ｂ５」への１フレーム分のみ、行われる。
【０１４２】
第３の例として、目標再生フレームがＩピクチャによるフレーム「Ｉ３」の場合について説明する。この場合、順方向および逆方向について１倍速以内の再生速度範囲においては、当該目標再生フレームの１フレームタイミング後に新たな目標再生フレームとなる可能性のあるフレームは、当該フレーム「Ｉ３」と、当該フレーム「Ｉ３」に対して表示順で前後に隣接するフレーム「Ｂ２」およびフレーム「Ｂ４」とである。
【０１４３】
目標再生フレームがフレーム「Ｉ３」の状態において、上述したような、目標再生フレームに基づき作成された目標フレームバッファパターンに従いデコードされたデータがフレームバッファに格納された状態では（図１１の第１行目のパターン参照）、目標再生フレーム「Ｉ３」と、その前後のフレーム「Ｂ２」およびフレーム「Ｂ４」は、それぞれ既にデコードされた状態でフレームバッファに格納されている。
【０１４４】
この状態から目標再生フレームがフレーム「Ｂ２」またはフレーム「Ｂ４」に移行された場合、移行された目標再生フレームに対する新たな目標フレームバッファパターンに基づいて、新たに必要となるフレームをデコードされた状態でフレームバッファに格納していく。
【０１４５】
これらのデータが格納されたフレームバッファの他の領域は、直前のデータが保持される。すなわち、図１１の例では、第１行目に示されるように、目標再生フレームが「Ｉ３」のときには、フレームバッファに、当該フレーム「Ｉ３」と、当該フレーム「Ｉ３」と同じＧＯＰに属する、フレーム「Ｐ６」、フレーム「Ｂ２」およびフレーム「Ｂ４」、ならびに、当該フレーム「Ｉ３」が属するＧＯＰに対して１つ前のＧＯＰに属するフレーム「Ｉ３−」、フレーム「Ｐ６−」、フレーム「Ｐ９」、フレーム「Ｐ１２−」およびフレーム「Ｐ１５」とが格納される。
【０１４６】
目標再生フレームがフレーム「Ｉ３」の場合、順方向に１フレーム分、目標再生フレームが移行すると、新たな目標再生フレームがフレーム「Ｂ４」になる。また、この新たな目標再生フレームに対して１フレームタイミング後にさらに新たな目標再生フレームとなる可能性があるフレームは、当該フレーム「Ｂ４」と、当該フレームに対して表示順で前後に隣接するフレーム「Ｉ３」およびフレーム「Ｂ５」とである。
【０１４７】
これらのうち、フレーム「Ｉ３」は、現在の目標再生フレームであるため、既にフレームバッファ上に存在している。また、フレーム「Ｂ５」をデコードするためには、フレーム「Ｉ３」およびフレーム「Ｐ６」が必要となる。フレーム「Ｐ６」は、フレーム「Ｂ４」をデコードするために用いられているので、既にフレームバッファ上に存在している。フレーム「Ｂ５」がこれらフレーム「Ｉ３」および「Ｐ６」を用いてデコードされる。
【０１４８】
この場合には、目標再生フレームが「Ｉ３」の状態における逆方向側の目標再生フレームであるフレーム「Ｂ２」は、不要となるため、破棄される。フレームバッファ上の、この破棄されるフレーム「Ｂ２」の領域にデコードされたフレーム「Ｂ５」が格納され、フレームバッファが更新される。
【０１４９】
逆方向に１フレーム分、再生が戻されると、新たな目標再生フレームがフレーム「Ｂ２」となり、この新たな目標再生フレーム対して１フレームタイミング後に新たな目標再生フレームとなる可能性のあるフレームは、フレーム「Ｂ２」と、フレーム「Ｂ１」およびフレーム「Ｉ３」とである。フレーム「Ｉ３」は、現在の目標再生フレームであるため、既にフレームバッファ上に存在している。また、フレーム「Ｂ１」をデコードするためには、フレーム「Ｉ３」と、フレーム「Ｉ３」が属するＧＯＰの１つ前のＧＯＰに属するフレーム「Ｐ１５−」が必要となる。フレーム「Ｂ１」がこれらフレーム「Ｐ１５−」および「Ｉ３」を用いてデコードされる。
【０１５０】
一方、目標再生フレームがフレーム「Ｉ３」からフレーム「Ｂ２」に移行した場合、目標再生フレームがフレーム「Ｉ３」の状態における順方向の隣接フレームであったフレーム「Ｂ４」は、不要となるため、破棄される。フレームバッファ上の、この破棄されたフレーム「Ｂ４」の領域に、新たにデコードされたフレーム「Ｂ１」が格納され、フレームバッファが更新される。
【０１５１】
このように、目標再生フレームがフレーム「Ｉ３」の状態から順方向に１フレーム進んだ場合、フレームの更新は、フレーム「Ｂ２」からフレーム「Ｂ５」への１フレーム分のみ、行われる。目標再生フレームがフレーム「Ｉ３」の状態から逆方向に１フレーム分戻された場合も、フレームの更新は、フレーム「Ｂ４」からフレーム「Ｂ１」への１フレーム分のみ、行われる。
【０１５２】
なお、上述したように、目標再生フレームが他のフレームに移行される際には、バッファメモリに格納された１フレームが破棄され、破棄されたフレーム領域に新たな１フレームがデコードされて格納され、バッファメモリが更新される。このとき、バッファメモリから破棄するフレームを、次のルールに基づき決めることができる。
（１）目標再生フレームおよび表示順で目標再生フレームに隣接するフレーム以外のＢピクチャによるフレームは、破棄する。
（２）上述の（１）のルールに従い破棄するＢピクチャによるフレームが存在しなかった場合、バッファメモリ上に存在する、下記（２ａ）または（２ｂ）の条件を満たすＩまたはＰピクチャによるフレームを破棄する。
（２ａ）順方向への目標再生フレーム移行の場合、目標再生フレームが存在するＧＯＰから逆方向に最も離れたＧＯＰにおいて、そのＧＯＰに属する最後尾のＩまたはＰピクチャ。
（２ｂ）逆方向への目標再生フレーム移行の場合、目標再生フレームが存在するＧＯＰから順方向に最も離れたＧＯＰにおいて、そのＧＯＰに属する最後尾のＩまたはＰピクチャ。
【０１５３】
上述のように、この発明の実施の一形態によるバッファメモリの更新パターンに従いバッファメモリ上にデータを溜め込んでおけば、現在の目標再生フレームがＩピクチャによるフレーム、ＰピクチャによるフレームおよびＢピクチャによるフレームの何れであっても、任意の方向への１フレーム分の移動に対してバッファメモリ上で行進されるデータが１フレーム分のみで済む。したがって、順方向および逆方向の１倍速以内の可変速再生を、１倍速デコーダを用いて固定遅延で実行することができる。
【０１５４】
なお、上述では、現在の目標再生フレームとして、ＧＯＰを構成するＩピクチャ、ＰピクチャおよびＢピクチャのそれぞれについて一例ずつ例を挙げて説明を行ったが、説明を省略した他のフレームが現在の目標再生フレームの場合でも、同様にして、任意の方向への１フレーム分の移動に対して、バッファメモリ上の１フレーム分のデータのみが更新される。
【０１５５】
次に、上述したような目標フレームバッファのパターンの一例の作成方法について、図１２のフローチャートを用いて説明する。また、以下では、目標とされるフレーム（カレントフレームと呼ぶ）がＢピクチャによるフレームであるものとして説明する。
【０１５６】
先ず、ステップＳ１０で、カレントフレームが属するカレントＧＯＰのＩピクチャ（Ｉ0）を取得する。図１３Ａに一例が示されるように、カレントフレームに対応するピクチャから記録媒体上の順序で逆方向に向けて、Ｉピクチャを検索する。なお、この段階では、目標フレームバッファパターンのフレームは、一つも確定していない（図１４Ａ参照）。
【０１５７】
カレントＧＯＰの先頭Ｉピクチャ（Ｉ0）ピクチャが取得されると、ステップＳ１１で、カレントフレームに対応するピクチャから記録媒体上の順序で順方向に向けて、カレントフレームより２フレーム進んだ位置以降のＩピクチャまたはＰピクチャ（Ｐ0）を検索する（図１３Ｂ参照）。この段階では、目標フレームバッファパターンのフレームは、一つも確定していない（図１４Ｂ参照）。
【０１５８】
ステップＳ１２で、上述したステップＳ１０およびステップＳ１１で取得されたピクチャ（Ｉ0）からピクチャ（Ｐ0）までのＩおよび／またはＰピクチャを記録媒体から検索する。例えば、図１３Ｃに一例が示されるように、ステップＳ１０で検索されたピクチャ（Ｉ0）を目標フレームバッファパターンに用いるフレームとして確定する。さらに、ピクチャ（Ｉ0）から記録媒体上の順序で順方向に向けて、次のＰピクチャ（Ｐ）が検索される。検索されたＰピクチャを、目標フレームバッファパターンに用いるフレームとして確定する。このように、記録媒体から順次、検索されたＰまたはＩピクチャに基づき、目標フレームバッファパターンに用いる、カレントＧＯＰのフレームが順次、確定される（図１４Ｃ参照）。
【０１５９】
ステップＳ１２で、カレントＧＯＰのＩおよびＰピクチャによるフレームが目標フレームバッファパターンに用いるフレームとして確定されると、ステップＳ１３で、記録媒体上の順序で、カレントフレームの１つ前のフレームからカレントフレームの１つ後のフレームまでの間に存在するＢピクチャが検索される（図１３Ｄ参照）。検索されたＢピクチャによるフレームは、目標フレームバッファパターンに用いられる、カレントＧＯＰのフレームとして確定される（図１４Ｄ参照）。
【０１６０】
すなわち、上述したステップＳ１１およびステップＳ１２で、カレントフレームの１つ前のフレームからカレントフレームの１つ後のフレームまでの間に存在するＢピクチャをデコードするために用いられるＩおよび／またはＰピクチャによるフレームが、目標フレームバッファパターンに用いられるフレームとして確定されている。ステップＳ１３では、これら確定された、Ｉおよび／またはＰピクチャによるフレームを用いてデコードされるＢピクチャによるフレームが、目標フレームバッファパターンに用いるフレームとして確定される。
【０１６１】
ステップＳ１３までの処理で、カレントＧＯＰの、目標フレームバッファパターンに用いるフレームが全て確定されると、ステップＳ１４で、カレントＧＯＰの１つ前のＧＯＰ内の先頭Ｉピクチャ（Ｉ-1）が検索される（図１３Ｅ参照）。例えば、カレントＧＯＰの先頭のＩピクチャ（Ｉ0）を起点として、記録媒体上の順序で逆方向に向けてＩピクチャが検索され、検索されたＩピクチャ（Ｉ-1）に基づき、記録媒体上の順序で順方向に、Ｐピクチャが検索される（図１３Ｆ参照）。そして、検索されたカレントＧＯＰの１つ前のＧＯＰのＩおよび／またはＰピクチャによるフレームが、目標フレームバッファパターンに用いるフレームとして確定される（図１４Ｆ参照）。
【０１６２】
上述のステップＳ１４からステップＳ１５までの処理は、バッファメモリが埋められるまで繰り返される（ステップＳ１６）。
【０１６３】
なお、記録媒体上に記録されたピクチャの位置やタイプ（Ｉピクチャ、ＰピクチャおよびＢピクチャ）は、図９を用いて説明したピクチャポインタファイルを参照することで知ることができる。例えばシステムやより上位のシステムから、あるフレームの再生が指示されると、ＣＰＵ１４は、再生を指示されたフレームを目標再生フレームとし、当該目標再生フレームが属するＧＯＰをカレントＧＯＰとしてピクチャポインタファイルを検索し、カレントＧＯＰのＩピクチャの位置を取得する。ピクチャポインタファイルには、上述のように、ピクチャタイプ、そのピクチャがＧＯＰの先頭のピクチャであるか否かを示すフラグ、ピクチャのサイズ情報、先頭アドレスが記述されているので、これらの情報に基づき記録媒体上の所望のピクチャを検索することが可能となっている。
【０１６４】
目標再生フレームに基づき目標フレームバッファパターンが確定し、確定された目標フレームバッファパターンに従いフレームバッファがデコードされたフレームで埋められると、図１１を用いて説明したような動作により、再生指示に対して所定の固定遅延で、順方向および逆方向の１倍速以内の再生が行われる。
【０１６５】
なお、ここでは、目標再生フレームがＢピクチャであるものとして説明したが、上述の図１２のフローチャートで説明した処理は、カレントフレームがＩピクチャおよびＰピクチャの場合にも同様にして適用できる。
【０１６６】
また、システムやより上位のシステムから再生を指示されたフレームを目標再生フレームとして、上述の図１２のフローチャートに従い、当該目標再生フレームに対応した目標フレームバッファパターンを作成する。この処理を、例えば目標再生フレームが指示される毎に行う。最初の目標再生フレームの指示に基づき、ＧＯＰ内の全てのフレームについて作成してもよい。作成された目標フレームバッファパターンは、例えばＲＡＭ３６に記憶される。
【０１６７】
これに限らず、再生するクリップのＧＯＰの構成が予め分かっていれば、上述の図１２のフローチャートに示される処理を、ＧＯＰを構成する各ピクチャに対して行って、上述した図１１のようなフレームバッファの更新パターンを予め作成しておくことも可能である。また、再生装置１において適用可能なＧＯＰの構成が決められていれば、予め更新パターンを作成し、ＲＯＭ３５に記憶させておくことも可能である。
【０１６８】
ＣＰＵ１４は、操作部１５に対する、順方向への１倍速以内または逆方向への１倍速以内の再生指示に応じて、出力フレームに対応する更新パターンを参照し、フレームタイミング毎に光ディスク１０から読み出すピクチャを指示し、フレームバッファの更新を行う。
【０１６９】
次に、フレームバッファの更新パターンに基づく再生制御動作について説明する。再生制御は、フレームタイミングで同期を取られて、フレーム毎に順次、行われる。図１５は、この発明の実施の一形態による同期制御を概略的に示す。この図１５の例では、３フレームを周期として、１フレーム分のビデオデータのデコードが行われると共に、このデコードに同期して、フレームバッファ上の１フレーム分のビデオデータが出力される。
【０１７０】
先ず、第１フレーム目では、現在フレームバッファに格納されているフレームの情報であって、ＣＰＵ１４により取得されるフレームバッファ情報と、ディスクドライブ１１におけるリード情報と、目標速度情報とから、目標再生フレームが確定される（ステップＳ２０）。リード情報は、光ディスク１０から既に読み出され、ディスクドライブ１１のキャッシュメモリ１２に溜め込まれているピクチャの情報である。また、目標速度情報は、操作部１５に対する操作や、より上位のアプリケーションなどからのコマンドにより、ＣＰＵ１４に対して供給される、再生速度および方向を示す情報である。
【０１７１】
目標再生フレームが確定されると、デコーダ２２に転送するピクチャが確定される（ステップＳ２１）。すなわち、図１１を用いて説明したフレームバッファの更新パターンに基づき、目標再生フレームの確定に伴いデコードすべきピクチャが確定される。
【０１７２】
例えば、図１１の第４行目の例でいうと、再生方向が順方向であれば、現在の目標再生フレーム「Ｐ６」に対して、新たな目標再生フレームは、フレーム「Ｂ７」またはフレーム「Ｐ６」の何れかに確定される。新たな目標再生フレームがフレーム「Ｂ７」およびフレーム「Ｐ６」の何方に確定されるかは、目標速度情報や、指示のタイミングなどに基づき一意的に決められる。ここでは、新たな目標再生フレームがフレーム「Ｂ７」に確定されたものとして説明する。
【０１７３】
さらに、第４行目のフレームバッファ情報と、新たな目標再生フレームが目標再生フレームとされているフレームバッファ情報とが比較され、新たにデコードされる必要があるフレームと、不要となるフレームとが抽出される。新たな目標再生フレームがフレーム「Ｂ７」であるこの例では、第４行目のフレームバッファ情報と次の第５行目のフレームバッファ情報とが比較され、フレーム「Ｂ５」が不要となると共に、フレーム「Ｂ８」がデコードされている必要があることが分かる。
【０１７４】
ステップＳ２１で転送するピクチャが確定されると、次の第２フレーム目のタイミングで、当該ピクチャがデコーダ２２に対して転送される（ステップＳ２２）。例えば、ＣＰＵ１４は、ディスクドライブ１１に対して、転送が確定されたピクチャを光ディスク１０から読み出すように要求する。この要求に応じて、ディスクドライブ１１により、光ディスク１０からピクチャ（上述の例では、フレーム「Ｂ８」に対応するピクチャ）が読み出される。読み出されたピクチャがデコーダ２２に転送されると共に、読み出されたピクチャをデコードするために必要な他のフレームがある場合は、フレームバッファから当該他のフレームが読み出され、デコーダ２２に転送される。
【０１７５】
フレーム「Ｂ８」をデコードするこの例では、フレーム「Ｂ８」に対応するピクチャと、フレーム「Ｂ８」をデコードするための他のフレーム「Ｐ６」および「Ｐ９」とがデコーダ２２に転送される。
【０１７６】
なお、実際には、転送が確定されたピクチャの転送は、上述したように、ディスクドライブ１１が有するキャッシュメモリ１２に対してアクセスされてなされ、キャッシュメモリ１２からデコーダ２２に対して、ＤＭＡ(Direct Memory Access)転送によりＣＰＵ１４を介さないで行われる。
【０１７７】
ディスクドライブ１１からデコーダ２２へのピクチャの転送は、次の第２フレーム目のタイミングに同期して行われる（ステップＳ２２）。また、ステップＳ２１での転送ピクチャの確定に伴い、当該ピクチャに対するデコード情報が確定される（ステップＳ２３）。例えば、確定された転送ピクチャのヘッダ情報から取り出されたデコードに必要なパラメータや、デコードに必要な他のフレームの情報がデコード情報として確定される。これら確定されたデコード情報は、デコーダ２２に渡される。
【０１７８】
デコーダ２２は、ステップＳ２３で転送されたデコード情報に基づき、ステップＳ２２で転送されたピクチャのデコードを、次の第３フレーム目のタイミングに同期して開始する（ステップＳ２４）。デコードされたピクチャ（フレーム）は、フレームバッファの所定のバンクに書き込まれ、フレームバッファが更新される。上述の図１１の第４行目の例では、バッファメモリ上のフレーム「Ｂ５」が書き込まれているバンクに対して、デコードされたフレーム「Ｂ８」のデータが上書きされる（図１１の第５行目参照）。
【０１７９】
一方、上述したステップＳ２０で目標再生フレームが確定されると、出力するビデオデータの情報が確定される（ステップＳ２５）。上述の図１１の第４行目の例では、出力ビデオデータとしてフレーム「Ｐ６」が確定される。この確定された出力ビデオデータの情報が出力データ制御部２３に渡される。出力データ制御部２３では、渡された情報に基づき、第３フレーム目の開始タイミングまでに、ビデオ出力の設定を行う（ステップＳ２６）。そして、この設定に基づき、第３フレーム目に同期して、フレーム「Ｐ６」が出力される（ステップＳ２７）。
【０１８０】
なお、１倍速以下の順方向の再生は、例えば、上述したステップＳ２０において、上位のアプリケーションからなど供給された再生速度情報に応じて、目標再生フレームを次のフレームに進めるか否かを制御することで可能である。一例として、順方向に１／２倍速で再生を行う場合には、出力するフレームを２フレームタイミング毎に１フレームだけ更新すればよい。これは、例えば、２フレームに１回の割合で、目標再生フレームを更新することで可能である。目標再生フレームが更新されなければ、直前の処理と同一のフレームバッファのパターンに基づき処理が行われることになるため、直前のフレームタイミングと同一のフレームが出力されることになる。このとき、ディスクドライブ１による光ディスク１０に対するアクセス動作や、デコーダ２２のデコード動作なども停止するようにすると、好ましい。
【０１８１】
上述では、再生方向が順方向の場合の処理について説明したが、再生方法が逆方向の場合にも、同様の処理が行われる。第１フレーム目で、フレームバッファ情報と、リード情報と、目標速度情報とから、目標再生フレームが確定される（ステップＳ２０）。目標再生フレームが確定されると、デコーダ２２に転送するピクチャが確定される（ステップＳ２１）。図１１の第４行目の例でいうと、再生方向が逆方向なので、目標再生フレームがフレーム「Ｂ５」またはフレーム「Ｐ６」の何れかに確定される。ここでは、目標再生フレームがフレーム「Ｂ５」に確定されるものとする。さらに、第４行目のフレームバッファ情報と、目標再生フレームが出力フレームとされている第３行目のフレームバッファ情報とが比較され、フレーム「Ｂ７」が不要になると共に、フレーム「Ｂ４」がデコードされている必要があることが分かる。
【０１８２】
ステップＳ２１で転送するピクチャが確定されると、次の第２フレーム目のタイミングに同期して、当該ピクチャがデコーダ２２に対して転送される（ステップＳ２２）。このとき、当該ピクチャをデコードするために必要な他のピクチャがある場合には、当該他のピクチャもフレームバッファから読み出されてデコーダ２２に転送される。フレーム「Ｂ４」をデコードするこの例では、フレーム「Ｂ４」をデコードするために用いられる、フレーム「Ｉ３」および「Ｐ６」も、デコーダ２２に転送される。フレーム「Ｉ３」および「Ｐ６」は、図１１の第４行目に示されるように、フレームバッファ上に既に存在する。
【０１８３】
ステップＳ２１での転送ピクチャの確定に伴い、当該ピクチャに対するデコード情報が確定される（ステップＳ２３）。確定されたデコード情報は、デコーダ２２に渡される。デコーダ２２は、ステップＳ２３で転送されたデコード情報に基づき、ステップＳ２２で転送されたピクチャのデコードを、次の第３フレーム目のタイミングに同期して開始する（ステップＳ２４）。デコードされたピクチャ（フレーム）は、フレームバッファの所定のバンクに書き込まれ、フレームバッファが更新される。上述の図１１の第４行目の例では、バッファメモリ上のフレーム「Ｂ７」が書き込まれているバンクに対して、デコードされたフレーム「Ｂ４」のデータが上書きされる（図１１の第３行目参照）。
【０１８４】
一方、上述したステップＳ２０で目標再生フレームが確定されると、出力するビデオデータの情報が確定される（ステップＳ２５）。上述の図１１の第４行目の例では、出力ビデオデータとしてフレーム「Ｐ６」が確定される。この確定された出力ビデオデータの情報が出力データ制御部２３に渡される。出力データ制御部２３では、渡された情報に基づき、第３フレーム目の開始タイミングまでに、ビデオ出力の設定を行う（ステップＳ２６）。そして、この設定に基づき、第３フレーム目に同期して、フレーム「Ｐ６」が出力される（ステップＳ２７）
【０１８５】
なお、再生方向が順方向および逆方向の何れの場合においても、上述のステップＳ２０〜ステップＳ２７で説明した処理は、フレームタイミング毎に順次、実行される。すなわち、第１フレーム目に同期して上述のステップＳ２０の処理による目標再生フレームが確定される。確定された目標再生フレームを新たな出力フレームとして、この新たな出力フレームに対応する新たな目標再生フレームの確定処理が次の第２フレーム目に同期して開始される。
【０１８６】
この新たな目標再生フレームの、ディスクドライブ１１からデコーダ２２への転送処理は、次の第３フレーム目に同期して行われるため、１つ前の処理と干渉することがない。同様に、デコーダ２２によるデコード処理も、図示されない第４フレーム目に同期して行われることになるため、１つ前の処理と干渉することがない。
【０１８７】
このように、この発明によれば、順方向の１倍速再生から逆方向の１倍速再生にわたる可変速再生において、与えられた再生速度および再生方向指示コマンドに対して固定的な遅延で、コマ落ちのない再生出力を、１倍速デコーダを用いて実現することができる。
【０１８８】
なお、上述の図１５のシーケンスにおいて、ステップＳ２０で目標再生フレームが確定してから、その目標再生フレームが目標再生フレームの確定から固定遅延で以てステップＳ２７でビデオ出力されるまでの間は、ステップＳ２２のデータ転送処理およびステップＳ２４のデコード処理がそれぞれ平均して１ピクチャ／フレーム時間に収まる必要がある。換言すれば、ステップＳ２２のデータ転送処理およびステップＳ２４のデコード処理は、それぞれ平均して１ピクチャ／フレーム時間に収まっていれば、それぞれの処理時間を１フレーム時間に固定的とする必要は、無い。
【０１８９】
ピクチャのデコードに１倍速デコーダを用い、順方向および逆方向に１倍速以内の再生を、上述したような目標フレームバッファパターンに基づく制御で以て固定遅延で行う場合、上述のように、目標再生フレームが移行する毎に、１フレームのデコードが行われ、それに伴いバッファメモリ上の１フレームが破棄される。そのため、ステップＳ２２のデータ転送処理およびステップＳ２４のデコード処理は、それぞれ１ピクチャ／フレーム時間の処理に収束するように推移し、全体として、図１５に示されるような３フレーム周期に収束する。
【０１９０】
このように、この発明によれば、順方向の１倍速再生から逆方向の１倍速再生にわたる可変速再生において、与えられた再生速度および再生方向指示コマンドに対して固定的な遅延で、コマ落ちのない再生出力を、１倍速デコーダを用いて実現することができる。
【０１９１】
上述では、この発明が記録媒体として光ディスクを用い、年輪構造でクリップが記録されている場合に適用されるように説明したが、これはこの例に限定されない。例えば、記録媒体上の記録フォーマットは、年輪構造に限られず、他のフォーマットであってもよい。また、記録媒体は、光ディスクに限られず、ハードディスクドライブや、半導体メモリであってもよい。さらに、この発明が記録媒体から再生されたデータに対して適用されるように説明したが、これはこの例に限定されず、安定的にストリームが供給可能な状況であれば、外部から供給されたストリームデータをデコードするようなデコーダ装置にもこの発明を適用することができる。
【０１９２】
また、上述では、再生装置１が光ディスク１０に記録されたビデオデータを再生する専用的なハードウェアであるように説明したが、これはこの例に限らず、例えばパーソナルコンピュータといった汎用的なコンピュータ装置（図示しない）を、再生装置１として用いることもできる。この場合、コンピュータ装置に搭載されるプログラムによって、再生装置１の機能を実現させることができる。またこの場合、ビデオデータのデコード処理は、ソフトウェア処理によりＣＰＵで行ってもよいし、専用的なハードウェアをコンピュータ装置に搭載することもできる。
【図面の簡単な説明】
【０１９３】
【図１】この発明による再生制御処理を概念的に示す略線図である。
【図２】この発明の実施の一形態に適用可能な再生装置の一例の構成を概略的に示すブロック図である。
【図３】デコーダの一例の構成を概略的に示すブロック図である。
【図４】デコーダの一例の構成をより具体的に示すブロック図である。
【図５】ディスク状記録媒体における一例のデータ配置を示す略線図である。
【図６】クリップについて説明するための略線図である。
【図７】光ディスクに対して年輪データが形成された一例の様子を示す略線図である。
【図８】ＭＰＥＧ２のロングＧＯＰにおける一例のデータ構造を示す略線図である。
【図９】ピクチャポインタ情報が記述されるピクチャポインタテーブルのより具体的な例を示す略線図である。
【図１０】カレントフレームに対して表示順で１フレーム後または１フレーム前のフレームをデコードする場合の必要バッファ量の例を示す略線図である。
【図１１】この発明の実施の一形態による目標フレームバッファの一例の更新パターンを示す略線図である。
【図１２】目標フレームバッファのパターンの一例の作成方法を示すフローチャートである。
【図１３】目標フレームバッファのパターンの一例の作成方法を説明するための略線図である。
【図１４】目標フレームバッファのパターンの一例の作成方法を説明するための略線図である。
【図１５】この発明の実施の一形態による同期制御を概略的に示す略線図である。
【図１６】ロングＧＯＰの場合のデコード処理について説明するための略線図である。
【符号の説明】
【０１９４】
１  再生装置
１０  光ディスク
１１  ディスクドライブ
１２  キャッシュメモリ
１３  デコーダ
１３Ａ  フレームメモリ（フレームバッファ）
１４  ＣＰＵ
２２  ＭＰＥＧデコーダ
２３  出力データ制御部
３３  予測復元部
３５  ＲＯＭ
３６  ＲＡＭ
【図１】
0004682759.tif 000002
【図２】
0004682759.tif 000003
【図３】
0004682759.tif 000004
【図４】
0004682759.tif 000005
【図５】
0004682759.tif 000006
【図６】
0004682759.tif 000007
【図７】
0004682759.tif 000008
【図８】
0004682759.tif 000009
【図９】
0004682759.tif 000010
【図１０】
0004682759.tif 000011
【図１１】
0004682759.tif 000012
【図１２】
0004682759.tif 000013
【図１３】
0004682759.tif 000014
【図１４】
0004682759.tif 000015
【図１５】
0004682759.tif 000016
【図１６】
0004682759.tif 000017