(57)【要約】【課題】  メディアデータを符号化して得られたパケットデータを受信し、該メディアデータを再生する再生装置において、当該再生処理の高速化を図る。【解決手段】  メディアデータを符号化して得られたパケットデータを受信し、該メディアデータを再生する再生装置であって、受信した前記パケットデータをリアルタイムに復号する複数の復号手段（１０４〜１０６）と、受信した前記パケットデータを所定のアプリケーションを用いて処理する処理手段（１１０、１１１）と、前記復号結果と、前記処理結果とに基づいて、前記メディアデータを再生する手段（１１４）と、前記パケットデータを解析することで、ポート番号とプロトコルとを取得し、前記パケットデータを、前記復号手段（１０４〜１０６）に送信するか、前記処理手段（１１０、１１１）に送信するかを決定する手段（１０３）とを備える。【選択図】  図１
2006343864.tif 000002
【特許請求の範囲】
【請求項１】
メディアデータを符号化しパケット単位に分割することで得られた複数のデータを受信し、該メディアデータを再生する再生装置であって、
受信した前記データをバッファリングし、所定のタイミングで該バッファリングしたデータを復号する複数の復号手段と、
受信した前記データを所定のアプリケーションを用いてソフトウェア処理する処理手段と、
前記復号手段により復号されたデータと、前記処理手段に処理されたデータとを用いて、前記メディアデータを再生する再生手段と、
受信した前記データに含まれる、前記復号手段に対応するポート番号とプロトコルに関する情報とを解析し、該データを、前記復号手段に送信するか、前記処理手段に送信するか決定する決定手段と
を備えることを特徴とする再生装置。
【請求項２】
前記決定手段は、受信した前記データに含まれるポート番号が予め設定された設定値と一致し、かつ、該データのプロトコルがＵＤＰ／ＲＴＰであった場合に、該データを前記復号手段に送信することを特徴とする請求項１に記載の再生装置。
【請求項３】
前記データの送信元との間で通信接続を確立する際に、前記復号手段に対応するポート番号を前記設定値として設定する設定手段を更に備えることを特徴とする請求項２に記載の再生装置。
【請求項４】
メディアデータを符号化しパケット単位に分割することで得られた複数のデータを受信し、該メディアデータを再生する再生装置であって、
受信した前記データをバッファリングし、所定のタイミングで該バッファリングしたデータを復号する複数の復号手段と、
受信した前記データを所定のアプリケーションを用いてソフトウェア処理する処理手段と、
前記復号手段により復号されたデータと、前記処理手段に処理されたデータとを用いて、前記メディアデータを再生する再生手段と、
受信した前記データに含まれるリアルタイムプロトコルの拡張ヘッダの有無を判断し、該判断結果に基づいて、受信した前記データを、前記復号手段に送信するか、前記処理手段に送信するかを決定する決定手段と
を備えることを特徴とする再生装置。
【請求項５】
受信した前記データにリアルタイムプロトコルの拡張ヘッドが含まれていた場合に、前記決定手段は、該データを前記復号手段に送信することを特徴とする請求項４に記載の再生装置。
【請求項６】
メディアデータを符号化しパケット単位に分割することで得られた複数のデータを受信し、該メディアデータを再生する再生装置であって、
受信した前記データをバッファリングし、所定のタイミングで該バッファリングしたデータを復号する複数の復号手段と、
受信した前記データを所定のアプリケーションを用いてソフトウェア処理する処理手段と、
前記復号手段により復号されたデータと、前記処理手段に処理されたデータとを用いて、前記メディアデータを再生する再生手段と、
受信した前記データの拡張ヘッダに前記復号手段を識別する識別子が含まれているか否かを判断する判断手段と、
前記判断手段における判断結果に基づいて、受信した前記データを、前記復号手段に送信するか、前記処理手段に送信するかを決定する決定手段と
を備えることを特徴とする再生装置。
【請求項７】
前記判断手段における判断の結果、前記データに前記識別子が含まれていた場合に、前記決定手段は、該データを前記復号手段に送信することを特徴とする請求項６に記載の再生装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受信したデータを処理し再生する再生装置に関するものである。
【背景技術】
【０００２】
近年、光ファイバー、ＡＤＳＬ等のブロードバンド環境が普及するにつれ、動画像、音声等の種々のメディアデータを、ストリーム系の伝送方式（ストリーミングを実現するための伝送方式。なお、ストリーミングとは、インターネット上で音声や動画像などのメディアデータを受信しながらリアルタイムに再生する技術をいう）を用いて伝送するサービスが増加してきている。例えば、インターネット電話、ビデオ会議、映像配信などはその典型的な例である。
【０００３】
一般に、ストリーム系の伝送方式においては、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）のＲＦＣ（Ｒｅｑｕｅｓｔ  ＦｏｒＣｏｍｍｅｎｔｓ）１８８９、１８９０で規定されているＲＴＰ（Ｒｅａｌ−ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ)、ＲＴＣＰ(ＲＴＰ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）等のプロトコルが用いられる。
【０００４】
図７は、上記のようなメディアデータの伝送（メディア伝送）をするためのプロトコルレイヤを示す図である。図７において、ＲＴＰ、ＲＴＣＰは、動画像、音声等のメディアデータを実際に伝送するとともに、同期、パケット廃棄、フロー制御等の課題の解決を目的としているプロトコルである。
【０００５】
また、ＲＴＳＰ（Ｒｅａｌ  Ｔｉｍｅ  Ｓｔｒｅｅｍｉｎｇ  Ｐｒｏｔｏｃｏｌ）、ＳＡＰ（Ｓｅｓｓｉｏｎ  Ａｎｎｏｕｎｃｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ)、ＳＩＰ(Ｓｅｓｓｉｏｎ  Ｉｎｉｔｉａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）は、セッション情報の伝達を目的とし、ＳＤＰ(Ｓｅｓｓｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）は、セッション情報を伝達する際の具体的なセッション記述フォーマットを決めているプロトコルである。
【０００６】
また、ＩＰ(Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ)マルチキャストを使用するＳＡＰ以外は、トランスポート層のプロトコルとして、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）またはＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）が用いられる。さらにレイアウト記述について、通常のＷｅｂコンテンツと同様に、ＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ)で転送される。
【０００７】
図８は、図７で説明したプロトコルレイヤを実装する従来の表示装置の構成を示すブロック図である。
【０００８】
８０１は、マイクロプロセッサ等のＣＰＵであり、後述のＲＯＭ／ＲＡＭ８０２に格納された制御プログラムに従って、各種データ信号や制御信号を出力することにより表示装置全体の制御を行う。８０２はＲＯＭ／ＲＡＭであり、制御プログラムデータ等を格納する。また、ＣＰＵ８０１のワークエリアとして使用され、種々の制御データが一時保存される。８０３は表示部であり、受信したメディアデータ等の対象を表示する。８０４は通信部であり、有線ＬＡＮ或いは無線ＬＡＮなどの通信を行う。また、８０５は、操作のためのスイッチ等の入力部であり、８０６はシステムバスである。
【０００９】
かかる構成のもと、物理層及びデータリンク層は、通信部８０４に実装され、ネットワーク層（ＩＰ）以上の上位プロトコルのすべての処理は、ＣＰＵ８０１が処理することとなる。
【００１０】
そして、従来より、このようなプロトコルを実装した装置において、受信したパケットを振り分ける処理について種々の提案がなされている（例えば、特許文献１参照）。
【特許文献１】特開２０００−２５０４６５号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、従来の装置において、上位プロトコルのすべての処理をＣＰＵ８０１に任せることとすると、種々の課題が発生することになる。
【００１２】
通常、通信部８０４からＩＰパケットを受け取ったＣＰＵ８０１では、まずＩＰヘッダの処理を行い、その上位レイヤであるＴＣＰ或いはＵＤＰの処理を行う。更に、その後、その上位であるＲＴＳＰ或いはＨＴＴＰ或いはＲＴＰ等の処理を行い、アプリケーションに実際のメディアデータや制御データを渡す。つまり、各パケットに対してシーケンシャルに処理が行われる。このため、ＣＰＵ８０１の処理負荷があがり、表示装置全体の処理の遅延は免れない。
【００１３】
また、上位プロトコルの処理に際しては、各レイヤのヘッダ処理をＣＰＵ８０１が行うため、ＣＰＵ８０１に対する負荷はますます増大する。この結果、アプリケーション等の他の処理を行うような場合にあっては、アプリケーション等のＧＵＩ処理で、応答速度が遅延するなどの影響がでてしまう。
【００１４】
本発明は、上記課題に鑑みてなされたものであり、メディアデータを符号化しパケット単位に分割することで得られた複数のデータを受信し、該メディアデータを再生する再生装置において、当該再生処理の高速化を図るとともに、該再生装置のＣＰＵの処理負荷を低減することを目的とする。
【課題を解決するための手段】
【００１５】
上記の目的を達成するために本発明に係る表示装置は以下のような構成を備える。即ち、
メディアデータを符号化しパケット単位に分割することで得られた複数のデータを受信し、該メディアデータを再生する再生装置であって、
受信した前記データをバッファリングし、所定のタイミングで該バッファリングしたデータを復号する複数の復号手段と、
受信した前記データを所定のアプリケーションを用いてソフトウェア処理する処理手段と、
前記復号手段により復号されたデータと、前記処理手段に処理されたデータとを用いて、前記メディアデータを再生する再生手段と、
受信した前記データに含まれる、前記復号手段に対応するポート番号とプロトコルに関する情報とを解析し、該データを、前記復号手段に送信するか、前記処理手段に送信するか決定する決定手段とを備える。
【発明の効果】
【００１６】
本発明によれば、メディアデータを符号化しパケット単位に分割することで得られた複数のデータを受信し、該メディアデータを再生する再生装置において、当該再生処理の高速化が実現できるとともに、該再生装置のＣＰＵの処理負荷を低減することが可能となる。
【発明を実施するための最良の形態】
【００１７】
以下、必要に応じて添付図面を参照しながら本発明の各実施形態を詳細に説明する。
【００１８】
［第１の実施形態］
＜表示装置の全体構成（図１）＞
図１は、本発明の第１の実施形態にかかる表示装置（１００）のブロック構成を示す図である。同図を用いて、表示装置（ディスプレイ端末）の構成を説明する。
【００１９】
同図に示すように、表示装置１００は、通信モジュール１０１、１次ＲＸバッファ１０２、通信振分け部１０３、ストリーム振分け部１０４、負荷配分部１０５、デコーダ部１０６、１０７、１０８、１０９、２次ＲＸバッファ１１０、アプリケーションＣＰＵ１１１、デコード能力モニタ１１２、フレームバッファ１１３、表示部１１４を備える。
【００２０】
通信モジュール１０１は、無線ＬＡＮ、或いは、有線ＬＡＮ或いは公衆回線用の通信モジュールであり、送信側の端末との接続、ネゴシエーション、送信されたパケットの受信を行う。
【００２１】
１次ＲＸバッファ１０２は、通信モジュール１０１で受信したパケットを一時蓄積するためのものである。通信振分け部１０３は、受信したパケットの各レイヤのヘッダの内容を判断し、パケットの処理を行うために、当該パケットを後述のストリーム振分け部１０４に渡したり、アプリケーションＣＰＵ１１１にソフトウェア処理させるために、２次ＲＸバッファ１１０に渡したりする。
【００２２】
ストリーム振分け部１０４は、受信したパケットのペイロード部分の中身を判断することにより、動画像、音声等、メディアの異なるパケットごとに分割して、負荷配分部１０５に渡す。負荷配分部１０５は、複数のデコーダ部１０６〜１０９の処理状況を監視し、ストリーム振分け部１０４から受信したパケットを、対応するデコーダ部１０６〜１０９に渡す。デコーダ部１０６〜１０９では、受信したパケットをデコード（復号）して、表示可能な形式に変換し、表示のためのメモリであるフレームバッファ１１３に書き込む。
【００２３】
２次ＲＸバッファ１１０では、通信振分け部１０３から受け取ったＴＣＰ／ＩＰパケットを一時蓄積する。アプリケーションＣＰＵ１１１では、表示装置１００全体の制御を司り、かつ、上位レイヤのプロトコルを処理する。
【００２４】
デコード能力モニタ１１２は、複数のデコーダ部１０６〜１０９の処理状況を監視し、この状況をアプリケーションＣＰＵ１１１に伝えるとともに、アプリケーションＣＰＵ１１１からの指示を負荷配分部１０５に伝える。
【００２５】
フレームバッファ１１３は、表示のためのメモリであり、デコーダ部１０６〜１０９からのデータと、アプリケーションＣＰＵ１１１からのデータとを重ね合わせて、表示部１１４に表示する。表示部１１４は、フレームバッファ１１３に書き込まれたデータに基づいて表示動作するディスプレイ等の表示部である。
【００２６】
＜表示装置１００における処理の流れ＞
図２は、本発明の第１の実施形態にかかる表示装置（１００）における処理の流れを示すフローチャートである。なお、当該フローチャートは、表示装置１００のパケット受信処理に関するものである。
【００２７】
ステップＳ２０１では、通信モジュール１０１が送信側端末からのセッション開始要求を待つ。セッション開始要求が受信されると、ステップＳ２０２では、デコード能力モニタ１１２に、現在のデコーダ部１０６〜１０９の処理状況を問い合わせ、デコーダ部１０６〜１０９のうち、どのデコーダ部を使用するかを決定する。例えば、動画像のデコードに関しては、デコーダ部１０６を使用するものとし、音声のデコードに関しては、デコーダ部１０７を使用するといったように割り当てる。さらに、セッションを識別するセッションＩＤとデコーダ部の指定を、デコード能力モニタ１１２を経由して、負荷配分部１０５に通知する。
【００２８】
次に、ステップＳ２０３では、ＲＴＰ及びＲＴＣＰに対応するＩＰのポート番号を設定する。通常、ポート番号は、使用するプロトコルに従って予約されているが、本実施形態においては、セッション毎にＲＴＰ及びＲＴＣＰに対して、新たにポート番号を設定するものとする。
【００２９】
具体的には、予約されていない１０２４以上のポート番号を指定する。その際、ＲＴＰとＲＴＣＰとはペアとして、ＲＴＰには偶数を、ＲＴＣＰにはＲＴＰに指定した番号プラス１の奇数の番号を設定する。
【００３０】
ステップＳ２０４では、設定したポート番号を、通信モジュール１０１を経由して、送信側の端末にセッション開始の確認コマンドとして送信する。以上のネゴシエーションにより、送信側端末からは実際のストリーミングデータが載ったパケットとして当該ポート番号が設定されたパケットが送信されることになる。
【００３１】
ステップＳ２０５では、通信モジュール１０１が送信側端末からのパケット（メディアデータを符号化し、パケット単位に分割することで得られた複数のデータ）の送信を待つ。通信モジュール１０１にて、パケットが受信されると、ステップＳ２０６では、通信振分け部１０３が当該受信したパケットのヘッダの解析を行い、ポート番号を確認する。ポート番号が、ステップＳ２０３で設定したものと同じであり、かつプロトコルがＵＤＰ／ＲＴＰであった場合には、ステップＳ２１０に進む。
【００３２】
一方、ステップＳ２０６において、ポート番号が通常予約されているものであり、プロトコルが、ＴＣＰ／ＩＰであったと判断された場合には、ステップＳ２０７に進む。通信振分け部１０３で、ＴＣＰ／ＩＰのパケットであると判断された場合、パケットは、２次ＲＸバッファ１１０に転送され、ステップＳ２０７において、トランスポート層以上のプロトコルの処理が行われ、アプリケーションＣＰＵ１１１がソフトウェア処理できるデータが生成される。
【００３３】
アプリケーションＣＰＵ１１１は、当該データをソフトウェア処理して、ステップＳ２０８にて、表示するためのデータをフレームバッファ１１３に書き込み、表示部１１４に表示する。その後、ステップＳ２０９で、セッションを終了させるコマンドを受信していないか否かを確認し、セッションを終了させるコマンドを受信していない場合には、ステップＳ２０５に戻る。ステップＳ２０５では、通信モジュール１０３が新たなパケットの受信を待つ。一方、セッションを終了させるコマンドを受信していた場合には、ステップＳ２１３に進み、通信モジュール１０１を介して、送信側端末にセッション終了確認のコマンドを送信し処理を終了する。
【００３４】
一方、ステップＳ２０６において、ポート番号があらかじめ（ステップＳ２０３で）設定されたものと一致し、プロトコルがＵＤＰ／ＲＴＰであったと判断された場合には、ステップＳ２１０に進む。ステップＳ２１０では、通信振分け部１０３でストリーミングデータを含むパケットをストリーム振分け部３０４に渡し、ストリーム振分け部３０４ではパケットのペイロード部分の解析を行って分割する。この分割されたパケットは負荷配分部１０５に渡され、あらかじめ、アプリケーションＣＰＵ１１１から指定された設定に従って、デコーダ部１０６〜１０９に渡される。
【００３５】
ステップＳ２１１では、当該パケットを、動画像、音声等のメディアの形式に従ってデコードする。次に、ステップＳ２１２では、デコードされたパケットをフレームバッファ１１３に書き込み、表示部１１４に表示する。これらの処理が終了すると、ステップＳ２０９に進んで、セッション終了のための処理を進めるか否かを判断する。ステップＳ２０９においてセッション終了のための処理を行わないと判断した場合には、ステップＳ２０５に戻り、次のパケット受信処理を進める。
【００３６】
以上の説明から明らかなように、本実施形態によれば、標準のＩＰの範囲内で、受信したパケットをデータ系とストリーム系とに振り分け、処理を分散させることにより、適切な負荷配分を行い高速な通信で受信した高画質の大容量のメディアデータを処理することが可能となる。
【００３７】
［第２の実施形態］
上記第１の実施形態では、標準のＩＰの範囲内で、受信したパケットをデータ系とストリーム系とに振り分けることとしたが、本発明は特にこれに限られない。ＲＴＰの拡張ヘッダを利用し、当該拡張ヘッダに基づいて、受信したパケットをデータ系とストリーム系とに振り分けるようにしてもよい。以下に詳細を説明する。
【００３８】
＜表示装置１００における処理の流れ＞
図３は、本発明の第２の実施形態にかかる表示装置（１００）における処理の流れを示すフローチャートである。当該フローチャートは、表示装置１００のパケット受信処理に関するものである。
【００３９】
ステップＳ３０１では、通信モジュール１０１が送信側端末からのセッション開始要求を待つ。セッション開始要求が受信されると、ステップＳ３０２では、デコード能力モニタ１１２に、現在のデコーダ部１０６〜１０９の処理状況を問い合わせ、デコーダ部１０６〜１０９のうち、どのデコーダ部を使用するかを決定する。そして、セッションを識別するセッションＩＤとデコーダ部の指定を、デコード能力モニタ１１２を経由して、負荷配分部１０５に通知する。
【００４０】
次に、ステップＳ３０３では、ＲＴＰの拡張ヘッダ（Ｈｅａｄｅｒ  ｅｘｔｅｎｓｉｏｎ）を設定する。図５は、ＲＴＰパケットのフォーマットを示す図である。同図においてＸ＝ｅｘｔｅｎｓｉｏｎのビットを１にして、Ｈｅａｄｅｒ  ｅｘｔｅｎｓｉｏｎ（ｏｐｔｉｏｎ）の領域を使用する。例えば、拡張ヘッダの部分に、現在、使用可能なデコーダ部及びデータ形式、或いはアドレス等を設定することができる。
【００４１】
ステップＳ３０４では、当該拡張ヘッダに設定した情報を、通信モジュール１０１を経由して、送信側の端末にセッション開始の確認コマンドとして送信する。以上のネゴシエーションにより、送信側端末から実際のストリーミングデータが載ったパケットが送信される場合には、拡張ヘッダにこれらの情報が記載されることとなる。
【００４２】
ステップＳ３０５では、通信モジュール１０１が送信側端末からのパケットの送信を待つ。通信モジュール１０１にて、パケットが受信されると、ステップＳ３０６では、通信振分け部１０３が当該受信したパケットのヘッダの解析を行い、拡張ヘッダがあるかどうかを確認する。拡張ヘッダがあった場合には、ステップＳ３１０に進む。
【００４３】
一方、ステップＳ３０６での確認の結果、ＲＴＰ以外のプロトコルであった場合、あるいはＲＴＰの拡張ヘッダがなかった場合には、ステップＳ３０７に進む。ＲＴＰ以外のプロトコルであった場合、あるいはＲＴＰの拡張ヘッダがなかった場合、受信したパケットは２次ＲＸバッファ１１０に転送され、ステップＳ３０７において、トランスポート層以上のプロトコルの処理が行われ、アプリケーションＣＰＵ１１１がソフトウェア処理できるデータが生成される。
【００４４】
アプリケーションＣＰＵ１１１は当該データをソフトウェア処理して、ステップＳ３０８にて、表示するためのデータをフレームバッファ１１３に書き込み、表示部１１４に表示する。その後、ステップＳ３０９で、セッションを終了させるコマンドを受信していないか否かを確認し、セッションを終了させるコマンドを受信していない場合には、ステップＳ３０５に戻る。ステップＳ３０５では、通信モジュール１０３が新たなパケットの受信を待つ。一方、セッションを終了させるコマンドを受信していた場合には、ステップＳ３１３に進み、通信モジュール１０１を介して、送信側端末にセッション終了確認のコマンドを送信し処理を終了する。
【００４５】
一方、ステップＳ３０６において拡張ヘッダがあった場合には、ステップＳ３１０に進む。ステップＳ３１０では、通信振分け部１０３で拡張ヘッダを含むパケットをストリーム振分け部１０４に渡し、ストリーム振分け部１０４では当該パケットのペイロード部分の解析を行って分割する。この分割されたパケットは負荷配分部１０５に渡され、あらかじめ、アプリケーションＣＰＵ１１１から指定された設定に従って、デコーダ部１０６〜１０９に渡される。
【００４６】
ステップＳ３１１では、当該パケットを、動画像、音声等のメディアデータの形式に従ってデコードする。次に、ステップＳ３１２では、デコードされたパケットをフレームバッファ１１３に書き込み、表示部１１４に表示する。これらの処理が終了すると、ステップＳ３０９に進んで、セッション終了のための処理を進めるか否かを判断する。ステップＳ３０９においてセッション終了のための処理を行わないと判断した場合には、ステップＳ３０５に戻り、次のパケット受信処理を進める。
【００４７】
以上の説明から明らかなように、本実施形態によれば、標準のＲＴＰの範囲内で、受信したパケットをデータ系とストリーム系とに振り分け、処理を分散させることにより、適切な負荷配分を行い高速な通信で受信した高画質の大容量のメディアデータを処理することが可能となる。
【００４８】
［第３の実施形態］
上記第２の実施形態では、ＲＴＰ拡張ヘッダの有無により、受信したパケットをデータ系とストリーム系とに振り分けることとしたが、本発明は特にこれに限られず、ＲＴＰ拡張ヘッダ内にデコーダ識別子が記載されているか否かにより、データ系とストリーム系とに振り分けるようにしてもよい。以下に詳細を説明する。
【００４９】
＜表示装置１００における処理の流れ＞
図４は、本発明の第３の実施形態にかかる表示装置１００における処理の流れを示すフローチャートである。本実施形態においては、受信側のリソースであるデコーダ部を識別するための識別子によって受信したパケットの振り分けを行う。当該フローチャートは、表示装置１００のパケット受信処理に関するものである。
【００５０】
ステップＳ４０１では、通信モジュール１０１が送信側端末からのセッション開始要求を待つ。セッション開始要求が受信されると、ステップＳ４０２では、デコード能力モニタ１１２に、現在のデコーダ部１０６〜１０９の処理状況を問い合わせ、デコーダ部１０６〜１０９のうち、どのデコーダ部を使用するかを決定する。そして、セッションを識別するセッションＩＤとデコーダ部の指定を、デコード能力モニタ１１２を経由して、負荷配分部１０５に通知する。
【００５１】
ステップＳ４０３では、使用可能なデコーダ部の識別子を設定し、ステップＳ４０４では、これらの情報を、通信モジュール１０１を経由して、送信側の端末にセッション開始の確認コマンドとして送信する。以上のネゴシエーションにより、送信側端末からは実際のストリーミングデータが載ったパケットとして、ＲＴＰの拡張ヘッダの部分に当該デコーダ識別子が設定されたパケットが送信されることになる。
【００５２】
ステップＳ４０５では、通信モジュール１０１が送信側端末からパケットの送信を待つ。通信モジュール１０１にて、パケットが受信されると、ステップＳ４０６では、通信振り分け部１０３が当該受信したパケットのヘッダの解析を行い、ＲＴＰの拡張ヘッダ内にデコーダ識別子があるかどうかを確認する。デコーダ識別子があった場合には、ステップＳ４１０に進む。
【００５３】
一方、ステップＳ４０６での確認の結果、ＲＴＰ以外のプロトコルであった場合、あるいはＲＴＰの拡張ヘッダ内にデコーダ識別子がなかった場合には、ステップＳ４０７に進む。ＲＴＰ以外のプロトコルであった場合、あるいはＲＴＰの拡張ヘッダ内にデコーダ識別子がなかったと判断された場合、受信したパケットは、２次ＲＸバッファ１１０に転送され、ステップＳ４０７において、トランスポート層以上のプロトコルの処理が行われ、アプリケーションＣＰＵ１１１がソフトウェア処理できるデータが生成される。
【００５４】
アプリケーションＣＰＵ１１１は当該データをソフトウェア処理して、ステップＳ４０８にて、表示するためのデータをフレームバッファ１１３に書き込み、表示部１１４に表示する。その後、ステップＳ４０９で、セッションを終了させるコマンドを受信していないか否かを確認し、セッションを終了させるコマンドを受信していない場合には、ステップＳ４０５に戻る。ステップＳ４０５では、通信モジュール１０３が新たなパケットの受信を待つ。一方、セッションを終了させるコマンドを受信していた場合には、ステップＳ４１３に進み、通信モジュール１０１を介して、送信側端末にセッション終了確認のコマンドを送信し、処理を終了する。
【００５５】
一方、ステップＳ４０６において、拡張ヘッダ内にデコーダ識別子があった場合には、ステップＳ４１０に進む。ステップＳ４１０では、通信振分け部１０３で拡張ヘッダを含むパケットをストリーム振分け部１０４に渡し、ストリーム振分け部１０４では当該パケットのペイロード部分の解析を行って分割する。この分割されたパケットは、負荷配分部１０５に渡され、あらかじめ、アプリケーションＣＰＵ１１１から指定されたデコーダ識別子の設定に従って、デコーダ部１０６〜１０９に渡される。
【００５６】
ステップＳ４１１では、当該パケットを、動画像、音声等のメディアデータの形式に従ってデコードする。次に、ステップＳ４１２では、デコードされたパケットをフレームバッファ１１３に書き込み、表示部１１４に表示する。これらの処理が終了すると、ステップＳ４０９に進んで、セッション終了のための処理を進めるか否かを判断する。ステップＳ４０９においてセッション終了のための処理を行わないと判断した場合には、ステップＳ４０５に戻り、次のパケット受信処理を進める。
【００５７】
以上の説明から明らかなように、本実施形態によれば、標準のＲＴＰの範囲内で、受信したパケットをデータ系とストリーム系とに振り分け、処理を分散させることにより、適切な負荷配分を行い高速な通信で受信した高画質の大容量のメディアデータを処理することが可能となる。
【００５８】
[第４の実施形態]
上記第１乃至第３の実施形態では、ストリーム振分け部１０４におけるパケットの分割手順について特に詳説しなかったが、パケットを分割することにより、処理の高速化を実現できる。以下に詳細を説明する。
【００５９】
図６は、本発明の第４の実施形態にかかる表示装置１００の処理の概要を説明するための図である（図１と対応する部分については同じ参照番号を付している）。
【００６０】
上述したように、表示装置１００において受信したパケットは、通信振分け部１０３において、ストリーム系のパケット（ＩＰ／ＵＤＰ／ＲＴＰ）と、データ系のパケット（ＩＰ／ＴＣＰ）とに振り分けられる。このうちＲＴＰパケットは、ストリーム振分け部６０２に渡され、ＴＣＰ／ＩＰパケットは、アプリケーションＣＰＵ６０６に渡されて、それぞれ処理される。
【００６１】
ストリーム振分け部１０４では、ＲＴＰパケット内のストリーミングデータの詳細を解析し、デコーダ部１０６または１０７に渡すためにメディア毎に分解される。例えば、ＭＰＥＧ２−ＴＳ（トランスポートストリーム）の場合、各メディアデータには、ＴＳヘッダが添付されているので、当該ＴＳヘッダを解析してＲＴＰパケットのペイロード内のメディアデータを分割する。
【００６２】
負荷配分部６０３では、ＲＴＰパケットのペイロードから抽出されたメディアデータ（例えば、ｖｉｄｅｏ（１）、ｖｉｄｅｏ（２））を結合して、対応するデコーダ部１０６に渡してデコードを行い、結果を表示する。これらの処理は、動画（ｖｉｄｅｏ）音声（Ａｕｄｉｏ）といった各メディアデータ毎に処理される。
【００６３】
また、ＴＣＰ／ＩＰパケットは、アプリケーションＣＰＵ１１１によって、トランスポート層（ＴＣＰ）より上位のプロトコルの処理が行われ、アプリケーションＣＰＵ１１１が扱うデータが取り出され、そのデータに応じた処理が行われる。
【００６４】
このように本実施形態によれば、ストリーム振分け部１０４に渡されたＲＴＰパケットを更にメディアデータごとに分割して処理することで（つまり、処理をパイプライン的に分散することで）、遅延を少なくすることが可能となる。
【００６５】
［第５の実施形態］
上記各実施形態においては、通信モジュール１０１にて受信したパケットを、通信振分け部１０３にて振り分け、ストリーミングデータの処理を行う構成としたが、通信振分け部１０３やストリーム振分け部１０４等における処理を、通信モジュール１０１内に実装するようにしてもよい。
【００６６】
また、上記各実施形態においては、データ系はＴＣＰ／ＩＰベースの通信プロトコルを使用し、ストリーム系はＲＴＰ／ＲＴＣＰベースの通信プロトコルを使用したが、特にこれに限定されるものではなく、他のデータ系及びストリーム系のプロトコルを使用しても、実現可能である。
【００６７】
さらに、上記各実施形態では、ストリーミングデータの表示を目的とした表示装置の構成をとったが、蓄積等の他の装置においても、実装可能である。
【００６８】
［他の実施形態］
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。
【００６９】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、達成されることは言うまでもない。
【００７０】
この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。
【００７１】
プログラムコードを供給するための記憶媒体としては、例えば、フロッピ（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどを用いることができる。
【００７２】
また、コンピュータが読出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【００７３】
さらに、記憶媒体から読出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【図面の簡単な説明】
【００７４】
【図１】本発明の第１の実施形態にかかる表示装置のブロック構成を示す図である。
【図２】本発明の第１の実施形態にかかる表示装置における処理の流れを示すフローチャートである。
【図３】本発明の第２の実施形態にかかる表示装置における処理の流れを示すフローチャートである。
【図４】本発明の第３の実施形態にかかる表示装置における処理の流れを示すフローチャートである。
【図５】ＲＴＰパケットのフォーマットを示す図である。
【図６】本発明の第４の実施形態にかかる表示装置の処理の概要を説明するための図である。
【図７】従来のメディア伝送を実現するプロトコルレイヤの図である。
【図８】従来のプロトコルレイヤを実装する装置の構成を示すブロック図である。
【符号の説明】
【００７５】
１０１          通信モジュール
１０２          １次ＲＸバッファ
１０３          通信振分け部
１０４          ストリーム振分け部
１０５          負荷配分部
１０６〜１０９  デコーダ部
１１０          ２次ＲＸバッファ
１１１          アプリケーションＣＰＵ
１１２          デコード能力モニタ
１１３          フレームバッファ
１１４          表示部
【図１】
2006343864.tif 000003
【図２】
2006343864.tif 000004
【図３】
2006343864.tif 000005
【図４】
2006343864.tif 000006
【図５】
2006343864.tif 000007
【図６】
2006343864.tif 000008
【図７】
2006343864.tif 000009
【図８】
2006343864.tif 000010