Nothing Special   »   [go: up one dir, main page]

JP3847751B2 - データ記録方法、データ記録装置、データ記録媒体、データ再生方法及びデータ再生装置 - Google Patents

データ記録方法、データ記録装置、データ記録媒体、データ再生方法及びデータ再生装置 Download PDF

Info

Publication number
JP3847751B2
JP3847751B2 JP2003577266A JP2003577266A JP3847751B2 JP 3847751 B2 JP3847751 B2 JP 3847751B2 JP 2003577266 A JP2003577266 A JP 2003577266A JP 2003577266 A JP2003577266 A JP 2003577266A JP 3847751 B2 JP3847751 B2 JP 3847751B2
Authority
JP
Japan
Prior art keywords
data
heading
information
atom
recorded
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
Application number
JP2003577266A
Other languages
English (en)
Other versions
JPWO2003079359A1 (ja
Inventor
次郎 木山
智哉 紫村
裕利 岩野
英士 木付
孝好 山口
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sharp Corp
Original Assignee
Sharp Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Sharp Corp filed Critical Sharp Corp
Publication of JPWO2003079359A1 publication Critical patent/JPWO2003079359A1/ja
Application granted granted Critical
Publication of JP3847751B2 publication Critical patent/JP3847751B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/34Indicating arrangements 
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/034Electronic editing of digitised analogue information signals, e.g. audio or video signals on discs
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • G11B27/036Insert-editing
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/102Programmed access in sequence to addressed parts of tracks of operating record carriers
    • G11B27/105Programmed access in sequence to addressed parts of tracks of operating record carriers of operating discs
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/10Indexing; Addressing; Timing or synchronising; Measuring tape travel
    • G11B27/19Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
    • G11B27/28Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
    • G11B27/32Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
    • G11B27/327Table of contents
    • G11B27/329Table of contents on a disc [VTOC]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/8042Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components involving data reduction
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • G11B20/10527Audio or video recording; Data buffering arrangements
    • G11B2020/10537Audio or video recording
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B20/00Signal processing not specific to the method of recording or reproducing; Circuits therefor
    • G11B20/10Digital recording or reproducing
    • G11B2020/10898Overwriting or replacing recorded data
    • G11B2020/10907Overwriting or replacing recorded data using pseudo-overwriting, i.e. virtually or logically overwriting data on WORM media by remapping recorded blocks to alternate areas
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00Record carriers by type
    • G11B2220/20Disc-shaped record carriers
    • G11B2220/21Disc-shaped record carriers characterised in that the disc is of read-only, rewritable, or recordable type
    • G11B2220/215Recordable discs
    • G11B2220/218Write-once discs
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00Record carriers by type
    • G11B2220/20Disc-shaped record carriers
    • G11B2220/25Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537Optical discs
    • G11B2220/2545CDs
    • GPHYSICS
    • G11INFORMATION STORAGE
    • G11BINFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00Record carriers by type
    • G11B2220/20Disc-shaped record carriers
    • G11B2220/25Disc-shaped record carriers characterised in that the disc is based on a specific recording technology
    • G11B2220/2537Optical discs
    • G11B2220/2562DVDs [digital versatile discs]; Digital video discs; MMCDs; HDCDs
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N5/00Details of television systems
    • H04N5/76Television signal recording
    • H04N5/84Television signal recording using optical recording
    • H04N5/85Television signal recording using optical recording on discs or drums
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/804Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components
    • H04N9/806Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components with processing of the sound signal
    • H04N9/8063Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback involving pulse code modulation of the colour picture signal components with processing of the sound signal using time division multiplex of the PCM audio and PCM video signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N9/00Details of colour television systems
    • H04N9/79Processing of colour television signals in connection with recording
    • H04N9/80Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback
    • H04N9/82Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only
    • H04N9/8205Transformation of the television signal for recording, e.g. modulation, frequency changing; Inverse transformation for playback the individual colour picture signal components being recorded simultaneously only involving the multiplexing of an additional signal and the colour video signal

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)
  • Management Or Editing Of Information On Record Carriers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

技術分野
本発明は、ハードディスク、光ディスク等のランダムアクセス可能な記録媒体に対して、映像データ、音声データを記録するデータ記録方法、データ記録装置、データ記録媒体、データ再生方法、データ再生装置に関するものである。
背景技術
ディスクメディアを用いたビデオのディジタル記録再生装置(以下、ビデオディスクレコーダと呼ぶ)が普及しつつある。その記録フォーマットには、PC(パーソナル・コンピュータ)との親和性を高めるため、PCで広く使われている、例えばQuickTimeファイルフォーマットやAVI(Audio Video Interleave)ファイルフォーマットを用いることがよく行われる。
このようなPC用ファイルフォーマットを用いた場合のディスク中でのコンテンツの管理方法については、日本国公開特許公報特開2001−84705公報(2001年3月30日公開)に開示されている。以下、図60を用いてその概要を説明する。ディスク305中のファイル301〜303は、録画した各シーンあるいはショットに対応しそれぞれ1個のQuickTimeファイル(以下、QuickTimeムービーファイルと呼ぶ)である。
インデックスファイル300は、ディスク305中のデータの目次的な情報を格納するファイルであり、各QuickTimeムービーファイル毎にエントリが存在し、各エントリには対応するシーンの代表画面の縮小画像データ311〜313とシーンが含まれるファイルのファイル名が格納される。
ユーザにインデックス画面を提示する際は、各エントリの縮小画像データ311〜313をデコードした縮小画像321〜323をコンテンツ選択画面307に表示する。ユーザはコンテンツ選択画面307に表示されている複数の縮小画像の中から再生や編集をしたいファイルを選択する。例えば、ユーザが縮小画像323を選択し、再生を指示したら、縮小画像323に対応するコンテンツの含まれるファイルのファイル名であるファイル303を取得し、ファイル303の再生を開始する。
インデックスファイル300にディスク305中のすべてのコンテンツに関してそれを格納したファイルへのポインタと縮小画像データが含まれているため、インデックスファイル300をディスク305から読み出すだけで、コンテンツ選択画面307の表示が可能であり、Index画面表示に要する時間が少なくて済むという利点がある。コンテンツ選択画面307は頻繁に表示するものであるため、その表示時間の削減は全体的な体感レスポンス向上に大きく寄与する。
近年、追記型の光ディスクの利用が急激に増加している。CD−Rはその代表的な例である。また、DVD−Rも急速に価格が低下しており、身近なものになってきている。上記のインデックスファイルをこれらの追記型の光ディスクに適用した場合、以下のような問題がある。
インデックスファイルは使用が進むにつれ、そのサイズが大きくなる性質のファイルである。追記型のディスクでは、一度記録した領域に再度記録することができない。そのようなメディアにおいて、インデックスファイルのように、使用が進むにつれ、そのサイズが大きくなるファイルを扱う場合、記憶容量を無駄なく使うことが難しい。例えば、インデックスファイルに対しエントリの追加、削除、変更等が発生するたびに新規のインデックスファイルを追記して行った場合、大量の無駄が発生する。
本発明は、上記課題を鑑みてなされたものであり、追記型の記録媒体において記憶容量の無駄を削減することが可能なデータ記録方法を提供することを目的とする。
発明の開示
本発明のデータ記録方法は、記録媒体に、第1のデータと第2のデータと第3のデータを記録する記録方法であって、前記第1のデータは第4のデータを含み、前記第3のデータは、前記第4のデータに関する情報を含んでいる。
本発明のデータ記録方法では、前記第2のデータが、前記第4のデータと同一のデータを0個以上持っていてもよい。
本発明のデータ記録方法では、同一のデータを含むかどうかは、第4のデータの属性に基づくことができる。
本発明のデータ記録方法では、前記第4のデータの属性がデータ量であってもよい。
本発明のデータ記録方法では、前記第4のデータの属性が階層情報であってもよい。
本発明のデータ記録方法では、前記第4のデータの属性が優先度であってもよい。
本発明のデータ記録方法では、前記第4のデータの属性が、前記第4に関連するデータを再生した時刻であってもよい。
本発明のデータ記録方法では、前記第4のデータの属性を前記記録媒体に記録してもよい。
本発明のデータ記録方法では、前記第1のデータと前記第2のデータを1個のファイルとして管理し、前記第4のデータを含む前記第2のデータを整数個の記録ユニットで構成してもよい。
本発明のデータ記録方法では、前記第4のデータを含む前記第2のデータを整数個の記録ユニットで構成するために無意味データを挿入してもよい。
本発明のデータ記録方法では、前記無意味データを無効化するためのデータを前記記録媒体に記録してもよい。
本発明のデータ記録方法では、前記無意味データ挿入位置は前記無意味データを挿入可能な位置であってもよい。
本発明のデータ記録方法では、第1のデータを前記第4のデータの近傍の前方と後方を別のファイルとして管理し、前記ファイル間の関連情報を前記記録媒体に記録してもよい。
本発明のデータ記録方法では、前記第1のデータが、領域確保用データを含んでいてもよい。
本発明のデータ記録方法では、前記第1のデータと前記第2のデータを別のファイルに記録し、前記ファイル間の読み出し制御情報を前記記録媒体に記録してもよい。
本発明のデータ記録方法では、前記第1のデータと前記第2のデータを別のファイルとして管理し、前記ファイル間の関連情報を前記記録媒体に記録してもよい。
本発明のデータ記録方法では、前記関連情報を前記ファイル名で表してもよい。
本発明のデータ記録方法では、前記第3のデータが有効な前記第4のデータの含まれるファイル名と前記ファイル内での位置情報であってもよい。
本発明のデータ記録方法では、前記第3のデータが前記第4のデータを無効化する情報であってもよい。
本発明のデータ記録方法では、前記第3のデータと前記第4のデータを別のファイルに記録してもよい。
本発明のデータ記録方法では、前記第1のデータと前記第2のデータを同一のファイルとして管理してもよい。
本発明のデータ記録方法では、前記第4のデータの先頭位置が記録ユニット境界になるように記録してもよい。
本発明のデータ記録方法では、前記第2のデータを整数個の記録ユニットで構成してもよい。
本発明のデータ記録方法では、前記第3のデータが有効な第4のデータの前記ファイル内での位置情報であってもよい。
本発明のデータ記録方法では、前記第3のデータが前記第4のデータを無効化する情報であってもよい。
本発明のデータ記録方法では、前記第3のデータを前記記録媒体上の近傍に記録してもよい。
本発明のデータ記録方法では、第5のデータを前記記録媒体に記録し、第4のデータは、第5のデータに関する情報であってもよい。
本発明のデータ記録方法では、前記第5のデータに関する情報が、前記第5のデータの代表画像データ、代表音データ、タイトルデータ、属性データの少なくとも1であってもよい。
本発明のデータ記録方法では、前記記録媒体が追記型であってもよい。
本発明のデータ記録方法では、前記第3のデータを前回追記終了位置を示す情報の近傍に記録してもよい。
本発明のデータ記録方法では、前記第2のデータが前記第1のデータの追加データであってもよい。
本発明のデータ記録装置は、記録媒体に、第1のデータと第2のデータと第3のデータを記録する記録手段を備えるデータ記録装置であって、前記第1のデータは第4のデータを含み、前記第3のデータは、前記第4のデータに関する情報を含んでいる。
本発明のデータ記録媒体は、第1のデータと第2のデータと第3のデータが記録された記録媒体であって、前記第1のデータは第4のデータを含み、前記第3のデータは、前記第4のデータに関する情報を含んでいる。
本発明のデータ再生方法は、記録媒体上に、第1のデータと第2のデータと第3のデータが記録され、前記第1のデータは第4のデータを含み、前記第3のデータは、前記第4のデータに関する情報である記録媒体のデータ再生方法であって、再生制御を前記第3のデータに基づいて行う。
本発明のデータ再生装置は、記録媒体上に、第1のデータと第2のデータと第3のデータが記録され、前記第1のデータは第4のデータを含み、前記第3のデータは、前記第4のデータに関する情報である記録媒体のデータ再生装置であって、前記第3のデータに基づく制御手段を備えている。
本発明によれば、追記データを記録する際に、既存データの有効/無効を管理する情報を記録することによって、既存データの再利用が可能となり、記録容量の無駄を削減できる。
また、本発明によれば、追記データを記録する際に、既存データの属性に応じて既存データと同一データを記録することによって、特定の属性を持つデータを高速に読み出すことが可能となり、ユーザへのレスポンスを向上させることができる。
本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分わかるであろう。また、本発明の利益は、添付図面を参照した次の説明で明白になるであろう。
発明を実施するための最良の形態
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。ここでの説明は、本発明において共通に用いる構成、個々の実施形態に固有の内容という順に行っていく。
<システム構成>
図1は本発明において共通に用いる、ビデオディスクレコーダの構成図である。この装置は、図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、および図示しないカメラ、マイク、スピーカ、ディスプレイ等で構成される。
なお、図1のビデオディスクレコーダが請求の範囲における「データ記録装置(記録装置)」または「データ再生装置(再生装置)」に相当し、光ディスク100が請求の範囲における「データ記録媒体(記録媒体)」に相当する。
ホストCPU101は、バス100を通じてデマルチプレクサ112、マルチプレクサ113、ピックアップ107、また、バス100との接続は図示していないが、オーディオデコーダ115、ビデオデコーダ116、オーディオエンコーダ117、ビデオエンコーダ118の制御を行う。
再生時に、光ディスク106からピックアップ107を通じて読み出されたデータは、ECCデコーダ108によって誤り訂正され、再生用バッファ110に一旦蓄えられる。ホストCPU101は、再生中のデータに関する管理情報に基づき、オーディオデコーダ115、ビデオデコーダ116からのデータ送信要求に従い、再生用バッファ110中のデータをその種別によって適当なデコーダに振り分けるようデマルチプレクサ112に指示を与える。
なお、ピックアップ107、ECCデコーダ108、再生用バッファ110、デマルチプレクサ112、オーディオデコーダ115、ビデオデコーダ116、ホストCPU101、およびRAM102により、請求の範囲における「再生手段」が構成される。
一方、記録時に、オーディオエンコーダ117とビデオエンコーダ118によって圧縮符号化されたデータは、多重化用バッファ114に一旦送られ、マルチプレクサ113によってAV多重化され、記録/アフレコ用バッファ111に送られる。記録/アフレコ用バッファ111中のデータは、ECCエンコーダ109によって誤り訂正符号を付加され、ピックアップ107を通じて光ディスク106に記録される。
なお、ピックアップ107、ECCエンコーダ109、記録/アフレコ用バッファ111、マルチプレクサ113、多重化用バッファ114、オーディオエンコーダ117、ビデオエンコーダ118、ホストCPU101、およびRAM102により、請求の範囲における「記録手段」が構成される。
オーディオデータの符号化方式にはMPEG−1 Layer−IIを、ビデオデータの符号化方式にはMPEG−2をそれぞれ用いる。光ディスク106は、追記型の光ディスクであるDVD−Rとする。2048byteを1セクタとし、誤り訂正のため16セクタでECCブロックを構成する。
<ファイルフォーマット>
本発明でAVストリーム管理のためのフォーマットとして用いる、QuickTimeファイルフォーマットについて説明する。QuickTimeファイルフォーマットとは、Apple社が開発したマルチメディアデータ管理用フォーマットであり、PCの世界で広く用いられている。
QuickTimeファイルフォーマットは、ビデオデータやオーディオデータ等(これらを総称してメディアデータとも呼ぶ)と管理情報とで構成される。両者を合わせてここでは、QuickTimeムービー(略してムービー)と呼ぶ。両者は同じファイル中に存在しても、別々のファイルに存在しても良い。
管理情報とメディアデータとが同じファイル中に存在する場合は、図2(a)に示すような構成をとる。各種情報はatomという共通の構造に格納される。管理情報はMovie atomという構造に格納され、メディアデータはMovie data atomという構造に格納される。尚、Movie atom中の管理情報には、メディアデータ中の任意の時間に対応するメディアデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。
一方、管理情報とメディアデータを別々のファイルに格納した場合は、図2(b)に示すような構成をとる。管理情報はMovie atomという構造に格納されるが、メディアデータはatomには格納される必要はない。このとき、Movie atomはメディアデータを格納したファイルを「外部参照」している、という。
外部参照は、図2(c)に示すように、複数のAVストリームファイルに対して行うことが可能であり、この仕組みにより、AVストリーム自体を物理的に移動することなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」「非破壊編集」が可能になる。
それでは、図3乃至図12を用いて、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の構成を図3に示す。Movie header atomは、そのMovie atomが管理するムービーの全体的な属性を管理する。Track atomは、そのムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納する。User data atomは、独自に定義可能なatomである。
Track atomの構成を図4に示す。Track header atomは、そのトラックの全体的な属性を管理する。Edit atomは、メディアデータのどの区間を、ムービーのどのタイミングで再生するかを管理する。Track reference atomは、別のトラックとの関係を管理する。Media atomは、実際のビデオやオーディオといったデータを管理する。
Track header atomの構成を図5に示す。ここでは、後での説明に必要なもののみについて説明する。flagsは属性を示すフラグの集合である。代表的なものとして、Track enabledフラグがあり、このフラグが1であれば、そのトラックは再生され、0であれば再生されない。layerはそのトラックの空間的な優先度を表しており、画像を表示するトラックが複数あれば、layerの値が小さいトラックほど画像が前面に表示される。
Media atomの構成を図6に示す。Media header atomは、そのMedia atomの管理するメディアデータに関する全体的な属性等を管理する。Handler reference atomは、メディアデータをどのデコーダでデコードするかを示す情報を格納する。Media information atomは、ビデオやオーディオ等メディア固有の属性情報を管理する。
Media information atomの構成を図7に示す。Media information header atomは、ビデオやオーディオ等メディア固有の属性情報を管理する。Handler reference atomは、Media atomの項で説明した通りである。Data information atomは、そのQuickTimeムービーが参照するメディアデータを含むファイルの名前を管理するatomであるData reference atomを含む。Sample table atomは、データのサイズや再生時間等を管理している。
次に、Sample table atomについて説明するが、その前に、QuickTimeにおけるデータの管理方法について、図8を用いて説明する。QuickTimeでは、データの最小単位(例えばビデオフレーム)をサンプルと呼ぶ。個々のトラック毎に、サンプルには再生時間順に1から番号(サンプル番号)がついている。
また、QuickTimeフォーマットでは、個々のサンプルの再生時間長およびデータサイズを管理している。また、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンクと呼ぶ。チャンクにも再生時間順に、1から番号がついている。
さらに、QuickTimeフォーマットでは、個々のチャンクのファイル先頭からのアドレスおよび個々のチャンクが含むサンプル数を管理している。これらの情報に基づき、任意の時間に対応するサンプルの位置を求めることが可能となっている。
Sample table atomの構成を図9に示す。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は、図10に示すように、1個のEdit list atomを含む。Edit list atomはNumber of entriesで指定される個数分の、Track duration、Media time、Media rateの値の組(エントリ)を持つ。各エントリは、トラック上で連続的に再生される区間に対応し、そのトラック上での再生時間順に並んでいる。
Track durationはそのエントリが管理する区間のトラック上での再生時間、Media timeはそのエントリが管理する区間の先頭に対応するメディアデータ上での位置、Media rateはそのエントリが管理する区間の再生スピードを表す。尚、Media timeが−1の場合は、そのエントリのTrack duration分、そのトラックでのサンプルの再生を停止する。この区間のことをempty editと呼ぶ。
図11(a)〜(c)にEdit listの使用例を示す。ここでは、Edit list atomの内容が図11(a)に示す内容であり、さらにサンプルの構成が図11(b)であったとする。尚、ここではi番目のエントリのTrack durationをD(i)、Media timeをT(i)、Media rateをR(i)とする。このとき、実際のサンプルの再生は、図11(c)に示す順に行われる。このことについて簡単に説明する。
まず、エントリ#1はTrack durationが13000、Media timeが20000、Media rateが1であるため、そのトラックの先頭から13000の区間はサンプル中の時刻20000から33000の区間を再生する。次に、エントリ#2はTrack durationが5000、Media timeが−1であるため、トラック中の時刻13000から18000の区間、何も再生を行わない。
最後に、エントリ#3はTrack durationが10000、Media timeが0、Media rateが1であるため、トラック中の時刻18000から28000の区間において、サンプル中の時刻0から10000の区間を再生する。
図12にUser data atomの構成を示す。このatomには、QuickTimeフォーマットで定義されてない独自の情報を任意個数格納することができる。1個の独自情報は1個のエントリで管理され、1個のエントリはSizeとTypeとUser dataで構成される。Sizeはそのエントリ自体のサイズを表し、Typeは独自情報をそれぞれ区別するための識別情報、User dataは実際のデータを表す。
次に、録画中の電源遮断等に対応するために導入された概念であるFragmented Movieについて説明する。Fragmented movieは、QuickTimeフォーマットの1アプリケーションであるMotion JPEG2000で導入された概念であり、上述のSample table atomに相当する情報を、部分的なAVストリーム毎に管理することが可能となっている。Motion JPEG2000では、atomの代わりにboxという用語を用いているが、ここでは統一のためにatomに置き換えて説明する。
Fragmented movieを導入したQuickTimeファイルの全体構成を図13に示す。先頭に、そのファイル全体に共通する情報を管理するMovie atomが配置され、その後に、部分AVストリームデータを格納するMovie data atomと、その部分AVストリームデータを構成するサンプルのアドレスやサイズ、再生時間等を管理するMovie fragment atomとが交互に配置される。尚、AVストリームデータは、通常のQuickTimeファイルと同様、別ファイルに存在しても構わない。
録画時にはこの順番で記録を行なっていくことにより、録画時の電源切断による被害を最小限に防ぐことが可能となっている。Movie atomには、そのQuickTimeムービーがFragmented movieであることを示すためのMovie extends atomが含まれる。Movie extends atomには、そのムービーに含まれる各トラックに関するデフォルト値が格納される。
また、Movie fragment atomには、そのMovie fragment atomが管理する部分AVストリームに関する管理情報が含まれている。管理情報には、その管理する部分AVストリーム全体に関する情報を格納するMovie fragment header atomと、部分AVストリーム中の各トラックに関する情報を格納するTrack fragment atomとがある。
Track fragment atomは、それが管理するトラックに属する部分AVストリームに関する情報を格納するTrack fragment header atomと、そのトラックに属する部分AVストリームを構成する論理的な連続領域(Track runと呼ばれる)をそれぞれ管理するTrack fragment run atomとを含む。以下に、各atomについて詳しく説明する。
Movie extends atomの構成を図14に示す。Movie extends atomは、前述のように、このatomを含むQuickTimeムービーがFragmented movieであることを示す役割を持つ。
Track extends atomの構成を図15に示す。Track extends atomは、このQuickTimeムービーに含まれる各トラックのサンプルのデフォルト値を設定するために存在する。track IDはMovie atom中で定義されているトラックのtrack IDを参照する。default−sample−で始まるフィールドは、このatomで管理されるtrack fragmentのデフォルト値を設定する。
Movie fragment atomの構成を図16に示す。録画中に逐次記録される管理情報はこのatomである。このatomは、前述のとおり、このatomの管理するMovie fragmentに関する実際の情報を格納するatomであるMovie fragment header atomやTrack fragment atomを含む。
Movie fragment header atomの構成を図17に示す。このatomに格納されている主な情報はsequence−numberである。sequence−numberは、このatomが含まれるMovie fragment atomが管理するMovie fragmentの先頭からの順番を表す。
Track fragment atomの構成を図18に示す。Track fragment atomは、Movie fragmentに含まれる特定のトラックのサンプルに関する管理情報であるTrack fragment header atomやTrack fragment run atomを格納する。
Track fragment header atomの構成を図19に示す。このatomは、Movie fragmentに含まれる特定のトラックのサンプルに関するデフォルト値等を格納する。track−IDは、Movie atom中で定義されているトラックのtrack IDとの対応を示す。sample−description−indexは、このatomが管理するサンプルの参照するsample description tableのインデックス番号、default−sampleで始まるフィールドは、それぞれこのatomが管理するサンプルのデフォルト値である。
Track fragment run atomの構成を図20に示す。このatomは、Track runと呼ばれる、このatomの管理する連続領域や個々のサンプルの管理情報を格納する。sample−countはTrack runに含まれるサンプルの個数を示す。data−offsetはbase−data−offsetからのTrack runのオフセット値を示す。sample−で始まるフィールドはこのatomが管理するサンプルの再生時間等の値を格納する。ただし、上述のデフォルト値と同じであれば、省略してデータサイズを縮小することが可能となっている。
<AVストリームの形態>
本発明において共通に用いられるAVストリームの構成について、図21及び図22を用いて説明する。AVストリームは整数個のContinuous Unit(CU)で構成される。CUはディスク上で連続的に記録する単位である。CUの長さは、AVストリームを構成するCUをどのようにディスク上に配置してもシームレス再生(再生中に画像や音声が途切れないで再生できること)やリアルタイムアフレコ(アフレコ対象のビデオをシームレス再生しながらオーディオを記録すること)が保証されるように設定される。この設定方法については後述する。
CUは、整数個のVideo Unit(VU)で構成される。VUは単独再生可能な単位であり、そのことから再生の際のエントリ・ポイントとなり得る。
VU構成を図22に示す。VUは、1秒程度のビデオデータを格納した整数個のGOP(グループ・オブ・ピクチャ)と、それらと同じ時間に再生されるメインオーディオデータを格納した整数個のAAU(オーディオ・アクセス・ユニット)とから構成される。
尚、GOPは、MPEG−2ビデオ規格における画像圧縮の単位であり、複数のビデオフレーム(典型的には15フレーム程度)で構成される。AAUはMPEG−1 Layer−II規格における音声圧縮の単位で、1152点の音波形サンプル点により構成される。サンプリング周波数が48kHzの場合、AAUあたりの再生時間は0.024秒となる。VU中では、AV同期再生のために必要となる遅延を小さくするため、AAU、GOPの順に配置する。
また、VU単位で独立再生を可能とするために、VU中のビデオデータの先頭にはSequence Header(SH)を置く。VUの再生時間は、VUに含まれるビデオフレーム数にビデオフレーム周期をかけたものと定義する。
<AVストリーム管理方法>
AVストリームの管理方法は、前述のQuickTimeファイルフォーマットをベースにしている。図23にAVストリーム管理形態を示す。ビデオトラックは、1ビデオフレームを1サンプル、VU中のビデオの塊を1チャンクとして管理する。メインオーディオトラックは、AAUを1サンプル、VU中のオーディオの塊を1チャンクとして管理する。
<CU単位決定方法>
次に、CU単位決定方法について説明する。この決定方法では、基準となるデバイス(リファレンス・デバイス・モデル)を想定し、その上でシームレス再生が破綻しないように連続記録単位を決める。
それではまず、リファレンス・デバイス・モデルについて、図24を用いて説明する。リファレンス・デバイス・モデルは1個のピックアップとそれにつながるECCエンコーダ・デコーダ501、トラックバッファ502、デマルチプレクサ503、アフレコ用バッファ504、オーディオエンコーダ509、ビデオバッファ505、オーディオバッファ506、ビデオデコーダ507、オーディオデコーダ508とによって構成される。
本モデルにおけるシームレス再生は、VUのデコード開始時にトラックバッファ502上に少なくとも1個VUが存在すれば保証されるものとする。オーディオフレームデータのECCエンコーダ501へのデータの入力速度およびECCデコーダ501からデータの出力速度はRsとする。
また、アクセスによる読み出し、記録の停止する最大期間をTaとする。さらに、短いアクセス(100トラック程度)に要する時間をTkとする。なお、これら期間には、シーク時間、回転待ち時間、アクセス後に最初にディスクから読み出したデータがECCから出力されるまでの時間が含まれる。本実施形態では、Rs=20Mbps、Ta=1秒、Tk=0.2秒とする。
前記リファレンス・デバイス・モデルにおいて再生を行った場合、次のような条件を満たせば、トラックバッファ502のアンダーフローがないことが保証できる。
条件を示す前にまず、記号の定義を行う。AVストリームを構成するi番目の連続領域をC#iとし、C#i中に含まれる再生時間をTc(i)とする。Tc(i)はC#i中に先頭が含まれているVUの再生時間の合計とする。また、C#iからC#i+1へのアクセス時間をTaとする。
また、再生時間Tc(i)分のVU読み出し時間をTr(i)とする。このとき、トラックバッファ502をアンダーフローさせない条件とは、分断ジャンプを含めた最大読み出し時間をTr(i)としたとき、任意のC#iにおいて、
Tc(i)≧Tr(i)+Ta・・・<式1>
が成立することである。
なぜなら、この式は、シームレス再生の十分条件である、
Figure 0003847751
を満たす十分条件であるためである。
<式1>中のTr(i)に、Tr(i)=Tc(i)×(Rv+Ra)/Rsを代入して、Tc(i)で解くとシームレス再生を保証可能なTc(i)の条件
Tc(i)≧(Ta×Rs)/(Rs−Rv−Ra)・・・<式2>
が得られる。
つまり、各連続領域に先頭の含まれるVUの合計が上式を満たすようにすれば、シームレス再生を保証可能である。このとき、各連続領域には合計の再生時間が上式を満たす完全なVU群を含むように制限しても良い。
自動分割ムービーファイルでも<式2>を満たす必要がある。ただし、先頭の自動分割ムービーの最初のCUおよび末尾の自動分割ムービーの最後のCUは<式2>を満たさなくてもよい。なぜなら、先頭については記録媒体からのデータ読み出し開始より再生開始を遅らせることにより吸収でき、末尾については次に続くデータがないため連続再生を気にする必要が無いからである。このように先頭と末尾において条件を緩めることにより、短い空き領域を有効利用できる。
<ファイルシステム>
本発明の説明において用いるファイルシステムのフォーマットである、UDF(Universal Disk Format)について図25(a)(b)と図26を用いて説明する。図25(a)に示すディレクトリ/ファイル構成をUDFで記録した例を図25(b)に示す。図中のAVDP602はAnchor Volume Descriptor Pointerの略であり、UDFの管理情報を探すためのエントリポイントに相当し、通常256セクタ目、Nセクタ目あるいはN−256セクタ目(Nは最大論理セクタ番号)に記録する。VDS601はVolume Descriptor Sequenceの略であり、UDFが管理する領域であるボリュームに関する管理情報を記録する。ボリュームは一般に一枚のディスクに1個存在し、その中にパーティションを一般に1個含む。FSD603はFile Set Descriptorの略であり、パーティションに1個存在する。パーティションの中での位置情報はパーティションの先頭からのセクタ番号に相当する論理ブロック番号で示される。なお、1個の論理ブロックは1セクタに対応する。
FSD603は、ルートディレクトリのFile Entry(FE)であるFE604の位置情報(論理ブロック番号と論理ブロック数で構成されextentと呼ばれる)を含む。FEは、extentの集合を管理しており、extentを書き換えたり、追加したり、削除することで、ファイルを構成する実データの順番を変えたり、データを挿入したり削除したりすることが可能である。FE604はルートディレクトリの直下のファイルやディレクトリの名称等を格納するFile Identifier Descriptor(FID)の集合を格納する領域605を管理する。領域605中のFID611、FID612は、それぞれファイル621、ファイル622のファイル名やextentの集合を管理するFE606、FE608の位置情報を含む。FE606はファイル621の実データを構成する領域である領域607、領域610をextentとして管理する。このときファイル621の実データにアクセスするためには、AVDP602、VDS601、FSD603、FE604、FID611、FE606、領域607、領域610の順にリンクを辿っていけばよい。
次に追記型ディスクに対応したUDFについて図26を用いて説明する。図25(b)と比べ、VAT(Virtual Allocation Table)613および前回追記終了領域614が加わっている点が異なる。VATは、FEを指すアドレスの変換テーブルであり、このテーブルを用いることで書き換えのできない追記型ディスクにおいて見た目上、書き換えを実現する。前回追記終了領域614は、前回の追記がどこで終わったかを示すための領域であり、DVD−RではBorder outと呼ばれている。DVD−RではBorder outの直前にVATを記録し、再生時はまずBorder outを検出し、その直前のVATを読み出すことで、FEを指すアドレスの変換テーブルをメモリ上に構築し、変換テーブルを経由してディスク上の実際のFEにアクセスすることになる。したがって、ファイルを見た目上書き換えるようとした場合、更新分のデータを追記し、そのデータのextentを書き換え対象のファイルのFEに追加したものをディスクに追記し、そのファイルのFEを新しいFEに読みかえるようなマッピングをVATに登録すればよい。ファイルの追加や削除についても同様に、FIDの集合のextentを管理するFEを追記し、従来のFEと置き換えるようなマッピングをVATに登録すればよい。
〔第1の実施形態〕
本発明の第1の実施形態について、図27乃至図41を用いて説明する。
<管理情報フォーマット>
前述のように、ディスク内に含まれるQuickTimeムービーや静止画データ等を含む各種ファイル(以後、AVファイルと呼ぶ)を管理するため、AV Indexファイル1740という特別のQuickTimeムービーファイルをディスク内に置く。図27に、本実施形態におけるAV Indexファイル1740の構成を示す。AV Indexファイル1740は通常のQuickTimeムービーファイルと同様、管理情報であるMovie atom1791とデータ自体のMovie data atom1792で構成される。
なお、AVファイルが請求の範囲における「本体データ」に相当し、AV Indexファイルが請求の範囲における「見出しデータ」に相当する。
AV Indexファイル1740は、複数のエントリを管理し、ディスク内の各AVファイルはそれぞれ1個のエントリで管理される。
Movie atom1791は、各エントリの属性情報(属性データ)を管理するためのProperty track1793、各エントリのタイトル文字列データを管理するためのTitle track1794、各エントリの代表画像データを管理するためのThumbnail track1795、各エントリの代表オーディオデータを管理するためのIntro music track1796の計4種類のトラックで構成される。
各エントリに関する属性情報やタイトル文字列データ、代表画像データ、代表オーディオデータはそれぞれ1793〜1796のトラックのサンプルとして管理される。例えばAVファイル1741に関する属性情報はProperty track1793上のサンプル1701、タイトル文字列データはTitle track1794上のサンプル1711、代表画像データはThumbnail track1795上のサンプル1721、代表オーディオデータはIntro music track1796上のサンプル1731で管理する。サンプル間の対応付けは、各サンプルの再生開始時間に基づき行う。すなわち、トラック間で同一時刻に位置するサンプルが同一エントリに対応していると判断する。
Movie data atom1792は、各AVファイルに関する属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータを格納する。
なお、属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータが、それぞれ請求の範囲における「見出し情報」に相当する。
属性情報は図28に示す構成を取る。各フィールドについて説明する。versionは、ファイルフォーマットのバージョンを示す。flagsは各種フラグをまとめたものである。entry−numberは、属性情報に対応するエントリのIDを格納する。
creation−timeおよびmodification−timeはこの属性情報に対応するエントリが作成された日時、修正された日時を表す。durationはこの属性情報に対応するエントリの再生時間を表す。file−identifierは、この管理情報に対応するエントリがファイルに対応していた場合、そのファイルのファイル名を格納する。
上記flagsについて図29を用いて説明する。Status of Entryは、対応するエントリが有効(available)か無効(invalid)かを識別するためのフラグである。
Movie data atom1792に格納されるその他のデータについて説明する。代表画像データには160×120画素に縮小されたJPEG圧縮されたデータ、タイトル文字列データにはテキストデータ、代表オーディオデータにはMPEG−1 Audio Layer−IIで圧縮されたデータをそれぞれ用いる。
<全体の流れ>
本実施形態における、ディスク挿入から、ディスクイジェクトあるいは電源OFFまでの流れを、図30に示す。
光ディスク106が挿入されたら、前述のシーケンスに沿って、まずファイルシステムの管理情報を読みこむ(ステップ2000)。次にAV Indexファイルを光ディスク106から読み込み、インデックス画面の表示を行う(ステップ2001)。次に、AV Indexファイルをディスクに記録するタイミングかどうかチェックする。記録するタイミングとは、ディスクイジェクト指示や電源OFFあるいは、RAM102に新規の情報を光ディスク106から読み出すために、AV Indexファイルに関する情報をRAM102上の光ディスク106に一旦記録する必要になったタイミングである。記録するタイミングであればステップ2003からステップ2004までのAV Index記録処理を行う。一方、そうでなかった場合、まず、ユーザからの指示が無いかチェックする(ステップ2008)。もし指示があれば、指示に沿って各種処理(図31参照)を実行し、上記の処理が終了したら、それらを反映してインデックス画面表示更新処理を実行する(ステップ2019)。
次に、ステップ2003からステップ2007で示される処理について説明する。まず、RAM102上の情報からAV Indexファイルの記録を行い(ステップ2003)、ファイル・ディレクトリ情報記録を行う(ステップ2004)。次に、AV Index記録を行うトリガーとなったのが、電源OFFあるいはディスクイジェクトがどうかをチェックし(ステップ2005)、電源OFFあるいはディスクイジェクトであれば、VATを記録し(ステップ2006)、追記終了位置を示すための領域であるBorder outを記録する(ステップ2007)。この光ディスク106を再生する場合、最初にVATを読み出す必要があるが、その位置を探すための情報がBorder outである。従って再生機器は、ファイルの読み出し前に必ず、ピックアップを光ディスクの半径方向に移動させ、最後のBorder outを探し、その直前のVATを読み出す。本実施形態のように、最新のAV Indexファイルの内容を記録する領域をVATやBorder outの近傍に置くことによって、AV Indexファイルを読み出すまでのシーク時間を短縮することができる。このことにより、代表画像やタイトル等を高速にユーザに示すことが可能になり、ユーザへのレスポンスの向上に繋がる。
次に、ステップ2009における各種処理について図31を用いて説明する。まず、指示が録画かどうかをチェックし(ステップ2010)、録画であれば後述する録画処理を行う(ステップ2011)。指示が録画でなければ、エントリ削除、すなわち既存のAVファイルの削除かどうかをチェックし(ステップ2012)、エントリ削除なら後述するエントリ削除処理(ステップ2013)を実行する。指示が録画でもエントリ削除でもなければ次に、既存のエントリに関する代表画像データやタイトル文字列データ、代表オーディオデータ、属性情報のいずれかの変更かどうかをチェックし(ステップ2014)、そうであれば後述するサムネイル等変更処理(ステップ2015)を実行する。指示されたのがサムネイル等変更処理でなければ、その他処理(ステップ2016)を実行する。
以下各処理について詳細を説明する。ここでは、処理を開始する前の初期状態として、光ディスク106に図32(a)に示すディレクトリ構成でファイルが記録され、それぞれが光ディスク106上に図32(b)に示すように配置されていると仮定する。すなわち、AVファイルであるSHRP0001.MOV、SHRP0002.MOVおよびSHRP0003.MOVは、それぞれ、AV file2201、AV file2202およびAV file2203の位置に記録される。またAV IndexファイルであるAVIF0000.MOVは、図32(b)中のAV Index file2204の領域に記録され、AV Index file2204の領域の先頭にはAV Index fileのMovie atomが領域2211に記録される。また、SHRP0001.MOVの属性情報、タイトル文字列データおよび代表画像データが、領域2212、領域2215、領域2218に記録され、SHRP0002.MOVの属性情報、タイトル文字列データおよび代表画像データが、領域2213、領域2216、領域2219に記録され、SHRP0003.MOVの属性情報、タイトル文字列データおよび代表画像データが、領域2214、領域2217、領域2220に記録されているとする。後述するインデックス画面表示処理を行った結果、RAM102には、AV Indexファイルに関する情報を管理するための図33に示すテーブルが構成される。ここでは、このテーブルをAV Index管理テーブルと呼ぶ。このテーブルの各行は、ディスク挿入時に読み出したAV Indexの状態およびその後の各エントリの更新を管理する。各行には、属性に関する情報や各エントリが管理するAVファイルの名称、代表画像データが記録してあった位置(AV Indexファイルの名称およびアドレス情報)、RAM102の別領域に保持している代表画像データへのポインタ情報を持つ。なお、代表オーディオデータおよびタイトル文字列データに関しては説明を簡単にするため図示していないが、それぞれ、代表画像データおよび属性情報と同様の扱いを行う。また、各ファイルの名称は実際にはルートディレクトリからのフルパスで管理しているが、ここでは簡単のため、ディレクトリ名は省略している。
<録画時の処理>
本実施形態における録画時の処理を図34(a)(b)を用いて説明する。ユーザから録画が指示されたら、まずオーディオエンコーダ117およびビデオエンコーダ118を起動し、図示されないカメラおよびマイクからの入力データを前述の符号化方式でエンコードを開始する。エンコードされたオーディオデータとビデオデータはマルチプレクサ113によって、前述のAVストリームフォーマットに従って多重化される。その際に、後ほどMovie atomを記録するのに必要となる、GOPのサイズや再生時間などをRAM102に蓄積していく。また、入力ビデオから先頭画像を代表画像として抜き出し縮小したものを、JPEG符号化でエンコードし、代表画像データを作成し、RAM102に保持する。多重化結果であるAVストリームは、記録/アフレコ用バッファ111およびECCエンコーダ109を経由して、ピックアップ107によって光ディスク106に記録される。AVストリームの光ディスク106への記録は、図34(a)の2100の位置に左から右に行われる。
ユーザから録画停止が指示され、記録/アフレコ用バッファ111に残ったAVストリームを光ディスク106へ記録し終わったら、記録したAVストリームのバイト数をRAM102に記憶し、次にMovie atomの記録を行う。記録は、図34(a)に示すようにセクタ境界2112から開始する。Movie atomの記録が終了したら、次のセクタ境界2113の直前にMovie data atomのatom headerの後端が位置するよう、適切なサイズのSkip atomを領域2102に挿入する。なお、Skip atomとは、QuickTimeファイルフォーマットにおいて主にパディング用途に使われるatomである。次に、Movie data atomのatom headerを領域2103に記録する。atom headerにはRAM102に記憶しておいたAVストリームのバイト数とMovie data atomのatom headerのバイト数を足し合わせた値を記録し、Movie data atomを意味する″mdat″を記録する。最後に、FEを2104の位置に記録する。FEには、このAVファイルを先頭から読み出した場合、図34(b)の順になるように情報を記録しておく。
このような記録形態を採る理由を以下に説明する。QuickTimeファイルフォーマットにおいて、Movie data atom中のsizeとMovie atomの内容は、録画が終了しない限り決定しない性質の情報である。通常、AVストリームのサイズは、記録/アフレコ用バッファ111より大きいため、Movie atom記録の前にAVストリームを記録する必要がある。このとき、書き換え可能型ディスクにおいては、前方(図34(a)におけるAV stream2100の左)に戻って、Movie atomを記録することが可能であるが、追記型ディスクの場合、後方(図34(a)におけるAV stream2100の右)にしかできない。したがって、光ディスク上での記録は、図34(a)の順に記録し、ファイルとしての読み出し順が図34(b)となるよう、ファイルシステムの管理情報であるFEを記録する。このとき、FEの情報により、複数の連続領域間を順次に読み出す場合は、最後の領域を除きそれぞれの領域のサイズはセクタ(記録ユニット)の整数倍となっている必要がある。そのため、Skip atom2102を挿入し、Movie atom2101、Movie data atomのatom header2103を記録した領域のサイズがセクタの整数倍となるよう調節している。Skip atomは最上位のatom(例えばMovie atomやMovie data atom)の境界ならどこにでも挿入可能であるため、Movie atom2101とMovie data atom2103の間以外にも例えば、Movie atomの直前でも構わない。また、本実施形態では、Movie atomとAVストリームを同一ファイルに格納したが、図2(b)に示すように別ファイルに記録してもよいことは言うまでもない。この場合、AVストリームファイル、Movie atomのみのファイルの順に記録することになる。
録画が終了した時点で、RAM102上のAV Index管理テーブルには、図35の行番号3で示す行を追加する。以下、その行の内容について説明する。属性情報において、entry−numberは既存の番号と重複しない番号を格納する。AVファイル名称に関しても、AV Index管理テーブルにおける既存のAVファイル名称の5桁目から8桁目までの数字部分がファイルシステム的に重複しないファイル名称を生成して格納する。また、代表画像データ記録位置に関しては、光ディスク106上には未記録であるため、未記録を示すNULLを格納する。また、代表画像データポインタに関しては、記録時に生成した前述の代表画像データのRAM102上でのアドレスを格納する。
<エントリ削除処理>
本実施形態におけるエントリ削除時の処理を説明する。ここでは、削除直前のAV Index管理テーブルの状態が図35に示す状態であったと仮定する。ユーザから、エントリの削除を指示された場合、RAM102上のAV Index管理テーブルに、図36の行番号4で示す行を追加する。すなわち、削除するエントリのentry−numberと同一のentry−numberを持ち、status of entryがinvalidの行を追加する。
<エントリデータ変更時の処理>
本実施形態におけるエントリデータ変更時の処理を説明する。ここでは、エントリデータ変更直前のAV Index管理テーブルの状態が図36に示す状態であったと仮定する。ユーザから、代表画像の変更を指示された場合、まず、変更後の画像を取得し、RAM102上にJPEG符号化データで格納する。次に、RAM102上のAV Index管理テーブルに、図37の行番号5で示す行を追加する。すなわち、代表画像を変更するエントリとentry−numberと同一のentry−numberを持ち、代表画像データポインタに前述のJPEG符号化データが格納されたRAM102上の先頭アドレスを持つ行を追加する。このとき、変更するのが代表画像データだけであることを示すため、他の項目には、無変更を意味するNO CHANGEを格納する。また、録画時と同様、光ディスク106上に未記録であるため、代表画像データ記録位置にはNULLを格納する。なお、ここでは、代表画像を変更する場合について説明したが代表オーディオやタイトル、その他属性情報等エントリデータの変更に関しても同様の処理を行う。
<AV Index記録処理>
本実施形態におけるAV Indexファイル記録処理を図38に沿って説明する。まず、AV Index管理テーブル上で、entry−numberが重複する行の統合を行う(ステップ2401、2402)。具体的にはentry−numberが重複する行があった場合、行番号の小さい行を行番号の大きい行の内容で上書きし、大きい行を削除する。上書きの際、変更無しを意味するNO CHANGEが格納されている項目については、行番号の小さい行の上書きを行わない。次に、削除済みのエントリを除外処理する。具体的にはstatus of entryがinvalidとなっている、entry−numberを持つ行をAV Index管理テーブルから削除する(ステップ2403)。
次に新規記録AV IndexファイルのSample tableの構築をRAM102上で行う(ステップ2404)。具体的には、属性情報やタイトル文字列データのようにデータ量の小さく、しかもユーザや機器にとって重要度の高い即座にアクセスしたいデータは、新規記録AV Indexファイルに記録し、代表画像データや代表オーディオデータのように、重要度の低い情報(例えば、文字列1行分の表示手段しか持たない機器では、代表画像は意味を持たない)は新規に追加されたデータを除き、既存のAV Indexファイルを参照するようにSample tableを構築する。
新規記録AV Indexファイルに記録するか、既存のAV Indexファイルを参照するようにするかは、属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータの各データの属性に基づいて定められる。このデータの属性としては、上記のようにデータ量が考えられるが、これ以外にも、そのデータの階層情報や、そのデータの優先度、そのデータに対応するAVファイルを再生した時刻なども考えられる。このようなデータの属性を、光ディスク106に記録しておいてもよい。
以上の処理は、請求の範囲における「見出しデータ作成手段」としてのホストCPU101およびRAM102により実行される。
このようにすることで、記録容量の無駄を削減しつつ、重要度の高い情報へのアクセス性能の低下を防ぐことが可能になる。次に、新規記録AV IndexファイルのMovie atomを記録し(ステップ2405)、AV Index管理テーブル中の全エントリの属性情報およびタイトル文字列を記録し(ステップ2406)、最後に新規に追加された、代表画像データおよび代表オーディオデータを記録する。新規に追加されたかどうかは、AV Index管理テーブル中の代表画像データ記録位置がNULLであるか否かで判断できる。
なお、新規記録AV Indexファイルの名称は光ディスク106上の既存のAV Indexファイルの名称の5桁目から8桁目までの数字を取り出した値の最大値に1を加えたものにする。例えば既存のAV Indexファイルの名称がAVIF0000.MOV〜AVIF0100.MOVであった場合、SHRP0101.MOVとする。このことにより、最新のAV Indexファイルを名称から判断することが可能になると同時に、最新以外のAV Indexファイルを参照することで、光ディスク106における、過去のスナップショット(状態)を容易に再現することが可能になる。
このように、AV Indexファイルの名称を、AV Indexファイル間の関連情報として光ディスク106に記録しておくことで、その光ディスク106における記録内容の変更履歴に容易にアクセスすることができるようになる。また、AV Indexファイルの名称の一部を通し番号とすることで、履歴の順番を容易に把握することができる。
以上の処理を行った直後の光ディスク106の記録状態を具体的に説明する。ここでは、AV Indexファイル記録処理開始直前に、RAM102上には図37の内容を持つAV Index管理テーブルが存在すると仮定する。AV Indexファイル記録処理を行った結果、光ディスク106上には図39に示すように、新規AV Index file2242が作成される。その中には、代表画像データを変更したSHRP0002.MOV2202に関する属性情報、タイトル文字列データおよび代表画像データが、領域2232、領域2235、領域2238に記録され、変更のないSHRP0003.MOV2203に関する属性情報、タイトル文字列データが領域2233および領域2236に記録され、新規に登録されたSHRP0004.MOV2241に関する属性情報、タイトル文字列データおよび代表画像データが、領域2234、領域2237、領域2239に記録される。SHRP0003.MOV2203の代表画像データについては、既存のAV Index file中の領域2220を参照するため、新たに記録は行わない。
なお、AV Index file2204が請求の範囲における「旧い見出しデータ」あるいは「第1のデータ」に相当し、AV Index file2242が請求の範囲における「新たな見出しデータ(新しい見出しデータ)」あるいは「第2のデータ」に相当する。
したがって、第1のデータは既記録データであり、第2のデータは新規記録データであることになる。そして、第1のデータと第2のデータとは、記録時期が異なり、記録媒体上でも離れて記録される。再生時には、第1のデータを、第2のデータより先に読み出すことになる。また、第2のデータは、第1のデータの追加データである、ともいえる。
また、Movie atom2231が請求の範囲における「第3のデータ」に相当し、AV Index file2204に含まれる属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータ(図32参照)等のエントリデータが、それぞれ請求の範囲における「第4のデータ」に相当する。
また、請求の範囲における「参照情報」あるいは「第4のデータに関する情報」は、管理情報であるMovie atom2231に含まれるサンプル(図27参照)の何れかに相当する。
また、AVファイルが請求の範囲における「第5のデータ」に相当する。したがって、属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータ等の第4のデータは、第5のデータに関する情報を有するデータであるといえる。
<インデックスファイル画面表示処理>
本実施形態におけるインデックスファイル画面表示処理を図40に沿って説明する。まず、最新のAV Indexファイルをopenし(ステップ2300)、Movie atomを読み込み、前述のAV Index管理テーブルをRAM102上に作成する。ただし、この時点では、代表画像データ等各種データの位置情報のみを取得したのみであり、まだ各種データのRAM102上への読み込みは行っていない(ステップ2301)。なお、どのAV Indexファイルが最新かどうかは、前述したように、ファイル名を用いて判断することが可能である。次に、各エントリのタイトル文字列データおよび属性情報を読み出し、AV Index管理テーブルに格納する(ステップ2302)。次に、代表画像データや代表オーディオデータの読出しのスケジューリングを行う(ステップ2303)。すなわち、ユーザに指定された現状のインデックス表示順および、各データの含まれるAV Indexファイルのファイル名を総合し、最も表示までの時間が短くなるようにファイルをopenする順番を決定する。具体的には、インデックス画面の表示順を基本とし、ファイルopenの回数が少なくなるようにする。次に、現在open中のAV Indexファイルから代表画像データおよび代表オーディオデータの読出しを行う(ステップ2304〜2305)。有効なデータを読み終わったら、ファイルをcloseし(ステップ2306)、ステップ2303で決定された、次にopenするAV Indexファイルの名称を取得し(ステップ2308)、最後のファイルまで読み終わっていなければそのファイルをopenし(ステップ2309)、ステップ2304以降を実行する。
前述のように、ステップ2301において、最新以外のAV Indexファイルを参照することで、光ディスク106における過去のスナップショット(状態)を容易に再現することが可能になる。
<バリエーション>
本実施形態では、削除済みのエントリや変更前のエントリデータについて、最新のAV Indexファイルでは管理していないが、管理するようにしてもよい。具体的には、既存エントリの削除や既存エントリデータの変更という属性を持ったエントリを定義し、追加するようにしていくことが考えられる。あるいは、Sample tableにサンプル毎の有効/無効を管理するテーブルを追加して記録してもよい。
また、本実施形態では、既存のデータを参照するのに、QuickTimeファイルフォーマットの外部参照機能を用いているが、ファイルシステムの機能を用いても同様の機能は実現可能である。例えば、本実施形態で外部参照しているデータを含むセクタを、最新AV Indexファイルのextentにして、Movie atomから参照すれば、QuickTimeファイルフォーマットの外部参照機能を用いることなく同様の機能が実現できる。図39を例にとると、最新AV Indexファイルを領域2231〜2239を含む連続セクタと領域2220を含む連続セクタの2個のextentで構成することになる。これにより、AV Indexファイル2204とAV Indexファイル2242とを同一のファイルとして管理することになる。このとき、Movie atomは、上記同一ファイル内での領域2220の位置情報を含むことになる。また、最新AV Indexファイルのファイル名を直前の最新AV Indexファイルのファイル名と同一にすることで、AV Indexファイルのファイル数を増加させることなく、既存データの再利用が可能となる。
さらに、代表画像データ等、エントリデータを記録する際に、その先頭位置がセクタの境界に合うように記録しておけば、エントリデータの先頭がextentの先頭となるため、上記処理が単純化され、しかもAV Indexファイルに余計なデータが含まれる度合いが減少する。
また、本実施形態では、代表画像データ等のエントリデータをAV Indexファイルに格納しているが、エントリデータだけをまとめて、あるいはエントリデータの種別毎に1個のファイルとして管理してもよい。また、AVファイル内に記録して、AV Indexファイルから参照するようにしてもよい。このようにすることで、AV Indexファイルの更新処理において、エントリデータは常に共通のデータファイルを参照すればよいため、エントリデータの参照先を変更する処理が不要となる。
また、本実施形態では、最新AV Indexファイルには、既存AV Indexファイルに含まれる代表画像データあるいは代表オーディオデータを記録せず、参照するようにしているが、既存AV Indexファイルに含まれている代表画像データあるいは代表オーディオデータであったとしても、特定のデータに関して光ディスク106からの読出しを高速にし、ユーザに対するレスポンスを向上させるため最新AV Indexファイルに記録してもよい。特定のデータとしては、例えば、記録してあるディレクトリ階層の浅いAVファイルに関する代表画像データが考えられる。また、最新AV Indexファイルを記録するタイミング(ディスクイジェクト時や電源OFF時)において、ユーザに示していたファイルに関する代表画像データや代表オーディオデータを最新AV Indexファイルに記録しておくことも当然考えられる。このことにより、ディスク挿入時や電源ON時に、前回の状態(例えば画面表示)をより短時間に再現することが可能になる。
代表画像データや代表オーディオデータを新規記録AV Indexファイルに記録するか、既存のAV Indexファイルを参照するようにするかは、これら代表画像データや代表オーディオデータの属性に基づいて定められるが、この属性としては、上記のように、そのデータの階層情報や、そのデータに対応するAVファイルを再生した時刻なども考えられる。
また、図41に示すように、属性情報に、表示や読出の優先度を格納するフィールドであるpriorityを用意し、優先度の高いものは、既存AV Indexファイルに含まれていても、最新AV Indexファイルに代表画像データあるいは代表オーディオデータを記録することで、ディスク挿入時のインデックス画面の表示を高速化し、ユーザに対するレスポンスを向上させることが考えられる。
〔第2の実施形態〕
本発明の第2の実施形態について、図42乃至図47を用いて説明する。第1の実施形態との違いは、第2の実施形態において最新AV Indexファイルには、既存のAV Indexファイル中のデータに関する管理情報を含まれておらず、管理情報の重複記録による無駄が少ない点にある。第1の実施形態と共通する部分が多いため、相違点に絞って説明を行う。
<管理情報フォーマット>
本実施形態におけるAV Indexファイルの構成は、Movie atomのUser data atomに図42に示すindex link atomが含まれている以外は第1の実施形態と共通である。index link atomは、複数のAV Indexファイルがディスク上に存在する場合の、ファイル間の前後関係を示す情報である。このatomには、フィールドpreviousとフィールドnextが存在するが、本発明ではフィールドpreviousのみ用いる。フィールドpreviousの使用方法については後述する。
<全体の流れ>
本実施形態における、ディスク挿入から、ディスクイジェクトあるいは電源OFFまでの流れは第1の実施形態と同様であり、説明を省略する。
<録画時の処理>
第1の実施形態と同様であり、説明を省略する。
<エントリ削除処理>
第1の実施形態と同様であり、説明を省略する。
<エントリデータ変更時の処理>
第1の実施形態と同様であり、説明を省略する。
<AV Index記録処理>
本実施形態におけるAV Indexファイル記録処理を図43に沿って説明する。まず、RAM102上のAV Index管理テーブルの統合処理を行う(ステップ3101〜3102)。具体的には、光ディスク106挿入後に追加された行について、NO CHANGEの項目があれば、その行より行番号の小さいエントリに実際のデータの位置が記録されていることがわかるため、同一のentry−numberを持つ行を探しその項目の内容で補う。内容の取得元が光ディスク106挿入後に追加された行であれば、その行を削除する。
次に、AV Index管理テーブルの情報に基づきSample tableの構築を行う(ステップ3103)。具体的には、まず、光ディスク106挿入後に追加された行について、各行を1エントリとして、各エントリ毎に、属性情報、代表画像データ、代表オーディオデータ、タイトル文字列データを管理するsampleを作成する。
次に、行の種別に応じてsampleに情報を格納する。エントリ削除を意味する行については、属性情報中のstatus of entryにinvalidをセットし、代表画像データ、代表オーディオデータ、タイトル文字列データを管理するsampleのsize情報を0にセットする。それ以外の行については、最新AV Indexファイルに最新の属性情報、代表データ、代表オーディオデータ、タイトル文字列データを記録するようにsampleを構成する。なお、status of entryにセットされたinvalidは、その行に対応するエントリを無効化する情報となる。このstatus of entryが、請求の範囲における「第3のデータ」に相当する。
次に、Movie atomを記録し(ステップ3104)、最後に、属性情報、代表データ、代表オーディオデータ、タイトル文字列データを記録する。なお、Movie atomのindex link atomのフィールドpreviousには直前の最新AV Indexファイルのファイル名を格納しておく。
なお、新規記録AV Indexファイルの名称は光ディスク106上の既存のAV Indexファイルの名称の5桁目から8桁目までの数字を取り出した値の最大値に1を加えたものにする。
以上の処理を行った直後の光ディスク106の記録状態を具体的に説明する。ここでは、AV Indexファイル記録処理開始直前に、RAM102上には図37の内容を持つAV Index管理テーブルが存在すると仮定する。AV Indexファイル記録処理を行った結果、光ディスク106上には図44に示すように、新規AV Index file2242が作成される。その中には、SHRP0002.MOVに関する属性情報、タイトル文字列データおよび代表画像データが、領域2252、領域2254および領域2256に記録され、SHRP0004.MOVに関する属性情報、タイトル文字列データおよび代表画像データが領域2253、領域2255および領域2257に記録される。
第1の実施形態においては、最新のAV IndexファイルのMovie atomは、光ディスク106に存在するすべてのエントリに関する情報を管理している。そのため、過去のAV IndexファイルのMovie atomと重複する情報が含まれており、その分、記憶容量の無駄が多い。それに対し、本実施形態では、最新のAV IndexファイルのMovie atomは、前回のAV Indexファイルからの差分(エントリの追加・削除、エントリデータの変更)しか管理していないため、第1の実施形態に比べ、管理情報の重複記録が少ないという利点がある。
<AV Indexマージ処理>
上記のAV Index記録を繰り返していった場合、図45(a)のように、光ディスク106上に複数のAV Indexファイルが分散して記録されることになる。光ディスクは、読み出し位置の移動に時間がかかるため、読み出し位置の変更回数が多いほど、結果として全体的な読み出し時間がかかることになる。したがって、AV Index記録を繰り返すほど、読み出しに時間がかかることになり、インデックス画面表示等のレスポンスに悪化を来す可能性が考えられる。これを解決する方法として、分散して記録された複数のAV Indexファイルの内容を近傍に集めて記録する、というものが考えられる。ここではその処理をマージ処理と呼ぶことにする。
マージ処理について例を用いて説明する。図45(b)はマージ処理を行った例であり、AV Index file3306にAV Index file3303およびAV Index file3304に含まれる属性情報や代表画像といったエントリデータをまとめて記録している。Movie atomには当然、それらのエントリデータを管理するためのSample tableを格納する。AV Index file3306のファイル名は、前述した通り、直前のAV IndexファイルであるAV Index file3304のファイル名に関して5〜8桁目の数字に1加算したものとする。このとき、Movie atomのUser data atom中のindex link atomのpreviousフィールドに、エントリデータのマージ元のAV Indexファイルの1個前のAV IndexファイルであるAV Index file3302のファイル名を格納する。このことによって、AV Indexファイルを最新のものから過去に遡って読み出していく際に、previousフィールドを参照することでマージ済みのデータを再度読み出してしまうことを防ぐことができる。また、マージ元のAV Indexファイルも残っているため、過去の状態を容易に再現できる機能も損なわれていない。なお、本実施形態ではマージ処理は、通常のAV Index記録処理と独立に行ったが、同時に行ってもよいことは言うまでもない。また、第1の実施形態と同様、エントリやエントリデータの属性に応じて、マージするエントリやエントリデータを選択してもよいことは言うまでもない。
このように、Movie atomのUser data atom中のindex link atomのpreviousフィールドに格納される情報は、ファイル間の読み出しを制御するための情報であり、この情報が、請求の範囲における「読み出し制御情報」に相当する。
<編集処理のやり直し処理>
前述のように、ディスクのイジェクトや電源OFFあるいは任意のタイミングでAV Indexファイルを記録するようにしているため、記録したAV Indexファイル単位で過去のスナップショット(状態)を容易に再現することが可能になる。
また、既存のAV Indexをディスクから読み出して、変更が反映されたAV Indexをディスクに書き出すまでの間に行われた編集操作等は、RAM上にAV Index管理テーブルがあるため、取り消すことが容易である。一方、AV Indexのファイル名の番号から、数字が小さいほど過去に作られたことがわかるため、AV Index単位で過去の状態に遡ることが容易である。AV Indexファイルに設定された日時情報よりいつ作成されたAV Indexファイルを特定することが可能である。
このとき、最新のAV Indexファイルの状態から、例えば3つ前のAV Indexファイルの状態に戻す事を考える。ここでの「戻す」とは、現在RAM上にあるAV Index管理テーブルの内容と過去2つのAV Indexファイルで管理される編集操作を全て破棄し、3つ前のAV Indexファイルの状態に復帰することを意味する。これは、index link atomのpreviousフィールドで管理されている前のAV Indexファイルを3回たどることによって可能である。index link atomによって把握した3つ前のAV Indexファイルの状態をディスクから読み出し、その状態に対して編集操作等を続行する。実際に最新のAV Indexファイルをディスクに記録する際、Movie atomのUser data atom中のindex link atomのpreviousフィールドに、遡った3つ前のAV Indexファイルのファイル名を格納する。
このことによって、AV Indexファイルを最新のものから過去に遡って読み出していく際に、previousフィールドを参照することで編集操作を取り消したデータを再度読み出してしまうことを防ぐことができる。また、編集操作を取り消したAV Indexファイルも残っているため、取り消した編集操作も含めて過去の状態を容易に再現できる機能も損なわれていない。また、遡った3つ前のAV Indexファイルの状態を最新のAV Indexファイルとしたい場合、ディスク内の未使用最大ファイル番号のAV Indexとして、有効なentryが管理されていないことを示すようサンプル数が0(エントリを一つも管理していない)あるいは全てのフィールドにNULLを記録するなどした1つの属性情報、またindex link atomに3つ前のAV Indexファイルのファイル名を格納した特別なAV Indexファイルを記録する。これによりファイル番号が最大の最初に読み出すAV Indexファイルより、3つ前のAV Indexファイルを辿ることが可能となる。
<インデックスファイル画面表示処理>
本実施形態におけるインデックスファイル画面表示処理を図46に沿って説明する。まず、最新のAV Indexファイルをopenし(ステップ3201)、Movie atomを読み込み、前述のAV Index管理テーブルをRAM102上に作成する。ただし、この時点では、代表画像データ等各種データの位置情報のみを取得したのみであり、まだ各種データのRAM102上への読み込みは行っていない(ステップ3203)。なお、どのAV Indexファイルが最新かどうかは、前述したように、ファイル名を用いて判断することが可能である。次に、AV Indexファイルから各エントリのタイトル文字列データ、属性情報、代表画像データ、代表オーディオデータを読み出し、AV Index管理テーブルに格納する(ステップ3204)。
なお、すでにAV Index管理テーブルに存在する行と、同じentry−numberを持つ属性情報が読み出されたら、その情報は読み捨てる。有効なエントリデータを読み終わったら、ファイルをcloseする(ステップ2306)。次に、直前にopenしたAV Indexファイル中のindex link atomのpreviousフィールドを参照し、次に読み出すAV Indexファイルの名称を取得する(ステップ3207)。次に、直前にopenしたAV Indexファイルが最後に読み出すAV Indexかどうか、を判断する(ステップ3208)。具体的には、次に読み出すAV Indexファイルの名称がindex link atomで参照無しを示すNULLが指定されていれば、最後のAV Indexと判断する。もし最後に読み出すAV Indexでなければ、次に読み出すAV Indexファイルの名称を持つファイルをopenし(ステップ3209)、ステップ3203以降を実行する。
前述のように、ステップ3201において、最新以外のAV Indexファイルを参照することで、光ディスク106における過去のスナップショット(状態)を容易に再現することが可能になる。
<バリエーション>
本実施形態では、代表画像データ等のエントリデータを変更する場合に、そのデータが含まれるエントリのすべてのエントリデータを再記録している。図44を例に取ると、領域2255にSHRP0002.MOVのタイトル文字列データを記録しているが、変更したのは代表画像データのみであり、本来は記録する必要がないデータである。しかし、前記のデータフォーマットでは変更対象のエントリデータの種別を指定できないため、ある種別のエントリデータを変更する場合、すべての種別のエントリデータを上書きする必要がある。このことを解決する方法としては、図47のように属性情報に変更対象のエントリデータの種別を追加することが考えられる。例えば代表画像データの変更をしたければ、Status of Thumbnailをavailableで他のStatus of Intro musicやStatus of Titleはinvalidに設定する。読み出し時はStatus of Thumbnailがavailableであればデータを読み出し、invalidであればデータは既存のものを用いる。このようにすることで、変更対象の種別のエントリデータだけ記録することが可能になり、記録容量の無駄を削減することが可能になる。
また、本実施形態では、エントリの削除を、entry−numberが同一でstatus of entryがinvalidのエントリを追加することで行っているが、削除対象のエントリを管理するAV Indexファイルを削除することで行ってもよい。この場合、各AV Indexファイルで管理するエントリは1個に限定することになる。さらに、削除対象のエントリを管理するAV Indexファイルに関して、ファイル名を変更し、無効化することで行ってもよい。
〔第3の実施形態〕
本発明の第3の実施形態について、図48乃至図52を用いて説明する。本実施形態は、管理情報の重複記録を避けるという点で第2の実施形態と共通するが、管理情報やエントリデータを1個のAV Indexファイルに追記していくという点が異なる。
<管理情報フォーマット>
本実施形態におけるAV Indexファイルの構成を図48に示す。AV Indexファイルは、前述のFragmented movieで構成する。すなわち、先頭にファイル全体の管理情報であるMovie atomを置き、Movie data atomとMovie fragment atomを交互に並べる。Movie fragment atomは、属性情報、代表オーディオデータ、代表画像データおよびタイトル文字列データを管理するために、Property track、Intro music track、Thumbnail track、Title trackをそれぞれ持つ。各Movie fragment atomは、トラックをまたぐサンプル同士が共通のエントリに対応していることを示すため、各トラックに関して同一数なおかつ同一時間長のサンプルを管理する。
例えば、Movie fragment atom4103がm個のエントリを管理していた場合、属性情報、代表オーディオデータ、代表画像データおよびタイトル文字列データそれぞれにm個のサンプルを管理する。そのサンプルに対応するデータは、Movie fragment atom4103に対応するMovie data atomであるMovie data atom4102に格納する。
なお、属性情報、代表オーディオデータ、代表画像データおよびタイトル文字列データのフォーマットは第1の実施形態と同一であるため、説明を省略する。
<全体の流れ>
本実施形態における、ディスク挿入から、ディスクイジェクトあるいは電源OFFまでの流れは第1の実施形態と同様であり、説明を省略する。ここでは、処理を開始する前の初期状態として、光ディスク106に第1の実施形態と同様の図32(a)に示すディレクトリ構成でファイルが記録され、それぞれが光ディスク106上に図49に示すように配置されていると仮定する。すなわち、AVファイルであるSHRP0001.MOV、SHRP0002.MOVおよびSHRP0003.MOVは、それぞれ、領域4201、領域4202および領域4203に記録される。またAV IndexファイルであるAVIF0000.MOVは、図49中の領域4204に記録され、領域4204の先頭にはAV Index fileのMovie atomが領域4211に記録される。
また、SHRP0001.MOVの属性情報、タイトル文字列データおよび代表画像データが、領域4212、領域4215、領域4218、に記録され、SHRP0002.MOVの属性情報、タイトル文字列データおよび代表画像データが、領域4213、領域4216、領域4219に、記録され、SHRP0003.MOVの属性情報、タイトル文字列データおよび代表画像データが、領域4214、領域4217、領域4220に記録され最後に上記のエントリデータを管理するMovie fragment atomと後述するSkip atomが領域4221と領域4222にそれぞれ記録されているとする。さらに、後述するインデックス画面表示処理を行った結果、RAM102には、AV Indexファイルに関する情報を管理するための図37に示すテーブルが構成されると仮定する。
<録画時の処理>
第1の実施形態と同様であり、説明を省略する。
<エントリ削除処理>
第1の実施形態と同様であり、説明を省略する。
<エントリデータ変更時の処理>
第1の実施形態と同様であり、説明を省略する。
<AV Index記録処理>
本実施形態におけるAV Indexファイル記録処理について図50を用いて説明する。まず、RAM102上のAV Index管理テーブルの統合処理を行い(ステップ4301〜4302)、その結果に基づきSample tableを構築する(ステップ4303)。具体的な処理は第2の実施形態と同一であるため、説明を省略する。次にMovie data atomを記録する(ステップ4304)。具体的には、atom headerを記録し、個々のエントリの属性情報、代表データ、代表オーディオデータおよびタイトル文字列データを記録する。最後に、上記のSample tableの内容を元にMovie fragment atomを記録する(ステップ4305)。Movie fragment atomの記録が終わったら、ファイルの終端がセクタの境界と一致するよう、前述のSkip atomを調整のため挿入する。これにより、AV Indexファイルを整数個のセクタで構成することになる。なお、Movie fragment atomとMovie data atomの記録順は逆であってもよい。また、サイズの調整にSkip atomでなく、Movie fragment atomの直前に無意味データを入れてもよい。その場合、Movie data atomのatom headerのsizeフィールドには、前記無意味データのデータ量を含めることになる。
その後、今回記録した領域を既存のAV Indexファイルの一部とするため、AV Indexファイルを管理するFEに対し、この領域を新規extentとして追加して、ディスクに追記する。Skip atomによるサイズ調整は、extent追加処理を行った場合でも、QuickTimeファイルとして矛盾が無いようにするために行っている。
このようにextentを追加されディスクに追記されたFEが、請求の範囲における「第3のデータ」に相当する。
以上の処理を行った直後の光ディスク106の記録状態を具体的に説明する。AV Indexファイル記録処理開始直前に、RAM102上には図37の内容を持つAV Index管理テーブルが存在すると仮定する。AV Indexファイル記録処理を行った結果、光ディスク106上には図51(a)に示すように、領域4242に対し領域4230〜4239に示すデータが追記される。まず、領域4242の先頭の領域4230にはMovie data atomのatom headerが記録される。領域4231〜4233には属性情報が記録され、それぞれ、SHRP0001.MOV4201を無効化するための属性情報、SHRP0002.MOV4202の代表画像データを置き換えるための属性情報、SHRP0004.MOV4241を新規登録するための属性情報である。領域4234および領域4235には、代表画像の変更されたSHRP0002.MOV4202および新規登録されたSHRP0004.MOV4241のタイトル文字列データが記録される。
また、領域4236、領域4237には、SHRP0002.MOV4202およびSHRP0004.MOV4241の代表画像データがそれぞれ記録されている。領域4238、領域4239にはMovie fragment atomとファイルの終端をセクタ境界に合わせるためのskip atomがそれぞれ記録されている。AV Indexファイルに関する既存の情報と最新の情報が領域4204および領域4242にそれぞれ記録され、AV IndexファイルのFEに対して領域4242を後続のextentとして追加したとき、AV Indexファイルを読み出すと図51(b)の左から順に読み出されることになる。
<インデックスファイル画面表示処理>
本実施形態におけるインデックスファイル画面表示処理を図52に沿って説明する。まず、AV Indexファイルをopenし(ステップ4401)、Movie atomを読み出す(ステップ4402)。次に、後続する領域を読み出し、ファイルの末尾であれば(ステップ4403)、インデックス画面を表示(ステップ4404)して終了する。ファイルの末尾でなければMovie fragment atomかどうかを判断する(ステップ4405)。Movie fragment atomであれば、Movie fragment atomを読み出し(ステップ4406)、その情報に従い、Movie data atom、すなわち属性情報等のエントリデータを読み出す(ステップ4407)。ステップ4405において、読み出した領域がMovie fragment atom以外のatomであった場合は、Movie fragment atomが出てくるまで読み飛ばしを行う(ステップ4408)。
<バリエーション>
本実施形態でも、第2の実施形態と同様、図47に示す変更対象のエントリデータの種別情報を記録することで、記録容量の無駄を削減することが可能である。
また、本実施形態では、エントリの削除を同一entry−numberを持つエントリを追記することで行っているが、削除対象のエントリを管理するFragmented Movieに対応するextentをAV IndexファイルのFEから削除することで行ってもよい。ただし、sequence−numberの不連続を無視する必要がある。
また、本実施形態においてファイルの読み出しは必ず先頭からになるため、最近記録したエントリデータにアクセスする時間が長くなる傾向にある。これを避けるため、エントリデータが新しく記録した順に並ぶよう、AV IndexファイルのFEを設定してもよい。また、その際に、第1や第2の実施形態に説明するように、エントリデータへのアクセスが高速化されるよう、特定の属性のエントリデータのみ、重複して記録してもよいことは言うまでもない。
〔第4の実施形態〕
本発明の第4の実施形態について、図53(a)〜図59(b)を用いて説明する。本実施形態は第1の実施形態に類似するが、Movie atomを含む記録済みのデータを、AV Indexファイルに関するFEの操作により極力再利用する点が異なる。ここでは、AV Indexファイルの更新処理に絞って説明する。
本実施形態の管理情報フォーマットは第1の実施形態と同一であるため、説明を省略する。
<AV Indexファイル更新時の処理(Movie atom中のデータ量の変化がセクタの整数倍の場合)>
まず、AV Indexファイル更新によってMovie atomのサイズがセクタの整数倍でしか変化しない場合(AV Indexファイル更新によってMovie atomのサイズが変化しない場合も含む)の、AV Indexファイルの更新処理について図53(a)(b)および図54を用いて説明する。
まず、更新前のAV Indexファイルのデータ構成を示す図53(a)の説明を行う。AV IndexファイルはMovie atom5101とatom header5102、属性情報5103等で構成されるMovie data atomで構成される。ここでは、Movie data atom中の属性情報5103の内容とデータ量を変更することを考える。このとき、Movie data atomのサイズが変わるため、atom header5102のsizeフィールドを書きかえる必要が発生する。さらに、属性情報5103のサイズが変わるため、属性情報5103のデータ量情報(Sample size atom)や、後続するデータに対応するサンプルの位置情報(Chunk offset atom)を書きかえる必要がある。すなわち、Movie atom5101の一部を書きかえる必要がある。このとき書きかえる必要のある部分を要変更部分5104と呼ぶことにする。なお、この変更によるサンプル数の変更はないため、通常Sample table atomのデータ量の増減は発生しない。
図53(a)に示すAV Indexファイルが、図54に示すように光ディスク106上の領域5221に記録され、上記の属性情報5103、atom header5102、要変更部分5104がディスク上のセクタ上に配置されたと仮定する。なお、データ5201およびデータ5202は、それぞれ要変更部分が格納されたセクタ列における、要変更部分5104の左方、右方のデータを示す。同様に、データ5203およびデータ5204は、それぞれatom header5102の左方、右方のデータを示す。また、データ5205、データ5206は、それぞれ属性情報5103の左方、右方のデータを示す。
変更処理により、変更後の属性情報5113、変更後のatom header5112、要変更部分5104の変更結果5114は、領域5224に以下に説明する形態で記録される。まず、変更後の属性情報5113に関しては、前記データ5205、属性情報5113、パディング5207、前記データ5206の順に記録される。パディング5207は、前記データ5205、属性情報5113、パディング5207、前記データ5206を合わせたデータ量をセクタサイズの整数倍にするための無効データである。
なお、パディング5207は、請求の範囲における「無意味データ」に相当する。
次に、変更後のatom header5112は、前記データ5203、atom header5112、前記データ5204の順に記録される。atom header5112はデータ量に変更が無いため、属性情報の記録において説明したようなパディングは必要ない。
次に、変更結果5114は、前記データ5207、変更結果5114、前記データ5202の順に記録する。前述のようにデータ量の変更はないため、パディングは必要無い。
最後に、図中のR1、R10、R3、R9、R5、R6、R8の順に読み出されるようにAV IndexファイルのFEを構成して追記する。
このように再構成されて追記されたFEが、請求の範囲における「第3のデータ」に相当する。
以上の処理により、AV Indexファイルが図53(b)のように書きかえられることになる。なお、ここでは、属性情報を変更の対象としたが、サムネイル等他のエントリデータについても同様である。
上記のAV Indexファイル更新処理を行うことで、変更に伴う記録容量の無駄を最小限に抑えることが可能になる。
<AV Indexファイル更新時の処理(Movie atom中のデータ量の変化がセクタの整数倍でない場合)>
次に、AV Indexファイル更新によってMovie atomのサイズがセクタの整数倍以外で変化する場合の、AV Indexファイルの更新処理について図55(a)(b)および図56を用いて説明する。
更新前のAV Indexファイルのデータ構成を図55(a)に示すが、図53(a)と同一であるため、説明を省略する。このAV Indexファイルに対し属性情報等エントリデータの追加を行うことを考える。追加によって、Movie atom5101の管理するサンプルの数が増加し、Chunk offset atomのエントリ数が増加、すなわち管理情報の追加が発生する。それに伴い、上位のatomのatom headerのsizeフィールドを更新する必要がある。また、エントリデータの追加によって、Movie data atomのデータ量が増加するため、Movie data atomのatom header中のsizeフィールドを更新する必要がある。
図55(a)に示すAV Indexファイルが、図56に示すように光ディスク106上の領域5221に記録され、Chunk offset atomのエントリ数増加に伴う追加管理情報5303の挿入位置がデータ追加箇所5301であると仮定する。なお、Movie data atomのatom header等のデータ量の変わらないものについては、図54と同様であるため省略する。なお、データ5311およびデータ5313は、それぞれデータ追加箇所5301の含まれるセクタにおける、データ追加箇所5301の左方、右方のデータを示す。
変更処理により、前記データ5311、前記データ5313、追加管理情報5303および追加エントリデータ5302は、以下に説明する形態で記録される。まず、前記データ5311、追加管理情報5303、前記データ5313、データ5314の順にセクタの先頭から記録される。また追加エントリデータ5302も、別のセクタ列に記録される。なお、データ5314は、前記データ5313の末尾からセクタの末尾までに存在する無意味データである。最後に、図57(a)に示すように、R11、R14、R13、R15の順にAV IndexファイルのFEを構成して追記する。このとき、データ5314は無意味データであり、このAV Indexファイルを先頭から解釈した場合、正しく解釈できない。それを避けるため、それらの無意味データを無効化する情報を光ディスク106に記録する。具体的には、SKIP0000.DATというファイルを作成し、それらのデータのAV Indexファイル先頭からのアドレスとバイト数を記録する。
AV Indexの読み出し時には、直前にSKIP0000.DATを読み出し、その情報に基づき、AV Indexファイルを解釈する。
以上のような更新処理により、AV Indexファイル更新に伴うMovie atom中のデータの重複記録を最小限にすることができる。
<バリエーション>
本実施形態では、無意味データも含め1個のファイルにまとめているが、図57(b)に示すように、複数のファイルで管理してもよい。すなわち、R11とデータ5311、追加管理情報5303、データ5313を1個の部分AV Indexファイル5321、R13と追加エントリデータ5302を1個の部分AV Indexファイル5324として管理する。部分AV Indexファイル5321と部分AV Indexファイル5324を連続して読み出すことで、RAM102上でAV Indexファイルを復元することになる。複数のファイル間の読み出し順を管理する方法としては、次のものが考えられる。例えば、最新のAV Indexファイルを構成するファイルについては、読み出し順にAVIF00001.MOS、AVIF0002.MOSのようにファイル名で順序がわかるようにすることが考えられる。ここで拡張子をMOSにしているのは、分割されているものであることを示すためである。また、ファイルの読み出し順を記録したファイルを作成し、AV Index読み出し時は必ずそのファイルを参照することも考えられる。
また、追加管理情報5303を含む追加データを、別のファイルに追加位置を管理する情報と共に記録し、AV Index読み出し時は必ずそのファイルを参照することも考えられる。
また、本実施形態では、追加管理情報のデータサイズがセクタの整数倍に満たないデータであった場合に、パディングを挿入しているが、そのパディングに、QuickTimeファイルフォーマットにおけるatomを用いてもよい。図58を用いて説明する。なお、上述の説明と同一の符号をつけているものは、上述と同一の意味を持つため、説明を省略する。更新処理の際、まず、データ追加箇所5301の右方に、パディングを挿入可能な個所、具体的にはatomの境界を探す。最初に見つかった個所をパディング挿入可能個所5320とする。また、データ追加箇所5301からパディング挿入可能個所5320までのデータをデータ5321、パディング挿入可能個所5320から最初のセクタ境界までのデータを5322と定義する。
上記のデータから、データ5311、追加管理情報5303、データ5321、パディング5323、データ5322を順に記録する。ここでパディング5323は上記のデータがセクタの整数倍のデータ量になるように挿入され、前述のskip atomのように、再生時に無視される無意味なatomを用いる。最後に、R11、R23、R22、R16の順にAV Indexファイルが読み出されるよう、AV IndexファイルのFEを構成して追記する。このように、セクタの整数倍でないデータを追加する場合、atomの境界にサイズ調整用のatomを挿入することで、データの追記を少なく抑え、なおかつAV Indexファイル単独で内容の解釈が可能となる。
また、本実施形態では、更新処理によってMovie atom中のatomサイズの増減が発生することを前提にしているが、サイズの増減するatom(例:edit atom、sample atom)については、AV Indexファイルの初期記録時に十分な大きさの領域を確保しておき、使用していない領域に関しては、図59(a)に示すように、再生時に無視される無意味なatom(ここではnull atomと呼ぶ)を記録することが考えられる。例えば、サンプル情報に追加によりChunk offset atomのデータ量が図59(a)のchunk offset atom5401からchunk offset atom5403のように増加したときには、それに伴い、後続するnull atomの先頭をファイルの後方にずらし、sizeを小さくすることで、上位のatomのatom headerの変更やMovie data atomの移動によるChunk offsetの変更、すなわち追記データの増加を防ぐことが可能になる。このような構成をとった場合、AV Indexファイルの分割やAV Indexファイルの内容を解釈するための付加的な情報は不要である。さらに、サイズの増減するatomの先頭5405およびnull atomの末尾5406をセクタ境界に一致させることで、処理を単純化することが可能である。
また、AV Indexファイルの初期記録時に使用していない領域に対して無意味なatomを入れる代わりに、図59(b)に示すように、十分な数の空のサンプルを登録しておいてもよい。図59(b)の場合、chunk offset atom5411のエントリ数を管理するフィールドであるnumber of entries5412に、例えば1000を記録しておき、エントリデータ5413からエントリデータ5414の間には1000個のエントリを登録しておく。このとき、AV Indexファイルへのエントリ追加に伴い、空のサンプルに実際のデータに関する情報を登録していく。サンプルが空であることを示す方法としては、サンプルのコーデック情報を無効なものに設定することが考えられる。あるいは、実際に管理しているentry数に相当するatomサイズより大きく、atom headerでatomサイズを管理することによって領域確保するようにしても良い。さらに、chunk offset atomの始終端をセクタ境界に一致させることで、処理を単純化することが可能である。このような構成をとった場合、AV Indexファイルの分割やAV Indexファイルの内容を解釈するための付加的な情報は不要である。これら方法は、他のatom、例えば、edit list atomに関しても適用可能なのは言うまでもない。
また、本実施形態に記してある更新処理は、AV IndexファイルだけでなくAVファイルにも適用可能なのは言うまでもない。
〔全実施形態を通じての補足〕
なお、上述の実施形態において記録媒体としてDVD−Rを用いているが、本発明は追記型の記録媒体であればDVD−R以外の記録媒体でも適用可能であることは言うまでもない。また、追記型でなくとも媒体の書き換え回数に制限のある記録媒体、例えばフラッシュROMにも適用可能であることは言うまでもない。したがって本実施形態においてはデータの管理単位としてセクタを用いているが、異なる記録媒体に適用した場合、セクタをそれぞれの記録媒体上のデータの管理/記録単位や管理/記録ユニットに読み替えることになる。
なお、上述の実施形態においてファイルシステムにUDFを用いているが、本発明はUDFに限定されるものではない。
また、上述の実施形態においてデータとしてオーディオやビデオといったAVデータを用いているが、本発明はそれに限定されるものではない。
なお、上述の実施形態においてファイルフォーマットとしてQuickTimeファイルフォーマットを用いているが、本発明はそれに限定されるものではない。
以上説明したように、本発明によれば、追記データを記録する際に、既存データの有効/無効を管理する情報を記録することによって、既存データの再利用が可能となり、記録容量の無駄を削減できる。
また、本発明によれば、追記データを記録する際に、既存データの属性に応じて既存データと同一データを記録することによって、特定の属性を持つデータを高速に読み出すことが可能となり、ユーザへのレスポンスを向上させることができる。
尚、発明を実施するための最良の形態の項においてなした具体的な実施態様または実施形態は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と次に記載する特許請求の範囲内で、いろいろと変更して実施することができるものである。
産業上の利用の可能性
本発明は、ハードディスク、光ディスク等のランダムアクセス可能な記録媒体に対して、映像データ、音声データを記録するデータ記録方法、データ記録装置、データ記録媒体、データ再生方法、データ再生装置に関するものである。追記型メディアにおいて、AVファイル管理用のインデックスファイルを更新する際、記録容量の無駄が生じる。そこで、更新時に新規のインデックスファイルを作成し、既存のインデックスファイル中のサムネイル画像データを参照することで、無駄を削減すると同時に、属性情報は新規のインデックスファイルに格納することで、最低限必要な情報へのアクセスを高速化する。
【図面の簡単な説明】
図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(a)〜(c)は、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は、本発明の実施形態におけるAVストリームの構成を示す図面である。
図22は、本発明の実施形態におけるVUの構造を示す図面である。
図23は、本発明の実施形態におけるQuickTimeによるAVストリーム管理形態を示す図面である。
図24は、本発明の実施形態におけるリファレンス・デバイス・モデルを示すブロック図である。
図25(a)(b)は、UDFにおける管理情報の関係を示す図面である。
図26は、追記型記録媒体でのUDFにおける管理情報の関係を示す図面である。
図27は、本発明の第1の実施形態における、AV Indexファイルの構成を示す図面である。
図28は、本発明の第1の実施形態における属性情報の構成を示す図面である。
図29は、本発明の第1の実施形態におけるflagsの構成を示す図面である。
図30は、本発明の第1の実施形態における全体の処理の流れを示すフローチャートである。
図31は、本発明の第1の実施形態におけるユーザ指示による各種処理の流れを示すフローチャートである。
図32(a)(b)は、それぞれ本発明の第1の実施形態におけるAV Indexファイル更新前のディレクトリ/ファイル構成および記録媒体上の記録状態の例を示す図面である。
図33は、本発明の第1の実施形態における、ディスク挿入直後のAV Index管理テーブルの例を示す図面である。
図34(a)(b)は、本発明の第1の実施形態における、録画処理直後の記録媒体上の記録状態の例を示す図面である。
図35は、本発明の第1の実施形態における、録画直後のAV Index管理テーブルの例を示す図面である。
図36は、本発明の第1の実施形態における、エントリ削除直後のAV Index管理テーブルの例を示す図面である。
図37は、本発明の第1の実施形態における、エントリデータ変更直後のAV Index管理テーブルの例を示す図面である。
図38は、本発明の第1の実施形態におけるAV Indexファイル更新処理を示すフローチャートである。
図39は、本発明の第1の実施形態におけるAV Indexファイル更新後の記録媒体上の記録状態の例を示す図面である。
図40は、本発明の第1の実施形態におけるAV Indexファイル読み出し処理を示すフローチャートである。
図41は、本発明の第1の実施形態における属性情報の第2の構成を示す図面である。
図42は、本発明の第2の実施形態において追加した管理情報の構成を示す図面である。
図43は、本発明の第2の実施形態におけるAV Indexファイル更新処理を示すフローチャートである。
図44は、本発明の第2の実施形態におけるAV Indexファイル更新後の記録媒体上の記録状態の例を示す図面である。
図45(a)(b)は、本発明の第2の実施形態におけるAV Indexファイルマージ前後の記録媒体上の記録状態の例を示す図面である。
図46は、本発明の第2の実施形態におけるAV Indexファイル読み出し処理を示すフローチャートである。
図47は、本発明の第2の実施形態におけるflagsの第2の構成を示す図面である。
図48は、本発明の第3の実施形態における、AV Indexファイルの構成を示す図面である。
図49は、本発明の第3の実施形態におけるAV Indexファイル更新前の記録媒体上の記録状態の例を示す図面である。
図50は、本発明の第3の実施形態におけるAV Indexファイル更新処理を示すフローチャートである。
図51(a)(b)は、本発明の第3の実施形態におけるAV Indexファイル更新後の記録媒体上の記録状態の例を示す図面である。
図52は、本発明の第3の実施形態におけるAV Indexファイル読み出し処理を示すフローチャートである。
図53(a)(b)は、本発明の第4の実施形態におけるAV Indexファイル更新処理(Movie atom中のデータ量の変化がセクタの整数倍の場合)を示す図面である。
図54は、本発明の第4の実施形態におけるAV Indexファイル更新(Movie atom中のデータ量の変化がセクタの整数倍の場合)後の記録媒体上の記録状態の例を示す図面である。
図55(a)(b)は、本発明の第4の実施形態におけるAV Indexファイル更新処理(Movie atom中のデータ量の変化がセクタの整数倍でない場合)を示す図面である。
図56は、本発明の第4の実施形態におけるAV Indexファイル更新(Movie atom中のデータ量の変化がセクタの整数倍でない場合)後の記録媒体上の記録状態の例を示す図面である。
図57(a)(b)は、本発明の第4の実施形態におけるAV Indexファイルと領域の関係の例を示す図面である。
図58は、本発明の第4の実施形態における第2の更新方法によるAV Indexファイル更新後の記録媒体上の記録状態の例を示す図面である。
図59(a)(b)は、本発明の第4の実施形態における第3の更新方法によるAV Indexファイル更新後の記録媒体上の記録状態の例を示す図面である。
図60は、従来技術におけるインデックスファイルを示す図面である。

Claims (5)

  1. 本体データと、その本体データに関する見出し情報を含んだ見出しデータとが記録されているデータ記録媒体の記録内容を、データ記録装置により変更するデータ記録方法であって、
    前記データ記録装置の見出しデータ作成手段が、変更後の記録内容に応じた新たな見出しデータを作成するステップと、
    前記データ記録装置の記録手段が、前記作成した新たな見出しデータを前記データ記録媒体に記録するステップとを含み、
    前記新たな見出しデータには、
    既に前記データ記録媒体に記録されている旧い見出しデータに含まれ、かつ、内容を変更する必要のない見出し情報のうちの一部のものに関して、前記旧い見出しデータに含まれる見出し情報を参照するための参照情報と、
    既に前記データ記録媒体に記録されている旧い見出しデータに含まれ、かつ、内容を変更する必要のない見出し情報のうちの他の一部のものに関して、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報とを含め、
    前記新たな見出しデータに、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報を含めるかどうかは、当該見出し情報の属性に基づいて定められるデータ記録方法。
  2. 本体データと、その本体データに関する見出し情報を含んだ見出しデータとが記録されているデータ記録媒体の記録内容を変更するデータ記録装置であって、
    前記データ記録媒体の記録内容を変更する際に、変更後の記録内容に応じた新たな見出しデータを作成する見出しデータ作成手段と、
    前記作成された新たな見出しデータを前記データ記録媒体に記録する記録手段とを備え、
    前記見出しデータ作成手段は、
    既に前記データ記録媒体に記録されている旧い見出しデータに含まれ、かつ、内容を変更する必要のない見出し情報のうちの一部のものに関して、前記旧い見出しデータに含まれる見出し情報を参照するための参照情報と、
    既に前記データ記録媒体に記録されている旧い見出しデータに含まれ、かつ、内容を変更する必要のない見出し情報のうちの他の一部のものに関して、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報とを、前記新たな見出しデータに含め、
    前記新たな見出しデータに、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報を含めるかどうかは、当該見出し情報の属性に基づいて定めるデータ記録装置。
  3. 本体データと、その本体データに関する見出し情報を含んだ見出しデータとが記録されているデータ記録媒体であって、
    記録内容を変更する前に記録された旧い見出しデータと、
    記録内容を変更した後に記録された新しい見出しデータとを含み、
    前記旧い見出しデータに含まれ、かつ、記録内容の変更後においても内容を変更する必要のない見出し情報のうちの一部のものに関して、前記旧い見出しデータに含まれる見出し情報を参照するための参照情報と、他の一部のものに関して、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報とが、前記新しい見出しデータに含まれ、
    前記新しい見出しデータに、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報が含まれるかどうかは、当該見出し情報の属性に基づいて定まっているデータ記録媒体。
  4. 本体データと、その本体データに関する見出し情報を含んだ見出しデータとが記録されているデータ記録媒体の記録内容を、データ再生装置により再生するデータ再生方法であって、
    前記データ記録媒体には、記録内容を変更する前に記録された旧い見出しデータと、記録内容を変更した後に記録された新しい見出しデータとが含まれ、
    前記新しい見出しデータには、前記旧い見出しデータに含まれ、かつ、記録内容の変更 後においても内容を変更する必要のない見出し情報のうちの一部のものに関して、前記旧い見出しデータに含まれる見出し情報を参照するための参照情報と、他の一部のものに関して、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報とが含まれ、
    前記新しい見出しデータに、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報が含まれるかどうかは、当該見出し情報の属性に基づいて定まっており、
    前記データ再生装置の再生手段が、前記新しい見出しデータに含まれる参照情報に基づいて、前記旧い見出しデータから見出し情報を取得するステップと、
    前記データ再生装置の再生手段が、前記新しい見出しデータに含まれる見出し情報を取得するステップとを含むデータ再生方法。
  5. 本体データと、その本体データに関する見出し情報を含んだ見出しデータとが記録されているデータ記録媒体の記録内容を再生するデータ再生装置であって、
    前記データ記録媒体には、記録内容を変更する前に記録された旧い見出しデータと、記録内容を変更した後に記録された新しい見出しデータとが含まれ、
    前記新しい見出しデータには、前記旧い見出しデータに含まれ、かつ、記録内容の変更後においても内容を変更する必要のない見出し情報のうちの一部のものに関して、前記旧い見出しデータに含まれる見出し情報を参照するための参照情報と、他の一部のものに関して、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報とが含まれ、
    前記新しい見出しデータに、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報が含まれるかどうかは、当該見出し情報の属性に基づいて定まっており、
    前記データ記録媒体の記録内容を再生する際に、前記新しい見出しデータに含まれる参照情報に基づいて、前記旧い見出しデータから見出し情報を取得するとともに、前記新しい見出しデータに含まれる見出し情報を取得する再生手段を備えるデータ再生装置。
JP2003577266A 2002-03-18 2003-03-17 データ記録方法、データ記録装置、データ記録媒体、データ再生方法及びデータ再生装置 Expired - Fee Related JP3847751B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2002073524 2002-03-18
JP2002073524 2002-03-18
PCT/JP2003/003210 WO2003079359A1 (fr) 2002-03-18 2003-03-17 Procede, dispositif et support d'enregistrement de donnees, et procede et dispositif de reproduction de donnees

Publications (2)

Publication Number Publication Date
JPWO2003079359A1 JPWO2003079359A1 (ja) 2005-07-21
JP3847751B2 true JP3847751B2 (ja) 2006-11-22

Family

ID=28035246

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2003577266A Expired - Fee Related JP3847751B2 (ja) 2002-03-18 2003-03-17 データ記録方法、データ記録装置、データ記録媒体、データ再生方法及びデータ再生装置

Country Status (6)

Country Link
US (1) US20050157599A1 (ja)
EP (1) EP1486979B1 (ja)
JP (1) JP3847751B2 (ja)
CN (1) CN1643605B (ja)
AU (1) AU2003221415A1 (ja)
WO (1) WO2003079359A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013518507A (ja) * 2010-03-05 2013-05-20 サムスン エレクトロニクス カンパニー リミテッド ファイルフォーマットベースの適応的ストリーム生成、再生方法及び装置とその記録媒体

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3988990B2 (ja) * 2002-08-27 2007-10-10 株式会社リコー 符号変換装置、符号変換方法、プログラム及び記録媒体
JP4022755B2 (ja) * 2003-01-21 2007-12-19 ソニー株式会社 記録装置、再生装置、ファイル管理方法及びファイル再生方法
JP4326236B2 (ja) * 2003-02-28 2009-09-02 ソニー株式会社 記録装置及び方法
JP3969656B2 (ja) * 2003-05-12 2007-09-05 ソニー株式会社 情報処理装置および方法、プログラム記録媒体、並びにプログラム
JP2005136537A (ja) * 2003-10-29 2005-05-26 Sony Corp ファイル記録装置、ファイル再生装置、ファイル編集装置、ファイル記録方法、ファイル再生方法、ファイル編集方法、ファイル記録方法のプログラム、ファイル再生方法のプログラム、ファイル編集方法のプログラム、ファイル記録方法のプログラムを記録した記録媒体、ファイル再生方法のプログラムを記録した記録媒体、ファイル編集方法のプログラムを記録した記録媒体、記録媒体
KR101009341B1 (ko) * 2003-11-25 2011-01-19 삼성전자주식회사 기록 장치, 재생 장치, 기록 방법, 재생 방법 및 그기록매체
DE102004001207A1 (de) * 2004-01-06 2005-07-28 Deutsche Thomson-Brandt Gmbh Verfahren und Vorrichtung zum Aktualisieren von Daten auf einem Plattenspeichermedium
US7624021B2 (en) 2004-07-02 2009-11-24 Apple Inc. Universal container for audio data
JP2006066014A (ja) * 2004-08-30 2006-03-09 Sony Corp 画像情報記録装置および画像情報表示装置
JP2006066015A (ja) 2004-08-30 2006-03-09 Sony Corp 画像情報記録装置および画像情報表示装置
JP4333599B2 (ja) * 2005-02-15 2009-09-16 ソニー株式会社 情報処理装置、情報処理方法
US20060181966A1 (en) * 2005-02-17 2006-08-17 Fuji Photo Film Co., Ltd. Image retrieving and recording apparatus, an image retrieving and recording method, and a recording medium
US20060181967A1 (en) * 2005-02-17 2006-08-17 Fuji Photo Film Co. Ltd Image retrieving apparatus, an image retrieving method, and a recording medium
JP4778253B2 (ja) * 2005-03-29 2011-09-21 株式会社日立製作所 コンテンツ情報表示装置
CN101053032A (zh) * 2005-08-23 2007-10-10 索尼株式会社 记录装置、记录方法、程序及计算机可读记录介质
JP4079169B2 (ja) * 2005-10-06 2008-04-23 コニカミノルタビジネステクノロジーズ株式会社 画像処理装置、その装置を備える画像処理システム、画像処理方法およびコンピュータを画像処理装置として機能させるためのプログラム
JP4626483B2 (ja) * 2005-10-27 2011-02-09 ソニー株式会社 サーバ装置、データ処理方法、プログラムおよび通信方法
JP2007149151A (ja) * 2005-11-24 2007-06-14 Funai Electric Co Ltd 光ディスク再生装置、音声信号出力装置及びavシステム
JP2007243907A (ja) * 2006-02-10 2007-09-20 Sony Corp 記録装置、記録方法、記録方法のプログラム、記録方法のプログラムを記録した記録媒体、再生装置、再生方法、再生方法のプログラム及び再生方法のプログラムを記録した記録媒体
JP5067599B2 (ja) 2006-06-08 2012-11-07 ソニー株式会社 映像信号処理装置、映像表示装置および映像表示方法
US7937662B2 (en) * 2006-07-21 2011-05-03 Cyberlink Corp. System and method for implementing remote control functions in a mouse in a video playback system
US8230125B2 (en) * 2007-10-30 2012-07-24 Mediatek Inc. Methods for reserving index memory space in AVI recording apparatus
CN101447207B (zh) 2008-12-30 2012-02-15 华为终端有限公司 一种媒体录制方法及装置
JP2010176786A (ja) * 2009-01-05 2010-08-12 Panasonic Corp コントローラ、録画機器及びメニュー表示方法
AU2010204110B2 (en) * 2009-01-07 2012-08-23 Nds Limited Data stream storage system

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3147255B2 (ja) * 1992-10-13 2001-03-19 ソニー株式会社 データ記録方法、データ記録装置およびデータ記録媒体
EP1912422A2 (en) * 1994-08-31 2008-04-16 Sony Corporation Still picture system
WO1996008014A1 (fr) * 1994-09-08 1996-03-14 Sony Corporation Systeme de visualisation d'image fixe
JP2857144B1 (ja) * 1995-04-11 1999-02-10 株式会社東芝 光ディスク再生装置及び再生方法並びに光ディスク記録装置及び記録方法
JPH09213056A (ja) * 1996-02-06 1997-08-15 Sharp Corp 大容量データ検索装置
US5940853A (en) * 1996-02-23 1999-08-17 Matsushita Electric Industrial Co., Ltd. Recording and reproducing apparatus enabling modification of data recorded on a non-erasable recording medium
JP3822942B2 (ja) * 1996-02-23 2006-09-20 松下電器産業株式会社 追記型記録媒体記録再生装置
JPH117700A (ja) * 1997-06-16 1999-01-12 Ricoh Co Ltd 追記型光ディスク装置のファイルデータ管理方法
WO1999014757A2 (en) * 1997-09-17 1999-03-25 Matsushita Electric Industrial Co., Ltd. Video data editing apparatus, optical disc for use as a recording medium of a video data editing apparatus, and computer-readable recording medium storing an editing program
JPH11242873A (ja) * 1998-02-26 1999-09-07 Sony Corp 記録再生装置
JP3614648B2 (ja) * 1998-03-13 2005-01-26 富士通株式会社 文書理解支援装置、要約文生成方法、並びに文書理解支援プログラムを記録したコンピュータ読み取り可能な記録媒体
JP2000021136A (ja) * 1998-06-30 2000-01-21 Toshiba Corp マルチメディア情報の記録再生装置及び同装置に適用する記録再生方法
JP2000235780A (ja) * 1999-02-15 2000-08-29 Nec Corp ディスク記憶媒体およびその録画編集再生方法およびその録画編集再生装置
JP3829268B2 (ja) * 1999-04-19 2006-10-04 株式会社日立製作所 ディスク記録媒体への情報記録方法および装置
EP1126454A4 (en) * 1999-07-07 2004-11-24 Matsushita Electric Ind Co Ltd AUDIOVISUAL PRINT RECORDING DEVICE AND METHOD, DISK RECORDED BY THIS DEVICE AND METHOD, AUDIOVISUAL DATA REPRODUCTION DEVICE AND METHOD THEREFOR
EP1206135B1 (en) * 1999-07-29 2011-08-24 Sharp Kabushiki Kaisha Method of determining access position on recording medium and method of managing recording medium
CA2279119C (en) * 1999-07-29 2004-10-19 Ibm Canada Limited-Ibm Canada Limitee Heuristic-based conditional data indexing
JP4629173B2 (ja) * 1999-09-17 2011-02-09 ソニー株式会社 記録装置および記録方法、並びに記録媒体
JP2001243107A (ja) * 2000-03-01 2001-09-07 Matsushita Electric Ind Co Ltd Avデータ記録装置及び方法、又は当該avデータ記録装置及び方法で記録されたディスク
KR100746821B1 (ko) * 2000-04-21 2007-08-06 소니 가부시끼 가이샤 정보 처리 장치와 방법, 기록매체
JP2002042451A (ja) * 2000-07-24 2002-02-08 Victor Co Of Japan Ltd オーディオデータ記録再生ディスク及びその再生装置、再生方法並びに記録方法
JP2002050131A (ja) * 2000-08-03 2002-02-15 Hitachi Ltd 追記型記録媒体の記録制御方法
JP2002278996A (ja) * 2001-03-22 2002-09-27 Sony Corp 記録装置および記録方法、並びに記録媒体
JP3695581B2 (ja) * 2001-08-08 2005-09-14 ソニー株式会社 記録装置および記録方法、記録媒体、並びに、電子カメラ

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013518507A (ja) * 2010-03-05 2013-05-20 サムスン エレクトロニクス カンパニー リミテッド ファイルフォーマットベースの適応的ストリーム生成、再生方法及び装置とその記録媒体
US9906580B2 (en) 2010-03-05 2018-02-27 Samsung Electronics Co., Ltd Method and apparatus for generating and reproducing adaptive stream based on file format, and recording medium thereof
US10630759B2 (en) 2010-03-05 2020-04-21 Samsung Electronics Co., Ltd Method and apparatus for generating and reproducing adaptive stream based on file format, and recording medium thereof

Also Published As

Publication number Publication date
EP1486979B1 (en) 2012-06-13
EP1486979A4 (en) 2006-09-06
WO2003079359A1 (fr) 2003-09-25
CN1643605A (zh) 2005-07-20
US20050157599A1 (en) 2005-07-21
AU2003221415A1 (en) 2003-09-29
EP1486979A1 (en) 2004-12-15
JPWO2003079359A1 (ja) 2005-07-21
CN1643605B (zh) 2011-05-04

Similar Documents

Publication Publication Date Title
JP3847751B2 (ja) データ記録方法、データ記録装置、データ記録媒体、データ再生方法及びデータ再生装置
JP5079757B2 (ja) データ記録方法、データ削除方法、記録装置、記録媒体およびプログラム
JP4937280B2 (ja) データ記録方法、データ編集方法およびデータ復号方法、並びにその装置、及び記録媒体
JP2000021130A (ja) 情報処理装置および方法、記録媒体、並びに提供媒体
JP4549855B2 (ja) データ記録方法、データ再生方法、データ記録装置、データ再生装置、データ構造、プログラム、およびそのプログラムを格納した記録媒体
JP3895305B2 (ja) データ記録方法、データ記録装置、およびデータ記録媒体
JP3986973B2 (ja) Avデータ記録方法、avデータ記録装置、データ記録媒体、及びプログラム
JP2002373480A (ja) データ記録方法及びデータ記録装置ならびに記録媒体
JP4409588B2 (ja) データ記録方法、データ削除方法、記録装置、記録媒体およびプログラム
JP4255796B2 (ja) データ記録装置、データ記録方法、データ記録プログラム、および該プログラムを記録した記録媒体
JP2003022621A (ja) データ記録方法、データ変更方法及びその装置
JP2003168284A (ja) データ記録方法およびデータ編集方法

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20060530

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20060731

RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20060731

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: 20060822

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20060823

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: 20090901

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100901

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20110901

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120901

Year of fee payment: 6

LAPS Cancellation because of no payment of annual fees