JP2009505327A - 記録媒体、データ再生方法及び再生装置並びにデータ記録方法及び記録装置 - Google Patents

Abstract

一実施例において、管理データは記録媒体から読み取られる。第２ビデオストリームは、管理データに基づいて第１ビデオストリームと共に選択的にディスプレイされる。第２ビデオストリームは、第１ビデオストリームにより表される第１プレゼンテーションパスに対してピクチャー・イン・ピクチャープレゼンテーションパスを表す。たとえ第２ビデオストリームがディスプレイされなくても、第２ビデオストリームがデコーディングされる。

Description

本発明は、記録媒体、データ再生方法及び再生装置並びにデータ記録方法及び記録装置に関する。

記録媒体として、大容量のデータを記録できる光ディスクが広く使われている。その中でも、最近では、大容量の高画質ビデオデータと高音質のオーディオデータを記録して保存することができる新しい高密度記録媒体、例えば、ブルーレイディスク（ＢＤ：Ｂｌｕ−ｒａｙ Ｄｉｓｃ）と高密度デジタルビデオディスク（ＨＤ−ＤＶＤ：Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）などが開発されている。

次世代記録媒体技術である高密度光学記録媒体は、既存のＤＶＤをはるかに超える容量のデータを記録できる次世代光記録ソリューションで、近年、他のデジタル機器と共にその開発が進行されている。また、高密度記録媒体の規格を応用した光記録／再生装置の開発も始まっている。

高密度記録媒体と光記録／再生装置の開発によって、複数のビデオを同時に再生することが可能になった。しかし、未だ複数のビデオを同時に記録又は再生する効果的な方法は知られていない。

さらに、高密度記録媒体の規格が完全には確立されていないことから、高密度記録媒体を基盤とした完成した光記録／再生装置を開発することは困難である。

本発明は、少なくとも１つのピクチャー・イン・ピクチャー（ｐｉｃｔｕｒｅ−ｉｎ−ｐｉｃｔｕｒｅ）プレゼンテーションパスの再生を管理する方法に関する。

一実施例として、記録媒体から管理データを読み取る。そして、管理データに基づいて第２ビデオストリームを第１ビデオストリームと共に選択的にディスプレイする。第２ビデオストリームは、第１ビデオストリームにより表される第１プレゼンテーションパスに関してピクチャー・イン・ピクチャープレゼンテーションパスを表す。たとえ第２ビデオストリームがディスプレイされなくても、第２ビデオストリームはデコーディングされる。

一実施例として、管理データは、第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを指示するディスプレイ情報を含む。そして、ディスプレイ情報に基づいて第２ビデオストリームはディスプレイされる。

他の実施例として、ディスプレイ情報は、第１ビデオストリームのトリック再生の間に、第２ビデオストリームが再生されるウィンドウをクローズするか否かを指示する。

また、第２ビデオストリームが第１ビデオストリームと同期して再生される場合に、ディスプレイ情報に基づいて第２ビデオストリームを選択的にディスプレイする。

本発明はまた、少なくとも１つのピクチャー・イン・ピクチャープレゼンテーションパスの再生管理のための装置に関する。

装置の一実施例として、ドライバーは、記録媒体からデータ再生のための再生要素を駆動するように構成される。そして、制御部は、ドライバーを制御して記録媒体から管理データを読み取るように構成される。制御部は、管理データに基づく第１ビデオストリームと共に第２ビデオストリームの選択的なディスプレイのために構成される。第２ビデオストリームは、第１ビデオストリームにより表された第１プレゼンテーションパスに関してピクチャー・イン・ピクチャープレゼンテーションパスを表す。装置において、デコーダは、制御部が第２ビデオストリームをディスプレイしなくても第２ビデオストリームをデコーディングするように構成される。

一実施例において、管理データは、第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを指示するディスプレイ情報を含む。そして、制御部は、ディスプレイ情報に基づいて第２ビデオストリームを選択的にディスプレイするように構成される。

他の実施例において、ディスプレイ情報は、第１ビデオストリームのトリック再生の間に、第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを指示する。

さらに他の実施例において、制御部は、第２ビデオストリームが第１ビデオストリームと同期して再生される場合に、ディスプレイ情報に基づいて第２ビデオストリームを選択的に再生するように構成される。

本発明はまた、少なくとも１つのピクチャー・イン・ピクチャープレゼンテーションパスの再生を管理するためのデータ構造を持つ記録媒体に関する。

一実施例において、記録媒体は、データ領域と管理領域を含む。データ領域は、第１ビデオストリームを保存する。第１ビデオストリームは、第１プレゼンテーションパスを表す。管理領域は、第１プレゼンテーションパスに関してピクチャー・イン・ピクチャープレゼンテーションパスの再生を管理するための管理データを保存する。管理データは、第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを指示するディスプレイ情報を含む。第２ビデオストリームは、ピクチャー・イン・ピクチャープレゼンテーションパスを表す。

例えば、ディスプレイ情報は、第１ビデオストリームのトリック再生の間に、第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを指示する。

また、本発明は、記録媒体上に少なくとも１つのピクチャー・イン・ピクチャープレゼンテーションパスの再生を管理するためのデータ構造を記録する方法及び装置に関する。

本発明の実施例によれば、第１ビデオのトリック再生モード時にも、第２ビデオを第１ビデオと一緒に再生することが可能である。コンデンツプロバイダは、第２ビデオのトリック再生フラグを用いて、第１ビデオのトリック再生モード時に再生される第２ビデオを使用者に提供するか否かを定めることができる。したがって、第２ビデオを第１ビデオと一緒に效率的に再生することが可能になることはもちろん、より多様に第２ビデオを具現可能になるという利点がある。

本発明の記録媒体、データ再生方法及び装置並びにデータ記録方法及び装置と関連し、第１ビデオのトリック再生モードにおいて第１ビデオと一緒に第２ビデオを再生することが可能であるということは自明である。第１ビデオのトリック再生モードで再生される第２ビデオを使用者に提供するか否かを制御することが可能になる。これにより、コンテンツプロバイダはより多様なコンテンツを構成し、より多様なコンテンツを使用者が経験できるようにすることができる。

図面符号は、本発明の実施例を具体化し且つ添付の図面を説明するために付するもので、可能な限り、図面全体にわたって同一または類似な部分には同一の図面符号を共通使用する。

以下の詳細な説明において、本発明の実施例は、光ディスクを取り上げて記録媒体について説明し、特に、説明の便宜上、ブルーレイディスク（ＢＤ）を記録媒体の例とする。しかし、それ以外に、ＨＤ−ＤＶＤなどの他の記録媒体にも本発明の技術思想が同一に適用可能であることは明らかである。

実施例において使用される“ストレージ（ｓｔｏｒａｇｅ）”は、光記録／再生装置（図１）内に備えられた一種の記憶手段であり、必要な情報及びデータを使用者が任意に保存し、後で使用できるようにする要素である。一般的に使用されるストレージの例には、ハードディスク、システムメモリー、フラッシュメモリーなどがあるが、これらに本発明が限定されるものではない。

本発明において、“ストレージ”は、記録媒体（例えば、ＢＤ）と関連したデータを保存する手段としても用いられ、通常、当該記録媒体と関連してストレージ中に保存されるデータは、外部からダウンロードしたデータである。

このようなデータに関しては、記録媒体から一部許容されたデータを直接読み取り、または、記録媒体の記録再生と関連したシステムデータ（例えば、メタデータ）を生成し、これらをストレージ内に保存することも可能であることは自明である。

本発明では、説明の便宜上、記録媒体内に記録されたデータを“オリジナルデータ（ｏｒｉｇｉｎａｌ ｄａｔａ）”と呼び、ストレージ内に保存されたデータのうち、記録媒体と関連したデータを“アディショナルデータ（ａｄｄｉｔｉｏｎａｌ ｄａｔａ）”と呼ぶ。

また、本発明において“タイトル（ｔｉｔｌｅ）”とは、使用者とのインターフェースをなす再生単位のことをいう。それぞれのタイトルは、特定のオブジェクト（Ｏｂｊｅｃｔ）とリンクされている。したがって、タイトルとリンクされているオブジェクト（Ｏｂｊｅｃｔ）内のコマンド（ｃｏｍｍａｎｄ）あるいはプログラムによって、ディスク内に記録された該当のタイトルに関するストリームが再生される。特に、説明の便宜上、ＭＰＥＧ圧縮方式によってビデオデータを含むタイトルのうち、連続したマルチ−アングル（ｍｕｌｔｉ−ａｎｇｌｅ）、マルチストーリー（ｍｕｌｔｉ ｓｔｏｒｙ）、ランゲージクレジット（ｌａｎｇｕａｇｅ ｃｒｅｄｉｔｓ）、ディレクターズカット（ｄｉｒｅｃｔｏｒ’ｓ ｃｕｔｓ）、トリロジーコレクション（ｔｒｉｌｏｇｙ ｃｏｌｌｅｃｔｉｏｎｓ）などを提供するタイトルを“ＨＤＭＶ（Ｈｉｇｈ Ｄｅｆｉｎｉｔｉｏｎ Ｍｏｖｉｅ）タイトル（ＨＤＭＶ ｔｉｔｌｅｓ）”と呼ぶ。また、ＭＰＥＧ圧縮方式によってビデオデータを含むタイトルのうち、ネットワークとの連結性を支援して高いインタラクティビティを可能にする、完全にプログラムされたアプリケーション環境を提供するタイトルを“ＢＤ−Jタイトル（ＢＤ−Ｊ ｔｉｔｌｅ）”と呼ぶ。

図１は、本発明の光記録／再生装置と周辺機器との統合的使用の一実施例を示す図である。

本発明の一実施例による光記録／再生装置１０は、様々な規格の光ディスクを記録又は再生することができる。必要に応じて、光記録／再生装置１０は、特定規格（例えば、ＢＤ）の光ディスクのみを記録／再生するように設計されても良く、または、記録機能は排除し、再生機能だけを持つようにしても良い。ただし、以下では、本発明で解決しようとするブルーレイディスク（ＢＤ）と周辺機器との連係性を考慮し、ブルーレイディスク（ＢＤ）を再生するＢＤ−プレーヤー（ＢＤ−Ｐｌａｙｅｒ）またはブルーレイディスク（ＢＤ）を記録／再生するＢＤ−レコーダー（ＢＤ−Ｒｅｃｏｒｄｅｒ）を取り上げて説明する。本発明の光記録／再生装置１０は、コンピュータなどに搭載可能なドライブ（ｄｒｉｖｅ）になりうることは、周知の事実である。

本発明の光記録／再生装置１０は、光ディスク３０を記録／再生する機能の他にも、外部入力信号を受信しこれを信号処理した後、外部ディスプレイ２０を介して使用者に画像(ｖｉｓｉｂｌｅ ｉｍａｇｅ)として伝達する機能を有する。この場合、入力可能な外部信号に特に制限はないが、その代表には、デジタル放送（Ｄｉｇｉｔａｌ ｍｕｌｔｉｍｅｄｉａ ｂｒｏａｄｃａｓｔｉｎｇ）信号及びインターネット信号などが挙げられる。特に、インターネット基盤の信号に関しては、インターネットは誰でも容易にアクセス可能な媒体であるため、インターネット上の所望のデータは、光記録／再生装置１０を介してダウンロードした後、使用可能である。

下記の説明において、外部ソース（ｅｘｔｅｒｎａｌ ｓｏｕｒｃｅ）としてコンテンツ（ｃｏｎｔｅｎｔ）を提供する者を総称して“コンテンツプロバイダ（ＣＰ:ｃｏｎｔｅｎｔ ｐｒｏｖｉｄｅｒ）”とする。

本発明で使われる“コンテンツ（ｃｏｎｔｅｎｔ）”という言葉は、タイトルを構成する内容で、記録媒体の製作者により提供されるデータを意味する。

オリジナルデータとアディショナルデータについて具体的に説明すれば、次の通りである。例えば、特定タイトルのマルチプレクシングされた（ｍｕｌｔｉｐｌｅｘｅｄ）ＡＶストリームは、光ディスクのオリジナルデータとして光ディスク内に記録される。この場合、オリジナルデータのオーディオストリーム（例えば、英語）と異なるオーディオストリーム（例えば、韓国語オーディオストリーム）を、インターネットを介してアディショナルデータとして提供することができる。使用者によっては、インターネット上からアディショナルデータに対応するオーディオストリーム（例えば、韓国語オーディオストリーム）のダウンロードを所望し、これをオリジナルデータに対応するＡＶストリームと一緒に再生することを所望し、または、アディショナルデータのみを再生することを所望することができる。これを可能にするためには、オリジナルデータとアディショナルデータとの連関性を規定し、この規定に基づいて使用者の要求で、オリジナルデータとアディショナルデータを管理／再生する体系化した方法が必要となる。

上述の如く、説明の便宜上、ディスク内に記録された信号を“オリジナルデータ（ｏｒｉｇｉｎａｌ ｄａｔａ）”と呼び、ディスクの外部に存在する信号を“アディショナルデータ（ａｄｄｉｔｉｏｎａｌ ｄａｔａ）”と呼ぶこととしたが、これらは、データを取得する方法によって区分されるだけで、オリジナルデータとアディショナルデータが必ずしも特定のデータに限定されることはない。オリジナルデータが記録されている光ディスクの外部に存在しながらオリジナルデータと関連しているものであれば、いかなる属性のデータもアディショナルデータとして使用されることができる。

使用者の上記の要求を実現可能にするには、オリジナルデータとアディショナルデータ相互間に関連したファイル構造が存在しなくてはならない。以下、ブルーレイディスク（ＢＤ）で使用可能なファイル構造及びデータ記録構造について、図２及び図３を用いて詳細に説明する。

図２は、本発明の一実施例による、ブルーレイディスク（ＢＤ）内に記録されたオリジナルデータの再生／管理のためのファイル構造を示す。

本発明のファイル構造は、１つのルートディレクトリと、ルートディレクトリの下に少なくとも１つ以上のＢＤＭＶディレクトリＢＤＭＶが存在する。ＢＤＭＶディレクトリＢＤＭＶには、使用者とのインタラクティビティ（ｉｎｔｅｒａｃｔｉｖｉｔｙ）を保障するための情報を持つ一般ファイル（上位ファイル）としてインデックスファイル“ｉｎｄｅｘ．ｂｄｍｖ”とオブジェクトファイル“ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ”とが存在する。また、本発明のファイル構造は、ディスク内に実際に記録されたデータに関する情報と、これを再生する方法に関する情報、すなわちプレイリストディレクトリであるＰＬＡＹＬＩＳＴ、クリップインフォメーションディレクトリであるＣＬＩＰＩＮＦ、ストリームディレクトリであるＳＴＲＥＡＭ、補助ディレクトリであるＡＵＸＤＡＴＡ、ＢＤ−ＪディレクトリであるＢＤＪＯ、メタデータディレクトリであるＭＥＴＡ、バックアップディレクトリであるＢＡＣＫＵＰ、及びＪＡＲディレクトリを含む。以下、上記のディレクトリ及びこれらのディレクトリ内に含まれるファイルについて詳細に説明する。

ＪＡＲディレクトリは、ジャバ（ＪＡＶＡ（登録商標））プログラムファイルを含む。

メタデータディレクトリであるＭＥＴＡは、データについてのデータ（ｄａｔａ ａｂｏｕｔ ａ ｄａｔａ）のファイル、すなわち、メタデータファイルを含む。このようなメタデータファイルは、検索ファイルとディスクライブラリー（ｄｉｓｃ ｌｉｂｒａｒｙ）のためのメタデータファイルとを含むことができ、データの記録／再生時にデータの効率的検索及び管理に用いられる。

ＢＤ−ＪディレクトリＢＤＪＯは、ＢＤ−Ｊタイトルを再生するためのＢＤ−Ｊオブジェクトファイルを含む。

補助ディレクトリＡＵＸＤＡＴＡは、ディスク再生に必要な付加的なデータファイルを含む。例えば、補助ディレクトリＡＵＸＤＡＴＡには、インタラクティブグラフィック（ｉｎｔｅｒａｃｔｉｖｅ ｇｒａｐｈｉｃｓ）機能の実行時にサウンドデータを提供するための“Ｓｏｕｎｄ．ｂｄｍｖ”ファイル、ディスク再生時にフォント（ｆｏｎｔ）情報を提供するための“１１１１１．ｏｔｆ”及び”“９９９９９．ｏｔｆ”ファイルを含めることができる。

ストリームディレクトリであるＳＴＲＥＡＭは、特定フォーマットによってディスク内に記録された複数のＡＶストリームファイルを含む。最も一般的に、このようなストリームは、ＭＰＥＧ−２に基づくトランスポート（ｔｒａｎｓｐｏｒｔ）パケット（ｐａｃｋｅｔｓ）の形態で記録される。ストリームディレクトリＳＴＲＥＡＭは、ストリームファイルの拡張名として“＊．ｍ２ｔｓ”（例えば、０１０００．ｍ２ｔｓ，０２０００．ｍ２ｔｓ，…）を使用する。特に、ビデオ／オーディオ／グラフィック情報のマルチプレクシングされたストリームを“ＡＶストリーム”という。タイトルは、少なくとも１つのＡＶストリームファイルで構成される。

クリップインフォメーション（クリップ−インフォ）ディレクトリであるＣＬＩＰＩＮＦは、ストリームディレクトリＳＴＲＥＡＭに含まれたストリームファイル“＊．ｍ２ｔｓ”とそれぞれ対応するクリップ−インフォファイル０１０００．ｃｌｐｉ、０２０００．ｃｌｐｉ、…を含む。特に、クリップ−インフォファイル“＊．ｃｌｐｉ”は、ストリームファイル“＊．ｍ２ｔｓ”の属性情報及びタイミング情報（ｔｉｍｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）を記録する。各クリップ−インフォファイル“＊．ｃｌｐｉ”とクリップ−インフォファイル“＊．ｃｌｐｉ”に対応するストリームファイル“＊．ｍ２ｔｓ”とを集合的に“クリップ（ｃｌｉｐ）”と命名する。すなわち、クリップは、ストリームファイル“＊．ｍ２ｔｓ”とこれに対応するクリップ−インフォファイル“＊．ｃｌｐｉ”とを全て含むデータを示す。

プレイリストディレクトリＰＬＡＹＬＩＳＴは、複数のプレイリストファイル“＊．ｍｐｌｓ”を含む。“プレイリスト（ｐｌａｙｌｉｓｔ）”は、クリップの再生区間の組み合わせを意味する。各再生区間は、“プレイアイテム（ｐｌａｙｉｔｅｍ）”という。それぞれのプレイリストファイル“＊．ｍｐｌｓ”は、少なくとも１つのプレイアイテム及びサブプレイアイテム（ｓｕｂｐｌａｙｉｔｅｍ）を含む。プレイアイテム及びサブプレイアイテムは、再生を希望する特定クリップの再生開始時間（ＩＮ−Ｔｉｍｅ）と再生終了時間（ＯＵＴ−Ｔｉｍｅ）に関する情報を含む。したがって、プレイリストは、プレイアイテムの組み合わせといえる。

プレイリストファイルと関連し、プレイリストファイル内で少なくとも１つのプレイアイテムを用いてデータを再生する過程を“メインパス（ｍａｉｎ ｐａｔｈ）”といい、１つのサブプレイアイテムを用いてデータを再生する過程を“サブパス（ｓｕｂ ｐａｔｈ）”という。メインパスは、関連したプレイリストのマスタープレゼンテーションを提供し、サブパスは、マスタープレゼンテーションと関連した補助的なプレゼンテーションを提供する。各プレイリストファイルは、１つのメインパスを含まなければならない。また、各プレイリストファイルは、少なくとも１つのサブパスを含み、その数はサブプレイアイテムの存在または不在によって決定される。したがって、各プレイリストファイルは、１つ以上のプレイアイテムの組み合わせに基づいて所望のクリップの再生のための全体再生／管理ファイル構造内の基本的再生／管理ファイル単位となる。

本発明と関連して、メインパスを通じて再生されるビデオデータを第１ビデオといい、サブパスを通じて再生されるビデオデータを第２ビデオという。また、第１ビデオと第２ビデオを同時に再生するための光記録／再生装置の機能を“ピクチャー・イン・ピクチャー（ｐｉｐ:ｐｉｃｔｕｒｅ−ｉｎ−ｐｉｃｔｕｒｅ）”と呼ぶ。これと関連して、第１ビデオが正常な再生速度以外の速度で順方向または逆方向に再生される場合、すなわち、第１ビデオのトリック再生モード時に第２ビデオをどのように再生するかが問題となる。本発明の実施例は、第１ビデオのトリック再生モード時に効果的に利用可能な第２ビデオ再生方法を提供する。これは、図７及び以下の図面で具体的に説明される。

バックアップディレクトリＢＡＣＫＵＰは、上に説明したファイル構造内のファイルのコピーを保存する。特に、ディスク再生と関連した情報が記録されるファイルのコピー、例えば、インデックスファイル“ｉｎｄｅｘ．ｂｄｍｖ”、オブジェクトファイル“ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ”及び”ＢＤ−ＪＯｂｊｅｃｔ．ｂｄｍｖ”、ユニットキーファイル、プレイリストディレクトリＰＬＡＹＬＩＳＴ内の全てのプレイリストファイル“＊．ｍｐｌｓ”及びクリップ−インフォディレクトリＣＬＩＰＩＮＦ内の全てのクリップ−インフォファイル“＊．ｃｌｐｉ”に対するコピーファイルを保存する。これは、上記ファイルが損失するとディスク再生に致命的なことになるのを考慮し、あらかじめバックアップ用にファイルのコピーを別に保存しておくためである。

一方、本発明のファイル構造が、説明した名称及び位置に必ずしも制限されないことは自明である。すなわち、上記のディレクトリ及びファイルは、その名称及び位置によって把握されてはならず、その意味によって把握されるべきである。

図３は、本発明の一実施例による光ディスクのデータ記録構造を示す図である。図３には、ディスク内にファイル構造と関連した情報の記録構造を示す。図３を参照すると、ディスクは、全体ファイルを管理するためのシステム情報が記録されたファイルシステム情報領域と、インデックスファイル、オブジェクトファイル、プレイリストファイル、クリップ−インフォファイル及びメタデータファイルが記録された領域（記録されたストリーム“＊．ｍ２ｔｓ”を再生するための領域）、それぞれオーディオ／ビデオ／グラフィックデータで構成されたストリームまたはストリームファイルが記録されるストリーム領域と、ジャワプログラムファイルが記録されるＪＡＲ領域が存在することがわかる。ディスクの内周から見るとき、これらの領域は上記した順序で配列される。

第１ビデオ及び／または第２ビデオのストリームデータは、ストリーム領域に保存される。第２ビデオは、第１ビデオと同じストリームにマルチプレクシングされても良く、第１ビデオと異なるストリームにマルチプレクシングされても良い。

ディスク内には、ストリーム領域内のコンテンツ（ｃｏｎｔｅｎｔｓ）の再生のためのファイル情報を記録する領域が存在する。この領域を“管理領域（ｍａｎａｇｅｍｅｎｔ ａｒｅａ）”といい、ファイルシステム情報領域とデータベース領域がこれに含まれる。本発明によれば、サブパスは、第２ビデオを再生するために使われる。サブパスは、第２ビデオがマルチプレクシングされるストリームの種類と、メインパスと同期されるか否かによって３種類に分類することができる。３つのサブパスの種類は、図８Ａ乃至図８Ｃを参照して説明される。サブパスの種類によって第２ビデオの再生方法が変わるので、管理領域はサブパス種類を表す情報を含むことになる。一方、本発明の実施例では、第１ビデオのトリック再生モード時の第２ビデオ再生と関連したフラグ（ｆｌａｇ）を管理領域に保存する。フラグは、第２ビデオの再生を管理するメタデータに含まれる。

図３の各領域は１つの例に過ぎず、本発明が図３のような各領域の配列構造に限定されることはない。

図４は、本発明の実施例による第２ビデオに関する概念的理解のために示す図である。

本発明は、第２ビデオデータを第１ビデオデータと同時に再生する方法を提供する。

例えば、本発明は、ＰｉＰアプリケーションが可能であり、特に、効率的にＰｉＰアプリケーションを行うことができる光記録／再生装置を提供する。

図４を参照すると、第１ビデオ４１０の再生の間に、第１ビデオ４１０と同じディスプレイ２０に、第１ビデオ４１０と関連した他のビデオデータを出力する必要がある場合がある。このようなＰｉＰアプリケーションを本発明によって達成することができる。

例えば、映画またはドキュメンタリーの再生中に、撮影過程に対する監督のコメントまたはエピソードを共に使用者に提供することが可能である。この場合において、コメントまたはエピソードのビデオは、第２ビデオ４２０である。第２ビデオ４２０は、第１ビデオ４１０の再生開始時から第１ビデオ４１０と同時に再生されることができる。

第２ビデオ４２０の再生は、第１ビデオ４１０の再生中に始まることもできる。また、第２ビデオ４２０は、再生順序によって画面上でその位置または大きさを変更しながらディスプレイされることも可能である。また、複数の第２ビデオ４２０が構成されても良い。

この場合に、第１ビデオ４１０の再生の間に、互いに分離されたまま第２ビデオ４２０を再生することができる。第１ビデオは、関連したオーディオ４１０ａと共に再生することができる。同様に、第２ビデオ４２０は、関連したオーディオ４２０ｂと共に再生することができる。

これと関連して、本発明の実施例は、もし第１ビデオ４１０が正常な再生速度ではない再生速度で再生される場合に、すなわち、第１ビデオ４１０がトリック再生モードに該当する場合に、第２ビデオ４２０がどのように処理されるべきかを決定するために提供される。すなわち、本発明の実施例は、第１ビデオのトリック再生にかかわらずにサブパスを通じて第２ビデオ４２０の再生を続けるか、すなわち、第２ビデオ４２０が出力されるウィンドウをオープン状態に維持するか、閉じるべきかを定義するために提供される。

図５は、本発明による光記録／再生装置１０の全体構成に関する一実施例を示す図である。

図５に示すように、光記録／再生装置１０は、主に、ピックアップ１１、サーボ１４、信号処理部１３及びマイコン１６を含む。ピックアップ１１は、光ディスクに記録されたオリジナルデータ及び管理データ（ｍａｎａｇｅｍｅｎｔ ｄａｔａ）を再生する。管理データは、再生管理ファイル情報を含む。サーボ１４は、ピックアップ１１の作動を制御する。信号処理部１３は、ピックアップ１１から再生信号を受信し、受信した再生信号を所望の信号値に復元する。また、信号処理部１３は、記録された信号、例えば第１ビデオと第２ビデオを、光ディスクに記録される信号にそれぞれ変調（ｍｏｄｕｌａｔｉｏｎ）する。マイコン１６は、ピックアップ１１、サーボ１４及び信号処理部１３の動作を制御する。ピックアップ１１、サーボ１４、信号処理部１３及びマイコン１６を総称して“記録／再生ユニット（ｒｅｃｏｒｄｉｎｇ／ｒｅｐｒｏｄｕｃｉｎｇ ｕｎｉｔ）”とする。本発明において、記録／再生ユニットは、制御部１２の制御によって光ディスク３０またはストレージ１５からデータを読み取ってＡＶデコーダ１７ｂに提供する。すなわち、記録／再生ユニットは、再生の観点ではデータを読み込む読取部（ｒｅａｄｅｒ ｕｎｉｔ）の役割を果たす。また、記録／再生ユニットは、ＡＶエンコーダ１８によりエンコーディングされた信号を受信し、受信した信号を光ディスク３０に記録する。したがって、記録／再生ユニットは、光ディスク３０にビデオ及びオーディオデータを記録できる。

制御部１２は、使用者の命令によって光ディスク３０の外部に存在するアディショナルデータをダウンロードしこれをストレージ１５に保存する。ストレージ１５内に保存されたアディショナルデータ及び／または光ディスク３０内のオリジナルデータを、使用者の要求に応じて再生する。本発明において制御部１２は、第２ビデオのトリック再生と関連した情報を生成してビデオデータと一緒に光ディスク３０内に記録するための制御操作を行う。この情報は、光ディスク３０内に記録されることができ、より正確には、第２ビデオの再生を管理するためのメタデータ内に含まれることができる。

光記録／再生装置１０は、制御部１２の制御によってデータをデコーディングし、使用者にデコーディングされたデータを提供する再生システム１７をさらに含む。再生システム１７は、ＡＶ信号をデコーディングするＡＶデコーダ１７ｂを含む。また、再生システム１７は、特定タイトルの再生と関連してオブジェクトコマンドまたはアプリケーションと制御部１２を通じて入力される使用者命令を分析し、分析結果に基づいて再生方向を決定するプレーヤーモデル１７ａを含む。実施例において、プレーヤーモデル１７ａはＡＶデコーダ１７ｂを含む意味として使われることができる。この場合、再生システム１７それ自体がプレーヤーモデルになる。ＡＶデコーダ１７ｂは、それぞれ異なる種類の信号と関連した複数のデコーダを含むことができる。

また、本発明の光記録／再生装置１０に含まれたＡＶエンコーダ１８は、光ディスク３０に入力信号を記録できるように、入力信号を特定フォーマットの信号、例えば、ＭＰＥＧ２トランスポートストリームに変換して信号処理部１３に提供する。

図６は、本発明の一実施例による再生システムを説明するために示す図である。本発明によれば、再生システムは第１ビデオと第２ビデオを一緒に再生することができる。“再生システム（ｐｌａｙｂａｃｋ ｓｙｓｔｅｍ）”は、光記録／再生装置内に備えられるプログラム（ソフトウェア）及び／またはハードウェアで構成される集合的再生処理手段を意味する。すなわち、再生システムは、光記録／再生装置内にローディングされた記録媒体を再生することはもちろん、記録媒体に関連して装置のストレージ内に保存された（例えば、記録媒体の外部からダウンロードした）データを再生及び管理できるシステムである。

特に、図６に示すように、再生システム１７は、使用者イベントマネジャー（ｕｓｅｒ ｅｖｅｎｔ ｍａｎａｇｅｒ）１７１、モジュールマネジャー（ｍｏｄｕｌｅ ｍａｎａｇｅｒ）１７２、メタデータマネジャー１７３、ＨＤＭＶモジュール（ＨＤＭＶ ｍｏｄｕｌｅ）１７４、ＢＤ−Ｊモジュール（ＢＤ−Ｊ ｍｏｄｕｌｅ）１７５、再生制御エンジン（ｐｌａｙｂａｃｋ ｃｏｎｔｒｏｌ ｅｎｇｉｎｅ）１７６、再生エンジン（ｐｒｅｓｅｎｔａｔｉｏｎ ｅｎｇｉｎｅ）１７７及び仮想ファイルシステム（ｖｉｒｔｕａｌ ｆｉｌｅ ｓｙｓｔｅｍ）４０を含む。この構成について詳細に説明すると、次の通りである。

ＨＤＭＶタイトルとＢＤ−Ｊタイトルの再生のための別の再生処理／管理手段として、ＨＤＭＶタイトルのためのＨＤＭＶモジュール１７４とＢＤ−ＪタイトルのためのＢＤ−Ｊモジュール１７５がお互い独立して構成される。ＨＤＭＶモジュール１７４及びＢＤ−Ｊモジュール１７５のそれぞれは、関連したオブジェクト“Ｍｏｖｉｅ Ｏｂｊｅｃｔ”または“ＢＤ−Ｊ Ｏｂｊｅｃｔ”内に含まれたコマンドあるいはプログラムを受信し、これを処理する制御機能を有する。ＨＤＭＶモジュール１７４とＢＤ−Ｊモジュール１７５はそれぞれ、再生システムのハードウェア的構成からコマンドあるいはアプリケーションを分離し、コマンドあるいはアプリケーションの移動を可能にする。コマンドを受信して処理するためにＨＤＭＶモジュール１７４は、コマンドプロセッサ（ｃｏｍｍａｎｄ ｐｒｏｃｅｓｓｏｒ）１７４ａを含む。アプリケーションを受信して処理するためにＢＤ−Ｊモジュール１７５は、Ｊａｖａ（登録商標）ＶＭ（Jａvａ（登録商標） Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ）１７５ａ及びアプリケーションマネジャー（Ａｐｐｌｉｃａｔｉｏｎ ｍａｎａｇｅｒ）１７５ｂを含む。

Ｊａｖａ（登録商標）ＶＭ１７５ａは、アプリケーションが実行されるバーチャルマシン（ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）である。アプリケーションマネジャー１７５ｂは、ＢＤ−Ｊモジュール１７５で行なわれるアプリケーションのライフサイクル（ｌｉｆｅ ｃｙｃｌｅ）を管理するアプリケーション管理機能を含む。

モジュールマネジャー１７２はそれぞれ、ＨＤＭＶモジュール１７４及びＢＤ−Ｊモジュール１７５に使用者命令を伝達するだけでなく、ＨＤＭＶモジュール１７４及びＢＤ−Ｊモジュール１７５の動作を制御する機能を果たす。

再生制御エンジン１７６は、ＨＤＭＶモジュール１７４及びＢＤ−Ｊモジュール１７５の再生命令によって実際ディスク内に記録されたプレイリストファイルを解析し、それに基づいて再生機能を行う。再生エンジン１７７は、再生制御エンジン１７６により再生と関連して管理される特定ストリームをデコーディングし、画面内にディスプレイする。特に、再生制御エンジン１７６は、全ての再生作業を管理する再生制御機能（ｐｌａｙｂａｃｋ ｃｏｎｔｒｏｌ ｆｕｎｃｔｉｏｎｓ）１７６ａと、プレーヤーの再生状態と再生環境（ｐｌａｙｅｒ ｓｔａｔｕｓ ｒｅｇｉｓｔｅｒｓ（ＰＳＲｓ）及びｇｅｎｅｒａｌ ｐｕｒｐｏｓｅ ｒｅｇｉｓｔｅｒｓ（ＧＰＲｓ）の情報）に関する情報を保存するためのプレーヤーレジスタ（ｐｌａｙｅｒ ｒｅｇｉｓｔｅｒｓ）１７６ｂとを含む。場合によっては、再生制御機能１７６ａが再生制御エンジン１７６それ自体を意味する。

ＨＤＭＶモジュール１７４及びＢＤ−Ｊモジュール１７５は、それぞれ別の方式で使用者の命令を受信する。また、ＨＤＭＶモジュール１７４及びＢＤ−Ｊモジュール１７５の使用者命令を処理する方式は、お互い独立している。使用者の命令を、関連したＨＤＭＶモジュール１７４及びＢＤ−Ｊモジュール１７５のうちいずれか１つに伝達するためには別の伝達手段が使用されなければならない。このような機能は、本発明では使用者イベントマネジャー（ｕｓｅｒ ｅｖｅｎｔ ｍａｎａｇｅｒ）１７１によって行われる。したがって、使用者イベントマネジャー１７１が使用者操作コントローラ（ｕｓｅｒ ｏｐｅｒａｔｉｏｎ（ＵＯ） ｃｏｎｔｒｏｌｌｅｒ）１７１ａによる使用者の命令であれば、これをモジュールマネジャー１７２または使用者操作コントローラ１７１ａに伝送する。一方、受信した命令がキーイベント（ｋｅｙ ｅｖｅｎｔ）による使用者命令であれば、これをＢＤ−Ｊモジュール１７５内のジャバＶＭ１７５ａに伝送する。

また、本発明の再生システム１７は、メタデータマネジャー（ｍｅｔａｄａｔａ ｍａｎａｇｅｒ）１７３を含むことができる。メタデータマネジャー１７３は、使用者にディスクライブラリー（ｄｉｓｃ ｌｉｂｒａｒｙ）と強化した検索メタデータアプリケーション（ｅｎｈａｎｃｅｄ ｓｅａｒｃｈ ｍｅｔａｄａｔａ ａｐｐｌｉｃａｔｉｏｎ）とを提供する。メタデータマネジャー１７３は、使用者の制御の下にタイトル選択を行うことができる。また、メタデータマネジャー１７３は、使用者に記録媒体とタイトルメタデータを提供することができる。

本発明による再生システムでモジュールマネジャー１７２、ＨＤＭＶモジュール１７４、ＢＤ−Ｊモジュール１７５、再生制御エンジン１７６は、ソフトウェア的な処理を行うことができる。実際にハードウェア構成よりはソフトウェアで処理することが、設計においてより有用である。もちろん、再生エンジン１７７、デコーダ１９及びプレーン（ｐｌａｎｅｓ）は、ハードウェアによって設計されることが一般的である。特に、ソフトウェア的に処理される構成要素（例えば、図面符号１７２、１７４、１７５及び１７６）は、制御部１２の一部として構成されることができる。したがって、上記の本発明の構成は、それらの意味に基づいて理解されるべきであり、ハードウェア的構成またはソフトウェア的構成のような構成方法に限定されてはいけないことは明らかである。ここで、“プレーン（ｐｌａｎｅ）”は、第１ビデオ、第２ビデオ、再生グラフィック（ＰＧ：ｐｒｅｓｅｎｔａｔｉｏｎ ｇｒａｐｈｉｃｓ）、インタラクティブグラフィック（ＩＧ：ｉｎｔｅｒａｃｔｉｖｅ ｇｒａｐｈｉｃｓ）、テキストサブタイトルのオーバーレイング（ｏｖｅｒｌａｙｉｎｇ）過程を説明するための概念的なモデルを意味する。本発明によれば、第２ビデオプレーンは、第１ビデオプレーンの前に位置する。したがって、デコーディングされた後に第２ビデオ出力は、第２ビデオプレーン上に表される。また、第２ビデオプレーンは、“ウィンドウ（ｗｉｎｄｏｗ）”と呼ばれる。以下では、第２ビデオが出力される第２ビデオプレーンを“第２ビデオウィンドウ”と呼ぶ。

図７は、本発明による第２ビデオメタデータの一実施例を示す図である。

本発明では、第２ビデオの再生は、メタデータを用いて管理される。メタデータは、第２ビデオの再生時期、再生大きさ及び再生位置に関する情報を含む。以下、管理データは、メタデータがＰｉＰメタデータである実施例と関連して説明される。ＰｉＰメタデータは、少なくとも１つのブロックヘッダ‘ｂｌｏｃｋ＿ｈｅａｄｅｒ［ｋ］’９１０とブロックデータ‘ｂｌｏｃｋ＿Ｄａｔａ［ｋ］’９２０とを含むことができる。ブロックヘッダとブロックデータの数は、ＰｉＰメタデータに保存されたメタデータブロックエントリーの数によって決定される。ブロックヘッダ９１０は、関連したメタデータブロックのヘッダ情報を含む。ブロックデータ９２０は、関連したメタデータブロックのデータ情報を含む。図７の実施例では、ＰｉＰメタデータが、プレイリストに存在する場合を取り上げているが、ＰｉＰを具現する第２ビデオストリームのヘッダに存在しても良い。

ブロックヘッダ９１０は、プレイアイテムを識別する情報（以下、‘ＰｌａｙＩｔｅｍ＿ｉｄ［ｋ］’という。）を指示するフィールドと、第２ビデオストリームを識別する情報（以下、‘ｓｅｃｏｎｄａｒｙ＿ｖｉｄｅｏ＿ｓｔｒｅａｍ＿ｉｄ［ｋ］'という。）を指示するフィールドとを含むことができる。‘ＰｌａｙＩｔｅｍ＿ｉｄ［ｋ］’は、‘ｓｅｃｏｎｄａｒｙ＿ｖｉｄｅｏ＿ｓｔｒｅａｍ＿ｉｄ［ｋ］’により指定される‘ｓｅｃｏｎｄａｒｙ ｖｉｄｅｏ＿ｓｔｒｅａｍ＿ｉｄ’エントリーがリストされたＳＴＮテーブルを含むプレイアイテムに対応する値である。‘ＰｌａｙＩｔｅｍ＿ｉｄ’値は、プレイリストファイルのプレイリストブロックに与えられる。ＰｉＰメタデータにおいて、‘ＰｌａｙＩｔｅｍ＿ｉｄ’のエントリーは‘ＰｌａｙＩｔｅｍ＿ｉｄ’の昇順で分類される。‘ｓｅｃｏｎｄａｒｙ＿ｖｉｄｅｏ＿ｓｔｒｅａｍ＿ｉｄ［ｋ］’は、サブパスと、関連したブロックデータ９２０が適用される第２ビデオストリームを区分するのに用いられる。すなわち、‘ＰｌａｙＩｔｅｍ＿ｉｄ［ｋ］’に対応する‘ＰｌａｙＩｔｅｍ’のＳＴＮテーブルで、‘ｓｅｃｏｎｄａｒｙ＿ｖｉｄｅｏ＿ｓｔｒｅａｍ＿ｉｄ［ｋ］’に対応するストリームエントリーを識別することが可能である。ストリームエントリーには第２ビデオと関連したサブパス識別情報値が記録されるので、光記録／再生装置１０は、記録された値を用いて第２ビデオを再生するサブパスを識別することができる。プレイリストブロックは、サブパスブロックを含む。

本発明の一実施例によれば、第１ビデオのトリック再生モード時に、第２ビデオの再生をどのように行うかを定義する。一方、第２ビデオの再生は、第２ビデオを再生するサブパスのサブパスタイプと、第２ビデオの再生を管理するＰｉＰメタデータで扱われるタイムラインのタイプとによって変わる。これについては、他のサブパスタイプを説明した後により詳細に説明する。

図８Ａ乃至図８Ｃは、本発明によるサブパスタイプの理解を助けるために示す図である。本発明の実施例によるＰｉＰアプリケーションモデルは、第２ビデオがマルチプレクシングされるストリームの種類と、第２ビデオを再生するサブパスが、関連するメインパスと同期されるか否かによって、３種類に大別されることができる。したがって、第２ビデオを再生するサブパスの種類、すなわち、サブパスタイプは、前述の３種類のモデルを考慮して決定される。

図８Ａに示すサブパスタイプは、第２ビデオが、第１ビデオと異なるストリームにエンコーディングされ、サブパスがメインパスと同期する場合である。第２ビデオが第１ビデオと別のストリームにマルチプレクシングされる場合を、‘アウト・オブ・マックス（ｏｕｔ−ｏｆ−ｍｕｘ）’という。

図８Ａを参照すると、第１ビデオと第２ビデオを管理するプレイリストは、第１ビデオを再生する１つのメインパスと、第２ビデオを再生する１つのサブパスとを含む。メインパスは、４つのプレイアイテム（‘ＰｌａｙＩｔｅｍ＿ｉｄ’＝０，１，２，３）で構成され、サブパスは、複数のサブプレイアイテムで構成される。サブパスは、メインパスと同期する。具体的に、第２ビデオは、各サブプレイアイテムと関連したプレイアイテムを識別する情報フィールド‘ｓｙｎｃ＿ＰｌａｙＩｔｅｍ＿ｉｄ’と、プレイアイテム内にサブプレイアイテムの再生時間を示すプレゼンテーションタイムスタンプ情報‘ｓｙｎｃ＿Ｓｔａｒｔ＿ＰＴＳ＿ｏｆ＿ＰｌａｙＩｔｅｍ’とを用いて、メインパスと同期する。すなわち、プレイアイテムの再生地点が、プレゼンテーションタイムスタンプ情報により指定された値に到達する時に、関連したサブプレイアイテムの再生が始まる。したがって、１つのサブパスを通じた第２ビデオの再生は、第１ビデオの再生の間に同時に始まる。

この場合、第２ビデオが第１ビデオと異なるストリームにマルチプレクシングされるため、プレイアイテムとサブプレイアイテムはそれぞれ異なるクリップを指定する。プレイアイテムとサブプレイアイテムのそれぞれは、再生すべき特定クリップの再生開始時間（ＩＮ−Ｔｉｍｅ）と再生終了時間（ＯＵＴ−Ｔｉｍｅ）に関する情報を含む。したがって、関連したプレイアイテムとサブプレイアイテムにより指定されるクリップは、ＡＶデコーダ１７ｂに提供される。

本発明によるＡＶデコーダモデルを概略的に示す図９Ａを参照すると、上記のクリップのストリームファイルは、トランスポートストリーム（ＴＳ：ｔｒａｎｓｐｒｏｒｔ ｓｔｒｅａｍ）の形態でＡＶデコーダ１７ｂに提供される。本発明では、メインパスを通じて再生されるＡＶストリームをメイントランスポートストリーム（以下、“メインストリーム”という。）と呼び、それ以外のＡＶストリームをサブトランスポートストリーム（以下、“サブストリーム”という。）と呼ぶ。したがって、第１ビデオと第２ビデオはそれぞれ、メインストリームとサブストリームとしてＡＶデコーダ１７ｂに提供される。ＡＶデコーダ１７ｂ内で、光ディスク３０からのメインストリームは、スイッチング要素を通過してバッファーＲＢ１に伝達される。そして、バッファリングされたメインストリームは、ソースデパケット化部（ｄｅｐａｃｋｅｔｉｚｅｒ）７１０ａでデパケット化される。デパケット化されたＡＶストリームに含まれたデータは、データパケットの種類によって、ＰＩＤ（ｐａｃｋｅｔ ｉｄｅｎｔｉｆｉｅｒ）フィルタ−１（７２０ａ）内で、デパケット化されたＡＶストリームから分離された後に、デコーダ７３０ａ〜７３０gのうち、関連するいずれか１つに提供される。ＰＩＤフィルタ−１（７２０ａ）からのパケットは、デコーダ７３０ｂ〜７３０ｇによって受け取られる前に、他のスイッチング要素を通過しても良い。

一方、光ディスク３０またはローカルストレージ１５からの各サブストリームは、スイッチング要素を通過してバッファーＲＢ２に伝達される。バッファリングされたサブストリームは、ソースデパケット化部７１０ｂでデパケット化される。デパケット化されたＡＶストリームに含まれたデータは、データパケットの種類によって、ＰＩＤフィルタ−２（７２０ｂ）内で、デパケット化されたＡＶストリームから分離された後に、デコーダ７３０ａ〜７３０ｇのうち、関連するいずれか１つに提供される。ＰＩＤフィルタ−２（７２０ｂ）からのパケットは、デコーダ７３０ｂ〜７３０ｆによって受け取られる前に、他のスイッチング要素を通過しても良い。

すなわち、第１ビデオは第１ビデオデコーダ７３０ａで、第１オーディオは第１オーディオデコーダ７３０ｅでデコーディングされる。また、ＰＧ（ｐｒｅｓｅｎｔａｔｉｏｎ ｇｒａｐｈｉｃ）、ＩＧ（ｉｎｔｅｒａｃｔｉｖｅ ｇｒａｐｈｉｃ）、第２オーディオ及びテキストサブタイトルは、ＰＧデコーダ７３０ｃ、ＩＧデコーダ７３０ｄ、第２オーディオデコーダ７３０ｆ及びテキストデコーダ７３０ｇでそれぞれデコーディングされる。

デコーディングされた第１ビデオ、第２ビデオ、ＰＧ及びＩＧはそれぞれ、第１ビデオプレーン７４０ａ、第２ビデオプレーン７３０ｂ、プレゼンテーショングラフィックプレーン７４０ｃ及びインタラクティブグラフィックプレーン７４０ｄに再生される。また、プレゼンテーショングラフィックプレーン７４０ｃは、テキストデコーダ７３０ｇでデコーディングされたグラフィックデータを再生することができる。デコーディングされた第１オーディオと第２オーディオは、オーディオミキサーでミキシングされたのち出力される。図８Ａのサブパスタイプは、第２ビデオを再生するサブパスとメインパスが同期するので、この場合、制御部１２は、第２ビデオが第１ビデオと同期して出力されるように制御する。

第１ビデオのトリック再生モード時に、図８Ａのサブパスタイプでは、第２ビデオは第１ビデオのトリック再生と同期して再生されることができる。

本発明の実施例で、制御部１２は、トリック再生モードの間に再生される第２ビデオをディスプレイするか否か、すなわち、第２ビデオウィンドウをクローズするか否かをトリック再生フラグから決定する。コンテンツプロバイダは、トリック再生フラグを、第１ビデオのトリック再生の間に第２ビデオウィンドウをクローズするか否かを指示する値に設定する。コンテンツプロバイダが、第１ビデオのトリック再生の間に第２ビデオウィンドウがクローズされることを希望する場合、トリック再生フラグの値を、例えば、‘０ｂ’に設定することができる。光記録／再生装置１０は、トリック再生フラグが‘０ｂ’に設定された場合、第１ビデオのトリック再生モードにおいて第２ビデオウィンドウをクローズする。

一方、トリック再生フラグがクローズを指示する値でない値（例えば、‘１ｂ’）に設定された場合、光記録／再生装置１０は、第２ビデオウィンドウをオープン状態に維持したりクローズすることができる。これは、光記録／再生装置１０に随意に具現されることができる。したがって、光記録／再生装置１０は、トリック再生フラグの値が‘１ｂ’である場合にも、第２ビデオウィンドウをクローズすることができる。第２ビデオをオープン状態に維持する場合、第１ビデオのトリック再生と同期して第２ビデオがディスプレイされる。例えば、第１ビデオが２倍の速度で順方向に再生される場合、第２ビデオも２倍の速度で順方向に再生される。一方、第１ビデオが逆方向に再生される場合、第２ビデオも同じ速度で逆方向に再生される。したがって、上記の方式で再生された第２ビデオが使用者に提供される。なお、第２ビデオがクローズされても、第２ビデオデコーダ７３０ｂは、第２ビデオデコーディングを続けることができるが、制御部１２が、第２ビデオプレーン７４０ｂが再生されるのを禁じる。このような方法で、第２ビデオは第１ビデオと相変わらず同期することができる。

トリック再生フラグは、ＰｉＰメタデータに含まれることができる。図７を参照すると、コンテンツプロバイダは、トリック再生フラグ（例えば、‘ｔｒｉｃｋ＿ｐｌａｙｉｎｇ＿ｆｌａｇ’９１０ａ）フィールドを提供し、第１ビデオのトリック再生モードの間に、第２ビデオウィンドウをクローズするか否かを指示する‘ｔｒｉｃｋ＿ｐｌａｙｉｎｇ＿ｆｌａｇ’を、‘０ｂ’または‘１ｂ’に設定できる。

図８Ｂに示すサブパスタイプで、第２ビデオは、第１ビデオと異なるストリームにエンコーディングされ、サブパスがメインパスと同期しない。図８Ａのサブパスタイプと似ているように、サブパスを通じて再生される第２ビデオストリームは、関連したプレイアイテムに基づき、再生されるクリップと分離してマルチプレクシングされる。ただし、図８Ｂのサブパスタイプは、サブパスの再生がメインパスのタイムライン上でいつでも始めることができるという点で、図８Ａとは異なる。一度サブパス再生が始まると、サブパス再生はメインパスと同期する。

図８Ｂを参照すると、第１ビデオと第２ビデオを管理するプレイリストは、第１ビデオを再生する１つのメインパスと、第２ビデオを再生する１つのサブパスとを含む。メインパスは、３つのプレイアイテム（‘ＰｌａｙＩｔｅｍ＿ｉｄ’＝０，１，２）で構成され、サブパスは、１つのサブプレイアイテムで構成される。サブパスにより再生される第２ビデオは、メインパスと同期しない。すなわち、サブプレイアイテムが、サブプレイアイテムと関連したプレイアイテムを識別する情報と、プレイアイテム内でサブプレイアイテムの再生時間を指示するプレゼンテーションタイムスタンプ（ｐｒｅｓｅｎｔａｔｉｏｎ ｔｉｍｅ ｓｔａｍｐ）情報とを含んでも、これらの情報は、図８Ｂのサブパスタイプでは有効でない。したがって、光記録／再生装置１０は、メインパスとサブパスを同期させるのに用いられる情報によらず作動することができる。このため、使用者は、第１ビデオが再生される間にはいつでも第２ビデオを見ることができる。

第２ビデオを再生するサブパスが図８Ｂのサブパスタイプに対応する場合、第２ビデオの再生は、第１ビデオと同期して再生される必要がないため、第１ビデオに関係なくいつでも開始できる。しかし、第２ビデオは、たとえ本発明によるトリック再生フラグが第２ビデオウィンドウをクローズするように指示する値に設定されている場合であっても、第１ビデオのトリック再生によって再生される。これは、一度サブパスが再生を始めると、サブパス再生はメインパスと同期するためである。もちろん、トリック再生フラグに関係なく第２ビデオウィンドウをクローズすることが可能である。もし第２ビデオウィンドウがクローズされると、第２ビデオはデコーディングを続けることができるが、ディスプレイされることはできない。

図８Ｃのサブパスタイプは、第２ビデオが第１ビデオのようなストリームにエンコーディングされ、サブパスがメインパスと同期する場合である。図８Ｃのサブパスタイプは、第２ビデオが第１ビデオと同じＡＶストリームにマルチプレクシングされる点で、図８Ａ及び図８Ｂのサブパスタイプと異なる。第２ビデオが第１ビデオと同じストリームにマルチプレクシングされた場合を、前述のように、‘ｉｎ−ｍｕｘ’という。

図８Ｃを参照すると、第１ビデオと第２ビデオを管理するプレイリストは、１つのメインパスと１つのサブパスとを含む。メインパスは、４つのプレイアイテム（‘ＰｌａｙＩｔｅｍ＿ｉｄ’＝０，１，２，３）で構成され、サブパスは、複数のサブプレイアイテムで構成される。サブパスを構成するサブプレイアイテムのそれぞれは、サブプレイアイテムと関連したプレイアイテムを識別する情報と、プレイアイテム内でサブプレイアイテムのプレゼンテーションタイムを指示するプレゼンテーションタイムスタンプ情報とを含む。図８Ａで説明したように、上記の情報によって各サブプレイアイテムは、関連したプレイアイテムと同期する。したがって、第２ビデオが第１ビデオと同期する。

図８Ｃのサブパスタイプにおいて、メインパスを構成するプレイアイテムとサブパスを構成するサブプレイアイテムは、同じクリップを参照する。したがって、第２ビデオは、第１ビデオと共に、メインストリームとしてＡＶデコーダ１７ｂに提供される。図９を参照すると、第１及び第２ビデオを含むデータがパケット化されたメインストリームは、ソースデパケット化部７１０ａによってデパケット化され、ＰＩＤフィルタ−１（７２０ａ）に送られる。これらのデータパケットは、関連したＰＩＤｓによって、ＰＩＤフィルタ−１（７２０ａ）内で、デパケット化されたデータからそれぞれ分離される。その後、デコーディングのために、関連したデコーダ７３０ａ〜７３０ｇに送られる。すなわち、第１ビデオは第１ビデオデコーダ７３０ａでデコーディングされた後に第１ビデオデコーダ７３０ａから出力される。第２ビデオは、第２ビデオデコーダ７３０ｂでデコーディングされた後に第２ビデオデコーダ７３０ｂから出力される。この場合に、制御部１２は、第２ビデオが第１ビデオと同期してディスプレイされるように制御する。

第２ビデオを再生するサブパスが図８Ｃのサブパスタイプに対応する場合、図８Ａと同様に、第２ビデオは第１ビデオのトリック再生と同期して再生される。トリック再生フラグを用いて、第２ビデオの出力される第２ビデオウィンドウをクローズするか否かを判定できることは、図８Ａで説明した通りである。もし、第２ビデオウィンドウがクローズされると、上述のように、第２ビデオはディスプレイされないが、デコーディングを続けることができる。

メインストリームとサブストリームは、記録媒体３０またはストレージ１５からＡＶデコーダ１７ｂに提供されることができる。第１ビデオと第２ビデオがそれぞれ異なるクリップに保存された場合、第１ビデオは、記録媒体３０に記録されて使用者に提供され、第２ビデオは、記録媒体３０外部からストレージ１５にダウンロードされることができる。その逆の場合も可能であることは勿論である。しかし、第１ビデオと第２ビデオがいずれも記録媒体３０に保存された場合、第１及び第２ビデオを同時に再生するためには、再生に先立ち、第１ビデオ及び第２ビデオのうちいずれか１つをストレージ１５にコピーしなければならない。第１及び第２ビデオが同じクリップに保存される場合、これらは記録媒体３０内に記録された後に提供される。しかしながら、このような場合、第１ビデオと第２ビデオがいずれも記録媒体３０の外部からダウンロードされることが可能である。

図７を参照すると、ブロックヘッダ９１０は、関連したＰｉＰメタデータにより参照されるタイムラインを指示する情報（以下、‘ｐｉｐ＿ｔｉｍｅｌｉｎｅ＿ｔｙｐｅ’という。）をさらに含むことができる。使用者に提供される第２ビデオタイプは、ＰｉＰタイムラインタイプによって変わる。以下、図１０Ａ乃至図１０Ｃを参照して、本発明の実施例によるＰｉＰタイムラインタイプについて説明する。

図１０Ａ乃至図１０Ｃは、本発明の第２ビデオタイムラインタイプの理解を助けるために示す図である。

ブロックデータ９２０は、ＰｉＰメタデータが位置する地点を指示するタイムスタンプ情報（以下、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ’という。）を含むことができる。上記の‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［i］’のエントリーが参照するタイムラインタイプ、すなわち、ＰｉＰメタデータがしたがうタイムラインタイプによって‘ｐｉｐ＿ｔｉｍｅｌｉｎｅ＿ｔｙｐｅ［ｋ］’値が定められる。以下、ＰｉＰタイムラインタイプを、‘ｐｉｐ＿ｔｉｍｅｌｉｎｅ＿ｔｙｐｅ［ｋ］’と‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［i］’に基づいて説明する。

図１０ＡのＰｉＰタイムラインタイプは、第２ビデオを再生するサブパスがメインパスと同期し、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ’エントリーがＰｉＰメタデータにより指定されるプレイアイテムのタイムラインを参照する。図１０Ａで、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ’は、‘ＰｌａｙＩｔｅｍ＿ｉｄ［ｋ］’により指定されるプレイアイテムのタイムライン上に投影される、関連したサブプレイアイテム区間の再生時間を指示する。図１０Ａのタイムラインタイプで、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［０］’と‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［ｍ］’は、関連したサブプレイアイテム区間がそれぞれ‘ｐｌａｙｉｔｅｍ＿ｄ［ｋ］’により指定されたプレイアイテムのタイムラインに投影される区間のそれぞれの開始点１０１ａ及び１０５ａに置かれる。

ブロックデータ９２０は、少なくとも１つの第２ビデオ構成情報（以下、‘ｐｉｐ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｍｅｔａｄａｔａ’）ブロックを含み、その数は‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［i］’によって決定される。

‘i'番目の‘ｐｉｐ＿ｃｏｍｐｏｓｉｔｏｎ＿ｍｅｔａｄａｔａ’は、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［i］’１０２ａと‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［i＋１］’１０３ａとの間で有効な第２ビデオ構成情報である。１つのブロックデータ９２０内の最後の‘ｐｉｐ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｍｅｔａｄａｔａ’は、ＰｉＰメタデータに含まれた‘ｓｅｃｏｎｄａｒｙ＿ｖｉｄｅｏ＿ｓｔｒｅａｍ＿ｉｄ［ｋ］’により指示されたサブパスの再生終了時間１０４ａまで有効である。

第２ビデオ構成情報は、第２ビデオの再生位置と大きさを指示する情報である。第２ビデオ構成情報は、第２ビデオの位置情報と大きさ情報（以下、‘ｐｉｐ＿ｓｃａｌｅ［i］’という。）を含むことができる。第２ビデオの位置情報には、第２ビデオの水平位置（以下、‘ｐｉｐ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ［i］’という。）情報と第２ビデオの垂直位置（以下、‘ｐｉｐ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ［i］’）情報とが含まれる。‘ｐｉｐ＿ｈｏｒｉｚｏｎｔａｌ＿ｐｏｓｉｔｉｏｎ’は、画面の基準点で画面上にディスプレイされる第２ビデオの水平位置を指示し、‘ｐｉｐ＿ｖｅｒｔｉｃａｌ＿ｐｏｓｉｔｉｏｎ’は、画面の基準点で画面上にディスプレイされる第２ビデオの垂直位置を指示する。画面上の第２ビデオのディスプレイ大きさ及び位置は、大きさ及び位置情報により決定される。

図１０Ａのタイムラインタイプにおいて、第２ビデオを再生するサブパス、すなわち、ＰｉＰ再生パスがメインパスと同期するので、前述した‘ｓｅｃｏｎｄａｒｙ＿ｖｉｄｅｏ＿ｓｔｒｅａｍ＿ｉｄ［ｋ］’により指示されるサブパスは、図８Ａまたは図８Ｃで説明したサブパスタイプ８１０または８３０に対応する。したがって、第１ビデオのトリック再生モード時に、第２ビデオは第１ビデオのトリック再生に同期して再生される。もちろん、トリック再生フラグによって、光記録／再生装置１０は、第２ビデオが出力される第２ビデオウィンドウをクローズしたりオープン状態に維持したりする。

図１０Ａのタイムラインタイプにおいて、メインパスを通じて表されるプレイアイテムと同期して第２ビデオが再生されるので、第２ビデオは、メインパスのタイムラインにしたがう。すなわち、第１ビデオのトリック再生モード時に、第１ビデオを再生するメインパスの再生地点が、例えば、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［i］’と‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［i＋１］’との間にある場合、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［i］’に対応する‘ｐｉｐ＿ｃｏｍｐｏｓｉｔｏｎ＿ｍｅｔａｄａｔａ［i］’が、第２ビデオに適用される。結局として、第２ビデオは第１ビデオ上にディスプレイされる。

図１０Ｂは、ＰｉＰ再生経路がメインパスと同期しなく、且つ、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ’エントリーがサブパスのタイムラインを参照する場合である。図１０Ｂの実施例において、ＰｉＰの再生経路がメインパスと同期しないので、前述した‘ｓｅｃｏｎｄａｒｙ＿ｖｉｄｅｏ＿ｔｉｍｅ＿ｓｔａｍｐ＿ｉｄ［ｋ］’により指示されるサブパスは、図８Ｂで説明したサブパスタイプに対応しなければならない。図１０Ｂのタイムラインタイプで、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ’は、ＰｉＰメタデータに含まれた‘ｓｅｃｏｎｄａｒｙ＿ｖｉｄｅｏ＿ｓｔｒｅａｍ＿ｉｄ［ｋ］’により指示されるサブプレイアイテムの区間で再生時間を指示する。このようなタイムラインタイプにおいて、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［０］’は、サブプレイアイテムの開始地点１０１ｂに置くことができる。

図１０Ｂのタイムラインタイプでは、第２ビデオは、サブプレイアイテムのタイムラインにしたがうので、メインパスを通じた再生手順に関わらず、サブパスを通じて再生される。すなわち、図１０Ｂのタイムラインタイプは、メインパスの再生地点がメインパスを通じて再生されるプレイアイテムのタイムライン上に特定地点に変更されても、これに関係なく第２ビデオは再生されるという点で、図１０Ａのタイムラインタイプと異なる。例えば、第２ビデオの再生位置と規模（ｓｃａｌｅ）は変わらない。

図１０Ｂのタイムラインタイプでは、上述の如く、ＰｉＰ再生経路がメインパスと同期しない。したがって、前述した‘ｓｅｃｏｎｄａｒｙ＿ｖｉｄｅｏ＿ｔｉｍｅ＿ｓｔａｍｐ＿ｉｄ［ｋ］’により指示されるサブパスは、図８Ｂで説明したサブパスタイプに対応する。

図１０Ｃは、ＰｉＰ再生経路がメインパスと同期しなく、かつ、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ’のエントリーによってＰｉＰメタデータに含まれた‘ＰｌａｙＩｔｅｍ＿ｉｄ［ｋ］’により指定されたプレイアイテムのタイムラインを参照する場合である。図１０Ａにおけるタイムラインと同様に、プレイアイテムのタイムラインは、図１０Ｃのタイムラインタイプに参照される。したがって、‘ＳｕｂＰｌａｙＩｔｅｍ＿ＩＮ＿ｔｉｍｅ’が、プレイアイテムのタイムラインにポイント１０２ｃで投影される。図１０Ｃのタイムラインタイプで、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ’は、‘ＰｌａｙＩｔｅｍ＿ｉｄ［ｋ］’により指示されるプレイアイテム区間で再生時間を指示する。図１０Ｃのタイムラインタイプは、ＰｉＰメタデータが‘ＰｌａｙＩｔｅｍ＿ｉｄ［ｋ］’により指示されるプレイアイテムのタイムラインに従うので、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［０］’は、‘ＰｌａｙＩｔｅｍ＿ｉｄ［ｋ］’により指示されるプレイアイテム区間の開始地点１０１ｃに置かれることができる。

しかし、図１０Ａのタイムラインタイプでは、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［０］’は、関連したサブプレイアイテム区間が‘ｐｌａｙｉｔｅｍ＿ｉｄ［ｋ］’によりプレイアイテムのタイムラインに投影される区間の開始地点１０１ａに置かれることができる。

図１０Ｃのタイムラインタイプでは、第２ビデオを再生するサブパスがメインパスと同期しないので、図１０Ａのタイムラインタイプと違い、第２ビデオが第１ビデオに関係なく開始できる。第１ビデオのトリック再生の間に、ＰｉＰメタデータが、関連したプレイアイテムのタイムラインに従うので、メインパスの再生地点に対応する‘ｐｉｐ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｍｅｔａｄａｔａ’が第２ビデオに適用される。図１０Ｃを参照すると、例えば、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［i＋１］’に該当する‘ｐｉｐ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｍｅｔａｄａｔａ［i＋１］’が第２ビデオに適用される状態で、逆方向再生によりメインパスの再生位置が、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［i＋１］'の位置から‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［i］’の位置に移動する場合に、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［i］'に該当する‘ｐｉｐ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｍｅｔａｄａｔａ［i］’が、第２ビデオに適用される。したがって、第２ビデオの再生経路及び速度と、第２ビデオが出力される第２ビデオウィンドウの大きさ及び位置は、第１ビデオのトリック再生に影響される。したがって、たとえ第２ビデオのストリーム再生が第１ビデオのトリック再生の間に続くとしても、使用者に見られる第２ビデオの再生パス、速度、大きさ及び位置は、第１ビデオのトリック再生に影響される。

図１０Ｃのタイムラインタイプにおいて、ＰｉＰの再生経路がメインパスと同期しないので、前述した‘ｓｅｃｏｎｄａｒｙ＿ｖｉｄｅｏ＿ｔｉｍｅ＿ｓｔａｍｐ＿ｉｄ［ｋ］’により指示されるサブパスは、図８Ｂで説明したサブパスタイプに対応しなければならない。

図１０Ｃのタイムラインタイプで、ＰｉＰメタデータは、‘ＰｌａｙＩｔｅｍ＿ｉｄ［ｋ］’により指定されるプレイアイテム区間で再生時間を指示するので、‘ｐｉｐ＿ｍｅｔａｄａｔａ＿ｔｉｍｅ＿ｓｔａｍｐ［１＋i］’は、現在プレイアイテムのアウトタイム１０４ｃまで有効である。しかし、１つのブロックデータ９２０内の最後の‘ｐｉｐ＿ｃｏｍｐｏｓｉｔｉｏｎ＿ｍｅｔａｄａｔａ’は、‘ｓｅｃｏｎｄａｒｙ＿ｖｉｄｅｏ＿ｓｔｒｅａｍ＿ｉｄ［ｋ］’により指示されたサブパスの再生終了時間まで有効であるから、サブプレイアイテムアウトタイム１０３ｃ以降には第２ビデオがディスプレイされない。

本発明は、第１ビデオのトリック再生モード時に、トリック再生フラグを用いて第２ビデオを再生するデータ再生方法に関するものである。コンテンツプロバイダは、記録媒体またはネットワークを介してデータを提供する場合、データのデータベース領域にトリック再生フラグを保存し、該トリック再生フラグを使用者に提供する。本発明の光記録／再生装置１０は、データベース領域内に保存されたトリック再生フラグを確認する。識別されたトリック再生フラグに基づき、第２ビデオウィンドウをクローズするように指示する値（例えば、‘０ｂ’）にトリック再生フラグが設定された場合には、第１ビデオのトリック再生モードで光記録／再生装置１０は第２ビデオウィンドウをクローズする。一方、トリック再生フラグがクローズ値と異なる値（例えば、‘１ｂ’）に設定された場合には、光記録／再生装置１０は、第２ビデオウィンドウをオープン状態に維持したり第２ビデオウィンドウをクローズしたりすることができる。

第２ビデオが第１ビデオと同期しないタイムラインタイプでは、第２ビデオは、第１ビデオのトリック再生に関らずに本来の再生経路によって再生されることができる。したがって、トリック再生フラグは、第２ビデオが第１ビデオと同期するタイムラインタイプの場合、すなわち、第２ビデオを再生するサブパスが、図８Ａまたは図８Ｃのサブパスタイプに対応する場合に有効になりうる。

図１１は、本発明の一実施例によるデータ再生方法を示すフローチャートである。

記録媒体及び／またはストレージに保存されたデータの再生のうち、第１ビデオのトリック再生命令（例えば、使用者の入力により）が下されると（Ｓ１１０）、第１ビデオは、トリック再生命令によって再生される。制御部１２は、第２ビデオのトリック再生フラグを確認し（Ｓ１２０）、再生された第２ビデオウィンドウをクローズするか否かを決定する（Ｓ１３０）。

本発明によれば、トリック再生フラグがクローズ値に設定された場合、第２ビデオウィンドウが開いた状態で第１ビデオのトリック再生が始まると、第２ビデオウィンドウはクローズされる（Ｓ１４０）。なお、第２ビデオがクローズされた状態で第１ビデオのトリック再生が始まると、たとえ第２ビデオがディスプレイされるべき時点に到達しても第２ビデオウィンドウは開かない。一方、トリック再生フラグがクローズ値と異なる値に設定されると、光記録／再生装置１０の具現されたオプションによって第２ビデオウィンドウはクローズ（Ｓ１４０）、又はオープンされることができる（Ｓ１５０）。

第２ビデオが第１ビデオと同期しないサブパスタイプでは、第２ビデオは第１ビデオによらず正常に再生できる。この場合、制御部１２は、トリック再生フラグに基づいて第２ビデオウィンドウ状態を変化させなくて良い。すなわち、トリック再生フラグが第２ビデオウィンドウのクローズを指示する値に設定されていても、制御部１２は、第２ビデオウィンドウをクローズしなくて良い。もちろん、制御部１２は、第２ビデオウィンドウをクローズしても良い。第２ビデオは、第１ビデオと同期して再生される。一方、第２ビデオが第１ビデオと同期する場合、第２ビデオは第１ビデオと同期して再生される（Ｓ１６０）。第２ビデオウィンドウがクローズされた場合であっても、第２ビデオは第１ビデオと同期しなければならない。例えば、たとえディスプレイされないとしても、第２ビデオウィンドウは、デコーディングされた結果が使用者に提供されないままでデコーディングを続けることができる。第１ビデオのトリック再生が完了した後には、第２ビデオウィンドウはオープンされることができる。

本発明の実施例によれば、第１ビデオのトリック再生モード時にも、第２ビデオを第１ビデオと一緒に再生することが可能である。コンデンツプロバイダは、第２ビデオのトリック再生フラグを用いて、第１ビデオのトリック再生モード時に再生される第２ビデオを使用者に提供するか否かを定めることができる。したがって、第２ビデオを第１ビデオと一緒に效率的に再生することが可能になることはもちろん、より多様に第２ビデオを具現可能になるという利点がある。

本発明の記録媒体、データ再生方法及び装置並びにデータ記録方法及び装置と関連し、第１ビデオのトリック再生モードにおいて第１ビデオと同時に第２ビデオを再生することが可能であるということは自明である。第１ビデオのトリック再生モードで再生される第２ビデオを使用者に提供するか否かを制御することが可能になる。これにより、コンテンツプロバイダはより多様なコンテンツを構成し、より多様なコンテンツを使用者が経験できるようにすることができる。

本発明の特徴または範囲を逸脱しない限度内で様々な改変が可能であるということは、本発明の属する技術分野における通常の知識を持つ者にとっては自明であり、したがって、それらの改変も本発明の範囲に含まれる。

本発明の光記録／再生装置と周辺機器との統合的使用の一実施例を示す図である。 本発明の一実施例による記録媒体である光ディスクに記録されるファイル構造を示す図である。 本発明の一実施例による記録媒体である光ディスクのデータ記録構造を示す図である。 本発明の一実施例による第２ビデオに関する概念的理解を助けるために示す図である。 本発明の一実施例による光記録／再生装置の全体構成を示す図である。 本発明の一実施例による再生システムを説明するための図である。 本発明による第２ビデオメタデータの一実施例を示す図である。 本発明の一実施例による第２ビデオサブパスタイプの理解のために示す図である。 本発明の一実施例による第２ビデオサブパスタイプの理解のために示す図である。 本発明の一実施例による第２ビデオサブパスタイプの理解のために示す図である。 本発明の一実施例によるＡＶデコーダモデルを概略的に示す図である。 本発明の一実施例による第２ビデオタイムラインタイプの理解のために示す図である。 本発明の一実施例による第２ビデオタイムラインタイプの理解のために示す図である。 本発明の一実施例による第２ビデオタイムラインタイプの理解のために示す図である。 本発明によるデータ再生方法の一実施例を示す図である。

Claims (39)

1. 少なくとも１つのピクチャー・イン・ピクチャープレゼンテーションパスの再生を管理する方法であって、
   記録媒体から管理データを読み取るステップと、
   前記管理データに基づいて第２ビデオストリームを第１ビデオストリームと共に選択的にディスプレイするステップであって、前記第２ビデオストリームは、前記第１ビデオストリームによって表される第１プレゼンテーションパスに対するピクチャー・イン・ピクチャープレゼンテーションパスを表すステップと、
   前記選択的にディスプレイするステップが前記第２ビデオストリームをディスプレイしない場合、前記第２ビデオストリームをデコードするステップと
   を有することを特徴とする方法。
2. 前記管理データは、前記第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを示すディスプレイ情報を含み、
   前記選択的にディスプレイするステップは、前記ディスプレイ情報に基づいて前記第２ビデオストリームをディスプレイすること
   を特徴とする請求項１に記載の方法。
3. 前記ディスプレイ情報は、前記第１ビデオストリームのトリック再生の間に、前記第２ビデオストリームが再生されるウィンドウをクローズするか否かを示すことを特徴とする請求項２に記載の方法。
4. 前記選択的にディスプレイするステップは、前記第２ビデオストリームが前記第１ビデオストリームと同期して再生される場合、前記ディスプレイ情報に基づいて前記第２ビデオストリームを選択的にディスプレイすることを特徴とする請求項３に記載の方法。
5. 前記読み取りステップは、前記記録媒体に記録されたプレイリストからメタデータを読み取り、前記プレイリストは、再生のための少なくとも１つのプレイアイテムを示し、前記プレイアイテムは、前記第１ビデオストリームの再生間隔を示し、前記メタデータは、前記管理データを含むことを特徴とする請求項３に記載の方法。
6. 前記メタデータは、前記第２ビデオストリームウィンドウをディスプレイする位置を示す構成情報を含み、
   前記選択的にディスプレイするステップは、前記構成情報により示される前記位置に前記第２ビデオストリームウィンドウをディスプレイすること
   を特徴とする請求項５に記載の方法。
7. 前記構成情報は、前記第２ビデオストリームウィンドウをディスプレイする大きさを示し、
   前記選択的にディスプレイするステップは、前記構成情報により示される前記大きさで前記第２ビデオストリームウィンドウをディスプレイすること
   を特徴とする請求項６に記載の方法。
8. 前記構成情報は、前記第２ビデオストリームウィンドウをディスプレイする大きさを示し、
   前記選択的にディスプレイするステップは、前記構成情報により示される前記大きさで前記第２ビデオストリームウィンドウをディスプレイすることを特徴とする請求項５に記載の方法。
9. 前記読み取りステップは、前記記録媒体に記録されたプレイリストからメタデータを読み取り、前記プレイリストは、再生のための少なくとも１つのプレイアイテムを示し、前記プレイアイテムは、前記第１ビデオストリームの再生間隔を示し、前記メタデータは、前記管理データを含むことを特徴とする請求項１に記載の方法。
10. 前記メタデータは、前記第２ビデオストリームをディスプレイする位置を示す構成情報を含み、
    前記選択的にディスプレイするステップは、前記構成情報により示される前記位置に前記第２ビデオストリームをディスプレイすることを特徴とする請求項９に記載の方法。
11. 前記構成情報は、前記第２ビデオストリームをディスプレイする大きさを示し、
    前記選択的にディスプレイするステップは、前記構成情報により示される前記大きさで前記第２ビデオストリームをディスプレイすることを特徴とする請求項１０に記載の方法。
12. 前記メタデータは、前記第２ビデオストリームをディスプレイする大きさを示す構成情報を含み、
    前記選択的にディスプレイするステップは、前記構成情報により示される前記大きさで前記第２ビデオストリームをディスプレイすることを特徴とする請求項９に記載の方法。
13. 少なくとも１つのピクチャー・イン・ピクチャープレゼンテーションパスの再生を管理する装置であって、
    記録媒体からデータ再生のための再生要素を駆動するように構成されたドライバーと、
    前記ドライバーを制御して前記記録媒体から管理データを読み取るように構成され、前記管理データに基づいた第１ビデオストリームと共に第２ビデオストリームを選択的にディスプレイするように構成された制御部であって、前記第２ビデオストリームは、前記第１ビデオストリームにより表された第１プレゼンテーションパスに対する前記ピクチャー・イン・ピクチャープレゼンテーションパスを表すビデオストリームである制御部と、
    前記制御部が前記第２ビデオストリームをディスプレイしなくても、前記第２ビデオストリームをデコードするように構成されたデコーダと
    を備えることを特徴とする装置。
14. 前記管理データは、前記第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを示すディスプレイ情報を含み、
    前記制御部は、前記ディスプレイ情報に基づいて前記第２ビデオストリームを選択的にディスプレイするように構成されること
    を特徴とする請求項１３に記載の装置。
15. 前記ディスプレイ情報は、前記第１ビデオストリームのトリック再生の間に、前記第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを示すことを特徴とする請求項１４に記載の装置。
16. 前記制御部は、前記第２ビデオストリームが前記第１ビデオストリームと同期して再生される場合に限り、前記ディスプレイ情報に基づいて前記第２ビデオストリームを選択的に再生するように構成されていることを特徴とする請求項１５に記載の装置。
17. 前記制御部は、前記記録媒体上に記録されたプレイリストからメタデータを読み取る前記ドライバーを制御するように構成され、前記プレイリストは、再生のための少なくとも１つのプレイアイテムを示し、前記プレイアイテムは、前記第１ビデオストリームの再生間隔を示し、前記メタデータは、前記管理データを含むことを特徴とする請求項１５に記載の装置。
18. 前記メタデータは、前記第２ビデオストリームウィンドウをディスプレイする位置を示す構成情報を含み、
    前記制御部は、前記構成情報により指示された前記位置に前記第２ビデオストリームウィンドウをディスプレイするように構成されること
    を特徴とする請求項１７に記載の装置。
19. 前記構成情報は、前記第２ビデオストリームウィンドウをディスプレイする大きさを示し、
    前記制御部は、前記構成情報により示された前記大きさで前記第２ビデオストリームウィンドウをディスプレイするように構成されること
    を特徴とする請求項１８に記載の装置。
20. 前記メタデータは、前記第２ビデオストリームウィンドウをディスプレイする大きさを示す構成情報を含み、
    前記選択的にディスプレイするステップは、前記構成情報により示された前記大きさで前記第２ビデオストリームウィンドウをディスプレイすること
    を特徴とする請求項１７に記載の装置。
21. 前記制御部は、前記ドライバーを制御して前記記録媒体上に記録されたプレイリストからメタデータを読み取るように構成され、前記プレイリストは、再生のために少なくとも１つのプレイアイテムを示し、前記プレイアイテムは、前記第１ビデオストリームの再生間隔を示し、前記メタデータは、前記管理データを含むことを特徴とする請求項１３に記載の装置。
22. 少なくとも１つのピクチャー・イン・ピクチャープレゼンテーションパスの再生を管理するデータ構造を有する記録媒体であって、
    第１ビデオストリームを保存するデータ領域であって、前記第１ビデオストリームは第１プレゼンテーションパスを表すビデオストリームであるデータ領域と、
    前記第１プレゼンテーションパスに対応するピクチャー・イン・ピクチャープレゼンテーションパスの再生を管理するための管理データを保存する管理領域であって、前記管理データは、第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを示すディスプレイ情報を含み、前記第２ビデオストリームは、前記ピクチャー・イン・ピクチャープレゼンテーションパスを表すビデオストリームである管理領域と
    を有することを特徴とする記録媒体。
23. 前記ディスプレイ情報は、前記第１ビデオストリームのトリック再生の間に、前記第２ビデオストリームがディスプレイされる前記ウィンドウをクローズするか否かを示すことを特徴とする請求項２２に記載の記録媒体。
24. 前記管理領域は、再生のために少なくとも１つのプレイアイテムを指示するプレイリストを保存し、前記プレイアイテムは、前記第１ビデオストリームの再生間隔を示し、前記プレイリストは、前記管理データを含むメタデータを含むことを特徴とする請求項２２に記載の記録媒体。
25. 前記メタデータは、前記第２ビデオストリームウィンドウをディスプレイする位置を示す構成情報を含むことを特徴とする請求項２４に記載の記録媒体。
26. 前記メタデータは、前記第２ビデオストリームウィンドウをディスプレイする大きさを示す構成情報を含むことを特徴とする請求項２４に記載の記録媒体。
27. 前記ディスプレイ情報は、前記第２ビデオストリームが前記第１ビデオストリームと同期して再生される場合に限り、前記第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを示すことを特徴とする請求項２２に記載の記録媒体。
28. 記録媒体に少なくとも１つのピクチャー・イン・ピクチャープレゼンテーションパスの再生を管理するデータ構造を記録する方法であって、
    前記記録媒体のデータ領域に、第１のプレゼンテーションパスを表す第１ビデオストリームを保存するステップと、
    前記記録媒体の管理領域に第１プレゼンテーションパスに対してピクチャー・イン・ピクチャープレゼンテーションパスの再生を管理するための管理データを保存するステップと
    を有し、
    前記管理データは、第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを示すディスプレイ情報を含み、前記第２ビデオストリームは、前記ピクチャー・イン・ピクチャープレゼンテーションパスを表すこと
    を特徴とする方法。
29. 前記ディスプレイ情報は、前記第１ビデオストリームのトリック再生の間に、前記第２ビデオストリームがディスプレイされる前記ウィンドウをクローズするか否かを示すことを特徴とする請求項２８に記載の方法。
30. 前記管理データを保存するステップは、前記管理領域にプレイリストを保存し、前記プレイリストは、再生のための少なくとも１つのプレイアイテムを示し、前記プレイアイテムは、前記第１ビデオストリームの再生間隔を示し、前記プレイリストは、前記管理データを含むメタデータを含むことを特徴とする請求項２８に記載の方法。
31. 前記メタデータは、前記第２ビデオストリームウィンドウをディスプレイする位置を示す構成情報を含むことを特徴とする請求項３０に記載の方法。
32. 前記メタデータは、前記第２ビデオストリームウィンドウをディスプレイする大きさを示す構成情報を含むことを特徴とする請求項３０に記載の方法。
33. 前記ディスプレイ情報は、前記第２ビデオストリームが前記第１ビデオストリームと同期して再生される時に有効であることを特徴とする請求項２８に記載の方法。
34. 記録媒体に少なくとも１つのピクチャー・イン・ピクチャープレゼンテーションパスの再生を管理するデータ構造を記録する装置であって、
    記録媒体上にデータ記録のための記録要素を駆動するように構成されたドライバーと、
    前記ドライバーを制御して前記記録媒体のデータ領域に第１ビデオストリームを保存するように構成された制御部であって、前記第１ビデオストリームは、第１プレゼンテーションパスを表すビデオストリームである制御部と
    を有し、
    前記制御部は、前記記録媒体の管理領域に前記第１プレゼンテーションパスに対するピクチャー・イン・ピクチャープレゼンテーションパスの再生を管理するための管理データを保存する前記ドライバーを制御するように構成され、前記管理データは、第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを示すディスプレイ情報を含み、前記第２ビデオストリームは、前記ピクチャー・イン・ピクチャープレゼンテーションパスを表すこと
    を特徴とするデータ記録装置。
35. 前記ディスプレイ情報は、前記第１ビデオストリームのトリック再生の間に、前記第２ビデオストリームがディスプレイされる前記ウィンドウをクローズするか否かを示すことを特徴とする請求項３４に記載のデータ記録装置。
36. 前記制御部は、前記ドライバーを制御して前記管理領域内にプレイリストを保存するように構成され、前記プレイリストは、再生のための少なくとも１つのプレイアイテムを示し、前記プレイアイテムは、前記第１ビデオストリームの再生間隔を示し、前記プレイリストは、前記管理データを含むメタデータを含むことを特徴とする請求項３４に記載のデータ記録装置。
37. 前記メタデータは、前記第２ビデオストリームウィンドウをディスプレイする位置を示す構成情報を含むことを特徴とする請求項３６に記載のデータ記録装置。
38. 前記メタデータは、前記第２ビデオストリームウィンドウをディスプレイする大きさを示す構成情報を含むことを特徴とする請求項３６に記載のデータ記録装置。
39. 前記ディスプレイ情報は、前記第２ビデオストリームが前記第１ビデオストリームと同期して再生される場合に限り、前記第２ビデオストリームがディスプレイされるウィンドウをクローズするか否かを示すことを特徴とする請求項３４に記載のデータ記録装置。

Images