以下、この発明の実施の一形態について説明する。図1は、この発明が適用可能な記録再生システムで用いる記録媒体上のアプリケーションフォーマットの概略的な構造を示す。このフォーマットは、AVストリームの管理のために、プレイリスト(PlayList)と、クリップ(Clip)の2つのレイヤを持つ。
1つのAVストリームとその付属情報のペアを1つのオブジェクトと考え、これをクリップと呼ぶ。AVストリームが格納されるAVストリームファイルを、クリップAVストリームファイル(Clip AV Stream File) と呼び、対応する付属情報が格納されるファイルを、クリップインフォメーションファイル(Clip Information File) と呼ぶ。
クリップAVストリームファイルのコンテンツは、時間軸上に展開され、プレイリストは、クリップの中のアクセスポイントをタイムスタンプ(Time Stamp)で指定する。プレイリストがクリップの中へのアクセスポイントをタイムスタンプで指し示しているとき、クリップインフォメーションファイルは、クリップAVストリームファイルの中でストリームのデコードを開始すべきアドレス情報を見つけるために用いられる。
プレイリストは、クリップの中の再生区間の集まりである。あるクリップの1つの再生区間をプレイアイテム(PlayItem)と呼ぶ。プレイアイテムは、時間軸上のIN点とOUT点のペアで表される。したがって、プレイリストは、プレイアイテムの集まりである。
1のディスク中に記録された全てのプレイリストおよびクリップは、ボリュームインフォメーション(Volume Information)で管理される。
図2は、この発明による記録再生システムで用いる記録媒体上に記録されたAVストリームの構造を概略的に示す。この発明では、AVストリームを、記録媒体上ではBDAV(Blu-ray Disc Audio/Video) MPEG2トランスポートストリームとして扱う。BDAV MPEG2トランスポートストリームは、それぞれ6144バイトのサイズを有する整数個のアライドユニット(Aligned Unit)から構成される。
アライドユニットは、32個のソースパケット(Source Packet) からなる。ソースパケットは、192バイトのサイズを有し、1つのソースパケットは、4バイトのサイズのトランスポートパケットエクストラヘッダ(TP _extra header) と、188バイトのサイズを有するトランスポートパケット(Transport Packet)とからなる。
ビデオストリームやオーディオストリームのデータは、MPEG2 PES(Packetized Elementary Stream)パケットにパケット化されている。すなわち、ビデオストリームやオーディオストリームのデータが適宜、分割され、PESパケットデータ部に詰め込まれる。このPESパケットデータ部に対して、当該PESパケットが伝送するエレメンタリストリームの種類を特定するストリームIDを含むPESパケットヘッダが付加され、PESパケットが形成される。
PESパケットは、さらに、トランスポートパケットにパケット化される。すなわち、PESパケットがトランスポートパケットのペイロードのサイズに分割され、ペイロードに所定にトランスポートパケットヘッダが付加されて、トランスポートパケットが形成される。トランスポートパケットヘッダは、ペイロードに格納されるデータの識別情報であるPID(Packet ID) を含む。
なお、ソースパケットには、クリップAVストリームの先頭を例えば0として、ソースパケット毎に1ずつ増加するソースパケット番号が与えられる。また、アライドユニットは、ソースパケットの第1バイト目から始まる。
上述したクリップインフォメーションファイルには、EP_mapが含まれる。EP_mapは、背景技術で既に説明したように、クリップへのアクセスポイントのタイムスタンプが与えられたときに、クリップAVストリームファイルの中でデータの読み出しを開始すべきデータアドレスを検索するために用いられる。EP_mapは、エレメンタリストリームおよびトランスポートストリームから抽出されたエントリポイント(EP)のリストである。EP_mapは、AVストリームの中でデコードを開始すべきエントリポイントを検索するためのアドレス情報を持つ。EP_map中の1つのEPデータは、プレゼンテーションタイムスタンプ(PTS)と、そのPTSに対応するアクセスユニットの、AVストリーム中のデータアドレスの対で構成される。なお、MPEG4 AVC|H.264において、1アクセスユニットは、1ピクチャに相当する。
EP_mapについて、図3および図4を用いて説明する。図3は、EP_mapの説明に用いるクリップAVストリームの例を示す。図3の例では、クリップAVストリームは、3本のビデオストリームが多重化されている。各々のビデオストリームは、ソースパケット毎に、ソースパケット内のトランスポートパケットのヘッダに含まれるPID(Packet Identification) により区別される。図3の例では、PID=x、PID=yおよびPID=zでそれぞれ区別される3本のビデオストリームが、1つのクリップAVストリームに多重化されている。
また、各々のビデオストリームは、Iピクチャの位置でランダムアクセスが可能とされる。図3において、四角で示されるソースパケットに対し、3本のビデオストリームのそれぞれについて、Iピクチャの先頭バイトを含むソースパケットを、塗り潰し、斜線、斜線および「×(ばつ)」印で区別して示している。塗り潰しなどがなされていない四角は、ランダムアクセスポイントとならないビデオデータが含まれるソースパケットや、ビデオデータ以外のデータが含まれるソースパケットを示す。
一例として、PID=xで区別されるビデオストリームについて、ランダムアクセス可能なIピクチャの先頭バイトを含む、ソースパケット番号X1のソースパケットは、クリップAVストリームの時間軸において、PTS=pts(x1)の位置に配置される。同様に、当該ビデオストリームの次にランダムアクセス可能なIピクチャの先頭バイトを含むソースパケットは、ソースパケット番号X2とされ、時間軸においてPTS=pts(x2)の位置に配置される。
図4は、この図3のクリップAVストリームに対応したEP_mapの例を概念的に示す。図4の例では、EP_mapは、フィールドstream_PID 、エントリPTS _EP_start およびエントリSPN _EP_start の各データを持つ。フィールドstream_PID は、ビデオストリームを伝送するトランスポートパケットのPIDが格納される。エントリPTS _EP_start は、ランダムアクセス可能なIピクチャから始まるアクセスユニット(詳細は後述する)のPTSが格納される。エントリSPN _EP_start は、AVストリームの中でエントリPTS _EP_start の値により参照されるアクセスユニットの第1バイト目を含むソースパケットのアドレスが格納される。
上述の図3に示される例を参照して、EP_mapにおいて、各ビデオストリームのPIDがフィールドstream_PID にそれぞれ格納され、フィールドstream_PID 毎に、エントリPTS _EP_start およびエントリSPN _EP_start の対応関係からなるテーブルEP_map _for _one _stream_PID() が作られる。例えば、図4において、PID=xで表されるビデオストリームについては、テーブルEP_map _for _one _stream_PID[0]に対して、PTS=pts(x1)とソースパケット番号X1、PTS=pts(x2)とソースパケット番号X2、・・・、PTS=pts(xk)とソースパケット番号Xkとがそれぞれ対応することが記述される。このテーブルが、同じクリップAVストリームに多重化された、他のPIDで表されるビデオストリームについて、それぞれ作られる。このEP_mapが、当該クリップAVストリームに対応するクリップインフォメーションファイルに格納される。
図5は、上述した、ランダムアクセス可能なIピクチャから始まるアクセスユニットを説明するための図である。図5中で、四角はピクチャを表し、「Entry Point」の矢印が指し示すピクチャがランダムアクセス可能なIピクチャから始まるアクセスユニットである。図5Aおよび図5Bは、MPEG4 AVC|H.264で定義されるIDRピクチャについて示す。MPEG4 AVC|H.264によれば、復号順序でIDRピクチャより後ろのピクチャをIDRピクチャよりも前のピクチャから予測することが禁止される。
なお、MPEG4 AVC|H.264においては、連続する一連のアクセスユニットをシーケンスと呼び、各シーケンスは、それぞれ独立して復号することが可能である。シーケンスの先頭は、必ずIDRピクチャでなければならない。IDRピクチャでは、バッファがリセットされ、また、そのIDRピクチャよりも復号順で前のピクチャを参照することが禁止されている。そのため、シーケンス毎に独立的に、その先頭からの復号を開始することができる。
図5Aの例では、IDRピクチャより復号順序で後のピクチャであるピクチャp12を、IDRピクチャより復号順序で前のピクチャであるピクチャp10から予測して符号化することが禁止される。また、図5Bの例では、図中の" GOP切れ目" 以後のピクチャの復号順序がIDRピクチャ、ピクチャb1 0、ピクチャp13、ピクチャb1 2の順であることを想定している。このとき、ピクチャb10は、復号順でIDRピクチャよりも後ろのピクチャであるので、IDRピクチャよりも前のピクチャp02から予測して符号化することが禁止される。同様に、図5Bにおいて、ピクチャp13をピクチャp02から予測することが禁止される。
図5Cは、図5BのIDRピクチャをIピクチャ(ピクチャi11)に置き換えた例である。この場合、ピクチャi11は、現在のGOPのIピクチャよりも表示順序で未来のピクチャを、過去のGOPのピクチャから予測することを禁止するように制限して、ビデオストリームの符号化を行う。図5Cの例では、ピクチャp13をピクチャp02から予測することを、符号化時に禁止する。
なお、MPEG4 AVC|H.264では、MPEG2のように明示的にGOPを規定していない。この発明の実施の一形態においては、復号順序でIDRピクチャまたはIピクチャから開始して、次のIDRピクチャまたはIピクチャの直前までのピクチャの集合を、便宜的にGOPと呼ぶことにする。また、MPEG4 AVC|H.264では、Iスライス、PスライスおよびBスライスといったように、異なるフレーム間符号化タイプを、1枚のピクチャ中にスライスレベルで混在させることができる。この発明の実施の一形態においては、Iピクチャとは、ピクチャの中の全てのスライスがIスライスであるピクチャを指す。
図6は、フィールドSPN _EP_start が指すソースパケット(source packet) の一例のデータ構造を示す。上述もしたが、ソースパケットは、サイズが188バイトのトランスポートパケットにサイズが4バイトのヘッダTP_extra _headerを付加してなる。トランスポートパケット部分は、ヘッダ部(TP header) とペイロード部とからなる。フィールドSPN _EP_start は、図5を用いて説明したIDRピクチャまたはIピクチャから始まるアクセスユニットの第1バイト目を含むソースパケットのソースパケット番号が格納される。MPEG4 AVC|H.264においては、アクセスユニットすなわちピクチャは、AUデリミタ(Access Unit Delimiter) から開始する。AUデリミタの後に、SRS(Sequence Parameter Set)と、PPS(Picture Parameter Set) が続く。そしてその後に、図5で説明したIDRピクチャまたはIピクチャのスライスのデータの、先頭部分または全体が格納される。
トランスポートパケットのヘッダ(TPヘッダ)において、フラグpayload _unit_start _indicator が値" 1" であれば、新たなPESパケットがこのトランスポートパケットのペイロードから始まることが示され、このソースパケットからアクセスユニットが開始されることが示される。
次に、EP_mapについて、図7、図8および図9を用いて、より詳細に説明する。テーブルEP_map _for _one _stream_PID() は、図7に一例が示されるように、2つのサブテーブルEP_coarseおよびEP_fineに分けられる。サブテーブルEP_coarseは、大まかな単位での検索を行うためのテーブルであり、サブテーブルEP_fineは、より精密な単位での検索を行うためのテーブルである。このように、EP_mapを2つのテーブルに分けて構成することで、テーブルEP_map _for _one _stream_PID() のデータサイズを削減し、且つ、データサーチのパフォーマンスを改善することができる。
図7の例では、サブテーブルEP_fineは、エントリPTS _EP_fineとエントリSPN _EP_fineとが対応付けられるテーブルである。サブテーブル内では、エントリのそれぞれに対して、例えば最上列を" 0" として昇順にエントリ番号が与えられる。サブテーブルEP_fineにおいて、エントリPTS _EP_fineとエントリSPN _EP_fineとを合わせたデータ幅は、4バイトとされる。一方、サブテーブルEP_coarseは、エントリref _to_EP_fine_id、エントリPTS _EP_coarseおよびエントリSPN _EP_coarseが対応付けられるテーブルである。エントリref _to_EP_fine_id、エントリPTS _EP_coarseおよびエントリSPN _EP_coarseを合わせたデータ幅は、8バイトとされる。サブテーブルEP_fineのエントリ数Nfは、サブテーブルEP_coarseのエントリ数Ncより少ない値となる。
サブテーブルEP_fineのエントリは、EP_map中のエントリPTS _EP_start およびエントリSPN _EP_start それぞれのLSB(Least Significant Bit) 側のビット情報からなる。また、サブテーブルEP_coarseのエントリは、これらエントリPTS _EP_start およびエントリSPN _EP_start それぞれのMSB(Most Significant Bit)側のビット情報と、それに対応するサブテーブルEP_fineのテーブル中のエントリ番号からなる。このエントリ番号は、同じデータPTS _EP_start から取り出したLSB側のビット情報を持つサブテーブルEP_fineの中のエントリである。
図8は、エントリPTS _EP_coarseおよびエントリPTS _EP_fineの一例のフォーマットについて示す。PTSすなわちエントリPTS _EP_start は、データ長が33ビットの値である。MSBのビットを第32ビット、LSBのビットを第0ビットとするとき、この図8の例では、大まかな単位で検索を行う際に用いられるエントリPTS _EP_coarseは、エントリPTS _EP_start の第32ビットから第19ビットまでの14ビットが用いられる。エントリPTS _EP_coarseにより、解像度が5.8秒で、26.5時間までの範囲で検索が可能である。また、より精密な検索を行うためのエントリPTS _EP_fineは、エントリPTS _EP_start の第19ビットから第9ビットまでの11ビットが用いられる。エントリPTS _EP_fineにより、解像度が5.7ミリ秒で、11.5秒までの範囲で検索が可能である。なお、第19ビットは、エントリPTS _EP_coarseとエントリPTS _EP_fineとで共通して用いられる。また、LSB側の第0ビットから第8ビットまでの9ビットは、用いられない。
図9は、エントリSPN _EP_coarseおよびエントリSPN _EP_fineの一例のフォーマットについて示す。ソースパケット番号すなわちエントリSPN _EP_start は、データ長が32ビットの値である。MSBのビットを第31ビット、LSBのビットを第0ビットとするとき、この図9の例では、大まかな単位で検索を行う際に用いられるエントリSPN _EP_coarseは、エントリSPN _EP_start の第31ビットから第0ビットまでの全てのビットが用いられる。また、より精密な検索を行うためのエントリSPN _EP_fineは、エントリSPN _EP_start の第16ビットから第0ビットまでの17ビットが用いられる。エントリSPN _EP_fineにより、例えば略25MB(Mega Byte) のAVストリームファイルまでの範囲で、検索が可能である。
なお、ソースパケット番号の場合でも、エントリSPN _EP_coarseとしてMSB側の所定ビット数の値だけ用いるようにしてもよい。例えば、エントリSPN _EP_coarseとして、エントリSPN _EP_start の第31ビットから第16ビットまでの17ビットを用い、エントリSPN _EP_fineは、エントリSPN _EP_start の第16ビットから第0ビットまでの17ビットを用いる。
図10は、テーブルEP_map _for _one _stream_PID() の一例のシンタクスを示す。ここでは、シンタクスをコンピュータ装置などのプログラムの記述言語として用いられるC言語の記述法に基づき示す。これは、他のシンタクスを表す図において、同様である。
テーブルEP_map _for _one _stream_PID() は、全体としてブロックEP_map() を構成する。フィールドnumber_of_stream_PID _entries は、EP_mapの中での、テーブルEP_map _for _one _stream_PID のエントリ数を示す。以下、引数を値[k]
として、for ループ内の内容がフィールドnumber_of_stream_PID _entries に格納される値になるまで繰り返される。フィールドstream_PID[k]は、EP_mapの中で[k]
番目にエントリされるテーブルEP_map _for _one _stream_PID (以下、[k] 番目のテーブルEP_map _for _one _stream_PID と記述する)によって参照されるエレメンタリストリームを伝送するトランスポートパケットのPIDの値を示す。フィールドEP_stream_type[k] は、[k] 番目のテーブルEP_map _for _one _stream_PID のによって参照されるエレメンタリストリームのタイプを示す。フィールドnum _EP_coarse_entries[k]は、[k] 番目のテーブルEP_map _for _one _stream_PID の中にあるサブテーブルEP-coarse のエントリ数を示す。フィールドnum _EP_fine_entries[k]は、[k]
番目のテーブルEP_map _for _one _stream_PID の中にあるサブテーブルEP-fine のエントリ数を示す。フィールドEP_map _for _one _stream_PID _start _address[k]は、ブロックEP_map() の中で[k] 番目のテーブルEP_map _for _one _stream_PID が始まる相対バイト位置を示す。この値は、ブロックEP_map() の第1バイト目からのバイト数で示される。
上述のfor ループが終了した後、パディングワードを挟んで、ブロックEP_map _for
_one _stream_PID が開始される。ブロックEP_map _for _one _stream_PID は、図3および図4で説明したように、トランスポートストリームに多重化された1または複数のAVストリームのうち1つのストリームに対するEP_mapD/A変換留。
図11は、ブロックEP_map _for _one _stream_PID の一例のシンタクスを示す。ブロックEP_map _for _one _stream_PID のセマンティクスを説明するために、先ず、ブロックEP_map _for _one _stream_PID に格納されるデータの元となるエントリである、エントリPTS _EP_start およびエントリSPN _EP_start の意味について説明する。エントリPTS _EP_start と、エントリPTS _EP_start に関連付けられたエントリSPN _EP_start は、それぞれAVストリーム上のエントリポイントを指す。そして、エントリPTS _EP_fineと、エントリPTS _EP_fineに関連付けられたエントリPTS _EP_coarseは、同一のエントリPTS _EP_start から導かれる。また、エントリSPN _EP_fineと、エントリSPN _EP_fineに関連付けられたエントリSPN _EP_coarseは、同一のエントリSPN _EP_start から導かれる。
エントリPTS _EP_start およびエントリSPN _EP_start は、次のように定義される。
エントリPTS _EP_start は、図8で示したように、データ長が33ビットの符号無し整数であり、AVストリーム中で、図5で説明したIDRピクチャまたはIピクチャから開始するビデオアクセスユニットの33ビット長のPTSを示す。
エントリSPN _EP_start は、図9で示したように、32ビットの符号無し整数であり、エントリPTS _EP_start に関連付けられたビデオアクセスユニットの第1バイト目を含むソースパケットの、AVストリームの中でのアドレスを示す。エントリSPN _EP_start は、ソースパケット番号の単位で表され、AVストリームファイル中の最初のソースパケットから、値" 0" を初期値として、ソースパケット毎に1ずつ増加する値としてカウントされる。
ブロックEP_map _for _one _stream_PID のセマンティクスを説明する。図11に示されるように、ブロックEP_map _for _one _stream_PID は、大まかな単位での検索を行うためのサブテーブルEP_coarseを記述するための第1のfor ループと、第1のfor ループの検索結果に基づきより詳細な検索を行うためのサブテーブルEP_fineを記述するための第2のfor ループとからなる。これら第1および第2のfor ループに先んじて、フィールドEP_fine_table _start _address が配される。フィールドEP_fine_table _start _address は、最初の第2のfor ループにおけるフィールドEP_video _type[EP _fine_id] の第1バイト目の開始アドレスを、ブロックEP_map _for _one _stream_PID() の第1バイト目からの相対バイト数で示す。相対バイト数は、値" 0" から開始する。
第1のfor ループは、引数[i] で以て、サブテーブルEP_coarseのエントリ数Ncまで繰り返される。第1のfor ループにおいて、フィールドref _to_EP_fine_id[i] は、フィールドref _to_EP_fine_id[i] に続くフィールドPTS _EP_coarse[i] が示すエントリPTS _EP_coarseに関連付けられるエントリPTS _EP_fineを持つ、サブテーブルEP_fine内のエントリ番号を示す。エントリPTS _EP_fineと、このエントリPTS _EP_fineに関連付けられるエントリPTS _EP_coarseとは、同一のエントリPTS _EP_start
から導かれる。フィールドref _to_EP_fine_id[i] は、第2のfor ループ中で記述される順番で定義される引数[EP _fine_id] の値により与えられる。
第1のfor ループの後に、パディングワードを挟んで第2のfor ループが配される。第2のfor ループは、サブテーブルEP_fineの行数Nfを最大値として、引数[EP _fine_id] で繰り返される。第2のfor ループにおいて、フィールドEP_video _type[EP _fine_id] およびフィールドI _end _position_offset[EP _fine_id] の次に、フィールドPTS _EP_fine[EP _fine_id] およびフィールドSPN _EP_fine[EP _fine_id]
がそれぞれ配される。フィールドPTS _EP_fine[EP _fine_id] およびフィールドSPN
_EP_fine[EP _fine_id] は、引数[EP _fine_id] によりサブテーブルEP_fineから参照されるエントリPTS _EP_fineおよびエントリSPN _EP_fineそれぞれが格納される。
エントリPTS _EP_coarseおよびエントリPTS _EP_fine、ならびに、エントリSPN _EP_coarseおよびエントリSPN _EP_fineは、次のように導かれる。サブテーブルEP_fineに、関連するデータSPN _EP_start の値の昇順に並んでいるNf個のエントリがあるとする。それぞれのエントリPTS _EP_fineは、対応するエントリPTS _EP_start から、次式(1)のように導かれる。
PTS _EP_fine[EP _fine_id] =(PTS _EP_start[EP_fine_id] >>9)/211 ・・(1)
エントリPTS _EP_coarseと、対応するエントリPTS _EP_fineとの関係は、次式(2)、(3)の通りである。
PTS _EP_coarse[i] =(PTS _EP_start[ref _to_EP_fine_id[i]] >> 19)/214 ・・(2)
PTS _EP_fine[ref_to_EP_fine_id[i]]=(PTS _EP_start[ref _to_EP_fine_id[i]] >> 9)/211 ・・(3)
それぞれのエントリSPN _EP_fineは、対応するエントリSPN _EP_start から、次式(4)のように導かれる。
SPN _EP_fine[EP _fine_id] =SPN _EP_start[EP_fine_id] /217 ・・(4)
エントリSPN _EP_coarseと、対応するエントリSPN _EP_fineとの関係は、次式(5)、(6)の通りである。
SPN _EP_coarse[i] =SPN _EP_start[ref _to_EP_fine_id[i]] ・・(5)
SPN _EP_fine[ref_to_EP_fine_id[i]]=SPN _EP_start[ref _to_EP_fine_id[i]]/217 ・・(6)
なお、上述の式(1)〜(6)において、記号「>>x」は、データのLSB側からxビットを超える桁からビットを用いることを意味する。
次に、上述したようなEP_mapの作成の手順について、図12のフローチャートを用いて説明する。この図12のフローチャート処理は、図16を用いて後述する多重化ストリーム解析部25において行われる。例えば、図1および図2を用いて説明したようなフォーマットのトランスポートストリームで以て入力されるAVストリームを記録媒体に記録する動作に伴い、このフローチャートの処理が行われる。
入力されたトランスポートストリームは、多重化ストリーム解析部25に入力される。ステップS10でEP_mapの作成が開始されると、ステップS11で、多重化ストリーム解析部25は、入力されるトランスポートストリームを解析し、記録するクリップAVストリーム中のビデオのPIDをセットする。入力されるトランスポートストリーム中にPIDが異なる複数のビデオが含まれるときは、それぞれのビデオPIDをセットする。ステップS12で、多重化ストリーム解析部25は、入力されたトランスポートストリームから、セットされたビデオPIDを持つビデオのトランスポートパケットを選別し、受信する。
次のステップS13で、多重化ストリーム解析部25は、受信したトランスポートパケットのペイロードがPESパケットの第1バイト目から開始しているか否かを調べる。これは、トランスポートパケットヘッダ中のフラグpayload _unit_start _indicator の値により判別でき、この値が" 1" で、当該トランスポートパケットのペイロードがPESパケットの第1バイト目から始まることが示される。若し、当該トランスポートパケットのペイロードがPESパケットの第1バイト目から始まっていないと判断されれば、処理はステップS12に戻される。
ステップS13で、当該トランスポートパケットのペイロードがPESパケットの第1バイト目から始まっていると判断されれば、処理はステップS14に移行する。ステップS14において、多重化ストリーム解析部25は、当該PESパケットのPESパケットデータ部が、図5を用いて説明したIDRピクチャまたはIピクチャの何れかから開始するビデオのアクセスユニットの第1バイト目から開始しているか否かを調べる。これは、図6を用いて説明したように、アクセスユニットデリミタおよびアクセスユニットデリミタ後に続くSPSおよびPPSを調べることで分かる。若し、第1バイト目から始まっていないと判断されれば、処理はステップS12に戻される。
ステップS14で、当該PESパケットのPESパケットデータ部が、IDRピクチャまたはIピクチャ何れかから開始するビデオのアクセスユニットの第1バイト目から開始していると判断されれば、処理はステップS15に移行する。ステップS15において、多重化ストリーム解析部25は、現在のトランスポートパケット(すなわちソースパケット)を、エントリポイントとする。
そして、次のステップS16で、多重化ストリーム解析部25は、ステップS15でエントリポイントとしたトランスポートパケット(ソースパケット)のパケット番号(ソースパケット番号)と、当該パケットに格納されるIDRピクチャまたはIピクチャのPTSと、当該エントリポイントが属するビデオのPIDとを取得する。取得されたこれらの情報は、多重化ストリーム解析部25から制御部へと渡される。制御部は、渡されたこれらの情報に基づき、EP_mapを作成する。
なお、エントリポイントとしたトランスパケットのパケット番号は、例えば、クリップAVストリームファイルの第1バイト目が格納されたトランスポートパケットのパケット番号を" 0" として、ステップS12でビデオのトランスポートパケットを受信する毎にパケット番号を" 1" ずつカウントアップしていくことで得られる。IDRピクチャまたはIピクチャのPTSは、PESパケットのヘッダ部に格納される。
次のステップS17で、多重化ストリーム解析部25は、現在入力されたトランスポートパケットが最後に入力されるトランスポートパケットであるか否かが判断される。最後のトランスポートパケットであると判断された場合、一連の処理が終了される。最後のトランスポートパケットではないと判断されれば、処理は、ステップS12に戻される。
次に、トランスポートストリーム中でビデオPIDが変化する場合について説明する。このような場合は、図13Aに例示されるように、EP_map中に、サブテーブルとしてビデオPID毎にさらにEP_mapを持たせるとよい。例えば、図13Bに一例が示されるように、クリップAVストリームファイルの前半のビデオPID=xが、後半にビデオPID=yに変化する場合について考える。
この場合、当該クリップAVストリームファイルに対応するクリップインフォメーションファイルが有するEP_mapに、図13Aに一例が示されるように、ビデオPID=xのトランスポートパケット(ソースパケット)に対応するEP_mapと、ビデオPID=yのトランスポートパケットに対応するEP_mapとを、それぞれサブテーブルとして持たせる。ビデオPID=xに対応するEP_mapおよびビデオPID=yに対応するEP_mapそれぞれのエントリPTS _EP_start は、同一の時間軸上での再生時系列に対応した値とされている。そのため、サーチ再生などの際には、図13Bに一例が示されるように、ビデオPID=xのソースパケットおよびビデオPID=yのIDRピクチャまたはIピクチャを、EP_map中のサブテーブルのエントリPTS _EP_start に従って、再生時系列に沿って順次、アクセスすることができる。
次に、IピクチャまたはIDRピクチャをサーチする動作について説明する。図14は、IピクチャまたはIDRピクチャをサーチする場合の一例のプレーヤモデルを示す。以下では、IピクチャまたはIDRピクチャをサーチすることを、便宜上、Iピクチャサーチと呼ぶ。また、図15は、図14のプレーヤモデルによるIピクチャサーチの一例の処理を示すフローチャートである。
図14において、プレーヤモデルは、ドライブ100、ファイルシステム101、ホストコントローラ102、デマルチプレクサ103およびデコーダ104を備える。ホストコントローラ102は、例えばCPU(Central Processing Unit) からなり、ファイルシステム101、デマルチプレクサ103およびデコーダ104は、それぞれハードウェアで構成することもできるし、CPU上で動作するソフトウェアで構成してもよい。図示されないユーザインターフェイス(UI)は、ユーザからの指示をホストコントローラに伝える。
クリップAVストリームファイルがトランスポートストリーム化されて記録された、例えば光ディスクからなる記録媒体がドライブ100に装填される。ステップS20で、ファイルシステム101は、ドライブ100に装填されたディスクを再生し、ディスクからクリップインフォメーションファイルを読み出し、インフォメーションファイル中のEP_mapのデータをホストコントローラ102に送る。
一方、UIは、ユーザの指示に基づき、再生するプログラムのプログラム番号およびサーチ開始時間のPTSをセットする。セットされた値は、ホストコントローラ102に送られる(ステップS21)。次のステップS22で、ホストコントローラ102は、EP_mapから、サーチ開始時間を示すPTSに対応するエントリSPN _EP_start を検索し、検索されたエントリSPN _EP_start が指し示すソースパケット番号のビデオPIDを、デマルチプレクサ103にセットする。
例えば、サーチ開始時間に対応するPTSのMSB側の14ビットに基づき、EP_mapのサブテーブルEP_coarseからエントリPTS _EP_coarseを検索し、対応するエントリref _to_EP_fine_idおよびエントリSPN _EP_coarseを得る。エントリSPN _EP_coarseに基づき、サーチ先のソースパケットの大まかな位置を知ることができる。そして、得られたエントリref _to_EP_fine_idに基づきサブテーブルEP_fineの検索範囲を設定し、設定された検索範囲内でサブテーブルEP_fineを検索する。検索結果として、サーチ開始時間に対応するPTSのLSB側の第10ビットからの11ビットの値に対応するエントリPTS _EP_fineを得る。このエントリPTS _EP_fineに対応するエントリSPN
_EP_coarseが指し示すソースパケット番号のビデオPIDがデマルチプレクサ103にセットされる。
なお、エントリSPN _EP_fineがエントリSPN _EP_start のMSB側17ビットを用いている場合には、エントリSPN _EP_fineとエントリSPN _EP_coarseとを所定に結合した値が指し示すソースパケット番号のビデオPIDがデマルチプレクサ103にセットされる。
次のステップS23で、ホストコントローラ102は、ステップS22で得られたソースパケット番号に対応するデータアドレスを、ファイルシステム101にセットする。ファイルシステム101は、指定されたデータアドレスからトランスポートストリームを読み出すように、ドライブ100に指示する。ドライブ100は、この指示に基づき、指定されたデータアドレスからトランスポートストリームを読み出す。このトランスポートストリームは、ファイルシステム101に渡され、ファイルシステム101からデマルチプレクサ103に渡される。
デマルチプレクサ103は、供給されたトランスポートストリームからヘッダTP_extra _headerを取り除いてトランスポートパケット化し、上述のステップS22でセットされたビデオPIDに基づき、対応するトランスポートパケットを選別して取り出す。そして、取り出されたトランスポートパケットからトランスポートパケットヘッダを取り除き、ペイロードを繋ぎ合わせて元のAVストリームを復元する。このAVストリームは、デコーダ104に供給されて所定に復号され、オーディオおよびビデオ出力とされる。
ステップS25で、ユーザによる次のサーチ指示があるか否かが判断され、次のサーチ指示がある場合には、処理はステップS21に戻される。
上述したように、エントリSPN _EP_fineが指し示すソースパケット番号のデータは、ランダムアクセス可能なIピクチャまたはIDRピクチャから始まるアクセスユニットの第1バイト目を含むソースパケットのアドレスを示している。上述のような処理により、サーチ動作などおいて、ランダムアクセス可能なIピクチャまたはIDRピクチャが常にアクセスされ、MPEG4 AVC|H.264ビデオストリームにおけるランダムアクセス再生が保障される。
次に、上述の図1で示されるアプリケーション構造のデータを記録再生するシステムについて説明する。図16は、この発明の実施の一形態に適用できる動画像記録再生装置の一例の構成を示す。
制御部17は、例えばCPU(Central Processing Unit) 、ROM(Read Only Memory)およびRAM(Random Access Memory)などからなる。ROMは、CPU上で動作されるプログラムや動作のために必要なデータが予め記憶される。RAMは、CPUのワークメモリとして用いられる。CPUは、ROMに記憶されたプログラムやデータを必要に応じて読み出し、RAMをワークメモリに用いながら、この動画像記録再生装置の全体を制御する。
また、各種のスイッチなどの操作子や、簡易的に表示を行う表示素子を有する図示されないユーザインターフェイスがユーザインターフェイス入力出力端子28に接続される。ユーザのユーザインターフェイスに対する操作に応じた制御信号が、ユーザインターフェイス入力出力端子28を介して制御部17に供給される。また、制御部17で生成された表示制御信号がインターフェイス入力出力端子28を介してユーザインターフェイスに供給される。ユーザインターフェイスは、この表示制御信号をテレビジョン受像器などのモニタ装置に供給し、表示させることもできる。
先ず、記録時の動作について説明する。入力端30にビデオ信号が入力される。入力端31にオーディオ信号が入力される。入力されたビデオ信号およびオーディオ信号は、AVエンコーダ23に供給される。ビデオ信号は、ビデオ解析部24にも供給される。AVエンコーダ23は、入力されたビデオ信号およびオーディオ信号を符号化し、符号化ビデオストリームV、符号化オーディオストリームAおよびシステム情報Sをそれぞれ出力する。
AVエンコーダ23は、入力されたビデオ信号を、図5を用いて説明したIピクチャのように、現在のGOPのIピクチャよりも表示順序で未来のピクチャを、過去のGOPから予測することを禁止するように制限して符号化する。例えば、AVエンコーダ23は、入力されたビデオ信号をMPEG4 AVC|H.264に準拠した符号化方式で符号化する。この場合、上述したようにしてGOP毎にIピクチャを形成するようにして符号化を行ってもよいし、GOP毎にIDRピクチャを配置して符号化を行うこともできる。
AVエンコーダ23は、オーディオ信号を、例えばMPEG1オーディオストリームやドルビーAC3オーディオストリームなどの形式に符号化する。システム情報Sは、符号化ピクチャやオーディオフレームのバイトサイズ、ピクチャの符号化タイプといった、ビデオ信号やオーディオ信号の符号化情報や、ビデオおよびオーディオの同期などに関する時間情報からなる。
AVエンコーダ23のこれらの符号化出力は、マルチプレクサ22に供給される。マルチプレクサ22は、供給された符号化ビデオストリームV、符号化オーディオストリームAを、システム情報Sに基づき多重化し、多重化ストリームを出力する。多重化ストリームは、例えばMPEG2トランスポートストリームや、MPEG2プログラムストリームである。多重化ストリームがMPEG2トランスポートストリームの場合、符号化ビデオストリームV、符号化オーディオストリームAおよびシステム情報Sは、それぞれトランスポートパケットのペイロードのサイズに分割され、所定のヘッダを付加されて、トランスポートパケット化される。ヘッダには、それぞれのデータ種類などを識別可能なように、PIDが所定に格納される。
マルチプレクサ22から出力された多重化ストリームは、端子50Aが選択されたスイッチ50を介してソースパケッタイザ21および上述した多重化ストリーム解析部25に供給される。ソースパケッタイザ21は、供給された多重化ストリームを、記録媒体のアプリケーションフォーマットに従って、例えば図2を用いて説明したような、ソースパケットから構成されるクリップAVストリームに符号化する。
ソースパケッタイザ21で符号化されたクリップAVストリームは、ECC(Error Correction Coding) 符号化部20でエラー訂正符号化され、変調部19で記録符号に変調され、書き込み部18に供給される。書き込み部18は、制御部17から供給される制御信号の指示に基づき、変調部19で記録符号に変調されたクリップAVストリームを、記録可能な記録媒体10に対して記録する。
この動画像記録再生装置は、クリップAVストリームが多重化されたトランスポートストリームを直接的に入力して、記録媒体に記録することができるようになっている。例えば、ディジタルインターフェイスまたはディジタルテレビジョンチューナから出力される、ディジタルテレビジョン放送などによるトランスポートストリームが入力端子32に対して入力される。
入力されたトランスポートストリームの記録方法としては、トランスペアレントに記録する方法と、記録ビットレートを下げるなどの目的のために再エンコードして記録する方法とが考えられる。この2通りの記録方法のうち何方を用いて記録を行うかを指示は、例えばユーザのユーザインターフェイスに対する操作によりなされ、この操作に応じた制御信号がユーザインターフェイス入力出力端子28を介して制御部17に供給される。制御部17は、この制御信号に基づきこの動画像記録再生装置の各部を制御し、記録方法の制御を行う。
入力トランスポートストリームをトランスペアレントに記録する場合、スイッチ50において端子50Bが選択されると共に、スイッチ51において端子51Aが選択され、入力端32から入力されたトランスポートストリームは、スイッチ51および50を介してソースパケッタイザ21および多重化ストリーム解析部25にそれぞれ供給される。これ以降の処理は、上述した、入力端30および31に入力されたビデオ信号およびオーディオ信号を符号化して記録する場合と同一である。
一方、入力トランスポートストリームを再エンコードして記録する場合、スイッチ51において端子51Bが選択され、入力端32から入力されたトランスポートストリームは、デマルチプレクサ15に供給される。デマルチプレクサ15は、供給されたトランスポートストリームに多重化されている符号化ビデオストリームV、符号化オーディオストリームAおよびシステム情報Sを分離し、符号化ビデオストリームVをAVデコーダ16に供給すると共に、符号化オーディオストリームAおよびシステム情報Sをマルチプレクサ22に供給する。
AVデコーダ16は、デマルチプレクサ15から供給された符号化ビデオストリームVを復号し、復号されたビデオ信号をAVエンコーダ23に供給する。AVエンコーダ23は、供給されたこのビデオ信号を符号化して符号化ビデオストリームVとする。この符号化は、上述と同様に、図5を用いて説明したIピクチャのように、現在のGOPのIピクチャよりも表示順序で未来のピクチャを、過去のGOPから予測することを禁止するように制限して符号化する。この符号化ビデオストリームVは、マルチプレクサ22に供給される。
マルチプレクサ22は、AVエンコーダ23で符号化され供給された符号化ビデオストリームVと、デマルチプレクサ15で分離された符号化オーディオストリームAとを、同じくデマルチプレクサ15で分離されたシステム情報Sに基づき多重化して多重化ストリームを出力する。これ以降の処理は、上述した、入力端30および31に入力されたビデオ信号およびオーディオ信号を符号化して記録する場合と同一である。
この動画像記録再生装置は、記録媒体10に対して上述のようにしてクリップAVストリームファイルを記録すると共に、記録するクリップAVストリームファイルに関連するアプリケーションデータベース情報をさらに記録する。アプリケーションデータベース情報は、ビデオ解析部24からの動画像の特徴情報と、多重化ストリーム解析部25からのクリップAVストリームの特徴情報と、端子28から入力されるユーザの指示情報とに基づき、制御部17により作成される。
ビデオ解析部24から得られる、動画像の特徴情報は、AVエンコーダ23によりビデオ信号を符号化して記録する場合に、この動画像記録再生装置内において生成される情報である。ビデオ解析部24は、入力端30から入力されたビデオ信号または入力端32から入力されたトランスポートストリームからデマルチプレクサ15で分離されAVデコーダ16で復号されたビデオ信号が供給される。ビデオ解析部24は、供給されたビデオ信号の内容を解析し、入力されたビデオ信号中の特徴的なマーク点の画像に関する情報を生成する。例えば、ビデオ解析部24は、入力ビデオ信号中のプログラムの開始点、シーンチェンジ点や、CM(コマーシャル)放映の開始、終了点などの特徴的なマーク点を検出し、検出されたマーク点の画像の指示情報を得る。また、マーク点の画像のサムネイル画像を生成するようにしてもよい。サムネイル画像は、実際の画像データを間引き処理などにより縮小した画像である。また、サムネイル画像のクリップAVストリーム上の位置は、PTSで示すことができる。
これらの画像の指示情報、サムネイル画像およびサムネイル画像の位置情報(例えばPTS)は、制御部17を介してマルチプレクサ22に供給される。マルチプレクサ22は、制御部17から指示されるマーク点の画像を符号化した符号化ピクチャを多重化する際に、当該符号化ピクチャのクリップAVストリーム上でのアドレス情報を制御部17に返す。制御部17は、特徴的な画像の種類と、対応する符号化ピクチャのクリップAVストリーム上でのアドレス情報とを関連付けて、例えばRAMに記憶する。
多重化ストリーム解析部25から得られる、クリップAVストリームの特徴情報は、記録されるクリップAVストリームの符号化情報に関連する情報であり、この動画像記録再生装置内において生成される。例えば、クリップAVストリームについて、エントリポイントのタイムスタンプと対応するアドレス情報とをクリップAVストリームの特徴情報として含む。この他にも、クリップAVストリームについて、STC(System Time Clock)
の不連続情報、プログラム内容の変化情報、アライバルタイムと対応するアドレス情報などが、クリップAVストリームの特徴情報として含まれる。
ここで、クリップAVストリーム内のエントリポイントとなる、図5で説明したIDRピクチャまたはIピクチャから開始するビデオアクセスユニットのタイムスタンプおよびアドレス情報は、上述のEP_mapに格納されるデータとなる。また、クリップAVストリーム内でのプログラム内容の変化情報は、クリップインフォメーションファイル中のブロックProgramInfo (図示しない)に格納されるデータとなる。
また、多重化ストリーム解析部25は、入力端32から入力されるトランスポートストリームをトランスペアレントに記録する場合、クリップAVストリーム中の特徴的なマーク点画像を検出し、検出された画像の種類とアドレス情報とを生成する。この情報は、クリップインフォメーションファイル中のブロックClipMark(図示しない)に格納されるデータとなる。このように、多重化ストリーム解析部25により得られたクリップAVストリームの特徴情報は、クリップAVストリームのデータベースであるクリップインフォメーションファイルに格納されることになる。多重化ストリーム解析部25で得られたこれらの情報は、例えば、制御部17のRAMに一旦記憶される。
図示されないユーザインターフェイスに対してなされたユーザの指示情報は、ユーザインターフェイス入力出力端子28から制御部17に供給される。この指示情報は、例えば、クリップAVストリーム中でユーザが気に入った再生区間の指定情報、当該再生区間の内容を説明するためのキャラクタ文字、ユーザが気に入ったシーンにセットするブックマーク点やリジューム点のクリップAVストリーム中のタイムスタンプなどが含まれる。これらのユーザの指示情報は、一旦、制御部17のRAMに記憶される。これらの指示情報は、記録媒体10上においては、プレイリストが有するデータベース(図示しない)に格納される。
制御部17は、RAM上に記憶された上述した入力情報、すなわち、ビデオ解析部24から得られる動画像の特徴情報、多重化ストリーム解析部25から得られるクリップAVストリームの特徴情報、ならびに、ユーザインターフェイス入力出力端子28から入力されたユーザ指示情報に基づき、クリップAVストリームのデータベース(クリップインフォメーション)、プレイリストのデータベース、記録媒体の記録内容に対する管理情報(info.drv)およびサムネイル情報を作成する。これらのデータベース情報は、制御部17のRAMから読み出され、クリップAVストリームと同様にして、制御部17からECC符号化部20に供給されエラー訂正符号化され、変調部19で記録符号に変調され、書き込み部18に供給される。書き込み部18は、制御部17から供給される制御信号に基づき、記録符号化されたデータベース情報を記録媒体10に記録する。
次に、再生時の動作について説明する。記録媒体10は、記録時の動作で説明したようにして作成された、クリップAVストリームファイルとアプリケーションデータベース情報とが記録されている。記録媒体10が図示されないドライブ装置に装填されると、先ず、制御部17は、読み出し部11に対して、記録媒体10上に記録されたアプリケーションデータベース情報を読み出すように指示する。読み出し部11は、この指示を受けて、記録媒体10からアプリケーションデータベース情報を読み出す。読み出し部11の出力は、復調部12に供給する。
復調部12は、読み出し部11の出力を復調し、記録符号を復号してディジタルデータとする。復調部12の出力は、ECC復号部13に供給され、エラー訂正符号が復号されエラー訂正処理が行われる。エラー訂正処理されたアプリケーションデータベース情報は、制御部17に供給される。
制御部17は、アプリケーションデータベース情報に基づいて、記録媒体10に記録されているプレイリストの一覧を、ユーザインターフェイス入力出力端子28を介してユーザインターフェイスに出力する。このプレイリストの一覧は、例えばユーザインターフェイスに設けられた表示部に所定に表示される。ユーザにより、このプレイリストの一覧から再生したいプレイリストが選択され、選択したプレイリストを再生するような操作がユーザインターフェイスに対してなされる。この操作に応じた制御信号がユーザインターフェイスから出力され、端子28を介して制御部17に供給される。
制御部17は、この制御信号に応じて、選択されたプレイリストの再生に必要なクリップAVストリームファイルの読み出しを、読み出し部11に指示する。読み出し部11は、この指示に従い、記録媒体10からクリップAVストリームファイルを読み出す。読み出し部11の出力は、復調部12に供給される。復調部12は、供給された信号を復調し、記録符号を復号してディジタルデータとして出力し、ECC復号部13に供給する。ECC復号部13は、供給されたディジタルデータのエラー訂正符号を復号し、エラー訂正を行う。エラー訂正されたクリップAVストリームファイルは、制御部17により提供される図示されないファイルシステム部の処理を受け、ソースデパケッタイザ14に供給される。
ソースデパケッタイザ14は、制御部17の制御に基づき、記録媒体10におけるアプリケーションフォーマットで記録されていたクリップAVストリームファイルを、デマルチプレクサ15に入力できる形式のストリームに変換する。例えば、ソースデパケッタイザ14は、記録媒体10から再生されたBDAV MPEG2トランスポートストリーム(図2参照)をソースパケット単位に分解し、ソースパケットからヘッダTP_extra _headerを取り除きトランスポートパケット化する。このトランスポートパケット化されたクリップAVストリームを、デマルチプレクサ15に供給する。
デマルチプレクサ15は、制御部17の制御に基づき、ソースデパケッタイザ14から供給されたクリップAVストリームの、制御部17により指定された再生区間(PlayItem)を構成するビデオストリームV、オーディオストリームAおよびシステム情報Sを出力し、AVデコーダ16に供給する。例えば、デマルチプレクサ15は、供給されたトランスポートパケットをPIDに基づき選別し、選別されたそれぞれについて、トランスポートパケットヘッダを取り除いて出力する。AVデコーダ16は、供給されたビデオストリームVおよびオーディオストリームAを復号し、復号された再生ビデオ信号および再生オーディオ信号をビデオ出力端26およびオーディオ出力端27にそれぞれ導出する。
このような再生時の構成において、ユーザによって選択されたプレイリストを、クリップAVストリーム上のある時間から途中再生する場合の動作は、次のようになる。制御部17は、指定された時間に最も近いPTSを持つエントリポイント、すなわち、図5を用いて説明したIDRピクチャまたはIピクチャから開始するビデオアクセスユニットのアドレスを、上述したようにして、指定された時間のPTSに基づきEP_mapを用いて検索する。そして、制御部17は、得られたアドレスからクリップAVストリームファイルを読み出すように、読み出し部11に指示する。
読み出されたクリップAVストリームファイルは、既に説明したようにして、復調部12、ECC復号部13、ソースデパケッタイザ14、デマルチプレクサ15およびAVデコーダ16を経て、再生ビデオ信号および再生オーディオ信号とされ、出力端26および27にそれぞれ導出する。
読み出し部11は、この指示に基づき記録媒体10からクリップAVストリームファイルを読み出す。読み出されたクリップAVストリームファイルは、復調部12、ECC復号部13およびソースデパケッタイザ14を経てデマルチプレクサ15に供給され、デマルチプレクサ15でトランスポートパケット化されてAVデコーダ16に供給される。
また、クリップインフォメーション中のブロックClipMarkに格納されている、番組の頭出し点やシーンチェンジ点の中から、ユーザがあるマークを選択した場合の再生動作は、次のようになる。例えば、クリップインフォメーション中のブロックClipMarkに格納されている番組の頭出し点やシーンチェンジ点のサムネイル画像リストを、制御部17が図示されないユーザインターフェイスに表示し、ユーザは、このサムネイル画像リストから所望のサムネイル画像を選択することで、この再生動作が開始される。サムネイル画像が選択されると、選択されたサムネイル画像に対応するクリップAVストリーム上の位置情報(例えばPTS)が制御部17に供給される。
制御部17は、クリップインフォメーションの内容に基づいて、記録媒体10からクリップAVストリームを読み出す位置を決定し、読み出し部11にクリップAVストリームの読み出しを指示する。より具体的には、制御部17は、ユーザが選択したサムネイル画像に対応するピクチャが格納されているクリップAVストリーム上のアドレスに最も近いアドレスにあるエントリポイント、すなわち、図5を用いて説明したIDRピクチャまたはIピクチャから開始するビデオアクセスユニットのアドレスを、上述したようにして、サムネイル画像に対応した時間のPTSに基づきEP_mapを用いて検索する。そして、制御部17は、得られたアドレスからクリップAVストリームファイルを読み出すように、読み出し部11に指示する。
読み出されたクリップAVストリームファイルは、既に説明したようにして、復調部12、ECC復号部13、ソースデパケッタイザ14、デマルチプレクサ15およびAVデコーダ16を経て、再生ビデオ信号および再生オーディオ信号とされ、出力端26および27にそれぞれ導出する。
なお、記録媒体10は、特に種類を限定されない。例えば、Blu−ray Disc(ブルーレイディスク)規格に沿ったディスク状記録媒体を記録媒体10として用いることができる。Blu−ray Disc規格では、記録媒体として直径12cm、カバー層0.1mmのディスクを用い、光学系として波長405nmの青紫色レーザ、開口数0.85の対物レンズを用いて、最大で27GB(ギガバイト)の記録容量を実現している。
これに限らず、ハードディスクを記録媒体10として用いることができる。また、ディスク状記録媒体に限らず、例えば大容量の半導体メモリを記録媒体10として用いることができる。さらに、記録可能な仕様のDVD(Digital Versatile Disc)、例えばDVD−R(DVD-Recordable)、DVD−RAM(DVD-Random Access Memory)DVD−RW(DVD-Rewritable)、DVD+RWを記録媒体10として用いることができる。同様に、CD−R(Compact Disc-Recordable) やCD−RW(Compact Disc-ReWritable) を記録媒体10として用いることができる。
また、記録媒体10は、記録可能な記録媒体に限定されない。すなわち、上述した動画像記録再生装置の記録時のプロセスと同様のプロセスを経て形成されたデータが予め記録された、再生専用の記録媒体を、記録媒体10として用いることができる。例えば、上述したBlu−ray Discの規格に基づいた再生専用のディスク(BD−ROMと呼ぶ)が提案されている。このBD−ROMを、記録媒体10として用いることができる。これに限らず、再生専用のDVD−ROM(DVD-Read Only Memory)やCD−ROM(Compact Disc-Read Only Memory) を記録媒体10として用いてもよい。
すなわち、図5を用いて説明したIピクチャのように、現在のGOPのIピクチャよりも表示順序で未来のピクチャを、過去のGOPから予測することを禁止するように制限して符号化したクリップAVストリームと、この符号化に対応して作成されたEP_mapとを、予めこのような再生専用の記録媒体に記録して、ユーザに提供する。
記録媒体10として再生専用の記録媒体を用いる場合でも、再生部側の動作は、上述と同一である。勿論、記録部側の動作は、行えないようにされる。また、再生専用の記録媒体を用いる場合において、上述の図16の構成を、記録部側の構成を省略した動画像再生装置とすることもできる。
さらに、上述の図16の構成を、再生部側の構成を省略した動画像記録装置とすることもできる。この場合、この動画像記録装置で作成された記録媒体10を、この実施の一形態によるEP_mapに対応した動画像再生装置で再生すると、サーチ動作などが円滑に行われ、好ましい。
さらにまた、上述では、図16に示す動画像記録再生装置がハードウェア的に構成されるように説明したが、これはこの例に限定されない。すなわち、動画像記録再生装置は、実際に記録媒体10が装填されるドライブ部などの機構部分以外の部分を、ソフトウェアとして構成することも可能である。この場合、ソフトウェアは、例えば制御部17が有するROMに予め記憶される。これに限らず、動画像記録再生装置を、パーソナルコンピュータなどのコンピュータ装置上に構成することも可能である。この場合には、動画像記録再生装置をコンピュータ装置に実行させるソフトウェアは、CD−ROMやDVD−ROMといった記録媒体に記録されて提供される。コンピュータ装置がネットワーク接続可能な場合、インターネットなどのネットワークを介して当該ソフトウェアを提供することも可能である。
さらに、上述では、多重化ストリームがMPEG2トランスポートストリームであるとして説明したが、これはこの例に限定されない。多重化ストリームとしてMPEG2プログラムストリームやDSS(Digital Satellite System)トランスポートストリームを用いるシステムに対してこの発明を適用することもできる。MPEG2プログラムストリームの場合は、ソースパケットの代わりに、パックが用いられる。