JPH11191884A - ビデオサーバの端末コンピュータ及びビデオサーバへのアクセス方法 - Google Patents

Abstract

(57)【要約】 （修正有） 【課題】 ファイル入出力型の端末コンピュータをスト
リーム型のサーバに適応した要求に変換する。 【解決手段】 端末コンピュータに要求型変換部が備え
られ、ビデオ処理アプリケーションが発行するファイル
入出力型のファイルオープン要求Ｑｏもしくは最初の読
み出し要求Ｑｒに基づいて発行されたストリーム型のデ
ータ送出要求Ｐｓに基づいてビデオサーバより得られた
ストリームデータは受信処理手段１０３２によってバッ
ファ１０３３に蓄積されるとともに、バッファ転送手段
１０３４によってビデオ処理アプリケーション１０４が
発行する読み出し要求Ｑｒに応じて，該バッファに蓄積
されたストリームデータをビデオ処理アプリケーション
１０４に転送する。バッファ１０３３の残容量が所定値
より少ないか多いかにより、バッファ転送手段１０３４
がストリーム型の送出一時停止要求Ｐｔ又は送出再開要
求Ｐｒをサーバに対して発行する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、コンピュータネットワ
ークにおける端末コンピュータと該端末コンピュータか
らビデオサーバへのアクセス方法に関するものである。

【０００２】

【従来の技術】動画のビデオデータは時間的に連続して
いなければならないという宿命を持っており、この点は
通常の情報機器で扱われるファイル情報との決定的な違
いとなる。

【０００３】このようなビデオデータを端末コンピュー
タからの命令に従って読み出すビデオサーバとして、そ
の方式の違いからストリーム型とファイル入出力型があ
る。ストリーム型ビデオサーバとは、端末コンピュータ
からのデータ送出命令に対し、ビデオデータ送出停止命
令を受けるまで、ビデオデータを連続して送出し続ける
形式のビデオサーバをいう。このデータ処理方法は、大
量のビデオデータを短時間に伝送出来る点でビデオデー
タのように時間的連続性を必要とするデータを扱うのに
適した処理方法であり、ビデオサーバの普及にともなっ
て注目され、脚光を浴び、将来的に広く普及するものと
みられている。

【０００４】それに対してファイル入出力型ビデオサー
バは、従来から、コンピュータのデータの読み出し処理
において、一般的に普及しているファイルの読み出し形
式をそのままビデオデータの読み出しに適用したもので
あり、端末コンピュータからのデータのオフセットと送
出サイズを指定したファイルの読み出し要求の繰り返し
に対応して、ビデオデータを上記指定されたサイズ毎送
出するビデオサーバをいう。

【０００５】ファイル入出力型は従来からの手法をその
まま流用している点で扱い易い点があるが、将来的に
は、より高速にデータ伝送ができるストリーム型がより
広く普及することが予測され、従って、上記ファイル入
出力型とストリーム型のビデオサーバは共存することに
なると考えられ、両形式の互換性が要求されることにな
る。

【０００６】ここで、ネットワークを介して接続される
ビデオサーバと端末コンピュータで構成されるビデオサ
ーバシステムの概要は公知であるので、ここでは図示、
及び説明を省略する。また、ファイル入出力型のビデオ
サーバの構成および、ストリーム型ビデオサーバの構成
はこの発明に直接関係ないので、説明を省略する。

【０００７】図２０はストリーム型ビデオサーバに対応
する端末コンピュータの内部構成の機能ブロック図を示
すものである。ストリーム型ビデオサーバに対応した端
末コンピュータは、パケット送受信部１１０５と、プロ
トコル処理部１１０６と、ストリーム型インターフェー
ス１１０７と、ストリーム型ビデオ処理アプリケーショ
ン１１０８とから構成される。

【０００８】上記構成において、ストリーム型ビデオ処
理アプリケーション１１０８がデータ送出要求を発行す
ると、パケット処理部１１０６で、該要求に対応するパ
ケットを形成してパケット送受信部１１０５より送出す
る。ついで、上記のデータ送出要求に対応するデータ返
送があったとき、パケット送受信部１１０５にて該返送
パケットを受信し、パケット処理部１１０６で該返送パ
ケットの内容を解析してビデオ処理アプリケーション１
１０８に渡す。ビデオ処理アプリケーション１１０８は
以下のようにデータ受信部１１０４とデータ処理部１１
０３を起動するようになっている。

【０００９】データ受信部１１０４では受信したストリ
ームデータを順次バッファに蓄積し、該バッファの残容
量が所定値以下になるとストリーム型データ送出一時停
止要求を発行し、これを受けてビデオサーバはデータ送
出を一時停止する。

【００１０】上記のようにバッファに蓄積されたデータ
はデータ処理部１１０３によって順次取り出されて例え
ば表示に供される。このとき、バッファの残容量が所定
値以上になったとき、送出再開要求が発行されるように
なっている。更に、ビデオ処理アプリケーション１１０
８が送出停止要求を発行すると、ビデオサーバはデータ
の送出を停止することになる。

【００１１】尚、図２０に示すストリーム型インターフ
ェイス１１０７はビデオ処理アプリケーション１１０８
からプロトコル処理部１１０６に渡される要求の種類を
判別している。

【００１２】一方、図２１はファイル入出力型のビデオ
サーバに対応した端末コンピュータの構成を機能ブロッ
ク図として示したものである。機構的にはストリーム型
インターフェース１１０７と、ストリーム型対応のビデ
オ処理アプリケーション１１０８に代えてファイル入出
力型インターフェース１１０９と、ファイル入出力型対
応のビデオ処理アプリケーション１１１０とから構成さ
れるのみの違いであるが、発行される要求の種類は以下
のように、上記ストリーム型の場合と異なる。

【００１３】すなわち、ビデオ処理アプリケーション１
１１０からファイルオープン要求が発行されると、該要
求に対応してビデオサーバはファイルを開いてその結果
を端末コンピュータのビデオ処理アプリケーション１１
１０に返送する。ここでオペレータがファイルＩＤ等の
必要なデータを入力すると読み出し要求が発行され、該
要求に応じて所定サイズ（例えば８キロバイト）のデー
タがビデオサーバより端末コンピュータに渡される。こ
のデータを受けたビデオ処理アプリケーション１１１０
は次の読み出し要求を発行し、次の所定サイズのデータ
を受け取る。この手順はビデオサーバ側に指定されたデ
ータがなくなるまで、あるいは、オペレータの操作によ
ってビデオ処理アプリケーション１１１０から読み出し
要求が発行されなくなるまで継続されることになる。

【００１４】

【発明が解決しようとする課題】以上記述したように、
上記従来のビデオサーバネットワークでは、ストリーム
型ビデオサーバに対しては、ストリーム型のビデオ処理
アプリケーションを搭載した端末コンピュータでのみデ
ータの書き込み読み出し処理をすることができるように
なっており、一方、ファイル入出力型ビデオサーバに対
しては、ファイル入出力型のビデオ処理アプリケーショ
ンを搭載した端末コンピュータでのみデータの書き込み
読み出し処理をすることができるようになっている。

【００１５】上記ファイル入出力型ビデオサーバとファ
イル入出力型ビデオ処理アプリケーションを搭載した端
末コンピュータとの通信プロトコルは、従来よりのコン
ピュータでのデータの読み出し書き込み処理に準じた規
格化された方式を用いることができ、通常の端末コンピ
ュータが備える処理手段である。

【００１６】ところが、ストリーム型ビデオサーバと、
ストリーム型ビデオ処理アプリケーションを備えた端末
コンピュータとのデータのやりとりには、未だ規格化さ
れた方式がある訳でなく、ストリーム型ビデオサーバの
処理に合わせて端末コンピュータ側のビデオ処理アプリ
ケーションのプログラムを新たに作成する必要があっ
た。

【００１７】従って、既に規格化が進んでいるファイル
入出力型のビデオ処理アプリケーションを備えた端末コ
ンピュータを用いる方が安価となるのは明らかである
が、上記したようにファイル入出力型のビデオ処理アプ
リケーションをからストリーム型ビデオサーバへのアク
セスをすることはできない難点がある。

【００１８】本発明は上記従来の事情に鑑みて提案され
たものであって、ファイル入出力型ビデオサーバに対応
したビデオ処理アプリケーションを備えた端末コンピュ
ータを用いて、ストリーム型ビデオサーバにアクセスが
可能な端末コンピュータおよびアクセス方法を提供する
ことを提供することを目的とする。

【００１９】

【課題を解決するための手段】本発明は、上記の課題を
解決するために以下のような手段を採用している。すな
わち、ビデオデータを格納した複数のビデオサーバとビ
デオ処理アプリケーションを備えた複数の端末コンピュ
ータより構成されるコンピュータネットワークで、特定
の端末コンピュータよりの要求に基づいて特定のビデオ
サーバへのアクセスを実行する方法、を前提とする。

【００２０】上記の方法において、本発明は、端末コン
ピュータ内部で、ファイル入出力型の上記ビデオ処理ア
プリケーション１０５が発行する各種要求をストリーム
型ビデオサーバに適合する要求に変換し、該変換された
要求に基づいてストリーム型ビデオサーバへのアクセス
を実行するようにしている。このため、端末コンピュー
タ内部にファイル入出力型の要求をストリーム型の要求
に変換する要求型変換部１０３が備えられる。

【００２１】これによって、具体的には以下のような変
換がなされる。まず、上記要求型変換ブロック１０３
は、上記ビデオ処理アプリケーションが発行するファイ
ル入出力型のファイルオープン要求Ｑｏもしくは最初の
読み出し要求Ｑｒに基づいてストリーム型のデータ送出
要求Ｐｓを発行するようになっている。

【００２２】上記データ送出要求Ｐｓに基づいてビデオ
サーバより得られたストリームデータは受信処理手段１
０３２によってバッファ１０３３に蓄積されるととも
に、バッファ転送手段１０３４によってビデオ処理アプ
リケーション１０４が発行する読み出し要求Ｑｒに応じ
て，該バッファに蓄積されたストリームデータをビデオ
処理アプリケーション１０４に転送するようになってい
る。

【００２３】上記受信によって上記該バッファ１０３３
の残容量が所定値より少なくなったとき、上記バッファ
転送手段１０３４がストリーム型の送出一時停止要求Ｐ
ｔをサーバに対して発行し、これによって、ビデオサー
バは一時データの送出を停止する。

【００２４】また、上記のようにバッファ転送手段１０
３４によってバッファ１０３３のデータをビデオ処理ア
プリケーション１０４に転送した結果、バッファ１０３
３の残容量が所定値より多くなったときには、該バッフ
ァ転送手段１０３４が送出再開要求Ｐｒを発行する。

【００２５】上記のような構成、および手順によってフ
ァイル入出力型の端末コンピュータを用いて、ストリー
ム型ビデオサーバよりビデオデータを取得することがで
きることになる。すなわち、端末コンピュータ内部（Ｏ
Ｓ部分）に変更を加える必要があるにしても、従来のフ
ァイル入出力型のビデオ処理アプリケーションをそのま
ま用いてストリーム型のビデオサーバへのアクセスが可
能となり、安価なシステムを提供できることになる。

【００２６】

【実施の形態】（実施例１）図１は本発明の端末コンピ
ュータの第１の実施例を示すブロック図である。

【００２７】本発明の端末コンピュータは従来のファイ
ル入出力型対応の端末コンピュータと同様パケット送受
信部１０１、プロトコル処理部１０２、ファイル入出力
インターフェイス１０４、ファイル入出力型ビデオ処理
アプリケーション（以下特に必要ないときは単にビデオ
処理アプリケーションという）１０５を備え、更に、本
発明対象となる、ファイル入出力型の要求をストリーム
型の要求に変換する要求型変換部１０３を備えた構成と
なる。ここで、上記ファイル入出力インターフェイス
（以下単にインターフェイスという）１０４はビデオ処
理アプリケーション１０５からの要求の種類（例えばフ
ァイルオープン要求か読み出し要求か）を判別して要求
型変換部１０３に渡す機能を備えている。

【００２８】上記構成において、要求型変換部１０３
は、ビデオ処理アプリケーション１０５から、インター
フェイス１０４を介して、ファイルオープン要求、読み
出し要求、ファイルクローズ要求等のファイル入出力型
の要求を受け取る。このようにファイル入出力型の要求
を受け取った要求型変換部１０３は、後述する図４に示
すようような手順に従ってストリーム型の要求、すなわ
ち、データ送出要求、データ送出停止要求、データ送出
一時停止要求、データ送出再開要求をビデオサーバに対
して発行する。このようにして得られたストリーム型の
要求は、プロトコル処理部１０２とパケット送受信部１
０１を介してビデオサーバに送られる。

【００２９】また、上記のように要求を受けたビデオサ
ーバからは当該要求に対応したデータが返され、端末コ
ンピュータのパケット送受信部１０１とプロトコル処理
部１０２とを介して要求型変換部１０３が受取り、ビデ
オ処理アプリケーション１０６に必要なデータを転送す
るようになっている。ここで、典型的な転送レートとし
ては1.5Mbps 程度であり数百Kbps（音声）〜数Mbps（映
像）まで使用可能である。

【００３０】図２は本発明に使用する要求型変換部の更
に詳しいブロック図であり、更に図３〜図５は当該端末
コンピュータの動作手順を示すフロー図である。まず、
ビデオ処理アプリケーション１０５より発行されるファ
イルオープ要求に対しては、図５に示すようにファイル
オープン処理手段１０３５が起動して、オペレータがフ
ァイルＩＤ等を入力できる状態を形成して終了する。

【００３１】次いで、オペレータがファイルＩＤ等を入
力すると、ビデオ処理アプリケーション１０５は最初の
読み出し要求Ｑｒを発行することになる。ここで、ファ
イル入出力型のビデオサーバに対応した読み出し要求Ｑ
ｒは上記したように、所定サイズ（例えば８キロバイ
ト）のデータを要求するために間欠的に発行される要求
パケットであり、その最初の要求（後述するように未だ
ストリーム型ビデオサーバにデータ送出要求Ｐｓが発行
されていないときに受けた読み出し要求Ｑｒ）を上記要
求型変換部１０３を構成する判別手段１０３０が確認
し、該確認に基づいて送出要求処理手段１０３１がスト
リーム型のデータ送出要求Ｐｓを発行する（図３、ステ
ップＳ３２０１→Ｓ３２０２）。上記データ送出要求Ｐ
ｓに基づいて要求型変換部１０３を構成する受信処理手
段１０３２が起動されるとともに、この受信処理手段１
０３２は受信ビデオデータがビデオサーバより返送され
るまでは待機状態となる（図３、ステップＳ３２０
３）。

【００３２】ストリーム型ビデオサーバからは、上記デ
ータ送出要求Ｐｓに応答してビデオデータが返され、該
ビデオデータはパケット送受信部１０１とプロトコル処
理部１０２とを介して要求型変換部１０３に受取られる
ことになる。受信処理手段１０３２はこのようにして受
け取られたストリームデータをバッファ１０３３に蓄積
処理をする（図３、ステップＳ３２０４）。上記受信処
理手段１０３２は常時バッファ１０３３の残容量を監視
しており、残容量がなくなる（所定値より少なくなる）
と、該送出一時停止要求Ｐｔをビデオサーバに発行する
（図３、ステップＳ３２０５→Ｓ３２０６）。これによ
って受信処理手段１０３２は後述する送出再開要求Ｐｒ
を受けるまで待機（ポーズ）状態となる。ここで使用さ
れるバッファサイズとしては通常数百Kbyte 程度のサイ
ズを使用、典型的には256Kbyte程度を使用し、また、上
記残容量としては0 〜128Kbyte程度を、典型的には32Kb
yte 程度を使用する。

【００３３】ここで、このようにバッファ１０３３に蓄
積されたストリームデータをビデオ処理アプリケーショ
ン側に渡す必要があるため、上記送出一時停止要求Ｐｔ
が受信処理手段１０３２より出されると、バッファ転送
手段１０３４が起動し、ビデオ処理アプリケーション１
０５に所定サイズのデータを転送する。ビデオ処理アプ
リケーション１０５はこのデータを受信すると、次の読
み出し要求Ｑｒを発行し、この読み出し要求Ｑｒは判別
手段１０３０で、送出要求中の読み出し要求Ｑｒと判断
されてバッファ転送手段１０３４の作動を継続し、バッ
ファよりの所定サイズ毎のデータ転送を繰り返すことに
なる（図３、ステップＳ３２０９）。

【００３４】上記バッファ転送手段１０３４はバッファ
１０３３の残容量を常時監視しており、該バッファ１０
３３の残容量が所定値以上になったとき、上記バッファ
転送手段１０３４は送出再開要求Ｐｒを発行する（図
３、ステップＳ３２１０→Ｓ３２１１）。これによっ
て、再び受信処理手段１０３２が受信手順を実行（リス
タート）することになる。

【００３５】オペレータの操作によってビデオ処理アプ
リケーション１０５がファイルクローズ要求Ｑｃを発行
すると、インターフェイス１０４がその内容を判別し、
送出停止処理手段１０３５を起動して、図４に示すよう
に、送出停止要求Ｐｕが発行され送出手順が終了する。

【００３６】以上のように、本実施例では、端末コンピ
ュータに要求型変換部１０３を設けて、ビデオ処理アプ
リケーション１０５より発行されるファイル入出力型の
要求をストリーム型の要求に変換しているため、ファイ
ル入出力型の端末コンピュータが備える標準的なビデオ
処理アプリケーションを用いてストリーム型ビデオサー
バと通信できるという効果を有することになる。

【００３７】（実施例２）本発明の端末コンピュータの
第２の実施例を説明する。端末コンピュータの構成自体
は実施例１と同様であるのでここでの説明は省略する。

【００３８】図６は当該実施例２の要求型変換部１０３
の更に詳しいブロック図であり、図７、図８はその動作
手順を示すフロー図である。インターフェイス１０４は
ビデオ処理アプリケーション１０５より発行されるファ
イルオープン要求Ｑｏを受けて、ファイルオープン処理
手段１０３５を起動してファイルオープンに必要な処理
をする。これとともに、送出要求処理手段１０３１を起
動して、ストリーム型のデータ送出要求Ｐｓを発行し、
更に、受信処理手段１０３２を起動する（図７、ステッ
プＳ４２０１）。この後、受信処理手段１０３２はビデ
オサーバよりデータが返送されるのを待ってバッファ１
０３３に順次ストリームデータを蓄積する（図７、ステ
ップＳ４２０２〜Ｓ４２０４）。これによってバッファ
１０３３の残容量が所定値以下になったとき送出一時停
止要求Ｐｔを発行して待機（ポーズ）状態となって終了
する（図７、ステップＳ４２０５）。

【００３９】上記ファイルオープン処理時にオペレータ
がファイルＩＤ等の必要な入力を行うと読み出し要求Ｑ
ｒがビデオ処理アプリケーション１０５から発行され、
該読み出し要求Ｑｒは上記受信処理手段１０３２が送出
一時停止要求Ｐｔを出したことを条件に（判別手段１０
３０参照）バッファ転送手段１０３４を起動して、上記
のようにバッファ１０３３に蓄積されたストリームデー
タを所定サイズビデオ処理アプリケーション１０５に転
送するようになっている（図７、ステップＳ４２１１→
Ｓ４２１２）。

【００４０】上記したように読み出し要求Ｑｒはビデオ
処理アプリケーション１０５が上記所定サイズのデータ
を受ける毎に発行されるので、上記転送処理は繰り返し
行われ、上記バッファ１０３３の残容量が所定値以上に
なったとき、バッファ転送手段１０３４が送出再開要求
Ｐｒを発行し、再び受信処理手段１０３２を起動（リス
タート）する（図７、ステップＳ４２１３→Ｓ４２１
４）。

【００４１】ビデオ処理アプリケーション１０５よりの
ファイルクローズ要求Ｑｃに対しては、図８に示すよう
に送出停止処理手段１０３６が起動して送出停止要求Ｐ
ｕをビデオサーバに発行して終了する。

【００４２】以上のように、本実施例では、実施例１の
動作と若干異なり、ファイル入出力型のファイルオープ
ン要求Ｑｏが発行された時点で、ストリーム型のデータ
送出要求Ｐｓを送出するようになっており、読み出し要
求Ｑｒが発行される前に、ストリームデータをバッファ
１０３３に先読みするようになっている。このように、
本実施例によれば、実施例１での効果に加えて、ファイ
ル入出力型の読み出し要求Ｑｒに対するビデオ処理アプ
リケーションへの応答が高速になるという効果を有す
る。

【００４３】（実施例３）図９は本発明の端末コンピュ
ータの第３の実施例を示すブロック図、図１０〜図１２
はその動作手順を示すフロー図である。本実施例に用い
る要求型変換部の詳細を示すブロック図は図２に示す変
換部と略同じであるので、該図２を用いて説明する。

【００４４】この端末コンピュータは実施例１と同様パ
ケット送受信部１０１、プロトコル処理部１０２、要求
型変換部１０３、ファイル入出力インターフェイス３０
４、ビデオ処理アプリケーション１０５で構成される
が、この実施例では、第１の実施例における上記要求型
変換部１０３より受信処理手段１０３２を分離させた構
成となっている。以下分離された受信処理手段を受信処
理部３０３として記述する。

【００４５】ビデオ処理アプリケーション１０５から、
インターフェイス１０４を介して、要求型変換部３０４
は、ファイル入出力型の要求を受け取り、ここで、スト
リーム型の要求に変換してプロトコル処理部１０２とパ
ケット送受信部１０１とを介しビデオサーバに転送する
点は上記実施例１と同様である。また、上記のように要
求を受けたビデオサーバからは当該要求に対応したデー
タが返され、パケット送受信部１０１とプロトコル処理
部１０２とを介してデータ受信部３０３が受取り、要求
型変換部３０４はデータ受信部３０３が受け取ったデー
タを、ビデオ処理アプリケーション１０６に転送するよ
うになっている。

【００４６】以下、図２のブロック図および図１０〜図
１２に示すフロー図に基づいて更に詳しく説明する。上
記実施例１と同様に、ビデオ処理アプリケーション１０
５よりのファイルオープン要求Ｑｏが発行されたときに
はファイルオープン処理手段１０３５が起動してファイ
ルオープン処理をして終了する。

【００４７】上記ファイルオープン状態でオペレータが
ファイルＩＤ等の必要なデータを入力するとビデオ処理
アプリケーション１０５は読み出し要求Ｑｒを発行す
る。このビデオ処理アプリケーション１０５よりのファ
イル読み出し要求Ｑｒに対して、まず、判別手段１０３
０が下記のデータ送出要求Ｐｓが出されていないことを
確認したとき、送出要求処理手段１０３１が起動する。
このように起動された送出要求処理手段１０３１はビデ
オサーバに対してデータ送出要求Ｐｓを発行するととも
に、データ受信部３０３を起動して待機状態に移行する
（図１０、ステップＳ５２０１〜Ｓ５２０４）。

【００４８】一方、上記のように起動されたデータ受信
部３０３は当該要求型変換部１０３と並行して動作しデ
ータを受信することになる。当該受信部３０３がバッフ
ァ１０３３にデータを受信して該バッファ１０３３の残
容量が所定値以下になったとき、ストリーム型送出一時
停止要求Ｐｔを発行して待機状態（ポーズ）となる（図
１１、ステップＳ５３０１〜Ｓ５３０５）。

【００４９】これによってビデオサーバからのデータ送
出が一時停止されるとともに、バッファ転送手段１０３
４が起動して、所定サイズのデータをバッファ１０３３
からビデオ処理アプリケーション１０５に転送すことに
なる（図１０、ステップＳ５２０５→Ｓ５２０６）。

【００５０】上記バッファ転送手段１０３４の作動によ
って最初の所定サイズのデータがビデオ処理アプリケー
ション１０５に転送されると、該ビデオ処理アプリケー
ション１０５は再度読み出し要求Ｑｒを発行することに
なる。この読み出し要求Ｑｒが発行された時点では上記
送出要求処理手段１０３１は起動しているので、上記読
み出し要求Ｑｒはバッファ転送手段１０３４を引き続き
駆動して所定サイズのデータをビデオ処理アプリケーシ
ョン１０５に転送することを繰り返すことになる（図１
０、ステップＳ５２０７〜Ｓ５２０８）、ここでバッフ
ァ１０３３の残容量が所定サイズ以上になるとビデオサ
ーバに対して送出再開要求Ｐｒを発行することになり、
この再開要求Ｐｒを受けて受信部３０３の待機状態は解
除（リスタート）される（図１０、Ｓ５２０９）。

【００５１】ファイルクローズ要求Ｑｃに対しては、上
記２つの実施例と同様送出停止処理手段１０３６がデー
タ送出停止要求Ｐｕを発行して処理を終了する。以上説
明したように、本実施例によれば、データ受信部３０３
（受信処理手段１０３２）を前記要求型変換部１０３よ
り分離したので、データ受信部３０３は前記要求型変換
部１０３より起動、ポーズ、リスタートの指示は受ける
ものの上記ビデオ処理アプリケーション１０５と関連し
て動作する要求型変換部１０３と殆ど関係なく動作する
ので、ビデオサーバから返送されるデータの転送レート
が高くなっても、ビデオ処理アプリケーション１０５へ
のデータ転送処理に影響を与えることはなく、映像の途
切れ等が発生するおそれはなくなる。

【００５２】（実施例４）図１３〜図１６は更に別の実
施例の動作手順を示すフロー図である。この実施例の端
末コンピュータの基本的な構成は上記図９に示す場合と
同じであるので図示および説明を省略する。また、この
実施例の要求型変換部の機能ブロック図は図６とほぼ同
じになるので以下図６および図１３〜図１６を用いて説
明する。

【００５３】この実施例は基本的には実施例３と実施例
２を組み合わせたものであり、受信処理手段１０３２が
ファイル入出ストリーム型変換部１０３より分離される
とともに、ファイル入出力型のファイルオープン要求Ｑ
ｏを利用して、ストリーム型のデータ送出要求Ｐｓを形
成する構成となっている。尚、この実施例でも分離され
た受信処理手段１０３２を受信部３０３として扱ってい
る。

【００５４】オペレータの操作によって、ビデオ処理ア
プリケーション１０５よりファイルオープン要求Ｑｏが
発行されるとファイルオープン処理手段１０３６が起動
する。これととともに、送出要求処理手段１０３１が起
動してビデオサーバに対してデータ送出要求Ｐｓを発行
し、更に、データ受信部３０３を起動する（図１３、ス
テップＳ６２０１→Ｓ６２０２）。

【００５５】上記のように起動されたデータ受信部３０
３は、データ受信を待ち、データ受信があったときバッ
ファ１０３３の残容量がなくなるまで受信し、バッファ
１０３３の残容量がなくなったとき、ビデオサーバに対
して一時停止要求Ｐｔを発行して待機（ポーズ）状態と
なる（図１５、ステップＳ６４０１〜Ｓ６４０５）。

【００５６】上記ファイルオープン要求Ｑｏの後にオペ
レータの操作によってファイルＩＤ等の必要な事項が入
力されると、ビデオ処理アプリケーション１０５はファ
イル入出力型の読み出し要求Ｑｒを発行する。この読み
出し要求Ｑｒは、上記受信部３０３が送出一時停止要求
Ｐｔを発行していることを条件に（判別手段１３０参
照）バッファ転送手段１０３４を起動してバッファ１０
３３に蓄積されたデータをビデオ処理アプリケーション
１０５に転送する（図１４、ステップＳ６３０１〜Ｓ６
３０３）。ここでバッファ１０３３の残容量が所定値よ
り多くなると、ビデオサーバに対してデータ送出再開要
求Ｐｒを発行するとともに、受信部３０３の待機状態を
解除（リスタート）する（図１４、ステップＳ６３０
４）。

【００５７】ファイルクローズ要求Ｑｃがあったときは
送出停止要求手段１０３６が起動して送出停止要求Ｐｕ
を発行してファイルクローズ処理をする。以上のよう
に、本実施例は要求型変換部１０３とデータ受信部３０
３とを分離した構成とするとともに、ファイル入出力の
ファイルオープン要求Ｑｏを以て、ストリーム型のデー
タ送出要求Ｐｓを発行するようになっている。従って、
データ受信部３０３は前記要求型変換部１０３より起
動、ポーズ、リスタートの指示は受けるものの上記ビデ
オ処理アプリケーション１０５と関連して動作する要求
種変換部１０３と殆ど関係なく動作するので、ビデオサ
ーバから返送されるデータの転送レートが高くなって
も、ビデオ処理アプリケーション１０５へのデータ転送
処理に影響を与えることはなく、映像の途切れ等が発生
するおそれはなくなる。

【００５８】（実施例５）図１７は本発明の別の実施例
の概要を示すブロック図であり、図１９はその操作手順
を示すフロー図である。

【００５９】上記実施例３に記述した場合と同様、パケ
ット送受信部１０１、プロトコル処理部１０２、データ
受信部３０３、要求型変換部１０３、ファイル入出力イ
ンターフェイス１０４、ビデオ処理アプリケーション１
０５を備えるとともに、本実施例では、ストリーム型ビ
デオサーバ判定部５０５、サーバ種情報蓄積部５０６を
備えた構成にしている。

【００６０】上記サーバ種情報蓄積部５０６には図１８
に示すテーブルのように、ビデオサーバを特定する識別
記号と、該ビデオサーバがファイル入出力型かストリー
ム型かを区別するサーバ種記号とを対にして記憶してい
る。この状態で、ビデオ処理アプリケーション１０５よ
りのファイルオープン要求があると該ファイルオープン
要求はまず判定部５０５に通知される。

【００６１】ここで、上記ファイルオープン要求には読
み出すべき装置ＩＤも含まれているので、上記判定部５
０５は上記サーバ種情報蓄積部５０６のテーブルを参照
して、要求対象のファイルが格納されたビデオサーバが
該テーブルに登録されているか否かを判断する（図１
９、ステップＳ７２０１→Ｓ７２０２）。ここで、上記
テーブルに対象のビデオサーバが登録されているときに
は、サーバ種判定部５０５は続いて該要求がストリーム
型サーバに対する要求か否かを判定する（図１９、ステ
ップＳ７２０３）。ここで、ストリーム型であると判定
された場合は、要求型変換部１０３が、ファイル入出力
型の要求を受け取り、上記の実施例３、４に説明したい
ずれかの手順でストリーム型の要求に変換され、その
後、パケットに編集されて対象のサーバに送信されるこ
とになる（図１９、ステップＳ７２０４→Ｓ７２０５→
Ｓ７２０６）。ここで、要求型変換部１０３と、受信部
３０３を分離しない構成をとることもでき、その場合は
上記実施例１、２で説明した手順でストリーム型の要求
に変換されることになる。

【００６２】また、当該要求を受け取ったビデオサーバ
は当該要求に対応するデータが端末コンピュータに返送
することになる。このように返送されたデータはパケッ
ト送受信部１０１とプロトコル処理部１０２を介してデ
ータ受信部３０３（データ受信手段１０３２）が受取
り、要求型変換部１０３はデータ受信部３０３が受信し
たデータを、ビデオ処理アプリケーション５０８に転送
することになる。

【００６３】一方、上記ビデオサーバの種類を判定する
処理の段階でストリーム型でないと判定された場合は、
ビデオ処理アプリケーション１０５よりの要求がそのま
ま、すなわち、ファイル入出力型の要求のままプロトコ
ル処理部１０２とパケット送受信部１０１を介してビデ
オサーバに送られる（図１９、ステップＳ７２０３：Ｎ
ｏ→Ｓ７２０５参照）。また、ビデオサーバからは当該
要求に対するデータが返され、プロトコル処理部１０２
とパケット送受信部１０１を介して受取り、ビデオ処理
アプリケーション１０５にデータを返す。

【００６４】上記サーバ種情報蓄積部５０６のテーブル
にアクセス対象のビデオサーバが登録されていないと判
断されたとき，対象のビデオサーバにストリーム型か否
かを問い合わせる（図１９、ステップＳ７２０２：Ｎｏ
→Ｓ７２０７）。要求型変換部１０３はこの返事を受け
取ってサーバ種情報蓄積部５０６のテーブルにその内容
を登録するとともに、その内容に従って各種の要求を出
すことになる。以上のように、本実施例では、端末コン
ピュータのシステム内部に、ビデオ処理アプリケーショ
ンからの要求が、ストリーム型ビデオサーバに対する要
求か否かを判定するサーバ判定部５０５を設け、ファイ
ル入出力型のビデオサーバに対する要求は、要求型変換
部１０３を経由しない構成としている。従って、本実施
例によれば、実施例１〜４に示した効果に加えて、スト
リーム型ビデオサーバに対しても、従来からのファイル
入出力型ビデオビデオサーバに対しても、通信が可能で
あるという効果を発揮することになる。

【００６５】

【発明の効果】以上説明したように本発明により、従来
からのファイル入出力型のビデオ処理アプリケーション
をそのまま用いて、ストリーム型ビデオサーバとの通信
を行なうことができることになる。読み出し対象となる
サーバがファイル入出力型かストリーム型かを判定する
判定手段を設けることによって、従来からのファイル入
出力型のビデオ処理アプリケーションをそのまま用い
て、ストリーム型ビデオサーバとも、ファイル入出力型
のビデオサーバとも、通信を行なうことができる。

【図面の簡単な説明】

【図１】本発明のシステム全体構成図である。

【図２】本発明の実施例１における要求型変換部の機能
ブロック図である。

【図３】本発明の実施例１における処理手順を示すフロ
ー図である。

【図４】本発明の実施例１における処理手順を示すフロ
ー図である。

【図５】本発明の実施例１における処理手順を示すフロ
ー図である。

【図６】本発明の実施例２における要求型変換部の機能
ブロック図である。

【図７】本発明の実施例２における処理手順を示すフロ
ー図である。

【図８】本発明の実施例２における処理手順を示すフロ
ー図である。

【図９】本発明の別のシステム構成図である。

【図１０】本発明の実施例３における処理手順を示すフ
ロー図である。

【図１１】本発明の実施例３における処理手順を示すフ
ロー図である。

【図１２】本発明の実施例３における処理手順を示すフ
ロー図である。

【図１３】本発明の実施例４における処理手順を示すフ
ロー図である。

【図１４】本発明の実施例４における処理手順を示すフ
ロー図である。

【図１５】本発明の実施例４における処理手順を示すフ
ロー図である。

【図１６】本発明の実施例４における処理手順を示すフ
ロー図である。

【図１７】本発明の実施例５におけるシステム構成図で
ある。

【図１８】本発明の実施例５に使用するテーブルの概念
図である。

【図１９】本発明の実施例５の処理手順を示すフロー図
である。

【図２０】従来のストリーム型端末コンピュータの構成
図である。

【図２１】従来のファイル入出力型端末コンピュータの
構成図である。

【符号の説明】

１０１ パケット送受信部 １０２ プロトコル処理部 １０３ 要求型変換部 １０４ ファイル入出力型インターフェイス １０５ ビデオ処理アプリケーション ３０３ データ受信部 ５０５ サーバ種判定部 ５０６ サーバ種情報蓄積部 １０３１ 送出要求処理手段 １０３２ 受信処理手段 １０３３ バッファ １０３４ バッファ転送手段 Ｑｒ 読み出し要求 Ｑｏ ファイルオープン要求 Ｑｃ ファイルクローズ要求 Ｐｓ データ送出要求 Ｐｔ 送出一時停止要求 Ｐｒ 送出再開要求 Ｐｕ 送出停止要求

Claims (18)

【特許請求の範囲】
1. 【請求項１】 ビデオデータを格納した複数のビデオサ
   ーバとビデオ処理アプリケーションを備えた複数の端末
   コンピュータより構成されるコンピュータネットワーク
   の上記端末コンピュータにおいて、 ファイル入出力型の上記ビデオ処理アプリケーションが
   発行する各種要求をストリーム型ビデオサーバへのアク
   セスに適合した要求に変換する要求型変換部を備えたこ
   とを特徴とするビデオサーバの端末コンピュータ。
2. 【請求項２】 上記要求型変換部が、 ビデオ処理アプリケーションが発行するファイル入出力
   型のファイルオープン要求もしくは最初の読み出し要求
   に基づいてストリーム型のデータ送出要求を発行する送
   出要求処理手段と、 上記データ送出要求に基づいてビデオサーバより得られ
   たストリームデータを受信してバッファに蓄積する受信
   処理手段とを備えた請求項１に記載の端末コンピュー
   タ。
3. 【請求項３】 上記受信処理手段が上記バッファの残容
   量が所定値以下になったときにストリーム型の送出一時
   停止要求を発行する請求項２に記載のビデオサーバの端
   末コンピュータ。
4. 【請求項４】 上記バッファに蓄積されたデータをビデ
   オ処理アプリケーションからの読み出し要求に基づいて
   ビデオ処理アプリケーションの記憶手段に転送するバッ
   ファ転送手段を備えた請求項２に記載のビデオサーバの
   端末コンピュータ。
5. 【請求項５】 上記バッファ転送手段が更に、上記バッ
   ファの残容量が所定値以上になったとき、ストリーム型
   の送出再開要求を発行する請求項４に記載のビデオサー
   バの端末コンピュータ。
6. 【請求項６】 上記送出要求処理手段が、最初の読み出
   し要求に基づいてデータ送出要求を発行し、上記受信処
   理手段が送出一時停止要求を発行した後に引き続いて、
   バッファ転送手段が１回目の転送処理をする請求項４ま
   たは５に記載のビデオサーバの端末コンピュータ。
7. 【請求項７】 上記バッファ転送手段が上記送出要求が
   発行された後にビデオ処理アプリケーションより得られ
   る読み出し要求に基づいて転送処理をする請求項４また
   は５に記載のビデオサーバの端末コンピュータ。
8. 【請求項８】 上記送出要求処理手段が、ファイルオー
   プン要求に基づいてデータ送出要求を発行し、バッファ
   転送手段が上記受信処理手段が送出一時停止要求を発行
   したことを確認した後に、読み出し要求に基づいて転送
   処理をする請求項４または５のいずれかに記載のビデオ
   サーバの端末コンピュータ。
9. 【請求項９】 上記受信処理手段が、上記送出要求処理
   手段の発行するデータ送出要求によって起動し、上記バ
   ッファ転送手段の動作と並行して受信処理を行う請求項
   ４または５のに記載の端末コンピュータ。
10. 【請求項１０】更に、ビデオサーバを特定する識別記号
    と、該ビデオサーバがファイル入出力型かストリーム型
    かを区別するサーバ種記号とを対にして記憶したサーバ
    種情報蓄積部と、 前記サーバ種蓄積部を参照して、ビデオ処理アプリケー
    ションよりの要求が、ストリーム型サーバに対する要求
    か否かを判定をし、ストリーム型サーバに対する要求で
    あるときには、該要求を要求型変換部に渡すデータ種判
    定部を備えた請求項１〜９のいずれかに記載の端末コン
    ピュータ。
11. 【請求項１１】 上記データ種判定部が判断対象となる
    サーバが上記サーバ種情報蓄積部に登録されているか否
    かを判定し、登録されていないときには該サーバにスト
    リーム型であるか否かを問い合わせて、得られた結果を
    サーバ種情報蓄積部に登録するとともに、上記サーバ種
    の判定をする請求項１０に記載の端末コンピュータ。
12. 【請求項１２】 ビデオデータを格納した複数のビデオ
    サーバとビデオ処理アプリケーションを備えた複数の端
    末コンピュータより構成されるコンピュータネットワー
    クで、特定の端末コンピュータよりの要求に基づいて特
    定のビデオサーバへのアクセスを実行する方法におい
    て、 上記端末コンピュータ内部において、ファイル入出力型
    の上記ビデオ処理アプリケーションが発行する各種要求
    をストリーム型ビデオサーバに適合する要求に変換し、
    該変換された要求に基づいてストリーム型ビデオサーバ
    へのアクセスを実行することを特徴とするビデオサーバ
    へのアクセス方法。
13. 【請求項１３】 上記ビデオ処理アプリケーションが発
    行するファイル入出力型のファイルオープン要求もしく
    は最初の読み出し要求に基づいてストリーム型のデータ
    送出要求を発行する請求項１２に記載の要求変換方法。
14. 【請求項１４】 上記データ送出要求に基づいてビデオ
    サーバより得られたストリームデータを受信してバッフ
    ァに蓄積するとともに、ビデオ処理アプリケーションが
    発行する読み出し要求に応じて該バッファに蓄積された
    ストリームデータをビデオ処理アプリケーションに転送
    する請求項１３に記載の要求変換方法。
15. 【請求項１５】 上記受信によって上記該バッファの残
    容量が所定値より少なくなったときにストリーム型の送
    出一時停止要求を発行する請求項１４に記載の要求変換
    方法。
16. 【請求項１６】 上記転送によって上記該バッファの残
    容量が所定値より多くなったときにストリーム型の送出
    再開要求を発行する請求項１４に記載の要求変換方法。
17. 【請求項１７】 ビデオデータを格納した複数のビデオ
    サーバとビデオ処理アプリケーションを備えた複数の端
    末コンピュータより構成されるコンピュータネットワー
    クで、特定の端末コンピュータよりの要求に基づいて特
    定のビデオサーバへのアクセスを実行する処理手順をプ
    ログラムとして格納した記憶媒体において、 上記端末コンピュータ内部において、ファイル入出力型
    の上記ビデオ処理アプリケーションが発行する各種要求
    をストリーム型ビデオサーバに適合する要求に変換し、
    該変換された要求に基づいてストリーム型ビデオサーバ
    へのアクセスを実行する処理手順をプログラムとして格
    納した記憶媒体。
18. 【請求項１８】 上記ビデオ処理アプリケーションが発
    行するファイル入出力型のファイルオープン要求もしく
    は最初の読み出し要求に基づいてストリーム型のデータ
    送出要求を発行する処理手順をプログラムとして格納し
    た請求項１７に記載した記憶媒体。