WO2014073202A1

WO2014073202A1 - 情報処理装置、情報処理方法、コンテンツ配信システム及びコンピュータプログラム記録媒体

Info

Publication number: WO2014073202A1
Application number: PCT/JP2013/006526
Authority: WO
Inventors: 浩三里田
Original assignee: 日本電気株式会社
Priority date: 2012-11-08
Filing date: 2013-11-06
Publication date: 2014-05-15

Abstract

コンテンツのビットレートが予めわからない状態であっても、ダウンロード後に廃棄されるマルチメディアデータを削減することができる情報処理装置などが開示される。係る情報処理装置は、端末からの配信要求に応じて、マルチメディアファイルを配信する配信サーバから受信したマルチメディアデータを一時的に保存する一時保存手段と、前記一時保存手段に保存されたマルチメディアデータに該マルチメディアデータのビットレートを算出する際に用いる情報が含まれているか否かを検出するヘッダ検出手段と、前記ヘッダ検出手段が検出した前記情報に基づいて前記マルチメディアデータのビットレートを算出するレート算出手段と、前記レート算出手段によって算出されたビットレートに基づいて前記一時保存手段から前記マルチメディアデータを読み出して前記端末に送信するデータ送信手段と、を備える。

Description

情報処理装置、情報処理方法、コンテンツ配信システム及びコンピュータプログラム記録媒体

　本発明は、コンテンツ配信における通信データ量を制御する技術に関する。

　近年、インターネットの高速化に伴い、映像や音声等のマルチメディアデータからなるコンテンツを、インターネットに通信可能に接続されたサーバからストリーミングしながら視聴するユーザが増加している。特に、モバイル網の高速化及びスマートフォン等のモバイル端末の高性能化、高機能化に伴い、モバイル網を利用したマルチメディアコンテンツのストリーミング視聴が急激に増加している。マルチメディアデータは、Ｗｅｂで利用されるテキストデータや画像データと比較してデータ量が大きく、現在ではモバイル網における全トラフィックのうち、半分以上をマルチメディアデータのストリーミングトラフィックが占めるといわれている。

　マルチメディアデータのストリーミングでは、通信プロトコルとして、ＵＤＰ（Ｕｓｅｒ　Ｄａｔａｇｒａｍ　Ｐｒｏｔｏｃｏｌ）におけるＲＴＰ（Ｒｅａｌｔｉｍｅ　Ｔｒａｎｓｐｏｒｔ　Ｐｒｏｔｏｃｏｌ）を利用して、映像や音声データを配信していた。しかし、現在、インターネットを用いたほとんどのストリーミングサービスは、マルチメディアデータの通信プロトコルとして、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ　Ｃｏｎｔｒｏｌ　Ｐｒｏｔｏｃｏｌ）におけるＨＴＴＰ（Ｈｙｐｅｒ　Ｔｅｘｔ　Ｔｒａｎｓｐｏｒｔ　Ｐｒｏｔｏｃｏｌ）を利用している。ＨＴＴＰを利用することにより、マルチメディアデータのロスがなく映像や音声の乱れがない、ＮＡＴ（Ｎｅｔｗｏｒｋ　Ａｄｄｒｅｓｓ　Ｔｒａｎｓｌａｔｉｏｎ）やファイアウォールの通過が容易、既存のＷｅｂインフラ（Ｗｅｂサーバ、プロキシサーバ等）を利用できる、等メリットがある。

　ＨＴＴＰを利用したマルチメディアデータのストリーミングには、プログレッシブダウンロード方式が多く用いられる。プログレッシブダウンロード方式では、ＨＴＴＰを利用することにより、サーバから、コンテンツを表すマルチメディアファイルをダウンロードする。プログレッシブダウンロード方式では、マルチメディアファイルを構成する全てのマルチメディアデータがダウンロードされるまで待つのではなく、再生に必要な量のマルチメディアデータのダウンロードが完了した時点で、マルチメディアデータの再生を開始する。プログレッシブダウンロード方式では、再生中もマルチメディアデータのダウンロードは継続する。プログレッシブダウンロード方式では、ダウンロード済みのデータを、端末が備える再生バッファに蓄積すると共に、再生バッファに蓄積済みのデータを逐次読み出しながら再生を行う。プログレッシブダウンロード方式では、ダウンロードが間に合わず、再生時に再生バッファに蓄積されたマルチメディアデータがない場合は、再生するデータが用意できないため、再生が停止してしまう。これにより、ユーザの体感品質を大きく損ねてしまう。

　このため、ＨＴＴＰを利用するプログレッシブダウンロード方式では、端末のバッファ量が０にならないように、マルチメディアデータをバースト的にダウンロードする。これにより、ＨＴＴＰを利用するプログレッシブダウンロード方式では、端末が備える再生バッファにできるだけ多くのダウンロード済みマルチメディアデータを蓄積する。しかしながら、多くのマルチメディアデータを蓄積することが、大きな問題となってきている。インターネットを利用するストリーミングサービスでは、コンテンツを最初から最後まで視聴するユーザは少なく、途中で視聴をやめるユーザが多い。ユーザが途中で視聴をやめると、端末が備える再生バッファに蓄積されたマルチメディアデータは、ユーザに視聴（利用）されることなく捨てられる。特に、モバイル網においては、マルチメディアデータのトラフィックが半分を占めるにも関わらず、ダウンロード後に廃棄される可能性の高いデータを送信することは、限りある無線リソースの利用効率を低下させる。

　このため、端末が備える再生バッファにマルチメディアデータを蓄積し過ぎず、コンテンツ視聴を取りやめた場合においても、利用されずに捨てられるマルチメディアデータを少なくするビデオページング技術が注目されている。

　例えば、特許文献１は、コンテンツ配信システムを開示する。このコンテンツ配信システムは、マルチメディアファイル再生時の単位時間当たりのデータ量であるビットレートをメタ情報として管理する。そして、このコンテンツ配信システムは、配信サーバからマルチメディアコンテンツを配信する場合、コンテンツのビットレートを元にダウンロードレートを決定し、決定したダウンロードレートに基づいて、マルチメディアデータを送信する。

　特許文献２は、マルチメディアデータを構成するＴＳ（Ｔｒａｎｓｐｏｒｔ　Ｓｔｒｅａｍ）からタイムスタンプを抽出することにより、コンテンツのビットレートを計算し、適切なビットレートによってコンテンツを再送信する再送信装置を開示する。

特開２００６－２７９８４３号公報特開２０１０－１１８８３６号公報

　しかしながら、特許文献１に記載された手法では、ビットレートが既知のコンテンツでないと、適切なレートでマルチメディアデータを送信することができない。特許文献２に記載された手法では、パケットを受信しながらパケットの中に記述されたタイムスタンプの抽出及び複数フレーム間の相関を取る処理が必要となる。そのため、特許文献２に記載された手法では、装置の負荷が大きくなってしまい、多くの配信セッションを処理することができない。

　本発明は、上記課題を鑑み、コンテンツのビットレートが予めわからない状態であっても、ダウンロード後に廃棄されるマルチメディアデータを削減することができる情報処理装置などを提供することを１つの目的とする。

　上記目的を達成するために、本発明に係る情報処理装置は、端末からの配信要求に応じて、マルチメディアファイルを配信する配信サーバから受信したマルチメディアデータを一時的に保存する一時保存手段と、前記一時保存手段に保存されたマルチメディアデータに該マルチメディアデータのビットレートを算出する際に用いる情報が含まれているか否かを検出するヘッダ検出手段と、前記ヘッダ検出手段が検出した前記情報に基づいて前記マルチメディアデータのビットレートを算出するレート算出手段と、前記レート算出手段によって算出されたビットレートに基づいて前記一時保存手段から前記マルチメディアデータを読み出して前記端末に送信するデータ送信手段と、を備える。

　上記目的を達成するために、本発明に係る情報処理方法は、端末からの配信要求に応じて、マルチメディアファイルを配信する配信サーバから受信したマルチメディアデータを一時的に一時保存手段に保存し、保存されたマルチメディアデータに該マルチメディアデータのビットレートを算出する際に用いる情報が含まれているか否かを検出し、検出した前記情報に基づいて前記マルチメディアデータのビットレートを算出し、算出されたビットレートに基づいて前記一時保存手段から前記マルチメディアデータを読み出して前記端末に送信する。

　上記目的を達成するために、本発明に係るコンピュータプログラム記録媒体は、端末からの配信要求に応じて、マルチメディアファイルを配信する配信サーバから受信したマルチメディアデータを一時的に保存する一時保存処理と、保存されたマルチメディアデータに該マルチメディアデータのビットレートを算出する際に用いる情報が含まれているか否かを検出するヘッダ検出処理と、検出した前記情報に基づいて前記マルチメディアデータのビットレートを算出するレート算出処理と、算出されたビットレートに基づいて前記マルチメディアデータを読み出して前記端末に送信するデータ送信処理と、をコンピュータに実行させる、コンピュータ読み取り可能なプログラムを格納する。

　本発明の情報処理装置によれば、コンテンツのビットレートが予めわからない状態であっても、ダウンロード後に廃棄されるマルチメディアデータを削減することができる。

本発明の第１の実施形態に係る情報処理装置を含むコンテンツ配信システムの構成例を示す図である。本発明の第１の実施形態に係る情報処理装置のハードウェア構成例を示す図である。本発明の第１の実施形態に係る情報処理装置の構成例を示すブロック図である。本発明の第１の実施形態に係る情報処理装置の動作を示すフローチャートである。本発明の第２の実施形態に係る情報処理装置の構成例を示すブロック図である。本発明の第２の実施形態に係る情報処理装置の動作を示すフローチャートである。図１に示した端末の構成例を示すブロック図である。図５に示した配信要求転送部から配信サーバへのリクエストの例を示す図である。リクエストに対する配信サーバからのレスポンスの例を示す図である。ＭＰ４ファイル形式のマルチメディアファイルの構成例を示す図である。 ”ｍｄａｔ”ボックスの次のボックスの場所を計算した表である。図５に示したデータ要求部から配信サーバへのリクエストの例を示す図である。

　本発明の実施形態について、図面を参照して詳細に説明する。

　第１の実施形態
　はじめに、本発明の第１の実施形態に係る情報処理装置１を含むコンテンツ配信システム１０について説明する。

　図１は、本発明の第１の実施形態に係る情報処理装置１を含むコンテンツ配信システム１０の構成例を示す図である。図１に示すように、コンテンツ配信システム１０は、情報処理装置１、配信サーバ１００、端末１０２、ネットワーク１０４及びネットワーク１０６を有する。

　配信サーバ１００は、通信ネットワーク（以下、「ネットワーク」と略称する）１０４を介して、情報処理装置１へマルチメディアコンテンツを送信する情報処理装置である。配信サーバ１００は、図示しないＣＰＵ（中央処理装置）、メモリ、及びＨＤＤ（ハードディスクドライブ）等の記憶装置を備える。配信サーバ１００は、ＣＰＵが記憶装置に記憶されているプログラムを実行することにより実現される。本実施形態では、配信サーバ１００は、ＨＴＴＰサーバ（Ｗｅｂサーバ）として実現されることを想定している。また、配信サーバ１００は、ＨＴＴＰ以外のプロトコルを利用する配信サーバでもよい。

　情報処理装置１は、配信サーバ１００と端末１０２との間に配置され、それぞれネットワーク１０４及びネットワーク１０６を介して通信可能に接続される。本実施形態では、配信サーバ１００と情報処理装置１間及び情報処理装置１と端末１０２間は、ＨＴＴＰプロトコルを利用して通信することを想定している。また、配信サーバ１００と情報処理装置１間及び情報処理装置１と端末１０２間は、ＨＴＴＰ以外のプロトコルを利用してもよい。情報処理装置１の詳細については、図２を参照して後述する。

　端末１０２は、ネットワーク１０６を介して、情報処理装置１からマルチメディアコンテンツを受信する。端末１０２は、情報処理装置１から受信したマルチメディアコンテンツを再生（表示など）する。端末１０２は、情報処理装置１からマルチメディアコンテンツを受信しながら、マルチメディアコンテンツを再生（表示など）してもよい。また、端末１０２は、複数存在してもよい。端末１０２が複数存在する場合、各端末１０２は、情報処理装置１とネットワーク１０６を介して接続され、各端末１０２の要求に応じたマルチメディアコンテンツを受信する。このとき、情報処理装置１から受信するマルチメディアコンテンツは、要求をした端末１０２が受信してもよいし、他の端末１０２に配信してもよい。端末１０２は、図示しないＣＰＵ（中央処理装置）、メモリ、及びＨＤＤ（ハードディスクドライブ）等の記憶装置を備える。端末１０２は、ＣＰＵが記憶装置に記憶されているプログラムを実行することにより実現される。本実施形態では、端末１０２は、ＨＴＴＰクライアント（Ｗｅｂブラウザ）として実現されることを想定している。また、端末１０２は、ＨＴＴＰ以外のプロトコルを利用してもよい。

　本実施形態では、配信サーバ１００は、端末１０２からの要求に従って、マルチメディアコンテンツを外部装置から入手する。また、マルチメディアコンテンツは、配信サーバ１００に格納されていてもよい。ここで、マルチメディアコンテンツとは、マルチメディアファイルである。マルチメディアファイルは、映像データや音声データなど各種のマルチメディアデータを含む。マルチメディアコンテンツは、配信サーバ１００に記憶されていてもよい。また、マルチメディアコンテンツは、別の装置に記憶されていてもよい。

　ネットワーク１０４及びネットワーク１０６は、ＩＰ（Ｉｎｔｅｒｎｅｔ　Ｐｒｏｔｏｃｏｌ）に準拠した通信を可能とする任意の通信ネットワークである。ネットワーク１０４及びネットワーク１０６は、図示しないルータ等の中継装置を含む。また、ネットワーク１０４及びネットワーク１０６は、その一部または全部が有線通信または無線通信により実現されてもよい。例えば、無線通信としては、第三世代のモバイルネットワーク（３Ｇ）、ＨＳＰＡ網（Ｈｉｇｈ　Ｓｐｅｅｄ　Ｐａｃｋｅｔ　Ａｃｃｅｓｓ）及びＬＴＥ網（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）等のモバイルネットワーク、または無線ＬＡＮ（ＷｉＦｉ）を利用してもよい。また、無線通信は、ＩＰに準拠した通信を可能とする任意の無線通信により接続されてもよい。

　本実施形態では、端末１０２からの要求により、マルチメディアコンテンツが送信されるＶｏＤ（Ｖｉｄｅｏ　ｏｎ　Ｄｅｍａｎｄ）形態のマルチメディアサービスを想定している。また、本実施形態では、マルチメディアコンテンツを送信するサービスであってもよい。

　次に、前述した本発明の第１の実施形態に係る情報処理装置１について説明する。

　図２は、本発明の第１の実施形態に係る情報処理装置１のハードウェア構成例を示す図である。図２に示すように、情報処理装置１は、ＣＰＵ１１、メモリ１２、ＨＤＤ１４、図示しないネットワークを介して通信を可能とする通信ＩＦ（インタフェース）１６及びＣＤ（コンパクトディスク）等のコンピュータ読み取り可能な記憶媒体２０に格納されたデータを読み取り可能なリーダーライター１８を有する。これらの構成要素は、バス２２を通して互いに接続されており、互いにデータの入出力を行う。

　本実施形態に係る情報処理装置１は、ＣＰＵ１１が、メモリ１２またはＨＤＤ１４に記憶されているコンピュータプログラム（以下、「プログラム」と称する）を実行することにより実現される。または、情報処理装置１は、ＣＰＵ１１が、記憶媒体２０に記憶されているプログラムを実行することにより実現されてもよい。ＣＰＵ１１において実行するプログラムは、通信ＩＦ１６あるいはリーダーライター１８を介して外部から取得してもよい。図２に示す情報処理装置１のハードウェア構成例は、後述する各実施形態にも適用可能である。

　図３は、本発明の第１の実施形態に係る情報処理装置１の構成例を示すブロック図である。図３は、図２において例示したハードウェア資源を用いて実現される機能を、機能単位に表現したブロック図である。図２に示すように、第１の実施形態に係る情報処理装置１は、データ受信部２０２、一時保存部２０４、ヘッダ検出部２０６、レート算出部２０８及びデータ送信部２１０を備える。

　データ受信部２０２は、配信サーバ１００から送信されるマルチメディアデータを受信する。具体的には、データ受信部２０２は、マルチメディアファイルを構成するマルチメディアデータを、配信サーバ１００から受信する。

　一時保存部２０４は、データ受信部２０２が受信したマルチメディアデータを、一時的に保存する。

　ヘッダ検出部２０６は、一時保存部２０４に保存されたマルチメディアデータに、マルチメディアデータのビットレートを算出する情報が含まれているか否かを検出する。ビットレートを算出する情報とは、マルチメディアデータの転送レート（ビットレート）を算出する際に用いる情報であって、例えば、マルチメディアファイルのファイルサイズ、及び、マルチメディアファイルに含まれる全てのマルチメディアデータを等速で再生したときに要する再生時間等の情報である。

　レート算出部２０８は、ヘッダ検出部２０６が検出した情報に基づいて、マルチメディアデータのビットレートを算出する。レート算出部２０８は、例えば、ヘッダ検出部２０６によって検出されたマルチメディアファイルのファイルサイズ、及び当該マルチメディアファイルに含まれる全てのマルチメディアデータを等速で再生したときに要する再生時間等に基づいて、マルチメディアデータのビットレートを算出する。

　データ送信部２１０は、レート算出部２０８によって算出されたビットレートに基づいて、一時保存部２０４からマルチメディアデータを読み出すと共に、当該マルチメディアデータを端末１０２に対して送信する。

　ここで、本実施形態において、配信サーバ１００から送信されるマルチメディアデータは、情報処理装置１が受信するように記載しているが、外部装置が受信する構成でもよい。

　次に、情報処理装置１の動作を説明する。

　図４は、本発明の第１の実施形態に係る情報処理装置１の動作を示すフローチャートである。係るフローチャートは、図３に示す各ブロックがプログラムによって表される場合、そのプログラムを実行するＣＰＵ１１の処理手順を表す。図４に示すように、データ受信部２０２は、配信サーバ１００から送信されるマルチメディアデータを受信する（ステップＳ１０２）。

　データ受信部２０２は、配信サーバ１００から受信したマルチメディアデータを一時保存部２０４に保存する（ステップＳ１０４）。

　ヘッダ検出部２０６は、一時保存部２０４に保存されたマルチメディアデータから、ビットレートを算出する際に用いる情報を検出する（ステップＳ１０６）。

　レート算出部２０８は、一時保存部２０４に保存されたマルチメディアデータのビットレートを、ヘッダ検出部２０６が検出したビットレートを算出する情報に基づいて算出する（ステップＳ１０８）。

　データ送信部２１０は、一時保存部２０４からマルチメディアデータを読み出す（ステップＳ１１０）。

　データ送信部２１０は、一時保存部２０４から読み出したマルチメディアデータを端末１０２に対して、レート算出部２０８において算出されたビットレートに基づいて送信する（ステップＳ１１２）。

　従って、本発明の第１の実施形態に係る情報処理装置１は、コンテンツのビットレートが予めわからない状態であっても、ダウンロード後に廃棄されるマルチメディアデータを削減することができる。その理由は、コンテンツのビットレートが既知でない場合であっても、マルチメディアデータのビットレートを算出し、算出したマルチメディアデータのビットレートに基づいてマルチメディアデータを転送するからである。

　第２の実施形態
　次に、上述した第１の実施形態に係る情報処理装置１を基本とする本発明の第２の実施形態に係る情報処理装置２について説明する。

　図５は、本発明の第２の実施形態に係る情報処理装置２の構成例を示すブロック図である。図５に示すように、本発明の第２の実施形態に係る情報処理装置２は、配信要求受付部２１２、要求転送先決定部２１４、配信要求転送部２１６、データ要求部２１８、コンテンツ保存部２２０及びメタデータ保存部２２２を更に備える点が、第１の実施形態に係る情報処理装置１の構成とは異なる。それ以外の構成については、第１の実施形態に係る情報処理装置１と同様なため、同一の図面参照番号を付与すると共に、重複する説明は省略する。

　配信要求受付部２１２は、端末１０２から配信サーバ１００へのマルチメディアファイルの配信要求を受け付ける。

　要求転送先決定部２１４は、端末１０２から受け付けた配信要求に基づいて配信サーバ１００へ要求を転送するか否かを決定する。例えば、要求転送先決定部２１４は、事前に別のユーザが同じマルチメディアファイルの要求を行っており、且つ、コンテンツ保存部２２０に要求されたマルチメディアファイルが保存されている場合、配信サーバ１００に配信要求を転送しない。

　配信要求転送部２１６は、配信サーバ１００に対して、マルチメディアファイルの配信要求を転送する。具体的には、配信要求転送部２１６は、要求転送先決定部２１４が配信サーバ１００に要求を転送することを決定した場合に、配信サーバ１００に対して、マルチメディアファイルの配信要求を転送する。

　データ要求部２１８は、ヘッダ検出部２０６によって検出した結果、ビットレートを算出する情報が含まれていない場合、ビットレートを算出する情報が受信できるよう配信サーバ１００に対して要求する。

　コンテンツ保存部２２０は、一時保存部２０４から読み出されたマルチメディアファイルを構成する全てのマルチメディアデータを、端末１０２に対して送信し終わった場合に、送信が完了したマルチメディアファイルを保存する。

　メタデータ保存部２２２は、マルチメディアファイルのメタデータを保存する。具体的には、メタデータ保存部２２２は、ビットレートやマルチメディアファイルの元の場所を示すＵＲＬ（Ｕｎｉｖｅｒｓａｌ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）などのメタデータを保存する。

　次に、情報処理装置２の動作を説明する。

　図６は、本発明の第２の実施形態に係る情報処理装置２の動作を示すフローチャートである。係るフローチャートは、図５に示す各ブロックがプログラムによって表される場合、そのプログラムを実行するＣＰＵ１１の処理手順を表す。

　配信要求受付部２１２は、端末１０２からの配信要求を受け付ける（ステップＳ２０２）。

　要求転送先決定部２１４は、配信要求受付部２１２が受け付けた配信要求を配信サーバ１００に転送するか否か決定する（ステップＳ２０４）。要求転送先決定部２１４が配信サーバ１００に配信要求を転送しないと決定した場合（ステップＳ２０４においてＮＯ）、データ送信部２１０は、コンテンツ保存部２２０からマルチメディアファイルを読み出す（ステップＳ２０６）。

　データ送信部２１０は、コンテンツ保存部２２０から読み出したマルチメディアファイルのビットレートを、メタデータ保存部２２２から読み出す（ステップＳ２０８）。

　一方、要求転送先決定部２１４が配信サーバ１００に配信要求を転送すると決定した場合（ステップＳ２０４においてＹＥＳ）、配信要求転送部２１６は、配信要求を配信サーバ１００に転送する。

　配信要求転送部２１６が配信サーバ１００に配信要求を転送するのに応じて、データ受信部２０２は、配信サーバ１００から送信されるマルチメディアデータを受信する（ステップＳ１０２）。

　ヘッダ検出部２０６は、一時保存部２０４に保存されたマルチメディアデータからビットレートを算出する際に用いる情報を検出する（ステップＳ１０６）。

　保存されたマルチメディアデータからビットレートを算出する際に用いる情報を、ヘッダ検出部２０６が検出できなかった場合（ステップＳ２１０においてＮＯ）、ヘッダ検出部２０６は、処理をステップＳ２１２に進める。

　データ要求部２１８は、ビットレートを算出する際に用いる情報を検出可能なデータを配信サーバ１００に要求する（ステップＳ２１２）。そして、処理は、ステップＳ１０２に戻る。

　一方、保存されたマルチメディアデータからビットレートを算出する際に用いる情報を、ヘッダ検出部２０６が検出できた場合（ステップＳ１０８においてＹＥＳ）、レート算出部２０８は、一時保存部２０４に保存されたマルチメディアデータのビットレートを、ヘッダ検出部２０６が検出した情報に基づいて算出する。

　データ送信部２１０は、レート算出部２０８において算出されたビットレートに基づいて、一時保存部２０４からマルチメディアデータを読み出す（ステップＳ１１０）。

　データ送信部２１０は、ビットレートに基づいた送信レートによって、読み出したマルチメディアデータを端末１０２に対して送信する（ステップＳ２１２）。

　従って、本発明の第２の実施形態に係る情報処理装置２は、事前に配信要求を受け、且つ、コンテンツ保存部２２０に、そのマルチメディアファイルが保存されている場合、配信サーバ１００からの受信を待つことなくコンテンツを配信することができる。その理由は、情報処理装置２は、コンテンツ保存部２２０及びメタデータ保存部２２２を備えるので、マルチメディアファイルとそのビットレートを取得することが可能なためである。

　［ビットレート算出方法の説明］
　上述した第１の実施形態及び第２の実施形態に共通したビットレート算出方法について説明する。

　まず、端末１０２におけるマルチメディアデータの利用形態について説明する。図７は、端末１０２の構成例を示すブロック図である。端末１０２は、データ受信部３０２、再生バッファ３０４及び再生部３０６を有する。端末１０２は、情報処理装置２を介して、配信サーバ１００から送信されたマルチメディアファイルを再生する場合、データ受信部３０２が受信したマルチメディアデータを、再生バッファ３０４に蓄積しながら、再生部３０６が再生する。

　データ受信部３０２が受信する単位時間あたりのマルチメディアデータ量が、再生部３０６が再生の際に用いる単位時間あたりのマルチメディアデータ量と、同じまたはそれ以上の場合、再生バッファ３０４に蓄積されるマルチメディアデータは、空にならない。一方、データ受信部３０２が受信する単位時間あたりのマルチメディアデータ量が、再生部３０６が再生の際に用いる単位時間あたりのマルチメディアデータ量を下回る場合、再生バッファ３０４に蓄積されるマルチメディアデータは、いずれ０になる。このとき、再生バッファ３０４には再生部３０６において再生可能なマルチメディアデータがなくなるので、再生部３０６は、マルチメディアファイルの再生を停止する。

　ここで、図５に示すデータ送信部２１０は、再生部３０６が再生の際に用いる単位時間あたりのマルチメディアデータ量、すなわちマルチメディアデータのビットレートを下回らないレートにて、マルチメディアデータを送信すればよい。

　図５に示すレート算出部２０８は、データ送信部２１０における送信に必要なマルチメディアデータのビットレートを算出する。

　マルチメディアデータのビットレート（ｂｉｔｒａｔｅ）は、マルチメディアファイルのファイルサイズ（ｃｏｎｔｅｎｔ_ｓｉｚｅ［バイト］）とすべてのマルチメディアデータを等速で再生したときに要する再生時間（ｄｕｒａｔｉｏｎ［秒］）、すなわちマルチメディアファイルの再生時間とにより、以下の（１）式によって計算される。
（ｂｉｔｒａｔｅ）＝（ｃｏｎｔｅｎｔ＿ｓｉｚｅ）÷（ｄｕｒａｔｉｏｎ）・・・（１）
　図５に示すヘッダ検出部２０６は、データ受信部２０２が受信すると共に一時保存部２０４に保存したマルチメディアデータに、ファイルサイズおよび再生時間が含まれるか否かを検出する。

　（ファイルサイズの取得方法）
　次に、ファイルサイズの取得方法について説明する。ＨＴＴＰを用いてマルチメディアデータを送信する場合、配信要求転送部２１６からのコンテンツ要求および配信サーバ１００からのレスポンスは、一般的なプロトコル内容である。図８は、配信要求転送部２１６から配信サーバ１００へのリクエストの例を示す図である。図９は、リクエストに対する配信サーバ１００からのレスポンスの例を示す図である。なお、図８および図９には必要な情報のみを記述しており、リクエストまたはレスポンスは、他にもヘッダ情報を含む。

　図８に示すように、配信要求転送部２１６は、配信サーバ１００に対して、”／ｖｏｄ／ｖｉｄｅｏ.ｍｐ４”のコンテンツを要求していることがわかる。図９に示すように、配信サーバ１００からのレスポンス中に含まれる、”Ｃｏｎｔｅｎｔ－Ｔｙｐｅ：”は、ファイルのタイプを示し、”Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈ：”はファイルのサイズを示している。すなわち、マルチメディアファイルのファイルサイズは、”Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈ：”中に書かれている。つまり、”Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈ：”を検出することによりｃｏｎｔｅｎｔ_ｓｉｚｅを取得する。この例では、”／ｖｏｄ／ｖｉｄｅｏ.ｍｐ４”のファイルサイズは５００００００バイトであることがわかる。

　また、ファイル形式によっては、ヘッダ部分にファイルサイズやファイルサイズに準じる情報（ファイルサイズにヘッダ情報を減じたサイズなど）が記述されている場合がある。この場合、ＨＴＴＰヘッダの”Ｃｏｎｔｅｎｔ－Ｌｅｎｇｔｈ：”を用いるのではなく、ファイルに含まれる情報をｃｏｎｔｅｎｔ_ｓｉｚｅとして用いてもよい。

　（再生時間の取得方法）
　次に、再生時間の取得方法について説明する。マルチメディアファイルの再生時間取得方法は、ファイル形式によって異なる。例えば、ＩＳＯ／ＩＥＣ（Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｏｒｇａｎｉｚａｔｉｏｎ　ｆｏｒ　Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ／Ｉｎｔｅｒｎａｔｉｏｎａｌ　Ｅｌｅｃｔｒｏｔｅｃｈｎｉｃａｌ　Ｃｏｍｍｉｓｓｉｏｎ）　１４４９６－１２で規定されたファイルを基にしているＭＰ４ファイル形式及び３ＧＰ（３ｒｄ　Ｇｅｎｅｒａｔｉｏｎ　Ｐａｒｔｎｅｒｓｈｉｐ）ファイル形式などは、ファイルのマルチメディアメタ情報を記述している”ｍｏｏｖ”ボックスに再生時間が記述されている。その他のファイル形式でも、Ｍｉｃｒｏｓｏｆｔ（登録商標）社が開発したｗｍｖ形式、Ａｄｏｂｅ（登録商標）社が開発したｆｌｖ形式、オープンなファイル形式であるｍｋｖ形式、Ａｐｐｌｅ（登録商標）社が開発したｍｏｖ形式及びＲｅａｌ　Ｎｅｔｗｏｒｋｓ社が開発したｒｍ形式など、多くのファイル形式は、ヘッダ中に再生時間を記述している。

　また、マルチメディアファイルの再生時間が記述されていない場合、マルチメディアデータのサンプル数（フレーム数）とサンプリング周波数（フレームレート）が記述されていれば、再生時間の計算は可能である。

　例えば、Ｍｉｃｒｏｓｏｆｔ社により開発されたＡＶＩ（Audio Video Interleave）ファイル形式は、ファイル先頭部にマルチメディアデータのサンプル数（フレーム数）とサンプリング周波数（フレームレート）とが記述されている。サンプル数（ｆｒａｍｅ＿ｎｕｍ［サンプル］）とサンプリング周波数（ｆｒａｍｅ＿ｒａｔｅ［サンプル／秒］）とが取得できた場合、再生時間は、以下の（２）式によって計算する。
（ｄｕｒａｔｉｏｎ）＝（ｆｒａｍｅ＿ｎｕｍ）÷（ｆｒａｍｅ＿ｒａｔｅ）・・・（２）
　図５に示すヘッダ検出部２０６が一時保存部２０４に蓄積されているマルチメディアデータ中に、上記ファイル形式のヘッダがあることを検出した場合、レート算出部２０８は、再生時間を取得すると共に、その再生時間とファイルサイズとに基づいて、ビットレートを算出する。

　（再生時間が取得できない場合のビットレート算出方法）
　次に、再生時間が取得できない場合のビットレートの算出方法について説明する。図５に示すレート算出部２０８は、ヘッダ検出部２０６が再生時間を取得できない場合でも、マルチメディアデータのビットレートを算出できることがある。このような場合、ビットレートは、マルチメディアデータのヘッダ部に記述されている。ヘッダ中にビットレートが記述される場合、マルチメディアデータのメディアごとのビットレートが算出できることがある。この場合は、すべてのメディアごとのビットレートを算出すると共に、算出したすべてのビットレートの和を算出することによって、マルチメディアデータのビットレートを算出することができる。各メディアのビットレートをｂ_ｉ（ｉ＝１，２，…，Ｍ）、Ｍをメディアの数と仮定すると、マルチメディアデータのビットレートは、以下の（３）式によって計算する。

　　　　　　　　　　　　・・・（３）

　また、（３）式により算出されたｂは、通常、マルチメディアファイルのヘッダ情報など、メディア以外のデータ量を含んでいない。そのため、ヘッダ分の余裕を考慮して、以下の（４）式によって求められる値を、マルチメディアデータのビットレートとしてもよい。
ｂ´＝α×ｂ（α≧１）・・・（４）
　また、ＴＳ（Ｔｒａｎｓｐｏｒｔ　Ｓｔｒｅａｍ）ファイルや、ＭＰＥＧ（Ｍｏｖｉｎｇ　Ｐｉｃｔｕｒｅ　Ｅｘｐｅｒｔｓ　Ｇｒｏｕｐ）－１、ＭＰＥＧ－２ファイルなどのファイル形式は、再生時間、ビットレートがヘッダに記述されていない。この場合、例えば、一時保存部２０４において、保存されるデータの一部を復号または再生し、再生時のレートをビットレートとしてもよい。

　また、配信サーバ１００が複数存在する場合（例えば、配信サーバ１００Ａ、配信サーバ１００Ｂ及び配信サーバ１００Ｃという３つのサーバが存在する場合）、配信サーバ１００ごとのコンテンツの統計情報がわかっていれば、統計情報に基づいてビットレートを算出してもよい。統計情報とは、例えば、配信サーバ１００Ａでは、ｂａ［ビット／秒］にて送信されるコンテンツが多い、配信サーバ１００Ｂでは、ｂｂ［ビット／秒］にて送信されるコンテンツが多い、配信サーバ１００ＣのコンテンツのうちＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）に”ｃ”という文字列が含まれていればｂｃ［ビット／秒］にて送信されるコンテンツが多いといった、情報である。

　（ヘッダが検出できない場合）
　次に、ヘッダを検出することができない場合について説明する。上記の方法によってヘッダを検出する場合に、ヘッダ中にビットレートを算出できる情報が記述されているファイル形式にも関わらず、すぐにヘッダが検出できないことがある。

　例えば、ＩＳＯ／ＩＥＣ　１４４９６－１２で規定されたファイルを基にしているＭＰ４形式、３ＧＰ形式のファイルなどでは、ファイルのマルチメディアメタ情報は”ｍｏｏｖ”ボックスと呼ばれるデータブロックに記述されているが、必ずしもファイル先頭に含まれるとは限らない。ファイルのマルチメディアメタ情報がファイルの最後に含まれる場合、最後までファイルを受信しないとビットレートを算出できない。この場合、データ要求部２１８は、配信サーバ１００に対して、マルチメディアファイルのマルチメディアメタ情報が含まれるヘッダを要求することによって、ビットレートの算出を速くする。

　図１０は、ＭＰ４ファイル形式のマルチメディアファイルの構成例を示す図である。図１０は、ＭＰ４ファイル全体を示し、ＭＰ４ファイルは、ＭＰ４ファイルであることを示す”ｆｔｙｐ”ボックス、マルチメディアデータ本体を保存する”ｍｄａｔ”ボックス、メタデータが記述される”ｍｏｏｖ”ボックスと呼ばれる各データブロックを含む。ここでは、”ｍｏｏｖ”ボックスがファイルの最後に含まれると仮定する。図１０に示す各ボックスの中の小さな箱は、１バイト分のデータを示す。１バイト分の箱に記述された二桁の英数字は、１６進数を示し、シングルクオートで囲まれた一文字の英文字は、１バイト分のアスキー文字を示す。”ｆｔｙｐ”、”ｍｄａｔ”、”ｍｏｏｖ”などのボックスの出現順番は、”ｆｔｙｐ”が必ず先頭に来るが、それ以外のボックスの順番は任意である。

　各ボックスは、ボックスの名前を示す”ｆｔｙｐ”、”ｍｏｏｖ”、”ｍｄａｔ”と、ボックスの名前の前にそのボックスのサイズが記述されている。図１０に示す例では、”ｆｔｙｐ”ボックスは１６進数で０Ｘ１８バイト、”ｍｄａｔ”ボックスは０Ｘ９Ｅ４２Ａバイトである。

　配信サーバ１００は、本実施形態では一例として、マルチメディアファイルの先頭からマルチメディアデータを送信する。そのため、データ受信部２０２は、マルチメディアファイルの先頭部分からマルチメディアデータを受信し、受信したマルチメディアデータを一時保存部２０４に保存する。

　ヘッダ検出部２０６は、一時保存部２０４から読み出したファイル先頭を参照することによって、当該ファイルがＭＰ４ファイル形式であることを検知する。しかしながら、ヘッダ検出部２０６は、”ｆｔｙｐ”ボックスの次に”ｍｏｏｖ”ボックスではなく、”ｍｄａｔ”ボックスが含まれることを検知する。そこで、ヘッダ検出部２０６は、”ｍｏｏｖ”ボックスを検出するために、”ｍｏｏｖ”ボックスの位置を計算する。

　図１１は、”ｍｄａｔ”ボックスの次のボックスの場所を計算した表である。図１０及び図１１に示すように、ファイルの先頭は、”ｆｔｙｐ”ボックス、続いて”ｍｄａｔ”ボックスである。、よって、”ｍｄａｔ”ボックスの次のボックスは、図１１に示すように、ファイル先頭から６４８２７４バイト目になる。

　データ要求部２１８は、上記の計算結果に基づいて、６４８２７４バイト目からのデータを配信サーバ１００に要求する。ＨＴＴＰプロトコルを利用している場合、データ要求部２１８は、ＨＴＴＰの部分リクエストを利用する。図１２は、データ要求部２１８から配信サーバ１００へのリクエストの例を示す図である。なお、本プロトコルは、必要な情報のみを記述しており、他にもヘッダ情報が含まれる。図１２に示すように、データ要求部２１８は、配信サーバ１００に対して、”／ｖｏｄ／ｖｉｄｅｏ．ｍｐ４”のコンテンツを要求している。また、データ要求部２１８は、配信サーバ１００に対して、”Ｒａｎｇｅ：”により、ファイルの指定した一部を要求している。すなわち、この場合、データ要求部２１８は、マルチメディアファイルの６４８２７４バイト目からのデータを要求している。

　データ要求部２１８が次のボックスの場所を要求すると、データ受信部２０２は、配信サーバ１００からのデータ送信を受信する。受信したマルチメディアデータは、一時保存部２０４に保存され、ヘッダ検出部２０６は、当該マルチメディアデータにヘッダが含まれるか検出する。ヘッダ検出部２０６は、もしヘッダが見つからない場合、さらに次のボックスを検索する。

　データ要求部２１８が次のボックスの送信を配信サーバ１００に要求した場合、最初からマルチメディアデータの受信に利用している通信セッションは、破棄されてもよいし、継続されてもよい。

　従って、ファイル先頭にヘッダ情報がない場合でも、ヘッダ情報を配信サーバ１００に要求することにより、早急にビットレートを算出することができる。

　上述した各実施形態では、図３および図５に示す情報処理装置を、図２に示すＣＰＵ１１が実行する一例として、ソフトウエア・プログラムによって実現する場合について説明した。しかしながら図３および図５に示す各ブロックに示す機能は、一部または全部を、ハードウエアとして実現してもよい。

　以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解しうる様々な変更をすることができる。

　本発明は、例えば、マルチメディアデータを配信サーバから受信すると共に、再生端末に送信する情報処理装置に適用できる。

　この出願は、２０１２年１１月８日に出願された日本出願特願２０１２－２４６２９９を基礎とする優先権を主張し、その開示の全てをここに取り込む。

　１、２　　情報処理装置
　１１　　ＣＰＵ
　１２　　メモリ
　１４　　ＨＤＤ
　１６　　通信ＩＦ
　１８　　リーダーライター
　２０　　記憶媒体
　２２　　バス
　１００　　配信サーバ
　１０２　　端末
　１０４、１０６　　ネットワーク
　２０２　　データ受信部
　２０４　　一時保存部
　２０６　　ヘッダ検出部
　２０８　　レート算出部
　２１０　　データ送信部
　２１２　　配信要求受付部
　２１４　　要求転送先決定部
　２１６　　配信要求転送部
　２１８　　データ要求部
　３０２　　データ受信部
　３０４　　再生バッファ
　３０６　　再生部

Claims

　端末からの配信要求に応じて、マルチメディアファイルを配信する配信サーバから受信したマルチメディアデータを一時的に保存する一時保存手段と、
　前記一時保存手段に保存されたマルチメディアデータに該マルチメディアデータのビットレートを算出する際に用いる情報が含まれているか否かを検出するヘッダ検出手段と、
　前記ヘッダ検出手段が検出した前記情報に基づいて前記マルチメディアデータのビットレートを算出するレート算出手段と、
　前記レート算出手段によって算出されたビットレートに基づいて前記一時保存手段から前記マルチメディアデータを読み出して前記端末に送信するデータ送信手段と
　を備える情報処理装置。
　前記ヘッダ検出手段によって、前記ビットレートを算出する情報が含まれていないと判断した場合、ビットレートを算出する情報が受信できるよう前記配信サーバに要求するデータ要求手段と
　をさらに備える請求項１に記載の情報処理装置。
　前記端末からのマルチメディアファイルの配信要求を受け付ける配信要求受付手段と、
　前記配信サーバに対して、前記配信要求を転送する配信要求転送手段と
　をさらに備える、請求項1または請求項２に記載の情報処理装置。
　前記端末から受け付けた配信要求に基づいて前記配信サーバへ要求を転送するか否かを決定する要求転送先決定手段と、
　前記要求転送先決定手段による決定に基づいて、前記一時保存手段から読み出されたマルチメディアファイルを構成するマルチメディアデータを、前記端末に対して送信し終わった場合に、送信が完了した前記マルチメディアファイルを保存するコンテンツ保存手段から、マルチメディアファイルを送信する場合、前記コンテンツ保存手段からマルチメディアファイルを読み出し、前記マルチメディアファイルのメタデータを保存するメタデータ保存手段から読み出したマルチメディアファイルのビットレートに基づいて、前記端末に対して当該マルチメディアデータを送信するコンテンツ送信手段と
　をさらに備える請求項１乃至３の何れかに記載の情報処理装置。
　前記要求転送先決定手段は、前記コンテンツ保存手段に、前記配信要求を受けたマルチメディアファイルが保存されており、且つ、前記メタデータ保存手段に該マルチメディアファイルのビットレートが保存されている場合、前記配信サーバに前記配信要求を転送しないよう決定する
　請求項４に記載の情報処理装置。
　前記レート算出手段は、マルチメディアファイルのファイルサイズと、当該マルチメディアファイルに含まれるマルチメディアデータを等速で再生したときに要する再生時間とに基づいて、マルチメディアデータのビットレートを算出する
　請求項１乃至５の何れかに記載の情報処理装置。
　前記マルチメディアファイルを配信する前記配信サーバと、
　前記マルチメディアファイルの配信を要求する前記端末と、
　請求項１乃至６の何れかに記載の情報処理装置と
　を有するコンテンツ配信システム。
　端末からの配信要求に応じて、マルチメディアファイルを配信する配信サーバから受信したマルチメディアデータを一時的に一時保存手段に保存し、
　保存されたマルチメディアデータに該マルチメディアデータのビットレートを算出する際に用いる情報が含まれているか否かを検出し、
　検出した前記情報に基づいて前記マルチメディアデータのビットレートを算出し、
　算出されたビットレートに基づいて前記一時保存手段から前記マルチメディアデータを読み出して前記端末に送信する
　情報処理方法。
　端末からの配信要求に応じて、マルチメディアファイルを配信する配信サーバから受信したマルチメディアデータを一時的に保存する一時保存処理と、
　保存されたマルチメディアデータに該マルチメディアデータのビットレートを算出する際に用いる情報が含まれているか否かを検出するヘッダ検出処理と、
　検出した前記情報に基づいて前記マルチメディアデータのビットレートを算出するレート算出処理と、
　算出されたビットレートに基づいて前記マルチメディアデータを読み出して前記端末に送信するデータ送信処理と
　をコンピュータに実行させるコンピュータ読み取り可能なコンピュータプログラムを格納するコンピュータプログラム記録媒体。