(57)【要約】ストリーミング再生されるデータの圧縮率に応じて、バッファリングする記憶装置の閾値を動的に決定することにより、メモリリソースの最適化を図る。サーバ５からダウンロードされる圧縮データを一時記憶して、順次再生を行うストリーミング再生を行うデータ再生装置において、圧縮データの圧縮率に応じて閾値を変更設定することにより、ＨＤＤ１３に蓄積されるデータ量を最適化するようにした。
2005034089.tif 000002
【特許請求の範囲】
【請求項１】
通信網を介してダウンロードされた圧縮データを伸張して再生するデータ再生装置において、
上記ダウンロードされた圧縮データを一時的に記憶する記憶手段と、
上記記憶手段で記憶している圧縮データを伸張するデータ伸張手段と、
上記データ伸張手段で伸張されたデータのストリーミング再生を行う再生手段と、
上記記憶手段に一時記憶されている圧縮データのデータ容量、及び上記ダウンロードされた圧縮データの圧縮率を検出する検出手段と、
上記検出手段で検出した圧縮率に応じて上記圧縮データのデータ容量に対する閾値を変更制御すると共に、上記記憶手段に一時記憶されているデータ容量が所定の閾値以上になったとき上記記憶手段から上記圧縮データを読み出して、上記データ伸張手段に転送する制御手段と
を具えることを特徴とするデータ再生装置。
【請求項２】
上記制御手段は、
上記記憶手段に一時記憶される圧縮データの圧縮率が低くなる場合には閾値を大きくし、該圧縮率が高くなる場合には閾値を小さくするように変更制御する
ことを特徴とする請求の範囲第１項に記載のデータ再生装置。
【請求項３】
上記検出手段は、
上記ダウンロードされた圧縮データのファイルのヘッダ、又はフッタに含まれるデータに基づいて、該圧縮データの圧縮率を検出する
ことを特徴とする請求の範囲第２項に記載のデータ再生装置。
【請求項４】
上記検出手段は、
上記ダウンロードされた圧縮データについてのビットレートデータに基づいて、該圧縮データの圧縮率を検出する
ことを特徴とする請求の範囲第２項に記載のデータ再生装置。
【請求項５】
上記制御手段は、
上記記憶手段から上記圧縮データを読み出し上記データ伸張手段に転送するタイミングを決める第１の閾値と、上記圧縮データの上記記憶手段へのダウンロードを中断するタイミングを決める第２の閾値とを、それぞれ変更制御する
ことを特徴とする請求の範囲第１項に記載のデータ再生装置。
【請求項６】
上記制御手段は、
上記通信網の伝送能力に応じて上記閾値を変更制御する
ことを特徴とする請求の範囲第１項に記載のデータ再生装置。
【請求項７】
上記圧縮データは、ＭＰ３（ＭＰＥＧ  Ａｕｄｉｏ  Ｌａｙｅｒ  ３）データである
ことを特徴とする請求の範囲第１項に記載のデータ再生装置。
【請求項８】
通信網を介してダウンロードされた圧縮データを伸張して再生するデータ再生方法であって、
（ａ）圧縮データを配信するサーバに接続するステップと、
（ｂ）上記圧縮データのダウンロードに際し、記憶手段に対する上記圧縮データのオーバーフローが発生しない範囲内で上記サーバに対して最大限サイズの部分データの転送を要求するステップと、
（ｃ）所定量の圧縮データが格納された時点で再生を開始するステップと、
（ｄ）上記記憶手段に一時記憶されている圧縮データのデータ容量、及び上記ダウンロードされた圧縮データの圧縮率を検出するステップと、
（ｅ）上記ステップ（ｄ）で検出した圧縮率に応じて上記圧縮データのデータ容量に対する閾値を変更制御するステップと、
（ｆ）上記記憶手段内の未再生の圧縮データが上記閾値以下になったか否かをチェックするステップと、
（ｇ）上記ステップ（ｆ）で上記閾値以下になったと判定された時点で再生を停止するステップと
を具え、
全データの転送要求が終了するまで、上記ステップ（ｃ）（ｄ）（ｅ）（ｆ）（ｇ）を繰り返して実行する
ことを特徴とするデータ再生方法。
【請求項９】
上記ステップ（ｅ）では、
上記記憶手段に一時記憶される圧縮データの圧縮率が低くなった場合には閾値を大きくし、該圧縮率が高くなった場合には閾値を小さくするように変更制御する
ことを特徴とする請求の範囲第８項に記載のデータ再生方法。
【請求項１０】
上記ステップ（ｄ）では、
上記ダウンロードされた圧縮データのファイルのヘッダ、又はフッタに含まれるデータに基づいて、該圧縮データの圧縮率を検出する
ことを特徴とする請求の範囲第９項に記載のデータ再生方法。
【請求項１１】
上記ステップ（ｄ）では、
上記ダウンロードされた圧縮データについてのビットレートデータに基づいて、該圧縮データの圧縮率を検出する
ことを特徴とする請求の範囲第９項に記載のデータ再生方法。
【請求項１２】
上記ステップ（ｅ）では、
上記記憶手段から圧縮データを読み出すタイミングを決める第１の閾値と、上記圧縮データの上記記憶手段へのダウンロードを中断するタイミングを決める第２の閾値とを、それぞれ変更制御する
ことを特徴とする請求の範囲第８項に記載のデータ再生方法。
【請求項１３】
上記ステップ（ｅ）では、
上記通信網の伝送能力に比じて上記閾値を変更制御する
ことを特徴とする請求の範囲第８項に記載のデータ再生方法。
【請求項１４】
上記圧縮データは、ＭＰ３データである
ことを特徴とする請求の範囲第８項に記載のデータ再生方法。
【請求項１５】
通信網を介してダウンロードされた圧縮データを伸張して再生するデータ再生方法を実現するプログラムであって、
（ａ）圧縮データを配信するサーバに接続するステップと、
（ｂ）上記圧縮データのダウンロードに際し、記憶手段に対する上記圧縮データのオーバーフローが発生しない範囲内で上記サーバに対して最大限サイズの部分データの転送を要求するステップと、
（ｃ）上記記憶手段に一時記憶されている圧縮データのデータ容量、及び上記ダウンロードされた圧縮データの圧縮率を検出するステップと、
（ｄ）所定量の圧縮データが格納された時点で再生を開始するステップと、
（ｅ）上記ステップ（ｃ）で検出した圧縮率に応じて上記圧縮データのデータ容量に対する閾値を変更制御するステップと、
（ｆ）上記記憶手段内の未再生の圧縮データが上記閾値以下になったか否かをチェックするステップと、
（ｇ）上記ステップ（ｆ）で上記閾値以下になったと判定された時点で再生を停止するステップと
を具え、
全データの転送要求が終了するまで、上記ステップ（ｃ）（ｄ）（ｅ）（ｆ）（ｇ）を繰り返す処理をコンピュータに実行させる
ことを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】  本発明は、データ再生装置及び方法並びにプログラムに関し、特に、ストリーミング再生されるコンテンツデータのバッファリング閾値を、そのビットレートに応じて変更したデータ再生装置及び方法並びにプログラムに関する。
【背景技術】  ストリーミング再生とは、サーバに対してクライアントがデータの転送を要求し、サーバからデータ全体を受信し終わる前に当該データの再生を開始し、受信と並行して再生を実行する技術である。
プログレッシブネットワークス社（Ｐｒｏｇｒｅｓｓｉｖｅ  Ｎｅｔ−ｗｏｒｋｓ，Ｓｅａｔｔｌｅ，ＷＡ）のリアルオーディオ（商標）、リアルビデオ（商標）、及びリアルプレイヤー（商標）の製品は、現在使用されているデータストリーミング技術の方法の例を提供している。
現在、データの高圧縮手段としては、ＡＴＲＡＣ３（Ａｄａｐｔｉｖｅ  Ｔｒａｎｓｆｏｒｍ  Ａｃｏｕｓｔｉｃ  Ｃｏｄｉｎｇ  ３）（商標）やＭＰ３（ＭＰＥＧ  Ａｕｄｉｏ  Ｌａｙｅｒ  ３）等があり、従来のデータ圧縮形式に比べ遙かに高い圧縮率が実現できる。
ストリーミング再生処理では、ネットワークからのダウンロード処理、ダウンロードデータの端末でのバッファリング処理、バッファリングデータの再生処理に分けて考えることができる。
ネットワークからのダウンロード処理は、ネットワーク状態による不安定さに応じてバッファリングにかかる時間が変化する等の問題があるが、携帯型の情報端末装置では、そのバッファリング方法を工夫して、受信データの再生品質が悪くならないように考えられている。
すなわち、携帯型の情報端末装置では、ネットワークからのダウンロードの不安定さ、バッファリングにかかる時間を示すネットワーク伝送能力をパラメータとして閾値を最適に選ぶことにより、安定した再生品質の確保と楽曲再生の開始時間を最適なものにすることができる。
下記の特許文献１には、情報端末装置による、サーバからのデータのダウンロード及びストリーミング再生に関する発明の記載がある。
ストリーミング再生においては、再生によりデータを消費するデータ速度より、転送されるデータ速度の方が大きくなければ再生が転送に追いついてしまい、再生が停止してしまう。このため、ストリーミング再生では、データ転送速度を大きくとる必要がある。しかし、ストリーミング再生では、逆に転送速度が大きすぎる場合、一度に大きなデータの要求を行い、クライアント側で用意した内部バッファの容量を越えたデータが転送されたとき、バッファのオーバーフローが発生し、そのあふれたデータは欠落データとなってしまう。これを回避するためには、オーバーフローが生じないように、サーバ側に対して、一度にデータの一部分を転送するように要求し、この要求を何度も繰り返して行う必要がある。しかし、ストリーミング再生では、このような高頻度の要求により冗長なヘッダ情報等の比率が増大してデータ転送効率が低下したり、要求からレスポンスまでに遅延が生じたりするおそれがある。また、その結果、ストリーミング再生では、再生が転送に追いついて再生が停止してしまう等のおそれもある。
このような問題は、内部バッファとして利用できるメモリ容量が制限されることの多い携帯型の情報端末装置、また、データ転送速度が変動しやすいインターネットのような通信環境でのデータダウンロードにおいて顕著となる。
図９に、特許文献１におけるストリーミング再生の処理手順の一例を示す。
まず、情報端末装置は、初回の要求サイズを計算する（Ｓ１１）。次いで、情報端末装置は、この計算した要求サイズ分の部分データの転送をサーバに対して要求する（Ｓ１２）。その後、情報端末装置は、データの受信を開始し（Ｓ１３）、所定量（ｄ０）のデータのバッファリング（蓄積）を待って（Ｓ１４）、再生を開始する（Ｓ１５）。この後、情報端末装置は、ダウンロードした全データを再生し終わるまで（Ｓ１６）、以下の処理を継続する。全データの量は、ダウンロード開始前にサーバから通知される情報により予め情報端末装置側で認識できる。
情報端末装置は、続くステップＳ１７で、今回の要求分の部分データをすべて取得したかを判断する。そして情報端末装置は、その部分データをすべて取得するまでは、先のステップＳ１５へ戻る。情報端末装置は、今回の要求分の部分データをすべて取得した後、その時点での要求サイズを計算する（Ｓ１８）。情報端末装置は、サーバにおける未転送の残りのデータがこの要求サイズ以下であれば（Ｓ１９，Ｙｅｓ）、残りのデータ分の転送要求を行う（Ｓ２１）。そうでなければ（Ｓ１９，Ｎｏ）情報端末装置は、バッファ残量（ｂｒ）の大きさをチェックする（Ｓ２０）。情報端末装置は、この残量が閾値より小さくなるまでは、ステップＳ１５へ戻り、再生を継続する。バッファ内の未再生のデータ残量ｂｒが閾値より小さくなるということは、要求サイズＲ１が所定のサイズより大きくなることに相当する。情報端末装置は、ステップＳ２０から戻ったステップＳ１５での処理では、前回の要求分の部分データに対する受信を終了しているので、受信処理を行わない。
情報端末装置は、ステップＳ２０において、バッファ残量が閾値以下となったら、その要求サイズで次の部分データの転送をサーバへ要求する（Ｓ２１）。次いで、情報端末装置は、ステップＳ１５へ戻り、受信と再生を並行して実行する。
このストリーミング再生では、ユーザの要求に対して直ちに再生を開始することができ、ダウンロードしたデータのストリーミング再生に際して、１回のダウンロード時にデータの一部分を逐次サーバに要求する場合に、限られたバッファ容量を有効に用いて、効率的なデータ転送が実現できるという記載がある。
【特許文献１】特開２００２−２１５５１６号公報（段落番号〔００３６〕〜〔００３９〕，図６）。
しかし、圧縮データはその圧縮率に応じて伸張後のデータサイズがそれぞれ異なる大きさになるので、情報端末装置では、バッファリングした圧縮データを伸張する場合、再生データの圧縮率を考慮しないで閾値を決めると、再生品質の保証や、再生開始時間の適正値を保証することができない。
また、圧縮率が異なる楽曲を再生する情報端末装置では、再生を開始するための閾値を特定の圧縮率のものだけに対応させて固定すると、異なる圧縮率で送信されてくる圧縮データから生成する再生データについては、楽曲毎に再生品質、再生開始時間がばらばらになってしまう。
さらに、一般に圧縮データを再生するアプリケーションソフトは、ソフト毎に要求される再生開始時間が異なっているので、再生するデータの圧縮率を考慮しないままに再生品質を保証し、かつメモリリソースを最適化することは困難であった。
【発明の開示】
本発明は、このような状況に鑑みてなされたものであり、ストリーミング再生されるデータの圧縮率に応じて、バッファリングする記憶装置の閾値を動的に決定することにより、メモリリソース最適化を図ったデータ再生装置及び方法並びにプログラムを提供することを目的としている。
前記課題を解決するために、本発明のデータ再生装置は、通信網を介してダウンロードされた圧縮データを伸張して再生するデータ再生装置において、前記ダウンロードされた圧縮データを一時的に記憶する記憶手段と、前記記憶手段で記憶している圧縮データを伸張するデータ伸張手段と、前記データ伸張手段で伸張されたデータのストリーミング再生を行う再生手段と、前記記憶手段に一時記憶されている圧縮データのデータ容量、及び前記ダウンロードされた圧縮データの圧縮率を検出する検出手段と、前記検出手段で検出した圧縮率に応じて前記圧縮データのデータ容量に対する閾値を変更制御すると共に、前記記憶手段に一時記憶されているデータ容量が所定の閾値以上になったとき前記記憶手段から前記圧縮データを読み出して、前記データ伸張手段に転送する制御手段とを備えている。
また、本発明に係るデータ再生方法は、通信網を介してダウンロードされた圧縮データを伸張して再生するデータ再生方法であって、
（ａ）圧縮データを配信するサーバに接続するステップと、
（ｂ）前記圧縮データのダウンロードに際し、記憶手段に対する前記圧縮データのオーバーフローが発生しない範囲内で前記サーバに対して最大限サイズの部分データの転送を要求するステップと、
（ｃ）所定量の圧縮データが格納された時点で再生を開始するステップと、
（ｄ）前記記憶手段に一時記憶されている圧縮データのデータ容量、及び前記受信した圧縮データの圧縮率を検出するステップと、
（ｅ）前記ステップ（ｄ）で検出した圧縮率に応じて前記圧縮データのデータ容量に対する閾値を変更制御するステップと、
（ｆ）前記記憶手段内の未再生の圧縮データが前記閾値以下になったか否かをチェックするステップと、
（ｇ）前記ステップ（ｆ）で前記閾値以下になったと判定された時点で再生を停止するステップと
を備え、全データの転送要求が終了するまで、前記ステップ（ｃ）（ｄ）（ｅ）（ｆ）（ｇ）を繰り返して実行することを特徴とする。
本発明のデータ再生装置及び方法並びにプログラムでは、サーバ側から提供されるコンテンツをストリーミング再生するとき、圧縮データとして転送されたコンテンツのビットレートに応じて、記憶手段に一時記憶すべきデータ容量の閾値を変更設定し、これによって再生音楽の途切れ等を確実に防止できる。
また、データ再生装置及び方法並びにプログラムでは、ビットレートに対するバッファリングの閾値を選ぶことで、再生品質を保証し、かつ再生品質を調整することができる。
【図面の簡単な説明】  図１は、本実施の形態のデータ再生装置がクライアント端末として適用される情報提供システムの全体構成を示す図である。
図２は、本実施の形態のデータ再生装置の回路構成を示すブロック図である。
図３は、ストリーミングデータ再生処理の概念図である。
図４は、本実施の形態のデータ再生装置における圧縮データの再生シーケンスを示すフローチャートである。
図５は、本実施の形態のデータ再生装置のプログラムモジュールを示す図である。
図６は、ビットレートが異なる圧縮データから再生されるディジタルデータの分量を示す図である。
図７は、ビットレートが異なる圧縮データから再生されるディジタルデータの分量を示す図である。
図８は、ビットレートが異なる圧縮データから再生されるディジタルデータの分量を示す図である。
図９は、従来のストリーミング再生の処理手順の一例を示すフローチャートである。
【符号の説明】
４……ネットワーク、５……サーバ、１０……クライアント端末、１１……ＣＰＵ、１４……ＲＡＭ、１３……ＨＤＤ、１９……オーディオデータ処理部、ＲＳ……ラジオ局、２０……インターネット、３０……ＵＲＬ提供サーバ、１００……情報提供システム
【発明を実施するための最良の形態】  以下、ストリーミング再生されるデータの圧縮率に応じて、バッファリングする記憶装置の閾値を動的に決定することにより、メモリリソース最適化を図るという目的を実現するデータ再生装置の最良の形態について説明する。
図１は、本実施の形態の情報再生装置をクライアント端末として適用可能な情報提供システムの全体構成を示す図である。
この図１に示すように、１００は全体として情報提供システムを示し、クライアント端末１０はラジオ局ＲＳからの放送を受信する。
この情報提供システム１００では、ラジオ局ＲＳと専用線接続されたコンピュータ構成の関連情報提供サーバＫＳが、ラジオ局ＲＳに代わって当該ラジオ局ＲＳのホームページを開設している。この関連情報提供サーバＫＳは、クライアント端末１０からの取得要求に応じて、ラジオ局ＲＳで放送した楽曲に関連する楽曲情報を関連情報としてインターネット２０等のネットワークを介して提供し得るように構成されている。
情報提供システム１００の関連情報提供サーバＫＳは、そのホームページ等を介してインターネット２０上で行っている情報提供サービスのアクセス先を示すＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）情報をコンピュータ構成のＵＲＬ提供サーバ３０へ通知する。この情報提供サービスには、ユーザからの要望に応じて、後述する楽曲データを圧縮データとして提供するサービスを含んでいる。
ＵＲＬ提供サーバ３０は、情報提供サービスのアクセス先アドレスを示すＵＲＬの変更があった場合でも、関連情報提供サーバＫＳからの通知によって変更後のＵＲＬを管理している。従ってＵＲＬ提供サーバ３０は、クライアント端末１０からラジオ局ＲＳの情報提供サービスへのアクセス先の問い合わせに対して最新のＵＲＬを常時提供し得る。
なお、ラジオ放送では受信可能な地域が制限されるために、同じ周波数を複数の地域で共通に用いている場合がある。例えば８０．０〔ＭＨｚ〕の周波数は、首都圏ではＦＭ東京が使用しており、東北地方ではＦＭ青森が使用している。
すなわち、クライアント端末１０では、ＵＲＬ提供サーバ３０に対して周波数を特定しただけではラジオ局ＲＳを特定したことにはならず、当該ラジオ局ＲＳを特定するためのコールサインと呼ばれる固有の情報をＵＲＬ提供サーバ３０へ通知する。これによりクライアント端末１０は、ラジオ局ＲＳの情報提供サービスに対するアクセス先を示すＵＲＬをＵＲＬ提供サーバ３０から間違いなく受け取ることができる。
図２は、本実施の形態のデータ再生装置の回路構成を示すブロック図である。
本実施の形態に係るデータ再生装置では、ストリーミング再生されるコンテンツのビットレートに応じて、バッファリングデータとして蓄積するための圧縮データの閾値を変更できる点に特徴がある。
図２において、携帯型の情報端末装置を構成するクライアント端末１０は、ＣＰＵ１１、プログラムを格納するためのフラッシュＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１２、所定の閾値が設定されたハードディスクドライブ（ＨＤＤ）１３、プログラム実行のためのプログラム展開用のＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１４、ネットワークに接続するためのネットワークデバイス１５、バス１６等から構成されている。
ＣＰＵ１１は、バス１６を介して接続されたフラッシュＲＯＭ１２から読み出してＲＡＭ１４に展開したＯＳ等の基本プログラム、及び各種アプリケーションプログラムに基づいて全体の制御や所定の演算処理等を行う制御手段であって、例えばネットワーク４を介した通信動作、ユーザからの入出力操作、メディアからのコンテンツ再生やラジオ局ＲＳからダウンロードしたコンテンツの書き込み、及びＨＤＤ１３の管理等を実行する。
ＨＤＤ１３では、そこに格納された圧縮データをストリーミング再生する際に、一時記憶されているデータ容量に対して所定の閾値が設定されている。そしてＨＤＤ１３は、インタフェース１３ａ、バス１６を介してＣＰＵ１１と接続されている。
ネットワークデバイス１５は、インタフェース１５ａを介してバス１６と接続され、ＣＰＵ１１の制御に基づいて送信データのエンコード処理を行い、ネットワーク４経由で外部のネットワーク対応機器へ送信し、あるいは外部のネットワーク対応機器から受信した受信データのデコード処理を行い、ＣＰＵ１１へ転送する。ＣＰＵ１１は、サーバ５のページ内のデータにより、あらかじめ圧縮データのビットレートを取得するか、あるいは転送されたコンテンツデータのヘッダ情報、タグ情報に含まれるビットレートデータを読み取って、ダウンロードに先立って圧縮データの圧縮率を検出できる。
ディスプレイ１７は、例えば液晶ディスプレイ等の表示デバイスがクライアント端末１０の本体部筐体の表面に直接取り付けられている場合や、外付けの表示デバイスであってもよく、ＣＰＵ１１による処理結果や各種情報を表示できる。
メディアドライブ１８は、例えばＣＤ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ）プレーヤ及びフラッシュメモリ等でなるメモリスティック（登録商標）を再生するドライブである。メディアドライブ１８による再生結果は、オーディオデータ処理部１９を介してディジタルアナログ変換処理された後に、２ｃｈのスピーカＳＰから出力される。
ＣＰＵ１１は、メディアドライブ１８を介して再生したデータが楽曲のオーディオコンテンツである場合、オーディオデータファイルとしてＨＤＤ１３に記憶する。
ＣＰＵ１１は、メディアドライブ１８により、メモリスティックに記憶された複数枚の静止画を読み出して、これらをディスプレイ１７にスライドショーとして表示することができる。また、ＣＰＵ１１は、ＨＤＤ１３に記憶した複数の楽曲をランダムアクセスで読み出し、あたかもジュークボックスのようにユーザ所望の順番で再生して出力することも可能である。
このＣＰＵ１１には、バス１６を介して例えばＡＭ、ＦＭラジオチューナ等のチューナ部２１も接続されている。このチューナ部２１は、ＣＰＵ１１の制御に基づいて、受信した放送信号を復調し、その結果を放送音声としてオーディオデータ処理部１９を介してスピーカＳＰから出力する。
オーディオデータ処理部１９では、本実施の形態では、高能率符号化方式の一種であるＭＰ３（ＭＰＥＧ  Ａｕｄｉｏ  Ｌａｙｅｒ  ３）の利用を想定している。また、インターネットとのデータの授受は、ＴＣＰ／ＩＰプロトコルの利用を想定している。しかし、本発明は特にこれらに限られるものではなく、音楽データ圧縮方式、デコード手段の構成及び通信プロトコル等の如何は問わない。例えば、高能率符号化の方式は、ＭＰ３に限らず、ＡＴＲＡＣ３（Ａｄａｐｔ−ｉｖｅ  Ｔｒａｎｓｆｏｒｍ  Ａｃｏｕｓｔｉｃ  Ｃｏｄｉｎｇ  ３）、ＡＡＣ（Ａｄｖａｎｃｅｄ  Ａｕｄｉｏ  Ｃｏｄｉｎｇ）、ＷＭＡ（Ｗｉｎｄｏｗｓ    Ｍｅｄｉａ  Ａｕｄｉｏ）、ＲｅａｌＡＵＤＩＯ  Ｇ２  Ｍｕｓｉｃ  Ｃｏｄｅｃ等でもかまわない。このようなデータ再生装置自体の構成は既知のものでよく、本発明の特徴部分はＣＰＵ１１の新規なストリーミング再生処理、及びそれを実現するコンピュータプログラムにある。
このようなハードウェア構成のクライアント端末１０により、ストリーミングデータを再生できる。
図３は、ストリーミングデータの再生処理の概念図である。図３の例では、ＭＰ３形式の圧縮データをＰＣＭ（パルス符号変調データ）データに伸張し、再生するものとする。
クライアント端末１０では、ＨＤＤ１３内に、ＭＰ３データ記憶領域１３ｂが確保される。また、ＲＡＭ１４内には、ＰＣＭデータ記憶領域１４ａが確保される。
さらに、ＲＡＭ１４内には、第１の閾値Ｔ１と第２の閾値Ｔ２とが格納される。ストリーミングデータのダウンロード開始前は、第１の閾値Ｔ１と第２の閾値Ｔ２とには、予め定義された初期値が設定される。
ストリーミングデータは、ストリーミング制御部１０ａによって制御される。ストリーミング制御部１０ａは、ＣＰＵ１１がネットワークデバイス１５やインタフェース１５ａを制御することで実現する機能である。
ストリーミング制御部１０ａは、サーバ５からＭＰ３のストリーミングデータを取得し、ＭＰ３データ記憶領域１３ｂに蓄積していく。このとき、ストリーミング制御部１０ａは、取得したストリーミングデータのヘッダ情報に含まれるビットレート（１秒間の音楽データをどのくらいのディジタルデータに変換するか）の情報から圧縮率を判断する。ストリーミング制御部１０ａは、例えば、ビットレートが高ければ圧縮率が低く、逆にビットレートが低ければ圧縮率が高いと判断できる。また、ストリーミング制御部１０ａは、ネットワーク４を介したデータの転送速度からネットワーク４の負荷を判断する。
そして、ストリーミング制御部１０ａは、ストリーミングデータの圧縮率及びネットワーク４の負荷に応じて、第１の閾値Ｔ１及び第２の閾値Ｔ２の値を変更する。具体的には、圧縮率が低いほど第１の閾値Ｔ１及び第２の閾値Ｔ２の値は大きくなる。また、ネットワーク４の負荷が大きい（転送速度が遅い）ほど、第１の閾値Ｔ１及び第２の閾値Ｔ２の値は大きくなる。
なお、ストリーミング制御部１０ａは、ＭＰ３データ記憶領域１３ｂに蓄積されたデータ量を監視しており、そのデータ量が第２の閾値Ｔ２を超えた場合、ＭＰ３データのストリーミングによる取得を中断する。その後、ＭＰ３データ記憶領域１３ｂ内に蓄積されたデータ量が、第２の閾値Ｔ２以下になると、ストリーミング制御部１０ａは、ＭＰ３データのストリーミングによる取得を再開する。
ＭＰ３データ記憶領域１３ｂに蓄積されたＭＰ３データは、デコーダ１０ｂにより伸張（デコード）され、ＰＣＭデータとしてＰＣＭデータ記憶領域１４ａに格納される。なお、デコーダ１０ｂは、ＭＰ３データ記憶領域１３ｂ内に蓄積されたデータ量が、第１の閾値Ｔ１を超えたときに、ＭＰ３データのデコードを開始する。デコードされたＭＰ３データは、ＭＰ３データ記憶領域１３ｂから削除される。その後、ＭＰ３データ記憶領域１３ｂ内に蓄積されたデータ量が、第１の閾値Ｔ１以下になると、デコーダ１０ｂは、ＭＰ３データのデコードを中断する。
ＰＣＭデータ記憶領域１４ａに蓄えられたＰＣＭデータは、オーディオデータ処理部１９で順次再生され、スピーカＳＰから出力される。
次に、上述したクライアント端末１０におけるストリーミング再生の処理手順の一例について説明する。
図４は、本実施の形態に係るデータ再生装置における圧縮データの再生シーケンスを示すフローチャートである。
最初に、視聴者は例えば所望する音楽を特定して、クライアント端末１０をその音楽情報を提供する音楽配信用のサーバ５に接続する（Ｓ１）。次に、クライアント端末１０のＣＰＵ１１は、圧縮データとして音楽データをサーバ５からダウンロードするとき、ＨＤＤ１３において圧縮データのオーバーフローが発生しない範囲内で、サーバ５に対して最大限サイズの部分データの転送を要求する（Ｓ２）。その後、ＣＰＵ１１は、データの受信を開始し、所定量の圧縮データのバッファリング（蓄積）を待って、受信と並行して音楽の再生（伸張）を開始する（Ｓ３）。
次に、ＣＰＵ１１は、ダウンロードすべき音楽情報の全データを再生したかどうかを判断する（Ｓ４）。その結果、ＣＰＵ１１は、再生が終了していないときには、ＨＤＤ１３に一時記憶している圧縮データのデータ容量、及び受信した圧縮データの圧縮率を検出する（Ｓ５）。
ＣＰＵ１１は、ステップＳ５で、受信した圧縮データのファイルのヘッダ、又はフッタに含まれるデータに基づいて、その圧縮率を検出することができる。また、ＣＰＵ１１は、このステップＳ５では、受信した圧縮データについてのビットレートデータに基づいて、その圧縮率を検出することもできる。
次に、ＣＰＵ１１は、ステップＳ５で検出した圧縮率に応じて、格納した圧縮データのデータ容量に対する閾値を設定し、必要に応じて変更するように制御する（Ｓ６）。
ＣＰＵ１１は、このステップＳ６で、ＨＤＤ１３に一時記憶する圧縮データの圧縮率が低くなった場合に閾値を大きくし、その圧縮率が高くなった場合に閾値を小さくするように変更制御する。
次に、ＣＰＵ１１は、ＨＤＤ１３内における未再生の圧縮データの残量が、設定された閾値以下になったか否かをチェックする（Ｓ７）。ここで、ＣＰＵ１１は、圧縮データの残量が閾値以下になったと判定したとき、一時的に再生を停止し（Ｓ８）、再びステップＳ７に戻る。そして、この間もクライアント端末１０での圧縮データのダウンロードは継続している。従って、ＣＰＵ１１は、いずれステップＳ７で圧縮データの残量が、設定された閾値以上になったと判断し、その時点でステップＳ３に戻ってデータの再生を再開し、上述した各ステップＳ４〜Ｓ８を繰り返して実行する。なお、ＣＰＵ１１は、全データを再生し終わった時点で、再生を終了する（Ｓ９）。
ＣＰＵ１１は、ステップＳ８で、圧縮データの残量が閾値以下になったときでも、即時に再生を停止しないで、所定のタイミングまで再生を継続することができる。これによりＣＰＵ１１は、音切れ間隔を調整することが可能になるから、音切れによる再生品質の低下を抑制できる。
また、ＣＰＵ１１は、ステップＳ６で、最初にＨＤＤ１３から圧縮データを読み出すタイミングを決める第１の閾値Ｔ１とは別に、ＨＤＤ１３へのダウンロードを中断するタイミングを決める第２の閾値Ｔ２を設定し、それぞれを変更制御するようにしている。
閾値Ｔ１は、ネットワークのパフォーマンス（通信網の伝送能力）をＮ、圧縮率をＢ、バイト数に変換するための係数をＲとするとき、
Ｔ１＝Ｎ×Ｂ×Ｒ
Ｔ２＝２Ｎ×Ｂ×Ｒ
のように表現できる。
ここで、パフォーマンスＮは、その最高値を１（最良の場合）、最低値を２（最悪の場合）とする係数である。また、圧縮率Ｂは、コンテンツのビットレート（６４〔Ｋｂｐｓ〕であれば「６４」、１２８〔Ｋｂｐｓ〕であれば「１２８」）とするものである。このように、閾値は圧縮率Ｂだけでなく、使用している通信網の伝送能力に応じて変更制御することが好ましい。これはネットワーク状態が悪くなった場合に、圧縮データの受信速度が再生速度より低下するおそれがあるからである。なお、ＣＰＵ１１による閾値Ｔ１，Ｔ２の変更制御については、閾値設定テーブルによって行うことも可能である。
このように、ネットワークからのダウンロードはネットワーク状態による不安定さ、バッファリングにかかる時間が必要なので、端末バッファリングを工夫し再生品質が悪くならないようにされている。情報端末装置は、ネットワーク状態の不安定さ、バッファリングにかかる時間を吸収できる程度のバッファ量を、予め閾値Ｔ１として定めておくことができる。そして、情報端末装置は、圧縮データのデータ残量が閾値Ｔ１を超えた時点で再生を開始し（Ｓ３）、閾値Ｔ２を超えた場合に再生は継続しつつ、ネットワークからのダウンロードを一時中断して、その後、データ残量が閾値Ｔ２を下回った場合にネットワークからのダウンロードを再開し（Ｓ３）、さらに閾値Ｔ１を下回った時点で再生を一時停止する（Ｓ８）。情報端末装置は、このストリーミング再生によりネットワークからのダウンロードの不安定さの過敏な入力要因に対してバッファで吸収し、不快な音途切れを防止することができる。
図５は、本実施の形態のデータ再生装置のプログラムモジュールを示す図である。
クライアント端末１０の端末内プログラム構成は、ネットワーク通信を司るコミュニケーションモジュール（Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｍｏｄｕｌｅ）３１、コンテンツデータの圧縮形式やデータサイズを判断してデータ形式を変換するプレイヤエンジン３２、コンテンツデータを蓄積したデータベースモジュール３３、及び表示画像や効果音の再生等、実際の再生制御を行うプレイヤモジュール３４からなるミドルウエアと、ウェッブページの画面遷移を行い、ウェッブページの画像表示や効果音の再生を司るユーザインタフェイスとしてブラウザ３５を備えている。
図５に示すコミュニケーションモジュール３１が、図３のストリーミング制御部１０ａの機能を有している。また、図５に示すプレイヤエンジン３２が、図３のデコーダ１０ｂの機能を有している。
図６〜図８は、ビットレートが異なる圧縮データから再生されるディジタルデータの分量を示す図である。ここでは、送信側から伝送される圧縮データとして、ＭＰ３圧縮方式による１２８〔Ｋｂｐｓ〕の高ビットレートのデータと、６４〔Ｋｂｐｓ〕の低ビットレートのデータとが存在するものと想定し、それらを伸張処理して元の音楽データに復元することによって、ＰＣＭデータが得られるものとしている。
ＭＰ３圧縮方式では、１秒あたりの情報量をビットレートとして表しており、ＩＰ３ファイルでは１２８〔Ｋｂｐｓ〕が一般的なビットレートである。圧縮データのビットレートが大きいということは、データ伝送時の圧縮率は低くなるが、解凍されたときの音声データの再生音質が高いことを意味している。ＩＰ３ファイルに付属するＩＤ３Ｔａｇには、前述した圧縮率やサンプリング周波数を始め、楽曲のタイトル、アーティスト名、音楽ジャンル等の文字情報を自由に書込むことができる。
図６に示すように、ビットレートが異なる圧縮データから同程度の、例えば４分間の再生時間を有するＰＣＭデータを取得するには、ビットレートの低いコンテンツ（６４〔Ｋｂｐｓ〕）と比べると、ビットレートの高いコンテンツ（１２８〔Ｋｂｐｓ〕）の圧縮データを格納するために、より大きなサイズの記憶容量が必要である。ここでは、図６（ａ）に示すビットレート６４〔Ｋｂｐｓ〕の圧縮データに対して、同図（ｂ）に示すビットレート１２８〔Ｋｂｐｓ〕のものを格納するために、２倍の記憶容量のバッファメモリを要している。
従って、バッファメモリに格納される圧縮データのビットレートにかかわらず、圧縮データのデータ容量に対する閾値を一定とした場合、図７に示すように、ビットレートの高いコンテンツ（１２８〔Ｋｂｐｓ〕）から復元される音楽データのＰＣＭサイズのほうが小さくなることは明らかである。すなわち、図７（ａ）に示すビットレート６４〔Ｋｂｐｓ〕の圧縮データから４分間のＰＣＭデータが得られ、これを最適な量としたときでも、同図（ｂ）に示すビットレート１２８〔Ｋｂｐｓ〕のものについては、その閾値を同じ値としたままでは１／２（２分間）のＰＣＭデータしか得られない。ストリーミング再生では、バッファされるＰＣＭデータにデータ不足が生じれば、音途切れの間隔が短くなり再生品質が悪くなる。
反対に、ビットレート１２８〔Ｋｂｐｓ〕のものについての閾値を、図８（ｂ）に示すように４分間のＰＣＭデータが得られるように高く設定すれば、同じ閾値でビットレートの低いコンテンツ（６４〔Ｋｂｐｓ〕）を格納した場合には、２倍（８分間）のＰＣＭデータが再生できることになる。このようなＰＣＭデータにデータ過多が生じると、バッファメモリでは必要以上にデータを保持することになり、情報端末装置におけるリソースの無駄となる。
本実施の形態のデータ再生方法では、配信される圧縮データのビットレートに応じて、バッファメモリにおける閾値を変更設定することにより、メモリリソースを最適化しつつ、その再生品質を保証することができる。
また、データ再生方法では、情報端末装置のメモリ使用量を制限する必要があり、かつユーザがそれ程高音質のものを要求していない場合、圧縮データとして低ビットレート（高圧縮率）のものを選択することができる。その場合データ再生方法では、閾値を低く取ることができる。一方、データ再生方法では、メモリ使用量の制限が少ない情報端末装置の場合であって、かつユーザが高い音質を求めている場合、圧縮データとして高ビットレート（低圧縮率）のものを選ぶことができる。その場合データ再生方法では、バッファメモリにおける閾値を、高く取るようにする。
このようにデータ再生方法では、圧縮データのビットレートに応じて、バッファリングの際の閾値を選ぶようにしたので、再生データのデータ枯渇による音切れ間隔を適切に調整することができ、再生品質の保証を行うことができる。
また、データ再生方法では、受信する圧縮データの対応ビットレートや、それらをバッファするメモリサイズ等の情報端末装置の要件に合わせて、適切な閾値を選ぶことができ、ＲＡＭサイズ等のメモリリソースの最適化を行うことができる。
なお上述の実施の形態においては、クライアント端末１０が受信可能な放送としてラジオ局から放送されるラジオ放送を適用したが、これに限らず、クライアント端末１０がインターネットラジオ放送や衛星ラジオ放送を受信して、その関連情報及びラジオ放送情報を取得するようにしたり、あるいはテレビジョン用の放送局から放送されるテレビジョン放送を受信し、そのテレビジョン放送のテレビジョン番組に関する各種放送情報等をインターネット２０等のネットワーク上のサーバから取得することも可能である。
また上述の実施の形態においては、音声（オーディオデータ）のストリーミング再生に関して本発明を適用したが、本発明はこれに限らず、映画やテレビジョン放送等のビデオデータ、コンピュータグラフィックスデータであるゲームデータ等、ストリーミング再生可能なデータであれば、この他種々のデータのストリーミング再生に関して本発明を適用することが可能である。
さらに上述の実施の形態においては、本発明によるデータ再生装置をクライアント端末１０に適用するようにした場合について述べたが、本発明はこれに限らず、パーソナルコンピュータや携帯電話機、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｃｅ）、ゲーム機器等の情報処理装置、テレビジョン受像機、ラジオ放送受信機、ＣＤプレーヤ、ＤＶＤ（Ｄｉｇｉ−ｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）プレーヤ、ハードディスクプレーヤ等のように、この他種々のデータ再生装置に広く適用することができる。
すなわち、上述の実施の形態においては、図２について上述したハードウェア回路ブロックや図５について上述したプログラムモジュールをクライアント端末１０に実装した場合について述べたが、本発明はこれに限らず、これらを携帯電話機やパーソナルコンピュータ等、クライアント端末１０以外の種々の端末に実装するようにしてもよく、これらハードウェア回路ブロックやプログラムモジュールを実装した端末であれば、上述したクライアント端末１０と同様の処理を実現することができる。
さらに、上記の処理機能は、コンピュータによっても実現することができる。その場合、コンピュータにはクライアント端末１０が有すべき機能の処理内容を記述したプログラムが提供される。コンピュータは、そのプログラムを実行することにより、上記処理機能を実現する。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。コンピュータで読み取り可能な記録媒体としては、磁気記録装置、光ディスク、光磁気記録媒体、半導体メモリ等がある。磁気記録装置には、ハードディスク装置（ＨＤＤ）、フレキシブルディスク（ＦＤ）、磁気テープ等がある。光ディスクには、ＤＶＤ、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ（Ｒｅｃｏｒｄａｂｌｅ）／ＲＷ（ＲｅＷｒｉｔａｂｌｅ）等がある。光磁気記録媒体には、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ  ｄｉｓｋ）等がある。
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ、ＣＤ−ＲＯＭ等の可搬型記録媒体が販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送される毎に、逐次、受け取ったプログラムに従った処理を実行することもできる。
さらに上述の実施の形態においては、本発明によるプログラムを図５について上述したプログラムモジュールに適用するようにした場合について述べたが、本発明はこれに限らず、この他種々の構成のプログラムを適用することができる。
さらに上述の実施の形態においては、ダウンロードされた圧縮データを一時的に記憶する記憶手段として、図１乃至図８について上述したＨＤＤ（ハードディスクドライブ）１３を適用するようにした場合について述べたが、本発明はこれに限らず、ダウンロードされた圧縮データを一時記憶することができれば、光磁気ディスク等のディスク状記録媒体や半導体メモリ等の記憶媒体にデータを記憶するハードウェア回路構成のドライブ回路や、各種プログラム（すなわち、ソフトウェア）に従って記憶媒体にデータを記憶するＣＰＵ等のように、この他種々の記憶手段を広く適用することができる。
さらに上述の実施の形態においては、記憶手段で記憶している圧縮データを伸張するデータ伸張手段として、図１乃至図８について上述したＣＰＵ１１を適用するようにした場合について述べたが、本発明はこれに限らず、圧縮データを伸張することができれば、圧縮データを伸張するハードウェア回路構成のデータ伸張回路や、各種プログラム（すなわち、ソフトウェア）に従って圧縮データを伸張するマイクロコンピュータ等のように、この他種々のデータ伸張手段を広く適用することができる。
さらに上述の実施の形態においては、データ伸張手段で伸張されたデータのストリーミング再生を行う再生手段として、図１乃至図８について上述したＣＰＵ１１、ＲＡＭ１４及びオーディオデータ処理部１９を適用するようにした場合について述べたが、本発明はこれに限らず、データのストリーミング再生を行うことができれば、データをストリーミング再生するハードウェア回路構成の再生回路や、各種プログラム（すなわち、ソフトウェア）に従ってデータをストリーミング再生するＣＰＵ単体等のように、この他種々の再生手段を広く適用することができる。
さらに上述の実施の形態においては、記憶手段に一時記憶されている圧縮データのデータ容量、及びダウンロードされた圧縮データの圧縮率を検出する検出手段として、図１乃至図８について上述したＣＰＵ１１を適用するようにした場合について述べたが、本発明はこれに限らず、圧縮データのデータ容量及び圧縮率を検出することができれば、圧縮データのデータ容量及び圧縮率を検出するハードウェア回路構成の検出回路や、各種プログラム（すなわち、ソフトウェア）に従って圧縮データのデータ容量及び圧縮率を検出するマイクロコンピュータ等のように、この他種々の検出手段を広く適用することができる。
さらに上述の実施の形態においては、検出手段で検出した圧縮率に応じて圧縮データのデータ容量に対する閾値を変更制御すると共に、記憶手段に一時記憶されているデータ容量が所定の閾値以上になったとき記憶手段から圧縮データを読み出して、データ伸張手段に転送する制御手段として、図１乃至図８について上述したＣＰＵ１１を適用するようにした場合について述べたが、本発明はこれに限らず、検出手段で検出した圧縮率に応じて圧縮データのデータ容量に対する閾値を変更制御すると共に、記憶手段に一時記憶されているデータ容量が所定の閾値以上になったとき記憶手段から圧縮データを読み出して、データ伸張手段に転送することができれば、ハードウェア回路構成の制御回路や、各種プログラム（すなわち、ソフトウェア）に従って動作するマイクロコンピュータ等のように、この他種々の制御手段を広く適用することができる。
【産業上の利用可能性】  ネットワークに接続されたオーディオ／ビジュアル機器等に対して、インターネット等のブロードバンドから音楽、ビデオや画像その他の関連情報を直接配信するコンテンツ配信システム等に利用できる。
【図１】
2005034089.tif 000003
【図２】
2005034089.tif 000004
【図３】
2005034089.tif 000005
【図４】
2005034089.tif 000006
【図５】
2005034089.tif 000007
【図６】
2005034089.tif 000008
【図７】
2005034089.tif 000009
【図８】
2005034089.tif 000010
【図９】
2005034089.tif 000011
【国際調査報告】
2005034089.tif 000012
2005034089.tif 000013
2005034089.tif 000014
2005034089.tif 000015