JP2005295467A

JP2005295467A - メディア配信装置

Info

Publication number: JP2005295467A
Application number: JP2004111681A
Authority: JP
Inventors: Hiroshi Mine; 博史峯; Osamu Takeuchi; 理竹内; Masaru Nomura; 賢野村
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2004-04-06
Filing date: 2004-04-06
Publication date: 2005-10-20
Anticipated expiration: 2024-04-06
Also published as: JP4718122B2; US8260947B2; US20050223107A1

Abstract

【課題】
ストリーミング配信を行う大規模配信ネットワークにおいて、新たなメディアフォーマットに対応する際には、プロキシ装置の更新および管理に必要なコストが嵩む。
【解決手段】
本発明のメディア配信装置は、メディアデータを、予めパケット化された状態で格納するパケットファイルと、それぞれのパケットを送信する時刻情報等を格納するヒントファイルとして、メディアフォーマット非依存の形式で格納する。メディア配信装置より、メディアフォーマットに依存する処理を行う配信制御プロキシ装置を分離して実装することにより、新たなメディアフォーマットには、配信制御プロキシ装置の更新のみで対応することがきる。大規模配信ネットワークに、本発明の配信制御プロキシ装置とメディア配信装置を用いることにより、新たなメディアフォーマットに対応する際に必要なコストを削減することができる。
【選択図】図９

Description

本発明は、映像、音等のメディアデータを、ネットワークを介して送信するストリーミング配信方法、および、ストリーミングデータを中継して配信するプロキシ配信装置に関する。

映画やライブ中継等の映像、音情報を計算機に取り込み、圧縮、符号化し、ネットワークを介して視聴端末に配信するストリーミング配信が行われている。

ストリーミング配信では、一般に、コンテンツプロバイダが管理する配信サーバ装置(以下、サーバ装置という)が、ユーザが操作するＰＣ（Personal Computer）、ＳＴＢ（Set Top Box）等のクライアント端末装置(以下、クライアント端末という)から受けたコンテンツ配信準備要求を処理し、ストリーミング配信の対象となるメディアファイルから必要なヘッダ情報をクライアント端末に応答する。

サーバ装置は、続けてクライアント端末から配信制御要求を受けると、ハードディスクドライブ等のストレージ装置から、メディアファイル中のメディアデータを読み出す。サーバ装置は、読み出したメディアデータをサーバ装置とクライアント端末それぞれのアプリケーションが同意した規則に従って適当な大きさに細分（パケット化）し、ネットワークプロトコルに従ったパケットを構成し、ネットワークを介して連続的に適切な通信速度（ビットレート）でクライアント端末に送信する。

ストリーミング配信において、上記配信制御要求や配信準備要求などの配信を制御するプロトコルとして非特許文献１記載のＲＴＳＰが、また、ネットワークプロトコルに従ったパケットを構成してメディアデータを伝送するプロトコルとして非特許文献２記載のＲＴＰが、それぞれ標準化されている。

ストリーミング配信をインターネットに代表されるＷＡＮ(Wide Area Network)(以下ＷＡＮという)を介して行う場合、配信品質の確保、およびサーバ負荷の低減、を図るため、プロキシ装置が用いられる。プロキシ装置は、サーバ装置とクライアント端末間の、クライアント端末に近い位置に配置され、ローカルストレージ装置を持ち、サーバ装置に代わりメディアデータのストリーミング配信処理を行う。プロキシ装置が配信するメディアデータは、予めサーバ装置から配布されたものか、あるいは、サーバ装置からクライアント端末へ配信されるストリーミング配信用パケットを中継する際に、ネットワークプロトコルに従ったパケットから取り出したメディアデータの複製であり、ローカルストレージ装置に格納されている。

例えば、特許文献１は、メディアデータが伝送されるネットワークプロトコルによらず、中継するメディアデータを複製することで、サーバ装置より配信されるコンテンツの一部または全部をローカルストレージ装置に蓄積（キャッシング）し、クライアント端末の要求に応じた伝送プロトコル、および、ビットレートで配信するプロキシ装置を開示している。

米国特許出願公開第2002/0176418号明細書（図３、図９) H. Schulzrinne、他２名、"Real Time Streaming Protocol (RTSP)"、[online]、平成１０年４月、The Internet Engineering Task Force、[平成１６年２月１６日検索]、インターネット＜URL: http://www.ietf.org/rfc/rfc2326.txt＞ H. Schulzrinne、他３名、"RTP: A Transport Protocol for Real-Time Applications"、[online]、平成８年１月、The Internet Engineering Task Force、[平成１６年２月１６日検索]、インターネット＜URL: http://www.ietf.org/rfc/rfc1889.txt＞

ストリーミング配信を行う場合、サーバ装置は、メディアデータを適当なサイズで区切りネットワークプロトコルに従ったパケットとして構成し、配信ビットレートに応じて送信する等、配信するメディアデータ固有のパラメータに応じた処理を行う必要がある。メディアデータ固有のパラメータは、一般に、メディアファイルのヘッダ情報として、メディアファイルのフォーマット、例えば、ＭＰＥＧ２（Moving Picture Experts Group layer 2）、ＭＰＥＧ４（Moving Picture Experts Group layer 4）、その他商用メディアフォーマット、に依存した形式で格納される。さらに、それぞれのパラメータの解釈、すなわち、配信時に必要な制御も異なる。

このため、ストリーミング配信において、サーバ装置は扱うメディアフォーマットによって異なる処理が必要となり、メディアフォーマット毎に専用のサーバ装置、または、サーバ装置上で動作する専用の配信制御アプリケーションプログラムが必要になる。

特許文献１に記載のプロキシ装置も、クライアント端末に対して、サーバ装置と同様のストリーミング配信を行う、と開示されているので、扱うメディアフォーマットに応じた専用の配信制御アプリケーションプログラムが必要になる。

また、ストリーミング配信されるパケットを中継しつつローカルストレージにメディアデータの複製を蓄積する処理も、メディアフォーマットに依存する処理である。従って、異なるメディアフォーマットに対応するためには、メディアフォーマット毎に専用のアプリケーションプログラムをプロキシ装置に用意しなければならず、プロキシ装置の更新および管理に必要な費用が嵩む。

ＷＡＮを介した大規模配信ネットワークを構築する場合、プロキシ装置は、サーバ装置に対してクライアント端末に近い位置に多数配置される。従って、大規模配信ネットワークにおいては、新たなメディアフォーマットに対応する際に必要なプロキシ装置の設備および管理コストの削減が課題となる。

したがって、設備コストや管理コストの面で改善されたプロキシ装置の実現が望まれている。

本発明は、第１には、サーバ装置から配信されるメディアデータをメディアフォーマットに依存せずに配信できるデータ形式で蓄積し、蓄積したメディアデータをクライアント端末に対してストリーミング配信するメディア配信装置を提供する。

本発明は、第２には、メディアデータ配信ネットワークにおいて、新たなメディアフォーマットに対応する際のコストの削減技術を提供する。

本発明は、ローカルストレージにメディアデータの複製を格納し、クライアント端末からの要求に応じてストリーミング配信を行うプロキシ装置であって、予め、メディアデータをネットワークに送信するパケットのサイズに分割し、分割したメディアデータを送信するタイミングを示す時刻情報とあわせてローカルストレージに格納する。配信時に、格納されているメディアデータを時刻情報に従いネットワークに送信することにより、適切なパケットサイズ、ビットレートでストリーミング配信を行うことが可能になる。

また、本発明は、サーバ装置からクライアント端末へストリーミング配信されるメディアデータのパケットを中継する際に、複製をローカルストレージに蓄積するプロキシ装置であって、パケットの受信時に、パケットに格納されている、分割されたメディアデータと共に、パケットを受信した時刻を記す時刻情報をローカルストレージに記録する。すなわち、本発明のプロキシ装置は、メディアデータの詳細を解釈する機構を備えることなく、メディアフォーマットに非依存の形式で、ローカルストレージにメディアデータを格納する。

さらに、上記プロキシ装置におけるストリーミング配信処理を、メディアフォーマットに依存する配信制御処理と、メディアフォーマットに依存しない配信処理に分けることができるので、上記プロキシ装置を、配信制御処理を行う配信制御プロキシ装置と、配信処理を行うメディア配信ストレージ装置に分離してもよい。さらに、大規模配信ネットワークにおいては、複数のメディア配信ストレージ装置を配置してもよい。配信部と比較して軽負荷の配信制御プロキシ装置が、複数のメディア配信ストレージ装置を制御することにより、配信制御プロキシ装置の更新のみで、新たなメディアフォーマットに対応可能となる。

なお、本発明におけるストリーミングとは、サーバ装置上にあるメディアデータを、クライアント端末がすべてダウンロードしてからではなく、クライアント端末がダウンロードと並行して当該メディアデータを再生することを可能にする技術を指す。

本発明によれば、サーバ装置から配信されるメディアデータをメディアフォーマットに依存しないデータ形式で蓄積し、クライアント端末に対してストリーミング配信を行うことができる。

また、大規模配信ネットワークにおいて、新たなメディアフォーマットに対応する際のコストを削減することができる。

本発明の実施例を図を用いて説明する。

図１は、本発明の第１の実施例におけるメディア配信装置の構成を表す。メディア配信装置１０は、メディアデータのストリーミング配信を行うサーバ装置２０と、ストリーミング配信されるメディアデータを受信し、再生するクライアント端末３０の間に位置し、例えば、ＲＴＳＰ形式でクライアント端末３０からの配信要求を受け付け、メディアデータを分割した結果であるメディアデータ要素をＲＴＰ形式でパケット化してストリーミング配信する。

各装置は、図示していない、インターネットなどのＷＡＮ７０を介して互いに接続されている。以下の実施例では、配信制御プロトコルとしてＲＴＳＰ、パケットを構成してメディアデータを伝送するプロトコルとしてＲＴＰを例示する。

メディア配信装置１０は、メディアデータをメディアフォーマットに依存しない独自の形式で格納するローカルストレージ(以下、ディスク装置という)１１０と、クライアント端末３０からの要求に応じてディスク装置１１０からメディアデータを読み込み、ストリーミング配信処理を行う制御部１２０からなる。

ディスク装置１１０は、例えば、ＳＣＳＩ（Small Computer System Interface）ハードディスクドライブからなり、メディアデータの複製を、ヒントファイル１１１とパケットファイル１１２という形式で格納する。

ヒントファイル１１１には、図２（ａ）に示すように、受信したＲＴＰパケットから得られる情報、例えばヘッダ情報と時刻、オフセット、サイズを一組のレコードとして格納する。各レコードは、ＷＡＮ７０を介して送信されるパケットに一対一に対応する。

ヘッダ情報は、パケットを再構成する際に必要となる補助情報、例えば、ＲＴＰ形式でパケットを送信する場合、ＲＴＰヘッダに含まれるマーカービット等の情報を格納する。時刻は、最初のパケットが送信される時刻を基準とする相対時刻であり、対応するパケットを送信するタイミングを表す。

パケットファイル１１２は、各パケットに含まれるメディアデータ要素をまとめたもので、上記オフセット、サイズを用いて、パケットファイル１１２内での各メディアデータ要素の位置を表す。

ヒントファイル１１１とパケットファイル１１２を用いることにより、例えば、第ｎ番目に送信されるＲＴＰパケットｎ’４０’は、図３（ｂ）に示すように、ヘッダ情報ｎに格納される情報と配信の都度変化するシーケンス番号、ＳＳＲＣ（Synchronization Source）等から生成されるヘッダｎ’と、オフセットＸｎとサイズＹｎで表される、メディア配信装置１０が受信したＲＴＰパケットに含まれていたものと同じメディアデータ要素であるデータｎで構成され、最初のパケットが送信されてからＴｎ後に送信するということを表すことができる。

なお、ヒントファイル１１１とパケットファイル１１２は、上述のように、サーバ装置２０から配信されるメディアデータを中継することで動的に生成してもよいし、予め適当な変換ツールを用いてサーバ装置２０上に格納されるメディアファイルを変換することで静的に生成してもよい。

また、メディアファイルとはコンテンツがディスクに格納されている状態のデータで、メディアデータ固有のパラメータを、メディアファイルのヘッダ情報として含む。メディアデータとはコンテンツの映像データそのものを指す。メディアファイルから、ストリーミング配信するメディアデータが抽出される。

制御部１２０は、クライアント端末３０からのＲＴＳＰ配信要求を処理する配信制御部１２１と、クライアントに対してＲＴＰパケットをストリーミング配信する配信部１２２、メディアデータを蓄積する際にサーバ装置２０からストリーミング配信されるＲＴＰパケットを受信する受信部１２３からなる。

なお、図１は、機能を明確にするために、配信制御部１２１、配信部１２２、受信部１２３は、それぞれ独立した処理部として表現しているが、実際には、汎用計算機上でソフトウェアが実行されることにより具現化されてもよい。

例えば、図４に示すように、制御部１２０は、プログラムを実行するＣＰＵ（Central Processing Unit）１２０１、プログラムおよびデータを一時的に格納するメモリ１２０２、ディスク装置およびネットワークインタフェース等を制御するＩ／Ｏインタフェース１２０３、プログラムを格納する、不揮発性の半導体メモリまたはハードディスク等からなるプログラム記憶装置１２０４を備える計算機であってもよい。

当該計算機において、ＣＰＵ１２０１が、プログラム記憶装置１２０４から、配信制御処理を行う配信制御プログラム１２０５を、配信処理を行う配信プログラム１２０６を、受信処理を行う受信プログラム１２０７を、適宜メモリ１２０２に読み込み、並列または時分割で処理することにより、上記それぞれの処理部が実現されてもよい。

各プログラムは、あらかじめ、上記プログラム記憶装置１２０４に格納されていてもよいし、必要なときに、当該計算機が利用可能な、着脱可能な記憶媒体または通信媒体（ＷＡＮ７０またはＷＡＮ７０上の搬送波やデジタル信号）を介して、上記プログラム記憶領域１２０４に導入されてもよい。

配信制御部１２１のメディアデータ配信時の動作を、図５を用いて説明する。この動作はクライアントからの要求に応じて行われる対話的な動作である。

配信制御部１２１は、クライアント装置３０からＲＴＳＰに従った、ストリーム配信要求を受け付け、配信制御処理を開始する。クライアント装置３０から、ＲＴＳＰにおける、ＤＥＳＣＲＩＢＥメソッド、ＳＥＴ＿ＰＡＲＡＭＥＴＥＲメソッド、ＧＥＴ＿ＰＡＲＡＭＥＴＥＲメソッド、ＳＥＴＵＰメソッド等の、配信準備要求を受信し（Ｓ１０１）、メディアファイル名、クライアント装置３０の受信ポート番号等の必要な情報を抽出する。

配信準備要求のうち、ＤＥＳＣＲＩＢＥメソッドおよびＳＥＴ＿ＰＡＲＡＭＥＴＥＲメソッドに含まれる認証情報等はサーバ装置２０に転送し（Ｓ１０２）、サーバ装置２０にメディアデータへのアクセス権の審査および課金等の処理を委任する。

続いて、サーバ装置２０からの応答を受信し、配信許可が得られたかどうかを判定する（Ｓ１０３）。

配信許可が得られなかった場合（Ｓ１０３でＮｏ）は、クライアント端末３０に配信許可が得られなかった理由、例えば、４０１Ｕｎａｕｔｈｏｒｉｚｅｄ等を含む配信拒否応答を返信し（Ｓ１０４）、処理を終了する。

配信許可が得られた場合（Ｓ１０３でＹｅｓ）は、クライアント端末３０に配信準備要求応答を返信し（Ｓ１０５）、処理を継続する。この配信準備要求応答には、サーバ装置２０からの応答に含まれる、メディアデータのビットレートおよび映像トラック数などのコンテンツ記述情報が含まれる。

クライアント端末３０から、ＲＴＳＰにおけるＰＬＡＹメソッド等の配信制御要求を受信すると（Ｓ１０６）、受信した配信制御要求の種類およびパラメータに応じて、配信部１２２に配信指示を出す（Ｓ１０７）。ここで、配信制御要求が、例えば、ＰＬＡＹメソッドの開始要求の場合は、配信指示の内容はメディアファイル名、配信開始位置等を含む送信開始指示となり、ＰＡＵＳＥメソッド、ＴＥＡＲＤＯＷＮメソッド等の停止要求の場合は、停止指示となる。

もし、Ｓ１０６で要求の受信待機中に、再生中で再生時間が経過した、または、クライアント端末３０とのコネクションが切断された等の異常時には、処理を終了する。

その後、クライアント端末３０からの配信制御要求が停止要求であるか、または、配信時間がメディアファイルの終わりに達したかを判定し（Ｓ１０８）、停止要求、または、ファイルの終わりであった場合は処理を終了し、そうでない場合は、配信制御要求に応じた処理を繰り返す。

配信制御部１２１のメディアデータ蓄積時の動作を、図６を用いて説明する。図６の処理は、メディア配信装置１０の管理者の指示で行われるバッチ的な処理である。

配信制御部１２１は、メディアデータの蓄積を行う際に、サーバ装置２０に対して、メディアファイル名等を含む配信準備要求を送信し（Ｓ２０１）、その応答からメディアデータの再生時間等の情報を得る。

続いて、配信制御部１２１は、サーバ装置２０に対して、メディアデータのストリーミング配信の開始を要求する配信制御要求を送信し（Ｓ２０２）、受信部１２３に蓄積指示を出す（Ｓ２０３）。受信部１２３は、蓄積指示に従って、ＲＴＰパケットを蓄積し、その後、メディアファイルが終わりに達したかどうかを、再生時間等の情報をもとに判定し（Ｓ２０４）、ファイルの終わりに達するまで、時間待ちを行う（Ｓ２０５）。

サーバ装置２０によってメディアデータが全て送信され、メディアファイルが終わりに達していると判断される場合（Ｓ２０４でＹｅｓ）、受信部１２３に停止指示を出し（Ｓ２０６）、処理を終了する。

なお、上記手順のうち、配信準備要求送信（Ｓ２０１）および配信制御要求送信（Ｓ２０２）の処理を、図５と同様にクライアント端末３０からサーバ装置２０へ送信される実際の配信要求を中継することで処理してもよい。そして、サーバ装置２０からストリーミング配信されるパケットを受信部１２３で受信し、送信部１２２よりクライアント端末３０に送信するという中継処理の際に、受信部１２３が後述する蓄積処理を行うことにより、クライアント端末３０の配信要求に合わせたメディアデータの蓄積を、並行して行ってもよい。

配信部１２２の動作を、図７を用いて説明する。

配信部１２２は、図５のＳ１０７に示す、配信制御部１２１による配信指示を受信し（Ｓ３０１）、配信指示に含まれるメディアファイル名等の情報を得る。メディアファイル名に基づいて、ヒントファイル名、パケットファイル名等の情報を得る。続いて、メディアファイル名に対応するヒントファイル１１１をディスク装置１１０から読み込み（Ｓ３０２）、ヒントファイル１１１のレコードによって示されるパケットファイル１１２のメディアデータ要素を読み込み、ヒントファイル１１１から読み込んだヘッダ情報、パケットファイル１１２から読み込んだメディアデータ要素を用いてパケットを生成する（Ｓ３０３）。

ヒントファイル１１１に含まれる相対的な時刻情報と、最初のパケットの送信時刻に基づき、送信予定時刻に達しているかを判定し（Ｓ３０４）、達していない場合は、配信予定時刻まで時間待ちを行う（Ｓ３０５）。予定時刻に達している場合は、生成したパケットをクライアント端末３０に対して送信する（Ｓ３０６）。

その後、配信制御部１２１から停止指示を受けたか、または、メディアファイルの終わりに達したかを判定する（Ｓ３０７）。メディアファイルの終端は、対応するヒントファイル１１１のレコードの終端およびパケットファイル１１２の終端と等価であり、ヒントファイル１１１の有効レコード数またはパケットファイル１１２のＥＯＦ判定により、検出できる。

配信制御部１２１から停止指示を受けた、または、ファイルの終わりであった場合は処理を終了し、そうでない場合は、パケットファイル１１２から次に送信すべきパケットを構成するために必要なメディアデータを読み出してパケットを生成し、指定された時刻に生成したパケットを送信する処理を繰り返す。なお、配信制御部１２１からの停止指示に応じて即時に配信停止を行うために、配信停止指示による処理の終了を、通常配信処理に対する割り込み処理として実装してもよい。

受信部１２３の動作を、図８を用いて説明する。

受信部１２３は、配信制御部１２１の蓄積指示に応じて蓄積処理を開始する。配信制御部１２１から蓄積指示を受信し（Ｓ４０１）、蓄積指示に含まれるメディアファイル名等の情報を得る。続いて、サーバ装置２０からストリーミング配信されるパケットを受信し（Ｓ４０２）、受信したパケットに関するヘッダ情報、受信時刻等に基づいた新たなエントリをヒントファイル１１１に追加して書き込み（Ｓ４０３）、パケットファイル１１２にメディアデータを追加して書き込む（Ｓ４０４）。例えば、ＭＰＥＧ２で符号化されたメディアデータがＲＴＰで配信される場合、パケットファイル１１２はＭＰＥＧ２ファイルとなる。

また、例えば、図３（ａ）に示すパケットｎ４０を、最初のパケットを受信してからＴｎ後に第ｎ番目に受信した場合、ヘッダｎからヘッダ情報ｎを生成し、受信時刻Ｔｎ、そのときのパケットファイル１１２のサイズをオフセットＸｎ、データｎのサイズＹｎとしてヒントファイル１１１に追加し、データｎを、パケットファイル１１２に追加する。

その後、配信制御部１２１からの停止指示を受けているかを判定し（Ｓ４０５）、停止指示を受けている場合は処理を終了し、停止指示を受けていない場合は、パケットを受信しヒントファイル１１１とパケットファイル１１２にメディアデータを追加する処理を繰り返す。

上述の実施例において、メディア配信装置１０は、メディアデータを、メディアフォーマットに依存しないヒントファイル１１１およびパケットファイル１１２の形式でディスク装置１１０に格納する。ストリーミング配信、メディアデータの蓄積は、制御部１２０によって制御される。ストリーミング配信を行う場合は、配信制御部１２１によってクライアント端末３０からの配信要求を受け付け、必要に応じてサーバ装置２０に配信要求を転送し、配信部１２２に配信指示を出す。

配信部１２２は、配信指示に従ってヒントファイル１１１およびパケットファイル１１２からパケットを構成し、ヒントファイル１１１で指定される時刻情報に従ってクライアント端末３０に対して送信する。メディアデータの蓄積を行う場合は、配信制御部１２１から受信部１２３に蓄積指示を出し、受信部１２３は、蓄積指示に従ってサーバ装置２０からストリーミング配信されるパケットを受信し、メディアデータをヒントファイル１１１およびパケットファイル１１２として蓄積する。

これらのファイルにより、メディアデータをパケット化する際の区切りとヘッダ情報と送信タイミングがわかるので、メディア配信装置１０は、メディアフォーマットに依存しない形式でサーバ装置２０から配信されるメディアデータを蓄積し、クライアント端末３０に対してＲＴＰを用いたストリーミング配信を行うことができる。

上記実施例における伝送プロトコルは例示したＲＴＰに限定されず他のプロトコルを用いてもよい。

本発明の第２の実施例として、メディア配信装置をライブストリーミング映像の蓄積、配信に用いる場合について説明する。説明には、第1の実施例で用いた図および符号を用いる。

メディア配信装置１０において、サーバ装置２０からストリーミング配信されるライブ映像を受信部１２３が受信することにより、実施例１記載の方法で、ライブ映像をメディアフォーマットに依存しない形式で、ヒントファイル１１１およびパケットファイル１１２として蓄積する。

サーバ装置２０が要求に応じて配信を開始するプル型のサーバ装置の場合、サーバ装置２０にストリーミング配信を開始させるには、配信制御部１２１がサーバ装置２０に対して配信開始を要求するか、配信制御部１２１がクライアント端末３０から配信要求を受信し、ＲＴＳＰメッセージのクライアントＩＰアドレス等をメディア配信装置１０のものに書き換えて、サーバ装置２０に転送すればよい。

後者の場合、受信部１２３は受信したパケットをディスク装置１１０に蓄積すると共に配信部１２２に渡し、配信部１２２がクライアント端末３０に転送することにより、ライブ映像を蓄積しつつ中継することができる。サーバ装置２０がプッシュ型の場合は、メディア配信装置１０に対してライブ映像のストリーミング配信を行うように、サーバ装置２０を設定すればよい。

上記ライブ映像を蓄積、中継するメディア配信装置１０からライブ映像のストリーミング配信を受信しているクライアント端末３０において、ユーザが一時停止（ＰＡＵＳＥという）を要求した場合を考える。

従来技術では、ライブ映像のストリーミング配信において、ユーザが一時停止を要求し、しばらくしてから再生再開を要求した場合、クライアント端末３０では、一時停止中の映像はスキップされ、再生再開を要求した時点の映像から再生が開始される。

これは、サーバ装置２０はクライアント端末３０からＲＴＳＰのＰＡＵＳＥ要求を受信した時点でライブ映像のストリーミング配信を停止し、再びＰＬＡＹ要求を受信した時点でライブ映像のストリーミング配信を再開するため、クライアント端末３０は一時停止中の映像データを受信していないためである。

本実施形態のメディア配信装置１０は、クライアント端末３０からＰＡＵＳＥ要求を受信した場合、クライアント端末３０へのＲＴＰパケットの転送は停止するが、サーバ装置２０からストリーミング配信されるライブ映像のディスク装置１１０への蓄積は継続する。そして、配信制御部１１２は、ＰＡＵＳＥ要求を受信した絶対時刻をクライアント端末３０とのセッション情報を記録している記憶領域（メモリ）１２０２に保持しておく。このときの時刻情報は、例えばライブ配信開始時を基準とした相対時刻でもよい。

クライアント端末３０から再生再開のＰＬＡＹ要求を受信すると、配信部１２２は、ヒントファイル１１１に格納される情報を参照しパケットファイル１１２のＰＡＵＳＥ要求を受信した時刻に対応する位置から、蓄積した映像データを読み込み、クライアント端末３０へのストリーミング配信を開始する。これにより、ライブ映像のストリーミング配信の中継からオンディマンド配信に、ＲＴＳＰの接続をし直すことなく切り替え、クライアント端末３０でストリーミング配信される映像データを長時間バッファリングすることなく、映像に飛びのない一時停止後の再生再開を実現することができる。

次に、クライアント端末３０が、メディア配信装置１０に対して、蓄積中のライブ映像のストリーミング配信を要求する場合を考える。

従来、ライブ映像のストリーミング配信において、現在時刻以前を再生開始時刻に指定して過去のライブ映像を配信させたり、再生中に以前の時刻に戻ったりすることはできなかった。これは、従来のサーバ装置は、ライブ映像のリアルタイム符号化および符号化した映像データのストリーミング配信処理に特化されており、過去の映像データを保持しないためである。

本実施例のメディア配信装置１０は、ライブ映像のストリーミング配信を中継する場合、中継したメディアデータ（ここでは映像データ）をディスク装置１１０に蓄積する。クライアント端末３０が、過去の時刻に戻って再生、というユーザ操作に応じて、ＲＴＳＰのＰＬＡＹ要求のＲａｎｇｅフィールドに開始時刻の現在時刻からの相対値を負数で指定し、過去の時刻を開始時刻として要求した場合、本実施例のメディア配信装置１０は、ヒントファイル１１１に格納されている情報を参照し、パケットファイル１１２の要求された開始時刻に対応する位置から蓄積した映像データを読み込み、クライアント端末３０へのストリーミング配信を開始する。

図1のシステム構成では、クライアント端末３０を一つ記しているが、本実施例のメディア配信装置１０には複数のクライアント端末３０を接続することができるため、これにより、異なるクライアント端末３０毎に異なる開始時刻を指定してライブ映像のストリーミング配信においてタイムシフト再生を実現することができる。同様に、ライブ映像のストリーミング配信における、過去の時刻へ遡るジャンプ再生も、ＰＡＵＳＥ要求を受信した時刻とＰＬＡＹ要求にＲａｎｇｅフィールドで指定される相対時刻値とから求まる時刻位置からのパケットファイル１１２を読み込むことにより実現することができる。すなわち、ライブストリーミング配信に途中から加わったユーザも、ライブ開始後の任意の時刻に遡ってライブ映像を視聴することができる。

なお、再生開始時刻の相対値は、例えば、配信を要求するコンテンツを識別するＵＲＬのファイル名の一部として値を含めてもよい。これにより、クライアント端末３０上の再生アプリケーションプログラムを変更することなく、開始時刻を変更することができる。

上記過去の時刻へ遡るジャンプ再生に加え、再生アプリケーションがｎ倍速再生に対応している場合、クライアント端末３０が、ＰＬＡＹ要求のScaleまたはSpeedフィールドに再生速度倍率を指定し、かつ、開始時刻に過去の時刻を指定して、メディア配信装置１０に対してライブ映像のストリーミング配信を要求することにより、ライブ映像のストリーミング配信の追いかけ再生ができる。これは、図７のステップＳ３０５で説明した配信部１２２のパケット送信時間待ちを、指定された再生速度倍率に応じて短くすることにより実現することができる。

上述の実施例において、メディア配信装置１０によってサーバ装置２０からストリーミング配信されるライブ映像を、時間情報を含むヒントファイル１１１およびパケットファイル１１２としてディスク装置１１０に蓄積することにより、ライブストリーミング配信を行うサーバ装置２０に特別な機能を備えることなく、かつ、クライアント端末３０で映像データの長時間のバッファリングを行うことなく、クライアント毎に任意の時刻の一時停止、過去の時刻からの繰り返し再生等のトリックプレイを行うことができる。

図９は、本発明の第３の実施例である、メディア配信装置６０と、配信制御プロキシ装置５０の構成を表す。これらは、第１の実施例におけるメディア配信プロキシ装置１０を、分離したものである。なお、第１の実施例と同様の構成要素には同一の符号を付しその説明は省略する。

配信制御プロキシ装置５０は、配信制御部１２１からなる。メディア配信装置６０は、配信部１２２と受信部１２３からなる制御部６２０と、ヒントファイル１１１とパケットファイル１１２を格納するディスク装置１１０からなる。配信制御プロキシ装置５０は、クライアント端末３０からの配信要求を受け付け、必要に応じてサーバ装置２０に配信要求を転送し、メディア配信装置６０に配信指示を出す。

メディア配信装置６０の配信部１２２は、配信指示に従ってヒントファイル１１１およびパケットファイル１１２からパケットを構成し、ヒントファイル１１１で指定される時刻情報に従ってクライアント端末３０に対して送信する。

配信制御プロキシ装置５０は、第１の実施例における、サーバ装置２０とメディアフォーマットとに依存する処理を行う配信制御部１２１を備え、メディア配信装置６０は、第１の実施例における、サーバ装置２０やメディアフォーマットには依存しない処理を行うディスク装置１１０、送信部１２２、受信部１２３とを、備える。

すなわち、配信制御プロキシ装置５０は、メディアフォーマットに依存するが、メディア配信装置６０は、メディアフォーマットに依存しない。よって、新たなメディアフォーマットに対応する場合であっても、配信制御プロキシ装置５０を入れ替えたり、バージョンアップしたり、などの更新を行うのみで済む。

なお、配信制御プロキシ装置５０の配信制御部１２１およびメディア配信装置６０の制御部６２０は、第１の実施例と同様に、計算機上で実行されるソフトウェアによって実現されるものとして実装してもよい。

図１０は、本実施例における配信制御プロキシ装置５０およびメディア配信装置６０を用いた、大規模配信システムの構成を表す。

サーバ装置２０、クライアント端末３０、配信制御プロキシ装置５０、メディア配信装置６０は、それぞれ、直接または、ルータ装置、ゲートウェイ装置等を介して、インターネット等のネットワーク（以下、ＷＡＮという）７０に接続している。ここで、サーバ装置２０はコンテンツプロバイダが提供し、クライアント端末３０はユーザが各自用意する等で、ＷＡＮ７０と同様に、配信制御プロキシ装置５０やメディア配信装置６０とは異なる当事者の管理対象であっても何ら問題ない。

配信制御プロキシ装置５０は、複数のメディア配信装置６０を制御し、クライアント端末３０からの要求に応じて、適当な、例えば、クライアント端末３０に最も近い場所に位置するメディア配信装置６０に対して、配信指示を出せばよい。

ストリーミング配信において、一般に、配信制御処理は配信処理よりも負荷が軽く、また、必要なネットワーク帯域も少ない。このため、ひとつの配信制御プロキシ装置５０から、複数のメディア配信装置６０を制御し、また、配信制御プロキシ装置５０と、クライアント端末３０、メディア配信装置６０間のネットワーク接続は、ＷＡＮ７０を経由するものであっても何ら問題ない。

本実施例においては、クライアント端末３０にネットワーク的に近い位置、所謂エッジサイトに配置されたメディア配信装置６０が、配信制御プロキシ装置５０の配信指示に従って、クライアント端末３０に対してストリーミング配信を行うことができる。メディア配信装置６０の選択は、例えばホップ数や、または、クライアント端末３０のIPアドレス、を調べて判断してもよい。

すなわち、クライアント端末３０は、例えば、企業内のＬＡＮ（Local Area Network）８０や、同一ＩＳＰ（Internet Service Provider）が提供するＡＤＳＬ（Asymmetric Digital Subscriber Line）９０、光ファイバー網を利用するＦＴＴＨ（Fiber To The Home）１００等の広帯域のネットワークで接続されたメディア配信装置６０から配信を受けることができる。

これにより、メディア配信装置６０とクライアント端末３０間で必要なネットワーク帯域を、ＷＡＮ７０を経由する場合と比較して、容易に確保することができ、高品質なメディアデータをストリーミング配信することができる。

本実施例においても、新たなメディアフォーマットでメディアデータを配信するサーバ装置２０に対応する場合には、メディアフォーマットに依存する処理を行う配信制御プロキシ装置５０のみを更新するだけでよく、各エッジサイトに分散配置されるメディア配信装置６０を変更する必要はない。これにより、大規模配信ネットワークにおいて、新たなメディアフォーマットに対応する際の、設備および管理コストを削減することができる。

第１の実施例に係るメディア配信装置の構成を表す図である。第１の実施例に係るメディアデータ格納形式を説明するための図である。第１の実施例に係るパケットの構成を説明するための図である。第１の実施例に係る制御部の構成を示す図である。第１の実施例に係る配信制御部の配信時の動作を説明するための図である。第１の実施例に係る配信制御部の蓄積時の動作を説明するための図である。第１の実施例に係る配信部の動作を説明するための図である。第１の実施例に係る受信部の動作を説明するための図である。第３の実施例に係る配信制御プロキシ装置およびメディア配信装置の構成を表す図である。第３の実施例に係る大規模配信ネットワークの構成を表す図である。

符号の説明

１０：メディア配信装置、２０：サーバ装置、３０：クライアント端末、４０：パケットｎ、４０’：パケットｎ’、５０：配信制御プロキシ装置、６０：メディア配信装置、７０：インターネット（ＷＡＮ）、８０：ＬＡＮ、９０：ＡＤＳＬ、１００：ＦＴＴＨ、１１０：ディスク装置、１１１：ヒントファイル、１１２：パケットファイル、１２０：制御部、１２１：配信制御部、１２２：配信部、１２３：受信部。

Claims

サーバ装置がネットワークを経由してクライアント端末へストリーミング配信するメディアデータを中継するメディア配信装置であって、
前記サーバ装置が、前記ストリーミング配信を行う際に前記ネットワークに送出したパケットを受信する受信部と、記憶装置と、を備え、
前記パケットは、分割された前記メディアデータであるメディアデータ要素を一つ以上含む、所定のネットワークプロトコルに従って構成されたものであり、
前記受信部は、
前記パケットから、前記メディアデータ要素を抽出し、
当該メディアデータ要素が含まれていた前記パケットと同じ構成を持つパケットを再構成するために必要な情報を作成し、
前記抽出したメディアデータ要素と併せて、前記記憶装置に蓄積する
ことを特徴とする、メディア配信装置。
前記パケットの再構成に必要な情報は、
ヘッダ情報と、前記再構成した前記パケットを前記ネットワークに送信するタイミングを示す時刻情報と、前記パケットに含まれるべき前記メディアデータ要素を前記記憶装置から抽出するための情報とからなる
ことを特徴とする、メディア配信装置。
請求項１に記載のメディア配信装置であって、さらに、
前記再構成に必要な情報に基づいて、前記同じ構成を持つパケットを再構成し、
前記時刻情報に従って前記ネットワークに送出する、配信部を備える
ことを特徴とする、メディア配信装置。
請求項１に記載のメディア配信装置であって、
前記受信部は、前記ヘッダ情報と前記時刻情報とを、前記サーバ装置から受信した前記パケットに含まれる情報と当該パケットを受信した時刻情報に基づいて、作成する
ことを特徴とする、メディア配信装置。
サーバ装置がネットワークを経由してクライアント端末へストリーミング配信するメディアデータを中継するメディア配信装置と、前記メディア配信装置を制御する配信制御プロキシ装置とからなるメディア配信システムであって、
前記メディア配信装置は、
前記サーバ装置が、前記ストリーミング配信を行う際に前記ネットワークに送出したパケットを受信する受信部と、記憶装置と、を備え、
前記パケットは、分割された前記メディアデータであるメディアデータ要素を一つ以上含む、所定のネットワークプロトコルに従って構成されたものであり、
前記受信部は、
前記パケットから、前記メディアデータ要素を抽出し、
当該メディアデータ要素が含まれていた前記パケットと同じ構成を持つパケットを再構成するために必要な情報を作成し、
前記抽出したメディアデータ要素と併せて、前記記憶装置に蓄積するものであり、
前記配信制御プロキシ装置は、
前記クライアント端末からの配信要求を受信する手段と、
前記クライアント端末から受信した前記配信要求に応じて、前記受信部へ蓄積指示または前記配信部へ配信指示を出す配信制御部を備える
ことを特徴とする、メディア配信システム。
請求項５に記載のメディア配信システムであって、
前記パケットの再構成に必要な情報は、
ヘッダ情報と、前記再構成した前記パケットを前記ネットワークに送信するタイミングを示す時刻情報と、前記パケットに含まれるべき前記メディアデータ要素を前記記憶装置から抽出するための情報とからなる
ことを特徴とする、メディア配信システム。
請求項５に記載のメディア配信システムであって、
前記メディア配信装置は、さらに、
前記再構成に必要な情報に基づいて、前記同じ構成を持つパケットを再構成し、
前記時刻情報に従って前記ネットワークに送出する、配信部を備える
ことを特徴とする、メディア配信システム。
請求項５に記載のメディア配信システムであって、
前記受信部は、前記ヘッダ情報と前記時刻情報とを、前記サーバ装置から受信した前記パケットに含まれる情報と当該パケットを受信した時刻情報に基づいて、作成する
ことを特徴とする、メディア配信システム。