(57)【要約】少なくとも映像又は音声の単独再生可能なビデオユニット（ＶＵ）を含む複数のレコードユニット（ＲＵ）で構成されるＡＶストリームと、前記ＡＶストリームを管理するプログラム情報（Ｍｏｖｉｅ  ａｔｏｍ）と、を、記録媒体に記録し、前記プログラム情報にレコードユニット又はＡＶストリーム間の結合箇所を管理する情報（Ｅｄｉｔ  ｌｉｓｔ  ａｔｏｍ）を有する。ＡＶストリームの復号において、結合箇所管理情報に基づいて、結合箇所では、例えば、復号の一時停止や復号器の切り替えを行う。
2002104016.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも映像又は音声からなる第１のデータを含む複数の第１のユニットで構成される第２のユニットと、前記第２のユニットを管理する第１のプログラムとを、記録媒体に記録するデータ記録方法であって、
前記第１のプログラムが、前記第１のユニット間の結合箇所を管理する情報を有することを特徴とするデータ記録方法。
【請求項２】
前記結合箇所は、前記第２のユニット中から任意の前記第１のデータを削除した箇所であることを特徴とする前記請求の範囲第１項に記載のデータ記録方法。
【請求項３】
前記第２のユニットは、１個のファイルで管理されることを特徴とする前記請求の範囲第１項又は２項に記載のデータ記録方法。
【請求項４】
前記映像の第１のデータは、該映像をＭＰＥＧ規格により符号化したものであることを特徴とする前記請求の範囲第１項乃至第３項に記載のデータ記録方法。
【請求項５】
少なくとも映像又は音声からなる第１のデータを含む第１のユニットと、少なくとも映像又は音声からなる第２のデータを含む第３のユニットとを接続して、第２のユニットを作成するデータ編集方法であって、
前記第２のユニットを管理する第１のプログラムが、前記第１のユニットと前記第３のユニットとの結合箇所を管理する情報を有することを特徴とするデータ編集方法。
【請求項６】
前記第１のユニットと前記第３のユニットは、前記第２のユニット中の任意の前記第１のデータを削除することによって形成されることを特徴とする前記請求の範囲第５項に記載のデータ編集方法。
【請求項７】
前記第２のユニットは、１個のファイルで管理されることを特徴とする前記請求の範囲第５項又は６項に記載のデータ編集方法。
【請求項８】
前記映像の第１、第２のデータは、該映像をＭＰＥＧ規格により符号化したものであることを特徴とする前記請求の範囲第５項乃至第７項に記載のデータ編集方法。
【請求項９】
少なくとも映像又は音声からなる第１のデータを含む複数の第１のユニットで構成される第２のユニットを、該第２のユニットを管理する第１のプログラムに従って復号するデータ復号方法であって、
前記第１のプログラムが、前記第１のユニット間の結合箇所を管理する情報を有し、
前記結合箇所情報に基づき、前記第１のユニットの復号を制御することを特徴とするデータ復号方法。
【請求項１０】
前記第１のユニットの復号の制御は、前記結合箇所において復号を一時停止することを特徴とする前記請求の範囲第９項に記載のデータ復号方法。
【請求項１１】
前記第１のユニットの復号の制御は、前記結合箇所の前後で復号器を切り替えることを特徴とする前記請求の範囲第９項に記載のデータ復号方法。
【請求項１２】
前記映像の第１，第２のデータは、該映像をＭＰＥＧ規格により符号化したものであることを特徴とする前記請求の範囲第９乃至１１項に記載のデータ復号方法。
【請求項１３】
少なくとも映像又は音声からなる第１のデータを含む複数の第１のユニットで構成される第２のユニットと、前記第２のユニットを管理する第１のプログラムとを、記録媒体に記録するデータ記録装置であって、
前記第１のプログラムが、前記第１のユニット間の結合箇所を管理する情報を有することを特徴とするデータ記録装置。
【請求項１４】
少なくとも映像又は音声からなる第１のデータを含む第１のユニットと、少なくとも映像又は音声からなる第２のデータを含む第３のユニットとを接続して、第２のユニットを作成するデータ編集装置であって、
前記第２のユニットを管理する第１のプログラムが、前記第１のユニットと第３のユニットとの結合箇所を管理する情報を有することを特徴とするデータ編集装置。
【請求項１５】
少なくとも映像又は音声からなる第１のデータを含む複数の第１のユニットで構成される第２ユニットを、該第２のユニットを管理する第１のプログラムに従って復号するデータ復号装置であって、
前記第１のプログラムが、前記第１のユニットの結合箇所情報を管理し、
前記結合箇所情報に基づき、復号の制御を行う前記第１のユニットの復号器を備えたことを特徴とするデータ復号装置。
【発明の詳細な説明】
技術分野
本発明は、映像データ、音声データをハードディスク、光ディスク等のランダムアクセス可能な記録媒体に対して記録・再生するデータ記録方法、データ編集方法およびデータ復号方法、及びその装置に関するものである。
背景技術
ディスクメディアを用いたビデオや音声のディジタル記録再生装置が普及しつつある。テープメディアにはないディスクメディアにおける特徴機能として、非破壊編集機能あるいはノンリニア編集機能と呼ばれるものがある。この機能は、ディスク上に記録したＡＶストリームを移動あるいはコピーすることなく、ＡＶストリームの任意の区間を任意の順番で再生できる、というもので、ＡＶストリームのどこからどこまでどういう順番で再生するかを示す情報（再生管理情報）を作り、その情報に従って再生することで実現される。
このようなディスクメディアでは、素材を書き換えたりデータを移動することなく、編集を行うことが可能なわけであるが、素材を直接編集したい場合もある。例えば、非破壊編集した結果を、パーソナル・コンピュータ（ＰＣ）で扱いやすいように１個のファイルにまとめたいとする。この場合、編集結果で使用されている部分のみを個々のＡＶストリームから抜き出し結合して１個のファイルにまとめることになる。
次のような場合もある。ディスクの空き容量を増やすため、ＡＶストリーム中の不要な中間部分を削除したいとする。この場合、中間部分の前後を結合することになる。
以上のような場合、ＡＶストリーム同士を繋ぎあわせることになる訳であるが、ビデオデータの符号化方式にＭＰＥＧビデオ規格（ＩＳＯ／ＩＥＣ  １１１７２−２やＩＳＯ／ＩＥＣ  １３８１８−２）を用いた場合、繋ぎ目において再生が乱れるおそれがある。
その理由について、以下に説明する。ＭＰＥＧビデオ規格では可変長符号化を採用しており、符号化データを所定のレートで符号化する場合、ＶＢＶ（Ｖｉｄｅｏ  Ｂｕｆｆｅｒｉｎｇ  Ｖｅｒｉｆｉｅｒ）と呼ばれる仮想デコーダモデルを符号化器の出力に接続して使用し、そのデコードバッファ（ＶＢＶバッファ）がオーバーフローもアンダーフローも発生しないように符号化することが規定されている。
このモデルでは、上記の所定レート以下で符号化データがＶＢＶバッファに入力され、そのレートでＶＢＶバッファのデータ占有量が増加する。その一方、フレームあるいはフィールドの復号が終了する毎、一瞬でその符号化データ量分、データ占有量が減少する。
ＭＰＥＧビデオによる符号化データは、このような増加・減少を繰り返しても、図２２に示すようなＶＢＶバッファがアンダーフローやオーバーフローを起こさないように制御して符号化されなければ、正常な再生は保証されない。ビデオデータを繋ぎ合わせた場合に、再生が乱れるおそれがあるのは、繋ぎ合わせた箇所において、ＶＢＶバッファがアンダーフローやオーバーフローしてしまうおそれがあるためである。
繋ぎ合わせた箇所でＶＢＶバッファが破綻する理由について、例を挙げて説明する。ここでは、ＶＢＶバッファの占有量の時間遷移がそれぞれ図２３（ａ）に示すビデオ符号化データＡの時間ＯＵＴの前半部と、図２３（ｂ）に示すビデオ符号化データＢの時間ＩＮの後半部とを結合する場合について説明する。
図２３（ｃ）にその結果を示す。結合点直前のバッファ占有量が低いのにも関わらず、結合点直後で符合化データ量の大きいフレームあるいはフィールドの復号が発生しているため、バッファのアンダーフローが発生していることがわかる。このようなことが発生するのは、繋ぎ目においてはバッファ占有量の整合が取れない可能性があるためである。
上述の問題を解決する方法として、例えば特開平９−１８２０２４号公報では、復号器の入力データの転送速度を高めることにより、アンダーフローを防止する技術が提案されている。しかしながら、この場合、特殊な復号器を用意する必要があり、コストの面で不利になるという問題点がある。
また別の方法として、例えば特開平８−２５１５８２号公報では、結合の際に繋ぎ目の部分を一旦復号し、ＶＢＶバッファが破綻しないような符号化データ量になるように符号化し直す技術（再符号化）が提案されている。しかしながら、この場合においては、再符号化により画質が低下するおそれがあり、さらに符号化と復号を逐次的あるいは並列的に行う必要あるため、装置が複雑化するという問題も孕んでいる。
本発明は、上記課題に鑑みてなされたものであり、ＡＶストリームを繋ぎ合わせて構成されたＡＶストリームを再生する際に、再生の乱れが生じるのを、簡単な構成にて防止することが可能なデータ記録方法、データ編集方法、データ復号方法、データ記録装置、及びデータ復号装置を提供することを目的とする。
発明の開示
本願の第１の発明は、少なくとも映像又は音声からなる第１のデータを含む複数の第１のユニットで構成される第２のユニットと、前記第２のユニットを管理する第１のプログラムとを、記録媒体に記録するデータ記録方法であって、前記第１のプログラムが、前記第１のユニット間の結合箇所を管理する情報を有することを特徴とする。
本願の第２の発明は、前記結合箇所は、前記第２のユニット中から任意の前記第１のデータを削除した箇所であることを特徴とする。
本願の第３の発明は、前記第２のユニットは、１個のファイルで管理されることを特徴とする。
本願の第４の発明は、前記映像の第１のデータは、該映像をＭＰＥＧ規格により符号化したものであることを特徴とする。
本願の第５の発明は、少なくとも映像又は音声からなる第１のデータを含む第１のユニットと、少なくとも映像又は音声からなる第２のデータを含む第３のユニットとを接続して、第２のユニットを作成するデータ編集方法であって、前記第２のユニットを管理する第１のプログラムが、前記第１のユニットと前記第３のユニットとの結合箇所を管理する情報を有することを特徴とする。
本願の第６の発明は、前記第１のユニットと前記第３のユニットは、前記第２のユニット中の任意の前記第１のデータを削除することによって形成されることを特徴とする。
本願の第７の発明は、前記第２のユニットは、１個のファイルで管理されることを特徴とする。
本願の第８の発明は、前記映像の第１、第２のデータは、該映像をＭＰＥＧ規格により符号化したものであることを特徴とする。
本願の第９の発明は、少なくとも映像又は音声からなる第１のデータを含む複数の第１のユニットで構成される第２のユニットを、該第２のユニットを管理する第１のプログラムに従って復号するデータ復号方法であって、前記第１のプログラムが、前記第１のユニット間の結合箇所を管理する情報を有し、前記結合箇所情報に基づき、前記第１のユニットの復号を制御することを特徴とする。
本願の第１０の発明は、前記第１のユニットの復号の制御は、前記結合箇所において復号を一時停止することを特徴とする。
本願の第１１の発明は、前記第１のユニットの復号の制御は、前記結合箇所の前後で復号器を切り替えることを特徴とする。
本願の第１２の発明は、前記映像の第１，第２のデータは、該映像をＭＰＥＧ規格により符号化したものであることを特徴とする。
本願の第１３の発明は、少なくとも映像又は音声からなる第１のデータを含む複数の第１のユニットで構成される第２のユニットと、前記第２のユニットを管理する第１のプログラムとを、記録媒体に記録するデータ記録装置であって、前記第１のプログラムが、前記第１のユニット間の結合箇所を管理する情報を有することを特徴とする。
本願の第１４の発明は、少なくとも映像又は音声からなる第１のデータを含む第１のユニットと、少なくとも映像又は音声からなる第２のデータを含む第３のユニットとを接続して、第２のユニットを作成するデータ編集装置であって、前記第２のユニットを管理する第１のプログラムが、前記第１のユニットと第３のユニットとの結合箇所を管理する情報を有することを特徴とする。
本願の第１５の発明は、少なくとも映像又は音声からなる第１のデータを含む複数の第１のユニットで構成される第２ユニットを、該第２のユニットを管理する第１のプログラムに従って復号するデータ復号装置であって、前記第１のプログラムが、前記第１のユニットの結合箇所情報を管理し、前記結合箇所情報に基づき、復号の制御を行う前記第１のユニットの復号器を備えたことを特徴とする。
発明を実施するための最良の形態
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
＜システム構成＞
図１は本実施形態において共通に用いる、アフレコ可能なビデオディスクレコーダの構成である。この装置は、図１に示すように、バス１００、ホストＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、ユーザインタフェース１０４、システムクロック１０５、光ディスク１０６、ピックアップ１０７、ＥＣＣデコーダ１０８、ＥＣＣエンコーダ１０９、再生用バッファ１１０、記録／アフレコ用バッファ１１１、出マルチプレクサ１１２、マルチプレクサ１１３、多重化用バッファ１１４、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８および図示されないカメラ、マイク、スピーカ、ディスプレイ等で構成される。
ホストＣＰＵ１０１は、バス１００を通じてデマルチプレクサ１１２、マルチプレクサ１１３、ピックアップ１０７、また図示していないが、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８との通信を行う。
再生時には、光ディスク１０６からピックアップ１０７を通じて読み出されたデータは、ＥＣＣデコーダ１０８によって誤り訂正され、再生用バッファ１１０に一旦蓄えられる。デマルチプレクサ１１２は、オーディオデコーダ１１５、ビデオデコーダ１１６からのデータ送信要求に従って、再生用バッファ中のデータをその種別によって適当なデコーダに振り分ける。
一方、記録時には、オーディオエンコーダ１１７とビデオエンコーダ１１８によって圧縮符号化されたデータは、多重化用バッファ１１４に一旦送られ、マルチプレクサ１１３によってＡＶ多重化され、記録／アフレコ用バッファ１１１に送られる。記録／アフレコ用バッファ１１１中のデータは、ＥＣＣエンコーダ１０９によって誤り訂正符号を付加され、ピックアップ１０７を通じて光ディスク１０６に記録される。
オーディオデータの符号化方式にはＭＰＥＧ−１  Ｌａｙｅｒ−ＩＩを、ビデオデータの符号化方式にはＭＰＥＧ−２をそれぞれ用いる。
光ディスク１０６は、外周から内周に向かって螺旋状に記録再生の行われる脱着可能な光ディスクとする。２０４８ｂｙｔｅを１セクタとし、誤り訂正のため１６セクタでＥＣＣブロックを構成する。ＥＣＣブロック中のデータを書き換える場合、そのデータが含まれるＥＣＣブロック全体を読み込み、誤り訂正を行い、対象のデータを書き換え、再び誤り訂正符号を付加し、ＥＣＣブロックを構成し記録媒体に記録する必要がある。
また、記録効率を上げるためＺＣＡＶ（ゾーン角速度一定）を採用しており、記録領域は回転数の異なる複数のゾーンで構成される。
＜ファイルシステム＞
光ディスク１０６上の各種情報を管理するためにファイルシステムを用いる。ファイルシステムには、ＰＣとの相互運用を考慮してＵＤＦ（Ｕｎｉｖｅｒｓａｌ  Ｄｉｓｋ  Ｆｏｒｍａｔ）を使用する。ファイルシステム上では、各種管理情報やＡＶストリームはファイルとして扱われる。ユーザエリアは、２０４８ｂｙｔｅの論理ブロック（セクタと一対一対応）で管理される。
各ファイルは、整数個のエクステント（連続した論理ブロック）で構成され、エクステント単位で分散して記録してもよい。空き領域は、Ｓｐａｃｅ  Ｂｉｔｍａｐを用いて論理ブロック単位で管理される。
上記エクステントを表す情報やＳｐａｃｅ  Ｂｉｔｍａｐ等、ファイルシステムに関する管理情報は光ディスク１０６上に記録される。
＜ファイルフォーマット＞
ＡＶストリーム管理のためのフォーマットとして、ＱｕｉｃｋＴｉｍｅファイルフォーマットを用いる。ＱｕｉｃｋＴｉｍｅファイルフォーマットとは、Ａｐｐｌｅ社が開発したマルチメディアデータ管理用フォーマットであり、ＰＣの世界で広く用いられている。
ＱｕｉｃｋＴｉｍｅファイルフォーマットは、ビデオデータやオーディオデータ等（これらを総称してメディアデータとも呼ぶ）と管理情報とで構成される。両者を合わせてここでは、ＱｕｉｃｋＴｉｍｅムービー（略してムービー）と呼ぶ。両者は同じファイル中に存在しても、別々のファイルに存在してもよい。
同じファイル中に存在する場合は、図２（ａ）に示すファイル２０１のような構成をとる。各種情報は、ａｔｏｍという共通の構造に格納される。管理情報はＭｏｖｉｅ  ａｔｏｍという構造に格納され、ＡＶストリームはＭｏｖｉｅ  ｄａｔａ  ａｔｏｍという構造に格納される。
尚、Ｍｏｖｉｅ  ａｔｏｍはメディアデータの任意の区間を任意の順序で再生することを制御するための一種のプログラム情報であり、メディアデータ中の任意の時間に対応するＡＶデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報などが含まれている。
一方、管理情報とメディアデータを別々のファイルに格納した場合は、図２（ｂ）に示すファイル２０２，２０３のような構成をとる。管理情報はＭｏｖｉｅ  ａｔｏｍという構造に格納されるが、ＡＶストリームはａｔｏｍには格納される必要はない。このとき、Ｍｏｖｉｅ  ａｔｏｍはＡＶストリームを格納したファイル２０３を「外部参照」している、という。
外部参照は、図２（ｃ）に示すように、ファイル２０４のＭｏｖｉｅ  ａｔｏｍが複数のファイル２０５，２０６に設けたＡＶストリームファイル＃１，＃２に対して行うことが可能であり、この仕組みにより、ＡＶストリーム自体を物理的に移動することなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」「非破壊編集」が可能になる。
それでは、図３乃至図１２を用いて、ＱｕｉｃｋＴｉｍｅの管理情報のフォーマットについて説明する。まず、共通の情報格納フォーマットであるａｔｏｍについて説明する。ａｔｏｍの先頭には、そのａｔｏｍのサイズであるＡｔｏｍ  ｓｉｚｅ、そのａｔｏｍの種別情報であるＴｙｐｅが必ず存在する。Ｔｙｐｅは４文字で区別され、例えばＭｏｖｉｅ  ａｔｏｍでは’ｍｏｏｖ’、Ｍｏｖｉｅ  ｄａｔａ  ａｔｏｍでは’ｍｄａｔ’となっている。
各ａｔｏｍは別のａｔｏｍを含むことができる。すなわち、ａｔｏｍ間には階層構造がある。Ｍｏｖｉｅ  ａｔｏｍの構成を図３に示す。Ｍｏｖｉｅ  ｈｅａｄｅｒ  ａｔｏｍは、そのＭｏｖｉｅ  ａｔｏｍが管理するムービーの全体的な属性を管理する。Ｔｒａｃｋ  ａｔｏｍは、そのムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納する。Ｕｓｅｒ−ｄｅｆｉｎｅｄ  ｄａｔａ  ａｔｏｍは、独自に定義可能なａｔｏｍである。
Ｔｒａｃｋ  ａｔｏｍの構成を図４に示す。Ｔｒａｃｋ  ｈｅａｄｅｒ  ａｔｏｍは、そのトラックの全体的な属性を管理する。Ｅｄｉｔ  ａｔｏｍは、メディアデータのどの区間をムービーのどのタイミングで再生するかを管理する。Ｔｒａｃｋ  ｒｅｆｅｒｅｎｃｅ  ａｔｏｍは、別のトラックとの関係を管理する。Ｍｅｄｉａ  ａｔｏｍは、実際のビデオやオーディオといったデータを管理する。
Ｔｒａｃｋ  ｈｅａｄｅｒ  ａｔｏｍの構成を図５に示す。ここでは、後での説明に必要なもののみ説明する。ｆｌａｇｓは属性を示すフラグの集合である。代表的なものとして、Ｔｒａｃｋ  ｅｎａｂｌｅｄフラグがあり、このフラグが１であれば、そのトラックは再生され、０であれば、再生されない。ｌａｙｅｒはそのトラックの空間的な優先度を表しており、画像を表示するトラックが複数あれば、ｌａｙｅｒの値が小さいトラックほど画像が前面に表示される。
Ｍｅｄｉａ  ａｔｏｍの構成を図６に示す。Ｍｅｄｉａ  ｈｅａｄｅｒ  ａｔｏｍは、そのＭｅｄｉａ  ａｔｏｍの管理するメディアデータに関する全体的な属性等を管理する。Ｈａｎｄｌｅｒ  ｒｅｆｅｒｅｎｃｅ  ａｔｏｍは、メディアデータをどのデコーダでデコードするかを示す情報を格納する。Ｍｅｄｉａ  ｉｎｆｏｒｍａｔｉｏｎ  ａｔｏｍは、ビデオやオーディオ等メディア固有の属性情報を管理する。
Ｍｅｄｉａ  ｉｎｆｏｒｍａｔｉｏｎ  ａｔｏｍの構成を図７に示す。Ｍｅｄｉａ  ｉｎｆｏｒｍａｔｉｏｎ  ｈｅａｄｅｒ  ａｔｏｍは、ビデオやオーディオ等メディア固有の属性情報を管理する。Ｈａｎｄｌｅｒ  ｒｅｆｅｒｅｎｃｅ  ａｔｏｍは、Ｍｅｄｉａ  ａｔｏｍの項で説明したとおりである。Ｄａｔａ  ｉｎｆｏｒｍａｔｉｏｎ  ａｔｏｍは、そのＱｕｉｃｋＴｉｍｅムービーが参照するメディアデータを含むファイルの名前を管理するａｔｏｍであるＤａｔａ  ｒｅｆｅｒｅｎｃｅ  ａｔｏｍを含む。Ｓａｍｐｌｅ  ｔａｂｌｅ  ａｔｏｍは、データのサイズや再生時間等を管理している。
次に、Ｓａｍｐｌｅ  ｔａｂｌｅ  ａｔｏｍについて説明するが、その前に、ＱｕｉｃｋＴｉｍｅにおけるデータの管理方法について、図８に示すファイル８０１を用いて説明する。ＱｕｉｃｋＴｉｍｅでは、データの最小単位（例えばビデオフレーム）をサンプル（ｓａｍｐｌｅ）と呼ぶ。個々のトラック毎に、サンプルには再生時間順に１から番号（サンプル番号）がついている。
ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のサンプルの再生時間長およびデータサイズを管理している。また、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンク（ｃｈｕｎｋ）と呼ぶ。チャンクにも再生時間順に、１から番号がついている。
また、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のチャンクのファイル先頭からのアドレスおよび個々のチャンクが含むサンプル数を管理している。これらの情報に基づき、任意の時間に対応するサンプルの位置を求めることが可能となっている。
Ｓａｍｐｌｅ  ｔａｂｌｅ  ａｔｏｍの構成を図９に示す。Ｓａｍｐｌｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ａｔｏｍは、個々のチャンクのデータフォーマット（Ｄａｔａ  ｆｏｒｍａｔ）やサンプルが格納されているファイルのインデックス等を管理するテーブルであり、データフォーマットやサンプルの格納されているファイル等が異なる場合、テーブル中の異なるエントリで管理される。なお、エントリとは、テーブル中において、他の情報から参照される情報の単位のことである。
Ｔｉｍｅ−ｔｏ−ｓａｍｐｌｅ  ａｔｏｍは、個々のサンプルの再生時間を管理する。Ｓｙｎｃ  ｓａｍｐｌｅ  ａｔｏｍは、個々のサンプルのうち、デコード開始可能なサンプルを管理する。Ｓａｍｐｌｅ−ｔｏ−ｃｈｕｎｋ  ａｔｏｍは、個々のチャンクに含まれるサンプル数および個々のチャンクがＳａｍｐｌｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ａｔｏｍ中のどのエントリを参照しているかを管理する。Ｓａｍｐｌｅ  ｓｉｚｅ  ａｔｏｍは、個々のサンプルのサイズを管理する。Ｃｈｕｎｋ  ｏｆｆｓｅｔ  ａｔｏｍは、個々のチャンクのファイル先頭からのアドレスを管理する
Ｅｄｉｔ  ａｔｏｍは、図１０に示すように、１個のＥｄｉｔ  ｌｉｓｔ  ａｔｏｍを含む。Ｅｄｉｔ  ｌｉｓｔ  ａｔｏｍは、Ｎｕｍｂｅｒ  ｏｆ  ｅｎｔｒｉｅｓで指定される個数分の、Ｔｒａｃｋ  ｄｕｒａｔｉｏｎ、Ｍｅｄｉａ  ｔｉｍｅ、Ｍｅｄｉａ  ｒａｔｅの値の組（エントリ）を持つ。各エントリは、トラック上で連続的に再生される区間に対応し、そのトラック上での再生時間順に並んでいる。
Ｔｒａｃｋ  ｄｕｒａｔｉｏｎはそのエントリが管理する区間のトラック上での再生時間、Ｍｅｄｉａ  ｔｉｍｅはそのエントリが管理する区間の先頭に対応するメディアデータ上での位置、Ｍｅｄｉａ  ｒａｔｅはそのエントリが管理する区間の再生スピードを表す。尚、Ｍｅｄｉａ  ｔｉｍｅが−１の場合は、そのエントリのＴｒａｃｋ  ｄｕｒａｔｉｏｎ分、そのトラックでのサンプルの再生を停止する。この区間のことをｅｍｐｔｙ  ｅｄｉｔと呼ぶ。
図１１にＥｄｉｔ  ｌｉｓｔの使用例を示す。ここでは、Ｅｄｉｔ  ｌｉｓｔ  ａｔｏｍの内容が図１１（ａ）に示す内容であり、さらにサンプルの構成が図１１（ｂ）であったとする。尚、ここではｉ番目のエントリのＴｒａｃｋ  ｄｕｒａｔｉｏｎをＤ（ｉ）、Ｍｅｄｉａ  ｔｉｍｅをＴ（ｉ）、Ｍｅｄｉａ  ｒａｔｅをＲ（ｉ）とする。このとき、実際のサンプルの再生は図１１（ｃ）に示す順に行われる。このことについて簡単に説明する。
まず、エントリ＃１はＴｒａｃｋ  ｄｕｒａｔｉｏｎが１３０００、Ｍｅｄｉａ  ｔｉｍｅが２００００、Ｍｅｄｉａ  ｒａｔｅが１であるため（図１１（ａ））、そのトラックの先頭から１３０００の区間（図１１（ｃ））はサンプル中の時刻２００００から３３０００（＝２００００＋１３０００）の区間を再生する（図１１（ｂ））。次に、エントリ＃２はＴｒａｃｋ  ｄｕｒａｔｉｏｎが５０００、Ｍｅｄｉａ  ｔｉｍｅが−１であるため（図１１（ａ））、トラック中の時刻１３０００から１８０００（＝１３０００＋５０００）の区間、何も再生を行わない（ｎｕｌｌ，図１１（ｃ））。
最後に、エントリ＃３はＴｒａｃｋ  ｄｕｒａｔｉｏｎが１００００、Ｍｅｄｉａ  ｔｉｍｅが０、Ｍｅｄｉａ  ｒａｔｅが１であるため（図１１（ａ））、トラック中の時刻１８０００（＝１３０００＋５０００）から２８０００（＝１８０００＋１００００）の区間において（図１１（ｃ））、サンプル中の時刻０から１００００の区間を再生する（図１１（ｂ））。
図１２にＵｓｅｒ−ｄｅｆｉｎｅｄ  ｄａｔａ  ａｔｏｍの構成を示す。このａｔｏｍには、ＱｕｉｃｋＴｉｍｅフォーマットで定義されてない独自の情報を任意個数格納することができる。１個の独自情報は１個のエントリで管理され、１個のエントリはＳｉｚｅとＴｙｐｅとＵｓｅｒ  ｄａｔａとで構成される。Ｓｉｚｅはそのエントリ自体のサイズを表し、Ｔｙｐｅは独自情報をそれぞれ区別するための識別情報、Ｕｓｅｒ  ｄａｔａは実際のデータを表す。
＜インデックス・ファイル＞
ディスク内に含まれるＱｕｉｃｋＴｉｍｅムービーを管理するため、ＡＶインデックス・ファイルという特別のＱｕｉｃｋＴｉｍｅムービーファイルをディスク内に１個置く。ＡＶインデックス・ファイルには、ディスク内のファイル（ＱｕｉｃｋＴｉｍｅムービーやＱｕｉｃｋＴｉｍｅムービーから参照されている静止画等）に関するサムネイルや各種属性が登録されている。
各種属性の中には、そのファイルが外部参照されている回数を示すｌｉｎｋ  ｃｏｕｎｔがある。ｌｉｎｋ  ｃｏｕｎｔを参照することで、そのファイルを参照しているファイルがあるかどうかを容易に知ることができ、他から参照されているファイルを不用意に削除してしまうことを防ぐことができる。
＜実施例１＞
本発明の一実施例について、図１３乃至図２１を用いて説明する。
＜ＡＶストリームの形態＞
本実施例におけるＡＶストリームの構成を、図１３及び図１４とともに説明する。ＡＶストリームは、整数個のＲｅｃｏｒｄ  Ｕｎｉｔ（ＲＵ）で構成される。ＲＵはディスク上で連続的に記録する単位である。ＲＵの長さは、ＡＶストリームを構成するＲＵをどのようにディスク上に配置してもシームレス再生（再生中に絵や音が途切れないで再生できること）が保証されるように設定される。この設定方法については後述する。
また、ＲＵ境界がＥＣＣブロック境界と一致するようにストリームを構成する。ＲＵのこれらの性質によって、ＡＶストリームをディスクに記録した後も、シームレス再生を保証したまま、ディスク上でＲＵ単位の配置を容易に変更することができる。
ＲＵは整数個のＶｉｄｅｏ  Ｕｎｉｔ（ＶＵ）で構成する。ＶＵは単独再生可能な単位であり、そのことから再生の際のエントリ・ポイントとなりうる。ＶＵの構成を図１４に示す。ＶＵは１秒程度のビデオデータを格納した整数個のＧＯＰ（グループ・オブ・ピクチャ）とそれらと同じ時間に再生されるメインオーディオデータを格納した整数個のＡＡＵ（オーディオ・アクセス・ユニット）で構成される。
尚、ＧＯＰはＭＰＥＧ−２ビデオ規格における圧縮の単位であり、複数のビデオフレーム（典型的には１５フレーム程度）で構成される。ＡＡＵはＭＰＥＧ−１  ＬａｙｅｒＩＩ規格における圧縮の単位で、１１５２点の音波形サンプル点により構成される。サンプリング周波数が４８ｋＨｚの場合、ＡＡＵあたりの再生時間は０．０２４秒となる。
ＶＵ中ではＡＶ同期再生のために必要となる遅延を小さくするため、ＡＡＵ、ＧＯＰの順に配置する。また、ＶＵ単位で独立再生可能なように、ＶＵ中のビデオデータの先頭にはＳｅｑｕｅｎｃｅ  Ｈｅａｄｅｒ（ＳＨ）を置く。
ＶＵの再生時間は、ＶＵに含まれるビデオフレーム数にビデオフレーム周期をかけたものと定義する。また、ＶＵを整数個組み合わせてＲＵを構成する場合、ＲＵの始終端をＥＣＣブロック境界に合わせるため、ＶＵの末尾を０で埋める。
尚、本実施例では、図１３および図１４に示すＡＶストリーム構成を用いて説明しているが、本発明はこのストリーム構成に限定されるものではない。
＜ＡＶストリーム管理方法＞
ＡＶストリームの管理方法は、前述のＱｕｉｃｋＴｉｍｅファイルフォーマットをベースにしている。図１５にＱｕｉｃｋＴｉｍｅによるＡＶストリーム管理形態を示す。ＡＡＵをオーディオデータのサンプル、Ｓｅｑｕｅｎｃｅ  ｈｅａｄｅｒと整数個のＧＯＰをビデオデータのサンプルとし、ＶＵ中のメインオーディオとビデオの塊をそれぞれ１チャンクに対応させる。
＜ディスク配置決定方法＞
ＡＶストリームのディスク上での配置決定方法について説明する。シームレス再生を保証するためには、次へのＲＵへのジャンプ時間も含めたＲＵ読み出し時間がＲＵの再生時間より小さければよい。
つまり、ＲＵ再生時間をＴｅ（ｉ）、ＡＶストリーム中の任意のＲＵであるＲＵ＃ｉについて最大再生時間をＴ（ｉ）、分断ジャンプを含めた最大読み出し時間をＴｒ（ｉ）としたとき、
Ｔｅ（ｉ）≧Ｔｒ（ｉ）・・・＜式１＞
を満たせばよい。
ＡＶストリーム中のメインオーディオ、ビデオの最大ビットレートをそれぞれＲａ、Ｒｖ、再生機器の最大アクセス時間をＴａ、連続読み出しレートをＲｓとしたとき、
Ｔｒ（ｉ）＝Ｔｅ（ｉ）×（Ｒｖ＋Ｒａ）／Ｒｓ＋Ｔａ・・・＜式２＞
となる。
＜式１＞＜式２＞をＴｅ（ｉ）で解いて、
Ｔｅ（ｉ）≧Ｔａ×Ｒｓ／（Ｒｓ−Ｒｖ−Ｒａ）・・・＜式３＞
が得られる。
つまり、シームレス再生保証可能なＲＵ再生時間下限値Ｔｅｍｉｎは、
Ｔｅｍｉｎ＝Ｔａ×Ｒｓ／（Ｒｓ−Ｒｖ−Ｒａ）・・・＜式４＞
となる。
＜記録時の処理＞
ユーザから録画が指示された場合の処理を、図１６に沿って説明する。このとき記録するＡＶストリームは、ビデオのビットレートＲｖ＝５Ｍｂｐｓ、オーディオのサンプリング周波数４８ｋＨｚ、ビットレートＲａ＝Ｒｐ＝２５６ｋｂｐｓであるものとする。すでに、ファイルシステムの管理情報はＲＡＭ上に読み込まれているとする。
まず、ストリームの構成や連続領域の構成を決定する（ステップ７０１）。１ＶＵを１ＧＯＰ＝３０フレームで構成するとしたとき、＜式４＞にＲｓ＝２０Ｍｂｐｓ、Ｔａ＝１秒、Ｒｖ＝５Ｍｂｐｓ、Ｒａ＝２５６ｋｂｐｓを代入し、Ｔｅ（ｉ）の範囲である１．３６秒以上が得られる。１ＶＵの再生時間を０．５秒としているため、ＲＵ再生時間は２秒とする。
次に、２個のＶＵを連続的に記録可能な空き領域を探す。具体的には２×（Ｒｖ＋Ｒａ）、つまり１１Ｍｂｉｔ以上の連続的な空き領域を、ＲＡＭ１０２上のＳｐａｃｅ  Ｂｉｔｍａｐを参照して探す。存在しなければ録画を中止し、録画できないことをユーザに知らせる（ステップ７０２）。
また、オーディオエンコーダ１１７、ビデオエンコーダ１１８をそれぞれ起動する（ステップ７０３）。次に、記録用バッファに１ＥＣＣブロック分（３２ＫＢ）以上のデータが蓄積されているかどうかをチェックし（ステップ７０４）、蓄積されている間、ステップ７０５からステップ７０８を繰り返す。
蓄積されていれば、次に記録するディスク上のＥＣＣブロックの空き状況を、ＲＡＭ上のＳｐａｃｅ  Ｂｉｔｍａｐを参照して調べる（ステップ７０５）。空きがなければ、２個のＶＵを記録可能な連続的な空き領域を探し（ステップ７０７）、その空き領域の先頭へピックアップを移動する（ステップ７０８）。
次に、記録用バッファ１１１中の１ＥＣＣブロック分のデータを、ディスクに記録する（ステップ７０６）。記録用バッファ１１１にデータが蓄積されていなければ、記録終了が指示されているかどうかをチェックし（ステップ７０９）、記録終了でなければ、ステップ７０４を実行する。
記録終了が指示されていた場合、以下のステップを実行する。まず、記録用バッファ中の３２ＫＢに満たないデータに関して、末尾にダミーデータを付加し３２ＫＢにする（ステップ７１０）。次に、そのデータをディスク上に記録する（ステップ７１１〜ステップ７１４）。最後に、ＲＡＭ１０２上のＱｕｉｃｋＴｉｍｅ管理情報（Ｍｏｖｉｅ  ａｔｏｍ）とファイルシステム管理情報を、光ディスク１０６に記録する（ステップ７１５〜ステップ７１６）。
以上の処理と並行するオーディオエンコーダ１１７、ビデオエンコーダ１１８やマルチプレクサ１１３の動作について説明する。それぞれのエンコーダはマルチプレクサ１１３にエンコード結果を送り、マルチプレクサはそれらを多重化用バッファ１１４に格納する。
１ＶＵ分のデータ、つまり１ＧＯＰとそれに同期して再生されるＡＡＵが多重化用バッファ１１４に蓄積されたら、マルチプレクサ１１３は記録用バッファ１１１に１ＶＵのデータを送る。さらに、ホストＣＰＵ１０１に１ＶＵ分のデータがエンコードできたことを通知し、ホストＣＰＵ１０１はＶＵを構成するＧＯＰやＡＡＵの数およびサイズを基に、ＲＡＭ１０２上のＱｕｉｃｋＴｉｍｅ管理情報を更新する。
＜編集時の処理＞
ＡＶストリームの途中をＲＵ単位で削除することを考える。前述のように、ＲＵの境界はＥＣＣブロック境界と一致する。さらに、ＥＣＣブロックは１６セクタで構成され、セクタと論理ブロックは一致する。したがって、ファイルシステム管理情報とＱｕｉｃｋＴｉｍｅ管理情報を書き換えるのみで、ＲＵ単位の削除が可能である。
ファイルシステム管理情報に関しては、前述のＳｐａｃｅ  ｂｉｔｍａｐ中の削除する領域に対応するビットを０にすることで、領域を開放し、削除対象ＲＵを管理するエクステントを変更する。ＱｕｉｃｋＴｉｍｅ管理情報に関しては、削除区間に含まれるサンプルをＳａｍｐｌｅ  ｔａｂｌｅから削除し、削除区間の後に位置するチャンクのＣｈｕｎｋ  ｏｆｆｓｅｔの値を削除区間のバイト数マイナスする。
また、削除による各トラックの再生時間の短縮に伴い、Ｅｄｉｔ  ｌｉｓｔ（図１０，１１）のＴｒａｃｋ  ｄｕｒａｔｉｏｎを短縮する（図１０，１１）。上記の削除により、ＡＶストリームは削除区間の直前と直後とが接続された形となる。このとき、ビデオトラックについては、繋ぎ目を示すために、削除直前と削除直後の領域の繋ぎ目にあたる時刻の前後で別のエントリとする。
例えばＡＶストリーム＃１とＡＶストリーム＃２を繋ぐことによって、図１７に示すような構成となったＡＶストリームがあった場合、Ｅｄｉｔ  ｌｉｓｔ  ａｔｏｍ（図１０）を、図１８に示すように、２エントリで構成する。一方、ＡＶストリーム同士をＲＵ単位で結合する場合も、削除の場合と同様、ファイルシステム管理情報とＱｕｉｃｋＴｉｍｅ管理情報とを書き換えることにより対応可能である。この情報により、トラックの時間軸における繋ぎ目の時刻および、その時刻に対応するデータのファイル中でのアドレスがわかる。
尚、本実施例では、繋ぎ目が１個の場合について説明したが、２個以上の場合、個数に応じてエントリ数を増やせばよいことは言うまでもない。
尚、ここでは、１トラックのビデオにおいて、Ｅｄｉｔ  ｌｉｓｔのエントリを切り替えることで繋ぎ目を示したが、ＡＶストリーム同士を結合することによって生じた、復号・再生に支障を来たす可能性のある箇所を示すことができればどのような方法を用いてもよいことは言うまでもない。一例を挙げると、繋ぎ目毎にビデオトラックを切り替えることで、繋ぎ目を示すことが考えられる。
具体的には、結合によって、図１７に示すような構成となったＡＶストリームがあった場合、前半部と後半部とを別トラックで管理し、前半部・後半部を管理するトラックのＥｄｉｔ  ｌｉｓｔ  ａｔｏｍ（図１０）の内容を、それぞれ図１９（ａ）、（ｂ）に示す内容とすることで、繋ぎ目を示すことが可能である。このとき、後の編集時にビデオトラック＃１と＃２が誤まって統合されることを防ぐために、ビデオトラック＃１、＃２の少なくとも１個の値、具体的にはＣｒｅａｔｉｏｎ  ｔｉｍｅ（図５）等を異なる値にする。
また、繋ぎ目の前後で異なる内容のＳａｍｐｌｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ａｔｏｍ（図９）を用いることで、繋ぎ目を示してもよい。具体的には、結合によって、図１７に示すような構成となったＡＶストリームがあった場合、図２０に示すように、ＡＶストリーム＃１中のビデオデータとＡＶストリーム＃２中のビデオデータがＳａｍｐｌｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ａｔｏｍの異なるエントリ＃１、＃２で表される属性を参照するようにする。
このことにより、繋ぎ目を示すことが可能になる。さらに、Ｓａｍｐｌｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ａｔｏｍのそれぞれのエントリ中の少なくとも１個の値が異なるようにすることで、後の編集時にＳａｍｐｌｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ｔａｂｌｅの最適化（内容の共通な複数のエントリを１個にまとめること）のためにエントリ＃１、＃２が誤まってマージされることを防ぐことが可能になる。
＜再生時の処理＞
ユーザから再生が指示された場合の処理を、図２１に沿って説明する。ここでは、すでに再生の対象となるＡＶストリームに関するＱｕｉｃｋＴｉｍｅ管理情報がＲＡＭ１０２に読み込まれているものとする。
光ディスク１０６上の再生指示されたＶＵの先頭から再生用データの読み出しを行う（ステップ９０１）。このとき、十分な再生時間分のデータを再生用バッファ１１０へ読み出すまでステップ９０１を繰り返す（ステップ９０２）。
ここで十分とは、再生用データ読み出しの中断期間が最大の場合でも、再生が途切れないだけのデータ量を意味する。具体的には、ＡＶデータの読み出しに伴う分断のジャンプ（最大１秒）を行った場合を想定し、１秒分のデータ量とする。
次に、ホストＣＰＵ１０１は、ビデオデコーダ１１６およびオーディオデコーダ１１５を起動する（ステップＳ９０３）。ホストＣＰＵ１０１は、ＱｕｉｃｋＴｉｍｅ管理情報に基づき、デマルチプレクサ１１２に指令を出すことで、符号化データを再生用バッファ１１０からオーディオデコーダ１１５およびビデオデコーダ１１６へ転送する。
また、ユーザから再生終了を指示されていないかチェックする（ステップ９０４）。指示されていなければ、再生用ＡＶデータの読み出しを行う（ステップ９０５）。再生終了を指示されていれば、終了する。
ホストＣＰＵ１０１はシステムクロック１０５を参照し、現在の時刻がビデオトラックのＥｄｉｔ  ｌｉｓｔ  ａｔｏｍ（図１０）のエントリ（図１１）の切り替えのタイミングであった場合、その箇所が繋ぎ目であると判断し、ビデオデコーダ１１６およびオーディオデコーダ１１５の復号を一時停止する。このとき、繋ぎ目を示すのに、ビデオチャンクの参照するＳａｍｐｌｅ  ｄｅｓｃｒｉｐｔｉｏｎ  ｔａｂｌｅ（図２０）のエントリの切り替わりを利用している場合は、エントリの切り替わりが発生した箇所を繋ぎ目と判断する。
このことによって、繋ぎ目直前のビデオフレームが複数フレーム連続して表示（フリーズ）されることになるが、その間にビデオデコーダ１１６のデコーダバッファにデータを貯えることができるため、バッファのアンダーフローは起きない。つまり、デコーダバッファのアンダーフローが発生したときのように、再生がしばらく乱れるようなことはない。また、もともと繋ぎ目における映像は不連続であるため、それ以外の箇所でフリーズが発生する場合に比べ、乱れが目立たない。
尚、本実施例では、ビデオデコーダが１個だけを用いているが、ビデオデコーダを複数個用意して繋ぎ目で切り替えてもよい。具体的には、再生時に以下のことを行う。まず、ビデオトラックのＥｄｉｔ  ｌｉｓｔ  ａｔｏｍのエントリの切り替えからＡＶデータ中の実際の繋ぎ目の位置がわかるため、繋ぎ目以降のビデオデータを繋ぎ目以前のビデオデコーダとは別のビデオデコーダに送りデコードを開始し、いつでも表示可能な状態にしておく。次に、Ｅｄｉｔ  ｌｉｓｔ  ａｔｏｍのエントリの切り替えのタイミングになった時点で、ビデオデコーダを繋ぎ目以前のものから繋ぎ目以降のものに切り替える。この場合、繋ぎ目の前後でデコーダが異なるため、ＶＢＶバッファの占有量の不連続が起こることはなく、さらに、ビデオデコーダが１個のときのようにフリーズさせる必要がない。
また、本実施例では、編集の際に生じる繋ぎ目を管理しているが、本発明の管理対象である繋ぎ目は編集の際に生じるものに限定されない。例えば、録画の際、新規のＡＶストリームを既存のＡＶストリームファイルの末尾に追加するかたちで行う場合、追加点の前後でＶＢＶバッファ占有量の不連続が生じ、そのＡＶストリームファイルをそのまま再生した場合、追加点の直後で復号・再生が乱れるおそれがあるが、追加点を本実施例と同様に管理することで、そのような復号・再生の乱れを抑えることが可能である。
以上説明したように、本発明によれば、複数のＡＶストリームを繋ぎ合わせて１本のＡＶストリームを作成した場合に、そのＡＶストリームを管理する管理情報によって、繋ぎ目の位置情報を管理することで、再生時に繋ぎ目付近で表示が乱れることを防ぐことが可能になる。
産業上の利用可能性
映像データや音声データ等のＡＶストリームを、例えばハードディスクや光ディスク等のランダムアクセス可能な記録媒体に記録、復号する場合に、該ＡＶストリーム間の再生データの乱れを防止できるデータ記録、編集、復号方法、並びにそれらの装置に適している。
【図面の簡単な説明】
図１は、本発明の実施形態におけるビデオディスクレコーダの概略構成を示すブロック図である。
図２は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおける管理情報とＡＶストリームの関係を示す説明図である。
図３は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｏｖｉｅ  ａｔｏｍの概要を示す説明図である。
図４は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ  ａｔｏｍの概要を示す説明図である。
図５は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ  ｈｅａｄｅｒ  ａｔｏｍの概要を示す説明図である。
図６は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｅｄｉａ  ａｔｏｍの概要を示す説明図である。
図７は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｅｄｉａ  ｉｎｆｏｒｍａｔｉｏｎ  ａｔｏｍの概要を示す説明図である。
図８は、Ｓａｍｐｌｅ  ｔａｂｌｅ  ａｔｏｍによるデータ管理の例を示す説明図である。
図９は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＳａｍｐｌｅ  ｔａｂｌｅ  ａｔｏｍの概要を示す説明図である。
図１０は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＥｄｉｔ  ａｔｏｍの概要を示す説明図である。
図１１は、Ｅｄｉｔ  ａｔｏｍによる再生範囲指定の例を示す説明図である。
図１２は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＵｓｅｒ−ｄｅｆｉｎｅｄ  ｄａｔａ  ａｔｏｍの概要を示す説明図である。
図１３は、本発明の第１の実施例におけるストリームの構成を示す説明図である。
図１４は、本発明の第１の実施例におけるＶＵの構造を示す説明図である。
図１５は、本発明の第１の実施例におけるＱｕｉｃｋＴｉｍｅによるＡＶストリーム管理形態を示す説明図である。
図１６は、本発明の第１の実施例における記録動作を示すフローチャートである。
図１７は、本発明の第１の実施例におけるＡＶストリーム結合の状態を示す説明図である。
図１８は、本発明の第１の実施例におけるＡＶストリーム結合を管理する情報の構成の第１の例を示す説明図である。
図１９は、本発明の第１の実施例におけるＡＶストリーム結合を管理する情報の構成の第２の例を示す説明図である。
図２０は、本発明の第１の実施例におけるＡＶストリーム結合を管理する情報の構成の第３の例を示す説明図である。
図２１は、本発明の第１の実施例における再生動作を示すフローチャートである。
図２２は、ＶＢＶバッファの占有量遷移の例を示す説明図である。
図２３は、従来技術によるＭＰＥＧビデオストリーム結合の例を示す説明図である。
【図１】
2002104016.tif 000003
【図２】
2002104016.tif 000004
【図３】
2002104016.tif 000005
【図４】
2002104016.tif 000006
【図５】
2002104016.tif 000007
【図６】
2002104016.tif 000008
【図７】
2002104016.tif 000009
【図８】
2002104016.tif 000010
【図９】
2002104016.tif 000011
【図１０】
2002104016.tif 000012
【図１１】
2002104016.tif 000013
【図１２】
2002104016.tif 000014
【図１３】
2002104016.tif 000015
【図１４】
2002104016.tif 000016
【図１５】
2002104016.tif 000017
【図１６】
2002104016.tif 000018
【図１７】
2002104016.tif 000019
【図１８】
2002104016.tif 000020
【図１９】
2002104016.tif 000021
【図２０】
2002104016.tif 000022
【図２１】
2002104016.tif 000023
【図２２】
2002104016.tif 000024
【図２３】
2002104016.tif 000025
【手続補正書】
【提出日】平成15年4月14日(2003.4.14)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】特許請求の範囲
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
少なくとも映像からなる第１のデータを含む複数の第１のユニットで構成される第２のユニットと、前記第１のユニットに関する位置情報を有する第１のプログラム情報とを、記録媒体に記録するデータ記録方法であって、
前記第１のデータは、ＭＰＥＧ規格により符号化されたデータであり、
前記第２のユニットは、１個のファイルとして管理され、
前記第１のプログラム情報に、前記ファイル内における前記第１のユニット間の結合箇所を示す情報を含めることを特徴とするデータ記録方法。
【請求項２】
前記結合箇所は、前記第１のユニット中から任意の前記第１のデータを削除した箇所であることを特徴とする前記請求の範囲第１項に記載のデータ記録方法。
【請求項３】
前記第１のユニットを、整数個のセクタで構成することを特徴とする前記請求の範囲第１項又は２項に記載のデータ記録方法。
【請求項４】
削除
【請求項５】
少なくとも映像からなる第１のデータをそれぞれ含む第１及び第３のユニットを接続して、第２のユニットを作成するデータ編集方法であって、
前記第１のデータは、ＭＰＥＧ規格により符号化されたデータであり、
前記第２のユニットは、１個のファイルとして管理され、
前記第１、第３のユニットに関する位置情報を、第１のプログラム情報が有し、
前記第１のプログラム情報は、前記ファイル内における前記第１のユニットと前記第３のユニットとの結合箇所を示す情報を有することを特徴とするデータ編集方法。
【請求項６】
前記第１のユニットと前記第３のユニットは、前記第２のユニット中の任意の前記第１のデータを削除することによって形成されることを特徴とする前記請求の範囲第５項に記載のデータ編集方法。
【請求項７】
少なくとも前記第１のユニットと前記第３のユニットの一方を、整数個のセクタで構成することを特徴とする前記請求の範囲第５項又は６項に記載のデータ編集方法。
【請求項８】
削除
【請求項９】
削除
【請求項１０】
少なくとも映像からなる第１のデータを含む複数の第１のユニットで構成される第２のユニットを、該第１のユニットに関する位置情報を有する第１のプログラム情報に従って復号するデータ復号方法であって、
前記第１のデータは、ＭＰＥＧ規格により符号化されたデータであり、
前記第２のユニットは、１個のファイルとして管理され、
前記第１のプログラム情報が、前記ファイル内における前記第１のユニットの結合箇所を示す情報を有し、
前記結合箇所において前記第１のユニットの復号を一時停止することを特徴とするデータ復号方法。
【請求項１１】
少なくとも映像からなる第１のデータを含む複数の第１のユニットで構成される第２のユニットを、該第１のユニットに関する位置情報を有する第１のプログラム情報に従って復号するデータ復号方法であって、
前記第１のデータは、ＭＰＥＧ規格により符号化されたデータであり、
前記第２のユニットは、１個のファイルとして管理され、
前記第１のプログラム情報が、前記ファイル内における前記第１のユニットの結合箇所を示す情報を有し、
前記結合箇所の前後で復号器を切り替えることを特徴とするデータ復号方法。
【請求項１２】
削除
【請求項１３】
少なくとも映像からなる第１のデータを含む複数の第１のユニットで構成される第２のユニットと、前記第１のユニットに関する位置情報を有する第１のプログラム情報とを、記録媒体に記録するデータ記録装置であって、
前記第１のデータは、ＭＰＥＧ規格により符号化されたデータであり、
前記第２のユニットは、１個のファイルとして管理され、
前記第１のプログラム情報が、前記ファイル内における前記第１のユニット間の結合箇所を示す情報を有することを特徴とするデータ記録装置。
【請求項１４】
少なくとも映像からなる第１のデータをそれぞれ含む第１及び第３のユニットを接続して、第２のユニットを作成するデータ編集装置であって、
前記第１のデータは、ＭＰＥＧ規格により符号化されたデータであり、
前記第２のユニットは、１個のファイルとして管理され、
前記第１及び第３のユニットに関する位置情報を、第１のプログラム情報が有し、
前記第１のプログラム情報は、前記ファイル内における前記第１のユニットと前記第３のユニットとの結合箇所を示す情報を有することを特徴とするデータ編集装置。
【請求項１５】
少なくとも映像からなる第１のデータを含む複数の第１のユニットで構成される第２ユニットを、該第１のユニットに関する位置情報を有する第１のプログラム情報に従って復号するデータ復号装置であって、
前記第１のデータは、ＭＰＥＧ規格により符号化されたデータであり、
前記第２のユニットは、１個のファイルとして管理され、
前記第１のプログラム情報が、前記ファイル内における前記第１のユニットの結合箇所を示す情報を有し、
前記結合箇所において前記第１のユニットの復号を一時停止することを特徴とするデータ復号装置。
【請求項１６】
少なくとも映像からなる第１のデータを含む複数の第１のユニットで構成される第２ユニットを、該第１のユニットに関する位置情報を有する第１のプログラム情報に従って復号するデータ復号装置であって、
前記第１のデータは、ＭＰＥＧ規格により符号化されたデータであり、
前記第２のユニットは、１個のファイルとして管理され、
前記第１のプログラム情報が、前記ファイル内における前記第１のユニットの結合箇所を示す情報を有し、
前記結合箇所の前後で復号器を切り替えることを特徴とするデータ復号装置。
【請求項１７】
少なくとも映像からなる第１のデータを含む複数の第１のユニットで構成される第２ユニットと、前記第１のユニットに関する位置情報を有する第１のプログラム情報とを記録した記録媒体であって、
前記第１のデータは、ＭＰＥＧ規格により符号化されたデータであり、
前記第２のユニットは、１個のファイルとして管理され、
前記第１のプログラム情報が、前記ファイル内における前記第１のユニット間の結合箇所を示す情報を有することを特徴とする記録媒体。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００１
【補正方法】変更
【補正の内容】
【０００１】
明  細  書
データ記録方法、データ編集方法およびデータ復号方法、並びにその装置、及び記録媒体
技術分野
本発明は、映像データ、音声データをハードディスク、光ディスク等のランダムアクセス可能な記録媒体に対して記録・再生するデータ記録方法、データ編集方法およびデータ復号方法、及びその装置、及び記録媒体に関するものである。
背景技術
ディスクメディアを用いたビデオや音声のディジタル記録再生装置が普及しつつある。テープメディアにはないディスクメディアにおける特徴機能として、非破壊編集機能あるいはノンリニア編集機能と呼ばれるものがある。この機能は、ディスク上に記録したＡＶストリームを移動あるいはコピーすることなく、ＡＶストリームの任意の区間を任意の順番で再生できる、というもので、ＡＶストリームのどこからどこまでどういう順番で再生するかを示す情報（再生管理情報）を作り、その情報に従って再生することで実現される。
このようなディスクメディアでは、素材を書き換えたりデータを移動することなく、編集を行うことが可能なわけであるが、素材を直接編集したい場合もある。例えば、非破壊編集した結果を、パーソナル・コンピュータ（ＰＣ）で扱いやすいように１個のファイルにまとめたいとする。この場合、編集結果で使用されている部分のみを個々のＡＶストリームから抜き出し結合して１個のファイルにまとめることになる。
次のような場合もある。ディスクの空き容量を増やすため、ＡＶストリーム中の不要な中間部分を削除したいとする。この場合、中間部分の前後を結合することになる。


【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００３
【補正方法】変更
【補正の内容】
【０００３】
のようなことが発生するのは、繋ぎ目においてはバッファ占有量の整合が取れない可能性があるためである。
上述の問題を解決する方法として、例えば特開平９−１８２０２４号公報では、復号器の入力データの転送速度を高めることにより、アンダーフローを防止する技術が提案されている。しかしながら、この場合、特殊な復号器を用意する必要があり、コストの面で不利になるという問題点がある。
また別の方法として、例えば特開平８−２５１５８２号公報では、結合の際に繋ぎ目の部分を一旦復号し、ＶＢＶバッファが破綻しないような符号化データ量になるように符号化し直す技術（再符号化）が提案されている。しかしながら、この場合においては、再符号化により画質が低下するおそれがあり、さらに符号化と復号を逐次的あるいは並列的に行う必要あるため、装置が複雑化するという問題も含んでいる。
本発明は、上記課題に鑑みてなされたものであり、ＡＶストリームを繋ぎ合わせて構成されたＡＶストリームを再生する際に、再生の乱れが生じるのを、簡単な構成にて防止することが可能なデータ記録方法、データ編集方法、データ復号方法、データ記録装置、データ復号装置、及び記録媒体を提供することを目的とする。
発明の開示
本願の第１の発明は、少なくとも映像又は音声からなる第１のデータを含む複数の第１のユニットで構成される第２のユニットと、前記第２のユニットを管理する第１のプログラムとを、記録媒体に記録するデータ記録方法であって、前記第１のプログラムが、前記第１のユニット間の結合箇所を管理する情報を有することを特徴とする。
本願の第２の発明は、前記結合箇所は、前記第２のユニット中から任意の前記第１のデータを削除した箇所であることを特徴とする。
本願の第３の発明は、前記第２のユニットは、１個のファイルで管理されるこ




【国際調査報告】
2002104016.tif 000026
2002104016.tif 000027