JP2010278539A

JP2010278539A - 映像情報再生方法、映像情報再生装置、及び記録媒体

Info

Publication number: JP2010278539A
Application number: JP2009126570A
Authority: JP
Inventors: Tomoaki Ryu; 智明龍
Original assignee: Mitsubishi Electric Corp
Current assignee: Mitsubishi Electric Corp
Priority date: 2009-05-26
Filing date: 2009-05-26
Publication date: 2010-12-09
Anticipated expiration: 2029-05-26
Also published as: JP5604810B2

Abstract

【課題】本発明は、再生映像の品位を落とすことなく早送り映像を立体視表示することが可能な映像記録媒体、映像情報再生装置、映像情報再生方法を提供することを目的とする。
【解決手段】本発明に係る記録媒体は、ベースビュー映像データのアクセスポイントに対応するベースビューＩピクチャーの記録先頭位置から記録終端位置までの領域に、当該ベースビューＩピクチャーに基づいて復号されるノン・ベースビュー映像データのピクチャーの先頭が配置されるよう映像データを記録し、ベースビューＩピクチャーの先頭及び終端を示す位置情報が記述されたインデックスファイルを記録したものである。
【選択図】図１

Description

本発明は、右目用の映像信号および左目用の映像信号により、立体視可能なコンテンツが記録された記録媒体、ならびに当該記録媒体から映像を再生する映像情報再生方法及び映像情報再生装置に関するものである。

映画やドラマなどの映像コンテンツを再生する機器として、ＤＶＤプレーヤーやＢＤプレーヤーがある。これらの映像は二次元の平面映像であるが、近年、２つのカメラで撮影した映像信号により立体視覚効果が得られることを利用した映画等が制作されるようになってきている。このような立体視映像を記録媒体に記録する方法の一例が、下記特許文献に記載されている。

特開平７−１０７４３５

通常の二次元の映像が記録された記録媒体を再生する、ＤＶＤやＢＤ（Ｂｌｕ−ｒａｙＤｉｓｃ）の再生装置において、早送り再生、チャプターサーチ再生といった特殊再生は一般的な機能として認知されている。こうした特殊再生は、ＭＰＥＧ２やＨ．２６４でエンコードされたピクチャーのうち、単一のピクチャーによるデコードが可能なＩ（Ｉｎｔｒａ）ピクチャーの頭出しを行うことで実現される。ＤＶＤやＢＤには、頭出しを行うために必要なＩピクチャーの位置情報が記述されたインデックス情報が記録されており、このインデックス情報に基づいてＩピクチャーの頭出しを行い、特殊再生を実現している。

二次元の映像データの場合、記録媒体に記録された映像データは１本であるのに対し、立体視用の映像データの場合は、右目用の映像データと、左目用の映像データの２本の映像データが記録される。また、右目用、左目用それぞれの映像データに対し、Ｉピクチャーの頭出しを行うための２つのインデックス情報が記録されている。ユーザーが早送り操作を行うと、例えば、右目用のインデックス情報に基づいて、右目用の映像データのＩピクチャーを読み出し、次に、左目用のインデックス情報に基づいて、左目用のＩピクチャーを読み出す。この時、右目用、左目用のＩピクチャーの位置が物理的に異なるため、読み出し装置において２回のシーク動作が必要となる。たとえば、ＢＤの読み出し装置において、５０００セクターのシーク動作には、約３００ｍｓｅｃ程度の時間を要するため、データを読み込む時間も考慮すると、１秒間に１枚程度しかＩピクチャーを表示することができないため、再生映像の品位が劣化してしまう。片目分のＩピクチャーだけを読むことで１秒間に表示するＩピクチャーの枚数を増やすことができるが、早送り中の映像は、立体視ではなく通常の二次元の映像となり、この場合も再生映像の品位が劣化するという問題点があった。

本発明は、上記課題を解決するためになされたものであり、再生映像の品位を落とすことなく早送り映像を立体視表示することが可能な映像記録媒体、映像情報再生装置、映像情報再生方法を提供することを目的とする。

本発明に係る記録媒体は、ベースビュー映像データのアクセスポイントに対応するベースビューＩピクチャーの記録先頭位置から記録終端位置までの領域に、当該ベースビューＩピクチャーに基づいて復号されるノン・ベースビュー映像データのピクチャーの先頭が配置されるよう映像データを記録し、ベースビューＩピクチャーの先頭及び終端を示す位置情報が記述されたインデックスファイルを記録したものである。

本発明に係る記録媒体によれば、早送り等の特殊再生に必要とされる、ベースビュー映像データとノン・ベースビュー映像データの両方のピクチャーを素早く読み出すことが可能であり、立体視の映像表示による早送り再生をすることができる。

本発明の一実施形態に係る映像情報再生装置の構成を概略的に示すブロック図である。本発明の一実施形態に係る記録媒体におけるファイルとディレクトリの構成の一例を示す図である。ｐｌｓｔファイルのシンタックスの一例を示す図である。プレイリストとｓｔｒｅａｍファイルとの関係の一例を示す図である。ｃｌｉｐファイルのシンタックスの一例を示す図である。Ｍｏｖｉｅ．ｔｉｔｌｅファイルのシンタックスの一例を示す図である。ベースビューピクチャーと、ノン・ベースビューピクチャーとの関係の一例を示す図である。ｓｔｒｅａｍファイルを構成するパケットの配列を示す図である。ベースビューＩピクチャーとノン・ベースビューＩピクチャーの配置の一例を示す図である。本発明の一実施形態に係る記録媒体におけるベースビューＩピクチャーとノン・ベースビューのＩピクチャーの配置を示す図である。Ｉピクチャーのデータサイズを示すテーブルの一例を示す図である。本発明の一実施形態に係る記録媒体におけるベースビューＩピクチャーとノン・ベースビューのＩピクチャーの配置を示す図である。ベースビューピクチャーと、ノン・ベースビューピクチャーとの関係の一例を示す図である。本発明の一実施形態に係る記録媒体におけるｃｌｉｐファイルのシンタックスを示す図である。本発明の一実施形態に係る記録媒体におけるベースビューＩピクチャーとノン・ベースビューのＩピクチャーの配置を示す図である。

実施の形態１
図１は、本発明の一実施形態に係る映像情報再生装置の構成の概略を示すブロック図である。図１に示す映像情報再生装置は、立体視表示用コンテンツが記録された記録媒体から読み出されるコンテンツを立体視表示可能な状態で再生する装置である。ここで、記憶媒体としては、ＤＶＤ、ＣＤ、Ｂｌｕ−ｒａｙディスク（ＢＤ）等の光ディスク媒体が想定される。本実施の形態において、記録媒体は、ＢＤ規格に準拠したデータフォーマットを有する光ディスク媒体とする。

図１に示す映像情報再生装置は、記録媒体を再生するための再生部１０と、装置全体の制御を行うＣＰＵ２１と、再生装置を制御するプログラムが格納された不揮発メモリ２２とを有する。再生部１０において、ドライブ１２は光ディスク１１から情報を読み出し、デマルチプレクサ１３に出力する。デマルチプレクサ１３は、読み出されたデータを映像情報、音声情報、字幕グラフィック情報などの各情報に分離し、ビデオデコーダ１４、字幕デコーダ１５、１６、オーディオデコーダ１７にそれぞれ出力する。ビデオデコーダ１４は、立体視用にフォーマットされた映像情報をデコードし、右目用のビデオ出力をビデオ重畳部１８に、左目用のビデオ出力をビデオ重畳部１９に出力する。字幕デコーダ１５は左目用の字幕グラフィック情報をデコードし、ビデオ重畳部１９に出力する。字幕デコーダ１６は右目用字幕グラフィック情報をデコードし、ビデオ重畳部１８に出力する。ビデオ重畳部１８は右目用のビデオ出力と字幕グラフィック情報を重畳し、ビデオ重畳部１９は左目用のビデオ出力と字幕グラフィック情報を重畳し、それぞれデジタル出力変換部１Ａに出力する。デジタル出力変換部１Ａは、オーディオデコーダ１７、ビデオ重畳部１８、１９の出力を外部表示装置（図示せず）に出力するためのＨＤＭＩ信号に変換して出力する。

図２は、光ディスク１１に記録された映像情報の再生に必要なファイルとディレクトリの構成の一例を示す図である。図２において、“Movie.title”ファイルは、最上位の再生単位であるタイトルの制御に必要な情報が記述されたファイルである。図２において、“PLST”は、プレイリスト（ＰｌａｙＬｉｓｔ）の再生制御に必要な情報が記述されたファイルが格納されているPLSTフォルダである。PLSTフォルダ内には、plstファイル“xxx.plst”が複数存在する。ここで、“xxx”は３桁の数字である。図２において、“STREAM”は、映像情報、音声情報、グラフィックス情報などの再生に必要なファイルが格納されるSTREAM（ストリーム）フォルダである。STREAMフォルダ内には、streamファイル“yyy.strm”が複数存在する。ここで、“yyy”は３桁の数字である。なお、streamファイルは、デジタル放送で採用されているＴＳ（トランスポートストリーム）から構成され、固有のパケットＩＤを持つ映像情報、音声情報、グラフィクス情報が重畳されたファイルである。図２において、“CLIP”は、streamファイルの再生制御に必要な情報が記述されたclipファイルが格納されるCLIPフォルダである。CLIPフォルダ内には、clipファイル“zzz.clip”が複数存在する。ここで、“zzz”は３桁の数字である。clipファイルとstreamファイルとは１対１に対応しており、例えば、CLIPフォルダ内にclipファイル“123.clip”が存在する場合、STREAMフォルダ内には、当該Clipファイルに対応するstreamファイル“123.strm”が存在する。

図３は、図２のplstファイル“xxx.plst”のシンタックスの一例を示す図である。図３において、“number_of_stream”は、１つのプレイリスト（ＰｌａｙＬｉｓｔ）の中で再生されるstreamファイルの総数を示す。次の“for”以下のループは“number_of_stream”の数だけ繰り返される。また、このループ内の“stream_file_name”には、再生対象となるstreamファイルのファイル名が記述される。また、“in_time”及び“out_time”には、streamファイルの再生対象となる部分の開始時刻と終了時刻が記述される。これらの時刻は、streamファイルのパケットに付加されたＰＴＳ（ＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅＳｔａｍｐ）に記述される。

図４は、plstファイルによって定義されるプレイリスト（ＰｌａｙＬｉｓｔ）とstreamファイルとの関係の一例を示す図である。図４において、このプレイリストによれば、“001.strm”の“in_time”から“Out_time”までの部分と、“003.strm”の“in_time”から“Out_time”までの部分が順次再生される。

図７は、立体視用の映像データの構成を示す図である。本実施の形態では立体視用の映像データは、ＭＶＣ（ＭｕｌｔｉＶｉｅｗＣｏｄｉｎｇ）により、エンコードされたデータとして説明を行う。図７において、４１は立体視用のベースビューストリーム、４２はノン・ベースビューストリームである。ここで、ベースビューストリーム４１はノン・ベースビューストリーム４２と関係なく独立してデコードが可能である。ベースビューストリームはＨ．２６４と同一の予測ルールに基づいて符号化される。一方、ノン・ベースビューストリーム４２は、ベースビューからのビュー間予測により符号化され、ベースビューストリームのデコード結果を利用してデコードされる。例えば、図７において、ノン・ベースビューＰピクチャー４４は、ベースビューＰピクチャー４３のデコード結果からデコードされる。このようにして、ビュー間の予測を行うことによって、２本の独立したストリームを利用する場合に比較して、２０〜５０％程度のデータサイズを節約することを実現している。また本実施の形態では、説明の便宜上、ベースビューを左目用、ノン・ベースビューを右目用と仮定して説明をする。

図５は、図２のclipファイル“zzz.clip”のシンタックスの一例を示す図である。図５において、clipファイルには、これと対をなすstreamファイルの映像情報及び音声情報などの重畳情報や、ランダムアクセスなどに必要なインデックス情報が記述される。“stream_info()”には、重畳された映像情報、音声情報、グラフィクス情報の属性情報が記述される。“index_info()”には、streamファイルに含まれる各Ｉピクチャーの先頭の時間情報及び位置情報が記述される。“number_of_I”は、streamファイルのベースビューに含まれる、アクセスポイントとして利用されるＩピクチャーの総数を示す。次のforループは、“number_of_I”の数だけ繰り返される。“start_PTS”は、アクセスポイントとなるＩピクチャーに付与されたＰＴＳ（ＰｒｅｓｅｎｔａｔｉｏｎＴｉｍｅＳｔａｍｐ）情報を示す。“relative_byte_base”は、streamファイルの先頭からベースビューに含まれるＩピクチャーの先頭までの相対バイト数を示す。“size_of_I_base”は、streamファイルにおけるベースビューＩピクチャーの先頭から終端までのバイト数を示す。同様に、 “relative_byte_non-base”は、streamファイルの先頭からノン・ベースビュー内のＩピクチャーの先頭までの相対バイト数を示し、“size_of_I_non-base”は、streamファイルにおけるノン・ベースビューのＩピクチャの先頭から終端までのバイト数を示す。

図８は、streamファイルの構成を示す図である。Streamファイルは、ＴＳ（ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ）パケットにより構成されており、ビデオデータ（Ｖ）、オーディオデータ（Ａ）、グラフィクスデータ（Ｇ）のそれぞれに対して、固有のＰＩＤ（ＰａｃｋｅｔＩｄｅｎｔｉｆｉｅｒ）が、割り当てられており、図１のデマルチプレクサ１３において、それぞれのデータ種別毎に分離される。各種別のデータは、再生中枯渇することがないよう交互に配置されている。

図６は、“Movie.title”ファイルのシンタックスを示す図である。“Movie.title”ファイルは、光ディスクがドライブ１２に挿入された際、ＣＰＵ２１が最初に読み出すファイルである。図６において、“number_of_title”は、光ディスクに記録されているタイトルの総数である。次のforループは、“number_of_title”の数だけ繰り返されるループである。このループ内には、それぞれのタイトル中に再生されるプレイリストのファイル名が記述される。再生されるプレイリストのファイル名は、例えば、“123.plst”となる。“next_title_id”は、現在再生しているタイトルの再生が終了したときに、次に再生する“title_id”が記述される。

次に、本実施の形態における、立体視コンテンツの通常再生および、早送り再生を行う手順について説明する。光ディスクがドライブ１２に挿入されると、ＣＰＵ２１は、図６に示す“Movie.title”ファイルを読み出す。次に、ＣＰＵ２１は“title_id”が“0”のプレイリストファイルを読み出す。ここで、ＣＰＵ２１は、再生するプレイリストファイル中に記述されている最初のstreamファイルを抽出し、当該streamファイルに対応するclipファイル（図５）を読み出すようドライブ１２を制御する。ＣＰＵ２１は、プレイリストファイル中の“In_time”に最も近く“In_time”よりも時間的に前のベースビューＩピクチャーをclipファイル中の“index_info()”から検索する。ＣＰＵ２１は、検索したＩピクチャーの“relative_byte_base”に記述された位置からstreamファイルの読み出しを行う。

streamファイルに格納された、左目用のベースビューのデータ、右目用のノン・ベースビューのデータには、右目用の字幕データ、左目用の字幕データが、それぞれ重畳されているものとする。デマルチプレクサ１３は、ＴＳパケットのヘッダに記述されたＰＩＤに基づいて、ビデオデータパケットをビデオデコーダ１４に、オーディオデータをオーディオデコーダ１７に、左目用の字幕データを字幕デコーダ１９に、右目用の字幕データを字幕デコーダ１８に、それぞれ入力する。ビデオデコーダ１４および字幕デコーダ１５の出力はビデオ重畳部１９で重畳され、左目用の映像が生成される。また、ビデオデコーダ１４および字幕デコーダ１６の出力はビデオ重畳部１８で重畳され、右目用の映像が生成される。オーディオデコーダ１７の出力、ビデオ重畳部１８の出力、およびビデオ重畳部１９の出力は、デジタル出力変換部１ＡによってＨＤＭＩ信号に変換され、外部表示装置に送出される。

次に、通常再生時、ユーザーから早送り再生の指令が出された際の動作について説明する。ＣＰＵ２１は、ユーザーからの早送り命令を受け取ると、指令された倍速数にしたがって、次に再生すべきＩピクチャーの再生時間を決定し、clipファイルから当該再生時間に最も近いＩピクチャのＰＴＳ“start_PTS”を検索する。次に、検索された“start_PTS”に対応付けられた、ベースビューＩピクチャの“relative_byte_base”及び“size_of_I_base”を読み出すようドライブ１２に指令を出す。同様にして、再生すべきノン・ベースビューＩピクチャの“relative_byte_non-base”及び“size_of_I_non-base”のデータサイズを読み出すよう、ドライブに指令を出す。

図９は、ベースビューＩピクチャーとノン・ベースビューＩピクチャの一般的な配置を示す図である。図９において、左はファイルの先頭方向であり、右はファイルの末端方向である。Ｉ_ＢはベースビューＩピクチャー、Ｐ_ＢはベースビューＢピクチャー、Ｉ_Ｎはノン・ベースビューのＩピクチャー、Ａはオーディオのデータをそれぞれ示す。図９において、記録媒体上のデータは、ベースビューＩピクチャーの先頭である“Ａ”点から、Ｉピクチャーの終点である“Ｂ”点までのデータを読み出し、次に、ノン・ベースビューのＩピクチャーの先頭である“Ｃ”点から、Ｉピクチャーの終点である“Ｄ”点までのデータを読み出す。

以上のようにして読み出された、ベースビューのＩピクチャ、およびノン・ベースビューのＩピクチャーを含む一連のデータは、デマルチプレクサ１３によって、ベースビューおよびノン・ベースビューそれぞれのＩピクチャーデータのみに分離され、ビデオデコーダ１４によってデコードされる。早送り再生時においては字幕データを読み出すことはできないため、ビデオのみの表示とすることが一般的である。以上の動作を繰り返すことで、早送り再生が行われる。

一般的な２次元映像再生装置の早送り再生において、１秒間に表示されるＩピクチャーの枚数は約２〜３枚程度である。一方、立体視用の映像データが記録された記録媒体を再生する場合、まずベースビューＩピクチャーを読み出し、その後で、ノン・ベースビューＩピクチャーを読み出す必要がある。一般的に、光ディスクが指定されたＩピクチャーの先頭にシークするには３００ｍｓｅｃの時間を要し、シーク後Ｉピクチャーを読み出すには１００ｍｓｅｃ程度を要する。このため、図９に示すように、ベースビューＩピクチャとノン・ベースビューＩピクチャのデータが、他のデータを隔てて記録されている場合、ベースビューＩピクチャーの先頭にシークして当該ベースビューＩピクチャを読み出すのに４００ｍｓｅｃの時間を要し、次に、ノン・ベースＩピクチャの先頭にシークして、当該ノン・ベースビューＩピクチャーを読み出すのに、さらに４００ｍｓｅｃの時間を要する。このため、両方のＩピクチャーを読み出すのに合計８００ｍｓｅｃの時間を要する。その結果、１秒間に表示可能なＩピクチャーは１枚程度となるため、早送り再生時の再生映像は不連続な映像となり、スムーズな早送り再生ができない。ベースビューのＩピクチャーのみを読み出して１秒間に表示するＩピクチャーの数を増やすことも可能であるが、この場合、早送り再生中の映像は２次元映像になってしまう。

図１０は、本実施の形態に係る映像情報再生装置において再生される光ディスク１１のデータ配置構成を示す図である。図９に示すデータ配置構成との違いは、ベースビューＩピクチャーが存在する“Ｘ―Ｙ”の領域に、ノン・ベースビューのＩピクチャーの先頭を配置している点である。ユーザーから早送り再生指示が出されると、ＣＰＵ２１は、“start_PTS”に基づいて、再生すべきＩピクチャーを検索し、検索されたＩピクチャーの“relative_byte_base”の値に基づいてベースビューＩピクチャの先頭位置にアクセスし、データの読み出しを開始する。ここで、ＣＰＵ２１は、“size_of_I-base”によって指定される範囲、すなわち、図１０に示すベースビューＩピクチャーが存在する“Ｘ―Ｙ”の領域を読み出すので、ベースビューＩピクチャと対応するノン・ベースビューＩピクチャとをシーケンシャルに読み出すことができる。このように、ベースビューＩピクチャー読み出後のシーク動作を減らすことにより、１秒あたりに表示可能がＩピクチャーの枚数が増え、立体視を維持したまま、ＤＶＤと同等の早送り再生が可能となる。

立体視に対応したデコードが可能な再生装置においては、ベースビュー及びノン・ベースビューの両方のピクチャーがデコードされるが、立体視に対応していない再生装置においては、ベースビューのピクチャーのみがデコードされる。立体視に対応していない再生装置において、ベースビューＩピクチャーではなく、誤ってノン・ベースビューのＩピクチャーへのアクセスがなされた場合、正常なデコード動作が出来なくなってしまうため、確実にベースビューＩピクチャーにアクセスすることが必要である。図５に示すように、clipファイルは、アクセスポイントとなるＩピクチャー先頭の位置情報を、“relative_byte_base”と“relative_byte_non-base”により、ベースビューＩピクチャーとノン・ベースビューＩピクチャーのそれぞれについて定義している。このため、立体視に対応していない再生装置において、確実にベースビューＩピクチャーの先頭位置を特定し、ベースビューＩピクチャーを読み出すことが可能となる。

実施の形態２
本実施の形態は、“size_of_I_base”のデータ容量を削減するための変形例に係るものである。Ｉピクチャーは約０．５秒あたり１枚挿入されるため、例えば、２時間の映画の場合、約１４０００枚存在することとなる。このため、“size_of_I_base”を４バイトで定義した場合、ベースビューと、ノン・ベースビューの両方で、“size_of_I_base”のデータサイズは、28000×4＝112,000バイトとなる。近年の光ディスクの容量は大容量化してきており、１枚のディスクに記録できる容量は、例えば、Ｂｌｕ−ｒａｙなどでは５０ＧＢに達している。このような大容量ディスクにおいて、数十時間分のコンテンツを記録した場合、“size_of_I_base”のデータサイズは更に大きくなる。このため、“size_of_I_base”の値を、例えば、３ｂｉｔの変換値として表す手法がとられている。図１１は、“size_of_I_base”の変換値を表すテーブル情報の一例を示す図である。図１１において、“size_of_I_base”が“011”の場合、当該Ｉピクチャーの先頭から終端までのバイト数は400001〜600000バイトの間となる。

図１２は、“size_of_I_base”を図１１に示すテーブル変換値を用いて表した場合における、ベースビューＩピクチャーとノン・ベースビューＩピクチャの配置を示す図である。図１２において、“Ｐ−Ｑ”はベースビューＩピクチャーが記録される領域であり、“Ｒ−Ｓ”はノン・ベースビューＩピクチャーが記録される領域であり、“Ｐ−Ｔ”は“size_of_I-base”のテーブル変換値によって表されるベースビューＩピクチャ先頭からのバイト数に対応する領域である。図１１に示すように、ノン・ベースビューＩピクチャーの先頭Ｒは“size_of_I_base”のテーブル変換値によって示される領域内に位置する。先術した通り、早送り再生におけるベースビューＩピクチャーの読み出し時、ドライブ１２は“size_of_I_base”によって示される範囲のデータをシークする。このため、ノン・ベースビューＩピクチャーの先頭が“Ｐ−Ｑ”の領域外に位置する場合であっても、当該先頭をテーブル変換値によって示される終端位置“Ｔ”よりも前に配置することで、ベースビューＩピクチャーとノン・ベースビューＩピクチャーをシーケンシャルに読み出すことができ、立体視を維持した早送り再生が可能となる。

実施の形態３
実施の形態１では、“start_PTS”によって示される、アクセスポイントとなるノン・ベースビューのピクチャーはＩピクチャーであるとして説明をした。しかし、ＭＶＣにおいては、図１３に示すように、アクセスポイントとなるベースビューＩピクチャーに対応するノン・ベースピクチャーをＰピクチャーとする場合がある。Ｐピクチャーの符号量は、Ｉピクチャーの符号量と比較して小さいため、圧縮率が高くなり、限られた容量の記録媒体において、より長時間記録することができるためである。この場合、デコード処理は、ベースビューＩピクチャー５１をデコードした後、そのデコード結果を使用して、ノン・ベースビューＰピクチャー５２をデコードする。以降のデコード順は、図７の場合と同じである。光ディスクのランダムアクセスのための頭出には、Ｉピクチャーを使うことが一般的である。このため、ベースビューＩピクチャーに対応するノン・ベースビューのピクチャーをＰピクチャーとした場合、当該Ｐピクチャーにアクセスするためのインデックス情報（“relative_byte_base”及び“size_of_I_base”に相当する情報）が存在しないため、図５に示すclipファイルのシンタックスでは、立体視を維持した状態で早送り再生を行うことができない。

図１５は、アクセスポイントとなるベースビューＩピクチャーに対応するノン・ベースビューのピクチャーがＰピクチャーである場合のベースビューＩピクチャーとノン・ベースビューＰピクチャーの配置を示す図である。図１５において、“Ｘ−Ｙ”はベースビューＩピクチャーが存在する領域を示し、“Ｚ−Ｗ”は対応するノン・ベースビューＰピクチャーＰ_Ｎ１が存在する領域を示している。図１５に示すように、アクセスポイントとなるノン・ベースビューＰピクチャーＰ_Ｎ１の先頭は、ベースビューＩピクチャーの領域に配置されている。図１４は、ノン・ベースビューのアクセスポイントピクチャーがＰピクチャーである場合のclipファイルのシンタックスである。図６に示すシンタックスとの違いは、“type_of_picture”が追加されている点である。“type_of_picture”は、ノン・ベースビューのアクセスポイントピクチャーがＩピクチャーである場合は“1”に設定され、Ｐピクチャーである場合は“0”に設定される。“type_of_picture”が“0”の場合、ノン・ベースビューＩピクチャーが存在しないので、後段の“relative_byte_non-base”、“size_of_I_non-base”の値は無視される。また、“type_of_picture”が“0”の場合、“size_of_I_-base”の値は、ベースビューＩピクチャーが存在する“Ｘ−Ｙ”の領域を含むデータサイズの値に設定される。

ユーザーから早送り再生の指示が出されると、ＣＰＵ２１は、次に再生すべきベースビューＩピクチャーの“relative_byte_base”にシークし、“size_of_I_base”分のデータを読み出すことで、ベースビューのＩピクチャーと、ノン・ベースビューのＰピクチャーの両方を一度のシーク動作で読み出される。以降の動作については実施の形態１と同じであるため、詳細は説明省略する。

図１４に示すようにclipファイルのシンタックスを変更し、図１５に示すようにデータ配置をすることで、ノン・ベースビューのアクセスポイントがＰピクチャーである場合においても、立体視を維持した早送り再生が可能となる。また、“size_of_I_base”を、図１１に示すテーブル変換値により表した場合においては、Iピクチャーの先頭から、当該Iピクチャーの“size_of_I_base”によって指定されるデータ範囲にノン・ベースビューＰピクチャーの先頭を配置してもよい。

図１４に示すclipのシンタックスにおいては、アクセスポイントとなるノン・ベースビューの先頭がＰピクチャーの場合、“relative_byte_non-base”および“size_of_I_non−base”の値を無視することとしたが、“type_of_picture”を省略し、通常通り、“relative_byte_non-base”の値をストリームファイル先頭からＰピクチャーの先頭までの相対バイト数とし、“size_of_I_non−base”の値をＰピクチャーの総バイト数としてもよい。

１０再生部、１１光ディスク（記録媒体）、１２ドライブ、１３デマルチプレクサ、１４ビデオデコーダ、１５字幕デコーダ、１６字幕デコーダ、１７オーディオデコーダ、１８ビデオ重畳部、１９ビデオ重畳部、１Ａデジタル出力変換部、２１ＣＰＵ（再生制御手段）、２２不揮発メモリ、３１外部表示装置。

Claims

独立して復号可能なベースビュー映像データと、前記ベースビュー映像データに基づいて復号されるノン・ベースビュー映像データにより構成される立体視用映像データが記録された記録媒体であって、
前記ベースビュー映像データのアクセスポイントに対応するベースビューＩピクチャーの記録先頭位置から記録終端位置までの領域に、当該ベースビューＩピクチャーに基づいて復号されるノン・ベースビュー映像データのピクチャーの先頭が配置されるよう映像データを記録し、
前記ベースビューＩピクチャーの先頭及び終端を示す位置情報が記述されたインデックスファイルを記録したことを特徴とした記録媒体。
前記インデックスファイルは、前記ベースビューＩピクチャーに基づいて復号されるノン・ベースビューのピクチャーの先頭及び終端を示す位置情報をさらに含むことを特徴とした請求項１に記載の記録媒体。
前記ベースビューＩピクチャーに基づいて復号されるノン・ベースビューのピクチャーは、Ｉピクチャー又はＰピクチャーであることを特徴とする請求項１に記載の記録媒体。
独立して復号可能なベースビュー映像データと、前記ベースビュー映像データに基づいて復号されるノン・ベースビュー映像データにより構成される立体視用映像データが記録された記録媒体であって、
前記ベースビュー映像データのアクセスポイントに対応するベースビューＩピクチャーより後方に当該ベースビューＩピクチャーに基づいて復号されるノン・ベース映像データのピクチャーを記録し、
前記ベースビューＩピクチャーの記録先頭位置から当該ベースビューＩピクチャーに基づいて復号されるノン・ベースビューのピクチャーの記録先頭位置までの領域を示す情報が記述された前記インデックスファイルを記録したことを特徴とした記録媒体。
前記ベースビューＩピクチャーに基づいて復号されるノン・ベースビューのピクチャーは、Ｉピクチャー又はＰピクチャーであることを特徴とする請求項４に記載の記録媒体。
請求項１又は４に記載の記録媒体を再生する映像情報再生方法であって、
前記インデックスファイルに基づいて、ベースビュー映像データのアクセスポイントに対応するベースビューＩピクチャーの先頭から当該ベースビューＩピクチャーに基づいて復号されるノン・ベースビュー映像データのピクチャーの終端までのデータをシーケンシャルに読み出すことを特徴とする映像情報再生方法。
請求項１又は４に記載の記録媒体を再生する映像情報再生装置であって、
前記記録媒体に記録されたデータを読み出すドライブと、
前記インデックスファイルに基づいて、ベースビュー映像データのアクセスポイントに対応するベースビューＩピクチャーの先頭から、当該ベースビューＩピクチャーに基づいて復号されるノン・ベースビュー映像データのピクチャーの終端までのデータをシーケンシャルに読み出すよう前記ドライブを制御する制御手段と、
を備えることを特徴とする映像情報再生装置。