JPH08317384A - 情報処理システム - Google Patents

Abstract

(57)【要約】 【目的】ユーザの要求等を考慮し提供するデータ量の制
御を行なう装置を実現する。 【構成】動画データを記憶する記憶手段と、データ量を
データ量削減規則に従って削減するデータ量削減手段
と、削減データをクライアント側に出力する出力手段
と、動画データへのアクセス命令を受け付ける入力手段
と、データ量削減の制御を行なう制御手段と、アクセス
命令に対して削減されたデータ量の総和を演算する削減
データ量演算手段と、通信媒体ごとの出力データ量を検
出する伝送量検出手段とを有し、制御手段は、削減デー
タ量演算手段の演算結果、および、前記伝送量検出手段
の検出結果に対応して予め定めた規則に従って、データ
量削減規則を選択して、データ量削減手段を駆動し、削
減データを、出力手段に与える。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、サーバ側がクライアン
ト側にマルチメディアデータを提供するシステムに係
り、特に、各種のネットワーク環境下において、トラフ
ィック飽和させることなく、動画データをクライアント
に配信するシステムに関する。

【０００２】

【従来の技術】近年、ネットワーク環境の整備、拡張が
進展し、ローカルエリアネットワーク（ＬＡＮ）、ＩＳ
ＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉ
ｇｉｔａｌ Ｎｅｔｗｏｒｋ）、アナログ回線等の公衆
回線によって構成されるＷＡＮ（Ｗｉｄｅ Ａｒｅａ
Ｎｅｔｗｏｒｋ）等の、各種のネットワーク環境におい
て、ネットワークの接続状態を意識せずに、ネットワー
クに接続されたある端末装置から他の端末装置へと、動
画データ等のマルチメディアデータのやりとりを行なう
ことが可能になってきた。

【０００３】ところで、動画データや音声データは、基
本的にデータ量が大きいため、これまで、データの蓄
積、伝送等の処理を行なうためには、効率良くデータを
圧縮した後に、圧縮データに対して所望の処理を行なう
ことが提案されている。

【０００４】代表的な圧縮方法としては、例えば、ＩＳ
Ｏにより推奨されている「ＭＰＥＧ１（Ｍｏｖｉｎｇ
Ｐｉｃｔｕｒｅ Ｇｒｏｕｐ Ｐｈａｓｅ １）」等の
圧縮方法が挙げられる。

【０００５】しかしながら、このような圧縮処理を行な
っても、マルチメディアデータのデータ量は、通常、膨
大な量となっており、ネットワークのトラヒックの飽和
を招いたり、また、例えば、サーバからクライアントに
マルチメディアデータの伝送を行なう際には、非常に長
い伝送時間を要する等の課題が存在していた。

【０００６】この様な課題を解決する従来技術を開示し
ている文献としては、特開平６−７０１７４号公報等が
挙げられ、この公報では、動画データを離散余弦変換し
た変換データの高周波成分を削除することによって、動
画データのデータ量を削減するための技術が開示されて
いる。

【０００７】また、ネットワークの伝送帯域を、動画デ
ータ伝送のための伝送帯域に設定し、提供する動画デー
タのフレーム数を適宜低減することによって、動画デー
タの伝送レートの調整を行なって、安定した動画データ
の供給を保証するファイルサーバが提供されている。

【０００８】

【発明が解決しようとする課題】ところで、上述した従
来技術のうち、特開平６−７０１７４号公報に開示され
た技術は、動画データのみのデータ量の削減には有効で
あるもののが、一般的に動画データには、音声データが
付随しているものが多く、特に、データ量が削減された
動画データと、音声データの同期の保証については考慮
されていない。

【０００９】また、動画データのフレーム数の削減のみ
で、提供する動画データに対する伝送レートの調整を行
なっていては、変化の激しい動画像を有する動画データ
では、動きの滑らかさが失われる等の問題があり、ユー
ザの画質への要求を考慮しながらデータ量の削減を行な
う必要があった。

【００１０】また、ネットワーク環境で動画データを供
給するファイルサーバは、動画データ伝送のための伝送
帯域を確保するため、クライアント数が限られている場
合においては、安定した動画データの供給が可能である
ものの、クライアント数が所定数以上になったときに
は、その途端に、新たなクライアントに対する動画デー
タの提供が不可能になったり、既に動画データの提供を
行なっているクライアントに対する、動画データの提供
に影響が及び、クライアントへの動画データの提供が安
定して行なえなくなる事態の発生を招いてしまうという
課題が存在していた。

【００１１】そこで、本発明は、以上のような課題に鑑
みて創作したもので、サーバが提供するマルチメディア
データのデータ量を、ユーザの要求に対して提供するデ
ータの伝送レートや、サーバに接続されるネットワーク
の伝送能力等を考慮して制御し、ユーザ側に配信するこ
とによって、たとえ接続されるネットワークの伝送レー
トが低い場合であっても、適切な品質のマルチメディア
データを提供するシステムを実現することを目的とし、
また、動画でデータを提供する際には、動画データと音
声データとのと同期がとれた動画データを提供すること
も可能にする。

【００１２】

【課題を解決するための手段】上記課題を解決するた
め、以下の手段が考えられる。

【００１３】動画データを提供するサーバと、該サーバ
と通信媒体を介して接続され、動画データの提供を受け
る少なくとも１以上のクライアントとを有して構成され
る情報処理システムである。

【００１４】そして、サーバは、動画データを、１種類
以上記憶するための記憶手段と、動画データのデータ量
を、予め定められた複数のデータ量削減規則のうちのい
ずれかに従って、削減するデータ量削減手段と、接続さ
れた通信媒体を介して、削減されたデータをクライアン
ト側に出力する出力手段と、接続された通信媒体を介し
て、前記記憶手段に記憶されている、いずれかの動画デ
ータへのアクセス命令を受け付ける入力手段と、入力さ
れたアクセス命令に応じて、データ量削減のための制御
を行なう制御手段と、１以上のアクセス命令に対して削
減されたデータ量の総和を演算する削減データ量演算手
段と、通信媒体ごとの出力データ量を検出する伝送量検
出手段とを有した構成とする。

【００１５】前記制御手段は、入力手段がクライアント
からのアクセス命令を受け付けたとき、前記削減データ
量演算手段の演算結果、および、前記伝送量検出手段の
検出結果、に対応して予め定めた規則に従って、前記デ
ータ量削減規則のいずれかを選択して、前記データ量削
減手段を駆動し、削減されたデータを、前記出力手段に
与える機能を有する。

【００１６】また、以下の示すような態様も考えられ
る。

【００１７】動画データを提供するサーバと、該サーバ
と通信媒体を介して接続され、動画データの提供を受け
る少なくとも１以上のクライアントとを有して構成され
る情報処理システムである。

【００１８】そして、前記サーバは、１種類以上の元動
画データと、各元動画データに対して、そのデータ量を
予め定められた複数のデータ量削減規則に従って削減し
た複数種類の削減データとを記憶するための記憶手段
と、接続された通信媒体を介して、削減データをクライ
アント側に出力する出力手段と、接続された通信媒体を
介して、前記記憶手段に記憶されている、いずれかの元
動画データへのアクセス命令を受け付ける入力手段と、
入力されたアクセス命令に応じて、削減データを選択
し、前記出力手段に与える制御を行なう制御手段と、所
定時間内に、出力手段が出力する削除データの量の総和
演算を行なう削減データ量演算手段と、通信媒体ごとの
出力データ量を検出する伝送量検出手段とを有して構成
される。

【００１９】前記制御手段は、入力手段がクライアント
からのアクセス命令を受け付けたとき、前記削減データ
量演算手段の演算結果、および、前記伝送量検出手段の
検出結果、に対応して予め定めた規則に従って、前記削
除データのいずれかを選択して、選択した削減データ
を、前記出力手段に与える機能を有する。

【００２０】

【作用】サーバは、動画データを提供し、クライアント
は、通信媒体を介して、サーバからの動画データの提供
を受ける。

【００２１】クライアント側では、命令送出手段によっ
て、通信媒体を介してアクセス命令を命令を送る。

【００２２】一方、サーバ側は、記憶手段に、動画デー
タを１種類以上記憶しており、データ量削減手段によっ
て、動画データのデータ量を、予め定められた複数のデ
ータ量削減規則のうちのいずれかに従って削減する。

【００２３】出力手段は、通信媒体を介して、削減され
たデータをクライアント側に出力する。

【００２４】入力手段は、通信媒体を介して送られてき
た、前記記憶手段に記憶されている、いずれかの動画デ
ータへのアクセス命令を受け付け、さらに、制御手段
は、入力されたアクセス命令に応じて、データ量削減の
ための制御を行なう。

【００２５】なお、削減データ量演算手段は、１以上の
アクセス命令に対して削減されたデータ量の総和を演算
を行ない、また、伝送量検出手段は、通信媒体ごとの出
力データ量を検出する。

【００２６】そして、制御手段は、入力手段によってア
クセス命令を受け付けたとき、前記削減データ量演算手
段の演算結果、および、前記伝送量検出手段の検出結
果、に対応して予め定めた規則に従って、前記データ量
削減規則のいずれかを選択して、前記データ量削減手段
を駆動する。この結果、削減されたデータは、出力手段
に与えられ、クライアント側に送られる。

【００２７】クライアント側の表示手段は、送られてき
たデータを表示する。

【００２８】以上は、クライアントからの要求にしたが
って動画データを提供する際、サーバは、データ量削減
規則を用いて、動画データのデータ量を削減してクライ
アント側に提供する。

【００２９】また、他の態様によれば、以下のような作
用となる。

【００３０】クライアント側では、命令送出手段によっ
て、通信媒体を介してアクセス命令を命令を送る。

【００３１】一方、サーバは、記憶手段に、１種類以上
の元動画データと、各元動画データに対して、そのデー
タ量を予め定められた複数のデータ量削減規則に従って
削減した複数種類の削減データとを記憶しており、ま
た、出力手段は、通信媒体を介して、削減データをクラ
イアント側に出力する。

【００３２】入力手段は、記憶手段に記憶されている、
いずれかの元動画データへのアクセス命令を受け付け、
さらに、制御手段は、入力手段によってアクセス命令を
受け付けたとき、削減データを選択し、出力手段に与え
る制御を行なう。

【００３３】なお、削減データ量演算手段は、所定時間
内に出力手段が出力する削除データの量の総和演算を行
ない、また、伝送量検出手段は、通信媒体ごとの出力デ
ータ量を検出する。

【００３４】そして、制御手段は、入力手段によってア
クセス命令を受け付けたとき、前記削減データ量演算手
段の演算結果、および、前記伝送量検出手段の検出結
果、に対応して予め定めた規則に従って、前記削除デー
タのいずれかを選択して、選択した削減データを、前記
出力手段に与えクライアント側に送信する。

【００３５】クライアント側の表示手段は、送られてき
たデータを表示する。

【００３６】以上は、クライアントからの要求にしたが
って動画データを提供する際、サーバが、複数種類の削
除データのうちのいずれかを送信することによって、動
画データのデータ量を削減してクライアント側に提供す
る。

【００３７】以上のような動作によれば、通常ではトラ
ヒックが飽和するような動画データの転送時において
も、トラヒックの飽和を回避し、各クライアントに動画
データの提供を円滑に行なうことを可能にする。

【００３８】

【実施例】以下、本発明にかかる実施例を、図面を参照
して説明する。

【００３９】まず、本発明を、マルチメディアデータを
ネットワークを介して、少なくとも１台の端末（クライ
アント）に配信する、マルチメディアデータサーバ（以
下適宜「メディアサーバ」や「サーバ」と記す）に適用
した場合について説明する。

【００４０】第１の実施例は、サーバが、クライアント
から配信要求されたデータのデータ量を、予め定めた規
則に従って削減し、削減データを配信する実施例である
（なお、本実施例を、便宜上「ハード型」と称する）。

【００４１】図１は、第１の実施例におけるメディアサ
ーバのネットワーク環境の一例を示している。

【００４２】１ａ、１ｂは、メディアサーバ、２ａ、２
ｂ、２ｃ、２ｄは、クライアント、５ａ、５ｂは、ゲー
トウエイであり、メディアサーバ、クライアント、ゲー
トウエイは、コンピュータ端末として実現できる。ま
た、３ａ、３ｂ、３ｃは、ＬＡＮ（Ｌｏｃａｌ Ａｒｅ
ａ Ｎｅｔｗｏｒｋ）であり、さらに詳しく述べると、
ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ
Ｍｏｄｅ）−ＬＡＮ等が挙げられる。

【００４３】また、４は、ＩＳＤＮ（Ｉｎｔｅｇｒａｔ
ｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏ
ｒｋ）であるが、ＩＳＤＮの替わりに、アナログ回線等
の公衆回線や、該公衆回線と同様の伝送技術を利用した
専用回線を用いても良い。

【００４４】前述した各コンピュータ端末（単に「端
末」とも記す）は、特に、以下に述べるような機能を有
する。

【００４５】端末１ａ、１ｂは、マルチメディアデータ
を、ネットワーク３やＩＳＤＮ４を介して、複数のコン
ピュータ端末に配信する機能を有するメディアサーバで
ある。

【００４６】端末１ａは、ＬＡＮ３ａに接続され、ま
た、端末１ｂは、ＬＡＮ３ａ、３ｂ、およびＩＳＤＮ４
に接続され、該ＬＡＮ３ａ、３ｂやＩＳＤＮ４に接続さ
れた他の端末との間で、所望のデータの伝送が行なわれ
る。

【００４７】端末２ａ、２ｂ、２ｃ、および２ｄは、所
定のメディアサーバとの間で、マルチメディアデータを
含む各種のデータの伝送が可能であり、メディアサーバ
によって配信された、動画データ、音声データ等のマル
チメディアデータを受信し、受信したデータを再生する
機能を有している。なお、端末２ａは、ＬＡＮ３ａに、
端末２ｂは、ＩＳＤＮ４に、端末２ｃは、ＬＡＮ３ｃ
に、端末２ｄは、ネットワーク３ｂに、各々接続されて
おり、ＬＡＮ３やＩＳＤＮ４に接続された他の端末との
間で、所望のデータの伝送が可能である。

【００４８】端末５ａ、５ｂは、ネットワークや回線等
の伝送媒体の物理的、および、論理的な伝送方式の変換
を行い、異なる伝送方式を用いる伝送媒体間に渡るデー
タ伝送を可能とする機能を有しており、一般に、このよ
うな機能は、ゲートウェイ機能、あるいは、ブリッジ機
能と呼ばれており、このような機能を有するコンピュー
タ端末のことを「ゲートウェイ」、あるいは「ブリッ
ジ」と呼している。

【００４９】また、複数の伝送媒体に渡るデータ伝送の
経路制御を行う機能を有するという意味において、この
機能をルータ（あるいはルーティング）機能と称し、か
かる機能を有するコンピュータ端末を「ルータ」と称す
ることもある。特に、あるネットワーク３ａから他のネ
ットワーク３ｂへ、データ伝送を行なう機能は、ルータ
機能そのものである。

【００５０】このようなネットワーク環境下において、
メディアサーバ１ａおよび１ｂは、全クライアント、２
ａ、２ｂ、２ｃ、２ｄに対して、マルチメディアデータ
を配信することが可能である。

【００５１】なお、メディアサーバ１ｂは、ＩＳＤＮ
４、ＬＡＮ３ａ、３ｂに接続されており、それぞれの伝
送媒体に接続されたコンピュータ端末との間でデータの
橋渡しを行なうことが可能であるため、ゲートウェイ端
末５ａと同等の機能を有するように構成されている。

【００５２】次に、本発明の第１の実施例における、メ
ディアサーバ１（１ａ、１ｂ）のマルチメディアデータ
のデータ量削減方法、削減データの配信方法の原理につ
いて説明する。

【００５３】メディアサーバ１は、ユーザ（クライアン
ト）からの品質要求と、ＬＡＮ３やＩＳＤＮ４の伝送速
度等に起因するサービス能力を考慮して、マルチメディ
アデータのデータ量を削減処理し、削減処理されたデー
タ（以下、適宜「削減データ」と称する）のクライアン
トへの配信を行う。

【００５４】以下の説明では、配信対象となるマルチメ
ディアデータとして、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃ
ｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）方式で圧縮さ
れた圧縮動画データを例にとって説明する。

【００５５】図２は、メディアサーバ１が、ＭＰＥＧ方
式、特に、ＭＰＥＧ１方式の圧縮方式を使用して圧縮し
た圧縮動画データを配信する場合の、該圧縮動画データ
のデータ量削減方式１０の内容を示した図である。

【００５６】この図において、行方向（横方向）には、
ユーザの画質に対する品質要求の程度をとる。一例とし
て、１０では、動き、あるいは、画像の精細度の優先度
を示す。通常、動画のデータ量と画質とは、トレードオ
フの関係にあり、同じデータ量であるならば、動画の精
細度を優先する場合は、例えば、単位時間あたりのフレ
ーム数を減少させる等の処理を行なって、可能な限り動
きの滑らかさが損なわれるようにデータ量の削除を行な
わざるを得ず、逆に、動画の動きの滑らかさを優先する
場合には、例えば、１フレームの画素数を間引いて、画
像の精細度を落として、データ量の削除を行なわざるを
得ない。

【００５７】図２の１０において、列方向（縦方向）に
は、元の動画のデータ量を「１００」とした場合の、同
一動画データのデータ量をとる。即ち、該図２の１０の
下の行にいくほど、データ量は減少している。

【００５８】なお、ここでは動画データのデータ量を削
除するためのパラメータとして、「画素数、ＡＣ係数の
上限値、フレーム数」の組み合わせを採用し、１つの組
み合わせを「セル」と称している。したがって、図２中
の、１１、１２、１３、１４、１５、１６、１７は、各
々セルである。

【００５９】例えば、横軸上の中間位置に存在するセル
１１の意味するところは、元の動画データのデータ量
を、動きの滑らかさと、精細度を同程度に優先しなが
ら、そのデータ量を「５０（％）」に削減する場合の、
具体的なデータ量削減方法を示すものである。以下、各
セルに対応するデータ量削減のためのパラメータをデー
タ量削減パラメータと呼ぶ。したがって、セル１１の場
合、データ量削減パラメータは、「画素数：３５２×２
４０」、「ＡＣ係数の上限値：３〜４」、「フレーム
数：１５（ｆｐｓ）」となっている。

【００６０】データ量削減パラメータとして、図２で
は、画素数の削減、空間周波数成分の交流成分（ＡＣ成
分）上限の制限、および、１秒間のフレーム数の削減を
挙げてある。例えば、動画像の動きの滑らかさと精細度
を同程度に優先しながら（即ち、横軸の中間位置に存在
するセルを採用する）、データ量を、元データの「５０
（％）」に削減するには、元の動画データに比べて、画
素数を減らさず（同上）、ＡＣ成分の上限を３〜４個に
し、フレーム数を半分にすることにより達成されること
を示している。

【００６１】このように、セル１１に記述された複数の
パラメータを組み合わせて、すなわち、セル１１に示さ
れているデータ量削減パラメータを使用して、データ量
の削減処理を行なうことによって、データ量の制御を行
なえる。すなわち、サーバは、クライアントの要求等を
考慮しながら、あるセルを選択し、選択したセルに示さ
れた、データ量削減パラメータを使用して、データ量の
削減処理を実行し、削減データの配信を行なう。なお、
個々の削減パラメータの詳細については、後述する。

【００６２】さて、配信する動画データのデータ量の制
御は、図２の１０を用いて、次のように行う。

【００６３】まず、ユーザ（クライアント）からの配信
要求が発生した場合、メディアサーバ１では、図２の１
０を参照し、ユーザの要求と、配信（サービス）能力を
考慮したにデータ量となるように、配信時の初期データ
量削減パラメータを決定し、該パラメータに従って、配
信対象の動画データのデータ量を削減して配信を行な
う。ここで、配信（サービス）能力とは、例えば、サー
バに接続されている各通信媒体の、通信許容伝送レート
等が考えられる。ユーザの要求のみならず、サーバに接
続されている各通信媒体の、通信許容伝送レートを越え
ないことを条件として、データ量の削減処理が行なわれ
る。

【００６４】これを仮に、セル１１に示されたデータ量
削減パラメータを採用するとし、配信の途中で、ユーザ
要求が、更に動きの滑らかさを優先するように変更され
た場合には、（横軸上で右側に存在する）セル１２で示
されたデータ量削減パラメータに変更し、また、精細度
を優先するように変更された場合は、（横軸上で左側に
存在する）セル１３で示されたデータ量削減パラメータ
に変更し、それぞれ変更したパラメータを使用して、配
信対象の動画データのデータ量を削減して、削減データ
を配信する。

【００６５】また、セル１１に示されたデータ量削減パ
ラメータを使用して削減処理を行なった削除データの配
信中に、メディアサーバ１のサービス能力が低下し、更
にデータ量を削減する必要があるときには、（縦軸下方
向に存在する）セル１５に示されたデータ量削減パラメ
ータに変更し、また、サービス能力が回復して、配信デ
ータ量を増加することが可能になれば、（縦軸上方向に
存在する）セル１４に示された符号量削減パラメータに
変更し、それぞれ変更したパラメータに従って、配信対
象である動画データのデータ量を削減処理して、削減デ
ータを配信する。

【００６６】さらに、ＭＰＥＧ１動画データのデータ量
の削減方式について説明する。

【００６７】その前に、ＭＰＥＧ１方式で圧縮処理され
た圧縮動画データのフォーマットについて説明する。た
だし、ここでは本発明の説明にぜひとも必要な事項の説
明を行なうのみとする。ＭＰＥＧの符号化方式やフォー
マットについて記載されている文献は多数存在し、例え
ば、「ＡＳＣＩＩ社刊「最新ＭＰＥＧ教科書」（１１０
から１２８頁等）」に述べられている。

【００６８】図３は、ＭＰＥＧ１動画データのフォーマ
ットの説明図である。

【００６９】動画の画像データ４０は、ＭＰＥＧ１ビデ
オ符号器４１により、また、音声データ４３は、ＭＰＥ
Ｇ１オーディオ符号器４４により、それぞれ符号化さ
れ、所定サイズの圧縮動画データパケット４２と、圧縮
音声データパケット４５とにパケット化される。ＭＰＥ
Ｇ１システム復号器４６は、パケット化された動画デー
タ４２と音声データ４５とを、到着順に、パケットヘッ
ダ等の情報を付加して、ＭＰＥＧ１システムストリーム
４７として出力する。

【００７０】次に、図４に、ＭＰＥＧ１動画データのデ
ータ量削減方式の原理説明をするための図を示す。本実
施例においては、画素数を削減する方式、圧縮動画デー
タの空間周波数の高周波成分を削減する（ＡＣ係数の数
の上限値の削減）方式、および、フレーム数を削除する
方式について説明する。

【００７１】まず、ＭＰＥＧ１方式で圧縮された動画デ
ータ（ＭＰＥＧ１圧縮動画データ）のデータ構造につい
て説明する。ＭＰＥＧシステムストリーム４７から、圧
縮動画データパケット４２だけを取り出して、圧縮（再
生）順に並べると、ＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃ
ｔｕｒｅ）と呼ばれる単位（５０）に分かれており、Ｇ
ＯＰは、さらに、Ｉ（Ｉｎｔｒａ）フレーム５１、Ｐ
（Ｐｒｅｄｉｃｔｉｖｅ）フレーム５３、および、Ｂ
（Ｂｉｄｉｒｅｃｔｉｏｎａｌｌｙ ｐｒｅｄｉｃｔｉ
ｖｅ）フレーム（５２、５４）から構成される。Ｉフレ
ーム５１は、基準フレームとも称され、該フレーム内の
画素データのみを使用して、他のフレームとは独立して
符号化（フレーム内予測により符号化）するフレームで
あり、従って、伸長して再生する場合でも、他のフレー
ムのデータを必要としない。

【００７２】次に、Ｐフレーム５３は、時間的に「前」
に存在するフレームとの相関性を利用するフレーム間予
測によって、符号化するフレームであり、Ｂフレーム５
２および５４は、時間的に「前後」のフレームとの相関
性を利用するフレーム間予測によって、符号化するフレ
ームである。ＧＯＰは、少なくともＩフレームを１枚含
むフレーム群のことであり、１つのＧＯＰは、Ｉ、Ｐ、
およびＢフレームの符号化データを有して構成されてい
る。

【００７３】さらに、Ｉ、Ｐ、およびＢの各フレーム
は、元動画像データのフレームデータの垂直・水平各８
画素（全６４画素）データを単位に、離散コサイン変換
することによって得られたＤＣＴ（Ｄｉｓｃｒｅｔｅ
Ｃｏｓｉｎｅ Ｔｒａｎｓｆｏｒｍ）係数からなる、複
数のブロック５５から構成される。

【００７４】図４の左下部に記載した図は、ブロック５
５の内容をマトリクスイメージで表現したものである。
実際のＭＰＥＧ１ストリーム中には、このようなマトリ
クスの左上の成分（ＤＣ）から右下の高周波成分（ＡＣ
６３）に向かって、ジグザグにたどってシリアルに並べ
たデータを、可変長符号化したデータが存在するが、こ
のＤＣを除いた６３個のＤＣＴ係数を「ＡＣ成分」と称
する。ＡＣ成分のうちでも、ＤＣに近い左上の成分程、
画質への影響が大きい成分となる。

【００７５】なお、一般に、圧縮動画データパケット４
２の切れ目と、ＧＯＰ５０の切れ目６０は、一致しない
ことが多い。しかし、ＧＯＰの途中から圧縮動画データ
を伸長して動画再生を行うと、再生画像の乱れが生じて
しまう。そのため、本実施例における動画データ量の削
減処理は、ＧＯＰ単位で行うものとする。

【００７６】次に、図２に示したデータ量削減方式の説
明において、前述したデータ量削減の実現方式の一例を
述べる。

【００７７】まず、画素数の削減は、既に符号化された
ＭＰＥＧ１データを一旦復号し、動画像データに戻した
段階で、画素を一定間隔で間引く処理や、位置的に隣接
した画素に対するデータの加重平均を取る処理を行なう
等によって画素数を減らし、画素数を減らしたデータを
再符号化することによって実現できる。

【００７８】ＡＣ成分の上限の制限は、前記ブロック５
５中のＤＣＴ係数のうち、右下の成分（高周波成分）か
ら、削減することによって実現するが、実際には、既に
符号化されたＭＰＥＧ１データを可変長符号の段階にま
で復号し、可変長符号単位で、所望のデータ量になるよ
うにＡＣ係数を削減して、再符号化する方法や、ＤＣＴ
係数の段階まで復号化し、所望のデータ量になるように
ＡＣ係数を削減して再符号化する方法等により実現でき
る。

【００７９】フレーム数の低減を、実際にＧＯＰを構成
するフレームデータそのものを間引くことにより実現す
ると、再生時に誤動作が生じることが多い。これは、Ｍ
ＰＥＧデータの中に、その動画のフレームレート（１秒
あたりのフレーム数）のデータが存在し、該フレームレ
ートのデータと、フレーム数を間引かれた圧縮動画デー
タの間で矛盾が生じるためである。よって、フレーム数
の削減は、ＧＯＰを構成する、少なくとも１つのフレー
ムのデータ（ピクチャ層のデータ）を、少なくともピク
チャ層の「開始コード」、ピクチャの「通番」、「ピク
チャタイプ」からなるデータであって、該フレームの中
身、すなわち、圧縮された画素データを含まない、ダミ
ーデータ５６に置き換えることにより実現する。

【００８０】この方式によれば、形式上フレーム数には
変化なく、実際には、フレームに対応した圧縮動画デー
タ自体がないので、再生時には、時間的に前のフレーム
から変更がないものとみなされ、上述したような矛盾が
なく、見かけ上のフレーム数の削減が実現でき、圧縮動
画データの時間あたりの転送量も減少する。

【００８１】フレーム数の削減によって、ＭＰＥＧ１動
画データを所望のデータ量にまで削減する場合は、画質
への影響を考慮して、まず、Ｂフレーム（５２、５４）
からダミーデータ５６に置き換え、全てのＢフレームを
置き換えても目的のデータ量削減を達成できなない場合
には、Ｐフレームをダミーデータ５６に置き換え、さら
に、全てのＰフレームを置き換えても目的のデータ量削
減を達成できない場合には、さらに、Ｉフレームをダミ
ーデータ５６に置き換えるというように、段階的にダミ
ーデータ５６への置き換えを行っていく。

【００８２】このように、データ量の削減方式を示す図
２の１０を参照して、必要に応じてＭＰＥＧ動画データ
のデータ量を削減しながら、削減データを配信すること
により、ユーザの配信品質要求と、メディアサーバの配
信能力を考慮した、配信マルチメディアデータのデータ
量制御を行なうことができる。

【００８３】なお、ＭＰＥＧ方式以外の動画や、音声の
みからなるデータや、静止画等のマルチメディアデータ
においても、データ量とユーザの配信品質要求を考慮し
た削減方式を定めることは可能である。

【００８４】例えば、符号化された音声データでは、ス
テレオのデータをモノラル化する方法や、サンプリング
周波数や量子化ステップを粗くする方法等によりデータ
量を削減することが可能であり、符号化された静止画デ
ータでは、画素数を減らす方法等によりデータ量を削減
できる。また、図２の１０は、メディアサーバ１が扱う
マルチメディアデータのうち、動画、静止画等のデータ
種別ごとに予め定めておき内蔵しておく構成にする。

【００８５】以下に、以上述べてきたメディアサーバ１
によるマルチメディアデータの配信を実現する方法につ
いて説明する。なお、本実現方法の説明においても、配
信対象となるマルチメディアデータを、ＭＰＥＧ１方式
で圧縮処理された圧縮動画データを例にとり説明する。

【００８６】ＭＰＥＧ１動画データのデータ量を削減し
ながらの、削減データのクライアント２への配信は、基
本的に、次の示す方法によって行なう。

【００８７】メディアサーバ１は、配信対象となる動画
データの種類毎に、図２に示すデータ量削減基準テーブ
ルを備えていて、該基準テーブル１０に示した削減方法
にしたがって、配信条件（ユーザの要求とメディアサー
バ１のサービス能力）に、最も近いデータ量削減方法を
示すセルを決定し、該セルに対応するデータ量削減パラ
メータを用いたデータ量削減により、データ量を削減制
御しながら、削減データを配信する。仮に、配信中に配
信条件が変更されたときには、その変更された配信条件
に最も近い、データ量削減方式に切り替えて配信する。
この時、データの削減方式の切り替えは、ＧＯＰの切れ
目で行う。

【００８８】なお、配信条件は、ユーザの要求とメディ
アサーバ１のサービス能力で決定される。ユーザの要求
は、例えば、図２に示すセルを１つ選択するために、図
２の横軸方向のセル位置を決定する命令に相当し、通
常、クライアントは、コマンドを入力することによっ
て、サーバ側に、図２の横軸方向のセル位置を決定する
命令を与え、サーバがこれを受け取る。なお、サーバ
は、通常、複数のクライアントからの要求に答えるため
に、複数の削減データを、複数の通信媒体を介して、ク
ライアント側に送信している。また、当然のことなが
ら、１つのサーバが処理することができる、削減データ
のデータ量の総和には、上限値（しきい値）が存在す
る。

【００８９】また、メディアサーバ１のサービス能力と
は、メディアサーバ１に接続される各通信媒体の最大伝
送レート（しきい値）のことを意味し、サーバは、これ
を越えないように、データ量を削減したセルを選択する
（通常、前記選択されたセルの存在位置を基準として、
縦軸下方向に存在するセルを選択することになる）。

【００９０】このように、サーバは、全ての削減データ
のデータ量および各通信媒体の最大伝送レートの少なく
とも一方が、各々に対して予め定められているしきい値
を越えたとき、前記データ量削減規則のうちから、前記
削減データ量演算手段の演算結果および各通信媒体の最
大伝送レートの双方が、各々に対して予め定められてい
るしきい値を越えないように、セルを選択していき、選
択したセルに対応する削減パラメータを使用して、デー
タ削除処理を行なう情報処理システムである。

【００９１】なお、通常は、全くデータ削除処理を行な
わずに、全ての削減データのデータ量および各通信媒体
の最大伝送レートの少なくとも一方が、各々に対して予
め定められているしきい値を越えたときに始めて、優先
度の小さな順に、動画データのデータ量を削減しておく
機能を有するように、サーバを構成しても良い。なお、
このような優先度は、クライアントからサーバに与える
ものとする。

【００９２】図５は、図１で説明したコンピュータ端末
のハードウェア構成を示す構成図である。

【００９３】１０１は、端末全体を制御する中央処理装
置（ＣＰＵ）、１０２は、プログラムが動作し、データ
量削除制御用のデータを保持するテーブルを一時的に確
保する主メモリで、ＲＡＭで実現される。

【００９４】１０３は、ＣＰＵ１０１等に、一定間隔で
割込み信号や日時の情報を供給する時計装置（クロッ
ク）である。１０４は、ユーザの指示入力を取り込むた
めのマウス、１０５は、同様にユーザの指示入力を取り
込むためのキーボードである。

【００９５】１０６は、ユーザのデータを保存するため
の記憶装置であり、ハードディスク（ＨＤ）や光磁気デ
ィスク（ＭＯ）で実現される。

【００９６】１１０は、ユーザに処理結果を表示して伝
えるためのディスプレー装置、１１１は、画像情報を取
り込むためのカメラであり、これらは、画像入出力制御
装置１０８により制御される。

【００９７】１０９は、ディスプレー１１０に表示する
データを保持するメモリ（ＶＲＡＭ：Ｖｉｄｅｏ ＲＡ
Ｍ）であり、画像入出力制御装置１０８により、常に最
新の表示データが書き込まれる。１１５は、カメラ１１
１によって取り込んだ動画や静止画等の画像データの圧
縮処理および伸長処理を行う画像コーディックである。

【００９８】１１３は、音声情報を取り込むマイク、１
１４は、音声情報をユーザに伝えるスピーカであり、こ
れらは、音声入出力制御装置１１２によって制御され
る。

【００９９】１１６は、マイク１１３によって取り込ん
だ音声データの圧縮処理および伸長処理を行う音声コー
ディックである。１０７は、ＬＡＮ３に端末を接続する
ためのネットワーク接続制御装置（ＬＡＮボード）であ
る。

【０１００】１１８は、ＩＳＤＮ４に端末を接続するた
めのモデム等の回線接続制御装置である。１２０は、デ
ィジタルシグナルプロセッサ（ＤＳＰ）であり、特定の
処理を行うマイクロプログラムを、記憶装置１０６から
ロードし、ＣＰＵ１０１と独立して高速に、ロードした
マイクロプログラムを実行する。このようなマイクロプ
ログラムは、通常、記憶装置１０６等に予め記憶してお
き、必要に応じてＤＳＰ１２０がマイクロをロードして
実行する。

【０１０１】またＣＰＵ１０１は、ＤＳＰ１２０に、デ
ータやそのデータに関する処理内容の情報を与えて、特
定の処理の実行を依頼し、ＤＳＰ１２０が、特定の処理
を実行した後、その処理結果を受け取ることによって、
端末処理全体での処理速度を向上することを可能とす
る。なお、ＤＳＰ１２０が行う特定の処理として、主な
ものに、画像、音声データの圧縮、伸長処理や、ネット
ワークや回線との接続制御処理等が挙げられる。これら
の処理のうち、例えば、画像や音声データの圧縮処理等
は、処理を行うプログラムを主メモリ１０２上に、ＣＰ
Ｕ１０１がロードして、ＣＰＵ１０１が、ロードしたプ
ログラムを実行することによっても実行可能であり、ま
た、画像コーディック１１５や音声コーディック１１６
等の専用ハードウェアに対して、ＣＰＵ１０１が、処理
を行なうことを依頼し、処理が実行されるようにしても
よい。

【０１０２】本実施例においては、後述するユーザ配信
タスク５００ａが、動画データのＧＯＰや音声データの
ＡＡＵ（これについては後述する）を主メモリ１０２上
にロードし、前述のデータ量削減処理を行なうマイクロ
プログラムをＤＳＰ１２０にロードし、ＤＳＰ１２０
が、該マイクロプログラムを実行することによって、動
画データや音声データのデータ量の削減を行なうか、あ
るいは、主メモリ１０２上に、予め記憶装置１０６に記
憶している、前述したデータ量の削減処理を行なうプロ
グラムをロードし、ＣＰＵ１０１により、動画データや
音声データのデータ量の削減処理を行なうものとする。
この時発生する動画、音声の、デコード処理、エンコー
ドの処理には、画像コーディック１１５、音声コーディ
ック１１６を使用して、各々の処理を行なわせるように
してもよい。

【０１０３】１１７は、各装置を接続し、装置間相互で
のデータのやり取りを行なうことを可能にするためのバ
スである。

【０１０４】なお、図１を参照して説明したコンピュー
タ端末において、全ての端末に必須な構成要素は、ＣＰ
Ｕ１０１、主メモリ１０２、クロック１０３、記憶装置
１０６、およびバス１１７であり、その他の装置は、端
末に必要な機能を考慮して、必要に応じて搭載するよう
に構成すればよい。

【０１０５】なお、本実施例において、以下に詳細に説
明するメディアサーバ１では、マウス１０４、キーボー
ド１０５、ＬＡＮボード１０７、モデム１１８、ディス
プレイ１１０、画像入出力制御装置１０８、ＶＲＡＭ１
０９、および、ＤＳＰ１２０が、少なくとも必要にな
る。

【０１０６】一方、クライアント２では、マウス１０
４、キーボード１０５、ＬＡＮボード１０７、モデム１
１８、ディスプレイ１１０、画像入出力制御装置１０
８、画像コーディック１１５、ＶＲＡＭ１０９、スピー
カ１１４、音声入出力制御装置１１２、音声コーディッ
ク１１６、および、ＤＳＰ１２０が、少なくとも必要に
なる。

【０１０７】図６は、本発明にかかる第１の実施例にお
ける、メディアサーバ１とクライアント２のソフトウェ
ア構成を示す図、即ち、機能ブロック図である。

【０１０８】まず、図６の（ａ）を参照して、メディア
サーバ１のソフトウェア構成について説明する。

【０１０９】２００ａは、メディアサーバ１の基本シス
テムソフトウェア、あるいは、オペーレティングシステ
ム（以下「ＯＳ」と記す）と称されるマルチタスクＯＳ
であり、メディアサーバ１上で動作するソフトウェアへ
のＣＰＵ１０１の機能の割当て管理、図５を参照して説
明した各ハードウェア装置資源の管理、メモリ１０２の
論理的な使用単位での管理、ソフトウェアおよびハード
ウェアの処理実行のスケジューリング等を行なうための
ソフトウエアであり、いわゆるマルチタスク処理を行な
う。マルチタスクＯＳ２００ａは、通常、ＬＡＮ３やＩ
ＳＤＮ４を介して、他の端末とデータ通信を行う際の通
信手順の制御等を行うためのプロトコル処理部２１０ａ
や、記憶装置１０６の動作制御や記憶装置１０６に格納
するデータのファイル管理を行うファイルシステム２２
０ａを含んで構成される。

【０１１０】３００ａは、メディアサーバ１において動
作するソフトウェアの実行単位で、メディアサーバ１上
に複数存在し、一般に、タスク（あるいは、プロセス）
と称されるものである。なお、以下に述べる４００ａ〜
７００ａも、タスク（あるいはプロセス）であり、マル
チタスクＯＳ２００ａ側から見た扱い方は、３００ａに
対するのと同様である。複数存在するタスク３００ａ
は、マルチタスクＯＳ２００ａにより生成され、ユーザ
やマルチタスクＯＳ２００ａによって、個々に指定され
た優先度に基づき、実行順序を決定や、ハードウェア資
源へのアクセス等の調整を行なうことにより、中断、実
行待ち、終了等の実行状態になるように管理される。

【０１１１】以下に述べるメディアサーバ１において、
マルチタスクＯＳ２００ａは、ＬＡＮ３からのデータの
着信、ユーザの入力装置１０５等を介した入力、記憶装
置１０６の処理終了等の、イベントに伴うＣＰＵ１０１
への割込みに対し、即座に優先度に基づき、タスク３０
０ａの実行順序の変更を行う、リアルタイム性を有した
マルチタスクＯＳである。

【０１１２】本実施例においては、特に、マルチタスク
ＯＳ２００ａは、タスク間での情報（メッセージ）伝達
の支援、ＬＡＮ３、ＩＳＤＮ４から送られてきたメッセ
ージをプロトコル処理部２１０ａによる処理を介してタ
スクへ伝達する等の、異なるネットワークや回線に渡る
タスク間通信支援機能を有し、また、マウス１０４、キ
ーボード１０５等の入力装置を介してユーザが入力した
入力内容を、必要に応じてタスクに伝達したり、タスク
のデータ出力要求を受け付けて画像入出力制御装置１０
８を制御し、ディスプレー１１０に、要求に適合したデ
ータを表示する等の、入出力制御機能も有している。

【０１１３】４００ａは、クライアント２からのマルチ
メディアデータ配信要求を受け付け、ユーザ配信処理タ
スク５００ａに配信要求を発したクライアント２への、
データの配信処理を依頼する、配信スケジューラタスク
である。また、ユーザ配信処理タスク５００ａは、マル
チタスクＯＳ２００ａにより、ユーザからの配信要求の
件数分だけ生成されるが、一般にＯＳが扱うことが可能
なタスク数は、ハードウェアの仕様等によって制限され
ており、そのような制限数を超える場合には、配信を行
わない。なお、配信スケジューラタスク４００ａの具体
的な処理内容については後述する。

【０１１４】５００ａは、要求を発したクライアントに
対して、マルチメディアデータの配信を行うユーザ配信
処理タスクであり、該タスクは、ユーザの指定したサー
ビス品質と、メディアサーバ１の処理負荷やＬＡＮ３、
ＩＳＤＮ４の伝送能力を考慮して、サービスするデータ
の品質を制御する、すなわち、データ量削減パラメータ
を定め、データ量の削減制御を行なう。

【０１１５】該制御は、例えば、ユーザの品質要求があ
るレベル以上であるときや、メディアサーバのサービス
能力が高くないときに（配信データに対して、通信媒体
の伝送能力が小さなとき）、配信するオリジナルのマル
チメディアデータのデータ量を削減して配信することに
より実現する。ユーザの指定したサービス品質に関する
情報（即ち、図２の１０において、セルの横軸方向の位
置を定める情報）は、配信スケジューラタスク４００ａ
により、また、メディアサーバ１の処理負荷やＬＡＮ
３、ＩＳＤＮ４の伝送能力等の、メディアサーバ１のサ
ービス能力に関する情報は、サービス品質管理タスク６
００ａにより、それぞれ取得する。該タスク５００ａに
よるデータ量制御の具体的な方法については、後述す
る。

【０１１６】６００ａは、メディアサーバ１の処理負荷
やＬＡＮ３、ＩＳＤＮ４の通信品質等、メディアサーバ
１のサービス能力に関する情報に基づき、配信のサービ
ス品質の決定、および、ユーザ配信処理タスク５００ａ
等に、サービス品質の情報を提供するサービス品質管理
タスクである。なお、公知となっているＯＳには、ＣＰ
Ｕ１０１の処理負荷を逐次、数値で評価して、各タスク
に通知する機能を有するものがある。また、ＬＡＮ３に
流れるデータパケットの流量を監視することにより、Ｌ
ＡＮ３中のデータの混雑の程度を数量的に評価し、各タ
スクに通知する機能を有するソフトウェアもある。ま
た、サービスするマルチメディアデータの転送レート
を、メディアサーバ１が、該データごとの情報として予
め有し、メディアサーバ１が、クライアント２に配信中
のデータの種類と、各転送レートの情報とを参照して、
自ら配信能力を数量的に評価して、各タスクに通知する
機能を有するように構成することも考えられる。このよ
うに、６００ａが提供するサービス能力の情報は、メデ
ィアサーバ１が自ら検知するか、クライアント２からの
データ要求のような外部からの情報を用いて検知した、
サービス能力を数量的に表現したものとし、特に、後者
の検知方法の実現例については、後述する。また数量的
に表現されたサービス能力値の伝達は、主メモリ１０２
の上の特定の領域を情報伝達用に割当て、該領域を、タ
スク３００ａ乃至７００ａが共有することによって実現
される。

【０１１７】７００ａは、配信するオリジナルのマルチ
メディアデータのデータ量を、高速に削減処理して配信
を容易にするようにデータを整形する、配信データ整形
タスクである。なお、該タスク７００ａの具体的な処理
内容については、後述する。

【０１１８】次に、図６（ｂ）を参照して、クライアン
ト２のソフトウェア構成について説明する。

【０１１９】８００ａは、クライアント２のＯＳであ
り、機能的には、メディアサーバ１のＯＳ２００と同様
である。また、ＯＳ８００ａは、マルチタスク２００ａ
と同様に、通信制御等を行うプロトコル処理部８１０ａ
や、ファイルシステム８２０ａを有して構成される。

【０１２０】９００ａおよび１０００ａは、ＯＳ８００
ａ上で動作するタスクである。

【０１２１】９００ａは、ユーザの指示により起動さ
れ、ユーザの必要とするマルチメディアデータの名称、
および、配信時のサービス品質等の要求を取り込み、こ
れらの情報をメディアサーバ１に、ＬＡＮ３やＩＳＤＮ
４等を介して伝送し、また、配信されてきたデータを受
信する、メディア要求処理タスクである。該タスク９０
０ａの具体的な処理内容については、後述する。

【０１２２】１０００ａは、メディア要求タスク９００
ａが受信した動画、静止画、音声等を有するマルチメデ
ィアデータを再生する、マルチメディアデータ再生タス
クである。該タスク１０００ａは、メディア要求タスク
９００ａが、マルチメディアデータを全て受信終了して
から、該データの再生を開始するようにしても良いし、
全ての受信処理を完了する前に、受信したデータを逐次
再生するようにしても良い。特に、動画等の再生では、
時間的制約条件が課される場合があり、このような場合
には、後者のような再生方法を採用すれば良い。また、
該タスク１０００ａが行なう処理は、画像コーディック
１１５や音声コーディック１１６のような専用ハードウ
ェアによって実行されても良いし、ＤＳＰ１２０による
マイクロプログラムの実行やＣＰＵ１０１による主メモ
リ１０２上のソフトウェアの実行によって、行なわれて
も良い。

【０１２３】次に、本発明にかかる第１の実施例におけ
る、メディアサーバ１の有する制御テーブルやデータ構
造について説明する。

【０１２４】メディアサーバ１では、図２の１０に示す
テーブルと、図７に示す各制御テーブルを、主メモリ１
０２上に格納し、少なくとも、マルチタスクＯＳ２００
ａ、配信スケジューラタスク４００ａ、ユーザ配信処理
タスク５００ａ、サービス品質管理タスク６００ａ、お
よび、配信データ整形タスク７００ａが参照可能な、ア
ドレス上に確保する。以下、図７に示す各制御テーブル
について説明する。

【０１２５】２９９９は、配信するＭＰＥＧ１データの
元データである。後に詳しく説明する配信データ整形タ
スク７００ａでは、元データ２９９９から、データ量の
削減を行ないやすいように整形したデータ３０００（以
下、整形済みの元データと記す）と、データ量削減時
に、削減処理対象のＧＯＰの先頭からのバイト数と該Ｇ
ＯＰのサイズを、ＧＯＰごとに記述した、データ３００
０に対応するＩＮＤＥＸデータ２０３０を生成する。

【０１２６】当然のことながら、メディアサーバ１に
は、複数種類の整形済み元データ３０００が存在し、Ｉ
ＮＤＥＸデータ２０３０も、整形済み元データ３０００
と一意に対応して複数存在する。ＩＮＤＥＸデータ２０
３０の内容については、後述する。

【０１２７】２０００ａ、ｂは、配信条件テーブルであ
り、これは配信スケジューラタスク４００ａにより、前
述したユーザ配信処理タスク５００ａ（図７の５００
ｃ、ｄ）と一意的に対応付けられて生成される、ユーザ
への配信条件に関する情報を記述したテーブルである。
ユーザ配信処理タスク５００ａと同様に、配信条件テー
ブル２０００も、配信件数分だけ存在し、１つのテーブ
ル２０００には、少なくとも、ファイル名２００１、
（サービス）品質２００２、（転送）状態２００３、お
よび（配信条件）変更フラグ２００４の各データの内容
が記述されている。

【０１２８】該テーブル２０００は、配信スケジューラ
タスク４００ａにより生成された後は、必要に応じてサ
ービス品質管理タスク６００ａにより、その内容が変更
される。

【０１２９】ファイル名２００１は、配信する整形済み
の元データ３０００を指定するための識別子である。

【０１３０】品質２００２は、ユーザに提供する動画の
品質に関するデータであるが、図２の１０に示す各セル
のうち、現在配信中の動画データのデータ量制御方式に
対応したセルに記述された、データ量制御パラメータが
記憶保持されている。

【０１３１】状態２００３は、最新のデータの配信状態
を表すデータであり、例えば、データの転送中には「転
送中」と、ユーザのポーズ要求により配信が一時的に停
止している場合は、「待ち」と、記憶される。

【０１３２】変更フラグ２００４が示すフラグは、該テ
ーブル２０００が、配信スケジューラタスク４００ａに
より新規に生成されたとき、および、サービス品質管理
タスク６００ａによりその内容が変更されたときに、
「変更あり」を示すように設定される。また、該フラグ
２００４は、ユーザ配信処理タスク５００ａが、２００
４を参照したときに、「変更なし」を示すように設定さ
れる。

【０１３３】２０１０は、メディアサーバ１がユーザへ
のサービス能力を管理するためのデータを保持する配信
管理テーブルである。該テーブル２０１０は、メディア
の配信要求ごとに、少なくとも、要求したクライアント
のクライアントＩＤ２０１２、配信の優先度２０１３、
メディア種別２０１４、メディアの転送レート２０１
５、配信処理の状態２０１６等の情報を保持する配信状
況レコード２０１１（図７では、３つのクライアント毎
に、２０１１ａ、２０１１ｂ、２０１１ｃとしている）
を情報として持っている。

【０１３４】さらに、２０１０は、メディアサーバ１に
接続している通信媒体ごとに、転送中のデータの転送レ
ートの最新の合計値を常に保持する、ネットワーク別転
送レート合計レコード２０２０、および、メディアサー
バ１が転送中のデータの転送レートの最新の合計値を常
に保持する、サービス転送レート合計レコード２０２５
を、情報として持っている。

【０１３５】配信状況レコード２０１１は、ユーザから
の配信要求があったときに、配信が可能であれば追加さ
れ、ユーザ配信処理タスク５００ａに一意に対応して存
在する。さらに、レコード２０１１中の各情報の設定方
法等について説明する。

【０１３６】クライアントＩＤ２０１２は、ネットワー
ク上でのクライアントの論理アドレス（例えば、ＩＰア
ドレス等）に一意に対応する識別子であり、他に、メデ
ィアサーバ１へのユーザアカウント等を使用することも
可能である。優先度２０１３は、メディアサーバ１にお
ける各配信処理の優先度を数値で表したものであり、ク
ライアント２が、配信要求時に指定するのが一般的であ
るが、メディアサーバ１が、予めクライアントＩＤ毎に
定めておいた優先度を使用するようにしてもよい。メデ
ィア種別２０１４は、動画、静止画と言った、配信中の
メディアの種類の識別子であり、配信データのファイル
名２００１と同一の情報を用いれば良い。

【０１３７】転送レート２０１５は、配信するデータ毎
の転送レート値であり、このデータは、後述するＩＮＤ
ＥＸデータ２０３０中のデータと同一のものである。削
除処理され、配信されるデータのデータ量に一意に対応
して、該転送レート２０１５が定まるため、転送レート
２０１５は、見方によっては、データ量であるともいえ
る。

【０１３８】状態２０１６は、前記配信条件テーブル２
０００の状態２００３と同一のデータであり、最新のデ
ータの配信状態を表す、「転送中」、「待ち」等の情報
が記憶される。２０１２〜２０１６は、配信開始時に、
サービス品質管理タスク６００ａによって、新規にレコ
ード２０１１が追加される時点で設定され、以後、ユー
ザの新たな配信要求の追加や配信条件の変更に伴って、
２０１２〜２０１６の内容は、追加、変更される。な
お、かかる変更処理の内容については、後に、サービス
品質管理タスク６００ａの処理の説明部分において述べ
る。

【０１３９】次に、ネットワーク別転送レート合計レコ
ード２０２０は、ユーザからの新規配信要求の追加時や
配信要求の変更時に、サービス品質管理タスク６００ａ
により更新される情報であり、該タスク６００ａは、複
数のＬＡＮやＩＳＤＮ（ＷＡＮ）４のような、サーバ１
に接続される通信媒体（以後「ネットワークセグメン
ト」と称す）ごとに、配信処理中のデータの転送レート
の合計を計算した値を設定する。この時、タスク６００
ａは、転送状態２０１６を参照して、転送中のレコード
２０１１を見つけ出し、クライアントＩＤ２０１２を手
がかりに、ネットワークセグメントを特定し、ネットワ
ークセグメント毎に転送レート２０１５を合計する。全
てのネットワークセグメント毎に転送レートを計算し、
それぞれレコード２０２０の中のデータ２０２１、２０
２３として設定する。

【０１４０】ネットワークセグメントとは、物理的なネ
ットワークの単位のことであり、例えば、メディアサー
バ１にＬＡＮボード１０７を複数装備し、かつ、それぞ
れのＬＡＮボードからアクセス可能なＬＡＮ３が異なる
場合、メディアサーバ１は、異なるネットワークセグメ
ントにアクセスしているとする。

【０１４１】なお、ネットワークセグメント毎に使用可
能な転送レート（伝送帯域２０２２）は、予め定められ
ており、この情報は、新規に配信を開始するか否かを決
定する場合に使用する。すなわち、セグメント毎に、許
容可能な転送レートの上限値が、伝送帯域２０２２によ
ってて定められており、いずれかのセグメントにおい
て、その転送レートが伝送帯域を越えるような場合に
は、越えないように、データ量の削減処理が行なわれる
ことになる。

【０１４２】サービス転送レート合計レコード２０２５
は、ユーザからの新規配信要求の追加時や配信要求の変
更時に、サービス品質管理タスク６００ａにより更新さ
れる情報であり、該タスク６００ａは、メディアサーバ
１が配信処理中のデータの転送レートの合計を計算し
て、２０２７に設定する。この時、該タスク６００ａ
は、状態２０１６を参照して、転送中のレコード２０１
１を見つけ出し、該レコードについての転送レート２０
１５を合計する。レコード２０２５には、メディアサー
バ１が備えるバス１１７が、データ配信可能な転送レー
トの上限値（伝送帯域２０２６）を予め決めておき、こ
の値を参照して、新規にデータ配信を開始するか否かを
決定する場合に使用する。

【０１４３】すなわち、サーバが扱うことが可能なマル
チメディアデータに対する転送レートの合計の上限値
（２０２７）を、伝送帯域２０２６によって定めてお
り、転送レート２０２７が、この伝送帯域２０２６を越
えるような場合には、越えないように、データ量の削減
処理が行なわれることになる。

【０１４４】次にＩＮＤＥＸデータ２０３０について、
説明する。本実施例においては、配信対象の動画データ
毎に、図２のテーブル１０と同様のテーブルを、メディ
アサーバ１に備えており、該テーブル１０の各セルで示
された削減方式に従って、前述したように、ユーザが与
えるユーザ要求と、伝送能力で定まるサービス要求を考
慮した、データ量削減方式を示すセルを決定し、データ
量を削減制御しながらデータを配信し、配信中に配信条
件が変更されたときには、その変更された配信条件に最
も近い（例えば、現在のセル位置を基準とした時、特定
方向に隣接するセルで示される）データ量削減方式に切
り替えて配信するが、この時、実際のＭＰＥＧ１データ
の構成上、次のような問題点がある。

【０１４５】図８には、ＭＰＥＧ１動画および音声デー
タのフォーマットと、動画および音声データパケット構
成の関係を示す。動画データのパケットとは、前述のよ
うに動画の符号化器４１が符号化しパケット化する際、
一定のサイズに区切った単位であり、図に示すように、
動画のＧＯＰ５０の切れ目（６０）と、該パケットの切
れ目は一致しない場合が多い。また、音声についても、
ＧＯＰと同様に、再生時の単位としてＡＡＵ（Ａｕｄｉ
ｏ Ａｃｃｅｓｓ Ｕｎｉｔ）５１（５１ａ等）がある
が、音声の符号化器４５が符号化しパケット化する際、
一定のサイズに区切った単位である音声データのパケッ
ト４４と、ＡＡＵ５１の切れ目（６１）とは一致しない
場合が多い。さらに、音声も、ＡＡＵの途中から再生す
ると正常に再生されない。よって、動画は、ＧＯＰの境
界から、音声はＡＡＵの境界から再生できるようにする
必要がある。

【０１４６】しかしながら、一般のＭＰＥＧシステムス
トリーム４７は、前述したように、圧縮動画データパケ
ット４２および圧縮音声データパケット４４の単位で、
多重化されており、ＧＯＰやＡＡＵの単位では多重化さ
れていない。これは、従来ＭＰＥＧ１のデータが、１つ
のコンピュータ端末内で、ハードディスク等の記憶装置
から読みだされ、バスを介してデコーダへ転送され、さ
らに、デコードされてディスプレイに表示するという、
使用環境を想定しているためである。即ち、バスやネッ
トワークにおけるデータの伝送は、データをパケット化
して行なわれるが、一般に、ネットワークよりバスの方
が、データ伝送の信頼性が高く、伝送速度が高速であ
り、パケットが欠落したり、パケットの到着順が狂った
り、伝送遅延が発生することが、比較的少ない。またデ
コーダも、ＧＯＰ、ＡＡＵのように、意味のある単位で
デコードするため、伝送されて来るＭＰＥＧ圧縮データ
を、一旦格納するためのメモリバッファが必要となる
が、該メモリバッファを構成するＲＡＭは、高価である
ため、あまり大きなパケットで伝送すると、大容量のメ
モリバッファを必要とし、デコーダが高価になる。

【０１４７】以上のような理由から、音声も動画もエン
コードしたデータ順に、固定長にし、比較的小さなサイ
ズでパケット化し、次々に、パケットを多重化していく
方法が採用されてきた。しかしながら、ＭＰＥＧ１デー
タもネットワークや回線を介して伝送することは一般的
になりつつあり、ＲＡＭの容量あたりの価格も低下し続
けている。

【０１４８】このため、ネットワークや回線の伝送速度
等に適応してデータ量を制御しながら、既圧縮のＭＰＥ
Ｇ１等の動画データを配信するには、一般的なシステム
ストリーム４７のままでは、動画および音声データのデ
ータ量の削減処理が複雑になることや、動画と音声の同
期がとれなくなるといった危険性がある。

【０１４９】したがって、まず、図９に示すように、Ｇ
ＯＰ５０ａと時間的に対応するＡＡＵ５１ａ、５１ｂ、
５１ｃ、５１ｄを、一まとめにし（７０ａ）、これを再
パケット化するＭＰＥＧ１データ整形を行い、図２のテ
ーブル１０のセルで示される削減方法に従って、データ
量の削減を、高速かつ容易に行なえるようにすることが
必要である。

【０１５０】次に、図１０に、前記手順で整形した元デ
ータ３０００と、ＩＮＤＥＸデータ２０３０の構成を示
す。配信する動画データのデータ量制御を実現するに
は、７０ａ、７０ｂ等の、ＧＯＰと対応するＡＡＵとの
組み合わせを、１つのデータ単位とし、該単位の切れ目
で、データ量削減方式を切り替える。即ち、データ量削
方式を示すテーブル１０にある、データ量削減のための
パラメータを変更する。

【０１５１】そのため、まず、前述のＩＮＤＥＸデータ
２０３０には、データ３０００の本来の転送レート２０
３１、および、単位７０（７０ａ、７０ｂ、７０ｃ、７
０ｄ、７０ｅ）毎の、データ３０００の先頭からのサイ
ズ（Ｓｅｅｋサイズ）２０３２（Ａ１、Ａ２、Ａ３、Ａ
４、Ａ５）と、各単位自体のサイズ（Ｒｅａｄサイズ）
２０３３（ａ１、ａ２、ａ３、ａ４、ａ５）を格納して
おく。

【０１５２】ＩＮＤＥＸデータ２０３０の生成は、元デ
ータの整形処理と同時に、あるいは、並行して行なうこ
とが可能であり、効率的でもある。

【０１５３】配信するデータのデータ量制御方式を切り
換える場合には、常にＩＮＤＥＸデータ２０３０を参照
し、単位７０を一括して同一のデータ量削減方式で削除
処理し、該削減処理が終了すると、データ量削減方式の
変更の必要性を判定し、変更の必要があれば、次の単位
を、変更したデータ量削減方式を使用して、一括して削
減処理を行なう。

【０１５４】以上述べてきたように、元データの整形を
行ない、ＩＮＤＥＸデータ２０３０を利用することによ
り、配信動画の再生に乱れを発生させず、効率良くデー
タ量の制御を行ないながら、削除データの配信が可能に
なる。

【０１５５】また、ユーザから、動画の飛ばし見や、ブ
ラウジングなどによる検索等の配信要求があった場合に
は、前記単位を、所定間隔で選択していき、選択した単
位を、ユーザに配信することが実現できるため、元デー
タの整形、ＩＮＤＥＸデータ２０３０の利用は、飛ばし
見や、早送り再生（順方向及び逆方向）の実現も可能と
する。なお、これらの特定の要求に対しては、図２の特
定のセルを採用するように、予め定めておけば良い。

【０１５６】さらに、ＩＮＤＥＸデータ２０３０に、Ｇ
ＯＰと対応するＡＡＵをまとめた一つのデータの単位７
０ごとに、該単位内での動きの大きさや精細度等を数量
的に評価し、それぞれデータ２０３４、データ２０３５
として保持することにより、ユーザの要求がなくとも、
サーバが自動的に動画データの削除を行なうことが可能
となる。

【０１５７】即ち、精細度２０３５に比べて、動き２０
３４の大きな単位７０においては、動画の高周波成分を
削減して、空間的解像度を落とし、動き２０３４に比べ
て精細度２０３５の大きい単位７０においては、動画の
フレーム数を削減して時間的解像度を落とし、動き２０
３４及び精細度２０３５が同程度の場合には、空間的及
び時間的解像度を同程度に落とすことにより、データ量
削減処理を行なう。

【０１５８】具体的には、２０３４と２０３５のデータ
の組に対して、予めセルを対応させておき、サーバは、
２０３４と２０３５のデータで定まるセルが示す、デー
タ量削除方式を採用して、データ削除処理を自動的に行
なう。この場合、接続される通信媒体の伝送能力を考慮
した、セルの定め方をしておけばよい。

【０１５９】なお、サーバがユーザの要求が発生してい
ても自動的にセルの選択を行なうシステム構成にするか
否かにかかわらず、サーバに接続される通信媒体を、伝
送速度６４（ｋｂｉｔ／秒）のＩＳＤＮ回線で構成した
場合には、データ量削減方式として、画素数を、縦１２
０画素、横１７６画素とする、セルを用意しておき、該
セルを選択するようにすればよい。また、前記通信媒体
を、伝送速度１４．４（ｋｂｉｔ／秒）のアナログ回線
で構成した場合には、データ量削減方式として、画素数
を、縦６０画素、横８８画素とする、セルを用意してお
き、該セルを選択するようにすればよい。

【０１６０】さて、前述の２０３４、２０３５は、サー
バが自ら定めるデータであるが、動きの大きさの評価
は、元データの整形を行なう際に、単位７０を構成する
フレームデータに存在する動きベクトルの大きさに基づ
いて行なう。即ち、例えば、単位７０のデータの動きベ
クトルの合計値を求め、この値を参照して、予め定めた
基準値の何倍になるかで、動きの大きさの値を決定す
る。なお、このような基準値は、コンピュータ実験等に
より、予め定めておけば良い。

【０１６１】一方、精細度の評価は、元データの整形を
行なう際に、単位７０を構成するフレームデータにＤＣ
Ｔ変換したデータの高周波成分の大きさに基づいて行な
う。

【０１６２】即ち、例えば、単位７０のＩフレームの高
周波成分値を、予め定めた基準値の何倍になるかで、精
細度の値を決定する。なお、このような基準値は、コン
ピュータ実験等により、予め定めておけば良い。

【０１６３】以上述べてきたサーバ１とクライアント２
の間で、データ量の削減処理を行ないながら、ＭＰＥＧ
１動画データを配信する、各タスクの処理内容につい
て、以下説明する。

【０１６４】まず、本発明にかかる第１の実施例におけ
る、メディアサーバ１の配信スケジューラタスク４００
ａの処理内容について説明する。

【０１６５】図１１は、配信スケジューラタスク４００
ａの処理内容を示すフローチャートである。

【０１６６】配信スケジューラタスク４００ａは、ユー
ザが、メディアサーバ１の入力装置１０５からの起動指
示入力や、ＬＡＮ３やＩＳＤＮ４を介した、クライアン
ト２からの起動要求メッセージデータを、マルチタスク
ＯＳ２００ａが受け取ったときに、マルチタスクＯＳ２
００ａによって起動される。

【０１６７】まず、ステップ４０１において、サービス
品質管理タスク６００ａを起動し、次に、ステップ４０
２において、ＬＡＮ３やＩＳＤＮ４を介したクライアン
ト２からのマルチメディアデータ配信要求や、サービス
内容の変更要求のメッセージデータ、ユーザのメディア
サーバ１の入力装置１０５からの指示入力等を受け付け
る。

【０１６８】次に、ステップ４０３では、前記メッセー
ジおよび指示入力等の内容を判定し、ユーザからの新た
なマルチメディアデータの配信要求であれば（新規）、
ステップ４１１に進み、また、画質等のサービス品質の
変更、動画の場合の早送り再生開始、ポーズ等、サービ
ス内容の変更要求であれば（変更）、ステップ４２１に
進み、さらに、終了指示入力であれば、ステップ４３１
に進む。

【０１６９】なお、新規な配信要求および変更要求を伝
えるメッセージデータの内容は、配信、変更の対象とな
るマルチメディアデータの識別名称と要求品質とからな
り、これらは、ＬＡＮ３やＩＳＤＮ４を介してクライア
ント２からメディアサーバのマルチタスクＯＳ２００ａ
に渡され、さらに、マルチタスクＯＳ２００ａによっ
て、配信スケジューラタスク４００ａに渡される。

【０１７０】次に、ステップ４１１では、サービス品質
管理タスク６００ａに、ユーザの指定通りの要求品質で
の新規配信が可能か否かを問い合わせ、配信可能であれ
ば、ステップ４１３に進み、配信不可能であればステッ
プ４１４に進む（ステップ４１２）。

【０１７１】次に、ステップ４１３では、新たなユーザ
配信処理タスク５００ａと配信条件テーブル２０００と
の生成を、マルチタスクＯＳ２００ａに要求し、メモリ
１０２の容量不足や予め設定された総タスク数を超える
などの要因により、タスク５００ａあるいはテーブル２
０００のいずれかの生成が不可能な場合には、（ステッ
プ４１５）ステップ４１４に進み、一方、可能な場合に
はステップ４０２に進む。また、ステップ４１４では、
配信要求のあったクライアント２に、メディアサーバ１
が配信不可能である旨のメッセージを送信し、ステップ
４０２に進む。

【０１７２】また、ステップ４２１では、サービス品質
管理タスク６００ａに、ユーザの指定通りのサービス内
容の変更が可能であるか否かを問い合わせ、変更対象の
ユーザ配信処理タスク５００ａが既に消滅していると
か、メディアサーバ１のサービス能力の限度を超える等
の要因により、タスク５００ａへの通知が不可能な場合
は、ステップ４２３に進み、一方、可能な場合には、ス
テップ４０２に進む。

【０１７３】そして、ステップ４２３では、変更要求の
あったクライアント２に、メディアサーバ１が、サービ
ス内容の変更が不可能である旨のメッセージを送信し、
ステップ４０２に進む。

【０１７４】最後に、ステップ４３１では、サービス品
質管理タスク６００ａおよび配信スケジューラ４００ａ
が生成した全てのユーザ配信処理タスク５００ａに、配
信処理の終了を指示するメッセージを与えた後、配信ス
ケジューラタスク４００ａが使用しているハードウェア
資源等を開放することにより、配信スケジューラタスク
４００ａが行なう処理を終了する。

【０１７５】次に、本発明にかかる第１の実施例におけ
る、メディアサーバ１のユーザ配信処理タスク５００ａ
が行なう処理内容について説明する。

【０１７６】図１２は、ユーザ配信処理タスク５００ａ
の処理内容を示すフローチャートである。

【０１７７】ユーザ配信処理タスク５００ａは、配信ス
ケジューラタスク４００ａにより、タスクとして生成さ
れ、マルチタスクＯＳ２００ａにより起動される。該タ
スク５００ａは、メディアサーバ１のマルチメディアデ
ータの配信件数分だけ生成され、マルチタスクＯＳ２０
０ａによって、適宜切り替えられながら動作し、見かけ
上、同時に複数のクライアント２に対する、マルチメデ
ィアデータの配信を行なっている。

【０１７８】まず、ステップ５０１では、配信対象のデ
ータに対応するＩＮＤＥＸデータ２０３０を、主メモリ
（ＲＡＭ）１０２上にロードする。ステップ５０２で
は、配信対象となるデータ３０００を、マルチタスクＯ
Ｓ２００ａや各タスクが、読み出し可能な状態にする。
通常、マルチタスクＯＳ２００ａは、記憶装置１０６等
に記憶しているデータのアクセスを管理するため、ファ
イルといった概念で管理するが、ステップ５０２では、
データ３０００のファイルをオープンする。

【０１７９】次に、ステップ５１１では、配信条件テー
ブル２０００ａの品質２００２を参照して、データ量削
減パラメータを読みだす。ステップ５１２では、配信対
象のデータ３０００のＩＮＤＥＸデータ２０３０の２０
３２を参照して、配信するデータ単位７０の読み出し開
始位置までシークする。

【０１８０】ステップ５１３では、読み出し開始位置か
らＩＮＤＥＸデータ２０３０の２０３３を参照して、配
信するデータ単位７０を読み出す。ステップ５１４で
は、データ単位７０を、ステップ５１１で読み出したデ
ータ量削減パラメータに従って、データ量の削減を行な
う。ここで、ネットワークや回線の伝送能力に余裕があ
り、メディアサーバ１のサービス能力に余裕がある場合
には、データ量の削減を必ずしも行なう必要がなく、そ
のようなときには、ステップ５１４では、何の処理も行
なわない。ステップ５１５では、データ量の削減処理を
行なった削減データを、単位７０毎に、クライアント２
に転送する。

【０１８１】そして、ステップ５２１では、ステップ５
１４で送信したデータがファイルの終わり（ＥＯＦ）で
あるか否かを判定し、終わりでない場合には、ステップ
５２２に進み、終わりならば、ステップ５３１に進む。
ステップ５２２では、配信スケジューラタスク４００ａ
からの、配信処理の終了を伝えるメッセージの有無を検
知し、終了要求があれば、ステップ５３１に進み、一
方、終了要求がなければ、ステップ５１１に進む。

【０１８２】次に、ステップ５３１では、ステップ５０
２でオープンしたファイルをクローズし、ステップ５３
２では、サービス品質管理タスク６００ａに配信の終了
を通知し、タスク５００ａが使用した主メモリ１０２上
のメモリ空間等のリソースの開放を行なった後、マルチ
タスクＯＳ２００ａにタスク５００ａの終了を、自ら要
求し、タスク５００ａの処理を終了する。なお、ステッ
プ５１１で、配信条件テーブル２０００を参照する際、
変更フラグ２００４が「変更あり」を示している場合に
は、これを「変更なし」の状態に設定する処理を行な
う。また、このフラグ２００４が「変更なし」であれ
ば、新たにデータ量削減パラメータを読み出す必要はな
い。

【０１８３】次に、本発明にかかる第１の実施例におけ
るメディアサーバ１のサービス品質管理タスク６００ａ
の処理内容について説明する。

【０１８４】図１３は、サービス品質管理タスク６００
の処理内容を示すフローチャートである。

【０１８５】サービス品質管理タスク６００ａは、配信
スケジューラタスク４００ａにより、タスクとして生成
され、マルチタスクＯＳ２００ａにより起動される。

【０１８６】まず、ステップ６０１では、配信管理テー
ブル２０１０を初期化し、ステップ６１１では、配信ス
ケジューラタスク４００ａからのメッセージを待ち、メ
ッセージを受信したらその内容を解釈し、メッセージの
内容が、「新規配信開始」であれば、ステップ６２１に
進み、「配信条件変更」であれば、ステップ６３１に進
み、配信中のユーザ配信処理タスク５００ａの処理の終
了（配信終了）であれば、ステップ６４１に進み、メデ
ィアサーバ１の配信スケジューラ自体の終了によるタス
ク終了処理要求（タスク処理終了）であれば、ステップ
６５１に進む。

【０１８７】ステップ６２１では、配信管理テーブル２
０１０のネットワーク別転送レート合計２０２０、およ
び、サービス転送レート合計２０２５を参照し、新規に
配信するデータの転送レート２０３１と、予め設定され
たネットワークセグメントやバス１１７の伝送帯域（２
０２２、２０２６）とを比較して、データ量を削減せず
に、あるいは、データ量を削減して新規に配信可能な
ら、ステップ６２４に進み、また、データ量を削減して
も、新規に配信が不可能なら、ステップ６２３に進む
（ステップ６２２）。この場合、タスク４００ａから渡
されたユーザの配信画質への要求品質と、サービス可能
な転送レートを同時に満たすデータ量の削減が可能であ
るか否かを、動画データの元の転送レート２０３１とデ
ータ量削減のための、図２のテーブル１０を参照し、該
テーブル１０に条件を満たすデータ量削減パラメータが
無い場合は、配信不可能とする。ステップ６２４では、
配信管理テーブルに、新規の配信要求に対応したレコー
ド２０１１を追加し、ステップ６２６では、配信スケジ
ューラタスク４００ａに配信可能である旨と配信条件テ
ーブルに設定するパラメータとを、メッセージにより伝
え、ステップ６１１に進む。

【０１８８】次に、ステップ６２３では、配信管理テー
ブルを参照し、既に配信を開始しているユーザ配信処理
タスクに対応する配信条件を変更すれば、新規配信が可
能であるか否かをを調べ、既に配信中のデータのうち、
それ以上転送レートを下げられないものがある場合等、
条件変更が不可能な場合には、ステップ６２７に進み、
一方、条件変更が可能ならば、ステップ６２５に進む。

【０１８９】また、ステップ６２３における配信条件を
変更における、配信の可否の判定も、ステップ６２２と
同様に、図２のテーブル１０を参照して行なう。なお、
ステップ６２３では、配信管理テーブルの優先度２０１
３の情報を用いて、優先度の高い配信処理については、
条件を変更せず、優先度の低いものから条件を変更して
いくようにする。

【０１９０】ステップ６２７では、配信スケジューラタ
スク４００ａに新規配信が不可能である旨をメッセージ
により伝え、ステップ６１１に進む。ステップ６２５で
は、変更した配信条件を配信管理テーブル２０１０の各
レコード２０１１に設定し、対応する配信条件テーブル
２０００のデータを再設定し、変更フラグ２００４を
「変更あり」に設定し、ステップ６２６を実行する。

【０１９１】次に、ステップ６３１では、配信管理テー
ブル２０１０を参照し、変更の対象となっているレコー
ド２０１１の内容の変更をすれば、既に配信中のデータ
のうち、それ以上転送レートを下げられないものがある
場合等、条件変更が不可能な場合の有無を判定し、条件
変更が可能な場合には、ステップ６３４に進み、条件変
更が不可能な場合には、ステップ６３３に進む（ステッ
プ６３２）。

【０１９２】ステップ６３３における配信の可否の判定
も、ステップ６２２と同様に、図２のテーブル１０を参
照して行なう。

【０１９３】なお、ステップ６３２では、配信管理テー
ブルの優先度２０１３の情報を参照して、優先度の高い
配信処理については、条件を変更せず、優先度の低いも
のから条件を変更していくようにする。

【０１９４】ステップ６３３では、配信スケジューラタ
スク４００ａに配信条件変更が不可能である旨をメッセ
ージにより伝え、ステップ６１１に進む。ステップ６３
４では、変更した配信条件を配信管理テーブル２０１０
の各レコード２０１１に設定し、対応する配信条件テー
ブル２０００のデータを再設定し、変更フラグ２００４
を「変更あり」に設定する。ステップ６３５では、配信
スケジューラタスク４００ａに配信条件可能である旨
を、メッセージにより返答し、ステップ６１１に進む。

【０１９５】次に、ステップ６４１では、配信の終了し
たレコード２０１１を配信管理テーブル２０１０より削
除し、必要なら、他のレコードの配信条件も変更する。

【０１９６】最後に、ステップ６５１では、サービス品
質管理タスク６００ａが使用した主メモリ１０２上のメ
モリ空間等のリソースの開放を行なった後、マルチタス
クＯＳ２００ａにタスク６００ａの終了を自ら要求し、
タスク６００ａの処理を終了する。

【０１９７】なお、新規に配信を開始するクライアント
が低速回線を介したＭＰＥＧ１データの配信要求であれ
ば、図２のテーブル１０を参照して、例えば、ＩＳＤＮ
の６４ｋｂ／ｓ程度の転送レートであれば、セル１６に
記述されたデータ量削減方法で、アナログ回線の１４．
４ｋｂ／ｓ程度の転送レートであれば、セル１７に記述
されたデータ量削減方法で削減処理したデータを転送す
れば、クライアント２側において、該データを受信しな
がらデコードして表示すること（リアルタイム再生）も
可能である。この場合、ＡＣ成分の上限数の制限や、フ
レーム数の削減は、伝送レートの調整のために採用す
る。

【０１９８】次に、本発明にかかる第１の実施例におけ
るメディアサーバ１の配信データ整形タスク７００ａの
処理内容について説明する。

【０１９９】図１４は、配信データ整形タスク７００ａ
の処理内容を示すフローチャートである。

【０２００】配信データ整形タスク７００ａは、ユーザ
が、メディアサーバにクライアント２で共用する動画デ
ータを登録するときに、ユーザの指示により、マルチタ
スクＯＳ２００ａが生成し、起動する。

【０２０１】ステップ７０１では、ユーザから登録され
たＭＰＥＧ１動画の元データ２９９９を読み込み、次
に、ステップ７０２では、データ２９９９を音声だけの
データと動画だけのデータに分離し、ステップ７１１で
は、ステップ７０２で分離した動画データから１ＧＯＰ
ごとに抜き出し、このＧＯＰの時間に対応するＡＡＵを
ステップ７１１で分離した音声だけのデータから抜き出
し、それぞれをマージして、図９に示すデータ単位７０
を作成する。この処理を全てのＧＯＰに対して繰返し、
全てのデータ単位７０をマージして整形済み元データ３
０００を作成して、ＩＮＤＥＸデータ２０３０に登録す
る。

【０２０２】そして、ステップ７２１では、選択したセ
ルに対応するデータ量削減パラメータを使用して、削除
データの作成を行ない、タスク７００ａの処理を終了す
る。

【０２０３】なお、ステップ７１１における動画と音声
の時間的な対応付けは、動画のフレームレートと音声の
サンプリング周波数より、各ＧＯＰおよびＡＡＵの再生
開始時間を計算し、両者を照らし合わせることにより行
なう。

【０２０４】次に、本発明にかかる第１の実施例におけ
るクライアント２のメディア要求タスク部９００ａの処
理内容について説明する。

【０２０５】図１５は、メディア要求部９００の処理の
フローチャートである。

【０２０６】ステップ９０１では、ユーザから配信要求
のあるデータのファイル名や、配信されたデータに利用
方法の情報などを受け付ける。利用方法の情報とは、配
信された動画データをブラウジングに使うか、あるい
は、詳細に鑑賞する旨を示す情報である。また、かかる
情報は、ユーザが入力しなくとも、ブラウジングを目的
とするアプリケーションからの要求であれば、メディア
要求タスク９００ａが自動的にブラウジング用と判断す
るような構成にしても良い。次に、ステップ９１１で
は、ユーザの用途から、動きの滑らかさか、あるいは、
精細度のいずれを、どの程度要求するかといった、動画
の画質に関する要求を評価し、そのデータを供給可能な
メディアサーバ１を、ＬＡＮ３、ＩＳＤＮ４に接続され
ているメディアサーバのなかから検索し、要求を満たす
メディアサーバ１を決定する。

【０２０７】ステップ９２１では、ステップ９１１で決
定したメディアサーバ１に配信を希望する動画データの
ファイル名と、画質の要求とをメッセージにより送信
し、サーバからのデータの配信を待つ。そして、ステッ
プ９３１では、メディアサーバ１からの返答を待ち、
「配信可能」であれば、受信したデータをマルチメディ
アデータ再生タスク１０００ａにより表示し、再生が終
了すれば、メディア要求タスク９００ａの処理を終了す
る。なお、メディアサーバからの返答が「配信不可能」
であれば、時間を空けてリトライした後、更に「配信不
可能」であれば処理を終了するようにしても良い。

【０２０８】以上述べてきた、第１の実施例によれば、
メディアサーバ１が記憶している、ある動画データをク
ライアント２に配信する際に、ユーザの画質への要求
と、ネットワークや回線の伝送能力を含めたメディアサ
ーバのサービス能力とを考慮して、データ量の削減を行
ないながら、削減データを配信することが可能になる。

【０２０９】また、データ量の削減制御も、時々刻々と
変化するサービス能力に追随して、動画のＧＯＰや音声
のＡＡＵの、切れ目に合わせて、データ量削減方式を切
り換えることができ、クライアント側では、配信を受け
る動画が乱れたり、音声がとぎれたりノイズが混入する
といったことが無くなる。以上のことから、メディアサ
ーバ１は、配信する動画データのデータ量を削減制御す
ることによる、ネットワークや回線、サーバの処理能力
を考慮したデータの提供が可能となり、クライアント２
のユーザは、希望する品質を有するデータの配信を受け
ることが可能になる。

【０２１０】なお、本実施例で述べたデータ量を削減し
ながらの配信は、予め配信データを図９に示すように整
形しておくため、データ量削除制御の処理負荷を増加さ
せることなく実現することが可能であり、複数クライア
ントの同時配信要求に対し、リアルタイムな配信処理が
実現できる。

【０２１１】また、転送するネットワークのトラヒック
が飽和する可能性がある場合にも、配信する動画データ
の転送レートを抑えながらの配信が可能であり、メディ
アサーバが同時に動画データを配信できるクライアント
の数を増加させることができる。この時、クライアント
ごとに優先度を設定することが可能であるため、優先度
の低いクライアントから、転送する動画のデータ量を削
除していくようにすることができ、ユーザが予め定めた
優先度にしたがった、ユーザの要求を満足するデータ提
供を実現できる。

【０２１２】次に、本発明にかかる第２の実施例を説明
する。

【０２１３】本実施例は、サーバが、クライアントから
配信要求されるデータのデータ量を、予め定めた規則に
従って削減した、削減データを予め用意して格納してお
き、適当な削減データを配信するという実施例である
（なお、本実施例を、便宜上「ソフト型」と称する）。

【０２１４】図１を参照して説明した、第１の実施例に
おけるメディアサーバのネットワーク環境の一例は、そ
のまま第２の実施例において用いることができる。

【０２１５】次に、本発明の第１の実施例における、メ
ディアサーバ１（１ａ、１ｂ）のマルチメディアデータ
のデータ量削減方法、削減データの配信方法の原理につ
いて説明したが、本実施例では、図２の各セルに対応す
る削減データを、サーバが予め備えた構成になってい
る。すなわち、削減データは、画素数、ＡＣ係数の上限
値、フレーム数を含むデータ量削除パラメータを使用し
て、元データのデータ量を削除して作成する。そして、
ある元データに対して、複数種類の削除データを予め生
成し、サーバが格納している。

【０２１６】さて、配信する削除データの選択は、図２
のテーブル１０を参照して、次のように行う。なお、サ
ーバは、各セルに対応した削除データを、予め作成し、
記憶装置に格納しているものとする。

【０２１７】まず、ユーザ（クライアント）からの配信
要求が発生した場合、メディアサーバ１では、図２の１
０を参照し、ユーザの要求と、配信（サービス）能力を
考慮したデータ量となるように、配信時の初期削減デー
タを選択し、選択した削減データの配信を行なう。ここ
で、配信（サービス）能力とは、例えば、サーバに接続
されている各通信媒体の、通信許容伝送レート等が考え
られる。ユーザの要求のみならず、サーバに接続されて
いる各通信媒体の、通信許容伝送レートを越えないこと
を条件として、データ量の削減処理が行なわれる。

【０２１８】これを仮に、セル１１に対応する削減デー
タを採用するとし、配信の途中で、ユーザ要求が、更に
動きの滑らかさを優先するように変更された場合には、
（横軸上で右側に存在する）セル１２に対応する削除デ
ータに変更選択し、また、精細度を優先するように変更
された場合は、（横軸上で左側に存在する）セル１３に
対応する削除データに変更選択し、それぞれ変更選択さ
れた削除データを配信する。

【０２１９】また、セル１１に対応する削除データの配
信中に、メディアサーバ１のサービス能力が低下し、更
にデータ量を削減する必要があるときには、（縦軸下方
向に存在する）セル１５に対応する削除データに変更選
択し、また、サービス能力が回復して、配信データ量を
増加することが可能になれば、（縦軸上方向に存在す
る）セル１４に対応する削除データに変更選択して、変
更選択した削除データを配信する。

【０２２０】なお、図３を参照して説明した、ＭＰＥＧ
１動画データのフォーマットは、第２の実施例でも同様
である。動画データのデータ量の削減方式について再度
説明することは避ける。

【０２２１】第１の実施例では、図５を参照して説明し
たコンピュータ端末をそのまま使用することができる。

【０２２２】ただし、クライアントおよびサーバが備え
る記憶装置には、第２実施例用のプログラムを格納して
おり、また、サーバ側には、元データに対応する、複数
種類の削除データを、元データ種類ごとに記憶してい
る。

【０２２３】図１６は、本発明にかかる第２の実施例に
おけるメディアサーバ１及びそのクライアント２のソフ
トウェア構成を示す図、即ち、機能ブロック図である。

【０２２４】まず、図１６（ａ）を参照して、メディア
サーバ１のソフトウェア構成について説明する。

【０２２５】第２の実施例における、タスク２００ｂ〜
６００ｂは、第１の実施例における、タスク２００ａ〜
６００ａと基本的には同じ機能を有するが、重複説明を
避けずに説明することにする。

【０２２６】２００ｂは、メディアサーバ１の基本シス
テムソフトウェア、あるいは、オペーレティングシステ
ム（以下「ＯＳ」と略記）と称されるソフトウェアであ
り、メディアサーバ１上で動作するソフトウェアへのＣ
ＰＵ１０１の機能の割当て管理、図５を参照して説明し
た各ハードウェア装置資源の管理、メモリ１０２の論理
的な使用単位での管理、ソフトウェアおよびハードウェ
アの処理実行のスケジューリング等を行うプログラムで
あり、いわゆるマルチタスク処理を行なう、マルチタス
クＯＳである。マルチタスクＯＳ２００ｂは、通常、Ｌ
ＡＮ３やＩＳＤＮ４を介して、他の端末とデータ通信を
行う際の通信手順の制御等を行うプロトコル処理部２１
０ｂや、記憶装置１０６の動作制御や記憶装置１０６に
格納するデータのファイル管理を行うファイルシステム
２２０ｂを含んで構成される。

【０２２７】３００ｂは、メディアサーバ１において動
作するソフトウェアの実行単位で、メディアサーバ１に
おいて複数存在し、一般に、タスク（あるいはプロセ
ス）と称されるものである。なお、以下に述べる４００
ｂ〜７００ｂも、タスク（あるいはプロセス）であり、
マルチタスクＯＳ２００ｂ側から見た扱い方は、３００
ｂに対するのと同様である。複数存在するタスク３００
ｂは、マルチタスクＯＳ２００ｂにより生成され、ユー
ザやマルチタスクＯＳ２００ｂによって、個々に指定さ
れた優先度に基づき、実行順序の決定や、ハードウェア
資源へのアクセス等の調整が行なわれることにより、中
断、実行待ち、終了等の実行状態になるように管理され
る。

【０２２８】以下で述べるメディアサーバ１において、
マルチタスクＯＳ２００ｂは、ＬＡＮ３からのデータの
着信、ユーザの入力装置１０５等を介した入力、記憶装
置１０６の処理終了等の、イベントに伴うＣＰＵ１０１
への割込みに対し、即座に優先度に基づき、タスク３０
０ｂの実行順序の変更を行う、リアルタイム性を有した
マルチタスクＯＳである。

【０２２９】本実施例においては、特に、マルチタスク
ＯＳ２００ｂは、タスク間での情報（メッセージ）伝達
の支援、ＬＡＮ３，ＩＳＤＮ４から送られてきたメッセ
ージをプロトコル処理部２１０ｂによる処理を介してタ
スクへ伝達する等の、異なるネットワークや回線に渡る
タスク間通信支援機能を有し、また、マウス１０４、キ
ーボード１０５等の入力装置を介してユーザが入力した
入力内容を、必要に応じてタスクに伝達したり、タスク
のデータ出力要求を受け付けて画像入出力制御装置１０
８を制御し、ディスプレー１１０に、要求に適合したデ
ータを表示する等の、入出力制御機能も有している。

【０２３０】４００ｂは、クライアント２からのマルチ
メディアデータ配信要求を受け付け、ユーザ配信処理タ
スク５００ｂに配信要求を発したクライアント２への、
データの配信処理を依頼する、配信スケジューラタスク
である。また、ユーザ配信処理タスク５００ｂは、マル
チタスクＯＳ２００ｂにより、ユーザからの配信要求の
件数分だけ生成されるが、一般にＯＳが扱うことが可能
なタスク数は、ハードウェアの仕様等によって制限され
ており、そのような制限数を超える場合には、配信を行
わない。また、配信スケジューラタスク４００ｂの具体
的な処理内容については後述する。

【０２３１】５００ｂは、要求を発したクライアントに
対して、マルチメディアデータの配信を行うユーザ配信
処理タスクであり、該タスクは、ユーザの指定したサー
ビス品質と、メディアサーバ１の処理負荷やＬＡＮ３、
ＩＳＤＮ４の伝送能力を考慮して、サービスするデータ
の品質を制御する、すなわち、配信対象とする削除デー
タを選択し、選択した削除データを配信する。

【０２３２】該制御は、例えば、ユーザの品質要求があ
るレベル以上であるときや、メディアサーバのサービス
能力が高くないときに（配信データに対して、通信媒体
の伝送能力が小さなとき）、配信するオリジナルのマル
チメディアデータのデータ量を削減して配信することに
より実現する。ユーザの指定したサービス品質に関する
情報（即ち、図２の１０において、セルの横軸方向の位
置を定める情報）は、配信スケジューラタスク４００ｂ
により、また、メディアサーバ１の処理負荷やＬＡＮ
３、ＩＳＤＮ４の伝送能力等の、メディアサーバ１のサ
ービス能力に関する情報は、サービス品質管理タスク６
００ｂにより、それぞれ取得する。該タスク５００ｂに
よるデータ量制御の具体的な方法については、後述す
る。

【０２３３】６００ｂは、メディアサーバ１の処理負荷
やＬＡＮ３、ＩＳＤＮ４の通信品質等、メディアサーバ
１のサービス能力に関する情報に基づき、配信のサービ
ス品質の決定、および、ユーザ配信処理タスク５００ｂ
等に、サービス品質の情報を提供するサービス品質管理
タスクである。なお、公知となっているＯＳには、ＣＰ
Ｕ１０１の処理負荷を逐次、数値で評価して、各タスク
に通知する機能を有するものがある。また、ＬＡＮ３に
流れるデータパケットの流量を監視することにより、Ｌ
ＡＮ３中のデータの混雑の程度を数量的に評価し、各タ
スクに通知する機能を有するソフトウェアもある。ま
た、サービスするマルチメディアデータの転送レート
を、メディアサーバ１が、該データごとの情報として予
め有し、メディアサーバ１が、クライアント２に配信中
のデータの種類と、各転送レートの情報とを参照して、
自ら配信能力を数量的に評価して、各タスクに通知する
機能を有するように構成することも考えられる。このよ
うに、６００ｂが提供するサービス能力の情報は、メデ
ィアサーバ１が自ら検知するか、クライアント２からの
データ要求のような外部からの情報を用いて検知した、
サービス能力を数量的に表現したものとし、特に、後者
の検知方法の実現例については、後述する。また数量的
に表現されたサービス能力値の伝達は、主メモリ１０２
の上の特定の領域を情報伝達用に割当て、該領域を、タ
スク３００ｂ乃至７００ｂが共有することによって実現
される。

【０２３４】７００ｂは、第１の実施例と異なるソフト
ウエアであり、第２の実施例の主要部をなすタスクであ
る。

【０２３５】ユーザの品質要求があるレベル以上である
ときや、メディアサーバのサービス能力が高くないとき
（配信データに対して、通信媒体の伝送能力が小さなと
き）に配信する削除データを、オリジナルのマルチメデ
ィアデータのデータ量を削減して生成する、削減データ
生成タスクである。削減データは、１つのオリジナルマ
ルチメディアデータに対し、図２の各セルに示すよう
な、複数のデータ量削減方法を採用して、予め複数種類
作成しておく。なおタスク７００ｂの具体的な処理内容
については、後述する。

【０２３６】なお、オリジナルのマルチメディアデータ
と、削減データのいずれを配信するかは、ユーザ配信処
理タスク５００ｂが判定し決定する。該タスク５００ｂ
によるデータ量制御は、配信するデータを、オリジナル
データまたは削減データに切り替えることにより実現す
る。なお、該タスク５００ｂの処理内容については、後
述する。

【０２３７】次に、図１６（ｂ）を参照して、クライア
ント２のソフトウェア構成について説明する。

【０２３８】８００ｂは、クライアント２のＯＳであ
り、機能的には、メディアサーバ１のＯＳ２００ｂと同
様である。また、ＯＳ８００ｂは、マルチタスク２００
ｂと同様に、通信制御等を行うプロトコル処理部８１０
ｂや、ファイルシステム８２０ｂを有して構成される。

【０２３９】９００ｂおよび１０００ｂは、ＯＳ８００
ｂ上で動作するタスクである。

【０２４０】９００ｂは、ユーザの指示により起動さ
れ、ユーザの必要とするマルチメディアデータの名称、
および、配信時のサービス品質等の要求を取り込み、こ
れらの情報をメディアサーバ１に、ＬＡＮ３やＩＳＤＮ
４等を介して伝送し、また、配信されてきたデータを受
信する、メディア要求処理タスクである。該タスク９０
０ｂの具体的な処理内容については、後述する。

【０２４１】１０００ｂは、メディア要求タスク９００
ｂが受信した動画、静止画、音声等を有するマルチメデ
ィアデータを再生する、マルチメディアデータ再生タス
クである。該タスク１０００ｂは、メディア要求タスク
９００ｂが、マルチメディアデータを全て受信終了して
から、該データの再生を開始するようにしても良いし、
全ての受信処理を完了する前に、受信したデータを逐次
再生するようにしても良い。特に、動画等の再生では、
時間的制約条件が課される場合があり、このような場合
には、後者のような再生方法を採用すれば良い。また、
該タスク１０００ｂが行なう処理は、画像コーディック
１１５や音声コーディック１１６のような専用ハードウ
ェアによって実行されても良いし、ＤＳＰ１２０による
マイクロプログラムの実行やＣＰＵ１０１による主メモ
リ１０２上のソフトウェアの実行によって、行なわれて
も良い。

【０２４２】次に、本発明にかかる第２の実施例におけ
るメディアサーバ１の有する制御テーブルやデータ構造
について説明する。

【０２４３】メディアサーバ１では、図２のテーブル１
０の各セルに対応する削減方法で作成した複数種類の削
除データや元データ、図７に示す各制御テーブルを、主
メモリ１０２上格納し、少なくとも、マルチタスクＯＳ
２００ｂ、配信スケジューラ４００ｂ、ユーザ配信処理
タスク５００ｂ、サービス品質管理タスク６００ｂ、お
よび、削減データ生成タスク７００ｂが参照可能な、ア
ドレス上に確保する。以下、図１７に示す各制御テーブ
ルについて説明する。

【０２４４】６０００は、配信するＭＰＥＧ１データの
元データである。後に詳しく説明する削減データ生成タ
スク７００ｂでは、図２のテーブル１０を参照し、元デ
ータ６０００から、データ量を図２のテーブル１０の各
セルに対応する削減方法にしたがって削減処理した削減
データを複数個生成し（６０２０）、元データ６０００
と削減データ６０２０の論理的な関係付けに関する情報
と、削減データの転送レートを記述したＩＮＤＥＸデー
タ４０３０を生成する。

【０２４５】当然のことながら、メディアサーバ１に
は、複数種類の元データ６０００が存在し、各元データ
ごとに、さらに複数種類の削減データ６０２０が存在す
るため、ＩＮＤＥＸデータ６０３０も、元データ６００
０と一意に対応して、複数存在する。なお、説明を容易
化するため、削除データ６０２０としては、３種類の削
除データ、６０２０ａ、６０２０ｂ、６０２０ｃのみを
図示している。

【０２４６】ＩＮＤＥＸデータ６０３０の内容について
は、後述する。

【０２４７】４０００ａ、ｂは、配信条件テーブルであ
り、これは配信スケジューラタスク４００ｂにより、前
述したユーザ配信処理タスク５００ｂ（図１７の５００
ｅ、５００ｆ）と一意的に対応付けられて生成される、
ユーザへの配信条件に関する情報を記述したテーブルで
ある。ユーザ配信処理タスク５００ｂと同様に、配信条
件テーブル４０００も、配信件数分だけ存在し、１つの
テーブル４０００には、少なくとも、ファイル名４００
１、（サービス）品質（データ名）４００２、および、
（配信条件）変更フラグ４００４の各データの内容が記
述されている。

【０２４８】該テーブル４０００は、配信スケジューラ
タスク４００ｂにより生成された後は、必要に応じてサ
ービス品質管理タスク６００ｂにより、その内容が変更
される。

【０２４９】ファイル名４００１は、配信する元データ
６０００を指定するための識別子である。

【０２５０】品質２００２は、ユーザに提供する動画の
品質に関するデータであるが、本実施例の場合は、デー
タ群６０１０のうち、実際に配信するデータ、即ち、６
０００か、６０２０ａ、ｂ、ｃのいずれかを指定するた
めのデータ識別子である。

【０２５１】変更フラグ４００４が示すフラグは、該テ
ーブル４０００が、配信スケジューラタスク４００ｂに
より新規に生成されたとき、および、サービス品質管理
タスク６００ｂによりその内容が変更されたときに、
「変更あり」を示すように設定される。また、該フラグ
４００４は、ユーザ配信処理タスク５００ｂが、６００
４を参照したときに、「変更なし」を示すように設定さ
れる。

【０２５２】４０１０は、メディアサーバ１がユーザへ
のサービス能力を管理するためのデータを保持する配信
管理テーブルである。該テーブル４０１０は、メディア
の配信要求ごとに、少なくとも、要求したクライアント
のクライアントＩＤ４０１２、配信の優先度４０１３、
メディア種別４０１４、メディアの転送レート４０１
５、配信処理の状態４０１６等の情報を保持する配信状
況レコード４０１１（図１７では、３つのクライアント
毎に、４０１１ａ、４０１１ｂ、４０１１ｃとしてい
る）を情報として持っている。

【０２５３】さらに、４０１０は、メディアサーバ１が
接続している通信媒体ごとに、転送中のデータの転送レ
ートの最新の合計値を常に保持する、ネットワーク別転
送レート合計レコード４０２０、および、メディアサー
バ１が転送中のデータの転送レートの最新の合計値を常
に保持する、サービス転送レート合計レコード４０２５
を、情報として持っている。

【０２５４】配信状況レコード４０１１は、ユーザから
の配信要求があったときに、配信が可能であれば追加さ
れ、ユーザ配信処理タスク５００ｂに一意に対応して存
在する。さらに、レコード４０１１中の各情報の設定方
法等について説明する。

【０２５５】クライアントＩＤ４０１２は、ネットワー
ク上でのクライアントの論理アドレス（例えばＩＰアド
レス等）を使用することも可能である。優先度４０１３
は、メディアサーバ１における各配信処理の優先度を数
値で表したものであり、クライアント２が、配信要求時
に指定するのが一般的であるが、メディアサーバ１が、
予めクライアントＩＤ毎に定めておいた優先度を使用す
るようにしてもよい。

【０２５６】メディア種別４０１４は、動画、静止画と
言った、配信中のメディアの種類の識別子であり、本実
施例においては、前記配信データ群６０１０のうち、元
データ６０００や削減データ６０２０の、データ識別子
を用いることが可能である。

【０２５７】なお、図示しているように、本配信管理テ
ーブル４０１０は、ある特定の動画１に対するテーブル
である。即ち、説明のために、元データ６０００の種類
を、「動画１」のみとして図示している。

【０２５８】転送レート４０１５は、配信するデータ毎
の転送レート値であり、このデータは、後述するＩＮＤ
ＥＸデータ４０３０中のデータと同一のものである。

【０２５９】状態４０１６は、最新のデータの配信状態
を表す、「転送中」、「待ち」等の情報が記憶される。
４０１２〜４０１６は、配信開始時に、サービス品質管
理タスク６００ｂによって、新規にレコード４０１１が
追加される時点で設定され、以後、ユーザの新たな配信
要求の追加や配信条件の変更に伴って、４０１２〜４０
１６の内容は、追加、変更される。なお、かかる変更処
理の内容については、後に、サービス品質管理タスク６
００ｂの処理の説明部分において述べる。

【０２６０】ネットワーク別転送レート合計レコード４
０２０は、ユーザからの新規配信要求の追加時や配信要
求の変更時に、サービス品質管理タスク６００ｂにより
更新される情報であり、該タスク６００ｂは、複数のＬ
ＡＮ３やＩＳＤＮ（ＷＡＮ）４のような、サーバ１に接
続される通信媒体（以後「ネットワークセグメント」と
称す）ごとに、配信処理中のデータの転送レートの合計
を計算した値を設定する。この時、該タスク６００ｂ
は、転送状態４０１６を参照して、転送中のレコード４
０１１を見つけ出し、クライアントＩＤ４０１２を手が
かりに、ネットワークセグメントを特定し、ネットワー
クセグメント毎に転送レート４０１５を合計する。全て
のネットワークセグメント毎に転送レートを計算し、ネ
ットワークセグメント、計算値のそれぞれを、レコード
４０２０の中のデータ４０２１、４０２３として設定す
る。

【０２６１】なお、ネットワークセグメント毎に使用可
能な転送レート（伝送帯域）を、予め定めておき、この
データを、新規に配信を開始するか否かを決定する場合
に使用する。即ち、この値を越えるような配信を行なう
ことは許容されない。

【０２６２】サービス転送レート合計レコード４０２５
は、ユーザからの新規配信要求の追加時や配信要求の変
更時に、サービス品質管理タスク６００ｂにより更新さ
れる情報で、該タスク６００ｂは、メディアサーバ１が
配信処理中のデータの転送レートの合計を計算して、４
０２７に設定する。この時、該タスク６００ｂは、状態
４０１６を参照して、転送中のレコード４０１１を見つ
け出し、該レコードについての転送レート４０１５を合
計する。該レコード４０２５には、メディアサーバ１が
備えるバス１１７が、データ配信可能な転送レートの上
限値（前記伝送帯域）を予め決めておき、この値を参照
して、新規にデータ配信を開始するか否かを決定する場
合に使用する。

【０２６３】すなわち、サーバが扱うことが可能なマル
チメディアデータに対する転送レートの合計の上限値
（４０２７）を定めており、転送レート４０２７が、こ
の上限値を越えるような場合には、越えないように、削
除データを選択して、選択した削除データが配信され
る。

【０２６４】次にＩＮＤＥＸデータ２０３０について、
説明する。本実施例においては、配信対象の動画データ
毎に、複数種類の削除データを予め作成しておき、メデ
ィアサーバ１に備えておき、ユーザが与えるユーザ要求
と、伝送能力で定まるサービス要求を考慮した、削除デ
ータを選択し、転送レートを削減しながらデータを配信
し、配信中に配信条件が変更されたときには、その変更
された配信条件に最も近い（例えば、現在のセル位置を
基準とした時、特定方向に隣接するセルで示される削減
方式を使用して作成された削減データ）削減データに切
り替えて配信する。この時、実際のＭＰＥＧ１データの
構成を考慮したときの問題点が存在することは、図８を
参照して、第１の実施例にて説明した通りであり、この
対処方法も、図９を参照して、第１の実施例にて説明し
たものと同一あるため、ここでは重複説明を省略する。

【０２６５】図１８には、図９にて説明した手順で整形
した元データ６０００と削減データ６０２０のＧＯＰと
ＡＡＵをまとめた単位（７０５、７１０、７２０）の対
応付けを示す。配信する動画のデータ量の制御を実現す
るには、この７０５、７１０、および７２０の切れ目で
切り替える。すなわち、１つの「ＧＯＰ＋ＡＡＵ」を単
位として、順次切り換えていく。

【０２６６】従って、図に示すように、配信条件が変化
する毎に、異なる種類のデータに対する単位で切り換え
ていく場合（例えば「、、、…」）、配信条件
が変化しない場合には、同一のデータに属する単位で切
り換えていく場合（例えば「、、…」）等の各種
の態様が考えられる。

【０２６７】さらに、同一のデータに属する単位で切り
換えていく場合において、途中で配信対象となるデータ
の種類の変更を余儀なくされるときに、所定時間経過し
た後に、再度、前記同一のデータに属する先頭単位に戻
って、単位ごとに切り換えていく方法も考えられる。

【０２６８】そのため、前述のＩＮＤＥＸデータ４０３
０には、データ名称４０３１として、元データ６０００
および削減データ６０２０のデータ識別子と、それぞれ
の転送レート４０３２および単位７００（７１０、７２
０）毎の、データの先頭からのサイズ（Ａ１乃至Ａ５）
と、単位のサイズ（ａ１乃至ａ５）（以上４０３３）
を、各データごとに記述する。配信するデータを切り換
える場合には、常に、データ４０３０を参照し、切り替
わった時点で、先頭からのサイズを呼んでシークし、単
位のサイズ文だけのデータを読んで、クライアント２に
送信すれば、クライアント２から見れば、配信データの
データ量が制御されて着信したことになる。

【０２６９】以上述べてきたソフトウェア、ハードウェ
ア構成を有するメディアサーバ１とクライアント２の間
で、データ量を制御をしながら、ＭＰＥＧ１動画データ
を配信する、各タスクの処理内容について以下述べる。

【０２７０】次に、本発明にかかる第２の実施例におけ
るメディアサーバ１の配信スケジューラの処理内容につ
いて説明するが、これは基本的には、図１１を参照して
説明した、第１の実施例の配信スケジューラと同様であ
るが、ステップ等に添字「ｂ」を付して、図１９を参照
して再度説明する。

【０２７１】図１９は、第２の実施例における配信スケ
ジューラタスク４００ｂの処理内容を示すフローチャー
トである。

【０２７２】配信スケジューラタスク４００ｂは、ユー
ザが、メディアサーバ１の入力装置１０５からの起動指
示入力や、ＬＡＮ３やＩＳＤＮ４を介した、クライアン
ト２からの起動要求メッセージデータを、マルチタスク
ＯＳ２００ｂが受け取ったときに、マルチタスクＯＳ２
００ｂによって起動される。

【０２７３】まず、ステップ４０１ｂにおいて、サービ
ス品質管理タスク６００ｂを起動し、次に、ステップ４
０２ｂにおいて、ＬＡＮ３やＩＳＤＮ４を介したクライ
アント２からのマルチメディアデータ配信要求や、サー
ビス内容の変更要求のメッセージデータ、ユーザのメデ
ィアサーバ１の入力装置１０５からの指示入力等を受け
付ける。

【０２７４】次に、ステップ４０３ｂでは、前記メッセ
ージおよび指示入力等の内容を判定し、ユーザからの新
たなマルチメディアデータの配信要求であれば（新
規）、ステップ４１１ｂに進み、また、画質等のサービ
ス品質の変更、動画の場合の早送り再生開始、ポーズ
等、サービス内容の変更要求であれば（変更）、ステッ
プ４２１ｂに進み、さらに、終了指示入力であれば、ス
テップ４３１ｂに進む。

【０２７５】なお、新規な配信要求および変更要求を伝
えるメッセージデータの内容は、配信、変更の対象とな
るマルチメディアデータの識別名称と要求品質とからな
り、これらは、ＬＡＮ３やＩＳＤＮ４を介してクライア
ント２からメディアサーバのマルチタスクＯＳ２００ｂ
に渡され、さらに、マルチタスクＯＳ２００ｂによっ
て、配信スケジューラタスク４００ｂに渡される。

【０２７６】次に、ステップ４１１ｂでは、サービス品
質管理タスク６００ｂに、ユーザの指定通りの要求品質
での新規配信が可能か否かを問い合わせ、配信可能であ
れば、ステップ４１３ｂに進み、配信不可能であればス
テップ４１４ｂに進む（ステップ４１２ｂ）。

【０２７７】次に、ステップ４１３ｂでは、新たなユー
ザ配信処理タスク５００ｂと配信条件テーブル４０００
との生成を、マルチタスクＯＳ２００ｂに要求し、メモ
リ１０２の容量不足や予め設定された総タスク数を超え
るなどの要因により、タスク５００ｂあるいはテーブル
４０００のいずれかの生成が不可能な場合には、（ステ
ップ４１５ｂ）ステップ４１４ｂに進み、一方、可能な
場合にはステップ４０２ｂに進む。また、ステップ４１
４ｂでは、配信要求のあったクライアント２に、メディ
アサーバ１が配信不可能である旨のメッセージを送信
し、ステップ４０２ｂに進む。

【０２７８】また、ステップ４２１ｂでは、サービス品
質管理タスク６００ｂに、ユーザの指定通りのサービス
内容の変更が可能であるか否かを問い合わせ、変更対象
のユーザ配信処理タスク５００ｂが既に消滅していると
か、メディアサーバ１のサービス能力の限度を超える等
の要因により、タスク５００ｂへの通知が不可能な場合
は、ステップ４２３ｂに進み、一方、可能な場合には、
ステップ４０２ｂに進む。

【０２７９】そして、ステップ４２３ｂでは、変更要求
のあったクライアント２に、メディアサーバ１が、サー
ビス内容の変更が不可能である旨のメッセージを送信
し、ステップ４０２ｂに進む。

【０２８０】最後に、ステップ４３１ｂでは、サービス
品質管理タスク６００ｂおよび配信スケジューラ４００
ｂが生成した全てのユーザ配信処理タスク５００ｂに、
配信処理の終了を指示するメッセージを与えた後、配信
スケジューラタスク４００ｂが使用しているハードウェ
ア資源等を開放することにより、配信スケジューラタス
ク４００ｂが行なう処理を終了する。

【０２８１】次に、本発明にかかる第２の実施例におけ
るメディアサーバ１のユーザ配信処理タスクの処理内容
について説明するが、これは基本的には、図１２を参照
して説明した、第１の実施例のユーザ配信処理タスクと
同様であるが、ステップ等に添字「ｂ」を付して、図２
０を参照して再度説明する。

【０２８２】図２０に、本発明にかかる第２の実施例に
おけるメディアサーバ１のユーザ配信タスク５００ｂの
処理内容について示す。

【０２８３】ユーザ配信タスク５００ｂは、配信スケジ
ューラタスク４００ｂにより、タスクとして生成され、
マルチタスクＯＳ２００ｂにより起動される。該タスク
５００ｂは、メディアサーバ１のマルチメディアデータ
の配信件数分だけ生成され、マルチタスクＯＳ２００ｂ
によって、適宜切り替えられながら動作し、見かけ上、
同時に複数のクライアント２に対する、マルチメディア
データの配信を行なっている。

【０２８４】まず、ステップ５０１ｂでは、配信対象の
データに対応するＩＮＤＥＸデータ４０３０を主メモリ
（ＲＡＭ）１０２上にロードする。ステップ５０２ｂで
は、配信対象となるデータ群６０１０のすべてのデータ
６０００および６０２０を、マルチタスクＯＳ２００ｂ
や各タスクが、読み出し可能な状態にする。通常、マル
チタスクＯＳ２００ｂは、記憶装置１０６等に記憶して
いるデータのアクセスを管理するため、ファイルといっ
た概念で管理するが、ステップ５０２ｂでは、６０１０
のデータを格納している、すべてのファイルをオープン
する。

【０２８５】次にステップ５１１ｂでは、配信条件テー
ブル４０００ａの品質４００２のデータ識別子を参照
し、ステップ５１２ｂでは、そのファイルに対応するＩ
ＮＤＥＸデータを検索し、ステップ５１３ｂでは、ＩＮ
ＤＥＸデータの４０３３を参照して、配信するデータの
読みだし開始位置までシークし、ステップ５１４ｂで
は、配信するデータの１単位７０５をクライアント２に
転送する。ステップ５２１ｂでは、ステップ５１４ｂで
送信したデータがファイルの終わり（ＥＯＦ）であるか
どうかを検知し、終わりでない場合は、ステップ５２２
ｂに進み、一方、終わりならばステップ５３１ｂに進
む。

【０２８６】ステップ５２２ｂでは、配信スケジューラ
４００ｂから配信処理の終了を伝えるメッセージの有無
を検知し、終了要求があれば、ステップ５３１ｂに進
み、一方、終了要求がなければステップ５１１ｂに進
む。

【０２８７】ステップ５３１ｂでは、ステップ５０２ｂ
でオープンしたファイルをすべてクローズし、ステップ
５３２ｂでは、サービス品質管理タスク６００ｂに配信
の終了を通知し、タスク５００ｂが使用した主メモリ１
０２上のメモリ空間等のリソースの開放を行なった後、
マルチタスクＯＳ２００ｂにタスク５００ｂの終了を自
ら要求し、タスク５００ｂの処理を終了する。なお、ス
テップ５１１ｂで、配信条件テーブル２０００を参照す
る際、変更フラグ４００４が「変更あり」を示している
場合には、これを「変更なし」の状態に設定する。ま
た、フラグ４００４が「変更なし」であれば、配信対象
ファイルを切り替える必要がなく、ステップ５１２ｂの
処理は省略できる。

【０２８８】次に、本発明にかかる第２の実施例におけ
るメディアサーバ１のサービス品質管理タスクの処理内
容について説明するが、これは基本的には、図１３を参
照して説明した、第１の実施例のサービス品質管理タス
クと同様であるが、ステップ等に添字「ｂ」を付して、
図２１を参照して再度説明する。

【０２８９】図２１は、第２の実施例におけるサービス
品質管理タスク６００ｂの処理内容を示すフローチャー
トである。

【０２９０】サービス品質管理タスク６００ｂは、配信
スケジューラタスク４００ｂにより、タスクとして生成
され、マルチタスクＯＳ２００ｂにより起動される。

【０２９１】まず、ステップ６０１ｂでは、配信管理テ
ーブル４０１０を初期化し、ステップ６１１ｂでは、配
信スケジューラタスク４００ｂからのメッセージを待
ち、メッセージを受信したらその内容を解釈し、メッセ
ージの内容が、「新規配信開始」であれば、ステップ６
２１ｂに進み、「配信条件変更」であれば、ステップ６
３１ｂに進み、配信中のユーザ配信処理タスク５００ｂ
の処理の終了（配信終了）であれば、ステップ６４１ｂ
に進み、メディアサーバ１の配信スケジューラ自体の終
了によるタスク終了処理要求（タスク処理終了）であれ
ば、ステップ６５１ｂに進む。

【０２９２】ステップ６２１ｂでは、配信管理テーブル
４０１０のネットワーク別転送レート合計４０２０、お
よび、サービス転送レート合計４０２５を参照し、新規
に配信するデータの転送レート４０３２と、予め設定さ
れたネットワークセグメントやバス１１７の伝送帯域と
を比較して、削除データ量を採用せずに、あるいは、選
択した削除データを新規に配信可能なら、ステップ６２
４ｂに進み、また、いずれの削除データ量を採用して
も、新規に配信が不可能なら、ステップ６２３ｂに進む
（ステップ６２２ｂ）。この場合、タスク４００ｂから
渡されたユーザの配信画質への要求品質と、サービス可
能な転送レートを同時に満たす削除データの選択が可能
であるか否かを、動画データの元の転送レートと削除デ
ータの転送レート（４０３２）とを、ＩＮＤＥＸデータ
を参照して調べ、条件を満たす削除データが無い場合
は、配信不可能とする。ステップ６２４ｂでは、配信管
理テーブルに、新規の配信要求に対応したレコード４０
１１を追加し、ステップ６２６ｂでは、配信スケジュー
ラタスク４００ｂに配信可能である旨と配信条件テーブ
ルに設定するパラメータとを、メッセージにより伝えス
テップ６１１ｂに進む。

【０２９３】次に、ステップ６２３ｂでは、配信管理テ
ーブルを参照し、既に配信を開始しているユーザ配信処
理タスクに対応する配信条件を変更すれば、新規配信が
可能であるか否かをを調べ、既に配信中のデータのう
ち、それ以上転送レートを下げられないものがある場合
等、条件変更が不可能な場合には、ステップ６２７ｂに
進み、一方、条件変更が可能ならば、ステップ６２５ｂ
に進む。

【０２９４】また、ステップ６２３ｂにおける配信条件
を変更における、配信の可否の判定も、ステップ６２２
ｂと同様に、ＩＮＤＥＸテーブルを参照して行なう。な
お、ステップ６２３ｂでは、配信管理テーブルの優先度
４０１３の情報を用いて、優先度の高い配信処理につい
ては、条件を変更せず、優先度の低いものから条件を変
更していくようにする。

【０２９５】ステップ６２７ｂでは、配信スケジューラ
タスク４００ｂに新規配信が不可能である旨をメッセー
ジにより伝え、ステップ６１１ｂに進む。ステップ６２
５ｂでは、変更した配信条件を配信管理テーブル４０１
０の各レコード４０１１に設定し、対応する配信条件テ
ーブル４０００のデータを再設定し、変更フラグ４００
４を「変更あり」に設定し、ステップ６２６ｂを実行す
る。

【０２９６】次に、ステップ６３１ｂでは、配信管理テ
ーブル４０１０を参照し、変更の対象となっているレコ
ード４０１１の内容の変更をすれば、既に配信中のデー
タのうち、それ以上転送レートを下げられないものがあ
る場合等、条件変更が不可能な場合の有無を判定し、条
件変更が可能な場合には、ステップ６３４ｂに進み、条
件変更が不可能な場合には、ステップ６３３ｂに進む
（ステップ６３２ｂ）。

【０２９７】ステップ６３３ｂにおける配信の可否の判
定も、ステップ６２２ｂと同様に、ＩＮＤＥＸテーブル
を参照して行なう。

【０２９８】なお、ステップ６３２ｂでは、配信管理テ
ーブルの優先度４０１３の情報を参照して、優先度の高
い配信処理については、条件を変更せず、優先度の低い
ものから条件を変更していくようにする。

【０２９９】ステップ６３３ｂでは、配信スケジューラ
タスク４００ｂに配信条件変更が不可能である旨をメッ
セージにより伝え、ステップ６１１ｂに進む。ステップ
６３４ｂでは、変更した配信条件を配信管理テーブル４
０１０の各レコード４０１１に設定し、対応する配信条
件テーブル４０００のデータを再設定し、変更フラグ４
００４を「変更あり」に設定する。ステップ６３５ｂで
は、配信スケジューラタスク４００ｂに配信条件可能で
ある旨を、メッセージにより返答し、ステップ６１１ｂ
に進む。

【０３００】次に、ステップ６４１ｂでは、配信の終了
したレコード４０１１を配信管理テーブル４０１０より
削除し、必要なら、他のレコードの配信条件も変更す
る。

【０３０１】最後に、ステップ６５１ｂでは、サービス
品質管理タスク６００ｂが使用した主メモリ１０２上の
メモリ空間等のリソースの開放を行なった後、マルチタ
スクＯＳ２００ｂにタスク６００ｂの終了を自ら要求
し、タスク６００ｂの処理を終了する。

【０３０２】なお、新規に配信を開始するクライアント
が低速回線を介したＭＰＥＧ１データの配信要求であれ
ば、例えば、通信媒体がＩＳＤＮであり、６４ｋｂ／ｓ
程度の転送レートであれば、セル１６に記述されたデー
タ量削減方法で削除された削除データを送信するように
し、通信媒体がアナログ回線であり、１４．４ｋｂ／ｓ
程度の転送レートであれば、セル１７に記述されたデー
タ量削減方法でで削除された削除データを送信するよう
にデータを転送すれば、クライアント２側において、デ
ータを受信しながらデコードして表示すること（リアル
タイム再生）も可能である。

【０３０３】次に、本発明にかかる第２の実施例におけ
るメディアサーバ１の削減データ生成タスク７００ｂの
処理内容について説明する。

【０３０４】図１４は、削減データ生成タスク７００ｂ
の処理内容を示すフローチャートである。

【０３０５】削減データ生成タスク７００ｂは、ユーザ
が、メディアサーバにクライアント２で共用する動画デ
ータを登録するときに、ユーザが指示を与えることによ
り、マルチタスクＯＳ２００ｂが生成し、起動する。

【０３０６】ステップ７０１ｂでは、ユーザから登録さ
れたＭＰＥＧ１動画の元データ６０００を読み込み、ス
テップ７１１ｂでは、元データ６０００を図９で説明し
た形式に整形し、ＩＮＤＥＸデータ４０３０に登録す
る。そして、ステップ７２１ｂでは、元データ６０００
より、図２のテーブル１０に示すセルで示される削減方
法にしたがって、複数の削減データ６０２０を生成し、
ＩＮＤＥＸデータ６０３０に登録する。

【０３０７】次に、本発明にかかる第２の実施例におけ
るクライアント２のメディア要求タスク９００ｂの処理
内容について説明する。

【０３０８】図１５は、メディア要求部９００の処理の
フローチャートである。

【０３０９】ステップ９０１ｂでは、ユーザから配信要
求のあるデータのファイル名や、配信されたデータに利
用方法の情報等を受け付ける。ここで、利用方法の情報
とは、配信された動画データをブラウジングに使うか、
詳細に鑑賞するといった情報である。また、かかる情報
は、ユーザが入力せずに、ブラウジングを目的とするア
プリケーションからの要求であれば、メディア要求タス
ク９００ｂが自動的にブラウジング用と判断するように
しても良い。ステップ９１１ｂでは、ユーザの用途か
ら、動きの滑らかさか、あるいは、精細度のいずれか
を、どの程度要求するかといった、動画の画質に関する
要求を評価し、そのデータを供給可能なメディアサーバ
１を、ＬＡＮ３、ＩＳＤＮ４に接続されているメディア
サーバの中から捜しだし、要求を満たすメディアサーバ
１を決定する。

【０３１０】ステップ９２１ｂでは、ステップ９１１ｂ
で決定したメディアサーバ１に、配信を希望する動画デ
ータのファイル名と、画質のユーザ要求とを、メッセー
ジによって送信し、データの配信を待つ。次に、ステッ
プ９３１ｂでは、メディアサーバ１からの返答を待ち、
「配信可能」であれば、受信したデータをマルチメディ
アデータ再生タスク１０００ｂにより表示し、再生が終
われば、本タスク９００ｂの処理を終了する。なお、メ
ディアサーバからの返答が「配信不可能」であれば、時
間をおいてリトライした後、さらに「配信不可能」であ
れば処理を終了するようにしても良い。

【０３１１】以上述べてきた、第１、２の実施例によれ
ば、メディアサーバ１が記憶している、ある動画データ
をクライアント２に配信する際に、ユーザの画質への要
求と、ネットワークや回線の伝送能力を含めたメディア
サーバのサービス能力とを考慮して、データ量の削減を
行ないながら削減データを配信することが可能になる。

【０３１２】また、データ量の削減制御も、時々刻々と
変化するサービス能力に追随して、動画のＧＯＰや音声
のＡＡＵの、切れ目に合わせて、データ量削減方式を切
り換えることができ、クライアント側では、配信を受け
る動画が乱れたり、音声がとぎれたりノイズが混入する
といったことが無くなる。以上のことから、メディアサ
ーバ１は、配信する動画データのデータ量を削減制御す
ることによる、ネットワークや回線、サーバの処理能力
を考慮したデータの提供が可能となり、クライアント２
のユーザは、希望する品質を有するデータの配信を受け
ることが可能になる。

【０３１３】なお、本実施例で述べたデータ量を削減し
ながらの配信は、予め配信データを図９に示すように整
形しておくため、データ量削除制御の処理負荷を増加さ
せることなく実現することが可能であり、複数クライア
ントの同時配信要求に対し、リアルタイムな配信処理が
実現できる。

【０３１４】また、転送するネットワークのトラヒック
が飽和する可能性がある場合にも、配信する動画データ
の転送レートを抑えながらの配信が可能であり、メディ
アサーバが同時に動画データを配信できるクライアント
の数を増加させることができる。この時、クライアント
ごとに優先度を設定することが可能であるため、優先度
の低いクライアントから、転送する動画のデータ量を削
除していくようにすることができ、ユーザが予め定めた
優先度にしたがった、ユーザの要求を満足するデータ提
供を実現できる。

【０３１５】

【発明の効果】以上のように、本発明によれば、各種の
コンピュータネットワーク環境において、動画等のマル
チメディアデータをクライアントに配信する際に、ユー
ザの希望する品質や、メディアサーバの接続しているネ
ットワークの伝送能力を考慮して、でー多量制御するこ
とが可能になる。したがって、公衆回線等の比較的転送
レートの低い伝送媒体を介しての動画データの配信も効
率良く行なえる。

【０３１６】また、転送するネットワークのトラヒック
が飽和する可能性がある場合にも、配信する動画データ
の転送レートを抑えながらの配信が可能であり、メディ
アサーバが、同時に動画データを配信可能なクライアン
ト数を増加させることが可能になる。この時、クライア
ントごとに優先度を設定することが可能であるため、優
先度の低いクライアントから、転送する動画のデータ量
を低減するように制御することができ、ユーザは予め優
先度を高くしておくことにより、画質の良いデータ配信
を受け続けることも可能である。

【０３１７】以上のことから、本発明によれば、各種の
ネットワーク環境において、メディアサーバ上にある動
画等のマルチメディアデータを、クライアントに効率良
く送信するこを可能にする。

【０３１８】

【図面の簡単な説明】

【図１】第１の実施例におけるネットワーク環境の説明
図である。

【図２】第１の実施例におけるＭＰＥＧ１動画データ量
の削減方法を示すテーブルの説明図である。

【図３】ＭＰＥＧ１動画データのフォーマットの説明図
である。

【図４】第１の実施例におけるＭＰＥＧ１動画データ量
削減方式の原理説明図である。

【図５】コンピュータ端末のハードウェアの構成図であ
る。

【図６】第１の実施例におけるメディアサーバとクライ
アントのソフトウェアの構成図である。

【図７】第１の実施例におけるメディアサーバの制御テ
ーブルの構成およびデータ関連を説明する説明図であ
る。

【図８】ＭＰＥＧ１動画および音声データフォーマット
と圧縮データパケットの関係の説明図である。

【図９】ＭＰＥＧ１データ整形方式の原理説明図であ
る。

【図１０】第１の実施例におけるＩＮＤＥＸデータの説
明図である。

【図１１】第１の実施例における配信スケジューラタス
クの処理内容を示すフローチャートである。

【図１２】第１の実施例におけるユーザ配信処理タスク
の処理内容を示すフローチャートである。

【図１３】第１の実施例におけるサービス品質管理タス
クの処理内容を示すフローチャートである。

【図１４】第１の実施例における配信データ整形タスク
の処理内容を示すフローチャートである。

【図１５】第１の実施例におけるクライアントのメディ
ア要求タスクの処理内容を示すフローチャートである。

【図１６】第２の実施例におけるメディアサーバとクラ
イアントのソフトウェアの構成図である。

【図１７】第２の実施例におけるメディアサーバの制御
テーブルの構成およびデータ関連を説明する説明図であ
る。

【図１８】第２の実施例におけるＩＮＤＥＸデータの説
明図である。

【図１９】第２の実施例における配信スケジューラタス
クの処理内容を示すフローチャートである。

【図２０】第２の実施例におけるユーザ配信処理タスク
の処理内容を示すフローチャートである。

【図２１】第２の実施例におけるサービス品質管理タス
クの処理内容を示すフローチャートである。

【図２２】第２の実施例における削除データ生成タスク
の処理内容を示すフローチャートである。

【図２３】第２の実施例におけるクライアントのメディ
ア要求タスクの処理内容を示すフローチャートである。

【符号の説明】

１…メディアサーバ、２…クライアント、４００…配信
スケジューラタスク、５００…ユーザ配信処理タスク、
６００…サービス品質管理タスク、７００ａ…配信デー
タ整形タスク、７００ｂ…削除データ生成タスク

───────────────────────────────────────────────────── フロントページの続き (72)発明者 山田 剛裕 神奈川県川崎市麻生区王禅寺1099番地 株 式会社日立製作所システム開発研究所内 (72)発明者 田中 和明 神奈川県横浜市戸塚区戸塚町5030番地 株 式会社日立製作所ソフトウェア開発本部内 (72)発明者 佐藤 義行 神奈川県海老名市下今泉810番地 株式会 社日立製作所オフィスシステム事業部内

Claims (20)

【特許請求の範囲】
1. 【請求項１】動画データを、１種類以上記憶するための
   記憶手段と、動画データのデータ量を、予め定められた
   複数のデータ量削減規則のうちのいずれかに従って、削
   減するデータ量削減手段と、削減されたデータを外部に
   出力する外部出力手段と、前記記憶手段に記憶されてい
   る、いずれかの動画データへのアクセス命令を受け付け
   る入力手段と、入力されたアクセス命令に応じて、デー
   タ量削減のための制御を行なう制御手段と、１以上のア
   クセス命令に対して削減されたデータの量の総和を演算
   する削減データ量演算手段とを備え、 該制御手段は、入力手段がアクセス命令を受け付けたと
   き、前記削減データ量演算手段の演算結果に対応して予
   め定めた規則に従って、前記データ量削減規則のいずれ
   かを選択して、前記データ量削減手段を駆動し、削減さ
   れたデータを、前記外部出力手段に与えることを特徴と
   する情報処理システム。
2. 【請求項２】動画データを、１種類以上記憶するための
   記憶手段と、動画データのデータ量を、予め定められた
   複数のデータ量削減規則のうちのいずれかに従って、削
   減するデータ量削減手段と、削減されたデータを外部に
   出力する外部出力手段と、前記記憶手段に記憶されてい
   る、いずれかの動画データへのアクセス命令を受け付け
   る入力手段と、入力されたアクセス命令に応じて、デー
   タ量削減のための制御を行なう制御手段と、アクセス命
   令に対応する動画データの、動きベクトルの合計値およ
   び離散余弦変換（DCT変換）後の所定周波数以上の成分
   の大きさを求め、記憶しておく動画情報検出記憶手段と
   を備え、 該制御手段は、入力手段がデータアクセス命令を受け付
   けたとき、前記動画情報検出記憶手段の記憶内容に対し
   て、予め一意に定めている前記データ量削減規則を選択
   して、前記データ量削減手段を駆動し、削減されたデー
   タを、前記外部出力手段に与えることを特徴とする情報
   処理システム。
3. 【請求項３】動画データを提供するサーバと、該サーバ
   と通信媒体を介して接続され、動画データの提供を受け
   る少なくとも１以上のクライアントとを有して構成され
   る情報処理システムであって、 前記サーバは、動画データを、１種類以上記憶するため
   の記憶手段と、動画データのデータ量を、予め定められ
   た複数のデータ量削減規則のうちのいずれかに従って、
   削減するデータ量削減手段と、接続された通信媒体を介
   して、削減されたデータをクライアント側に出力する出
   力手段と、接続された通信媒体を介して、前記記憶手段
   に記憶されている、いずれかの動画データへのアクセス
   命令を受け付ける入力手段と、入力されたアクセス命令
   に応じて、データ量削減のための制御を行なう制御手段
   と、１以上のアクセス命令に対して削減されたデータ量
   の総和を演算する削減データ量演算手段と、通信媒体ご
   との出力データ量を検出する伝送量検出手段とを有し、 前記制御手段は、入力手段が、サーバからのアクセス命
   令を受け付けたとき、前記削減データ量演算手段の演算
   結果、および、前記伝送量検出手段の検出結果、に対応
   して予め定めた規則に従って、前記データ量削減規則の
   いずれかを選択して、前記データ量削減手段を駆動し、
   削減されたデータを、前記出力手段に与える機能を有す
   る、ことを特徴とする情報処理システム。
4. 【請求項４】請求項３において、前記予め定めた規則
   は、前記削減データ量演算手段の演算結果および前記伝
   送量検出手段の検出結果の少なくとも一方が、各々に対
   して予め定められているしきい値を越えたとき、前記デ
   ータ量削減規則のうちから、前記削減データ量演算手段
   の演算結果および前記伝送量検出手段の検出結果の双方
   が、各々に対して予め定められているしきい値を越えな
   いようにする規則である、情報処理システム。
5. 【請求項５】請求項３において、前記サーバが備える記
   憶手段には、動画データに対して優先度を付して記憶
   し、前記制御手段は、前記削減データ量演算手段の演算
   結果および前記伝送量検出手段の検出結果の少なくとも
   一方が、各々に対して予め定められているしきい値を越
   えたときに始めて、優先度の小さな順に動画データを前
   記データ量削減手段に与える機能を有することを特徴と
   する情報処理システム。
6. 【請求項６】請求項１、２、３、４および５のいずれか
   において、前記データ量削減規則は、画素数、ＡＣ係数
   を含む空間的解像度およびフレーム数を含む時間的解像
   度の組み合わせで定まる解像度パラメータを用いたデー
   タ削減である、ことを特徴とする情報処理システム。
7. 【請求項７】音声付き動画データを、動画データと音声
   データとに分離して、動画データの１以上のフレームデ
   ータを集めた第１データ群、第１データ群に対応する音
   声データを集めた第２データ群を生成し、さらに、第
   １、第２データ群を組み合わせた第３データ群を生成
   し、該第３データ群を連続して構成した音声付き動画デ
   ータを生成するデータ整形手段と、 該データ整形手段により生成された音声付き動画データ
   と一意的に対応して存在し、第３データ群毎に、該第３
   データ群のデータサイズ、該音声付き動画データの先頭
   から各第３データ群の先頭までのデータサイズを記憶す
   るインデクスデータテーブルと、 画素数、ＡＣ係数の個数、フレームレート数を組み合わ
   せた、データ量削減パラメータを複数種類記述したデー
   タ削除テーブルと、 前記データ量削減パラメータのいずれかを選択するユー
   ザ要求を受け付ける第１機能、音声付き動画データ量の
   削除を行なう第２機能、削除データを出力する第３機能
   を有する制御手段と、該制御手段に接続され、削除デー
   タを伝送出力する１以上の通信媒体とを備え、 前記制御手段は、前記ユーザ要求、および、各通信媒体
   に出力される削除データ量を参照して、予め定めた規則
   に従って、データ削除テーブルからデータ量削減パラメ
   ータを選択して、さらに、インデクスデータテーブルで
   指定される第３データ群のデータサイズを参照して、該
   第３データ群の順序を調べ、順番に、該第３データ群
   の、選択したデータ量削減パラメータによるデータ量の
   削除処理を行なうことを特徴とする情報処理システム。
8. 【請求項８】請求項３、４、５および６のいずれかにお
   いて、 前記通信媒体を、伝送速度６４（ｋｂｉｔ／秒）のＩＳ
   ＤＮ回線で構成し、 前記制御手段は、前記データ量削減規則として、画素数
   を、縦１２０画素、横１７６画素とする、予め定めてあ
   る規則を選択する機能を有することを特徴とする情報処
   理システム。
9. 【請求項９】請求項３、４、５および６のいずれかにお
   いて、 前記通信媒体を、伝送速度１４．４（ｋｂｉｔ／秒）の
   アナログ回線で構成し、前記制御手段は、前記データ量
   削減規則として、画素数を、縦６０画素、横８８画素と
   する、予め定めてある規則を選択する機能を有すること
   を特徴とする情報処理システム。
10. 【請求項１０】１種類以上の元動画データと、各元動画
    データに対して、そのデータ量を予め定められた複数の
    データ量削減規則に従って削減した複数種類の削減デー
    タとを記憶するための記憶手段と、削減データを外部に
    出力する外部出力手段と、前記記憶手段に記憶されてい
    る、いずれかの元動画データへのアクセス命令を受け付
    ける入力手段と、入力されたアクセス命令に応じて、削
    減データを選択し、前記外部出力手段に与える制御を行
    なう制御手段と、所定時間内に、外部出力手段が出力す
    る削除データ量の総和を演算する削減データ量演算手段
    とを備え、 該制御手段は、入力手段がアクセス命令を受け付けたと
    き、前記削減データ量演算手段の演算結果に対応して予
    め定めた規則に従って、前記削除データのいずれかを選
    択して、選択した削減データを前記外部出力手段に与え
    ることを特徴とする情報処理システム。
11. 【請求項１１】動画データを提供するサーバと、該サー
    バと通信媒体を介して接続され、動画データの提供を受
    ける少なくとも１以上のクライアントとを有して構成さ
    れる情報処理システムであって、 前記サーバは、１種類以上の元動画データと、各元動画
    データに対して、そのデータ量を予め定められた複数の
    データ量削減規則に従って削減した複数種類の削減デー
    タとを記憶するための記憶手段と、接続された通信媒体
    を介して、削減データをクライアント側に出力する出力
    手段と、接続された通信媒体を介して、前記記憶手段に
    記憶されている、いずれかの元動画データへのアクセス
    命令を受け付ける入力手段と、入力されたアクセス命令
    に応じて、削減データを選択し、前記出力手段に与える
    制御を行なう制御手段と、所定時間内に、出力手段が出
    力する削除データの量の総和演算を行なう削減データ量
    演算手段と、通信媒体ごとの出力データ量を検出する伝
    送量検出手段とを有し、 該制御手段は、入力手段がクライアントからのアクセス
    命令を受け付けたとき、前記削減データ量演算手段の演
    算結果、および、前記伝送量検出手段の検出結果、に対
    応して予め定めた規則に従って、前記削除データのいず
    れかを選択して、選択した削減データを、前記出力手段
    に与える機能を有することを特徴とする情報処理システ
    ム。
12. 【請求項１２】請求項１１において、前記予め定めた規
    則は、前記削減データ量演算手段の演算結果および前記
    伝送量検出手段の検出結果の少なくとも一方が、各々に
    対して予め定められているしきい値を越えたとき、前記
    削減データのうちから、前記削減データ量演算手段の演
    算結果および前記伝送量検出手段の検出結果の双方が、
    各々に対して予め定められているしきい値を越えないよ
    うにすることである、情報処理システム。
13. 【請求項１３】請求項１１において、前記サーバが備え
    る記憶手段には、削減データに対して優先度を付して記
    憶し、前記制御手段は、前記削減データ量演算手段の演
    算結果および前記伝送量検出手段の検出結果の少なくと
    も一方が、各々に対して予め定められているしきい値を
    越えたときに始めて、優先度の小さな順に、削減データ
    を前記出力手段に与える機能を有することを特徴とする
    情報処理システム。
14. 【請求項１４】請求項１０、１１、１２、および１３の
    いずれかにおいて、前記削減データは、画素数、ＡＣ係
    数を含む空間的解像度およびフレーム数を含む時間的解
    像度のうち少なくとも一方の解像度の変更によって、元
    動画データのデータ量を削減したデータである、ことを
    特徴とする情報処理システム。
15. 【請求項１５】請求項１１において、 前記制御手段は、ある元動画データに対する削除データ
    の１つを前記出力手段に与える際に、前記削減データ量
    演算手段の演算結果、および、前記伝送量検出手段の検
    出結果の少なくとも一方が、各々に対して予め定められ
    ているしきい値を越えたとき、次に、前記削減データ量
    演算手段の演算結果が小さくなる、削減データの種類
    を、所定動画データ単位ごとに選択しながら、選択した
    種類に対応した削除データを、前記出力手段に与える機
    能を有することを特徴とする情報処理システム。
16. 【請求項１６】請求項１１、１２、１３、１４および１
    ５のいずれかにおいて、 前記通信媒体を、伝送速度６４（ｋｂｉｔ／秒）のＩＳ
    ＤＮ回線で構成し、 前記記憶手段には、画素数を、縦１２０画素、横１７６
    画素とする削除データを予め記憶しておき、 前記制御手段は、画素数を、縦１２０画素、横１７６画
    素とする削除データを前記出力手段に与える機能を有す
    ることを特徴とする情報処理システム。
17. 【請求項１７】請求項１１、１２、１３、１４および１
    ５のいずれかにおいて、 前記通信媒体を、伝送速度１４．４（ｋｂｉｔ／秒）の
    アナログ回線で構成し、前記記憶手段には、画素数を、
    縦６０画素、横８８画素とする削除データを予め記憶し
    ておき、 前記制御手段は、画素数を、縦６０画素、横８８画素と
    する削除データを前記出力手段に与える機能を有するこ
    とを特徴とする情報処理システム。
18. 【請求項１８】請求項３、４、５、６、１１、１２、１
    ３、１４および１５のいずれかにおいて、前記動画デー
    タは、ＭＰＥＧ１方式により既に圧縮された圧縮データ
    とし、前記クライアント側は、該圧縮データを伸長する
    データ伸長手段を備えることを特徴とする情報処理シス
    テム。
19. 【請求項１９】請求項３、４、５、および６において、
    前記サーバの入力手段は、前記クライアントが備える命
    令送出手段を介して与えた、ブラウジングを要求する命
    令であるブラウジング命令を受け付ける機能を有し、 前記制御手段は、入力手段がブラウジング命令を受け付
    けたとき、該命令に対して予め定めているデータ量削減
    規則を選択して、前記データ量削減手段を駆動し、削減
    処理されたデータを前記出力手段に与える機能を有する
    ことを特徴とする情報処理システム。
20. 【請求項２０】請求項１１、１２、１３、１４および１
    ５において、前記サーバの入力手段は、前記クライアン
    トが備える命令送出手段を介して与えた、ブラウジング
    を要求する命令であるブラウジング命令を受け付ける機
    能を有し、 前記制御手段は、入力手段がブラウジング命令を受け付
    けたとき、該命令に対して予め定めている削除データを
    選択して、選択した削除データを前記出力手段に与える
    機能を有することを特徴とする情報処理システム。