JP4366770B2 - データ再生装置及び方法、並びにデータ通信システム - Google Patents
データ再生装置及び方法、並びにデータ通信システム Download PDFInfo
- Publication number
- JP4366770B2 JP4366770B2 JP22862799A JP22862799A JP4366770B2 JP 4366770 B2 JP4366770 B2 JP 4366770B2 JP 22862799 A JP22862799 A JP 22862799A JP 22862799 A JP22862799 A JP 22862799A JP 4366770 B2 JP4366770 B2 JP 4366770B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- transmission side
- transmitted
- time length
- transmission
- 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
- Television Signal Processing For Recording (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、送信側からネットワークを介して送信されてくるデータを、通信に伴う遅延の影響を気にすることなく、あたかも手元で再生するのと同様の感覚で再生できるデータ再生装置及び方法、並びにデータ通信システムに関する。
【０００２】
【従来の技術】
例えば、映像再生システムを構成する、ＶＴＲ１０１は、本来図１７に示すように、操作卓或いはコントロールパネル等と呼ばれる操作装置１０２からの制御信号Scに従って動作し、映像信号Vをモニタ１０３に出力する。このシステムでは、ＶＴＲ１０１、操作装置１０２、モニタ１０３は、制御信号Scや映像信号Vの伝送規格を満たす程に、互いに近くに設置されている。
【０００３】
【発明が解決しようとする課題】
これに対して図１８に示すように、ＶＴＲ１０１が操作装置１０２やモニタ１０３から遠く離れた、遠隔の場所に設置され、コンピュータネットワーク１０５を介して接続された映像送受信システムの場合には、コンピュータネットワーク１０５で生じる遅延等による、動作精度やタイミング等への影響を考慮しなくてはならなかった。
【０００４】
以下、この課題を詳細に説明する。
【０００５】
ＶＴＲ１０１側をリモート側とし、操作装置１０２側をローカル側とする。ローカル側にはＩ／Ｆ(2)１０６が設けられ、操作装置１０２からの制御信号Scを例えばTCP/IP等のような何らかの形式でコンピュータネットワーク１０５に送信すると共に、コンピュータネットワーク１０５から例えばUDP/IP等のような何らかの形式で映像信号を受信してモニタ１０３に出力する。また、リモート側にはＩ／Ｆ(1)１０４が設けられ、コンピュータネットワーク１０５から何らかの形式で制御信号を受信してＶＴＲ１０１に送ると共に、ＶＴＲ１０１からの映像信号Vをコンピュータネットワーク１０５に何らかの形式で送信する。コンピュータネットワーク１０５は、ギガビットイーサネットやATM等が考えられ、QoS(Quality of Service)が保証されているものが望ましい。
【０００６】
この図１８のシステムで注意しなければならないことは、コンピュータネットワーク１０５には遅延があり、映像信号Vや制御信号Scの時間精度と比べて無視できないということである。コンピュータネットワーク１０５の遅延は、条件が良くても10msec程度は覚悟しなくてはならない。しかし、放送用や業務用のＶＴＲはフレーム(NTSC方式では33msec、PAL方式では25msec)やフィールド(0.5フレーム)単位の時間精度で動作しているので、10msecもの遅延は無視できない。特に業務用ＶＴＲの制御プロトコルである9PINプロトコルでは、制御に対する応答を9msec以内に返さなくてはならないため、10msecもの遅延があると通信そのものが成立しない。
【０００７】
そのため、単純にローカル側の制御信号をネットワーク１０５を介してそのままリモート側に転送し、リモート側の映像信号をネットワーク１０５を介してそのままローカル側に転送するような方法では、ＶＴＲ１０１の動作精度や応答性等に問題が生じてしまう。放送用・業務用などで正確な動作精度やタイミングが要求される用途には、コンピュータネットワーク等を介して遠隔地にある映像機器の映像情報をリアルタイムに利用することは難しく、そのことを特別に配慮して使わなくてはならない。
【０００８】
本発明は、上記実情に鑑みてなされたものであり、遠隔地にある映像機器を、コンピュータネットワーク等の通信回線を用いて、あたかも近くにあるように利用させることのできるデータ再生装置及び方法、並びにデータ通信システムの提供を目的とする。
【０００９】
【発明を解決するための手段】
本発明に係るデータ再生装置は、上記課題を解決するために、送信側からネットワークを介して送信されるデータを受信する通信手段と、上記通信手段で受信したデータを内容順序にしたがって一時的に蓄積部に蓄積すると共に該蓄積部に蓄積されたデータを所望の再生位置から出力する受信側データ再生手段と、上記蓄積部に蓄積されたデータの内容順序の終端から逆方向にα時間長分からなる順方向連続性補償データ範囲に上記再生位置が達したとき、上記通信手段を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求し、上記送信側から送信されたデータを上記蓄積部に内容順序にしたがって蓄積させ、上記蓄積部に蓄積されたデータの内容順序の始端から順方向にβ時間長分からなる逆方向連続性補償データ範囲に上記再生位置が達したとき、上記通信手段を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求し、上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させる制御手段とを備え、上記制御手段は、上記αを、上記通信手段を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求してから上記送信側から送信されたデータにより上記蓄積部を更新し始めるまでに掛かる時間以上として上記順方向連続性補償データ範囲を設定し、上記βを、上記通信手段を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求してから上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させるまでに掛かる時間以上として上記逆方向連続性補償データ範囲を設定し、上記蓄積部に少なくとも（α＋３β）時間長分のデータを蓄積させることを特徴とする。
【００１１】
また、本発明に係るデータ再生方法は、上記課題を解決するために、送信側からネットワークを介して送信されてくるデータを通信部で受信する工程と、上記データを内容順序にしたがって少なくとも（α＋３β）時間長分のデータを一時的に蓄積部に蓄積すると共に該蓄積部に蓄積されたデータを所望の再生位置から出力する受信側データ再生工程とを備え、上記受信側データ再生工程では、上記蓄積部に蓄積されたデータの内容順序の終端から逆方向にα時間長分からなる順方向連続性補償データ範囲に上記再生位置が達したとき、上記通信部を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求し、上記送信側から送信されたデータを上記蓄積部に内容順序にしたがって蓄積させ、上記蓄積部に蓄積されたデータの内容順序の始端から順方向にβ時間長分からなる逆方向連続性補償データ範囲に上記再生位置が達したとき、上記通信部を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求し、上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させ、上記αは、上記通信部を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求してから上記送信側から送信されたデータにより上記蓄積部を更新し始めるまでに掛かる時間以上であり、上記βは、上記通信部を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求してから上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させるまでに掛かる時間以上であることを特徴とする。
【００１３】
また、本発明に係るデータ通信システムは、ネットワークを介してデータ送信手段から送信されるデータを受信して再生するデータ通信システムであって、上記ネットワークを介して送信されてくるデータを受信して再生するデータ受信手段側に、送信側からネットワークを介して送信されるデータを受信する通信手段と、上記通信手段で受信したデータを内容順序にしたがって一時的に蓄積部に蓄積すると共に該蓄積部に蓄積されたデータを所望の再生位置から出力する受信側データ再生手段と、上記蓄積部に蓄積されたデータの内容順序の終端から逆方向にα時間長分からなる順方向連続性補償データ範囲に上記再生位置が達したとき、上記通信手段を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求し、上記送信側から送信されたデータを上記蓄積部に内容順序にしたがって蓄積させ、上記蓄積部に蓄積されたデータの内容順序の始端から順方向にβ時間長分からなる逆方向連続性補償データ範囲に上記再生位置が達したとき、上記通信手段を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求し、上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させる制御手段とを備え、上記制御手段は、上記αを、上記通信手段を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求してから上記送信側から送信されたデータにより上記蓄積部を更新し始めるまでに掛かる時間以上として上記順方向連続性補償データ範囲を設定し、上記βを、上記通信手段を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求してから上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させるまでに掛かる時間以上として上記逆方向連続性補償データ範囲を設定し、上記蓄積部に少なくとも（α＋３β）時間長分のデータを蓄積させることを特徴とする。
【００１４】
具体的には、コンピュータネットワーク等を介してVTR等の映像機器を利用する際に、映像信号や制御信号を単純にコンピュータネットワークを介してそのままやり取りするのではなく、手元に仮想的な映像機器を設けることで、コンピュータネットワークで生じる遅延等による動作の精度やタイミング等の狂いを抑える。
【００１５】
また、 仮想的な映像機器は、コンピュータネットワーク越しにある本物の映像機器から、コンピュータネットワークを介して当座に必要な映像信号を取得し、一時記憶しておくので、映像機器の使用者に対しては、仮想的な映像機器自身が本物の映像機器のようにふるまい、映像機器として正しい反応をすることで、使用者にコンピュータネットワークを介していることを意識させない。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照しながら説明する。図１にはデータ通信システムの具体例である映像データ通信システム１の概略構成を示す。この映像データ通信システム１はリモート側２とローカル側６がコンピュータネットワーク５によって接続されている。特にローカル側６は本発明のデータ再生装置の具体例となり、本発明のデータ再生方法を実行する映像データ再生装置である。リモート側２は映像データを送信する送信側であり、ローカル側６は映像データを受信する受信側でもある。
【００１７】
送信側であるリモート側２にはビデオテープから映像信号を再生するＶＴＲ３が設けられ、このＶＴＲ３とコンピュータネットワーク５の間にはＩ／Ｆ４が設けられている。Ｉ／Ｆ４はコンピュータネットワーク５から何らかの形式で制御信号SCを受信してＶＴＲ３に送ると共に、ＶＴＲ３からの映像信号Vをコンピュータネットワーク５に何らかの形式で送信する。
【００１８】
Ｉ／Ｆ４の内部構成例を図２に示す。このＩ／Ｆ４は、ＶＴＲ３からのＳＤＩ入力等の映像信号Vを映像入力回路１２で受け、受信映像データDVとし、この受信映像データDVを例えばATMＩ／ＦのようなネットワークＩ／Ｆ１５でコンピュータネットワーク５のフォーマットに変換して送信すると共に、ネットワークＩ／Ｆ１５で受信した受信制御データDCを例えばRS-422Ｉ／Ｆのような制御出力Ｉ／Ｆ１８で制御信号SCに変換してＶＴＲ３に出力する。映像入力回路１２とネットワークＩ／Ｆ１５との間には各種入出力データを内部で扱える形式に変換するデータ変換器１３，１４が設けられている。またネットワークＩ／Ｆ１５と制御出力Ｉ／Ｆ１８との間にも同様のデータ変換器１６，１７が設けられている。
【００１９】
図１において、コンピュータネットワーク５はギガビットイーサネットやATM等が考えられ、QoS(Quality of Service)が保証されているものが望ましい。
【００２０】
受信側であるローカル側６にはリモート側２からコンピュータネットワーク５を介して送信されてくる例えばUDP/IP等のような何らかの形式の映像データDVを受信するネットワークＩ／Ｆ７と、このネットワークＩ／Ｆ７で受信した映像データDVを一時的に蓄積するキャッシュバッファメモリを備えた受信側再生部（仮想ＶＴＲ）８と、この仮想ＶＴＲ８を制御する制御部１０と、仮想ＶＴＲ８からの映像信号SVを出力するモニタ９と、ユーザからの操作信号を受け付け、制御部１０に制御信号SCを送る操作装置１１が備えられている。
【００２１】
仮想ＶＴＲ８は実際にはキャッシュバッファを記録媒体にした再生装置であり、ビデオテープを記録媒体にした一般的なＶＴＲではなく、ローカル側６から見た場合に仮想的にＶＴＲのように動作する。具体的に、この仮想ＶＴＲ８は、リモート側２にあるＶＴＲ３の映像データ(映像信号を作り出すのに必要な情報)の一部をあらかじめキャッシュバッファに一時記憶しておき、操作装置１１からの制御信号SCに応じ制御部１０で生成された制御データDCに対して、あたかもＶＴＲそのもののように振舞ってモニタ９に映像信号SVを出力する。このような仮想ＶＴＲ８というものを用いることで、ローカル側６では、コンピュータネットワーク５の遅延を気にせず、あたかも手元にＶＴＲがあるように使うことができる。また、仮想ＶＴＲ８が映像出力をしている映像素材中の再生位置を、「仮想ヘッド」と呼ぶ。また、リモート側２にある本物のＶＴＲ３を、適宜「実ＶＴＲ３」と記す。
【００２２】
ネットワークＩ／Ｆ７と、仮想ＶＴＲ８と、制御部１０の詳細な構成を図３に示す。コンピュータネットワーク５を介して例えばATMＩ／ＦのようなネットワークＩ／Ｆ７で受信した映像データDVは仮想ＶＴＲ８中のキャッシュバッファ２２の所定の位置に書き込まれる。キャッシバッファ２２に記録されている映像データDVの内、仮想ＶＴＲ８の仮想ヘッドに対応するデータが、映像出力回路２５を経てＳＤＩ出力等の映像信号SVとしてモニタ９に出力される。操作装置１１が接続されている制御部１０は、制御信号SCを例えばRS422Ｉ／Ｆ等の制御入力Ｉ／Ｆ２９で受け取った後、入力制御データDCiとして直接そのままネットワークＩ／Ｆ７に送るのではなく、ＣＰＵ２７に送る。ＣＰＵ２７は入力制御データDCiを解釈して仮想ＶＴＲ８の動作を決定し、キャッシュバッファ２２の更新に必要な実ＶＴＲ３の動作内容を送信制御データDCoとしてネットワークＩ／Ｆ７に出力する。なお、ネットワークＩ／Ｆ７とキャッシュバッファ２２との間には各種入出力データを内部で扱える形式に変換するデータ変換器２０，２１が設けられている。また仮想ＶＴＲ８内部のキャッシュバッファ２２と映像出力回路２５との間にもデータ変換器２３，２４が設けられている。また制御部１０内部の制御入力Ｉ／Ｆ２９とＣＰＵ２７の間にもデータ変換器２８が設けられている。さらにＣＰＵ２７とネットワークＩ／Ｆ７との間にもデータ変換器２６が設けられている。
【００２３】
ローカル側６として説明してきた映像データ再生装置の基本的な原理を以下に説明する。仮想ＶＴＲ８は、仮想ヘッドの前後一定区間の映像データDVを、あらかじめ実ＶＴＲ３からコンピュータネットワーク５経由で取得し、一時的にキャッシュバッファ２２に記憶しておく。操作装置１１から例えばPLAY(通常再生)等の制御信号SCを受けたら、仮想ヘッドに該当する映像信号SVをキャッシュバッファ２２から出力し、仮想ヘッドの位置を進める。仮想ヘッドが、キャッシュバッファ２２中に蓄積されている所定データ範囲から外れる前に、この映像データ再生装置は実ＶＴＲ３にコンピュータネットワーク５経由でPLAYの制御信号を送り、将来必要になる映像データを受け取る。
【００２４】
実ＶＴＲ３から受け取った映像データは、キャッシュバッファ２２のいらなくなった映像データに上書きして記憶される。これによりキャッシュバッファ２２の範囲が更新される。仮想ＶＴＲ８の再生動作がSTOPしたりして、キャッシュバッファ２２に余裕ができたら、実ＶＴＲ３を止める。このような処理を繰り返すことで、仮想ＶＴＲ８をあたかも本物のＶＴＲのように使うことができる。
【００２５】
上記基本的な原理は制御部１０によるキャッシュバッファ管理により実現される。上記所定データ範囲を仮想ＶＴＲ８によるキャッシュバッファ２２を用いたデータ再生の連続性を保つために必要とされる連続性補償データ範囲とすると、この連続性補償データ範囲の一方の端部に仮想ヘッドが達したら、制御部１０はネットワークＩ／Ｆ７、コンピュータネットワーク５を介してリモート側２にデータの送信を要求する。そして、制御部１０はリモート側２から送信されたデータをキャッシュバッファ２２に蓄積させる。
【００２６】
連続性補償データ範囲は、仮想ＶＴＲ８がキャッシュバッファ２２中のデータを順方向再生している場合と、逆方向再生している場合とでは異なる。前者を順方向連続性補償データ範囲、後者を逆方向連続性補償データ範囲とする。この各データ範囲については後述する。
【００２７】
上記キャッシュバッファ管理の具体例を、図４に示すフローチャートにしたがって説明する。先ず、ステップＳ１で制御部１０は実ＶＴＲ３をプレイさせ、キャッシュバッファ２２を映像データで埋めておく。すなわち、仮想ヘッドの前後一定区間の映像データを、コンピュータネットワーク５経由で実ＶＴＲ３から取得し、キャッシュバッファ２２に記憶しておく。そして、キャッシュバッファ２２が必要データ範囲となったらステップＳ２で実ＶＴＲ３をストップさせる。このように、制御部１０はキャッシュバッファ２２に蓄積されるべき必要データ範囲を判別する。
【００２８】
ここで、例えば操作装置１１から通常再生等の制御信号を受けたら、仮想ヘッドに該当する映像信号を出力し、仮想ヘッドの位置を進める。そして、ステップＳ３で仮想ヘッドの位置に余裕があるか否かを判断する。順方向連続性補償データ範囲の記録内容順序にしたがった始端に仮想ヘッダが達したら、つまりキャッシュバッファ２２に余裕がなくなればステップＳ４に進んで、実ＶＴＲ３をプレイさせ、キャッシュバッファ２２を更新していく。この処理はステップＳ５で仮想ヘッドの位置に余裕ができ、ステップＳ２で実ＶＴＲ３をストップさせるまで続く。このように、制御部１０は上記順方向連続性補償データ範囲を含めた必要データ範囲のデータがキャッシュバッファ２２に蓄積される状態を維持するために必要に応じてコンピュータネットワーク５を介してリモート側２の送信動作を制御する。
【００２９】
これにより、制御部１０は、見かけ上、リモート側２のデータ送信タイミングと同一タイミングで仮想ＶＴＲ８を動かすことができる。
【００３０】
なお、実際には、仮想ＶＴＲ８を本物のＶＴＲのように使えるようにするために、PLAY, STOP以外にも可変速再生（JOG/VAR)による逆方向への再生や、高速再生（シャトル、SHUTTLE)、頭出し（キュウアップ、CUE UP)にも対応するようにする必要がある。仮想ＶＴＲ８の概略的な状態遷移を図５に示す。ここでは、ログイン（login）動作、キュウアップ（CUE UP)動作、通常動作、シャトル（SHUTTLE)動作間の状態の遷移の様子を示す。
【００３１】
先ず、login動作について説明する。仮想ＶＴＲ８と実ＶＴＲ３のコンピュータネットワーク５経由での接続を確立し、実ＶＴＲ３の独占使用権を取得する動作である。login完了直後に仮想ＶＴＲ８がPLAY等の動作を要求される場合を考慮して、CUE UP動作を経て即再生可能となった時点でlogin動作完了とし、通常動作に遷移する。図５中には「login動作」状態から「CUE UP動作」状態を経由して「通常動作」状態に移る様子を矢印ａとして示す。
【００３２】
次に、CUE UP動作について説明する。仮想ＶＴＲ８が操作装置１１からCUE UP動作を指示されたら、仮想ヘッドの位置をCUE UPで指定された位置とし、実ＶＴＲ３を仮想ヘッドよりも少し前の位置にCUE UP、PLAYし、キャッシュバッファ２２に仮想ヘッドを中心とした領域の映像データを格納する。キャッシュバッファ２２への映像データ格納が完了した時点で、CUE UP動作完了とする。
【００３３】
次に、通常動作について説明する。上記図４に示したフローチャートのような基本原理でキャッシュバッファを更新し、映像信号出力を行う。通常動作に遷移する前には、必ずCUE UP動作を経て、キャッシュバッファ２２を必要な映像データで満たさなくてはならない。図５中には矢印ｂで示す。また詳細を後述する。
【００３４】
次に、SHUTTLE動作について説明する。SHUTTLEは、高速で(最高100倍速程度)、出力するフレームが不連続(飛び飛び)な再生形態であるので、「通常動作」状態のような再生方法は使えない。そこでキャッシュバッファ２２を用いずに、図５中矢印ｃに示すようにSHUTTLE命令をそのままコンピュータネットワーク５を介して実ＶＴＲ３に送り、実ＶＴＲ３からの映像出力をコンピュータネットワーク５を介して受け取りそのまま出力するようにする。SHUTTLEは、テープの映像をおおまかに探すための動作であり、動作精度がそれほど要求されないため、このような方法でよい。SHUTTLEが終了した時は、図５中ｄに示すようにCUE UP動作を経て通常動作に遷移する。
【００３５】
通常動作時のキャッシュバッファの更新を、映像データ中の時間位置（テープ中の位置）を示す図６を用いて詳細に説明する。通常動作で重要なことは、キャッシュバッファ２２の更新は、仮想ＶＴＲ８のローカル側６から見た動作状態(PLAY, STOP等)とは無関係に、仮想ヘッドとキャッシュバッファ２２にある映像データ範囲の位置関係のみに依存して行われるということである。
【００３６】
CUE UP動作が完了した時点で、キャッシュバッファ２２は、図６中範囲Av「キャッシュバッファにある映像データの範囲」を映像データで満たしており、仮想ヘッドの位置は、図６の範囲As「仮想ヘッドがこの間にあれば、何もしなくてよい範囲」の中にある。仮想ＶＴＲ８は、操作装置１１からの制御信号に従って、キャッシュバッファ２２にある映像データを映像信号として出力し、本物のＶＴＲ３と同様に仮想ヘッドの位置を更新していく。
【００３７】
そして、制御部１０は、仮想ＶＴＲ８の仮想ヘッドの位置が図６に示す順方向連続補償データ範囲αの記録内容順序にしたがった始端ｓFに達したら、順方向データ再生の連続性を保つために、ネットワークＩ／Ｆ７と、コンピュータネットワーク５を介してリモート側２の実ＶＴＲ３を図６のTfにCUE UPし、PLAYさせ、Tfよりも順方向Ｆにある映像データを送信させる。仮想ＶＴＲ８は実ＶＴＲ３からネットワーク５経由でTfよりも順方向Ｆにある映像データを受け取り、キャッシュバッファ２２を更新していく。
【００３８】
このキャッシュバッファ２２の更新は、制御部１０の制御により、仮想ＶＴＲ８の仮想ヘッドが上記順方向連続性補償データ範囲αの終端ｅFに達する前に、この終端ｅFからデータが連続して蓄積されるように行われる。
【００３９】
そして、キャッシュバッファ２２を更新していった結果、仮想ヘッドの位置が再び図６の範囲Asに収まったら、実ＶＴＲ３をSTOPさせ、キャッシュバッファ２２の更新を止める。仮想ＶＴＲ３の順方向ＦのJOG/VARの最大速度をPLAYの速度以下とすれば、順方向連続性補償データ範囲αは、
(実VTRがTbからTfまでCUE UPしてPLAYするまでの時間) ＋(ネットワークの遅延)＋ (その他遅延) ≦ α ・・・(式１)
を満たす時間長とする。上記式１の意味は、左辺が仮想ＶＴＲ８がキャッシュバッファ２２を更新しはじめるまでの時間、右辺が仮想ヘッドがTfに到達するまでの最短時間である。このようにすることで、仮想ヘッドがキャッシュバッファ２２のTfよりも順方向Ｆにはみ出してしまうことはない。式１の「ネットワークの遅延」とは、仮想ＶＴＲ８からの制御データが実ＶＴＲ３に届くまでの遅延と、実ＶＴＲ３からの映像データが仮想ＶＴＲ８に届くまでの遅延を合わせたものである。式１の「その他遅延」とは、仮想ＶＴＲ８のキャッシュバッファ２２の読み書きに要する遅延など、仮想ＶＴＲ８内の細かな遅延要素をまとめたものである。
【００４０】
次に、仮想ＶＴＲ８がキャッシュバッファ２２中のデータを逆方向Ｒ側へ再生している時のキャッシバッファ２２の更新について上記図６を用いて説明する。仮想ヘッドの位置が図６の逆方向連続性補償データ範囲βの、記録内容順序にしたがった終端eRに達したとき、制御部１０はリモート側２がデータの送信を開始するまでに要する時間と、送信側からの送信レートに応じた時間分以上の時間で仮想ＶＴＲ８にキャッシュバッファ２２中の逆方向連続性補償データ範囲βを再生させる。具体的には、仮想ヘッドが逆方向連続性補償データ範囲βの終端eRに達したとき、実ＶＴＲ３を図６のTbからさらに逆方向にβだけ戻った位置(Tb−β)にCUE UPし、PLAYさせ、(Tb−β)からTbまでの範囲にある映像データをコンピュータネットワーク５に送信させる。仮想ＶＴＲ８は実ＶＴＲ３からコンピュータネットワーク５経由で(Tb−β)からTbまでの範囲にある映像データを受け取り、キャッシュバッファ２２を更新する。キャッシュバッファ２２の更新が終わった時点で、仮想ヘッドの位置は図６でいうAsに相当する範囲に収まっているはずなので、実ＶＴＲ３をSTOPさせる。仮想ＶＴＲ８の逆方向ＢのJOG再生やVariable再生の最大速度をk倍速(kは1未満)とすれば、βは、
(実VTRがTfから(Tb−β)までCUE UPしてPLAYするまでの時間) ＋ (ネットワークの遅延) ＋ (その他遅延) ＋ β≦β/k ・・・(式２)
を満たす時間長とする。式２の意味は、左辺第3項までが仮想ＶＴＲ８がキャッシュバッファ２２の更新を開始するまでの時間、左辺第4項がキャッシュバッファ２２の更新を開始してから終了するまでの時間、右辺が仮想ヘッドがTbに到達するまでの最短時間である。左辺の「ネットワークの遅延」と「その他遅延」の意味は、式１と同じである。
【００４１】
例えば、k＝1/2 (0.5倍速)とすれば、
(実VTRがTfからTb−βまでCUE UPしてPLAYするまでの時間) ＋(ネットワークの遅延) ＋ (その他遅延) ≦ β ・・・(式３)
となる。このようにすることで、仮想ヘッドがキャッシュバッファのTbよりも逆方向にはみ出してしまうことはないはずである。
【００４２】
次に、図７を用いてキャッシュバッファ２２について説明する。キャッシュバッファ２２は有限の大きさのバッファであるため、どちらかの方向側に更新すれば(増やせば)、当然その分だけ反対方向側は減ることになる。また、キャッシュバッファ２２の更新は、順方向Ｆは仮想ヘッドの動きに追随して必要な分だけ行われるのに対して、逆方向Ｒは長さβ単位で更新され、一旦更新がはじまったら長さβの分の更新が完了するまで止まらない。
【００４３】
そこで、最も厳しいパターンは、逆方向Ｒ側の更新動作を開始した直後に、仮想ヘッドが順方向Ｆに進んだ場合である。仮想ヘッドが、順方向側から図７の(Tb＋β)の位置に来たときに、キャッシュバッファ２２の逆方向Ｒ側の更新がはじまる。その時点でキャッシュバッファ２２の(Tf−β)〜Tfの領域は、逆方向Ｒ側の更新データ((Tb−β)〜Tb)の上書きが始まるため、使用できなくなる。直後に仮想ヘッドが順方向Ｆ側に進み始めたとする。キャッシュバッファ２２の逆方向Ｒ側の更新動作が終了するまでにはβの時間がかかり、その間に仮想ヘッドは最大でβだけ順方向Ｆ側に進む。キャッシュバッファ２２の逆方向Ｒ側の更新動作が完了するまでの間に、順方向Ｆ側の更新動作が必要になってはならない。そのためには、図７のキャッシュバッファの(Tb＋β)〜(Tf−β)の長さがβ＋α以上必要となる。結局、キャッシュバッファの大きさは、
β＋(β＋α)＋β＝α＋3β ・・・(式4)
以上必要になる。なお、逆方向Ｒ側の更新動作が終了するまでの間に、仮想ヘッドが何度も方向を変えた場合が考えられるが、上記アルゴリズムでは仮想ヘッドとキャッシュバッファにある映像データの位置関係のみに注目しているので、仮想ヘッドが何度も方向を変えても影響はない(行ったり来たりする分だけ結果的にゆっくり動いたのと同じことになる)。
【００４４】
以上に概略的に説明した、キャッシュバッファ２２読み書きの流れを、図８〜図１１を用いて説明する。制御部１０によって行われる動作である。
【００４５】
先ず、キャッシュバッファ２２の読み出し動作について図８を用いて説明する。ステップＳ１１では入力された制御データに応じて、実ＶＴＲ３と同様に、仮想ＶＴＲ８を動かす。そして、ステップＳ１２で仮想ヘッドの位置に対応する映像データを、キャッシュバッファ２２から読み出し、映像信号として出力する。
【００４６】
次に、キャッシュバッファ２２の書き込み動作について図９を用いて説明する。順方向再生しているときと、逆方向再生しているときに分かれる。ステップＳ２１で仮想ヘッドがαで示される順方向連続性補償データ範囲に入ったか否かを判断し、入ればステップＳ２２に進んで順方向キャッシュバッファ更新動作を行う。入っていなければステップＳ２３に進んで、仮想ヘッドがβで示される逆方向連続性補償データ範囲に入ったか否かを判断する。入っていればステップＳ２４に進んで逆方向側キャッシュバッファ更新動作を行う。
【００４７】
次に、上記ステップＳ２２での順方向キャッシュバッファ更新動作について図１０を用いて説明する。ステップＳ３１で予め制御部１０は実ＶＴＲ３に上記図６中のTfにキュウアップする命令を発行し、完了するのを待つ。次にステップＳ３２で実ＶＴＲ３にplay命令を発行する。そして、実ＶＴＲ３から、上記Tfよりも順方向Ｆ側にある映像データを受け取り、キャッシュバッファ２２に書き込む。
【００４８】
制御部１０は、操作装置１１からの命令で仮想ＶＴＲ８の再生を開始し、仮想ヘッドが上記図６中の「何もしなくてよい」の範囲Asに入っているか否かを判断する。ここで、入っていればステップＳ３５に進み、実ＶＴＲ３にストップ命令を発行するが、入っていなければ、すなわち、上記順方向連続性補償データ範囲αの始端Sfに入ればステップＳ３３からの処理を繰り返す。
【００４９】
これに対して、上記ステップＳ２４での逆方向キャッシュバッファ更新動作について図１１を用いて説明する。ステップＳ４１で制御部１０は、実ＶＴＲ３に上記図６中のTb−βにキュウアップする命令を発行し、完了するのを待つ。そして、ステップＳ４３で実ＶＴＲ３から、Tb−β〜Tbの範囲にある映像データを受け取り、キャッシュバッファ２２に書き込む。
【００５０】
制御部１０は、操作装置１１からの命令で仮想ＶＴＲ８において逆方向再生を開始し、実ＶＴＲ３が上記図６のTbまで再生し終わったか否かを判断し、終わっていれば実ＶＴＲ３にstop命令を発行する。
【００５１】
以上、映像通信システム１について説明した。特に、このシステムではローカル側６を映像データ再生装置というハードウェア構成で示した。この映像データ再生装置によれば、仮想ＶＴＲ８というものを用いることで、コンピュータネットワーク５の遅延を気にせず、あたかも手元で映像を再生している感じを操作者に与えることができる。
【００５２】
次に、本発明のデータ再生方法の具体例について説明する。この具体例は、本発明のデータ再生方法をプログラムとしたソフトウェアである。このソフトウェアは図１２に構成を示すコンピュータによって実行される。
【００５３】
先ず、このプログラムは、送信側となるリモート側２からコンピュータネットワーク５を介して送信されてくる映像データを通信部で受信する工程と、上記映像データを一時的に蓄積部に蓄積すると共に該蓄積部に蓄積されたデータを再生する受信側データ再生工程とを備えている。そして、上記受信側データ再生工程による蓄積部でのデータ再生の連続性を保つために必要とされる順方向又は逆方向連続性補償データ範囲の一方の端部に再生位置が達したとき、上記通信部を介して送信側にデータの送信を要求し、送信側から送信されるデータを上記データ再生工程の蓄積部に蓄積させる。
【００５４】
このプログラムは、図１２中のプログラム用ＲＯＭ＆ＲＡＭ３０に格納される。このＲＯＭ＆ＲＡＭ３０は、ＣＰＵバス３１を介してＣＰＵ２７に接続されている。ＣＰＵ２７にはＣＰＵバス３１を介して、ネットワークＩ／Ｆ７、キャッシュバッファ２２、映像出力回路２５及び制御入力Ｉ／Ｆ２９も接続されている。
【００５５】
各ブロックは、ＣＰＵ２７から動作の設定、データの読み書きなどが行える。ネットワークＩ／Ｆ７とキャッシュバッファ２２の間の映像データの転送は、専用のバス、つまりキャッシュバッファ書き込み専用バスBusWによって行われる。また、キャッシュバッファ２２と映像出力回路２５の間の映像データの転送は、キャッシュバッファ読み出し専用バスBusRによって行われる。また、各ブロックの詳細は、上記図３を用いて説明したのと同様であるのでここでは説明を省略する。
【００５６】
このコンピュータは、仮想ＶＴＲを構成しており、図１３に示すデータの流れによりキャッシュバッファからデータを読み出す。すなわち、ＣＰＵ２７は、矢印３１で示すように供給されてくる制御信号に応じて、仮想ヘッドを本物のＶＴＲと同様に動かし、仮想ヘッドの位置に該当する映像データを、キャッシュバッファ２２から矢印３２に示すように出力させる。
【００５７】
また、図１４に示すデータの流れによりキャッシュバッファにデータを書き込む。すなわち、ＣＰＵ２７は、矢印３３に示す経路で実ＶＴＲ３に制御データを送り、矢印３４に示すようにキャッシュバッファ２２に映像データを書き込む。
【００５８】
また、キャッシュバッファの具体的な構造としては、例えば、図１５のようなリングバッファ構造などが考えられる。
【００５９】
順方向再生時、仮想ヘッド位置PHは、順方向Ｆ側に動き、順方向連続性補償データ範囲αの方向に動く。また、逆方法再生時には逆方向Ｒ側に動き、逆方向連続性補償データ範囲βの方向に動く。キャッシュバッファ２２は有限の大きさのバッファであるため、どちらかの方向側に更新すれば(増やせば)、当然その分だけ反対方向側は減ることになるが、リングバッファを用いることで、更新のための制御を単純にすることができる。
【００６０】
また、ローカル側６の使用環境としては、例えば、図１６に示すように編集機５０を用いた編集システムにおける使用環境も考えられる。編集機５０は、上記図１に示したモニタ９と、操作部１１と、制御部１０の機能も備える。すなわち、編集機５０は、ユーザからの編集に関わる操作信号を受け付け、この操作信号に応じた制御信号Scを生成して仮想ＶＴＲ８を上述したように動作させる。そして、映像信号Svを受け取って画像表示部に表示し、再生用ＶＴＲ５１で再生した映像信号と共に、記録用ＶＴＲ５２に記録しながら、編集映像を作成していく。
【００６１】
【発明の効果】
本発明によれば、遠隔地などにある映像機器を、コンピュータネットワーク等の通信回線を用いて、あたかも近くにあるのと変わらない感覚で利用できるようになる。このため、遠隔地にある素材をいつでもリアルタイムに利用することができる。また、素材が入ったビデオテープ等のコピーを、各地にそれぞれ用意しなくて済む。また、普段使わない素材は、地価の安い郊外の施設で保管し、必要なときに通信回線経由で不自由なく利用できる。
【図面の簡単な説明】
【図１】本発明のデータ通信システムの具体例となる映像データ通信システムの概略構成を示すブロック図である。
【図２】上記映像データ通信システムのリモート側に設置したＩ／Ｆの詳細な構成を示すブロック図である。
【図３】上記映像データ通信システムのローカル側の要部の詳細な構成を示すブロック図である。
【図４】上記映像データ通信システムのローカル側で行われるキャッシュバッファ管理の具体例を説明するフローチャートである。
【図５】上記映像データ通信システムのローカル側に設けた仮想ＶＴＲの概略的な状態遷移図である。
【図６】通常動作時のキャッシュバッファの更新を説明するために用いる、映像データ中の時間位置（テープ中の位置）を示す図である。
【図７】順方向再生、逆方向再生時のキャッシュバッファの更新を説明するための図である。
【図８】キャッシュバッファの読み出し動作を説明するためのフローチャートである。
【図９】キャッシュバッファの書き込み動作を説明するためのフローチャートである。
【図１０】順方向キャッシュバッファ更新動作を詳細に説明するためのフローチャートである。
【図１１】逆方向キャッシュバッファ更新動作を詳細に説明するためのフローチャートである。
【図１２】本発明のデータ再生方法をプログラムとしたソフトウェアを実行するコンピュータの構成を示すブロック図である。
【図１３】上記コンピュータにおいてキャッシュバッファからデータを読み出すときのデータの流れを説明するための図である。
【図１４】上記コンピュータにおいてキャッシュバッファにデータを書き込むときのデータの流れを説明するための図である。
【図１５】キャッシュバッファの具体例となる、リングバッファの構造を示す図である。
【図１６】ローカル側を編集システムとしたときの構成を示すブロック図である。
【図１７】従来の映像再生システムのブロック図である。
【図１８】コンピュータネットワークを用いた映像送受信システムのブロック図である。
【符号の説明】
１ 映像データ通信システム、２ リモート側、３ 実ＶＴＲ、４ Ｉ／Ｆ、５ コンピュータネットワーク、６ ローカル側、７ ネットワークＩ／Ｆ、８仮想ＶＴＲ、９ モニタ、１０ 制御部、１１ 操作装置
【発明の属する技術分野】
本発明は、送信側からネットワークを介して送信されてくるデータを、通信に伴う遅延の影響を気にすることなく、あたかも手元で再生するのと同様の感覚で再生できるデータ再生装置及び方法、並びにデータ通信システムに関する。
【０００２】
【従来の技術】
例えば、映像再生システムを構成する、ＶＴＲ１０１は、本来図１７に示すように、操作卓或いはコントロールパネル等と呼ばれる操作装置１０２からの制御信号Scに従って動作し、映像信号Vをモニタ１０３に出力する。このシステムでは、ＶＴＲ１０１、操作装置１０２、モニタ１０３は、制御信号Scや映像信号Vの伝送規格を満たす程に、互いに近くに設置されている。
【０００３】
【発明が解決しようとする課題】
これに対して図１８に示すように、ＶＴＲ１０１が操作装置１０２やモニタ１０３から遠く離れた、遠隔の場所に設置され、コンピュータネットワーク１０５を介して接続された映像送受信システムの場合には、コンピュータネットワーク１０５で生じる遅延等による、動作精度やタイミング等への影響を考慮しなくてはならなかった。
【０００４】
以下、この課題を詳細に説明する。
【０００５】
ＶＴＲ１０１側をリモート側とし、操作装置１０２側をローカル側とする。ローカル側にはＩ／Ｆ(2)１０６が設けられ、操作装置１０２からの制御信号Scを例えばTCP/IP等のような何らかの形式でコンピュータネットワーク１０５に送信すると共に、コンピュータネットワーク１０５から例えばUDP/IP等のような何らかの形式で映像信号を受信してモニタ１０３に出力する。また、リモート側にはＩ／Ｆ(1)１０４が設けられ、コンピュータネットワーク１０５から何らかの形式で制御信号を受信してＶＴＲ１０１に送ると共に、ＶＴＲ１０１からの映像信号Vをコンピュータネットワーク１０５に何らかの形式で送信する。コンピュータネットワーク１０５は、ギガビットイーサネットやATM等が考えられ、QoS(Quality of Service)が保証されているものが望ましい。
【０００６】
この図１８のシステムで注意しなければならないことは、コンピュータネットワーク１０５には遅延があり、映像信号Vや制御信号Scの時間精度と比べて無視できないということである。コンピュータネットワーク１０５の遅延は、条件が良くても10msec程度は覚悟しなくてはならない。しかし、放送用や業務用のＶＴＲはフレーム(NTSC方式では33msec、PAL方式では25msec)やフィールド(0.5フレーム)単位の時間精度で動作しているので、10msecもの遅延は無視できない。特に業務用ＶＴＲの制御プロトコルである9PINプロトコルでは、制御に対する応答を9msec以内に返さなくてはならないため、10msecもの遅延があると通信そのものが成立しない。
【０００７】
そのため、単純にローカル側の制御信号をネットワーク１０５を介してそのままリモート側に転送し、リモート側の映像信号をネットワーク１０５を介してそのままローカル側に転送するような方法では、ＶＴＲ１０１の動作精度や応答性等に問題が生じてしまう。放送用・業務用などで正確な動作精度やタイミングが要求される用途には、コンピュータネットワーク等を介して遠隔地にある映像機器の映像情報をリアルタイムに利用することは難しく、そのことを特別に配慮して使わなくてはならない。
【０００８】
本発明は、上記実情に鑑みてなされたものであり、遠隔地にある映像機器を、コンピュータネットワーク等の通信回線を用いて、あたかも近くにあるように利用させることのできるデータ再生装置及び方法、並びにデータ通信システムの提供を目的とする。
【０００９】
【発明を解決するための手段】
本発明に係るデータ再生装置は、上記課題を解決するために、送信側からネットワークを介して送信されるデータを受信する通信手段と、上記通信手段で受信したデータを内容順序にしたがって一時的に蓄積部に蓄積すると共に該蓄積部に蓄積されたデータを所望の再生位置から出力する受信側データ再生手段と、上記蓄積部に蓄積されたデータの内容順序の終端から逆方向にα時間長分からなる順方向連続性補償データ範囲に上記再生位置が達したとき、上記通信手段を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求し、上記送信側から送信されたデータを上記蓄積部に内容順序にしたがって蓄積させ、上記蓄積部に蓄積されたデータの内容順序の始端から順方向にβ時間長分からなる逆方向連続性補償データ範囲に上記再生位置が達したとき、上記通信手段を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求し、上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させる制御手段とを備え、上記制御手段は、上記αを、上記通信手段を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求してから上記送信側から送信されたデータにより上記蓄積部を更新し始めるまでに掛かる時間以上として上記順方向連続性補償データ範囲を設定し、上記βを、上記通信手段を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求してから上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させるまでに掛かる時間以上として上記逆方向連続性補償データ範囲を設定し、上記蓄積部に少なくとも（α＋３β）時間長分のデータを蓄積させることを特徴とする。
【００１１】
また、本発明に係るデータ再生方法は、上記課題を解決するために、送信側からネットワークを介して送信されてくるデータを通信部で受信する工程と、上記データを内容順序にしたがって少なくとも（α＋３β）時間長分のデータを一時的に蓄積部に蓄積すると共に該蓄積部に蓄積されたデータを所望の再生位置から出力する受信側データ再生工程とを備え、上記受信側データ再生工程では、上記蓄積部に蓄積されたデータの内容順序の終端から逆方向にα時間長分からなる順方向連続性補償データ範囲に上記再生位置が達したとき、上記通信部を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求し、上記送信側から送信されたデータを上記蓄積部に内容順序にしたがって蓄積させ、上記蓄積部に蓄積されたデータの内容順序の始端から順方向にβ時間長分からなる逆方向連続性補償データ範囲に上記再生位置が達したとき、上記通信部を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求し、上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させ、上記αは、上記通信部を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求してから上記送信側から送信されたデータにより上記蓄積部を更新し始めるまでに掛かる時間以上であり、上記βは、上記通信部を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求してから上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させるまでに掛かる時間以上であることを特徴とする。
【００１３】
また、本発明に係るデータ通信システムは、ネットワークを介してデータ送信手段から送信されるデータを受信して再生するデータ通信システムであって、上記ネットワークを介して送信されてくるデータを受信して再生するデータ受信手段側に、送信側からネットワークを介して送信されるデータを受信する通信手段と、上記通信手段で受信したデータを内容順序にしたがって一時的に蓄積部に蓄積すると共に該蓄積部に蓄積されたデータを所望の再生位置から出力する受信側データ再生手段と、上記蓄積部に蓄積されたデータの内容順序の終端から逆方向にα時間長分からなる順方向連続性補償データ範囲に上記再生位置が達したとき、上記通信手段を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求し、上記送信側から送信されたデータを上記蓄積部に内容順序にしたがって蓄積させ、上記蓄積部に蓄積されたデータの内容順序の始端から順方向にβ時間長分からなる逆方向連続性補償データ範囲に上記再生位置が達したとき、上記通信手段を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求し、上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させる制御手段とを備え、上記制御手段は、上記αを、上記通信手段を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求してから上記送信側から送信されたデータにより上記蓄積部を更新し始めるまでに掛かる時間以上として上記順方向連続性補償データ範囲を設定し、上記βを、上記通信手段を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求してから上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させるまでに掛かる時間以上として上記逆方向連続性補償データ範囲を設定し、上記蓄積部に少なくとも（α＋３β）時間長分のデータを蓄積させることを特徴とする。
【００１４】
具体的には、コンピュータネットワーク等を介してVTR等の映像機器を利用する際に、映像信号や制御信号を単純にコンピュータネットワークを介してそのままやり取りするのではなく、手元に仮想的な映像機器を設けることで、コンピュータネットワークで生じる遅延等による動作の精度やタイミング等の狂いを抑える。
【００１５】
また、 仮想的な映像機器は、コンピュータネットワーク越しにある本物の映像機器から、コンピュータネットワークを介して当座に必要な映像信号を取得し、一時記憶しておくので、映像機器の使用者に対しては、仮想的な映像機器自身が本物の映像機器のようにふるまい、映像機器として正しい反応をすることで、使用者にコンピュータネットワークを介していることを意識させない。
【００１６】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照しながら説明する。図１にはデータ通信システムの具体例である映像データ通信システム１の概略構成を示す。この映像データ通信システム１はリモート側２とローカル側６がコンピュータネットワーク５によって接続されている。特にローカル側６は本発明のデータ再生装置の具体例となり、本発明のデータ再生方法を実行する映像データ再生装置である。リモート側２は映像データを送信する送信側であり、ローカル側６は映像データを受信する受信側でもある。
【００１７】
送信側であるリモート側２にはビデオテープから映像信号を再生するＶＴＲ３が設けられ、このＶＴＲ３とコンピュータネットワーク５の間にはＩ／Ｆ４が設けられている。Ｉ／Ｆ４はコンピュータネットワーク５から何らかの形式で制御信号SCを受信してＶＴＲ３に送ると共に、ＶＴＲ３からの映像信号Vをコンピュータネットワーク５に何らかの形式で送信する。
【００１８】
Ｉ／Ｆ４の内部構成例を図２に示す。このＩ／Ｆ４は、ＶＴＲ３からのＳＤＩ入力等の映像信号Vを映像入力回路１２で受け、受信映像データDVとし、この受信映像データDVを例えばATMＩ／ＦのようなネットワークＩ／Ｆ１５でコンピュータネットワーク５のフォーマットに変換して送信すると共に、ネットワークＩ／Ｆ１５で受信した受信制御データDCを例えばRS-422Ｉ／Ｆのような制御出力Ｉ／Ｆ１８で制御信号SCに変換してＶＴＲ３に出力する。映像入力回路１２とネットワークＩ／Ｆ１５との間には各種入出力データを内部で扱える形式に変換するデータ変換器１３，１４が設けられている。またネットワークＩ／Ｆ１５と制御出力Ｉ／Ｆ１８との間にも同様のデータ変換器１６，１７が設けられている。
【００１９】
図１において、コンピュータネットワーク５はギガビットイーサネットやATM等が考えられ、QoS(Quality of Service)が保証されているものが望ましい。
【００２０】
受信側であるローカル側６にはリモート側２からコンピュータネットワーク５を介して送信されてくる例えばUDP/IP等のような何らかの形式の映像データDVを受信するネットワークＩ／Ｆ７と、このネットワークＩ／Ｆ７で受信した映像データDVを一時的に蓄積するキャッシュバッファメモリを備えた受信側再生部（仮想ＶＴＲ）８と、この仮想ＶＴＲ８を制御する制御部１０と、仮想ＶＴＲ８からの映像信号SVを出力するモニタ９と、ユーザからの操作信号を受け付け、制御部１０に制御信号SCを送る操作装置１１が備えられている。
【００２１】
仮想ＶＴＲ８は実際にはキャッシュバッファを記録媒体にした再生装置であり、ビデオテープを記録媒体にした一般的なＶＴＲではなく、ローカル側６から見た場合に仮想的にＶＴＲのように動作する。具体的に、この仮想ＶＴＲ８は、リモート側２にあるＶＴＲ３の映像データ(映像信号を作り出すのに必要な情報)の一部をあらかじめキャッシュバッファに一時記憶しておき、操作装置１１からの制御信号SCに応じ制御部１０で生成された制御データDCに対して、あたかもＶＴＲそのもののように振舞ってモニタ９に映像信号SVを出力する。このような仮想ＶＴＲ８というものを用いることで、ローカル側６では、コンピュータネットワーク５の遅延を気にせず、あたかも手元にＶＴＲがあるように使うことができる。また、仮想ＶＴＲ８が映像出力をしている映像素材中の再生位置を、「仮想ヘッド」と呼ぶ。また、リモート側２にある本物のＶＴＲ３を、適宜「実ＶＴＲ３」と記す。
【００２２】
ネットワークＩ／Ｆ７と、仮想ＶＴＲ８と、制御部１０の詳細な構成を図３に示す。コンピュータネットワーク５を介して例えばATMＩ／ＦのようなネットワークＩ／Ｆ７で受信した映像データDVは仮想ＶＴＲ８中のキャッシュバッファ２２の所定の位置に書き込まれる。キャッシバッファ２２に記録されている映像データDVの内、仮想ＶＴＲ８の仮想ヘッドに対応するデータが、映像出力回路２５を経てＳＤＩ出力等の映像信号SVとしてモニタ９に出力される。操作装置１１が接続されている制御部１０は、制御信号SCを例えばRS422Ｉ／Ｆ等の制御入力Ｉ／Ｆ２９で受け取った後、入力制御データDCiとして直接そのままネットワークＩ／Ｆ７に送るのではなく、ＣＰＵ２７に送る。ＣＰＵ２７は入力制御データDCiを解釈して仮想ＶＴＲ８の動作を決定し、キャッシュバッファ２２の更新に必要な実ＶＴＲ３の動作内容を送信制御データDCoとしてネットワークＩ／Ｆ７に出力する。なお、ネットワークＩ／Ｆ７とキャッシュバッファ２２との間には各種入出力データを内部で扱える形式に変換するデータ変換器２０，２１が設けられている。また仮想ＶＴＲ８内部のキャッシュバッファ２２と映像出力回路２５との間にもデータ変換器２３，２４が設けられている。また制御部１０内部の制御入力Ｉ／Ｆ２９とＣＰＵ２７の間にもデータ変換器２８が設けられている。さらにＣＰＵ２７とネットワークＩ／Ｆ７との間にもデータ変換器２６が設けられている。
【００２３】
ローカル側６として説明してきた映像データ再生装置の基本的な原理を以下に説明する。仮想ＶＴＲ８は、仮想ヘッドの前後一定区間の映像データDVを、あらかじめ実ＶＴＲ３からコンピュータネットワーク５経由で取得し、一時的にキャッシュバッファ２２に記憶しておく。操作装置１１から例えばPLAY(通常再生)等の制御信号SCを受けたら、仮想ヘッドに該当する映像信号SVをキャッシュバッファ２２から出力し、仮想ヘッドの位置を進める。仮想ヘッドが、キャッシュバッファ２２中に蓄積されている所定データ範囲から外れる前に、この映像データ再生装置は実ＶＴＲ３にコンピュータネットワーク５経由でPLAYの制御信号を送り、将来必要になる映像データを受け取る。
【００２４】
実ＶＴＲ３から受け取った映像データは、キャッシュバッファ２２のいらなくなった映像データに上書きして記憶される。これによりキャッシュバッファ２２の範囲が更新される。仮想ＶＴＲ８の再生動作がSTOPしたりして、キャッシュバッファ２２に余裕ができたら、実ＶＴＲ３を止める。このような処理を繰り返すことで、仮想ＶＴＲ８をあたかも本物のＶＴＲのように使うことができる。
【００２５】
上記基本的な原理は制御部１０によるキャッシュバッファ管理により実現される。上記所定データ範囲を仮想ＶＴＲ８によるキャッシュバッファ２２を用いたデータ再生の連続性を保つために必要とされる連続性補償データ範囲とすると、この連続性補償データ範囲の一方の端部に仮想ヘッドが達したら、制御部１０はネットワークＩ／Ｆ７、コンピュータネットワーク５を介してリモート側２にデータの送信を要求する。そして、制御部１０はリモート側２から送信されたデータをキャッシュバッファ２２に蓄積させる。
【００２６】
連続性補償データ範囲は、仮想ＶＴＲ８がキャッシュバッファ２２中のデータを順方向再生している場合と、逆方向再生している場合とでは異なる。前者を順方向連続性補償データ範囲、後者を逆方向連続性補償データ範囲とする。この各データ範囲については後述する。
【００２７】
上記キャッシュバッファ管理の具体例を、図４に示すフローチャートにしたがって説明する。先ず、ステップＳ１で制御部１０は実ＶＴＲ３をプレイさせ、キャッシュバッファ２２を映像データで埋めておく。すなわち、仮想ヘッドの前後一定区間の映像データを、コンピュータネットワーク５経由で実ＶＴＲ３から取得し、キャッシュバッファ２２に記憶しておく。そして、キャッシュバッファ２２が必要データ範囲となったらステップＳ２で実ＶＴＲ３をストップさせる。このように、制御部１０はキャッシュバッファ２２に蓄積されるべき必要データ範囲を判別する。
【００２８】
ここで、例えば操作装置１１から通常再生等の制御信号を受けたら、仮想ヘッドに該当する映像信号を出力し、仮想ヘッドの位置を進める。そして、ステップＳ３で仮想ヘッドの位置に余裕があるか否かを判断する。順方向連続性補償データ範囲の記録内容順序にしたがった始端に仮想ヘッダが達したら、つまりキャッシュバッファ２２に余裕がなくなればステップＳ４に進んで、実ＶＴＲ３をプレイさせ、キャッシュバッファ２２を更新していく。この処理はステップＳ５で仮想ヘッドの位置に余裕ができ、ステップＳ２で実ＶＴＲ３をストップさせるまで続く。このように、制御部１０は上記順方向連続性補償データ範囲を含めた必要データ範囲のデータがキャッシュバッファ２２に蓄積される状態を維持するために必要に応じてコンピュータネットワーク５を介してリモート側２の送信動作を制御する。
【００２９】
これにより、制御部１０は、見かけ上、リモート側２のデータ送信タイミングと同一タイミングで仮想ＶＴＲ８を動かすことができる。
【００３０】
なお、実際には、仮想ＶＴＲ８を本物のＶＴＲのように使えるようにするために、PLAY, STOP以外にも可変速再生（JOG/VAR)による逆方向への再生や、高速再生（シャトル、SHUTTLE)、頭出し（キュウアップ、CUE UP)にも対応するようにする必要がある。仮想ＶＴＲ８の概略的な状態遷移を図５に示す。ここでは、ログイン（login）動作、キュウアップ（CUE UP)動作、通常動作、シャトル（SHUTTLE)動作間の状態の遷移の様子を示す。
【００３１】
先ず、login動作について説明する。仮想ＶＴＲ８と実ＶＴＲ３のコンピュータネットワーク５経由での接続を確立し、実ＶＴＲ３の独占使用権を取得する動作である。login完了直後に仮想ＶＴＲ８がPLAY等の動作を要求される場合を考慮して、CUE UP動作を経て即再生可能となった時点でlogin動作完了とし、通常動作に遷移する。図５中には「login動作」状態から「CUE UP動作」状態を経由して「通常動作」状態に移る様子を矢印ａとして示す。
【００３２】
次に、CUE UP動作について説明する。仮想ＶＴＲ８が操作装置１１からCUE UP動作を指示されたら、仮想ヘッドの位置をCUE UPで指定された位置とし、実ＶＴＲ３を仮想ヘッドよりも少し前の位置にCUE UP、PLAYし、キャッシュバッファ２２に仮想ヘッドを中心とした領域の映像データを格納する。キャッシュバッファ２２への映像データ格納が完了した時点で、CUE UP動作完了とする。
【００３３】
次に、通常動作について説明する。上記図４に示したフローチャートのような基本原理でキャッシュバッファを更新し、映像信号出力を行う。通常動作に遷移する前には、必ずCUE UP動作を経て、キャッシュバッファ２２を必要な映像データで満たさなくてはならない。図５中には矢印ｂで示す。また詳細を後述する。
【００３４】
次に、SHUTTLE動作について説明する。SHUTTLEは、高速で(最高100倍速程度)、出力するフレームが不連続(飛び飛び)な再生形態であるので、「通常動作」状態のような再生方法は使えない。そこでキャッシュバッファ２２を用いずに、図５中矢印ｃに示すようにSHUTTLE命令をそのままコンピュータネットワーク５を介して実ＶＴＲ３に送り、実ＶＴＲ３からの映像出力をコンピュータネットワーク５を介して受け取りそのまま出力するようにする。SHUTTLEは、テープの映像をおおまかに探すための動作であり、動作精度がそれほど要求されないため、このような方法でよい。SHUTTLEが終了した時は、図５中ｄに示すようにCUE UP動作を経て通常動作に遷移する。
【００３５】
通常動作時のキャッシュバッファの更新を、映像データ中の時間位置（テープ中の位置）を示す図６を用いて詳細に説明する。通常動作で重要なことは、キャッシュバッファ２２の更新は、仮想ＶＴＲ８のローカル側６から見た動作状態(PLAY, STOP等)とは無関係に、仮想ヘッドとキャッシュバッファ２２にある映像データ範囲の位置関係のみに依存して行われるということである。
【００３６】
CUE UP動作が完了した時点で、キャッシュバッファ２２は、図６中範囲Av「キャッシュバッファにある映像データの範囲」を映像データで満たしており、仮想ヘッドの位置は、図６の範囲As「仮想ヘッドがこの間にあれば、何もしなくてよい範囲」の中にある。仮想ＶＴＲ８は、操作装置１１からの制御信号に従って、キャッシュバッファ２２にある映像データを映像信号として出力し、本物のＶＴＲ３と同様に仮想ヘッドの位置を更新していく。
【００３７】
そして、制御部１０は、仮想ＶＴＲ８の仮想ヘッドの位置が図６に示す順方向連続補償データ範囲αの記録内容順序にしたがった始端ｓFに達したら、順方向データ再生の連続性を保つために、ネットワークＩ／Ｆ７と、コンピュータネットワーク５を介してリモート側２の実ＶＴＲ３を図６のTfにCUE UPし、PLAYさせ、Tfよりも順方向Ｆにある映像データを送信させる。仮想ＶＴＲ８は実ＶＴＲ３からネットワーク５経由でTfよりも順方向Ｆにある映像データを受け取り、キャッシュバッファ２２を更新していく。
【００３８】
このキャッシュバッファ２２の更新は、制御部１０の制御により、仮想ＶＴＲ８の仮想ヘッドが上記順方向連続性補償データ範囲αの終端ｅFに達する前に、この終端ｅFからデータが連続して蓄積されるように行われる。
【００３９】
そして、キャッシュバッファ２２を更新していった結果、仮想ヘッドの位置が再び図６の範囲Asに収まったら、実ＶＴＲ３をSTOPさせ、キャッシュバッファ２２の更新を止める。仮想ＶＴＲ３の順方向ＦのJOG/VARの最大速度をPLAYの速度以下とすれば、順方向連続性補償データ範囲αは、
(実VTRがTbからTfまでCUE UPしてPLAYするまでの時間) ＋(ネットワークの遅延)＋ (その他遅延) ≦ α ・・・(式１)
を満たす時間長とする。上記式１の意味は、左辺が仮想ＶＴＲ８がキャッシュバッファ２２を更新しはじめるまでの時間、右辺が仮想ヘッドがTfに到達するまでの最短時間である。このようにすることで、仮想ヘッドがキャッシュバッファ２２のTfよりも順方向Ｆにはみ出してしまうことはない。式１の「ネットワークの遅延」とは、仮想ＶＴＲ８からの制御データが実ＶＴＲ３に届くまでの遅延と、実ＶＴＲ３からの映像データが仮想ＶＴＲ８に届くまでの遅延を合わせたものである。式１の「その他遅延」とは、仮想ＶＴＲ８のキャッシュバッファ２２の読み書きに要する遅延など、仮想ＶＴＲ８内の細かな遅延要素をまとめたものである。
【００４０】
次に、仮想ＶＴＲ８がキャッシュバッファ２２中のデータを逆方向Ｒ側へ再生している時のキャッシバッファ２２の更新について上記図６を用いて説明する。仮想ヘッドの位置が図６の逆方向連続性補償データ範囲βの、記録内容順序にしたがった終端eRに達したとき、制御部１０はリモート側２がデータの送信を開始するまでに要する時間と、送信側からの送信レートに応じた時間分以上の時間で仮想ＶＴＲ８にキャッシュバッファ２２中の逆方向連続性補償データ範囲βを再生させる。具体的には、仮想ヘッドが逆方向連続性補償データ範囲βの終端eRに達したとき、実ＶＴＲ３を図６のTbからさらに逆方向にβだけ戻った位置(Tb−β)にCUE UPし、PLAYさせ、(Tb−β)からTbまでの範囲にある映像データをコンピュータネットワーク５に送信させる。仮想ＶＴＲ８は実ＶＴＲ３からコンピュータネットワーク５経由で(Tb−β)からTbまでの範囲にある映像データを受け取り、キャッシュバッファ２２を更新する。キャッシュバッファ２２の更新が終わった時点で、仮想ヘッドの位置は図６でいうAsに相当する範囲に収まっているはずなので、実ＶＴＲ３をSTOPさせる。仮想ＶＴＲ８の逆方向ＢのJOG再生やVariable再生の最大速度をk倍速(kは1未満)とすれば、βは、
(実VTRがTfから(Tb−β)までCUE UPしてPLAYするまでの時間) ＋ (ネットワークの遅延) ＋ (その他遅延) ＋ β≦β/k ・・・(式２)
を満たす時間長とする。式２の意味は、左辺第3項までが仮想ＶＴＲ８がキャッシュバッファ２２の更新を開始するまでの時間、左辺第4項がキャッシュバッファ２２の更新を開始してから終了するまでの時間、右辺が仮想ヘッドがTbに到達するまでの最短時間である。左辺の「ネットワークの遅延」と「その他遅延」の意味は、式１と同じである。
【００４１】
例えば、k＝1/2 (0.5倍速)とすれば、
(実VTRがTfからTb−βまでCUE UPしてPLAYするまでの時間) ＋(ネットワークの遅延) ＋ (その他遅延) ≦ β ・・・(式３)
となる。このようにすることで、仮想ヘッドがキャッシュバッファのTbよりも逆方向にはみ出してしまうことはないはずである。
【００４２】
次に、図７を用いてキャッシュバッファ２２について説明する。キャッシュバッファ２２は有限の大きさのバッファであるため、どちらかの方向側に更新すれば(増やせば)、当然その分だけ反対方向側は減ることになる。また、キャッシュバッファ２２の更新は、順方向Ｆは仮想ヘッドの動きに追随して必要な分だけ行われるのに対して、逆方向Ｒは長さβ単位で更新され、一旦更新がはじまったら長さβの分の更新が完了するまで止まらない。
【００４３】
そこで、最も厳しいパターンは、逆方向Ｒ側の更新動作を開始した直後に、仮想ヘッドが順方向Ｆに進んだ場合である。仮想ヘッドが、順方向側から図７の(Tb＋β)の位置に来たときに、キャッシュバッファ２２の逆方向Ｒ側の更新がはじまる。その時点でキャッシュバッファ２２の(Tf−β)〜Tfの領域は、逆方向Ｒ側の更新データ((Tb−β)〜Tb)の上書きが始まるため、使用できなくなる。直後に仮想ヘッドが順方向Ｆ側に進み始めたとする。キャッシュバッファ２２の逆方向Ｒ側の更新動作が終了するまでにはβの時間がかかり、その間に仮想ヘッドは最大でβだけ順方向Ｆ側に進む。キャッシュバッファ２２の逆方向Ｒ側の更新動作が完了するまでの間に、順方向Ｆ側の更新動作が必要になってはならない。そのためには、図７のキャッシュバッファの(Tb＋β)〜(Tf−β)の長さがβ＋α以上必要となる。結局、キャッシュバッファの大きさは、
β＋(β＋α)＋β＝α＋3β ・・・(式4)
以上必要になる。なお、逆方向Ｒ側の更新動作が終了するまでの間に、仮想ヘッドが何度も方向を変えた場合が考えられるが、上記アルゴリズムでは仮想ヘッドとキャッシュバッファにある映像データの位置関係のみに注目しているので、仮想ヘッドが何度も方向を変えても影響はない(行ったり来たりする分だけ結果的にゆっくり動いたのと同じことになる)。
【００４４】
以上に概略的に説明した、キャッシュバッファ２２読み書きの流れを、図８〜図１１を用いて説明する。制御部１０によって行われる動作である。
【００４５】
先ず、キャッシュバッファ２２の読み出し動作について図８を用いて説明する。ステップＳ１１では入力された制御データに応じて、実ＶＴＲ３と同様に、仮想ＶＴＲ８を動かす。そして、ステップＳ１２で仮想ヘッドの位置に対応する映像データを、キャッシュバッファ２２から読み出し、映像信号として出力する。
【００４６】
次に、キャッシュバッファ２２の書き込み動作について図９を用いて説明する。順方向再生しているときと、逆方向再生しているときに分かれる。ステップＳ２１で仮想ヘッドがαで示される順方向連続性補償データ範囲に入ったか否かを判断し、入ればステップＳ２２に進んで順方向キャッシュバッファ更新動作を行う。入っていなければステップＳ２３に進んで、仮想ヘッドがβで示される逆方向連続性補償データ範囲に入ったか否かを判断する。入っていればステップＳ２４に進んで逆方向側キャッシュバッファ更新動作を行う。
【００４７】
次に、上記ステップＳ２２での順方向キャッシュバッファ更新動作について図１０を用いて説明する。ステップＳ３１で予め制御部１０は実ＶＴＲ３に上記図６中のTfにキュウアップする命令を発行し、完了するのを待つ。次にステップＳ３２で実ＶＴＲ３にplay命令を発行する。そして、実ＶＴＲ３から、上記Tfよりも順方向Ｆ側にある映像データを受け取り、キャッシュバッファ２２に書き込む。
【００４８】
制御部１０は、操作装置１１からの命令で仮想ＶＴＲ８の再生を開始し、仮想ヘッドが上記図６中の「何もしなくてよい」の範囲Asに入っているか否かを判断する。ここで、入っていればステップＳ３５に進み、実ＶＴＲ３にストップ命令を発行するが、入っていなければ、すなわち、上記順方向連続性補償データ範囲αの始端Sfに入ればステップＳ３３からの処理を繰り返す。
【００４９】
これに対して、上記ステップＳ２４での逆方向キャッシュバッファ更新動作について図１１を用いて説明する。ステップＳ４１で制御部１０は、実ＶＴＲ３に上記図６中のTb−βにキュウアップする命令を発行し、完了するのを待つ。そして、ステップＳ４３で実ＶＴＲ３から、Tb−β〜Tbの範囲にある映像データを受け取り、キャッシュバッファ２２に書き込む。
【００５０】
制御部１０は、操作装置１１からの命令で仮想ＶＴＲ８において逆方向再生を開始し、実ＶＴＲ３が上記図６のTbまで再生し終わったか否かを判断し、終わっていれば実ＶＴＲ３にstop命令を発行する。
【００５１】
以上、映像通信システム１について説明した。特に、このシステムではローカル側６を映像データ再生装置というハードウェア構成で示した。この映像データ再生装置によれば、仮想ＶＴＲ８というものを用いることで、コンピュータネットワーク５の遅延を気にせず、あたかも手元で映像を再生している感じを操作者に与えることができる。
【００５２】
次に、本発明のデータ再生方法の具体例について説明する。この具体例は、本発明のデータ再生方法をプログラムとしたソフトウェアである。このソフトウェアは図１２に構成を示すコンピュータによって実行される。
【００５３】
先ず、このプログラムは、送信側となるリモート側２からコンピュータネットワーク５を介して送信されてくる映像データを通信部で受信する工程と、上記映像データを一時的に蓄積部に蓄積すると共に該蓄積部に蓄積されたデータを再生する受信側データ再生工程とを備えている。そして、上記受信側データ再生工程による蓄積部でのデータ再生の連続性を保つために必要とされる順方向又は逆方向連続性補償データ範囲の一方の端部に再生位置が達したとき、上記通信部を介して送信側にデータの送信を要求し、送信側から送信されるデータを上記データ再生工程の蓄積部に蓄積させる。
【００５４】
このプログラムは、図１２中のプログラム用ＲＯＭ＆ＲＡＭ３０に格納される。このＲＯＭ＆ＲＡＭ３０は、ＣＰＵバス３１を介してＣＰＵ２７に接続されている。ＣＰＵ２７にはＣＰＵバス３１を介して、ネットワークＩ／Ｆ７、キャッシュバッファ２２、映像出力回路２５及び制御入力Ｉ／Ｆ２９も接続されている。
【００５５】
各ブロックは、ＣＰＵ２７から動作の設定、データの読み書きなどが行える。ネットワークＩ／Ｆ７とキャッシュバッファ２２の間の映像データの転送は、専用のバス、つまりキャッシュバッファ書き込み専用バスBusWによって行われる。また、キャッシュバッファ２２と映像出力回路２５の間の映像データの転送は、キャッシュバッファ読み出し専用バスBusRによって行われる。また、各ブロックの詳細は、上記図３を用いて説明したのと同様であるのでここでは説明を省略する。
【００５６】
このコンピュータは、仮想ＶＴＲを構成しており、図１３に示すデータの流れによりキャッシュバッファからデータを読み出す。すなわち、ＣＰＵ２７は、矢印３１で示すように供給されてくる制御信号に応じて、仮想ヘッドを本物のＶＴＲと同様に動かし、仮想ヘッドの位置に該当する映像データを、キャッシュバッファ２２から矢印３２に示すように出力させる。
【００５７】
また、図１４に示すデータの流れによりキャッシュバッファにデータを書き込む。すなわち、ＣＰＵ２７は、矢印３３に示す経路で実ＶＴＲ３に制御データを送り、矢印３４に示すようにキャッシュバッファ２２に映像データを書き込む。
【００５８】
また、キャッシュバッファの具体的な構造としては、例えば、図１５のようなリングバッファ構造などが考えられる。
【００５９】
順方向再生時、仮想ヘッド位置PHは、順方向Ｆ側に動き、順方向連続性補償データ範囲αの方向に動く。また、逆方法再生時には逆方向Ｒ側に動き、逆方向連続性補償データ範囲βの方向に動く。キャッシュバッファ２２は有限の大きさのバッファであるため、どちらかの方向側に更新すれば(増やせば)、当然その分だけ反対方向側は減ることになるが、リングバッファを用いることで、更新のための制御を単純にすることができる。
【００６０】
また、ローカル側６の使用環境としては、例えば、図１６に示すように編集機５０を用いた編集システムにおける使用環境も考えられる。編集機５０は、上記図１に示したモニタ９と、操作部１１と、制御部１０の機能も備える。すなわち、編集機５０は、ユーザからの編集に関わる操作信号を受け付け、この操作信号に応じた制御信号Scを生成して仮想ＶＴＲ８を上述したように動作させる。そして、映像信号Svを受け取って画像表示部に表示し、再生用ＶＴＲ５１で再生した映像信号と共に、記録用ＶＴＲ５２に記録しながら、編集映像を作成していく。
【００６１】
【発明の効果】
本発明によれば、遠隔地などにある映像機器を、コンピュータネットワーク等の通信回線を用いて、あたかも近くにあるのと変わらない感覚で利用できるようになる。このため、遠隔地にある素材をいつでもリアルタイムに利用することができる。また、素材が入ったビデオテープ等のコピーを、各地にそれぞれ用意しなくて済む。また、普段使わない素材は、地価の安い郊外の施設で保管し、必要なときに通信回線経由で不自由なく利用できる。
【図面の簡単な説明】
【図１】本発明のデータ通信システムの具体例となる映像データ通信システムの概略構成を示すブロック図である。
【図２】上記映像データ通信システムのリモート側に設置したＩ／Ｆの詳細な構成を示すブロック図である。
【図３】上記映像データ通信システムのローカル側の要部の詳細な構成を示すブロック図である。
【図４】上記映像データ通信システムのローカル側で行われるキャッシュバッファ管理の具体例を説明するフローチャートである。
【図５】上記映像データ通信システムのローカル側に設けた仮想ＶＴＲの概略的な状態遷移図である。
【図６】通常動作時のキャッシュバッファの更新を説明するために用いる、映像データ中の時間位置（テープ中の位置）を示す図である。
【図７】順方向再生、逆方向再生時のキャッシュバッファの更新を説明するための図である。
【図８】キャッシュバッファの読み出し動作を説明するためのフローチャートである。
【図９】キャッシュバッファの書き込み動作を説明するためのフローチャートである。
【図１０】順方向キャッシュバッファ更新動作を詳細に説明するためのフローチャートである。
【図１１】逆方向キャッシュバッファ更新動作を詳細に説明するためのフローチャートである。
【図１２】本発明のデータ再生方法をプログラムとしたソフトウェアを実行するコンピュータの構成を示すブロック図である。
【図１３】上記コンピュータにおいてキャッシュバッファからデータを読み出すときのデータの流れを説明するための図である。
【図１４】上記コンピュータにおいてキャッシュバッファにデータを書き込むときのデータの流れを説明するための図である。
【図１５】キャッシュバッファの具体例となる、リングバッファの構造を示す図である。
【図１６】ローカル側を編集システムとしたときの構成を示すブロック図である。
【図１７】従来の映像再生システムのブロック図である。
【図１８】コンピュータネットワークを用いた映像送受信システムのブロック図である。
【符号の説明】
１ 映像データ通信システム、２ リモート側、３ 実ＶＴＲ、４ Ｉ／Ｆ、５ コンピュータネットワーク、６ ローカル側、７ ネットワークＩ／Ｆ、８仮想ＶＴＲ、９ モニタ、１０ 制御部、１１ 操作装置
Claims (9)
- 送信側からネットワークを介して送信されるデータを受信する通信手段と、
上記通信手段で受信したデータを内容順序にしたがって一時的に蓄積部に蓄積すると共に該蓄積部に蓄積されたデータを所望の再生位置から出力する受信側データ再生手段と、
上記蓄積部に蓄積されたデータの内容順序の終端から逆方向にα時間長分からなる順方向連続性補償データ範囲に上記再生位置が達したとき、上記通信手段を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求し、上記送信側から送信されたデータを上記蓄積部に内容順序にしたがって蓄積させ、上記蓄積部に蓄積されたデータの内容順序の始端から順方向にβ時間長分からなる逆方向連続性補償データ範囲に上記再生位置が達したとき、上記通信手段を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求し、上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させる制御手段とを備え、
上記制御手段は、上記αを、上記通信手段を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求してから上記送信側から送信されたデータにより上記蓄積部を更新し始めるまでに掛かる時間以上として上記順方向連続性補償データ範囲を設定し、上記βを、上記通信手段を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求してから上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させるまでに掛かる時間以上として上記逆方向連続性補償データ範囲を設定し、上記蓄積部に少なくとも（α＋３β）時間長分のデータを蓄積させるデータ再生装置。 - 上記受信側データ再生手段の蓄積部は、リングバッファである請求項１記載のデータ再生装置。
- 上記送信側には記録媒体からデータを再生する送信側データ再生手段が備えられ、この送信側データ再生手段で再生されたデータが上記ネットワークを介して上記通信手段に送信される請求項１記載のデータ再生装置。
- 送信側からネットワークを介して送信されてくるデータを通信部で受信する工程と、
上記データを内容順序にしたがって少なくとも（α＋３β）時間長分のデータを一時的に蓄積部に蓄積すると共に該蓄積部に蓄積されたデータを所望の再生位置から出力する受信側データ再生工程とを備え、
上記受信側データ再生工程では、上記蓄積部に蓄積されたデータの内容順序の終端から逆方向にα時間長分からなる順方向連続性補償データ範囲に上記再生位置が達したとき、上記通信部を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求し、上記送信側から送信されたデータを上記蓄積部に内容順序にしたがって蓄積させ、上記蓄積部に蓄積されたデータの内容順序の始端から順方向にβ時間長分からなる逆方向連続性補償データ範囲に上記再生位置が達したとき、上記通信部を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求し、上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させ、
上記αは、上記通信部を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求してから上記送信側から送信されたデータにより上記蓄積部を更新し始めるまでに掛かる時間以上であり、
上記βは、上記通信部を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求してから上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させるまでに掛かる時間以上であるデータ再生方法。 - 上記蓄積部は、リングバッファである請求項４記載のデータ再生方法。
- 上記送信側には記録媒体からデータを再生する送信側データ再生部が備えられ、この送信側データ再生部で再生されたデータが上記ネットワークを介して上記通信部に送信される請求項４記載のデータ再生方法。
- ネットワークを介してデータ送信手段から送信されるデータを受信して再生するデータ通信システムであって、
上記ネットワークを介して送信されてくるデータを受信して再生するデータ受信手段側に、送信側からネットワークを介して送信されるデータを受信する通信手段と、
上記通信手段で受信したデータを内容順序にしたがって一時的に蓄積部に蓄積すると共に該蓄積部に蓄積されたデータを所望の再生位置から出力する受信側データ再生手段と、
上記蓄積部に蓄積されたデータの内容順序の終端から逆方向にα時間長分からなる順方向連続性補償データ範囲に上記再生位置が達したとき、上記通信手段を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求し、上記送信側から送信されたデータを上記蓄積部に内容順序にしたがって蓄積させ、上記蓄積部に蓄積されたデータの内容順序の始端から順方向にβ時間長分からなる逆方向連続性補償データ範囲に上記再生位置が達したとき、上記通信手段を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求し、上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させる制御手段とを備え、
上記制御手段は、上記αを、上記通信手段を介して上記送信側に上記内容順序の終端から順方向のデータの送信を要求してから上記送信側から送信されたデータにより上記蓄積部を更新し始めるまでに掛かる時間以上として上記順方向連続性補償データ範囲を設定し、上記βを、上記通信手段を介して上記送信側に上記内容順序の始端から逆方向にβ時間長分のデータの送信を要求してから上記送信側から送信されたβ時間長分のデータを上記蓄積部に内容順序にしたがって蓄積させるまでに掛かる時間以上として上記逆方向連続性補償データ範囲を設定し、上記蓄積部に少なくとも（α＋３β）時間長分のデータを蓄積させるデータ通信システム。 - 上記受信側データ再生手段の蓄積部は、リングバッファである請求項７記載のデータ通信システム。
- 上記送信側には記録媒体からデータを再生する送信側データ再生手段が備えられ、この送信側データ再生手段で再生されたデータが上記ネットワークを介して上記通信手段に送信される請求項７記載のデータ通信システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP22862799A JP4366770B2 (ja) | 1999-08-12 | 1999-08-12 | データ再生装置及び方法、並びにデータ通信システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP22862799A JP4366770B2 (ja) | 1999-08-12 | 1999-08-12 | データ再生装置及び方法、並びにデータ通信システム |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2001054098A JP2001054098A (ja) | 2001-02-23 |
| JP2001054098A5 JP2001054098A5 (ja) | 2006-06-08 |
| JP4366770B2 true JP4366770B2 (ja) | 2009-11-18 |
Family
ID=16879314
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP22862799A Expired - Fee Related JP4366770B2 (ja) | 1999-08-12 | 1999-08-12 | データ再生装置及び方法、並びにデータ通信システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4366770B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7962942B1 (en) * | 2006-02-28 | 2011-06-14 | Rovi Guides, Inc. | Systems and methods for enhanced trick-play functions |
-
1999
- 1999-08-12 JP JP22862799A patent/JP4366770B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2001054098A (ja) | 2001-02-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5764893A (en) | Video-on-demand system uses adjusting positions of slots in a slot table to address additional image data distribution request from terminal devices | |
| JPH0998362A (ja) | マルチメディア通信システム | |
| US7536077B2 (en) | Method for sending information on a network, and electronic information equipment | |
| JP4366770B2 (ja) | データ再生装置及び方法、並びにデータ通信システム | |
| JP4206667B2 (ja) | データ記録再生装置及び方法 | |
| US8655139B2 (en) | Video recording and reproducing system and reading method of video data | |
| JP4253913B2 (ja) | 編集装置、データ記録再生装置及び編集素材記録方法 | |
| US7068916B2 (en) | Method of masking picture display transitions upon change-over of the video playback speed | |
| JPH08242423A (ja) | ディスク記録再生装置 | |
| JP2002010180A (ja) | 情報提供システム、映像編集システム及びその編集方法 | |
| US6785465B1 (en) | Disk apparatus, video/audio data processor, and video/audio control method that detect audiovisual frame information to control output | |
| EP0992993A1 (en) | Audiovisual data recording / reproducing system | |
| JP2014121049A (ja) | 記録装置、記録方法およびプログラム | |
| JP3596466B2 (ja) | 情報信号制御装置及び情報信号制御方法 | |
| JPH09116860A (ja) | 動画範囲選択方法及びビデオ編集装置 | |
| JP3141266B2 (ja) | 情報信号送出装置及び情報信号送受装置 | |
| JP2833511B2 (ja) | クライアントサーバ型マルチメディア再生方法及び再生システム | |
| JP2002094962A (ja) | 映像データ送受信システム、映像データ送受信方法および記録媒体 | |
| JPH0549026A (ja) | 映像編集再生方法 | |
| JPH06209474A (ja) | 映像提供システム | |
| JPH11275526A (ja) | ビデオサーバシステム | |
| US20040179812A1 (en) | Image recording and/or reproducing method and image processing apparatus | |
| JP2001218149A (ja) | ビデオテープ再生記録装置 | |
| JP2002010193A (ja) | データ記録再生装置及びデータ記録再生方法 | |
| JP2003169299A (ja) | 映像再生システム、映像再生装置、映像録画装置および映像再生方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060307 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060307 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090210 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090410 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090512 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090713 |
|
| 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: 20090804 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090817 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120904 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |