JP2003168283A

JP2003168283A - データ編集方法およびデータ記録媒体

Info

Publication number: JP2003168283A
Application number: JP2001363588A
Authority: JP
Inventors: Jiro Kiyama; 次郎木山; Hirotoshi Iwano; 裕利岩野; Takayoshi Yamaguchi; 孝好山口
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2001-11-29
Filing date: 2001-11-29
Publication date: 2003-06-13

Abstract

(57)【要約】【課題】少ないファイル数で非破壊編集に伴う再エン
コードデータを管理する。【解決手段】記録媒体上の既存のデータを格納した1
個以上の第1のファイルの再生方法を管理する管理情報
を第2のファイルに記録し、前記既存データと関連付け
られたデータを記録するデータ編集方法であって、前記
関連付けられたデータと前記管理情報とを同一ファイル
に格納する。なお、前記関連付けられたデータとは、第
1のファイルに含まれるデータを再エンコードしたデー
タ、或いは、第1のファイルに含まれるデータと同期再
生するデータである。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ハードディスク、
光ディスク等のランダムアクセス可能な記録媒体に対し
て、映像データ、音声データを記録・編集するデータ編
集方法に関するものである。

【０００２】

【従来の技術】ディスクメディアを用いたビデオのディ
ジタル記録再生装置（以下、ビデオディスクレコーダと
呼ぶ）が普及しつつある。テープメディアにはないディ
スクメディアにおける特徴機能として、非破壊編集機能
あるいはノンリニア編集機能と呼ばれるものがある。こ
の機能は、ディスク上に記録したAVストリームを移動あ
るいはコピーすることなく、AVストリームの任意の区間
（シーン）を任意の順番で再生できる、というもので、
AVストリームのどこからどこまでどういう順番で再生す
るかを示す情報（再生管理情報）を作り、その情報に従
って再生することで実現される。

【０００３】一般的に、ビデオディスクレコーダでのビ
デオの圧縮にはMPEG-2が用いられる。MPEG-2において
は、複数のフレーム（一般的には15フレーム程度）でGO
P（Group Of Pictures）が構成され、デコードはGOP単
位に行われる。そのため、非破壊編集において、シーン
再生開始フレームにGOPの途中のフレームが指定された
場合、シーン再生開始フレームの含まれるGOPの先頭か
らデコードし、シーン再生開始フレーム直前のフレーム
までのデコード結果は破棄するように制御する必要があ
る。

【０００４】この場合、破棄されるフレームのデータも
デコーダへ送り、デコードすることになるため、シーン
再生開始フレーム付近では単位時間あたりのデコーダへ
のデータ転送量およびデコーダの処理量が他の個所より
高くなり、処理が追いつかず再生に途切れが生じるおそ
れがある。また、指定されたシーン再生終了フレームが
GOPの途中のフレームであった場合、シーン再生終了フ
レーム以降のデコードを打ち切るように制御する必要が
ある。つまり、フレーム単位に繋ぎ目が指定された非破
壊編集結果を途切れなく再生しようとすると、複雑な制
御が要求されることになる。

【０００５】このような問題を解決するための一方法
が、特開2001-157145号公報に開示されている。以下、
図２９および図３０を用いてその概要を説明する。ここ
では、図２９に示すように、ビデオストリームが格納さ
れているファイル3001、3002があったとき、まず、ファ
イル3001をGOP3011中のフレーム3021まで再生し、次
に、ファイル3002をGOP3012中のフレーム3022から再生
する、という非破壊編集をすることを想定する。

【０００６】このとき、従来技術では、GOP3011をデコ
ードしフレーム3021までのフレーム列3031と、GOP3012
をデコードしフレーム3022からのフレーム列3032とを接
続し、フレーム列3033を作り、それをエンコードした結
果をファイル3003に格納する。このエンコードのことを
再エンコードと呼ぶ。それらの再生順や再生区間を管理
するための情報を、図３０に示すようにファイル3003に
格納する。

【０００７】再生は、ファイル3003に格納されている情
報を基にせず、ファイル3001のGOP3011の直前までのデ
ータ3041、次にファイル3003の全データ3042、最後にフ
ァイル3002のGOP3012の直後のデータ3043をデコーダに
順に送るだけでよく、デコード結果を破棄したり、デコ
ードの打ち切りのような複雑な制御は必要としない。な
ぜなら、デコーダに送られるビデオストリームには表示
を行うフレームデータしか含まれないようにしているか
らである。

【０００８】

【発明が解決しようとする課題】しかしながら、上述し
た従来技術においては、つなぎ目1箇所毎にファイルを
作成する必要がある。用いているファイルシステムにお
いては、扱うことができるファイル数が限られている場
合があり、その場合、ユーザが作成できる非破壊編集結
果の数が少なくなる。

【０００９】本発明は、上記課題を鑑みてなされたもの
であり、非破壊編集時における再エンコード区間を少な
いファイル数で管理することが可能なデータ編集方法を
提供することを目的とする。

【００１０】

【課題を解決するための手段】本願の第１の発明は、記
録媒体上の既存のデータを格納した1個以上の第1のファ
イルの再生方法を管理する管理情報を第2のファイルに
記録し、前記既存データと関連付けられたデータを記録
するデータ編集方法であって、前記関連付けられたデー
タと前記管理情報とを同一ファイルに格納することを特
徴とする。

【００１１】本願の第２の発明は、記録媒体上の既存の
データを格納した1個以上の第1のファイルの再生方法を
管理する管理情報を第2のファイルに記録し、前記既存
データと関連付けられたデータを記録するデータ編集方
法であって、前記関連付けられたデータと前記管理情報
とを前記記録媒体上の近傍に配置することを特徴とす
る。

【００１２】本願の第３の発明は、前記関連付けられた
データが、第1のファイルに含まれるデータを再エンコ
ードしたデータであることを特徴とする。

【００１３】本願の第４の発明は、前記関連付けられた
データは、第1のファイルに含まれるデータと同期再生
するデータであることを特徴とする。

【００１４】本願の第５の発明は、データを格納した1
個以上の第1のファイルと、前記第1のファイルの再生方
法を管理する管理情報を格納する第2のファイルと、前
記第1のファイルと関連付けられたデータとが記録され
たデータ記録媒体であって、前記第2のファイル中には
前記第1のファイルと関連付けられたデータが格納され
ていることを特徴とする。

【００１５】

【発明の実施の形態】以下、本発明の実施形態につい
て、図面を参照しながら詳細に説明する。ここでの説明
は、本発明において共通に用いる構成、個々の実施形態
に固有の内容という順に行っていく。

【００１６】＜システム構成＞図１は本発明において共
通に用いる、アフレコ可能なビデオディスクレコーダの
構成図である。この装置は、図１に示すように、バス10
0、ホストCPU101、RAM102、ROM103、ユーザインタフェ
ース104、システムクロック105、光ディスク106、ピッ
クアップ107、ECC(Error Correcting Coding)デコーダ1
08、ECCエンコーダ109、再生用バッファ110、記録/アフ
レコ用バッファ111、デマルチプレクサ112、マルチプレ
クサ113、多重化用バッファ114、オーディオデコーダ11
5、ビデオデコーダ116、オーディオエンコーダ117、ビ
デオエンコーダ118、および図示しないカメラ、マイ
ク、スピーカ、ディスプレイ等で構成される。

【００１７】ホストCPU101は、バス100を通じてデマル
チプレクサ112、マルチプレクサ113、ピックアップ10
7、また図示していないが、オーディオデコーダ115、ビ
デオデコーダ116、オーディオエンコーダ117、ビデオエ
ンコーダ118との通信を行う。

【００１８】再生時に、光ディスク106からピックアッ
プ107を通じて読み出されたデータは、ECCデコーダ108
によって誤り訂正され、再生用バッファ110に一旦蓄え
られる。デマルチプレクサ112はオーディオデコーダ11
5、ビデオデコーダ116からのデータ送信要求に従い、再
生用バッファ中のデータをその種別によって適当なデコ
ーダに振り分ける。

【００１９】一方、記録時に、オーディオエンコーダ11
7とビデオエンコーダ118によって圧縮符号化されたデー
タは、多重化用バッファ114に一旦送られ、マルチプレ
クサ113によってAV多重化され、記録/アフレコ用バッフ
ァ111に送られる。記録/アフレコ用バッファ111中のデ
ータは、ECCエンコーダ109によって誤り訂正符号を付加
され、ピックアップ107を通じて光ディスク106に記録さ
れる。

【００２０】オーディオデータの符号化方式にはMPEG-1
Layer-IIを、ビデオデータの符号化方式にはMPEG-2を
それぞれ用いる。

【００２１】光ディスク106は、外周から内周に向かっ
て螺旋状に記録再生が行われる脱着可能な光ディスクと
する。2048byteを1セクタとし、誤り訂正のため16セク
タでECCブロックを構成する。ECCブロック中のデータを
書き換える場合、そのデータが含まれるECCブロック全
体を読み込み、誤り訂正を行って、対象のデータを書き
換え、再び誤り訂正符号を付加し、ECCブロックを構成
して、記録媒体に記録する必要がある。また、光ディス
ク106は、記録効率を上げるためZCAV（ゾーン角速度一
定）を採用しており、記録領域は回転数の異なる複数の
ゾーンで構成される。

【００２２】＜ファイルシステム＞光ディスク106上の
各種情報を管理するためにファイルシステムを用いる。
ファイルシステムには、パーソナルコンピュータ（PC）
との相互運用を考慮してUDF（Universal Disk Format）
を使用する。ファイルシステム上では、各種管理情報や
AVストリームはファイルとして扱われる。

【００２３】ユーザエリアは、2048byteの論理ブロック
（セクタと一対一対応）で管理される。各ファイルは、
整数個のエクステント（連続した論理ブロック）で構成
され、エクステント単位で分散して記録しても良い。空
き領域は、Space Bitmapを用いて論理ブロック単位で管
理される。

【００２４】＜ファイルフォーマット＞AVストリーム管
理のためのフォーマットとして、QuickTimeファイルフ
ォーマットを用いる。QuickTimeファイルフォーマット
とは、Apple社が開発したマルチメディアデータ管理用
フォーマットであり、PCの世界で広く用いられている。

【００２５】QuickTimeファイルフォーマットは、ビデ
オデータやオーディオデータ等（これらを総称してメデ
ィアデータとも呼ぶ）と管理情報とで構成される。両者
を合わせてここでは、QuickTimeムービー（略してムー
ビー）と呼ぶ。両者は同じファイル中に存在しても、別
々のファイルに存在しても良い。

【００２６】同じファイル中に存在する場合は、図２
（a）に示すような構成をとる。各種情報はatomという
共通の構造に格納される。管理情報はMovie atomという
構造に格納され、AVストリームはMovie data atomとい
う構造に格納される。尚、Movieatom中の管理情報に
は、メディアデータ中の任意の時間に対応するAVデータ
のファイル中での相対位置を導くためのテーブルや、メ
ディアデータの属性情報や、後述する外部参照情報等が
含まれている。

【００２７】一方、管理情報とメディアデータを別々の
ファイルに格納した場合は、図２（b）に示すような構
成をとる。管理情報はMovie atomという構造に格納され
るが、AVストリームはatomには格納される必要はない。
このとき、Movie atomはAVストリームを格納したファイ
ルを「外部参照」している、という。

【００２８】外部参照は、図２（c）に示すように、複
数のAVストリームファイルに対して行うことが可能であ
り、この仕組みにより、AVストリーム自体を物理的に移
動することなく、見かけ上編集を行ったように見せる、
いわゆる「ノンリニア編集」「非破壊編集」が可能にな
る。

【００２９】それでは、図３乃至図１２を用いて、Quic
kTimeの管理情報のフォーマットについて説明する。ま
ず、共通の情報格納フォーマットであるatomについて説
明する。atomの先頭には、そのatomのサイズであるAtom
size、そのatomの種別情報であるTypeが必ず存在す
る。Typeは4文字で区別され、例えばMovie atomでは'mo
ov'、Movie data atomでは'mdat'となっている。

【００３０】各atomは別のatomを含むことができる。す
なわち、atom間には階層構造がある。Movie atomの構成
を図３に示す。Movie header atomは、そのMovie atom
が管理するムービーの全体的な属性を管理する。Track
atomは、そのムービーに含まれるビデオやオーディオ等
のトラックに関する情報を格納する。User data atom
は、独自に定義可能なatomである。

【００３１】Track atomの構成を図４に示す。Track he
ader atomは、そのトラックの全体的な属性を管理す
る。Edit atomは、メディアデータのどの区間を、ムー
ビーのどのタイミングで再生するかを管理する。Track
reference atomは、別のトラックとの関係を管理する。
Media atomは、実際のビデオやオーディオといったデー
タを管理する。

【００３２】Track header atomの構成を図５に示す。
ここでは、後での説明に必要なもののみについて説明す
る。flagsは属性を示すフラグの集合である。代表的な
ものとして、Track enabledフラグがあり、このフラグ
が1であれば、そのトラックは再生され、0であれば再生
されない。layerはそのトラックの空間的な優先度を表
しており、画像を表示するトラックが複数あれば、laye
rの値が小さいトラックほど画像が前面に表示される。

【００３３】Media atomの構成を図６に示す。Media he
ader atomは、そのMedia atomの管理するメディアデー
タに関する全体的な属性等を管理する。Handler refere
nceatomは、メディアデータをどのデコーダでデコード
するかを示す情報を格納する。Media information atom
は、ビデオやオーディオ等メディア固有の属性情報を管
理する。

【００３４】Media information atomの構成を図７に示
す。Media information header atomは、ビデオやオー
ディオ等メディア固有の属性情報を管理する。Handler
reference atomは、Media atomの項で説明した通りであ
る。Data information atomは、そのQuickTimeムービー
が参照するメディアデータを含むファイルの名前を管理
するatomであるData reference atomを含む。Sample ta
ble atomは、データのサイズや再生時間等を管理してい
る。

【００３５】次に、Sample table atomについて説明す
るが、その前に、QuickTimeにおけるデータの管理方法
について、図８を用いて説明する。QuickTimeでは、デ
ータの最小単位（例えばビデオフレーム）をサンプルと
呼ぶ。個々のトラック毎に、サンプルには再生時間順に
1から番号（サンプル番号）がついている。

【００３６】また、QuickTimeフォーマットでは、個々
のサンプルの再生時間長およびデータサイズを管理して
いる。また、同一トラックに属するサンプルが再生時間
順にファイル中で連続的に配置された領域をチャンクと
呼ぶ。チャンクにも再生時間順に、1から番号がついて
いる。

【００３７】さらに、QuickTimeフォーマットでは、個
々のチャンクのファイル先頭からのアドレスおよび個々
のチャンクが含むサンプル数を管理している。これらの
情報に基づき、任意の時間に対応するサンプルの位置を
求めることが可能となっている。

【００３８】Sample table atomの構成を図９に示す。S
ample description atomは、個々のチャンクのデータフ
ォーマット（Data format）やサンプルが格納されてい
るファイルのチャンクの Index等を管理する。Time-to-
sample atomは、個々のサンプルの再生時間を管理す
る。

【００３９】Sync sample atomは、個々のサンプルのう
ち、デコード開始可能なサンプルを管理する。Sample-t
o-chunk atomは、個々のチャンクに含まれるサンプル数
を管理する。Sample size atomは、個々のサンプルのサ
イズを管理する。Chunk offset atomは、個々のチャン
クのファイル先頭からのアドレスを管理する。

【００４０】Edit atomは、図１０に示すように、1個の
Edit list atomを含む。Edit listatomはNumber of ent
riesで指定される個数分の、Track duration、Media ti
me、Media rateの値の組（エントリ）を持つ。各エント
リは、トラック上で連続的に再生される区間に対応し、
そのトラック上での再生時間順に並んでいる。

【００４１】Track durationはそのエントリが管理する
区間のトラック上での再生時間、Media timeはそのエン
トリが管理する区間の先頭に対応するメディアデータ上
での位置、Media rateはそのエントリが管理する区間の
再生スピードを表す。尚、Media timeが-1の場合は、そ
のエントリのTrack duration分、そのトラックでのサン
プルの再生を停止する。この区間のことをempty editと
呼ぶ。

【００４２】図１１にEdit listの使用例を示す。ここ
では、Edit list atomの内容が図１１（a）に示す内容
であり、さらにサンプルの構成が図１１（b）であった
とする。尚、ここではi番目のエントリのTrack duratio
nをD(i)、Media timeをT(i)、Media rateをR(i)とす
る。このとき、実際のサンプルの再生は、図１１（c）
に示す順に行われる。このことについて簡単に説明す
る。

【００４３】まず、エントリ#1はTrack durationが1300
0、Media timeが20000、Media rateが1であるため、そ
のトラックの先頭から13000の区間はサンプル中の時刻2
0000から33000の区間を再生する。次に、エントリ#2はT
rack durationが5000、Mediatimeが-1であるため、トラ
ック中の時刻13000から18000の区間、何も再生を行わな
い。

【００４４】最後に、エントリ#3はTrack durationが10
000、Media timeが0、Media rateが1であるため、トラ
ック中の時刻18000から28000の区間において、サンプル
中の時刻0から10000の区間を再生する。

【００４５】図１２にUser data atomの構成を示す。こ
のatomには、QuickTimeフォーマットで定義されてない
独自の情報を任意個数格納することができる。1個の独
自情報は1個のエントリで管理され、1個のエントリはSi
zeとTypeとUser dataで構成される。Sizeはそのエント
リ自体のサイズを表し、Typeは独自情報をそれぞれ区別
するための識別情報、User dataは実際のデータを表
す。

【００４６】＜AVストリームの形態＞まず、本実施例に
おけるAVストリームの構成について、図１３及び図１４
を用いて説明する。AVストリームは整数個のRecord Uni
t（RU）で構成される。RUはディスク上で連続的に記録
する単位である。RUの長さは、AVストリームを構成する
RUをどのようにディスク上に配置してもシームレス再生
（再生中に画像や音声が途切れないで再生できること）
やリアルタイムアフレコ（アフレコ対象のビデオをシー
ムレス再生しながらオーディオを記録すること）が保証
されるように設定される。この設定方法については後述
する。

【００４７】また、RU境界がECCブロック境界と一致す
るようにストリームを構成する。RUのこれらの性質によ
って、AVストリームをディスクに記録した後も、シーム
レス再生を保証したまま、ディスク上でRU単位の配置を
容易に変更することができる。

【００４８】RUは、整数個のVideo Unit（VU）で構成さ
れる。VUは単独再生可能な単位であり、そのことから再
生の際のエントリ・ポイントとなりうる。

【００４９】VU構成を図１４に示す。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（S
H）を置く。VUの再生時間は、VUに含まれるビデオフレ
ーム数にビデオフレーム周期をかけたものと定義する。
さらに、VUを整数個組み合わせてRUを構成する場合、RU
の始終端をECCブロック境界に合わせるため、VUの末尾
を0で埋める。

【００５２】＜AVストリーム管理方法＞AVストリームの
管理方法は、前述のQuickTimeファイルフォーマットを
ベースにしている。図１５にAVストリーム管理形態を示
す。ビデオトラックは、各ビデオフレームを1サンプル
（ビデオサンプル）、VU中のビデオの塊を1チャンク
（ビデオチャンク）として管理する。メインオーディオ
トラックは、AAUを1サンプル（オーディオサンプル）、
VU中のオーディオの塊を1チャンク（オーディオチャン
ク）として管理する。

【００５３】＜RU単位決定方法＞次に、RU単位決定方法
について説明する。この決定方法では、基準となるデバ
イス(リファレンス・デバイス・モデル)を想定し、その
上でシームレス再生が破綻しないように連続記録単位を
決める。

【００５４】それではまず、リファレンス・デバイス・
モデルについて、図１６を用いて説明する。リファレン
ス・デバイス・モデルは１個のピックアップとそれにつ
ながる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、T
a=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＞中のTr(i)に、Tr(i)=Tc(i)×(Rv+R
a)/Rsを代入して、Tc(i)で解くとシームレス再生を保証
可能なTc(i)の条件 Tc(i)≧(Ta×Rs)/(Rs-Rv-Ra)・・・＜式２＞が得られる。

【００６４】つまり、各連続領域に先頭の含まれるVUの
合計が上式を満たすようにすれば、シームレス再生を保
証可能である。このとき、各連続領域には合計の再生時
間が上式を満たす完全なVU群を含むように制限しても良
い。

【００６５】自動分割ムービーファイルでも＜式２＞を
満たす必要がある。ただし、先頭の自動分割ムービーの
最初のRUおよび末尾の自動分割ムービーの最後のRUは＜
式２＞を満たさなくてもよい。なぜなら、先頭は記録媒
体からのデータ読み出し開始より再生開始を遅らせるこ
とにより吸収でき、末尾については次に続くデータがな
いため、連続再生を気にする必要が無いからである。こ
のように先頭と末尾において条件を緩めることにより、
短い空き領域を有効利用できる。

【００６６】＜インデックス・ファイル＞ディスク内に
含まれるQuickTimeムービーや静止画データ等を含む各
種コンテンツ（以後、AVファイルと呼ぶ）を管理するた
め、AV Indexファイルという特別のQuickTimeムービー
ファイルをディスク内に１個置く。

【００６７】図１７に、AV Indexファイルの構成を示
す。AV Indexファイルは通常のQuickTimeムービーファ
イルと同様、管理情報であるMovie atom1791とデータ自
体のMovie data atom1792で構成される。AV Indexファ
イルは、複数のエントリを管理し、ディスク内の各AVフ
ァイルはそれぞれ1個のエントリで管理される。さら
に、各AVファイルをまとめるための入れ物（以後フォル
ダと呼ぶ）等もそれぞれ1個のエントリで管理する。

【００６８】Movie atom1791は、各エントリの属性情報
を管理するためのProperty track1793、各エントリのタ
イトル文字列データを管理するためのTitle track179
4、各エントリのサムネイル画像データを管理するため
のThumbnail track1795、各エントリの代表オーディオ
データを管理するためのIntro music track1796の計4種
類のトラックで構成される。

【００６９】各エントリに関する属性情報は、それぞれ
の1792〜1795のトラックのサンプルとして管理される。
例えばAVファイル1740に関する属性情報はProperty tra
ck1793上のサンプル1701、タイトル文字列データはTitl
e track1794上のサンプル1711、サムネイル画像データ
はThumbnail track1795上のサンプル1721、代表オーデ
ィオデータはIntro music track1796上のサンプル1731
で管理する。サンプル間の対応付けは、各サンプルの再
生開始時間に基づき行う。すなわち、トラック間で同一
時刻に位置するサンプルが同一エントリに対応している
と判断する。

【００７０】Movie data atom1793は、各AVファイルに
関する属性情報や、タイトル文字列データ、サムネイル
画像データ、代表オーディオデータを格納する。属性情
報は図１８に示す構成を取る。各フィールドについて説
明する。versionは、ファイルフォーマットのバージョ
ンを示す。pe-flagsは各種フラグをまとめたものであ
り、詳細は後述する。

【００７１】parent-entry-numberは、属性情報に対応
するエントリが属するフォルダに対応するエントリのen
try-numberを格納、entry-numberは、属性情報に対応す
るエントリのentry-numberを格納する。この2個の情報
で、ファイルとフォルダの包含関係を表す。set-depend
ent-flagsおよびuser-private-flagsについては、説明
を省略する。

【００７２】creation-timeおよびmodification-timeは
この属性情報に対応するエントリが作成された日時、修
正された日時を表す。durationはこの属性情報に対応す
るエントリの再生時間を表す。binary-file-identifier
は、この管理情報に対応するエントリがファイルに対応
していた場合、そのファイルのパス名を固定長にエンコ
ーディングしたもので、詳細についての説明は省略す
る。

【００７３】referred-counterはこの属性情報に対応す
るエントリが管理するファイルが他のファイルから参照
されている回数を格納する。referring file listは、
実際に参照しているファイルのパス名のリストを格納す
る。URL file identifierは、管理するファイルが上記
のbinary-file-identifierにエンコードできない場合に
URL（Unified Resource Locator）形式で、ファイルの
パスを格納する。

【００７４】＜第１の実施形態＞本発明の第１の実施形
態について、非破壊編集を行う場合の処理について図１
９から図２６を用いて説明する。ここでは、図１９に示
すように、AVストリームが格納されているQuickTimeフ
ァイル2001、2002があったとき、まず、ファイル2001を
VU2011中のGOP列2051中のフレーム2021まで再生し、次
に、ファイル2002をVU2012中のGOP列2052中のフレーム2
022から再生する、というGOPの途中で繋ぐ非破壊編集を
することを想定する。なお、Movie atom2041、2042はそ
れぞれ、ファイル2001、2002を再生するための管理情報
である。

【００７５】以下では、まずAVストリームに関する処理
について説明し、次に管理情報に関する処理について説
明する。

【００７６】＜非破壊編集処理：AVストリームに関する
処理＞非破壊編集時のAVストリームに関する処理につい
て、図２０を用いて説明する。前述のVU2011からGOP列2
051、VU2012からGOP列2052を抜き出し、ビデオデコーダ
116でそれぞれビデオフレーム列2031、2032にデコード
する。

【００７７】次に、デコードされたビデオフレーム列20
31中のビデオフレーム202１までの部分ビデオフレーム
列2033からビデオエンコーダ116でエンコード（再エン
コード）し、GOP列2053を作成し、部分ビデオフレーム
列2033に時間的に対応する部分AAU列2071と結合するこ
とでVU2013を作成する。

【００７８】同時に、デコードされたビデオフレーム列
2032中のビデオフレーム2022以降の部分ビデオフレーム
列2034に関してはビデオエンコーダ116でエンコード
（再エンコード）し、GOP列2054を作成し、部分ビデオ
フレーム列2034に時間的に対応する部分AAU列2072と結
合することでVU2014を作成する。すなわち2個のVUを作
成する。

【００７９】このとき、2個のVUではなく1個のVUにまと
めることも考えられるが、以下に説明する理由により、
2個のVUで構成することにする。1個のVUにまとめる場合
の手順を図２１に示す。部分ビデオフレーム列2033と20
34を結合し、ビデオフレーム列2035を作成し、それをエ
ンコードした結果のGOP列2055と、部分AAU列2071と2072
を繋げた結果であるAAU列2075を結合することでVU2015
を作成する。

【００８０】この場合の問題点として、つなぎ目におい
て、オーディオ、ビデオのいずれかに時間的隙間が発生
する。なぜなら、図２２に示すように、ビデオフレーム
周期2081とAAU周期2082が整数倍の関係になっていない
ため、部分ビデオフレーム列2083と部分ビデオフレーム
列2084を時間的隙間無く再生しようとすると、部分AAU
列2071と2072のつなぎ目において隙間2083ができること
になる。

【００８１】2個のVUの場合でもこの隙間2083はできる
が、1個のVUの場合、VUの途中に隙間2083が発生するた
め、VU単位に移動を行う場合を考えた場合、処理が複雑
化する可能性がある。そのため2個のVUで構成すること
にする。

【００８２】＜非破壊編集処理：管理情報に関する処理
＞非破壊編集時の管理情報に関する処理について、図２
３を用いて説明する。まず、ファイル2001のMovie atom
2041からVU2011直前までのVU列に関する情報を取得す
る。同様に、ファイル2002のMovie atom2042 のSample
table atomから、VU2012直後より後のVU列に関する情報
を取得する。

【００８３】次に、新規に作成した前述のVU2013とVU20
14に関して、Sample table作成に必要な情報、具体的に
はビデオチャンク、オーディオチャンクのデータサイズ
および再生時間等を取得する。それらの情報を元に非破
壊編集結果に関するSample table atomをビデオトラッ
ク、オーディオトラックそれぞれについてRAM102上で再
構築する。

【００８４】次に、前記Sample table atom中のサンプ
ルを順に隙間無く再生するようにEdit list atomを構成
する。ただし、VU2013とVU2014のつなぎ目に関しては、
VU2014以降が正しくAV同期再生可能なように、前述のよ
うにオーディオトラックに関して、無再生区間を挿入す
る必要がある。これらの情報を基に、非破壊編集結果に
関するMovie atom2043を作成し、VU2013およびVU2014と
共にファイル2003にまとめる。ファイル2003を記録する
際には、記録媒体上で連続的に配置されるように記録す
る。

【００８５】このように非破壊編集に伴い再エンコード
したデータと非破壊編集結果に関する管理情報を1個の
ファイルにまとめることによって、次のようなメリット
が生じる。まず、ファイル数の増加が抑えられる点であ
る。ファイルシステムによっては管理可能なファイル数
の上限が存在するため、そのようなファイルシステムに
おいてはファイル数が少なくて済むということは、より
多数のコンテンツを記録できることを意味する。なお、
本実施形態ではファイル2003を記録する際、連続的に記
録しているが、連続的でなくてもファイル数増加抑制の
効果があることは言うまでもない。

【００８６】なお、本実施形態では、つなぎ目を含むVU
（VU2011とVU2012）のみを抜き出して１個のファイル20
03にまとめたが、非破壊編集結果がシームレス再生可能
なよう、ファイル2003中のAVデータが前述の＜式２＞を
満たすようにつなぎ目を含むVU以外のVUも抜き出すこと
も考えられる。

【００８７】図２４を用いて説明する。VU2011はRU2101
に含まれ、VU2012はRU2102に含まれるとする。このと
き、RU2101に含まれるVU2011直前のVU列2103と再エンコ
ードしたVU2013とVU2014とRU2102に含まれるVU2012より
後のVU列2112の合計の再生時間が＜式２＞を満たすので
あれば、ファイル2003にVU列2103、VU2013、VU2014、VU
列2112を記録媒体上で連続に格納する。仮に＜式２＞に
満たないのであれば、RU2101の直前のRUであるRU2103も
コピーする。このことにより、ファイル2003が＜式２＞
を満たし、非破壊編集結果に関してもシームレス再生を
保証することが可能になる。

【００８８】＜再生時の処理＞非破壊編集結果ファイル
2003の再生が指示された場合、まず、Movie atom2043を
光ディスク106からRAM102上に読み出す。読み出したMov
ie atomの情報に基づき、再生順に、VU列2091、VU201
3、VU2014、VU列2092の順（図２５中の(1)〜(5)の順）
に光ディスク106から再生用バッファ110に読み出してい
く。

【００８９】再生用バッファ110に読み出されたAVデー
タは、Movie atomの情報に基づき、デマルチプレクサ11
2によって、オーディオデータとビデオデータに分けら
れ、それぞれオーディオデコーダ115、ビデオデコーダ1
16に送られる。オーディオデコーダ115、ビデオデコー
ダ116はMovie atomの情報に基づくホストCPU101からの
制御により、同期を取って再生を行う。

【００９０】このとき、図２６の（1）〜（5）に示す順
番で読み出しを行う、すなわち、VU2013、VU2014、VU列
2091、VU列2092の順に行うことも考えられる。VU2013お
よびVU2014は実際にはVU列2091の後に再生されるため、
VU列2091の再生が終わるまで再生用バッファ110にVU201
3およびVU2014から読み出したデータを保持しておき、V
U列2091の再生が終了すると同時に、再生を行う。

【００９１】このようにすることで、再生順に読み出し
た場合と比較して、シーク回数が1回減るため、シーク
に伴うモーターの消費電力が削減できる。非破壊編集結
果の管理情報と再エンコードデータをディスク上で物理
的に連続的に記録しておくことで、上述の効果を実現可
能である。なお、非破壊編集結果の管理情報と再エンコ
ードデータは連続してなくとも近傍に配置されていれば
同様の効果を実現可能なのは言うまでもない。

【００９２】＜第２の実施形態＞本実施形態では、オリ
ジナルデータファイルに影響を与えず、部分的な区間に
エフェクトをかける処理について、図２７を用いて説明
する。ここでは、オリジナルデータがファイル2201に格
納されており、区間2221に対してエフェクト（例えばモ
ザイク）をかけることを想定する。

【００９３】このとき、区間2221を含むRU列2232中のGO
P列をデコードし、生成された非圧縮ビデオフレームデ
ータに対し、指定区間に対しエフェクトを施し、エフェ
クト結果に対してエンコードを行い、RU列2234を再構成
する。RU列2234はMovie atom2212と共に1個のファイル2
202に格納する。

【００９４】Movie atom2212には、RU列2231、RU列223
4、RU列2233の順に再生するように管理情報を格納す
る。なおRU列2234は記録媒体上で連続的に配置されるよ
う記録する。

【００９５】以上の構成により、上述した第１の実施形
態と同様、ファイルを1個増やすのみでオリジナルデー
タファイルに影響を与えることなく、しかもオリジナル
データをすべてコピーすることなく部分的な区間に対し
エフェクトをかけることが可能となる。また、ファイル
2202に格納するデータはRUを考慮しているため、エフェ
クト結果もシームレス再生を保証することが可能であ
る。なお、本実施形態ではＲＵ列2234を記録する際、連
続的に記録しているが、連続的でなくてもファイル数増
加抑制の効果があることは言うまでもない。

【００９６】＜第３の実施形態＞本実施形態では、オリ
ジナルデータに影響を与えず、オーディオアフターレコ
ーディング（アフレコ）を行う処理について、図２８を
用いて説明する。ここでは、オリジナルデータ2321がフ
ァイル2301に格納されており、任意の区間に対してアフ
レコを行うことを想定する。

【００９７】このとき、アフレコ時に入力されたオーデ
ィオデータ2322をファイル2302に、Movie atom2312と共
に格納する。Movie atom2312には、オリジナルデータ23
21とオーディオデータ2322を同期再生するように管理情
報を格納する。Movie atom2312とオーディオデータ2322
は記録媒体上で連続的に配置されるように記録する。

【００９８】以上の構成により、上述した第１の実施形
態と同様、ファイルを1個増やすのみでオリジナルデー
タに影響を与えることなく、アフレコデータを管理する
ことが可能となる。なお、本実施形態ではMovie atom23
12とオーディオデータ2322を記録する際、連続的に記録
しているが、連続的でなくてもファイル数増加抑制の効
果があることは言うまでもない。

【００９９】また、Movie atom2312とオーディオデータ
2322は記録媒体上で連続的に配置されていることによ
り、Movie atom2312とオーディオデータ2322をシークす
ることなく連続的に読み込むことができるため、ユーザ
からの再生指示から実際に再生が開始されるまでの間、
時間を要することなく、さらに再生中にオーディオデー
タ2322へのシークを行うことなく、オーディオデータ23
22とオリジナルデータ2321との同期再生が可能となる。

【０１００】

【発明の効果】以上説明したように、本発明によれば、
非破壊編集時に再エンコードしたデータを非破壊編集結
果の管理情報と同じファイルに格納することで、オリジ
ナルデータファイルを書きかえず、しかもファイル数の
増加を1個のみに抑えることが可能となる。

【０１０１】また、本発明によれば、非破壊編集時に再
エンコードしたデータを非破壊開編集結果の管理情報と
記録媒体上で近傍に記録することで、再生時のアクセス
を減少することが可能になる。

【図面の簡単な説明】

【図１】本発明の実施形態における概略構成を示すブロ
ック図である。

【図２】QuickTimeファイルフォーマットにおける管理
情報とAVストリームとの関係を示す説明図である。

【図３】QuickTimeファイルフォーマットにおけるMovie
atomの概要を示す説明図である。

【図４】QuickTimeファイルフォーマットにおけるTrack
atomの概要を示す説明図である。

【図５】QuickTimeファイルフォーマットにおけるTrack
header atomの構成を示す説明図である。

【図６】QuickTimeファイルフォーマットにおけるMedia
atomの構成を示す説明図である。

【図７】QuickTimeファイルフォーマットにおけるMedia
information atomの構成を示す説明図である。

【図８】Sample table atomによるデータ管理の例を示
す説明図である。

【図９】QuickTimeファイルフォーマットにおけるSampl
e table atomの構成を示す説明図である。

【図１０】QuickTimeファイルフォーマットにおけるEdi
t atomの構成を示す説明図である。

【図１１】Edit atomによる再生範囲指定の例を示す説
明図である。

【図１２】QuickTimeファイルフォーマットにおけるUse
r data atomの構成を示す説明図である。

【図１３】本発明におけるAVストリームの構成を示す説
明図である。

【図１４】本発明におけるVUの構造を示す説明図であ
る。

【図１５】本発明におけるAVストリーム管理形態を示す
説明図である。

【図１６】本発明におけるリファレンス・デバイス・モ
デルを示す説明図である。

【図１７】本発明におけるAV Indexの構成を示す説明図
である。

【図１８】本発明におけるAV Index中の属性情報の構成
を示す説明図である。

【図１９】本発明の第１の実施形態における、非破壊編
集の条件を示す説明図である。

【図２０】本発明の第１の実施形態における、第1の再
エンコード方法を示す説明図である。

【図２１】本発明の第１の実施形態における、第2の再
エンコード方法を示す説明図である。

【図２２】本発明の第１の実施形態における、つなぎ目
のオーディオ・ビデオ間の時間的不整合を示す説明図で
ある。

【図２３】本発明の第１の実施形態における、非破壊編
集結果の第1の管理方法を示す説明図である。

【図２４】本発明の第１の実施形態における、非破壊編
集結果の第２の管理方法を示す説明図である。

【図２５】本発明の第１の実施形態における、再生処理
時の第1の読み出し順を示す説明図である。

【図２６】本発明の第１の実施形態における、再生処理
時の第２の読み出し順を示す説明図である。

【図２７】本発明の第２の実施形態における、非破壊編
集結果の管理方法を示す説明図である。

【図２８】本発明の第３の実施形態における、アフレコ
結果の管理方法を示す説明図である。

【図２９】従来技術における再エンコード方法を示す説
明図である。

【図３０】従来技術における非破壊編集結果の管理方法
を示す説明図である。

【符号の説明】

100 バス 101 ホストCPU 102 RAM 103 ROM 104 ユーザインタフェース 105 システムクロック 106 光ディスク 107 ピックアップ 108 ECCデコーダ 109 ECCエンコーダ 110 再生用バッファ 111 記録/アフレコ用バッファ 112 デマルチプレクサ 113 マルチプレクサ 114 多重化用バッファ 115 オーディオデコーダ 116 ビデオデコーダ 117 オーディオエンコーダ 118 ビデオエンコーダ

───────────────────────────────────────────────────── フロントページの続き (72)発明者山口孝好大阪府大阪市阿倍野区長池町22番22号シャープ株式会社内Ｆターム(参考） 5C053 FA14 FA23 GA11 GB15 GB37 5D044 AB07 BC04 CC06 DE32 DE48 GK12 GM21 HL16 5D110 AA14 AA29 BB01 BB20 CA05 CA06 CA31 CB08 CC06 CF21 DA12 DB03 DC05 DC16 DE01

Claims

【特許請求の範囲】

【請求項１】記録媒体上の既存のデータを格納した1
個以上の第1のファイルの再生方法を管理する管理情報
を第2のファイルに記録し、前記既存データと関連付け
られたデータを記録するデータ編集方法であって、前記関連付けられたデータと前記管理情報とを同一ファ
イルに格納することを特徴とするデータ編集方法。
【請求項２】記録媒体上の既存のデータを格納した1
個以上の第1のファイルの再生方法を管理する管理情報
を第2のファイルに記録し、前記既存データと関連付け
られたデータを記録するデータ編集方法であって、前記関連付けられたデータと前記管理情報とを前記記録
媒体上の近傍に配置することを特徴とするデータ編集方
法。
【請求項３】前記請求項１又は２に記載のデータ編集
方法において、前記関連付けられたデータは、第1のファイルに含まれ
るデータを再エンコードしたデータであることを特徴と
するデータ編集方法。
【請求項４】前記請求項１又は２に記載のデータ編集
方法において、前記関連付けられたデータは、第1のファイルに含まれ
るデータと同期再生するデータであることを特徴とする
データ編集方法。
【請求項５】データを格納した1個以上の第1のファイ
ルと、前記第1のファイルの再生方法を管理する管理情
報を格納する第2のファイルと、前記第1のファイルと関
連付けられたデータとが記録されたデータ記録媒体であ
って、前記第2のファイル中には前記第1のファイルと関連付け
られたデータが格納されていることを特徴とするデータ
記録媒体。