(57)【特許請求の範囲】
【請求項１】
少なくともビデオストリームとオーディオストリームが多重化された第１の多重化ストリームの最後のピクチャである第１のピクチャに第２の多重化ストリームの最初のピクチャである第２のピクチャが連続して再生されるよう接続された多重化ストリームを復号する情報処理装置において、
上記多重化ストリームのアライバルタイムスタンプに従ってソースパケットを出力する出力手段と、
上記ソースパケットのうちビデオデータをバッファリングするビデオバッファと、
上記ソースパケットのうちオーディオデータをバッファリングするオーディオバッファと、
上記ビデオバッファにバッファリングされたビデオデータを復号するビデオ復号手段と、
上記オーディオバッファにバッファリングされたオーディオデータを復号するオーディオ復号手段とを有し、
上記第１の多重化ストリームの最後のビデオパケットが、エレメンタリストリームのトランスポートバッファに入力終了する時刻Ｔ１から、上記第１の多重化ストリームの最後のバイトが入力終了するまでの時刻Ｔ２までの間において、ソースパケットの入力を、上記第１の多重化ストリームのソースパケットのアライバルタイムスタンプによって決定するとともに、
上記オーディオバッファは、上記第２のピクチャの最大のビット量をそのデコードタイミングまでに上記ビデオバッファに入力するために要する時間分のオーディオデータをバッファリング可能な容量を有し、
上記オーディオバッファに必要な容量をEBn_max（bits）とし、上記第２のピクチャのビット量をI_max（bits）とし、上記ビデオバッファへの入力ビットレートをRv(bps)とし、オーディオデータのビットレートをRa（bps）としたとき、
EBn_max＝（I_max／Rv）×Ra
を満たす
情報処理装置。
【請求項２】
上記第２のピクチャは、フレーム内符号化画像である請求項１記載の情報処理装置。
【請求項３】
上記オーディオバッファは、上記第２のピクチャを０．５秒ごとに符号化する場合、少なくとも１００ミリ秒分のオーディオデータをバッファリング可能な容量を有する請求項１記載の情報処理装置。
【請求項４】
上記第１の多重化ストリームの時間軸における上記第１のピクチャの表示終了時刻と上記第２の多重化ストリームの時間軸における上記第２のピクチャの表示開始時刻との時間差をSTC_deltaとし、上記第１の多重化ストリームの最後のソースパケットの最後のバイトが上記出力手段から出力される該第１の多重化ストリームの時間軸上の値STC1１ｅｎｄを上記時間差STC_deltaにより上記第２の多重化ストリームの時間軸上の値に換算した値をSTC2１ｅｎｄ（＝STC1１ｅｎｄ−STC_delta）とし、上記第２の多重化ストリームの最初のパケットの最初のバイトが上記出力手段から出力される該第２の多重化ストリームの時間軸上の値をSTC2２ｓｔａｒｔとしたとき、上記多重化ストリームは、
STC2２ｓｔａｒｔ＞STC2１ｅｎｄ
を満たす請求項１記載の情報処理装置。
【請求項５】
上記第１の多重化ストリームの時間軸における上記第１のピクチャの表示終了時刻と上記第２の多重化ストリームの時間軸における上記第２のピクチャの表示開始時刻との時間差をSTC_deltaとし、上記第１の多重化ストリームの最後のソースパケットの最後のバイトが上記出力手段から出力される該第１の多重化ストリームの時間軸上の値STC1１ｅｎｄを上記時間差STC_deltaにより上記第２の多重化ストリームの時間軸上の値に換算した値をSTC2１ｅｎｄ（＝STC1１ｅｎｄ−STC_delta）とし、上記第２の多重化ストリームの最初のパケットの最初のバイトが上記出力手段から出力される該第２の多重化ストリームの時間軸上の値をSTC2２ｓｔａｒｔとし、上記第１の多重化ストリームの最後のパケットが上記出力手段から出力された後、所定時間delta1の経過後に上記第２の多重化ストリームの最初のパケットを上記出力手段から出力するものとしたとき、上記多重化ストリームは、
STC2２ｓｔａｒｔ＞STC2１ｅｎｄ＋delta1
を満たす請求項１記載の情報処理装置。
【請求項６】
上記第１及び第２の多重化ストリームにおけるオーディオデータは、マルチチャンネルのオーディオデータからなる請求項１記載の情報処理装置。
【請求項７】
少なくともビデオストリームとオーディオストリームが多重化された第１の多重化ストリームの最後のピクチャである第１のピクチャに第２の多重化ストリームの最初のピクチャである第２のピクチャが連続して再生されるよう接続された多重化ストリームを復号する情報処理方法において、
上記多重化ストリームのアライバルタイムスタンプに従ってソースパケットを出力する出力工程と、
上記ソースパケットのうちビデオデータをビデオバッファにバッファリングし、オーディオデータをオーディオバッファにバッファリングするバッファリング工程と、
上記ビデオバッファ及びオーディオバッファにバッファリングされた夫々ビデオデータ及びオーディオデータを復号する復号工程とを有し、
上記第１の多重化ストリームの最後のビデオパケットが、エレメンタリストリームのトランスポートバッファに入力終了する時刻Ｔ１から、上記第１の多重化ストリームの最後のバイトが入力終了するまでの時刻Ｔ２までの間において、ソースパケットの入力を、上記第１の多重化ストリームのソースパケットのアライバルタイムスタンプによって決定するとともに、
上記バッファリング工程では、上記第２のピクチャの最大のビット量をそのデコードタイミングまでに上記ビデオバッファに入力するために要する時間分のオーディオデータを、上記第２のピクチャを上記ビデオバッファにバッファリングする前に上記オーディオバッファにバッファリングし、
上記オーディオバッファに必要な容量をEBn_max（bits）とし、上記第２のピクチャのビット量をI_max（bits）とし、上記ビデオバッファへの入力ビットレートをRv(bps)とし、オーディオデータのビットレートをRa（bps）としたとき、
EBn_max＝（I_max／Rv）×Ra
を満たす
情報処理方法。
【請求項８】
少なくともビデオストリームとオーディオストリームが多重化された第１の多重化ストリームの最後のピクチャである第１のピクチャに第２の多重化ストリームの最初のピクチャである第２のピクチャが連続して再生されるよう接続された多重化ストリームを復号する処理をコンピュータに実行させるためのプログラムであって、
上記多重化ストリームのアライバルタイムスタンプに従ってソースパケットを出力する出力工程と、
上記ソースパケットのうちビデオデータをビデオバッファにバッファリングし、オーディオデータをオーディオバッファにバッファリングするバッファリング工程と、
上記ビデオバッファ及びオーディオバッファにバッファリングされた夫々ビデオデータ及びオーディオデータを復号する復号工程とを有し、
上記第１の多重化ストリームの最後のビデオパケットが、エレメンタリストリームのトランスポートバッファに入力終了する時刻Ｔ１から、上記第１の多重化ストリームの最後のバイトが入力終了するまでの時刻Ｔ２までの間において、ソースパケットの入力を、上記第１の多重化ストリームのソースパケットのアライバルタイムスタンプによって決定するとともに、
上記バッファリング工程では、上記第２のピクチャの最大のビット量をそのデコードタイミングまでに上記ビデオバッファに入力するために要する時間分のオーディオデータを、上記第２のピクチャを上記ビデオバッファにバッファリングする前に上記オーディオバッファにバッファリングし、
上記オーディオバッファに必要な容量をEBn_max（bits）とし、上記第２のピクチャのビット量をI_max（bits）とし、上記ビデオバッファへの入力ビットレートをRv(bps)とし、オーディオデータのビットレートをRa（bps）としたとき、
EBn_max＝（I_max／Rv）×Ra
を満たす
プログラム。
【請求項９】
少なくともビデオストリームとオーディオストリームが多重化された第１の多重化ストリームの最後のピクチャである第１のピクチャに第２の多重化ストリームの最初のピクチャである第２のピクチャが連続して再生されるよう接続された多重化ストリームを復号する処理をコンピュータに実行させるためのプログラムが記録されたコンピュータ読み取り可能な記録媒体であって、
上記多重化ストリームのアライバルタイムスタンプに従ってソースパケットを出力する出力工程と、
上記ソースパケットのうちビデオデータをビデオバッファにバッファリングし、オーディオデータをオーディオバッファにバッファリングするバッファリング工程と、
上記ビデオバッファ及びオーディオバッファにバッファリングされた夫々ビデオデータ及びオーディオデータを復号する復号工程とを有し、
上記第１の多重化ストリームの最後のビデオパケットが、エレメンタリストリームのトランスポートバッファに入力終了する時刻Ｔ１から、上記第１の多重化ストリームの最後のバイトが入力終了するまでの時刻Ｔ２までの間において、ソースパケットの入力を、上記第１の多重化ストリームのソースパケットのアライバルタイムスタンプによって決定するとともに、
上記バッファリング工程では、上記第２のピクチャの最大のビット量をそのデコードタイミングまでに上記ビデオバッファに入力するために要する時間分のオーディオデータを、上記第２のピクチャを上記ビデオバッファにバッファリングする前に上記オーディオバッファにバッファリングし、
上記オーディオバッファに必要な容量をEBn_max（bits）とし、上記第２のピクチャのビット量をI_max（bits）とし、上記ビデオバッファへの入力ビットレートをRv(bps)とし、オーディオデータのビットレートをRa（bps）としたとき、
EBn_max＝（I_max／Rv）×Ra
を満たす
プログラムが記録された記録媒体。
【発明の詳細な説明】
【０００１】
本発明は、ビデオストリームとオーディオストリームとの多重化ストリームをビデオフレーム精度で編集して、編集点を連続的（シームレス）に再生するための情報処理装置、その方法、プログラム及び記録媒体に関する。
【０００２】
【従来の技術】
ビデオストリームとオーディオストリームの多重化ストリームをビデオフレーム精度で編集して、編集点をシームレスに再生するための方法が下記特許文献１乃至３に記載されている。
【０００３】
図１２は、従来のDVR-STDモデル（DVR MPEG2 transport stream player model）（以下、プレーヤという。）１０１を示すブロック図である。DVR-STDは、シームレス接続された２つのPlayItemによって参照されるAVストリームの生成および検証の際におけるデコード処理をモデル化するための概念モデルである。
【０００４】
図１２に示すように、プレーヤ１０１においては、読出部（DVRdrive）１１１からビットレートRＵＤで読み出されたTS（トランスポートストリーム）ファイルは、リードバッファ１１２にバッファリングされ、このリードバッファ１１２からソースパケットがソースデパケッタイザ部（１source depacketizer）１１３へ最大ビットレートRＭＡＸで読み出される。
【０００５】
パルス発振器（27MHz X-tal）１１４は、２７ＭＨｚのパルスを発生する。アライバルクロックカウンタ（Arrival time clock counter）１１５は、この２７MHzの周波数のパルスをカウントするバイナリカウンタであり、ソースデパケッタイザ部１１３に、時刻t(i)におけるArrival time clock counterのカウント値Arrival_time_clock(i)を供給する。
【０００６】
１つのソースパケットは、１つのトランスポートパケットとそれのarrival_time_stampを持つ。現在のソースパケットのarrival_time_stampがarrival_time_clock(i)のＬＳＢ（least significant Bit：最下位ビット）３０ビットの値と等しい時、ソースデパケッタイザ部１１３からそのトランスポートパケットが出力される。TS_recording_rateは、トランスポートストリーム（以下、TSという。）のビットレートである。また、図１２に示すn、TBn、MBn、EBn、TBsys、Bsys、Rxn、Rbxn、Rxsys、Dn、Dsys、On及びPn(k)の表記方法は、ISO/IEC13818-1 (MPEG2 Systems規格)のT-STD（ISO/IEC 13818-1で規定されるtransport stream system target decoder）に定義されているものと同じである。
【０００７】
次に、このような従来のプレーヤ１０１におけるデコーディングプロセスについて説明する。先ず、１つのDVR MPEG2 TSを再生している時のデコーディングプロセスを説明する。単一のDVR MPEG2TSを再生している間は、出力部１１０からトランスポートパケットを出力してデコーダ１２０であるDVR-STDのTB1、TBn又はTBsysのバッファへ入力するタイミングは、ソースパケットのarrival_time_stampにより決定される。TB1、MB1、EB1、TBn、Bn、TBsys及びTBsysのバッファリング動作の規定は、ISO/IEC 13818-1に規定されているT-STDと同じである。復号動作と表示動作の規定もまた、ISO/IEC 13818-1に規定されているT-STDと同じである。
【０００８】
次に、シームレス接続されたPlayItemを再生している間のデコーディングプロセスについて説明する。ここでは、シームレス接続されたPlayItemによって参照される先行するストリームTS1と、現在のストリームTS2との再生について説明をする。
【０００９】
あるAVストリーム（TS1）からそれにシームレスに接続された次のAVストリーム（TS2）へと移る間には、TS2のアライバルタイムベースの時間軸は、TS1のアライバルタイムベースの時間軸と同じ時間軸でない。また、TS2のシステムタイムベースの時間軸は、TS1のシステムタイムベースの時間軸と同じ時間軸でない。ビデオの表示は、シームレスに連続していることが要求される。オーディオのプレゼンテーションユニットの表示時間にはオーバーラップがあってもよい。
【００１０】
次に、ソースデパケッタイザ部から読み出されるトランスポートパケットのDVR-STDへの入力タイミングについて説明する。
【００１１】
（１）TS1の最後のビデオパケットがDVR-STDのTB1に入力終了する時刻Ｔ１までの時間
時刻Ｔ１までの時間は、DVR-STDのTB1、TBn又はTBsysのバッファへの入力タイミングは、TS1のソースパケットのarrival_time_stampによって決定される。
【００１２】
（２）時刻Ｔ１からTS1の残りのパケットの最後のバイトがに入力終了する時刻Ｔ２まで
TS1の残りのパケットは、TS_recording_rate（TS1）のビットレート（TS1の最大ビットレート）でDVR-STDのTBn又はTBsysのバッファへ入力されなければならない。ここで、TS_recording_rate（TS1）は、Clip１に対応するClipInfo()において定義されるTS_recording_rateの値である。TS1の最後のバイトがバッファへ入力する時刻は、時刻Ｔ２である。従って、時刻Ｔ１からＴ２までの区間では、ソースパケットのarrival_time_stampは無視される。
【００１３】
Ｎ１をTS1の最後のビデオパケットに続くTS1のトランスポートパケットのバイト数とすると、時刻Ｔ１からＴ２までの時間Ｔ２−１＝Ｔ２−Ｔ１は、Ｎ1バイトがTS_recording_rate（TS1）のビットレートで入力終了するために必要な時間であり、下記式（１）のように計算される。
【００１４】
【数１】
0004902935.tif 000002
【００１５】
時刻Ｔ１からＴ２までの間は、図１２に示すRxnとRxsysの値は共にTS_recording_rate（TS1）の値に変化する。このルール以外のバッファリング動作は、T-STDと同じである。
【００１６】
オーディオデコーダは、時刻Ｔ１からＴ２までの区間の入力データを処理することができるように、即ち、時刻Ｔ１からＴ２までの間は、図１２に示すRxnとRxsysの値が共にTS_recording_rate（TS1）の値に変化するため、T-STDで定義されるバッファ量に加えて付加的なバッファ量（約1秒分のデータ量）が必要である。
【００１７】
（３）時刻Ｔ２以後
Ｔ２の時刻において、アライバルタイムクロックカウンタ１１５は、TS2の最初のソースパケットのarrival_time_stampの値にリセットされる。DVR-STDのTB1、TBn又はTBsysのバッファへの入力タイミングは、TS2のソースパケットのarrival_time_stampによって決定される。RxnとRxsysは共に、T-STDにおいて定義されている値に変化する。
【００１８】
次に、ビデオのプレゼンテーションタイミングについて説明する。ビデオプレゼンテーションユニットの表示は、接続点（コネクションポイント）を通してギャップなしに連続でなければならない。
ここで、
STC（System Time Clock）１：TS1のシステムタイムベースの時間軸
STC2：TS2のシステムタイムベースの時間軸（正確には、STC2は、TS2の最初のPCR（Program Clock Refarence）がT-STDに入力した時刻から開始する。）
とする。
【００１９】
STC1とSTC2との間のオフセット値は、次のように決定される。
PTS1ｅｎｄ：TS1の最後のビデオプレゼンテーションユニットに対応するSTC1上のPTS
PTS2ｓｔａｒｔ：TS2の最初のビデオプレゼンテーションユニットに対応するSTC2上のPTS
Ｔｐｐ：最後のビデオプレゼンテーションユニットの表示期間
とすると、
２つのシステムタイムベースの間のオフセット値STC_deltaは、下記式（２）のように計算される。
【００２０】
【数２】
0004902935.tif 000003
【００２１】
次に、オーディオのプレゼンテーションタイミングについて説明する。TS1とTS2との接続点において、オーディオプレゼンテーションユニットの表示タイミングのオーバーラップがあってもよく、それは０から２オーディオフレーム未満である。プレーヤ１０１には、どちらのオーディオサンプルを選択するかということと、オーディオプレゼンテーションユニットの表示を接続点の後の補正されたタイムベースに再同期する制御が要求される。
【００２２】
TS1からそれにシームレスに接続された次のTS2へと移る時、DVR-STDのシステムタイムクロックの制御について、プレーヤ１０１が行う処理を説明する。TS1の最後のオーディオプレゼンテーションユニットが表示される時刻Ｔ５において、システムタイムクロックは、時刻Ｔ２からＴ５の間にオーバーラップしていてもよい。この区間では、DVR-STDは、システムタイムクロックを古いタイムベースの値（STC1）から新しいタイムベースの値（STC2）の値に切り替える。STC2の値は、下記式（３）のように計算できる。
【００２３】
【数３】
0004902935.tif 000004
【００２４】
TS1から、これにシームレスに接続された次のTS2へと移る時、TS1及びTS2が満たさなければいけない符号化条件を説明する。
【００２５】
STC1１ｖｉｄｅｏ_ｅｎｄ：TS1の最後のビデオパケットの最後のバイトがDVR-STDのTB1へ到着する時のシステムタイムベースSTC1上のSTCの値
STC2２ｖｉｄｅｏ_ｓｔａｒｔ：TS2の最初のビデオパケットの最初のバイトがDVR-STDのTB1へ到着する時のシステムタイムベースSTC2上のSTCの値
STC2１ｖｉｄｅｏ_ｅｎｄ：STC1１ｖｉｄｅｏ_ｅｎｄの値をシステムタイムベースSTC2上の値に換算した値
とした場合、STC2１ｖｉｄｅｏ_ｅｎｄは、下記式（４）のようにして計算される。
【００２６】
【数４】
0004902935.tif 000005
【００２７】
ここで、デコーダ１２０がDVR-STDに従うために、次の２つの条件を満たすことが要求される。
【００２８】
（条件１）
TS2の最初のビデオパケットのTB1への到着タイミングは、次に示す不等式（５）を満たさなければならない。
【００２９】
【数５】
0004902935.tif 000006
【００３０】
この上記不等式（５）を満たすように、Clip１及び／又はClip２の部分的なストリームを再エンコード及び／又は再多重化することが必要になる。
【００３１】
（条件２）
STC1とSTC2とを同じ時間軸上に換算したシステムタイムベースの時間軸上において、TS1からのビデオパケットの入力とそれに続くTS2からのビデオパケットの入力は、ビデオバッファをオーバーフロウ及びアンダーフローさせてはならない。
【００３２】
【特許文献１】
特開２０００−１７５１５２号公報
【特許文献２】
特開２００１−５４４１１８号公報
【特許文献３】
特開２００２−１５８９７４号公報
【００３３】
【発明が解決しようとする課題】
しかしながら、上述したように、DVR-STDモデルを使用した従来のプレーヤ１０１においては、時刻Ｔ１からＴ２までの区間の入力データを処理することができるように、即ち、時刻Ｔ１からＴ２までの間は、TS1の残りのパケットは、TS_recording_rate（TS1）のビットレート（TS1の最大ビットレート）でDVR-STDのTBn又はTBsysのバッファへ入力されていたため、T-STDで定義されるバッファに加えて、約1秒分のデータをバッファリング可能な容量の付加的なバッファが必要である。
【００３４】
このバッファ容量の大きさは、次の要因に基づく。すなわち、MPEG2TSの中において、あるバイト位置にあるビデオデータに同期再生されるオーディオデータが、所定範囲内の多重化位相差を離れて存在することができ、この多重化位相差の最大値が１秒分のデータ量に相当する。従って、上記式（１）のＮ１の最大値は、最大１秒分のオーディオデータに相当する。時刻Ｔ１からＴ２までの間は、ソースパケットのarrival_time_stampを無視して、TSの最大ビットレートでＮ１のデータ量のソースパケットが、オーディオバッファに入力されるので、このデータ量をバッファリングするために、T-STDで定義されるバッファ量に加えて付加的なバッファ量（約1秒分のデータ量）が必要になっていた。
【００３５】
この付加的なバッファの大きさを具体的に計算すると次のようになる。即ち、例えば６４０kbpsのドルビーＡＣ３方式により符号化されたオーディオストリームの場合、１秒分のオーディオデータは、６４０kbits＝８０kBytesとなり、８０kBytesの付加的なバッファが必要となる。
【００３６】
また、Linear PCM方式により符号化されたオーディオストリームであって、２４bitSample、９６kHz sampling frequency、８channelsの場合、１秒分のオーディオデータは、２４bitSample×９６０００samples／sec×８channels＝約１８Mbitsとなり、約３Mbytesの付加的なバッファが必要となり、このようなマルチチャンネルのオーディオデータを扱う場合、この付加的なバッファが極めて大きくなってしまうという問題点がある。
【００３７】
本発明は、このような従来の実情に鑑みて提案されたものであり、オーディオストリームとビデオストリームとが多重化された２つの多重化ストリームをシームレスに連続して復号するために、最適な容量のオーディオバッファとした情報処理装置、その方法、プログラム及び記録媒体を提供することを目的とする。
【００３８】
【課題を解決するための手段】
上述した目的を達成するために、本発明に係る情報処理装置は、少なくともビデオストリームとオーディオストリームが多重化された第１の多重化ストリームの最後のピクチャである第１のピクチャに第２の多重化ストリームの最初のピクチャである第２のピクチャが連続して再生されるよう接続された多重化ストリームを復号する情報処理装置において、上記多重化ストリームのアライバルタイムスタンプに従ってソースパケットを出力する出力手段と、上記ソースパケットのうちビデオデータをバッファリングするビデオバッファと、上記ソースパケットのうちオーディオデータをバッファリングするオーディオバッファと、上記ビデオバッファにバッファリングされたビデオデータを復号するビデオ復号手段と、上記オーディオバッファにバッファリングされたオーディオデータを復号するオーディオ復号手段とを有し、上記第１の多重化ストリームの最後のビデオパケットが、エレメンタリストリームのトランスポートバッファに入力終了する時刻Ｔ１から、上記第１の多重化ストリームの最後のバイトが入力終了するまでの時刻Ｔ２までの間において、ソースパケットの入力を、上記第１の多重化ストリームのソースパケットのアライバルタイムスタンプによって決定するとともに、上記オーディオバッファは、上記第２のピクチャの最大のビット量をそのデコードタイミングまでに上記ビデオバッファに入力するために要する時間分のオーディオデータをバッファリング可能な容量を有し、上記オーディオバッファに必要な容量をEBn_max（bits）とし、上記第２のピクチャのビット量をI_max（bits）とし、上記ビデオバッファへの入力ビットレートをRv(bps)とし、オーディオデータのビットレートをRa（bps）としたとき、
EBn_max＝（I_max／Rv）×Ra
を満たす。
【００３９】
本発明においては、オーディオバッファのサイズを、上記第２のピクチャを上記ビデオバッファに入力するために要する時間分のオーディオデータをバッファリング可能な容量とすると共に、上記第１のピクチャが上記ビデオバッファに入力終了する時刻から第１の多重化ストリームの最後のパケットを入力終了する時刻までの間においても、多重化ストリームのソースパケットのアライバルタイムスタンプ（arrival_time_stamp）に従ってソースパケットをバッファに入力するようにしたので、従来ソースパケットのarrival_time_stampを無視して、トランスポートストリーム（TS）の最大ビットレートで入力するために必要とされていた１秒分の付加的なバッファを不要とすると共に、第１の多重化ストリームの最後のトランスポートパケットを入力した後に、第２の多重化ストリームの最初にデコードされるピクチャをそのデコードタイミングまでにビデオバッファへ入力することができる。
【００４０】
また、上記オーディオバッファの必要な容量をEBn_max（bits）とし、上記第２のピクチャのビット量をI_max（bits）とし、上記ビデオバッファへの入力ビットレートをRv(bps)とし、オーディオデータのビットレートをRa（bps）としたとき、EBn_max＝（I_max／Rv）×Raを満たすものとすることができ、第２のピクチャとなる例えばＩピクチャのビット量の最大値をI_maxとした場合、オーディオバッファの容量は、最大でEBn_max＝（I_max／Rv）×Raとすることができる。
【００４１】
更に、上記オーディオバッファは、１００ミリ秒分のオーディオデータをバッファリング可能な容量を有することが好ましく、これにより、例えばMPEG2のＩピクチャのデータ量は、通常１秒間で伝送されるデータ量の１０％以下の大きさであるため、オーディオバッファをこれと同じ大きさの容量としておき、その大きさ分のオーディオデータを先送りしておくことで、Ｉピクチャをそのデコードタイミングまでにビデオバッファへ入力することができ、ビデオデータのエンコード制限が少なくなる。即ち、オーディオバッファを上記容量とすることで、オーディオデータをそれが再生されるタイミングよりも１００ミリ秒だけ早く入力終了するように多重化ストリームを多重化することができる。
【００４２】
更にまた、上記第１の多重化ストリームの時間軸における上記第１のピクチャの表示終了時刻と上記第２の多重化ストリームの時間軸における上記第２のピクチャの表示開始時刻との時間差をSTC_deltaとし、上記第１の多重化ストリームの最後のソースパケットの最後のバイトが上記出力手段から出力される該第１の多重化ストリームの時間軸上の値STC1１ｅｎｄを上記時間差STC_deltaにより上記第２の多重化ストリームの時間軸上の値に換算した値をSTC2１ｅｎｄ（＝STC1１ｅｎｄ−STC_delta）とし、上記第２の多重化ストリームの最初のパケットの最初のバイトが上記出力手段から出力される該第２の多重化ストリームの時間軸上の値をSTC2２ｓｔａｒｔとしたとき、上記多重化ストリームは、STC2２ｓｔａｒｔ＞STC2１ｅｎｄを満たすものとすることにより、DVR-STDに従ったものとすることができる。
【００４３】
更にまた、上記第１の多重化ストリームの最後のパケットが上記出力手段から出力された後、所定時間delta1の経過後、上記第２の多重化ストリームの最初のパケットを上記出力手段から出力するものとし、STC2２ｓｔａｒｔ＞STC2１ｅｎｄ＋delta1を満たすものとしてもよく、これにより、第２の多重化ストリームの最初のパケットの入力タイミングに柔軟性を持たせ、第２の多重化ストリームの符号化を容易にすることができる。
【００４４】
本発明に係る情報処理方法は、少なくともビデオストリームとオーディオストリームが多重化された第１の多重化ストリームの最後のピクチャである第１のピクチャに第２の多重化ストリームの最初のピクチャである第２のピクチャが連続して再生されるよう接続された多重化ストリームを復号する情報処理方法において、上記多重化ストリームのアライバルタイムスタンプに従ってソースパケットを出力する出力工程と、上記ソースパケットのうちビデオデータをビデオバッファにバッファリングし、オーディオデータをオーディオバッファにバッファリングするバッファリング工程と、上記ビデオバッファ及びオーディオバッファにバッファリングされた夫々ビデオデータ及びオーディオデータを復号する復号工程とを有し、上記第１の多重化ストリームの最後のビデオパケットが、エレメンタリストリームのトランスポートバッファに入力終了する時刻Ｔ１から、上記第１の多重化ストリームの最後のバイトが入力終了するまでの時刻Ｔ２までの間において、ソースパケットの入力を、上記第１の多重化ストリームのソースパケットのアライバルタイムスタンプによって決定するとともに、上記バッファリング工程では、上記第２のピクチャの最大のビット量をそのデコードタイミングまでに上記ビデオバッファに入力するために要する時間分のオーディオデータを、上記第２のピクチャを上記ビデオバッファにバッファリングする前に上記オーディオバッファにバッファリングし、上記オーディオバッファに必要な容量をEBn_max（bits）とし、上記第２のピクチャのビット量をI_max（bits）とし、上記ビデオバッファへの入力ビットレートをRv(bps)とし、オーディオデータのビットレートをRa（bps）としたとき、
EBn_max＝（I_max／Rv）×Ra
を満たす。
【００４５】
また、本発明に係るプログラムは、上述した情報処理をコンピュータに実行させるものであり、本発明に係る記録媒体は、そのようなプログラムが記録されたコンピュータ読み取り可能なものである。
【００４６】
本発明に係る他の記録媒体は、トランスポートパケットとそのアライバルタイムスタンプとを有するソースパケットを単位とするデータ列からなる多重化ストリームが記録された記録媒体であって、上記多重化ストリームは、第１の多重化ストリームの最後のピクチャである第１のピクチャに第２の多重化ストリームの最初のピクチャである第２のピクチャが連続して再生されるよう接続され、上記第１及び第２の多重化ストリームが夫々のアライバルタイムスタンプに基づいてデコーダに入力可能であって、且つ、上記第２のピクチャをデコーダに入力するために要する時間分のオーディオデータを該第２のピクチャが該デコーダに入力開始される前までに入力終了可能なように多重化された多重化ストリームが記録されたことを特徴とする。
【００４７】
本発明においては、第２のピクチャを上記デコーダに入力するために要する時間分のオーディオデータを該第２のピクチャが該デコーダに入力開始される前までに入力終了可能なように多重化ストリームが多重化されているため、このような多重化ストリームを、第２のピクチャをビデオバッファに入力するために要する時間分のオーディオデータをバッファリング可能な容量のオーディオバッファを有するデコーダにより復号すれば、第１の多重化ストリームの最後のトランスポートパケットを入力した後に、第２の多重化ストリームの最初にデコードされるピクチャをそのデコードタイミングまでにビデオバッファへ入力することができる。
【００４８】
本発明に係る他の情報処理装置は、トランスポートパケットとそのアライバルタイムスタンプとを有するソースパケットを単位とするデータ列からなり、該アライバルタイムスタンプに基づきデコーダにより読み出されてデコードされる多重化ストリームを生成する情報処理装置において、第１のピクチャで表示終了する第１のビデオ符号化ストリームを生成し、この第１のピクチャに続けて表示される第２のピクチャから表示開始する第２のビデオ符号化ストリームを生成するビデオ符号化手段と、上記第１のビデオ符号化ストリームとこの上記第１のビデオ符号化ストリームに同期したオーディオ符号化ストリームとを多重化して第１の多重化ストリームを生成し、上記第２のビデオ符号化ストリームとこの第２のビデオ符号化ストリームに同期したオーディオ符号化ストリームとを多重化して第２の多重化ストリームを生成し、上記第１の多重化ストリームの最後のピクチャである上記第１のピクチャに上記第２の多重化ストリームの最初のピクチャである上記第２のピクチャが連続して再生されるよう接続された多重化ストリームを生成する多重化手段とを有し、上記多重化手段は、上記第２のピクチャを上記デコーダに入力するために要する時間分のオーディオデータを上記第２のピクチャが該デコーダに入力開始される前までに入力終了可能なように多重化することを特徴とする。
【００４９】
本発明においては、上記第２のピクチャを上記デコーダに入力するために要する時間分の、例えば１００ミリ秒分のオーディオデータを上記第２のピクチャが該デコーダに入力開始される前までに入力終了可能なように多重化するため、デコーダにおいて、オーディオデータをオーディオバッファに先送りして、Ｉピクチャ等の第２のピクチャを、そのデコードタイミングまでに伝送する時間を十分に確保することができ、多重化ストリームの符号化が容易になる。
【００５０】
本発明に係る他の情報処理方法は、トランスポートパケットとそのアライバルタイムスタンプとを有するソースパケットを単位とするデータ列からなり、該アライバルタイムスタンプに基づきデコーダにより読み出されてデコードされる多重化ストリームを生成する情報処理方法において、第１のピクチャで表示終了する第１のビデオ符号化ストリームを生成し、この第１のピクチャに続けて表示される第２のピクチャから表示開始する第２のビデオ符号化ストリームを生成するビデオ符号化工程と、上記第１のビデオ符号化ストリームとこの上記第１のビデオ符号化ストリームに同期したオーディオ符号化ストリームとを多重化して第１の多重化ストリームを生成し、上記第２のビデオ符号化ストリームとこの第２のビデオ符号化ストリームに同期したオーディオ符号化ストリームとを多重化して第２の多重化ストリームを生成し、上記第１の多重化ストリームの最後のピクチャである上記第１のピクチャに上記第２の多重化ストリームの最初のピクチャである上記第２のピクチャが連続して再生されるよう接続された多重化ストリームを生成する多重化工程とを有し、上記多重化工程では、上記第２のピクチャを上記デコーダに入力するために要する時間分のオーディオデータを上記第２のピクチャが該デコーダに入力開始される前までに入力終了可能なように多重化することを特徴とする。
【００５１】
【発明の実施の形態】
以下、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。この実施の形態は、本発明を、ビデオストリームとオーディオストリームとが多重化された２つのAVストリームをシームレスで連続再生する情報処理装置に適用したものである。そして、本実施の形態においては、DVR-STD（Digital Video Recording-System Target Decoder）において、シームレスに接続された２つのAVストリームを再生する際に最適な容量としたオーディオバッファを提案するものである。
【００５２】
はじめに、以下の説明において使用する用語について説明する。Clipは、ビデオストリームとオーディオストリームとの多重化ストリームを示す。また、PlayListは、Clipの中の再生区間の集まりを示す。あるClipの中の一つの再生区間は、PlayItemと呼ばれ、それは、時間軸上のＩＮ点とＯＵＴ点のペアで表される。
それゆえ、PlayListは、PlayItemの集まりである。
【００５３】
PlayItem間をシームレスに再生するとは、再生装置（プレーヤ）が、デコーダの再生出力にポーズやギャップを起こさせることなく、ディスクに記録されたオーディオビデオデータを表示（再生）することができることである。
【００５４】
シームレス接続されている２つのPlayItemsの構造について説明する。先行するPlayItemと現在のPlayItemとの接続が、シームレス表示できるように保証されているかどうかは、現在のPlayItemにおいて定義されているconnection_conditionフィールドから判断することができる。そして、PlayItem間のシームレス接続は、Bridge-Clip（BridgeSequence）を使用する方法（以下、第１の方法とする。）と使用しない方法（以下、第２の方法とする。）がある。
【００５５】
先ず、先行するPlayItem（previous PlayItem）と現在のPlayItem（current Play Item）とが、第１の方法であるBridgeSequenceを使用して接続されている場合のTS1及びTS2について説明する。図１は、第１の方法であるBridge-Clipを使用する場合の先行するPlayItemと現在のPlayItemとの関係を示す模式図である。この図１において、Bridge-Clipを使用する場合にプレーヤが読み出すストリームデータを影を付けて示す。ここで、DVR MPEG（Moving Picture Experts Group）2トランスポートストリーム（TS）は、整数個のAligned unitから構成される。Aligned unitの大きさは、６１４４バイト(2048×3バイト)である。１つのAligned unitは、３２個のソースパケットからなり、ソースパケットの第１バイト目から始まる。
【００５６】
各ソースパケットは、１９２バイト長である。１つのソースパケットは、TP_extra_headerとトランスポートパケットとから成り、TP_extra_headerは、４バイト長であり、またトランスポートパケットは、１８８バイト長である。TP_extra_headerは、copy_premission_indicatorとarrival_time_stampとを有し、copy_premission_indicatorは、トランスポートパケットのペイロード（Payload）のコピー制限を表す整数、arrival_time_stamp（ATS）は、AVストリームの中で、対応するトランスポートパケットがデコーダに到着する時刻を示すタイムスタンプである。AVストリームを構成する各ソースパケットのarrival_time_stampに基づいて作られる時間軸をアライバルタイムベースといい、そのクロックをＡＴＣ（Arrival Time Clock）と呼ぶ。
【００５７】
図１に示すTS1（第１の多重化ストリーム）は、Clip1（Clip AVストリーム）の影を付けて示すストリームデータＤ１とBridge-ClipのSPN_arrival_time_discontinuityより前の影を付けて示すストリームデータＤ２からなる。SPN_arrival_time_discontinuityは、the Bridge-Clip AVストリームファイルの中でアライバルタイムベースの不連続点があるところのソースパケットのアドレスを示す。
【００５８】
そして、TS1に含まれるClip1の影を付けて示すストリームデータＤ１は、先行するPlayItemのIN_time（図１においてIN_time１で示す。）に対応するプレゼンテーションユニットを復号するために必要なストリームのアドレスから、SPN_exit_from_previous_Clipで参照されるソースパケットまでのストリームデータである。
【００５９】
また、TS1に含まれるBridge-ClipのSPN_arrival_time_discontinuityより前の影を付けて示すストリームデータＤ２は、Bridge-Clipの最初のソースパケットから、SPN_arrival_time_discontinuityで参照されるソースパケットの直前のソースパケットまでのストリームデータである。
【００６０】
また、図１に示すTS2（第２の多重化ストリーム）は、Clip２（Clip AVストリーム）の影を付けて示すストリームデータＤ４とBridge-ClipのSPN_arrival_time_discontinuity以後の影を付けて示すストリームデータＤ３からなる。
【００６１】
そして、TS2に含まれるBridge-ClipのSPN_arrival_time_discontinuity以後の影を付けて示すストリームデータＤ３は、SPN_arrival_time_discontinuityで参照されるソースパケットから、Bridge-Clipの最後のソースパケットまでのストリームデータである。
【００６２】
また、TS2に含まれるClip２の影を付けて示すストリームデータＤ４は、SPN_enter_to_current_Clipで参照されるソースパケットから、現在のPlayItemのOUT_time（図１において、OUT_time２で示す。）に対応するプレゼンテーションユニットを復号するために必要なストリームのアドレスまでのストリームデータである。
【００６３】
次に、先行するPlayItemと現在のPlayItemが、第２の方法であるBridgeSequenceを使用しないで接続されている場合のTS1及びTS2について説明する。図２は、第２の方法であるBridge-Clipを使用しない場合の先行するPlayItemと現在のPlayItemの関係を示す模式図である。この図２において、プレーヤが読み出すストリームデータは、影を付けて示す。
【００６４】
図２に示すTS1（第１の多重化ストリーム）は、Clip１(Clip AVストリーム)の影を付けて示すストリームデータＤ５からなる。TS1に含まれるClip１の影を付けて示すストリームデータＤ５は、先行するPlayItemのIN_time（図２においてIN_time１で示す）に対応するプレゼンテーションユニットを復号するために必要なストリームのアドレスから始まり、Clip１の最後のソースパケットまでのデータである。
【００６５】
また、図２に示すTS2（第２の多重化ストリーム）は、Clip２（Clip AVストリーム）の影を付けて示すストリームデータＤ６からなる。TS2に含まれるClip２の影を付けて示すストリームデータＤ６は、Clip２の最初のソースパケットから始まり、現在のPlayItemのOUT_time（図２においてOUT_time２で示す）に対応するプレゼンテーションユニットを復号するために必要なストリームのアドレスまでのストリームデータである。
【００６６】
図１及び図２の両方において、TS1及びTS2は、ソースパケットの連続したストリームである。次に、TS1及びTS2のストリーム規定とそれらの間の接続条件について説明する。
【００６７】
TS1及びTS2は、ビデオストリームとオーディオストリームとが多重化されたものであるが、ここでは、先ず、シームレス接続のための符号化制限におけるビデオビットストリームの制限について説明する。
【００６８】
図３は、ビデオストリームとしてのClip1とClip2とをシームレス接続する例をピクチャの表示順序（Presentation order）で示す模式図である。動画像プログラムの一部分をスキップ再生する際に、スキップ再生開始点であるアウト点ピクチャより時間的に前側のプログラムであるアウト点側プログラムと、スキップ再生到達点であるイン点ピクチャより時間に後側のプログラムであるイン点側プログラムとをシームレスに接続するには、復号装置においてビデオストリームの再エンコード処理を行う必要がある。
【００６９】
MPEG2規格に準じた画像群の単位であるＧＯＰ（group of pictures）には、他の画像からの予測符号化なしに画像が符号化された参照画像である少なくとも１つのＩ（Intra）ピクチャ（フレーム内符号化画像）と、表示順序に順方向の予測符号化を用いて画像が符号化された順方向予測符号化画像であるＰ（predictive）ピクチャと、順方向及び逆方向の予測符号化を用いて画像が符号化された双方向予測符号化画像であるＢ（bidirectionally）ピクチャとの３種類の符号化画像が含まれている。図３においては、Clip1及びClip2の各数字は表示順序を示し、Ｉ、Ｐ、Ｂ、又はｉ、ｐ、ｂは各ピクチャの種類を示す。例えば図３には、Clip1のＢ７とClip２のｂ４とを接続する例を示すが、この接続点においてビデオストリームをシームレスに表示できるためには、OUT_time1（Clip１のOUT_time）の後とIN_time2（Clip2のIN_time）の前に表示される不必要なピクチャは、接続点付近のClipの部分的なストリームを再エンコードするプロセスにより、除去されなければならない。
【００７０】
図３に示すようなビデオストリーム（Clip1及びClip2）をシームレス接続する場合に、上記第１の方法であるBridgeSequenceを使用してシームレス接続を実現する例を図４に示す。SPN_arrival_time_discontinuityより前のBridge-Clipのビデオストリームは、図３に示すClip1のOUT_time1に対応するピクチャまでの符号化ビデオストリームからなる。そして、そのビデオストリームは先行するClip１のビデオストリームに接続され、一つの連続でMPEG2規格に従ったエレメンタリーストリームとなるように再エンコードされている。同様にして、SPN_arrival_time_discontinuity以後のBridge-Clipのビデオストリームは、図３のClip２のIN_time２に対応するピクチャ以後の符号化ビデオストリームからなる。そして、そのビデオストリームは、正しくデコード開始することができて、これに続くClip2のビデオストリームに接続され、一つの連続でMPEG2規格に従ったエレメンタリーストリームとなるように再エンコードされている。Bridge-Clipを作るためには、一般に、数枚のピクチャは再エンコードしなければならず、それ以外のピクチャはオリジナルのClipからコピーすることができる。
【００７１】
図４（ａ）は、図３に示すClip1をその復号順に示したものであり、プレーヤは、先行するClip1のＰ５のソースパケット番号（SPN_exit_from_previous_Clip）から図４（ｂ）に示すBridge-Clipにジャンプする。ここで、Bridge-Clipの図１に示したＤ２、即ち、BridgeSequenceにおけるSPN_arrival_time_discontinuityの前までのビデオデータに相当するClip1のOUT_time1側のストリームデータにおいて、Ｂ４までのデータｄ１は、Clip1をそのままコピーしたデータからなり、これに続くデータＰ７，Ｂ６は本来はオリジナルのClip1のＢ６及びＢ７からなるが、Clip1を復号し圧縮していない画像データに戻してから再びエンコードしてＰ７及びＢ６としたデータｄ２となっている。また、Bridge-Clipの図１に示したＤ３、即ち、BridgeSequence におけるSPN_arrival_time_discontinuity以降のビデオデータに相当するClip2のIN_time2側のストリームデータにおいても、オリジナルのClip2のｂ４、ｐ５、ｐ８、ｂ６、ｂ７は、Clip2を一旦復号して圧縮していない画像データに戻してから再びエンコードして新たに作成されたデータ（ｉ０、ｐ１、ｐ４、ｂ２、ｂ３）ｄ３となり、それ以降Clip2のSPN_enter_to_currenr_Clipにジャンプするまでの間のデータｄ４は、Clip2をそのままコピーしたものとなっている。
【００７２】
次に、図３に示すようなビデオストリーム（Clip1及びClip2）をシームレス接続する場合に、上記第２の方法であるBridgeSequenceを使用しないでシームレス接続を実現する例を図５に示す。図５において、Clip1及びClip２は、その復号順序にピクチャを示す。BridgeSequenceを使用しない場合であっても、図４に示したBridgeSequenceを使用する場合と同様に、接続点（コネクションポイント：conection point）付近のストリームは、一旦復号して圧縮していないデータに戻してから最適なピクチャタイプに再デコードされる。即ち、Clip１のビデオストリームは、図３のOUT_time1に対応するピクチャまでの符号化ビデオストリームからなり、それは、１つの連続でMPEG2規格に従ったエレメンタリーストリームとなるように、Ｂ６，Ｂ７が再エンコードされたデータ（Ｐ７，Ｂ６）ｄ５とされている。同様にして、Clip２のビデオストリームは、図３のClip2のIN_time2に対応するピクチャ以後の符号化ビデオストリームからなり、それは、１つの連続でMPEG2規格に従ったエレメンタリーストリームとなるように、ｂ４，ｐ５，ｐ８，ｂ６，ｂ７が再エンコードされたデータ（ｉ０，ｐ１，ｐ４，ｂ２，ｂ３）ｄ６とされている。
【００７３】
次に、TS1及びTS2のそれぞれの多重化ストリームの符号化制限について説明する。図６は、オーディオの表示のオーバーラップを説明する図であって、TS1及びTS2におけるビデオのプレゼンテーションユニット及びオーディオのプレゼンテーションユニットを示す模式図である。
【００７４】
図６に示すように、TS1のオーディオストリームの最後のオーディオフレームA_endは、TS1の最後の表示ピクチャの表示終了時（OUT_time1）に等しい表示時刻を持つオーディオサンプルを含んでいる。また、TS2のオーディオストリームの最初のオーディオフレームA_startは、TS2の最初の表示ピクチャの表示開始時（IN_time2）に等しい表示時刻を持つオーディオサンプルを含んでいる。これにより、TS1とTS2との接続点において、オーディオプレゼンテーションユニットのシーケンスにギャップは存在せず、２オーディオフレーム区間未満のオーディオプレゼンテーションユニットの長さで定義されるオーディオオーバーラップ（Audio overlap）が生じる。接続点におけるTSは、後述するDVR-STD（Digital Video Recording-System Target Decoder）に従ったDVR MPEG2TSである。
【００７５】
DVR-STDは、シームレス接続された２つのPlayItemによって参照されるAVストリームの生成および検証の際におけるデコード処理をモデル化するための概念モデルである。DVR-STDモデル（DVR MPEG2 transport stream player model）を図７に示す。
【００７６】
図７に示すように、本実施の形態における情報処理装置（DVR MPEG2 transport stream player model、以下プレーヤという。）１は、シームレスに再生されるよう接続されたTSからトランスポートパケット（Transport packets）を読出し出力する出力部１０と、出力部１０からのトランスポートパケットをデコードするデコーダ（DVR-STD）２０とから構成される。このデコーダ２０は、後述するように、上述した従来のDVR-STDにおけるトランスポートパケットの入力タイミングとオーディオバッファの容量とを変更したものである。出力部１０において、読出部（DVRdrive）１１から読出しレートRＵＤで読み出されたTSファイルは、リードバッファ１２にバッファリングされ、このリードバッファ１２からソースパケット（Source packets）がソースデパケッタイザ部（source depacketizer）１３へビットレートRＭＡＸで読み出される。RＭＡＸは、ソースパケットストリームのビットレートである。
【００７７】
パルス発振器（27MHz X-tal）１４は、２７ＭＨｚのパルスを発生する。アライバルクロックカウンタ（Arrival time clock counter）１５は、この２７MHzの周波数のパルスをカウントするバイナリカウンタであり、ソースデパケッタイザ部１３に、時刻t(i)におけるArrival time clock counterのカウント値Arrival_time_clock(i)を供給する。
【００７８】
上述したように、１つのソースパケットは、１つのトランスポートパケットとそれのarrival_time_stampを持つ。現在のソースパケットのarrival_time_stampがarrival_time_clock(i)のＬＳＢ３０ビットの値と等しい時、ソースデパケッタイザ部１３からそのトランスポートパケットが出力される。TS_recording_rateは、TSのビットレートである。
【００７９】
また、図７に示すn、TBn、MBn、EBn、TBsys、Bsys、Rxn、Rbxn、Rxsys、Dn、Dsys、On及びPn(k)の表記方法は、ISO/IEC13818-1 (MPEG2 Systems規格)のT-STD（ISO/IEC 13818-1で規定されるtransport stream system target decoder）に定義されているものと同じである。すなわち、次の通りである。
【００８０】
n：エレメンタリーストリームのインデクス番号
TBn：エレメンタリーストリームnのトランスポートバッファ
MBn：エレメンタリーストリームnの多重バッファ（ビデオストリームについてのみ存在）
EBn：エレメンタリーストリームnのエレメンタリーストリームバッファ、ビデオストリームについてのみ存在
TBsys：復号中のプログラムのシステム情報のための入力バッファ
Bsys：復号中のプログラムのシステム情報のためのシステムターゲットデコーダ内のメインバッファ
Rxn：データがTBnから取り除かれる伝送レート
Rbxn：PESパケットペイロードがMBnから取り除かれる伝送レート（ビデオストリームについてのみ存在）
Rxsys：データがTBsysから取り除かれる伝送レート
Dn：エレメンタリーストリームnのデコーダ
Dsys：復号中のプログラムのシステム情報に関するデコーダ
On：ビデオストリームnの再配列バッファ（re-ordering buffer）
Pn(k)：エレメンタリーストリームnのk番目のプレゼンテーションユニット
【００８１】
次に、デコーダ２０のデコーディングプロセスについて説明する。先ず、１つのDVR MPEG2 TSを再生している時のデコーディングプロセスを説明する。
【００８２】
単一のDVR MPEG2TSを再生している間は、トランスポートパケットをTB1、TBn又はTBsysのバッファへ入力するタイミングは、ソースパケットのarrival_time_stampにより決定される。
【００８３】
TB1、MB1、EB1、TBn、Bn、TBsys及びTBsysのバッファリング動作の規定は、ISO/IEC 13818-1に規定されているT-STDと同じである。復号動作と表示動作の規定もまた、ISO/IEC 13818-1に規定されているT-STDと同じである。
【００８４】
次に、シームレス接続されたPlayItemを再生している間のデコーディングプロセスについて説明する。図８は、あるAVストリーム（TS1）から、これにシームレスに接続された次のAVストリーム（TS2）へと移る時のトランスポートパケットの入力、復号、及び表示のタイミングチャートである。
【００８５】
ここでは、シームレス接続されたPlayItemによって参照される２つのAVストリームの再生について説明をすることにし、以後の説明では、図１又は図２に示した、シームレス接続されたTS1及びTS2の再生について説明する。従って、TS1は、先行するストリームであり、TS2は、現在のストリームである。
【００８６】
あるAVストリーム（TS1）からそれにシームレスに接続された次のAVストリーム（TS2）へと移る間には、TS2のアライバルタイムベースの時間軸（図８においてATC2で示される）は、TS1のアライバルタイムベースの時間軸（図８におけるATC1で示される）と同じ時間軸でない。また、TS2のシステムタイムベースの時間軸（図８においてSTC2で示される）は、TS1のシステムタイムベースの時間軸（図８においてSTC1で示される）と同じ時間軸でない。ビデオの表示は、シームレスに連続していることが要求される。オーディオのプレゼンテーションユニットの表示時間にはオーバーラップがあってもよい。
【００８７】
ここで、本実施の形態におけるプレーヤ１においては、上記特許文献１乃至３に記載のプレーヤ１０１に対し、以下の２点を変更することで、オーディオバッファを最適な容量とするものである。先ず、１つ目の変更点について説明する。１つ目の変更点は、あるAVストリーム(TS1)からそれにシームレスに接続された次のAVストリーム(TS2)へと移る時、TS1の最後のパケットまでのデコーダ２０への入力をそれらソースパケットのarrival_time_stampによって決定することとする点である。
【００８８】
即ち、上述した如く、従来は、TS1の最後のビデオパケットがTB1に入力終了する時刻Ｔ１から、TS1の最後のバイトが入力終了するまでの時刻Ｔ２までの間は、arrival_time_stampを無視して、TSの最大ビットレートで、トランスポートパケットがバッファに入力されていたのに対し、本実施の形態においては、Ｔ１からＴ２までの間のソースパケットの入力を、時刻Ｔ１までと同様にして、TS1のソースパケットのarrival_time_stampによって決定する。これにより、従来ソースパケットのarrival_time_stampを無視して、TSの最大ビットレートRＭＡＸで入力するために必要とされていた１秒分の付加的なバッファは、不要となる。
【００８９】
この場合のデコーダ２０への入力タイミングについて、図８を参照して説明する。
【００９０】
（１）時刻Ｔ１までの時間
時刻Ｔ１までの時間、即ち、TS1の最後のビデオパケットがデコーダ２０のTB1に入力終了するまでは、デコーダ２０のTB1、TBn又はTBsysのバッファへの入力タイミングは、TS1のソースパケットのarrival_time_stampによって決定される。
【００９１】
（２）時刻Ｔ１からＴ２まで
TS1の残りのパケットがデコーダ２０へ入力するタイミングもまた、TS1のソースパケットのarrival_time_stampによって決定される。TS1の最後のバイトがバッファへ入力する時刻は、時刻Ｔ２である。
【００９２】
（３）時刻Ｔ２以後
Ｔ２の時刻において、arrival time clock counterは、TS2の最初のソースパケットのarrival_time_stampの値にリセットされる。デコーダ２０のTB1、TBn又はTBsysのバッファへの入力タイミングは、TS2のソースパケットのarrival_time_stampによって決定される。
【００９３】
即ち、デコーダ２０への入力タイミングは、TS1の最後のバイトがバッファへ入力する時刻Ｔ２までは、デコーダ２０のTB1、TBn又はTBsysのバッファへの入力タイミングをTS1のソースパケットのarrival_time_stampによって決定し、Ｔ２以降は、TS2のソースパケットのarrival_time_stampによって決定する。
【００９４】
次に、ビデオのプレゼンテーションタイミングについて説明する。ビデオプレゼンテーションユニットの表示は、上述の図１又は図２に示すような接続点（コネクションポイント）を通して、ギャップなしに連続しなければならない。即ち、TS1の最後のビデオデータ（第１のピクチャ）に、TS2の最初のビデオデータ（第２のピクチャ）が連続して再生される。ここで、
STC1：TS1のシステムタイムベースの時間軸（図８ではSTC1と示す。）
STC2：TS2のシステムタイムベースの時間軸（図８ではSTC2と示す。）正確には、STC2は、TS2の最初のPCR（（Program Clock Refarence））がT-STDに入力した時刻から開始される。）
とする。
【００９５】
また、STC1とSTC2との間のオフセットは、次のように決定される。即ち、
PTS1ｅｎｄ：TS1の最後のビデオプレゼンテーションユニットに対応するSTC1上のPTS
PTS2ｓｔａｒｔ：TS2の最初のビデオプレゼンテーションユニットに対応するSTC2上のPTS
Ｔｐｐ：TS1の最後のビデオプレゼンテーションユニットの表示期間
とすると、２つのシステムタイムベースの間のオフセット値STC_deltaは、下記式（６）のように計算される。
【００９６】
【数６】
0004902935.tif 000007
【００９７】
次に、オーディオのプレゼンテーションタイミングについて説明する。TS1とTS2との接続点において、オーディオプレゼンテーションユニットの表示タイミングのオーバーラップがあってもよく、それは０以上であって２オーディオフレーム未満である（図８のオーディオオーバーラップを参照）。プレーヤには、どちらのオーディオサンプルを選択するかということ及び、オーディオプレゼンテーションユニットの表示を接続点の後の補正されたタイムベースに再同期する制御が要求される。
【００９８】
TS1からそれにシームレスに接続された次のTS2へと移る時、デコーダ２０のシステムタイムクロックの制御について、プレーヤが行う処理を説明する。
【００９９】
時刻Ｔ５において、TS1の最後のオーディオプレゼンテーションユニットが表示される。システムタイムクロックは、時刻Ｔ２からＴ５の間にオーバーラップしていてもよい。この区間では、デコーダ２０は、システムタイムクロックを古いタイムベースの値（STC1）を新しいタイムベースの値（STC2）に切り替える。
STC2の値は、下記式（７）のように計算できる。
【０１００】
【数７】
0004902935.tif 000008
【０１０１】
次に、TS1から、このTS1にシームレスに接続される次のTS2へと移る時、TS1及びTS2が満たさなければいけない符号化条件を説明する。ここで、
STC1１ｅｎｄ：TS1の最後のパケットの最後のバイトがデコーダ２０へ到着する時のシステムタイムベースSTC1上のSTCの値
STC2２ｓｔａｒｔ：TS2の最初のパケットの最初のバイトがデコーダ２０へ到着する時のシステムタイムベースSTC2上のSTCの値
STC2１ｅｎｄ：STC1１ｅｎｄの値をシステムタイムベースSTC2上の値に換算した値
とすると、STC2１ｅｎｄは、下記式（８）のようにして計算される。
【０１０２】
【数８】
0004902935.tif 000009
【０１０３】
ここで、デコーダ２０がDVR-STDに従うために、次の２つの条件を満たすことが要求される。
【０１０４】
（条件１）
TS2の最初のパケットのデコーダ２０への到着タイミングは、次に示す不等式（９）を満たさなければならない。
【０１０５】
【数９】
0004902935.tif 000010
【０１０６】
この上記不等式（９）を満たすように、Clip1及び／又はClip2の部分的なストリームを再エンコード及び／又は再多重化することが必要になる。
【０１０７】
（条件２）
STC1とSTC2とを同じ時間軸上に換算したシステムタイムベースの時間軸上において、TS1からのビデオパケットの入力とそれに続くTS2からのビデオパケットの入力は、ビデオバッファをオーバーフロウ及びアンダーフローさせてはならない。また、STC1とSTC2とを同じ時間軸上に換算したシステムタイムベースの時間軸上において、TS1からのパケットの入力とそれに続くTS2からのパケットの入力は、デコーダ２０のすべてのバッファをオーバーフロウおよびアンダーフローさせてはならない。
【０１０８】
図９は、あるAVストリーム(TS1)からそれにシームレスに接続された次のAVストリーム(TS2)へと移る時のトランスポートパケットの入力、復号、表示のタイミングチャートの他の例である。この場合もまた、TS1の最後のパケットまでのデコーダ２０への入力をそれらソースパケットのarrival_time_stampによって決定することは同様であるが、図８に示すタイミングチャートとの一点の違いとして、図９に示すように、TS1の最後のパケットの直後にTS2の最初のパケット入力する必要がないように、所定の時間間隔（delta1：時刻Ｔ２〜Ｔ２’の間）を設けている。これにより、TS2の最初のパケットの入力タイミングの決定が図８の場合よりも柔軟であるので、TS2の符号化を容易にする効果がある。
【０１０９】
この場合のデコーダ２０への入力タイミングについて、図９を参照して説明する。
【０１１０】
（１）時刻Ｔ２までの時間
時刻Ｔ２までの時間、すなわち、TS1の最後のパケットの最後のバイトがデコーダ２０へ入力終了するまでは、デコーダ２０のTB1、TBnまたはTBsysのバッファへの入力タイミングは、TS1のソースパケットのarrival_time_stampによって決定される。
【０１１１】
（２）時刻Ｔ２’以後
時刻Ｔ２からdelta1の時間の後、時刻Ｔ２'の時刻において、arrival time clock counterは、TS2の最初のソースパケットのarrival_time_stampの値にリセットされる。デコーダ２０のTB1、TBn又はTBsysのバッファへの入力タイミングは、TS2のソースパケットのarrival_time_stampによって決定される。
【０１１２】
ここで、図９に示すように、delta1を設ける場合、上述のSTC22ｓｔａｒｔとSTC21ｅｎｄ は下記の関係式（１０）を満たさなければならない。
【０１１３】
【数１０】
0004902935.tif 000011
【０１１４】
以上説明したように、デコーダ２０への入力タイミングを、先行するTS1の最後のビデオパケットを入力した後もソースパケットのアライバルタイムスタンプに従って行う点が１つ目の変更点である。次に２つ目の変更点について説明する。
【０１１５】
２つ目の変更点としては、デコーダ２０のオーディオバッファのサイズを、次の条件が満たされるような十分な大きさに変更する。この条件とは、TS1からこれにシームレスに接続される次のTS2へと移る時、TS1の最後のトランスポートパケットを入力後に、TS2の最初にデコードされるピクチャ（Ｉピクチャ）をそのデコードタイミングまでにビデオバッファへ入力できることである。
【０１１６】
この条件を満たすために、オーディオバッファの必要な容量の最大値は次のような値である。即ち、「Ｉピクチャの最大のビット量をそのデコードタイミングまでにビデオバッファへ入力できる時間」に相当する長さのオーディオのデータ量を蓄えられる大きさである。オーディオバッファの必要量の最大値EBn_maxは、次の式（１１）で計算できる。
【０１１７】
【数１１】
0004902935.tif 000012
【０１１８】
ここで、I_maxは、Iピクチャの最大のビット量であり、これは、図７に示すビデオコードバッファEB1の大きさである。Rvは、ビデオコードバッファEB1への入力ビットレートである。上記式（１１）に示すように、求めるべきオーディオバッファの大きさEBn_maxは、ビデオエレメンタリーストリームバッファ（EB1）への入力ビットレートでビデオコードバッファEB1のバッファ占有量をゼロからI_maxにするまでにかかる時間(I_max／Rv)にRaを掛けた値である。
【０１１９】
また、具体的な値として、少なくとも１００ミリ秒分のオーディオデータを蓄えられるバッファサイズを推奨する。これは以下の理由による。即ち、Ｉピクチャを０．５秒ごとに符号化する場合、Ｉピクチャのビットサイズは、一般的に、符号化ビットレートの１０％以下である。例えば、符号化ビットレートが１０Mbpsの場合、Ｉピクチャのサイズは、通常１Mbits以下である。
【０１２０】
従って、第１に、少なくとも、１００ミリ秒分の時間があれば、Ｉピクチャをそのデコードタイミングまでにデコーダ２０のビデオバッファへ入力できる。また、第２にデコーダ２０のオーディオバッファが、１００ミリ秒分のオーディオデータを蓄えられるのであれば、オーディオデータをそれが再生されるタイミングよりも１００ミリ秒だけ早く、オーディオバッファに入力終了するようにTS1を多重化できる。従って、オーディオバッファを、少なくとも１００ミリ秒分のオーディオデータを蓄えられるバッファサイズとすれば、上記第１及び第２の理由により、TS1からそれにシームレスに接続される次のTS2へと移る時、TS1の最後のトランスポートパケットを入力後に、TS2の最初にデコードされるピクチャ（Ｉピクチャ）をビデオバッファへ入力終了する（Ｉピクチャのコードタイミング）までの時間として少なくとも１００ミリ秒分を確保することができる。
【０１２１】
１００ミリ秒分のオーディオデータを蓄えられるオーディオバッファの容量を具体的に計算すると次のようになる。
【０１２２】
６４０kbpsのドルビーAC3オーディオストリームの場合：６４０kbps×０．１sec＝６４kbitS＝８kBytes
Linear PCMオーディオストリーム、２４bitSample、９６kHz sampling frequency、８channalsの場合：（24bitSample*96000samples/sec*8ch）×０．１sec＝２３０４００Bytes
【０１２３】
次に、以上説明した本実施の形態のデコーダ２０のように、DVR-STDのオーディオバッファのサイズを、「TS2の最初にデコードされるピクチャ（Ｉピクチャ）をそのデコードタイミングまでにビデオバッファへ入力できる時間に相当するオーディオのデータ量を蓄えられる大きさ」に変更することによる効果を図１０及び図１１を用いて更に詳細に説明する。
【０１２４】
例として、オーディオストリームが、ビットレート６４０kbps、サンプリング周波数４８kHzのAC3オーディオストリームの場合を説明する。AC3オーディオストリームの１オーディオフレームのサンプル数は１５３６samplesであるので、その時間長は、３２ミリ秒である。また、１オーディオフレームのバイトサイズは、２５６０Bytesである。
【０１２５】
図１０（ａ）及び（ｂ）は、従来のDVR-STDの場合であり、オーディオのバッファサイズが４kBytesである場合に、TS1からそれにシームレスに接続される次のTS2へと移る時のDVR-STDの夫々ビデオバッファ及びオーディオバッファのビット占有量の変化の例を示すグラフ図である。この図１０において、TS1のビデオ／オーディオデータのバッファ遷移を破線で示し、また、TS2のビデオ／オーディオデータのバッファ遷移を実線で示す。
【０１２６】
４kBytesのオーディオバッファは、５０ミリ秒分のオーディオデータを蓄えられる。従って、TS１の最後のオーディオパケットの最後のバイトがDVR-STDに到着する時刻であるSTC1１ａｕｄｉｏ_ｅｎｄにおいて、オーディオデータをそれが再生されるタイミングよりも５０ミリ秒だけ早く入力終了するようにTS1を多重化できる。しかしながら、５０ミリ秒は、TS2の最初にデコードされるピクチャ（Ｉピクチャ）をそのデコードタイミングまでにビデオバッファへ入力するためには、不十分である。そのため、TS2の最初にデコードされるピクチャ（Ｉピクチャ）のサイズを小さくするようにエンコードを制限することになり、画質が悪くなる問題がある。
【０１２７】
即ち、４kBytesのオーディオバッファでは、先送りすることができるオーディオデータは５０ミリ秒であるので、TS2の最初のＩピクチャをビデオバッファに入力するための時間である図１０に示すスタートアップディレイ（start-up delay）ｔ１は、最大５０ミリ秒と小さくなる。従って、TS2の最初のＩピクチャを入力する時間を十分とれず、ＩピクチャサイズＳ１が小さくなり、符号化が制限されＩピクチャの画質が劣化する。なお、このstart-up delayを大きくするため、上述した如く、従来は、４ｋBytesに加えて１秒分程度の付加的なバッファを設け、且つＴ１〜Ｔ２の間はTSの最大レートRＭＡＸで入力する必要があった。ここでは、ビットレート６４０kbpsのAC3オーディオストリームについて説明しているが、上述した如く、マルチチャネルのLPCMオーディオに対応可能なように設計すると、１秒分程度の付加的なバッファは極めて大きくなってしまう。
【０１２８】
この問題を解決するために、本実施の形態におけるデコーダ２０のように、DVR-STDのオーディオバッファサイズを例えば８kBytesに変更する。図１１（ａ）及び（ｂ）は、オーディオバッファの容量を最適化した例を示すものであって、オーディオのバッファサイズが８kBytesである場合に、TS1からこれにシームレスに接続される次のTS2へと移る時の本実施の形態におけるDVR-STDの夫々ビデオバッファ及びオーディオバッファのビット占有量の変化の例を示すグラフ図である。この図１１において、TS1のビデオ／オーディオデータのバッファ遷移を破線で示し、また、TS2のビデオ／オーディオデータのバッファ遷移を実線で示す。
【０１２９】
８kBytesのオーディオバッファは、１００ミリ秒分のオーディオデータを蓄えられる。したがって、TS１の最後のオーディオパケットの最後のバイトがDVR-STDに到着する時刻であるSTC1１ａｕｄｉｏ_ｅｎｄにおいて、オーディオデータをそれが再生されるタイミングよりも１００ミリ秒だけ早く入力終了するようにTS1を多重化できる。少なくとも、１００ミリ秒あれば、TS2の最初にデコードされるピクチャ（Ｉピクチャ）をそのデコードタイミングまでにビデオバッファへ入力する余裕ができる。即ち、TS2の最初のＩピクチャを入力する時間（スタートアップディレイ）ｔ２を十分とることができ、そのため、TS2の最初にデコードされるピクチャ（Ｉピクチャ）サイズＳ２を大きくすることができ、従ってＩピクチャのエンコード制限が小さく、高画質にすることができる。
【０１３０】
また、図７に示すようなプレーヤモデル１において、トランスポートパケットとそのアライバルタイムスタンプとを有するソースパケットを単位とするデータ列からなり、そのアライバルタイムスタンプに基づきデコーダにより読み出されてデコードされるTSは、多重化装置（情報処理装置）において生成され記録されたものとすることができる。
【０１３１】
多重化装置は、例えば上述の図３乃至５を参照して説明したように、所定のピクチャで表示終了するよう、再符号化したClip1（第１のビデオ符号化ストリーム）を生成し、このピクチャに続けて表示され、且つ表示開始できるよう再符号化したClip2（第２のビデオ符号化ストリーム）を生成するビデオ符号化部と、Clip1とこのClip1に同期したオーディオ符号化ストリームとを多重化してTS1を生成し、Clip2とこのClip2に同期したオーディオ符号化ストリームとを多重化してTS2を生成する多重化部と、TS1及びTS2からなる多重化ストリームを記録する記録部とを備える。ここで、多重化部においては、上記第２のピクチャであるＩピクチャをデコーダ２０のビデオバッファに入力するために要する時間分のオーディオデータを当該Ｉピクチャがデコーダ２０に入力開始される前までに入力終了可能なように多重化する。なお、図４に示すように、符号化部においてBridge-Clipを生成し、多重化部においてBridge-Clipも合わせて多重化するようにしてもよいことはもちろんである。
【０１３２】
このような多重化装置により生成された多重化ストリームが記録された記録媒体には、第１のピクチャで表示終了するTS1と、この第１のピクチャに続けて再生する第２のピクチャから表示開始するTS2とから生成され、TS1及びTS2が夫々のアライバルタイムスタンプに基づいてデコーダ２０に入力可能であって、且つ、第２のピクチャであるTS2の最初のピクチャをデコーダに入力するために要する時間分のオーディオデータを第２のピクチャがデコーダ２０に入力開始される前までに入力終了可能なように多重化された多重化ストリームが記録されたものとなっている。
【０１３３】
このように構成された本実施の形態においては、シームレスに接続されたTS1及びTS2を再生する際、TS1の最後のビデオパケットがデコーダ２０のTB1に入力終了した後からTS1の残りのパケットがデコーダ２０へ入力するまでにおいても、トランスポートパケットをアライバルタイムスタンプに従って入力するようにし、オーディオバッファのサイズを、従来のDVR-STDにおける４ｋBytesから、Ｉピクチャの最大のビット量をそのデコードタイミングまでにビデオバッファへ入力できる時間に相当する長さのオーディオのデータ量を蓄えられる大きさに変更することにより、TS1の最後のパケットが入力終了してからTS2の最初のピクチャであるＩピクチャをそのデコードタイミングまでに入力する時間（スタートアップディレイ）を十分確保することができるので、Ｉピクチャの符号化制限を小さくし、高画質とすることができる。
【０１３４】
また、従来のように付加的なバッファを設ける方法であると、例えばTSにおけるオーディオデータをマルチチャンネルのLPCMオーディオデータとした場合に極めて大きい容量の付加的なバッファが必要になるのに対し、本実施の形態においては、オーディオバッファの容量を上記のように変更し、アライバルタイムスタンプに従ってトランスポートパケットを入力するようにすることで、従来必要となっていた付加的なバッファを不要とすることができる。
【０１３５】
【発明の効果】
以上詳述した本発明においては、トランスポートパケットとそのアライバルタイムスタンプとを有するソースパケットを単位とするデータ列からなり、第１の多重化ストリームの最後のピクチャである第１のピクチャに第２の多重化ストリームの最初のピクチャである第２のピクチャが連続して再生されるよう接続された多重化ストリームを復号する情報処理装置において、上記多重化ストリームの上記アライバルタイムスタンプに従って上記ソースパケットを出力し、オーディオバッファの容量を、上記第２のピクチャをビデオバッファに入力するために要する時間分のオーディオデータをバッファリング可能なものとしたので、ビデオストリームとオーディオストリームの多重化ストリームをビデオフレーム精度で編集して、編集点をシームレスに再生することが可能であり、従来ソースパケットのarrival_time_stampを無視して、TSの最大ビットレートで入力するために必要とされていた１秒分の付加的なバッファを不要とし、従来よりもデコーダに必要なバッファ量を小さくできると共に、オーディオバッファのサイズを、上記第２のピクチャを上記ビデオバッファに入力するために要する時間分のオーディオデータをバッファリング可能な容量とすることにより第２のピクチャのエンコード制限が小さく、高画質とすることができる。
【図面の簡単な説明】
【図１】  Bridge-Clipを使用する場合の先行するPlayItemと現在のPlayItemとの関係を示す模式図である。
【図２】  Bridge-Clipを使用しない場合の先行するPlayItemと現在のPlayItemの関係を示す模式図である。
【図３】ビデオストリームとしてのClip1とClip2とをシームレス接続する例をピクチャの表示順序（Presentation order）で示す模式図である。
【図４】図３に示ビデオストリーム（Clip1及びClip2）をシームレス接続する場合に、第１の方法であるBridgeSequenceを使用してシームレス接続を実現する各AVストリームにおけるデータ列を示す模式図である。
【図５】図３示すビデオストリーム（Clip1及びClip2）をシームレス接続する場合に、第２の方法であるBridgeSequenceを使用しないでシームレス接続を実現する各AVストリームにおけるデータ列を示す模式図である。
【図６】オーディオの表示のオーバーラップを説明する図であって、TS1及びTS2におけるビデオのプレゼンテーションユニット及びオーディオのプレゼンテーションユニットを示す模式図である。
【図７】本発明の実施の形態における情報処理装置を示すブロック図である。
【図８】あるAVストリーム（TS1）から、これにシームレスに接続された次のAVストリーム（TS2）へと移る時のトランスポートパケットの入力、復号、及び表示のタイミングチャートである。
【図９】あるAVストリーム(TS1)からそれにシームレスに接続された次のAVストリーム(TS2)へと移る時のトランスポートパケットの入力、復号、表示の他の例を示すタイミングチャートである。
【図１０】（ａ）及び（ｂ）は、従来のDVR-STDの場合であり、オーディオのバッファサイズが４kBytesである場合に、TS1からそれにシームレスに接続される次のTS2へと移る時のDVR-STDの夫々ビデオバッファ及びオーディオバッファのビット占有量の変化の例を示すグラフ図である。
【図１１】（ａ）及び（ｂ）は、本発明の実施の形態における効果を説明する図であって、オーディオのバッファサイズが８kBytesである場合に、TS1からそれにシームレスに接続される次のTS2へと移る時のDVR-STDの夫々ビデオバッファ及びオーディオバッファのビット占有量の変化の例を示すグラフ図である。
【図１２】従来の情報処理装置を示すブロック図である。
【符号の説明】
１１  読出部、１２  リードバッファ、１３  ソースデパケッタイザ部、１４パルス発振器、１５  アライバルタイムクロックカウンタ
【図１】
0004902935.tif 000013
【図２】
0004902935.tif 000014
【図３】
0004902935.tif 000015
【図４】
0004902935.tif 000016
【図５】
0004902935.tif 000017
【図６】
0004902935.tif 000018
【図７】
0004902935.tif 000019
【図８】
0004902935.tif 000020
【図９】
0004902935.tif 000021
【図１０】
0004902935.tif 000022
【図１１】
0004902935.tif 000023
【図１２】
0004902935.tif 000024