JP4619353B2 - マルチメディアコンテンツを配信するためのシステム - Google Patents

Description

本発明は、クライアント装置にマルチメディアコンテンツを配信するための通信システムに関する。本発明はまた、そのようなシステムで利用されるサーバに関する。本発明はさらに、そのようなサーバからマルチメディアコンテンツをリクエストするためのクライアント装置に関する。最後に、本発明は、当該システムに利用される方法に関する。

本発明は、例えば、インターネットやモバイルネットワークを介しクライアントにライブのマルチメディアコンテンツを配信するためのアプリケーションを見出す。

ライブ音声、映像及びあらゆる種類のマルチメディアコンテンツのインターネットを介したストリーミングが、普及してきている。図１に示されるように、ストリーミングセッションは、ライブのマルチメディアコンテンツをリアルタイムに符号化し、符号化されたデータストリームを供給するリアルタイムエンコーダ、エンコーダとストリーミングサーバとの間の配信接続、及びサーバと複数のクライアントの間の複数のポイント・ツー・ポイント接続を伴う。ＩＰネットワークを介したこのようなリアルタイムの送信に利用される標準的なプロトコルは、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）である。この符号化されたデータストリームは、サーバ及びさらにはクライアントに送信されるＲＴＰパケットに変換される。

ＲＴＰプロトコルによって提起される問題は、ＲＴＰパケットがしばしばファイアウォール及びＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｏｒ）によってブロックされることである。この結果、クライアントは、リクエストされたマルチメディアコンテンツを受信することができなくなる。

この問題を回避する１つの解決手段は、Ｍａｔｈｉａｓ Ｊｏｈａｎｓｏｎによる「Ａｎ ＲＴＰ ｔｏ ＨＴＴＰ ｖｉｄｅｏ ｇａｔｅｗａｙ」（ＡＣＭ，１−５８１１３−３４８−０／０１／０００５，２００１）による刊行物からすでに知られている。当該解決手段は、ＲＴＰパケットをサーバのウェブページに含まれ、ＲＴＰプロトコルの代わりにＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）を利用してクライアントに送信されるファイルに変換することから構成される。このＨＴＴＰプロトコルの効果は、それがすべてのファイアウォールによって受付けられ、ＮＡＴと良好に機能するということである。

この従来技術では、画像シーケンスからなる映像コンテンツは、ＭＪＰＥＧ（Ｍｏｔｉｏｎ Ｊｏｉｎｔ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔ Ｇｒｏｕｐ）ストリームに符号化される。ＭＪＰＥＧは、映像を符号化するための標準的フォーマットであり、静止画像用に開発されたＪＰＥＧを用いてシーケンスの各画像を個別に符号化することから構成される。ＭＪＰＥＧストリームはさらに、ＲＦＣ（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｃｏｍｍｅｎｔ）２４３５に記載されるようなＲＴＰストリームに変換される。ＲＴＰストリームは、ＲＴＰマルチキャスト接続を介しウェブサーバに送信される。このウェブサーバは、ＲＴＰストリームをＭＩＭＥ（Ｍｕｌｔｉｐｕｒｐｏｓｅ Ｉｎｔｅｒｎｅｔ Ｍａｉｌ Ｅｘｔｅｎｓｉｏｎ）マルチパートファイルに変換するための手段から構成される。ＭＩＭＥマルチパートは、インターネットメッセージ本体のフォーマットを指定及び記述するための規格であり、ＨＴＭＬウェブページのＪＰＥＧ画像シーケンスを表示可能にする。Ｊｏｈａｎｓｏｎの解決策では、ＭＪＰＥＧストリームのＪＰＥＧ画像は、ＭＩＭＥマルチパートファイルの一部に格納される。このＭＩＭＥファイルは、ウェブサーバ上で利用可能なウェブページ上のそれのＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ ＲＦＣ番号１７３８を参照されたい）によってアクセス可能とされる。クライアントが当該ウェブページをブラウズし、このＵＲＬアドレスをクリックすると、ＭＪＰＥＧファイルの連続するＪＰＥＧ画像のダウンロードを指示及び同期化するため、特定のＪａｖａ（登録商標）アプレットがクライアント側にダウンロード及び開始される。クライアントによって受信されると、ＪＰＥＧ画像がＪＰＥＧデコーダによって復号されながら、次のＪＰＥＧ画像がダウンロードされる。従って、ＭＪＰＥＧ映像シーケンスはリアルタイムに再生される。

この解決策の大きな問題点は、それがあまり汎用性がないということである。ＭＩＭＥマルチパートフォーマットは、ＪＰＥＧやＧＩＦなどの静止画像符号化フォーマットしか受付けない。独立したＪＰＥＧ画像の集まりとして映像シーケンスを符号化し、このため、この映像シーケンスの時間的冗長性を利用しないＭＪＰＥＧフォーマットは、インターネットやモバイルネットワークなどの低ビットレートネットワーク接続を介した映像ストリーミングを可能にするのに十分な圧縮率を実現するものでない。ＭＪＰＥＧフォーマットは、スタジオ構成に対しては大変興味深いものであるが、インターネットを介した映像ストリーミングには全く普及していない。ＭＰＥＧ−４などの他の映像符号化フォーマットを利用するため、変換が必要となり、重大な画質低下をもたらすことになるであろう。

この方法の他の問題点は、それが音声やテキストなどの映像以外の他のタイプのマルチメディアコンテンツに機能しないということである。それは、複数のマルチメディアソースを同期させるための手段を与えるものでない。例えば、当該方法は、インターネットを介し映画をストリーミングするための手段を提供していない。

本発明の課題は、サーバを介しインターネット上で映像及びより一般的にはあらゆる種類のマルチメディアコンテンツを配信するためのより効率的な解決策を提案することである。

上記課題は、請求項１〜４に記載される通信システム、請求項５〜７に記載されるサーバ、請求項８に記載されるクライアント装置、請求項９及び１０に記載される方法、請求項１１に記載されるコンピュータプログラム及び請求項１２に記載される信号により実現される。

本発明によると、マルチメディアコンテンツは、符号化されたデータストリームに符号化される。この符号化データストリームは、配信送信を介しサーバにリアルタイムに配信される。ＩＰネットワーク上では、エンコーダとサーバとの間の配信送信は、通常はＲＴＰ（ＲｅａｌＴｉｍｅ Ｐｒｏｔｏｃｏｌ）プロトコルによって規定されるマルチキャスト接続である。このとき、サーバは受信した符号化データストリームをプログレッシブダウンロードと互換的なフォーマットを有するプログレッシブファイルに変換し、例えば、ウェブページにより当該プログレッシブファイルをクライアント装置に利用可能なものとすることができる。

プログレッシブファイルは、ポイント・ツー・ポイントネットワークを介しサーバからクライアントに送信される。ＩＰネットワーク上では、このポイント・ツー・ポイントネットワーク接続は、通常はＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ ＲＦＣ２６１６を参照せよ）プロトコルによって規定される。ワールドワイドウェブの基礎となるこのＨＴＴＰプロトコルは、あらゆるファイアフォール及びＮＡＴによって受け入れられているという大きな利点を有している。

ファイルのプログレッシブダウンロードは、それの完全なダウンロードの前にファイルの復号化を開始することからなる。これは、メディアデータ及びメタデータがインタリーブされる構成を有するファイルフォーマットによって可能とされる。メディアデータは、符号化されたマルチメディアコンテンツの音声、映像、画像またはテキストトラックから構成される。メタデータは、メディアデータの符号化方法を記述している。このファイルフォーマットを用いて、ファイルの一部がメディアデータと当該メディアデータに関するメタデータを含む場合に当該部分に対して復号化が実現可能となる。

本発明によると、クライアントは、マルチメディアコンテンツの配信中の任意の時点でサーバと接続し、マルチメディアコンテンツを受信することを要求するよう期待される。このため、サーバはプログレッシブファイルをクライアントのリクエストに適合したクライアントプログレッシブファイルにカスタマイズすることが可能である。クライアントプログレッシブファイルは、例えば、プレーヤーを設定するため配信を開始する前に通常送信される初期化メタデータなどの現在のマルチメディア配信をクライアントが取得することを可能にするためのメタデータから構成される。

本発明の好適な実施例では、使用されるファイルフォーマットは、映像用のＭＰＥＧ−４やＨ．２６３あるいは音声用のＡＭＲ（Ａｄｖａｎｃｅｄ Ｍｕｌｔｉ Ｒａｔｅ）などの多数のマルチメディアデータ符号化規格によって可読なＩＳＯファイルフォーマットバージョン２である。

本発明の第１の効果は、これらの規格がマルチメディアデータ圧縮用に普及しているということである。例えば、ＭＰＥＧ−４や等価な規格は、インターネット上のコンテンツ提供者によって広く利用されている。このため、ＭＰＥＧ−４ストリームをｍＪＰＥＧストリームに符号変換するＪｏｈａｎｓｏｎの解決策のケースでしばしば必要となるサーバ側での符号変換手段を必要としない。

第２の効果は、映像符号化のための上記規格は、極めて低いビットレートから高いビットレートまでの任意のビットレートにおいて、ＭＪＰＥＧよりはるかに良好な圧縮率を実現するということである。この画質向上は、クライアントがインターネット接続モデムを有するパーソナルコンピュータや携帯電話であり、低いビットレートのネットワーク接続によって制限されるときに特に関係がある。

また、ＩＳＯファイルフォーマットバージョン２は、音声、映像、画像やテキストなどの異なるソースからのマルチメディアデータをインタリーブし、これにより、同期化された音声、映像及びテキストが同時に利用可能な符号化データをクライアントのプレーヤーに提供することができる。マルチメディアソースの処理に特に設計されたＭＰＥＧ−４などのマルチメディア規格と組み合わされて、ＩＳＯファイルフォーマットバージョン２は、マルチメディアデータのダウンロードサーバを介したクライアントへの送信を可能にする。本発明の他の効果は、インターネット上の現在のアプリケーションにより適した映像だけでなく任意の種類のマルチメディアコンテンツ、すなわち、同期化された音声、映像、テキスト及び画像を配信するための手段が提案されるということである。

また、本発明によるシステムは、受信したクライアントプログレッシブファイルのコピーをクライアントが維持することを可能にするため効果的である。サーバはまた、ＤＲＭ（Ｄａｔａ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ）を利用して認証されたコピーの回数を制限するようにしてもよい。これは、Ｊａｖａ（登録商標）アプレットを利用するＪｏｈａｎｓｏｎの解決策では、データをクライアントのファイルシステムに書き込む権限を事前的に有していないため容易には実行できない。

本発明の上記及び他の特徴は、以降に接続される実施例を参照することにより明らかとなるであろう。

図２において、本発明による通信システムが示される。このような通信システムは、エンコーダ２０、エンコーダ２０とサーバ４０との間の第１ネットワーク接続３０、サーバ４０とクライアント装置６０との間の第２ネットワーク接続５０から構成される。エンコーダ２０は、コンテンツ提供者からのマルチメディアコンテンツ１０を符号化データストリームＥＤＳに符号化する。

この符号化データストリームは、映像トラック、音声トラック、テキストトラックまたは画像トラックなどのいくつかのメディアトラックから構成されてもよい。それは、第１ネットワーク接続３０を介しリアルタイムに送信される。本発明の好適な実施例では、しばしばストリーミングアプリケーションの場合と同様に、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）プロトコルが利用されるが、これは限定的なものでない。ＭＰＥＧ−２ ＴＳと呼ばれるＭＰＥＧ−２規格のトランスポートレイヤもまた利用可能である。符号化データストリームＥＤＳは、ＲＴＰパケットにカプセル化される。ＲＴＰパケットは、メディアデータと呼ばれる符号化データと当該メディアデータを記述する制御データであるメタデータとから構成される。

ここで、マルチメディアコンテンツＭＭは、ライブコンテンツまたはより一般には任意の記録されたマルチメディアプログラムであってもよいが、当該マルチメディアコンテンツは配信され、「ビデオオンデマンド」サーバを介しては利用可能とされないということを留意すべきである。従って、第１ネットワーク接続は、いくつかのクライアントとサーバ４０によって「聴取される」マルチキャスト配信セッションである。

ＲＴＰパケットストリームは、サーバ４０の受信手段４１によって受信され、ストリーム−ファイル変換手段４２によってプログレッシブファイルＰＦに変換される。このプログレッシブファイルＰＦは、インタリーブされたメディアデータとメタデータから構成されるファイルフォーマットを有する。本発明の好適な実施例では、プログレッシブファイルは、ＩＳＯファイルフォーマットバージョン２に準拠する。ここで、ＩＳＯファイルフォーマットバージョン２に準拠させるため、ファイルはメタデータとメディアデータの両方を有する必要があり、データのシンタックスは規格により規定されているが、その構成は規定されていないということに留意すべきである。図３を参照するに、本発明によるライブファイルは、各々がメタデータまたはメディアデータからなる連結されたデータボックスに分割される。ＩＳＯファイルフォーマットバージョン２は、３つのタイプのデータボックスを規定している。
・「ＭＤＡＴ」データボックス ＭＤＡＴデータボックスは、音声Ａ、映像ＶまたはテキストＴのソースなどのインタリーブされたメディアデータのデータ群を含む。このデータ群は構成やマーカを有さず、１つの「ＭＯＯＶ」といくつかの「ＭＯＯＦ」データボックスは、メディアデータを記述及びアクセスするためのめたデータを含む。ＩＳＯファイルフォーマットは、単一の「ＭＯＯＶ」データボックスから始まる。それは、「ＭＤＡＴ」ボックスと「ＭＯＯＦ」ボックスに続く。
・「ＭＯＯＶ」データボックスは、第１ＭＤＡＴに格納されているメディアデータにアクセスするためのいくつかのインデックステーブルやデコーダ構成の要素などの初期化メディアデータから構成される。「ＭＯＯＦ」データボックスは、典型的には以降のＭＤＡＴに格納されているメディアデータにアクセスするためのインデックステーブルから構成される。

ここで、例えば、ＭＪＰＥＧやＡｐｐｌｅの．ｍｏｏｖファイルフォーマットなどの専用ファイルなどの他のファイルフォーマットが利用可能であるということに留意すべきである。ＩＳＯファイルフォーマットバージョン２の一効果は、映像トラック用のＭＰＥＧ−４と音声トラック用のＡＭＲなどのマルチメディアデータを符号化するためのいくつかの規格に互換的であるということであり、このことは、当該フォーマットを利用したファイルが当該規格に準拠したデコーダによって再生可能であることを意味する。これは、ＭＪＰＥＧデコーダを必要とするＭＪＰＥＧファイルによるケースでもなく、またＡｐｐｌｅのＱｕｉｃｋＴｉｍｅプレーヤー用に特に設計された．ｍｏｏｖファイルのケースでもない。

ストリーム−ファイル変換手段４２は、受信したＲＴＰパケットに含まれるメタデータとメディアデータによってライブファイル構成に注入するよう機能する。

以降において、符号化データストリームはＭＰＥＧ−４符号化データストリームであると仮定される。上述したように、これは限定的なものでなく、ＩＳＯファイルフォーマットバージョン２に互換する他の任意のフォーマットが利用可能となる。

このＭＰＥＧ−４符号化データストリームは、アクセスユニットに分割される。アクセスユニットは、直接アクセス可能なデータセットである。ＲＴＰパケットは、ＭＰＥＧ−４符号化データストリームからの１以上のアクセスユニットと、ＲＴＰヘッダを構成するアクセスユニットに関するメタデータとから構成される。特に、ＲＴＰヘッダは、アクセスユニットを復号化することを必要とする時点を示すアクセスユニットタイムスタンプを有する。

ストリーム−ファイル変換手段４２は、
・タイムスタンプに関するアクセスユニットを各々がインデックスを有する１以上のＭＤＡＴボックスにコピーし、
・タイムスタンプとＭＤＡＴボックスインデックスを関連付けることによりインデックスのＭＯＯＶ及びＭＯＯＦテーブルを構成し、
・ＲＴＰストリームとパラレルにサーバに通常は送信されるＳＤＰ（Ｓｅｓｓｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ Ｐｒｏｔｏｃｏｌ マルチメディアセッションの初期化用プロトコル）ファイルからデコーダ設定を指定するメタデータを抽出し、それらをプログレッシブファイルのＭＯＯＶテーブルにコピーすることによって、ＩＳＯファイルフォーマットバージョン２を利用してプログレッシブファイルＰＦを生成することから主として構成される。

得られたプログレッシブファイルは、いくつかの独立したデータ部分から構成されているため、ＭＯＯＶデータボックスを除いて他の任意のデータから独立的に復号可能なＭＯＯＦデータボックスとＭＤＡＴデータボックスから構成されるデータ部分をプログレッシブダウンロードするよう構成される。この結果、極めて短い遅延に対応するＭＯＯＶデータボックスの受信後すぐに復号化を開始することができる。

サーバ４０はさらに、クライアントプログレッシブファイルをクライアント装置６０に送信するための送信手段４４を有する。クライアント装置６０は、例えば、クライアントプログレッシブファイルＣＰＦがダウンロード可能ファイルとして利用可能とされるウェブページをブラウジングするためのウェブブラウザから構成される。クライアントプログレッシブファイルＣＰＦは、第２ネットワーク接続５０を介したクライアントリクエストＲＱに応答して、クライアント装置６０に送信される。本発明の好適な実施例では、第２ネットワーク接続５０は、ＨＴＴＰプロトコルを利用する。ワールドワイドウェブの基礎となるこのプロトコルは、ＨＴＭＬドキュメントを伝送するためのものであり、インターネット上のトラフィックを管理する。しかしながら、これは限定的なものではなく、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）もまた利用可能である。

このプログレッシブファイルには、例えば、「ｈｔｔｐ：／／ｓｅｒｖｅｒ：ｐｏｒｔ／ａｍｅｒｉｃａｎ／ｌｉｖｅ／ｍａｄｏｎｎａ．ｍｐｇ４」などのベーシックＵＲＬアドレスが与えられる。送信手段４４は、リダイレクションサブ手段（ｒｅｄｉｒｅｃｔｉｏｎ ｓｕｂ−ｍｅａｎｓ）を有する。リダイレクションサブ手段は、ベーシックＵＲＬアドレスを含めるため、リダイレクションファイルを生成することから構成される。このリダイレクションファイルには、例えば、ウェブページ上のハイパーテキストリンクによって指示されるリダイレクションＵＲＬアドレス「ｈｔｔｐ：／／ｓｅｒｖｅｒ：ｐｏｒｔ／ｒｅｄｉｒｅｃｔｉｏｎ／ｍａｄｏｎｎａ．ｍ４ｒ」が与えられる。リダイレクションＵＲＬアドレスをクリックすることにより、クライアント装置６０のウェブブラウザはリダイレクションファイルをダウンロードする。ダウンロードされると、リダイレクションファイルがウェブブラウザによって読み込まれる。ウェブブラウザは、ベーシックＵＲＬアドレスにおいてＭＰＥＧ−４ファイルを特定し、このようなファイルフォーマットの処理に適したプレーヤー６１を直接呼び出すことができる。この後、プレーヤーは、リダイレクションファイルに含まれるＵＲＬアドレスを読み込み、ダウンロード手段６２にダウンロードを継続するよう直接要求する。ダウンロード手段６２は、ファイル全体がすでにダウンロードされたことをプレーヤーに表示するが、プレーヤーにプログレッシブファイルを即座に開かせるため、当該ファイルの一部のみが実際には利用可能である。開かれると、すでに利用可能なプログレッシブファイルの一部が、ＩＳＯファイルフォーマットバージョン２の構成によって読み込み可能となる。

本発明によるリダイレクション手段とダウンロード手段６２の一効果は、プログレッシブダウンロードを可能にすることである。リダイレクションがない場合、プログレッシブファイルＰＦは、プレーヤーへの送信前にウェブブラウザによって完全にダウンロードされるであろう。ダウンロード手段６２がない場合、プログレッシブファイルＰＦを開く前にダウンロードの終了までプレーヤーは待機するであろう。

サーバ４０は、最終的にはプログレッシブファイルＰＦをクライアントのリクエストに適合させたクライアントプログレッシブファイルＣＰＦにカスタマイズするカスタマイズ手段４３を有する。図５において、このクライアントプログレッシブファイルの可能な構成が示され、以下において説明されるであろう。

マルチメディアコンテンツが時点ｔ_０からサーバ４０によってＲＴＰストリームとして受信されていると仮定すると共に、このＲＴＰストリームがサーバ側においてウェブページ上のプログレッシブファイルＰＦへのハイパーテキストリンクとして利用可能であると仮定する。多数のクライアントが、当該マルチメディアコンテンツを同時に再生しているかもしれない。図４を参照するに、サーバのウェブページをブラウジングする新たなクライアントが、時点ｔにおいてこのプログレッシブファイルＰＦをプログレッシブにダウンロードするよう要求すると仮定する。このカスタマイズ手段４３の目的は、この新しいクライアントに可能な限り迅速にマルチメディアコンテンツに追いつかせることである。このため、カスタマイズ手段４３は、時点ｔにおいて初期化メタデータを当該クライアントに提供するためのプライマサブ手段（ｐｒｉｍｅｒ ｓｕｂ−ｍｅａｎｓ）４５を有する。初期化メタデータは、主としてデコーダ設定から構成されるが、より一般には、リアルタイム符号化データの受信を開始するのにクライアントによって必要とされるすべてのデータから構成される。

重要な点は、この符号化データが所定のタイムスタンプにおいてのみアクセス可能であるということである。タイムスタンプは、上述のアクセスユニットと関連するものである。このため、アクセスユニットは、含まれているメディアデータがどの時点で再生されるべきか示すタイムスタンプを有する。一部のアクセスユニットはランダムなアクセスポイントである。すなわち、それらは直接アクセスすることが可能である。映像トラックの内部では、例えば、ランダムアクセスポイントは、「イントラ」画像、すなわち、以前の画像から独立に符号化され、このため独立に復号可能な画像に対応している。

サーバは、直近に受信したＲＴＰパケットに対応するプログレッシブファイルの部分を一時的に格納するためのバッファＢＵＦを有する。このバッファは、まだ受信されていないＲＴＰパケットとは独立に復号可能なプログレッシブファイルの部分を格納することができる。従って、このような部分は、ＭＯＯＦボックスとＭＤＡＴボックスを有する。ＭＤＡＴボックスは、例えば、音声及び映像トラックから符号化データの相異なるトラックからのいくつかのアクセスユニットを有する。ＭＯＯＦボックスは、ＭＤＡＴボックスに含まれる符号化データにアクセスするためのインデックステーブルを含む。従って、当該部分は、複数のアクセスユニットタイムスタンプを有することとなる。以降において、「アクセス可能タイムスタンプ」ＴＳは、ＭＤＡＴボックスの第１のアクセスユニットタイムスタンプと呼ばれるであろう。

バッファがフルになると、そのコンテンツはデータバーストとして同時にすべての接続されたクライアントに送信され、バッファは新しいプログレッシブファイル部分を格納する。

バッファは、数秒間分の符号化データを格納することができる。このことは、クライアントが数秒の遅れでライブのマルチメディアコンテンツを受信することを意味する。一方では、この遅延は特にフットボールの試合などのライブイベントには大きなものとされるべきではなく、他方、バッファが小さいほど、データオーバヘッドは大きなものとなる。実際問題として、データをＭＯＯＦ及びＭＤＡＴに再構成することは、コストがかかることであり、圧縮率に影響を与えないように適度なボックスサイズが用いられる必要がある。

従って、プライマサブ手段４５は以下を実行することができる。
・初期ＳＤＰファイルに対応するプログレッシブファイルのＭＯＯＶボックスの一部としてデコーダ設定ＩＮＩをクライアントに送信することによってクライアントのリクエストに回答する。
・時点ｔ以降に発生した次のアクセス可能なタイムスタンプＴＳを検索する。時点ｔが次のタイムスタンプＴＳより短い場合、プログレッシブファイルに含まれるデータは、次のタイムスタンプＴＳ以前にはアクセス可能でない。その間の期間中に、プライマサブ手段４５は、クライアントをタイムスタンプＴＳまで待機させるための追加的なパディングデータＰＡＤを新しいクライアントに送信することができる。これらのパディングデータＰＡＤは、単にブラック画面、ロゴあるいはコマーシャルを提供するものであってもよい。

プログレッシブファイルＰＦは、サーバ側においてその全体が存在しない可能性があるため、実際には仮想的ファイルとなるかもしれない。ライブファイルの一部のみがバッファＢＵＦにおいて時点ｔで利用可能である。

カスタマイズ手段４３はさらに、スタートサブ手段４６を有する。このスタートサブ手段４５は、タイムスタンプＴＳからバッファＢＵＦのコンテンツの新しいクライアントへの送信を開始するためのものである。スタートサブ手段４６は、例えば、既に登録されているクライアントのリストへの当該クライアントのアドレスの追加から構成される。図４は、時点ｔからの新しいクライアントによりサーバから受信したデータを示す。このタイムスタンプＴＳから、新しいクライアントは他のクライアントと同一のデータを正確に受信する。

これは、本発明の追加的な重要な効果である。すなわち、最小限のハードウェアリソースによってより良好なサーバパフォーマンスを可能にするため、各クライアントには同時に同一のデータが送信されるということである。従来のビデオオンデマンドでは、サーバパフォーマンスは、サーバが処理しなければならないコンカレントなストリームの個数に従って低下する。例えば、１０００個のコンカレントストリームを提供することが可能なサーバは、サーバのダイナミックメモリのサイズ、すなわち、アクセススピードの大きな差によるハードディスクの代わりにダイナミックメモリのデータの利用性に応じて、２０００以上の同様のストリームを提供することが可能であるかもしれない。具体的に本ケースでは、すべてのクライアントに同時にサービスを提供するのに必要な最大メモリサイズが典型的なサーバのダイナミックメモリより大多数は小さい上記バッファサイズであるため、映像サーバのパフォーマンスは最適となる。

デコーダ設定ＩＮＩ、パディングデータＰＡＤ及びタイムスタンプＴＳからのメディアデータは、プログレッシブファイルＰＦのカスタマイズされたバージョン、すなわち、要求元のクライアントに具体的に適合されたクライアントプログレッシブファイルＣＰＦを形成する。このクライアントプログレッシブファイルＣＰＦはまた仮想的ファイルである。

第１ネットワーク接続３０と異なり、第２ネットワーク接続５０は、サーバ４０とクライアント装置６０との間のポイント・ツー・ポイント接続であり、ここでは、サーバとクライアント装置は互いを認識している。図４に示されるように、クライアント装置６０は、サーバ４０上で利用可能なプログレッシブファイルＰＦを要求する要求手段６３と、第２ネットワーク接続５０を介しカスタマイズ手段４３によって供給されるクライアントプログレッシブファイルＣＰＦをダウンロードするダウンロード手段６２と、リアルタイムにクライアントプログレッシブファイルに含まれる受信された符号化データＲＥＤを再生するプレーヤー６１とから構成される。

ここで、従来のプレーヤーはローカルファイルを開くことしかできず、リモートファイル、すなわち、リモートサーバに置かれたファイルをダウンロードすることはできないということに留意すべきである。当業者には既知のダウンロード手段６２は、プレーヤー６１がプログレッシブファイルに含まれる受信した符号化データを、それがあたかもローカルファイルに格納されているかのように取り扱うことを可能にする。ダウンロード手段は、例えば、ウェブブラウジング手段６３の代わりにＨＴＴＰコマンドＧＥＴを用いることによって、プログレッシブファイルのダウンロードを指示することができる。プログレッシブファイルからの符号化データが受信されるとすぐに、プレーヤー６１は、ＩＳＯファイルフォーマットバージョン２を認識し、ダウンロードの終了前に受信した符号化データＲＥＤの復号化を開始することができる。復号化されたマルチメディアコンテンツＤＭＣは、出力及び表示される。

受信した符号化データＲＥＤは、格納及び再生可能な受信したクライアントプログレッシブファイルを形成する。ここで、サーバはクライアントに承認されたコピー数を制限するよう構成することが可能であるということに留意すべきである。このような制限は、例えば、ＯＭＡ（Ｏｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ）ダウンロードバージョン１などのＤＲＭ（Ｄａｔａ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ）技術を利用することによって設定することが可能である。

ここで、完全なファイルのサイズはクライアントの格納サイズを超過するかもしれず、この場合、プログレッシブダウンロードは、ファイルの始まりに対応するデータを再生が進行するに従って消去し、より直近のデータのためのスペースを与えることが可能となるというさらなる効果を提供する。このように、効果的にエンドレスなプログラムを利用可能とすることができる。

本発明によるクライアント装置のさらなる効果は、当業者には既知な普及しつつあるプログレッシブダウンロードを実現する機能を除いて、特定の詳細を有さないということである。これは、本発明がＩＳＯファイルフォーマットバージョン２に対応可能なプレーヤーとダウンロード手段を有する任意のクライアントにより機能するということを意味する。

本発明の他の実施例では、ダウンロードサーバ４０はさらに、図６に示されるようなプログレッシブファイルＰＦにおけるホール（ｈｏｌｅ）を完備させる修復手段４９を有する。このホールは、第１ネットワーク接続３０によるリアルタイムのデータストリームにおける可能性のあるデータ損失によって引き起こされるかもしれない。例えば、ＲＴＰプロトコルが使用される場合、一部のＲＴＰパケットは、送信中に単に消失したり、サーバ側におけるＲＴＰプロトコルによるエラーとして特定されるかもしれない。第２のケースでは、それらは拒否されるかもしれない。なぜなら、リアルタイム送信では、パケットの再送を要求する時間がないからである。サーバ４０によるＲＴＰパケットの消失または拒否は何れも、変換手段４２により生成されるプログレッシブファイルの「ホール」の原因となる。ホールによって、プレーヤーがクライアント側でクラッシュされるべきではない。なぜなら、準拠したデコーダは、例えば、アクセスユニットのタイムスタンプが欠落していることを検出することによって、符号化データのストリームにおけるデータの欠落を処理することができることが期待される。しかしながら、ホールは表示される復号化されたマルチメディアコンテンツの品質低下を引き起こすであろう。

エンコーダ２０からクライアント６０への送信中に符号化データを傍受するが可能な本発明によるシステムの一効果は、当該傍受を利用して符号化データを修復するということである。このため、修復手段４８は、エラー復元技術を利用して近傍データを外挿することによってホールを完備することができる。当業者には既知のエラー復元技術は、圧縮または伸長されたデータを処理するようにしてもよい。修復されたプログレッシブファイルＲＰＦが出力され、クライアントにより修復されたプログレッシブファイルＣＲＰＦはクライアント６０に送信される。

さらなる効果的な処理が、サーバ４０によるデータの傍受中に実行されてもよい。それは、例えば、典型的には異なる言語を示すトラックに対して、１つの音声トラックを他の音声トラックにより置換することによって、クライアント装置６０に割当てられたプロファイルデータの機能としてプログレッシブファイルに含まれるメディアデータをカスタマイズすることから構成される。極めて広範なプログラム（すなわち、国レベルまたは世界レベル）が、各々が与えられた国、地域、町あるいはエリアに固有のものである多数のサーバを用いて配布されることが予期される。この場合、例えば、典型的には宣伝を与えられたサーバのユーザによりターゲットを絞った宣伝により置換することなど、一部のシーケンスを他のシーケンスにより置換することが、ユーザやサービス提供者の経済的価値に影響する。また、サーバ単位で上述のような異なる処理を有する代わりに、同一のサーバがユーザ選好やユーザプロファイルなどの他の基準に基づく具体的処理を実行することが可能となる。このような処理タイプの例として、言語の選択や宣伝のターゲット化があげられる。

上記説明及び図面は、本発明を限定するものでなく、例示するためのものである。添付された請求項の範囲内に属する他の多数の実施例が存在することは明らかであろう。これに関して、ハードウェアまたはソフトウェアアイテム、あるいはその両方によって、機能を実現する方法が多数ある。図面は極めて図解的なものであり、各図面は本発明の可能性のある１つのみの実施例を表現しているに過ぎない。従って、図面は各機能を各ブロックとして示しているが、このことは、ハードウェアまたはソフトウェアの単一のアイテムが複数の機能を実行したり、あるいは単一の機能がハードウェアまたはソフトウェアアイテムの組み合わせ、あるいはその両方の組み合わせによって実行されることを排除するものではない。例えば、図２、４及び６に示されるものと異なって、プレーヤー６１はクライアント装置６０とは独立なリモート装置とすることが可能である。請求項における任意の参照符号は、当該請求項を限定するものとして解釈されるべきでない。「有する」という動詞またはその派生語を使用することは、請求項に記載されたもの以外の要素またはステップの存在を排除するものではない。要素またはステップに先行する「ある」という冠詞の使用は、当該要素またはステップが複数存在することを排除するものでない。

図１は、リアルタイムネットワーク接続を介しマルチメディアデータをストリーミングするための通信システムを示す図である。 図２は、本発明による第１ネットワーク接続、サーバ及び第２ネットワーク接続を介しマルチメディアコンテンツを配信するための通信システムを示すブロック図である。 図３は、ＩＳＯファイルフォーマットバージョン２によるファイルの構造を示す。 図４は、本発明によるクライアントリクエストに適合されたクライアントプログレッシブファイルをカスタマイズ手段がどのように構成することができるかに関する機能的方法を示す。 図５は、本発明によるクライアントプログレッシブファイルの構造を示す。 図６は、受信した符号化データストリームに含まれるメディアデータを修復する修復手段を有するサーバに関する本発明の一実施例の概略表示である。

Claims (8)

1. マルチメディアコンテンツを配信する通信システムであって、
   メディアデータを有する符号化データストリームに含まれる前記マルチメディアコンテンツを符号化するエンコーダと、
   サーバと、
   クライアント装置と、
   前記サーバに前記符号化データストリームを送信するための第１ネットワーク接続と、を有し、
   前記サーバは、
   前記符号化データストリームを受信する受信手段と、
   前記受信した符号化データストリームに含まれるメディアデータからメタデータを生成し、前記メディアデータと前記メタデータとがインタリーブされたプログレッシブファイルであって、前記メディアデータにアクセスするためのタイムスタンプであり、当該メディアデータ上の時点を示すタイムスタンプを有するプログレッシブファイルを生成するストリーム−ファイル変換手段と、
   前記メタデータを利用して、前記プログレッシブファイルをクライアントリクエストに適合したクライアントプログレッシブファイルにカスタマイズするカスタマイズ手段であって、時点ｔ_０から前記受信手段によって受信されている前記符合化データストリームにおけるある時点を表す時点ｔで送信されたクライアントリクエストに対し、
   前記時点ｔにおける初期化メタデータを前記クライアント装置に提供するプライマサブ手段と、
   前記時点ｔより大きなタイムスタンプにおける前記プログレッシブファイルの送信を開始するスタートサブ手段と、
   を有するカスタマイズ手段と、
   前記クライアントプログレッシブファイルを、第２ネットワーク接続を介し前記クライアント装置に送信する送信手段と、
   を有し、
   前記クライアント装置は、
   前記プログレッシブファイルを前記サーバにリクエストするリクエスト手段と、
   前記クライアントプログレッシブファイルを前記第２ネットワーク接続を介しダウンロードし、前記メタデータを利用して前記ダウンロードの終了前にプレーヤーに前記受信したメディアデータを提供するダウンロード手段と、
   を有することを特徴とするシステム。
2. 請求項１記載のシステムであって、
   前記プログレッシブファイルは、ＩＳＯファイルフォーマットバージョン２の形式を有することを特徴とするシステム。
3. 請求項１記載のシステムであって、
   前記第１ネットワーク接続は、ＲＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を利用することを特徴とするシステム。
4. 請求項１記載のシステムであって、
   前記第２ネットワーク接続は、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）を利用することを特徴とするシステム。
5. 配信されたマルチメディアコンテンツを、メディアデータを有する符号化データストリームとして受信し、前記メディアデータをクライアント装置に送信するサーバであって、
   前記符号化データストリームを受信する受信手段と、
   前記受信した符号化データストリームに含まれるメディアデータからメタデータを生成し、前記メディアデータと前記メタデータとがインタリーブされたプログレッシブファイルであって、前記メディアデータにアクセスするためのタイムスタンプであり、当該メディアデータ上の時点を示すタイムスタンプを有するプログレッシブファイルを生成するストリーム−ファイル変換手段と、
   前記メタデータを利用して、前記プログレッシブファイルをクライアントリクエストに適合したクライアントプログレッシブファイルにカスタマイズするカスタマイズ手段であって、時点ｔ_０から前記受信手段によって受信されている前記符合化データストリームにおけるある時点を表す時点ｔで送信されたクライアントリクエストに対し、
   前記時点ｔにおける初期化メタデータを前記クライアント装置に提供するプライマサブ手段と、
   前記時点ｔより大きなタイムスタンプにおける前記プログレッシブファイルの送信を開始するスタートサブ手段と、
   を有するカスタマイズ手段と、
   前記クライアントプログレッシブファイルを、第２ネットワーク接続を介し前記クライアント装置に送信する送信手段と、
   を有することを特徴とするサーバ。
6. 請求項５記載のサーバであって、
   前記受信した符号化データストリームのデータの欠落によって生じる前記プログレッシブファイルのホールを修復する修復手段を有することを特徴とするサーバ。
7. 第１ネットワークを介してエンコーダに接続しているサーバから、第２ネットワークを介して前記サーバに接続しているクライアント装置にマルチメディアコンテンツを配信する方法であって、
   前記エンコーダが、前記マルチメディアコンテンツを、メディアデータを有する符号化データストリームに符号化するステップと、
   前記エンコーダが前記第１ネットワークを介して、前記符号化データストリームを前記サーバに送信するステップと、
   前記サーバが、前記メディアデータからメタデータを生成し、インタリーブされたメタデータと、メディアデータと、前記メディアデータにアクセスするためのタイムスタンプであり、当該メディアデータ上の時点を示すタイムスタンプとを有するプログレッシブファイルを生成するステップと、
   前記サーバが、時点ｔ_０から前記サーバによって受信されている前記符合化データストリームにおけるある時点を表す時点ｔで送信されたクライアントリクエストに対し、前記時点ｔにおける初期化メタデータを前記クライアント装置に提供し、前記時点ｔより大きなタイムスタンプにおける前記プログレッシブファイルの送信を開始することにより、前記プログレッシブファイルをクライアントリクエストに適合したクライアントプログレッシブファイルにカスタマイズするステップと、
   前記サーバが、前記クライアントプログレッシブファイルを前記クライアント装置に送信するステップと、
   前記クライアント装置が、前記クライアントプログレッシブファイルをダウンロードし、前記インタリーブされたメタデータとメディアデータとを利用して、前記ダウンロードの終了前に前記受信したマルチメディアコンテンツの再生を開始するステップと、
   を有することを特徴とする方法。
8. 請求項７記載の方法であって、さらに、
   前記サーバが、前記プログレッシブファイルに含まれる前記メディアデータを前記クライアント装置に割当てられたプロファイルデータの一機能としてカスタマイズするステップを有することを特徴とする方法。

Images