情報記録媒体、画像符号化方法、および画像復号方法
【課題】 ＶＣ−１においてランダムアクセス単位の先頭がＰ／Ｉピクチャであると、シームレス接続やマルチアングル再生時に、Ｐ／Ｉピクチャの第１フィールドであるＰピクチャが復号できず、解像度が半分になるという課題があった。
【解決手段】 クローズドＧＯＰ型のＲＡＵであることを識別するフラグがセットされている際には、ＲＡＵの先頭にはＰ／Ｉピクチャを配置しない。画像復号装置では、ＲＡＵの先頭がＰ／Ｉピクチャであるかどうかに応じて表示動作を切替えるための手段が不要となる。
【解決手段】 クローズドＧＯＰ型のＲＡＵであることを識別するフラグがセットされている際には、ＲＡＵの先頭にはＰ／Ｉピクチャを配置しない。画像復号装置では、ＲＡＵの先頭がＰ／Ｉピクチャであるかどうかに応じて表示動作を切替えるための手段が不要となる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、シームレス接続やマルチアングル再生などの特殊再生時に有効な補助情報を符号化する画像符号化方法と画像復号方法、およびそのストリームに関する。
【背景技術】
【０００２】
近年、音声，画像，その他の画素値を統合的に扱うマルチメディア時代を迎え、従来からの情報メディア，つまり新聞，雑誌，テレビ，ラジオ，電話等の情報を人に伝達する手段がマルチメディアの対象として取り上げられるようになってきた。一般に、マルチメディアとは、文字だけでなく、図形、音声、特に画像等を同時に関連づけて表すことをいうが、上記従来の情報メディアをマルチメディアの対象とするには、その情報をディジタル形式にして表すことが必須条件となる。
【０００３】
ところが、上記各情報メディアの持つ情報量をディジタル情報量として見積もってみると、文字の場合１文字当たりの情報量は１〜２バイトであるのに対し、音声の場合１秒当たり６４Ｋｂｉｔｓ（電話品質）、さらに動画については１秒当たり１００Ｍｂｉｔｓ（現行テレビ受信品質）以上の情報量が必要となり、上記情報メディアでその膨大な情報をディジタル形式でそのまま扱うことは現実的では無い。例えば、テレビ電話は、６４Ｋｂｉｔ／ｓ〜１．５Ｍｂｉｔｓ／ｓの伝送速度を持つサービス総合ディジタル網（ＩＳＤＮ ： Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）によってすでに実用化されているが、テレビ・カメラの映像をそのままＩＳＤＮで送ることは不可能である。
【０００４】
そこで、必要となってくるのが情報の圧縮技術であり、例えば、テレビ電話の場合、ＩＴＵ−Ｔ（国際電気通信連合 電気通信標準化部門）で勧告されたＨ．２６１やＨ．２６３規格の動画圧縮技術が用いられている。また、ＭＰＥＧ−１規格の情報圧縮技術によると、通常の音楽用ＣＤ（コンパクト・ディスク）に音声情報とともに画像情報を入れることも可能となる。
【０００５】
ここで、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）とは、ＩＳＯ／ＩＥＣ（国際標準化機構 国際電気標準会議）で標準化された動画像信号圧縮の国際規格であり、ＭＰＥＧ−１は、動画像信号を１．５Ｍｂｐｓまで、つまりテレビ信号の情報を約１００分の１にまで圧縮する規格である。また、ＭＰＥＧ−１規格では対象とする品質を伝送速度が主として約１．５Ｍｂｐｓで実現できる程度の中程度の品質としたことから、さらなる高画質化の要求をみたすべく規格化されたＭＰＥＧ−２では、動画像信号を２〜１５ＭｂｐｓでＴＶ放送品質を実現する。さらに現状では、ＭＰＥＧ−１，ＭＰＥＧ−２と標準化を進めてきた作業グループ（ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１）によって、ＭＰＥＧ−１，ＭＰＥＧ−２を上回る圧縮率を達成し、更に物体単位で符号化・復号・操作を可能とし、マルチメディア時代に必要な新しい機能を実現するＭＰＥＧ−４が規格化された。ＭＰＥＧ−４では、当初、低ビットレートの符号化方法の標準化を目指して進められたが、現在はインタレース画像も含む高ビットレートも含む、より汎用的な符号化に拡張されている。その後、ＩＳＯ／ＩＥＣとＩＴＵ−Ｔが共同でより高圧縮率の次世代画像符号化方式として、ＭＰＥＧ−４ ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）がされ、さらに、現在ＳＭＰＴＥ（Ｓｏｃｉｅｔｙ ｏｆ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ ａｎｄ Ｔｅｌｅｖｉｓｉｏｎ Ｅｎｇｉｎｅｅｒｓ）においてＶＣ−１（非特許文献１）が規格化中である。ＶＣ−１では、ＭＰＥＧ−２、およびＭＰＥＧ−４の方式をベースとして、符号化ツール等の拡張を行っている。このうちＶＣ−１は、ＢＤ（Ｂｌｕ−ｒａｙ ｄｉｓｃ）、ＨＤ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）−ＤＶＤなど次世代の光ディスク関連機器などで使用される見込みである。
【０００６】
一般に動画像の符号化では、時間方向および空間方向の冗長性を削減することによって情報量の圧縮を行う。そこで時間的な冗長性の削減を目的とする画面間予測符号化では、前方または後方のピクチャを参照してブロック単位で動きの検出および予測画像の作成を行い、得られた予測画像と符号化対象ピクチャとの差分値に対して符号化を行う。ここで、ピクチャとは１枚の画面を表す用語であり、プログレッシブ画像ではフレームを意味し、インタレース画像ではフレームもしくはフィールドを意味する。ここで、インタレース画像とは、１つのフレームが時刻の異なる２つのフィールドから構成される画像である。インタレース画像の符号化や復号処理においては、１つのフレームをフレームのまま処理したり、２つのフィールドとして処理したり、フレーム内のブロック毎にフレーム構造またはフィールド構造として処理したりすることができる。
【０００７】
参照画像を持たず画面内予測符号化を行うものをＩピクチャと呼ぶ。また、１枚のピクチャのみを参照し画面間予測符号化を行うものをＰピクチャと呼ぶ。また、同時に２枚のピクチャを参照して画面間予測符号化を行うことのできるものをＢピクチャと呼ぶ。Ｂピクチャは表示時間が前方もしくは後方から任意の組み合わせとして２枚のピクチャを参照することが可能である。ただし、これらのピクチャを符号化および復号する場合の条件として、参照するピクチャが既に符号化および復号されている必要がある。
【０００８】
次に、ＶＣ−１のストリーム構造について説明する。ＶＣ−１も基本的にはＭＰＥＧ−２と同一のストリーム構造をもつ。ただし、ランダムアクセスポイントは、エントリ・ポイント（Ｅｎｔｒｙ Ｐｏｉｎｔ）と呼ばれ、エントリ・ポイントにはヘッダ（Ｅｎｔｒｙ Ｐｏｉｎｔ Ｈｅａｄｅｒ）が付加される。エントリ・ポイントから次のエントリ・ポイントまでのデータがランダムアクセス単位となり、ＭＰＥＧ−２におけるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）に相当する。以降、ＶＣ−１におけるランダムアクセス単位をＲＡＵ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ）と呼ぶ。ここで、ＲＡＵには、ＲＡＵを構成するピクチャについてのユーザーデータ（エントリ・ポイントレベルのユーザーデータ）を格納することができ、エントリ・ポイント・ヘッダの直後に格納される。
【０００９】
ＶＣ−１におけるピクチャのタイプについて以下に示す。まず、Ｉ、Ｐ、ＢピクチャについてはＭＰＥＧ−２と同等の予測構造をもつが、これら３種類のピクチャに加えて、Ｓｋｉｐｐｅｄピクチャ、およびＢＩピクチャの２種類が定義される。Ｓｋｉｐｐｅｄピクチャとは、画素データを含まないピクチャであり、復号順で直前の参照ピクチャと同一の画素データを持つＰピクチャとして扱う。例えば、下記の例では、Ｓ６がＰ４と同一であるとみなされるため、ストリームの復号時の動作は（１）と（２）で同一となる。
【００１０】
（１）表示順： Ｉ０ Ｂ１ Ｐ２ Ｂ３ Ｐ４ Ｂ５ Ｓ６ （ＳはＳｋｉｐｐｅｄピクチャを示す）
（２）表示順： Ｉ０ Ｂ１ Ｐ２ Ｂ３ Ｐ４ Ｂ５ Ｐ４
Ｓｋｉｐｐｅｄピクチャは、画像が静止しているケースにおいて特に有効である。例えば、ＲＡＵの途中から画像が静止する際には、Ｉ０ Ｐ１ Ｐ２ Ｐ３ Ｓ４ Ｓ５ Ｓ６．．のように、画像が静止している部分についてはＳｋｉｐｐｅｄピクチャを使用することで、符号量が削減できる。また、ＢＩピクチャとは、ＢピクチャとＩピクチャの性質を併せ持つピクチャである。具体的には、復号と表示の順序は異なり、他のピクチャからは参照されないという点でＢピクチャの性質をもち、全てのマクロブロックが画面内符号化されており、他のピクチャを参照しないという点でＩピクチャの性質をもつ。
【００１１】
次に、Ｉ、Ｐ、Ｂ、Ｓｋｉｐｐｅｄ、およびＢＩピクチャの判別方法を説明する。基本的にはピクチャレイヤのピクチャタイプを参照することによりピクチャのタイプが判別できるが、ピクチャレイヤにより示すことのできるピクチャタイプはプロファイルに応じて下記のように規定される。
【００１２】
シンプル・プロファイル： Ｉ、Ｐ
メイン・プロファイル： Ｉ、Ｐ、Ｂ、ＢＩ
アドバンスト・プロファイル： Ｉ、Ｐ、Ｂ、ＢＩ、Ｓｋｉｐｐｅｄ
【００１３】
ここで、シンプル、メインの両プロファイルではピクチャレイヤのピクチャタイプにからはＳｋｉｐｐｅｄピクチャを判別できないため、任意のピクチャタイプをもつピクチャのサイズが１バイト以下である際に、当該ピクチャがＳｋｉｐｐｅｄピクチャであると規定されている。また、メイン・プロファイルでは、ＢまたはＢＩピクチャを示すピクチャタイプが定義されており、ピクチャタイプからＢピクチャとＢＩピクチャとを区別することはできない。
【００１４】
ＶＣ−１のＲＡＵにおいても、ＭＰＥＧ−２と同様にオープンＧＯＰ型とクローズドＧＯＰ型とがある。クローズドＧＯＰ型とは、ＲＡＵ内のＢピクチャが復号順で直前のＲＡＵ内のＩピクチャあるいはＰピクチャを参照しないタイプである。一方、オープンＧＯＰ型は、ＲＡＵ内のＢピクチャが復号順で直前のＲＡＵ内のＩピクチャあるいはＰピクチャを参照してもよいタイプである。なお、オープン型、クローズド型ともに、ＲＡＵ内のＩピクチャとＰピクチャは、復号順で直前のＲＡＵ内のＩピクチャとＰピクチャを参照できない。
【００１５】
次に、フィールド符号化時に１フレームを構成するフィールドのタイプについて説明する。ＶＣ−１では、アドバンスト・プロファイルだけがフィールド符号化に対応しており、フィールド符号化時の第１フィールドと第２フィールドのピクチャタイプは、ピクチャレイヤにおけるフィールド・ピクチャタイプにより示される。フィールド・ピクチャタイプは、（第１フィールドのピクチャタイプ、第２フィールドのピクチャタイプ）として、（Ｉ、Ｉ）、（Ｉ、Ｐ）、（Ｐ、Ｉ）、（Ｐ、Ｐ）、（Ｂ、Ｂ）、（Ｂ、ＢＩ）、（ＢＩ、Ｂ）、（ＢＩ、ＢＩ）の８通りが定義されている。以降、これらのピクチャを、それぞれＩ／Ｉピクチャ、Ｉ／Ｉピクチャ、Ｉ／Ｐピクチャ、Ｐ／Ｉピクチャ、Ｐ／Ｐピクチャ、Ｂ／Ｂピクチャ、Ｂ／ＢＩピクチャ、ＢＩ／Ｉピクチャ、ＢＩ／ＢＩピクチャと呼ぶ。ここで、１フレームを構成する２つのフィールドは、フィールド・ペアと呼ばる。Ｉ／Ｐピクチャなど上記８通りのピクチャは、ピクチャと表記するが、全てフィールド・ペアである。なお、ＭＰＥＧ−２においては、Ｐ／Ｉピクチャ、Ｂ／ＢＩピクチャ、ＢＩ／Ｉピクチャ、およびＢＩ／ＢＩピクチャは存在しない。
【００１６】
図３５は、従来の画像符号化方法を実現する画像符号化装置１のブロック図である。
画像符号化装置１は、入力される画像信号Ｖｉｎ を圧縮符号化して可変長符号化等のビットストリームに変換した画像符号化信号Ｓｔｒ を出力する装置であり、動き検出ユニットＭＥ、動き補償ユニットＭＣ、減算ユニットＳｕｂ、直交変換ユニットＴ、量子化ユニットＱ、逆量子化ユニットＩＱ、逆直交変換ユニットＩＴ、加算ユニットＡｄｄ、ピクチャメモリＰｉｃＭｅｍ、スイッチＳＷ、および可変長符号化ユニットＶＬＣを備えている。
【００１７】
画像信号Ｖｉｎ は、減算ユニットＳｕｂおよび動き検出ユニットＭＥに入力される。減算ユニットＳｕｂは、入力された画像信号Ｖｉｎ と予測画像の差分値を計算し、直交変換ユニットＴに出力する。直交変換ユニットＴは、差分値を周波数係数に変換し、量子化ユニットＱに出力する。量子化ユニットＱは、入力された周波数係数を量子化し、量子化値Ｑｃｏｅｆを可変長符号化ユニットに出力する。
【００１８】
逆量子化ユニットＩＱは、量子化値Ｑｃｏｅｆを逆量子化して周波数係数に復元し、逆直交変換ユニットＩＴに出力する。逆直交変換ユニットＩＴは、周波数係数から画素差分値に逆周波数変換し、加算ユニットＡｄｄに出力する。加算ユニットＡｄｄは、画素差分値と動き補償ユニットＭＣから出力される予測画像とを加算して復号画像とする。スイッチＳＷは、当該復号画像の保存が指示された場合にＯＮになり、復号画像はピクチャメモリＰｉｃＭｅｍに保存される。
【００１９】
一方、画像信号Ｖｉｎ がマクロブロック単位で入力された動き検出ユニットＭＥは、ピクチャメモリＰｉｃＭｅｍに格納されている復号画像を探索対象とし、最も入力画像信号に近い画像領域を検出することによってその位置を指し示す動きベクトルＭＶを決定する。
【００２０】
動き補償ユニットＭＣでは、上記処理によって検出された動きベクトルなどを用いて、ピクチャメモリＰｉｃＭｅｍに格納されている復号画像から予測画像に最適な画像領域を取り出す。
【００２１】
ピクチャ予測構造決定ユニットＰＴＹＰＥはＲＡＵ開始ピクチャＲＡＵｉｎによって対象ピクチャがＲＡＵの開始位置であれば、対象ピクチャをランダムアクセスが可能な特別なピクチャとして符号化（画面内符号化）するように、ピクチャタイプＰｔｙｐｅで動き検出ユニットＭＥおよび動き補償ユニットＭＣに指示し、更にそのピクチャタイプＰｔｙｐｅを可変長符号化ユニットＶＬＣで符号化する。ここで、先頭ピクチャをフィールドとして符号化する際のピクチャタイプとしては、Ｉ／Ｉ、Ｉ／Ｐ、およびＰ／Ｉピクチャを自由に選択できる。
【００２２】
可変長符号化ユニットＶＬＣは量子化値Ｑｃｏｅｆ、ピクチャタイプＰｔｙｐｅおよび動きベクトルＭＶなどを可変長符号化して符号化ストリームＳｔｒとする。
【００２３】
図３６は、従来の画像復号方法を実現する画像復号装置３のブロック図である。同図において、図３５の画像符号化装置１のブロック図と同じ動作をするユニットは同じ記号を付し、説明を省略する。可変長復号ユニットＶＬＤは符号化ストリームＳｔｒを復号し、量子化値Ｑｃｏｅｆ、相対インデックスＩｎｄｅｘ、ピクチャタイプＰｔｙｐｅおよび動きベクトルＭＶを出力する。量子化値Ｑｃｏｅｆ、相対インデックスＩｎｄｅｘおよび動きベクトルＭＶは、ピクチャメモリＰｉｃＭｅｍ、動き補償ユニットＭＣおよび逆量子化ユニットＩＱに入力され復号処理が行われるが、その動作は図１４の従来の画像符号化方法を実現する画像符号化装置のブロック図で説明済みである。バッファメモリＢｕｆＭｅｍは、復号画像Ｖｏｕｔを格納するメモリである。表示方法切替ユニットＭｏｄｅＳｅｔは、次に表示するピクチャがＲＡＵの先頭ピクチャである際には、ピクチャタイプを取得するために必要なデータＰｉｎｆをバッファメモリＢｕｆＭｅｍに格納された復号画像データから取得する。さらに、当該ピクチャがＰ／Ｉピクチャである際には、第１フィールドと第２フィールドにおいて同一の画像を表示する旨を表示命令ｍｏｄｅによって表示ユニットＤｉｓｐに通知する。Ｐ／Ｉピクチャでなければ、第１フィールドと第２フィールドは、１フレームを構成するフィールド・ペアにおける第１フィールドと第２フィールドを、それぞれ表示するように表示ユニットＤｉｓｐに指示する。表示ユニットＤｉｓｐは、バッファメモリＢｕｆＭｅｍから復号画像Ｄｉｎを取得し、表示命令ｍｏｄｅに従って表示する。なお、ピクチャメモリＰｉｃＭｅｍとバッファメモリＢｕｆＭｅｍは共用してもよい。
【００２４】
図３７は、従来の画像復号装置３において、マルチアングル再生や、同一ストリーム内の異なる区間を連続して再生するなどの特殊再生時の表示動作を示すフローチャートである。まず、ステップＳ１００１において表示対象のピクチャがＲＡＵの先頭ピクチャであるかどうか判定する。先頭ピクチャであれば、ステップＳ１００２に進み、先頭ピクチャでなければステップＳ１００５に進む。ステップＳ１００２では、ピクチャのピクチャタイプを取得して、ステップＳ１００３においてＰ／Ｉピクチャであったかどうか判定する。Ｐ／Ｉピクチャである際にはステップＳ１００４に進み、Ｐ／ＩピクチャでなければステップＳ１００５に進む。ステップＳ１００４では、第２フィールドを２回繰り返して表示すると決定する。つまり、Ｐ／Ｉピクチャにおいては、第１フィールドであるＰピクチャは復号できないため、第２フィールドであるＩピクチャをＰピクチャの代わりに表示することになる。ステップＳ１００５では、フィールド・ペアを構成する第１フィールドと第２フィールドを、それぞれ順番に表示すると決定する。
【特許文献１】特開２０００−２２８６５６号公報
【非特許文献１】Ｐｒｏｐｏｓｅｄ ＳＭＰＴＥ Ｓｔａｎｄａｒｄ ｆｏｒ Ｔｅｌｅｖｉｓｉｏｎ： ＶＣ−９ Ｃｏｍｐｒｅｓｓｅｄ Ｖｉｄｅｏ Ｂｉｔｓｔｒｅａｍ Ｆｏｒｍａｔ ａｎｄ Ｄｅｃｏｄｉｎｇ Ｐｒｏｃｅｓｓ， Ｃｏｍｍｉｔｔｅｅ Ｄｒａｆｔ １， ２００４．７．１９
【発明の開示】
【発明が解決しようとする課題】
【００２５】
ＲＡＵの先頭ピクチャがＰ／Ｉピクチャであると、飛び込み再生やマルチアングル再生などの特殊再生時に、Ｐ／Ｉピクチャの第１フィールドであるＰピクチャが再生できないという課題があった。また、ＲＡＵの先頭がＰ／Ｉピクチャである際には、第２フィールドを繰り返して表示するなどして、Ｐ／Ｉピクチャ以外のピクチャとは表示動作を切替える必要があり、表示に係る処理が増加するという課題もあった。以下に、特殊再生時の課題について説明する。
【００２６】
図２７が示すように、Ｐ／ＩピクチャをＲＡＵの先頭ピクチャとして用いることも可能である。ＲＡＵの先頭は特殊再生等における再生開始点として指定することができる位置であるが、Ｐ／Ｉピクチャを先頭ピクチャとして有しているＲＡＵから再生を開始する場合、第１フィールドであるＰピクチャは前方の他のピクチャを参照しているために復号することができない。そのため、第２フィールドであるＩピクチャからデコードを開始することになり、このＰ／Ｉピクチャであるフレームの画像を表示するときには、第２フィールドの画像のみからフレームを表示することになる。例えば、第２フィールドの画像を２回出力することにより、１フレームの画像を表示する。
【００２７】
さらに、図２８が示すように、ＲＡＵ先頭のピクチャのみ読み込む早送り再生のような特殊再生をする場合、同様にＰピクチャはデコードできないので、１フレームのうちの１フィールドしかデコードできず、解像度が半分に落ちてしまう欠点がある。
【００２８】
また、ＤＶＤやＢＤなどでは、プレイリストを用いて同一ストリームにおいて異なる時間位置のストリームを連続再生する、あるいは、マルチアングル再生時に異なるアングルを構成するストリームを連続して再生するなどの特殊再生が一般的に行われる。さらに、追記型、あるいは書き換え型のディスクにおいては、編集後のストリームをプレイリストによって仮想的に連結することもある。このとき、プレイリストでは、プレイアイテムと呼ばれる再生区間を連続して再生する。図２９は、プレイリストから指される第１プレイアイテムと第２プレイアイテムとを連続的に再生する例を示す。ここで、第２プレイアイテムの先頭ピクチャがＰ／Ｉピクチャであると、Ｐ／Ｉピクチャを構成するＰピクチャは復号できず、第１プレイアイテムから第２プレイアイテムへのシームレスな接続が実現できない。
【課題を解決するための手段】
【００２９】
本発明は、以上の課題を解決するためになされたものである。
本発明の請求項１にかかる情報記録媒体は、少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、前記動画像の符号化データは、１以上のランダムアクセス可能な単位から構成され、前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、前記符号化データにおいて前記フィールド・ペアが存在するかどうかを示す識別情報を格納することを特徴とする。
【００３０】
本発明の請求項２にかかる情報記録媒体は、前記ランダムアクセス単位には、ランダムアクセス単位内の双方向予測ピクチャが、復号順で直前のランダムアクセス単位内のピクチャを参照することを禁止した、クローズド型のランダムアクセス単位と、ランダムアクセス単位内の双方向予測ピクチャが、復号順で直前のランダムアクセス単位内のピクチャを参照することを許容した、オープン型のランダムアクセス単位と、の２種類があり、前記識別情報は、前記ランダムアクセス単位がクローズド型であるかどうかを示す情報であり、前記ランダムアクセス単位がクローズド型である際には、前記ランダムアクセス単位の先頭に前記フィールド・ペアが存在しないことを特徴とする請求項１記載の情報記録媒体である。
【００３１】
本発明の請求項３にかかる情報記録媒体は、前記識別情報は、前記符号化ストリームのビットレートが所定の値以下であるかどうかを示す情報であることを特徴とする請求項１記載の情報記録媒体である。
【００３２】
本発明の請求項４にかかる情報記録媒体は、前記動画像は再生時刻に応じて複数の再生区間に分割され、前記管理情報は、１以上の前記動画像における１以上の前記再生区間を連続して再生するための情報を格納し、前記識別情報は、前記管理情報に格納され、前記連続して再生される前記再生区間がシームレスに接続されるかどうかを示し、前記シームレスに接続されることが示される際には、接続先となる前記再生区間の先頭は前記フィールド・ペアでないことを特徴とする請求項１の情報記録媒体である。
【００３３】
本発明の請求項５にかかる情報記録媒体は、前記動画像は再生時刻に応じて複数の再生区間に分割され、前記管理情報は、１以上の前記動画像における１以上の前記再生区間を連続して再生するための情報を格納し、前記識別情報は、前記管理情報に格納され、前記連続して再生される区間が、それぞれ異なる動画像のストリームに属するかどうかを識別する情報であり、前記異なる動画ストリームに属することが示される際には、接続先となる前記再生区間の先頭は前記フィールド・ペアでないことを特徴とする。
【００３４】
本発明の請求項６にかかる画像符号化方法は、動画像を１以上のランダムアクセス単位に符号化する画像符号化方法であって、前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアであるかどうかを示す情報を作成する補助情報作成ステップと、前記作成した補助情報と画素を符号化して符号化ストリームを作成する符号化ステップと、を備えることを特徴とする。
【００３５】
本発明の請求項７にかかる画像符号化装置は、動画像を１以上のランダムアクセス単位に符号化する画像符号化装置であって、前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアであるかどうかを示す情報を作成する補助情報作成手段と、前記作成した補助情報と画素を符号化して符号化ストリームを作成する符号化手段と、を備えることを特徴とする。
【００３６】
本発明の請求項８にかかる画像復号方法は、請求項１の情報記録媒体に記録された符号化データを復号して再生する画像復号方法であって、前記識別情報により、前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアでないことが示される場合に、前記先頭ピクチャにおける第１フィールド、および第２フィールドを、それぞれ１番目と２番目に表示する表示ステップ、を備えることを特徴とする。
【００３７】
本発明の請求項９にかかる画像復号装置は、請求項１の情報記録媒体に記録された符号化データを復号して再生する画像復号装置であって、前記識別情報により、前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアでないことが示される場合に、前記先頭ピクチャにおける第１フィールド、および第２フィールドを、それぞれ１番目と２番目に表示する表示手段、を備えることを特徴とする。
【００３８】
本発明の請求項１０にかかる情報記録媒体は、少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、前記動画像の符号化データは、１以上のランダムアクセス可能な単位から構成され、前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、前記ランダムアクセス単位の先頭とは異なるピクチャが前記フィールド・ペアであるときには、前記ランダムアクセス単位内のピクチャであって、前記フィールド・ペアよりも表示順が後であるピクチャは、前記フィールド・ペアの第１フィールドを参照しないことが保証され、前記保証されることを示す情報を前記ストリーム内に格納することを特徴とする。
【００３９】
本発明の請求項１１にかかる情報記録媒体は、少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、前記動画像の符号化データは、１以上のランダムアクセス可能な単位から構成され、前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、前記ランダムアクセス単位の先頭とは異なるピクチャが前記フィールド・ペアであるときには、前記ランダムアクセス単位内のピクチャであって、前記フィールド・ペアよりも表示順が後であるピクチャは、前記フィールド・ペアの第１フィールドを参照する場合としない場合とがあり、前記フィールド・ペアよりも表示順が後であるピクチャが、前記フィールド・ペアの第１フィールドを参照するかどうかを示す情報を前記ストリーム内に格納することを特徴とする。
【００４０】
本発明の請求項１２にかかる情報記録媒体は、少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、前記動画像の符号化データは、１以上のピクチャをまとめたグループ化単位が複数連結されたデータであり、前記管理情報は、ランダムアクセスすることができる前記グループ化単位の一覧情報を格納し、前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、前記ストリームは、前記一覧情報から指されない前記グループ化単位の先頭ピクチャが前記フィールド・ペアであるかどうかを示す情報を格納することを特徴とする。
【発明の効果】
【００４１】
以上のように、本発明によれば、Ｐ／Ｉピクチャを使用する際に、ストリームおよび管理情報を制約することにより、特殊再生時の再生品質を向上させることができ、特殊再生機能が重視されるパッケージメディアにおいて、特にその実用的価値が高い。
【発明を実施するための最良の形態】
【００４２】
以下、本発明の実施の形態について、図面を参照しながら説明する。
【００４３】
（実施の形態１）
まず最初に本発明の第１の実施の形態について説明する。
【００４４】
（ディスク上の論理データ構造）
図１は、ＢＤ−ＲＯＭの構成、特にディスク媒体であるＢＤディスク（１０４）と、ディスクに記録されているデータ（１０１、１０２、１０３）の構成を示す図である。ＢＤディスク（１０４）に記録されるデータは、ＡＶデータ（１０３）と、ＡＶデータに関する管理情報およびＡＶ再生シーケンスなどのＢＤ管理情報（１０２）と、インタラクティブを実現するＢＤ再生プログラム（１０１）である。本実施の形態では、説明の都合上、映画のＡＶコンテンツを再生するためのＡＶアプリケーションを主眼においてのＢＤディスクの説明を行うが、他の用途として用いても勿論同様である。
【００４５】
図２は、上述したＢＤディスクに記録されている論理データのディレクトリ・ファイル構成を示した図である。ＢＤディスクは、他の光ディスク、例えばＤＶＤやＣＤなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリード・インと外周のリード・アウトの間に論理データを記録できる論理アドレス空間を有している。また、リード・インの内側にはＢＣＡ（Ｂｕｒｓｔ Ｃｕｔｔｉｎｇ Ａｒｅａ）と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがある。
【００４６】
論理アドレス空間には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは従来技術で説明した通り、ＵＤＦやＩＳＯ９６６０などのことであり、通常のＰＣと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。
【００４７】
本実施例の場合、ＢＤディスク上のディレクトリ、ファイル構造は、ルートディレクトリ（ＲＯＯＴ）直下にＢＤＶＩＤＥＯディレクトリが置かれている。このディレクトリはＢＤで扱うＡＶコンテンツや管理情報などのデータ（図１で説明した１０１、１０２、１０３）が格納されているディレクトリである。
【００４８】
ＢＤＶＩＤＥＯディレクトリの下には、次の７種類のファイルが記録されている。
【００４９】
ＢＤ．ＩＮＦＯ（ファイル名固定）
「ＢＤ管理情報」の一つであり、ＢＤディスク全体に関する情報を記録したファイルである。ＢＤプレーヤは最初にこのファイルを読み出す。
【００５０】
ＢＤ．ＰＲＯＧ（ファイル名固定）
「ＢＤ再生プログラム」の一つであり、ＢＤディスク全体に関わる再生制御情報を記録したファイルである。
【００５１】
ＸＸＸ．ＰＬ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ管理情報」の一つであり、シナリオ（再生シーケンス）であるプレイリスト情報を記録したファイルである。プレイリスト毎に１つのファイルを持っている。
【００５２】
ＸＸＸ．ＰＲＯＧ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ再生プログラム」の一つであり、前述したプレイリスト毎の再生制御情報を記録したファイルである。プレイリストとの対応はファイルボディ名（「ＸＸＸ」が一致する）によって識別される。
【００５３】
ＹＹＹ．ＶＯＢ（「ＹＹＹ」は可変、拡張子「ＶＯＢ」は固定）
「ＡＶデータ」の一つであり、ＶＯＢ（従来例で説明したＶＯＢと同じ）を記録したファイルである。ＶＯＢ毎に１つのファイルを持っている。
【００５４】
ＹＹＹ．ＶＯＢＩ（「ＹＹＹ」は可変、拡張子「ＶＯＢＩ」は固定）
「ＢＤ管理情報」の一つであり、ＡＶデータであるＶＯＢに関わるストリーム管理情報を記録したファイルである。ＶＯＢとの対応はファイルボディ名（「ＹＹＹ」が一致する）によって識別される。
【００５５】
ＺＺＺ．ＰＮＧ（「ＺＺＺ」は可変、拡張子「ＰＮＧ」は固定）
「ＡＶデータ」の一つであり、字幕およびメニューを構成するためのイメージデータＰＮＧ（Ｗ３Ｃによって標準化された画像フォーマットであり「ピング」と読む）を記録したファイルである。１つのＰＮＧイメージ毎に１つのファイルを持つ。
【００５６】
（プレーヤの構成）
次に、前述したＢＤディスクを再生するプレーヤの構成について図６および図７を用いて説明する。
【００５７】
図３は、プレーヤの大まかな機能構成を示すブロック図である。
ＢＤディスク（２０１）上のデータは、光ピックアップ（２０２）を通して読み出される。読み出されたデータは夫々のデータの種類に応じて専用のメモリに転送される。ＢＤ再生プログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」ファイルの中身）はプログラム記録メモリ（２０３）に、ＢＤ管理情報（「ＢＤ．ＩＮＦＯ」、「ＸＸＸ．ＰＬ」または「ＹＹＹ．ＶＯＢＩ」）は管理情報記録メモリ（２０４）に、ＡＶデータ（「ＹＹＹ．ＶＯＢ」または「ＺＺＺ．ＰＮＧ」）はＡＶ記録メモリ（２０５）に夫々転送される。
【００５８】
プログラム記録メモリ（２０３）に記録されたＢＤ再生プログラムはプログラム処理部（２０６）によって、管理情報記録メモリ（２０４）に記録されたＢＤ管理情報は管理情報処理部（２０７）によって、また、ＡＶ記録メモリ（２０５）に記録されたＡＶデータはプレゼンテーション処理部（２０８）によって夫々処理される。
【００５９】
プログラム処理部（２０６）は、管理情報処理部（２０７）より再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムでは再生するプレイリストを動的に変える事が可能であり、この場合は管理情報処理部（２０７）に対してプレイリストの再生命令を送ることで実現する。プログラム処理部（２０６）は、ユーザからのイベント、即ちリモコンキーからのリクエストを受け、ユーザイベントに対応するプログラムがある場合は、それを実行する。
【００６０】
管理情報処理部（２０７）は、プログラム処理部（２０６）の指示を受け、対応するプレイリストおよびプレイリストに対応したＶＯＢの管理情報を解析し、プレゼンテーション処理部（２０８）に対象となるＡＶデータの再生を指示する。また、管理情報処理部（２０７）は、プレゼンテーション処理部（２０８）より基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部（２０８）にＡＶデータ再生の停止指示を行い、また、プログラム処理部（２０６）に対してプログラム実行タイミングを示すイベントを生成する。
【００６１】
プレゼンテーション処理部（２０８）は、映像、音声、字幕／イメージ（静止画）の夫々に対応するデコーダを持ち、管理情報処理部（２０７）からの指示に従い、ＡＶデータのデコードおよび出力を行う。映像データ、字幕／イメージの場合は、デコード後に夫々の専用プレーン、ビデオプレーン（２１０）およびイメージプレーン（２０９）に描画され、合成処理部（２１１）によって映像の合成処理が行われＴＶなどの表示デバイスへ出力される。
【００６２】
このように図３に示すように、ＢＤプレーヤは図１で示したＢＤディスクに記録されているデータ構成に基づいた機器構成をとっている。
【００６３】
図４は前述したプレーヤ構成を詳細化したブロック図である。図７では、ＡＶ記録メモリ（２０５）はイメージメモリ（３０８）とトラックバッファ（３０９）に、プログラム処理部（２０６）はプログラムプロセッサ（３０２）とＵＯＰマネージャ（３０３）に、管理情報処理部（２０７）はシナリオプロセッサ（３０５）とプレゼンテーションコントローラ（３０６）に、プレゼンテーション処理部（２０８）はクロック（３０７）、デマルチプレクサ（３１０）、イメージプロセッサ（３１１）、ビデオプロセッサ（３１２）とサウンドプロセッサ（３１３）に夫々対応／展開している。
【００６４】
ＢＤディスク（２０１）から読み出されたＶＯＢデータ（ＭＰＥＧストリーム）はトラックバッファ（３０９）に、イメージデータ（ＰＮＧ）はイメージメモリ（３０８）に夫々記録される。デマルチプレクサ（３１０）がクロック（３０７）の時刻に基づき、トラックバッファ（３０９）に記録されたＶＯＢデータを抜き出し、映像データをビデオプロセッサ（３１２）に音声データをサウンドプロセッサ（３１３）に夫々送り込む。ビデオプロセッサ（３１２）およびサウンドプロセッサ（３１３）は夫々ＭＰＥＧシステム規格で定める通りに、デコーダバッファとデコーダから夫々構成されている。即ち、デマルチプレクサ（３１０）から送りこまれる映像、音声夫々のデータは、夫々のデコーダバッファに一時的に記録され、クロック（３０７）に従い個々のデコーダでデコード処理される。
【００６５】
イメージメモリ（３０８）に記録されたＰＮＧは、次の２つの処理方法がある。
イメージデータが字幕用の場合は、プレゼンテーションコントローラ（３０６）によってデコードタイミングが指示される。クロック（３０７）からの時刻情報をシナリオプロセッサ（３０５）が一旦受け、適切な字幕表示が行えるように、字幕表示時刻（開始および終了）になればプレゼンテーションコントローラ（３０６）に対して字幕の表示、非表示の指示を出す。プレゼンテーションコントローラ（３０６）からデコード／表示の指示を受けたイメージプロセッサ（３１１）は対応するＰＮＧデータをイメージメモリ（３０８）から抜き出し、デコードし、イメージプレーン（３１４）に描画する。
【００６６】
次に、イメージデータがメニュー用の場合は、プログラムプロセッサ（３０２）によってデコードタイミングが指示される。プログラムプロセッサ（３０２）が何時イメージのデコードを指示するかは、プログラムプロセッサ（３０２）が処理しているＢＤプログラムに因るものであって一概には決まらない。
【００６７】
イメージデータおよび映像データは、図６で説明したように夫々デコード後にイメージプレーン（３１４）、ビデオプレーン（３１５）に出力され、合成処理部（３１６）によって合成後出力される。
【００６８】
ＢＤディスク（２０１）から読み出された管理情報（シナリオ、ＡＶ管理情報）は、管理情報記録メモリ（３０４）に格納されるが、シナリオ情報（「ＢＤ．ＩＮＦＯ」および「ＸＸＸ．ＰＬ」）はシナリオプロセッサ（３０５）へ読み込み処理される。また、ＡＶ管理情報（「ＹＹＹ．ＶＯＢＩ」）はプレゼンテーションコントローラ（３０６）によって読み出され処理される。
【００６９】
シナリオプロセッサ（３０５）は、プレイリストの情報を解析し、プレイリストによって参照されているＶＯＢとその再生位置をプレゼンテーションコントローラ（３０６）に指示し、プレゼンテーションコントローラ（３０６）は対象となるＶＯＢの管理情報（「ＹＹＹ．ＶＯＢＩ」）を解析して、対象となるＶＯＢを読み出すようにドライブコントローラ（３１７）に指示を出す。
【００７０】
ドライブコントローラ（３１７）はプレゼンテーションコントローラ（３０６）の指示に従い、光ピックアップを移動させ、対象となるＡＶデータの読み出しを行う。読み出されたＡＶデータは、前述したようにイメージメモリ（３０８）またはトラックバッファ（３０９）に読み出される。
【００７１】
また、シナリオプロセッサ（３０５）は、クロック（３０７）の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ（３０２）に投げる。
【００７２】
プログラム記録メモリ（３０１）に記録されたＢＤプログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」）は、プログラムプロセッサ３０２によって実行処理される。プログラムプロセッサ（３０２）がＢＤプログラムを処理するのは、シナリオプロセッサ（３０５）からイベントが送られてきた場合か、ＵＯＰマネージャ（３０３）からイベントが送られてきた場合である。ＵＯＰマネージャ（３０３）は、ユーザからリモコンキーによってリクエストが送られてきた場合に、プログラムプロセッサ（３０２）に対するイベントを生成する。
【００７３】
（アプリケーション空間）
図５は、ＢＤのアプリケーション空間を示す図である。
【００７４】
ＢＤのアプリケーション空間では、プレイリスト（ＰｌａｙＬｉｓｔ）が一つの再生単位になっている。プレイリストはセル（Ｃｅｌｌ）の連結で、連結の順序により決定される再生シーケンスである静的なシナリオと、プログラムによって記述される動的なシナリオを有している。プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。一方で、プログラムは、プレイリストを超えての再生記述や、ユーザ選択またはプレーヤの状態によって再生する対象を動的に変えることが可能である。典型的な例としてはメニューがあげられる。ＢＤの場合、メニューとはユーザの選択によって再生するシナリオと定義でき、プログラムによってプレイリストを動的に選択することである。
【００７５】
ここで言うプログラムとは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。
【００７６】
時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図４で説明したシナリオプロセッサ（３０５）からプログラムプロセッサ（３０２）に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ（３０２）はＩＤによって対応付けられるイベントハンドラを実行処理する。前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。
【００７７】
ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく２つのタイプに分けられる。一つ目は、カーソルキー（「上」「下」「左」「右」キー）または「決定」キーの操作によって生成されるメニュー選択のイベントである。メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効であり（プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている）、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。
【００７８】
二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー呼び出しのイベントである。メニュー呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、ＤＶＤのメニューコール（タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点からのタイトル再生を実行する機能等）を実装することができる。
【００７９】
プレイリストで静的シナリオを構成する単位であるセル（Ｃｅｌｌ）はＶＯＢ（ＭＰＥＧストリーム）の全部または一部の再生区間を参照したものである。セルはＶＯＢ内の再生区間を開始、終了時刻の情報として持っている。個々のＶＯＢと一対になっているＶＯＢ管理情報（ＶＯＢＩ）は、その内部にデータの再生時刻に対応した記録アドレスのテーブル情報であるタイムマップ（Ｔｉｍｅ ＭａｐまたはＴＭＡＰ）を有しており、このタイムマップによって前述したＶＯＢの再生、終了時刻をＶＯＢ内（即ち対象となるファイル「ＹＹＹ．ＶＯＢ」内）での読み出し開始アドレスおよび終了アドレスを導き出すことが可能である。なおタイムマップの詳細は後述する。
【００８０】
（ＶＯＢの詳細）
図６は、本実施例で使用するＭＰＥＧストリーム（ＶＯＢ）の構成図である。
【００８１】
図６に示すように、ＶＯＢは複数のＶＯＢＵ（Ｖｉｄｅｏ Ｏｂｊｅｃｔ Ｕｎｉｔ）によって構成されている。ＶＯＢＵは、ＭＰＥＧビデオストリームで言うＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ）を基準として、音声データも含んだ多重化ストリームとしての一再生単位である。ＶＯＢＵは１．０秒以下のビデオ再生時間を持ち、通常は０．５秒程度の再生時間を持っている。
【００８２】
ＶＯＢＵ先頭のＴＳパケット（ＭＰＥＧ−２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ Ｐａｃｋｅｔ）は、シーケンスヘッダとそれに続くＧＯＰヘッダとＩピクチャ（Ｉｎｔｒａ−ｃｏｄｅｄ）を格納しており、このＩピクチャからの復号が開始可能なようになっている。また、このＶＯＢＵ先頭のＩピクチャの先頭を含むＴＳパケットのアドレス（開始アドレス）と、この開始アドレスからＩピクチャの最後を含むＴＳパケットまでのアドレス（終了アドレス）と、このＩピクチャの再生開始時刻（ＰＴＳ）をタイムマップで管理している。したがって、タイムマップのエントリーはＶＯＢＵ先頭のＴＳパケットごとに与えられている。
【００８３】
ＶＯＢＵは、その内部にビデオパケット（Ｖ＿ＰＫＴ）とオーディオパケット（Ａ＿ＰＫＴ）を有している。各パケットは１８８バイトであり、図６に図示してはいないが、各ＴＳパケットの直前には、そのＴＳパケットの相対的なデコーダ供給開始時刻であるＡＴＳ（Ａｒｒｉｖａｌ Ｔｉｍｅ Ｓｔａｍｐ）が付与されている。
【００８４】
ＡＴＳを各ＴＳパケットごとに付与するのは、このＴＳストリームのシステムレートが固定レートでなく、可変レートであるためである。一般的にシステムレートを固定にする場合にはＮＵＬＬパケットと呼ばれるダミーのＴＳパケットを挿入することになるが、限られた記録容量の中に高画質で記録するためには、可変レートが適しており、ＢＤではＡＴＳ付きのＴＳストリームとして記録している。
【００８５】
図７は、ＴＳパケットの構成を示した図である。
図７に示すように、ＴＳパケットは、ＴＳパケットヘッダと、適用フィールドと、ペイロード部から構成される。ＴＳパケットヘッダにはＰＩＤ（Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）が格納され、これにより、ＴＳパケットがどのような情報を格納しているのか識別される。適用フィールドにはＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）が格納される。ＰＣＲはストリームをデコードする機器の基準クロック（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ、ＳＴＣと呼ぶ）の参照値である。機器は典型的にはＰＣＲのタイミングでシステムストリームをデマルチプレクスし、ビデオストリーム等の各種ストリームを再構築する。ペイロードにはＰＥＳパケットが格納される。
【００８６】
ＰＥＳパケットヘッダには、ＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）とＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）が格納される。ＤＴＳは当該ＰＥＳパケットに格納されるピクチャ／オーディオフレームのデコードタイミングを示し、ＰＴＳは映像音声出力等のプレゼンテーションタイミングを示す。ビデオデータおよびオーディオデータといったエレメンタリデータは、ＰＥＳパケットペイロード（ＰＥＳ Ｐａｃｋｅｔ Ｐａｙｌｏａｄ）と呼ばれるパケット（ＰＥＳ Ｐａｃｋｅｔ）のデータ格納領域に先頭から順次入れられていく。ＰＥＳパケットヘッダには、ペイロードに格納してあるデータがどのストリームなのかを識別するためのＩＤ（ｓｔｒｅａｍ＿ｉｄ）も記録されている。
【００８７】
ＴＳストリームの詳細についてはＩＳＯ／ＩＥＣ１３８１８−１で規定されており、ＢＤで特徴的なのはＡＴＳを各ＴＳパケットごとに付与したことである。
【００８８】
（ＶＯＢのインターリーブ記録）
次に図８および図９を用いてＶＯＢファイルのインターリーブ記録について説明する。
【００８９】
図８上段は、前述したプレーヤ構成図の一部である。図の通り、ＢＤディスク上のデータは、光ピックアップを通してＶＯＢ即ちＭＰＥＧストリームであればトラックバッファへ入力され、ＰＮＧ即ちイメージデータであればイメージメモリへと入力される。
【００９０】
トラックバッファはＦＩＦＯであり、入力されたＶＯＢのデータは入力された順にデマルチプレクサへと送られる。この時、前述したＡＴＳに従って個々のＴＳパケットはトラックバッファから引き抜かれデマルチプレクサを介してビデオプロセッサまたはサウンドプロセッサへとデータが送り届けられる。一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラによって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリから削除されるが、メニュー用のイメージデータの場合は、そのメニュー描画中はイメージメモリ内にそのまま残される。これはメニューの描画はユーザ操作に依存しており、ユーザーの操作に追従してメニューの一部分を再表示もしくは異なるイメージに置き換えることがあり、その際に再表示される部分のイメージデータをデコードし易くするためである。
【００９１】
図８下段は、ＢＤディスク上でのＶＯＢファイルおよびＰＮＧファイルのインターリーブ記録を示す図である。一般的にＲＯＭ、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの場合、一連の連続再生単位となるＡＶデータは連続記録されている。これは、連続記録されている限り、ドライブは順次データを読み出し、デコーダに送り届けるだけで良いが、連続データが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになり、データの供給が止まる可能性があるからである。ＢＤの場合も同様に、ＶＯＢファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにＶＯＢに記録されている映像データと同期して再生されるデータがあり、ＶＯＢファイルと同様に字幕データも何らかの方法によってＢＤディスクから読み出す事が必要になる。
【００９２】
字幕データの読み出し方法の一手段として、ＶＯＢの再生開始前に一まとめで字幕用のイメージデータ（ＰＮＧファイル）を読み出してしまう方法がある。しかしながら、この場合には大量のメモリが必要となり、非現実的である。
【００９３】
そこで、ＶＯＢファイルを幾つかのブロックに分けて、イメージデータとインターリーブ記録する方式を使用している。図８下段はそのインターリーブ記録を説明した図である。
【００９４】
ＶＯＢファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリに格納することが可能になる。しかしながらイメージデータを読み出している際には、ＶＯＢデータの読み込みは当然のことながら停止することになる。
【００９５】
図９は、この問題を解決するトラックバッファを使ったＶＯＢデータ連続供給モデルを説明する図である。
【００９６】
既に説明したように、ＶＯＢのデータは、一旦トラックバッファに蓄積される。トラックバッファへのデータ入力レート（Ｖａ）とトラックバッファからのデータ出力レート（Ｖｂ）の間に差（Ｖａ＞Ｖｂ）を設けると、ＢＤディスクからデータを読み出し続けている限り、トラックバッファのデータ蓄積量は増加をしていくことになる。
【００９７】
図９の上段に記すようにＶＯＢの一連続記録領域が論理アドレスの”ａ１”から”ａ２”まで続くとする。”ａ２”から”ａ３”の間は、イメージデータが記録されていて、ＶＯＢデータの読み出しが行えない区間であるとする。
【００９８】
図９の下段は、トラックバッファの内部を示す図である。横軸が時間、縦軸がトラックバッファ内部に蓄積されているデータ量を示している。時刻”ｔ１”がＶＯＢの一連続記録領域の開始点である”ａ１”の読み出しを開始した時刻を示している。この時刻以降、トラックバッファにはレートＶａ−Ｖｂでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファの入出力レートの差である。時刻”ｔ２”は一連続記録領域の終了点である”ａ２”のデータを読み込む時刻である。即ち時刻”ｔ１”から”ｔ２”の間レートＶａ−Ｖｂでトラックバッファ内はデータ量が増加していき、時刻”ｔ２”でのデータ蓄積量はＢ（ｔ２）は下式によって求めることができる。
Ｂ（ｔ２） ＝ （Ｖａ−Ｖｂ）×（ｔ２−ｔ１） （式１）
この後、ＢＤディスク上のアドレス”ａ３”まではイメージデータが続くため、トラックバッファへの入力は０となり、出力レートである”−Ｖｂ”でトラックバッファ内のデータ量は減少していくことになる。これは読み出し位置”ａ３”まで、時刻でいう”ｔ３”までになる。
【００９９】
ここで大事なことは、時刻”ｔ３”より前にトラックバッファに蓄積されているデータ量が０になると、デコーダへ供給するＶＯＢのデータが無くなってしまい、ＶＯＢの再生がストップしてしまう可能性がある。しかしながら、時刻”ｔ３”でトラックバッファにデータが残っている場合には、ＶＯＢの再生がストップすることなく連続できることを意味している。
【０１００】
この条件は下式によって示すことができる。
Ｂ（ｔ２） ≧ −Ｖｂ×（ｔ３−ｔ２） （式２）
即ち、式２を満たすようにイメージデータ（非ＶＯＢデータ）の配置を決めればよい事になる。
【０１０１】
（ナビゲーションデータ構造）
図１０から図１６を用いて、ＢＤのナビゲーションデータ（ＢＤ管理情報）構造について説明をする。
【０１０２】
図１０は、ＶＯＢ管理情報情報ファイル（”ＹＹＹ．ＶＯＢＩ”）の内部構造を示した図である。
【０１０３】
ＶＯＢ管理情報は、当該ＶＯＢのストリーム属性情報（Ａｔｔｒｉｂｕｔｅ）とタイムマップを有している。ストリーム属性は、ビデオ属性（Ｖｉｄｅｏ）、オーディオ属性（Ａｕｄｉｏ＃０〜Ａｕｄｉｏ＃ｍ）個々に持つ構成となっている。特にオーディオストリームの場合は、ＶＯＢが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数（Ｎｕｍｂｅｒ）によって、データフィールドの有無を示している。
【０１０４】
下記はビデオ属性（Ｖｉｄｅｏ）の持つフィールドと夫々が持ち得る値である。
圧縮方式（Ｃｏｄｉｎｇ）：
ＭＰＥＧ１
ＭＰＥＧ２
ＭＰＥＧ４
ＭＰＥＧ４−ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）
解像度（Ｒｅｓｏｌｕｔｉｏｎ）：
１９２０ｘ１０８０
１４４０ｘ１０８０
１２８０ｘ７２０
７２０ｘ４８０
７２０ｘ５６５
アスペクト比（Ａｓｐｅｃｔ）
４：３
１６：９
フレームレート（Ｆｒａｍｅｒａｔｅ）
６０
５９．９４（６０／１．００１）
５０
３０
２９．９７（３０／１．００１）
２５
２４
２３．９７６（２４／１．００１）
【０１０５】
下記はオーディオ属性（Ａｕｄｉｏ）の持つフィールドと夫々が持ち得る値である。
圧縮方式（Ｃｏｄｉｎｇ）：
ＡＣ３
ＭＰＥＧ１
ＭＰＥＧ２
ＬＰＣＭ
チャンネル数（Ｃｈ）：
１〜８
言語属性（Ｌａｎｇｕａｇｅ）：
【０１０６】
タイムマップ（ＴＭＡＰ）はＶＯＢＵ毎の情報を持つテーブルであって、当該ＶＯＢが有するＶＯＢＵ数（Ｎｕｍｂｅｒ）と各ＶＯＢＵ情報（ＶＯＢＵ＃１〜ＶＯＢＵ＃ｎ）を持つ。個々のＶＯＢＵ情報は、ＶＯＢＵ先頭ＴＳパケット（Ｉピクチャ開始）のアドレスＩ＿ｓｔａｒｔと、そのＩピクチャの終了アドレスまでのオフセットアドレス（Ｉ＿ｅｎｄ）、およびそのＩピクチャの再生開始時刻（ＰＴＳ）から構成される。
【０１０７】
なお、Ｉ＿ｅｎｄの値はオフセット値、すなわちＩピクチャのサイズを持たせるのではなく、実際のＩピクチャの終了アドレスを持たせてもよい。
【０１０８】
図１１はＶＯＢＵ情報の詳細を説明する図である。
広く知られているように、ＭＰＥＧビデオストリームは高画質記録するために可変ビットレート圧縮されることがあり、その再生時間とデータサイズ間に単純な相関はない。逆に、音声の圧縮規格であるＡＣ３は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は１次式によって求めることができる。しかしながらＭＰＥＧビデオデータの場合は、個々のフレームは固定の表示時間、例えばＮＴＳＣの場合は１フレームは１／２９．９７秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるＩ／Ｐ／Ｂピクチャによってデータサイズは大きく変わってくる。従って、ＭＰＥＧビデオの場合は、時間とアドレスの関係は一次式の形で表現することは不可能である。
【０１０９】
当然の事として、ＭＰＥＧビデオデータを多重化しているＭＰＥＧシステムストリーム、即ちＶＯＢも時間とデータサイズとを一次式の形で表現することは不可能である。このため、ＶＯＢ内での時間とアドレスとの関係を結びつけるのがタイムマップ（ＴＭＡＰ）である。
【０１１０】
このようにして、ある時刻情報が与えられた場合、先ずは当該時刻がどのＶＯＢＵに属するのかを検索（ＶＯＢＵ毎のＰＴＳを追っていく）して、当該時刻の直前のＰＴＳをＴＭＡＰに持つＶＯＢＵに飛びこみ（Ｉ＿ｓｔａｒｔで指定されたアドレス）、ＶＯＢＵ先頭のＩピクチャから復号を開始し、当該時刻のピクチャから表示を開始する。
【０１１１】
次に図１２を使って、プレイリスト情報（”ＸＸＸ．ＰＬ”）の内部構造を説明する。
プレイリスト情報は、セルリスト（ＣｅｌｌＬｉｓｔ）とイベントリスト（ＥｖｅｎｔＬｉｓｔ）から構成されている。
【０１１２】
セルリスト（ＣｅｌｌＬｉｓｔ）は、プレイリスト内の再生セルシーケンスであり、本リストの記述順でセルが再生される事になる。セルリスト（ＣｅｌｌＬｉｓｔ）の中身は、セルの数（Ｎｕｍｂｅｒ）と各セル情報（Ｃｅｌｌ＃１〜Ｃｅｌｌ＃ｎ）である。
【０１１３】
セル情報（Ｃｅｌｌ＃）は、ＶＯＢファイル名（ＶＯＢＮａｍｅ）、当該ＶＯＢ内での開始時刻（Ｉｎ）および終了時刻（Ｏｕｔ）と、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）を持っている。開始時刻（Ｉｎ）および終了時刻（Ｏｕｔ）は、夫々当該ＶＯＢ内でのフレーム番号で表現され、前述したタイムマップを使うことによって再生に必要なＶＯＢデータのアドレスを得る事ができる。
【０１１４】
字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は、当該ＶＯＢと同期再生される字幕情報を持つテーブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）最初の情報も言語数（Ｎｕｍｂｅｒ）とそれに続く個々の言語ごとのテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）から構成されている。
【０１１５】
各言語のテーブル（Ｌａｎｇｕａｇｅ＃）は、言語情報（Ｌａｎｇ）と、個々に表示される字幕の字幕情報数（Ｎｕｍｂｅｒ）と、個々に表示される字幕の字幕情報（Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）から構成され、字幕情報（Ｓｐｅｅｃｈ＃）は対応するイメージデータファイル名（Ｎａｍｅ）、字幕表示開始時刻（Ｉｎ）および字幕表示終了時刻（Ｏｕｔ）と、字幕の表示位置（Ｐｏｓｉｔｉｏｎ）から構成されている。
【０１１６】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、当該プレイリスト内で発生するイベントを定義したテーブルである。イベントリストは、イベント数（Ｎｕｍｂｅｒ）に続いて個々のイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）から構成され、個々のイベント（Ｅｖｅｎｔ＃）は、イベントの種類（Ｔｙｐｅ）、イベントのＩＤ（ＩＤ）、イベント発生時刻（Ｔｉｍｅ）と有効期間（Ｄｕｒａｔｉｏｎ）から構成されている。
【０１１７】
図１３は、個々のプレイリスト毎のイベントハンドラ（時間イベントと、メニュー選択用のユーザイベント）を持つイベントハンドラテーブル（”ＸＸＸ．ＰＲＯＧ”）である。
【０１１８】
イベントハンドラテーブルは、定義されているイベントハンドラ／プログラム数（Ｎｕｍｂｅｒ）と個々のイベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）を有している。各イベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃）内の記述は、イベントハンドラ開始の定義（＜ｅｖｅｎｔ＿ｈａｎｄｌｅｒ＞タグ）と前述したイベントのＩＤと対になるイベントハンドラのＩＤ（ＩＤ）を持ち、その後に当該プログラムもＦｕｎｃｔｉｏｎに続く括弧”｛”と”｝”の間に記述する。前述の”ＸＸＸ．ＰＬ”のイベントリスト（ＥｖｅｎｔＬｉｓｔ）に格納されたイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）は”ＸＸＸ．ＰＲＯＧ”のイベントハンドラのＩＤ（ＩＤ）を用いて特定される。
【０１１９】
次に図１４を用いてＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）の内部構造を説明する。
【０１２０】
ＢＤディスク全体情報は、タイトルリスト（ＴｉｔｌｅＬｉｓｔ）とグローバルイベント用のイベントテーブル（ＥｖｅｎｔＬｉｓｔ）から構成されている。
【０１２１】
タイトルリスト（ＴｉｔｌｅＬｉｓｔ）は、ディスク内のタイトル数（Ｎｕｍｂｅｒ）と、これに続く各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）から構成されている。個々のタイトル情報（Ｔｉｔｌｅ＃）は、タイトルに含まれるプレイリストのテーブル（ＰＬＴａｂｌｅ）とタイトル内のチャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）を含んでいる。プレイリストのテーブル（ＰＬＴａｂｌｅ）はタイトル内のプレイリストの数（Ｎｕｍｂｅｒ）と、プレイリスト名（Ｎａｍｅ）即ちプレイリストのファイル名を有している。
【０１２２】
チャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）は、当該タイトルに含まれるチャプタ数（Ｎｕｍｂｅｒ）と個々のチャプタ情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）から構成され、個々のチャプタ情報（Ｃｈａｐｔｅｒ＃）は当該チャプタが含むセルのテーブル（ＣｅｌｌＴａｂｌｅ）を持ち、セルのテーブル（ＣｅｌｌＴａｂｌｅ）はセル数（Ｎｕｍｂｅｒ）と個々のセルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）から構成されている。セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃）は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。
【０１２３】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、グローバルイベントの数（Ｎｕｍｂｅｒ）と個々のグローバルイベントの情報を持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）と呼ばれ、ＢＤディスクがプレーヤに挿入された時、最初に呼ばれるイベントである。グローバルイベント用イベント情報はイベントタイプ（Ｔｙｐｅ）とイベントのＩＤ（ＩＤ）だけを持っている。
【０１２４】
図１５は、グローバルイベントハンドラのプログラムのテーブル（”ＢＤ．ＰＲＯＧ”）である。
【０１２５】
本テーブルは、図１６で説明したイベントハンドラテーブルと同一内容である。
【０１２６】
（イベント発生のメカニズム）
図１６から図１８を使ってイベント発生のメカニズムについて説明する。
【０１２７】
図１６はタイムイベントの例である。
前述したとおり、タイムイベントはプレイリスト情報（”ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。タイムイベントとして定義されているイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＴｉｍｅＥｖｅｎｔ”の場合、イベント生成時刻（”ｔ１”）になった時点で、ＩＤ”Ｅｘ１”を持つタイムイベントがシナリオプロセッサからプログラムプロセッサに対してあげられる。プログラムプロセッサは、イベントＩＤ”Ｅｘ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合では、２つのボタンイメージの描画を行うなどを行うことができる。
【０１２８】
図１７はメニュー操作を行うユーザーイベントの例である。
前述したとおり、メニュー操作を行うユーザイベントもプレイリスト情報（”ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。ユーザイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＵｓｅｒＥｖｅｎｔ”の場合、イベント生成時刻（”ｔ１”）になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。当該イベントは、有効期間情報（Ｄｕｒａｔｉｏｎ）で記される期間レディ状態にある。
【０１２９】
図１７に描くように、ユーザがリモコンキーの「上」「下」「左」「右」キーまたは「決定」キーを押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してＵＯＰイベントを流し、シナリオプロセッサはＵＯＰイベントを受け取った時刻に有効なユーザイベントが存在するかを検索し、対象となるユーザイベントがあった場合は、ユーザイベントを生成し、プログラムプロセッサに持ち上げる。プログラムプロセッサでは、イベントＩＤ”Ｅｖ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合では、プレイリスト＃２の再生を開始する。
【０１３０】
生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、ＵＯＰイベントによってプログラムプロセッサに伝えられ、仮想プレーヤが持つレジスタＳＰＲＭ（８）に記録保持される。イベントハンドラのプログラムは、このレジスタの値を調べ分岐処理を実行することが可能である。
【０１３１】
図１８はグローバルイベントの例である。
前述したとおり、グローバルイベントはＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。グローバルイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＧｌｏｂａｌＥｖｅｎｔ”の場合、ユーザのリモコンキー操作があった場合にのみイベントが生成される。
【０１３２】
ユーザが”メニュー”を押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してＵＯＰイベントを流し、シナリオプロセッサは、該当するグローバルイベントを生成し、プログラムプロセッサに送る。プログラムプロセッサでは、イベントＩＤ”ｍｅｎｕ”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合ではプレイリスト＃３の再生を開始している。
【０１３３】
本実施例では、単に”メニュー”キーと呼んでいるが、ＤＶＤのように複数のメニューキーがあってもよい。各メニューキーに対応するＩＤを夫々定義することで対応することが可能である。
【０１３４】
（仮想プレーヤマシン）
図１９を用いてプログラムプロセッサの機能構成を説明する。
【０１３５】
プログラムプロセッサは、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンはＢＤとして定義された機能モデルであって、各ＢＤプレーヤの実装には依存しないものである。即ち、どのＢＤプレーヤにおいても同様の機能を実行するできることを保証している。
【０１３６】
仮想プレーヤマシンは大きく２つの機能を持っている。プログラミング関数とプレーヤ変数（レジスタ）である。プログラミング関数は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔをベースとして、以下に記す２つの機能をＢＤ固有関数として定義している。
【０１３７】
リンク関数：現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始する
Ｌｉｎｋ（ＰＬ＃，Ｃｅｌｌ＃，ｔｉｍｅ）
ＰＬ＃ ： プレイリスト名
Ｃｅｌｌ＃ ： セル番号
ｔｉｍｅ ： セル内での再生開始時刻
ＰＮＧ描画関数：指定ＰＮＧデータをイメージプレーンに描画する
Ｄｒａｗ（Ｆｉｌｅ，Ｘ，Ｙ）
Ｆｉｌｅ ： ＰＮＧファイル名
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
イメージプレーンクリア関数：イメージプレーンの指定領域をクリアする
Ｃｌｅａｒ（Ｘ，Ｙ，Ｗ，Ｈ）
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
Ｗ ： Ｘ方向幅
Ｈ ： Ｙ方向幅
プレーヤ変数は、プレーヤの状態を示すシステムパラメータ（ＳＰＲＭ）と一般用途として使用可能なゼネラルパラメータ（ＧＰＲＭ）とがある。
【０１３８】
図２０はシステムパラメータ（ＳＰＲＭ）の一覧である。
ＳＰＲＭ（０） ： 言語コード
ＳＰＲＭ（１） ： 音声ストリーム番号
ＳＰＲＭ（２） ： 字幕ストリーム番号
ＳＰＲＭ（３） ： アングル番号
ＳＰＲＭ（４） ： タイトル番号
ＳＰＲＭ（５） ： チャプタ番号
ＳＰＲＭ（６） ： プログラム番号
ＳＰＲＭ（７） ： セル番号
ＳＰＲＭ（８） ： 選択キー情報
ＳＰＲＭ（９） ： ナビゲーションタイマー
ＳＰＲＭ（１０） ： 再生時刻情報
ＳＰＲＭ（１１） ： カラオケ用ミキシングモード
ＳＰＲＭ（１２） ： パレンタル用国情報
ＳＰＲＭ（１３） ： パレンタルレベル
ＳＰＲＭ（１４） ： プレーヤ設定値（ビデオ）
ＳＰＲＭ（１５） ： プレーヤ設定値（オーディオ）
ＳＰＲＭ（１６） ： 音声ストリーム用言語コード
ＳＰＲＭ（１７） ： 音声ストリーム用言語コード（拡張）
ＳＰＲＭ（１８） ： 字幕ストリーム用言語コード
ＳＰＲＭ（１９） ： 字幕ストリーム用言語コード（拡張）
ＳＰＲＭ（２０） ： プレーヤリージョンコード
ＳＰＲＭ（２１） ： 予備
ＳＰＲＭ（２２） ： 予備
ＳＰＲＭ（２３） ： 再生状態
ＳＰＲＭ（２４） ： 予備
ＳＰＲＭ（２５） ： 予備
ＳＰＲＭ（２６） ： 予備
ＳＰＲＭ（２７） ： 予備
ＳＰＲＭ（２８） ： 予備
ＳＰＲＭ（２９） ： 予備
ＳＰＲＭ（３０） ： 予備
ＳＰＲＭ（３１） ： 予備
なお、本実施例では、仮想プレーヤのプログラミング関数をＪａｖａＳｃｒｉｐｔベースとしたが、ＪａｖａＳｃｒｉｐｔではなく、ＵＮＩＸ（登録商標） ＯＳなどで使われているＢ−Ｓｈｅｌｌや、Ｐｅｒｌ Ｓｃｒｉｐｔなど他のプログラミング関数であっても構わなく、言い換えれば、本発明はＪａｖａＳｃｒｉｐｔに限定されるものでは無い。
【０１３９】
（プログラムの例）
図２１および図２２は、イベントハンドラでのプログラムの例である。
【０１４０】
図２１は、２つの選択ボタンを持ったメニューの例である。
セル（ＰｌａｙＬｉｓｔ＃１．Ｃｅｌｌ＃１）先頭でタイムイベントを使って図２４左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つＧＰＲＭ（０）に”１”がセットされている。ＧＰＲＭ（０）は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン１が選択されている事を初期値として持たされている。
【０１４１】
次に、ＰＮＧの描画を描画関数であるＤｒａｗを使ってボタン１、ボタン２夫々について行っている。ボタン１は、座標（１０、２００）を起点（左端）としてＰＮＧイメージ”１ｂｌａｃｋ．ｐｎｇ”を描画している。ボタン２は、座標（３３０，２００）を起点（左端）としてＰＮＧイメージ”２ｗｈｉｔｅ．ｐｎｇ”を描画している。
【０１４２】
また、本セル最後ではタイムイベントを使って図２４右側のプログラムが実行される。ここでは、Ｌｉｎｋ関数を使って当該セルの先頭から再度再生するように指定している。
【０１４３】
図２２は、メニュー選択のユーザイベントのイベントハンドラの例である。
「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合夫々に対応するプログラムがイベントハンドラに書かれている。ユーザがリモコンキーを押した場合、図１７で説明したとおり、ユーザイベントが生成され、図２２のイベントハンドラが起動されることになる。本イベントハンドラでは、選択ボタンを識別しているＧＰＲＭ（０）の値と、選択されたリモコンキーを識別するＳＰＲＭ（８）を使って分岐処理を行っている。
【０１４４】
条件１）ボタン１が選択されている、かつ、選択キーが「右」キーの場合
ＧＰＲＭ（０）を２に再設定して、選択状態にあるボタンを右ボタン２に変更する。
ボタン１、ボタン２のイメージを夫々書き換える。
条件２）選択キーが「決定（ＯＫ）」の場合で、ボタン１が選択されている場合
プレイリスト＃２の再生を開始する
条件３）選択キーが「決定（ＯＫ）」の場合で、ボタン２が選択されている場合
プレイリスト＃３の再生を開始する
上記のようにして実行処理が行われる。
【０１４５】
（プレーヤ処理フロー）
次に図２３から図２６を用いてプレーヤでの処理フローを説明する。
【０１４６】
図２３は、ＡＶ再生までの基本処理フローである。
ＢＤディスクを挿入すると（Ｓ１０１）、ＢＤプレーヤはＢＤ．ＩＮＦＯファイルの読み込みと解析（Ｓ１０２）、ＢＤ．ＰＲＯＧの読み込み（Ｓ１０３）を実行する。ＢＤ．ＩＮＦＯおよびＢＤ．ＰＲＯＧは共に管理情報記録メモリに一旦格納され、シナリオプロセッサによって解析される。
【０１４７】
続いて、シナリオプロセッサは、ＢＤ．ＩＮＦＯファイル内のファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）情報に従い、最初のイベントを生成する（Ｓ１０４）。生成されたファーストイベントは、プログラムプロセッサで受け取られ、当該イベントに対応するイベントハンドラを実行処理する（Ｓ１０５）。
【０１４８】
ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリスト情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになる。（Ｓ２０１）。ＢＤプレーヤはユーザからのリモコン操作を受け付けると、ＵＯＰマネージャはプログラムマネージャに対してＵＯＰイベントを立ち上げる（Ｓ２０２）。
【０１４９】
プログラムマネージャは、ＵＯＰイベントがメニューキーかを判別し（Ｓ２０３）、メニューキーの場合は、シナリオプロセッサにＵＯＰイベントを流し、シナリオプロセッサがユーザイベントを生成する（Ｓ２０４）。プログラムプロセッサは生成されたユーザイベントに対応するイベントハンドラを実行処理する（Ｓ２０５）。
【０１５０】
図２４は、ＰＬ再生開始からＶＯＢ再生開始までの処理フローである。
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始される（Ｓ３０１）。シナリオプロセッサは、再生対象のプレイリスト再生に必要な情報として、プレイリスト情報”ＸＸＸ．ＰＬ”の読み込みと解析（Ｓ３０２）、プレイリストに対応するプログラム情報”ＸＸＸ．ＰＲＯＧ”の読み込みを行う（Ｓ３０３）。続いてシナリオプロセッサは、プレイリストに登録されているセル情報に基づいてセルの再生を指示する（Ｓ３０４）。セル再生は、シナリオプロセッサからプレゼンテーションコントローラに対して要求が出さる事を意味し、プレゼンテーションコントローラはＡＶ再生を開始する（Ｓ３０５）。
【０１５１】
ＡＶ再生の開始（Ｓ４０１）を開始すると、プレゼンテーションコントローラは再生するセルに対応するＶＯＢの情報ファイル（ＸＸＸ．ＶＯＢＩ）を読み込みおよび解析をする（Ｓ４０２）。プレゼンテーションコントローラは、タイムマップを使って再生開始するＶＯＢＵとそのアドレスを特定し、ドライブコントローラに読み出しアドレスを指示し、ドライブコントローラは対象となるＶＯＢデータを読み出し（Ｓ４０３）、ＶＯＢデータがデコーダに送られ再生が開始される（Ｓ４０４）。
【０１５２】
ＶＯＢ再生は、当該ＶＯＢの再生区間が終了するまで続けられ（Ｓ４０５）、終了すると次のセル再生Ｓ３０４へ移行する。次にセルが無い場合は、再生が停止する（Ｓ４０６）。
【０１５３】
図２５は、ＡＶ再生開始後からのイベント処理フローである。
ＢＤプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスが夫々起動され、平行してイベント処理を実行するようになる。
【０１５４】
Ｓ５００系の処理は、タイムイベント系の処理フローである。
プレイリスト再生開始後（Ｓ５０１）、プレイリスト再生が終了しているかを確認するステップ（Ｓ５０２）を経て、シナリオプロセッサは、タイムイベント発生時刻になったかを確認する（Ｓ５０３）。タイムイベント発生時刻になっている場合には、シナリオプロセッサはタイムイベントを生成し（Ｓ５０４）、プログラムプロセッサがタイムイベントを受け取りイベントハンドラを実行処理する（Ｓ５０５）。
【０１５５】
ステップＳ５０３でタイムイベント発生時刻になっていない場合、または、ステップＳ５０４でイベントハンドラ実行処理後は再度ステップＳ５０２へ戻り、上述した処理を繰り返す。また、ステップＳ５０２でプレイリスト再生が終了したことが確認されると、タイムイベント系の処理は強制的に終了する。
【０１５６】
Ｓ６００系の処理は、ユーザイベント系の処理フローである。
プレイリスト再生開始後（Ｓ６０１）、プレイリスト再生終了確認ステップ（Ｓ６０２）を経て、ＵＯＰ受付確認ステップの処理に移る（Ｓ６０３）。ＵＯＰの受付があった場合、ＵＯＰマネージャはＵＯＰイベントを生成し（Ｓ６０４）、ＵＯＰイベントを受け取ったプログラムプロセッサはＵＯＰイベントがメニューコールであるかを確認し（Ｓ６０５）、メニューコールであった場合は、プログラムプロセッサはシナリオプロセッサにイベントを生成させ（Ｓ６０７）、プログラムプロセッサはイベントハンドラを実行処理する（Ｓ６０８）。
【０１５７】
ステップＳ６０５でＵＯＰイベントがメニューコールで無いと判断された場合、ＵＯＰイベントはカーソルキーまたは「決定」キーによるイベントである事を示している。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサが判断し（Ｓ６０６）、有効期間内である場合には、シナリオプロセッサがユーザイベントを生成し（Ｓ６０７）、プログラムプロセッサが対象のイベントハンドラを実行処理する（Ｓ６０８）。
【０１５８】
ステップＳ６０３でＵＯＰ受付が無い場合、ステップＳ６０６で現在時刻がユーザイベント有効期間に無い場合、または、ステップＳ６０８でイベントハンドラ実行処理後は再度ステップＳ６０２へ戻り、上述した処理を繰り返す。また、ステップＳ６０２でプレイリスト再生が終了したことが確認されると、ユーザイベント系の処理は強制的に終了する。
【０１５９】
図２６は字幕処理のフローである。
プレイリスト再生開始後（Ｓ７０１）、プレイリスト再生終了確認ステップ（Ｓ７０２）を経て、字幕描画開始時刻確認ステップに移る（Ｓ７０３）。字幕描画開始時刻の場合、シナリオプロセッサはプレゼンテーションコントローラに字幕描画を指示し、プレゼンテーションコントローラはイメージプロセッサに字幕描画を指示する（Ｓ７０４）。ステップＳ７０３で字幕描画開始時刻で無いと判断された場合、字幕表示終了時刻であるかを確認する（Ｓ７０５）。字幕表示終了時刻であると判断された場合は、プレゼンテーションコントローラがイメージプロセッサに字幕消去指示を行い、描画されている字幕をイメージプレーンから消去する（Ｓ７０６）。
【０１６０】
字幕描画ステップＳ７０４終了後、字幕消去ステップＳ７０６終了後、または、字幕表示終了時刻確認ステップＳ７０５で当該時刻でないことが判断された場合、ステップＳ７０２に戻り、上述した処理を繰り返す。また、ステップＳ７０２でプレイリスト再生が終了したことが確認されると、字幕表示系の処理は強制的に終了する。
【０１６１】
（実施の形態２）
本実施の形態では、Ｐ／Ｉピクチャを使用する際に、ストリームおよび管理情報を制約することにより特殊再生時の再生品質を向上させる。以下に、符号化ストリームを多重化する際の制約事項について説明する。
【０１６２】
まず、タイムマップと符号化ストリームとの関係について説明する。タイムマップからは、再生開始点として選択できる位置や、特殊再生時に読み込むことができるピクチャ指すことができる。本発明のタイムマップは、再生開始点として選択できる位置や、特殊再生時に読み込むことができる点として、Ｐ／Ｉピクチャから開始するＲＡＵは選択しない。
【０１６３】
図３０は、タイムマップとＲＡＵの関係を示している。再生開始点や特殊再生時に読み込まれるＲＡＵ先頭のピクチャの位置は、図３０が示すようにタイムマップに時間と関連付けられてアドレスが格納されている。時間を指定されると、タイムマップを利用して、再生開始するアドレスを割り出し、シークを行って再生を開始するわけである。この際、Ｐ／Ｉピクチャは、再生開始位置や特殊再生時に読み込まれるピクチャとして適切ではないため、タイムマップには登録しない。こうすることにより、再生開始点や特殊再生時には選択されず、解像度が半分に落ちた画像から再生が開始されることが回避できる。
【０１６４】
また、タイムマップの属性情報の１つとして、ストリーム中にＰ／Ｉピクチャが存在しないことを保証するフラグがあってもよい。このフラグが有効であれば、Ｐ／Ｉピクチャは存在しないので、どのＲＡＵ先頭から再生を開始してもよい。
【０１６５】
また、タイムマップの属性情報の１つとして、タイムマップがＰ／Ｉピクチャを指していないことを保証するフラグがあってもよい。このフラグが有効であれば、タイムマップはＰ／Ｉピクチャを指していないため、タイムマップに登録してあるＲＡＵ先頭位置から再生を開始すればよい。
【０１６６】
この２つの属性情報のいずれかがあれば、プレーヤはストリームを解析することなく、タイムマップを参照するだけで、十分な解像度をもって再生を開始できる再生開始位置の情報を取得することが可能となる。
【０１６７】
図３１は、タイムマップに属性情報を追加して、タイムマップが指すピクチャのピクチャタイプを登録できるようにした例である。このようにピクチャタイプが分かれば、再生開始位置としてＰ／Ｉピクチャは選ばないよう、プレーヤが判断することも可能となるので、このような方法も有効である。
【０１６８】
なお、図３２に示すように、Ｐ／Ｉピクチャにおいて、第１フィールドのＰピクチャが第２フィールドのＩピクチャを参照している場合、最初のフレームをデコードすることが可能となるため、これまで述べてきたＰ／Ｉピクチャと区別して、こちらの場合は再生開始点や特殊再生時に表示できるピクチャとして選択してもよい。
【０１６９】
以下に、制約方法の他の例について説明する。
ストリームの接続点、あるいはアングルの切替え点においては、切替え前後で再生画像をシームレスに連結できることが重要である。従って、シームレスな接続を実現するために、切替え後の先頭ピクチャとしてＰ／Ｉピクチャを禁止することは有効であり、下記が可能である。
【０１７０】
１．タイムマップからＰ／Ｉピクチャを指さない
２．ストリームにおいてＲＡＵの先頭をＰ／Ｉピクチャとしない
以下、１、２の順に説明する。
【０１７１】
タイムマップには、現プレイアイテムと直前のプレイアイテムとがシームレスに接続できるかどうかを示すフラグが格納される。従って、当該フラグにより、シームレスに接続できることが示されるプレイアイテムにおいては、プレイアイテムの先頭ピクチャとしてＰ／Ｉピクチャを配置しないことにしてもよい。また、タイムマップにおいては、プレイアイテムが１以上のアングルについての情報を示すことができ、さらに、アングル切替えをシームレスに行えるかどうかを示すフラグが格納できる。従って、シームレスなアングル切替えが可能であると示される際には、各アングルの先頭ピクチャとしてＰ／Ｉピクチャを配置しないことにしてもよい。あるいは、アングル切替えのポイントにおいては、シームレスであるかどうかに関わらず、アングル切替わり後の先頭ピクチャとしてはＰ／Ｉピクチャを禁止してもよい。また、各プレイアイテムをランダムアクセス再生することがコンテンツ作成者によって許可されているかどうかを示すフラグも格納されるため、ランダムアクセスが許可される際には、プレイアイテムの先頭にＰ／Ｉピクチャを配置しないことにしてもよい。図３３の例は、シームレス接続可能であることを示すフラグがセットされていれば、プレイアイテムの先頭ピクチャはＩ／Ｉピクチャ、またはＩ／Ｐピクチャのみであり、セットされていなければ、Ｐ／Ｉピクチャがプレイアイテムの先頭であってもよいことを示す。
【０１７２】
なお、本方式はＰ／Ｉピクチャに限定されるものではなく、ＲＡＵの先頭ピクチャの復号が保証できないケース全般において使用できる。なお、シームレスに接続できるかどうかを示す情報は、現プレイアイテムと直後のプレイアイテムとの関係を示してもよいし、プレイリストにより示される全てのプレイアイテムについての情報であってもよい。
【０１７３】
次に、タイムマップと組み合わせずに、ＶＣ−１のストリーム内で制約する例について説明する。Ｐ／Ｉピクチャの有無は、ＲＡＵ内のピクチャの復号を開始する前に判定できることが望ましいことから、ＲＡＵの先頭ピクチャがＰ／Ｉピクチャであるかどうかを示す情報をＲＡＵの先頭に格納する。先に、ＶＣ−１のＲＡＵには、クローズドＧＯＰ型とオープンＧＯＰ型の２種類があることを述べた。ＲＡＵがどちらのタイプであるかは、エントリ・ポイントのヘッダ内のフラグにより示され、フラグがセットされていればクローズドＧＯＰ型、セットされていなければオープンＧＯＰ型となる。シームレス接続やマルチアングル再生などにおいては、クローズドＧＯＰ型のＲＡＵから再生を開始するのが一般的であるため、クローズドＲＡＵの先頭ピクチャをＰ／Ｉピクチャとしないことにする。このとき、ＲＡＵがクローズドＧＯＰ型であるかどうかを示すフラグを、ＲＡＵの先頭ピクチャがＰ／Ｉピクチャであるかどうかを示すフラグとして使うことができる。従って、図３４に示すように、エントリ・ポイントのヘッダにおいてクローズドＧＯＰ型のＲＡＵであることが示される場合には、ＲＡＵの先頭ピクチャとしてＰ／Ｉピクチャを禁止し、オープンＧＯＰ型のＲＡＵであることが示される場合にはＲＡＵの先頭ピクチャとしてＰ／Ｉピクチャを使用可能とする。なお、ＲＡＵの先頭がＰ／Ｉピクチャであるかどうかを示す情報を、ユーザーデータなどを利用して別途格納してもよい。
【０１７４】
さらに、タイムマップの情報とストリーム内の情報とを組み合わせて使うことにより、ランダムアクセス単位の属性として下記４種類の情報を示すことができる。
【０１７５】
１．クローズドＧＯＰ型のＲＡＵであり、ＲＡＵの先頭ピクチャはＰ／Ｉピクチャではない
２．クローズドＧＯＰ型のＲＡＵであり、ＲＡＵの先頭ピクチャはＰ／Ｉピクチャであってもよい
３．オープンＧＯＰ型のＲＡＵであり、ＲＡＵの先頭ピクチャはＰ／Ｉピクチャではない
４．オープンＧＯＰ型のＲＡＵであり、ＲＡＵの先頭ピクチャはＰ／Ｉピクチャであってもよい
【０１７６】
例えば、（ストリーム内でクローズド型のＧＯＰであるかどうかを示すフラグ、タイムマップにおいてシームレス接続可能かどうかを示すフラグ）＝（１，１）、（１，０）、（０，１）、（０，０）の組み合わせが、それぞれ上記１、２、３、４を示すとする。こうすることで、Ｉピクチャのみの高速再生、飛び込み再生、シームレス接続、あるいはマルチアングル再生など、アプリケーションによって重視されるパターンに応じて上記のいずれかの属性を選択して使用できる。具体的には、上記１と、上記３あるいは上記４を選択すれば、オープンＧＯＰ型のＲＡＵにおいてはＩ／Ｐピクチャの配置に対しては制約がなく、クローズドＧＯＰ型のＲＡＵではＩ／Ｐピクチャを先頭に配置しないことになる。なお、上記１と上記２、およびオープンＧＯＰ型のＲＡＵの３種類を定義してもよい。
【０１７７】
また、ストリームのビットレートに応じてＰ／Ｉピクチャが使用できるかどうかを切替えてもよい。Ｐ／Ｉピクチャは、フレーム内の第２フィールドにおいてシーンチェンジが発生する際に有効であり、特に、低ビットレート時に有効である。従って、ＶＣ−１のストリーム、あるいは管理情報により示されるビットレートが所定の値以下、あるいは未満である場合にのみＰ／Ｉピクチャを使用可能としてもよい。ビットレートは、シーケンス・レイヤにおいて示すことができる。さらに、エントリ・ポイントレベルなどのユーザーデータにおいて、ビットレートを示してもよい。ここで、ユーザーデータにおいてビットレートを直接示さずに、ＲＡＵの先頭がＰ／Ｉピクチャであることを示す情報などが存在すれば、対応するＲＡＵ、あるいはストリーム全体におけるビットレートが所定の値以下、あるいは未満であるとしてもよい。ここで、再生機器の処理能力の上限値を設定するという意味で最大ビットレートが望ましいが、平均ビットレートであってもよい。また、ＶＣ−１規格では複数のレベルを設けて、レベル毎にビットレートや復号時に必要なバッファサイズなどを規定している。従って、レベルに応じてＰ／Ｉピクチャが使用できるかどうかを切替えてもよい。なお、レベルはシーケンス・レイヤなどにより示される。
【０１７８】
なお、上記の各制約方法を組み合わせて使用してもよく、例えば、ビットレートが所定の値以下である際には、オープンＧＯＰ型のＲＡＵにおいてのみＰ／Ｉピクチャを使用可能とする、などとしてもよい。これは、クローズドＧＯＰ型のＲＡＵではＧＯＰの先頭ピクチャから画質を劣化させずに再生できることが望ましいが、オープンＧＯＰ型のＲＡＵでは、元々ランダムアクセス時に復号できないピクチャが存在し得るため、Ｐ／Ｉピクチャの存在により復号できないピクチャが１枚増加することに対する許容度が大きいことによる。
【０１７９】
なお、ＢＤやＨＤ−ＤＶＤなど特定のアプリケーションでＶＣ−１ストリームを使用する際には、ＲＡＵの先頭をＰ／Ｉピクチャとすることを禁止してもよい。このとき、ＢＤ−ＲＯＭであれば、ＢＤ−ＩＮＦＯなど特定の名前のディレクトリが存在するかどうかによってアプリケーションの種類が示される。また、ＶＣ−１のストリームがメインのコンテンツであるか、ボーナス映像など付加的なコンテンツであるかに応じてＰ／Ｉピクチャの使用可否を切替えてもよい。一般に、付加的なコンテンツはビットレートが低く、Ｐ／Ｉピクチャが有効であるため、Ｐ／Ｉピクチャを使用可とし、ビットレートの高いメインのコンテンツにおいてはＰ／Ｉピクチャの使用を禁止する。ここで、メインのコンテンツであるか、付加的なコンテンツであるかは、ＢＤ管理情報内のフラグにより示される。あるいは、ネットワーク経由、ハードディスクなど光ディスクとは異なる場所に蓄積されたコンテンツを付加的なコンテンツとみなすこともできる。
【０１８０】
また、符号化ストリームはＶＣ−１に限定されるものではなく、第１フィールドがＰピクチャで、第２フィールドがＩピクチャであるフィールド・ペアを使える任意の符号化方式に適用できる。
【０１８１】
（実施の形態３）
図３８は、実施の形態２に係るＶＣ−１のストリームを符号化する本発明の符号化方法のフローチャートであり、クローズドＧＯＰ型のＲＡＵでは先頭にＰ／Ｉピクチャを配置しないように制約するステップＳ１１０１からステップＳ１１０３を新たに備えた点において従来の符号化方法と異なる。
【０１８２】
まず、ステップＳ１１０１では、符号化するピクチャがＲＡＵの先頭ピクチャであるかどうか判定し、先頭ピクチャであればステップＳ１１０２に進み、そうでなければステップＳ１１０４に進む。ステップＳ１１０３では、ＲＡＵがクローズドＧＯＰ型であるかどうか判定し、クローズドＧＯＰ型である際にはステップＳ１１０３に進み、そうでなければステップＳ１１０４に進む。ステップＳ１１０３では、ピクチャをフィールドとして符号化する際には、Ｉ／Ｉピクチャ、またはＩ／Ｐピクチャを用い、Ｐ／Ｉピクチャは使用しないと決定する。続いて、ステップＳ１１０４では、ステップＳ１１０３の決定に基づいてＲＡＵを構成するピクチャを符号化する。ここで、クローズドＧＯＰ型のＲＡＵである際には、ＲＡＵがクローズドＧＯＰ型であることを示すフラグをセットする。なお、ステップＳ１１０１に先立ってステップＳ１１０２の処理を行ってもよい。
【０１８３】
また、本符号化方法により符号化したストリームを、オーディオなどと多重化してもよい。多重化方式としては、ＭＰＥＧ−２のトランスポートストリーム、あるいはＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）などパッケージメディア毎に規定された方式がある。
【０１８４】
なお、出力されたストリームを多重化する際には、シームレス接続マルチアングル再生におけるアングルの切替りにおいては、接続点あるいは切替り点の直後の先頭ピクチャがＰ／Ｉピクチャとならないようにタイムマップを作成する。具体的には、接続点や切替り点としてはクローズドＧＯＰ型のＲＡＵのみを指定してもよい。
【０１８５】
図３９は、本実施の形態の符号化方法を実現する画像符号化装置１０の構成を示すブロック図である。画像符号化装置１０は、上記ステップＳ１１０１からステップＳ１１０３までの処理を行うタイプ制限ユニットＬＩＭＩＴを備えた点において従来の画像符号化装置１と異なる。予測構造決定ユニットＰＴＹＥは、タイプ制限ユニットＬＩＭＩＴにより指定されたピクチャタイプの制限情報ＬｍｔＩｎｆに基づいてピクチャの予測構造を決定する。
【０１８６】
（実施の形態４）
図４０は、実施の形態２に係るＶＣ−１ストリームの多重化データを復号する画像復号方法において、マルチアングル再生や、同一ストリーム内の異なる区間を連続して再生するなどの特殊再生時の表示動作を示すフローチャートである。本画像復号方法では、ＲＡＵの先頭ピクチャがＰ／Ｉピクチャであるかどうかに応じてピクチャの表示動作を切替えるステップＳ１００１からステップＳ１００４までの動作が不要である点において従来の画像復号方法と異なる。
【０１８７】
なお、タイムマップなどの管理情報によってマルチアングル再生が可能である、あるいは、シームレスに接続できることが保証される場合に限り、表示動作を切替えないことにして、当該情報が管理情報から識別できない場合には、従来の画像復号方法と同様に表示動作を切替えてもよい。
【０１８８】
なお、ＲＡＵがクローズドＧＯＰ型である際には表示動作を切替えずに、オープンＧＯＰ型であれば従来の画像復号方法と同様に表示動作を切替えてもよい。
【０１８９】
図４１は、本実施の形態の復号方法を実現する画像復号装置３０の構成を示すブロック図である。画像復号装置３０は、表示切替ユニットＭｏｄｅＳｅｔを備えない点において従来の画像復号装置と異なる。
【０１９０】
なお、上記各実施の形態における動画像の符号化方式はＶＣ−１に限定されるものではなく、同様の予測構造を有する符号化方式全般に適用できる。
【０１９１】
（実施の形態５）
本実施の形態５では、Ｐ／Ｉピクチャを用いることにより、ランダムアクセス再生や逆再生などの特殊再生の機能性向上を実現するデータ構造について説明する。
【０１９２】
まず、従来のデータ構造における第１の課題について説明する。図４３は、従来のＲＡＵの構造例を示す。図４３の例では、各ピクチャはフィールド構造で符号化されており、ＲＡＵの途中にはＰ／Ｉピクチャが存在する。ＶＣ−１規格では、ＲＡＵの先頭ピクチャとなるＰ／Ｉピクチャについては、表示順がＰ／Ｉピクチャよりも後であるピクチャが、Ｐ／ＩピクチャにおけるＰピクチャを参照することを禁止しているが、ＲＡＵの途中のＰ／Ｉピクチャについては、前記制約は規定していない。従って、図４３に示すように、Ｐ／Ｉピクチャよりも後のピクチャがＰ／ＩピクチャのＰピクチャを参照してもよい。このとき、Ｐ／ＩピクチャのＰピクチャは、表示順で前方のＰピクチャを参照できることから、Ｐ／Ｉピクチャ以降のピクチャを復号するためには、ＲＡＵの先頭ピクチャから復号しなければならない。従って、ユーザ操作などにより、Ｐ／Ｉピクチャ以降のピクチャから再生を開始する場合にも、タイムマップからランダムアクセス・ポイントとして指されたＲＡＵの先頭から、ＩピクチャとＰピクチャを少なくとも復号する必要がある。特に、ＲＡＵの再生時間長が長く、ＲＡＵを構成するピクチャの数が増えると、飛び込み位置から再生開始するために復号が必要なピクチャの数が増え、遅延および処理量が増大するという第１の課題がある。
【０１９３】
図４４は、従来のデータ構造の第２の課題について示す。実施の形態１から実施の形態４で述べたように、ＲＡＵの先頭ピクチャがＰ／Ｉピクチャであると、ＲＡＵの先頭のフレーム、あるいはフィールド・ペアのみを再生して高速再生を実現する際の再生品質が低下することから、ＲＡＵの先頭にはＰ／Ｉピクチャを配置しないように規定することがある。ここで、図４４（ａ）に示すように、第１フィールドと第２フィールドの間でシーンチェンジが発生したとする。特殊再生時には、シーンチェンジの発生位置から飛込み再生できることが望ましいため、ＲＡＵを分割することを考えると、ＲＡＵの先頭にはＰ／Ｉピクチャを配置できないことから、図４４（ｂ）に示すようにＲＡＵの先頭ピクチャをＩ／Ｉピクチャとする必要がある。この例のように、第１フィールドと第２フィールドの間でシーンチェンジが発生している際には、第１フィールドについては表示順で前の画像との相関が高いため、Ｐ／Ｉピクチャを使用したほうが符号化効率が向上する。従って、先頭ピクチャをＩ／Ｉピクチャにすることにより符号化効率が低下するという第２の課題がある。
【０１９４】
図４５は、本実施の形態のＲＡＵ構造例を示す。図４５のＲＡＵでは、ＲＡＵの途中のＰ／Ｉピクチャの予測構造について次の制約を設ける。
【０１９５】
・表示順がＰ／Ｉピクチャよりも後であるピクチャは、Ｐ／ＩピクチャにおけるＰピクチャを参照しない。
【０１９６】
これにより、ユーザ操作などにより、Ｐ／Ｉピクチャ以降のピクチャから再生を開始する場合にも、Ｐ／ＩピクチャにおけるＩピクチャから復号開始することにより、Ｐ／Ｉピクチャ以降のピクチャを復号でき、飛び込み再生時の遅延および処理量が軽減できるという効果が得られる。また、逆再生を行う場合にも、Ｐ／Ｉピクチャ以降のピクチャを再生する際に、ＲＡＵの先頭ピクチャから読み込んで復号する必要がなく、Ｐ／ＩピクチャのＩピクチャ、および以降のピクチャのみを読み込めばよいため、逆再生時に必要なバッファメモリのサイズ、あるいは、バッファメモリへのデータ読み込み回数を低減できるという効果が得られる。なお、Ｐ／Ｉピクチャは、通常、第１フィールドと第２フィールドの間でシーンチェンジが発生する際に使用されるため、Ｐ／Ｉピクチャ以降のピクチャと、Ｐ／ＩピクチャにおけるＰピクチャとの相関関係は低く、当該Ｐピクチャへの参照を制約しても符号化効率への影響は軽微である。
【０１９７】
図４６は、本実施の形態のＲＡＵ構造の他の例である。図４５の例では、タイムマップにおいてランダムアクセス・ポイントとして指される位置と、ＲＡＵとが一対一に対応していた。一方、図４６では、タイムマップが指すＮ番目とＮ＋１番目のランダムアクセス・ポイントの間に複数のＲＡＵが存在する。つまり、タイムマップから指されないＲＡＵが存在し、ここでは、ＲＡＵ２はタイムマップから指されない。図４６は、図４５のＲＡＵをＲＡＵ１とＲＡＵ２の２つのＲＡＵに分割したものであり、ＲＡＵの先頭ピクチャはＰ／Ｉピクチャとなる。ここで、ＲＡＵ２の先頭Ｐ／Ｉピクチャ以降のピクチャから再生を開始する場合、ＲＡＵ内の後続ピクチャは先頭Ｐ／ＩピクチャのＰピクチャを参照しないことが保証されるため、先頭Ｐ／ＩピクチャのＩピクチャから復号開始すればよい。
【０１９８】
このように、特殊再生時に復号動作をリセットするポイントとして、Ｐ／Ｉピクチャが使用できる。さらに、Ｐ／Ｉピクチャよりも後のピクチャがＰ／ＩピクチャのＰピクチャを参照しないという制約は、ＲＡＵ内の全てのＰ／Ｉピクチャに対して適用してもよいが、特殊再生時の効率を向上させるには、Ｐ／Ｉピクチャに対して選択的に制約をかければよく、Ｐ／Ｉピクチャに対して制約が適用されるかどうかを示す情報を付加することは有効である。この情報は、符号化ストリーム内に格納してもよいし、管理情報に格納してもよい。図４７は、表示順がＰ／Ｉピクチャよりも後のピクチャがＰ／ＩピクチャのＰピクチャを参照しないという制約が適用されるかどうかを示す情報を符号化ストリーム内に格納した例である。ここでは、ＲＡＵマップと呼ぶマップ情報により当該情報を格納する。図４７（ａ）に示すように、ＲＡＵマップはＲＡＵ内のピクチャデータよりも前に配置される。例えば、ＶＣ−１であればエントリ・ポイントレベルのユーザデータに格納できる。ここで、図４７（ａ）のＲＡＵマップは、図４７（ｂ）のＲＡＵについての情報を示す。図４７（ｂ）のＲＡＵでは、ＲＡＵ内に４つのＰ／Ｉピクチャが存在し、２番目のＰ／Ｉピクチャについてのみ参照関係が制約されている。従って、２番目のＰ／Ｉピクチャは、特殊再生時に復号動作をリセットするポイントとして使用できる。そこで、ＲＡＵマップには、１番目、３番目、４番目のＰ／Ｉピクチャについては参照関係が制約されていることが保証されておらず、２番目のＰ／Ｉピクチャについては参照関係が制約されていることが保証されている、ことが示される。
【０１９９】
図５４は、ＲＡＵマップのシンタックス例である。図５４（ａ）は、ＲＡＵを構成するフレーム、あるいはフィールド・ペアのタイプの一覧を復号順に示したテーブルである。各パラメータの定義は以下の通りとする。
【０２００】
ｎｕｍ＿ｆｒａｍｅ＿ｉｎ＿ＲＡＵ： ＲＡＵを構成するフレーム、あるいはフィールド・ペアの個数
ｆｒａｍｅ＿ｆｌａｇ： フレームであるかフィールド・ペアであるかを判別するフラグ
ｆｒａｍｅ＿ｔｙｐｅ： フレームのタイプ（Ｉフレーム、Ｐフレーム、Ｂフレーム、ＢＩフレーム、Ｓｋｉｐｐｅｄフレームなど）を示す識別子
ｆｉｅｌｄ＿ｐａｉｒ＿ｔｙｐｅ： フィールド・ペアのタイプ（Ｉ／Ｉピクチャ、Ｉ／Ｐピクチャ、Ｐ／Ｉピクチャなど）
【０２０１】
ここで、ｆｉｅｌｄ＿ｐａｉｒ＿ｔｙｐｅにおいて、復号動作がリセットできることが保証されたＰ／Ｉピクチャと、復号動作がリセットできることが保証されていないＰ／Ｉピクチャとで、異なる識別子を用いることにより、両者を区別できる。
【０２０２】
図５４（ｂ）は、ＲＡＵを構成するフレーム、あるいはフィールドのタイプの一覧を復号順に示したテーブルである。各パラメータの定義は以下の通りとする。
【０２０３】
ｎｕｍ＿ｐｉｃｔｕｒｅ＿ｉｎ＿ＲＡＵ： ＲＡＵを構成するフレーム、あるいはフィールドの個数
ｆｒａｍｅ＿ｆｌａｇ： フレームであるかフィールドであるかを判別するフラグ
ｐｉｃｔｕｒｅ＿ｔｙｐｅ： フレーム、あるいはフィールドのタイプ
【０２０４】
ここで、Ｐ／Ｉピクチャの第１フィールドであるＰピクチャについて、復号動作がリセットできることが保証されたＰ／ＩピクチャのＰピクチャと、復号動作がリセットできることが保証されていないＰ／ＩピクチャのＰピクチャとは、ｐｉｃｔｕｒｅ＿ｔｙｐｅにおいて異なる識別子を用いることにより区別される。
【０２０５】
なお、ｆｒａｍｅ＿ｆｌａｇには、フレームであるかフィールドであるかだけではなく、フレームにおけるに３：２プルダウン（テレシネ変換）についての情報などを含めてもよい。
【０２０６】
ＲＡＵ内に復号動作をリセットするポイントを設けることは、ＲＡＵの再生時間長が長い場合に特に有効である。ここで、ＲＡＵの時間長は、Ｉピクチャの間隔に依存し、ＩピクチャはＰピクチャやＢピクチャに比べて符号量が多いため、ＲＡＵの時間長を長くしてＩピクチャの間隔を長くすることにより、結果としてビットレートを低減できる。従って、低ビットレート時にはＲＡＵの時間長を長くすることが有効である。このため、ＲＡＵの再生時間長が所定の値以上、あるいは、符号化ストリームのビットレートが所定の値以下である場合にのみ、Ｐ／Ｉピクチャに対する参照関係の制約を適用する、あるいは、ＲＡＵマップを付加してＰ／Ｉピクチャに対する参照関係の制約があるかどうかを示してもよい。さらに、ＲＡＵの先頭Ｉピクチャのみを再生する高速再生など特殊再生時の再生品質を考慮して、ＲＡＵの再生時間長を所定の時間以下としてもよい。また、タイムマップにより指されるランダムアクセス・ポイント間の表示時刻あるいは復号時刻の差分値を所定の値以下としてもよい。ここで、オープンＧＯＰ型のＲＡＵでは、タイムマップにより指されるＩピクチャの表示時刻よりも、ＲＡＵ内で最初に表示されるＢピクチャなどの表示時刻のほうが早くなることに注意する。
【０２０７】
ＲＡＵ内に複数のＰ／Ｉピクチャが存在する場合には、特殊再生の実現容易性を考慮して、当該Ｐ／Ｉピクチャについて参照関係を制約するかどうかを決定できる。例えば、１秒など所定の単位で、特殊再生時に復号動作がリセットできるポイントを設ける際には、Ｐ／Ｉピクチャ間の表示時刻の差分が前記所定の単位以下となるように、Ｐ／Ｉピクチャについての参照関係を制約できる。
【０２０８】
以下に、図４６のようなケースでも、タイムマップが示す連続した２つのランダムアクセス・ポイントの間に特殊再生時の復号動作をリセットできるポイントが存在するかどうか示す方法を示す。図４８は、タイムマップによりランダムアクセス・ポイントであることが示されるＲＡＵの前にＲＡＵマップを配置して、次のランダムアクセス・ポイントとの間にあるＲＡＵについての情報を示す例である。ここでは、ランダムアクセス・ポイントの間には、２つのＲＡＵが存在し、それぞれの再生時間長が１秒であることが示される。ＲＡＵは、復号動作をリセットするポイントとして使用できるため、各ＲＡＵの再生時間長に基づいて、何番目のＲＡＵから復号を開始すればよいか決定できる。さらに、ＲＡＵマップにおいて、各ＲＡＵマップの先頭がＰ／Ｉピクチャであるかどうかを示してもよい。図４８におけるＲＡＵマップと、図４７に示したＲＡＵ単位のマップ情報とを合わせて使用してもよい。
【０２０９】
（実施の形態６）
本実施の形態６では、実施の形態５で示したデータを生成する画像符号化方法、および画像符号化装置について説明する。
【０２１０】
図４９は、本実施の形態の画像符号化方法において、ピクチャの参照関係を制約するかどうかを判定する際の動作を示すフローチャートである。まず、ステップＳ２００１において、現フレームあるいはフィールド・ペアをＰ／Ｉピクチャとして符号化するかどうか判定し、ステップＳ２００２に進む。ステップＳ２００２では、現フレームあるいはフィールド・ペアがＲＡＵの先頭フレームを構成するピクチャであるかどう判定し、先頭フレームを構成するピクチャであればステップＳ２００３に進み、そうでなければステップＳ２００４に進む。ステップＳ２００３では、現フレームあるいはフィールド・ペアが復号動作をリセットできるピクチャとするかどうか判定し、リセットするピクチャであればステップＳ２００４に進み、そうでなければ処理を終了する。ステップＳ２００４では、ＲＡＵ内において表示順が現Ｐ／Ｉピクチャよりも後であるピクチャが、現Ｐ／ＩピクチャにおけるＰピクチャを参照しないように、後続ピクチャの参照関係を制約すると決定する。なお、全てのＰ／Ｉピクチャを、復号動作がリセットできるピクチャとしてもよい。
【０２１１】
図５０は、ＲＡＵマップをＲＡＵの先頭に付加する際の動作を示すフローチャートである。本フローチャートでは、ＲＡＵマップの生成動作を主に説明し、各ピクチャの符号化動作の詳細については説明を省略する。まず、ステップＳ２１０１では、Ｐ／Ｉピクチャに関連して後続ピクチャの参照関係を制約するかどうか判定する。次に、ステップＳ２１０２では、ステップＳ２１０１で決定した制約を満たすように、ピクチャの参照関係を決定し、ステップＳ２１０３に進む。ステップＳ２１０３では、現ピクチャがＲＡＵの最終ピクチャであるかどうか判定し、最終ピクチャであればステップＳ２１０４に進み、そうでなければ処理を終了する。なお、ステップＳ２０１３では、現ピクチャがＲＡＵ内の最終Ｐ／Ｉピクチャであるかどうか判定してもよい。最後に、ステップＳ２０１４では、Ｐ／Ｉピクチャについての情報を格納したＲＡＵマップを生成し、ＲＡＵを構成するピクチャデータの前に付加する。
【０２１２】
図５１は、本実施の形態の画像符号化方法を実現する画像符号化装置２０００の構成を示すブロック図である。画像符号化装置２０００は、Ｐ／Ｉ制約決定ユニットＰｌｉｍとマップ情報作成ユニットＭａｐＩｎｆｏを新たに備えた点、および予測構造決定ユニットＰＴＹＰＥの動作が異なる点において従来の画像符号化装置１と異なる。Ｐ／Ｉ制約決定ユニットＰｌｉｍは、ステップＳ２００１からステップＳ２００４までの処理を行い、符号化されるピクチャがＰ／Ｉピクチャである際には、ＲＡＵ内の後続ピクチャが当該Ｐ／ＩピクチャのＰピクチャを参照しないとするかどうか決定する。予測構造決定ユニットＰＴＹＰＥは、Ｐ／Ｉ制約決定ユニットＰｌｉｍで決定された条件を満たすように、ピクチャの符号化タイプおよび参照関係などを決定する。一方、マップ情報作成ユニットＭａｐＩｎｆｏは、実施の形態５で述べたＲＡＵマップを生成する。
【０２１３】
（実施の形態７）
本実施の形態７では、実施の形態５で示したデータを復号する画像復号方法、および画像復号装置について説明する。
【０２１４】
図５２は、本実施の形態の画像復号方法における特殊再生時の復号動作を示すフローチャートである。本方法は、ユーザ操作などにより飛び込み再生、あるいは逆再生などを行う際に、復号を開始するピクチャを決定する際に特に有効である。まず、ステップＳ２２０１において、タイムマップにより指されるピクチャとは異なるピクチャ（Ｐｉｃ＿ｓｔ）から再生開始するかどうか判定し、Ｐｉｃ＿ｓｔと異なるピクチャから再生開始する際には、ステップＳ２２０２に進み、そうでなければステップＳ２２０４に進む。ステップＳ２２０２では、Ｐｉｃ＿ｓｔよりも復号順が前である、復号動作をリセットできるＰ／Ｉピクチャ（ＰＩ＿ｓｔ）が存在するかどうか判定する。ここで、判定時には、ＲＡＵマップを参照して、復号順が、
・Ｐｉｃ＿ｓｔよりも前であり、
・タイムマップにより指されるＲＡＵの先頭ピクチャよりも後である、
復号動作がリセットできるＰ／Ｉピクチャを検索する。なお、ＰＩ＿ｓｔは、Ｐｉｃ＿ｓｔよりも復号順が前であり、かつ復号順がＰｉｃ＿ｓｔに最も近いピクチャとする。
【０２１５】
次に、ステップＳ２２０３では、ＰＩ＿ｓｔにおけるＩピクチャから復号開始すると決定する。ステップＳ２２０４では、タイムマップにより指されるＲＡＵの先頭ピクチャから復号開始すると決定する。
【０２１６】
図５３は、本実施の形態の画像復号方法を実現する画像復号装置３０００の構成を示すブロック図である。画像復号装置３０００は、ＰＩ情報取得ユニットＰＩｓｅｌを備える点において従来の画像復号装置３と異なる。
【０２１７】
ユーザ操作などにより特殊再生を指示する信号ＴｒｉｃｋＭｏｄｅがＰＩ情報取得ユニットＰＩｓｅｌに入力されると、ＰＩ情報取得ユニットＰＩｓｅｌは、可変長復号ユニットＶＬＤからＲＡＵマップの情報ＭａｐＩｎｆを取得する。ここで、可変長復号ユニットＶＬＤは、符号化ストリームを解析してＲＡＵマップを取得し、ＰＩ情報取得ユニットＰＩｓｅｌに入力する。さらに、ＰＩ情報取得ユニットＰＩｓｅｌは、ＲＡＵマップの情報ＭａｐＩｎｆを解析して、復号を開始するピクチャを決定し、決定した復号開始ピクチャを示す情報ＳｅｌＰｉｃをストリーム抽出ユニットＥＸＴに入力する。
【０２１８】
（実施の形態８）
さらに、上記各実施の形態で示した画像符号化方法および画像復号方法を実現するためのプログラムを、フレキシブルディスク等の記録媒体に記録するようにすることにより、上記各実施の形態で示した処理を、独立したコンピュータシステムにおいて簡単に実施することが可能となる。
【０２１９】
図４２は、上記各実施の形態の画像符号化方法および画像復号方法を、フレキシブルディスク等の記録媒体に記録されたプログラムを用いて、コンピュータシステムにより実施する場合の説明図である。
【０２２０】
図４２（ｂ）は、フレキシブルディスクの正面からみた外観、断面構造、及びフレキシブルディスクを示し、図４２（ａ）は、記録媒体本体であるフレキシブルディスクの物理フォーマットの例を示している。フレキシブルディスクＦＤはケースＦ内に内蔵され、該ディスクの表面には、同心円状に外周からは内周に向かって複数のトラックＴｒが形成され、各トラックは角度方向に１６のセクタＳｅに分割されている。従って、上記プログラムを格納したフレキシブルディスクでは、上記フレキシブルディスクＦＤ上に割り当てられた領域に、上記プログラムが記録されている。
【０２２１】
また、図４２（ｃ）は、フレキシブルディスクＦＤに上記プログラムの記録再生を行うための構成を示す。画像符号化方法および画像復号方法を実現する上記プログラムをフレキシブルディスクＦＤに記録する場合は、コンピュータシステムＣｓから上記プログラムをフレキシブルディスクドライブを介して書き込む。また、フレキシブルディスク内のプログラムにより画像符号化方法および画像復号方法を実現する上記画像符号化方法および画像復号方法をコンピュータシステム中に構築する場合は、フレキシブルディスクドライブによりプログラムをフレキシブルディスクから読み出し、コンピュータシステムに転送する。
【０２２２】
なお、上記説明では、記録媒体としてフレキシブルディスクを用いて説明を行ったが、光ディスクを用いても同様に行うことができる。また、記録媒体はこれに限らず、ＩＣカード、ＲＯＭカセット等、プログラムを記録できるものであれば同様に実施することができる。
【産業上の利用可能性】
【０２２３】
本発明に係る画像符号化方法および画像復号方法は、ＶＣ−１のストリームを再生する際に、高速や逆再生などの特殊再生機能を備える機器全般に適用することができ、特殊再生機能が重視される光ディスク関連機器において特に有効である。
【図面の簡単な説明】
【０２２４】
【図１】ＨＤ−ＤＶＤのデータ階層図
【図２】ＨＤ−ＤＶＤ上の論理空間の構成図
【図３】ＨＤ−ＤＶＤプレーヤの概要ブロック図
【図４】ＨＤ−ＤＶＤプレーヤの構成ブロック図
【図５】ＨＤ−ＤＶＤのアプリケーション空間の説明図
【図６】ＭＰＥＧストリーム（ＶＯＢ）の構成図
【図７】パックの構成図
【図８】ＡＶストリームとプレーヤ構成の関係を説明する図
【図９】トラックバッファへのＡＶデータ連続供給モデル図
【図１０】ＶＯＢ情報ファイル構成図
【図１１】タイムマップの説明図
【図１２】プレイリストファイルの構成図
【図１３】プレイリストに対応するプログラムファイルの構成図
【図１４】ＢＤディスク全体管理情報ファイルの構成図
【図１５】グローバルイベントハンドラを記録するファイルの構成図
【図１６】タイムイベントの例を説明する図
【図１７】ユーザイベントの例を説明する図
【図１８】グローバルイベントハンドラの例を説明する図
【図１９】仮想マシンの構成図
【図２０】プレーヤ変数テーブルの図
【図２１】イベントハンドラ（タイムイベント）の例を示す図
【図２２】イベントハンドラ（ユーザイベント）の例を示す図
【図２３】プレーヤの基本処理のフローチャート
【図２４】プレイリスト再生処理のフローチャート
【図２５】イベント処理のフローチャート
【図２６】字幕処理のフローチャート
【図２７】ＲＡＵ先頭のＰ／Ｉピクチャを説明する図
【図２８】Ｐ／Ｉピクチャにおける第１の特殊再生例を説明する図
【図２９】Ｐ／Ｉピクチャを特殊再生に使用する際の課題を説明する図
【図３０】タイムマップとＰ／Ｉピクチャの関係図
【図３１】ピクチャタイプ属性を持つタイムマップとＰ／Ｉピクチャの関係図
【図３２】第２フィールドのＩピクチャを参照するＰ／Ｉピクチャの説明図
【図３３】Ｐ／Ｉピクチャにおける第２の特殊再生例を説明する図
【図３４】本発明の実施の形態１のストリーム構造を示す図
【図３５】従来の画像符号化装置の構成を示すブロック図
【図３６】従来の画像復号装置の構成を示すブロック図
【図３７】従来の画像復号装置の動作を示すフローチャート
【図３８】本発明の実施の形態３の画像符号化方法の動作を示すフローチャート
【図３９】本発明の実施の形態３の画像符号化装置の構成を示すブロック図
【図４０】本発明の実施の形態４の画像復号方法の動作を示すフローチャート
【図４１】本発明の実施の形態４の画像復号装置の構成を示すブロック図
【図４２】本発明の画像符号化方法および画像復号方法を実現するためのプログラムを記録した記録媒体
【図４３】従来のデータ構造において、ランダムアクセス単位の途中から再生を開始する場合の課題を示す図
【図４４】従来のデータ構造において、シーンチェンジが発生した場合の課題を示す図
【図４５】本実施の形態５のランダムアクセス単位の第１の構成例を示す図
【図４６】本実施の形態５のランダムアクセス単位の第２の構成例を示す図
【図４７】本実施の形態５において、ランダムアクセス単位の先頭に付加される第１の補助情報について説明する図
【図４８】本実施の形態５において、ランダムアクセス単位の先頭に付加される第２の補助情報について説明する図
【図４９】本実施の形態６の画像符号化方法において、ピクチャの参照関係を制約する際の動作を示すフローチャート
【図５０】本実施の形態６の画像符号化方法の動作を示すフローチャート
【図５１】本実施の形態６の画像符号化装置の構成を示すブロック図
【図５２】本実施の形態７の画像復号方法の動作を示すフローチャート
【図５３】本実施の形態７の画像復号装置の構成を示すブロック図
【図５４】ＲＡＵマップのシンタックス例を示す図
【符号の説明】
【０２２５】
ＬＩＭＩＴ タイプ制限ユニット
ＰＴＹＰＥ 予測構造決定ユニット
ＶＬＣ 可変長符号化ユニット
ＰｉｃＭｅｍ ピクチャメモリ
【技術分野】
【０００１】
本発明は、シームレス接続やマルチアングル再生などの特殊再生時に有効な補助情報を符号化する画像符号化方法と画像復号方法、およびそのストリームに関する。
【背景技術】
【０００２】
近年、音声，画像，その他の画素値を統合的に扱うマルチメディア時代を迎え、従来からの情報メディア，つまり新聞，雑誌，テレビ，ラジオ，電話等の情報を人に伝達する手段がマルチメディアの対象として取り上げられるようになってきた。一般に、マルチメディアとは、文字だけでなく、図形、音声、特に画像等を同時に関連づけて表すことをいうが、上記従来の情報メディアをマルチメディアの対象とするには、その情報をディジタル形式にして表すことが必須条件となる。
【０００３】
ところが、上記各情報メディアの持つ情報量をディジタル情報量として見積もってみると、文字の場合１文字当たりの情報量は１〜２バイトであるのに対し、音声の場合１秒当たり６４Ｋｂｉｔｓ（電話品質）、さらに動画については１秒当たり１００Ｍｂｉｔｓ（現行テレビ受信品質）以上の情報量が必要となり、上記情報メディアでその膨大な情報をディジタル形式でそのまま扱うことは現実的では無い。例えば、テレビ電話は、６４Ｋｂｉｔ／ｓ〜１．５Ｍｂｉｔｓ／ｓの伝送速度を持つサービス総合ディジタル網（ＩＳＤＮ ： Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）によってすでに実用化されているが、テレビ・カメラの映像をそのままＩＳＤＮで送ることは不可能である。
【０００４】
そこで、必要となってくるのが情報の圧縮技術であり、例えば、テレビ電話の場合、ＩＴＵ−Ｔ（国際電気通信連合 電気通信標準化部門）で勧告されたＨ．２６１やＨ．２６３規格の動画圧縮技術が用いられている。また、ＭＰＥＧ−１規格の情報圧縮技術によると、通常の音楽用ＣＤ（コンパクト・ディスク）に音声情報とともに画像情報を入れることも可能となる。
【０００５】
ここで、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）とは、ＩＳＯ／ＩＥＣ（国際標準化機構 国際電気標準会議）で標準化された動画像信号圧縮の国際規格であり、ＭＰＥＧ−１は、動画像信号を１．５Ｍｂｐｓまで、つまりテレビ信号の情報を約１００分の１にまで圧縮する規格である。また、ＭＰＥＧ−１規格では対象とする品質を伝送速度が主として約１．５Ｍｂｐｓで実現できる程度の中程度の品質としたことから、さらなる高画質化の要求をみたすべく規格化されたＭＰＥＧ−２では、動画像信号を２〜１５ＭｂｐｓでＴＶ放送品質を実現する。さらに現状では、ＭＰＥＧ−１，ＭＰＥＧ−２と標準化を進めてきた作業グループ（ＩＳＯ／ＩＥＣ ＪＴＣ１／ＳＣ２９／ＷＧ１１）によって、ＭＰＥＧ−１，ＭＰＥＧ−２を上回る圧縮率を達成し、更に物体単位で符号化・復号・操作を可能とし、マルチメディア時代に必要な新しい機能を実現するＭＰＥＧ−４が規格化された。ＭＰＥＧ−４では、当初、低ビットレートの符号化方法の標準化を目指して進められたが、現在はインタレース画像も含む高ビットレートも含む、より汎用的な符号化に拡張されている。その後、ＩＳＯ／ＩＥＣとＩＴＵ−Ｔが共同でより高圧縮率の次世代画像符号化方式として、ＭＰＥＧ−４ ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）がされ、さらに、現在ＳＭＰＴＥ（Ｓｏｃｉｅｔｙ ｏｆ Ｍｏｔｉｏｎ Ｐｉｃｔｕｒｅ ａｎｄ Ｔｅｌｅｖｉｓｉｏｎ Ｅｎｇｉｎｅｅｒｓ）においてＶＣ−１（非特許文献１）が規格化中である。ＶＣ−１では、ＭＰＥＧ−２、およびＭＰＥＧ−４の方式をベースとして、符号化ツール等の拡張を行っている。このうちＶＣ−１は、ＢＤ（Ｂｌｕ−ｒａｙ ｄｉｓｃ）、ＨＤ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ）−ＤＶＤなど次世代の光ディスク関連機器などで使用される見込みである。
【０００６】
一般に動画像の符号化では、時間方向および空間方向の冗長性を削減することによって情報量の圧縮を行う。そこで時間的な冗長性の削減を目的とする画面間予測符号化では、前方または後方のピクチャを参照してブロック単位で動きの検出および予測画像の作成を行い、得られた予測画像と符号化対象ピクチャとの差分値に対して符号化を行う。ここで、ピクチャとは１枚の画面を表す用語であり、プログレッシブ画像ではフレームを意味し、インタレース画像ではフレームもしくはフィールドを意味する。ここで、インタレース画像とは、１つのフレームが時刻の異なる２つのフィールドから構成される画像である。インタレース画像の符号化や復号処理においては、１つのフレームをフレームのまま処理したり、２つのフィールドとして処理したり、フレーム内のブロック毎にフレーム構造またはフィールド構造として処理したりすることができる。
【０００７】
参照画像を持たず画面内予測符号化を行うものをＩピクチャと呼ぶ。また、１枚のピクチャのみを参照し画面間予測符号化を行うものをＰピクチャと呼ぶ。また、同時に２枚のピクチャを参照して画面間予測符号化を行うことのできるものをＢピクチャと呼ぶ。Ｂピクチャは表示時間が前方もしくは後方から任意の組み合わせとして２枚のピクチャを参照することが可能である。ただし、これらのピクチャを符号化および復号する場合の条件として、参照するピクチャが既に符号化および復号されている必要がある。
【０００８】
次に、ＶＣ−１のストリーム構造について説明する。ＶＣ−１も基本的にはＭＰＥＧ−２と同一のストリーム構造をもつ。ただし、ランダムアクセスポイントは、エントリ・ポイント（Ｅｎｔｒｙ Ｐｏｉｎｔ）と呼ばれ、エントリ・ポイントにはヘッダ（Ｅｎｔｒｙ Ｐｏｉｎｔ Ｈｅａｄｅｒ）が付加される。エントリ・ポイントから次のエントリ・ポイントまでのデータがランダムアクセス単位となり、ＭＰＥＧ−２におけるＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅｓ）に相当する。以降、ＶＣ−１におけるランダムアクセス単位をＲＡＵ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｐｏｉｎｔ）と呼ぶ。ここで、ＲＡＵには、ＲＡＵを構成するピクチャについてのユーザーデータ（エントリ・ポイントレベルのユーザーデータ）を格納することができ、エントリ・ポイント・ヘッダの直後に格納される。
【０００９】
ＶＣ−１におけるピクチャのタイプについて以下に示す。まず、Ｉ、Ｐ、ＢピクチャについてはＭＰＥＧ−２と同等の予測構造をもつが、これら３種類のピクチャに加えて、Ｓｋｉｐｐｅｄピクチャ、およびＢＩピクチャの２種類が定義される。Ｓｋｉｐｐｅｄピクチャとは、画素データを含まないピクチャであり、復号順で直前の参照ピクチャと同一の画素データを持つＰピクチャとして扱う。例えば、下記の例では、Ｓ６がＰ４と同一であるとみなされるため、ストリームの復号時の動作は（１）と（２）で同一となる。
【００１０】
（１）表示順： Ｉ０ Ｂ１ Ｐ２ Ｂ３ Ｐ４ Ｂ５ Ｓ６ （ＳはＳｋｉｐｐｅｄピクチャを示す）
（２）表示順： Ｉ０ Ｂ１ Ｐ２ Ｂ３ Ｐ４ Ｂ５ Ｐ４
Ｓｋｉｐｐｅｄピクチャは、画像が静止しているケースにおいて特に有効である。例えば、ＲＡＵの途中から画像が静止する際には、Ｉ０ Ｐ１ Ｐ２ Ｐ３ Ｓ４ Ｓ５ Ｓ６．．のように、画像が静止している部分についてはＳｋｉｐｐｅｄピクチャを使用することで、符号量が削減できる。また、ＢＩピクチャとは、ＢピクチャとＩピクチャの性質を併せ持つピクチャである。具体的には、復号と表示の順序は異なり、他のピクチャからは参照されないという点でＢピクチャの性質をもち、全てのマクロブロックが画面内符号化されており、他のピクチャを参照しないという点でＩピクチャの性質をもつ。
【００１１】
次に、Ｉ、Ｐ、Ｂ、Ｓｋｉｐｐｅｄ、およびＢＩピクチャの判別方法を説明する。基本的にはピクチャレイヤのピクチャタイプを参照することによりピクチャのタイプが判別できるが、ピクチャレイヤにより示すことのできるピクチャタイプはプロファイルに応じて下記のように規定される。
【００１２】
シンプル・プロファイル： Ｉ、Ｐ
メイン・プロファイル： Ｉ、Ｐ、Ｂ、ＢＩ
アドバンスト・プロファイル： Ｉ、Ｐ、Ｂ、ＢＩ、Ｓｋｉｐｐｅｄ
【００１３】
ここで、シンプル、メインの両プロファイルではピクチャレイヤのピクチャタイプにからはＳｋｉｐｐｅｄピクチャを判別できないため、任意のピクチャタイプをもつピクチャのサイズが１バイト以下である際に、当該ピクチャがＳｋｉｐｐｅｄピクチャであると規定されている。また、メイン・プロファイルでは、ＢまたはＢＩピクチャを示すピクチャタイプが定義されており、ピクチャタイプからＢピクチャとＢＩピクチャとを区別することはできない。
【００１４】
ＶＣ−１のＲＡＵにおいても、ＭＰＥＧ−２と同様にオープンＧＯＰ型とクローズドＧＯＰ型とがある。クローズドＧＯＰ型とは、ＲＡＵ内のＢピクチャが復号順で直前のＲＡＵ内のＩピクチャあるいはＰピクチャを参照しないタイプである。一方、オープンＧＯＰ型は、ＲＡＵ内のＢピクチャが復号順で直前のＲＡＵ内のＩピクチャあるいはＰピクチャを参照してもよいタイプである。なお、オープン型、クローズド型ともに、ＲＡＵ内のＩピクチャとＰピクチャは、復号順で直前のＲＡＵ内のＩピクチャとＰピクチャを参照できない。
【００１５】
次に、フィールド符号化時に１フレームを構成するフィールドのタイプについて説明する。ＶＣ−１では、アドバンスト・プロファイルだけがフィールド符号化に対応しており、フィールド符号化時の第１フィールドと第２フィールドのピクチャタイプは、ピクチャレイヤにおけるフィールド・ピクチャタイプにより示される。フィールド・ピクチャタイプは、（第１フィールドのピクチャタイプ、第２フィールドのピクチャタイプ）として、（Ｉ、Ｉ）、（Ｉ、Ｐ）、（Ｐ、Ｉ）、（Ｐ、Ｐ）、（Ｂ、Ｂ）、（Ｂ、ＢＩ）、（ＢＩ、Ｂ）、（ＢＩ、ＢＩ）の８通りが定義されている。以降、これらのピクチャを、それぞれＩ／Ｉピクチャ、Ｉ／Ｉピクチャ、Ｉ／Ｐピクチャ、Ｐ／Ｉピクチャ、Ｐ／Ｐピクチャ、Ｂ／Ｂピクチャ、Ｂ／ＢＩピクチャ、ＢＩ／Ｉピクチャ、ＢＩ／ＢＩピクチャと呼ぶ。ここで、１フレームを構成する２つのフィールドは、フィールド・ペアと呼ばる。Ｉ／Ｐピクチャなど上記８通りのピクチャは、ピクチャと表記するが、全てフィールド・ペアである。なお、ＭＰＥＧ−２においては、Ｐ／Ｉピクチャ、Ｂ／ＢＩピクチャ、ＢＩ／Ｉピクチャ、およびＢＩ／ＢＩピクチャは存在しない。
【００１６】
図３５は、従来の画像符号化方法を実現する画像符号化装置１のブロック図である。
画像符号化装置１は、入力される画像信号Ｖｉｎ を圧縮符号化して可変長符号化等のビットストリームに変換した画像符号化信号Ｓｔｒ を出力する装置であり、動き検出ユニットＭＥ、動き補償ユニットＭＣ、減算ユニットＳｕｂ、直交変換ユニットＴ、量子化ユニットＱ、逆量子化ユニットＩＱ、逆直交変換ユニットＩＴ、加算ユニットＡｄｄ、ピクチャメモリＰｉｃＭｅｍ、スイッチＳＷ、および可変長符号化ユニットＶＬＣを備えている。
【００１７】
画像信号Ｖｉｎ は、減算ユニットＳｕｂおよび動き検出ユニットＭＥに入力される。減算ユニットＳｕｂは、入力された画像信号Ｖｉｎ と予測画像の差分値を計算し、直交変換ユニットＴに出力する。直交変換ユニットＴは、差分値を周波数係数に変換し、量子化ユニットＱに出力する。量子化ユニットＱは、入力された周波数係数を量子化し、量子化値Ｑｃｏｅｆを可変長符号化ユニットに出力する。
【００１８】
逆量子化ユニットＩＱは、量子化値Ｑｃｏｅｆを逆量子化して周波数係数に復元し、逆直交変換ユニットＩＴに出力する。逆直交変換ユニットＩＴは、周波数係数から画素差分値に逆周波数変換し、加算ユニットＡｄｄに出力する。加算ユニットＡｄｄは、画素差分値と動き補償ユニットＭＣから出力される予測画像とを加算して復号画像とする。スイッチＳＷは、当該復号画像の保存が指示された場合にＯＮになり、復号画像はピクチャメモリＰｉｃＭｅｍに保存される。
【００１９】
一方、画像信号Ｖｉｎ がマクロブロック単位で入力された動き検出ユニットＭＥは、ピクチャメモリＰｉｃＭｅｍに格納されている復号画像を探索対象とし、最も入力画像信号に近い画像領域を検出することによってその位置を指し示す動きベクトルＭＶを決定する。
【００２０】
動き補償ユニットＭＣでは、上記処理によって検出された動きベクトルなどを用いて、ピクチャメモリＰｉｃＭｅｍに格納されている復号画像から予測画像に最適な画像領域を取り出す。
【００２１】
ピクチャ予測構造決定ユニットＰＴＹＰＥはＲＡＵ開始ピクチャＲＡＵｉｎによって対象ピクチャがＲＡＵの開始位置であれば、対象ピクチャをランダムアクセスが可能な特別なピクチャとして符号化（画面内符号化）するように、ピクチャタイプＰｔｙｐｅで動き検出ユニットＭＥおよび動き補償ユニットＭＣに指示し、更にそのピクチャタイプＰｔｙｐｅを可変長符号化ユニットＶＬＣで符号化する。ここで、先頭ピクチャをフィールドとして符号化する際のピクチャタイプとしては、Ｉ／Ｉ、Ｉ／Ｐ、およびＰ／Ｉピクチャを自由に選択できる。
【００２２】
可変長符号化ユニットＶＬＣは量子化値Ｑｃｏｅｆ、ピクチャタイプＰｔｙｐｅおよび動きベクトルＭＶなどを可変長符号化して符号化ストリームＳｔｒとする。
【００２３】
図３６は、従来の画像復号方法を実現する画像復号装置３のブロック図である。同図において、図３５の画像符号化装置１のブロック図と同じ動作をするユニットは同じ記号を付し、説明を省略する。可変長復号ユニットＶＬＤは符号化ストリームＳｔｒを復号し、量子化値Ｑｃｏｅｆ、相対インデックスＩｎｄｅｘ、ピクチャタイプＰｔｙｐｅおよび動きベクトルＭＶを出力する。量子化値Ｑｃｏｅｆ、相対インデックスＩｎｄｅｘおよび動きベクトルＭＶは、ピクチャメモリＰｉｃＭｅｍ、動き補償ユニットＭＣおよび逆量子化ユニットＩＱに入力され復号処理が行われるが、その動作は図１４の従来の画像符号化方法を実現する画像符号化装置のブロック図で説明済みである。バッファメモリＢｕｆＭｅｍは、復号画像Ｖｏｕｔを格納するメモリである。表示方法切替ユニットＭｏｄｅＳｅｔは、次に表示するピクチャがＲＡＵの先頭ピクチャである際には、ピクチャタイプを取得するために必要なデータＰｉｎｆをバッファメモリＢｕｆＭｅｍに格納された復号画像データから取得する。さらに、当該ピクチャがＰ／Ｉピクチャである際には、第１フィールドと第２フィールドにおいて同一の画像を表示する旨を表示命令ｍｏｄｅによって表示ユニットＤｉｓｐに通知する。Ｐ／Ｉピクチャでなければ、第１フィールドと第２フィールドは、１フレームを構成するフィールド・ペアにおける第１フィールドと第２フィールドを、それぞれ表示するように表示ユニットＤｉｓｐに指示する。表示ユニットＤｉｓｐは、バッファメモリＢｕｆＭｅｍから復号画像Ｄｉｎを取得し、表示命令ｍｏｄｅに従って表示する。なお、ピクチャメモリＰｉｃＭｅｍとバッファメモリＢｕｆＭｅｍは共用してもよい。
【００２４】
図３７は、従来の画像復号装置３において、マルチアングル再生や、同一ストリーム内の異なる区間を連続して再生するなどの特殊再生時の表示動作を示すフローチャートである。まず、ステップＳ１００１において表示対象のピクチャがＲＡＵの先頭ピクチャであるかどうか判定する。先頭ピクチャであれば、ステップＳ１００２に進み、先頭ピクチャでなければステップＳ１００５に進む。ステップＳ１００２では、ピクチャのピクチャタイプを取得して、ステップＳ１００３においてＰ／Ｉピクチャであったかどうか判定する。Ｐ／Ｉピクチャである際にはステップＳ１００４に進み、Ｐ／ＩピクチャでなければステップＳ１００５に進む。ステップＳ１００４では、第２フィールドを２回繰り返して表示すると決定する。つまり、Ｐ／Ｉピクチャにおいては、第１フィールドであるＰピクチャは復号できないため、第２フィールドであるＩピクチャをＰピクチャの代わりに表示することになる。ステップＳ１００５では、フィールド・ペアを構成する第１フィールドと第２フィールドを、それぞれ順番に表示すると決定する。
【特許文献１】特開２０００−２２８６５６号公報
【非特許文献１】Ｐｒｏｐｏｓｅｄ ＳＭＰＴＥ Ｓｔａｎｄａｒｄ ｆｏｒ Ｔｅｌｅｖｉｓｉｏｎ： ＶＣ−９ Ｃｏｍｐｒｅｓｓｅｄ Ｖｉｄｅｏ Ｂｉｔｓｔｒｅａｍ Ｆｏｒｍａｔ ａｎｄ Ｄｅｃｏｄｉｎｇ Ｐｒｏｃｅｓｓ， Ｃｏｍｍｉｔｔｅｅ Ｄｒａｆｔ １， ２００４．７．１９
【発明の開示】
【発明が解決しようとする課題】
【００２５】
ＲＡＵの先頭ピクチャがＰ／Ｉピクチャであると、飛び込み再生やマルチアングル再生などの特殊再生時に、Ｐ／Ｉピクチャの第１フィールドであるＰピクチャが再生できないという課題があった。また、ＲＡＵの先頭がＰ／Ｉピクチャである際には、第２フィールドを繰り返して表示するなどして、Ｐ／Ｉピクチャ以外のピクチャとは表示動作を切替える必要があり、表示に係る処理が増加するという課題もあった。以下に、特殊再生時の課題について説明する。
【００２６】
図２７が示すように、Ｐ／ＩピクチャをＲＡＵの先頭ピクチャとして用いることも可能である。ＲＡＵの先頭は特殊再生等における再生開始点として指定することができる位置であるが、Ｐ／Ｉピクチャを先頭ピクチャとして有しているＲＡＵから再生を開始する場合、第１フィールドであるＰピクチャは前方の他のピクチャを参照しているために復号することができない。そのため、第２フィールドであるＩピクチャからデコードを開始することになり、このＰ／Ｉピクチャであるフレームの画像を表示するときには、第２フィールドの画像のみからフレームを表示することになる。例えば、第２フィールドの画像を２回出力することにより、１フレームの画像を表示する。
【００２７】
さらに、図２８が示すように、ＲＡＵ先頭のピクチャのみ読み込む早送り再生のような特殊再生をする場合、同様にＰピクチャはデコードできないので、１フレームのうちの１フィールドしかデコードできず、解像度が半分に落ちてしまう欠点がある。
【００２８】
また、ＤＶＤやＢＤなどでは、プレイリストを用いて同一ストリームにおいて異なる時間位置のストリームを連続再生する、あるいは、マルチアングル再生時に異なるアングルを構成するストリームを連続して再生するなどの特殊再生が一般的に行われる。さらに、追記型、あるいは書き換え型のディスクにおいては、編集後のストリームをプレイリストによって仮想的に連結することもある。このとき、プレイリストでは、プレイアイテムと呼ばれる再生区間を連続して再生する。図２９は、プレイリストから指される第１プレイアイテムと第２プレイアイテムとを連続的に再生する例を示す。ここで、第２プレイアイテムの先頭ピクチャがＰ／Ｉピクチャであると、Ｐ／Ｉピクチャを構成するＰピクチャは復号できず、第１プレイアイテムから第２プレイアイテムへのシームレスな接続が実現できない。
【課題を解決するための手段】
【００２９】
本発明は、以上の課題を解決するためになされたものである。
本発明の請求項１にかかる情報記録媒体は、少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、前記動画像の符号化データは、１以上のランダムアクセス可能な単位から構成され、前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、前記符号化データにおいて前記フィールド・ペアが存在するかどうかを示す識別情報を格納することを特徴とする。
【００３０】
本発明の請求項２にかかる情報記録媒体は、前記ランダムアクセス単位には、ランダムアクセス単位内の双方向予測ピクチャが、復号順で直前のランダムアクセス単位内のピクチャを参照することを禁止した、クローズド型のランダムアクセス単位と、ランダムアクセス単位内の双方向予測ピクチャが、復号順で直前のランダムアクセス単位内のピクチャを参照することを許容した、オープン型のランダムアクセス単位と、の２種類があり、前記識別情報は、前記ランダムアクセス単位がクローズド型であるかどうかを示す情報であり、前記ランダムアクセス単位がクローズド型である際には、前記ランダムアクセス単位の先頭に前記フィールド・ペアが存在しないことを特徴とする請求項１記載の情報記録媒体である。
【００３１】
本発明の請求項３にかかる情報記録媒体は、前記識別情報は、前記符号化ストリームのビットレートが所定の値以下であるかどうかを示す情報であることを特徴とする請求項１記載の情報記録媒体である。
【００３２】
本発明の請求項４にかかる情報記録媒体は、前記動画像は再生時刻に応じて複数の再生区間に分割され、前記管理情報は、１以上の前記動画像における１以上の前記再生区間を連続して再生するための情報を格納し、前記識別情報は、前記管理情報に格納され、前記連続して再生される前記再生区間がシームレスに接続されるかどうかを示し、前記シームレスに接続されることが示される際には、接続先となる前記再生区間の先頭は前記フィールド・ペアでないことを特徴とする請求項１の情報記録媒体である。
【００３３】
本発明の請求項５にかかる情報記録媒体は、前記動画像は再生時刻に応じて複数の再生区間に分割され、前記管理情報は、１以上の前記動画像における１以上の前記再生区間を連続して再生するための情報を格納し、前記識別情報は、前記管理情報に格納され、前記連続して再生される区間が、それぞれ異なる動画像のストリームに属するかどうかを識別する情報であり、前記異なる動画ストリームに属することが示される際には、接続先となる前記再生区間の先頭は前記フィールド・ペアでないことを特徴とする。
【００３４】
本発明の請求項６にかかる画像符号化方法は、動画像を１以上のランダムアクセス単位に符号化する画像符号化方法であって、前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアであるかどうかを示す情報を作成する補助情報作成ステップと、前記作成した補助情報と画素を符号化して符号化ストリームを作成する符号化ステップと、を備えることを特徴とする。
【００３５】
本発明の請求項７にかかる画像符号化装置は、動画像を１以上のランダムアクセス単位に符号化する画像符号化装置であって、前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアであるかどうかを示す情報を作成する補助情報作成手段と、前記作成した補助情報と画素を符号化して符号化ストリームを作成する符号化手段と、を備えることを特徴とする。
【００３６】
本発明の請求項８にかかる画像復号方法は、請求項１の情報記録媒体に記録された符号化データを復号して再生する画像復号方法であって、前記識別情報により、前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアでないことが示される場合に、前記先頭ピクチャにおける第１フィールド、および第２フィールドを、それぞれ１番目と２番目に表示する表示ステップ、を備えることを特徴とする。
【００３７】
本発明の請求項９にかかる画像復号装置は、請求項１の情報記録媒体に記録された符号化データを復号して再生する画像復号装置であって、前記識別情報により、前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアでないことが示される場合に、前記先頭ピクチャにおける第１フィールド、および第２フィールドを、それぞれ１番目と２番目に表示する表示手段、を備えることを特徴とする。
【００３８】
本発明の請求項１０にかかる情報記録媒体は、少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、前記動画像の符号化データは、１以上のランダムアクセス可能な単位から構成され、前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、前記ランダムアクセス単位の先頭とは異なるピクチャが前記フィールド・ペアであるときには、前記ランダムアクセス単位内のピクチャであって、前記フィールド・ペアよりも表示順が後であるピクチャは、前記フィールド・ペアの第１フィールドを参照しないことが保証され、前記保証されることを示す情報を前記ストリーム内に格納することを特徴とする。
【００３９】
本発明の請求項１１にかかる情報記録媒体は、少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、前記動画像の符号化データは、１以上のランダムアクセス可能な単位から構成され、前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、前記ランダムアクセス単位の先頭とは異なるピクチャが前記フィールド・ペアであるときには、前記ランダムアクセス単位内のピクチャであって、前記フィールド・ペアよりも表示順が後であるピクチャは、前記フィールド・ペアの第１フィールドを参照する場合としない場合とがあり、前記フィールド・ペアよりも表示順が後であるピクチャが、前記フィールド・ペアの第１フィールドを参照するかどうかを示す情報を前記ストリーム内に格納することを特徴とする。
【００４０】
本発明の請求項１２にかかる情報記録媒体は、少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、前記動画像の符号化データは、１以上のピクチャをまとめたグループ化単位が複数連結されたデータであり、前記管理情報は、ランダムアクセスすることができる前記グループ化単位の一覧情報を格納し、前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、前記ストリームは、前記一覧情報から指されない前記グループ化単位の先頭ピクチャが前記フィールド・ペアであるかどうかを示す情報を格納することを特徴とする。
【発明の効果】
【００４１】
以上のように、本発明によれば、Ｐ／Ｉピクチャを使用する際に、ストリームおよび管理情報を制約することにより、特殊再生時の再生品質を向上させることができ、特殊再生機能が重視されるパッケージメディアにおいて、特にその実用的価値が高い。
【発明を実施するための最良の形態】
【００４２】
以下、本発明の実施の形態について、図面を参照しながら説明する。
【００４３】
（実施の形態１）
まず最初に本発明の第１の実施の形態について説明する。
【００４４】
（ディスク上の論理データ構造）
図１は、ＢＤ−ＲＯＭの構成、特にディスク媒体であるＢＤディスク（１０４）と、ディスクに記録されているデータ（１０１、１０２、１０３）の構成を示す図である。ＢＤディスク（１０４）に記録されるデータは、ＡＶデータ（１０３）と、ＡＶデータに関する管理情報およびＡＶ再生シーケンスなどのＢＤ管理情報（１０２）と、インタラクティブを実現するＢＤ再生プログラム（１０１）である。本実施の形態では、説明の都合上、映画のＡＶコンテンツを再生するためのＡＶアプリケーションを主眼においてのＢＤディスクの説明を行うが、他の用途として用いても勿論同様である。
【００４５】
図２は、上述したＢＤディスクに記録されている論理データのディレクトリ・ファイル構成を示した図である。ＢＤディスクは、他の光ディスク、例えばＤＶＤやＣＤなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリード・インと外周のリード・アウトの間に論理データを記録できる論理アドレス空間を有している。また、リード・インの内側にはＢＣＡ（Ｂｕｒｓｔ Ｃｕｔｔｉｎｇ Ａｒｅａ）と呼ばれるドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがある。
【００４６】
論理アドレス空間には、ファイルシステム情報（ボリューム）を先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは従来技術で説明した通り、ＵＤＦやＩＳＯ９６６０などのことであり、通常のＰＣと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。
【００４７】
本実施例の場合、ＢＤディスク上のディレクトリ、ファイル構造は、ルートディレクトリ（ＲＯＯＴ）直下にＢＤＶＩＤＥＯディレクトリが置かれている。このディレクトリはＢＤで扱うＡＶコンテンツや管理情報などのデータ（図１で説明した１０１、１０２、１０３）が格納されているディレクトリである。
【００４８】
ＢＤＶＩＤＥＯディレクトリの下には、次の７種類のファイルが記録されている。
【００４９】
ＢＤ．ＩＮＦＯ（ファイル名固定）
「ＢＤ管理情報」の一つであり、ＢＤディスク全体に関する情報を記録したファイルである。ＢＤプレーヤは最初にこのファイルを読み出す。
【００５０】
ＢＤ．ＰＲＯＧ（ファイル名固定）
「ＢＤ再生プログラム」の一つであり、ＢＤディスク全体に関わる再生制御情報を記録したファイルである。
【００５１】
ＸＸＸ．ＰＬ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ管理情報」の一つであり、シナリオ（再生シーケンス）であるプレイリスト情報を記録したファイルである。プレイリスト毎に１つのファイルを持っている。
【００５２】
ＸＸＸ．ＰＲＯＧ（「ＸＸＸ」は可変、拡張子「ＰＬ」は固定）
「ＢＤ再生プログラム」の一つであり、前述したプレイリスト毎の再生制御情報を記録したファイルである。プレイリストとの対応はファイルボディ名（「ＸＸＸ」が一致する）によって識別される。
【００５３】
ＹＹＹ．ＶＯＢ（「ＹＹＹ」は可変、拡張子「ＶＯＢ」は固定）
「ＡＶデータ」の一つであり、ＶＯＢ（従来例で説明したＶＯＢと同じ）を記録したファイルである。ＶＯＢ毎に１つのファイルを持っている。
【００５４】
ＹＹＹ．ＶＯＢＩ（「ＹＹＹ」は可変、拡張子「ＶＯＢＩ」は固定）
「ＢＤ管理情報」の一つであり、ＡＶデータであるＶＯＢに関わるストリーム管理情報を記録したファイルである。ＶＯＢとの対応はファイルボディ名（「ＹＹＹ」が一致する）によって識別される。
【００５５】
ＺＺＺ．ＰＮＧ（「ＺＺＺ」は可変、拡張子「ＰＮＧ」は固定）
「ＡＶデータ」の一つであり、字幕およびメニューを構成するためのイメージデータＰＮＧ（Ｗ３Ｃによって標準化された画像フォーマットであり「ピング」と読む）を記録したファイルである。１つのＰＮＧイメージ毎に１つのファイルを持つ。
【００５６】
（プレーヤの構成）
次に、前述したＢＤディスクを再生するプレーヤの構成について図６および図７を用いて説明する。
【００５７】
図３は、プレーヤの大まかな機能構成を示すブロック図である。
ＢＤディスク（２０１）上のデータは、光ピックアップ（２０２）を通して読み出される。読み出されたデータは夫々のデータの種類に応じて専用のメモリに転送される。ＢＤ再生プログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」ファイルの中身）はプログラム記録メモリ（２０３）に、ＢＤ管理情報（「ＢＤ．ＩＮＦＯ」、「ＸＸＸ．ＰＬ」または「ＹＹＹ．ＶＯＢＩ」）は管理情報記録メモリ（２０４）に、ＡＶデータ（「ＹＹＹ．ＶＯＢ」または「ＺＺＺ．ＰＮＧ」）はＡＶ記録メモリ（２０５）に夫々転送される。
【００５８】
プログラム記録メモリ（２０３）に記録されたＢＤ再生プログラムはプログラム処理部（２０６）によって、管理情報記録メモリ（２０４）に記録されたＢＤ管理情報は管理情報処理部（２０７）によって、また、ＡＶ記録メモリ（２０５）に記録されたＡＶデータはプレゼンテーション処理部（２０８）によって夫々処理される。
【００５９】
プログラム処理部（２０６）は、管理情報処理部（２０７）より再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムでは再生するプレイリストを動的に変える事が可能であり、この場合は管理情報処理部（２０７）に対してプレイリストの再生命令を送ることで実現する。プログラム処理部（２０６）は、ユーザからのイベント、即ちリモコンキーからのリクエストを受け、ユーザイベントに対応するプログラムがある場合は、それを実行する。
【００６０】
管理情報処理部（２０７）は、プログラム処理部（２０６）の指示を受け、対応するプレイリストおよびプレイリストに対応したＶＯＢの管理情報を解析し、プレゼンテーション処理部（２０８）に対象となるＡＶデータの再生を指示する。また、管理情報処理部（２０７）は、プレゼンテーション処理部（２０８）より基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部（２０８）にＡＶデータ再生の停止指示を行い、また、プログラム処理部（２０６）に対してプログラム実行タイミングを示すイベントを生成する。
【００６１】
プレゼンテーション処理部（２０８）は、映像、音声、字幕／イメージ（静止画）の夫々に対応するデコーダを持ち、管理情報処理部（２０７）からの指示に従い、ＡＶデータのデコードおよび出力を行う。映像データ、字幕／イメージの場合は、デコード後に夫々の専用プレーン、ビデオプレーン（２１０）およびイメージプレーン（２０９）に描画され、合成処理部（２１１）によって映像の合成処理が行われＴＶなどの表示デバイスへ出力される。
【００６２】
このように図３に示すように、ＢＤプレーヤは図１で示したＢＤディスクに記録されているデータ構成に基づいた機器構成をとっている。
【００６３】
図４は前述したプレーヤ構成を詳細化したブロック図である。図７では、ＡＶ記録メモリ（２０５）はイメージメモリ（３０８）とトラックバッファ（３０９）に、プログラム処理部（２０６）はプログラムプロセッサ（３０２）とＵＯＰマネージャ（３０３）に、管理情報処理部（２０７）はシナリオプロセッサ（３０５）とプレゼンテーションコントローラ（３０６）に、プレゼンテーション処理部（２０８）はクロック（３０７）、デマルチプレクサ（３１０）、イメージプロセッサ（３１１）、ビデオプロセッサ（３１２）とサウンドプロセッサ（３１３）に夫々対応／展開している。
【００６４】
ＢＤディスク（２０１）から読み出されたＶＯＢデータ（ＭＰＥＧストリーム）はトラックバッファ（３０９）に、イメージデータ（ＰＮＧ）はイメージメモリ（３０８）に夫々記録される。デマルチプレクサ（３１０）がクロック（３０７）の時刻に基づき、トラックバッファ（３０９）に記録されたＶＯＢデータを抜き出し、映像データをビデオプロセッサ（３１２）に音声データをサウンドプロセッサ（３１３）に夫々送り込む。ビデオプロセッサ（３１２）およびサウンドプロセッサ（３１３）は夫々ＭＰＥＧシステム規格で定める通りに、デコーダバッファとデコーダから夫々構成されている。即ち、デマルチプレクサ（３１０）から送りこまれる映像、音声夫々のデータは、夫々のデコーダバッファに一時的に記録され、クロック（３０７）に従い個々のデコーダでデコード処理される。
【００６５】
イメージメモリ（３０８）に記録されたＰＮＧは、次の２つの処理方法がある。
イメージデータが字幕用の場合は、プレゼンテーションコントローラ（３０６）によってデコードタイミングが指示される。クロック（３０７）からの時刻情報をシナリオプロセッサ（３０５）が一旦受け、適切な字幕表示が行えるように、字幕表示時刻（開始および終了）になればプレゼンテーションコントローラ（３０６）に対して字幕の表示、非表示の指示を出す。プレゼンテーションコントローラ（３０６）からデコード／表示の指示を受けたイメージプロセッサ（３１１）は対応するＰＮＧデータをイメージメモリ（３０８）から抜き出し、デコードし、イメージプレーン（３１４）に描画する。
【００６６】
次に、イメージデータがメニュー用の場合は、プログラムプロセッサ（３０２）によってデコードタイミングが指示される。プログラムプロセッサ（３０２）が何時イメージのデコードを指示するかは、プログラムプロセッサ（３０２）が処理しているＢＤプログラムに因るものであって一概には決まらない。
【００６７】
イメージデータおよび映像データは、図６で説明したように夫々デコード後にイメージプレーン（３１４）、ビデオプレーン（３１５）に出力され、合成処理部（３１６）によって合成後出力される。
【００６８】
ＢＤディスク（２０１）から読み出された管理情報（シナリオ、ＡＶ管理情報）は、管理情報記録メモリ（３０４）に格納されるが、シナリオ情報（「ＢＤ．ＩＮＦＯ」および「ＸＸＸ．ＰＬ」）はシナリオプロセッサ（３０５）へ読み込み処理される。また、ＡＶ管理情報（「ＹＹＹ．ＶＯＢＩ」）はプレゼンテーションコントローラ（３０６）によって読み出され処理される。
【００６９】
シナリオプロセッサ（３０５）は、プレイリストの情報を解析し、プレイリストによって参照されているＶＯＢとその再生位置をプレゼンテーションコントローラ（３０６）に指示し、プレゼンテーションコントローラ（３０６）は対象となるＶＯＢの管理情報（「ＹＹＹ．ＶＯＢＩ」）を解析して、対象となるＶＯＢを読み出すようにドライブコントローラ（３１７）に指示を出す。
【００７０】
ドライブコントローラ（３１７）はプレゼンテーションコントローラ（３０６）の指示に従い、光ピックアップを移動させ、対象となるＡＶデータの読み出しを行う。読み出されたＡＶデータは、前述したようにイメージメモリ（３０８）またはトラックバッファ（３０９）に読み出される。
【００７１】
また、シナリオプロセッサ（３０５）は、クロック（３０７）の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ（３０２）に投げる。
【００７２】
プログラム記録メモリ（３０１）に記録されたＢＤプログラム（「ＢＤ．ＰＲＯＧ」または「ＸＸＸ．ＰＲＯＧ」）は、プログラムプロセッサ３０２によって実行処理される。プログラムプロセッサ（３０２）がＢＤプログラムを処理するのは、シナリオプロセッサ（３０５）からイベントが送られてきた場合か、ＵＯＰマネージャ（３０３）からイベントが送られてきた場合である。ＵＯＰマネージャ（３０３）は、ユーザからリモコンキーによってリクエストが送られてきた場合に、プログラムプロセッサ（３０２）に対するイベントを生成する。
【００７３】
（アプリケーション空間）
図５は、ＢＤのアプリケーション空間を示す図である。
【００７４】
ＢＤのアプリケーション空間では、プレイリスト（ＰｌａｙＬｉｓｔ）が一つの再生単位になっている。プレイリストはセル（Ｃｅｌｌ）の連結で、連結の順序により決定される再生シーケンスである静的なシナリオと、プログラムによって記述される動的なシナリオを有している。プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。一方で、プログラムは、プレイリストを超えての再生記述や、ユーザ選択またはプレーヤの状態によって再生する対象を動的に変えることが可能である。典型的な例としてはメニューがあげられる。ＢＤの場合、メニューとはユーザの選択によって再生するシナリオと定義でき、プログラムによってプレイリストを動的に選択することである。
【００７５】
ここで言うプログラムとは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。
【００７６】
時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図４で説明したシナリオプロセッサ（３０５）からプログラムプロセッサ（３０２）に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ（３０２）はＩＤによって対応付けられるイベントハンドラを実行処理する。前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。
【００７７】
ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく２つのタイプに分けられる。一つ目は、カーソルキー（「上」「下」「左」「右」キー）または「決定」キーの操作によって生成されるメニュー選択のイベントである。メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効であり（プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている）、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。
【００７８】
二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー呼び出しのイベントである。メニュー呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、ＤＶＤのメニューコール（タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点からのタイトル再生を実行する機能等）を実装することができる。
【００７９】
プレイリストで静的シナリオを構成する単位であるセル（Ｃｅｌｌ）はＶＯＢ（ＭＰＥＧストリーム）の全部または一部の再生区間を参照したものである。セルはＶＯＢ内の再生区間を開始、終了時刻の情報として持っている。個々のＶＯＢと一対になっているＶＯＢ管理情報（ＶＯＢＩ）は、その内部にデータの再生時刻に対応した記録アドレスのテーブル情報であるタイムマップ（Ｔｉｍｅ ＭａｐまたはＴＭＡＰ）を有しており、このタイムマップによって前述したＶＯＢの再生、終了時刻をＶＯＢ内（即ち対象となるファイル「ＹＹＹ．ＶＯＢ」内）での読み出し開始アドレスおよび終了アドレスを導き出すことが可能である。なおタイムマップの詳細は後述する。
【００８０】
（ＶＯＢの詳細）
図６は、本実施例で使用するＭＰＥＧストリーム（ＶＯＢ）の構成図である。
【００８１】
図６に示すように、ＶＯＢは複数のＶＯＢＵ（Ｖｉｄｅｏ Ｏｂｊｅｃｔ Ｕｎｉｔ）によって構成されている。ＶＯＢＵは、ＭＰＥＧビデオストリームで言うＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅｓ）を基準として、音声データも含んだ多重化ストリームとしての一再生単位である。ＶＯＢＵは１．０秒以下のビデオ再生時間を持ち、通常は０．５秒程度の再生時間を持っている。
【００８２】
ＶＯＢＵ先頭のＴＳパケット（ＭＰＥＧ−２ Ｔｒａｎｓｐｏｒｔ Ｓｔｒｅａｍ Ｐａｃｋｅｔ）は、シーケンスヘッダとそれに続くＧＯＰヘッダとＩピクチャ（Ｉｎｔｒａ−ｃｏｄｅｄ）を格納しており、このＩピクチャからの復号が開始可能なようになっている。また、このＶＯＢＵ先頭のＩピクチャの先頭を含むＴＳパケットのアドレス（開始アドレス）と、この開始アドレスからＩピクチャの最後を含むＴＳパケットまでのアドレス（終了アドレス）と、このＩピクチャの再生開始時刻（ＰＴＳ）をタイムマップで管理している。したがって、タイムマップのエントリーはＶＯＢＵ先頭のＴＳパケットごとに与えられている。
【００８３】
ＶＯＢＵは、その内部にビデオパケット（Ｖ＿ＰＫＴ）とオーディオパケット（Ａ＿ＰＫＴ）を有している。各パケットは１８８バイトであり、図６に図示してはいないが、各ＴＳパケットの直前には、そのＴＳパケットの相対的なデコーダ供給開始時刻であるＡＴＳ（Ａｒｒｉｖａｌ Ｔｉｍｅ Ｓｔａｍｐ）が付与されている。
【００８４】
ＡＴＳを各ＴＳパケットごとに付与するのは、このＴＳストリームのシステムレートが固定レートでなく、可変レートであるためである。一般的にシステムレートを固定にする場合にはＮＵＬＬパケットと呼ばれるダミーのＴＳパケットを挿入することになるが、限られた記録容量の中に高画質で記録するためには、可変レートが適しており、ＢＤではＡＴＳ付きのＴＳストリームとして記録している。
【００８５】
図７は、ＴＳパケットの構成を示した図である。
図７に示すように、ＴＳパケットは、ＴＳパケットヘッダと、適用フィールドと、ペイロード部から構成される。ＴＳパケットヘッダにはＰＩＤ（Ｐａｃｋｅｔ Ｉｄｅｎｔｉｆｉｅｒ）が格納され、これにより、ＴＳパケットがどのような情報を格納しているのか識別される。適用フィールドにはＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）が格納される。ＰＣＲはストリームをデコードする機器の基準クロック（Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ、ＳＴＣと呼ぶ）の参照値である。機器は典型的にはＰＣＲのタイミングでシステムストリームをデマルチプレクスし、ビデオストリーム等の各種ストリームを再構築する。ペイロードにはＰＥＳパケットが格納される。
【００８６】
ＰＥＳパケットヘッダには、ＤＴＳ（Ｄｅｃｏｄｉｎｇ Ｔｉｍｅ Ｓｔａｍｐ）とＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ Ｔｉｍｅ Ｓｔａｍｐ）が格納される。ＤＴＳは当該ＰＥＳパケットに格納されるピクチャ／オーディオフレームのデコードタイミングを示し、ＰＴＳは映像音声出力等のプレゼンテーションタイミングを示す。ビデオデータおよびオーディオデータといったエレメンタリデータは、ＰＥＳパケットペイロード（ＰＥＳ Ｐａｃｋｅｔ Ｐａｙｌｏａｄ）と呼ばれるパケット（ＰＥＳ Ｐａｃｋｅｔ）のデータ格納領域に先頭から順次入れられていく。ＰＥＳパケットヘッダには、ペイロードに格納してあるデータがどのストリームなのかを識別するためのＩＤ（ｓｔｒｅａｍ＿ｉｄ）も記録されている。
【００８７】
ＴＳストリームの詳細についてはＩＳＯ／ＩＥＣ１３８１８−１で規定されており、ＢＤで特徴的なのはＡＴＳを各ＴＳパケットごとに付与したことである。
【００８８】
（ＶＯＢのインターリーブ記録）
次に図８および図９を用いてＶＯＢファイルのインターリーブ記録について説明する。
【００８９】
図８上段は、前述したプレーヤ構成図の一部である。図の通り、ＢＤディスク上のデータは、光ピックアップを通してＶＯＢ即ちＭＰＥＧストリームであればトラックバッファへ入力され、ＰＮＧ即ちイメージデータであればイメージメモリへと入力される。
【００９０】
トラックバッファはＦＩＦＯであり、入力されたＶＯＢのデータは入力された順にデマルチプレクサへと送られる。この時、前述したＡＴＳに従って個々のＴＳパケットはトラックバッファから引き抜かれデマルチプレクサを介してビデオプロセッサまたはサウンドプロセッサへとデータが送り届けられる。一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラによって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリから削除されるが、メニュー用のイメージデータの場合は、そのメニュー描画中はイメージメモリ内にそのまま残される。これはメニューの描画はユーザ操作に依存しており、ユーザーの操作に追従してメニューの一部分を再表示もしくは異なるイメージに置き換えることがあり、その際に再表示される部分のイメージデータをデコードし易くするためである。
【００９１】
図８下段は、ＢＤディスク上でのＶＯＢファイルおよびＰＮＧファイルのインターリーブ記録を示す図である。一般的にＲＯＭ、例えばＣＤ−ＲＯＭやＤＶＤ−ＲＯＭの場合、一連の連続再生単位となるＡＶデータは連続記録されている。これは、連続記録されている限り、ドライブは順次データを読み出し、デコーダに送り届けるだけで良いが、連続データが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになり、データの供給が止まる可能性があるからである。ＢＤの場合も同様に、ＶＯＢファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにＶＯＢに記録されている映像データと同期して再生されるデータがあり、ＶＯＢファイルと同様に字幕データも何らかの方法によってＢＤディスクから読み出す事が必要になる。
【００９２】
字幕データの読み出し方法の一手段として、ＶＯＢの再生開始前に一まとめで字幕用のイメージデータ（ＰＮＧファイル）を読み出してしまう方法がある。しかしながら、この場合には大量のメモリが必要となり、非現実的である。
【００９３】
そこで、ＶＯＢファイルを幾つかのブロックに分けて、イメージデータとインターリーブ記録する方式を使用している。図８下段はそのインターリーブ記録を説明した図である。
【００９４】
ＶＯＢファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリに格納することが可能になる。しかしながらイメージデータを読み出している際には、ＶＯＢデータの読み込みは当然のことながら停止することになる。
【００９５】
図９は、この問題を解決するトラックバッファを使ったＶＯＢデータ連続供給モデルを説明する図である。
【００９６】
既に説明したように、ＶＯＢのデータは、一旦トラックバッファに蓄積される。トラックバッファへのデータ入力レート（Ｖａ）とトラックバッファからのデータ出力レート（Ｖｂ）の間に差（Ｖａ＞Ｖｂ）を設けると、ＢＤディスクからデータを読み出し続けている限り、トラックバッファのデータ蓄積量は増加をしていくことになる。
【００９７】
図９の上段に記すようにＶＯＢの一連続記録領域が論理アドレスの”ａ１”から”ａ２”まで続くとする。”ａ２”から”ａ３”の間は、イメージデータが記録されていて、ＶＯＢデータの読み出しが行えない区間であるとする。
【００９８】
図９の下段は、トラックバッファの内部を示す図である。横軸が時間、縦軸がトラックバッファ内部に蓄積されているデータ量を示している。時刻”ｔ１”がＶＯＢの一連続記録領域の開始点である”ａ１”の読み出しを開始した時刻を示している。この時刻以降、トラックバッファにはレートＶａ−Ｖｂでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファの入出力レートの差である。時刻”ｔ２”は一連続記録領域の終了点である”ａ２”のデータを読み込む時刻である。即ち時刻”ｔ１”から”ｔ２”の間レートＶａ−Ｖｂでトラックバッファ内はデータ量が増加していき、時刻”ｔ２”でのデータ蓄積量はＢ（ｔ２）は下式によって求めることができる。
Ｂ（ｔ２） ＝ （Ｖａ−Ｖｂ）×（ｔ２−ｔ１） （式１）
この後、ＢＤディスク上のアドレス”ａ３”まではイメージデータが続くため、トラックバッファへの入力は０となり、出力レートである”−Ｖｂ”でトラックバッファ内のデータ量は減少していくことになる。これは読み出し位置”ａ３”まで、時刻でいう”ｔ３”までになる。
【００９９】
ここで大事なことは、時刻”ｔ３”より前にトラックバッファに蓄積されているデータ量が０になると、デコーダへ供給するＶＯＢのデータが無くなってしまい、ＶＯＢの再生がストップしてしまう可能性がある。しかしながら、時刻”ｔ３”でトラックバッファにデータが残っている場合には、ＶＯＢの再生がストップすることなく連続できることを意味している。
【０１００】
この条件は下式によって示すことができる。
Ｂ（ｔ２） ≧ −Ｖｂ×（ｔ３−ｔ２） （式２）
即ち、式２を満たすようにイメージデータ（非ＶＯＢデータ）の配置を決めればよい事になる。
【０１０１】
（ナビゲーションデータ構造）
図１０から図１６を用いて、ＢＤのナビゲーションデータ（ＢＤ管理情報）構造について説明をする。
【０１０２】
図１０は、ＶＯＢ管理情報情報ファイル（”ＹＹＹ．ＶＯＢＩ”）の内部構造を示した図である。
【０１０３】
ＶＯＢ管理情報は、当該ＶＯＢのストリーム属性情報（Ａｔｔｒｉｂｕｔｅ）とタイムマップを有している。ストリーム属性は、ビデオ属性（Ｖｉｄｅｏ）、オーディオ属性（Ａｕｄｉｏ＃０〜Ａｕｄｉｏ＃ｍ）個々に持つ構成となっている。特にオーディオストリームの場合は、ＶＯＢが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数（Ｎｕｍｂｅｒ）によって、データフィールドの有無を示している。
【０１０４】
下記はビデオ属性（Ｖｉｄｅｏ）の持つフィールドと夫々が持ち得る値である。
圧縮方式（Ｃｏｄｉｎｇ）：
ＭＰＥＧ１
ＭＰＥＧ２
ＭＰＥＧ４
ＭＰＥＧ４−ＡＶＣ（Ａｄｖａｎｃｅｄ Ｖｉｄｅｏ Ｃｏｄｉｎｇ）
解像度（Ｒｅｓｏｌｕｔｉｏｎ）：
１９２０ｘ１０８０
１４４０ｘ１０８０
１２８０ｘ７２０
７２０ｘ４８０
７２０ｘ５６５
アスペクト比（Ａｓｐｅｃｔ）
４：３
１６：９
フレームレート（Ｆｒａｍｅｒａｔｅ）
６０
５９．９４（６０／１．００１）
５０
３０
２９．９７（３０／１．００１）
２５
２４
２３．９７６（２４／１．００１）
【０１０５】
下記はオーディオ属性（Ａｕｄｉｏ）の持つフィールドと夫々が持ち得る値である。
圧縮方式（Ｃｏｄｉｎｇ）：
ＡＣ３
ＭＰＥＧ１
ＭＰＥＧ２
ＬＰＣＭ
チャンネル数（Ｃｈ）：
１〜８
言語属性（Ｌａｎｇｕａｇｅ）：
【０１０６】
タイムマップ（ＴＭＡＰ）はＶＯＢＵ毎の情報を持つテーブルであって、当該ＶＯＢが有するＶＯＢＵ数（Ｎｕｍｂｅｒ）と各ＶＯＢＵ情報（ＶＯＢＵ＃１〜ＶＯＢＵ＃ｎ）を持つ。個々のＶＯＢＵ情報は、ＶＯＢＵ先頭ＴＳパケット（Ｉピクチャ開始）のアドレスＩ＿ｓｔａｒｔと、そのＩピクチャの終了アドレスまでのオフセットアドレス（Ｉ＿ｅｎｄ）、およびそのＩピクチャの再生開始時刻（ＰＴＳ）から構成される。
【０１０７】
なお、Ｉ＿ｅｎｄの値はオフセット値、すなわちＩピクチャのサイズを持たせるのではなく、実際のＩピクチャの終了アドレスを持たせてもよい。
【０１０８】
図１１はＶＯＢＵ情報の詳細を説明する図である。
広く知られているように、ＭＰＥＧビデオストリームは高画質記録するために可変ビットレート圧縮されることがあり、その再生時間とデータサイズ間に単純な相関はない。逆に、音声の圧縮規格であるＡＣ３は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は１次式によって求めることができる。しかしながらＭＰＥＧビデオデータの場合は、個々のフレームは固定の表示時間、例えばＮＴＳＣの場合は１フレームは１／２９．９７秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるＩ／Ｐ／Ｂピクチャによってデータサイズは大きく変わってくる。従って、ＭＰＥＧビデオの場合は、時間とアドレスの関係は一次式の形で表現することは不可能である。
【０１０９】
当然の事として、ＭＰＥＧビデオデータを多重化しているＭＰＥＧシステムストリーム、即ちＶＯＢも時間とデータサイズとを一次式の形で表現することは不可能である。このため、ＶＯＢ内での時間とアドレスとの関係を結びつけるのがタイムマップ（ＴＭＡＰ）である。
【０１１０】
このようにして、ある時刻情報が与えられた場合、先ずは当該時刻がどのＶＯＢＵに属するのかを検索（ＶＯＢＵ毎のＰＴＳを追っていく）して、当該時刻の直前のＰＴＳをＴＭＡＰに持つＶＯＢＵに飛びこみ（Ｉ＿ｓｔａｒｔで指定されたアドレス）、ＶＯＢＵ先頭のＩピクチャから復号を開始し、当該時刻のピクチャから表示を開始する。
【０１１１】
次に図１２を使って、プレイリスト情報（”ＸＸＸ．ＰＬ”）の内部構造を説明する。
プレイリスト情報は、セルリスト（ＣｅｌｌＬｉｓｔ）とイベントリスト（ＥｖｅｎｔＬｉｓｔ）から構成されている。
【０１１２】
セルリスト（ＣｅｌｌＬｉｓｔ）は、プレイリスト内の再生セルシーケンスであり、本リストの記述順でセルが再生される事になる。セルリスト（ＣｅｌｌＬｉｓｔ）の中身は、セルの数（Ｎｕｍｂｅｒ）と各セル情報（Ｃｅｌｌ＃１〜Ｃｅｌｌ＃ｎ）である。
【０１１３】
セル情報（Ｃｅｌｌ＃）は、ＶＯＢファイル名（ＶＯＢＮａｍｅ）、当該ＶＯＢ内での開始時刻（Ｉｎ）および終了時刻（Ｏｕｔ）と、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）を持っている。開始時刻（Ｉｎ）および終了時刻（Ｏｕｔ）は、夫々当該ＶＯＢ内でのフレーム番号で表現され、前述したタイムマップを使うことによって再生に必要なＶＯＢデータのアドレスを得る事ができる。
【０１１４】
字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）は、当該ＶＯＢと同期再生される字幕情報を持つテーブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブル（ＳｕｂｔｉｔｌｅＴａｂｌｅ）最初の情報も言語数（Ｎｕｍｂｅｒ）とそれに続く個々の言語ごとのテーブル（Ｌａｎｇｕａｇｅ＃１〜Ｌａｎｇｕａｇｅ＃ｋ）から構成されている。
【０１１５】
各言語のテーブル（Ｌａｎｇｕａｇｅ＃）は、言語情報（Ｌａｎｇ）と、個々に表示される字幕の字幕情報数（Ｎｕｍｂｅｒ）と、個々に表示される字幕の字幕情報（Ｓｐｅｅｃｈ＃１〜Ｓｐｅｅｃｈ＃ｊ）から構成され、字幕情報（Ｓｐｅｅｃｈ＃）は対応するイメージデータファイル名（Ｎａｍｅ）、字幕表示開始時刻（Ｉｎ）および字幕表示終了時刻（Ｏｕｔ）と、字幕の表示位置（Ｐｏｓｉｔｉｏｎ）から構成されている。
【０１１６】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、当該プレイリスト内で発生するイベントを定義したテーブルである。イベントリストは、イベント数（Ｎｕｍｂｅｒ）に続いて個々のイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）から構成され、個々のイベント（Ｅｖｅｎｔ＃）は、イベントの種類（Ｔｙｐｅ）、イベントのＩＤ（ＩＤ）、イベント発生時刻（Ｔｉｍｅ）と有効期間（Ｄｕｒａｔｉｏｎ）から構成されている。
【０１１７】
図１３は、個々のプレイリスト毎のイベントハンドラ（時間イベントと、メニュー選択用のユーザイベント）を持つイベントハンドラテーブル（”ＸＸＸ．ＰＲＯＧ”）である。
【０１１８】
イベントハンドラテーブルは、定義されているイベントハンドラ／プログラム数（Ｎｕｍｂｅｒ）と個々のイベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃１〜Ｐｒｏｇｒａｍ＃ｎ）を有している。各イベントハンドラ／プログラム（Ｐｒｏｇｒａｍ＃）内の記述は、イベントハンドラ開始の定義（＜ｅｖｅｎｔ＿ｈａｎｄｌｅｒ＞タグ）と前述したイベントのＩＤと対になるイベントハンドラのＩＤ（ＩＤ）を持ち、その後に当該プログラムもＦｕｎｃｔｉｏｎに続く括弧”｛”と”｝”の間に記述する。前述の”ＸＸＸ．ＰＬ”のイベントリスト（ＥｖｅｎｔＬｉｓｔ）に格納されたイベント（Ｅｖｅｎｔ＃１〜Ｅｖｅｎｔ＃ｍ）は”ＸＸＸ．ＰＲＯＧ”のイベントハンドラのＩＤ（ＩＤ）を用いて特定される。
【０１１９】
次に図１４を用いてＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）の内部構造を説明する。
【０１２０】
ＢＤディスク全体情報は、タイトルリスト（ＴｉｔｌｅＬｉｓｔ）とグローバルイベント用のイベントテーブル（ＥｖｅｎｔＬｉｓｔ）から構成されている。
【０１２１】
タイトルリスト（ＴｉｔｌｅＬｉｓｔ）は、ディスク内のタイトル数（Ｎｕｍｂｅｒ）と、これに続く各タイトル情報（Ｔｉｔｌｅ＃１〜Ｔｉｔｌｅ＃ｎ）から構成されている。個々のタイトル情報（Ｔｉｔｌｅ＃）は、タイトルに含まれるプレイリストのテーブル（ＰＬＴａｂｌｅ）とタイトル内のチャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）を含んでいる。プレイリストのテーブル（ＰＬＴａｂｌｅ）はタイトル内のプレイリストの数（Ｎｕｍｂｅｒ）と、プレイリスト名（Ｎａｍｅ）即ちプレイリストのファイル名を有している。
【０１２２】
チャプタリスト（ＣｈａｐｔｅｒＬｉｓｔ）は、当該タイトルに含まれるチャプタ数（Ｎｕｍｂｅｒ）と個々のチャプタ情報（Ｃｈａｐｔｅｒ＃１〜Ｃｈａｐｔｅｒ＃ｎ）から構成され、個々のチャプタ情報（Ｃｈａｐｔｅｒ＃）は当該チャプタが含むセルのテーブル（ＣｅｌｌＴａｂｌｅ）を持ち、セルのテーブル（ＣｅｌｌＴａｂｌｅ）はセル数（Ｎｕｍｂｅｒ）と個々のセルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃１〜ＣｅｌｌＥｎｔｒｙ＃ｋ）から構成されている。セルのエントリ情報（ＣｅｌｌＥｎｔｒｙ＃）は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。
【０１２３】
イベントリスト（ＥｖｅｎｔＬｉｓｔ）は、グローバルイベントの数（Ｎｕｍｂｅｒ）と個々のグローバルイベントの情報を持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）と呼ばれ、ＢＤディスクがプレーヤに挿入された時、最初に呼ばれるイベントである。グローバルイベント用イベント情報はイベントタイプ（Ｔｙｐｅ）とイベントのＩＤ（ＩＤ）だけを持っている。
【０１２４】
図１５は、グローバルイベントハンドラのプログラムのテーブル（”ＢＤ．ＰＲＯＧ”）である。
【０１２５】
本テーブルは、図１６で説明したイベントハンドラテーブルと同一内容である。
【０１２６】
（イベント発生のメカニズム）
図１６から図１８を使ってイベント発生のメカニズムについて説明する。
【０１２７】
図１６はタイムイベントの例である。
前述したとおり、タイムイベントはプレイリスト情報（”ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。タイムイベントとして定義されているイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＴｉｍｅＥｖｅｎｔ”の場合、イベント生成時刻（”ｔ１”）になった時点で、ＩＤ”Ｅｘ１”を持つタイムイベントがシナリオプロセッサからプログラムプロセッサに対してあげられる。プログラムプロセッサは、イベントＩＤ”Ｅｘ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合では、２つのボタンイメージの描画を行うなどを行うことができる。
【０１２８】
図１７はメニュー操作を行うユーザーイベントの例である。
前述したとおり、メニュー操作を行うユーザイベントもプレイリスト情報（”ＸＸＸ．ＰＬ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。ユーザイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＵｓｅｒＥｖｅｎｔ”の場合、イベント生成時刻（”ｔ１”）になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。当該イベントは、有効期間情報（Ｄｕｒａｔｉｏｎ）で記される期間レディ状態にある。
【０１２９】
図１７に描くように、ユーザがリモコンキーの「上」「下」「左」「右」キーまたは「決定」キーを押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してＵＯＰイベントを流し、シナリオプロセッサはＵＯＰイベントを受け取った時刻に有効なユーザイベントが存在するかを検索し、対象となるユーザイベントがあった場合は、ユーザイベントを生成し、プログラムプロセッサに持ち上げる。プログラムプロセッサでは、イベントＩＤ”Ｅｖ１”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合では、プレイリスト＃２の再生を開始する。
【０１３０】
生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、ＵＯＰイベントによってプログラムプロセッサに伝えられ、仮想プレーヤが持つレジスタＳＰＲＭ（８）に記録保持される。イベントハンドラのプログラムは、このレジスタの値を調べ分岐処理を実行することが可能である。
【０１３１】
図１８はグローバルイベントの例である。
前述したとおり、グローバルイベントはＢＤディスク全体に関する情報（”ＢＤ．ＩＮＦＯ”）のイベントリスト（ＥｖｅｎｔＬｉｓｔ）で定義される。グローバルイベントとして定義されるイベント、即ちイベントタイプ（Ｔｙｐｅ）が”ＧｌｏｂａｌＥｖｅｎｔ”の場合、ユーザのリモコンキー操作があった場合にのみイベントが生成される。
【０１３２】
ユーザが”メニュー”を押した場合、先ずＵＯＰイベントがＵＯＰマネージャによって生成されプログラムプロセッサに上げられる。プログラムプロセッサは、シナリオプロセッサに対してＵＯＰイベントを流し、シナリオプロセッサは、該当するグローバルイベントを生成し、プログラムプロセッサに送る。プログラムプロセッサでは、イベントＩＤ”ｍｅｎｕ”を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施例の場合ではプレイリスト＃３の再生を開始している。
【０１３３】
本実施例では、単に”メニュー”キーと呼んでいるが、ＤＶＤのように複数のメニューキーがあってもよい。各メニューキーに対応するＩＤを夫々定義することで対応することが可能である。
【０１３４】
（仮想プレーヤマシン）
図１９を用いてプログラムプロセッサの機能構成を説明する。
【０１３５】
プログラムプロセッサは、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンはＢＤとして定義された機能モデルであって、各ＢＤプレーヤの実装には依存しないものである。即ち、どのＢＤプレーヤにおいても同様の機能を実行するできることを保証している。
【０１３６】
仮想プレーヤマシンは大きく２つの機能を持っている。プログラミング関数とプレーヤ変数（レジスタ）である。プログラミング関数は、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔをベースとして、以下に記す２つの機能をＢＤ固有関数として定義している。
【０１３７】
リンク関数：現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始する
Ｌｉｎｋ（ＰＬ＃，Ｃｅｌｌ＃，ｔｉｍｅ）
ＰＬ＃ ： プレイリスト名
Ｃｅｌｌ＃ ： セル番号
ｔｉｍｅ ： セル内での再生開始時刻
ＰＮＧ描画関数：指定ＰＮＧデータをイメージプレーンに描画する
Ｄｒａｗ（Ｆｉｌｅ，Ｘ，Ｙ）
Ｆｉｌｅ ： ＰＮＧファイル名
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
イメージプレーンクリア関数：イメージプレーンの指定領域をクリアする
Ｃｌｅａｒ（Ｘ，Ｙ，Ｗ，Ｈ）
Ｘ ： Ｘ座標位置
Ｙ ： Ｙ座標位置
Ｗ ： Ｘ方向幅
Ｈ ： Ｙ方向幅
プレーヤ変数は、プレーヤの状態を示すシステムパラメータ（ＳＰＲＭ）と一般用途として使用可能なゼネラルパラメータ（ＧＰＲＭ）とがある。
【０１３８】
図２０はシステムパラメータ（ＳＰＲＭ）の一覧である。
ＳＰＲＭ（０） ： 言語コード
ＳＰＲＭ（１） ： 音声ストリーム番号
ＳＰＲＭ（２） ： 字幕ストリーム番号
ＳＰＲＭ（３） ： アングル番号
ＳＰＲＭ（４） ： タイトル番号
ＳＰＲＭ（５） ： チャプタ番号
ＳＰＲＭ（６） ： プログラム番号
ＳＰＲＭ（７） ： セル番号
ＳＰＲＭ（８） ： 選択キー情報
ＳＰＲＭ（９） ： ナビゲーションタイマー
ＳＰＲＭ（１０） ： 再生時刻情報
ＳＰＲＭ（１１） ： カラオケ用ミキシングモード
ＳＰＲＭ（１２） ： パレンタル用国情報
ＳＰＲＭ（１３） ： パレンタルレベル
ＳＰＲＭ（１４） ： プレーヤ設定値（ビデオ）
ＳＰＲＭ（１５） ： プレーヤ設定値（オーディオ）
ＳＰＲＭ（１６） ： 音声ストリーム用言語コード
ＳＰＲＭ（１７） ： 音声ストリーム用言語コード（拡張）
ＳＰＲＭ（１８） ： 字幕ストリーム用言語コード
ＳＰＲＭ（１９） ： 字幕ストリーム用言語コード（拡張）
ＳＰＲＭ（２０） ： プレーヤリージョンコード
ＳＰＲＭ（２１） ： 予備
ＳＰＲＭ（２２） ： 予備
ＳＰＲＭ（２３） ： 再生状態
ＳＰＲＭ（２４） ： 予備
ＳＰＲＭ（２５） ： 予備
ＳＰＲＭ（２６） ： 予備
ＳＰＲＭ（２７） ： 予備
ＳＰＲＭ（２８） ： 予備
ＳＰＲＭ（２９） ： 予備
ＳＰＲＭ（３０） ： 予備
ＳＰＲＭ（３１） ： 予備
なお、本実施例では、仮想プレーヤのプログラミング関数をＪａｖａＳｃｒｉｐｔベースとしたが、ＪａｖａＳｃｒｉｐｔではなく、ＵＮＩＸ（登録商標） ＯＳなどで使われているＢ−Ｓｈｅｌｌや、Ｐｅｒｌ Ｓｃｒｉｐｔなど他のプログラミング関数であっても構わなく、言い換えれば、本発明はＪａｖａＳｃｒｉｐｔに限定されるものでは無い。
【０１３９】
（プログラムの例）
図２１および図２２は、イベントハンドラでのプログラムの例である。
【０１４０】
図２１は、２つの選択ボタンを持ったメニューの例である。
セル（ＰｌａｙＬｉｓｔ＃１．Ｃｅｌｌ＃１）先頭でタイムイベントを使って図２４左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つＧＰＲＭ（０）に”１”がセットされている。ＧＰＲＭ（０）は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン１が選択されている事を初期値として持たされている。
【０１４１】
次に、ＰＮＧの描画を描画関数であるＤｒａｗを使ってボタン１、ボタン２夫々について行っている。ボタン１は、座標（１０、２００）を起点（左端）としてＰＮＧイメージ”１ｂｌａｃｋ．ｐｎｇ”を描画している。ボタン２は、座標（３３０，２００）を起点（左端）としてＰＮＧイメージ”２ｗｈｉｔｅ．ｐｎｇ”を描画している。
【０１４２】
また、本セル最後ではタイムイベントを使って図２４右側のプログラムが実行される。ここでは、Ｌｉｎｋ関数を使って当該セルの先頭から再度再生するように指定している。
【０１４３】
図２２は、メニュー選択のユーザイベントのイベントハンドラの例である。
「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合夫々に対応するプログラムがイベントハンドラに書かれている。ユーザがリモコンキーを押した場合、図１７で説明したとおり、ユーザイベントが生成され、図２２のイベントハンドラが起動されることになる。本イベントハンドラでは、選択ボタンを識別しているＧＰＲＭ（０）の値と、選択されたリモコンキーを識別するＳＰＲＭ（８）を使って分岐処理を行っている。
【０１４４】
条件１）ボタン１が選択されている、かつ、選択キーが「右」キーの場合
ＧＰＲＭ（０）を２に再設定して、選択状態にあるボタンを右ボタン２に変更する。
ボタン１、ボタン２のイメージを夫々書き換える。
条件２）選択キーが「決定（ＯＫ）」の場合で、ボタン１が選択されている場合
プレイリスト＃２の再生を開始する
条件３）選択キーが「決定（ＯＫ）」の場合で、ボタン２が選択されている場合
プレイリスト＃３の再生を開始する
上記のようにして実行処理が行われる。
【０１４５】
（プレーヤ処理フロー）
次に図２３から図２６を用いてプレーヤでの処理フローを説明する。
【０１４６】
図２３は、ＡＶ再生までの基本処理フローである。
ＢＤディスクを挿入すると（Ｓ１０１）、ＢＤプレーヤはＢＤ．ＩＮＦＯファイルの読み込みと解析（Ｓ１０２）、ＢＤ．ＰＲＯＧの読み込み（Ｓ１０３）を実行する。ＢＤ．ＩＮＦＯおよびＢＤ．ＰＲＯＧは共に管理情報記録メモリに一旦格納され、シナリオプロセッサによって解析される。
【０１４７】
続いて、シナリオプロセッサは、ＢＤ．ＩＮＦＯファイル内のファーストイベント（ＦｉｒｓｔＥｖｅｎｔ）情報に従い、最初のイベントを生成する（Ｓ１０４）。生成されたファーストイベントは、プログラムプロセッサで受け取られ、当該イベントに対応するイベントハンドラを実行処理する（Ｓ１０５）。
【０１４８】
ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリスト情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになる。（Ｓ２０１）。ＢＤプレーヤはユーザからのリモコン操作を受け付けると、ＵＯＰマネージャはプログラムマネージャに対してＵＯＰイベントを立ち上げる（Ｓ２０２）。
【０１４９】
プログラムマネージャは、ＵＯＰイベントがメニューキーかを判別し（Ｓ２０３）、メニューキーの場合は、シナリオプロセッサにＵＯＰイベントを流し、シナリオプロセッサがユーザイベントを生成する（Ｓ２０４）。プログラムプロセッサは生成されたユーザイベントに対応するイベントハンドラを実行処理する（Ｓ２０５）。
【０１５０】
図２４は、ＰＬ再生開始からＶＯＢ再生開始までの処理フローである。
前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始される（Ｓ３０１）。シナリオプロセッサは、再生対象のプレイリスト再生に必要な情報として、プレイリスト情報”ＸＸＸ．ＰＬ”の読み込みと解析（Ｓ３０２）、プレイリストに対応するプログラム情報”ＸＸＸ．ＰＲＯＧ”の読み込みを行う（Ｓ３０３）。続いてシナリオプロセッサは、プレイリストに登録されているセル情報に基づいてセルの再生を指示する（Ｓ３０４）。セル再生は、シナリオプロセッサからプレゼンテーションコントローラに対して要求が出さる事を意味し、プレゼンテーションコントローラはＡＶ再生を開始する（Ｓ３０５）。
【０１５１】
ＡＶ再生の開始（Ｓ４０１）を開始すると、プレゼンテーションコントローラは再生するセルに対応するＶＯＢの情報ファイル（ＸＸＸ．ＶＯＢＩ）を読み込みおよび解析をする（Ｓ４０２）。プレゼンテーションコントローラは、タイムマップを使って再生開始するＶＯＢＵとそのアドレスを特定し、ドライブコントローラに読み出しアドレスを指示し、ドライブコントローラは対象となるＶＯＢデータを読み出し（Ｓ４０３）、ＶＯＢデータがデコーダに送られ再生が開始される（Ｓ４０４）。
【０１５２】
ＶＯＢ再生は、当該ＶＯＢの再生区間が終了するまで続けられ（Ｓ４０５）、終了すると次のセル再生Ｓ３０４へ移行する。次にセルが無い場合は、再生が停止する（Ｓ４０６）。
【０１５３】
図２５は、ＡＶ再生開始後からのイベント処理フローである。
ＢＤプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスが夫々起動され、平行してイベント処理を実行するようになる。
【０１５４】
Ｓ５００系の処理は、タイムイベント系の処理フローである。
プレイリスト再生開始後（Ｓ５０１）、プレイリスト再生が終了しているかを確認するステップ（Ｓ５０２）を経て、シナリオプロセッサは、タイムイベント発生時刻になったかを確認する（Ｓ５０３）。タイムイベント発生時刻になっている場合には、シナリオプロセッサはタイムイベントを生成し（Ｓ５０４）、プログラムプロセッサがタイムイベントを受け取りイベントハンドラを実行処理する（Ｓ５０５）。
【０１５５】
ステップＳ５０３でタイムイベント発生時刻になっていない場合、または、ステップＳ５０４でイベントハンドラ実行処理後は再度ステップＳ５０２へ戻り、上述した処理を繰り返す。また、ステップＳ５０２でプレイリスト再生が終了したことが確認されると、タイムイベント系の処理は強制的に終了する。
【０１５６】
Ｓ６００系の処理は、ユーザイベント系の処理フローである。
プレイリスト再生開始後（Ｓ６０１）、プレイリスト再生終了確認ステップ（Ｓ６０２）を経て、ＵＯＰ受付確認ステップの処理に移る（Ｓ６０３）。ＵＯＰの受付があった場合、ＵＯＰマネージャはＵＯＰイベントを生成し（Ｓ６０４）、ＵＯＰイベントを受け取ったプログラムプロセッサはＵＯＰイベントがメニューコールであるかを確認し（Ｓ６０５）、メニューコールであった場合は、プログラムプロセッサはシナリオプロセッサにイベントを生成させ（Ｓ６０７）、プログラムプロセッサはイベントハンドラを実行処理する（Ｓ６０８）。
【０１５７】
ステップＳ６０５でＵＯＰイベントがメニューコールで無いと判断された場合、ＵＯＰイベントはカーソルキーまたは「決定」キーによるイベントである事を示している。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサが判断し（Ｓ６０６）、有効期間内である場合には、シナリオプロセッサがユーザイベントを生成し（Ｓ６０７）、プログラムプロセッサが対象のイベントハンドラを実行処理する（Ｓ６０８）。
【０１５８】
ステップＳ６０３でＵＯＰ受付が無い場合、ステップＳ６０６で現在時刻がユーザイベント有効期間に無い場合、または、ステップＳ６０８でイベントハンドラ実行処理後は再度ステップＳ６０２へ戻り、上述した処理を繰り返す。また、ステップＳ６０２でプレイリスト再生が終了したことが確認されると、ユーザイベント系の処理は強制的に終了する。
【０１５９】
図２６は字幕処理のフローである。
プレイリスト再生開始後（Ｓ７０１）、プレイリスト再生終了確認ステップ（Ｓ７０２）を経て、字幕描画開始時刻確認ステップに移る（Ｓ７０３）。字幕描画開始時刻の場合、シナリオプロセッサはプレゼンテーションコントローラに字幕描画を指示し、プレゼンテーションコントローラはイメージプロセッサに字幕描画を指示する（Ｓ７０４）。ステップＳ７０３で字幕描画開始時刻で無いと判断された場合、字幕表示終了時刻であるかを確認する（Ｓ７０５）。字幕表示終了時刻であると判断された場合は、プレゼンテーションコントローラがイメージプロセッサに字幕消去指示を行い、描画されている字幕をイメージプレーンから消去する（Ｓ７０６）。
【０１６０】
字幕描画ステップＳ７０４終了後、字幕消去ステップＳ７０６終了後、または、字幕表示終了時刻確認ステップＳ７０５で当該時刻でないことが判断された場合、ステップＳ７０２に戻り、上述した処理を繰り返す。また、ステップＳ７０２でプレイリスト再生が終了したことが確認されると、字幕表示系の処理は強制的に終了する。
【０１６１】
（実施の形態２）
本実施の形態では、Ｐ／Ｉピクチャを使用する際に、ストリームおよび管理情報を制約することにより特殊再生時の再生品質を向上させる。以下に、符号化ストリームを多重化する際の制約事項について説明する。
【０１６２】
まず、タイムマップと符号化ストリームとの関係について説明する。タイムマップからは、再生開始点として選択できる位置や、特殊再生時に読み込むことができるピクチャ指すことができる。本発明のタイムマップは、再生開始点として選択できる位置や、特殊再生時に読み込むことができる点として、Ｐ／Ｉピクチャから開始するＲＡＵは選択しない。
【０１６３】
図３０は、タイムマップとＲＡＵの関係を示している。再生開始点や特殊再生時に読み込まれるＲＡＵ先頭のピクチャの位置は、図３０が示すようにタイムマップに時間と関連付けられてアドレスが格納されている。時間を指定されると、タイムマップを利用して、再生開始するアドレスを割り出し、シークを行って再生を開始するわけである。この際、Ｐ／Ｉピクチャは、再生開始位置や特殊再生時に読み込まれるピクチャとして適切ではないため、タイムマップには登録しない。こうすることにより、再生開始点や特殊再生時には選択されず、解像度が半分に落ちた画像から再生が開始されることが回避できる。
【０１６４】
また、タイムマップの属性情報の１つとして、ストリーム中にＰ／Ｉピクチャが存在しないことを保証するフラグがあってもよい。このフラグが有効であれば、Ｐ／Ｉピクチャは存在しないので、どのＲＡＵ先頭から再生を開始してもよい。
【０１６５】
また、タイムマップの属性情報の１つとして、タイムマップがＰ／Ｉピクチャを指していないことを保証するフラグがあってもよい。このフラグが有効であれば、タイムマップはＰ／Ｉピクチャを指していないため、タイムマップに登録してあるＲＡＵ先頭位置から再生を開始すればよい。
【０１６６】
この２つの属性情報のいずれかがあれば、プレーヤはストリームを解析することなく、タイムマップを参照するだけで、十分な解像度をもって再生を開始できる再生開始位置の情報を取得することが可能となる。
【０１６７】
図３１は、タイムマップに属性情報を追加して、タイムマップが指すピクチャのピクチャタイプを登録できるようにした例である。このようにピクチャタイプが分かれば、再生開始位置としてＰ／Ｉピクチャは選ばないよう、プレーヤが判断することも可能となるので、このような方法も有効である。
【０１６８】
なお、図３２に示すように、Ｐ／Ｉピクチャにおいて、第１フィールドのＰピクチャが第２フィールドのＩピクチャを参照している場合、最初のフレームをデコードすることが可能となるため、これまで述べてきたＰ／Ｉピクチャと区別して、こちらの場合は再生開始点や特殊再生時に表示できるピクチャとして選択してもよい。
【０１６９】
以下に、制約方法の他の例について説明する。
ストリームの接続点、あるいはアングルの切替え点においては、切替え前後で再生画像をシームレスに連結できることが重要である。従って、シームレスな接続を実現するために、切替え後の先頭ピクチャとしてＰ／Ｉピクチャを禁止することは有効であり、下記が可能である。
【０１７０】
１．タイムマップからＰ／Ｉピクチャを指さない
２．ストリームにおいてＲＡＵの先頭をＰ／Ｉピクチャとしない
以下、１、２の順に説明する。
【０１７１】
タイムマップには、現プレイアイテムと直前のプレイアイテムとがシームレスに接続できるかどうかを示すフラグが格納される。従って、当該フラグにより、シームレスに接続できることが示されるプレイアイテムにおいては、プレイアイテムの先頭ピクチャとしてＰ／Ｉピクチャを配置しないことにしてもよい。また、タイムマップにおいては、プレイアイテムが１以上のアングルについての情報を示すことができ、さらに、アングル切替えをシームレスに行えるかどうかを示すフラグが格納できる。従って、シームレスなアングル切替えが可能であると示される際には、各アングルの先頭ピクチャとしてＰ／Ｉピクチャを配置しないことにしてもよい。あるいは、アングル切替えのポイントにおいては、シームレスであるかどうかに関わらず、アングル切替わり後の先頭ピクチャとしてはＰ／Ｉピクチャを禁止してもよい。また、各プレイアイテムをランダムアクセス再生することがコンテンツ作成者によって許可されているかどうかを示すフラグも格納されるため、ランダムアクセスが許可される際には、プレイアイテムの先頭にＰ／Ｉピクチャを配置しないことにしてもよい。図３３の例は、シームレス接続可能であることを示すフラグがセットされていれば、プレイアイテムの先頭ピクチャはＩ／Ｉピクチャ、またはＩ／Ｐピクチャのみであり、セットされていなければ、Ｐ／Ｉピクチャがプレイアイテムの先頭であってもよいことを示す。
【０１７２】
なお、本方式はＰ／Ｉピクチャに限定されるものではなく、ＲＡＵの先頭ピクチャの復号が保証できないケース全般において使用できる。なお、シームレスに接続できるかどうかを示す情報は、現プレイアイテムと直後のプレイアイテムとの関係を示してもよいし、プレイリストにより示される全てのプレイアイテムについての情報であってもよい。
【０１７３】
次に、タイムマップと組み合わせずに、ＶＣ−１のストリーム内で制約する例について説明する。Ｐ／Ｉピクチャの有無は、ＲＡＵ内のピクチャの復号を開始する前に判定できることが望ましいことから、ＲＡＵの先頭ピクチャがＰ／Ｉピクチャであるかどうかを示す情報をＲＡＵの先頭に格納する。先に、ＶＣ−１のＲＡＵには、クローズドＧＯＰ型とオープンＧＯＰ型の２種類があることを述べた。ＲＡＵがどちらのタイプであるかは、エントリ・ポイントのヘッダ内のフラグにより示され、フラグがセットされていればクローズドＧＯＰ型、セットされていなければオープンＧＯＰ型となる。シームレス接続やマルチアングル再生などにおいては、クローズドＧＯＰ型のＲＡＵから再生を開始するのが一般的であるため、クローズドＲＡＵの先頭ピクチャをＰ／Ｉピクチャとしないことにする。このとき、ＲＡＵがクローズドＧＯＰ型であるかどうかを示すフラグを、ＲＡＵの先頭ピクチャがＰ／Ｉピクチャであるかどうかを示すフラグとして使うことができる。従って、図３４に示すように、エントリ・ポイントのヘッダにおいてクローズドＧＯＰ型のＲＡＵであることが示される場合には、ＲＡＵの先頭ピクチャとしてＰ／Ｉピクチャを禁止し、オープンＧＯＰ型のＲＡＵであることが示される場合にはＲＡＵの先頭ピクチャとしてＰ／Ｉピクチャを使用可能とする。なお、ＲＡＵの先頭がＰ／Ｉピクチャであるかどうかを示す情報を、ユーザーデータなどを利用して別途格納してもよい。
【０１７４】
さらに、タイムマップの情報とストリーム内の情報とを組み合わせて使うことにより、ランダムアクセス単位の属性として下記４種類の情報を示すことができる。
【０１７５】
１．クローズドＧＯＰ型のＲＡＵであり、ＲＡＵの先頭ピクチャはＰ／Ｉピクチャではない
２．クローズドＧＯＰ型のＲＡＵであり、ＲＡＵの先頭ピクチャはＰ／Ｉピクチャであってもよい
３．オープンＧＯＰ型のＲＡＵであり、ＲＡＵの先頭ピクチャはＰ／Ｉピクチャではない
４．オープンＧＯＰ型のＲＡＵであり、ＲＡＵの先頭ピクチャはＰ／Ｉピクチャであってもよい
【０１７６】
例えば、（ストリーム内でクローズド型のＧＯＰであるかどうかを示すフラグ、タイムマップにおいてシームレス接続可能かどうかを示すフラグ）＝（１，１）、（１，０）、（０，１）、（０，０）の組み合わせが、それぞれ上記１、２、３、４を示すとする。こうすることで、Ｉピクチャのみの高速再生、飛び込み再生、シームレス接続、あるいはマルチアングル再生など、アプリケーションによって重視されるパターンに応じて上記のいずれかの属性を選択して使用できる。具体的には、上記１と、上記３あるいは上記４を選択すれば、オープンＧＯＰ型のＲＡＵにおいてはＩ／Ｐピクチャの配置に対しては制約がなく、クローズドＧＯＰ型のＲＡＵではＩ／Ｐピクチャを先頭に配置しないことになる。なお、上記１と上記２、およびオープンＧＯＰ型のＲＡＵの３種類を定義してもよい。
【０１７７】
また、ストリームのビットレートに応じてＰ／Ｉピクチャが使用できるかどうかを切替えてもよい。Ｐ／Ｉピクチャは、フレーム内の第２フィールドにおいてシーンチェンジが発生する際に有効であり、特に、低ビットレート時に有効である。従って、ＶＣ−１のストリーム、あるいは管理情報により示されるビットレートが所定の値以下、あるいは未満である場合にのみＰ／Ｉピクチャを使用可能としてもよい。ビットレートは、シーケンス・レイヤにおいて示すことができる。さらに、エントリ・ポイントレベルなどのユーザーデータにおいて、ビットレートを示してもよい。ここで、ユーザーデータにおいてビットレートを直接示さずに、ＲＡＵの先頭がＰ／Ｉピクチャであることを示す情報などが存在すれば、対応するＲＡＵ、あるいはストリーム全体におけるビットレートが所定の値以下、あるいは未満であるとしてもよい。ここで、再生機器の処理能力の上限値を設定するという意味で最大ビットレートが望ましいが、平均ビットレートであってもよい。また、ＶＣ−１規格では複数のレベルを設けて、レベル毎にビットレートや復号時に必要なバッファサイズなどを規定している。従って、レベルに応じてＰ／Ｉピクチャが使用できるかどうかを切替えてもよい。なお、レベルはシーケンス・レイヤなどにより示される。
【０１７８】
なお、上記の各制約方法を組み合わせて使用してもよく、例えば、ビットレートが所定の値以下である際には、オープンＧＯＰ型のＲＡＵにおいてのみＰ／Ｉピクチャを使用可能とする、などとしてもよい。これは、クローズドＧＯＰ型のＲＡＵではＧＯＰの先頭ピクチャから画質を劣化させずに再生できることが望ましいが、オープンＧＯＰ型のＲＡＵでは、元々ランダムアクセス時に復号できないピクチャが存在し得るため、Ｐ／Ｉピクチャの存在により復号できないピクチャが１枚増加することに対する許容度が大きいことによる。
【０１７９】
なお、ＢＤやＨＤ−ＤＶＤなど特定のアプリケーションでＶＣ−１ストリームを使用する際には、ＲＡＵの先頭をＰ／Ｉピクチャとすることを禁止してもよい。このとき、ＢＤ−ＲＯＭであれば、ＢＤ−ＩＮＦＯなど特定の名前のディレクトリが存在するかどうかによってアプリケーションの種類が示される。また、ＶＣ−１のストリームがメインのコンテンツであるか、ボーナス映像など付加的なコンテンツであるかに応じてＰ／Ｉピクチャの使用可否を切替えてもよい。一般に、付加的なコンテンツはビットレートが低く、Ｐ／Ｉピクチャが有効であるため、Ｐ／Ｉピクチャを使用可とし、ビットレートの高いメインのコンテンツにおいてはＰ／Ｉピクチャの使用を禁止する。ここで、メインのコンテンツであるか、付加的なコンテンツであるかは、ＢＤ管理情報内のフラグにより示される。あるいは、ネットワーク経由、ハードディスクなど光ディスクとは異なる場所に蓄積されたコンテンツを付加的なコンテンツとみなすこともできる。
【０１８０】
また、符号化ストリームはＶＣ−１に限定されるものではなく、第１フィールドがＰピクチャで、第２フィールドがＩピクチャであるフィールド・ペアを使える任意の符号化方式に適用できる。
【０１８１】
（実施の形態３）
図３８は、実施の形態２に係るＶＣ−１のストリームを符号化する本発明の符号化方法のフローチャートであり、クローズドＧＯＰ型のＲＡＵでは先頭にＰ／Ｉピクチャを配置しないように制約するステップＳ１１０１からステップＳ１１０３を新たに備えた点において従来の符号化方法と異なる。
【０１８２】
まず、ステップＳ１１０１では、符号化するピクチャがＲＡＵの先頭ピクチャであるかどうか判定し、先頭ピクチャであればステップＳ１１０２に進み、そうでなければステップＳ１１０４に進む。ステップＳ１１０３では、ＲＡＵがクローズドＧＯＰ型であるかどうか判定し、クローズドＧＯＰ型である際にはステップＳ１１０３に進み、そうでなければステップＳ１１０４に進む。ステップＳ１１０３では、ピクチャをフィールドとして符号化する際には、Ｉ／Ｉピクチャ、またはＩ／Ｐピクチャを用い、Ｐ／Ｉピクチャは使用しないと決定する。続いて、ステップＳ１１０４では、ステップＳ１１０３の決定に基づいてＲＡＵを構成するピクチャを符号化する。ここで、クローズドＧＯＰ型のＲＡＵである際には、ＲＡＵがクローズドＧＯＰ型であることを示すフラグをセットする。なお、ステップＳ１１０１に先立ってステップＳ１１０２の処理を行ってもよい。
【０１８３】
また、本符号化方法により符号化したストリームを、オーディオなどと多重化してもよい。多重化方式としては、ＭＰＥＧ−２のトランスポートストリーム、あるいはＢＤ（Ｂｌｕ−ｒａｙ Ｄｉｓｃ）などパッケージメディア毎に規定された方式がある。
【０１８４】
なお、出力されたストリームを多重化する際には、シームレス接続マルチアングル再生におけるアングルの切替りにおいては、接続点あるいは切替り点の直後の先頭ピクチャがＰ／Ｉピクチャとならないようにタイムマップを作成する。具体的には、接続点や切替り点としてはクローズドＧＯＰ型のＲＡＵのみを指定してもよい。
【０１８５】
図３９は、本実施の形態の符号化方法を実現する画像符号化装置１０の構成を示すブロック図である。画像符号化装置１０は、上記ステップＳ１１０１からステップＳ１１０３までの処理を行うタイプ制限ユニットＬＩＭＩＴを備えた点において従来の画像符号化装置１と異なる。予測構造決定ユニットＰＴＹＥは、タイプ制限ユニットＬＩＭＩＴにより指定されたピクチャタイプの制限情報ＬｍｔＩｎｆに基づいてピクチャの予測構造を決定する。
【０１８６】
（実施の形態４）
図４０は、実施の形態２に係るＶＣ−１ストリームの多重化データを復号する画像復号方法において、マルチアングル再生や、同一ストリーム内の異なる区間を連続して再生するなどの特殊再生時の表示動作を示すフローチャートである。本画像復号方法では、ＲＡＵの先頭ピクチャがＰ／Ｉピクチャであるかどうかに応じてピクチャの表示動作を切替えるステップＳ１００１からステップＳ１００４までの動作が不要である点において従来の画像復号方法と異なる。
【０１８７】
なお、タイムマップなどの管理情報によってマルチアングル再生が可能である、あるいは、シームレスに接続できることが保証される場合に限り、表示動作を切替えないことにして、当該情報が管理情報から識別できない場合には、従来の画像復号方法と同様に表示動作を切替えてもよい。
【０１８８】
なお、ＲＡＵがクローズドＧＯＰ型である際には表示動作を切替えずに、オープンＧＯＰ型であれば従来の画像復号方法と同様に表示動作を切替えてもよい。
【０１８９】
図４１は、本実施の形態の復号方法を実現する画像復号装置３０の構成を示すブロック図である。画像復号装置３０は、表示切替ユニットＭｏｄｅＳｅｔを備えない点において従来の画像復号装置と異なる。
【０１９０】
なお、上記各実施の形態における動画像の符号化方式はＶＣ−１に限定されるものではなく、同様の予測構造を有する符号化方式全般に適用できる。
【０１９１】
（実施の形態５）
本実施の形態５では、Ｐ／Ｉピクチャを用いることにより、ランダムアクセス再生や逆再生などの特殊再生の機能性向上を実現するデータ構造について説明する。
【０１９２】
まず、従来のデータ構造における第１の課題について説明する。図４３は、従来のＲＡＵの構造例を示す。図４３の例では、各ピクチャはフィールド構造で符号化されており、ＲＡＵの途中にはＰ／Ｉピクチャが存在する。ＶＣ−１規格では、ＲＡＵの先頭ピクチャとなるＰ／Ｉピクチャについては、表示順がＰ／Ｉピクチャよりも後であるピクチャが、Ｐ／ＩピクチャにおけるＰピクチャを参照することを禁止しているが、ＲＡＵの途中のＰ／Ｉピクチャについては、前記制約は規定していない。従って、図４３に示すように、Ｐ／Ｉピクチャよりも後のピクチャがＰ／ＩピクチャのＰピクチャを参照してもよい。このとき、Ｐ／ＩピクチャのＰピクチャは、表示順で前方のＰピクチャを参照できることから、Ｐ／Ｉピクチャ以降のピクチャを復号するためには、ＲＡＵの先頭ピクチャから復号しなければならない。従って、ユーザ操作などにより、Ｐ／Ｉピクチャ以降のピクチャから再生を開始する場合にも、タイムマップからランダムアクセス・ポイントとして指されたＲＡＵの先頭から、ＩピクチャとＰピクチャを少なくとも復号する必要がある。特に、ＲＡＵの再生時間長が長く、ＲＡＵを構成するピクチャの数が増えると、飛び込み位置から再生開始するために復号が必要なピクチャの数が増え、遅延および処理量が増大するという第１の課題がある。
【０１９３】
図４４は、従来のデータ構造の第２の課題について示す。実施の形態１から実施の形態４で述べたように、ＲＡＵの先頭ピクチャがＰ／Ｉピクチャであると、ＲＡＵの先頭のフレーム、あるいはフィールド・ペアのみを再生して高速再生を実現する際の再生品質が低下することから、ＲＡＵの先頭にはＰ／Ｉピクチャを配置しないように規定することがある。ここで、図４４（ａ）に示すように、第１フィールドと第２フィールドの間でシーンチェンジが発生したとする。特殊再生時には、シーンチェンジの発生位置から飛込み再生できることが望ましいため、ＲＡＵを分割することを考えると、ＲＡＵの先頭にはＰ／Ｉピクチャを配置できないことから、図４４（ｂ）に示すようにＲＡＵの先頭ピクチャをＩ／Ｉピクチャとする必要がある。この例のように、第１フィールドと第２フィールドの間でシーンチェンジが発生している際には、第１フィールドについては表示順で前の画像との相関が高いため、Ｐ／Ｉピクチャを使用したほうが符号化効率が向上する。従って、先頭ピクチャをＩ／Ｉピクチャにすることにより符号化効率が低下するという第２の課題がある。
【０１９４】
図４５は、本実施の形態のＲＡＵ構造例を示す。図４５のＲＡＵでは、ＲＡＵの途中のＰ／Ｉピクチャの予測構造について次の制約を設ける。
【０１９５】
・表示順がＰ／Ｉピクチャよりも後であるピクチャは、Ｐ／ＩピクチャにおけるＰピクチャを参照しない。
【０１９６】
これにより、ユーザ操作などにより、Ｐ／Ｉピクチャ以降のピクチャから再生を開始する場合にも、Ｐ／ＩピクチャにおけるＩピクチャから復号開始することにより、Ｐ／Ｉピクチャ以降のピクチャを復号でき、飛び込み再生時の遅延および処理量が軽減できるという効果が得られる。また、逆再生を行う場合にも、Ｐ／Ｉピクチャ以降のピクチャを再生する際に、ＲＡＵの先頭ピクチャから読み込んで復号する必要がなく、Ｐ／ＩピクチャのＩピクチャ、および以降のピクチャのみを読み込めばよいため、逆再生時に必要なバッファメモリのサイズ、あるいは、バッファメモリへのデータ読み込み回数を低減できるという効果が得られる。なお、Ｐ／Ｉピクチャは、通常、第１フィールドと第２フィールドの間でシーンチェンジが発生する際に使用されるため、Ｐ／Ｉピクチャ以降のピクチャと、Ｐ／ＩピクチャにおけるＰピクチャとの相関関係は低く、当該Ｐピクチャへの参照を制約しても符号化効率への影響は軽微である。
【０１９７】
図４６は、本実施の形態のＲＡＵ構造の他の例である。図４５の例では、タイムマップにおいてランダムアクセス・ポイントとして指される位置と、ＲＡＵとが一対一に対応していた。一方、図４６では、タイムマップが指すＮ番目とＮ＋１番目のランダムアクセス・ポイントの間に複数のＲＡＵが存在する。つまり、タイムマップから指されないＲＡＵが存在し、ここでは、ＲＡＵ２はタイムマップから指されない。図４６は、図４５のＲＡＵをＲＡＵ１とＲＡＵ２の２つのＲＡＵに分割したものであり、ＲＡＵの先頭ピクチャはＰ／Ｉピクチャとなる。ここで、ＲＡＵ２の先頭Ｐ／Ｉピクチャ以降のピクチャから再生を開始する場合、ＲＡＵ内の後続ピクチャは先頭Ｐ／ＩピクチャのＰピクチャを参照しないことが保証されるため、先頭Ｐ／ＩピクチャのＩピクチャから復号開始すればよい。
【０１９８】
このように、特殊再生時に復号動作をリセットするポイントとして、Ｐ／Ｉピクチャが使用できる。さらに、Ｐ／Ｉピクチャよりも後のピクチャがＰ／ＩピクチャのＰピクチャを参照しないという制約は、ＲＡＵ内の全てのＰ／Ｉピクチャに対して適用してもよいが、特殊再生時の効率を向上させるには、Ｐ／Ｉピクチャに対して選択的に制約をかければよく、Ｐ／Ｉピクチャに対して制約が適用されるかどうかを示す情報を付加することは有効である。この情報は、符号化ストリーム内に格納してもよいし、管理情報に格納してもよい。図４７は、表示順がＰ／Ｉピクチャよりも後のピクチャがＰ／ＩピクチャのＰピクチャを参照しないという制約が適用されるかどうかを示す情報を符号化ストリーム内に格納した例である。ここでは、ＲＡＵマップと呼ぶマップ情報により当該情報を格納する。図４７（ａ）に示すように、ＲＡＵマップはＲＡＵ内のピクチャデータよりも前に配置される。例えば、ＶＣ−１であればエントリ・ポイントレベルのユーザデータに格納できる。ここで、図４７（ａ）のＲＡＵマップは、図４７（ｂ）のＲＡＵについての情報を示す。図４７（ｂ）のＲＡＵでは、ＲＡＵ内に４つのＰ／Ｉピクチャが存在し、２番目のＰ／Ｉピクチャについてのみ参照関係が制約されている。従って、２番目のＰ／Ｉピクチャは、特殊再生時に復号動作をリセットするポイントとして使用できる。そこで、ＲＡＵマップには、１番目、３番目、４番目のＰ／Ｉピクチャについては参照関係が制約されていることが保証されておらず、２番目のＰ／Ｉピクチャについては参照関係が制約されていることが保証されている、ことが示される。
【０１９９】
図５４は、ＲＡＵマップのシンタックス例である。図５４（ａ）は、ＲＡＵを構成するフレーム、あるいはフィールド・ペアのタイプの一覧を復号順に示したテーブルである。各パラメータの定義は以下の通りとする。
【０２００】
ｎｕｍ＿ｆｒａｍｅ＿ｉｎ＿ＲＡＵ： ＲＡＵを構成するフレーム、あるいはフィールド・ペアの個数
ｆｒａｍｅ＿ｆｌａｇ： フレームであるかフィールド・ペアであるかを判別するフラグ
ｆｒａｍｅ＿ｔｙｐｅ： フレームのタイプ（Ｉフレーム、Ｐフレーム、Ｂフレーム、ＢＩフレーム、Ｓｋｉｐｐｅｄフレームなど）を示す識別子
ｆｉｅｌｄ＿ｐａｉｒ＿ｔｙｐｅ： フィールド・ペアのタイプ（Ｉ／Ｉピクチャ、Ｉ／Ｐピクチャ、Ｐ／Ｉピクチャなど）
【０２０１】
ここで、ｆｉｅｌｄ＿ｐａｉｒ＿ｔｙｐｅにおいて、復号動作がリセットできることが保証されたＰ／Ｉピクチャと、復号動作がリセットできることが保証されていないＰ／Ｉピクチャとで、異なる識別子を用いることにより、両者を区別できる。
【０２０２】
図５４（ｂ）は、ＲＡＵを構成するフレーム、あるいはフィールドのタイプの一覧を復号順に示したテーブルである。各パラメータの定義は以下の通りとする。
【０２０３】
ｎｕｍ＿ｐｉｃｔｕｒｅ＿ｉｎ＿ＲＡＵ： ＲＡＵを構成するフレーム、あるいはフィールドの個数
ｆｒａｍｅ＿ｆｌａｇ： フレームであるかフィールドであるかを判別するフラグ
ｐｉｃｔｕｒｅ＿ｔｙｐｅ： フレーム、あるいはフィールドのタイプ
【０２０４】
ここで、Ｐ／Ｉピクチャの第１フィールドであるＰピクチャについて、復号動作がリセットできることが保証されたＰ／ＩピクチャのＰピクチャと、復号動作がリセットできることが保証されていないＰ／ＩピクチャのＰピクチャとは、ｐｉｃｔｕｒｅ＿ｔｙｐｅにおいて異なる識別子を用いることにより区別される。
【０２０５】
なお、ｆｒａｍｅ＿ｆｌａｇには、フレームであるかフィールドであるかだけではなく、フレームにおけるに３：２プルダウン（テレシネ変換）についての情報などを含めてもよい。
【０２０６】
ＲＡＵ内に復号動作をリセットするポイントを設けることは、ＲＡＵの再生時間長が長い場合に特に有効である。ここで、ＲＡＵの時間長は、Ｉピクチャの間隔に依存し、ＩピクチャはＰピクチャやＢピクチャに比べて符号量が多いため、ＲＡＵの時間長を長くしてＩピクチャの間隔を長くすることにより、結果としてビットレートを低減できる。従って、低ビットレート時にはＲＡＵの時間長を長くすることが有効である。このため、ＲＡＵの再生時間長が所定の値以上、あるいは、符号化ストリームのビットレートが所定の値以下である場合にのみ、Ｐ／Ｉピクチャに対する参照関係の制約を適用する、あるいは、ＲＡＵマップを付加してＰ／Ｉピクチャに対する参照関係の制約があるかどうかを示してもよい。さらに、ＲＡＵの先頭Ｉピクチャのみを再生する高速再生など特殊再生時の再生品質を考慮して、ＲＡＵの再生時間長を所定の時間以下としてもよい。また、タイムマップにより指されるランダムアクセス・ポイント間の表示時刻あるいは復号時刻の差分値を所定の値以下としてもよい。ここで、オープンＧＯＰ型のＲＡＵでは、タイムマップにより指されるＩピクチャの表示時刻よりも、ＲＡＵ内で最初に表示されるＢピクチャなどの表示時刻のほうが早くなることに注意する。
【０２０７】
ＲＡＵ内に複数のＰ／Ｉピクチャが存在する場合には、特殊再生の実現容易性を考慮して、当該Ｐ／Ｉピクチャについて参照関係を制約するかどうかを決定できる。例えば、１秒など所定の単位で、特殊再生時に復号動作がリセットできるポイントを設ける際には、Ｐ／Ｉピクチャ間の表示時刻の差分が前記所定の単位以下となるように、Ｐ／Ｉピクチャについての参照関係を制約できる。
【０２０８】
以下に、図４６のようなケースでも、タイムマップが示す連続した２つのランダムアクセス・ポイントの間に特殊再生時の復号動作をリセットできるポイントが存在するかどうか示す方法を示す。図４８は、タイムマップによりランダムアクセス・ポイントであることが示されるＲＡＵの前にＲＡＵマップを配置して、次のランダムアクセス・ポイントとの間にあるＲＡＵについての情報を示す例である。ここでは、ランダムアクセス・ポイントの間には、２つのＲＡＵが存在し、それぞれの再生時間長が１秒であることが示される。ＲＡＵは、復号動作をリセットするポイントとして使用できるため、各ＲＡＵの再生時間長に基づいて、何番目のＲＡＵから復号を開始すればよいか決定できる。さらに、ＲＡＵマップにおいて、各ＲＡＵマップの先頭がＰ／Ｉピクチャであるかどうかを示してもよい。図４８におけるＲＡＵマップと、図４７に示したＲＡＵ単位のマップ情報とを合わせて使用してもよい。
【０２０９】
（実施の形態６）
本実施の形態６では、実施の形態５で示したデータを生成する画像符号化方法、および画像符号化装置について説明する。
【０２１０】
図４９は、本実施の形態の画像符号化方法において、ピクチャの参照関係を制約するかどうかを判定する際の動作を示すフローチャートである。まず、ステップＳ２００１において、現フレームあるいはフィールド・ペアをＰ／Ｉピクチャとして符号化するかどうか判定し、ステップＳ２００２に進む。ステップＳ２００２では、現フレームあるいはフィールド・ペアがＲＡＵの先頭フレームを構成するピクチャであるかどう判定し、先頭フレームを構成するピクチャであればステップＳ２００３に進み、そうでなければステップＳ２００４に進む。ステップＳ２００３では、現フレームあるいはフィールド・ペアが復号動作をリセットできるピクチャとするかどうか判定し、リセットするピクチャであればステップＳ２００４に進み、そうでなければ処理を終了する。ステップＳ２００４では、ＲＡＵ内において表示順が現Ｐ／Ｉピクチャよりも後であるピクチャが、現Ｐ／ＩピクチャにおけるＰピクチャを参照しないように、後続ピクチャの参照関係を制約すると決定する。なお、全てのＰ／Ｉピクチャを、復号動作がリセットできるピクチャとしてもよい。
【０２１１】
図５０は、ＲＡＵマップをＲＡＵの先頭に付加する際の動作を示すフローチャートである。本フローチャートでは、ＲＡＵマップの生成動作を主に説明し、各ピクチャの符号化動作の詳細については説明を省略する。まず、ステップＳ２１０１では、Ｐ／Ｉピクチャに関連して後続ピクチャの参照関係を制約するかどうか判定する。次に、ステップＳ２１０２では、ステップＳ２１０１で決定した制約を満たすように、ピクチャの参照関係を決定し、ステップＳ２１０３に進む。ステップＳ２１０３では、現ピクチャがＲＡＵの最終ピクチャであるかどうか判定し、最終ピクチャであればステップＳ２１０４に進み、そうでなければ処理を終了する。なお、ステップＳ２０１３では、現ピクチャがＲＡＵ内の最終Ｐ／Ｉピクチャであるかどうか判定してもよい。最後に、ステップＳ２０１４では、Ｐ／Ｉピクチャについての情報を格納したＲＡＵマップを生成し、ＲＡＵを構成するピクチャデータの前に付加する。
【０２１２】
図５１は、本実施の形態の画像符号化方法を実現する画像符号化装置２０００の構成を示すブロック図である。画像符号化装置２０００は、Ｐ／Ｉ制約決定ユニットＰｌｉｍとマップ情報作成ユニットＭａｐＩｎｆｏを新たに備えた点、および予測構造決定ユニットＰＴＹＰＥの動作が異なる点において従来の画像符号化装置１と異なる。Ｐ／Ｉ制約決定ユニットＰｌｉｍは、ステップＳ２００１からステップＳ２００４までの処理を行い、符号化されるピクチャがＰ／Ｉピクチャである際には、ＲＡＵ内の後続ピクチャが当該Ｐ／ＩピクチャのＰピクチャを参照しないとするかどうか決定する。予測構造決定ユニットＰＴＹＰＥは、Ｐ／Ｉ制約決定ユニットＰｌｉｍで決定された条件を満たすように、ピクチャの符号化タイプおよび参照関係などを決定する。一方、マップ情報作成ユニットＭａｐＩｎｆｏは、実施の形態５で述べたＲＡＵマップを生成する。
【０２１３】
（実施の形態７）
本実施の形態７では、実施の形態５で示したデータを復号する画像復号方法、および画像復号装置について説明する。
【０２１４】
図５２は、本実施の形態の画像復号方法における特殊再生時の復号動作を示すフローチャートである。本方法は、ユーザ操作などにより飛び込み再生、あるいは逆再生などを行う際に、復号を開始するピクチャを決定する際に特に有効である。まず、ステップＳ２２０１において、タイムマップにより指されるピクチャとは異なるピクチャ（Ｐｉｃ＿ｓｔ）から再生開始するかどうか判定し、Ｐｉｃ＿ｓｔと異なるピクチャから再生開始する際には、ステップＳ２２０２に進み、そうでなければステップＳ２２０４に進む。ステップＳ２２０２では、Ｐｉｃ＿ｓｔよりも復号順が前である、復号動作をリセットできるＰ／Ｉピクチャ（ＰＩ＿ｓｔ）が存在するかどうか判定する。ここで、判定時には、ＲＡＵマップを参照して、復号順が、
・Ｐｉｃ＿ｓｔよりも前であり、
・タイムマップにより指されるＲＡＵの先頭ピクチャよりも後である、
復号動作がリセットできるＰ／Ｉピクチャを検索する。なお、ＰＩ＿ｓｔは、Ｐｉｃ＿ｓｔよりも復号順が前であり、かつ復号順がＰｉｃ＿ｓｔに最も近いピクチャとする。
【０２１５】
次に、ステップＳ２２０３では、ＰＩ＿ｓｔにおけるＩピクチャから復号開始すると決定する。ステップＳ２２０４では、タイムマップにより指されるＲＡＵの先頭ピクチャから復号開始すると決定する。
【０２１６】
図５３は、本実施の形態の画像復号方法を実現する画像復号装置３０００の構成を示すブロック図である。画像復号装置３０００は、ＰＩ情報取得ユニットＰＩｓｅｌを備える点において従来の画像復号装置３と異なる。
【０２１７】
ユーザ操作などにより特殊再生を指示する信号ＴｒｉｃｋＭｏｄｅがＰＩ情報取得ユニットＰＩｓｅｌに入力されると、ＰＩ情報取得ユニットＰＩｓｅｌは、可変長復号ユニットＶＬＤからＲＡＵマップの情報ＭａｐＩｎｆを取得する。ここで、可変長復号ユニットＶＬＤは、符号化ストリームを解析してＲＡＵマップを取得し、ＰＩ情報取得ユニットＰＩｓｅｌに入力する。さらに、ＰＩ情報取得ユニットＰＩｓｅｌは、ＲＡＵマップの情報ＭａｐＩｎｆを解析して、復号を開始するピクチャを決定し、決定した復号開始ピクチャを示す情報ＳｅｌＰｉｃをストリーム抽出ユニットＥＸＴに入力する。
【０２１８】
（実施の形態８）
さらに、上記各実施の形態で示した画像符号化方法および画像復号方法を実現するためのプログラムを、フレキシブルディスク等の記録媒体に記録するようにすることにより、上記各実施の形態で示した処理を、独立したコンピュータシステムにおいて簡単に実施することが可能となる。
【０２１９】
図４２は、上記各実施の形態の画像符号化方法および画像復号方法を、フレキシブルディスク等の記録媒体に記録されたプログラムを用いて、コンピュータシステムにより実施する場合の説明図である。
【０２２０】
図４２（ｂ）は、フレキシブルディスクの正面からみた外観、断面構造、及びフレキシブルディスクを示し、図４２（ａ）は、記録媒体本体であるフレキシブルディスクの物理フォーマットの例を示している。フレキシブルディスクＦＤはケースＦ内に内蔵され、該ディスクの表面には、同心円状に外周からは内周に向かって複数のトラックＴｒが形成され、各トラックは角度方向に１６のセクタＳｅに分割されている。従って、上記プログラムを格納したフレキシブルディスクでは、上記フレキシブルディスクＦＤ上に割り当てられた領域に、上記プログラムが記録されている。
【０２２１】
また、図４２（ｃ）は、フレキシブルディスクＦＤに上記プログラムの記録再生を行うための構成を示す。画像符号化方法および画像復号方法を実現する上記プログラムをフレキシブルディスクＦＤに記録する場合は、コンピュータシステムＣｓから上記プログラムをフレキシブルディスクドライブを介して書き込む。また、フレキシブルディスク内のプログラムにより画像符号化方法および画像復号方法を実現する上記画像符号化方法および画像復号方法をコンピュータシステム中に構築する場合は、フレキシブルディスクドライブによりプログラムをフレキシブルディスクから読み出し、コンピュータシステムに転送する。
【０２２２】
なお、上記説明では、記録媒体としてフレキシブルディスクを用いて説明を行ったが、光ディスクを用いても同様に行うことができる。また、記録媒体はこれに限らず、ＩＣカード、ＲＯＭカセット等、プログラムを記録できるものであれば同様に実施することができる。
【産業上の利用可能性】
【０２２３】
本発明に係る画像符号化方法および画像復号方法は、ＶＣ−１のストリームを再生する際に、高速や逆再生などの特殊再生機能を備える機器全般に適用することができ、特殊再生機能が重視される光ディスク関連機器において特に有効である。
【図面の簡単な説明】
【０２２４】
【図１】ＨＤ−ＤＶＤのデータ階層図
【図２】ＨＤ−ＤＶＤ上の論理空間の構成図
【図３】ＨＤ−ＤＶＤプレーヤの概要ブロック図
【図４】ＨＤ−ＤＶＤプレーヤの構成ブロック図
【図５】ＨＤ−ＤＶＤのアプリケーション空間の説明図
【図６】ＭＰＥＧストリーム（ＶＯＢ）の構成図
【図７】パックの構成図
【図８】ＡＶストリームとプレーヤ構成の関係を説明する図
【図９】トラックバッファへのＡＶデータ連続供給モデル図
【図１０】ＶＯＢ情報ファイル構成図
【図１１】タイムマップの説明図
【図１２】プレイリストファイルの構成図
【図１３】プレイリストに対応するプログラムファイルの構成図
【図１４】ＢＤディスク全体管理情報ファイルの構成図
【図１５】グローバルイベントハンドラを記録するファイルの構成図
【図１６】タイムイベントの例を説明する図
【図１７】ユーザイベントの例を説明する図
【図１８】グローバルイベントハンドラの例を説明する図
【図１９】仮想マシンの構成図
【図２０】プレーヤ変数テーブルの図
【図２１】イベントハンドラ（タイムイベント）の例を示す図
【図２２】イベントハンドラ（ユーザイベント）の例を示す図
【図２３】プレーヤの基本処理のフローチャート
【図２４】プレイリスト再生処理のフローチャート
【図２５】イベント処理のフローチャート
【図２６】字幕処理のフローチャート
【図２７】ＲＡＵ先頭のＰ／Ｉピクチャを説明する図
【図２８】Ｐ／Ｉピクチャにおける第１の特殊再生例を説明する図
【図２９】Ｐ／Ｉピクチャを特殊再生に使用する際の課題を説明する図
【図３０】タイムマップとＰ／Ｉピクチャの関係図
【図３１】ピクチャタイプ属性を持つタイムマップとＰ／Ｉピクチャの関係図
【図３２】第２フィールドのＩピクチャを参照するＰ／Ｉピクチャの説明図
【図３３】Ｐ／Ｉピクチャにおける第２の特殊再生例を説明する図
【図３４】本発明の実施の形態１のストリーム構造を示す図
【図３５】従来の画像符号化装置の構成を示すブロック図
【図３６】従来の画像復号装置の構成を示すブロック図
【図３７】従来の画像復号装置の動作を示すフローチャート
【図３８】本発明の実施の形態３の画像符号化方法の動作を示すフローチャート
【図３９】本発明の実施の形態３の画像符号化装置の構成を示すブロック図
【図４０】本発明の実施の形態４の画像復号方法の動作を示すフローチャート
【図４１】本発明の実施の形態４の画像復号装置の構成を示すブロック図
【図４２】本発明の画像符号化方法および画像復号方法を実現するためのプログラムを記録した記録媒体
【図４３】従来のデータ構造において、ランダムアクセス単位の途中から再生を開始する場合の課題を示す図
【図４４】従来のデータ構造において、シーンチェンジが発生した場合の課題を示す図
【図４５】本実施の形態５のランダムアクセス単位の第１の構成例を示す図
【図４６】本実施の形態５のランダムアクセス単位の第２の構成例を示す図
【図４７】本実施の形態５において、ランダムアクセス単位の先頭に付加される第１の補助情報について説明する図
【図４８】本実施の形態５において、ランダムアクセス単位の先頭に付加される第２の補助情報について説明する図
【図４９】本実施の形態６の画像符号化方法において、ピクチャの参照関係を制約する際の動作を示すフローチャート
【図５０】本実施の形態６の画像符号化方法の動作を示すフローチャート
【図５１】本実施の形態６の画像符号化装置の構成を示すブロック図
【図５２】本実施の形態７の画像復号方法の動作を示すフローチャート
【図５３】本実施の形態７の画像復号装置の構成を示すブロック図
【図５４】ＲＡＵマップのシンタックス例を示す図
【符号の説明】
【０２２５】
ＬＩＭＩＴ タイプ制限ユニット
ＰＴＹＰＥ 予測構造決定ユニット
ＶＬＣ 可変長符号化ユニット
ＰｉｃＭｅｍ ピクチャメモリ
【特許請求の範囲】
【請求項１】
少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、
前記動画像の符号化データは、１以上のランダムアクセス可能な単位から構成され、
前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、
前記符号化データにおいて前記フィールド・ペアが存在するかどうかを示す識別情報を格納する
ことを特徴とする情報記録媒体。
【請求項２】
前記ランダムアクセス単位には、
ランダムアクセス単位内の双方向予測ピクチャが、復号順で直前のランダムアクセス単位内のピクチャを参照することを禁止した、クローズド型のランダムアクセス単位と、
ランダムアクセス単位内の双方向予測ピクチャが、復号順で直前のランダムアクセス単位内のピクチャを参照することを許容した、オープン型のランダムアクセス単位と、
の２種類があり、
前記識別情報は、前記ランダムアクセス単位がクローズド型であるかどうかを示す情報であり、
前記ランダムアクセス単位がクローズド型である際には、前記ランダムアクセス単位の先頭に前記フィールド・ペアが存在しない
ことを特徴とする請求項１記載の情報記録媒体。
【請求項３】
前記識別情報は、前記符号化ストリームのビットレートが所定の値以下であるかどうかを示す情報である
ことを特徴とする請求項１記載の情報記録媒体。
【請求項４】
前記動画像は再生時刻に応じて複数の再生区間に分割され、前記管理情報は、１以上の前記動画像における１以上の前記再生区間を連続して再生するための情報を格納し、
前記識別情報は、前記管理情報に格納され、前記連続して再生される前記再生区間がシームレスに接続されるかどうかを示し、
前記シームレスに接続されることが示される際には、接続先となる前記再生区間の先頭は前記フィールド・ペアでない
ことを特徴とする請求項１の情報記録媒体。
【請求項５】
前記動画像は再生時刻に応じて複数の再生区間に分割され、前記管理情報は、１以上の前記動画像における１以上の前記再生区間を連続して再生するための情報を格納し、
前記識別情報は、前記管理情報に格納され、前記連続して再生される区間が、それぞれ異なる動画像のストリームに属するかどうかを識別する情報であり、
前記異なる動画ストリームに属することが示される際には、接続先となる前記再生区間の先頭は前記フィールド・ペアでない
ことを特徴とする請求項１の情報記録媒体。
【請求項６】
動画像を１以上のランダムアクセス単位に符号化する画像符号化方法であって、
前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、
前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアであるかどうかを示す情報を作成する補助情報作成ステップと、
前記作成した補助情報と画素を符号化して符号化ストリームを作成する符号化ステップと
を備えることを特徴とした画像符号化方法。
【請求項７】
動画像を１以上のランダムアクセス単位に符号化する画像符号化装置であって、
前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、
前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアであるかどうかを示す情報を作成する補助情報作成手段と、
前記作成した補助情報と画素を符号化して符号化ストリームを作成する符号化手段と、
を備えることを特徴とした画像符号化装置。
【請求項８】
請求項１の情報記録媒体に記録された符号化データを復号して再生する画像復号方法であって、
前記識別情報により、前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアでないことが示される場合に、前記先頭ピクチャにおける第１フィールド、および第２フィールドを、それぞれ１番目と２番目に表示する表示ステップ、
を備えることを特徴とした画像復号方法。
【請求項９】
請求項１の情報記録媒体に記録された符号化データを復号して再生する画像復号装置であって、
前記識別情報により、前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアでないことが示される場合に、前記先頭ピクチャにおける第１フィールド、および第２フィールドを、それぞれ１番目と２番目に表示する表示手段、
を備えることを特徴とした画像復号装置。
【請求項１０】
少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、
前記動画像の符号化データは、１以上のランダムアクセス可能な単位から構成され、
前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、
前記ランダムアクセス単位の先頭とは異なるピクチャが前記フィールド・ペアであるときには、前記ランダムアクセス単位内のピクチャであって、前記フィールド・ペアよりも表示順が後であるピクチャは、前記フィールド・ペアの第１フィールドを参照しないことが保証され、
前記保証されることを示す情報を前記ストリーム内に格納することを特徴とする情報記録媒体。
【請求項１１】
少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、
前記動画像の符号化データは、１以上のランダムアクセス可能な単位から構成され、
前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、
前記ランダムアクセス単位の先頭とは異なるピクチャが前記フィールド・ペアであるときには、前記ランダムアクセス単位内のピクチャであって、前記フィールド・ペアよりも表示順が後であるピクチャは、前記フィールド・ペアの第１フィールドを参照する場合としない場合とがあり、
前記フィールド・ペアよりも表示順が後であるピクチャが、前記フィールド・ペアの第１フィールドを参照するかどうかを示す情報を前記ストリーム内に格納することを特徴とする情報記録媒体。
【請求項１２】
少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、
前記動画像の符号化データは、１以上のピクチャをまとめたグループ化単位が複数連結されたデータであり、
前記管理情報は、ランダムアクセスすることができる前記グループ化単位の一覧情報を格納し、
前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、
前記ストリームは、前記一覧情報から指されない前記グループ化単位の先頭ピクチャが前記フィールド・ペアであるかどうかを示す情報を格納することを特徴とする情報記録媒体。
【請求項１】
少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、
前記動画像の符号化データは、１以上のランダムアクセス可能な単位から構成され、
前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、
前記符号化データにおいて前記フィールド・ペアが存在するかどうかを示す識別情報を格納する
ことを特徴とする情報記録媒体。
【請求項２】
前記ランダムアクセス単位には、
ランダムアクセス単位内の双方向予測ピクチャが、復号順で直前のランダムアクセス単位内のピクチャを参照することを禁止した、クローズド型のランダムアクセス単位と、
ランダムアクセス単位内の双方向予測ピクチャが、復号順で直前のランダムアクセス単位内のピクチャを参照することを許容した、オープン型のランダムアクセス単位と、
の２種類があり、
前記識別情報は、前記ランダムアクセス単位がクローズド型であるかどうかを示す情報であり、
前記ランダムアクセス単位がクローズド型である際には、前記ランダムアクセス単位の先頭に前記フィールド・ペアが存在しない
ことを特徴とする請求項１記載の情報記録媒体。
【請求項３】
前記識別情報は、前記符号化ストリームのビットレートが所定の値以下であるかどうかを示す情報である
ことを特徴とする請求項１記載の情報記録媒体。
【請求項４】
前記動画像は再生時刻に応じて複数の再生区間に分割され、前記管理情報は、１以上の前記動画像における１以上の前記再生区間を連続して再生するための情報を格納し、
前記識別情報は、前記管理情報に格納され、前記連続して再生される前記再生区間がシームレスに接続されるかどうかを示し、
前記シームレスに接続されることが示される際には、接続先となる前記再生区間の先頭は前記フィールド・ペアでない
ことを特徴とする請求項１の情報記録媒体。
【請求項５】
前記動画像は再生時刻に応じて複数の再生区間に分割され、前記管理情報は、１以上の前記動画像における１以上の前記再生区間を連続して再生するための情報を格納し、
前記識別情報は、前記管理情報に格納され、前記連続して再生される区間が、それぞれ異なる動画像のストリームに属するかどうかを識別する情報であり、
前記異なる動画ストリームに属することが示される際には、接続先となる前記再生区間の先頭は前記フィールド・ペアでない
ことを特徴とする請求項１の情報記録媒体。
【請求項６】
動画像を１以上のランダムアクセス単位に符号化する画像符号化方法であって、
前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、
前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアであるかどうかを示す情報を作成する補助情報作成ステップと、
前記作成した補助情報と画素を符号化して符号化ストリームを作成する符号化ステップと
を備えることを特徴とした画像符号化方法。
【請求項７】
動画像を１以上のランダムアクセス単位に符号化する画像符号化装置であって、
前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、
前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアであるかどうかを示す情報を作成する補助情報作成手段と、
前記作成した補助情報と画素を符号化して符号化ストリームを作成する符号化手段と、
を備えることを特徴とした画像符号化装置。
【請求項８】
請求項１の情報記録媒体に記録された符号化データを復号して再生する画像復号方法であって、
前記識別情報により、前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアでないことが示される場合に、前記先頭ピクチャにおける第１フィールド、および第２フィールドを、それぞれ１番目と２番目に表示する表示ステップ、
を備えることを特徴とした画像復号方法。
【請求項９】
請求項１の情報記録媒体に記録された符号化データを復号して再生する画像復号装置であって、
前記識別情報により、前記ランダムアクセス単位の先頭ピクチャが前記フィールド・ペアでないことが示される場合に、前記先頭ピクチャにおける第１フィールド、および第２フィールドを、それぞれ１番目と２番目に表示する表示手段、
を備えることを特徴とした画像復号装置。
【請求項１０】
少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、
前記動画像の符号化データは、１以上のランダムアクセス可能な単位から構成され、
前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、
前記ランダムアクセス単位の先頭とは異なるピクチャが前記フィールド・ペアであるときには、前記ランダムアクセス単位内のピクチャであって、前記フィールド・ペアよりも表示順が後であるピクチャは、前記フィールド・ペアの第１フィールドを参照しないことが保証され、
前記保証されることを示す情報を前記ストリーム内に格納することを特徴とする情報記録媒体。
【請求項１１】
少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、
前記動画像の符号化データは、１以上のランダムアクセス可能な単位から構成され、
前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、
前記ランダムアクセス単位の先頭とは異なるピクチャが前記フィールド・ペアであるときには、前記ランダムアクセス単位内のピクチャであって、前記フィールド・ペアよりも表示順が後であるピクチャは、前記フィールド・ペアの第１フィールドを参照する場合としない場合とがあり、
前記フィールド・ペアよりも表示順が後であるピクチャが、前記フィールド・ペアの第１フィールドを参照するかどうかを示す情報を前記ストリーム内に格納することを特徴とする情報記録媒体。
【請求項１２】
少なくとも動画像の符号化データを多重化したストリームとその管理情報とを記録した情報記録媒体であって、前記管理情報は前記ストリーム内の動画像の再生時刻情報、サイズ情報、およびストリーム内での開始アドレス情報とを記録し、
前記動画像の符号化データは、１以上のピクチャをまとめたグループ化単位が複数連結されたデータであり、
前記管理情報は、ランダムアクセスすることができる前記グループ化単位の一覧情報を格納し、
前記動画像の符号化方式においては、１フレームの画像をフィールド単位で符号化する際に、第１フィールドを前方予測ピクチャとし、第２フィールドを面内符号化ピクチャとして符号化されたフィールド・ペアを使用できる際に、
前記ストリームは、前記一覧情報から指されない前記グループ化単位の先頭ピクチャが前記フィールド・ペアであるかどうかを示す情報を格納することを特徴とする情報記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【図３７】
【図３８】
【図３９】
【図４０】
【図４１】
【図４２】
【図４３】
【図４４】
【図４５】
【図４６】
【図４７】
【図４８】
【図４９】
【図５０】
【図５１】
【図５２】
【図５３】
【図５４】
【公開番号】特開２００６−１５７８５５（Ｐ２００６−１５７８５５Ａ）
【公開日】平成１８年６月１５日（２００６．６．１５）
【国際特許分類】
【出願番号】特願２００５−４９９８１（Ｐ２００５−４９９８１）
【出願日】平成１７年２月２５日（２００５．２．２５）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成１８年６月１５日（２００６．６．１５）
【国際特許分類】
【出願日】平成１７年２月２５日（２００５．２．２５）
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]