(57)【特許請求の範囲】
【請求項１】
ネットワークを介して複数のクライアントとビデオサーバが接続されたビデオオンデマンドシステムにおけるビデオサーバであって、
コンテンツ、およびクライアントが復号化できる圧縮形式ならびにクライアントが受信可能な最大受信ビットレートを含むクライアントのデコーダの仕様に関する情報を記憶するデータベースと、
前記クライアントに配信するコンテンツを圧縮形式で前記データベースに登録する手段と、
前記クライアントからの配信要求に応答して、要求されたコンテンツの圧縮形式が前記クライアントが復号化できる圧縮形式に対応するか否かおよびビットレートが最大受信ビットレートの範囲内に入るか否かを前記データベースを参照して判断する手段と、
前記データベースに登録されたクライアントの仕様と前記コンテンツの仕様とが対応すると前記判断手段が判断したとき、対応するコンテンツを前記データベースから読み出し、前記クライアントに圧縮形式で配信する手段と、
前記クライアントのデコーダの仕様に変更があった場合に変更のある属性を前記配信要求とともに前記クライアントから通知される仕様変更に応答して、前記データベースに記憶されたクライアントの仕様のうち通知された変更のある属性について更新する手段と、
を有することを特徴とするビデオサーバ。
【請求項２】
前記判断手段により前記クライアントの仕様と前記コンテンツの仕様とが対応しないと判断したとき、前記クライアントに配信すべき圧縮データを復号化するデコーダと、
前記デコーダで復号化されたデータを前記クライアントがサポートする圧縮形式およびビットレートに再圧縮するエンコーダと、
を備え、
前記エンコーダにより再圧縮されたデータを前記配信する手段により配信することを特徴とする請求項１記載のビデオサーバ。
【請求項３】
ネットワークを介して複数のクライアントとビデオサーバが接続されたビデオオンデマンドシステムにおいて、
前記ビデオサーバは、
コンテンツ、およびクライアントが復号化できる圧縮形式ならびにクライアントが受信可能な最大受信ビットレートを含むクライアントのデコーダの仕様に関する情報を記憶するデータベースと、
前記クライアントに配信するコンテンツを圧縮形式で前記データベースに登録する手段と、
前記クライアントからの配信要求に応答して、要求されたコンテンツの圧縮形式が前記クライアントが復号化できる圧縮形式に対応するか否かおよび前記コンテンツのビットレートが前記クライアントが受信可能な最大受信ビットレートの範囲内に入るか否かを前記データベースを参照して判断する手段と、
前記データベースに登録されたクライアントの仕様と前記コンテンツの仕様とが対応すると前記判断手段が判断したとき、対応するコンテンツを前記データベースから読み出し、前記クライアントに圧縮形式で配信する手段と、
前記クライアントのデコーダの仕様に変更があった場合に変更のある属性を前記配信要求とともに前記クライアントから通知される仕様変更に応答して、前記データベースに記憶されたクライアントの仕様のうち通知された変更のある属性について更新する手段とを有し、
前記クライアントは、
前記ビデオサーバから配信された圧縮されたコンテンツを復号化するデコーダと、
前記コンテンツの配信要求時に、前記クライアントのデコーダの仕様に変更があった場合に変更のある属性について前記デコーダの仕様変更を前記ビデオサーバに前記配信要求とともに通知する手段とを有することを特徴とするビデオオンデマンドシステム。
【請求項４】
前記ビデオサーバは、前記クライアントからの仕様変更通知に応答して、前記クライアントが前記データベースに登録されているか否か判断し、登録されていると判断したとき、前記クライアントに対して、変更された仕様の属性値の送信を要求し、登録されていないと判断したとき、前記クライアントに対して仕様に関するすべての属性の送信を要求し、前記データベースを更新することを特徴とする請求項３に記載のビデオオンデマンドシステム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
この発明はビデオオンデマンドシステムにおいて、クライアント仕様に合わせてサービスを提供することができるようにしたビデオサーバおよびクライアントに関する。
【０００２】
【従来の技術】
従来、ビデオオンデマンドシステムでは、ビデオサーバがクライアントの仕様に関わりなく、ビデオサーバが持つ固定的なサービスを一方的に提供していた。
【０００３】
【発明が解決しようとする課題】
クライアントがビデオサーバの提供しうるサービスに対応していない場合、クライアントはビデオサーバから送られてくるデータを受信しても、何もすることができなかった。特開平８−２７４９０２では、クライアントの仕様に応じて可変ビットレートを固定ビットレートに変換する方式を提案しているが、その他の圧縮形式、圧縮パラメータに対してはクライアントが対応していない場合、対策手段が無い。
【０００４】
この発明は上記事情に鑑みて成されたものであり、その目的は、ビデオオンデマンドシステムにおいて、クライアントの仕様に対応したコンテンツを配信することができるビデオサーバを提供することである。
【０００５】
【課題を解決するための手段】
この発明によれば、ネットワークを介して複数のクライアントとビデオサーバが接続されたビデオオンデマンドシステムにおいて、前記ビデオサーバは、コンテンツを圧縮形式で登録を行う手段と、コンテンツを圧縮形式で配信する手段と、クライアントの仕様に関する情報を保持するデータベースと、前記クライアントからの配信要求に応答して前記データベースに記憶されたクライアントの仕様と、前記クライアントの要求したビデオデータの仕様とが一致するか否かを判断し、一致したとき、前記コンテンツを前記クライアントに送信する手段を有することを特徴とする。
【０００６】
この発明によれば、クライアントの仕様に応じて柔軟なビデオオンデマンドサービスをクライアントが受けることができる。
【０００７】
また、この発明によれば、ネットワークを介して複数のクライアントとビデオサーバが接続されたビデオオンデマンドシステムにおいて、前記ビデオサーバは、コンテンツを圧縮形式で登録を行う手段と、コンテンツを圧縮形式で配信する手段と、クライアントの仕様に関する情報を保持するデータベースと、前記クライアントからの配信要求に応答して前記データベースに記憶されたクライアントの仕様と、前記クライアントの要求したビデオデータの仕様とが一致するか否かを判断し、一致したとき、前記コンテンツを前記クライアントに送信する手段と、前記クライアントの仕様と、前記クライアントの要求したビデオデータの仕様とが一致しないとき、送信すべき圧縮データを復号化するデコーダ手段と、
前記デコーダ手段で復号化されたデータを前記クライアントがサポートする圧縮形式および圧縮パラメータに再圧縮するエンコーダと、前記エンコーダにより再圧縮されたデータを前記送信手段により送信することを特徴とする。
【０００８】
この発明によれば、ビデオサーバ側にデコーダおよびエンコーダを具備し、クライアントの仕様に適応するように、コンテンツを再圧縮することができるので、クライアント側に、ビデオサーバが提供し得るすべてのサービスに対応する機能を用意する必要がなくなる。また、処理能力の劣る端末でもサービスの品質に限定があるものの、ビデオオンデマンドシステムのクライアントとして利用することができ、機器の再利用が可能である。
【０００９】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を説明する。
【００１０】
図１はこの発明のクライアント主体のビデオオンデマンドシステムを示すシステムブロック図である。図１に示すシステムは、コンテンツの圧縮形式での登録、およびコンテンツを圧縮形式での配信を行うビデオサーバ１００、受信した圧縮データのデコーダ１１０を有する複数のクライアント１０１、およびビデオサーバ１００と複数のクライアント１０１を接続するネットワーク１０２を有する。ビデオサーバ１００はクライアント１０１の仕様に関する属性値を記憶したデータベース１０３を保持する。この実施形態においては、データベース１０３は、属性として、クライアント１０１のホスト名、クライアント１０１が復号化できる圧縮形式（保存形式は後述）、圧縮パラメータに関係する、クライアント１００が受信可能な最大ビットレート(Mbps単位)、およびクライアント１０１が受信可能な最大受信パケットサイズ（バイト単位）を有する。
【００１１】
図２にデータベース１０３が有する属性情報の一例を示す。同図において、ホストＡは圧縮形式が「０１１」で、最大受信ビットレートが「５」で、最大受信パケットサイズが「１５００」である。圧縮形式は図３に示すように、ビット０乃至ビット２の３ビットで構成され、ビット０が「１」の時、クライアント１０１は、ＭＰＥＧ１をサポートすることを意味し、ビット１が「１」の時、クライアント１０１はＭＰＥＧ２をサポートすることを意味し、ビット２が「１」の時、クライアント１０１はＭＰＥＧ４をサポートすることを意味する。従って、ホストＡは、圧縮形式として、ＭＰＥＧ１およびＭＰＥＧ２をサポートし、最大受信ビットレートは５Ｍｂｐｓをサポートし、さらに最大受信パケットサイズとして１５００バイトをサポートする。同様に、ホストＢは、圧縮形式の保存形式として、ＭＰＥＧ１、ＭＰＥＧ２、およびＭＰＥＧ４をサポートするとともに、最大受信ビットレートは７Ｍｂｐｓ、最大受信パケットサイズは２０００バイトをサポートする。さらに、ホストＣは、圧縮形式の保存形式として、ＭＰＥＧ１のみをサポートし、最大受信ビットレートとして３Ｍｂｐｓ、最大受信パケットサイズとして１５００バイトをサポートする。
【００１２】
クライアント１０１がサポートしていない、圧縮形式の圧縮データを受信しても、クライアント１０１はコンテンツを復号化できない。また、圧縮データのビットレートがクライアント１０１の最大受信ビットレートを超えていれば、、フレーム落ちやブロックノイズが発生し、滑らかできれいな動画を再生できなくなる。さらに、送信データのパケットサイズがクライアントの最大受信パケットサイズを超えていれば、受信した圧縮データの一部を取りこぼすことになり、圧縮データの復号化が不可能になる。
【００１３】
データベース１０３に保持される他の属性としては、クライアント１０１が利用可能なネットワークの帯域がある。帯域制御により、ネットワークの負荷が上がった場合でも品質を損なうことなくビデオオンデマンドサービスをクライアント１０１が受けることができる。これらの属性値は、サーバ１００の管理者により、あらかじめ、各クライアント１０１について、手動で入力される。これらの属性値は自動的に更新することも可能である。すなわち、サーバ１００側からクライアント１００に対してポーリングをかけ、属性値の変更を検知したら、データベース１０３に記憶されている対応属性を変更する。
【００１４】
ビデオサーバ１００は１つのタイトルに対し、複数のビットレート、複数の圧縮形式で圧縮されたコンテンツを保持する。サーバ１００はクライアント１０１側で、デコーダ１１０の更新や追加が行われた際、追加されたり更新されたりした属性をソフトウエアにより（例えばサーバ１００側からクライアント１０１に対してポーリングをかけることにより）認識することができる機能を有する。
【００１５】
ネットワーク１０２は例えば、Ethernet, ATM, CATV網で構成し得るがこれに限定されるものではない。
【００１６】
以下、図４に示すフローチャートを参照して、図１に示すシステムの動作について説明する。
【００１７】
ステップ２０１において、クライアント１０１から配信要求があると、ビデオサーバ１００は、データベース１０３から要求のあったクライアントの対応する属性情報、すなわちリクエストしたクライアント１０１が復号可能な圧縮形式、最大受信ビットレート、最大受信パケットサイズを読み出す。ステップ２０５において、クライアント１０１から要求されたコンテンツの圧縮形式が、要求したクライアント１０１の圧縮形式に対応するか否か判断する。対応しない場合には、ビデオサーバ１００は、ステップ２０９において、要求されたサービスの提供が不可能であることを要求したクライアント１０１に通知し、リクエストをキャンセルする。
【００１８】
一方、ステップ２０５において、配信すべきコンテンツの圧縮形式が、要求したクライアント１０１の圧縮形式に対応すれば、ビデオサーバ１００は次にステップ２０７において、リクエストを受けたタイトルのコンテンツのビットレートの中に、ビデオサーバ１００がデータベース１０３から抽出した、要求元クライアントの最大受信ビットレートの範囲内に入るものがあるかどうか判断する。範囲内に入らないと判断すると、ビデオサーバ１００は上述したようにステップ２０９において、十分な品質のサービスを提供できない（例えばフレーム落ちする等）旨のメッセージをクライアント１０１へ通知し、ユーザ側にサービスを続行の是非の判断を促す。ユーザがサービスの続行を選択すれば、ステップ２１１において、サービスの提供を開始する。一方、ユーザが続行を選択しなければ、サービスをキャンセルする。
【００１９】
一方、ステップ２０７において、リクエストを受けたタイトルのコンテンツのビットレートの中に、ビデオサーバ１００がデータベース１０３から抽出した要求元クライアントの最大受信ビットレートの範囲内に入るものがあれば、ステップ２１１において、コンテンツの配信を開始する。
【００２０】
ビデオサーバ１００が圧縮データを送信する際、データベース１０３から抽出したクライアント１０１の最大受信パケットサイズ内に収まるように、パケットを区切って圧縮データを送信する。
【００２１】
このように、この発明のクライアント主体ビデオオンデマンドシステムによれば、ビデオサーバ１００のデータベース１０３にクライアント１０１の属性情報を記憶しておき、クライアント１０１から配信要求があったき、そのクライアント１０１の属性情報を読み出し、クライアント１０１が要求したタイトルのコンテンツの圧縮形式およびビットレートとクライアント１０１の圧縮形式およびビットレートが対応するか否かを判断することができるので、クライアントの仕様に応じた柔軟なビデオオンデマンドサービスをクライアントに提供することができる。
【００２２】
次に、この発明の第２の実施形態について、図５および図６を参照して説明する。なお、図１と同一部には同符号を付して説明を省略する。
【００２３】
図５に示すビデオオンデマンドシステムは図１のシステムに加えてさらに、ビデオサーバ１００がデコーダ１１１およびエンコーダ１１２を有している。すなわち、ビデオサーバ１００は、ビデオオンデマンドシステムがサポートする各圧縮形式のデコーダ１１１、エンコーダ１１２をそれぞれ有し、各コンテンツを別の形式に再圧縮する機能を有する。この機能により、異なる圧縮形式の圧縮データを作成することができ、また、同じ圧縮形式で異なるビットレートの圧縮データを作成することができる。
【００２４】
以下、図６に示すフローチャートを参照して、図５に示すシステムの動作について説明する。
【００２５】
ステップ３０１において、クライアント１０１から配信要求があるとビデオサーバ１００は、データベース１０３から、要求したクライアントが復号可能な圧縮形式、最大受信ビットレート、および最大受信パケットサイズを抽出する。そして、ステップ３０５において、ビデオサーバ１００はクライアントが要求したタイトルのコンテンツの圧縮形式とクライアント１０１側の圧縮形式とが対応するか否か判断する。リクエストを受けたタイトルのコンテンツの圧縮形式の中に、ビデオサーバ１００が抽出した圧縮形式と合致しない場合、ビデオサーバ１００は、ステップ３０９において、要求されたタイトルのコンテンツを一旦デコーダ１１１で復号化し、次にエンコーダ１１２によりクライアント１０１が復号化可能な方式に再圧縮を行ない、ステップ３１１において、クライアント１０１へ再圧縮されたデータを送信する。このとき、ビデオサーバ１００はデータ送信と並行して、再圧縮されたデータはビデオサーバ１００のコンテンツ登録プログラムにより、リクエストされたタイトルの新たなコンテンツとして圧縮データ記憶部１０４に登録される。
【００２６】
一方、ステップ３０５において、クライアント１０１が要求したタイトルのコンテンツの圧縮形式とクライアント１０１側の圧縮形式とが対応すると判断した場合には、次に、ステップ３０７において、クライアント１０１の要求したタイトルのコンテンツのビットレートが、クライアント１０１の最大受信ビットレートと合致するか否か判断する。合致しない場合には、ビデオサーバ１００は、ステップ３０９において、上述したように、デコーダ１１１により圧縮データの復号化を行ない、次に、エンコーダ１１２により、クライアント１０１の許容範囲のビットレートに再圧縮し、この再圧縮と並行して、ステップ３１０において、再圧縮されたデータは、ビデオサーバ１００のコンテンツ登録プログラムにより、リクエストされたタイトルの新たなコンテンツとして圧縮データ部１０４に登録される。再圧縮されたデータを新たなコンテンツとして登録しておくことにより、同一クライアントまたは同一の復号化機能をもつクライアントへコンテンツの配信を行う際、事前に登録されていた圧縮データを再び圧縮する必要がなくなるので、ビデオサーバに対して再圧縮に伴う負荷が軽減される。
【００２７】
また、送信に際して、ビデオサーバ１００はデータベース１０３から抽出したクライアント１０１の最大受信パケットサイズ内に収まるように、パケットを区切って圧縮データを送信する。
【００２８】
図７は、サーバ１００からのポーリング（すなわち、仕様の変更の問い合わせ）に対して、クライアント１０１のデコーダ１１０の更新或いは追加といった仕様に変更があった場合の動作を示すフローチャートである。図７に示すように、クライアント１０１はステップ４０１において、リクエストと共に、更新（追加）フラッグ、変更のある属性、および変更後（追加する）属性値をビデオサーバ１００に通知する。なお、この更新（追加）フラッグは、クライアント１０１がデコーダ１１０等の更新（追加）に際して設定する１ビットのフラッグである。通知に際しては、例えばネットワーク１０２がEthernetで構成されている場合は、ＴＣＰ／ＩＰで通知を行うというように、信頼性のある通信方式で通知を行う。クライアント１０１からの変更通知を受けて、ビデオサーバ１００はステップ４０３において、データベース１０３内にクライアント１０１が要求した属性があるか否か判断する。無ければ、ステップ４０５において、ビデオサーバ１００は、クライアント１０１に属性を要求する。ビデオサーバ１００の要求に応答して、クライアント１０１は、ステップ４０７において、属性値をビデオサーバ１００に送出する。
【００２９】
一方、ステップ４０３において、データベース１０３内に要求したクライアントの情報がある場合、あるいは、ステップ４０７におけるクライアント１０１からの属性の送信に応答して、ビデオサーバ１００はステップ４０９において、データベースを更新する。
【００３０】
図８は、クライアント１０１がある圧縮形式に対応するデコーダを削除したときの動作を示すフローチャートである。ステップ５０１において、クライアント１０１は、ビデオサーバ１００からのポーリングに対し、変更要求を送信するとともに、更新（追加フラッグ）、変更のある属性、更新後（追加する）属性値をビデオサーバ１００に通知する。ビデオサーバ１００は、クライアント１０１からの要求に応答して、ステップ５０３において、データベース１０３内の圧縮形式の属性値から、通知を受けた圧縮形式を削除する。
【００３１】
なお、上述した実施形態では、クライアント側の仕様の更新（追加）があった場合、サーバ側からのポーリングにより、クライアント側の仕様の更新（追加）を検出するように構成したが、クライアント側からサーバ側に知らせるようにしてもよい。すなわち、図９のステップ６０１において、クライアント１０１が仕様を変更すると、ステップ６０３において、クライアント１０１がサーバ１００に対して、仕様の変更を通知する。サーバ１００はこの通知に応答して、サーバの負荷量を判断する（ステップ６０５）。サーバの負荷が高ければ、更新を行わずに更新処理を終了する。この場合、属性の更新はサーバからのポーリング又は配信要求時に行われる。一方、サーバ負荷が低ければ、ステップ６０７において、サーバ１００はデータベース１０３を更新し、ステップ６０９において、クライアント１０１側の更新（追加あるいは削除）フラッグをリセットする。
【００３２】
【発明の効果】
この発明のビデオサーバおよびビデオオンデマンドシステムによれば、以下の効果が得られる。
【００３３】
第１に、クライアントの仕様に応じた柔軟なビデオオンデマンドサービスをクライアントが受けることができる。
【００３４】
第２に、クライアントに、ビデオサーバが提供しうるすべてのサービスに対応する機能を用意する必要がなくなる。また、処理能力の劣る端末でも、サービスの品質に限定があるものの、ビデオオンデマンドシステムのクライアントとして利用することができ、機器の再利用が可能である。
【００３５】
第３に、システムの拡張に容易に対応できる。しかも、システムをアップデートする際に、クライアントの下位互換に対応できる。
【００３６】
第４に、一度圧縮された圧縮データを新たなコンテンツとして再利用することができる。再圧縮に伴うビデオサーバの負荷を最小限に抑えることができる。
【図面の簡単な説明】
【図１】この発明のクライアント主体のビデオオンデマンドシステムの第１の実施形態のシステムブロック図である。
【図２】図１に示すデータベース１０３に格納されるクライアントの属性情報の一例を示す図である。
【図３】図１に示すクライアントの圧縮形式の属性値の保存形式の例を示す図である。
【図４】図１に示す第１の実施形態の動作を示すフローチャートである。
【図５】この発明のクライアント主体のビデオオンデマンドシステムの第２の実施形態を示すシステムブロック図である。
【図６】図５に示す第２の実施形態の動作を示すフローチャートである。
【図７】クライアントが属性を変更（追加）した場合のビデオサーバ側の動作を示すフローチャートである。
【図８】クライアントが圧縮形式を削除した場合のビデオサーバ側の動作を示すフローチャートである。
【図９】クライアントがサーバに対して仕様変更を通知する場合の動作を示すフローチャートである。
【符号の説明】
１００…ビデオサーバ
１０１…クライアント
１０２…ネットワーク
１０３…データベース
１１０…デコーダ
１１１…デコーダ
１１２…エンコーダ
【図１】
0003999410.tif 000002
【図２】
0003999410.tif 000003
【図３】
0003999410.tif 000004
【図４】
0003999410.tif 000005
【図５】
0003999410.tif 000006
【図６】
0003999410.tif 000007
【図７】
0003999410.tif 000008
【図８】
0003999410.tif 000009
【図９】
0003999410.tif 000010