JP3999410B2 - Video server and video on demand system - Google Patents

Video server and video on demand system Download PDF

Info

Publication number
JP3999410B2
JP3999410B2 JP16974399A JP16974399A JP3999410B2 JP 3999410 B2 JP3999410 B2 JP 3999410B2 JP 16974399 A JP16974399 A JP 16974399A JP 16974399 A JP16974399 A JP 16974399A JP 3999410 B2 JP3999410 B2 JP 3999410B2
Authority
JP
Japan
Prior art keywords
client
database
content
video
video server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP16974399A
Other languages
Japanese (ja)
Other versions
JP2000358230A (en
Inventor
紀之 平山
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP16974399A priority Critical patent/JP3999410B2/en
Publication of JP2000358230A publication Critical patent/JP2000358230A/en
Application granted granted Critical
Publication of JP3999410B2 publication Critical patent/JP3999410B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Data Exchanges In Wide-Area Networks (AREA)
  • Multi Processors (AREA)
  • Television Signal Processing For Recording (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Description

【０００１】
【発明の属する技術分野】
この発明はビデオオンデマンドシステムにおいて、クライアント仕様に合わせてサービスを提供することができるようにしたビデオサーバおよびクライアントに関する。
【０００２】
【従来の技術】
従来、ビデオオンデマンドシステムでは、ビデオサーバがクライアントの仕様に関わりなく、ビデオサーバが持つ固定的なサービスを一方的に提供していた。
【０００３】
【発明が解決しようとする課題】
クライアントがビデオサーバの提供しうるサービスに対応していない場合、クライアントはビデオサーバから送られてくるデータを受信しても、何もすることができなかった。特開平８−２７４９０２では、クライアントの仕様に応じて可変ビットレートを固定ビットレートに変換する方式を提案しているが、その他の圧縮形式、圧縮パラメータに対してはクライアントが対応していない場合、対策手段が無い。
【０００４】
この発明は上記事情に鑑みて成されたものであり、その目的は、ビデオオンデマンドシステムにおいて、クライアントの仕様に対応したコンテンツを配信することができるビデオサーバを提供することである。
【０００５】
【課題を解決するための手段】
この発明によれば、ネットワークを介して複数のクライアントとビデオサーバが接続されたビデオオンデマンドシステムにおいて、前記ビデオサーバは、コンテンツを圧縮形式で登録を行う手段と、コンテンツを圧縮形式で配信する手段と、クライアントの仕様に関する情報を保持するデータベースと、前記クライアントからの配信要求に応答して前記データベースに記憶されたクライアントの仕様と、前記クライアントの要求したビデオデータの仕様とが一致するか否かを判断し、一致したとき、前記コンテンツを前記クライアントに送信する手段を有することを特徴とする。
【０００６】
この発明によれば、クライアントの仕様に応じて柔軟なビデオオンデマンドサービスをクライアントが受けることができる。
【０００７】
また、この発明によれば、ネットワークを介して複数のクライアントとビデオサーバが接続されたビデオオンデマンドシステムにおいて、前記ビデオサーバは、コンテンツを圧縮形式で登録を行う手段と、コンテンツを圧縮形式で配信する手段と、クライアントの仕様に関する情報を保持するデータベースと、前記クライアントからの配信要求に応答して前記データベースに記憶されたクライアントの仕様と、前記クライアントの要求したビデオデータの仕様とが一致するか否かを判断し、一致したとき、前記コンテンツを前記クライアントに送信する手段と、前記クライアントの仕様と、前記クライアントの要求したビデオデータの仕様とが一致しないとき、送信すべき圧縮データを復号化するデコーダ手段と、
前記デコーダ手段で復号化されたデータを前記クライアントがサポートする圧縮形式および圧縮パラメータに再圧縮するエンコーダと、前記エンコーダにより再圧縮されたデータを前記送信手段により送信することを特徴とする。
【０００８】
この発明によれば、ビデオサーバ側にデコーダおよびエンコーダを具備し、クライアントの仕様に適応するように、コンテンツを再圧縮することができるので、クライアント側に、ビデオサーバが提供し得るすべてのサービスに対応する機能を用意する必要がなくなる。また、処理能力の劣る端末でもサービスの品質に限定があるものの、ビデオオンデマンドシステムのクライアントとして利用することができ、機器の再利用が可能である。
【０００９】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態を説明する。
【００１０】
図１はこの発明のクライアント主体のビデオオンデマンドシステムを示すシステムブロック図である。図１に示すシステムは、コンテンツの圧縮形式での登録、およびコンテンツを圧縮形式での配信を行うビデオサーバ１００、受信した圧縮データのデコーダ１１０を有する複数のクライアント１０１、およびビデオサーバ１００と複数のクライアント１０１を接続するネットワーク１０２を有する。ビデオサーバ１００はクライアント１０１の仕様に関する属性値を記憶したデータベース１０３を保持する。この実施形態においては、データベース１０３は、属性として、クライアント１０１のホスト名、クライアント１０１が復号化できる圧縮形式（保存形式は後述）、圧縮パラメータに関係する、クライアント１００が受信可能な最大ビットレート(Mbps単位)、およびクライアント１０１が受信可能な最大受信パケットサイズ（バイト単位）を有する。
【００１１】
図２にデータベース１０３が有する属性情報の一例を示す。同図において、ホストＡは圧縮形式が「０１１」で、最大受信ビットレートが「５」で、最大受信パケットサイズが「１５００」である。圧縮形式は図３に示すように、ビット０乃至ビット２の３ビットで構成され、ビット０が「１」の時、クライアント１０１は、ＭＰＥＧ１をサポートすることを意味し、ビット１が「１」の時、クライアント１０１はＭＰＥＧ２をサポートすることを意味し、ビット２が「１」の時、クライアント１０１はＭＰＥＧ４をサポートすることを意味する。従って、ホストＡは、圧縮形式として、ＭＰＥＧ１およびＭＰＥＧ２をサポートし、最大受信ビットレートは５Ｍｂｐｓをサポートし、さらに最大受信パケットサイズとして１５００バイトをサポートする。同様に、ホストＢは、圧縮形式の保存形式として、ＭＰＥＧ１、ＭＰＥＧ２、およびＭＰＥＧ４をサポートするとともに、最大受信ビットレートは７Ｍｂｐｓ、最大受信パケットサイズは２０００バイトをサポートする。さらに、ホストＣは、圧縮形式の保存形式として、ＭＰＥＧ１のみをサポートし、最大受信ビットレートとして３Ｍｂｐｓ、最大受信パケットサイズとして１５００バイトをサポートする。
【００１２】
クライアント１０１がサポートしていない、圧縮形式の圧縮データを受信しても、クライアント１０１はコンテンツを復号化できない。また、圧縮データのビットレートがクライアント１０１の最大受信ビットレートを超えていれば、、フレーム落ちやブロックノイズが発生し、滑らかできれいな動画を再生できなくなる。さらに、送信データのパケットサイズがクライアントの最大受信パケットサイズを超えていれば、受信した圧縮データの一部を取りこぼすことになり、圧縮データの復号化が不可能になる。
【００１３】
データベース１０３に保持される他の属性としては、クライアント１０１が利用可能なネットワークの帯域がある。帯域制御により、ネットワークの負荷が上がった場合でも品質を損なうことなくビデオオンデマンドサービスをクライアント１０１が受けることができる。これらの属性値は、サーバ１００の管理者により、あらかじめ、各クライアント１０１について、手動で入力される。これらの属性値は自動的に更新することも可能である。すなわち、サーバ１００側からクライアント１００に対してポーリングをかけ、属性値の変更を検知したら、データベース１０３に記憶されている対応属性を変更する。
【００１４】
ビデオサーバ１００は１つのタイトルに対し、複数のビットレート、複数の圧縮形式で圧縮されたコンテンツを保持する。サーバ１００はクライアント１０１側で、デコーダ１１０の更新や追加が行われた際、追加されたり更新されたりした属性をソフトウエアにより（例えばサーバ１００側からクライアント１０１に対してポーリングをかけることにより）認識することができる機能を有する。
【００１５】
ネットワーク１０２は例えば、Ethernet, ATM, CATV網で構成し得るがこれに限定されるものではない。
【００１６】
以下、図４に示すフローチャートを参照して、図１に示すシステムの動作について説明する。
【００１７】
ステップ２０１において、クライアント１０１から配信要求があると、ビデオサーバ１００は、データベース１０３から要求のあったクライアントの対応する属性情報、すなわちリクエストしたクライアント１０１が復号可能な圧縮形式、最大受信ビットレート、最大受信パケットサイズを読み出す。ステップ２０５において、クライアント１０１から要求されたコンテンツの圧縮形式が、要求したクライアント１０１の圧縮形式に対応するか否か判断する。対応しない場合には、ビデオサーバ１００は、ステップ２０９において、要求されたサービスの提供が不可能であることを要求したクライアント１０１に通知し、リクエストをキャンセルする。
【００１８】
一方、ステップ２０５において、配信すべきコンテンツの圧縮形式が、要求したクライアント１０１の圧縮形式に対応すれば、ビデオサーバ１００は次にステップ２０７において、リクエストを受けたタイトルのコンテンツのビットレートの中に、ビデオサーバ１００がデータベース１０３から抽出した、要求元クライアントの最大受信ビットレートの範囲内に入るものがあるかどうか判断する。範囲内に入らないと判断すると、ビデオサーバ１００は上述したようにステップ２０９において、十分な品質のサービスを提供できない（例えばフレーム落ちする等）旨のメッセージをクライアント１０１へ通知し、ユーザ側にサービスを続行の是非の判断を促す。ユーザがサービスの続行を選択すれば、ステップ２１１において、サービスの提供を開始する。一方、ユーザが続行を選択しなければ、サービスをキャンセルする。
【００１９】
一方、ステップ２０７において、リクエストを受けたタイトルのコンテンツのビットレートの中に、ビデオサーバ１００がデータベース１０３から抽出した要求元クライアントの最大受信ビットレートの範囲内に入るものがあれば、ステップ２１１において、コンテンツの配信を開始する。
【００２０】
ビデオサーバ１００が圧縮データを送信する際、データベース１０３から抽出したクライアント１０１の最大受信パケットサイズ内に収まるように、パケットを区切って圧縮データを送信する。
【００２１】
このように、この発明のクライアント主体ビデオオンデマンドシステムによれば、ビデオサーバ１００のデータベース１０３にクライアント１０１の属性情報を記憶しておき、クライアント１０１から配信要求があったき、そのクライアント１０１の属性情報を読み出し、クライアント１０１が要求したタイトルのコンテンツの圧縮形式およびビットレートとクライアント１０１の圧縮形式およびビットレートが対応するか否かを判断することができるので、クライアントの仕様に応じた柔軟なビデオオンデマンドサービスをクライアントに提供することができる。
【００２２】
次に、この発明の第２の実施形態について、図５および図６を参照して説明する。なお、図１と同一部には同符号を付して説明を省略する。
【００２３】
図５に示すビデオオンデマンドシステムは図１のシステムに加えてさらに、ビデオサーバ１００がデコーダ１１１およびエンコーダ１１２を有している。すなわち、ビデオサーバ１００は、ビデオオンデマンドシステムがサポートする各圧縮形式のデコーダ１１１、エンコーダ１１２をそれぞれ有し、各コンテンツを別の形式に再圧縮する機能を有する。この機能により、異なる圧縮形式の圧縮データを作成することができ、また、同じ圧縮形式で異なるビットレートの圧縮データを作成することができる。
【００２４】
以下、図６に示すフローチャートを参照して、図５に示すシステムの動作について説明する。
【００２５】
ステップ３０１において、クライアント１０１から配信要求があるとビデオサーバ１００は、データベース１０３から、要求したクライアントが復号可能な圧縮形式、最大受信ビットレート、および最大受信パケットサイズを抽出する。そして、ステップ３０５において、ビデオサーバ１００はクライアントが要求したタイトルのコンテンツの圧縮形式とクライアント１０１側の圧縮形式とが対応するか否か判断する。リクエストを受けたタイトルのコンテンツの圧縮形式の中に、ビデオサーバ１００が抽出した圧縮形式と合致しない場合、ビデオサーバ１００は、ステップ３０９において、要求されたタイトルのコンテンツを一旦デコーダ１１１で復号化し、次にエンコーダ１１２によりクライアント１０１が復号化可能な方式に再圧縮を行ない、ステップ３１１において、クライアント１０１へ再圧縮されたデータを送信する。このとき、ビデオサーバ１００はデータ送信と並行して、再圧縮されたデータはビデオサーバ１００のコンテンツ登録プログラムにより、リクエストされたタイトルの新たなコンテンツとして圧縮データ記憶部１０４に登録される。
【００２６】
一方、ステップ３０５において、クライアント１０１が要求したタイトルのコンテンツの圧縮形式とクライアント１０１側の圧縮形式とが対応すると判断した場合には、次に、ステップ３０７において、クライアント１０１の要求したタイトルのコンテンツのビットレートが、クライアント１０１の最大受信ビットレートと合致するか否か判断する。合致しない場合には、ビデオサーバ１００は、ステップ３０９において、上述したように、デコーダ１１１により圧縮データの復号化を行ない、次に、エンコーダ１１２により、クライアント１０１の許容範囲のビットレートに再圧縮し、この再圧縮と並行して、ステップ３１０において、再圧縮されたデータは、ビデオサーバ１００のコンテンツ登録プログラムにより、リクエストされたタイトルの新たなコンテンツとして圧縮データ部１０４に登録される。再圧縮されたデータを新たなコンテンツとして登録しておくことにより、同一クライアントまたは同一の復号化機能をもつクライアントへコンテンツの配信を行う際、事前に登録されていた圧縮データを再び圧縮する必要がなくなるので、ビデオサーバに対して再圧縮に伴う負荷が軽減される。
【００２７】
また、送信に際して、ビデオサーバ１００はデータベース１０３から抽出したクライアント１０１の最大受信パケットサイズ内に収まるように、パケットを区切って圧縮データを送信する。
【００２８】
図７は、サーバ１００からのポーリング（すなわち、仕様の変更の問い合わせ）に対して、クライアント１０１のデコーダ１１０の更新或いは追加といった仕様に変更があった場合の動作を示すフローチャートである。図７に示すように、クライアント１０１はステップ４０１において、リクエストと共に、更新（追加）フラッグ、変更のある属性、および変更後（追加する）属性値をビデオサーバ１００に通知する。なお、この更新（追加）フラッグは、クライアント１０１がデコーダ１１０等の更新（追加）に際して設定する１ビットのフラッグである。通知に際しては、例えばネットワーク１０２がEthernetで構成されている場合は、ＴＣＰ／ＩＰで通知を行うというように、信頼性のある通信方式で通知を行う。クライアント１０１からの変更通知を受けて、ビデオサーバ１００はステップ４０３において、データベース１０３内にクライアント１０１が要求した属性があるか否か判断する。無ければ、ステップ４０５において、ビデオサーバ１００は、クライアント１０１に属性を要求する。ビデオサーバ１００の要求に応答して、クライアント１０１は、ステップ４０７において、属性値をビデオサーバ１００に送出する。
【００２９】
一方、ステップ４０３において、データベース１０３内に要求したクライアントの情報がある場合、あるいは、ステップ４０７におけるクライアント１０１からの属性の送信に応答して、ビデオサーバ１００はステップ４０９において、データベースを更新する。
【００３０】
図８は、クライアント１０１がある圧縮形式に対応するデコーダを削除したときの動作を示すフローチャートである。ステップ５０１において、クライアント１０１は、ビデオサーバ１００からのポーリングに対し、変更要求を送信するとともに、更新（追加フラッグ）、変更のある属性、更新後（追加する）属性値をビデオサーバ１００に通知する。ビデオサーバ１００は、クライアント１０１からの要求に応答して、ステップ５０３において、データベース１０３内の圧縮形式の属性値から、通知を受けた圧縮形式を削除する。
【００３１】
なお、上述した実施形態では、クライアント側の仕様の更新（追加）があった場合、サーバ側からのポーリングにより、クライアント側の仕様の更新（追加）を検出するように構成したが、クライアント側からサーバ側に知らせるようにしてもよい。すなわち、図９のステップ６０１において、クライアント１０１が仕様を変更すると、ステップ６０３において、クライアント１０１がサーバ１００に対して、仕様の変更を通知する。サーバ１００はこの通知に応答して、サーバの負荷量を判断する（ステップ６０５）。サーバの負荷が高ければ、更新を行わずに更新処理を終了する。この場合、属性の更新はサーバからのポーリング又は配信要求時に行われる。一方、サーバ負荷が低ければ、ステップ６０７において、サーバ１００はデータベース１０３を更新し、ステップ６０９において、クライアント１０１側の更新（追加あるいは削除）フラッグをリセットする。
【００３２】
【発明の効果】
この発明のビデオサーバおよびビデオオンデマンドシステムによれば、以下の効果が得られる。
【００３３】
第１に、クライアントの仕様に応じた柔軟なビデオオンデマンドサービスをクライアントが受けることができる。
【００３４】
第２に、クライアントに、ビデオサーバが提供しうるすべてのサービスに対応する機能を用意する必要がなくなる。また、処理能力の劣る端末でも、サービスの品質に限定があるものの、ビデオオンデマンドシステムのクライアントとして利用することができ、機器の再利用が可能である。
【００３５】
第３に、システムの拡張に容易に対応できる。しかも、システムをアップデートする際に、クライアントの下位互換に対応できる。
【００３６】
第４に、一度圧縮された圧縮データを新たなコンテンツとして再利用することができる。再圧縮に伴うビデオサーバの負荷を最小限に抑えることができる。
【図面の簡単な説明】
【図１】この発明のクライアント主体のビデオオンデマンドシステムの第１の実施形態のシステムブロック図である。
【図２】図１に示すデータベース１０３に格納されるクライアントの属性情報の一例を示す図である。
【図３】図１に示すクライアントの圧縮形式の属性値の保存形式の例を示す図である。
【図４】図１に示す第１の実施形態の動作を示すフローチャートである。
【図５】この発明のクライアント主体のビデオオンデマンドシステムの第２の実施形態を示すシステムブロック図である。
【図６】図５に示す第２の実施形態の動作を示すフローチャートである。
【図７】クライアントが属性を変更（追加）した場合のビデオサーバ側の動作を示すフローチャートである。
【図８】クライアントが圧縮形式を削除した場合のビデオサーバ側の動作を示すフローチャートである。
【図９】クライアントがサーバに対して仕様変更を通知する場合の動作を示すフローチャートである。
【符号の説明】
１００…ビデオサーバ
１０１…クライアント
１０２…ネットワーク
１０３…データベース
１１０…デコーダ
１１１…デコーダ
１１２…エンコーダ[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a video server and a client capable of providing services according to client specifications in a video on demand system.
[0002]
[Prior art]
Conventionally, in a video-on-demand system, a fixed service that the video server has is unilaterally provided regardless of the specifications of the client.
[0003]
[Problems to be solved by the invention]
If the client does not support the services that the video server can provide, the client could not do anything even if it received data sent from the video server. Japanese Patent Laid-Open No. 8-274902 proposes a method of converting a variable bit rate into a fixed bit rate according to the client specifications, but when the client does not support other compression formats and compression parameters, There is no countermeasure.
[0004]
The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a video server capable of distributing content corresponding to client specifications in a video on demand system.
[0005]
[Means for Solving the Problems]
According to the present invention, in a video on demand system in which a plurality of clients and a video server are connected via a network, the video server registers the content in a compressed format, and distributes the content in a compressed format. And whether or not the database holding information about the client specifications matches the client specifications stored in the database in response to the delivery request from the client and the video data requested by the client And a means for transmitting the content to the client when they match.
[0006]
According to the present invention, the client can receive a flexible video-on-demand service according to the specification of the client.
[0007]
According to the present invention, in a video on demand system in which a plurality of clients and a video server are connected via a network, the video server distributes the content in a compressed format and means for registering the content in a compressed format. And a database that holds information relating to client specifications, whether the client specifications stored in the database in response to a delivery request from the client match the video data specifications requested by the client When the data matches, the means for transmitting the content to the client, the specifications of the client, and the video data requested by the client do not match, and the compressed data to be transmitted is decoded. Decoder means for
An encoder for recompressing data decoded by the decoder means into a compression format and compression parameters supported by the client, and data recompressed by the encoder are transmitted by the transmission means.
[0008]
According to the present invention, the video server side is provided with a decoder and an encoder, and the content can be recompressed so as to adapt to the specifications of the client, so that all services that can be provided by the video server are provided to the client side. There is no need to prepare corresponding functions. In addition, although a terminal with inferior processing capability has limited service quality, it can be used as a client of a video-on-demand system, and equipment can be reused.
[0009]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[0010]
FIG. 1 is a system block diagram showing a client-based video on demand system of the present invention. The system shown in FIG. 1 includes a video server 100 that registers content in a compressed format and distributes content in a compressed format, a plurality of clients 101 having a decoder 110 for received compressed data, and a plurality of video servers 100 and a plurality of video servers 100. A network 102 to which the client 101 is connected is provided. The video server 100 holds a database 103 that stores attribute values related to the specifications of the client 101. In this embodiment, the database 103 includes, as attributes, the host name of the client 101, a compression format that can be decrypted by the client 101 (a storage format will be described later), and a maximum bit rate that can be received by the client 100 related to compression parameters ( Mbps) and a maximum received packet size (byte unit) that the client 101 can receive.
[0011]
FIG. 2 shows an example of attribute information that the database 103 has. In the figure, the compression format of the host A is “011”, the maximum reception bit rate is “5”, and the maximum reception packet size is “1500”. As shown in FIG. 3, the compression format is composed of 3 bits from bit 0 to bit 2. When bit 0 is “1”, it means that the client 101 supports MPEG1, and bit 1 is “1”. In this case, it means that the client 101 supports MPEG2, and when bit 2 is “1”, it means that the client 101 supports MPEG4. Therefore, the host A supports MPEG1 and MPEG2 as compression formats, supports a maximum reception bit rate of 5 Mbps, and further supports 1500 bytes as a maximum reception packet size. Similarly, the host B supports MPEG1, MPEG2, and MPEG4 as storage formats for compression formats, supports a maximum reception bit rate of 7 Mbps, and a maximum reception packet size of 2000 bytes. Further, the host C supports only MPEG1 as a compression format storage format, supports a maximum reception bit rate of 3 Mbps, and a maximum reception packet size of 1500 bytes.
[0012]
Even when compressed data in a compressed format that is not supported by the client 101 is received, the client 101 cannot decrypt the content. If the bit rate of the compressed data exceeds the maximum reception bit rate of the client 101, frame dropping or block noise occurs, and a smooth and beautiful moving image cannot be reproduced. Furthermore, if the packet size of the transmission data exceeds the maximum reception packet size of the client, a part of the received compressed data is missed, and it becomes impossible to decode the compressed data.
[0013]
Another attribute held in the database 103 includes a network bandwidth that can be used by the client 101. With bandwidth control, the client 101 can receive a video-on-demand service without losing quality even when the network load increases. These attribute values are manually input in advance for each client 101 by the administrator of the server 100. These attribute values can be automatically updated. That is, when the client 100 is polled from the server 100 side and a change in the attribute value is detected, the corresponding attribute stored in the database 103 is changed.
[0014]
The video server 100 holds content compressed with a plurality of bit rates and a plurality of compression formats for one title. The server 100 recognizes the added or updated attribute by software (for example, by polling the client 101 from the server 100 side) when the decoder 110 is updated or added on the client 101 side. It has a function that can be.
[0015]
For example, the network 102 may be an Ethernet, ATM, or CATV network, but is not limited thereto.
[0016]
The operation of the system shown in FIG. 1 will be described below with reference to the flowchart shown in FIG.
[0017]
In step 201, when there is a delivery request from the client 101, the video server 100 sends the attribute information corresponding to the client requested from the database 103, that is, the compression format, maximum reception bit rate, maximum Read the received packet size. In step 205, it is determined whether the compression format of the content requested from the client 101 corresponds to the compression format of the requested client 101. If not, in step 209, the video server 100 notifies the client 101 that requested that the requested service cannot be provided, and cancels the request.
[0018]
On the other hand, if the compression format of the content to be distributed corresponds to the requested compression format of the client 101 in step 205, the video server 100 next includes the requested bit rate of the content of the title in step 207. The video server 100 determines whether there is anything extracted from the database 103 that falls within the range of the maximum reception bit rate of the requesting client. If it is determined that it does not fall within the range, the video server 100 notifies the client 101 of a message indicating that sufficient quality of service cannot be provided (for example, dropped frames) in step 209 as described above, and the service is provided to the user side. Encourage your decision to continue. If the user selects to continue the service, provision of the service is started in step 211. On the other hand, if the user does not select continue, the service is canceled.
[0019]
On the other hand, in step 207, if there is a bit rate of the requested title content within the range of the maximum reception bit rate of the requesting client extracted from the database 103 by the video server 100, in step 211. , Start distributing content.
[0020]
When the video server 100 transmits the compressed data, the compressed data is transmitted by dividing the packet so as to be within the maximum received packet size of the client 101 extracted from the database 103.
[0021]
As described above, according to the client-based video on demand system of the present invention, the attribute information of the client 101 is stored in the database 103 of the video server 100, and when the client 101 receives a distribution request, the attribute information of the client 101 is stored. Since the compression format and bit rate of the content of the title requested by the client 101 correspond to the compression format and bit rate of the client 101, it is possible to flexibly turn on the video according to the client specifications. Demand services can be provided to clients.
[0022]
Next, a second embodiment of the present invention will be described with reference to FIGS. The same parts as those in FIG. 1 are denoted by the same reference numerals and description thereof is omitted.
[0023]
In addition to the system shown in FIG. 1, the video server 100 further includes a decoder 111 and an encoder 112 in the video on demand system shown in FIG. In other words, the video server 100 includes a decoder 111 and an encoder 112 of each compression format supported by the video on demand system, and has a function of recompressing each content into a different format. With this function, compressed data of different compression formats can be created, and compressed data of different bit rates can be created with the same compression format.
[0024]
The operation of the system shown in FIG. 5 will be described below with reference to the flowchart shown in FIG.
[0025]
In step 301, when there is a distribution request from the client 101, the video server 100 extracts from the database 103 the compression format, maximum reception bit rate, and maximum reception packet size that can be decoded by the requested client. In step 305, the video server 100 determines whether the compression format of the content of the title requested by the client corresponds to the compression format on the client 101 side. If the compression format of the requested title content does not match the compression format extracted by the video server 100, the video server 100 once decrypts the requested title content in the decoder 111 in step 309. Next, the encoder 112 performs recompression into a method that the client 101 can decode, and in step 311, the recompressed data is transmitted to the client 101. At this time, in parallel with data transmission, the video server 100 registers the recompressed data in the compressed data storage unit 104 as new content of the requested title by the content registration program of the video server 100.
[0026]
On the other hand, if it is determined in step 305 that the compression format of the title content requested by the client 101 corresponds to the compression format on the client 101 side, then in step 307 the content of the title requested by the client 101 is determined. It is determined whether or not the bit rate matches the maximum reception bit rate of the client 101. If they do not match, the video server 100 decodes the compressed data by the decoder 111 in step 309 as described above, and then recompresses the bit rate within the allowable range of the client 101 by the encoder 112. In parallel with this recompression, in step 310, the recompressed data is registered in the compressed data unit 104 as new content of the requested title by the content registration program of the video server 100. By registering the recompressed data as new content, when distributing content to the same client or a client having the same decryption function, it is necessary to compress the previously registered compressed data again. As a result, the load accompanying recompression on the video server is reduced.
[0027]
Further, at the time of transmission, the video server 100 transmits the compressed data by dividing the packet so as to be within the maximum received packet size of the client 101 extracted from the database 103.
[0028]
FIG. 7 is a flowchart showing an operation when there is a change in the specification such as update or addition of the decoder 110 of the client 101 in response to polling from the server 100 (that is, an inquiry about a change in the specification). As shown in FIG. 7, in step 401, the client 101 notifies the video server 100 of an update (added) flag, an attribute with a change, and a changed (added) attribute value together with the request. This update (addition) flag is a 1-bit flag set by the client 101 when updating (adding) the decoder 110 or the like. When the notification is made, for example, when the network 102 is configured by Ethernet, the notification is performed by a reliable communication method such as notification by TCP / IP. In response to the change notification from the client 101, the video server 100 determines in step 403 whether or not the attribute requested by the client 101 exists in the database 103. If not, the video server 100 requests an attribute from the client 101 in step 405. In response to the request from the video server 100, the client 101 sends the attribute value to the video server 100 in step 407.
[0029]
On the other hand, in step 403, when there is information of the requested client in the database 103 or in response to the transmission of the attribute from the client 101 in step 407, the video server 100 updates the database in step 409.
[0030]
FIG. 8 is a flowchart showing an operation when the client 101 deletes a decoder corresponding to a certain compression format. In step 501, the client 101 transmits a change request in response to polling from the video server 100, and notifies the video server 100 of updated (addition flag), changed attributes, and updated (added) attribute values. . In response to the request from the client 101, the video server 100 deletes the notified compression format from the compression format attribute value in the database 103 in step 503.
[0031]
In the above-described embodiment, the configuration is such that when the client-side specification is updated (added), the client-side specification update (added) is detected by polling from the server side. You may make it notify to the server side. That is, when the client 101 changes the specification in step 601 in FIG. 9, the client 101 notifies the server 100 of the change in specification in step 603. In response to this notification, the server 100 determines the load amount of the server (step 605). If the server load is high, the update process is terminated without updating. In this case, the attribute is updated at the time of polling or distribution request from the server. On the other hand, if the server load is low, the server 100 updates the database 103 in step 607, and resets the update (addition or deletion) flag on the client 101 side in step 609.
[0032]
【The invention's effect】
According to the video server and the video on demand system of the present invention, the following effects can be obtained.
[0033]
First, the client can receive a flexible video-on-demand service according to the client specification.
[0034]
Second, it is not necessary for the client to provide functions corresponding to all services that can be provided by the video server. Even terminals with inferior processing capability can be used as a client of a video on demand system with limited service quality, and equipment can be reused.
[0035]
Third, it can easily cope with system expansion. Moreover, when the system is updated, it is possible to support backward compatibility of clients.
[0036]
Fourth, the compressed data once compressed can be reused as new content. The load on the video server accompanying recompression can be minimized.
[Brief description of the drawings]
FIG. 1 is a system block diagram of a first embodiment of a client-based video on demand system of the present invention.
FIG. 2 is a diagram illustrating an example of client attribute information stored in a database 103 illustrated in FIG. 1;
FIG. 3 is a diagram illustrating an example of a storage format of attribute values in a compression format of the client illustrated in FIG. 1;
FIG. 4 is a flowchart showing the operation of the first embodiment shown in FIG. 1;
FIG. 5 is a system block diagram showing a second embodiment of the client-based video on demand system of the present invention.
FIG. 6 is a flowchart showing an operation of the second embodiment shown in FIG. 5;
FIG. 7 is a flowchart showing an operation on the video server side when a client changes (adds) an attribute.
FIG. 8 is a flowchart showing an operation on the video server side when a client deletes a compression format.
FIG. 9 is a flowchart illustrating an operation when a client notifies a server of a specification change.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 100 ... Video server 101 ... Client 102 ... Network 103 ... Database 110 ... Decoder 111 ... Decoder 112 ... Encoder

Claims (4)

ネットワークを介して複数のクライアントとビデオサーバが接続されたビデオオンデマンドシステムにおけるビデオサーバであって、
コンテンツ、およびクライアントが復号化できる圧縮形式ならびにクライアントが受信可能な最大受信ビットレートを含むクライアントのデコーダの仕様に関する情報を記憶するデータベースと、
前記クライアントに配信するコンテンツを圧縮形式で前記データベースに登録する手段と、
前記クライアントからの配信要求に応答して、要求されたコンテンツの圧縮形式が前記クライアントが復号化できる圧縮形式に対応するか否かおよびビットレートが最大受信ビットレートの範囲内に入るか否かを前記データベースを参照して判断する手段と、
前記データベースに登録されたクライアントの仕様と前記コンテンツの仕様とが対応すると前記判断手段が判断したとき、対応するコンテンツを前記データベースから読み出し、前記クライアントに圧縮形式で配信する手段と、
前記クライアントのデコーダの仕様に変更があった場合に変更のある属性を前記配信要求とともに前記クライアントから通知される仕様変更に応答して、前記データベースに記憶されたクライアントの仕様のうち通知された変更のある属性について更新する手段と、
を有することを特徴とするビデオサーバ。 A video server in a video-on-demand system in which a plurality of clients and the video servers are connected through a network,
A database that stores information about the content and specifications of the client's decoder, including the compression format that the client can decode and the maximum received bit rate that the client can receive;
Means for registering content to be delivered to the client in the database in a compressed format;
In response to the delivery request from the client, whether the compression format of the requested content corresponds to a compression format that can be decoded by the client, and whether the bit rate falls within the range of the maximum reception bit rate. Means for judging with reference to the database ;
Means for reading the corresponding content from the database and delivering it to the client in a compressed format when the determination means determines that the specifications of the client registered in the database correspond to the specifications of the content ;
In response to a specification change notified from the client together with the distribution request when there is a change in the specification of the decoder of the client, the change notified of the client specification stored in the database Means for updating certain attributes,
A video server comprising: 前記判断手段により前記クライアントの仕様と前記コンテンツの仕様とが対応しないと判断したとき、前記クライアントに配信すべき圧縮データを復号化するデコーダと、
前記デコーダで復号化されたデータを前記クライアントがサポートする圧縮形式およびビットレートに再圧縮するエンコーダと、
を備え、
前記エンコーダにより再圧縮されたデータを前記配信する手段により配信することを特徴とする請求項１記載のビデオサーバ。A decoder that decodes compressed data to be distributed to the client when the determination unit determines that the specification of the client does not correspond to the specification of the content ;
An encoder for re-compressing the decoded data by the decoder in a compressed format and bit rate the client supports,
With
The video server according to claim 1 , wherein the data recompressed by the encoder is distributed by the means for distributing . ネットワークを介して複数のクライアントとビデオサーバが接続されたビデオオンデマンドシステムにおいて、
前記ビデオサーバは、
コンテンツ、およびクライアントが復号化できる圧縮形式ならびにクライアントが受信可能な最大受信ビットレートを含むクライアントのデコーダの仕様に関する情報を記憶するデータベースと、
前記クライアントに配信するコンテンツを圧縮形式で前記データベースに登録する手段と、
前記クライアントからの配信要求に応答して、要求されたコンテンツの圧縮形式が前記クライアントが復号化できる圧縮形式に対応するか否かおよび前記コンテンツのビットレートが前記クライアントが受信可能な最大受信ビットレートの範囲内に入るか否かを前記データベースを参照して判断する手段と、
前記データベースに登録されたクライアントの仕様と前記コンテンツの仕様とが対応すると前記判断手段が判断したとき、対応するコンテンツを前記データベースから読み出し、前記クライアントに圧縮形式で配信する手段と、
前記クライアントのデコーダの仕様に変更があった場合に変更のある属性を前記配信要求とともに前記クライアントから通知される仕様変更に応答して、前記データベースに記憶されたクライアントの仕様のうち通知された変更のある属性について更新する手段とを有し、
前記クライアントは、
前記ビデオサーバから配信された圧縮されたコンテンツを復号化するデコーダと、
前記コンテンツの配信要求時に、前記クライアントのデコーダの仕様に変更があった場合に変更のある属性について前記デコーダの仕様変更を前記ビデオサーバに前記配信要求 とともに通知する手段とを有することを特徴とするビデオオンデマンドシステム。In a video-on-demand system in which multiple clients and video servers are connected via a network,
The video server is
A database that stores information about the content and specifications of the client's decoder, including the compression format that the client can decode and the maximum received bit rate that the client can receive;
Means for registering content to be delivered to the client in the database in a compressed format;
In response to a delivery request from the client, whether or not the requested content compression format corresponds to a compression format that can be decoded by the client, and the bit rate of the content is the maximum reception bit rate that the client can receive Means for referring to the database to determine whether it falls within the range of
Means for reading the corresponding content from the database and delivering it to the client in a compressed format when the determination means determines that the specifications of the client registered in the database correspond to the specifications of the content ;
In response to a specification change notified from the client together with the distribution request when there is a change in the specification of the decoder of the client, the change notified of the client specification stored in the database Means for updating a certain attribute ,
The client
A decoder for decoding the compressed content distributed from the video server;
And a means for notifying the video server together with the distribution request of a change in the specifications of the decoder when there is a change in the specifications of the client decoder when the content distribution request is made. Video on demand system . 前記ビデオサーバは、前記クライアントからの仕様変更通知に応答して、前記クライアントが前記データベースに登録されているか否か判断し、登録されていると判断したとき、前記クライアントに対して、変更された仕様の属性値の送信を要求し、登録されていないと判断したとき、前記クライアントに対して仕様に関するすべての属性の送信を要求し、前記データベースを更新することを特徴とする請求項３に記載のビデオオンデマンドシステム。In response to the specification change notification from the client, the video server determines whether or not the client is registered in the database. When the video server determines that the client is registered, the video server has changed the client. requesting transmission of the attribute value specifications, when it is determined not to be registered, according to claim 3, requesting the transmission of all the attributes of the specification to the client, and updates the database Video on demand system.
JP16974399A 1999-06-16 1999-06-16 Video server and video on demand system Expired - Fee Related JP3999410B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP16974399A JP3999410B2 (en) 1999-06-16 1999-06-16 Video server and video on demand system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP16974399A JP3999410B2 (en) 1999-06-16 1999-06-16 Video server and video on demand system

Publications (2)

Publication Number Publication Date
JP2000358230A JP2000358230A (en) 2000-12-26
JP3999410B2 true JP3999410B2 (en) 2007-10-31

Family

ID=15892035

Family Applications (1)

Application Number Title Priority Date Filing Date
JP16974399A Expired - Fee Related JP3999410B2 (en) 1999-06-16 1999-06-16 Video server and video on demand system

Country Status (1)

Country Link
JP (1) JP3999410B2 (en)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3918447B2 (en) * 2001-03-30 2007-05-23 三菱電機株式会社 Moving image receiving apparatus and moving image transmitting apparatus
JP3871201B2 (en) 2002-01-29 2007-01-24 ソニー株式会社 Content provision acquisition system
US20040098463A1 (en) * 2002-11-19 2004-05-20 Bo Shen Transcoding-enabled caching proxy and method thereof
JP2004221836A (en) 2003-01-14 2004-08-05 Ricoh Co Ltd Image processor, program, storage medium, and code expanding method
JP4585479B2 (en) * 2006-03-30 2010-11-24 株式会社東芝 Server apparatus and video distribution method
JP5941270B2 (en) * 2010-12-17 2016-06-29 キヤノン株式会社 Information processing apparatus and information processing method
KR20120105688A (en) * 2011-03-16 2012-09-26 정민재 System and method for virtualization service between server/client terminal of heterogeneous computing types
US9571433B2 (en) 2011-09-12 2017-02-14 Panasonic Intellectual Property Management Co., Ltd. Communication device, relay server for relaying data from communication device, and communication system including them
CN114401445B (en) * 2021-12-31 2024-03-22 深圳云天励飞技术股份有限公司 Video processing control method, device, monitoring equipment, client and storage medium

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06326856A (en) * 1993-05-17 1994-11-25 Hitachi Ltd Data recorder and its method
JP3588679B2 (en) * 1994-03-17 2004-11-17 富士通株式会社 Information provision device
JPH08274902A (en) * 1995-04-04 1996-10-18 Sony Corp Data server system, terminal equipment and data transmission method
JP3609488B2 (en) * 1995-05-17 2005-01-12 株式会社日立製作所 Information processing system
JPH09298749A (en) * 1996-05-08 1997-11-18 Hitachi Ltd Moving image distributing method and executing device for the same
JP2982698B2 (en) * 1996-07-08 1999-11-29 日本電気株式会社 Distributed information service system
JP3435295B2 (en) * 1996-09-30 2003-08-11 株式会社東芝 Information transmitting device and traffic control device, band operation method and call accepting method using the same
JPH11355756A (en) * 1998-06-04 1999-12-24 Oki Electric Ind Co Ltd Storage and distribution method for moving image data

Also Published As

Publication number Publication date
JP2000358230A (en) 2000-12-26

Similar Documents

Publication Publication Date Title
US20200351250A1 (en) Providing Load Balanced Secure Media Content and Data Delivery in a Distributed Computing Environment
US7275095B1 (en) Internet subscriber management
US9369330B2 (en) Service gateway for interactive television
US9015477B2 (en) System and method for secure asynchronous event notification for adaptive streaming based on ISO base media file format
EP1623341B1 (en) Methods, data structures, and systems for processing media data streams
EP2618534B1 (en) Method, apparatus, and system for dynamic media content insertion based on http stream
JP5224426B2 (en) Transmission method and gateway
US20120060178A1 (en) Continuable communication management apparatus and continuable communication managing method
US20090254960A1 (en) Method for a clustered centralized streaming system
JP2002500853A (en) System and method for multicasting multimedia content
KR20030081430A (en) Multimedia messaging method and system
JP2006510310A (en) Method and system for multimedia message processing service
JP2003503957A (en) Method and apparatus for use with email
JP3999410B2 (en) Video server and video on demand system
JP2001204001A (en) Moving picture distribution system, reproduction terminal and distributor
GB2324003A (en) Information Delivery System Using Satellite Communication
KR102482207B1 (en) A method and apparatus for supporting service change for digital broadcast systems
CN101389017B (en) Method for storing media file in mobile stream media live service
JP2003274382A (en) Video information streaming distribution system, computer, program, and video information streaming distributing method
US7539292B2 (en) Contents distribution system, contents server, contents receiving apparatus, contents distribution method, program and storage media
US7599962B2 (en) Content delivery system, content server, content receiver, content delivery method, storage medium and program
US8977763B1 (en) Systems and methods for distributing streams and stream metadata
WO2024187803A1 (en) Resource allocation method and related apparatus
JP4552348B2 (en) Communications system

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20050317

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20070417

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070424

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070528

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20070807

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20070809

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20100817

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees