JP2019080269A - 映像伝送装置 - Google Patents
映像伝送装置 Download PDFInfo
- Publication number
- JP2019080269A JP2019080269A JP2017207702A JP2017207702A JP2019080269A JP 2019080269 A JP2019080269 A JP 2019080269A JP 2017207702 A JP2017207702 A JP 2017207702A JP 2017207702 A JP2017207702 A JP 2017207702A JP 2019080269 A JP2019080269 A JP 2019080269A
- Authority
- JP
- Japan
- Prior art keywords
- class
- transmission
- skew
- target class
- video
- 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.)
- Pending
Links
Landscapes
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Communication Control (AREA)
Abstract
【課題】2重化された映像伝送システムにおいて、ユースケースに応じた適切なスキュークラスを決定し、該クラスに基づいて伝送制御することにより、2伝送路間の映像切り替え時の視認性および操作性を改善することができる伝送制御方法を提供する。【解決手段】映像送出装置102は、同一ネットワーク上に接続されている受信装置から機器情報を取得して接続機器を管理するテーブルを生成するネットワーク情報管理部211と、取得した機器情報に含まれる接続機器タイプおよびステータスに応じて目標クラスを決定する目標クラス決定部212と、該目標クラスに応じてエンコードレート制御するレート制御部204と、を有する。【選択図】図2
Description
本発明は、映像信号を符号化してネットワーク経由で伝送する映像出力システムに関し、特に、二重化された伝送路に同一の映像および音声データを送出する構成において、ユースケースに応じた適切なスキュークラスを決定して伝送制御を行う映像伝送装置に関する。
現在、放送制作用機器の映像伝送にはSDI(シリアル・デジタル・インタフェース)ケーブルが用いられている。従来は、SDIケーブル1本で映像伝送が行われていたが、撮像機器の高画質化に伴って複数のSDIケーブルを束ねることにより伝送する方法が考案されている。例えば、4K/60P映像を伝送するにはSDIケーブルを4本束ねることで伝送が可能である。
しかし、機材間を接続するのに従来の4倍のケーブルを使用するため、設置スペースの問題やSDIケーブルの重量が課題となる。また、撮像機器の更なる高画質化に伴って、より多くのSDIケーブルを必要とするため、それら課題が大きな問題となる。
そこで、近年では撮影した映像信号をIP(InternetProtocol)ネットワークを活用してリアルタイムに伝送する映像出力システムが開発されている。ネットワーク機器は、SDIケーブルに比べてより高速な伝送が実用化されており、加えて業務専用の機器に比べて汎用設備が利用できるため安価に環境を構築できる等のメリットがある。今後、放送制作用機器のネットワーク化が急速に普及すると考えられる。
映像出力システムにおけるIPネットワーク伝送では、デジタル化された映像データをベースバンド(非圧縮)で伝送したり、圧縮符号化処理(エンコード)して伝送したりする手法がある。符号化方法としては、例えば、国際標準規格のMPEG−2(Moving Picture Experts Group phase2)等がある。そして、リアルタイム性の求められる映像データや音声データを伝送するプロトコルとしてRTP(Real−time Transport Protocol)が使われる。
RTPでは映像出力装置側でヘッダ部にパケットの順序番号やタイムスタンプを付加することによって、受信装置側で適切な順序で再生することができる。また、RTCP(Real−time Transport Control Protocol)プロトコルを用いることによって、RTPのフロー制御を行うための情報を送受信装置間で双方向通信することができる。これにより、受信装置側で検出したパケット損失や、伝送中の遅延情報を映像出力装置へ通知することができる。さらに、RTCPプロトコルにおいて、アプリケーション定義パケットを使用することにより、接続機器の詳細情報を各送受信装置間で双方向に通信できる。
一般的にRTPでは、UDP(User Datagram Protocol)をトランスポート層のプロトコルとして使用しており、映像データの再送制御はないため、RTCPで伝送路の輻輳状態を監視し、パケットロス率に応じた転送ビットレートの制御が行われる。
上記映像データのIP伝送は、国際標準化を目指して議論されておりSMPTE(Society of Motion Picture & Television Engineers)2022規格としてまとめられている。SMPTE2022−7規格では、「Seamless Protection Switching」として映像データパケットを2重化して伝送し、どちらかの伝送路がダウンしても瞬時に正常な伝送路に切り替える方法について記載されている。
さらに、SMPTE2022−7規格では、映像信号を途切れなく伝送するために、2重化された伝送路間のスキューに対応する受信クラスやスキュー値としての時間を規定している。 図17は映像出力装置における2重化された伝送路間のスキューを説明する図である。
図17のPT(図17の2303)は、映像出力装置から出力された送信データが、受信装置に最も遅く到着した場合のレイテンシーを示す。EA(図17の2304)は、映像出力装置から出力された送信データが、受信装置に最も速く到着した場合のレイテンシーを示す。P1(図17の2305)およびP2(図17の2306)は、映像出力装置から出力された送信データが、受信装置に到着したある任意の時刻におけるレイテンシーを示す。PD(図17の2307)は、レイテンシーP1(図17の2305)とレイテンシーP2(図17の2306)の差分値であり、当該差分値が伝送路Aと伝送路Bのスキューを示す。
図12(c)は、SMPTE2022−7規格に定められているクラスと時間規定の例を説明する図である。例えば、クラスCの受信装置においてスキューPDは、HBR(HighBitRate)ストリームの映像伝送では150[ms]以下、SBR(SlowerBitRate)ストリームの映像伝送では450[ms]以下となるように規定されている。
ところで、SMPTE2022−7規格に記載されている通り、一般的な受信装置はレイテンシーP1およびP2の絶対値を知らない。そのため、受信装置は2本のストリームをシームレスに切り替え可能とするために、最大スキューとなるクラスCのケースを想定して映像信号をバッファに蓄えておいてから再生表示している。すなわち、受信装置は2伝送路間のスキューを吸収できるように、常に最大遅延を持たせて表示再生している。
例えば、前述したHBRストリームにおいて、起動時のスキューをゼロ、スキューPDを150[ms]以下、プラスマイナス方向の偏差を考慮して、クラスCの受信装置は最大300[ms]の遅延をもって表示している。また同様にクラスCの受信装置はSBRストリームにおいては、最大900[ms]の遅延が生じる。
遅延をできるだけ抑制してシームレスな切り替えを実現するには、受信装置と映像出力装置で其々クラス情報に応じた映像出力処理および受信処理を行う必要がある。
遅延をできるだけ抑制してシームレスな切り替えを実現するには、受信装置と映像出力装置で其々クラス情報に応じた映像出力処理および受信処理を行う必要がある。
特許文献1は、受信した映像と音声を同期させるリップシンク処理において、映像処理の変化で生じた映像遅延時間の変化量(差分時間)を予め定めた規定時間と比較し、比較結果が規定時間以上の場合に、ユーザーによるリップシンク処理(音声の遅延設定)を促す方法が記載されている。
特許文献2は、映像出力装置において、パケットロス率に基づいて再送データのエンコードレートを制御する方法について記載されている。
しかしながら、SMPTE2022−7規格では2重化された伝送路間のスキュー値は規定されているものの、映像出力装置と受信装置における伝送路毎のレイテンシーの送受信等の相互連携については定められておらず、一般的な受信装置は最大遅延をもって再生表示している。その結果、例えば映像出力装置(例えば、ビデオカメラ)の画面上にメニュー等を表示して操作を行った場合、その操作画面が受信装置(例えば、モニタ)に表示されるまでに遅れて表示されるため、ユーザーにとって操作性が低いと感じる問題がある。
また、上記特許文献1に記載の技術は、映像信号処理による遅延時間に対して規定時間を設けて、該規定時間以上となる場合にはユーザーに音声の遅延調整を促すことで、受信装置における内部遅延をユーザーに調整させることを可能としている。しかしながら、上記特許文献ではP2Pで接続するような、伝送遅延をほとんど無視できる構成では有用であるものの、同一伝送路上に複数の機器が接続されて伝送遅延が生じるようなネットワークの場合には、通信状態の影響を大きく受けるためユーザー調整は極めて困難である。また、映像と音声の伝送であるため、伝送路間で切り替え制御することについては考慮されていない。
また、上記特許文献2に記載の技術は、伝送路の輻輳状態に応じて伝送可能な帯域を算出してエンコードレートを決定する方法について記載されているが、2重化については考慮されていない。すなわち、各伝送路における最適な制御はできるものの、伝送路間のスキューや伝送路間で切り替えた際の品質については考慮されておらず、エンコードレートによっては切り替え品質が低下する恐れがある。
本発明は、上述した課題に鑑みてなされたものであり、ユースケースに応じた適切なスキュークラスを判定してスキュー制御することにより、2伝送路間の映像切り替え時の視認性および操作性を改善することを目的とする。
上述した課題を解決するために、本発明は撮像部で撮像された映像を2重化し、第1と第2のネットワークで伝送することが可能な伝送装置と、前記2重化されて伝送された映像を受信することが可能な受信装置と、前記伝送装置と前記受信装置は前記第1と第2の異なる伝送路で接続され、前記伝送装置は、前記同一ネットワークに接続される複数の伝送装置に係る機器種別と機器状態を定期的に取得し、前記機器種別と機器状態に応じて前記2重化した伝送路間のスキュークラスを決定する手段を備えることを特徴とする。
本発明によれば、ユースケースに応じた適切なスキュークラスを判定してスキュー制御することにより、2伝送路間の映像切り替え時の視認性および操作性を改善することができる。
<第1の実施形態>
以下、図面を参照して、本発明を実施するための形態を例示的に詳しく説明する。ただし、実施形態に記載されている構成部品の機能、相対配置などは特定的な記載がない限り、本発明の範囲をそれらのみに限定する趣旨のものではない。また、以下の説明で一度説明した構成や部品についての機能、形状などは特に改めて記載しない限り初めの説明と同様のものとする。
以下、図面を参照して、本発明を実施するための形態を例示的に詳しく説明する。ただし、実施形態に記載されている構成部品の機能、相対配置などは特定的な記載がない限り、本発明の範囲をそれらのみに限定する趣旨のものではない。また、以下の説明で一度説明した構成や部品についての機能、形状などは特に改めて記載しない限り初めの説明と同様のものとする。
図1は、本発明を適用可能な映像出力システムの構成を示す概略図である。撮像部101、送信装置102を含んで構成される映像出力装置100と、受信装置300とにより本実施形態の映像出力システムが構成される。また、映像出力装置100と受信装置300の間にはルーターA103及びルーターB104が配置され、それぞれ独立した伝送路で接続されている。同図ではルーターA103およびルーターB104に2台の端末A105及び端末B106の2台が接続されていることを示しているが、3台以上の端末が接続されていても良い。端末A105またはB106は、例えばモニタやレコーダ等の他の受信装置や、映像出力装置や受信装置を制御可能なコントローラ等の制御装置である。
映像出力装置100は、例えば撮像部101によって撮像した映像データを送信装置102で符号化処理し、伝送路を介して受信装置300へ送信する。本実施形態では、映像出力装置100は、撮影した同一映像データを2つの伝送路A107と伝送路B108を使用して2重化して受信装置300へ送信する。
受信装置300は、映像出力装置100から出力された映像データを受信して表示するものである。受信装置300は、同一の映像データを二つの伝送路を介して受信しているので、一方の伝送路がダウンしても瞬時に正常な伝送路に切り替えることが可能である。なお、受信装置300は、表示デバイスに限定されるものではなく、映像出力装置100から出力された映像データを受信して蓄積するような記憶装置でも構わない。
図2は、第1実施形態に係る送信装置の一構成例を示す機能ブロック図である。図2において、制御部200には不図示のROM、RAMが接続され、ROMに格納されたプログラムに従って送信装置全体の制御を司る。RAMは揮発性メモリであり、制御部200のワークメモリとして使用されると同時に、各種データの一時記憶エリアとしても使用される。映像入力部201は、カメラ等の撮像部からの映像データを受信し、映像データの符号化および符号化データをエンコード処理するエンコード部A202およびエンコードB203に分配する。
エンコード部A202およびエンコード部B203は、レート制御部204から設定されたエンコードレートに基づいてそれぞれエンコード(圧縮)処理する。タイムスタンプ処理部A205およびタイムスタンプ処理部B206は、エンコード部A202およびエンコード部B203から入力されたエンコードデータにタイムスタンプを付与する。タイムスタンプ処理部(図2の205、206)は、エンコード部A202およびエンコード部B203から入力された同一映像データには同一のタイムスタンプが付与されるように処理する。
パケット処理部A207およびパケット処理部B208は、タイムスタンプを含むエンコードデータの送信パケット化を行って、ネットワークI/F部A209およびネットワークI/F部B210を介して外部装置に対してパケット送信する。また、パケット処理部A207およびパケット処理部B208はネットワークI/F部A209およびネットワークI/F部B210から受信したパケットデータから受信データへの復号処理を行って、ネットワーク情報管理部211へ出力する。
ネットワーク情報管理部211はネットワークI/F部A209またはネットワークI/F部B210を介して受信した受信データを解析して伝送路A107および伝送路B108を介して接続されている機器情報を取得し、接続されている機器の情報を接続機器テーブルとして作成する。
目標クラス決定部212は、ネットワーク情報管理部211で作成した接続機器テーブルに基づき、後述する処理フローに従って、送信装置102の目標クラスを決定し、レート制御部へ目標クラスを通知する。さらに、目標クラス決定部212は、ネットワーク情報管理部211を介して目標クラスを受信装置300へ通知する。レート制御部204は、目標クラス決定部212からの目標クラス通知に応じてエンコード部A202およびエンコード部B203に対するエンコードレート設定を変更する。
なお、レート制御部204は、エンコード部A202とエンコード部B203にそれぞれ異なるレートを設定可能である。
図3は、第1実施形態に係る受信装置の一構成例を示す機能ブロック図である。図3において、受信装置300の制御部301には不図示のROM、RAMが接続され、ROMに格納されたプログラムに従って受信装置全体の制御を司る。RAMは揮発性メモリであり、制御部のワークメモリとして使用されると同時に、各種データの一時記憶エリアとしても使用される。
受信装置300は、映像出力装置100と伝送路A107および伝送路B108を介して通信を行うネットワークI/F部A302およびネットワークI/F部B303を備える。さらに、受信パケットから受信データへの復号を行うパケット処理部A304およびパケット処理部B305と、受信データから映像データへ復号処理を行うデコード部A306およびデコード部B307を備える。パケット処理部A304およびパケット処理部B305は復号処理した受信データをネットワーク情報管理部308へ出力する。
ネットワーク情報管理部308は、受信データから送信装置の目標クラス情報を取得し、実際に適用する目標クラスを決定して、バッファ制御部309へ通知する。また、ネットワーク情報管理部308は、適用する目標クラス情報をパケット処理部A304およびパケット処理部B305で送信パケットとして生成して、ネットワークI/F部A302またはネットワークI/F部B303を介して送信装置102へ応答する。
バッファ制御部309は、適用する目標クラスに応じて、デコード部A306およびデコード部B307のバッファ容量を設定するとともに、デコード部A306またはデコード部B307の再生までの遅延時間を制御する。具体的には、例えばSBRストリームにおいて、目標クラスがCであればスキューPDを450[ms]、最大遅延900[ms]で再生表示し、目標クラスがAであればスキューPDを10[ms]、最大遅延20[ms]で再生表示するようにバッファ制御する。
映像出力部310は、デコード部A306またはデコード部B307から入力された映像データを選択、受信して表示部311へ出力する。表示部311は、例えばLCD(Liquid Crystal Display)やOLED(Organic ElectroLuminance Display)等を用いた表示デバイスである。
図4は送信装置と受信装置間におけるスキューとエンコードレートの関係を説明するための模式図である。データ出力のスループットを一定、伝送路A107を基準として、目標クラスA、B、Cは伝送路B108の伝送距離の長さに例えることができる(図4の401〜403)。即ち、目標クラスAと目標クラスCのスキューの関係は、図4の伝送距離が長くなることと等価である。図4の模式図において、送信装置100は、例えばスループットを変えずに目標クラスCから目標クラスAにするには、単位時間当たりの映像フレームの伝送量が増えるように伝送路Bのエンコードレートを上げれば良い。
また、受信装置300は、伝送路間の映像切り替えに備えて、目標クラスに応じたバッファ容量に変更して、再生遅延時間を変更する。送信装置100のエンコードレートを上げることにより、伝送路間の切り替え品質は低下するが、スキューを小さくすることが可能であり、エンコードレートを下げることで、スキューは大きくなるが、伝送路間の切り替え品質はスキューが小さい場合に比べて向上することが可能となる。
図5(a)は、送信装置102のネットワーク情報管理部211で作成した接続機器テーブルの一例を説明する図である。同一ネットワーク上に接続された各機器は、RTCPプロトコルで定義されるアプリケーション定義パケットを用いることによって各種機器情報を相互に通信できる。本実施形態では、アプリケーション定義パケットのアプリケーション機能拡張として、接続機器の機器タイプ、機器ステータス、伝送路A及び伝送路Bのどちらに機器が接続されているかを示す伝送路情報を送受信装置間で通信可能である。
図5(b)は接続機器の機器タイプの一例を説明する図、図5(c)はモニタの機器ステータスの一例、図5(d)はカメラ/レコーダの機器ステータスの一例を説明する図である。
各機器は、図5(b)〜(d)に示す機器タイプや機器ステータスのうち適切なIDを選択してRTCPパケットとして送出する。具体的には、受信装置としてのモニタであれば、アプリケーション定義パケット名に「機器タイプ」、アプリケーション定義データに「モニタ」をRTCPパケットに格納して送出する。また、モニタの機器状態が表示中であれば、アプリケーション定義パケット名に「ステータス」、アプリケーション定義データには“表示中”ステータスを示すIDの「0x03」をRTCPパケットに格納して送出する。
なお、図5(a)に示した送信装置の接続機器テーブルには、同一機器タイプの機器が複数台接続されているため、送信装置102は機器を識別管理するための機器No.を付与している。
図6は映像出力装置100の処理の流れを説明するフローチャート図である。図6に示すように、映像出力装置100は、ネットワークに接続されると受信装置300との接続を行い、機器情報の送受信を開始する(図6のステップS801)。なお、本実施形態では、例えば映像データをRTPプロトコルにより送信し、接続機器間の情報の送受信にはRTCP等の通信制御プロトコルを用いる。
ステップS802において、エンコード部(図2の202、203)は映像入力部201から入力された映像データに対して、初期値として予め定めておいた目標クラス、または、ステップS801で受信装置から取得した目標クラスに対応する目標レートからエンコードレート値を決定してエンコード処理を行う。ここで、前述した目標クラスに対応する目標レート(図7(a))は、送信装置102の制御部200に予め保持している。
なお、目標クラスCからクラスAになるほど要求されるスキューが小さくなることから、図7(a)に示す目標レート値はクラスCに対してクラスAのエンコードレートを高くしてネットワーク上での帯域負荷を抑制することを目的としたパラメータ設定となっている。なお、図7(a)に記すパラメータはこれに限定するものではなく、上記目的の範囲内でパラメータを指定してよい。
次に、ステップS803において、パケット処理部(図2の207、208)は、エンコード部(図2の202、203)およびタイムスタンプ処理部(図2の205、206)から入力された送信データの送信パケット化を行い、ネットワークI/F部(図2の209、210)を介して映像データの出力を開始する。ここで、映像出力装置100は、受信装置300で伝送路A107と伝送路B108のコンテンツが同一かどうかを判別可能なように、映像データの出力と合わせてコンテンツID等をヘッダ情報として付与して送信する。
ステップS804において、ネットワークI/F部は、映像データを出力しつつ、パケット処理部A207またはパケット処理部B208は受信装置300からパケット受信すると、受信パケットから受信データへの復号処理を行って、ネットワーク情報管理部211へ出力する。
ステップS805において、ネットワーク情報管理部211は、受信した情報から接続機器の情報を取得し、接続機器テーブルの更新要否を確認する。ネットワーク情報管理部211は、接続機器テーブルに変更が生じた場合には、接続機器テーブルを更新する。
次にステップS806において、目標クラス決定部212は、ネットワーク情報管理部211から接続機器テーブルを取得し、後述の図8に示す処理フローに従って目標クラスを選択する。
続けて、ステップS807で目標クラス決定部212は、目標クラスの変更要否を判定し、変更が必要な場合にはステップS808でレート制御部204に対して目標クラスの変更を通知する。さらに、ステップS808において、目標クラス決定部212は、ネットワーク情報管理部211を介して受信装置300に対しても目標クラスの変更を通知する。
ステップS809において、レート制御部204は、目標クラス決定部212からの目標クラス変更通知に基づいてエンコード部A202およびエンコード部B203に対するレート設定の変更を実施する。
ステップS809において、レート制御部204は、目標クラス決定部212からの目標クラス変更通知に基づいてエンコード部A202およびエンコード部B203に対するレート設定の変更を実施する。
その後、ステップS810では、映像出力装置100の制御部200によって映像データ出力中か否かを確認し、映像データ出力中であればステップS804へ戻り、映像データ出力中でなければ本フロー処理を終了する。
図8は送信装置102において実行される目標クラス決定処理の流れを説明するフローチャート図である。図8に示すように、送信装置102は、ネットワーク情報管理部211で取得・作成した接続機器テーブル(図5(a))と目標クラス判定テーブル(図7(b))に基づいて、目標クラスを決定する。
まずステップS1001において、目標クラス決定部212はネットワーク情報管理部211から接続機器テーブルを読み出す。次にステップS1002において目標クラス決定部212は、接続機器の機器タイプと機器ステータスに基づいて、予め保持している目標クラス判定テーブル(図7(b))を用いて各機器の優先順位を判定する。
ここで、図7(b)の目標クラス判定テーブルは機器タイプと機器ステータスの組み合わせにおける目標クラスと優先順位を説明する図である。例えば、送信装置の接続先であるモニタが表示中であれば目標クラスBであるが、非表示中の場合は目標クラスCとすることを示している。これは、受信装置の状態によらず不用意にエンコードレートが高いまま伝送したままにする場合に比べ、受信装置がデータ未使用の場合はエンコードレートを下げて伝送することにより、ネットワークの帯域負荷を低減させることができる。さらには、映像送出は継続することにより、モニタが表示状態へ復帰した場合でも瞬時に表示状態に移行できるメリットがある。
次に、ステップS1003において、目標クラス決定部212は、接続機器に優先順位1の機器がある場合にはステップS1004に進み、目標クラスAとしてレート制御部204に通知する。また、接続機器に優先順位1の機器がない場合にはステップS1005に進む。
ステップS1005において、目標クラス決定部212は、接続機器に優先順位2の機器がある場合にはステップS1006に進み、目標クラスBとしてレート制御部204に通知する。また、優先順位2の機器がない場合にはステップS1007に進む。
ステップS1007において、目標クラス決定部212は、接続機器に優先順位3の機器がある場合にはステップS1008に進み、目標クラスCとしてレート制御部204に通知する。また、優先順位3の機器がないか、優先順位が不定の機器が接続されている場合には、ステップS1009に進む。
ステップS1009では、目標クラス決定部212は接続機器の優先順位が不定の場合には目標クラスをCとしてレート制御部204に通知する。または、目標クラス決定部212は送信装置102のネットワーク情報管理部211を介して、接続機器のネットワークの輻輳状態に応じて目標クラスを設定する。即ち、輻輳状態においてはネットワーク負荷を低減させる方向に目標クラスを設定する。
次に受信装置300の動作について説明する。図9は受信装置300において実行される処理の流れを説明するフローチャート図である。
図9に示すように、受信装置300はネットワークに接続されると、まずステップS1201において機器情報を送信する。機器情報とは、前述した機器タイプや機器ステータスを示す情報である。
次に、ステップS1202において受信装置300は、映像出力装置100との接続を行い、映像データを含むパケット受信処理を開始する。ステップS1203では、パケット処理部(図3の304、305)は、ネットワークI/F部(図3の302、303)を介して映像データの受信を開始し、映像データパケットをデコード部(図3の306、307)へ出力する。さらに、パケット処理部(図3の304、305)は、受信したパケットから、ネットワーク上に接続される機器情報や、使用している伝送路の情報、ならびに映像出力装置の目標クラス情報等を抽出し、ネットワーク情報管理部308へ出力する。
ステップS1204において、ネットワーク情報管理部308は、現在映像表示に使用している映像出力装置100からの目標クラスの変更通知有無を確認する。そして、変更がある場合にはステップS1205へ進み、表示遅延量の変更処理要求をバッファ制御部309へ出力する。
ステップS1206において、バッファ制御部309はデコード部(図3の306、307)のバッファ量を変更設定して、映像出力部310へ出力する遅延時間を変更制御する。ステップS1207において、映像出力部310は、デコード部Aまたはデコード部Bから入力された映像データのうち、表示出力するデータを選択して表示部311へ出力する。
ステップS1208において、パケット処理部(図3の304、305)は所定時間パケット受信がない場合に映像が停止したと判断してステップS1201に戻る。なお、映像データの受信中断や切替え、またはネットワークの切断・再接続を検出した場合には本処理フローを先頭から再開する。
図10は映像出力装置100において実行される別の目標クラス決定処理の流れを説明するフローチャート図である。図10は図6で説明した処理フローに加えて、送信装置自身のステータスを考慮して目標クラスを決定する。図10で示すフローチャートは、図6のステップS804からステップS806の間で実行され、ステップS806の目標クラスより優先的に適用する。まず、ステップS1301において、送信装置102の目標クラス決定部212は、制御部200から送信装置自身の機器ステータスを取得する。
次にステップS1302において、目標クラス決定部212は図7(c)の機器ステータスに基づいて優先順位を判定する。図7(c)は、送信装置自身の機器ステータスにおける目標クラスと優先順位を説明する図であり、例えば、送信装置102としてのビデオカメラが撮影した映像を出力中であれば目標クラスBとし、メニュー操作画面を表示装置に出力中であれば目標クラスAとすることを示している。これは、例えば、目標クラスBではスキューは大きいが再生遅延も大きくなるため、メニュー操作を行った場合には目標クラスAとして、スキューを小さくすることで、再生遅延も小さくすることを意味する。即ち、映像品質は低下するがユーザーにとって、レスポンスが向上できる効果がある。
ステップS1302において、目標クラス決定部212は機器ステータスが優先順位1の場合にはステップS1303に進み、優先順位1ではない場合にはステップS1305に進む。ステップS1303において、目標クラス決定部212は目標クラスAを選択して、前述した図6のステップS806へ進む。ステップS1304において、目標クラス決定部212は機器ステータスが優先順位2の場合にはステップS1305に進み、優先順位2ではない場合にはステップS1306に進む。
ステップS1305において、目標クラス決定部212は目標クラスBを選択して、前述した図6のステップS806へ進む。ステップS1306において、目標クラス決定部212は目標クラスCを選択して、前述した図6のステップS806へ進む。ステップS806の目標クラス決定処理では、図8および図10の処理フローで選択した目標クラスのうち、スキューの小さいクラスを最終的な目標クラスとして決定する。例えば、図8の処理フローに基づく目標クラスをB、図10の処理フローに基づく目標クラスをAとした場合、最終的な目標クラスはAとして決定し、レート制御部204によるレート変更ならびに受信装置300への目標クラス変更通知を実施する。
受信装置300は、図9の処理フローで説明した通り、送信装置102から通知された目標クラス変更通知に基づいて、バッファ制御ならびに再生遅延制御を行う。
以上説明したように、本実施形態の送信装置は接続される機器タイプおよび機器ステータスに基づいてスキュー制御するための目標クラスを決定する。その結果、例えば受信装置であるモニタから、送信装置のメニューを操作するような場合でも、スキューの小さいクラスを選択することで遅延を抑制し、ユーザー操作に対するレスポンスが向上できる。
また、受信装置と送信装置間でスキュークラスを相互に通信することにより、受信装置による無駄なバッファ処理を抑制することが出来るので、結果的に遅延を抑制できる。
以上から、送信装置および受信装置ともに、ユースケースに応じたクラス設定が可能となるので適切なバッファリング処理が可能となり、映像切り替え時の品質低下を抑制できる効果がある。
<第2の実施形態>
次に、本発明の第2の実施形態による処理について、以下、図面を参照しながら説明する。なお、第2の実施形態の説明において、上述した第1の実施形態と共通する部分については、適宜、説明を省略する。 第2の実施形態は、送信装置200において、ユーザーが接続機器間の距離情報を手動設定出来る構成としたものである。第2の実施形態における送信装置の目標クラス決定部は、操作入力部から入力されたユーザー設定値を優先的にレート制御部へ出力する。このように制御することで、機器タイプ、ステータスのみならず、送受信装置の物理的な設置距離に応じたクラス設定が可能となる。
次に、本発明の第2の実施形態による処理について、以下、図面を参照しながら説明する。なお、第2の実施形態の説明において、上述した第1の実施形態と共通する部分については、適宜、説明を省略する。 第2の実施形態は、送信装置200において、ユーザーが接続機器間の距離情報を手動設定出来る構成としたものである。第2の実施形態における送信装置の目標クラス決定部は、操作入力部から入力されたユーザー設定値を優先的にレート制御部へ出力する。このように制御することで、機器タイプ、ステータスのみならず、送受信装置の物理的な設置距離に応じたクラス設定が可能となる。
図11は第2実施形態に係る送信装置の一構成例を示す機能ブロック図である。図11において、操作入力部1501はユーザーからの入力を受付けて制御部に通知し、制御部200は操作入力に応じてメニュー画面を生成して、表示部1502へ表示出力する。
図7(d)は、送信装置1500の表示部1502に表示されたメニュー画面例の一部を説明する図である。メニュー画面には、受信装置に関する環境設定メニュー1601があり、設定リストとして、「オート」「短距離」「中距離」「長距離」(図7(d)の1602)が選択可能である。
メニューにおいて、「短距離」は目標クラスA、「中距離」は目標クラスB、「長距離」は目標クラスCに対応する。また、「オート」は第1の実施形態で説明した接続機器テーブルに基づく目標クラス決定処理を適用する場合に選択する。
図12(a)は、第2実施形態に係る機器管理テーブルの一例を説明する図である。第1実施形態に加えて、各機器に対するメニュー設定よる設定値を保持している。ここで、第1の実施形態における目標クラス決定部212は、接続機器中のリストNo.1のモニタが表示中であることから目標クラスBを選択していた。しかし、第2の実施形態におけるリストNo.1のモニタは、メニュー設定で長距離が選択されている。従って、第2の実施形態における送信装置1500の目標クラス決定部1503は、メニューによる選択を優先して目標クラスCを選択する。
そして、目標クラス決定部1503は、その他接続されている機器の機器タイプとステータスを総合的に判断し、送信装置1500としての目標クラスCを選択し、レート制御部204へ通知する。
以上から、本例では、機器タイプとステータスのみで目標クラスを判定した場合には目標クラスBとなるが、ユーザーが物理的な設置環境を手動選択できるようにすることで目標クラスCが選択されることとなる。すなわち、第1の実施形態の如く、機器情報のみで目標クラスを決定する場合に比べ、物理的な設置環境を考慮することができるので、過剰な目標クラス選択による伝送帯域の圧迫を回避することができる効果がある。
なお、本実施形態では理解を容易にするために、ユーザーがメニュー画面を使って距離情報を直接入力可能な構成としたがこれに限定されるものではなく、機器間の物理的な位置情報が把握できれば良い。
例えば、送受信装置間でネットワークアドレスを相互に通信することで、何段のゲートウェイを通過することが判断できる。したがってゲートウェイの接続段数が多いほどネットワーク間の距離が遠い、すなわち物理的な距離も遠いと推測しても良い。また、送信装置および受信装置がそれぞれGPSを備えることによっても機器間距離を推測することも可能である。
以上説明したように、本実施形態ではユーザー入力により接続機器間の物理的な距離を入力可能とすることで、目標クラスの判定に利用する。その結果、機器タイプやステータスのみならず、物理的距離を考慮した目標クラスを決定することが可能となり、よりユースケースに適した目標クラスによるスキュー制御が可能となる効果がある。
<第3の実施形態>
次に、本発明の第3の実施形態による処理について、以下、図面を参照しながら説明する。なお、第3の実施形態の説明において、上述した第1または第2の実施形態と共通する部分については、適宜、説明を省略する。 第3の実施形態は、送信装置において接続機器のバッファ容量を取得し、接続機器の機器タイプ、機器ステータス、バッファ容量に応じて、より適切に目標クラスを設定できる構成としたものである。
次に、本発明の第3の実施形態による処理について、以下、図面を参照しながら説明する。なお、第3の実施形態の説明において、上述した第1または第2の実施形態と共通する部分については、適宜、説明を省略する。 第3の実施形態は、送信装置において接続機器のバッファ容量を取得し、接続機器の機器タイプ、機器ステータス、バッファ容量に応じて、より適切に目標クラスを設定できる構成としたものである。
図13は、第3実施形態に係る映像出力システムの構成を示す概略図である。撮像部101、送信装置1802を含んで構成される映像出力装置1800と、受信装置A1807、受信装置B1808とにより本実施形態の映像出力システムが構成される。また、映像出力装置1800と受信装置A1807、受信装置B1808の間にはルーターA103およびルーターB104が配置され、それぞれ独立した伝送路で接続されている。
映像出力装置1800は伝送路1801とルーターA103を経由して受信装置A1807と受信装置B1808に映像出力するとともに伝送路1802とルーターB104を経由して2重化目の映像を出力する。ここで、ルーターB104を2重化目として上述したが、受信装置AまたはBはルーターA103経由かルーターB104経由かに関係なく、映像受信して表示等に使用可能である。
図14は第3実施形態に係る送信装置の一構成例を示す機能ブロック図である。第1の実施形態で説明した構成に加えて、バッファ時間管理部1901を備えている。
バッファ時間管理部1901は、ネットワーク情報管理部211、ネットワークI/F部を介して、受信装置のバッファサイズの情報を取得する。そして、バッファ時間管理部1901は、受信装置(図13の1807、1808)から取得したバッファサイズの情報からエンコード処理後のデータがどのくらいの時間分保持できるか換算処理する。
バッファ時間管理部1901は、ネットワーク情報管理部211、ネットワークI/F部を介して、受信装置のバッファサイズの情報を取得する。そして、バッファ時間管理部1901は、受信装置(図13の1807、1808)から取得したバッファサイズの情報からエンコード処理後のデータがどのくらいの時間分保持できるか換算処理する。
例えば、受信装置が60Hz、4Kの映像を10フレーム分保持できるバッファを備えているとして、エンコードしたデータがどのくらいの時間分保持できるかはエンコードレートに依存する。具体的には、エンコード後のデータが半分であれば、上記バッファには20フレームの時間分保持できる。そこで、送信装置は自身が出力する映像データのエンコードレートに基づき、受信装置側のバッファサイズから映像の再生時間と等価な値として「バッファ時間」を算出する。
図15は第3実施形態に係る受信装置の一構成例を示す機能ブロック図である。第1の実施形態で説明した構成に加えて、バッファ制御部2001は伝送路Aおよび伝送路Bそれぞれに対応するバッファサイズを管理している。バッファサイズとは受信した映像を切り替え制御するため、実際に蓄積できるデータサイズに対応する。
ネットワーク情報管理部2002は、送信装置1802からのバッファサイズ取得要求に応じて、伝送路Aおよび伝送路Bに対応するそれぞれのバッファサイズと、未使用のバッファサイズをバッファ制御部2001から取得して、ネットワークI/F部A302またはネットワークI/F部B303を介して送信装置1802へ応答する。
図16は送信装置1802において実行される処理の流れを説明するフローチャート図である。図16は、第1の実施形態で説明した接続機器テーブル作成の処理フローに加えて、受信装置の残バッファ時間を考慮して目標クラスを決定する。図16で示すフローチャートは図6のステップS804からステップS806の間で実行され、ステップS806の目標クラスより優先して設定する。
まず、ステップS2101において、送信装置1802のバッファ時間管理部1901はネットワーク情報管理部211およびネットワークI/F部(図14の209、210)を介して受信装置(図13の1807、1808)のバッファサイズを取得する。
次にステップS2102において、バッファ時間管理部1901は受信装置(図13の1807、1808)から取得したバッファサイズに対して送信装置1802のエンコードレートからバッファ時間を算出する。この時、伝送路Aと伝送路Bのエンコードレートが異なると、バッファサイズが同量でも受信可能なバッファ時間が異なることに注意が必要である。
次にステップS2103においてネットワーク情報管理部211は、第1の実施形態で説明したのと同様の手順により接続機器テーブルを作成するとともに、ステップS2102で算出したバッファ時間を該テーブルにあわせて保持する(図12(b))。
図12(b)は、第3の実施形態における接続機器テーブルの一例を説明する図である。図12(b)によれば、同一ネットワーク上には2台のモニタが接続され、モニタ_1は伝送路Aを表示中、モニタ_2は伝送路Bを表示中である。
この時、バッファ時間を参照するとモニタ_1は総時間50[ms]である。これは、SMPTE2022−7規格を参照すると、現在のエンコードレートではモニタ_1はクラスA以上にのみ対応しているということになる。言い換えると、受信装置はクラスBやクラスCは非対応であり、該クラスを選択すると映像品質が低下する等の問題が生じてしまう恐れがあることを示している。
エンコードレート値によって対応クラスがクラスBやクラスCに変わることから、本実施形態ではエンコードレート値に基づいてバッファ時間を算出し、該時間から適応クラスを判定する。
なお、モニタ_2は総時間900[ms]であり、クラスCまで対応しているため、この場合はモニタ_1のクラス判定結果を優先して使用する。ステップS2104において、目標クラス決定部1902は、図7(b)で示した機器タイプと機器ステータスに加え、バッファ可能時間を考慮して目標クラスを決定する。例えば、本例においてモニタ_1は、機器タイプ「モニタ」、機器ステータス「表示」であるため図7(b)に従うと目標クラスBとなる。しかし、ステップS2102でのバッファ時間換算の結果、現在のエンコードレート値ではクラスA以上に該当することから、目標クラスBではなく目標クラスAを選択する。
ステップS2105では、目標クラス決定部1902は現在設定中の目標クラスからの変更要否を判定し、変更が必要な場合にはステップS2106へ進み、変更不要の場合にはステップS2107へ進む。
ステップS2106において、目標クラス決定部1902は、ステップS2104において選択した目標クラスをレート制御部204に通知する。レート制御部204は、第1の実施形態と同様にレート変更ならびに目標クラス変更通知を実施する。受信装置(図13の1807、1808)は、第1の実施形態で説明したのと同様に、送信装置1802から通知された目標クラス変更通知に基づいて、バッファ制御ならびに再生遅延制御を行う。
以上説明したように、本実施形態の送信装置は接続される第1の実施形態と同様にして選択した目標クラスに加え、受信装置のバッファ時間を加味して目標クラスを決定する。その結果、受信装置のバッファ性能を考慮した目標クラスを決定することが可能となり、より機器性能に適した目標クラスによるスキュー制御が可能となる効果がある。
以上、本発明をその好適な実施形態に基づいて詳述してきたが、本発明はこれら特定の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。上述の実施形態の一部を適宜組み合わせてもよい。
以上、本発明をその好適な実施形態に基づいて詳述してきたが、本発明はこれら特定の実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。上述の実施形態の一部を適宜組み合わせてもよい。
100 映像出力装置
101 撮像部
102 送信装置
300 受信装置
101 撮像部
102 送信装置
300 受信装置
Claims (7)
- 撮像部で撮像された映像を2重化し、
第1と第2のネットワークで伝送することが可能な伝送装置と
前記2重化されて伝送された映像を受信することが可能な受信装置と、
前記伝送装置と前記受信装置は前記第1と第2の異なる伝送路で接続され、
前記伝送装置は、前記同一ネットワークに接続される複数の伝送装置に係る機器種別と機器状態を定期的に取得し、
前記機器種別と機器状態に応じて
前記2重化した伝送路間のスキュークラスを決定することを特徴とする
映像伝送装置。 - 前記スキュークラスは少なくとも2つ以上のクラスから成り、
前記伝送装置は、スキュークラスを選択可能な入力手段を備え、
前記入力手段によって選択したスキュークラスと、
前記スキュークラス決定手段によるスキュークラスを比較し、
スキューの小さいクラスを目標クラスとして決定することを特徴とする
請求項1に記載の映像伝送装置。 - 前記スキュークラス入力手段は
前記伝送装置に対する前記受信装置の距離情報であって
前記距離情報に対応するスキュークラスに基づいてスキュークラスを選択することを特徴とする
請求項1または2に記載の映像伝送装置。 - 前記伝送装置は
前記受信装置のバッファ容量を取得する手段と、
前記伝送装置のエンコードレートと
前記取得したバッファ容量からバッファ時間を算出する手段と
前記バッファ算出手段によるバッファ時間に基づいてスキュークラスを選択する手段と
前記バッファ時間に基づくスキュークラスと
前記スキュークラス決定手段によるスキュークラスを比較し、
スキューの小さいクラスを目標クラスとして決定することを特徴とする
請求項1乃至3のいずれか1項に記載の映像伝送装置。 - 2伝送路のうち、受信装置が使用している伝送路側を優先する
前記伝送装置は、
前記算出したバッファ時間のうち、前記受信装置により使用しているバッファ時間を使用することを特徴とする
請求項1乃至4のいずれか1項に記載の映像伝送装置。 - 前記伝送装置は、
前記算出したバッファ時間に対応するスキュークラスを判定する手段と、
前記受信装置が複数ある場合に
前記スキュークラスのうち、スキューの小さいクラスを目標クラスとして決定することを特徴とする
請求項1乃至5のいずれか1項に記載の映像伝送装置。 - 前記伝送装置は、
前記目標クラスとして決定したクラス情報を前記受信装置へ通知する手段を備え、
前記受信装置は、
前記伝送装置から受信したクラス情報に基づいて
受信した映像をバッファリングして再生するまでの遅延時間を変更制御することを特徴とする
請求項1に記載の受信装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017207702A JP2019080269A (ja) | 2017-10-27 | 2017-10-27 | 映像伝送装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2017207702A JP2019080269A (ja) | 2017-10-27 | 2017-10-27 | 映像伝送装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2019080269A true JP2019080269A (ja) | 2019-05-23 |
Family
ID=66626655
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2017207702A Pending JP2019080269A (ja) | 2017-10-27 | 2017-10-27 | 映像伝送装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2019080269A (ja) |
-
2017
- 2017-10-27 JP JP2017207702A patent/JP2019080269A/ja active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4670902B2 (ja) | 送信装置、送信方法および受信装置 | |
US8683007B2 (en) | Seamless transfer of media streams | |
JP5043132B2 (ja) | 通信システムにおけるデータ伝送方法 | |
KR102115922B1 (ko) | 영상 통신 방법 및 그 영상 통신 시스템 | |
WO2009128528A1 (ja) | サーバ装置とコンテンツ配信方法とプログラム | |
US9621617B2 (en) | Method and server for sending a data stream to a client and method and client for receiving a data stream from a server | |
WO2011049193A1 (ja) | 配信システム、ゲートウェイ、配信方法及びプログラム | |
KR20130005873A (ko) | 방송 시스템에서 컨텐츠 수신 방법 및 장치 | |
JP2007208458A (ja) | 通信システム、通信端末および通信方法 | |
JP4170942B2 (ja) | モバイルアドホックネットワーク環境での効率的なデータ送受信のためのネットワーク装置及びデータ転送方法 | |
US9794317B2 (en) | Network system and network method | |
JP2010028378A (ja) | 通信装置及び通信方法 | |
JP6278275B2 (ja) | 送信装置、受信装置、送信方法および受信方法 | |
JP2010161550A (ja) | 映像コンテンツ受信装置、および映像コンテンツ受信方法 | |
JP2008311969A (ja) | 受信機、送信機、通信システム、受信機の制御方法、通信方法、受信機の制御プログラム、およびそれを記録した記録媒体 | |
JP2008167351A (ja) | 端末装置 | |
JP2014086850A (ja) | 映像コンテンツ配信装置 | |
KR101548501B1 (ko) | 청크 기반의 끊김 없는 스트림 송수신 장치 및 그 방법 | |
JP2019080269A (ja) | 映像伝送装置 | |
JP5675164B2 (ja) | 送信装置、送信方法、並びにプログラム | |
JP2008113226A (ja) | 通信装置および通信方法 | |
JP2006148789A (ja) | ストリーミング受信装置及び配信サーバ装置 | |
JP5122327B2 (ja) | 移動端末へメディアストリームを配信するシステム | |
JP6468663B2 (ja) | 映像コンテンツ配信装置 | |
JP2007228412A (ja) | 携帯端末装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
RD01 | Notification of change of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7421 Effective date: 20191125 |