JP3889338B2 - データ記録方法、データ記録装置、データ変換方法、データ変換装置、データ記録媒体、データ記録のためのプログラムおよびそのプログラムを記録した記録媒体 - Google Patents
データ記録方法、データ記録装置、データ変換方法、データ変換装置、データ記録媒体、データ記録のためのプログラムおよびそのプログラムを記録した記録媒体 Download PDFInfo
- Publication number
- JP3889338B2 JP3889338B2 JP2002244304A JP2002244304A JP3889338B2 JP 3889338 B2 JP3889338 B2 JP 3889338B2 JP 2002244304 A JP2002244304 A JP 2002244304A JP 2002244304 A JP2002244304 A JP 2002244304A JP 3889338 B2 JP3889338 B2 JP 3889338B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- stream
- video
- recording
- management information
- 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 - Fee Related
Links
Images
Landscapes
- Television Signal Processing For Recording (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ハードディスク、光ディスク、半導体メモリ等のランダムアクセス可能な記録媒体に対して、映像データおよび音声データを記録するデータ記録方法、データ記録装置、データ変換方法、データ変換装置、データ記録媒体、データ記録媒体、データ記録のためのプログラム、およびそのプログラムが記録された記録媒体に関するものである。
【０００２】
【従来の技術】
ディスクメディアを用いたビデオのディジタル記録再生装置（以下、ビデオディスクレコーダと呼ぶ）が普及しつつある。その記録フォーマットには、ＰＣ（パーソナルコンピュータ）との親和性を高めるため、ＰＣで広く使われている、QuickTime（商標）ファイルフォーマットを用いることがよく行われる。
【０００３】
QuickTime ファイルフォーマットを用いたビデオデータの管理については、特開２００１−１７６１９５号公報に開示されている。以下、図３９を用いてその概要を説明する。
【０００４】
ビデオデータは、ムービーファイル５００１に格納されている。ムービーファイル５００１は、実際のビデオデータおよびオーディオデータを格納するMovie data atom と、ビデオデータおよびオーディオデータを管理するためのMovie atomとで構成される。
【０００５】
Movie data atom 中では、入力されたオーディオとビデオとのＥＳ(Elementary Stream)が所定の時間（１秒程度）に対応するアクセスユニット（ＭＰＥＧ２ビデオであればＧＯＰ(Group of Pictures) 、ＭＰＥＧ２オーディオであればオーディオフレームとしてのＡＡＵ(Audio Access Unit) ）毎に区切り、これらを交互に配置する。それぞれの区切られた単位は、QuickTime におけるチャンクとして扱われる。また、各オーディオフレームおよびＧＯＰは、QuickTime におけるサンプルとして扱われる。各サンプルのデータ量および再生時間、ならびにムービーファイル５００１中での各チャンクの相対アドレスは、Movie atomに格納し、再生の際は、Movie atomを参照することで、ある時間に対応するビデオデータおよびオーディオデータの記録位置を特定することが可能となる。
【０００６】
【発明が解決しようとする課題】
しかしながら、一般に広く用いられているのは、上記のストリーム構成と異なる構成を持ったISO/IEC 13818-1 に定義されるTransport Stream（以下MPEG 2-TS ）や、Program Stream（以下MPEG 2-PS ）である。例えば、DVD-Video ではＭＰＥＧ２−ＰＳが採用されており、ディジタル放送やIEEE-1394による機器間のデータ転送形式ではＭＰＥＧ２−ＴＳが採用されている。したがって、上記のストリーム構成で記録したデータをIEEE-1394による伝送形式で別の機器に転送したり、ＤＶＤプレーヤで再生できるようにするためには、上記のストリーム構成のデータをＭＰＥＧ２−ＰＳやＭＰＥＧ２−ＴＳへ変換する必要がある。ところが、前記の従来技術においては、そのための方法が開示されていない。
【０００７】
本発明は、上記課題を鑑みてなされたものであり、Elementary Stream 同士を多重化したストリーム構成を持ち、そのストリームを、複数のフレームを１単位として管理する場合において、ＭＰＥＧ２−ＴＳ／ＰＳのファイルフォーマットのストリームに容易に変換可能な形態でデータを記録媒体に記録するデータ記録方法等を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明のデータ記録方法および装置は、１個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームを記録する領域とは別の領域に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録方法および装置であって、前記ＡＶストリーム中に前記ユニットの個々に関する第２の管理情報を含んだ状態で前記ＡＶストリームを記録し、前記第２の管理情報が、対応する前記ユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴としている。
【０００９】
この方法・装置では、QuickTime ファイルフォーマットでデータ記録媒体に記録されているＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳストリームに変換する際に、ＡＶストリーム中の第２管理情報を用いることによって、画像データ群を解析することなく、通常の記録・再生に必要な管理情報を増やさずに、ストリーム変換することができる。それゆえ、QuickTime ファイルフォーマットのＡＶ(Audio and Visual)ストリームをＭＰＥＧ２−ＴＳのファイルフォーマットを採用する機器（IEEE-1394やＤＶＤプレーヤ等）に容易に転送することができる。
【００１０】
上記のデータ記録方法においては、第２の管理情報のデータフォーマットにISO base media file formatにおけるMovie Fragmentを用いることが好ましい。これにより、通常の記録・再生に必要な管理情報を増やさないだけでなく、再生互換性を高めることができる。
【００１１】
本発明の他のデータ記録方法および装置は、１個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームを記録する領域とは別の領域に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録方法および装置であって、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記データ記録媒体に記録することを特徴としている。
【００１２】
この方法および装置では、上記の遅延時間をデータ記録媒体に記録するので、このデータ記録媒体から読み出された、QuickTime ファイルフォーマットでデータ記録媒体に記録されているＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳストリームに変換する際に、遅延時間を用いることによって、確実にストリーム変換することができる。
【００１３】
このデータ記録方法において、前記遅延時間を含んだ前記ＡＶストリームを記録することが好ましい。これにより、通常の記録・再生に必要な管理情報を増加させることがない。
【００１４】
しかも、前記ＡＶストリーム中に前記ユニットの個々に関して第２の管理情報を含んだ状態で前記ＡＶストリームを記録し、前記第２の管理情報、例えば後述するVideo Frame Informationが、対応するユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間を持つことにより、画像データ群を解析する必要がない。
【００１５】
また、前記第２の管理情報を、対応する前記ユニットの物理的な近傍に配置することにより、ＡＶストリームのデコードの前に必要なバッファメモリの容量を少なくすることができる。あるいは、前記第２の管理情報と前記ＡＶストリームとを同一ファイルで管理し、前記第２の管理情報を対応する前記画像データ群よりも低い前記ファイルの先頭からの相対アドレスアドレスに置くことによっても、バッファメモリの容量が少なくすることができる。
【００１６】
前述のように、遅延時間をＡＶストリーム中に記録した場合、前記遅延時間を少なくとも前記画像データ群外に記録し、前記第１の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間情報を持つことが好ましい。これにより、画像データ群を解析する必要がなくなる。
【００１７】
前記第１の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことが好ましい。これにより、Ｂピクチャにも対応することができる。
【００１８】
前記第１の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記ビデオフレームのピクチャタイプに関する情報および前記遅延時間を持つことが好ましい。これにより、画像データ群を解析する必要がない。
【００１９】
前記第２の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことが好ましい。
【００２０】
本発明のデータ記録プログラムは、前記のデータ記録方法をコンピュータに実行させる。また、このデータ記録プログラムは、コンピュータ読み取り可能な 記録媒体に記録される。
【００２１】
本発明のデータ変換方法および装置は、１個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報とが記録されているデータ記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、変換の際に、前記データ量に関する情報を用いることを特徴としている。この方法では、QuickTime ファイルフォーマットの第１のＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳの第２のストリームに変換する際に、第１のＡＶストリーム中の第２の管理情報を用いることによって、画像データ群を解析することなく、ストリーム変換することができる。それゆえ、QuickTime ファイルフォーマットのＡＶ(Audio and Visual)ストリームをＭＰＥＧ２−ＴＳのファイルフォーマットを採用する機器（IEEE-1394やＤＶＤプレーヤ等）に容易に転送することができる。
【００２２】
本発明の他のデータ変換方法および装置は、１個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、前記遅延時間を用いて前記画像データ群を分割して前記第１のＡＶストリームを第２のＡＶストリームに変換することを特徴としている。
【００２３】
この方法では、上記の遅延時間が記録されたデータ記録媒体から読み出された、QuickTime ファイルフォーマットのＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳストリームに変換する際に、遅延時間を用いることによって画像データ群（ＧＯＰ）をビデオフレームに分割するので、確実にストリーム変換することができる。
【００２４】
本発明の他のデータ変換方法は、１個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間およびデータ量とが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、前記遅延時間および前記データ量を用いて前記画像データ群を分割して前記第１のＡＶストリームを第２のＡＶストリームに変換することにより、前述のデータ変換方法と同様、画像データ群を解析する必要がないだけでなく、遅延時間およびデータ量を用いることによって、確実にストリーム変換することができる。
【００２５】
本発明のさらに他のデータ変換方法は、１個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間、データ量およびピクチャタイプに関する情報が記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、前記遅延時間、前記データ量および前記ピクチャタイプを用いて前記画像データ群を分割して前記第１のＡＶストリームを第２のＡＶストリームに変換することにより、前述のデータ変換方法と同様、画像データ群を解析する必要がないだけでなく、遅延時間およびデータ量を用いることによって、確実にストリーム変換することができ、さらにＢピクチャにも対応することができる。
【００２６】
本発明のデータ記録媒体は、１個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームが記録された領域とは別の領域に前記ユニットに関する第１の管理情報が記録されているデータ記録媒体であって、前記ＡＶストリームは、前記ユニットの個々に関する第２の管理情報を含み、前記第２の管理情報は、対応する前記ユニットにおける前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴としている。
【００２７】
このようなデータ記録媒体から読み出されたQuickTime ファイルフォーマットのＡＶストリームは、ＭＰＥＧ２−ＴＳ／ＰＳの第２のストリームに変換する際に、ＡＶストリーム中の第２の管理情報を用いることによって、画像データ群を解析することなく、ストリーム変換することができる。それゆえ、QuickTime ファイルフォーマットのＡＶ(Audio and Visual)ストリームをＭＰＥＧ２−ＴＳのファイルフォーマットを採用する機器（IEEE-1394やＤＶＤプレーヤ等）に容易に転送することができる。
【００２８】
本発明の他のデータ記録媒体は、１個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームが記録されている領域とは別の領域に前記ユニットに関する第１の管理情報が記録されているデータ記録媒体であって、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されていることを特徴としている。
【００２９】
上記の遅延時間が記録されたデータ記録媒体から読み出された、QuickTime ファイルフォーマットのＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳストリームに変換する際に、遅延時間を用いることによって、確実にストリーム変換することができる。
【００３０】
【発明の実施の形態】
以下、本発明の実施形態について、図１ないし図３８を参照しながら詳細に説明する。ここでの説明は、本発明において共通に用いる構成、個々の実施形態に固有の内容という順に行なうものとする。
【００３１】
〔基本システム〕
図１は、後述する各実施形態において共通のビデオディスクレコーダの基本システム構成図である。以下に、この基本システムについて説明する。
【００３２】
＜システム構成＞
このビデオディスクレコーダは、図１に示すように、バス１００、ホストＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、ユーザインタフェース１０４、システムクロック発生器１０５、光ディスク１０６、ピックアップ１０７、ＥＣＣ(Error Correcting Coding)デコーダ１０８、ＥＣＣエンコーダ１０９、オーディオ再生用バッファ１１０、ビデオ再生用バッファ１１１、デマルチプレクサ１１２、マルチプレクサ１１３、記録用バッファ１１４、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８、オーディオ記録用バッファ１１９、ビデオ記録用バッファ１２０、ＴＳ／ＰＳ変換部１２１、外部ディジタル出力部１２２、および図示しないカメラ、マイク、スピーカ、ディスプレイ等で構成される。
【００３３】
ホストＣＰＵ１０１は、デマルチプレクサ１１２、マルチプレクサ１１３、ピックアップ１０７、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８、ＴＳ／ＰＳ変換部１２１等の制御をバス１００を通じて行う。デマルチプレクサ１１２、マルチプレクサ１１３、ピックアップ１０７、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８およびＴＳ／ＰＳ変換部１２１は、ハードウエアで構成されていてもよいし、ソフトウエアで構成されていてもよ。
【００３４】
ＲＡＭ１０２は、ビデオディスクレコーダの動作を制御するためにホストＣＰＵ１０１に実行させる制御プログラム等のプログラムやプログラムの実行に必要なデータをロードしたり、プログラムの実行のための作業領域を提供している。また、ＲＡＭ１０２は、再生時のＴＳ／ＰＳ変換部１２１によるファイルフォーマットの変換時等にＡＶストリームの後述する管理情報を読み込む。
【００３５】
ＲＯＭ１０３は、上記のプログラムやデータを格納している。制御プログラムは、後述する記録時の処理を実現するためのデータ記録プログラムやＴＳ／ＰＳ変換部１２１の変換処理を実現するための変換プログラムを含んでいる。このデータ記録プログラムや変換プログラムは、ＲＯＭ１０３に限らず、記憶媒体１２３に記憶されていてもよい。記録媒体１２３は、コンピュータが読み取り可能である光ディスク、光磁気ディスク、磁気ディスク、磁気テープ、半導体メモリ等の媒体であって、ドライブ装置１２４によって駆動される。
【００３６】
ユーザインタフェース１０４は、ユーザがディスプレイの画面上で本ビデオディスクレコーダの各種の操作をリモートコントローラを用いてできるように、操作案内等を画面に表示したりユーザによる操作入力を受け入れたりするためのソフトウエアである。
【００３７】
システムクロック発生器１０５は、ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３等に供給するためのシステムクロックを発生する回路である。
【００３８】
再生時に、光ディスク１０６からピックアップ１０７を通じて読み出されたデータは、ＥＣＣデコーダ１０８によって誤り訂正され、デマルチプレクサ１１２に送られる。デマルチプレクサ１１２は、ホストＣＰＵ１０１からの指示に従い、ＥＣＣデコーダ１０８から読み出されたデータよりオーディオデータおよびビデオデータを抽出して、それぞれをオーディオ再生用バッファ１１０およびビデオ再生用バッファ１１１に振り分ける。オーディオデータおよびビデオデータは、それぞれオーディオ再生用バッファ１１０およびビデオ再生用バッファ１１１に一時的に格納される。オーディオデコーダ１１５およびビデオデコーダ１１６は、ホストＣＰＵ１０１からの指示に従って、それぞれオーディオ再生用バッファ１１０およびビデオ再生用バッファ１１１からデータを読み出しデコードを行う。
【００３９】
一方、記録時には、オーディオデータおよびビデオデータがそれぞれオーディオエンコーダ１１７およびビデオエンコーダ１１８によって圧縮符号化される。圧縮符号化されたオーディオデータおよびビデオデータは、それぞれオーディオ記録用バッファ１１９およびビデオ記録用バッファ１２０に送られ、そこで一時的に格納される。マルチプレクサ１１３は、ホストＣＰＵ１０１からの指示に従って、オーディオ記録用バッファ１１９およびビデオ記録用バッファ１２０からデータを読み出し、これらをＡＶ多重化して記録用バッファ１１４に送る。ＥＣＣエンコーダ１０９は、記録用バッファ１１４から読み出したＡＶ多重化データに対し誤り訂正符号を付加し、ピックアップ１０７を通じて光ディスク１０６に記録する。
【００４０】
また、ＴＳ／ＰＳ変換部１２１は、ホストＣＰＵ１０１からの指示に従って、オーディオ再生用バッファ１１０およびビデオ再生用バッファ１１１に蓄えられている後述のQuickTime ファイルフォーマットのＥＳ(Elementary Stream) を、ＭＰＥＧ２−ＴＳ(Transport Stream)およびＭＰＥＧ２−ＰＳ(Program Stream)にファイルフォーマット変換する。このＴＳ／ＰＳ変換部１２１は、ソフトウエアで構成される場合、データ変換プログラムであって、ＲＯＭ１０３または記録媒体１２３に格納されている。変換の結果として生成されたＭＰＥＧ２−ＴＳおよびＭＰＥＧ２−ＰＳフォーマットのデータは、外部ディジタル出力部１２２を介して外部に出力されるか、あるいは記録用バッファ１１４およびＥＣＣエンコーダ１０９を介して光ピックアップ１０７により光ディスク１０６に記録される。
【００４１】
ＥＣＣエンコーダ１０９によるオーディオデータの符号化方式にはISO/IEC 11172-3で規定されるＭＰＥＧ１ Layer-IIを用いる。一方、ＥＣＣエンコーダ１０９によるビデオデータの符号化方式にはISO/IEC 13818-2で規定されるＭＰＥＧ２を用いる。光ディスク１０６は、ＤＶＤ−ＲＡＭのような書き換え可能な光ディスクである。この光ディスク１０６においては、２０４８byteを１セクタとし、誤り訂正のため１６セクタでＥＣＣブロックを構成する。
【００４２】
＜ファイルフォーマット＞
本基本システムにおいて、ＡＶストリーム管理のためのフォーマットとして用いる、QuickTimeファイルフォーマットについて説明する。QuickTime ファイルフォーマットとは、Apple 社が開発したマルチメディアデータ管理用フォーマットであり、ＰＣの世界で広く用いられている。また、QuickTime ファイルフォーマットをベースとしてISO base media file formatが規格化されている。
【００４３】
QuickTime ファイルフォーマットは、ビデオデータやオーディオデータ等（これらを総称してメディアデータとも呼ぶ）と管理情報とで構成される。両者を合わせてここでは、QuickTime ムービー（略してムービー）と称する。両者は、同じファイル中に存在してもよいし、別々のファイルに存在してもよい。
【００４４】
図２（ａ）は、両者が同じファイル２０１中に存在する場合にとる構成を示している。各種情報は“atom”という共通の構造に格納される。より詳細には、第１の管理情報はMovie atom２１１という構造に格納され、メディアデータはMovie dataatom２１２という構造に格納される。Movie atom２１１における管理情報には、メディアデータ中の任意の時間に対応するメディアデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。一方、Movie data atom２１２におけるメディアデータすなわちＡＶストリーム(AV stream) ２１３は、ＡＨ(Atom Header) が付加される。このような構成では、Movie atomはメディアデータをatom内で参照している。
【００４５】
図２（ｂ）は、管理情報とメディアデータとをそれぞれ別々のファイル２０２，２０３に格納した場合の構成を示している。管理情報はMovie atom２１１という構造に格納されるが、メディアデータはatomには格納される必要はない。このとき、Movie atom２１１は、メディアデータを格納したファイル２０３を「外部参照」している、という。
【００４６】
図２（ｃ）に示すように、外部参照は、例えば、ファイル２０４におけるMovie atom２１１から、複数のファイル２０５，２０６にそれぞれ格納されるＡＶストリーム２１３（AV stream ♯１，♯２）に対して行うことが可能である。このような仕組みにより、ＡＶストリーム２１３自体を物理的に移動することなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」や「非破壊編集」が可能になる。
【００４７】
続いて、図３ないし図２０を用いて、QuickTimeの管理情報のフォーマットについて説明する。
【００４８】
まず、共通の情報格納フォーマットであるatomについて説明する。
【００４９】
atomの先頭には、そのatomのサイズであるAtom size、およびそのatomの種別情報であるTypeが必ず存在する。Typeは4文字で区別され、例えば、図３に示すMovie atomでは'moov'となっており、Movie data atomでは'mdat'となっている。atomの先頭にあるAtom sizeおよびTypeの列を、ここでは“atom header”と称する。各atomは、別のatomを含むことができる。すなわち、atom間には階層構造がある。
【００５０】
図３は、Movie atomの構成を示している。この構造において、“Movie header atom”は、そのMovie atomが管理するムービーの全体的な属性を管理する。“Track atom”は、そのムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納する。“User data atom”は、ユーザにて独自に定義可能なatomである。
【００５１】
図４は、Track atomの構成を示している。“Track header atom”は、そのトラックの全体的な属性を管理する。“Edit atom”は、メディアデータのどの区間を、ムービーのどのタイミングで再生するかを管理する。“Track reference atom”は、本トラックと別のトラックとの関係を管理する。“Media atom”は、実際のビデオやオーディオといったデータを管理する。
【００５２】
図５は、Track header atomの構成を示している。ここでは、後での説明に必要なもののみについて説明する。“Flags”は、属性を示すフラグの集合であり、代表的なものとしてTrack enabledフラグがあり、このフラグが１であれば、そのトラックは再生され、０であれば再生されない。“Layer”は、そのトラックの空間的な優先度を表しており、画像を表示するトラックが複数あれば、Layerの値が小さいトラックほど画像が前面に表示される。
【００５３】
図６は、Media atomの構成を示している。“Media header atom”は、そのMedia atomの管理するメディアデータに関する全体的な属性等を管理する。“Handler reference atom”は、メディアデータをどのデコーダでデコードするかを示す情報を格納する。“Media information atom”は、ビデオやオーディオ等のメディア固有の属性情報を管理する。
【００５４】
図７は、Media information atomの構成を示している。“Media information header atom”は、ビデオやオーディオ等メディア固有の属性情報を管理する。“Handler reference atom”は、前述のMedia atomに含まれるものと同じである。“Data information atom”は、そのQuickTimeムービーが参照するメディアデータを含むファイルの名称を管理するatomである“Data reference atom”を含む。“Sample table atom”は、データのサイズや再生時間等を管理している。
【００５５】
次に、Sample table atomについて説明するが、その前に、QuickTimeにおけるデータの管理方法について、図８を用いて説明する。
【００５６】
QuickTimeでは、データの最小単位（例えばビデオフレーム）をサンプル(sample)と称する。サンプルには、個々のトラック毎に、再生時間順に１から番号（サンプル番号）が♯１，♯２，…♯ｉというように付与されている。
【００５７】
また、QuickTimeフォーマットでは、個々のサンプルの再生時間長およびデータサイズを管理している。しかも、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンク(chunk) と称する。チャンクにも、サンプルと同様に、再生時間順に１から番号が付与されている。
【００５８】
さらに、QuickTimeフォーマットでは、個々のチャンクのファイル先頭からのアドレスおよび個々のチャンクが含むサンプル数を管理している。これらの情報に基づき、任意の時間に対応するサンプルの位置を求めることが可能となっている。
【００５９】
図９は、Sample table atomの構成を示している。“Sample description atom”は、個々のチャンクのデータフォーマット(Data format) やサンプルが格納されているファイルのチャンクの Index等を管理する。“Time-to-sample atom”は、個々のサンプルの再生時間を管理する。
【００６０】
“Sync sample atom”は、個々のサンプルのうち、デコード開始可能なサンプルを管理する。“Sample-to-chunk atom”は、個々のチャンクに含まれるサンプル数を管理する。“Sample size atom”は、個々のサンプルのサイズを管理する。“Chunk offset atom”は、個々のチャンクのファイル先頭からのアドレスを管理する。
【００６１】
図１０は、Edit atom の構成を示している。Edit atom は、１個のEdit list atomを含む。Edit list atomは、Number of entriesで指定される個数分の、“Track duration”、“Media time”、“Media rate”の値の組（エントリ）を持つ。各エントリは、トラック上で連続的に再生される区間に対応し、そのトラック上での再生時間順に並んでいる。
【００６２】
Track durationは、そのエントリが管理する区間のトラック上での再生時間を表している。Media timeは、そのエントリが管理する区間の先頭に対応するメディアデータ上での位置を表している。Media rateは、そのエントリが管理する区間の再生スピードを表している。
【００６３】
なお、Media timeが−１の場合は、そのエントリのTrack duration分、そのトラックに無再生区間を挿入する。この区間のことをempty editと称する。
【００６４】
図１１は、Edit list の使用例を示す。ここでは、Edit list atomの内容が図１１（ａ）に示す内容であり、さらにサンプルの構成が図１１（ｂ）であったとする。なお、ここではｉ番目のエントリのTrack durationをＤ(i) 、Media timeをＴ(i) 、Media rateをＲ(i) とする。このとき、実際のサンプルの再生は、図１１（ｃ）に示す順に行われる。このことについて簡単に説明する。
【００６５】
まず、エントリ♯１は、Ｄ(1) が１３０００、Ｔ(1) が２００００、Ｒ(1) が１であるため、そのトラックの先頭から１３０００の区間は、サンプル中の時刻２００００から３３０００の区間を再生する。次に、エントリ♯２は、Ｄ(2) が５０００、Ｔ(2) が−１であるため、トラック中の時刻１３０００から１８０００の区間、何も再生を行わない（図１１（ｃ）における“null”）。
【００６６】
最後に、エントリ♯３は、Ｄ(3) が１００００、Ｔ(3) が０、Ｒ(3) が１であるため、トラック中の時刻１８０００から２８０００の区間において、サンプル中の時刻０から１００００の区間を再生する。
【００６７】
図１２は、User data atomの構成を示している。このatomには、QuickTimeフォーマットで定義されてない独自の情報を任意個数格納することができる。１個の独自情報は１個のエントリで管理され、１個のエントリは“Size”と“Type”と“User data ”とで構成される。Sizeはそのエントリ自体のサイズを表し、Typeは独自情報をそれぞれ区別するための識別情報を表し、User dataは実際のデータを表している。
【００６８】
次に、録画中の電源遮断等に対応するために導入された概念であるFragmented Movieについて説明する。Fragmented movieは、QuickTime フォーマットの１アプリケーションであるMotion JPEG2000 で導入された概念であり、上述のSample table atomに相当する情報を、部分的なＡＶストリーム毎に管理することが可能となっている。Motion JPEG2000 では、atomの代わりにbox という用語を用いているが、ここでは統一のためにatomに置き換えて説明する。
【００６９】
図１３は、Fragmented movieを導入したQuickTime ファイル４０１の全体構成を示している。先頭に、そのファイル全体に共通する情報を管理するMovie atom（情報管理部）４０２が配置され、その後に、部分ＡＶストリームデータを格納するMovie data atom（データ格納部）４０３と、その部分ＡＶストリームデータを構成するサンプルのアドレスやサイズ、再生時間等を管理するMovie fragment atom （管理部）４０４とが交互に配置される。なお、ＡＶストリームデータは、通常の QuickTimeファイルと同様、別ファイルに存在しても構わない。
【００７０】
録画時には、この順番で記録を行なっていくことにより、録画時の電源切断による被害を最小限に防ぐことが可能となっている。Movie atom４０２には、そのQuickTime ムービーがFragmented movie であることを示すためのMovie extends atom４０２１が含まれる。Movie extends atom４０２１には、そのムービーに含まれる各トラックに関するデフォルト値(Track extends atom４０４２) が格納される。
【００７１】
また、 Movie fragment atom４０４には、その Movie fragment atom４０４が管理する部分ＡＶストリームに関する管理情報が含まれている。管理情報には、その管理する部分ＡＶストリーム全体に関する情報を格納するMovie fragment header atom ４０４１と、部分ＡＶストリーム中の各トラックに関する情報を格納する Track fragment atom４０４２とがある。
【００７２】
Track fragment atom４０４２は、それが管理するトラックに属する部分ＡＶストリームに関する情報を格納するTrack fragment header atom４０４３と、そのトラックに属する部分ＡＶストリームを構成する論理的な連続領域（Track runと呼ばれる）をそれぞれ管理する Track fragment run atom４０４４とを含む。以下に、各atomについて詳しく説明する。
【００７３】
図１４は、 Movie extends atom４０２１の構成を示している。Movie extends atom４０２１は、前述のように、このatomを含む QuickTimeムービーがFragmented movieであることを示す役割を持つ。
【００７４】
図１５は、Track extends atom４０２１の構成を示す。Track extends atom ４０２１は、この QuickTimeムービーに含まれる各トラックのサンプルのデフォルト値を設定するために存在する。Track-IDは、Movie atom中で定義されているトラックのtrack-IDを参照する。“Default-sample- ”で始まるフィールドは、このatomで管理されるtrack fragmentのデフォルト値を設定する。
【００７５】
図１６は、 Movie fragment atom４０４の構成を示している。このatomは、録画中に逐次記録される管理情報であり、前述のとおり、このatomの管理するMovie fragmentに関する実際の情報を格納するatomである Movie fragment header atom４０４３や Track fragment atom４０４２を含む。
【００７６】
図１７は、Movie fragment header atom４０４３の構成を示している。このatomに格納されている主な情報は“sequence-number ”である。sequence-numberは、このatomが含まれるMovie fragment atom４０４が管理するMovie fragmentの先頭からの順番を表す。
【００７７】
図１８は、 Track fragment atom４０４２の構成を示す。Track fragment atom４０４３は、Movie fragmentに含まれる特定のトラックのサンプルに関する管理情報であるTrack fragment header atom４０４３やTrack fragment run atom４０４４を格納する。
【００７８】
図１９は、Track fragment header atom４０４３の構成を示している。このatomは、Movie fragmentに含まれる特定のトラックのサンプルに関するデフォルト値等を格納する。track-IDは、Movie atom中で定義されているトラックのtrack IDとの対応を示す。sample-description-indexは、このatomが管理するサンプルの参照するsample description tableのインデックス番号、“default-sample- ”で始まるフィールドは、それぞれこのatomが管理するサンプルのデフォルト値である。
【００７９】
図２０は、 Track fragment run atom４０４４の構成を示す。このatomは、Track runと呼ばれる、このatomの管理する連続領域や個々のサンプルの管理情報を格納する。sample-countは、Track run に含まれるサンプルの個数を示す。data-offset は、base-data-offsetからのTrack run のオフセット値を示す。“sample- ”で始まるフィールドは、このatomが管理するサンプルの再生時間等の値を格納する。ただし、上述のデフォルト値と同じであれば、省略してデータサイズを縮小することが可能となっている。
【００８０】
＜ファイルシステム＞
本発明の説明において用いるファイルシステムのフォーマットであるＵＤＦ(Universal Disk Format) について図２１を用いて説明する。図２１（ｂ）は、図２１（ａ）に示すディレクトリ/ファイル構成をＵＤＦで記録した例を示す。
【００８１】
図中のＡＶＤＰ(Anchor Volume Descriptor Pointer)６０２は、ＵＤＦの管理情報を探すためのエントリポイントに相当し、通常２５６セクタ目、Ｎセクタ目あるいはＮ−２５６セクタ目(Ｎは最大論理セクタ番号)に記録される。
【００８２】
ＶＤＳ(Volume Descriptor Sequence)６０１は、ＵＤＦが管理する領域であるボリュームに関する管理情報を記録する。ボリュームは、一般に１枚の光ディスク１０６に１個存在し、その中にパーティションを一般に１個含む。
【００８３】
ＦＳＤ(File Set Descriptor) ６０３は、パーティションに１個存在する。パーティションの中での位置情報は、パーティションの先頭からのセクタ番号に相当する論理ブロック番号で示される。
【００８４】
なお、１個の論理ブロックは１セクタに対応する。また、各パーティションには図示しないがSpace Bitmapと呼ばれる各論理ブロックがファイルにすでに割り当てられているか否かを示すテーブルが存在する。
【００８５】
ＦＳＤ６０３は、ルートディレクトリのＦＥ(File Entry)６０４の位置情報（論理ブロック番号と論理ブロック数とで構成されて“extent”と呼ばれる）を含む。ＦＥは、extentの集合を管理しており、extentを書き換えたり、追加や削除することで、ファイルを構成する実データの順番を変えたり、データの挿入や削除をしたりできる。
【００８６】
ＦＥ６０４は、ルートディレクトリの直下のファイルやディレクトリの名称等を格納するＦＩＤ(File Identifier Descriptor)６１１，６１２，…の集合を格納する領域６０５を管理する。領域６０５中のＦＩＤ６１１，６１２は、それぞれファイル６２１，６２２のファイル名やextentの集合を管理するＦＥ６０６，６０８の位置情報を含む。
【００８７】
ＦＥ６０６は、ファイル６２１の実データを構成する領域である領域６０７，６１０をextentとして管理する。このとき、ファイル６２１の実データにアクセスするには、ＡＶＤＰ６０２、ＶＤＳ６０１、ＦＳＤ６０３、ＦＥ６０４、ＦＩＤ６１１、ＦＥ６０６、領域６０７、領域６１０の順にリンクを辿っていけばよい。
【００８８】
光ディスク１０６のデータ記録領域には、図２１（ｂ）の構成でＡＶストリームが記録されている。前述のムービーファイル、すなわちＡＶストリームやMovie atom、Movie fragment atom 等の管理情報は、図２１(ｂ)の領域６０７，６１０で表されるファイルを構成する実データとして記録される。例えば、図２（ａ）のムービーファイル２０１のMovie atom２１１は、領域６１０の前半部分に記録され、ＡＶストリームを含むMovie dara atom２１２は、領域６１０の後半部分および領域６０７全体に記録されるようなとこが考えられる。
【００８９】
この場合、ＦＥ６０６には、ファイルシステムを通して、ムービーファイル２０１を読み出したときに、図２（ａ）の順に読み出されるように、領域６１０のextent、領域６０７のextentの順に位置情報を格納する。つまり、この例で示すように、ファイルを構成する実データは、実際には、光ディスク１０６では連続的に記録される保証はなく、また、ファイル中の順序で光ディスク１０６に記録される保証もない。
【００９０】
ただし、次のような例外もある。ディスク媒体に対しては、ディスク上で物理的に離れた場所にあるデータにアクセスするのに、ピックアップの移動を伴い、その間にデータの読み出しおよび記録が停止する。そのため、管理情報を物理的に連続して記録することで、管理情報の読み出しを高速化したり、ＡＶストリームを所定の長さ以上で連続的に記録したりすることで、ビデオデータやオーディオデータを途切れることなく再生することを保証するのはよく知られた技術である。
【００９１】
〔第１の実施形態〕
本発明の第１の実施形態について、図２２ないし図３３を用いて説明する。
【００９２】
＜システム構成＞
本実施形態に係るビデオディスクレコーダは、図１に示す前述のビデオディスクレコーダの構成と共通しているが、本実施形態で特徴的な処理部であるＴＳ／ＰＳ変換部１２１について図２２を用いて詳細に説明する。
【００９３】
ＴＳ／ＰＳ変換部１２１は、ビデオＰＥＳパケット生成部１１０１、ビデオＴＳパケット生成部１１０２、ビデオＴＳパケット用バッファ１１０３、ビデオパック生成部１１０４、ビデオパック用バッファ１１０５、オーディオＰＥＳパケット生成部１１１１、オーディオＴＳパケット生成部１１１２、オーディオＴＳパケット用バッファ１１１３、オーディオパック生成部１１１４、オーディオパック用バッファ１１１５、ＴＳマルチプレクサ１１２１、ＰＳマルチプレクサ１１２２、およびビデオ解析部１１３１より構成される。
【００９４】
次に、それぞれの処理部について説明する。
【００９５】
ビデオＰＥＳパケット生成部１１０１は、ビデオ再生用バッファ１１１から読み出したビデオＥＳ（ビデオフレームデータ）に基づいてＰＥＳ(Packetized Elementary Stream)パケットを生成する。オーディオＰＥＳパケット生成部１１１１も同様に、オーディオ再生用バッファ１１０から読み出したオーディオＥＳに基づいてＰＥＳパケットを生成する。ビデオ解析部１１３１は、ビデオ再生用バッファ１１１からのビデオＥＳにおけるビデオフレームの境界を検出する。ビデオＰＥＳパケット生成部１１０１は、その境界に基づいてビデオチャンクをビデオフレームに分割する。
【００９６】
ビデオＴＳパケット生成部１１０２は、ビデオＰＥＳパケット生成部１１０１からのＰＥＳパケットに基づいてＴＳ(Transport Stream)パケット（ビデオＴＳパケット）を生成する。オーディオＴＳパケット生成部１１１２は、オーディオＰＥＳパケット生成部１１１１からのＰＥＳパケットに基づいてＴＳパケット（オーディオＴＳパケット）を生成する。
【００９７】
ＴＳマルチプレクサ１１２１は、ビデオＴＳパケット生成部１１０２およびオーディオＴＳパケット生成部１１１２によって生成されたＴＳパケットを、多重化してＭＰＥＧ２−ＴＳを生成する。ビデオＴＳパケット用バッファ１１０３およびオーディオＴＳパケット用バッファ１１１３は、ビデオＴＳパケット生成部１１０２およびオーディオＴＳパケット生成部１１１２からのＴＳパケットを一時的に蓄えることにより、両ＴＳパケット生成部１１０２，１１１２とＴＳマルチプレクサ１１２１との処理の時間差を吸収する。
【００９８】
ビデオパック生成部１１０４は、ビデオＰＥＳパケット生成部１１０１から送られてきたビデオＰＥＳパケットをグループ化してビデオパックを生成する。オーディオパック生成部１１１４も同様に、オーディオＰＥＳパケット生成部１１１１から送られてきたオーディオＰＥＳパケットをグループ化してオーディオパックを生成する。
【００９９】
ＰＳマルチプレクサ１１２２は、ビデオパック生成部１１０４およびオーディオパック生成部１１１４によって生成されたパックを多重化してＭＰＥＧ２−ＰＳを生成する。ビデオパック用バッファ１１０５およびオーディオパック用バッファ１１１５は、ビデオパック生成部１１０４およびオーディオパック生成部１１１４からのパックを一時的に蓄えることにより、両パック生成部１１０４，１１１４とＰＳマルチプレクサ１１２２との処理の時間差を吸収する。
【０１００】
＜ＡＶストリームの形態＞
本実施形態において用いるＡＶストリームの構成について、図２３および図２４を用いて説明する。
【０１０１】
ＡＶストリーム７０１は、整数個のＣＵ(Continuous Unit) ７０２で構成される。ＣＵ７０２は、ディスク上で連続的に記録する単位である。ＣＵ７０２の長さは、ＡＶストリーム７０１を構成するＣＵ７０２をどのように光ディスク１０６上に配置してもシームレス再生（再生中に画像や音声が途切れないで再生できること）やリアルタイムアフターレコーディング（アフレコ対象のビデオをシームレス再生しながらオーディオを記録すること）が保証されるように設定される。この設定方法については後述する。
【０１０２】
ＣＵ７０２は、先頭から連続する番号が♯１，♯２，…，♯Ｌのように付与されており、各ＣＵ７０２は整数個のＶＵ(Video Unit)７０３から構成される。ＶＵ７０３は、単独再生可能な単位であり、そのことから再生の際のエントリポイントとなり得る。また、ＶＵ７０３も、先頭から連続する番号が♯１，♯２，…，♯Ｍのように付与される。
【０１０３】
図２４は、ＶＵ７０３構成を示している。ユニットとしてのＶＵ７０３は、１秒程度のビデオデータを格納した複数（整数個）のＧＯＰ７０４（画像データ群）と、それらと同じ時間に再生されるオーディオデータを格納した複数（整数個）のオーディオ復号単位であるＡＡＵ７０５とから構成される。
【０１０４】
なお、ＧＯＰ７０４は、ＭＰＥＧ２ビデオ規格における画像圧縮の単位であり、複数のビデオフレーム（典型的には１５フレーム程度）で構成される。ＡＡＵ７０５は、ＭＰＥＧ１オーディオのレイヤＩＩ(Layer-II)規格における音声圧縮の単位で、１１５２点の音波形サンプル点により構成される。サンプリング周波数が４８kHzの場合、ＡＡＵ７０５あたりの再生時間は０．０２４秒となる。ＶＵ７０３中では、ＡＶ同期再生のために必要となる遅延を小さくするため、ＡＡＵ７０５が配置され、それに続いてＧＯＰ７０４が配置される。
【０１０５】
また、ＶＵ７０３単位で独立再生を可能とするために、ＶＵ７０３におけるビデオデータ（ＧＯＰ７０４）の先頭には、ランダムアクセスの頭出しのために用いられるＳＨ(Sequence Header) ７０６が配置される。ＶＵ７０３の再生時間は、ＶＵ７０３に含まれるビデオフレーム数にビデオフレーム周期を乗算した時間と定義する。
【０１０６】
ビデオデータについては、ＴＳ／ＰＳへの変換の容易さを考慮して、ピクチャ層(picture header())におけるvbv＿delay に以下の制限を設ける。まず、ＭＰＥＧ２ビデオ規格におけるvbv＿delay について説明する。ＭＰＥＧ２ビデオ規格において、vbv＿delay は、一定速度のＣＢＲ(Constant Bit Rate) の場合、ストリーム検証用の仮想的なモデルであるＶＢＶ(Video Buffering Verifier)におけるＶＢＶバッファにピクチャの最初のデータが入ってから、実際にそのピクチャがデコードされるまでの遅延時間を格納している。一方、可変速度のＶＢＲ(Variable Bit Rate) の場合、vbv＿delay は、ＣＢＲと同様に遅延時間を格納することも、格納しないことも可能である。なお、遅延時間を格納していないことを示すために、vbv＿delay に０ｘＦＦＦＦを格納する。
【０１０７】
本実施形態では、vbv＿delay に対して、ＶＢＲの場合においても必ず、遅延時間を格納するように制限する。このことによって、後述するように、ＴＳ／ＰＳに変換する際、ＭＰＥＧ規格に沿った多重化が容易になる。
【０１０８】
＜ＡＶストリーム管理方法＞
ＡＶストリームの管理方法は、前述の QuickTimeファイルフォーマットをベースにしている。
【０１０９】
図２５は、ＡＶストリーム管理形態を示している。ビデオデータ，オーディオデータをそれぞれビデオトラック，オーディオトラックで管理し、ビデオトラックについては、１個のＧＯＰ７０４を１サンプル(Sample)、ＶＵ７０３におけるビデオの塊となるＶＣ(Video Cghunk)７０７を１チャンクとして管理する。オーディオトラックについては、ＡＡＵ７０５を１サンプル、ＶＵ７０３中のオーディオの塊となるＡＣ(Audio Chunk) ７０８を１チャンクとして管理する。
【０１１０】
＜ＣＵ単位決定方法＞
次に、ＣＵ単位決定方法について説明する。この決定方法では、基準となるデバイス(リファレンスデバイスモデル)を想定し、その上でシームレス再生が破綻しないように連続記録単位を決める。
【０１１１】
まず、リファレンスデバイスモデルについて図２６を用いて説明する。
【０１１２】
リファレンスデバイスモデルは、１個のピックアップとそれにつながるＥＣＣエンコーダデコーダ５０１、トラックバッファ５０２、デマルチプレクサ５０３、アフレコ（アフターレコーディング）用バッファ５０４、オーディオエンコーダ５０９、ビデオバッファ５０５、オーディオバッファ５０６、ビデオデコーダ５０７、およびオーディオデコーダ５０８によって構成される。
【０１１３】
本モデルにおけるシームレス再生は、ＶＵのデコード開始時にトラックバッファ５０２上に少なくとも１個のＶＵが存在すれば保証されるものとする。オーディオフレームデータのＥＣＣエンコーダ５０１へのデータ入力速度およびＥＣＣデコーダ５０１からのデータ出力速度をＲｓとする。
【０１１４】
また、アクセスによる読み出し、記録の停止する最大期間をＴａとする。さらに、短いアクセス（１００トラック程度）に要する時間をＴｋとする。これらの期間（時間）には、シーク時間、回転待ち時間、アクセス後に最初にディスクから読み出したデータがＥＣＣから出力されるまでの時間が含まれる。本実施形態では、Ｒｓ＝２０Mbps、Ｔａ＝１秒、Ｔｋ＝０．２秒とする。
【０１１５】
前記のリファレンスデバイスモデルにおいて再生を行った場合、次のような条件を満たせば、トラックバッファ５０２のアンダーフローがないことが保証できる。
【０１１６】
条件を示す前にまず、記号を定義する。ＡＶストリームを構成するｉ番目の連続領域をＣ♯ｉとし、Ｃ♯ｉ中に含まれる再生時間をＴｃ(i) とする。Ｔｃ(i) は、Ｃ♯ｉ中に先頭が含まれているＶＵの再生時間の合計とする。また、Ｃ♯ｉからＣ♯ｉ＋１へのアクセス時間をＴａとする。
【０１１７】
また、再生時間Ｔｃ(i) 分のＶＵ読み出し時間をＴｒ(i) とする。この場合、トラックバッファ５０２をアンダーフローさせない条件とは、分断ジャンプを含めた最大読み出し時間をＴｒ(i) としたとき、任意のＣ♯ｉにおいて、
Ｔｃ(i) ≧Ｔｒ(i) ＋Ｔａ …式１
が成立することである。
【０１１８】
なぜなら、この式はシームレス再生の十分条件である、
【０１１９】
【数１】
【０１２０】
を満たす十分条件であるためである。
【０１２１】
式１中のＴｒ(i) に、Ｔｒ(i) ＝Ｔｃ(i) ×（Ｒｖ＋Ｒａ）／Ｒｓを代入して、Ｔｃ(i) で解くと、シームレス再生を保証可能なＴｃ(i) の条件
Ｔｃ(i) ≧（Ｔａ×Ｒｓ）／（Ｒｓ−Ｒｖ−Ｒａ） …式２
が得られる。ここで、Ｒａはオーディオデータのビットレートであり、Ｒｖはビデオデータのビットレートである。
【０１２２】
つまり、各連続領域に先頭の含まれるＶＵの合計が上式を満たすようにすれば、シームレス再生を保証可能である。このとき、各連続領域には合計の再生時間が上式を満たす完全なＶＵ群を含むように制限してもよい。
【０１２３】
＜録画時の処理＞
ユーザから録画が指示された場合のホストＣＰＵ１０１が前述のデータ記録プログラムを実行することによって実現される処理を、図２７を参照しながら説明する。
【０１２４】
このとき記録するＡＶストリームは、ビデオのビットレートＲｖの上限が５Mbpsであり、オーディオのビットレートＲａが２５６kbpsであり、ＶＵ再生時間Ｔｖが約０．５秒固定ストリームであるとする。また、ファイルシステムの管理情報はすでにＲＡＭ１０２上に読み込まれているものとする。
【０１２５】
まず、ストリームの構成や連続領域の構成を決定する（Ｓ７０１）。ここでは、１ＶＵを１ＧＯＰ１５フレームで構成するとしたとき、式２にＲｓ＝２０Mbps、Ｔａ＝１秒、Ｒｖ＝５Mbps、Ｒａ＝２５６kbpsを代入し、Ｔ(c) の範囲１．４秒以上が得られる。Ｔｖが約０．５秒であるため、ＣＵは３個のＶＵで構成すればよい。
【０１２６】
まず、ＲＡＭ１０２上のSpace Bitmapを参照して９個のＶＵを連続的に記録可能な空き領域を探す。空き領域が存在しなければ、録画を中止し、録画できないことをユーザに知らせる（Ｓ７０２）。
【０１２７】
また、オーディオエンコーダ１１７およびビデオエンコーダ１１８をそれぞれ起動する（Ｓ７０３）。そして、記録用バッファ１１４に１ＥＣＣブロック分（例えば３２KB）以上のデータが蓄積されているか否かをチェックする（Ｓ７０４）。
【０１２８】
１ＥＣＣブロック分以上のデータが蓄積されていれば、次に記録するディスク上のＥＣＣブロックの空き状況をＲＡＭ１０２上のSpace Bitmapを参照して調べる（Ｓ７０５）。ＥＣＣブロックの空きがなければ、３個のＶＵを記録可能な連続的な空き領域を探し（Ｓ７０６）、その空き領域の先頭へピックアップを移動させる（Ｓ７０７）。
【０１２９】
そして、記録用バッファ１１４中の１ＥＣＣブロック分のデータをディスクに記録して（Ｓ７０８）、処理をＳ７０４に戻す。また、Ｓ７０５でＥＣＣブロックの空きがあれば、Ｓ７０８の記録を行う。Ｓ７０５〜Ｓ７０８の処理は、Ｓ７０４で１ＥＣＣブロック分以上のデータが蓄積されていないと判定されるまで繰り返される。一方、Ｓ７０４で記録用バッファ１１４に１ＥＣＣブロック分のデータが蓄積されていないと判定されると、記録終了が指示されているかどうかをチェックし（Ｓ７０９）、記録終了が指示されていない場合はＳ７０４を実行する。
【０１３０】
Ｓ７０９で記録終了が指示されていた場合、以下のステップを実行する。まず、記録用バッファ１１４における１ＥＣＣブロックに満たないデータに関して、末尾にダミーデータを付加し１ＥＣＣブロックにする（Ｓ７１０）。次に、Ｓ７０５〜Ｓ７０８と同様にして、そのデータをディスク上に記録する（Ｓ７１１〜Ｓ７１４）。ＲＡＭ１０２上の QuickTime管理情報（Movie atom）とファイルシステム管理情報とを光ディスク１０６に記録して（Ｓ７１５，７１６）、処理を終える。
【０１３１】
以上の処理と並行するオーディオエンコーダ１１７、ビデオエンコーダ１１８やマルチプレクサ１１３の動作について説明する。ビデオエンコーダ１１８およびオーディオエンコーダ１１７がエンコードした結果は、それぞれビデオ記録用バッファ１１８およびオーディオ記録用バッファ１１９に一時的に蓄えられる。マルチプレクサ１１３は、ビデオ記録用バッファ１１８およびオーディオ記録用バッファ１１９からそれぞれデータを読み出し、それらの多重化を行い、記録用バッファ１１４に格納する。
【０１３２】
１ＶＵ分のデータ、つまり１ＧＯＰとそれに同期して再生されるＡＡＵが記録用バッファ１１４に蓄積されたら、マルチプレクサ１１３は記録用バッファ１１４に１ＶＵのデータを送る。
【０１３３】
さらに、マルチプレクサ１１３が、ホストＣＰＵ１０１に１ＶＵ分のデータがエンコードできたことを通知すると、ホストＣＰＵ１０１はＶＵを構成するＧＯＰやＡＡＵの数およびサイズを基にＲＡＭ１０２上の QuickTime管理情報を更新する。
【０１３４】
＜ＴＳ変換時の処理＞
本実施形態におけるＴＳ変換時の処理を説明する。まず、ここでは、ビデオおよびオーディオそれぞれのＴＳパケット生成手順について説明した後、それらを多重化してＴＳを出力する手順について説明する。
【０１３５】
なお、ＴＳ変換を開始する時点に変換対象のムービーファイルのMovie atomの内容はＲＡＭ１０２に読み込まれているとする。
【０１３６】
（１）ビデオＴＳパケット生成
まず、前述のビデオＰＥＳパケット生成部１１０１、ビデオＴＳパケット生成部１１０２およびビデオ解析部１１３１によるビデオＴＳパケットの生成手順を図２８を用いて説明する。
【０１３７】
ここでは、図２８に示すように、エレメンタリストリームとしてのＡＶストリーム中のｉ番目のビデオチャンクに対応するビデオデータをビデオチャンクVChunk(i) と称し、ＡＶストリーム中のｊ番目のオーディオチャンクに対応するオーディオデータをオーディオチャンクAChunk(j) と称する。以下の説明では、ビデオチャンクVChunk(i) を例に挙げる。VChunk(i) のトラック上での再生時刻は、Movie atom（図３参照）の情報から取得することができ、それをＴｖ(i) とする。
【０１３８】
ビデオＰＥＳパケット生成部１１０１は、ビデオ再生用バッファ１１０から読み出されたビデオエレメンタリストリームにおけるビデオチャンクVChunk(i) をビデオフレーム単位（ビデオフレームデータ）に分割する。ビデオチャンクVChunk(i) を構成するビデオフレーム数がＮ(i) であるとき、それらのビデオフレームデータをVFRM(i,0) ，VFRM(i,1) ，…，VFRM(i,N(i)-1)と称する。ビデオフレームの境界は、図２２に示すビデオ解析部１１３１がVChunk(i) を解析し、picture＿header()を検出することで得られる。なぜなら、ビデオフレームデータの先頭には、picture＿header()が存在するため、picture＿header()を検出することは、ビデオフレームデータの先頭位置すなわち境界位置を得ることになる。なお、picture＿header()の先頭は、特性のビットパターンであるため、ビデオエレメンタリストリーム中から容易に検出することができる。また、ビデオ解析部１１３１は、その解析の際、前述のpicture＿header()から、各フレームのピクチャタイプ（Ｉ，Ｐ，Ｂ）も同時に取得する。
【０１３９】
また、ビデオＰＥＳパケット生成部１１０１は、各ビデオフレームデータの先頭データが前述のＶＢＶバッファに入ってからデコードを行うまでの遅延量を求める。ｎ番目のビデオフレームデータの遅延量をＶＤＥＬＡＹ(i,n) と称し、ｎ番目のビデオフレームデータのpicture header()中のvbv＿delay を用いる。また、ビデオＰＥＳパケット生成部１１０１は、このビデオストリーム中での最大ビットレートを示す、sequence header() 中のbitrateを取得し、変数Ｒmax に格納する。
【０１４０】
次に、ビデオＰＥＳパケット生成部１１０１は、ビデオフレームデータをＰＥＳパケットにパケット化する。ＰＥＳパケットVPKT(i,0) ，VPKT(i,1) ，…，VPKT(i,N(i)-1)は、ビデオフレームデータVFRM(i,0) ，VFRM(i,1) ，…，VFRM(i,N(i)-1)から、それぞれ一対一の対応で生成される。
【０１４１】
各ＰＥＳパケットのヘッダ部分には、ビデオデータであることの属性を表すstream id やＰＴＳ(Presentation Time Stamp) およびＤＴＳ(Decording Time Stamp)の２種類のタイムスタンプが設定される。このうち、stream id には１１１０００００ｂが設定される。また、ｎ番目のＰＥＳパケットのＰＴＳ，ＤＴＳをそれぞれＶＰＴＳ(i,n)，ＶＤＴＳ(i,n) と呼ぶとき、ＶＰＴＳ(i,n) ，ＶＤＴＳ(i,n) は次のルールで設定される。
【０１４２】
なお、各フレームの後に連続するＢピクチャの個数をｂ(n) と呼ぶ。例えば、Ｉ，Ｂ，Ｂ，Ｐ，…のピクチャが連続するＧＯＰ構成の場合、０番目のビデオフレームであるＩピクチャに対するｂ(0) は２となる。また、ビデオフレーム周期を９kHz クロックでカウントした値をＴｆとする。まず、VChunk(i) 中にＢピクチャが存在する場合は、ＩピクチャおよびＰピクチャに対し、
ＰＴＳ(i,n) ＝Ｔｖ(i) ＋（ｎ＋ｂ(n) ）×Ｔｆ
ＤＴＳ(i,n) ＝Ｔｖ(i) ＋（ｎ−１）×Ｔｆ
を設定し、Ｂピクチャに対し、
ＰＴＳ(i,n) ＝Ｔｖ(i) ＋（ｎ−１）×Ｔｆ
ＤＴＳ(i,n) ＝Ｔｖ(i) ＋（ｎ−１）×Ｔｆ
を設定する。一方、VChunk(i) 中にＢピクチャが存在しない場合、各ビデオフレームに対し、
ＰＴＳ(i,n) ＝ＤＴＳ(i,n) ＝Ｔｖ(i) ＋ｎ×Ｔｆ
を設定する。
【０１４３】
次に、ビデオＴＳパケット生成部１１０２によるＴＳパケットの生成について説明する。
【０１４４】
ビデオＴＳパケット生成部１１０２は、各ＰＥＳパケットを先頭から１８４バイト単位で所定の大きさに分割し、分割されたデータの直前にＴＳパケットのヘッダを４バイト付加することによってＴＳパケットを生成する。ここで、図２８に示すように、ｎ番目のビデオＰＥＳパケットであるVPKT(i,n) からＫ(i,n) 個のＴＳパケットが生成される場合、それぞれのＴＳパケットをVTSP(i,n,0) ，VTSP(i,n,1) ，…，VTSP(i,n,K(i,n)-1)と称する。
【０１４５】
このとき、ビデオＴＳパケット生成部１１０２は、それぞれのＴＳパケットに対し、理想的なＰＣＲ(System Clock Reference)を付与する。このＰＣＲの値は、ＴＳパケット中には格納されず、あくまでも後段のＴＳパケット多重化の際の多重タイミング設定の指標に用いるための情報である。ここで、ｋ番目のＴＳパケットに対応する理想的なＰＣＲをＶＰＣＲ(i,n,k) とする。ｋ＝０の場合、
ＶＰＣＲ(i,n,k) ＝ＤＴＳ(i,n) −ＶＤＥＬＡＹ(i,n)
とする。一方、０＜ｋ＜Ｋ(i,n) の場合、
ＶＰＣＲ(i,n,k) ＝ＶＰＣＲ(i,n,0) ＋１８４×８×ｋ×27000000/Ｒmax
とする。
【０１４６】
また、ビデオＴＳパケットのヘッダ中の各フィールドには次のように値を設定する。例えば、パケットを識別するためのＰＩＤ(Packet Identification) に０ｘ１０１１を格納し、ＴＳパケットがＰＥＳパケットの先頭バイトを含んでいた場合、ペイロード(payload unit start indicator)に１をセットする。
【０１４７】
生成されたビデオＴＳパケットは、上記のＶＰＣＲを付与された状態でビデオＴＳパケット用バッファ１１０３に順に送られ、図２８に示すように、ビデオチャンクやビデオフレームの区別が取り去られて一次元でアクセス可能になる。すなわち、ビデオＴＳパケット総数をVCOUNTとすると、生成された順にＶＴＳＰ(0) ，ＶＴＳＰ(1) ，…，ＶＴＳＰ(VCOUNT-1)と呼ぶことになる。
【０１４８】
（２）オーディオＴＳパケット生成
続いて、前述のオーディオＰＥＳパケット生成部１１１１およびオーディオＴＳパケット生成部１１１２によるオーディオＴＳパケットの生成手順を図２９を用いて説明する。
【０１４９】
図２９に示すように、ＡＶストリーム中のｊ番目のオーディオチャンクに対応するオーディオデータをAChunk(j) と称する。以下の説明では、オーディオチャンクAChunk(j) を例に挙げる。AChunk(j) のトラック上での再生時刻は、オーディオデータを管理しているトラックのsample table atom （図７参照）を参照することで取得可能であり、sample table atom を含むMovie atom（図３参照）の情報から取得することができ、それをＴｐ(j)とする。
【０１５０】
オーディオＰＥＳパケット生成部１１１１は、オーディオ再生用バッファ１１１から読み出されたオーディオエレメンタリストリームにおけるオーディオチャンクAChunk(j) をオーディオフレーム単位（オーディオフレームデータ）に分割する。分割のために必要な情報は、AChunk(j) を構成する各オーディオフレームのデータ長である。各オーディオフレームのデータ長は、オーディオデータを管理しているトラックのsample size atom（図９参照）を参照することで取得可能である。オーディオチャンクAChunk(j) を構成するオーディオフレーム数がＭ(j) であるとき、それらのオーディオフレームデータをAFRM(j,0) ，AFRM(j,1) ，…，AFRM(j,M(j)-1)と称する。また、ｍ番目のオーディオフレームのデータ長をAFLEN(j,m)とする。
【０１５１】
次に、オーディオＰＥＳパケット生成部１１１１は、オーディオフレームデータをＰＥＳパケットにパケット化する。ＰＥＳパケットAPKT(j,0) ，APKT(j,1) ，…，APKT(j,M(i)-1)は、オーディオフレームデータAFRM(j,0) ，AFRM(j,1) ，…，AFRM(j,M(j)-1)から、それぞれ一対一の対応で生成される。
【０１５２】
各ＰＥＳパケットのヘッダ部分には前述のstream idやＰＴＳが設定される。このうち、stream idには１１００００００が設定される。また、ｍ番目のＰＥＳパケットのＰＴＳをＡＰＴＳ(j,m) と呼び、オーディオフレーム周期を９KHzクロックでカウントした値をＴafとしたときＡＰＴＳ(j,m) は、
ＡＰＴＳ(j,m) ＝Ｔｐ(j) ＋ｍ×Ｔaf
とする。上記のＴafは、Sample tableから取得することが可能である。
【０１５３】
次に、オーディオＴＳパケット生成部１１１２によるＴＳパケットの生成について説明する。
【０１５４】
オーディオＴＳパケット生成部１１１２は、各ＰＥＳパケットを先頭から１８４バイト単位で所定の大きさ分割し、分割されたデータの直前にＴＳパケットのヘッダを４バイト付加することによってＴＳパケットを生成する。ここで、図２９に示すように、ｎ番目のオーディオＰＥＳパケットであるAPKT(j,m) からＨ(j,m) 個のＴＳパケットが生成される場合、それぞれのＴＳパケットをATSP(j,m,0) ，ATSP(j,m,1) ，…，ATSP(j,m,H(j,m)-1)と称する。
【０１５５】
このとき、前述のビデオＴＳパケットの生成時と同様、それぞれのＴＳパケットに対し、理想的なＰＣＲを付与する。このＰＣＲの値は、ＴＳパケット中には格納されず、あくまでも後段のＴＳパケット多重化の際の多重タイミング設定の指標に用いるための情報である。ここで、ｈ番目のＴＳパケットに対応する理想的なＰＣＲをＡＰＣＲ(j,m,h) とする。ｈ＝０の場合、オーディオのビットレートをＲａとしたとき、
ＡＰＣＲ(j,m,h) ＝ＡＰＴＳ(j,m) −ＡＦＬＥＮ(j,m) ×８×２／Ｒａ
にする。一方、０＜ｈ＜Ｈ(j,m) の場合、
ＡＰＣＲ(j,m,h) ＝ＡＰＣＲ(j,m,0) ＋１８４×８×ｈ×27000000／Ｒａ
とする。上記のＲａは、Sample table中のサンプルのdurationとsizeとから求めることが可能である。
【０１５６】
また、オーディオＴＳパケットのヘッダ中の各フィールドには次のように値を設定する。例えば、ＰＩＤには、０ｘ１０２１を格納し、ＴＳパケットがＰＥＳパケットの先頭バイトを含んでいた場合、前述のペイロードに１をセットする。
【０１５７】
生成されたオーディオＴＳパケットは、上記のＡＰＣＲを付与された状態でオーディオＴＳパケット用バッファ１１１３に順に送られ、図２９に示すように、オーディオチャンクやオーディオフレームの区別が取り去さられて一次元でアクセス可能になる。すなわち、オーディオＴＳパケット総数をACOUNTとすると、生成された順にＡＴＳＰ(0) ，ＡＴＳＰ(1) ，…，ＡＴＳＰ(ACOUNT-1)と呼ぶことになる。
【０１５８】
（３）ＴＳパケット多重化
上記のようにして生成されたビデオおよびオーディオのＴＳパケットからＴＳマルチプレクサ１１２１によってＴＳを生成するための手順を、図３０に示すフローチャートを用いて説明する。
【０１５９】
まず、現在の処理対象のＴＳパケットのカウンタ値ＳＴＣを初期化する（Ｓ１１０１）。初期化には、ＶＰＣＲおよびＡＰＣＲのうち最も値の小さいものを用いる。次に、ビデオＴＳパケット用バッファ１１０３に蓄えられているビデオＴＳパケットおよびオーディオＴＳパケットバッファ１１１３に蓄えられているオーディオＴＳパケットをそれぞれ指定するためのインデックスであるvindexおよびaindexをリセットする（Ｓ１１０２）。そして、以下の処理をビデオＴＳパケット用バッファ１１０３およびオーディオＴＳパケット用バッファ１１１３が空になるまで、すなわちvindexまたはaindexが所定値のVCOUNTまたはACOUNTに達するまで行う（ステップＳ１１０３）。
【０１６０】
まず、ＰＣＲおよびＳＩ(Service Information) やＰＳＩ(Program Specific Information)を挿入するタイミングをチェックし（Ｓ１１０４）、現在のＳＴＣがＰＣＲ／ＰＳＩ／ＳＩを挿入するタイミングであるか否かをチェックする（Ｓ１１０５）。ＰＣＲを挿入する間隔は、ＭＰＥＧ規格によって、０．１秒以下に規定されている。また、ＳＩ／ＰＳＩの挿入間隔についてもＡＲＩＢ(Association of Radio Industries and Buisiness) ＳＴ-Ｂ２１によって規定されている。したがって、前回挿入したときのＳＣＲの値を記憶しておき、前回のＳＴＣ値と現在のＳＴＣ値の差分が０．１秒になったときが挿入するタイミングとなる。もし、挿入するタイミングであった場合、ＴＳパケットを生成しＰＣＲ／ＰＳＩ／ＳＩの挿入を行う（ステップＳ１１０６）。ＰＣＲを含むＴＳパケットの場合、ＰＣＲには現在のＳＴＣの値を設定する。
【０１６１】
Ｓ１１０５で、挿入するタイミングでなかった場合、次に、aindexで指し示されるＡＴＳＰのＡＰＣＲの値がＳＴＣの値以上であるか否かを調べる（Ｓ１１１１）。ＡＰＣＲの値がＳＴＣの値以上であった場合、ＡＴＳＰ(aindex)を出力し（Ｓ１１１２）、aindexをインクリメントする（Ｓ１１１３）。
【０１６２】
Ｓ１１１１で、ＡＰＣＲの値がＳＴＣの値未満であった場合（ＡＴＳＰを出力するタイミングでなかった場合）、vindexで指し示されるＶＴＳＰのＶＰＣＲの値がＳＴＣの値以上であるか否かを調べる（Ｓ１１２１）。ＶＰＣＲの値がＳＴＣの値以上であった場合、ＶＴＳＰ(vindex)を出力し（Ｓ１１２２）、vindexをインクリメントする（Ｓ１１２３）。
【０１６３】
Ｓ１１２１で、ＶＰＣＲの値がＳＴＣの値未満であった場合（現在のＳＴＣの値が何も出力するタイミングでなかった場合）、null packet を出力する（Ｓ１１３１）。
【０１６４】
そして、何らかのＴＳパケットを出力したら、ＳＴＣをインクリメントする(Ｓ１１０７)。ＳＴＣのインクリメント量は、ＴＳ転送用に確保したビットレートによって決定される。ＴＳ転送用のビットレートを２７Mbpsと設定しており、インクリメント量ΔＳＣＲは１５０４となる。
【０１６５】
＜ＰＳ変換時の処理＞
本実施形態では、DVD-Video やDVD-Video Recording 規格を想定して１パックが２０４８バイトになるようにＥＳ−ＰＳ変換を行う。
【０１６６】
なお、変換対象のムービーファイルのMovie atomの内容はＲＡＭ１０２に読み込まれているとする。
【０１６７】
（１）ビデオパック生成
まず、前述のビデオＰＥＳパケット生成部１１０１およびビデオパック生成部１１０４によるビデオパックの生成手順を図３１を用いて説明する。
【０１６８】
図３１に示すように、ＡＶストリーム中のｉ番目のビデオチャンクに対応するビデオデータをVChunk(i) と称する。以下の説明では、ビデオチャンクVChunk(i)を例に挙げる。VChunk(i) のトラック上での再生時刻はMovie atomの情報から取得することができ、それをＴｖ(i) とする。
【０１６９】
ビデオＰＥＳパケット生成部１１０１は、前述のビデオＴＳパケット生成の場合と同様にビデオチャンクVChunk(i) をビデオフレーム単位に分割する。このときの手順はＴＳ生成処理と同一であるため、説明を省略する。また、ビデオＰＥＳパケット生成部１１０１は、ビデオフレームデータをＰＥＳパケットにパケット化する。ＰＥＳパケットは、ビデオフレームデータVFRM(i,0) ，VFRM(i,1) ，…，VFRM(i,N(i)-1)から、それぞれ複数生成される。
【０１７０】
ここでは、ｎ番目のビデオフレームデータを例に挙げて説明する。VFRM(i,n)の先頭から、２０３４バイト単位でデータを切り出し、パケットに格納する。ただし、先頭だけはＰＴＳおよびＤＴＳを格納する空間が必要であるために２０１９バイトでデータを切り出す。さらに、VFRM(i,0) の先頭については、２４バイトのシステムヘッダ(System Header) を挿入する必要があるため、さらに短い１９９５バイトでデータ切り出す。生成されたパケット数がＧ(i,n)個であるとき、ＰＥＳパケットとしてVPKT(i,n,0) ，VPKT(i,n,1) ，…，VPKT(i,n,G(i,n)-1)が生成される。このうち、先頭のパケットとしてのVPKT(i,n,0) には、ＰＴＳおよびＤＴＳを設定する必要があり、設定する値については、前述のＴＳ変換の場合について説明したルールで計算する。
【０１７１】
次に、ビデオパック生成部１１０４によるビデオパックの生成について説明する。
【０１７２】
ビデオパック生成部１１０４は、所定数のＰＥＳパケットを１４バイトのパックヘッダの後に格納してグループ化し、VChunk(i) の先頭のVPKT(i,0,0) の場合、パックヘッダとＰＥＳパケット群との間に前記のシステムヘッダを挿入する。ここで、ｇ番目のビデオＰＥＳパケットVPKT(i,n,g) に対応するビデオパックをVPCK(i,n,g) と称する。
【０１７３】
このとき、ビデオパック生成部１１０４は、それぞれのパックのパックヘッダに対し、以下のような計算で求めたＳＣＲを格納する。このＳＣＲの値は、ＰＳ多重化の際に実際の値に書き換えられる。ここで、ｇ番目のパックに対応する、計算上のＳＣＲをＶＰＣＲ(i,n,g) とする。ｋ＝０の場合、
ＶＳＣＲ(i,n,g) ＝ＤＴＳ(i,n) −ＶＤＥＬＡＹ(i,n)
とする。一方、０＜ｇ＜Ｇ(i,n) の場合、
ＶＳＣＲ(i,n,g) ＝ＶＰＣＲ(i,n,0) ＋２０４８×８×ｋ×27000000/Ｒmaxとする。また、パックヘッダ中の、多重化ビットレートを示すフィールドprogram mux rateには、１００８Mbpsを示す０ｘ０１８９ｃ３を格納する。
【０１７４】
生成されたビデオパックは、上記のＶＳＣＲを付与された状態でビデオパック用バッファ１１０５に順に送られ、図３１に示すように、ビデオチャンクやビデオフレームの区別が取り去さられて一次元でアクセス可能になる。すなわち、ビデオパック総数をVCOUNTとすると、生成された順にＶＰＣＫ(0) ，ＶＰＣＫ(1) ，…，ＶＰＣＫ(VCOUNT-1)と呼ぶことになる。
【０１７５】
（２）オーディオパック生成
続いて、前述のオーディオＰＥＳパケット生成部１１１１およびオーディオパック生成部１１１４によるオーディオパックの生成手順を図３２を用いて説明する。
【０１７６】
図３２に示すように、ＡＶストリーム中のｊ番目のオーディオチャンクに対応するオーディオデータをAChunk(j) と称する。以下の説明では、オーディオチャンクAChunk(j) を例に挙げる。AChunk(j) のトラック上での再生時刻はMovie atomの情報から取得することができ、それをＴｐ(j) とする。
【０１７７】
オーディオＰＳパケット生成部１１１１は、前述のオーディオＴＳパケット生成の場合と同様に、オーディオチャンクAChunk(j) をオーディオフレーム単位に分割する。このときの手順は、ＴＳ生成処理の場合と同一であるため、その説明を省略する。また、オーディオＰＳパケット生成部１１１１は、オーディオフレームデータをＰＥＳパケットにパケット化する。ＰＥＳパケットは、オーディオフレームデータAFRM(j,0) ，AFRM(j,1) ，…，VFRM(j,M(i)-1)からそれぞれ複数生成される。
【０１７８】
ここでは、ｍ番目のオーディオフレームデータを例に挙げて説明する。AFRM(j,m)の先頭から、２０２５バイト単位でデータを切り出し、パケットに格納する。ただし、先頭だけはＰＴＳを格納する空間が必要であるために２０２０バイトでデータを切り出す。生成されたパケット数がＨ(j,m) 個であるとき、ＰＥＳパケットとしてAPKT(j,m,0) ，APKT(j,m,1) ，…，APKT(j,m,H(j,m)-1)が生成される。このうち、先頭のパケットであるAPKT(i,n,0) には、ＰＴＳを設定する必要があり、設定する値については、前述のＴＳ変換の場合について説明したルールで計算する。
【０１７９】
次に、オーディオパック生成部１１１４によるオーディオパックの生成について説明する。
【０１８０】
オーディオパック生成部１１１４は、所定数のＰＥＳパケットを１４バイトのパックヘッダの後に格納してグループ化する。ここで、ｇ番目のオーディオＰＥＳパケットAPKT(j,m,h) に対応するオーディオパックをAPCK(j,m,h) と称する。
【０１８１】
このとき、オーディオパック生成部１１１４は、それぞれのパックのパックヘッダに対し、以下のような計算で求めたＳＣＲを格納する。このＳＣＲの値は、ＰＳ多重化の際に実際の値に書き換えられる。ここで、ｈ番目のパックに対応する、計算上のＳＣＲをＡＰＣＲ(j,m,h) とする。ｈ＝０の場合、
ＡＳＣＲ(j,m,h) ＝ＡＰＴＳ(j,m) −ＡＦＬＥＮ(j,m) ×８×２／Ｒａ
にする。一方、０＜ｈ＜Ｈ(j,m) の場合、
ＡＳＣＲ(j,m,h) ＝ＡＳＣＲ(j,m,0) ＋２０４８×８×ｈ×27000000/Ｒａ
とする。また、パックヘッダ中の、多重化ビットレートを示すフィールドprogram mux rateには、１００８Mbpsを示す０ｘ０１８９ｃ３を格納する。
【０１８２】
生成されたオーディオパックは、上記のＡＳＣＲを付与された状態でオーディオパック用バッファ１１１５に順に送られ、図３２に示すように、オーディオチャンクやオーディオフレームの区別が取り去られて一次元でアクセス可能になる。すなわち、オーディオパック総数をACOUNTとしたとき、生成された順にＡＰＣＫ(0) ，ＡＣＰＫ(1) ，…，ＡＣＰＫ(ACOUNT-1)と呼ぶことになる。
【０１８３】
（３）パック多重化
以上のようにして生成されたビデオおよびオーディオのパックからＰＳマルチプレクサ１１２２によってＰＳを生成するための手順を、図３３に示すフローチャートを用いて説明する。
【０１８４】
まず、現在のカウンタ値ＳＴＣを初期化する（Ｓ１２０１）。初期化には、ＶＳＣＲおよびＡＳＣＲのうち最も値の小さいものを用いる。次に、ビデオパック用バッファ１１０５に蓄えられているビデオパックおよびオーディオパック用バッファ１１１５に蓄えられているオーディオパックをそれぞれ指定するためのインデックスであるvindexおよびaindexをリセットする（Ｓ１２０２）。そして、以下の処理をビデオパック用バッファ１１０５およびオーディオパック用バッファ１１１５が空になるまで、すなわちvindexまたはaindexが所定値のVCOUNTまたはACOUNTに達するまで行う（Ｓ１２０３）。
【０１８５】
まず、aindexで指し示されるオーディオパックＡＰＣＫのＡＳＣＲの値がＳＴＣの値以上であるか否かを調べる（Ｓ１２０４）。ＡＳＣＲの値がＳＴＣの値以上であった場合、ＡＰＣＫ(aindex)を出力し（Ｓ１２０５）、aindexをインクリメントする（Ｓ１２０６）。
【０１８６】
Ｓ１２０４で、ＡＰＣＫを出力するタイミングでなかった場合、vindexで指し示されるＶＰＣＫのＶＳＣＲの値がＳＴＣの値以上であるか否かを調べる（Ｓ１２１１）。ＶＳＣＲの値がＳＴＣの値以上であった場合、ＶＴＳＰ(vindex)を出力し（Ｓ１２１２）、vindexをインクリメントする（Ｓ１２１３）。
【０１８７】
なお、各パックの出力の際には、パックヘッダのＳＣＲの値を現在のＳＴＣの値に書き換える。
【０１８８】
次に、現在のＳＴＣに該当するパックの有無にかかわらず、ＳＴＣをインクリメントする(Ｓ１２０７)。ＳＴＣのインクリメント量は、転送ビットレートによって決定される。ここでは、DVD-Video を対象にしているため、転送用ビットレートを１００８Mbpsと設定しており、インクリメント量ΔＳＣＲは４３８７５となる。
【０１８９】
〔第２の実施形態〕
本発明の第２の実施形態について、図３４ないし図３６を用いて説明する。
【０１９０】
本実施形態は、ＴＳ／ＰＳ変換のために必要な情報をビデオデータを解析する必要がないように、ビデオデータ外にそれらの情報をあらかじめ記録しておく点が第１の実施形態と異なっている。本実施形態は、第１の実施形態と共通する部分が多いため、主に相違点について説明する。
【０１９１】
＜システム構成＞
図３４に示すように、本実施形態におけるビデオディスクレコーダのシステム構成は、第１の実施形態のシステム構成と、ビデオ解析部１１３１を備えていないことを除いてほぼ同一である。その他の構成要素は、第１の実施形態の構成要素と同じであり、同じ構成要素については共通の符号を用いている。
【０１９２】
＜ＡＶストリームの形態＞
図３５は、本実施形態におけるＡＶストリーム構成を示している。基本的には、第１の実施形態のＡＶストリーム構成（図２５参照）と同一であるが、ＶＵ７０３におけるオーディオデータとビデオデータとの間にＶＦＩ(Video Frame Information) ７０９というデータ領域が設けられている点で異なる。
【０１９３】
ＶＦＩ７０９については、図３６を用いて説明する。ＶＦＩ７０９には、この情報が含まれるＶＵ７０３の各ビデオフレームに関する情報が格納されている。ＶＦＩ７０９中のNumber of framesは、ＶＵ７０３中のビデオフレーム数を示す。１ＧＯＰを１サンプルで管理した場合、Movie atom中の情報から、ＶＵ７０３中の正確なビデオフレーム数が得られる保証はないため、この情報が必要である。また、fsize[i]にはＶＵ７０３中のｉ番目のビデオフレームデータに対応するデータサイズが、ftype[i]にはピクチャタイプが、vdelay[i]にはvbv＿delayがそれぞれ格納されている。また、ビデオデータのビットレートはbitrate に格納されている。このような管理情報をビデオデータ外に設けることで、ＴＳ／ＰＳ変換時にビデオデータを解析する必要がなくなる。これにより、第１の実施形態におけるビデオ解析部１１３１が不要となるので、システム構成が簡略化される。
【０１９４】
ＶＦＩ７０３は、オーディオデータとビデオデータとの間に挿入されている。これにより、ＡＶストリームデータの部分的な移動や削除の際、ＶＦＩ７０９のみが取り残される可能性が低くなる。また、直前のオーディオデータおよび直後のビデオデータの位置はSample tableから分かるため、ＶＦＩ７０９の記録位置を管理するために、ムービーファイル中に管理情報を新規に追加する必要がなくなる。また、ＶＦＩ７０９は、対応するビデオデータの直前に読み出されるので、対応するビデオデータが読み出されたら、直ちにＴＳへの変換のための処理を開始することが可能である。
【０１９５】
なお、本実施形態では、ビデオデータおよびＶＦＩ７０９は同一ファイルに格納されているが、本発明はそれに限定されるものではない。例えば、ビデオデータおよびＶＦＩ７０９が別ファイルであったとしても、ＶＦＩ７０９がビデオデータよりも先に読み出されるように配置されていれば同様の効果を達成できる。
【０１９６】
また、これらの情報をMovie atomではなくＡＶストリーム７０１内に記録することによって、通常再生の際にMovie atomをＲＡＭ１０２に保持するために必要なメモリ量を増大させることがない。
【０１９７】
また、ここでは、ＶＦＩ７０９中にピクチャタイプを記録しているが、ビデオデータのエンコードに際して両方向予測符号化を行わない場合には、ピクチャタイプは不要である。また、両方向予測符号化を行ったとしても、記録すべき情報はピクチャタイプに限定されない。例えば、フレーム間の表示順のようにピクチャタイプを導くことのできる情報であれば何でもよい。
【０１９８】
＜記録処理＞
本実施形態における記録処理は第１の実施形態の録画時の処理と同様であるが、ＡＣ（オーディオチャンク）７０８とＶＣ（ビデオチャンク）７０９との間にＶＦＩ７０９を挿入された状態で記録を行う点が異なる。また、第１の実施形態と異なり、ＶＢＲの場合でも、picture＿header()中のvbv＿delayに０ｘｆｆｆｆをセットしてもよい。なぜなら、vbv＿delayに想到する情報は、前述のＶＦＩ７０９に格納されているからである。
【０１９９】
＜ＴＳ変換時の処理＞
本実施形態におけるＴＳ変換時の処理は第１の実施形態と類似するため、主に相違点を説明する。
【０２００】
（１）ビデオＴＳパケット生成
まず、VChunk(i) の読み出し前に直前のＶＦＩ７０９が読み出されてＲＡＭ１０２に格納されているとする。
【０２０１】
VChunk(i) をビデオフレームデータに分解する際には、ＶＦＩ７０９におけるfsizeを利用する。また、各ビデオフレームデータのピクチャタイプは、ＶＦＩ７０９におけるftypeから直接取得することが可能である。また、VDELAYについてもＶＦＩ７０９におけるvdelayから直接取得することが可能である。またＲｘについてもＶＦＩ７０９におけるbitrateから直接取得することが可能である。このことは、ＶＦＩ７０９をビデオデータとは別にまとめて用意しておくことで、ビデオ解析部１１３１によりビデオデータを解析する必要がなくなったことを意味する。
【０２０２】
なお、「（２）オーディオＴＳパケット生成」および「（３）ＴＳパケット多重化」の処理は第１の実施形態での録画時の処理と同様であるため、その説明を省略する。
【０２０３】
＜ＰＳ変換時の処理＞
ビデオＴＳパケット生成と同様、ＶＦＩ７０９内の情報を用いることで、本処理に必要な各フレームのデータ量、ピクチャタイプおよびvbv＿delayの値を取得可能である。
【０２０４】
＜バリエーション＞
本実施形態では、vbv＿delayに相当する値をＡＶストリーム７０１におけるＧＯＰ７０３外に記録しているが、Movie atom中の例えばUser data atomに記録したとしても、同様の効果が得られる。また、フレーム毎のデータ量やピクチャタイプに関する情報についても同様である。また、ＶＦＩ７０９におけるbitrateは、固定ビットレートの場合はsample tableから算出できるため特に記録する必要はない。また、記録する場合もMovie atom中に記録しても同様の効果が得られることは言うまでもない。
【０２０５】
〔第３の実施形態〕
＜システム構成＞
本実施形態におけるシステム構成は第２の実施形態と共通であるため、その説明を省略する。
【０２０６】
＜ＡＶストリーム管理方法＞
上記のＡＶストリームの管理情報の構成について説明する。ＡＶストリームは、図３７に示すように、ムービーファイル２４０１と、ムービーファイル２４０２とで管理される。
【０２０７】
ムービーファイル２４０１は、Movie data atomに格納された前述のＡＶストリーム７０１（図２３参照）と、ＡＶストリーム７０１を構成するサンプルのアドレスやサイズ、再生時間等を管理するMovie atomとで構成される。ＡＶストリーム７０１は、前述のように、ＣＵ７０２で構成され、各ＣＵ７０２は必ず光ディスク１０６上で連続的に配置されるように記録される。
【０２０８】
一方、ムービーファイル２４０２は、ムービーファイル２４０１における各ＣＵ７０２を管理するｍｏｏｆ(Movie fragment atom) ７１０で構成される。
【０２０９】
この２つのファイル２４０１，２４０２は、図３７に示すように、ＣＵ７０２単位で多重化されて、光ディスク１０６上に連続して記録される。ムービーファイル２４０１では１個のＧＯＰ７０４を１サンプルと扱っているのに対し、ムービーファイル２４０２ではビデオフレームを１サンプルとして扱う。そのため、ムービーファイル２４０１の管理情報に比べ、ムービーファイル２４０２の管理情報量は多くなる。
【０２１０】
また、ビデオフレーム間のフレーム順の入れ替わりを管理するため、前述のsample-composition-time-offsetを用いる。すなわち、sample-durationとsample-composition-time-offsetから、各サンプルのデコードタイミングと表示タイミングが分かる。このことは、各サンプル（ビデオフレーム）のピクチャータイプが分かることを意味する。
【０２１１】
また、ビデオトラックを管理するTrack fragment atomに前記のvbv＿delayを管理するために、独自管理情報であるVBV delay atomを追加定義する。図３８にVBV delay atomの構成を示すように、Track fragment atomで管理されるビデオフレームのvbv＿delayの値を順に格納したものである。なお、このatomは一般のプレーヤでは無視されることになる。
【０２１２】
このように、管理情報をサイズ（大きさ）が異なるサンプルについて２個用意することによって、専用プレーヤで再生するときには、必要なメモリ容量の少ないムービーファイル２４０１を用い、汎用のQuickTime （あるいはISO base media file format）対応プレーヤで再生するときには、ムービーファイル２４０２を用いることで、省メモリと再生互換性とを両立することが可能となる。
【０２１３】
＜記録時の処理＞
本実施形態における記録時の処理は第１の実施形態での録画時の処理と共通しているが、Movie fragmentをContinuous Unit毎に記録する点が異なる。また、第１の実施形態と異なり、ＶＢＲの場合でも、picture＿header()中のvbv＿delayに０ｘｆｆｆｆをセットしてもよい。なぜなら、vbv＿delayに想到する情報は、前述のVBV delay atomに格納されているからである。
【０２１４】
＜ＴＳ変換時の処理＞
（１）ビデオＴＳパケット生成
まず、VChunk(i) の読み出し前に、VChunk(i) に対応するMovie fragment atom ７１０は読み出されてＲＡＭ１０２に格納されているとする。
【０２１５】
本実施形態でVChunk(i) をビデオフレームデータに分解する際には、Track fragment run atom中のsample-sizeから取得した各ビデオフレームデータのデータ量を用いる。また、各ビデオフレームデータのピクチャタイプは次のように取得できる。
【０２１６】
まず、Track fragment run atom 中のsample-composition-time-offset が０のものはＢピクチャと判断できるが、０でなかった場合、Track fragment run atom 中のsample flag を見る。sample flag 中には、対応するサンプル画、キーフレームであるか否かのフラグがあり、そのフラグが１の場合はＩピクチャと判断でき、そうでない場合はＰピクチャと判断できる。また、ＶＤＥＬＡＹについては、Track fragment atom 中のVBV delay atomの値から直接取得可能である。つまり、第２実施形態と同様、ビデオ解析部１１３１によりビデオデータを解析する必要が無い。以下の「（２）オーディオＴＳパケット生成処理」および「（３）ＴＳパケット多重化」の処理は第１の実施形態での処理と同様であるため、その説明を省略する。
【０２１７】
＜ＰＳ変換時の処理＞
ＰＳ変換時の処理は第１の実施形態の処理とほぼ同様であるため、主に異なる点について説明する。
【０２１８】
（１）ビデオパック生成
ビデオＴＳパケット生成と同様、Track fragment atom中の情報を用いることで、本処理に必要な各フレームのデータ量、ピクチャタイプおよびVBV delayの値を取得可能である。
【０２１９】
（２）オーディオパック生成
第１の実施形態と同様であるため省略する。
【０２２０】
（３）パック多重化
第１の実施形態と同様であるため省略する。
【０２２１】
＜バリエーション＞
本実施形態では、vbv＿delayに相当する値をVBV delay atomとして管理情報に記録しているが、この記録は必須ではない。なぜなら、各ビデオフレームのピクチャタイプおよびデータ量を元に、ＶＢＶバッファの占有量をシミュレートすることで、ＭＰＥＧ規格に準拠したＴＳ／ＰＳを生成できるからである。ただし、その場合、シミュレーションに伴う処理の複雑化が生じる。
【０２２２】
なお、以上に述べた各実施形態では、光ディスク１０６にＡＶストリームを記録することについて説明してきたが、ＡＶストリームを記録する記録媒体としては、光ディスクに限らず、ランダムアクセス可能な記録媒体であれば、例えばハードディスクや半導体メモリであってもよい。
【０２２３】
〔他の実施形態〕
本発明の実施形態の記録方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含むＡＶストリームと、ＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報（Movie atom 等）を記録媒体に記録する記録方法であって、ＡＶストリーム中に、個々の前記第１のユニットに関する第２の管理情報を記録し、第２の管理情報（Video Frame Information）は、対応する第１のユニットを構成するＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２２４】
また、前記記録方法では、第２の管理情報のデータフォーマットにISO base media file formatにおけるMovie Fragment（Movie Fragment atom）を用いることが好ましい。
【０２２５】
また、他の記録方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含むＡＶストリームと、ＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録する記録方法であって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記記録媒体に記録する。
【０２２６】
また、前記遅延時間はＡＶストリーム中に記録されることが好ましい。
【０２２７】
また、さらに他の記録方法は、ＡＶストリーム中に、個々の第１のユニットに関して第２の管理情報を記録し、第２の管理情報は、対応する第１のユニットを構成するＧＯＰを構成するビデオフレームデータ毎のデータ量および前記遅延時間を持つ。
【０２２８】
前記第２の管理情報は、対応する前記第１のユニットの物理的な近傍に配置されることが好ましい。
【０２２９】
前記各記録方法では、第２の管理情報と前記第１のＡＶストリームとを同一ファイルで管理し、前記第２の管理情報を対応するＧＯＰよりも低いアドレスに置くことが好ましい。
【０２３０】
前記記録方法では、前記遅延時間は少なくとも前記ＧＯＰ外に記録し、第１の管理情報は、ＧＯＰを構成するビデオフレームデータ毎のデータ量および遅延時間情報を持つことが好ましい。
【０２３１】
前記第１の管理情報は、ビデオフレーム間のピクチャタイプに関する情報を持つことが好ましい。前記第１の管理情報は、ＧＯＰを構成するビデオフレームデータ毎のデータ量および前記ビデオフレーム間のピクチャタイプに関する情報および前記遅延時間を持つことが好ましい。前記第２の管理情報は、ビデオフレーム間のピクチャタイプに関する情報を持つことが好ましい。
【０２３２】
本発明の実施形態のＡＶストリーム変換方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持記録媒体に関して、前記第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換方法であって、変換の際に、前記データ量に関する情報を用いる。
【０２３３】
また、他のＡＶストリーム変換方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、前記第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換方法であって、変換の際に、前記遅延時間を用いる。
【０２３４】
また、さらに他のＡＶストリーム変換方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とデータ量が記録されている記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換方法であって、変換の際に、前記遅延時間および前記データ量を用いる。
【０２３５】
また、さらに他のＡＶストリーム変換方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とデータ量とピクチャタイプに関する情報が記録されている記録媒体に関して、前記第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換方法であって、変換の際に、遅延時間および前記データ量およびピクチャタイプに関する情報を用いる。
【０２３６】
本願の実施形態の記録装置は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に前記第１のユニットに関する第１の管理情報を記録媒体に記録する記録装置であって、ＡＶストリーム中に、個々の前記第１のユニットに関する第２の管理情報を記録する手段を備え、第２の管理情報は、対応する第１のユニットを構成する前記ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２３７】
また、他の記録装置は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録する記録装置であって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記記録媒体に記録する手段を備える。
【０２３８】
本発明の実施形態のＡＶストリーム変換装置は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換装置であって、前記データ量に関する情報を用いる変換手段を備える。
【０２３９】
他のＡＶストリーム変換装置は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換装置であって、遅延時間を用いて変換する。
【０２４０】
本発明の実施形態の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録した記録媒体であって、ＡＶストリーム中に、個々の前記第１のユニットに関する第２の管理情報を記録し、第２の管理情報は、対応する第１のユニットを構成する前記ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２４１】
他の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報した記録媒体であって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を記録してある。
【０２４２】
本発明の実施形態のコンピュータプログラムは、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に前記第１のユニットに関する第１の管理情報を記録媒体に記録するステップを有するコンピュータプログラムであって、ＡＶストリーム中に、個々の第１のユニットに関する第２の管理情報を記録するステップを有し、第２の管理情報は、対応する第１のユニットを構成するＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２４３】
また、他のコンピュータプログラムは、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録するステップを有するコンピュータプログラムであって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記記録媒体に記録するステップを有する。
【０２４４】
また、さらに他のコンピュータプログラムは、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するステップを有するコンピュータプログラムであって、変換ステップが、前記データ量に関する情報を用いる。
【０２４５】
また、さらに他のコンピュータプログラムは、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するステップを有するコンピュータプログラムであって、変換ステップが遅延時間を用いる。
【０２４６】
本発明の実施形態の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、ＡＶストリーム中に、個々の第１のユニットに関する第２の管理情報を記録するステップを有し、第２の管理情報は、対応する第１のユニットを構成する前記ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２４７】
また、他の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を記録媒体に記録するステップを有する。
【０２４８】
また、さらに他の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、変換ステップがデータ量に関する情報を用いる。
【０２４９】
また、さらに他の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、変換ステップが遅延時間を用いる。
【０２５０】
また、データ変換装置およびデータ変換方法は、ビデオエレメンタリストリームにおけるデータ管理の最小単位である第１ビデオデータ単位の複数からなる第２ビデオデータ単位をビデオフレームデータに分割し、該ビデオフレームデータをパケット化して第１パケットを生成する第１パケット生成手段（処理）と、前記第１パケットを所定の大きさに分割して第１分割パケットを生成する第１分割パケット生成手段（処理）と、オーディオエレメンタリストリームにおけるデータ管理の最小単位である第１オーディオデータ単位の複数からなる第２オーディオデータ単位をオーディオフレームデータに分割し、該オーディオフレームデータをパケット化して第２パケットを生成する第２パケット生成手段（処理）と、前記第２パケットを所定の大きさに分割して第２分割パケットを生成する第２分割パケット生成手段（処理）と、前記第１および第２分割パケットを多重化して多重化ストリームを生成する多重化手段（処理）とを備えている。
【０２５１】
上記の構成では、第１パケット生成手段（処理）によって、QuickTime ファイルフォーマットのビデオエレメンタリストリームが第２ビデオデータ単位のビデオフレームデータに分割され、このビデオフレームデータを基に第１パケットが生成される。例えば、データ管理の最小単位である第１ビデオデータ単位はサンプルであり、第２ビデオデータ単位はチャンクである。そして、第１分割パケット生成手段（処理）によって、上記の第１パケットがさらに分割されて第１分割パケットが生成される。
【０２５２】
また、第２パケット生成手段（処理）によって、QuickTime ファイルフォーマットのオーディオエレメンタリストリームが第２オーディオデータ単位のオーディオフレームデータに分割され、このオーディオフレームデータを基に第２パケットが生成される。例えば、データ管理の最小単位である第１オーディオデータ単位はサンプルであり、第２オーディオデータ単位はチャンクである。そして、第２分割パケット生成手段（処理）によって、上記の第２パケットがさらに分割されて第２分割パケットが生成される。
【０２５３】
上記のようにして生成された第１および第２分割パケットは、多重化手段によって多重化され、その結果、ＭＰＥＧ２−ＴＳストリームとしての多重化ストリームが生成される。
【０２５４】
このように、QuickTime ファイルフォーマットのビデオエレメンタリストリームおよびオーディオエレメンタリストリームからＭＰＥＧ２−ＴＳストリームが得られる。それゆえ、QuickTime ファイルフォーマットのＡＶ(Audio and Visual)ストリームをＭＰＥＧ２−ＴＳのファイルフォーマットを採用する機器（IEEE-1394等）に転送することができる。
【０２５５】
他のデータ変換装置およびデータ変換方法は、ビデオエレメンタリストリームにおけるデータ管理の最小単位である第１ビデオデータ単位の複数からなる第２ビデオデータ単位をビデオフレームデータに分割し、該ビデオフレームデータをパケット化して第１パケットを生成する第１パケット生成手段（処理）と、複数の前記第１パケットをグループ化して第１パケット群を生成する第１パケット群生成手段（処理）と、オーディオエレメンタリストリームにおけるデータ管理の最小単位である第１オーディオデータ単位の複数からなる第２オーディオデータ単位をオーディオフレームデータに分割し、該オーディオフレームデータをパケット化して第２パケットを生成する第２パケット生成手段（処理）と、複数の前記第２パケットをグループ化して第２パケット群を生成する第２分割パケット群生成手段（処理）と、前記第１および第２パケット群を多重化して多重化ストリームを生成する多重化手段（処理）とを備えている。
【０２５６】
上記の構成では、第１パケット生成手段（処理）によって、前述のように、第１パケットが生成される。そして、第１パケット群生成手段（処理）によって、複数の第１パケットがグループ化されて第１パケット群が生成される。
【０２５７】
また、第２パケット生成手段（処理）によって、前述のように、第２パケットが生成される。そして、第２パケット群生成手段（処理）によって、複数の第２パケットがグループ化されて第２パケット群が生成される。
【０２５８】
上記のようにして生成された第１および第２パケット群は、多重化手段によって多重化され、その結果、ＭＰＥＧ２−ＰＳストリームとしての多重化ストリームが生成される。
【０２５９】
このように、QuickTime ファイルフォーマットのビデオエレメンタリストリームおよびオーディオエレメンタリストリームからＭＰＥＧ２−ＰＳストリームが得られる。それゆえ、QuickTime ファイルフォーマットのＡＶ(Audio and Visual)ストリームをＭＰＥＧ２−ＰＳのファイルフォーマットを採用する機器（ＤＶＤプレーヤ等）に転送することができる。
【０２６０】
前記の発明は、前記ビデオエレメンタリストリームと前記オーディオエレメンタリストリームとが多重化されてなるエレメンタリストリームを前記ビデオエレメンタリストリームと前記オーディオエレメンタリストリームとに分離してそれぞれを前記第１パケット生成手段（処理）と前記第２パケット生成手段（処理）とに与える分離手段（処理）を備え、前記エレメンタリストリームが、該エレメンタリストリームの格納されるファイルとは別のファイルに格納され、前記エレメンタリストリームの前記ビデオフレームデータに関する管理情報が付加され、前記第１パケット生成手段（処理）が、前記ビデオエレメンタリストリームに付随して分離された前記管理情報に基づいて第２ビデオデータ単位をビデオフレームデータに分割することが好ましい。
【０２６１】
上記の構成では、第１および第２パケット生成手段（処理）にそれぞれ与えられるビデオエレメンタリストリームおよびオーディオエレメンタリストリームは、分離手段（処理）によって、エレメンタリストリームから分離される。このエレメンタリストリームは、それが格納されるファイルとは別のファイルに格納され、エレメンタリストリームのビデオフレームデータに関する管理情報が付加されている。この管理情報としては、ビデオフレームデータ毎のデータ量、ビデオフレームデータのデコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間、ビデオフレームのピクチャタイプ等に関する情報が含まれる。
【０２６２】
これにより、第１パケット生成手段（処理）は、その管理情報に基づいて、ビデオエレメンタリストリームをビデオフレームデータに分割する。それゆえ、ビデオフレームデータの分割のためにエレメンタリストリームを解析してビデオフレームデータの分割位置を検出するための手段や処理が必要ない。
【０２６３】
あるいは、前記の発明は、前記分離手段（処理）を備え、前記エレメンタリストリームに、所定の間隔毎に前記ビデオフレームデータに関する管理情報が付加され、前記第１パケット生成手段が、前記ビデオエレメンタリストリームに付随して分離された前記管理情報に基づいて第２ビデオデータ単位をビデオフレームデータに分割することが好ましい。
【０２６４】
この構成では、エレメンタリストリームに、前述の管理情報が付加されているので、ビデオフレームデータの分割のためにエレメンタリストリームを解析してビデオフレームデータの分割位置を検出するための手段や処理が必要ない。
【０２６５】
また、前記の従来技術においては、管理情報量を減らすために、ＧＯＰを１サンプルとして管理している。しかしながら、QuickTime ファイルフォーマットでは、本来１ビデオフレームを１サンプルとして管理するのが原則であり、QuickTime ファイルフォーマットを扱うプレーヤや編集ソフトにおいて互換性に支障が生じる虞がある。なお、この原則は、QuickTime ファイルフォーマットをベースにしてISO/IEC 15444-3/FPDAmd 1として規格化されたISO base media file formatにも踏襲されている。
【０２６６】
そこで、上記の構成において、前記エレメンタリストリームは、大きさの異なる前記第１ビデオデータ単位で前記ビデオフレームデータを管理するための複数種の前記管理情報が付加されていることが好ましい。これにより、例えば、第１ビデオデータ単位をサンプルとした場合、ＧＯＰをサンプルとするようなメモリ（バッファ）容量の小さい専用プレーヤでビデオデータを再生する一方、ビデオフレームデータをサンプルとするようなQuickTime 対応プレーヤでビデオデータを再生することができる。
【０２６７】
また、上記の構成において、前記管理情報は、前記第２ビデオデータ単位のビデオフレームデータよりも先に読み出されるように設けられていることが好ましい。これにより、管理情報がエレメンタリストリームと同一のファイルに格納されているか否かに関わらず、管理情報がビデオフレームデータよりも先に読み出されるので、管理情報が読み出されてから、ビデオエレメンタリストリームにおいて分割されるべきビデオフレームデータが読み出される。それゆえ、第１パケット生成手段（処理）が、読み出された管理情報に基づいて、ビデオエレメンタリストリームのビデオフレームデータへの分割処理を速やかに行なうことができる。
【０２６８】
前記の発明は、前記分離手段（処理）を備え、前記エレメンタリストリームが、同一ファイルにおいて該エレメンタリストリームの設けられる領域と別の領域に設けられ、前記エレメンタリストリームの前記ビデオフレームデータに関する管理情報が１個の前記エレメンタリストリームと対をなすように付加され、前記第１パケット生成手段が、前記ビデオエレメンタリストリームに付随して分離された前記管理情報に基づいて第２ビデオデータ単位をビデオフレームデータに分割することが好ましい。
【０２６９】
この構成では、前記管理情報が、同一ファイルにおいてエレメンタリストリームの設けられる領域と別の領域に設けられ、１個のエレメンタリストリームと対をなすように付加されるので、前述の分離手段（処理）を備えた構成と同様に、エレメンタリストリームに、ビデオフレームデータの分割のためにエレメンタリストリームを解析してビデオフレームデータの分割位置を検出するための手段や処理が必要ない。
【０２７０】
データ変換プログラムは、前記のデータ変換方法における各処理をコンピュータに実行させ、また、このデータ変換プログラムは、コンピュータ読み取り可能な記録媒体に記録して提供可能である。
【０２７１】
【発明の効果】
以上のように、本発明によれば、ビデオデータ中のvbv＿delayに常に値をセットするようにしたことで、ＥＳをインターリーブしたＡＶストリーム構成においてＴＳ／ＰＳへの変換を容易にしかも確実にすることが可能である。
【０２７２】
また、通常の管理情報とは別に、ビデオデータの各ビデオフレームのデータ量、ピクチャタイプ、vbv＿delay値を、ビデオデータとは別の位置に記録することで、ＴＳ／ＰＳ変換時にビデオデータを解析する必要がなくなる。また、これらの情報をＡＶストリーム中に記録し、通常再生に用いる管理情報とは別にすることで、通常再生時の管理情報を記憶するためのメモリを増加させることはない。
【０２７３】
さらに、通常再生に用いる管理情報とは別に、ビデオデータの各ビデオフレームのデータ量、ピクチャタイプ、vbv＿delayを求めることが可能な情報を、ISO base media file formatで規定されているMovie fragmentの形式で格納することによって、専用プレーヤだけでなく、ISO base media file formatあるいはQuickTimeファイルフォーマットに対応したプレーヤで再生可能になる。
【図面の簡単な説明】
【図１】本発明の実施形態に係るビデオディスクレコーダの概略構成を示すブロック図である。
【図２】 (ａ)ないし(ｃ)はQuickTime ファイルフォーマットにおける管理情報とＡＶストリームとの関係を示す図である。
【図３】 QuickTime ファイルフォーマットにおけるMovie atomの概要を示す図である。
【図４】 QuickTime ファイルフォーマットにおけるTrack atomの概要を示す図である。
【図５】 QuickTime ファイルフォーマットにおけるTrack header atom の構成を示す図である。
【図６】 QuickTime ファイルフォーマットにおけるMedia atomの構成を示す図である。
【図７】 QuickTime ファイルフォーマットにおけるMedia information atomの構成を示す図である。
【図８】 Sample table atomによるデータ管理の例を示す図である。
【図９】 QuickTime ファイルフォーマットにおけるSample table atom の構成を示す図である。
【図１０】 QuickTime ファイルフォーマットにおけるEdit atom の構成を示す図である。
【図１１】 Edit atomによる再生範囲指定の例を示す説明図である。
【図１２】 QuickTime ファイルフォーマットにおけるUser data atomの構成を示す図である。
【図１３】 QuickTime ファイルフォーマットにおけるFragmented movieの全体構成を示す図である。
【図１４】 QuickTime ファイルフォーマットにおけるMovie extends atomの構成を示す図である。
【図１５】 QuickTime ファイルフォーマットにおけるTrack extends atomの構成を示す図である。
【図１６】 QuickTime ファイルフォーマットにおけるMovie fragment atom の構成を示す図である。
【図１７】 QuickTime ファイルフォーマットにおけるMovie fragment header atomの構成を示す図である。
【図１８】 QuickTime ファイルフォーマットにおけるTrack fragment atom の構成を示す図である。
【図１９】 QuickTime ファイルフォーマットにおけるTrack fragment header atomの構成を示す図である。
【図２０】 QuickTime ファイルフォーマットにおけるTrack fragment run atom の構成を示す図である。
【図２１】（ａ）はディレクトリ／ファイル構成を示す図であり、（ｂ）はそのディレクトリ／ファイル構成のＵＤＦにおける管理を示す図である。
【図２２】本発明の第１の実施形態に係るビデオディスクレコーダにおけるＴＳ／ＰＳ変換部の概略構成を示すブロック図である。
【図２３】上記第１の実施形態におけるＡＶストリームの構成を示す図である。
【図２４】上記第１の実施形態におけるＶＵの構造を示す図である。
【図２５】上記第１の実施形態におけるQuickTime によるＡＶストリーム管理形態を示す図である。
【図２６】上記第１の実施形態におけるリファレンスデバイスモデルを示す説明図である。
【図２７】上記第１の実施形態における記録処理の手順を示すフローチャートである。
【図２８】上記第１の実施形態におけるビデオＴＳパケット生成処理の概念を示す図である。
【図２９】上記第１の実施形態におけるオーディオＴＳパケット生成処理の概念を示す図である。
【図３０】上記第１の実施形態におけるＴＳパケット多重化処理の手順を示すフローチャートである。
【図３１】上記第１の実施形態におけるビデオＰＳパック生成処理の概念を示す図である。
【図３２】上記第１の実施形態におけるオーディオＰＳパック生成処理の概念を示す図である。
【図３３】上記第１の実施形態におけるＰＳパック多重化処理の手順を示すフローチャートである。
【図３４】本発明の第２の実施形態に係るビデオディスクレコーダにおけるＴＳ／ＰＳ変換部の概略構成を示すブロック図である。
【図３５】上記第２の実施形態におけるＶＵの構造を示す図である。
【図３６】上記第２の実施形態におけるQuickTime によるＡＶストリーム管理形態を示す図である。
【図３７】本発明の第３の実施形態に係るビデオディスクレコーダにおけるＡＶストリームの構成を示す図である。
【図３８】上記第３の実施形態におけるVBV delay atomの構成を示す図である。
【図３９】従来技術におけるQuickTime ファイルフォーマットを用いたＡＶファイルの構成を示す図である。
【符号の説明】
１００ バス
１０１ ホストＣＰＵ
１０２ ＲＡＭ
１０３ ＲＯＭ
１０４ ユーザインタフェース
１０７ 光ピックアップ（記録手段）
１０９ ＥＣＣエンコーダ（記録手段）
１１０ オーディオ再生用バッファ
１１１ ビデオ再生用バッファ
１１２ デマルチプレクサ
１１３ マルチプレクサ
１１５ オーディオデコーダ
１１６ ビデオデコーダ
１１７ オーディオエンコーダ
１１８ ビデオエンコーダ
１２１ ＴＳ／ＰＳ変換部（変換手段）
１２３ 記録媒体
２０１ Movie atom（第１の管理情報）
４０４ Movie fragment atom（第２の管理情報）
７０１ ＡＶストリーム
７０３ ＶＵ（ユニット）
７０４ ＧＯＰ（画像データ群）
７０５ ＡＡＵ
７０７ ＶＣ
７０８ ＡＣ
７０９ ＶＦＩ（第２の管理情報）
７１０ Movie fragment atom（第２の管理情報）
１１０１ ビデオＰＥＳパケット生成部
１１１１ オーディオＰＥＳパケット生成部
１１０２ ビデオＴＳパケット生成部
１１１２ オーディオＴＳパケット生成部
１１２１ ＴＳマルチプレクサ
１１２２ ＰＳマルチプレクサ
【発明の属する技術分野】
本発明は、ハードディスク、光ディスク、半導体メモリ等のランダムアクセス可能な記録媒体に対して、映像データおよび音声データを記録するデータ記録方法、データ記録装置、データ変換方法、データ変換装置、データ記録媒体、データ記録媒体、データ記録のためのプログラム、およびそのプログラムが記録された記録媒体に関するものである。
【０００２】
【従来の技術】
ディスクメディアを用いたビデオのディジタル記録再生装置（以下、ビデオディスクレコーダと呼ぶ）が普及しつつある。その記録フォーマットには、ＰＣ（パーソナルコンピュータ）との親和性を高めるため、ＰＣで広く使われている、QuickTime（商標）ファイルフォーマットを用いることがよく行われる。
【０００３】
QuickTime ファイルフォーマットを用いたビデオデータの管理については、特開２００１−１７６１９５号公報に開示されている。以下、図３９を用いてその概要を説明する。
【０００４】
ビデオデータは、ムービーファイル５００１に格納されている。ムービーファイル５００１は、実際のビデオデータおよびオーディオデータを格納するMovie data atom と、ビデオデータおよびオーディオデータを管理するためのMovie atomとで構成される。
【０００５】
Movie data atom 中では、入力されたオーディオとビデオとのＥＳ(Elementary Stream)が所定の時間（１秒程度）に対応するアクセスユニット（ＭＰＥＧ２ビデオであればＧＯＰ(Group of Pictures) 、ＭＰＥＧ２オーディオであればオーディオフレームとしてのＡＡＵ(Audio Access Unit) ）毎に区切り、これらを交互に配置する。それぞれの区切られた単位は、QuickTime におけるチャンクとして扱われる。また、各オーディオフレームおよびＧＯＰは、QuickTime におけるサンプルとして扱われる。各サンプルのデータ量および再生時間、ならびにムービーファイル５００１中での各チャンクの相対アドレスは、Movie atomに格納し、再生の際は、Movie atomを参照することで、ある時間に対応するビデオデータおよびオーディオデータの記録位置を特定することが可能となる。
【０００６】
【発明が解決しようとする課題】
しかしながら、一般に広く用いられているのは、上記のストリーム構成と異なる構成を持ったISO/IEC 13818-1 に定義されるTransport Stream（以下MPEG 2-TS ）や、Program Stream（以下MPEG 2-PS ）である。例えば、DVD-Video ではＭＰＥＧ２−ＰＳが採用されており、ディジタル放送やIEEE-1394による機器間のデータ転送形式ではＭＰＥＧ２−ＴＳが採用されている。したがって、上記のストリーム構成で記録したデータをIEEE-1394による伝送形式で別の機器に転送したり、ＤＶＤプレーヤで再生できるようにするためには、上記のストリーム構成のデータをＭＰＥＧ２−ＰＳやＭＰＥＧ２−ＴＳへ変換する必要がある。ところが、前記の従来技術においては、そのための方法が開示されていない。
【０００７】
本発明は、上記課題を鑑みてなされたものであり、Elementary Stream 同士を多重化したストリーム構成を持ち、そのストリームを、複数のフレームを１単位として管理する場合において、ＭＰＥＧ２−ＴＳ／ＰＳのファイルフォーマットのストリームに容易に変換可能な形態でデータを記録媒体に記録するデータ記録方法等を提供することを目的とする。
【０００８】
【課題を解決するための手段】
本発明のデータ記録方法および装置は、１個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームを記録する領域とは別の領域に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録方法および装置であって、前記ＡＶストリーム中に前記ユニットの個々に関する第２の管理情報を含んだ状態で前記ＡＶストリームを記録し、前記第２の管理情報が、対応する前記ユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴としている。
【０００９】
この方法・装置では、QuickTime ファイルフォーマットでデータ記録媒体に記録されているＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳストリームに変換する際に、ＡＶストリーム中の第２管理情報を用いることによって、画像データ群を解析することなく、通常の記録・再生に必要な管理情報を増やさずに、ストリーム変換することができる。それゆえ、QuickTime ファイルフォーマットのＡＶ(Audio and Visual)ストリームをＭＰＥＧ２−ＴＳのファイルフォーマットを採用する機器（IEEE-1394やＤＶＤプレーヤ等）に容易に転送することができる。
【００１０】
上記のデータ記録方法においては、第２の管理情報のデータフォーマットにISO base media file formatにおけるMovie Fragmentを用いることが好ましい。これにより、通常の記録・再生に必要な管理情報を増やさないだけでなく、再生互換性を高めることができる。
【００１１】
本発明の他のデータ記録方法および装置は、１個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームを記録する領域とは別の領域に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録方法および装置であって、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記データ記録媒体に記録することを特徴としている。
【００１２】
この方法および装置では、上記の遅延時間をデータ記録媒体に記録するので、このデータ記録媒体から読み出された、QuickTime ファイルフォーマットでデータ記録媒体に記録されているＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳストリームに変換する際に、遅延時間を用いることによって、確実にストリーム変換することができる。
【００１３】
このデータ記録方法において、前記遅延時間を含んだ前記ＡＶストリームを記録することが好ましい。これにより、通常の記録・再生に必要な管理情報を増加させることがない。
【００１４】
しかも、前記ＡＶストリーム中に前記ユニットの個々に関して第２の管理情報を含んだ状態で前記ＡＶストリームを記録し、前記第２の管理情報、例えば後述するVideo Frame Informationが、対応するユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間を持つことにより、画像データ群を解析する必要がない。
【００１５】
また、前記第２の管理情報を、対応する前記ユニットの物理的な近傍に配置することにより、ＡＶストリームのデコードの前に必要なバッファメモリの容量を少なくすることができる。あるいは、前記第２の管理情報と前記ＡＶストリームとを同一ファイルで管理し、前記第２の管理情報を対応する前記画像データ群よりも低い前記ファイルの先頭からの相対アドレスアドレスに置くことによっても、バッファメモリの容量が少なくすることができる。
【００１６】
前述のように、遅延時間をＡＶストリーム中に記録した場合、前記遅延時間を少なくとも前記画像データ群外に記録し、前記第１の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間情報を持つことが好ましい。これにより、画像データ群を解析する必要がなくなる。
【００１７】
前記第１の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことが好ましい。これにより、Ｂピクチャにも対応することができる。
【００１８】
前記第１の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記ビデオフレームのピクチャタイプに関する情報および前記遅延時間を持つことが好ましい。これにより、画像データ群を解析する必要がない。
【００１９】
前記第２の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことが好ましい。
【００２０】
本発明のデータ記録プログラムは、前記のデータ記録方法をコンピュータに実行させる。また、このデータ記録プログラムは、コンピュータ読み取り可能な 記録媒体に記録される。
【００２１】
本発明のデータ変換方法および装置は、１個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報とが記録されているデータ記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、変換の際に、前記データ量に関する情報を用いることを特徴としている。この方法では、QuickTime ファイルフォーマットの第１のＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳの第２のストリームに変換する際に、第１のＡＶストリーム中の第２の管理情報を用いることによって、画像データ群を解析することなく、ストリーム変換することができる。それゆえ、QuickTime ファイルフォーマットのＡＶ(Audio and Visual)ストリームをＭＰＥＧ２−ＴＳのファイルフォーマットを採用する機器（IEEE-1394やＤＶＤプレーヤ等）に容易に転送することができる。
【００２２】
本発明の他のデータ変換方法および装置は、１個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、前記遅延時間を用いて前記画像データ群を分割して前記第１のＡＶストリームを第２のＡＶストリームに変換することを特徴としている。
【００２３】
この方法では、上記の遅延時間が記録されたデータ記録媒体から読み出された、QuickTime ファイルフォーマットのＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳストリームに変換する際に、遅延時間を用いることによって画像データ群（ＧＯＰ）をビデオフレームに分割するので、確実にストリーム変換することができる。
【００２４】
本発明の他のデータ変換方法は、１個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間およびデータ量とが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、前記遅延時間および前記データ量を用いて前記画像データ群を分割して前記第１のＡＶストリームを第２のＡＶストリームに変換することにより、前述のデータ変換方法と同様、画像データ群を解析する必要がないだけでなく、遅延時間およびデータ量を用いることによって、確実にストリーム変換することができる。
【００２５】
本発明のさらに他のデータ変換方法は、１個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間、データ量およびピクチャタイプに関する情報が記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、前記遅延時間、前記データ量および前記ピクチャタイプを用いて前記画像データ群を分割して前記第１のＡＶストリームを第２のＡＶストリームに変換することにより、前述のデータ変換方法と同様、画像データ群を解析する必要がないだけでなく、遅延時間およびデータ量を用いることによって、確実にストリーム変換することができ、さらにＢピクチャにも対応することができる。
【００２６】
本発明のデータ記録媒体は、１個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームが記録された領域とは別の領域に前記ユニットに関する第１の管理情報が記録されているデータ記録媒体であって、前記ＡＶストリームは、前記ユニットの個々に関する第２の管理情報を含み、前記第２の管理情報は、対応する前記ユニットにおける前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴としている。
【００２７】
このようなデータ記録媒体から読み出されたQuickTime ファイルフォーマットのＡＶストリームは、ＭＰＥＧ２−ＴＳ／ＰＳの第２のストリームに変換する際に、ＡＶストリーム中の第２の管理情報を用いることによって、画像データ群を解析することなく、ストリーム変換することができる。それゆえ、QuickTime ファイルフォーマットのＡＶ(Audio and Visual)ストリームをＭＰＥＧ２−ＴＳのファイルフォーマットを採用する機器（IEEE-1394やＤＶＤプレーヤ等）に容易に転送することができる。
【００２８】
本発明の他のデータ記録媒体は、１個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームが記録されている領域とは別の領域に前記ユニットに関する第１の管理情報が記録されているデータ記録媒体であって、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されていることを特徴としている。
【００２９】
上記の遅延時間が記録されたデータ記録媒体から読み出された、QuickTime ファイルフォーマットのＡＶストリームをＭＰＥＧ２−ＴＳ／ＰＳストリームに変換する際に、遅延時間を用いることによって、確実にストリーム変換することができる。
【００３０】
【発明の実施の形態】
以下、本発明の実施形態について、図１ないし図３８を参照しながら詳細に説明する。ここでの説明は、本発明において共通に用いる構成、個々の実施形態に固有の内容という順に行なうものとする。
【００３１】
〔基本システム〕
図１は、後述する各実施形態において共通のビデオディスクレコーダの基本システム構成図である。以下に、この基本システムについて説明する。
【００３２】
＜システム構成＞
このビデオディスクレコーダは、図１に示すように、バス１００、ホストＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、ユーザインタフェース１０４、システムクロック発生器１０５、光ディスク１０６、ピックアップ１０７、ＥＣＣ(Error Correcting Coding)デコーダ１０８、ＥＣＣエンコーダ１０９、オーディオ再生用バッファ１１０、ビデオ再生用バッファ１１１、デマルチプレクサ１１２、マルチプレクサ１１３、記録用バッファ１１４、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８、オーディオ記録用バッファ１１９、ビデオ記録用バッファ１２０、ＴＳ／ＰＳ変換部１２１、外部ディジタル出力部１２２、および図示しないカメラ、マイク、スピーカ、ディスプレイ等で構成される。
【００３３】
ホストＣＰＵ１０１は、デマルチプレクサ１１２、マルチプレクサ１１３、ピックアップ１０７、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８、ＴＳ／ＰＳ変換部１２１等の制御をバス１００を通じて行う。デマルチプレクサ１１２、マルチプレクサ１１３、ピックアップ１０７、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８およびＴＳ／ＰＳ変換部１２１は、ハードウエアで構成されていてもよいし、ソフトウエアで構成されていてもよ。
【００３４】
ＲＡＭ１０２は、ビデオディスクレコーダの動作を制御するためにホストＣＰＵ１０１に実行させる制御プログラム等のプログラムやプログラムの実行に必要なデータをロードしたり、プログラムの実行のための作業領域を提供している。また、ＲＡＭ１０２は、再生時のＴＳ／ＰＳ変換部１２１によるファイルフォーマットの変換時等にＡＶストリームの後述する管理情報を読み込む。
【００３５】
ＲＯＭ１０３は、上記のプログラムやデータを格納している。制御プログラムは、後述する記録時の処理を実現するためのデータ記録プログラムやＴＳ／ＰＳ変換部１２１の変換処理を実現するための変換プログラムを含んでいる。このデータ記録プログラムや変換プログラムは、ＲＯＭ１０３に限らず、記憶媒体１２３に記憶されていてもよい。記録媒体１２３は、コンピュータが読み取り可能である光ディスク、光磁気ディスク、磁気ディスク、磁気テープ、半導体メモリ等の媒体であって、ドライブ装置１２４によって駆動される。
【００３６】
ユーザインタフェース１０４は、ユーザがディスプレイの画面上で本ビデオディスクレコーダの各種の操作をリモートコントローラを用いてできるように、操作案内等を画面に表示したりユーザによる操作入力を受け入れたりするためのソフトウエアである。
【００３７】
システムクロック発生器１０５は、ＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３等に供給するためのシステムクロックを発生する回路である。
【００３８】
再生時に、光ディスク１０６からピックアップ１０７を通じて読み出されたデータは、ＥＣＣデコーダ１０８によって誤り訂正され、デマルチプレクサ１１２に送られる。デマルチプレクサ１１２は、ホストＣＰＵ１０１からの指示に従い、ＥＣＣデコーダ１０８から読み出されたデータよりオーディオデータおよびビデオデータを抽出して、それぞれをオーディオ再生用バッファ１１０およびビデオ再生用バッファ１１１に振り分ける。オーディオデータおよびビデオデータは、それぞれオーディオ再生用バッファ１１０およびビデオ再生用バッファ１１１に一時的に格納される。オーディオデコーダ１１５およびビデオデコーダ１１６は、ホストＣＰＵ１０１からの指示に従って、それぞれオーディオ再生用バッファ１１０およびビデオ再生用バッファ１１１からデータを読み出しデコードを行う。
【００３９】
一方、記録時には、オーディオデータおよびビデオデータがそれぞれオーディオエンコーダ１１７およびビデオエンコーダ１１８によって圧縮符号化される。圧縮符号化されたオーディオデータおよびビデオデータは、それぞれオーディオ記録用バッファ１１９およびビデオ記録用バッファ１２０に送られ、そこで一時的に格納される。マルチプレクサ１１３は、ホストＣＰＵ１０１からの指示に従って、オーディオ記録用バッファ１１９およびビデオ記録用バッファ１２０からデータを読み出し、これらをＡＶ多重化して記録用バッファ１１４に送る。ＥＣＣエンコーダ１０９は、記録用バッファ１１４から読み出したＡＶ多重化データに対し誤り訂正符号を付加し、ピックアップ１０７を通じて光ディスク１０６に記録する。
【００４０】
また、ＴＳ／ＰＳ変換部１２１は、ホストＣＰＵ１０１からの指示に従って、オーディオ再生用バッファ１１０およびビデオ再生用バッファ１１１に蓄えられている後述のQuickTime ファイルフォーマットのＥＳ(Elementary Stream) を、ＭＰＥＧ２−ＴＳ(Transport Stream)およびＭＰＥＧ２−ＰＳ(Program Stream)にファイルフォーマット変換する。このＴＳ／ＰＳ変換部１２１は、ソフトウエアで構成される場合、データ変換プログラムであって、ＲＯＭ１０３または記録媒体１２３に格納されている。変換の結果として生成されたＭＰＥＧ２−ＴＳおよびＭＰＥＧ２−ＰＳフォーマットのデータは、外部ディジタル出力部１２２を介して外部に出力されるか、あるいは記録用バッファ１１４およびＥＣＣエンコーダ１０９を介して光ピックアップ１０７により光ディスク１０６に記録される。
【００４１】
ＥＣＣエンコーダ１０９によるオーディオデータの符号化方式にはISO/IEC 11172-3で規定されるＭＰＥＧ１ Layer-IIを用いる。一方、ＥＣＣエンコーダ１０９によるビデオデータの符号化方式にはISO/IEC 13818-2で規定されるＭＰＥＧ２を用いる。光ディスク１０６は、ＤＶＤ−ＲＡＭのような書き換え可能な光ディスクである。この光ディスク１０６においては、２０４８byteを１セクタとし、誤り訂正のため１６セクタでＥＣＣブロックを構成する。
【００４２】
＜ファイルフォーマット＞
本基本システムにおいて、ＡＶストリーム管理のためのフォーマットとして用いる、QuickTimeファイルフォーマットについて説明する。QuickTime ファイルフォーマットとは、Apple 社が開発したマルチメディアデータ管理用フォーマットであり、ＰＣの世界で広く用いられている。また、QuickTime ファイルフォーマットをベースとしてISO base media file formatが規格化されている。
【００４３】
QuickTime ファイルフォーマットは、ビデオデータやオーディオデータ等（これらを総称してメディアデータとも呼ぶ）と管理情報とで構成される。両者を合わせてここでは、QuickTime ムービー（略してムービー）と称する。両者は、同じファイル中に存在してもよいし、別々のファイルに存在してもよい。
【００４４】
図２（ａ）は、両者が同じファイル２０１中に存在する場合にとる構成を示している。各種情報は“atom”という共通の構造に格納される。より詳細には、第１の管理情報はMovie atom２１１という構造に格納され、メディアデータはMovie dataatom２１２という構造に格納される。Movie atom２１１における管理情報には、メディアデータ中の任意の時間に対応するメディアデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。一方、Movie data atom２１２におけるメディアデータすなわちＡＶストリーム(AV stream) ２１３は、ＡＨ(Atom Header) が付加される。このような構成では、Movie atomはメディアデータをatom内で参照している。
【００４５】
図２（ｂ）は、管理情報とメディアデータとをそれぞれ別々のファイル２０２，２０３に格納した場合の構成を示している。管理情報はMovie atom２１１という構造に格納されるが、メディアデータはatomには格納される必要はない。このとき、Movie atom２１１は、メディアデータを格納したファイル２０３を「外部参照」している、という。
【００４６】
図２（ｃ）に示すように、外部参照は、例えば、ファイル２０４におけるMovie atom２１１から、複数のファイル２０５，２０６にそれぞれ格納されるＡＶストリーム２１３（AV stream ♯１，♯２）に対して行うことが可能である。このような仕組みにより、ＡＶストリーム２１３自体を物理的に移動することなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」や「非破壊編集」が可能になる。
【００４７】
続いて、図３ないし図２０を用いて、QuickTimeの管理情報のフォーマットについて説明する。
【００４８】
まず、共通の情報格納フォーマットであるatomについて説明する。
【００４９】
atomの先頭には、そのatomのサイズであるAtom size、およびそのatomの種別情報であるTypeが必ず存在する。Typeは4文字で区別され、例えば、図３に示すMovie atomでは'moov'となっており、Movie data atomでは'mdat'となっている。atomの先頭にあるAtom sizeおよびTypeの列を、ここでは“atom header”と称する。各atomは、別のatomを含むことができる。すなわち、atom間には階層構造がある。
【００５０】
図３は、Movie atomの構成を示している。この構造において、“Movie header atom”は、そのMovie atomが管理するムービーの全体的な属性を管理する。“Track atom”は、そのムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納する。“User data atom”は、ユーザにて独自に定義可能なatomである。
【００５１】
図４は、Track atomの構成を示している。“Track header atom”は、そのトラックの全体的な属性を管理する。“Edit atom”は、メディアデータのどの区間を、ムービーのどのタイミングで再生するかを管理する。“Track reference atom”は、本トラックと別のトラックとの関係を管理する。“Media atom”は、実際のビデオやオーディオといったデータを管理する。
【００５２】
図５は、Track header atomの構成を示している。ここでは、後での説明に必要なもののみについて説明する。“Flags”は、属性を示すフラグの集合であり、代表的なものとしてTrack enabledフラグがあり、このフラグが１であれば、そのトラックは再生され、０であれば再生されない。“Layer”は、そのトラックの空間的な優先度を表しており、画像を表示するトラックが複数あれば、Layerの値が小さいトラックほど画像が前面に表示される。
【００５３】
図６は、Media atomの構成を示している。“Media header atom”は、そのMedia atomの管理するメディアデータに関する全体的な属性等を管理する。“Handler reference atom”は、メディアデータをどのデコーダでデコードするかを示す情報を格納する。“Media information atom”は、ビデオやオーディオ等のメディア固有の属性情報を管理する。
【００５４】
図７は、Media information atomの構成を示している。“Media information header atom”は、ビデオやオーディオ等メディア固有の属性情報を管理する。“Handler reference atom”は、前述のMedia atomに含まれるものと同じである。“Data information atom”は、そのQuickTimeムービーが参照するメディアデータを含むファイルの名称を管理するatomである“Data reference atom”を含む。“Sample table atom”は、データのサイズや再生時間等を管理している。
【００５５】
次に、Sample table atomについて説明するが、その前に、QuickTimeにおけるデータの管理方法について、図８を用いて説明する。
【００５６】
QuickTimeでは、データの最小単位（例えばビデオフレーム）をサンプル(sample)と称する。サンプルには、個々のトラック毎に、再生時間順に１から番号（サンプル番号）が♯１，♯２，…♯ｉというように付与されている。
【００５７】
また、QuickTimeフォーマットでは、個々のサンプルの再生時間長およびデータサイズを管理している。しかも、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンク(chunk) と称する。チャンクにも、サンプルと同様に、再生時間順に１から番号が付与されている。
【００５８】
さらに、QuickTimeフォーマットでは、個々のチャンクのファイル先頭からのアドレスおよび個々のチャンクが含むサンプル数を管理している。これらの情報に基づき、任意の時間に対応するサンプルの位置を求めることが可能となっている。
【００５９】
図９は、Sample table atomの構成を示している。“Sample description atom”は、個々のチャンクのデータフォーマット(Data format) やサンプルが格納されているファイルのチャンクの Index等を管理する。“Time-to-sample atom”は、個々のサンプルの再生時間を管理する。
【００６０】
“Sync sample atom”は、個々のサンプルのうち、デコード開始可能なサンプルを管理する。“Sample-to-chunk atom”は、個々のチャンクに含まれるサンプル数を管理する。“Sample size atom”は、個々のサンプルのサイズを管理する。“Chunk offset atom”は、個々のチャンクのファイル先頭からのアドレスを管理する。
【００６１】
図１０は、Edit atom の構成を示している。Edit atom は、１個のEdit list atomを含む。Edit list atomは、Number of entriesで指定される個数分の、“Track duration”、“Media time”、“Media rate”の値の組（エントリ）を持つ。各エントリは、トラック上で連続的に再生される区間に対応し、そのトラック上での再生時間順に並んでいる。
【００６２】
Track durationは、そのエントリが管理する区間のトラック上での再生時間を表している。Media timeは、そのエントリが管理する区間の先頭に対応するメディアデータ上での位置を表している。Media rateは、そのエントリが管理する区間の再生スピードを表している。
【００６３】
なお、Media timeが−１の場合は、そのエントリのTrack duration分、そのトラックに無再生区間を挿入する。この区間のことをempty editと称する。
【００６４】
図１１は、Edit list の使用例を示す。ここでは、Edit list atomの内容が図１１（ａ）に示す内容であり、さらにサンプルの構成が図１１（ｂ）であったとする。なお、ここではｉ番目のエントリのTrack durationをＤ(i) 、Media timeをＴ(i) 、Media rateをＲ(i) とする。このとき、実際のサンプルの再生は、図１１（ｃ）に示す順に行われる。このことについて簡単に説明する。
【００６５】
まず、エントリ♯１は、Ｄ(1) が１３０００、Ｔ(1) が２００００、Ｒ(1) が１であるため、そのトラックの先頭から１３０００の区間は、サンプル中の時刻２００００から３３０００の区間を再生する。次に、エントリ♯２は、Ｄ(2) が５０００、Ｔ(2) が−１であるため、トラック中の時刻１３０００から１８０００の区間、何も再生を行わない（図１１（ｃ）における“null”）。
【００６６】
最後に、エントリ♯３は、Ｄ(3) が１００００、Ｔ(3) が０、Ｒ(3) が１であるため、トラック中の時刻１８０００から２８０００の区間において、サンプル中の時刻０から１００００の区間を再生する。
【００６７】
図１２は、User data atomの構成を示している。このatomには、QuickTimeフォーマットで定義されてない独自の情報を任意個数格納することができる。１個の独自情報は１個のエントリで管理され、１個のエントリは“Size”と“Type”と“User data ”とで構成される。Sizeはそのエントリ自体のサイズを表し、Typeは独自情報をそれぞれ区別するための識別情報を表し、User dataは実際のデータを表している。
【００６８】
次に、録画中の電源遮断等に対応するために導入された概念であるFragmented Movieについて説明する。Fragmented movieは、QuickTime フォーマットの１アプリケーションであるMotion JPEG2000 で導入された概念であり、上述のSample table atomに相当する情報を、部分的なＡＶストリーム毎に管理することが可能となっている。Motion JPEG2000 では、atomの代わりにbox という用語を用いているが、ここでは統一のためにatomに置き換えて説明する。
【００６９】
図１３は、Fragmented movieを導入したQuickTime ファイル４０１の全体構成を示している。先頭に、そのファイル全体に共通する情報を管理するMovie atom（情報管理部）４０２が配置され、その後に、部分ＡＶストリームデータを格納するMovie data atom（データ格納部）４０３と、その部分ＡＶストリームデータを構成するサンプルのアドレスやサイズ、再生時間等を管理するMovie fragment atom （管理部）４０４とが交互に配置される。なお、ＡＶストリームデータは、通常の QuickTimeファイルと同様、別ファイルに存在しても構わない。
【００７０】
録画時には、この順番で記録を行なっていくことにより、録画時の電源切断による被害を最小限に防ぐことが可能となっている。Movie atom４０２には、そのQuickTime ムービーがFragmented movie であることを示すためのMovie extends atom４０２１が含まれる。Movie extends atom４０２１には、そのムービーに含まれる各トラックに関するデフォルト値(Track extends atom４０４２) が格納される。
【００７１】
また、 Movie fragment atom４０４には、その Movie fragment atom４０４が管理する部分ＡＶストリームに関する管理情報が含まれている。管理情報には、その管理する部分ＡＶストリーム全体に関する情報を格納するMovie fragment header atom ４０４１と、部分ＡＶストリーム中の各トラックに関する情報を格納する Track fragment atom４０４２とがある。
【００７２】
Track fragment atom４０４２は、それが管理するトラックに属する部分ＡＶストリームに関する情報を格納するTrack fragment header atom４０４３と、そのトラックに属する部分ＡＶストリームを構成する論理的な連続領域（Track runと呼ばれる）をそれぞれ管理する Track fragment run atom４０４４とを含む。以下に、各atomについて詳しく説明する。
【００７３】
図１４は、 Movie extends atom４０２１の構成を示している。Movie extends atom４０２１は、前述のように、このatomを含む QuickTimeムービーがFragmented movieであることを示す役割を持つ。
【００７４】
図１５は、Track extends atom４０２１の構成を示す。Track extends atom ４０２１は、この QuickTimeムービーに含まれる各トラックのサンプルのデフォルト値を設定するために存在する。Track-IDは、Movie atom中で定義されているトラックのtrack-IDを参照する。“Default-sample- ”で始まるフィールドは、このatomで管理されるtrack fragmentのデフォルト値を設定する。
【００７５】
図１６は、 Movie fragment atom４０４の構成を示している。このatomは、録画中に逐次記録される管理情報であり、前述のとおり、このatomの管理するMovie fragmentに関する実際の情報を格納するatomである Movie fragment header atom４０４３や Track fragment atom４０４２を含む。
【００７６】
図１７は、Movie fragment header atom４０４３の構成を示している。このatomに格納されている主な情報は“sequence-number ”である。sequence-numberは、このatomが含まれるMovie fragment atom４０４が管理するMovie fragmentの先頭からの順番を表す。
【００７７】
図１８は、 Track fragment atom４０４２の構成を示す。Track fragment atom４０４３は、Movie fragmentに含まれる特定のトラックのサンプルに関する管理情報であるTrack fragment header atom４０４３やTrack fragment run atom４０４４を格納する。
【００７８】
図１９は、Track fragment header atom４０４３の構成を示している。このatomは、Movie fragmentに含まれる特定のトラックのサンプルに関するデフォルト値等を格納する。track-IDは、Movie atom中で定義されているトラックのtrack IDとの対応を示す。sample-description-indexは、このatomが管理するサンプルの参照するsample description tableのインデックス番号、“default-sample- ”で始まるフィールドは、それぞれこのatomが管理するサンプルのデフォルト値である。
【００７９】
図２０は、 Track fragment run atom４０４４の構成を示す。このatomは、Track runと呼ばれる、このatomの管理する連続領域や個々のサンプルの管理情報を格納する。sample-countは、Track run に含まれるサンプルの個数を示す。data-offset は、base-data-offsetからのTrack run のオフセット値を示す。“sample- ”で始まるフィールドは、このatomが管理するサンプルの再生時間等の値を格納する。ただし、上述のデフォルト値と同じであれば、省略してデータサイズを縮小することが可能となっている。
【００８０】
＜ファイルシステム＞
本発明の説明において用いるファイルシステムのフォーマットであるＵＤＦ(Universal Disk Format) について図２１を用いて説明する。図２１（ｂ）は、図２１（ａ）に示すディレクトリ/ファイル構成をＵＤＦで記録した例を示す。
【００８１】
図中のＡＶＤＰ(Anchor Volume Descriptor Pointer)６０２は、ＵＤＦの管理情報を探すためのエントリポイントに相当し、通常２５６セクタ目、Ｎセクタ目あるいはＮ−２５６セクタ目(Ｎは最大論理セクタ番号)に記録される。
【００８２】
ＶＤＳ(Volume Descriptor Sequence)６０１は、ＵＤＦが管理する領域であるボリュームに関する管理情報を記録する。ボリュームは、一般に１枚の光ディスク１０６に１個存在し、その中にパーティションを一般に１個含む。
【００８３】
ＦＳＤ(File Set Descriptor) ６０３は、パーティションに１個存在する。パーティションの中での位置情報は、パーティションの先頭からのセクタ番号に相当する論理ブロック番号で示される。
【００８４】
なお、１個の論理ブロックは１セクタに対応する。また、各パーティションには図示しないがSpace Bitmapと呼ばれる各論理ブロックがファイルにすでに割り当てられているか否かを示すテーブルが存在する。
【００８５】
ＦＳＤ６０３は、ルートディレクトリのＦＥ(File Entry)６０４の位置情報（論理ブロック番号と論理ブロック数とで構成されて“extent”と呼ばれる）を含む。ＦＥは、extentの集合を管理しており、extentを書き換えたり、追加や削除することで、ファイルを構成する実データの順番を変えたり、データの挿入や削除をしたりできる。
【００８６】
ＦＥ６０４は、ルートディレクトリの直下のファイルやディレクトリの名称等を格納するＦＩＤ(File Identifier Descriptor)６１１，６１２，…の集合を格納する領域６０５を管理する。領域６０５中のＦＩＤ６１１，６１２は、それぞれファイル６２１，６２２のファイル名やextentの集合を管理するＦＥ６０６，６０８の位置情報を含む。
【００８７】
ＦＥ６０６は、ファイル６２１の実データを構成する領域である領域６０７，６１０をextentとして管理する。このとき、ファイル６２１の実データにアクセスするには、ＡＶＤＰ６０２、ＶＤＳ６０１、ＦＳＤ６０３、ＦＥ６０４、ＦＩＤ６１１、ＦＥ６０６、領域６０７、領域６１０の順にリンクを辿っていけばよい。
【００８８】
光ディスク１０６のデータ記録領域には、図２１（ｂ）の構成でＡＶストリームが記録されている。前述のムービーファイル、すなわちＡＶストリームやMovie atom、Movie fragment atom 等の管理情報は、図２１(ｂ)の領域６０７，６１０で表されるファイルを構成する実データとして記録される。例えば、図２（ａ）のムービーファイル２０１のMovie atom２１１は、領域６１０の前半部分に記録され、ＡＶストリームを含むMovie dara atom２１２は、領域６１０の後半部分および領域６０７全体に記録されるようなとこが考えられる。
【００８９】
この場合、ＦＥ６０６には、ファイルシステムを通して、ムービーファイル２０１を読み出したときに、図２（ａ）の順に読み出されるように、領域６１０のextent、領域６０７のextentの順に位置情報を格納する。つまり、この例で示すように、ファイルを構成する実データは、実際には、光ディスク１０６では連続的に記録される保証はなく、また、ファイル中の順序で光ディスク１０６に記録される保証もない。
【００９０】
ただし、次のような例外もある。ディスク媒体に対しては、ディスク上で物理的に離れた場所にあるデータにアクセスするのに、ピックアップの移動を伴い、その間にデータの読み出しおよび記録が停止する。そのため、管理情報を物理的に連続して記録することで、管理情報の読み出しを高速化したり、ＡＶストリームを所定の長さ以上で連続的に記録したりすることで、ビデオデータやオーディオデータを途切れることなく再生することを保証するのはよく知られた技術である。
【００９１】
〔第１の実施形態〕
本発明の第１の実施形態について、図２２ないし図３３を用いて説明する。
【００９２】
＜システム構成＞
本実施形態に係るビデオディスクレコーダは、図１に示す前述のビデオディスクレコーダの構成と共通しているが、本実施形態で特徴的な処理部であるＴＳ／ＰＳ変換部１２１について図２２を用いて詳細に説明する。
【００９３】
ＴＳ／ＰＳ変換部１２１は、ビデオＰＥＳパケット生成部１１０１、ビデオＴＳパケット生成部１１０２、ビデオＴＳパケット用バッファ１１０３、ビデオパック生成部１１０４、ビデオパック用バッファ１１０５、オーディオＰＥＳパケット生成部１１１１、オーディオＴＳパケット生成部１１１２、オーディオＴＳパケット用バッファ１１１３、オーディオパック生成部１１１４、オーディオパック用バッファ１１１５、ＴＳマルチプレクサ１１２１、ＰＳマルチプレクサ１１２２、およびビデオ解析部１１３１より構成される。
【００９４】
次に、それぞれの処理部について説明する。
【００９５】
ビデオＰＥＳパケット生成部１１０１は、ビデオ再生用バッファ１１１から読み出したビデオＥＳ（ビデオフレームデータ）に基づいてＰＥＳ(Packetized Elementary Stream)パケットを生成する。オーディオＰＥＳパケット生成部１１１１も同様に、オーディオ再生用バッファ１１０から読み出したオーディオＥＳに基づいてＰＥＳパケットを生成する。ビデオ解析部１１３１は、ビデオ再生用バッファ１１１からのビデオＥＳにおけるビデオフレームの境界を検出する。ビデオＰＥＳパケット生成部１１０１は、その境界に基づいてビデオチャンクをビデオフレームに分割する。
【００９６】
ビデオＴＳパケット生成部１１０２は、ビデオＰＥＳパケット生成部１１０１からのＰＥＳパケットに基づいてＴＳ(Transport Stream)パケット（ビデオＴＳパケット）を生成する。オーディオＴＳパケット生成部１１１２は、オーディオＰＥＳパケット生成部１１１１からのＰＥＳパケットに基づいてＴＳパケット（オーディオＴＳパケット）を生成する。
【００９７】
ＴＳマルチプレクサ１１２１は、ビデオＴＳパケット生成部１１０２およびオーディオＴＳパケット生成部１１１２によって生成されたＴＳパケットを、多重化してＭＰＥＧ２−ＴＳを生成する。ビデオＴＳパケット用バッファ１１０３およびオーディオＴＳパケット用バッファ１１１３は、ビデオＴＳパケット生成部１１０２およびオーディオＴＳパケット生成部１１１２からのＴＳパケットを一時的に蓄えることにより、両ＴＳパケット生成部１１０２，１１１２とＴＳマルチプレクサ１１２１との処理の時間差を吸収する。
【００９８】
ビデオパック生成部１１０４は、ビデオＰＥＳパケット生成部１１０１から送られてきたビデオＰＥＳパケットをグループ化してビデオパックを生成する。オーディオパック生成部１１１４も同様に、オーディオＰＥＳパケット生成部１１１１から送られてきたオーディオＰＥＳパケットをグループ化してオーディオパックを生成する。
【００９９】
ＰＳマルチプレクサ１１２２は、ビデオパック生成部１１０４およびオーディオパック生成部１１１４によって生成されたパックを多重化してＭＰＥＧ２−ＰＳを生成する。ビデオパック用バッファ１１０５およびオーディオパック用バッファ１１１５は、ビデオパック生成部１１０４およびオーディオパック生成部１１１４からのパックを一時的に蓄えることにより、両パック生成部１１０４，１１１４とＰＳマルチプレクサ１１２２との処理の時間差を吸収する。
【０１００】
＜ＡＶストリームの形態＞
本実施形態において用いるＡＶストリームの構成について、図２３および図２４を用いて説明する。
【０１０１】
ＡＶストリーム７０１は、整数個のＣＵ(Continuous Unit) ７０２で構成される。ＣＵ７０２は、ディスク上で連続的に記録する単位である。ＣＵ７０２の長さは、ＡＶストリーム７０１を構成するＣＵ７０２をどのように光ディスク１０６上に配置してもシームレス再生（再生中に画像や音声が途切れないで再生できること）やリアルタイムアフターレコーディング（アフレコ対象のビデオをシームレス再生しながらオーディオを記録すること）が保証されるように設定される。この設定方法については後述する。
【０１０２】
ＣＵ７０２は、先頭から連続する番号が♯１，♯２，…，♯Ｌのように付与されており、各ＣＵ７０２は整数個のＶＵ(Video Unit)７０３から構成される。ＶＵ７０３は、単独再生可能な単位であり、そのことから再生の際のエントリポイントとなり得る。また、ＶＵ７０３も、先頭から連続する番号が♯１，♯２，…，♯Ｍのように付与される。
【０１０３】
図２４は、ＶＵ７０３構成を示している。ユニットとしてのＶＵ７０３は、１秒程度のビデオデータを格納した複数（整数個）のＧＯＰ７０４（画像データ群）と、それらと同じ時間に再生されるオーディオデータを格納した複数（整数個）のオーディオ復号単位であるＡＡＵ７０５とから構成される。
【０１０４】
なお、ＧＯＰ７０４は、ＭＰＥＧ２ビデオ規格における画像圧縮の単位であり、複数のビデオフレーム（典型的には１５フレーム程度）で構成される。ＡＡＵ７０５は、ＭＰＥＧ１オーディオのレイヤＩＩ(Layer-II)規格における音声圧縮の単位で、１１５２点の音波形サンプル点により構成される。サンプリング周波数が４８kHzの場合、ＡＡＵ７０５あたりの再生時間は０．０２４秒となる。ＶＵ７０３中では、ＡＶ同期再生のために必要となる遅延を小さくするため、ＡＡＵ７０５が配置され、それに続いてＧＯＰ７０４が配置される。
【０１０５】
また、ＶＵ７０３単位で独立再生を可能とするために、ＶＵ７０３におけるビデオデータ（ＧＯＰ７０４）の先頭には、ランダムアクセスの頭出しのために用いられるＳＨ(Sequence Header) ７０６が配置される。ＶＵ７０３の再生時間は、ＶＵ７０３に含まれるビデオフレーム数にビデオフレーム周期を乗算した時間と定義する。
【０１０６】
ビデオデータについては、ＴＳ／ＰＳへの変換の容易さを考慮して、ピクチャ層(picture header())におけるvbv＿delay に以下の制限を設ける。まず、ＭＰＥＧ２ビデオ規格におけるvbv＿delay について説明する。ＭＰＥＧ２ビデオ規格において、vbv＿delay は、一定速度のＣＢＲ(Constant Bit Rate) の場合、ストリーム検証用の仮想的なモデルであるＶＢＶ(Video Buffering Verifier)におけるＶＢＶバッファにピクチャの最初のデータが入ってから、実際にそのピクチャがデコードされるまでの遅延時間を格納している。一方、可変速度のＶＢＲ(Variable Bit Rate) の場合、vbv＿delay は、ＣＢＲと同様に遅延時間を格納することも、格納しないことも可能である。なお、遅延時間を格納していないことを示すために、vbv＿delay に０ｘＦＦＦＦを格納する。
【０１０７】
本実施形態では、vbv＿delay に対して、ＶＢＲの場合においても必ず、遅延時間を格納するように制限する。このことによって、後述するように、ＴＳ／ＰＳに変換する際、ＭＰＥＧ規格に沿った多重化が容易になる。
【０１０８】
＜ＡＶストリーム管理方法＞
ＡＶストリームの管理方法は、前述の QuickTimeファイルフォーマットをベースにしている。
【０１０９】
図２５は、ＡＶストリーム管理形態を示している。ビデオデータ，オーディオデータをそれぞれビデオトラック，オーディオトラックで管理し、ビデオトラックについては、１個のＧＯＰ７０４を１サンプル(Sample)、ＶＵ７０３におけるビデオの塊となるＶＣ(Video Cghunk)７０７を１チャンクとして管理する。オーディオトラックについては、ＡＡＵ７０５を１サンプル、ＶＵ７０３中のオーディオの塊となるＡＣ(Audio Chunk) ７０８を１チャンクとして管理する。
【０１１０】
＜ＣＵ単位決定方法＞
次に、ＣＵ単位決定方法について説明する。この決定方法では、基準となるデバイス(リファレンスデバイスモデル)を想定し、その上でシームレス再生が破綻しないように連続記録単位を決める。
【０１１１】
まず、リファレンスデバイスモデルについて図２６を用いて説明する。
【０１１２】
リファレンスデバイスモデルは、１個のピックアップとそれにつながるＥＣＣエンコーダデコーダ５０１、トラックバッファ５０２、デマルチプレクサ５０３、アフレコ（アフターレコーディング）用バッファ５０４、オーディオエンコーダ５０９、ビデオバッファ５０５、オーディオバッファ５０６、ビデオデコーダ５０７、およびオーディオデコーダ５０８によって構成される。
【０１１３】
本モデルにおけるシームレス再生は、ＶＵのデコード開始時にトラックバッファ５０２上に少なくとも１個のＶＵが存在すれば保証されるものとする。オーディオフレームデータのＥＣＣエンコーダ５０１へのデータ入力速度およびＥＣＣデコーダ５０１からのデータ出力速度をＲｓとする。
【０１１４】
また、アクセスによる読み出し、記録の停止する最大期間をＴａとする。さらに、短いアクセス（１００トラック程度）に要する時間をＴｋとする。これらの期間（時間）には、シーク時間、回転待ち時間、アクセス後に最初にディスクから読み出したデータがＥＣＣから出力されるまでの時間が含まれる。本実施形態では、Ｒｓ＝２０Mbps、Ｔａ＝１秒、Ｔｋ＝０．２秒とする。
【０１１５】
前記のリファレンスデバイスモデルにおいて再生を行った場合、次のような条件を満たせば、トラックバッファ５０２のアンダーフローがないことが保証できる。
【０１１６】
条件を示す前にまず、記号を定義する。ＡＶストリームを構成するｉ番目の連続領域をＣ♯ｉとし、Ｃ♯ｉ中に含まれる再生時間をＴｃ(i) とする。Ｔｃ(i) は、Ｃ♯ｉ中に先頭が含まれているＶＵの再生時間の合計とする。また、Ｃ♯ｉからＣ♯ｉ＋１へのアクセス時間をＴａとする。
【０１１７】
また、再生時間Ｔｃ(i) 分のＶＵ読み出し時間をＴｒ(i) とする。この場合、トラックバッファ５０２をアンダーフローさせない条件とは、分断ジャンプを含めた最大読み出し時間をＴｒ(i) としたとき、任意のＣ♯ｉにおいて、
Ｔｃ(i) ≧Ｔｒ(i) ＋Ｔａ …式１
が成立することである。
【０１１８】
なぜなら、この式はシームレス再生の十分条件である、
【０１１９】
【数１】
を満たす十分条件であるためである。
【０１２１】
式１中のＴｒ(i) に、Ｔｒ(i) ＝Ｔｃ(i) ×（Ｒｖ＋Ｒａ）／Ｒｓを代入して、Ｔｃ(i) で解くと、シームレス再生を保証可能なＴｃ(i) の条件
Ｔｃ(i) ≧（Ｔａ×Ｒｓ）／（Ｒｓ−Ｒｖ−Ｒａ） …式２
が得られる。ここで、Ｒａはオーディオデータのビットレートであり、Ｒｖはビデオデータのビットレートである。
【０１２２】
つまり、各連続領域に先頭の含まれるＶＵの合計が上式を満たすようにすれば、シームレス再生を保証可能である。このとき、各連続領域には合計の再生時間が上式を満たす完全なＶＵ群を含むように制限してもよい。
【０１２３】
＜録画時の処理＞
ユーザから録画が指示された場合のホストＣＰＵ１０１が前述のデータ記録プログラムを実行することによって実現される処理を、図２７を参照しながら説明する。
【０１２４】
このとき記録するＡＶストリームは、ビデオのビットレートＲｖの上限が５Mbpsであり、オーディオのビットレートＲａが２５６kbpsであり、ＶＵ再生時間Ｔｖが約０．５秒固定ストリームであるとする。また、ファイルシステムの管理情報はすでにＲＡＭ１０２上に読み込まれているものとする。
【０１２５】
まず、ストリームの構成や連続領域の構成を決定する（Ｓ７０１）。ここでは、１ＶＵを１ＧＯＰ１５フレームで構成するとしたとき、式２にＲｓ＝２０Mbps、Ｔａ＝１秒、Ｒｖ＝５Mbps、Ｒａ＝２５６kbpsを代入し、Ｔ(c) の範囲１．４秒以上が得られる。Ｔｖが約０．５秒であるため、ＣＵは３個のＶＵで構成すればよい。
【０１２６】
まず、ＲＡＭ１０２上のSpace Bitmapを参照して９個のＶＵを連続的に記録可能な空き領域を探す。空き領域が存在しなければ、録画を中止し、録画できないことをユーザに知らせる（Ｓ７０２）。
【０１２７】
また、オーディオエンコーダ１１７およびビデオエンコーダ１１８をそれぞれ起動する（Ｓ７０３）。そして、記録用バッファ１１４に１ＥＣＣブロック分（例えば３２KB）以上のデータが蓄積されているか否かをチェックする（Ｓ７０４）。
【０１２８】
１ＥＣＣブロック分以上のデータが蓄積されていれば、次に記録するディスク上のＥＣＣブロックの空き状況をＲＡＭ１０２上のSpace Bitmapを参照して調べる（Ｓ７０５）。ＥＣＣブロックの空きがなければ、３個のＶＵを記録可能な連続的な空き領域を探し（Ｓ７０６）、その空き領域の先頭へピックアップを移動させる（Ｓ７０７）。
【０１２９】
そして、記録用バッファ１１４中の１ＥＣＣブロック分のデータをディスクに記録して（Ｓ７０８）、処理をＳ７０４に戻す。また、Ｓ７０５でＥＣＣブロックの空きがあれば、Ｓ７０８の記録を行う。Ｓ７０５〜Ｓ７０８の処理は、Ｓ７０４で１ＥＣＣブロック分以上のデータが蓄積されていないと判定されるまで繰り返される。一方、Ｓ７０４で記録用バッファ１１４に１ＥＣＣブロック分のデータが蓄積されていないと判定されると、記録終了が指示されているかどうかをチェックし（Ｓ７０９）、記録終了が指示されていない場合はＳ７０４を実行する。
【０１３０】
Ｓ７０９で記録終了が指示されていた場合、以下のステップを実行する。まず、記録用バッファ１１４における１ＥＣＣブロックに満たないデータに関して、末尾にダミーデータを付加し１ＥＣＣブロックにする（Ｓ７１０）。次に、Ｓ７０５〜Ｓ７０８と同様にして、そのデータをディスク上に記録する（Ｓ７１１〜Ｓ７１４）。ＲＡＭ１０２上の QuickTime管理情報（Movie atom）とファイルシステム管理情報とを光ディスク１０６に記録して（Ｓ７１５，７１６）、処理を終える。
【０１３１】
以上の処理と並行するオーディオエンコーダ１１７、ビデオエンコーダ１１８やマルチプレクサ１１３の動作について説明する。ビデオエンコーダ１１８およびオーディオエンコーダ１１７がエンコードした結果は、それぞれビデオ記録用バッファ１１８およびオーディオ記録用バッファ１１９に一時的に蓄えられる。マルチプレクサ１１３は、ビデオ記録用バッファ１１８およびオーディオ記録用バッファ１１９からそれぞれデータを読み出し、それらの多重化を行い、記録用バッファ１１４に格納する。
【０１３２】
１ＶＵ分のデータ、つまり１ＧＯＰとそれに同期して再生されるＡＡＵが記録用バッファ１１４に蓄積されたら、マルチプレクサ１１３は記録用バッファ１１４に１ＶＵのデータを送る。
【０１３３】
さらに、マルチプレクサ１１３が、ホストＣＰＵ１０１に１ＶＵ分のデータがエンコードできたことを通知すると、ホストＣＰＵ１０１はＶＵを構成するＧＯＰやＡＡＵの数およびサイズを基にＲＡＭ１０２上の QuickTime管理情報を更新する。
【０１３４】
＜ＴＳ変換時の処理＞
本実施形態におけるＴＳ変換時の処理を説明する。まず、ここでは、ビデオおよびオーディオそれぞれのＴＳパケット生成手順について説明した後、それらを多重化してＴＳを出力する手順について説明する。
【０１３５】
なお、ＴＳ変換を開始する時点に変換対象のムービーファイルのMovie atomの内容はＲＡＭ１０２に読み込まれているとする。
【０１３６】
（１）ビデオＴＳパケット生成
まず、前述のビデオＰＥＳパケット生成部１１０１、ビデオＴＳパケット生成部１１０２およびビデオ解析部１１３１によるビデオＴＳパケットの生成手順を図２８を用いて説明する。
【０１３７】
ここでは、図２８に示すように、エレメンタリストリームとしてのＡＶストリーム中のｉ番目のビデオチャンクに対応するビデオデータをビデオチャンクVChunk(i) と称し、ＡＶストリーム中のｊ番目のオーディオチャンクに対応するオーディオデータをオーディオチャンクAChunk(j) と称する。以下の説明では、ビデオチャンクVChunk(i) を例に挙げる。VChunk(i) のトラック上での再生時刻は、Movie atom（図３参照）の情報から取得することができ、それをＴｖ(i) とする。
【０１３８】
ビデオＰＥＳパケット生成部１１０１は、ビデオ再生用バッファ１１０から読み出されたビデオエレメンタリストリームにおけるビデオチャンクVChunk(i) をビデオフレーム単位（ビデオフレームデータ）に分割する。ビデオチャンクVChunk(i) を構成するビデオフレーム数がＮ(i) であるとき、それらのビデオフレームデータをVFRM(i,0) ，VFRM(i,1) ，…，VFRM(i,N(i)-1)と称する。ビデオフレームの境界は、図２２に示すビデオ解析部１１３１がVChunk(i) を解析し、picture＿header()を検出することで得られる。なぜなら、ビデオフレームデータの先頭には、picture＿header()が存在するため、picture＿header()を検出することは、ビデオフレームデータの先頭位置すなわち境界位置を得ることになる。なお、picture＿header()の先頭は、特性のビットパターンであるため、ビデオエレメンタリストリーム中から容易に検出することができる。また、ビデオ解析部１１３１は、その解析の際、前述のpicture＿header()から、各フレームのピクチャタイプ（Ｉ，Ｐ，Ｂ）も同時に取得する。
【０１３９】
また、ビデオＰＥＳパケット生成部１１０１は、各ビデオフレームデータの先頭データが前述のＶＢＶバッファに入ってからデコードを行うまでの遅延量を求める。ｎ番目のビデオフレームデータの遅延量をＶＤＥＬＡＹ(i,n) と称し、ｎ番目のビデオフレームデータのpicture header()中のvbv＿delay を用いる。また、ビデオＰＥＳパケット生成部１１０１は、このビデオストリーム中での最大ビットレートを示す、sequence header() 中のbitrateを取得し、変数Ｒmax に格納する。
【０１４０】
次に、ビデオＰＥＳパケット生成部１１０１は、ビデオフレームデータをＰＥＳパケットにパケット化する。ＰＥＳパケットVPKT(i,0) ，VPKT(i,1) ，…，VPKT(i,N(i)-1)は、ビデオフレームデータVFRM(i,0) ，VFRM(i,1) ，…，VFRM(i,N(i)-1)から、それぞれ一対一の対応で生成される。
【０１４１】
各ＰＥＳパケットのヘッダ部分には、ビデオデータであることの属性を表すstream id やＰＴＳ(Presentation Time Stamp) およびＤＴＳ(Decording Time Stamp)の２種類のタイムスタンプが設定される。このうち、stream id には１１１０００００ｂが設定される。また、ｎ番目のＰＥＳパケットのＰＴＳ，ＤＴＳをそれぞれＶＰＴＳ(i,n)，ＶＤＴＳ(i,n) と呼ぶとき、ＶＰＴＳ(i,n) ，ＶＤＴＳ(i,n) は次のルールで設定される。
【０１４２】
なお、各フレームの後に連続するＢピクチャの個数をｂ(n) と呼ぶ。例えば、Ｉ，Ｂ，Ｂ，Ｐ，…のピクチャが連続するＧＯＰ構成の場合、０番目のビデオフレームであるＩピクチャに対するｂ(0) は２となる。また、ビデオフレーム周期を９kHz クロックでカウントした値をＴｆとする。まず、VChunk(i) 中にＢピクチャが存在する場合は、ＩピクチャおよびＰピクチャに対し、
ＰＴＳ(i,n) ＝Ｔｖ(i) ＋（ｎ＋ｂ(n) ）×Ｔｆ
ＤＴＳ(i,n) ＝Ｔｖ(i) ＋（ｎ−１）×Ｔｆ
を設定し、Ｂピクチャに対し、
ＰＴＳ(i,n) ＝Ｔｖ(i) ＋（ｎ−１）×Ｔｆ
ＤＴＳ(i,n) ＝Ｔｖ(i) ＋（ｎ−１）×Ｔｆ
を設定する。一方、VChunk(i) 中にＢピクチャが存在しない場合、各ビデオフレームに対し、
ＰＴＳ(i,n) ＝ＤＴＳ(i,n) ＝Ｔｖ(i) ＋ｎ×Ｔｆ
を設定する。
【０１４３】
次に、ビデオＴＳパケット生成部１１０２によるＴＳパケットの生成について説明する。
【０１４４】
ビデオＴＳパケット生成部１１０２は、各ＰＥＳパケットを先頭から１８４バイト単位で所定の大きさに分割し、分割されたデータの直前にＴＳパケットのヘッダを４バイト付加することによってＴＳパケットを生成する。ここで、図２８に示すように、ｎ番目のビデオＰＥＳパケットであるVPKT(i,n) からＫ(i,n) 個のＴＳパケットが生成される場合、それぞれのＴＳパケットをVTSP(i,n,0) ，VTSP(i,n,1) ，…，VTSP(i,n,K(i,n)-1)と称する。
【０１４５】
このとき、ビデオＴＳパケット生成部１１０２は、それぞれのＴＳパケットに対し、理想的なＰＣＲ(System Clock Reference)を付与する。このＰＣＲの値は、ＴＳパケット中には格納されず、あくまでも後段のＴＳパケット多重化の際の多重タイミング設定の指標に用いるための情報である。ここで、ｋ番目のＴＳパケットに対応する理想的なＰＣＲをＶＰＣＲ(i,n,k) とする。ｋ＝０の場合、
ＶＰＣＲ(i,n,k) ＝ＤＴＳ(i,n) −ＶＤＥＬＡＹ(i,n)
とする。一方、０＜ｋ＜Ｋ(i,n) の場合、
ＶＰＣＲ(i,n,k) ＝ＶＰＣＲ(i,n,0) ＋１８４×８×ｋ×27000000/Ｒmax
とする。
【０１４６】
また、ビデオＴＳパケットのヘッダ中の各フィールドには次のように値を設定する。例えば、パケットを識別するためのＰＩＤ(Packet Identification) に０ｘ１０１１を格納し、ＴＳパケットがＰＥＳパケットの先頭バイトを含んでいた場合、ペイロード(payload unit start indicator)に１をセットする。
【０１４７】
生成されたビデオＴＳパケットは、上記のＶＰＣＲを付与された状態でビデオＴＳパケット用バッファ１１０３に順に送られ、図２８に示すように、ビデオチャンクやビデオフレームの区別が取り去られて一次元でアクセス可能になる。すなわち、ビデオＴＳパケット総数をVCOUNTとすると、生成された順にＶＴＳＰ(0) ，ＶＴＳＰ(1) ，…，ＶＴＳＰ(VCOUNT-1)と呼ぶことになる。
【０１４８】
（２）オーディオＴＳパケット生成
続いて、前述のオーディオＰＥＳパケット生成部１１１１およびオーディオＴＳパケット生成部１１１２によるオーディオＴＳパケットの生成手順を図２９を用いて説明する。
【０１４９】
図２９に示すように、ＡＶストリーム中のｊ番目のオーディオチャンクに対応するオーディオデータをAChunk(j) と称する。以下の説明では、オーディオチャンクAChunk(j) を例に挙げる。AChunk(j) のトラック上での再生時刻は、オーディオデータを管理しているトラックのsample table atom （図７参照）を参照することで取得可能であり、sample table atom を含むMovie atom（図３参照）の情報から取得することができ、それをＴｐ(j)とする。
【０１５０】
オーディオＰＥＳパケット生成部１１１１は、オーディオ再生用バッファ１１１から読み出されたオーディオエレメンタリストリームにおけるオーディオチャンクAChunk(j) をオーディオフレーム単位（オーディオフレームデータ）に分割する。分割のために必要な情報は、AChunk(j) を構成する各オーディオフレームのデータ長である。各オーディオフレームのデータ長は、オーディオデータを管理しているトラックのsample size atom（図９参照）を参照することで取得可能である。オーディオチャンクAChunk(j) を構成するオーディオフレーム数がＭ(j) であるとき、それらのオーディオフレームデータをAFRM(j,0) ，AFRM(j,1) ，…，AFRM(j,M(j)-1)と称する。また、ｍ番目のオーディオフレームのデータ長をAFLEN(j,m)とする。
【０１５１】
次に、オーディオＰＥＳパケット生成部１１１１は、オーディオフレームデータをＰＥＳパケットにパケット化する。ＰＥＳパケットAPKT(j,0) ，APKT(j,1) ，…，APKT(j,M(i)-1)は、オーディオフレームデータAFRM(j,0) ，AFRM(j,1) ，…，AFRM(j,M(j)-1)から、それぞれ一対一の対応で生成される。
【０１５２】
各ＰＥＳパケットのヘッダ部分には前述のstream idやＰＴＳが設定される。このうち、stream idには１１００００００が設定される。また、ｍ番目のＰＥＳパケットのＰＴＳをＡＰＴＳ(j,m) と呼び、オーディオフレーム周期を９KHzクロックでカウントした値をＴafとしたときＡＰＴＳ(j,m) は、
ＡＰＴＳ(j,m) ＝Ｔｐ(j) ＋ｍ×Ｔaf
とする。上記のＴafは、Sample tableから取得することが可能である。
【０１５３】
次に、オーディオＴＳパケット生成部１１１２によるＴＳパケットの生成について説明する。
【０１５４】
オーディオＴＳパケット生成部１１１２は、各ＰＥＳパケットを先頭から１８４バイト単位で所定の大きさ分割し、分割されたデータの直前にＴＳパケットのヘッダを４バイト付加することによってＴＳパケットを生成する。ここで、図２９に示すように、ｎ番目のオーディオＰＥＳパケットであるAPKT(j,m) からＨ(j,m) 個のＴＳパケットが生成される場合、それぞれのＴＳパケットをATSP(j,m,0) ，ATSP(j,m,1) ，…，ATSP(j,m,H(j,m)-1)と称する。
【０１５５】
このとき、前述のビデオＴＳパケットの生成時と同様、それぞれのＴＳパケットに対し、理想的なＰＣＲを付与する。このＰＣＲの値は、ＴＳパケット中には格納されず、あくまでも後段のＴＳパケット多重化の際の多重タイミング設定の指標に用いるための情報である。ここで、ｈ番目のＴＳパケットに対応する理想的なＰＣＲをＡＰＣＲ(j,m,h) とする。ｈ＝０の場合、オーディオのビットレートをＲａとしたとき、
ＡＰＣＲ(j,m,h) ＝ＡＰＴＳ(j,m) −ＡＦＬＥＮ(j,m) ×８×２／Ｒａ
にする。一方、０＜ｈ＜Ｈ(j,m) の場合、
ＡＰＣＲ(j,m,h) ＝ＡＰＣＲ(j,m,0) ＋１８４×８×ｈ×27000000／Ｒａ
とする。上記のＲａは、Sample table中のサンプルのdurationとsizeとから求めることが可能である。
【０１５６】
また、オーディオＴＳパケットのヘッダ中の各フィールドには次のように値を設定する。例えば、ＰＩＤには、０ｘ１０２１を格納し、ＴＳパケットがＰＥＳパケットの先頭バイトを含んでいた場合、前述のペイロードに１をセットする。
【０１５７】
生成されたオーディオＴＳパケットは、上記のＡＰＣＲを付与された状態でオーディオＴＳパケット用バッファ１１１３に順に送られ、図２９に示すように、オーディオチャンクやオーディオフレームの区別が取り去さられて一次元でアクセス可能になる。すなわち、オーディオＴＳパケット総数をACOUNTとすると、生成された順にＡＴＳＰ(0) ，ＡＴＳＰ(1) ，…，ＡＴＳＰ(ACOUNT-1)と呼ぶことになる。
【０１５８】
（３）ＴＳパケット多重化
上記のようにして生成されたビデオおよびオーディオのＴＳパケットからＴＳマルチプレクサ１１２１によってＴＳを生成するための手順を、図３０に示すフローチャートを用いて説明する。
【０１５９】
まず、現在の処理対象のＴＳパケットのカウンタ値ＳＴＣを初期化する（Ｓ１１０１）。初期化には、ＶＰＣＲおよびＡＰＣＲのうち最も値の小さいものを用いる。次に、ビデオＴＳパケット用バッファ１１０３に蓄えられているビデオＴＳパケットおよびオーディオＴＳパケットバッファ１１１３に蓄えられているオーディオＴＳパケットをそれぞれ指定するためのインデックスであるvindexおよびaindexをリセットする（Ｓ１１０２）。そして、以下の処理をビデオＴＳパケット用バッファ１１０３およびオーディオＴＳパケット用バッファ１１１３が空になるまで、すなわちvindexまたはaindexが所定値のVCOUNTまたはACOUNTに達するまで行う（ステップＳ１１０３）。
【０１６０】
まず、ＰＣＲおよびＳＩ(Service Information) やＰＳＩ(Program Specific Information)を挿入するタイミングをチェックし（Ｓ１１０４）、現在のＳＴＣがＰＣＲ／ＰＳＩ／ＳＩを挿入するタイミングであるか否かをチェックする（Ｓ１１０５）。ＰＣＲを挿入する間隔は、ＭＰＥＧ規格によって、０．１秒以下に規定されている。また、ＳＩ／ＰＳＩの挿入間隔についてもＡＲＩＢ(Association of Radio Industries and Buisiness) ＳＴ-Ｂ２１によって規定されている。したがって、前回挿入したときのＳＣＲの値を記憶しておき、前回のＳＴＣ値と現在のＳＴＣ値の差分が０．１秒になったときが挿入するタイミングとなる。もし、挿入するタイミングであった場合、ＴＳパケットを生成しＰＣＲ／ＰＳＩ／ＳＩの挿入を行う（ステップＳ１１０６）。ＰＣＲを含むＴＳパケットの場合、ＰＣＲには現在のＳＴＣの値を設定する。
【０１６１】
Ｓ１１０５で、挿入するタイミングでなかった場合、次に、aindexで指し示されるＡＴＳＰのＡＰＣＲの値がＳＴＣの値以上であるか否かを調べる（Ｓ１１１１）。ＡＰＣＲの値がＳＴＣの値以上であった場合、ＡＴＳＰ(aindex)を出力し（Ｓ１１１２）、aindexをインクリメントする（Ｓ１１１３）。
【０１６２】
Ｓ１１１１で、ＡＰＣＲの値がＳＴＣの値未満であった場合（ＡＴＳＰを出力するタイミングでなかった場合）、vindexで指し示されるＶＴＳＰのＶＰＣＲの値がＳＴＣの値以上であるか否かを調べる（Ｓ１１２１）。ＶＰＣＲの値がＳＴＣの値以上であった場合、ＶＴＳＰ(vindex)を出力し（Ｓ１１２２）、vindexをインクリメントする（Ｓ１１２３）。
【０１６３】
Ｓ１１２１で、ＶＰＣＲの値がＳＴＣの値未満であった場合（現在のＳＴＣの値が何も出力するタイミングでなかった場合）、null packet を出力する（Ｓ１１３１）。
【０１６４】
そして、何らかのＴＳパケットを出力したら、ＳＴＣをインクリメントする(Ｓ１１０７)。ＳＴＣのインクリメント量は、ＴＳ転送用に確保したビットレートによって決定される。ＴＳ転送用のビットレートを２７Mbpsと設定しており、インクリメント量ΔＳＣＲは１５０４となる。
【０１６５】
＜ＰＳ変換時の処理＞
本実施形態では、DVD-Video やDVD-Video Recording 規格を想定して１パックが２０４８バイトになるようにＥＳ−ＰＳ変換を行う。
【０１６６】
なお、変換対象のムービーファイルのMovie atomの内容はＲＡＭ１０２に読み込まれているとする。
【０１６７】
（１）ビデオパック生成
まず、前述のビデオＰＥＳパケット生成部１１０１およびビデオパック生成部１１０４によるビデオパックの生成手順を図３１を用いて説明する。
【０１６８】
図３１に示すように、ＡＶストリーム中のｉ番目のビデオチャンクに対応するビデオデータをVChunk(i) と称する。以下の説明では、ビデオチャンクVChunk(i)を例に挙げる。VChunk(i) のトラック上での再生時刻はMovie atomの情報から取得することができ、それをＴｖ(i) とする。
【０１６９】
ビデオＰＥＳパケット生成部１１０１は、前述のビデオＴＳパケット生成の場合と同様にビデオチャンクVChunk(i) をビデオフレーム単位に分割する。このときの手順はＴＳ生成処理と同一であるため、説明を省略する。また、ビデオＰＥＳパケット生成部１１０１は、ビデオフレームデータをＰＥＳパケットにパケット化する。ＰＥＳパケットは、ビデオフレームデータVFRM(i,0) ，VFRM(i,1) ，…，VFRM(i,N(i)-1)から、それぞれ複数生成される。
【０１７０】
ここでは、ｎ番目のビデオフレームデータを例に挙げて説明する。VFRM(i,n)の先頭から、２０３４バイト単位でデータを切り出し、パケットに格納する。ただし、先頭だけはＰＴＳおよびＤＴＳを格納する空間が必要であるために２０１９バイトでデータを切り出す。さらに、VFRM(i,0) の先頭については、２４バイトのシステムヘッダ(System Header) を挿入する必要があるため、さらに短い１９９５バイトでデータ切り出す。生成されたパケット数がＧ(i,n)個であるとき、ＰＥＳパケットとしてVPKT(i,n,0) ，VPKT(i,n,1) ，…，VPKT(i,n,G(i,n)-1)が生成される。このうち、先頭のパケットとしてのVPKT(i,n,0) には、ＰＴＳおよびＤＴＳを設定する必要があり、設定する値については、前述のＴＳ変換の場合について説明したルールで計算する。
【０１７１】
次に、ビデオパック生成部１１０４によるビデオパックの生成について説明する。
【０１７２】
ビデオパック生成部１１０４は、所定数のＰＥＳパケットを１４バイトのパックヘッダの後に格納してグループ化し、VChunk(i) の先頭のVPKT(i,0,0) の場合、パックヘッダとＰＥＳパケット群との間に前記のシステムヘッダを挿入する。ここで、ｇ番目のビデオＰＥＳパケットVPKT(i,n,g) に対応するビデオパックをVPCK(i,n,g) と称する。
【０１７３】
このとき、ビデオパック生成部１１０４は、それぞれのパックのパックヘッダに対し、以下のような計算で求めたＳＣＲを格納する。このＳＣＲの値は、ＰＳ多重化の際に実際の値に書き換えられる。ここで、ｇ番目のパックに対応する、計算上のＳＣＲをＶＰＣＲ(i,n,g) とする。ｋ＝０の場合、
ＶＳＣＲ(i,n,g) ＝ＤＴＳ(i,n) −ＶＤＥＬＡＹ(i,n)
とする。一方、０＜ｇ＜Ｇ(i,n) の場合、
ＶＳＣＲ(i,n,g) ＝ＶＰＣＲ(i,n,0) ＋２０４８×８×ｋ×27000000/Ｒmaxとする。また、パックヘッダ中の、多重化ビットレートを示すフィールドprogram mux rateには、１００８Mbpsを示す０ｘ０１８９ｃ３を格納する。
【０１７４】
生成されたビデオパックは、上記のＶＳＣＲを付与された状態でビデオパック用バッファ１１０５に順に送られ、図３１に示すように、ビデオチャンクやビデオフレームの区別が取り去さられて一次元でアクセス可能になる。すなわち、ビデオパック総数をVCOUNTとすると、生成された順にＶＰＣＫ(0) ，ＶＰＣＫ(1) ，…，ＶＰＣＫ(VCOUNT-1)と呼ぶことになる。
【０１７５】
（２）オーディオパック生成
続いて、前述のオーディオＰＥＳパケット生成部１１１１およびオーディオパック生成部１１１４によるオーディオパックの生成手順を図３２を用いて説明する。
【０１７６】
図３２に示すように、ＡＶストリーム中のｊ番目のオーディオチャンクに対応するオーディオデータをAChunk(j) と称する。以下の説明では、オーディオチャンクAChunk(j) を例に挙げる。AChunk(j) のトラック上での再生時刻はMovie atomの情報から取得することができ、それをＴｐ(j) とする。
【０１７７】
オーディオＰＳパケット生成部１１１１は、前述のオーディオＴＳパケット生成の場合と同様に、オーディオチャンクAChunk(j) をオーディオフレーム単位に分割する。このときの手順は、ＴＳ生成処理の場合と同一であるため、その説明を省略する。また、オーディオＰＳパケット生成部１１１１は、オーディオフレームデータをＰＥＳパケットにパケット化する。ＰＥＳパケットは、オーディオフレームデータAFRM(j,0) ，AFRM(j,1) ，…，VFRM(j,M(i)-1)からそれぞれ複数生成される。
【０１７８】
ここでは、ｍ番目のオーディオフレームデータを例に挙げて説明する。AFRM(j,m)の先頭から、２０２５バイト単位でデータを切り出し、パケットに格納する。ただし、先頭だけはＰＴＳを格納する空間が必要であるために２０２０バイトでデータを切り出す。生成されたパケット数がＨ(j,m) 個であるとき、ＰＥＳパケットとしてAPKT(j,m,0) ，APKT(j,m,1) ，…，APKT(j,m,H(j,m)-1)が生成される。このうち、先頭のパケットであるAPKT(i,n,0) には、ＰＴＳを設定する必要があり、設定する値については、前述のＴＳ変換の場合について説明したルールで計算する。
【０１７９】
次に、オーディオパック生成部１１１４によるオーディオパックの生成について説明する。
【０１８０】
オーディオパック生成部１１１４は、所定数のＰＥＳパケットを１４バイトのパックヘッダの後に格納してグループ化する。ここで、ｇ番目のオーディオＰＥＳパケットAPKT(j,m,h) に対応するオーディオパックをAPCK(j,m,h) と称する。
【０１８１】
このとき、オーディオパック生成部１１１４は、それぞれのパックのパックヘッダに対し、以下のような計算で求めたＳＣＲを格納する。このＳＣＲの値は、ＰＳ多重化の際に実際の値に書き換えられる。ここで、ｈ番目のパックに対応する、計算上のＳＣＲをＡＰＣＲ(j,m,h) とする。ｈ＝０の場合、
ＡＳＣＲ(j,m,h) ＝ＡＰＴＳ(j,m) −ＡＦＬＥＮ(j,m) ×８×２／Ｒａ
にする。一方、０＜ｈ＜Ｈ(j,m) の場合、
ＡＳＣＲ(j,m,h) ＝ＡＳＣＲ(j,m,0) ＋２０４８×８×ｈ×27000000/Ｒａ
とする。また、パックヘッダ中の、多重化ビットレートを示すフィールドprogram mux rateには、１００８Mbpsを示す０ｘ０１８９ｃ３を格納する。
【０１８２】
生成されたオーディオパックは、上記のＡＳＣＲを付与された状態でオーディオパック用バッファ１１１５に順に送られ、図３２に示すように、オーディオチャンクやオーディオフレームの区別が取り去られて一次元でアクセス可能になる。すなわち、オーディオパック総数をACOUNTとしたとき、生成された順にＡＰＣＫ(0) ，ＡＣＰＫ(1) ，…，ＡＣＰＫ(ACOUNT-1)と呼ぶことになる。
【０１８３】
（３）パック多重化
以上のようにして生成されたビデオおよびオーディオのパックからＰＳマルチプレクサ１１２２によってＰＳを生成するための手順を、図３３に示すフローチャートを用いて説明する。
【０１８４】
まず、現在のカウンタ値ＳＴＣを初期化する（Ｓ１２０１）。初期化には、ＶＳＣＲおよびＡＳＣＲのうち最も値の小さいものを用いる。次に、ビデオパック用バッファ１１０５に蓄えられているビデオパックおよびオーディオパック用バッファ１１１５に蓄えられているオーディオパックをそれぞれ指定するためのインデックスであるvindexおよびaindexをリセットする（Ｓ１２０２）。そして、以下の処理をビデオパック用バッファ１１０５およびオーディオパック用バッファ１１１５が空になるまで、すなわちvindexまたはaindexが所定値のVCOUNTまたはACOUNTに達するまで行う（Ｓ１２０３）。
【０１８５】
まず、aindexで指し示されるオーディオパックＡＰＣＫのＡＳＣＲの値がＳＴＣの値以上であるか否かを調べる（Ｓ１２０４）。ＡＳＣＲの値がＳＴＣの値以上であった場合、ＡＰＣＫ(aindex)を出力し（Ｓ１２０５）、aindexをインクリメントする（Ｓ１２０６）。
【０１８６】
Ｓ１２０４で、ＡＰＣＫを出力するタイミングでなかった場合、vindexで指し示されるＶＰＣＫのＶＳＣＲの値がＳＴＣの値以上であるか否かを調べる（Ｓ１２１１）。ＶＳＣＲの値がＳＴＣの値以上であった場合、ＶＴＳＰ(vindex)を出力し（Ｓ１２１２）、vindexをインクリメントする（Ｓ１２１３）。
【０１８７】
なお、各パックの出力の際には、パックヘッダのＳＣＲの値を現在のＳＴＣの値に書き換える。
【０１８８】
次に、現在のＳＴＣに該当するパックの有無にかかわらず、ＳＴＣをインクリメントする(Ｓ１２０７)。ＳＴＣのインクリメント量は、転送ビットレートによって決定される。ここでは、DVD-Video を対象にしているため、転送用ビットレートを１００８Mbpsと設定しており、インクリメント量ΔＳＣＲは４３８７５となる。
【０１８９】
〔第２の実施形態〕
本発明の第２の実施形態について、図３４ないし図３６を用いて説明する。
【０１９０】
本実施形態は、ＴＳ／ＰＳ変換のために必要な情報をビデオデータを解析する必要がないように、ビデオデータ外にそれらの情報をあらかじめ記録しておく点が第１の実施形態と異なっている。本実施形態は、第１の実施形態と共通する部分が多いため、主に相違点について説明する。
【０１９１】
＜システム構成＞
図３４に示すように、本実施形態におけるビデオディスクレコーダのシステム構成は、第１の実施形態のシステム構成と、ビデオ解析部１１３１を備えていないことを除いてほぼ同一である。その他の構成要素は、第１の実施形態の構成要素と同じであり、同じ構成要素については共通の符号を用いている。
【０１９２】
＜ＡＶストリームの形態＞
図３５は、本実施形態におけるＡＶストリーム構成を示している。基本的には、第１の実施形態のＡＶストリーム構成（図２５参照）と同一であるが、ＶＵ７０３におけるオーディオデータとビデオデータとの間にＶＦＩ(Video Frame Information) ７０９というデータ領域が設けられている点で異なる。
【０１９３】
ＶＦＩ７０９については、図３６を用いて説明する。ＶＦＩ７０９には、この情報が含まれるＶＵ７０３の各ビデオフレームに関する情報が格納されている。ＶＦＩ７０９中のNumber of framesは、ＶＵ７０３中のビデオフレーム数を示す。１ＧＯＰを１サンプルで管理した場合、Movie atom中の情報から、ＶＵ７０３中の正確なビデオフレーム数が得られる保証はないため、この情報が必要である。また、fsize[i]にはＶＵ７０３中のｉ番目のビデオフレームデータに対応するデータサイズが、ftype[i]にはピクチャタイプが、vdelay[i]にはvbv＿delayがそれぞれ格納されている。また、ビデオデータのビットレートはbitrate に格納されている。このような管理情報をビデオデータ外に設けることで、ＴＳ／ＰＳ変換時にビデオデータを解析する必要がなくなる。これにより、第１の実施形態におけるビデオ解析部１１３１が不要となるので、システム構成が簡略化される。
【０１９４】
ＶＦＩ７０３は、オーディオデータとビデオデータとの間に挿入されている。これにより、ＡＶストリームデータの部分的な移動や削除の際、ＶＦＩ７０９のみが取り残される可能性が低くなる。また、直前のオーディオデータおよび直後のビデオデータの位置はSample tableから分かるため、ＶＦＩ７０９の記録位置を管理するために、ムービーファイル中に管理情報を新規に追加する必要がなくなる。また、ＶＦＩ７０９は、対応するビデオデータの直前に読み出されるので、対応するビデオデータが読み出されたら、直ちにＴＳへの変換のための処理を開始することが可能である。
【０１９５】
なお、本実施形態では、ビデオデータおよびＶＦＩ７０９は同一ファイルに格納されているが、本発明はそれに限定されるものではない。例えば、ビデオデータおよびＶＦＩ７０９が別ファイルであったとしても、ＶＦＩ７０９がビデオデータよりも先に読み出されるように配置されていれば同様の効果を達成できる。
【０１９６】
また、これらの情報をMovie atomではなくＡＶストリーム７０１内に記録することによって、通常再生の際にMovie atomをＲＡＭ１０２に保持するために必要なメモリ量を増大させることがない。
【０１９７】
また、ここでは、ＶＦＩ７０９中にピクチャタイプを記録しているが、ビデオデータのエンコードに際して両方向予測符号化を行わない場合には、ピクチャタイプは不要である。また、両方向予測符号化を行ったとしても、記録すべき情報はピクチャタイプに限定されない。例えば、フレーム間の表示順のようにピクチャタイプを導くことのできる情報であれば何でもよい。
【０１９８】
＜記録処理＞
本実施形態における記録処理は第１の実施形態の録画時の処理と同様であるが、ＡＣ（オーディオチャンク）７０８とＶＣ（ビデオチャンク）７０９との間にＶＦＩ７０９を挿入された状態で記録を行う点が異なる。また、第１の実施形態と異なり、ＶＢＲの場合でも、picture＿header()中のvbv＿delayに０ｘｆｆｆｆをセットしてもよい。なぜなら、vbv＿delayに想到する情報は、前述のＶＦＩ７０９に格納されているからである。
【０１９９】
＜ＴＳ変換時の処理＞
本実施形態におけるＴＳ変換時の処理は第１の実施形態と類似するため、主に相違点を説明する。
【０２００】
（１）ビデオＴＳパケット生成
まず、VChunk(i) の読み出し前に直前のＶＦＩ７０９が読み出されてＲＡＭ１０２に格納されているとする。
【０２０１】
VChunk(i) をビデオフレームデータに分解する際には、ＶＦＩ７０９におけるfsizeを利用する。また、各ビデオフレームデータのピクチャタイプは、ＶＦＩ７０９におけるftypeから直接取得することが可能である。また、VDELAYについてもＶＦＩ７０９におけるvdelayから直接取得することが可能である。またＲｘについてもＶＦＩ７０９におけるbitrateから直接取得することが可能である。このことは、ＶＦＩ７０９をビデオデータとは別にまとめて用意しておくことで、ビデオ解析部１１３１によりビデオデータを解析する必要がなくなったことを意味する。
【０２０２】
なお、「（２）オーディオＴＳパケット生成」および「（３）ＴＳパケット多重化」の処理は第１の実施形態での録画時の処理と同様であるため、その説明を省略する。
【０２０３】
＜ＰＳ変換時の処理＞
ビデオＴＳパケット生成と同様、ＶＦＩ７０９内の情報を用いることで、本処理に必要な各フレームのデータ量、ピクチャタイプおよびvbv＿delayの値を取得可能である。
【０２０４】
＜バリエーション＞
本実施形態では、vbv＿delayに相当する値をＡＶストリーム７０１におけるＧＯＰ７０３外に記録しているが、Movie atom中の例えばUser data atomに記録したとしても、同様の効果が得られる。また、フレーム毎のデータ量やピクチャタイプに関する情報についても同様である。また、ＶＦＩ７０９におけるbitrateは、固定ビットレートの場合はsample tableから算出できるため特に記録する必要はない。また、記録する場合もMovie atom中に記録しても同様の効果が得られることは言うまでもない。
【０２０５】
〔第３の実施形態〕
＜システム構成＞
本実施形態におけるシステム構成は第２の実施形態と共通であるため、その説明を省略する。
【０２０６】
＜ＡＶストリーム管理方法＞
上記のＡＶストリームの管理情報の構成について説明する。ＡＶストリームは、図３７に示すように、ムービーファイル２４０１と、ムービーファイル２４０２とで管理される。
【０２０７】
ムービーファイル２４０１は、Movie data atomに格納された前述のＡＶストリーム７０１（図２３参照）と、ＡＶストリーム７０１を構成するサンプルのアドレスやサイズ、再生時間等を管理するMovie atomとで構成される。ＡＶストリーム７０１は、前述のように、ＣＵ７０２で構成され、各ＣＵ７０２は必ず光ディスク１０６上で連続的に配置されるように記録される。
【０２０８】
一方、ムービーファイル２４０２は、ムービーファイル２４０１における各ＣＵ７０２を管理するｍｏｏｆ(Movie fragment atom) ７１０で構成される。
【０２０９】
この２つのファイル２４０１，２４０２は、図３７に示すように、ＣＵ７０２単位で多重化されて、光ディスク１０６上に連続して記録される。ムービーファイル２４０１では１個のＧＯＰ７０４を１サンプルと扱っているのに対し、ムービーファイル２４０２ではビデオフレームを１サンプルとして扱う。そのため、ムービーファイル２４０１の管理情報に比べ、ムービーファイル２４０２の管理情報量は多くなる。
【０２１０】
また、ビデオフレーム間のフレーム順の入れ替わりを管理するため、前述のsample-composition-time-offsetを用いる。すなわち、sample-durationとsample-composition-time-offsetから、各サンプルのデコードタイミングと表示タイミングが分かる。このことは、各サンプル（ビデオフレーム）のピクチャータイプが分かることを意味する。
【０２１１】
また、ビデオトラックを管理するTrack fragment atomに前記のvbv＿delayを管理するために、独自管理情報であるVBV delay atomを追加定義する。図３８にVBV delay atomの構成を示すように、Track fragment atomで管理されるビデオフレームのvbv＿delayの値を順に格納したものである。なお、このatomは一般のプレーヤでは無視されることになる。
【０２１２】
このように、管理情報をサイズ（大きさ）が異なるサンプルについて２個用意することによって、専用プレーヤで再生するときには、必要なメモリ容量の少ないムービーファイル２４０１を用い、汎用のQuickTime （あるいはISO base media file format）対応プレーヤで再生するときには、ムービーファイル２４０２を用いることで、省メモリと再生互換性とを両立することが可能となる。
【０２１３】
＜記録時の処理＞
本実施形態における記録時の処理は第１の実施形態での録画時の処理と共通しているが、Movie fragmentをContinuous Unit毎に記録する点が異なる。また、第１の実施形態と異なり、ＶＢＲの場合でも、picture＿header()中のvbv＿delayに０ｘｆｆｆｆをセットしてもよい。なぜなら、vbv＿delayに想到する情報は、前述のVBV delay atomに格納されているからである。
【０２１４】
＜ＴＳ変換時の処理＞
（１）ビデオＴＳパケット生成
まず、VChunk(i) の読み出し前に、VChunk(i) に対応するMovie fragment atom ７１０は読み出されてＲＡＭ１０２に格納されているとする。
【０２１５】
本実施形態でVChunk(i) をビデオフレームデータに分解する際には、Track fragment run atom中のsample-sizeから取得した各ビデオフレームデータのデータ量を用いる。また、各ビデオフレームデータのピクチャタイプは次のように取得できる。
【０２１６】
まず、Track fragment run atom 中のsample-composition-time-offset が０のものはＢピクチャと判断できるが、０でなかった場合、Track fragment run atom 中のsample flag を見る。sample flag 中には、対応するサンプル画、キーフレームであるか否かのフラグがあり、そのフラグが１の場合はＩピクチャと判断でき、そうでない場合はＰピクチャと判断できる。また、ＶＤＥＬＡＹについては、Track fragment atom 中のVBV delay atomの値から直接取得可能である。つまり、第２実施形態と同様、ビデオ解析部１１３１によりビデオデータを解析する必要が無い。以下の「（２）オーディオＴＳパケット生成処理」および「（３）ＴＳパケット多重化」の処理は第１の実施形態での処理と同様であるため、その説明を省略する。
【０２１７】
＜ＰＳ変換時の処理＞
ＰＳ変換時の処理は第１の実施形態の処理とほぼ同様であるため、主に異なる点について説明する。
【０２１８】
（１）ビデオパック生成
ビデオＴＳパケット生成と同様、Track fragment atom中の情報を用いることで、本処理に必要な各フレームのデータ量、ピクチャタイプおよびVBV delayの値を取得可能である。
【０２１９】
（２）オーディオパック生成
第１の実施形態と同様であるため省略する。
【０２２０】
（３）パック多重化
第１の実施形態と同様であるため省略する。
【０２２１】
＜バリエーション＞
本実施形態では、vbv＿delayに相当する値をVBV delay atomとして管理情報に記録しているが、この記録は必須ではない。なぜなら、各ビデオフレームのピクチャタイプおよびデータ量を元に、ＶＢＶバッファの占有量をシミュレートすることで、ＭＰＥＧ規格に準拠したＴＳ／ＰＳを生成できるからである。ただし、その場合、シミュレーションに伴う処理の複雑化が生じる。
【０２２２】
なお、以上に述べた各実施形態では、光ディスク１０６にＡＶストリームを記録することについて説明してきたが、ＡＶストリームを記録する記録媒体としては、光ディスクに限らず、ランダムアクセス可能な記録媒体であれば、例えばハードディスクや半導体メモリであってもよい。
【０２２３】
〔他の実施形態〕
本発明の実施形態の記録方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含むＡＶストリームと、ＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報（Movie atom 等）を記録媒体に記録する記録方法であって、ＡＶストリーム中に、個々の前記第１のユニットに関する第２の管理情報を記録し、第２の管理情報（Video Frame Information）は、対応する第１のユニットを構成するＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２２４】
また、前記記録方法では、第２の管理情報のデータフォーマットにISO base media file formatにおけるMovie Fragment（Movie Fragment atom）を用いることが好ましい。
【０２２５】
また、他の記録方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含むＡＶストリームと、ＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録する記録方法であって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記記録媒体に記録する。
【０２２６】
また、前記遅延時間はＡＶストリーム中に記録されることが好ましい。
【０２２７】
また、さらに他の記録方法は、ＡＶストリーム中に、個々の第１のユニットに関して第２の管理情報を記録し、第２の管理情報は、対応する第１のユニットを構成するＧＯＰを構成するビデオフレームデータ毎のデータ量および前記遅延時間を持つ。
【０２２８】
前記第２の管理情報は、対応する前記第１のユニットの物理的な近傍に配置されることが好ましい。
【０２２９】
前記各記録方法では、第２の管理情報と前記第１のＡＶストリームとを同一ファイルで管理し、前記第２の管理情報を対応するＧＯＰよりも低いアドレスに置くことが好ましい。
【０２３０】
前記記録方法では、前記遅延時間は少なくとも前記ＧＯＰ外に記録し、第１の管理情報は、ＧＯＰを構成するビデオフレームデータ毎のデータ量および遅延時間情報を持つことが好ましい。
【０２３１】
前記第１の管理情報は、ビデオフレーム間のピクチャタイプに関する情報を持つことが好ましい。前記第１の管理情報は、ＧＯＰを構成するビデオフレームデータ毎のデータ量および前記ビデオフレーム間のピクチャタイプに関する情報および前記遅延時間を持つことが好ましい。前記第２の管理情報は、ビデオフレーム間のピクチャタイプに関する情報を持つことが好ましい。
【０２３２】
本発明の実施形態のＡＶストリーム変換方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持記録媒体に関して、前記第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換方法であって、変換の際に、前記データ量に関する情報を用いる。
【０２３３】
また、他のＡＶストリーム変換方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、前記第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換方法であって、変換の際に、前記遅延時間を用いる。
【０２３４】
また、さらに他のＡＶストリーム変換方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とデータ量が記録されている記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換方法であって、変換の際に、前記遅延時間および前記データ量を用いる。
【０２３５】
また、さらに他のＡＶストリーム変換方法は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とデータ量とピクチャタイプに関する情報が記録されている記録媒体に関して、前記第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換方法であって、変換の際に、遅延時間および前記データ量およびピクチャタイプに関する情報を用いる。
【０２３６】
本願の実施形態の記録装置は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に前記第１のユニットに関する第１の管理情報を記録媒体に記録する記録装置であって、ＡＶストリーム中に、個々の前記第１のユニットに関する第２の管理情報を記録する手段を備え、第２の管理情報は、対応する第１のユニットを構成する前記ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２３７】
また、他の記録装置は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録する記録装置であって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記記録媒体に記録する手段を備える。
【０２３８】
本発明の実施形態のＡＶストリーム変換装置は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換装置であって、前記データ量に関する情報を用いる変換手段を備える。
【０２３９】
他のＡＶストリーム変換装置は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するＡＶストリーム変換装置であって、遅延時間を用いて変換する。
【０２４０】
本発明の実施形態の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録した記録媒体であって、ＡＶストリーム中に、個々の前記第１のユニットに関する第２の管理情報を記録し、第２の管理情報は、対応する第１のユニットを構成する前記ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２４１】
他の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報した記録媒体であって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を記録してある。
【０２４２】
本発明の実施形態のコンピュータプログラムは、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に前記第１のユニットに関する第１の管理情報を記録媒体に記録するステップを有するコンピュータプログラムであって、ＡＶストリーム中に、個々の第１のユニットに関する第２の管理情報を記録するステップを有し、第２の管理情報は、対応する第１のユニットを構成するＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２４３】
また、他のコンピュータプログラムは、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録するステップを有するコンピュータプログラムであって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記記録媒体に記録するステップを有する。
【０２４４】
また、さらに他のコンピュータプログラムは、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するステップを有するコンピュータプログラムであって、変換ステップが、前記データ量に関する情報を用いる。
【０２４５】
また、さらに他のコンピュータプログラムは、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するステップを有するコンピュータプログラムであって、変換ステップが遅延時間を用いる。
【０２４６】
本発明の実施形態の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、ＡＶストリーム中に、個々の第１のユニットに関する第２の管理情報を記録するステップを有し、第２の管理情報は、対応する第１のユニットを構成する前記ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【０２４７】
また、他の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、第１のＡＶストリームとは別の場所に第１のユニットに関する第１の管理情報を記録媒体に記録するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を記録媒体に記録するステップを有する。
【０２４８】
また、さらに他の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームデータ毎のデータ量に関する情報を持記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、変換ステップがデータ量に関する情報を用いる。
【０２４９】
また、さらに他の記録媒体は、１個以上のＧＯＰで構成される１個以上の第１のユニットを含む第１のＡＶストリームと、ＧＯＰを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、第１のＡＶストリームを第２のＡＶストリームに変換するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、変換ステップが遅延時間を用いる。
【０２５０】
また、データ変換装置およびデータ変換方法は、ビデオエレメンタリストリームにおけるデータ管理の最小単位である第１ビデオデータ単位の複数からなる第２ビデオデータ単位をビデオフレームデータに分割し、該ビデオフレームデータをパケット化して第１パケットを生成する第１パケット生成手段（処理）と、前記第１パケットを所定の大きさに分割して第１分割パケットを生成する第１分割パケット生成手段（処理）と、オーディオエレメンタリストリームにおけるデータ管理の最小単位である第１オーディオデータ単位の複数からなる第２オーディオデータ単位をオーディオフレームデータに分割し、該オーディオフレームデータをパケット化して第２パケットを生成する第２パケット生成手段（処理）と、前記第２パケットを所定の大きさに分割して第２分割パケットを生成する第２分割パケット生成手段（処理）と、前記第１および第２分割パケットを多重化して多重化ストリームを生成する多重化手段（処理）とを備えている。
【０２５１】
上記の構成では、第１パケット生成手段（処理）によって、QuickTime ファイルフォーマットのビデオエレメンタリストリームが第２ビデオデータ単位のビデオフレームデータに分割され、このビデオフレームデータを基に第１パケットが生成される。例えば、データ管理の最小単位である第１ビデオデータ単位はサンプルであり、第２ビデオデータ単位はチャンクである。そして、第１分割パケット生成手段（処理）によって、上記の第１パケットがさらに分割されて第１分割パケットが生成される。
【０２５２】
また、第２パケット生成手段（処理）によって、QuickTime ファイルフォーマットのオーディオエレメンタリストリームが第２オーディオデータ単位のオーディオフレームデータに分割され、このオーディオフレームデータを基に第２パケットが生成される。例えば、データ管理の最小単位である第１オーディオデータ単位はサンプルであり、第２オーディオデータ単位はチャンクである。そして、第２分割パケット生成手段（処理）によって、上記の第２パケットがさらに分割されて第２分割パケットが生成される。
【０２５３】
上記のようにして生成された第１および第２分割パケットは、多重化手段によって多重化され、その結果、ＭＰＥＧ２−ＴＳストリームとしての多重化ストリームが生成される。
【０２５４】
このように、QuickTime ファイルフォーマットのビデオエレメンタリストリームおよびオーディオエレメンタリストリームからＭＰＥＧ２−ＴＳストリームが得られる。それゆえ、QuickTime ファイルフォーマットのＡＶ(Audio and Visual)ストリームをＭＰＥＧ２−ＴＳのファイルフォーマットを採用する機器（IEEE-1394等）に転送することができる。
【０２５５】
他のデータ変換装置およびデータ変換方法は、ビデオエレメンタリストリームにおけるデータ管理の最小単位である第１ビデオデータ単位の複数からなる第２ビデオデータ単位をビデオフレームデータに分割し、該ビデオフレームデータをパケット化して第１パケットを生成する第１パケット生成手段（処理）と、複数の前記第１パケットをグループ化して第１パケット群を生成する第１パケット群生成手段（処理）と、オーディオエレメンタリストリームにおけるデータ管理の最小単位である第１オーディオデータ単位の複数からなる第２オーディオデータ単位をオーディオフレームデータに分割し、該オーディオフレームデータをパケット化して第２パケットを生成する第２パケット生成手段（処理）と、複数の前記第２パケットをグループ化して第２パケット群を生成する第２分割パケット群生成手段（処理）と、前記第１および第２パケット群を多重化して多重化ストリームを生成する多重化手段（処理）とを備えている。
【０２５６】
上記の構成では、第１パケット生成手段（処理）によって、前述のように、第１パケットが生成される。そして、第１パケット群生成手段（処理）によって、複数の第１パケットがグループ化されて第１パケット群が生成される。
【０２５７】
また、第２パケット生成手段（処理）によって、前述のように、第２パケットが生成される。そして、第２パケット群生成手段（処理）によって、複数の第２パケットがグループ化されて第２パケット群が生成される。
【０２５８】
上記のようにして生成された第１および第２パケット群は、多重化手段によって多重化され、その結果、ＭＰＥＧ２−ＰＳストリームとしての多重化ストリームが生成される。
【０２５９】
このように、QuickTime ファイルフォーマットのビデオエレメンタリストリームおよびオーディオエレメンタリストリームからＭＰＥＧ２−ＰＳストリームが得られる。それゆえ、QuickTime ファイルフォーマットのＡＶ(Audio and Visual)ストリームをＭＰＥＧ２−ＰＳのファイルフォーマットを採用する機器（ＤＶＤプレーヤ等）に転送することができる。
【０２６０】
前記の発明は、前記ビデオエレメンタリストリームと前記オーディオエレメンタリストリームとが多重化されてなるエレメンタリストリームを前記ビデオエレメンタリストリームと前記オーディオエレメンタリストリームとに分離してそれぞれを前記第１パケット生成手段（処理）と前記第２パケット生成手段（処理）とに与える分離手段（処理）を備え、前記エレメンタリストリームが、該エレメンタリストリームの格納されるファイルとは別のファイルに格納され、前記エレメンタリストリームの前記ビデオフレームデータに関する管理情報が付加され、前記第１パケット生成手段（処理）が、前記ビデオエレメンタリストリームに付随して分離された前記管理情報に基づいて第２ビデオデータ単位をビデオフレームデータに分割することが好ましい。
【０２６１】
上記の構成では、第１および第２パケット生成手段（処理）にそれぞれ与えられるビデオエレメンタリストリームおよびオーディオエレメンタリストリームは、分離手段（処理）によって、エレメンタリストリームから分離される。このエレメンタリストリームは、それが格納されるファイルとは別のファイルに格納され、エレメンタリストリームのビデオフレームデータに関する管理情報が付加されている。この管理情報としては、ビデオフレームデータ毎のデータ量、ビデオフレームデータのデコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間、ビデオフレームのピクチャタイプ等に関する情報が含まれる。
【０２６２】
これにより、第１パケット生成手段（処理）は、その管理情報に基づいて、ビデオエレメンタリストリームをビデオフレームデータに分割する。それゆえ、ビデオフレームデータの分割のためにエレメンタリストリームを解析してビデオフレームデータの分割位置を検出するための手段や処理が必要ない。
【０２６３】
あるいは、前記の発明は、前記分離手段（処理）を備え、前記エレメンタリストリームに、所定の間隔毎に前記ビデオフレームデータに関する管理情報が付加され、前記第１パケット生成手段が、前記ビデオエレメンタリストリームに付随して分離された前記管理情報に基づいて第２ビデオデータ単位をビデオフレームデータに分割することが好ましい。
【０２６４】
この構成では、エレメンタリストリームに、前述の管理情報が付加されているので、ビデオフレームデータの分割のためにエレメンタリストリームを解析してビデオフレームデータの分割位置を検出するための手段や処理が必要ない。
【０２６５】
また、前記の従来技術においては、管理情報量を減らすために、ＧＯＰを１サンプルとして管理している。しかしながら、QuickTime ファイルフォーマットでは、本来１ビデオフレームを１サンプルとして管理するのが原則であり、QuickTime ファイルフォーマットを扱うプレーヤや編集ソフトにおいて互換性に支障が生じる虞がある。なお、この原則は、QuickTime ファイルフォーマットをベースにしてISO/IEC 15444-3/FPDAmd 1として規格化されたISO base media file formatにも踏襲されている。
【０２６６】
そこで、上記の構成において、前記エレメンタリストリームは、大きさの異なる前記第１ビデオデータ単位で前記ビデオフレームデータを管理するための複数種の前記管理情報が付加されていることが好ましい。これにより、例えば、第１ビデオデータ単位をサンプルとした場合、ＧＯＰをサンプルとするようなメモリ（バッファ）容量の小さい専用プレーヤでビデオデータを再生する一方、ビデオフレームデータをサンプルとするようなQuickTime 対応プレーヤでビデオデータを再生することができる。
【０２６７】
また、上記の構成において、前記管理情報は、前記第２ビデオデータ単位のビデオフレームデータよりも先に読み出されるように設けられていることが好ましい。これにより、管理情報がエレメンタリストリームと同一のファイルに格納されているか否かに関わらず、管理情報がビデオフレームデータよりも先に読み出されるので、管理情報が読み出されてから、ビデオエレメンタリストリームにおいて分割されるべきビデオフレームデータが読み出される。それゆえ、第１パケット生成手段（処理）が、読み出された管理情報に基づいて、ビデオエレメンタリストリームのビデオフレームデータへの分割処理を速やかに行なうことができる。
【０２６８】
前記の発明は、前記分離手段（処理）を備え、前記エレメンタリストリームが、同一ファイルにおいて該エレメンタリストリームの設けられる領域と別の領域に設けられ、前記エレメンタリストリームの前記ビデオフレームデータに関する管理情報が１個の前記エレメンタリストリームと対をなすように付加され、前記第１パケット生成手段が、前記ビデオエレメンタリストリームに付随して分離された前記管理情報に基づいて第２ビデオデータ単位をビデオフレームデータに分割することが好ましい。
【０２６９】
この構成では、前記管理情報が、同一ファイルにおいてエレメンタリストリームの設けられる領域と別の領域に設けられ、１個のエレメンタリストリームと対をなすように付加されるので、前述の分離手段（処理）を備えた構成と同様に、エレメンタリストリームに、ビデオフレームデータの分割のためにエレメンタリストリームを解析してビデオフレームデータの分割位置を検出するための手段や処理が必要ない。
【０２７０】
データ変換プログラムは、前記のデータ変換方法における各処理をコンピュータに実行させ、また、このデータ変換プログラムは、コンピュータ読み取り可能な記録媒体に記録して提供可能である。
【０２７１】
【発明の効果】
以上のように、本発明によれば、ビデオデータ中のvbv＿delayに常に値をセットするようにしたことで、ＥＳをインターリーブしたＡＶストリーム構成においてＴＳ／ＰＳへの変換を容易にしかも確実にすることが可能である。
【０２７２】
また、通常の管理情報とは別に、ビデオデータの各ビデオフレームのデータ量、ピクチャタイプ、vbv＿delay値を、ビデオデータとは別の位置に記録することで、ＴＳ／ＰＳ変換時にビデオデータを解析する必要がなくなる。また、これらの情報をＡＶストリーム中に記録し、通常再生に用いる管理情報とは別にすることで、通常再生時の管理情報を記憶するためのメモリを増加させることはない。
【０２７３】
さらに、通常再生に用いる管理情報とは別に、ビデオデータの各ビデオフレームのデータ量、ピクチャタイプ、vbv＿delayを求めることが可能な情報を、ISO base media file formatで規定されているMovie fragmentの形式で格納することによって、専用プレーヤだけでなく、ISO base media file formatあるいはQuickTimeファイルフォーマットに対応したプレーヤで再生可能になる。
【図面の簡単な説明】
【図１】本発明の実施形態に係るビデオディスクレコーダの概略構成を示すブロック図である。
【図２】 (ａ)ないし(ｃ)はQuickTime ファイルフォーマットにおける管理情報とＡＶストリームとの関係を示す図である。
【図３】 QuickTime ファイルフォーマットにおけるMovie atomの概要を示す図である。
【図４】 QuickTime ファイルフォーマットにおけるTrack atomの概要を示す図である。
【図５】 QuickTime ファイルフォーマットにおけるTrack header atom の構成を示す図である。
【図６】 QuickTime ファイルフォーマットにおけるMedia atomの構成を示す図である。
【図７】 QuickTime ファイルフォーマットにおけるMedia information atomの構成を示す図である。
【図８】 Sample table atomによるデータ管理の例を示す図である。
【図９】 QuickTime ファイルフォーマットにおけるSample table atom の構成を示す図である。
【図１０】 QuickTime ファイルフォーマットにおけるEdit atom の構成を示す図である。
【図１１】 Edit atomによる再生範囲指定の例を示す説明図である。
【図１２】 QuickTime ファイルフォーマットにおけるUser data atomの構成を示す図である。
【図１３】 QuickTime ファイルフォーマットにおけるFragmented movieの全体構成を示す図である。
【図１４】 QuickTime ファイルフォーマットにおけるMovie extends atomの構成を示す図である。
【図１５】 QuickTime ファイルフォーマットにおけるTrack extends atomの構成を示す図である。
【図１６】 QuickTime ファイルフォーマットにおけるMovie fragment atom の構成を示す図である。
【図１７】 QuickTime ファイルフォーマットにおけるMovie fragment header atomの構成を示す図である。
【図１８】 QuickTime ファイルフォーマットにおけるTrack fragment atom の構成を示す図である。
【図１９】 QuickTime ファイルフォーマットにおけるTrack fragment header atomの構成を示す図である。
【図２０】 QuickTime ファイルフォーマットにおけるTrack fragment run atom の構成を示す図である。
【図２１】（ａ）はディレクトリ／ファイル構成を示す図であり、（ｂ）はそのディレクトリ／ファイル構成のＵＤＦにおける管理を示す図である。
【図２２】本発明の第１の実施形態に係るビデオディスクレコーダにおけるＴＳ／ＰＳ変換部の概略構成を示すブロック図である。
【図２３】上記第１の実施形態におけるＡＶストリームの構成を示す図である。
【図２４】上記第１の実施形態におけるＶＵの構造を示す図である。
【図２５】上記第１の実施形態におけるQuickTime によるＡＶストリーム管理形態を示す図である。
【図２６】上記第１の実施形態におけるリファレンスデバイスモデルを示す説明図である。
【図２７】上記第１の実施形態における記録処理の手順を示すフローチャートである。
【図２８】上記第１の実施形態におけるビデオＴＳパケット生成処理の概念を示す図である。
【図２９】上記第１の実施形態におけるオーディオＴＳパケット生成処理の概念を示す図である。
【図３０】上記第１の実施形態におけるＴＳパケット多重化処理の手順を示すフローチャートである。
【図３１】上記第１の実施形態におけるビデオＰＳパック生成処理の概念を示す図である。
【図３２】上記第１の実施形態におけるオーディオＰＳパック生成処理の概念を示す図である。
【図３３】上記第１の実施形態におけるＰＳパック多重化処理の手順を示すフローチャートである。
【図３４】本発明の第２の実施形態に係るビデオディスクレコーダにおけるＴＳ／ＰＳ変換部の概略構成を示すブロック図である。
【図３５】上記第２の実施形態におけるＶＵの構造を示す図である。
【図３６】上記第２の実施形態におけるQuickTime によるＡＶストリーム管理形態を示す図である。
【図３７】本発明の第３の実施形態に係るビデオディスクレコーダにおけるＡＶストリームの構成を示す図である。
【図３８】上記第３の実施形態におけるVBV delay atomの構成を示す図である。
【図３９】従来技術におけるQuickTime ファイルフォーマットを用いたＡＶファイルの構成を示す図である。
【符号の説明】
１００ バス
１０１ ホストＣＰＵ
１０２ ＲＡＭ
１０３ ＲＯＭ
１０４ ユーザインタフェース
１０７ 光ピックアップ（記録手段）
１０９ ＥＣＣエンコーダ（記録手段）
１１０ オーディオ再生用バッファ
１１１ ビデオ再生用バッファ
１１２ デマルチプレクサ
１１３ マルチプレクサ
１１５ オーディオデコーダ
１１６ ビデオデコーダ
１１７ オーディオエンコーダ
１１８ ビデオエンコーダ
１２１ ＴＳ／ＰＳ変換部（変換手段）
１２３ 記録媒体
２０１ Movie atom（第１の管理情報）
４０４ Movie fragment atom（第２の管理情報）
７０１ ＡＶストリーム
７０３ ＶＵ（ユニット）
７０４ ＧＯＰ（画像データ群）
７０５ ＡＡＵ
７０７ ＶＣ
７０８ ＡＣ
７０９ ＶＦＩ（第２の管理情報）
７１０ Movie fragment atom（第２の管理情報）
１１０１ ビデオＰＥＳパケット生成部
１１１１ オーディオＰＥＳパケット生成部
１１０２ ビデオＴＳパケット生成部
１１１２ オーディオＴＳパケット生成部
１１２１ ＴＳマルチプレクサ
１１２２ ＰＳマルチプレクサ
Claims (23)
- １個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームを記録する領域とは別の領域に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録方法であって、
前記ＡＶストリーム中に前記ユニットの個々に関する第２の管理情報を含んだ状態で前記ＡＶストリームを記録し、
前記第２の管理情報は、対応する前記ユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴とするデータ記録方法。 - 第２の管理情報のデータフォーマットにISO base media file formatにおけるMovie Fragmentを用いることを特徴とする請求項１に記載のデータ記録方法。
- １個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームを記録する領域とは別の領域に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録方法であって、
前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記データ記録媒体に記録することを特徴とするデータ記録方法。 - 前記遅延時間を含んだ前記ＡＶストリームを記録することを特徴とする請求項３に記載のデータ記録方法。
- 前記ＡＶストリーム中に前記ユニットの個々に関する第２の管理情報を含んだ状態で前記ＡＶストリームを記録し、
前記第２の管理情報は、対応するユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間を持つことを特徴とする請求項４に記載のデータ記録方法。 - 前記第２の管理情報を、対応する前記ユニットの物理的な近傍に配置することを特徴とする請求項５に記載のデータ記録方法。
- 前記第２の管理情報と前記ＡＶストリームとを同一ファイルで管理し、前記第２の管理情報を対応する前記画像データ群よりも低い前記ファイルの先頭からの相対アドレスに置くことを特徴とする請求項５に記載のデータ記録方法。
- 前記遅延時間を少なくとも前記画像データ群外に記録し、
前記第１の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間情報を持つことを特徴とする請求項４に記載のデータ記録方法。 - 前記第１の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことを特徴とする請求項５に記載のデータ記録方法。
- 前記第１の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記ビデオフレームのピクチャタイプに関する情報および前記遅延時間を持つことを特徴とする請求項３に記載のデータ記録方法。
- 前記第２の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことを特徴とする請求項３または６記載のデータ記録方法。
- １個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報とが記録されているデータ記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、
前記データ量を用いて前記画像データ群をビデオフレームに分割して前記第１のＡＶストリームを前記第２のＡＶストリームに変換することを特徴とするデータ変換方法。 - １個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、
前記遅延時間を用いて前記画像データ群をビデオフレームに分割して前記第１のＡＶストリームを前記第２のＡＶストリームに変換することを特徴とするデータ変換方法。 - １個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間およびデータ量とが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、
前記遅延時間および前記データ量を用いて前記画像データ群をビデオフレームに分割して前記第１のＡＶストリームを前記第２のＡＶストリームに変換することを特徴とするデータ変換方法。 - １個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間、データ量およびピクチャタイプとが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換方法であって、
前記遅延時間、前記データ量および前記ピクチャタイプを用いて前記画像データ群をビデオフレームに分割して前記第１のＡＶストリームを前記第２のＡＶストリームに変換することを特徴とするデータ変換方法。 - １個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームとは別の領域に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録装置であって、
前記ＡＶストリーム中に前記ユニットの個々に関する第２の管理情報を含んだ状態で記録する記録手段を備え、
前記第２の管理情報は、対応する前記ユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴とするデータ記録装置。 - １個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームとは別の場所に前記ユニットに関する第１の管理情報とをデータ記録媒体に記録するデータ記録装置であって、
前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記データ記録媒体に記録する記録手段を備えることを特徴とするデータ記録装置。 - １個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を記録されているデータ記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換装置であって、
前記データ量に関する情報を用いて前記画像データ群をビデオフレームに分割して前記第１のＡＶストリームを第２のＡＶストリームに変換する変換手段を備えることを特徴とするデータ変換装置。 - １個以上の画像データ群を含む１個以上のユニットを含む第１のＡＶストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とが記録されている記録媒体から読み出された前記第１のＡＶストリームを第２のＡＶストリームに変換するデータ変換装置であって、
前記遅延時間を用いて前記画像データ群をビデオフレームに分割して前記第１のＡＶストリームを第２のＡＶストリームに変換する変換手段を備えることを特徴とするデータ変換装置。 - １個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームが記録された領域とは別の領域に前記ユニットに関する第１の管理情報が記録されているデータ記録媒体であって、
前記ＡＶストリームは、前記ユニットの個々に関する第２の管理情報を含み、前記第２の管理情報は、対応する前記ユニットにおける前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴とするデータ記録媒体。 - １個以上の画像データ群を含む１個以上のユニットを含むＡＶストリームと、前記ＡＶストリームが記録されている領域とは別の領域に前記ユニットに関する第１の管理情報が記録されているデータ記録媒体であって、
前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されていることを特徴とするデータ記録媒体。 - 請求項１ないし１１のいずれか１項に記載のデータ記録方法をコンピュータに実行させるデータ記録プログラム。
- 請求項２２のデータ記録プログラムを記録したコンピュータ読み取り可能な 記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002244304A JP3889338B2 (ja) | 2002-08-23 | 2002-08-23 | データ記録方法、データ記録装置、データ変換方法、データ変換装置、データ記録媒体、データ記録のためのプログラムおよびそのプログラムを記録した記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002244304A JP3889338B2 (ja) | 2002-08-23 | 2002-08-23 | データ記録方法、データ記録装置、データ変換方法、データ変換装置、データ記録媒体、データ記録のためのプログラムおよびそのプログラムを記録した記録媒体 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004088267A JP2004088267A (ja) | 2004-03-18 |
| JP2004088267A5 JP2004088267A5 (ja) | 2005-10-27 |
| JP3889338B2 true JP3889338B2 (ja) | 2007-03-07 |
Family
ID=32052822
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002244304A Expired - Fee Related JP3889338B2 (ja) | 2002-08-23 | 2002-08-23 | データ記録方法、データ記録装置、データ変換方法、データ変換装置、データ記録媒体、データ記録のためのプログラムおよびそのプログラムを記録した記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3889338B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2145471A4 (en) * | 2007-04-04 | 2011-03-30 | Korea Electronics Telecomm | STORAGE / RELEASE METHOD AND APPARATUS FOR MPEG-2 TRANSPORT STREAM BASED ON ISO MULTIMEDIA FILE FORMAT |
-
2002
- 2002-08-23 JP JP2002244304A patent/JP3889338B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004088267A (ja) | 2004-03-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0926903B1 (en) | Optical disc and computer-readable storage medium, and recording method and apparatus therefor | |
| JP4951087B2 (ja) | 情報記録媒体、データ再生装置及び記録方法 | |
| JP4481991B2 (ja) | 情報記録媒体、データ分別装置、データ再生装置及び記録方法 | |
| JP2008178112A (ja) | Ａｖデータ記録再生装置及び方法、当該ａｖデータ記録再生装置又は方法で記録されたディスク | |
| WO2006054590A1 (ja) | データ処理装置 | |
| WO2001010119A1 (fr) | Procede de determination de position d'acces sur un support d'enregistrement et procede de gestion du support d'enregistrement | |
| US20100142554A1 (en) | Multiplexer and multiplexing method, program, and recording medium | |
| CN111276170B (zh) | 解码系统以及解码方法 | |
| US7835615B2 (en) | Data processing apparatus | |
| CN106463149B (zh) | 记录介质、再现方法以及再现装置 | |
| KR100537393B1 (ko) | 기록 방법, 기록 매체 및 기록 장치 | |
| JP3889338B2 (ja) | データ記録方法、データ記録装置、データ変換方法、データ変換装置、データ記録媒体、データ記録のためのプログラムおよびそのプログラムを記録した記録媒体 | |
| JP3986973B2 (ja) | Ａｖデータ記録方法、ａｖデータ記録装置、データ記録媒体、及びプログラム | |
| JP4616144B2 (ja) | データ処理装置 | |
| KR20080089129A (ko) | 기록 방법 | |
| JP4312783B2 (ja) | Ａｖデータ再生方法、ａｖデータ再生装置、プログラム、並びに記録媒体 | |
| JP2003052017A (ja) | Ａｖデータ記録装置及び方法、当該ａｖデータ記録装置又は方法で記録されたディスク、並びに当該ディスクを再生するａｖデータ再生装置及び方法又はａｖデータ記録再生装置及び方法 | |
| JP2019067481A (ja) | 記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050719 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050719 |
|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20050719 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060911 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060919 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061027 |
|
| 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: 20061128 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061129 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091208 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101208 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101208 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111208 Year of fee payment: 5 |
|
| LAPS | Cancellation because of no payment of annual fees |