JP4169569B2 - Recording method, recording medium, and recording / reproducing apparatus - Google Patents

Description

【００３９】
とする。なお、ceiling(x)はx以上の最小の整数を、floor(x)はx以下の最大の整数を求める関数である。PRUを持つEUSの場合にデータ転送速度などに基づきNvuの最小値を設定する理由は、EUあたりの時間が十分に大きくないと、図 23のように逐次的にアフレコを行なう際、ヘッドを現在の読込位置からアフレコ領域へ移動させるオーバーヘッドの占める割合が大きくなり、データの読込が表示に追いつかなくなりビデオやオーディオの再生が途切れてしまうからである。
【００４０】
次にVUについて説明を行なう。VUは、sequence-headerおよびそれに続くGOP-headerを直前に置いた1個以上の整数個のGOP(グループ・オブ・ピクチャ)からなるビデオデータと、それと同期する整数個のAAU(オーディオ・アクセス・ユニット)からなるオーディオデータを含む。GOPは、MPEGビデオ圧縮の単位で、複数のフィールド群あるいはフレーム群で構成される。AAUは、オーディオサンプルを0.024秒毎にセグメント化しそれぞれのセグメントを圧縮したものである。GOP、AAUともにそれぞれの単位の先頭からデコードする必要があるが、VUはそれぞれを整数個含んでいるためVU単位で独立再生可能である。1VUあたりのビデオフィールド数はNTSCの場合、24フィールドから60フィールド、PALの場合は20フィールドから50フィールドの範囲にする。
【００４１】
VUは図 6のように、先頭にVU Header Block(VH-BLK)、次に前述のオーディオデータを格納したA-BLKの列を置き、最後に前述のビデオデータを格納したV-BLKの列の順に配置する。A-BLKの個数は、前述のオーディオデータを格納するのに必要十分なものにする。最後のA-BLKに余りが出た場合には前述のようにP-PKTあるいはスタッフィングバイトで調整する。V-BLKも同様の構成とする。
【００４２】
上記のように独立再生が可能な単位であるVUの集合でEUを構成することによって、EUの途中から再生を開始する場合のオーバーヘッドが小さくなる。転送速度がデータのビットレートに比べ余裕が無い場合、Nvuを大きく、すなわちEUあたりの提示時間を長く設定する必要があるが、その場合にVUのような単位を設けなければ、例えばEUの終端付近から再生を始める場合でも、EUの先頭から読み込まなければならず、ユーザに対するレスポンスの低下を招くことになる。また、VUを整数個のblock、すなわちセクタで構成することで、VUの先頭へのアクセスが簡略化される。
【００４３】
VH-PKTの構造を図 7に示す。図中のBP(バイト・ポジション)は先頭からの相対的なバイト位置であり、バイト数はそれぞれのフィールドのバイト数を示す。packet-start-code-prefix、stream-id、PES-packet-lengthは前述の通りである。VU Propertyは1byteのビットフィールドで、このVU headerが含まれるVUに関する情報を格納する。その中の1つであるFirst VU of EUはそのVH-PKTを含むVUがEU中の先頭のVUであれば1それ以外は0に設定される。このフィールドは、後述するように、アフレコ時に同期を取るのに用いる。Length of VUはこのVU headerが含まれるVU中のblock数を表わす。Start RLBN of Video Dataは、VUの先頭からビデオデータが始まるまでのblock数を表わす。
【００４４】
次にPRUについて説明を行なう。PRUは、1以上整数個のVUに対するオーディオを格納するための領域であり、1個のEUに0個あるいは1個存在する。PRUのサイズは、EUあたりの提示時間に対応するオーディオデータとPRUヘッダ・ブロックを含むことのできる最小の整数個のECCブロックである。PRUを構成するECCブロックの数NPRU,ECCは
【００４５】
【数２】

【００４６】
として規定される。なお、PRU中に記録するオーディオデータは、そのPRUが含まれるEU中のVUのオーディオと同じデータレート、同じサンプリング周波数で記録する。
【００４７】
オリジナルデータ記録直後のPRUの構成を図 8に示す。先頭にPRU Header Block (PH-BLK)を1個記録し、残りの領域をPadding Block (P-BLK)で埋めておく。つまり、オリジナルデータ記録直後の時点では、オーディオデータは記録されていない。
【００４８】
PRUにオーディオをアフレコした後のPRUの構成を図 9に示す。先頭にPRU Header Block (PH-BLK)を1個記録し、その後にはそのEUに同期したオーディオデータをA-BLKの列として記録し、残りの領域をP-BLKで埋めておく。このとき、PRU中のA-BLKは、同じEU中のそれぞれのVUに含まれるA-BLK数の合計と同じ数にする。さらに、PRU中のそれぞれのA-BLKの持つPTSの値が同EU中のそれぞれのVUに含まれるA-BLKのPTSと同じ順番でかつ、同じ値を取るように、ポストレコーディングのオーディオデータを記録する。すなわち、アフレコ後PRU中には、各VUに含まれるA-BLKの列に対応するA-BLKの列が存在することになる。このような、VUに対応したPRU中のA-BLKの列をSAU(サブ・オーディオ・ユニット)と呼ぶことにする。なお、言うまでもないが、SAUには、VUと同様整数個のAAUが含まれることになる。
【００４９】
PH-PKTの構造を図 10に示す。packet-start-code-prefix、stream-id、PES-packet-lengthについてはVUヘッダ・パケットと同様である。Length of PRUは、このPH-PKTの含まれるPRUを構成するblock数を記述する。Number of VUはこのPH-BLKの含まれるEUを構成するVUの数を表わす。Start RLBN of Data for VUは、各SAUのPRUの先頭からのblock数を表わす。
【００５０】
上記のように、PRUを整数個のBlockすなわちセクタで構成される整数個のAAUを含む単位(SAU)の集合とすることで、PRUをバッファメモリ108に読み込んだ後、その中のアフレコデータをSAU単位で部分的に書き換えることが容易になる。なぜなら、各SAUに含まれるAAUは他のSAU中のAAUとは独立したパケットに格納されているため、SAU単位で書き換えるのであれば、その他のSAUには影響を与えることはないからである。もし、このような構成を取らなければ、1つのパケットに異なるSAUに含まれるAAUが存在することになり、すでにアフレコ済みのPRUに対してその途中からアフレコを行なう際に、パケットを解いてAAUの先頭を探し、データを書き換え再度パケット化するという手順を踏まねばならず、処理が複雑化する。
【００５１】
さらに、それぞれのSAUの先頭位置を示す情報をストリーム中に挿入しているため、PRUをSAU単位で書き換えする場合に、どの位置から書き換えを開始したらよいかが即座にわかる。
【００５２】
また、PRU中のデータをVU中のオーディオデータと同様の構造にしておくことで、例えば、PRU中のオーディオデータをVU中に部分的にコピーする等、PRUとVUの間でのデータのやり取りが容易になる。
【００５３】
EU中でのPRUの配置について説明する。PRUは、それが含まれるEUの先頭の15セクタ以内のECC境界、つまりEU中の最初に現れるECC境界に置く。例えば、あるEUの先頭がECCブロック境界だった場合、図 11 (a)のように、そのEUの先頭の直後にPRUを配置する。また、EUの先頭がECCブロック境界でなかった場合は、(b)のように、EUの境界の直後から15論理ブロック以内のECCブロック境界、つまりEU中の最初に現れるECCブロック境界に配置する。この場合、EU中の先頭のVUはPRUによって分断されることになる。
【００５４】
上記のように、PRUのサイズをECCブロックサイズの整数倍にし、なおかつPRUをECCブロック境界に配置することで、アフレコの際は、記録媒体上で書き換えるデータはPRUだけになり、書き換えを行なう領域が最小限で済むという利点がある。
【００５５】
上記実施例において、PRUがEUの先頭付近にある理由は、あるEUを再生する場合に、PRU全体と1つのVUを読み込んだ時点でVUとPRUの同期再生が可能になるためである。もし、PRUがEUの終端付近にあった場合、そのEUのほとんどのデータを読み終わるまでプログラムの再生ができず、しかもほぼEU全体を記憶するためのバッファメモリが必要となる。
【００５６】
EUS Managementファイルの構造を図 12に示す。EUS Managementファイルは、ディスク中に記録されたすべてのEUSファイルを管理するための情報を格納したものである。以下、本実施形態の説明に必須な項目のみについて説明を行なう。フィールドNumber of EUSIは、このファイルで管理するEUSファイルの個数を表わす。フィールドEUSI(EUS Information)は各EUSファイルに関する情報であり、Number of EUSI個分存在する。EUSIはさらに図 13のように構成される。図中のStart PTおよびEnd PTは、このEUSIが管理するEUSファイル中のの開始PTSおよび終了PTSの最上位ビットを省略したものである。なお、以後このようにPTSの最上位ビットを省略した形式をPTフォーマットと呼ぶことにする。Post Recording Unit SizeはこのEUSIが管理するEUSファイル中のPRUのサイズを表わす。
【００５７】
Address LUT(ルックアップ・テーブル)は、PTフォーマットで記述されたタイムコードからそのタイムコードに対応するデータが記録されているアドレスを検索するためのテーブルである。Address LUTの構成を図 14に示す。フィールドPB Time of EUは、EUあたりの提示時間を1/90000[秒]単位で表わしたものであり、PTフォーマットと同じスケールとなっている。PB Time of VUも、同様にVUあたりの提示時間を1/90000[秒]単位で表わしたものである。Number of PRU InformationはAddress LUT中のPRU Informationの数であると同時に、EUS中のPRUの個数も表わす。Number of VU Informationも同様にAddress LUT中のVU Informationの数およびEUS中のVU数を表わしている。
【００５８】
図 15は、PRU Informationの内容を表わす。図中のRLBN of PRUはそのPRU Informationが管理するPRUのアドレスを表わす。図 16は、VU Informationの内容を表わす。図中のRLBN of VUはそのVU Informationが管理するVUのアドレスを表わす。
【００５９】
Address LUTを用いて、あるタイムコードPTに対応するPRUのアドレスを求める手順を以下に示す。まず、PTからEUSI中のStartPTを引くことで相対PTを求め、次に相対PTをPB Time of EUで割り、小数部を切り捨てることで、そのPTに対応するPRUを管理するPRU Informationのインデックスが求まる。次に、そのインデックスに対応するPRU Information中のRLBN of PRUで与えられるアドレスが、目的とするPTに対応するPRUのアドレスである。時刻PTに対応するVUのアドレスも同様に、PTからStart PTを引いたものをPB Time of VUで割り、小数部を切り捨てた値に対応するインデックスのVU Information中のRLBN of VUを参照することで得られる。このように単純な処理でVUやPRUの先頭アドレスが得られるのは、EUおよびVUあたりの提示時間を一定にしているためである。
【００６０】
上記ディスクフォーマットで記録、再生およびアフレコを行なう際の手順を以下に示す。なお、以下の説明ではビデオはNTSCで記録し、VUを30フィールドからなる1個のGOPで構成し、ビデオ最大ビットレートを8[Mbps]とする。ディスク転送レートRsは12[Mbps]、アフレコ領域への最大ジャンプ時間Tkを0.3[秒]、最大回転待ち時間Tvを0.2[秒]とする。また、オーディオビットレートおよびオーディオチャンネル数をそれぞれ0.125[Mbps/チャンネル]、2[チャンネル]とし、オリジナルおよびアフレコで共通に用いることにする。このとき、VUあたりの提示時間Tpvは約0.5秒となる。また、アフレコが可能なEUあたりのVU数Nvuの範囲は、7≦Nvu≦20となる。本実施形態では、Nvu=8、すなわちEUあたりの提示時間は約4秒となる。
【００６１】
オリジナルプログラム記録時のCPU102の処理の流れを図 17に沿って説明する。すでに、ディスクからEUS Managementファイルやファイルシステム管理情報がRAM103に読み込まれているものとする。CPU102はエンコーダ106を起動し（ステップ1）、次にファイルシステム管理情報を基に1EU分のデータを記録するのに十分な連続領域がディスク上にあるかどうか調べる(ステップ2)。もし、なければ録画を停止する（ステップ12）。
【００６２】
もし十分な領域があれば、記録対象のVUがEU中の何番目のVUかを表わす変数iを0にリセットし、空き領域先頭アドレスを変数addrに記憶させる(ステップ3)。次に、マルチプレクサ107から1VU分のデータがバッファメモリ108にバッファリングされたことの通知を待つ(ステップ4)。マルチプレクサ107から通知が来たら、変数iが0のときは（ステップ5）、変数addrがECCブロック境界かどうかを判断し(ステップ9)、もし、ECCブロック境界でなければ、次のECCブロック境界までバッファメモリ108中のVUデータをディスクに記録する(ステップ10)。
【００６３】
次に、PH-PKTおよびP-PKTでPRUをRAM103中に構成し、それをディスクに記録する(ステップ11)。次に、バッファメモリ108中の先頭のVUデータをディスクに記録する(ステップ6)。記録が終わったら変数iをインクリメントする(ステップ7)。変数iがEU中のVU数を表わす変数Nvuより小さければステップ4にジャンプし(ステップ8)、等しくなればステップ2にジャンプする。以上の処理を、操作部101から停止指令がきたり、ディスク中に十分な連続領域が無くなるまで、EU単位に行なっていく。
【００６４】
以上のCPU102の処理と並行して、マルチプレクサ107は、オーディオ、ビデオそれぞれのエンコーダ106から送られるデータにPTS等を付与しパケット化しバッファメモリ108に貯えていく。1GOP分のV-PKTとそれに同期するA-PKTがバッファメモリ108に貯えられたらCPU102にVU分のデータをバッファリングしたことを通知する。
【００６５】
以上の手順で記録を行なったオリジナルプログラムの再生時にユーザからアフレコ開始の指示が与えられた場合の処理の流れを説明する。すでに、ディスクからEUS Managementファイルおよびファイルシステム管理情報がRAM103に読み込まれているものとする。CPU102はデコーダ112を起動し、ファイルシステム管理情報を基に、指定されたEUSファイルを先頭から読み込むようにディスクドライブ109に指令を出す。ディスクドライブ109はECCデコーダ112を経由してデマルチプレクサ111に読み込んだデータを送り、デマルチプレクサ111は、バッファメモリ108にデータを蓄積していく。デコーダ112は、ビデオやオーディオの再生に必要なデータをデマルチプレクサ111に要求し、デマルチプレクサ111はその要求に応じてバッファメモリ108に蓄積したデータを、パケットヘッダ中のstream-idに基づき適切なデコーダ112に送る。デコーダ112はデマルチプレクサ111から十分なデータを受け取りビデオやオーディオを出力可能になった時点でそのデータに対応するPTSでシステムクロック105を初期化し、以後は、システムクロック105の値を基準にして出力の同期を取る。
【００６６】
デマルチプレクサ111は、ユーザからアフレコが指示されたときのために現在再生中のデータに対応するPRUと、その次に再生するEUに対応するPRUの合計2個のPRUを常にバッファメモリ108内に保持する。さらに、それらのPRUを管理するためのテーブル(PRU管理テーブル)をRAM103中に作成する。
【００６７】
PRU管理テーブルの構成を図 18に示す。PRU管理テーブルは2個のテーブル、SAU開始PTS(SAU-PTS[j][i])とSAU開始アドレス(RLBN[j][i])とで構成される。SAU-PTS[j][i]は2次元の配列であり、1番目のインデックスがバッファメモリ108中のPRUの番号、2番目のインデックスがPRU中のSAUの番号を表わしており、その2つのインデックスでSAUの先頭のPTSを得ることができる。RLBN[j][i]も同様の構造を持ち、PRUの番号とPRU中のSAUの番号をインデックスとし、そのPRUの先頭を基準としたSAUの相対アドレスを得ることが可能である。この2つのテーブルを用いることで、あるPTSに対応するデータをバッファメモリ108中のどのSAUに記録すればよいかがわかる。
【００６８】
以上の再生処理を行なっている最中に、ユーザから操作部101を通じてアフレコを行なう指示が与えられた場合の処理を説明する。まず、CPU102がオーディオのエンコーダ106を起動する。デマルチプレクサ111は、システムクロック105からアフレコが開始された時点のタイムスタンプ(アフレコ開始PTS)を得、前述のSAU-PTS[j][i]の中から、アフレコ開始PTSを超えない最大のPTSを持つインデックスを検索する。検索の結果得られたPRU番号n、SAU番号mをデマルチプレクサ111はアフレコ開始PTSとともにマルチプレクサ107に通知する。マルチプレクサ107は、エンコーダ106から送られるAAUをバッファメモリ108中のn番目のPRUのRLBN[n][m]の位置から記憶していく。記録を開始するSAUの先頭PTSとアフレコ開始PTSの差に応じて、パケット化の前にマルチプレクサ107はオーディオエンコーダ106から送られるAAUの前に、無音のAAUを差に相当する分挿入してタイミングを調整する。
【００６９】
ユーザからアフレコが指示された時点のシステムクロック105の値、すなわちアフレコ開始PTSが228228だった場合を例に取って説明する。まず、SAU-PTS[i][j]中でアフレコ開始PTSを超えない最大のSAU開始PTSを持つSAU番号、PRU番号の組を検索する。図 18の場合、PRU番号=0、SAU番号=5となる。次にその番号に対応するRLBN[0][5]の値を見る。その結果、SAU＃5のアドレス41が得られる。したがって、バッファメモリ108中のPRU＃0の先頭から第41 block目に存在するSAU＃5からアフレコデータを記録していくことになる。
【００７０】
アフレコデータを格納中のPRUのインデックスをnとしたとき、そのPRUの最後までデータを格納した時点で、i=0から7までのRLBN[n][i]の値を現在のPRU中のPH-PKTのフィールドStart RLBN of Data for VUに順に格納し、PRUの最後までデータが格納されたことをCPU102に通知する。その際、SAU-PTS[n][0]、すなわちそのPRUを含むEUの先頭PTSも知らせる。一方、CPU102は、前記のオリジナルプログラムの再生を行ないながら、マルチプレクサ107からの通知があったら、その際に得られるEUの先頭PTSを基に、Address LUTを参照して、そのアフレコオーディオデータを記録すべきディスク113上のPRUのアドレスを求め、ディスクドライブ109に、バッファメモリ108中のn番目のPRUを前記アドレスに記録するように指令を出す。以降は、バッファメモリ中のPRUに入力されるアフレコデータを交互に格納していくことになる。
【００７１】
PRU管理テーブルの作成手順を図 19に示す。基本的な考え方は、各VUに含まれるA-BLKの個数をVH-PKT中のStart RLBN of Videoから求め、その個数がSAUに含まれるA-BLKの個数と同じことを利用して、SAU先頭アドレステーブルを構築し、同時にVU中の最初のA-PKTのPTSを抜き出しSAU先頭PTSテーブルを構築することにある。まず、VH-PKTの直後であることを表わすフラグであるVH-flgをリセットし、バッファメモリ108中のPRU番号を指すインデックスであるjを1にセットする(ステップ1)。デマルチプレクサ111に到着したパケットがVH-PKTの場合(ステップ2)、ステップ3にジャンプし、そうでないならステップ7にジャンプする。
【００７２】
パケットがVH-PKTの場合、VH-PKT中のFirst VU of EUフィールドが1かどうか検査し(ステップ3)、1なら、それ以降のデータを格納する領域を現在のPRUからもう一方のPRUを変更するために、jをインクリメントする。同時に、RLBN[j][0]に1をセットする。さらに、一時変数tmpに現在のVH-PKT中のStart RLBN of Videoフィールドの値をセットし、iに0をセットする(ステップ4)。もし、FirstVU of EUフィールドが0なら、RLBN[j][i]に一時変数tmpをセットし、さらにtmpに現在のVH-PKT中のStart RLBN of Videoフィールドの値から1引いたものを加える(ステップ6)。ここで1を引くのは、VU中のA-BLKの個数にVH-BLKの個数1を加えた値であるStart RLBN of Videoから、ここで必要となるVU中のA-BLKの個数を求めるために、VH-BLKの分を差し引くことを意味する。First VU of EUフィールドがいずれの場合も次に、VH-flgに1をセットし、iをインクリメントする(ステップ5)。
【００７３】
ステップ7では、デマルチプレクサ111に到着したパケットがA-PKTかどうか検査し、A-PKTならステップ8へジャンプし、A-PKTでないならステップ2にジャンプする。ステップ8では、変数VH-flgを検査し、VH-flgが1ならば、そのパケットのパケットヘッダ中のPTSをSAU-PTS[j][i]にセットし、VH-flgを0にリセットする(ステップ9)。以上の処理をblock毎に行なうことで、EUをすべて読み込んだ時点で、そのEU中のPRUに対するPRU管理テーブルを作成することができる。
【００７４】
以上のアフレコの際のディスク中のヘッド位置とバッファメモリ108中に占めるオリジナルデータ量の時間的変化について図 20に沿って説明する。ここではプログラムが、ディスク中のs11〜s18〜の連続的な領域に配置され、s11〜s13、s13〜s15、s15〜s17がそれぞれEUに対応し、s11〜s12、s13〜s14、s15〜s16、s17〜s18がそれぞれPRUに対応しているとする。
【００７５】
時刻t1の時点では、既にs13までの領域をすべてバッファメモリ108に読み込み、領域s11〜s13のビデオの提示およびそれを見ながらのアフレコオーディオの入力を行っているとする。入力されたアフレコオーディオはバッファメモリ108中の一方のPRU(PRU＃0)に格納されているとする。
【００７６】
時刻t1〜t3では、ディスクドライブ109が領域s13〜s15を読み込む。時刻t2は、時刻t1までに読み込まれた領域s12〜s13のVUがビデオ再生のために使い果たされる時間に対応する。
【００７７】
時刻t3は、領域s12〜s13のVUの提示を見て入力されたアフレコオーディオのエンコーディングが終了する時刻に相当する。この時点で、PRU＃0の最後までデータが記録され、マルチプレクサ107はそのPRUの先頭PTSをCPU102に通知し、アフレコオーディオの格納先をもう一方のPRU(PRU＃1)に切り替える。
【００７８】
ここでは、時刻t3でディスクからの読み込みと、アフレコオーディオのエンコーディングが同時に終了するようになっているが、必ずしも同時である必要はないことは言うまでもない。
【００７９】
CPU102はマルチプレクサ107から送られた先頭PTSからPRU＃0の内容を記録すべきアドレス、すなわち領域s11〜s12のアドレスを求め、時刻t3〜t4でPRU＃0の内容をディスク113に記録する。
【００８０】
時刻t5では次の領域s15〜s17の読み込みを行う。このタイミングはｔ4で書き込み終了後であればよく、バッファメモリ108がオーバーフローを起こさず、またバッファメモリ108のデータがすべてなくなる（アンダーフロー）しないタイミング（ｔ4〜ｔ6の間）で読み込みを開始すればよい。以下同様の処理を繰り返す。
【００８１】
本実施形態によれば、アフレコデータの書き込みにおける時間が従来技術に比して短くなるために、図 20におけるt4〜t5間を短くすることができる。このことは、ディスクの読み込み時間に対する提示時間が短い場合（単位時間中に多くの情報量を割り当てた場合やディスクの読み込み転送レートが低い場合）であっても、ビデオやオーディオが途切れることがないという効果がある。
【００８２】
本実施形態では、PH-PKT中のフィールドStart RLBN of Data for VUをアフレコ時に記録しているが、固定の値であるためオリジナルデータ記録時に予め記録してもよい。さらに、PH-PKT中に各SAUの先頭PTSを記録するフィールドを追加することも考えられる。その場合、オリジナルデータ記録時に予めそのフィールドに値を記録しておくことで、アフレコ時には、PH-PKTを読み込むだけで、PRU管理テーブルを構築するのに必要な情報を得ることができ、図 19の処理が不要になる。
【００８３】
また、本実施形態では、EUの先頭を表わす情報としてVH-PKT中のFirst VU of EUフィールドを用いたが、EUの境界を表わすパケットをEUの先頭に挿入してもよい。
【００８４】
本実施形態ではSAUとVUの提示時間を同一にしているが、そのことは必須ではない。特に、SAUの提示時間をVUより短く、例えば半分や1/4にすることで、アフレコ開始終了時間をより細かい精度にすることができる。例えば、本実施例では、アフレコデータ記録済みのEUSの途中からアフレコを開始した場合、最悪の場合、アフレコ区間の前後のそれぞれ1SAU分(=1VU分)近く記録済みのアフレコデータを無音で上書きしてしまうことになる。しかし、SAUをVUより時間的に短くすれば、無音で上書きしてしまう範囲を小さくすることが可能となる。
【００８５】
以上の手順でアフレコを行なったプログラムの途中から再生する場合の手順を説明する。すでに、ディスクからファイルシステム管理情報およびEUS ManagementファイルがRAM103に読み込まれているものとする。ユーザに指定されたプログラムとタイミングからCPU102は、対応するEUSファイルとPTS(再生開始PTS)を求め、その値をデマルチプレクサ111とデコーダ112に送る。次に、Address LUTを用いて、再生開始PTSから対応するデータの含まれるVUの先頭アドレス(VU先頭アドレス)とPRUの先頭アドレス(PRU先頭アドレス）を計算する。
【００８６】
このとき、図 21(a)のようにPRUとVUのアドレスの差が小さい場合には、前記VUとPRUのアドレスのうち小さい方のアドレスから読込を始めるようにディスクドライブ109に指令を出す。一方、図 21(b)のようにPRUに比べVUのアドレスがある程度以上大きい、すなわちEU中の後半のVUから再生する場合、CPU102はディスクドライブ109にまずEUSI中のPost Recording Unit Sizeで示されるPRUのデータサイズのデータを前記PRU先頭アドレスから読み込むよう指令を出し、次に前記VU先頭アドレスからの読込を指示する。このようにする理由は、EUの後部のVUから再生を始める場合、その前に位置するVUをスキップした方が無駄なデータの読込がなくなりユーザに対するレスポンスが早くなるためである。
【００８７】
デマルチプレクサ111は、ディスクドライブ109からECCデコーダ112を経由して送られてくるデータをバッファメモリ108に蓄積し、デコーダ112からデータの要求があればデコーダ112に応じたデータを順に送る。デコーダ112は、デマルチプレクサ111に要求し、受け取ったデータのデコードを行なう。再生開始PTSがGOPの途中に相当する場合、ビデオデコーダ112はそのGOPの最初からデコードを行ない、再生開始PTSのタイミングから映像の出力を行なう。オーディオデコーダ112も同様に、デマルチプレクサ111から受け取ったデータのデコードを行ない、再生開始PTSのタイミングから音声の出力を行なう。ビデオデコードの方が時間がかかるため、オーディオデコーダ112はビデオデコーダ112が再生開始PTSの映像出力が可能になるのを待ち、その時点でシステムクロック105を再生開始PTSにセットし、提示を開始する。
【００９１】
【発明の効果】
本願発明によれば、データストリームにおけるユニットの再生時間は、記録媒体の入出力にかかわるシーク時間や、転送レートなどによって求められるため、第２のデータ書き込み時に、再生或いは記録が途切れてしまうという問題がない。
【図面の簡単な説明】
【図１】本発明の一実施形態における構成を示すブロック図である。
【図２】本発明の一実施形態におけるのディスク中のデータ配置である。
【図３】本発明の一実施形態におけるのEUSファイルの概要を示す図である。
【図４】パケットの構造を示す図である。
【図５】本発明の一実施形態におけるのEUの構造を示す図である。
【図６】本発明の一実施形態におけるのVUの構造を示す図である。
【図７】本発明の一実施形態におけるのVU Header Packetの構造を示す図である。
【図８】本発明の一実施形態におけるのアフレコ前のPRUの構造を示す図である。
【図９】本発明の一実施形態におけるのアフレコ後のPRUの構造を示す図である。
【図１０】本発明の一実施形態におけるのPRU Header Packetの構造を示す図である。
【図１１】本発明の一実施形態におけるのPRUの配置に関する図である。
【図１２】本発明の一実施形態におけるのEUS Managementファイルの構造を示す図である。
【図１３】本発明の一実施形態におけるのEUSIの構造を示す図である。
【図１４】本発明の一実施形態におけるのAddress LUTの構造を示す図である。
【図１５】本発明の一実施形態におけるのAddress LUT中のPRU Informationの構造を示す図である。
【図１６】本発明の一実施形態におけるのVU Informationの構造を示す図である。
【図１７】本発明の一実施形態におけるのオリジナルデータ記録のフローチャートである。
【図１８】本発明の一実施形態におけるのPRU管理テーブルの構造を示す図である。
【図１９】本発明の一実施形態におけるのPRU管理テーブル作成のフローチャートである。
【図２０】アフレコ時のヘッドの動きとバッファメモリ108におけるデータの占有率の変化の模式図である。
【図２１】本発明の一実施形態におけるのEUの途中から再生を始める場合のアクセス方法を示す図である。
【図２２】従来技術におけるディスク上での記録形態を示す図である。
【図２３】従来技術におけるアフレコ時のヘッドの動きとバッファメモリ108におけるデータの占有率の変化の模式図である。
【符号の説明】
１０１ 操作部
１０２ CPU
１０３ RAM
１０４ ROM
１０５ システムクロック
１０６ エンコーダ
１０７ マルチプレクサ
１０８ バッファメモリ
１０９ ディスクドライブ
１１０ バス
１１１ デマルチプレクサ
１１２ デコーダ
１１３ ディスク
１１４ ECCエンコーダ・デコーダ[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a process for recording / reproducing video data and audio data on / from a randomly accessible recording medium such as a hard disk or an optical disk.
[0002]
[Prior art]
Video and audio digital recording / reproducing apparatuses using disk media are becoming widespread. In these cases, a technique for realizing an after recording (after-recording) function at a low cost as with a tape medium is required. The post-recording function is a function for adding information, particularly audio, to an already recorded audio or video.
[0003]
Japanese Patent Laid-Open No. 5-234084 discloses a conventional technique for realizing a post-recording function with a disk medium. This technology takes advantage of the fact that the data reading period is shorter than the program presentation period, so that the input after-recording audio data is read from the time the data is read into the memory from the currently presented disk until the next data is read. Can be realized even if there is only one disc recording / reproducing means.
[0004]
Here, the program presentation period is a reproduction period unique to each program such as video and music. For example, a video of 1 minute cannot be said to be played correctly unless it is played back in 1 minute even if the playback means is changed.
[0005]
The recording format of the disk in the prior art is shown in FIG. A disc is composed of a sequence of ECC (Error Collection Coding) blocks. The ECC block is the minimum unit for encoding, and is encoded by adding error correction parity in addition to data. When reading data, the reading error is corrected in this unit, and then necessary data is taken out. On the other hand, when data is rewritten, first, ECC blocks are read and error-corrected data is rewritten with necessary portions, and error codes are assigned again, and the data is recorded on the disk. This means that even when rewriting one byte, it is necessary to read and write the entire ECC block including that byte.
[0006]
Video and audio are arranged in the ECC block in the order of an after-recording audio block, an original audio block, and an original video block as shown in FIG. Each block contains post-recording audio, original audio, and original video corresponding to almost the same time. The original audio block and the original video block are collectively called an original block. When the original program (video before recording the after-recording audio) is recorded, dummy data is written in the after-recording audio block.
[0007]
Next, the operation during post-recording in the prior art will be described with reference to FIG. In the figure, the upper graph shows each means and the relationship between each means and the recording medium. The middle graph schematically shows the position of the head on the disk, and the lower graph schematically shows the ratio of program data in the buffer memory 108.
[0008]
Here, the program is arranged in a continuous area from s11 to s18 on the disk, and s11 to s13, s13 to s15, and s15 to s17 correspond to ECC blocks, respectively, and s11 to s12, s13 to s14, s15 to Assume that s16 and s17 to s18 correspond to post-recording audio blocks, respectively.
[0009]
The area up to s13 has already been stored in the buffer memory 108 at time t1, and the data recorded in s11 to s13 is decoded and presented (reproduced), and after-recording audio input and encoding of the data is performed. Has been done.
[0010]
At times t1 to t3, the data in the areas s13 to s15 are read from the disk and stored in the buffer memory 108 and the after-recording buffer. The post-recording buffer stores the read ECC block as it is, and has a configuration similar to that shown in FIG.
[0011]
Time t2 is the time when decoding and reproduction of the data recorded in s11 to s13 performed at time t1 ends. After time t2, the data from s13 to s15 read at times t1 to t3 are decoded and reproduced, and after-recording audio of the data is input and encoded. The decoding and reproduction of the data of s13 to s15 is performed until t5.
[0012]
The post-recording audio input by t2 is encoded at least by t3. At time t3, the post-recording sound input by t2 is recorded on the disk medium. At this time, it takes time to wait for the rotation of the disk to access s11. However, this time is shorter than the time for reading and writing the disk, and is not considered here.
[0013]
After-recording audio is written to the disc at times t3 to t4. When writing to the disk ends at t4, data from s15 to s17 is read from the disk from t4. In this way, the same processing is repeated thereafter.
[0014]
In this prior art, by utilizing the fact that the reading time is shorter than the data reproduction time by performing information compression, one recording / reproduction is performed by using the recording / reproduction means in time division for recording and reproduction. After-recording is realized only by means.
[0015]
[Problems to be solved by the invention]
As described above, since error correction encoding is performed for each ECC block, even when one byte in the ECC block is rewritten, it is necessary to read and write the entire ECC block including the byte. When post-recording audio data is distributed and arranged in ECC blocks as in the above-described prior art, in order to record post-recording audio data, it is necessary to rewrite most ECC blocks, that is, all of the data. Thus, when performing a dubbing operation by rewriting many ECC blocks, a disk drive having a high read / write speed is used, or the amount of data to be read / written is reduced.
[0016]
Disk drives with high read / write speeds are more expensive than low ones. Further, since it is necessary to increase the number of revolutions of the disk, power consumption is also increased. On the other hand, if you try to achieve post-recording with a low-speed disk drive, the image quality will be reduced and the amount of data will be reduced.
[0017]
The present invention has been made in view of the problems of the prior art, and there is no time lag with the original video even in a disk drive having a relatively low data transfer speed when recording / reproduction can be performed only in units of ECC blocks. Moreover, it aims to realize post-recording without reducing the image quality.
[0018]
[Means for Solving the Problems]
  The present inventionUsing recording and playback means,A first data unit composed of video data or audio data, and a second data unit composed of data reproduced in synchronization with the first data unit.Is an optical discRecording to record on the recording mediumRegenerationA method,
  Managing the plurality of first data units and the second data unit when added to the first data unit later as an editing unit;
  When recording the second data unit while reproducing the first data unit,in frontThe total playback time of the first data unit constituting the editing unit is
  Of the recording / reproducing means for the recording medium.Data transfer in data input / outputspeed,When the recording / reproducing means accesses the recording mediumSeek time,Of the recording medium when the recording / reproducing means accessesRotation waiting time,Recording bit rate of the first data unit and recording of the second data unit in the recording / reproducing meansOf the bit rateat leastBased on oneA minimum value is obtained in which the reproduction of the first data unit and the recording of the second data unit are not interrupted, and the value is equal to or greater than the minimum value.To decide.
[0019]
  The present invention also provides:Using recording and playback means,A first data unit composed of video data or audio data, and a second data unit composed of data reproduced in synchronization with the first data unit.Is an optical discA recording medium for recording on a recording medium,
  Managing the plurality of first data units and the second data unit when added to the first data unit later as an editing unit;
  When recording the second data unit while reproducing the first data unit, the total reproduction time of the first data unit constituting the editing unit is
  Of the recording / reproducing means for the recording medium.Data transfer in data input / outputspeed,When the recording / reproducing means accesses the recording mediumSeek time,Of the recording medium when the recording / reproducing means accessesRotation waiting time,Recording bit rate of the first data unit and recording of the second data unit in the recording / reproducing meansOf the bit rateat leastBased on oneA minimum value is obtained in which the reproduction of the first data unit and the recording of the second data unit are not interrupted, and the value is equal to or greater than the minimum value.It is determined and recorded.
[0020]
  Furthermore, the present invention provides an input means for inputting a first data unit composed of video data or audio data, and a second data unit composed of data reproduced in synchronization with the first data unit;
  Encoding means for managing and encoding the plurality of first data units and the second data unit when added to the first data unit later as an editing unit;
  Record the editing unit on a recording mediumRegenerationRecordRegenerationRecords with meansRegenerationA device,
  The encoding means includes
  When recording the second data unit while reproducing the first data unit, the total reproduction time of the first data unit constituting the editing unit is
  Of the recording / reproducing means for the recording medium.Data transfer in data input / outputspeed,When the recording / reproducing means accesses the recording mediumSeek time,Of the recording medium when the recording / reproducing means accessesRotation waiting time,Recording bit rate of the first data unit and recording of the second data unit in the recording / reproducing meansOf the bit rateat leastBased on oneA minimum value is obtained in which the reproduction of the first data unit and the recording of the second data unit are not interrupted, and the value is equal to or greater than the minimum value.To decide.
[0022]
The present invention is a recording method for recording first data (original data) composed of video or audio and second data (after-recording data) reproduced in synchronization with the first data on a recording medium. The first data for a predetermined reproduction time and the second data reproduced in synchronization with the first data are managed as a first unit (EU (Editable Unit)). In the data stream composed of the first unit, the reproduction time of the first unit is the same, and the reproduction time of the first unit is the data transfer time and seek time at the time of input / output to the recording medium The rotation waiting time is determined based on one of the bit rate of the first data or the second data.
[0025]
DETAILED DESCRIPTION OF THE INVENTION
A first embodiment of the present invention will be described. FIG. 1 shows the configuration of a video disc recorder capable of post-recording in the first embodiment. As shown in the figure, this apparatus includes an operation unit 101, CPU 102, RAM 103, ROM 104, system clock 105, buffer memory 108, encoder 106, multiplexer 107, disk drive 109, bus 110, demultiplexer 111, decoder 112, disk 113. And an ECC encoder / decoder 114.
[0026]
The disk 113 is a detachable optical disk in which recording / reproduction is performed spirally from the outer periphery toward the inner periphery. The ECC block is composed of 16 sectors for error correction with 2048 bytes as one sector. When rewriting data in an ECC block, it is necessary to read the entire ECC block containing the data, perform error correction, rewrite the target data, add the error correction code again, configure the ECC block, and record it on the recording medium There is.
[0027]
The configuration of the disk 113 is shown in FIG. At the top of the disk is file system management information, and the rest is a user area managed in file units by the file system. The user area is divided into a management information area and an AV stream area. The management information area includes files relating to management information, and the AV stream area includes EUS (editable unit sequence) files. The EUS file is a data stream unit file in which a series of video / audio data from the start to the end of video recording is recorded. On the other hand, the file in the management information area includes an EUS Management file storing information related to the EUS file.
[0028]
In this embodiment, each file is accessed through a file system managed by the file system management information. Therefore, it is possible to access a file distributed in the disk like the EUS file # 2 in the figure with continuous logical addresses. The unit for accessing with a logical address is a sector unit. In this embodiment, the description about the file system is omitted because it is not directly related to the invention. Further, the address in the following description refers to a logical address unless otherwise specified.
[0029]
The encoding method used in the present embodiment will be described. Original video is encoded at a variable rate of about 5 Mbps by MPEG-2 encoding, and audio is sampled at 48 kHz for both original and post-recording, and encoded at a fixed rate of 256 kbps for 2 channels by MPEG-1 / Layer II encoding.
[0030]
The EUS file is a file that stores an EUS that is a unit of a multiplexed data stream of video and audio information. Figure 3 shows the general configuration of EUS. The main elements that make up EUS are summarized below.
[0031]
Block: A unit of fixed length of 2048 bytes corresponding to a sector.Video data specified in ISO / IEC 13818-2, audio data specified in ISO / IEC 13818-3, and other data, ISO / IEC 13818 Consists of packetized PES Packet specified by -1.
VU (Video Unit): A unit of random access at the time of playback. If accessed from the top of the VU, it is guaranteed that audio and video are correctly decoded even during the EUS. Consists of Block
PRU (Post Recording Unit): An area for recording post-recording data (post-recording data) related to a plurality of VUs. Consists of Block
EU (Editable Unit): Consists of multiple VUs and 0 or 1 PRU corresponding to them. One EU records continuously in the disc
EUS (Editable Unit Sequence): A unit corresponding to the section of Rec Start to Stop or Pause, and consists of an integer number of EUs.
[0032]
The block in the figure is a unit of a fixed length of 2048 bytes, and one block is stored in one sector. One block is basically composed of one packet. The packet here conforms to the PES packet defined in ISO / IEC 13818-1. Figure 4 shows the packet structure. The packet is composed of a packet header that stores attributes and the like related to the packet and packet data that stores actual data such as video data. The main information included in the packet header is as follows. The packet-start-code-prefix is a packet start code defined by ISO / IEC 13818-1. The stream-id represents the type of this packet. PES-packet-length represents the size of data after this field. PES-header-data-length represents the size of the packet header. PTS (Presentation Time Stamp) is synchronization information between elementary streams such as multiplexed audio and video, and the timing at which the access unit (1 frame in the case of video) containing the beginning is reproduced is 90 kHz. The value counted by the clock is represented by 33 bits. The DTS (Decoding Time Stamp) represents the timing at which the access unit having the head in the packet is decoded on the same time axis as the PTS. The stuffing-bytes is used to adjust the packet size as described below.
[0033]
If the packet is less than 2048 bytes and the shortage is less than 7 bytes, a stuffing byte is inserted in the packet header. On the other hand, when the shortage is 8 bytes or more, a padding packet corresponding to the shortage is placed after the packet. The stuffing byte and padding packet are so-called dummy data that is not actually processed. The packets used in this embodiment are summarized below.
[0034]
V-PKT (Video Packet): A packet containing video data defined by ISO / IEC 13818-2
A-PKT (Audio Packet): A packet containing audio data defined by ISO / IEC 13818-3
P-PKT (Padding Packet): Padding packet defined by ISO / IEC 13818-1
VH-PKT (VU Header Packet): A packet containing a header related to VU
PH-PKT (PRU Header Packet): A packet containing a header related to PRU
V-PKT, A-PKT, and P-PKT formats conform to ISO / IEC 13818-1. Other packet formats will be described later. The blocks that make up the EUS are summarized below.
[0035]
V-BLK (Video Block): A block containing V-PKT
A-BLK (Audio Block): A block containing A-PKT
P-BLK (Padding Block): A block containing P-PKT
VH-BLK (VU Header Block): A block containing VH-PKT
PH-BLK (PRU Header Block): block containing PH-PKT
First, the EU will be explained. Figure 5 shows the EU structure. The EU contains one or more integer VUs and zero or one PRU. The presentation time of the VUs that make up one EUS is the same. In other words, the VU playback interval in one EUS is always the same. However, the last VU of EUS may be shorter than other VUs.
[0036]
In addition, when the VU includes video data, the presentation time of the VU is defined as the number of video fields or video frames included in the VU multiplied by the video field period or video frame period, respectively.
[0037]
The EUs that make up one EUS either include all PRUs or do not include all PRUs. The number of VUs constituting the EU Nvu is constant within the EUS except for the last EU of the EUS. In other words, in one EUS, the EU presentation time interval is always constant. For EUS without PRU, it is not necessary to provide many VUs, so Nvu = 1. On the other hand, in the case of EUS with PRU, the presentation time per VU is Tpv, the rotation waiting time is Tv, the time to jump from the currently loaded track to the track with the after-recording area is Tk, the data transfer rate from the disk is Rs, When the bit rate of the entire EUS is Ro, the bit rate per channel of post-recording audio is Ra, and the number of channels of post-recording audio is Nch,
[0038]
[Expression 1]

[0039]
And Here, ceiling (x) is a function for obtaining the smallest integer greater than or equal to x, and floor (x) is the function for obtaining the largest integer less than or equal to x. In the case of EUS with PRU, the reason for setting the minimum value of Nvu based on the data transfer rate is that if the time per EU is not sufficiently large, the head is This is because the ratio of the overhead for moving from the reading position to the post-recording area increases, and the reading of data cannot catch up with the display and the reproduction of video and audio is interrupted.
[0040]
Next, VU will be described. VU consists of video data consisting of one or more integer GOPs (group of pictures) immediately preceded by a sequence-header followed by a GOP-header, and an integer number of AAUs (audio access Audio data consisting of units). GOP is a unit of MPEG video compression and is composed of a plurality of field groups or frame groups. AAU segments audio samples every 0.024 seconds and compresses each segment. Both GOP and AAU need to be decoded from the beginning of each unit. However, since VU includes an integer number of units, independent playback is possible in units of VU. The number of video fields per VU should be in the range of 24 to 60 fields for NTSC and 20 to 50 fields for PAL.
[0041]
As shown in Fig. 6, the VU has a VU Header Block (VH-BLK) at the beginning, an A-BLK column storing the above-mentioned audio data, and a V-BLK column storing the above-mentioned video data at the end. Arrange in the order of. The number of A-BLKs is necessary and sufficient to store the above audio data. If there is a remainder in the last A-BLK, adjust with P-PKT or stuffing byte as described above. V-BLK has the same configuration.
[0042]
By configuring the EU with a set of VUs, which are units that can be independently reproduced as described above, overhead when reproduction is started from the middle of the EU is reduced. If the transfer rate has no margin compared to the data bit rate, Nvu must be increased, that is, the presentation time per EU must be set longer, but in this case, if a unit such as VU is not provided, for example, the end of the EU Even when playback is started from the vicinity, it must be read from the beginning of the EU, resulting in a decrease in response to the user. In addition, by configuring the VU with an integer number of blocks, that is, sectors, access to the top of the VU is simplified.
[0043]
Figure 7 shows the structure of VH-PKT. BP (byte position) in the figure is a relative byte position from the beginning, and the number of bytes indicates the number of bytes in each field. The packet-start-code-prefix, stream-id, and PES-packet-length are as described above. VU Property is a 1-byte bit field, and stores information on the VU including this VU header. One of them, First VU of EU, is set to 1 if the VU including the VH-PKT is the first VU in the EU, and 0 otherwise. As will be described later, this field is used for synchronization during post-recording. Length of VU represents the number of blocks in the VU including this VU header. Start RLBN of Video Data represents the number of blocks from the beginning of VU to the start of video data.
[0044]
Next, PRU will be described. The PRU is an area for storing audio for one or more integers of VU, and there are 0 or 1 in one EU. The size of the PRU is the smallest integer number of ECC blocks that can contain audio data and PRU header blocks corresponding to the presentation time per EU. Number of ECC blocks that make up a PRU NPRU, ECC
[0045]
[Expression 2]

[0046]
Is defined as The audio data recorded in the PRU is recorded at the same data rate and the same sampling frequency as the VU audio in the EU including the PRU.
[0047]
Figure 8 shows the configuration of the PRU immediately after recording the original data. Record one PRU Header Block (PH-BLK) at the beginning and fill the remaining area with Padding Block (P-BLK). That is, no audio data is recorded immediately after the original data is recorded.
[0048]
Figure 9 shows the PRU configuration after audio has been dubbed into the PRU. One PRU Header Block (PH-BLK) is recorded at the beginning, and then the audio data synchronized with the EU is recorded as an A-BLK column, and the remaining area is filled with P-BLK. At this time, the number of A-BLKs in the PRU is the same as the total number of A-BLKs included in each VU in the same EU. Furthermore, post-recording audio data should be set so that the PTS value of each A-BLK in the PRU takes the same value as the A-BLK PTS included in each VU in the same EU. Record. That is, in the post-recording PRU, there are A-BLK columns corresponding to the A-BLK columns included in each VU. Such a sequence of A-BLK in the PRU corresponding to the VU is called SAU (sub audio unit). Needless to say, the SAU includes an integer number of AAUs as in the VU.
[0049]
Fig. 10 shows the structure of PH-PKT. packet-start-code-prefix, stream-id, and PES-packet-length are the same as those of the VU header packet. Length of PRU describes the number of blocks constituting the PRU included in this PH-PKT. Number of VU represents the number of VUs constituting the EU included in this PH-BLK. Start RLBN of Data for VU represents the number of blocks from the head of each SAU PRU.
[0050]
As described above, by setting the PRU as a set of units (SAU) including an integer number of blocks, that is, an integer number of AAUs, after reading the PRU into the buffer memory 108, the post-record data in the PRU is stored. It becomes easy to rewrite partly in SAU units. This is because the AAU included in each SAU is stored in a packet independent of the AAUs in the other SAUs, and therefore, if rewritten in units of SAUs, the other SAUs are not affected. If such a configuration is not adopted, there will be AAUs included in different SAUs in one packet, and when performing post-recording on a PRU that has already been post-recorded, the packet is solved and the AAU The process of searching for the beginning of the message, rewriting the data and packetizing it again becomes complicated, and the processing becomes complicated.
[0051]
Furthermore, since information indicating the head position of each SAU is inserted in the stream, it is immediately known from which position rewriting should be started when rewriting a PRU in SAU units.
[0052]
In addition, the data in the PRU is structured in the same way as the audio data in the VU. For example, the audio data in the PRU is partially copied into the VU, and data is exchanged between the PRU and the VU. Becomes easier.
[0053]
Describe the placement of PRUs in the EU. The PRU is placed at the ECC boundary within the first 15 sectors of the EU in which it is contained, that is, the first ECC boundary that appears in the EU. For example, if the head of an EU is an ECC block boundary, a PRU is placed immediately after the head of the EU as shown in FIG. 11 (a). Also, if the head of the EU is not an ECC block boundary, place it on the ECC block boundary within 15 logical blocks immediately after the EU boundary, that is, the ECC block boundary that appears first in the EU, as shown in (b) . In this case, the leading VU in the EU will be divided by the PRU.
[0054]
As described above, by setting the PRU size to an integer multiple of the ECC block size and placing the PRU on the ECC block boundary, the data to be rewritten on the recording medium is only the PRU during post-recording, and the area to be rewritten There is an advantage that can be minimized.
[0055]
In the above embodiment, the reason why the PRU is near the head of the EU is that when reproducing a certain EU, synchronized playback of the VU and PRU becomes possible when the entire PRU and one VU are read. If the PRU is near the end of the EU, the program cannot be replayed until most of the EU data has been read, and a buffer memory is required to store almost the entire EU.
[0056]
Figure 12 shows the structure of the EUS Management file. The EUS Management file stores information for managing all EUS files recorded on the disc. Hereinafter, only items essential for the description of the present embodiment will be described. A field Number of EUSI represents the number of EUS files managed by this file. A field EUSI (EUS Information) is information about each EUS file, and there are Number of EUSI items. EUSI is further organized as shown in Figure 13. Start PT and End PT in the figure are obtained by omitting the most significant bits of the start PTS and end PTS in the EUS file managed by EUSI. Hereinafter, such a format in which the most significant bit of the PTS is omitted will be referred to as a PT format. Post Recording Unit Size represents the size of the PRU in the EUS file managed by this EUSI.
[0057]
The Address LUT (Lookup Table) is a table for searching an address where data corresponding to the time code is recorded from the time code described in the PT format. Figure 14 shows the configuration of the Address LUT. The field PB Time of EU represents the presentation time per EU in units of 1/90000 [seconds] and has the same scale as the PT format. Similarly, PB Time of VU represents the presentation time per VU in units of 1/90000 [seconds]. Number of PRU Information is the number of PRU Information in the Address LUT and also represents the number of PRUs in the EUS. Similarly, Number of VU Information represents the number of VU Information in the Address LUT and the number of VUs in the EUS.
[0058]
Fig. 15 shows the contents of PRU Information. RLBN of PRU in the figure represents the address of the PRU managed by the PRU Information. Fig. 16 shows the contents of VU Information. RLBN of VU in the figure represents the address of the VU managed by the VU Information.
[0059]
A procedure for obtaining an address of a PRU corresponding to a certain time code PT using the Address LUT is described below. First, the relative PT is obtained by subtracting StartPT in EUSI from PT, then the relative PT is divided by PB Time of EU, and the fractional part is rounded down to obtain the PRU Information index that manages the PRU corresponding to that PT. I want. Next, the address given by RLBN of PRU in the PRU Information corresponding to the index is the address of the PRU corresponding to the target PT. Similarly, for the VU address corresponding to time PT, refer to RLBN of VU in VU Information of the index corresponding to the value obtained by dividing PT by Start PT and dividing by PB Time of VU and truncating the fractional part. It is obtained with. The reason why the start address of VU or PRU can be obtained by such simple processing is that the presentation time per EU and VU is constant.
[0060]
The procedure for recording, reproducing and post-recording in the above disk format is shown below. In the following description, video is recorded in NTSC, VU is composed of one GOP consisting of 30 fields, and the maximum video bit rate is 8 [Mbps]. The disk transfer rate Rs is 12 [Mbps], the maximum jump time Tk to the after-recording area is 0.3 [second], and the maximum rotation waiting time Tv is 0.2 [second]. Also, the audio bit rate and the number of audio channels are set to 0.125 [Mbps / channel] and 2 [channel], respectively, and are used in common for the original and after-recording. At this time, the presentation time Tpv per VU is about 0.5 seconds. Further, the range of the number of VUs Nvu per EU where after-recording is possible is 7 ≦ Nvu ≦ 20. In this embodiment, Nvu = 8, that is, the presentation time per EU is about 4 seconds.
[0061]
The flow of processing of the CPU 102 when recording the original program will be described with reference to FIG. It is assumed that the EUS Management file and file system management information have already been read from the disk into the RAM 103. The CPU 102 activates the encoder 106 (step 1), and then checks whether there is sufficient continuous area on the disk to record 1 EU worth of data based on the file system management information (step 2). If not, recording is stopped (step 12).
[0062]
If there is a sufficient area, the variable i indicating the VU of the VU to be recorded is reset to 0, and the free area head address is stored in the variable addr (step 3). Next, it waits for notification from the multiplexer 107 that 1 VU worth of data has been buffered in the buffer memory 108 (step 4). When a notification is received from the multiplexer 107, if the variable i is 0 (step 5), it is determined whether the variable addr is an ECC block boundary (step 9). If it is not an ECC block boundary, the next ECC block boundary is determined. Until the VU data in the buffer memory 108 is recorded on the disk (step 10).
[0063]
Next, the PRU is configured in the RAM 103 with the PH-PKT and the P-PKT, and is recorded on the disk (step 11). Next, the top VU data in the buffer memory 108 is recorded on the disk (step 6). When recording is completed, the variable i is incremented (step 7). If the variable i is smaller than the variable Nvu representing the number of VUs in the EU, the process jumps to step 4 (step 8), and if equal, the process jumps to step 2. The above processing is performed in units of EU until a stop command is issued from the operation unit 101 or there is no sufficient continuous area in the disk.
[0064]
In parallel with the processing of the CPU 102 described above, the multiplexer 107 appends PTS or the like to the data transmitted from the audio and video encoders 106, packetizes them, and stores them in the buffer memory 108. When the V-PKT for 1 GOP and the A-PKT synchronized therewith are stored in the buffer memory 108, the CPU 102 is notified that data for VU has been buffered.
[0065]
A flow of processing when an instruction to start after-recording is given from the user during reproduction of the original program recorded in the above procedure will be described. It is assumed that the EUS Management file and file system management information have already been read from the disk into the RAM 103. The CPU 102 activates the decoder 112 and issues a command to the disk drive 109 to read the designated EUS file from the beginning based on the file system management information. The disk drive 109 sends the read data to the demultiplexer 111 via the ECC decoder 112, and the demultiplexer 111 accumulates the data in the buffer memory 108. The decoder 112 requests the demultiplexer 111 for data required for video and audio reproduction, and the demultiplexer 111 sends the data stored in the buffer memory 108 in response to the request based on the stream-id in the packet header. Send to decoder 112. When the decoder 112 receives sufficient data from the demultiplexer 111 and can output video and audio, it initializes the system clock 105 with the PTS corresponding to the data, and thereafter outputs it based on the value of the system clock 105. Take the synchronization.
[0066]
The demultiplexer 111 always stores in the buffer memory 108 a total of two PRUs, that is, the PRU corresponding to the data currently being played back and the PRU corresponding to the EU to be played back next time when the user instructs post-recording. Hold. Further, a table (PRU management table) for managing those PRUs is created in the RAM 103.
[0067]
Figure 18 shows the configuration of the PRU management table. The PRU management table is composed of two tables, SAU start PTS (SAU-PTS [j] [i]) and SAU start address (RLBN [j] [i]). SAU-PTS [j] [i] is a two-dimensional array, where the first index represents the PRU number in the buffer memory 108 and the second index represents the SAU number in the PRU. The first PTS of SAU can be obtained with the index. RLBN [j] [i] has a similar structure, and it is possible to obtain the relative address of the SAU with the PRU number and the SAU number in the PRU as an index and using the head of the PRU as a reference. By using these two tables, it is possible to know which SAU in the buffer memory 108 should record data corresponding to a certain PTS.
[0068]
A process when a user gives an instruction to perform post-recording through the operation unit 101 during the above reproduction process will be described. First, the CPU 102 activates the audio encoder 106. The demultiplexer 111 obtains the time stamp (after-recording start PTS) when the after-recording is started from the system clock 105, and the maximum PTS that does not exceed the after-recording start PTS from the above-mentioned SAU-PTS [j] [i]. Search for indexes with. The demultiplexer 111 notifies the multiplexer 107 of the PRU number n and SAU number m obtained as a result of the search together with the post-recording start PTS. The multiplexer 107 stores the AAU sent from the encoder 106 from the position of RLBN [n] [m] of the nth PRU in the buffer memory 108. Depending on the difference between the first PTS of the SAU that starts recording and the after-recording PTS, the multiplexer 107 inserts a silent AAU corresponding to the difference before the AAU sent from the audio encoder 106 before packetization. Adjust.
[0069]
An example will be described in which the value of the system clock 105 at the time when post-recording is instructed by the user, that is, the post-recording start PTS is 228228. First, a pair of SAU numbers and PRU numbers having the maximum SAU start PTS that does not exceed the after-record start PTS in SAU-PTS [i] [j] is searched. In the case of FIG. 18, PRU number = 0 and SAU number = 5. Next, look at the value of RLBN [0] [5] corresponding to that number. As a result, the address 41 of SAU # 5 is obtained. Therefore, after-recording data is recorded from SAU # 5 existing in the 41st block from the beginning of PRU # 0 in the buffer memory 108.
[0070]
When the index of the PRU that is storing the post-record data is n, when the data is stored up to the end of the PRU, the value of RLBN [n] [i] from i = 0 to 7 is set to the PH in the current PRU. -Store sequentially in the field Start RLBN of Data for VU of PKT, and notify the CPU 102 that data has been stored up to the end of the PRU. At that time, SAU-PTS [n] [0], that is, the EU top PTS including the PRU is also notified. On the other hand, the CPU 102 records the post-recording audio data by referring to the Address LUT based on the EU top PTS obtained at the time of notification from the multiplexer 107 while reproducing the original program. The address of the PRU on the disk 113 to be obtained is obtained, and the disk drive 109 is instructed to record the nth PRU in the buffer memory 108 at the address. Thereafter, after-recording data input to the PRU in the buffer memory is alternately stored.
[0071]
Figure 19 shows the procedure for creating the PRU management table. The basic idea is that the number of A-BLKs included in each VU is obtained from the Start RLBN of Video in the VH-PKT, and the number is the same as the number of A-BLKs included in the SAU. The first address table is constructed, and at the same time, the PTS of the first A-PKT in the VU is extracted to construct the SAU first PTS table. First, VH-flg which is a flag indicating that it is immediately after VH-PKT is reset, and j which is an index indicating a PRU number in the buffer memory 108 is set to 1 (step 1). If the packet arriving at the demultiplexer 111 is VH-PKT (step 2), the process jumps to step 3, otherwise jumps to step 7.
[0072]
If the packet is a VH-PKT, check whether the First VU of EU field in the VH-PKT is 1 (step 3). If 1, the area for storing subsequent data is changed from the current PRU to the other PRU. Increment j to change. At the same time, 1 is set to RLBN [j] [0]. Further, the value of the Start RLBN of Video field in the current VH-PKT is set in the temporary variable tmp, and 0 is set in i (step 4). If the FirstVU of EU field is 0, the temporary variable tmp is set in RLBN [j] [i], and the value of the Start RLBN of Video field in the current VH-PKT is added to tmp. Step 6). Here, 1 is subtracted from the Start RLBN of Video, which is the value obtained by adding the number 1 of VH-BLK to the number of A-BLK in VU, and the number of A-BLK in VU required here is obtained. This means subtracting VH-BLK. Next, regardless of the First VU of EU field, 1 is set in VH-flg and i is incremented (step 5).
[0073]
In step 7, it is checked whether the packet arriving at the demultiplexer 111 is A-PKT. If it is A-PKT, the process jumps to step 8, and if it is not A-PKT, the process jumps to step 2. In step 8, the variable VH-flg is checked. If VH-flg is 1, the PTS in the packet header of the packet is set to SAU-PTS [j] [i] and VH-flg is reset to 0. (Step 9). By performing the above processing for each block, when all EUs are read, a PRU management table for PRUs in that EU can be created.
[0074]
The temporal change of the head position in the disk and the original data amount in the buffer memory 108 during the above-described post-recording will be described with reference to FIG. Here, the program is arranged in a continuous area of s11 to s18 on the disk, s11 to s13, s13 to s15, s15 to s17 correspond to EU, s11 to s12, s13 to s14, s15 to s16 , S17 to s18 each correspond to a PRU.
[0075]
At time t1, it is assumed that all the areas up to s13 have already been read into the buffer memory 108, and the video in the areas s11 to s13 has been presented and the after-recording audio is input while watching it. It is assumed that the input after-recording audio is stored in one PRU (PRU # 0) in the buffer memory 108.
[0076]
At times t1 to t3, the disk drive 109 reads the areas s13 to s15. The time t2 corresponds to the time when the VUs in the areas s12 to s13 read up to the time t1 are used up for video playback.
[0077]
Time t3 corresponds to the time when encoding of the after-recording audio that is input by looking at the presentation of the VU in the areas s12 to s13 ends. At this point, data is recorded up to the end of PRU # 0, and multiplexer 107 notifies CPU 102 of the leading PTS of that PRU, and switches the post-recording audio storage destination to the other PRU (PRU # 1).
[0078]
Here, the reading from the disc and the encoding of the after-recording audio are completed at the time t3, but it goes without saying that they need not be simultaneously.
[0079]
The CPU 102 obtains the address where the contents of PRU # 0 are to be recorded from the head PTS sent from the multiplexer 107, that is, the addresses of the areas s11 to s12, and records the contents of PRU # 0 on the disk 113 at times t3 to t4.
[0080]
At time t5, the next areas s15 to s17 are read. This timing may be after the end of writing at t4. If reading is started at a timing (between t4 and t6) in which the buffer memory 108 does not overflow and all the data in the buffer memory 108 does not disappear (underflow). Good. Thereafter, the same processing is repeated.
[0081]
According to the present embodiment, since the time for writing after-recording data is shorter than that in the prior art, the time between t4 and t5 in FIG. 20 can be shortened. This means that even if the presentation time for the disc reading time is short (when a large amount of information is allocated during a unit time or when the disc reading transfer rate is low), the video and audio are not interrupted. There is an effect.
[0082]
In this embodiment, the field Start RLBN of Data for VU in the PH-PKT is recorded at the time of post-recording. However, since it is a fixed value, it may be recorded in advance at the time of recording original data. Furthermore, it is possible to add a field for recording the first PTS of each SAU in the PH-PKT. In that case, by recording a value in the field in advance when recording the original data, it is possible to obtain information necessary for constructing the PRU management table simply by reading the PH-PKT during post-recording. Is no longer necessary.
[0083]
In this embodiment, the First VU of EU field in the VH-PKT is used as information representing the head of the EU. However, a packet representing the EU boundary may be inserted at the head of the EU.
[0084]
In this embodiment, the SAU and VU presentation times are the same, but this is not essential. In particular, by making the SAU presentation time shorter than VU, for example, half or 1/4, the after-recording start / end time can be made more precise. For example, in this embodiment, when post-recording is started in the middle of the EUS where the post-recording data has been recorded, in the worst case, the recorded post-recording data near 1 SAU (= 1 VU) before and after the post-recording section is overwritten silently. It will end up. However, if SAU is made shorter in time than VU, the range overwritten with silence can be reduced.
[0085]
A procedure for reproducing from the middle of a program that has been dubbed in the above procedure will be described. It is assumed that the file system management information and the EUS Management file have already been read from the disk into the RAM 103. The CPU 102 obtains the corresponding EUS file and PTS (reproduction start PTS) from the program and timing designated by the user, and sends the values to the demultiplexer 111 and the decoder 112. Next, using the Address LUT, the VU start address (VU start address) and the PRU start address (PRU start address) containing the corresponding data are calculated from the playback start PTS.
[0086]
At this time, if the difference between the PRU and VU addresses is small as shown in FIG. 21 (a), the disk drive 109 is instructed to start reading from the smaller one of the VU and PRU addresses. On the other hand, as shown in Fig. 21 (b), when the VU address is somewhat larger than the PRU, that is, when playback is performed from the VU in the latter half of the EU, the CPU 102 first indicates the disk drive 109 with the Post Recording Unit Size in the EUSI. A command is issued to read data of the PRU data size from the PRU head address, and then reading from the VU head address is instructed. The reason for this is that, when playback is started from the VU at the rear of the EU, if the VU located before that is skipped, useless data is not read and the response to the user is quicker.
[0087]
The demultiplexer 111 accumulates data sent from the disk drive 109 via the ECC decoder 112 in the buffer memory 108, and sends data corresponding to the decoder 112 in sequence if there is a data request from the decoder 112. The decoder 112 requests the demultiplexer 111 to decode the received data. When the playback start PTS corresponds to the middle of a GOP, the video decoder 112 performs decoding from the beginning of the GOP and outputs a video from the timing of the playback start PTS. Similarly, the audio decoder 112 decodes the data received from the demultiplexer 111 and outputs audio from the timing of the reproduction start PTS. Since video decoding takes more time, the audio decoder 112 waits for the video decoder 112 to be able to output the playback start PTS video, at which point the system clock 105 is set to the playback start PTS and presentation is started. .
[0091]
【The invention's effect】
  According to the present invention, since the reproduction time of the unit in the data stream is determined by the seek time related to input / output of the recording medium, the transfer rate, etc., the reproduction or recording is interrupted when writing the second data. There is no.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a configuration in an embodiment of the present invention.
FIG. 2 is a data arrangement in a disk according to an embodiment of the present invention.
FIG. 3 is a diagram showing an outline of an EUS file in an embodiment of the present invention.
FIG. 4 is a diagram illustrating a packet structure.
FIG. 5 is a diagram showing an EU structure according to an embodiment of the present invention.
FIG. 6 is a diagram showing a structure of a VU in an embodiment of the present invention.
FIG. 7 is a diagram illustrating a structure of a VU Header Packet in an embodiment of the present invention.
FIG. 8 is a diagram showing a structure of a PRU before dubbing in an embodiment of the present invention.
FIG. 9 is a diagram showing the structure of a PRU after dubbing in an embodiment of the present invention.
FIG. 10 is a diagram showing a structure of a PRU Header Packet in one embodiment of the present invention.
FIG. 11 is a diagram relating to the arrangement of PRUs in one embodiment of the present invention.
FIG. 12 is a diagram showing a structure of an EUS Management file in an embodiment of the present invention.
FIG. 13 is a diagram showing a structure of EUSI in one embodiment of the present invention.
FIG. 14 is a diagram illustrating the structure of an Address LUT according to an embodiment of the present invention.
FIG. 15 is a diagram showing a structure of PRU information in the Address LUT according to the embodiment of the present invention.
FIG. 16 is a diagram showing the structure of VU Information in one embodiment of the present invention.
FIG. 17 is a flowchart of original data recording according to an embodiment of the present invention.
FIG. 18 is a diagram showing a structure of a PRU management table in an embodiment of the present invention.
FIG. 19 is a flowchart for creating a PRU management table in an embodiment of the present invention;
FIG. 20 is a schematic diagram of the movement of the head during post-recording and the change in the data occupancy rate in the buffer memory 108;
FIG. 21 is a diagram showing an access method when reproduction is started from the middle of EU in one embodiment of the present invention.
FIG. 22 is a diagram showing a recording form on a disc in the prior art.
FIG. 23 is a schematic diagram showing a change in head movement and a data occupancy rate in the buffer memory 108 during post-recording in the prior art.
[Explanation of symbols]
101 Operation unit
102 CPU
103 RAM
104 ROM
105 System clock
106 Encoder
107 multiplexer
108 Buffer memory
109 disk drive
110 bus
111 Demultiplexer
112 decoder
113 discs
114 ECC encoder / decoder

Claims (3)

Using a recording / reproducing means, a first data unit composed of video data or audio data and a second data unit composed of data reproduced in synchronization with the first data unit are recorded on a recording medium which is an optical disk. A recording method for recording,
Managing the plurality of first data units and the second data unit when added to the first data unit later as an editing unit;
When recording the second data unit while reproducing the first data unit, the total reproduction time of the first data units constituting the front Symbol editing unit,
A data transfer speed at the data input / output of the recording / reproducing means with respect to the recording medium, a seek time when the recording / reproducing means accesses the recording medium, a rotation waiting time of the recording medium when the recording / reproducing means accesses , the recording / reproducing The reproduction of the first data unit and the recording of the second data unit are interrupted based on at least one of the reproduction bit rate of the first data unit and the recording bit rate of the second data unit. A recording method characterized in that a minimum value having no difference is obtained and determined so as to be equal to or greater than the minimum value . Using a recording / reproducing means, a first data unit composed of video data or audio data and a second data unit composed of data reproduced in synchronization with the first data unit are recorded on a recording medium which is an optical disk. A recording medium for recording,
Managing the plurality of first data units and the second data unit when added to the first data unit later as an editing unit;
When recording the second data unit while reproducing the first data unit, the total reproduction time of the first data unit constituting the editing unit is
A data transfer speed at the data input / output of the recording / reproducing means with respect to the recording medium, a seek time when the recording / reproducing means accesses the recording medium, a rotation waiting time of the recording medium when the recording / reproducing means accesses , the recording / reproducing The reproduction of the first data unit and the recording of the second data unit are interrupted based on at least one of the reproduction bit rate of the first data unit and the recording bit rate of the second data unit. What is claimed is: 1. A recording medium , comprising: obtaining a minimum value having no difference, determining and recording the minimum value to be equal to or greater than the minimum value Input means for inputting a first data unit made of video data or audio data and a second data unit made of data reproduced in synchronization with the first data unit;
Encoding means for managing and encoding the plurality of first data units and the second data unit when added to the first data unit later as an editing unit;
A recording / reproducing apparatus comprising recording / reproducing means for recording / reproducing the editing unit on / from a recording medium,
The encoding means includes
When recording the second data unit while reproducing the first data unit, the total reproduction time of the first data unit constituting the editing unit is
A data transfer speed at the data input / output of the recording / reproducing means with respect to the recording medium, a seek time when the recording / reproducing means accesses the recording medium, a rotation waiting time of the recording medium when the recording / reproducing means accesses , the recording / reproducing The reproduction of the first data unit and the recording of the second data unit are interrupted based on at least one of the reproduction bit rate of the first data unit and the recording bit rate of the second data unit. A recording / reproducing apparatus characterized in that a minimum value having no difference is obtained and determined to be equal to or greater than the minimum value .

Images