JP4635801B2 - 情報処理装置及び情報処理方法 - Google Patents

Description

本発明は、例えば、ストリーミング再生機能を有する携帯電話機等に好適な情報処理装置及び情報処理装置に関し、特に、再生不可のストリームの不要な受信の防止を図った情報処理装置及び情報処理方法に関する。

ネットワークを介した音声データ及び／又は画像データ（以下、これらをまとめてコンテンツデータともいう。）の伝送には、ダウンロード型伝送方式とストリーム型伝送方式（以下、ストリーミング（Streaming）ともいう。）とがある。ダウンロード型伝送方式では、配信サーバから送信されたコンテンツデータファイルは、クライアント端末（デバイス）側で一旦コピーされ、その後、コンテンツデータファイルの映像等のコンテンツデータが再生されることとなる。このため、このダウンロード型伝送方式では、ファイルの転送が完了するまでは、端末側ではデータの再生を行うことができず、映像データ等を長時間再生するには不向きである。

一方、ストリーミングは、クライアント端末がデジタル信号の連続した流れを受信しながらリアルタイムに順次再生するもので、ストリームサーバからクライアント端末への伝送が行われている間にも、クライアント端末側で受信したデータの再生が行われる。このストリーミングは、ＩＥＴＦ（Internet Engineering Task Force）のＲＦＣ１８８９において規定されているＲＴＰ（Real-Time Transport Protocol：リアルタイム伝送プロトコル）と呼ばれるプロトコルを使用するものが主流となっている。

通常、ＲＴＰによるストリーミングでは、継続的な再生が可能なように、再生開始前に一定時間分のデータをバッファに蓄積し、その後再生を開始する。しかし、コンテンツを再生する側の機器において、音声／画像符号化方式自体は対応していても、音声データにおけるサンプリング周波数や、画像データにおけるフレーム間隔値などのパラメータ値が対応しているか否かは不明である。そこで、実際再生してヘッダ情報から判別する必要があり、非対応だった場合には再生開始直後にパラメータエラーにより再生不可となる。

例えば、特許文献１には、入力されたストリームに対し、エラーチェッカによりフォーマット違反やシンタクス違反などのエラーを検出し、ストリームと共にエラー情報を記録しておく記録装置が開示されている。このエラー情報のエラーレベルに応じて、再生時には、エラー処理部が出力を遮断したり、ヘッダ修正をしたりなどのエラーレベルに応じた処理を行うことができる。また、この特許文献１には、エラーを検出した場合には、所定のエラー処理を施してから再生する、又は出力を遮断する再生装置が開示されている。
特開２００１−１６９２５１号公報

しかしながら、上述したように、ＲＴＰによるストリーミングでは、継続的な再生が可能なように、再生開始前に一定時間分のデータをバッファに蓄積し、その後再生を開始する。したがって、特許文献１に記載の技術のように、実際に再生してから再生不可を検出すると、バッファに蓄積したデータが無駄になってしまい、例えば携帯電話機などにおいてはその分、不要のパケットを受信することとなり、当該パケット受信の料金が無駄になってしまう。特に、携帯電話網の場合、ＡＤＳＬなどの高速回線網と比べ回線速度が遅いため、バッファへの蓄積時間もより多くかかり、再生可能か否かの検出までに時間がかかってしまうという問題点がある。

本発明は、このような問題点を解決するためになされたものであり、再生不可の不要なデータの受信を最小限にすることができる情報処理装置及び情報処理方法を提供することを目的とする。

上述した目的を達成するために、本発明にかかる情報処理装置は、符号化されたコンテンツストリームを受信する受信部と、前記ストリームを復号する復号部と、前記復号部の復号結果に基づき前記コンテンツストリームの受信拒否を制御する制御部とを有し、前記復号部は、機器で再生可能か否かを判断するための最小限データを復号した結果に基づき前記ストリームの再生可否を判定し、前記制御部は、前記受信部に先ず前記最小限データのみを受信させ、前記復号部が再生可であると判定した場合に前記ストリームの受信を再開させるものであって、前記最小限データは、前記コンテンツストリームのヘッダ情報である。

本発明においては、ストリームの受信に先立ち、ストリームのうち最小限データのみを先ず受信し、これを復号して機器で再生可能か否かを判断し、再生可能と判断された場合にのみストリームを受信することで、受信しても再生不可であるような無駄なデータは最小限データ以外受信することがない。

また、前記復号部は、復号した前記最小限データに含まれるコンテンツのヘッダ情報に基づき前記再生可否を判定することができ、ヘッダ情報に基づき再生の可否を判断することができる。

この場合、前記復号部は、前記ストリームのパラメータ値が機器に対応しているか否かにより前記再生可否を判定することができる。

例えば、前記コンテンツはオーディオデータであって、前記パラメータ値はサンプリング周波数を含むものとしたり、前記コンテンツはビデオデータであって、前記パラメータ値はフレーム間隔を含むものとすることができる。

また、前記最小限データは、少なくとも１フレームデータを有するものとすることができ、最小限データとしては、１フレームデータを復号することで再生可否を判断することが可能である。

更に、前記ストリームをストリーミング再生する際に前記ストリームをバッファリングするバッファを有し、前記最小限データは、前記ストリーミング再生する際に前記バッファにバッファリングされるデータ未満とすることができ、最小限データにより再生可否を判断するため、通常であればストリーミング開始によりバッファリングされてしまう最小限データ以上の無駄になる可能性があるデータを再生可否を判断するまで受信することがない。

更にまた、前記制御部は、前記復号部が再生可能と判定した場合には、前記受信部に前記最小限データ以降のストリームの受信を開始させることができ、再生可否の判定に利用した最小限データは再度受信することなく通常再生に利用することができる。

また、前記制御部は、前記復号部が再生可能と判定した場合には、前記受信部に前記ストリームの先頭から受信を開始させることができ、最小限データを破棄し、通常通りストリームの先頭から受信を開始することで、処理を簡単化することができる。

更に、前記制御部は、前記受信部に機器に対応したフォーマット形式のストリームを受信させることができ、フォーマット形式が異なる場合等は最小限データを受信する前に受信を拒否することができる。

更にまた、前記復号部にて復号した復号データを再生出力する出力部を有し、前記制御部は、前記復号部が再生不可と判定した場合には、前記再生出力部にその旨を出力させることができ、ユーザに再生不可を通知することができる。

また、ＲＴＰによるストリーミング再生機能を有する携帯電話機に適用することができる。携帯電話機のように、パケット代が課金されるような機器においては、最小限データでストリームの再生可否を判定して無駄な受信による受信料の支払いを回避することができる。

本発明にかかる情報処理方法は、符号化されたコンテンツストリームの受信を開始する前に、当該コンテンツストリームの少なくともヘッダ情報を含む１フレームデータを有する最小限データのみを受信し、前記最小限データを復号した結果に基づき前記ストリームの再生可否を判定し、再生可であると判定した場合に、前記コンテンツストリームの受信を開始するものである。

本発明によれば、最小限データにより機器で再生できるか否かを確認し、再生可能であることを確認してから全コンテンツを受信するので、再生不可能のコンテンツを受信してしまうことがない。

本発明によれば、短時間かつ小さいデータで再生可否を判断することで不要なストリームの受信を行なわないようにすることができる情報処理装置及び情報処理装置を提供することができる。

以下、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。この実施の形態は、本発明を、ＲＴＰによるストリーミング再生機能を有する携帯電話機に適用したものである。なお、本実施の形態においては、情報処理装置の一例として携帯電話機を例にとって説明するが、パーソナルコンピュータ、携帯機器などストリーム受信が可能な機器に適用可能である。

図１は、本発明の実施の形態にかかる情報システム１０を示す模式図である。図１に示すように、情報システム１０は、コンテンツを提供するコンテンツサーバ１と携帯電話機２とからなる。

コンテンツサーバ１は、ＲＴＰストリーミング用のコンテンツを蓄積しており、ＲＴＳＰ（Real-Time Streaming Protocol：リアルタイム・ストリーム制御プロトコル、ＲＦＣ２３２６にて規定）／ＲＴＰプロトコルを使用して、ストリーミング用コンテンツを利用者である携帯電話機２へ配信する。

データ送受信部３は、無線を経由してコンテンツストリーム（ＲＴＰデータ）の送受信を行う機能を有する。ＲＴＰバッファ４は、コンテンツサーバ１から受信したＲＴＰデータを蓄積する機能を有する。このＲＴＰバッファ４に所定量のＲＴＰデータを蓄積してから、データの復号・再生が開始される。

ＲＴＰ／ＲＴＳＰ解析部５は、コンテンツサーバ１とＲＴＳＰパケット送受信を行い解析する機能と、ＲＴＰバッファ４から受信したＲＴＰパケットを解析して、符号化されたフレームデータに変換し、復号部６へ送信する機能とを有する。

復号部６は、受信したデータを復号して出力部７へ送信する。また、本実施の形態における復号部は、少なくとも１フレームを含む最小限データとしての初期蓄積データのパラメータチェックを行い、再生可能か否かの判定も行う。

出力部７は、復号部６から受信した動画・音声データを出力する機能を有する。また、復号部６での再生不可と判定された場合にその旨のメッセージを出力する機能も有する。たとえば、表示画面を有する場合には、表示画面に、エラー等、再生不可の旨を通知する文字を出力する。又は音声にて通知するようにしてもよい。

ここで、本実施の形態にかかる携帯電話機２は、ＲＴＰによるストリーミング再生機能を具備し、ストリーミングを復号して解析することで再生可否を早期検出するものである。このため、本携帯電話機２は、受信したい（再生したい）コンテンツがある場合、コンテンツのストリーム受信に先立って先ず解析に必要な最小限データのみを受信し、この受信した最小限データのヘッダ情報にあるパラメータ値を解析し、携帯電話機が非対応のパラメータの場合には、即座に受信を停止し不要なＲＴＰパケットを受信しない機能を有する。図２は、この機能を説明するための図である。

図２に示すように、携帯電話機２からコンテンツサーバ１に対して、コンテンツＣのストリーミング開始要求を行うと、まず、コンテンツサーバ１からのＲＴＰによるパケット送信により、順次ＲＴＰバッファ４に初期蓄積データが蓄積されていく。ここで、通常は一定時間分のデータＤ２を初期蓄積データとして蓄積することで、受信しながら再生するストリーミング再生を実行することができる。これに対し、本実施の形態においては、一定時間分のデータＤ２未満の、パラメータチェックを行える最小限のデータ量Ｄ１だけの蓄積を行う。

次に、初期蓄積したデータＤ１を復号部６へ送信し、パラメータチェックを行う。パラメータチェックの結果、復号部６での再生に対応しているパラメータであった場合には、通常通り、初期蓄積データ量Ｄ２までＲＴＰバッファ４にデータを蓄積し、ストリーミングを開始する。一方、パラメータチェックの結果、復号部６での再生に非対応のパラメータだった場合には、携帯電話機２で再生できないため、ストリーミングを停止する。この場合は、通常の初期蓄積データ量Ｄ２までのデータ蓄積も行わない。

すなわち、予め必要最小限のデータ（最小限データ）のみを受信し、再生可否のチェックし、受信するか否かを決定するため、パラメータ値が非対応のコンテンツであって再生不可の場合には、最小限データの受信のみとし、通常初期蓄積データＤ２として蓄積してしまうデータをも受信することなく、パケット代の無駄な消費を省き、再生可否の検出までの時間を短縮することができる。

図３は、本実施の形態における、コンテンツのデータ量と再生時間との関係を示したものである。全データ量Ｃに相当、つまりコンテンツの全再生に相当する時間をｔ３とする。また、通常の初期蓄積データ量に相当する再生時間をｔ２、本実施の形態における初期蓄積データ量、つまりパラメータチェックに必要な最小限データ量に相当する時間をｔ１とする。

通常のストリーミング再生を行なう場合には、再生時間ｔ２分までのストリームを予めバッファリングしてから、受信しながら復号・再生することとなり、再生不可が検出されるのは、ｔ２までのストリームを受信してからとなってしまう。これに対し、本実施の形態においては、ｔ１までの最小限データを解析して再生可否を判定するため、ｔ３−ｔ２分のパケットを受信する必要がなくなり、不要なパケットの受信を防止することができる。

図４、図５は、本実施の形態における情報処理方法を示すフローチャートである。すなわち、図４、図５は、ストリーム受信前に予め最小限データのみの受信を行い、再生可否を判定してからストリーム受信の許否を決定する方法を示す。

携帯電話機２からＲＴＰ用ストリーミングコンテンツへアクセスする際には、先ず、ＲＴＰ／ＲＴＳＰ解析部５からコンテンツサーバ１に対して、ＲＴＳＰによる接続情報の要求（ＤＥＳＣＲＩＢＥ）メッセージを発行し、ビデオやオーディオデータ（コンテンツ）の受信に必要な情報を要求する。携帯電話機２はコンテンツサーバ１からＯＫ応答を受信すると共にＳＤＰ（セッション記述プロトコル）を受け取る。次に、セッション（接続）確立要求（ＳＥＴＵＰメッセージ）を送信すると、これに対し、コンテンツサーバ１からＯＫ応答を受信することでセッションが確立する（ステップＳ１）。こうして、コンテンツ再生に関する情報交換ならびに再生準備を実施する。

次にＰＬＡＹメッセージによる再生開始要求（データ取得要求）を、ＲＴＰ／ＲＴＳＰ解析部５からコンテンツサーバ１に対して送信する（ステップＳ２）。その際、再生区間を"Range"パラメータで指定する。ここで、通常であれば、コンテンツの全データ量（Ｃ）に相当する"ｎｐｔ＝０−ｔ３"（図３参照）を指定するところを、本実施の形態においては、パラメータチェックに必要な最小限データであるデータ量（Ｄ１）だけを取得するために"ｎｐｔ＝０−ｔ１"を指定する（ステップＳ３）。そして、コンテンツサーバ１からＯＫ応答を受信したら（ステップＳ４）、コンテンツサーバ１からＲＴＰによるデータ送信が始まる。こうして、ＲＴＰバッファ４にデータＤ１が蓄積されるまでＲＴＰパケットが送信される（ステップＳ５）。なお、上述したように、ステップＳ３においてRange：ｎｐｔ＝０−ｔ１"のパラメータ指定があるため、コンテンツサーバ１から送信されるデータは、パラメータチェックに必要なデータ量Ｄ１のみとなる。

ＲＴＰバッファ４にパラメータチェックに必要なデータ量Ｄ１が蓄積されたら、ＲＴＰバッファ４から蓄積データＤ１をＲＴＰ／ＲＴＳＰ解析部５へ送信する。ＲＴＰ／ＲＴＳＰ解析部５では、このデータをフレームデータに変換し、パラメータチェック用として復号部６へ送信する（ステップＳ６）。この際、このフレームデータはＲＴＰ／ＲＴＳＰ解析部５にもそのまま保存しておく。フレームデータを受信した復号部６は、パラメータチェックを行い、コンテンツデータが再生可能化かものかどうかを判定し（ステップＳ７）、その結果をＲＴＰ／ＲＴＳＰ解析部５へ応答する。

復号部６での判定結果が、再生不可だった場合（ステップＳ８：Ｎｏ）、ＲＴＰ／ＲＴＳＰ解析部５では、ステップＳ６で保存していたフレームデータを破棄し（ステップＳ９）、出力部７に「再生不可」の表示をさせる（ステップＳ１０）。そして、ＲＴＰ／ＲＴＳＰ解析部５からコンテンツサーバ１に対して、ストリームの配信の停止を要求するＴＥＡＲＤＯＷＮメッセージの送信し、コンテンツサーバ１からＯＫ応答の受信を行い、ストリーミングを停止する（ステップＳ１１）。

一方、復号部６での判定結果が、「再生可能」だった場合（ステップＳ８：Ｙｅｓ）、図５に示すように、再度、ＲＴＰ／ＲＴＳＰ解析部５からデータ取得要求ＰＬＡＹメッセージをコンテンツサーバ１に対して送信する（ステップＳ１２）。この際、パラメータチェックに必要であったデータＤ１は取得済みのため、"Range"パラメータには、"ｎｐｔ＝ｔ１−ｔ３"を指定する（ステップＳ１３）。そして、コンテンツサーバ１からＯＫ応答を受信し（ステップＳ１４）、コンテンツサーバ１からＲＴＰによるデータ送信が再開される。これにより、時間ｔ１からｔ３分のＲＴＰパケットがコンテンツサーバ１から送信され、ＲＴＰバッファ４にコンテンツが蓄積される。そして、通常の初期蓄積データ量Ｄ２に相当する時刻ｔ２までのデータがＲＴＰバッファ４に蓄積されたら、携帯電話機２は、再生を開始する（ステップＳ１６）。再生開始時、パラメータチェック用のデータ量（時間０〜ｔ１）は、上述のステップＳ６においてＲＴＰ／ＲＴＳＰ解析部５に保存されているため、先ずこれを復号部６へ送信し再生する（ステップＳ１７）と共に、ＲＴＰバッファ４の残りのデータをＲＴＰ／ＲＴＳＰ解析部５に送りフレームデータ化し復号部６へ供給する。

この後は順次コンテンツサーバ１からコンテンツＣの全てのＲＴＰパケットが順次送信される（ステップＳ１８）ため、ＲＴＰパケットをＲＴＰバッファ４へ蓄積する動作と、ＲＴＰ／ＲＴＳＰ解析部５で順次フレームデータ化し復号部６へ送信し再生する動作を並行的に実施して、通常のストリーミング再生を実施する（ステップＳ１９）。

本発明により、携帯電話機においてパラメータ値が非対応のコンテンツであっても、必要最小限のデータのみでチェックすることが可能となるため、パケット代の無駄な消費を省き、検出までの時間を短縮することができる。

なお、本発明は上述した実施の形態のみに限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。例えば、本実施の形態においては、ステップＳ６でパラメータチェック用のデータ量を保存しているので、ステップＳ１３でのパラメータ指定において、パラメータチェック用のデータ量を再受信しないように指定しているが、ステップＳ６でのデータＤ２の保存を実施せずに、ステップＳ１３において"Range：ｎｐｔ＝０−ｔ３"と指定してコンテンツの先頭からデータを受信することも可能である。このことにより、通常のストリーミングと同等の処理とすることができ、処理を簡潔化することができる。

また、上述の実施の形態における各ブロックが実行する任意の処理を、ＣＰＵ（Central Processing Unit）にコンピュータプログラムを実行させることにより実現することも可能である。この場合、コンピュータプログラムは、記録媒体に記録して提供することも可能であり、また、インターネットその他の伝送媒体を介して伝送することにより提供することも可能である。

本発明の実施の形態にかかる携帯電話機を含む情報システムを示す模式図である。 本発明の実施の形態にかかる携帯電話機が非対応のパラメータの場合には、受信を停止し不要なＲＴＰパケットを受信しない機能を説明するための図である。 本発明の実施の形態における、コンテンツのデータ量と再生時間との関係を示したものである。 本発明の実施の形態における情報処理方法を示す図であってストリーム受信前に最小限データにより再生可否を判定してからストリーム受信の許否を決定する方法を示すフローチャートである。 同じく、本発明の実施の形態における情報処理方法を示す図である。

符号の説明

１ コンテンツサーバ
２ 携帯電話機
３ データ送受信部
４ ＲＴＰバッファ
５ ＲＴＰ／ＲＴＳＰ解析部
６ 復号部
７ 出力部
１０ 情報システム

Claims (14)

1. 符号化されたコンテンツストリームを受信する受信部と、
   前記ストリームを復号する復号部と、
   前記復号部の復号結果に基づき前記コンテンツストリームの受信拒否を制御する制御部とを有し、
   前記復号部は、機器で再生可能か否かを判断するための最小限データを復号した結果に基づき前記ストリームの再生可否を判定し、
   前記制御部は、前記受信部に先ず前記最小限データのみを受信させ、前記復号部が再生可であると判定した場合に前記ストリームの受信を再開させるものであって、
   前記最小限データは、前記コンテンツストリームのヘッダ情報である情報処理装置。
2. 前記復号部は、復号した前記最小限データに含まれるコンテンツのヘッダ情報を解析し、前記ヘッダ情報に含まれる符号化パラメータに基づき前記再生可否を判定する
   ことを特徴とする請求項１記載の情報処理装置。
3. 前記復号部は、前記ストリームのパラメータ値が機器に対応しているか否かにより前記再生可否を判定する
   ことを特徴とする請求項２記載の情報処理装置。
4. 前記コンテンツはオーディオデータであって、前記パラメータ値はサンプリング周波数を含む
   ことを特徴とする請求項３項記載の情報処理装置。
5. 前記コンテンツはビデオデータであって、前記パラメータ値はフレーム間隔を含む
   ことを特徴とする請求項３項記載の情報処理装置。
6. 前記最小限データは、少なくとも１フレームデータを有する
   ことを特徴とする請求項１乃至５のいずれか１項記載の情報処理装置。
7. 前記ストリームをストリーミング再生する際に前記ストリームをバッファリングするバッファを有し、
   前記最小限データは、前記ストリーミング再生する際に前記バッファにバッファリングされるデータ未満である
   ことを特徴とする請求項１乃至６のいずれか１項記載の情報処理装置。
8. 前記制御部は、前記復号部が再生可能と判定した場合には、前記受信部に前記最小限データ以降のストリームの受信を開始させる
   ことを特徴とする請求項１乃至７のいずれか１項記載の情報処理装置。
9. 前記制御部は、前記復号部が再生可能と判定した場合には、前記受信部に前記ストリームの先頭から受信を開始させる
   ことを特徴とする請求項１乃至７のいずれか１項記載の情報処理装置。
10. 前記制御部は、前記受信部に機器に対応したフォーマット形式のストリームを受信させる
    ことを特徴とする請求項１乃至９のいずれか１項記載の情報処理装置。
11. 前記復号部にて復号した復号データを再生出力する出力部を有し、
    前記制御部は、前記復号部が再生不可と判定した場合には、前記再生出力部にその旨を出力させる
    ことを特徴とする請求項１乃至１０のいずれか１項記載の情報処理装置。
12. ＲＴＰによるストリーミング再生機能を有する携帯電話機である
    ことを特徴とする請求項１乃至１１のいずれか１項記載の情報処理装置。
13. 符号化されたコンテンツストリームの受信を開始する前に、当該コンテンツストリームの少なくともヘッダ情報を含む１フレームデータを有する最小限データのみを受信し、
    前記最小限データを復号した結果に基づき前記ストリームの再生可否を判定し、
    再生可であると判定した場合に、前記コンテンツストリームの受信を開始する情報処理方法。
14. 前記再生可否を判定する際には、復号された前記最小限データのヘッダ情報を解析し、前記ヘッダ情報に含まれる符号化パラメータに基づき再生可否を判定する
    ことを特徴とする請求項１３記載の情報処理方法。

Images