(57)【特許請求の範囲】
【請求項１】
１つ以上のトランスコーダと、
データを格納するキャッシュ型データベースと、
コンテンツ又はライブ、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、該キャッシュ型データベースに該要求されたデータが格納されるように該トランスコーダ及び該キャッシュ型データベースを連携して制御するヒット/ミス判定部と、
を備え、
該ヒット/ミス判定部はさらに要求されたコンテンツ又はライブ、及び符号化方式に対応する符号化レートの内前記要求された符号化レートに最も近い符号化レートを検索し、前記要求された符号化レートと検索された要求に最も近い符号化レートの差分絶対値が所定の閾値以下のとき、該要求データが該キャッシュ型データベースに格納されていると判断する
ことを特徴とするストリーム・サーバ。
【請求項２】
請求項１において、
さらに、ユーザ端末との間のネットワーク負荷、コンテンツサーバの混雑度、又はユーザ端末の処理能力の少なくともいずれか１つを監視し、監視結果を該ヒット/ミス判定部に与えるネットワーク監視部を有し、
該ヒット/ミス判定部が該監視結果に基づき最適符号化レートを決定することを特徴としたストリーム・サーバ。
【請求項３】
１つ以上のトランスコーダと、
データを格納するキャッシュ型データベースと、
コンテンツ又はライブ、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、該キャッシュ型データベースに該要求されたデータが格納されるように該トランスコーダ及び該キャッシュ型データベースを連携して制御するヒット/ミス判定部と、
を備え、
該トランスコーダが、空間スケーラビリティ、時間スケーラビリティ、又はSNRスケーラビリティによる階層符号化において、符号化レート変更対象階層及びその１つ上位の階層の符号化データのみ新規に作成し、該新規上位階層より伸長された復号データと現上位階層より伸長された復号データの差分絶対値の和が所定の閾値以下であるとき該新規作成された変更対象階層及び上位階層を現階層とすることを特徴とするストリーム・サーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はストリーム・サーバに関し、特にストリーミング技術等によるインターネット等を媒体としてライブ及びコンテンツを配信するストリーム・サーバに関するものである。
【０００２】
近年、ADSL及び無線LAN等の普及によるインターネット等のネットワークのブロードバンド化が進んでいる。これに伴い、データ、音声、映像等を送受信するマルチメディア・多チャネルの通信環境が急速に整備されている。さらに、常時接続が一般化され、情報家電とネットワークの融合化が促進され、映像・音楽等のコンテンツ配信及びライブ配信等の需要が拡大している。
【０００３】
このようなネットワークにおいては、マルチメディアを多重化して１つのディジタル情報の流れとして扱うストリーミング技術によるライブ及びコンテンツを配信は重要である。
【背景技術】
【０００４】
図10は、従来のライブ配信及びコンテンツ配信例を示している。ユーザ端末(PDA)170_2がライブ720を配信要求したときに、キャッシュサーバ150_2がライブ720を保持していない場合、映像入力装置120で撮影されたライブ720は、リアルタイムエンコーダ130に与えられる。
【０００５】
エンコーダ130は、ライブ720を、要求された符号化方式・符号化レートのデータに変換して、IPネットワーク140及びキャッシュサーバ150_2を経由したライブ配信720aで、ユーザ端末170_2に送信する。このとき、キャッシュサーバ150_2は、ライブ720を一時的に記憶する。
【０００６】
ユーザ端末(携帯電話)170_3が、同じ符号化方式・符号化レートのライブ720を配信要求したとき、キャッシュサーバ150_2は、記憶したライブ720を、ライブ配信720bでユーザ端末170_3に送信する。
【０００７】
コンテンツ710は、コンテンツサーバ110のソースデータベース700に格納されている。ユーザ端末(デスクトップPC)170_1がコンテンツ710を配信要求したときに、キャッシュサーバ150_1がコンテンツ710を記憶していない場合、コンテンツ710は、コンテンツサーバ110からIPネットワーク140及びターミナルアダプタ(TA)160を経由して、ユーザ端末170_1にコンテンツ配信710aが行われる。
【０００８】
このとき、キャッシュサーバ150_1は、コンテンツ710を一時記憶する。この後、例えば、ユーザ端末170_2からコンテンツ710の配信要求があったときのキャッシュサーバ150_1の動作は、キャッシュサーバ150_2と同様である。
【０００９】
ライブ配信720a，720b及びコンテンツ配信710aは、例えば、リファレンスデータ参照による伸長処理を行うMPEGストリーム等で行われる。
【００１０】
IPネットワーク140は、基本的にはベストエフォート型であり、MPEGストリームを長時間途切れずに配信には適応していない。
【００１１】
この課題を解決する従来技術として、例えば、リアルタイム転送プロトコル(Real-time Transport Protocol、以下、RTPと称する。)、リアルタイム転送制御プロトコル(Real-time Transport Control Protocol、以下、RTCPと称する。)、及びリアルタイム・ストリーム制御プロトコル(Real Time Streaming Protocol、以下RTSPと称する。)等のストリーミング技術がある。
【００１２】
RTPは、メディア同期が受信側で可能となるように、音声データや映像データを伝送する際のパケット形式を定めた伝送プロトコルである。RTSPは、コンテンツの配信開始や一時停止等のようなストリーム制御を行うプロトコルである。RTCPは、音声や映像のストリームに対するフロー制御に必要な情報やメディア同期のための基準時間情報を伝達する手順を定めているプロトコルである。
【００１３】
これらのプロトコルによって、ユーザ端末と配信元とのネゴシエーション、データ配信時におけるネットワーク負荷、及びユーザ端末の処理能力等の与えられた環境を考慮したより快適なRTPストリーム（コンテンツ配信又はライブ配信）がリアルタイムで制御される。
【００１４】
しかしながら、従来のストリーミング環境においては、ライブ配信は、ストリーム・サーバ(配信側)から、固定化された複数の符号化レートのデータを不特定多数のユーザ端末(受信側)に対して配信している。
【００１５】
ユーザ端末は、自身の処理能力に応じて、配信元から固定化された複数の符号化レートのデータの内から選択して受信している。従って、不特定多数のユーザ端末に対して、それぞれ、ネットワーク負荷及びユーザ端末の処理能力等をリアルタイムに考慮した、快適なマルチキャスト型のコンテンツ配信及びライブ配信を実現していない。
【００１６】
すなわち、従来のストリーミング環境は、コンテンツ配信において、或る１つのコンテンツ（ワンソース）を、符号化方式のみならず、リアルタイムな最適符号化レートも各ユーザ端末に対応したデータ（マルチユース）を配信することは困難である。
【００１７】
これを解決するためには、ユーザ端末数分のリアルタイムエンコーダ、若しくは全符号化レートのデータのデータベースといった、莫大なハードウェアが必要であり現実的ではない。
【００１８】
すなわち、コンテンツ、符号化方式のみならず符号化レートまでを範疇としたワンソース・マルチユース化ができない。
【００１９】
また、ライブ配信において、リアルタイムエンコーダ130がリアルタイムエンコードデータを、そのままネットワークに配信するため、ユーザ端末は、コンテンツ・サーバに対して、巻き戻し、一時停止等のコミュニケーション（選択性）の拡張が困難である。
【００２０】
したがって、ユーザ端末は、コンテンツ配信とライブ配信が異なることを考慮したサービスを受けなければならない。また、配信サーバは、コンテンツ・サーバとライブ・サーバが独立装置であり、それぞれ独立に制御する必要があり、コンテンツ配信とライブ配信の融合が困難である。
【００２１】
コンテンツ配信において、コンテンツに対応する複数の符号化データを予めデータベース化しているため、多数のユーザが視聴する映画コンテンツ、或る個人ユーザのみが視聴するパーソナルビデオコンテンツに関係なく、全コンテンツデータをデータベース化する必要があり、莫大なデータベース容量が必要となる。
【００２２】
このため、最近のトレンドである個人ユーザがオリジナルに制作したディジタルコンテンツ等を格納するパーソナルデータベースの構築にも限界が生じる。
【００２３】
また、コンテンツ配信において、データベースは、圧縮された符号化データを格納しており、MPEGストリームにおけるシーケンスヘッダの任意位置への挿入/削除が困難なため、ユーザ端末(受信側)任意の映像の頭出し機能、アクセス回線種別、ネットワークの混雑度、ユーザ端末処理能力等を考慮した最適符号化レート/解像度変更等が困難である。
【００２４】
また、従来のコンテンツ配信又はライブ配信は、配信サーバとキャッシュサーバ(エッジサーバ)が独立配備かつ独立動作しており、キャッシュサーバでは、ユーザ端末(受信側)から要求されたコンテンツ又はライブ、符号化方式を考慮したヒット/ミス判定は可能である。
【００２５】
しかし、ネゴシエーション又はユーザ端末からのRR(Receiver Report)タイプのRTCPパケットのフィードバックをトリガとして決定した符号化レートまでを考慮した要求データの視聴開始/停止/変更を管理できない。したがって、視聴率を考慮したヒット/ミス判定を実施することが困難である。
【００２６】
従来のコンテンツ配信又はライブ配信は、ネゴシエーション動作時又はストリーミングにおけるRRタイプのRTCPパケットフィードバック時のような、ユーザ端末からのアクションに対応して、ストリーム・サーバが動作している。
【００２７】
したがって、ある映画コンテンツの配信開始となった日時に不特定多数ユーザからの視聴要求が重なった場合に、トランスコーダ(transcoder)へのアクセス競合が多数発生し、ユーザ端末に対する配信サービスの即応性が困難になる。
【００２８】
また、従来のコンテンツ配信又はライブ配信におけるキャッシュサーバ(エッジサーバ)は、様々なコンテンツ又はライブデータ、符号化方式、符号化レート等のデータが格納されており、ユーザ端末が要求するデータの有無の確認を全格納データに対して行うため、そのヒット/ミス判定回路は莫大なハードウェア規模が必要になる。
【００２９】
また、従来のコンテンツ配信又はライブ配信は、配信サーバとキャッシュサーバ(エッジサーバ)が独立配備かつ独立動作しており、ユーザ端末からのキャッシュサーバ(エッジサーバ)内に格納されていない新コンテンツ又はライブ、新符号化方式、新符号化レートが要求された場合、ミス判定になる。
【００３０】
これにより、配信サーバは上記コンテンツ、符号化方式に対応したデータをキャッシュサーバに配信するため、キャッシュサーバは、必ず既に格納されているデータを破棄しなければならない。
【００３１】
また、キャッシュサーバ(エッジサーバ)のヒット/ミス判定において、配信サーバ側の混雑度等を考慮しないため、配信サーバの即応性が悪い場合には、配信データのスループットの低下、揺らぎ等が発生する。
【００３２】
また、従来の階層符号化において、ある階層データの符号化レート又は解像度等を変更する場合には、上記階層をリファレンスデータとして参照し、符号化処理を実施する。
【００３３】
以後、全上位階層データも再生成する必要があるため、莫大なハードウェアが必要となり、かつトランスコーダ等の資源の使用回数の増大(資源の有効活用が困難)を招く。
【００３４】
そこで本発明は、ストリーミング技術等によるインターネット等を媒体としてライブ及びコンテンツを配信するストリーム・サーバにおいて、以下の項目(1)〜(9)を目的とする。
【００３５】
(1)不特定多数ユーザ端末に対して、それぞれ与えられた環境、すなわち、ネットワーク負荷、ユーザ端末の処理能力、又はストリーム・サーバの混雑度等にリアルタイムに対応したコンテンツ配信又はライブ配信を行う。
【００３６】
(2)コンテンツ配信とライブ配信とを融合することを、少ないハードウエアで実現する。
【００３７】
(3)必要なデータベースの容量を削減する。
【００３８】
(4)要求されたコンテンツ及び符号化方式のみならず、要求された符号化レートに対応したワンソース・マルチユースを実現する。
【００３９】
(5)ユーザ端末が、アクセス回線種別、ネットワークの混雑度、及びユーザ端末処理能力に対応した、任意の映像の頭出し、最適符号化レート変更、及び解像度変更を行うことを可能とする。
【００４０】
(6)視聴率に対応したコンテンツ又はライブ配信サービスを行う。
【００４１】
(7)ユーザが要求したデータの有無の判定を高速化する。
【００４２】
(8)ユーザから要求された新コンテンツ又は新ライブ、新符号化方式、及び新符号化レートのデータのヒットミスを少なくする。
【００４３】
(9)階層符号化において、符号化レート及び解像度の変更の効率化を図る。
【先行技術文献】
【００４４】
・特開2000-228669号
・特開2001-54095号
・特開2001-54094号
・特開平10-108160号
・特開2000-299702号
【発明の開示】
【００４５】
上記の課題を解決するため、本発明のストリーム・サーバは、１つ以上のトランスコーダと、データを格納するキャッシュ型データベースと、コンテンツ又はライブ、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、該キャッシュ型データベースに該要求されたデータが格納されるように該トランスコーダ及び該キャッシュ型データベースを連携して制御するヒット/ミス判定部と、を備え、該ヒット/ミス判定部はさらに要求されたコンテンツ又はライブ、及び符号化方式に対応する符号化レートの内前記要求された符号化レートに最も近い符号化レートを検索し、前記要求された符号化レートと検索された要求に最も近い符号化レートの差分絶対値が所定の閾値以下のとき、該要求データが該キャッシュ型データベースに格納されていると判断することを特徴としている。
【００４６】
すなわち、トランスコーダは、通常の如く、指定されたコンテンツ又はライブを、指定された符号化方式の指定された符号化レートのデータに変換する。このデータをキャッシュ型データベースは格納する。
【００４７】
ヒット/ミス判定部は、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、要求されたデータをキャッシュ型データベースに格納することを、トランスコーダ及びキャッシュ型データベースが連携して制御する。
【００４８】
これにより、キャッシュ型データベースは、例えばユーザ端末から要求されたコンテンツ又はライブを、要求された符号化方式の要求された符号化レートのデータとして格納することになり、各ユーザ端末は、要求した符号化方式の符号化レートのコンテンツ配信又はライブ配信を実現することが可能になる。
【００４９】
なお、ここで言うキャッシュ型データベース及びトランスコーダは、後述するそれぞれ制御/調停部が含んでいるものとするが、以下において、キャッシュ型データベースをキャッシュ型データベース本体とその制御/調停部に分け、トランスコーダをトランスコーダとその制御/調停部に分けて表示することがある。
【００５０】
また、上記のトランスコーダはエンコーダ又はCODECであることが可能である。
【００５１】
すなわち、トランスコーダには、CODEC、及びエンコーダを含むものとする。例えば、ライブ配信の場合、トランスコーダの代わりにエンコーダを用いることが可能である。
【００５２】
また、上記のキャッシュ型データベースが、同一のコンテンツ又はライブ及び符号化方式に対して異なる符号化レートの該データをそれぞれ格納する複数のラインを有することができる。
【００５３】
すなわち、キャッシュ型データベースは、複数のラインを有し、これらのラインには、それぞれ、例えば、同一のコンテンツ及び符号化方式に対して異なる符号化レートに変換したデータが格納される。
【００５４】
これにより、不特定多数のユーザ端末に対してマルチキャスト型コンテンツ配信又はライブ配信を実現する。すなわち、コンテンツ又はライブ、符号化方式、さらには符号化レートを各ユーザ端末に対応して配信するワンソース・マルチユースを実現することが可能になる。
【００５５】
また、ユーザ端末との間で、呼制御、又は該データの配信の開始制御、一時停止制御、若しくは巻戻し制御に関するネゴシエーションを行い、その結果を該ヒット/ミス判定部に通知する呼制御/ネゴシエーション処理部をさらに有し、該ヒット/ミス判定部が、該結果に基づき該トランスコーダ及び該キャッシュ型データベースに対する連携制御を行うことが可能である。
【００５６】
すなわち、呼制御/ネゴシエーション処理部はユーザ端末との間で、呼制御、又は該データの配信の開始制御、一時停止制御、若しくは巻戻しのネゴシエーションを行う。
【００５７】
この結果に基づき、ヒット/ミス判定部は、キャッシュ型データベースに格納されたデータの配信の開始、一時停止、又は巻戻し制御を行う。
【００５８】
これにより、コンテンツ配信に対する開始、一時停止、巻戻制御が可能になるとともにライブ配信をデータをキャッシュ型データベースに格納後、行うことにより、ライブ配信に対する開始、一時停止、巻戻制御も可能になる。
【００５９】
また、本発明は、さらに、ユーザ端末との間のネットワーク負荷、コンテンツサーバの混雑度、又はユーザ端末の処理能力の少なくともいずれか１つを監視し、監視結果を該ヒット/ミス判定部に与えるネットワーク監視部を有し、該ヒット/ミス判定部が該監視結果に基づき最適符号化レートを決定することができる。
【００６０】
すなわち、ネットワーク監視部は、ユーザ端末との間のネットワーク負荷、コンテンツサーバの混雑度、又はユーザ端末の処理能力を監視する。この監視結果に基づきヒット/ミス判定部は、各ユーザ端末に対する最適な符号化レートを決定する。
【００６１】
これにより、例えば、ネットワーク負荷、コンテンツサーバの混雑度、ユーザ端末の現在の処理能力等をリアルタイムで考慮した符号化レートのコンテンツ配信又はライブ配信が可能になる。
【００６２】
すなわち、与えられた環境の中で、ユーザに対して、より快適なコンテンツ配信又はライブ配信をリアルタイムに制御することが可能になる。
【００６３】
また、上記において、所定のプロトコルを実装し、該所定プロトコルに基づきユーザ端末との間の通信処理を行うプロトコル実装処理部をさらに有することができる。
【００６４】
すなわち、プロトコル実装処理部は、本ストリーム・サーバとユーザ端末との間の通信処理を行うプロトコルを実装している。この実装されたプロトコルに基づき、コンテンツ配信又はライブ配信の及びそれらの制御を実行することができる。
【００６５】
また、上記のプロトコル実装処理部が、少なくともIPヘッダ処理部、UDPヘッダ処理部、RTPヘッダ処理部、RTCPヘッダ処理部、及びRTSPヘッダ処理部の中のいずれか１つを備えることができる。
【００６６】
これにより、IP、UDP、RTP、RTCP、RTSP等のプロトコルに基づきコンテンツ配信又はライブ配信及びそれらの制御することが可能になる。
【００６７】
また、上記のプロトコル実装処理部が、MPEGシーケンスヘッダ処理部を備えていることができる。
【００６８】
これにより、アクセス回線種別、ネットワークの混雑度、又はユーザ端末能力を考慮した、MPEG符号化方式の最適符号化レートの変更及び解像度変更、並びに任意の映像の頭出し機能等が容易になる。
【００６９】
また、上記のトランスコーダは、入力した少なくとも素材データ、トランスコードデータ、及びライブデータの内のいずれか１つを該指定された符号化方式の指定された符号化レートのデータに変換することができる。
【００７０】
すなわち、トランスコーダは、例えば、ソースデータベース装置から素材データ又はトランスコードデータを入力し、映像入力装置からライブデータを入力して該データに変換することができる。
【００７１】
なお、ストリーム・サーバとソースデータベース装置及び映像入力装置との接続は、直接接続及びネットワークを介した接続のいずれでもよい。
【００７２】
また、上記のヒット/ミス判定部が、要求されたコンテンツ又はライブの検索、その符号化方式の検索、符号化レートの検索、及びデータが有効であるか否かの検索の順序を所定の順序で行い要求データのヒット/ミス判定を行うことができる。
【００７３】
すなわち、ヒット/ミス判定部は、例えば、要求されたコンテンツ又はライブ及びその符号化方式の検索、符号化レートの検索、及びデータが有効であるか否かの検索の順序で要求データのヒット/ミス判定を行う。
【００７４】
これにより、ヒット/ミス判定が容易になると共に、ハードウェアの大幅な削減が可能になる。
【００７５】
また、上記のヒット/ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されているか否かの判定に、該符号化レートが許容範囲に入っている否かを判定することができる。
【００７６】
すなわち、該ヒット/ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートに変換されたのデータが該キャッシュ型データベースに格納されているか否かの判定するとき、例えば、要求された符号化レートと同一符号化レートでなく、要求された符号化レートから許容範囲にある符号化レートのデータもヒットしたものとみなす。
【００７７】
これにより、要求された符号化レートの代わりに、許容範囲内の符号化レートのデータを配信することが可能になり、要求された全ての符号化レートのデータを格納する必要がなくなり、効率的にキャッシュ型データベースを運用することが可能になるとともに、安定したコンテンツ配信及びライブ配信が実現する。
【００７８】
また、上記のヒット/ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されていないとき、該要求されたコンテンツ又はライブ、要求された符号化方式であり、該要求された符号化レートに近い符号化レートのデータを破棄し、該データが格納されていた位置に、該要求されたデータを格納するように該トランスコーダ及び該キャッシュ型データベースを連携して制御することができる。
【００７９】
すなわち、ヒット/ミス判定部は、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されていなとき、該要求されたコンテンツ又はライブであって要求された符号化方式であるが、該要求された符号化レートに近い符号化レートのデータを検索して破棄する。
【００８０】
そして、ヒット/ミス判定部は、該データが格納されていた位置に、該要求されたデータを格納するように該トランスコーダ及び該キャッシュ型データベースを連携して制御する。
【００８１】
これにより、要求されたデータをユーザ端末に配信することが可能になる。
【００８２】
また、上記のヒット/ミス判定部が、低視聴率のコンテンツデータ又はライブデータ、又は低視聴率の符号化レートのデータを破棄することができる。
【００８３】
これにより、該キャッシュ型データベースのサイズを削減することが可能になるとともに、高視聴率のコンテンツ又はライブのデータを保持され続けるため、キャッシュ型データベースのヒット率も高くなる。
【００８４】
また、上記のキャッシュ型データベースは、該ネットワーク監視部から与えられた、該要求されたデータについて、その視聴開始時刻情報、停止時刻情報、及び変更時刻情報を格納し、該ヒット/ミス判定部が、該情報に基づきヒット/ミス判定を行うことができる。
【００８５】
すなわち、該キャッシュ型データベースは、該ネットワーク監視部から与えられた、該要求されたデータについて、その視聴開始時刻情報、停止時刻情報、及び変更時刻情報を格納する。該ヒット/ミス判定部が、該情報に基づき、例えば、リアルタイムな視聴率を計算し、この視聴率に基づきヒット/ミス判定を行う。
【００８６】
これにより、ヒット/ミス判定部は、例えば、リアルタイムな視聴率を考慮したヒット/ミス判定を行うことが可能になる。
【００８７】
また、上記のヒット/ミス判定部が、低視聴率のコンテンツデータ又はライブデータ、低視聴率の符号化方式、又は低視聴率の符号化レートのデータの内の少なくとも１つを破棄して、該破棄されたデータが格納されていた場所に、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納するように該トランスコーダ及びキャッシュ型データベースに指示することができる。
【００８８】
すなわち、ヒット/ミス判定部は、例えば、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納する場所がキャッシュ型データベース内に無いとき、低視聴率のコンテンツデータ又はライブデータ、低視聴率の符号化方式、又は低視聴率の符号化レートのデータを破棄する。
【００８９】
そして、破棄したデータが格納されていた場所に、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納する。
【００９０】
これにより、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納する場所を確保することが可能になる。
【００９１】
また、該キャッシュ型データベースのサイズを削減することが可能になるとともに、高視聴率のコンテンツ又はライブのデータが保持され続ける。
【００９２】
これにより、キャッシュ型データベースのヒット率も高くなり、効率的なキャッシュ型データベースの運用を実現することができる。
【００９３】
また、上記のヒット/ミス判定部は、未使用トランスコーダがあるとき、このトランスコーダ及び該キャッシュ型データベースを制御して、新規コンテンツ又は新規ライブを所定符号化レートの所定符号化方式のデータに変換し、該キャッシュ型データベースに格納することができる。
【００９４】
すなわち、ヒット/ミス判定部は、新規コンテンツ又は新規ライブがあるときで、且つ使用していないトランスコーダがあるとき、新規コンテンツ又は新規ライブを所定符号化レートの所定符号化方式のデータに変換し、該キャッシュ型データベースに格納するように該トランスコーダ及び該キャッシュ型データベースを制御する。
【００９５】
これにより、トランスコーダは、例えば、要求されたコンテンツの変換を行っていないときで且つキャッシュ型データベースに空きがあるとき、事前に新規コンテンツを所定符号化方式の所定符号化レートのデータに変換することが可能になる。この結果、トランスコーダ及びキャッシュ型データベースのアクセス競合を回避することが可能になるとともに、資源の有効活用が実現できる
さらに、本発明では、該トランスコーダが、空間スケーラビリティ、時間スケーラビリティ、又はSNRスケーラビリティによる階層符号化において、符号化レート変更対象階層及びその１つ上位の階層の符号化データのみ新規に作成し、該新規上位階層より伸長された復号データと現上位階層より伸長された復号データの差分絶対値の和が所定の閾値以下であるとき該新規作成された変更対象階層及び上位階層を現階層とすることが可能である。
【００９６】
これにより、他に使用されている符号化レートデータに対して影響を与えることなく、ターゲットとなる符号化レートを変更することができる。
【００９７】
また、符号化レート変更対象階層及びその１つ上位の階層を新規作成するのみで、全上位階層のデータを新規に作成する必要がなくなり、莫大なハードウエアが必要でなくなるとともに、トランスコーダ等の資源の使用回数を少なくすることが可能になる。
【発明を実施するための最良の形態】
【００９８】
図１は、本発明に係るストリーム・サーバ100の一実施例を示している。このサーバ100は、トランスコーダ制御/調停部10、トランスコーダ20_1〜20_L（以下、符号20で総称することがある。）、データベース制御/調停部30、キャッシュ型データベース40、ヒット/ミス判定部50、ネットワーク監視部60、呼制御/ネゴシエーション処理部70、及びプロトコル実装処理部80で構成されている。
【００９９】
キャッシュ型データベース40は、コンテンツデータ又はライブデータ（以下、コンテンツデータ及びライブデータをコンテンツデータで総称することがある。）を格納するライン43_1〜43_N(以下、符号43で総称することがある。)で構成されている。
【０１００】
プロトコル実装処理部80は、IPヘッダ処理部81、UDPヘッダ処理部82、RTPヘッダ処理部83、MPEGシーケンスヘッダ処理部84、RTCPヘッダ処理部85、RTSPヘッダ処理部86で構成されている。
【０１０１】
ヒット/ミス判定部50は、キャッシュ型データベース40に要求データが格納されているか否かの確認を行い、ネットワーク監視部60はRTCPプロトコルでネットワークを監視し、呼制御/ネゴシエーション処理部70は、RTSPプロトコルで呼制御及びネゴシエーションを行う。
【０１０２】
図2(5)は、図１に示した、キャッシュ型データベース40のより詳細な構成例を示している。このデータベース40は、タグラム(TAG RAM)41、タグラム42、及びキャッシュ43で構成されている。
【０１０３】
タグラム41は、“MRU(Most Recently Used)”、“コンテンツ”、“符号化方式”、及び“タグラム42のアドレス”のフィールドから成るタグラム41_1〜41_Mで構成されている。
【０１０４】
タグラム41は、“コンテンツ”及び“符号化方式”単位に管理され、“コンテンツ”及び“符号化方式”には、それぞれ、例えば、コンテンツ情報及びその符号化方式情報が格納される。
【０１０５】
タグラム41の“MRU”には、ネゴシエーション時又はネットワーク監視((RRタイプのRTCPパケットフィードバック)時の符号化レート変更時における、視聴開始/停止/変更時刻情報等の視聴履歴情報（例えば、視聴率情報）が格納される。
【０１０６】
タグラム41の“タグラム42のアドレス”には、“コンテンツ”及び“符号化方式”に対応するタグラム42の先頭アドレスが格納される。
【０１０７】
タグラム42は、“MRU”、“符号化レート”、及び“階層”のフィールドから成るタグラム42_1〜42_N（以下、符号42で総称することがある。）で構成され、“符号化レート”単位に管理される。
【０１０８】
タグラム42の“MRU”には、符号化レート変更時における、視聴開始/停止/変更時刻情報等の視聴履歴情報（視聴率情報）が格納される。
【０１０９】
“符号化レート”、及び“階層”には、それぞれ、符号化レート情報及びその階層が格納される。
【０１１０】
キャッシュ43は、それぞれ、データ1〜データX1、…、データ1〜データXNから成るライン43_1〜43_N（以下、符号43で総称することがある。）で構成されている。各ライン43は、各データの有効/無効を示す有効フィールドをさらに含んでいる。各データ1〜X1等に格納される、コンテンツデータの管理単位はMPEGデータの場合は、GOP(Group Of Picture)である。
【０１１１】
このライン43_1〜43_Nは、それぞれ、タグラム42_1〜42_Nに対応しており、この対応関係は、例えば、タグラム42にライン43の先頭アドレスを示すフィールド（図示せず）を設けて示す。
【０１１２】
同図(2)は、同図(5)に示したタグラム41_1をより詳細に示しており、このタグラム41_1には、管理単位のコンテンツ及び符号化方式が、それぞれ「コンテンツ710_1」及び「MPEG2」であり、そのMRUが視聴履歴01〜視聴履歴0xであることを示している。
【０１１３】
さらに、タグラム41_1には、「コンテンツ710_1」及び「MPEG2」に対応するタグラム42（符号化レート)の先頭アドレスが、「0x0」，「0x1」，…，「0xy」であることが示されている。
【０１１４】
同図(3)は、同図(5)に示したタグラム42_1，42_2，…のより詳細例を示している。この例では、タグラム41_1のタグラム42アドレス＝“0x0”で指定されたタグラム42_1が示されている。
【０１１５】
このタグラム42_1は、符号化レート＝“1Mbps”の階層が“1”であり、そのMRUが視聴履歴11〜1Xであることを示している。
【０１１６】
ストリーム・サーバ100の基本的動作として、ヒット/ミス判定部50が、ユーザ端末からの契機〔1〕ネゴシエーション時、又は契機〔2〕RRタイプのRTCPパケットフィードバック時（ネットワーク監視時）に、それぞれキャッシュ型データベース40のヒット/ミス判定を行う。
【０１１７】
また、ヒット/ミス判定部50は、契機〔1〕又は〔2〕以外の契機〔3〕未使用のトランスコーダが存在し、且つ人気コンテンツがソースデータベースに新規格納され、キャッシュ型データベース40には未格納の場合、自律的な連携動作でキャッシュ型データベース40のヒット/ミス判定を行い、人気コンテンツの符号化データをキャッシュ型データベース40に格納する。
【０１１８】
これにより、例えば、人気コンテンツ配信開始時における不特定多数ユーザからの配信要求が競合した際においても、通常はキャッシュ型データベースより読み出すことができる。このように、有限数のトランスコーダ資源の有効活用ができるとともに、ユーザ端末(受信側)に対する配信サービスの即応性が実現できる。
【０１１９】
図３は、ストリーム・サーバ100のヒット/ミス判定部の基本的な動作手順を示している。ストリーミング技術においては、図２に示したように、例えば、コンテンツ（又はライブ）710_1及び符号化方式(MPEG2)に対して複数の符号化レート（1Mbps，5Mbps，…，20Mbps）がサポートされる。
【０１２０】
そこで、ヒット/ミス判定部50は、キャッシュ型データベース40のヒット/ミス判定を下記の(T1)〜(T3)の３段階で行う。
【０１２１】
(T1)タグラム41を検索して、要求コンテンツ又はライブ及び符号化方式が格納されているか否かを判定する（図2(1)の判定T1参照）。
【０１２２】
(T2)次に、タグラム42の検索を検索して、要求符号化レートが格納されているか否かを判定する（図2(1)の判定T2参照）。
【０１２３】
(T3)最後に、キャッシュ43の「有効(Valid)フィールド」を検索して、要求データが格納されているか否かを判定する（図2(1)の判定T3参照）。
【０１２４】
［1］ネゴシエーション時
図４は、本発明のストリーム・サーバ100のネゴシエーション時（契機〔1〕）における動作手順例を示している。同図及び図１、図２を参照してネゴシエーション時における動作手順を以下に説明する。
【０１２５】
なお、この説明においては、図１に示したソースデータベース700に格納されているコンテンツ710をユーザ端末170が要求した場合について説明する。
【０１２６】
ユーザ端末がライブ720を要求した場合も同様であるが、ライブ配信の場合、トランスコーダ20としてエンコーダを用いることもでき、同図に示したトランスコーダ制御/調停部10はエンコーダ制御/調停部10になる。
【０１２７】
図４において、破線で囲まれたステップS100はヒット/ミス判定部50のキャッシュ型データベース検索手順を示し、破線で囲まれたステップS200はトランスコーダ制御/調停部10、データベース制御/調停部30、及びヒット/ミス判定部50におけるトランスコーダエントリ手順を示し、破線で囲まれたステップS300はプロトコル実装処理部80のプロトコル実装処理手順を示している。
【０１２８】
図１において、呼制御/ネゴシエーション処理部70は、ユーザ端末170から呼制御/ネゴシエーション動作によりストリーム・サーバ100とユーザ端末170との間のコネクションを確立する。
【０１２９】
ステップS110〜S130：ヒット/ミス判定部50は、ユーザ端末170が要求したコンテンツデータ、符号化方式、及び符号化レート、例えば、コンテンツ710_1、MPEG2、及び５Mbpsと一致するデータがキャッシュ型データベース40に格納されているか否かを確認する。
【０１３０】
すなわち、図２において、ヒット/ミス判定部50は、ユーザ端末170から同図(1)に示した(T0)例えば、コンテンツ名＝コンテンツ710_1、符号化方式＝“MPEG2”、及び符号化レート＝“5Mbps”の要求を受ける。
【０１３１】
なお、ネゴシエーション時には、同図(1)に示したGOP番号の要求はない。
【０１３２】
そこで、ヒット/ミス判定部50は、同図(2)において、タグラム41から、コンテンツ710_1及び符号化方式＝“MPEG2”を検索する同図(1)に示したヒット/ミス判定T1を行い、タグラム41_1にヒットする。
【０１３３】
さらに、ヒット/ミス判定部50は、タグラム41_1のタグラム42アドレスフィールドに示された先頭アドレス＝0x0，0x1，…，0xyにそれぞれ対応するタグラム42_1〜42_yの中から符号化レート＝“５Mbps”を検索する同図(1)に示したヒット/ミス判定T2を行い、タグラム42_2にヒットする。
【０１３４】
ステップS180：さらに、ヒット/ミス判定部50は、ヒットしたタグラム42_2に対応するライン43_2のデータが有効であるか否かを判定するヒット/ミス判定T3（図2(4)参照）を行う。
【０１３５】
符号化されたデータが有効である場合、ヒット/ミス判定部50は、有効なデータ“1”をデータ802として読み出しプロトコル実装処理部80に与える。この動作を繰り返すことにより、ライン43_2のデータ1〜データX2は、順次、プロトコル実装処理部80に与えられることになる。
【０１３６】
データが無効である場合、ヒット/ミス判定部50は、トランスコーダエントリのステップS210に進む。
【０１３７】
ステップS310〜S340：プロトコル実装処理部80は、MPEGシーケンスヘッダ、RTPヘッダ、UDPヘッダ、及びIPヘッダをデータ801に挿入した後、IPネットワーク140を経由して、ユーザ端末170にライン43_2に格納されたコンテンツの配信を開始する（図2(1)のデータ配信T4）。
【０１３８】
ステップS140〜S170：ステップS110、S120でミスした（データが存在しない）場合、ヒット/ミス判定部50は、キャッシュ型データベース40の内から、データ未格納ライン43の検索、又は、予め設定された閾値aより低い視聴率のコンテンツの検索、低視聴率の符号化方式の検索、低視聴率の符号化レートの検索を行う。
【０１３９】
すなわち、ヒット/ミス判定部50は、図2(5)において、データ未格納ライン43を検索し、無い（ミス）場合、タグラム41のMRUの内で閾値aより低い視聴率を示したコンテンツ/符号化方式を検索し、無い（ミス）場合、タグラム42のMRUの内で閾値aより低い視聴率を示した符号化レートを検索する。
【０１４０】
ステップS210：上記の検索の１つにヒットした（ヒットラインがある）場合、ヒット/ミス判定部50は、トランスコーダ制御/調停部10及びデータベース制御/調停部30に対して、それぞれトランスコーダエントリ要求信号800及び信号801与える。
【０１４１】
トランスコーダ制御/調停部10は、例えば、トランスコーダ20_2が未使用である場合、トランスコーダエントリ要求信号800が示す、ユーザが要求したコンテンツ（素材又はトランスコード）710をソースデータベース700からトランスコーダ20_2に与える。
【０１４２】
未使用のトランスコーダが無い場合、ステップS290に進む。
【０１４３】
ステップS220：トランスコーダ20_2は、コンテンツ710に対してリアルタイムエンコード処理したデータをデータベース制御/調停部30に与える。データベース制御/調停部30は、キャッシュ型データベース40内の例えば未格納ライン（又は低視聴率ライン）43_1にエンコードされたデータを格納する(キャッシュフィル)。
【０１４４】
ステップS230：ヒット/ミス判定部50は、キャッシュフィルされたライン43_2からデータ802を読み出しプロトコル実装処理部80に与える。
【０１４５】
ステップS310〜S340：プロトコル実装処理部80は、上記のステップS310〜S340と同様に、IPネットワーク140を経由して、順次、ユーザ端末170に要求されたコンテンツ配信又はライブ配信を開始する。
【０１４６】
ステップS290：上記のステップS140〜S170において、未格納ラインの検索、低視聴率のコンテンツの検索、低視聴率の符号化方式の検索、及び低視聴率の符号化レートの検索が全てミスの場合、又はステップS210において、未使用トランスコーダ20が無い（トランスコーダエントリ要求に失敗した）場合、ユーザ端末170からのエントリ要求は失敗となる。
【０１４７】
［2］ネットワーク監視時
図５は、ストリーム・サーバ100が、ユーザ端末170に対してコンテンツ配信又はライブ配信を行っている時、ユーザ端末170（図１参照）からRRタイプRTCPパケットを受信した時の動作手順を示している。
【０１４８】
この動作手順を、図２を参照して以下に説明する。図５においてステップS400はネットワーク監視手順を示し、ステップS500はキャッシュ型データベースの検索手順を示し、ステップS600はトランスコーダへのエントリ手順を示し、ステップS800は、プロトコル実装処理手順を示している。
【０１４９】
ステップS410：呼制御/ネゴシエーション処理部70は、ユーザ端末170から送信されたRRタイプのRTCPパケットを受信し、このパケットに含まれるフィードバック情報をヒット/ミス判定部50に与える。
【０１５０】
RRタイプRTCPパケットは、ストリームを受信したユーザ端末がストリームの受信状態（パケットの廃棄率(Fraction Lost）、累積パケット廃棄率(Cumulative Number of Packet Lost)、パケット到着間のゆらぎ(Interarrival Jitter)）に関する情報をストリーム送信側にフィードバックするパケットである。
【０１５１】
この情報に基づき、ヒット/ミス判定部50は、視聴者数、視聴履歴、パケット廃棄率、累積パケット廃棄率、パケット到着間隔の揺らぎ等より、現在のネットワークの混雑度、ユーザ端末170の能力等を考慮した最適符号化レートを算出する。
【０１５２】
すなわち、ヒット/ミス判定部50は、図2(1)のT0、すなわち、ユーザ端末170に対して配信しているコンテンツ名、符号化方式、符号化レート、及びGOP番号を決定する。
【０１５３】
ステップS510：ヒット/ミス判定部50は、算出した最適符号化レートと一致するデータがキャッシュ型データベース40に格納されているか否かの確認を行う。
【０１５４】
すなわち、ヒット/ミス判定部50は、図2(2)及び(3)において、要求されたコンテンツ及び符号化方式に対する最適な符号化レートがあるか否かのヒット/ミス判定T1，T2を行う。
【０１５５】
ステップS590，S710：最適な符号化レートが存在する(ヒット)場合、ヒット/ミス判定部50は、符号化レートに対応するラインのデータが有効か否かのヒット/ミス判定T3を行う（同図(1)参照）。
【０１５６】
データがヒットした（有効の）場合、ヒット/ミス判定部50は、ヒットしたライン43から読み出したデータ802をプロトコル実装処理部80に与える。
【０１５７】
ステップS810〜S840：プロトコル実装処理部80は、MPEGシーケンスヘッダ、RTPヘッダ、UDPヘッダ、IPヘッダを挿入した最適符号化レートデータ802をユーザ端末170に、IPネットワーク140を経由して順次配信する。これにより、前の符号化レートデータに継続して最適符号化レートデータ802が、ユーザ端末170に配信されることになる。
【０１５８】
ステップS590，S770：データがミスした（無効の）場合は、キャッシュには要求する符号化レートは存在するが、対象となるデータ自体が存在しない状態を示す。
【０１５９】
そこで、ヒット/ミス判定部50は、信号800及び信号801をそれぞれトランスコーダ制御/調停部10及びデータベース制御/調停部30に与える。
【０１６０】
これらの信号800及び信号801に基づき、現在使用中のトランスコーダは、要求されたコンテンツを、要求された符号化方式で要求された符号化レートのデータにエンコードし、このデータは、ステップS510でヒットしたライン43に格納される（キャッシュフィル）。
【０１６１】
ステップS780：ヒット/ミス判定部50は、ヒットライン43のデータを読み出して、プロトコル実装処理部80に与える。
【０１６２】
ステップS810〜S840：プロトコル実装処理部80は、MPEGシーケンスヘッダ、RTPヘッダ、UDPヘッダ、IPヘッダを挿入したデータ802をユーザ端末170に、IPネットワーク140を経由して順次配信する。
【０１６３】
これにより、最適符号化レートのデータが、ユーザ端末170に配信されることになる。
【０１６４】
ステップS510，S520：最適符号化レートのデータが存在しない(ミス)場合、ヒット/ミス判定部50は、最適符号化レートに最も近い符号化データをキャッシュ型データベース40から検索する。
【０１６５】
すなわち、ヒット/ミス判定部50は、図2(2)、(3)において、要求されたコンテンツ及び符号化方式に対応するタグラム41に対応するタグラム42の符号化レートの内で最適符号化ルートに最も近い符号化レート（比較対照符号化レート）を検索する。
【０１６６】
ステップS530：差分絶対値x＝｜最適符号化レート−比較対象符号化レート｜が予め設定された閾値b以下の場合、ヒット/ミス判定部50は、要求データが存在する(ヒット)とみなす。
【０１６７】
ステップS590：そして、ヒット/ミス判定部50は、ヒットとみなしたラインのデータが有効か否かのヒット/ミス判定T3を行い、有効である場合、データを読み出し、プロトコル実装処理部80に与える。
【０１６８】
すなわち、ヒット/ミス判定部50は、図2(3)、(4)において、ヒットした符号化レートのタグラム42に対応するライン43から読み出した有効なデータ802をプロトコル実装処理部80に与える。以後の動作は、上記のステップS810〜S840と同様である。
【０１６９】
これにより、最適符号化レートのデータではないが、許容範囲内の符号化レートのデータ802が、ユーザ端末170に配信されることになる。
【０１７０】
ステップS540：差分絶対値xが、設定された閾値bより大きく閾値c以下である場合、ヒット/ミス判定部50は、要求データが存在せず(図2(1)のヒット/ミス判定T1，T2におけるミス判定)且つキャッシュ型データベース40に格納されている比較対象符号化レートのデータが不要である(RRタイプのRTCPパケットによる符号化レートの変更要求がある)ため、トランスコーダ制御/調停部10に対してトランスコーダエントリ要求信号800を与える。
【０１７１】
ステップS610，S620：トランスコーダ制御/調停部10は、トランスコーダエントリ要求に対して、トランスコーダ20の内に未使用トランスコーダ20が存在する場合、素材データ又はトランスコードデータをソースとして、リアルタイムエンコード処理を行い、処理したデータをキャッシュ型データベース40内の比較対象符号化レートライン（ミスライン）に格納する(キャッシュフィル)。
【０１７２】
ステップS720：ヒット/ミス判定部50は、このキャッシュフィルされたラインから読み出したデータ802をプロトコル実装処理部80に与える。
【０１７３】
ステップS810〜S840：プロトコル実装処理部80は、データ801をIPネットワーク140を経由してユーザ端末170に順次配信する。
【０１７４】
これにより、最適符号化レートとの差分絶対値が閾値bより大きく閾値c以下の比較対象符号化レートのラインに最適符号化レートのデータをフィルすることが可能になる。このデータフィルによっても、比較対象符号化レートのラインのデータを使用するユーザ端末に対する映像及び音声への影響が少ない。
【０１７５】
差分絶対値が設定された閾値cより大きい場合、比較対象データから要求データへの符号化レート変更を行うと、比較対象符号化レートのデータを使用するユーザに対する映像及び音声への影響が大きい。
【０１７６】
そこで、ヒット/ミス判定部50は以下の判定を行う。
【０１７７】
ステップS550，S630：ヒット/ミス判定部50は、比較対象符号化レートの差分絶対値が大きいため、キャッシュ型データベース40の未格納ライン43を検索し、対象となるラインが存在する(ヒット)場合、トランスコーダ制御/調停部10に対してトランスコーダエントリ要求信号800を与える。
【０１７８】
ステップS640，S730：トランスコーダ制御/調停部10は、トランスコーダエントリ要求に対して、未使用のトランスコーダ20が存在する場合、素材データもしくはトランスコードデータを未使用トランスコーダ20に与える。
【０１７９】
このトランスコーダ20は、与えられたデータに対してリアルタイムエンコード処理を行い、データベース制御/調停部30を経由して未格納ライン43に格納（キャッシュフィル）する。このフィルラインからデータ802が読み出されてユーザ端末に送信される。
【０１８０】
ステップS560〜S580：ヒット/ミス判定部50は、未格納ラインが無いため、キャッシュ型データベース40から予め設定された閾値aより低い視聴率のコンテンツ、符号化方式、又は符号化レートのライン43を検索し、対象となるデータが存在する(ヒット)場合、トランスコーダ制御/調停部10に対してトランスコーダエントリを要求する。
【０１８１】
ステップS650，S660：トランスコーダ制御/調停部10は、トランスコーダエントリ要求に対して、未使用のトランスコーダ20が存在する場合、素材データもしくはトランスコードデータを未使用トランスコーダ20に与える。
【０１８２】
このトランスコーダ20は、与えられたデータに対してリアルタイムエンコード処理を行いデータベース制御/調停部30を経由してキャッシュ型データベース40内の低視聴率ライン43に格納する（キャッシュフィル）。
【０１８３】
ステップS740：ヒット/ミス判定部50は、キャッシュフィルされたライン43からデータ802を読み出し、プロトコル実装処理部に与える。
【０１８４】
ステップS810〜S840：プロトコル実装処理部80は、上記のヘッダを挿入したデータをユーザ端末に順次配信を継続する。
【０１８５】
ステップS580，S670，S680，S760：上記キャッシュ型データベースに格納されている、未格納ライン及び閾値aより低い視聴履歴ライン検索において、対象となるデータが存在しない場合、ヒット/ミス判定部50はトランスコーダ制御/調停部10に対してトランスコーダエントリ要求信号800を与える。
【０１８６】
未使用トランスコーダが存在する場合、素材データもしくはトランスコードデータに対してはリアルタイムエンコード処理が行われ、キャッシュ型データベース40内の比較対象符号化レートライン43に格納する（キャッシュフィル）。このキャッシュフィルされたライン43から読み出されたデータがプロトコル実装処理部80に与えられる。
【０１８７】
ステップS810〜S840：プロトコル実装処理部80は、ユーザ端末170に順次データ配信を継続する。
【０１８８】
ステップS610，S630，S650，S670，S750：未使用トランスコーダ20が存在しない場合、RRタイプのRTCPパケットに基づく符号化レート変更要求は失敗となる。
【０１８９】
ヒット/ミス判定部50は、現在の符号化レートのデータの送信を継続し、次回符号化レート変更要求を待つ。
【０１９０】
このようなトランスコーダ制御/調停部10、トランスコーダ20、データベース制御/調停部30、キャッシュ型データベース40、及びヒット/ミス判定部50の連携動作により、ストリーム・サーバ100は、ライブ配信のみならず、コンテンツ配信においても、リアルタイムにネットワーク負荷、ユーザ端末の処理能力等を考慮した、リアルタイムエンコード処理を行うことが可能になる。
【０１９１】
また、ストリーム・サーバ100は、低視聴率の符号化レートの符号化方式のコンテンツデータ及びライブデータを破棄することにより、高視聴率の符号化レートの符号化方式のコンテンツデータ及びライブデータのみが、キャッシュ型データベース40に格納され続けることになる。
【０１９２】
この結果、通常は、キャッシュ型データベース40に格納されている高視聴率データを多くのユーザ端末に配信することができる。
【０１９３】
すなわち、ストリーム・サーバ100は、不特定多数ユーザに対して、それぞれ、リアルタイムのネットワーク負荷、ユーザ端末170の処理能力、ストリーム・サーバ100の混雑度等を考慮した、快適なマルチキャスト型コンテンツ配信及びライブ配信が実現でき、コンテンツ及び符号化方式のみならず、符号化レートまでを範疇とした、“ワンソース・マルチユース化”を実現できる。
【０１９４】
また、ストリーム・サーバ100は、不特定多数ユーザに対するコンテンツ配信データ及びライブ配信データは、通常、高視聴率の符号化レートの符号化方式のコンテンツデータ及びライブデータを格納するキャッシュ型データベースより読み出すことができる(ヒットする)ため、ユーザ数分のトランスコーダを備える必要はなく、トランスコーダ数の大幅な削減が可能になる。
【０１９５】
また、ストリーム・サーバ100のキャッシュ型データベース40は、常に、個人ユーザのみが視聴する低視聴率のコンテンツ及びライブは破棄され、多数のユーザが視聴する映画コンテンツ等の高視聴率コンテンツ及び高視聴率ライブのみが保存され続けるため、データベースサイズの大幅な削減が実現でき、且つストリーム・サーバ100でのパーソナルデータベースの配信サービスも容易となる。
【０１９６】
また、ストリーム・サーバ100は、トランスコーダ20の後段にキャッシュ型データベース40を配置し、コンテンツデータ及びライブデータを一旦キャッシュ型データベース40に格納後、ユーザに配信されるため、ライブ配信においても、ユーザ端末(受信側)からストリーム・サーバ(配信側)に対する巻戻し、一時停止要求といったコミュニケーション機能(選択性)の拡張が可能である。
【０１９７】
すなわち、ユーザ端末(受信側)170は、ライブ配信とコンテンツ配信の区別することなく、サービスを享受することができ、ライブ配信とコンテンツ配信の融合が可能となる。
【０１９８】
また、ストリーム・サーバ100は、キャッシュ型データベース40の後段に、MPEGシーケンスヘッダ処理部84を挿入することにより、シーケンスヘッダに実装されている、フレームレート及び解像度等を変更することが容易となり、ユーザ端末(受信側)任意の映像の頭出し機能、アクセス回線種別、ネットワークの混雑度、ユーザ端末の処理能力等を考慮した、最適符号化レート/解像度変更等が容易に実現できる。
【０１９９】
このように、本発明のストリーム・サーバ100は、トランスコーダ20とキャッシュ型データベース40との連携動作により、不特定多数ユーザ端末170に対する快適なマルチキャスト型通信によるワンソース・マルチユース化、ユーザ端末170とストリーム・サーバ100間のコミュニティ環境の構築によるライブ配信とコンテンツ配信の融合、与えられた環境の中で、ストリーム・サーバ(配信側)は、リアルタイムかつ最適な制御を実現でき、ユーザ(受信側)は、より快適な配信サービスを享受できると共に、さらに大幅なハードウェア削減が可能になる。
【０２００】
図６は、本発明のストリーム・サーバ100のヒット/ミス判定部50における要求コンテンツ（又はライブ）及び符号化方式等のヒット/ミス判定法をより詳細に示している。なお、同図に示されているステップ符号は、図４のステップ符号に対応している。
【０２０１】
〔1〕ネゴシエーション時におけるキャッシュ型データベース40の３段階検索フローに基づくヒット/ミス判定(1)〜(5)を以下に説明する。
【０２０２】
(1)ヒット/ミス判定部50は、タグラム41を検索して、要求コンテンツ（又はライブ）及び符号化方式のヒット/ミス判定T1を行う。要求データが存在する(ヒット)場合には、後述する図７の要求符号化レートのヒット/ミス判定T2へ遷移する（図４のステップS110〜S130参照）。
【０２０３】
(2)要求データがタグラム41に存在しない(ミス)場合、ヒット/ミス判定部50は、タグラム42の未格納ライン43を検索し、要求データを未格納ライン43に格納する（同ステップS140，S210，S220参照）。
【０２０４】
(3)タグラム42の検索において、未格納ラインが存在しない(ミス)場合、ヒット/ミス判定部50は、低視聴率のコンテンツラインを検索し、対象となるデータが存在する(ヒット)場合、低視聴率のコンテンツラインのデータを破棄して、このラインに要求データを格納する（同ステップS150，S160，S210，S220参照)。
【０２０５】
(4)タグラム41の検索において、低視聴率のコンテンツラインが存在しない(ミス)場合、ヒット/ミス判定部50は、タグラム42のMRUより低視聴率の符号化レートラインを検索し、対象となるデータが存在する(ヒット)場合、低視聴率の符号化レートラインのデータを破棄し、このラインに要求データを格納する（同ステップS170，S210，S220参照)。
【０２０６】
(5)タグラム41，42の検索において、低視聴率のコンテンツ、及び低視聴率の符号化レートが存在しない場合、ヒット/ミス判定部50は対象データ読み出し失敗となる（同ステップS180参照）。
【０２０７】
〔3〕未使用トランスコーダが有る時のキャッシュ型データベース40の自律動作によるヒット/ミス判定(6)〜(10)を以下に説明する。この自律動作により、ソースデータベースに新規に格納された人気コンテンツが自動的にキャッシュ型データベースに格納される。(6)〜(10)の動作は、それぞれ、上述した(1)〜(5)と同様ある。
【０２０８】
(6)ヒット/ミス判定部50は、要求（新規）符号化方式のコンテンツ（又はライブ）がある（ヒットした）場合、後述する図７の符号化レートのヒット/ミス判定T2に遷移する。
【０２０９】
(7)要求符号化方式のコンテンツ（又はライブ）が無く（ミスし）、且つ未格納ラインが有る場合、要求符号化方式のコンテンツ（又はライブ）を未格納ラインに追加する。
【０２１０】
(8)要求符号化方式のコンテンツ（又はライブ）が無く（ミスし）、未格納ラインが無く、且つ低視聴率のコンテンツが有る場合、低視聴率のコンテンツを破棄して、要求符号化方式のコンテンツ（又はライブ）を破棄した低視聴率のコンテンツラインに追加する。
【０２１１】
(9)要求符号化方式のコンテンツ（又はライブ）が無く（ミスし）、未格納ラインが無く、低視聴率のコンテンツが無く、且つ低視聴率の符号化レートが有る場合、低視聴率の符号化レートを破棄して、要求符号化方式のコンテンツ（又はライブ）を破棄した低視聴率の符号化レートラインに追加する。
【０２１２】
(10)要求符号化方式のコンテンツ（又はライブ）が無く（ミスし）、未格納ラインが無く、低視聴率のコンテンツが無く、且つ低視聴率の符号化レートが無い場合、新規コンテンツのエントリは失敗となる。
【０２１３】
(7)〜(9)により、新規コンテンツが自律的にキャッシュ型データベースに格納されたことになる。
【０２１４】
図７は、本発明のにおける要求符号化レートのヒット/ミス判定T2の例を示している。
【０２１５】
この判定は冗長性をもたせている。すなわち、差分絶対値x（現在配信しているキャッシュ型データベース40に格納されている比較対象の符号化データの符号化レートと、要求データの符号化レートとの差分の絶対値x）と、所定の閾値b，cとの大小関係によって判定が異なる。
【０２１６】
また、ネゴシエーション時とネットワーク監視（RRタイプのRTCPパケットフィードバック）時とでは、判定動作が異なる。なお、同図に示されているステップ符号は、図４、図５のステップ符号に対応している。
【０２１７】
〔1〕ネゴシエーション時における要求符号化レート等のヒット/ミス判定(1)〜(5)を以下に説明する。
【０２１８】
(1)ヒット/ミス判定部50は、差分絶対値x≦閾値bである場合、要求符号化レートが存在する（ヒット）と判定し、要求符号化データに冗長を持ったヒット/ミス判定T3に遷移する。
【０２１９】
(2)ヒット/ミス判定部50は、閾値b＜差分絶対値xである場合、要求符号化レートが存在しない（ミス）と判定し、タグラム42のMRUより未格納ラインを検索し未格納ラインが有る場合、要求データを未格納ラインに格納する。
【０２２０】
(3)ヒット/ミス判定部50は、上記の未格納ライン検索において、未格納ラインが存在しない(ミス)場合、要求符号化レートのヒット/ミス判定を強制ヒット判定し、次の要求符号化データのヒット/ミス判定T3へ遷移する。
【０２２１】
〔3〕ネットワーク監視（RRタイプのRTCPパケットフィードバック）時における要求符号化レートのヒット/ミス判定T2(4)〜(8)を以下に説明する。
【０２２２】
(4)ヒット/ミス判定部50は、差分絶対値x≦閾値bである場合、要求符号化レートが存在する（みなしヒット）と判定し、要求符号化データのヒット/ミス判定T3に遷移する。
【０２２３】
(5)ヒット/ミス判定部50は、閾値b＜差分絶対値x≦閾値cである場合、要求符号化レートが存在しない（ミス）と判定し、比較対象符号化レートラインのデータを破棄した後、このラインに要求データを格納する。
【０２２４】
(6)ヒット/ミス判定部50は、閾値c＜差分絶対値xである場合、要求符号化レートが存在しない（ミス）と判定し、タグラム42のMRUより未格納ラインを検索し未格納ラインが有り、且つ対象となるデータが存在する(ヒット)場合、要求データを未格納ラインに格納する。
【０２２５】
(7)ヒット/ミス判定部50は、上記の未格納ライン検索で未格納ラインが存在しない（ミス）場合、タグラム42において、低視聴率の符号化レートラインが存在する(ヒット)場合、要求データを低視聴率の符号化レートラインに格納する。
【０２２６】
(8)ヒット/ミス判定部50は、上記の未格納ライン及び低視聴率の符号化レートラインが存在しない(ミス)場合、比較対象符号化レートのラインを破棄し、このラインに要求データを格納する。
【０２２７】
なお、上記の(5)〜(8)は、使用するトランスコーダが有る場合の処理である。
【０２２８】
また、符号化RTCPパケット(RRタイプ)フィードバックによるリアルタイムな符号化レート制御を行っているため、未使用トランスコーダ存在時における自律的な符号化レート制御（要求符号化レートのヒット/ミス判定T2）は基本的には不要である。
【０２２９】
上記の要求符号化データのヒット/ミス判定T3に遷移した場合、ヒット/ミス判定部50は、キャッシュ43の検索においてヒット/ミス判定T3行い、要求データが存在する(ヒット)場合、ヒット判定し、要求データが存在しない(ミス)場合、要求データを対象インデックスに格納する。
【０２３０】
上記のようにキャッシュ型データベース40において、図２に示すようにタグラム41のMRU及びタグラム42のMRUに、それぞれ、コンテンツ及び符号化方式単位並びに符号化レート単位の各ユーザの視聴開始/停止/変更時刻情報をキューイングすることにより、キャッシュ型データベースに格納されているデータに対する各ユーザの視聴開始/停止時刻、リアルタイムな視聴率を考慮したヒット/ミス判定を行うことができる。
【０２３１】
また、上記のキャッシュ型データベース40のヒット/ミス判定は、通常の判定契機［1］：或るユーザ端末(受信側)からの配信要求によるネゴシエーション時、通常の判定契機［2］：RRタイプのRTCPパケットフィードバック時がある。さらに、ヒット/ミス判定は、判定契機［1］及び［2］以外に、未使用トランスコーダが存在する時を動作契機［3］とすることにより、ソースデータベースに新規格納され、かつキャッシュ型データベースに未格納である、人気コンテンツを事前に格納（キャッシュフィル）することができる。
【０２３２】
また、ストリーミング技術においては、或る一つのコンテンツまたは、ライブ、符号化方式に対する、複数の符号化レートをサポートしている。
【０２３３】
したがって、キャッシュ型データベース40のヒット/ミス判定は、ユーザから配信要求に対して、要求コンテンツ又はライブ、符号化方式が対応するデータの検索（ヒット/ミス判定T1）を行い、次に要求符号化レートが対応するデータの検索（ヒット/ミス判定T2）を行い、最後に要求データの検索（ヒット/ミス判定T3）を行うといった３段階的な検索を行うことにより、判定の容易化/高速化が実現できるとともに、ヒット/ミス判定回路のハードウェア規模の大幅な削減が実現できる。
【０２３４】
また、キャッシュ型データベース40のヒット/ミス判定は、ユーザ(受信側)からの要求コンテンツ又はライブ、符号化方式、符号化レート、及び符号化データが存在しない(ミス)場合は、タグラム41のMRU、タグラム42のMRUに格納されている視聴履歴を参照して、低視聴率のコンテンツ、符号化レートラインを破棄するため、不特定多数ユーザが要求する高視聴率のコンテンツ及び高視聴率の符号化レートのデータのみが格納され、効率的なキャッシュ運用を実現する。
【０２３５】
また、キャッシュ型データベースのヒット/ミス判定は、RRタイプのRTCPパケットによるフィードバック情報を基にしたネットワークの混雑度、ユーザ端末処理能力を考慮した最適な要求符号化レートに対する、現在使用されている符号化レートとの差分絶対値が、所定の閾値以下の場合は、冗長性をもたせたヒット/ミス判定を行うことにより、リアルタイムなネットワークの混雑度、ユーザ端末処理能力の急激な変化に追従しない。
【０２３６】
また、所定の閾値以上の場合においても、キャッシュ型データベースに格納されているデータが、例えば全て高視聴率データの場合は、強制ヒット判定を行うことにより、他ユーザへの配信データに対して、影響を与えない。
【０２３７】
上記の動作により、本発明のストリーム・サーバは、自律動作による自身の配信要求データ、及び他のユーザ端末へ配信データが実現できる。
【０２３８】
図８、９は、本発明のストリーム・サーバ100における階層化符号化方式例を示している。この階層符号化は、空間スケーラビリティ、時間スケーラビリティ、及びSNR(Signal to Noise Ratio)スケーラビリティ等により階層化され、或る階層の符号化レートを変更する際に、符号化レート変更対象の階層及びこの階層の１つ上位の階層の符号化データのみ、新規符号化データを作成する。
【０２３９】
図８は、低符号化レートを高符号化レートに変更する場合を示している。同図(1)において、各階層1，2，3，及び4の階層の符号化レートは、それぞれ、1Mbps，5Mbps、10Mbps、及び20Mbpsである。
【０２４０】
同図(4)は、同図(1)に示した各階層1〜4の符号化レートが格納されているバンク90を示しており、バンク90_1〜90_4には、それぞれ、符号化レート1Mbps，5Mbps，10Mbps，20Mbpsのデータが格納されている。
【０２４１】
同図(2)、(5)において、階層2の符号化レートを5Mbps(低符号化レート)から7Mbps(高符号化レート)に変更する場合、新階層2新規符号化データ、及びこの新階層2をリファレンスとして伸長動作を行う新階層3(10Mbps)の新規符号化データを、それぞれバンク90_5，90_6に格納する。
【０２４２】
同図(3)、(6)において、新階層3より伸長された復号フレームデータと現階層3により伸長された復号フレームデータの差分絶対値和が、或る閾値以下になった場合に、現階層2、3(バンク90_2，90_3)を破棄し、新階層2，3（バンク90_5，90_6）を現階層2，3とし、新しい階層構成に切り替える。
【０２４３】
図９は、高符号化レートを低符号化レートに変更する場合を示している。同図(1)及び(4)は、それぞれ、図8(1)及び(4)と同様である。
【０２４４】
図9(2)、(5)において、階層3の符号化レートを10Mbps(高符号化レート)から7Mbps(低符号化レート)に変更する場合、新階層3（7Mbps）、及びこの新階層3をリファレンスとして伸長動作を行う新階層4(20Mbps)の新規符号化データをバンク90_5，90_6に格納する。
【０２４５】
同図(3)、(6)において、新階層4より伸長された復号フレームデータと現階層4により伸長された復号フレームデータの差分絶対値和が、或る閾値以下になった場合に、現階層3、4(バンク90_3，90_4)を破棄し、新階層3，4（バンク90_5，90_6）を現階層2，3とし、新しい階層構成に切り替える。
【０２４６】
すなわち、上記階層符号化における、或る一つの階層の符号化レートを変更する場合に、この階層データをリファレンスデータとして使用する、以降の上位階層すべてのデータ変更を行うことなく、一つ上位の階層データのみの変更を行うことで、符号化レートを変更して新しい階層構成を構築することができる。
【０２４７】
この符号化レート変更において、必要となるバンク数は、階層数＋２のみで実現でき、ハードウェア規模の削減が可能である。
【０２４８】
以上説明したように、本発明のストリーム・サーバによれば、不特定多数ユーザ端末に対して、それぞれ与えられた環境、すなわち、ネットワーク負荷、ユーザ端末の処理能力、又はストリーム・サーバの混雑度にリアルタイムに対応したコンテンツ配信を行うこと、また、コンテンツ配信とライブ配信の融合することを、少ないハードウエアで実現することが可能になる。
【図面の簡単な説明】
【０２４９】
【図１】本発明に係るストリーム・サーバの一実施例を示したブロック図である。
【図２】本発明に係るストリーム・サーバにおけるキャッシュ型データベースの一構成例を示したブロック図である。
【図３】本発明に係るストリーム・サーバにおける３段階検索手順例を示した図である。
【図４】本発明に係るストリーム・サーバのネゴシエーション時における動作手順を示したフローチャート図である。
【図５】本発明に係るストリーム・サーバのネットワーク監視時における動作手順を示したフローチャート図である。
【図６】本発明に係るストリーム・サーバにおける要求コンテンツ（又はライブ）及び符号化方式等のヒット/ミス判定及びその後の処理を示した図である。
【図７】本発明に係るストリーム・サーバにおける要求符号化レート等のヒット/ミス判定及びその後の処理を示した図である。
【図８】本発明に係るストリーム・サーバにおける階層符号化における符号化レート変更例(低符号化レート→高符号化レート)を示した図である。
【図９】本発明に係るストリーム・サーバにおける階層符号化における符号化レート変更法(高符号化レート→低符号化レート)を示した図である。
【図１０】従来のコンテンツ配信及びライブ配信を示したブロック図である。
【符号の説明】
【０２５０】
100  ストリーム・サーバ               10  トランスコーダ制御/調停部
20，20_1〜20_L  トランスコーダ、エンコーダ、CODEC
30  データベース制御/調停部           40  キャッシュ型データベース
41，41_1〜41_M  タグラム(TAG_RAM)     41a  視聴履歴（MRU）
41b  コンテンツ名(Contents)           41c  符号化方式(COD)
41d  タグラム・アドレス(TAG_RAM_Adr)  42，42_1〜42_N  タグラム
42a  視聴履歴(MRU)                42b  符号化レート(Rate)
42c  階層(Layer)                      43  キャッシュ
43_1〜43_N  ライン(LINE)              43a  インデックス
50  ヒット/ミス判定部                 60  ネットワーク監視部
70  呼制御/ネゴシエーション処理部     80  プロトコル実装処理部
81  IPヘッダ処理部                    82  UDPヘッダ処理部
83  RTPヘッダ処理部                   84  MPEGシーケンスヘッダ処理部
85  RTCPヘッダ処理部                  86  RTSPヘッダ処理部
90，90_1〜90_6  バンク
110  コンテンツサーバ                 120  映像入力装置
130  リアルタイムエンコーダ           140  IPネットワーク
150_1，150_2  キャッシュサーバ        160  ターミナルアダプタ(TA)
170  ユーザ端末
170_1  ユーザ端末(デスクトップPC)
170_2  ユーザ端末(PDA)                170_3  ユーザ端末(携帯電話)
700  ソースデータベース
710，710_1〜710_3，720_1，720_2  コンテンツ
710a  コンテンツ配信                  720  ライブ
720a，720b  ライブ配信
800  トランスコーダエントリ要求信号   801  信号
802  データ
a，b，c  閾値                         x  差分絶対値
01〜0x，11〜1x，21〜2x，y1〜yx  視聴履歴
T1〜T3  ヒット/ミス判定
図中、同一符号は同一又は相当部分を示す。
【図１】
0004408811.tif 000002
【図２】
0004408811.tif 000003
【図３】
0004408811.tif 000004
【図４】
0004408811.tif 000005
【図５】
0004408811.tif 000006
【図６】
0004408811.tif 000007
【図７】
0004408811.tif 000008
【図８】
0004408811.tif 000009
【図９】
0004408811.tif 000010
【図１０】
0004408811.tif 000011