(57)【要約】【課題】  マルチメディアコンテンツの再生システムは、特定の順序でストリームを処理するように制御しなければ、正しい再生が行われない危惧があり、その問題を避けるために、ストリームの処理順序を正しく維持する制御を行えば、再生の開始が遅くなる副次的な問題点がある。【解決手段】  ストリーム入力部1はメディアストリームを入力し、ストリーム蓄積部2は入力したメディアストリームを保持し、ストリーム処理部3はメディアストリームをデータ処理する。そして、ストリーム蓄積制御部4は、保持されたメディアストリームから参照される参照先のメディアストリームが利用可能になるまで、参照元のメディアストリームが保持されるように、ストリーム蓄積部2を制御する。【選択図】    図4
2005184695.tif 000002
【特許請求の範囲】
【請求項１】
メディアストリームを入力する入力手段と、
前記入力手段によって入力されるメディアストリームを保持する保持手段と、
前記メディアストリームをデータ処理する処理手段とを有し、
前記保持手段は、保持したメディアストリームから参照される参照先のメディアストリームが利用可能になるまで、参照元のメディアストリームを保持することを特徴とするマルチメディアデータ再生装置。
【請求項２】
前記保持手段は、前記参照先のメディアストリームが利用可能になると、前記参照元のメディアストリームの保持を解除し、保持したメディアストリームを前記処理手段に送出することを特徴とする請求項1に記載されたマルチメディアデータ再生装置。
【請求項３】
前記保持手段は、前記メディアストリームの種類を判断し、ストリームの属性情報が記述されたメディアストリームは保持せずに前記処理手段へ送出することを特徴とする請求項1または請求項2に記載されたマルチメディアデータ再生装置。
【請求項４】
前記処理手段は、前記属性情報が記述されたメディアストリームの処理が完了すると、その属性情報によって示されるメディアストリームの保持の解除要求を発行することを特徴とする請求項3に記載されたマルチメディアデータ再生装置。
【請求項５】
前記属性情報が記述されたメディアストリームは、MPEG-4におけるオブジェクトディスクリプタを扱うことを特徴とする請求項3または請求項4に記載されたマルチメディアデータ再生装置。
【請求項６】
前記保持手段は、前記メディアストリームの種類を判断し、映像・音声ストリーム等の、データを破棄可能なストリームは破棄可能にすることを特徴とする請求項1から請求項5の何れかに記載されたマルチメディアデータ再生装置。
【請求項７】
前記処理手段は、制御データが記述されたメディアストリームが示す属性情報が記述されたメディアストリームを参照する際は、前記属性情報が記述されたメディアストリームが利用可能になるまで待機することを特徴とする請求項1または請求項2に記載されたマルチメディアデータ再生装置。
【請求項８】
メディアストリームを入力し、
入力したメディアストリームを保持し、
前記メディアストリームをデータ処理する各ステップを有し、
前記保持は、保持したメディアストリームから参照される参照先のメディアストリームが利用可能になるまで、参照元のメディアストリームを保持することを特徴とするマルチメディアデータ再生方法。
【請求項９】
情報処理装置を制御して、請求項8に記載されたマルチメディア処理を実行することを特徴とするプログラム。
【請求項１０】
請求項9に記載されたプログラムが記録されたことを特徴とする記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はマルチメディアデータ再生装置およびその方法に関し、例えば、制御ストリームデータとビデオまたはオーディオ符号化ストリームデータによって構成されるマルチメディアコンテンツの再生に関する。
【背景技術】
【０００２】
メディア表現の高度化にともない、従来の音声・映像によるメディア表現から、それらをディジタル符号化、多重化して複数のメディア情報を統合して一つのコンテンツとして表現する、いわゆるマルチメディア表現が一般的に用いられるようになった。現在、このようなマルチメディア表現の適用領域は、DVDのメニューシステム、ディジタルテレビ放送、テレビ会議システムにおけるホワイトボード情報など多用途に用いられている。
【０００３】
上記のようなマルチメディア表現を実現するには、それらをコンテンツの作成者が意図する空間的な配置や、時間的な順序関係で再現するための情報が記述された「データ」ストリームと呼ばれる種類のストリームを、音声・映像ストリームとともに用いる。
【０００４】
典型的なマルチメディアシステムにおけるデータストリームは、音声や映像ストリームとは独立したストリームとして、ネットワークなどの伝送手段を介して再生端末に渡される。そして、再生端末は、受け取ったデータストリームの内容に基づき、映像・音声ストリームのデータを合成し、最終的に一つのマルチメディア表現として再生する。
【０００５】
上記のようなマルチメディア表現のための符号化を規定する規格に、国際標準規格ISO/IEC14496-1（非特許文献1参照）として定められるMPEG-4システムのようなものがある。MPEG-4システムは、映像・音声といったデータを「オブジェクト」として扱い、複数のオブジェクトが空間的、時間的に配置された「シーン」を表現可能な特徴をもつ。
【０００６】
図1はMPEG-4システムにおける映像・音声データをシーンとして表現するためのメカニズムを説明する図である。
【０００７】
MPEG-4システムは、シーンを記述するためのデータストリームとして、BIFS (Binary Format for Scenes)およびオブジェクトディスクリプタ（Object Descriptor、以下「OD」と表記する）と呼ばれる二種類のデータ形式を規定する。前者は、シーンを構成するオブジェクトの配置情報を記述するためのデータで、後者は、BIFSによって記述されたオブジェクトと実際の映像・音声ストリームとの関連付け、および、ストリームの属性情報を記述するためのデータである。これらのデータストリームは、映像・音声ストリームとは独立したストリームとして渡されたのち、再生端末の内部で統合される。
【０００８】
このように、MPEG-4システムは、上記のBIFSおよびODストリームによって、複数のメディア情報を統合して提示するためのメカニズムを提供する。
【０００９】
上述したように、マルチメディアコンテンツの映像・音声ストリームの構成や属性情報はデータストリームに記述される。従って、映像・音声の再生を開始するには、最初にデータストリームを受信し、その内容に基づき映像・音声ストリームを受信し再生する、といった順序の再生制御処理を行う必要がある。
【００１０】
図2はMPEG-4システムの仕組みを用いる再生システムにおけるストリームの典型的な構成および相関を説明する図である。
【００１１】
再生端末には、まず最初に、イニシャルオブジェクトディスクリプタ（Initial Object Descriptor、以下「IOD」と表記する）と呼ばれる初期ストリーム情報を記述するためのデータ構造が渡される。IODには、マルチメディアコンテンツを構成するエレメンタリストリームの属性を記述するためのESディスクリプタ（ES_Descriptor、以下「ESD」と表記する）と呼ばれるデータ構造が格納されていて、ES_IDと呼ばれる一意な識別子を用いてエレメンタリストリームを参照することが可能である。
【００１２】
IODには、典型的には、BIFSおよびODのESDが格納され、再生端末は、このESDの内容に基づき、ストリームの送信元にBIFSおよびODのエレメンタリストリームを要求する。
【００１３】
ODストリームには、典型的には、映像あるいは音声のエレメンタリストリームに対応するESDが格納され、再生端末は、このESDに基づき、ストリーム送信元に対して映像、音声のエレメンタリストリームを要求する。
【００１４】
このようにして要求された映像・音声のエレメンタリストリームに含まれるデータが、既に再生端末に受信されているBIFSおよびODの内容とともに合成されたシーンとして再生される。
【００１５】
このように、上記の再生システムにおいては、映像・音声データに先んじて、ODに相当するストリーム情報の構成データが最初に処理されるように、再生端末へ送付される、あるいは、再生端末が受け取るようにする必要がある。従って、再生端末とデータの送信元のデータ送受信の手順は図3に示すような流れになる。以下、図3を用いて、一般的なMPEG-4システムの仕組みを用いた再生システムの通信手順を順を追って説明する。なお、図3では、通信手段として特定の通信プロトコルを想定していないが、OD、BIFSなどのデータストリームは、受信確認を行うことでデータが確実に伝送されることが保証されるプロトコル、映像・音声ストリームは、受信確認を省略することでリアルタイム性が保たれるプロトコルで伝送されるものとして説明する。また、各通信セッションはそれぞれ異なる通信チャネルを介して行われるものとする。
【００１６】
ステップS1：再生端末は送信元にIODを要求し、送信元はIODを再生端末に送付する。IODを受信した再生端末は、受信が正しく行われたことを示す受信応答を送信元に送付する。
【００１７】
ステップS2：再生端末は、IODを解析して得られたストリーム情報に基づき、送信元にODを要求し、送信元はODを再生端末に送付する。ODを受信した再生端末は、ステップS1と同様に、受信の成功を示す受信応答を送信元に送付する。
【００１８】
ステップS3：再生端末は、ステップS2と同じく、IODを解析して得られたストリーム情報に基づき、送信元に対してBIFSを要求し、送信元はBIFSを再生端末に送付する。BIFSを受信した再生端末は、ステップS1と同様に、受信の成功を示す受信応答を送信元に送付する。
【００１９】
ステップS4：再生端末は、ステップS2で受信したODを解析して得られるストリーム情報に基づき、映像・音声ストリームを送信元に要求し、送信元は要求された映像・音声ストリームを再生端末に送る。映像・音声の場合は、通信のリアルタイム性を維持するために受信応答処理は行わない。
【００２０】
一般的なストリーミングシステムでは、以上のような流れでデータ交換が行われる。しかし、上記のようなデータ交換手順には、次に挙げる二つの潜在的な問題点がある。
【００２１】
第一に、ODデータは、必ずしも再生端末に最初に到着し、処理されることが保証されない。
【００２２】
上記のステップS2およびS3は、ステップS1でIODが解析された後に同時に非同期的に実行することもできる。しかし、その結果、ステップS3のBIFSデータの処理は、ステップS2でODデータを受け取るより前に行われる場合がある。また、ステップS2の処理後、ODを解析してステップS4の映像・音声データの取得が行われるが、ステップS3のBIFSの解析処理とステップS4の処理が非同期的に行われる場合、BIFSの解析が完了する前に映像・音声のエレメンタリストリームが到着することも考えられる。
【００２３】
MPEG-4システムにおいては、BIFSデータおよびそれから参照されるすべての映像・音声のエレメンタリストリームが再生端末に到着し、解析処理が完了した状態になって、はじめてシーンを合成し表示することができる。しかし、エレメンタリストリームの情報はODによって記述されるため、ODが到着していない状態ではエレメンタリストリームを参照することができない。従って、上記の処理が図3と異なる順序で実行された場合、ODより前に到着したストリームデータの正常な処理は保証されず、結果として、コンテンツが視聴できない問題が発生し得る。
【００２４】
第二に、図3に示すような処理手順は、時間的なオーバヘッドが大きいという問題点がある。
【００２５】
第一の問題点として指摘した問題を避けるため、例えば、映像・音声データを受け取る前にODデータが確実に処理されるようにするには、図3においてODデータの受信および解析処理が完了してからステップS4の処理を行う必要がある。しかし、そうすれば再生端末に映像・音声データが受け渡されるには下記の時間が必要になり、最初にODを受信してから下記の時間だけのタイムラグが生じることになる。つまり、体感的には、再生の開始が遅く感じられる結果になる。
タイムラグ = ODの解析が完了するまでの時間
+ 映像・音声ストリーム要求が送信元に到着するまでの時間
+ 映像・音声ストリームが再生端末に到着するまでの時間
【００２６】
上述したように、上記の再生システムは、MPEG-4システムに代表されるデータストリームと映像・音声ストリームからなるマルチメディアコンテンツのデータを処理する際は、特定の順序でストリームを処理するように再生端末を制御しなければ、正しい再生が行われない危惧がある。さらに、その問題を避けるために、ストリームの処理順序を正しく維持する制御を行えば、再生の開始が遅くなる副次的な問題点がある。
【００２７】
【非特許文献１】国際標準規格  ISO/IEC14496-1 "Information technology _ Coding of audio-visual objects _ Part 1: Systems"
【発明の開示】
【発明が解決しようとする課題】
【００２８】
本発明は、上述の問題を個々にまたはまとめて解決するもので、メディアストリームの到着順序に関わらず、確実にマルチメディアコンテンツを再生することを目的とする。
【００２９】
また、マルチメディアコンテンツを再生する際の、再生開始までのタイムラグを短縮することを他の目的とする。
【課題を解決するための手段】
【００３０】
本発明は、前記の目的を達成する一手段として、以下の構成を備える。
【００３１】
メディアストリームを入力し、入力したメディアストリームを保持し、メディアストリームをデータ処理する際に、保持したメディアストリームから参照される参照先のメディアストリームが利用可能になるまで、参照元のメディアストリームを保持することを特徴とする。
【発明の効果】
【００３２】
本発明によれば、メディアストリームの到着順序に関わらず、確実にマルチメディアコンテンツを再生することができる。
【００３３】
また、マルチメディアコンテンツを再生する際の、再生開始までのタイムラグを短縮することができる。
【発明を実施するための最良の形態】
【００３４】
まず、実施例のマルチメディアデータ再生装置の動作原理を解説する。
【００３５】
実施例のマルチメディアデータ再生装置は、エレメンタリストリームの蓄積機構を装置内に設けることによって、入力されたエレメンタリストリームを蓄積して、他のエレメンタリストリームが参照することが可能になった時点で蓄積を止め、後続の処理にストリームデータを受け渡すといった制御を行う。このような制御によって、参照するエレメンタリストリームが到着していないことによる、再生時の異常動作を未然に防止する。
【００３６】
加えて、送信側・受信側の何れも、ストリームの処理順序を意識した制御を行う必要がなく、順序を維持するための処理のオーバヘッドが発生することもなく、極めて簡素な制御が実現できる。
【００３７】
図4は実施例のマルチメディアデータ再生装置の構成例を示すブロック図である。なお、図4に示す構成は、上記の動作原理を具現化するために取り得る構成の一例であり、上記の動作原理が実施できれば、各機能ブロックの論理的・物理的な配置および構成はいかなる形態であってもよい。また、各ブロックの機能は、論理的・物理的に統合あるいは分離され、図4で示されるものと異なる構成の機能ブロックとして実施されてもよい。
【００３８】
また、以下では、対象とするデータ形式として、MPEG-4システムをデータストリームに用いるマルチメディアデータを想定して説明するが、MPEG-4システムと同等のデータストリームを用いるマルチメディアデータ形式に対しても同様に適用することが可能である。
【００３９】
図4において、ストリーム入力部1は、図には示さない伝送手段によってマルチメディアデータ再生装置に受け渡されるエレメンタリストリームを入力し、後続の処理ブロックに受け渡す処理を行う。ストリーム入力部1に渡されるエレメンタリストリームは、装置の内部から取得されても、あるいは、外部の装置からネットワークなどの手段を介して入力されてもよい。また、伝送路で交換されるデータストリームが、ISO/IECによって規格化されているMP4ファイル形式やFlexMux多重化形式のように何らかの形で多重化されている場合は、受信ストリームをデマルチプレックスしてエレメンタリストリームを抽出し、ストリーム入力部1に受け渡す、図には示さない、デマルチプレックス部が介在するものとする。
【００４０】
ストリーム蓄積部2は、ストリーム入力部1から渡されるエレメンタリストリームを、後続の処理ブロックから要求されるまで蓄積する。ストリーム蓄積部2は、ストリームの蓄積解除が要求されると、それまでに蓄積したエレメンタリストリームのデータを後続の処理ブロックへ送出する。
【００４１】
ストリーム蓄積部2がデータを蓄積するための手段は、メモリのような一次記憶手段であっても、キャッシュファイルのような二次記憶手段であってもよい。また、エレメンタリストリームを蓄積する必要がない場合、ストリーム蓄積部2として、いわゆる「NULLデバイス」のようにデータを蓄積せずに廃棄するといった記憶手段を用いてもよい。
【００４２】
また、ストリーム蓄積部2は、入力されるストリームの符号化形式などのストリームの属性情報がストリーム入力部1などから予め通知され、その情報によって、蓄積を行うか否かといったデータ蓄積の方針を変えることができる。
【００４３】
ストリーム処理部3は、ストリーム蓄積部2から渡されるエレメンタリストリームの内容を解析して、再生制御に必要な処理を行う。ストリーム処理部3は、従来の再生システムにおける「デコーダ」に相当し、その内部で行われる処理も従来のデコーダと同じである。ただし、ストリーム処理部3は、従来のデコーダと異なり、エレメンタリストリームのデコード処理によって、他のエレメンタリストリームを参照する必要があるか否かを検出し、参照が必要な場合は、後述するストリーム蓄積制御部4に対して参照を行うエレメンタリストリームを一意に識別するストリーム識別子およびストリームの解析処理の進行の度合いを示す処理状況を渡す。そして、ストリーム蓄積制御部4にストリーム識別子および処理状況を渡した後、ストリーム処理部3は、参照するストリームのデータが送出されるまで待機する。
【００４４】
MPEG-4システムを用いる典型的な再生システムでは、ストリーム識別子に、前述したES_IDや、対象のエレメンタリストリームを参照するオブジェクトディスクリプタのID（ObjectDescriptorID、以下「OD_ID」と記述する）などが用いられる。なお、上記の処理状況については後述する。
【００４５】
ストリーム蓄積制御部4は、エレメンタリストリームのデータ蓄積処理を制御するため、ストリーム蓄積部2の動作を管理する。ストリーム蓄積制御部4は、蓄積動作を管理しているエレメンタリストリームをストリーム識別子によって一意に識別することができる。
【００４６】
ストリーム処理部3で処理されているエレメンタリストリームから他のエレメンタリストリームが参照される場合、ストリーム処理部3からストリーム蓄積制御部4へ、参照するストリームの識別子が渡される。加えて、ストリーム処理部3で行われる処理の内容に応じた処理状況もストリーム蓄積制御部4に渡される。
【００４７】
ストリーム蓄積制御部4は、エレメンタリストリームの処理状況に基づいて、渡されたストリーム識別子で識別されるエレメンタリストリームのデータを蓄積しているストリーム蓄積部2に対して、蓄積動作を停止し、蓄積したストリームデータを後続の処理ブロックに対して送出するように要求する。ストリーム蓄積部2からストリームが放出される時点では、後続のストリーム処理部3、および、さらにその後の、図には示さないシーン合成処理、表示処理などを行う再生処理部では、参照されるエレメンタリストリームのデータの受信が完了し、正しく処理できる状態になっていることが保証される。そのため、ストリーム処理部3以後は、エレメンタリストリームが欠損することなく安全な参照が可能になる。
【００４８】
なお、ストリーム処理部3では、蓄積されたストリームが送出されるタイミングでストリームデータの待機処理が解除されることが期待される。この解除トリガとしては、ストリーム蓄積部2から蓄積されたエレメンタリストリームがストリーム処理部3に受け渡されたタイミング、あるいは、ストリーム蓄積部2が蓄積処理を停止したことを示す通知がストリーム処理部3に渡されたタイミングなどが考えられる。何れであっても、ストリーム処理部3は、待機処理が解除され、到着したエレメンタリストリームを参照することで、処理が継続されるものとする。
【００４９】
なお、図4では、構成を簡略化するため、ストリーム入力部1、ストリーム蓄積部2、ストリーム処理部3およびストリーム蓄積制御部4がそれぞれ一つ存在するものとしたが、これら処理ブロックの何れかまたはすべては、複数存在することも可能である。例えば、エレメンタリストリームの一つに付き、上記の処理ブロックをそれぞれ一つずつ割り当てる構成も有り得る。あるいは、OD、BIFS、映像および音声といったデータの種別ごとに上記の処理ブロックを一組ずつ用いる構成も可能である。ただし、実施例では、これら処理ブロックの数および構成については特定しない。
【００５０】
［エレメンタリストリームの処理］
以上説明したマルチメディアデータ再生装置の実施例において、エレメンタリストリームをどのようにして処理するかを、以下に具体的な実施例を挙げて説明する。
【００５１】
MPEG-4システムを用いる再生システムにおいて、ODおよびBIFSストリームがそれぞれ独立した通信チャネルで再生端末に渡される場合を例として、実施例のマルチメディアデータ再生装置の処理を説明する。
【００５２】
図5は実施例において再生端末に送付されるBIFSストリームの内容の一例を示す図で、BIFSには、Sound2DオブジェクトとBitmapオブジェクトから構成される動画・音声を再生するシンプルな2Dのシーンが記述されている。
【００５３】
シーン中のSound2Dオブジェクトには、OD_IDが「10」のオブジェクトディスクリプタに記述されるエレメンタリストリームで運ばれる音声データがマッピングされている。同様に、Bitmapオブジェクトには、OD_IDが「20」のオブジェクトディスクリプタに記述されるエレメンタリストリームで運ばれる動画像データがマッピングされている。
【００５４】
図6は実施例において送付されるODストリームの内容の一例を示す図で、オブジェクトディスクリプタの内容が更新されることを示すコマンドデータである。このデータ中に、更新されるオブジェクトディスクリプタとして、OD_IDに「10」および「20」が割り当てられたオブジェクトディスクリプタのデータが含まれる。各オブジェクトディスクリプタは、それぞれ対応するエレメンタリストリームの属性情報が記述されたESディスクリプタを含んでいる。このオブジェクトディスクリプタの内容は、図5に示すBIFSからOD_IDを介して参照される。従って、参照されるオブジェクトディスクリプタのデータは、BIFSストリームが処理され、参照が行われる前に準備ができていなければならない。
【００５５】
しかし、図3に示したステップS2とS3がそれぞれ独立した処理として非同期的に実行される場合と同じように処理される。すなわち、ステップS2でODストリームが受信され、処理される前に、ステップS3でBIFSストリームが処理される場合が有り得る。そのため、従来のシステムでは再生が正しく行えない可能性があることは前述した。このような問題を防ぐために、実施例のマルチメディアデータ再生装置がデータをどのように処理するかを、以下で説明する。
【００５６】
［ストリームの処理状況］
処理手順を説明する前に、上述したストリームの処理状況について説明する。
【００５７】
図7はストリームの処理状況を保持するためのデータ構造を、C言語の構造体を模した形式で表現した図である。
【００５８】
フラグis_cachedは、ストリームがストリーム蓄積部2によって蓄積されているか否かを示す。フラグis_readyは、該ストリームが他のストリームから参照可能な状態か否かを示す。フラグis_discardableは、該ストリームのデータが映像、音声などのように破棄しても再生に致命的な影響が生じない種類のストリームであるか否かを示す。このis_discardableの値が真‘1’の場合、該ストリームのデータは蓄積せずにすべて破棄することも可能である。
【００５９】
このストリームの処理状況を示すデータは、ストリーム蓄積部2ないしストリーム蓄積制御部4において、ストリームの蓄積処理をコントロールするために内部的に保持・管理される。この処理状況は、ストリームの種類に応じて初期化された後、後続のストリーム処理部3の処理の度合いに応じて更新される。そして、ストリーム蓄積部2では、処理状況が更新されたら、その内容に応じて蓄積されたストリームデータを送出する処理を行う。
【００６０】
引き続き、上述の処理状況がどのように初期化され、更新されるかを、図を用いて順を追って説明する。
【００６１】
［ストリーム処理状況の初期化］
図8はストリーム蓄積部2においてストリームの受信開始時点で実行されるストリーム処理状況の初期化処理を説明するフローチャートである。
【００６２】
ストリームの処理状況の初期値として、is_cached=‘1’、is_ready=‘0’、is_discardable=‘0’をセットする(S81)。これは、到着したストリームは、デフォルトで、ストリーム蓄積部2によって破棄されることなく蓄積されることを意味する。また、到着したストリームは他のストリームからはまだ参照することができないことも意味する。
【００６３】
受信されたストリームの種類がODストリームであるか否かをチェックする(S82)。ストリームの種類は、MPEG-4システムの場合、オブジェクトディスクリプタに含まれるデコーダ構成ディスクリプタ(Decoder Coding Descriptor)のstreamType、および、objectTypeIndicationと呼ばれるフィールドで識別可能である。実施例1のストリーム蓄積部2は、予め再生端末に渡されたイニシャルオブジェクトディスクリプタのstreamTypeおよびobjectTypeIndicationの値によって、ストリームの種類を知ることが可能である。
【００６４】
そして、受信ストリームの種類がODストリームの場合、is_cachedに‘0’をセットする(S83)。これは、ODストリームの場合は、ストリームを蓄積せずにストリーム処理部3へ直接渡す制御を行うためである。
【００６５】
次に、受信ストリームの種類が映像・音声ストリームであるか否かをチェックする(S84)。ストリームの種類は、ステップS82と同様、streamTypeおよびobjectTypeIndicationの値によって判別可能である。そして、受信ストリームの種類が映像・音声ストリームの場合、is_discardableに‘0’をセットする(S85)。これは、映像・音声ストリームの場合は、ストリームを蓄積せずに破棄する制御を可能にすることを意味する。なお、映像・音声ストリームを破棄するか否かは、再生システムのアプリケーション仕様によって異なる。例えば、監視モニタのように、任意の時点から視聴する形態のアプリケーションは、ストリームが破棄されても問題にはならないが、映画のようにストリームの先頭から視聴することが要求されるアプリケーションは、ストリームは破棄されるべきではない。このように、is_discardable=‘1’のときのストリームデータの扱いは、実際にはアプリケーションの仕様によって異なる。
【００６６】
以上の処理によって、StreamState構造体（図7参照）として示されるストリーム処理状況が初期化される。以降の処理において、ストリーム蓄積部2、ストリーム処理部3およびストリーム蓄積制御部4は、この処理状況の値を監視して、状況に応じた処理を行う。
【００６７】
［ストリーム蓄積部2］
図9は、上述のストリームの処理状況に従って、ストリーム蓄積部2がどのような制御処理を行うかを示すフローチャートである。
【００６８】
まず、ストリーム蓄積部2は、ストリームの蓄積処理を解除する要求を受信したか否かをチェックする(S91)。蓄積解除処理は、通常、後続のストリーム処理部3において、ODストリームに含まれるオブジェクトディスクリプタが正しくデコードされた時点で、ストリーム蓄積制御部4を介してストリーム蓄積部2に送られる。なお、ODのデコード処理については後述し、ここではまだODは処理されていないものとして説明を続ける。
【００６９】
ストリームの蓄積解除要求を受信した場合、ストリーム処理状況のis_cachedに‘0’を、is_readyに‘1’をセットし(S92)、ストリーム処理状況のis_cachedの値をチェックする(S93)。そして、is_cachedの値が‘0’の場合、ストリーム処理部3に対してストリームデータを送出する(S94)。この際、蓄積したストリームデータがある場合は、蓄積したすべてのデータをストリーム処理部3に送付する。
【００７０】
本実施例の場合、初期状態では、ストリームの到着順序にかかわらずODストリームのis_cachedの値は‘0’になるため、ODストリームは蓄積されることなくストリーム処理部3に渡される。一方、その他の種類のストリームのis_cachedの値は‘1’であるため、この時点ではストリーム処理部3には渡されない。
【００７１】
また、is_cachedの値が‘1’の場合、ストリーム処理状況のis_discardableの値をチェックし(S95)、is_discardableの値が‘0’の場合、ストリームデータを解除要求を受信するまで蓄積する(S96)。本実施例の場合、BIFSストリームの処理状況は、is_cached=‘1’、is_discardable=‘0’になるからBIFSストリームはストリーム蓄積部2に蓄積される。
【００７２】
ストリーム処理状況のis_discardableの値が‘0’でなければ、ストリームデータを蓄積せずに破棄する(S97)。なお、本実施例では、映像・音声ストリームの処理状況はis_cached=‘1’、is_discardable=‘1’になるため、ステップS97の処理によってストリームデータは破棄される。なお、上述したように、is_discardable=‘1’のときのストリームデータの取り扱いは、アプリケーションの仕様に依存するため、すべての実施例においてストリームデータが破棄されるとは限らない。
【００７３】
以上説明したように、図9のフローチャートに示す処理によって、図5に示すODデータ、および、図6に示すBIFSデータが再生端末にどのような順序で渡されたとしても、常にODストリームが先に処理されることが保証される。
【００７４】
［ODストリームの処理］
引き続き、図9に示す処理によってストリーム蓄積部2を介してストリーム処理部3に渡されたODストリームデータがどのように処理され、それに伴い、ストリームの処理状況がどのように変化するかを説明する。
【００７５】
図10はストリーム処理部3に渡されたODストリームデータの処理手順を示すフローチャートである。
【００７６】
ストリーム処理部3は、入力されるストリームデータから、オブジェクトディスクリプタのデータを抽出し、デコードする(S101)。デコードされたオブジェクトディスクリプタは、一般には、後続の合成・再生処理のために内部形式に変換され、保持される。ただし、ストリーム処理部3でデコード処理が行われた後のデータの取り扱いや処理の詳細については、本明細書で扱うべき内容の範囲を超えるため、説明は省略する。
【００７７】
次に、抽出したオブジェクトディスクリプタのデコードが正しく行われたか否かを確認し(S102)、デコードが正常に行われた場合は、そのオブジェクトディスクリプタによって示されるストリームの蓄積解除要求を、そのストリームの識別子とともに、ストリーム蓄積制御部4に送付する(S103)。
【００７８】
本実施例では、ODストリームデータの内容は図5に示すとおり、OD_ID=10の音声ストリーム、およびOD_ID=20の映像ストリームである。すなわち、ステップS103で、図5のODデータの処理が行われた結果、OD_ID=10およびOD_ID=20に対応するストリームの蓄積解除要求がストリーム蓄積制御部4に送られる。ストリーム蓄積制御部4は、蓄積解除要求をストリーム蓄積部2に通知し、その結果、図9のフローチャートに示す処理によって、音声および映像ストリームが、ストリーム蓄積部2からストリーム処理部3へ送出される。
【００７９】
また、オブジェクトディスクリプタのデコード処理が正常に行われなかった場合は、何らかのエラー処理を行う(S104)。エラー処理の詳細は、アプリケーション仕様に依存するが、データストリームのデコードに失敗するケースは致命的に近い状況であるため、再生が不可能であることを通知し、処理を中断するといった処理でも問題ないと考えられる。
【００８０】
このように、図10のフローチャートに示す処理によって、ODストリームから映像・音声ストリームを正しく参照することが可能になる。仮に、図3のステップS2およびS4の処理が同時に非同期的に実行され、映像・音声ストリームがODストリームのデコードおよび内部形式への変換処理が行われる前に再生端末に到着するような現象が起きたとしても、ODストリームの先処理が保証される。そのため、対応するオブジェクトディスクリプタが存在しない映像・音声ストリームを処理するといった、不正な状況が発生することはない。
【００８１】
［OD以外のデータストリームの処理］
最後に、BIFSなどのデータストリームから、オブジェクトディスクリプタ、および、それによって記述されるストリームのデータが参照される場合、ストリーム処理部3に渡されたストリームデータがどのように処理されるかを説明する。
【００８２】
図11はストリーム処理部3に渡されたBIFSストリームデータの処理手順を示すフローチャートである。
【００８３】
ストリーム処理部3は、BIFSストリームデータに記述された参照先ストリームの属性を含むODストリームの処理状況をストリーム蓄積制御部2に問い合わせ、ODストリームのis_readyの値をチェックする(S111)。
【００８４】
本実施例では、BIFSデータから参照されるストリームは、図5に示すようにOD_ID=10の音声ストリームおよびOD_ID=20の映像ストリームである。これらのストリームの属性を含むODストリームのis_readyの値は、初期状態では‘0’であるが、ODストリームのデコード処理が完了した時点で、図9のフローチャートに示す処理によって、ストリーム蓄積部2に処理の完了が通知され、図8のフローチャートに示す処理によってis_readyが‘1’に更新される。
【００８５】
ストリーム処理部3は、参照先ストリームの属性を含むODストリームのis_readyの値が‘1’になるまで待機する(S112)。この待機処理は、ODストリームが処理が完了した時点で、is_readyの値が‘1’に更新されることで解除され、後続の処理に進むことができる。
【００８６】
ストリーム処理部3は、再生端末の内部で管理されているODストリームのデコード済みデータを参照する(S113)。デコードされたODストリームのデータは、ステップS101で説明したように、内部形式で保持されているため、どこからどのように参照するかについては本明細書では記述しない。ただ、いかなる実施例であっても、デコードされたオブジェクトディスクリプタは、この時点で正常に参照することが可能になっていることが保証される。
【００８７】
このように、図11のフローチャートに示す処理によって、BIFSなどのデータストリームからODストリームを正しく参照することや、さらに、ODに記述された他のストリームを正しく参照することが可能になる。これによって、図3のステップS2、S3およびS4のすべての処理が非同期的に実行されたとしても、対応するオブジェクトディスクリプタが存在しないストリームを処理する状況が発生することはなくなる。
【００８８】
また、以上述べたような処理が実行されることによって、図3に示される一連の処理を順番どおりに逐次行わずとも、正しいストリーム処理が行えるようになる。そのため、ストリームの送出側でデータの受信応答を待たずともストリームデータを送付することが可能になり、データ送受信のための会話処理にかかるオーバヘッドを削減することができる。その結果、再生開始までの体感的な時間を短縮することが可能になる。
【００８９】
［他の実施例］
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【００９０】
また、本発明の目的は、前述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはCPUやMPU）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)などが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。
【００９１】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。
【００９２】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。
【図面の簡単な説明】
【００９３】
【図１】MPEG-4システムにおける映像・音声データをシーンとして表現するためのメカニズムを説明する図、
【図２】MPEG-4システムの仕組みを用いる再生システムにおけるストリームの典型的な構成および相関を説明する図、
【図３】再生端末とデータの送信元のデータ送受信の手順を示す図、
【図４】実施例のマルチメディアデータ再生装置の構成例を示すブロック図、
【図５】再生端末に送付されるBIFSストリームの内容の一例を示す図、
【図６】送付されるODストリームの内容の一例を示す図、
【図７】ストリームの処理状況を保持するためのデータ構造を、C言語の構造体を模した形式で表現した図、
【図８】ストリームの受信開始時点で実行されるストリーム処理状況の初期化処理を説明するフローチャート、
【図９】ストリーム蓄積部が行う制御処理を示すフローチャート、
【図１０】ODストリームデータの処理手順を示すフローチャート、
【図１１】BIFSストリームデータの処理手順を示すフローチャートである。
【図１】
2005184695.tif 000003
【図２】
2005184695.tif 000004
【図３】
2005184695.tif 000005
【図４】
2005184695.tif 000006
【図５】
2005184695.tif 000007
【図６】
2005184695.tif 000008
【図７】
2005184695.tif 000009
【図８】
2005184695.tif 000010
【図９】
2005184695.tif 000011
【図１０】
2005184695.tif 000012
【図１１】
2005184695.tif 000013