JP2016040919A - 情報処理装置、情報処理方法およびプログラム - Google Patents

Abstract

【課題】情報処理装置、情報処理方法およびプログラムを提供する。【解決手段】異なるビットレートであり、複数のセグメントから構成される、複数のコンテンツのそれぞれにおける前記複数のセグメントに関する所在情報を、他の機器に送信する送信部と、前記セグメントの所在情報を、前記他の機器から受信する受信部と、前記送信部は、前記受信部により受信された前記セグメントの所在情報に基づいて、前記セグメントを前記他の機器に送信する、情報処理装置。【選択図】図８

Description

本発明は、情報処理装置、情報処理方法およびプログラムに関する。

近日、コンテンツ伝送のためのＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、およびコンテンツ圧縮符号化に関するＭＰ４が広く利用されている。ＨＴＴＰによれば、インターネットにおいて、コンテンツのダウンロードだけでなく、ストリーミングを行うことが可能である。このＨＴＴＰストリーミングは、「ＤＬＮＡ ｇｕｉｄｅｌｉｎｅｓ」（２００６）や「Ｏｐｅｎ ＩＰＴＶ Ｆｏｒｕｍ」（２００９）などのネットワークメディア規格にも採用されている。また、ＭＰ４（ＩＳＯ／ＩＥＣ−１４４９６−１２，１４）は、記憶フォーマットとしてだけでなく、ダウンロードやストリーミングなどの伝送フォーマットとしても利用可能である。

例えば、非特許文献１には、インターネットを介したコンテンツのストリーミングをＨＴＴＰおよびＭＰ４を用いて行うことが記載されている。より詳細には、非特許文献１には、サーバが、異なるビットレートで符号化されたＭＰ４形式の符号化ファイルを記憶しており、ネットワーク状況に適切な符号化ファイルを構成するセグメントを順次に送信することが記載されている。

「ＩＩＳ Ｓｍｏｏｔｈ Ｓｔｒｅａｍｉｎｇ Ｔｅｃｈｎｉｃａｌ Ｏｖｅｒｖｉｅｗ」、Ａｌｅｘ Ｚａｍｂｅｌｌｉ，Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ、Ｍａｒｃｈ ２００９

しかし、従来のシステムでは、いずれの符号化ファイルを構成するセグメントを送信するかをサーバ側で判断していたため、サーバ側の負荷が大きくなってしまうという問題があった。また、クライアントにはセグメントが再生される時間（コンテンツの先頭からの相対時間）などの情報が提供されないために、可変速再生などのトリックプレイや、相対時間への飛び越してからの再生（シーク再生）などを行うことが困難であった。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、コンテンツの適応的なストリーミングにおける送信側の負荷を軽減するための、新規かつ改良された情報処理装置、情報処理方法およびプログラムを提供することにある。

上記課題を解決するために、本発明のある観点によれば、同一コンテンツを異なるビットレートで符号化して複数の符号化データを生成する生成部、および複数のセグメントから構成される前記複数の符号化データの各々を記憶する記憶部、を有するコンテンツサーバと、いずれの符号化データを構成するセグメントを前記コンテンツサーバに要求するかを、前記同一コンテンツ内で順次に選択する選択部、前記選択部により選択されたセグメントを前記コンテンツサーバに要求して前記コンテンツサーバから取得する取得部、および、前記コンテンツサーバから取得されたセグメントを順次に再生する再生部、を有するコンテンツ再生装置と、を備えるコンテンツ再生システムが提供される。

前記複数の符号化データを構成する前記複数のセグメントの各々は、前記複数の符号化データ間で代替して復号できるように符号化されてもよい。

前記生成部は、前記複数の符号化データへアクセスするためのアクセス情報を含む第１のデータファイル、および前記複数の符号化データの各々を含む複数の第２のデータファイルを生成し、前記アクセス情報は、前記複数の第２のデータファイルのネットワーク位置情報、および前記符号化データの各セグメントのファイル内での位置情報および各セグメントの再生時間（各セグメントの再生に要する時間）を含んでもよい。

前記生成部は、前記複数の符号化データへアクセスするためのアクセス情報、および前記複数の符号化データのうちの１の符号化データを含む第１のデータファイル、他の符号化データを含む第２のデータファイルを生成してもよい。

前記第２のデータファイルは、前記他の符号化データを構成するセグメントの前記第２のデータファイルにおける位置情報をさらに含み、前記第１のデータファイルに含まれる前記他の符号化データへのアクセス情報は、前記第２のデータファイルのネットワーク位置情報、および前記符号化データを含むトラックを示す識別情報を含み、前記第２のデータファイルは、ファイルに含まれる前記符号化データのセグメントのファイル内での位置情報ならびに各セグメントの再生時間を含んでもよい。

前記取得部は、前記第１のデータファイルに含まれる前記アクセス情報を取得し、前記選択部により選択されたセグメントを、当該アクセス情報に基づいて前記コンテンツサーバから取得してもよい。

前記生成部は、前記第１のデータファイルおよび前記第２のデータファイルをＭＰ４形式で生成し、前記第１のデータファイルにおける前記他の符号化データへアクセスするためのネットワーク位置情報をＭＰ４の「ｄｉｎｆ」に記載してもよい。

前記セグメントは、ＭＰ４ファイルのＳｙｎｃ Ｓａｍｐｌｅを境界にして分割されたデータであってもよい。

前記生成部は、前記第１のデータファイルに、前記複数の符号化データの対応するセグメント同士は代替して再生可能であることを示す情報を記載してもよい。

前記取得部は、ＨＴＴＰに従って前記複数の符号化データの各々へのアクセス情報および前記セグメントを取得してもよい。

前記生成部は、前記第１のデータファイルに、前記複数の符号化データのビットレート情報を記載してもよい。

前記取得部は、アクセス情報に含まれる各符号化データファイルのネットワーク位置情報および各セグメントのファイル内でのバイト単位での位置情報を指定して、ＨＴＴＰに従って前記セグメントを取得してもよい。

前記取得部は、前記アクセス情報に基づき、時系列に復号されるべきセグメントを前記コンテンツサーバからネットワークを介して順次に取得し、前記選択部は、いずれの符号化データを構成するセグメントを前記コンテンツサーバに要求するかを、前記ネットワークの状況に応じて動的に選択してもよい。

前記コンテンツ再生装置は、前記取得部により取得されたセグメントをバッファリングするバッファを備え、前記再生部は、前記バッファにバッファリングされたセグメントを順次に再生し、前記選択部は、いずれの符号化データを構成するセグメントを前記コンテンツサーバに要求するかを、前記バッファによるバッファリング状況に応じて選択してもよい。

前記選択部は、前記バッファにバッファリングされているセグメントで再生可能な時間が短くなると、低ビットレートで符号化された符号化データを構成するセグメントを選択し、前記バッファにバッファリングされているセグメントで再生可能な時間が長くなると、高ビットレートで符号化された符号化データを構成するセグメントを選択してもよい。

また、上記課題を解決するために、本発明の別の観点によれば、同一コンテンツを異なるビットレートで符号化して複数の符号化データを生成し、複数のセグメントから構成される前記複数の符号化データの各々を記憶するコンテンツサーバに、いずれの符号化データを構成するセグメントを要求するかを、前記同一コンテンツ内で順次に選択する選択部と、前記選択部により選択されたセグメントを前記コンテンツサーバに要求して前記コンテンツサーバから取得する取得部と、前記コンテンツサーバから取得されたセグメントを順次に再生する再生部と、を備えるコンテンツ再生装置が提供される。

また、上記課題を解決するために、本発明の別の観点によれば、コンピュータを、同一コンテンツを異なるビットレートで符号化して複数の符号化データを生成し、複数のセグメントから構成される前記複数の符号化データの各々を記憶するコンテンツサーバに、いずれの符号化データを構成するセグメントを要求するかを、前記同一コンテンツ内で順次に選択する選択部と、前記選択部により選択されたセグメントを前記コンテンツサーバに要求して前記コンテンツサーバから取得する取得部と、前記コンテンツサーバから取得されたセグメントを順次に再生する再生部と、として機能させるためのプログラムが提供される。

また、上記課題を解決するために、本発明の別の観点によれば、コンテンツサーバが、同一コンテンツを異なるビットレートで符号化して複数の符号化データを生成するステップと、前記コンテンツサーバが、複数のセグメントから構成される前記複数の符号化データの各々を記憶媒体に記憶するステップと、コンテンツ再生装置が、いずれの符号化データを構成するセグメントを前記コンテンツサーバに要求するかを、前記同一コンテンツ内で順次に選択するステップと、前記コンテンツ再生装置が、選択されたセグメントを前記コンテンツサーバに要求して前記コンテンツサーバから取得するステップと、前記コンテンツ再生装置が、前記コンテンツサーバから取得されたセグメントを順次に再生するステップと、を含むコンテンツ再生方法が提供される。

また、上記課題を解決するために、本発明の別の観点によれば、同一コンテンツを異なるビットレートで符号化して複数の符号化データを生成する生成部と、複数のセグメントから構成される前記複数の符号化データの各々を記憶する記憶部とを備え、前記生成部は、前記複数の符号化データの各々へのアクセス情報、および前記複数の符号化データのうちの１の符号化データからなる第１のデータファイルと、他の符号化データの各々からなる１または２以上の第２のデータファイルとを、生成する、コンテンツサーバが提供される。

以上説明したように本発明によれば、コンテンツの適応的なストリーミングにおける送信側の負荷を軽減することができる。

本発明の実施形態によるコンテンツ再生システムの構成を示した説明図である。 本実施形態によるコンテンツ再生システムにおけるデータの流れを示した説明図である。 コンテンツ再生装置のハードウェア構成を示したブロック図である。 本実施形態によるコンテンツサーバの構成を示した機能ブロック図である。 一般的なＭＰ４ファイルの構成を示した説明図である。 本実施形態においてファイル生成部により生成されるＭＰ４ファイルの構成を示した説明図である。 本実施形態においてファイル生成部により生成されるＭＰ４ファイルの変形例を示した説明図である。 本実施形態によるコンテンツ再生装置の構成を示した機能ブロック図である。 本実施形態によるコンテンツ再生システムの動作を示したシーケンス図である。 本実施形態においてファイル生成部により生成されるＭＰ４ファイルの変形例を示した説明図である。 本実施形態においてファイル生成部により生成されるＭＰ４ファイルの変形例を示した説明図である。 本実施形態においてファイル生成部により生成されるＭＰ４ファイルの変形例を示した説明図である。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

また、以下に示す項目順序に従って当該「発明を実施するための形態」を説明する。
１．コンテンツ再生システムの概要
２．コンテンツ再生装置のハードウェア構成
３．コンテンツサーバの機能
４．コンテンツ再生装置の機能
５．コンテンツ再生システムの動作
６．変形例
７．まとめ

＜１．コンテンツ再生システムの概要＞
まず、図１および図２を参照し、本発明の実施形態によるコンテンツ再生システム１について概略的に説明する。

図１は、本発明の実施形態によるコンテンツ再生システムの構成を示した説明図である。図１に示したように、本発明の実施形態によるコンテンツ再生システム１は、コンテンツサーバ１０と、ネットワーク１２と、コンテンツ再生装置２０（クライアント）と、を備える。

コンテンツサーバ１０とコンテンツ再生装置２０は、ネットワーク１２を介して接続されている。このネットワーク１２は、ネットワーク１２に接続されている装置から送信される情報の有線、または無線の伝送路である。

例えば、ネットワーク１２は、インターネット、電話回線網、衛星通信網などの公衆回線網や、Ｅｔｈｅｒｎｅｔ（登録商標）を含む各種のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）などを含んでもよい。また、ネットワーク１２は、ＩＰ−ＶＰＮ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ−Ｖｉｒｔｕａｌ Ｐｒｉｖａｔｅ Ｎｅｔｗｏｒｋ）などの専用回線網を含んでもよい。

コンテンツサーバ１０は、コンテンツデータを符号化し、符号化データおよび符号化データのメタ情報を含むデータファイルを生成して記憶する。なお、コンテンツサーバ１０がＭＰ４形式のデータファイルを生成する場合、符号化データは「ｍｄａｔ」に該当し、メタ情報は「ｍｏｏｖ」に該当する。

また、コンテンツデータは、音楽、講演およびラジオ番組などの音楽データや、映画、テレビジョン番組、ビデオプログラム、写真、文書、絵画および図表などの映像データや、ゲームおよびソフトウェアなどであってもよい。

ここで、本実施形態によるコンテンツサーバ１０は、同一コンテンツに関し、異なるビットレートで複数のデータファイルを生成する。以下、図２を参照して当該事項について具体的に説明する。

図２は、本実施形態によるコンテンツ再生システム１におけるデータの流れを示した説明図である。コンテンツサーバ１０は、同一のコンテンツデータを異なるビットレートで符号化し、図２に示したように例えば２ＭｂｐｓのファイルＡ、１．５ＭｂｐｓのファイルＢ、１ＭｂｐｓのファイルＣを生成する。相対的に、ファイルＡはハイビットレートであり、ファイルＢは標準ビットレートであり、ファイルＣはロービットレートである。

また、図２に示したように、各ファイルの符号化データは複数のセグメントに区分されている。例えば、ファイルＡの符号化データは「Ａ１」、「Ａ２」、「Ａ３」、・・・「Ａｎ」というセグメントに区分されており、ファイルＢの符号化データは「Ｂ１」、「Ｂ２」、「Ｂ３」、・・・「Ｂｎ」というセグメントに区分されており、ファイルＣの符号化データは「Ｃ１」、「Ｃ２」、「Ｃ３」、・・・「Ｃｎ」というセグメントに区分されている。

ここで、各セグメントはＭＰ４のシンクサンプル（たとえば、ＡＶＣ/Ｈ．２６４の映像符号化ではＩＤＲ−ピクチャ）で始まる単独で再生可能な１または２以上の映像符号化データおよび音声符号化データより構成サンプルで構成される。例えば、一秒３０フレームのビデオデータが１５フレーム固定長のＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ）にて符号化されていた場合、各セグメントは、４ＧＯＰに相当する２秒分の映像ならびに音声符号化データであっても、２０ＧＯＰに相当する１０秒分の映像ならびに音声符号化データであってもよい。

また、各ファイルにおける配置順番が同一のセグメントによる再生範囲（コンテンツの先頭からの時間位置の範囲）は同一である。例えば、セグメント「Ａ２」、セグメント「Ｂ２」、およびセグメント「Ｃ２」の再生範囲は同一であり、各セグメントが２秒分の符号化データである場合、セグメント「Ａ２」、セグメント「Ｂ２」、およびセグメント「Ｃ２」の再生範囲は、いずれもコンテンツの２秒〜４秒である。

コンテンツサーバ１０は、このような複数のセグメントから構成されるファイルＡ〜ファイルＣを生成すると、ファイルＡ〜ファイルＣを記憶する。そして、コンテンツサーバ１０は、図２に示したように、異なるファイルを構成するセグメントをコンテンツ再生装置２０に順次に送信し、コンテンツ再生装置２０は、受信したセグメントをストリーミング再生する。

なお、図１にはコンテンツ再生装置２０の一例として表示装置を示しているが、コンテンツ再生装置２０はかかる例に限定されない。例えば、コンテンツ再生装置２０は、ＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）、家庭用映像処理装置（ＤＶＤレコーダ、ビデオデッキなど）、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、家庭用ゲーム機器、家電機器などの情報処理装置であってもよい。また、コンテンツ再生装置２０は、携帯電話、ＰＨＳ（Ｐｅｒｓｏｎａｌ Ｈａｎｄｙｐｈｏｎｅ Ｓｙｓｔｅｍ）、携帯用音楽再生装置、携帯用映像処理装置、携帯用ゲーム機器などの情報処理装置であってもよい。

ここで、コンテンツサーバ１０からは、ネットワーク状況に応じたセグメントが送信されることが望ましい。例えば、ネットワーク帯域の余裕が大きい場合にはハイビットレートのセグメント（例えば、ファイルＡを構成するセグメント）を送信し、ネットワーク帯域の余裕が少ない場合にはロービットレートのセグメント（例えば、ファイルＣを構成するセグメント）を送信することが適切である。

しかし、ネットワーク状況の監視、およびネットワーク状況に応じたセグメントの選択をコンテンツサーバ１０が行うと、コンテンツサーバ１０の負荷が大きくなってしまうという問題があった。

そこで、上記の背景の下、本実施形態にかかるコンテンツ再生システム１を創作するに至った。本実施形態にかかるコンテンツ再生システム１によれば、適応的なストリーミングをサーバ側の負荷を軽減して実現することができる。

さらに、本実施形態にかかるコンテンツ再生システム１によれば、ＨＴＴＰやＭＰ４などの規格の大部分に準拠し、かつ、既存装置と互換性を確保することができる。以下、このような本実施形態にかかるコンテンツ再生システム１を構成するコンテンツ再生装置２０およびコンテンツサーバ１０について詳細に説明する。

＜２．コンテンツ再生装置のハードウェア構成＞
図３は、コンテンツ再生装置２０のハードウェア構成を示したブロック図である。コンテンツ再生装置２０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）２０１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）２０２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０３と、ホストバス２０４と、を備える。また、コンテンツ再生装置２０は、ブリッジ２０５と、外部バス２０６と、インタフェース２０７と、入力装置２０８と、出力装置２１０と、ストレージ装置（ＨＤＤ）２１１と、ドライブ２１２と、通信装置２１５とを備える。

ＣＰＵ２０１は、演算処理装置および制御装置として機能し、各種プログラムに従ってコンテンツ再生装置２０内の動作全般を制御する。また、ＣＰＵ２０１は、マイクロプロセッサであってもよい。ＲＯＭ２０２は、ＣＰＵ２０１が使用するプログラムや演算パラメータ等を記憶する。ＲＡＭ２０３は、ＣＰＵ２０１の実行において使用するプログラムや、その実行において適宜変化するパラメータ等を一時記憶する。これらはＣＰＵバスなどから構成されるホストバス２０４により相互に接続されている。

ホストバス２０４は、ブリッジ２０５を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バスなどの外部バス２０６に接続されている。なお、必ずしもホストバス２０４、ブリッジ２０５および外部バス２０６を分離構成する必要はなく、一のバスにこれらの機能を実装してもよい。

入力装置２０８は、マウス、キーボード、タッチパネル、ボタン、マイクロフォン、スイッチおよびレバーなどユーザが情報を入力するための入力手段と、ユーザによる入力に基づいて入力信号を生成し、ＣＰＵ２０１に出力する入力制御回路などから構成されている。コンテンツ再生装置２０のユーザは、該入力装置２０８を操作することにより、コンテンツ再生装置２０に対して各種のデータを入力したり処理動作を指示したりすることができる。

出力装置２１０は、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）ディスプレイ装置、液晶ディスプレイ（ＬＣＤ）装置、ＯＬＥＤ（Ｏｒｇａｎｉｃ Ｌｉｇｈｔ Ｅｍｉｔｔｉｎｇ Ｄｉｏｄｅ）装置およびランプなどの表示装置を含む。さらに、出力装置２１０は、スピーカおよびヘッドホンなどの音声出力装置を含む。出力装置２１０は、例えば、再生されたコンテンツを出力する。具体的には、表示装置は再生された映像データ等の各種情報をテキストまたはイメージで表示する。一方、音声出力装置は、再生された音声データ等を音声に変換して出力する。

ストレージ装置２１１は、本実施形態にかかるコンテンツ再生装置２０の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置２１１は、記憶媒体、記憶媒体にデータを記録する記録装置、記憶媒体からデータを読み出す読出し装置および記憶媒体に記録されたデータを削除する削除装置などを含んでもよい。ストレージ装置２１１は、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）で構成される。このストレージ装置２１１は、ハードディスクを駆動し、ＣＰＵ２０１が実行するプログラムや各種データを格納する。

ドライブ２１２は、記憶媒体用リーダライタであり、コンテンツ再生装置２０に内蔵、あるいは外付けされる。ドライブ２１２は、装着されている磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリ等のリムーバブル記憶媒体２４に記録されている情報を読み出して、ＲＡＭ２０３に出力する。また、ドライブ２１２は、リムーバブル記憶媒体２４に情報を書き込むこともできる。

通信装置２１５は、例えば、ネットワーク１２に接続するための通信デバイス等で構成された通信インタフェースである。また、通信装置２１５は、無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）対応通信装置であっても、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）対応通信装置であっても、有線による通信を行うワイヤー通信装置であってもよい。

以上、図３を参照してコンテンツ再生装置２０のハードウェア構成について説明した。コンテンツサーバ１０のハードウェアはコンテンツ再生装置２０と実質的に同一に構成することが可能であるため、説明を省略する。

＜３．コンテンツサーバの機能＞
次に、図４〜図７を参照し、本実施形態によるコンテンツサーバ１０の機能を説明する。

図４は、本実施形態によるコンテンツサーバ１０の構成を示した機能ブロック図である。図４に示したように、本実施形態によるコンテンツサーバ１０は、ファイル生成部１２０と、記憶部１３０と、通信部１４０と、を備える。

ファイル生成部１２０は、コンテンツデータを符号化するエンコーダ１２２を備え、符号化データおよびメタデータを含むＭＰ４ファイルを生成する。より詳細には、ファイル生成部１２０は、同一コンテンツに関し、符号化データのビットレートが異なる複数のＭＰ４ファイルを生成する。以下、図５を参照して一般的なＭＰ４ファイルの構成を説明した後、本実施形態においてファイル生成部１２０により生成されるＭＰ４ファイルの構成を説明する。

図５は、一般的なＭＰ４ファイルの構成を示した説明図である。図５に示したように、ＭＰ４ファイルは「ｍｏｏｖ」および「ｍｄａｔ」を含む。「ｍｄａｔ」は映像や音声などの符号化データである。本実施例では、映像の符号化にはＨ．２４６／ＡＶＣ，音声符号化にはＨＥ−ＡＡＣを利用する。「ｍｏｏｖ」は、「ｔｒａｋ（ｖｉｄｅｏ）」や「ｔｒａｋ（ａｕｄｉｏ）」など、「ｍｄａｔ」に含まれる各セグメントへのアクセス情報を含む。アクセス情報としては、例えば、各サンプルの所在情報（バイトオフセット）や再生時間情報などがあげられる。

なお、ＭＰ４においては他の外部ファイルを参照するためのデータボックスとして「ｄｉｎｆ」が規定されている。図５に示したように「ｍｏｏｖ」の参照先が同一のＭＰ４ファイルに含まれる「ｍｄａｔ」である場合、この「ｄｉｎｆ」の値は「ｎｕｌｌ」である。これに対し、本実施形態においては、図６を参照して説明するように、この「ｄｉｎｆ」を活用することで顕著な効果を得ることができる。

図６は、本実施形態においてファイル生成部１２０により生成されるＭＰ４ファイルの構成を示した説明図である。図６に示したように、ファイル生成部１２０は、同一コンテンツに関し、ビットレートが異なる「ｍｄａｔ」を含む複数のＭＰ４ファイルＡ〜ＭＰ４ファイルＣを生成する。

本実施形態では、セグメントはビデオのＭＰ４ Ｓｙｎｃ Ｓａｍｐｌｅを境界にして分割されたデータであり、セグメント中には映像符号化データと音声符号化データがインターリーブして配置されている。セグメントは、コンテンツが再生される時系列に連続的にｍｄａｔに配列されている。ビットレートが異なる各データファイルのセグメントの再生時間は同じになるように符号化されている。また、セグメントの先頭にはＡＶＣ／Ｈ．２６４の場合はＩＤＲピクチャーが存在するように配置され、セグメント単位で、ビットレートの異なるデータに切り替えることができる。

なお、各セグメントの位置はＳｙｎｃ Ｓａｍｐｌｅの位置であり、コンテンツ再生装置２０は、「ｍｏｏｖ」のＳａｍｐｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ ｂｏｘの情報、もしくは、それに含まれるＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅｂｏｘと組み合わせによって得られるセグメント位置を元に、各データファイルから、セグメントデータの読み込みを行える。本実施形態では１つのビデオフレームを一つのＳａｍｐｌｅとし、３０フレームに一回ＩＤＲピクチャーが存在するＳａｍｐｌｅであるＳｙｎｃ Ｓａｍｐｌｅとなるようにし、Ｓａｍｐｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ ｂｏｘにはＳｙｎｃ ｓａｍｐｌｅ ｔａｂｌｅ ｂｏｘを設ける。

ＭＰ４ファイルＢ（第１のデータファイル）の「ｍｄａｔ」は、ビットレートが１．５ＭｂｐｓであるセグメントＢ１〜Ｂｎで構成され、ＭＰ４ファイルＣの「ｍｄａｔ」（第２のデータファイル）は、ビットレートが１ＭｂｐｓであるセグメントＣ１〜Ｃｎで構成され、ＭＰ４ファイルＡ（第３のデータファイル）の「ｍｄａｔ」は、ビットレートが２ＭｂｐｓであるセグメントＡ１〜Ａｎで構成される。

また、ＭＰ４ファイルＢの「ｍｏｏｖ」は、同一ファイルを構成するセグメントＢ１〜Ｂｎにアクセスするための「ｔｒａｋ（ｖｉｄｅｏ）Ｂ」や「ｔｒａｋ（ａｕｄｉｏＢ）」を含む。

さらに、ＭＰ４ファイルＢの「ｍｏｏｖ」は、ＭＰ４ファイルＣを構成するセグメントＣ１〜Ｃｎにアクセスするための「ｔｒａｋ（ｖｉｄｅｏＣ’）」および「ｔｒａｋ（ａｕｄｉｏＣ’）」を含む。

すなわち、この「ｔｒａｋ（ｖｉｄｅｏＣ’）」および「ｔｒａｋ（ａｕｄｉｏＣ’）」の「ｄｉｎｆ」には、ＭＰ４ファイルＣのＵＲＬが記載される。より具体的には、以下に示す「ｄｉｎｆ」の構文中の‘ｌｏｃａｔｉｏｎ’の欄にＭＰ４ファイルＣのＵＲＬが記載される。また、「ｔｒａｋ（ＶｉｄｅｏＣ’）」および「ｔｒａｋ（ａｕｄｉｏＣ’）」に記載されている映像トラックのＳａｍｐｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｂｏｘの情報から、各ＳａｍｐｌｅおよびＳｙｎｃ ＳａｍｐｌｅセグメントＣ１〜Ｃｎの位置情報（ファイル内でのバイトオフセット）が得られる。

（構文例）
aligned(8)
class DataEntryUrlBox (bit(24) flags) extends FullBox(‘url ’,
version
= 0, flags) {
string location;
}

同様に、ＭＰ４ファイルＢの「ｍｏｏｖ」は、ＭＰ４ファイルＡを構成するセグメントＡ１〜Ａｎにアクセスするための「ｔｒａｋ（ｖｉｄｅｏＡ’）」および「ｔｒａｋ（ａｕｄｉｏＡ’）」を含む。すなわち、この「ｔｒａｋ（ｖｉｄｅｏＡ’）」および「ｔｒａｋ（ａｕｄｉｏＡ’）」の「ｄｉｎｆ」には、ＭＰ４ファイルＡのＵＲＬが記載される。

なお、ＭＰ４ファイルＡにも、ＭＰ４ファイルＡを構成するセグメントＡ１〜Ａｎにアクセスするための「ｔｒａｋ（ｖｉｄｅｏＡ）」および「ｔｒａｋ（ａｕｄｉｏＡ）」が含まれるが、コンテンツ再生装置２０は、これらは後述の適応的なストリーミングには利用しない。

同様に、ＭＰ４ファイルＣにもＭＰ４ファイルＣを構成するセグメントＣ１〜Ｃｎにアクセスするための「ｔｒａｋ（ｖｉｄｅｏＣ）」および「ｔｒａｋ（ａｕｄｉｏＣ）」が含まれるが、コンテンツ再生装置２０は、これらは後述の適応的なストリーミングには利用しない。

上述したように、本実施形態においては、異なるビットレートを有する「ｍｄａｔ」を、同一のＭＰ４ファイルでなく、異なるＭＰ４ファイルに作成する。また、１のＭＰ４ファイルに、他のＭＰ４ファイルに含まれる「ｍｄａｔ」を参照するためのＵＲＬおよび各セグメントのファイル内でのオフセット情報がＳａｍｐｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ ｂｏｘに記載される。

かかる構成により、本実施形態によるＭＰ４ファイルを、ストリーミング用だけでなく、ダウンロード用としても支障なく利用することが可能となる。その理由を、異なるビットレートを有する複数の「ｍｄａｔ」を同一ファイルに生成する場合と比較して説明する。

異なるビットレートを有する複数の「ｍｄａｔ」を同一ファイルに生成し、当該ファイルをダウンロード用としても利用する場合、クライアントは、複数の「ｍｄａｔ」を含む当該ファイル全体をダウンロードすることとなる。このため、ダウンロードデータ量およびダウンロード時間が不要に倍増してしまうという問題が生じる。

これに対し、本実施形態においては、ビットレートが異なる複数の「ｍｄａｔ」のうちで、１の「ｍｄａｔ」のみを含むＭＰ４ファイルをダウンロードすることができる。例えば、コンテンツ再生装置２０は、ビットレートが異なる複数の「ｍｄａｔ」のうちでハイビットレートの「ｍｄａｔ」のみを含むＭＰ４ファイルＡをダウンロードすることができる。したがって、クライアントは、ダウンロードデータ量およびダウンロード時間を抑制してダウンロードを行うことが可能となる。

なお、ファイル生成部１２０は、ファイルＢの「ｍｏｏｖ」中の各トラックの「ｍｉｎｆｏ」に、各「ｔｒａｋ」の参照先のメディアデータが、異なるビットレートでの符号化により得られた代替可能なメディアデータのグループに属するか否かを示す情報を記載してもよい。例えば、以下に示す「ｍｉｎｆｏ」の構文中の以下の拡張ブロックを設け、“ａｌｔｅｒｎａｔｉｖｅ＿ｍｅｄｉａ＿ｇｒｏｕｐ”には、代替可能なメディアデータのグループの識別番号を記載し、「ｅｘｔｅｎｄｅｄ＿ｔｙｐｅ」に「＜ｕｕｉｄ＿ｖａｌｕｅ＞：Ｔ．Ｂ．Ｄ」と記載し、「ｆｌａｇｓ」に「０」と記載してもよい。コンテンツ再生装置２０は、代替可能なメディアデータのグループに属するメディアデータのセグメントは、同一のグループに属する他のメディアデータ中の対応セグメントで代替可能であることを認識できる。また、メディアの最大ビットレートmaxbitrateおよび平均ビットレートavgbitrateが記載されており、コンテンツ再生装置２０が、どの符号化データのセグメントを取得するかに判断に利用できる。

（構文例）
aligned(8) class
AlternateMediaInformationBox extends FullBox(‘uuid’, version=0,
flags
= 0, extended_type){
unsigned
int(32) alternative_media_group;
unsigned int(32)
maxbitrate;
unsigned int(32)
avgbitrate;
}

かかる構成により、コンテンツ再生装置２０は、ＭＰ４ファイルの「ｍｏｏｖ」中の「ｍｉｎｆｏ」を確認することにより、当該ＭＰ４ファイルが本実施形態の方法により生成されたものであるかを判断することができる。そして、当該ＭＰ４ファイルが本実施形態の方法により生成されたものである場合、コンテンツ再生装置２０は、後述するように適応的なストリーミングをコンテンツサーバ１０に対して要求することが可能となる。

また、図６においては、ＭＰ４ファイルが主に「ｍｏｏｖ」と「ｍｄａｔ」から構成される例を示したが、ＭＰ４ファイルの構成はかかる例に限定されない。例えば、図６に示した「ｍｏｏｖ」に含まれるアクセス情報を、図７に示すように「ｍｏｏｖ」と「ｍｏｏｆ」を用いて分散的に配置してもよい。

図７は、本実施形態においてファイル生成部１２０により生成されるＭＰ４ファイルの変形例を示した説明図である。図７に示したように、各ファイルの先頭には「ｍｏｏｖ」が配置され、以降、「ｍｄａｔ」と「ｍｏｏｆ」が交互に配置される。ＭＰ４ファイルＢの「ｍｏｏｖ」には、前述したＭＰ４ファイルの構造と同様に、ＭＰ４ファイルＢとＡとＣの各セグメントにアクセス情報が記載された「ｔｒａｋ」および後続の「ｍｄａｔ」へアクセスするための「Ｓａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ ｂｏｘが含まれる。また、ＭＰ４ファイルＢの各「ｍｏｏｆ」には、「ｍｏｏｖ」に記載された「ｔｒａｋ」に対応した複数の「ｔｒａｆ」を含み、「ｔｒａｆ」にはそれぞれのファイルの後続する「ｍｄａｔ」の各セグメントにアクセスするための情報を含む。なお、ＭＰ４ファイルＣ，Ａにも「ｍｏｏｖ」、「ｍｏｏｆ」は記載されても良いが、前例と同様に、コンテンツ再生装置２０は、適応ストリーミングでは使用しない。

このようにアクセス情報を分散的に配置することにより、ＭＰ４ファイルＢの先頭「ｍｏｏｖ」および各「ｍｏｏｆ」のデータ量を小さくすることができ、先頭の「ｍｏｏｖ」取得時間の抑制ならび、コンテンツ再生装置２０がバッファ２３０に保持する「ｍｏｏｖ」および「ｍｏｏｆ」の情報を減少させることができる。また、「ｍｏｏｆ」および対応のndatは独立して生成することができるため、生放送などのライブコンテンツのストリーミングに利用できる。本実施形態は、「ｍｏｏｖ」、「ｍｏｏｆ」および「ｍｄａｔ」を分散的に配置する図７に示したフォーマットにも適用可能である。

ここで図４を参照してコンテンツサーバ１０の構成の説明に戻る。図４に示したコンテンツサーバ１０の記憶部１３０は、ファイル生成部１２０により生成された複数のＭＰ４ファイルを記憶する記憶媒体である。

例えば、記憶部１３０は、不揮発性メモリ、磁気ディスク、光ディスク、およびＭＯ（Ｍａｇｎｅｔｏ Ｏｐｔｉｃａｌ）ディスクなどの記憶媒体であってもよい。不揮発性メモリとしては、例えば、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ）があげられる。また、磁気ディスクとしては、ハードディスクおよび円盤型磁性体ディスクなどがあげられる。また、光ディスクとしては、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ、ＤＶＤ−Ｒ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ Ｒｅｃｏｒｄａｂｌｅ）およびＢＤ（Ｂｌｕ−Ｒａｙ Ｄｉｓｃ（登録商標））などがあげられる。

通信部１４０は、コンテンツ再生装置２０とのインターフェースであって、ネットワーク１２を介してコンテンツ再生装置２０と通信する。より詳細には、通信部１４０は、ＨＴＴＰに従ってコンテンツ再生装置２０と通信するＨＴＴＰサーバとしての機能を有する。例えば、通信部１４０は、ＨＴＴＰに従ってコンテンツ再生装置２０から要求されたデータを記憶部１３０から抽出し、ＨＴＴＰレスポンスとしてコンテンツ再生装置２０にデータを送信する。

＜４．コンテンツ再生装置の機能＞
以上、本実施形態によるコンテンツサーバ１０の機能を説明した。続いて、図８を参照し、本実施形態によるコンテンツ再生装置２０の機能を説明する。

図８は、本実施形態によるコンテンツ再生装置２０の構成を示した機能ブロック図である。図８に示したように、本実施形態によるコンテンツ再生装置２０は、取得部２２０と、バッファ２３０と、再生部２４０と、選択部２５０と、を備える。

取得部２２０は、コンテンツサーバ１０とのインターフェースであって、コンテンツサーバ１０に対してデータを要求し、コンテンツサーバ１０からデータを取得する。より詳細には、取得部２２０は、ＨＴＴＰに従ってコンテンツ再生装置２０と通信するＨＴＴＰクライアントとしての機能を有する。例えば、取得部２２０は、ＨＴＴＰ Ｒａｎｇｅを利用することにより、コンテンツサーバ１０からＭＰ４ファイルの一部（ｍｏｏｖやセグメント）を部分的に取得することができる。

バッファ２３０は、取得部２２０によりコンテンツサーバ１０から取得されるセグメントを順次にバッファリングする。バッファ２３０にバッファリングされたセグメントは、ＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）で再生部２４０へ順次に供給される。

再生部２４０は、バッファ２３０から供給されるセグメントを順次に再生する。具体的には、再生部２４０は、セグメントのデコード、ＤＡ変換、およびレンダリングなどを行う。

選択部２５０は、いずれのＭＰ４ファイルを構成するセグメントを取得するか、すなわち、いずれのビットレートを有するセグメントを取得するかを、ネットワーク１２の状況に応じて同一コンテンツ内で順次に選択する。例えば、選択部２５０がセグメント「Ａ１」、「Ｂ２」、「Ａ３」を順次に選択すると、図２に示したように、取得部２２０がコンテンツサーバ１０からセグメント「Ａ１」、「Ｂ２」、「Ａ３」を順次に取得する。

なお、取得部２２０は、セグメントの取得に先立ってＭＰ４ファイルの「ｍｏｏｖ」を取得しており、選択部２５０により選択されたセグメントを当該「ｍｏｏｖ」に含まれるアクセス情報を指定してコンテンツサーバ１０から取得することができる。

ここで、ネットワーク１２の帯域が大きくなるとバッファ２３０のバッファリングデータ量が増加し、帯域が小さくなるとバッファ２３０のバッファリングデータ量が減少すると考えられる。そこで、選択部２５０は、バッファ２３０のバッファリング状況を監視することで、ネットワーク１２の状況を間接的に把握してもよい。

例えば、選択部２５０は、バッファ２３０にバッファリングされているサンプル数（ビデオフレーム数）が所定範囲内である場合、すなわち、バッファ２３０にバッファリングされているサンプルで再生可能な時間が所定範囲内である場合には、標準ビットレート（例えば、１．５Ｍｂｐｓ）のセグメントを選択してもよい。例えば、コンテンツ再生装置２０は、標準ビットレート９０個のサンプル（３秒分）を一時蓄積してから、ストリーミングの再生を開始し、後続のセグメントデータを読み続けながら再生を続けるが、その再生中にバッファ２３０のデータが７５個から１０５個のサンプルの範囲内にある場合は、標準のビットレートのセグメントを選択する。

一方、選択部２５０は、バッファリング量が減少し、バッファ２３０にバッファリングされているサンプルで再生可能な時間が所定範囲を下回った場合、ロービットレート（例えば、１Ｍｂｐｓ）のセグメントを選択してもよい。例えば、選択部２５０は、再生中にバッファ２３０のデータが７５個のサンプル以下になった場合は、ロービットレートのセグメントを選択する。

また、選択部２５０は、バッファリング量が増加し、バッファ２３０にバッファリングされているサンプルで再生可能な時間が所定範囲を上回った場合、ハイビットレート（例えば、２Ｍｂｐｓ）のセグメントを選択してもよい。例えば、選択部２５０は再生中にバッファ２３０のデータが１０５個サンプル以上になった場合は、ハイビットレートのセグメントを選択する。さらに、バッファ２３０中のセグメントが１２０個と十分になった場合には、読み込みを一時中断し、１２０個以下になった場合に再開する。

なお、上記ではネットワーク１２の帯域の判断方法の一例としてバッファ２３０のバッファリング状況を監視する例を説明したに過ぎず、本実施形態はかかる例に限定されない。例えば、コンテンツ再生装置１０は、実際にダミーパケットをネットワーク１２に送信することによりネットワーク１２の帯域を判断しても、取得部２２０によるセグメントの取得速度に基づいてネットワーク１２の帯域を判断してもよい。

＜５．コンテンツ再生システムの動作＞
以上、本実施形態によるコンテンツサーバ１０およびコンテンツ再生装置２０の機能を説明した。続いて、本実施形態によるコンテンツ再生システム１の動作について図９を参照して説明する。

図９は、本実施形態によるコンテンツ再生システム１の動作を示したシーケンス図である。まず、コンテンツ再生装置２０の取得部２２０は、「ＨＴＴＰ：ＧＥＴ ＵＲＬ−Ｂ ｗｉｔｈ Ｒａｎｇｅ」により、コンテンツサーバ１０に対してあるコンテンツに関するＭＰ４ファイルＢの「ｍｏｏｖ」の送信を要求する（Ｓ３０４）。そして、コンテンツサーバ１０の通信部１４０は、「ＨＴＴＰ：Ｒｅｓｐｏｎｓｅ」として、ＭＰ４ファイルＢの「ｍｏｏｖ」をコンテンツ再生装置２０に送信する（Ｓ３０８）。なお、ＭＰ４ファイルＢのＵＲＬ−Ｂは、コンテンツのメタデータ情報に記載されて、コンテンツ再生装置２０は事前に取得済であるものとする。そして、コンテンツ再生装置２０のバッファ２３０が、コンテンツサーバ１０から取得されるＭＰ４ファイルＢの「ｍｏｏｖ」のバッファリングを開始する（Ｓ３１０）。

ここで、コンテンツ再生装置２０の選択部２５０は、「ｍｏｏｖ」中の「ｍｉｎｆｏ」を確認することにより、「ｍｏｏｖ」中の「ｔｒａｋ」の参照先のファイルが、異なるビットレートでの符号化により得られた代替メディアグループに属しているか否かを判断することができる。

そして、「ｍｏｏｖ」中の「ｔｒａｋ」の参照先のファイルが異なるビットレートでの符号化により得られた代替メディアグループに属している場合、選択部２５０は、標準ビットレートを有するＭＰ４ファイルＢのセグメントＢｉを選択する。

続いて、取得部２２０が、「ＨＴＴＰ：ＧＥＴ ＵＲＬ−Ｂ ｗｉｔｈ Ｒａｎｇｅ」を用い、選択部２５０により選択されたＭＰ４ファイルＢのセグメントＢｉをコンテンツサーバ１０に要求する（Ｓ３１２）。具体的には、取得部２２０は、ＭＰ４ファイルＢのネットワーク位置情報、ＭＰ４ファイルＢにおけるセグメントＢｉのバイト単位での位置情報指定することにより、ＭＰ４ファイルＢのセグメントＢｉをコンテンツサーバ１０に要求する。なお、ＭＰ４ファイルＢのネットワーク位置情報、ＭＰ４ファイルＢにおけるセグメントＢｉのバイト単位での位置情報などは、Ｓ３０８で受信されるＭＰ４ファイルＢの「ｍｏｏｖ」に記載されている。そして、コンテンツサーバ１０の通信部１４０は、「ＨＴＴＰ：Ｒｅｓｐｏｎｓｅ」として、ＭＰ４ファイルＢのセグメントＢｉをコンテンツ再生装置２０に送信する（Ｓ３１６）。

その後、コンテンツ再生装置２０のバッファ２３０にセグメントＢｉが十分にバッファリングされると、再生部２４０がセグメントＢｉの再生を開始する（Ｓ３２０）。なお、バッファリング開始時（Ｓ３１０）から、ある一定の時間たたっても十分なバッファの読み出しができない場合は、ネットワーク帯域が十分でないと考えられる。そこで、このような場合は、Ｓ３１６から後続するセグメントの読み込みをファイルＣのセグメントに切り替えてもよい。同様に、早く所定のセグメントをバッファリングできると判断した場合は、ファイルＡのセグメントをバッファリングしてから再生を開始する（Ｓ３２０）ことも可能である。

同様に、コンテンツ再生装置２０の取得部２５０は、「ＨＴＴＰ：ＧＥＴ ＵＲＬ−Ｂ ｗｉｔｈ Ｒａｎｇｅ」を用い、次のセグメントＢｊをコンテンツサーバ１０に要求する（Ｓ３２４）。そして、コンテンツサーバ１０の通信部１４０は、「ＨＴＴＰ：Ｒｅｓｐｏｎｓｅ」として、次のセグメントＢｊをコンテンツ再生装置２０に送信する（Ｓ３２８）。

ここで、バッファ２３０のバッファリング量が減少し、バッファ２３０にバッファリングされているサンプルで再生可能な時間が所定範囲を下回った場合（Ｓ３３２）、選択部２５０は、ロービットレートを有するＭＰ４ファイルＣのセグメントＣｋを選択する。

そして、取得部２２０が、「ＨＴＴＰ：ＧＥＴ ＵＲＬ−Ｃ ｗｉｔｈ Ｒａｎｇｅ」を用い、選択部２５０により選択されたＭＰ４ファイルＣのセグメントＣｋをコンテンツサーバ１０に要求する（Ｓ３３６）。当該要求を受けたコンテンツサーバ１０の通信部１４０は、「ＨＴＴＰ：Ｒｅｓｐｏｎｓｅ」として、ＭＰ４ファイルＣのセグメントＣｋをコンテンツ再生装置２０に送信する（Ｓ３４０）。

その後、バッファ２３０のバッファリング量が増加し、バッファ２３０にバッファリングされているサンプルで再生可能な時間が所定範囲になった場合（Ｓ３４４）、選択部２５０は、標準ビットレートを有するＭＰ４ファイルＢのセグメントＢｌを選択する。

続いて、取得部２２０が、「ＨＴＴＰ：ＧＥＴ ＵＲＬ−Ｂ ｗｉｔｈ Ｒａｎｇｅ」を用い、選択部２５０により選択されたＭＰ４ファイルＢのセグメントＢｌをコンテンツサーバ１０に要求する（Ｓ３４８）。そして、コンテンツサーバ１０の通信部１４０は、「ＨＴＴＰ：Ｒｅｓｐｏｎｓｅ」として、ＭＰ４ファイルＢのセグメントＢｌをコンテンツ再生装置２０に送信する（Ｓ３５２）。

さらにその後、バッファ２３０のバッファリング量が増加し、バッファ２３０にバッファリングされているサンプルで再生可能な時間が所定範囲を上回った場合（Ｓ３５６）、選択部２５０は、ハイビットレートを有するＭＰ４ファイルＡのセグメントＡｍを選択する。

続いて、取得部２２０が、「ＨＴＴＰ：ＧＥＴ ＵＲＬ−Ａ ｗｉｔｈ Ｒａｎｇｅ」を用い、選択部２５０により選択されたＭＰ４ファイルＡのセグメントＡｍをコンテンツサーバ１０に要求する（Ｓ３６０）。そして、コンテンツサーバ１０の通信部１４０は、「ＨＴＴＰ：Ｒｅｓｐｏｎｓｅ」として、ＭＰ４ファイルＡのセグメントＡｍをコンテンツ再生装置２０に送信する（Ｓ３５２）。

以降も同様に、バッファ２３０のバッファリング量に応じて選択部２５０がいずれのビットレートを有するセグメントを要求するかを選択し、選択部２５０により選択されたセグメントを取得部２２０がコンテンツサーバ１０から取得する。

かかる構成により、ネットワーク１２の帯域が小さい場合に再生が途切れてしまうことを防止し、また、ネットワーク１２の帯域が大きい場合には高品質な再生を実現することができる。また、本実施形態においては、ネットワーク１２の帯域判断、および要求するセグメントの選択をコンテンツ再生装置２０側で行うことができるため、コンテンツサーバ１０の負荷軽減を図ることが可能である。

＜６．変形例＞
上記では、「ｔｒａｋ」中の「ｄｉｎｆ」を用いて他ファイルの「ｍｄａｔ」へのアクセスを可能とする例を説明したが、図１０を参照して説明するように、「ｔｒａｋ」を用いて他ファイルの「ｔｒａｋ」を参照できるようにしてもよい。

図１０は、本実施形態においてファイル生成部１２０により生成されるＭＰ４ファイルの変形例を示した説明図である。図１０に示したように、ＭＰ４ファイルＢの「ｔｒａｋ」にＭＰ４ファイルＡの「ｔｒａｋ」へのアクセス情報を記載すると、コンテンツ再生装置２０は、ＭＰ４ファイルＢの「ｔｒａｋ」を解析し、記載されているアクセス情報を用いてＭＰ４ファイルＡの「ｔｒａｋ」を取得することができる。このため、コンテンツ再生装置２０は、ＭＰ４ファイルＡの「ｔｒａｋ」およびそこに記載されているＳａｍｐｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｂｏｘに基づき、セグメントＡ１、Ａ２、・・・を取得することも可能となる。

同様に、ＭＰ４ファイルＢの「ｔｒａｋ」にＭＰ４ファイルＣの「ｔｒａｋ」へのアクセス情報を記載すると、コンテンツ再生装置２０は、ＭＰ４ファイルＢの「ｔｒａｋ」を解析し、記載されているアクセス情報を用いてＭＰ４ファイルＣの「ｔｒａｋ」を取得することができる。このため、コンテンツ再生装置２０は、ＭＰ４ファイルＣの「ｔｒａｋ」およびそこに記載されているＳａｍｐｌｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｂｏｘに基づき、に基づいてセグメントＣ１、Ｃ２、・・・を取得することも可能となる。

具体的には、ＭＰ４ファイルフォーマットを拡張し、以下に示す拡張ボックスを「ｍｉｎｆｏ」に記載し、構文中の「ｅｘｔｅｎｄｅｄ＿ｔｙｐｅ」に「＜ｕｕｉｄ＿ｖａｌｕｅ＞：Ｔ．Ｂ．Ｄ」と記載し、「ｌｏｃａｔｉｏｎ」に参照先のＭＰ４ファイルのＵＲＬを記載し、「ｔｒａｃｋ＿ＩＤ」に参照先のＭＰ４ファイルにおける「ｔｒａｋ」の識別子を記載してもよい。これにより、コンテンツ再生装置２０は、ファイルＢのトラックのメディアデータとして代替可能なメディアデータがトラックＣのｔｒａｃｋ＿ｉｄに示されるトラックにあることを認識できる。また、メディアの最大ビットレートmaxbitrateおよび平均ビットレートavgbitrateなどのビットレート情報が記載されており、コンテンツ再生装置２０が、どの符号化データのセグメントを取得するかに判断に利用できる。

（構文例）
aligned(8)
class AlternateMediaReferenceBox extends FullBox(‘uuid’, version=0,
flags = 0, extended_type){unsigned
int(32) entry_count;
for
(i=1; i ・
entry_count; i++) {
string
location; // URL
unsigned
int(32) track_ID;
unsigned int(32)
maxbitrate;
unsigned int(32)
avgbitrate;
}

}

なお、上記構成は、「ｍｏｏｖ」に含まれるアクセス情報を、「ｍｏｏｖ」と「ｍｏｏｆ」を用いて分散的に配置するファイルフォーマットにも同様に適用可能である。この場合、図１１に示すように、「ｔｒａｋ」に他ファイルの「ｔｒａｋ」へのアクセス情報を記載することにより、ＭＰ４ファイルＢの「ｔｒａｋ」を用いて、他のファイルの「ｔｒａｋ」および「ｔｒａｆ」にアクセスすることが可能となる。

図１１は、本実施形態においてファイル生成部１２０により生成されるＭＰ４ファイルの変形例を示した説明図である。図１１に示したように、ＭＰ４ファイルＢの「ｔｒａｋ」にＭＰ４ファイルＡの「ｔｒａｋ」へのアクセス情報を記載すると、コンテンツ再生装置２０は、ＭＰ４ファイルＢの「ｔｒａｋ」を解析し、記載されているアクセス情報を用いてＭＰ４ファイルＡの「ｔｒａｋ」を取得することができる。このため、コンテンツ再生装置２０は、ＭＰ４ファイルＡの「ｔｒａｋ」に基づいてセグメントＡ１１、Ａ１２、・・・を取得することも可能となる。

同様に、ＭＰ４ファイルＢの「ｔｒａｋ」にＭＰ４ファイルＣの「ｔｒａｋ」へのアクセス情報を記載すると、コンテンツ再生装置２０は、ＭＰ４ファイルＢの「ｔｒａｋ」を解析し、記載されているアクセス情報を用いてＭＰ４ファイルＣの「ｔｒａｋ」を取得することができる。このため、コンテンツ再生装置２０は、ＭＰ４ファイルＣの「ｔｒａｋ」および各「ｔｒａｆ」に基づいてセグメントＣ１１、Ｃ１２、・・・を取得することも可能となる。なお、各ファイルの「ｍｏｏｆ」のファイル中の位置は、コンテンツ再生装置２０がＭＰ４ファイルのＢＯＸ構造を解析することによりも可能であるが、ＭＰ４ファイルに記載されたＭｏｖｉｅ Ｆｒａｇｍｅｎｔ Ｒａｎｄｏｍ ａｃｃｅｓｓ ｂｏｘを利用して、各ｍｏｏｆの位置情報を取得して該当のｍｏｏｆ情報を取得後に、ｍｏｏｆに後続のｍｄａｔの各セグメントにアクセスしても良い。また、ｍｏｏｆ情報を先読みして「ｔｒａｆ」を解析しておくことで、「ｍｏｏｆ」直後のmdatを時間的遅延なしに読み出し可能である。

＜７．まとめ＞
以上説明したように、本実施形態においては、コンテンツ再生装置２０の選択部２５０がいずれのビットレートを有するセグメントを要求するかをネットワーク１２の帯域に応じて選択し、選択されたセグメントを取得部２２０がコンテンツサーバ１０から取得する。したがって、本実施形態によれば、コンテンツサーバ１０の負荷軽減を図ることが可能である。

また、本実施形態の大部分は、ＨＴＴＰやＭＰ４などの既存の規格に準拠するものである。したがって、本実施形態は、既存のＨＴＴＰおよびＭＰ４を利用するストリーミングと互換性を有し、かつ、拡張機能を最小限に抑制できるため、円滑な導入が期待される。

また、本実施形態においては、異なるビットレートを有する「ｍｄａｔ」を、同一のＭＰ４ファイルでなく、異なるＭＰ４ファイルに作成する。このため、各ＭＰ４ファイルを、ストリーミング用としてだけでなく、ダウンロード用としても支障なく利用することが可能である。

なお、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

例えば、本明細書のコンテンツ再生システム１の処理における各ステップは、必ずしもシーケンス図として記載された順序に沿って時系列に処理する必要はない。例えば、コンテンツ再生システム１の処理における各ステップは、シーケンス図として記載した順序と異なる順序で処理されても、並列的に処理されてもよい。

また、コンテンツ再生装置２０およびコンテンツサーバ１０に内蔵されるＣＰＵ２０１、ＲＯＭ２０２およびＲＡＭ２０３などのハードウェアを、上述したコンテンツ再生装置２０およびコンテンツサーバ１０の各構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供される。

また、本実施例では、図６，７、１０，１１に示す通り、第１のデータファイルは標準ビットレートの符号化データを配置したが、ロービットレート、または、ハイビットレートの符号化データを配置してもよい。

また、本実施例では、図６，７、１０，１１に示す通り、第１のデータファイルに符号化データを配置したが、第１のデータファイルのmoofにはそれら符号化データへのアクセス情報のみを配置するようにしてもよい。

また、本実施例では、図７に示すように「ｍｏｏｖ」、「ｍｏｏｆ」および「ｍｄａｔ」を分散的に配置する例を示したが、第１のデータファイルのみ分散的に配置し、他のデータファイルは図８に示すように「ｍｏｏｖ」およびそれに対応する「ｍｄａｔ」から構成されるように配置してもよい。

さらに、第１のデータファイルに符号化データが含まれない場合の実施例を図１２に示す。第１のデータファイルには、他のデータファイルに配置された符号化データの各セグメントのアクセス情報が記載されている。また、第１のデータファイルには「ｍｏｏｖ」および「ｍｏｏｆ」を利用してアクセス情報が分散化されるように配置され、各「ｍｏｏｆ」にはただ１つのデータファイルのセグメントへのアクセス情報のみを記載されている。

この場合は、映像トラック、音声トラック、各々の「ｔｒａｆ」には各セグメントのアクセス情報が各「ｍｏｏｆ」に記載されており、連続して配置された「ｍｏｏｆ」の組（この場合は３組）にある範囲のセグメントに対するアクセス情報が記載される。

図１２に示した例では、「ｍｏｏｖ」の各「ｔｒａｋ」にはセグメントへのアクセス情報が含まれず、次の３つの「ｍｏｏｆ」にセグメント１からセグメント（ｉ−１）へのアクセス情報が記載される。同様に、さらに次の３つの「ｍｏｏｆ」にセグメントｉからセグメント（ｊ−１）へのアクセス情報が記載され、さらに次の３つの「ｍｏｏｆ」がセグメントｊからセグメント（ｋ−１）へのアクセス情報が記載される。なお、「ｍｏｏｖ」中の「ｔｒａｋ」の配置順序（すなわち、Ｂ、Ｃ、Ａ）と、３つの「ｍｏｏｆ」中の「ｔｒａｆ」の配置順序（すなわち、Ｂ、Ｃ、Ａ）は一致しているので、「ｔｒａｆ」の読み込みが容易になる。

このように第１データファイルを構成することによって、セグメントへのアクセス情報が第１のデータファイルを解析することのみによって容易に得られる。また、各データファイルのセグメント情報も「ｍｏｏｆ」の単位で分割されているために、コンテンツ再生装置２０は、すべてのデータファイルのセグメントのアクセス情報を保持することなく、必要なデータファイルの「ｍｏｏｆ」のみを取得ならび、保持することで、ネットワーク状況に合わせて適切なビットレートのデータファイルを選択しながら、適応ストリーミングを行うことが可能となる。

また、符号化データを含まないデータファイルは「ｍｏｏｆ」による分散化がされておらず、「ｍｏｏｖ」と「ｍｄａｔ」によって構成されるために、既存のＨＴＴＰおよびＭＰ４を利用するストリーミングのみをサポートするコンテンツ再生装置のために、これらデータファイルは利用することができる。

一方、第１のデータファイルには符号化データが含まれないため、既存のコンテンツ再生装置の場合では再生できないなどの問題を考慮し、コンテンツ再生装置が適応ストリーミングに対応している場合は第１のＭＰ４ファイル、そうでない場合は分散化されていなＭＰ４ファイルが再生されるような仕組みを設けてもよい。例えば、コンテンツ再生装置に、各ＵＲＬと属性を開示させ、コンテンツ再生装置の能力と属性に基づいてＵＲＬ選ぶ方法などがある。

１ コンテンツ再生システム
１０ コンテンツサーバ
１２ ネットワーク
２０ コンテンツ再生装置
１２０ ファイル生成部
１２２ エンコーダ
１３０ 記憶部
１４０ 通信部
２２０ 取得部
２３０ バッファ
２４０ 再生部
２５０ 選択部

Claims (8)

1. 異なるビットレートであり、複数のセグメントから構成される、複数のコンテンツのそれぞれにおける前記複数のセグメントに関する所在情報を、他の機器に送信する送信部と、
   前記セグメントの所在情報を、前記他の機器から受信する受信部と、
   前記送信部は、前記受信部により受信された前記セグメントの所在情報に基づいて、前記セグメントを前記他の機器に送信する、情報処理装置。
2. 前記送信部は、前記複数のセグメントに関する所在情報をHTTPに従って送信し、前記受信部は、前記セグメントの所在情報をHTTPに従って受信する請求項１に記載の情報処理装置。
3. 前記コンテンツは、エンコードされたオーディオデータ、またはエンコードされた
   映像データのいずれかである請求項１に記載の情報処理装置。
4. 前記送信部は、前記ビットレートを表す情報をさらに送信する、請求項１に記載の情報処理装置。
5. 前記所在情報はＵＲＬである、請求項１に記載の情報処理装置。
6. 前記セグメントは、MP4ファイルフォーマットのmoofとmdatにより定義される、請求項１に記載の情報処理装置。
7. 異なるビットレートであり、複数のセグメントから構成される、複数のコンテンツのそれぞれにおける前記複数のセグメントに関する所在情報を、他の機器に送信することと、
   前記セグメントの所在情報を、前記他の機器から受信することと、
   受信された前記所在情報に基づいてセグメントを前記他の機器に送信することと、
   を含む、情報処理装置により実行される情報処理方法。
8. コンピュータに、
   異なるビットレートであり、複数のセグメントから構成される、複数のコンテンツのそれぞれにおける前記複数のセグメントに関する所在情報を、他の機器に送信することと、
   前記セグメントの所在情報を、前記他の機器から受信することと、
   受信された前記所在情報に基づいてセグメントを前記他の機器に送信することと、
   を実行させるための、プログラム。
   

Images