説明

再生装置、再生方法および再生プログラム

【課題】 予測符号化によるフレーム間圧縮を行ったビデオ信号の順方向1倍速から逆方向1倍速までの可変速再生を、1倍速デコーダを用いて固定的な遅延で行う。
【解決手段】 目標再生フレームに対応するバッファの目標パターンを作成する。目標パターンは、少なくとも、目標再生フレームと、目標再生フレームに対して時間的に隣接する2つのフレームと、目標再生フレームからこの2つのフレーム夫々の方向について少なくとも1フレーム分の再生を更に継続するために必要なフレームとからなる。1フレーム毎に、現在のバッファ状態と目標パターンとを比較し、新規にデコードが必要なピクチャを抽出して入力を開始すると共に、不要なフレームを抽出し、新たにデコードされたフレームをバッファの不要フレームの領域に対して書き込む。バッファが常に1フレーム分だけ更新され、固定遅延でコマ落ちしない変速再生ができる。

【発明の詳細な説明】
【技術分野】
【0001】
この発明は、順方向または逆方向の可変速再生をより高画質に行うようにした再生装置、再生方法および再生プログラムに関する。
【背景技術】
【0002】
ディジタルビデオ信号およびディジタルオーディオ信号を記録媒体に記録し、また、記録媒体から再生するようなデータ記録再生装置が知られている。ディジタルビデオ信号およびディジタルオーディオ信号を記録するための記録媒体としては、従来から、磁気テープのようなシリアルアクセスを行う記録媒体が多く用いられてきたが、近年では、光ディスク、ハードディスク、半導体メモリなどといった、ランダムアクセス可能な記録媒体が、ディジタルビデオ信号およびディジタルオーディオ信号の記録再生に多く用いられるようになってきている。
【0003】
ディジタルビデオ信号は、データ容量が膨大となるため、所定の方式で圧縮符号化されて記録媒体に記録されるのが一般的である。近年では、MPEG2(Moving Picture Experts Group 2)方式が圧縮符号化の標準的な方式として知られている。MPEG2では、DCT(Discrete Cosine Transform)と動き補償とを用いてディジタルビデオ信号の圧縮符号化を行い、さらに可変長符号を用いてデータの圧縮率を高めている。
【0004】
MPEG2のデータストリーム構造について、概略的に説明する。MPEG2は、動き補償予測符号化と、DCTによる圧縮符号化とを組み合わせたものである。MPEG2のデータ構造は、階層構造をなしており、下位から、ブロック層、マクロブロック層、スライス層、ピクチャ層、GOP層およびシーケンス層となっている。ブロック層は、DCTを行う単位であるDCTブロックからなる。マクロブロック層は、複数のDCTブロックで構成される。スライス層は、ヘッダ部と、1以上のマクロブロックより構成される。ピクチャ層は、ヘッダ部と、1以上のスライスとから構成される。ピクチャは、1画面に対応する。
【0005】
GOP層は、ヘッダ部と、フレーム内符号化に基づくピクチャであるI(Intra-coded)ピクチャと、予測符号化に基づくピクチャであるP(Predictive-coded)ピクチャB(Bi-directionally predictive coded)ピクチャとから構成される。Iピクチャは、それ自身の情報のみでデコードが可能であり、PおよびBピクチャは、基準画像として前あるいは前後の画像が必要とされ、単独ではデコードされない。例えばPピクチャは、自身より時間的に前のIピクチャまたはPピクチャを基準画像として用いてデコードされる。また、Bピクチャは、自身の前後のIピクチャまたはPピクチャの2枚のピクチャを基準画像として用いてデコードされる。最低1枚のIピクチャを含むそれ自身で完結したグループをGOP(Group Of Picture)と呼び、MPEGのストリームにおいて独立してアクセス可能な最小の単位とされる。
【0006】
GOPには1または複数のピクチャから構成される。以下では、便宜上、1枚のIピクチャのみで構成されるGOPをシングルGOPと呼び、Iピクチャと、Pおよび/またはBピクチャとからなる複数のピクチャで構成されるGOPをロングGOPと呼ぶことにする。シングルGOPでは、GOPをIピクチャのみから構成することで、フレーム単位での編集が容易とされると共に、フレーム間の予測符号化を行わないために、より高画質を得ることができる。一方、ロングGOPでは、フレーム間の予測符号化を行うために、圧縮効率がよいという利点がある。
【0007】
なお、ロングGOPにおいて、GOP内で完全にデコードが可能な、閉じた構造を持つクローズドGOPと、デコードの際に符号化順で1つ前のGOPの情報を用いることができるオープンGOPとの2種類がある。オープンGOPは、クローズドGOPと比較して、より多くの情報を用いてデコードできるため高画質を得られ、一般的に用いられている。以下では、単に「GOP」と記述した場合には、特に記載のない限り、このオープンGOPを指すものとする。
【0008】
ビデオ信号のフォーマットとして、従来から、ビットレートが25Mbps(メガビットパーセカンド)のSD(Standard Definition)フォーマットが知られている。特に放送局などで使用される映像機器においては、SDフォーマットのビデオ信号を上述したシングルGOPで用い、高画質と高精度の編集環境とを実現していた。SDフォーマットのビデオ信号は、フレーム毎のビットレートが固定の固定ビットレートが適用される。
【0009】
一方、近年では、ディジタルハイビジョン放送などの実施に伴い、SDフォーマットより高解像度とされた、HD(High Definition)フォーマットが用いられるようになってきた。HDフォーマットは、高解像度に伴いビットレートが高くなっており、シングルGOPでは記録媒体に対して長時間の記録ができない。そこで、HDフォーマットのビデオ信号を上述したロングGOPで用いる。ロングGOPでは、予測符号化を用いたフレーム間圧縮を行うため、フレーム毎にビットレートが異なる可変ビットレートとされる。
【0010】
ところで、ビデオ信号の編集の際には、IN点やOUT点といった編集点を決めるために、フレーム単位での頭出しが行われる。そのためには、順方向および逆方向の再生方向のそれぞれにおいて、再生速度が1倍速以下の可変速再生が必要となる。SDフォーマットのように、シングルGOPを用いている場合には、それぞれのフレームを独立してデコード可能なので、1倍速以下の可変速再生について、特に問題が発生することがない。すなわち、シングルGOPの場合、少なくとも表示するフレームだけをデコードすれば済むからである。
【0011】
一方、HDフォーマットのように、ロングGOPを用いている場合には、上述のSDフォーマットのようにそれぞれのフレームを独立してデコードすることができない。図16を用いて、ロングGOPの場合のデコード処理について説明する。ここでは、1GOPが1枚のIピクチャ、4枚のPピクチャおよび10枚のBピクチャの、計15枚のピクチャから構成されるものとする。GOP内のI、PおよびBピクチャの表示順は、図16Aに一例が示されるように、「B01234567891011121314」のようになる。なお、添え字は表示順を示す。
【0012】
この例では、最初の2枚のB0ピクチャおよびB1ピクチャは、1つ前のGOPにおける最後尾のP14ピクチャと、このGOP内のI2ピクチャを用いて予測されデコードされたピクチャである。GOP内の最初のP5ピクチャは、I2ピクチャから予測されデコードされたピクチャである。他のP8ピクチャ、P11ピクチャおよびP14は、それぞれ1つ前のPピクチャを用いて予測されデコードされたピクチャである。また、Iピクチャ以降の各Bピクチャは、それぞれ前後のIおよび/またはPピクチャから予測されデコードされたピクチャである。
【0013】
一方、Bピクチャは、時間的に前後のIまたはPピクチャを用いて予測されデコードされるため、ストリームや記録媒体上におけるI、PおよびBピクチャの並び順は、デコーダにおけるデコードの順序を考慮して決める必要がある。すなわち、BピクチャをデコードするためのIおよび/またはPピクチャは、当該Bピクチャよりも常に先にデコードされていなければならない。
【0014】
上述の例では、ストリームや記録媒体上の各ピクチャの配列は、図16Bに例示されるように、「I20153486711910141213」のようになり、この順でデコーダに入力される。なお、添え字は、図16Aに対応し、表示順を示す。
【0015】
デコーダにおけるデコード処理は、図16Cに示されるように、先ずI2ピクチャをデコードし、デコードされたこのI2ピクチャと1つ前のGOPにおける最後尾(表示順)のP14ピクチャとによりB0ピクチャおよびB1ピクチャを予測しデコードする。そして、B0ピクチャおよびB1ピクチャをデコードされた順にデコーダから出力し、次にI2ピクチャを出力する。B1ピクチャが出力されると、次にP5ピクチャがI2ピクチャを用いて予測されデコードされる。そして、I2ピクチャおよびP5ピクチャを用いてB3ピクチャおよびB4ピクチャが予測されデコードされる。そして、デコードされたB3ピクチャおよびB4ピクチャをデコードされた順にデコーダから出力し、次にP5ピクチャを出力する。
【0016】
以下、同様にして、Bピクチャの予測に用いるPまたはIピクチャをBピクチャより先にデコードし、このデコードされたPまたはIピクチャを用いてBピクチャを予測してデコードし、デコードされたBピクチャを出力してから、当該Bピクチャをデコードするために用いたPまたはIピクチャを出力する処理が繰り返される。記録媒体上やストリームにおける図16Bのようなピクチャ配列は、一般的に用いられるもので、デコードに4フレーム分のフレームメモリが必要となる。非特許文献1には、このようにしてMPEG2のエレメンタリストリームをデコードする方法が記載されている。
【非特許文献1】藤原 洋、「ポイント図解式・最新MPEG教科書」、初版、株式会社アスキー、1994年8月1日、p.106
【0017】
このような、ビデオ信号にロングGOPを用いた場合の順方向への1倍速再生は、1フレーム分の時間で1フレームのピクチャのデコード結果が得られるデコーダ(1倍速デコーダと呼ぶ)を用いて可能である。
【発明の開示】
【発明が解決しようとする課題】
【0018】
ところで、特に編集作業などの場合、必要なフレームを探すために、再生速度については1倍速以下で可変に、また、再生方向については順方向および逆方向に自在に切り換えられることが求められる。ビデオ信号にロングGOPを用い、順方向および逆方向に1倍速以下の再生速度で可変速再生する場合について考える。
【0019】
なお、ビデオ信号にシングルGOPを用いた場合は、上述したように、表示するためのフレームを単独でデコードすることができるため、順方向および逆方向の1倍速以下の可変速再生や、順方向および逆方向への再生方向の切り換えを行っても、特に問題は発生しない。
【0020】
ビデオ信号にロングGOPを用いた場合、上述したように、表示するためのフレームをデコードする際に、時間的に前および/または後のピクチャを1乃至複数枚、必要とする。順方向で1倍速以下の再生速度での再生は、再生速度に応じて入力ストリームを止めてフレームメモリを更新しないようにすると共に、出力されるビデオ信号をフレームメモリから繰り返し読み出すことで、上述の1倍速デコーダを用いて実現できる。
【0021】
一方、ビデオ信号にロングGOPを用いて逆方向再生を行う場合、1フレームの画像を表示するのに、順方向の再生時に比べ、より多くのピクチャが必要となる場合が多い。
【0022】
一例として、表示順が図16Aに例示されるビデオストリームを逆方向再生する場合、P14ピクチャを最初に出力しなければならない。上述したように、P14ピクチャをデコードするためには、I2ピクチャ、P5ピクチャ、P8ピクチャおよびP11ピクチャのデコードが必要である。したがって、図16Bのような配列でストリームが入力される場合、少なくとも4フレーム分のデコード処理を行うだけの遅延が生じることになる。また、I2ピクチャ、P5ピクチャ、P8ピクチャおよびP11ピクチャは、Bピクチャをデコードするために用いられるため、メモリに保持することが必要になる。
【0023】
さらに、当該GOPの最後に出力されるべきB1ピクチャおよびB0ピクチャは、当該GOPのI2ピクチャと、本来の再生方向において1つ前のGOP、すなわち逆方向再生では1つ後のGOPのP14ピクチャとを用いて予測されデコードされるため、当該GOPのデコード処理中に、さらに逆方向再生における表示順で1つ後のGOPのデコード処理も必要になる。
【0024】
ここで、再生方向を順方向から逆方向、または、逆方向から順方向に切り換える場合について考える。例えば、ジョグダイヤルなどで再生速度および再生方向を制御できるような編集装置などを想定し、再生速度が0の点を中心に再生速度および再生方向を切り換えながら所望のフレームを探すような場合に相当する。
【0025】
例えば順方向に再生中の任意のフレームが表示されているときに、再生方向を逆方向に切り換えた場合、再生方向を順方向から逆方向に切り換える直前のフレームの、1フレーム前のフレーム画像がフレームメモリに残っていれば、逆方向に再生方向を切り換えたときの1フレーム目は、フレームメモリに残っている当該フレーム画像を用いて表示することができる。
【0026】
しかしながら、例えば、再生方向を逆方向に切り換える直前のフレームがGOPの最後に表示されるP14ピクチャであった場合、再生方向を逆方向に切り換えた直後に表示されるべきフレームは、当該GOPのB13ピクチャである。このB13ピクチャをデコードするためには、P14ピクチャとP11ピクチャが必要であり、さらに、P11ピクチャをデコードするためには、当該GOPのI2ピクチャ、P5ピクチャおよびP8ピクチャが必要とされる。
【0027】
したがって、この場合、再生方向を順方向から逆方向に切り換えた瞬間に、少なくとも4ピクチャ分(I2ピクチャ、P5ピクチャ、P8ピクチャおよびP11ピクチャ)のデコード時間分の遅延が生じてしまうという問題点があった。特に、順方向と逆方向の切り換えを頻繁に行うような場合では、この遅延が操作感の悪さとなって現れてしまい、問題となる。
【0028】
すなわち、記録再生装置を編集動作などに適用させるためには、編集装置といった上位のシステムから要求されたコマンド速度に対して、常に一定の遅延で再生出力結果を出す必要がある。順方向から逆方向に再生方向を切り換えた際に遅延が生ずるのでは、編集動作としては適当でないといえる。
【0029】
この問題を解決するために、幾つかの方法が考えられている。第1の方法としては、デコーダに1倍速よりも十分高速なデコード速度を持つものを用いる方法が考えられる。例えば、上述の例では、1フレーム時間内に4フレーム分以上のピクチャをデコード可能なデコーダを用いることが考えられる。しかしながら、1倍速デコーダに対して、高速なデコード速度を持つデコーダは高価であり、コストが嵩んでしまうという問題点があった。
【0030】
第2の方法として、所定の表示タイミングに対してデコードの間に合わないピクチャをコマ落ち、すなわちデコードおよび表示しないようにし、見かけ上、再生が継続されるようにする方法が考えられる。しかしながら、この方法は、表示品質の点で問題があった。
【0031】
第3の方法として、エンコード時に、入力されたビデオ信号に基づき、本来用いられるビデオ信号に対して解像度を落としたより低解像度のデータなど、固定遅延で再生出力可能なデータを作成し、記録媒体に記録しておく。そして、再生時に、本来用いられるビデオ信号のデコードが間に合わない際にこの低解像度のデータを用いて表示を行う方法が考えられる。この方法でも、本来用いられるビデオ信号のピクチャに対して低解像度のピクチャが混在して表示されることになり、表示品質の点で問題があった。
【0032】
第4の方法として、上位のシステムから要求されるコマンド速度が決まってから、必要なピクチャをデコードし、再生動作が滞らない程度のピクチャがフレームメモリに蓄積されたら、実際の再生を開始する方法が考えられる。しかしながらこの方法では、上位のシステムからコマンド速度が要求されてから再生が開始されるまで、遅延が生じてしまうことになり、上述の問題点を解決できない。
【0033】
したがって、この発明の目的は、予測符号化によるフレーム間圧縮を行ったビデオ信号の再生を1倍速デコーダを用いて行う場合において、順方向の1倍速再生から逆方向の1倍速再生までの可変速再生を、固定的な遅延で行うことができる再生装置、再生方法および再生プログラムを提供することにある。
【課題を解決するための手段】
【0034】
この発明は、上述した課題を解決するために、予測符号化によるフレーム間圧縮を用いて圧縮符号化されランダムアクセス可能な記録媒体に記録されたビデオデータを、逆方向の1倍速再生から順方向の1倍速再生まで可変速に再生するようにした再生装置において、複数フレーム分のビデオデータを一時的に格納可能なフレームバッファと、次に再生されるべき目標再生フレームに対するフレームバッファの目標パターンを作成する目標パターン作成部と、現在のフレームバッファの状態と目標パターンとを比較する比較部と、比較部による比較結果に基づき、新たにデコードが必要なフレームを抽出すると共に現在のフレームバッファの状態で不要になるフレームを抽出するフレームバッファ制御部とを有することを特徴とする再生装置である。
【0035】
また、この発明は、予測符号化によるフレーム間圧縮を用いて圧縮符号化されランダムアクセス可能な記録媒体に記録されたビデオデータを、逆方向の1倍速再生から順方向の1倍速再生まで可変速に再生するようにした再生方法において、次に再生されるべき目標再生フレームに対する、複数フレーム分のビデオデータを一時的に格納可能なフレームバッファの目標パターンを作成する目標パターン作成のステップと、現在のフレームバッファの状態と目標パターンとを比較する比較のステップと、比較のステップによる比較結果に基づき、新たにデコードが必要なフレームを抽出すると共に現在のフレームバッファの状態で不要になるフレームを抽出するステップとを有することを特徴とする再生方法である。
【0036】
また、この発明は、予測符号化によるフレーム間圧縮を用いて圧縮符号化されランダムアクセス可能な記録媒体に記録されたビデオデータを、逆方向の1倍速再生から順方向の1倍速再生まで可変速に再生するようにした再生方法をコンピュータ装置に実行させる再生プログラムにおいて、次に再生されるべき目標再生フレームに対する、複数フレーム分のビデオデータを一時的に格納可能なフレームバッファの目標パターンを作成する目標パターン作成のステップと、現在のフレームバッファの状態と目標パターンとを比較する比較のステップと、比較のステップによる比較結果に基づき、新たにデコードが必要なフレームを抽出すると共に現在のフレームバッファの状態で不要になるフレームを抽出するステップとを有する再生方法をコンピュータ装置に実行させることを特徴とする再生プログラムである。
【0037】
上述したように、この発明は、次に再生されるべき目標再生フレームに対する、複数フレーム分のビデオデータを一時的に格納可能なフレームバッファの目標パターンを作成し、現在のフレームバッファの状態と目標パターンとを比較した比較結果に基づき、新たにデコードが必要なフレームを抽出すると共に現在のフレームバッファの状態で不要になるフレームを抽出するようにしているため、順方向への1倍速再生から逆方向への1倍速再生までの再生時に、フレームバッファにおける更新フレーム数が常に1フレームとすることができる。またこれにより、フレームの入力からデコードまでの遅延量が固定的とされ、順方向への1倍速再生から逆方向への1倍速再生までの可変速再生を、固定的な遅延量でコマ落ち無しに、1倍速デコーダを用いて行うことができる。
【発明の効果】
【0038】
この発明は、上述のように、次に再生されるべき目標再生フレームに対するフレームバッファの目標パターンを作成し、作成された目標パターンと現在のフレームバッファの状態とを比較する。そして、比較結果に基づき、新たにデコードが必要なフレームと現在のフレームバッファの状態で不要になるフレームとを抽出するようにしている。そのため、順方向への1倍速再生から逆方向への1倍速再生までの再生時に、フレームバッファにおける更新フレーム数を常に1フレームとすることができると共に、フレームの入力からデコードまでの遅延量が固定的にできる効果がある。
【0039】
またこれにより、順方向への1倍速再生から逆方向への1倍速再生までの可変速再生を、固定的な遅延量でコマ落ち無しに、1倍速デコーダを用いて行うことができる効果がある。
【発明を実施するための最良の形態】
【0040】
以下、この発明の実施の一形態を、図面を参照しながら説明する。図1は、この発明による再生制御処理を概念的に示す。ステップS1で、次に再生すべき目標再生フレームが指示される。目標再生フレームは、例えば再生速度が順方向または逆方向に1倍速以内であれば、1フレームタイミング前で確定した目標再生フレームに対して表示順で隣接するフレームの範囲となる。目標再生フレームは、例えばより上位のシステムから指定され、フレームタイミング毎に供給される。
【0041】
目標再生フレームが指示されると、次に、目標再生フレームに対する目標フレームバッファのパターンが作成される(ステップS2)。目標フレームバッファのパターンは、目標再生フレームを再生すると共に、逆方向および順方向への再生を継続するために、フレームバッファ上にデコードされた状態で溜め込まれている必要があるフレームのパターンである。次のステップS3で、作成された目標フレームバッファパターンと現在のフレームバッファの状態とが比較される。この比較により、現在のフレームバッファの状態に対して新規にデコードが必要なピクチャが抽出される(ステップS4)と共に、現在のフレームバッファの状態において不要なピクチャが抽出される(ステップS5)。ステップS4およびステップS5で抽出されるピクチャは、常に1ピクチャである。
【0042】
ここまでが、実際にデコードを行うためのターゲットを作成する処理となる。次から、実際にデコーダが制御され、デコード処理が開始される。
【0043】
ステップS6では、例えば記録媒体がアクセスされ、ステップS4で抽出された結果に基づき所定のピクチャがデコーダに対してストリーム入力される。デコーダでデコードされたピクチャは、フレームバッファ上の、上述のステップS5で抽出された不要ピクチャの領域に上書きされる(ステップS7)。1ピクチャ分のデコードが完了すると、デコード済みの出力フレーム画像として出力される(ステップS8)。
【0044】
図2は、この発明の実施の一形態に適用可能な再生装置1の一例の構成を概略的に示す。再生装置1は、光ディスク10を記録媒体として用いる。CPU(Central Processing Unit)14は、ROM(Read Only Memory)およびRAM(Random Access Memory)が接続され(図示しない)、ROMに予め記憶されたプログラムに従いこの再生装置1の各部を制御する。RAMは、CPU14のワークメモリとして用いられる。
【0045】
ディスクドライブ11は、CPU14の制御に基づき、装填された光ディスク10の所定のアドレスからデータを読み出す。読み出されたデータは、キャッシュメモリ12に一時的に溜め込まれる。そして、CPU14の命令に基づき、キャッシュメモリ12からデコーダ13に対してビデオストリームが供給され、要求に応じて入力されたビデオストリームをフレームメモリ13Aを用いてデコードする。デコード出力は、ベースバンドのビデオ信号として出力される。
【0046】
操作部15は、キーやスイッチなどの様々な操作子が設けられ、操作子に対してなされた操作に応じた制御信号を生成し、CPU14に供給する。CPU14は、供給されたこの制御信号に応じて再生装置1の各部に対して命令を送る。操作部15には、例えばジョグダイヤル16が設けられる。ジョグダイヤル16は、回転角に応じた信号が出力されるようになっており、例えば、ジョグダイヤル16は、ユーザによる操作に応じて、再生方向について順方向および逆方向の指定を行うための制御信号や、再生速度を略リアルタイムで指示する制御信号などを生成し、CPU14に供給する。
【0047】
なお、再生速度や再生方向などを指示する命令は、操作部15に対する操作に基づくものに限定されない。例えば、所定の通信手段(図示しない)により再生装置1に接続された、編集装置などの他の装置からこの装置に対して、再生速度や再生方向を命令するコマンドを送信するようにできる。この場合、再生装置1に対してコマンドを送信する他の装置は、この再生装置1に対するより上位の装置となる。
【0048】
この再生装置1で扱われるビデオストリームは、MPEG2(Moving Pictures Experts Group 2)の規格に準じて圧縮符号化がなされたストリームであって、GOP(Group Of picture)の構成は、ロングGOPおよびオープンGOPであるものとする。
【0049】
図3は、デコーダ13の一例の構成を概略的に示す。光ディスク10から読み出され、ディスクドライブ11から出力されるストリームデータは、例えばMPEG−ES(MPEG Elementally Stream)である。このMPEG−ESは、ストリームデコーダ20に供給される。ストリームデコーダ20は、入力されたMPEG−ESのパケットとヘッダ情報とを解析し、デコード処理に必要な各種パラメータと、圧縮符号化されパケット中のペイロードに格納されたピクチャのデータとを抽出する。各種パラメータは、例えばCPU14に供給される。抽出されたピクチャデータは、ストリームバッファ21に所定に溜め込まれる。
【0050】
MPEGデコーダ22は、ストリームデコーダ20に対してストリームバッファ21に溜め込まれたピクチャデータを要求し、要求に応じてストリームバッファ21から読み出されたピクチャデータをデコードしてフレームメモリ13Aに書き込む。また、MPEGデコーダ22は、フレームメモリ13Aに書き込まれたピクチャデータを用いて他のピクチャデータ(例えばPピクチャやBピクチャ)をデコードする処理も行う。
【0051】
なお、詳細は後述するが、フレームメモリ13Aは、順方向の再生と逆方向の再生とを固定的な遅延で実行可能とするための必要十分な容量を有する。例えば、フレームメモリ13Aは、デコードされたピクチャの9フレーム分を溜め込めるだけの容量を有する。一例として、フレームメモリ13Aは、それぞれ1フレーム分のデータを格納可能な9個のバンクに記憶領域が分割され、バンク毎にアクセスが制御される。
【0052】
出力データ制御部23は、出力されるビデオデータの管理を行う。例えば、出力データ制御部23は、操作部15に対する操作に応じたCPU14の命令に基づき、フレームメモリ13Aから次に表示するためのフレームデータを読み出す。読み出されたフレームデータは、ベースバンドのビデオ信号として出力される。
【0053】
図4は、デコーダ13の一例の構成をより具体的に示す。なお、図4において、上述する図3と共通する部分には同一の符号を付して詳細な説明を省略する。ディスクドライブ11から出力されたMPEG−ESは、デマルチプレクサ(DMUX)30に供給され、パケットが解析される。パケットから取り出されたMPEG ESおよびヘッダ情報は、ストリームバッファ21に溜め込まれる。パケットのヘッダ情報は、また、ユーザデータデコーダ31に供給され、各種パラメータが抽出される。抽出されたパラメータは、ストリームバッファ21に所定に溜め込まれる。
【0054】
デコーダ32は、ストリームバッファ21に溜め込まれたヘッダ情報やMPEG ESをデコードする。デコーダ32は、ヘッダ情報のデコードを行いピクチャのデコードに必要なパラメータを取り出す。デコーダ32は、ヘッダ情報から取り出されたパラメータに基づき、MPEG ESに対して、可変長符号のデコード、逆量子化および逆DCT(Discrete Cosine Transform)を行い、ピクチャ毎のデコードを行う。デコーダ32でデコードされたピクチャデータは、予測復元部33を介してフレームメモリ13Aに書き込まれる。
【0055】
予測復元部33は、フレームメモリ13Aに書き込まれたピクチャデータを用いて、予測符号化を用いてフレーム間圧縮をされたピクチャをデコードする。フレーム間圧縮をデコードされたピクチャは、フレームデータとしてフレームメモリ13Aに再び書き込まれる。
【0056】
一方、ユーザの、再生方向および再生速度を指定するためのジョグダイヤル16に対する操作などにより、操作部15で、再生速度や再生方向を示す制御信号が所定に生成される。この制御信号は、CPU14に供給される。再生方向や再生速度を示す制御信号は、これに限らず、上述したように、図示されない通信手段を介してより上位の装置からコマンドとしてCPU14に供給されるようにしてもよい。
【0057】
CPU14は、ROM35に予め記憶されたプログラムに従い、操作部15から供給された制御信号に基づき、ビデオ出力部23に対して命令を出し、出力すべきフレームを指示する。なお、RAM36は、必要に応じてCPU14のワークメモリとして用いられる。ビデオ出力部23は、この命令に応じてフレームメモリ13Aから指示されたフレームを読み出す。
【0058】
読み出されたフレームは、補助データ重畳部34に供給され、ストリームバッファ21に溜め込まれた情報に基づき所定にビデオインデックス情報や補助データなどが重畳され、さらに同期信号を付加されて、出力ビデオ信号として出力される。
【0059】
次に、この発明の実施の一形態に適用できる記録媒体について説明する。先ず、図5を用いて、ディスク状記録媒体における一例のデータ配置について説明する。この図5に一例が示されるデータ配置は、記録可能な光ディスク、ハードディスクといった、ランダムアクセスが可能なディスク状記録媒体における一般的なデータ配置である。論理アドレス空間は、任意のデータを記録再生可能な領域である。
【0060】
この実施の一形態では、記録媒体を光ディスクとする。なお、この実施の一形態に適用可能な記録媒体は、光ディスクに限られない。すなわち、この実施の一形態は、ハードディスクドライブや半導体メモリといった、他のランダムアクセス可能な記録媒体にも適用できるものである。
【0061】
論理アドレスの先端および後端には、ファイルシステムFSが配置される。任意のデータは、論理アドレス空間内に一般的にファイルと称される所定の形式で記録される。記録媒体上のデータは、基本的にファイル単位で管理される。ファイルの管理情報は、ファイルシステムFSに記録される。記録再生装置のシステム制御部(後述する)のファイルシステム層は、このファイルシステムFSの情報を参照および操作することで、多種多様なデータを一つの記録媒体上で管理することができる。ファイルシステムFSは、例えばUDF(Universal Disk Format)が用いられ、2kB単位でファイルを管理する。
【0062】
論理アドレス空間の外に、交替領域が配置される。交替領域は、記録媒体の一部が欠陥(ディフェクト)により物理的に読み書きできなくなった場合に代替的に用いることができる領域である。例えば、記録媒体に対するアクセス(特に記録時のアクセス)の際に欠陥領域が認識された場合、通常は交替処理が行われ、当該欠陥領域のアドレスが交替領域内に移動される。
【0063】
交替領域の使用状況は、所定領域にディフェクトリストとして記憶され、記録再生装置のドライブ制御部や、システム制御部の下位階層により用いられる。すなわち、後述するドライブ制御部やシステム制御部の下位階層では、記録媒体へのアクセスの際にディフェクトリストを参照することで、交替処理が行われている場合にも、適切な領域へのアクセスを行うことができる。交替領域のこの仕組みにより、上位アプリケーションは、記録媒体上の不良記録領域の有無や位置などを考慮することなく、記録媒体に対するデータの記録再生を行うことができる。
【0064】
ディスク状記録媒体の場合、交替領域は、ディスクの最内周側または最外周側に配置されることが多い。ディスクの回転制御を、ディスクの半径方向に段階的に回転速度を変更するゾーン制御で行っている場合には、ゾーン毎に交替領域を設ける場合もある。記録媒体が半導体メモリなどディスク状記録媒体ではない場合には、物理アドレスが最も小さい側または最も大きい側に配置されることが多い。
【0065】
オーディオデータおよびビデオデータ(以下、まとめてAVデータと呼ぶ)を扱うアプリケーションにおいては、連続同期再生、すなわち実時間再生が保障された再生が必要な単位となるデータのまとまりを、クリップと呼ぶ。例えば、ビデオカメラにより撮影が開始されてから終了されるまでのひとまとまりのデータがクリップとされる。クリップの実体は、単一のファイルまたは複数のファイルからなる。この発明においては、クリップは、複数のファイルからなる。クリップの詳細については、後述する。
【0066】
論理アドレス空間に対して、例えば先頭側にクリップ以外の任意のファイルが記録できるNRT(Non Real Time)領域が配置され、NRT領域の次から、クリップが順に詰め込まれていく。クリップは、光ディスク10上のディフェクト位置を避けて配置され、上述した交替処理が行われないようにされる。各クリップには、ヘッダ(H)およびフッタ(F)が付加される。この例では、ヘッダおよびフッタは、クリップの後端側にまとめて配置されている。
【0067】
なお、以下の説明において、光ディスク10に最初に記録されるクリップを、クリップ#1とし、以降、クリップ#2、クリップ#3、・・・とクリップ番号が増加していくものとする。
【0068】
論理アドレス空間内において、データが記録されていない領域や、過去にデータが記録されていたが現在では不要になった領域は、未使用領域としてファイルシステムFSに管理される。記録媒体上に新たに記録されるファイルに対して、未使用領域に基づき記録領域が割り当てられる。当該ファイルの管理情報は、ファイルシステムFSに追加される。
【0069】
記録媒体として記録可能な光ディスクを用いた場合、この発明では、クリップを年輪構造によって記録媒体に記録する。図6および図7を用いて、年輪構造について説明する。図6Aは、一つのクリップ100をタイムライン上に示す例である。この例では、クリップ100は、ビデオデータ101、オーディオデータ102A〜102D、補助AVデータ103およびリアルタイムメタデータ104の7ファイルからなる。
【0070】
ビデオデータ101は、ベースバンドのビデオデータを、例えばビットレートが50Mbps(メガビットパーセカンド)の高ビットレートで圧縮符号化したビデオデータである。圧縮符号化方式としては、例えばMPEG2(Moving Pictures Experts Group 2)方式が用いられる。オーディオデータ102A、102B、102Cおよび102Dは、ベースバンドのオーディオデータが用いられ、それぞれ2チャンネルのオーディオデータである。これに限らず、オーディオデータ102A、102B、102Cおよび102Dは、ベースバンドのオーディオデータを高ビットレートで圧縮符号化したオーディオデータを用いてもよい。ビデオデータ101およびオーディオデータ102A〜102Dは、実際の放送や編集の対象とされるデータであって、本線系のデータと称される。
【0071】
補助AVデータ103は、ベースバンドのビデオデータおよびオーディオデータを、本線系のビデオデータおよびオーディオデータに対してより低ビットレートで圧縮符号化して多重化したデータである。圧縮符号化方式としては、例えばMPEG4方式が用いられ、本線系のAVデータを、ビットレートを例えば数Mbpsまで落とすように圧縮符号化して生成する。補助AVデータ103は、高速サーチ再生を行うために本線系のデータの代理として用いられるデータであって、プロキシ(Proxy)データとも称される。
【0072】
メタデータは、あるデータに関する上位データであり、各種データの内容を表すためのインデックスとして機能する。メタデータには、上述の本線系のAVデータの時系列に沿って発生されるリアルタイムメタデータ104と、本線系のAVデータにおけるシーン毎など、所定の区間に対して発生される非時系列メタデータの2種類がある。非時系列メタデータは、例えば図5で説明したNRT領域に記録される。
【0073】
クリップ100は、図6Bに一例が示されるように、所定の再生時間(例えば2秒)を基準として分割され、年輪構造として光ディスクに記録される。一つの年輪は、図6Cに一例が示されるように、ビデオデータ101、オーディオデータ102A〜102D、補助AVデータ103およびリアルタイムメタデータ(RM)104を、それぞれ再生時間帯が対応するように、トラック1周分以上のデータサイズを有する所定の再生時間単位に分割し、分割された再生時間単位毎に順に配置して記録する。すなわち、クリップ100を構成する各データは、年輪構造により所定時間単位でインターリーブされ、光ディスクに記録される。
【0074】
年輪を形成するデータを年輪データと称する。年輪データは、ディスクにおける最小の記録単位の整数倍のデータ量とされる。また、年輪は、その境界がディスクの記録単位のブロック境界と一致するように記録される。
【0075】
図7は、光ディスク10に対して年輪データが形成された一例の様子を示す。例えば、図6Bを用いて説明したように、光ディスク10の内周側から外周側に向けて、1つのクリップが所定の再生時間単位に分割された年輪データ#1、#2、#3、・・・が連続的に記録される。すなわち、光ディスク10の内周側から外周側に向けて、再生の時系列が連続するようにデータが配置される。なお、図示しないが、NRT領域は、図7の例では、先頭の年輪データ#1のさらに内周側に配置される。
【0076】
HDフォーマットでは、可変長ビットレートでの圧縮符号化が可能とされている。また、ロングGOPを用いた場合、予測符号化を用いたフレーム間圧縮符号化により、Iピクチャ、PピクチャおよびBピクチャにより、データサイズが異なる。そこで、ピクチャポインタファイルを用いて所望の位置へのアクセスを実現する。
【0077】
ピクチャポインタは、クリップ内の各フレーム位置のオフセット情報である。すなわち、例えばMPEG2においては、フレーム毎にデータの圧縮率を変える可変ビットレートが可能とされている。例えば、平坦な画面のフレームは、より高圧縮率で圧縮符号化し、粗い画面のフレームは、より低圧縮率で圧縮符号化する。このように、フレームの性質に応じて圧縮率を変えることで、より高解像度のビデオデータをより低いビットレートで伝送および記録することができる。また、MPEG2においては、可変長符号による圧縮符号化もなされる。
【0078】
このような、ビットレートを可変として圧縮符号化されたビデオデータは、フレーム位置や複数フレームで再生が完結されるGOPの位置がフレーム毎やGOP毎に異なり、所望の位置へのジャンプなどが難しい。そこで、可変長ビットレートのアクセスを容易とするために、クリップ内の各フレーム位置のオフセット情報をピクチャポイントとしてテーブル化して非時系列メタデータファイルとし、クリップにそれぞれ対応して配置する。例えばドライブにディスクを挿入した際にこのピクチャポイントを所定に読み込んでおくことで、クリップ内の所望位置へのアクセスを高速に行うことができるようになる。
【0079】
図8および図9を用いて、より詳細に説明する。図8は、MPEG2のロングGOPにおける一例のデータ構造を示す。例えば、図8Aに示されるように、1つのクリップから1ロングGOPファイルが構成される。ロングGOPファイルは、図8Bに示されるように、ビデオMXF(Material Exchange Format)ファイルOP−Atomと呼ばれる構造を有し、先頭からヘッダパーティションパック(HPP)およびヘッダメタデータが配置されてヘッダ情報が構成され、その後ろに、ビデオデータの本体が格納されるエッセンスコンテナが配置される。ファイルの末尾には、フッタパーティションパック(FPP)が配置される。
【0080】
エッセンスコンテナは、図8Cに示されるように、GOPが並んでいる構成となっている。各GOPの内容は、図8Dに示されるように、ピクチャの集合であり、1つのピクチャの内容は、図8Eに示されるように、先頭にKL(Key,length)情報が配され、次にI、PまたはBピクチャの本体が配され、さらにKL情報が配される。ピクチャの末尾には、必要に応じてフィラーが配され、バイト単位で末尾が揃えられる。
【0081】
このような構成において、MPEG2のロングGOPでは、各ピクチャの情報量、すなわち図8Eに示されるI、PおよびBピクチャのサイズの値が不確定となる。したがって、例えばロングGOPビデオファイル中のあるフレームから再生を開始しようとした場合に、ロングGOPビデオファイル中のそのフレームに対応するピクチャの先頭位置を、バイト位置などで指定することができない。
【0082】
そのため、ロングGOPビデオファイルの先頭位置からバイト単位で示されるファイルアドレス(図8F参照)を基準として、ロングGOPビデオファイルに含まれる各ピクチャそれぞれについて、ファイルアドレス、サイズおよびピクチャタイプ(I、PまたはBピクチャ)と、そのピクチャがGOPの先頭のピクチャであるか否かを示す情報を、ピクチャポインタ情報として用意する。このピクチャポインタ情報は、ロングGOPビデオファイル毎に用意される。
【0083】
なお、図8Eに示されるピクチャ末尾に配されるフィラーは、各ピクチャの境界がファイルアドレスで見て例えば2048バイトといった所定バイトの倍数になるように調整する。一例として、各ピクチャの境界が光ディスク10のセクタといった最小アクセス単位の境界に一致するように、フィラーを用いて調整すると、各ピクチャ毎のアクセスが容易となり好ましい。
【0084】
図9は、ピクチャポインタ情報が記述されるピクチャポインタテーブルのより具体的な例を示す。この例では、ピクチャポインタテーブルは、8バイト単位でデータが記述される。先頭の8バイトは、予約領域およびこのピクチャポインタテーブルのバージョン情報が格納される。以下、1フレームすなわち1ピクチャに対して8バイトが割り当てられ、この8バイトの情報がロングGOPビデオファイルに含まれるピクチャの数だけ並べられる。各ピクチャは、表示フレーム順に並べられている。
【0085】
各ピクチャ毎のデータについて説明する。先頭の1ビットは、そのピクチャがGOPの先頭のピクチャであるか否かを示すフラグである。例えば、1GOP内にIピクチャが複数枚、存在する場合を想定すると、Iピクチャの位置だけではGOPの境界を特定できない。GOPの境界を特定できないと、MPEG2に規定されるシーケンスヘッダ(Sequence Header)の位置が分からず、デコーダに入力されるストリームの先頭にシーケンスヘッダが無いという状態になるおそれがある。このGOP先頭のピクチャであるか否かを示すフラグをピクチャ毎に持たせることで、このような状態を回避できる。再生時には、このフラグにもとづきでコーダにストリームを入力させる。
【0086】
次の23ビットは、図8Eに示される、ピクチャのサイズ情報が格納される。サイズ情報として23ビットを確保することで、8MB(メガバイト)までのデータサイズに対応でき、MPEGプロファイルの422@HLにも対応可能となる。
【0087】
次の2ビットでピクチャのタイプが示される。Bピクチャについては、参照方向の情報も示される。ピクチャのタイプは、より具体的には、例えば次のように記述される。
00:Iピクチャ
10:Pピクチャ
01:前方(未来)のフレームが参照されて復元されるBピクチャ。これは、例えばオープンGOPの場合の、ロングGOPビデオファイル先頭のBピクチャ、または、クローズドGOPの場合の各GOPの先頭のBピクチャである。
11:前方および後方のフレームが参照されて復元されるBピクチャ。
【0088】
次の38ビットは、当該ピクチャのロングGOPビデオファイル内におけるファイルアドレスが示される。ファイルアドレスに38ビットを割り当てることで、サイズが256GB(ギガバイト)までのロングGOPビデオファイルに対応可能である。例えば、1層で27GBの記録容量を有する記録層が8層まで形成された光ディスク10に対応可能である。
【0089】
このピクチャポインタテーブルは、ピクチャポインタファイルとして、非時系列メタデータと共に例えば記録媒体のNRT領域に記録される。光ディスク10がディスクドライブ11に装填された際に、このNRT領域に記録された非時系列メタデータとピクチャポインタファイルがディスクドライブ11により読み出され、光ディスク10が再生装置1のシステムに対してマウントされる。読み出された非時系列メタデータやピクチャポインタファイルは、例えばCPU14が有するRAMに保持される。CPU14は、RAMに保持されるピクチャポインタテーブルを参照することで、光ディスク10に記録されるクリップ中の任意のピクチャにアクセスすることができる。
【0090】
次に、この発明の実施の一形態による再生制御処理について、より詳細に説明する。先ず、図1のステップS2で説明した、目標フレームバッファパターンの作成について説明する。最初に、任意の目標再生フレームと、当該目標再生フレームに対して表示順で隣接する前後のフレームとを再生するために必要なフレームバッファサイズを求める。
【0091】
図10は、カレントフレーム(例えば目標再生フレーム)に対して表示順で1フレーム後または1フレーム前のフレームをデコードする場合の必要バッファ量の例を示す。図10において、出力フレーム(カレントフレーム)を「0」で示し、現在より表示順で順方向すなわち未来(後)になるフレームは「+」を、表示順で逆方向すなわち過去(前)になるフレームは「−」を、それぞれ付して示す。また、図中、「M」は、間にBピクチャがある場合の、基準ピクチャから次の基準ピクチャまでのピクチャの移動数、「N」は、1GOP内のピクチャ数を示す。例えば、GOPが「I20153486711910141213」の15枚のピクチャで構成される場合、M=3、N=15である。
【0092】
図10Aは、順方向に1フレームだけ再生を進める場合の例を示す。この場合、M=3のときに、目標再生フレームが隣り合ったBピクチャの表示順で前方のBピクチャの場合に、最もバッファが必要となる。この場合には、次のフレームタイミングで当該目標再生フレームから次のBピクチャに移動することになる。
【0093】
すなわち、この場合には、B4ピクチャおよびB5ピクチャは、それぞれI3ピクチャおよびP6ピクチャを用いてデコードされる。B5ピクチャのデコードが終了するまで、I3ピクチャはバッファから破棄できず、且つ、P6ピクチャはB5ピクチャの次に表示されるため、バッファ内に保持される。したがって、M+1=4ピクチャ分のバッファが必要となる。
【0094】
図10Bは、逆方向に1フレームだけ再生を進める(戻す)場合の例を示す。一般的なM=3およびN=15のオープンGOPであれば、目標再生フレームがI3’ピクチャである場合に、最もバッファが必要となる。この場合には、次のフレームタイミングで当該目標再生フレームから表示順で後方のB2’ピクチャに移動することになる。
【0095】
すなわち、この場合には、B2’ピクチャをデコードするために、I3’ピクチャと、B2’ピクチャの表示順で前のP15ピクチャとが必要となり、このP15ピクチャをデコードするために、当該P15ピクチャの属するGOPにおけるI3ピクチャ、P6ピクチャ、P9ピクチャ、P12ピクチャが順次、必要となる。したがって、N/M+2=7ピクチャ分のバッファが必要となる。ここで、N/Mは、GOPに含まれるIピクチャおよびPピクチャの枚数に相当する。
【0096】
図10Cは、順方向および逆方向の何れかの方向に対する1フレームの移行を考慮した場合の例である。一般的なM=3およびN=15のオープンGOPであれば、目標再生フレームがI3’ピクチャである場合に最もバッファが必要となる。この場合には、次のフレームタイミングで、当該I3’ピクチャの表示順で次のB4’ピクチャまたは表示順で前のB2’ピクチャに移動することになる。
【0097】
すなわち、この場合は、上述の図10Aの例と図10Bの例とを組み合わせた状態となり、目標再生フレームであるI3’ピクチャの表示順で次のB4’ピクチャをデコードするために、当該I3’ピクチャと、当該I3’ピクチャの次に現れる基準ピクチャであるP6’ピクチャとが必要となる。また、当該I3’ピクチャの表示順で前のB2’ピクチャをデコードするために、当該I3’ピクチャと、当該I3’ピクチャの属するGOPの前のGOPにおけるI3ピクチャ、P6ピクチャ、P9ピクチャ、P12ピクチャおよびP15ピクチャとが順次、必要となる。したがって、N/M+M+1=9ピクチャ分のバッファが必要となる。
【0098】
このように、目標再生フレームから表示順で隣接する前後のフレームに移動する場合には、9ピクチャ分のバッファが必要となる。
【0099】
この発明の実施の一形態では、フレームバッファにおいて、目標再生フレームに対して表示順で隣接する前後のピクチャが常に固定遅延で表示可能となるような、バッファの更新パターンを作成する。すなわち、デコードされバッファ上に存在する目標再生フレームに対して表示順で前後に隣接するフレームが常にデコードされバッファ上に存在する状態とする。さらに、逆方向再生を継続するために必要なフレームと、順方向再生を継続するために必要なフレームとを、常に、全てデコードし、バッファ上に溜め込んでおく。このようなバッファ上のパターンを、目標再生フレームを1フレーム毎に移動させた全パターンについて作成する。
【0100】
この状態において、目標再生フレームが1フレーム分移動し、更新された場合、新たにデコードが必要となるデータは、再生方向が順方向および逆方向によらず常に1フレーム分となる。したがって、再生方向が順方向および逆方向の何れの場合の1倍速以内の再生速度での変速再生が、1倍速デコーダを用いて実現可能となる。
【0101】
さらに、この状態において、逆方向の1倍速再生から、順方向の1倍速再生のコマンド速度の間では、固定遅延で再生出力結果を得ることができる。
【0102】
図11は、上述の考えに基づき作成した目標フレームバッファの一例の更新パターンを示す。この図11の例は、(N=15、M=3)であるロングGOPの場合に関する。1GOPが15ピクチャ(フレーム)で構成されるため、15のパターンからなる。図11中の各行に示されるように、目標再生フレームに対応したフレームがフレームバッファに格納された状態で、目標再生フレームを任意の方向に1フレームずつ移動させた場合に、更新されるフレームがそれぞれ1フレーム分で済み、順方向および逆方向の1倍速以内の可変速再生を、1倍速デコーダを用いて行うことができるようにしている。
【0103】
なお、図11中のI、PおよびBは、それぞれIピクチャ、PピクチャおよびBピクチャに基づくフレームであって、付加される数字は、GOP内の表示順を示す。基準となるGOP(カレントGOP)に属するピクチャによるフレームは、記号を付加しない。カレントGOPの1つ前のGOP(GOP(−)と呼ぶ)に属するピクチャによるフレームに対して、マイナス記号(−)を付加する。カレントGOPの1つ後のGOP(GOP(+)と呼ぶ)に属するピクチャによるフレームに対して、プラス記号(+)を付加する。
【0104】
この図11の更新パターンは、図の上側から下側に向けた方向が順方向の再生を示し、下側から上側に向けた方向が逆方向の再生を示す。すなわち、図11の上側から下側に1行分進むことで、目標再生フレームが1フレーム進み、下側から上側に1行分進むことで、目標再生フレームが1フレーム戻る。また、この図11の更新パターンは、循環的とされ、第1行目から目標再生フレームが1フレーム分戻ったときには、第15行目のフレームバッファの格納パターンに移行される。
【0105】
図11のフレームバッファの更新パターンにおいて、第1行目は、目標再生フレームがフレーム「I3」の場合のパターンの例である。目標再生フレーム「I3」から順方向に1フレーム進むために必要とされるフレームは、フレーム「B4」およびフレーム「P6」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「B2」、フレーム「P15−」、フレーム「P12−」、フレーム「P9−」、フレーム「P6−」およびフレーム「I3−」である。
【0106】
第2行目は、目標再生フレームがフレーム「B4」の場合のパターンの例である。目標再生フレーム「B4」から順方向に1フレーム進むために必要とされるフレームは、フレーム「B5」およびフレーム「P6」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「I3」、フレーム「P15−」、フレーム「P12−」、フレーム「P9−」、フレーム「P6−」およびフレーム「I3−」である。
【0107】
第3行目は、目標再生フレームがフレーム「B5」の場合のパターンの例である。目標再生フレーム「B5」から順方向に1フレーム進むために必要とされるフレームは、フレーム「P6」およびフレーム「P9」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「B4」、フレーム「I3」、フレーム「P12−」、フレーム「P9−」、フレーム「P6−」およびフレーム「I3−」である。
【0108】
第4行目は、目標再生フレームがフレーム「P6」の場合のパターンの例である。目標再生フレーム「P6」から順方向に1フレーム進むために必要とされるフレームは、フレーム「B7」およびフレーム「P9」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「B5」、フレーム「I3」、フレーム「P12−」、フレーム「P9−」、フレーム「P6−」およびフレーム「I3−」である。
【0109】
第5行目は、目標再生フレームがフレーム「B7」の場合のパターンの例である。目標再生フレーム「B7」から順方向に1フレーム進むために必要とされるフレームは、フレーム「B8」およびフレーム「P9」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「P6」、フレーム「I3」、フレーム「P12−」、フレーム「P9−」、フレーム「P6−」およびフレーム「I3−」である。
【0110】
第6行目は、目標再生フレームがフレーム「B8」の場合のパターンの例である。目標再生フレーム「B8」から順方向に1フレーム進むために必要とされるフレームは、フレーム「P9」およびフレーム「P12」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「B7」、フレーム「P6」、フレーム「I3」、フレーム「P9−」、フレーム「P6−」およびフレーム「I3−」である。
【0111】
第7行目は、目標再生フレームがフレーム「P9」の場合のパターンの例である。目標再生フレーム「P9」から順方向に1フレーム進むために必要とされるフレームは、フレーム「B10」およびフレーム「P12」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「P6」、フレーム「I3」、フレーム「P9−」、フレーム「P6−」およびフレーム「I3−」である。
【0112】
第8行目は、目標再生フレームがフレーム「B10」の場合のパターンの例である。目標再生フレーム「B10」から順方向に1フレーム進むために必要とされるフレームは、フレーム「B11」およびフレーム「P12」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「P9」、フレーム「P6」、フレーム「I3」、フレーム「P9−」、フレーム「P6−」およびフレーム「I3−」である。
【0113】
第9行目は、目標再生フレームがフレーム「B11」の場合のパターンの例である。目標再生フレーム「B11」から順方向に1フレーム進むために必要とされるフレームは、フレーム「P12」およびフレーム「P15」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「B10」、フレーム「P9」、フレーム「P6」、フレーム「I3」、フレーム「P6−」およびフレーム「I3−」である。
【0114】
第10行目は、目標再生フレームがフレーム「P12」の場合のパターンの例である。目標再生フレーム「P12」から順方向に1フレーム進むために必要とされるフレームは、フレーム「B13」およびフレーム「P15」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「B11」、フレーム「P9」、フレーム「P6」、フレーム「I3」、フレーム「P6−」およびフレーム「I3−」である。
【0115】
第11行目は、目標再生フレームがフレーム「B13」の場合のパターンの例である。目標再生フレーム「B13」から順方向に1フレーム進むために必要とされるフレームは、フレーム「B14」およびフレーム「P15」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「P12」、フレーム「P9」、フレーム「P6」、フレーム「I3」、フレーム「P6−」およびフレーム「I3−」である。
【0116】
第12行目は、目標再生フレームがフレーム「B14」の場合のパターンの例である。目標再生フレーム「B14」から順方向に1フレーム進むために必要とされるフレームは、フレーム「P15」およびフレーム「I3+」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「B13」、フレーム「P12」、フレーム「P9」、フレーム「P6」、フレーム「I3」およびフレーム「I3−」である。
【0117】
第13行目は、目標再生フレームがフレーム「P15」の場合のパターンの例である。目標再生フレーム「P15」から順方向に1フレーム進むために必要とされるフレームは、フレーム「B1+」およびフレーム「I3+」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「B14」、フレーム「P12」、フレーム「P9」、フレーム「P6」、フレーム「I3」およびフレーム「I3−」である。
【0118】
第14行目は、目標再生フレームがフレーム「B1+」の場合のパターンの例である。目標再生フレーム「B1+」から順方向に1フレーム進むために必要とされるフレームは、フレーム「B2+」およびフレーム「I3+」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「P15」、フレーム「P12」、フレーム「P9」、フレーム「P6」、フレーム「I3」およびフレーム「I3−」である。
【0119】
第15行目は、目標再生フレームがフレーム「B2+」の場合のパターンの例である。目標再生フレーム「B2+」から順方向に1フレーム進むために必要とされるフレームは、フレーム「I3+」およびフレーム「P6+」である。また、目標再生フレームから逆方向に1フレーム戻るために必要とされるフレームは、フレーム「B1+」フレーム「P15」、フレーム「P12」、フレーム「P9」、フレーム「P6」およびフレーム「I3」である。
【0120】
このように、図11に一例を示すフレームバッファの更新パターンでは、各フレーム毎の更新パターン間で、1フレーム分のみが更新されるようになっている。幾つかの例を挙げて、より具体的に説明する。
【0121】
第1の例として、目標再生フレームがPピクチャによるフレーム「P6」の場合について説明する。この場合、順方向および逆方向について1倍速以内の再生速度範囲においては、当該目標再生フレームの1フレームタイミング後に新たな目標再生フレームとなる可能性のあるフレームは、当該フレーム「P6」と、当該フレーム「P6」に対して表示順で前後に隣接するフレーム「B5」およびフレーム「B7」とである。
【0122】
目標再生フレームがフレーム「P6」の状態において、上述したような、目標再生フレームに基づき作成された目標フレームバッファパターンに従いデコードされたフレームがフレームバッファに格納された状態では(図11の第4行目のパターン参照)、目標再生フレーム「P6」と、その前後のフレーム「B5」およびフレーム「B7」は、それぞれ既にデコードされた状態でフレームバッファに格納されている。
【0123】
この状態から目標再生フレームがフレーム「B5」またはフレーム「B7」に移行された場合、移行された目標再生フレームに対する新たな目標フレームバッファパターンに基づいて、新たに必要となるフレームをデコードされた状態でフレームバッファに格納していく。
【0124】
これらのデータが格納されたフレームバッファの他の領域は、直前のデータが保持される。すなわち、図11の例では、第4行目に示されるように、目標再生フレームがフレーム「P6」のときは、フレームバッファに、当該フレーム「P6」と、当該フレーム「P6」と同じGOPに属するフレーム「I3」、フレーム「P9」、フレーム「B5」およびフレーム「B7」、ならびに、当該フレーム「P6」が属するGOPに対して1つ前のGOPに属するフレーム「I3−」、フレーム「P6−」、フレーム「P9−」およびフレーム「P12−」が格納される。
【0125】
この目標再生フレームがフレーム「P6」の場合、順方向に1フレーム分、目標再生フレームが移行すると、新たな目標再生フレームがフレーム「B7」となる。また、この新たな目標再生フレームに対して1フレームタイミング後にさらに新たな目標再生フレームとなる可能性があるフレームは、フレーム「B7」と、当該フレーム「B7」に対して表示順で前後に隣接するフレーム「P6」およびフレーム「B8」となる。
【0126】
なお、再生速度が順方向および逆方向に1倍速以内の場合、同一のフレームが2フレームタイミングで連続して出力される場合がある。この場合、次のフレームタイミングに移っても、目標再生フレームが変化しない。
【0127】
これらのうち、フレーム「P6」は、現在の目標再生フレームであるため、既にフレームバッファ上に存在している。また、フレーム「B8」をデコードするためには、フレーム「P6」およびフレーム「P9」が必要となる。フレーム「P6」およびフレーム「P9」は、それぞれフレーム「B7」をデコードするために用いられているので、既にフレームバッファ上に存在している。フレーム「B8」がこれらフレーム「P6」および「P9」を用いてデコードされる。
【0128】
一方、目標再生フレームがフレーム「B7」に移行した場合、目標再生フレームがフレーム「P6」の状態における逆方向側の表示順で隣接フレームであったフレーム「B5」は、不要となるため破棄される。フレームバッファ上の、この破棄されたフレーム「B5」の領域に、新たにデコードされたフレーム「B8」が格納され、フレームバッファが更新される。
【0129】
逆方向に1フレーム分、再生が戻されると、新たな目標再生フレームがフレーム「B5」となり、この新たな目標再生フレームに対して1フレームタイミング後にさらに新たな目標再生フレームとなる可能性のあるフレームは、フレーム「B5」と、フレーム「B4」およびフレーム「P6」とである。フレーム「P6」は、現在の目標再生フレームであるため、既にフレームバッファ上に存在している。また、フレーム「B4」をデコードするためには、フレーム「I3」およびフレーム「P6」が必要となる。フレーム「I3」を、フレームバッファ上に保持する。フレーム「B4」がこれらフレーム「I3」および「P6」を用いてデコードされる。
【0130】
一方、目標再生フレームがフレーム「P6」からフレーム「B5」に移行した場合、目標再生フレームが「P6」の状態における順方向側の隣接フレームであったフレーム「B7」は、不要となるため、破棄される。フレームバッファ上の、この破棄されたフレーム「B7」の領域に、新たにデコードされたフレーム「B4」が格納され、フレームバッファが更新される。
【0131】
このように、目標再生フレームがフレーム「P6」の状態から順方向に1フレーム分進んだ場合、フレームの更新は、フレーム「B5」からフレーム「B8」への1フレーム分のみ、行われる。目標再生フレームがフレーム「P6」の状態から逆方向に1フレーム分戻された場合も、フレームの更新は、フレーム「B7」からフレーム「B4」への1フレーム分のみ、行われる。
【0132】
第2の例として、目標再生フレームがBピクチャによるフレーム「B7」の場合について説明する。この場合、順方向および逆方向について1倍速以内の再生速度範囲においては、当該目標再生フレームの1フレームタイミング後に新たな目標再生フレームとなる可能性のあるフレームは、当該フレーム「B7」と、当該フレーム「B7」に対して表示順で前後に隣接するフレーム「P6」および「B8」とである。
【0133】
目標再生フレームがフレーム「B7」の状態において、上述したような、目標再生フレームに基づき作成された目標フレームバッファパターンに従いデコードされたフレームがフレームバッファに格納された状態では(図11の第5行目のパターン参照)、目標再生フレーム「B7」と、その前後のフレーム「P6」およびフレーム「B8」は、それぞれ既にデコードされた状態でフレームバッファに格納されている。
【0134】
この状態から目標再生フレームがフレーム「P6」またはフレーム「B8」に移行された場合、移行された目標再生フレームに対する新たな目標フレームバッファパターンに基づいて、新たに必要となるフレームをデコードされた状態でフレームバッファに格納していく。
【0135】
これらのデータが格納されたフレームバッファの他の領域は、直前のデータが保持される。すなわち、図11の例では、第5行目に示されるように、目標再生フレームがフレーム「B7」のときには、フレームバッファに、当該フレーム「B7」と、当該フレーム「B7」と同じGOPに属するフレーム「I3」、フレーム「P9」およびフレーム「B8」、ならびに、当該フレーム「B7」が属するGOPに対して1つ前のGOPに属するフレーム「I3−」、フレーム「P6−」、フレーム「P9−」およびフレーム「P12−」が格納される。
【0136】
この目標再生フレームがフレーム「B7」の場合、順方向に1フレーム分、目標再生フレームが移行すると、新たな目標再生フレームがフレーム「B8」になる。また、この新たな目標再生フレームに対して1フレームタイミング後にさらに新たな目標再生フレームとなる可能性があるフレームは、当該フレーム「B8」と、当該フレーム「B8」に対して表示順で前後に隣接するフレーム「B7」およびフレーム「P9」とである。
【0137】
これらのうち、フレーム「B7」は、現在の目標再生フレームであるため、既にフレームバッファ上に存在している。また、フレーム「B8」をデコードするためには、フレーム「P6」およびフレーム「P9」が必要となる。フレーム「P6」およびフレーム「P9」は、それぞれフレーム「B7」をデコードするために必要なフレームであるので、既にフレームバッファ上に存在している。フレーム「B8」がこれらフレーム「P6」および「P9」を用いてデコードされる。また、フレーム「P9」も、既にフレームバッファ上に存在している。
【0138】
この場合には、目標再生フレームがフレーム「B7」の状態における逆方向側の表示順で隣接フレームであったフレーム「P6」は、フレーム「B8」をデコードするために用いられるため、破棄されない。さらに順方向に1フレーム、再生が進んだ際に用いられるフレーム「P12」が、フレーム「P9」を用いてデコードされる。また、バッファメモリ内に存在する最も前のGOPに属するフレームのうち、バッファメモリ内に存在し最も表示順で新しいフレームであるフレーム「P12−」を破棄し、デコードされたフレーム「P12」を格納する。
【0139】
逆方向に1フレーム分、再生が戻されると、新たな目標再生フレームがフレーム「P6」となり、この新たな目標再生フレームに対して1フレームタイミング後にさらに新たな目標再生フレームとなる可能性のあるフレームは、フレーム「P6」と、フレーム「B5」およびフレーム「B7」とである。フレーム「B7」は、現在の目標再生フレームであるため、既にフレームバッファ上に存在している。また、フレーム「B5」をデコードするためには、フレーム「I3」およびフレーム「P6」が必要となる。フレーム「I3」をフレームバッファ上に保持する。フレーム「B5」がこれらフレーム「I3」およびフレーム「P6」を用いてデコードされる。
【0140】
一方、目標再生フレームがフレーム「B7」からフレーム「P6」に移行した場合、目標再生フレームが「B7」の状態における順方向側の隣接フレームであったフレーム「B8」は、不要となるため、破棄される。フレームバッファ上の、この破棄されたフレーム「B8」の領域に、新たにデコードされたフレーム「B5」が格納され、フレームバッファが更新される。
【0141】
このように、目標再生フレームがフレーム「B7」の状態から順方向に1フレーム進んだ場合、フレームの更新は、フレーム「P12−」からフレーム「P12」への1フレーム分のみ、行われる。目標再生フレームがフレーム「B7」の状態から逆方向に1フレーム分戻された場合も、フレームの更新は、フレーム「B8」からフレーム「B5」への1フレーム分のみ、行われる。
【0142】
第3の例として、目標再生フレームがIピクチャによるフレーム「I3」の場合について説明する。この場合、順方向および逆方向について1倍速以内の再生速度範囲においては、当該目標再生フレームの1フレームタイミング後に新たな目標再生フレームとなる可能性のあるフレームは、当該フレーム「I3」と、当該フレーム「I3」に対して表示順で前後に隣接するフレーム「B2」およびフレーム「B4」とである。
【0143】
目標再生フレームがフレーム「I3」の状態において、上述したような、目標再生フレームに基づき作成された目標フレームバッファパターンに従いデコードされたデータがフレームバッファに格納された状態では(図11の第1行目のパターン参照)、目標再生フレーム「I3」と、その前後のフレーム「B2」およびフレーム「B4」は、それぞれ既にデコードされた状態でフレームバッファに格納されている。
【0144】
この状態から目標再生フレームがフレーム「B2」またはフレーム「B4」に移行された場合、移行された目標再生フレームに対する新たな目標フレームバッファパターンに基づいて、新たに必要となるフレームをデコードされた状態でフレームバッファに格納していく。
【0145】
これらのデータが格納されたフレームバッファの他の領域は、直前のデータが保持される。すなわち、図11の例では、第1行目に示されるように、目標再生フレームが「I3」のときには、フレームバッファに、当該フレーム「I3」と、当該フレーム「I3」と同じGOPに属する、フレーム「P6」、フレーム「B2」およびフレーム「B4」、ならびに、当該フレーム「I3」が属するGOPに対して1つ前のGOPに属するフレーム「I3−」、フレーム「P6−」、フレーム「P9」、フレーム「P12−」およびフレーム「P15」とが格納される。
【0146】
目標再生フレームがフレーム「I3」の場合、順方向に1フレーム分、目標再生フレームが移行すると、新たな目標再生フレームがフレーム「B4」になる。また、この新たな目標再生フレームに対して1フレームタイミング後にさらに新たな目標再生フレームとなる可能性があるフレームは、当該フレーム「B4」と、当該フレームに対して表示順で前後に隣接するフレーム「I3」およびフレーム「B5」とである。
【0147】
これらのうち、フレーム「I3」は、現在の目標再生フレームであるため、既にフレームバッファ上に存在している。また、フレーム「B5」をデコードするためには、フレーム「I3」およびフレーム「P6」が必要となる。フレーム「P6」は、フレーム「B4」をデコードするために用いられているので、既にフレームバッファ上に存在している。フレーム「B5」がこれらフレーム「I3」および「P6」を用いてデコードされる。
【0148】
この場合には、目標再生フレームが「I3」の状態における逆方向側の目標再生フレームであるフレーム「B2」は、不要となるため、破棄される。フレームバッファ上の、この破棄されるフレーム「B2」の領域にデコードされたフレーム「B5」が格納され、フレームバッファが更新される。
【0149】
逆方向に1フレーム分、再生が戻されると、新たな目標再生フレームがフレーム「B2」となり、この新たな目標再生フレーム対して1フレームタイミング後に新たな目標再生フレームとなる可能性のあるフレームは、フレーム「B2」と、フレーム「B1」およびフレーム「I3」とである。フレーム「I3」は、現在の目標再生フレームであるため、既にフレームバッファ上に存在している。また、フレーム「B1」をデコードするためには、フレーム「I3」と、フレーム「I3」が属するGOPの1つ前のGOPに属するフレーム「P15−」が必要となる。フレーム「B1」がこれらフレーム「P15−」および「I3」を用いてデコードされる。
【0150】
一方、目標再生フレームがフレーム「I3」からフレーム「B2」に移行した場合、目標再生フレームがフレーム「I3」の状態における順方向の隣接フレームであったフレーム「B4」は、不要となるため、破棄される。フレームバッファ上の、この破棄されたフレーム「B4」の領域に、新たにデコードされたフレーム「B1」が格納され、フレームバッファが更新される。
【0151】
このように、目標再生フレームがフレーム「I3」の状態から順方向に1フレーム進んだ場合、フレームの更新は、フレーム「B2」からフレーム「B5」への1フレーム分のみ、行われる。目標再生フレームがフレーム「I3」の状態から逆方向に1フレーム分戻された場合も、フレームの更新は、フレーム「B4」からフレーム「B1」への1フレーム分のみ、行われる。
【0152】
なお、上述したように、目標再生フレームが他のフレームに移行される際には、バッファメモリに格納された1フレームが破棄され、破棄されたフレーム領域に新たな1フレームがデコードされて格納され、バッファメモリが更新される。このとき、バッファメモリから破棄するフレームを、次のルールに基づき決めることができる。
(1)目標再生フレームおよび表示順で目標再生フレームに隣接するフレーム以外のBピクチャによるフレームは、破棄する。
(2)上述の(1)のルールに従い破棄するBピクチャによるフレームが存在しなかった場合、バッファメモリ上に存在する、下記(2a)または(2b)の条件を満たすIまたはPピクチャによるフレームを破棄する。
(2a)順方向への目標再生フレーム移行の場合、目標再生フレームが存在するGOPから逆方向に最も離れたGOPにおいて、そのGOPに属する最後尾のIまたはPピクチャ。
(2b)逆方向への目標再生フレーム移行の場合、目標再生フレームが存在するGOPから順方向に最も離れたGOPにおいて、そのGOPに属する最後尾のIまたはPピクチャ。
【0153】
上述のように、この発明の実施の一形態によるバッファメモリの更新パターンに従いバッファメモリ上にデータを溜め込んでおけば、現在の目標再生フレームがIピクチャによるフレーム、PピクチャによるフレームおよびBピクチャによるフレームの何れであっても、任意の方向への1フレーム分の移動に対してバッファメモリ上で行進されるデータが1フレーム分のみで済む。したがって、順方向および逆方向の1倍速以内の可変速再生を、1倍速デコーダを用いて固定遅延で実行することができる。
【0154】
なお、上述では、現在の目標再生フレームとして、GOPを構成するIピクチャ、PピクチャおよびBピクチャのそれぞれについて一例ずつ例を挙げて説明を行ったが、説明を省略した他のフレームが現在の目標再生フレームの場合でも、同様にして、任意の方向への1フレーム分の移動に対して、バッファメモリ上の1フレーム分のデータのみが更新される。
【0155】
次に、上述したような目標フレームバッファのパターンの一例の作成方法について、図12のフローチャートを用いて説明する。また、以下では、目標とされるフレーム(カレントフレームと呼ぶ)がBピクチャによるフレームであるものとして説明する。
【0156】
先ず、ステップS10で、カレントフレームが属するカレントGOPのIピクチャ(I0)を取得する。図13Aに一例が示されるように、カレントフレームに対応するピクチャから記録媒体上の順序で逆方向に向けて、Iピクチャを検索する。なお、この段階では、目標フレームバッファパターンのフレームは、一つも確定していない(図14A参照)。
【0157】
カレントGOPの先頭Iピクチャ(I0)ピクチャが取得されると、ステップS11で、カレントフレームに対応するピクチャから記録媒体上の順序で順方向に向けて、カレントフレームより2フレーム進んだ位置以降のIピクチャまたはPピクチャ(P0)を検索する(図13B参照)。この段階では、目標フレームバッファパターンのフレームは、一つも確定していない(図14B参照)。
【0158】
ステップS12で、上述したステップS10およびステップS11で取得されたピクチャ(I0)からピクチャ(P0)までのIおよび/またはPピクチャを記録媒体から検索する。例えば、図13Cに一例が示されるように、ステップS10で検索されたピクチャ(I0)を目標フレームバッファパターンに用いるフレームとして確定する。さらに、ピクチャ(I0)から記録媒体上の順序で順方向に向けて、次のPピクチャ(P)が検索される。検索されたPピクチャを、目標フレームバッファパターンに用いるフレームとして確定する。このように、記録媒体から順次、検索されたPまたはIピクチャに基づき、目標フレームバッファパターンに用いる、カレントGOPのフレームが順次、確定される(図14C参照)。
【0159】
ステップS12で、カレントGOPのIおよびPピクチャによるフレームが目標フレームバッファパターンに用いるフレームとして確定されると、ステップS13で、記録媒体上の順序で、カレントフレームの1つ前のフレームからカレントフレームの1つ後のフレームまでの間に存在するBピクチャが検索される(図13D参照)。検索されたBピクチャによるフレームは、目標フレームバッファパターンに用いられる、カレントGOPのフレームとして確定される(図14D参照)。
【0160】
すなわち、上述したステップS11およびステップS12で、カレントフレームの1つ前のフレームからカレントフレームの1つ後のフレームまでの間に存在するBピクチャをデコードするために用いられるIおよび/またはPピクチャによるフレームが、目標フレームバッファパターンに用いられるフレームとして確定されている。ステップS13では、これら確定された、Iおよび/またはPピクチャによるフレームを用いてデコードされるBピクチャによるフレームが、目標フレームバッファパターンに用いるフレームとして確定される。
【0161】
ステップS13までの処理で、カレントGOPの、目標フレームバッファパターンに用いるフレームが全て確定されると、ステップS14で、カレントGOPの1つ前のGOP内の先頭Iピクチャ(I-1)が検索される(図13E参照)。例えば、カレントGOPの先頭のIピクチャ(I0)を起点として、記録媒体上の順序で逆方向に向けてIピクチャが検索され、検索されたIピクチャ(I-1)に基づき、記録媒体上の順序で順方向に、Pピクチャが検索される(図13F参照)。そして、検索されたカレントGOPの1つ前のGOPのIおよび/またはPピクチャによるフレームが、目標フレームバッファパターンに用いるフレームとして確定される(図14F参照)。
【0162】
上述のステップS14からステップS15までの処理は、バッファメモリが埋められるまで繰り返される(ステップS16)。
【0163】
なお、記録媒体上に記録されたピクチャの位置やタイプ(Iピクチャ、PピクチャおよびBピクチャ)は、図9を用いて説明したピクチャポインタファイルを参照することで知ることができる。例えばシステムやより上位のシステムから、あるフレームの再生が指示されると、CPU14は、再生を指示されたフレームを目標再生フレームとし、当該目標再生フレームが属するGOPをカレントGOPとしてピクチャポインタファイルを検索し、カレントGOPのIピクチャの位置を取得する。ピクチャポインタファイルには、上述のように、ピクチャタイプ、そのピクチャがGOPの先頭のピクチャであるか否かを示すフラグ、ピクチャのサイズ情報、先頭アドレスが記述されているので、これらの情報に基づき記録媒体上の所望のピクチャを検索することが可能となっている。
【0164】
目標再生フレームに基づき目標フレームバッファパターンが確定し、確定された目標フレームバッファパターンに従いフレームバッファがデコードされたフレームで埋められると、図11を用いて説明したような動作により、再生指示に対して所定の固定遅延で、順方向および逆方向の1倍速以内の再生が行われる。
【0165】
なお、ここでは、目標再生フレームがBピクチャであるものとして説明したが、上述の図12のフローチャートで説明した処理は、カレントフレームがIピクチャおよびPピクチャの場合にも同様にして適用できる。
【0166】
また、システムやより上位のシステムから再生を指示されたフレームを目標再生フレームとして、上述の図12のフローチャートに従い、当該目標再生フレームに対応した目標フレームバッファパターンを作成する。この処理を、例えば目標再生フレームが指示される毎に行う。最初の目標再生フレームの指示に基づき、GOP内の全てのフレームについて作成してもよい。作成された目標フレームバッファパターンは、例えばRAM36に記憶される。
【0167】
これに限らず、再生するクリップのGOPの構成が予め分かっていれば、上述の図12のフローチャートに示される処理を、GOPを構成する各ピクチャに対して行って、上述した図11のようなフレームバッファの更新パターンを予め作成しておくことも可能である。また、再生装置1において適用可能なGOPの構成が決められていれば、予め更新パターンを作成し、ROM35に記憶させておくことも可能である。
【0168】
CPU14は、操作部15に対する、順方向への1倍速以内または逆方向への1倍速以内の再生指示に応じて、出力フレームに対応する更新パターンを参照し、フレームタイミング毎に光ディスク10から読み出すピクチャを指示し、フレームバッファの更新を行う。
【0169】
次に、フレームバッファの更新パターンに基づく再生制御動作について説明する。再生制御は、フレームタイミングで同期を取られて、フレーム毎に順次、行われる。図15は、この発明の実施の一形態による同期制御を概略的に示す。この図15の例では、3フレームを周期として、1フレーム分のビデオデータのデコードが行われると共に、このデコードに同期して、フレームバッファ上の1フレーム分のビデオデータが出力される。
【0170】
先ず、第1フレーム目では、現在フレームバッファに格納されているフレームの情報であって、CPU14により取得されるフレームバッファ情報と、ディスクドライブ11におけるリード情報と、目標速度情報とから、目標再生フレームが確定される(ステップS20)。リード情報は、光ディスク10から既に読み出され、ディスクドライブ11のキャッシュメモリ12に溜め込まれているピクチャの情報である。また、目標速度情報は、操作部15に対する操作や、より上位のアプリケーションなどからのコマンドにより、CPU14に対して供給される、再生速度および方向を示す情報である。
【0171】
目標再生フレームが確定されると、デコーダ22に転送するピクチャが確定される(ステップS21)。すなわち、図11を用いて説明したフレームバッファの更新パターンに基づき、目標再生フレームの確定に伴いデコードすべきピクチャが確定される。
【0172】
例えば、図11の第4行目の例でいうと、再生方向が順方向であれば、現在の目標再生フレーム「P6」に対して、新たな目標再生フレームは、フレーム「B7」またはフレーム「P6」の何れかに確定される。新たな目標再生フレームがフレーム「B7」およびフレーム「P6」の何方に確定されるかは、目標速度情報や、指示のタイミングなどに基づき一意的に決められる。ここでは、新たな目標再生フレームがフレーム「B7」に確定されたものとして説明する。
【0173】
さらに、第4行目のフレームバッファ情報と、新たな目標再生フレームが目標再生フレームとされているフレームバッファ情報とが比較され、新たにデコードされる必要があるフレームと、不要となるフレームとが抽出される。新たな目標再生フレームがフレーム「B7」であるこの例では、第4行目のフレームバッファ情報と次の第5行目のフレームバッファ情報とが比較され、フレーム「B5」が不要となると共に、フレーム「B8」がデコードされている必要があることが分かる。
【0174】
ステップS21で転送するピクチャが確定されると、次の第2フレーム目のタイミングで、当該ピクチャがデコーダ22に対して転送される(ステップS22)。例えば、CPU14は、ディスクドライブ11に対して、転送が確定されたピクチャを光ディスク10から読み出すように要求する。この要求に応じて、ディスクドライブ11により、光ディスク10からピクチャ(上述の例では、フレーム「B8」に対応するピクチャ)が読み出される。読み出されたピクチャがデコーダ22に転送されると共に、読み出されたピクチャをデコードするために必要な他のフレームがある場合は、フレームバッファから当該他のフレームが読み出され、デコーダ22に転送される。
【0175】
フレーム「B8」をデコードするこの例では、フレーム「B8」に対応するピクチャと、フレーム「B8」をデコードするための他のフレーム「P6」および「P9」とがデコーダ22に転送される。
【0176】
なお、実際には、転送が確定されたピクチャの転送は、上述したように、ディスクドライブ11が有するキャッシュメモリ12に対してアクセスされてなされ、キャッシュメモリ12からデコーダ22に対して、DMA(Direct Memory Access)転送によりCPU14を介さないで行われる。
【0177】
ディスクドライブ11からデコーダ22へのピクチャの転送は、次の第2フレーム目のタイミングに同期して行われる(ステップS22)。また、ステップS21での転送ピクチャの確定に伴い、当該ピクチャに対するデコード情報が確定される(ステップS23)。例えば、確定された転送ピクチャのヘッダ情報から取り出されたデコードに必要なパラメータや、デコードに必要な他のフレームの情報がデコード情報として確定される。これら確定されたデコード情報は、デコーダ22に渡される。
【0178】
デコーダ22は、ステップS23で転送されたデコード情報に基づき、ステップS22で転送されたピクチャのデコードを、次の第3フレーム目のタイミングに同期して開始する(ステップS24)。デコードされたピクチャ(フレーム)は、フレームバッファの所定のバンクに書き込まれ、フレームバッファが更新される。上述の図11の第4行目の例では、バッファメモリ上のフレーム「B5」が書き込まれているバンクに対して、デコードされたフレーム「B8」のデータが上書きされる(図11の第5行目参照)。
【0179】
一方、上述したステップS20で目標再生フレームが確定されると、出力するビデオデータの情報が確定される(ステップS25)。上述の図11の第4行目の例では、出力ビデオデータとしてフレーム「P6」が確定される。この確定された出力ビデオデータの情報が出力データ制御部23に渡される。出力データ制御部23では、渡された情報に基づき、第3フレーム目の開始タイミングまでに、ビデオ出力の設定を行う(ステップS26)。そして、この設定に基づき、第3フレーム目に同期して、フレーム「P6」が出力される(ステップS27)。
【0180】
なお、1倍速以下の順方向の再生は、例えば、上述したステップS20において、上位のアプリケーションからなど供給された再生速度情報に応じて、目標再生フレームを次のフレームに進めるか否かを制御することで可能である。一例として、順方向に1/2倍速で再生を行う場合には、出力するフレームを2フレームタイミング毎に1フレームだけ更新すればよい。これは、例えば、2フレームに1回の割合で、目標再生フレームを更新することで可能である。目標再生フレームが更新されなければ、直前の処理と同一のフレームバッファのパターンに基づき処理が行われることになるため、直前のフレームタイミングと同一のフレームが出力されることになる。このとき、ディスクドライブ1による光ディスク10に対するアクセス動作や、デコーダ22のデコード動作なども停止するようにすると、好ましい。
【0181】
上述では、再生方向が順方向の場合の処理について説明したが、再生方法が逆方向の場合にも、同様の処理が行われる。第1フレーム目で、フレームバッファ情報と、リード情報と、目標速度情報とから、目標再生フレームが確定される(ステップS20)。目標再生フレームが確定されると、デコーダ22に転送するピクチャが確定される(ステップS21)。図11の第4行目の例でいうと、再生方向が逆方向なので、目標再生フレームがフレーム「B5」またはフレーム「P6」の何れかに確定される。ここでは、目標再生フレームがフレーム「B5」に確定されるものとする。さらに、第4行目のフレームバッファ情報と、目標再生フレームが出力フレームとされている第3行目のフレームバッファ情報とが比較され、フレーム「B7」が不要になると共に、フレーム「B4」がデコードされている必要があることが分かる。
【0182】
ステップS21で転送するピクチャが確定されると、次の第2フレーム目のタイミングに同期して、当該ピクチャがデコーダ22に対して転送される(ステップS22)。このとき、当該ピクチャをデコードするために必要な他のピクチャがある場合には、当該他のピクチャもフレームバッファから読み出されてデコーダ22に転送される。フレーム「B4」をデコードするこの例では、フレーム「B4」をデコードするために用いられる、フレーム「I3」および「P6」も、デコーダ22に転送される。フレーム「I3」および「P6」は、図11の第4行目に示されるように、フレームバッファ上に既に存在する。
【0183】
ステップS21での転送ピクチャの確定に伴い、当該ピクチャに対するデコード情報が確定される(ステップS23)。確定されたデコード情報は、デコーダ22に渡される。デコーダ22は、ステップS23で転送されたデコード情報に基づき、ステップS22で転送されたピクチャのデコードを、次の第3フレーム目のタイミングに同期して開始する(ステップS24)。デコードされたピクチャ(フレーム)は、フレームバッファの所定のバンクに書き込まれ、フレームバッファが更新される。上述の図11の第4行目の例では、バッファメモリ上のフレーム「B7」が書き込まれているバンクに対して、デコードされたフレーム「B4」のデータが上書きされる(図11の第3行目参照)。
【0184】
一方、上述したステップS20で目標再生フレームが確定されると、出力するビデオデータの情報が確定される(ステップS25)。上述の図11の第4行目の例では、出力ビデオデータとしてフレーム「P6」が確定される。この確定された出力ビデオデータの情報が出力データ制御部23に渡される。出力データ制御部23では、渡された情報に基づき、第3フレーム目の開始タイミングまでに、ビデオ出力の設定を行う(ステップS26)。そして、この設定に基づき、第3フレーム目に同期して、フレーム「P6」が出力される(ステップS27)
【0185】
なお、再生方向が順方向および逆方向の何れの場合においても、上述のステップS20〜ステップS27で説明した処理は、フレームタイミング毎に順次、実行される。すなわち、第1フレーム目に同期して上述のステップS20の処理による目標再生フレームが確定される。確定された目標再生フレームを新たな出力フレームとして、この新たな出力フレームに対応する新たな目標再生フレームの確定処理が次の第2フレーム目に同期して開始される。
【0186】
この新たな目標再生フレームの、ディスクドライブ11からデコーダ22への転送処理は、次の第3フレーム目に同期して行われるため、1つ前の処理と干渉することがない。同様に、デコーダ22によるデコード処理も、図示されない第4フレーム目に同期して行われることになるため、1つ前の処理と干渉することがない。
【0187】
このように、この発明によれば、順方向の1倍速再生から逆方向の1倍速再生にわたる可変速再生において、与えられた再生速度および再生方向指示コマンドに対して固定的な遅延で、コマ落ちのない再生出力を、1倍速デコーダを用いて実現することができる。
【0188】
なお、上述の図15のシーケンスにおいて、ステップS20で目標再生フレームが確定してから、その目標再生フレームが目標再生フレームの確定から固定遅延で以てステップS27でビデオ出力されるまでの間は、ステップS22のデータ転送処理およびステップS24のデコード処理がそれぞれ平均して1ピクチャ/フレーム時間に収まる必要がある。換言すれば、ステップS22のデータ転送処理およびステップS24のデコード処理は、それぞれ平均して1ピクチャ/フレーム時間に収まっていれば、それぞれの処理時間を1フレーム時間に固定的とする必要は、無い。
【0189】
ピクチャのデコードに1倍速デコーダを用い、順方向および逆方向に1倍速以内の再生を、上述したような目標フレームバッファパターンに基づく制御で以て固定遅延で行う場合、上述のように、目標再生フレームが移行する毎に、1フレームのデコードが行われ、それに伴いバッファメモリ上の1フレームが破棄される。そのため、ステップS22のデータ転送処理およびステップS24のデコード処理は、それぞれ1ピクチャ/フレーム時間の処理に収束するように推移し、全体として、図15に示されるような3フレーム周期に収束する。
【0190】
このように、この発明によれば、順方向の1倍速再生から逆方向の1倍速再生にわたる可変速再生において、与えられた再生速度および再生方向指示コマンドに対して固定的な遅延で、コマ落ちのない再生出力を、1倍速デコーダを用いて実現することができる。
【0191】
上述では、この発明が記録媒体として光ディスクを用い、年輪構造でクリップが記録されている場合に適用されるように説明したが、これはこの例に限定されない。例えば、記録媒体上の記録フォーマットは、年輪構造に限られず、他のフォーマットであってもよい。また、記録媒体は、光ディスクに限られず、ハードディスクドライブや、半導体メモリであってもよい。さらに、この発明が記録媒体から再生されたデータに対して適用されるように説明したが、これはこの例に限定されず、安定的にストリームが供給可能な状況であれば、外部から供給されたストリームデータをデコードするようなデコーダ装置にもこの発明を適用することができる。
【0192】
また、上述では、再生装置1が光ディスク10に記録されたビデオデータを再生する専用的なハードウェアであるように説明したが、これはこの例に限らず、例えばパーソナルコンピュータといった汎用的なコンピュータ装置(図示しない)を、再生装置1として用いることもできる。この場合、コンピュータ装置に搭載されるプログラムによって、再生装置1の機能を実現させることができる。またこの場合、ビデオデータのデコード処理は、ソフトウェア処理によりCPUで行ってもよいし、専用的なハードウェアをコンピュータ装置に搭載することもできる。
【図面の簡単な説明】
【0193】
【図1】この発明による再生制御処理を概念的に示す略線図である。
【図2】この発明の実施の一形態に適用可能な再生装置の一例の構成を概略的に示すブロック図である。
【図3】デコーダの一例の構成を概略的に示すブロック図である。
【図4】デコーダの一例の構成をより具体的に示すブロック図である。
【図5】ディスク状記録媒体における一例のデータ配置を示す略線図である。
【図6】クリップについて説明するための略線図である。
【図7】光ディスクに対して年輪データが形成された一例の様子を示す略線図である。
【図8】MPEG2のロングGOPにおける一例のデータ構造を示す略線図である。
【図9】ピクチャポインタ情報が記述されるピクチャポインタテーブルのより具体的な例を示す略線図である。
【図10】カレントフレームに対して表示順で1フレーム後または1フレーム前のフレームをデコードする場合の必要バッファ量の例を示す略線図である。
【図11】この発明の実施の一形態による目標フレームバッファの一例の更新パターンを示す略線図である。
【図12】目標フレームバッファのパターンの一例の作成方法を示すフローチャートである。
【図13】目標フレームバッファのパターンの一例の作成方法を説明するための略線図である。
【図14】目標フレームバッファのパターンの一例の作成方法を説明するための略線図である。
【図15】この発明の実施の一形態による同期制御を概略的に示す略線図である。
【図16】ロングGOPの場合のデコード処理について説明するための略線図である。
【符号の説明】
【0194】
1 再生装置
10 光ディスク
11 ディスクドライブ
12 キャッシュメモリ
13 デコーダ
13A フレームメモリ(フレームバッファ)
14 CPU
22 MPEGデコーダ
23 出力データ制御部
33 予測復元部
35 ROM
36 RAM

【特許請求の範囲】
【請求項1】
予測符号化によるフレーム間圧縮を用いて圧縮符号化されランダムアクセス可能な記録媒体に記録されたビデオデータを、逆方向の1倍速再生から順方向の1倍速再生まで可変速に再生するようにした再生装置において、
複数フレーム分のビデオデータを一時的に格納可能なフレームバッファと、
次に再生されるべき目標再生フレームに対する上記フレームバッファの目標パターンを作成する目標パターン作成部と、
現在の上記フレームバッファの状態と上記目標パターンとを比較する比較部と、
上記比較部による比較結果に基づき、新たにデコードが必要なフレームを抽出すると共に上記現在のフレームバッファの状態で不要になるフレームを抽出するフレームバッファ制御部と
を有する
ことを特徴とする再生装置。
【請求項2】
請求項1に記載の再生装置において、
上記フレームバッファ制御部により抽出された上記新たにデコードが必要なフレームの入力を開始し、該入力が開始されたフレームをデコードして上記フレームバッファ上の上記不要になるフレームの領域に対して格納するように制御するデコード制御部と、
上記フレームバッファに格納された複数のフレームのうち出力フレームを設定する出力制御部と
をさらに有する
ことを特徴とする再生装置。
【請求項3】
請求項1に記載の再生装置において、
上記目標パターンは、
少なくとも、上記目標再生フレームと、該目標再生フレームに時間的に隣接する2つのフレームと、該目標再生フレームから該隣接する2つのフレームそれぞれの方向について少なくとも1フレーム分の再生をさらに継続するために必要なフレームと
からなる
ことを特徴とする再生装置。
【請求項4】
請求項1に記載の再生装置において、
上記目標パターンは、
ビデオデータの再生に伴いフレーム毎に順次作成され記憶媒体に記憶されるようにした
ことを特徴とする再生装置。
【請求項5】
請求項1に記載の再生装置において、
上記目標パターンは、
予め作成され記憶媒体に記憶されている
ことを特徴とする再生装置。
【請求項6】
予測符号化によるフレーム間圧縮を用いて圧縮符号化されランダムアクセス可能な記録媒体に記録されたビデオデータを、逆方向の1倍速再生から順方向の1倍速再生まで可変速に再生するようにした再生方法において、
次に再生されるべき目標再生フレームに対する、複数フレーム分のビデオデータを一時的に格納可能なフレームバッファの目標パターンを作成する目標パターン作成のステップと、
現在の上記フレームバッファの状態と上記目標パターンとを比較する比較のステップと、
上記比較のステップによる比較結果に基づき、新たにデコードが必要なフレームを抽出すると共に上記現在のフレームバッファの状態で不要になるフレームを抽出するステップと
を有する
ことを特徴とする再生方法。
【請求項7】
予測符号化によるフレーム間圧縮を用いて圧縮符号化されランダムアクセス可能な記録媒体に記録されたビデオデータを、逆方向の1倍速再生から順方向の1倍速再生まで可変速に再生するようにした再生方法をコンピュータ装置に実行させる再生プログラムにおいて、
次に再生されるべき目標再生フレームに対する、複数フレーム分のビデオデータを一時的に格納可能なフレームバッファの目標パターンを作成する目標パターン作成のステップと、
現在の上記フレームバッファの状態と上記目標パターンとを比較する比較のステップと、
上記比較のステップによる比較結果に基づき、新たにデコードが必要なフレームを抽出すると共に上記現在のフレームバッファの状態で不要になるフレームを抽出するステップと
を有する再生方法をコンピュータ装置に実行させる
ことを特徴とする再生プログラム。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate


【公開番号】特開2007−73151(P2007−73151A)
【公開日】平成19年3月22日(2007.3.22)
【国際特許分類】
【出願番号】特願2005−260742(P2005−260742)
【出願日】平成17年9月8日(2005.9.8)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】