(57)【要約】【課題】マルチメディアストリームのバッファの枯渇を防ぐ。【解決手段】ストリーム受信部１１は、オーディオとビデオに対応するストリームデータを入力する。ストリーム管理部１３ａ、１３ｂは、ストリーム受信部１１から入力して、一旦記憶部１５でバッファリングしたそれぞれのビデオストリームデータおよびオーディオストリームデータに関してストリーム処理部１２への受け渡しを制御する。記憶部１５は、オーディオバッファ領域１６、ビデオバッファ領域１７を有し、ストリームデータをそれぞれ対応する領域に一時的に保持する。バッファ管理部１４は、記憶部１５における領域のサイズに関し、ブロック単位にリング状のリスト構造となるように領域を管理し、バッファ再構築判定条件を元にリスト構造を変更することでストリームデータの入出力中に領域のサイズの変更を動的に行う。【選択図】図１
2007293502.tif 000002
【特許請求の範囲】
【請求項１】
複数のメディアを含むストリームデータを入出力する入出力部と、
前記複数のメディアに対応する複数の領域を有し、前記複数の領域に前記複数のメディアのうち対応するメディアを一時的に保持する記憶部と、
前記ストリームデータの入出力中に前記複数のメディアに応答して前記領域のサイズを動的に変更するバッファ管理部と、
を備えることを特徴とするマルチメディア処理システム。
【請求項２】
前記バッファ管理部は、ブロック単位にリング状のリスト構造となるように前記領域を管理し、バッファ再構築判定条件を元に該リスト構造を変更することで前記領域のサイズを変更することを特徴とする請求項１記載のマルチメディア処理システム。
【請求項３】
前記バッファ管理部は、一の領域のサイズを増大させる場合に、他の領域において現在入出力の対象となっていない空きブロックがあれば、該空きブロックを該他の領域のリスト構造から外して前記一の領域のリスト構造に繰り込むことを特徴とする請求項２記載のマルチメディア処理システム。
【請求項４】
前記バッファ管理部は、前記一の領域のサイズを増大させる場合に、前記他の領域において入出力の対象となっていない空きブロックが無ければ、該空きブロックが発生するまで待って、発生した空きブロックを該他の領域のリスト構造から外して前記一の領域のリスト構造に繰り込むことを特徴とする請求項３記載のマルチメディア処理システム。
【請求項５】
前記空きブロックが発生するまで待つ際に、発生する予定の空きブロックに対して前記一の領域のリスト構造に繰り込むためにリンクを張ることを特徴とする請求項４記載のマルチメディア処理システム。
【請求項６】
前記バッファ再構築判定条件は、所定のストリームデータをデコードして出力する際のデコードにおけるビットレートに基づいて定められることを特徴とする請求項２記載のマルチメディア処理システム。
【請求項７】
前記バッファ管理部は、所定のストリームデータのデコードにおけるビットレートが他のストリームデータのビットレートに比べて所定量増大したときに前記所定のストリームデータに対応する領域のサイズを増加させることを特徴とする請求項１〜５のいずれか一に記載のマルチメディア処理システム。
【請求項８】
複数のメディアを含むストリームデータを入出力する入出力部と、前記複数のメディアに対応する複数の領域を有し、前記複数の領域に前記複数のメディアのうち対応するメディアを一時的に保持する記憶部と、を備えるマルチメディア処理システムが前記領域のサイズを管理する方法であって、
前記ストリームデータの入出力中に前記複数のメディアに応答して前記領域のサイズを動的に変更することを特徴とするマルチメディア処理システムのバッファ管理方法。
【請求項９】
ブロック単位にリング状のリスト構造となるように前記領域を管理し、バッファ再構築判定条件を元に該リスト構造を変更することで前記領域のサイズを変更することを特徴とする請求項８記載のマルチメディア処理システムのバッファ管理方法。
【請求項１０】
一の領域のサイズを増大させる場合に、他の領域において現在入出力の対象となっていない空きブロックがあれば、該空きブロックを該他の領域のリスト構造から外して前記一の領域のリスト構造に繰り込むことを特徴とする請求項９記載のマルチメディア処理システムのバッファ管理方法。
【請求項１１】
前記一の領域のサイズを増大させる場合に、前記他の領域において入出力の対象となっていない空きブロックが無ければ、該空きブロックが発生するまで待って、発生した空きブロックを該他の領域のリスト構造から外して前記一の領域のリスト構造に繰り込むことを特徴とする請求項１０記載のマルチメディア処理システムのバッファ管理方法。
【請求項１２】
前記空きブロックが発生するまで待つ際に、発生する予定の空きブロックに対して前記一の領域のリスト構造に繰り込むためにリンクを張ることを特徴とする請求項１１記載のマルチメディア処理システムのバッファ管理方法。
【請求項１３】
前記バッファ再構築判定条件は、所定のストリームデータをデコードして出力する際のデコードにおけるビットレートに基づいて定められることを特徴とする請求項９記載のマルチメディア処理システムのバッファ管理方法。
【請求項１４】
所定のストリームデータのデコードにおけるビットレートが他のストリームデータのビットレートに比べて所定量増大したときに前記所定のストリームデータに対応する領域のサイズを増加させることを特徴とする請求項８〜１２のいずれか一に記載のマルチメディア処理システムのバッファ管理方法。
【請求項１５】
複数のメディアを含むストリームデータを入出力する入出力部と、前記複数のメディアに対応する複数の領域を有し、前記複数の領域に前記複数のメディアのうち対応するメディアを一時的に保持する記憶部と、を備えるマルチメディア処理システムを構成するコンピュータに、
前記ストリームデータの入出力中に前記複数のメディアに応答して前記領域のサイズを動的に変更するバッファ管理処理を実行させるプログラム。
【請求項１６】
前記バッファ管理処理において、ブロック単位にリング状のリスト構造となるように前記領域を管理し、バッファ再構築判定条件を元に該リスト構造を変更することで前記領域のサイズを変更することを特徴とする請求項１５記載のプログラム。
【請求項１７】
前記バッファ管理処理において、一の領域のサイズを増大させる場合に、他の領域において現在入出力の対象となっていない空きブロックがあれば、該空きブロックを該他の領域のリスト構造から外して前記一の領域のリスト構造に繰り込むことを特徴とする請求項１６記載のプログラム。
【請求項１８】
前記バッファ管理処理において、前記一の領域のサイズを増大させる場合に、前記他の領域において入出力の対象となっていない空きブロックが無ければ、該空きブロックが発生するまで待って、発生した空きブロックを該他の領域のリスト構造から外して前記一の領域のリスト構造に繰り込むことを特徴とする請求項１７記載のプログラム。
【請求項１９】
前記バッファ管理処理において、前記空きブロックが発生するまで待つ際に、発生する予定の空きブロックに対して前記一の領域のリスト構造に繰り込むためにリンクを張ることを特徴とする請求項１８記載のプログラム。
【請求項２０】
前記バッファ再構築判定条件は、所定のストリームデータをデコードして出力する際のデコードにおけるビットレートに基づいて定められることを特徴とする請求項１６記載のプログラム。
【請求項２１】
前記バッファ管理処理において、所定のストリームデータのデコードにおけるビットレートが他のストリームデータのビットレートに比べて所定量増大したときに前記所定のストリームデータに対応する領域のサイズを増加させることを特徴とする請求項１５〜１９のいずれか一に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、マルチメディア処理システム、そのバッファ管理方法およびプログラムに係り、特にビデオとオーディオを同時にデコードする動画システム等における複数のストリームバッファを同時に使用する際のバッファ管理技術に関する。
【背景技術】
【０００２】
ビデオとオーディオを同時にデコード及びエンコードする動画システム等において、複数のストリームバッファを同時に使用するマルチメディア処理システムが用いられる。マルチメディア処理システムは、デコードの対象となるストリームデータをカード等のストレージやネットワークから読み出しながら、エンコードしたストリームデータをストレージやネットワークへ書き込む。このとき、デコードするためにカードやネットワークから読み出したストリームデータ、及びエンコードしたデータをカードやネットワークへ書き込むために、一時的に格納するためのメモリを確保する必要がある。
【０００３】
例えば再生において、カードインタフェースやネットワーク等に負荷がかかり一時的にストリームデータが供給されなくなると、再生が中断してしまう。そこで、通常は、ある一定の枠内でストリームデータをメモリにバッファリングし、一時的にストリームが供給されなくなったときはバッファリングしたストリームを再生することでビデオやオーディオの再生途切れを防ぐようにする。例えばビデオとオーディオを同時にデコード及びエンコードする動画システムであれば、ストリームデータを一時的に保存するメモリとして、ビデオ再生、オーディオ再生、ビデオ記録、オーディオ記録に対応するそれぞれのメモリが必要となる。このような複数のメモリを備えることは、部品点数の増加やコストの増加につながってしまう。
【０００４】
そこで、例えば特許文献１では、メモリを１つとし、そのメモリ内の容量を、記憶動作、再生動作などの状況に応じて、振り分けるように構成する記録再生装置が開示されている。この記録再生装置は、メモリ調停部を設け、メモリ調停部に対して記録動作が指示されると、記録に必要なビデオアクセスユニット領域、オーディオアクセスユニット領域等の領域を確保して割り当てる。再生動作が指示されれば、再生に必要な再生用多重化ストリーム領域等を確保して割り当てる。記録再生動作が指示されると、記録用多重化ストリーム領域、再生用多重化ストリーム領域等を割り当てる。このように、再生／記録の判断に基づいてストリーム領域を割り当てることで、複数のメモリを備えることなく記録や再生の動作を行うことを可能としている。
【０００５】
【特許文献１】特開２００２−５１２８８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところで、特許文献１に記載される記録再生装置は、メモリの確保及び割り当てを再生／記録開始時に行っている。このため、初期段階で想定して確保したメモリ以上にストリームが供給されなかった場合には、ビデオやオーディオの再生途切れが発生してしまう。例えばストリーミング再生において、再生開始時のビデオ符号量／オーディオ符号量に応じてビデオ再生用メモリ／オーディオ再生用メモリを割り当てた場合に、再生途中で符号量の割合が変動してオーディオ符号量が高くなると、オーディオのバッファリング量が少なくなるためにシステム負荷によってオーディオの再生途切れが発生しやすくなってしまう虞がある。
【０００７】
マルチメディア処理システムにおいて音飛びと絵飛びを防ぐためには、ビデオ及びオーディオそれぞれに対して最大符号量を考慮したバッファサイズを確保するのが理想である。しかし、メモリの使用量には限界があり、設計段階では通常の使用状況をベースとするために、設計段階で想定したビットレートに比べて、記録／再生ビットレートが低くなると過剰なバッファが増えることとなり、逆に高くなるとバッファが少なくなる。この高ビットレート状態においてシステムの負荷変動が大きくなりストリームの供給遅れが発生したときには、バッファの枯渇が発生してしまう。
【０００８】
本発明の解決課題は、システムの負荷が高くなってストリーム供給の遅れが発生したときのストリームバッファの枯渇を防ぐことにある。
【課題を解決するための手段】
【０００９】
本発明の１つのアスペクトに係るマルチメディア処理システムは、複数のメディアを含むストリームデータを入出力する入出力部と、複数のメディアに対応する複数の領域を有し、複数の領域に複数のメディアのうち対応するメディアを一時的に保持する記憶部と、ストリームデータの入出力中に複数のメディアに応答して領域のサイズを動的に変更するバッファ管理部と、を備える。
【００１０】
本発明の１つのアスペクトに係るマルチメディア処理システムのバッファ管理方法は、複数のメディアを含むストリームデータを入出力する入出力部と、複数のメディアに対応する複数の領域を有し、複数の領域に複数のメディアのうち対応するメディアを一時的に保持する記憶部と、を備えるマルチメディア処理システムが領域のサイズを管理する方法であって、ストリームデータの入出力中に複数のメディアに応答して領域のサイズを動的に変更する。
【００１１】
本発明の１つのアスペクトに係るプログラムは、複数のメディアを含むストリームデータを入出力する入出力部と、複数のメディアに対応する複数の領域を有し、複数の領域に複数のメディアのうち対応するメディアを一時的に保持する記憶部と、を備えるマルチメディア処理システムを構成するコンピュータに、ストリームデータの入出力中に複数のメディアに応答して領域のサイズを動的に変更するバッファ管理処理を実行させる。
【発明の効果】
【００１２】
本発明によれば、ストリームデータのデータ量に合わせてそれぞれのメディアに対応するバッファサイズを動的に増減することで、システムの負荷が高くなってストリーム供給の遅れが発生したときのストリームバッファの枯渇を防ぐことができる。
【発明を実施するための最良の形態】
【００１３】
本発明の実施形態に係るマルチメディア処理システムは、それぞれのメディア、例えばオーディオとビデオに対応するストリームデータを入出力する入出力部と、それぞれのメディアに対応する領域を有し、ストリームデータをそれぞれ対応する領域に一時的に保持する記憶部と、記憶部における領域のサイズを管理するバッファ管理部と、を備える。バッファ管理部は、ブロック単位にリング状のリスト構造となるように領域を管理し、バッファ再構築判定条件を元にリスト構造を変更することでストリームデータの入出力中に領域のサイズの変更を動的に行う。
【００１４】
また、バッファ管理部は、例えばオーディオ用の領域のサイズを増大させる場合に、ビデオ用の領域において現在入出力の対象となっていない空きブロックがあれば、空きブロックをビデオ用の領域のリスト構造から外してオーディオ用の領域のリスト構造に繰り込む。ビデオ用の領域において入出力の対象となっていない空きブロックが無ければ、空きブロックが発生するまで待って、発生した空きブロックをビデオ用の領域のリスト構造から外してオーディオ用の領域のリスト構造に繰り込む。ここで、空きブロックが発生するまで待つ際に、発生する予定の空きブロックに対してオーディオ用の領域のリスト構造に繰り込むためにリンクを張るようにする。
【００１５】
なお、バッファ再構築判定条件は、所定のストリームデータをデコードして出力する際のデコードにおけるビットレートに基づいて定められ、バッファ管理部は、所定のストリームデータのデコードにおけるビットレートが他のストリームデータのビットレートに比べて所定量増大したときに所定のストリームデータに対応する領域のサイズを増加させる。
【００１６】
このようにバッファ管理部は、入出力ストリームを監視し、全てのバッファへのアクセス状況を把握する。例えば再生において、オーディオの再生ビットレートが高くなり、出力する符号量があるレベルを超えたときには、ビデオバッファエリアを削減し、オーディオバッファエリアを拡大する。このように再生／記録符号量に合わせてビデオ／オーディオそれぞれのバッファ領域の大きさを動的に増減することで、システムの負荷が高くなってストリーム供給遅れが発生したときのストリームバッファの枯渇を防ぐようにする。
【００１７】
以上のように、ストリームデータのビットレートに応じてそれぞれのメディアに対応するバッファサイズを動的に変更することで、バッファの状態を過不足無く適切な状態で使用することができる。また、万が一システム負荷によるストリーム供給遅れが発生しても、その影響を極力防ぐことが可能となる。以下、実施例に即し、図面を参照して詳しく説明する。
【実施例１】
【００１８】
図１は、本発明の実施例に係るマルチメディア処理システムの主要部を表すブロック図である。図１において、マルチメディア処理システムは、ストリーム受信部１１と、ストリーム処理部１２と、ストリーム管理部１３ａ、１３ｂと、バッファ管理部１４と、記憶部１５とを含む。
【００１９】
ストリーム受信部１１は、不図示のカード等のストレージやネットワーク等からストリームデータである受信データＤｉを受信し、受信データＤｉにおけるメディアの種別に対応してストリーム管理部１３ａ、１３ｂに振り分けて出力する。例えば、ストリーム管理部１３ａは、オーディオデータを扱い、ストリーム管理部１３ｂは、ビデオデータを扱う。ストリーム処理部１２は、ストリーム管理部１３ａ、１３ｂから出力されるストリームのデコードを行い、不図示の再生出力側に出力する。
【００２０】
ストリーム管理部１３ａは、ストリーム受信部１１から入力して、一旦記憶部１５でバッファリングしたオーディオストリームデータに関してストリーム処理部１２への受け渡しを制御する。すなわち、記憶部１５への書き込みあるいは記憶部１５からの読み出しに際し、バッファ管理部１４にリードライト要求Ｒｑ１を出力する。その後、リードライトデータＤ１を記憶部１５との間で転送し、転送終了時にバッファ管理部１４からリードライト完了Ｒｃ１を受け取る。また、ストリーム管理部１３ｂも同様であって、ストリーム受信部１１から入力して、一旦記憶部１５でバッファリングしたビデオストリームデータに関してストリーム処理部１２への受け渡しを制御する。すなわち、記憶部１５への書き込みあるいは記憶部１５からの読み出しに際し、バッファ管理部１４にリードライト要求Ｒｑ２を出力する。その後、リードライトデータＤ２を記憶部１５との間で転送し、転送終了時にバッファ管理部１４からリードライト完了Ｒｃ２を受け取る。
【００２１】
バッファ管理部１４は、リードライト要求Ｒｑ１、Ｒｑ２およびストリーム処理部１２から送られるストリーム情報Ｓｔに応じて記憶部１５における複数のバッファの管理を行い、リードライトのためのアドレス情報Ａｄを記憶部１５に与える。記憶部１５は、バッファとして大きさが動的に制御されるオーディオバッファ領域１６とビデオバッファ領域１７とを備え、リードライトデータＤ１、Ｄ２をそれぞれ領域毎にバッファリングする。
【００２２】
図２は、バッファ管理部１４の構成を表すブロック図である。図２において、バッファ管理部１４は、読み出し制御部２１、書き込み制御部２２、バッファ使用頻度情報蓄積部２３、最適化部２４、バッファ構成情報管理部２５を備える。
【００２３】
読み出し制御部２１は、バッファリスト更新部３１とバッファ面更新部３２とを備え、記憶部１５からの読み出し処理時に動作して読み出し情報およびバッファ構成情報の更新を行う。バッファリスト更新部３１は、リードライト要求Ｒｑ１（Ｒｑ２）における読み出し要求と読み出し可能情報Ｒｉとから読み出し情報Ｒｒを求めてバッファ使用頻度情報蓄積部２３に出力する。すなわち、読み出し要求（デコード処理を実行するためのストリームデータ取得要求）が入力されると、バッファ構成情報管理部２５から読み出し可能情報Ｒｉを取得（バッファツリーにストリームデータが格納されているか否かを調べ、格納されていれば先頭ブロックの情報を取得）する。もし、読み出し不可であれば（バッファにストリームデータが無ければ）読み出し可能になるまで待つ。読み出し可能な情報が取得できたときに、バッファ面更新部３２にバッファリストの更新を指示する。バッファ面更新部３２は、読み出し可能な情報を取得できたときに、読み出すストリームデータの格納されているバッファ面を破棄するためにバッファリング面更新情報Ｂｍをバッファ構成情報管理部２５に出力する。出力が終了すると、読み出し完了情報であるリードライト完了Ｒｃ１（Ｒｃ２）をストリーム管理部１３ａ（１３ｂ）に出力する。これによって、ストリーム管理部１３ａ（１３ｂ）は、読み出したストリームデータを実際にデコードする。さらに、バッファリスト更新部３１は、読み出し情報が更新されたこと示す読み出し情報Ｒｒをバッファ使用頻度情報蓄積部２３に出力する。この出力は、バッファ使用頻度によってバッファの再構築を行うときに用いられる。
【００２４】
書き込み制御部２２は、バッファ面生成部３３とバッファリスト更新部３４とを備え、バッファへの書き込み処理時に動作し、書き込み情報およびバッファ構成情報の更新を行う。バッファ面生成部３３は、リードライト要求Ｒｑ１（Ｒｑ２）中の書き込み要求と書き込み可能情報取得Ｗｉとから書き込み情報Ｗｒを求めてバッファ使用頻度情報蓄積部２３に出力する。書き込み要求（ストリームデータを格納するための要求）が入力されると、バッファ構成情報管理部２５から書き込み可能情報Ｗｉを取得（バッファツリーにストリームデータを格納するための空きブロックが存在するか否かを調べ、存在すれば空きブロックの情報を取得）する。もし、書き込み不可であれば（バッファに空きブロックが無ければ）書き込み可能になるまで待つ。書き込み可能な情報が取得できたときに、バッファリスト更新部３４にバッファリストの更新を指示する。バッファリスト更新部３４は、書き込み可能な情報を取得できたときに、書き込むストリームデータのバッファ面を生成するためにバッファリング面更新情報Ｂｎをバッファ構成情報管理部２５に出力する。出力が終了すれば、書き込み完了情報であるリードライト完了Ｒｃ１（Ｒｃ２）をストリーム管理部１３ａ（１３ｂ）に出力し、ストリームデータが実際にバッファに格納されたことを通知する。さらに、バッファ面生成部３３は、書き込み情報が更新されたこと示す書き込み情報Ｗｒをバッファ使用頻度情報蓄積部２３に出力する。この出力は、バッファ使用頻度によってバッファの再構築を行うときに用いられる。
【００２５】
バッファ使用頻度情報蓄積部２３は、読み出し情報Ｒｒと書き込み情報Ｗｒとからバッファ使用頻度情報Ｂｇを求めて最適化部２４に出力する。読み出し情報Ｒｒは、デコード処理を行うためにストリームデータをバッファから読み出したときの更新情報（バッファからデータがどれだけ無くなったかを示す情報）であり、書き込み情報Ｗｒは、ストリームデータをバッファに格納したときの更新情報（バッファにデータをどれだけ格納したかを示す情報）である。この２つの情報を合わせて現在バッファがどのように使用されているか（バッファからデータが減り続けているのか、増え続けているのか、増減が一定しているのか、等）を示すのがバッファ使用頻度情報Ｂｇである。
【００２６】
最適化部２４は、再構築判定部３５と再構築実行部３６とを備え、定期的に起動され、ストリーム情報Ｓｔ及びバッファの使用状態をモニタし、必要に応じてバッファ構成を変更するためのバッファ再構築情報Ｂｃをバッファ構成情報管理部２５に出力する。最適化部２４は、通常はストリーム情報Ｓｔを用いて最適化するが、必要に応じてストリーム情報Ｓｔの代わりにバッファ使用頻度情報Ｂｇを用いて最適化する。例えば、オーディオのストリーム読み出し情報に対してビデオのストリーム読み出し情報の頻度が高い場合、オーディオ用に対してビデオ用バッファの割合を多くなるように再構築してビデオストリームデータを多く格納する。あるいは逆にオーディオのストリーム読み出し情報に対してビデオのストリーム読み出し情報の頻度が高い場合、オーディオ用に対してビデオ用バッファの割合を多くなるように再構築してビデオストリームデータを多く格納するというようにバッファ構成を変更する。
【００２７】
バッファ構成情報管理部２５は、バッファをブロックに細分化した情報として管理し、図３に示すようなブロック情報４１とリードライトポインタ情報４２とを保持する。ブロック情報４１は、図３（Ａ）に示すようなブロック毎の情報として、ブロック番号ＢＮ、ブロックに入るべきストリームのメディア識別子Ｍ１、現在ブロックに入っているストリームのメディア識別子Ｍ２、次のストリームが格納されているブロック番号Ｌ（リンクを表す）をそれぞれブロック数分だけ備える。ここでメディア識別子Ｍ１、Ｍ２は、例えば、ビデオストリームデータであれば「Ｖ」、オーディオストリームデータであれば「Ａ」、何も無い場合には「０」が割り当てられる。また、図３（Ｂ）に示すようなリードライトポインタ情報４２として、各メディアのリードライトブロック番号とこれに対応するアドレスを持つ。すなわち、ビデオ読み出しブロック番号とこれに対応するビデオ読み出しアドレス、ビデオ書き込みブロック番号とこれに対応するビデオ書き込みアドレス、オーディオ読み出しブロック番号とこれに対応するオーディオ読み出しアドレス、オーディオ書き込みブロック番号とこれに対応するオーディオ書き込みアドレス、を備える。
【００２８】
さらに、バッファ構成情報管理部２５は、使用可能メモリを複数のブロックに細分化して管理するために、図４に示すようにブロック単位にリング状のリスト構造となるバッファツリーを構築する。すなわち、ビデオブロック群４３ａは、ブロック番号１、２、３、４のブロックをリング状のリストとする。また、オーディオブロック群４３ｂは、ブロック番号５、６、７、８のブロックをリング状のリストとする。そして、リスト構造となるブロックに関するブロック情報４１とリードライトポインタ情報４２とを元に記憶部１５におけるアクセス対象となるアドレス情報Ａｄを出力する。
【００２９】
次に、マルチメディア処理システムの動作について説明する。図５は、マルチメディア処理システムの動作を表すフローチャートである。デコード開始前にバッファ管理部１４に対し、実行情報（ストリーミング再生、ビデオ＋オーディオ）、トータル使用可能メモリサイズ、バッファ再構築判定条件、ストリームバッファの優先度等を設定する（ステップＳ１１）。
【００３０】
ストリームデータのデコードを開始すると、ストリーム受信部１１にビデオストリームデータ、オーディオストリームデータが送られる（ステップＳ１２）。このときストリーム受信部１１は、ビデオストリームデータであればストリーム管理部１３ａにデータ格納リクエストを発行し、オーディオストリームデータであればストリーム管理部１３ｂにデータ格納リクエストを発行する。それぞれのストリーム管理部１３ａ、１３ｂは、バッファ管理部１４に対してストリームデータ格納リクエストを発行する。
【００３１】
バッファ管理部１４は、ストリームデータ格納リクエストが発行されると（ステップＳ１２のＹ）、バッファ構成情報管理部２５のリードライトポインタ情報４２を参照し、記憶部１５の空き領域にストリームデータをバッファリングし（ステップＳ１３）、バッファ構成情報管理部２５内の各情報を更新し（ステップＳ１４）、ストリーム管理部１３ａ（１３ｂ）に格納完了を通知する。それぞれのストリーム管理部１３ａ、１３ｂは、ストリーム受信部１１に対して格納完了を通知する。
【００３２】
また、マルチメディア処理システムにおいて、ストリームデータ入力ではなく（ステップＳ１２のＮ）、デコード処理を実行するときは（ステップＳ１５）、ストリーム処理部１２がストリーム管理部１３ａ（１３ｂ）にデータ読み出しリクエストを発行する。それぞれのストリーム管理部１３ａ、１３ｂは、バッファ管理部１４に対してデータ読み出しリクエストを発行する。
【００３３】
バッファ管理部１４は、データ読み出しリクエストが発行されると、バッファ構成情報管理部２５のリードライトポインタ情報４２を参照して記憶部１５のストリームデータを読み出し（ステップＳ１６）、バッファ構成情報管理部２５内の各情報を更新して（ステップＳ１４）、ストリーム管理部１３ａ（１３ｂ）に読み出し完了を通知する。それぞれのストリーム管理部１３ａ、１３ｂは、ストリーム処理部１２に対し読み出し完了を通知する。その後、ストリーム処理部１２は、読み出したデータをデコードする。
【００３４】
最適化部２４は、一定周期ごとに起動され、バッファの再構築を実施するか否かを判定する（ステップＳ１７）。例えば、再構築の条件を「オーディオ再生ビットレートがビデオ＋オーディオの合計ビットレートに対して２割以上変化した場合」に設定していたとき、バッファ管理部１４に入力されるストリーム情報Ｓｔを監視し、再構築条件を満たしているか否かを判断する。再構築条件を満たしたとき（ステップＳ１７のＹ）には、バッファ再構築情報Ｂｃを発行する。それを受けてバッファ構成情報管理部２５におけるリンク情報を再構成する（ステップＳ１４）。これにより、ビデオ／オーディオそれぞれのストリームがビットレートに応じたバッファサイズを確保することができる。再構築条件を満たさないとき（ステップＳ１７のＮ）には、ステップＳ１８に進む。デコードが全て終了していない場合には、ステップＳ１２に戻る。
【００３５】
次に、バッファの再構築について、具体的な例を取り上げて説明する。バッファ構成情報の再構築の一具体例として、空きブロックがある場合について示す。図６（Ａ）に示すビデオブロック群４３ｃにおいて、ブロック番号１のブロックが読み出し中であって、ブロック番号２のブロックが書き込み中であって、ブロック番号３、４が空きブロック（メディア識別子Ｍ２が０）である。また、オーディオブロック群４３ｄにおいて、ブロック番号５のブロックが読み出し中であって、ブロック番号６のブロックが書き込み中であって、ブロック番号７、８が空きブロックである。ビデオの２つの空きブロックをオーディオ用に変換する場合、図６（Ｂ）に示すように、ブロック番号３、４をビデオ用ブロックのリンクから外してオーディオ用ブロックのリンクに加える。すなわち、ブロック番号８のリンク先をブロック番号５からブロック番号３に変更し、ブロック番号４のリンク先をブロック番号１からブロック番号５に変更すると共に、ブロック番号３、４のメディア識別子Ｍ１を「Ｖ」から「Ａ」に変更する。このようにして、ビデオブロック群４３ｃは４３ｅに、オーディオブロック群４３ｄは４３ｆに変更し、空きブロックをオーディオ用に変換してリスト構造を再構築する。
【００３６】
また、別の例として、再構築時に空きブロックがない場合について示す。図７において、ビデオ用の２つのブロックをオーディオ用に変換する際、図７（Ａ）に示すように、ビデオのブロックに空きが無いとする（ブロック番号１〜４のメディア識別子Ｍ２が「Ｖ」）。この場合、図７（Ｂ）に示すように、ブロック番号８のリンク先をブロック番号５からブロック番号１に変更すると共にブロック番号１、２のメディア識別子Ｍ１を「Ｖ」から「Ａ」に変更する。また、ブロック番号４のリンク先をブロック番号１からブロック番号３に変更する。このようにビデオの読み出し中のブロックに対し予約となるリンクを張って再構築を行う。そして、ブロック番号２までビデオの読み出しが完了したならば、図７（Ｃ）に示すように、ブロック番号２のリンク先をブロック番号３からブロック番号５に変更すると共にブロック番号１、２のメディア識別子Ｍ２を「Ｖ」から「０」に変更する再構築を行う。
【００３７】
以上のように、本発明のマルチメディア処理システムは、全てのバッファへのアクセス状況を監視し、出力ストリームのチェックを行う。例えばオーディオの再生ビットレートが高くなり、出力する符号量があるスレッシュレベルを超えたときには、ブロックのリンク構造を変更してビデオバッファエリアを削減し、オーディオバッファエリアを拡大する。これによって、システム負荷が重くなってストリーム供給遅れが発生したときのストリームバッファの枯渇を防ぐ。次にこの様子を、ストリーミング等によるビデオとオーディオを同時に扱うシステムにおいて、ビデオとオーディオの合計符号量が固定されているときを例にとって説明する。
【００３８】
オーディオのビットレートが増加した状態でシステム負荷が高くなった場合であって、本発明を適用しなかった場合の各情報量の変動を表すタンミングチャートを図８に示す。タイミングｔ１でオーディオの符号量が増大し、タイミングｔ２で負荷が重くなってストリーム供給遅れが発生し、オーディオ用にバッファリングされたストリームデータを用いて再生を続ける。しかし、バッファリングされたストリームデータを全て使用したタイミングｔ３でバッファの枯渇が発生し、タイミングｔ３、ｔ４間で音切れが発生してしまう。
【００３９】
同様にオーディオのビットレートが増加した状態でシステム負荷が高くなった場合であって、本発明を適用した場合のタンミングチャートを図９に示す。タイミングｔ１でオーディオのビットレートが増加したときにはオーディオバッファの上限値を拡大する。タイミングｔ２で負荷が重くなりストリーム供給遅れが発生したときには、ビットレートに合わせて拡張されたバッファに格納されているデータを用いて再生する。これによって、タイミングｔ３でのバッファの枯渇を生じることなく音切れの発生を防ぐことができる。
【図面の簡単な説明】
【００４０】
【図１】本発明の実施例に係るマルチメディア処理システムの主要部を表すブロック図である。
【図２】本発明の実施例に係るバッファ管理部の構成を表すブロック図である。
【図３】ブロック情報とリードライトポインタ情報の構成を示す図である。
【図４】ブロックのリスト構造を示す図である。
【図５】本発明の実施例に係るマルチメディア処理システムの動作を表すフローチャートである。
【図６】ブロックのリスト構造の変化の第１の例を示す図である。
【図７】ブロックのリスト構造の変化の第２の例を示す図である。
【図８】本発明を適用しなかった場合の各情報量の変動を表すタンミングチャートである。
【図９】本発明を適用した場合の各情報量の変動を表すタンミングチャートである。
【符号の説明】
【００４１】
１１  ストリーム受信部
１２  ストリーム処理部
１３ａ、１３ｂ  ストリーム管理部
１４  バッファ管理部
１５  記憶部
１６  オーディオバッファ領域
１７  ビデオバッファ領域
２１  読み出し制御部
２２  書き込み制御部
２３  バッファ使用頻度情報蓄積部
２４  最適化部
２５  バッファ構成情報管理部
３１  バッファリスト更新部
３２  バッファ面更新部
３３  バッファ面生成部
３４  バッファリスト更新部
３５  再構築判定部
３６  再構築実行部
４１  ブロック情報
４２  リードライトポインタ情報
４３ａ、４３ｃ、４３ｅ  ビデオブロック群
４３ｂ、４３ｄ、４３ｆ  オーディオブロック群
【図１】
2007293502.tif 000003
【図２】
2007293502.tif 000004
【図３】
2007293502.tif 000005
【図４】
2007293502.tif 000006
【図５】
2007293502.tif 000007
【図６】
2007293502.tif 000008
【図７】
2007293502.tif 000009
【図８】
2007293502.tif 000010
【図９】
2007293502.tif 000011