ストリーム受信再生装置及びストリーミングネットワークシステム
【課題】ストリームデータの送信側が送信するストリームのレートの制御をすることが不可能であるシステムにおいても、ストリームデータ受信用バッファのアンダーフローの発生頻度を低下させること。
【解決手段】ネットワーク１０３を介して配信されたストリームデータおよび制御データを受信する端末通信部１１０と、受信したストリームデータを一時的に蓄積するバッファ１１１と、蓄積されたストリームデータをデコードするデコーダ１１２と、端末制御部１１３を具備する。端末制御部１１３は、端末通信部１１０からストリームデータに関する制御情報を受信し、受信した制御情報によりストリームデータの状態が一時停止可能であり、かつ、ストリームデータの蓄積量の増加必要性が有ると判定した場合に、デコーダ１１２を制御してストリームデータのデコードを一時停止し、バッファ１１１に蓄積されるストリームデータのデータ量を増加させる。
【解決手段】ネットワーク１０３を介して配信されたストリームデータおよび制御データを受信する端末通信部１１０と、受信したストリームデータを一時的に蓄積するバッファ１１１と、蓄積されたストリームデータをデコードするデコーダ１１２と、端末制御部１１３を具備する。端末制御部１１３は、端末通信部１１０からストリームデータに関する制御情報を受信し、受信した制御情報によりストリームデータの状態が一時停止可能であり、かつ、ストリームデータの蓄積量の増加必要性が有ると判定した場合に、デコーダ１１２を制御してストリームデータのデコードを一時停止し、バッファ１１１に蓄積されるストリームデータのデータ量を増加させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、音声や動画などのデータをネットワーク経由で受信しながら再生するストリーミング技術を用いるストリーム受信再生装置及びストリーミングネットワークシステムに関する。
【背景技術】
【０００２】
ストリーミング技術は、音声や動画などのリアルタイム性が要求されるデータを、ネットワークを介して配送し、配送しながら再生を行う技術である。
【０００３】
ストリーミング技術を用いたストリーム受信再生装置は、全データをダウンロードすることなく再生できるので、
（１）受信側に大容量の記憶装置などが不要となる。
【０００４】
（２）全データをダウンロードして再生する方式に比べ、データの配送開始から再生開始までの所要時間を短縮してデータ再生の高速化を図れる。
という特徴がある。
【０００５】
しかしながら、ストリーミング技術を用いたストリーム受信再生装置においては、ネットワーク上での通信エラー発生や、無線ネットワーク経由でデータを配信する場合の電波状況の悪化などが原因となって、ストリームデータの受信バッファのアンダーフローが発生するという課題がある。
【０００６】
このようなストリームデータの受信バッファのアンダーフローが発生すると聴感上の雑音発生などの問題が生じる。
【０００７】
この問題を解決する技術として、例えば特許文献１に示す「伝送システム」がある。図５は、特許文献１記載の伝送システムの構成を示すブロック図である。
【０００８】
図５において、サーバ３０は、ネットワーク１０を介してクライアント端末２０と接続されている。
【０００９】
サーバ３０には、画像と音声を多重化した多重化レートの異なる複数の多重化ファイル（ストリームデータ）が格納されている。
【００１０】
サーバ３０から送られた多重化データは、まずクライアント端末２０の入力バッファ２１でバッファリングされ多重分離部２２に渡される。
【００１１】
多重分離部２２は、データストリームを画像データと音声データとに分離し、画像復号部２３及び音声復号部２４にデータを送る。
【００１２】
画像復号部２３は、画像データを復号し、画像バッファ２５に復号データを送る。
【００１３】
音声復号部２４は、音声データを復号し、音声バッファ２６に復号データを送る。
【００１４】
画像バッファ２５と音声バッファ２６は、画像復号部２３と音声復号部２４の復号時間差を吸収し、画像と音声の同期をとる役割を担う。
【００１５】
同期がとられた画像データと音声データは、ディスプレイ２７とスピーカ２８からそれぞれ画像、音声として出力される。
【００１６】
レート計算部２９は、例えばサーバ３０からネットワーク１０を経由して入力バッファ２１へ送られてくる単位時間内のデータ量を常にカウントし、実質の伝送レートを計算し、その伝送レート情報をサーバ３０に通知する。このような通知は、例えば所定の時間ごとに行う。
【００１７】
サーバ３０は、画像と音声を多重化した符号化レートが異なる多重化ファイル（ストリームデータ）３１〜３３と、クライアント端末２０側から送られてくる伝送レート情報によってファイルを切り替える多重化ファイル切換スイッチ３４と、を備える。
【００１８】
多重化ファイル３１〜３３は、符号化レートが異なる同一のコンテンツ、すなわち符号化レートが異なる同一データを蓄積する。符号化レートは、例えば６０ｋｂｐｓ、４５ｋｂｐｓ、３０ｋｂｐｓのように設定する。
【００１９】
この伝送システムにおいてストリ一ミング再生を開始すると、サーバ３０は、クライアント端末２０に対して動画像の伝送を始める。
【００２０】
クライアント端末２０は、入力バッファ２１で多重化データのバッファリングを開始しながら、レート計算部２９において実質伝送レート（ｂｐｓ）の計算を開始する。この実質伝送レートは、サーバ３０の負荷が上がったり、ネットワーク１０が混雑したりすると低下の方向に向かう。この伝送レート情報は、例えば一定の時間間隔でサーバ３０に通知される。
【００２１】
サーバ３０は、一定の時間間隔でクライアント端末２０から通知される伝送レート情報に基づき、多重化ファイル切換スイッチ３４で通知されたレートに近いかそれ以下になる多重化ファイル３１〜３３を選択し、切り替える。
【００２２】
このように、特許文献１の「伝送システム」では、ネットワーク１０が混雑したり、サーバ３０の負荷が増大したりすることによってクライアント端末２０での実質の受信レートが変動した場合、一定周期でクライアント端末２０からサーバ３０に送られている伝送レート情報に基づいて、その伝送レート以下の最も近いファイルに切り替える。
【００２３】
これにより、この「伝送システム」では、クライアント端末２０側で実質伝送レートが変動した場合でも、ストリーミング再生において途切れ途切れになることがなくシームレスな再生を行うことができ、動画像の見にくさが解消される。
【特許文献１】特開平１１−２０５３９０号公報
【発明の開示】
【発明が解決しようとする課題】
【００２４】
しかしながら、前記従来の構成では、ストリームデータの送信側（サーバ）が符号化レートの異なる多重化ファイル（ストリームデータ）を送信可能なシステムにしか適用することができないという課題を有していた。
【００２５】
また、前記従来の構成では、ストリームデータの受信側（クライアント端末）が、ストリームデータの実質の受信レートであるレート情報をストリームデータの送信側（サーバ）に通知し、ストリームデータの送信側（サーバ）が前記レート情報を元にストリーム配信のレートの制御をすることが可能であるシステムにしか適用することができないという課題も有していた。
【００２６】
本発明は、かかる点に鑑みてなされたもので、ストリームデータの送信側が符号化レートの異なるストリームデータを送信不可能なシステムや、ストリームデータの受信側の通知したレート情報を元にストリームデータの送信側がストリーム配信のレートの制御をすることが不可能であるシステムにおいても、ストリームデータ受信用バッファのアンダーフローの発生頻度を低下させることができるストリーム受信再生装置及びストリーミングネットワークシステムを提供することを目的とする。
【課題を解決するための手段】
【００２７】
かかる課題を解決するため、本発明のストリーム受信再生装置は、配信されたストリームデータおよび制御データを受信する通信手段と、前記通信手段により受信した前記ストリームデータを一時的に蓄積する蓄積手段と、前記蓄積手段により蓄積された前記ストリームデータをデコードするデコード手段と、前記通信手段が受信した前記ストリームデータに関する制御情報により、前記ストリームデータの状態が一時停止可能であり、かつ前記ストリームデータの蓄積量の増加必要性が有ると判定した場合に、前記デコード手段を制御して前記ストリームデータのデコードを一時停止し、前記蓄積手段に蓄積される前記ストリームデータのデータ量を増加させる制御手段と、を具備する構成を採る。
【発明の効果】
【００２８】
本発明のストリーム受信再生装置及びストリーミングネットワークシステムによれば、ストリームデータの送信側が符号化レートの異なるストリームデータを送信不可能なシステムや、ストリームデータの受信側の通知したレート情報を元にストリームデータの送信側がストリーム配信のレートの制御をすることが不可能であるシステムにおいても、ストリームデータ受信用バッファのアンダーフローの発生頻度を低下させることができる。
【発明を実施するための最良の形態】
【００２９】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００３０】
図１は、本発明の一実施の形態に係るストリーミングネットワークシステムの構成を示す図である。
【００３１】
図１に示すように、本例のストリーミングネットワークシステム１００は、ストリーム受信再生装置（クライアント）１０１と、サーバ１０２と、ネットワーク１０３から構成される。なお、図１において、ネットワーク１０３は、本例では無線ネットワークを例示しているが、これに限らず、有線ネットワークでも良い。
【００３２】
ストリーム受信再生装置１０１は、端末通信部１１０と、バッファ１１１と、デコーダ１１２と、端末制御部１１３と、を備えている。
【００３３】
サーバ１０２は、サーバ制御部１２０と、ストリームデータ送出部１２１と、サーバ通信部１２２と、ストリームデータ蓄積部１２３と、を備えている。
【００３４】
まず、クライアントであるストリーム受信再生装置１０１の構成について説明する。
【００３５】
図１において、端末通信部１１０は、ネットワーク１０３を介してストリームデータを受信し、受信したストリームデータをバッファ１１１へ出力する。
【００３６】
クライアント側の蓄積手段としてのバッファ１１１は、端末通信部１１０から入力したストリームデータを一時的に蓄積する。そして、バッファ１１１は、蓄積したストリームデータをデコーダ１１２へ出力する。
【００３７】
デコーダ１１２は、バッファ１１１から入力したストリームデータをデコードしてスピーカ１１４へ出力する。
【００３８】
端末制御部１１３は、端末通信部１１０から受信したストリームデータに関する制御情報と、バッファ１１１の状態とに基づいて、デコーダ１１２を制御する。具体的には、端末制御部１１３は、ストリームデータの状態が一時停止可能であり、ストリームデータの蓄積量の増加必要性があると判定した場合には、デコーダ１１２を制御してストリームデータのデコードを一時停止し、バッファ１１１に蓄積されるストリームデータのデータ量を増加させるように制御する。
【００３９】
スピーカ１１４は、デコーダ１１２から入力したストリームデータが表す音楽等を外部へ出力する。
【００４０】
次に、サーバ１０２の構成について説明する。
【００４１】
ストリームデータ蓄積部１２３は、配信するストリームデータ及びストリームデータに関する制御情報、例えば、曲名、アルバム名、アーティスト名、曲の長さなどの時間情報、といった曲情報を蓄積し、ストリームデータをストリームデータ送出部１２１に出力する。
【００４２】
ストリームデータ送出部１２１は、サーバ制御部１２０の制御に基づいて、ストリームデータをサーバ通信部１２２へ出力する。
【００４３】
サーバ制御部１２０は、ストリームデータ送出部１２１を制御する。また、サーバ制御部１２０は、ストリームデータ蓄積部１２３から制御情報を読み出し、読み出した制御情報をサーバ通信部１２２へ出力する。
【００４４】
サーバ通信部１２２は、ストリームデータ送出部１２１から入力したストリームデータ、及びサーバ制御部１２０から入力した制御情報を、ネットワーク１０３を介してストリーム受信再生装置１０１へ送信する。
【００４５】
次に、図２を用いて、上述のように構成されたストリーミングネットワークシステム１００の動作について説明する。図２は、本発明の一実施の形態に係るストリーミングネットワークシステムの動作を示すフローチャートである。
【００４６】
通常のストリーミング再生の基本動作では、ストリーム受信再生装置１０１は、ネットワーク１０３を介してストリームデータの受信を開始し、受信開始から一定時間内（例えばＴｉｎｉ）に受信したストリームデータをバッファ１１１に蓄える。
【００４７】
なお、ストリーム受信再生装置１０１は、一定時間内に受信したストリームデータをバッファ１１１に蓄えるように構成されている場合に限らず、一定量のストリームデータをバッファ１１１に蓄えるように構成されていても良い。
【００４８】
端末制御部１１３は、一定時間Ｔｉｎｉが経過するか、またはバッファ１１１に一定量のストリームデータが蓄積されると、ストリームデータのデコードの開始をデコーダ１１２に対して指示する。
【００４９】
デコーダ１１２は、端末制御部１１３からの指示に応答して、バッファ１１１に蓄積されたストリームデータのデコードを開始し、デコード済みのストリームデータをスピーカ１１４に与える。
【００５０】
このようにして、ストリーム受信再生装置１０１では、ストリームデータが再生され、受信したストリームデータが表す音楽がスピーカ１１４から鳴り始める。
【００５１】
以降のストリームデータ再生中の状態においては、ストリームデータを受信（ステップＳＴ２０１）し、受信したストリームデータをバッファ１１１に蓄積する（ステップＳＴ２０２）。
【００５２】
端末制御部１１３は、ストリームデータの受信中に、制御情報を受信したか否か判定する（ステップＳＴ２０３）。
【００５３】
そして、ステップＳＴ２０３において、端末制御部１１３が制御情報を受信していないと判定した場合には、ステップＳＴ２０１〜ステップＳＴ２０３の処理を繰返す。
【００５４】
一方、ステップＳＴ２０３において、端末制御部１１３が制御情報を受信したと判定した場合には、ストリームデータの状態が一時停止可能であるか否かを判定する（ステップＳＴ２０４）。
【００５５】
そして、ステップＳＴ２０４において、ストリームデータの状態が一時停止可能で無いと判定した場合には、ステップＳＴ２０１〜ステップＳＴ２０４の処理を繰返す。
【００５６】
一方、ステップＳＴ２０４において、ストリームデータの状態が一時停止可能であると判定した場合には、バッファ１１１に蓄積されたストリームデータのデータ量（以下、これを「残バッファ量」という）に基づき、ストリームデータの蓄積量の増加必要性があるか否かを判定する（ステップＳＴ２０５）。
【００５７】
そして、ステップＳＴ２０５にいて、ストリームデータの蓄積量の増加必要性が無いと判定した場合には、ステップＳＴ２０１〜ステップＳＴ２０５の処理を繰返す。
【００５８】
一方、ステップＳＴ２０５にいて、ストリームデータの蓄積量の増加必要性が有ると判定した場合には、端末制御部１１３はデコーダ１１２を制御してストリームデータのデコードを一時停止する（ステップＳＴ２０６）。
【００５９】
次いで、ストリームデータのデコードを一時停止した状態において、ストリームデータを受信すると（ステップＳＴ２０７）、ストリームデータをバッファ１１１に蓄積（ステップＳＴ２０８）し、再度、ストリームデータの蓄積量の増加必要性があるか否かを判定する（ステップＳＴ２０９）。
【００６０】
そして、ステップＳＴ２０９において、ストリームデータの蓄積量の増加必要性があると判定した場合には、ステップＳＴ２０７〜ステップＳＴ２０９の処理を繰返す。
【００６１】
一方、ステップＳＴ２０９において、ストリームデータの蓄積量の増加必要性が無いと判定した場合には、ストリームデータのデコードを再開し（ステップＳＴ２１０）、ステップＳＴ２０１に戻ってステップＳＴ２０１からステップＳＴ２０９の処理を繰返す。
【００６２】
次に、ステップＳＴ２０４において、ストリームデータの状態が一時停止可能であるか否かを判定する方法について具体例を挙げて説明する。
【００６３】
ここでは、具体例として、ステップＳＴ２０３において端末制御部１１３が受信の有無を判定する制御情報が、曲名、アルバム名、アーティスト名、曲の長さなどの時間情報、曲の区切りを示す曲の区切り情報、曲のトラック番号情報、曲間の状態を示す曲状態情報、といった曲情報を含んでいる場合について説明する。
【００６４】
このように、制御情報が曲情報、例えば曲の区切り情報を含んでいる場合には、ストリームデータが曲の区切りにあるときにストリームデータの状態が一時停止可能であると判定するように端末制御部１１３を構成することで、ストリームデータの状態が一時停止可能であるか否かを判定することが可能となる。
【００６５】
また、制御情報に曲のトラック番号の変化を通知する情報が含まれている場合には、ストリームデータが曲と曲の間の状態にあるときにストリームデータの状態が一時停止可能であると判定するように端末制御部１１３を構成することで、ストリームデータの状態が一時停止可能であるか否かを判定することが可能となる。
【００６６】
同様に、制御情報に曲間の状態を示す情報が含まれていた場合には、ストリームデータが曲と曲の間の状態にあるときにストリームデータの状態が一時停止可能であると判定するように端末制御部１１３を構成することで、ストリームデータの状態が一時停止可能であるか否かを判定することが可能となる。
【００６７】
次に、ステップＳＴ２０５において、ストリームデータの蓄積量の増加必要性があるか否かを判定する方法について具体例を挙げて説明する。
【００６８】
ストリームデータの蓄積量の増加必要性の有無の判定方法としては、例えば、ある一定の閾値（例えばＢｔｈ＿Ｐａｕｓｅ）を設けておき、残バッファ量が閾値Ｂｔｈ＿Ｐａｕｓｅ以下であれば、ストリームデータの蓄積量の増加必要性があると判定すれば良い。
【００６９】
また、他の判定方法としては、残バッファ量を定期的に観測し、残バッファ量が減少傾向にあるならば、ストリームデータの蓄積量の増加必要性があると判定しても良い。
【００７０】
なお、ステップＳＴ２０９におけるストリームデータの蓄積量の増加必要性があるか否かを判定する方法については、ステップＳＴ２０５と同じ判定基準による判定方法を用いても良いし、あるいは異なった判定方法を用いても良い。
【００７１】
ステップＳＴ２０５と異なった判定方法としては、例えば、ステップＳＴ２０９において判定に用いる閾値をＢｔｈ＿Ｒｅｓｔａｒｔとし、残バッファ量がＢｔｈ＿Ｒｅｓｔａｒｔ以下であれば、ストリームデータの蓄積量の増加必要性があると判定すれば良い。
【００７２】
すなわち、この判定方法では、言い換えれば、残バッファ量がＢｔｈ＿Ｒｅｓｔａｒｔを超えればストリームデータのデコードを再開するということになる。
【００７３】
なお、これらの判定方法は、Ｂｔｈ＿Ｐａｕｓｅ＝Ｂｔｈ＿ＲｅｓｔａｒｔであればステップＳＴ２０５と同じ判定基準による判定方法となり、Ｂｔｈ＿Ｐａｕｓｅ≠Ｂｔｈ＿Ｒｅｓｔａｒｔであれば異なる判定基準による判定方法となる。
【００７４】
次に、具体例として、図３を用いて、ストリームデータの２曲目の再生中に通信エラーが発生して、２曲目と３曲目の間でバッファ量を回復させる場合について説明する。
【００７５】
図３は、本発明の一実施の形態に係る残バッファ量の時刻推移及びストリームデータの状態を示す図である。なお、ここでは、制御情報に曲の区切り情報が含まれている場合を例にとって説明する。
【００７６】
図３において、ブロック３０１は、ストリーム受信再生装置１０１の端末通信部１１０が受信したストリームデータの内容の時刻推移を表す。ブロック３０２は、ストリーム受信再生装置１０１のデコーダ１１２がデコードするストリームデータの内容の時刻推移を表す。ブロック３０３は、ストリーム受信再生装置１０１のバッファ１１１に蓄積されているストリームデータの残バッファ量の時刻推移を表す。
【００７７】
図３においては、時刻Ｔｄから時刻Ｔｅの間に通信エラーが発生し、ストリーム受信再生装置１０１のバッファ１１１に蓄積されているストリームデータの残バッファ量が減少している状態を示している。
【００７８】
図３に示すように、クライアントであるストリーム受信再生装置１０１は、時刻Ｔａにストリームデータの受信を開始し、一定時間（Ｔｉｎｉ）経過後の時刻Ｔｂからデコーダ１１２によるストリームデータのデコードが開始される。
【００７９】
このように、本例のストリーム受信再生装置１０１においては、バッファ１１１に一定の残バッファ量のストリームデータを確保するために、時刻Ｔａから時刻Ｔｂの間は、ストリームデータはバッファ１１１に蓄積されるがストリームデータのデコードは開始されない。
【００８０】
そして、時刻Ｔｂ以降の、１曲目のストリームデータが配信されている間は、ストリームデータの蓄積とデコードを繰返す。
【００８１】
その後、端末制御部１１３は、１曲目の終了を示す曲の区切り情報が含まれている制御情報を受信すると、残バッファ量に基づきストリームデータの蓄積量の増加必要性があるか否かを判定する。
【００８２】
図３に示す例では、１曲目の終了時点での残バッファ量はＢ１であるので、残バッファ量Ｂ１が閾値Ｂｔｈ＿Ｐａｕｓｅ以下であるか否か判定する。この例の場合は、Ｂ１＞Ｂｔｈ＿Ｐａｕｓｅであるので、ストリームデータの蓄積量の増加必要性は無いと判定し、引き続き２曲目のデコード処理を継続する。
【００８３】
その後、端末制御部１１３は、２曲目の終了を示す曲の区切り情報が含まれている制御情報を受信すると、残バッファ量に基づきストリームデータの蓄積量の増加必要性があるか否かを判定する。
【００８４】
図３に示す例では、２曲目の終了時点での残バッファ量はＢ２であるので、残バッファ量Ｂ２が閾値Ｂｔｈ＿Ｐａｕｓｅ以下であるか否か判定する。この例の場合は、Ｂ２＜Ｂｔｈ＿Ｐａｕｓｅであるので、ストリームデータの蓄積量の増加必要性があると判定し、端末制御部１１３がデコーダ１１２を制御してストリームデータのデコードを一時停止する。
【００８５】
次いで、デコードを一時停止している状態においてストリームデータを受信すると、ストリームデータの受信とストリームデータのバッファ１１１への蓄積を行い、ストリームデータの蓄積量の増加必要性があるか否かを判定する。
【００８６】
図３に示す例では、時刻Ｔｆから時刻Ｔｇまでの間は残バッファ量がＢｔｈ＿Ｒｅｓｔａｒｔ以下であるので、ストリームデータの蓄積量の増加必要性があると判定して、ストリームデータのデコードの一時停止を継続する（デコード停止区間３０２１）。
【００８７】
そして、図３に示す例では、時刻Ｔｇを超えた段階で、残バッファ量がＢｔｈ＿Ｒｅｓｔａｒｔを超えるので、時刻Ｔｇより後では、ストリームデータのデコードが再開されて３曲目がデコードされる。
【００８８】
上述のように、本例のストリーム受信再生装置１０１においては、受信したストリームデータに関する制御情報により、ストリームデータの状態が一時停止可能であるか否かを判定することができる。
【００８９】
また、本例のストリーム受信再生装置１０１においては、バッファ１１１に蓄積されているストリームデータの残バッファ量から、ストリームデータの蓄積量の増加必要性の有無を判定することができる。
【００９０】
そして、本例のストリーム受信再生装置１０１においては、ストリームデータの状態が一時停止可能であり、かつ、ストリームデータの蓄積量の増加必要性があると判定した場合に、端末制御部１１３が、デコーダ１１２を制御してストリームデータのデコードを一時停止し、バッファ１１１に蓄積されているストリームデータの残バッファ量を増加させるように制御する。
【００９１】
従って、本例のストリーム受信再生装置１０１を用いたストリーミングネットワークシステムにおいては、ストリームデータの受信側であるストリーム受信再生装置１０１だけの制御により、ネットワーク１０３上での通信エラーや、無線電波状況の悪化などが原因により発生するバッファ１１１のアンダーフローの発生頻度を抑えることができる。
【００９２】
なお、ここでは、図３に示すように、制御情報に曲の終了を示す「曲の区切り情報」が含まれている場合を例にとって説明したが、本例のストリーム受信再生装置１０１は、図４に示すように、制御情報に曲のトラック番号の変化通知する情報あるいは曲間の状態を示す情報が含まれている場合でも同様に制御することができる。
【００９３】
図４に示す例の場合は、曲の終了を示す「曲の区切り情報」の代わりに「曲間の状態」を示す情報が制御情報に含まれている。
【００９４】
図４に示す例は、例えば時刻Ｔｃにおいて、１曲目の終了を示す「曲の区切り情報」の変わりに「曲間の状態」を示す制御情報を用いて、ストリームデータの状態が一時停止可能であるか否か、及びストリームデータの蓄積量の増加必要性があるか否かを判定する点が、図３に示した例の場合と異なる。
【００９５】
また、図４に示す例は、時刻Ｔｆにおいて、２曲目の終了を示す「曲の区切り情報」の変わりに「曲間の状態」を示す制御情報を用いて、ストリームデータの状態が一時停止可能であるか否か、及びストリームデータの蓄積量の増加必要性があるか否かを判定する点が、図３に示した例の場合と異なる。
【００９６】
なお、以上の説明では、無線通信方式に関しては特に限定されるものではないが、例えば近距離無線通信技術のＢｌｕｅｔｏｏｔｈや無線ＬＡＮを用いても良い。
【００９７】
ここで、無線通信方式にＢｌｕｅｔｏｏｔｈを用いる場合は、例えばストリームデータはＡ２ＤＰ（Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｐｒｏｆｉｌｅ）で送信して良い。
【００９８】
また、ストリームデータに関する制御情報は、例えばＡＶＲＣＰ（Ａｕｄｉｏ／Ｖｉｄｅｏ Ｒｅｍｏｔｅ Ｃｏｎｔｒｏｌ Ｐｒｏｆｉｌｅ）におけるＶｅｎｄｏｒ Ｄｅｐｅｎｄｅｎｔ Ｃｏｍｍａｎｄで送信しても良い。
【００９９】
また、ストリームデータに関する制御情報は、ＡＶＲＣＰにおけるＶｅｎｄｏｒ Ｕｎｉｑｕｅ Ｏｐｅｒａｔｉｏｎ＿Ｉｄを持つＰａｓｓ Ｔｈｒｏｕｇｈ Ｃｏｍｍａｎｄで送信しても良い。
【０１００】
ここで、Ａ２ＤＰは、Ｂｌｕｅｔｏｏｔｈにおいて音楽データなどのストリームデータを送受信するための技術的仕様である。
【０１０１】
また、ＡＶＲＣＰは、Ｂｌｕｅｔｏｏｔｈにおいてストリームの制御コマンド（Ｐｌａｙ、Ｓｔｏｐなど）を送受信するための技術的仕様である。
【０１０２】
さらに、Ｖｅｎｄｏｒ Ｄｅｐｅｎｄｅｎｔ ＣｏｍｍａｎｄやＶｅｎｄｏｒ Ｕｎｉｑｕｅ Ｏｐｅｒａｔｉｏｎ＿Ｉｄは、ＡＶＲＣＰにおいて各ベンダーが独自の拡張をすることができるコマンドである。
【０１０３】
なお、上記説明では具体値を上げて説明した部分もあるが本発明がそれに限定されないことは言うまでもない。
【産業上の利用可能性】
【０１０４】
本発明に係るストリーミングネットワークシステム及びストリーム受信再生装置は、ストリームデータの送信側が符号化レートの異なるストリームデータを送信不可能なシステムや、ストリームデータの受信側の通知したレート情報を元にストリームデータの送信側がストリーム配信のレートの制御をすることが不可能であるシステムにおいても、ストリームデータ受信用バッファのアンダーフローの発生頻度を低下させることができるので、音声や動画などのデータをネットワーク経由で受信しながら再生するストリーミング技術を用いたストリーミングネットワークシステム及びストリーム受信再生装置として有用である。
【図面の簡単な説明】
【０１０５】
【図１】本発明の一実施の形態に係るストリーミングネットワークシステムの構成を示すブロック図
【図２】本発明の一実施の形態に係るストリーミングネットワークシステムの動作を示すフローチャート
【図３】本発明の一実施の形態に係る残バッファ量の時刻推移及びストリームデータの状態を示す図
【図４】本発明の一実施の形態に係る残バッファ量の時刻推移及びストリームデータの他の状態を示す図
【図５】特許文献１記載の伝送システムの構成を示すブロック図
【符号の説明】
【０１０６】
１００ ストリーミングネットワークシステム
１０１ ストリーム受信再生装置
１０２ サーバ
１０３ ネットワーク
１１０ 端末通信部
１１１ バッファ
１１２ デコーダ
１１３ 端末制御部
１１４ スピーカ
１２０ サーバ制御部
１２１ ストリームデータ送出部
１２２ サーバ通信部
１２３ ストリームデータ蓄積部
【技術分野】
【０００１】
本発明は、音声や動画などのデータをネットワーク経由で受信しながら再生するストリーミング技術を用いるストリーム受信再生装置及びストリーミングネットワークシステムに関する。
【背景技術】
【０００２】
ストリーミング技術は、音声や動画などのリアルタイム性が要求されるデータを、ネットワークを介して配送し、配送しながら再生を行う技術である。
【０００３】
ストリーミング技術を用いたストリーム受信再生装置は、全データをダウンロードすることなく再生できるので、
（１）受信側に大容量の記憶装置などが不要となる。
【０００４】
（２）全データをダウンロードして再生する方式に比べ、データの配送開始から再生開始までの所要時間を短縮してデータ再生の高速化を図れる。
という特徴がある。
【０００５】
しかしながら、ストリーミング技術を用いたストリーム受信再生装置においては、ネットワーク上での通信エラー発生や、無線ネットワーク経由でデータを配信する場合の電波状況の悪化などが原因となって、ストリームデータの受信バッファのアンダーフローが発生するという課題がある。
【０００６】
このようなストリームデータの受信バッファのアンダーフローが発生すると聴感上の雑音発生などの問題が生じる。
【０００７】
この問題を解決する技術として、例えば特許文献１に示す「伝送システム」がある。図５は、特許文献１記載の伝送システムの構成を示すブロック図である。
【０００８】
図５において、サーバ３０は、ネットワーク１０を介してクライアント端末２０と接続されている。
【０００９】
サーバ３０には、画像と音声を多重化した多重化レートの異なる複数の多重化ファイル（ストリームデータ）が格納されている。
【００１０】
サーバ３０から送られた多重化データは、まずクライアント端末２０の入力バッファ２１でバッファリングされ多重分離部２２に渡される。
【００１１】
多重分離部２２は、データストリームを画像データと音声データとに分離し、画像復号部２３及び音声復号部２４にデータを送る。
【００１２】
画像復号部２３は、画像データを復号し、画像バッファ２５に復号データを送る。
【００１３】
音声復号部２４は、音声データを復号し、音声バッファ２６に復号データを送る。
【００１４】
画像バッファ２５と音声バッファ２６は、画像復号部２３と音声復号部２４の復号時間差を吸収し、画像と音声の同期をとる役割を担う。
【００１５】
同期がとられた画像データと音声データは、ディスプレイ２７とスピーカ２８からそれぞれ画像、音声として出力される。
【００１６】
レート計算部２９は、例えばサーバ３０からネットワーク１０を経由して入力バッファ２１へ送られてくる単位時間内のデータ量を常にカウントし、実質の伝送レートを計算し、その伝送レート情報をサーバ３０に通知する。このような通知は、例えば所定の時間ごとに行う。
【００１７】
サーバ３０は、画像と音声を多重化した符号化レートが異なる多重化ファイル（ストリームデータ）３１〜３３と、クライアント端末２０側から送られてくる伝送レート情報によってファイルを切り替える多重化ファイル切換スイッチ３４と、を備える。
【００１８】
多重化ファイル３１〜３３は、符号化レートが異なる同一のコンテンツ、すなわち符号化レートが異なる同一データを蓄積する。符号化レートは、例えば６０ｋｂｐｓ、４５ｋｂｐｓ、３０ｋｂｐｓのように設定する。
【００１９】
この伝送システムにおいてストリ一ミング再生を開始すると、サーバ３０は、クライアント端末２０に対して動画像の伝送を始める。
【００２０】
クライアント端末２０は、入力バッファ２１で多重化データのバッファリングを開始しながら、レート計算部２９において実質伝送レート（ｂｐｓ）の計算を開始する。この実質伝送レートは、サーバ３０の負荷が上がったり、ネットワーク１０が混雑したりすると低下の方向に向かう。この伝送レート情報は、例えば一定の時間間隔でサーバ３０に通知される。
【００２１】
サーバ３０は、一定の時間間隔でクライアント端末２０から通知される伝送レート情報に基づき、多重化ファイル切換スイッチ３４で通知されたレートに近いかそれ以下になる多重化ファイル３１〜３３を選択し、切り替える。
【００２２】
このように、特許文献１の「伝送システム」では、ネットワーク１０が混雑したり、サーバ３０の負荷が増大したりすることによってクライアント端末２０での実質の受信レートが変動した場合、一定周期でクライアント端末２０からサーバ３０に送られている伝送レート情報に基づいて、その伝送レート以下の最も近いファイルに切り替える。
【００２３】
これにより、この「伝送システム」では、クライアント端末２０側で実質伝送レートが変動した場合でも、ストリーミング再生において途切れ途切れになることがなくシームレスな再生を行うことができ、動画像の見にくさが解消される。
【特許文献１】特開平１１−２０５３９０号公報
【発明の開示】
【発明が解決しようとする課題】
【００２４】
しかしながら、前記従来の構成では、ストリームデータの送信側（サーバ）が符号化レートの異なる多重化ファイル（ストリームデータ）を送信可能なシステムにしか適用することができないという課題を有していた。
【００２５】
また、前記従来の構成では、ストリームデータの受信側（クライアント端末）が、ストリームデータの実質の受信レートであるレート情報をストリームデータの送信側（サーバ）に通知し、ストリームデータの送信側（サーバ）が前記レート情報を元にストリーム配信のレートの制御をすることが可能であるシステムにしか適用することができないという課題も有していた。
【００２６】
本発明は、かかる点に鑑みてなされたもので、ストリームデータの送信側が符号化レートの異なるストリームデータを送信不可能なシステムや、ストリームデータの受信側の通知したレート情報を元にストリームデータの送信側がストリーム配信のレートの制御をすることが不可能であるシステムにおいても、ストリームデータ受信用バッファのアンダーフローの発生頻度を低下させることができるストリーム受信再生装置及びストリーミングネットワークシステムを提供することを目的とする。
【課題を解決するための手段】
【００２７】
かかる課題を解決するため、本発明のストリーム受信再生装置は、配信されたストリームデータおよび制御データを受信する通信手段と、前記通信手段により受信した前記ストリームデータを一時的に蓄積する蓄積手段と、前記蓄積手段により蓄積された前記ストリームデータをデコードするデコード手段と、前記通信手段が受信した前記ストリームデータに関する制御情報により、前記ストリームデータの状態が一時停止可能であり、かつ前記ストリームデータの蓄積量の増加必要性が有ると判定した場合に、前記デコード手段を制御して前記ストリームデータのデコードを一時停止し、前記蓄積手段に蓄積される前記ストリームデータのデータ量を増加させる制御手段と、を具備する構成を採る。
【発明の効果】
【００２８】
本発明のストリーム受信再生装置及びストリーミングネットワークシステムによれば、ストリームデータの送信側が符号化レートの異なるストリームデータを送信不可能なシステムや、ストリームデータの受信側の通知したレート情報を元にストリームデータの送信側がストリーム配信のレートの制御をすることが不可能であるシステムにおいても、ストリームデータ受信用バッファのアンダーフローの発生頻度を低下させることができる。
【発明を実施するための最良の形態】
【００２９】
以下、本発明の実施の形態について、図面を参照して詳細に説明する。
【００３０】
図１は、本発明の一実施の形態に係るストリーミングネットワークシステムの構成を示す図である。
【００３１】
図１に示すように、本例のストリーミングネットワークシステム１００は、ストリーム受信再生装置（クライアント）１０１と、サーバ１０２と、ネットワーク１０３から構成される。なお、図１において、ネットワーク１０３は、本例では無線ネットワークを例示しているが、これに限らず、有線ネットワークでも良い。
【００３２】
ストリーム受信再生装置１０１は、端末通信部１１０と、バッファ１１１と、デコーダ１１２と、端末制御部１１３と、を備えている。
【００３３】
サーバ１０２は、サーバ制御部１２０と、ストリームデータ送出部１２１と、サーバ通信部１２２と、ストリームデータ蓄積部１２３と、を備えている。
【００３４】
まず、クライアントであるストリーム受信再生装置１０１の構成について説明する。
【００３５】
図１において、端末通信部１１０は、ネットワーク１０３を介してストリームデータを受信し、受信したストリームデータをバッファ１１１へ出力する。
【００３６】
クライアント側の蓄積手段としてのバッファ１１１は、端末通信部１１０から入力したストリームデータを一時的に蓄積する。そして、バッファ１１１は、蓄積したストリームデータをデコーダ１１２へ出力する。
【００３７】
デコーダ１１２は、バッファ１１１から入力したストリームデータをデコードしてスピーカ１１４へ出力する。
【００３８】
端末制御部１１３は、端末通信部１１０から受信したストリームデータに関する制御情報と、バッファ１１１の状態とに基づいて、デコーダ１１２を制御する。具体的には、端末制御部１１３は、ストリームデータの状態が一時停止可能であり、ストリームデータの蓄積量の増加必要性があると判定した場合には、デコーダ１１２を制御してストリームデータのデコードを一時停止し、バッファ１１１に蓄積されるストリームデータのデータ量を増加させるように制御する。
【００３９】
スピーカ１１４は、デコーダ１１２から入力したストリームデータが表す音楽等を外部へ出力する。
【００４０】
次に、サーバ１０２の構成について説明する。
【００４１】
ストリームデータ蓄積部１２３は、配信するストリームデータ及びストリームデータに関する制御情報、例えば、曲名、アルバム名、アーティスト名、曲の長さなどの時間情報、といった曲情報を蓄積し、ストリームデータをストリームデータ送出部１２１に出力する。
【００４２】
ストリームデータ送出部１２１は、サーバ制御部１２０の制御に基づいて、ストリームデータをサーバ通信部１２２へ出力する。
【００４３】
サーバ制御部１２０は、ストリームデータ送出部１２１を制御する。また、サーバ制御部１２０は、ストリームデータ蓄積部１２３から制御情報を読み出し、読み出した制御情報をサーバ通信部１２２へ出力する。
【００４４】
サーバ通信部１２２は、ストリームデータ送出部１２１から入力したストリームデータ、及びサーバ制御部１２０から入力した制御情報を、ネットワーク１０３を介してストリーム受信再生装置１０１へ送信する。
【００４５】
次に、図２を用いて、上述のように構成されたストリーミングネットワークシステム１００の動作について説明する。図２は、本発明の一実施の形態に係るストリーミングネットワークシステムの動作を示すフローチャートである。
【００４６】
通常のストリーミング再生の基本動作では、ストリーム受信再生装置１０１は、ネットワーク１０３を介してストリームデータの受信を開始し、受信開始から一定時間内（例えばＴｉｎｉ）に受信したストリームデータをバッファ１１１に蓄える。
【００４７】
なお、ストリーム受信再生装置１０１は、一定時間内に受信したストリームデータをバッファ１１１に蓄えるように構成されている場合に限らず、一定量のストリームデータをバッファ１１１に蓄えるように構成されていても良い。
【００４８】
端末制御部１１３は、一定時間Ｔｉｎｉが経過するか、またはバッファ１１１に一定量のストリームデータが蓄積されると、ストリームデータのデコードの開始をデコーダ１１２に対して指示する。
【００４９】
デコーダ１１２は、端末制御部１１３からの指示に応答して、バッファ１１１に蓄積されたストリームデータのデコードを開始し、デコード済みのストリームデータをスピーカ１１４に与える。
【００５０】
このようにして、ストリーム受信再生装置１０１では、ストリームデータが再生され、受信したストリームデータが表す音楽がスピーカ１１４から鳴り始める。
【００５１】
以降のストリームデータ再生中の状態においては、ストリームデータを受信（ステップＳＴ２０１）し、受信したストリームデータをバッファ１１１に蓄積する（ステップＳＴ２０２）。
【００５２】
端末制御部１１３は、ストリームデータの受信中に、制御情報を受信したか否か判定する（ステップＳＴ２０３）。
【００５３】
そして、ステップＳＴ２０３において、端末制御部１１３が制御情報を受信していないと判定した場合には、ステップＳＴ２０１〜ステップＳＴ２０３の処理を繰返す。
【００５４】
一方、ステップＳＴ２０３において、端末制御部１１３が制御情報を受信したと判定した場合には、ストリームデータの状態が一時停止可能であるか否かを判定する（ステップＳＴ２０４）。
【００５５】
そして、ステップＳＴ２０４において、ストリームデータの状態が一時停止可能で無いと判定した場合には、ステップＳＴ２０１〜ステップＳＴ２０４の処理を繰返す。
【００５６】
一方、ステップＳＴ２０４において、ストリームデータの状態が一時停止可能であると判定した場合には、バッファ１１１に蓄積されたストリームデータのデータ量（以下、これを「残バッファ量」という）に基づき、ストリームデータの蓄積量の増加必要性があるか否かを判定する（ステップＳＴ２０５）。
【００５７】
そして、ステップＳＴ２０５にいて、ストリームデータの蓄積量の増加必要性が無いと判定した場合には、ステップＳＴ２０１〜ステップＳＴ２０５の処理を繰返す。
【００５８】
一方、ステップＳＴ２０５にいて、ストリームデータの蓄積量の増加必要性が有ると判定した場合には、端末制御部１１３はデコーダ１１２を制御してストリームデータのデコードを一時停止する（ステップＳＴ２０６）。
【００５９】
次いで、ストリームデータのデコードを一時停止した状態において、ストリームデータを受信すると（ステップＳＴ２０７）、ストリームデータをバッファ１１１に蓄積（ステップＳＴ２０８）し、再度、ストリームデータの蓄積量の増加必要性があるか否かを判定する（ステップＳＴ２０９）。
【００６０】
そして、ステップＳＴ２０９において、ストリームデータの蓄積量の増加必要性があると判定した場合には、ステップＳＴ２０７〜ステップＳＴ２０９の処理を繰返す。
【００６１】
一方、ステップＳＴ２０９において、ストリームデータの蓄積量の増加必要性が無いと判定した場合には、ストリームデータのデコードを再開し（ステップＳＴ２１０）、ステップＳＴ２０１に戻ってステップＳＴ２０１からステップＳＴ２０９の処理を繰返す。
【００６２】
次に、ステップＳＴ２０４において、ストリームデータの状態が一時停止可能であるか否かを判定する方法について具体例を挙げて説明する。
【００６３】
ここでは、具体例として、ステップＳＴ２０３において端末制御部１１３が受信の有無を判定する制御情報が、曲名、アルバム名、アーティスト名、曲の長さなどの時間情報、曲の区切りを示す曲の区切り情報、曲のトラック番号情報、曲間の状態を示す曲状態情報、といった曲情報を含んでいる場合について説明する。
【００６４】
このように、制御情報が曲情報、例えば曲の区切り情報を含んでいる場合には、ストリームデータが曲の区切りにあるときにストリームデータの状態が一時停止可能であると判定するように端末制御部１１３を構成することで、ストリームデータの状態が一時停止可能であるか否かを判定することが可能となる。
【００６５】
また、制御情報に曲のトラック番号の変化を通知する情報が含まれている場合には、ストリームデータが曲と曲の間の状態にあるときにストリームデータの状態が一時停止可能であると判定するように端末制御部１１３を構成することで、ストリームデータの状態が一時停止可能であるか否かを判定することが可能となる。
【００６６】
同様に、制御情報に曲間の状態を示す情報が含まれていた場合には、ストリームデータが曲と曲の間の状態にあるときにストリームデータの状態が一時停止可能であると判定するように端末制御部１１３を構成することで、ストリームデータの状態が一時停止可能であるか否かを判定することが可能となる。
【００６７】
次に、ステップＳＴ２０５において、ストリームデータの蓄積量の増加必要性があるか否かを判定する方法について具体例を挙げて説明する。
【００６８】
ストリームデータの蓄積量の増加必要性の有無の判定方法としては、例えば、ある一定の閾値（例えばＢｔｈ＿Ｐａｕｓｅ）を設けておき、残バッファ量が閾値Ｂｔｈ＿Ｐａｕｓｅ以下であれば、ストリームデータの蓄積量の増加必要性があると判定すれば良い。
【００６９】
また、他の判定方法としては、残バッファ量を定期的に観測し、残バッファ量が減少傾向にあるならば、ストリームデータの蓄積量の増加必要性があると判定しても良い。
【００７０】
なお、ステップＳＴ２０９におけるストリームデータの蓄積量の増加必要性があるか否かを判定する方法については、ステップＳＴ２０５と同じ判定基準による判定方法を用いても良いし、あるいは異なった判定方法を用いても良い。
【００７１】
ステップＳＴ２０５と異なった判定方法としては、例えば、ステップＳＴ２０９において判定に用いる閾値をＢｔｈ＿Ｒｅｓｔａｒｔとし、残バッファ量がＢｔｈ＿Ｒｅｓｔａｒｔ以下であれば、ストリームデータの蓄積量の増加必要性があると判定すれば良い。
【００７２】
すなわち、この判定方法では、言い換えれば、残バッファ量がＢｔｈ＿Ｒｅｓｔａｒｔを超えればストリームデータのデコードを再開するということになる。
【００７３】
なお、これらの判定方法は、Ｂｔｈ＿Ｐａｕｓｅ＝Ｂｔｈ＿ＲｅｓｔａｒｔであればステップＳＴ２０５と同じ判定基準による判定方法となり、Ｂｔｈ＿Ｐａｕｓｅ≠Ｂｔｈ＿Ｒｅｓｔａｒｔであれば異なる判定基準による判定方法となる。
【００７４】
次に、具体例として、図３を用いて、ストリームデータの２曲目の再生中に通信エラーが発生して、２曲目と３曲目の間でバッファ量を回復させる場合について説明する。
【００７５】
図３は、本発明の一実施の形態に係る残バッファ量の時刻推移及びストリームデータの状態を示す図である。なお、ここでは、制御情報に曲の区切り情報が含まれている場合を例にとって説明する。
【００７６】
図３において、ブロック３０１は、ストリーム受信再生装置１０１の端末通信部１１０が受信したストリームデータの内容の時刻推移を表す。ブロック３０２は、ストリーム受信再生装置１０１のデコーダ１１２がデコードするストリームデータの内容の時刻推移を表す。ブロック３０３は、ストリーム受信再生装置１０１のバッファ１１１に蓄積されているストリームデータの残バッファ量の時刻推移を表す。
【００７７】
図３においては、時刻Ｔｄから時刻Ｔｅの間に通信エラーが発生し、ストリーム受信再生装置１０１のバッファ１１１に蓄積されているストリームデータの残バッファ量が減少している状態を示している。
【００７８】
図３に示すように、クライアントであるストリーム受信再生装置１０１は、時刻Ｔａにストリームデータの受信を開始し、一定時間（Ｔｉｎｉ）経過後の時刻Ｔｂからデコーダ１１２によるストリームデータのデコードが開始される。
【００７９】
このように、本例のストリーム受信再生装置１０１においては、バッファ１１１に一定の残バッファ量のストリームデータを確保するために、時刻Ｔａから時刻Ｔｂの間は、ストリームデータはバッファ１１１に蓄積されるがストリームデータのデコードは開始されない。
【００８０】
そして、時刻Ｔｂ以降の、１曲目のストリームデータが配信されている間は、ストリームデータの蓄積とデコードを繰返す。
【００８１】
その後、端末制御部１１３は、１曲目の終了を示す曲の区切り情報が含まれている制御情報を受信すると、残バッファ量に基づきストリームデータの蓄積量の増加必要性があるか否かを判定する。
【００８２】
図３に示す例では、１曲目の終了時点での残バッファ量はＢ１であるので、残バッファ量Ｂ１が閾値Ｂｔｈ＿Ｐａｕｓｅ以下であるか否か判定する。この例の場合は、Ｂ１＞Ｂｔｈ＿Ｐａｕｓｅであるので、ストリームデータの蓄積量の増加必要性は無いと判定し、引き続き２曲目のデコード処理を継続する。
【００８３】
その後、端末制御部１１３は、２曲目の終了を示す曲の区切り情報が含まれている制御情報を受信すると、残バッファ量に基づきストリームデータの蓄積量の増加必要性があるか否かを判定する。
【００８４】
図３に示す例では、２曲目の終了時点での残バッファ量はＢ２であるので、残バッファ量Ｂ２が閾値Ｂｔｈ＿Ｐａｕｓｅ以下であるか否か判定する。この例の場合は、Ｂ２＜Ｂｔｈ＿Ｐａｕｓｅであるので、ストリームデータの蓄積量の増加必要性があると判定し、端末制御部１１３がデコーダ１１２を制御してストリームデータのデコードを一時停止する。
【００８５】
次いで、デコードを一時停止している状態においてストリームデータを受信すると、ストリームデータの受信とストリームデータのバッファ１１１への蓄積を行い、ストリームデータの蓄積量の増加必要性があるか否かを判定する。
【００８６】
図３に示す例では、時刻Ｔｆから時刻Ｔｇまでの間は残バッファ量がＢｔｈ＿Ｒｅｓｔａｒｔ以下であるので、ストリームデータの蓄積量の増加必要性があると判定して、ストリームデータのデコードの一時停止を継続する（デコード停止区間３０２１）。
【００８７】
そして、図３に示す例では、時刻Ｔｇを超えた段階で、残バッファ量がＢｔｈ＿Ｒｅｓｔａｒｔを超えるので、時刻Ｔｇより後では、ストリームデータのデコードが再開されて３曲目がデコードされる。
【００８８】
上述のように、本例のストリーム受信再生装置１０１においては、受信したストリームデータに関する制御情報により、ストリームデータの状態が一時停止可能であるか否かを判定することができる。
【００８９】
また、本例のストリーム受信再生装置１０１においては、バッファ１１１に蓄積されているストリームデータの残バッファ量から、ストリームデータの蓄積量の増加必要性の有無を判定することができる。
【００９０】
そして、本例のストリーム受信再生装置１０１においては、ストリームデータの状態が一時停止可能であり、かつ、ストリームデータの蓄積量の増加必要性があると判定した場合に、端末制御部１１３が、デコーダ１１２を制御してストリームデータのデコードを一時停止し、バッファ１１１に蓄積されているストリームデータの残バッファ量を増加させるように制御する。
【００９１】
従って、本例のストリーム受信再生装置１０１を用いたストリーミングネットワークシステムにおいては、ストリームデータの受信側であるストリーム受信再生装置１０１だけの制御により、ネットワーク１０３上での通信エラーや、無線電波状況の悪化などが原因により発生するバッファ１１１のアンダーフローの発生頻度を抑えることができる。
【００９２】
なお、ここでは、図３に示すように、制御情報に曲の終了を示す「曲の区切り情報」が含まれている場合を例にとって説明したが、本例のストリーム受信再生装置１０１は、図４に示すように、制御情報に曲のトラック番号の変化通知する情報あるいは曲間の状態を示す情報が含まれている場合でも同様に制御することができる。
【００９３】
図４に示す例の場合は、曲の終了を示す「曲の区切り情報」の代わりに「曲間の状態」を示す情報が制御情報に含まれている。
【００９４】
図４に示す例は、例えば時刻Ｔｃにおいて、１曲目の終了を示す「曲の区切り情報」の変わりに「曲間の状態」を示す制御情報を用いて、ストリームデータの状態が一時停止可能であるか否か、及びストリームデータの蓄積量の増加必要性があるか否かを判定する点が、図３に示した例の場合と異なる。
【００９５】
また、図４に示す例は、時刻Ｔｆにおいて、２曲目の終了を示す「曲の区切り情報」の変わりに「曲間の状態」を示す制御情報を用いて、ストリームデータの状態が一時停止可能であるか否か、及びストリームデータの蓄積量の増加必要性があるか否かを判定する点が、図３に示した例の場合と異なる。
【００９６】
なお、以上の説明では、無線通信方式に関しては特に限定されるものではないが、例えば近距離無線通信技術のＢｌｕｅｔｏｏｔｈや無線ＬＡＮを用いても良い。
【００９７】
ここで、無線通信方式にＢｌｕｅｔｏｏｔｈを用いる場合は、例えばストリームデータはＡ２ＤＰ（Ａｄｖａｎｃｅｄ Ａｕｄｉｏ Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｐｒｏｆｉｌｅ）で送信して良い。
【００９８】
また、ストリームデータに関する制御情報は、例えばＡＶＲＣＰ（Ａｕｄｉｏ／Ｖｉｄｅｏ Ｒｅｍｏｔｅ Ｃｏｎｔｒｏｌ Ｐｒｏｆｉｌｅ）におけるＶｅｎｄｏｒ Ｄｅｐｅｎｄｅｎｔ Ｃｏｍｍａｎｄで送信しても良い。
【００９９】
また、ストリームデータに関する制御情報は、ＡＶＲＣＰにおけるＶｅｎｄｏｒ Ｕｎｉｑｕｅ Ｏｐｅｒａｔｉｏｎ＿Ｉｄを持つＰａｓｓ Ｔｈｒｏｕｇｈ Ｃｏｍｍａｎｄで送信しても良い。
【０１００】
ここで、Ａ２ＤＰは、Ｂｌｕｅｔｏｏｔｈにおいて音楽データなどのストリームデータを送受信するための技術的仕様である。
【０１０１】
また、ＡＶＲＣＰは、Ｂｌｕｅｔｏｏｔｈにおいてストリームの制御コマンド（Ｐｌａｙ、Ｓｔｏｐなど）を送受信するための技術的仕様である。
【０１０２】
さらに、Ｖｅｎｄｏｒ Ｄｅｐｅｎｄｅｎｔ ＣｏｍｍａｎｄやＶｅｎｄｏｒ Ｕｎｉｑｕｅ Ｏｐｅｒａｔｉｏｎ＿Ｉｄは、ＡＶＲＣＰにおいて各ベンダーが独自の拡張をすることができるコマンドである。
【０１０３】
なお、上記説明では具体値を上げて説明した部分もあるが本発明がそれに限定されないことは言うまでもない。
【産業上の利用可能性】
【０１０４】
本発明に係るストリーミングネットワークシステム及びストリーム受信再生装置は、ストリームデータの送信側が符号化レートの異なるストリームデータを送信不可能なシステムや、ストリームデータの受信側の通知したレート情報を元にストリームデータの送信側がストリーム配信のレートの制御をすることが不可能であるシステムにおいても、ストリームデータ受信用バッファのアンダーフローの発生頻度を低下させることができるので、音声や動画などのデータをネットワーク経由で受信しながら再生するストリーミング技術を用いたストリーミングネットワークシステム及びストリーム受信再生装置として有用である。
【図面の簡単な説明】
【０１０５】
【図１】本発明の一実施の形態に係るストリーミングネットワークシステムの構成を示すブロック図
【図２】本発明の一実施の形態に係るストリーミングネットワークシステムの動作を示すフローチャート
【図３】本発明の一実施の形態に係る残バッファ量の時刻推移及びストリームデータの状態を示す図
【図４】本発明の一実施の形態に係る残バッファ量の時刻推移及びストリームデータの他の状態を示す図
【図５】特許文献１記載の伝送システムの構成を示すブロック図
【符号の説明】
【０１０６】
１００ ストリーミングネットワークシステム
１０１ ストリーム受信再生装置
１０２ サーバ
１０３ ネットワーク
１１０ 端末通信部
１１１ バッファ
１１２ デコーダ
１１３ 端末制御部
１１４ スピーカ
１２０ サーバ制御部
１２１ ストリームデータ送出部
１２２ サーバ通信部
１２３ ストリームデータ蓄積部
【特許請求の範囲】
【請求項１】
配信されたストリームデータおよび制御データを受信する通信手段と、
前記通信手段により受信した前記ストリームデータを一時的に蓄積する蓄積手段と、
前記蓄積手段により蓄積された前記ストリームデータをデコードするデコード手段と、
前記通信手段が受信した前記ストリームデータに関する制御情報により、前記ストリームデータの状態が一時停止可能であり、かつ前記ストリームデータの蓄積量の増加必要性が有ると判定した場合に、前記デコード手段を制御して前記ストリームデータのデコードを一時停止し、前記蓄積手段に蓄積される前記ストリームデータのデータ量を増加させる制御手段と、
を具備する、ストリーム受信再生装置。
【請求項２】
前記制御手段は、前記蓄積手段に蓄積されたストリームデータの蓄積量が予め設定した閾値以下である場合に、前記ストリームデータの蓄積量の増加必要性が有ると判定する、請求項１記載のストリーム受信再生装置。
【請求項３】
前記制御情報は、前記ストリームデータの曲情報を含み、前記制御手段は前記ストリームデータが曲間の状態であれば、前記ストリームデータのデコードを一時停止可能であると判定する、請求項１記載のストリーム受信再生装置。
【請求項４】
前記制御情報は、前記ストリームデータの曲情報を含み、前記制御手段は前記ストリームデータにおける曲のトラックの変更を検出した場合に、前記ストリームデータのデコードを一時停止可能であると判定する、請求項１記載のストリーム受信再生装置。
【請求項５】
ストリームデータを配信するサーバと、前記サーバから配信された前記ストリームデータを受信して再生するストリーム受信再生装置と、を含むネットワークで構成されるストリーミングネットワークシステムであって、
前記ストリーム受信再生装置は、配信されたストリームデータおよび制御データを受信する通信手段と、前記通信手段により受信した前記ストリームデータを一時的に蓄積する蓄積手段と、前記蓄積手段により蓄積された前記ストリームデータをデコードするデコード手段と、前記通信手段が受信した前記ストリームデータに関する制御情報により、前記ストリームデータの状態が一時停止可能であり、かつ前記ストリームデータの蓄積量の増加必要性が有ると判定した場合に、前記デコード手段を制御して前記ストリームデータのデコードを一時停止し、前記蓄積手段に蓄積される前記ストリームデータのデータ量を増加させる制御手段と、を具備し、
前記サーバは、前記ストリームデータを蓄積するストリームデータ蓄積手段と、前記ストリームデータ蓄積手段により蓄積された前記ストリームデータを送出するストリームデータ送出手段と、前記ストリームデータに関する制御情報を送出する制御手段と、前記ストリーム受信再生装置に前記ストリームデータを配信するストリームデータ配信手段と、を具備する、ストリーミングネットワークシステム。
【請求項６】
配信されたストリームデータおよび制御データを受信する通信ステップと、
前記通信ステップで受信した前記ストリームデータを一時的に蓄積する蓄積ステップと、
前記蓄積ステップで蓄積された前記ストリームデータをデコードするデコードステップと、
前記通信ステップで受信した前記ストリームデータに関する制御情報により、前記ストリームデータの状態が一時停止可能であり、かつ前記ストリームデータの蓄積量の増加必要性が有ると判定した場合に、前記ストリームデータのデコードを一時停止し、前記蓄積ステップで蓄積される前記ストリームデータのデータ量を増加させる制御ステップと、
を具備する、ストリーム受信方法。
【請求項１】
配信されたストリームデータおよび制御データを受信する通信手段と、
前記通信手段により受信した前記ストリームデータを一時的に蓄積する蓄積手段と、
前記蓄積手段により蓄積された前記ストリームデータをデコードするデコード手段と、
前記通信手段が受信した前記ストリームデータに関する制御情報により、前記ストリームデータの状態が一時停止可能であり、かつ前記ストリームデータの蓄積量の増加必要性が有ると判定した場合に、前記デコード手段を制御して前記ストリームデータのデコードを一時停止し、前記蓄積手段に蓄積される前記ストリームデータのデータ量を増加させる制御手段と、
を具備する、ストリーム受信再生装置。
【請求項２】
前記制御手段は、前記蓄積手段に蓄積されたストリームデータの蓄積量が予め設定した閾値以下である場合に、前記ストリームデータの蓄積量の増加必要性が有ると判定する、請求項１記載のストリーム受信再生装置。
【請求項３】
前記制御情報は、前記ストリームデータの曲情報を含み、前記制御手段は前記ストリームデータが曲間の状態であれば、前記ストリームデータのデコードを一時停止可能であると判定する、請求項１記載のストリーム受信再生装置。
【請求項４】
前記制御情報は、前記ストリームデータの曲情報を含み、前記制御手段は前記ストリームデータにおける曲のトラックの変更を検出した場合に、前記ストリームデータのデコードを一時停止可能であると判定する、請求項１記載のストリーム受信再生装置。
【請求項５】
ストリームデータを配信するサーバと、前記サーバから配信された前記ストリームデータを受信して再生するストリーム受信再生装置と、を含むネットワークで構成されるストリーミングネットワークシステムであって、
前記ストリーム受信再生装置は、配信されたストリームデータおよび制御データを受信する通信手段と、前記通信手段により受信した前記ストリームデータを一時的に蓄積する蓄積手段と、前記蓄積手段により蓄積された前記ストリームデータをデコードするデコード手段と、前記通信手段が受信した前記ストリームデータに関する制御情報により、前記ストリームデータの状態が一時停止可能であり、かつ前記ストリームデータの蓄積量の増加必要性が有ると判定した場合に、前記デコード手段を制御して前記ストリームデータのデコードを一時停止し、前記蓄積手段に蓄積される前記ストリームデータのデータ量を増加させる制御手段と、を具備し、
前記サーバは、前記ストリームデータを蓄積するストリームデータ蓄積手段と、前記ストリームデータ蓄積手段により蓄積された前記ストリームデータを送出するストリームデータ送出手段と、前記ストリームデータに関する制御情報を送出する制御手段と、前記ストリーム受信再生装置に前記ストリームデータを配信するストリームデータ配信手段と、を具備する、ストリーミングネットワークシステム。
【請求項６】
配信されたストリームデータおよび制御データを受信する通信ステップと、
前記通信ステップで受信した前記ストリームデータを一時的に蓄積する蓄積ステップと、
前記蓄積ステップで蓄積された前記ストリームデータをデコードするデコードステップと、
前記通信ステップで受信した前記ストリームデータに関する制御情報により、前記ストリームデータの状態が一時停止可能であり、かつ前記ストリームデータの蓄積量の増加必要性が有ると判定した場合に、前記ストリームデータのデコードを一時停止し、前記蓄積ステップで蓄積される前記ストリームデータのデータ量を増加させる制御ステップと、
を具備する、ストリーム受信方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公開番号】特開２００７−３１１９０２（Ｐ２００７−３１１９０２Ａ）
【公開日】平成１９年１１月２９日（２００７．１１．２９）
【国際特許分類】
【出願番号】特願２００６−１３６６４９（Ｐ２００６−１３６６４９）
【出願日】平成１８年５月１６日（２００６．５．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
【公開日】平成１９年１１月２９日（２００７．１１．２９）
【国際特許分類】
【出願日】平成１８年５月１６日（２００６．５．１６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（０００００５８２１）松下電器産業株式会社 (73,050)
【Ｆターム（参考）】
[ Back to top ]