WO1998038798A1

WO1998038798A1 - Device, system, and method for distributing video data

Info

Publication number: WO1998038798A1
Application number: PCT/JP1997/000562
Authority: WO
Inventors: Tomohisa Yamaguchi
Original assignee: Mitsubishi Denki Kabushiki Kaisha
Priority date: 1997-02-26
Filing date: 1997-02-26
Publication date: 1998-09-03
Also published as: EP0901285A4; EP0901285A1; JP3393143B2

Description

明細書ビデオデータ配信装置、ビデオデータ配信システム、並びに、そのビデォデータ配信方法。技術分野

この発明は、要求に応じてビデオデータを配信するビデオデータ配信装置、ビデオデータ配信システム、並びに、そのビデオデータ配信方法に関するものである。背景技術

第 33図を用いて背景技術を説明する。第 33図はネットワークを通して、 MPEG 等の高ビットレ一トのビデオデータをビデオサーバからクライアントへ配信するためのシステム構成を示す機能プロック図である。第 33 図において 1 はビデオデータ配信専用のネットワーク、 2 は専用ネットワーク 1 に接続され、ビデオデータを配信するビデオサーバ、 3 は専用ネットワーク 1 に接続され、ビデオサーバ 2から配信されてきたビデオデータを受け取り、その再生を行うクライアントである。

次に動作について説明する。

ビデオサーバ 2はクライアント 3からのデータ転送要求を受け取ると、専用ネットワーク 1 に要求されたビデオデータを流しはじめる。専用ネットワーク 1を通して配信されてきたビデオデータをクライアント 3が受け取り、デコードし、ビデオの再生を行う。

第 33図のような構成のシステムではネットワークにビデオ配信専用のネットヮ一クを使用しているので、ネットヮ一クのバンド幅が十分であればほぼフレーム落ち無しでビデオの再生を行えるが、クライアント 3 の数が増加し、配信するビデオデータの量が増加した結果、ネットヮーク負荷等が増大した場合に、ビデオデータを送信できないために長時間に渡ってフレーム落ちが発生する。

また、通常のネットワークのようなバンド幅が十分ではないビデオ配信専用ネットワーク以外のネットワーク上で MPEG のような高転送レートのビデオを利用すると、ネットワーク負荷が増大し、安定したビデオ配信が行われないばかり力、ネットワーク上の他のトラフィックにも悪影響を及ぼす場合がある。発明の開示

本発明は以上のような問題を解決するためになされたものであり、ビデォデータの配信にかかるネットワーク負荷を軽減し、ネットワークに接続されたシステム全体の安定化を図るとともに、再生時の乱れが少ないリアルタイムな表示が行えるビデオデータ配信装置、ビデオデータ配信システム、並びに、そのビデオデータ配信方法を得ることを目的とする。

この目的を達成するため、ネットワーク又はビデオデータ配信装置の負荷状態を測定する負荷測定部と、複数のフレームデータを含むビデオデータから、上記負荷測定部の測定結果に応じた数のフレームデータを抽出するデータ抽出部と、このデータ抽出部が抽出したフレームデータを送信する送信部と、を備えることとした。

また、データ抽出部は、負荷測定部の測定結果に基づいて、負荷が低いときにはビデオデータの全てのフレームデータを抽出し、負荷が高いときには、上記ビデオデータの一部のフレームデータを抽出することとした。

また、データ抽出部は、ビデオデータ内の複数のフレームデータ間のフレームデータを間引くことによって、負荷測定部の測定結果に基づいた数のフレームデータを抽出することとした。

また、データ抽出部は、フレーム内圧縮フレームのデータ及びフレーム間圧縮フレームのデータを有するビデオデータから、負荷測定部の測定結果に基づいて、フレーム間圧縮フレームのデータを削除したビデオデータを抽出し、送信部は、データ抽出部が抽出したビデオデータを送信することとした。

また、ビデオデータは、 MPEGデータであることとした。

また、データ抽出部は、 Iピクチャ及び Pピクチャを有する MPEGデータから、負荷測定部の測定結果に応じて、 Pピクチャを削除した MPEGデータを生成することとした。

また、データ抽出部は、 Iピクチャ及び Bピクチャを有する MPEGデ一タから、負荷測定部の測定結果に応じて、 Bピクチャを削除した MPEGデータを生成することとした。

また、データ抽出部は、 Iピクチャ、 Pピクチャ及び Bピクチャを有する MPEGデータから、負荷測定部の測定結果に応じて、 Pピクチャ及び B ピクチャを削除した MPEGデータを生成することとした。

また、データ抽出部は、複数の I ピクチャを有する MPEGデータから、負荷測定部の測定結果に応じた間隔で複数の I ピクチャを抽出することとした。

また、ビデオカメラからの映像信号をリアルタイムにェンコ一ドし、複数のフレームデータを有するビデオデータを生成するエンコーダと、このエンコーダが生成したビデオデ一タをー時的に記憶するバッファと、を備え、データ抽出部は、上記バッファに記憶されたビデオデータ内の複数のフレームデータ間のフレームデータを間引くことによって、上記ビデオデータから負荷測定部の測定結果に基づいた数のフレームデータを抽出することとした。

また、— ビデオデータ配信システムの負荷状態を測定する負荷測定部、複数のフレームデータを含むビデオデータから、上記負荷測定部の測定結果に応じた数のフレームデータを抽出するデータ抽出部と、このデータ抽出部が抽出したフレームデータをネットワークを介して送信する送信部と、を備えたビデオデータ配信装置、上記ネットワークから上記ビデォデータ配信装置の送信部から送信されたフレームデータを受信するとともに、受信したフレームデータを再生するビデオデータ再生装置、を備えることとした。

また、負荷測定部は、ビデオデータ再生装置の動作を制御するプロセッサの負荷を測定することとした。

また、複数のビデオデータ再生装置がネットワークに接続され、ビデォデータ配信装置の送信部から上記ネットワーク上に送信された 1つのフレームデータは、上記複数のビデオデータ再生装置それぞれにおいて受信されることとした。

また、ビデオデータ再生装置は、それぞれデータ量が指定されたデ一タ転送要求を複数回ビデオデータ配信装置へ送信し、ビデオデータ配信装置は、上記複数回のデータ転送要求を受信すると、これらのデータ転送要求それぞれに指定されたデータ量に基づいたフレームデータを、上記データ転送要求ごとに送信することとした。

また、ビデオデータ再生装置は、ビデオデータが指定されたデータ転送要求を送信し、ビデオデータ配信装置は、上記のデータ転送要求を受信すると、上記ビデオデータの一部のフレームデータを有するバケツトを所定の間隔で複数送信することこととした。

また、ビデオデータ配信システムの負荷に応じた送信レベルを決定する送信レベル決定ステップと、複数のフレームデータを含むビデオデータから、上記送信レベル決定ステップにおいて決定された送信レベルに応じた数のフレームデータを抽出するデータ抽出ステップと、上記デ一タ抽出ステップにおいて抽出されたフレームデータを送信する送信ステップと、を備えることとした。

また、送信レベル決定ステップは、ビデオデータ再生装置で実行され、ビデオデータ再生装置の動作を制御するプロセッサの負荷を測定する負荷測定ステップと、この負荷測定ステップの測定結果に対応した送信レベルを決定する決定ステップと、この決定ステップによって決定した送信レベルをビデオデータ再生装置からビデオデータ配信装置へ送信する送信レベル送信ステップと、を備えることとした。

また、ビデオデータ再生装置が、送信ステップによって送信されたフレームデータを受信し、受信したフレームデータを再生する再生ステツプを備えることとした。

また、送信レベル決定ステップは、ビデオデータ再生装置がビデオデータを早送り再生する場合には、ビデオデ一タに含まれる複数のフレームデータから一部のフレームデータを間引いたビデオデータが抽出されるように送信レベルを決定し、早送り再生しない場合には、ビデオデータのフレームデ一タを間引かないように送信レベルを決定することとした。

また、データ抽出ステップは、ビデオデータ再生装置が複数のフレームデータ及び音声データを含むビデオデータを早送り再生する場合には- ビデオデータから上記音声データを削除し、送信レベルに応じた数のフレームデータを抽出したビデオデータを生成し、送信ステップは、上記データ抽出ステップが生成したビデオデータを送信することとした。図面の簡単な説明第 1図は、本発明の実施例 1、 2、 4にかかるクライアント 'サーバシステムのシステム構成図である。

第 2図は、本発明の実施例 1、 3、 4にかかる LBRデータ配信ノ再生部分のソフトウユア構成図である。

第 3図は、本発明のクライアント主導型の動作を示すシーケンス図である。

第 4図は、本発明の実施例 1にかかるクライアントプログラムの処理を説明するフローチヤ一トである。

第 5図は、本発明の実施例 1にかかる OPEN要求のデータ構造示す図である。

第 6図は、本発明の実施例 1にかかる READ要求のデータ構造示す図である。

第 7図は、本発明の実施例 1にかかる CPU負荷測定処理を説明するフロ一チヤ一トである

第 8図は、本発明の実施例 1にかかるネットワーク負荷測定処理を説明するフロ一チヤ一トである。

第 9図は、本発明の実施例 1にかかるオフセットの調整処理を説明する図である。

第 10図は、本発明の実施例 1にかかるビデオサーバの MPEGデータ配信処理を説明するフローチャートである。

第 11図は、本発明の実施例 1 にかかる LBR処理を説明するフローチヤ —トである。

第 12図は、本発明の実施例 1 にかかるピクチャチェック処理を説明するフロ一チヤ一トである。

第 13図は、本発明の実施例 1にかかる I ピクチャチェック処理を説明するフロ一チヤ一トである。第 14図は、本発明の実施例 1にかかる IPピクチャチェック処理を説明するフローチヤ一トである。

第 15図は、本発明の実施例 1 にかかる IPBピクチャチェック処理を説明するフローチヤ一トである。

第 16図は、本発明の実施例 1にかかる間引き間隔と見つかったピクチャを取り出すか否かの判断とを説明する表を示す図である。

第 17図は、 MPEG1システムのデータ構造を示す図である。

第 18図は、 MPEG1システムの G0P層までのデータ構造を示す図である。第 19図は、本発明の実施例 1 にかかるビデオ配信処理のシーケンス図である。

第 20図は、本発明の実施例 1にかかるビデオ配信処理のシーケンス図である。

第 21図は、本発明の実施例 2にかかる LBRデータ配信 Z再生部分のソフトウエア構成図である。

第 22図は、本発明のサーバ主導型の動作を示すシーケンス図である。第 23図は、本発明の実施例 2にかかるクライアントプログラムの処理を説明するフローチヤ一トである。

第 24図は、本発明の実施例 2にかかるビデオサーバの配信処理を説明するフローチヤ一トである。

第 25図は、本発明の実施例 3にかかるクライアント ' サーバシステムのシステム構成図である。

第 26図は、本発明の実施例 3にかかるビデオ配信処理のシーケンス図である。

第 27図は、本発明の実施例 3にかかるサーバプログラムの処理を説明するフローチャートである。

第 28図は、本発明の実施例 3にかかるクライアントプログラムの処理を説明するフローチャートである。

第 290は、本発明の実施例 4にかかるサーバプログラムの処理を説明するフローチヤ一トである。

第 30図は、本発明の実施例 4にかかるクライアントプログラムの処理を説明するフローチャートである。

第 31図は、本発明にかかるビデオサーバの機能プロック図である。第 32図は、本発明にかかる LBR処理を説明する機能プロック図である。第 33図は、背景技術にかかるビデオサーバのシステム構成図である。発明を実施するための最良の形態

第 1図に本発明におけるクライアント.サーバシステムのシステム構成の実施例を示す。以下に説明する実施例ではビデオデータとして MPEG データを使用している。

第 1図において、 4はビデオデータ以外のデータも流れている通常のネットヮ一ク、 5はネットワーク 4を通して MPEGデ一タを配信するビデオサーバであり、例えば、ネットワークサーバの機能を有する周知の OS が実装されたコンピュータを用いる。 6は MPEGデータを格納しておくためのディスク装置、 7はディスク装置 6から MPEGデータを読み込むためのサ一バ用バッファである。 8はサ一バ用バッファ 7に読み込まれた MPEG データを LBR化したデータ（以下 LBRデータ； Low Bi t Rat e) に変更する際に、この LBRデータを書き出すために使用される LBR用バッファ、 9 は配信されてきた LBRデータを受け取り、その再生を行うクライアントであり、例えば、ネットワーク機能を有するマイクロソフト社の 0S、 Windows95が実装されたコンピュータを用いる。クライアント 9はビデォデ一タ再生以外のアプリケーションも同時実行可能である。 10はビデォサーバ 5から配信されてきた MPEGデータを一時的に格納しておくためのクライアント用バッファである。

第 31図は、ビデオサーバ 5の機能を説明するための機能プロック図である。第 31図において、第 1図と同一の符号は同一又は相当の部分を表している。 18はネットワーク 4の負荷を測定するネットワーク負荷測定部、 19はビデオサーバ 5の CPUの負荷を測定する CPU負荷測定部である。ビデォサーバ 5の CPUは、ビデオサーバ 5の動作を制御するためのプロセッサである。 91は、ネットワーク負荷測定部 18、若しくは CPU負荷測定部 19 が測定した負荷情報に基づいて、ディスク装置 6 から受け取った MPEGデータ D1を、送信部 92又は LBR処理部 12へ選択的に出力する切替部である。 12はディスク装置 6から切替部 91を介して受け取った MPEG データ D 1のデータ量を減少させる処理を行う LBR処理部である。 92は、切替部 91カゝら受けとつた MPEGデータのフルデータ、又は、 LBR処理部 12から受け取ったデータ量の少ない MPEGデータ（LBRデータ）を、ネットワーク 4上に送信する送信部である。 LBR処理の詳細については後述する。

ここで、クライアント 9はビデオ再生装置である。ネットワーク負荷測定部 18、若しくは CPU負荷測定部 19は、負荷測定部である。 LBR処理部 12は、データ抽出部である。

次に、第 31図に基づいて、ビデオサーバ 5の動作を説明する。

ネットワーク負荷測定部 18は、ネットワーク 4の負荷を常に監視する。また、 CPU負荷測定部 19も CPUの負荷を常に監視している。ビデオサーノく 5は、クライアント 9からのデータ転送要求があると、ディスク装置 6 から MPEGデータのフルデータ D 1 を読み込む。切替部 91 は、この MPEG データのフルデータ D 1を受け取り、ネットワーク負荷測定部 18及び CPU 負荷測定部 19からそれぞれ受け取った負荷情報に基づき、送信部 92、又は、 LBR処理部 12を選択してフルデータ D1 を出力する。ここで、フルデ一タとは、 LBR処理を行っていないビデオデータをいう。

例えば、ネットワーク 4 の負荷、及び、 CPU の負荷が低い場合には、切替部 91は、送信部 92を選択してフルデータ D2を出力する。このフルデータ D2は、フルデータ D 1 と同じものである。

一方、ネットワーク 4の負荷、又は、 CPUの負荷が高い場合には、 LBR 処理部 12を選択して、 MPEGデータのフルデータ D1を出力する。負荷が高い/低いという判定は、予め定められたしきい値を基準に行われる。このフルデータ D1 を受け取った LBR処理部 12は、 LBR処理を行い、フルデータ D 1から、例えば Pピクチャ、 Bピクチャを削除し、 I ピクチャを抽出することによって LBRデータ D3を作成し、 MPEGデータのデータ量を減らす。そして、 LBR処理部 12によってデータ量を減らされた LBR データ D3は、送信部 92へ出力される。 I ピクチャ、 Bピクチャ、 Pピクチヤは、それぞれ 1 フレームの画像データ、すなわちフレームデータである。各ピクチャの詳細については後述する。

切替部 91又は LBR処理部 12から、フルデータ D2又は LBRデータ D3 を受け取った送信部 92は、受け取った MPEGデータ D2，D3をネットヮ一ク 4上へ送信する。ネットワーク 4へ送信された MPEGデータ D2，D3は、クライアント 9 に受信され、クライアント 9が受け取った MPEGデータ D2, D3を再生する。

上述の説明では、 Bピクチャ、 Pピクチャを間引く実施例を説明したが、第 32図に示されるように、 LBR処理部 12は、複数の I ピクチャによって構成されるフルデータ D 1から、各 Iピクチャの間の I ピクチャを間引くことによって、 LBRデータ D3を抽出することもできる。

以上のように、この発明の実施例によれば、ネットワーク 4の負荷、 CPUの負荷等のシステムの負荷に応じて、ネットワーク 4上に送信する MPEGデータの量を調整するため、クライアント 9で再生されるビデオが長時間にわたって更新されないという現象を抑制し、リアルタイムな再生を行うことができる。

また、ビデオデータ以外のトラフィックの送受信が行われるネットヮークにおいても、ビデオデータがネットワークを長時間占有するために、その他のトラフィックの送信が長時間にわたって待ち状態にとなることを防止し、ネットワーク等の負荷に応じてビデオデータの送信量を減少させるため、他の重要なトラフィックを送信することができる。

実施例 1.

次に、本発明にかかる実施例 1 のビデオサーバ 5及びクライアント 9 を詳細に説明する。システム全体のハードウェア構成は、第 1図に示した通りである。

第 2図はビデオサーバ 5およびクライアント 9の MPEGデ一タ、 LBRデータの配信 Z再生部分のソフトウェア構成を示したものである。第 2図において、第 1図と同一の符号は同一又は相当の部分を表す。 1 1は MPEG/LBR データを配信するためのサーバプログラム、 12は MPEGデータを LBR化するための LBR処理部である。 13 はビデオサーバ 5 から送られてくる MPEG/LBRデータの処理を行うクライアントプログラム、 14は周知の技術である MPEGデータ再生アプリケーシヨン、 18はネットワーク 4の負荷を測定するネットワーク負荷測定部、 19はクライアントの CPUの負荷を測定する CPU負荷測定部である。クライアントの CPUは、クライアント 9 の動作を制御するためのプロセッサである。

本実施例のビデオデータ配信システムは、クライアント 9からのデータ転送要求に従って、ビデオサーバ 5で LBRデータをリアルタイムに生成し配信する、クライアント主導型で動作する。クライアント主導型とは第 3 図にあるように、クライアント 9からのデータ転送要求に従って、ビデオサーバ 5が要求されたビデオデータの転送を行うものである。クライアント 9はネットヮ一ク 4の負荷、クライアント 9自身の負荷、 LBRや特殊再生要求などによって転送サイズ、オフセット、転送モード（MPEGデータ要求または LBRデータ要求）等を決定し、ビデオサーバ 5にビデオデータを要求する。

なおクライアント主導型から実施例 2記載のサーバ主導型に切り替えることも可能である。

本実施例のシステムは以上のような構成であり、以下 LBRデータ配信/ 再生を第 10図〜第 15図に示したサーバプログラム、第 4図、第 7図、及び第 8図に示したクライアントプログラムの処理フロ一チヤ一ト、並びに第 19図、及び第 20図のクライアントーサーバ間のプロトコルに基づき、その動作を以下に詳細に説明する。

1.クライアントプログラムの動作

1. 1 初期化処理

まず、第 4図のステップ S 101で、クライアントプログラム 13は起動直後にサーバプログラム 1 1に対しサーバ確認要求として、 MOUNT リクエストを送る（第 19図ステップ S241)。これはサーバが起動されているかどうかを確認するために行うものである。サーバから REPLYが返ってこない場合には、サーバ起動されていないとして、エラーメッセージを出力して、動作を終了する。返ってきた場合には、ステップ S 103に進む。次にクライアントプログラム 13はネットワーク負荷と CPU負荷の測定処理を行う（ステップ S 103、ステップ S 104)。これらの処理を一定間隔で行うように別プロセスまたは別スレッドとして実行する。第 7図、第 8図を用いてこれらの処理は後述する。

次に、 MPEGデータ再生アプリケ一ション 14から各種の要求が送られてくるのを待つ（ステップ S 105)。

MPEGデータ再生アプリケーション 14から要求を受け取ったクライアントプログラム 13は、受け取った要求がデータ転送要求か、否かを判断し（ステップ S 106)、データ転送要求の場合には、ステップ S 1 10に進み、デ一タ転送要求ではない場合には、ステップ S 107へ進む。

1. 2 データ転送要求以外の要求に対する処理

ステップ S107カゝらステップ S 109は、 MPEGデータ再生アプリケーション 14から受け取った要求をサーバへ送信し（ステップ S107)、 REPLYが返つてくるのを待ち（ステップ S108)、返ってきた REPLYを MPEGデータ再生アプリケーシヨン 14へ送信する（ステップ S 109)処理であり、ステツプ S 109が終了すると、ステップ S 105へ戻って、再び要求を待つ。ここで、ステップ S 107で送信される要求の一つとしては、 OPEN要求がある（第 19図ステップ S243)。 MPEGデータ再生アプリケーシヨン 14は、データ転送要求を行う前に、データ転送の対象となるファイルを指定する上述の OPEN要求を送信する。

第 5図、第 6図に例としてサーバプログラム 1 1に渡す OPEN, READ要求のデータ構造を示す。 OPEN要求には、 MPEG再生アプリケーション 14が指定した、 LBRモード、すなわちフルデータを転送するか、 LBR化したデータを転送するかを示すデータ（間引き間隔）が含まれているという特徴力 ^sある。

1. 3 データ転送要求に対する処理

—方、 MPEGデータ再生アプリケーション 14からの要求がデータ転送要求であった場合には、ステップ S 103、ステップ S 104で得られたネットワーク負荷、 CPU負荷より各ピクチャの間引き間隔を決定する（ステツプ S110)。このステップ S 1 10は、決定ステップである。間引き間隔は送信レベルである。ここで、各ピクチャの間引き間隔を決定するとは、例えば、

( l) IPB全てのデータを送信する。 (2) IPのみのデータを送信する。

(3) 1のみのデータを送信する。

(4) 1のみのデータの一部を所定間隔で抽出したデータを送信する。

の送信方法の中から、 1つの送信方法を選択する処理であって、（1)は負荷が軽いときに選択され、（2)は次に、（3)はまたその次に、負荷が軽いとき、（4)は負荷が最も重いときに選択される。ここで、 P、 B についても所定の間隔でデータを抽出するように指定することもできる。従って、間引き間隔は、例えば、どのピクチャを抽出するかというピクチャ指定データと、ピクチャ指定データに指定されたピクチャのそれぞれについて、抽出する間隔を指定する間隔指定データとによって構成することができる。上述（1)〜（4)のいずれの処理を実行するかは、予め定められたしきい値を基準に判定される。

次に間引き間隔に変更があつたか否かが判断され（ステップ S 1 11 )、変更があった場合には次のステップ S112へ進む。変更がない場合には、ステツプ S114へ進んで、ビデオサーバ 5へデータ転送要求を送信する。

1. 4 変更要求送信処理

変更がある場合には、クライアント 9はビデオサーバ 5に対して変更要求を送信する。この変更要求送信処理は、送信レベル送信ステップである。変更要求には、変更要求命令を示す識別子及び上述ステップ S1 10 で説明した（1)〜（4)を示す識別子が含まれる。

サーバプログラム 11は、この変更要求を受け取ると、変更要求に指定されたモードに従って内部に記憶した転送モードのフラグを書き換え、

REPLYを返す。

ビデオサーバ 5から REPLYを受け取ると（ステップ S 113)、クライアントプログラム 13は、ステップ S114へ進みデータ転送要求の処理に移る。 1. 5 データ転送要求処理クライアントプログラム 13は、 MPEGデータ再生アプリケーション 14 から要求されたサイズを指定して、ビデオサーバ 5へデータ転送要求を送信する（ステップ S1 14、第 19図ステップ S245)。次に、ビデオサーバ 5 からデータが送信されるのを待ち（ステップ S 1 15)、データを受信する (第 19図ステップ S248)と、クライアント用バッファ 10 に受信したデータを格納し（ステップ S 1 16)、受信したデータについてオフセットの計算を行う。このオフセットの計算は、ビデオサーバ 5から送信されるデータは、 LBR化されている場合があり、ステップ S 1 14で要求したデータサィズと異なることがあるため、ステップ S1 14〜S1 17の処理の繰り返しによってクライアント用バッファ 10 に格納された総データ量からオフセットを計算する処理である。

続いて、ビデオサーバ 5から受け取ったデータが MPEGデータ再生ァプリケ一ション 14 が要求したサイズに達したか否かを判断し（ステップ

51 18)、達していない場合には、ステップ S 1 14へ戻り再びデータ転送要求を送信する。達している場合には、クライアント用バッファ 10に格納したデータを MPEG データ再生ァプリケ一シヨン 14 へ渡す（ステップ

51 19)。具体的には、ステップ S 1 17で計算したオフセットに基づいて判断される。

ステップ S 119が終了すると、ステップ S105へ戻り、再び MPEGデータ再生アプリケーシヨン 14からの要求を待つ処理を繰り返す。

クライアントプログラム 13の動作は以上である。

1. 6 CPU負荷測定処理

次に、第 7図を用いて、負荷測定ステップたる CPU負荷測定処理の一例について説明する。 CPU 負荷測定処理では、まず現在の時刻（T 1 ) を測定し記憶しておく（ステップ S 121)。次にプライオリティの低い処理を実行し（ステップ S 122)、この処理にかかった時間、すなわちプライオリティが低い処理が実際に CPUを使用した時間（T2) を測定し、記憶する（ステツプ S_123)。次にもう一度現在の時刻（T3)を測定する（ステップ S124)。これらの時刻情報から CPU 使用率を以下のようにして求める（ステップ S125)。

CPU使用率（°/。） =100- (T2/ (T3-T1) X 100)

この CPU使用率が高いほど、 CPU負荷が高いことになり、 CPU使用率が低レ、ほど、 CPU負荷が低いことになる。

1.7 ネットワーク負荷測定処理

次に、第 8図を用いて、負荷測定ステップたるネットワーク負荷測定処理の一例を説明する。ネットワーク負荷測定処理では、まず現在の時刻 (T1) を測定し記憶しておく（ステップ S131)。次にビデオサーバ 5で使用していないポートに対して一定サイズ（例えば 8 K B) のデータを送り（ステップ S132)、これに費やされた時間（T2) を測定し、記憶しておく（ステップ S133)。次にもう一度現在の時刻（T3) を測定する（ステツプ S134)。これらの時刻情報からネットワーク負荷を図るための指標を以下のようにして求める（ステップ S134)_c

ネットワーク負荷 =

( (転送したデータサイズ） Z (T2-T1) )Zネットワークの帯域） 1.8 オフセットの調整処理

第 9図を用いてオフセットの調整処理の説明を行う。なお、説明の簡単化のため、 LBRモードは、 LBR処理を行う（0N)、 LBR処理を行わない（OFF) の 2種類とし、 ONのときのピクチャ指定データ及び間隔指定データは固定値とする。この例では時間 TOで LBRモード OFFで始めて、時間 T2で LBRモード 0N、さらに時間 T5で LBRモード OFFにしている。また説明の簡素化のため LBRデータの量がもととなる MPEGデータ（フルデータ）の量の半分になるとしている。まず MPEGデータアプリケーション 14が時間 T0、オフセット 0、サイズ 10でデータ要求を出す。この要求がクライアントプログラム 13→サ —バプログラム 11→クライアントプログラム 13を経てサイズ 10のデ一タが送られてくる。次に MPEGビデオ再生アプリケーシヨン 14が時間 Tl、オフセット 10、サイズ 10でデータ要求を出す。先ほどと同じようにサィズ 10のデータが送られてくる。

次に MPEGデ一タ再生アプリケーシヨン 14が時間 T2で LBRモード ON 要求を行い、オフセット 20、サイズ 10でデータ要求を行う。クライアントプログラム 13は LBRモ一ド ON要求をサーバプログラム 1 1に送るとともに、オフセット 20、サイズ 10でデータ要求を行う。サ一バプログラム 1 1はオフセット 20、サイズ 10のデータを取り出し LBR化を行い、サイズ 5の LBRデータに変換し、これをクライアントプログラム 13に送る。

クライアントプログラム 13はサーバプログラム 1 1から送られてきた LBRデータのサイズと MPEGデータ再生アブリケーシヨン 14からの要求サイズを比較し、送られてきたデータサイズでは MPEGデータ再生アプリケ一シヨン 14 からの要求サイズを満たさないので、サーバプログラム 1 1に対してオフセット 30、サイズ 10でデータ要求を行う。先ほどと同様にサーバプログラム 1 1は LBRデータをクライアントプログラム 13に送る。

クライアントプログラム 13 はすでに送られてきているデータサイズと今送られてきたデータサイズを合わせ、 MPEGデータ再生アブリケーシヨン 14からの要求サイズと比較する。今度は MPEGデータ再生アプリケ —シヨン 14からの要求サイズを満たしているので、 MPEGデータ再生ァプリケーション 14にサーバプログラム 1 1から送られてきたデータを送る。クライアントプログラム 13は MPEGデータ再生アプリケーション 14からのオフセット、サイズと実際に使用されるビデオファイルのオフセット、サイズの両方を記憶しておき、このような MPEGデータ再生アプリケーション 14からの要求サイズとサーバプログラム 1 1から送られてくるデ一タサイズの差異を管理する。

次に MPEGデータ再生アプリケーシヨン 14は時間 T3で先ほどと同様にデータ要求を行う。先ほどと同様にクライアントプログラム 13 は MPEG データ再生アプリケーシヨン 14 からの要求サイズを満たすまでサーバプログラム 1 1にデータ要求を行う。

サーバプログラム 1 1は先ほどと同様に LBRデータをクライアントプログラム 13に送る。

次に MPEGデータ再生アプリケ一シヨン 14は時間 T4で LBRモード OFF 要求を行い、オフセット 40、サイズ 10 でデータ要求を行う。クライアントプログラム 13は LBRモード OFF要求をサーバプログラム 1 1 に送るとともにオフセット 60、サイズ 10でデータ要求を行う。サーバプログラム 1 1はオフセット 60、サイズ 10のデータを取り出し、クライアントプログラム 13に送る。

以上のようにして送られてきたデータで MPEG データ再生アプリケ一シヨン 14は再生を行っていく。また MPEGデータ再生アプリケーション 14が再生位置の変更を行った場合にはオフセットの値を MPEGデータ再生アプリケーション 14 で要求するオフセットと実際に使用されるビデォファイルのオフセットを同一の値にして初期化する。

1. 9 LBRデ一タの転送か、フルデータの転送かの判断

ここで、 MPEGデータ再生アプリケーション 14は、ビデオデータの再生を通常データまたは LBR データのどちらで開始するかを決定し、 LBR データで開始する場合はこれをクライアントプログラム 13 に送ることもできる。

また MPEGデータ再生アプリケーシヨン 14は、いつでもサーバプログラム 1 1から送られてくるデータを通常データから LBRデータに、または、 LBRデータから通常データへ配信の変更要求を行える。

2. サーバプログラムの動作

2. 1サーバプログラム全体動作

次に、第 10図に基づいて、サーバプログラム 1 1の動作について説明する。サーバプログラム 1 1は、クライアント 9からの要求を待ち（ステツプ S141)、要求を受け取ると、受け取った要求がデータ転送要求か否かを判断する（ステップ S 142)。

データ転送要求ではない場合には、要求に応じた処理を行い（ステップ

S143)、処理結果を REPLY としてクライアント 9 へ送信する（ステツプ

S 4)。ここで、ステップ S 143で行われる処理は、例えば、 MPEGデータに係るファイルの 0PEN、 CLOSE等の処理である。また、クライアント 9 から LBRモードの変更が指示された場合に、 LBRモードを変更する処理も、ステップ S 143で行われる。

一方、データ転送要求である場合には、ディスク装置 6から MPEGデータを読み込み、読み込んだデータをサーバ用バッファ 7へ格納する。このとき、読み込む MPEGデータは、クライアント 9から指定された要求サィズ分の MPEGデータである（ステップ S 145)。次に、内部に記憶された

LBRモードを調べ、 LBR化が必要か否かを判断する（ステップ S 146)。

LBR化が不要な場合には、サーバ用バッファ 7に格納された MPEGデータをクライアント 5へ送信する（ステップ S149、第 19図ステップ S247)。一方、 LBR化が必要な場合には、サーバ用バッファ 7に記憶された MPEG データについて LBRモードに応じた LBR処理を行って、 LBR処理後の MPEG データを LBR用バッファ 8に格納する（ステップ S147)。そして、 LBR用バッファ 8に格納された MPEGデ一タをクライアント 9へ送信する（ステップ S148)。このステップ S148は送信ステップである。 LBR処理については後述する。

2. 2 LBR処理

次にデータ抽出ステップたる LBR処理について詳述する。

LBR処理は、 Iピクチャ、 Pピクチャ、 Bピクチャを有する MPEGデータから、所定のピクチャを抽出して、データサイズの小さい MPEGデータを作成する処理である。

2. 2. 1 MPEG1のデータ構造

まず、 MPEG1データの構造について説明する。第 17図に MPEG1 システム、第 18図に GOP (Group of Pi ctures) 層までの MPEGl ビデオの各構成を示す。これらの MPEG1 データの構造は、文献 IS0/IEC11172- 1/2： Information technology-Coding of moving pi ctures and associated audio for di gi tal Storage media at up to about 1. 5Mbit/S", INTERNATIONAL STANDARD, 1993に詳細に説明されているものである。

MPEG1システムは MPEG1 ビデオ、 MPEG1オーディオを同期化して、多重化したもので、実際にアプリケーションに適用する場合には、この MPEG1 システムが使用される。第 17図のように PACK START C0DE、 Packet Start codeなどの開始コードは 32 ビットのデータであり、バイト配置されてレヽる。また、これらの開始コードのビットパターンは MPEG1のビットストリーム中ではそれ以外に決して発生しないものであり、各種ヘッダの識別に使用される。 System header にはストリ一ム全体の概要を記述した情報グループが入っている（例えば、ビットレ一トなど）。 other header data にはタイムスタンプ（PTS、 DTS ) などの情報が入っている。 SCR (System Clock Reference) とは、ビデオとオーディオの復号器を含む MPEGシステム復号器において、時刻基準となる STC (System Time Clock, 基本となる同期信号）の値を符号器側で意図した値にセット，校正する為の情報である。 MPEG1 ビデオの G0Pは MPEG1 ビデオにおけるランダムアクセス単位であり、通常 G0Pは 0. 5秒程度の再生時間になる。

第 18図は、第 17図の Packet dataがビデオデータであった場合の内容を詳細に示したものであり、 G0P層の I、 P、 Bはそれぞれ I ピクチャ、 P ピクチャ、 B ピクチャを表している。各ピクチャの内容は以下の通りである。

I ピクチャ： Intra- Picture (フレーム内符号化画像）

I ピクチャは前後のピクチャとは無関係にその情報だけから符号化された画面で、フレーム間予測を使わずに生成されたものである。 I ピクチヤはフレーム内圧縮フレームのデータの一種である。

Pピクチャ： Predictive- Pi cture (フレーム間順方向予測符号化画像） P ピクチャは I または P ピクチャからの予測を行うことによってできる画面である。すなわち、前の Iまたは Pピクチャからの差分によって表される。 Pピクチャはフレーム間圧縮フレームのデータの一種である。

Bピクチャ： Bidirectional ly predi ctive- Pi cture (双方向予測符号化画像）

Bピクチャは MPEGの特徴である双方向予測によってできる画面である。すなわち、前後の I または P ピクチャからの差分によって表される。 B ピクチャはフレーム間圧縮フレームのデータの一種である。

2. 2. 2 LBR処理の動作説明

次に、 LBR処理部 12が行う LBR処理の詳細について第 12図に基づいて説明する。まず、 LBR処理部 12 は、サーバ用バッファ 7 に格納されている MPEG データのパックヘッダの位置が確定済みかを判断する（ステップ S 151)、確定済みの場合には、ステップ S 159に進む。確定済みでない場合には、ステップ S 152に進みパックへッダの位置を確定する処理を行う。

パックヘッダの位置を確定する処理は、まず、サーバ用バッファ 7に記憶されている MPEG データの内容をデータの先頭部分から順次調べていき、パックヘッダのデータを探し（ステップ S 152)、探し出したパックヘッダを LBR用バッファ 8へ複写する（ステップ S 153)。

次に、パックヘッダに続くデータがシステムヘッダかを調べる（ステツプ S 154)。システムヘッダであった場合には、そのシステムヘッダ部分をサーバ用バッファ 7から LBR用バッファ 8へ複写する（ステップ S 155)。システムヘッダでない場合には、ステップ S 155の処理を跳ばして、ステップ S 156へ進む。

ステップ S154若しくはステップ S155が終了すると、続くサ一バ用バッファ 7内のデータがビデオバケツトであるかを調べる（ステップ S 156)。ビデオパケットである場合には、ステップ S157のピクチャチェックを行う。このピクチャチェックによって、所定のピクチャが LBR用バッファ 8 へ抽出される。ピクチャチェックについては、第 12図を用いて詳細に説明する。一方、ビデオバケツトではない場合には、ステップ S 158へ進み、パケットの終わりまでのデータをサーバ用バッファ 7から LBR用バッファ 8へコピーする。ビデオパケット以外のパケットとしては、ォ一ディォバケツトがあり、このオーディオバケツトが LBR用バッファ 8にコピーされる。

次に、次のデータがパックヘッダであるかを調べ（ステップ S 159)、パックヘッダである場合には、そのパックヘッダをサーバ用バッファ 7から LBR用バッファ 8へコピーする。パックヘッダでない場合には、ステップ S 161へ進む。

ステップ S159若しくはステップ S160が終了すると、次のデータがシステムヘッダであるかが調べられる（ステップ S 161)。システムヘッダである場合には、当該システムヘッダをサーバ用バッファ 7から LBR用バッファ 8へコピーする（ステップ S 162)。システムヘッダでない場合には、ステップ S 163へ進む。

ステップ S161若しくはステップ S 162が終了すると、続くデータがビデォバケツトであるかを調べ（ステップ S 163)、ビデオパケットである場合には、ピクチャチェックを行う（ステップ S 165)。このピクチャチエツクは、上述ステップ S157 と同様の処理である。一方、ビデオパケットではない場合には、パケットの終わりまでのデータをサーバ用バッファ 7 から LBR用バッファ 8へコピーする（ステップ S 164)。

ステップ S 164若しくはステップ S 165が終了すると、サーバ用バッフ了 7内にある MPEGデータの終わりまでについて、上述の処理が終了したかが調べられ（ステップ S 166)、サーバ用バッファ 7内にある MPEGデータの終わりまで処理が終了していない場合には、ステップ S 159へ進み、ステップ S159〜ステップ S 165までの処理を繰り返す。

一方、サーバ用バッファ 7内にある MPEGデータの終わりまで処理が終了した場合には、 LBR用バッファ 8に LBRヘッダを LBR用バッファの先頭、すなわちパケットの先頭に書き込む（ステップ S167)。 LBRヘッダは、 MPEGデータと LBRデ一タの区別をするためのヘッダである。このとき、 I、 P、若しくは Bピクチャの取り出しの際（ピクチャチェック S 155、 S 165 の際）にバケツトのサイズの変更が発生した場合は、 LBR用バッファに書き出されたバケツトの長さに基づいて、バケツトのヘッダ部にあるパケット長の変更を行う。ステップ S167が終了すると、 LBR処理（ステップ S 147)が終了する（ステップ S 168)。 LBR処理については以上のような動作を行う。

2. 2. 3ピクチャチェック処理

次に、上述ステップ S157、及び、ステップ S165で説明したピクチャチェック処理について、第 12図〜第 15図を用いて詳細に説明する。

第 12図は、 3 種類のピクチャチェック処理を表しており、それぞれのピクチャチェック処理の詳細については、第 13図〜第 15図でそれぞれ説明する。

まず、最初に上述第 4図のステップ S112や MPEGデータの OPEN時にサ —バ側に通知された間引き間隔に基づき、 I，P及び B ピクチャを取り出すか否かを判断する（ステップ S171)。取り出すと判断されたときは、 IPB ピクチャチェック処理（ステップ S172)を行なった後、ピクチャチェック処理を終了する。取り出さないと判断されたときは、 I及び P ピクチャの取り出しを行うかを判断する（ステップ S173)。取り出すと判断されたときは、 IPピクチャチェック処理（ステップ S174)を行なった後、ピクチャチェック処理を終了する。取り出さないと判断されたときは、 I ピクチヤの取り出しを行うかを判断する（ステップ S175) _c 取り出しを行うと判断されたときは、 I ピクチャチェック処理（ステップ S176)を行った後、ピクチャチェック処理を終了する。行わないと判断されたときは、ピクチヤチェック処理を終了する。

Iピクチャチェック処理（ステップ S176)

I ピクチャチェック処理とは、 MPEGデータ中から I ピクチャの一部又は全部を抽出し、 P ピクチャ及び B ピクチャを削除したデータを生成する処理である。

以下に、第 13図を用いて詳細に説明する。

まず、最初に pts、 dts、 I ピクチャフラグをチェックする（ステップ S181)。 I ピクチャフラグとは、現在ポインタが指しているデータが、 I ピクチャのデータ中にあるか否かを示すフラグであり、 O Nのときは I ピクチャ中、 O F Fのときは I ピクチャ中ではないことを表す。ここで、ポインタとは、周知の技術であるファイルポインタのことであり、サーバ用バッファ 7に格納されている MPEGデータにアクセスするために用いられる。

次に、サーバ一用バッファ 7のデータ中、現在、ポインタが示している位置は I ピクチャ中である力、すなわち、 I ピクチャフラグが O Nか否かを判断し（ステップ S182)、 I ピクチャ中である場合には、ポインタが示している位置からパケットの終わりまでのデータを、サーバー用バッファ 7から LBRノッファ 8へコピーして（ステップ S190)、 I ピクチャチェック処理（ステップ S176)を終了する（ステップ S191)。

一方、 I ピクチャ中でない場合には、現在ポインタが示している位置からバケツトの終わり方向に向けて I ピクチャの先頭があるかを検索する（ステップ S183)。 I ピクチャの先頭が見つからなかった場合には、 I ピクチャチェックを終了する（ステップ S191 ) _c

I ピクチャの先頭が見つかった場合には、間引き間隔に基づいて見つかったピクチャを取り出すかを判断する（ステップ S184)。間引き間隔は、クライアント 9より通知された間隔である。例えば、第 16図に示すように判断する。第 16図は、間引き間隔の間隔指定データに対するステップ S184等の判断を示した表の一例である。指定された間引き間隔の間隔指定データが「2」の場合、このステップ S184の 1回目の実行であるときは、 Yesと判断してステップ S185に進み、ピクチャを取り出す。ステツプ S189等を通って再びこのステップ S184に戻ってきた場合、すなわち、 2回目の実行である場合には、 Noと判断し、ステップ S189に進み、ピクチヤを取り出さない。以下、同様に 3回目は YeS、 4回目は No といったように判断する。他の間引き間隔においても同様に第 16図に示したように判断する。

ステップ S184で Iピクチャを取り出す、すなわち Yesと判断された場合には、このステップ S185に進み、 I ピクチャフラグを O Nにする。次に、ポインタの位置からパケットの終わり方向に、 I ピクチャの終わりを検索する（ステップ S186)。バケツトの終端まで終わりがなかった場合には、全てのデータが Iピクチャであつたと判断し、ステップ S186 の検索前のポインタ位置からバケツトの終端までのデータを、サーバ用ノッファ 7力、ら LBR用バッファ 8へコピ一し（ステップ S187)、 I ピクチャチェック処理（ステップ S176)を終了する（ステップ S191)。

一方、ステップ S186で Iピクチャの終わりが見つかった場合には、ステツプ S185で O Nにしたピクチャフラグを O F Fとし、ステップ S 186 の検索前のボインタ位置から、見つかった I ピクチャの終わりまでのデータを、サーバ用バッファ 7カゝら LBR用バッファ 8へコピーする（ステツブ S188)。

そして、パケットの終わりまでチェック処理が完了したかを調べる（ステツプ S189)。終わりまでチェック処理が完了した場合には、 Iピクチャチェック処理（ステップ S176)を終了する（ステップ S191)。まだ、バケツトの終わりまでチェック処理が終了していない場合には、ステップ S183 に戻り、上述の処理を繰り返す（ステップ S189)。

なお、上述の処理において、サーバ用バッファ 7から LBR用バッファ 8 へデータをコピーした場合には、サーバ用バッファ 7内のバケツトデータを指すポインタは、コピーしたデータの分だけ進む。また、検索を行つた場合にも、検索を行った位置まで移動する。

IPピクチャチェック処理 IPピクチャチェック処理とは、 MPEGデータ中から Iピクチャ及び Pピクチャの一部又は全部を抽出し、 B ピクチャを削除したデータを生成する処理である。

以下に、第 14図を用いて詳細に説明する。 IPピクチャチェックは、抽出するデータの対象が、 I ピクチャ及び P ピクチャである点を除いて、基本的に第 13図に示した Iピクチャチェック処理（ステップ S176)と同様である。

まず、最初に pts、 dts、 I ピクチャフラグ、及び Pピクチャフラグをチェックする（ステップ S201)。 Pピクチャフラグとは、現在ポインタが指しているデータが、 P ピクチャのデータ中にあるか否かを示すフラグであり、 O Nのときは Pピクチヤ中、 O F Fのときは Pピクチヤ中ではないことを表す。

次に、サーバー用バッファ 7のデ一タ中、現在、ポインタが示している位置は I若しくは P ピクチャ中である力、すなわち、 I若しくは P ピクチャフラグが O Nか否かを判断し（ステップ S202)、 I若しくは Pピクチヤ中である場合には、ボインタが示している位置からバケツトの終わりまでのデータを、サーバ一用バッファ 7力ら LBRノッファ 8へコピーして（ステップ S210)、 IP ピクチャチェック処理（ステップ S174)を終了する（ステップ S211)。

—方、 I若しくは P ピクチャ中でない場合には、現在位置からバケツトの終わり方向に向けて I若しくは Pピクチャの先頭があるかを検索する（ステップ S203)。 I若しくは Pピクチャの先頭が見つからなかった場合には、 IPピクチャチェックを終了する（ステップ S21 1)。

I若しくは P ピクチャの先頭が見つかった場合には、間引き間隔に基づいて見つかったピクチャを取り出すかを判断する（ステップ S204)。間引き間隔は、クライアント 3 より I ピクチャ、 P ピクチャのそれぞれについて通知された間隔である。例えば、第 16図に示すように判断する。ステップ S203で Iピクチャの先頭が見つかった場合には、 I ピクチャについて指定された間引き間隔で、第 16図に示したような判断を行う。一方、ステップ S203で Pピクチヤの先頭が見つかった場合には、 Pピクチャについて指定された間引き間隔で、第 16図に示したような判断を行う。ステップ S204でピクチャを取り出す、すなわち Yesと判断された場合には、このステップ S205に進み、ステップ S203で見つかったピクチャの先頭に対応して、 I ピクチャフラグ又は P ピクチャフラグを O Nにする。

次に、ポインタの位置からパケットの終わり方向に、 I若しくは P ピクチャの終わりを検索する（ステップ S206)。バケツトの終端まで終わりがなかった場合には、全てのデータが I若しくは Pピクチャであつたと判断し、ステップ S206の検索前のボインタ位置からバケツ卜の終端までのデータを、サ一バ用バッファ 7力ら LBR用バッファ 8へコピ一し（ステップ S207)、 IP ピクチャチェック処理（ステップ S174)を終了する（ステップ S211)。

一方、ステップ S206で I若しくは Pピクチャの終わりが見つかった場合には、ステップ S205で O Nにしたピクチャフラグを O F Fとし、ステップ S206の検索前のボインタ位置から、見つかった I若しくは Pピクチャの終わりまでのデータを、サーバ用バッファ 7から LBR用バッファ 8 へコピーする（ステップ S208)。

そしてノ、。ケットの終わりまでチェック処理が完了したかを調べる（ステツプ S209)。終わりまでチェック処理が完了した場合には、 IPピクチャチェック処理（ステップ S174)を終了する（ステップ S211)。まだ、パケットの終わりまでチェック処理が終了していない場合には、ステップ S203に戻り、上述の処理を繰り返す（ステップ S209)。なお、上述の処理において、サ一バ用バッファ 7カゝら LBR用バッファ 8 へデータをコピーした場合には、サーバ用バッファ 7内のバケツトデ一タを指すポインタは、コピーしたデータの分だけ進む。また、検索を行つた場合にも、検索を行った位置まで移動する。

IPBピクチャチェック処理

IPB ピクチャチェック処理とは、 MPEGデータ中から I ピクチャ、 P ピクチャ、及び、 B ピクチャの一部又は全部を抽出したデータを生成する処理である。

以下に、第 15図を用いて詳細に説明する。 IPB ピクチャチェックは、抽出するデータの対象が、 I ピクチャ、 Pピクチャ、及び Bピクチャである点を除いて、基本的に第 13図に示した I ピクチャチェック処理（ステツプ S176)と同様である。

まず、最初に pts、 dts、 Iピクチャフラグ、 Pピクチャフラグ、及び B ピクチャフラグをチェックする（ステップ S221)。 Bピクチャフラグとは、現在ポインタが指しているデータが、 B ピクチャのデータ中にあるか否かを示すフラグであり、 O Nのときは B ピクチヤ中、 O F Fのときは B ピクチャ中ではないことを表す。

次に、サーバー用バッファ 7のデータ中、現在、ポインタが示している位置は I、 P、若しくは Bピクチャ中である力、すなわち、 I、 P、若しくは Bピクチャフラグが O Nか否かを判断し（ステップ S222)、 I、 P、若しくは Bピクチャ中である場合には、ボインタが示している位置からパケットの終わりまでのデータを、サ一バー用バッファ 7から LBRバッファ 8へコピ一して（ステップ S230)、 IPBピクチャチェック処理（ステップ S172)を終了する（ステップ S231)。

一方、 I、 P、若しくは Bピクチャ中でない場合には、現在位置からパケットの終わり方向に向けて I、 P、若しくは Bピクチャの先頭があるかを検索する（ステップ S223)。 I、 P、若しくは Bピクチャの先頭が見つからなかった場合には、 IPBピクチャチェックを終了する（ステップ S231)。

I、 P、若しくは Bピクチャの先頭が見つかった場合には、間引き間隔に基づいて見つかったピクチャを取り出すかを判断する（ステップ S224)。間引き間隔は、クライアント 3 より I ピクチャ、 P ピクチャ、 B ピクチャのそれぞれについて通知された間隔である。例えば、第 16図に示すように判断する。ステップ S223で I ピクチャの先頭が見つかった場合には、 I ピクチャについて指定された間引き間隔で、第 16図に示したような判断を行う。一方、ステップ S223で Pピクチャの先頭が見つかつた場合には、 Pピクチャについて指定された間引き間隔で、 Bピクチャの先頭が見つかった場合には、 B ピクチャについて指定された間引き間隔で第 16図に示したような判断を行う。

ステップ S224でピクチャを取り出す、すなわち Yesと判断された場合には、このステップ S225に進み、ステップ S223で見つかったピクチャの先頭に対応して、 I、 P、又は Bピクチャフラグを O Nにする- 次に、ポインタの位置からパケットの終わり方向に、 I、 P、若しくは Bピクチャの終わりを検索する（ステップ S226)。パケットの終端まで終わりがなかった場合には、全てのデータが I、 P、若しくは Bピクチャであつたと判断し、ステップ S226の検索前のボインタ位置からバケツトの終端までのデータを、サ一バ用バッファ 7から LBR用バッファ 8へコピ一し（ステップ S227)、 IPBピクチャチェック処理（ステップ S172)を終了する（ステップ S231)。

一方、ステップ S226で I、 P、若しくは B ピクチャの終わりが見つかつた場合には、ステップ S225で O Nにしたピクチャフラグを O F Fとし、ステップ S226の検索前のボインタ位置から、見つかった I、 P、若しくは Bピクチャの終わりまでのデータを、サーバ用バッファ Ίから LBR用バッファ 8へコピ一する（ステップ S228)。

そして、パケッ卜の終わりまでチェック処理が完了したかを調べる（ステツプ S229)。終わりまでチェック処理が完了した場合には、 IPBピクチャチヱック処理（ステップ S 172)を終了する（ステップ S231 )。まだ、パケットの終わりまでチェック処理が終了していない場合には、ステップ S223に戻り、上述の処理を繰り返す（ステップ S229)。

なお、上述の処理において、サーバ用バッファ 7から LBR用バッファ 8 へデータをコピーした場合には、サーバ用バッファ 7内のパケットデータを指すポインタは、コピーしたデータの分だけ進む。また、検索を行つた場合にも、検索を行った位置まで移動する。この実施例 1によれば、第 20図に示されるように、ネットワーク 4や CPU の負荷状態に応じて、高品質なフルデータの送受信（ステップ S271 〜ステップ S273)、データ量の少ない LBRデータの送受信（ステップ S274 〜ステップ S277)が切り替わるため、厳しい負荷状態においても、リアルタイムに MPEGデータを配信することができる。

特に、 MPEGデータを間引いて、所定間隔のフレームデータを送信しているため、ある時期のフルデータは集中して再生され、ネットワーク負荷が高くビデオデータを送信できないために、 MPEGデータの送信がビデォの再生時刻に間に合わない結果、その他の時期の MPEGデータは再生されないという現象を抑制することができる。

また、クライアント 9の負荷が高くビデオ再生に十分な CPU時間を割り当てることができない場合には、フルデータを送信してもフレーム落ちが発生してしまう。この実施例によれば、ビデオ再生装置の CPU負荷を測定し、 CPU負荷に応じた LBR処理を行っているため、上述のような場合には、データ量を減少させた LBRデータを送信し、ネットワーク負荷を軽^することができる。

実施例 1ではビデオデ一タとして MPEGデータを例として上げ説明した力フレーム内圧縮フレームとフレーム間圧縮フレームを持つビデオデータであれば、他のビデオデータであっても、フレーム間圧縮フレームまたはフレーム内圧縮フレームとフレーム間圧縮フレームを適切に間引くことによって LBR化をおこない転送するデータ量を調節することができる。

ここで、フレーム内圧縮フレームのデータとは、自己のフレーム内のデータに基づいて、圧縮されたフレームデータであり、フレーム間圧縮フレームのデータとは、他のフレームとの差分に基づいて、圧縮されたフレームデータである。実施例 2.

第 1図に本発明の実施例 2におけるシステム構成を示す。第 21図はビデォサーバ 5およびクライアント 9の MPEGデータ、 LBRデータの配信/再生部分の S/W構成を示したものである。第 21図において、第 2図と同一の符号は同一又は相当の部分を表しており、ネットワーク負荷測定部 18、 CPU負荷測定部 19がクライアントプログラム 13ではなく、サーバプログラム 1 1にある。

この実施例 2は、サーバ主導型で動作するシステムである。サーバ主導型とは、クライアント 9からのデータ転送要求に従って、ビデオサーパ 5でフルデータ若しくは LBRデータをリアルタイムに生成し配信し、第 22図にあるように、クライアント 9からのデータ転送要求をトリガーとして配信を開始し、その後ビデオサーバ 5がネットワーク負荷測定部 18や CPU負荷測定部 19からの情報を考慮し、ビデオサーバ 5側で適切な量のデータをクライアントに配信し続けるものである。クライアント 9 は送られてきたデータの受け取りと再生を行う。なお途中で、サーバ主導型からクライアント主導型に切り替えることも可能である。

この実施例 2のシステムは以上のような構成であり、フルデータ若しくは LBRデータ配信/再生を第 24図のサーバプログラム、第 23図のクライアントプログラムの処理フローチヤ一トに基づき、以下に詳細に説明する。なお、第 23図において、第 4図と同一の符号は同一又は相当の部分を表し、第 24図において、第 10図と同一の符号は同一又は相当の部分を表す。

第 23図及び第 24図の処理フロ一チヤ一トにおいて、まず MPEGデータ再生アプリケーション 14 がデータ転送要求を送信する（第 23図ステップ S1 14)。この要求はクライアントプログラム 13からネットワーク 4を経てサーバプログラム 1 1に渡される。

サーバプログラム 1 1 ではプログラム起動時にネットワーク負荷測定部 18および CPU負荷測定処理部 19を独立のプロセスで起動しており、ネットヮーク負荷及び CPU負荷を常時測定している。

LBR開始要求を受け取った（第 24図ステップ S 141、 S 142)サーバプログラム 1 1は LBRデータ生成のためにディスク装置 6からサーバ用バッファ 7 へ MPEGデータの読み込みを行う（ステップ S 145)。

次に、サーバプログラム 1 1 は、ネットヮ一ク負荷測定部 18及び CPU 負荷測定部 19が測定した、ネットワーク負荷及び CPU負荷に基づき、 LBR モードを決定する。この決定方法は、実施例 1で示した方法と同様である。

続いて、ステップ S300の決定結果に基づき、 LBR処理を行かを判断し (ステップ S 146)、行う場合にはステップ S 147で LBR処理を行う。この LBR処理は、実施例 1 と同様な方法で行う。そして、サーバプログラム 1 1はフルデータ若しくは LBR用バッファ 8 に生成された LBRデータをクライアントプログラム 13に配信する（ステップ S148若しくはステップ S149)。

次に、クライアント 9からデータ転送要求で指定された MPEGデータのファイル終端（EOF)まで、送信が終了したかが判断される（ステップ S301)。送信が終了した場合には、ステップ S 141に戻り、次のクライァント 9からの要求待ち処理を行う。ファイル終端までの送信が終了していない場合には、ステップ S145に戻り、次の MPEGデータの送信処理を行う。

この実施例 2のサーバプログラム 1 1では以上のことを繰り返し行うことによって、 LBR データの配信をし続ける。一方クライアントプログラム 13は送られてきた LBRデータを受け取り（第 23図ステップ S 1 15)、これをクライアント用バッファ 10に格納し（ステップ S 1 16)、 MPEGデータ再生アプリケーション 14が要求したサイズ分のフルデータ若しくは LBR デ一タを、 MPEG データ再生アプリケーションに渡す（ステップ S 1 19) _c MPEGデータ再生アプリケーシヨン 14はこのデータの再生を行う。

以上のことを繰り返して MPEGデータの再生が行われる。

この実施例 2 においても、ネットワーク負荷、 CPU負荷の状態に応じて、転送する MPEGデータの量を自動的に調整して配信するため、ビデオデータをリアルタイムに再生することができる。なお、この実施例 2ではビデオデータとして MPEGデータを例として上げ説明したが、フレーム内圧縮フレームとフレーム間圧縮フレームを持つビデオデータであれば、他のビデオデータであっても、フレーム間圧縮フレームまたはフレーム内圧縮フレームとフレーム間圧縮フレームを適切に間引くことによって LBR化をおこない転送するデータ量を調節することができる。実施例 3.

第 25図に本発明の実施例 3におけるシステム構成を示す。

第 25図において、第 1図と同一の符号は同一又は相当の部分を表している。 15はビデオカメラ、 16はビデオカメラ 15からのビデオ信号を入力し、リアルタイムに MPEGデータにェンコ一ドするためのリアルタイムェンコ一ダ、 17 はリァノレタイムエンコーダがェンコ一ドした MPEGデータを記憶するリアルタイムデータ用バッファである。

また、図示していないが、ビデオサーバ 5は、マルチキャスト時の MPEG データの途中再生に使用する MPEGデータの各種パラメータ、例えば、フレ一ムレート等を格納しておくパラメータ記憶バッファを有している。第 2図は本実施例のビデオサーバ 5およびクライアント 9の LBRデータの配信ノ再生部分の S/W構成を示している。

本実施例ではリアルタイムでエンコードされた MPEG データをビデオサーバ 5上でリアルタイムに LBR処理を行って生成する LBRデータ、または実施例 1記載のディスク装置 6に格納されている通常の MPEGデータから生成する LBRデータをマルチキャス卜で各クライアント 9に配信するものである（以下マルチキャスト LBR配信という）。ここで、この実施例 3では実施例 1 と同様にクライアント主導型で動作する。なおクライアント主導型から実施例 2記載のサーバ主導型に切り替えることも可である。

本実施例のシステムは以上のような構成であり、以下第 26図のシ一ケンス図、第 27図のサーバプログラム、および第 28図のクライアントプログラムの処理フローチャートに基づき詳細に説明する。第 27図において、第 10図と同一の符号は同一又は相当の部分を表し、第 28図において、第 4 と同一の符号は同一又は相当の部分を表す。第 26図はデータ転送のマルチキヤ^トモ一ドによる配信を説明するシーケンス図であり、ビデオサ —バ 5が 2つのクライアント 9に同時にデータ転送を行う場合を示している。

まず、最初にクライアント 9側の動作について説明する。 MPEG再生ァプリケーション 14がマルチキャストモ一ドを指定して OPEN要求を行う。この OPEN要求を受け取ったクライアントプログラム 13は、ネットヮーク 4を介して、ビデオサーバ 5へマルチキャストグループ参加要求を送信する（第 28図ステップ S 107、第 26図ステップ S320)。このマルチキャストグループ参加要求は実施例 1の OPEN要求の役割及びマルチキャストグループへの参加を要求する役割を持つ要求である。

次に、クライアントプログラム 13は、ステップ S 108〜ステップ S 1 13 までの処理を行い、 MPEG再生アプリケ一ション 14による指示に基づき、データ転送要求若しくはリアルタイムデータ転送要求のいずれかを送信する（第 28図ステップ S1 14、第 26図ステップ S321)。

以降、実施例 1 と同様に動作して、ビデオサーバ 5から送信された MPEG データを再生する。次に、第 27図を用いてビデオサーバ 5側の動作について説明する。ステップ S 141で、クライアント 9からの要求を受け取ったサーバプログラム 1 1は、受け取った要求が、データ転送要求若しくはリアルタイムデ一タ転送要求であるかを判断する（ステップ S310)。

データ転送要求若しくはリアルタイムデータ転送要求ではない場合には、受け取った要求がマルチキャストグル一プ参加要求であるか否かを判断する（第 27図ステップ S31 1)。マルチキャストグループ参加要求であるときには、サーバプログラム 1 1は、マルチキャストグル一プ参加要求を送信したクライアント 9を、マルチキャストグル一プへ登録し（ステツプ S312〉、登録されたマルチキャストグループの IDの情報を含むリプラィを返す（ステップ S 144)。マルチキャストグループ参加要求ではない場合には、ステップ S143に進み、実施例 1で説明した通りの処理を行う。一方、ステップ S310で、受け取った要求が、データ転送要求若しくはリアルタイムデータ転送要求であると判断された場合には、受け取った要求が最初のリアルタイムデータ転送要求であるかが判断される（ステップ S313)、最初のリアルタイムデータ転送要求である場合には、リアルタイムエンコーダ 16 に開始要求を出力し（ステップ S314)、この開始要求を受け取ったリアルタイムエンコーダ 16がビデオカメラ 15から受け取ったビデオ信号のエンコードを開始する。すなわち、リアルタイムエンコーダ 16はビデオカメラ 15で撮影しているビデオを入力し、リアルタイムに MPEGデータにェンコ一ドし、 MPEGデータをディスク装置 6 に書き出すと同時に、リアルタイム用データバッファ 7にも書き出す。ここでディスク装置 6に書き出された MPEGデータを使用したマルチキヤストも可能である。リアルタイムエンコーダ 16は以後、サーバプログラム 1 1からの停止要求があるまで、リアルタイムエンコードを行い続ける = 次にサーバプログラム 1 1 はリアルタイムエンコード開始要求を出した直後にリアルタイムエンコーダ 16から送られてきた MPEGデ一タをパラメータ記憶バッファに格納しておく。このバッファはマルチキャスト配信中に接続してくるクライアントが MPEG データの途中から生成できるようにする為に各種 MPEGデータのパラメータ、例えばフレームレート等、を格納する為に使用するものである。

次に、サーバ用バッファ 7に MPEGデータを読み込む（ステップ S315)。この MPEGデータの読み込みは、データ転送要求か、リアルタイムデータ転送要求かによつて MPEGデータの読み込み元が異なり、データ転送要求である場合には、第 10図のステップ S 145でも説明したようにディスク装置 6から読み込む。リアルタイムデータ転送要求の場合には、リアルタィムデータ用バッファ 17から MPEGデータを読み込む。リアルタイムデータ用バッファ 17から MPEGデータを読み込む処理は、読み込み元が異なる点を除いて、第 10図のステップ S 145で説明した処理と同様である。次に、ステップ S146〜ステップ S149の処理を実施例 1 と同様に行い、クライアント 9へ MPEGデ一タを配信する。ただし、 MPEGデータの配信は、ステップ S31 1で登録されたマルチキャストグループに登録されたクライアント 9全部に、マルチキャストで送信される。具体的には、データ転送のパケットの出力先に、マルチキャストグループの IDを指定して、パケットを送信することによって行う。各クライアントは、ステップ S 144で送信されたリプライを受け取つており、このリプライに指定された自己のマノレチキャストグノレ一プの IDと、ネットワーク 4上に送信された IDとが一致するか否かを判定して、一致した場合には、そのバケツトを受け取る。

以上のような処理を行うことによって、複数のクライアント 9が同時にビデオデータの配信を受け取ることができる。この場合には、 1 回の配信で、複数のクライアント 9にビデオデータを供給できるので、ネットワーク負荷が少ないという効果がある。第 26図は、マルチキャストによるビデオデータの配信を説明するシーケンス図である。

まず、最初にクライアント 9の 1つであるクライアント Aが、マルチキャストグループ参加要求を送信する（ステップ S320)。このグループ参加要求を受け取ったビデオサーバ 5は、クライアント Aについて、上述のようにマルチキャストグループへの登録を行う。続いて、クライアント Aは、データ転送要求を出力し（ステップ S321)、ビデオサーバ 5よりビデオデータを受け取る（ステップ S322)。このときクライアント Bはまだマルチキャストグループに参加していないのでこのデータを受け取ることはできない。なお、ここでは、データ転送要求を出力しているが、リアルタイムデータ転送要求も同様に送信される。続いて、 MPEG再生ァプリケーション 14からのデータ転送要求があり、かつクライアント用バッファ 10に十分な空き容量ができると、再びデータ転送要求を出力する (ステップ S323)。

次に、クライアント 9の 1つであるクライアント Bカ、マルチキャストグループ参加要求を送信すると（ステップ S327)、ビデオサーバ 5は、クライアント Bをマルチキャストグル一プに登録し、マルチキャストグループの ID情報を有するリプライを返送する。

以降、クライアント A若しくはクライアント Bからデータ転送要求が出力され（ステップ S330等）、このデータ転送要求に対応して、ビデオサーバ 5がビデオデータを配信する（ステップ S329等）という処理が繰り返される。ここで配信されたビデオデータは、クライアント A及びクライアント Bによって受信され、クライアント A及びクライアント Bでビデォデータが再生される。 MPEG再生アプリケ一ション 14若しくはクライアントプログラム 13は、クライアント用バッファ 10に所定量の MPEGデータが残っている場合にはデータ転送要求を出力しないので、どのクライアント 9によってデータ転送要求が送信されるかは、それぞれのクライアント用バッファ 10に記憶されている MPEGデータの量によつて決定され、このデータ量が最先に所定量以下になったクライアント 9がデータ転送要求を送信する。なお、この実施例 3ではビデオデータとして MPEGデータを例として上げ説明したが、フレーム内圧縮フレームとフレーム間圧縮フレームを持つビデオデータであれば、他のビデオデータであっても、フレーム間圧縮フレームまたはフレーム内圧縮フレームとフレーム間圧縮フレームを適切に間引くことによって LBR化をおこない転送するデータ量を調節することができる。実施例 4.

第 1図に本発明の実施例 4におけるシステム構成を示す。システム構成は実施例 1 と同じであるが、 LBR用バッファ 8は早送り用バッファとして使用される。第 2図はビデオサーバ 5 及びクライアントプログラム 9 の早送りデータの配信 Z再生部分の s/w構成を示したものであり、 s/w 構成は実施例 1 と同様であるが、 LBR処理部 12は早送り処理部として使用される。

本実施例では実施例 1 と同様にクライアント主導型で動作する。また本実施例における早送りデータは実施例 1 の LBRデータと同様に I ピクチヤを取り出すことは同じであり、 LBR データとの違いはォ一ディォバケットの削除、バケツト内の PTS、 DTSの値を早送り再生用に変更することである。

本実施例のシステムは以上のような構成であり、以下早送り配信を第 29図のサーバプログラム 1 1、第 30図のクライアントプログラム 13の処理フローチヤ一トに基づき詳細に説明する。

第 29図はビデオサーバ 5の早送りデータの配信処理を説明するフローチャートであり、第 29図において、第 10図と同一の符号は同一又は相当の部分を表す。

第 30図はクライアントプログラム 13 の処理を説明するフ口一チヤ一トであり、第 30図において、第 4図と同一の符号は同一又は相当の部分を表す。

第 29図、第 30図の処理フローチヤ一トにおいて、まず MPEGデータ再生アプリケーション 14が早送り要求を行う。この早送り要求は、早送り要求であることを示す識別子と、ビデオデータを特定するデータとを含むパケットを送信することによって行われる。早送り要求はビデオが再生中であっても停止状態であっても構わない。この要求はクライアントプログラム 13が受け取り（ステップ S 101)、クライアントブログラム 13がビデオサーバ 5へ送信する（ステップ S350)。このときのビデオサーバ 5 の動作については後述する。

ビデオサーバ 5から早送りデータが送られてくると（ステップ S 1 15)、そのデータをクライアント用バッファ 10 に格納し（ステップ S 1 16)、ォフセットを計算し（ステップ S 1 17)、クライアント用バッファ 10 に要求されたサイズのデータが格納されるまでステップ S350〜ステップ S1 17 の処理が繰り返される（ステップ S 1 18)。クライアント用バッファ 10 に要求されたサイズのデータが格納されると、 MPEG再生アプリケーション 14 へ早送りデータが渡される（ステップ S 1 19)。この早送りデータは、 MPEGデ一タである。次に、同データ転送処理がクライアントプログラム 13とサーバプログラム 1 1 との間で繰り返される。

同データ転送処理は、まず、 MPEG再生アプリケーション 14からの早送り要求を待ち（ステップ S 101)、クライアント用バッファ 10 に要求されたサイズのデータが格納されると、 MPEG再生アプリケ一ション 14へ早送りデータが渡され（ステップ S l l⁹)、オフセットの計算を行う（ステップ S 1 17)、である。同データ転送処理内のステップ S 1 19で送信されるデータは、既に MPEG再生アプリケ一ション 14へ送信された早送りデータと同じものである。

クライアントプログラム 13はクライアント用バッファ 10に格納された早送りデータを再生アプリケーション 14に渡すとき早送りデータ（1 画面分）—を 1回（通常）だけ渡してもよいし、同じデータを複数回渡してもよい。複数回渡すことによって早送りの再生速度を変更できる。例えば 2回連続して同じデータを渡した場合は 1回だけ渡した場合の再生速度に比べて 1/2 になる。また当然ネットワークを流れるデータも 1/2 になる。このようにして渡された早送りデータは再生アプリケーション 1 1によって再生される。次に、サーバプログラム 1 1の動作について説明する。

ステップ S341で早送り要求を受け取ったサーバプログラム 1 1は、早送りデ一タ生成のためにディスク装置 6からサーバ用バッファ 7へ MPEG データの読み込みを行う（ステップ S 145)。次にこの MPEGデータについて LBR処理を行い、実施例 1 と同様な方法で早送りデータを生成する（ステツプ S 147)。ただし、以下の手順が実施例 1 の LBRデータ生成方法と異なる。

• ビデオバケツト以外のバケツトの取り出し処理

パケットがビデオパケット以外のものであった場合はバケツトを早送り用バッファ 8に書き出さない。

•バケツトの変更処理

パケット内の PTS、 DTSの値を早送り再生用に変更する。

次にサーバプログラム 1 1は早送り用バッファ 8に生成された早送りデータをクライアント 9に配信する（ステップ S 148)。

サーバプログラム 11では以上のことを繰り返し行うことによって、早送りデータの配信を行う。

特に、クライアントでビデオデータを早送り表示する際には、ビデオデータの全てのフレームデータを送信せずに、送信するフレームを間引いても表示上の支障がない。すなわち、通常再生時に 1秒間 3 0フレームで再生していた場合には、 2倍速再生を行う場合には、単純計算で 1 秒間に 6 0 フレームの再生を行うこととなる。しかしながら、 1 秒間に 3 0フレームのデータを表示しても、 1秒間に 6 0フレームのデータを表示しても、人間の視覚特性上、認識できる画質は差がないため、例えば、 2倍速再生においても 1秒間 3 0フレームの表示を行えばよい。したがって、この場合には、ビデオデータ中の複数のフレームデータのうち、図 3 2に示したように 1 フレームデータおきにフレームデ一タを抽出し、送信すればよい。このとき、ビデオサーバが送信するデータ量は少なくなるため、ネットワークにかかる負担を軽減することができる。早送り要求は、 2倍速、 5倍速といった早送り速度に応じた送信レベル指定して行ってもよい。

以上のことを繰り返して早送りデータの配信 Z再生が行われる。

なお実施例 4ではビデオデータとして MPEGデータで説明したが、フレーム間圧縮で圧縮されたフレームを持つビデオデータに応用して適用することは容易である。以上のように、本発明によるビデオデータ配信装置によれば、ネットワーク又はビデオデータ配信装置の負荷状態を測定する負荷測定部と、複数のフレームデータを含むビデオデータから、上記負荷測定部の測定結果に応じた数のフレームデータを抽出するデータ抽出部と、このデータ抽出部が抽出したフレームデータを送信する送信部と、を備えることとしたため、ビデオデータの表示品質の劣化を抑止しつつ、ネットヮーク負荷を軽減することができる。

また、データ抽出部は、負荷測定部の測定結果に基づいて、負荷が低いときにはビデオデータの全てのフレームデータを抽出し、負荷が高いときには、上記ビデオデータの一部のフレームデータを抽出するため、ビデオデータの表示品質の劣化を抑止しつつ、ネットワーク負荷を軽減することができる。

また、データ抽出部は、ビデオデータ内の複数のフレームデータ間のフレームデータを間引くことによって、負荷測定部の測定結果に基づいた数のフレームデータを抽出するため、ビデオデータの表示品質の劣化を抑止しつつ、ネットワーク負荷を軽減することができる。

また、データ抽出部は、フレーム内圧縮フレームのデータ及びフレ一ム間圧縮フレームのデータを有するビデオデータから、負荷測定部の測定結果に基づいて、フレーム間圧縮フレームのデータを削除したビデオデータを抽出し、送信部は、データ抽出部が抽出したビデオデータを送信するため、ビデオデータの表示品質の劣化を抑止しつつ、ネットヮーク負荷を軽減することができる。

また、ビデオデータは、 MPEGデータであるため、リアルタイムな再生が可能な MPEGデータを提供することができる。

また、データ油出部は、 I ピクチャ及び Pピクチャを有する MPEGデ一タから、負荷測定部の測定結果に応じて、 Pピクチャを削除した MPEGデ —タを生成するため、ビデオデータの量を少なくさせても画像の乱れの少な、ビデオデ一タを提供することができる。

また、データ抽出部は、 Iピクチャ及び Bピクチャを有する MPEGデータカら、負荷測定部の測定結果に応じて、 Bピクチャを削除した MPEGデータを生成するため、リアルタイムな再生が可能な MPEGデータを提供することができる。

また、データ抽出部は、 Iピクチャ、 Pピクチャ及び Bピクチャを有する MPEGデータから、負荷測定部の測定結果に応じて、 Pピクチャ及び B ピクチャを削除した MPEGデータを生成するため、リアルタイムな再生が一

4 5 可能な MPEGデータを提供することができる。

また、-データ抽出部は、複数の I ピクチャを有する MPEGデータから、負荷測定部の測定結果に応じた間隔で複数の Iピクチャを抽出するため、リアルタイムな再生が可能な MPEGデータを提供することができる。

また、ビデオカメラからの映像信号をリアルタイムにエンコードし、複数のフレームデータを有するビデオデータを生成するエンコーダと、このエンコーダが生成したビデオデータをー時的に記憶するバッファと、を備え、データ抽出部は、上記バッファに記憶されたビデオデータ内の複数のフレームデータ間のフレームデータを間引くことによって、上記ビデオデータから負荷測定部の測定結果に基づいた数のフレームデータを抽出するため、ビデオデータの表示品質の劣化を抑止しつつ、ネットワーク負荷を軽減することができる。

また、この発明のビデオデータ配信システムによれば、ビデオデータ配信システムの負荷状態を測定する負荷測定部、複数のフレームデータを含むビデオデータから、上記負荷測定部の測定結果に応じた数のフレ —ムデータを抽出するデータ抽出部と、このデータ抽出部が抽出したフレームデータをネットワークを介して送信する送信部と、を備えたビデォデータ配信装置、上記ネットワークから上記ビデオデータ配信装置の送信部から送信されたフレームデータを受信するとともに、受信したフレームデータを再生するビデオデータ再生装置、を備えるため、ビデオデータをリアルタイムに再生することができる。

また、負荷測定部は、ビデオデータ再生装置の動作を制御するプロセッサの負荷を測定するため、使用されないフレームデータの送信を抑制し、送信するビデオデータの量をより少なくすることができる。

また、複数のビデオデータ再生装置がネットワークに接続され、ビデォデータ配信装置の送信部から上記ネットワーク上に送信された 1つのフレームデータは、上記複数のビデオデータ再生装置それぞれにおいて受信されるため、一度に複数のビデオデータ再生装置へビデオデータを送信することができ、ネットワークの負荷を軽くすることができる。また、ビデオデータ再生装置は、データ量が指定されたデータ転送要求を複数回ビデオデータ配信装置へ送信し、ビデオデータ配信装置は、上記データ転送要求を受信すると、このデータ転送要求に指定されたデ —タサイズに基づいたフレームデータを送信するため、ビデオデータ再生装置の指示に基づいて、ビデオデータをリアルタイムに再生することができる。

また、ビデオデータ再生装置は、ビデオデータが指定されたデータ転送要求を送信し、ビデオデータ配信装置は、上記データ転送要求を受信すると、上記ビデオデータの一部のフレームデータを有するバケツトを所定の間隔で複数送信するため、ビデオデータをリアルタイムに再生することができる。

また、この発明によるビデオデータ配信方法によれば、ビデオデータ配信システムの負荷に応じた送信レベルを決定する送信レベル決定ステップと、複数のフレームデータを含むビデオデータから、上記送信レべル決定ステップにより決定された送信レベルに応じた数のフレームデータを抽出するデータ抽出ステップと、上記データ抽出ステップにおいて抽出されたフレームデータを送信する送信ステップと、を備えるため、リアルタイムなビデオデータの再生が可能になる。

また、送信レベル決定ステップは、ビデオデータ再生装置で実行され、ビデオデータ再生装置の動作を制御するプロセッサの負荷を測定する負荷測定ステップと、この負荷測定ステップの測定結果に対応した送信レベルを決定する決定ステップと、この決定ステップによって決定した送信レベルをビデオデータ再生装置からビデオデータ配信装置へ送信する送信レベル送信ステップと、を備えるため、リアルタイムなビデオデータの再生が可能になる。

また、ビデオデータ再生装置が、送信ステップによって送信されたフレームデータを受信し、受信したフレームデータを再生する再生ステツプを備えるため、リアルタイムなビデオデータの再生が可能になる。また、送信レベル決定ステップは、ビデオデータ再生装置がビデオデータを早送り再生する場合には、ビデオデータに含まれる複数のフレームデータから一部のフレームデータを間引いたビデオデータが抽出されるように送信レベルを決定し、早送り再生しない場合には、ビデオデータのフレームデータを間引かないように送信レベルを決定するため、ネットワーク負荷をより少なくすることができる。

また、データ抽出ステップは、ビデオデータ再生装置が複数のフレームデータ及び音声データを含むビデオデータを早送り再生する場合には、ビデオデータから上記音声データを削除し、送信レベルに応じた数のフレームデータを抽出したビデオデータを生成し、送信ステップは、上記データ抽出ステツプが生成したビデオデ一タを送信するため、ネットヮ —ク負荷をより少なくすることができる。産業上の利用可能性

以上のように、本発明にかかるビデオデータ配信装置、ビデオデータ配信システム、並びに、そのビデオデータ配信方法は、例えば、多量のビデオデータを配信するビデオデータ配信システムにおいて用いられるのに適している。

Claims

請求の範囲

1 .ネットワーク又はビデオデータ配信装置の負荷状態を測定する負荷測定部と、

複数のフレームデータを含むビデオデータから、上記負荷測定部の測定結果に応じた数のフレームデータを抽出するデータ抽出部と、

このデータ抽出部が抽出したフレームデータを送信する送信部と、を備えたビデオデータ配信装置。

2.データ抽出部は、負荷測定部の測定結果に基づいて、負荷が低いときにはビデオデータの全てのフレームデータを抽出し、負荷が高いときには、上記ビデオデータの一部のフレームデータを抽出することを特徴とする請求項 1に記載のビデオデータ配信装置。

3.データ抽出部は、ビデオデータ内の複数のフレームデータ間のフレームデータを間引くことによって、負荷測定部の測定結果に基づいた数のフレームデータを抽出することを特徴とする請求項 1 に記載のビデオデータ配信装置。

4.データ抽出部は、フレーム内圧縮フレームのデータ及びフレーム間圧縮フレームのデータを有するビデオデータから、負荷測定部の測定結果に基づいて、フレーム間圧縮フレームのデータを削除したビデオデータを抽出し、

送信部は、データ抽出部が抽出したビデオデータを送信することを特徴とする請求項 1に記載のビデオデータ配信装置。

5.ビデオデータは、 MPEGデータであることを特徴とする請求項 1に記載のビデオデータ配信装置。

6.データ抽出部は、 I ピクチャ及び Pピクチャを有する MPEGデータから、負荷測定部の測定結果に応じて、 Pピクチャを削除した MPEGデータを生成することを特徴とする請求項 5に記載のビデオデータ配信装置。

7.データ抽出部は、 Iピクチャ及び Bピクチャを有する MPEGデータから、負荷測定部の測定結果に応じて、 Bピクチャを削除した MPEGデータを生成することを特徴とする請求項 5に記載のビデオデータ配信装置。

8.デ一タ抽出部は、 I ピクチャ、 Pピクチャ及び Bピクチャを有する MPEG データから、負荷測定部の測定結果に応じて、 P ピクチャ及び B ピクチャを削除した MPEGデータを生成することを特徴とする請求項 5に記載のビデオデータ配信装置。

9.データ抽出部は、複数の Iピクチャを有する MPEGデータから、負荷測定部の測定結果に応じた間隔で複数の I ピクチャを抽出することを特徴とする請求項 5に記載のビデオデータ配信装置。

1 0 . ビデオカメラからの映像信号をリアルタイムにエンコードし、複数のフレームデータを有するビデオデータを生成するエンコーダと、このエンコーダが生成したビデオデータを一時的に記憶するバッファと、を備え、

データ抽出部は、上記バッファに記憶されたビデオデータ内の複数のフレームデータ間のフレームデータを間引くことによって、上記ビデオデータから負荷測定部の測定結果に基づいた数のフレームデータを抽出することを特徴とする請求項 1に記載のビデオデータ配信装置。

1 1 . ビデオデータ配信システムの負荷状態を測定する負荷測定部、複数のフレームデータを含むビデオデータから、上記負荷測定部の測定結果に応じた数のフレームデータを抽出するデータ抽出部と、このデータ抽出部が抽出したフレームデータをネットワークを介して送信する送信部と、を備えたビデオデータ配信装置、

上記ネットワークから上記ビデオデータ配信装置の送信部から送信されたフレームデ一タを受信するとともに、受信したフレームデータを再生するビデオデータ再生装置、

を備えたビデオデータ配信システム。

1 2 .負荷測定部は、ビデオデータ再生装置の動作を制御するプロセッサの負荷を測定することを特徴とする請求項 1 1に記載のビデオデータ配

1 3 . 複数のビデオデータ再生装置がネットワークに接続され、

ビデオデータ配信装置の送信部から上記ネットワーク上に送信された

1つのフレームデータは、上記複数のビデオデータ再生装置それぞれにおいて受信されることを特徴とする請求項 1 2に記載のビデオデータ配信システム。

1 4 . ビデオデータ再生装置は、それぞれデータ量が指定されたデータ転送要求を複数回ビデオデータ配信装置へ送信し、

ビデオデータ配信装置は、上記複数回のデータ転送要求を受信すると、これらのデータ転送要求それぞれに指定されたデータ量に基づいたフレ —ムデータを上記データ転送要求ごとに送信することを特徴とする請求項 1 1に記載のビデオデータ配信システム。

1 5 . ビデオデータ再生装置は、ビデオデータが指定されたデータ転送要求を送信し、

ビデオデータ配信装置は、上記データ転送要求を受信すると、上記ビデォデ一タの一部のフレームデータを有するバケツトを所定の間隔で複数送信することを特徴とする請求項 1 2に記載のビデオデータ配信システム。

1 6 . ビデオデータ配信システムの負荷に応じた送信レベルを決定する送信レベル決定ステップと、

複数のフレームデータを含むビデオデータから、上記送信レベル決定ステップにより決定された送信レベルに応じた数のフレームデータを抽出するデータ抽出ステップと、

上記データ抽出ステップにおいて抽出されたフレームデータを送信する送信ステップと、

を備えたビデオデ一タ配信方法。

1 7 . 送信レベル決定ステップは、ビデオデータ再生装置で実行され、ビデオデータ再生装置の動作を制御するプロセッサの負荷を測定する負荷測定ステップと、この負荷測定ステップの測定結果に対応した送信レベルを決定する決定ステップと、この決定ステップによって決定した送信レベルをビデオデータ再生装置からビデオデータ配信装置へ送信する送信レベル送信ステップと、を備えたことを特徴とする請求項 1 6に記載のビデオデータ配信方法。

1 8 . ビデオデ一タ再生装置が、送信ステップによって送信されたフレームデータを受信し、受信したフレームデータを再生する再生ステップを備えたことを特徴とする請求項 1 6に記載のビデオデータ配信方法。

1 9 . 送信レベル決定ステップは、ビデオデータ再生装置がビデオデータを早送り再生する場合には、ビデオデータに含まれる複数のフレームデータから一部のフレームデータを間引いたビデオデータが抽出されるように送信レベルを決定し、早送り再生しない場合には、ビデオデータのフレームデータを間引かないように送信レベルを決定することを特徴とする請求項 1 6に記載のビデオデータ配信方法。

2 0 . データ抽出ステップは、ビデオデータ再生装置が複数のフレームデータ及び音声データを含むビデオデータを早送り再生する場合には、ビデオデータから上記音声データを削除し、送信レベルに応じた数のフレ一ムデータを抽出したビデオデータを生成し、

送信ステップは、上記データ抽出ステップが生成したビデオデータを送信することを特徴とする請求項 1 6に記載のビデオデータ配信方法。