JP2004088267A - データ記録方法、データ記録装置、データ変換方法、データ変換装置、データ記録媒体、データ記録のためのプログラムおよびそのプログラムを記録した記録媒体 - Google Patents

Abstract

【課題】エレメンタリストリーム同士を多重化した構成のストリームを、ＭＰＥＧ２−ＴＳ（ＰＳ）のファイルフォーマットのストリームに容易に変換する。
【解決手段】１個以上のＧＯＰ７０４を含む１個以上のＶＵ７０３を含むＡＶストリームと、このＡＶストリームを記録する領域とは別の領域にＶＵ７０３に関する第１の管理情報としてＭｏｖｉｅ　Ａｔｏｍを光ディスクに記録しておく。また、ＡＶストリーム中に、ユニットの個々に関する第２の管理情報としてＩＳＯ　ｂａｓｅ　ｍｅｄｉａ　ｆｉｌｅ　ｆｏｒｍａｔにおけるＭｏｖｉｅ　Ｆｒａｇｍｅｎｔを記録しておく。Ｍｏｖｉｅ　Ｆｒａｇｍｅｎｔは、対応する第ユニットを構成する前記ＧＯＰ７０４を構成するビデオフレームデータ毎のデータ量に関する情報を持っている。光ディスクから読み出されたＡＶストリームを他のＡＶストリームに変換する際に、データ量に関する情報を用いることによって、ＧＯＰ７０４を解析することなく、ストリーム変換できる。
【選択図】　図３５

Description

【０００１】
【発明の属する技術分野】
本発明は、ハードディスク、光ディスク、半導体メモリ等のランダムアクセス可能な記録媒体に対して、映像データおよび音声データを記録するデータ記録方法、データ記録装置、データ変換方法、データ変換装置、データ記録媒体、データ記録媒体、データ記録のためのプログラム、およびそのプログラムが記録された記録媒体に関するものである。
【０００２】
【従来の技術】
ディスクメディアを用いたビデオのディジタル記録再生装置（以下、ビデオディスクレコーダと呼ぶ）が普及しつつある。その記録フォーマットには、ＰＣ（パーソナルコンピュータ）との親和性を高めるため、ＰＣで広く使われている、ＱｕｉｃｋＴｉｍｅ（商標）ファイルフォーマットを用いることがよく行われる。
【０００３】
ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットを用いたビデオデータの管理については、特開２００１−１７６１９５号公報に開示されている。以下、図３９を用いてその概要を説明する。
【０００４】
ビデオデータは、ムービーファイル５００１に格納されている。ムービーファイル５００１は、実際のビデオデータおよびオーディオデータを格納するＭｏｖｉｅ　ｄａｔａ　ａｔｏｍ　と、ビデオデータおよびオーディオデータを管理するためのＭｏｖｉｅ　ａｔｏｍとで構成される。
【０００５】
Ｍｏｖｉｅ　ｄａｔａ　ａｔｏｍ　中では、入力されたオーディオとビデオとのＥＳ（Ｅｌｅｍｅｎｔａｒｙ　Ｓｔｒｅａｍ）が所定の時間（１秒程度）に対応するアクセスユニット（ＭＰＥＧ２ビデオであればＧＯＰ（Ｇｒｏｕｐ　ｏｆ　Ｐｉｃｔｕｒｅｓ）　、ＭＰＥＧ２オーディオであればオーディオフレームとしてのＡＡＵ（Ａｕｄｉｏ　Ａｃｃｅｓｓ　Ｕｎｉｔ）　）毎に区切り、これらを交互に配置する。それぞれの区切られた単位は、ＱｕｉｃｋＴｉｍｅ　におけるチャンクとして扱われる。また、各オーディオフレームおよびＧＯＰは、ＱｕｉｃｋＴｉｍｅ　におけるサンプルとして扱われる。各サンプルのデータ量および再生時間、ならびにムービーファイル５００１中での各チャンクの相対アドレスは、Ｍｏｖｉｅ　ａｔｏｍに格納し、再生の際は、Ｍｏｖｉｅ　ａｔｏｍを参照することで、ある時間に対応するビデオデータおよびオーディオデータの記録位置を特定することが可能となる。
【０００６】
【発明が解決しようとする課題】
しかしながら、一般に広く用いられているのは、上記のストリーム構成と異なる構成を持ったＩＳＯ／ＩＥＣ　１３８１８−１　に定義されるＴｒａｎｓｐｏｒｔ　Ｓｔｒｅａｍ（以下ＭＰＥＧ　２−ＴＳ　）や、Ｐｒｏｇｒａｍ　Ｓｔｒｅａｍ（以下ＭＰＥＧ　２−ＰＳ　）である。例えば、ＤＶＤ−Ｖｉｄｅｏ　ではＭＰＥＧ２−ＰＳが採用されており、ディジタル放送やＩＥＥＥ−１３９４による機器間のデータ転送形式ではＭＰＥＧ２−ＴＳが採用されている。したがって、上記のストリーム構成で記録したデータをＩＥＥＥ−１３９４による伝送形式で別の機器に転送したり、ＤＶＤプレーヤで再生できるようにするためには、上記のストリーム構成のデータをＭＰＥＧ２−ＰＳやＭＰＥＧ２−ＴＳへ変換する必要がある。ところが、前記の従来技術においては、そのための方法が開示されていない。
【０００７】
本発明は、上記課題を鑑みてなされたものであり、Ｅｌｅｍｅｎｔａｒｙ　Ｓｔｒｅａｍ　同士を多重化したストリーム構成を持ち、そのストリームを、複数のフレームを１単位として管理する場合において、ＭＰＥＧ２−ＴＳ／ＰＳのファイルフォーマットのストリームに容易に変換可能な形態でデータを記録媒体に記録するデータ記録方法等を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明のデータ記録方法および装置は、１個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームを記録する領域とは別の領域に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録方法および装置であって、前記ＡＶストリーム中に前記ユニットの個々に関する第２の管理情報を含んだ状態で前記ＡＶストリームを記録し、前記第２の管理情報が、対応する第ユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴としている。
【０００９】
この方法・装置では、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットでデータ記録媒体に記録されているＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳストリームに変換する際に、ＡＶストリーム中の第２管理情報を用いることによって、画像データ群を解析することなく、通常の記録・再生に必要な管理情報を増やさずに、ストリーム変換することができる。それゆえ、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのＡＶ（Ａｕｄｉｏ　ａｎｄ　Ｖｉｓｕａｌ）ストリームをＭＰＥＧ２−ＴＳのファイルフォーマットを採用する機器（ＩＥＥＥ−１３９４やＤＶＤプレーヤ等）に容易に転送することができる。
【００１０】
上記のデータ記録方法においては、第２の管理情報のデータフォーマットにＩＳＯ　ｂａｓｅ　ｍｅｄｉａ　ｆｉｌｅ　ｆｏｒｍａｔにおけるＭｏｖｉｅ　Ｆｒａｇｍｅｎｔを用いることが好ましい。これにより、通常の記録・再生に必要な管理情報を増やさないだけでなく、再生互換性を高めることができる。
【００１１】
本発明の他のデータ記録方法および装置は、１個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームを記録する領域とは別の領域に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録方法および装置であって、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記ＡＶストリームに含んだ状態で前記データ記録媒体に記録することを特徴としている。
【００１２】
この方法および装置では、上記の遅延時間をデータ記録媒体に記録するので、このデータ記録媒体から読み出された、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットでデータ記録媒体に記録されているＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳストリームに変換する際に、遅延時間を用いることによって、確実にストリーム変換することができる。
【００１３】
このデータ記録方法において、前記遅延時間を含んだ前記ＡＶストリームを記録することが好ましい。これにより、通常の記録・再生に必要な管理情報を増加させることがない。
【００１４】
しかも、前記ＡＶストリーム中に前記ユニットの個々に関して第２の管理情報を含んだ状態で前記ＡＶストリームを記録し、前記第２の管理情報、例えば後述するＶｉｄｅｏ　Ｆｒａｍｅ　Ｉｎｆｏｒｍａｔｉｏｎが、対応するユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間を持つことにより、画像データ群を解析する必要がない。
【００１５】
また、前記第２の管理情報を、対応する前記ユニットの物理的な近傍に配置することにより、ＡＶストリームのデコードの前に必要なバッファメモリの容量を少なくすることができる。あるいは、前記第２の管理情報と前記ＡＶストリームとを同一ファイルで管理し、前記第２の管理情報を対応する前記画像データ群よりも低い前記ファイルの先頭からの相対アドレスアドレスに置くことによっても、バッファメモリの容量が少なくすることができる。
【００１６】
前述のように、遅延時間をＡＶストリーム中に記録した場合、前記遅延時間を少なくとも前記画像データ群外に記録し、前記第１の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間情報を持つことが好ましい。これにより、画像データ群を解析する必要がなくなる。
【００１７】
前記第１の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことが好ましい。これにより、Ｂピクチャにも対応することができる。
【００１８】
前記第１の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記ビデオフレームのピクチャタイプに関する情報および前記遅延時間を持つことが好ましい。これにより、画像データ群を解析する必要がない。
【００１９】
前記第２の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことが好ましい。
【００２０】
本発明のデータ記録プログラムは、前記のデータ記録方法をコンピュータに実行させる。また、このデータ記録プログラムは、コンピュータ読み取り可能な　記録媒体に記録される。
【００２１】
本発明のデータ変換方法および装置は、１個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報とが記録されているデータ記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、変換の際に、前記データ量に関する情報を用いることを特徴としている。この方法では、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットの第１のＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳの第２のストリームに変換する際に、第１のＡＶストリーム中の第２の管理情報を用いることによって、画像データ群を解析することなく、ストリーム変換することができる。それゆえ、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのＡＶ（Ａｕｄｉｏ　ａｎｄ　Ｖｉｓｕａｌ）ストリームをＭＰＥＧ２−ＴＳのファイルフォーマットを採用する機器（ＩＥＥＥ−１３９４やＤＶＤプレーヤ等）に容易に転送することができる。
【００２２】
本発明の他のデータ変換方法および装置は、１個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、前記遅延時間を用いて前記画像データ群を分割して前記第１のＡＶストリームを第２のＡＶストリームに変換することを特徴としている。
【００２３】
この方法では、上記の遅延時間が記録されたデータ記録媒体から読み出された、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳストリームに変換する際に、遅延時間を用いることによって画像データ群（ＧＯＰ）をビデオフレームに分割するので、確実にストリーム変換することができる。
【００２４】
本発明の他のデータ変換方法は、１個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間およびデータ量とが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、前記遅延時間および前記データ量を用いて前記画像データ群を分割して前記第１のＡＶストリームを第２のＡＶストリームに変換することにより、前述のデータ変換方法と同様、画像データ群を解析する必要がないだけでなく、遅延時間およびデータ量を用いることによって、確実にストリーム変換することができる。
【００２５】
本発明のさらに他のデータ変換方法は、１個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間、データ量およびピクチャタイプに関する情報が記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、前記遅延時間、前記データ量および前記ピクチャタイプを用いて前記画像データ群を分割して前記第１のＡＶストリームを第２のＡＶストリームに変換することにより、前述のデータ変換方法と同様、画像データ群を解析する必要がないだけでなく、遅延時間およびデータ量を用いることによって、確実にストリーム変換することができ、さらにＢピクチャにも対応することができる。
【００２６】
本発明のデータ記録媒体は、１個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームが記録された領域とは別の領域に前記ユニットに関する第１の管理情報が記録されているデータ記録媒体であって、前記ＡＶストリームは、前記ユニットの個々に関する第２の管理情報を含み、前記第２の管理情報は、対応する前記ユニットにおける前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴としている。
【００２７】
このようなデータ記録媒体から読み出されたＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのＡＶストリームは、ＭＰＥＧ２−ＴＳ／ＰＳの第２のストリームに変換する際に、ＡＶストリーム中の第２の管理情報を用いることによって、画像データ群を解析することなく、ストリーム変換することができる。それゆえ、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのＡＶ（Ａｕｄｉｏ　ａｎｄ　Ｖｉｓｕａｌ）ストリームをＭＰＥＧ２−ＴＳのファイルフォーマットを採用する機器（ＩＥＥＥ−１３９４やＤＶＤプレーヤ等）に容易に転送することができる。
【００２８】
本発明の他のデータ記録媒体は、１個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームが記録されている領域とは別の領域に前記ユニットに関する第１の管理情報が記録されているデータ記録媒体であって、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されていることを特徴としている。
【００２９】
上記の遅延時間が記録されたデータ記録媒体から読み出された、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳストリームに変換する際に、遅延時間を用いることによって、確実にストリーム変換することができる。
【００３０】
【発明の実施の形態】
以下、本発明の実施形態について、図１ないし図３８を参照しながら詳細に説明する。ここでの説明は、本発明において共通に用いる構成、個々の実施形態に固有の内容という順に行なうものとする。
【００３１】
〔基本システム〕
図１は、後述する各実施形態において共通のビデオディスクレコーダの基本システム構成図である。以下に、この基本システムについて説明する。
【００３２】
＜システム構成＞
このビデオディスクレコーダは、図１に示すように、バス１００、ホストＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、ユーザインタフェース１０４、システムクロック発生器１０５、光ディスク１０６、ピックアップ１０７、ＥＣＣ（Ｅｒｒｏｒ　Ｃｏｒｒｅｃｔｉｎｇ　Ｃｏｄｉｎｇ）デコーダ１０８、ＥＣＣエンコーダ１０９、オーディオ再生用バッファ１１０、ビデオ再生用バッファ１１１、デマルチプレクサ１１２、マルチプレクサ１１３、記録用バッファ１１４、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８、オーディオ記録用バッファ１１９、ビデオ記録用バッファ１２０、ＴＳ／ＰＳ変換部１２１、外部ディジタル出力部１２２、および図示しないカメラ、マイク、スピーカ、ディスプレイ等で構成される。
【００３３】
ホストＣＰＵ１０１は、デマルチプレクサ１１２、マルチプレクサ１１３、ピックアップ１０７、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８、ＴＳ／ＰＳ変換部１２１等の制御をバス１００を通じて行う。デマルチプレクサ１１２、マルチプレクサ１１３、ピックアップ１０７、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８およびＴＳ／ＰＳ変換部１２１は、ハードウエアで構成されていてもよいし、ソフトウエアで構成されていてもよ。
【００３４】
ＲＡＭ１０２は、ビデオディスクレコーダの動作を制御するためにホストＣＰＵ１０１に実行させる制御プログラム等のプログラムやプログラムの実行に必要なデータをロードしたり、プログラムの実行のための作業領域を提供している。また、ＲＡＭ１０２は、再生時のＴＳ／ＰＳ変換部１２１によるファイルフォーマットの変換時等にＡＶストリームの後述する管理情報を読み込む。
【００３５】
ＲＯＭ１０３は、上記のプログラムやデータを格納している。制御プログラムは、後述する記録時の処理を実現するためのデータ記録プログラムやＴＳ／ＰＳ変換部１２１の変換処理を実現するための変換プログラムを含んでいる。このデータ記録プログラムや変換プログラムは、ＲＯＭ１０３に限らず、記憶媒体１２３に記憶されていてもよい。記録媒体１２３は、コンピュータが読み取り可能である光ディスク、光磁気ディスク、磁気ディスク、磁気テープ、半導体メモリ等の媒体であって、ドライブ装置１２４によって駆動される。
【００３６】
ユーザインタフェース１０４は、ユーザがディスプレイの画面上で本ビデオディスクレコーダの各種の操作をリモートコントローラを用いてできるように、操作案内等を画面に表示したりユーザによる操作入力を受け入れたりするためのソフトウエアである。
【００３７】
システムクロック発生器１０５は、ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３等に供給するためのシステムクロックを発生する回路である。
【００３８】
再生時に、光ディスク１０６からピックアップ１０７を通じて読み出されたデータは、ＥＣＣデコーダ１０８によって誤り訂正され、デマルチプレクサ１１２に送られる。デマルチプレクサ１１２は、ホストＣＰＵ１０１からの指示に従い、ＥＣＣデコーダ１０８から読み出されたデータよりオーディオデータおよびビデオデータを抽出して、それぞれをオーディオ再生用バッファ１１０およびビデオ再生用バッファ１１１に振り分ける。オーディオデータおよびビデオデータは、それぞれオーディオ再生用バッファ１１０およびビデオ再生用バッファ１１１に一時的に格納される。オーディオデコーダ１１５およびビデオデコーダ１１６は、ホストＣＰＵ１０１からの指示に従って、それぞれオーディオ再生用バッファ１１０およびビデオ再生用バッファ１１１からデータを読み出しデコードを行う。
【００３９】
一方、記録時には、オーディオデータおよびビデオデータがそれぞれオーディオエンコーダ１１７およびビデオエンコーダ１１８によって圧縮符号化される。圧縮符号化されたオーディオデータおよびビデオデータは、それぞれオーディオ記録用バッファ１１９およびビデオ記録用バッファ１２０に送られ、そこで一時的に格納される。マルチプレクサ１１３は、ホストＣＰＵ１０１からの指示に従って、オーディオ記録用バッファ１１９およびビデオ記録用バッファ１２０からデータを読み出し、これらをＡＶ多重化して記録用バッファ１１４に送る。ＥＣＣエンコーダ１０９は、記録用バッファ１１４から読み出したＡＶ多重化データに対し誤り訂正符号を付加し、ピックアップ１０７を通じて光ディスク１０６に記録する。
【００４０】
また、ＴＳ／ＰＳ変換部１２１は、ホストＣＰＵ１０１からの指示に従って、オーディオ再生用バッファ１１０およびビデオ再生用バッファ１１１に蓄えられている後述のＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのＥＳ（Ｅｌｅｍｅｎｔａｒｙ　Ｓｔｒｅａｍ）　を、ＭＰＥＧ２−ＴＳ（Ｔｒａｎｓｐｏｒｔ　Ｓｔｒｅａｍ）およびＭＰＥＧ２−ＰＳ（Ｐｒｏｇｒａｍ　Ｓｔｒｅａｍ）にファイルフォーマット変換する。このＴＳ／ＰＳ変換部１２１は、ソフトウエアで構成される場合、データ変換プログラムであって、ＲＯＭ１０３または記録媒体１２３に格納されている。変換の結果として生成されたＭＰＥＧ２−ＴＳおよびＭＰＥＧ２−ＰＳフォーマットのデータは、外部ディジタル出力部１２２を介して外部に出力されるか、あるいは記録用バッファ１１４およびＥＣＣエンコーダ１０９を介して光ピックアップ１０７により光ディスク１０６に記録される。
【００４１】
ＥＣＣエンコーダ１０９によるオーディオデータの符号化方式にはＩＳＯ／ＩＥＣ　１１１７２−３で規定されるＭＰＥＧ１　Ｌａｙｅｒ−ＩＩを用いる。一方、ＥＣＣエンコーダ１０９によるビデオデータの符号化方式にはＩＳＯ／ＩＥＣ　１３８１８−２で規定されるＭＰＥＧ２を用いる。光ディスク１０６は、ＤＶＤ−ＲＡＭのような書き換え可能な光ディスクである。この光ディスク１０６においては、２０４８ｂｙｔｅを１セクタとし、誤り訂正のため１６セクタでＥＣＣブロックを構成する。
【００４２】
＜ファイルフォーマット＞
本基本システムにおいて、ＡＶストリーム管理のためのフォーマットとして用いる、ＱｕｉｃｋＴｉｍｅファイルフォーマットについて説明する。ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットとは、Ａｐｐｌｅ　社が開発したマルチメディアデータ管理用フォーマットであり、ＰＣの世界で広く用いられている。また、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットをベースとしてＩＳＯ　ｂａｓｅ　ｍｅｄｉａ　ｆｉｌｅ　ｆｏｒｍａｔが規格化されている。
【００４３】
ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットは、ビデオデータやオーディオデータ等（これらを総称してメディアデータとも呼ぶ）と管理情報とで構成される。両者を合わせてここでは、ＱｕｉｃｋＴｉｍｅ　ムービー（略してムービー）と称する。両者は、同じファイル中に存在してもよいし、別々のファイルに存在してもよい。
【００４４】
図２（ａ）は、両者が同じファイル２０１中に存在する場合にとる構成を示している。各種情報は“ａｔｏｍ”という共通の構造に格納される。より詳細には、第１の管理情報はＭｏｖｉｅ　ａｔｏｍ２１１という構造に格納され、メディアデータはＭｏｖｉｅ　ｄａｔａａｔｏｍ２１２という構造に格納される。Ｍｏｖｉｅ　ａｔｏｍ２１１における管理情報には、メディアデータ中の任意の時間に対応するメディアデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。一方、Ｍｏｖｉｅ　ｄａｔａ　ａｔｏｍ２１２におけるメディアデータすなわちＡＶストリーム（ＡＶ　ｓｔｒｅａｍ）　２１３は、ＡＨ（Ａｔｏｍ　Ｈｅａｄｅｒ）　が付加される。このような構成では、Ｍｏｖｉｅ　ａｔｏｍはメディアデータをａｔｏｍ内で参照している。
【００４５】
図２（ｂ）は、管理情報とメディアデータとをそれぞれ別々のファイル２０２，２０３に格納した場合の構成を示している。管理情報はＭｏｖｉｅ　ａｔｏｍ２１１という構造に格納されるが、メディアデータはａｔｏｍには格納される必要はない。このとき、Ｍｏｖｉｅ　ａｔｏｍ２１１は、メディアデータを格納したファイル２０３を「外部参照」している、という。
【００４６】
図２（ｃ）に示すように、外部参照は、例えば、ファイル２０４におけるＭｏｖｉｅ　ａｔｏｍ２１１から、複数のファイル２０５，２０６にそれぞれ格納されるＡＶストリーム２１３（ＡＶ　ｓｔｒｅａｍ　♯１，♯２）に対して行うことが可能である。このような仕組みにより、ＡＶストリーム２１３自体を物理的に移動することなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」や「非破壊編集」が可能になる。
【００４７】
続いて、図３ないし図２０を用いて、ＱｕｉｃｋＴｉｍｅの管理情報のフォーマットについて説明する。
【００４８】
まず、共通の情報格納フォーマットであるａｔｏｍについて説明する。
【００４９】
ａｔｏｍの先頭には、そのａｔｏｍのサイズであるＡｔｏｍ　ｓｉｚｅ、およびそのａｔｏｍの種別情報であるＴｙｐｅが必ず存在する。Ｔｙｐｅは４文字で区別され、例えば、図３に示すＭｏｖｉｅ　ａｔｏｍでは’ｍｏｏｖ’となっており、Ｍｏｖｉｅ　ｄａｔａ　ａｔｏｍでは’ｍｄａｔ’となっている。ａｔｏｍの先頭にあるＡｔｏｍ　ｓｉｚｅおよびＴｙｐｅの列を、ここでは“ａｔｏｍ　ｈｅａｄｅｒ”と称する。各ａｔｏｍは、別のａｔｏｍを含むことができる。すなわち、ａｔｏｍ間には階層構造がある。
【００５０】
図３は、Ｍｏｖｉｅ　ａｔｏｍの構成を示している。この構造において、“Ｍｏｖｉｅ　ｈｅａｄｅｒａｔｏｍ”は、そのＭｏｖｉｅ　ａｔｏｍが管理するムービーの全体的な属性を管理する。“Ｔｒａｃｋ　ａｔｏｍ”は、そのムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納する。“Ｕｓｅｒ　ｄａｔａ　ａｔｏｍ”は、ユーザにて独自に定義可能なａｔｏｍである。
【００５１】
図４は、Ｔｒａｃｋ　ａｔｏｍの構成を示している。“Ｔｒａｃｋ　ｈｅａｄｅｒ　ａｔｏｍ”は、そのトラックの全体的な属性を管理する。“Ｅｄｉｔ　ａｔｏｍ”は、メディアデータのどの区間を、ムービーのどのタイミングで再生するかを管理する。“Ｔｒａｃｋ　ｒｅｆｅｒｅｎｃｅ　ａｔｏｍ”は、本トラックと別のトラックとの関係を管理する。“Ｍｅｄｉａ　ａｔｏｍ”は、実際のビデオやオーディオといったデータを管理する。
【００５２】
図５は、Ｔｒａｃｋ　ｈｅａｄｅｒ　ａｔｏｍの構成を示している。ここでは、後での説明に必要なもののみについて説明する。“Ｆｌａｇｓ”は、属性を示すフラグの集合であり、代表的なものとしてＴｒａｃｋ　ｅｎａｂｌｅｄフラグがあり、このフラグが１であれば、そのトラックは再生され、０であれば再生されない。“Ｌａｙｅｒ”は、そのトラックの空間的な優先度を表しており、画像を表示するトラックが複数あれば、Ｌａｙｅｒの値が小さいトラックほど画像が前面に表示される。
【００５３】
図６は、Ｍｅｄｉａ　ａｔｏｍの構成を示している。“Ｍｅｄｉａ　ｈｅａｄｅｒ　ａｔｏｍ”は、そのＭｅｄｉａ　ａｔｏｍの管理するメディアデータに関する全体的な属性等を管理する。“Ｈａｎｄｌｅｒ　ｒｅｆｅｒｅｎｃｅ　ａｔｏｍ”は、メディアデータをどのデコーダでデコードするかを示す情報を格納する。“Ｍｅｄｉａ　ｉｎｆｏｒｍａｔｉｏｎ　ａｔｏｍ”は、ビデオやオーディオ等のメディア固有の属性情報を管理する。
【００５４】
図７は、Ｍｅｄｉａ　ｉｎｆｏｒｍａｔｉｏｎ　ａｔｏｍの構成を示している。“Ｍｅｄｉａ　ｉｎｆｏｒｍａｔｉｏｎ　ｈｅａｄｅｒ　ａｔｏｍ”は、ビデオやオーディオ等メディア固有の属性情報を管理する。“Ｈａｎｄｌｅｒ　ｒｅｆｅｒｅｎｃｅ　ａｔｏｍ”は、前述のＭｅｄｉａ　ａｔｏｍに含まれるものと同じである。“Ｄａｔａ　ｉｎｆｏｒｍａｔｉｏｎ　ａｔｏｍ”は、そのＱｕｉｃｋＴｉｍｅムービーが参照するメディアデータを含むファイルの名称を管理するａｔｏｍである“Ｄａｔａ　ｒｅｆｅｒｅｎｃｅ　ａｔｏｍ”を含む。“Ｓａｍｐｌｅ　ｔａｂｌｅ　ａｔｏｍ”は、データのサイズや再生時間等を管理している。
【００５５】
次に、Ｓａｍｐｌｅ　ｔａｂｌｅ　ａｔｏｍについて説明するが、その前に、ＱｕｉｃｋＴｉｍｅにおけるデータの管理方法について、図８を用いて説明する。
【００５６】
ＱｕｉｃｋＴｉｍｅでは、データの最小単位（例えばビデオフレーム）をサンプル（ｓａｍｐｌｅ）と称する。サンプルには、個々のトラック毎に、再生時間順に１から番号（サンプル番号）が♯１，♯２，…♯ｉというように付与されている。
【００５７】
また、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のサンプルの再生時間長およびデータサイズを管理している。しかも、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンク（ｃｈｕｎｋ）　と称する。チャンクにも、サンプルと同様に、再生時間順に１から番号が付与されている。
【００５８】
さらに、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のチャンクのファイル先頭からのアドレスおよび個々のチャンクが含むサンプル数を管理している。これらの情報に基づき、任意の時間に対応するサンプルの位置を求めることが可能となっている。
【００５９】
図９は、Ｓａｍｐｌｅ　ｔａｂｌｅ　ａｔｏｍの構成を示している。“Ｓａｍｐｌｅ　ｄｅｓｃｒｉｐｔｉｏｎ　ａｔｏｍ”は、個々のチャンクのデータフォーマット（Ｄａｔａ　ｆｏｒｍａｔ）　やサンプルが格納されているファイルのチャンクの　Ｉｎｄｅｘ等を管理する。“Ｔｉｍｅ−ｔｏ−ｓａｍｐｌｅ　ａｔｏｍ”は、個々のサンプルの再生時間を管理する。
【００６０】
“Ｓｙｎｃ　ｓａｍｐｌｅ　ａｔｏｍ”は、個々のサンプルのうち、デコード開始可能なサンプルを管理する。“Ｓａｍｐｌｅ−ｔｏ−ｃｈｕｎｋ　ａｔｏｍ”は、個々のチャンクに含まれるサンプル数を管理する。“Ｓａｍｐｌｅ　ｓｉｚｅ　ａｔｏｍ”は、個々のサンプルのサイズを管理する。“Ｃｈｕｎｋ　ｏｆｆｓｅｔ　ａｔｏｍ”は、個々のチャンクのファイル先頭からのアドレスを管理する。
【００６１】
図１０は、Ｅｄｉｔ　ａｔｏｍ　の構成を示している。Ｅｄｉｔ　ａｔｏｍ　は、１個のＥｄｉｔ　ｌｉｓｔ　ａｔｏｍを含む。Ｅｄｉｔ　ｌｉｓｔ　ａｔｏｍは、Ｎｕｍｂｅｒ　ｏｆ　ｅｎｔｒｉｅｓで指定される個数分の、“Ｔｒａｃｋ　ｄｕｒａｔｉｏｎ”、“Ｍｅｄｉａ　ｔｉｍｅ”、“Ｍｅｄｉａ　ｒａｔｅ”の値の組（エントリ）を持つ。各エントリは、トラック上で連続的に再生される区間に対応し、そのトラック上での再生時間順に並んでいる。
【００６２】
Ｔｒａｃｋ　ｄｕｒａｔｉｏｎは、そのエントリが管理する区間のトラック上での再生時間を表している。Ｍｅｄｉａ　ｔｉｍｅは、そのエントリが管理する区間の先頭に対応するメディアデータ上での位置を表している。Ｍｅｄｉａ　ｒａｔｅは、そのエントリが管理する区間の再生スピードを表している。
【００６３】
なお、Ｍｅｄｉａ　ｔｉｍｅが−１の場合は、そのエントリのＴｒａｃｋ　ｄｕｒａｔｉｏｎ分、そのトラックに無再生区間を挿入する。この区間のことをｅｍｐｔｙ　ｅｄｉｔと称する。
【００６４】
図１１は、Ｅｄｉｔ　ｌｉｓｔ　の使用例を示す。ここでは、Ｅｄｉｔ　ｌｉｓｔ　ａｔｏｍの内容が図１１（ａ）に示す内容であり、さらにサンプルの構成が図１１（ｂ）であったとする。なお、ここではｉ番目のエントリのＴｒａｃｋ　ｄｕｒａｔｉｏｎをＤ（ｉ）　、Ｍｅｄｉａ　ｔｉｍｅをＴ（ｉ）　、Ｍｅｄｉａ　ｒａｔｅをＲ（ｉ）　とする。このとき、実際のサンプルの再生は、図１１（ｃ）に示す順に行われる。このことについて簡単に説明する。
【００６５】
まず、エントリ♯１は、Ｄ（１）　が１３０００、Ｔ（１）　が２００００、Ｒ（１）　が１であるため、そのトラックの先頭から１３０００の区間は、サンプル中の時刻２００００から３３０００の区間を再生する。次に、エントリ♯２は、Ｄ（２）　が５０００、Ｔ（２）　が−１であるため、トラック中の時刻１３０００から１８０００の区間、何も再生を行わない（図１１（ｃ）における“ｎｕｌｌ”）。
【００６６】
最後に、エントリ♯３は、Ｄ（３）　が１００００、Ｔ（３）　が０、Ｒ（３）　が１であるため、トラック中の時刻１８０００から２８０００の区間において、サンプル中の時刻０から１００００の区間を再生する。
【００６７】
図１２は、Ｕｓｅｒ　ｄａｔａ　ａｔｏｍの構成を示している。このａｔｏｍには、ＱｕｉｃｋＴｉｍｅフォーマットで定義されてない独自の情報を任意個数格納することができる。１個の独自情報は１個のエントリで管理され、１個のエントリは“Ｓｉｚｅ”と“Ｔｙｐｅ”と“Ｕｓｅｒ　ｄａｔａ　”とで構成される。Ｓｉｚｅはそのエントリ自体のサイズを表し、Ｔｙｐｅは独自情報をそれぞれ区別するための識別情報を表し、Ｕｓｅｒ　ｄａｔａは実際のデータを表している。
【００６８】
次に、録画中の電源遮断等に対応するために導入された概念であるＦｒａｇｍｅｎｔｅｄＭｏｖｉｅについて説明する。Ｆｒａｇｍｅｎｔｅｄ　ｍｏｖｉｅは、ＱｕｉｃｋＴｉｍｅ　フォーマットの１アプリケーションであるＭｏｔｉｏｎ　ＪＰＥＧ２０００　で導入された概念であり、上述のＳａｍｐｌｅｔａｂｌｅ　ａｔｏｍに相当する情報を、部分的なＡＶストリーム毎に管理することが可能となっている。Ｍｏｔｉｏｎ　ＪＰＥＧ２０００　では、ａｔｏｍの代わりにｂｏｘ　という用語を用いているが、ここでは統一のためにａｔｏｍに置き換えて説明する。
【００６９】
図１３は、Ｆｒａｇｍｅｎｔｅｄ　ｍｏｖｉｅを導入したＱｕｉｃｋＴｉｍｅ　ファイル４０１の全体構成を示している。先頭に、そのファイル全体に共通する情報を管理するＭｏｖｉｅ　ａｔｏｍ（情報管理部）４０２が配置され、その後に、部分ＡＶストリームデータを格納するＭｏｖｉｅ　ｄａｔａ　ａｔｏｍ（データ格納部）４０３と、その部分ＡＶストリームデータを構成するサンプルのアドレスやサイズ、再生時間等を管理するＭｏｖｉｅ　ｆｒａｇｍｅｎｔ　ａｔｏｍ　（管理部）４０４とが交互に配置される。なお、ＡＶストリームデータは、通常の　ＱｕｉｃｋＴｉｍｅファイルと同様、別ファイルに存在しても構わない。
【００７０】
録画時には、この順番で記録を行なっていくことにより、録画時の電源切断による被害を最小限に防ぐことが可能となっている。Ｍｏｖｉｅ　ａｔｏｍ４０２には、そのＱｕｉｃｋＴｉｍｅ　ムービーがＦｒａｇｍｅｎｔｅｄ　ｍｏｖｉｅ　であることを示すためのＭｏｖｉｅ　ｅｘｔｅｎｄｓａｔｏｍ４０２１が含まれる。Ｍｏｖｉｅ　ｅｘｔｅｎｄｓ　ａｔｏｍ４０２１には、そのムービーに含まれる各トラックに関するデフォルト値（Ｔｒａｃｋ　ｅｘｔｅｎｄｓ　ａｔｏｍ４０４２）　が格納される。
【００７１】
また、　Ｍｏｖｉｅ　ｆｒａｇｍｅｎｔ　ａｔｏｍ４０４には、その　Ｍｏｖｉｅ　ｆｒａｇｍｅｎｔ　ａｔｏｍ４０４が管理する部分ＡＶストリームに関する管理情報が含まれている。管理情報には、その管理する部分ＡＶストリーム全体に関する情報を格納するＭｏｖｉｅ　ｆｒａｇｍｅｎｔ　ｈｅａｄｅｒ　ａｔｏｍ　４０４１と、部分ＡＶストリーム中の各トラックに関する情報を格納する　Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ａｔｏｍ４０４２とがある。
【００７２】
Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ａｔｏｍ４０４２は、それが管理するトラックに属する部分ＡＶストリームに関する情報を格納するＴｒａｃｋ　ｆｒａｇｍｅｎｔ　ｈｅａｄｅｒ　ａｔｏｍ４０４３と、そのトラックに属する部分ＡＶストリームを構成する論理的な連続領域（Ｔｒａｃｋ　ｒｕｎと呼ばれる）をそれぞれ管理する　Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ｒｕｎ　ａｔｏｍ４０４４とを含む。以下に、各ａｔｏｍについて詳しく説明する。
【００７３】
図１４は、　Ｍｏｖｉｅ　ｅｘｔｅｎｄｓ　ａｔｏｍ４０２１の構成を示している。Ｍｏｖｉｅ　ｅｘｔｅｎｄｓａｔｏｍ４０２１は、前述のように、このａｔｏｍを含む　ＱｕｉｃｋＴｉｍｅムービーがＦｒａｇｍｅｎｔｅｄ　ｍｏｖｉｅであることを示す役割を持つ。
【００７４】
図１５は、Ｔｒａｃｋ　ｅｘｔｅｎｄｓ　ａｔｏｍ４０２１の構成を示す。Ｔｒａｃｋ　ｅｘｔｅｎｄｓ　ａｔｏｍ　４０２１は、この　ＱｕｉｃｋＴｉｍｅムービーに含まれる各トラックのサンプルのデフォルト値を設定するために存在する。Ｔｒａｃｋ−ＩＤは、Ｍｏｖｉｅ　ａｔｏｍ中で定義されているトラックのｔｒａｃｋ−ＩＤを参照する。“Ｄｅｆａｕｌｔ−ｓａｍｐｌｅ−　”で始まるフィールドは、このａｔｏｍで管理されるｔｒａｃｋ　ｆｒａｇｍｅｎｔのデフォルト値を設定する。
【００７５】
図１６は、　Ｍｏｖｉｅ　ｆｒａｇｍｅｎｔ　ａｔｏｍ４０４の構成を示している。このａｔｏｍは、録画中に逐次記録される管理情報であり、前述のとおり、このａｔｏｍの管理するＭｏｖｉｅ　ｆｒａｇｍｅｎｔに関する実際の情報を格納するａｔｏｍである　Ｍｏｖｉｅ　ｆｒａｇｍｅｎｔ　ｈｅａｄｅｒ　ａｔｏｍ４０４３や　Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ａｔｏｍ４０４２を含む。
【００７６】
図１７は、Ｍｏｖｉｅ　ｆｒａｇｍｅｎｔ　ｈｅａｄｅｒ　ａｔｏｍ４０４３の構成を示している。このａｔｏｍに格納されている主な情報は“ｓｅｑｕｅｎｃｅ−ｎｕｍｂｅｒ　”である。ｓｅｑｕｅｎｃｅ−ｎｕｍｂｅｒは、このａｔｏｍが含まれるＭｏｖｉｅ　ｆｒａｇｍｅｎｔ　ａｔｏｍ４０４が管理するＭｏｖｉｅ　ｆｒａｇｍｅｎｔの先頭からの順番を表す。
【００７７】
図１８は、　Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ａｔｏｍ４０４２の構成を示す。Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ａｔｏｍ４０４３は、Ｍｏｖｉｅ　ｆｒａｇｍｅｎｔに含まれる特定のトラックのサンプルに関する管理情報であるＴｒａｃｋ　ｆｒａｇｍｅｎｔ　ｈｅａｄｅｒ　ａｔｏｍ４０４３やＴｒａｃｋ　ｆｒａｇｍｅｎｔ　ｒｕｎ　ａｔｏｍ４０４４を格納する。
【００７８】
図１９は、Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ｈｅａｄｅｒ　ａｔｏｍ４０４３の構成を示している。このａｔｏｍは、Ｍｏｖｉｅ　ｆｒａｇｍｅｎｔに含まれる特定のトラックのサンプルに関するデフォルト値等を格納する。ｔｒａｃｋ−ＩＤは、Ｍｏｖｉｅ　ａｔｏｍ中で定義されているトラックのｔｒａｃｋ　ＩＤとの対応を示す。ｓａｍｐｌｅ−ｄｅｓｃｒｉｐｔｉｏｎ−ｉｎｄｅｘは、このａｔｏｍが管理するサンプルの参照するｓａｍｐｌｅ　ｄｅｓｃｒｉｐｔｉｏｎ　ｔａｂｌｅのインデックス番号、“ｄｅｆａｕｌｔ−ｓａｍｐｌｅ−　”で始まるフィールドは、それぞれこのａｔｏｍが管理するサンプルのデフォルト値である。
【００７９】
図２０は、　Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ｒｕｎ　ａｔｏｍ４０４４の構成を示す。このａｔｏｍは、Ｔｒａｃｋ　ｒｕｎと呼ばれる、このａｔｏｍの管理する連続領域や個々のサンプルの管理情報を格納する。ｓａｍｐｌｅ−ｃｏｕｎｔは、Ｔｒａｃｋ　ｒｕｎ　に含まれるサンプルの個数を示す。ｄａｔａ−ｏｆｆｓｅｔ　は、ｂａｓｅ−ｄａｔａ−ｏｆｆｓｅｔからのＴｒａｃｋ　ｒｕｎ　のオフセット値を示す。“ｓａｍｐｌｅ−　”で始まるフィールドは、このａｔｏｍが管理するサンプルの再生時間等の値を格納する。ただし、上述のデフォルト値と同じであれば、省略してデータサイズを縮小することが可能となっている。
【００８０】
＜ファイルシステム＞
本発明の説明において用いるファイルシステムのフォーマットであるＵＤＦ（Ｕｎｉｖｅｒｓａｌ　Ｄｉｓｋ　Ｆｏｒｍａｔ）　について図２１を用いて説明する。図２１（ｂ）は、図２１（ａ）に示すディレクトリ／ファイル構成をＵＤＦで記録した例を示す。
【００８１】
図中のＡＶＤＰ（Ａｎｃｈｏｒ　Ｖｏｌｕｍｅ　Ｄｅｓｃｒｉｐｔｏｒ　Ｐｏｉｎｔｅｒ）６０２は、ＵＤＦの管理情報を探すためのエントリポイントに相当し、通常２５６セクタ目、Ｎセクタ目あるいはＮ−２５６セクタ目（Ｎは最大論理セクタ番号）に記録される。
【００８２】
ＶＤＳ（Ｖｏｌｕｍｅ　Ｄｅｓｃｒｉｐｔｏｒ　Ｓｅｑｕｅｎｃｅ）６０１は、ＵＤＦが管理する領域であるボリュームに関する管理情報を記録する。ボリュームは、一般に１枚の光ディスク１０６に１個存在し、その中にパーティションを一般に１個含む。
【００８３】
ＦＳＤ（Ｆｉｌｅ　Ｓｅｔ　Ｄｅｓｃｒｉｐｔｏｒ）　６０３は、パーティションに１個存在する。パーティションの中での位置情報は、パーティションの先頭からのセクタ番号に相当する論理ブロック番号で示される。
【００８４】
なお、１個の論理ブロックは１セクタに対応する。また、各パーティションには図示しないがＳｐａｃｅ　Ｂｉｔｍａｐと呼ばれる各論理ブロックがファイルにすでに割り当てられているか否かを示すテーブルが存在する。
【００８５】
ＦＳＤ６０３は、ルートディレクトリのＦＥ（Ｆｉｌｅ　Ｅｎｔｒｙ）６０４の位置情報（論理ブロック番号と論理ブロック数とで構成されて“ｅｘｔｅｎｔ”と呼ばれる）を含む。ＦＥは、ｅｘｔｅｎｔの集合を管理しており、ｅｘｔｅｎｔを書き換えたり、追加や削除することで、ファイルを構成する実データの順番を変えたり、データの挿入や削除をしたりできる。
【００８６】
ＦＥ６０４は、ルートディレクトリの直下のファイルやディレクトリの名称等を格納するＦＩＤ（Ｆｉｌｅ　Ｉｄｅｎｔｉｆｉｅｒ　Ｄｅｓｃｒｉｐｔｏｒ）６１１，６１２，…の集合を格納する領域６０５を管理する。領域６０５中のＦＩＤ６１１，６１２は、それぞれファイル６２１，６２２のファイル名やｅｘｔｅｎｔの集合を管理するＦＥ６０６，６０８の位置情報を含む。
【００８７】
ＦＥ６０６は、ファイル６２１の実データを構成する領域である領域６０７，６１０をｅｘｔｅｎｔとして管理する。このとき、ファイル６２１の実データにアクセスするには、ＡＶＤＰ６０２、ＶＤＳ６０１、ＦＳＤ６０３、ＦＥ６０４、ＦＩＤ６１１、ＦＥ６０６、領域６０７、領域６１０の順にリンクを辿っていけばよい。
【００８８】
光ディスク１０６のデータ記録領域には、図２１（ｂ）の構成でＡＶストリームが記録されている。前述のムービーファイル、すなわちＡＶストリームやＭｏｖｉｅ　ａｔｏｍ、Ｍｏｖｉｅ　ｆｒａｇｍｅｎｔ　ａｔｏｍ　等の管理情報は、図２１（ｂ）の領域６０７，６１０で表されるファイルを構成する実データとして記録される。例えば、図２（ａ）のムービーファイル２０１のＭｏｖｉｅ　ａｔｏｍ２１１は、領域６１０の前半部分に記録され、ＡＶストリームを含むＭｏｖｉｅ　ｄａｒａ　ａｔｏｍ２１２は、領域６１０の後半部分および領域６０７全体に記録されるようなとこが考えられる。
【００８９】
この場合、ＦＥ６０６には、ファイルシステムを通して、ムービーファイル２０１を読み出したときに、図２（ａ）の順に読み出されるように、領域６１０のｅｘｔｅｎｔ、領域６０７のｅｘｔｅｎｔの順に位置情報を格納する。つまり、この例で示すように、ファイルを構成する実データは、実際には、光ディスク１０６では連続的に記録される保証はなく、また、ファイル中の順序で光ディスク１０６に記録される保証もない。
【００９０】
ただし、次のような例外もある。ディスク媒体に対しては、ディスク上で物理的に離れた場所にあるデータにアクセスするのに、ピックアップの移動を伴い、その間にデータの読み出しおよび記録が停止する。そのため、管理情報を物理的に連続して記録することで、管理情報の読み出しを高速化したり、ＡＶストリームを所定の長さ以上で連続的に記録したりすることで、ビデオデータやオーディオデータを途切れることなく再生することを保証するのはよく知られた技術である。
【００９１】
〔第１の実施形態〕
本発明の第１の実施形態について、図２２ないし図３３を用いて説明する。
【００９２】
＜システム構成＞
本実施形態に係るビデオディスクレコーダは、図１に示す前述のビデオディスクレコーダの構成と共通しているが、本実施形態で特徴的な処理部であるＴＳ／ＰＳ変換部１２１について図２２を用いて詳細に説明する。
【００９３】
ＴＳ／ＰＳ変換部１２１は、ビデオＰＥＳパケット生成部１１０１、ビデオＴＳパケット生成部１１０２、ビデオＴＳパケット用バッファ１１０３、ビデオパック生成部１１０４、ビデオパック用バッファ１１０５、オーディオＰＥＳパケット生成部１１１１、オーディオＴＳパケット生成部１１１２、オーディオＴＳパケット用バッファ１１１３、オーディオパック生成部１１１４、オーディオパック用バッファ１１１５、ＴＳマルチプレクサ１１２１、ＰＳマルチプレクサ１１２２、およびビデオ解析部１１３１より構成される。
【００９４】
次に、それぞれの処理部について説明する。
【００９５】
ビデオＰＥＳパケット生成部１１０１は、ビデオ再生用バッファ１１１から読み出したビデオＥＳ（ビデオフレームデータ）に基づいてＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ　Ｅｌｅｍｅｎｔａｒｙ　Ｓｔｒｅａｍ）パケットを生成する。オーディオＰＥＳパケット生成部１１１１も同様に、オーディオ再生用バッファ１１０から読み出したオーディオＥＳに基づいてＰＥＳパケットを生成する。ビデオ解析部１１３１は、ビデオ再生用バッファ１１１からのビデオＥＳにおけるビデオフレームの境界を検出する。ビデオＰＥＳパケット生成部１１０１は、その境界に基づいてビデオチャンクをビデオフレームに分割する。
【００９６】
ビデオＴＳパケット生成部１１０２は、ビデオＰＥＳパケット生成部１１０１からのＰＥＳパケットに基づいてＴＳ（Ｔｒａｎｓｐｏｒｔ　Ｓｔｒｅａｍ）パケット（ビデオＴＳパケット）を生成する。オーディオＴＳパケット生成部１１１２は、オーディオＰＥＳパケット生成部１１１１からのＰＥＳパケットに基づいてＴＳパケット（オーディオＴＳパケット）を生成する。
【００９７】
ＴＳマルチプレクサ１１２１は、ビデオＴＳパケット生成部１１０２およびオーディオＴＳパケット生成部１１１２によって生成されたＴＳパケットを、多重化してＭＰＥＧ２−ＴＳを生成する。ビデオＴＳパケット用バッファ１１０３およびオーディオＴＳパケット用バッファ１１１３は、ビデオＴＳパケット生成部１１０２およびオーディオＴＳパケット生成部１１１２からのＴＳパケットを一時的に蓄えることにより、両ＴＳパケット生成部１１０２，１１１２とＴＳマルチプレクサ１１２１との処理の時間差を吸収する。
【００９８】
ビデオパック生成部１１０４は、ビデオＰＥＳパケット生成部１１０１から送られてきたビデオＰＥＳパケットをグループ化してビデオパックを生成する。オーディオパック生成部１１１４も同様に、オーディオＰＥＳパケット生成部１１１１から送られてきたオーディオＰＥＳパケットをグループ化してオーディオパックを生成する。
【００９９】
ＰＳマルチプレクサ１１２２は、ビデオパック生成部１１０４およびオーディオパック生成部１１１４によって生成されたパックを多重化してＭＰＥＧ２−ＰＳを生成する。ビデオパック用バッファ１１０５およびオーディオパック用バッファ１１１５は、ビデオパック生成部１１０４およびオーディオパック生成部１１１４からのパックを一時的に蓄えることにより、両パック生成部１１０４，１１１４とＰＳマルチプレクサ１１２２との処理の時間差を吸収する。
【０１００】
＜ＡＶストリームの形態＞
本実施形態において用いるＡＶストリームの構成について、図２３および図２４を用いて説明する。
【０１０１】
ＡＶストリーム７０１は、整数個のＣＵ（Ｃｏｎｔｉｎｕｏｕｓ　Ｕｎｉｔ）　７０２で構成される。ＣＵ７０２は、ディスク上で連続的に記録する単位である。ＣＵ７０２の長さは、ＡＶストリーム７０１を構成するＣＵ７０２をどのように光ディスク１０６上に配置してもシームレス再生（再生中に画像や音声が途切れないで再生できること）やリアルタイムアフターレコーディング（アフレコ対象のビデオをシームレス再生しながらオーディオを記録すること）が保証されるように設定される。この設定方法については後述する。
【０１０２】
ＣＵ７０２は、先頭から連続する番号が♯１，♯２，…，♯Ｌのように付与されており、各ＣＵ７０２は整数個のＶＵ（Ｖｉｄｅｏ　Ｕｎｉｔ）７０３から構成される。ＶＵ７０３は、単独再生可能な単位であり、そのことから再生の際のエントリポイントとなり得る。また、ＶＵ７０３も、先頭から連続する番号が♯１，♯２，…，♯Ｍのように付与される。
【０１０３】
図２４は、ＶＵ７０３構成を示している。ユニットとしてのＶＵ７０３は、１秒程度のビデオデータを格納した複数（整数個）のＧＯＰ７０４（画像データ群）と、それらと同じ時間に再生されるオーディオデータを格納した複数（整数個）のオーディオ復号単位であるＡＡＵ７０５とから構成される。
【０１０４】
なお、ＧＯＰ７０４は、ＭＰＥＧ２ビデオ規格における画像圧縮の単位であり、複数のビデオフレーム（典型的には１５フレーム程度）で構成される。ＡＡＵ７０５は、ＭＰＥＧ１オーディオのレイヤＩＩ（Ｌａｙｅｒ−ＩＩ）規格における音声圧縮の単位で、１１５２点の音波形サンプル点により構成される。サンプリング周波数が４８ｋＨｚの場合、ＡＡＵ７０５あたりの再生時間は０．０２４秒となる。ＶＵ７０３中では、ＡＶ同期再生のために必要となる遅延を小さくするため、ＡＡＵ７０５が配置され、それに続いてＧＯＰ７０４が配置される。
【０１０５】
また、ＶＵ７０３単位で独立再生を可能とするために、ＶＵ７０３におけるビデオデータ（ＧＯＰ７０４）の先頭には、ランダムアクセスの頭出しのために用いられるＳＨ（Ｓｅｑｕｅｎｃｅ　Ｈｅａｄｅｒ）　７０６が配置される。ＶＵ７０３の再生時間は、ＶＵ７０３に含まれるビデオフレーム数にビデオフレーム周期を乗算した時間と定義する。
【０１０６】
ビデオデータについては、ＴＳ／ＰＳへの変換の容易さを考慮して、ピクチャ層（ｐｉｃｔｕｒｅ　ｈｅａｄｅｒ（））におけるｖｂｖ＿ｄｅｌａｙ　に以下の制限を設ける。まず、ＭＰＥＧ２ビデオ規格におけるｖｂｖ＿ｄｅｌａｙ　について説明する。ＭＰＥＧ２ビデオ規格において、ｖｂｖ＿ｄｅｌａｙ　は、一定速度のＣＢＲ（Ｃｏｎｓｔａｎｔ　Ｂｉｔ　Ｒａｔｅ）　の場合、ストリーム検証用の仮想的なモデルであるＶＢＶ（Ｖｉｄｅｏ　Ｂｕｆｆｅｒｉｎｇ　Ｖｅｒｉｆｉｅｒ）におけるＶＢＶバッファにピクチャの最初のデータが入ってから、実際にそのピクチャがデコードされるまでの遅延時間を格納している。一方、可変速度のＶＢＲ（Ｖａｒｉａｂｌｅ　Ｂｉｔ　Ｒａｔｅ）　の場合、ｖｂｖ＿ｄｅｌａｙ　は、ＣＢＲと同様に遅延時間を格納することも、格納しないことも可能である。なお、遅延時間を格納していないことを示すために、ｖｂｖ＿ｄｅｌａｙ　に０ｘＦＦＦＦを格納する。
【０１０７】
本実施形態では、ｖｂｖ＿ｄｅｌａｙ　に対して、ＶＢＲの場合においても必ず、遅延時間を格納するように制限する。このことによって、後述するように、ＴＳ／ＰＳに変換する際、ＭＰＥＧ規格に沿った多重化が容易になる。
【０１０８】
＜ＡＶストリーム管理方法＞
ＡＶストリームの管理方法は、前述の　ＱｕｉｃｋＴｉｍｅファイルフォーマットをベースにしている。
【０１０９】
図２５は、ＡＶストリーム管理形態を示している。ビデオデータ，オーディオデータをそれぞれビデオトラック，オーディオトラックで管理し、ビデオトラックについては、１個のＧＯＰ７０４を１サンプル（Ｓａｍｐｌｅ）、ＶＵ７０３におけるビデオの塊となるＶＣ（Ｖｉｄｅｏ　Ｃｇｈｕｎｋ）７０７を１チャンクとして管理する。オーディオトラックについては、ＡＡＵ７０５を１サンプル、ＶＵ７０３中のオーディオの塊となるＡＣ（Ａｕｄｉｏ　Ｃｈｕｎｋ）　７０８を１チャンクとして管理する。
【０１１０】
＜ＣＵ単位決定方法＞
次に、ＣＵ単位決定方法について説明する。この決定方法では、基準となるデバイス（リファレンスデバイスモデル）を想定し、その上でシームレス再生が破綻しないように連続記録単位を決める。
【０１１１】
まず、リファレンスデバイスモデルについて図２６を用いて説明する。
【０１１２】
リファレンスデバイスモデルは、１個のピックアップとそれにつながるＥＣＣエンコーダデコーダ５０１、トラックバッファ５０２、デマルチプレクサ５０３、アフレコ（アフターレコーディング）用バッファ５０４、オーディオエンコーダ５０９、ビデオバッファ５０５、オーディオバッファ５０６、ビデオデコーダ５０７、およびオーディオデコーダ５０８によって構成される。
【０１１３】
本モデルにおけるシームレス再生は、ＶＵのデコード開始時にトラックバッファ５０２上に少なくとも１個のＶＵが存在すれば保証されるものとする。オーディオフレームデータのＥＣＣエンコーダ５０１へのデータ入力速度およびＥＣＣデコーダ５０１からのデータ出力速度をＲｓとする。
【０１１４】
また、アクセスによる読み出し、記録の停止する最大期間をＴａとする。さらに、短いアクセス（１００トラック程度）に要する時間をＴｋとする。これらの期間（時間）には、シーク時間、回転待ち時間、アクセス後に最初にディスクから読み出したデータがＥＣＣから出力されるまでの時間が含まれる。本実施形態では、Ｒｓ＝２０Ｍｂｐｓ、Ｔａ＝１秒、Ｔｋ＝０．２秒とする。
【０１１５】
前記のリファレンスデバイスモデルにおいて再生を行った場合、次のような条件を満たせば、トラックバッファ５０２のアンダーフローがないことが保証できる。
【０１１６】
条件を示す前にまず、記号を定義する。ＡＶストリームを構成するｉ番目の連続領域をＣ♯ｉとし、Ｃ♯ｉ中に含まれる再生時間をＴｃ（ｉ）　とする。Ｔｃ（ｉ）　は、Ｃ♯ｉ中に先頭が含まれているＶＵの再生時間の合計とする。また、Ｃ♯ｉからＣ♯ｉ＋１へのアクセス時間をＴａとする。
【０１１７】
また、再生時間Ｔｃ（ｉ）　分のＶＵ読み出し時間をＴｒ（ｉ）　とする。この場合、トラックバッファ５０２をアンダーフローさせない条件とは、分断ジャンプを含めた最大読み出し時間をＴｒ（ｉ）　としたとき、任意のＣ♯ｉにおいて、
Ｔｃ（ｉ）　≧Ｔｒ（ｉ）　＋Ｔａ　　　　　　　　　　　　　　　　　　…式１
が成立することである。
【０１１８】
なぜなら、この式はシームレス再生の十分条件である、
【０１１９】
【数１】

【０１２０】
を満たす十分条件であるためである。
【０１２１】
式１中のＴｒ（ｉ）　に、Ｔｒ（ｉ）　＝Ｔｃ（ｉ）　×（Ｒｖ＋Ｒａ）／Ｒｓを代入して、Ｔｃ（ｉ）　で解くと、シームレス再生を保証可能なＴｃ（ｉ）　の条件
Ｔｃ（ｉ）　≧（Ｔａ×Ｒｓ）／（Ｒｓ−Ｒｖ−Ｒａ）　　　　　　　…式２
が得られる。ここで、Ｒａはオーディオデータのビットレートであり、Ｒｖはビデオデータのビットレートである。
【０１２２】
つまり、各連続領域に先頭の含まれるＶＵの合計が上式を満たすようにすれば、シームレス再生を保証可能である。このとき、各連続領域には合計の再生時間が上式を満たす完全なＶＵ群を含むように制限してもよい。
【０１２３】
＜録画時の処理＞
ユーザから録画が指示された場合のホストＣＰＵ１０１が前述のデータ記録プログラムを実行することによって実現される処理を、図２７を参照しながら説明する。
【０１２４】
このとき記録するＡＶストリームは、ビデオのビットレートＲｖの上限が５Ｍｂｐｓであり、オーディオのビットレートＲａが２５６ｋｂｐｓであり、ＶＵ再生時間Ｔｖが約０．５秒固定ストリームであるとする。また、ファイルシステムの管理情報はすでにＲＡＭ１０２上に読み込まれているものとする。
【０１２５】
まず、ストリームの構成や連続領域の構成を決定する（Ｓ７０１）。ここでは、１ＶＵを１ＧＯＰ１５フレームで構成するとしたとき、式２にＲｓ＝２０Ｍｂｐｓ、Ｔａ＝１秒、Ｒｖ＝５Ｍｂｐｓ、Ｒａ＝２５６ｋｂｐｓを代入し、Ｔ（ｃ）　の範囲１．４秒以上が得られる。Ｔｖが約０．５秒であるため、ＣＵは３個のＶＵで構成すればよい。
【０１２６】
まず、ＲＡＭ１０２上のＳｐａｃｅ　Ｂｉｔｍａｐを参照して９個のＶＵを連続的に記録可能な空き領域を探す。空き領域が存在しなければ、録画を中止し、録画できないことをユーザに知らせる（Ｓ７０２）。
【０１２７】
また、オーディオエンコーダ１１７およびビデオエンコーダ１１８をそれぞれ起動する（Ｓ７０３）。そして、記録用バッファ１１４に１ＥＣＣブロック分（例えば３２ＫＢ）以上のデータが蓄積されているか否かをチェックする（Ｓ７０４）。
【０１２８】
１ＥＣＣブロック分以上のデータが蓄積されていれば、次に記録するディスク上のＥＣＣブロックの空き状況をＲＡＭ１０２上のＳｐａｃｅ　Ｂｉｔｍａｐを参照して調べる（Ｓ７０５）。ＥＣＣブロックの空きがなければ、３個のＶＵを記録可能な連続的な空き領域を探し（Ｓ７０６）、その空き領域の先頭へピックアップを移動させる（Ｓ７０７）。
【０１２９】
そして、記録用バッファ１１４中の１ＥＣＣブロック分のデータをディスクに記録して（Ｓ７０８）、処理をＳ７０４に戻す。また、Ｓ７０５でＥＣＣブロックの空きがあれば、Ｓ７０８の記録を行う。Ｓ７０５〜Ｓ７０８の処理は、Ｓ７０４で１ＥＣＣブロック分以上のデータが蓄積されていないと判定されるまで繰り返される。一方、Ｓ７０４で記録用バッファ１１４に１ＥＣＣブロック分のデータが蓄積されていないと判定されると、記録終了が指示されているかどうかをチェックし（Ｓ７０９）、記録終了が指示されていない場合はＳ７０４を実行する。
【０１３０】
Ｓ７０９で記録終了が指示されていた場合、以下のステップを実行する。まず、記録用バッファ１１４における１ＥＣＣブロックに満たないデータに関して、末尾にダミーデータを付加し１ＥＣＣブロックにする（Ｓ７１０）。次に、Ｓ７０５〜Ｓ７０８と同様にして、そのデータをディスク上に記録する（Ｓ７１１〜Ｓ７１４）。ＲＡＭ１０２上の　ＱｕｉｃｋＴｉｍｅ管理情報（Ｍｏｖｉｅ　ａｔｏｍ）とファイルシステム管理情報とを光ディスク１０６に記録して（Ｓ７１５，７１６）、処理を終える。
【０１３１】
以上の処理と並行するオーディオエンコーダ１１７、ビデオエンコーダ１１８やマルチプレクサ１１３の動作について説明する。ビデオエンコーダ１１８およびオーディオエンコーダ１１７がエンコードした結果は、それぞれビデオ記録用バッファ１１８およびオーディオ記録用バッファ１１９に一時的に蓄えられる。マルチプレクサ１１３は、ビデオ記録用バッファ１１８およびオーディオ記録用バッファ１１９からそれぞれデータを読み出し、それらの多重化を行い、記録用バッファ１１４に格納する。
【０１３２】
１ＶＵ分のデータ、つまり１ＧＯＰとそれに同期して再生されるＡＡＵが記録用バッファ１１４に蓄積されたら、マルチプレクサ１１３は記録用バッファ１１４に１ＶＵのデータを送る。
【０１３３】
さらに、マルチプレクサ１１３が、ホストＣＰＵ１０１に１ＶＵ分のデータがエンコードできたことを通知すると、ホストＣＰＵ１０１はＶＵを構成するＧＯＰやＡＡＵの数およびサイズを基にＲＡＭ１０２上の　ＱｕｉｃｋＴｉｍｅ管理情報を更新する。
【０１３４】
＜ＴＳ変換時の処理＞
本実施形態におけるＴＳ変換時の処理を説明する。まず、ここでは、ビデオおよびオーディオそれぞれのＴＳパケット生成手順について説明した後、それらを多重化してＴＳを出力する手順について説明する。
【０１３５】
なお、ＴＳ変換を開始する時点に変換対象のムービーファイルのＭｏｖｉｅ　ａｔｏｍの内容はＲＡＭ１０２に読み込まれているとする。
【０１３６】
（１）ビデオＴＳパケット生成
まず、前述のビデオＰＥＳパケット生成部１１０１、ビデオＴＳパケット生成部１１０２およびビデオ解析部１１３１によるビデオＴＳパケットの生成手順を図２８を用いて説明する。
【０１３７】
ここでは、図２８に示すように、エレメンタリストリームとしてのＡＶストリーム中のｉ番目のビデオチャンクに対応するビデオデータをビデオチャンクＶＣｈｕｎｋ（ｉ）　と称し、ＡＶストリーム中のｊ番目のオーディオチャンクに対応するオーディオデータをオーディオチャンクＡＣｈｕｎｋ（ｊ）　と称する。以下の説明では、ビデオチャンクＶＣｈｕｎｋ（ｉ）　を例に挙げる。ＶＣｈｕｎｋ（ｉ）　のトラック上での再生時刻は、Ｍｏｖｉｅ　ａｔｏｍ（図３参照）の情報から取得することができ、それをＴｖ（ｉ）　とする。
【０１３８】
ビデオＰＥＳパケット生成部１１０１は、ビデオ再生用バッファ１１０から読み出されたビデオエレメンタリストリームにおけるビデオチャンクＶＣｈｕｎｋ（ｉ）　をビデオフレーム単位（ビデオフレームデータ）に分割する。ビデオチャンクＶＣｈｕｎｋ（ｉ）　を構成するビデオフレーム数がＮ（ｉ）　であるとき、それらのビデオフレームデータをＶＦＲＭ（ｉ，０）　，ＶＦＲＭ（ｉ，１）　，…，ＶＦＲＭ（ｉ，Ｎ（ｉ）−１）と称する。ビデオフレームの境界は、図２２に示すビデオ解析部１１３１がＶＣｈｕｎｋ（ｉ）　を解析し、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）を検出することで得られる。なぜなら、ビデオフレームデータの先頭には、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）が存在するため、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）を検出することは、ビデオフレームデータの先頭位置すなわち境界位置を得ることになる。なお、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）の先頭は、特性のビットパターンであるため、ビデオエレメンタリストリーム中から容易に検出することができる。また、ビデオ解析部１１３１は、その解析の際、前述のｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）から、各フレームのピクチャタイプ（Ｉ，Ｐ，Ｂ）も同時に取得する。
【０１３９】
また、ビデオＰＥＳパケット生成部１１０１は、各ビデオフレームデータの先頭データが前述のＶＢＶバッファに入ってからデコードを行うまでの遅延量を求める。ｎ番目のビデオフレームデータの遅延量をＶＤＥＬＡＹ（ｉ，ｎ）　と称し、ｎ番目のビデオフレームデータのｐｉｃｔｕｒｅ　ｈｅａｄｅｒ（）中のｖｂｖ＿ｄｅｌａｙ　を用いる。また、ビデオＰＥＳパケット生成部１１０１は、このビデオストリーム中での最大ビットレートを示す、ｓｅｑｕｅｎｃｅ　ｈｅａｄｅｒ（）　中のｂｉｔｒａｔｅを取得し、変数Ｒｍａｘ　に格納する。
【０１４０】
次に、ビデオＰＥＳパケット生成部１１０１は、ビデオフレームデータをＰＥＳパケットにパケット化する。ＰＥＳパケットＶＰＫＴ（ｉ，０）　，ＶＰＫＴ（ｉ，１）　，…，ＶＰＫＴ（ｉ，Ｎ（ｉ）−１）は、ビデオフレームデータＶＦＲＭ（ｉ，０）　，ＶＦＲＭ（ｉ，１）　，…，ＶＦＲＭ（ｉ，Ｎ（ｉ）−１）から、それぞれ一対一の対応で生成される。
【０１４１】
各ＰＥＳパケットのヘッダ部分には、ビデオデータであることの属性を表すｓｔｒｅａｍ　ｉｄ　やＰＴＳ（Ｐｒｅｓｅｎｔａｔｉｏｎ　Ｔｉｍｅ　Ｓｔａｍｐ）　およびＤＴＳ（Ｄｅｃｏｒｄｉｎｇ　Ｔｉｍｅ　Ｓｔａｍｐ）の２種類のタイムスタンプが設定される。このうち、ｓｔｒｅａｍ　ｉｄ　には１１１０００００ｂが設定される。また、ｎ番目のＰＥＳパケットのＰＴＳ，ＤＴＳをそれぞれＶＰＴＳ（ｉ，ｎ），ＶＤＴＳ（ｉ，ｎ）　と呼ぶとき、ＶＰＴＳ（ｉ，ｎ）　，ＶＤＴＳ（ｉ，ｎ）　は次のルールで設定される。
【０１４２】
なお、各フレームの後に連続するＢピクチャの個数をｂ（ｎ）　と呼ぶ。例えば、Ｉ，Ｂ，Ｂ，Ｐ，…のピクチャが連続するＧＯＰ構成の場合、０番目のビデオフレームであるＩピクチャに対するｂ（０）　は２となる。また、ビデオフレーム周期を９ｋＨｚ　クロックでカウントした値をＴｆとする。まず、ＶＣｈｕｎｋ（ｉ）　中にＢピクチャが存在する場合は、ＩピクチャおよびＰピクチャに対し、
ＰＴＳ（ｉ，ｎ）　＝Ｔｖ（ｉ）　＋（ｎ＋ｂ（ｎ）　）×Ｔｆ
ＤＴＳ（ｉ，ｎ）　＝Ｔｖ（ｉ）　＋（ｎ−１）×Ｔｆ
を設定し、Ｂピクチャに対し、
ＰＴＳ（ｉ，ｎ）　＝Ｔｖ（ｉ）　＋（ｎ−１）×Ｔｆ
ＤＴＳ（ｉ，ｎ）　＝Ｔｖ（ｉ）　＋（ｎ−１）×Ｔｆ
を設定する。一方、ＶＣｈｕｎｋ（ｉ）　中にＢピクチャが存在しない場合、各ビデオフレームに対し、
ＰＴＳ（ｉ，ｎ）　＝ＤＴＳ（ｉ，ｎ）　＝Ｔｖ（ｉ）　＋ｎ×Ｔｆ
を設定する。
【０１４３】
次に、ビデオＴＳパケット生成部１１０２によるＴＳパケットの生成について説明する。
【０１４４】
ビデオＴＳパケット生成部１１０２は、各ＰＥＳパケットを先頭から１８４バイト単位で所定の大きさに分割し、分割されたデータの直前にＴＳパケットのヘッダを４バイト付加することによってＴＳパケットを生成する。ここで、図２８に示すように、ｎ番目のビデオＰＥＳパケットであるＶＰＫＴ（ｉ，ｎ）　からＫ（ｉ，ｎ）　個のＴＳパケットが生成される場合、それぞれのＴＳパケットをＶＴＳＰ（ｉ，ｎ，０）　，ＶＴＳＰ（ｉ，ｎ，１）　，…，ＶＴＳＰ（ｉ，ｎ，Ｋ（ｉ，ｎ）−１）と称する。
【０１４５】
このとき、ビデオＴＳパケット生成部１１０２は、それぞれのＴＳパケットに対し、理想的なＰＣＲ（Ｓｙｓｔｅｍ　Ｃｌｏｃｋ　Ｒｅｆｅｒｅｎｃｅ）を付与する。このＰＣＲの値は、ＴＳパケット中には格納されず、あくまでも後段のＴＳパケット多重化の際の多重タイミング設定の指標に用いるための情報である。ここで、ｋ番目のＴＳパケットに対応する理想的なＰＣＲをＶＰＣＲ（ｉ，ｎ，ｋ）　とする。ｋ＝０の場合、
ＶＰＣＲ（ｉ，ｎ，ｋ）　＝ＤＴＳ（ｉ，ｎ）　−ＶＤＥＬＡＹ（ｉ，ｎ）
とする。一方、０＜ｋ＜Ｋ（ｉ，ｎ）　の場合、
ＶＰＣＲ（ｉ，ｎ，ｋ）　＝ＶＰＣＲ（ｉ，ｎ，０）　＋１８４×８×ｋ×２７００００００／Ｒｍａｘ
とする。
【０１４６】
また、ビデオＴＳパケットのヘッダ中の各フィールドには次のように値を設定する。例えば、パケットを識別するためのＰＩＤ（Ｐａｃｋｅｔ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）　に０ｘ１０１１を格納し、ＴＳパケットがＰＥＳパケットの先頭バイトを含んでいた場合、ペイロード（ｐａｙｌｏａｄ　ｕｎｉｔ　ｓｔａｒｔ　ｉｎｄｉｃａｔｏｒ）に１をセットする。
【０１４７】
生成されたビデオＴＳパケットは、上記のＶＰＣＲを付与された状態でビデオＴＳパケット用バッファ１１０３に順に送られ、図２８に示すように、ビデオチャンクやビデオフレームの区別が取り去られて一次元でアクセス可能になる。すなわち、ビデオＴＳパケット総数をＶＣＯＵＮＴとすると、生成された順にＶＴＳＰ（０）　，ＶＴＳＰ（１）　，…，ＶＴＳＰ（ＶＣＯＵＮＴ−１）と呼ぶことになる。
【０１４８】
（２）オーディオＴＳパケット生成
続いて、前述のオーディオＰＥＳパケット生成部１１１１およびオーディオＴＳパケット生成部１１１２によるオーディオＴＳパケットの生成手順を図２９を用いて説明する。
【０１４９】
図２９に示すように、ＡＶストリーム中のｊ番目のオーディオチャンクに対応するオーディオデータをＡＣｈｕｎｋ（ｊ）　と称する。以下の説明では、オーディオチャンクＡＣｈｕｎｋ（ｊ）　を例に挙げる。ＡＣｈｕｎｋ（ｊ）　のトラック上での再生時刻は、オーディオデータを管理しているトラックのｓａｍｐｌｅ　ｔａｂｌｅ　ａｔｏｍ　（図７参照）を参照することで取得可能であり、ｓａｍｐｌｅ　ｔａｂｌｅ　ａｔｏｍ　を含むＭｏｖｉｅ　ａｔｏｍ（図３参照）の情報から取得することができ、それをＴｐ（ｊ）とする。
【０１５０】
オーディオＰＥＳパケット生成部１１１１は、オーディオ再生用バッファ１１１から読み出されたオーディオエレメンタリストリームにおけるオーディオチャンクＡＣｈｕｎｋ（ｊ）　をオーディオフレーム単位（オーディオフレームデータ）に分割する。分割のために必要な情報は、ＡＣｈｕｎｋ（ｊ）　を構成する各オーディオフレームのデータ長である。各オーディオフレームのデータ長は、オーディオデータを管理しているトラックのｓａｍｐｌｅ　ｓｉｚｅ　ａｔｏｍ（図９参照）を参照することで取得可能である。オーディオチャンクＡＣｈｕｎｋ（ｊ）　を構成するオーディオフレーム数がＭ（ｊ）　であるとき、それらのオーディオフレームデータをＡＦＲＭ（ｊ，０）　，ＡＦＲＭ（ｊ，１）　，…，ＡＦＲＭ（ｊ，Ｍ（ｊ）−１）と称する。また、ｍ番目のオーディオフレームのデータ長をＡＦＬＥＮ（ｊ，ｍ）とする。
【０１５１】
次に、オーディオＰＥＳパケット生成部１１１１は、オーディオフレームデータをＰＥＳパケットにパケット化する。ＰＥＳパケットＡＰＫＴ（ｊ，０）　，ＡＰＫＴ（ｊ，１）　，…，ＡＰＫＴ（ｊ，Ｍ（ｉ）−１）は、オーディオフレームデータＡＦＲＭ（ｊ，０）　，ＡＦＲＭ（ｊ，１）　，…，ＡＦＲＭ（ｊ，Ｍ（ｊ）−１）から、それぞれ一対一の対応で生成される。
【０１５２】
各ＰＥＳパケットのヘッダ部分には前述のｓｔｒｅａｍ　ｉｄやＰＴＳが設定される。このうち、ｓｔｒｅａｍ　ｉｄには１１００００００が設定される。また、ｍ番目のＰＥＳパケットのＰＴＳをＡＰＴＳ（ｊ，ｍ）　と呼び、オーディオフレーム周期を９ＫＨｚクロックでカウントした値をＴａｆとしたときＡＰＴＳ（ｊ，ｍ）　は、
ＡＰＴＳ（ｊ，ｍ）　＝Ｔｐ（ｊ）　＋ｍ×Ｔａｆ
とする。上記のＴａｆは、Ｓａｍｐｌｅ　ｔａｂｌｅから取得することが可能である。
【０１５３】
次に、オーディオＴＳパケット生成部１１１２によるＴＳパケットの生成について説明する。
【０１５４】
オーディオＴＳパケット生成部１１１２は、各ＰＥＳパケットを先頭から１８４バイト単位で所定の大きさ分割し、分割されたデータの直前にＴＳパケットのヘッダを４バイト付加することによってＴＳパケットを生成する。ここで、図２９に示すように、ｎ番目のオーディオＰＥＳパケットであるＡＰＫＴ（ｊ，ｍ）　からＨ（ｊ，ｍ）　個のＴＳパケットが生成される場合、それぞれのＴＳパケットをＡＴＳＰ（ｊ，ｍ，０）　，ＡＴＳＰ（ｊ，ｍ，１）　，…，ＡＴＳＰ（ｊ，ｍ，Ｈ（ｊ，ｍ）−１）と称する。
【０１５５】
このとき、前述のビデオＴＳパケットの生成時と同様、それぞれのＴＳパケットに対し、理想的なＰＣＲを付与する。このＰＣＲの値は、ＴＳパケット中には格納されず、あくまでも後段のＴＳパケット多重化の際の多重タイミング設定の指標に用いるための情報である。ここで、ｈ番目のＴＳパケットに対応する理想的なＰＣＲをＡＰＣＲ（ｊ，ｍ，ｈ）　とする。ｈ＝０の場合、オーディオのビットレートをＲａとしたとき、
ＡＰＣＲ（ｊ，ｍ，ｈ）　＝ＡＰＴＳ（ｊ，ｍ）　−ＡＦＬＥＮ（ｊ，ｍ）　×８×２／Ｒａ
にする。一方、０＜ｈ＜Ｈ（ｊ，ｍ）　の場合、
ＡＰＣＲ（ｊ，ｍ，ｈ）　＝ＡＰＣＲ（ｊ，ｍ，０）　＋１８４×８×ｈ×２７００００００／Ｒａ
とする。上記のＲａは、Ｓａｍｐｌｅ　ｔａｂｌｅ中のサンプルのｄｕｒａｔｉｏｎとｓｉｚｅとから求めることが可能である。
【０１５６】
また、オーディオＴＳパケットのヘッダ中の各フィールドには次のように値を設定する。例えば、ＰＩＤには、０ｘ１０２１を格納し、ＴＳパケットがＰＥＳパケットの先頭バイトを含んでいた場合、前述のペイロードに１をセットする。
【０１５７】
生成されたオーディオＴＳパケットは、上記のＡＰＣＲを付与された状態でオーディオＴＳパケット用バッファ１１１３に順に送られ、図２９に示すように、オーディオチャンクやオーディオフレームの区別が取り去さられて一次元でアクセス可能になる。すなわち、オーディオＴＳパケット総数をＡＣＯＵＮＴとすると、生成された順にＡＴＳＰ（０）　，ＡＴＳＰ（１）　，…，ＡＴＳＰ（ＡＣＯＵＮＴ−１）と呼ぶことになる。
【０１５８】
（３）ＴＳパケット多重化
上記のようにして生成されたビデオおよびオーディオのＴＳパケットからＴＳマルチプレクサ１１２１によってＴＳを生成するための手順を、図３０に示すフローチャートを用いて説明する。
【０１５９】
まず、現在の処理対象のＴＳパケットのカウンタ値ＳＴＣを初期化する（Ｓ１１０１）。初期化には、ＶＰＣＲおよびＡＰＣＲのうち最も値の小さいものを用いる。次に、ビデオＴＳパケット用バッファ１１０３に蓄えられているビデオＴＳパケットおよびオーディオＴＳパケットバッファ１１１３に蓄えられているオーディオＴＳパケットをそれぞれ指定するためのインデックスであるｖｉｎｄｅｘおよびａｉｎｄｅｘをリセットする（Ｓ１１０２）。そして、以下の処理をビデオＴＳパケット用バッファ１１０３およびオーディオＴＳパケット用バッファ１１１３が空になるまで、すなわちｖｉｎｄｅｘまたはａｉｎｄｅｘが所定値のＶＣＯＵＮＴまたはＡＣＯＵＮＴに達するまで行う（ステップＳ１１０３）。
【０１６０】
まず、ＰＣＲおよびＳＩ（Ｓｅｒｖｉｃｅ　Ｉｎｆｏｒｍａｔｉｏｎ）　やＰＳＩ（Ｐｒｏｇｒａｍ　Ｓｐｅｃｉｆｉｃ　Ｉｎｆｏｒｍａｔｉｏｎ）を挿入するタイミングをチェックし（Ｓ１１０４）、現在のＳＴＣがＰＣＲ／ＰＳＩ／ＳＩを挿入するタイミングであるか否かをチェックする（Ｓ１１０５）。ＰＣＲを挿入する間隔は、ＭＰＥＧ規格によって、０．１秒以下に規定されている。また、ＳＩ／ＰＳＩの挿入間隔についてもＡＲＩＢ（Ａｓｓｏｃｉａｔｉｏｎ　ｏｆ　Ｒａｄｉｏ　Ｉｎｄｕｓｔｒｉｅｓ　ａｎｄ　Ｂｕｉｓｉｎｅｓｓ）　ＳＴ−Ｂ２１によって規定されている。したがって、前回挿入したときのＳＣＲの値を記憶しておき、前回のＳＴＣ値と現在のＳＴＣ値の差分が０．１秒になったときが挿入するタイミングとなる。もし、挿入するタイミングであった場合、ＴＳパケットを生成しＰＣＲ／ＰＳＩ／ＳＩの挿入を行う（ステップＳ１１０６）。ＰＣＲを含むＴＳパケットの場合、ＰＣＲには現在のＳＴＣの値を設定する。
【０１６１】
Ｓ１１０５で、挿入するタイミングでなかった場合、次に、ａｉｎｄｅｘで指し示されるＡＴＳＰのＡＰＣＲの値がＳＴＣの値以上であるか否かを調べる（Ｓ１１１１）。ＡＰＣＲの値がＳＴＣの値以上であった場合、ＡＴＳＰ（ａｉｎｄｅｘ）を出力し（Ｓ１１１２）、ａｉｎｄｅｘをインクリメントする（Ｓ１１１３）。
【０１６２】
Ｓ１１１１で、ＡＰＣＲの値がＳＴＣの値未満であった場合（ＡＴＳＰを出力するタイミングでなかった場合）、ｖｉｎｄｅｘで指し示されるＶＴＳＰのＶＰＣＲの値がＳＴＣの値以上であるか否かを調べる（Ｓ１１２１）。ＶＰＣＲの値がＳＴＣの値以上であった場合、ＶＴＳＰ（ｖｉｎｄｅｘ）を出力し（Ｓ１１２２）、ｖｉｎｄｅｘをインクリメントする（Ｓ１１２３）。
【０１６３】
Ｓ１１２１で、ＶＰＣＲの値がＳＴＣの値未満であった場合（現在のＳＴＣの値が何も出力するタイミングでなかった場合）、ｎｕｌｌ　ｐａｃｋｅｔ　を出力する（Ｓ１１３１）。
【０１６４】
そして、何らかのＴＳパケットを出力したら、ＳＴＣをインクリメントする（Ｓ１１０７）。ＳＴＣのインクリメント量は、ＴＳ転送用に確保したビットレートによって決定される。ＴＳ転送用のビットレートを２７Ｍｂｐｓと設定しており、インクリメント量ΔＳＣＲは１５０４となる。
【０１６５】
＜ＰＳ変換時の処理＞
本実施形態では、ＤＶＤ−Ｖｉｄｅｏ　やＤＶＤ−Ｖｉｄｅｏ　Ｒｅｃｏｒｄｉｎｇ　規格を想定して１パックが２０４８バイトになるようにＥＳ−ＰＳ変換を行う。
【０１６６】
なお、変換対象のムービーファイルのＭｏｖｉｅ　ａｔｏｍの内容はＲＡＭ１０２に読み込まれているとする。
【０１６７】
（１）ビデオパック生成
まず、前述のビデオＰＥＳパケット生成部１１０１およびビデオパック生成部１１０４によるビデオパックの生成手順を図３１を用いて説明する。
【０１６８】
図３１に示すように、ＡＶストリーム中のｉ番目のビデオチャンクに対応するビデオデータをＶＣｈｕｎｋ（ｉ）　と称する。以下の説明では、ビデオチャンクＶＣｈｕｎｋ（ｉ）を例に挙げる。ＶＣｈｕｎｋ（ｉ）　のトラック上での再生時刻はＭｏｖｉｅ　ａｔｏｍの情報から取得することができ、それをＴｖ（ｉ）　とする。
【０１６９】
ビデオＰＥＳパケット生成部１１０１は、前述のビデオＴＳパケット生成の場合と同様にビデオチャンクＶＣｈｕｎｋ（ｉ）　をビデオフレーム単位に分割する。このときの手順はＴＳ生成処理と同一であるため、説明を省略する。また、ビデオＰＥＳパケット生成部１１０１は、ビデオフレームデータをＰＥＳパケットにパケット化する。ＰＥＳパケットは、ビデオフレームデータＶＦＲＭ（ｉ，０）　，ＶＦＲＭ（ｉ，１）　，…，ＶＦＲＭ（ｉ，Ｎ（ｉ）−１）から、それぞれ複数生成される。
【０１７０】
ここでは、ｎ番目のビデオフレームデータを例に挙げて説明する。ＶＦＲＭ（ｉ，ｎ）の先頭から、２０３４バイト単位でデータを切り出し、パケットに格納する。ただし、先頭だけはＰＴＳおよびＤＴＳを格納する空間が必要であるために２０１９バイトでデータを切り出す。さらに、ＶＦＲＭ（ｉ，０）　の先頭については、２４バイトのシステムヘッダ（Ｓｙｓｔｅｍ　Ｈｅａｄｅｒ）　を挿入する必要があるため、さらに短い１９９５バイトでデータ切り出す。生成されたパケット数がＧ（ｉ，ｎ）個であるとき、ＰＥＳパケットとしてＶＰＫＴ（ｉ，ｎ，０）　，ＶＰＫＴ（ｉ，ｎ，１）　，…，ＶＰＫＴ（ｉ，ｎ，Ｇ（ｉ，ｎ）−１）が生成される。このうち、先頭のパケットとしてのＶＰＫＴ（ｉ，ｎ，０）　には、ＰＴＳおよびＤＴＳを設定する必要があり、設定する値については、前述のＴＳ変換の場合について説明したルールで計算する。
【０１７１】
次に、ビデオパック生成部１１０４によるビデオパックの生成について説明する。
【０１７２】
ビデオパック生成部１１０４は、所定数のＰＥＳパケットを１４バイトのパックヘッダの後に格納してグループ化し、ＶＣｈｕｎｋ（ｉ）　の先頭のＶＰＫＴ（ｉ，０，０）　の場合、パックヘッダとＰＥＳパケット群との間に前記のシステムヘッダを挿入する。ここで、ｇ番目のビデオＰＥＳパケットＶＰＫＴ（ｉ，ｎ，ｇ）　に対応するビデオパックをＶＰＣＫ（ｉ，ｎ，ｇ）　と称する。
【０１７３】
このとき、ビデオパック生成部１１０４は、それぞれのパックのパックヘッダに対し、以下のような計算で求めたＳＣＲを格納する。このＳＣＲの値は、ＰＳ多重化の際に実際の値に書き換えられる。ここで、ｇ番目のパックに対応する、計算上のＳＣＲをＶＰＣＲ（ｉ，ｎ，ｇ）　とする。ｋ＝０の場合、
ＶＳＣＲ（ｉ，ｎ，ｇ）　＝ＤＴＳ（ｉ，ｎ）　−ＶＤＥＬＡＹ（ｉ，ｎ）
とする。一方、０＜ｇ＜Ｇ（ｉ，ｎ）　の場合、
ＶＳＣＲ（ｉ，ｎ，ｇ）　＝ＶＰＣＲ（ｉ，ｎ，０）　＋２０４８×８×ｋ×２７００００００／Ｒｍａｘ
とする。また、パックヘッダ中の、多重化ビットレートを示すフィールドｐｒｏｇｒａｍ　ｍｕｘ　ｒａｔｅには、１００８Ｍｂｐｓを示す０ｘ０１８９ｃ３を格納する。
【０１７４】
生成されたビデオパックは、上記のＶＳＣＲを付与された状態でビデオパック用バッファ１１０５に順に送られ、図３１に示すように、ビデオチャンクやビデオフレームの区別が取り去さられて一次元でアクセス可能になる。すなわち、ビデオパック総数をＶＣＯＵＮＴとすると、生成された順にＶＰＣＫ（０）　，ＶＰＣＫ（１）　，…，ＶＰＣＫ（ＶＣＯＵＮＴ−１）と呼ぶことになる。
【０１７５】
（２）オーディオパック生成
続いて、前述のオーディオＰＥＳパケット生成部１１１１およびオーディオパック生成部１１１４によるオーディオパックの生成手順を図３２を用いて説明する。
【０１７６】
図３２に示すように、ＡＶストリーム中のｊ番目のオーディオチャンクに対応するオーディオデータをＡＣｈｕｎｋ（ｊ）　と称する。以下の説明では、オーディオチャンクＡＣｈｕｎｋ（ｊ）　を例に挙げる。ＡＣｈｕｎｋ（ｊ）　のトラック上での再生時刻はＭｏｖｉｅ　ａｔｏｍの情報から取得することができ、それをＴｐ（ｊ）　とする。
【０１７７】
オーディオＰＳパケット生成部１１１１は、前述のオーディオＴＳパケット生成の場合と同様に、オーディオチャンクＡＣｈｕｎｋ（ｊ）　をオーディオフレーム単位に分割する。このときの手順は、ＴＳ生成処理の場合と同一であるため、その説明を省略する。また、オーディオＰＳパケット生成部１１１１は、オーディオフレームデータをＰＥＳパケットにパケット化する。ＰＥＳパケットは、オーディオフレームデータＡＦＲＭ（ｊ，０）　，ＡＦＲＭ（ｊ，１）　，…，ＶＦＲＭ（ｊ，Ｍ（ｉ）−１）からそれぞれ複数生成される。
【０１７８】
ここでは、ｍ番目のオーディオフレームデータを例に挙げて説明する。ＡＦＲＭ（ｊ，ｍ）の先頭から、２０２５バイト単位でデータを切り出し、パケットに格納する。ただし、先頭だけはＰＴＳを格納する空間が必要であるために２０２０バイトでデータを切り出す。生成されたパケット数がＨ（ｊ，ｍ）　個であるとき、ＰＥＳパケットとしてＡＰＫＴ（ｊ，ｍ，０）　，ＡＰＫＴ（ｊ，ｍ，１）　，…，ＡＰＫＴ（ｊ，ｍ，Ｈ（ｊ，ｍ）−１）が生成される。このうち、先頭のパケットであるＡＰＫＴ（ｉ，ｎ，０）　には、ＰＴＳを設定する必要があり、設定する値については、前述のＴＳ変換の場合について説明したルールで計算する。
【０１７９】
次に、オーディオパック生成部１１１４によるオーディオパックの生成について説明する。
【０１８０】
オーディオパック生成部１１１４は、所定数のＰＥＳパケットを１４バイトのパックヘッダの後に格納してグループ化する。ここで、ｇ番目のオーディオＰＥＳパケットＡＰＫＴ（ｊ，ｍ，ｈ）　に対応するオーディオパックをＡＰＣＫ（ｊ，ｍ，ｈ）　と称する。
【０１８１】
このとき、オーディオパック生成部１１１４は、それぞれのパックのパックヘッダに対し、以下のような計算で求めたＳＣＲを格納する。このＳＣＲの値は、ＰＳ多重化の際に実際の値に書き換えられる。ここで、ｈ番目のパックに対応する、計算上のＳＣＲをＡＰＣＲ（ｊ，ｍ，ｈ）　とする。ｈ＝０の場合、
ＡＳＣＲ（ｊ，ｍ，ｈ）　＝ＡＰＴＳ（ｊ，ｍ）　−ＡＦＬＥＮ（ｊ，ｍ）　×８×２／Ｒａ
にする。一方、０＜ｈ＜Ｈ（ｊ，ｍ）　の場合、
ＡＳＣＲ（ｊ，ｍ，ｈ）　＝ＡＳＣＲ（ｊ，ｍ，０）　＋２０４８×８×ｈ×２７００００００／Ｒａ
とする。また、パックヘッダ中の、多重化ビットレートを示すフィールドｐｒｏｇｒａｍ　ｍｕｘ　ｒａｔｅには、１００８Ｍｂｐｓを示す０ｘ０１８９ｃ３を格納する。
【０１８２】
生成されたオーディオパックは、上記のＡＳＣＲを付与された状態でオーディオパック用バッファ１１１５に順に送られ、図３２に示すように、オーディオチャンクやオーディオフレームの区別が取り去られて一次元でアクセス可能になる。すなわち、オーディオパック総数をＡＣＯＵＮＴとしたとき、生成された順にＡＰＣＫ（０）　，ＡＣＰＫ（１）　，…，ＡＣＰＫ（ＡＣＯＵＮＴ−１）と呼ぶことになる。
【０１８３】
（３）パック多重化
以上のようにして生成されたビデオおよびオーディオのパックからＰＳマルチプレクサ１１２２によってＰＳを生成するための手順を、図３３に示すフローチャートを用いて説明する。
【０１８４】
まず、現在のカウンタ値ＳＴＣを初期化する（Ｓ１２０１）。初期化には、ＶＳＣＲおよびＡＳＣＲのうち最も値の小さいものを用いる。次に、ビデオパック用バッファ１１０５に蓄えられているビデオパックおよびオーディオパック用バッファ１１１５に蓄えられているオーディオパックをそれぞれ指定するためのインデックスであるｖｉｎｄｅｘおよびａｉｎｄｅｘをリセットする（Ｓ１２０２）。そして、以下の処理をビデオパック用バッファ１１０５およびオーディオパック用バッファ１１１５が空になるまで、すなわちｖｉｎｄｅｘまたはａｉｎｄｅｘが所定値のＶＣＯＵＮＴまたはＡＣＯＵＮＴに達するまで行う（Ｓ１２０３）。
【０１８５】
まず、ａｉｎｄｅｘで指し示されるオーディオパックＡＰＣＫのＡＳＣＲの値がＳＴＣの値以上であるか否かを調べる（Ｓ１２０４）。ＡＳＣＲの値がＳＴＣの値以上であった場合、ＡＰＣＫ（ａｉｎｄｅｘ）を出力し（Ｓ１２０５）、ａｉｎｄｅｘをインクリメントする（Ｓ１２０６）。
【０１８６】
Ｓ１２０４で、ＡＰＣＫを出力するタイミングでなかった場合、ｖｉｎｄｅｘで指し示されるＶＰＣＫのＶＳＣＲの値がＳＴＣの値以上であるか否かを調べる（Ｓ１２１１）。ＶＳＣＲの値がＳＴＣの値以上であった場合、ＶＴＳＰ（ｖｉｎｄｅｘ）を出力し（Ｓ１２１２）、ｖｉｎｄｅｘをインクリメントする（Ｓ１２１３）。
【０１８７】
なお、各パックの出力の際には、パックヘッダのＳＣＲの値を現在のＳＴＣの値に書き換える。
【０１８８】
次に、現在のＳＴＣに該当するパックの有無にかかわらず、ＳＴＣをインクリメントする（Ｓ１２０７）。ＳＴＣのインクリメント量は、転送ビットレートによって決定される。ここでは、ＤＶＤ−Ｖｉｄｅｏ　を対象にしているため、転送用ビットレートを１００８Ｍｂｐｓと設定しており、インクリメント量ΔＳＣＲは４３８７５となる。
【０１８９】
〔第２の実施形態〕
本発明の第２の実施形態について、図３４ないし図３６を用いて説明する。
【０１９０】
本実施形態は、ＴＳ／ＰＳ変換のために必要な情報をビデオデータを解析する必要がないように、ビデオデータ外にそれらの情報をあらかじめ記録しておく点が第１の実施形態と異なっている。本実施形態は、第１の実施形態と共通する部分が多いため、主に相違点について説明する。
【０１９１】
＜システム構成＞
図３４に示すように、本実施形態におけるビデオディスクレコーダのシステム構成は、第１の実施形態のシステム構成と、ビデオ解析部１１３１を備えていないことを除いてほぼ同一である。その他の構成要素は、第１の実施形態の構成要素と同じであり、同じ構成要素については共通の符号を用いている。
【０１９２】
＜ＡＶストリームの形態＞
図３５は、本実施形態におけるＡＶストリーム構成を示している。基本的には、第１の実施形態のＡＶストリーム構成（図２５参照）と同一であるが、ＶＵ７０３におけるオーディオデータとビデオデータとの間にＶＦＩ（Ｖｉｄｅｏ　Ｆｒａｍｅ　Ｉｎｆｏｒｍａｔｉｏｎ）　７０９というデータ領域が設けられている点で異なる。
【０１９３】
ＶＦＩ７０９については、図３６を用いて説明する。ＶＦＩ７０９には、この情報が含まれるＶＵ７０３の各ビデオフレームに関する情報が格納されている。ＶＦＩ７０９中のＮｕｍｂｅｒ　ｏｆ　ｆｒａｍｅｓは、ＶＵ７０３中のビデオフレーム数を示す。１ＧＯＰを１サンプルで管理した場合、Ｍｏｖｉｅ　ａｔｏｍ中の情報から、ＶＵ７０３中の正確なビデオフレーム数が得られる保証はないため、この情報が必要である。また、ｆｓｉｚｅ［ｉ］にはＶＵ７０３中のｉ番目のビデオフレームデータに対応するデータサイズが、ｆｔｙｐｅ［ｉ］にはピクチャタイプが、ｖｄｅｌａｙ［ｉ］にはｖｂｖ＿ｄｅｌａｙがそれぞれ格納されている。また、ビデオデータのビットレートはｂｉｔｒａｔｅ　に格納されている。このような管理情報をビデオデータ外に設けることで、ＴＳ／ＰＳ変換時にビデオデータを解析する必要がなくなる。これにより、第１の実施形態におけるビデオ解析部１１３１が不要となるので、システム構成が簡略化される。
【０１９４】
ＶＦＩ７０３は、オーディオデータとビデオデータとの間に挿入されている。これにより、ＡＶストリームデータの部分的な移動や削除の際、ＶＦＩ７０９のみが取り残される可能性が低くなる。また、直前のオーディオデータおよび直後のビデオデータの位置はＳａｍｐｌｅ　ｔａｂｌｅから分かるため、ＶＦＩ７０９の記録位置を管理するために、ムービーファイル中に管理情報を新規に追加する必要がなくなる。また、ＶＦＩ７０９は、対応するビデオデータの直前に読み出されるので、対応するビデオデータが読み出されたら、直ちにＴＳへの変換のための処理を開始することが可能である。
【０１９５】
なお、本実施形態では、ビデオデータおよびＶＦＩ７０９は同一ファイルに格納されているが、本発明はそれに限定されるものではない。例えば、ビデオデータおよびＶＦＩ７０９が別ファイルであったとしても、ＶＦＩ７０９がビデオデータよりも先に読み出されるように配置されていれば同様の効果を達成できる。
【０１９６】
また、これらの情報をＭｏｖｉｅ　ａｔｏｍではなくＡＶストリーム７０１内に記録することによって、通常再生の際にＭｏｖｉｅ　ａｔｏｍをＲＡＭ１０２に保持するために必要なメモリ量を増大させることがない。
【０１９７】
また、ここでは、ＶＦＩ７０９中にピクチャタイプを記録しているが、ビデオデータのエンコードに際して両方向予測符号化を行わない場合には、ピクチャタイプは不要である。また、両方向予測符号化を行ったとしても、記録すべき情報はピクチャタイプに限定されない。例えば、フレーム間の表示順のようにピクチャタイプを導くことのできる情報であれば何でもよい。
【０１９８】
＜記録処理＞
本実施形態における記録処理は第１の実施形態の録画時の処理と同様であるが、ＡＣ（オーディオチャンク）７０８とＶＣ（ビデオチャンク）７０９との間にＶＦＩ７０９を挿入された状態で記録を行う点が異なる。また、第１の実施形態と異なり、ＶＢＲの場合でも、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）中のｖｂｖ＿ｄｅｌａｙに０ｘｆｆｆｆをセットしてもよい。なぜなら、ｖｂｖ＿ｄｅｌａｙに想到する情報は、前述のＶＦＩ７０９に格納されているからである。
【０１９９】
＜ＴＳ変換時の処理＞
本実施形態におけるＴＳ変換時の処理は第１の実施形態と類似するため、主に相違点を説明する。
【０２００】
（１）ビデオＴＳパケット生成
まず、ＶＣｈｕｎｋ（ｉ）　の読み出し前に直前のＶＦＩ７０９が読み出されてＲＡＭ１０２に格納されているとする。
【０２０１】
ＶＣｈｕｎｋ（ｉ）　をビデオフレームデータに分解する際には、ＶＦＩ７０９におけるｆｓｉｚｅを利用する。また、各ビデオフレームデータのピクチャタイプは、ＶＦＩ７０９におけるｆｔｙｐｅから直接取得することが可能である。また、ＶＤＥＬＡＹについてもＶＦＩ７０９におけるｖｄｅｌａｙから直接取得することが可能である。またＲｘについてもＶＦＩ７０９におけるｂｉｔｒａｔｅから直接取得することが可能である。このことは、ＶＦＩ７０９をビデオデータとは別にまとめて用意しておくことで、ビデオ解析部１１３１によりビデオデータを解析する必要がなくなったことを意味する。
【０２０２】
なお、「（２）オーディオＴＳパケット生成」および「（３）ＴＳパケット多重化」の処理は第１の実施形態での録画時の処理と同様であるため、その説明を省略する。
【０２０３】
＜ＰＳ変換時の処理＞
ビデオＴＳパケット生成と同様、ＶＦＩ７０９内の情報を用いることで、本処理に必要な各フレームのデータ量、ピクチャタイプおよびｖｂｖ＿ｄｅｌａｙの値を取得可能である。
【０２０４】
＜バリエーション＞
本実施形態では、ｖｂｖ＿ｄｅｌａｙに相当する値をＡＶストリーム７０１におけるＧＯＰ７０３外に記録しているが、Ｍｏｖｉｅ　ａｔｏｍ中の例えばＵｓｅｒ　ｄａｔａ　ａｔｏｍに記録したとしても、同様の効果が得られる。また、フレーム毎のデータ量やピクチャタイプに関する情報についても同様である。また、ＶＦＩ７０９におけるｂｉｔｒａｔｅは、固定ビットレートの場合はｓａｍｐｌｅ　ｔａｂｌｅから算出できるため特に記録する必要はない。また、記録する場合もＭｏｖｉｅ　ａｔｏｍ中に記録しても同様の効果が得られることは言うまでもない。
【０２０５】
〔第３の実施形態〕
＜システム構成＞
本実施形態におけるシステム構成は第２の実施形態と共通であるため、その説明を省略する。
【０２０６】
＜ＡＶストリーム管理方法＞
上記のＡＶストリームの管理情報の構成について説明する。ＡＶストリームは、図３７に示すように、ムービーファイル２４０１と、ムービーファイル２４０２とで管理される。
【０２０７】
ムービーファイル２４０１は、Ｍｏｖｉｅ　ｄａｔａ　ａｔｏｍに格納された前述のＡＶストリーム７０１（図２３参照）と、ＡＶストリーム７０１を構成するサンプルのアドレスやサイズ、再生時間等を管理するＭｏｖｉｅ　ａｔｏｍとで構成される。ＡＶストリーム７０１は、前述のように、ＣＵ７０２で構成され、各ＣＵ７０２は必ず光ディスク１０６上で連続的に配置されるように記録される。
【０２０８】
一方、ムービーファイル２４０２は、ムービーファイル２４０１における各ＣＵ７０２を管理するｍｏｏｆ（Ｍｏｖｉｅ　ｆｒａｇｍｅｎｔ　ａｔｏｍ）　７１０で構成される。
【０２０９】
この２つのファイル２４０１，２４０２は、図３７に示すように、ＣＵ７０２単位で多重化されて、光ディスク１０６上に連続して記録される。ムービーファイル２４０１では１個のＧＯＰ７０４を１サンプルと扱っているのに対し、ムービーファイル２４０２ではビデオフレームを１サンプルとして扱う。そのため、ムービーファイル２４０１の管理情報に比べ、ムービーファイル２４０２の管理情報量は多くなる。
【０２１０】
また、ビデオフレーム間のフレーム順の入れ替わりを管理するため、前述のｓａｍｐｌｅ−ｃｏｍｐｏｓｉｔｉｏｎ−ｔｉｍｅ−ｏｆｆｓｅｔを用いる。すなわち、ｓａｍｐｌｅ−ｄｕｒａｔｉｏｎとｓａｍｐｌｅ−ｃｏｍｐｏｓｉｔｉｏｎ−ｔｉｍｅ−ｏｆｆｓｅｔから、各サンプルのデコードタイミングと表示タイミングが分かる。このことは、各サンプル（ビデオフレーム）のピクチャータイプが分かることを意味する。
【０２１１】
また、ビデオトラックを管理するＴｒａｃｋ　ｆｒａｇｍｅｎｔ　ａｔｏｍに前記のｖｂｖ＿ｄｅｌａｙを管理するために、独自管理情報であるＶＢＶ　ｄｅｌａｙ　ａｔｏｍを追加定義する。図３８にＶＢＶ　ｄｅｌａｙ　ａｔｏｍの構成を示すように、Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ａｔｏｍで管理されるビデオフレームのｖｂｖ＿ｄｅｌａｙの値を順に格納したものである。なお、このａｔｏｍは一般のプレーヤでは無視されることになる。
【０２１２】
このように、管理情報をサイズ（大きさ）が異なるサンプルについて２個用意することによって、専用プレーヤで再生するときには、必要なメモリ容量の少ないムービーファイル２４０１を用い、汎用のＱｕｉｃｋＴｉｍｅ　（あるいはＩＳＯ　ｂａｓｅ　ｍｅｄｉａ　ｆｉｌｅ　ｆｏｒｍａｔ）対応プレーヤで再生するときには、ムービーファイル２４０２を用いることで、省メモリと再生互換性とを両立することが可能となる。
【０２１３】
＜記録時の処理＞
本実施形態における記録時の処理は第１の実施形態での録画時の処理と共通しているが、Ｍｏｖｉｅ　ｆｒａｇｍｅｎｔをＣｏｎｔｉｎｕｏｕｓ　Ｕｎｉｔ毎に記録する点が異なる。また、第１の実施形態と異なり、ＶＢＲの場合でも、ｐｉｃｔｕｒｅ＿ｈｅａｄｅｒ（）中のｖｂｖ＿ｄｅｌａｙに０ｘｆｆｆｆをセットしてもよい。なぜなら、ｖｂｖ＿ｄｅｌａｙに想到する情報は、前述のＶＢＶ　ｄｅｌａｙ　ａｔｏｍに格納されているからである。
【０２１４】
＜ＴＳ変換時の処理＞
（１）ビデオＴＳパケット生成
まず、ＶＣｈｕｎｋ（ｉ）　の読み出し前に、ＶＣｈｕｎｋ（ｉ）　に対応するＭｏｖｉｅ　ｆｒａｇｍｅｎｔ　ａｔｏｍ　７１０は読み出されてＲＡＭ１０２に格納されているとする。
【０２１５】
本実施形態でＶＣｈｕｎｋ（ｉ）　をビデオフレームデータに分解する際には、Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ｒｕｎ　ａｔｏｍ中のｓａｍｐｌｅ−ｓｉｚｅから取得した各ビデオフレームデータのデータ量を用いる。また、各ビデオフレームデータのピクチャタイプは次のように取得できる。
【０２１６】
まず、Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ｒｕｎ　ａｔｏｍ　中のｓａｍｐｌｅ−ｃｏｍｐｏｓｉｔｉｏｎ−ｔｉｍｅ−ｏｆｆｓｅｔ　が０のものはＢピクチャと判断できるが、０でなかった場合、Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ｒｕｎ　ａｔｏｍ　中のｓａｍｐｌｅ　ｆｌａｇ　を見る。ｓａｍｐｌｅ　ｆｌａｇ　中には、対応するサンプル画、キーフレームであるか否かのフラグがあり、そのフラグが１の場合はＩピクチャと判断でき、そうでない場合はＰピクチャと判断できる。また、ＶＤＥＬＡＹについては、Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ａｔｏｍ　中のＶＢＶ　ｄｅｌａｙ　ａｔｏｍの値から直接取得可能である。つまり、第２実施形態と同様、ビデオ解析部１１３１によりビデオデータを解析する必要が無い。以下の「（２）オーディオＴＳパケット生成処理」および「（３）ＴＳパケット多重化」の処理は第１の実施形態での処理と同様であるため、その説明を省略する。
【０２１７】
＜ＰＳ変換時の処理＞
ＰＳ変換時の処理は第１の実施形態の処理とほぼ同様であるため、主に異なる点について説明する。
【０２１８】
（１）ビデオパック生成
ビデオＴＳパケット生成と同様、Ｔｒａｃｋ　ｆｒａｇｍｅｎｔ　ａｔｏｍ中の情報を用いることで、本処理に必要な各フレームのデータ量、ピクチャタイプおよびＶＢＶ　ｄｅｌａｙの値を取得可能である。
【０２１９】
（２）オーディオパック生成
第１の実施形態と同様であるため省略する。
【０２２０】
（３）パック多重化
第１の実施形態と同様であるため省略する。
【０２２１】
＜バリエーション＞
本実施形態では、ｖｂｖ＿ｄｅｌａｙに相当する値をＶＢＶ　ｄｅｌａｙ　ａｔｏｍとして管理情報に記録しているが、この記録は必須ではない。なぜなら、各ビデオフレームのピクチャタイプおよびデータ量を元に、ＶＢＶバッファの占有量をシミュレートすることで、ＭＰＥＧ規格に準拠したＴＳ／ＰＳを生成できるからである。ただし、その場合、シミュレーションに伴う処理の複雑化が生じる。
【０２２２】
なお、以上に述べた各実施形態では、光ディスク１０６にＡＶストリームを記録することについて説明してきたが、ＡＶストリームを記録する記録媒体としては、光ディスクに限らず、ランダムアクセス可能な記録媒体であれば、例えばハードディスクや半導体メモリであってもよい。
【０２２３】
〔他の実施形態〕
本発明の実施形態の記録方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含むＡＶストリームと、ＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報（Ｍｏｖｉｅ　ａｔｏｍ　等）を記録媒体に記録する記録方法であって、ＡＶストリーム中に、個々の前記第１のユニットに関する第２の管理情報を記録し、第２の管理情報（Ｖｉｄｅｏ　Ｆｒａｍｅ　Ｉｎｆｏｒｍａｔｉｏｎ）は、対応する第１のユニットを構成するＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２２４】
また、前記記録方法では、第２の管理情報のデータフォーマットにＩＳＯ　ｂａｓｅ　ｍｅｄｉａ　ｆｉｌｅ　ｆｏｒｍａｔにおけるＭｏｖｉｅ　Ｆｒａｇｍｅｎｔ（Ｍｏｖｉｅ　Ｆｒａｇｍｅｎｔ　ａｔｏｍ）を用いることが好ましい。
【０２２５】
また、他の記録方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含むＡＶストリームと、ＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録する記録方法であって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記記録媒体に記録する。
【０２２６】
また、前記遅延時間はＡＶストリーム中に記録されることが好ましい。
【０２２７】
また、さらに他の記録方法は、ＡＶストリーム中に、個々の第１のユニットに関して第２の管理情報を記録し、第２の管理情報は、対応する第１のユニットを構成するＧＯＰを構成するビデオフレームデータ毎のデータ量および前記遅延時間を持つ。
【０２２８】
前記第２の管理情報は、対応する前記第１のユニットの物理的な近傍に配置されることが好ましい。
【０２２９】
前記各記録方法では、第２の管理情報と前記第１のＡＶストリームとを同一ファイルで管理し、前記第２の管理情報を対応するＧＯＰよりも低いアドレスに置くことが好ましい。
【０２３０】
前記記録方法では、前記遅延時間は少なくとも前記ＧＯＰ外に記録し、第１の管理情報は、ＧＯＰを構成するビデオフレームデータ毎のデータ量および遅延時間情報を持つことが好ましい。
【０２３１】
前記第１の管理情報は、ビデオフレーム間のピクチャタイプに関する情報を持つことが好ましい。前記第１の管理情報は、ＧＯＰを構成するビデオフレームデータ毎のデータ量および前記ビデオフレーム間のピクチャタイプに関する情報および前記遅延時間を持つことが好ましい。前記第２の管理情報は、ビデオフレーム間のピクチャタイプに関する情報を持つことが好ましい。
【０２３２】
本発明の実施形態のＡＶストリーム変換方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持記録媒体に関して、前記第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換方法であって、変換の際に、前記データ量に関する情報を用いる。
【０２３３】
また、他のＡＶストリーム変換方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、前記第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換方法であって、変換の際に、前記遅延時間を用いる。
【０２３４】
また、さらに他のＡＶストリーム変換方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とデータ量が記録されている記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換方法であって、変換の際に、前記遅延時間および前記データ量を用いる。
【０２３５】
また、さらに他のＡＶストリーム変換方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とデータ量とピクチャタイプに関する情報が記録されている記録媒体に関して、前記第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換方法であって、変換の際に、遅延時間および前記データ量およびピクチャタイプに関する情報を用いる。
【０２３６】
本願の実施形態の記録装置は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に前記第１のユニットに関する第１の管理情報を記録媒体に記録する記録装置であって、ＡＶストリーム中に、個々の前記第１のユニットに関する第２の管理情報を記録する手段を備え、第２の管理情報は、対応する第１のユニットを構成する前記ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２３７】
また、他の記録装置は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録する記録装置であって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記記録媒体に記録する手段を備える。
【０２３８】
本発明の実施形態のＡＶストリーム変換装置は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換装置であって、前記データ量に関する情報を用いる変換手段を備える。
【０２３９】
他のＡＶストリーム変換装置は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換装置であって、遅延時間を用いて変換する。
【０２４０】
本発明の実施形態の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録した記録媒体であって、ＡＶストリーム中に、個々の前記第１のユニットに関する第２の管理情報を記録し、第２の管理情報は、対応する第１のユニットを構成する前記ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２４１】
他の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報した記録媒体であって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を記録してある。
【０２４２】
本発明の実施形態のコンピュータプログラムは、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に前記第１のユニットに関する第１の管理情報を記録媒体に記録するステップを有するコンピュータプログラムであって、ＡＶストリーム中に、個々の第１のユニットに関する第２の管理情報を記録するステップを有し、第２の管理情報は、対応する第１のユニットを構成するＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２４３】
また、他のコンピュータプログラムは、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録するステップを有するコンピュータプログラムであって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記記録媒体に記録するステップを有する。
【０２４４】
また、さらに他のコンピュータプログラムは、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するステップを有するコンピュータプログラムであって、変換ステップが、前記データ量に関する情報を用いる。
【０２４５】
また、さらに他のコンピュータプログラムは、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するステップを有するコンピュータプログラムであって、変換ステップが遅延時間を用いる。
【０２４６】
本発明の実施形態の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、ＡＶストリーム中に、個々の第１のユニットに関する第２の管理情報を記録するステップを有し、第２の管理情報は、対応する第１のユニットを構成する前記ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２４７】
また、他の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を記録媒体に記録するステップを有する。
【０２４８】
また、さらに他の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、変換ステップがデータ量に関する情報を用いる。
【０２４９】
また、さらに他の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、変換ステップが遅延時間を用いる。
【０２５０】
また、データ変換装置およびデータ変換方法は、ビデオエレメンタリストリームにおけるデータ管理の最小単位である第１ビデオデータ単位の複数からなる第２ビデオデータ単位をビデオフレームデータに分割し、該ビデオフレームデータをパケット化して第１パケットを生成する第１パケット生成手段（処理）と、前記第１パケットを所定の大きさに分割して第１分割パケットを生成する第１分割パケット生成手段（処理）と、オーディオエレメンタリストリームにおけるデータ管理の最小単位である第１オーディオデータ単位の複数からなる第２オーディオデータ単位をオーディオフレームデータに分割し、該オーディオフレームデータをパケット化して第２パケットを生成する第２パケット生成手段（処理）と、前記第２パケットを所定の大きさに分割して第２分割パケットを生成する第２分割パケット生成手段（処理）と、前記第１および第２分割パケットを多重化して多重化ストリームを生成する多重化手段（処理）とを備えている。
【０２５１】
上記の構成では、第１パケット生成手段（処理）によって、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのビデオエレメンタリストリームが第２ビデオデータ単位のビデオフレームデータに分割され、このビデオフレームデータを基に第１パケットが生成される。例えば、データ管理の最小単位である第１ビデオデータ単位はサンプルであり、第２ビデオデータ単位はチャンクである。そして、第１分割パケット生成手段（処理）によって、上記の第１パケットがさらに分割されて第１分割パケットが生成される。
【０２５２】
また、第２パケット生成手段（処理）によって、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのオーディオエレメンタリストリームが第２オーディオデータ単位のオーディオフレームデータに分割され、このオーディオフレームデータを基に第２パケットが生成される。例えば、データ管理の最小単位である第１オーディオデータ単位はサンプルであり、第２オーディオデータ単位はチャンクである。そして、第２分割パケット生成手段（処理）によって、上記の第２パケットがさらに分割されて第２分割パケットが生成される。
【０２５３】
上記のようにして生成された第１および第２分割パケットは、多重化手段によって多重化され、その結果、ＭＰＥＧ２−ＴＳストリームとしての多重化ストリームが生成される。
【０２５４】
このように、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのビデオエレメンタリストリームおよびオーディオエレメンタリストリームからＭＰＥＧ２−ＴＳストリームが得られる。それゆえ、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのＡＶ（Ａｕｄｉｏ　ａｎｄ　Ｖｉｓｕａｌ）ストリームをＭＰＥＧ２−ＴＳのファイルフォーマットを採用する機器（ＩＥＥＥ−１３９４等）に転送することができる。
【０２５５】
他のデータ変換装置およびデータ変換方法は、ビデオエレメンタリストリームにおけるデータ管理の最小単位である第１ビデオデータ単位の複数からなる第２ビデオデータ単位をビデオフレームデータに分割し、該ビデオフレームデータをパケット化して第１パケットを生成する第１パケット生成手段（処理）と、複数の前記第１パケットをグループ化して第１パケット群を生成する第１パケット群生成手段（処理）と、オーディオエレメンタリストリームにおけるデータ管理の最小単位である第１オーディオデータ単位の複数からなる第２オーディオデータ単位をオーディオフレームデータに分割し、該オーディオフレームデータをパケット化して第２パケットを生成する第２パケット生成手段（処理）と、複数の前記第２パケットをグループ化して第２パケット群を生成する第２分割パケット群生成手段（処理）と、前記第１および第２パケット群を多重化して多重化ストリームを生成する多重化手段（処理）とを備えている。
【０２５６】
上記の構成では、第１パケット生成手段（処理）によって、前述のように、第１パケットが生成される。そして、第１パケット群生成手段（処理）によって、複数の第１パケットがグループ化されて第１パケット群が生成される。
【０２５７】
また、第２パケット生成手段（処理）によって、前述のように、第２パケットが生成される。そして、第２パケット群生成手段（処理）によって、複数の第２パケットがグループ化されて第２パケット群が生成される。
【０２５８】
上記のようにして生成された第１および第２パケット群は、多重化手段によって多重化され、その結果、ＭＰＥＧ２−ＰＳストリームとしての多重化ストリームが生成される。
【０２５９】
このように、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのビデオエレメンタリストリームおよびオーディオエレメンタリストリームからＭＰＥＧ２−ＰＳストリームが得られる。それゆえ、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットのＡＶ（Ａｕｄｉｏ　ａｎｄ　Ｖｉｓｕａｌ）ストリームをＭＰＥＧ２−ＰＳのファイルフォーマットを採用する機器（ＤＶＤプレーヤ等）に転送することができる。
【０２６０】
前記の発明は、前記ビデオエレメンタリストリームと前記オーディオエレメンタリストリームとが多重化されてなるエレメンタリストリームを前記ビデオエレメンタリストリームと前記オーディオエレメンタリストリームとに分離してそれぞれを前記第１パケット生成手段（処理）と前記第２パケット生成手段（処理）とに与える分離手段（処理）を備え、前記エレメンタリストリームが、該エレメンタリストリームの格納されるファイルとは別のファイルに格納され、前記エレメンタリストリームの前記ビデオフレームデータに関する管理情報が付加され、前記第１パケット生成手段（処理）が、前記ビデオエレメンタリストリームに付随して分離された前記管理情報に基づいて第２ビデオデータ単位をビデオフレームデータに分割することが好ましい。
【０２６１】
上記の構成では、第１および第２パケット生成手段（処理）にそれぞれ与えられるビデオエレメンタリストリームおよびオーディオエレメンタリストリームは、分離手段（処理）によって、エレメンタリストリームから分離される。このエレメンタリストリームは、それが格納されるファイルとは別のファイルに格納され、エレメンタリストリームのビデオフレームデータに関する管理情報が付加されている。この管理情報としては、ビデオフレームデータ毎のデータ量、ビデオフレームデータのデコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間、ビデオフレームのピクチャタイプ等に関する情報が含まれる。
【０２６２】
これにより、第１パケット生成手段（処理）は、その管理情報に基づいて、ビデオエレメンタリストリームをビデオフレームデータに分割する。それゆえ、ビデオフレームデータの分割のためにエレメンタリストリームを解析してビデオフレームデータの分割位置を検出するための手段や処理が必要ない。
【０２６３】
あるいは、前記の発明は、前記分離手段（処理）を備え、前記エレメンタリストリームに、所定の間隔毎に前記ビデオフレームデータに関する管理情報が付加され、前記第１パケット生成手段が、前記ビデオエレメンタリストリームに付随して分離された前記管理情報に基づいて第２ビデオデータ単位をビデオフレームデータに分割することが好ましい。
【０２６４】
この構成では、エレメンタリストリームに、前述の管理情報が付加されているので、ビデオフレームデータの分割のためにエレメンタリストリームを解析してビデオフレームデータの分割位置を検出するための手段や処理が必要ない。
【０２６５】
また、前記の従来技術においては、管理情報量を減らすために、ＧＯＰを１サンプルとして管理している。しかしながら、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットでは、本来１ビデオフレームを１サンプルとして管理するのが原則であり、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットを扱うプレーヤや編集ソフトにおいて互換性に支障が生じる虞がある。なお、この原則は、ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットをベースにしてＩＳＯ／ＩＥＣ　１５４４４−３／ＦＰＤＡｍｄ　１として規格化されたＩＳＯ　ｂａｓｅ　ｍｅｄｉａ　ｆｉｌｅ　ｆｏｒｍａｔにも踏襲されている。
【０２６６】
そこで、上記の構成において、前記エレメンタリストリームは、大きさの異なる前記第１ビデオデータ単位で前記ビデオフレームデータを管理するための複数種の前記管理情報が付加されていることが好ましい。これにより、例えば、第１ビデオデータ単位をサンプルとした場合、ＧＯＰをサンプルとするようなメモリ（バッファ）容量の小さい専用プレーヤでビデオデータを再生する一方、ビデオフレームデータをサンプルとするようなＱｕｉｃｋＴｉｍｅ　対応プレーヤでビデオデータを再生することができる。
【０２６７】
また、上記の構成において、前記管理情報は、前記第２ビデオデータ単位のビデオフレームデータよりも先に読み出されるように設けられていることが好ましい。これにより、管理情報がエレメンタリストリームと同一のファイルに格納されているか否かに関わらず、管理情報がビデオフレームデータよりも先に読み出されるので、管理情報が読み出されてから、ビデオエレメンタリストリームにおいて分割されるべきビデオフレームデータが読み出される。それゆえ、第１パケット生成手段（処理）が、読み出された管理情報に基づいて、ビデオエレメンタリストリームのビデオフレームデータへの分割処理を速やかに行なうことができる。
【０２６８】
前記の発明は、前記分離手段（処理）を備え、前記エレメンタリストリームが、同一ファイルにおいて該エレメンタリストリームの設けられる領域と別の領域に設けられ、前記エレメンタリストリームの前記ビデオフレームデータに関する管理情報が１個の前記エレメンタリストリームと対をなすように付加され、前記第１パケット生成手段が、前記ビデオエレメンタリストリームに付随して分離された前記管理情報に基づいて第２ビデオデータ単位をビデオフレームデータに分割することが好ましい。
【０２６９】
この構成では、前記管理情報が、同一ファイルにおいてエレメンタリストリームの設けられる領域と別の領域に設けられ、１個のエレメンタリストリームと対をなすように付加されるので、前述の分離手段（処理）を備えた構成と同様に、エレメンタリストリームに、ビデオフレームデータの分割のためにエレメンタリストリームを解析してビデオフレームデータの分割位置を検出するための手段や処理が必要ない。
【０２７０】
データ変換プログラムは、前記のデータ変換方法における各処理をコンピュータに実行させ、また、このデータ変換プログラムは、コンピュータ読み取り可能な記録媒体に記録して提供可能である。
【０２７１】
【発明の効果】
以上のように、本発明によれば、ビデオデータ中のｖｂｖ＿ｄｅｌａｙに常に値をセットするようにしたことで、ＥＳをインターリーブしたＡＶストリーム構成においてＴＳ／ＰＳへの変換を容易にしかも確実にすることが可能である。
【０２７２】
また、通常の管理情報とは別に、ビデオデータの各ビデオフレームのデータ量、ピクチャタイプ、ｖｂｖ＿ｄｅｌａｙ値を、ビデオデータとは別の位置に記録することで、ＴＳ／ＰＳ変換時にビデオデータを解析する必要がなくなる。また、これらの情報をＡＶストリーム中に記録し、通常再生に用いる管理情報とは別にすることで、通常再生時の管理情報を記憶するためのメモリを増加させることはない。
【０２７３】
さらに、通常再生に用いる管理情報とは別に、ビデオデータの各ビデオフレームのデータ量、ピクチャタイプ、ｖｂｖ＿ｄｅｌａｙを求めることが可能な情報を、ＩＳＯ　ｂａｓｅ　ｍｅｄｉａ　ｆｉｌｅ　ｆｏｒｍａｔで規定されているＭｏｖｉｅ　ｆｒａｇｍｅｎｔの形式で格納することによって、専用プレーヤだけでなく、ＩＳＯ　ｂａｓｅ　ｍｅｄｉａ　ｆｉｌｅ　ｆｏｒｍａｔあるいはＱｕｉｃｋＴｉｍｅファイルフォーマットに対応したプレーヤで再生可能になる。
【図面の簡単な説明】
【図１】本発明の実施形態に係るビデオディスクレコーダの概略構成を示すブロック図である。
【図２】（ａ）ないし（ｃ）はＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおける管理情報とＡＶストリームとの関係を示す図である。
【図３】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＭｏｖｉｅ　ａｔｏｍの概要を示す図である。
【図４】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＴｒａｃｋ　ａｔｏｍの概要を示す図である。
【図５】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＴｒａｃｋ　ｈｅａｄｅｒ　ａｔｏｍ　の構成を示す図である。
【図６】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＭｅｄｉａ　ａｔｏｍの構成を示す図である。
【図７】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＭｅｄｉａ　ｉｎｆｏｒｍａｔｉｏｎ　ａｔｏｍの構成を示す図である。
【図８】Ｓａｍｐｌｅ　ｔａｂｌｅ　ａｔｏｍによるデータ管理の例を示す図である。
【図９】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＳａｍｐｌｅ　ｔａｂｌｅ　ａｔｏｍ　の構成を示す図である。
【図１０】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＥｄｉｔ　ａｔｏｍ　の構成を示す図である。
【図１１】Ｅｄｉｔ　ａｔｏｍによる再生範囲指定の例を示す説明図である。
【図１２】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＵｓｅｒ　ｄａｔａ　ａｔｏｍの構成を示す図である。
【図１３】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＦｒａｇｍｅｎｔｅｄ　ｍｏｖｉｅの全体構成を示す図である。
【図１４】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＭｏｖｉｅ　ｅｘｔｅｎｄｓ　ａｔｏｍの構成を示す図である。
【図１５】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＴｒａｃｋ　ｅｘｔｅｎｄｓ　ａｔｏｍの構成を示す図である。
【図１６】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＭｏｖｉｅ　ｆｒａｇｍｅｎｔ　ａｔｏｍ　の構成を示す図である。
【図１７】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＭｏｖｉｅ　ｆｒａｇｍｅｎｔ　ｈｅａｄｅｒ　ａｔｏｍの構成を示す図である。
【図１８】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＴｒａｃｋ　ｆｒａｇｍｅｎｔ　ａｔｏｍ　の構成を示す図である。
【図１９】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＴｒａｃｋ　ｆｒａｇｍｅｎｔ　ｈｅａｄｅｒ　ａｔｏｍの構成を示す図である。
【図２０】ＱｕｉｃｋＴｉｍｅ　ファイルフォーマットにおけるＴｒａｃｋ　ｆｒａｇｍｅｎｔ　ｒｕｎ　ａｔｏｍ　の構成を示す図である。
【図２１】（ａ）はディレクトリ／ファイル構成を示す図であり、（ｂ）はそのディレクトリ／ファイル構成のＵＤＦにおける管理を示す図である。
【図２２】本発明の第１の実施形態に係るビデオディスクレコーダにおけるＴＳ／ＰＳ変換部の概略構成を示すブロック図である。
【図２３】上記第１の実施形態におけるＡＶストリームの構成を示す図である。
【図２４】上記第１の実施形態におけるＶＵの構造を示す図である。
【図２５】上記第１の実施形態におけるＱｕｉｃｋＴｉｍｅ　によるＡＶストリーム管理形態を示す図である。
【図２６】上記第１の実施形態におけるリファレンスデバイスモデルを示す説明図である。
【図２７】上記第１の実施形態における記録処理の手順を示すフローチャートである。
【図２８】上記第１の実施形態におけるビデオＴＳパケット生成処理の概念を示す図である。
【図２９】上記第１の実施形態におけるオーディオＴＳパケット生成処理の概念を示す図である。
【図３０】上記第１の実施形態におけるＴＳパケット多重化処理の手順を示すフローチャートである。
【図３１】上記第１の実施形態におけるビデオＰＳパック生成処理の概念を示す図である。
【図３２】上記第１の実施形態におけるオーディオＰＳパック生成処理の概念を示す図である。
【図３３】上記第１の実施形態におけるＰＳパック多重化処理の手順を示すフローチャートである。
【図３４】本発明の第２の実施形態に係るビデオディスクレコーダにおけるＴＳ／ＰＳ変換部の概略構成を示すブロック図である。
【図３５】上記第２の実施形態におけるＶＵの構造を示す図である。
【図３６】上記第２の実施形態におけるＱｕｉｃｋＴｉｍｅ　によるＡＶストリーム管理形態を示す図である。
【図３７】本発明の第３の実施形態に係るビデオディスクレコーダにおけるＡＶストリームの構成を示す図である。
【図３８】上記第３の実施形態におけるＶＢＶ　ｄｅｌａｙ　ａｔｏｍの構成を示す図である。
【図３９】従来技術におけるＱｕｉｃｋＴｉｍｅ　ファイルフォーマットを用いたＡＶファイルの構成を示す図である。
【符号の説明】
１００　　　バス
１０１　　　ホストＣＰＵ
１０２　　　ＲＡＭ
１０３　　　ＲＯＭ
１０４　　　ユーザインタフェース
１０７　　　光ピックアップ（記録手段）
１０９　　　ＥＣＣエンコーダ（記録手段）
１１０　　　オーディオ再生用バッファ
１１１　　　ビデオ再生用バッファ
１１２　　　デマルチプレクサ
１１３　　　マルチプレクサ
１１５　　　オーディオデコーダ
１１６　　　ビデオデコーダ
１１７　　　オーディオエンコーダ
１１８　　　ビデオエンコーダ
１２１　　　ＴＳ／ＰＳ変換部（変換手段）
１２３　　　記録媒体
２０１　　　Ｍｏｖｉｅ　ａｔｏｍ（第１の管理情報）
４０４　　　Ｍｏｖｉｅ　ｆｒａｇｍｅｎｔ　ａｔｏｍ（第２の管理情報）
７０１　　　ＡＶストリーム
７０３　　　ＶＵ（ユニット）
７０４　　　ＧＯＰ（画像データ群）
７０５　　　ＡＡＵ
７０７　　　ＶＣ
７０８　　　ＡＣ
７０９　　　ＶＦＩ（第２の管理情報）
７１０　　　Ｍｏｖｉｅ　ｆｒａｇｍｅｎｔ　ａｔｏｍ（第２の管理情報）
１１０１　　ビデオＰＥＳパケット生成部
１１１１　　オーディオＰＥＳパケット生成部
１１０２　　ビデオＴＳパケット生成部
１１１２　　オーディオＴＳパケット生成部
１１２１　　ＴＳマルチプレクサ
１１２２　　ＰＳマルチプレクサ

Claims (23)

1. １個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームを記録する領域とは別の領域に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録方法であって、
   前記ＡＶストリーム中に前記ユニットの個々に関する第２の管理情報を含んだ状態で前記ＡＶストリームを記録し、
   前記第２の管理情報は、対応する第ユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴とするデータ記録方法。
2. 第２の管理情報のデータフォーマットにＩＳＯ　ｂａｓｅ　ｍｅｄｉａ　ｆｉｌｅ　ｆｏｒｍａｔにおけるＭｏｖｉｅ　Ｆｒａｇｍｅｎｔを用いることを特徴とする請求項１に記載のデータ記録方法。
3. １個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームを記録する領域とは別の領域に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録方法であって、
   前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記ＡＶストリームに含んだ状態で前記データ記録媒体に記録することを特徴とするデータ記録方法。
4. 前記遅延時間を含んだ前記ＡＶストリームを記録することを特徴とする請求項３に記載のデータ記録方法。
5. 前記ＡＶストリーム中に前記ユニットの個々に関する第２の管理情報を含んだ状態で前記ＡＶストリームを記録し、
   前記第２の管理情報は、対応するユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間を持つことを特徴とする請求項４に記載のデータ記録方法。
6. 前記第２の管理情報を、対応する前記ユニットの物理的な近傍に配置することを特徴とする請求項５に記載のデータ記録方法。
7. 前記第２の管理情報と前記ＡＶストリームとを同一ファイルで管理し、前記第２の管理情報を対応する前記画像データ群よりも低い前記ファイルの先頭からの相対アドレスに置くことを特徴とする請求項５に記載のデータ記録方法。
8. 前記遅延時間を少なくとも前記画像データ群外に記録し、
   前記第１の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間情報を持つことを特徴とする請求項４に記載のデータ記録方法。
9. 前記第１の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことを特徴とする請求項５に記載のデータ記録方法。
10. 前記第１の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記ビデオフレームのピクチャタイプに関する情報および前記遅延時間を持つことを特徴とする請求項３に記載のデータ記録方法。
11. 前記第２の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことを特徴とする請求項３または６記載のデータ記録方法。
12. １個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報とが記録されているデータ記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、
    前記データ量を用いて前記画像データ群をビデオフレームに分割して前記第１のＡＶストリームを前記第２のＡＶストリームに変換することを特徴とするデータ変換方法。
13. １個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、
    前記遅延時間を用いて前記画像データ群をビデオフレームに分割して前記第１のＡＶストリームを前記第２のＡＶストリームに変換することを特徴とするデータ変換方法。
14. １個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間およびデータ量とが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、
    前記遅延時間および前記データ量を用いて前記画像データ群をビデオフレームに分割して前記第１のＡＶストリームを前記第２のＡＶストリームに変換することを特徴とするデータ変換方法。
15. １個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間、データ量およびピクチャタイプとが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、
    前記遅延時間、前記データ量および前記ピクチャタイプを用いて前記画像データ群をビデオフレームに分割して前記第１のＡＶストリームを前記第２のＡＶストリームに変換することを特徴とするデータ変換方法。
16. １個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームとは別の領域に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録装置であって、
    前記ＡＶストリーム中に前記ユニットの個々に関する第２の管理情報を含んだ状態で記録する記録手段を備え、
    前記第２の管理情報は、対応する前記ユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴とするデータ記録装置。
17. １個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームとは別の場所に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録装置であって、
    前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を含んだ前記ＡＶストリームを前記データ記録媒体に記録する記録手段を備えることを特徴とするデータ記録装置。
18. １個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を記録されているデータ記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換装置であって、
    前記データ量に関する情報を用いて前記画像データ群をビデオフレームに分割して前記第１のＡＶストリームを第２のＡＶストリームに変換する変換手段を備えることを特徴とするデータ変換装置。
19. １個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換装置であって、
    前記遅延時間を用いて前記画像データ群をビデオフレームに分割して前記第１のＡＶストリームを第２のＡＶストリームに変換する変換手段を備えることを特徴とするデータ変換装置。
20. １個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームが記録された領域とは別の領域に前記ユニットに関する第１の管理情報が記録されているデータ記録媒体であって、
    前記ＡＶストリームは、前記ユニットの個々に関する第２の管理情報を含み、前記第２の管理情報は、対応する前記ユニットにおける前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴とするデータ記録媒体。
21. １個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームが記録されている領域とは別の領域に前記ユニットに関する第１の管理情報が記録されているデータ記録媒体であって、
    前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されていることを特徴とするデータ記録媒体。
22. 請求項１ないし１１のいずれか１項に記載のデータ記録方法をコンピュータに実行させるデータ記録プログラム。
23. 請求項２２のデータ記録プログラムを記録したコンピュータ読み取り可能な　記録媒体。

Images