JP4062725B2 - データ転送方法 - Google Patents
データ転送方法 Download PDFInfo
- Publication number
- JP4062725B2 JP4062725B2 JP2002155911A JP2002155911A JP4062725B2 JP 4062725 B2 JP4062725 B2 JP 4062725B2 JP 2002155911 A JP2002155911 A JP 2002155911A JP 2002155911 A JP2002155911 A JP 2002155911A JP 4062725 B2 JP4062725 B2 JP 4062725B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- buffer
- vtr
- audio
- devices
- 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
Description
【０００１】
【発明の属する技術分野】
本発明はネットワークに接続される装置及びそれら装置間でデータを転送する方法に係り、特に動画や音声などのリアルタイム性が要求されるデータを送受信する技術に関する。
【０００２】
【従来の技術】
特開平１１−８８８５６号公報は、ＭＰＥＧ等リアルタイム性の高いデータをネットワーク経由で伝送する場合の最適なパケット分割方法について述べられている。特開２０００−３５８０３３号公報は、機器同士が互いに通信する前に自己処理可能な通信プロトコルを通知し合うことにより、機器間で最適なデータ転送を可能にする方法について開示している。特開平７−４４２９１号公報は、マルチメディアコントローラによって他の機器の接続を自動的に検知して管理を行うシステムを開示している。
【０００３】
【発明が解決しようとする課題】
しかしながら、上述した各公報においては、ネットワーク接続された装置間の同期性の保証に関して言及していない。また、特開平１０−１９１４６３号公報は、ＨＴＴＰプロトコルを利用して動画転送を行うことが述べられているが、ここでの「動画」はあくまで静止画の集まりとして転送されており、ＨＴＴＰ転送プロトコルのみに限定されている。
【０００４】
本発明はこのような事情に鑑みてなされたもので、リアルタイム性を要求される動画等のコンテンツをＶＴＲ装置やＴＶ受像機などのリアルタイム性を要求される装置上で表示、記録又は再生等する必要がある場合に、データのリアルタイム伝送が損なわれる事態に陥っても問題なく制御・視聴・操作等が可能で、コマ落ちや途切れ等を回避できるネットワーク接続装置及びデータ転送方法を提供することを目的とする。
【０００５】
【課題を解決するための手段】
本発明は前記目的を達成するために、ネットワークに接続された複数台の装置間でデータの受渡しを行うデータ転送方法であって、送信側及び受信側の各装置にデータを一時的に記憶するバッファと、前記バッファに蓄積されたデータ量を監視するフロー管理手段とを設け、前記送信側及び受信側の各装置がそれぞれ自己の前記フロー管理手段で検出される前記バッファ内のデータ量に基づいて自己及び他の装置の動作を制御し、更に、前記送信側及び受信側の各装置のうち前記バッファの蓄積が最も遅い装置から他の装置すべてに対して出力されるタイミング信号によって前記送信側及び受信側の各装置が同期した動作を行うことを特徴としている。
【０００６】
すなわち、本発明はネットワーク接続される装置の内部にバッファを設け、送信側の装置及び受信側の装置それぞれがバッファのデータ蓄積量を管理して、通信状況に応じて相互に通信及び自他の処理を制御する。ネットワーク経由で伝送されるデータが途切れないようにバッファリングによって処理を制御し、データが途切れそうになったら送信側及び受信側の少なくとも一方の処理を中断させてバッファ蓄積量の回復を待ち、ある程度のデータ量が蓄積されたら処理を再開する。データ転送のリアルタイム性は犠牲になり得るが、少なくともデータが途切れる事態を防止でき、同期性が確保される。
【０００８】
【発明の実施の形態】
以下添付図面に従って本発明に係るネットワーク接続装置及びデータ転送方法の好ましい実施の形態について詳説する。
【０００９】
図１は、本発明を適用したＬＡＮ接続型ビデオテープレコーダ（ＶＴＲ）装置等から成るシステムのブロック図である。本例では説明の便宜上、ネットワーク接続装置の種類を限定しているが、本発明の適用範囲は図１に示した例に限定されない。
【００１０】
図１に示したシステムは、リアルタイム画像データを処理するネットワークシステムであって、１０ＢＡＳＥ−Ｔで代表されるＬＡＮ１０にＶＴＲ（Video Tape Recorder ）１、ＶＴＲ２、ＴＶモニタ装置３及びオーディオ装置４が接続されている。
【００１１】
これら各装置（１〜４）内には、それぞれ共通的な構成として、ＬＡＮ接続用インターフェース部１１，２１，３１，４１と、各プロトコルを処理／応答するＬＡＮ処理部１２，２２，３２，４２と、データを蓄積するためのバッファ部１３，２３，３３，４３と、バッファ部１３，２３，３３，４３から装置内の各処理部にデータを読み書きするインターフェース部１４，２４，３４，４４と、ＬＡＮ側及び装置内部側のデータを遣り取りするフロー制御部として機能するＣＰＵ１５，２５，３５，４５と、が設けられている。
【００１２】
各装置（１〜４）は、上記の構成に加えて、各装置に特有の機能を実現するために必要な構成を備えている。すなわち、ＶＴＲ１及びＶＴＲ２は、画像処理回路１６，２６及び磁気記録再生装置１７，２７を備えている。ＴＶモニタ装置３は画像処理回路３６、ＣＲＴドライバ３７及びＣＲＴ３８を備えている。オーディオ装置４はオーディオ処理回路４６、アンプ４７Ｒ、４７Ｌ及びスピーカ４８Ｒ、４８Ｌを備えている。
【００１３】
ＬＡＮ１０には、上記各装置（１〜４）の他、パソコン（ＰＣ）５を接続することが可能であり、パソコン５からＬＡＮ１０経由で各装置（１〜４）を操作することが可能である。パソコン５の構成は周知であるため詳細な構成について図示しないが、パソコン５はＬＡＮ接続用のアダプタ（ＬＡＮアダプタ）５１を備えている。
【００１４】
ＶＴＲ１に記録済みビデオカセットテープ６１を挿入すると、該ビデオカセットテープ６１に記録されているデータは磁気記録再生装置１７によって再生される。再生された動画像データは画像処理回路１６に送られ、ここで各種復調処理を経て、例えば、ＭＰＥＧ２データに変換される。同様に、音声は例えばＭＰ３データに変換され、装置内のバッファ部１３に送られる。ＭＰＥＧ２データは、インターネットプロトコルのＵＤＰ（User Datagram Protocol）パケットに挿入できるように分解されて、直接コネクションを張っているＶＴＲ２又はＴＶモニタ装置３に対して送信される。なお、ＵＤＰパケットの構造については図２で後述する。また、ＭＰ３データも同様にパケット化され、ＵＤＰプロトコルによってＶＴＲ２又はオーディオ装置４に対して送信される。
【００１５】
ＶＴＲ２によって録画を行う場合には、記録可能なビデオカセットテープ６２をＶＴＲ２に挿入する。ＬＡＮ１０を経由してバッファ部２３に蓄えられた動画像データは画像処理回路２６において記録用の信号に変換され、その記録用信号が磁気記録再生装置２７を介してビデオカセットテープ６２に記録される。
【００１６】
図２に転送パケットの構造を示す。１つのパケットの中は、図２のような層構造を有し、先頭はイーサネット物理層のヘッダ、次いで、ＩＰプロトコル層のヘッダ、ＵＤＰ層のヘッダ、Ｉフレーム／Ｐフレーム／Ｂフレームの区別を示す情報、タイムコード（例えば、時分秒、フィールド番号、フレーム番号などの情報を含む）、及びパケット分割数の情報（１つのフレームを複数のパケットで送る場合の分割数）などの付属情報が含まれ、これら情報とともにＭＰＥＧパケット１〜ｎが１つのパケットとして送られる。
【００１７】
１の画面は複数のパケットに分割され、パケットの何番目から何番目までが１つの画面を構成するのかを把握できるように、各パケットにはパケット分割数の情報が付加されている。また、タイムコードは時分秒の情報及びフレーム番号（必要に応じてフィールド番号）の情報を含んでいるため、タイムコード（ＴＣ）の情報からも１画面を構成するパケット群を把握できる。
【００１８】
ＭＰＥＧ特有の圧縮情報（Ｉフレーム／Ｐフレーム／Ｂフレームの区別を示す情報）は、ダビングその他の動画編集の際に重要な役割を果たす。Ｉフレームは１画面の中で閉じた圧縮をしているため、この画面内情報だけで画像を再生できる。Ｐフレームは１つ前の画面情報、Ｂフレームは前後の画面情報がなければ画像を再生できない。したがって、シーンの切替えは必ずＩフレームで編集される。本実施形態における動画像データのバッファリングや録画の制御はＩフレームを区切りとして行う。すなわち、バッファファリングエンドの目安は、編集可能単位（バッファ最大量）かつＩフレーム単位とし、録画の中断／再開についてもＩフレームのタイミングで制御する。
【００１９】
次に、上記の如く構成されたシステムにおいてＶＴＲ１を用いて音声付き動画のデータを再生し、その再生データをＬＡＮ１０経由でＴＶモニタ装置３及びオーディオ装置４に出力する場合の動作について説明する。
【００２０】
図３は制御の流れを示すフローチャートである。まず、ＶＴＲ１にビデオカセットテープ６１を挿入し（Ｓ１１０）、ＶＴＲ１本体又はパソコン５から再生実行を指示する（Ｓ１１２）。再生指示が入力されると、ＶＴＲ１は、ＴＣＰ／ＩＰプロトコルによって出力対象装置（この場合、ＴＶモニタ装置３及びオーディオ装置４）と接続を行い、コネクションを確立する（Ｓ１１４）。このとき、受付可能フォーマット及びデータ形式等についてお互いにネゴシエーションを行い、送信側・受信側で共通かつ最もレベルの高いフォーマットに設定する（Ｓ１１４、Ｓ２１４、Ｓ３１４）。
【００２１】
コネクション及びネゴシエーションが確立された後、ＶＴＲ１からオーバヘッドの小さい（誤り訂正や再送処理のない）ＵＤＰプロトコルにて動画像データを送信する（Ｓ１１６）。この場合、送信先（ＴＶモニタ装置３及びオーディオ装置４）の受信が可能であるかを確認する必要があるが、送り始めの場合は両装置とも、受信バッファ（バッファ部３３、４３）はエンプティであるので、問題なく受信を始めることができる。ＴＶモニタ装置３及びオーディオ装置４は、ＶＴＲ１から送られてくるデータを受信する（Ｓ２１６、Ｓ３１６）。
【００２２】
送信側（ＶＴＲ１）及び受信側（ＴＶモニタ装置３及びオーディオ装置４）は、それぞれ送信バッファ（バッファ部１３）及び受信バッファ（バッファ部３３、４３）のバッファリング量をリアルタイムで監視し（Ｓ１１８、Ｓ２１８、Ｓ３１８）、バッファ蓄積量が適正な量か否かを判定する（Ｓ１２０、Ｓ２２０、Ｓ３２０）。
【００２３】
すなわち、各装置のＣＰＵ１５、３５、４５は、データ転送レートの変化から（パケット転送レート）からバッファ部１３、３３、４３のエンプティを予測し、再生処理等の制御を行う。
【００２４】
ＴＶモニタ装置３のバッファ蓄積量が適正であれば、再生処理を開始し（Ｓ２２２）、動画表示を行う。また、オーディオ装置４にバッファ蓄積量が適正であれば、再生処理を開始し（Ｓ３２２）、音声出力を行う。
【００２５】
仮に、何らかの原因でＬＡＮ１０上の転送データ量が一時的に増加し、ＶＴＲ１からＴＶモニタ装置３及びオーディオ装置４に転送するデータが減少した場合、これら受信側の受信バッファ蓄積量が次第に減少する。やがて、ＴＶモニタ装置３及びオーディオ装置４の受信バッファがエンプティに近くなったことを、バッファ部３３、４３の図示せぬ検出回路（例えば、FIFO回路）が検出すると、その情報をＣＰＵ３５、４５に通知する。バッファ量の検出は、FIFO回路でデータ量を検出して信号を出力する構成でもよいし、ロジックを組んで実現してもよく、ＣＰＵ３５、４５がフローコントロールしてもよい。
【００２６】
ＣＰＵ３５、４５は、通知された情報を基にＬＡＮ１０経由のデータ転送レートと受信バッファ残容量からデータ転送が間に合うか否か（データ転送が途切れなく行われるか否か）を判断する（Ｓ２２０、Ｓ３２０）。
【００２７】
ＴＶモニタ装置３のＣＰＵ３５によってデータ転送が間に合わないと判断された場合、ＣＰＵ３５はバッファ部３３からの読み出し及び画像処理を中止し（Ｓ２２４）、処理直前の画像を静止画として表示する制御を行う（Ｓ２２６）と同時に、オーディオ装置４に対してＴＣＰ／ＩＰ経由でミュート指示を送信する（Ｓ２２８）。ミュート指示や後述する静止画表示指示など、他の装置に対する制御コードについては、誤り訂正チェックが行われるＴＣＰ／ＩＰのパケットで送られる。
【００２８】
オーディオ装置４はミュート指示の入力を判断し（Ｓ３５０）、ミュート指示の入力があった場合には音声再生処理を中止して音声出力をミュートする（Ｓ３５２）。
【００２９】
ＴＶモニタ装置３はミュート指示を出力した後（Ｓ２２８）に、バッファ蓄積量の監視と判断の処理を継続し（Ｓ２３０）、バッファ蓄積量が適正な値に回復したら、再生処理を再開すると同時に（Ｓ２３２）、オーディオ装置４に対して処理の再開を要求する指示（再開指示）を出力する（Ｓ２３４）。オーディオ装置４は再開指示の入力を判断し（Ｓ３５４）、再開指示が入力されたときには音声再生処理を再開する（Ｓ３５６）。こうして、動画表示及び音声出力が再開される。
【００３０】
ＴＶモニタ装置３は、Ｓ２３４において再開指示を出力した後、Ｓ２１６に戻る。一方、オーディオ装置４はＳ３５６において音声再生処理を再開した後、Ｓ３１６に戻る。
【００３１】
また、Ｓ３２０において、オーディオ装置４側でも同じように受信バッファがエンプティになることが予想される場合、オーディオ装置４のＣＰＵ４５はバッファ部４３からの読み出し及び音声処理を中止する制御を行うと同時に（Ｓ３２４）、ＴＶモニタ装置３に対して静止画表示の指示を送信する（Ｓ３２８）。ＴＶモニタ装置３は、静止画表示指示の入力を判断し（Ｓ２５０）、静止画表示指示の入力があった場合には、動画再生処理を中止するとともに（Ｓ２５２）、処理直前の画像を静止画として表示する制御を行う（Ｓ２５３）。これにより、動画出力が停止する。
【００３２】
オーディオ装置４は、静止画表示指示を出力した後（Ｓ３２８）に、バッファ蓄積量の監視と判断の処理を継続し（Ｓ３３０）、バッファ蓄積量が適正な値に回復したら、再生処理を再開すると同時に（Ｓ３３２）、ＴＶモニタ装置３に対して再開開始の指示を出力する（Ｓ３３４）。ＴＶモニタ装置３は再開指示の入力を判断し（Ｓ２５４）、再開指示が入力されたときには動画再生処理を再開する（Ｓ２５６）。こうして、動画表示及び音声出力が再開される。
【００３３】
ＴＶモニタ装置３は、Ｓ２５６において動画再生処理を再開した後、Ｓ２１６に戻る。一方、オーディオ装置４はＳ３３４において再開指示を出力した後、Ｓ３１６に戻る。
【００３４】
送信側であるＶＴＲ１の処理が間に合わなくなり、送信側のバッファ部１３がエンプティになりかけた場合にも同様にして、Ｓ１２０においてバッファ蓄積量不足と判断されると、ＴＶモニタ装置３及びオーディオ装置４それぞれに対して静止画表示指示・ミュート指示を出力する（Ｓ１２７、Ｓ１２８）。こうして、ＴＶモニタ装置３においては動画再生が中断され、静止画表示となる（Ｓ２５０〜２５３）。また、オーディオ装置４においては音声再生が中断され、音声の出力が停止する（Ｓ３５０〜３５２）。このように、送信側、受信側のバッファにそれぞれ一定量のデータが蓄えられるまで出力側のデータ処理が中止される。
【００３５】
ＶＴＲ１は、静止画表示指示（Ｓ１２７）及びミュート指示（Ｓ１２８）を出力した後もバッファ蓄積量の監視と判断の処理を継続し（Ｓ１３０）、バッファ蓄積量が適正な値に回復したら、ＴＶモニタ装置３及びオーディオ装置４に対して再開開始の指示を出力する（Ｓ１３４）。これにより、動画表示及び音声出力が再開される（Ｓ２５４〜Ｓ２５６、Ｓ３５４〜３５６）。
【００３６】
ＶＴＲ１は、Ｓ１３４において再開指示を出力した後、Ｓ１１６に戻る。また、Ｓ１２０においてバッファ量が適正であると判断した場合には、再生対象の動画データの再生処理が終了したか否かの判断を行い（Ｓ１６０）。再生途中であれば、Ｓ１１６に戻り、上記処理を継続する。一方、ユーザによる再生終了の指示が入力された場合、或いは再生対象の動画データを最後まで再生し終えた場合などにはＳ１６０においてＹＥＳ判定となる。この場合は、通信接続を解除して（Ｓ１６２）、処理を終了する。
【００３７】
ＴＶモニタ装置３における動画再生処理中、Ｓ２５０において静止画表示指示の入力がない場合は、通信接続が解除されたか否かを判断し（Ｓ２７０）、接続状態が維持されていればＳ２１６に戻って上記の処理を継続する一方、Ｓ２７０において通信接続が解除された場合には処理を終了する。
【００３８】
同様に、オーディオ装置４における音声再生処理中、Ｓ３５０においてミュート指示の入力がない場合は、通信接続が解除されたか否かを判断し（Ｓ３７０）、接続状態が維持されていればＳ３１６に戻って上記の処理を継続する一方、Ｓ３７０において通信接続が解除された場合には処理を終了する。
【００３９】
なお、図３では、バッファ蓄積量が回復したことを検出すると自動的に処理を再開しているが、ユーザに再スタートの指示入力を促し、ユーザからの指示入力を受けて処理を再開させてもよい。
【００４０】
次に、ＶＴＲ１で再生からＶＴＲ２に向かって動画像データの編集作業を行う場合を説明する。図４は、編集動作の制御手順を示すフローチャートである。
【００４１】
まず、ＶＴＲ１及びＶＴＲ２の操作パネルから直接、又はパソコン５から編集モードを指示する（Ｓ４１０、Ｓ５１０）。指示が入力されると、対象装置間（この場合、ＶＴＲ１とＶＴＲ２の間）でＴＣＰ／ＩＰにてネゴシエーションを行い（Ｓ４１２、Ｓ５１２）、最大公約数的な条件にて通信プロトコル、転送レート、操作可能コマンド等を遣り取りして設定を行う。
【００４２】
説明を簡単にするために、ＶＴＲ１からＶＴＲ２に対して３０分の動画をダビングする例を述べる。ＶＴＲ１の操作パネルから直接、又はパソコン５からダビング開始の指示を入力すると（Ｓ４１４）、ＶＴＲ１−ＶＴＲ２間でそれぞれ再生モード（Ｓ４１６）、録画モード（Ｓ５１６）に設定され、ＶＴＲ１は再生処理を開始し（Ｓ４１８）、ＶＴＲ２は録画ポーズ（PAUSE)状態で待機する（Ｓ５１８）。
【００４３】
ＶＴＲ１側で再生及びデータの処理が行われ、画像データがＬＡＮ１０経由でＶＴＲ２に転送される（Ｓ４２０）。この転送にはＵＤＰプロトコルを用いる。ＶＴＲ２は、ＶＴＲ１から送られてくるデータをＬＡＮ１０経由で受信する（Ｓ５２０）。
【００４４】
ＶＴＲ２は受信データのバッファ蓄積量を判断し（Ｓ５２２）、一定量のデータが蓄積されるまで録画ポーズ状態を維持して（Ｓ５２４）、データ受信を継続する（Ｓ５２０）。Ｓ５２２において、ＶＴＲ２側で一定量のデータがバッファ部２３に蓄積されたと判断されたら、ポーズ状態を解除して（Ｓ５２６）、ＶＴＲ２側は録画を開始する（Ｓ５２８）。
【００４５】
ＶＴＲ１は、所定時間分（例えば、３０分）の動画再生を終えるまで、再生処理（Ｓ４１８）とデータ送信処理（Ｓ４２０）を継続する。所定時間分の動画再生が終了したことを検出したら（Ｓ４２２）、ＶＴＲ１は再生を停止し（Ｓ４２４）、待機モードに移行すると同時に（Ｓ４２６）、その旨をＶＴＲ２に通知する（Ｓ４２８）。
【００４６】
ＶＴＲ２は、このコマンド（待機モード状態の通知）の入力を判断し（Ｓ５３０）、入力がなければＳ５２０に戻って上記処理（Ｓ５２０〜Ｓ５３０）を継続する。Ｓ５３０においてコマンドの入力を検出すると、バッファ量を判断し（Ｓ５３２）、バッファ部２３がエンプティになるまで録画を続ける（Ｓ５２８〜Ｓ５３２）。バッファ部２３内のデータを全て記録し終えたら、録画ポーズ状態に移行して（Ｓ５３４）、処理を終了する。
【００４７】
仮に、データ転送中にＬＡＮ１０内部のデータ流量が、何らかの要因で増加し、ＶＴＲ１からＶＴＲ２の転送データ量が間に合わなくなったと判断された場合（Ｓ５２２においてＮＯ判定の場合）、上記説明したのと同様にして、ＶＴＲ２を録画ポーズモードにし（Ｓ５２４）、ＶＴＲ２側のバッファ蓄積量が一定量に回復するまで記録動作を停止する。
【００４８】
上述した通り、本実施形態によれば、データ転送レートの変化から（パケット転送レート）から、バッファ部２３のエンプティを予測し、エンプティ到達前にＶＴＲ２の記録（REC)／ポーズ(PAUSE) の制御を行うようにしたので、仮に、ＬＡＮ１０上の転送データ量が一時的に増加してリアルタイムデータの転送処理が間に合わなくなっても、不都合なく、リアルタイムデータのＬＡＮ経由処理が可能となる。また、動画データについてはＵＤＰパケットで送信する一方、他の装置を制御するコマンド（ミュート指示や静止画表示指示など）については、ＴＣＰパケットを用い、最優先転送の短いコントロールメッセージを遣り取りすることで、バッファオーバーフロー、或いはアンダーフローチャートすることなしに動画データのリアルタイム転送及び受渡しが可能になる。
【００４９】
磁気テープなどの連続媒体を使用して動画等のデータを記録／再生する場合、途中で乱れたり、途切れたりすることは致命的な失敗となるが、本発明によれば、送信側と受信側とがそれぞれバッファ量を監視しながら、両者がある程度同期して動き、データ転送が途切れそうになったら処理を中断し、バッファをためて一定量のデータ蓄積を行ってから処理を再開するので、確実に動画を記録することができる。これにより、画面が乱れたり、コマ落ちしたりせずに、滑らかな動画映像を記録／再生することができる。もちろん、本発明の適用範囲は、磁気テープなどの連続媒体を使用する装置に限定されるものではなく、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスクなど、様々な記録媒体を使用する装置にも適用できる。
【００５０】
また、図２で説明したように、パケット内にフレーム番号とＩ／Ｐ／Ｂフレームのデータ情報を同時に乗せて、これら情報を転送バッファリングや録画のコントロール（ＴＣタイムコード形式）用として用いるようにしたので、中断された動画のつなぎ目を滑らかに連結させることができる。
【００５１】
本実施形態によれば、ＬＡＮ１０に接続されたＶＴＲ１、２、ＴＶモニタ装置３、オーディオ装置４など、リアルタイム伝送が必要とされる装置に、フローコントロール付きのバッファを設け、バッファ内のデータ量を監視しながら、送受信をコントロールすることにより、リアルタイム性が保てなくなったときにも、支障なく制御・視聴・操作することが可能となる。
【００５２】
本実施形態によれば、リアルタイムデータ転送の保証されていない伝送系経由で動画データや音声データ等のリアルタイムデータを伝送しても、問題無くリアルタイムデータを扱うことが可能になる。したがって、伝送路に専用線を用いる必要がなく、また、大きな帯域を占有することがないため、安価なネットワーク経由でデータ伝送が可能になる。非同期伝送によって実質タイムラグがあっても、リアルタイムに録画・再生・編集等が可能である。
【００５３】
なお、本例ではフローコントロール付きのバッファとして半導体メモリを用いているが、本発明の実施に際しては、これに限定されず、ハードディスク、光ディスク、フラッシュメモリ等の不揮発性メモリで置き換えることも可能である。
【００５４】
本発明の実施に際しては、上記した実施形態に限定されない。例えば、以下に示す変形例がある。
【００５５】
〔変形例１〕 ＶＴＲ１、２のテープダメージ防止の観点から、一定時間以上（例えば、５分以上）データ転送が中断された場合には、録画ポーズモードから「ストップ（STOP) モード」に遷移させる。ダビング等の編集途中で「ストップモード」になった場合、送信側サイトに再接続（リトライ）を行う。予め設定されているリトライ回数リミットまでリトライを繰り返しても、処理を再開できなかった場合には、編集処理を終了するとともに、「録画失敗」の旨を告知する表示を行う。
【００５６】
〔変形例２〕 テレビ放送の分野においては、番組放送において各地域のコマーシャル（ＣＭ）の切替えを制御するために、放送信号の中にＣＭ切替え用の同期信号（ＣＭのプログラム番号など）が含まれていることがある。このようなＣＭ信号、或いは番組の開始／終了信号を利用してバッファリング量をコントロールし、ＣＭ分のデータをバッファリングして、編集時にそのＣＭデータを破棄し、番組本編分のデータをあらためてバッファリングしてから録画用のデータの送受信を行う。これにより、ＣＭをカットした番組録画が可能となる。また、番組の切り替わり点で画像をつなぐため、レコーディング開始によるレインボーノイズの発生やつなぎ目の乱れが発生しないという利点がある。
【００５７】
〔変形例３〕 通常、リアルタイム動画の転送時には１００Ｍbit クラスの帯域を占有してしまう。このようなデータをＷＡＮ（Wide Area Network ）に流出させると、他のネットワーク利用者に迷惑をかけることも予想される。そこで、本発明の実施に際して、帯域予約プロトコル（ＲＳＶＰ）により、ＬＡＮ１０の転送データをルータの外に出さないように構成する態様がある。家庭内ＬＡＮ（例えば、ギガビットＬＡＮ）の構築によって図１のようにＶＴＲ１、２、ＴＶモニタ装置３、オーディオ装置４及びパソコン５を接続し、ルータを介して家庭内ＬＡＮとＷＡＮを接続する構成とする。こうして、家庭内ＬＡＮの中で動画データの受渡しを行い、ルータの外にデータを流出させないことにより、上述のコントロール編集／記録／再生時における帯域の占有という問題が回避され、ＬＡＮ内のデータ転送処理がルータ外部のＷＡＮ側に影響を与えない。
【００５８】
〔変形例４〕 本発明によれば、非同期式（asynchronous）伝送経路を用いて動画や音声データなどの同期記録再生が可能となる。すなわち、ネットワークに接続される各対象装置にある程度大容量のバッファを設け、バッファ内に一定量データが溜まったら各装置がそれぞれＯＫ信号を出して、同期して記録・再生・編集を行う。複数の対象装置のうち、バッファ蓄積の最も遅い装置が一斉通報（ブロードキャスト）を用いてタイミング信号を送出する。これにより、擬似的にリアルタイム記録・再生・編集を実現できる。
【００５９】
【発明の効果】
以上説明したように本発明によれば、ネットワーク接続される装置の内部にバッファを設け、送信側の装置及び受信側の装置それぞれがバッファのデータ蓄積量を管理して、通信状況に応じて相互に通信及び処理を制御するようにしたので、動画や音声などリアルタイム性を要求されるコンテンツを確実に記録・再生・編集することができる。
【図面の簡単な説明】
【図１】本発明を適用したＬＡＮ接続型ＶＴＲ装置等から成るシステムのブロック図
【図２】ＭＰＥＧデータを転送する際のパケットの構造を示す図
【図３】本実施形態に係るシステムの制御例を示すフローチャート
【図４】本実施形態に係るシステムの他の制御例を示すフローチャート
【符号の説明】
１，２…ＶＴＲ、３…ＴＶモニタ装置、４…オーディオ装置、５…パソコン、１０…ＬＡＮ、１２，２２，３２，４２…ＬＡＮ処理部、１３，２３，３３，４３…バッファ部、１５，２５，３５，４５…ＣＰＵ
【発明の属する技術分野】
本発明はネットワークに接続される装置及びそれら装置間でデータを転送する方法に係り、特に動画や音声などのリアルタイム性が要求されるデータを送受信する技術に関する。
【０００２】
【従来の技術】
特開平１１−８８８５６号公報は、ＭＰＥＧ等リアルタイム性の高いデータをネットワーク経由で伝送する場合の最適なパケット分割方法について述べられている。特開２０００−３５８０３３号公報は、機器同士が互いに通信する前に自己処理可能な通信プロトコルを通知し合うことにより、機器間で最適なデータ転送を可能にする方法について開示している。特開平７−４４２９１号公報は、マルチメディアコントローラによって他の機器の接続を自動的に検知して管理を行うシステムを開示している。
【０００３】
【発明が解決しようとする課題】
しかしながら、上述した各公報においては、ネットワーク接続された装置間の同期性の保証に関して言及していない。また、特開平１０−１９１４６３号公報は、ＨＴＴＰプロトコルを利用して動画転送を行うことが述べられているが、ここでの「動画」はあくまで静止画の集まりとして転送されており、ＨＴＴＰ転送プロトコルのみに限定されている。
【０００４】
本発明はこのような事情に鑑みてなされたもので、リアルタイム性を要求される動画等のコンテンツをＶＴＲ装置やＴＶ受像機などのリアルタイム性を要求される装置上で表示、記録又は再生等する必要がある場合に、データのリアルタイム伝送が損なわれる事態に陥っても問題なく制御・視聴・操作等が可能で、コマ落ちや途切れ等を回避できるネットワーク接続装置及びデータ転送方法を提供することを目的とする。
【０００５】
【課題を解決するための手段】
本発明は前記目的を達成するために、ネットワークに接続された複数台の装置間でデータの受渡しを行うデータ転送方法であって、送信側及び受信側の各装置にデータを一時的に記憶するバッファと、前記バッファに蓄積されたデータ量を監視するフロー管理手段とを設け、前記送信側及び受信側の各装置がそれぞれ自己の前記フロー管理手段で検出される前記バッファ内のデータ量に基づいて自己及び他の装置の動作を制御し、更に、前記送信側及び受信側の各装置のうち前記バッファの蓄積が最も遅い装置から他の装置すべてに対して出力されるタイミング信号によって前記送信側及び受信側の各装置が同期した動作を行うことを特徴としている。
【０００６】
すなわち、本発明はネットワーク接続される装置の内部にバッファを設け、送信側の装置及び受信側の装置それぞれがバッファのデータ蓄積量を管理して、通信状況に応じて相互に通信及び自他の処理を制御する。ネットワーク経由で伝送されるデータが途切れないようにバッファリングによって処理を制御し、データが途切れそうになったら送信側及び受信側の少なくとも一方の処理を中断させてバッファ蓄積量の回復を待ち、ある程度のデータ量が蓄積されたら処理を再開する。データ転送のリアルタイム性は犠牲になり得るが、少なくともデータが途切れる事態を防止でき、同期性が確保される。
【０００８】
【発明の実施の形態】
以下添付図面に従って本発明に係るネットワーク接続装置及びデータ転送方法の好ましい実施の形態について詳説する。
【０００９】
図１は、本発明を適用したＬＡＮ接続型ビデオテープレコーダ（ＶＴＲ）装置等から成るシステムのブロック図である。本例では説明の便宜上、ネットワーク接続装置の種類を限定しているが、本発明の適用範囲は図１に示した例に限定されない。
【００１０】
図１に示したシステムは、リアルタイム画像データを処理するネットワークシステムであって、１０ＢＡＳＥ−Ｔで代表されるＬＡＮ１０にＶＴＲ（Video Tape Recorder ）１、ＶＴＲ２、ＴＶモニタ装置３及びオーディオ装置４が接続されている。
【００１１】
これら各装置（１〜４）内には、それぞれ共通的な構成として、ＬＡＮ接続用インターフェース部１１，２１，３１，４１と、各プロトコルを処理／応答するＬＡＮ処理部１２，２２，３２，４２と、データを蓄積するためのバッファ部１３，２３，３３，４３と、バッファ部１３，２３，３３，４３から装置内の各処理部にデータを読み書きするインターフェース部１４，２４，３４，４４と、ＬＡＮ側及び装置内部側のデータを遣り取りするフロー制御部として機能するＣＰＵ１５，２５，３５，４５と、が設けられている。
【００１２】
各装置（１〜４）は、上記の構成に加えて、各装置に特有の機能を実現するために必要な構成を備えている。すなわち、ＶＴＲ１及びＶＴＲ２は、画像処理回路１６，２６及び磁気記録再生装置１７，２７を備えている。ＴＶモニタ装置３は画像処理回路３６、ＣＲＴドライバ３７及びＣＲＴ３８を備えている。オーディオ装置４はオーディオ処理回路４６、アンプ４７Ｒ、４７Ｌ及びスピーカ４８Ｒ、４８Ｌを備えている。
【００１３】
ＬＡＮ１０には、上記各装置（１〜４）の他、パソコン（ＰＣ）５を接続することが可能であり、パソコン５からＬＡＮ１０経由で各装置（１〜４）を操作することが可能である。パソコン５の構成は周知であるため詳細な構成について図示しないが、パソコン５はＬＡＮ接続用のアダプタ（ＬＡＮアダプタ）５１を備えている。
【００１４】
ＶＴＲ１に記録済みビデオカセットテープ６１を挿入すると、該ビデオカセットテープ６１に記録されているデータは磁気記録再生装置１７によって再生される。再生された動画像データは画像処理回路１６に送られ、ここで各種復調処理を経て、例えば、ＭＰＥＧ２データに変換される。同様に、音声は例えばＭＰ３データに変換され、装置内のバッファ部１３に送られる。ＭＰＥＧ２データは、インターネットプロトコルのＵＤＰ（User Datagram Protocol）パケットに挿入できるように分解されて、直接コネクションを張っているＶＴＲ２又はＴＶモニタ装置３に対して送信される。なお、ＵＤＰパケットの構造については図２で後述する。また、ＭＰ３データも同様にパケット化され、ＵＤＰプロトコルによってＶＴＲ２又はオーディオ装置４に対して送信される。
【００１５】
ＶＴＲ２によって録画を行う場合には、記録可能なビデオカセットテープ６２をＶＴＲ２に挿入する。ＬＡＮ１０を経由してバッファ部２３に蓄えられた動画像データは画像処理回路２６において記録用の信号に変換され、その記録用信号が磁気記録再生装置２７を介してビデオカセットテープ６２に記録される。
【００１６】
図２に転送パケットの構造を示す。１つのパケットの中は、図２のような層構造を有し、先頭はイーサネット物理層のヘッダ、次いで、ＩＰプロトコル層のヘッダ、ＵＤＰ層のヘッダ、Ｉフレーム／Ｐフレーム／Ｂフレームの区別を示す情報、タイムコード（例えば、時分秒、フィールド番号、フレーム番号などの情報を含む）、及びパケット分割数の情報（１つのフレームを複数のパケットで送る場合の分割数）などの付属情報が含まれ、これら情報とともにＭＰＥＧパケット１〜ｎが１つのパケットとして送られる。
【００１７】
１の画面は複数のパケットに分割され、パケットの何番目から何番目までが１つの画面を構成するのかを把握できるように、各パケットにはパケット分割数の情報が付加されている。また、タイムコードは時分秒の情報及びフレーム番号（必要に応じてフィールド番号）の情報を含んでいるため、タイムコード（ＴＣ）の情報からも１画面を構成するパケット群を把握できる。
【００１８】
ＭＰＥＧ特有の圧縮情報（Ｉフレーム／Ｐフレーム／Ｂフレームの区別を示す情報）は、ダビングその他の動画編集の際に重要な役割を果たす。Ｉフレームは１画面の中で閉じた圧縮をしているため、この画面内情報だけで画像を再生できる。Ｐフレームは１つ前の画面情報、Ｂフレームは前後の画面情報がなければ画像を再生できない。したがって、シーンの切替えは必ずＩフレームで編集される。本実施形態における動画像データのバッファリングや録画の制御はＩフレームを区切りとして行う。すなわち、バッファファリングエンドの目安は、編集可能単位（バッファ最大量）かつＩフレーム単位とし、録画の中断／再開についてもＩフレームのタイミングで制御する。
【００１９】
次に、上記の如く構成されたシステムにおいてＶＴＲ１を用いて音声付き動画のデータを再生し、その再生データをＬＡＮ１０経由でＴＶモニタ装置３及びオーディオ装置４に出力する場合の動作について説明する。
【００２０】
図３は制御の流れを示すフローチャートである。まず、ＶＴＲ１にビデオカセットテープ６１を挿入し（Ｓ１１０）、ＶＴＲ１本体又はパソコン５から再生実行を指示する（Ｓ１１２）。再生指示が入力されると、ＶＴＲ１は、ＴＣＰ／ＩＰプロトコルによって出力対象装置（この場合、ＴＶモニタ装置３及びオーディオ装置４）と接続を行い、コネクションを確立する（Ｓ１１４）。このとき、受付可能フォーマット及びデータ形式等についてお互いにネゴシエーションを行い、送信側・受信側で共通かつ最もレベルの高いフォーマットに設定する（Ｓ１１４、Ｓ２１４、Ｓ３１４）。
【００２１】
コネクション及びネゴシエーションが確立された後、ＶＴＲ１からオーバヘッドの小さい（誤り訂正や再送処理のない）ＵＤＰプロトコルにて動画像データを送信する（Ｓ１１６）。この場合、送信先（ＴＶモニタ装置３及びオーディオ装置４）の受信が可能であるかを確認する必要があるが、送り始めの場合は両装置とも、受信バッファ（バッファ部３３、４３）はエンプティであるので、問題なく受信を始めることができる。ＴＶモニタ装置３及びオーディオ装置４は、ＶＴＲ１から送られてくるデータを受信する（Ｓ２１６、Ｓ３１６）。
【００２２】
送信側（ＶＴＲ１）及び受信側（ＴＶモニタ装置３及びオーディオ装置４）は、それぞれ送信バッファ（バッファ部１３）及び受信バッファ（バッファ部３３、４３）のバッファリング量をリアルタイムで監視し（Ｓ１１８、Ｓ２１８、Ｓ３１８）、バッファ蓄積量が適正な量か否かを判定する（Ｓ１２０、Ｓ２２０、Ｓ３２０）。
【００２３】
すなわち、各装置のＣＰＵ１５、３５、４５は、データ転送レートの変化から（パケット転送レート）からバッファ部１３、３３、４３のエンプティを予測し、再生処理等の制御を行う。
【００２４】
ＴＶモニタ装置３のバッファ蓄積量が適正であれば、再生処理を開始し（Ｓ２２２）、動画表示を行う。また、オーディオ装置４にバッファ蓄積量が適正であれば、再生処理を開始し（Ｓ３２２）、音声出力を行う。
【００２５】
仮に、何らかの原因でＬＡＮ１０上の転送データ量が一時的に増加し、ＶＴＲ１からＴＶモニタ装置３及びオーディオ装置４に転送するデータが減少した場合、これら受信側の受信バッファ蓄積量が次第に減少する。やがて、ＴＶモニタ装置３及びオーディオ装置４の受信バッファがエンプティに近くなったことを、バッファ部３３、４３の図示せぬ検出回路（例えば、FIFO回路）が検出すると、その情報をＣＰＵ３５、４５に通知する。バッファ量の検出は、FIFO回路でデータ量を検出して信号を出力する構成でもよいし、ロジックを組んで実現してもよく、ＣＰＵ３５、４５がフローコントロールしてもよい。
【００２６】
ＣＰＵ３５、４５は、通知された情報を基にＬＡＮ１０経由のデータ転送レートと受信バッファ残容量からデータ転送が間に合うか否か（データ転送が途切れなく行われるか否か）を判断する（Ｓ２２０、Ｓ３２０）。
【００２７】
ＴＶモニタ装置３のＣＰＵ３５によってデータ転送が間に合わないと判断された場合、ＣＰＵ３５はバッファ部３３からの読み出し及び画像処理を中止し（Ｓ２２４）、処理直前の画像を静止画として表示する制御を行う（Ｓ２２６）と同時に、オーディオ装置４に対してＴＣＰ／ＩＰ経由でミュート指示を送信する（Ｓ２２８）。ミュート指示や後述する静止画表示指示など、他の装置に対する制御コードについては、誤り訂正チェックが行われるＴＣＰ／ＩＰのパケットで送られる。
【００２８】
オーディオ装置４はミュート指示の入力を判断し（Ｓ３５０）、ミュート指示の入力があった場合には音声再生処理を中止して音声出力をミュートする（Ｓ３５２）。
【００２９】
ＴＶモニタ装置３はミュート指示を出力した後（Ｓ２２８）に、バッファ蓄積量の監視と判断の処理を継続し（Ｓ２３０）、バッファ蓄積量が適正な値に回復したら、再生処理を再開すると同時に（Ｓ２３２）、オーディオ装置４に対して処理の再開を要求する指示（再開指示）を出力する（Ｓ２３４）。オーディオ装置４は再開指示の入力を判断し（Ｓ３５４）、再開指示が入力されたときには音声再生処理を再開する（Ｓ３５６）。こうして、動画表示及び音声出力が再開される。
【００３０】
ＴＶモニタ装置３は、Ｓ２３４において再開指示を出力した後、Ｓ２１６に戻る。一方、オーディオ装置４はＳ３５６において音声再生処理を再開した後、Ｓ３１６に戻る。
【００３１】
また、Ｓ３２０において、オーディオ装置４側でも同じように受信バッファがエンプティになることが予想される場合、オーディオ装置４のＣＰＵ４５はバッファ部４３からの読み出し及び音声処理を中止する制御を行うと同時に（Ｓ３２４）、ＴＶモニタ装置３に対して静止画表示の指示を送信する（Ｓ３２８）。ＴＶモニタ装置３は、静止画表示指示の入力を判断し（Ｓ２５０）、静止画表示指示の入力があった場合には、動画再生処理を中止するとともに（Ｓ２５２）、処理直前の画像を静止画として表示する制御を行う（Ｓ２５３）。これにより、動画出力が停止する。
【００３２】
オーディオ装置４は、静止画表示指示を出力した後（Ｓ３２８）に、バッファ蓄積量の監視と判断の処理を継続し（Ｓ３３０）、バッファ蓄積量が適正な値に回復したら、再生処理を再開すると同時に（Ｓ３３２）、ＴＶモニタ装置３に対して再開開始の指示を出力する（Ｓ３３４）。ＴＶモニタ装置３は再開指示の入力を判断し（Ｓ２５４）、再開指示が入力されたときには動画再生処理を再開する（Ｓ２５６）。こうして、動画表示及び音声出力が再開される。
【００３３】
ＴＶモニタ装置３は、Ｓ２５６において動画再生処理を再開した後、Ｓ２１６に戻る。一方、オーディオ装置４はＳ３３４において再開指示を出力した後、Ｓ３１６に戻る。
【００３４】
送信側であるＶＴＲ１の処理が間に合わなくなり、送信側のバッファ部１３がエンプティになりかけた場合にも同様にして、Ｓ１２０においてバッファ蓄積量不足と判断されると、ＴＶモニタ装置３及びオーディオ装置４それぞれに対して静止画表示指示・ミュート指示を出力する（Ｓ１２７、Ｓ１２８）。こうして、ＴＶモニタ装置３においては動画再生が中断され、静止画表示となる（Ｓ２５０〜２５３）。また、オーディオ装置４においては音声再生が中断され、音声の出力が停止する（Ｓ３５０〜３５２）。このように、送信側、受信側のバッファにそれぞれ一定量のデータが蓄えられるまで出力側のデータ処理が中止される。
【００３５】
ＶＴＲ１は、静止画表示指示（Ｓ１２７）及びミュート指示（Ｓ１２８）を出力した後もバッファ蓄積量の監視と判断の処理を継続し（Ｓ１３０）、バッファ蓄積量が適正な値に回復したら、ＴＶモニタ装置３及びオーディオ装置４に対して再開開始の指示を出力する（Ｓ１３４）。これにより、動画表示及び音声出力が再開される（Ｓ２５４〜Ｓ２５６、Ｓ３５４〜３５６）。
【００３６】
ＶＴＲ１は、Ｓ１３４において再開指示を出力した後、Ｓ１１６に戻る。また、Ｓ１２０においてバッファ量が適正であると判断した場合には、再生対象の動画データの再生処理が終了したか否かの判断を行い（Ｓ１６０）。再生途中であれば、Ｓ１１６に戻り、上記処理を継続する。一方、ユーザによる再生終了の指示が入力された場合、或いは再生対象の動画データを最後まで再生し終えた場合などにはＳ１６０においてＹＥＳ判定となる。この場合は、通信接続を解除して（Ｓ１６２）、処理を終了する。
【００３７】
ＴＶモニタ装置３における動画再生処理中、Ｓ２５０において静止画表示指示の入力がない場合は、通信接続が解除されたか否かを判断し（Ｓ２７０）、接続状態が維持されていればＳ２１６に戻って上記の処理を継続する一方、Ｓ２７０において通信接続が解除された場合には処理を終了する。
【００３８】
同様に、オーディオ装置４における音声再生処理中、Ｓ３５０においてミュート指示の入力がない場合は、通信接続が解除されたか否かを判断し（Ｓ３７０）、接続状態が維持されていればＳ３１６に戻って上記の処理を継続する一方、Ｓ３７０において通信接続が解除された場合には処理を終了する。
【００３９】
なお、図３では、バッファ蓄積量が回復したことを検出すると自動的に処理を再開しているが、ユーザに再スタートの指示入力を促し、ユーザからの指示入力を受けて処理を再開させてもよい。
【００４０】
次に、ＶＴＲ１で再生からＶＴＲ２に向かって動画像データの編集作業を行う場合を説明する。図４は、編集動作の制御手順を示すフローチャートである。
【００４１】
まず、ＶＴＲ１及びＶＴＲ２の操作パネルから直接、又はパソコン５から編集モードを指示する（Ｓ４１０、Ｓ５１０）。指示が入力されると、対象装置間（この場合、ＶＴＲ１とＶＴＲ２の間）でＴＣＰ／ＩＰにてネゴシエーションを行い（Ｓ４１２、Ｓ５１２）、最大公約数的な条件にて通信プロトコル、転送レート、操作可能コマンド等を遣り取りして設定を行う。
【００４２】
説明を簡単にするために、ＶＴＲ１からＶＴＲ２に対して３０分の動画をダビングする例を述べる。ＶＴＲ１の操作パネルから直接、又はパソコン５からダビング開始の指示を入力すると（Ｓ４１４）、ＶＴＲ１−ＶＴＲ２間でそれぞれ再生モード（Ｓ４１６）、録画モード（Ｓ５１６）に設定され、ＶＴＲ１は再生処理を開始し（Ｓ４１８）、ＶＴＲ２は録画ポーズ（PAUSE)状態で待機する（Ｓ５１８）。
【００４３】
ＶＴＲ１側で再生及びデータの処理が行われ、画像データがＬＡＮ１０経由でＶＴＲ２に転送される（Ｓ４２０）。この転送にはＵＤＰプロトコルを用いる。ＶＴＲ２は、ＶＴＲ１から送られてくるデータをＬＡＮ１０経由で受信する（Ｓ５２０）。
【００４４】
ＶＴＲ２は受信データのバッファ蓄積量を判断し（Ｓ５２２）、一定量のデータが蓄積されるまで録画ポーズ状態を維持して（Ｓ５２４）、データ受信を継続する（Ｓ５２０）。Ｓ５２２において、ＶＴＲ２側で一定量のデータがバッファ部２３に蓄積されたと判断されたら、ポーズ状態を解除して（Ｓ５２６）、ＶＴＲ２側は録画を開始する（Ｓ５２８）。
【００４５】
ＶＴＲ１は、所定時間分（例えば、３０分）の動画再生を終えるまで、再生処理（Ｓ４１８）とデータ送信処理（Ｓ４２０）を継続する。所定時間分の動画再生が終了したことを検出したら（Ｓ４２２）、ＶＴＲ１は再生を停止し（Ｓ４２４）、待機モードに移行すると同時に（Ｓ４２６）、その旨をＶＴＲ２に通知する（Ｓ４２８）。
【００４６】
ＶＴＲ２は、このコマンド（待機モード状態の通知）の入力を判断し（Ｓ５３０）、入力がなければＳ５２０に戻って上記処理（Ｓ５２０〜Ｓ５３０）を継続する。Ｓ５３０においてコマンドの入力を検出すると、バッファ量を判断し（Ｓ５３２）、バッファ部２３がエンプティになるまで録画を続ける（Ｓ５２８〜Ｓ５３２）。バッファ部２３内のデータを全て記録し終えたら、録画ポーズ状態に移行して（Ｓ５３４）、処理を終了する。
【００４７】
仮に、データ転送中にＬＡＮ１０内部のデータ流量が、何らかの要因で増加し、ＶＴＲ１からＶＴＲ２の転送データ量が間に合わなくなったと判断された場合（Ｓ５２２においてＮＯ判定の場合）、上記説明したのと同様にして、ＶＴＲ２を録画ポーズモードにし（Ｓ５２４）、ＶＴＲ２側のバッファ蓄積量が一定量に回復するまで記録動作を停止する。
【００４８】
上述した通り、本実施形態によれば、データ転送レートの変化から（パケット転送レート）から、バッファ部２３のエンプティを予測し、エンプティ到達前にＶＴＲ２の記録（REC)／ポーズ(PAUSE) の制御を行うようにしたので、仮に、ＬＡＮ１０上の転送データ量が一時的に増加してリアルタイムデータの転送処理が間に合わなくなっても、不都合なく、リアルタイムデータのＬＡＮ経由処理が可能となる。また、動画データについてはＵＤＰパケットで送信する一方、他の装置を制御するコマンド（ミュート指示や静止画表示指示など）については、ＴＣＰパケットを用い、最優先転送の短いコントロールメッセージを遣り取りすることで、バッファオーバーフロー、或いはアンダーフローチャートすることなしに動画データのリアルタイム転送及び受渡しが可能になる。
【００４９】
磁気テープなどの連続媒体を使用して動画等のデータを記録／再生する場合、途中で乱れたり、途切れたりすることは致命的な失敗となるが、本発明によれば、送信側と受信側とがそれぞれバッファ量を監視しながら、両者がある程度同期して動き、データ転送が途切れそうになったら処理を中断し、バッファをためて一定量のデータ蓄積を行ってから処理を再開するので、確実に動画を記録することができる。これにより、画面が乱れたり、コマ落ちしたりせずに、滑らかな動画映像を記録／再生することができる。もちろん、本発明の適用範囲は、磁気テープなどの連続媒体を使用する装置に限定されるものではなく、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスクなど、様々な記録媒体を使用する装置にも適用できる。
【００５０】
また、図２で説明したように、パケット内にフレーム番号とＩ／Ｐ／Ｂフレームのデータ情報を同時に乗せて、これら情報を転送バッファリングや録画のコントロール（ＴＣタイムコード形式）用として用いるようにしたので、中断された動画のつなぎ目を滑らかに連結させることができる。
【００５１】
本実施形態によれば、ＬＡＮ１０に接続されたＶＴＲ１、２、ＴＶモニタ装置３、オーディオ装置４など、リアルタイム伝送が必要とされる装置に、フローコントロール付きのバッファを設け、バッファ内のデータ量を監視しながら、送受信をコントロールすることにより、リアルタイム性が保てなくなったときにも、支障なく制御・視聴・操作することが可能となる。
【００５２】
本実施形態によれば、リアルタイムデータ転送の保証されていない伝送系経由で動画データや音声データ等のリアルタイムデータを伝送しても、問題無くリアルタイムデータを扱うことが可能になる。したがって、伝送路に専用線を用いる必要がなく、また、大きな帯域を占有することがないため、安価なネットワーク経由でデータ伝送が可能になる。非同期伝送によって実質タイムラグがあっても、リアルタイムに録画・再生・編集等が可能である。
【００５３】
なお、本例ではフローコントロール付きのバッファとして半導体メモリを用いているが、本発明の実施に際しては、これに限定されず、ハードディスク、光ディスク、フラッシュメモリ等の不揮発性メモリで置き換えることも可能である。
【００５４】
本発明の実施に際しては、上記した実施形態に限定されない。例えば、以下に示す変形例がある。
【００５５】
〔変形例１〕 ＶＴＲ１、２のテープダメージ防止の観点から、一定時間以上（例えば、５分以上）データ転送が中断された場合には、録画ポーズモードから「ストップ（STOP) モード」に遷移させる。ダビング等の編集途中で「ストップモード」になった場合、送信側サイトに再接続（リトライ）を行う。予め設定されているリトライ回数リミットまでリトライを繰り返しても、処理を再開できなかった場合には、編集処理を終了するとともに、「録画失敗」の旨を告知する表示を行う。
【００５６】
〔変形例２〕 テレビ放送の分野においては、番組放送において各地域のコマーシャル（ＣＭ）の切替えを制御するために、放送信号の中にＣＭ切替え用の同期信号（ＣＭのプログラム番号など）が含まれていることがある。このようなＣＭ信号、或いは番組の開始／終了信号を利用してバッファリング量をコントロールし、ＣＭ分のデータをバッファリングして、編集時にそのＣＭデータを破棄し、番組本編分のデータをあらためてバッファリングしてから録画用のデータの送受信を行う。これにより、ＣＭをカットした番組録画が可能となる。また、番組の切り替わり点で画像をつなぐため、レコーディング開始によるレインボーノイズの発生やつなぎ目の乱れが発生しないという利点がある。
【００５７】
〔変形例３〕 通常、リアルタイム動画の転送時には１００Ｍbit クラスの帯域を占有してしまう。このようなデータをＷＡＮ（Wide Area Network ）に流出させると、他のネットワーク利用者に迷惑をかけることも予想される。そこで、本発明の実施に際して、帯域予約プロトコル（ＲＳＶＰ）により、ＬＡＮ１０の転送データをルータの外に出さないように構成する態様がある。家庭内ＬＡＮ（例えば、ギガビットＬＡＮ）の構築によって図１のようにＶＴＲ１、２、ＴＶモニタ装置３、オーディオ装置４及びパソコン５を接続し、ルータを介して家庭内ＬＡＮとＷＡＮを接続する構成とする。こうして、家庭内ＬＡＮの中で動画データの受渡しを行い、ルータの外にデータを流出させないことにより、上述のコントロール編集／記録／再生時における帯域の占有という問題が回避され、ＬＡＮ内のデータ転送処理がルータ外部のＷＡＮ側に影響を与えない。
【００５８】
〔変形例４〕 本発明によれば、非同期式（asynchronous）伝送経路を用いて動画や音声データなどの同期記録再生が可能となる。すなわち、ネットワークに接続される各対象装置にある程度大容量のバッファを設け、バッファ内に一定量データが溜まったら各装置がそれぞれＯＫ信号を出して、同期して記録・再生・編集を行う。複数の対象装置のうち、バッファ蓄積の最も遅い装置が一斉通報（ブロードキャスト）を用いてタイミング信号を送出する。これにより、擬似的にリアルタイム記録・再生・編集を実現できる。
【００５９】
【発明の効果】
以上説明したように本発明によれば、ネットワーク接続される装置の内部にバッファを設け、送信側の装置及び受信側の装置それぞれがバッファのデータ蓄積量を管理して、通信状況に応じて相互に通信及び処理を制御するようにしたので、動画や音声などリアルタイム性を要求されるコンテンツを確実に記録・再生・編集することができる。
【図面の簡単な説明】
【図１】本発明を適用したＬＡＮ接続型ＶＴＲ装置等から成るシステムのブロック図
【図２】ＭＰＥＧデータを転送する際のパケットの構造を示す図
【図３】本実施形態に係るシステムの制御例を示すフローチャート
【図４】本実施形態に係るシステムの他の制御例を示すフローチャート
【符号の説明】
１，２…ＶＴＲ、３…ＴＶモニタ装置、４…オーディオ装置、５…パソコン、１０…ＬＡＮ、１２，２２，３２，４２…ＬＡＮ処理部、１３，２３，３３，４３…バッファ部、１５，２５，３５，４５…ＣＰＵ
Claims (1)
- ネットワークに接続された複数台の装置間でデータの受渡しを行うデータ転送方法であって、
送信側及び受信側の各装置にデータを一時的に記憶するバッファと、前記バッファに蓄積されたデータ量を監視するフロー管理手段とを設け、前記送信側及び受信側の各装置がそれぞれ自己の前記フロー管理手段で検出される前記バッファ内のデータ量に基づいて自己及び他の装置の動作を制御し、更に、前記送信側及び受信側の各装置のうち前記バッファの蓄積が最も遅い装置から他の装置すべてに対して出力されるタイミング信号によって前記送信側及び受信側の各装置が同期した動作を行うことを特徴とするデータ転送方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002155911A JP4062725B2 (ja) | 2002-05-29 | 2002-05-29 | データ転送方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002155911A JP4062725B2 (ja) | 2002-05-29 | 2002-05-29 | データ転送方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003348175A JP2003348175A (ja) | 2003-12-05 |
| JP4062725B2 true JP4062725B2 (ja) | 2008-03-19 |
Family
ID=29772316
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002155911A Expired - Fee Related JP4062725B2 (ja) | 2002-05-29 | 2002-05-29 | データ転送方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4062725B2 (ja) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP4363204B2 (ja) * | 2004-02-04 | 2009-11-11 | ヤマハ株式会社 | 通信端末 |
| US20060023066A1 (en) * | 2004-07-27 | 2006-02-02 | Microsoft Corporation | System and Method for Client Services for Interactive Multi-View Video |
| JP2007080347A (ja) * | 2005-09-13 | 2007-03-29 | Funai Electric Co Ltd | 光ディスク再生装置 |
| JP4894476B2 (ja) * | 2006-11-21 | 2012-03-14 | 富士通東芝モバイルコミュニケーションズ株式会社 | 音声送信装置および移動通信端末 |
| JP5469842B2 (ja) * | 2008-10-02 | 2014-04-16 | 日立コンシューマエレクトロニクス株式会社 | コンテンツ送信装置、コンテンツ受信装置 |
| US8925032B2 (en) | 2010-05-07 | 2014-12-30 | Sharp Kabushiki Kaisha | AV output system performing video output |
| JP5962328B2 (ja) | 2012-08-21 | 2016-08-03 | 株式会社ソシオネクスト | データ転送装置、データ転送方法、及び半導体装置 |
| CN110062008A (zh) * | 2019-05-21 | 2019-07-26 | 北京计算机技术及应用研究所 | 恶劣温度条件下的语音记录系统软件优化方法 |
-
2002
- 2002-05-29 JP JP2002155911A patent/JP4062725B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003348175A (ja) | 2003-12-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7873059B2 (en) | Gateway device | |
| JPH11501786A (ja) | 圧縮ビデオ信号受信方法 | |
| US20060024022A1 (en) | Method for generating additional information for guaranteeing seamless playback between data streams, recording medium storing the information, and recording, editing and/or playback apparatus using the same | |
| JP4735697B2 (ja) | 電子機器、コンテンツ再生方法及びプログラム | |
| US20090222576A1 (en) | Method and apparatus for reducing power consumption of a network communication device receiving streaming content via an ip-based network | |
| JP4062725B2 (ja) | データ転送方法 | |
| JP3911380B2 (ja) | 転送レート制御装置 | |
| JP4062339B2 (ja) | 情報記録再生装置 | |
| KR100957797B1 (ko) | 대화형 광디스크 장치에서의 콘텐츠 정보 재생방법과,콘텐츠 제공서버에서의 콘텐츠 정보 제공방법 | |
| JP2004048464A (ja) | 音声映像データ記録再生装置 | |
| JP2003348125A (ja) | 情報配信システム、情報処理置および方法、記録媒体、並びにプログラム | |
| JP2004007172A (ja) | 情報配信システム、情報配信装置および方法、情報端末装置および情報処理方法、記録媒体、並びにプログラム | |
| JPH10134507A (ja) | 著作権保護方法、供給媒体、デジタル記録機器、及び制御用ｉｃ | |
| JP2004260454A (ja) | 送受信システム、送信装置 | |
| JP3675693B2 (ja) | ルータ装置、ネットワーク放送システム、プログラム、及び記録媒体 | |
| JP2002298501A (ja) | データ記録再生システム及びデータ記録再生方法 | |
| JP4219883B2 (ja) | 転送レート制御装置、及び記録媒体 | |
| JP2010057051A (ja) | 制御機器、制御方法、およびプログラム | |
| WO2006087862A1 (ja) | デジタル記録再生装置及びデジタル記録方法 | |
| JP2002209201A (ja) | 映像受信端末 | |
| JP3887949B2 (ja) | 画像情報記録再生装置および方法、並びに記録媒体 | |
| JP4461803B2 (ja) | 情報記録再生装置および情報記録再生方法、記録媒体、並びにプログラム | |
| JP4117186B2 (ja) | ストリームデータ記録装置、ストリームデータ再生装置、ストリームデータ記録制御装置、ストリームデータ再生制御装置、ストリームデータ記録方法、およびストリームデータ再生方法 | |
| US20060056439A1 (en) | Data transfer method and device | |
| JP4211928B2 (ja) | 通信モジュール、これを有する再生装置、ナビゲーション装置及びディスプレイ装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050215 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060831 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060927 |
|
| A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20061127 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070425 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070622 |
|
| 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: 20071210 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20071223 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110111 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110111 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120111 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120111 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130111 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130111 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140111 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |