JP2003348175A - ネットワーク接続装置及びデータ転送方法 - Google Patents

Abstract

(57)【要約】 【課題】動画や音声などリアルタイム性を要求されるコ
ンテンツをネットワーク経由で転送し、コマ落ちや途切
れ等を回避して確実に記録・再生・編集することができ
るネットワーク接続装置及びそのデータ転送方法を提供
する。 【解決手段】ＬＡＮ１０に接続される各装置１、２、
３、４の内部にバッファ部１３、２３、３３、４３を設
け、送信側の装置及び受信側の装置それぞれがバッファ
のデータ蓄積量を管理して、通信状況に応じて相互に通
信及び自他の処理を制御する。バッファリングによって
データが途切れないように処理を制御し、データが途切
れそうになったら送信側及受信側の少なくとも一方の処
理を中断させてバッファ蓄積量の回復を待ち、ある程度
のデータ量が蓄積されたら処理を再開させる。動画や音
声のデータはＵＤＰプロトコルで送信し、他の装置に対
して処理の中止／再開を指令する制御コマンドはＴＣＰ
／ＩＰ経由で送る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明はネットワークに接続
される装置及びそれら装置間でデータを転送する方法に
係り、特に動画や音声などのリアルタイム性が要求され
るデータを送受信する技術に関する。

【０００２】

【従来の技術】特開平１１−８８８５６号公報は、ＭＰ
ＥＧ等リアルタイム性の高いデータをネットワーク経由
で伝送する場合の最適なパケット分割方法について述べ
られている。特開２０００−３５８０３３号公報は、機
器同士が互いに通信する前に自己処理可能な通信プロト
コルを通知し合うことにより、機器間で最適なデータ転
送を可能にする方法について開示している。特開平７−
４４２９１号公報は、マルチメディアコントローラによ
って他の機器の接続を自動的に検知して管理を行うシス
テムを開示している。

【０００３】

【発明が解決しようとする課題】しかしながら、上述し
た各公報においては、ネットワーク接続された装置間の
同期性の保証に関して言及していない。また、特開平１
０−１９１４６３号公報は、ＨＴＴＰプロトコルを利用
して動画転送を行うことが述べられているが、ここでの
「動画」はあくまで静止画の集まりとして転送されてお
り、ＨＴＴＰ転送プロトコルのみに限定されている。

【０００４】本発明はこのような事情に鑑みてなされた
もので、リアルタイム性を要求される動画等のコンテン
ツをＶＴＲ装置やＴＶ受像機などのリアルタイム性を要
求される装置上で表示、記録又は再生等する必要がある
場合に、データのリアルタイム伝送が損なわれる事態に
陥っても問題なく制御・視聴・操作等が可能で、コマ落
ちや途切れ等を回避できるネットワーク接続装置及びデ
ータ転送方法を提供することを目的とする。

【０００５】

【課題を解決するための手段】本発明は前記目的を達成
するために、ネットワークに接続するための通信インタ
ーフェース部と、前記通信インターフェース部を介して
送信又は受信するデータを一時的に記憶するバッファ
と、前記バッファに蓄積されるデータ量を監視するフロ
ー管理手段と、前記フロー管理手段で検出される前記バ
ッファ内のデータ量に応じて自己の動作を制御するとと
もに、前記ネットワークに接続されている他の装置に対
して制御信号を出力する制御手段と、を備えたことを特
徴としている。

【０００６】すなわち、本発明はネットワーク接続され
る装置の内部にバッファを設け、送信側の装置及び受信
側の装置それぞれがバッファのデータ蓄積量を管理し
て、通信状況に応じて相互に通信及び自他の処理を制御
する。ネットワーク経由で伝送されるデータが途切れな
いようにバッファリングによって処理を制御し、データ
が途切れそうになったら送信側及び受信側の少なくとも
一方の処理を中断させてバッファ蓄積量の回復を待ち、
ある程度のデータ量が蓄積されたら処理を再開する。デ
ータ転送のリアルタイム性は犠牲になり得るが、少なく
ともデータが途切れる事態を防止でき、同期性が確保さ
れる。

【０００７】また、本発明の他の態様は、ネットワーク
に接続された複数台の装置間でデータの受渡しを行うデ
ータ転送方法であって、送信側及び受信側の各装置にデ
ータを一時的に記憶するバッファと、前記バッファに蓄
積されたデータ量を監視するフロー管理手段とを設け、
前記送信側及び受信側の各装置がそれぞれ自己の前記フ
ロー管理手段で検出される前記バッファ内のデータ量に
基づいて自己及び他の装置の動作を制御することを特徴
としている。

【０００８】

【発明の実施の形態】以下添付図面に従って本発明に係
るネットワーク接続装置及びデータ転送方法の好ましい
実施の形態について詳説する。

【０００９】図１は、本発明を適用したＬＡＮ接続型ビ
デオテープレコーダ（ＶＴＲ）装置等から成るシステム
のブロック図である。本例では説明の便宜上、ネットワ
ーク接続装置の種類を限定しているが、本発明の適用範
囲は図１に示した例に限定されない。

【００１０】図１に示したシステムは、リアルタイム画
像データを処理するネットワークシステムであって、１
０ＢＡＳＥ−Ｔで代表されるＬＡＮ１０にＶＴＲ（Vide
o Tape Recorder ）１、ＶＴＲ２、ＴＶモニタ装置３及
びオーディオ装置４が接続されている。

【００１１】これら各装置（１〜４）内には、それぞれ
共通的な構成として、ＬＡＮ接続用インターフェース部
１１，２１，３１，４１と、各プロトコルを処理／応答
するＬＡＮ処理部１２，２２，３２，４２と、データを
蓄積するためのバッファ部１３，２３，３３，４３と、
バッファ部１３，２３，３３，４３から装置内の各処理
部にデータを読み書きするインターフェース部１４，２
４，３４，４４と、ＬＡＮ側及び装置内部側のデータを
遣り取りするフロー制御部として機能するＣＰＵ１５，
２５，３５，４５と、が設けられている。

【００１２】各装置（１〜４）は、上記の構成に加え
て、各装置に特有の機能を実現するために必要な構成を
備えている。すなわち、ＶＴＲ１及びＶＴＲ２は、画像
処理回路１６，２６及び磁気記録再生装置１７，２７を
備えている。ＴＶモニタ装置３は画像処理回路３６、Ｃ
ＲＴドライバ３７及びＣＲＴ３８を備えている。オーデ
ィオ装置４はオーディオ処理回路４６、アンプ４７Ｒ、
４７Ｌ及びスピーカ４８Ｒ、４８Ｌを備えている。

【００１３】ＬＡＮ１０には、上記各装置（１〜４）の
他、パソコン（ＰＣ）５を接続することが可能であり、
パソコン５からＬＡＮ１０経由で各装置（１〜４）を操
作することが可能である。パソコン５の構成は周知であ
るため詳細な構成について図示しないが、パソコン５は
ＬＡＮ接続用のアダプタ（ＬＡＮアダプタ）５１を備え
ている。

【００１４】ＶＴＲ１に記録済みビデオカセットテープ
６１を挿入すると、該ビデオカセットテープ６１に記録
されているデータは磁気記録再生装置１７によって再生
される。再生された動画像データは画像処理回路１６に
送られ、ここで各種復調処理を経て、例えば、ＭＰＥＧ
２データに変換される。同様に、音声は例えばＭＰ３デ
ータに変換され、装置内のバッファ部１３に送られる。
ＭＰＥＧ２データは、インターネットプロトコルのＵＤ
Ｐ（User Datagram Protocol）パケットに挿入できるよ
うに分解されて、直接コネクションを張っているＶＴＲ
２又はＴＶモニタ装置３に対して送信される。なお、Ｕ
ＤＰパケットの構造については図２で後述する。また、
ＭＰ３データも同様にパケット化され、ＵＤＰプロトコ
ルによってＶＴＲ２又はオーディオ装置４に対して送信
される。

【００１５】ＶＴＲ２によって録画を行う場合には、記
録可能なビデオカセットテープ６２をＶＴＲ２に挿入す
る。ＬＡＮ１０を経由してバッファ部２３に蓄えられた
動画像データは画像処理回路２６において記録用の信号
に変換され、その記録用信号が磁気記録再生装置２７を
介してビデオカセットテープ６２に記録される。

【００１６】図２に転送パケットの構造を示す。１つの
パケットの中は、図２のような層構造を有し、先頭はイ
ーサネット（登録商標）物理層のヘッダ、次いで、ＩＰ
プロトコル層のヘッダ、ＵＤＰ層のヘッダ、Ｉフレーム
／Ｐフレーム／Ｂフレームの区別を示す情報、タイムコ
ード（例えば、時分秒、フィールド番号、フレーム番号
などの情報を含む）、及びパケット分割数の情報（１つ
のフレームを複数のパケットで送る場合の分割数）など
の付属情報が含まれ、これら情報とともにＭＰＥＧパケ
ット１〜ｎが１つのパケットとして送られる。

【００１７】１の画面は複数のパケットに分割され、パ
ケットの何番目から何番目までが１つの画面を構成する
のかを把握できるように、各パケットにはパケット分割
数の情報が付加されている。また、タイムコードは時分
秒の情報及びフレーム番号（必要に応じてフィールド番
号）の情報を含んでいるため、タイムコード（ＴＣ）の
情報からも１画面を構成するパケット群を把握できる。

【００１８】ＭＰＥＧ特有の圧縮情報（Ｉフレーム／Ｐ
フレーム／Ｂフレームの区別を示す情報）は、ダビング
その他の動画編集の際に重要な役割を果たす。Ｉフレー
ムは１画面の中で閉じた圧縮をしているため、この画面
内情報だけで画像を再生できる。Ｐフレームは１つ前の
画面情報、Ｂフレームは前後の画面情報がなければ画像
を再生できない。したがって、シーンの切替えは必ずＩ
フレームで編集される。本実施形態における動画像デー
タのバッファリングや録画の制御はＩフレームを区切り
として行う。すなわち、バッファファリングエンドの目
安は、編集可能単位（バッファ最大量）かつＩフレーム
単位とし、録画の中断／再開についてもＩフレームのタ
イミングで制御する。

【００１９】次に、上記の如く構成されたシステムにお
いてＶＴＲ１を用いて音声付き動画のデータを再生し、
その再生データをＬＡＮ１０経由でＴＶモニタ装置３及
びオーディオ装置４に出力する場合の動作について説明
する。

【００２０】図３は制御の流れを示すフローチャートで
ある。まず、ＶＴＲ１にビデオカセットテープ６１を挿
入し（Ｓ１１０）、ＶＴＲ１本体又はパソコン５から再
生実行を指示する（Ｓ１１２）。再生指示が入力される
と、ＶＴＲ１は、ＴＣＰ／ＩＰプロトコルによって出力
対象装置（この場合、ＴＶモニタ装置３及びオーディオ
装置４）と接続を行い、コネクションを確立する（Ｓ１
１４）。このとき、受付可能フォーマット及びデータ形
式等についてお互いにネゴシエーションを行い、送信側
・受信側で共通かつ最もレベルの高いフォーマットに設
定する（Ｓ１１４、Ｓ２１４、Ｓ３１４）。

【００２１】コネクション及びネゴシエーションが確立
された後、ＶＴＲ１からオーバヘッドの小さい（誤り訂
正や再送処理のない）ＵＤＰプロトコルにて動画像デー
タを送信する（Ｓ１１６）。この場合、送信先（ＴＶモ
ニタ装置３及びオーディオ装置４）の受信が可能である
かを確認する必要があるが、送り始めの場合は両装置と
も、受信バッファ（バッファ部３３、４３）はエンプテ
ィであるので、問題なく受信を始めることができる。Ｔ
Ｖモニタ装置３及びオーディオ装置４は、ＶＴＲ１から
送られてくるデータを受信する（Ｓ２１６、Ｓ３１
６）。

【００２２】送信側（ＶＴＲ１）及び受信側（ＴＶモニ
タ装置３及びオーディオ装置４）は、それぞれ送信バッ
ファ（バッファ部１３）及び受信バッファ（バッファ部
３３、４３）のバッファリング量をリアルタイムで監視
し（Ｓ１１８、Ｓ２１８、Ｓ３１８）、バッファ蓄積量
が適正な量か否かを判定する（Ｓ１２０、Ｓ２２０、Ｓ
３２０）。

【００２３】すなわち、各装置のＣＰＵ１５、３５、４
５は、データ転送レートの変化から（パケット転送レー
ト）からバッファ部１３、３３、４３のエンプティを予
測し、再生処理等の制御を行う。

【００２４】ＴＶモニタ装置３のバッファ蓄積量が適正
であれば、再生処理を開始し（Ｓ２２２）、動画表示を
行う。また、オーディオ装置４にバッファ蓄積量が適正
であれば、再生処理を開始し（Ｓ３２２）、音声出力を
行う。

【００２５】仮に、何らかの原因でＬＡＮ１０上の転送
データ量が一時的に増加し、ＶＴＲ１からＴＶモニタ装
置３及びオーディオ装置４に転送するデータが減少した
場合、これら受信側の受信バッファ蓄積量が次第に減少
する。やがて、ＴＶモニタ装置３及びオーディオ装置４
の受信バッファがエンプティに近くなったことを、バッ
ファ部３３、４３の図示せぬ検出回路（例えば、FIFO回
路）が検出すると、その情報をＣＰＵ３５、４５に通知
する。バッファ量の検出は、FIFO回路でデータ量を検出
して信号を出力する構成でもよいし、ロジックを組んで
実現してもよく、ＣＰＵ３５、４５がフローコントロー
ルしてもよい。

【００２６】ＣＰＵ３５、４５は、通知された情報を基
にＬＡＮ１０経由のデータ転送レートと受信バッファ残
容量からデータ転送が間に合うか否か（データ転送が途
切れなく行われるか否か）を判断する（Ｓ２２０、Ｓ３
２０）。

【００２７】ＴＶモニタ装置３のＣＰＵ３５によってデ
ータ転送が間に合わないと判断された場合、ＣＰＵ３５
はバッファ部３３からの読み出し及び画像処理を中止し
（Ｓ２２４）、処理直前の画像を静止画として表示する
制御を行う（Ｓ２２６）と同時に、オーディオ装置４に
対してＴＣＰ／ＩＰ経由でミュート指示を送信する（Ｓ
２２８）。ミュート指示や後述する静止画表示指示な
ど、他の装置に対する制御コードについては、誤り訂正
チェックが行われるＴＣＰ／ＩＰのパケットで送られ
る。

【００２８】オーディオ装置４はミュート指示の入力を
判断し（Ｓ３５０）、ミュート指示の入力があった場合
には音声再生処理を中止して音声出力をミュートする
（Ｓ３５２）。

【００２９】ＴＶモニタ装置３はミュート指示を出力し
た後（Ｓ２２８）に、バッファ蓄積量の監視と判断の処
理を継続し（Ｓ２３０）、バッファ蓄積量が適正な値に
回復したら、再生処理を再開すると同時に（Ｓ２３
２）、オーディオ装置４に対して処理の再開を要求する
指示（再開指示）を出力する（Ｓ２３４）。オーディオ
装置４は再開指示の入力を判断し（Ｓ３５４）、再開指
示が入力されたときには音声再生処理を再開する（Ｓ３
５６）。こうして、動画表示及び音声出力が再開され
る。

【００３０】ＴＶモニタ装置３は、Ｓ２３４において再
開指示を出力した後、Ｓ２１６に戻る。一方、オーディ
オ装置４はＳ３５６において音声再生処理を再開した
後、Ｓ３１６に戻る。

【００３１】また、Ｓ３２０において、オーディオ装置
４側でも同じように受信バッファがエンプティになるこ
とが予想される場合、オーディオ装置４のＣＰＵ４５は
バッファ部４３からの読み出し及び音声処理を中止する
制御を行うと同時に（Ｓ３２４）、ＴＶモニタ装置３に
対して静止画表示の指示を送信する（Ｓ３２８）。ＴＶ
モニタ装置３は、静止画表示指示の入力を判断し（Ｓ２
５０）、静止画表示指示の入力があった場合には、動画
再生処理を中止するとともに（Ｓ２５２）、処理直前の
画像を静止画として表示する制御を行う（Ｓ２５３）。
これにより、動画出力が停止する。

【００３２】オーディオ装置４は、静止画表示指示を出
力した後（Ｓ３２８）に、バッファ蓄積量の監視と判断
の処理を継続し（Ｓ３３０）、バッファ蓄積量が適正な
値に回復したら、再生処理を再開すると同時に（Ｓ３３
２）、ＴＶモニタ装置３に対して再開開始の指示を出力
する（Ｓ３３４）。ＴＶモニタ装置３は再開指示の入力
を判断し（Ｓ２５４）、再開指示が入力されたときには
動画再生処理を再開する（Ｓ２５６）。こうして、動画
表示及び音声出力が再開される。

【００３３】ＴＶモニタ装置３は、Ｓ２５６において動
画再生処理を再開した後、Ｓ２１６に戻る。一方、オー
ディオ装置４はＳ３３４において再開指示を出力した
後、Ｓ３１６に戻る。

【００３４】送信側であるＶＴＲ１の処理が間に合わな
くなり、送信側のバッファ部１３がエンプティになりか
けた場合にも同様にして、Ｓ１２０においてバッファ蓄
積量不足と判断されると、ＴＶモニタ装置３及びオーデ
ィオ装置４それぞれに対して静止画表示指示・ミュート
指示を出力する（Ｓ１２７、Ｓ１２８）。こうして、Ｔ
Ｖモニタ装置３においては動画再生が中断され、静止画
表示となる（Ｓ２５０〜２５３）。また、オーディオ装
置４においては音声再生が中断され、音声の出力が停止
する（Ｓ３５０〜３５２）。このように、送信側、受信
側のバッファにそれぞれ一定量のデータが蓄えられるま
で出力側のデータ処理が中止される。

【００３５】ＶＴＲ１は、静止画表示指示（Ｓ１２７）
及びミュート指示（Ｓ１２８）を出力した後もバッファ
蓄積量の監視と判断の処理を継続し（Ｓ１３０）、バッ
ファ蓄積量が適正な値に回復したら、ＴＶモニタ装置３
及びオーディオ装置４に対して再開開始の指示を出力す
る（Ｓ１３４）。これにより、動画表示及び音声出力が
再開される（Ｓ２５４〜Ｓ２５６、Ｓ３５４〜３５
６）。

【００３６】ＶＴＲ１は、Ｓ１３４において再開指示を
出力した後、Ｓ１１６に戻る。また、Ｓ１２０において
バッファ量が適正であると判断した場合には、再生対象
の動画データの再生処理が終了したか否かの判断を行い
（Ｓ１６０）。再生途中であれば、Ｓ１１６に戻り、上
記処理を継続する。一方、ユーザによる再生終了の指示
が入力された場合、或いは再生対象の動画データを最後
まで再生し終えた場合などにはＳ１６０においてＹＥＳ
判定となる。この場合は、通信接続を解除して（Ｓ１６
２）、処理を終了する。

【００３７】ＴＶモニタ装置３における動画再生処理
中、Ｓ２５０において静止画表示指示の入力がない場合
は、通信接続が解除されたか否かを判断し（Ｓ２７
０）、接続状態が維持されていればＳ２１６に戻って上
記の処理を継続する一方、Ｓ２７０において通信接続が
解除された場合には処理を終了する。

【００３８】同様に、オーディオ装置４における音声再
生処理中、Ｓ３５０においてミュート指示の入力がない
場合は、通信接続が解除されたか否かを判断し（Ｓ３７
０）、接続状態が維持されていればＳ３１６に戻って上
記の処理を継続する一方、Ｓ３７０において通信接続が
解除された場合には処理を終了する。

【００３９】なお、図３では、バッファ蓄積量が回復し
たことを検出すると自動的に処理を再開しているが、ユ
ーザに再スタートの指示入力を促し、ユーザからの指示
入力を受けて処理を再開させてもよい。

【００４０】次に、ＶＴＲ１で再生からＶＴＲ２に向か
って動画像データの編集作業を行う場合を説明する。図
４は、編集動作の制御手順を示すフローチャートであ
る。

【００４１】まず、ＶＴＲ１及びＶＴＲ２の操作パネル
から直接、又はパソコン５から編集モードを指示する
（Ｓ４１０、Ｓ５１０）。指示が入力されると、対象装
置間（この場合、ＶＴＲ１とＶＴＲ２の間）でＴＣＰ／
ＩＰにてネゴシエーションを行い（Ｓ４１２、Ｓ５１
２）、最大公約数的な条件にて通信プロトコル、転送レ
ート、操作可能コマンド等を遣り取りして設定を行う。

【００４２】説明を簡単にするために、ＶＴＲ１からＶ
ＴＲ２に対して３０分の動画をダビングする例を述べ
る。ＶＴＲ１の操作パネルから直接、又はパソコン５か
らダビング開始の指示を入力すると（Ｓ４１４）、ＶＴ
Ｒ１−ＶＴＲ２間でそれぞれ再生モード（Ｓ４１６）、
録画モード（Ｓ５１６）に設定され、ＶＴＲ１は再生処
理を開始し（Ｓ４１８）、ＶＴＲ２は録画ポーズ（PAUS
E)状態で待機する（Ｓ５１８）。

【００４３】ＶＴＲ１側で再生及びデータの処理が行わ
れ、画像データがＬＡＮ１０経由でＶＴＲ２に転送され
る（Ｓ４２０）。この転送にはＵＤＰプロトコルを用い
る。ＶＴＲ２は、ＶＴＲ１から送られてくるデータをＬ
ＡＮ１０経由で受信する（Ｓ５２０）。

【００４４】ＶＴＲ２は受信データのバッファ蓄積量を
判断し（Ｓ５２２）、一定量のデータが蓄積されるまで
録画ポーズ状態を維持して（Ｓ５２４）、データ受信を
継続する（Ｓ５２０）。Ｓ５２２において、ＶＴＲ２側
で一定量のデータがバッファ部２３に蓄積されたと判断
されたら、ポーズ状態を解除して（Ｓ５２６）、ＶＴＲ
２側は録画を開始する（Ｓ５２８）。

【００４５】ＶＴＲ１は、所定時間分（例えば、３０
分）の動画再生を終えるまで、再生処理（Ｓ４１８）と
データ送信処理（Ｓ４２０）を継続する。所定時間分の
動画再生が終了したことを検出したら（Ｓ４２２）、Ｖ
ＴＲ１は再生を停止し（Ｓ４２４）、待機モードに移行
すると同時に（Ｓ４２６）、その旨をＶＴＲ２に通知す
る（Ｓ４２８）。

【００４６】ＶＴＲ２は、このコマンド（待機モード状
態の通知）の入力を判断し（Ｓ５３０）、入力がなけれ
ばＳ５２０に戻って上記処理（Ｓ５２０〜Ｓ５３０）を
継続する。Ｓ５３０においてコマンドの入力を検出する
と、バッファ量を判断し（Ｓ５３２）、バッファ部２３
がエンプティになるまで録画を続ける（Ｓ５２８〜Ｓ５
３２）。バッファ部２３内のデータを全て記録し終えた
ら、録画ポーズ状態に移行して（Ｓ５３４）、処理を終
了する。

【００４７】仮に、データ転送中にＬＡＮ１０内部のデ
ータ流量が、何らかの要因で増加し、ＶＴＲ１からＶＴ
Ｒ２の転送データ量が間に合わなくなったと判断された
場合（Ｓ５２２においてＮＯ判定の場合）、上記説明し
たのと同様にして、ＶＴＲ２を録画ポーズモードにし
（Ｓ５２４）、ＶＴＲ２側のバッファ蓄積量が一定量に
回復するまで記録動作を停止する。

【００４８】上述した通り、本実施形態によれば、デー
タ転送レートの変化から（パケット転送レート）から、
バッファ部２３のエンプティを予測し、エンプティ到達
前にＶＴＲ２の記録（REC)／ポーズ(PAUSE) の制御を行
うようにしたので、仮に、ＬＡＮ１０上の転送データ量
が一時的に増加してリアルタイムデータの転送処理が間
に合わなくなっても、不都合なく、リアルタイムデータ
のＬＡＮ経由処理が可能となる。また、動画データにつ
いてはＵＤＰパケットで送信する一方、他の装置を制御
するコマンド（ミュート指示や静止画表示指示など）に
ついては、ＴＣＰパケットを用い、最優先転送の短いコ
ントロールメッセージを遣り取りすることで、バッファ
オーバーフロー、或いはアンダーフローチャートするこ
となしに動画データのリアルタイム転送及び受渡しが可
能になる。

【００４９】磁気テープなどの連続媒体を使用して動画
等のデータを記録／再生する場合、途中で乱れたり、途
切れたりすることは致命的な失敗となるが、本発明によ
れば、送信側と受信側とがそれぞれバッファ量を監視し
ながら、両者がある程度同期して動き、データ転送が途
切れそうになったら処理を中断し、バッファをためて一
定量のデータ蓄積を行ってから処理を再開するので、確
実に動画を記録することができる。これにより、画面が
乱れたり、コマ落ちしたりせずに、滑らかな動画映像を
記録／再生することができる。もちろん、本発明の適用
範囲は、磁気テープなどの連続媒体を使用する装置に限
定されるものではなく、半導体メモリ、磁気ディスク、
光ディスク、光磁気ディスクなど、様々な記録媒体を使
用する装置にも適用できる。

【００５０】また、図２で説明したように、パケット内
にフレーム番号とＩ／Ｐ／Ｂフレームのデータ情報を同
時に乗せて、これら情報を転送バッファリングや録画の
コントロール（ＴＣタイムコード形式）用として用いる
ようにしたので、中断された動画のつなぎ目を滑らかに
連結させることができる。

【００５１】本実施形態によれば、ＬＡＮ１０に接続さ
れたＶＴＲ１、２、ＴＶモニタ装置３、オーディオ装置
４など、リアルタイム伝送が必要とされる装置に、フロ
ーコントロール付きのバッファを設け、バッファ内のデ
ータ量を監視しながら、送受信をコントロールすること
により、リアルタイム性が保てなくなったときにも、支
障なく制御・視聴・操作することが可能となる。

【００５２】本実施形態によれば、リアルタイムデータ
転送の保証されていない伝送系経由で動画データや音声
データ等のリアルタイムデータを伝送しても、問題無く
リアルタイムデータを扱うことが可能になる。したがっ
て、伝送路に専用線を用いる必要がなく、また、大きな
帯域を占有することがないため、安価なネットワーク経
由でデータ伝送が可能になる。非同期伝送によって実質
タイムラグがあっても、リアルタイムに録画・再生・編
集等が可能である。

【００５３】なお、本例ではフローコントロール付きの
バッファとして半導体メモリを用いているが、本発明の
実施に際しては、これに限定されず、ハードディスク、
光ディスク、フラッシュメモリ等の不揮発性メモリで置
き換えることも可能である。

【００５４】本発明の実施に際しては、上記した実施形
態に限定されない。例えば、以下に示す変形例がある。

【００５５】〔変形例１〕 ＶＴＲ１、２のテープダメ
ージ防止の観点から、一定時間以上（例えば、５分以
上）データ転送が中断された場合には、録画ポーズモー
ドから「ストップ（STOP) モード」に遷移させる。ダビ
ング等の編集途中で「ストップモード」になった場合、
送信側サイトに再接続（リトライ）を行う。予め設定さ
れているリトライ回数リミットまでリトライを繰り返し
ても、処理を再開できなかった場合には、編集処理を終
了するとともに、「録画失敗」の旨を告知する表示を行
う。

【００５６】〔変形例２〕 テレビ放送の分野において
は、番組放送において各地域のコマーシャル（ＣＭ）の
切替えを制御するために、放送信号の中にＣＭ切替え用
の同期信号（ＣＭのプログラム番号など）が含まれてい
ることがある。このようなＣＭ信号、或いは番組の開始
／終了信号を利用してバッファリング量をコントロール
し、ＣＭ分のデータをバッファリングして、編集時にそ
のＣＭデータを破棄し、番組本編分のデータをあらため
てバッファリングしてから録画用のデータの送受信を行
う。これにより、ＣＭをカットした番組録画が可能とな
る。また、番組の切り替わり点で画像をつなぐため、レ
コーディング開始によるレインボーノイズの発生やつな
ぎ目の乱れが発生しないという利点がある。

【００５７】〔変形例３〕 通常、リアルタイム動画の
転送時には１００Ｍbit クラスの帯域を占有してしま
う。このようなデータをＷＡＮ（Wide Area Network ）
に流出させると、他のネットワーク利用者に迷惑をかけ
ることも予想される。そこで、本発明の実施に際して、
帯域予約プロトコル（ＲＳＶＰ）により、ＬＡＮ１０の
転送データをルータの外に出さないように構成する態様
がある。家庭内ＬＡＮ（例えば、ギガビットＬＡＮ）の
構築によって図１のようにＶＴＲ１、２、ＴＶモニタ装
置３、オーディオ装置４及びパソコン５を接続し、ルー
タを介して家庭内ＬＡＮとＷＡＮを接続する構成とす
る。こうして、家庭内ＬＡＮの中で動画データの受渡し
を行い、ルータの外にデータを流出させないことによ
り、上述のコントロール編集／記録／再生時における帯
域の占有という問題が回避され、ＬＡＮ内のデータ転送
処理がルータ外部のＷＡＮ側に影響を与えない。

【００５８】〔変形例４〕 本発明によれば、非同期式
（asynchronous）伝送経路を用いて動画や音声データな
どの同期記録再生が可能となる。すなわち、ネットワー
クに接続される各対象装置にある程度大容量のバッファ
を設け、バッファ内に一定量データが溜まったら各装置
がそれぞれＯＫ信号を出して、同期して記録・再生・編
集を行う。複数の対象装置のうち、バッファ蓄積の最も
遅い装置が一斉通報（ブロードキャスト）を用いてタイ
ミング信号を送出する。これにより、擬似的にリアルタ
イム記録・再生・編集を実現できる。

【００５９】

【発明の効果】以上説明したように本発明によれば、ネ
ットワーク接続される装置の内部にバッファを設け、送
信側の装置及び受信側の装置それぞれがバッファのデー
タ蓄積量を管理して、通信状況に応じて相互に通信及び
処理を制御するようにしたので、動画や音声などリアル
タイム性を要求されるコンテンツを確実に記録・再生・
編集することができる。

【図面の簡単な説明】

【図１】本発明を適用したＬＡＮ接続型ＶＴＲ装置等か
ら成るシステムのブロック図

【図２】ＭＰＥＧデータを転送する際のパケットの構造
を示す図

【図３】本実施形態に係るシステムの制御例を示すフロ
ーチャート

【図４】本実施形態に係るシステムの他の制御例を示す
フローチャート

【符号の説明】

１，２…ＶＴＲ、３…ＴＶモニタ装置、４…オーディオ
装置、５…パソコン、１０…ＬＡＮ、１２，２２，３
２，４２…ＬＡＮ処理部、１３，２３，３３，４３…バ
ッファ部、１５，２５，３５，４５…ＣＰＵ

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5C053 FA15 FA21 FA27 GB06 GB21 GB37 HA27 HA33 KA01 LA15 5C059 KK35 RB02 RC32 RE15 RE16 RE20 SS08 TA71 TB01 TC16 TC21 UA34 5K030 HA08 HB01 HB02 KA03 LC01 LC09 MA13 MB04 MB12 5K034 AA02 CC02 CC05 DD03 HH50

Claims (2)

【特許請求の範囲】
1. 【請求項１】 ネットワークに接続するための通信イン
   ターフェース部と、 前記通信インターフェース部を介して送信又は受信する
   データを一時的に記憶するバッファと、 前記バッファに蓄積されるデータ量を監視するフロー管
   理手段と、 前記フロー管理手段で検出される前記バッファ内のデー
   タ量に応じて自己の動作を制御するとともに、前記ネッ
   トワークに接続されている他の装置に対して制御信号を
   出力する制御手段と、 を備えたことを特徴とするネットワーク接続装置。
2. 【請求項２】 ネットワークに接続された複数台の装置
   間でデータの受渡しを行うデータ転送方法であって、 送信側及び受信側の各装置にデータを一時的に記憶する
   バッファと、前記バッファに蓄積されたデータ量を監視
   するフロー管理手段とを設け、前記送信側及び受信側の
   各装置がそれぞれ自己の前記フロー管理手段で検出され
   る前記バッファ内のデータ量に基づいて自己及び他の装
   置の動作を制御することを特徴とするデータ転送方法。