JPH11239334A - ブリッジ制御クライアント装置 - Google Patents

Abstract

(57)【要約】 【課題】 ビデオサーバシステムに高精細度用画像符号
化装置、復号装置を併用して使用する。 【解決手段】 揺らぎ吸収バッファと、命令コードを受
信するコマンド受信スレッドと、コマンド受信スレッド
中の該当コマンドに基づいて入力画像信号の受信バッフ
ァから所定のタイミングで設定量の画像データを取り出
しバッファに読み込み、かつステップ中に受信スレッド
中のコマンドを調べる読み込みスレッドと、コマンド受
信スレッド中の該当コマンドに基づいてバッファから所
定のタイミングで設定量の画像データを取り出して出力
画像信号の送信バッファに書き込み、かつステップ中に
受信スレッド中のコマンドを調べる書き込みスレッドと
を備えて、読み込みスレッドまたは書き込みスレッドの
実行優先度を最も高くした。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ビデオサーバと、
高精細動画の符号化装置、復号装置とを仲介して高精細
動画の再生、登録とそれらの命令および、一時停止、そ
の解除や停止といったストリーム制御ができるようにす
る装置に関するものである。

【０００２】

【従来の技術】図８は従来の例えばビデオサーバ１台と
クライアント３台とから成るビデオサーバシステムであ
り、図において１はビデオサーバ、３は従来のクライア
ント、２は、クライアントとビデオサーバを接続するた
めのネットワーク接続機器である。

【０００３】次にこの構成の装置の動作について説明す
る。まず、従来クライアント３上では、ビデオサーバ上
に格納されている動画ファイルを確認でき、見たい動画
ファイルがあると、それを選択して配信要求をビデオサ
ーバ１に対して行う。従来クライアント３からの接続要
求が発生すると、ビデオサーバはビデオサーバ自身のリ
ソースを確認して、リソースに余裕があれば配信可能と
判断して配信を開始する。従来クライアント３は、その
動画に対応した拡張ボードあるいは復号するためのＳ／
Ｗを介し配信された動画を従来クライアント３に接続さ
れたディスプレイに表示する。

【０００４】ビデオサーバ１は、従来クライアント３で
再生、表示可能な、高々６Ｍｂｐｓ程度の動画を転送レ
ートを守って配信するためのものである。その配信制御
はソフトウエアで行っており、ビデオサーバ上のＯＳの
タスク制御やスワップなどの動作により、遅延が発生す
る場合がある。通常ビデオサーバは、この遅延のリカバ
リを行い遅延した分を取り戻すためにデータを速く送出
する。この制御の結果として、最終的に転送レートを守
る仕組みである。従来クライアント３上では、バッファ
リングを行い、遅延を吸収しながら復号、再生制御を行
っている。

【０００５】一方これとは別に、高精細度の動画画像を
伝送するシステムがあり、そのシステム中の符号化装置
および復号装置は、直接接続する目的で設計されている
ので、ビデオサーバに画像を蓄積して、クライアントか
ら画生等の制御をすることができない。ビデオサーバシ
ステムとして、クライアントとこれらの機器を接続し
て、ストリーム制御を行うために、例えばＡＴＭ上で動
画を転送する手段としてＭＰＥＧ２−ＴＳと呼ばれる１
８８バイトのＴＳパケットを２つずつ、すなわち３７６
バイトずつ転送するＭＰＥＧ ｏｖｅｒ ＡＴＭ（ＡＴ
Ｍフォーラムにて公開）を採用すると、クライアントは
３７６バイト単位の処理を行う必要がある。この処理は
２０Ｍｂｐｓでは、毎秒６６５０回の処理が必要とな
り、ソフトウエアだけでは処理できない。従ってビデオ
サーバのＯＳによるタスク制御やスワップ動作で処理が
途切れて、登録蓄積の場合にはデータ落ち、再生の場合
には画像の欠落が生じる。

【０００６】

【発明が解決しようとする課題】従来のビデオサーバシ
ステムでは、ビデオサーバから配信される動画を接続さ
れている従来クライアント以外の他の復号装置に対して
送出して動画像を表示したり、高精細度動画用の符号化
装置によってデジタル化された高精細度動画像をファイ
ル化することは出来ないという課題があった。また、ビ
デオサーバはクライアントに対して動画を転送するため
に存在するため、クライアントからの命令によってのみ
動作するので、こうした命令に対応していないいわゆる
直後結合形とでもいうべき高精細度符号化装置と高精細
度復号装置に介在して、ビデオ配信を行うことは出来な
いという課題があった。さらに、従来クライアント上で
２０Ｍｂｐｓ以上もの広帯域動画を復号する拡張ボード
は、装置が大きくなるため実用的でないという課題もあ
った。

【０００７】この発明は上記の課題を解決するためにな
されたもので、サーバシステムにおいて、高精細度用の
画像符号化装置、復号装置を接続し、高速に動画像をリ
アルタイム転送し、かつ、ソフトウエアでの処理を軽減
したブリッジ制御クライアントを得ることを目的とす
る。こうすることでビデオサーバは従来クライアントに
対する動画配信サービスと、新たに付加した高精細度用
のブリッジ制御クライアントが併存するシステムを構築
することができる。

【０００８】

【課題を解決するための手段】この発明に係るブリッジ
制御クライアント装置は、網または装置に接続された画
像送信源装置からの入力画像信号を中継して装置または
網に接続された画像受信装置に転送するために、揺らぎ
吸収バッファと、画像の蓄積開始または再生、停止を含
む命令コードを受信するコマンド受信スレッドと、この
コマンド受信スレッド中の該当コマンドに基づいて入力
画像信号の受信バッファから第１の所定のタイミングで
第１の設定量の画像データを取り出しバッファに読み込
み、かつステップ中に上記受信スレッド中のコマンドを
調べるステップを設けた読み込みスレッドと、コマンド
受信スレッド中の該当コマンドに基づいてバッファから
第２の所定のタイミングで第２の設定量の画像データを
取り出して出力画像信号の送信バッファに書き込み、か
つステップ中に受信スレッド中のコマンドを調べるステ
ップを設けた書き込みスレッドとを備えて、読み込みス
レッドまたは書き込みスレッドの実行優先度を最も高く
した。

【０００９】また更に、画像送信源装置は網に接続され
たビデオサーバとし、画像受信装置は装置に接続された
画像復号装置とし、書き込みスレッドの実行優先度を最
も高くして、この書き込みスレッドに対する動作要求コ
ードがある場合は、他に優先して動作させ、かつ定めら
れた画像データでバッファの取り出しを終了し、読み込
みスレッドの実行優先度を次いで高くして、動画である
入力画像信号を転送するようにした。

【００１０】また更に、画像送信源装置は装置に接続さ
れた画像符号化装置とし、画像受信装置は網に接続され
たビデオサーバとし、読み込みスレッドの実行優先度を
最も高くして、この読み込みスレッドに対する動作要求
コードがある場合は、他に優先して動作させ、かつ定め
られた画像データからバッファの取り出しを行い、書き
込みスレッドの実行優先度を次いで高くして、動画であ
る入力画像信号を転送するようにした。

【００１１】

【発明の実施の形態】実施の形態１．一般的に従来のク
ライアント（ＰＣ）で再生可能な動画は、転送レートが
６Ｍｂｐｓ程度までのものであり、ＰＣ上の拡張ボード
により復号するものが主流である。本発明は、これまで
のようにＰＣ上で表示可能な動画データを復号するので
はなく、従来のクライアントとは別の、高精細動画用の
符号化装置、復号装置を接続して、キーボードや他のプ
ログラムからストリーム制御が可能なブリッジ制御クラ
イアントに関するものである。この新らしいクライアン
トを併用して、デジタル化された２０Ｍｂｐｓ以上の高
精細動画の再生、登録、一時停止、その解除や停止が行
えるマルチメディアサーバ・システムを得る。本実施の
形態のクライアントは、こうした高精細度用のブリッジ
制御クライアントについて説明する。以下、この発明の
実施の形態１におけるクライアント装置を図について説
明する。図１はマルチメディアサーバ・システムのハー
ドウエア構成図である。図において、１はビデオサー
バ、２はスイッチと呼ばれるネットワークの接続機器、
３は動画を復号する手段を搭載した従来のクライアン
ト、４は本発明に係る装置であり、動画を復号または復
号化する手段は持たないでストリーム制御をもっぱら行
うブリッジ制御クライアントである。５は広帯域動画を
復号する復号装置（デコーダ）、６は広帯域動画を符号
化する符号化装置（エンコーダ）、２はビデオサーバで
ある。なお、図１において、ビデオサーバ及び従来のク
ライアント、ブリッジ制御クライアントは何台接続され
ていても良く、各クライアントとビデオサーバが相互に
通信できればネットワークはどのように接続されていて
も構わない。また、ブリッジ制御クライアント４には、
符号化装置、復号装置と通信可能で、リアルタイム送受
信可能な拡張ボード、例えばＡＴＭボードを備えてい
る。また、ネットワークでは画像データはＡＴＭセルで
分割されてそのタイミングでクライアントに入力、また
はクライアントから出力されているものとする。

【００１２】図２は、ブリッジ制御クライアントを使用
した場合に、広帯域動画を再生した時の、入力画像信号
を中継受信して出力画像信号として復号装置に出力する
までの広帯域動画データの流れと、介在するプログラム
の構成を示す図である。図中、太い四角はデータを記憶
するバッファメモリを示し、丸は並列に動作するプログ
ラムの単位を示し、波線の四角はプログラムを示し、い
ずれかのスレッドの一部として動作する。また太い矢印
は画像データの流れを示し、細い矢印は制御の流れや制
御を行うために変更または参照を行う制御コードの流れ
を示す。図において、２１はブリッジ制御クライアント
の動作環境の条件を示す動作環境設定テーブルであり、
ブリッジ制御プログラム起動時にこの値がメモリ上に展
開される。２２はクライアントの図示しないキーボード
または相当するアプリケーションプログラムから入力さ
れた広帯域動画ファイルの選択、その再生、停止、一時
停止といった制御命令を送るモジュールで、ストリーム
制御モジュールと呼ぶ。２３はストリーム制御モジュー
ルから送付されるコマンドを受け付けるコマンド受信用
スレッドである。２９はコマンド受信スレッドが受信し
たコマンドを示すフラグを書き込むための受信コマンド
テーブルを記憶するコマンドテーブル・メモリである。
２４はビデオサーバから配信された広帯域動画データを
受信して書き込む入力バッファであり、装置とは非同期
に書き込まれ、この書き込まれたデータが入力データと
なる。

【００１３】ビデオサーバは通常、単位時間当たりのデ
ータ送信量に遅延が発生することがあるので、それを補
うために再生レートよりも速くデータを送信する。一
方、ネットワーク中の上述の遅延があるので入力データ
の到着は変動し、これをデータ送信の揺らぎと呼ぶ。２
６はこういった入力２４の影響による変動を吸収し、出
力が常に復号装置側で要求される速度で画像データを出
力できるようにする揺らぎ吸収バッファである。更に詳
細に云えば、再生前にこのバッファにデータを貯えるこ
とで広帯域動画データのデコーダへの円滑な送信開始が
可能となる。

【００１４】２５は読み込み専用のスレッドであり、入
力バッファ２４から入力されるデータを揺らぎ吸収バッ
ファ２６へ格納する。２７は書き込み専用スレッドであ
り、揺らぎ吸収バッファ２６に格納されたデータを出力
バッファ２８へ送信する。コマンド受信用スレッド２
３、読み込み専用スレッド２５、書き込み専用スレッド
２７をそれぞれ独立したスレッドで動作させ、それぞれ
のプライオリティを最適に段階付けることによって、ス
トリーム制御モジュール２２からのコマンド入力が可能
であって、しかもこれらのコマンドが画面に影響を与え
ず、広帯域動画データ入力または広帯域動画データ出力
が円滑に動作可能になっている。また、コマンド受信用
スレッド２３は、優先度は低いが、読み込み専用スレッ
ド２５および書き込み専用スレッド２７の各動作ステッ
プ中にこのコマンド受信用スレッドを読みに行くステッ
プを設けて、制御することによって、実際のストリーム
制御を行う。２８は出力バッファであり、書き込みスレ
ッド２７によって揺らぎ吸収バッファ中から設定量だけ
取り出された出力画像データが記憶される。即ちこのデ
ータがストリーム制御モジュール２２の制御により結果
として出力される広帯域動画データであり、Ｈ／Ｗへ出
力されることになる。ここで、Ｈ／Ｗへ出力するドライ
バは、復号装置５へ出力可能なインターフェースを持つ
拡張ボードのためのドライバであればどんなものでもよ
いが、この拡張ボードは２０Ｍｂｐｓ以上の広帯域動画
のリアルタイム送信能力が必要である。書き込み専用ス
レッド２７は最優先で動作を行うため、読み込み専用ス
レッド２５よりもタスク実行の優先度が高くしており、
読み込み専用スレッド２５はコマンド受信スレッド２３
よりもタスク実行の優先度を高くしている。

【００１５】図３は、ブリッジ制御クライアントを使用
した場合に、広帯域動画を登録またはビデオサーバに蓄
積する時の、入力画像信号を中継受信して出力画像信号
としてビデオサーバに出力するまでの広帯域動画データ
の流れと介在するプログラムの構成を示す図である。２
１、２２、２３は、図２に示したものと同じものであ
る。３４はエンコーダと接続してそのデータを受けるバ
ッファであって、Ｈ／Ｗ（拡張ボード）を制御するため
のドライバによってエンコーダで生成された広帯域動画
データが入力される。エンコーダはリアルタイムにデー
タ生成をつづけているが、クライアントのコンピュータ
のＳ／Ｗ制御による処理能力には限界がある。ＭＰＥＧ
２−ＴＳ ２０Ｍｂｐｓの広帯域動画をＭＰＥＧ ｏｖ
ｅｒ ＡＴＭで受信しようとした場合、３７６バイト単
位での受信となりコンピュータ上では毎秒６６５０回程
度の割り込み処理が必要となる。データがこのように細
かい単位で送付されるため、これを数キロバイトのデー
タにまとめてコンピュータ上で制御し易くする必要があ
り、この処理をＭＰＥＧ ｏｖｅｒ ＡＴＭ受信スレッ
ド３２が行う。そしてまとめたデータはＭＰＥＧ ｏｖ
ｅｒ ＡＴＭ受信バッファ３３に格納する。また、例え
ば、コンピュータ上でスワップなどのディスクＩ／Ｏを
伴うシステム動作が発生すると、バッファへの書き込み
に遅延が発生することもある。この遅延に基づく動作を
ビデオサーバからのネットワーク経由の受信時の揺らぎ
と同等に考え、常に出力バッファ３９のための出力用画
像データ書き込みができるようにするための揺らぎ吸収
バッファ３６を設ける。

【００１６】３５は読み込み専用スレッドであり、エン
コーダから入力されてＡＴＭ受信バッファにあるデータ
を読み込み、揺らぎ吸収バッファ３６へと格納する。３
７は書き込み専用スレッドであり、揺らぎ吸収バッファ
３６に格納されたデータを出力バッファ３９出力へ書き
込み、網を経由してビデオサーバ１に送信、蓄積する。
コマンド受信用スレッド２３、読み込み専用スレッド３
５、書き込み専用スレッド３７をそれぞれ独立したスレ
ッドで動作させ、それぞれの優先度を段階付けることに
よって、ストリーム制御モジュール２３を経たコマンド
入力が可能であって、しかもこれらのコマンドが画面に
影響を与えず、広帯域動画データ入力または広帯域動画
データ出力が同時に動作可能になっている。

【００１７】この時、エンコーダからの受信データの損
失がないように、ＭＰＥＧ ｏｖｅｒ ＡＴＭ受信スレ
ッドはＯＳが正常に動作する範囲で最高位のプライオリ
ティとし、常にＭＰＥＧ ｏｖｅｒ ＡＴＭ受信バッフ
ァへの書き込み処理を行い、読み込み専用スレッド３５
の動作開始に備える。また、優先度は低くても、コマン
ド受信用スレッド２３は、受信したコマンドを受信コマ
ンドテーブル２９に書き込み、優先度の高い読み込み専
用スレッド３５および書き込み専用スレッド３７は定期
的にこの受信コマンドテーブル２９を確認することでス
トリーム制御を行う。同一クライアント上のアプリケー
ションなどによる影響を抑えるために、読み込み専用ス
レッド３５は書き込み専用スレッド３７よりもタスク実
行の優先度を高くし、書き込み専用スレッド３７は、コ
マンド受信スレッド２３よりもタスク実行の優先度を高
くし、ＭＰＥＧ ｏｖｅｒ ＡＴＭ受信スレッドは、こ
れらのどれよりも高い優先度とする。この優先度設定に
よって、よりリアルタイム動作が要求される読み込み専
用スレッド３５は、最優先で動作し、書き込み専用スレ
ッド３７およびコマンド受信スレッド２３は、読み込み
専用スレッド３５の動作の合間に処理を行う。

【００１８】３４は、入力バッファで、Ｈ／Ｗから広帯
域動画データを入力するドライバによってそのデータが
読み込まれる。ここで、Ｈ／Ｗから入力するドライバ
は、符号化装置６から入力可能なインターフェースを持
つ拡張ボードのドライバであればどんなものでもよい
が、この拡張ボードは２０Ｍｂｐｓ以上の広帯域動画の
リアルタイム受信能力が必要である。３８は書き込み専
用スレッド３７の一部として動作する整合性管理プログ
ラムであり、登録（蓄積）開始時、登録（蓄積）停止時
のタイミングで揺らぎ吸収バッファ３６を経て広帯域動
画データを出力する直前にデータの内容をチェックし、
登録開始時は動画として再生可能な単位の先頭から出力
バッファ３９にデータを送付し、登録停止時は動画とし
て再生可能な単位の末尾まででデータ送付を終了する、
一種のフィルタの役割を果たす。このことは、登録時の
データの無駄を無くして、再生時における再生命令受信
から実際の画像出力までの時間を短縮する。ここで、動
画として再生可能な単位とは、ランダムアクセスや動画
編集可能な単位を示し、例えばＭＰＥＧと呼ばれる圧縮
方式では、株式会社アスキー発行「ポイント図解式最新
ＭＰＥＧ教科書」の９８ページにあるようなＧＯＰと呼
ばれる単位を示す。なお、図２および図３において、本
実施の形態では同一のプロセスで実行を行うため、２
１、２２、２３は同一のテーブル、モジュール、スレッ
ドを示す。

【００１９】図９は、図２、図３に示すプログラムに基
づいて各図のバッファ間におけるデータの転送状態を説
明する図である。図において、左端の要素名と転送時に
おけるデータの流れは図２、図３における同じ名称と対
応している。図２におけるデータの転送単位は、サーバ
１からは約６５ｋバイトづつ５回または５０回リード
し、読み込み専用スレッド２５は、入力バッファ２４か
ら揺らぎ吸収バッファ２６へは例えば約６５ｋバイト単
位でリード２５ｂする。揺らぎ吸収バッファは例えば少
くとも約３３０ｋバイト、場合により約３．３Ｍバイト
の容量を持ち、一巡してオーバーライトする構成として
いる。予め揺らぎ吸収量だけ先にリードしていたデータ
を、書き込み専用スレッド２７は約１１ｋバイト単位で
出力バッファ２８に転送２７ｂする。この出力バッファ
２８に書き込まれたデータは、例えば３７６バイト単位
で復号装置５へ出力される。図３におけるデータの転送
単位も同様に説明される。即ち、符号化装置６からのデ
ータは３７６バイト単位で入力バッファ３４に取り込ま
れ、ＭＰＥＧｏｖｅｒＡＴＭ受信スレッド３２がＭＰＥ
ＧｏｖｅｒＡＴＭ受信バッファ３３に約３７６バイト単
位で転送３２ｂする。読み込み専用スレッド３５は、Ｍ
ＰＥＧｏｖｅｒＡＴＭ受信バッファ３３があふれない周
期で揺らぎ吸収バッファ３６に例えば約１１ｋバイト単
位で転送３５ｂする。予め揺らぎ吸収量だけ先にリード
していたデータを、書き込み専用スレッド３７は約６５
ｋバイト単位で、必要により整合性管理プログラム３８
を経由して、出力バッファ３９に転送３７ｂする。この
出力バッファ３９に書き込まれたデータは、網２の運用
規約に従ってサーバ１へ出力される。

【００２０】図４は、動作環境テーブル２１の内容の例
を示す図であり、登録（蓄積）時も、再生時も共通であ
る。図において、４１は広帯域動画の転送レートを指定
する欄であり、ファイルに指定された転送レートを読み
取り起動時にセットする。４２はエンコーダと接続する
Ｈ／Ｗ用入力のドライバからの１回のデータ読み込みサ
イズの欄であり、４３はそのサイズでの読み込み回数を
示す欄であり、登録時には少くとも入力サイズ＊入力回
数および出力サイズ＊出力回数の容量が揺らぎ吸収バッ
ファのサイズとなる。４４は、エンコーダと接続するＨ
／Ｗ用入力ドライバを示すコンピュータ上の識別名の欄
である。４５はデコーダと接続するＨ／Ｗ用出力ドライ
バへのデータ出力サイズの欄であり、４６はそのサイズ
での書き込み回数を示す欄であり、再生時には少くとも
出力サイズ＊出力回数および入力サイズ＊入力回数の容
量が揺らぎ吸収バッファのサイズとなる。４７はデコー
ダと接続するＨ／Ｗ用出力ドライバを示すコンピュータ
上の識別名の欄である。

【００２１】図５はコマンド受信用スレッド２３がコマ
ンドの種類に応じて書き込みを行う受信コマンドテーブ
ル２９の例を示す図である。コマンド受信スレッド２３
がストリーム制御用モジュール２２からコマンドを受信
すると、受信したコマンドに応じて受信コマンドテーブ
ル２９のフラグをＯＮにする。再生時の読み込み専用ス
レッド２５及び書き込み専用スレッド２７、登録時の読
み込み専用スレッド３５および書き込み専用スレッド３
７は、定期的にこの受信コマンドテーブルを参照して動
作を行う。各スレッドは各設定された優先度で処理を実
行しているが、それらの区切りでこのコマンドを調べる
ので画面表示がこれらのコマンドで乱されることがな
い。

【００２２】図６から図８は、ビデオサーバ１からデコ
ーダ５への再生時の処理の流れを示すフローチャートで
あり、図６はコマンド受信スレッド、図７は読み込み専
用スレッド、図８は書き込み専用スレッドの処理を示
す。

【００２３】次にこれらの図を用いて本実施の形態にお
けるブリッジ制御クライアント装置の再生時の動作を説
明する。図６は、ストリーム制御用モジュール２２から
の命令コードを受け付けるコマンド受信用スレッドの動
作フローチャートである。まず、ステップ（以降ステッ
プの呼称は省略する）Ｓ１０１でコマンド受信スレッド
が起動されると、図４に示したテーブルに設定された初
期値データを不揮発性の記憶媒体、例えばハードディス
ク等から読み込んでメモリ上にコピーする。その後、Ｓ
１０２でコマンド受信待ちの状態になり、その後、受信
したコマンドに応じて処理を行う。

【００２４】この状態でコマンドが受信されると、その
コマンドに応じた処理を行う。オープン要求ならばＳ１
０４、再生要求ならばＳ１０６、停止要求ならばＳ１１
１、一時停止要求ならばＳ１１４、一時停止の解除要求
ならばＳ１１６、クローズ要求ならばＳ１１９でそれぞ
れ要求に応じた処理を行う。それ以外はエラーとし、Ｓ
１１８を経てエラー処理を行う。なお、これ以外のコマ
ンドを実現する場合には、Ｓ１１５とＳ１１７の間に対
応する調査ステップと処理ステップを挿入することによ
り、必要に応じて増設可能である。例えば、再生位置の
変更を行うシークと呼ばれるコマンドがあるが、これは
停止要求を実行した後にファイルポインタを移動する。
この際、バッファに既に読み込まれたものは出力に達し
ていないため廃棄し、そのバッファの分を内部的に考慮
した上でファイルポインタの移動を行う。

【００２５】次にそれぞれのコマンド要求に対する処理
に関して簡単に説明する。Ｓ１０４はオープンコマンド
が要求された時のオープン処理である。この処理では、
ビデオサーバからの広帯域動画の再生対象であるファイ
ルのオープン、出力用ドライバのオープン、読み込み専
用スレッドの生成、書き込み専用スレッドの生成を行
う。なお、オープンした再生対象ファイルおよびドライ
バの識別子はどのスレッドからも参照可能な領域に確保
する。また、再生要求であるため、よりリアルタイム性
が要求される書き込み専用スレッドは読み込み専用スレ
ッドよりも高い優先度に設定し、読み込み専用スレッド
は、コマンド受信スレッドよりも高い優先度に設定す
る。

【００２６】Ｓ１０６は再生要求がなされたときの再生
処理である。再生フラグをセットして、停止フラグまた
は一時停止フラグがセットされている場合はそれらをリ
セットする。これにより、読み込み専用スレッド、書き
込み専用スレッドの待ちが解除され、処理が開始され
る。なお、本実施の形態でフラグとしている部分は、待
ちを行うものに関してはＯＳなどで用意されているいわ
ゆるセマフォなどの同期オブジェクトを使用した方がよ
い。

【００２７】Ｓ１０８〜Ｓ１１１は、停止要求コマンド
実行時の処理である。まず、Ｓ１０８で現在停止中かど
うか確認する停止中ならば何もせずにＳ１０２コマンド
待ちに戻る。次にＳ１０９で現在一時停止中かどうか確
認する。一時停止中ならばＳ１１０で一時停止フラグを
リセットする。次にＳ１０９において一時停止中である
か否かにか関わらず、停止フラグをセットして停止する
ために現在バッファリングされている広帯域データの廃
棄処理などの停止処理を行う。

【００２８】Ｓ１１３、Ｓ１１４は、一時停止要求コマ
ンド実行時の処理である。Ｓ１１３で現在再生中かどう
か確認する。再生中であった場合のみＳ１１４で一時停
止フラグをセットする。これにより、書き込み専用スレ
ッドが停止し、揺らぎ吸収バッファが一杯に充填される
と読み込み専用スレッドもバッファの空き待ちで停止す
る。再生中でなければＳ１０２のコマンド待ちに戻る。
本実施例では停止状態での一時停止は無効と定義してい
るが、停止状態での一時停止要求をバッファ充填と考え
て処理してもよい。状態遷移の都合による処理はどのよ
うに実装してもかまわない。

【００２９】Ｓ１１６は、一時停止の解除要求コマンド
実行時の処理である。一時停止フラグをリセットする処
理を行う。これにより、書き込み専用スレッドが処理を
開始し、揺らぎ吸収バッファの空き領域ができ、したが
って読み込み専用スレッドのバッファ空き待ちが解除さ
れ、読み込み専用スレッドも処理を再開する。

【００３０】Ｓ１１８は、該当するコマンドが無かった
場合の処理である。この場合、内部的な動作は一切せ
ず、ストリーム制御モジュールにエラーステータスを返
却するのみである。なお、処理の一貫性を保つため、全
てのコマンドはその処理の正常／異常に関わらずステー
タスを返却する。

【００３１】Ｓ１１９は、再生対象ファイルのクローズ
要求に対する処理である。オープン処理と逆に再生対象
ファイルのクローズ、ドライバの終了、読み込み専用ス
レッドの抹消、書き込み専用スレッドの抹消を行う。こ
の際、読み込み専用スレッド、書き込み専用スレッドの
自発的な消滅を促すため、クローズフラグをセットす
る。一定時間内に読み込み専用スレッドおよび書き込み
専用スレッドが終了しない場合は、コマンド受信スレッ
ドより強制終了を行う。

【００３２】次に、図７に関して説明する。図７は、読
み込み専用スレッドの動作を示すフローチャートであ
る。読み込み専用スレッドの生成は、上述した通りコマ
ンド受信スレッドによってなされる。Ｓ２０１で、まず
予めコマンド受信スレッドがオープンしたファイル識別
子を得て、Ｓ２０２で停止フラグまたはＥＯＦフラグの
リセット待ちに入る。ここで、ＥＯＦフラグとは、読み
込み専用スレッドが再生対象ファイルを最後まで読み込
んだことを自ら検出し、読み込み専用スレッド自らを停
止させるためのものである。本実施の形態ではＥＯＦフ
ラグをリセットする処理は発生していないが、例えば再
生位置変更要求コマンドを実装した場合には、そのコマ
ンドの処理の中でＥＯＦフラグをリセットする必要があ
る。Ｓ２０２において、停止フラグまたはＥＯＦフラグ
が既にリセットされていれば、読み込みを開始する。こ
こで、映像の再生においてはプリロードと呼ばれる処理
がある。これは、予め揺らぎ吸収バッファをデータで一
杯にしておいて揺らぎを吸収可能な状態で待ちに入ると
いう処理である。具体的には、コマンド受信スレッドか
ら明示的にプリロード量を指定して実行してもよいし、
ここでバッファが一杯になるまで読み込みを行ってもよ
い。

【００３３】再生が開始されると、次にＳ２０３で読み
込みバッファの確認を行う。ここで、バッファとして
は、１つのバッファを使用してもよいし、２つ以上のバ
ッファを用いても構わない。本実施の形態では、出力サ
イズと出力回数をベースとした２つのバッファをスイッ
チする処理を行っている。なお、バッファに空き領域が
無い場合には、書き込み専用スレッドによりバッファの
内容が読み出され、空き領域ができるまで待ちに入る。

【００３４】バッファの空き領域が発生すると、Ｓ２０
５で再生対象ファイルからデータを読み込み、バッファ
の空いた領域に次々と書き込んでいく。Ｓ２０６で再生
対象ファイルの終端まで読み込んだかどうか確認し、再
生対象ファイルの終端であった場合、Ｓ２０７でＥＯＦ
フラグをセットし、Ｓ２０２で停止する。

【００３５】Ｓ２０８で、クローズフラグがセットされ
ているか否か確認し、セットされている場合自発的にス
レッドを終了する。

【００３６】次に、図８に関して説明する。図８は、再
生時における書き込み専用スレッドの動作を示すフロー
チャートである。書き込み専用スレッドの生成は、上述
した通りコマンド受信スレッドによってなされる。Ｓ３
０１で、まず予めコマンド受信スレッドがオープンした
ドライバ識別子を得て、Ｓ３０２で再生フラグのセット
待ちに入る。これらのフラグが既にセットされていれ
ば、書き込みを開始する。

【００３７】再生が開始されると次にＳ３０３で読み込
み専用スレッドによって読み込み済みのバッファの確認
を行う。本実施の形態では、出力サイズと出力回数をベ
ースとしたサイズの２つのバッファをスイッチする処理
を行っている。なお、バッファに空き領域が無い場合に
は、Ｓ３０４で読み込み待ちに入るが、待ち時間によっ
ては画像の停止を意味するため、本待ち処理は行わない
設定とするのが望ましい。例えば、本実施の形態では書
き込みをリアルタイムに行い、読み込みはその合間に行
うようにして、データが常にバッファ内に存在するよう
にしている。すなわち、書き込みで転送レートの調整を
行い、空いた時間でできる限り読み込みを行う。

【００３８】Ｓ３０５で、揺らぎ吸収バッファから予め
指定された出力サイズ、出力回数で画像データを出力す
る。このリアルタイム出力を行うドライバは、ＯＳの一
部として組み込まれたドライバとみなされるのでシステ
ムによって取り扱えるメモリ領域に限界があるためであ
る。Ｓ３０６で一時停止フラグがセットされているか否
か確認し、セットされていれば出力を停止し、Ｓ３０２
で一時停止フラグのリセット待ちの状態で停止する。Ｓ
３０７で停止フラグがセットされているか否か確認し、
セットされていれば出力を停止し、Ｓ３０２で停止フラ
グのリセット待ちの状態で停止する。

【００３９】Ｓ３０８で、クローズフラグがセットされ
ているか否か確認し、セットされている場合は、スレッ
ドを終了する。エンコーダから例えばビデオサーバへの
画像データの蓄積または他のブリッジ制御クライアント
装置への配信時の動作については、上述の再生動作と略
同様であるので詳細記述は省略する。システム構成とし
ては従来システムの改良であるため、従来クライアント
上で表示してきた動画も従来通りそのクライアントでは
表示でき、同一のシステムに接続して高精度動画もブリ
ッジ制御クライアント経由で再生が可能である。

【００４０】

【発明の効果】以上のようにこの発明によれば、ブリッ
ジ制御クライアント装置として揺らぎ吸収バッファと、
異なる優先度で並行して動作するコマンド受信スレッ
ド、読み込みスレッド、書き込みスレッドを設けたの
で、このブリッジ制御クライアント装置を経由してビデ
オサーバからＨＤＴＶ対応の高精細な２０Ｍｂｐｓ以上
の広帯域動画の配信ができる効果がある。またクライア
ント上のツールやアプリケーションによって、その広帯
域動画のストリーム制御ができる効果がある。さらに、
登録時に関しても同様にストリーム制御が可能であり、
登録の際には動画として再生できない不必要なデータを
取り込まないのでコマンド実行から画像表示までの時間
を短縮したり、ハードディスクの使用効率を向上する効
果もある。

【図面の簡単な説明】

【図１】 この発明の実施の形態におけるマルチメディ
アサーバ・システムのハードウエア構成図である。

【図２】 この発明の実施の形態１におけるブリッジ制
御クライアント装置の再生時のデータの流れとプログラ
ムの構成を示す図である。

【図３】 この発明の実施の形態１におけるブリッジ制
御クライアント装置の登録（蓄積）時のデータの流れと
プログラムの構成を示す図である。

【図４】 実施の形態１におけるブリッジ制御クライア
ント装置が設定する動作環境テーブルの例を示す図であ
る。

【図５】 実施の形態１におけるブリッジ制御クライア
ント装置が設定する受信コマンドテーブルの例を示す図
である。

【図６】 実施の形態１におけるブリッジ制御クライア
ント装置が行うコマンド受信スレッドの動作フローチャ
ート図である。

【図７】 実施の形態１におけるブリッジ制御クライア
ント装置が行う読み込み専用スレッドの動作フローチャ
ート図である。

【図８】 実施の形態１におけるブリッジ制御クライア
ント装置が行う書き込み専用スレッドの動作フローチャ
ート図である。

【図９】 この発明におけるブリッジ制御クライアント
装置が行うデータ転送の例を説明する図である。

【図１０】 従来のマルチメディアサーバ・システムの
ハードウエア構成図である。

【符号の説明】

１ ビデオサーバ、２ ネットワーク接続機器、３ 従
来クライアント、４ブリッジ制御クライアント、５ 復
号装置（デコーダ）、６ 符号化装置（エンコーダ）、
２１ 動作環境設定テーブル（初期化情報）、２２ ス
トリーム制御モジュール、２３ コマンド受信用スレッ
ド、２４ 入力バッファ（ビデオサーバからの広帯域動
画データ受信用）、２５ 読み込み専用スレッド、２６
ゆらぎ吸収バッファ、２７ 書き込み専用スレッド、
２８ 出力バッファ（リアルタイムのデータ出力用）、
３４ 入力バッファ（エンコーダからの広帯域動画デー
タのリアルタイム受信用）、３５ 読み込み専用スレッ
ド、３６ ゆらぎ吸収バッファ、３７ 書き込み専用ス
レッド、３８ 整合性管理プログラム、３９ 出力バッ
ファ（出力データの一時格納用）、４１ 広帯域動画フ
ァイルの再生レート記憶欄、４２ ファイル登録時のド
ライバ１回に読み込むサイズを示す欄、４３ ファイル
登録時の読み込み回数を示す欄、４４ ファイル登録時
のエンコーダからのデータ受信ドライバ指定欄、４５
ファイル再生時のドライバに１回に書き込むサイズを示
す欄、４６ ファイル再生時の書き込み回数を示す欄、
４７ファイル再生時のデコーダへのデータ送信ドライバ
指定欄、５１ オープンフラグ欄、５２ 再生フラグ
欄、５３ 登録フラグ欄、５４ 停止フラグ欄、５５一
時停止フラグ欄、５６ クローズフラグ欄、Ｓ２０８
クローズフラグ調査ステップ、Ｓ３０６ 一時停止フラ
グ調査ステップ、Ｓ３０７ 停止フラグ調査ステップ、
Ｓ３０８ クローズフラグ調査ステップ。

Claims (3)

【特許請求の範囲】
1. 【請求項１】 網または装置に接続された画像送信源装
   置からの入力画像信号を中継して、装置または網に接続
   された画像受信装置に転送するために、 揺らぎ吸収バッファと、 画像の蓄積開始または再生、停止を含む命令コードを受
   信するコマンド受信スレッドと、 上記コマンド受信スレッド中の該当コマンドに基づいて
   上記入力画像信号の受信バッファから第１の所定のタイ
   ミングで第１の設定量の画像データを取り出し上記バッ
   ファに読み込み、かつステップ中に上記受信スレッド中
   のコマンドを調べるステップを設けた読み込みスレッド
   と、 上記コマンド受信スレッド中の該当コマンドに基づいて
   上記バッファから第２の所定のタイミングで第２の設定
   量の画像データを取り出して上記出力画像信号の送信バ
   ッファに書き込み、かつステップ中に上記受信スレッド
   中のコマンドを調べるステップを設けた書き込みスレッ
   ドとを備えて、上記読み込みスレッドまたは書き込みス
   レッドの実行優先度を最も高くしたブリッジ制御クライ
   アント装置。
2. 【請求項２】 画像送信源装置は網に接続されたビデオ
   サーバとし、画像受信装置は装置に接続された画像復号
   装置とし、 書き込みスレッドの実行優先度を最も高くして、該書き
   込みスレッドに対する動作要求コードがある場合は、他
   に優先して動作させ、かつ定められた画像データでバッ
   ファの取り出しを終了し、 読み込みスレッドの実行優先度を次いで高くして、動画
   である入力画像信号を転送するようにしたことを特徴と
   する請求項１記載のブリッジ制御クライアント装置。
3. 【請求項３】 画像送信源装置は装置に接続された画像
   符号化装置とし、画像受信装置は網に接続されたビデオ
   サーバとし、 読み込みスレッドの実行優先度を最も高くして、該読み
   込みスレッドに対する動作要求コードがある場合は、他
   に優先して動作させ、かつ定められた画像データからバ
   ッファの取り出しを行い、 書き込みスレッドの実行優先度を次いで高くして、動画
   である入力画像信号を転送するようにしたことを特徴と
   する請求項１記載のブリッジ制御クライアント装置。