JP3609488B2 - 情報処理システム - Google Patents
情報処理システム Download PDFInfo
- Publication number
- JP3609488B2 JP3609488B2 JP11867295A JP11867295A JP3609488B2 JP 3609488 B2 JP3609488 B2 JP 3609488B2 JP 11867295 A JP11867295 A JP 11867295A JP 11867295 A JP11867295 A JP 11867295A JP 3609488 B2 JP3609488 B2 JP 3609488B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- reduction
- amount
- unit time
- distribution
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Compression, Expansion, Code Conversion, And Decoders (AREA)
- Multi Processors (AREA)
Description
【０００１】
【産業上の利用分野】
本発明は、サーバ側がクライアント側にマルチメディアデータを提供するシステムに係り、特に、各種のネットワーク環境下において、トラフィック飽和させることなく、動画データをクライアントに配信するシステムに関する。
【０００２】
【従来の技術】
近年、ネットワーク環境の整備、拡張が進展し、ローカルエリアネットワーク（ＬＡＮ）、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）、アナログ回線等の公衆回線によって構成されるＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の、各種のネットワーク環境において、ネットワークの接続状態を意識せずに、ネットワークに接続されたある端末装置から他の端末装置へと、動画データ等のマルチメディアデータのやりとりを行なうことが可能になってきた。
【０００３】
ところで、動画データや音声データは、基本的にデータ量が大きいため、これまで、データの蓄積、伝送等の処理を行なうためには、効率良くデータを圧縮した後に、圧縮データに対して所望の処理を行なうことが提案されている。
【０００４】
代表的な圧縮方法としては、例えば、ＩＳＯにより推奨されている「ＭＰＥＧ１（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｇｒｏｕｐ Ｐｈａｓｅ １）」等の圧縮方法が挙げられる。
【０００５】
しかしながら、このような圧縮処理を行なっても、マルチメディアデータのデータ量は、通常、膨大な量となっており、ネットワークのトラヒックの飽和を招いたり、また、例えば、サーバからクライアントにマルチメディアデータの伝送を行なう際には、非常に長い伝送時間を要する等の課題が存在していた。
【０００６】
この様な課題を解決する従来技術を開示している文献としては、特開平６−７０１７４号公報等が挙げられ、この公報では、動画データを離散余弦変換した変換データの高周波成分を削除することによって、動画データのデータ量を削減するための技術が開示されている。
【０００７】
また、ネットワークの伝送帯域を、動画データ伝送のための伝送帯域に設定し、提供する動画データのフレーム数を適宜低減することによって、動画データの伝送レートの調整を行なって、安定した動画データの供給を保証するファイルサーバが提供されている。
【０００８】
【発明が解決しようとする課題】
ところで、上述した従来技術のうち、特開平６−７０１７４号公報に開示された技術は、動画データのみのデータ量の削減には有効であるもののが、一般的に動画データには、音声データが付随しているものが多く、特に、データ量が削減された動画データと、音声データの同期の保証については考慮されていない。
【０００９】
また、動画データのフレーム数の削減のみで、提供する動画データに対する伝送レートの調整を行なっていては、変化の激しい動画像を有する動画データでは、動きの滑らかさが失われる等の問題があり、ユーザの画質への要求を考慮しながらデータ量の削減を行なう必要があった。
【００１０】
また、ネットワーク環境で動画データを供給するファイルサーバは、動画データ伝送のための伝送帯域を確保するため、クライアント数が限られている場合においては、安定した動画データの供給が可能であるものの、クライアント数が所定数以上になったときには、その途端に、新たなクライアントに対する動画データの提供が不可能になったり、既に動画データの提供を行なっているクライアントに対する、動画データの提供に影響が及び、クライアントへの動画データの提供が安定して行なえなくなる事態の発生を招いてしまうという課題が存在していた。
【００１１】
そこで、本発明は、以上のような課題に鑑みて創作したもので、サーバが提供するマルチメディアデータのデータ量を、ユーザの要求に対して提供するデータの伝送レートや、サーバに接続されるネットワークの伝送能力等を考慮して制御し、ユーザ側に配信することによって、たとえ接続されるネットワークの伝送レートが低い場合であっても、適切な品質のマルチメディアデータを提供するシステムを実現することを目的とし、また、動画でデータを提供する際には、動画データと音声データとのと同期がとれた動画データを提供することも可能にする。
【００１２】
【課題を解決するための手段】
上記課題を解決するため、以下の手段が考えられる。
【００１３】
動画データを提供するサーバと、該サーバと通信媒体を介して接続され、動画データの提供を受ける少なくとも１以上のクライアントとを有して構成される情報処理システムである。
【００１４】
そして、サーバは、動画データを、１種類以上記憶するための記憶手段と、動画データのデータ量を、予め定められた複数のデータ量削減規則のうちのいずれかに従って、削減するデータ量削減手段と、接続された通信媒体を介して、削減されたデータをクライアント側に出力する出力手段と、接続された通信媒体を介して、前記記憶手段に記憶されている、いずれかの動画データへのアクセス命令を受け付ける入力手段と、入力されたアクセス命令に応じて、データ量削減のための制御を行なう制御手段と、１以上のアクセス命令に対して削減されたデータ量の総和を演算する削減データ量演算手段と、通信媒体ごとの出力データ量を検出する伝送量検出手段とを有した構成とする。
【００１５】
前記制御手段は、入力手段がクライアントからのアクセス命令を受け付けたとき、前記削減データ量演算手段の演算結果、および、前記伝送量検出手段の検出結果、に対応して予め定めた規則に従って、前記データ量削減規則のいずれかを選択して、前記データ量削減手段を駆動し、削減されたデータを、前記出力手段に与える機能を有する。
【００１６】
また、以下の示すような態様も考えられる。
【００１７】
動画データを提供するサーバと、該サーバと通信媒体を介して接続され、動画データの提供を受ける少なくとも１以上のクライアントとを有して構成される情報処理システムである。
【００１８】
そして、前記サーバは、１種類以上の元動画データと、各元動画データに対して、そのデータ量を予め定められた複数のデータ量削減規則に従って削減した複数種類の削減データとを記憶するための記憶手段と、接続された通信媒体を介して、削減データをクライアント側に出力する出力手段と、接続された通信媒体を介して、前記記憶手段に記憶されている、いずれかの元動画データへのアクセス命令を受け付ける入力手段と、入力されたアクセス命令に応じて、削減データを選択し、前記出力手段に与える制御を行なう制御手段と、所定時間内に、出力手段が出力する削除データの量の総和演算を行なう削減データ量演算手段と、通信媒体ごとの出力データ量を検出する伝送量検出手段とを有して構成される。
【００１９】
前記制御手段は、入力手段がクライアントからのアクセス命令を受け付けたとき、前記削減データ量演算手段の演算結果、および、前記伝送量検出手段の検出結果、に対応して予め定めた規則に従って、前記削除データのいずれかを選択して、選択した削減データを、前記出力手段に与える機能を有する。
【００２０】
【作用】
サーバは、動画データを提供し、クライアントは、通信媒体を介して、サーバからの動画データの提供を受ける。
【００２１】
クライアント側では、命令送出手段によって、通信媒体を介してアクセス命令を命令を送る。
【００２２】
一方、サーバ側は、記憶手段に、動画データを１種類以上記憶しており、データ量削減手段によって、動画データのデータ量を、予め定められた複数のデータ量削減規則のうちのいずれかに従って削減する。
【００２３】
出力手段は、通信媒体を介して、削減されたデータをクライアント側に出力する。
【００２４】
入力手段は、通信媒体を介して送られてきた、前記記憶手段に記憶されている、いずれかの動画データへのアクセス命令を受け付け、さらに、制御手段は、入力されたアクセス命令に応じて、データ量削減のための制御を行なう。
【００２５】
なお、削減データ量演算手段は、１以上のアクセス命令に対して削減されたデータ量の総和を演算を行ない、また、伝送量検出手段は、通信媒体ごとの出力データ量を検出する。
【００２６】
そして、制御手段は、入力手段によってアクセス命令を受け付けたとき、前記削減データ量演算手段の演算結果、および、前記伝送量検出手段の検出結果、に対応して予め定めた規則に従って、前記データ量削減規則のいずれかを選択して、前記データ量削減手段を駆動する。この結果、削減されたデータは、出力手段に与えられ、クライアント側に送られる。
【００２７】
クライアント側の表示手段は、送られてきたデータを表示する。
【００２８】
以上は、クライアントからの要求にしたがって動画データを提供する際、サーバは、データ量削減規則を用いて、動画データのデータ量を削減してクライアント側に提供する。
【００２９】
また、他の態様によれば、以下のような作用となる。
【００３０】
クライアント側では、命令送出手段によって、通信媒体を介してアクセス命令を命令を送る。
【００３１】
一方、サーバは、記憶手段に、１種類以上の元動画データと、各元動画データに対して、そのデータ量を予め定められた複数のデータ量削減規則に従って削減した複数種類の削減データとを記憶しており、また、出力手段は、通信媒体を介して、削減データをクライアント側に出力する。
【００３２】
入力手段は、記憶手段に記憶されている、いずれかの元動画データへのアクセス命令を受け付け、さらに、制御手段は、入力手段によってアクセス命令を受け付けたとき、削減データを選択し、出力手段に与える制御を行なう。
【００３３】
なお、削減データ量演算手段は、所定時間内に出力手段が出力する削除データの量の総和演算を行ない、また、伝送量検出手段は、通信媒体ごとの出力データ量を検出する。
【００３４】
そして、制御手段は、入力手段によってアクセス命令を受け付けたとき、前記削減データ量演算手段の演算結果、および、前記伝送量検出手段の検出結果、に対応して予め定めた規則に従って、前記削除データのいずれかを選択して、選択した削減データを、前記出力手段に与えクライアント側に送信する。
【００３５】
クライアント側の表示手段は、送られてきたデータを表示する。
【００３６】
以上は、クライアントからの要求にしたがって動画データを提供する際、サーバが、複数種類の削除データのうちのいずれかを送信することによって、動画データのデータ量を削減してクライアント側に提供する。
【００３７】
以上のような動作によれば、通常ではトラヒックが飽和するような動画データの転送時においても、トラヒックの飽和を回避し、各クライアントに動画データの提供を円滑に行なうことを可能にする。
【００３８】
【実施例】
以下、本発明にかかる実施例を、図面を参照して説明する。
【００３９】
まず、本発明を、マルチメディアデータをネットワークを介して、少なくとも１台の端末（クライアント）に配信する、マルチメディアデータサーバ（以下適宜「メディアサーバ」や「サーバ」と記す）に適用した場合について説明する。
【００４０】
第１の実施例は、サーバが、クライアントから配信要求されたデータのデータ量を、予め定めた規則に従って削減し、削減データを配信する実施例である（なお、本実施例を、便宜上「ハード型」と称する）。
【００４１】
図１は、第１の実施例におけるメディアサーバのネットワーク環境の一例を示している。
【００４２】
１ａ、１ｂは、メディアサーバ、２ａ、２ｂ、２ｃ、２ｄは、クライアント、５ａ、５ｂは、ゲートウエイであり、メディアサーバ、クライアント、ゲートウエイは、コンピュータ端末として実現できる。また、３ａ、３ｂ、３ｃは、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であり、さらに詳しく述べると、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）−ＬＡＮ等が挙げられる。
【００４３】
また、４は、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）であるが、ＩＳＤＮの替わりに、アナログ回線等の公衆回線や、該公衆回線と同様の伝送技術を利用した専用回線を用いても良い。
【００４４】
前述した各コンピュータ端末（単に「端末」とも記す）は、特に、以下に述べるような機能を有する。
【００４５】
端末１ａ、１ｂは、マルチメディアデータを、ネットワーク３やＩＳＤＮ４を介して、複数のコンピュータ端末に配信する機能を有するメディアサーバである。
【００４６】
端末１ａは、ＬＡＮ３ａに接続され、また、端末１ｂは、ＬＡＮ３ａ、３ｂ、およびＩＳＤＮ４に接続され、該ＬＡＮ３ａ、３ｂやＩＳＤＮ４に接続された他の端末との間で、所望のデータの伝送が行なわれる。
【００４７】
端末２ａ、２ｂ、２ｃ、および２ｄは、所定のメディアサーバとの間で、マルチメディアデータを含む各種のデータの伝送が可能であり、メディアサーバによって配信された、動画データ、音声データ等のマルチメディアデータを受信し、受信したデータを再生する機能を有している。なお、端末２ａは、ＬＡＮ３ａに、端末２ｂは、ＩＳＤＮ４に、端末２ｃは、ＬＡＮ３ｃに、端末２ｄは、ネットワーク３ｂに、各々接続されており、ＬＡＮ３やＩＳＤＮ４に接続された他の端末との間で、所望のデータの伝送が可能である。
【００４８】
端末５ａ、５ｂは、ネットワークや回線等の伝送媒体の物理的、および、論理的な伝送方式の変換を行い、異なる伝送方式を用いる伝送媒体間に渡るデータ伝送を可能とする機能を有しており、一般に、このような機能は、ゲートウェイ機能、あるいは、ブリッジ機能と呼ばれており、このような機能を有するコンピュータ端末のことを「ゲートウェイ」、あるいは「ブリッジ」と呼している。
【００４９】
また、複数の伝送媒体に渡るデータ伝送の経路制御を行う機能を有するという意味において、この機能をルータ（あるいはルーティング）機能と称し、かかる機能を有するコンピュータ端末を「ルータ」と称することもある。特に、あるネットワーク３ａから他のネットワーク３ｂへ、データ伝送を行なう機能は、ルータ機能そのものである。
【００５０】
このようなネットワーク環境下において、メディアサーバ１ａおよび１ｂは、全クライアント、２ａ、２ｂ、２ｃ、２ｄに対して、マルチメディアデータを配信することが可能である。
【００５１】
なお、メディアサーバ１ｂは、ＩＳＤＮ４、ＬＡＮ３ａ、３ｂに接続されており、それぞれの伝送媒体に接続されたコンピュータ端末との間でデータの橋渡しを行なうことが可能であるため、ゲートウェイ端末５ａと同等の機能を有するように構成されている。
【００５２】
次に、本発明の第１の実施例における、メディアサーバ１（１ａ、１ｂ）のマルチメディアデータのデータ量削減方法、削減データの配信方法の原理について説明する。
【００５３】
メディアサーバ１は、ユーザ（クライアント）からの品質要求と、ＬＡＮ３やＩＳＤＮ４の伝送速度等に起因するサービス能力を考慮して、マルチメディアデータのデータ量を削減処理し、削減処理されたデータ（以下、適宜「削減データ」と称する）のクライアントへの配信を行う。
【００５４】
以下の説明では、配信対象となるマルチメディアデータとして、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）方式で圧縮された圧縮動画データを例にとって説明する。
【００５５】
図２は、メディアサーバ１が、ＭＰＥＧ方式、特に、ＭＰＥＧ１方式の圧縮方式を使用して圧縮した圧縮動画データを配信する場合の、該圧縮動画データのデータ量削減方式１０の内容を示した図である。
【００５６】
この図において、行方向（横方向）には、ユーザの画質に対する品質要求の程度をとる。一例として、１０では、動き、あるいは、画像の精細度の優先度を示す。通常、動画のデータ量と画質とは、トレードオフの関係にあり、同じデータ量であるならば、動画の精細度を優先する場合は、例えば、単位時間あたりのフレーム数を減少させる等の処理を行なって、可能な限り動きの滑らかさが損なわれるようにデータ量の削除を行なわざるを得ず、逆に、動画の動きの滑らかさを優先する場合には、例えば、１フレームの画素数を間引いて、画像の精細度を落として、データ量の削除を行なわざるを得ない。
【００５７】
図２の１０において、列方向（縦方向）には、元の動画のデータ量を「１００」とした場合の、同一動画データのデータ量をとる。即ち、該図２の１０の下の行にいくほど、データ量は減少している。
【００５８】
なお、ここでは動画データのデータ量を削除するためのパラメータとして、「画素数、ＡＣ係数の上限値、フレーム数」の組み合わせを採用し、１つの組み合わせを「セル」と称している。したがって、図２中の、１１、１２、１３、１４、１５、１６、１７は、各々セルである。
【００５９】
例えば、横軸上の中間位置に存在するセル１１の意味するところは、元の動画データのデータ量を、動きの滑らかさと、精細度を同程度に優先しながら、そのデータ量を「５０（％）」に削減する場合の、具体的なデータ量削減方法を示すものである。以下、各セルに対応するデータ量削減のためのパラメータをデータ量削減パラメータと呼ぶ。したがって、セル１１の場合、データ量削減パラメータは、「画素数：３５２×２４０」、「ＡＣ係数の上限値：３〜４」、「フレーム数：１５（ｆｐｓ）」となっている。
【００６０】
データ量削減パラメータとして、図２では、画素数の削減、空間周波数成分の交流成分（ＡＣ成分）上限の制限、および、１秒間のフレーム数の削減を挙げてある。例えば、動画像の動きの滑らかさと精細度を同程度に優先しながら（即ち、横軸の中間位置に存在するセルを採用する）、データ量を、元データの「５０（％）」に削減するには、元の動画データに比べて、画素数を減らさず（同上）、ＡＣ成分の上限を３〜４個にし、フレーム数を半分にすることにより達成されることを示している。
【００６１】
このように、セル１１に記述された複数のパラメータを組み合わせて、すなわち、セル１１に示されているデータ量削減パラメータを使用して、データ量の削減処理を行なうことによって、データ量の制御を行なえる。すなわち、サーバは、クライアントの要求等を考慮しながら、あるセルを選択し、選択したセルに示された、データ量削減パラメータを使用して、データ量の削減処理を実行し、削減データの配信を行なう。なお、個々の削減パラメータの詳細については、後述する。
【００６２】
さて、配信する動画データのデータ量の制御は、図２の１０を用いて、次のように行う。
【００６３】
まず、ユーザ（クライアント）からの配信要求が発生した場合、メディアサーバ１では、図２の１０を参照し、ユーザの要求と、配信（サービス）能力を考慮したにデータ量となるように、配信時の初期データ量削減パラメータを決定し、該パラメータに従って、配信対象の動画データのデータ量を削減して配信を行なう。ここで、配信（サービス）能力とは、例えば、サーバに接続されている各通信媒体の、通信許容伝送レート等が考えられる。ユーザの要求のみならず、サーバに接続されている各通信媒体の、通信許容伝送レートを越えないことを条件として、データ量の削減処理が行なわれる。
【００６４】
これを仮に、セル１１に示されたデータ量削減パラメータを採用するとし、配信の途中で、ユーザ要求が、更に動きの滑らかさを優先するように変更された場合には、（横軸上で右側に存在する）セル１２で示されたデータ量削減パラメータに変更し、また、精細度を優先するように変更された場合は、（横軸上で左側に存在する）セル１３で示されたデータ量削減パラメータに変更し、それぞれ変更したパラメータを使用して、配信対象の動画データのデータ量を削減して、削減データを配信する。
【００６５】
また、セル１１に示されたデータ量削減パラメータを使用して削減処理を行なった削除データの配信中に、メディアサーバ１のサービス能力が低下し、更にデータ量を削減する必要があるときには、（縦軸下方向に存在する）セル１５に示されたデータ量削減パラメータに変更し、また、サービス能力が回復して、配信データ量を増加することが可能になれば、（縦軸上方向に存在する）セル１４に示された符号量削減パラメータに変更し、それぞれ変更したパラメータに従って、配信対象である動画データのデータ量を削減処理して、削減データを配信する。
【００６６】
さらに、ＭＰＥＧ１動画データのデータ量の削減方式について説明する。
【００６７】
その前に、ＭＰＥＧ１方式で圧縮処理された圧縮動画データのフォーマットについて説明する。ただし、ここでは本発明の説明にぜひとも必要な事項の説明を行なうのみとする。ＭＰＥＧの符号化方式やフォーマットについて記載されている文献は多数存在し、例えば、「ＡＳＣＩＩ社刊「最新ＭＰＥＧ教科書」（１１０から１２８頁等）」に述べられている。
【００６８】
図３は、ＭＰＥＧ１動画データのフォーマットの説明図である。
【００６９】
動画の画像データ４０は、ＭＰＥＧ１ビデオ符号器４１により、また、音声データ４３は、ＭＰＥＧ１オーディオ符号器４４により、それぞれ符号化され、所定サイズの圧縮動画データパケット４２と、圧縮音声データパケット４５とにパケット化される。ＭＰＥＧ１システム復号器４６は、パケット化された動画データ４２と音声データ４５とを、到着順に、パケットヘッダ等の情報を付加して、ＭＰＥＧ１システムストリーム４７として出力する。
【００７０】
次に、図４に、ＭＰＥＧ１動画データのデータ量削減方式の原理説明をするための図を示す。本実施例においては、画素数を削減する方式、圧縮動画データの空間周波数の高周波成分を削減する（ＡＣ係数の数の上限値の削減）方式、および、フレーム数を削除する方式について説明する。
【００７１】
まず、ＭＰＥＧ１方式で圧縮された動画データ（ＭＰＥＧ１圧縮動画データ）のデータ構造について説明する。ＭＰＥＧシステムストリーム４７から、圧縮動画データパケット４２だけを取り出して、圧縮（再生）順に並べると、ＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ）と呼ばれる単位（５０）に分かれており、ＧＯＰは、さらに、Ｉ（Ｉｎｔｒａ）フレーム５１、Ｐ（Ｐｒｅｄｉｃｔｉｖｅ）フレーム５３、および、Ｂ（Ｂｉｄｉｒｅｃｔｉｏｎａｌｌｙ ｐｒｅｄｉｃｔｉｖｅ）フレーム（５２、５４）から構成される。Ｉフレーム５１は、基準フレームとも称され、該フレーム内の画素データのみを使用して、他のフレームとは独立して符号化（フレーム内予測により符号化）するフレームであり、従って、伸長して再生する場合でも、他のフレームのデータを必要としない。
【００７２】
次に、Ｐフレーム５３は、時間的に「前」に存在するフレームとの相関性を利用するフレーム間予測によって、符号化するフレームであり、Ｂフレーム５２および５４は、時間的に「前後」のフレームとの相関性を利用するフレーム間予測によって、符号化するフレームである。ＧＯＰは、少なくともＩフレームを１枚含むフレーム群のことであり、１つのＧＯＰは、Ｉ、Ｐ、およびＢフレームの符号化データを有して構成されている。
【００７３】
さらに、Ｉ、Ｐ、およびＢの各フレームは、元動画像データのフレームデータの垂直・水平各８画素（全６４画素）データを単位に、離散コサイン変換することによって得られたＤＣＴ（Ｄｉｓｃｒｅｔｅ Ｃｏｓｉｎｅ Ｔｒａｎｓｆｏｒｍ）係数からなる、複数のブロック５５から構成される。
【００７４】
図４の左下部に記載した図は、ブロック５５の内容をマトリクスイメージで表現したものである。実際のＭＰＥＧ１ストリーム中には、このようなマトリクスの左上の成分（ＤＣ）から右下の高周波成分（ＡＣ６３）に向かって、ジグザグにたどってシリアルに並べたデータを、可変長符号化したデータが存在するが、このＤＣを除いた６３個のＤＣＴ係数を「ＡＣ成分」と称する。ＡＣ成分のうちでも、ＤＣに近い左上の成分程、画質への影響が大きい成分となる。
【００７５】
なお、一般に、圧縮動画データパケット４２の切れ目と、ＧＯＰ５０の切れ目６０は、一致しないことが多い。しかし、ＧＯＰの途中から圧縮動画データを伸長して動画再生を行うと、再生画像の乱れが生じてしまう。そのため、本実施例における動画データ量の削減処理は、ＧＯＰ単位で行うものとする。
【００７６】
次に、図２に示したデータ量削減方式の説明において、前述したデータ量削減の実現方式の一例を述べる。
【００７７】
まず、画素数の削減は、既に符号化されたＭＰＥＧ１データを一旦復号し、動画像データに戻した段階で、画素を一定間隔で間引く処理や、位置的に隣接した画素に対するデータの加重平均を取る処理を行なう等によって画素数を減らし、画素数を減らしたデータを再符号化することによって実現できる。
【００７８】
ＡＣ成分の上限の制限は、前記ブロック５５中のＤＣＴ係数のうち、右下の成分（高周波成分）から、削減することによって実現するが、実際には、既に符号化されたＭＰＥＧ１データを可変長符号の段階にまで復号し、可変長符号単位で、所望のデータ量になるようにＡＣ係数を削減して、再符号化する方法や、ＤＣＴ係数の段階まで復号化し、所望のデータ量になるようにＡＣ係数を削減して再符号化する方法等により実現できる。
【００７９】
フレーム数の低減を、実際にＧＯＰを構成するフレームデータそのものを間引くことにより実現すると、再生時に誤動作が生じることが多い。これは、ＭＰＥＧデータの中に、その動画のフレームレート（１秒あたりのフレーム数）のデータが存在し、該フレームレートのデータと、フレーム数を間引かれた圧縮動画データの間で矛盾が生じるためである。よって、フレーム数の削減は、ＧＯＰを構成する、少なくとも１つのフレームのデータ（ピクチャ層のデータ）を、少なくともピクチャ層の「開始コード」、ピクチャの「通番」、「ピクチャタイプ」からなるデータであって、該フレームの中身、すなわち、圧縮された画素データを含まない、ダミーデータ５６に置き換えることにより実現する。
【００８０】
この方式によれば、形式上フレーム数には変化なく、実際には、フレームに対応した圧縮動画データ自体がないので、再生時には、時間的に前のフレームから変更がないものとみなされ、上述したような矛盾がなく、見かけ上のフレーム数の削減が実現でき、圧縮動画データの時間あたりの転送量も減少する。
【００８１】
フレーム数の削減によって、ＭＰＥＧ１動画データを所望のデータ量にまで削減する場合は、画質への影響を考慮して、まず、Ｂフレーム（５２、５４）からダミーデータ５６に置き換え、全てのＢフレームを置き換えても目的のデータ量削減を達成できなない場合には、Ｐフレームをダミーデータ５６に置き換え、さらに、全てのＰフレームを置き換えても目的のデータ量削減を達成できない場合には、さらに、Ｉフレームをダミーデータ５６に置き換えるというように、段階的にダミーデータ５６への置き換えを行っていく。
【００８２】
このように、データ量の削減方式を示す図２の１０を参照して、必要に応じてＭＰＥＧ動画データのデータ量を削減しながら、削減データを配信することにより、ユーザの配信品質要求と、メディアサーバの配信能力を考慮した、配信マルチメディアデータのデータ量制御を行なうことができる。
【００８３】
なお、ＭＰＥＧ方式以外の動画や、音声のみからなるデータや、静止画等のマルチメディアデータにおいても、データ量とユーザの配信品質要求を考慮した削減方式を定めることは可能である。
【００８４】
例えば、符号化された音声データでは、ステレオのデータをモノラル化する方法や、サンプリング周波数や量子化ステップを粗くする方法等によりデータ量を削減することが可能であり、符号化された静止画データでは、画素数を減らす方法等によりデータ量を削減できる。また、図２の１０は、メディアサーバ１が扱うマルチメディアデータのうち、動画、静止画等のデータ種別ごとに予め定めておき内蔵しておく構成にする。
【００８５】
以下に、以上述べてきたメディアサーバ１によるマルチメディアデータの配信を実現する方法について説明する。なお、本実現方法の説明においても、配信対象となるマルチメディアデータを、ＭＰＥＧ１方式で圧縮処理された圧縮動画データを例にとり説明する。
【００８６】
ＭＰＥＧ１動画データのデータ量を削減しながらの、削減データのクライアント２への配信は、基本的に、次の示す方法によって行なう。
【００８７】
メディアサーバ１は、配信対象となる動画データの種類毎に、図２に示すデータ量削減基準テーブルを備えていて、該基準テーブル１０に示した削減方法にしたがって、配信条件（ユーザの要求とメディアサーバ１のサービス能力）に、最も近いデータ量削減方法を示すセルを決定し、該セルに対応するデータ量削減パラメータを用いたデータ量削減により、データ量を削減制御しながら、削減データを配信する。仮に、配信中に配信条件が変更されたときには、その変更された配信条件に最も近い、データ量削減方式に切り替えて配信する。この時、データの削減方式の切り替えは、ＧＯＰの切れ目で行う。
【００８８】
なお、配信条件は、ユーザの要求とメディアサーバ１のサービス能力で決定される。ユーザの要求は、例えば、図２に示すセルを１つ選択するために、図２の横軸方向のセル位置を決定する命令に相当し、通常、クライアントは、コマンドを入力することによって、サーバ側に、図２の横軸方向のセル位置を決定する命令を与え、サーバがこれを受け取る。なお、サーバは、通常、複数のクライアントからの要求に答えるために、複数の削減データを、複数の通信媒体を介して、クライアント側に送信している。また、当然のことながら、１つのサーバが処理することができる、削減データのデータ量の総和には、上限値（しきい値）が存在する。
【００８９】
また、メディアサーバ１のサービス能力とは、メディアサーバ１に接続される各通信媒体の最大伝送レート（しきい値）のことを意味し、サーバは、これを越えないように、データ量を削減したセルを選択する（通常、前記選択されたセルの存在位置を基準として、縦軸下方向に存在するセルを選択することになる）。
【００９０】
このように、サーバは、全ての削減データのデータ量および各通信媒体の最大伝送レートの少なくとも一方が、各々に対して予め定められているしきい値を越えたとき、前記データ量削減規則のうちから、前記削減データ量演算手段の演算結果および各通信媒体の最大伝送レートの双方が、各々に対して予め定められているしきい値を越えないように、セルを選択していき、選択したセルに対応する削減パラメータを使用して、データ削除処理を行なう情報処理システムである。
【００９１】
なお、通常は、全くデータ削除処理を行なわずに、全ての削減データのデータ量および各通信媒体の最大伝送レートの少なくとも一方が、各々に対して予め定められているしきい値を越えたときに始めて、優先度の小さな順に、動画データのデータ量を削減しておく機能を有するように、サーバを構成しても良い。なお、このような優先度は、クライアントからサーバに与えるものとする。
【００９２】
図５は、図１で説明したコンピュータ端末のハードウェア構成を示す構成図である。
【００９３】
１０１は、端末全体を制御する中央処理装置（ＣＰＵ）、１０２は、プログラムが動作し、データ量削除制御用のデータを保持するテーブルを一時的に確保する主メモリで、ＲＡＭで実現される。
【００９４】
１０３は、ＣＰＵ１０１等に、一定間隔で割込み信号や日時の情報を供給する時計装置（クロック）である。１０４は、ユーザの指示入力を取り込むためのマウス、１０５は、同様にユーザの指示入力を取り込むためのキーボードである。
【００９５】
１０６は、ユーザのデータを保存するための記憶装置であり、ハードディスク（ＨＤ）や光磁気ディスク（ＭＯ）で実現される。
【００９６】
１１０は、ユーザに処理結果を表示して伝えるためのディスプレー装置、１１１は、画像情報を取り込むためのカメラであり、これらは、画像入出力制御装置１０８により制御される。
【００９７】
１０９は、ディスプレー１１０に表示するデータを保持するメモリ（ＶＲＡＭ：Ｖｉｄｅｏ ＲＡＭ）であり、画像入出力制御装置１０８により、常に最新の表示データが書き込まれる。１１５は、カメラ１１１によって取り込んだ動画や静止画等の画像データの圧縮処理および伸長処理を行う画像コーディックである。
【００９８】
１１３は、音声情報を取り込むマイク、１１４は、音声情報をユーザに伝えるスピーカであり、これらは、音声入出力制御装置１１２によって制御される。
【００９９】
１１６は、マイク１１３によって取り込んだ音声データの圧縮処理および伸長処理を行う音声コーディックである。１０７は、ＬＡＮ３に端末を接続するためのネットワーク接続制御装置（ＬＡＮボード）である。
【０１００】
１１８は、ＩＳＤＮ４に端末を接続するためのモデム等の回線接続制御装置である。１２０は、ディジタルシグナルプロセッサ（ＤＳＰ）であり、特定の処理を行うマイクロプログラムを、記憶装置１０６からロードし、ＣＰＵ１０１と独立して高速に、ロードしたマイクロプログラムを実行する。このようなマイクロプログラムは、通常、記憶装置１０６等に予め記憶しておき、必要に応じてＤＳＰ１２０がマイクロをロードして実行する。
【０１０１】
またＣＰＵ１０１は、ＤＳＰ１２０に、データやそのデータに関する処理内容の情報を与えて、特定の処理の実行を依頼し、ＤＳＰ１２０が、特定の処理を実行した後、その処理結果を受け取ることによって、端末処理全体での処理速度を向上することを可能とする。なお、ＤＳＰ１２０が行う特定の処理として、主なものに、画像、音声データの圧縮、伸長処理や、ネットワークや回線との接続制御処理等が挙げられる。これらの処理のうち、例えば、画像や音声データの圧縮処理等は、処理を行うプログラムを主メモリ１０２上に、ＣＰＵ１０１がロードして、ＣＰＵ１０１が、ロードしたプログラムを実行することによっても実行可能であり、また、画像コーディック１１５や音声コーディック１１６等の専用ハードウェアに対して、ＣＰＵ１０１が、処理を行なうことを依頼し、処理が実行されるようにしてもよい。
【０１０２】
本実施例においては、後述するユーザ配信タスク５００ａが、動画データのＧＯＰや音声データのＡＡＵ（これについては後述する）を主メモリ１０２上にロードし、前述のデータ量削減処理を行なうマイクロプログラムをＤＳＰ１２０にロードし、ＤＳＰ１２０が、該マイクロプログラムを実行することによって、動画データや音声データのデータ量の削減を行なうか、あるいは、主メモリ１０２上に、予め記憶装置１０６に記憶している、前述したデータ量の削減処理を行なうプログラムをロードし、ＣＰＵ１０１により、動画データや音声データのデータ量の削減処理を行なうものとする。この時発生する動画、音声の、デコード処理、エンコードの処理には、画像コーディック１１５、音声コーディック１１６を使用して、各々の処理を行なわせるようにしてもよい。
【０１０３】
１１７は、各装置を接続し、装置間相互でのデータのやり取りを行なうことを可能にするためのバスである。
【０１０４】
なお、図１を参照して説明したコンピュータ端末において、全ての端末に必須な構成要素は、ＣＰＵ１０１、主メモリ１０２、クロック１０３、記憶装置１０６、およびバス１１７であり、その他の装置は、端末に必要な機能を考慮して、必要に応じて搭載するように構成すればよい。
【０１０５】
なお、本実施例において、以下に詳細に説明するメディアサーバ１では、マウス１０４、キーボード１０５、ＬＡＮボード１０７、モデム１１８、ディスプレイ１１０、画像入出力制御装置１０８、ＶＲＡＭ１０９、および、ＤＳＰ１２０が、少なくとも必要になる。
【０１０６】
一方、クライアント２では、マウス１０４、キーボード１０５、ＬＡＮボード１０７、モデム１１８、ディスプレイ１１０、画像入出力制御装置１０８、画像コーディック１１５、ＶＲＡＭ１０９、スピーカ１１４、音声入出力制御装置１１２、音声コーディック１１６、および、ＤＳＰ１２０が、少なくとも必要になる。
【０１０７】
図６は、本発明にかかる第１の実施例における、メディアサーバ１とクライアント２のソフトウェア構成を示す図、即ち、機能ブロック図である。
【０１０８】
まず、図６の（ａ）を参照して、メディアサーバ１のソフトウェア構成について説明する。
【０１０９】
２００ａは、メディアサーバ１の基本システムソフトウェア、あるいは、オペーレティングシステム（以下「ＯＳ」と記す）と称されるマルチタスクＯＳであり、メディアサーバ１上で動作するソフトウェアへのＣＰＵ１０１の機能の割当て管理、図５を参照して説明した各ハードウェア装置資源の管理、メモリ１０２の論理的な使用単位での管理、ソフトウェアおよびハードウェアの処理実行のスケジューリング等を行なうためのソフトウエアであり、いわゆるマルチタスク処理を行なう。マルチタスクＯＳ２００ａは、通常、ＬＡＮ３やＩＳＤＮ４を介して、他の端末とデータ通信を行う際の通信手順の制御等を行うためのプロトコル処理部２１０ａや、記憶装置１０６の動作制御や記憶装置１０６に格納するデータのファイル管理を行うファイルシステム２２０ａを含んで構成される。
【０１１０】
３００ａは、メディアサーバ１において動作するソフトウェアの実行単位で、メディアサーバ１上に複数存在し、一般に、タスク（あるいは、プロセス）と称されるものである。なお、以下に述べる４００ａ〜７００ａも、タスク（あるいはプロセス）であり、マルチタスクＯＳ２００ａ側から見た扱い方は、３００ａに対するのと同様である。複数存在するタスク３００ａは、マルチタスクＯＳ２００ａにより生成され、ユーザやマルチタスクＯＳ２００ａによって、個々に指定された優先度に基づき、実行順序を決定や、ハードウェア資源へのアクセス等の調整を行なうことにより、中断、実行待ち、終了等の実行状態になるように管理される。
【０１１１】
以下に述べるメディアサーバ１において、マルチタスクＯＳ２００ａは、ＬＡＮ３からのデータの着信、ユーザの入力装置１０５等を介した入力、記憶装置１０６の処理終了等の、イベントに伴うＣＰＵ１０１への割込みに対し、即座に優先度に基づき、タスク３００ａの実行順序の変更を行う、リアルタイム性を有したマルチタスクＯＳである。
【０１１２】
本実施例においては、特に、マルチタスクＯＳ２００ａは、タスク間での情報（メッセージ）伝達の支援、ＬＡＮ３、ＩＳＤＮ４から送られてきたメッセージをプロトコル処理部２１０ａによる処理を介してタスクへ伝達する等の、異なるネットワークや回線に渡るタスク間通信支援機能を有し、また、マウス１０４、キーボード１０５等の入力装置を介してユーザが入力した入力内容を、必要に応じてタスクに伝達したり、タスクのデータ出力要求を受け付けて画像入出力制御装置１０８を制御し、ディスプレー１１０に、要求に適合したデータを表示する等の、入出力制御機能も有している。
【０１１３】
４００ａは、クライアント２からのマルチメディアデータ配信要求を受け付け、ユーザ配信処理タスク５００ａに配信要求を発したクライアント２への、データの配信処理を依頼する、配信スケジューラタスクである。また、ユーザ配信処理タスク５００ａは、マルチタスクＯＳ２００ａにより、ユーザからの配信要求の件数分だけ生成されるが、一般にＯＳが扱うことが可能なタスク数は、ハードウェアの仕様等によって制限されており、そのような制限数を超える場合には、配信を行わない。なお、配信スケジューラタスク４００ａの具体的な処理内容については後述する。
【０１１４】
５００ａは、要求を発したクライアントに対して、マルチメディアデータの配信を行うユーザ配信処理タスクであり、該タスクは、ユーザの指定したサービス品質と、メディアサーバ１の処理負荷やＬＡＮ３、ＩＳＤＮ４の伝送能力を考慮して、サービスするデータの品質を制御する、すなわち、データ量削減パラメータを定め、データ量の削減制御を行なう。
【０１１５】
該制御は、例えば、ユーザの品質要求があるレベル以上であるときや、メディアサーバのサービス能力が高くないときに（配信データに対して、通信媒体の伝送能力が小さなとき）、配信するオリジナルのマルチメディアデータのデータ量を削減して配信することにより実現する。ユーザの指定したサービス品質に関する情報（即ち、図２の１０において、セルの横軸方向の位置を定める情報）は、配信スケジューラタスク４００ａにより、また、メディアサーバ１の処理負荷やＬＡＮ３、ＩＳＤＮ４の伝送能力等の、メディアサーバ１のサービス能力に関する情報は、サービス品質管理タスク６００ａにより、それぞれ取得する。該タスク５００ａによるデータ量制御の具体的な方法については、後述する。
【０１１６】
６００ａは、メディアサーバ１の処理負荷やＬＡＮ３、ＩＳＤＮ４の通信品質等、メディアサーバ１のサービス能力に関する情報に基づき、配信のサービス品質の決定、および、ユーザ配信処理タスク５００ａ等に、サービス品質の情報を提供するサービス品質管理タスクである。なお、公知となっているＯＳには、ＣＰＵ１０１の処理負荷を逐次、数値で評価して、各タスクに通知する機能を有するものがある。また、ＬＡＮ３に流れるデータパケットの流量を監視することにより、ＬＡＮ３中のデータの混雑の程度を数量的に評価し、各タスクに通知する機能を有するソフトウェアもある。また、サービスするマルチメディアデータの転送レートを、メディアサーバ１が、該データごとの情報として予め有し、メディアサーバ１が、クライアント２に配信中のデータの種類と、各転送レートの情報とを参照して、自ら配信能力を数量的に評価して、各タスクに通知する機能を有するように構成することも考えられる。このように、６００ａが提供するサービス能力の情報は、メディアサーバ１が自ら検知するか、クライアント２からのデータ要求のような外部からの情報を用いて検知した、サービス能力を数量的に表現したものとし、特に、後者の検知方法の実現例については、後述する。また数量的に表現されたサービス能力値の伝達は、主メモリ１０２の上の特定の領域を情報伝達用に割当て、該領域を、タスク３００ａ乃至７００ａが共有することによって実現される。
【０１１７】
７００ａは、配信するオリジナルのマルチメディアデータのデータ量を、高速に削減処理して配信を容易にするようにデータを整形する、配信データ整形タスクである。なお、該タスク７００ａの具体的な処理内容については、後述する。
【０１１８】
次に、図６（ｂ）を参照して、クライアント２のソフトウェア構成について説明する。
【０１１９】
８００ａは、クライアント２のＯＳであり、機能的には、メディアサーバ１のＯＳ２００と同様である。また、ＯＳ８００ａは、マルチタスク２００ａと同様に、通信制御等を行うプロトコル処理部８１０ａや、ファイルシステム８２０ａを有して構成される。
【０１２０】
９００ａおよび１０００ａは、ＯＳ８００ａ上で動作するタスクである。
【０１２１】
９００ａは、ユーザの指示により起動され、ユーザの必要とするマルチメディアデータの名称、および、配信時のサービス品質等の要求を取り込み、これらの情報をメディアサーバ１に、ＬＡＮ３やＩＳＤＮ４等を介して伝送し、また、配信されてきたデータを受信する、メディア要求処理タスクである。該タスク９００ａの具体的な処理内容については、後述する。
【０１２２】
１０００ａは、メディア要求タスク９００ａが受信した動画、静止画、音声等を有するマルチメディアデータを再生する、マルチメディアデータ再生タスクである。該タスク１０００ａは、メディア要求タスク９００ａが、マルチメディアデータを全て受信終了してから、該データの再生を開始するようにしても良いし、全ての受信処理を完了する前に、受信したデータを逐次再生するようにしても良い。特に、動画等の再生では、時間的制約条件が課される場合があり、このような場合には、後者のような再生方法を採用すれば良い。また、該タスク１０００ａが行なう処理は、画像コーディック１１５や音声コーディック１１６のような専用ハードウェアによって実行されても良いし、ＤＳＰ１２０によるマイクロプログラムの実行やＣＰＵ１０１による主メモリ１０２上のソフトウェアの実行によって、行なわれても良い。
【０１２３】
次に、本発明にかかる第１の実施例における、メディアサーバ１の有する制御テーブルやデータ構造について説明する。
【０１２４】
メディアサーバ１では、図２の１０に示すテーブルと、図７に示す各制御テーブルを、主メモリ１０２上に格納し、少なくとも、マルチタスクＯＳ２００ａ、配信スケジューラタスク４００ａ、ユーザ配信処理タスク５００ａ、サービス品質管理タスク６００ａ、および、配信データ整形タスク７００ａが参照可能な、アドレス上に確保する。以下、図７に示す各制御テーブルについて説明する。
【０１２５】
２９９９は、配信するＭＰＥＧ１データの元データである。後に詳しく説明する配信データ整形タスク７００ａでは、元データ２９９９から、データ量の削減を行ないやすいように整形したデータ３０００（以下、整形済みの元データと記す）と、データ量削減時に、削減処理対象のＧＯＰの先頭からのバイト数と該ＧＯＰのサイズを、ＧＯＰごとに記述した、データ３０００に対応するＩＮＤＥＸデータ２０３０を生成する。
【０１２６】
当然のことながら、メディアサーバ１には、複数種類の整形済み元データ３０００が存在し、ＩＮＤＥＸデータ２０３０も、整形済み元データ３０００と一意に対応して複数存在する。ＩＮＤＥＸデータ２０３０の内容については、後述する。
【０１２７】
２０００ａ、ｂは、配信条件テーブルであり、これは配信スケジューラタスク４００ａにより、前述したユーザ配信処理タスク５００ａ（図７の５００ｃ、ｄ）と一意的に対応付けられて生成される、ユーザへの配信条件に関する情報を記述したテーブルである。ユーザ配信処理タスク５００ａと同様に、配信条件テーブル２０００も、配信件数分だけ存在し、１つのテーブル２０００には、少なくとも、ファイル名２００１、（サービス）品質２００２、（転送）状態２００３、および（配信条件）変更フラグ２００４の各データの内容が記述されている。
【０１２８】
該テーブル２０００は、配信スケジューラタスク４００ａにより生成された後は、必要に応じてサービス品質管理タスク６００ａにより、その内容が変更される。
【０１２９】
ファイル名２００１は、配信する整形済みの元データ３０００を指定するための識別子である。
【０１３０】
品質２００２は、ユーザに提供する動画の品質に関するデータであるが、図２の１０に示す各セルのうち、現在配信中の動画データのデータ量制御方式に対応したセルに記述された、データ量制御パラメータが記憶保持されている。
【０１３１】
状態２００３は、最新のデータの配信状態を表すデータであり、例えば、データの転送中には「転送中」と、ユーザのポーズ要求により配信が一時的に停止している場合は、「待ち」と、記憶される。
【０１３２】
変更フラグ２００４が示すフラグは、該テーブル２０００が、配信スケジューラタスク４００ａにより新規に生成されたとき、および、サービス品質管理タスク６００ａによりその内容が変更されたときに、「変更あり」を示すように設定される。また、該フラグ２００４は、ユーザ配信処理タスク５００ａが、２００４を参照したときに、「変更なし」を示すように設定される。
【０１３３】
２０１０は、メディアサーバ１がユーザへのサービス能力を管理するためのデータを保持する配信管理テーブルである。該テーブル２０１０は、メディアの配信要求ごとに、少なくとも、要求したクライアントのクライアントＩＤ２０１２、配信の優先度２０１３、メディア種別２０１４、メディアの転送レート２０１５、配信処理の状態２０１６等の情報を保持する配信状況レコード２０１１（図７では、３つのクライアント毎に、２０１１ａ、２０１１ｂ、２０１１ｃとしている）を情報として持っている。
【０１３４】
さらに、２０１０は、メディアサーバ１に接続している通信媒体ごとに、転送中のデータの転送レートの最新の合計値を常に保持する、ネットワーク別転送レート合計レコード２０２０、および、メディアサーバ１が転送中のデータの転送レートの最新の合計値を常に保持する、サービス転送レート合計レコード２０２５を、情報として持っている。
【０１３５】
配信状況レコード２０１１は、ユーザからの配信要求があったときに、配信が可能であれば追加され、ユーザ配信処理タスク５００ａに一意に対応して存在する。さらに、レコード２０１１中の各情報の設定方法等について説明する。
【０１３６】
クライアントＩＤ２０１２は、ネットワーク上でのクライアントの論理アドレス（例えば、ＩＰアドレス等）に一意に対応する識別子であり、他に、メディアサーバ１へのユーザアカウント等を使用することも可能である。優先度２０１３は、メディアサーバ１における各配信処理の優先度を数値で表したものであり、クライアント２が、配信要求時に指定するのが一般的であるが、メディアサーバ１が、予めクライアントＩＤ毎に定めておいた優先度を使用するようにしてもよい。メディア種別２０１４は、動画、静止画と言った、配信中のメディアの種類の識別子であり、配信データのファイル名２００１と同一の情報を用いれば良い。
【０１３７】
転送レート２０１５は、配信するデータ毎の転送レート値であり、このデータは、後述するＩＮＤＥＸデータ２０３０中のデータと同一のものである。削除処理され、配信されるデータのデータ量に一意に対応して、該転送レート２０１５が定まるため、転送レート２０１５は、見方によっては、データ量であるともいえる。
【０１３８】
状態２０１６は、前記配信条件テーブル２０００の状態２００３と同一のデータであり、最新のデータの配信状態を表す、「転送中」、「待ち」等の情報が記憶される。２０１２〜２０１６は、配信開始時に、サービス品質管理タスク６００ａによって、新規にレコード２０１１が追加される時点で設定され、以後、ユーザの新たな配信要求の追加や配信条件の変更に伴って、２０１２〜２０１６の内容は、追加、変更される。なお、かかる変更処理の内容については、後に、サービス品質管理タスク６００ａの処理の説明部分において述べる。
【０１３９】
次に、ネットワーク別転送レート合計レコード２０２０は、ユーザからの新規配信要求の追加時や配信要求の変更時に、サービス品質管理タスク６００ａにより更新される情報であり、該タスク６００ａは、複数のＬＡＮやＩＳＤＮ（ＷＡＮ）４のような、サーバ１に接続される通信媒体（以後「ネットワークセグメント」と称す）ごとに、配信処理中のデータの転送レートの合計を計算した値を設定する。この時、タスク６００ａは、転送状態２０１６を参照して、転送中のレコード２０１１を見つけ出し、クライアントＩＤ２０１２を手がかりに、ネットワークセグメントを特定し、ネットワークセグメント毎に転送レート２０１５を合計する。全てのネットワークセグメント毎に転送レートを計算し、それぞれレコード２０２０の中のデータ２０２１、２０２３として設定する。
【０１４０】
ネットワークセグメントとは、物理的なネットワークの単位のことであり、例えば、メディアサーバ１にＬＡＮボード１０７を複数装備し、かつ、それぞれのＬＡＮボードからアクセス可能なＬＡＮ３が異なる場合、メディアサーバ１は、異なるネットワークセグメントにアクセスしているとする。
【０１４１】
なお、ネットワークセグメント毎に使用可能な転送レート（伝送帯域２０２２）は、予め定められており、この情報は、新規に配信を開始するか否かを決定する場合に使用する。すなわち、セグメント毎に、許容可能な転送レートの上限値が、伝送帯域２０２２によってて定められており、いずれかのセグメントにおいて、その転送レートが伝送帯域を越えるような場合には、越えないように、データ量の削減処理が行なわれることになる。
【０１４２】
サービス転送レート合計レコード２０２５は、ユーザからの新規配信要求の追加時や配信要求の変更時に、サービス品質管理タスク６００ａにより更新される情報であり、該タスク６００ａは、メディアサーバ１が配信処理中のデータの転送レートの合計を計算して、２０２７に設定する。この時、該タスク６００ａは、状態２０１６を参照して、転送中のレコード２０１１を見つけ出し、該レコードについての転送レート２０１５を合計する。レコード２０２５には、メディアサーバ１が備えるバス１１７が、データ配信可能な転送レートの上限値（伝送帯域２０２６）を予め決めておき、この値を参照して、新規にデータ配信を開始するか否かを決定する場合に使用する。
【０１４３】
すなわち、サーバが扱うことが可能なマルチメディアデータに対する転送レートの合計の上限値（２０２７）を、伝送帯域２０２６によって定めており、転送レート２０２７が、この伝送帯域２０２６を越えるような場合には、越えないように、データ量の削減処理が行なわれることになる。
【０１４４】
次にＩＮＤＥＸデータ２０３０について、説明する。本実施例においては、配信対象の動画データ毎に、図２のテーブル１０と同様のテーブルを、メディアサーバ１に備えており、該テーブル１０の各セルで示された削減方式に従って、前述したように、ユーザが与えるユーザ要求と、伝送能力で定まるサービス要求を考慮した、データ量削減方式を示すセルを決定し、データ量を削減制御しながらデータを配信し、配信中に配信条件が変更されたときには、その変更された配信条件に最も近い（例えば、現在のセル位置を基準とした時、特定方向に隣接するセルで示される）データ量削減方式に切り替えて配信するが、この時、実際のＭＰＥＧ１データの構成上、次のような問題点がある。
【０１４５】
図８には、ＭＰＥＧ１動画および音声データのフォーマットと、動画および音声データパケット構成の関係を示す。動画データのパケットとは、前述のように動画の符号化器４１が符号化しパケット化する際、一定のサイズに区切った単位であり、図に示すように、動画のＧＯＰ５０の切れ目（６０）と、該パケットの切れ目は一致しない場合が多い。また、音声についても、ＧＯＰと同様に、再生時の単位としてＡＡＵ（Ａｕｄｉｏ Ａｃｃｅｓｓ Ｕｎｉｔ）５１（５１ａ等）があるが、音声の符号化器４５が符号化しパケット化する際、一定のサイズに区切った単位である音声データのパケット４４と、ＡＡＵ５１の切れ目（６１）とは一致しない場合が多い。さらに、音声も、ＡＡＵの途中から再生すると正常に再生されない。よって、動画は、ＧＯＰの境界から、音声はＡＡＵの境界から再生できるようにする必要がある。
【０１４６】
しかしながら、一般のＭＰＥＧシステムストリーム４７は、前述したように、圧縮動画データパケット４２および圧縮音声データパケット４４の単位で、多重化されており、ＧＯＰやＡＡＵの単位では多重化されていない。これは、従来ＭＰＥＧ１のデータが、１つのコンピュータ端末内で、ハードディスク等の記憶装置から読みだされ、バスを介してデコーダへ転送され、さらに、デコードされてディスプレイに表示するという、使用環境を想定しているためである。即ち、バスやネットワークにおけるデータの伝送は、データをパケット化して行なわれるが、一般に、ネットワークよりバスの方が、データ伝送の信頼性が高く、伝送速度が高速であり、パケットが欠落したり、パケットの到着順が狂ったり、伝送遅延が発生することが、比較的少ない。またデコーダも、ＧＯＰ、ＡＡＵのように、意味のある単位でデコードするため、伝送されて来るＭＰＥＧ圧縮データを、一旦格納するためのメモリバッファが必要となるが、該メモリバッファを構成するＲＡＭは、高価であるため、あまり大きなパケットで伝送すると、大容量のメモリバッファを必要とし、デコーダが高価になる。
【０１４７】
以上のような理由から、音声も動画もエンコードしたデータ順に、固定長にし、比較的小さなサイズでパケット化し、次々に、パケットを多重化していく方法が採用されてきた。しかしながら、ＭＰＥＧ１データもネットワークや回線を介して伝送することは一般的になりつつあり、ＲＡＭの容量あたりの価格も低下し続けている。
【０１４８】
このため、ネットワークや回線の伝送速度等に適応してデータ量を制御しながら、既圧縮のＭＰＥＧ１等の動画データを配信するには、一般的なシステムストリーム４７のままでは、動画および音声データのデータ量の削減処理が複雑になることや、動画と音声の同期がとれなくなるといった危険性がある。
【０１４９】
したがって、まず、図９に示すように、ＧＯＰ５０ａと時間的に対応するＡＡＵ５１ａ、５１ｂ、５１ｃ、５１ｄを、一まとめにし（７０ａ）、これを再パケット化するＭＰＥＧ１データ整形を行い、図２のテーブル１０のセルで示される削減方法に従って、データ量の削減を、高速かつ容易に行なえるようにすることが必要である。
【０１５０】
次に、図１０に、前記手順で整形した元データ３０００と、ＩＮＤＥＸデータ２０３０の構成を示す。配信する動画データのデータ量制御を実現するには、７０ａ、７０ｂ等の、ＧＯＰと対応するＡＡＵとの組み合わせを、１つのデータ単位とし、該単位の切れ目で、データ量削減方式を切り替える。即ち、データ量削方式を示すテーブル１０にある、データ量削減のためのパラメータを変更する。
【０１５１】
そのため、まず、前述のＩＮＤＥＸデータ２０３０には、データ３０００の本来の転送レート２０３１、および、単位７０（７０ａ、７０ｂ、７０ｃ、７０ｄ、７０ｅ）毎の、データ３０００の先頭からのサイズ（Ｓｅｅｋサイズ）２０３２（Ａ１、Ａ２、Ａ３、Ａ４、Ａ５）と、各単位自体のサイズ（Ｒｅａｄサイズ）２０３３（ａ１、ａ２、ａ３、ａ４、ａ５）を格納しておく。
【０１５２】
ＩＮＤＥＸデータ２０３０の生成は、元データの整形処理と同時に、あるいは、並行して行なうことが可能であり、効率的でもある。
【０１５３】
配信するデータのデータ量制御方式を切り換える場合には、常にＩＮＤＥＸデータ２０３０を参照し、単位７０を一括して同一のデータ量削減方式で削除処理し、該削減処理が終了すると、データ量削減方式の変更の必要性を判定し、変更の必要があれば、次の単位を、変更したデータ量削減方式を使用して、一括して削減処理を行なう。
【０１５４】
以上述べてきたように、元データの整形を行ない、ＩＮＤＥＸデータ２０３０を利用することにより、配信動画の再生に乱れを発生させず、効率良くデータ量の制御を行ないながら、削除データの配信が可能になる。
【０１５５】
また、ユーザから、動画の飛ばし見や、ブラウジングなどによる検索等の配信要求があった場合には、前記単位を、所定間隔で選択していき、選択した単位を、ユーザに配信することが実現できるため、元データの整形、ＩＮＤＥＸデータ２０３０の利用は、飛ばし見や、早送り再生（順方向及び逆方向）の実現も可能とする。なお、これらの特定の要求に対しては、図２の特定のセルを採用するように、予め定めておけば良い。
【０１５６】
さらに、ＩＮＤＥＸデータ２０３０に、ＧＯＰと対応するＡＡＵをまとめた一つのデータの単位７０ごとに、該単位内での動きの大きさや精細度等を数量的に評価し、それぞれデータ２０３４、データ２０３５として保持することにより、ユーザの要求がなくとも、サーバが自動的に動画データの削除を行なうことが可能となる。
【０１５７】
即ち、精細度２０３５に比べて、動き２０３４の大きな単位７０においては、動画の高周波成分を削減して、空間的解像度を落とし、動き２０３４に比べて精細度２０３５の大きい単位７０においては、動画のフレーム数を削減して時間的解像度を落とし、動き２０３４及び精細度２０３５が同程度の場合には、空間的及び時間的解像度を同程度に落とすことにより、データ量削減処理を行なう。
【０１５８】
具体的には、２０３４と２０３５のデータの組に対して、予めセルを対応させておき、サーバは、２０３４と２０３５のデータで定まるセルが示す、データ量削除方式を採用して、データ削除処理を自動的に行なう。この場合、接続される通信媒体の伝送能力を考慮した、セルの定め方をしておけばよい。
【０１５９】
なお、サーバがユーザの要求が発生していても自動的にセルの選択を行なうシステム構成にするか否かにかかわらず、サーバに接続される通信媒体を、伝送速度６４（ｋｂｉｔ／秒）のＩＳＤＮ回線で構成した場合には、データ量削減方式として、画素数を、縦１２０画素、横１７６画素とする、セルを用意しておき、該セルを選択するようにすればよい。また、前記通信媒体を、伝送速度１４．４（ｋｂｉｔ／秒）のアナログ回線で構成した場合には、データ量削減方式として、画素数を、縦６０画素、横８８画素とする、セルを用意しておき、該セルを選択するようにすればよい。
【０１６０】
さて、前述の２０３４、２０３５は、サーバが自ら定めるデータであるが、動きの大きさの評価は、元データの整形を行なう際に、単位７０を構成するフレームデータに存在する動きベクトルの大きさに基づいて行なう。即ち、例えば、単位７０のデータの動きベクトルの合計値を求め、この値を参照して、予め定めた基準値の何倍になるかで、動きの大きさの値を決定する。なお、このような基準値は、コンピュータ実験等により、予め定めておけば良い。
【０１６１】
一方、精細度の評価は、元データの整形を行なう際に、単位７０を構成するフレームデータにＤＣＴ変換したデータの高周波成分の大きさに基づいて行なう。
【０１６２】
即ち、例えば、単位７０のＩフレームの高周波成分値を、予め定めた基準値の何倍になるかで、精細度の値を決定する。なお、このような基準値は、コンピュータ実験等により、予め定めておけば良い。
【０１６３】
以上述べてきたサーバ１とクライアント２の間で、データ量の削減処理を行ないながら、ＭＰＥＧ１動画データを配信する、各タスクの処理内容について、以下説明する。
【０１６４】
まず、本発明にかかる第１の実施例における、メディアサーバ１の配信スケジューラタスク４００ａの処理内容について説明する。
【０１６５】
図１１は、配信スケジューラタスク４００ａの処理内容を示すフローチャートである。
【０１６６】
配信スケジューラタスク４００ａは、ユーザが、メディアサーバ１の入力装置１０５からの起動指示入力や、ＬＡＮ３やＩＳＤＮ４を介した、クライアント２からの起動要求メッセージデータを、マルチタスクＯＳ２００ａが受け取ったときに、マルチタスクＯＳ２００ａによって起動される。
【０１６７】
まず、ステップ４０１において、サービス品質管理タスク６００ａを起動し、次に、ステップ４０２において、ＬＡＮ３やＩＳＤＮ４を介したクライアント２からのマルチメディアデータ配信要求や、サービス内容の変更要求のメッセージデータ、ユーザのメディアサーバ１の入力装置１０５からの指示入力等を受け付ける。
【０１６８】
次に、ステップ４０３では、前記メッセージおよび指示入力等の内容を判定し、ユーザからの新たなマルチメディアデータの配信要求であれば（新規）、ステップ４１１に進み、また、画質等のサービス品質の変更、動画の場合の早送り再生開始、ポーズ等、サービス内容の変更要求であれば（変更）、ステップ４２１に進み、さらに、終了指示入力であれば、ステップ４３１に進む。
【０１６９】
なお、新規な配信要求および変更要求を伝えるメッセージデータの内容は、配信、変更の対象となるマルチメディアデータの識別名称と要求品質とからなり、これらは、ＬＡＮ３やＩＳＤＮ４を介してクライアント２からメディアサーバのマルチタスクＯＳ２００ａに渡され、さらに、マルチタスクＯＳ２００ａによって、配信スケジューラタスク４００ａに渡される。
【０１７０】
次に、ステップ４１１では、サービス品質管理タスク６００ａに、ユーザの指定通りの要求品質での新規配信が可能か否かを問い合わせ、配信可能であれば、ステップ４１３に進み、配信不可能であればステップ４１４に進む（ステップ４１２）。
【０１７１】
次に、ステップ４１３では、新たなユーザ配信処理タスク５００ａと配信条件テーブル２０００との生成を、マルチタスクＯＳ２００ａに要求し、メモリ１０２の容量不足や予め設定された総タスク数を超えるなどの要因により、タスク５００ａあるいはテーブル２０００のいずれかの生成が不可能な場合には、（ステップ４１５）ステップ４１４に進み、一方、可能な場合にはステップ４０２に進む。また、ステップ４１４では、配信要求のあったクライアント２に、メディアサーバ１が配信不可能である旨のメッセージを送信し、ステップ４０２に進む。
【０１７２】
また、ステップ４２１では、サービス品質管理タスク６００ａに、ユーザの指定通りのサービス内容の変更が可能であるか否かを問い合わせ、変更対象のユーザ配信処理タスク５００ａが既に消滅しているとか、メディアサーバ１のサービス能力の限度を超える等の要因により、タスク５００ａへの通知が不可能な場合は、ステップ４２３に進み、一方、可能な場合には、ステップ４０２に進む。
【０１７３】
そして、ステップ４２３では、変更要求のあったクライアント２に、メディアサーバ１が、サービス内容の変更が不可能である旨のメッセージを送信し、ステップ４０２に進む。
【０１７４】
最後に、ステップ４３１では、サービス品質管理タスク６００ａおよび配信スケジューラ４００ａが生成した全てのユーザ配信処理タスク５００ａに、配信処理の終了を指示するメッセージを与えた後、配信スケジューラタスク４００ａが使用しているハードウェア資源等を開放することにより、配信スケジューラタスク４００ａが行なう処理を終了する。
【０１７５】
次に、本発明にかかる第１の実施例における、メディアサーバ１のユーザ配信処理タスク５００ａが行なう処理内容について説明する。
【０１７６】
図１２は、ユーザ配信処理タスク５００ａの処理内容を示すフローチャートである。
【０１７７】
ユーザ配信処理タスク５００ａは、配信スケジューラタスク４００ａにより、タスクとして生成され、マルチタスクＯＳ２００ａにより起動される。該タスク５００ａは、メディアサーバ１のマルチメディアデータの配信件数分だけ生成され、マルチタスクＯＳ２００ａによって、適宜切り替えられながら動作し、見かけ上、同時に複数のクライアント２に対する、マルチメディアデータの配信を行なっている。
【０１７８】
まず、ステップ５０１では、配信対象のデータに対応するＩＮＤＥＸデータ２０３０を、主メモリ（ＲＡＭ）１０２上にロードする。ステップ５０２では、配信対象となるデータ３０００を、マルチタスクＯＳ２００ａや各タスクが、読み出し可能な状態にする。通常、マルチタスクＯＳ２００ａは、記憶装置１０６等に記憶しているデータのアクセスを管理するため、ファイルといった概念で管理するが、ステップ５０２では、データ３０００のファイルをオープンする。
【０１７９】
次に、ステップ５１１では、配信条件テーブル２０００ａの品質２００２を参照して、データ量削減パラメータを読みだす。ステップ５１２では、配信対象のデータ３０００のＩＮＤＥＸデータ２０３０の２０３２を参照して、配信するデータ単位７０の読み出し開始位置までシークする。
【０１８０】
ステップ５１３では、読み出し開始位置からＩＮＤＥＸデータ２０３０の２０３３を参照して、配信するデータ単位７０を読み出す。ステップ５１４では、データ単位７０を、ステップ５１１で読み出したデータ量削減パラメータに従って、データ量の削減を行なう。ここで、ネットワークや回線の伝送能力に余裕があり、メディアサーバ１のサービス能力に余裕がある場合には、データ量の削減を必ずしも行なう必要がなく、そのようなときには、ステップ５１４では、何の処理も行なわない。ステップ５１５では、データ量の削減処理を行なった削減データを、単位７０毎に、クライアント２に転送する。
【０１８１】
そして、ステップ５２１では、ステップ５１４で送信したデータがファイルの終わり（ＥＯＦ）であるか否かを判定し、終わりでない場合には、ステップ５２２に進み、終わりならば、ステップ５３１に進む。ステップ５２２では、配信スケジューラタスク４００ａからの、配信処理の終了を伝えるメッセージの有無を検知し、終了要求があれば、ステップ５３１に進み、一方、終了要求がなければ、ステップ５１１に進む。
【０１８２】
次に、ステップ５３１では、ステップ５０２でオープンしたファイルをクローズし、ステップ５３２では、サービス品質管理タスク６００ａに配信の終了を通知し、タスク５００ａが使用した主メモリ１０２上のメモリ空間等のリソースの開放を行なった後、マルチタスクＯＳ２００ａにタスク５００ａの終了を、自ら要求し、タスク５００ａの処理を終了する。なお、ステップ５１１で、配信条件テーブル２０００を参照する際、変更フラグ２００４が「変更あり」を示している場合には、これを「変更なし」の状態に設定する処理を行なう。また、このフラグ２００４が「変更なし」であれば、新たにデータ量削減パラメータを読み出す必要はない。
【０１８３】
次に、本発明にかかる第１の実施例におけるメディアサーバ１のサービス品質管理タスク６００ａの処理内容について説明する。
【０１８４】
図１３は、サービス品質管理タスク６００の処理内容を示すフローチャートである。
【０１８５】
サービス品質管理タスク６００ａは、配信スケジューラタスク４００ａにより、タスクとして生成され、マルチタスクＯＳ２００ａにより起動される。
【０１８６】
まず、ステップ６０１では、配信管理テーブル２０１０を初期化し、ステップ６１１では、配信スケジューラタスク４００ａからのメッセージを待ち、メッセージを受信したらその内容を解釈し、メッセージの内容が、「新規配信開始」であれば、ステップ６２１に進み、「配信条件変更」であれば、ステップ６３１に進み、配信中のユーザ配信処理タスク５００ａの処理の終了（配信終了）であれば、ステップ６４１に進み、メディアサーバ１の配信スケジューラ自体の終了によるタスク終了処理要求（タスク処理終了）であれば、ステップ６５１に進む。
【０１８７】
ステップ６２１では、配信管理テーブル２０１０のネットワーク別転送レート合計２０２０、および、サービス転送レート合計２０２５を参照し、新規に配信するデータの転送レート２０３１と、予め設定されたネットワークセグメントやバス１１７の伝送帯域（２０２２、２０２６）とを比較して、データ量を削減せずに、あるいは、データ量を削減して新規に配信可能なら、ステップ６２４に進み、また、データ量を削減しても、新規に配信が不可能なら、ステップ６２３に進む（ステップ６２２）。この場合、タスク４００ａから渡されたユーザの配信画質への要求品質と、サービス可能な転送レートを同時に満たすデータ量の削減が可能であるか否かを、動画データの元の転送レート２０３１とデータ量削減のための、図２のテーブル１０を参照し、該テーブル１０に条件を満たすデータ量削減パラメータが無い場合は、配信不可能とする。ステップ６２４では、配信管理テーブルに、新規の配信要求に対応したレコード２０１１を追加し、ステップ６２６では、配信スケジューラタスク４００ａに配信可能である旨と配信条件テーブルに設定するパラメータとを、メッセージにより伝え、ステップ６１１に進む。
【０１８８】
次に、ステップ６２３では、配信管理テーブルを参照し、既に配信を開始しているユーザ配信処理タスクに対応する配信条件を変更すれば、新規配信が可能であるか否かをを調べ、既に配信中のデータのうち、それ以上転送レートを下げられないものがある場合等、条件変更が不可能な場合には、ステップ６２７に進み、一方、条件変更が可能ならば、ステップ６２５に進む。
【０１８９】
また、ステップ６２３における配信条件を変更における、配信の可否の判定も、ステップ６２２と同様に、図２のテーブル１０を参照して行なう。なお、ステップ６２３では、配信管理テーブルの優先度２０１３の情報を用いて、優先度の高い配信処理については、条件を変更せず、優先度の低いものから条件を変更していくようにする。
【０１９０】
ステップ６２７では、配信スケジューラタスク４００ａに新規配信が不可能である旨をメッセージにより伝え、ステップ６１１に進む。ステップ６２５では、変更した配信条件を配信管理テーブル２０１０の各レコード２０１１に設定し、対応する配信条件テーブル２０００のデータを再設定し、変更フラグ２００４を「変更あり」に設定し、ステップ６２６を実行する。
【０１９１】
次に、ステップ６３１では、配信管理テーブル２０１０を参照し、変更の対象となっているレコード２０１１の内容の変更をすれば、既に配信中のデータのうち、それ以上転送レートを下げられないものがある場合等、条件変更が不可能な場合の有無を判定し、条件変更が可能な場合には、ステップ６３４に進み、条件変更が不可能な場合には、ステップ６３３に進む（ステップ６３２）。
【０１９２】
ステップ６３３における配信の可否の判定も、ステップ６２２と同様に、図２のテーブル１０を参照して行なう。
【０１９３】
なお、ステップ６３２では、配信管理テーブルの優先度２０１３の情報を参照して、優先度の高い配信処理については、条件を変更せず、優先度の低いものから条件を変更していくようにする。
【０１９４】
ステップ６３３では、配信スケジューラタスク４００ａに配信条件変更が不可能である旨をメッセージにより伝え、ステップ６１１に進む。ステップ６３４では、変更した配信条件を配信管理テーブル２０１０の各レコード２０１１に設定し、対応する配信条件テーブル２０００のデータを再設定し、変更フラグ２００４を「変更あり」に設定する。ステップ６３５では、配信スケジューラタスク４００ａに配信条件可能である旨を、メッセージにより返答し、ステップ６１１に進む。
【０１９５】
次に、ステップ６４１では、配信の終了したレコード２０１１を配信管理テーブル２０１０より削除し、必要なら、他のレコードの配信条件も変更する。
【０１９６】
最後に、ステップ６５１では、サービス品質管理タスク６００ａが使用した主メモリ１０２上のメモリ空間等のリソースの開放を行なった後、マルチタスクＯＳ２００ａにタスク６００ａの終了を自ら要求し、タスク６００ａの処理を終了する。
【０１９７】
なお、新規に配信を開始するクライアントが低速回線を介したＭＰＥＧ１データの配信要求であれば、図２のテーブル１０を参照して、例えば、ＩＳＤＮの６４ｋｂ／ｓ程度の転送レートであれば、セル１６に記述されたデータ量削減方法で、アナログ回線の１４．４ｋｂ／ｓ程度の転送レートであれば、セル１７に記述されたデータ量削減方法で削減処理したデータを転送すれば、クライアント２側において、該データを受信しながらデコードして表示すること（リアルタイム再生）も可能である。この場合、ＡＣ成分の上限数の制限や、フレーム数の削減は、伝送レートの調整のために採用する。
【０１９８】
次に、本発明にかかる第１の実施例におけるメディアサーバ１の配信データ整形タスク７００ａの処理内容について説明する。
【０１９９】
図１４は、配信データ整形タスク７００ａの処理内容を示すフローチャートである。
【０２００】
配信データ整形タスク７００ａは、ユーザが、メディアサーバにクライアント２で共用する動画データを登録するときに、ユーザの指示により、マルチタスクＯＳ２００ａが生成し、起動する。
【０２０１】
ステップ７０１では、ユーザから登録されたＭＰＥＧ１動画の元データ２９９９を読み込み、次に、ステップ７０２では、データ２９９９を音声だけのデータと動画だけのデータに分離し、ステップ７１１では、ステップ７０２で分離した動画データから１ＧＯＰごとに抜き出し、このＧＯＰの時間に対応するＡＡＵをステップ７１１で分離した音声だけのデータから抜き出し、それぞれをマージして、図９に示すデータ単位７０を作成する。この処理を全てのＧＯＰに対して繰返し、全てのデータ単位７０をマージして整形済み元データ３０００を作成して、ＩＮＤＥＸデータ２０３０に登録する。
【０２０２】
そして、ステップ７２１では、選択したセルに対応するデータ量削減パラメータを使用して、削除データの作成を行ない、タスク７００ａの処理を終了する。
【０２０３】
なお、ステップ７１１における動画と音声の時間的な対応付けは、動画のフレームレートと音声のサンプリング周波数より、各ＧＯＰおよびＡＡＵの再生開始時間を計算し、両者を照らし合わせることにより行なう。
【０２０４】
次に、本発明にかかる第１の実施例におけるクライアント２のメディア要求タスク部９００ａの処理内容について説明する。
【０２０５】
図１５は、メディア要求部９００の処理のフローチャートである。
【０２０６】
ステップ９０１では、ユーザから配信要求のあるデータのファイル名や、配信されたデータに利用方法の情報などを受け付ける。利用方法の情報とは、配信された動画データをブラウジングに使うか、あるいは、詳細に鑑賞する旨を示す情報である。また、かかる情報は、ユーザが入力しなくとも、ブラウジングを目的とするアプリケーションからの要求であれば、メディア要求タスク９００ａが自動的にブラウジング用と判断するような構成にしても良い。次に、ステップ９１１では、ユーザの用途から、動きの滑らかさか、あるいは、精細度のいずれを、どの程度要求するかといった、動画の画質に関する要求を評価し、そのデータを供給可能なメディアサーバ１を、ＬＡＮ３、ＩＳＤＮ４に接続されているメディアサーバのなかから検索し、要求を満たすメディアサーバ１を決定する。
【０２０７】
ステップ９２１では、ステップ９１１で決定したメディアサーバ１に配信を希望する動画データのファイル名と、画質の要求とをメッセージにより送信し、サーバからのデータの配信を待つ。そして、ステップ９３１では、メディアサーバ１からの返答を待ち、「配信可能」であれば、受信したデータをマルチメディアデータ再生タスク１０００ａにより表示し、再生が終了すれば、メディア要求タスク９００ａの処理を終了する。なお、メディアサーバからの返答が「配信不可能」であれば、時間を空けてリトライした後、更に「配信不可能」であれば処理を終了するようにしても良い。
【０２０８】
以上述べてきた、第１の実施例によれば、メディアサーバ１が記憶している、ある動画データをクライアント２に配信する際に、ユーザの画質への要求と、ネットワークや回線の伝送能力を含めたメディアサーバのサービス能力とを考慮して、データ量の削減を行ないながら、削減データを配信することが可能になる。
【０２０９】
また、データ量の削減制御も、時々刻々と変化するサービス能力に追随して、動画のＧＯＰや音声のＡＡＵの、切れ目に合わせて、データ量削減方式を切り換えることができ、クライアント側では、配信を受ける動画が乱れたり、音声がとぎれたりノイズが混入するといったことが無くなる。以上のことから、メディアサーバ１は、配信する動画データのデータ量を削減制御することによる、ネットワークや回線、サーバの処理能力を考慮したデータの提供が可能となり、クライアント２のユーザは、希望する品質を有するデータの配信を受けることが可能になる。
【０２１０】
なお、本実施例で述べたデータ量を削減しながらの配信は、予め配信データを図９に示すように整形しておくため、データ量削除制御の処理負荷を増加させることなく実現することが可能であり、複数クライアントの同時配信要求に対し、リアルタイムな配信処理が実現できる。
【０２１１】
また、転送するネットワークのトラヒックが飽和する可能性がある場合にも、配信する動画データの転送レートを抑えながらの配信が可能であり、メディアサーバが同時に動画データを配信できるクライアントの数を増加させることができる。この時、クライアントごとに優先度を設定することが可能であるため、優先度の低いクライアントから、転送する動画のデータ量を削除していくようにすることができ、ユーザが予め定めた優先度にしたがった、ユーザの要求を満足するデータ提供を実現できる。
【０２１２】
次に、本発明にかかる第２の実施例を説明する。
【０２１３】
本実施例は、サーバが、クライアントから配信要求されるデータのデータ量を、予め定めた規則に従って削減した、削減データを予め用意して格納しておき、適当な削減データを配信するという実施例である（なお、本実施例を、便宜上「ソフト型」と称する）。
【０２１４】
図１を参照して説明した、第１の実施例におけるメディアサーバのネットワーク環境の一例は、そのまま第２の実施例において用いることができる。
【０２１５】
次に、本発明の第１の実施例における、メディアサーバ１（１ａ、１ｂ）のマルチメディアデータのデータ量削減方法、削減データの配信方法の原理について説明したが、本実施例では、図２の各セルに対応する削減データを、サーバが予め備えた構成になっている。すなわち、削減データは、画素数、ＡＣ係数の上限値、フレーム数を含むデータ量削除パラメータを使用して、元データのデータ量を削除して作成する。そして、ある元データに対して、複数種類の削除データを予め生成し、サーバが格納している。
【０２１６】
さて、配信する削除データの選択は、図２のテーブル１０を参照して、次のように行う。なお、サーバは、各セルに対応した削除データを、予め作成し、記憶装置に格納しているものとする。
【０２１７】
まず、ユーザ（クライアント）からの配信要求が発生した場合、メディアサーバ１では、図２の１０を参照し、ユーザの要求と、配信（サービス）能力を考慮したデータ量となるように、配信時の初期削減データを選択し、選択した削減データの配信を行なう。ここで、配信（サービス）能力とは、例えば、サーバに接続されている各通信媒体の、通信許容伝送レート等が考えられる。ユーザの要求のみならず、サーバに接続されている各通信媒体の、通信許容伝送レートを越えないことを条件として、データ量の削減処理が行なわれる。
【０２１８】
これを仮に、セル１１に対応する削減データを採用するとし、配信の途中で、ユーザ要求が、更に動きの滑らかさを優先するように変更された場合には、（横軸上で右側に存在する）セル１２に対応する削除データに変更選択し、また、精細度を優先するように変更された場合は、（横軸上で左側に存在する）セル１３に対応する削除データに変更選択し、それぞれ変更選択された削除データを配信する。
【０２１９】
また、セル１１に対応する削除データの配信中に、メディアサーバ１のサービス能力が低下し、更にデータ量を削減する必要があるときには、（縦軸下方向に存在する）セル１５に対応する削除データに変更選択し、また、サービス能力が回復して、配信データ量を増加することが可能になれば、（縦軸上方向に存在する）セル１４に対応する削除データに変更選択して、変更選択した削除データを配信する。
【０２２０】
なお、図３を参照して説明した、ＭＰＥＧ１動画データのフォーマットは、第２の実施例でも同様である。動画データのデータ量の削減方式について再度説明することは避ける。
【０２２１】
第１の実施例では、図５を参照して説明したコンピュータ端末をそのまま使用することができる。
【０２２２】
ただし、クライアントおよびサーバが備える記憶装置には、第２実施例用のプログラムを格納しており、また、サーバ側には、元データに対応する、複数種類の削除データを、元データ種類ごとに記憶している。
【０２２３】
図１６は、本発明にかかる第２の実施例におけるメディアサーバ１及びそのクライアント２のソフトウェア構成を示す図、即ち、機能ブロック図である。
【０２２４】
まず、図１６（ａ）を参照して、メディアサーバ１のソフトウェア構成について説明する。
【０２２５】
第２の実施例における、タスク２００ｂ〜６００ｂは、第１の実施例における、タスク２００ａ〜６００ａと基本的には同じ機能を有するが、重複説明を避けずに説明することにする。
【０２２６】
２００ｂは、メディアサーバ１の基本システムソフトウェア、あるいは、オペーレティングシステム（以下「ＯＳ」と略記）と称されるソフトウェアであり、メディアサーバ１上で動作するソフトウェアへのＣＰＵ１０１の機能の割当て管理、図５を参照して説明した各ハードウェア装置資源の管理、メモリ１０２の論理的な使用単位での管理、ソフトウェアおよびハードウェアの処理実行のスケジューリング等を行うプログラムであり、いわゆるマルチタスク処理を行なう、マルチタスクＯＳである。マルチタスクＯＳ２００ｂは、通常、ＬＡＮ３やＩＳＤＮ４を介して、他の端末とデータ通信を行う際の通信手順の制御等を行うプロトコル処理部２１０ｂや、記憶装置１０６の動作制御や記憶装置１０６に格納するデータのファイル管理を行うファイルシステム２２０ｂを含んで構成される。
【０２２７】
３００ｂは、メディアサーバ１において動作するソフトウェアの実行単位で、メディアサーバ１において複数存在し、一般に、タスク（あるいはプロセス）と称されるものである。なお、以下に述べる４００ｂ〜７００ｂも、タスク（あるいはプロセス）であり、マルチタスクＯＳ２００ｂ側から見た扱い方は、３００ｂに対するのと同様である。複数存在するタスク３００ｂは、マルチタスクＯＳ２００ｂにより生成され、ユーザやマルチタスクＯＳ２００ｂによって、個々に指定された優先度に基づき、実行順序の決定や、ハードウェア資源へのアクセス等の調整が行なわれることにより、中断、実行待ち、終了等の実行状態になるように管理される。
【０２２８】
以下で述べるメディアサーバ１において、マルチタスクＯＳ２００ｂは、ＬＡＮ３からのデータの着信、ユーザの入力装置１０５等を介した入力、記憶装置１０６の処理終了等の、イベントに伴うＣＰＵ１０１への割込みに対し、即座に優先度に基づき、タスク３００ｂの実行順序の変更を行う、リアルタイム性を有したマルチタスクＯＳである。
【０２２９】
本実施例においては、特に、マルチタスクＯＳ２００ｂは、タスク間での情報（メッセージ）伝達の支援、ＬＡＮ３，ＩＳＤＮ４から送られてきたメッセージをプロトコル処理部２１０ｂによる処理を介してタスクへ伝達する等の、異なるネットワークや回線に渡るタスク間通信支援機能を有し、また、マウス１０４、キーボード１０５等の入力装置を介してユーザが入力した入力内容を、必要に応じてタスクに伝達したり、タスクのデータ出力要求を受け付けて画像入出力制御装置１０８を制御し、ディスプレー１１０に、要求に適合したデータを表示する等の、入出力制御機能も有している。
【０２３０】
４００ｂは、クライアント２からのマルチメディアデータ配信要求を受け付け、ユーザ配信処理タスク５００ｂに配信要求を発したクライアント２への、データの配信処理を依頼する、配信スケジューラタスクである。また、ユーザ配信処理タスク５００ｂは、マルチタスクＯＳ２００ｂにより、ユーザからの配信要求の件数分だけ生成されるが、一般にＯＳが扱うことが可能なタスク数は、ハードウェアの仕様等によって制限されており、そのような制限数を超える場合には、配信を行わない。また、配信スケジューラタスク４００ｂの具体的な処理内容については後述する。
【０２３１】
５００ｂは、要求を発したクライアントに対して、マルチメディアデータの配信を行うユーザ配信処理タスクであり、該タスクは、ユーザの指定したサービス品質と、メディアサーバ１の処理負荷やＬＡＮ３、ＩＳＤＮ４の伝送能力を考慮して、サービスするデータの品質を制御する、すなわち、配信対象とする削除データを選択し、選択した削除データを配信する。
【０２３２】
該制御は、例えば、ユーザの品質要求があるレベル以上であるときや、メディアサーバのサービス能力が高くないときに（配信データに対して、通信媒体の伝送能力が小さなとき）、配信するオリジナルのマルチメディアデータのデータ量を削減して配信することにより実現する。ユーザの指定したサービス品質に関する情報（即ち、図２の１０において、セルの横軸方向の位置を定める情報）は、配信スケジューラタスク４００ｂにより、また、メディアサーバ１の処理負荷やＬＡＮ３、ＩＳＤＮ４の伝送能力等の、メディアサーバ１のサービス能力に関する情報は、サービス品質管理タスク６００ｂにより、それぞれ取得する。該タスク５００ｂによるデータ量制御の具体的な方法については、後述する。
【０２３３】
６００ｂは、メディアサーバ１の処理負荷やＬＡＮ３、ＩＳＤＮ４の通信品質等、メディアサーバ１のサービス能力に関する情報に基づき、配信のサービス品質の決定、および、ユーザ配信処理タスク５００ｂ等に、サービス品質の情報を提供するサービス品質管理タスクである。なお、公知となっているＯＳには、ＣＰＵ１０１の処理負荷を逐次、数値で評価して、各タスクに通知する機能を有するものがある。また、ＬＡＮ３に流れるデータパケットの流量を監視することにより、ＬＡＮ３中のデータの混雑の程度を数量的に評価し、各タスクに通知する機能を有するソフトウェアもある。また、サービスするマルチメディアデータの転送レートを、メディアサーバ１が、該データごとの情報として予め有し、メディアサーバ１が、クライアント２に配信中のデータの種類と、各転送レートの情報とを参照して、自ら配信能力を数量的に評価して、各タスクに通知する機能を有するように構成することも考えられる。このように、６００ｂが提供するサービス能力の情報は、メディアサーバ１が自ら検知するか、クライアント２からのデータ要求のような外部からの情報を用いて検知した、サービス能力を数量的に表現したものとし、特に、後者の検知方法の実現例については、後述する。また数量的に表現されたサービス能力値の伝達は、主メモリ１０２の上の特定の領域を情報伝達用に割当て、該領域を、タスク３００ｂ乃至７００ｂが共有することによって実現される。
【０２３４】
７００ｂは、第１の実施例と異なるソフトウエアであり、第２の実施例の主要部をなすタスクである。
【０２３５】
ユーザの品質要求があるレベル以上であるときや、メディアサーバのサービス能力が高くないとき（配信データに対して、通信媒体の伝送能力が小さなとき）に配信する削除データを、オリジナルのマルチメディアデータのデータ量を削減して生成する、削減データ生成タスクである。削減データは、１つのオリジナルマルチメディアデータに対し、図２の各セルに示すような、複数のデータ量削減方法を採用して、予め複数種類作成しておく。なおタスク７００ｂの具体的な処理内容については、後述する。
【０２３６】
なお、オリジナルのマルチメディアデータと、削減データのいずれを配信するかは、ユーザ配信処理タスク５００ｂが判定し決定する。該タスク５００ｂによるデータ量制御は、配信するデータを、オリジナルデータまたは削減データに切り替えることにより実現する。なお、該タスク５００ｂの処理内容については、後述する。
【０２３７】
次に、図１６（ｂ）を参照して、クライアント２のソフトウェア構成について説明する。
【０２３８】
８００ｂは、クライアント２のＯＳであり、機能的には、メディアサーバ１のＯＳ２００ｂと同様である。また、ＯＳ８００ｂは、マルチタスク２００ｂと同様に、通信制御等を行うプロトコル処理部８１０ｂや、ファイルシステム８２０ｂを有して構成される。
【０２３９】
９００ｂおよび１０００ｂは、ＯＳ８００ｂ上で動作するタスクである。
【０２４０】
９００ｂは、ユーザの指示により起動され、ユーザの必要とするマルチメディアデータの名称、および、配信時のサービス品質等の要求を取り込み、これらの情報をメディアサーバ１に、ＬＡＮ３やＩＳＤＮ４等を介して伝送し、また、配信されてきたデータを受信する、メディア要求処理タスクである。該タスク９００ｂの具体的な処理内容については、後述する。
【０２４１】
１０００ｂは、メディア要求タスク９００ｂが受信した動画、静止画、音声等を有するマルチメディアデータを再生する、マルチメディアデータ再生タスクである。該タスク１０００ｂは、メディア要求タスク９００ｂが、マルチメディアデータを全て受信終了してから、該データの再生を開始するようにしても良いし、全ての受信処理を完了する前に、受信したデータを逐次再生するようにしても良い。特に、動画等の再生では、時間的制約条件が課される場合があり、このような場合には、後者のような再生方法を採用すれば良い。また、該タスク１０００ｂが行なう処理は、画像コーディック１１５や音声コーディック１１６のような専用ハードウェアによって実行されても良いし、ＤＳＰ１２０によるマイクロプログラムの実行やＣＰＵ１０１による主メモリ１０２上のソフトウェアの実行によって、行なわれても良い。
【０２４２】
次に、本発明にかかる第２の実施例におけるメディアサーバ１の有する制御テーブルやデータ構造について説明する。
【０２４３】
メディアサーバ１では、図２のテーブル１０の各セルに対応する削減方法で作成した複数種類の削除データや元データ、図７に示す各制御テーブルを、主メモリ１０２上格納し、少なくとも、マルチタスクＯＳ２００ｂ、配信スケジューラ４００ｂ、ユーザ配信処理タスク５００ｂ、サービス品質管理タスク６００ｂ、および、削減データ生成タスク７００ｂが参照可能な、アドレス上に確保する。以下、図１７に示す各制御テーブルについて説明する。
【０２４４】
６０００は、配信するＭＰＥＧ１データの元データである。後に詳しく説明する削減データ生成タスク７００ｂでは、図２のテーブル１０を参照し、元データ６０００から、データ量を図２のテーブル１０の各セルに対応する削減方法にしたがって削減処理した削減データを複数個生成し（６０２０）、元データ６０００と削減データ６０２０の論理的な関係付けに関する情報と、削減データの転送レートを記述したＩＮＤＥＸデータ４０３０を生成する。
【０２４５】
当然のことながら、メディアサーバ１には、複数種類の元データ６０００が存在し、各元データごとに、さらに複数種類の削減データ６０２０が存在するため、ＩＮＤＥＸデータ６０３０も、元データ６０００と一意に対応して、複数存在する。なお、説明を容易化するため、削除データ６０２０としては、３種類の削除データ、６０２０ａ、６０２０ｂ、６０２０ｃのみを図示している。
【０２４６】
ＩＮＤＥＸデータ６０３０の内容については、後述する。
【０２４７】
４０００ａ、ｂは、配信条件テーブルであり、これは配信スケジューラタスク４００ｂにより、前述したユーザ配信処理タスク５００ｂ（図１７の５００ｅ、５００ｆ）と一意的に対応付けられて生成される、ユーザへの配信条件に関する情報を記述したテーブルである。ユーザ配信処理タスク５００ｂと同様に、配信条件テーブル４０００も、配信件数分だけ存在し、１つのテーブル４０００には、少なくとも、ファイル名４００１、（サービス）品質（データ名）４００２、および、（配信条件）変更フラグ４００４の各データの内容が記述されている。
【０２４８】
該テーブル４０００は、配信スケジューラタスク４００ｂにより生成された後は、必要に応じてサービス品質管理タスク６００ｂにより、その内容が変更される。
【０２４９】
ファイル名４００１は、配信する元データ６０００を指定するための識別子である。
【０２５０】
品質２００２は、ユーザに提供する動画の品質に関するデータであるが、本実施例の場合は、データ群６０１０のうち、実際に配信するデータ、即ち、６０００か、６０２０ａ、ｂ、ｃのいずれかを指定するためのデータ識別子である。
【０２５１】
変更フラグ４００４が示すフラグは、該テーブル４０００が、配信スケジューラタスク４００ｂにより新規に生成されたとき、および、サービス品質管理タスク６００ｂによりその内容が変更されたときに、「変更あり」を示すように設定される。また、該フラグ４００４は、ユーザ配信処理タスク５００ｂが、６００４を参照したときに、「変更なし」を示すように設定される。
【０２５２】
４０１０は、メディアサーバ１がユーザへのサービス能力を管理するためのデータを保持する配信管理テーブルである。該テーブル４０１０は、メディアの配信要求ごとに、少なくとも、要求したクライアントのクライアントＩＤ４０１２、配信の優先度４０１３、メディア種別４０１４、メディアの転送レート４０１５、配信処理の状態４０１６等の情報を保持する配信状況レコード４０１１（図１７では、３つのクライアント毎に、４０１１ａ、４０１１ｂ、４０１１ｃとしている）を情報として持っている。
【０２５３】
さらに、４０１０は、メディアサーバ１が接続している通信媒体ごとに、転送中のデータの転送レートの最新の合計値を常に保持する、ネットワーク別転送レート合計レコード４０２０、および、メディアサーバ１が転送中のデータの転送レートの最新の合計値を常に保持する、サービス転送レート合計レコード４０２５を、情報として持っている。
【０２５４】
配信状況レコード４０１１は、ユーザからの配信要求があったときに、配信が可能であれば追加され、ユーザ配信処理タスク５００ｂに一意に対応して存在する。さらに、レコード４０１１中の各情報の設定方法等について説明する。
【０２５５】
クライアントＩＤ４０１２は、ネットワーク上でのクライアントの論理アドレス（例えばＩＰアドレス等）を使用することも可能である。優先度４０１３は、メディアサーバ１における各配信処理の優先度を数値で表したものであり、クライアント２が、配信要求時に指定するのが一般的であるが、メディアサーバ１が、予めクライアントＩＤ毎に定めておいた優先度を使用するようにしてもよい。
【０２５６】
メディア種別４０１４は、動画、静止画と言った、配信中のメディアの種類の識別子であり、本実施例においては、前記配信データ群６０１０のうち、元データ６０００や削減データ６０２０の、データ識別子を用いることが可能である。
【０２５７】
なお、図示しているように、本配信管理テーブル４０１０は、ある特定の動画１に対するテーブルである。即ち、説明のために、元データ６０００の種類を、「動画１」のみとして図示している。
【０２５８】
転送レート４０１５は、配信するデータ毎の転送レート値であり、このデータは、後述するＩＮＤＥＸデータ４０３０中のデータと同一のものである。
【０２５９】
状態４０１６は、最新のデータの配信状態を表す、「転送中」、「待ち」等の情報が記憶される。４０１２〜４０１６は、配信開始時に、サービス品質管理タスク６００ｂによって、新規にレコード４０１１が追加される時点で設定され、以後、ユーザの新たな配信要求の追加や配信条件の変更に伴って、４０１２〜４０１６の内容は、追加、変更される。なお、かかる変更処理の内容については、後に、サービス品質管理タスク６００ｂの処理の説明部分において述べる。
【０２６０】
ネットワーク別転送レート合計レコード４０２０は、ユーザからの新規配信要求の追加時や配信要求の変更時に、サービス品質管理タスク６００ｂにより更新される情報であり、該タスク６００ｂは、複数のＬＡＮ３やＩＳＤＮ（ＷＡＮ）４のような、サーバ１に接続される通信媒体（以後「ネットワークセグメント」と称す）ごとに、配信処理中のデータの転送レートの合計を計算した値を設定する。この時、該タスク６００ｂは、転送状態４０１６を参照して、転送中のレコード４０１１を見つけ出し、クライアントＩＤ４０１２を手がかりに、ネットワークセグメントを特定し、ネットワークセグメント毎に転送レート４０１５を合計する。全てのネットワークセグメント毎に転送レートを計算し、ネットワークセグメント、計算値のそれぞれを、レコード４０２０の中のデータ４０２１、４０２３として設定する。
【０２６１】
なお、ネットワークセグメント毎に使用可能な転送レート（伝送帯域）を、予め定めておき、このデータを、新規に配信を開始するか否かを決定する場合に使用する。即ち、この値を越えるような配信を行なうことは許容されない。
【０２６２】
サービス転送レート合計レコード４０２５は、ユーザからの新規配信要求の追加時や配信要求の変更時に、サービス品質管理タスク６００ｂにより更新される情報で、該タスク６００ｂは、メディアサーバ１が配信処理中のデータの転送レートの合計を計算して、４０２７に設定する。この時、該タスク６００ｂは、状態４０１６を参照して、転送中のレコード４０１１を見つけ出し、該レコードについての転送レート４０１５を合計する。該レコード４０２５には、メディアサーバ１が備えるバス１１７が、データ配信可能な転送レートの上限値（前記伝送帯域）を予め決めておき、この値を参照して、新規にデータ配信を開始するか否かを決定する場合に使用する。
【０２６３】
すなわち、サーバが扱うことが可能なマルチメディアデータに対する転送レートの合計の上限値（４０２７）を定めており、転送レート４０２７が、この上限値を越えるような場合には、越えないように、削除データを選択して、選択した削除データが配信される。
【０２６４】
次にＩＮＤＥＸデータ２０３０について、説明する。本実施例においては、配信対象の動画データ毎に、複数種類の削除データを予め作成しておき、メディアサーバ１に備えておき、ユーザが与えるユーザ要求と、伝送能力で定まるサービス要求を考慮した、削除データを選択し、転送レートを削減しながらデータを配信し、配信中に配信条件が変更されたときには、その変更された配信条件に最も近い（例えば、現在のセル位置を基準とした時、特定方向に隣接するセルで示される削減方式を使用して作成された削減データ）削減データに切り替えて配信する。この時、実際のＭＰＥＧ１データの構成を考慮したときの問題点が存在することは、図８を参照して、第１の実施例にて説明した通りであり、この対処方法も、図９を参照して、第１の実施例にて説明したものと同一あるため、ここでは重複説明を省略する。
【０２６５】
図１８には、図９にて説明した手順で整形した元データ６０００と削減データ６０２０のＧＯＰとＡＡＵをまとめた単位（７０５、７１０、７２０）の対応付けを示す。配信する動画のデータ量の制御を実現するには、この７０５、７１０、および７２０の切れ目で切り替える。すなわち、１つの「ＧＯＰ＋ＡＡＵ」を単位として、順次切り換えていく。
【０２６６】
従って、図に示すように、配信条件が変化する毎に、異なる種類のデータに対する単位で切り換えていく場合（例えば「▲１▼、▲２▼、▲３▼、▲４▼…」）、配信条件が変化しない場合には、同一のデータに属する単位で切り換えていく場合（例えば「▲１▼、▲６▼、▲７▼…」）等の各種の態様が考えられる。
【０２６７】
さらに、同一のデータに属する単位で切り換えていく場合において、途中で配信対象となるデータの種類の変更を余儀なくされるときに、所定時間経過した後に、再度、前記同一のデータに属する先頭単位に戻って、単位ごとに切り換えていく方法も考えられる。
【０２６８】
そのため、前述のＩＮＤＥＸデータ４０３０には、データ名称４０３１として、元データ６０００および削減データ６０２０のデータ識別子と、それぞれの転送レート４０３２および単位７００（７１０、７２０）毎の、データの先頭からのサイズ（Ａ１乃至Ａ５）と、単位のサイズ（ａ１乃至ａ５）（以上４０３３）を、各データごとに記述する。配信するデータを切り換える場合には、常に、データ４０３０を参照し、切り替わった時点で、先頭からのサイズを呼んでシークし、単位のサイズ文だけのデータを読んで、クライアント２に送信すれば、クライアント２から見れば、配信データのデータ量が制御されて着信したことになる。
【０２６９】
以上述べてきたソフトウェア、ハードウェア構成を有するメディアサーバ１とクライアント２の間で、データ量を制御をしながら、ＭＰＥＧ１動画データを配信する、各タスクの処理内容について以下述べる。
【０２７０】
次に、本発明にかかる第２の実施例におけるメディアサーバ１の配信スケジューラの処理内容について説明するが、これは基本的には、図１１を参照して説明した、第１の実施例の配信スケジューラと同様であるが、ステップ等に添字「ｂ」を付して、図１９を参照して再度説明する。
【０２７１】
図１９は、第２の実施例における配信スケジューラタスク４００ｂの処理内容を示すフローチャートである。
【０２７２】
配信スケジューラタスク４００ｂは、ユーザが、メディアサーバ１の入力装置１０５からの起動指示入力や、ＬＡＮ３やＩＳＤＮ４を介した、クライアント２からの起動要求メッセージデータを、マルチタスクＯＳ２００ｂが受け取ったときに、マルチタスクＯＳ２００ｂによって起動される。
【０２７３】
まず、ステップ４０１ｂにおいて、サービス品質管理タスク６００ｂを起動し、次に、ステップ４０２ｂにおいて、ＬＡＮ３やＩＳＤＮ４を介したクライアント２からのマルチメディアデータ配信要求や、サービス内容の変更要求のメッセージデータ、ユーザのメディアサーバ１の入力装置１０５からの指示入力等を受け付ける。
【０２７４】
次に、ステップ４０３ｂでは、前記メッセージおよび指示入力等の内容を判定し、ユーザからの新たなマルチメディアデータの配信要求であれば（新規）、ステップ４１１ｂに進み、また、画質等のサービス品質の変更、動画の場合の早送り再生開始、ポーズ等、サービス内容の変更要求であれば（変更）、ステップ４２１ｂに進み、さらに、終了指示入力であれば、ステップ４３１ｂに進む。
【０２７５】
なお、新規な配信要求および変更要求を伝えるメッセージデータの内容は、配信、変更の対象となるマルチメディアデータの識別名称と要求品質とからなり、これらは、ＬＡＮ３やＩＳＤＮ４を介してクライアント２からメディアサーバのマルチタスクＯＳ２００ｂに渡され、さらに、マルチタスクＯＳ２００ｂによって、配信スケジューラタスク４００ｂに渡される。
【０２７６】
次に、ステップ４１１ｂでは、サービス品質管理タスク６００ｂに、ユーザの指定通りの要求品質での新規配信が可能か否かを問い合わせ、配信可能であれば、ステップ４１３ｂに進み、配信不可能であればステップ４１４ｂに進む（ステップ４１２ｂ）。
【０２７７】
次に、ステップ４１３ｂでは、新たなユーザ配信処理タスク５００ｂと配信条件テーブル４０００との生成を、マルチタスクＯＳ２００ｂに要求し、メモリ１０２の容量不足や予め設定された総タスク数を超えるなどの要因により、タスク５００ｂあるいはテーブル４０００のいずれかの生成が不可能な場合には、（ステップ４１５ｂ）ステップ４１４ｂに進み、一方、可能な場合にはステップ４０２ｂに進む。また、ステップ４１４ｂでは、配信要求のあったクライアント２に、メディアサーバ１が配信不可能である旨のメッセージを送信し、ステップ４０２ｂに進む。
【０２７８】
また、ステップ４２１ｂでは、サービス品質管理タスク６００ｂに、ユーザの指定通りのサービス内容の変更が可能であるか否かを問い合わせ、変更対象のユーザ配信処理タスク５００ｂが既に消滅しているとか、メディアサーバ１のサービス能力の限度を超える等の要因により、タスク５００ｂへの通知が不可能な場合は、ステップ４２３ｂに進み、一方、可能な場合には、ステップ４０２ｂに進む。
【０２７９】
そして、ステップ４２３ｂでは、変更要求のあったクライアント２に、メディアサーバ１が、サービス内容の変更が不可能である旨のメッセージを送信し、ステップ４０２ｂに進む。
【０２８０】
最後に、ステップ４３１ｂでは、サービス品質管理タスク６００ｂおよび配信スケジューラ４００ｂが生成した全てのユーザ配信処理タスク５００ｂに、配信処理の終了を指示するメッセージを与えた後、配信スケジューラタスク４００ｂが使用しているハードウェア資源等を開放することにより、配信スケジューラタスク４００ｂが行なう処理を終了する。
【０２８１】
次に、本発明にかかる第２の実施例におけるメディアサーバ１のユーザ配信処理タスクの処理内容について説明するが、これは基本的には、図１２を参照して説明した、第１の実施例のユーザ配信処理タスクと同様であるが、ステップ等に添字「ｂ」を付して、図２０を参照して再度説明する。
【０２８２】
図２０に、本発明にかかる第２の実施例におけるメディアサーバ１のユーザ配信タスク５００ｂの処理内容について示す。
【０２８３】
ユーザ配信タスク５００ｂは、配信スケジューラタスク４００ｂにより、タスクとして生成され、マルチタスクＯＳ２００ｂにより起動される。該タスク５００ｂは、メディアサーバ１のマルチメディアデータの配信件数分だけ生成され、マルチタスクＯＳ２００ｂによって、適宜切り替えられながら動作し、見かけ上、同時に複数のクライアント２に対する、マルチメディアデータの配信を行なっている。
【０２８４】
まず、ステップ５０１ｂでは、配信対象のデータに対応するＩＮＤＥＸデータ４０３０を主メモリ（ＲＡＭ）１０２上にロードする。ステップ５０２ｂでは、配信対象となるデータ群６０１０のすべてのデータ６０００および６０２０を、マルチタスクＯＳ２００ｂや各タスクが、読み出し可能な状態にする。通常、マルチタスクＯＳ２００ｂは、記憶装置１０６等に記憶しているデータのアクセスを管理するため、ファイルといった概念で管理するが、ステップ５０２ｂでは、６０１０のデータを格納している、すべてのファイルをオープンする。
【０２８５】
次にステップ５１１ｂでは、配信条件テーブル４０００ａの品質４００２のデータ識別子を参照し、ステップ５１２ｂでは、そのファイルに対応するＩＮＤＥＸデータを検索し、ステップ５１３ｂでは、ＩＮＤＥＸデータの４０３３を参照して、配信するデータの読みだし開始位置までシークし、ステップ５１４ｂでは、配信するデータの１単位７０５をクライアント２に転送する。ステップ５２１ｂでは、ステップ５１４ｂで送信したデータがファイルの終わり（ＥＯＦ）であるかどうかを検知し、終わりでない場合は、ステップ５２２ｂに進み、一方、終わりならばステップ５３１ｂに進む。
【０２８６】
ステップ５２２ｂでは、配信スケジューラ４００ｂから配信処理の終了を伝えるメッセージの有無を検知し、終了要求があれば、ステップ５３１ｂに進み、一方、終了要求がなければステップ５１１ｂに進む。
【０２８７】
ステップ５３１ｂでは、ステップ５０２ｂでオープンしたファイルをすべてクローズし、ステップ５３２ｂでは、サービス品質管理タスク６００ｂに配信の終了を通知し、タスク５００ｂが使用した主メモリ１０２上のメモリ空間等のリソースの開放を行なった後、マルチタスクＯＳ２００ｂにタスク５００ｂの終了を自ら要求し、タスク５００ｂの処理を終了する。なお、ステップ５１１ｂで、配信条件テーブル２０００を参照する際、変更フラグ４００４が「変更あり」を示している場合には、これを「変更なし」の状態に設定する。また、フラグ４００４が「変更なし」であれば、配信対象ファイルを切り替える必要がなく、ステップ５１２ｂの処理は省略できる。
【０２８８】
次に、本発明にかかる第２の実施例におけるメディアサーバ１のサービス品質管理タスクの処理内容について説明するが、これは基本的には、図１３を参照して説明した、第１の実施例のサービス品質管理タスクと同様であるが、ステップ等に添字「ｂ」を付して、図２１を参照して再度説明する。
【０２８９】
図２１は、第２の実施例におけるサービス品質管理タスク６００ｂの処理内容を示すフローチャートである。
【０２９０】
サービス品質管理タスク６００ｂは、配信スケジューラタスク４００ｂにより、タスクとして生成され、マルチタスクＯＳ２００ｂにより起動される。
【０２９１】
まず、ステップ６０１ｂでは、配信管理テーブル４０１０を初期化し、ステップ６１１ｂでは、配信スケジューラタスク４００ｂからのメッセージを待ち、メッセージを受信したらその内容を解釈し、メッセージの内容が、「新規配信開始」であれば、ステップ６２１ｂに進み、「配信条件変更」であれば、ステップ６３１ｂに進み、配信中のユーザ配信処理タスク５００ｂの処理の終了（配信終了）であれば、ステップ６４１ｂに進み、メディアサーバ１の配信スケジューラ自体の終了によるタスク終了処理要求（タスク処理終了）であれば、ステップ６５１ｂに進む。
【０２９２】
ステップ６２１ｂでは、配信管理テーブル４０１０のネットワーク別転送レート合計４０２０、および、サービス転送レート合計４０２５を参照し、新規に配信するデータの転送レート４０３２と、予め設定されたネットワークセグメントやバス１１７の伝送帯域とを比較して、削除データ量を採用せずに、あるいは、選択した削除データを新規に配信可能なら、ステップ６２４ｂに進み、また、いずれの削除データ量を採用しても、新規に配信が不可能なら、ステップ６２３ｂに進む（ステップ６２２ｂ）。この場合、タスク４００ｂから渡されたユーザの配信画質への要求品質と、サービス可能な転送レートを同時に満たす削除データの選択が可能であるか否かを、動画データの元の転送レートと削除データの転送レート（４０３２）とを、ＩＮＤＥＸデータを参照して調べ、条件を満たす削除データが無い場合は、配信不可能とする。ステップ６２４ｂでは、配信管理テーブルに、新規の配信要求に対応したレコード４０１１を追加し、ステップ６２６ｂでは、配信スケジューラタスク４００ｂに配信可能である旨と配信条件テーブルに設定するパラメータとを、メッセージにより伝えステップ６１１ｂに進む。
【０２９３】
次に、ステップ６２３ｂでは、配信管理テーブルを参照し、既に配信を開始しているユーザ配信処理タスクに対応する配信条件を変更すれば、新規配信が可能であるか否かをを調べ、既に配信中のデータのうち、それ以上転送レートを下げられないものがある場合等、条件変更が不可能な場合には、ステップ６２７ｂに進み、一方、条件変更が可能ならば、ステップ６２５ｂに進む。
【０２９４】
また、ステップ６２３ｂにおける配信条件を変更における、配信の可否の判定も、ステップ６２２ｂと同様に、ＩＮＤＥＸテーブルを参照して行なう。なお、ステップ６２３ｂでは、配信管理テーブルの優先度４０１３の情報を用いて、優先度の高い配信処理については、条件を変更せず、優先度の低いものから条件を変更していくようにする。
【０２９５】
ステップ６２７ｂでは、配信スケジューラタスク４００ｂに新規配信が不可能である旨をメッセージにより伝え、ステップ６１１ｂに進む。ステップ６２５ｂでは、変更した配信条件を配信管理テーブル４０１０の各レコード４０１１に設定し、対応する配信条件テーブル４０００のデータを再設定し、変更フラグ４００４を「変更あり」に設定し、ステップ６２６ｂを実行する。
【０２９６】
次に、ステップ６３１ｂでは、配信管理テーブル４０１０を参照し、変更の対象となっているレコード４０１１の内容の変更をすれば、既に配信中のデータのうち、それ以上転送レートを下げられないものがある場合等、条件変更が不可能な場合の有無を判定し、条件変更が可能な場合には、ステップ６３４ｂに進み、条件変更が不可能な場合には、ステップ６３３ｂに進む（ステップ６３２ｂ）。
【０２９７】
ステップ６３３ｂにおける配信の可否の判定も、ステップ６２２ｂと同様に、ＩＮＤＥＸテーブルを参照して行なう。
【０２９８】
なお、ステップ６３２ｂでは、配信管理テーブルの優先度４０１３の情報を参照して、優先度の高い配信処理については、条件を変更せず、優先度の低いものから条件を変更していくようにする。
【０２９９】
ステップ６３３ｂでは、配信スケジューラタスク４００ｂに配信条件変更が不可能である旨をメッセージにより伝え、ステップ６１１ｂに進む。ステップ６３４ｂでは、変更した配信条件を配信管理テーブル４０１０の各レコード４０１１に設定し、対応する配信条件テーブル４０００のデータを再設定し、変更フラグ４００４を「変更あり」に設定する。ステップ６３５ｂでは、配信スケジューラタスク４００ｂに配信条件可能である旨を、メッセージにより返答し、ステップ６１１ｂに進む。
【０３００】
次に、ステップ６４１ｂでは、配信の終了したレコード４０１１を配信管理テーブル４０１０より削除し、必要なら、他のレコードの配信条件も変更する。
【０３０１】
最後に、ステップ６５１ｂでは、サービス品質管理タスク６００ｂが使用した主メモリ１０２上のメモリ空間等のリソースの開放を行なった後、マルチタスクＯＳ２００ｂにタスク６００ｂの終了を自ら要求し、タスク６００ｂの処理を終了する。
【０３０２】
なお、新規に配信を開始するクライアントが低速回線を介したＭＰＥＧ１データの配信要求であれば、例えば、通信媒体がＩＳＤＮであり、６４ｋｂ／ｓ程度の転送レートであれば、セル１６に記述されたデータ量削減方法で削除された削除データを送信するようにし、通信媒体がアナログ回線であり、１４．４ｋｂ／ｓ程度の転送レートであれば、セル１７に記述されたデータ量削減方法でで削除された削除データを送信するようにデータを転送すれば、クライアント２側において、データを受信しながらデコードして表示すること（リアルタイム再生）も可能である。
【０３０３】
次に、本発明にかかる第２の実施例におけるメディアサーバ１の削減データ生成タスク７００ｂの処理内容について説明する。
【０３０４】
図１４は、削減データ生成タスク７００ｂの処理内容を示すフローチャートである。
【０３０５】
削減データ生成タスク７００ｂは、ユーザが、メディアサーバにクライアント２で共用する動画データを登録するときに、ユーザが指示を与えることにより、マルチタスクＯＳ２００ｂが生成し、起動する。
【０３０６】
ステップ７０１ｂでは、ユーザから登録されたＭＰＥＧ１動画の元データ６０００を読み込み、ステップ７１１ｂでは、元データ６０００を図９で説明した形式に整形し、ＩＮＤＥＸデータ４０３０に登録する。そして、ステップ７２１ｂでは、元データ６０００より、図２のテーブル１０に示すセルで示される削減方法にしたがって、複数の削減データ６０２０を生成し、ＩＮＤＥＸデータ６０３０に登録する。
【０３０７】
次に、本発明にかかる第２の実施例におけるクライアント２のメディア要求タスク９００ｂの処理内容について説明する。
【０３０８】
図１５は、メディア要求部９００の処理のフローチャートである。
【０３０９】
ステップ９０１ｂでは、ユーザから配信要求のあるデータのファイル名や、配信されたデータに利用方法の情報等を受け付ける。ここで、利用方法の情報とは、配信された動画データをブラウジングに使うか、詳細に鑑賞するといった情報である。また、かかる情報は、ユーザが入力せずに、ブラウジングを目的とするアプリケーションからの要求であれば、メディア要求タスク９００ｂが自動的にブラウジング用と判断するようにしても良い。ステップ９１１ｂでは、ユーザの用途から、動きの滑らかさか、あるいは、精細度のいずれかを、どの程度要求するかといった、動画の画質に関する要求を評価し、そのデータを供給可能なメディアサーバ１を、ＬＡＮ３、ＩＳＤＮ４に接続されているメディアサーバの中から捜しだし、要求を満たすメディアサーバ１を決定する。
【０３１０】
ステップ９２１ｂでは、ステップ９１１ｂで決定したメディアサーバ１に、配信を希望する動画データのファイル名と、画質のユーザ要求とを、メッセージによって送信し、データの配信を待つ。次に、ステップ９３１ｂでは、メディアサーバ１からの返答を待ち、「配信可能」であれば、受信したデータをマルチメディアデータ再生タスク１０００ｂにより表示し、再生が終われば、本タスク９００ｂの処理を終了する。なお、メディアサーバからの返答が「配信不可能」であれば、時間をおいてリトライした後、さらに「配信不可能」であれば処理を終了するようにしても良い。
【０３１１】
以上述べてきた、第１、２の実施例によれば、メディアサーバ１が記憶している、ある動画データをクライアント２に配信する際に、ユーザの画質への要求と、ネットワークや回線の伝送能力を含めたメディアサーバのサービス能力とを考慮して、データ量の削減を行ないながら削減データを配信することが可能になる。
【０３１２】
また、データ量の削減制御も、時々刻々と変化するサービス能力に追随して、動画のＧＯＰや音声のＡＡＵの、切れ目に合わせて、データ量削減方式を切り換えることができ、クライアント側では、配信を受ける動画が乱れたり、音声がとぎれたりノイズが混入するといったことが無くなる。以上のことから、メディアサーバ１は、配信する動画データのデータ量を削減制御することによる、ネットワークや回線、サーバの処理能力を考慮したデータの提供が可能となり、クライアント２のユーザは、希望する品質を有するデータの配信を受けることが可能になる。
【０３１３】
なお、本実施例で述べたデータ量を削減しながらの配信は、予め配信データを図９に示すように整形しておくため、データ量削除制御の処理負荷を増加させることなく実現することが可能であり、複数クライアントの同時配信要求に対し、リアルタイムな配信処理が実現できる。
【０３１４】
また、転送するネットワークのトラヒックが飽和する可能性がある場合にも、配信する動画データの転送レートを抑えながらの配信が可能であり、メディアサーバが同時に動画データを配信できるクライアントの数を増加させることができる。この時、クライアントごとに優先度を設定することが可能であるため、優先度の低いクライアントから、転送する動画のデータ量を削除していくようにすることができ、ユーザが予め定めた優先度にしたがった、ユーザの要求を満足するデータ提供を実現できる。
【０３１５】
【発明の効果】
以上のように、本発明によれば、各種のコンピュータネットワーク環境において、動画等のマルチメディアデータをクライアントに配信する際に、ユーザの希望する品質や、メディアサーバの接続しているネットワークの伝送能力を考慮して、でー多量制御することが可能になる。したがって、公衆回線等の比較的転送レートの低い伝送媒体を介しての動画データの配信も効率良く行なえる。
【０３１６】
また、転送するネットワークのトラヒックが飽和する可能性がある場合にも、配信する動画データの転送レートを抑えながらの配信が可能であり、メディアサーバが、同時に動画データを配信可能なクライアント数を増加させることが可能になる。この時、クライアントごとに優先度を設定することが可能であるため、優先度の低いクライアントから、転送する動画のデータ量を低減するように制御することができ、ユーザは予め優先度を高くしておくことにより、画質の良いデータ配信を受け続けることも可能である。
【０３１７】
以上のことから、本発明によれば、各種のネットワーク環境において、メディアサーバ上にある動画等のマルチメディアデータを、クライアントに効率良く送信するこを可能にする。
【０３１８】
【図面の簡単な説明】
【図１】第１の実施例におけるネットワーク環境の説明図である。
【図２】第１の実施例におけるＭＰＥＧ１動画データ量の削減方法を示すテーブルの説明図である。
【図３】ＭＰＥＧ１動画データのフォーマットの説明図である。
【図４】第１の実施例におけるＭＰＥＧ１動画データ量削減方式の原理説明図である。
【図５】コンピュータ端末のハードウェアの構成図である。
【図６】第１の実施例におけるメディアサーバとクライアントのソフトウェアの構成図である。
【図７】第１の実施例におけるメディアサーバの制御テーブルの構成およびデータ関連を説明する説明図である。
【図８】ＭＰＥＧ１動画および音声データフォーマットと圧縮データパケットの関係の説明図である。
【図９】ＭＰＥＧ１データ整形方式の原理説明図である。
【図１０】第１の実施例におけるＩＮＤＥＸデータの説明図である。
【図１１】第１の実施例における配信スケジューラタスクの処理内容を示すフローチャートである。
【図１２】第１の実施例におけるユーザ配信処理タスクの処理内容を示すフローチャートである。
【図１３】第１の実施例におけるサービス品質管理タスクの処理内容を示すフローチャートである。
【図１４】第１の実施例における配信データ整形タスクの処理内容を示すフローチャートである。
【図１５】第１の実施例におけるクライアントのメディア要求タスクの処理内容を示すフローチャートである。
【図１６】第２の実施例におけるメディアサーバとクライアントのソフトウェアの構成図である。
【図１７】第２の実施例におけるメディアサーバの制御テーブルの構成およびデータ関連を説明する説明図である。
【図１８】第２の実施例におけるＩＮＤＥＸデータの説明図である。
【図１９】第２の実施例における配信スケジューラタスクの処理内容を示すフローチャートである。
【図２０】第２の実施例におけるユーザ配信処理タスクの処理内容を示すフローチャートである。
【図２１】第２の実施例におけるサービス品質管理タスクの処理内容を示すフローチャートである。
【図２２】第２の実施例における削除データ生成タスクの処理内容を示すフローチャートである。
【図２３】第２の実施例におけるクライアントのメディア要求タスクの処理内容を示すフローチャートである。
【符号の説明】
１…メディアサーバ、２…クライアント、４００…配信スケジューラタスク、５００…ユーザ配信処理タスク、６００…サービス品質管理タスク、７００ａ…配信データ整形タスク、７００ｂ…削除データ生成タスク
【産業上の利用分野】
本発明は、サーバ側がクライアント側にマルチメディアデータを提供するシステムに係り、特に、各種のネットワーク環境下において、トラフィック飽和させることなく、動画データをクライアントに配信するシステムに関する。
【０００２】
【従来の技術】
近年、ネットワーク環境の整備、拡張が進展し、ローカルエリアネットワーク（ＬＡＮ）、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）、アナログ回線等の公衆回線によって構成されるＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）等の、各種のネットワーク環境において、ネットワークの接続状態を意識せずに、ネットワークに接続されたある端末装置から他の端末装置へと、動画データ等のマルチメディアデータのやりとりを行なうことが可能になってきた。
【０００３】
ところで、動画データや音声データは、基本的にデータ量が大きいため、これまで、データの蓄積、伝送等の処理を行なうためには、効率良くデータを圧縮した後に、圧縮データに対して所望の処理を行なうことが提案されている。
【０００４】
代表的な圧縮方法としては、例えば、ＩＳＯにより推奨されている「ＭＰＥＧ１（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｇｒｏｕｐ Ｐｈａｓｅ １）」等の圧縮方法が挙げられる。
【０００５】
しかしながら、このような圧縮処理を行なっても、マルチメディアデータのデータ量は、通常、膨大な量となっており、ネットワークのトラヒックの飽和を招いたり、また、例えば、サーバからクライアントにマルチメディアデータの伝送を行なう際には、非常に長い伝送時間を要する等の課題が存在していた。
【０００６】
この様な課題を解決する従来技術を開示している文献としては、特開平６−７０１７４号公報等が挙げられ、この公報では、動画データを離散余弦変換した変換データの高周波成分を削除することによって、動画データのデータ量を削減するための技術が開示されている。
【０００７】
また、ネットワークの伝送帯域を、動画データ伝送のための伝送帯域に設定し、提供する動画データのフレーム数を適宜低減することによって、動画データの伝送レートの調整を行なって、安定した動画データの供給を保証するファイルサーバが提供されている。
【０００８】
【発明が解決しようとする課題】
ところで、上述した従来技術のうち、特開平６−７０１７４号公報に開示された技術は、動画データのみのデータ量の削減には有効であるもののが、一般的に動画データには、音声データが付随しているものが多く、特に、データ量が削減された動画データと、音声データの同期の保証については考慮されていない。
【０００９】
また、動画データのフレーム数の削減のみで、提供する動画データに対する伝送レートの調整を行なっていては、変化の激しい動画像を有する動画データでは、動きの滑らかさが失われる等の問題があり、ユーザの画質への要求を考慮しながらデータ量の削減を行なう必要があった。
【００１０】
また、ネットワーク環境で動画データを供給するファイルサーバは、動画データ伝送のための伝送帯域を確保するため、クライアント数が限られている場合においては、安定した動画データの供給が可能であるものの、クライアント数が所定数以上になったときには、その途端に、新たなクライアントに対する動画データの提供が不可能になったり、既に動画データの提供を行なっているクライアントに対する、動画データの提供に影響が及び、クライアントへの動画データの提供が安定して行なえなくなる事態の発生を招いてしまうという課題が存在していた。
【００１１】
そこで、本発明は、以上のような課題に鑑みて創作したもので、サーバが提供するマルチメディアデータのデータ量を、ユーザの要求に対して提供するデータの伝送レートや、サーバに接続されるネットワークの伝送能力等を考慮して制御し、ユーザ側に配信することによって、たとえ接続されるネットワークの伝送レートが低い場合であっても、適切な品質のマルチメディアデータを提供するシステムを実現することを目的とし、また、動画でデータを提供する際には、動画データと音声データとのと同期がとれた動画データを提供することも可能にする。
【００１２】
【課題を解決するための手段】
上記課題を解決するため、以下の手段が考えられる。
【００１３】
動画データを提供するサーバと、該サーバと通信媒体を介して接続され、動画データの提供を受ける少なくとも１以上のクライアントとを有して構成される情報処理システムである。
【００１４】
そして、サーバは、動画データを、１種類以上記憶するための記憶手段と、動画データのデータ量を、予め定められた複数のデータ量削減規則のうちのいずれかに従って、削減するデータ量削減手段と、接続された通信媒体を介して、削減されたデータをクライアント側に出力する出力手段と、接続された通信媒体を介して、前記記憶手段に記憶されている、いずれかの動画データへのアクセス命令を受け付ける入力手段と、入力されたアクセス命令に応じて、データ量削減のための制御を行なう制御手段と、１以上のアクセス命令に対して削減されたデータ量の総和を演算する削減データ量演算手段と、通信媒体ごとの出力データ量を検出する伝送量検出手段とを有した構成とする。
【００１５】
前記制御手段は、入力手段がクライアントからのアクセス命令を受け付けたとき、前記削減データ量演算手段の演算結果、および、前記伝送量検出手段の検出結果、に対応して予め定めた規則に従って、前記データ量削減規則のいずれかを選択して、前記データ量削減手段を駆動し、削減されたデータを、前記出力手段に与える機能を有する。
【００１６】
また、以下の示すような態様も考えられる。
【００１７】
動画データを提供するサーバと、該サーバと通信媒体を介して接続され、動画データの提供を受ける少なくとも１以上のクライアントとを有して構成される情報処理システムである。
【００１８】
そして、前記サーバは、１種類以上の元動画データと、各元動画データに対して、そのデータ量を予め定められた複数のデータ量削減規則に従って削減した複数種類の削減データとを記憶するための記憶手段と、接続された通信媒体を介して、削減データをクライアント側に出力する出力手段と、接続された通信媒体を介して、前記記憶手段に記憶されている、いずれかの元動画データへのアクセス命令を受け付ける入力手段と、入力されたアクセス命令に応じて、削減データを選択し、前記出力手段に与える制御を行なう制御手段と、所定時間内に、出力手段が出力する削除データの量の総和演算を行なう削減データ量演算手段と、通信媒体ごとの出力データ量を検出する伝送量検出手段とを有して構成される。
【００１９】
前記制御手段は、入力手段がクライアントからのアクセス命令を受け付けたとき、前記削減データ量演算手段の演算結果、および、前記伝送量検出手段の検出結果、に対応して予め定めた規則に従って、前記削除データのいずれかを選択して、選択した削減データを、前記出力手段に与える機能を有する。
【００２０】
【作用】
サーバは、動画データを提供し、クライアントは、通信媒体を介して、サーバからの動画データの提供を受ける。
【００２１】
クライアント側では、命令送出手段によって、通信媒体を介してアクセス命令を命令を送る。
【００２２】
一方、サーバ側は、記憶手段に、動画データを１種類以上記憶しており、データ量削減手段によって、動画データのデータ量を、予め定められた複数のデータ量削減規則のうちのいずれかに従って削減する。
【００２３】
出力手段は、通信媒体を介して、削減されたデータをクライアント側に出力する。
【００２４】
入力手段は、通信媒体を介して送られてきた、前記記憶手段に記憶されている、いずれかの動画データへのアクセス命令を受け付け、さらに、制御手段は、入力されたアクセス命令に応じて、データ量削減のための制御を行なう。
【００２５】
なお、削減データ量演算手段は、１以上のアクセス命令に対して削減されたデータ量の総和を演算を行ない、また、伝送量検出手段は、通信媒体ごとの出力データ量を検出する。
【００２６】
そして、制御手段は、入力手段によってアクセス命令を受け付けたとき、前記削減データ量演算手段の演算結果、および、前記伝送量検出手段の検出結果、に対応して予め定めた規則に従って、前記データ量削減規則のいずれかを選択して、前記データ量削減手段を駆動する。この結果、削減されたデータは、出力手段に与えられ、クライアント側に送られる。
【００２７】
クライアント側の表示手段は、送られてきたデータを表示する。
【００２８】
以上は、クライアントからの要求にしたがって動画データを提供する際、サーバは、データ量削減規則を用いて、動画データのデータ量を削減してクライアント側に提供する。
【００２９】
また、他の態様によれば、以下のような作用となる。
【００３０】
クライアント側では、命令送出手段によって、通信媒体を介してアクセス命令を命令を送る。
【００３１】
一方、サーバは、記憶手段に、１種類以上の元動画データと、各元動画データに対して、そのデータ量を予め定められた複数のデータ量削減規則に従って削減した複数種類の削減データとを記憶しており、また、出力手段は、通信媒体を介して、削減データをクライアント側に出力する。
【００３２】
入力手段は、記憶手段に記憶されている、いずれかの元動画データへのアクセス命令を受け付け、さらに、制御手段は、入力手段によってアクセス命令を受け付けたとき、削減データを選択し、出力手段に与える制御を行なう。
【００３３】
なお、削減データ量演算手段は、所定時間内に出力手段が出力する削除データの量の総和演算を行ない、また、伝送量検出手段は、通信媒体ごとの出力データ量を検出する。
【００３４】
そして、制御手段は、入力手段によってアクセス命令を受け付けたとき、前記削減データ量演算手段の演算結果、および、前記伝送量検出手段の検出結果、に対応して予め定めた規則に従って、前記削除データのいずれかを選択して、選択した削減データを、前記出力手段に与えクライアント側に送信する。
【００３５】
クライアント側の表示手段は、送られてきたデータを表示する。
【００３６】
以上は、クライアントからの要求にしたがって動画データを提供する際、サーバが、複数種類の削除データのうちのいずれかを送信することによって、動画データのデータ量を削減してクライアント側に提供する。
【００３７】
以上のような動作によれば、通常ではトラヒックが飽和するような動画データの転送時においても、トラヒックの飽和を回避し、各クライアントに動画データの提供を円滑に行なうことを可能にする。
【００３８】
【実施例】
以下、本発明にかかる実施例を、図面を参照して説明する。
【００３９】
まず、本発明を、マルチメディアデータをネットワークを介して、少なくとも１台の端末（クライアント）に配信する、マルチメディアデータサーバ（以下適宜「メディアサーバ」や「サーバ」と記す）に適用した場合について説明する。
【００４０】
第１の実施例は、サーバが、クライアントから配信要求されたデータのデータ量を、予め定めた規則に従って削減し、削減データを配信する実施例である（なお、本実施例を、便宜上「ハード型」と称する）。
【００４１】
図１は、第１の実施例におけるメディアサーバのネットワーク環境の一例を示している。
【００４２】
１ａ、１ｂは、メディアサーバ、２ａ、２ｂ、２ｃ、２ｄは、クライアント、５ａ、５ｂは、ゲートウエイであり、メディアサーバ、クライアント、ゲートウエイは、コンピュータ端末として実現できる。また、３ａ、３ｂ、３ｃは、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であり、さらに詳しく述べると、ＡＴＭ（Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓｆｅｒ Ｍｏｄｅ）−ＬＡＮ等が挙げられる。
【００４３】
また、４は、ＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）であるが、ＩＳＤＮの替わりに、アナログ回線等の公衆回線や、該公衆回線と同様の伝送技術を利用した専用回線を用いても良い。
【００４４】
前述した各コンピュータ端末（単に「端末」とも記す）は、特に、以下に述べるような機能を有する。
【００４５】
端末１ａ、１ｂは、マルチメディアデータを、ネットワーク３やＩＳＤＮ４を介して、複数のコンピュータ端末に配信する機能を有するメディアサーバである。
【００４６】
端末１ａは、ＬＡＮ３ａに接続され、また、端末１ｂは、ＬＡＮ３ａ、３ｂ、およびＩＳＤＮ４に接続され、該ＬＡＮ３ａ、３ｂやＩＳＤＮ４に接続された他の端末との間で、所望のデータの伝送が行なわれる。
【００４７】
端末２ａ、２ｂ、２ｃ、および２ｄは、所定のメディアサーバとの間で、マルチメディアデータを含む各種のデータの伝送が可能であり、メディアサーバによって配信された、動画データ、音声データ等のマルチメディアデータを受信し、受信したデータを再生する機能を有している。なお、端末２ａは、ＬＡＮ３ａに、端末２ｂは、ＩＳＤＮ４に、端末２ｃは、ＬＡＮ３ｃに、端末２ｄは、ネットワーク３ｂに、各々接続されており、ＬＡＮ３やＩＳＤＮ４に接続された他の端末との間で、所望のデータの伝送が可能である。
【００４８】
端末５ａ、５ｂは、ネットワークや回線等の伝送媒体の物理的、および、論理的な伝送方式の変換を行い、異なる伝送方式を用いる伝送媒体間に渡るデータ伝送を可能とする機能を有しており、一般に、このような機能は、ゲートウェイ機能、あるいは、ブリッジ機能と呼ばれており、このような機能を有するコンピュータ端末のことを「ゲートウェイ」、あるいは「ブリッジ」と呼している。
【００４９】
また、複数の伝送媒体に渡るデータ伝送の経路制御を行う機能を有するという意味において、この機能をルータ（あるいはルーティング）機能と称し、かかる機能を有するコンピュータ端末を「ルータ」と称することもある。特に、あるネットワーク３ａから他のネットワーク３ｂへ、データ伝送を行なう機能は、ルータ機能そのものである。
【００５０】
このようなネットワーク環境下において、メディアサーバ１ａおよび１ｂは、全クライアント、２ａ、２ｂ、２ｃ、２ｄに対して、マルチメディアデータを配信することが可能である。
【００５１】
なお、メディアサーバ１ｂは、ＩＳＤＮ４、ＬＡＮ３ａ、３ｂに接続されており、それぞれの伝送媒体に接続されたコンピュータ端末との間でデータの橋渡しを行なうことが可能であるため、ゲートウェイ端末５ａと同等の機能を有するように構成されている。
【００５２】
次に、本発明の第１の実施例における、メディアサーバ１（１ａ、１ｂ）のマルチメディアデータのデータ量削減方法、削減データの配信方法の原理について説明する。
【００５３】
メディアサーバ１は、ユーザ（クライアント）からの品質要求と、ＬＡＮ３やＩＳＤＮ４の伝送速度等に起因するサービス能力を考慮して、マルチメディアデータのデータ量を削減処理し、削減処理されたデータ（以下、適宜「削減データ」と称する）のクライアントへの配信を行う。
【００５４】
以下の説明では、配信対象となるマルチメディアデータとして、ＭＰＥＧ（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ）方式で圧縮された圧縮動画データを例にとって説明する。
【００５５】
図２は、メディアサーバ１が、ＭＰＥＧ方式、特に、ＭＰＥＧ１方式の圧縮方式を使用して圧縮した圧縮動画データを配信する場合の、該圧縮動画データのデータ量削減方式１０の内容を示した図である。
【００５６】
この図において、行方向（横方向）には、ユーザの画質に対する品質要求の程度をとる。一例として、１０では、動き、あるいは、画像の精細度の優先度を示す。通常、動画のデータ量と画質とは、トレードオフの関係にあり、同じデータ量であるならば、動画の精細度を優先する場合は、例えば、単位時間あたりのフレーム数を減少させる等の処理を行なって、可能な限り動きの滑らかさが損なわれるようにデータ量の削除を行なわざるを得ず、逆に、動画の動きの滑らかさを優先する場合には、例えば、１フレームの画素数を間引いて、画像の精細度を落として、データ量の削除を行なわざるを得ない。
【００５７】
図２の１０において、列方向（縦方向）には、元の動画のデータ量を「１００」とした場合の、同一動画データのデータ量をとる。即ち、該図２の１０の下の行にいくほど、データ量は減少している。
【００５８】
なお、ここでは動画データのデータ量を削除するためのパラメータとして、「画素数、ＡＣ係数の上限値、フレーム数」の組み合わせを採用し、１つの組み合わせを「セル」と称している。したがって、図２中の、１１、１２、１３、１４、１５、１６、１７は、各々セルである。
【００５９】
例えば、横軸上の中間位置に存在するセル１１の意味するところは、元の動画データのデータ量を、動きの滑らかさと、精細度を同程度に優先しながら、そのデータ量を「５０（％）」に削減する場合の、具体的なデータ量削減方法を示すものである。以下、各セルに対応するデータ量削減のためのパラメータをデータ量削減パラメータと呼ぶ。したがって、セル１１の場合、データ量削減パラメータは、「画素数：３５２×２４０」、「ＡＣ係数の上限値：３〜４」、「フレーム数：１５（ｆｐｓ）」となっている。
【００６０】
データ量削減パラメータとして、図２では、画素数の削減、空間周波数成分の交流成分（ＡＣ成分）上限の制限、および、１秒間のフレーム数の削減を挙げてある。例えば、動画像の動きの滑らかさと精細度を同程度に優先しながら（即ち、横軸の中間位置に存在するセルを採用する）、データ量を、元データの「５０（％）」に削減するには、元の動画データに比べて、画素数を減らさず（同上）、ＡＣ成分の上限を３〜４個にし、フレーム数を半分にすることにより達成されることを示している。
【００６１】
このように、セル１１に記述された複数のパラメータを組み合わせて、すなわち、セル１１に示されているデータ量削減パラメータを使用して、データ量の削減処理を行なうことによって、データ量の制御を行なえる。すなわち、サーバは、クライアントの要求等を考慮しながら、あるセルを選択し、選択したセルに示された、データ量削減パラメータを使用して、データ量の削減処理を実行し、削減データの配信を行なう。なお、個々の削減パラメータの詳細については、後述する。
【００６２】
さて、配信する動画データのデータ量の制御は、図２の１０を用いて、次のように行う。
【００６３】
まず、ユーザ（クライアント）からの配信要求が発生した場合、メディアサーバ１では、図２の１０を参照し、ユーザの要求と、配信（サービス）能力を考慮したにデータ量となるように、配信時の初期データ量削減パラメータを決定し、該パラメータに従って、配信対象の動画データのデータ量を削減して配信を行なう。ここで、配信（サービス）能力とは、例えば、サーバに接続されている各通信媒体の、通信許容伝送レート等が考えられる。ユーザの要求のみならず、サーバに接続されている各通信媒体の、通信許容伝送レートを越えないことを条件として、データ量の削減処理が行なわれる。
【００６４】
これを仮に、セル１１に示されたデータ量削減パラメータを採用するとし、配信の途中で、ユーザ要求が、更に動きの滑らかさを優先するように変更された場合には、（横軸上で右側に存在する）セル１２で示されたデータ量削減パラメータに変更し、また、精細度を優先するように変更された場合は、（横軸上で左側に存在する）セル１３で示されたデータ量削減パラメータに変更し、それぞれ変更したパラメータを使用して、配信対象の動画データのデータ量を削減して、削減データを配信する。
【００６５】
また、セル１１に示されたデータ量削減パラメータを使用して削減処理を行なった削除データの配信中に、メディアサーバ１のサービス能力が低下し、更にデータ量を削減する必要があるときには、（縦軸下方向に存在する）セル１５に示されたデータ量削減パラメータに変更し、また、サービス能力が回復して、配信データ量を増加することが可能になれば、（縦軸上方向に存在する）セル１４に示された符号量削減パラメータに変更し、それぞれ変更したパラメータに従って、配信対象である動画データのデータ量を削減処理して、削減データを配信する。
【００６６】
さらに、ＭＰＥＧ１動画データのデータ量の削減方式について説明する。
【００６７】
その前に、ＭＰＥＧ１方式で圧縮処理された圧縮動画データのフォーマットについて説明する。ただし、ここでは本発明の説明にぜひとも必要な事項の説明を行なうのみとする。ＭＰＥＧの符号化方式やフォーマットについて記載されている文献は多数存在し、例えば、「ＡＳＣＩＩ社刊「最新ＭＰＥＧ教科書」（１１０から１２８頁等）」に述べられている。
【００６８】
図３は、ＭＰＥＧ１動画データのフォーマットの説明図である。
【００６９】
動画の画像データ４０は、ＭＰＥＧ１ビデオ符号器４１により、また、音声データ４３は、ＭＰＥＧ１オーディオ符号器４４により、それぞれ符号化され、所定サイズの圧縮動画データパケット４２と、圧縮音声データパケット４５とにパケット化される。ＭＰＥＧ１システム復号器４６は、パケット化された動画データ４２と音声データ４５とを、到着順に、パケットヘッダ等の情報を付加して、ＭＰＥＧ１システムストリーム４７として出力する。
【００７０】
次に、図４に、ＭＰＥＧ１動画データのデータ量削減方式の原理説明をするための図を示す。本実施例においては、画素数を削減する方式、圧縮動画データの空間周波数の高周波成分を削減する（ＡＣ係数の数の上限値の削減）方式、および、フレーム数を削除する方式について説明する。
【００７１】
まず、ＭＰＥＧ１方式で圧縮された動画データ（ＭＰＥＧ１圧縮動画データ）のデータ構造について説明する。ＭＰＥＧシステムストリーム４７から、圧縮動画データパケット４２だけを取り出して、圧縮（再生）順に並べると、ＧＯＰ（Ｇｒｏｕｐ ｏｆ Ｐｉｃｔｕｒｅ）と呼ばれる単位（５０）に分かれており、ＧＯＰは、さらに、Ｉ（Ｉｎｔｒａ）フレーム５１、Ｐ（Ｐｒｅｄｉｃｔｉｖｅ）フレーム５３、および、Ｂ（Ｂｉｄｉｒｅｃｔｉｏｎａｌｌｙ ｐｒｅｄｉｃｔｉｖｅ）フレーム（５２、５４）から構成される。Ｉフレーム５１は、基準フレームとも称され、該フレーム内の画素データのみを使用して、他のフレームとは独立して符号化（フレーム内予測により符号化）するフレームであり、従って、伸長して再生する場合でも、他のフレームのデータを必要としない。
【００７２】
次に、Ｐフレーム５３は、時間的に「前」に存在するフレームとの相関性を利用するフレーム間予測によって、符号化するフレームであり、Ｂフレーム５２および５４は、時間的に「前後」のフレームとの相関性を利用するフレーム間予測によって、符号化するフレームである。ＧＯＰは、少なくともＩフレームを１枚含むフレーム群のことであり、１つのＧＯＰは、Ｉ、Ｐ、およびＢフレームの符号化データを有して構成されている。
【００７３】
さらに、Ｉ、Ｐ、およびＢの各フレームは、元動画像データのフレームデータの垂直・水平各８画素（全６４画素）データを単位に、離散コサイン変換することによって得られたＤＣＴ（Ｄｉｓｃｒｅｔｅ Ｃｏｓｉｎｅ Ｔｒａｎｓｆｏｒｍ）係数からなる、複数のブロック５５から構成される。
【００７４】
図４の左下部に記載した図は、ブロック５５の内容をマトリクスイメージで表現したものである。実際のＭＰＥＧ１ストリーム中には、このようなマトリクスの左上の成分（ＤＣ）から右下の高周波成分（ＡＣ６３）に向かって、ジグザグにたどってシリアルに並べたデータを、可変長符号化したデータが存在するが、このＤＣを除いた６３個のＤＣＴ係数を「ＡＣ成分」と称する。ＡＣ成分のうちでも、ＤＣに近い左上の成分程、画質への影響が大きい成分となる。
【００７５】
なお、一般に、圧縮動画データパケット４２の切れ目と、ＧＯＰ５０の切れ目６０は、一致しないことが多い。しかし、ＧＯＰの途中から圧縮動画データを伸長して動画再生を行うと、再生画像の乱れが生じてしまう。そのため、本実施例における動画データ量の削減処理は、ＧＯＰ単位で行うものとする。
【００７６】
次に、図２に示したデータ量削減方式の説明において、前述したデータ量削減の実現方式の一例を述べる。
【００７７】
まず、画素数の削減は、既に符号化されたＭＰＥＧ１データを一旦復号し、動画像データに戻した段階で、画素を一定間隔で間引く処理や、位置的に隣接した画素に対するデータの加重平均を取る処理を行なう等によって画素数を減らし、画素数を減らしたデータを再符号化することによって実現できる。
【００７８】
ＡＣ成分の上限の制限は、前記ブロック５５中のＤＣＴ係数のうち、右下の成分（高周波成分）から、削減することによって実現するが、実際には、既に符号化されたＭＰＥＧ１データを可変長符号の段階にまで復号し、可変長符号単位で、所望のデータ量になるようにＡＣ係数を削減して、再符号化する方法や、ＤＣＴ係数の段階まで復号化し、所望のデータ量になるようにＡＣ係数を削減して再符号化する方法等により実現できる。
【００７９】
フレーム数の低減を、実際にＧＯＰを構成するフレームデータそのものを間引くことにより実現すると、再生時に誤動作が生じることが多い。これは、ＭＰＥＧデータの中に、その動画のフレームレート（１秒あたりのフレーム数）のデータが存在し、該フレームレートのデータと、フレーム数を間引かれた圧縮動画データの間で矛盾が生じるためである。よって、フレーム数の削減は、ＧＯＰを構成する、少なくとも１つのフレームのデータ（ピクチャ層のデータ）を、少なくともピクチャ層の「開始コード」、ピクチャの「通番」、「ピクチャタイプ」からなるデータであって、該フレームの中身、すなわち、圧縮された画素データを含まない、ダミーデータ５６に置き換えることにより実現する。
【００８０】
この方式によれば、形式上フレーム数には変化なく、実際には、フレームに対応した圧縮動画データ自体がないので、再生時には、時間的に前のフレームから変更がないものとみなされ、上述したような矛盾がなく、見かけ上のフレーム数の削減が実現でき、圧縮動画データの時間あたりの転送量も減少する。
【００８１】
フレーム数の削減によって、ＭＰＥＧ１動画データを所望のデータ量にまで削減する場合は、画質への影響を考慮して、まず、Ｂフレーム（５２、５４）からダミーデータ５６に置き換え、全てのＢフレームを置き換えても目的のデータ量削減を達成できなない場合には、Ｐフレームをダミーデータ５６に置き換え、さらに、全てのＰフレームを置き換えても目的のデータ量削減を達成できない場合には、さらに、Ｉフレームをダミーデータ５６に置き換えるというように、段階的にダミーデータ５６への置き換えを行っていく。
【００８２】
このように、データ量の削減方式を示す図２の１０を参照して、必要に応じてＭＰＥＧ動画データのデータ量を削減しながら、削減データを配信することにより、ユーザの配信品質要求と、メディアサーバの配信能力を考慮した、配信マルチメディアデータのデータ量制御を行なうことができる。
【００８３】
なお、ＭＰＥＧ方式以外の動画や、音声のみからなるデータや、静止画等のマルチメディアデータにおいても、データ量とユーザの配信品質要求を考慮した削減方式を定めることは可能である。
【００８４】
例えば、符号化された音声データでは、ステレオのデータをモノラル化する方法や、サンプリング周波数や量子化ステップを粗くする方法等によりデータ量を削減することが可能であり、符号化された静止画データでは、画素数を減らす方法等によりデータ量を削減できる。また、図２の１０は、メディアサーバ１が扱うマルチメディアデータのうち、動画、静止画等のデータ種別ごとに予め定めておき内蔵しておく構成にする。
【００８５】
以下に、以上述べてきたメディアサーバ１によるマルチメディアデータの配信を実現する方法について説明する。なお、本実現方法の説明においても、配信対象となるマルチメディアデータを、ＭＰＥＧ１方式で圧縮処理された圧縮動画データを例にとり説明する。
【００８６】
ＭＰＥＧ１動画データのデータ量を削減しながらの、削減データのクライアント２への配信は、基本的に、次の示す方法によって行なう。
【００８７】
メディアサーバ１は、配信対象となる動画データの種類毎に、図２に示すデータ量削減基準テーブルを備えていて、該基準テーブル１０に示した削減方法にしたがって、配信条件（ユーザの要求とメディアサーバ１のサービス能力）に、最も近いデータ量削減方法を示すセルを決定し、該セルに対応するデータ量削減パラメータを用いたデータ量削減により、データ量を削減制御しながら、削減データを配信する。仮に、配信中に配信条件が変更されたときには、その変更された配信条件に最も近い、データ量削減方式に切り替えて配信する。この時、データの削減方式の切り替えは、ＧＯＰの切れ目で行う。
【００８８】
なお、配信条件は、ユーザの要求とメディアサーバ１のサービス能力で決定される。ユーザの要求は、例えば、図２に示すセルを１つ選択するために、図２の横軸方向のセル位置を決定する命令に相当し、通常、クライアントは、コマンドを入力することによって、サーバ側に、図２の横軸方向のセル位置を決定する命令を与え、サーバがこれを受け取る。なお、サーバは、通常、複数のクライアントからの要求に答えるために、複数の削減データを、複数の通信媒体を介して、クライアント側に送信している。また、当然のことながら、１つのサーバが処理することができる、削減データのデータ量の総和には、上限値（しきい値）が存在する。
【００８９】
また、メディアサーバ１のサービス能力とは、メディアサーバ１に接続される各通信媒体の最大伝送レート（しきい値）のことを意味し、サーバは、これを越えないように、データ量を削減したセルを選択する（通常、前記選択されたセルの存在位置を基準として、縦軸下方向に存在するセルを選択することになる）。
【００９０】
このように、サーバは、全ての削減データのデータ量および各通信媒体の最大伝送レートの少なくとも一方が、各々に対して予め定められているしきい値を越えたとき、前記データ量削減規則のうちから、前記削減データ量演算手段の演算結果および各通信媒体の最大伝送レートの双方が、各々に対して予め定められているしきい値を越えないように、セルを選択していき、選択したセルに対応する削減パラメータを使用して、データ削除処理を行なう情報処理システムである。
【００９１】
なお、通常は、全くデータ削除処理を行なわずに、全ての削減データのデータ量および各通信媒体の最大伝送レートの少なくとも一方が、各々に対して予め定められているしきい値を越えたときに始めて、優先度の小さな順に、動画データのデータ量を削減しておく機能を有するように、サーバを構成しても良い。なお、このような優先度は、クライアントからサーバに与えるものとする。
【００９２】
図５は、図１で説明したコンピュータ端末のハードウェア構成を示す構成図である。
【００９３】
１０１は、端末全体を制御する中央処理装置（ＣＰＵ）、１０２は、プログラムが動作し、データ量削除制御用のデータを保持するテーブルを一時的に確保する主メモリで、ＲＡＭで実現される。
【００９４】
１０３は、ＣＰＵ１０１等に、一定間隔で割込み信号や日時の情報を供給する時計装置（クロック）である。１０４は、ユーザの指示入力を取り込むためのマウス、１０５は、同様にユーザの指示入力を取り込むためのキーボードである。
【００９５】
１０６は、ユーザのデータを保存するための記憶装置であり、ハードディスク（ＨＤ）や光磁気ディスク（ＭＯ）で実現される。
【００９６】
１１０は、ユーザに処理結果を表示して伝えるためのディスプレー装置、１１１は、画像情報を取り込むためのカメラであり、これらは、画像入出力制御装置１０８により制御される。
【００９７】
１０９は、ディスプレー１１０に表示するデータを保持するメモリ（ＶＲＡＭ：Ｖｉｄｅｏ ＲＡＭ）であり、画像入出力制御装置１０８により、常に最新の表示データが書き込まれる。１１５は、カメラ１１１によって取り込んだ動画や静止画等の画像データの圧縮処理および伸長処理を行う画像コーディックである。
【００９８】
１１３は、音声情報を取り込むマイク、１１４は、音声情報をユーザに伝えるスピーカであり、これらは、音声入出力制御装置１１２によって制御される。
【００９９】
１１６は、マイク１１３によって取り込んだ音声データの圧縮処理および伸長処理を行う音声コーディックである。１０７は、ＬＡＮ３に端末を接続するためのネットワーク接続制御装置（ＬＡＮボード）である。
【０１００】
１１８は、ＩＳＤＮ４に端末を接続するためのモデム等の回線接続制御装置である。１２０は、ディジタルシグナルプロセッサ（ＤＳＰ）であり、特定の処理を行うマイクロプログラムを、記憶装置１０６からロードし、ＣＰＵ１０１と独立して高速に、ロードしたマイクロプログラムを実行する。このようなマイクロプログラムは、通常、記憶装置１０６等に予め記憶しておき、必要に応じてＤＳＰ１２０がマイクロをロードして実行する。
【０１０１】
またＣＰＵ１０１は、ＤＳＰ１２０に、データやそのデータに関する処理内容の情報を与えて、特定の処理の実行を依頼し、ＤＳＰ１２０が、特定の処理を実行した後、その処理結果を受け取ることによって、端末処理全体での処理速度を向上することを可能とする。なお、ＤＳＰ１２０が行う特定の処理として、主なものに、画像、音声データの圧縮、伸長処理や、ネットワークや回線との接続制御処理等が挙げられる。これらの処理のうち、例えば、画像や音声データの圧縮処理等は、処理を行うプログラムを主メモリ１０２上に、ＣＰＵ１０１がロードして、ＣＰＵ１０１が、ロードしたプログラムを実行することによっても実行可能であり、また、画像コーディック１１５や音声コーディック１１６等の専用ハードウェアに対して、ＣＰＵ１０１が、処理を行なうことを依頼し、処理が実行されるようにしてもよい。
【０１０２】
本実施例においては、後述するユーザ配信タスク５００ａが、動画データのＧＯＰや音声データのＡＡＵ（これについては後述する）を主メモリ１０２上にロードし、前述のデータ量削減処理を行なうマイクロプログラムをＤＳＰ１２０にロードし、ＤＳＰ１２０が、該マイクロプログラムを実行することによって、動画データや音声データのデータ量の削減を行なうか、あるいは、主メモリ１０２上に、予め記憶装置１０６に記憶している、前述したデータ量の削減処理を行なうプログラムをロードし、ＣＰＵ１０１により、動画データや音声データのデータ量の削減処理を行なうものとする。この時発生する動画、音声の、デコード処理、エンコードの処理には、画像コーディック１１５、音声コーディック１１６を使用して、各々の処理を行なわせるようにしてもよい。
【０１０３】
１１７は、各装置を接続し、装置間相互でのデータのやり取りを行なうことを可能にするためのバスである。
【０１０４】
なお、図１を参照して説明したコンピュータ端末において、全ての端末に必須な構成要素は、ＣＰＵ１０１、主メモリ１０２、クロック１０３、記憶装置１０６、およびバス１１７であり、その他の装置は、端末に必要な機能を考慮して、必要に応じて搭載するように構成すればよい。
【０１０５】
なお、本実施例において、以下に詳細に説明するメディアサーバ１では、マウス１０４、キーボード１０５、ＬＡＮボード１０７、モデム１１８、ディスプレイ１１０、画像入出力制御装置１０８、ＶＲＡＭ１０９、および、ＤＳＰ１２０が、少なくとも必要になる。
【０１０６】
一方、クライアント２では、マウス１０４、キーボード１０５、ＬＡＮボード１０７、モデム１１８、ディスプレイ１１０、画像入出力制御装置１０８、画像コーディック１１５、ＶＲＡＭ１０９、スピーカ１１４、音声入出力制御装置１１２、音声コーディック１１６、および、ＤＳＰ１２０が、少なくとも必要になる。
【０１０７】
図６は、本発明にかかる第１の実施例における、メディアサーバ１とクライアント２のソフトウェア構成を示す図、即ち、機能ブロック図である。
【０１０８】
まず、図６の（ａ）を参照して、メディアサーバ１のソフトウェア構成について説明する。
【０１０９】
２００ａは、メディアサーバ１の基本システムソフトウェア、あるいは、オペーレティングシステム（以下「ＯＳ」と記す）と称されるマルチタスクＯＳであり、メディアサーバ１上で動作するソフトウェアへのＣＰＵ１０１の機能の割当て管理、図５を参照して説明した各ハードウェア装置資源の管理、メモリ１０２の論理的な使用単位での管理、ソフトウェアおよびハードウェアの処理実行のスケジューリング等を行なうためのソフトウエアであり、いわゆるマルチタスク処理を行なう。マルチタスクＯＳ２００ａは、通常、ＬＡＮ３やＩＳＤＮ４を介して、他の端末とデータ通信を行う際の通信手順の制御等を行うためのプロトコル処理部２１０ａや、記憶装置１０６の動作制御や記憶装置１０６に格納するデータのファイル管理を行うファイルシステム２２０ａを含んで構成される。
【０１１０】
３００ａは、メディアサーバ１において動作するソフトウェアの実行単位で、メディアサーバ１上に複数存在し、一般に、タスク（あるいは、プロセス）と称されるものである。なお、以下に述べる４００ａ〜７００ａも、タスク（あるいはプロセス）であり、マルチタスクＯＳ２００ａ側から見た扱い方は、３００ａに対するのと同様である。複数存在するタスク３００ａは、マルチタスクＯＳ２００ａにより生成され、ユーザやマルチタスクＯＳ２００ａによって、個々に指定された優先度に基づき、実行順序を決定や、ハードウェア資源へのアクセス等の調整を行なうことにより、中断、実行待ち、終了等の実行状態になるように管理される。
【０１１１】
以下に述べるメディアサーバ１において、マルチタスクＯＳ２００ａは、ＬＡＮ３からのデータの着信、ユーザの入力装置１０５等を介した入力、記憶装置１０６の処理終了等の、イベントに伴うＣＰＵ１０１への割込みに対し、即座に優先度に基づき、タスク３００ａの実行順序の変更を行う、リアルタイム性を有したマルチタスクＯＳである。
【０１１２】
本実施例においては、特に、マルチタスクＯＳ２００ａは、タスク間での情報（メッセージ）伝達の支援、ＬＡＮ３、ＩＳＤＮ４から送られてきたメッセージをプロトコル処理部２１０ａによる処理を介してタスクへ伝達する等の、異なるネットワークや回線に渡るタスク間通信支援機能を有し、また、マウス１０４、キーボード１０５等の入力装置を介してユーザが入力した入力内容を、必要に応じてタスクに伝達したり、タスクのデータ出力要求を受け付けて画像入出力制御装置１０８を制御し、ディスプレー１１０に、要求に適合したデータを表示する等の、入出力制御機能も有している。
【０１１３】
４００ａは、クライアント２からのマルチメディアデータ配信要求を受け付け、ユーザ配信処理タスク５００ａに配信要求を発したクライアント２への、データの配信処理を依頼する、配信スケジューラタスクである。また、ユーザ配信処理タスク５００ａは、マルチタスクＯＳ２００ａにより、ユーザからの配信要求の件数分だけ生成されるが、一般にＯＳが扱うことが可能なタスク数は、ハードウェアの仕様等によって制限されており、そのような制限数を超える場合には、配信を行わない。なお、配信スケジューラタスク４００ａの具体的な処理内容については後述する。
【０１１４】
５００ａは、要求を発したクライアントに対して、マルチメディアデータの配信を行うユーザ配信処理タスクであり、該タスクは、ユーザの指定したサービス品質と、メディアサーバ１の処理負荷やＬＡＮ３、ＩＳＤＮ４の伝送能力を考慮して、サービスするデータの品質を制御する、すなわち、データ量削減パラメータを定め、データ量の削減制御を行なう。
【０１１５】
該制御は、例えば、ユーザの品質要求があるレベル以上であるときや、メディアサーバのサービス能力が高くないときに（配信データに対して、通信媒体の伝送能力が小さなとき）、配信するオリジナルのマルチメディアデータのデータ量を削減して配信することにより実現する。ユーザの指定したサービス品質に関する情報（即ち、図２の１０において、セルの横軸方向の位置を定める情報）は、配信スケジューラタスク４００ａにより、また、メディアサーバ１の処理負荷やＬＡＮ３、ＩＳＤＮ４の伝送能力等の、メディアサーバ１のサービス能力に関する情報は、サービス品質管理タスク６００ａにより、それぞれ取得する。該タスク５００ａによるデータ量制御の具体的な方法については、後述する。
【０１１６】
６００ａは、メディアサーバ１の処理負荷やＬＡＮ３、ＩＳＤＮ４の通信品質等、メディアサーバ１のサービス能力に関する情報に基づき、配信のサービス品質の決定、および、ユーザ配信処理タスク５００ａ等に、サービス品質の情報を提供するサービス品質管理タスクである。なお、公知となっているＯＳには、ＣＰＵ１０１の処理負荷を逐次、数値で評価して、各タスクに通知する機能を有するものがある。また、ＬＡＮ３に流れるデータパケットの流量を監視することにより、ＬＡＮ３中のデータの混雑の程度を数量的に評価し、各タスクに通知する機能を有するソフトウェアもある。また、サービスするマルチメディアデータの転送レートを、メディアサーバ１が、該データごとの情報として予め有し、メディアサーバ１が、クライアント２に配信中のデータの種類と、各転送レートの情報とを参照して、自ら配信能力を数量的に評価して、各タスクに通知する機能を有するように構成することも考えられる。このように、６００ａが提供するサービス能力の情報は、メディアサーバ１が自ら検知するか、クライアント２からのデータ要求のような外部からの情報を用いて検知した、サービス能力を数量的に表現したものとし、特に、後者の検知方法の実現例については、後述する。また数量的に表現されたサービス能力値の伝達は、主メモリ１０２の上の特定の領域を情報伝達用に割当て、該領域を、タスク３００ａ乃至７００ａが共有することによって実現される。
【０１１７】
７００ａは、配信するオリジナルのマルチメディアデータのデータ量を、高速に削減処理して配信を容易にするようにデータを整形する、配信データ整形タスクである。なお、該タスク７００ａの具体的な処理内容については、後述する。
【０１１８】
次に、図６（ｂ）を参照して、クライアント２のソフトウェア構成について説明する。
【０１１９】
８００ａは、クライアント２のＯＳであり、機能的には、メディアサーバ１のＯＳ２００と同様である。また、ＯＳ８００ａは、マルチタスク２００ａと同様に、通信制御等を行うプロトコル処理部８１０ａや、ファイルシステム８２０ａを有して構成される。
【０１２０】
９００ａおよび１０００ａは、ＯＳ８００ａ上で動作するタスクである。
【０１２１】
９００ａは、ユーザの指示により起動され、ユーザの必要とするマルチメディアデータの名称、および、配信時のサービス品質等の要求を取り込み、これらの情報をメディアサーバ１に、ＬＡＮ３やＩＳＤＮ４等を介して伝送し、また、配信されてきたデータを受信する、メディア要求処理タスクである。該タスク９００ａの具体的な処理内容については、後述する。
【０１２２】
１０００ａは、メディア要求タスク９００ａが受信した動画、静止画、音声等を有するマルチメディアデータを再生する、マルチメディアデータ再生タスクである。該タスク１０００ａは、メディア要求タスク９００ａが、マルチメディアデータを全て受信終了してから、該データの再生を開始するようにしても良いし、全ての受信処理を完了する前に、受信したデータを逐次再生するようにしても良い。特に、動画等の再生では、時間的制約条件が課される場合があり、このような場合には、後者のような再生方法を採用すれば良い。また、該タスク１０００ａが行なう処理は、画像コーディック１１５や音声コーディック１１６のような専用ハードウェアによって実行されても良いし、ＤＳＰ１２０によるマイクロプログラムの実行やＣＰＵ１０１による主メモリ１０２上のソフトウェアの実行によって、行なわれても良い。
【０１２３】
次に、本発明にかかる第１の実施例における、メディアサーバ１の有する制御テーブルやデータ構造について説明する。
【０１２４】
メディアサーバ１では、図２の１０に示すテーブルと、図７に示す各制御テーブルを、主メモリ１０２上に格納し、少なくとも、マルチタスクＯＳ２００ａ、配信スケジューラタスク４００ａ、ユーザ配信処理タスク５００ａ、サービス品質管理タスク６００ａ、および、配信データ整形タスク７００ａが参照可能な、アドレス上に確保する。以下、図７に示す各制御テーブルについて説明する。
【０１２５】
２９９９は、配信するＭＰＥＧ１データの元データである。後に詳しく説明する配信データ整形タスク７００ａでは、元データ２９９９から、データ量の削減を行ないやすいように整形したデータ３０００（以下、整形済みの元データと記す）と、データ量削減時に、削減処理対象のＧＯＰの先頭からのバイト数と該ＧＯＰのサイズを、ＧＯＰごとに記述した、データ３０００に対応するＩＮＤＥＸデータ２０３０を生成する。
【０１２６】
当然のことながら、メディアサーバ１には、複数種類の整形済み元データ３０００が存在し、ＩＮＤＥＸデータ２０３０も、整形済み元データ３０００と一意に対応して複数存在する。ＩＮＤＥＸデータ２０３０の内容については、後述する。
【０１２７】
２０００ａ、ｂは、配信条件テーブルであり、これは配信スケジューラタスク４００ａにより、前述したユーザ配信処理タスク５００ａ（図７の５００ｃ、ｄ）と一意的に対応付けられて生成される、ユーザへの配信条件に関する情報を記述したテーブルである。ユーザ配信処理タスク５００ａと同様に、配信条件テーブル２０００も、配信件数分だけ存在し、１つのテーブル２０００には、少なくとも、ファイル名２００１、（サービス）品質２００２、（転送）状態２００３、および（配信条件）変更フラグ２００４の各データの内容が記述されている。
【０１２８】
該テーブル２０００は、配信スケジューラタスク４００ａにより生成された後は、必要に応じてサービス品質管理タスク６００ａにより、その内容が変更される。
【０１２９】
ファイル名２００１は、配信する整形済みの元データ３０００を指定するための識別子である。
【０１３０】
品質２００２は、ユーザに提供する動画の品質に関するデータであるが、図２の１０に示す各セルのうち、現在配信中の動画データのデータ量制御方式に対応したセルに記述された、データ量制御パラメータが記憶保持されている。
【０１３１】
状態２００３は、最新のデータの配信状態を表すデータであり、例えば、データの転送中には「転送中」と、ユーザのポーズ要求により配信が一時的に停止している場合は、「待ち」と、記憶される。
【０１３２】
変更フラグ２００４が示すフラグは、該テーブル２０００が、配信スケジューラタスク４００ａにより新規に生成されたとき、および、サービス品質管理タスク６００ａによりその内容が変更されたときに、「変更あり」を示すように設定される。また、該フラグ２００４は、ユーザ配信処理タスク５００ａが、２００４を参照したときに、「変更なし」を示すように設定される。
【０１３３】
２０１０は、メディアサーバ１がユーザへのサービス能力を管理するためのデータを保持する配信管理テーブルである。該テーブル２０１０は、メディアの配信要求ごとに、少なくとも、要求したクライアントのクライアントＩＤ２０１２、配信の優先度２０１３、メディア種別２０１４、メディアの転送レート２０１５、配信処理の状態２０１６等の情報を保持する配信状況レコード２０１１（図７では、３つのクライアント毎に、２０１１ａ、２０１１ｂ、２０１１ｃとしている）を情報として持っている。
【０１３４】
さらに、２０１０は、メディアサーバ１に接続している通信媒体ごとに、転送中のデータの転送レートの最新の合計値を常に保持する、ネットワーク別転送レート合計レコード２０２０、および、メディアサーバ１が転送中のデータの転送レートの最新の合計値を常に保持する、サービス転送レート合計レコード２０２５を、情報として持っている。
【０１３５】
配信状況レコード２０１１は、ユーザからの配信要求があったときに、配信が可能であれば追加され、ユーザ配信処理タスク５００ａに一意に対応して存在する。さらに、レコード２０１１中の各情報の設定方法等について説明する。
【０１３６】
クライアントＩＤ２０１２は、ネットワーク上でのクライアントの論理アドレス（例えば、ＩＰアドレス等）に一意に対応する識別子であり、他に、メディアサーバ１へのユーザアカウント等を使用することも可能である。優先度２０１３は、メディアサーバ１における各配信処理の優先度を数値で表したものであり、クライアント２が、配信要求時に指定するのが一般的であるが、メディアサーバ１が、予めクライアントＩＤ毎に定めておいた優先度を使用するようにしてもよい。メディア種別２０１４は、動画、静止画と言った、配信中のメディアの種類の識別子であり、配信データのファイル名２００１と同一の情報を用いれば良い。
【０１３７】
転送レート２０１５は、配信するデータ毎の転送レート値であり、このデータは、後述するＩＮＤＥＸデータ２０３０中のデータと同一のものである。削除処理され、配信されるデータのデータ量に一意に対応して、該転送レート２０１５が定まるため、転送レート２０１５は、見方によっては、データ量であるともいえる。
【０１３８】
状態２０１６は、前記配信条件テーブル２０００の状態２００３と同一のデータであり、最新のデータの配信状態を表す、「転送中」、「待ち」等の情報が記憶される。２０１２〜２０１６は、配信開始時に、サービス品質管理タスク６００ａによって、新規にレコード２０１１が追加される時点で設定され、以後、ユーザの新たな配信要求の追加や配信条件の変更に伴って、２０１２〜２０１６の内容は、追加、変更される。なお、かかる変更処理の内容については、後に、サービス品質管理タスク６００ａの処理の説明部分において述べる。
【０１３９】
次に、ネットワーク別転送レート合計レコード２０２０は、ユーザからの新規配信要求の追加時や配信要求の変更時に、サービス品質管理タスク６００ａにより更新される情報であり、該タスク６００ａは、複数のＬＡＮやＩＳＤＮ（ＷＡＮ）４のような、サーバ１に接続される通信媒体（以後「ネットワークセグメント」と称す）ごとに、配信処理中のデータの転送レートの合計を計算した値を設定する。この時、タスク６００ａは、転送状態２０１６を参照して、転送中のレコード２０１１を見つけ出し、クライアントＩＤ２０１２を手がかりに、ネットワークセグメントを特定し、ネットワークセグメント毎に転送レート２０１５を合計する。全てのネットワークセグメント毎に転送レートを計算し、それぞれレコード２０２０の中のデータ２０２１、２０２３として設定する。
【０１４０】
ネットワークセグメントとは、物理的なネットワークの単位のことであり、例えば、メディアサーバ１にＬＡＮボード１０７を複数装備し、かつ、それぞれのＬＡＮボードからアクセス可能なＬＡＮ３が異なる場合、メディアサーバ１は、異なるネットワークセグメントにアクセスしているとする。
【０１４１】
なお、ネットワークセグメント毎に使用可能な転送レート（伝送帯域２０２２）は、予め定められており、この情報は、新規に配信を開始するか否かを決定する場合に使用する。すなわち、セグメント毎に、許容可能な転送レートの上限値が、伝送帯域２０２２によってて定められており、いずれかのセグメントにおいて、その転送レートが伝送帯域を越えるような場合には、越えないように、データ量の削減処理が行なわれることになる。
【０１４２】
サービス転送レート合計レコード２０２５は、ユーザからの新規配信要求の追加時や配信要求の変更時に、サービス品質管理タスク６００ａにより更新される情報であり、該タスク６００ａは、メディアサーバ１が配信処理中のデータの転送レートの合計を計算して、２０２７に設定する。この時、該タスク６００ａは、状態２０１６を参照して、転送中のレコード２０１１を見つけ出し、該レコードについての転送レート２０１５を合計する。レコード２０２５には、メディアサーバ１が備えるバス１１７が、データ配信可能な転送レートの上限値（伝送帯域２０２６）を予め決めておき、この値を参照して、新規にデータ配信を開始するか否かを決定する場合に使用する。
【０１４３】
すなわち、サーバが扱うことが可能なマルチメディアデータに対する転送レートの合計の上限値（２０２７）を、伝送帯域２０２６によって定めており、転送レート２０２７が、この伝送帯域２０２６を越えるような場合には、越えないように、データ量の削減処理が行なわれることになる。
【０１４４】
次にＩＮＤＥＸデータ２０３０について、説明する。本実施例においては、配信対象の動画データ毎に、図２のテーブル１０と同様のテーブルを、メディアサーバ１に備えており、該テーブル１０の各セルで示された削減方式に従って、前述したように、ユーザが与えるユーザ要求と、伝送能力で定まるサービス要求を考慮した、データ量削減方式を示すセルを決定し、データ量を削減制御しながらデータを配信し、配信中に配信条件が変更されたときには、その変更された配信条件に最も近い（例えば、現在のセル位置を基準とした時、特定方向に隣接するセルで示される）データ量削減方式に切り替えて配信するが、この時、実際のＭＰＥＧ１データの構成上、次のような問題点がある。
【０１４５】
図８には、ＭＰＥＧ１動画および音声データのフォーマットと、動画および音声データパケット構成の関係を示す。動画データのパケットとは、前述のように動画の符号化器４１が符号化しパケット化する際、一定のサイズに区切った単位であり、図に示すように、動画のＧＯＰ５０の切れ目（６０）と、該パケットの切れ目は一致しない場合が多い。また、音声についても、ＧＯＰと同様に、再生時の単位としてＡＡＵ（Ａｕｄｉｏ Ａｃｃｅｓｓ Ｕｎｉｔ）５１（５１ａ等）があるが、音声の符号化器４５が符号化しパケット化する際、一定のサイズに区切った単位である音声データのパケット４４と、ＡＡＵ５１の切れ目（６１）とは一致しない場合が多い。さらに、音声も、ＡＡＵの途中から再生すると正常に再生されない。よって、動画は、ＧＯＰの境界から、音声はＡＡＵの境界から再生できるようにする必要がある。
【０１４６】
しかしながら、一般のＭＰＥＧシステムストリーム４７は、前述したように、圧縮動画データパケット４２および圧縮音声データパケット４４の単位で、多重化されており、ＧＯＰやＡＡＵの単位では多重化されていない。これは、従来ＭＰＥＧ１のデータが、１つのコンピュータ端末内で、ハードディスク等の記憶装置から読みだされ、バスを介してデコーダへ転送され、さらに、デコードされてディスプレイに表示するという、使用環境を想定しているためである。即ち、バスやネットワークにおけるデータの伝送は、データをパケット化して行なわれるが、一般に、ネットワークよりバスの方が、データ伝送の信頼性が高く、伝送速度が高速であり、パケットが欠落したり、パケットの到着順が狂ったり、伝送遅延が発生することが、比較的少ない。またデコーダも、ＧＯＰ、ＡＡＵのように、意味のある単位でデコードするため、伝送されて来るＭＰＥＧ圧縮データを、一旦格納するためのメモリバッファが必要となるが、該メモリバッファを構成するＲＡＭは、高価であるため、あまり大きなパケットで伝送すると、大容量のメモリバッファを必要とし、デコーダが高価になる。
【０１４７】
以上のような理由から、音声も動画もエンコードしたデータ順に、固定長にし、比較的小さなサイズでパケット化し、次々に、パケットを多重化していく方法が採用されてきた。しかしながら、ＭＰＥＧ１データもネットワークや回線を介して伝送することは一般的になりつつあり、ＲＡＭの容量あたりの価格も低下し続けている。
【０１４８】
このため、ネットワークや回線の伝送速度等に適応してデータ量を制御しながら、既圧縮のＭＰＥＧ１等の動画データを配信するには、一般的なシステムストリーム４７のままでは、動画および音声データのデータ量の削減処理が複雑になることや、動画と音声の同期がとれなくなるといった危険性がある。
【０１４９】
したがって、まず、図９に示すように、ＧＯＰ５０ａと時間的に対応するＡＡＵ５１ａ、５１ｂ、５１ｃ、５１ｄを、一まとめにし（７０ａ）、これを再パケット化するＭＰＥＧ１データ整形を行い、図２のテーブル１０のセルで示される削減方法に従って、データ量の削減を、高速かつ容易に行なえるようにすることが必要である。
【０１５０】
次に、図１０に、前記手順で整形した元データ３０００と、ＩＮＤＥＸデータ２０３０の構成を示す。配信する動画データのデータ量制御を実現するには、７０ａ、７０ｂ等の、ＧＯＰと対応するＡＡＵとの組み合わせを、１つのデータ単位とし、該単位の切れ目で、データ量削減方式を切り替える。即ち、データ量削方式を示すテーブル１０にある、データ量削減のためのパラメータを変更する。
【０１５１】
そのため、まず、前述のＩＮＤＥＸデータ２０３０には、データ３０００の本来の転送レート２０３１、および、単位７０（７０ａ、７０ｂ、７０ｃ、７０ｄ、７０ｅ）毎の、データ３０００の先頭からのサイズ（Ｓｅｅｋサイズ）２０３２（Ａ１、Ａ２、Ａ３、Ａ４、Ａ５）と、各単位自体のサイズ（Ｒｅａｄサイズ）２０３３（ａ１、ａ２、ａ３、ａ４、ａ５）を格納しておく。
【０１５２】
ＩＮＤＥＸデータ２０３０の生成は、元データの整形処理と同時に、あるいは、並行して行なうことが可能であり、効率的でもある。
【０１５３】
配信するデータのデータ量制御方式を切り換える場合には、常にＩＮＤＥＸデータ２０３０を参照し、単位７０を一括して同一のデータ量削減方式で削除処理し、該削減処理が終了すると、データ量削減方式の変更の必要性を判定し、変更の必要があれば、次の単位を、変更したデータ量削減方式を使用して、一括して削減処理を行なう。
【０１５４】
以上述べてきたように、元データの整形を行ない、ＩＮＤＥＸデータ２０３０を利用することにより、配信動画の再生に乱れを発生させず、効率良くデータ量の制御を行ないながら、削除データの配信が可能になる。
【０１５５】
また、ユーザから、動画の飛ばし見や、ブラウジングなどによる検索等の配信要求があった場合には、前記単位を、所定間隔で選択していき、選択した単位を、ユーザに配信することが実現できるため、元データの整形、ＩＮＤＥＸデータ２０３０の利用は、飛ばし見や、早送り再生（順方向及び逆方向）の実現も可能とする。なお、これらの特定の要求に対しては、図２の特定のセルを採用するように、予め定めておけば良い。
【０１５６】
さらに、ＩＮＤＥＸデータ２０３０に、ＧＯＰと対応するＡＡＵをまとめた一つのデータの単位７０ごとに、該単位内での動きの大きさや精細度等を数量的に評価し、それぞれデータ２０３４、データ２０３５として保持することにより、ユーザの要求がなくとも、サーバが自動的に動画データの削除を行なうことが可能となる。
【０１５７】
即ち、精細度２０３５に比べて、動き２０３４の大きな単位７０においては、動画の高周波成分を削減して、空間的解像度を落とし、動き２０３４に比べて精細度２０３５の大きい単位７０においては、動画のフレーム数を削減して時間的解像度を落とし、動き２０３４及び精細度２０３５が同程度の場合には、空間的及び時間的解像度を同程度に落とすことにより、データ量削減処理を行なう。
【０１５８】
具体的には、２０３４と２０３５のデータの組に対して、予めセルを対応させておき、サーバは、２０３４と２０３５のデータで定まるセルが示す、データ量削除方式を採用して、データ削除処理を自動的に行なう。この場合、接続される通信媒体の伝送能力を考慮した、セルの定め方をしておけばよい。
【０１５９】
なお、サーバがユーザの要求が発生していても自動的にセルの選択を行なうシステム構成にするか否かにかかわらず、サーバに接続される通信媒体を、伝送速度６４（ｋｂｉｔ／秒）のＩＳＤＮ回線で構成した場合には、データ量削減方式として、画素数を、縦１２０画素、横１７６画素とする、セルを用意しておき、該セルを選択するようにすればよい。また、前記通信媒体を、伝送速度１４．４（ｋｂｉｔ／秒）のアナログ回線で構成した場合には、データ量削減方式として、画素数を、縦６０画素、横８８画素とする、セルを用意しておき、該セルを選択するようにすればよい。
【０１６０】
さて、前述の２０３４、２０３５は、サーバが自ら定めるデータであるが、動きの大きさの評価は、元データの整形を行なう際に、単位７０を構成するフレームデータに存在する動きベクトルの大きさに基づいて行なう。即ち、例えば、単位７０のデータの動きベクトルの合計値を求め、この値を参照して、予め定めた基準値の何倍になるかで、動きの大きさの値を決定する。なお、このような基準値は、コンピュータ実験等により、予め定めておけば良い。
【０１６１】
一方、精細度の評価は、元データの整形を行なう際に、単位７０を構成するフレームデータにＤＣＴ変換したデータの高周波成分の大きさに基づいて行なう。
【０１６２】
即ち、例えば、単位７０のＩフレームの高周波成分値を、予め定めた基準値の何倍になるかで、精細度の値を決定する。なお、このような基準値は、コンピュータ実験等により、予め定めておけば良い。
【０１６３】
以上述べてきたサーバ１とクライアント２の間で、データ量の削減処理を行ないながら、ＭＰＥＧ１動画データを配信する、各タスクの処理内容について、以下説明する。
【０１６４】
まず、本発明にかかる第１の実施例における、メディアサーバ１の配信スケジューラタスク４００ａの処理内容について説明する。
【０１６５】
図１１は、配信スケジューラタスク４００ａの処理内容を示すフローチャートである。
【０１６６】
配信スケジューラタスク４００ａは、ユーザが、メディアサーバ１の入力装置１０５からの起動指示入力や、ＬＡＮ３やＩＳＤＮ４を介した、クライアント２からの起動要求メッセージデータを、マルチタスクＯＳ２００ａが受け取ったときに、マルチタスクＯＳ２００ａによって起動される。
【０１６７】
まず、ステップ４０１において、サービス品質管理タスク６００ａを起動し、次に、ステップ４０２において、ＬＡＮ３やＩＳＤＮ４を介したクライアント２からのマルチメディアデータ配信要求や、サービス内容の変更要求のメッセージデータ、ユーザのメディアサーバ１の入力装置１０５からの指示入力等を受け付ける。
【０１６８】
次に、ステップ４０３では、前記メッセージおよび指示入力等の内容を判定し、ユーザからの新たなマルチメディアデータの配信要求であれば（新規）、ステップ４１１に進み、また、画質等のサービス品質の変更、動画の場合の早送り再生開始、ポーズ等、サービス内容の変更要求であれば（変更）、ステップ４２１に進み、さらに、終了指示入力であれば、ステップ４３１に進む。
【０１６９】
なお、新規な配信要求および変更要求を伝えるメッセージデータの内容は、配信、変更の対象となるマルチメディアデータの識別名称と要求品質とからなり、これらは、ＬＡＮ３やＩＳＤＮ４を介してクライアント２からメディアサーバのマルチタスクＯＳ２００ａに渡され、さらに、マルチタスクＯＳ２００ａによって、配信スケジューラタスク４００ａに渡される。
【０１７０】
次に、ステップ４１１では、サービス品質管理タスク６００ａに、ユーザの指定通りの要求品質での新規配信が可能か否かを問い合わせ、配信可能であれば、ステップ４１３に進み、配信不可能であればステップ４１４に進む（ステップ４１２）。
【０１７１】
次に、ステップ４１３では、新たなユーザ配信処理タスク５００ａと配信条件テーブル２０００との生成を、マルチタスクＯＳ２００ａに要求し、メモリ１０２の容量不足や予め設定された総タスク数を超えるなどの要因により、タスク５００ａあるいはテーブル２０００のいずれかの生成が不可能な場合には、（ステップ４１５）ステップ４１４に進み、一方、可能な場合にはステップ４０２に進む。また、ステップ４１４では、配信要求のあったクライアント２に、メディアサーバ１が配信不可能である旨のメッセージを送信し、ステップ４０２に進む。
【０１７２】
また、ステップ４２１では、サービス品質管理タスク６００ａに、ユーザの指定通りのサービス内容の変更が可能であるか否かを問い合わせ、変更対象のユーザ配信処理タスク５００ａが既に消滅しているとか、メディアサーバ１のサービス能力の限度を超える等の要因により、タスク５００ａへの通知が不可能な場合は、ステップ４２３に進み、一方、可能な場合には、ステップ４０２に進む。
【０１７３】
そして、ステップ４２３では、変更要求のあったクライアント２に、メディアサーバ１が、サービス内容の変更が不可能である旨のメッセージを送信し、ステップ４０２に進む。
【０１７４】
最後に、ステップ４３１では、サービス品質管理タスク６００ａおよび配信スケジューラ４００ａが生成した全てのユーザ配信処理タスク５００ａに、配信処理の終了を指示するメッセージを与えた後、配信スケジューラタスク４００ａが使用しているハードウェア資源等を開放することにより、配信スケジューラタスク４００ａが行なう処理を終了する。
【０１７５】
次に、本発明にかかる第１の実施例における、メディアサーバ１のユーザ配信処理タスク５００ａが行なう処理内容について説明する。
【０１７６】
図１２は、ユーザ配信処理タスク５００ａの処理内容を示すフローチャートである。
【０１７７】
ユーザ配信処理タスク５００ａは、配信スケジューラタスク４００ａにより、タスクとして生成され、マルチタスクＯＳ２００ａにより起動される。該タスク５００ａは、メディアサーバ１のマルチメディアデータの配信件数分だけ生成され、マルチタスクＯＳ２００ａによって、適宜切り替えられながら動作し、見かけ上、同時に複数のクライアント２に対する、マルチメディアデータの配信を行なっている。
【０１７８】
まず、ステップ５０１では、配信対象のデータに対応するＩＮＤＥＸデータ２０３０を、主メモリ（ＲＡＭ）１０２上にロードする。ステップ５０２では、配信対象となるデータ３０００を、マルチタスクＯＳ２００ａや各タスクが、読み出し可能な状態にする。通常、マルチタスクＯＳ２００ａは、記憶装置１０６等に記憶しているデータのアクセスを管理するため、ファイルといった概念で管理するが、ステップ５０２では、データ３０００のファイルをオープンする。
【０１７９】
次に、ステップ５１１では、配信条件テーブル２０００ａの品質２００２を参照して、データ量削減パラメータを読みだす。ステップ５１２では、配信対象のデータ３０００のＩＮＤＥＸデータ２０３０の２０３２を参照して、配信するデータ単位７０の読み出し開始位置までシークする。
【０１８０】
ステップ５１３では、読み出し開始位置からＩＮＤＥＸデータ２０３０の２０３３を参照して、配信するデータ単位７０を読み出す。ステップ５１４では、データ単位７０を、ステップ５１１で読み出したデータ量削減パラメータに従って、データ量の削減を行なう。ここで、ネットワークや回線の伝送能力に余裕があり、メディアサーバ１のサービス能力に余裕がある場合には、データ量の削減を必ずしも行なう必要がなく、そのようなときには、ステップ５１４では、何の処理も行なわない。ステップ５１５では、データ量の削減処理を行なった削減データを、単位７０毎に、クライアント２に転送する。
【０１８１】
そして、ステップ５２１では、ステップ５１４で送信したデータがファイルの終わり（ＥＯＦ）であるか否かを判定し、終わりでない場合には、ステップ５２２に進み、終わりならば、ステップ５３１に進む。ステップ５２２では、配信スケジューラタスク４００ａからの、配信処理の終了を伝えるメッセージの有無を検知し、終了要求があれば、ステップ５３１に進み、一方、終了要求がなければ、ステップ５１１に進む。
【０１８２】
次に、ステップ５３１では、ステップ５０２でオープンしたファイルをクローズし、ステップ５３２では、サービス品質管理タスク６００ａに配信の終了を通知し、タスク５００ａが使用した主メモリ１０２上のメモリ空間等のリソースの開放を行なった後、マルチタスクＯＳ２００ａにタスク５００ａの終了を、自ら要求し、タスク５００ａの処理を終了する。なお、ステップ５１１で、配信条件テーブル２０００を参照する際、変更フラグ２００４が「変更あり」を示している場合には、これを「変更なし」の状態に設定する処理を行なう。また、このフラグ２００４が「変更なし」であれば、新たにデータ量削減パラメータを読み出す必要はない。
【０１８３】
次に、本発明にかかる第１の実施例におけるメディアサーバ１のサービス品質管理タスク６００ａの処理内容について説明する。
【０１８４】
図１３は、サービス品質管理タスク６００の処理内容を示すフローチャートである。
【０１８５】
サービス品質管理タスク６００ａは、配信スケジューラタスク４００ａにより、タスクとして生成され、マルチタスクＯＳ２００ａにより起動される。
【０１８６】
まず、ステップ６０１では、配信管理テーブル２０１０を初期化し、ステップ６１１では、配信スケジューラタスク４００ａからのメッセージを待ち、メッセージを受信したらその内容を解釈し、メッセージの内容が、「新規配信開始」であれば、ステップ６２１に進み、「配信条件変更」であれば、ステップ６３１に進み、配信中のユーザ配信処理タスク５００ａの処理の終了（配信終了）であれば、ステップ６４１に進み、メディアサーバ１の配信スケジューラ自体の終了によるタスク終了処理要求（タスク処理終了）であれば、ステップ６５１に進む。
【０１８７】
ステップ６２１では、配信管理テーブル２０１０のネットワーク別転送レート合計２０２０、および、サービス転送レート合計２０２５を参照し、新規に配信するデータの転送レート２０３１と、予め設定されたネットワークセグメントやバス１１７の伝送帯域（２０２２、２０２６）とを比較して、データ量を削減せずに、あるいは、データ量を削減して新規に配信可能なら、ステップ６２４に進み、また、データ量を削減しても、新規に配信が不可能なら、ステップ６２３に進む（ステップ６２２）。この場合、タスク４００ａから渡されたユーザの配信画質への要求品質と、サービス可能な転送レートを同時に満たすデータ量の削減が可能であるか否かを、動画データの元の転送レート２０３１とデータ量削減のための、図２のテーブル１０を参照し、該テーブル１０に条件を満たすデータ量削減パラメータが無い場合は、配信不可能とする。ステップ６２４では、配信管理テーブルに、新規の配信要求に対応したレコード２０１１を追加し、ステップ６２６では、配信スケジューラタスク４００ａに配信可能である旨と配信条件テーブルに設定するパラメータとを、メッセージにより伝え、ステップ６１１に進む。
【０１８８】
次に、ステップ６２３では、配信管理テーブルを参照し、既に配信を開始しているユーザ配信処理タスクに対応する配信条件を変更すれば、新規配信が可能であるか否かをを調べ、既に配信中のデータのうち、それ以上転送レートを下げられないものがある場合等、条件変更が不可能な場合には、ステップ６２７に進み、一方、条件変更が可能ならば、ステップ６２５に進む。
【０１８９】
また、ステップ６２３における配信条件を変更における、配信の可否の判定も、ステップ６２２と同様に、図２のテーブル１０を参照して行なう。なお、ステップ６２３では、配信管理テーブルの優先度２０１３の情報を用いて、優先度の高い配信処理については、条件を変更せず、優先度の低いものから条件を変更していくようにする。
【０１９０】
ステップ６２７では、配信スケジューラタスク４００ａに新規配信が不可能である旨をメッセージにより伝え、ステップ６１１に進む。ステップ６２５では、変更した配信条件を配信管理テーブル２０１０の各レコード２０１１に設定し、対応する配信条件テーブル２０００のデータを再設定し、変更フラグ２００４を「変更あり」に設定し、ステップ６２６を実行する。
【０１９１】
次に、ステップ６３１では、配信管理テーブル２０１０を参照し、変更の対象となっているレコード２０１１の内容の変更をすれば、既に配信中のデータのうち、それ以上転送レートを下げられないものがある場合等、条件変更が不可能な場合の有無を判定し、条件変更が可能な場合には、ステップ６３４に進み、条件変更が不可能な場合には、ステップ６３３に進む（ステップ６３２）。
【０１９２】
ステップ６３３における配信の可否の判定も、ステップ６２２と同様に、図２のテーブル１０を参照して行なう。
【０１９３】
なお、ステップ６３２では、配信管理テーブルの優先度２０１３の情報を参照して、優先度の高い配信処理については、条件を変更せず、優先度の低いものから条件を変更していくようにする。
【０１９４】
ステップ６３３では、配信スケジューラタスク４００ａに配信条件変更が不可能である旨をメッセージにより伝え、ステップ６１１に進む。ステップ６３４では、変更した配信条件を配信管理テーブル２０１０の各レコード２０１１に設定し、対応する配信条件テーブル２０００のデータを再設定し、変更フラグ２００４を「変更あり」に設定する。ステップ６３５では、配信スケジューラタスク４００ａに配信条件可能である旨を、メッセージにより返答し、ステップ６１１に進む。
【０１９５】
次に、ステップ６４１では、配信の終了したレコード２０１１を配信管理テーブル２０１０より削除し、必要なら、他のレコードの配信条件も変更する。
【０１９６】
最後に、ステップ６５１では、サービス品質管理タスク６００ａが使用した主メモリ１０２上のメモリ空間等のリソースの開放を行なった後、マルチタスクＯＳ２００ａにタスク６００ａの終了を自ら要求し、タスク６００ａの処理を終了する。
【０１９７】
なお、新規に配信を開始するクライアントが低速回線を介したＭＰＥＧ１データの配信要求であれば、図２のテーブル１０を参照して、例えば、ＩＳＤＮの６４ｋｂ／ｓ程度の転送レートであれば、セル１６に記述されたデータ量削減方法で、アナログ回線の１４．４ｋｂ／ｓ程度の転送レートであれば、セル１７に記述されたデータ量削減方法で削減処理したデータを転送すれば、クライアント２側において、該データを受信しながらデコードして表示すること（リアルタイム再生）も可能である。この場合、ＡＣ成分の上限数の制限や、フレーム数の削減は、伝送レートの調整のために採用する。
【０１９８】
次に、本発明にかかる第１の実施例におけるメディアサーバ１の配信データ整形タスク７００ａの処理内容について説明する。
【０１９９】
図１４は、配信データ整形タスク７００ａの処理内容を示すフローチャートである。
【０２００】
配信データ整形タスク７００ａは、ユーザが、メディアサーバにクライアント２で共用する動画データを登録するときに、ユーザの指示により、マルチタスクＯＳ２００ａが生成し、起動する。
【０２０１】
ステップ７０１では、ユーザから登録されたＭＰＥＧ１動画の元データ２９９９を読み込み、次に、ステップ７０２では、データ２９９９を音声だけのデータと動画だけのデータに分離し、ステップ７１１では、ステップ７０２で分離した動画データから１ＧＯＰごとに抜き出し、このＧＯＰの時間に対応するＡＡＵをステップ７１１で分離した音声だけのデータから抜き出し、それぞれをマージして、図９に示すデータ単位７０を作成する。この処理を全てのＧＯＰに対して繰返し、全てのデータ単位７０をマージして整形済み元データ３０００を作成して、ＩＮＤＥＸデータ２０３０に登録する。
【０２０２】
そして、ステップ７２１では、選択したセルに対応するデータ量削減パラメータを使用して、削除データの作成を行ない、タスク７００ａの処理を終了する。
【０２０３】
なお、ステップ７１１における動画と音声の時間的な対応付けは、動画のフレームレートと音声のサンプリング周波数より、各ＧＯＰおよびＡＡＵの再生開始時間を計算し、両者を照らし合わせることにより行なう。
【０２０４】
次に、本発明にかかる第１の実施例におけるクライアント２のメディア要求タスク部９００ａの処理内容について説明する。
【０２０５】
図１５は、メディア要求部９００の処理のフローチャートである。
【０２０６】
ステップ９０１では、ユーザから配信要求のあるデータのファイル名や、配信されたデータに利用方法の情報などを受け付ける。利用方法の情報とは、配信された動画データをブラウジングに使うか、あるいは、詳細に鑑賞する旨を示す情報である。また、かかる情報は、ユーザが入力しなくとも、ブラウジングを目的とするアプリケーションからの要求であれば、メディア要求タスク９００ａが自動的にブラウジング用と判断するような構成にしても良い。次に、ステップ９１１では、ユーザの用途から、動きの滑らかさか、あるいは、精細度のいずれを、どの程度要求するかといった、動画の画質に関する要求を評価し、そのデータを供給可能なメディアサーバ１を、ＬＡＮ３、ＩＳＤＮ４に接続されているメディアサーバのなかから検索し、要求を満たすメディアサーバ１を決定する。
【０２０７】
ステップ９２１では、ステップ９１１で決定したメディアサーバ１に配信を希望する動画データのファイル名と、画質の要求とをメッセージにより送信し、サーバからのデータの配信を待つ。そして、ステップ９３１では、メディアサーバ１からの返答を待ち、「配信可能」であれば、受信したデータをマルチメディアデータ再生タスク１０００ａにより表示し、再生が終了すれば、メディア要求タスク９００ａの処理を終了する。なお、メディアサーバからの返答が「配信不可能」であれば、時間を空けてリトライした後、更に「配信不可能」であれば処理を終了するようにしても良い。
【０２０８】
以上述べてきた、第１の実施例によれば、メディアサーバ１が記憶している、ある動画データをクライアント２に配信する際に、ユーザの画質への要求と、ネットワークや回線の伝送能力を含めたメディアサーバのサービス能力とを考慮して、データ量の削減を行ないながら、削減データを配信することが可能になる。
【０２０９】
また、データ量の削減制御も、時々刻々と変化するサービス能力に追随して、動画のＧＯＰや音声のＡＡＵの、切れ目に合わせて、データ量削減方式を切り換えることができ、クライアント側では、配信を受ける動画が乱れたり、音声がとぎれたりノイズが混入するといったことが無くなる。以上のことから、メディアサーバ１は、配信する動画データのデータ量を削減制御することによる、ネットワークや回線、サーバの処理能力を考慮したデータの提供が可能となり、クライアント２のユーザは、希望する品質を有するデータの配信を受けることが可能になる。
【０２１０】
なお、本実施例で述べたデータ量を削減しながらの配信は、予め配信データを図９に示すように整形しておくため、データ量削除制御の処理負荷を増加させることなく実現することが可能であり、複数クライアントの同時配信要求に対し、リアルタイムな配信処理が実現できる。
【０２１１】
また、転送するネットワークのトラヒックが飽和する可能性がある場合にも、配信する動画データの転送レートを抑えながらの配信が可能であり、メディアサーバが同時に動画データを配信できるクライアントの数を増加させることができる。この時、クライアントごとに優先度を設定することが可能であるため、優先度の低いクライアントから、転送する動画のデータ量を削除していくようにすることができ、ユーザが予め定めた優先度にしたがった、ユーザの要求を満足するデータ提供を実現できる。
【０２１２】
次に、本発明にかかる第２の実施例を説明する。
【０２１３】
本実施例は、サーバが、クライアントから配信要求されるデータのデータ量を、予め定めた規則に従って削減した、削減データを予め用意して格納しておき、適当な削減データを配信するという実施例である（なお、本実施例を、便宜上「ソフト型」と称する）。
【０２１４】
図１を参照して説明した、第１の実施例におけるメディアサーバのネットワーク環境の一例は、そのまま第２の実施例において用いることができる。
【０２１５】
次に、本発明の第１の実施例における、メディアサーバ１（１ａ、１ｂ）のマルチメディアデータのデータ量削減方法、削減データの配信方法の原理について説明したが、本実施例では、図２の各セルに対応する削減データを、サーバが予め備えた構成になっている。すなわち、削減データは、画素数、ＡＣ係数の上限値、フレーム数を含むデータ量削除パラメータを使用して、元データのデータ量を削除して作成する。そして、ある元データに対して、複数種類の削除データを予め生成し、サーバが格納している。
【０２１６】
さて、配信する削除データの選択は、図２のテーブル１０を参照して、次のように行う。なお、サーバは、各セルに対応した削除データを、予め作成し、記憶装置に格納しているものとする。
【０２１７】
まず、ユーザ（クライアント）からの配信要求が発生した場合、メディアサーバ１では、図２の１０を参照し、ユーザの要求と、配信（サービス）能力を考慮したデータ量となるように、配信時の初期削減データを選択し、選択した削減データの配信を行なう。ここで、配信（サービス）能力とは、例えば、サーバに接続されている各通信媒体の、通信許容伝送レート等が考えられる。ユーザの要求のみならず、サーバに接続されている各通信媒体の、通信許容伝送レートを越えないことを条件として、データ量の削減処理が行なわれる。
【０２１８】
これを仮に、セル１１に対応する削減データを採用するとし、配信の途中で、ユーザ要求が、更に動きの滑らかさを優先するように変更された場合には、（横軸上で右側に存在する）セル１２に対応する削除データに変更選択し、また、精細度を優先するように変更された場合は、（横軸上で左側に存在する）セル１３に対応する削除データに変更選択し、それぞれ変更選択された削除データを配信する。
【０２１９】
また、セル１１に対応する削除データの配信中に、メディアサーバ１のサービス能力が低下し、更にデータ量を削減する必要があるときには、（縦軸下方向に存在する）セル１５に対応する削除データに変更選択し、また、サービス能力が回復して、配信データ量を増加することが可能になれば、（縦軸上方向に存在する）セル１４に対応する削除データに変更選択して、変更選択した削除データを配信する。
【０２２０】
なお、図３を参照して説明した、ＭＰＥＧ１動画データのフォーマットは、第２の実施例でも同様である。動画データのデータ量の削減方式について再度説明することは避ける。
【０２２１】
第１の実施例では、図５を参照して説明したコンピュータ端末をそのまま使用することができる。
【０２２２】
ただし、クライアントおよびサーバが備える記憶装置には、第２実施例用のプログラムを格納しており、また、サーバ側には、元データに対応する、複数種類の削除データを、元データ種類ごとに記憶している。
【０２２３】
図１６は、本発明にかかる第２の実施例におけるメディアサーバ１及びそのクライアント２のソフトウェア構成を示す図、即ち、機能ブロック図である。
【０２２４】
まず、図１６（ａ）を参照して、メディアサーバ１のソフトウェア構成について説明する。
【０２２５】
第２の実施例における、タスク２００ｂ〜６００ｂは、第１の実施例における、タスク２００ａ〜６００ａと基本的には同じ機能を有するが、重複説明を避けずに説明することにする。
【０２２６】
２００ｂは、メディアサーバ１の基本システムソフトウェア、あるいは、オペーレティングシステム（以下「ＯＳ」と略記）と称されるソフトウェアであり、メディアサーバ１上で動作するソフトウェアへのＣＰＵ１０１の機能の割当て管理、図５を参照して説明した各ハードウェア装置資源の管理、メモリ１０２の論理的な使用単位での管理、ソフトウェアおよびハードウェアの処理実行のスケジューリング等を行うプログラムであり、いわゆるマルチタスク処理を行なう、マルチタスクＯＳである。マルチタスクＯＳ２００ｂは、通常、ＬＡＮ３やＩＳＤＮ４を介して、他の端末とデータ通信を行う際の通信手順の制御等を行うプロトコル処理部２１０ｂや、記憶装置１０６の動作制御や記憶装置１０６に格納するデータのファイル管理を行うファイルシステム２２０ｂを含んで構成される。
【０２２７】
３００ｂは、メディアサーバ１において動作するソフトウェアの実行単位で、メディアサーバ１において複数存在し、一般に、タスク（あるいはプロセス）と称されるものである。なお、以下に述べる４００ｂ〜７００ｂも、タスク（あるいはプロセス）であり、マルチタスクＯＳ２００ｂ側から見た扱い方は、３００ｂに対するのと同様である。複数存在するタスク３００ｂは、マルチタスクＯＳ２００ｂにより生成され、ユーザやマルチタスクＯＳ２００ｂによって、個々に指定された優先度に基づき、実行順序の決定や、ハードウェア資源へのアクセス等の調整が行なわれることにより、中断、実行待ち、終了等の実行状態になるように管理される。
【０２２８】
以下で述べるメディアサーバ１において、マルチタスクＯＳ２００ｂは、ＬＡＮ３からのデータの着信、ユーザの入力装置１０５等を介した入力、記憶装置１０６の処理終了等の、イベントに伴うＣＰＵ１０１への割込みに対し、即座に優先度に基づき、タスク３００ｂの実行順序の変更を行う、リアルタイム性を有したマルチタスクＯＳである。
【０２２９】
本実施例においては、特に、マルチタスクＯＳ２００ｂは、タスク間での情報（メッセージ）伝達の支援、ＬＡＮ３，ＩＳＤＮ４から送られてきたメッセージをプロトコル処理部２１０ｂによる処理を介してタスクへ伝達する等の、異なるネットワークや回線に渡るタスク間通信支援機能を有し、また、マウス１０４、キーボード１０５等の入力装置を介してユーザが入力した入力内容を、必要に応じてタスクに伝達したり、タスクのデータ出力要求を受け付けて画像入出力制御装置１０８を制御し、ディスプレー１１０に、要求に適合したデータを表示する等の、入出力制御機能も有している。
【０２３０】
４００ｂは、クライアント２からのマルチメディアデータ配信要求を受け付け、ユーザ配信処理タスク５００ｂに配信要求を発したクライアント２への、データの配信処理を依頼する、配信スケジューラタスクである。また、ユーザ配信処理タスク５００ｂは、マルチタスクＯＳ２００ｂにより、ユーザからの配信要求の件数分だけ生成されるが、一般にＯＳが扱うことが可能なタスク数は、ハードウェアの仕様等によって制限されており、そのような制限数を超える場合には、配信を行わない。また、配信スケジューラタスク４００ｂの具体的な処理内容については後述する。
【０２３１】
５００ｂは、要求を発したクライアントに対して、マルチメディアデータの配信を行うユーザ配信処理タスクであり、該タスクは、ユーザの指定したサービス品質と、メディアサーバ１の処理負荷やＬＡＮ３、ＩＳＤＮ４の伝送能力を考慮して、サービスするデータの品質を制御する、すなわち、配信対象とする削除データを選択し、選択した削除データを配信する。
【０２３２】
該制御は、例えば、ユーザの品質要求があるレベル以上であるときや、メディアサーバのサービス能力が高くないときに（配信データに対して、通信媒体の伝送能力が小さなとき）、配信するオリジナルのマルチメディアデータのデータ量を削減して配信することにより実現する。ユーザの指定したサービス品質に関する情報（即ち、図２の１０において、セルの横軸方向の位置を定める情報）は、配信スケジューラタスク４００ｂにより、また、メディアサーバ１の処理負荷やＬＡＮ３、ＩＳＤＮ４の伝送能力等の、メディアサーバ１のサービス能力に関する情報は、サービス品質管理タスク６００ｂにより、それぞれ取得する。該タスク５００ｂによるデータ量制御の具体的な方法については、後述する。
【０２３３】
６００ｂは、メディアサーバ１の処理負荷やＬＡＮ３、ＩＳＤＮ４の通信品質等、メディアサーバ１のサービス能力に関する情報に基づき、配信のサービス品質の決定、および、ユーザ配信処理タスク５００ｂ等に、サービス品質の情報を提供するサービス品質管理タスクである。なお、公知となっているＯＳには、ＣＰＵ１０１の処理負荷を逐次、数値で評価して、各タスクに通知する機能を有するものがある。また、ＬＡＮ３に流れるデータパケットの流量を監視することにより、ＬＡＮ３中のデータの混雑の程度を数量的に評価し、各タスクに通知する機能を有するソフトウェアもある。また、サービスするマルチメディアデータの転送レートを、メディアサーバ１が、該データごとの情報として予め有し、メディアサーバ１が、クライアント２に配信中のデータの種類と、各転送レートの情報とを参照して、自ら配信能力を数量的に評価して、各タスクに通知する機能を有するように構成することも考えられる。このように、６００ｂが提供するサービス能力の情報は、メディアサーバ１が自ら検知するか、クライアント２からのデータ要求のような外部からの情報を用いて検知した、サービス能力を数量的に表現したものとし、特に、後者の検知方法の実現例については、後述する。また数量的に表現されたサービス能力値の伝達は、主メモリ１０２の上の特定の領域を情報伝達用に割当て、該領域を、タスク３００ｂ乃至７００ｂが共有することによって実現される。
【０２３４】
７００ｂは、第１の実施例と異なるソフトウエアであり、第２の実施例の主要部をなすタスクである。
【０２３５】
ユーザの品質要求があるレベル以上であるときや、メディアサーバのサービス能力が高くないとき（配信データに対して、通信媒体の伝送能力が小さなとき）に配信する削除データを、オリジナルのマルチメディアデータのデータ量を削減して生成する、削減データ生成タスクである。削減データは、１つのオリジナルマルチメディアデータに対し、図２の各セルに示すような、複数のデータ量削減方法を採用して、予め複数種類作成しておく。なおタスク７００ｂの具体的な処理内容については、後述する。
【０２３６】
なお、オリジナルのマルチメディアデータと、削減データのいずれを配信するかは、ユーザ配信処理タスク５００ｂが判定し決定する。該タスク５００ｂによるデータ量制御は、配信するデータを、オリジナルデータまたは削減データに切り替えることにより実現する。なお、該タスク５００ｂの処理内容については、後述する。
【０２３７】
次に、図１６（ｂ）を参照して、クライアント２のソフトウェア構成について説明する。
【０２３８】
８００ｂは、クライアント２のＯＳであり、機能的には、メディアサーバ１のＯＳ２００ｂと同様である。また、ＯＳ８００ｂは、マルチタスク２００ｂと同様に、通信制御等を行うプロトコル処理部８１０ｂや、ファイルシステム８２０ｂを有して構成される。
【０２３９】
９００ｂおよび１０００ｂは、ＯＳ８００ｂ上で動作するタスクである。
【０２４０】
９００ｂは、ユーザの指示により起動され、ユーザの必要とするマルチメディアデータの名称、および、配信時のサービス品質等の要求を取り込み、これらの情報をメディアサーバ１に、ＬＡＮ３やＩＳＤＮ４等を介して伝送し、また、配信されてきたデータを受信する、メディア要求処理タスクである。該タスク９００ｂの具体的な処理内容については、後述する。
【０２４１】
１０００ｂは、メディア要求タスク９００ｂが受信した動画、静止画、音声等を有するマルチメディアデータを再生する、マルチメディアデータ再生タスクである。該タスク１０００ｂは、メディア要求タスク９００ｂが、マルチメディアデータを全て受信終了してから、該データの再生を開始するようにしても良いし、全ての受信処理を完了する前に、受信したデータを逐次再生するようにしても良い。特に、動画等の再生では、時間的制約条件が課される場合があり、このような場合には、後者のような再生方法を採用すれば良い。また、該タスク１０００ｂが行なう処理は、画像コーディック１１５や音声コーディック１１６のような専用ハードウェアによって実行されても良いし、ＤＳＰ１２０によるマイクロプログラムの実行やＣＰＵ１０１による主メモリ１０２上のソフトウェアの実行によって、行なわれても良い。
【０２４２】
次に、本発明にかかる第２の実施例におけるメディアサーバ１の有する制御テーブルやデータ構造について説明する。
【０２４３】
メディアサーバ１では、図２のテーブル１０の各セルに対応する削減方法で作成した複数種類の削除データや元データ、図７に示す各制御テーブルを、主メモリ１０２上格納し、少なくとも、マルチタスクＯＳ２００ｂ、配信スケジューラ４００ｂ、ユーザ配信処理タスク５００ｂ、サービス品質管理タスク６００ｂ、および、削減データ生成タスク７００ｂが参照可能な、アドレス上に確保する。以下、図１７に示す各制御テーブルについて説明する。
【０２４４】
６０００は、配信するＭＰＥＧ１データの元データである。後に詳しく説明する削減データ生成タスク７００ｂでは、図２のテーブル１０を参照し、元データ６０００から、データ量を図２のテーブル１０の各セルに対応する削減方法にしたがって削減処理した削減データを複数個生成し（６０２０）、元データ６０００と削減データ６０２０の論理的な関係付けに関する情報と、削減データの転送レートを記述したＩＮＤＥＸデータ４０３０を生成する。
【０２４５】
当然のことながら、メディアサーバ１には、複数種類の元データ６０００が存在し、各元データごとに、さらに複数種類の削減データ６０２０が存在するため、ＩＮＤＥＸデータ６０３０も、元データ６０００と一意に対応して、複数存在する。なお、説明を容易化するため、削除データ６０２０としては、３種類の削除データ、６０２０ａ、６０２０ｂ、６０２０ｃのみを図示している。
【０２４６】
ＩＮＤＥＸデータ６０３０の内容については、後述する。
【０２４７】
４０００ａ、ｂは、配信条件テーブルであり、これは配信スケジューラタスク４００ｂにより、前述したユーザ配信処理タスク５００ｂ（図１７の５００ｅ、５００ｆ）と一意的に対応付けられて生成される、ユーザへの配信条件に関する情報を記述したテーブルである。ユーザ配信処理タスク５００ｂと同様に、配信条件テーブル４０００も、配信件数分だけ存在し、１つのテーブル４０００には、少なくとも、ファイル名４００１、（サービス）品質（データ名）４００２、および、（配信条件）変更フラグ４００４の各データの内容が記述されている。
【０２４８】
該テーブル４０００は、配信スケジューラタスク４００ｂにより生成された後は、必要に応じてサービス品質管理タスク６００ｂにより、その内容が変更される。
【０２４９】
ファイル名４００１は、配信する元データ６０００を指定するための識別子である。
【０２５０】
品質２００２は、ユーザに提供する動画の品質に関するデータであるが、本実施例の場合は、データ群６０１０のうち、実際に配信するデータ、即ち、６０００か、６０２０ａ、ｂ、ｃのいずれかを指定するためのデータ識別子である。
【０２５１】
変更フラグ４００４が示すフラグは、該テーブル４０００が、配信スケジューラタスク４００ｂにより新規に生成されたとき、および、サービス品質管理タスク６００ｂによりその内容が変更されたときに、「変更あり」を示すように設定される。また、該フラグ４００４は、ユーザ配信処理タスク５００ｂが、６００４を参照したときに、「変更なし」を示すように設定される。
【０２５２】
４０１０は、メディアサーバ１がユーザへのサービス能力を管理するためのデータを保持する配信管理テーブルである。該テーブル４０１０は、メディアの配信要求ごとに、少なくとも、要求したクライアントのクライアントＩＤ４０１２、配信の優先度４０１３、メディア種別４０１４、メディアの転送レート４０１５、配信処理の状態４０１６等の情報を保持する配信状況レコード４０１１（図１７では、３つのクライアント毎に、４０１１ａ、４０１１ｂ、４０１１ｃとしている）を情報として持っている。
【０２５３】
さらに、４０１０は、メディアサーバ１が接続している通信媒体ごとに、転送中のデータの転送レートの最新の合計値を常に保持する、ネットワーク別転送レート合計レコード４０２０、および、メディアサーバ１が転送中のデータの転送レートの最新の合計値を常に保持する、サービス転送レート合計レコード４０２５を、情報として持っている。
【０２５４】
配信状況レコード４０１１は、ユーザからの配信要求があったときに、配信が可能であれば追加され、ユーザ配信処理タスク５００ｂに一意に対応して存在する。さらに、レコード４０１１中の各情報の設定方法等について説明する。
【０２５５】
クライアントＩＤ４０１２は、ネットワーク上でのクライアントの論理アドレス（例えばＩＰアドレス等）を使用することも可能である。優先度４０１３は、メディアサーバ１における各配信処理の優先度を数値で表したものであり、クライアント２が、配信要求時に指定するのが一般的であるが、メディアサーバ１が、予めクライアントＩＤ毎に定めておいた優先度を使用するようにしてもよい。
【０２５６】
メディア種別４０１４は、動画、静止画と言った、配信中のメディアの種類の識別子であり、本実施例においては、前記配信データ群６０１０のうち、元データ６０００や削減データ６０２０の、データ識別子を用いることが可能である。
【０２５７】
なお、図示しているように、本配信管理テーブル４０１０は、ある特定の動画１に対するテーブルである。即ち、説明のために、元データ６０００の種類を、「動画１」のみとして図示している。
【０２５８】
転送レート４０１５は、配信するデータ毎の転送レート値であり、このデータは、後述するＩＮＤＥＸデータ４０３０中のデータと同一のものである。
【０２５９】
状態４０１６は、最新のデータの配信状態を表す、「転送中」、「待ち」等の情報が記憶される。４０１２〜４０１６は、配信開始時に、サービス品質管理タスク６００ｂによって、新規にレコード４０１１が追加される時点で設定され、以後、ユーザの新たな配信要求の追加や配信条件の変更に伴って、４０１２〜４０１６の内容は、追加、変更される。なお、かかる変更処理の内容については、後に、サービス品質管理タスク６００ｂの処理の説明部分において述べる。
【０２６０】
ネットワーク別転送レート合計レコード４０２０は、ユーザからの新規配信要求の追加時や配信要求の変更時に、サービス品質管理タスク６００ｂにより更新される情報であり、該タスク６００ｂは、複数のＬＡＮ３やＩＳＤＮ（ＷＡＮ）４のような、サーバ１に接続される通信媒体（以後「ネットワークセグメント」と称す）ごとに、配信処理中のデータの転送レートの合計を計算した値を設定する。この時、該タスク６００ｂは、転送状態４０１６を参照して、転送中のレコード４０１１を見つけ出し、クライアントＩＤ４０１２を手がかりに、ネットワークセグメントを特定し、ネットワークセグメント毎に転送レート４０１５を合計する。全てのネットワークセグメント毎に転送レートを計算し、ネットワークセグメント、計算値のそれぞれを、レコード４０２０の中のデータ４０２１、４０２３として設定する。
【０２６１】
なお、ネットワークセグメント毎に使用可能な転送レート（伝送帯域）を、予め定めておき、このデータを、新規に配信を開始するか否かを決定する場合に使用する。即ち、この値を越えるような配信を行なうことは許容されない。
【０２６２】
サービス転送レート合計レコード４０２５は、ユーザからの新規配信要求の追加時や配信要求の変更時に、サービス品質管理タスク６００ｂにより更新される情報で、該タスク６００ｂは、メディアサーバ１が配信処理中のデータの転送レートの合計を計算して、４０２７に設定する。この時、該タスク６００ｂは、状態４０１６を参照して、転送中のレコード４０１１を見つけ出し、該レコードについての転送レート４０１５を合計する。該レコード４０２５には、メディアサーバ１が備えるバス１１７が、データ配信可能な転送レートの上限値（前記伝送帯域）を予め決めておき、この値を参照して、新規にデータ配信を開始するか否かを決定する場合に使用する。
【０２６３】
すなわち、サーバが扱うことが可能なマルチメディアデータに対する転送レートの合計の上限値（４０２７）を定めており、転送レート４０２７が、この上限値を越えるような場合には、越えないように、削除データを選択して、選択した削除データが配信される。
【０２６４】
次にＩＮＤＥＸデータ２０３０について、説明する。本実施例においては、配信対象の動画データ毎に、複数種類の削除データを予め作成しておき、メディアサーバ１に備えておき、ユーザが与えるユーザ要求と、伝送能力で定まるサービス要求を考慮した、削除データを選択し、転送レートを削減しながらデータを配信し、配信中に配信条件が変更されたときには、その変更された配信条件に最も近い（例えば、現在のセル位置を基準とした時、特定方向に隣接するセルで示される削減方式を使用して作成された削減データ）削減データに切り替えて配信する。この時、実際のＭＰＥＧ１データの構成を考慮したときの問題点が存在することは、図８を参照して、第１の実施例にて説明した通りであり、この対処方法も、図９を参照して、第１の実施例にて説明したものと同一あるため、ここでは重複説明を省略する。
【０２６５】
図１８には、図９にて説明した手順で整形した元データ６０００と削減データ６０２０のＧＯＰとＡＡＵをまとめた単位（７０５、７１０、７２０）の対応付けを示す。配信する動画のデータ量の制御を実現するには、この７０５、７１０、および７２０の切れ目で切り替える。すなわち、１つの「ＧＯＰ＋ＡＡＵ」を単位として、順次切り換えていく。
【０２６６】
従って、図に示すように、配信条件が変化する毎に、異なる種類のデータに対する単位で切り換えていく場合（例えば「▲１▼、▲２▼、▲３▼、▲４▼…」）、配信条件が変化しない場合には、同一のデータに属する単位で切り換えていく場合（例えば「▲１▼、▲６▼、▲７▼…」）等の各種の態様が考えられる。
【０２６７】
さらに、同一のデータに属する単位で切り換えていく場合において、途中で配信対象となるデータの種類の変更を余儀なくされるときに、所定時間経過した後に、再度、前記同一のデータに属する先頭単位に戻って、単位ごとに切り換えていく方法も考えられる。
【０２６８】
そのため、前述のＩＮＤＥＸデータ４０３０には、データ名称４０３１として、元データ６０００および削減データ６０２０のデータ識別子と、それぞれの転送レート４０３２および単位７００（７１０、７２０）毎の、データの先頭からのサイズ（Ａ１乃至Ａ５）と、単位のサイズ（ａ１乃至ａ５）（以上４０３３）を、各データごとに記述する。配信するデータを切り換える場合には、常に、データ４０３０を参照し、切り替わった時点で、先頭からのサイズを呼んでシークし、単位のサイズ文だけのデータを読んで、クライアント２に送信すれば、クライアント２から見れば、配信データのデータ量が制御されて着信したことになる。
【０２６９】
以上述べてきたソフトウェア、ハードウェア構成を有するメディアサーバ１とクライアント２の間で、データ量を制御をしながら、ＭＰＥＧ１動画データを配信する、各タスクの処理内容について以下述べる。
【０２７０】
次に、本発明にかかる第２の実施例におけるメディアサーバ１の配信スケジューラの処理内容について説明するが、これは基本的には、図１１を参照して説明した、第１の実施例の配信スケジューラと同様であるが、ステップ等に添字「ｂ」を付して、図１９を参照して再度説明する。
【０２７１】
図１９は、第２の実施例における配信スケジューラタスク４００ｂの処理内容を示すフローチャートである。
【０２７２】
配信スケジューラタスク４００ｂは、ユーザが、メディアサーバ１の入力装置１０５からの起動指示入力や、ＬＡＮ３やＩＳＤＮ４を介した、クライアント２からの起動要求メッセージデータを、マルチタスクＯＳ２００ｂが受け取ったときに、マルチタスクＯＳ２００ｂによって起動される。
【０２７３】
まず、ステップ４０１ｂにおいて、サービス品質管理タスク６００ｂを起動し、次に、ステップ４０２ｂにおいて、ＬＡＮ３やＩＳＤＮ４を介したクライアント２からのマルチメディアデータ配信要求や、サービス内容の変更要求のメッセージデータ、ユーザのメディアサーバ１の入力装置１０５からの指示入力等を受け付ける。
【０２７４】
次に、ステップ４０３ｂでは、前記メッセージおよび指示入力等の内容を判定し、ユーザからの新たなマルチメディアデータの配信要求であれば（新規）、ステップ４１１ｂに進み、また、画質等のサービス品質の変更、動画の場合の早送り再生開始、ポーズ等、サービス内容の変更要求であれば（変更）、ステップ４２１ｂに進み、さらに、終了指示入力であれば、ステップ４３１ｂに進む。
【０２７５】
なお、新規な配信要求および変更要求を伝えるメッセージデータの内容は、配信、変更の対象となるマルチメディアデータの識別名称と要求品質とからなり、これらは、ＬＡＮ３やＩＳＤＮ４を介してクライアント２からメディアサーバのマルチタスクＯＳ２００ｂに渡され、さらに、マルチタスクＯＳ２００ｂによって、配信スケジューラタスク４００ｂに渡される。
【０２７６】
次に、ステップ４１１ｂでは、サービス品質管理タスク６００ｂに、ユーザの指定通りの要求品質での新規配信が可能か否かを問い合わせ、配信可能であれば、ステップ４１３ｂに進み、配信不可能であればステップ４１４ｂに進む（ステップ４１２ｂ）。
【０２７７】
次に、ステップ４１３ｂでは、新たなユーザ配信処理タスク５００ｂと配信条件テーブル４０００との生成を、マルチタスクＯＳ２００ｂに要求し、メモリ１０２の容量不足や予め設定された総タスク数を超えるなどの要因により、タスク５００ｂあるいはテーブル４０００のいずれかの生成が不可能な場合には、（ステップ４１５ｂ）ステップ４１４ｂに進み、一方、可能な場合にはステップ４０２ｂに進む。また、ステップ４１４ｂでは、配信要求のあったクライアント２に、メディアサーバ１が配信不可能である旨のメッセージを送信し、ステップ４０２ｂに進む。
【０２７８】
また、ステップ４２１ｂでは、サービス品質管理タスク６００ｂに、ユーザの指定通りのサービス内容の変更が可能であるか否かを問い合わせ、変更対象のユーザ配信処理タスク５００ｂが既に消滅しているとか、メディアサーバ１のサービス能力の限度を超える等の要因により、タスク５００ｂへの通知が不可能な場合は、ステップ４２３ｂに進み、一方、可能な場合には、ステップ４０２ｂに進む。
【０２７９】
そして、ステップ４２３ｂでは、変更要求のあったクライアント２に、メディアサーバ１が、サービス内容の変更が不可能である旨のメッセージを送信し、ステップ４０２ｂに進む。
【０２８０】
最後に、ステップ４３１ｂでは、サービス品質管理タスク６００ｂおよび配信スケジューラ４００ｂが生成した全てのユーザ配信処理タスク５００ｂに、配信処理の終了を指示するメッセージを与えた後、配信スケジューラタスク４００ｂが使用しているハードウェア資源等を開放することにより、配信スケジューラタスク４００ｂが行なう処理を終了する。
【０２８１】
次に、本発明にかかる第２の実施例におけるメディアサーバ１のユーザ配信処理タスクの処理内容について説明するが、これは基本的には、図１２を参照して説明した、第１の実施例のユーザ配信処理タスクと同様であるが、ステップ等に添字「ｂ」を付して、図２０を参照して再度説明する。
【０２８２】
図２０に、本発明にかかる第２の実施例におけるメディアサーバ１のユーザ配信タスク５００ｂの処理内容について示す。
【０２８３】
ユーザ配信タスク５００ｂは、配信スケジューラタスク４００ｂにより、タスクとして生成され、マルチタスクＯＳ２００ｂにより起動される。該タスク５００ｂは、メディアサーバ１のマルチメディアデータの配信件数分だけ生成され、マルチタスクＯＳ２００ｂによって、適宜切り替えられながら動作し、見かけ上、同時に複数のクライアント２に対する、マルチメディアデータの配信を行なっている。
【０２８４】
まず、ステップ５０１ｂでは、配信対象のデータに対応するＩＮＤＥＸデータ４０３０を主メモリ（ＲＡＭ）１０２上にロードする。ステップ５０２ｂでは、配信対象となるデータ群６０１０のすべてのデータ６０００および６０２０を、マルチタスクＯＳ２００ｂや各タスクが、読み出し可能な状態にする。通常、マルチタスクＯＳ２００ｂは、記憶装置１０６等に記憶しているデータのアクセスを管理するため、ファイルといった概念で管理するが、ステップ５０２ｂでは、６０１０のデータを格納している、すべてのファイルをオープンする。
【０２８５】
次にステップ５１１ｂでは、配信条件テーブル４０００ａの品質４００２のデータ識別子を参照し、ステップ５１２ｂでは、そのファイルに対応するＩＮＤＥＸデータを検索し、ステップ５１３ｂでは、ＩＮＤＥＸデータの４０３３を参照して、配信するデータの読みだし開始位置までシークし、ステップ５１４ｂでは、配信するデータの１単位７０５をクライアント２に転送する。ステップ５２１ｂでは、ステップ５１４ｂで送信したデータがファイルの終わり（ＥＯＦ）であるかどうかを検知し、終わりでない場合は、ステップ５２２ｂに進み、一方、終わりならばステップ５３１ｂに進む。
【０２８６】
ステップ５２２ｂでは、配信スケジューラ４００ｂから配信処理の終了を伝えるメッセージの有無を検知し、終了要求があれば、ステップ５３１ｂに進み、一方、終了要求がなければステップ５１１ｂに進む。
【０２８７】
ステップ５３１ｂでは、ステップ５０２ｂでオープンしたファイルをすべてクローズし、ステップ５３２ｂでは、サービス品質管理タスク６００ｂに配信の終了を通知し、タスク５００ｂが使用した主メモリ１０２上のメモリ空間等のリソースの開放を行なった後、マルチタスクＯＳ２００ｂにタスク５００ｂの終了を自ら要求し、タスク５００ｂの処理を終了する。なお、ステップ５１１ｂで、配信条件テーブル２０００を参照する際、変更フラグ４００４が「変更あり」を示している場合には、これを「変更なし」の状態に設定する。また、フラグ４００４が「変更なし」であれば、配信対象ファイルを切り替える必要がなく、ステップ５１２ｂの処理は省略できる。
【０２８８】
次に、本発明にかかる第２の実施例におけるメディアサーバ１のサービス品質管理タスクの処理内容について説明するが、これは基本的には、図１３を参照して説明した、第１の実施例のサービス品質管理タスクと同様であるが、ステップ等に添字「ｂ」を付して、図２１を参照して再度説明する。
【０２８９】
図２１は、第２の実施例におけるサービス品質管理タスク６００ｂの処理内容を示すフローチャートである。
【０２９０】
サービス品質管理タスク６００ｂは、配信スケジューラタスク４００ｂにより、タスクとして生成され、マルチタスクＯＳ２００ｂにより起動される。
【０２９１】
まず、ステップ６０１ｂでは、配信管理テーブル４０１０を初期化し、ステップ６１１ｂでは、配信スケジューラタスク４００ｂからのメッセージを待ち、メッセージを受信したらその内容を解釈し、メッセージの内容が、「新規配信開始」であれば、ステップ６２１ｂに進み、「配信条件変更」であれば、ステップ６３１ｂに進み、配信中のユーザ配信処理タスク５００ｂの処理の終了（配信終了）であれば、ステップ６４１ｂに進み、メディアサーバ１の配信スケジューラ自体の終了によるタスク終了処理要求（タスク処理終了）であれば、ステップ６５１ｂに進む。
【０２９２】
ステップ６２１ｂでは、配信管理テーブル４０１０のネットワーク別転送レート合計４０２０、および、サービス転送レート合計４０２５を参照し、新規に配信するデータの転送レート４０３２と、予め設定されたネットワークセグメントやバス１１７の伝送帯域とを比較して、削除データ量を採用せずに、あるいは、選択した削除データを新規に配信可能なら、ステップ６２４ｂに進み、また、いずれの削除データ量を採用しても、新規に配信が不可能なら、ステップ６２３ｂに進む（ステップ６２２ｂ）。この場合、タスク４００ｂから渡されたユーザの配信画質への要求品質と、サービス可能な転送レートを同時に満たす削除データの選択が可能であるか否かを、動画データの元の転送レートと削除データの転送レート（４０３２）とを、ＩＮＤＥＸデータを参照して調べ、条件を満たす削除データが無い場合は、配信不可能とする。ステップ６２４ｂでは、配信管理テーブルに、新規の配信要求に対応したレコード４０１１を追加し、ステップ６２６ｂでは、配信スケジューラタスク４００ｂに配信可能である旨と配信条件テーブルに設定するパラメータとを、メッセージにより伝えステップ６１１ｂに進む。
【０２９３】
次に、ステップ６２３ｂでは、配信管理テーブルを参照し、既に配信を開始しているユーザ配信処理タスクに対応する配信条件を変更すれば、新規配信が可能であるか否かをを調べ、既に配信中のデータのうち、それ以上転送レートを下げられないものがある場合等、条件変更が不可能な場合には、ステップ６２７ｂに進み、一方、条件変更が可能ならば、ステップ６２５ｂに進む。
【０２９４】
また、ステップ６２３ｂにおける配信条件を変更における、配信の可否の判定も、ステップ６２２ｂと同様に、ＩＮＤＥＸテーブルを参照して行なう。なお、ステップ６２３ｂでは、配信管理テーブルの優先度４０１３の情報を用いて、優先度の高い配信処理については、条件を変更せず、優先度の低いものから条件を変更していくようにする。
【０２９５】
ステップ６２７ｂでは、配信スケジューラタスク４００ｂに新規配信が不可能である旨をメッセージにより伝え、ステップ６１１ｂに進む。ステップ６２５ｂでは、変更した配信条件を配信管理テーブル４０１０の各レコード４０１１に設定し、対応する配信条件テーブル４０００のデータを再設定し、変更フラグ４００４を「変更あり」に設定し、ステップ６２６ｂを実行する。
【０２９６】
次に、ステップ６３１ｂでは、配信管理テーブル４０１０を参照し、変更の対象となっているレコード４０１１の内容の変更をすれば、既に配信中のデータのうち、それ以上転送レートを下げられないものがある場合等、条件変更が不可能な場合の有無を判定し、条件変更が可能な場合には、ステップ６３４ｂに進み、条件変更が不可能な場合には、ステップ６３３ｂに進む（ステップ６３２ｂ）。
【０２９７】
ステップ６３３ｂにおける配信の可否の判定も、ステップ６２２ｂと同様に、ＩＮＤＥＸテーブルを参照して行なう。
【０２９８】
なお、ステップ６３２ｂでは、配信管理テーブルの優先度４０１３の情報を参照して、優先度の高い配信処理については、条件を変更せず、優先度の低いものから条件を変更していくようにする。
【０２９９】
ステップ６３３ｂでは、配信スケジューラタスク４００ｂに配信条件変更が不可能である旨をメッセージにより伝え、ステップ６１１ｂに進む。ステップ６３４ｂでは、変更した配信条件を配信管理テーブル４０１０の各レコード４０１１に設定し、対応する配信条件テーブル４０００のデータを再設定し、変更フラグ４００４を「変更あり」に設定する。ステップ６３５ｂでは、配信スケジューラタスク４００ｂに配信条件可能である旨を、メッセージにより返答し、ステップ６１１ｂに進む。
【０３００】
次に、ステップ６４１ｂでは、配信の終了したレコード４０１１を配信管理テーブル４０１０より削除し、必要なら、他のレコードの配信条件も変更する。
【０３０１】
最後に、ステップ６５１ｂでは、サービス品質管理タスク６００ｂが使用した主メモリ１０２上のメモリ空間等のリソースの開放を行なった後、マルチタスクＯＳ２００ｂにタスク６００ｂの終了を自ら要求し、タスク６００ｂの処理を終了する。
【０３０２】
なお、新規に配信を開始するクライアントが低速回線を介したＭＰＥＧ１データの配信要求であれば、例えば、通信媒体がＩＳＤＮであり、６４ｋｂ／ｓ程度の転送レートであれば、セル１６に記述されたデータ量削減方法で削除された削除データを送信するようにし、通信媒体がアナログ回線であり、１４．４ｋｂ／ｓ程度の転送レートであれば、セル１７に記述されたデータ量削減方法でで削除された削除データを送信するようにデータを転送すれば、クライアント２側において、データを受信しながらデコードして表示すること（リアルタイム再生）も可能である。
【０３０３】
次に、本発明にかかる第２の実施例におけるメディアサーバ１の削減データ生成タスク７００ｂの処理内容について説明する。
【０３０４】
図１４は、削減データ生成タスク７００ｂの処理内容を示すフローチャートである。
【０３０５】
削減データ生成タスク７００ｂは、ユーザが、メディアサーバにクライアント２で共用する動画データを登録するときに、ユーザが指示を与えることにより、マルチタスクＯＳ２００ｂが生成し、起動する。
【０３０６】
ステップ７０１ｂでは、ユーザから登録されたＭＰＥＧ１動画の元データ６０００を読み込み、ステップ７１１ｂでは、元データ６０００を図９で説明した形式に整形し、ＩＮＤＥＸデータ４０３０に登録する。そして、ステップ７２１ｂでは、元データ６０００より、図２のテーブル１０に示すセルで示される削減方法にしたがって、複数の削減データ６０２０を生成し、ＩＮＤＥＸデータ６０３０に登録する。
【０３０７】
次に、本発明にかかる第２の実施例におけるクライアント２のメディア要求タスク９００ｂの処理内容について説明する。
【０３０８】
図１５は、メディア要求部９００の処理のフローチャートである。
【０３０９】
ステップ９０１ｂでは、ユーザから配信要求のあるデータのファイル名や、配信されたデータに利用方法の情報等を受け付ける。ここで、利用方法の情報とは、配信された動画データをブラウジングに使うか、詳細に鑑賞するといった情報である。また、かかる情報は、ユーザが入力せずに、ブラウジングを目的とするアプリケーションからの要求であれば、メディア要求タスク９００ｂが自動的にブラウジング用と判断するようにしても良い。ステップ９１１ｂでは、ユーザの用途から、動きの滑らかさか、あるいは、精細度のいずれかを、どの程度要求するかといった、動画の画質に関する要求を評価し、そのデータを供給可能なメディアサーバ１を、ＬＡＮ３、ＩＳＤＮ４に接続されているメディアサーバの中から捜しだし、要求を満たすメディアサーバ１を決定する。
【０３１０】
ステップ９２１ｂでは、ステップ９１１ｂで決定したメディアサーバ１に、配信を希望する動画データのファイル名と、画質のユーザ要求とを、メッセージによって送信し、データの配信を待つ。次に、ステップ９３１ｂでは、メディアサーバ１からの返答を待ち、「配信可能」であれば、受信したデータをマルチメディアデータ再生タスク１０００ｂにより表示し、再生が終われば、本タスク９００ｂの処理を終了する。なお、メディアサーバからの返答が「配信不可能」であれば、時間をおいてリトライした後、さらに「配信不可能」であれば処理を終了するようにしても良い。
【０３１１】
以上述べてきた、第１、２の実施例によれば、メディアサーバ１が記憶している、ある動画データをクライアント２に配信する際に、ユーザの画質への要求と、ネットワークや回線の伝送能力を含めたメディアサーバのサービス能力とを考慮して、データ量の削減を行ないながら削減データを配信することが可能になる。
【０３１２】
また、データ量の削減制御も、時々刻々と変化するサービス能力に追随して、動画のＧＯＰや音声のＡＡＵの、切れ目に合わせて、データ量削減方式を切り換えることができ、クライアント側では、配信を受ける動画が乱れたり、音声がとぎれたりノイズが混入するといったことが無くなる。以上のことから、メディアサーバ１は、配信する動画データのデータ量を削減制御することによる、ネットワークや回線、サーバの処理能力を考慮したデータの提供が可能となり、クライアント２のユーザは、希望する品質を有するデータの配信を受けることが可能になる。
【０３１３】
なお、本実施例で述べたデータ量を削減しながらの配信は、予め配信データを図９に示すように整形しておくため、データ量削除制御の処理負荷を増加させることなく実現することが可能であり、複数クライアントの同時配信要求に対し、リアルタイムな配信処理が実現できる。
【０３１４】
また、転送するネットワークのトラヒックが飽和する可能性がある場合にも、配信する動画データの転送レートを抑えながらの配信が可能であり、メディアサーバが同時に動画データを配信できるクライアントの数を増加させることができる。この時、クライアントごとに優先度を設定することが可能であるため、優先度の低いクライアントから、転送する動画のデータ量を削除していくようにすることができ、ユーザが予め定めた優先度にしたがった、ユーザの要求を満足するデータ提供を実現できる。
【０３１５】
【発明の効果】
以上のように、本発明によれば、各種のコンピュータネットワーク環境において、動画等のマルチメディアデータをクライアントに配信する際に、ユーザの希望する品質や、メディアサーバの接続しているネットワークの伝送能力を考慮して、でー多量制御することが可能になる。したがって、公衆回線等の比較的転送レートの低い伝送媒体を介しての動画データの配信も効率良く行なえる。
【０３１６】
また、転送するネットワークのトラヒックが飽和する可能性がある場合にも、配信する動画データの転送レートを抑えながらの配信が可能であり、メディアサーバが、同時に動画データを配信可能なクライアント数を増加させることが可能になる。この時、クライアントごとに優先度を設定することが可能であるため、優先度の低いクライアントから、転送する動画のデータ量を低減するように制御することができ、ユーザは予め優先度を高くしておくことにより、画質の良いデータ配信を受け続けることも可能である。
【０３１７】
以上のことから、本発明によれば、各種のネットワーク環境において、メディアサーバ上にある動画等のマルチメディアデータを、クライアントに効率良く送信するこを可能にする。
【０３１８】
【図面の簡単な説明】
【図１】第１の実施例におけるネットワーク環境の説明図である。
【図２】第１の実施例におけるＭＰＥＧ１動画データ量の削減方法を示すテーブルの説明図である。
【図３】ＭＰＥＧ１動画データのフォーマットの説明図である。
【図４】第１の実施例におけるＭＰＥＧ１動画データ量削減方式の原理説明図である。
【図５】コンピュータ端末のハードウェアの構成図である。
【図６】第１の実施例におけるメディアサーバとクライアントのソフトウェアの構成図である。
【図７】第１の実施例におけるメディアサーバの制御テーブルの構成およびデータ関連を説明する説明図である。
【図８】ＭＰＥＧ１動画および音声データフォーマットと圧縮データパケットの関係の説明図である。
【図９】ＭＰＥＧ１データ整形方式の原理説明図である。
【図１０】第１の実施例におけるＩＮＤＥＸデータの説明図である。
【図１１】第１の実施例における配信スケジューラタスクの処理内容を示すフローチャートである。
【図１２】第１の実施例におけるユーザ配信処理タスクの処理内容を示すフローチャートである。
【図１３】第１の実施例におけるサービス品質管理タスクの処理内容を示すフローチャートである。
【図１４】第１の実施例における配信データ整形タスクの処理内容を示すフローチャートである。
【図１５】第１の実施例におけるクライアントのメディア要求タスクの処理内容を示すフローチャートである。
【図１６】第２の実施例におけるメディアサーバとクライアントのソフトウェアの構成図である。
【図１７】第２の実施例におけるメディアサーバの制御テーブルの構成およびデータ関連を説明する説明図である。
【図１８】第２の実施例におけるＩＮＤＥＸデータの説明図である。
【図１９】第２の実施例における配信スケジューラタスクの処理内容を示すフローチャートである。
【図２０】第２の実施例におけるユーザ配信処理タスクの処理内容を示すフローチャートである。
【図２１】第２の実施例におけるサービス品質管理タスクの処理内容を示すフローチャートである。
【図２２】第２の実施例における削除データ生成タスクの処理内容を示すフローチャートである。
【図２３】第２の実施例におけるクライアントのメディア要求タスクの処理内容を示すフローチャートである。
【符号の説明】
１…メディアサーバ、２…クライアント、４００…配信スケジューラタスク、５００…ユーザ配信処理タスク、６００…サービス品質管理タスク、７００ａ…配信データ整形タスク、７００ｂ…削除データ生成タスク
Claims (11)
- 動画データを配信するサーバと、該サーバと少なくとも 1 つの通信媒体を介して接続され、動画データの配信要求を行う少なくとも１以上のクライアントとを有して構成される情報処理システムであって、
前記サーバは、動画データを記憶するための記憶手段と、動画データの単位時間当たりのデータ量を、予め定められた複数のデータ量削減規則のうちのいずれかに従って、削減するデータ量削減手段と、
前記通信媒体を介して、前記データ量削減手段が削減処理を行った後の削減後データをクライアントに出力する出力手段と、
前記通信媒体を介して、前記記憶手段に記憶されている動画データへのアクセス命令を、受け付ける入力手段と、
入力されたアクセス命令に応じて、単位時間当たりのデータ量を削減するための制御を行なう制御手段と、
前記入力手段がアクセス命令を受け付けたとき、前記通信媒体毎に、当該アクセス命令に対する第１の削減後の単位時間当たりのデータ量を前記データ量削減規則にしたがって演算するとともに、前記通信媒体毎に、それまで受け付けたアクセス命令に応じて前記制御手段が制御した第２の単位時間当たりの削減後のデータ量を演算し、前記通信媒体毎に、前記第１の削減後の単位時間当たりのデータ量と前記第２の削減後の単位時間当たりのデータ量を加算して前記出力手段が当該通信媒体を介して出力する削減後の単位時間当たりのデータ量の総和を演算する伝送量演算手段と、
前記入力手段がアクセス命令を受け付けたとき、当該アクセス命令に対する第１の削減後の単位時間当たりのデータ量を前記データ量削減規則にしたがって演算するとともに、それまで受け付けたアクセス命令に応じて前記制御手段が制御した第２の単位時間当たりの削減後のデータ量を演算し、前記第１の削減後の単位時間当たりのデータ量と前記第２の削減後の単位時間当たりのデータ量を加算して前記出力手段が出力する削減後の単位時間当たりのデータ量の総和を演算する出力量演算手段とを有し
前記入力手段は、前記動画データのアクセス命令を受け付けるとともに、動画データ配信処理の優先度を受け付け、
前記制御手段は、前記優先度の小さいアクセス命令の順に、前記伝送量演算手段が演算した削減後の単位時間当たりのデータ量の総和が前記通信媒体毎にあらかじめ定められた最大伝送レートを超えない前記データ量削減規則であって、かつ、前記出力量演算手段が演算した削減後の単位時間当たりのデータ量の総和が、あらかじめ定められた前記サーバの最大伝送レートを超えない前記データ量削減規則のいずれかを選択し、
前記データ量削減手段を駆動し、削減処理された削減後データを、前記出力手段に与えること
を特徴とする情報処理システム。 - 請求項１記載の情報処理システムにおいて、前記データ量削減規則は、画素数、ＡＣ係数を含む空間的解像度およびフレーム数を含む時間的解像度の組み合わせで定まる解像度パラメータを用いたデータ削減である、ことを特徴とする情報処理システム。
- 動画データと、当該動画データの単位時間当たりのデータ量を予め定められた複数のデータ量削減規則に従って削減した後の複数種類の削減後データとを記憶するための記憶手段と、
前記記憶手段に記憶されている複数種類の削減後データのいずれかを、外部に出力する出力手段と、
前記記憶手段に記憶されている動画データへのアクセス命令を受け付ける入力手段と、
入力されたアクセス命令に応じて、前記記憶手段に記憶された複数種類の削減後データのいずれかを選択する制御手段と、を備え、
前記制御手段は、前記入力手段がアクセス命令を受け付けたとき、当該アクセス命令に対する第１の削減後の単位時間当たりのデータ量を前記データ量削減規則にしたがって演算するとともに、それまで受け付けたアクセス命令に応じて前記制御手段が選択した第２の単位時間当たりの削減後のデータ量を演算し、前記第１の削減後の単位時間当たりのデータ量と前記第２の削減後の単位時間当たりのデータ量を加算して前記出力手段が出力する削減後の単位時間当たりのデータ量の総和を演算し、
前記削減後の単位時間当りのデータ量の総和があらかじめ定められた最大伝送レートを超えない前記記憶手段に記憶された複数種類の削減後データのいずれかを選択して、当該選択された削減後データを、前記出力手段に与えること
を特徴とする情報処理システム。 - 動画データを配信するサーバと、当該サーバと少なくとも１つの通信媒体を介して接続され、動画データの配信要求を行う少なくとも１つのクライアントとを有して構成される情報処理システムであって、
前記サーバは、動画データと、当該動画データの単位時間当たりのデータ量を予め定められた複数のデータ量削減規則に従って削減した後の複数種類の削減後データとを記憶するための記憶手段と、
前記通信媒体を介して、前記記憶手段に記憶されている複数種類の削減後データのいずれかを、クライアントに出力する出力手段と、
前記通信媒体を介して、前記記憶手段に記憶されている動画データへのアクセス命令を、受け付ける入力手段と、
入力されたアクセス命令に応じて、前記記憶手段に記憶された複数種類の削減後データのいずれかを選択する制御手段と、
前記入力手段がアクセス命令を受け付けたとき、当該アクセス命令に対する第１の削減後の単位時間当たりのデータ量を前記データ量削減規則にしたがって演算するとともに、それまで受け付けたアクセス命令に応じて前記制御手段が選択した第２の単位時間当たりの削減後のデータ量を演算し、前記第１の削減後の単位時間当たりのデータ量と前記第２の削減後の単位時間当たりのデータ量を加算して前記出力手段が出力する削減後の単位時間当たりのデータ量の総和を演算する出力量演算手段と、を有し、
前記制御手段は、前記出力量演算手段が演算した削減後の単位時間当たりのデータ量の総和があらかじめ定められた前記サーバの最大伝送レートを超えない前記記憶手段に記憶された削減後データのいずれかを選択して、当該選択された削減後データを、前記出力手段に与えること
を特徴とする情報処理システム。 - 請求項４おいて、
前記入力手段がアクセス命令を受け付けたとき、前記通信媒体毎に、当該アクセス命令に対する第１の削減後の単位時間当たりのデータ量を前記データ量削減規則にしたがって演算するとともに、前記通信媒体毎に、それまで受け付けたアクセス命令に応じて前記制御手段が選択した第２の単位時間当たりの削減後のデータ量を演算し、前記通信媒体毎に、前記第１の削減後の単位時間当たりのデータ量と前記第２の削減後の単位時間当たりのデータ量を加算して前記出力手段が当該通信媒体を介して出力する削減後の単位時間当たりのデータ量の総和を演算する伝送量演算手段を、さらに有し、
前記入力手段は、前記動画データのアクセス命令を受け付けるとともに、動画データ配信処理の優先度を受け付け、
前記制御手段は、前記優先度の小さいアクセス命令の順に、前記出力量演算手段が演算した削減後の単位時間当たりのデータ量の総和が、あらかじめ定められた前記サーバの最大伝送レートを超えない前記記憶手段に記憶された削減後データであって、かつ、前記伝送量演算手段が演算した通信媒体毎の削減後の単位時間当たりのデータ量の総和が、前記通信媒体毎にあらかじめ定められた最大伝送レートを超えない前記記憶手段に記憶された削減後データのいずれかを選択して、当該選択された削減後データを、前記出力手段に与えること
を特徴とする情報処理システム。 - 請求項３、４および５のいずれかにおいて、前記削減後データは、画素数、ＡＣ係数を含む空間的解像度およびフレーム数を含む時間的解像度のうち少なくとも一方の解像度の変更によって、前記動画データの単位時間当たりのデータ量を削減したデータである、ことを特徴とする情報処理システム。
- 請求項４において、
前記入力手段がアクセス命令を受け付けたとき、前記通信媒体毎に、当該アクセス命令に対する第１の削減後の単位時間当たりのデータ量を前記データ量削減規則にしたがって演算するとともに、前記通信媒体毎に、それまで受け付けたアクセス命令に応じて前記制御手段が選択した第２の単位時間当たりの削減後のデータ量を演算し、前記通信媒体毎に、前記第１の削減後の単位時間当たりのデータ量と前記第２の削減後の単位時間当たりのデータ量を加算して前記出力手段が当該通信媒体を介して出力する削減後の単位時間当たりのデータ量の総和を演算する伝送量演算手段を、さらに有し、
前記制御手段は、前記動画データの所定の単位毎に、前記出力量演算手段が演算した削減後の単位時間当たりのデータ量の総和が、あらかじめ定められた前記サーバの最大伝送レートを超えない前記記憶手段に記憶された削減後データであって、かつ、前記伝送量演算手段が演算した通信媒体毎の削減後の単位時間当たりのデータ量の総和が、前記通信媒体毎にあらかじめ定められた最大伝送レートを超えない前記記憶手段に記憶された削減後データのいずれかを選択して、当該選択された削減後データを、前記出力手段に与えること
を特徴とする情報処理システム。 - 請求項４、５、６および７のいずれかにおいて、
前記通信媒体を、伝送速度６４（ｋｂｉｔ／秒）のＩＳＤＮ回線で構成し、
前記記憶手段には、画素数を、縦１２０画素、横１７６画素とする削減後データを予め記憶しておき、
前記制御手段は、画素数を、縦１２０画素、横１７６画素とする削減後データを前記出力手段に与える機能を有することを特徴とする情報処理システム。 - 請求項４、５、６および７のいずれかにおいて、
前記通信媒体を、伝送速度１４．４（ｋｂｉｔ／秒）のアナログ回線で構成し、前記記憶手段には、画素数を、縦６０画素、横８８画素とする削減後データを予め記憶しておき、
前記制御手段は、画素数を、縦６０画素、横８８画素とする削減後データを前記出力手段に与える機能を有することを特徴とする情報処理システム。 - 請求項１または２において、
前記サーバの入力手段は、前記クライアントが備える命令送出手段を介して与えた、ブラウジングを要求する命令であるブラウジング命令を受け付ける機能を有し、
前記制御手段は、前記入力手段がブラウジング命令を受け付けたとき、該命令に対して予め定めているデータ量削減規則を選択して、前記データ量削減手段を駆動し、削減後データを前記出力手段に与える機能を有することを特徴とする情報処理システム。 - 請求項４、５、６および７のいずれかにおいて、
前記サーバの入力手段は、前記クライアントが備える命令送出手段を介して与えた、ブラウジングを要求する命令であるブラウジング命令を受け付ける機能を有し、
前記制御手段は、前記入力手段がブラウジング命令を受け付けたとき、該命令に対して予め定められた前記記憶手段に記憶された削減後データを選択し、当該選択された削減後データを前記出力手段に与える機能を有することを特徴とする情報処理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11867295A JP3609488B2 (ja) | 1995-05-17 | 1995-05-17 | 情報処理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP11867295A JP3609488B2 (ja) | 1995-05-17 | 1995-05-17 | 情報処理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH08317384A JPH08317384A (ja) | 1996-11-29 |
| JP3609488B2 true JP3609488B2 (ja) | 2005-01-12 |
Family
ID=14742361
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP11867295A Expired - Fee Related JP3609488B2 (ja) | 1995-05-17 | 1995-05-17 | 情報処理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3609488B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7853118B2 (en) | 2005-08-31 | 2010-12-14 | Kabushiki Kaisha Toshiba | Image replay apparatus and method for moving-picture streams |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3628469B2 (ja) * | 1997-03-17 | 2005-03-09 | 三菱電機株式会社 | ビデオサーバシステム |
| US6735253B1 (en) | 1997-05-16 | 2004-05-11 | The Trustees Of Columbia University In The City Of New York | Methods and architecture for indexing and editing compressed video over the world wide web |
| JPH114252A (ja) * | 1997-06-11 | 1999-01-06 | Mitsubishi Electric Corp | データ伝送システム |
| US6407998B1 (en) * | 1997-10-02 | 2002-06-18 | Thomson Licensing S.A. | Multimedia decoder for prioritized bi-directional communication in a broadcast system |
| US6134243A (en) * | 1998-01-15 | 2000-10-17 | Apple Computer, Inc. | Method and apparatus for media data transmission |
| JP3999410B2 (ja) * | 1999-06-16 | 2007-10-31 | 株式会社東芝 | ビデオサーバおよびビデオオンデマンドシステム |
| JP2001025013A (ja) * | 1999-07-12 | 2001-01-26 | Matsushita Electric Ind Co Ltd | 送受信方法及びその装置 |
| JP2001169293A (ja) | 1999-12-08 | 2001-06-22 | Nec Corp | 画像伝送装置 |
| JP2001243043A (ja) | 2000-02-29 | 2001-09-07 | Sony Corp | ユーザインタフェースシステム、シーン記述生成装置及び方法、シーン記述変換装置及び方法、記録媒体並びに伝送媒体 |
| JP2002094994A (ja) | 2000-09-19 | 2002-03-29 | Nec Corp | 動画再生処理装置および動画再生処理方法 |
| JP4892541B2 (ja) * | 2002-02-18 | 2012-03-07 | 株式会社日立国際電気 | 画像伝送方法および画像伝送システム |
| EP1532812A4 (en) | 2002-04-26 | 2007-10-10 | Univ Columbia | OPTIMAL VIDEO TRANSCODING METHOD AND SYSTEM BASED ON UTILITY PROGRAM FUNCTION DESCRIPTERS |
| ATE345534T1 (de) | 2002-09-04 | 2006-12-15 | Oce Tech Bv | Verfahren und vorrichtung zur physikalischen verwaltung eines dokuments |
| US7558323B2 (en) | 2002-11-27 | 2009-07-07 | Hitachi Kokusai Electric Inc. | Video data transmission method for changing transmission data amounts in accordance with a transmission speed and a transmission system therefor |
| US8219702B2 (en) | 2004-04-30 | 2012-07-10 | Canon Kabushiki Kaisha | Video delivery apparatus and method |
| JP2006092052A (ja) * | 2004-09-22 | 2006-04-06 | Nec Corp | メール配信システム、メールサーバ及びそれらに用いるメール送受信方法並びにそのプログラム |
| WO2006096612A2 (en) | 2005-03-04 | 2006-09-14 | The Trustees Of Columbia University In The City Of New York | System and method for motion estimation and mode decision for low-complexity h.264 decoder |
| US8477840B2 (en) | 2005-09-29 | 2013-07-02 | Thomson Research Funding Corporation | Method and apparatus for constrained variable bit rate (VBR) video encoding |
| WO2009126785A2 (en) | 2008-04-10 | 2009-10-15 | The Trustees Of Columbia University In The City Of New York | Systems and methods for image archaeology |
| US8671069B2 (en) | 2008-12-22 | 2014-03-11 | The Trustees Of Columbia University, In The City Of New York | Rapid image annotation via brain state decoding and visual pattern mining |
| US8611414B2 (en) * | 2010-02-17 | 2013-12-17 | University-Industry Cooperation Group Of Kyung Hee University | Video signal processing and encoding |
| CN106303534B (zh) * | 2015-06-08 | 2022-05-31 | 上海天荷电子信息有限公司 | 多种索引串与像素串融合复制方式的图像压缩方法和装置 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0766789A (ja) * | 1993-08-23 | 1995-03-10 | Matsushita Electric Ind Co Ltd | 可変レート画像伝送装置 |
| JP3432009B2 (ja) * | 1993-08-31 | 2003-07-28 | キヤノン株式会社 | 通信方法及び装置 |
| JPH07248980A (ja) * | 1994-03-11 | 1995-09-26 | N T T Data Tsushin Kk | マルチメディア情報の通信方式 |
-
1995
- 1995-05-17 JP JP11867295A patent/JP3609488B2/ja not_active Expired - Fee Related
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7853118B2 (en) | 2005-08-31 | 2010-12-14 | Kabushiki Kaisha Toshiba | Image replay apparatus and method for moving-picture streams |
Also Published As
| Publication number | Publication date |
|---|---|
| JPH08317384A (ja) | 1996-11-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3609488B2 (ja) | 情報処理システム | |
| JP3330797B2 (ja) | 動画像データ格納方式および動画像データ復号方式 | |
| JP4965059B2 (ja) | ビデオストリームの切り替え | |
| JP3628359B2 (ja) | データ転送方法、データ送信装置、データ受信装置およびビデオメールシステム | |
| KR20180031547A (ko) | 서버에서 멀티 비트 레이트 스트림 미디어를 적응적으로 제공하기 위한 방법 및 장치 | |
| JP2002084339A (ja) | ストリーミング方法およびそれを実行するシステム | |
| CN1254151A (zh) | 多媒体数据流网络代码转换用的系统 | |
| JP4983917B2 (ja) | 動画像配信システム、変換装置および動画像配信方法 | |
| JP2001204001A (ja) | 動画像配信システム，再生端末装置，及び配信装置 | |
| JP2002077260A (ja) | 画像伝送のためのシステムおよび方法 | |
| CA2160562A1 (en) | Adaptive video decompression | |
| JP2002199019A (ja) | 通信制御装置、通信制御方法、及び通信制御プログラムが記録された記録媒体 | |
| JP3852366B2 (ja) | 符号化装置および方法、復号装置および方法、並びにプログラム | |
| Biersack et al. | Constant data length retrieval for video servers with variable bit rate streams | |
| JP2002320228A (ja) | 信号処理装置 | |
| JPH07248980A (ja) | マルチメディア情報の通信方式 | |
| JPH09298749A (ja) | 動画配信方法及びその実施装置 | |
| JP3066301B2 (ja) | 記録媒体再生装置、再生方法、記録方法、及び記録装置 | |
| WO2004045216A1 (en) | Video streaming device and method of control for switchable video streams | |
| JP3860957B2 (ja) | マルチメディアデータの送出装置 | |
| JPH0818622A (ja) | 情報通信端末装置 | |
| Krunz et al. | Efficient support for interactive scanning operations in MPEG-based video-on-demand systems | |
| JP3730942B2 (ja) | ネットワーク動画像配信システム及びこのシステムにおけるクライアント装置 | |
| JP3946804B2 (ja) | 画像符号化制御方法 | |
| JPH11205390A (ja) | 伝送システム、端末装置、サーバ装置及び記録媒体 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040413 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040610 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20041005 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20041014 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20071022 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20081022 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |