JP4264617B2 - 記録装置および方法、再生装置および方法、記録媒体、プログラム、並びに記録媒体 - Google Patents
記録装置および方法、再生装置および方法、記録媒体、プログラム、並びに記録媒体 Download PDFInfo
- Publication number
- JP4264617B2 JP4264617B2 JP2001109342A JP2001109342A JP4264617B2 JP 4264617 B2 JP4264617 B2 JP 4264617B2 JP 2001109342 A JP2001109342 A JP 2001109342A JP 2001109342 A JP2001109342 A JP 2001109342A JP 4264617 B2 JP4264617 B2 JP 4264617B2
- Authority
- JP
- Japan
- Prior art keywords
- thumbnail
- image
- data
- image data
- recording
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は記録装置および方法、再生装置および方法、記録媒体、プログラム、並びに記録媒体に関し、特に、データを代表するサムネイルをデータに付加する記録装置および方法、再生装置および方法、記録媒体、プログラム、並びに記録媒体に関する。
【０００２】
【従来の技術】
近年、記録再生装置から取り外し可能なディスク型の記録媒体として、各種の光ディスクが提案されつつある。このような記録可能な光ディスクは、数ギガバイトの大容量メディアとして提案されており、ビデオ信号等のAV(Audio Visual)信号を記録するメディアとしての期待が高い。この記録可能な光デイスクに記録するデジタルのAV信号のソース（供給源）としては、CSデジタル衛星放送やBSデジタル放送があり、また、将来はデジタル方式の地上波テレビジョン放送等も提案されている。
【０００３】
ここで、これらのソースから供給されるデジタルビデオ信号は、通常MPEG（Moving Picture Experts Group）２方式で画像圧縮されているのが一般的である。また、記録装置には、その装置固有の記録レートが定められている。従来の民生用映像蓄積メディアで、デジタル放送由来のデジタルビデオ信号を記録する場合、アナログ記録方式であれば、デジタルビデオ信号をデコード後、帯域制限をして記録する。あるいは、MPEG１ Video、MPEG２ Video、DV方式をはじめとするデジタル記録方式であれば、１度デコードされた後に、その装置固有の記録レート・符号化方式で再エンコードされて記録される。
【０００４】
しかしながら、このような記録方法は、供給されたビットストリームを１度デコードし、その後で帯域制限や再エンコードを行って記録するため、画質の劣化を伴う。画像圧縮されたデジタル信号の記録をする場合、入力されたデジタル信号の伝送レートが記録再生装置の記録レートを超えない場合には、供給されたビットストリームをデコードや再エンコードすることなく、そのまま記録する方法が最も画質の劣化が少ない。ただし、画像圧縮されたデジタル信号の伝送レートが記録媒体としてのディスクの記録レートを超える場合には、記録再生装置でデコード後、伝送レートがディスクの記録レートの上限以下になるように、再エンコードをして記録する必要はある。
【０００５】
また、入力デジタル信号のビットレートが時間により増減する可変レート方式によって伝送されている場合には、回転ヘッドが固定回転数であるために記録レートが固定レートになるテープ記録方式に比べ、１度バッファにデータを蓄積し、バースト的に記録ができるディスク記録装置が記録媒体の容量をより無駄なく利用できる。
【０００６】
以上のように、デジタル放送が主流となる将来においては、データストリーマのように放送信号をデジタル信号のまま、デコードや再エンコードすることなく記録し、記録媒体としてディスクを使用した記録再生装置が求められると予測される。
【０００７】
【発明が解決しようとする課題】
上述したような装置により、複数のデータ（例えば、映像データや音声データなどから構成される番組のデータ）が記録されている記録媒体を再生する際、記録媒体に記録されるデータ量が増加するに従い、どの番組を再生するのか、番組中のどのシーンから再生するのかといった、再生させる前の処理が煩雑になるといった課題があった。
【０００８】
本発明はこのような状況に鑑みてなされたものであり、データを代表するサムネイルをデータに付加することにより、再生させるデータを簡単に選択できるようにすることを目的とする。
【０００９】
【課題を解決するための手段】
本発明の記録装置は、入力された動画像データから、前記動画像データの内容を代表するサムネイル画像を第１のサムネイルデータとして生成すると共に、前記動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像を第２のサムネイルデータとして生成する生成手段と、前記生成手段により生成された前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したグループとして記録媒体に記録する記録手段とを有することを特徴とする。
【００１０】
前記生成手段は、第１のサムネイルデータと第２のサムネイルデータを、各々独立したファイルとして生成するようにすることができる。
【００１１】
前記第１のサムネイルは、プレイリストを代表するサムネイルであり、前記第２のサムネイルは、マーク点を表すサムネイルであるようにすることができる。
【００１２】
前記生成手段は、第１のサムネイルデータに対応する番号で第１のサムネイルデータを管理する第１の管理データも生成すると共に、第２のサムネイルデータに対応する番号で第２のサムネイルデータを管理する第２の管理データも生成し、前記記録手段は、第１の管理データおよび第２の管理データを記録媒体に記録するようにすることができる。
【００１３】
前記第１の管理データと第２の管理データは、管理するサムネイル画像の画像データのフォーマット形式を示すデータを含むようにすることができる。
【００１４】
前記記録手段は、第１のサムネイルデータまたは第２のサムネイルデータに含まれるサムネイル画像の画像データを、所定の大きさのブロック単位で記録するようにすることができる。
【００１５】
前記記録手段は、第１のサムネイル画像の参照先を示す情報をさらに別ファイルとして記録媒体に記録するようにすることができる。
【００１６】
前記記録手段は、第２のサムネイルデータに含まれるサムネイル画像の参照先を示す情報をさらに記録するようにすることができる。
【００１７】
本発明の記録方法は、入力された動画像データから、前記動画像データの内容を代表するサムネイル画像を第１のサムネイルデータとして生成すると共に、前記動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像を第２のサムネイルデータとして生成する生成ステップと、前記生成ステップの処理で生成された前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したグループとして記録媒体に記録するための制御を行う記録制御ステップとを含むことを特徴とする。
【００１８】
本発明の第１の記録媒体のプログラムは、入力された動画像データから、前記動画像データの内容を代表するサムネイル画像を第１のサムネイルデータとして生成すると共に、前記動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像を第２のサムネイルデータとして生成する生成ステップと、前記生成ステップの処理で生成された前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したグループとして記録媒体に記録するための制御を行う記録制御ステップとを含む。
【００１９】
本発明の第１のプログラムは、入力された動画像データから、前記動画像データの内容を代表するサムネイル画像を第１のサムネイルデータとして生成すると共に、前記動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像を第２のサムネイルデータとして生成する生成ステップと、前記生成ステップの処理で生成された前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したグループとして記録媒体に記録するための制御を行う記録制御ステップとを実行させるコンピュータが読み取り可能なプログラム。
【００２０】
本発明の再生装置は、画像データの再生が指示された場合、前記画像データの内容を代表するサムネイル画像の画像データを管理する管理データを読み出す第１の読み出し手段と、前記読み出し手段により読み出された前記管理データに基づき、前記画像データを読み出す第２の読み出し手段と、前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データを読み出す第３の読み出し手段と、前記第３の読み出し手段により読み出された前記管理データに基づき、前記画像データを読み出す第４の読み出し手段とを含むことを特徴とする。
【００２１】
本発明の再生方法は、画像データの再生が指示された場合、前記画像データの内容を代表するサムネイル画像の画像データを管理する管理データの読み出しを制御する第１の読み出し制御ステップと、前記読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データの読み出しを制御する第２の読み出し制御ステップと、前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データを読み出す第３の読み出しステップと、前記第３の読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データを読み出す第４の読み出しステップとを含むことを特徴とする。
【００２２】
本発明の第２の記録媒体のプログラムは、画像データの再生が指示された場合、前記画像データの内容を代表するサムネイル画像の画像データを管理する管理データの読み出しを制御する第１の読み出し制御ステップと、前記読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データの読み出しを制御する第２の読み出し制御ステップと、前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データを読み出す第３の読み出しステップと、前記第３の読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データを読み出す第４の読み出しステップとを含む。
【００２３】
本発明の第２のプログラムは、画像データの再生が指示された場合、前記画像データの内容を代表するサムネイル画像の画像データを管理する管理データの読み出しを制御する第１の読み出し制御ステップと、前記読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データの読み出しを制御する第２の読み出し制御ステップと、前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データを読み出す第３の読み出しステップと、前記第３の読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データを読み出す第４の読み出しステップとを実行するコンピュータが読み取り可能なプログラム。
【００２４】
本発明の第３の記録媒体は、画像データ、前記画像データから、前記画像データの内容を代表するサムネイル画像の画像データと、そのサムネイル画像のデータを管理する管理データから構成される第１のデータ、および、前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザが指定した画像のサムネイル画像の画像データと、その画像データを管理する管理データから構成される第２のデータが記録されていることを特徴とする。
【００２５】
本発明の記録装置および方法、並びに第１のプログラムにおいては、入力された動画像データから、動画像データの内容を代表するサムネイル画像が第１のサムネイルデータとして生成されると共に、動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像が第２のサムネイルデータとして生成され、生成された第１のサムネイルデータと第２のサムネイルデータが、各々独立したグループとして記録媒体に記録される。
【００２６】
本発明の再生装置および方法、並びに第２のプログラムにおいては、画像データの再生が指示された場合、画像データの内容を代表するサムネイル画像の画像データを管理する管理データが読み出され、読み出された管理データに基づき、画像データが読み出され、画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データが読み出され、読み出された管理データに基づき、画像データが読み出される。
【００２７】
【発明の実施の形態】
以下に、本発明の実施の形態について、図面を参照して説明する。図１は、本発明を適用した記録再生装置１の内部構成例を示す図である。まず、外部から入力された信号を記録媒体に記録する動作を行う部分の構成について説明する。記録再生装置１は、アナログデータ、または、デジタルデータを入力し、記録することができる構成とされている。
【００２８】
端子１１には、アナログのビデオ信号が、端子１２には、アナログのオーディオ信号が、それぞれ入力される。端子１１に入力されたビデオ信号は、解析部１４とAVエンコーダ１５に、それぞれ出力される。端子１２に入力されたオーディオ信号は、AVエンコーダ１５にのみ出力される。解析部１４は、入力されたビデオ信号からシーンチェンジなどの特徴点を抽出する。
【００２９】
AVエンコーダ１５は、入力されたビデオ信号とオーディオ信号を、それぞれ符号化し、符号化ビデオストリーム(V)、符号化オーディオストリーム(A)、およびAV同期等のシステム情報(S)をマルチプレクサ１６に出力する。
【００３０】
符号化ビデオストリームは、例えば、MPEG（Moving Picture Expert Group）２方式により符号化されたビデオストリームであり、符号化オーディオストリームは、例えば、MPEG１方式により符号化されたオーディオストリームや、ドルビーAC3方式により符号化されたオーディオストリーム等である。マルチプレクサ１６は、入力されたビデオおよびオーディオのストリームを、入力システム情報に基づいて多重化して、スイッチ１７を介して多重化ストリーム解析部１８とソースパケッタイザ１９に出力する。
【００３１】
多重化ストリームは、例えば、MPEG2トランスポートストリームやMPEG2プログラムストリームである。ソースパケッタイザ１９は、入力された多重化ストリームを、そのストリームを記録させる記録媒体１００のアプリケーションフォーマットに従って、ソースパケットから構成されるAVストリームを符号化する。AVストリームは、ECC（誤り訂正）符号化部２０、変調部２１で所定の処理が施され、書き込み部２２に出力される。書き込み部２２は、制御部２３から出力される制御信号に基づいて、記録媒体１００にAVストリームファイルを書き込む（記録する）。
【００３２】
デジタルインタフェースまたはデジタルテレビジョンチューナから入力されるデジタルテレビジョン放送等のトランスポートストリームは、端子１３に入力される。端子１３に入力されたトランスポートストリームの記録方式には、２通りあり、それらは、トランスペアレントに記録する方式と、記録ビットレートを下げるなどの目的のために再エンコードをした後に記録する方式である。記録方式の指示情報は、ユーザインターフェースとしての端子２４から制御部２３へ入力される。
【００３３】
入力トランスポートストリームをトランスペアレントに記録する場合、端子１３に入力されたトランスポートストリームは、多重化ストリーム解析部１８と、ソースパケッタイザ１９に出力される。これ以降の記録媒体１００へAVストリームが記録されるまでの処理は、上述の入力オーディオ信号とビデオ信号を符号化して記録する場合と同一の処理なので、その説明は省略する。
【００３４】
入力トランスポートストリームを再エンコードした後に記録する場合、端子１３に入力されたトランスポートストリームは、デマルチプレクサ２６に入力される。デマルチプレクサ２６は、入力されたトランスポートストリームに対してデマルチプレクス処理を施し、ビデオストリーム(V)、オーディオストリーム(A)、およびシステム情報(S)を抽出する。
【００３５】
デマルチプレクサ２６により抽出されたストリーム（情報）のうち、ビデオストリームはAVデコーダ２７に、オーディオストリームとシステム情報はマルチプレクサ１６に、それぞれ出力される。AVデコーダ２７は、入力されたビデオストリームを復号し、その再生ビデオ信号をAVエンコーダ１５に出力する。AVエンコーダ１５は、入力ビデオ信号を符号化し、符号化ビデオストリーム(V)をマルチプレクサ１６に出力する。
【００３６】
一方、デマルチプレクサ２６から出力され、マルチプレクサ１６に入力されたオーディオストリームとシステム情報、および、AVエンコーダ１５から出力されたビデオストリームは、入力システム情報に基づいて、多重化されて、多重化ストリームとして多重化ストリーム解析部１８とソースパケットタイザ１９にスイッチ１７を介して出力される。これ以後の記録媒体１００へAVストリームが記録されるまでの処理は、上述の入力オーディオ信号と、ビデオ信号を符号化して記録する場合と同一の処理なので、その説明は省略する。
【００３７】
本実施の形態の記録再生装置１は、AVストリームのファイルを記録媒体１００に記録すると共に、そのファイルを説明するアプリケーションデータベース情報も記録する。アプリケーションデータベース情報は、制御部２３により作成される。制御部２３への入力情報は、解析部１４からの動画像の特徴情報、多重化ストリーム解析部１８からのAVストリームの特徴情報、および端子２４から入力されるユーザからの指示情報である。
【００３８】
解析部１４から供給される動画像の特徴情報は、入力動画像信号の中の特徴的な画像に関係する情報であり、例えば、プログラムの開始点、シーンチェンジ点、コマーシャル（ＣＭ）の開始・終了点などの指定情報（マーク）であり、また、その指定場所の画像のサムネイル画像の情報も含まれる。
【００３９】
多重化ストリーム解析部１８からのAVストリームの特徴情報は、記録されるAVストリームの符号化情報に関係する情報であり、例えば、AVストリーム内のIピクチャのアドレス情報、AVストリームの符号化パラメータ、AVストリームの中の符号化パラメータの変化点情報、ビデオストリームの中の特徴的な画像に関係する情報（マーク）などである。
【００４０】
端子２４からのユーザの指示情報は、AVストリームの中の、ユーザが指定した再生区間の指定情報、その再生区間の内容を説明するキャラクター文字、ユーザが好みのシーンにセットするブックマークやリジューム点の情報などである。
【００４１】
制御部２３は、上記の入力情報に基づいて、AVストリームのデータベース(Clip)、AVストリームの再生区間(PlayItem)をグループ化したもの（PlayList）のデータベース、記録媒体１００の記録内容の管理情報(info.dvr)、およびサムネイル画像の情報を作成する。これらの情報から構成されるアプリケーションデータベース情報は、AVストリームと同様にして、ECC符号化部２０、変調部２１で処理されて、書き込み部２２へ入力される。書き込み部２２は、制御部２３から出力される制御信号に基づいて、記録媒体１００へデータベースファイルを記録する。
【００４２】
上述したアプリケーションデータベース情報についての詳細は後述する。
【００４３】
このようにして記録媒体１００に記録されたAVストリームファイル（画像データと音声データのファイル）と、アプリケーションデータベース情報が再生される場合、まず、制御部２３は、読み出し部２８に対して、記録媒体１００からアプリケーションデータベース情報を読み出すように指示する。そして、読み出し部２８は、記録媒体１００からアプリケーションデータベース情報を読み出し、そのアプリケーションデータベース情報は、復調部２９、ECC復号部３０の処理を経て、制御部２３へ入力される。
【００４４】
制御部２３は、アプリケーションデータベース情報に基づいて、記録媒体１００に記録されているPlayListの一覧を端子２４のユーザインターフェースへ出力する。ユーザは、PlayListの一覧から再生したいPlayListを選択し、再生を指定されたPlayListに関する情報が制御部２３へ入力される。制御部２３は、そのPlayListの再生に必要なAVストリームファイルの読み出しを、読み出し部２８に指示する。読み出し部２８は、その指示に従い、記録媒体１００から対応するAVストリームを読み出し復調部２９に出力する。復調部２９に入力されたAVストリームは、所定の処理が施されることにより復調され、さらにECC復号部３０の処理を経て、ソースデパケッタイザ３１出力される。
【００４５】
ソースデパケッタイザ３１は、記録媒体１００から読み出され、所定の処理が施されたアプリケーションフォーマットのAVストリームを、デマルチプレクサ２６に出力できるストリームに変換する。デマルチプレクサ２６は、制御部２３により指定されたAVストリームの再生区間(PlayItem)を構成するビデオストリーム(V)、オーディオストリーム(A)、およびAV同期等のシステム情報(S)を、AVデコーダ２７に出力する。AVデコーダ２７は、ビデオストリームとオーディオストリームを復号し、再生ビデオ信号と再生オーディオ信号を、それぞれ対応する端子３２と端子３３から出力する。
【００４６】
また、ユーザインタフェースとしての端子２４から、ランダムアクセス再生や特殊再生を指示する情報が入力された場合、制御部２３は、AVストリームのデータベース(Clip)の内容に基づいて、記憶媒体１００からのAVストリームの読み出し位置を決定し、そのAVストリームの読み出しを、読み出し部２８に指示する。例えば、ユーザにより選択されたPlayListを、所定の時刻から再生する場合、制御部２３は、指定された時刻に最も近いタイムスタンプを持つIピクチャからのデータを読み出すように読み出し部２８に指示する。
【００４７】
また、ユーザによって高速再生(Fast-forward playback)が指示された場合、制御部２３は、AVストリームのデータベース(Clip)に基づいて、AVストリームの中のI-ピクチャデータを順次連続して読み出すように読み出し部２８に指示する。
【００４８】
読み出し部２８は、指定されたランダムアクセスポイントからAVストリームのデータを読み出し、読み出されたデータは、後段の各部の処理を経て再生される。
【００４９】
次に、ユーザが、記録媒体１００に記録されているAVストリームの編集をする場合を説明する。ユーザが、記録媒体１００に記録されているAVストリームの再生区間を指定して新しい再生経路を作成したい場合、例えば、番組Ａという歌番組から歌手Ａの部分を再生し、その後続けて、番組Ｂという歌番組の歌手Ａの部分を再生したいといった再生経路を作成したい場合、ユーザインタフェースとしての端子２４から再生区間の開始点（イン点）と終了点（アウト点）の情報が制御部２３に入力される。制御部２３は、AVストリームの再生区間(PlayItem)をグループ化したもの（PlayList）のデータベースを作成する。
【００５０】
ユーザが、記録媒体１００に記録されているAVストリームの一部を消去したい場合、ユーザインタフェースとしての端子２４から消去区間のイン点とアウト点の情報が制御部２３に入力される。制御部２３は、必要なAVストリーム部分だけを参照するようにPlayListのデータベースを変更する。また、AVストリームの不必要なストリーム部分を消去するように、書き込み部２２に指示する。
【００５１】
ユーザが、記録媒体１００に記録されているAVストリームの再生区間を指定して新しい再生経路を作成したい場合であり、かつ、それぞれの再生区間をシームレスに接続したい場合について説明する。このような場合、制御部２３は、AVストリームの再生区間(PlayItem)をグループ化したもの（PlayList）のデータベースを作成し、さらに、再生区間の接続点付近のビデオストリームの部分的な再エンコードと再多重化を行う。
【００５２】
まず、端子２４から再生区間のイン点のピクチャの情報と、アウト点のピクチャの情報が制御部２３へ入力される。制御部２３は、読み出し部２８にイン点側のピクチャとアウト点側のピクチャを再生するために必要なデータの読み出しを指示する。そして、読み出し部２８は、記録媒体１００からデータを読み出し、そのデータは、復調部２９、ECC復号部３０、ソースデパケッタイザ３１を経て、デマルチプレクサ２６に出力される。
【００５３】
制御部２３は、デマルチプレクサ２６に入力されたデータを解析して、ビデオストリームの再エンコード方法（picture_coding_typeの変更、再エンコードする符号化ビット量の割り当て）と、再多重化方式を決定し、その方式をAVエンコーダ１５とマルチプレクサ１６に供給する。
【００５４】
次に、デマルチプレクサ２６は、入力されたストリームをビデオストリーム(V)、オーディオストリーム(A)、およびシステム情報(S)に分離する。ビデオストリームは、「AVデコーダ２７に入力されるデータ」と「マルチプレクサ１６に入力されるデータ」がある。前者のデータは、再エンコードするために必要なデータであり、これはAVデコーダ２７で復号され、復号されたピクチャはAVエンコーダ１５で再エンコードされて、ビデオストリームにされる。後者のデータは、再エンコードをしないで、オリジナルのストリームからコピーされるデータである。オーディオストリーム、システム情報については、直接、マルチプレクサ１６に入力される。
【００５５】
マルチプレクサ１６は、制御部２３から入力された情報に基づいて、入力ストリームを多重化し、多重化ストリームを出力する。多重化ストリームは、ECC符号化部２０、変調部２１で処理されて、書き込み部２２に入力される。書き込み部２２は、制御部２３から供給される制御信号に基づいて、記録媒体１００にAVストリームを記録する。
【００５６】
このような記録再生装置１において記録媒体１００に記録されるデータ（記録媒体１００から再生されるデータ）について説明する。MPEG Video、MPEG Audio等の符号化方式で符号化され、MPEG-2 Systemsに従って多重化されたビットストリームを、ファイルシステムが扱うファイルの形にしてディスク（以下、適宜、記録媒体１００をディスク状の記録媒体とし、ディスクと称する）に記録したものをAV(Audio Video)ストリームファイル（またはClip AVストリーム）と称する。
【００５７】
このようなAVストリームファイルの一部または全部の範囲を指定して、必要な部分だけを並べて再生する再生順序指定の仕組みを説明する。図２のように、AVストリームファイルの一部または全部の範囲を指定して、必要な部分だけを再生する再生順序指定がPlaylistである。Playlistは、ユーザから見て、ひとまとまりの単位である。最も簡単な構成になるのは、記録開始をしてから記録終了までの単位で、編集をしなければ、これが１つのPlaylistになる。
【００５８】
Playlistは、どのAVストリームを再生するかという、AVストリームファイルの指定と、そのファイル中の再生開始点（イン点）と再生終了点（アウト点）の集まりで構成される。AVストリームファイル、再生開始点、再生終了点等を１組とし、これをPlayitemと称する。すなわち、PlaylistはPlayitemの集合である。
【００５９】
図２に示したように、Playitemは、あるAVストリームファイルの、イン点、アウト点で指定する範囲を参照する。Playitemを再生するということは、そのPlayitemが参照するAVストリームの一部分を再生するということになる。
【００６０】
AVストリームは、MPEG-TSの形などにマルチプレクスされているビットストリームであるが、このAVストリームが記録されるファイルとは別のファイルに、そのビットストリームに対して１対１に対応する情報（クリップ情報：Clip information）を保持する。これは、再生、編集をより容易にするために設けられている。このようなクリップ情報と、AVストリームの両方をひとまとまとり（オブジェクト）とみなし、これをClip（クリップ）と呼ぶ。すなわち、ClipはAVストリームと、それに付随する情報から構成される１つのオブジェクトである。
【００６１】
以上のような、関係をUML図で表すと、図３のようになる。図３のUML図で表されるAVストリームファイル、Clip、Playitem、Playlistの構造により、AVストリームファイルを変更しない、任意の部分だけを再生する非破壊再生順序指定が可能になる。
【００６２】
次に、本発明を実現するための、各種の情報が記録または再生される記録媒体（メディア）上のファイル配置について説明する。メディア上には、図４に示すように、info.dvr、menu.thmb（mark.thmb）、#####.rpls（#####.vpls） (#####は任意の番号)、%%%%%.clpi (%%%%%は任意の番号)、および %%%%%.m2ts (%%%%%は、各m2tsファイルがcpliファイルと１対１に対応するような番号)の、５種類のファイルが記録される。
【００６３】
ディスク上にディレクトリ/DVRを用意し、このディレクトリの下が、１つのディスク記録再生システムで管理される範囲とする。/DVRは、ディスクのルートディレクトリにあっても良いし、所定のディレクトリの下に存在していても良い。/DVRディレクトリには、info.dvr、 menu.thmb、 mark.thmbというファイルが置かれる。また、/DVRの下には、/PLAYLIST、 /CLIPINF、 /M2TSというディレクトリが置かれる。ファイル#####.rpls、 #####.vplsは、/PLAYLISTの下に置かれ、/CLIPINFには%%%%%.clpiが置かれ、/M2TSには、%%%%%.m2tsが置かれる。
【００６４】
ファイルinfo.dvrは、/DVRの下にだた１つある。info.dvrの構造は、図５に示したようなシンタクスで表される。ファイルの内部は、機能別の情報ごとにブロックを構成しており、volumeに関する情報はDVRVolume()に、 Playlistの並びに関する情報はTableOfPlayLists()に、記録再生装置１のメーカ固有の情報はMakerPrivateData()に、それぞれ格納される。ファイルの先頭部分には、それらのブロックの先頭を表すアドレスが記述されている。例えば、TableOfPlayLists_Start_addressは、TableOfPlayLists()が開始する位置を、ファイル内での相対バイト数で表したものになっている。
【００６５】
DVRVolume()の構造は図６に示したようなシンタクスで表される。version_numberは、DVRVolume()のバージョン番号を表し、lengthは、length直後のフィールドからDVRVolume()の最後までの長さをバイトで表したものである。ResumeVolume()はresumeに関する情報を格納し、UIAppInfoVolume()はVolumeの属性情報を格納する領域である。
【００６６】
図７は、UIAppInfoVolume()のシンタクスを表したものである。character_setは、Volume_nameフィールドに符号化されているキャラクター文字の符号化方法を示す。その符号化方法としては、ASCII、Unicode等を選択できる。name_lengthは、Volume_nameフィールドの中に示されるボリューム（ディスク）名のバイト長を示す。Volume_nameは、ボリューム（ディスク）の名前を示す。このフィールドの中の左からname_length数のバイト数が、有効なキャラクター文字であり、それはボリューム（ディスク）の名前を示す。
【００６７】
Volume_nameフィールドの中で、それら有効なキャラクター文字の後の値は、どんな値が入っていても良い。Volume_protect_flagは、そのボリュームの中のコンテンツをユーザに制限することなしに見せてよいかどうかを示すフラグである。このフラグが１にセットされている場合、ユーザが正しくPIN番号（図７中のPIN）を入力できた場合にだけ、ユーザは、そのボリュームのコンテンツを視聴する事ができる。このフラグが０にセットされている場合、ユーザがPIN番号を入力しなくても、ユーザが、そのボリュームのコンテンツを視聴する事ができる。最初に、ユーザが、ディスクをプレーヤ（記録再生装置１）へ挿入した時において、もしこのフラグが０にセットされているか、または、このフラグが１にセットされていてもユーザがPIN番号を正しく入力できたならば、プレーヤーは、そのセットされたディスクの中のPlayListの一覧を表示させる。
【００６８】
以上は、Volumeに対しての再生制限であるが、それぞれのPlayListの再生制限については、Volume_protect_flagとは無関係であり、それは後述する図９のUIAppInfoPlayList()の中で定義されるplayback_control_flagによって示される。PINは、４個の０乃至９までの数字であり、それぞれの数字は、ISO/IEC 646に従って符号化される。ref_thumbnail_indexは、Volumeを代表するサムネイルが存在する場合、そのサムネイルを特定するための番号を格納する領域である。ref_thumbnail_indexで指定されるthumbnail_indexを持つ、ファイルmenu.thmb中のサムネイルが、Volumeを代表するメニューサムネイル（本発明では、VolumeやPlaylistを代表するサムネイルを特にメニューサムネイルと称する）となる。
【００６９】
rp_info_valid_flagは、これが１である場合に次に続くrp_ref_to_PlayList_file_name, rp_ref_to_PlayItem_idおよびrp_time_stampが有効な値を持つこと示す。rp_ref_to_PlayList_file_nameは、上記のVolumeを代表するメニューサムネイルが、所定のPlayList中の画像から抜き出された画像から作られていることを示し、そのPlayListファイルの名前を示す。
【００７０】
rp_ref_to_PlayItem_idは、rp_ref_to_PlayList_file_nameで示されるPlayListの中の１つのPlayItemを指すPlayItem_idを示し、上記のVolumeを代表するメニューサムネイルが、そのPlayItem中の画像から抜き出された画像から作られていることを示す。rp_time_stampは、rp_ref_to_PlayItem_idが指すPlayItem中の１つの画像のプレゼンテーションタイムスタンプを示し、その画像から上記のVolumeを代表するメニューサムネイルが作られていることを示す。
【００７１】
図８は、TableOfPlayLists()のシンタクスを表したものである。ここでnumber_of_PlayListsはVolume中のPlaylistの数を表し、PlayList_file_nameは#####.rpls、 #####.vpls等のファイル名を指定するものである。UIAppInfoPlayList()には、Playlistの各種属性がかかれており、シンタクスは図９のようになっている。図９に示したUIAppInfoPlayList()には、Playlistの再生には直接必要ではない、Playlistの名前、記録日時、記録時間、消去禁止の有無等の、各種属性情報が格納される。その中のref_thumbnail_indexにより、PlayListの代表画としてのサムネイルを指定することができる。すなわち、ref_thumbnail_indexで指定されるthumbnail_indexを持つ、ファイルmenu.thmb中のサムネイルが、このPlaylistを代表するメニューサムネイルとなる。
【００７２】
rp_info_valid_flagは、これが１である場合に、次に続くrp_ref_to_PlayItem_idおよびrp_time_stampが有効な値を持つこと示す。rp_ref_to_PlayItem_idは、PlayListの中の１つのPlayItemを指すPlayItem_idを示し、PlayListを代表するメニューサムネイルが、そのPlayItem中の画像から抜き出された画像から作られていることを示す。rp_time_stampは、rp_ref_to_PlayItem_idが指すPlayItem中の１つの画像のプレゼンテーションタイムスタンプを示し、その画像からPlayListを代表するメニューサムネイルが作られていることを示す。
【００７３】
図４に示したファイル%%%%%.clpiは、/CLIPINFの下に、各AVストリームファイル%%%%%.m2tsに対応して１つ作られる。%%%%%.clpiの構造は、図１０に示すようになっている。ファイルの内部は、機能別の情報ごとにブロックを構成しており、Clipに関する情報はClipInfo()に、MPEG-2 systemsにおけるトランスポートストリームの時刻基準を表すPCR（プログラムクロックリファレンス）の不連続点に関する情報はSTC_Info()に、MPEG-2 systemsのprogram（プログラム）に関する情報はProgramInfo()に、 AVストリーム中のランダムアクセス開始可能点等の特徴的な点を表すCPI（Characteristic Point Information）に関する情報はCPI()に、Clipにつけられた、頭出しのためのインデックス点やコマーシャルの開始・終了点などのマーク情報はClipMark()に、それぞれ格納される。ファイルの先頭部分には、それらのブロックの先頭を表すアドレスが記述されている。
【００７４】
ここでは、サムネイルに関係するブロックだけを説明する。本実施の形態においては、クリップにサムネイルを付ける操作は、クリップのマークにサムネイルを付与することで実現する。クリップに付けられるマークの情報は、 ClipMark()に格納されている。図１１に、ClipMark()のシンタクスを示す。シンタクス中のmark_typeが、resume、 bookmark、 skip等のマークの種類を表し、mark_time_stampでマークがつけられた時刻を表す。サムネイルに関係するフィールドは、ref_thumbnail_index である。ref_thumbnail_indexは、ここでサムネイルの番号を指定することで、サムネイルのデータが格納されているmark.thmbファイル中のサムネイルを特定する。ref_thumbnail_indexで指定されるサムネイルが、このマークに付与されたマークサムネイル（本発明では、マークに付与されたサムネイルを特にマークサムネイルと称する）となる。
【００７５】
マークは、主としてClipおよびPlaylistの中のハイライトや特徴的なシーンを指し示すためにある。また、マークより後の部分は再生を飛ばして、次のPlaylistの再生をするように指示するスキップ機能も、マークによって実現できる。図１２は、マークがClip、Playlistに付けられている様子を図で示したものである。以下にマークの特徴をまとめる。
【００７６】
Clipに付加されるマークは、AVストリームの内容に起因する特徴的なシーン、例えば、シーンチェンジ点などを指定する。Playlistを再生する時には、そのPlaylistが参照しているClip中のマークを利用してランダムアクセス等ができる。図１２では、Clipに対してcommercial（ＣＭ）とsceneという、２種類のマークが付けられているが、commercialのマークは左のPlaylistから、sceneマークは二つのPlaylistから利用されている。Playlistに付加されるマークは、主としてユーザによって設定される。例えば、ブックマークやリジューム点などである。図１２では、bookmarkとresumeマークが相当する。
【００７７】
ClipまたはPlaylistにマークを設定することは、マークの時刻を示すタイムスタンプをマークリストに追加することにより行われる。また、マークを削除することは、マークリストの中からそのマークのタイムスタンプを除去する事である。それゆえ、マークの設定や削除は、AVストリームを何も変化させない。
【００７８】
次に、図４に示したファイル#####.rpls、#####.vplsについて説明するに、ファイル#####.rpls、 #####.vplsは、/PLAYLISTの下に、各playlistに対してどちらか１つ作られる。#####.rpls、#####.vplsの構造は、図１３に示すようになっている。ファイルの内部は、機能別の情報ごとにブロックを構成しており、Playlistに関する情報はPlayList()に、Playlistに付けられるマークの情報はPlayListMark()に、このPlaylistファイルを記録した記録再生装置のメーカ固有の情報はMakerPrivateData()に、それぞれ格納される。ファイルの先頭部分には、ブロックの先頭を表すアドレス(PlayListMark_Start_address等)が記述されている。これにより、ブロックの前あるいは後ろにpadding_byteを挿入することが出来る。ただし、PlayList()の開始位置は固定で、ファイルの先頭から、例えば、256バイト目と設定されている。
【００７９】
ブロックPlayList()の内容は、図１４のようになっている。最初にversion_numberがあり、以下に続く情報のバージョン番号を表す。lengthは、lengthの直後のフィールドから、PlayList()の終わりまでのバイト長を表す。PlayList_typeは、このPlaylistの種類を表し、CPI_typeは、このPlaylistが持つCPIの種類を表す。number_of_PlayItemsは、このPlaylistを構成するPlayitemの数を表す。number_of_SubPlayItemsは、このPlaylistに付けられているアフレコオーディオ用のPlayitem(SubPlayitem)の数を表す。PlayItem()は、Playitemの情報を、SubPlayItem()は、SubPlayitemの情報を格納する。
【００８０】
ブロックPlayItem()の内容は、図１５のようになっている。Clip_Information_file_nameは、このPlayItemが参照しているClip情報ファイル（拡張子がclpiであるファイル）のファイル名が文字列で格納されている。STC_sequence_idは、program中に存在する、PCRが連続な時間範囲の区間をあらわす。この区間内では、一貫した連続時間軸が定義できるようになっているので、PlayItemの開始・終了点を一意に定めることが出来る。つまり、各PlayItemの開始点と終了点は、同一のSTC_sequenceに存在していなければならない。
【００８１】
IN_timeは、このPlayItemの開始点の、STC_sequence 上でのpts（Presentation Time Stamp）を表し、OUT_time はPlayItemの終了点の、STC_sequence 上でのptsを表す。connection_conditionは、このPlayitemが次のPlayitemとの間でどのような接続がされているかを表す情報であり、Playitemの間を継ぎ目なく再生できるかどうかの条件を表す。
【００８２】
BridgeSequnceInfo()は、Playitemの継ぎ目の部分で、本来再生すべきビットストリームとは異なるビットストリームに飛び、それを代わりに再生することで、Playitemの間をシームレスに再生する機能を実現する際に作成されるビットストリーム（ブリッジシーケンス）に関する情報を格納する。program_numberは、このPlayitemが参照しているprogram(MPEG Systemsで定義されている、ビデオ・オーディオ等のエレメンタリストリームのまとまりをいう。いわゆるテレビジョン放送のチャンネルに相当するものである）のprogram_numberを表す。
【００８３】
以上が、Playlist、Playitemを構成するデータ構造の概要である。このようなデータ構造により、AVストリーム中の再生したい部分をIN、OUT点の組で指定したPlayitemの並びでPlaylistを構築し、ユーザが認識するひとまとまりの再生単位を管理することが可能になる。
【００８４】
本発明の実施の形態では、プレイリスト上の任意の時刻にサムネイルを付ける操作は、プレイリストのマークにサムネイルを付与することで実現している。Playlistに付けられるマークの情報は、PlayListMark()に格納されている。図１６は、PlaylistMark()のシンタクスを示す図である。シンタクス中のmark_typeが、resume、 bookmark、 skip等のマークの種類を表し、mark_time_stampでマークがつけられた時刻を表す。ref_thumbnail_indexは、ここでサムネイルの番号を指定することで、サムネイルのデータが格納されているmark.thmbファイル中のサムネイルを特定する。ref_thumbnail_indexで指定されるサムネイルが、このマークに対応するマークサムネイルとなる。
【００８５】
次に、サムネイルの詳細について説明する。サムネイルとは、Volume、Playlist、Clipに付随する静止画のことを指す。サムネイルには２種類ある。一つは、内容を表す代表画としてのサムネイルである。これは主としてユーザがカーソルを操作して見たいものを選択するためのメニュー画面で使われる。もう一つは、マークが指しているシーンを表す画像である。
【００８６】
Volumeと各Playlistは代表画を持つことができるようにする必要がある。Volumeの代表画とは、ディスクをプレーヤに入れた時に、ディスクの内容を表す静止画を最初に表示する場合などに用いることを想定している。Playlistの代表画とは、Playlistを選択するメニュー画面において、Playlistの内容を表すための静止画として用いられることを想定している。
【００８７】
Playlistの代表画の最も簡単な実現方法は、Playlistの最初の画像をサムネイルにすることであるが、必ずしも再生時刻0の先頭の画像が内容を表す上で最適な画像とは限らない。そこで、Playlistのサムネイルとして、任意の画像を決めることが出来るようにしておく。以上２種類のサムネイルをメニューサムネイルと称する。メニューサムネイルは、頻繁に表示されるため、ディスクから高速に読み出されることが可能である必要がある。この要求を満たすには、全てのメニューサムネイルを１つのファイルに格納することが効率的である。必ずしもボリューム内の動画から抜き出したピクチャだけではなく、図１７に示すように、パーソナルコンピュータやデジタルスチルカメラから取り込んだ画像でもよい。
【００８８】
一方、ClipとPlaylistは複数個のマークを打てる必要があり、マーク位置の内容を知るためにマーク点の画像を容易に見ることが出来るようにする必要がある。このようなマーク点を表すピクチャをマークサムネイルと称する。よって、サムネイルの元となるものは、図１８や図１９に示したように、外部から取り込んだ画像よりも、マーク点の画像を抜き出したものが主となる。メニューサムネイルと異なり、マークサムネイルはPlaylistの詳細を表す時に使われるサブメニュー等で使われるため、短いアクセス時間で読み出されなくても良い。
【００８９】
そのため、サムネイルが必要になる度に、プレイヤーがファイルを開き、ファイルの一部を読み出すことで多少時間がかかっても、問題にはならない。また、ボリューム内に存在するファイル数を減らすために、すべてのマークサムネイルは一つのファイルに格納するのがよい。Playlistはメニューサムネイル一つと複数のマークサムネイルを有することができるが、Clipは直接ユーザが選択する必要性がない（通常、Playlist経由で指定する）ため、メニューサムネイルを持つことはしない。図２０は、以上の関係を示した図である。
【００９０】
サムネイルは頻繁に追加、削除されるので、追加操作と部分削除の操作は容易に、かつ、高速に実行されなければならない。この理由のため、Thumbnail()はブロック構造を有する。画像のデータはいくつかの部分に分割され、各部分は１つのtn_block()に格納される。１つの画像データは、連続したtn_block()に格納される。tn_block()の列には、使用されていないtn_block()が存在してもよい。１つのサムネイル画像のバイト長は可変である。
【００９１】
図２１は、サムネイルのデータを格納するファイルのシンタクスである。このファイルには、Thumbnail()がただ一つ存在する。図２２は、thubnail()のシンタクスを表す。version_numberは、このthumbnail()のバージョンナンバーを示す4個のキャラクター文字を表す。lengthは、このlengthフィールドの直後からthumbnail()の最後までのthumbnail()のバイト数を示す３２ビットの符号なし整数である。tn_blocks_start_addressは、thumbnail()中の最初のtn_block()の、thumbnail()の先頭からの開始バイトアドレスを示す３２ビットの符号なし整数である。
【００９２】
number_of_thumbnailsは、このthumbnail()に格納されているサムネイル画像の数を示す１６ビットの符号なし整数である。tn_block_sizeは、1 tn_block()の大きさをキロバイト単位で表す１６ビットの符号なし整数である。例えば、tn_block_size が１であるのは、１つのtn_block()のサイズが1024バイトであることを表す。number_of_tn_blocksは、この thumbnail()中のtn_block()の数を表す１６ビットの符号なし整数である。
【００９３】
thumbnail_indexは、このthumbnail_indexフィールドから始まるforループ１回分のサムネイル情報で表されるサムネイルのインデクス番号を表す１６ビットの符号なし整数である。 thumbnail_index として、0xFFFF という値を使用してはならない。thumbnail_index はref_thumbnail_indexによって参照される。tumbnail_picture_format は、サムネイル画像のピクチャフォーマットを表す８ビットの符号なし整数で、図２３に示したような値をとる。図２３中のDCF（Design rule for Camera File System）とPNG（Portable Network Graphics）は”menu.thmb”内でのみ許される。すなわちマークサムネイルは、値"0x00" (MPEG-2 Video I-picture)ととらなければならない。
【００９４】
picture_data_size は、符号化されたサムネイル画像のバイト長を表す３２ビットの符号なし整数である。start_tn_block_numberは、サムネイル画像のデータが始まるtn_block()のtn_block_numberを表す１６ビットの符号なし整数である。サムネイル画像データの先頭は、tb_blockの先頭と一致していなければならない。start_tn_block_number は、０から始まり、tn_blockのfor-ループ中の変数kの値に関係している。x_picture_length は、サムネイル画像の水平方向のピクセル数を表す１６ビットの符号なし整数である。
【００９５】
y_picture_lengthは、サムネイル画像の垂直方向のピクセル数を表す１６ビットの符号なし整数である。tn_block() は、ピクチャデータを格納する領域である。thumbnail()中のすべてのtn_block()は、tn_block_size で定められる同一の大きさを有していなければならない。図２４は、画像データがどのようにtn_block()に格納されるかを模式的に表した図である。図２４に示したように、各画像データはtn_block()の先頭から始まり、1tn_block()を超える大きさの場合は、連続する次のtn_block()を使用することにより格納される。
【００９６】
画像データは、可変長であるが、１tn_block()は、固定長である。このように、可変長であるデータを固定長のデータに変換して扱うようにすることにより、新たな画像データの追加や、画像データの削除といった処理に対してブロック単位で対処できるため、アドレスの管理など、簡便に行うことが可能となる。
【００９７】
ここで、サムネイル記録についてのディレクトリ・ファイル構造、シンタックスの別案を示す。まず、図４で表されるディレクトリ・ファイル構造の別案として、図２５の構造が考えられる。図４では、マークサムネイルを記録するためのファイルが/DVRの下に１つ、mark.thmbだけであるのに対し、図２５では、プレイリスト、クリップごとに１対１に対応してファイルxxxxx.thmb(xxxxxは対応するプレイリストまたはクリップをあらわす、拡張子を除いたファイル名)が作られている。
【００９８】
例えば、#####.rplsで表されるプレイリストが有するマークサムネイルの画像は、同じディレクトリ内の#####.thmbに格納されることになる。同様に、%%%%%.clpiで表されるクリップが有するマークサムネイルの画像は、同じディレクトリ内の%%%%%.thmbに格納されることになる。プレイリスト・クリップのマークサムネイルは、ファイルの拡張子を除いた名前の部分が同一の.thmbファイルに記録されるという制約があるだけで、xxxxx.thmb内のシンタックスは、図２６のように、menu.thmbやmark.thmb（図２１）と同一である。
【００９９】
また、プレイリストのメニューサムネイルについて、図８、図９では、サムネイルを特定するref_thumbnail_indexを、ファイルInfo.dvrのTableOfPlayLists()の中のUIAppInfoPlayList()に置いているが、UIAppInfoPlayList()をInfo.dvrではなく、各プレイリストファイル中に入れる方法もある。このような場合、UIAppInfoPlayList()を、TableOfPlayLists()から、プレイリストファイル中のplaylist()へ移すことになり、図８に示したシンタクスは図２７に示すシンタクスのようになり、図１４に示したシンタクスは図２８に示すシンタクスのようになる。図２８中のUIAppInfoPlayList()は、図２９に示すシンタクスのようになり、ここにref_thumbnail_indexが入る。
【０１００】
以上のようなファイル、シンタックスでもサムネイルの記録が可能である。
【０１０１】
次に、図３０に示したフローチャートを参照して、マークサムネイルの作成について説明する。ステップＳ１において、ユーザは、再生したいPlayList（プレイリスト）を選択する。ステップＳ２において、選択されたPlayListに基づいて、AVストリームの再生が開始される。ステップＳ３において、ユーザは、再生されているAVストリームを視聴し、マークしたいシーンを探索する。ユーザは、マークしたいシーンが探索できた場合、記録再生装置１に付属するリモートコントローラ（不図示）のマークボタンを操作する。この操作は、再生中に操作されても、一時停止された状態で操作されても良い。
【０１０２】
ステップＳ３において、ユーザによりマークボタンが操作されると、ステップＳ４において、ユーザの指示に対応する処理としてマーク位置が決定される。マーク位置が決定されると、ステップＳ５において、サムネイル画像にする画像の選択が行われる。マーク位置が指示された時点で、制御部２３（図１）は、サムネイルを作成するかどうかをユーザに尋ね、作成する場合には、サムネイルとする画像の候補をコマ送り等によりユーザに提供し、ユーザがサムネイル画像を選択するようにしても良い。
【０１０３】
ユーザ、または、制御部２３により、サムネイル画像にする画像が選択されると、制御部２３は、ステップＳ６において、AVデコーダ１５から画像を取り込み制御部２３のRAM（Random Access Memory）（不図示）に転送する。ステップＳ７において、画像を圧縮するか否かが判断され、画像を圧縮すると判断された場合、制御部２３は、ステップＳ８に進み、画像圧縮を行い、再びデータをRAMに戻す。ステップＳ７において、画像を圧縮しないと判断された場合、ステップＳ８の処理はスキップされ、ステップＳ９に進む。
【０１０４】
ステップＳ９において、制御部２３は、サムネイルの符号化方式、サムネイルを識別するthumbnail_id、サイズ（バイト数）、X、Y方向のピクセル数から構成されるサムネイルのヘッダ情報を作成し、画像データをtn_block()の単位に分割する。ステップＳ１０において、ECC符号化ブロック２０にヘッダ情報とtn_block()の形に分割した画像データが転送され、書き込み部２２を経て、mark.thmbファイルとして記録媒体１００に書き込まれる。
【０１０５】
次に、メニューサムネイルを作成について、図３１に示したフローチャートを参照して説明する。メニューサムネイルはボリュームまたは各プレイリストに対して付けられるので、制御部２３は、ステップＳ２１において、ユーザに対して、メニューサムネイルをつける対象を選択させる。ステップＳ２２において、制御部２３は、サムネイルを外部から取り込むか、プレイリスト中のあるシーンから取り込むかをユーザに選択させる。
【０１０６】
ステップＳ２２において、サムネイルを外部から取り込むと判断された場合、ステップＳ２３に進み、ユーザが指定した入力端子あるいはファイルから画像データが取り込まれる。取り込みが終了されると、ステップＳ２６に進む。
【０１０７】
一方、ステップＳ２２において、サムネイルを外部から取り込むのではないと判断された場合、ステップＳ２４に進み、制御部２３は、まず、ユーザに対して、どのプレイリストからサムネイル画像を取得するのかを選択させ、その後、選択されたプレイリストの再生を開始する。そして、ステップＳ２５において、ユーザにサムネイルにしたいシーンを選択させる。
【０１０８】
ステップＳ２３、或いは、ステップＳ２５において、サムネイル画像が選択されると、ステップＳ２６に進む。ステップＳ２６以降の処理は、図３０に示したフローチャートのステップＳ５以降の処理と同様であるので、その説明は省略する。
【０１０９】
このように、サムネイル画像をプレイリストに付与することにより、それらのサムネイル画像を管理しやすくなり、記録されているＡＶストリームを再生する際にも、再生させるＡＶストリームの選択などの処理を簡便に行わせることが可能となる。
【０１１０】
図３２は、ディスク上につくられるディレクトリおよびファイルの別の例を示す図である。"menu.tidx"と"menu.tdat"は、メニューサムネール、すなわちVolumeを代表する１つのピクチャおよびPlayList毎に、それを代表する１つのピクチャの情報をストアする。すべてのメニューサムネールのヘッダ情報は、１つのmenu.tidxに集めて管理される。すべてのメニューサムネールのピクチャデータは、１つのmenu.tdatに集められて管理される。
【０１１１】
"mark.tidx"と"mark.tdat"は、マークサムネール、すなわちマーク点で指されるピクチャについての情報をストアする。Volume中のすべてのClipおよびPlayListに付加されている、全てのマークサムネールのヘッダ情報は、１つのmark.tidxに集めて管理される。全てのマークサムネールのピクチャデータは、１つのmark.tdatに集めて管理される。
【０１１２】
すなわち、このファイル構造では、サムネールのヘッダ情報とサムネールのピクチャデータが、別々のファイルに分けて管理される。この理由は、ファイルシステムが行うファイルの管理方法に関係する。すなわち、サムネールのヘッダ情報のファイルは、比較的重要な情報であるため、ファイルシステムがディスク上にデータを２重書きして管理する。
【０１１３】
これは、例えば、片方のデータがディスクの傷などによって失われてしまったような場合に対応できるようにするためめであり、データのバックアップの意味合いをもつ。ピクチャデータのファイルは、２重書きはしないが、その理由は、ピクチャデータは比較的データ量が大きくなり、これを２重書きするとディスク上の必要容量が大きくなるためである。
【０１１４】
menu.tdatおよびmark.tdatにストアされるピクチャデータの符号化方法、サンプリング構造、およびスキャン構造は、ピクチャ毎に符号化方法を変更することが可能であるが、全てのピクチャデータで同じであるほうが、記録再生装置１の構成を簡単化できる。例えば、JFIF (JPEG File Interchange Format)、コンポーネント信号、プログレッシブスキャンフォーマットが使用される。
【０１１５】
これら4個のファイルのシンタクスとセマンティクスを説明する。"menu.tidx"と"mark.tidx"は、同じシンタクス構造を持つ。図３３は、"menu.tidx"と"mark.tidx"のシンタクス構造を示す。version_numberは、このサムネールヘッダ情報ファイルのバージョンナンバーを示す４個の数字である。
【０１１６】
lengthは、このlengthフィールドの直後のバイトからmenu.tidx/mark.tidxの最後のバイトまでのバイト数である。number_of_thumbnailsは、menu.tidxの場合にはmenu.tdatにストアされているサムネールピクチャの数であり、mark.tidxの場合、mark.tdatにストアされているサムネールピクチャの数である。
【０１１７】
tn_block_sizeは、menu.tidxの場合、menu.tdatの中の１つのtn_blockのサイズを示し、mark.tidxの場合、mark.tdatの中の１つのtn_blockのサイズを示す。このサイズは、1024バイトを単位とする大きさである。例えば、tn_block_size=1は、１つのtn_blockのサイズが1024バイトであることを示す。１つのサムネールピクチャは、１つのtn_blockの中にストアされなければならない。
【０１１８】
number_of_tn_blocksは、menu.tidxの場合、menu.tdatの中にあるtn_blockの数を示し、mark.tidxの場合にはmark.tdatの中にあるtn_blockの数を示す。thumbnail_indexは、このthumbnail_indexフィールドに続くサムネール情報のインデクス番号を表す。thumbnail_indexして、0xFFFF という値を使用してはならない。
【０１１９】
menu.tidxの場合、thumbnail_indexはUIAppInfoVolume()、UIAppInfoPlayList()の中のref_thumbnail_indexによって参照される。mark.tidxの場合、thumbnail_indexはPlayListMark()およびClipMark()の中のref_thumbnail_indexによって参照される。
【０１２０】
ref_to_tn_block_idは、menu.tidxの場合、menu.tdat中の１つのtn_blockを示し、そのtn_blockは、thumbnail_indexで指されるピクチャデータをストアしている。ref_to_tn_block_idの値は、menu.tdatのシンタクス中のtn_block_idの値を参照する。
【０１２１】
mark.tidxの場合、mark.tdat中の１つのtn_blockを示し、そのtn_blockは、thumbnail_indexで指されるピクチャデータをストアしている。ref_to_tn_block_idの値は、menu.tdatのシンタクス中のtn_block_idの値を参照する。
【０１２２】
picture_byte_sizeは、thumbnail_indexで指される１つの符号化サムネールピクチャのデータ長をバイト単位で示す。picture_byte_sizeは、1024*tn_block_sizeの値以下でなければならない。すなわち、記録再生装置１は、１つの符号化サムネールピクチャのデータ長を1024*tn_block_sizeの値以下になるように、符号化しなければならない。
【０１２３】
horizontal_picture_sizeは、thumbnail_indexで指される符号化サムネールピクチャの水平方向の画素数を示す。vertical_picture_sizeは、thumbnail_indexで指される符号化サムネールピクチャの垂直方向の画素数を示す。display_aspect_ratioは、thumbnail_indexで指される符号化サムネールピクチャのディスプレイ・アスペクト・レシオを示す。値の意味を図３４に示す。
【０１２４】
color_spaceは、Y,Cb,Crのコンポーネント信号をR,G,Bのコンポーネント信号へ変換する時のフォーマットを示す。値の意味を図３５に示す。
【０１２５】
"menu.tdat"と"mark.tdat"は、同じシンタクス構造を持つ。図３６は、"menu.tdat"と"mark.tdat"のシンタクス構造を示す図である。tn_blockは、１つの符号化サムネールピクチャがストアされる領域である。１つのサムネイルピクチャのバイト長は、１つのtn_blockの大きさ以下である。１つのピクチャデータの第１バイト目は、tn_blockの第１バイト目と一致していなければならない。
【０１２６】
menu.tdatの場合、１つのtn_blockのサイズは、menu.tdatの中のtn_block_sizeで示される。mark.tdatの場合、１つのtn_blockのサイズはmark.tdatの中のtn_block_sizeで示される。各tn_blockは、それがシンタクス中のfor-loopの中で現れるときのtn_block_idの値で区別される。menu.tidx中のtn_block_idは、menu.tidx中のref_to_tn_block_idによって参照される。mark.tidx中のtn_block_idは、mark.tidx中のref_to_tn_block_idによって参照される。
【０１２７】
サムネイルは頻繁に追加、削除されるので、追加操作と部分削除の操作は、容易に高速に実行できなければならない。この理由のため、menu.tdatとmark.tdatは、ブロック構造を有する。１つのピクチャデータは、１つのtn_blockに格納される。
【０１２８】
menu.tdatおよびmark.tdatのtn_block列の中に、使用されていないtn_blockが存在してもよい。例えば、所定のサムネイルの削除をする場合、サムネールのヘッダ情報ファイルの中にエントリーされているthumbnail_indexを消去し、サムネールのピクチャデータファイルを何も変更しなかったとき、tn_block列の中に、使用されていないtn_blockができる。
【０１２９】
図３７は、サムネールピクチャデータが、どのようにtn_blockに格納されるかを模式的に表した図である。図３７に示すように、１つのサムネイルピクチャのバイト長は、１つのtn_blockの大きさ以下である。tn_block列の中に、使用されていないtn_blockが存在してもよい。
【０１３０】
上述した実施の形態においては、例えば、menu.tbatとmark.tbatのファイルが２個に分けられて記録されるとして説明したが、それぞれのファイルをブロックと考え、menu.tbatのデータの第１のブロックと、mark.tbatのデータの第２のブロックを、１つのファイルにまとめて記録するようにしても良い。１つのファイルにまとめて記録するとは、例えば、Clip Information fileの中で、SequenceInfo、CPI、ClipMarkを別のブロックとして記録するような形態にしても良い。
【０１３１】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば図３８に示すような構成の汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【０１３２】
図３８に示すパーソナルコンピュータにおいて、CPU（Central Processing Unit）２０１は、ROM（Read Only Memory）２０２に記憶されているプログラム、または記憶部２０８からRAM（Random Access Memory）２０３にロードされたプログラムに従って各種の処理を実行する。RAM２０３にはまた、CPU２０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０１３３】
CPU２０１、ROM２０２、およびRAM２０３は、バス２０４を介して相互に接続されている。このバス２０４にはまた、入出力インタフェース２０５も接続されている。
【０１３４】
入出力インタフェース２０５には、キーボード、マウスなどよりなる入力部２０６、CRT、LCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部２０７、ハードディスクなどより構成される記憶部２０８、モデム、ターミナルアダプタなどより構成される通信部２０９が接続されている。通信部２０９は、ネットワークを介しての通信処理を行う。
【０１３５】
入出力インタフェース２０５にはまた、必要に応じてドライブ２１０が接続され、磁気ディスク２２１、光ディスク２２２、光磁気ディスク２２３、或いは半導体メモリ２２４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２０８にインストールされる。
【０１３６】
この記録媒体は、図３８に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク２２１（フロッピディスクを含む）、光ディスク２２２（CD-ROM（Compact Disk-Read Only Memory）、DVD（Digital Versatile Disk）を含む）、光磁気ディスク２２３（MD（Mini-Disk）を含む）、若しくは半導体メモリ２２４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されているROM２０２や記憶部２０８が含まれるハードディスクなどで構成される。
【０１３７】
なお、本明細書において、媒体により提供されるプログラムを記述するステップは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１３８】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１３９】
【発明の効果】
以上のごとく、本発明によれば、ユーザが記録されているデータの選択を簡便に行える。
【図面の簡単な説明】
【図１】本発明を適用した記録再生装置の一実施の形態の構成を示す図である。
【図２】 ClipとPlaylistの関係を表す図である。
【図３】 AVストリームを管理する構造のUML図である。
【図４】 DVRシステムのディレクトリ構成を表す図である。
【図５】 info.dvrを説明する図である。
【図６】 DVRVolume()を説明する図である。
【図７】 UIAppInfoVolume()を説明する図である。
【図８】 TableOfPlayLists()を説明する図である。
【図９】 UIAppInfoPlayList()を説明する図である。
【図１０】 zzzzz.clpiを説明する図である。
【図１１】 ClipMark()を説明する図である。
【図１２】マークを説明する図である。
【図１３】 xxxxx.rpls、 yyyyy.vplsを説明する図である。
【図１４】 Playlist()を説明する図である。
【図１５】 PlayItem()を説明する図である。
【図１６】 PlayListMark()を説明する図である。
【図１７】メニューサムネイルを説明する図である。
【図１８】プレイリストに付けられるマークを説明する図である。
【図１９】クリップに付けられるマークを説明する図である。
【図２０】サムネイルを格納するファイルを説明する図である。
【図２１】 menu_thmb/mark.thmbを説明する図である。
【図２２】 Thumbnail()を説明する図である。
【図２３】 Thumbnail_picture_formatを説明する図である。
【図２４】サムネイルの画像データをtn_block()に格納する方法を説明する図である。
【図２５】他のディレクトリ・ファイル構造を示す図である。
【図２６】図２５に示したファイル構造に対応するmenu_thmb/mark.thmbを説明する図である。
【図２７】図２５に示したファイル構造に対応するTableOfPlayLists()を説明する図である。
【図２８】図２５に示したファイル構造に対応するPlaylist()を説明する図である。
【図２９】図２５に示したファイル構造に対応するUIAppInfoPlayList()を説明する図である。
【図３０】マークサムネイルの作成手順を表したフローチャートである。
【図３１】メニューサムネイルの作成手順を表したフローチャートである。
【図３２】 DVRシステムの他のディレクトリ構成を表す図である。
【図３３】サムネールのヘッダ情報ファイルのシンタクスを示す図である。
【図３４】 display_aspect_raitoを説明する図である。
【図３５】 color_spaceを説明する図である。
【図３６】サムネールのピクチャデータファイルのシンタクスを示す図である。
【図３７】 tn_blockへのデータの格納について説明する図である。
【図３８】媒体を説明する図である。
【符号の説明】
１ 記録再生装置， １１乃至１３ 端子， １４ 解析部， １５ AVエンコーダ， １６ マルチプレクサ， １７ スイッチ， １８ 多重化ストリーム解析部， １９ ソースパケッタイザ， ２０ ECC符号化部， ２１ 変調部， ２２ 書き込み部， ２３ 制御部， ２４ ユーザインタフェース， ２５ スイッチ， ２６ デマルチプレクサ， ２７ AVデコーダ， ２８ 読み出し部， ２９ 復調部， ３０ ECC復号部， ３１ ソースパケッタイザ， ３２，３３ 端子
【発明の属する技術分野】
本発明は記録装置および方法、再生装置および方法、記録媒体、プログラム、並びに記録媒体に関し、特に、データを代表するサムネイルをデータに付加する記録装置および方法、再生装置および方法、記録媒体、プログラム、並びに記録媒体に関する。
【０００２】
【従来の技術】
近年、記録再生装置から取り外し可能なディスク型の記録媒体として、各種の光ディスクが提案されつつある。このような記録可能な光ディスクは、数ギガバイトの大容量メディアとして提案されており、ビデオ信号等のAV(Audio Visual)信号を記録するメディアとしての期待が高い。この記録可能な光デイスクに記録するデジタルのAV信号のソース（供給源）としては、CSデジタル衛星放送やBSデジタル放送があり、また、将来はデジタル方式の地上波テレビジョン放送等も提案されている。
【０００３】
ここで、これらのソースから供給されるデジタルビデオ信号は、通常MPEG（Moving Picture Experts Group）２方式で画像圧縮されているのが一般的である。また、記録装置には、その装置固有の記録レートが定められている。従来の民生用映像蓄積メディアで、デジタル放送由来のデジタルビデオ信号を記録する場合、アナログ記録方式であれば、デジタルビデオ信号をデコード後、帯域制限をして記録する。あるいは、MPEG１ Video、MPEG２ Video、DV方式をはじめとするデジタル記録方式であれば、１度デコードされた後に、その装置固有の記録レート・符号化方式で再エンコードされて記録される。
【０００４】
しかしながら、このような記録方法は、供給されたビットストリームを１度デコードし、その後で帯域制限や再エンコードを行って記録するため、画質の劣化を伴う。画像圧縮されたデジタル信号の記録をする場合、入力されたデジタル信号の伝送レートが記録再生装置の記録レートを超えない場合には、供給されたビットストリームをデコードや再エンコードすることなく、そのまま記録する方法が最も画質の劣化が少ない。ただし、画像圧縮されたデジタル信号の伝送レートが記録媒体としてのディスクの記録レートを超える場合には、記録再生装置でデコード後、伝送レートがディスクの記録レートの上限以下になるように、再エンコードをして記録する必要はある。
【０００５】
また、入力デジタル信号のビットレートが時間により増減する可変レート方式によって伝送されている場合には、回転ヘッドが固定回転数であるために記録レートが固定レートになるテープ記録方式に比べ、１度バッファにデータを蓄積し、バースト的に記録ができるディスク記録装置が記録媒体の容量をより無駄なく利用できる。
【０００６】
以上のように、デジタル放送が主流となる将来においては、データストリーマのように放送信号をデジタル信号のまま、デコードや再エンコードすることなく記録し、記録媒体としてディスクを使用した記録再生装置が求められると予測される。
【０００７】
【発明が解決しようとする課題】
上述したような装置により、複数のデータ（例えば、映像データや音声データなどから構成される番組のデータ）が記録されている記録媒体を再生する際、記録媒体に記録されるデータ量が増加するに従い、どの番組を再生するのか、番組中のどのシーンから再生するのかといった、再生させる前の処理が煩雑になるといった課題があった。
【０００８】
本発明はこのような状況に鑑みてなされたものであり、データを代表するサムネイルをデータに付加することにより、再生させるデータを簡単に選択できるようにすることを目的とする。
【０００９】
【課題を解決するための手段】
本発明の記録装置は、入力された動画像データから、前記動画像データの内容を代表するサムネイル画像を第１のサムネイルデータとして生成すると共に、前記動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像を第２のサムネイルデータとして生成する生成手段と、前記生成手段により生成された前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したグループとして記録媒体に記録する記録手段とを有することを特徴とする。
【００１０】
前記生成手段は、第１のサムネイルデータと第２のサムネイルデータを、各々独立したファイルとして生成するようにすることができる。
【００１１】
前記第１のサムネイルは、プレイリストを代表するサムネイルであり、前記第２のサムネイルは、マーク点を表すサムネイルであるようにすることができる。
【００１２】
前記生成手段は、第１のサムネイルデータに対応する番号で第１のサムネイルデータを管理する第１の管理データも生成すると共に、第２のサムネイルデータに対応する番号で第２のサムネイルデータを管理する第２の管理データも生成し、前記記録手段は、第１の管理データおよび第２の管理データを記録媒体に記録するようにすることができる。
【００１３】
前記第１の管理データと第２の管理データは、管理するサムネイル画像の画像データのフォーマット形式を示すデータを含むようにすることができる。
【００１４】
前記記録手段は、第１のサムネイルデータまたは第２のサムネイルデータに含まれるサムネイル画像の画像データを、所定の大きさのブロック単位で記録するようにすることができる。
【００１５】
前記記録手段は、第１のサムネイル画像の参照先を示す情報をさらに別ファイルとして記録媒体に記録するようにすることができる。
【００１６】
前記記録手段は、第２のサムネイルデータに含まれるサムネイル画像の参照先を示す情報をさらに記録するようにすることができる。
【００１７】
本発明の記録方法は、入力された動画像データから、前記動画像データの内容を代表するサムネイル画像を第１のサムネイルデータとして生成すると共に、前記動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像を第２のサムネイルデータとして生成する生成ステップと、前記生成ステップの処理で生成された前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したグループとして記録媒体に記録するための制御を行う記録制御ステップとを含むことを特徴とする。
【００１８】
本発明の第１の記録媒体のプログラムは、入力された動画像データから、前記動画像データの内容を代表するサムネイル画像を第１のサムネイルデータとして生成すると共に、前記動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像を第２のサムネイルデータとして生成する生成ステップと、前記生成ステップの処理で生成された前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したグループとして記録媒体に記録するための制御を行う記録制御ステップとを含む。
【００１９】
本発明の第１のプログラムは、入力された動画像データから、前記動画像データの内容を代表するサムネイル画像を第１のサムネイルデータとして生成すると共に、前記動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像を第２のサムネイルデータとして生成する生成ステップと、前記生成ステップの処理で生成された前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したグループとして記録媒体に記録するための制御を行う記録制御ステップとを実行させるコンピュータが読み取り可能なプログラム。
【００２０】
本発明の再生装置は、画像データの再生が指示された場合、前記画像データの内容を代表するサムネイル画像の画像データを管理する管理データを読み出す第１の読み出し手段と、前記読み出し手段により読み出された前記管理データに基づき、前記画像データを読み出す第２の読み出し手段と、前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データを読み出す第３の読み出し手段と、前記第３の読み出し手段により読み出された前記管理データに基づき、前記画像データを読み出す第４の読み出し手段とを含むことを特徴とする。
【００２１】
本発明の再生方法は、画像データの再生が指示された場合、前記画像データの内容を代表するサムネイル画像の画像データを管理する管理データの読み出しを制御する第１の読み出し制御ステップと、前記読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データの読み出しを制御する第２の読み出し制御ステップと、前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データを読み出す第３の読み出しステップと、前記第３の読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データを読み出す第４の読み出しステップとを含むことを特徴とする。
【００２２】
本発明の第２の記録媒体のプログラムは、画像データの再生が指示された場合、前記画像データの内容を代表するサムネイル画像の画像データを管理する管理データの読み出しを制御する第１の読み出し制御ステップと、前記読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データの読み出しを制御する第２の読み出し制御ステップと、前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データを読み出す第３の読み出しステップと、前記第３の読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データを読み出す第４の読み出しステップとを含む。
【００２３】
本発明の第２のプログラムは、画像データの再生が指示された場合、前記画像データの内容を代表するサムネイル画像の画像データを管理する管理データの読み出しを制御する第１の読み出し制御ステップと、前記読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データの読み出しを制御する第２の読み出し制御ステップと、前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データを読み出す第３の読み出しステップと、前記第３の読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データを読み出す第４の読み出しステップとを実行するコンピュータが読み取り可能なプログラム。
【００２４】
本発明の第３の記録媒体は、画像データ、前記画像データから、前記画像データの内容を代表するサムネイル画像の画像データと、そのサムネイル画像のデータを管理する管理データから構成される第１のデータ、および、前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザが指定した画像のサムネイル画像の画像データと、その画像データを管理する管理データから構成される第２のデータが記録されていることを特徴とする。
【００２５】
本発明の記録装置および方法、並びに第１のプログラムにおいては、入力された動画像データから、動画像データの内容を代表するサムネイル画像が第１のサムネイルデータとして生成されると共に、動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像が第２のサムネイルデータとして生成され、生成された第１のサムネイルデータと第２のサムネイルデータが、各々独立したグループとして記録媒体に記録される。
【００２６】
本発明の再生装置および方法、並びに第２のプログラムにおいては、画像データの再生が指示された場合、画像データの内容を代表するサムネイル画像の画像データを管理する管理データが読み出され、読み出された管理データに基づき、画像データが読み出され、画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データが読み出され、読み出された管理データに基づき、画像データが読み出される。
【００２７】
【発明の実施の形態】
以下に、本発明の実施の形態について、図面を参照して説明する。図１は、本発明を適用した記録再生装置１の内部構成例を示す図である。まず、外部から入力された信号を記録媒体に記録する動作を行う部分の構成について説明する。記録再生装置１は、アナログデータ、または、デジタルデータを入力し、記録することができる構成とされている。
【００２８】
端子１１には、アナログのビデオ信号が、端子１２には、アナログのオーディオ信号が、それぞれ入力される。端子１１に入力されたビデオ信号は、解析部１４とAVエンコーダ１５に、それぞれ出力される。端子１２に入力されたオーディオ信号は、AVエンコーダ１５にのみ出力される。解析部１４は、入力されたビデオ信号からシーンチェンジなどの特徴点を抽出する。
【００２９】
AVエンコーダ１５は、入力されたビデオ信号とオーディオ信号を、それぞれ符号化し、符号化ビデオストリーム(V)、符号化オーディオストリーム(A)、およびAV同期等のシステム情報(S)をマルチプレクサ１６に出力する。
【００３０】
符号化ビデオストリームは、例えば、MPEG（Moving Picture Expert Group）２方式により符号化されたビデオストリームであり、符号化オーディオストリームは、例えば、MPEG１方式により符号化されたオーディオストリームや、ドルビーAC3方式により符号化されたオーディオストリーム等である。マルチプレクサ１６は、入力されたビデオおよびオーディオのストリームを、入力システム情報に基づいて多重化して、スイッチ１７を介して多重化ストリーム解析部１８とソースパケッタイザ１９に出力する。
【００３１】
多重化ストリームは、例えば、MPEG2トランスポートストリームやMPEG2プログラムストリームである。ソースパケッタイザ１９は、入力された多重化ストリームを、そのストリームを記録させる記録媒体１００のアプリケーションフォーマットに従って、ソースパケットから構成されるAVストリームを符号化する。AVストリームは、ECC（誤り訂正）符号化部２０、変調部２１で所定の処理が施され、書き込み部２２に出力される。書き込み部２２は、制御部２３から出力される制御信号に基づいて、記録媒体１００にAVストリームファイルを書き込む（記録する）。
【００３２】
デジタルインタフェースまたはデジタルテレビジョンチューナから入力されるデジタルテレビジョン放送等のトランスポートストリームは、端子１３に入力される。端子１３に入力されたトランスポートストリームの記録方式には、２通りあり、それらは、トランスペアレントに記録する方式と、記録ビットレートを下げるなどの目的のために再エンコードをした後に記録する方式である。記録方式の指示情報は、ユーザインターフェースとしての端子２４から制御部２３へ入力される。
【００３３】
入力トランスポートストリームをトランスペアレントに記録する場合、端子１３に入力されたトランスポートストリームは、多重化ストリーム解析部１８と、ソースパケッタイザ１９に出力される。これ以降の記録媒体１００へAVストリームが記録されるまでの処理は、上述の入力オーディオ信号とビデオ信号を符号化して記録する場合と同一の処理なので、その説明は省略する。
【００３４】
入力トランスポートストリームを再エンコードした後に記録する場合、端子１３に入力されたトランスポートストリームは、デマルチプレクサ２６に入力される。デマルチプレクサ２６は、入力されたトランスポートストリームに対してデマルチプレクス処理を施し、ビデオストリーム(V)、オーディオストリーム(A)、およびシステム情報(S)を抽出する。
【００３５】
デマルチプレクサ２６により抽出されたストリーム（情報）のうち、ビデオストリームはAVデコーダ２７に、オーディオストリームとシステム情報はマルチプレクサ１６に、それぞれ出力される。AVデコーダ２７は、入力されたビデオストリームを復号し、その再生ビデオ信号をAVエンコーダ１５に出力する。AVエンコーダ１５は、入力ビデオ信号を符号化し、符号化ビデオストリーム(V)をマルチプレクサ１６に出力する。
【００３６】
一方、デマルチプレクサ２６から出力され、マルチプレクサ１６に入力されたオーディオストリームとシステム情報、および、AVエンコーダ１５から出力されたビデオストリームは、入力システム情報に基づいて、多重化されて、多重化ストリームとして多重化ストリーム解析部１８とソースパケットタイザ１９にスイッチ１７を介して出力される。これ以後の記録媒体１００へAVストリームが記録されるまでの処理は、上述の入力オーディオ信号と、ビデオ信号を符号化して記録する場合と同一の処理なので、その説明は省略する。
【００３７】
本実施の形態の記録再生装置１は、AVストリームのファイルを記録媒体１００に記録すると共に、そのファイルを説明するアプリケーションデータベース情報も記録する。アプリケーションデータベース情報は、制御部２３により作成される。制御部２３への入力情報は、解析部１４からの動画像の特徴情報、多重化ストリーム解析部１８からのAVストリームの特徴情報、および端子２４から入力されるユーザからの指示情報である。
【００３８】
解析部１４から供給される動画像の特徴情報は、入力動画像信号の中の特徴的な画像に関係する情報であり、例えば、プログラムの開始点、シーンチェンジ点、コマーシャル（ＣＭ）の開始・終了点などの指定情報（マーク）であり、また、その指定場所の画像のサムネイル画像の情報も含まれる。
【００３９】
多重化ストリーム解析部１８からのAVストリームの特徴情報は、記録されるAVストリームの符号化情報に関係する情報であり、例えば、AVストリーム内のIピクチャのアドレス情報、AVストリームの符号化パラメータ、AVストリームの中の符号化パラメータの変化点情報、ビデオストリームの中の特徴的な画像に関係する情報（マーク）などである。
【００４０】
端子２４からのユーザの指示情報は、AVストリームの中の、ユーザが指定した再生区間の指定情報、その再生区間の内容を説明するキャラクター文字、ユーザが好みのシーンにセットするブックマークやリジューム点の情報などである。
【００４１】
制御部２３は、上記の入力情報に基づいて、AVストリームのデータベース(Clip)、AVストリームの再生区間(PlayItem)をグループ化したもの（PlayList）のデータベース、記録媒体１００の記録内容の管理情報(info.dvr)、およびサムネイル画像の情報を作成する。これらの情報から構成されるアプリケーションデータベース情報は、AVストリームと同様にして、ECC符号化部２０、変調部２１で処理されて、書き込み部２２へ入力される。書き込み部２２は、制御部２３から出力される制御信号に基づいて、記録媒体１００へデータベースファイルを記録する。
【００４２】
上述したアプリケーションデータベース情報についての詳細は後述する。
【００４３】
このようにして記録媒体１００に記録されたAVストリームファイル（画像データと音声データのファイル）と、アプリケーションデータベース情報が再生される場合、まず、制御部２３は、読み出し部２８に対して、記録媒体１００からアプリケーションデータベース情報を読み出すように指示する。そして、読み出し部２８は、記録媒体１００からアプリケーションデータベース情報を読み出し、そのアプリケーションデータベース情報は、復調部２９、ECC復号部３０の処理を経て、制御部２３へ入力される。
【００４４】
制御部２３は、アプリケーションデータベース情報に基づいて、記録媒体１００に記録されているPlayListの一覧を端子２４のユーザインターフェースへ出力する。ユーザは、PlayListの一覧から再生したいPlayListを選択し、再生を指定されたPlayListに関する情報が制御部２３へ入力される。制御部２３は、そのPlayListの再生に必要なAVストリームファイルの読み出しを、読み出し部２８に指示する。読み出し部２８は、その指示に従い、記録媒体１００から対応するAVストリームを読み出し復調部２９に出力する。復調部２９に入力されたAVストリームは、所定の処理が施されることにより復調され、さらにECC復号部３０の処理を経て、ソースデパケッタイザ３１出力される。
【００４５】
ソースデパケッタイザ３１は、記録媒体１００から読み出され、所定の処理が施されたアプリケーションフォーマットのAVストリームを、デマルチプレクサ２６に出力できるストリームに変換する。デマルチプレクサ２６は、制御部２３により指定されたAVストリームの再生区間(PlayItem)を構成するビデオストリーム(V)、オーディオストリーム(A)、およびAV同期等のシステム情報(S)を、AVデコーダ２７に出力する。AVデコーダ２７は、ビデオストリームとオーディオストリームを復号し、再生ビデオ信号と再生オーディオ信号を、それぞれ対応する端子３２と端子３３から出力する。
【００４６】
また、ユーザインタフェースとしての端子２４から、ランダムアクセス再生や特殊再生を指示する情報が入力された場合、制御部２３は、AVストリームのデータベース(Clip)の内容に基づいて、記憶媒体１００からのAVストリームの読み出し位置を決定し、そのAVストリームの読み出しを、読み出し部２８に指示する。例えば、ユーザにより選択されたPlayListを、所定の時刻から再生する場合、制御部２３は、指定された時刻に最も近いタイムスタンプを持つIピクチャからのデータを読み出すように読み出し部２８に指示する。
【００４７】
また、ユーザによって高速再生(Fast-forward playback)が指示された場合、制御部２３は、AVストリームのデータベース(Clip)に基づいて、AVストリームの中のI-ピクチャデータを順次連続して読み出すように読み出し部２８に指示する。
【００４８】
読み出し部２８は、指定されたランダムアクセスポイントからAVストリームのデータを読み出し、読み出されたデータは、後段の各部の処理を経て再生される。
【００４９】
次に、ユーザが、記録媒体１００に記録されているAVストリームの編集をする場合を説明する。ユーザが、記録媒体１００に記録されているAVストリームの再生区間を指定して新しい再生経路を作成したい場合、例えば、番組Ａという歌番組から歌手Ａの部分を再生し、その後続けて、番組Ｂという歌番組の歌手Ａの部分を再生したいといった再生経路を作成したい場合、ユーザインタフェースとしての端子２４から再生区間の開始点（イン点）と終了点（アウト点）の情報が制御部２３に入力される。制御部２３は、AVストリームの再生区間(PlayItem)をグループ化したもの（PlayList）のデータベースを作成する。
【００５０】
ユーザが、記録媒体１００に記録されているAVストリームの一部を消去したい場合、ユーザインタフェースとしての端子２４から消去区間のイン点とアウト点の情報が制御部２３に入力される。制御部２３は、必要なAVストリーム部分だけを参照するようにPlayListのデータベースを変更する。また、AVストリームの不必要なストリーム部分を消去するように、書き込み部２２に指示する。
【００５１】
ユーザが、記録媒体１００に記録されているAVストリームの再生区間を指定して新しい再生経路を作成したい場合であり、かつ、それぞれの再生区間をシームレスに接続したい場合について説明する。このような場合、制御部２３は、AVストリームの再生区間(PlayItem)をグループ化したもの（PlayList）のデータベースを作成し、さらに、再生区間の接続点付近のビデオストリームの部分的な再エンコードと再多重化を行う。
【００５２】
まず、端子２４から再生区間のイン点のピクチャの情報と、アウト点のピクチャの情報が制御部２３へ入力される。制御部２３は、読み出し部２８にイン点側のピクチャとアウト点側のピクチャを再生するために必要なデータの読み出しを指示する。そして、読み出し部２８は、記録媒体１００からデータを読み出し、そのデータは、復調部２９、ECC復号部３０、ソースデパケッタイザ３１を経て、デマルチプレクサ２６に出力される。
【００５３】
制御部２３は、デマルチプレクサ２６に入力されたデータを解析して、ビデオストリームの再エンコード方法（picture_coding_typeの変更、再エンコードする符号化ビット量の割り当て）と、再多重化方式を決定し、その方式をAVエンコーダ１５とマルチプレクサ１６に供給する。
【００５４】
次に、デマルチプレクサ２６は、入力されたストリームをビデオストリーム(V)、オーディオストリーム(A)、およびシステム情報(S)に分離する。ビデオストリームは、「AVデコーダ２７に入力されるデータ」と「マルチプレクサ１６に入力されるデータ」がある。前者のデータは、再エンコードするために必要なデータであり、これはAVデコーダ２７で復号され、復号されたピクチャはAVエンコーダ１５で再エンコードされて、ビデオストリームにされる。後者のデータは、再エンコードをしないで、オリジナルのストリームからコピーされるデータである。オーディオストリーム、システム情報については、直接、マルチプレクサ１６に入力される。
【００５５】
マルチプレクサ１６は、制御部２３から入力された情報に基づいて、入力ストリームを多重化し、多重化ストリームを出力する。多重化ストリームは、ECC符号化部２０、変調部２１で処理されて、書き込み部２２に入力される。書き込み部２２は、制御部２３から供給される制御信号に基づいて、記録媒体１００にAVストリームを記録する。
【００５６】
このような記録再生装置１において記録媒体１００に記録されるデータ（記録媒体１００から再生されるデータ）について説明する。MPEG Video、MPEG Audio等の符号化方式で符号化され、MPEG-2 Systemsに従って多重化されたビットストリームを、ファイルシステムが扱うファイルの形にしてディスク（以下、適宜、記録媒体１００をディスク状の記録媒体とし、ディスクと称する）に記録したものをAV(Audio Video)ストリームファイル（またはClip AVストリーム）と称する。
【００５７】
このようなAVストリームファイルの一部または全部の範囲を指定して、必要な部分だけを並べて再生する再生順序指定の仕組みを説明する。図２のように、AVストリームファイルの一部または全部の範囲を指定して、必要な部分だけを再生する再生順序指定がPlaylistである。Playlistは、ユーザから見て、ひとまとまりの単位である。最も簡単な構成になるのは、記録開始をしてから記録終了までの単位で、編集をしなければ、これが１つのPlaylistになる。
【００５８】
Playlistは、どのAVストリームを再生するかという、AVストリームファイルの指定と、そのファイル中の再生開始点（イン点）と再生終了点（アウト点）の集まりで構成される。AVストリームファイル、再生開始点、再生終了点等を１組とし、これをPlayitemと称する。すなわち、PlaylistはPlayitemの集合である。
【００５９】
図２に示したように、Playitemは、あるAVストリームファイルの、イン点、アウト点で指定する範囲を参照する。Playitemを再生するということは、そのPlayitemが参照するAVストリームの一部分を再生するということになる。
【００６０】
AVストリームは、MPEG-TSの形などにマルチプレクスされているビットストリームであるが、このAVストリームが記録されるファイルとは別のファイルに、そのビットストリームに対して１対１に対応する情報（クリップ情報：Clip information）を保持する。これは、再生、編集をより容易にするために設けられている。このようなクリップ情報と、AVストリームの両方をひとまとまとり（オブジェクト）とみなし、これをClip（クリップ）と呼ぶ。すなわち、ClipはAVストリームと、それに付随する情報から構成される１つのオブジェクトである。
【００６１】
以上のような、関係をUML図で表すと、図３のようになる。図３のUML図で表されるAVストリームファイル、Clip、Playitem、Playlistの構造により、AVストリームファイルを変更しない、任意の部分だけを再生する非破壊再生順序指定が可能になる。
【００６２】
次に、本発明を実現するための、各種の情報が記録または再生される記録媒体（メディア）上のファイル配置について説明する。メディア上には、図４に示すように、info.dvr、menu.thmb（mark.thmb）、#####.rpls（#####.vpls） (#####は任意の番号)、%%%%%.clpi (%%%%%は任意の番号)、および %%%%%.m2ts (%%%%%は、各m2tsファイルがcpliファイルと１対１に対応するような番号)の、５種類のファイルが記録される。
【００６３】
ディスク上にディレクトリ/DVRを用意し、このディレクトリの下が、１つのディスク記録再生システムで管理される範囲とする。/DVRは、ディスクのルートディレクトリにあっても良いし、所定のディレクトリの下に存在していても良い。/DVRディレクトリには、info.dvr、 menu.thmb、 mark.thmbというファイルが置かれる。また、/DVRの下には、/PLAYLIST、 /CLIPINF、 /M2TSというディレクトリが置かれる。ファイル#####.rpls、 #####.vplsは、/PLAYLISTの下に置かれ、/CLIPINFには%%%%%.clpiが置かれ、/M2TSには、%%%%%.m2tsが置かれる。
【００６４】
ファイルinfo.dvrは、/DVRの下にだた１つある。info.dvrの構造は、図５に示したようなシンタクスで表される。ファイルの内部は、機能別の情報ごとにブロックを構成しており、volumeに関する情報はDVRVolume()に、 Playlistの並びに関する情報はTableOfPlayLists()に、記録再生装置１のメーカ固有の情報はMakerPrivateData()に、それぞれ格納される。ファイルの先頭部分には、それらのブロックの先頭を表すアドレスが記述されている。例えば、TableOfPlayLists_Start_addressは、TableOfPlayLists()が開始する位置を、ファイル内での相対バイト数で表したものになっている。
【００６５】
DVRVolume()の構造は図６に示したようなシンタクスで表される。version_numberは、DVRVolume()のバージョン番号を表し、lengthは、length直後のフィールドからDVRVolume()の最後までの長さをバイトで表したものである。ResumeVolume()はresumeに関する情報を格納し、UIAppInfoVolume()はVolumeの属性情報を格納する領域である。
【００６６】
図７は、UIAppInfoVolume()のシンタクスを表したものである。character_setは、Volume_nameフィールドに符号化されているキャラクター文字の符号化方法を示す。その符号化方法としては、ASCII、Unicode等を選択できる。name_lengthは、Volume_nameフィールドの中に示されるボリューム（ディスク）名のバイト長を示す。Volume_nameは、ボリューム（ディスク）の名前を示す。このフィールドの中の左からname_length数のバイト数が、有効なキャラクター文字であり、それはボリューム（ディスク）の名前を示す。
【００６７】
Volume_nameフィールドの中で、それら有効なキャラクター文字の後の値は、どんな値が入っていても良い。Volume_protect_flagは、そのボリュームの中のコンテンツをユーザに制限することなしに見せてよいかどうかを示すフラグである。このフラグが１にセットされている場合、ユーザが正しくPIN番号（図７中のPIN）を入力できた場合にだけ、ユーザは、そのボリュームのコンテンツを視聴する事ができる。このフラグが０にセットされている場合、ユーザがPIN番号を入力しなくても、ユーザが、そのボリュームのコンテンツを視聴する事ができる。最初に、ユーザが、ディスクをプレーヤ（記録再生装置１）へ挿入した時において、もしこのフラグが０にセットされているか、または、このフラグが１にセットされていてもユーザがPIN番号を正しく入力できたならば、プレーヤーは、そのセットされたディスクの中のPlayListの一覧を表示させる。
【００６８】
以上は、Volumeに対しての再生制限であるが、それぞれのPlayListの再生制限については、Volume_protect_flagとは無関係であり、それは後述する図９のUIAppInfoPlayList()の中で定義されるplayback_control_flagによって示される。PINは、４個の０乃至９までの数字であり、それぞれの数字は、ISO/IEC 646に従って符号化される。ref_thumbnail_indexは、Volumeを代表するサムネイルが存在する場合、そのサムネイルを特定するための番号を格納する領域である。ref_thumbnail_indexで指定されるthumbnail_indexを持つ、ファイルmenu.thmb中のサムネイルが、Volumeを代表するメニューサムネイル（本発明では、VolumeやPlaylistを代表するサムネイルを特にメニューサムネイルと称する）となる。
【００６９】
rp_info_valid_flagは、これが１である場合に次に続くrp_ref_to_PlayList_file_name, rp_ref_to_PlayItem_idおよびrp_time_stampが有効な値を持つこと示す。rp_ref_to_PlayList_file_nameは、上記のVolumeを代表するメニューサムネイルが、所定のPlayList中の画像から抜き出された画像から作られていることを示し、そのPlayListファイルの名前を示す。
【００７０】
rp_ref_to_PlayItem_idは、rp_ref_to_PlayList_file_nameで示されるPlayListの中の１つのPlayItemを指すPlayItem_idを示し、上記のVolumeを代表するメニューサムネイルが、そのPlayItem中の画像から抜き出された画像から作られていることを示す。rp_time_stampは、rp_ref_to_PlayItem_idが指すPlayItem中の１つの画像のプレゼンテーションタイムスタンプを示し、その画像から上記のVolumeを代表するメニューサムネイルが作られていることを示す。
【００７１】
図８は、TableOfPlayLists()のシンタクスを表したものである。ここでnumber_of_PlayListsはVolume中のPlaylistの数を表し、PlayList_file_nameは#####.rpls、 #####.vpls等のファイル名を指定するものである。UIAppInfoPlayList()には、Playlistの各種属性がかかれており、シンタクスは図９のようになっている。図９に示したUIAppInfoPlayList()には、Playlistの再生には直接必要ではない、Playlistの名前、記録日時、記録時間、消去禁止の有無等の、各種属性情報が格納される。その中のref_thumbnail_indexにより、PlayListの代表画としてのサムネイルを指定することができる。すなわち、ref_thumbnail_indexで指定されるthumbnail_indexを持つ、ファイルmenu.thmb中のサムネイルが、このPlaylistを代表するメニューサムネイルとなる。
【００７２】
rp_info_valid_flagは、これが１である場合に、次に続くrp_ref_to_PlayItem_idおよびrp_time_stampが有効な値を持つこと示す。rp_ref_to_PlayItem_idは、PlayListの中の１つのPlayItemを指すPlayItem_idを示し、PlayListを代表するメニューサムネイルが、そのPlayItem中の画像から抜き出された画像から作られていることを示す。rp_time_stampは、rp_ref_to_PlayItem_idが指すPlayItem中の１つの画像のプレゼンテーションタイムスタンプを示し、その画像からPlayListを代表するメニューサムネイルが作られていることを示す。
【００７３】
図４に示したファイル%%%%%.clpiは、/CLIPINFの下に、各AVストリームファイル%%%%%.m2tsに対応して１つ作られる。%%%%%.clpiの構造は、図１０に示すようになっている。ファイルの内部は、機能別の情報ごとにブロックを構成しており、Clipに関する情報はClipInfo()に、MPEG-2 systemsにおけるトランスポートストリームの時刻基準を表すPCR（プログラムクロックリファレンス）の不連続点に関する情報はSTC_Info()に、MPEG-2 systemsのprogram（プログラム）に関する情報はProgramInfo()に、 AVストリーム中のランダムアクセス開始可能点等の特徴的な点を表すCPI（Characteristic Point Information）に関する情報はCPI()に、Clipにつけられた、頭出しのためのインデックス点やコマーシャルの開始・終了点などのマーク情報はClipMark()に、それぞれ格納される。ファイルの先頭部分には、それらのブロックの先頭を表すアドレスが記述されている。
【００７４】
ここでは、サムネイルに関係するブロックだけを説明する。本実施の形態においては、クリップにサムネイルを付ける操作は、クリップのマークにサムネイルを付与することで実現する。クリップに付けられるマークの情報は、 ClipMark()に格納されている。図１１に、ClipMark()のシンタクスを示す。シンタクス中のmark_typeが、resume、 bookmark、 skip等のマークの種類を表し、mark_time_stampでマークがつけられた時刻を表す。サムネイルに関係するフィールドは、ref_thumbnail_index である。ref_thumbnail_indexは、ここでサムネイルの番号を指定することで、サムネイルのデータが格納されているmark.thmbファイル中のサムネイルを特定する。ref_thumbnail_indexで指定されるサムネイルが、このマークに付与されたマークサムネイル（本発明では、マークに付与されたサムネイルを特にマークサムネイルと称する）となる。
【００７５】
マークは、主としてClipおよびPlaylistの中のハイライトや特徴的なシーンを指し示すためにある。また、マークより後の部分は再生を飛ばして、次のPlaylistの再生をするように指示するスキップ機能も、マークによって実現できる。図１２は、マークがClip、Playlistに付けられている様子を図で示したものである。以下にマークの特徴をまとめる。
【００７６】
Clipに付加されるマークは、AVストリームの内容に起因する特徴的なシーン、例えば、シーンチェンジ点などを指定する。Playlistを再生する時には、そのPlaylistが参照しているClip中のマークを利用してランダムアクセス等ができる。図１２では、Clipに対してcommercial（ＣＭ）とsceneという、２種類のマークが付けられているが、commercialのマークは左のPlaylistから、sceneマークは二つのPlaylistから利用されている。Playlistに付加されるマークは、主としてユーザによって設定される。例えば、ブックマークやリジューム点などである。図１２では、bookmarkとresumeマークが相当する。
【００７７】
ClipまたはPlaylistにマークを設定することは、マークの時刻を示すタイムスタンプをマークリストに追加することにより行われる。また、マークを削除することは、マークリストの中からそのマークのタイムスタンプを除去する事である。それゆえ、マークの設定や削除は、AVストリームを何も変化させない。
【００７８】
次に、図４に示したファイル#####.rpls、#####.vplsについて説明するに、ファイル#####.rpls、 #####.vplsは、/PLAYLISTの下に、各playlistに対してどちらか１つ作られる。#####.rpls、#####.vplsの構造は、図１３に示すようになっている。ファイルの内部は、機能別の情報ごとにブロックを構成しており、Playlistに関する情報はPlayList()に、Playlistに付けられるマークの情報はPlayListMark()に、このPlaylistファイルを記録した記録再生装置のメーカ固有の情報はMakerPrivateData()に、それぞれ格納される。ファイルの先頭部分には、ブロックの先頭を表すアドレス(PlayListMark_Start_address等)が記述されている。これにより、ブロックの前あるいは後ろにpadding_byteを挿入することが出来る。ただし、PlayList()の開始位置は固定で、ファイルの先頭から、例えば、256バイト目と設定されている。
【００７９】
ブロックPlayList()の内容は、図１４のようになっている。最初にversion_numberがあり、以下に続く情報のバージョン番号を表す。lengthは、lengthの直後のフィールドから、PlayList()の終わりまでのバイト長を表す。PlayList_typeは、このPlaylistの種類を表し、CPI_typeは、このPlaylistが持つCPIの種類を表す。number_of_PlayItemsは、このPlaylistを構成するPlayitemの数を表す。number_of_SubPlayItemsは、このPlaylistに付けられているアフレコオーディオ用のPlayitem(SubPlayitem)の数を表す。PlayItem()は、Playitemの情報を、SubPlayItem()は、SubPlayitemの情報を格納する。
【００８０】
ブロックPlayItem()の内容は、図１５のようになっている。Clip_Information_file_nameは、このPlayItemが参照しているClip情報ファイル（拡張子がclpiであるファイル）のファイル名が文字列で格納されている。STC_sequence_idは、program中に存在する、PCRが連続な時間範囲の区間をあらわす。この区間内では、一貫した連続時間軸が定義できるようになっているので、PlayItemの開始・終了点を一意に定めることが出来る。つまり、各PlayItemの開始点と終了点は、同一のSTC_sequenceに存在していなければならない。
【００８１】
IN_timeは、このPlayItemの開始点の、STC_sequence 上でのpts（Presentation Time Stamp）を表し、OUT_time はPlayItemの終了点の、STC_sequence 上でのptsを表す。connection_conditionは、このPlayitemが次のPlayitemとの間でどのような接続がされているかを表す情報であり、Playitemの間を継ぎ目なく再生できるかどうかの条件を表す。
【００８２】
BridgeSequnceInfo()は、Playitemの継ぎ目の部分で、本来再生すべきビットストリームとは異なるビットストリームに飛び、それを代わりに再生することで、Playitemの間をシームレスに再生する機能を実現する際に作成されるビットストリーム（ブリッジシーケンス）に関する情報を格納する。program_numberは、このPlayitemが参照しているprogram(MPEG Systemsで定義されている、ビデオ・オーディオ等のエレメンタリストリームのまとまりをいう。いわゆるテレビジョン放送のチャンネルに相当するものである）のprogram_numberを表す。
【００８３】
以上が、Playlist、Playitemを構成するデータ構造の概要である。このようなデータ構造により、AVストリーム中の再生したい部分をIN、OUT点の組で指定したPlayitemの並びでPlaylistを構築し、ユーザが認識するひとまとまりの再生単位を管理することが可能になる。
【００８４】
本発明の実施の形態では、プレイリスト上の任意の時刻にサムネイルを付ける操作は、プレイリストのマークにサムネイルを付与することで実現している。Playlistに付けられるマークの情報は、PlayListMark()に格納されている。図１６は、PlaylistMark()のシンタクスを示す図である。シンタクス中のmark_typeが、resume、 bookmark、 skip等のマークの種類を表し、mark_time_stampでマークがつけられた時刻を表す。ref_thumbnail_indexは、ここでサムネイルの番号を指定することで、サムネイルのデータが格納されているmark.thmbファイル中のサムネイルを特定する。ref_thumbnail_indexで指定されるサムネイルが、このマークに対応するマークサムネイルとなる。
【００８５】
次に、サムネイルの詳細について説明する。サムネイルとは、Volume、Playlist、Clipに付随する静止画のことを指す。サムネイルには２種類ある。一つは、内容を表す代表画としてのサムネイルである。これは主としてユーザがカーソルを操作して見たいものを選択するためのメニュー画面で使われる。もう一つは、マークが指しているシーンを表す画像である。
【００８６】
Volumeと各Playlistは代表画を持つことができるようにする必要がある。Volumeの代表画とは、ディスクをプレーヤに入れた時に、ディスクの内容を表す静止画を最初に表示する場合などに用いることを想定している。Playlistの代表画とは、Playlistを選択するメニュー画面において、Playlistの内容を表すための静止画として用いられることを想定している。
【００８７】
Playlistの代表画の最も簡単な実現方法は、Playlistの最初の画像をサムネイルにすることであるが、必ずしも再生時刻0の先頭の画像が内容を表す上で最適な画像とは限らない。そこで、Playlistのサムネイルとして、任意の画像を決めることが出来るようにしておく。以上２種類のサムネイルをメニューサムネイルと称する。メニューサムネイルは、頻繁に表示されるため、ディスクから高速に読み出されることが可能である必要がある。この要求を満たすには、全てのメニューサムネイルを１つのファイルに格納することが効率的である。必ずしもボリューム内の動画から抜き出したピクチャだけではなく、図１７に示すように、パーソナルコンピュータやデジタルスチルカメラから取り込んだ画像でもよい。
【００８８】
一方、ClipとPlaylistは複数個のマークを打てる必要があり、マーク位置の内容を知るためにマーク点の画像を容易に見ることが出来るようにする必要がある。このようなマーク点を表すピクチャをマークサムネイルと称する。よって、サムネイルの元となるものは、図１８や図１９に示したように、外部から取り込んだ画像よりも、マーク点の画像を抜き出したものが主となる。メニューサムネイルと異なり、マークサムネイルはPlaylistの詳細を表す時に使われるサブメニュー等で使われるため、短いアクセス時間で読み出されなくても良い。
【００８９】
そのため、サムネイルが必要になる度に、プレイヤーがファイルを開き、ファイルの一部を読み出すことで多少時間がかかっても、問題にはならない。また、ボリューム内に存在するファイル数を減らすために、すべてのマークサムネイルは一つのファイルに格納するのがよい。Playlistはメニューサムネイル一つと複数のマークサムネイルを有することができるが、Clipは直接ユーザが選択する必要性がない（通常、Playlist経由で指定する）ため、メニューサムネイルを持つことはしない。図２０は、以上の関係を示した図である。
【００９０】
サムネイルは頻繁に追加、削除されるので、追加操作と部分削除の操作は容易に、かつ、高速に実行されなければならない。この理由のため、Thumbnail()はブロック構造を有する。画像のデータはいくつかの部分に分割され、各部分は１つのtn_block()に格納される。１つの画像データは、連続したtn_block()に格納される。tn_block()の列には、使用されていないtn_block()が存在してもよい。１つのサムネイル画像のバイト長は可変である。
【００９１】
図２１は、サムネイルのデータを格納するファイルのシンタクスである。このファイルには、Thumbnail()がただ一つ存在する。図２２は、thubnail()のシンタクスを表す。version_numberは、このthumbnail()のバージョンナンバーを示す4個のキャラクター文字を表す。lengthは、このlengthフィールドの直後からthumbnail()の最後までのthumbnail()のバイト数を示す３２ビットの符号なし整数である。tn_blocks_start_addressは、thumbnail()中の最初のtn_block()の、thumbnail()の先頭からの開始バイトアドレスを示す３２ビットの符号なし整数である。
【００９２】
number_of_thumbnailsは、このthumbnail()に格納されているサムネイル画像の数を示す１６ビットの符号なし整数である。tn_block_sizeは、1 tn_block()の大きさをキロバイト単位で表す１６ビットの符号なし整数である。例えば、tn_block_size が１であるのは、１つのtn_block()のサイズが1024バイトであることを表す。number_of_tn_blocksは、この thumbnail()中のtn_block()の数を表す１６ビットの符号なし整数である。
【００９３】
thumbnail_indexは、このthumbnail_indexフィールドから始まるforループ１回分のサムネイル情報で表されるサムネイルのインデクス番号を表す１６ビットの符号なし整数である。 thumbnail_index として、0xFFFF という値を使用してはならない。thumbnail_index はref_thumbnail_indexによって参照される。tumbnail_picture_format は、サムネイル画像のピクチャフォーマットを表す８ビットの符号なし整数で、図２３に示したような値をとる。図２３中のDCF（Design rule for Camera File System）とPNG（Portable Network Graphics）は”menu.thmb”内でのみ許される。すなわちマークサムネイルは、値"0x00" (MPEG-2 Video I-picture)ととらなければならない。
【００９４】
picture_data_size は、符号化されたサムネイル画像のバイト長を表す３２ビットの符号なし整数である。start_tn_block_numberは、サムネイル画像のデータが始まるtn_block()のtn_block_numberを表す１６ビットの符号なし整数である。サムネイル画像データの先頭は、tb_blockの先頭と一致していなければならない。start_tn_block_number は、０から始まり、tn_blockのfor-ループ中の変数kの値に関係している。x_picture_length は、サムネイル画像の水平方向のピクセル数を表す１６ビットの符号なし整数である。
【００９５】
y_picture_lengthは、サムネイル画像の垂直方向のピクセル数を表す１６ビットの符号なし整数である。tn_block() は、ピクチャデータを格納する領域である。thumbnail()中のすべてのtn_block()は、tn_block_size で定められる同一の大きさを有していなければならない。図２４は、画像データがどのようにtn_block()に格納されるかを模式的に表した図である。図２４に示したように、各画像データはtn_block()の先頭から始まり、1tn_block()を超える大きさの場合は、連続する次のtn_block()を使用することにより格納される。
【００９６】
画像データは、可変長であるが、１tn_block()は、固定長である。このように、可変長であるデータを固定長のデータに変換して扱うようにすることにより、新たな画像データの追加や、画像データの削除といった処理に対してブロック単位で対処できるため、アドレスの管理など、簡便に行うことが可能となる。
【００９７】
ここで、サムネイル記録についてのディレクトリ・ファイル構造、シンタックスの別案を示す。まず、図４で表されるディレクトリ・ファイル構造の別案として、図２５の構造が考えられる。図４では、マークサムネイルを記録するためのファイルが/DVRの下に１つ、mark.thmbだけであるのに対し、図２５では、プレイリスト、クリップごとに１対１に対応してファイルxxxxx.thmb(xxxxxは対応するプレイリストまたはクリップをあらわす、拡張子を除いたファイル名)が作られている。
【００９８】
例えば、#####.rplsで表されるプレイリストが有するマークサムネイルの画像は、同じディレクトリ内の#####.thmbに格納されることになる。同様に、%%%%%.clpiで表されるクリップが有するマークサムネイルの画像は、同じディレクトリ内の%%%%%.thmbに格納されることになる。プレイリスト・クリップのマークサムネイルは、ファイルの拡張子を除いた名前の部分が同一の.thmbファイルに記録されるという制約があるだけで、xxxxx.thmb内のシンタックスは、図２６のように、menu.thmbやmark.thmb（図２１）と同一である。
【００９９】
また、プレイリストのメニューサムネイルについて、図８、図９では、サムネイルを特定するref_thumbnail_indexを、ファイルInfo.dvrのTableOfPlayLists()の中のUIAppInfoPlayList()に置いているが、UIAppInfoPlayList()をInfo.dvrではなく、各プレイリストファイル中に入れる方法もある。このような場合、UIAppInfoPlayList()を、TableOfPlayLists()から、プレイリストファイル中のplaylist()へ移すことになり、図８に示したシンタクスは図２７に示すシンタクスのようになり、図１４に示したシンタクスは図２８に示すシンタクスのようになる。図２８中のUIAppInfoPlayList()は、図２９に示すシンタクスのようになり、ここにref_thumbnail_indexが入る。
【０１００】
以上のようなファイル、シンタックスでもサムネイルの記録が可能である。
【０１０１】
次に、図３０に示したフローチャートを参照して、マークサムネイルの作成について説明する。ステップＳ１において、ユーザは、再生したいPlayList（プレイリスト）を選択する。ステップＳ２において、選択されたPlayListに基づいて、AVストリームの再生が開始される。ステップＳ３において、ユーザは、再生されているAVストリームを視聴し、マークしたいシーンを探索する。ユーザは、マークしたいシーンが探索できた場合、記録再生装置１に付属するリモートコントローラ（不図示）のマークボタンを操作する。この操作は、再生中に操作されても、一時停止された状態で操作されても良い。
【０１０２】
ステップＳ３において、ユーザによりマークボタンが操作されると、ステップＳ４において、ユーザの指示に対応する処理としてマーク位置が決定される。マーク位置が決定されると、ステップＳ５において、サムネイル画像にする画像の選択が行われる。マーク位置が指示された時点で、制御部２３（図１）は、サムネイルを作成するかどうかをユーザに尋ね、作成する場合には、サムネイルとする画像の候補をコマ送り等によりユーザに提供し、ユーザがサムネイル画像を選択するようにしても良い。
【０１０３】
ユーザ、または、制御部２３により、サムネイル画像にする画像が選択されると、制御部２３は、ステップＳ６において、AVデコーダ１５から画像を取り込み制御部２３のRAM（Random Access Memory）（不図示）に転送する。ステップＳ７において、画像を圧縮するか否かが判断され、画像を圧縮すると判断された場合、制御部２３は、ステップＳ８に進み、画像圧縮を行い、再びデータをRAMに戻す。ステップＳ７において、画像を圧縮しないと判断された場合、ステップＳ８の処理はスキップされ、ステップＳ９に進む。
【０１０４】
ステップＳ９において、制御部２３は、サムネイルの符号化方式、サムネイルを識別するthumbnail_id、サイズ（バイト数）、X、Y方向のピクセル数から構成されるサムネイルのヘッダ情報を作成し、画像データをtn_block()の単位に分割する。ステップＳ１０において、ECC符号化ブロック２０にヘッダ情報とtn_block()の形に分割した画像データが転送され、書き込み部２２を経て、mark.thmbファイルとして記録媒体１００に書き込まれる。
【０１０５】
次に、メニューサムネイルを作成について、図３１に示したフローチャートを参照して説明する。メニューサムネイルはボリュームまたは各プレイリストに対して付けられるので、制御部２３は、ステップＳ２１において、ユーザに対して、メニューサムネイルをつける対象を選択させる。ステップＳ２２において、制御部２３は、サムネイルを外部から取り込むか、プレイリスト中のあるシーンから取り込むかをユーザに選択させる。
【０１０６】
ステップＳ２２において、サムネイルを外部から取り込むと判断された場合、ステップＳ２３に進み、ユーザが指定した入力端子あるいはファイルから画像データが取り込まれる。取り込みが終了されると、ステップＳ２６に進む。
【０１０７】
一方、ステップＳ２２において、サムネイルを外部から取り込むのではないと判断された場合、ステップＳ２４に進み、制御部２３は、まず、ユーザに対して、どのプレイリストからサムネイル画像を取得するのかを選択させ、その後、選択されたプレイリストの再生を開始する。そして、ステップＳ２５において、ユーザにサムネイルにしたいシーンを選択させる。
【０１０８】
ステップＳ２３、或いは、ステップＳ２５において、サムネイル画像が選択されると、ステップＳ２６に進む。ステップＳ２６以降の処理は、図３０に示したフローチャートのステップＳ５以降の処理と同様であるので、その説明は省略する。
【０１０９】
このように、サムネイル画像をプレイリストに付与することにより、それらのサムネイル画像を管理しやすくなり、記録されているＡＶストリームを再生する際にも、再生させるＡＶストリームの選択などの処理を簡便に行わせることが可能となる。
【０１１０】
図３２は、ディスク上につくられるディレクトリおよびファイルの別の例を示す図である。"menu.tidx"と"menu.tdat"は、メニューサムネール、すなわちVolumeを代表する１つのピクチャおよびPlayList毎に、それを代表する１つのピクチャの情報をストアする。すべてのメニューサムネールのヘッダ情報は、１つのmenu.tidxに集めて管理される。すべてのメニューサムネールのピクチャデータは、１つのmenu.tdatに集められて管理される。
【０１１１】
"mark.tidx"と"mark.tdat"は、マークサムネール、すなわちマーク点で指されるピクチャについての情報をストアする。Volume中のすべてのClipおよびPlayListに付加されている、全てのマークサムネールのヘッダ情報は、１つのmark.tidxに集めて管理される。全てのマークサムネールのピクチャデータは、１つのmark.tdatに集めて管理される。
【０１１２】
すなわち、このファイル構造では、サムネールのヘッダ情報とサムネールのピクチャデータが、別々のファイルに分けて管理される。この理由は、ファイルシステムが行うファイルの管理方法に関係する。すなわち、サムネールのヘッダ情報のファイルは、比較的重要な情報であるため、ファイルシステムがディスク上にデータを２重書きして管理する。
【０１１３】
これは、例えば、片方のデータがディスクの傷などによって失われてしまったような場合に対応できるようにするためめであり、データのバックアップの意味合いをもつ。ピクチャデータのファイルは、２重書きはしないが、その理由は、ピクチャデータは比較的データ量が大きくなり、これを２重書きするとディスク上の必要容量が大きくなるためである。
【０１１４】
menu.tdatおよびmark.tdatにストアされるピクチャデータの符号化方法、サンプリング構造、およびスキャン構造は、ピクチャ毎に符号化方法を変更することが可能であるが、全てのピクチャデータで同じであるほうが、記録再生装置１の構成を簡単化できる。例えば、JFIF (JPEG File Interchange Format)、コンポーネント信号、プログレッシブスキャンフォーマットが使用される。
【０１１５】
これら4個のファイルのシンタクスとセマンティクスを説明する。"menu.tidx"と"mark.tidx"は、同じシンタクス構造を持つ。図３３は、"menu.tidx"と"mark.tidx"のシンタクス構造を示す。version_numberは、このサムネールヘッダ情報ファイルのバージョンナンバーを示す４個の数字である。
【０１１６】
lengthは、このlengthフィールドの直後のバイトからmenu.tidx/mark.tidxの最後のバイトまでのバイト数である。number_of_thumbnailsは、menu.tidxの場合にはmenu.tdatにストアされているサムネールピクチャの数であり、mark.tidxの場合、mark.tdatにストアされているサムネールピクチャの数である。
【０１１７】
tn_block_sizeは、menu.tidxの場合、menu.tdatの中の１つのtn_blockのサイズを示し、mark.tidxの場合、mark.tdatの中の１つのtn_blockのサイズを示す。このサイズは、1024バイトを単位とする大きさである。例えば、tn_block_size=1は、１つのtn_blockのサイズが1024バイトであることを示す。１つのサムネールピクチャは、１つのtn_blockの中にストアされなければならない。
【０１１８】
number_of_tn_blocksは、menu.tidxの場合、menu.tdatの中にあるtn_blockの数を示し、mark.tidxの場合にはmark.tdatの中にあるtn_blockの数を示す。thumbnail_indexは、このthumbnail_indexフィールドに続くサムネール情報のインデクス番号を表す。thumbnail_indexして、0xFFFF という値を使用してはならない。
【０１１９】
menu.tidxの場合、thumbnail_indexはUIAppInfoVolume()、UIAppInfoPlayList()の中のref_thumbnail_indexによって参照される。mark.tidxの場合、thumbnail_indexはPlayListMark()およびClipMark()の中のref_thumbnail_indexによって参照される。
【０１２０】
ref_to_tn_block_idは、menu.tidxの場合、menu.tdat中の１つのtn_blockを示し、そのtn_blockは、thumbnail_indexで指されるピクチャデータをストアしている。ref_to_tn_block_idの値は、menu.tdatのシンタクス中のtn_block_idの値を参照する。
【０１２１】
mark.tidxの場合、mark.tdat中の１つのtn_blockを示し、そのtn_blockは、thumbnail_indexで指されるピクチャデータをストアしている。ref_to_tn_block_idの値は、menu.tdatのシンタクス中のtn_block_idの値を参照する。
【０１２２】
picture_byte_sizeは、thumbnail_indexで指される１つの符号化サムネールピクチャのデータ長をバイト単位で示す。picture_byte_sizeは、1024*tn_block_sizeの値以下でなければならない。すなわち、記録再生装置１は、１つの符号化サムネールピクチャのデータ長を1024*tn_block_sizeの値以下になるように、符号化しなければならない。
【０１２３】
horizontal_picture_sizeは、thumbnail_indexで指される符号化サムネールピクチャの水平方向の画素数を示す。vertical_picture_sizeは、thumbnail_indexで指される符号化サムネールピクチャの垂直方向の画素数を示す。display_aspect_ratioは、thumbnail_indexで指される符号化サムネールピクチャのディスプレイ・アスペクト・レシオを示す。値の意味を図３４に示す。
【０１２４】
color_spaceは、Y,Cb,Crのコンポーネント信号をR,G,Bのコンポーネント信号へ変換する時のフォーマットを示す。値の意味を図３５に示す。
【０１２５】
"menu.tdat"と"mark.tdat"は、同じシンタクス構造を持つ。図３６は、"menu.tdat"と"mark.tdat"のシンタクス構造を示す図である。tn_blockは、１つの符号化サムネールピクチャがストアされる領域である。１つのサムネイルピクチャのバイト長は、１つのtn_blockの大きさ以下である。１つのピクチャデータの第１バイト目は、tn_blockの第１バイト目と一致していなければならない。
【０１２６】
menu.tdatの場合、１つのtn_blockのサイズは、menu.tdatの中のtn_block_sizeで示される。mark.tdatの場合、１つのtn_blockのサイズはmark.tdatの中のtn_block_sizeで示される。各tn_blockは、それがシンタクス中のfor-loopの中で現れるときのtn_block_idの値で区別される。menu.tidx中のtn_block_idは、menu.tidx中のref_to_tn_block_idによって参照される。mark.tidx中のtn_block_idは、mark.tidx中のref_to_tn_block_idによって参照される。
【０１２７】
サムネイルは頻繁に追加、削除されるので、追加操作と部分削除の操作は、容易に高速に実行できなければならない。この理由のため、menu.tdatとmark.tdatは、ブロック構造を有する。１つのピクチャデータは、１つのtn_blockに格納される。
【０１２８】
menu.tdatおよびmark.tdatのtn_block列の中に、使用されていないtn_blockが存在してもよい。例えば、所定のサムネイルの削除をする場合、サムネールのヘッダ情報ファイルの中にエントリーされているthumbnail_indexを消去し、サムネールのピクチャデータファイルを何も変更しなかったとき、tn_block列の中に、使用されていないtn_blockができる。
【０１２９】
図３７は、サムネールピクチャデータが、どのようにtn_blockに格納されるかを模式的に表した図である。図３７に示すように、１つのサムネイルピクチャのバイト長は、１つのtn_blockの大きさ以下である。tn_block列の中に、使用されていないtn_blockが存在してもよい。
【０１３０】
上述した実施の形態においては、例えば、menu.tbatとmark.tbatのファイルが２個に分けられて記録されるとして説明したが、それぞれのファイルをブロックと考え、menu.tbatのデータの第１のブロックと、mark.tbatのデータの第２のブロックを、１つのファイルにまとめて記録するようにしても良い。１つのファイルにまとめて記録するとは、例えば、Clip Information fileの中で、SequenceInfo、CPI、ClipMarkを別のブロックとして記録するような形態にしても良い。
【０１３１】
上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば図３８に示すような構成の汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。
【０１３２】
図３８に示すパーソナルコンピュータにおいて、CPU（Central Processing Unit）２０１は、ROM（Read Only Memory）２０２に記憶されているプログラム、または記憶部２０８からRAM（Random Access Memory）２０３にロードされたプログラムに従って各種の処理を実行する。RAM２０３にはまた、CPU２０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
【０１３３】
CPU２０１、ROM２０２、およびRAM２０３は、バス２０４を介して相互に接続されている。このバス２０４にはまた、入出力インタフェース２０５も接続されている。
【０１３４】
入出力インタフェース２０５には、キーボード、マウスなどよりなる入力部２０６、CRT、LCDなどよりなるディスプレイ、並びにスピーカなどよりなる出力部２０７、ハードディスクなどより構成される記憶部２０８、モデム、ターミナルアダプタなどより構成される通信部２０９が接続されている。通信部２０９は、ネットワークを介しての通信処理を行う。
【０１３５】
入出力インタフェース２０５にはまた、必要に応じてドライブ２１０が接続され、磁気ディスク２２１、光ディスク２２２、光磁気ディスク２２３、或いは半導体メモリ２２４などが適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部２０８にインストールされる。
【０１３６】
この記録媒体は、図３８に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク２２１（フロッピディスクを含む）、光ディスク２２２（CD-ROM（Compact Disk-Read Only Memory）、DVD（Digital Versatile Disk）を含む）、光磁気ディスク２２３（MD（Mini-Disk）を含む）、若しくは半導体メモリ２２４などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されているROM２０２や記憶部２０８が含まれるハードディスクなどで構成される。
【０１３７】
なお、本明細書において、媒体により提供されるプログラムを記述するステップは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０１３８】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０１３９】
【発明の効果】
以上のごとく、本発明によれば、ユーザが記録されているデータの選択を簡便に行える。
【図面の簡単な説明】
【図１】本発明を適用した記録再生装置の一実施の形態の構成を示す図である。
【図２】 ClipとPlaylistの関係を表す図である。
【図３】 AVストリームを管理する構造のUML図である。
【図４】 DVRシステムのディレクトリ構成を表す図である。
【図５】 info.dvrを説明する図である。
【図６】 DVRVolume()を説明する図である。
【図７】 UIAppInfoVolume()を説明する図である。
【図８】 TableOfPlayLists()を説明する図である。
【図９】 UIAppInfoPlayList()を説明する図である。
【図１０】 zzzzz.clpiを説明する図である。
【図１１】 ClipMark()を説明する図である。
【図１２】マークを説明する図である。
【図１３】 xxxxx.rpls、 yyyyy.vplsを説明する図である。
【図１４】 Playlist()を説明する図である。
【図１５】 PlayItem()を説明する図である。
【図１６】 PlayListMark()を説明する図である。
【図１７】メニューサムネイルを説明する図である。
【図１８】プレイリストに付けられるマークを説明する図である。
【図１９】クリップに付けられるマークを説明する図である。
【図２０】サムネイルを格納するファイルを説明する図である。
【図２１】 menu_thmb/mark.thmbを説明する図である。
【図２２】 Thumbnail()を説明する図である。
【図２３】 Thumbnail_picture_formatを説明する図である。
【図２４】サムネイルの画像データをtn_block()に格納する方法を説明する図である。
【図２５】他のディレクトリ・ファイル構造を示す図である。
【図２６】図２５に示したファイル構造に対応するmenu_thmb/mark.thmbを説明する図である。
【図２７】図２５に示したファイル構造に対応するTableOfPlayLists()を説明する図である。
【図２８】図２５に示したファイル構造に対応するPlaylist()を説明する図である。
【図２９】図２５に示したファイル構造に対応するUIAppInfoPlayList()を説明する図である。
【図３０】マークサムネイルの作成手順を表したフローチャートである。
【図３１】メニューサムネイルの作成手順を表したフローチャートである。
【図３２】 DVRシステムの他のディレクトリ構成を表す図である。
【図３３】サムネールのヘッダ情報ファイルのシンタクスを示す図である。
【図３４】 display_aspect_raitoを説明する図である。
【図３５】 color_spaceを説明する図である。
【図３６】サムネールのピクチャデータファイルのシンタクスを示す図である。
【図３７】 tn_blockへのデータの格納について説明する図である。
【図３８】媒体を説明する図である。
【符号の説明】
１ 記録再生装置， １１乃至１３ 端子， １４ 解析部， １５ AVエンコーダ， １６ マルチプレクサ， １７ スイッチ， １８ 多重化ストリーム解析部， １９ ソースパケッタイザ， ２０ ECC符号化部， ２１ 変調部， ２２ 書き込み部， ２３ 制御部， ２４ ユーザインタフェース， ２５ スイッチ， ２６ デマルチプレクサ， ２７ AVデコーダ， ２８ 読み出し部， ２９ 復調部， ３０ ECC復号部， ３１ ソースパケッタイザ， ３２，３３ 端子
Claims (16)
- 入力された動画像データから、前記動画像データの内容を代表するサムネイル画像を第１のサムネイルデータとして生成すると共に、前記動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像を第２のサムネイルデータとして生成する生成手段と、
前記生成手段により生成された前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したグループとして記録媒体に記録する記録手段と
を有することを特徴とする記録装置。 - 前記生成手段は、前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したファイルとして生成する
ことを特徴とする請求項１に記載の記録装置。 - 前記第１のサムネイルは、プレイリストを代表するサムネイルであり、前記第２のサムネイルは、マーク点を表すサムネイルである
ことを特徴とする請求項１に記載の記録装置。 - 前記生成手段は、前記第１のサムネイルデータに対応する番号で前記第１のサムネイルデータを管理する第１の管理データも生成すると共に、前記第２のサムネイルデータに対応する番号で前記第２のサムネイルデータを管理する第２の管理データも生成し、
前記記録手段は、前記第１の管理データおよび前記第２の管理データを前記記録媒体に記録する
ことを特徴とする請求項１に記載の記録装置。 - 前記第１の管理データと前記第２の管理データは、管理する前記サムネイル画像の画像データのフォーマット形式を示すデータを含む
ことを特徴とする請求項４に記載の記録装置。 - 前記記録手段は、前記第１のサムネイルデータまたは前記第２のサムネイルデータに含まれる前記サムネイル画像の画像データを、所定の大きさのブロック単位で記録する
ことを特徴とする請求項４に記載の記録装置。 - 前記記録手段は、前記第１のサムネイル画像の参照先を示す情報をさらに別ファイルとして前記記録媒体に記録する
ことを特徴とする請求項１に記載の記録装置。 - 前記記録手段は、前記第２のサムネイルデータに含まれる前記サムネイル画像の参照先を示す情報をさらに記録する
ことを特徴とする請求項１に記載の記録装置。 - 入力された動画像データから、前記動画像データの内容を代表するサムネイル画像を第１のサムネイルデータとして生成すると共に、前記動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像を第２のサムネイルデータとして生成する生成ステップと、
前記生成ステップの処理で生成された前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したグループとして記録媒体に記録するための制御を行う記録制御ステップと
を含むことを特徴とする記録方法。 - 入力された動画像データから、前記動画像データの内容を代表するサムネイル画像を第１のサムネイルデータとして生成すると共に、前記動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像を第２のサムネイルデータとして生成する生成ステップと、
前記生成ステップの処理で生成された前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したグループとして記録媒体に記録するための制御を行う記録制御ステップと
を含む処理を実行するコンピュータが読み取り可能なプログラムが記録されている記録媒体。 - 入力された動画像データから、前記動画像データの内容を代表するサムネイル画像を第１のサムネイルデータとして生成すると共に、前記動画像データから、特徴的な画像として抽出された画像のサムネイル画像か、または、ユーザが指定した画像のサムネイル画像を第２のサムネイルデータとして生成する生成ステップと、
前記生成ステップの処理で生成された前記第１のサムネイルデータと前記第２のサムネイルデータを、各々独立したグループとして記録媒体に記録するための制御を行う記録制御ステップと
を実行させるコンピュータが読み取り可能なプログラム。 - 画像データの再生が指示された場合、前記画像データの内容を代表するサムネイル画像の画像データを管理する管理データを読み出す第１の読み出し手段と、
前記読み出し手段により読み出された前記管理データに基づき、前記画像データを読み出す第２の読み出し手段と、
前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データを読み出す第３の読み出し手段と、
前記第３の読み出し手段により読み出された前記管理データに基づき、前記画像データを読み出す第４の読み出し手段と
を含むことを特徴とする再生装置。 - 画像データの再生が指示された場合、前記画像データの内容を代表するサムネイル画像の画像データを管理する管理データの読み出しを制御する第１の読み出し制御ステップと、
前記読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データの読み出しを制御する第２の読み出し制御ステップと、
前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データを読み出す第３の読み出しステップと、
前記第３の読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データを読み出す第４の読み出しステップと
を含むことを特徴とする再生方法。 - 画像データの再生が指示された場合、前記画像データの内容を代表するサムネイル画像の画像データを管理する管理データの読み出しを制御する第１の読み出し制御ステップと、
前記読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データの読み出しを制御する第２の読み出し制御ステップと、
前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データを読み出す第３の読み出しステップと、
前記第３の読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データを読み出す第４の読み出しステップと
を含む処理を実行するコンピュータが読み取り可能なプログラムが記録されている記録媒体。 - 画像データの再生が指示された場合、前記画像データの内容を代表するサムネイル画像の画像データを管理する管理データの読み出しを制御する第１の読み出し制御ステップと、
前記読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データの読み出しを制御する第２の読み出し制御ステップと、
前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザにより指定された画像のサムネイル画像の画像データと、その画像データを管理する管理データを読み出す第３の読み出しステップと、
前記第３の読み出し制御ステップの処理で読み出しが制御された前記管理データに基づき、前記画像データを読み出す第４の読み出しステップと
を実行するコンピュータが読み取り可能なプログラム。 - 画像データ、前記画像データから、前記画像データの内容を代表するサムネイル画像の画像データと、そのサムネイル画像のデータを管理する管理データから構成される第１のデータ、および、前記画像データから、特徴的な画像として抽出された画像のサムネイル画像の画像データか、または、ユーザが指定した画像のサムネイル画像の画像データと、その画像データを管理する管理データから構成される第２のデータが記録されている
ことを特徴とする記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2001109342A JP4264617B2 (ja) | 2000-04-21 | 2001-04-06 | 記録装置および方法、再生装置および方法、記録媒体、プログラム、並びに記録媒体 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000-185479 | 2000-04-21 | ||
| JP2000185479 | 2000-04-21 | ||
| JP2001109342A JP4264617B2 (ja) | 2000-04-21 | 2001-04-06 | 記録装置および方法、再生装置および方法、記録媒体、プログラム、並びに記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2002056651A JP2002056651A (ja) | 2002-02-22 |
| JP4264617B2 true JP4264617B2 (ja) | 2009-05-20 |
Family
ID=26594321
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2001109342A Expired - Lifetime JP4264617B2 (ja) | 2000-04-21 | 2001-04-06 | 記録装置および方法、再生装置および方法、記録媒体、プログラム、並びに記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4264617B2 (ja) |
Families Citing this family (39)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100448452B1 (ko) | 2000-06-09 | 2004-09-13 | 엘지전자 주식회사 | 고밀도 광 기록매체의 메뉴 지원방법 |
| JP4409792B2 (ja) * | 2001-06-22 | 2010-02-03 | ソニー株式会社 | データ伝送装置および方法、記録媒体並びにプログラム |
| KR100563685B1 (ko) * | 2002-02-25 | 2006-03-28 | 엘지전자 주식회사 | 재기록 가능 기록매체의 재생리스트 관리방법 |
| KR100469258B1 (ko) * | 2002-05-24 | 2005-02-02 | 엘지전자 주식회사 | 썸네일 영상 생성 장치 및 방법 |
| CN101350214B (zh) | 2002-06-24 | 2015-07-01 | Lg电子株式会社 | 记录和再现用于视频数据的再现的数据结构的方法及装置 |
| KR20040000290A (ko) | 2002-06-24 | 2004-01-03 | 엘지전자 주식회사 | 고밀도 광디스크의 멀티 경로 데이터 스트림 관리방법 |
| RU2320030C2 (ru) | 2002-06-24 | 2008-03-20 | Эл Джи Электроникс Инк. | Носитель записи со структурой данных для управления воспроизведением записанных на нем видеоданных нескольких каналов воспроизведения и способы и устройства записи и воспроизведения |
| AU2003243025B2 (en) | 2002-06-28 | 2009-02-19 | Lg Electronics Inc. | Recording medium having data structure for managing reproduction of multiple play-back path video data recorded thereon and recording and reproducing methods and apparatuses |
| JP4300767B2 (ja) | 2002-08-05 | 2009-07-22 | ソニー株式会社 | ガイドシステム、コンテンツサーバ、携帯装置、情報処理方法、情報処理プログラム、及び記憶媒体 |
| EP1550122A4 (en) | 2002-09-05 | 2009-12-02 | Lg Electronics Inc | RECORDING MEDIUM HAVING A DATA STRUCTURE MANAGING THE REPRODUCTION OF FIXED IMAGES RECORDED THEREIN, AND METHODS AND APPARATUSES FOR RECORDING AND REPRODUCING |
| JP4588968B2 (ja) * | 2002-10-01 | 2010-12-01 | パイオニア株式会社 | 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造 |
| CN100487807C (zh) | 2002-10-04 | 2009-05-13 | Lg电子有限公司 | 有管理图形数据再现的数据结构的录制介质及录制与再现方法和装置 |
| TWI260591B (en) | 2002-10-14 | 2006-08-21 | Samsung Electronics Co Ltd | Information storage medium with structure for multi-angle data, and recording and reproducing apparatus therefor |
| US7054888B2 (en) | 2002-10-16 | 2006-05-30 | Microsoft Corporation | Optimizing media player memory during rendering |
| JPWO2004045207A1 (ja) * | 2002-11-12 | 2006-03-16 | 松下電器産業株式会社 | 記録再生装置および方法 |
| JP2006506772A (ja) * | 2002-11-20 | 2006-02-23 | エルジー エレクトロニクス インコーポレーテッド | 記録されたデータの再生を管理するためのデータ構造を有する記録媒体、それによる記録及び再生方法及び装置 |
| JP3846422B2 (ja) * | 2002-12-26 | 2006-11-15 | ソニー株式会社 | 光ディスク記録装置及び方法 |
| KR100998906B1 (ko) | 2003-01-20 | 2010-12-09 | 엘지전자 주식회사 | 기록된 정지 영상의 재생을 관리하기 위한 데이터 구조를갖는 기록 매체, 그에 따른 기록 및 재생 방법 및 장치 |
| US8145033B2 (en) | 2003-02-05 | 2012-03-27 | Lg Electronics Inc. | Recording medium having data structure for managing reproducton duration of still pictures recorded thereon and recording and reproducing methods and apparatuses |
| US7734154B2 (en) | 2003-02-14 | 2010-06-08 | Lg Electronics Inc. | Recording medium having data structure for managing reproduction duration of still pictures recorded thereon and recording and reproducing methods and apparatuses |
| US7809775B2 (en) | 2003-02-27 | 2010-10-05 | Lg Electronics, Inc. | Recording medium having data structure for managing playback control recorded thereon and recording and reproducing methods and apparatuses |
| JP3924787B2 (ja) | 2003-02-27 | 2007-06-06 | ソニー株式会社 | 記録装置、ファイル管理方法、ファイル管理方法のプログラム、ファイル管理方法のプログラムを記録した記録媒体 |
| WO2004077417A1 (en) | 2003-02-28 | 2004-09-10 | Lg Electronics Inc. | Recording medium having data structure for managing random/shuffle reproduction of video data recorded thereon and recording and reproducing methods and apparatuses |
| JP3931843B2 (ja) | 2003-06-13 | 2007-06-20 | 株式会社日立製作所 | 記録媒体および再生方法 |
| CN1833286B (zh) * | 2003-07-01 | 2012-01-18 | 日本先锋公司 | 信息记录装置和方法、信息重放装置和方法、信息记录/重放装置和方法 |
| KR20050005074A (ko) | 2003-07-01 | 2005-01-13 | 엘지전자 주식회사 | 고밀도 광디스크의 그래픽 데이터 관리방법 및 그에 따른고밀도 광디스크 |
| KR20050004339A (ko) | 2003-07-02 | 2005-01-12 | 엘지전자 주식회사 | 고밀도 광디스크의 그래픽 데이터 관리방법 및 그에 따른고밀도 광디스크 |
| JP4641046B2 (ja) * | 2003-10-10 | 2011-03-02 | シャープ株式会社 | 再生装置、ビデオデータの再生方法、コンテンツ記録媒体、制御プログラム、制御プログラムを記録したコンピュータ読み取り可能な記録媒体 |
| CN101833968B (zh) | 2003-10-10 | 2012-06-27 | 夏普株式会社 | 内容再现装置和内容再现方法 |
| KR20050064150A (ko) | 2003-12-23 | 2005-06-29 | 엘지전자 주식회사 | 고밀도 광디스크의 메뉴 구성방법 및 실행방법과기록재생장치 |
| US7752548B2 (en) | 2004-10-29 | 2010-07-06 | Microsoft Corporation | Features such as titles, transitions, and/or effects which vary according to positions |
| WO2006090612A1 (ja) | 2005-02-25 | 2006-08-31 | Sharp Kabushiki Kaisha | データ管理システム、データ管理方法、サーバ装置、受信装置、制御プログラムおよびそれを記録したコンピュータ読み取り可能な記録媒体 |
| JP4875338B2 (ja) | 2005-09-13 | 2012-02-15 | ソニー株式会社 | 情報処理装置および方法、並びにプログラム |
| JP4850605B2 (ja) | 2006-07-18 | 2012-01-11 | 株式会社日立製作所 | 映像記録方法 |
| JP2008047962A (ja) * | 2006-08-10 | 2008-02-28 | Sony Corp | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム |
| JP2008047963A (ja) * | 2006-08-10 | 2008-02-28 | Sony Corp | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム |
| JP4656021B2 (ja) * | 2006-08-10 | 2011-03-23 | ソニー株式会社 | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム |
| JP4951376B2 (ja) * | 2007-03-19 | 2012-06-13 | 株式会社日立製作所 | 再生装置、映像記録装置、および、その番組情報編集方法 |
| JP4827072B2 (ja) * | 2010-06-07 | 2011-11-30 | パイオニア株式会社 | 情報記録媒体、情報記録装置及び方法、情報再生装置及び方法、情報記録再生装置及び方法、記録又は再生制御用のコンピュータプログラム、並びに制御信号を含むデータ構造 |
-
2001
- 2001-04-06 JP JP2001109342A patent/JP4264617B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2002056651A (ja) | 2002-02-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4264617B2 (ja) | 記録装置および方法、再生装置および方法、記録媒体、プログラム、並びに記録媒体 | |
| KR100780153B1 (ko) | 기록 장치 및 방법, 재생 장치 및 방법, 및 기록 매체 | |
| JP4022818B2 (ja) | データ記録装置および方法、データ記録媒体、データ再生装置および方法、データ編集装置および方法、プログラム格納媒体、並びにプログラム | |
| JP4409792B2 (ja) | データ伝送装置および方法、記録媒体並びにプログラム | |
| US8098979B2 (en) | Reproduction apparatus having protection flags and code number | |
| JP4517267B2 (ja) | 記録装置および方法、再生装置および方法、プログラム、並びに記録媒体 | |
| AU2003243025B2 (en) | Recording medium having data structure for managing reproduction of multiple play-back path video data recorded thereon and recording and reproducing methods and apparatuses | |
| JP4765733B2 (ja) | 記録装置、記録方法および記録プログラム | |
| JP5314097B2 (ja) | 記録装置および情報記録方法 | |
| US8164990B2 (en) | Recording apparatus, recording method, recording program, recording/reproducing apparatus, recording/reproducing method, recording/reproducing program, editing apparatus, editing method, editing program, and display method | |
| KR20020020919A (ko) | 정보 처리 장치 및 방법, 프로그램과 기록 매체 | |
| US8295673B2 (en) | Apparatus, method, and computer program for processing information | |
| US8208782B2 (en) | Recording device, recording method, and recording program | |
| JP4355988B2 (ja) | 情報処理装置、情報処理方法、プログラム記録媒体、プログラム、および情報記録媒体 | |
| US7912338B2 (en) | Recording medium having data structure for managing random/shuffle reproduction of video data recorded thereon and recording and reproducing methods and apparatuses | |
| KR20070122155A (ko) | 정보 처리 장치, 및 정보 처리 방법, 및 컴퓨터·프로그램 | |
| JP5999405B2 (ja) | 情報処理装置、情報処理方法、並びにプログラム | |
| JP2013115552A (ja) | 情報処理装置、情報処理方法、並びにプログラム | |
| JP6010900B2 (ja) | 情報処理装置、情報処理方法、並びにプログラム | |
| JP2006302498A (ja) | データ受信装置および方法 | |
| JP2006216227A (ja) | データ受信装置および方法 | |
| WO2006006571A1 (ja) | データ処理装置 | |
| JP2005322405A (ja) | 記録装置、記録媒体およびデータ構造 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080306 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081023 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081219 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090120 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090202 |
|
| R151 | Written notification of patent or utility model registration |
Ref document number: 4264617 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R151 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120227 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130227 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140227 Year of fee payment: 5 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| EXPY | Cancellation because of completion of term |