JP5389528B2 - ネットワークデコーダ装置 - Google Patents
ネットワークデコーダ装置 Download PDFInfo
- Publication number
- JP5389528B2 JP5389528B2 JP2009120883A JP2009120883A JP5389528B2 JP 5389528 B2 JP5389528 B2 JP 5389528B2 JP 2009120883 A JP2009120883 A JP 2009120883A JP 2009120883 A JP2009120883 A JP 2009120883A JP 5389528 B2 JP5389528 B2 JP 5389528B2
- Authority
- JP
- Japan
- Prior art keywords
- picture
- video data
- received
- decoder
- 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.)
- Active
Links
Landscapes
- Closed-Circuit Television Systems (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
Description
或いは、画像送信装置1a等の配信能力の不足によりフルフレームの映像を送ることができない場合がある。画像送信装置1a等において、接続クライアント数に応じて配信のための処理能力(処理時間、バッファメモリ)が分配されるが、接続数が多くなると1クライアント当たりの処理能力が十分でなくなるためである。
また、WEBサーバ機能を有する雲台付力メラ画像送信装置もしくはIP力メラ、画像サーバ装置への力メラ制御要求を、画像受信装置に直接接続された専用操作器のみならずネットワーク経由でアクセスしている各クライアントから行なえるよう、ネットワークデコーダ装置は制御要求を中継する。これにより、力メラ制御要求の宛先を映像要求のそれと同じにでき、制御を簡略化する事ができる。
また、画像送信装置からの実効受信レートと、各クライアントへの実効送信レートとは必ずしも一致しないため、受信した符号化映像データを少なくともIピクチャ周期分格納するバッファと、符号化映像データの再配信要求を受信したときに、前記バッファから符号化映像データを順次読み出して、該再配信要求の要求元へ送信する再配信手段と、を備えて、該再送信手段が、バッファに格納された最新Iピクチャより古いデータを符号化映像データの送信をスキップする。
なお、本システムは、ネットワークデコーダ装置(画像受信装置)において、符号化映像データを受信して復号しNTSC信号もしくはデジタル映像信号出力によりモニター画面に映像表示させる通常の機能に加え、力メラ制御を行うPCの画面上にも同じ映像を表示させ、該映像を確認しながら力メラ制御を行えるようにすることを意図し、下記の性能を満足することを目標にしている。
(1) 画像送信装置に対する配信負荷を増加させないこと。
(2) 画像送信装置と画像受信装置、クライアントPC間のネットワーク伝送路の負荷の増加を最小限にすること。
(3) 画像送信装置と力メラ制御用の通信を行うときは、画像受信装置を経由させる事で制御の複雑さを緩和させる。
ネットワークデコーダ装置16(以後、デコーダと呼ぶ)は、予め設定された通信プ口トコルを用いて、画像送信装置1等から目的の各画像データをネットワーク4を経由して受信する。その際、画像送信装置1等から送信されネットワーク4を伝送する画像データは、1クライアント分のトラフイック量であり、設計上の品質で支障なく伝送できる。ネットワーク4は、遠地に設置される画像送信装置等を多数接続するものであるため、SONET(Synchronous Optical NETwork)のような高速なものから、56Kbpsのモデム回線まで、各種の物理層が使用されうる。
またトランスポート層以上の上位層において、例えば、バッファとして最新の完全な1GOP(Group of Picture)分のデータの保存に必要な容量を備え、フレーム間引きにより適応的な送信レート制御を行うようにする。最新のGOPの先頭を受信すると、継続中の直前のGOPの再送信は、直ちに或いはフレームかスライスの境界で中止され、該最新のGOPの再送信を開始する。これにより、モデム等を使用した低品質の回線を用いた場合でも、最低限の復号可能な(フレーム内符号化された)1ピクチャ分の映像データを再配信することができる。
画像送信装置1aは、入力された映像信号を目標ビットレートになるように圧縮符号化し、符号化映像データ(ストリームデータ)を所定のプロトコルに従ってネットワークインタフェースから送信する。
デコーダ16−1は、画像送信装置1aから対応するプロトコルで受信した符号化映像データを復号化しアナログ映像信号として出力する(図示せず)とともに、受信した符号化映像データをバッファに格納し、所定のプロトコルに従ってネットワークインタフェースから送信する。
デコーダ16−2、113−3は、デコーダ16−1から対応するプロトコルで受信した符号化映像データを復号化しアナログ映像信号として出力する。
ネットワーク4−2は、デコーダ16−1とデコーダ16−2とを接続する任意の伝送路であり、512kbps程度の実効通信速度を有するADSL回線を想定する。
ネットワーク4−3は、デコーダ16−2とデコーダ16−3とを接続する任意の伝送路であり、2Mbps程度の実効通信速度を有するLAN(Local Area Network) を想定する。
ネットワーク4−1〜3はいずれもIPパケットを伝送することができる。なお、図10ではデコーダ16−1等が2つのネットワークに直接接続するかのように図示してあるが、ルータ機能の内蔵を意図したものではなく、デコーダ16等は、物理インタフェースとして、Ethernet(商標)等のポートを1個備える。
Picture(以下、Pピクチャと称する)およびBiderectionally Predictive
Picture(以下、Bピクチャと称する)の3種類に分類でき、ピクチャ種類毎に異なる符号化モードで圧縮されている。
Iピクチャとは、アナログ映像の1フレーム分全ての画像データをそのフレーム内で符号化変換されたデータである(簡単のため、インタレース走査は考えない)。従って、デコーダ16−2等では、このIピクチャを受信した場合、他のピクチャを参照することなくこのIピクチャだけで1フレーム分の画像を再生することができる。
Pピクチャとは、符号化済みの(時間的に前の)IピクチャまたはPピクチャ(以下I/Pピクチャと呼ぶ)から一方向のフレーム間予測を行い、予測差分のデータのみ符号化したものである。従って、デコーダ16−2等では、受信したPピクチャだけでは画像を再生することができず、予測時に参照したI/Pピクチャがなければ画像を再生できない(図9参照)。更に、途中のPピクチャがなければ、誤った画像、例えば、プロック歪等が発生した画像となる。
Bピクチャとは、2つの符号化済みI/Pピクチャ(通常は、時間的に前のピクチャと、後のピクチャ)から2方向のフレーム間予測を行い予測差分データのみ符号化したものである。このBピクチャは、Pピクチャと同様にBピクチャだけでは元の画像を再生できない。PピクチャおよびBピクチャは、前後のピクチャとの時間軸方向の冗長度を削減しているため、圧縮後の符号量を少なくできるが、それだけでは元の画像を再生できない。
(I)(B)(B)(P)(B)(B)(P)(B)(B)(P)(B)(B)(P)(B)(B)(I)(B)(B)(P)・・・・・このようにIピクチャは、15ピクチャに1回存在し、これが繰り返される構成が一般的である。なお、ストリーム中でのデータ順はこれとは異なり、Bピクチャの符復号に必要なPピクチャが、それらBピクチャより前に符号化されトリーム中に配置される。
この1個のIピクチャを含む複数ピクチャからなる時間的周期構造は、ビデオエレメンタリーストリームの基本単位であり、GOP(Group of Picture)と呼ばれる。GOPには、そのGOPの外のピクチャの参照が不要なクローズドGOPと、参照を行うオープンGOPがある。クローズドGOPは、ストリーム中ではIピクチャで始まり、次のIピクチャの直前のPピクチャで終わる。表示時刻順でこのPピクチャと次のIピクチャの間にあったBピクチャは、次のIピクチャのみ参照するように符号化されて、ストリーム中で次のGOPのIピクチャに続けて配置される。GOPの先頭には通常、GOPヘッダが設けられるが、必須ではない。GOPヘッダには、GOP内の先頭ピクチャのタイムコードや、GOPがクローズドかオープンのどちらかを示すフラグ等が記述される。
実際には、ストリーム中にはGOPのほか、映像の途中から復号を始められるようにするためのシーケンスヘッダが、GOP境界等に任意の間隔で挿入されており、シーケンスヘッダには、ピクチャの縦と横のサイズ、クロマフォーマット、ピクチャレート、プロファイル、レベル、ビットレート等の各種パラメータが含まれている。
ステップ401では、受信したストリームデータに、シーケンスヘッダ、GOP、ピクチャ等の各種スタートコードが含まれていないか探索する。
ステップ402では、格納しようとするストリームデータがIピクチャか、Pピクチャかを判定し、Iピクチャの場合(GOP先頭の場合)にはステップ403に進み、Pピクチャの場合にはステップ407に進む。
ステップ404では、現在書き込みに使用中のストリームバッファ要素を判定し、現在使用中のストリームバッファ要素が要素1(図1参照)ならばステップ406に進み、要素2ならばステップ405に進む。
ステップ406では、格納先となるトリームバッファ要素を現在使用されていない要素2に切り替えステップ407に進む。
ステップ408では、ストリームバッファ格納位置を更新する。格納位置は指定形式は、要素の先頭(GOP先頭)からのオフセットアドレスとしてもよく、ピクチャカウンタとピクチャ先頭からのオフセットアドレスの組合せでもよい。
まずステップ501では、画像受信装置113−1から受信した送信要求に含まれるPピクチャ要求数や時刻情報を、所定の変数エリアに保存する。また、ストリームバッファの要素のうち、書込みに使用されている要素を読み出し対象として設定する。
ステップ502では、Pピクチャ要求数を判定し、読み出し対象の要素に格納されたストリームデータが、要求数を満たさない場合には、他方の要素(書込みに使用されていない要素)を読み出し対象として設定する。
ただし、図4の書込み処理の書込み位置が読出し位置に追いついたとき(これは、読み出し対象要素が、当該読み出し処理の開始後に書込み処理によって書込み対象要素に選択された場合に起こりうる)は、その時点でこのステップを終了する。
デコーダ16−2は、任意のタイミングで送信要求15をデコーダ16−1に送信する。デコーダ16−1は、ネットワーク4−2を介して送信要求15を受信すると、自身はエンコーダではないのでそれを中継送信要求の意味に解釈し、その送信要求が示すPピクチャ要求数(本例では15)のGOP単位ストリームデータ17(以後GOP単位データと呼ぶ)が用意でき次第、デコーダ16−2への中継送信を開始する。
デコーダ16−2は、(送信要求15の応答としての)GOP単位データ103の受信開始を検知すると、その開始時刻を記録すると共に、必要に応じ再生バッファをクリアした後、GOP単位ストリームデータ103の伸張(復号)を直ちに開始して、アナログ映像信号を順次出力する。
図6は、本例のデコーダ16−1に係るストリームバッファからの読出し処理のフローチャートであり、図5に代わるものである。図6の処理は、図5と同様、デコーダ16−1が画像受信部(例えば、デコーダ16−2、113−3)からのストリームデータの送信要求を受信するたびに開始される。本処理では、前回送信したピクチャが属したGOPのタイムコードを変数エリアに格納して使用するので、再送信プロセスの起動時に、タイムコードを、それが取りうる最古の値などに初期化しておく。
ステップ601では、デコーダ16−2等から受信した送信要求に含まれるPピクチャ要求数や時刻情報を、所定の変数エリアに保存する。
ステップ602では、前回送信したピクチャが属したGOPのタイムコード(前回タイムコード)を所定の変数エリアから読み出して、現在の書込み対象要素のGOPのタイムコード(現在タイムコード)と比較し、前回タイムコードが現在タイムコードより古い場合、読出し対象要素を現在の書込み対象要素と同じに設定し、読出し位置をその要素の先頭に設定(初期化)する。
なお、ステップ602における現在タイムコードとしては、単純に現在の書込み対象要素のGOPのタイムコードを採用するのではなく、現在の書込み対象要素に少なくともIピクチャが格納されている(書込み位置が2番目以降のピクチャを示している)ときにのみ採用し、それ以外のときは他方の要素のGOPのタイムコードを採用するようにしてもよい。
以上説明したように、本実施例2のデコーダ16−1は、最新のIピクチャ13(例えば映像取込5)から要求のあった所定のPピクチャの送信ピクチャ数に達するまでストリームデータを蓄積する。蓄積が達成した時点で、Iピクチャとこれに続く所定のピクチャ数のPピクチャをGOP単位に加工して、画像受信装置に送信することで、回線状況に合わせたストリームデータ量を任意に指定することができ、回線の効率を最大限に使用できるようにしたものである。
デコーダ16−2は、ネットワーク4−2を経由し、デコーダ16−1にストリームデータの送信要求(図示せず)をする。デコーダ16−1は、ストリームデータの要求があったデコーダ16−2に、その時点で最新のIピクチャであるIピクチャ13−1を伝送する。デコーダ16−2は、Iピクチャ13−1を受信したら即座にストリームデータの復号(伸張)を開始する。このIピクチャ13−1の受信に係る期間を、デコーダ16−2の映像伸張1として図示してある。なおピクチャの受信完了から復号完了までの時間はフレーム時間に対して十分短いとみなして、受信期間と復号期間はほぼ同じとして扱う。なお、上述の「即座に復号」とは、受信中のピクチャの2つ前のピクチャを復号することは含まないが、1ピクチャ分のデータの受信完了を待って復号を開始する(つまり、1つ前のピクチャを復号する)ことまでは含む。
本例のデコーダでは、常時少なくとも1GOP分のストリームデータが1GOP時間以上バッファされているため、デコーダ16−3のように少なくとも1GOP時間(最大で2GOP時間)を使ってIピクチャを送信することができる。
図13は、本実施例3のデコーダ18のブロック図である。図13において、画像送信装置1等からIPパケット化された映像データが入力端子130に入力される。なお映像データの符号化方式としてMPEG-4 Part2 Visualを想定する。
Protocol)もしくはTCP(Transmission Control Protocol)である。
RFC3016は、MPEG-4 Visualのビットストリーム(符号化データ)をMPEG-2システム等を用いずにネットワーク上で伝送するのに適したRTPペイロードフォーマットを規定している。1ピクチャ(フレーム)を構成するVOP(Video Object Plane)を1乃至複数のRTPパケットで伝送する場合、各RTPパケットのペイロード先頭には常にコンフィグレーション情報、VOPヘッダ、VP(Video packet)ヘッダのどれかを配置し、エラー耐性を高めている。
RTPパケット処理部134−1、134−2〜134−4は通常、プロセッサ(不図示)上で動作するソフトウェアにより実現され、受信ストリーム数及びクライアント数に対応する数だけそれぞれ起動される。I−VOP周期バッファ133も受信ストリーム数だけ起動される。
リングバッファ81は、RTPパケット処理部134−1からのビットストリームを、書き込みポインタWPの示す位置から順次書き込み、読出しポインタRPの示す位置から順次読み出してRTPパケット処理部134−2等に出力する。
リングバッファ81は、1GOV(Group of VOP)分のビットストリームを保持するのに十分な容量のFIFO型のバッファ(リングバッファ)であり、WPはRPより優先度が高く、RPを追い越すことができる(RPをWPの前に強制移動する)。
最新GOVタイムコードとは、リングバッファ81にIーVOP(図では、Iと表示)を書き込む都度、そのIーVOPの直前にあるGOVヘッダ中のタイムコードが、RTPパケット処理部134−1により書き込まれるものである。
読出済GOVタイムコードとは、リングバッファ81からIーVOPが読み出される都度、最新I−VOPタイムコードがコピーされて書き込まれるものである。
I−VOPの検出は、RTPパケット処理部134−1から通知されるMビットに拠っても、或いはGOVヘッダの先頭にある32bitの”group_vop_start_code”をビットストリーム中からサーチすることに拠っても良い。また、GOVヘッダ中のタイムコードの代わりにRTPパケットヘッダ中のタイムスタンプを用いても良い。
各RTPパケット処理部134−2、134−3、134−4は、L2−L3処理部135からの伝送レートに応じたレディー信号(図13では点線で示す信号)により、I−VOP周期バッファ133から符号化データを読み出す。レディー信号とは、例えばRTCPのRR(Receiver Report)である。TCPの場合、クライアント(画像受信装置やデコーダ等)からのACK(受信応答)を利用可能ではあるが、RTCPの併用が望ましい()。例えば、各RTPパケット処理部134−2等は定期的にSRをクライアントに送信し、クライアントから返信されるRRに含まれるパケット破棄率情報や最新SR受信時刻情報などを得る。この定期的な情報から、パケット破棄率がゼロとなるように(目標)送信レートを決定する。
例1:最新GOVタイムコード
<> 読出しGOVタイムコード
例2:d秒 >(最新GOVタイムコード
− 読み出し対象VOPのタイムコード)
例3:d秒 >(最新のI−VOPのタイムスタンプ
− 読み出し対象VOPのタイムスタンプ)
例4:a >(読出しポインタRP
− 書込みポインタWP)
等がある。なお、読み出し対象VOPとは読出しポインタRPが指す位置のVOPのことであり、“<>”は左辺と右辺が等しくないことを意味する。dは、正の値であり、I-VOP周期やネットワーク伝送ジッタ(RTCPのRRから得られる)に応じて適切に設定するものとする。なお、例2における、「読み出し対象VOPのタイムコード」は、VOPヘッダからは直接得られず、読出済GOVタイムコードと、VOPヘッダ内のmodulo_time_baseやvop_time_incrementとから計算する必要がある。その他の値は、ヘッダポインタテーブル83等に格納されているものを用いる。例4はWPがRPに迫ってきていることを意味し、アドレスの差がa未満になると真となる。
低レート伝送路に対しては、読み出し速度が書き込み速度より遅くなる場合がある。この場合の読み出し条件判断処理では、I−VOPタイムコードに格納されているI(n)よりも時間の早い(タイムコードの小さい)P(3)を読み出すことになる。従って、その差分がd秒以上となるため、上述の読み出し条件が成立することになり、I(n)に読み出しポインタRPを移動してI(n)を読み出す動作となる。
本例の伝送レート適応型パケット伝送方式は、ベストエフォートの伝送路(ネットワーク)に対して有効である。つまり、伝送レートの動的な変動に対しても自動的に適応した画像符号化データの伝送が可能となる。
H.264のエンコーダは概念的に、スライス単位で符号化データを出力するビデオ符号化レイヤ(VCL)と、そのスライス出力をパケットネットワークでの伝送に適したNALユニットにパケット化するネットワーク抽象化レイヤとから構成される。スライスとは、1ピクチャ(フレーム)を1乃至複数に分割したものであり、1ピクチャ分のデータの集まりはAU(アクセスユニット)と呼ばれる。
”nal_unit_types”の値は、NALユニットの内容が、IDRピクチャ(他のピクチャに依存せずに復号可能なピクチャ。前述のIピクチャに相当)のスライスであれば”5”になり、AU delimiter(アクセスユニットの境界を示す)であれば”9”になり、またSVC(Scalable
Video Coding)を用いたときには、それらに対応する値をとる。その他、シーケンスパラメータセット、ピクチャパラメータセット、サブセットシーケンスパラメータセット、End of sequence等のNALについても値が決められている。
H.264は、シンタックスの自由度が高いのが特徴であり、スライス(ピクチャ)の標本化/再生時刻(順序)とは異なるような、符号化順序、伝送時刻順序、復号順序が許容されている。また上述のようなNALユニット化より、従来のエレメンタリーストリーム中で使用されていたスタートコードが不要になっている。
本例のRTP処理部44−1(134−1に相当する)は、受信したRTPパケットに対し、RFC3984等に規定されているRTP処理等をして、RTPペイロードを出力する。この規定におけるRTPペイロードフォーマットには、シングルNALユニットパケット、集合パケット、分割パケット等があるが、必ず、ペイロードの先頭はNALヘッダから始まるようになっている。
parameter set、picture parameter、SEI等のNALユニットが配置され、AU delimiter NALの前にはEnd of sequence NALが配置される場合があり、これらを利用して検出しても良い。1IDRピクチャ分のIDR−NALが複数ある場合でも、それらは連続していることが通常である。
或いは、もしSVCを用いていれば、NAL拡張ヘッダも参照して、重要度や他からの依存性の低いNALから送信をスキップする。拡張ヘッダには、空間、CGS、MGS、FGS等のレイヤ構造においてどの階層に属するかを示す情報を含む。拡張ヘッダが無い場合、シンタックスを解釈して判別する。つまりNALペイロードの先頭には通常、スライスヘッダがあるのでそれを参照する。
送信レートが絞られていくと最終的に、VCLクラスのNALとしてはIDR−NALの一部だけを送信するようになる。ただし、AU delimiter NALのような重要なnon−VCLクラスのNALもスキップせず送信する。
本例では、NAL(RTPパケット)のスキップにより、AUの最後のRTPパケットにMビットを適切に設定できない可能性があるが、通常の伝送路上のパケットロス同様、Mビットだけに頼らない実装が一般的となっており、問題ない。
2008年11月)に準拠したネットワーク映像配信システムで使用されることを前提にした点などで先の実施例4と異なる。
ONVIFでは、サービス指向アーキテクチャが採用されており、ネットワーク上にある機器を発見したり、カメラ、画像送信装置(エンコーダ)、画像受信装置(デコーダ)の仕様(プロファイル)情報を交換したり、雲台を制御したりするための各種の通信は全てWSDL(Web Service Description Language)で定義され、それらの機能はWebサービスとして提供される。WSDLはXMLの構文で記述され、SOAP(Simple
Object Access Protocol)のメッセージとして通信される。SOAPのメッセージ(エンベロープ)は、更にHTTPを用いてそのBODY内に格納されて伝送される。
本例のSOAP/HTTP処理部31は、マルチキャストアドレスに限らず、ブロードキャストされたSOAPメッセージ、或いはLAN上のモニター可能な全てのSOAPメッセージを受信している。
もしクライアントからの映像要求である”GetStreamUriRequest”を受信すると、Webサービス管理部33は、映像要求の対象(Media profileで特定される)が、現在デコーダ30自身で受信しているものかどうか判断し、受信していなければその映像要求を無視し、受信していればデコーダ30のホスト名を含むURIを含む応答”GetStreamUriResponse”を返す。URIは、ホスト名以降のパス名として、対応するMedia profileを特定可能な文字列等が付加されて、動的に生成されうる。映像要求を無視しても、クライアントは、DPサーバ等からの応答を受け取ってそのURI(IP力メラ等のもの)を知ることができる。一方、有効な(エラーではない)応答を冗長に受け取った場合は、URIをアドレス解決し、そのIPアドレスがクライアントの属するネットワークに近い方(或いはネットマスクが一致する方)を採用すればよい。
”GetStreamUriResponse”を受け取ったクライアントは、当該URI宛にRTSPのDESCRIBEメソッドを送信するが、デコーダ30がそれを受信した場合、映像再配信要求と解釈して、セッションを初期化し、プレゼンテーションを開始する。つまりRTP処理部34−2等(実施例4の44−2等に相当する)を新たに起動し、要求対象に対応するIDR周期バッファからストリームを読み出して、要求元クライアントに配信する。
もしクライアントが発したWebサービス要求が直接、宛先通りに真のエンコーダ等に届き、応答が両者から帰ってきた場合、クライアントは任意の一方(例えばネットマスクが一致する方)を採用すればよい。
configuration”、”Video encoder
configuration”、”PTZ configuration”などが規定されている。
本例のデコーダ30は、MPEG等の動画の形式で受信中の映像について、JPEGで映像要求を受けたときに、処理負荷に余裕があれば、MEPGを復号して得た映像をJPEGにトランスコードして、要求元に配信(プレゼンテーション)することもできるようにする。具体的な処理の手順は以下のようになる。
GetProfilesRequest”を受信する。Webサービス管理部33はそれを解釈し、Media Profileが示す映像源(Video source configuration)が、デコーダ30が現在受信中のものと同じか否か判定し、同じでなければ、Media Profileを1つも含まない空の”GetProfilesResponse”を応答する。ステップ401において映像源が、同じであれば、符号化方式やピクチャサイズ等も同じか否かを判定する。
ステップ402として、ステップ401において映像源が同じと判定された場合、処理負荷の余裕度に応じて、1乃至複数のMedia Profileを含む”GetProfilesResponse”を応答する。即ち、余裕度があれば、現在受信中の映像の符号化方式やピクチャサイズ等と同じ”Video encoder
configuration”を規定するMedia Profileの他、符号化処理部35で再符号化可能な他の映像形式を指定するMedia
Profileも含ませる。
ステップ403として、ステップ402の”GetProfilesResponse”を受信したクライアントから”GetStreamUriRequest”等の映像要求を受信した場合、その時点で処理負荷に余裕があれば、デコーダ30のホスト名を含むURIを生成して応答”GetStreamUriResponse”を返すとともに、映像要求が指定するMedia Profileの示す符号化方式やピクチャサイズ等で符号化するよう、符号化処理部35を初期化する。
ステップ404として、ステップ403の”GetStreamUriResponse” を受信したクライアントからRTSPの所定のメソッドを受信した場合、セッションを初期化し、プレゼンテーションを開始する。符号化処理部35は、指定された符号化方式等に従い、必要に応じてフレーム間引き処理、インタレース/プログレッシブ変換処理、リサイズ処理(超解像処理によるサイズの拡大も含む)等を行なう。Media Profileとして複数のVideoSourceを指定することも可能であり、その場合、複数の映像を1画面に合成し(例えば4−up)、1ストリームに符号化して再配信する。
3 画像サーバ装置、 4 ネットワーク、
5 パーソナルコンピュータ(PC)、6 画像受信装置(従来)、
7 PC(操作専用)、 8,8a ビデオモニタ、
9 専用操作器、
11−1〜11−n アナログ映像、 12 アナログカメラ、
13−1〜13−n I/Pピクチャ、14 ストリームバッファ、
16、18、30 ネットワークデコーダ装置(デコーダ)、
17 GOP単位ストリームデータ、
31 SOAP/HTTP処理部、 32 セッション管理部、
33 Webサービス管理部、 34,44,134 RTP処理部、
35 符号化処理部、 43 IDR周期バッファ、
81 リングバッファ、 82 I−VOPタイムコードレジスタ、
83 ヘッダポインタテーブル、
131,135 L2−L3処理部、 132 復号化処理部、
133 I−VOP周期バッファ、 136 出力端子。
Claims (4)
- 映像送信装置からIPネットワークを介して符号化映像データを受信し、復号して出力するネットワークデコーダ装置において、
受信した符号化映像データを、少なくともIピクチャ周期分格納するバッファと、
符号化映像データの再配信要求を受信したときに、Iピクチャから所定のPピクチャ数分を1単位として前記バッファから符号化映像データを順次読み出して、該再配信要求の要求元クライアントへ送信する再配信手段と、
該受信した符号化映像データの送信元の映像送信装置が有するサーバ機能と互換の機能を有し、前記再配信要求を受け付けるサーバ手段とを備え、
該再送信手段は、バッファに格納された最新Iピクチャより古いデータを符号化映像データの送信をスキップし、
前記再配信要求は、前記映像送信装置が符号化映像データの送信に使用可能な複数のプロトコルのうちの任意のプロトコルを指定して再配信を要求するものであり、
前記サーバ手段は、該指定されたプロトコルを使用して再配信をするように前記再配信手段を制御し、
前記再配信要求に基づいて再配信された符号化映像データを受信すると、受信した時刻と現在の時刻とを比較し、その差が前記1単位の時間より長ければ次回の再配信要求数を減らし、その差が前記1単位の時間より短ければ次回の再配信要求数を増やすことを特徴とするネットワークデコーダ装置。 - 請求項1記載のネットワークデコーダ装置において、
サーバ手段は、前記再配信の送信先から、前記映像送信装置が送信する符号化映像データの情報源である力メラに関する制御要求を受信したとき、該制御要求を該映像送信装置に宛てて転送することを特徴とするネットワークデコーダ装置。 - 請求項2記載のネットワークデコーダ装置において、
入力された複数の映像データを、該複数の映像が1画面内に並んで表示されるように1の映像データに合成し、該合成された1の映像データを符号化する符号化処理手段を更に備え、
映像源の異なる映像送信装置から複数の符号化映像データを受信して前記符号化処理手段に入力し、該合成された1の映像データを、クライアントからの要求に応じて再配信することを特徴とするネットワークデコーダ装置。 - 前記ネットワークデコーダ装置は、
クライアントからサービスの探索を受信したときには、前記受信した符号化映像データの送信元の映像送信装置の代わりに該探索に応答して、該ネットワークデコーダ装置のURIを該クライアントに通知し、
該クライアントから該URIにメディアプロファイルの問い合わせを受けたときには、
前記受信した符号化映像データと同じ映像形式を規定するメディアプロファイルを含む1乃至複数のメディアプロファイルを該クライアントに通知し、
該クライアントから該メディアプロファイルに基づく映像要求を受信したときに、前記再配信を行なうことを特徴とする請求項2記載のネットワークデコーダ装置。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009120883A JP5389528B2 (ja) | 2009-05-19 | 2009-05-19 | ネットワークデコーダ装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2009120883A JP5389528B2 (ja) | 2009-05-19 | 2009-05-19 | ネットワークデコーダ装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2010272943A JP2010272943A (ja) | 2010-12-02 |
JP5389528B2 true JP5389528B2 (ja) | 2014-01-15 |
Family
ID=43420656
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2009120883A Active JP5389528B2 (ja) | 2009-05-19 | 2009-05-19 | ネットワークデコーダ装置 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP5389528B2 (ja) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6425389B2 (ja) * | 2014-02-19 | 2018-11-21 | キヤノン株式会社 | 撮像装置、及び撮像システム |
US9350484B2 (en) * | 2014-03-18 | 2016-05-24 | Qualcomm Incorporated | Transport accelerator implementing selective utilization of redundant encoded content data functionality |
JP6357188B2 (ja) * | 2016-04-12 | 2018-07-11 | 株式会社Nexpoint | 監視カメラシステム及び監視カメラデータ保存方法 |
CN113395546B (zh) * | 2020-03-13 | 2022-12-06 | 杭州海康威视数字技术股份有限公司 | 一种媒体显示的控制系统、方法及控制设备 |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4255685B2 (ja) * | 2002-02-18 | 2009-04-15 | 株式会社日立国際電気 | 画像伝送方法および画像伝送装置 |
JP2006279893A (ja) * | 2005-03-30 | 2006-10-12 | Victor Co Of Japan Ltd | 画像処理装置及び画像処理方法 |
JP2008193500A (ja) * | 2007-02-06 | 2008-08-21 | Canon Inc | データ送信装置及びデータ中継装置 |
-
2009
- 2009-05-19 JP JP2009120883A patent/JP5389528B2/ja active Active
Also Published As
Publication number | Publication date |
---|---|
JP2010272943A (ja) | 2010-12-02 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
KR101983432B1 (ko) | 동적 적응형 스트리밍 오버 http(dash)를 http 라이브 스트리밍(hls)으로 변환 또는 번역하기 위한 장치, 시스템, 및 방법 | |
JP5770345B2 (ja) | ビデオデータをストリーミングするためのビデオ切替え | |
US10951930B2 (en) | Adaptive content delivery network | |
JP4921488B2 (ja) | スケーラブルなビデオ符号化を用いて、またスケーラブルなテレビ会議サーバを複合してテレビ会議を行うためのシステムおよび方法 | |
RU2510908C2 (ru) | Описание характеристик агрегированных блоков медиаданных с обратной совместимостью | |
JP4195030B2 (ja) | 連続的なビデオディスプレイのためのビデオデータの送信方法及び受信方法 | |
US10805615B2 (en) | Synchronizing video signals using cached key frames | |
JP6522583B2 (ja) | 改善されたrtpペイロードフォーマット設計 | |
WO2009128528A1 (ja) | サーバ装置とコンテンツ配信方法とプログラム | |
WO2009128515A1 (ja) | ゲートウエイ装置と方法とプログラム | |
US20070188594A1 (en) | Communication system, communication terminal and communication method | |
US9153127B2 (en) | Video transmitting apparatus, video receiving apparatus, and video transmission system | |
JP2006508574A (ja) | 要求に応じたi画像の挿入 | |
WO2011030811A1 (ja) | 配信システム、ゲートウェイ、配信方法及びプログラム | |
US20200021867A1 (en) | Broadcast signal transmitting and receiving method and device | |
KR101808639B1 (ko) | 다중 네트워크 환경 적응형 미디어 스트리밍 전송방법 및 그 장치 | |
JP5389528B2 (ja) | ネットワークデコーダ装置 | |
JP5734699B2 (ja) | 配信映像の超解像化装置 | |
JP4799191B2 (ja) | 通信端末、通信システムおよび通信方法 | |
US8290063B2 (en) | Moving image data conversion method, device, and program | |
KR101249613B1 (ko) | 비디오 스트리밍을 위한 네트워크 적응형 가변 스트림 계층화 장치 및 방법 | |
Johanson | Designing an environment for distributed real-time collaboration | |
Luis et al. | Scalable streaming of JPEG 2000 live video using RTP over UDP | |
JP2006229618A (ja) | 映像通信システム、映像通信装置、プログラム、及び映像通信方法 | |
Al-Khatib et al. | IPTV multimedia networks: concepts, developments, and design |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20120330 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20130415 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130508 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130702 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20130725 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130802 |
|
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: 20131003 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20131009 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 5389528 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
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 |
|
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 |