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
【発明の属する技術分野】
本発明は、ハードディスク、光ディスク、半導体メモリ等のランダムアクセス可能な記録媒体に対して、映像データおよび音声データを記録するデータ記録方法、データ記録装置、データ変換方法、データ変換装置、データ記録媒体、データ記録媒体、データ記録のためのプログラム、およびそのプログラムが記録された記録媒体に関するものである。
【0002】
【従来の技術】
ディスクメディアを用いたビデオのディジタル記録再生装置(以下、ビデオディスクレコーダと呼ぶ)が普及しつつある。その記録フォーマットには、PC(パーソナルコンピュータ)との親和性を高めるため、PCで広く使われている、QuickTime(商標)ファイルフォーマットを用いることがよく行われる。
【0003】
QuickTime ファイルフォーマットを用いたビデオデータの管理については、特開2001−176195号公報に開示されている。以下、図39を用いてその概要を説明する。
【0004】
ビデオデータは、ムービーファイル5001に格納されている。ムービーファイル5001は、実際のビデオデータおよびオーディオデータを格納するMovie data atom と、ビデオデータおよびオーディオデータを管理するためのMovie atomとで構成される。
【0005】
Movie data atom 中では、入力されたオーディオとビデオとのES(Elementary Stream)が所定の時間(1秒程度)に対応するアクセスユニット(MPEG2ビデオであればGOP(Group of Pictures) 、MPEG2オーディオであればオーディオフレームとしてのAAU(Audio Access Unit) )毎に区切り、これらを交互に配置する。それぞれの区切られた単位は、QuickTime におけるチャンクとして扱われる。また、各オーディオフレームおよびGOPは、QuickTime におけるサンプルとして扱われる。各サンプルのデータ量および再生時間、ならびにムービーファイル5001中での各チャンクの相対アドレスは、Movie atomに格納し、再生の際は、Movie atomを参照することで、ある時間に対応するビデオデータおよびオーディオデータの記録位置を特定することが可能となる。
【0006】
【発明が解決しようとする課題】
しかしながら、一般に広く用いられているのは、上記のストリーム構成と異なる構成を持ったISO/IEC 13818-1 に定義されるTransport Stream(以下MPEG 2-TS )や、Program Stream(以下MPEG 2-PS )である。例えば、DVD-Video ではMPEG2−PSが採用されており、ディジタル放送やIEEE-1394による機器間のデータ転送形式ではMPEG2−TSが採用されている。したがって、上記のストリーム構成で記録したデータをIEEE-1394による伝送形式で別の機器に転送したり、DVDプレーヤで再生できるようにするためには、上記のストリーム構成のデータをMPEG2−PSやMPEG2−TSへ変換する必要がある。ところが、前記の従来技術においては、そのための方法が開示されていない。
【0007】
本発明は、上記課題を鑑みてなされたものであり、Elementary Stream 同士を多重化したストリーム構成を持ち、そのストリームを、複数のフレームを1単位として管理する場合において、MPEG2−TS/PSのファイルフォーマットのストリームに容易に変換可能な形態でデータを記録媒体に記録するデータ記録方法等を提供することを目的とする。
【0008】
【課題を解決するための手段】
本発明のデータ記録方法および装置は、1個以上の画像データ群を含む1個以上のユニットを含むAVストリームと、前記AVストリームを記録する領域とは別の領域に前記ユニットに関する第1の管理情報とをデータ記録媒体に記録するデータ記録方法および装置であって、前記AVストリーム中に前記ユニットの個々に関する第2の管理情報を含んだ状態で前記AVストリームを記録し、前記第2の管理情報が、対応する前記ユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴としている。
【0009】
この方法・装置では、QuickTime ファイルフォーマットでデータ記録媒体に記録されているAVストリームをMPEG2−TS/PSストリームに変換する際に、AVストリーム中の第2管理情報を用いることによって、画像データ群を解析することなく、通常の記録・再生に必要な管理情報を増やさずに、ストリーム変換することができる。それゆえ、QuickTime ファイルフォーマットのAV(Audio and Visual)ストリームをMPEG2−TSのファイルフォーマットを採用する機器(IEEE-1394やDVDプレーヤ等)に容易に転送することができる。
【0010】
上記のデータ記録方法においては、第2の管理情報のデータフォーマットにISO base media file formatにおけるMovie Fragmentを用いることが好ましい。これにより、通常の記録・再生に必要な管理情報を増やさないだけでなく、再生互換性を高めることができる。
【0011】
本発明の他のデータ記録方法および装置は、1個以上の画像データ群を含む1個以上のユニットを含むAVストリームと、前記AVストリームを記録する領域とは別の領域に前記ユニットに関する第1の管理情報とをデータ記録媒体に記録するデータ記録方法および装置であって、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記データ記録媒体に記録することを特徴としている。
【0012】
この方法および装置では、上記の遅延時間をデータ記録媒体に記録するので、このデータ記録媒体から読み出された、QuickTime ファイルフォーマットでデータ記録媒体に記録されているAVストリームをMPEG2−TS/PSストリームに変換する際に、遅延時間を用いることによって、確実にストリーム変換することができる。
【0013】
このデータ記録方法において、前記遅延時間を含んだ前記AVストリームを記録することが好ましい。これにより、通常の記録・再生に必要な管理情報を増加させることがない。
【0014】
しかも、前記AVストリーム中に前記ユニットの個々に関して第2の管理情報を含んだ状態で前記AVストリームを記録し、前記第2の管理情報、例えば後述するVideo Frame Informationが、対応するユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間を持つことにより、画像データ群を解析する必要がない。
【0015】
また、前記第2の管理情報を、対応する前記ユニットの物理的な近傍に配置することにより、AVストリームのデコードの前に必要なバッファメモリの容量を少なくすることができる。あるいは、前記第2の管理情報と前記AVストリームとを同一ファイルで管理し、前記第2の管理情報を対応する前記画像データ群よりも低い前記ファイルの先頭からの相対アドレスアドレスに置くことによっても、バッファメモリの容量が少なくすることができる。
【0016】
前述のように、遅延時間をAVストリーム中に記録した場合、前記遅延時間を少なくとも前記画像データ群外に記録し、前記第1の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間情報を持つことが好ましい。これにより、画像データ群を解析する必要がなくなる。
【0017】
前記第1の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことが好ましい。これにより、Bピクチャにも対応することができる。
【0018】
前記第1の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記ビデオフレームのピクチャタイプに関する情報および前記遅延時間を持つことが好ましい。これにより、画像データ群を解析する必要がない。
【0019】
前記第2の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことが好ましい。
【0020】
本発明のデータ記録プログラムは、前記のデータ記録方法をコンピュータに実行させる。また、このデータ記録プログラムは、コンピュータ読み取り可能な 記録媒体に記録される。
【0021】
本発明のデータ変換方法および装置は、1個以上の画像データ群を含む1個以上のユニットを含む第1のAVストリームと、前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報とが記録されているデータ記録媒体から読み出された前記第1のAVストリームを第2のAVストリームに変換するデータ変換方法であって、変換の際に、前記データ量に関する情報を用いることを特徴としている。この方法では、QuickTime ファイルフォーマットの第1のAVストリームをMPEG2−TS/PSの第2のストリームに変換する際に、第1のAVストリーム中の第2の管理情報を用いることによって、画像データ群を解析することなく、ストリーム変換することができる。それゆえ、QuickTime ファイルフォーマットのAV(Audio and Visual)ストリームをMPEG2−TSのファイルフォーマットを採用する機器(IEEE-1394やDVDプレーヤ等)に容易に転送することができる。
【0022】
本発明の他のデータ変換方法および装置は、1個以上の画像データ群を含む1個以上のユニットを含む第1のAVストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とが記録されている記録媒体から読み出された前記第1のAVストリームを第2のAVストリームに変換するデータ変換方法であって、前記遅延時間を用いて前記画像データ群を分割して前記第1のAVストリームを第2のAVストリームに変換することを特徴としている。
【0023】
この方法では、上記の遅延時間が記録されたデータ記録媒体から読み出された、QuickTime ファイルフォーマットのAVストリームをMPEG2−TS/PSストリームに変換する際に、遅延時間を用いることによって画像データ群(GOP)をビデオフレームに分割するので、確実にストリーム変換することができる。
【0024】
本発明の他のデータ変換方法は、1個以上の画像データ群を含む1個以上のユニットを含む第1のAVストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間およびデータ量とが記録されている記録媒体から読み出された前記第1のAVストリームを第2のAVストリームに変換するデータ変換方法であって、前記遅延時間および前記データ量を用いて前記画像データ群を分割して前記第1のAVストリームを第2のAVストリームに変換することにより、前述のデータ変換方法と同様、画像データ群を解析する必要がないだけでなく、遅延時間およびデータ量を用いることによって、確実にストリーム変換することができる。
【0025】
本発明のさらに他のデータ変換方法は、1個以上の画像データ群を含む1個以上のユニットを含む第1のAVストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間、データ量およびピクチャタイプに関する情報が記録されている記録媒体から読み出された前記第1のAVストリームを第2のAVストリームに変換するデータ変換方法であって、前記遅延時間、前記データ量および前記ピクチャタイプを用いて前記画像データ群を分割して前記第1のAVストリームを第2のAVストリームに変換することにより、前述のデータ変換方法と同様、画像データ群を解析する必要がないだけでなく、遅延時間およびデータ量を用いることによって、確実にストリーム変換することができ、さらにBピクチャにも対応することができる。
【0026】
本発明のデータ記録媒体は、1個以上の画像データ群を含む1個以上のユニットを含むAVストリームと、前記AVストリームが記録された領域とは別の領域に前記ユニットに関する第1の管理情報が記録されているデータ記録媒体であって、前記AVストリームは、前記ユニットの個々に関する第2の管理情報を含み、前記第2の管理情報は、対応する前記ユニットにおける前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴としている。
【0027】
このようなデータ記録媒体から読み出されたQuickTime ファイルフォーマットのAVストリームは、MPEG2−TS/PSの第2のストリームに変換する際に、AVストリーム中の第2の管理情報を用いることによって、画像データ群を解析することなく、ストリーム変換することができる。それゆえ、QuickTime ファイルフォーマットのAV(Audio and Visual)ストリームをMPEG2−TSのファイルフォーマットを採用する機器(IEEE-1394やDVDプレーヤ等)に容易に転送することができる。
【0028】
本発明の他のデータ記録媒体は、1個以上の画像データ群を含む1個以上のユニットを含むAVストリームと、前記AVストリームが記録されている領域とは別の領域に前記ユニットに関する第1の管理情報が記録されているデータ記録媒体であって、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されていることを特徴としている。
【0029】
上記の遅延時間が記録されたデータ記録媒体から読み出された、QuickTime ファイルフォーマットのAVストリームをMPEG2−TS/PSストリームに変換する際に、遅延時間を用いることによって、確実にストリーム変換することができる。
【0030】
【発明の実施の形態】
以下、本発明の実施形態について、図1ないし図38を参照しながら詳細に説明する。ここでの説明は、本発明において共通に用いる構成、個々の実施形態に固有の内容という順に行なうものとする。
【0031】
〔基本システム〕
図1は、後述する各実施形態において共通のビデオディスクレコーダの基本システム構成図である。以下に、この基本システムについて説明する。
【0032】
<システム構成>
このビデオディスクレコーダは、図1に示すように、バス100、ホストCPU101、RAM102、ROM103、ユーザインタフェース104、システムクロック発生器105、光ディスク106、ピックアップ107、ECC(Error Correcting Coding)デコーダ108、ECCエンコーダ109、オーディオ再生用バッファ110、ビデオ再生用バッファ111、デマルチプレクサ112、マルチプレクサ113、記録用バッファ114、オーディオデコーダ115、ビデオデコーダ116、オーディオエンコーダ117、ビデオエンコーダ118、オーディオ記録用バッファ119、ビデオ記録用バッファ120、TS/PS変換部121、外部ディジタル出力部122、および図示しないカメラ、マイク、スピーカ、ディスプレイ等で構成される。
【0033】
ホストCPU101は、デマルチプレクサ112、マルチプレクサ113、ピックアップ107、オーディオデコーダ115、ビデオデコーダ116、オーディオエンコーダ117、ビデオエンコーダ118、TS/PS変換部121等の制御をバス100を通じて行う。デマルチプレクサ112、マルチプレクサ113、ピックアップ107、オーディオデコーダ115、ビデオデコーダ116、オーディオエンコーダ117、ビデオエンコーダ118およびTS/PS変換部121は、ハードウエアで構成されていてもよいし、ソフトウエアで構成されていてもよ。
【0034】
RAM102は、ビデオディスクレコーダの動作を制御するためにホストCPU101に実行させる制御プログラム等のプログラムやプログラムの実行に必要なデータをロードしたり、プログラムの実行のための作業領域を提供している。また、RAM102は、再生時のTS/PS変換部121によるファイルフォーマットの変換時等にAVストリームの後述する管理情報を読み込む。
【0035】
ROM103は、上記のプログラムやデータを格納している。制御プログラムは、後述する記録時の処理を実現するためのデータ記録プログラムやTS/PS変換部121の変換処理を実現するための変換プログラムを含んでいる。このデータ記録プログラムや変換プログラムは、ROM103に限らず、記憶媒体123に記憶されていてもよい。記録媒体123は、コンピュータが読み取り可能である光ディスク、光磁気ディスク、磁気ディスク、磁気テープ、半導体メモリ等の媒体であって、ドライブ装置124によって駆動される。
【0036】
ユーザインタフェース104は、ユーザがディスプレイの画面上で本ビデオディスクレコーダの各種の操作をリモートコントローラを用いてできるように、操作案内等を画面に表示したりユーザによる操作入力を受け入れたりするためのソフトウエアである。
【0037】
システムクロック発生器105は、CPU101、RAM102、ROM103等に供給するためのシステムクロックを発生する回路である。
【0038】
再生時に、光ディスク106からピックアップ107を通じて読み出されたデータは、ECCデコーダ108によって誤り訂正され、デマルチプレクサ112に送られる。デマルチプレクサ112は、ホストCPU101からの指示に従い、ECCデコーダ108から読み出されたデータよりオーディオデータおよびビデオデータを抽出して、それぞれをオーディオ再生用バッファ110およびビデオ再生用バッファ111に振り分ける。オーディオデータおよびビデオデータは、それぞれオーディオ再生用バッファ110およびビデオ再生用バッファ111に一時的に格納される。オーディオデコーダ115およびビデオデコーダ116は、ホストCPU101からの指示に従って、それぞれオーディオ再生用バッファ110およびビデオ再生用バッファ111からデータを読み出しデコードを行う。
【0039】
一方、記録時には、オーディオデータおよびビデオデータがそれぞれオーディオエンコーダ117およびビデオエンコーダ118によって圧縮符号化される。圧縮符号化されたオーディオデータおよびビデオデータは、それぞれオーディオ記録用バッファ119およびビデオ記録用バッファ120に送られ、そこで一時的に格納される。マルチプレクサ113は、ホストCPU101からの指示に従って、オーディオ記録用バッファ119およびビデオ記録用バッファ120からデータを読み出し、これらをAV多重化して記録用バッファ114に送る。ECCエンコーダ109は、記録用バッファ114から読み出したAV多重化データに対し誤り訂正符号を付加し、ピックアップ107を通じて光ディスク106に記録する。
【0040】
また、TS/PS変換部121は、ホストCPU101からの指示に従って、オーディオ再生用バッファ110およびビデオ再生用バッファ111に蓄えられている後述のQuickTime ファイルフォーマットのES(Elementary Stream) を、MPEG2−TS(Transport Stream)およびMPEG2−PS(Program Stream)にファイルフォーマット変換する。このTS/PS変換部121は、ソフトウエアで構成される場合、データ変換プログラムであって、ROM103または記録媒体123に格納されている。変換の結果として生成されたMPEG2−TSおよびMPEG2−PSフォーマットのデータは、外部ディジタル出力部122を介して外部に出力されるか、あるいは記録用バッファ114およびECCエンコーダ109を介して光ピックアップ107により光ディスク106に記録される。
【0041】
ECCエンコーダ109によるオーディオデータの符号化方式にはISO/IEC 11172-3で規定されるMPEG1 Layer-IIを用いる。一方、ECCエンコーダ109によるビデオデータの符号化方式にはISO/IEC 13818-2で規定されるMPEG2を用いる。光ディスク106は、DVD−RAMのような書き換え可能な光ディスクである。この光ディスク106においては、2048byteを1セクタとし、誤り訂正のため16セクタでECCブロックを構成する。
【0042】
<ファイルフォーマット>
本基本システムにおいて、AVストリーム管理のためのフォーマットとして用いる、QuickTimeファイルフォーマットについて説明する。QuickTime ファイルフォーマットとは、Apple 社が開発したマルチメディアデータ管理用フォーマットであり、PCの世界で広く用いられている。また、QuickTime ファイルフォーマットをベースとしてISO base media file formatが規格化されている。
【0043】
QuickTime ファイルフォーマットは、ビデオデータやオーディオデータ等(これらを総称してメディアデータとも呼ぶ)と管理情報とで構成される。両者を合わせてここでは、QuickTime ムービー(略してムービー)と称する。両者は、同じファイル中に存在してもよいし、別々のファイルに存在してもよい。
【0044】
図2(a)は、両者が同じファイル201中に存在する場合にとる構成を示している。各種情報は“atom”という共通の構造に格納される。より詳細には、第1の管理情報はMovie atom211という構造に格納され、メディアデータはMovie dataatom212という構造に格納される。Movie atom211における管理情報には、メディアデータ中の任意の時間に対応するメディアデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。一方、Movie data atom212におけるメディアデータすなわちAVストリーム(AV stream) 213は、AH(Atom Header) が付加される。このような構成では、Movie atomはメディアデータをatom内で参照している。
【0045】
図2(b)は、管理情報とメディアデータとをそれぞれ別々のファイル202,203に格納した場合の構成を示している。管理情報はMovie atom211という構造に格納されるが、メディアデータはatomには格納される必要はない。このとき、Movie atom211は、メディアデータを格納したファイル203を「外部参照」している、という。
【0046】
図2(c)に示すように、外部参照は、例えば、ファイル204におけるMovie atom211から、複数のファイル205,206にそれぞれ格納されるAVストリーム213(AV stream ♯1,♯2)に対して行うことが可能である。このような仕組みにより、AVストリーム213自体を物理的に移動することなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」や「非破壊編集」が可能になる。
【0047】
続いて、図3ないし図20を用いて、QuickTimeの管理情報のフォーマットについて説明する。
【0048】
まず、共通の情報格納フォーマットであるatomについて説明する。
【0049】
atomの先頭には、そのatomのサイズであるAtom size、およびそのatomの種別情報であるTypeが必ず存在する。Typeは4文字で区別され、例えば、図3に示すMovie atomでは'moov'となっており、Movie data atomでは'mdat'となっている。atomの先頭にあるAtom sizeおよびTypeの列を、ここでは“atom header”と称する。各atomは、別のatomを含むことができる。すなわち、atom間には階層構造がある。
【0050】
図3は、Movie atomの構成を示している。この構造において、“Movie header atom”は、そのMovie atomが管理するムービーの全体的な属性を管理する。“Track atom”は、そのムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納する。“User data atom”は、ユーザにて独自に定義可能なatomである。
【0051】
図4は、Track atomの構成を示している。“Track header atom”は、そのトラックの全体的な属性を管理する。“Edit atom”は、メディアデータのどの区間を、ムービーのどのタイミングで再生するかを管理する。“Track reference atom”は、本トラックと別のトラックとの関係を管理する。“Media atom”は、実際のビデオやオーディオといったデータを管理する。
【0052】
図5は、Track header atomの構成を示している。ここでは、後での説明に必要なもののみについて説明する。“Flags”は、属性を示すフラグの集合であり、代表的なものとしてTrack enabledフラグがあり、このフラグが1であれば、そのトラックは再生され、0であれば再生されない。“Layer”は、そのトラックの空間的な優先度を表しており、画像を表示するトラックが複数あれば、Layerの値が小さいトラックほど画像が前面に表示される。
【0053】
図6は、Media atomの構成を示している。“Media header atom”は、そのMedia atomの管理するメディアデータに関する全体的な属性等を管理する。“Handler reference atom”は、メディアデータをどのデコーダでデコードするかを示す情報を格納する。“Media information atom”は、ビデオやオーディオ等のメディア固有の属性情報を管理する。
【0054】
図7は、Media information atomの構成を示している。“Media information header atom”は、ビデオやオーディオ等メディア固有の属性情報を管理する。“Handler reference atom”は、前述のMedia atomに含まれるものと同じである。“Data information atom”は、そのQuickTimeムービーが参照するメディアデータを含むファイルの名称を管理するatomである“Data reference atom”を含む。“Sample table atom”は、データのサイズや再生時間等を管理している。
【0055】
次に、Sample table atomについて説明するが、その前に、QuickTimeにおけるデータの管理方法について、図8を用いて説明する。
【0056】
QuickTimeでは、データの最小単位(例えばビデオフレーム)をサンプル(sample)と称する。サンプルには、個々のトラック毎に、再生時間順に1から番号(サンプル番号)が♯1,♯2,…♯iというように付与されている。
【0057】
また、QuickTimeフォーマットでは、個々のサンプルの再生時間長およびデータサイズを管理している。しかも、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンク(chunk) と称する。チャンクにも、サンプルと同様に、再生時間順に1から番号が付与されている。
【0058】
さらに、QuickTimeフォーマットでは、個々のチャンクのファイル先頭からのアドレスおよび個々のチャンクが含むサンプル数を管理している。これらの情報に基づき、任意の時間に対応するサンプルの位置を求めることが可能となっている。
【0059】
図9は、Sample table atomの構成を示している。“Sample description atom”は、個々のチャンクのデータフォーマット(Data format) やサンプルが格納されているファイルのチャンクの Index等を管理する。“Time-to-sample atom”は、個々のサンプルの再生時間を管理する。
【0060】
“Sync sample atom”は、個々のサンプルのうち、デコード開始可能なサンプルを管理する。“Sample-to-chunk atom”は、個々のチャンクに含まれるサンプル数を管理する。“Sample size atom”は、個々のサンプルのサイズを管理する。“Chunk offset atom”は、個々のチャンクのファイル先頭からのアドレスを管理する。
【0061】
図10は、Edit atom の構成を示している。Edit atom は、1個のEdit list atomを含む。Edit list atomは、Number of entriesで指定される個数分の、“Track duration”、“Media time”、“Media rate”の値の組(エントリ)を持つ。各エントリは、トラック上で連続的に再生される区間に対応し、そのトラック上での再生時間順に並んでいる。
【0062】
Track durationは、そのエントリが管理する区間のトラック上での再生時間を表している。Media timeは、そのエントリが管理する区間の先頭に対応するメディアデータ上での位置を表している。Media rateは、そのエントリが管理する区間の再生スピードを表している。
【0063】
なお、Media timeが−1の場合は、そのエントリのTrack duration分、そのトラックに無再生区間を挿入する。この区間のことをempty editと称する。
【0064】
図11は、Edit list の使用例を示す。ここでは、Edit list atomの内容が図11(a)に示す内容であり、さらにサンプルの構成が図11(b)であったとする。なお、ここではi番目のエントリのTrack durationをD(i) 、Media timeをT(i) 、Media rateをR(i) とする。このとき、実際のサンプルの再生は、図11(c)に示す順に行われる。このことについて簡単に説明する。
【0065】
まず、エントリ♯1は、D(1) が13000、T(1) が20000、R(1) が1であるため、そのトラックの先頭から13000の区間は、サンプル中の時刻20000から33000の区間を再生する。次に、エントリ♯2は、D(2) が5000、T(2) が−1であるため、トラック中の時刻13000から18000の区間、何も再生を行わない(図11(c)における“null”)。
【0066】
最後に、エントリ♯3は、D(3) が10000、T(3) が0、R(3) が1であるため、トラック中の時刻18000から28000の区間において、サンプル中の時刻0から10000の区間を再生する。
【0067】
図12は、User data atomの構成を示している。このatomには、QuickTimeフォーマットで定義されてない独自の情報を任意個数格納することができる。1個の独自情報は1個のエントリで管理され、1個のエントリは“Size”と“Type”と“User data ”とで構成される。Sizeはそのエントリ自体のサイズを表し、Typeは独自情報をそれぞれ区別するための識別情報を表し、User dataは実際のデータを表している。
【0068】
次に、録画中の電源遮断等に対応するために導入された概念であるFragmented Movieについて説明する。Fragmented movieは、QuickTime フォーマットの1アプリケーションであるMotion JPEG2000 で導入された概念であり、上述のSample table atomに相当する情報を、部分的なAVストリーム毎に管理することが可能となっている。Motion JPEG2000 では、atomの代わりにbox という用語を用いているが、ここでは統一のためにatomに置き換えて説明する。
【0069】
図13は、Fragmented movieを導入したQuickTime ファイル401の全体構成を示している。先頭に、そのファイル全体に共通する情報を管理するMovie atom(情報管理部)402が配置され、その後に、部分AVストリームデータを格納するMovie data atom(データ格納部)403と、その部分AVストリームデータを構成するサンプルのアドレスやサイズ、再生時間等を管理するMovie fragment atom (管理部)404とが交互に配置される。なお、AVストリームデータは、通常の QuickTimeファイルと同様、別ファイルに存在しても構わない。
【0070】
録画時には、この順番で記録を行なっていくことにより、録画時の電源切断による被害を最小限に防ぐことが可能となっている。Movie atom402には、そのQuickTime ムービーがFragmented movie であることを示すためのMovie extends atom4021が含まれる。Movie extends atom4021には、そのムービーに含まれる各トラックに関するデフォルト値(Track extends atom4042) が格納される。
【0071】
また、 Movie fragment atom404には、その Movie fragment atom404が管理する部分AVストリームに関する管理情報が含まれている。管理情報には、その管理する部分AVストリーム全体に関する情報を格納するMovie fragment header atom 4041と、部分AVストリーム中の各トラックに関する情報を格納する Track fragment atom4042とがある。
【0072】
Track fragment atom4042は、それが管理するトラックに属する部分AVストリームに関する情報を格納するTrack fragment header atom4043と、そのトラックに属する部分AVストリームを構成する論理的な連続領域(Track runと呼ばれる)をそれぞれ管理する Track fragment run atom4044とを含む。以下に、各atomについて詳しく説明する。
【0073】
図14は、 Movie extends atom4021の構成を示している。Movie extends atom4021は、前述のように、このatomを含む QuickTimeムービーがFragmented movieであることを示す役割を持つ。
【0074】
図15は、Track extends atom4021の構成を示す。Track extends atom 4021は、この QuickTimeムービーに含まれる各トラックのサンプルのデフォルト値を設定するために存在する。Track-IDは、Movie atom中で定義されているトラックのtrack-IDを参照する。“Default-sample- ”で始まるフィールドは、このatomで管理されるtrack fragmentのデフォルト値を設定する。
【0075】
図16は、 Movie fragment atom404の構成を示している。このatomは、録画中に逐次記録される管理情報であり、前述のとおり、このatomの管理するMovie fragmentに関する実際の情報を格納するatomである Movie fragment header atom4043や Track fragment atom4042を含む。
【0076】
図17は、Movie fragment header atom4043の構成を示している。このatomに格納されている主な情報は“sequence-number ”である。sequence-numberは、このatomが含まれるMovie fragment atom404が管理するMovie fragmentの先頭からの順番を表す。
【0077】
図18は、 Track fragment atom4042の構成を示す。Track fragment atom4043は、Movie fragmentに含まれる特定のトラックのサンプルに関する管理情報であるTrack fragment header atom4043やTrack fragment run atom4044を格納する。
【0078】
図19は、Track fragment header atom4043の構成を示している。このatomは、Movie fragmentに含まれる特定のトラックのサンプルに関するデフォルト値等を格納する。track-IDは、Movie atom中で定義されているトラックのtrack IDとの対応を示す。sample-description-indexは、このatomが管理するサンプルの参照するsample description tableのインデックス番号、“default-sample- ”で始まるフィールドは、それぞれこのatomが管理するサンプルのデフォルト値である。
【0079】
図20は、 Track fragment run atom4044の構成を示す。このatomは、Track runと呼ばれる、このatomの管理する連続領域や個々のサンプルの管理情報を格納する。sample-countは、Track run に含まれるサンプルの個数を示す。data-offset は、base-data-offsetからのTrack run のオフセット値を示す。“sample- ”で始まるフィールドは、このatomが管理するサンプルの再生時間等の値を格納する。ただし、上述のデフォルト値と同じであれば、省略してデータサイズを縮小することが可能となっている。
【0080】
<ファイルシステム>
本発明の説明において用いるファイルシステムのフォーマットであるUDF(Universal Disk Format) について図21を用いて説明する。図21(b)は、図21(a)に示すディレクトリ/ファイル構成をUDFで記録した例を示す。
【0081】
図中のAVDP(Anchor Volume Descriptor Pointer)602は、UDFの管理情報を探すためのエントリポイントに相当し、通常256セクタ目、Nセクタ目あるいはN−256セクタ目(Nは最大論理セクタ番号)に記録される。
【0082】
VDS(Volume Descriptor Sequence)601は、UDFが管理する領域であるボリュームに関する管理情報を記録する。ボリュームは、一般に1枚の光ディスク106に1個存在し、その中にパーティションを一般に1個含む。
【0083】
FSD(File Set Descriptor) 603は、パーティションに1個存在する。パーティションの中での位置情報は、パーティションの先頭からのセクタ番号に相当する論理ブロック番号で示される。
【0084】
なお、1個の論理ブロックは1セクタに対応する。また、各パーティションには図示しないがSpace Bitmapと呼ばれる各論理ブロックがファイルにすでに割り当てられているか否かを示すテーブルが存在する。
【0085】
FSD603は、ルートディレクトリのFE(File Entry)604の位置情報(論理ブロック番号と論理ブロック数とで構成されて“extent”と呼ばれる)を含む。FEは、extentの集合を管理しており、extentを書き換えたり、追加や削除することで、ファイルを構成する実データの順番を変えたり、データの挿入や削除をしたりできる。
【0086】
FE604は、ルートディレクトリの直下のファイルやディレクトリの名称等を格納するFID(File Identifier Descriptor)611,612,…の集合を格納する領域605を管理する。領域605中のFID611,612は、それぞれファイル621,622のファイル名やextentの集合を管理するFE606,608の位置情報を含む。
【0087】
FE606は、ファイル621の実データを構成する領域である領域607,610をextentとして管理する。このとき、ファイル621の実データにアクセスするには、AVDP602、VDS601、FSD603、FE604、FID611、FE606、領域607、領域610の順にリンクを辿っていけばよい。
【0088】
光ディスク106のデータ記録領域には、図21(b)の構成でAVストリームが記録されている。前述のムービーファイル、すなわちAVストリームやMovie atom、Movie fragment atom 等の管理情報は、図21(b)の領域607,610で表されるファイルを構成する実データとして記録される。例えば、図2(a)のムービーファイル201のMovie atom211は、領域610の前半部分に記録され、AVストリームを含むMovie dara atom212は、領域610の後半部分および領域607全体に記録されるようなとこが考えられる。
【0089】
この場合、FE606には、ファイルシステムを通して、ムービーファイル201を読み出したときに、図2(a)の順に読み出されるように、領域610のextent、領域607のextentの順に位置情報を格納する。つまり、この例で示すように、ファイルを構成する実データは、実際には、光ディスク106では連続的に記録される保証はなく、また、ファイル中の順序で光ディスク106に記録される保証もない。
【0090】
ただし、次のような例外もある。ディスク媒体に対しては、ディスク上で物理的に離れた場所にあるデータにアクセスするのに、ピックアップの移動を伴い、その間にデータの読み出しおよび記録が停止する。そのため、管理情報を物理的に連続して記録することで、管理情報の読み出しを高速化したり、AVストリームを所定の長さ以上で連続的に記録したりすることで、ビデオデータやオーディオデータを途切れることなく再生することを保証するのはよく知られた技術である。
【0091】
〔第1の実施形態〕
本発明の第1の実施形態について、図22ないし図33を用いて説明する。
【0092】
<システム構成>
本実施形態に係るビデオディスクレコーダは、図1に示す前述のビデオディスクレコーダの構成と共通しているが、本実施形態で特徴的な処理部であるTS/PS変換部121について図22を用いて詳細に説明する。
【0093】
TS/PS変換部121は、ビデオPESパケット生成部1101、ビデオTSパケット生成部1102、ビデオTSパケット用バッファ1103、ビデオパック生成部1104、ビデオパック用バッファ1105、オーディオPESパケット生成部1111、オーディオTSパケット生成部1112、オーディオTSパケット用バッファ1113、オーディオパック生成部1114、オーディオパック用バッファ1115、TSマルチプレクサ1121、PSマルチプレクサ1122、およびビデオ解析部1131より構成される。
【0094】
次に、それぞれの処理部について説明する。
【0095】
ビデオPESパケット生成部1101は、ビデオ再生用バッファ111から読み出したビデオES(ビデオフレームデータ)に基づいてPES(Packetized Elementary Stream)パケットを生成する。オーディオPESパケット生成部1111も同様に、オーディオ再生用バッファ110から読み出したオーディオESに基づいてPESパケットを生成する。ビデオ解析部1131は、ビデオ再生用バッファ111からのビデオESにおけるビデオフレームの境界を検出する。ビデオPESパケット生成部1101は、その境界に基づいてビデオチャンクをビデオフレームに分割する。
【0096】
ビデオTSパケット生成部1102は、ビデオPESパケット生成部1101からのPESパケットに基づいてTS(Transport Stream)パケット(ビデオTSパケット)を生成する。オーディオTSパケット生成部1112は、オーディオPESパケット生成部1111からのPESパケットに基づいてTSパケット(オーディオTSパケット)を生成する。
【0097】
TSマルチプレクサ1121は、ビデオTSパケット生成部1102およびオーディオTSパケット生成部1112によって生成されたTSパケットを、多重化してMPEG2−TSを生成する。ビデオTSパケット用バッファ1103およびオーディオTSパケット用バッファ1113は、ビデオTSパケット生成部1102およびオーディオTSパケット生成部1112からのTSパケットを一時的に蓄えることにより、両TSパケット生成部1102,1112とTSマルチプレクサ1121との処理の時間差を吸収する。
【0098】
ビデオパック生成部1104は、ビデオPESパケット生成部1101から送られてきたビデオPESパケットをグループ化してビデオパックを生成する。オーディオパック生成部1114も同様に、オーディオPESパケット生成部1111から送られてきたオーディオPESパケットをグループ化してオーディオパックを生成する。
【0099】
PSマルチプレクサ1122は、ビデオパック生成部1104およびオーディオパック生成部1114によって生成されたパックを多重化してMPEG2−PSを生成する。ビデオパック用バッファ1105およびオーディオパック用バッファ1115は、ビデオパック生成部1104およびオーディオパック生成部1114からのパックを一時的に蓄えることにより、両パック生成部1104,1114とPSマルチプレクサ1122との処理の時間差を吸収する。
【0100】
<AVストリームの形態>
本実施形態において用いるAVストリームの構成について、図23および図24を用いて説明する。
【0101】
AVストリーム701は、整数個のCU(Continuous Unit) 702で構成される。CU702は、ディスク上で連続的に記録する単位である。CU702の長さは、AVストリーム701を構成するCU702をどのように光ディスク106上に配置してもシームレス再生(再生中に画像や音声が途切れないで再生できること)やリアルタイムアフターレコーディング(アフレコ対象のビデオをシームレス再生しながらオーディオを記録すること)が保証されるように設定される。この設定方法については後述する。
【0102】
CU702は、先頭から連続する番号が♯1,♯2,…,♯Lのように付与されており、各CU702は整数個のVU(Video Unit)703から構成される。VU703は、単独再生可能な単位であり、そのことから再生の際のエントリポイントとなり得る。また、VU703も、先頭から連続する番号が♯1,♯2,…,♯Mのように付与される。
【0103】
図24は、VU703構成を示している。ユニットとしてのVU703は、1秒程度のビデオデータを格納した複数(整数個)のGOP704(画像データ群)と、それらと同じ時間に再生されるオーディオデータを格納した複数(整数個)のオーディオ復号単位であるAAU705とから構成される。
【0104】
なお、GOP704は、MPEG2ビデオ規格における画像圧縮の単位であり、複数のビデオフレーム(典型的には15フレーム程度)で構成される。AAU705は、MPEG1オーディオのレイヤII(Layer-II)規格における音声圧縮の単位で、1152点の音波形サンプル点により構成される。サンプリング周波数が48kHzの場合、AAU705あたりの再生時間は0.024秒となる。VU703中では、AV同期再生のために必要となる遅延を小さくするため、AAU705が配置され、それに続いてGOP704が配置される。
【0105】
また、VU703単位で独立再生を可能とするために、VU703におけるビデオデータ(GOP704)の先頭には、ランダムアクセスの頭出しのために用いられるSH(Sequence Header) 706が配置される。VU703の再生時間は、VU703に含まれるビデオフレーム数にビデオフレーム周期を乗算した時間と定義する。
【0106】
ビデオデータについては、TS/PSへの変換の容易さを考慮して、ピクチャ層(picture header())におけるvbv_delay に以下の制限を設ける。まず、MPEG2ビデオ規格におけるvbv_delay について説明する。MPEG2ビデオ規格において、vbv_delay は、一定速度のCBR(Constant Bit Rate) の場合、ストリーム検証用の仮想的なモデルであるVBV(Video Buffering Verifier)におけるVBVバッファにピクチャの最初のデータが入ってから、実際にそのピクチャがデコードされるまでの遅延時間を格納している。一方、可変速度のVBR(Variable Bit Rate) の場合、vbv_delay は、CBRと同様に遅延時間を格納することも、格納しないことも可能である。なお、遅延時間を格納していないことを示すために、vbv_delay に0xFFFFを格納する。
【0107】
本実施形態では、vbv_delay に対して、VBRの場合においても必ず、遅延時間を格納するように制限する。このことによって、後述するように、TS/PSに変換する際、MPEG規格に沿った多重化が容易になる。
【0108】
<AVストリーム管理方法>
AVストリームの管理方法は、前述の QuickTimeファイルフォーマットをベースにしている。
【0109】
図25は、AVストリーム管理形態を示している。ビデオデータ,オーディオデータをそれぞれビデオトラック,オーディオトラックで管理し、ビデオトラックについては、1個のGOP704を1サンプル(Sample)、VU703におけるビデオの塊となるVC(Video Cghunk)707を1チャンクとして管理する。オーディオトラックについては、AAU705を1サンプル、VU703中のオーディオの塊となるAC(Audio Chunk) 708を1チャンクとして管理する。
【0110】
<CU単位決定方法>
次に、CU単位決定方法について説明する。この決定方法では、基準となるデバイス(リファレンスデバイスモデル)を想定し、その上でシームレス再生が破綻しないように連続記録単位を決める。
【0111】
まず、リファレンスデバイスモデルについて図26を用いて説明する。
【0112】
リファレンスデバイスモデルは、1個のピックアップとそれにつながるECCエンコーダデコーダ501、トラックバッファ502、デマルチプレクサ503、アフレコ(アフターレコーディング)用バッファ504、オーディオエンコーダ509、ビデオバッファ505、オーディオバッファ506、ビデオデコーダ507、およびオーディオデコーダ508によって構成される。
【0113】
本モデルにおけるシームレス再生は、VUのデコード開始時にトラックバッファ502上に少なくとも1個のVUが存在すれば保証されるものとする。オーディオフレームデータのECCエンコーダ501へのデータ入力速度およびECCデコーダ501からのデータ出力速度をRsとする。
【0114】
また、アクセスによる読み出し、記録の停止する最大期間をTaとする。さらに、短いアクセス(100トラック程度)に要する時間をTkとする。これらの期間(時間)には、シーク時間、回転待ち時間、アクセス後に最初にディスクから読み出したデータがECCから出力されるまでの時間が含まれる。本実施形態では、Rs=20Mbps、Ta=1秒、Tk=0.2秒とする。
【0115】
前記のリファレンスデバイスモデルにおいて再生を行った場合、次のような条件を満たせば、トラックバッファ502のアンダーフローがないことが保証できる。
【0116】
条件を示す前にまず、記号を定義する。AVストリームを構成するi番目の連続領域をC♯iとし、C♯i中に含まれる再生時間をTc(i) とする。Tc(i) は、C♯i中に先頭が含まれているVUの再生時間の合計とする。また、C♯iからC♯i+1へのアクセス時間をTaとする。
【0117】
また、再生時間Tc(i) 分のVU読み出し時間をTr(i) とする。この場合、トラックバッファ502をアンダーフローさせない条件とは、分断ジャンプを含めた最大読み出し時間をTr(i) としたとき、任意のC♯iにおいて、
Tc(i) ≧Tr(i) +Ta …式1
が成立することである。
【0118】
なぜなら、この式はシームレス再生の十分条件である、
【0119】
【数1】
【0120】
を満たす十分条件であるためである。
【0121】
式1中のTr(i) に、Tr(i) =Tc(i) ×(Rv+Ra)/Rsを代入して、Tc(i) で解くと、シームレス再生を保証可能なTc(i) の条件
Tc(i) ≧(Ta×Rs)/(Rs−Rv−Ra) …式2
が得られる。ここで、Raはオーディオデータのビットレートであり、Rvはビデオデータのビットレートである。
【0122】
つまり、各連続領域に先頭の含まれるVUの合計が上式を満たすようにすれば、シームレス再生を保証可能である。このとき、各連続領域には合計の再生時間が上式を満たす完全なVU群を含むように制限してもよい。
【0123】
<録画時の処理>
ユーザから録画が指示された場合のホストCPU101が前述のデータ記録プログラムを実行することによって実現される処理を、図27を参照しながら説明する。
【0124】
このとき記録するAVストリームは、ビデオのビットレートRvの上限が5Mbpsであり、オーディオのビットレートRaが256kbpsであり、VU再生時間Tvが約0.5秒固定ストリームであるとする。また、ファイルシステムの管理情報はすでにRAM102上に読み込まれているものとする。
【0125】
まず、ストリームの構成や連続領域の構成を決定する(S701)。ここでは、1VUを1GOP15フレームで構成するとしたとき、式2にRs=20Mbps、Ta=1秒、Rv=5Mbps、Ra=256kbpsを代入し、T(c) の範囲1.4秒以上が得られる。Tvが約0.5秒であるため、CUは3個のVUで構成すればよい。
【0126】
まず、RAM102上のSpace Bitmapを参照して9個のVUを連続的に記録可能な空き領域を探す。空き領域が存在しなければ、録画を中止し、録画できないことをユーザに知らせる(S702)。
【0127】
また、オーディオエンコーダ117およびビデオエンコーダ118をそれぞれ起動する(S703)。そして、記録用バッファ114に1ECCブロック分(例えば32KB)以上のデータが蓄積されているか否かをチェックする(S704)。
【0128】
1ECCブロック分以上のデータが蓄積されていれば、次に記録するディスク上のECCブロックの空き状況をRAM102上のSpace Bitmapを参照して調べる(S705)。ECCブロックの空きがなければ、3個のVUを記録可能な連続的な空き領域を探し(S706)、その空き領域の先頭へピックアップを移動させる(S707)。
【0129】
そして、記録用バッファ114中の1ECCブロック分のデータをディスクに記録して(S708)、処理をS704に戻す。また、S705でECCブロックの空きがあれば、S708の記録を行う。S705〜S708の処理は、S704で1ECCブロック分以上のデータが蓄積されていないと判定されるまで繰り返される。一方、S704で記録用バッファ114に1ECCブロック分のデータが蓄積されていないと判定されると、記録終了が指示されているかどうかをチェックし(S709)、記録終了が指示されていない場合はS704を実行する。
【0130】
S709で記録終了が指示されていた場合、以下のステップを実行する。まず、記録用バッファ114における1ECCブロックに満たないデータに関して、末尾にダミーデータを付加し1ECCブロックにする(S710)。次に、S705〜S708と同様にして、そのデータをディスク上に記録する(S711〜S714)。RAM102上の QuickTime管理情報(Movie atom)とファイルシステム管理情報とを光ディスク106に記録して(S715,716)、処理を終える。
【0131】
以上の処理と並行するオーディオエンコーダ117、ビデオエンコーダ118やマルチプレクサ113の動作について説明する。ビデオエンコーダ118およびオーディオエンコーダ117がエンコードした結果は、それぞれビデオ記録用バッファ118およびオーディオ記録用バッファ119に一時的に蓄えられる。マルチプレクサ113は、ビデオ記録用バッファ118およびオーディオ記録用バッファ119からそれぞれデータを読み出し、それらの多重化を行い、記録用バッファ114に格納する。
【0132】
1VU分のデータ、つまり1GOPとそれに同期して再生されるAAUが記録用バッファ114に蓄積されたら、マルチプレクサ113は記録用バッファ114に1VUのデータを送る。
【0133】
さらに、マルチプレクサ113が、ホストCPU101に1VU分のデータがエンコードできたことを通知すると、ホストCPU101はVUを構成するGOPやAAUの数およびサイズを基にRAM102上の QuickTime管理情報を更新する。
【0134】
<TS変換時の処理>
本実施形態におけるTS変換時の処理を説明する。まず、ここでは、ビデオおよびオーディオそれぞれのTSパケット生成手順について説明した後、それらを多重化してTSを出力する手順について説明する。
【0135】
なお、TS変換を開始する時点に変換対象のムービーファイルのMovie atomの内容はRAM102に読み込まれているとする。
【0136】
(1)ビデオTSパケット生成
まず、前述のビデオPESパケット生成部1101、ビデオTSパケット生成部1102およびビデオ解析部1131によるビデオTSパケットの生成手順を図28を用いて説明する。
【0137】
ここでは、図28に示すように、エレメンタリストリームとしてのAVストリーム中のi番目のビデオチャンクに対応するビデオデータをビデオチャンクVChunk(i) と称し、AVストリーム中のj番目のオーディオチャンクに対応するオーディオデータをオーディオチャンクAChunk(j) と称する。以下の説明では、ビデオチャンクVChunk(i) を例に挙げる。VChunk(i) のトラック上での再生時刻は、Movie atom(図3参照)の情報から取得することができ、それをTv(i) とする。
【0138】
ビデオPESパケット生成部1101は、ビデオ再生用バッファ110から読み出されたビデオエレメンタリストリームにおけるビデオチャンクVChunk(i) をビデオフレーム単位(ビデオフレームデータ)に分割する。ビデオチャンクVChunk(i) を構成するビデオフレーム数がN(i) であるとき、それらのビデオフレームデータをVFRM(i,0) ,VFRM(i,1) ,…,VFRM(i,N(i)-1)と称する。ビデオフレームの境界は、図22に示すビデオ解析部1131がVChunk(i) を解析し、picture_header()を検出することで得られる。なぜなら、ビデオフレームデータの先頭には、picture_header()が存在するため、picture_header()を検出することは、ビデオフレームデータの先頭位置すなわち境界位置を得ることになる。なお、picture_header()の先頭は、特性のビットパターンであるため、ビデオエレメンタリストリーム中から容易に検出することができる。また、ビデオ解析部1131は、その解析の際、前述のpicture_header()から、各フレームのピクチャタイプ(I,P,B)も同時に取得する。
【0139】
また、ビデオPESパケット生成部1101は、各ビデオフレームデータの先頭データが前述のVBVバッファに入ってからデコードを行うまでの遅延量を求める。n番目のビデオフレームデータの遅延量をVDELAY(i,n) と称し、n番目のビデオフレームデータのpicture header()中のvbv_delay を用いる。また、ビデオPESパケット生成部1101は、このビデオストリーム中での最大ビットレートを示す、sequence header() 中のbitrateを取得し、変数Rmax に格納する。
【0140】
次に、ビデオPESパケット生成部1101は、ビデオフレームデータをPESパケットにパケット化する。PESパケットVPKT(i,0) ,VPKT(i,1) ,…,VPKT(i,N(i)-1)は、ビデオフレームデータVFRM(i,0) ,VFRM(i,1) ,…,VFRM(i,N(i)-1)から、それぞれ一対一の対応で生成される。
【0141】
各PESパケットのヘッダ部分には、ビデオデータであることの属性を表すstream id やPTS(Presentation Time Stamp) およびDTS(Decording Time Stamp)の2種類のタイムスタンプが設定される。このうち、stream id には11100000bが設定される。また、n番目のPESパケットのPTS,DTSをそれぞれVPTS(i,n),VDTS(i,n) と呼ぶとき、VPTS(i,n) ,VDTS(i,n) は次のルールで設定される。
【0142】
なお、各フレームの後に連続するBピクチャの個数をb(n) と呼ぶ。例えば、I,B,B,P,…のピクチャが連続するGOP構成の場合、0番目のビデオフレームであるIピクチャに対するb(0) は2となる。また、ビデオフレーム周期を9kHz クロックでカウントした値をTfとする。まず、VChunk(i) 中にBピクチャが存在する場合は、IピクチャおよびPピクチャに対し、
PTS(i,n) =Tv(i) +(n+b(n) )×Tf
DTS(i,n) =Tv(i) +(n−1)×Tf
を設定し、Bピクチャに対し、
PTS(i,n) =Tv(i) +(n−1)×Tf
DTS(i,n) =Tv(i) +(n−1)×Tf
を設定する。一方、VChunk(i) 中にBピクチャが存在しない場合、各ビデオフレームに対し、
PTS(i,n) =DTS(i,n) =Tv(i) +n×Tf
を設定する。
【0143】
次に、ビデオTSパケット生成部1102によるTSパケットの生成について説明する。
【0144】
ビデオTSパケット生成部1102は、各PESパケットを先頭から184バイト単位で所定の大きさに分割し、分割されたデータの直前にTSパケットのヘッダを4バイト付加することによってTSパケットを生成する。ここで、図28に示すように、n番目のビデオPESパケットであるVPKT(i,n) からK(i,n) 個のTSパケットが生成される場合、それぞれのTSパケットをVTSP(i,n,0) ,VTSP(i,n,1) ,…,VTSP(i,n,K(i,n)-1)と称する。
【0145】
このとき、ビデオTSパケット生成部1102は、それぞれのTSパケットに対し、理想的なPCR(System Clock Reference)を付与する。このPCRの値は、TSパケット中には格納されず、あくまでも後段のTSパケット多重化の際の多重タイミング設定の指標に用いるための情報である。ここで、k番目のTSパケットに対応する理想的なPCRをVPCR(i,n,k) とする。k=0の場合、
VPCR(i,n,k) =DTS(i,n) −VDELAY(i,n)
とする。一方、0<k<K(i,n) の場合、
VPCR(i,n,k) =VPCR(i,n,0) +184×8×k×27000000/Rmax
とする。
【0146】
また、ビデオTSパケットのヘッダ中の各フィールドには次のように値を設定する。例えば、パケットを識別するためのPID(Packet Identification) に0x1011を格納し、TSパケットがPESパケットの先頭バイトを含んでいた場合、ペイロード(payload unit start indicator)に1をセットする。
【0147】
生成されたビデオTSパケットは、上記のVPCRを付与された状態でビデオTSパケット用バッファ1103に順に送られ、図28に示すように、ビデオチャンクやビデオフレームの区別が取り去られて一次元でアクセス可能になる。すなわち、ビデオTSパケット総数をVCOUNTとすると、生成された順にVTSP(0) ,VTSP(1) ,…,VTSP(VCOUNT-1)と呼ぶことになる。
【0148】
(2)オーディオTSパケット生成
続いて、前述のオーディオPESパケット生成部1111およびオーディオTSパケット生成部1112によるオーディオTSパケットの生成手順を図29を用いて説明する。
【0149】
図29に示すように、AVストリーム中のj番目のオーディオチャンクに対応するオーディオデータをAChunk(j) と称する。以下の説明では、オーディオチャンクAChunk(j) を例に挙げる。AChunk(j) のトラック上での再生時刻は、オーディオデータを管理しているトラックのsample table atom (図7参照)を参照することで取得可能であり、sample table atom を含むMovie atom(図3参照)の情報から取得することができ、それをTp(j)とする。
【0150】
オーディオPESパケット生成部1111は、オーディオ再生用バッファ111から読み出されたオーディオエレメンタリストリームにおけるオーディオチャンクAChunk(j) をオーディオフレーム単位(オーディオフレームデータ)に分割する。分割のために必要な情報は、AChunk(j) を構成する各オーディオフレームのデータ長である。各オーディオフレームのデータ長は、オーディオデータを管理しているトラックのsample size atom(図9参照)を参照することで取得可能である。オーディオチャンクAChunk(j) を構成するオーディオフレーム数がM(j) であるとき、それらのオーディオフレームデータをAFRM(j,0) ,AFRM(j,1) ,…,AFRM(j,M(j)-1)と称する。また、m番目のオーディオフレームのデータ長をAFLEN(j,m)とする。
【0151】
次に、オーディオPESパケット生成部1111は、オーディオフレームデータをPESパケットにパケット化する。PESパケットAPKT(j,0) ,APKT(j,1) ,…,APKT(j,M(i)-1)は、オーディオフレームデータAFRM(j,0) ,AFRM(j,1) ,…,AFRM(j,M(j)-1)から、それぞれ一対一の対応で生成される。
【0152】
各PESパケットのヘッダ部分には前述のstream idやPTSが設定される。このうち、stream idには11000000が設定される。また、m番目のPESパケットのPTSをAPTS(j,m) と呼び、オーディオフレーム周期を9KHzクロックでカウントした値をTafとしたときAPTS(j,m) は、
APTS(j,m) =Tp(j) +m×Taf
とする。上記のTafは、Sample tableから取得することが可能である。
【0153】
次に、オーディオTSパケット生成部1112によるTSパケットの生成について説明する。
【0154】
オーディオTSパケット生成部1112は、各PESパケットを先頭から184バイト単位で所定の大きさ分割し、分割されたデータの直前にTSパケットのヘッダを4バイト付加することによってTSパケットを生成する。ここで、図29に示すように、n番目のオーディオPESパケットであるAPKT(j,m) からH(j,m) 個のTSパケットが生成される場合、それぞれのTSパケットをATSP(j,m,0) ,ATSP(j,m,1) ,…,ATSP(j,m,H(j,m)-1)と称する。
【0155】
このとき、前述のビデオTSパケットの生成時と同様、それぞれのTSパケットに対し、理想的なPCRを付与する。このPCRの値は、TSパケット中には格納されず、あくまでも後段のTSパケット多重化の際の多重タイミング設定の指標に用いるための情報である。ここで、h番目のTSパケットに対応する理想的なPCRをAPCR(j,m,h) とする。h=0の場合、オーディオのビットレートをRaとしたとき、
APCR(j,m,h) =APTS(j,m) −AFLEN(j,m) ×8×2/Ra
にする。一方、0<h<H(j,m) の場合、
APCR(j,m,h) =APCR(j,m,0) +184×8×h×27000000/Ra
とする。上記のRaは、Sample table中のサンプルのdurationとsizeとから求めることが可能である。
【0156】
また、オーディオTSパケットのヘッダ中の各フィールドには次のように値を設定する。例えば、PIDには、0x1021を格納し、TSパケットがPESパケットの先頭バイトを含んでいた場合、前述のペイロードに1をセットする。
【0157】
生成されたオーディオTSパケットは、上記のAPCRを付与された状態でオーディオTSパケット用バッファ1113に順に送られ、図29に示すように、オーディオチャンクやオーディオフレームの区別が取り去さられて一次元でアクセス可能になる。すなわち、オーディオTSパケット総数をACOUNTとすると、生成された順にATSP(0) ,ATSP(1) ,…,ATSP(ACOUNT-1)と呼ぶことになる。
【0158】
(3)TSパケット多重化
上記のようにして生成されたビデオおよびオーディオのTSパケットからTSマルチプレクサ1121によってTSを生成するための手順を、図30に示すフローチャートを用いて説明する。
【0159】
まず、現在の処理対象のTSパケットのカウンタ値STCを初期化する(S1101)。初期化には、VPCRおよびAPCRのうち最も値の小さいものを用いる。次に、ビデオTSパケット用バッファ1103に蓄えられているビデオTSパケットおよびオーディオTSパケットバッファ1113に蓄えられているオーディオTSパケットをそれぞれ指定するためのインデックスであるvindexおよびaindexをリセットする(S1102)。そして、以下の処理をビデオTSパケット用バッファ1103およびオーディオTSパケット用バッファ1113が空になるまで、すなわちvindexまたはaindexが所定値のVCOUNTまたはACOUNTに達するまで行う(ステップS1103)。
【0160】
まず、PCRおよびSI(Service Information) やPSI(Program Specific Information)を挿入するタイミングをチェックし(S1104)、現在のSTCがPCR/PSI/SIを挿入するタイミングであるか否かをチェックする(S1105)。PCRを挿入する間隔は、MPEG規格によって、0.1秒以下に規定されている。また、SI/PSIの挿入間隔についてもARIB(Association of Radio Industries and Buisiness) ST-B21によって規定されている。したがって、前回挿入したときのSCRの値を記憶しておき、前回のSTC値と現在のSTC値の差分が0.1秒になったときが挿入するタイミングとなる。もし、挿入するタイミングであった場合、TSパケットを生成しPCR/PSI/SIの挿入を行う(ステップS1106)。PCRを含むTSパケットの場合、PCRには現在のSTCの値を設定する。
【0161】
S1105で、挿入するタイミングでなかった場合、次に、aindexで指し示されるATSPのAPCRの値がSTCの値以上であるか否かを調べる(S1111)。APCRの値がSTCの値以上であった場合、ATSP(aindex)を出力し(S1112)、aindexをインクリメントする(S1113)。
【0162】
S1111で、APCRの値がSTCの値未満であった場合(ATSPを出力するタイミングでなかった場合)、vindexで指し示されるVTSPのVPCRの値がSTCの値以上であるか否かを調べる(S1121)。VPCRの値がSTCの値以上であった場合、VTSP(vindex)を出力し(S1122)、vindexをインクリメントする(S1123)。
【0163】
S1121で、VPCRの値がSTCの値未満であった場合(現在のSTCの値が何も出力するタイミングでなかった場合)、null packet を出力する(S1131)。
【0164】
そして、何らかのTSパケットを出力したら、STCをインクリメントする(S1107)。STCのインクリメント量は、TS転送用に確保したビットレートによって決定される。TS転送用のビットレートを27Mbpsと設定しており、インクリメント量ΔSCRは1504となる。
【0165】
<PS変換時の処理>
本実施形態では、DVD-Video やDVD-Video Recording 規格を想定して1パックが2048バイトになるようにES−PS変換を行う。
【0166】
なお、変換対象のムービーファイルのMovie atomの内容はRAM102に読み込まれているとする。
【0167】
(1)ビデオパック生成
まず、前述のビデオPESパケット生成部1101およびビデオパック生成部1104によるビデオパックの生成手順を図31を用いて説明する。
【0168】
図31に示すように、AVストリーム中のi番目のビデオチャンクに対応するビデオデータをVChunk(i) と称する。以下の説明では、ビデオチャンクVChunk(i)を例に挙げる。VChunk(i) のトラック上での再生時刻はMovie atomの情報から取得することができ、それをTv(i) とする。
【0169】
ビデオPESパケット生成部1101は、前述のビデオTSパケット生成の場合と同様にビデオチャンクVChunk(i) をビデオフレーム単位に分割する。このときの手順はTS生成処理と同一であるため、説明を省略する。また、ビデオPESパケット生成部1101は、ビデオフレームデータをPESパケットにパケット化する。PESパケットは、ビデオフレームデータVFRM(i,0) ,VFRM(i,1) ,…,VFRM(i,N(i)-1)から、それぞれ複数生成される。
【0170】
ここでは、n番目のビデオフレームデータを例に挙げて説明する。VFRM(i,n)の先頭から、2034バイト単位でデータを切り出し、パケットに格納する。ただし、先頭だけはPTSおよびDTSを格納する空間が必要であるために2019バイトでデータを切り出す。さらに、VFRM(i,0) の先頭については、24バイトのシステムヘッダ(System Header) を挿入する必要があるため、さらに短い1995バイトでデータ切り出す。生成されたパケット数がG(i,n)個であるとき、PESパケットとしてVPKT(i,n,0) ,VPKT(i,n,1) ,…,VPKT(i,n,G(i,n)-1)が生成される。このうち、先頭のパケットとしてのVPKT(i,n,0) には、PTSおよびDTSを設定する必要があり、設定する値については、前述のTS変換の場合について説明したルールで計算する。
【0171】
次に、ビデオパック生成部1104によるビデオパックの生成について説明する。
【0172】
ビデオパック生成部1104は、所定数のPESパケットを14バイトのパックヘッダの後に格納してグループ化し、VChunk(i) の先頭のVPKT(i,0,0) の場合、パックヘッダとPESパケット群との間に前記のシステムヘッダを挿入する。ここで、g番目のビデオPESパケットVPKT(i,n,g) に対応するビデオパックをVPCK(i,n,g) と称する。
【0173】
このとき、ビデオパック生成部1104は、それぞれのパックのパックヘッダに対し、以下のような計算で求めたSCRを格納する。このSCRの値は、PS多重化の際に実際の値に書き換えられる。ここで、g番目のパックに対応する、計算上のSCRをVPCR(i,n,g) とする。k=0の場合、
VSCR(i,n,g) =DTS(i,n) −VDELAY(i,n)
とする。一方、0<g<G(i,n) の場合、
VSCR(i,n,g) =VPCR(i,n,0) +2048×8×k×27000000/Rmaxとする。また、パックヘッダ中の、多重化ビットレートを示すフィールドprogram mux rateには、1008Mbpsを示す0x0189c3を格納する。
【0174】
生成されたビデオパックは、上記のVSCRを付与された状態でビデオパック用バッファ1105に順に送られ、図31に示すように、ビデオチャンクやビデオフレームの区別が取り去さられて一次元でアクセス可能になる。すなわち、ビデオパック総数をVCOUNTとすると、生成された順にVPCK(0) ,VPCK(1) ,…,VPCK(VCOUNT-1)と呼ぶことになる。
【0175】
(2)オーディオパック生成
続いて、前述のオーディオPESパケット生成部1111およびオーディオパック生成部1114によるオーディオパックの生成手順を図32を用いて説明する。
【0176】
図32に示すように、AVストリーム中のj番目のオーディオチャンクに対応するオーディオデータをAChunk(j) と称する。以下の説明では、オーディオチャンクAChunk(j) を例に挙げる。AChunk(j) のトラック上での再生時刻はMovie atomの情報から取得することができ、それをTp(j) とする。
【0177】
オーディオPSパケット生成部1111は、前述のオーディオTSパケット生成の場合と同様に、オーディオチャンクAChunk(j) をオーディオフレーム単位に分割する。このときの手順は、TS生成処理の場合と同一であるため、その説明を省略する。また、オーディオPSパケット生成部1111は、オーディオフレームデータをPESパケットにパケット化する。PESパケットは、オーディオフレームデータAFRM(j,0) ,AFRM(j,1) ,…,VFRM(j,M(i)-1)からそれぞれ複数生成される。
【0178】
ここでは、m番目のオーディオフレームデータを例に挙げて説明する。AFRM(j,m)の先頭から、2025バイト単位でデータを切り出し、パケットに格納する。ただし、先頭だけはPTSを格納する空間が必要であるために2020バイトでデータを切り出す。生成されたパケット数がH(j,m) 個であるとき、PESパケットとしてAPKT(j,m,0) ,APKT(j,m,1) ,…,APKT(j,m,H(j,m)-1)が生成される。このうち、先頭のパケットであるAPKT(i,n,0) には、PTSを設定する必要があり、設定する値については、前述のTS変換の場合について説明したルールで計算する。
【0179】
次に、オーディオパック生成部1114によるオーディオパックの生成について説明する。
【0180】
オーディオパック生成部1114は、所定数のPESパケットを14バイトのパックヘッダの後に格納してグループ化する。ここで、g番目のオーディオPESパケットAPKT(j,m,h) に対応するオーディオパックをAPCK(j,m,h) と称する。
【0181】
このとき、オーディオパック生成部1114は、それぞれのパックのパックヘッダに対し、以下のような計算で求めたSCRを格納する。このSCRの値は、PS多重化の際に実際の値に書き換えられる。ここで、h番目のパックに対応する、計算上のSCRをAPCR(j,m,h) とする。h=0の場合、
ASCR(j,m,h) =APTS(j,m) −AFLEN(j,m) ×8×2/Ra
にする。一方、0<h<H(j,m) の場合、
ASCR(j,m,h) =ASCR(j,m,0) +2048×8×h×27000000/Ra
とする。また、パックヘッダ中の、多重化ビットレートを示すフィールドprogram mux rateには、1008Mbpsを示す0x0189c3を格納する。
【0182】
生成されたオーディオパックは、上記のASCRを付与された状態でオーディオパック用バッファ1115に順に送られ、図32に示すように、オーディオチャンクやオーディオフレームの区別が取り去られて一次元でアクセス可能になる。すなわち、オーディオパック総数をACOUNTとしたとき、生成された順にAPCK(0) ,ACPK(1) ,…,ACPK(ACOUNT-1)と呼ぶことになる。
【0183】
(3)パック多重化
以上のようにして生成されたビデオおよびオーディオのパックからPSマルチプレクサ1122によってPSを生成するための手順を、図33に示すフローチャートを用いて説明する。
【0184】
まず、現在のカウンタ値STCを初期化する(S1201)。初期化には、VSCRおよびASCRのうち最も値の小さいものを用いる。次に、ビデオパック用バッファ1105に蓄えられているビデオパックおよびオーディオパック用バッファ1115に蓄えられているオーディオパックをそれぞれ指定するためのインデックスであるvindexおよびaindexをリセットする(S1202)。そして、以下の処理をビデオパック用バッファ1105およびオーディオパック用バッファ1115が空になるまで、すなわちvindexまたはaindexが所定値のVCOUNTまたはACOUNTに達するまで行う(S1203)。
【0185】
まず、aindexで指し示されるオーディオパックAPCKのASCRの値がSTCの値以上であるか否かを調べる(S1204)。ASCRの値がSTCの値以上であった場合、APCK(aindex)を出力し(S1205)、aindexをインクリメントする(S1206)。
【0186】
S1204で、APCKを出力するタイミングでなかった場合、vindexで指し示されるVPCKのVSCRの値がSTCの値以上であるか否かを調べる(S1211)。VSCRの値がSTCの値以上であった場合、VTSP(vindex)を出力し(S1212)、vindexをインクリメントする(S1213)。
【0187】
なお、各パックの出力の際には、パックヘッダのSCRの値を現在のSTCの値に書き換える。
【0188】
次に、現在のSTCに該当するパックの有無にかかわらず、STCをインクリメントする(S1207)。STCのインクリメント量は、転送ビットレートによって決定される。ここでは、DVD-Video を対象にしているため、転送用ビットレートを1008Mbpsと設定しており、インクリメント量ΔSCRは43875となる。
【0189】
〔第2の実施形態〕
本発明の第2の実施形態について、図34ないし図36を用いて説明する。
【0190】
本実施形態は、TS/PS変換のために必要な情報をビデオデータを解析する必要がないように、ビデオデータ外にそれらの情報をあらかじめ記録しておく点が第1の実施形態と異なっている。本実施形態は、第1の実施形態と共通する部分が多いため、主に相違点について説明する。
【0191】
<システム構成>
図34に示すように、本実施形態におけるビデオディスクレコーダのシステム構成は、第1の実施形態のシステム構成と、ビデオ解析部1131を備えていないことを除いてほぼ同一である。その他の構成要素は、第1の実施形態の構成要素と同じであり、同じ構成要素については共通の符号を用いている。
【0192】
<AVストリームの形態>
図35は、本実施形態におけるAVストリーム構成を示している。基本的には、第1の実施形態のAVストリーム構成(図25参照)と同一であるが、VU703におけるオーディオデータとビデオデータとの間にVFI(Video Frame Information) 709というデータ領域が設けられている点で異なる。
【0193】
VFI709については、図36を用いて説明する。VFI709には、この情報が含まれるVU703の各ビデオフレームに関する情報が格納されている。VFI709中のNumber of framesは、VU703中のビデオフレーム数を示す。1GOPを1サンプルで管理した場合、Movie atom中の情報から、VU703中の正確なビデオフレーム数が得られる保証はないため、この情報が必要である。また、fsize[i]にはVU703中のi番目のビデオフレームデータに対応するデータサイズが、ftype[i]にはピクチャタイプが、vdelay[i]にはvbv_delayがそれぞれ格納されている。また、ビデオデータのビットレートはbitrate に格納されている。このような管理情報をビデオデータ外に設けることで、TS/PS変換時にビデオデータを解析する必要がなくなる。これにより、第1の実施形態におけるビデオ解析部1131が不要となるので、システム構成が簡略化される。
【0194】
VFI703は、オーディオデータとビデオデータとの間に挿入されている。これにより、AVストリームデータの部分的な移動や削除の際、VFI709のみが取り残される可能性が低くなる。また、直前のオーディオデータおよび直後のビデオデータの位置はSample tableから分かるため、VFI709の記録位置を管理するために、ムービーファイル中に管理情報を新規に追加する必要がなくなる。また、VFI709は、対応するビデオデータの直前に読み出されるので、対応するビデオデータが読み出されたら、直ちにTSへの変換のための処理を開始することが可能である。
【0195】
なお、本実施形態では、ビデオデータおよびVFI709は同一ファイルに格納されているが、本発明はそれに限定されるものではない。例えば、ビデオデータおよびVFI709が別ファイルであったとしても、VFI709がビデオデータよりも先に読み出されるように配置されていれば同様の効果を達成できる。
【0196】
また、これらの情報をMovie atomではなくAVストリーム701内に記録することによって、通常再生の際にMovie atomをRAM102に保持するために必要なメモリ量を増大させることがない。
【0197】
また、ここでは、VFI709中にピクチャタイプを記録しているが、ビデオデータのエンコードに際して両方向予測符号化を行わない場合には、ピクチャタイプは不要である。また、両方向予測符号化を行ったとしても、記録すべき情報はピクチャタイプに限定されない。例えば、フレーム間の表示順のようにピクチャタイプを導くことのできる情報であれば何でもよい。
【0198】
<記録処理>
本実施形態における記録処理は第1の実施形態の録画時の処理と同様であるが、AC(オーディオチャンク)708とVC(ビデオチャンク)709との間にVFI709を挿入された状態で記録を行う点が異なる。また、第1の実施形態と異なり、VBRの場合でも、picture_header()中のvbv_delayに0xffffをセットしてもよい。なぜなら、vbv_delayに想到する情報は、前述のVFI709に格納されているからである。
【0199】
<TS変換時の処理>
本実施形態におけるTS変換時の処理は第1の実施形態と類似するため、主に相違点を説明する。
【0200】
(1)ビデオTSパケット生成
まず、VChunk(i) の読み出し前に直前のVFI709が読み出されてRAM102に格納されているとする。
【0201】
VChunk(i) をビデオフレームデータに分解する際には、VFI709におけるfsizeを利用する。また、各ビデオフレームデータのピクチャタイプは、VFI709におけるftypeから直接取得することが可能である。また、VDELAYについてもVFI709におけるvdelayから直接取得することが可能である。またRxについてもVFI709におけるbitrateから直接取得することが可能である。このことは、VFI709をビデオデータとは別にまとめて用意しておくことで、ビデオ解析部1131によりビデオデータを解析する必要がなくなったことを意味する。
【0202】
なお、「(2)オーディオTSパケット生成」および「(3)TSパケット多重化」の処理は第1の実施形態での録画時の処理と同様であるため、その説明を省略する。
【0203】
<PS変換時の処理>
ビデオTSパケット生成と同様、VFI709内の情報を用いることで、本処理に必要な各フレームのデータ量、ピクチャタイプおよびvbv_delayの値を取得可能である。
【0204】
<バリエーション>
本実施形態では、vbv_delayに相当する値をAVストリーム701におけるGOP703外に記録しているが、Movie atom中の例えばUser data atomに記録したとしても、同様の効果が得られる。また、フレーム毎のデータ量やピクチャタイプに関する情報についても同様である。また、VFI709におけるbitrateは、固定ビットレートの場合はsample tableから算出できるため特に記録する必要はない。また、記録する場合もMovie atom中に記録しても同様の効果が得られることは言うまでもない。
【0205】
〔第3の実施形態〕
<システム構成>
本実施形態におけるシステム構成は第2の実施形態と共通であるため、その説明を省略する。
【0206】
<AVストリーム管理方法>
上記のAVストリームの管理情報の構成について説明する。AVストリームは、図37に示すように、ムービーファイル2401と、ムービーファイル2402とで管理される。
【0207】
ムービーファイル2401は、Movie data atomに格納された前述のAVストリーム701(図23参照)と、AVストリーム701を構成するサンプルのアドレスやサイズ、再生時間等を管理するMovie atomとで構成される。AVストリーム701は、前述のように、CU702で構成され、各CU702は必ず光ディスク106上で連続的に配置されるように記録される。
【0208】
一方、ムービーファイル2402は、ムービーファイル2401における各CU702を管理するmoof(Movie fragment atom) 710で構成される。
【0209】
この2つのファイル2401,2402は、図37に示すように、CU702単位で多重化されて、光ディスク106上に連続して記録される。ムービーファイル2401では1個のGOP704を1サンプルと扱っているのに対し、ムービーファイル2402ではビデオフレームを1サンプルとして扱う。そのため、ムービーファイル2401の管理情報に比べ、ムービーファイル2402の管理情報量は多くなる。
【0210】
また、ビデオフレーム間のフレーム順の入れ替わりを管理するため、前述のsample-composition-time-offsetを用いる。すなわち、sample-durationとsample-composition-time-offsetから、各サンプルのデコードタイミングと表示タイミングが分かる。このことは、各サンプル(ビデオフレーム)のピクチャータイプが分かることを意味する。
【0211】
また、ビデオトラックを管理するTrack fragment atomに前記のvbv_delayを管理するために、独自管理情報であるVBV delay atomを追加定義する。図38にVBV delay atomの構成を示すように、Track fragment atomで管理されるビデオフレームのvbv_delayの値を順に格納したものである。なお、このatomは一般のプレーヤでは無視されることになる。
【0212】
このように、管理情報をサイズ(大きさ)が異なるサンプルについて2個用意することによって、専用プレーヤで再生するときには、必要なメモリ容量の少ないムービーファイル2401を用い、汎用のQuickTime (あるいはISO base media file format)対応プレーヤで再生するときには、ムービーファイル2402を用いることで、省メモリと再生互換性とを両立することが可能となる。
【0213】
<記録時の処理>
本実施形態における記録時の処理は第1の実施形態での録画時の処理と共通しているが、Movie fragmentをContinuous Unit毎に記録する点が異なる。また、第1の実施形態と異なり、VBRの場合でも、picture_header()中のvbv_delayに0xffffをセットしてもよい。なぜなら、vbv_delayに想到する情報は、前述のVBV delay atomに格納されているからである。
【0214】
<TS変換時の処理>
(1)ビデオTSパケット生成
まず、VChunk(i) の読み出し前に、VChunk(i) に対応するMovie fragment atom 710は読み出されてRAM102に格納されているとする。
【0215】
本実施形態でVChunk(i) をビデオフレームデータに分解する際には、Track fragment run atom中のsample-sizeから取得した各ビデオフレームデータのデータ量を用いる。また、各ビデオフレームデータのピクチャタイプは次のように取得できる。
【0216】
まず、Track fragment run atom 中のsample-composition-time-offset が0のものはBピクチャと判断できるが、0でなかった場合、Track fragment run atom 中のsample flag を見る。sample flag 中には、対応するサンプル画、キーフレームであるか否かのフラグがあり、そのフラグが1の場合はIピクチャと判断でき、そうでない場合はPピクチャと判断できる。また、VDELAYについては、Track fragment atom 中のVBV delay atomの値から直接取得可能である。つまり、第2実施形態と同様、ビデオ解析部1131によりビデオデータを解析する必要が無い。以下の「(2)オーディオTSパケット生成処理」および「(3)TSパケット多重化」の処理は第1の実施形態での処理と同様であるため、その説明を省略する。
【0217】
<PS変換時の処理>
PS変換時の処理は第1の実施形態の処理とほぼ同様であるため、主に異なる点について説明する。
【0218】
(1)ビデオパック生成
ビデオTSパケット生成と同様、Track fragment atom中の情報を用いることで、本処理に必要な各フレームのデータ量、ピクチャタイプおよびVBV delayの値を取得可能である。
【0219】
(2)オーディオパック生成
第1の実施形態と同様であるため省略する。
【0220】
(3)パック多重化
第1の実施形態と同様であるため省略する。
【0221】
<バリエーション>
本実施形態では、vbv_delayに相当する値をVBV delay atomとして管理情報に記録しているが、この記録は必須ではない。なぜなら、各ビデオフレームのピクチャタイプおよびデータ量を元に、VBVバッファの占有量をシミュレートすることで、MPEG規格に準拠したTS/PSを生成できるからである。ただし、その場合、シミュレーションに伴う処理の複雑化が生じる。
【0222】
なお、以上に述べた各実施形態では、光ディスク106にAVストリームを記録することについて説明してきたが、AVストリームを記録する記録媒体としては、光ディスクに限らず、ランダムアクセス可能な記録媒体であれば、例えばハードディスクや半導体メモリであってもよい。
【0223】
〔他の実施形態〕
本発明の実施形態の記録方法は、1個以上のGOPで構成される1個以上の第1のユニットを含むAVストリームと、AVストリームとは別の場所に第1のユニットに関する第1の管理情報(Movie atom 等)を記録媒体に記録する記録方法であって、AVストリーム中に、個々の前記第1のユニットに関する第2の管理情報を記録し、第2の管理情報(Video Frame Information)は、対応する第1のユニットを構成するGOPを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【0224】
また、前記記録方法では、第2の管理情報のデータフォーマットにISO base media file formatにおけるMovie Fragment(Movie Fragment atom)を用いることが好ましい。
【0225】
また、他の記録方法は、1個以上のGOPで構成される1個以上の第1のユニットを含むAVストリームと、AVストリームとは別の場所に第1のユニットに関する第1の管理情報を記録媒体に記録する記録方法であって、GOPを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記記録媒体に記録する。
【0226】
また、前記遅延時間はAVストリーム中に記録されることが好ましい。
【0227】
また、さらに他の記録方法は、AVストリーム中に、個々の第1のユニットに関して第2の管理情報を記録し、第2の管理情報は、対応する第1のユニットを構成するGOPを構成するビデオフレームデータ毎のデータ量および前記遅延時間を持つ。
【0228】
前記第2の管理情報は、対応する前記第1のユニットの物理的な近傍に配置されることが好ましい。
【0229】
前記各記録方法では、第2の管理情報と前記第1のAVストリームとを同一ファイルで管理し、前記第2の管理情報を対応するGOPよりも低いアドレスに置くことが好ましい。
【0230】
前記記録方法では、前記遅延時間は少なくとも前記GOP外に記録し、第1の管理情報は、GOPを構成するビデオフレームデータ毎のデータ量および遅延時間情報を持つことが好ましい。
【0231】
前記第1の管理情報は、ビデオフレーム間のピクチャタイプに関する情報を持つことが好ましい。前記第1の管理情報は、GOPを構成するビデオフレームデータ毎のデータ量および前記ビデオフレーム間のピクチャタイプに関する情報および前記遅延時間を持つことが好ましい。前記第2の管理情報は、ビデオフレーム間のピクチャタイプに関する情報を持つことが好ましい。
【0232】
本発明の実施形態のAVストリーム変換方法は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、GOPを構成するビデオフレームデータ毎のデータ量に関する情報を持記録媒体に関して、前記第1のAVストリームを第2のAVストリームに変換するAVストリーム変換方法であって、変換の際に、前記データ量に関する情報を用いる。
【0233】
また、他のAVストリーム変換方法は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、GOPを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、前記第1のAVストリームを第2のAVストリームに変換するAVストリーム変換方法であって、変換の際に、前記遅延時間を用いる。
【0234】
また、さらに他のAVストリーム変換方法は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、GOPを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とデータ量が記録されている記録媒体に関して、第1のAVストリームを第2のAVストリームに変換するAVストリーム変換方法であって、変換の際に、前記遅延時間および前記データ量を用いる。
【0235】
また、さらに他のAVストリーム変換方法は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、GOPを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とデータ量とピクチャタイプに関する情報が記録されている記録媒体に関して、前記第1のAVストリームを第2のAVストリームに変換するAVストリーム変換方法であって、変換の際に、遅延時間および前記データ量およびピクチャタイプに関する情報を用いる。
【0236】
本願の実施形態の記録装置は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、第1のAVストリームとは別の場所に前記第1のユニットに関する第1の管理情報を記録媒体に記録する記録装置であって、AVストリーム中に、個々の前記第1のユニットに関する第2の管理情報を記録する手段を備え、第2の管理情報は、対応する第1のユニットを構成する前記GOPを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【0237】
また、他の記録装置は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、第1のAVストリームとは別の場所に第1のユニットに関する第1の管理情報を記録媒体に記録する記録装置であって、GOPを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記記録媒体に記録する手段を備える。
【0238】
本発明の実施形態のAVストリーム変換装置は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、GOPを構成するビデオフレームデータ毎のデータ量に関する情報を記録媒体に関して、第1のAVストリームを第2のAVストリームに変換するAVストリーム変換装置であって、前記データ量に関する情報を用いる変換手段を備える。
【0239】
他のAVストリーム変換装置は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、GOPを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、第1のAVストリームを第2のAVストリームに変換するAVストリーム変換装置であって、遅延時間を用いて変換する。
【0240】
本発明の実施形態の記録媒体は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、第1のAVストリームとは別の場所に第1のユニットに関する第1の管理情報を記録した記録媒体であって、AVストリーム中に、個々の前記第1のユニットに関する第2の管理情報を記録し、第2の管理情報は、対応する第1のユニットを構成する前記GOPを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【0241】
他の記録媒体は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、第1のAVストリームとは別の場所に第1のユニットに関する第1の管理情報した記録媒体であって、GOPを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を記録してある。
【0242】
本発明の実施形態のコンピュータプログラムは、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、第1のAVストリームとは別の場所に前記第1のユニットに関する第1の管理情報を記録媒体に記録するステップを有するコンピュータプログラムであって、AVストリーム中に、個々の第1のユニットに関する第2の管理情報を記録するステップを有し、第2の管理情報は、対応する第1のユニットを構成するGOPを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【0243】
また、他のコンピュータプログラムは、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、第1のAVストリームとは別の場所に第1のユニットに関する第1の管理情報を記録媒体に記録するステップを有するコンピュータプログラムであって、GOPを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記記録媒体に記録するステップを有する。
【0244】
また、さらに他のコンピュータプログラムは、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、GOPを構成するビデオフレームデータ毎のデータ量に関する情報を持記録媒体に関して、第1のAVストリームを第2のAVストリームに変換するステップを有するコンピュータプログラムであって、変換ステップが、前記データ量に関する情報を用いる。
【0245】
また、さらに他のコンピュータプログラムは、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、GOPを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、第1のAVストリームを第2のAVストリームに変換するステップを有するコンピュータプログラムであって、変換ステップが遅延時間を用いる。
【0246】
本発明の実施形態の記録媒体は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、第1のAVストリームとは別の場所に第1のユニットに関する第1の管理情報を記録媒体に記録するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、AVストリーム中に、個々の第1のユニットに関する第2の管理情報を記録するステップを有し、第2の管理情報は、対応する第1のユニットを構成する前記GOPを構成するビデオフレームデータ毎のデータ量に関する情報を持つ。
【0247】
また、他の記録媒体は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、第1のAVストリームとは別の場所に第1のユニットに関する第1の管理情報を記録媒体に記録するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、GOPを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を記録媒体に記録するステップを有する。
【0248】
また、さらに他の記録媒体は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、GOPを構成するビデオフレームデータ毎のデータ量に関する情報を持記録媒体に関して、第1のAVストリームを第2のAVストリームに変換するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、変換ステップがデータ量に関する情報を用いる。
【0249】
また、さらに他の記録媒体は、1個以上のGOPで構成される1個以上の第1のユニットを含む第1のAVストリームと、GOPを構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されている記録媒体に関して、第1のAVストリームを第2のAVストリームに変換するステップを有するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、変換ステップが遅延時間を用いる。
【0250】
また、データ変換装置およびデータ変換方法は、ビデオエレメンタリストリームにおけるデータ管理の最小単位である第1ビデオデータ単位の複数からなる第2ビデオデータ単位をビデオフレームデータに分割し、該ビデオフレームデータをパケット化して第1パケットを生成する第1パケット生成手段(処理)と、前記第1パケットを所定の大きさに分割して第1分割パケットを生成する第1分割パケット生成手段(処理)と、オーディオエレメンタリストリームにおけるデータ管理の最小単位である第1オーディオデータ単位の複数からなる第2オーディオデータ単位をオーディオフレームデータに分割し、該オーディオフレームデータをパケット化して第2パケットを生成する第2パケット生成手段(処理)と、前記第2パケットを所定の大きさに分割して第2分割パケットを生成する第2分割パケット生成手段(処理)と、前記第1および第2分割パケットを多重化して多重化ストリームを生成する多重化手段(処理)とを備えている。
【0251】
上記の構成では、第1パケット生成手段(処理)によって、QuickTime ファイルフォーマットのビデオエレメンタリストリームが第2ビデオデータ単位のビデオフレームデータに分割され、このビデオフレームデータを基に第1パケットが生成される。例えば、データ管理の最小単位である第1ビデオデータ単位はサンプルであり、第2ビデオデータ単位はチャンクである。そして、第1分割パケット生成手段(処理)によって、上記の第1パケットがさらに分割されて第1分割パケットが生成される。
【0252】
また、第2パケット生成手段(処理)によって、QuickTime ファイルフォーマットのオーディオエレメンタリストリームが第2オーディオデータ単位のオーディオフレームデータに分割され、このオーディオフレームデータを基に第2パケットが生成される。例えば、データ管理の最小単位である第1オーディオデータ単位はサンプルであり、第2オーディオデータ単位はチャンクである。そして、第2分割パケット生成手段(処理)によって、上記の第2パケットがさらに分割されて第2分割パケットが生成される。
【0253】
上記のようにして生成された第1および第2分割パケットは、多重化手段によって多重化され、その結果、MPEG2−TSストリームとしての多重化ストリームが生成される。
【0254】
このように、QuickTime ファイルフォーマットのビデオエレメンタリストリームおよびオーディオエレメンタリストリームからMPEG2−TSストリームが得られる。それゆえ、QuickTime ファイルフォーマットのAV(Audio and Visual)ストリームをMPEG2−TSのファイルフォーマットを採用する機器(IEEE-1394等)に転送することができる。
【0255】
他のデータ変換装置およびデータ変換方法は、ビデオエレメンタリストリームにおけるデータ管理の最小単位である第1ビデオデータ単位の複数からなる第2ビデオデータ単位をビデオフレームデータに分割し、該ビデオフレームデータをパケット化して第1パケットを生成する第1パケット生成手段(処理)と、複数の前記第1パケットをグループ化して第1パケット群を生成する第1パケット群生成手段(処理)と、オーディオエレメンタリストリームにおけるデータ管理の最小単位である第1オーディオデータ単位の複数からなる第2オーディオデータ単位をオーディオフレームデータに分割し、該オーディオフレームデータをパケット化して第2パケットを生成する第2パケット生成手段(処理)と、複数の前記第2パケットをグループ化して第2パケット群を生成する第2分割パケット群生成手段(処理)と、前記第1および第2パケット群を多重化して多重化ストリームを生成する多重化手段(処理)とを備えている。
【0256】
上記の構成では、第1パケット生成手段(処理)によって、前述のように、第1パケットが生成される。そして、第1パケット群生成手段(処理)によって、複数の第1パケットがグループ化されて第1パケット群が生成される。
【0257】
また、第2パケット生成手段(処理)によって、前述のように、第2パケットが生成される。そして、第2パケット群生成手段(処理)によって、複数の第2パケットがグループ化されて第2パケット群が生成される。
【0258】
上記のようにして生成された第1および第2パケット群は、多重化手段によって多重化され、その結果、MPEG2−PSストリームとしての多重化ストリームが生成される。
【0259】
このように、QuickTime ファイルフォーマットのビデオエレメンタリストリームおよびオーディオエレメンタリストリームからMPEG2−PSストリームが得られる。それゆえ、QuickTime ファイルフォーマットのAV(Audio and Visual)ストリームをMPEG2−PSのファイルフォーマットを採用する機器(DVDプレーヤ等)に転送することができる。
【0260】
前記の発明は、前記ビデオエレメンタリストリームと前記オーディオエレメンタリストリームとが多重化されてなるエレメンタリストリームを前記ビデオエレメンタリストリームと前記オーディオエレメンタリストリームとに分離してそれぞれを前記第1パケット生成手段(処理)と前記第2パケット生成手段(処理)とに与える分離手段(処理)を備え、前記エレメンタリストリームが、該エレメンタリストリームの格納されるファイルとは別のファイルに格納され、前記エレメンタリストリームの前記ビデオフレームデータに関する管理情報が付加され、前記第1パケット生成手段(処理)が、前記ビデオエレメンタリストリームに付随して分離された前記管理情報に基づいて第2ビデオデータ単位をビデオフレームデータに分割することが好ましい。
【0261】
上記の構成では、第1および第2パケット生成手段(処理)にそれぞれ与えられるビデオエレメンタリストリームおよびオーディオエレメンタリストリームは、分離手段(処理)によって、エレメンタリストリームから分離される。このエレメンタリストリームは、それが格納されるファイルとは別のファイルに格納され、エレメンタリストリームのビデオフレームデータに関する管理情報が付加されている。この管理情報としては、ビデオフレームデータ毎のデータ量、ビデオフレームデータのデコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間、ビデオフレームのピクチャタイプ等に関する情報が含まれる。
【0262】
これにより、第1パケット生成手段(処理)は、その管理情報に基づいて、ビデオエレメンタリストリームをビデオフレームデータに分割する。それゆえ、ビデオフレームデータの分割のためにエレメンタリストリームを解析してビデオフレームデータの分割位置を検出するための手段や処理が必要ない。
【0263】
あるいは、前記の発明は、前記分離手段(処理)を備え、前記エレメンタリストリームに、所定の間隔毎に前記ビデオフレームデータに関する管理情報が付加され、前記第1パケット生成手段が、前記ビデオエレメンタリストリームに付随して分離された前記管理情報に基づいて第2ビデオデータ単位をビデオフレームデータに分割することが好ましい。
【0264】
この構成では、エレメンタリストリームに、前述の管理情報が付加されているので、ビデオフレームデータの分割のためにエレメンタリストリームを解析してビデオフレームデータの分割位置を検出するための手段や処理が必要ない。
【0265】
また、前記の従来技術においては、管理情報量を減らすために、GOPを1サンプルとして管理している。しかしながら、QuickTime ファイルフォーマットでは、本来1ビデオフレームを1サンプルとして管理するのが原則であり、QuickTime ファイルフォーマットを扱うプレーヤや編集ソフトにおいて互換性に支障が生じる虞がある。なお、この原則は、QuickTime ファイルフォーマットをベースにしてISO/IEC 15444-3/FPDAmd 1として規格化されたISO base media file formatにも踏襲されている。
【0266】
そこで、上記の構成において、前記エレメンタリストリームは、大きさの異なる前記第1ビデオデータ単位で前記ビデオフレームデータを管理するための複数種の前記管理情報が付加されていることが好ましい。これにより、例えば、第1ビデオデータ単位をサンプルとした場合、GOPをサンプルとするようなメモリ(バッファ)容量の小さい専用プレーヤでビデオデータを再生する一方、ビデオフレームデータをサンプルとするようなQuickTime 対応プレーヤでビデオデータを再生することができる。
【0267】
また、上記の構成において、前記管理情報は、前記第2ビデオデータ単位のビデオフレームデータよりも先に読み出されるように設けられていることが好ましい。これにより、管理情報がエレメンタリストリームと同一のファイルに格納されているか否かに関わらず、管理情報がビデオフレームデータよりも先に読み出されるので、管理情報が読み出されてから、ビデオエレメンタリストリームにおいて分割されるべきビデオフレームデータが読み出される。それゆえ、第1パケット生成手段(処理)が、読み出された管理情報に基づいて、ビデオエレメンタリストリームのビデオフレームデータへの分割処理を速やかに行なうことができる。
【0268】
前記の発明は、前記分離手段(処理)を備え、前記エレメンタリストリームが、同一ファイルにおいて該エレメンタリストリームの設けられる領域と別の領域に設けられ、前記エレメンタリストリームの前記ビデオフレームデータに関する管理情報が1個の前記エレメンタリストリームと対をなすように付加され、前記第1パケット生成手段が、前記ビデオエレメンタリストリームに付随して分離された前記管理情報に基づいて第2ビデオデータ単位をビデオフレームデータに分割することが好ましい。
【0269】
この構成では、前記管理情報が、同一ファイルにおいてエレメンタリストリームの設けられる領域と別の領域に設けられ、1個のエレメンタリストリームと対をなすように付加されるので、前述の分離手段(処理)を備えた構成と同様に、エレメンタリストリームに、ビデオフレームデータの分割のためにエレメンタリストリームを解析してビデオフレームデータの分割位置を検出するための手段や処理が必要ない。
【0270】
データ変換プログラムは、前記のデータ変換方法における各処理をコンピュータに実行させ、また、このデータ変換プログラムは、コンピュータ読み取り可能な記録媒体に記録して提供可能である。
【0271】
【発明の効果】
以上のように、本発明によれば、ビデオデータ中のvbv_delayに常に値をセットするようにしたことで、ESをインターリーブしたAVストリーム構成においてTS/PSへの変換を容易にしかも確実にすることが可能である。
【0272】
また、通常の管理情報とは別に、ビデオデータの各ビデオフレームのデータ量、ピクチャタイプ、vbv_delay値を、ビデオデータとは別の位置に記録することで、TS/PS変換時にビデオデータを解析する必要がなくなる。また、これらの情報をAVストリーム中に記録し、通常再生に用いる管理情報とは別にすることで、通常再生時の管理情報を記憶するためのメモリを増加させることはない。
【0273】
さらに、通常再生に用いる管理情報とは別に、ビデオデータの各ビデオフレームのデータ量、ピクチャタイプ、vbv_delayを求めることが可能な情報を、ISO base media file formatで規定されているMovie fragmentの形式で格納することによって、専用プレーヤだけでなく、ISO base media file formatあるいはQuickTimeファイルフォーマットに対応したプレーヤで再生可能になる。
【図面の簡単な説明】
【図1】本発明の実施形態に係るビデオディスクレコーダの概略構成を示すブロック図である。
【図2】 (a)ないし(c)はQuickTime ファイルフォーマットにおける管理情報とAVストリームとの関係を示す図である。
【図3】 QuickTime ファイルフォーマットにおけるMovie atomの概要を示す図である。
【図4】 QuickTime ファイルフォーマットにおけるTrack atomの概要を示す図である。
【図5】 QuickTime ファイルフォーマットにおけるTrack header atom の構成を示す図である。
【図6】 QuickTime ファイルフォーマットにおけるMedia atomの構成を示す図である。
【図7】 QuickTime ファイルフォーマットにおけるMedia information atomの構成を示す図である。
【図8】 Sample table atomによるデータ管理の例を示す図である。
【図9】 QuickTime ファイルフォーマットにおけるSample table atom の構成を示す図である。
【図10】 QuickTime ファイルフォーマットにおけるEdit atom の構成を示す図である。
【図11】 Edit atomによる再生範囲指定の例を示す説明図である。
【図12】 QuickTime ファイルフォーマットにおけるUser data atomの構成を示す図である。
【図13】 QuickTime ファイルフォーマットにおけるFragmented movieの全体構成を示す図である。
【図14】 QuickTime ファイルフォーマットにおけるMovie extends atomの構成を示す図である。
【図15】 QuickTime ファイルフォーマットにおけるTrack extends atomの構成を示す図である。
【図16】 QuickTime ファイルフォーマットにおけるMovie fragment atom の構成を示す図である。
【図17】 QuickTime ファイルフォーマットにおけるMovie fragment header atomの構成を示す図である。
【図18】 QuickTime ファイルフォーマットにおけるTrack fragment atom の構成を示す図である。
【図19】 QuickTime ファイルフォーマットにおけるTrack fragment header atomの構成を示す図である。
【図20】 QuickTime ファイルフォーマットにおけるTrack fragment run atom の構成を示す図である。
【図21】(a)はディレクトリ/ファイル構成を示す図であり、(b)はそのディレクトリ/ファイル構成のUDFにおける管理を示す図である。
【図22】本発明の第1の実施形態に係るビデオディスクレコーダにおけるTS/PS変換部の概略構成を示すブロック図である。
【図23】上記第1の実施形態におけるAVストリームの構成を示す図である。
【図24】上記第1の実施形態におけるVUの構造を示す図である。
【図25】上記第1の実施形態におけるQuickTime によるAVストリーム管理形態を示す図である。
【図26】上記第1の実施形態におけるリファレンスデバイスモデルを示す説明図である。
【図27】上記第1の実施形態における記録処理の手順を示すフローチャートである。
【図28】上記第1の実施形態におけるビデオTSパケット生成処理の概念を示す図である。
【図29】上記第1の実施形態におけるオーディオTSパケット生成処理の概念を示す図である。
【図30】上記第1の実施形態におけるTSパケット多重化処理の手順を示すフローチャートである。
【図31】上記第1の実施形態におけるビデオPSパック生成処理の概念を示す図である。
【図32】上記第1の実施形態におけるオーディオPSパック生成処理の概念を示す図である。
【図33】上記第1の実施形態におけるPSパック多重化処理の手順を示すフローチャートである。
【図34】本発明の第2の実施形態に係るビデオディスクレコーダにおけるTS/PS変換部の概略構成を示すブロック図である。
【図35】上記第2の実施形態におけるVUの構造を示す図である。
【図36】上記第2の実施形態におけるQuickTime によるAVストリーム管理形態を示す図である。
【図37】本発明の第3の実施形態に係るビデオディスクレコーダにおけるAVストリームの構成を示す図である。
【図38】上記第3の実施形態におけるVBV delay atomの構成を示す図である。
【図39】従来技術におけるQuickTime ファイルフォーマットを用いたAVファイルの構成を示す図である。
【符号の説明】
100 バス
101 ホストCPU
102 RAM
103 ROM
104 ユーザインタフェース
107 光ピックアップ(記録手段)
109 ECCエンコーダ(記録手段)
110 オーディオ再生用バッファ
111 ビデオ再生用バッファ
112 デマルチプレクサ
113 マルチプレクサ
115 オーディオデコーダ
116 ビデオデコーダ
117 オーディオエンコーダ
118 ビデオエンコーダ
121 TS/PS変換部(変換手段)
123 記録媒体
201 Movie atom(第1の管理情報)
404 Movie fragment atom(第2の管理情報)
701 AVストリーム
703 VU(ユニット)
704 GOP(画像データ群)
705 AAU
707 VC
708 AC
709 VFI(第2の管理情報)
710 Movie fragment atom(第2の管理情報)
1101 ビデオPESパケット生成部
1111 オーディオPESパケット生成部
1102 ビデオTSパケット生成部
1112 オーディオTSパケット生成部
1121 TSマルチプレクサ
1122 PSマルチプレクサ
Claims (23)
- 1個以上の画像データ群を含む1個以上のユニットを含むAVストリームと、前記AVストリームを記録する領域とは別の領域に前記ユニットに関する第1の管理情報とをデータ記録媒体に記録するデータ記録方法であって、
前記AVストリーム中に前記ユニットの個々に関する第2の管理情報を含んだ状態で前記AVストリームを記録し、
前記第2の管理情報は、対応する前記ユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴とするデータ記録方法。 - 第2の管理情報のデータフォーマットにISO base media file formatにおけるMovie Fragmentを用いることを特徴とする請求項1に記載のデータ記録方法。
- 1個以上の画像データ群を含む1個以上のユニットを含むAVストリームと、前記AVストリームを記録する領域とは別の領域に前記ユニットに関する第1の管理情報とをデータ記録媒体に記録するデータ記録方法であって、
前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記データ記録媒体に記録することを特徴とするデータ記録方法。 - 前記遅延時間を含んだ前記AVストリームを記録することを特徴とする請求項3に記載のデータ記録方法。
- 前記AVストリーム中に前記ユニットの個々に関する第2の管理情報を含んだ状態で前記AVストリームを記録し、
前記第2の管理情報は、対応するユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間を持つことを特徴とする請求項4に記載のデータ記録方法。 - 前記第2の管理情報を、対応する前記ユニットの物理的な近傍に配置することを特徴とする請求項5に記載のデータ記録方法。
- 前記第2の管理情報と前記AVストリームとを同一ファイルで管理し、前記第2の管理情報を対応する前記画像データ群よりも低い前記ファイルの先頭からの相対アドレスに置くことを特徴とする請求項5に記載のデータ記録方法。
- 前記遅延時間を少なくとも前記画像データ群外に記録し、
前記第1の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記遅延時間情報を持つことを特徴とする請求項4に記載のデータ記録方法。 - 前記第1の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことを特徴とする請求項5に記載のデータ記録方法。
- 前記第1の管理情報は、前記画像データ群を構成するビデオフレームデータ毎のデータ量および前記ビデオフレームのピクチャタイプに関する情報および前記遅延時間を持つことを特徴とする請求項3に記載のデータ記録方法。
- 前記第2の管理情報は、前記ビデオフレームのピクチャタイプに関する情報を持つことを特徴とする請求項3または6記載のデータ記録方法。
- 1個以上の画像データ群を含む1個以上のユニットを含む第1のAVストリームと、前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報とが記録されているデータ記録媒体から読み出された前記第1のAVストリームを第2のAVストリームに変換するデータ変換方法であって、
前記データ量を用いて前記画像データ群をビデオフレームに分割して前記第1のAVストリームを前記第2のAVストリームに変換することを特徴とするデータ変換方法。 - 1個以上の画像データ群を含む1個以上のユニットを含む第1のAVストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とが記録されている記録媒体から読み出された前記第1のAVストリームを第2のAVストリームに変換するデータ変換方法であって、
前記遅延時間を用いて前記画像データ群をビデオフレームに分割して前記第1のAVストリームを前記第2のAVストリームに変換することを特徴とするデータ変換方法。 - 1個以上の画像データ群を含む1個以上のユニットを含む第1のAVストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間およびデータ量とが記録されている記録媒体から読み出された前記第1のAVストリームを第2のAVストリームに変換するデータ変換方法であって、
前記遅延時間および前記データ量を用いて前記画像データ群をビデオフレームに分割して前記第1のAVストリームを前記第2のAVストリームに変換することを特徴とするデータ変換方法。 - 1個以上の画像データ群を含む1個以上のユニットを含む第1のAVストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間、データ量およびピクチャタイプとが記録されている記録媒体から読み出された前記第1のAVストリームを第2のAVストリームに変換するデータ変換方法であって、
前記遅延時間、前記データ量および前記ピクチャタイプを用いて前記画像データ群をビデオフレームに分割して前記第1のAVストリームを前記第2のAVストリームに変換することを特徴とするデータ変換方法。 - 1個以上の画像データ群を含む1個以上のユニットを含むAVストリームと、前記AVストリームとは別の領域に前記ユニットに関する第1の管理情報とをデータ記録媒体に記録するデータ記録装置であって、
前記AVストリーム中に前記ユニットの個々に関する第2の管理情報を含んだ状態で記録する記録手段を備え、
前記第2の管理情報は、対応する前記ユニットを構成する前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴とするデータ記録装置。 - 1個以上の画像データ群を含む1個以上のユニットを含むAVストリームと、前記AVストリームとは別の場所に前記ユニットに関する第1の管理情報とをデータ記録媒体に記録するデータ記録装置であって、
前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間を前記データ記録媒体に記録する記録手段を備えることを特徴とするデータ記録装置。 - 1個以上の画像データ群を含む1個以上のユニットを含む第1のAVストリームと、前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を記録されているデータ記録媒体から読み出された前記第1のAVストリームを第2のAVストリームに変換するデータ変換装置であって、
前記データ量に関する情報を用いて前記画像データ群をビデオフレームに分割して前記第1のAVストリームを第2のAVストリームに変換する変換手段を備えることを特徴とするデータ変換装置。 - 1個以上の画像データ群を含む1個以上のユニットを含む第1のAVストリームと、前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間とが記録されている記録媒体から読み出された前記第1のAVストリームを第2のAVストリームに変換するデータ変換装置であって、
前記遅延時間を用いて前記画像データ群をビデオフレームに分割して前記第1のAVストリームを第2のAVストリームに変換する変換手段を備えることを特徴とするデータ変換装置。 - 1個以上の画像データ群を含む1個以上のユニットを含むAVストリームと、前記AVストリームが記録された領域とは別の領域に前記ユニットに関する第1の管理情報が記録されているデータ記録媒体であって、
前記AVストリームは、前記ユニットの個々に関する第2の管理情報を含み、前記第2の管理情報は、対応する前記ユニットにおける前記画像データ群を構成するビデオフレームデータ毎のデータ量に関する情報を持つことを特徴とするデータ記録媒体。 - 1個以上の画像データ群を含む1個以上のユニットを含むAVストリームと、前記AVストリームが記録されている領域とは別の領域に前記ユニットに関する第1の管理情報が記録されているデータ記録媒体であって、
前記画像データ群を構成するビデオフレームに関する、デコード時にデコーダ直前のバッファに入ってからデコードされるまでの遅延時間が記録されていることを特徴とするデータ記録媒体。 - 請求項1ないし11のいずれか1項に記載のデータ記録方法をコンピュータに実行させるデータ記録プログラム。
- 請求項22のデータ記録プログラムを記録したコンピュータ読み取り可能な 記録媒体。
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 |
---|---|---|---|---|
CN101682718B (zh) * | 2007-04-04 | 2015-09-09 | 韩国电子通信研究院 | 基于iso基本媒体文件格式的mpeg-2传输流的存储/回放方法和设备 |
-
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) | Avデータ記録再生装置及び方法、当該avデータ記録再生装置又は方法で記録されたディスク | |
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) | Avデータ記録方法、avデータ記録装置、データ記録媒体、及びプログラム | |
JP4616144B2 (ja) | データ処理装置 | |
KR20080089129A (ko) | 기록 방법 | |
JP4312783B2 (ja) | Avデータ再生方法、avデータ再生装置、プログラム、並びに記録媒体 | |
JP2003052017A (ja) | Avデータ記録装置及び方法、当該avデータ記録装置又は方法で記録されたディスク、並びに当該ディスクを再生するavデータ再生装置及び方法又はavデータ記録再生装置及び方法 | |
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 |