ネットワークデコーダ装置
【課題】ネットワークデコーダからのカメラ制御の操作性を改善する。
【解決手段】デコーダ１６は、画像送信装置１ａ等から受信した各画像データを、復号化してビデオモニタ９に出力すると共に、デコーダ１６に配信要求をしたクライアントに対して再配信を行う。クライアントがデコーダ１６にカメラ制御要求をすると、デコーダ１６はそれを画像送信装置１ａ等に転送する。従って、デコーダ１６は、従来の画像受信装置６からはあたかも画像送信装置１等のように認識される。実行伝送速度の異なる複数のクライアントへ再配信を行なうため、受信した画像データを少なくともＩピクチャ周期分格納する共通バッファを備え、各クライアントに対しては、順次読み出しを原則とし、受信した最新Ｉピクチャより古い符号化映像データをスキップする様態で再配信を行なう。
【解決手段】デコーダ１６は、画像送信装置１ａ等から受信した各画像データを、復号化してビデオモニタ９に出力すると共に、デコーダ１６に配信要求をしたクライアントに対して再配信を行う。クライアントがデコーダ１６にカメラ制御要求をすると、デコーダ１６はそれを画像送信装置１ａ等に転送する。従って、デコーダ１６は、従来の画像受信装置６からはあたかも画像送信装置１等のように認識される。実行伝送速度の異なる複数のクライアントへ再配信を行なうため、受信した画像データを少なくともＩピクチャ周期分格納する共通バッファを備え、各クライアントに対しては、順次読み出しを原則とし、受信した最新Ｉピクチャより古い符号化映像データをスキップする様態で再配信を行なう。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークデコーダ装置に関し、特にネットワークを介して受信した符号化映像データを復号するとともに他の機器に再配信するネットワークデコーダ装置に関する。
【背景技術】
【０００２】
従来、監視カメラで撮影した映像を符号化し、ＩＰネットワークを介して伝送するＣＣＴＶ（Closed Circuit TeleVsion）システムが知られる。
【０００３】
図１１は、従来のＣＣＴＶシステムの模式図である。ＷＥＢサーバ機能を有する画像送信装置（画像伝送装置）１ａ、１ｂ、ＩＰ力メラ２、或いは画像サーバ装置３（以後、画像送信装置１等と呼ぶ）は、符号化（圧縮）画像デジタルデータ（以後、画像データと呼ぶ）を各種通信プ口トコルを用いてネットワーク４を経由で送信する。パーソナルコンピュータ（ＰＣ）５や画像受信装置６（これらをクライアントと総称する）は、自身宛の画像データを受信して復号化し、映像の表示或いはビデオモニタ８への映像信号の出力を行う。
【０００４】
画像受信装置６は、シリアル信号を、画像送信装置１ａ、１ｂやＩＰ力メラ２との間でネットワーク４を介して双方向通信する機能を有し、カメラ制御用のシリアル信号を、RS-485やRS-232Cケーブルで接続された専用操作器９から或いはネットワークで接続されたＰＣ７から入力されると、それをＩＰ力メラ２等に中継する。ＰＣ５も、同等の機能をソフトウェアにより実現する。
【０００５】
上述の他、映像データの中継（転送）機能を有する映像再生装置等が知られる（例えば、特許文献１及び２参照。）。また、映像データを中継或いは送信する際に、フレームの間引き（コマ落し）を行うストリームデータ配信システム等が知られる（例えば、特許文献３及び４、非特許文献１及び２参照。）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】国際公開第０５／０５０９３１号パンフレット
【特許文献２】特開２００７−２０１９９５号公報
【特許文献３】特開２００７−１９３６９０号公報
【特許文献４】特許第４２５５６８５号公報
【非特許文献】
【０００７】
【非特許文献１】福永茂，外３名，"LANにおける分散マルチポイント画像伝送方式の検討"，1993年画像符号化シンポジウム(PCSJ93)第8回シンポジウム資料，社団法人 電子情報通信学会，1993年10月，p.83-84
【非特許文献２】笠井裕之、富永英義，"マルチプルトランスコーダ・ストリームスイッチングに基づくスケーラブルゲートウェイ方式"，電子情報通信学会論文誌. B，平成15年10月1日，J86-B，No.10，p.2229-2244
【非特許文献３】John Beatty，外１２名， “Web Services DynamicDiscovery (WS-Discovery)”，[online]，2005年4月，インターネット＜ＵＲＬ：http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
図１１において、画像受信装置６は新たに増設されたものとし、ＰＣ５で表示している映像と同じ映像を表示させる場合を考える。このとき、画像送信装置１ａ等は、ＰＣ５と画像受信装置６のそれぞれに宛てて画像データを個別に送信するので、ネットワーク４で伝送される映像データが２倍に膨れ上がってＰＣ５または画像受信装置６が利用できる帯域幅が圧迫され、映像受信に支障をきたす場合がある。これは画像送信装置１が最大配信の能力に対しベストエフォートにて処理を行っているからであり、各クライアントに同じ条件の各画像データを配信できなくなる。
或いは、画像送信装置１ａ等の配信能力の不足によりフルフレームの映像を送ることができない場合がある。画像送信装置１ａ等において、接続クライアント数に応じて配信のための処理能力（処理時間、バッファメモリ）が分配されるが、接続数が多くなると１クライアント当たりの処理能力が十分でなくなるためである。
【０００９】
また、画像受信装置６にネットワーク４経由でアクセスしているＰＣ７は、専ら制御のためのものであり、画像送信装置１等からの映像を確認することはできない。そのため、ＰＣ７から力メラ制御する際には、ビデオモニタ８の表示映像を確認しながらＰＣ７から力メラ制御を行うこととなり、操作性が悪いという問題があった。
【課題を解決するための手段】
【００１０】
本発明のネットワークデコーダ装置（画像受信装置）は、ネットワークを利用した画像送信装置もしくはＩＰ力メラ、画像サーバ装置などからネットワークを経由して各画像データ（符号化画像デジタルデータ）を受信し、受信した画像データに復号化画像処理を行いＮＴＳＣ信号もしくはデジタル映像信号に変換出力する。それと共に、当該ネットワークデコーダ装置に対して画像要求をした他のクラアイアントへ、画像送信装置等から受信した画像データを再配信する。これにより、画像送信装置等とネットワークデコーダ装置間の伝送路に必要とされるビットレートを抑える事ができる。
また、ＷＥＢサーバ機能を有する雲台付力メラ画像送信装置もしくはＩＰ力メラ、画像サーバ装置への力メラ制御要求を、画像受信装置に直接接続された専用操作器のみならずネットワーク経由でアクセスしている各クライアントから行なえるよう、ネットワークデコーダ装置は制御要求を中継する。これにより、力メラ制御要求の宛先を映像要求のそれと同じにでき、制御を簡略化する事ができる。
また、画像送信装置からの実効受信レートと、各クライアントへの実効送信レートとは必ずしも一致しないため、受信した符号化映像データを少なくともＩピクチャ周期分格納するバッファと、符号化映像データの再配信要求を受信したときに、前記バッファから符号化映像データを順次読み出して、該再配信要求の要求元へ送信する再配信手段と、を備えて、該再送信手段が、バッファに格納された最新Ｉピクチャより古いデータを符号化映像データの送信をスキップする。
【発明の効果】
【００１１】
本発明によれば、ネットワークデコーダが受信した映像データを再配信するようにしたので、カメラ制御を行うクライアントＰＣの画面に映像を表示させ、力メラ制御の操作性を向上させることができる。また、その再配信機能により、ネットワークの負荷を過剰に増加させることなく映像を表示可能なクライアントＰＣの数を多くすることができ、システムの構築が容易になる。
【図面の簡単な説明】
【００１２】
【図１】デコーダ１６−１へのピクチャデータの流れ示す模式図（実施例１）
【図２】ネットワーク映像配信システムの配信動作を説明する図（実施例１）
【図３】デコーダ３０のブロック図（実施例５）
【図４】ストリームバッファへの書き込み処理のフローチャート（実施例１）
【図５】ストリームバッファからの読出し処理のフローチャート（実施例１）
【図６】ストリームバッファからの読出し処理のフローチャート（実施例２）
【図７】ネットワーク映像配信システムの配信動作を説明する図（実施例２）
【図８】Ｉ−ＶＯＰ周期バッファ１３３の構成図（実施例３）
【図９】Ｐピクチャのスキップを説明する図（実施例２乃至６）
【図１０】ネットワーク映像配信システムの模式図（実施例１）
【図１１】従来のＣＣＴＶシステムの模式図
【図１２】ネットワーク映像配信システムの模式図（本発明）
【図１３】デコーダ１８のブロック図（実施例３）
【発明を実施するための形態】
【００１３】
以下、本発明のネットワークデコーダ装置の一例を用いたネットワーク映像配信システムについて、図面を参照して説明する。
なお、本システムは、ネットワークデコーダ装置（画像受信装置）において、符号化映像データを受信して復号しＮＴＳＣ信号もしくはデジタル映像信号出力によりモニター画面に映像表示させる通常の機能に加え、力メラ制御を行うＰＣの画面上にも同じ映像を表示させ、該映像を確認しながら力メラ制御を行えるようにすることを意図し、下記の性能を満足することを目標にしている。
(1) 画像送信装置に対する配信負荷を増加させないこと。
(2) 画像送信装置と画像受信装置、クライアントＰＣ間のネットワーク伝送路の負荷の増加を最小限にすること。
(3) 画像送信装置と力メラ制御用の通信を行うときは、画像受信装置を経由させる事で制御の複雑さを緩和させる。
【００１４】
図１２は、ネットワーク映像配信システムの模式図である。図１１に示した従来の構成と同一の箇所には、同一の符号を付してある。
ネットワークデコーダ装置１６（以後、デコーダと呼ぶ）は、予め設定された通信プ口トコルを用いて、画像送信装置１等から目的の各画像データをネットワーク４を経由して受信する。その際、画像送信装置１等から送信されネットワーク４を伝送する画像データは、１クライアント分のトラフイック量であり、設計上の品質で支障なく伝送できる。ネットワーク４は、遠地に設置される画像送信装置等を多数接続するものであるため、ＳＯＮＥＴ（Synchronous Optical NETwork）のような高速なものから、５６Ｋｂｐｓのモデム回線まで、各種の物理層が使用されうる。
【００１５】
デコーダ１６は、受信した各画像データを復号化し、ＮＴＳＣ信号もしくはＨＤＭＩ等のデジタル映像信号に変換してビデオモニタ８ａに送信すると共に、受信した各画像データのストリームをバッファに一時蓄積し、デコーダ１６に対して映像要求をしたＰＣ５や画像受信装置６へ再送信（再配信）する。デコーダ１６とＰＣ５等とは、ネットワーク上で近距離（例えばＬＡＮ内）であるか、十分な帯域の伝送路で接続されていることを想定しており、図１２では、便宜的にネットワーク４を介せずに途中から分岐するように図示してある。
【００１６】
この再送信の通信プロコトルは、画像送信装置１等がＰＣ５に送信するときに利用可能なものと同じであり、ＨＴＴＰ、ＲＴＰ、マルチキャスト（ＲＴＰ）等から選択することができる。つまり、デコーダ１６は、従来の画像受信装置６からはあたかも画像送信装置１等のように認識される。
またトランスポート層以上の上位層において、例えば、バッファとして最新の完全な１ＧＯＰ（Group of Picture）分のデータの保存に必要な容量を備え、フレーム間引きにより適応的な送信レート制御を行うようにする。最新のＧＯＰの先頭を受信すると、継続中の直前のＧＯＰの再送信は、直ちに或いはフレームかスライスの境界で中止され、該最新のＧＯＰの再送信を開始する。これにより、モデム等を使用した低品質の回線を用いた場合でも、最低限の復号可能な（フレーム内符号化された）１ピクチャ分の映像データを再配信することができる。
【００１７】
ところで、デコーダ１６の再送信機能を使用することにより、再送信するクライアント数、通信プ口トコル、画像送信装置の符号化ビットレート量によっては、本来の復号化処理がリアルタイムに行えずこま落ちすることが懸念される。そのため、各クライアントからの要求による再送信のプライオリティを、復号化処理のプライオリティより相対的に下げるなどし、復号化処理に支障が発生しない様にする。または、画像受信装置と各クライアントが同じブロードキャストドメイン内にあるか、再送信を行う経路上のルータやＬ３スイッチ等がマルチキャストに対応している場合は、プ口トコルとしてマルチキャストを選択することもできる。
【００１８】
更には、デコーダ１６のクライアント機能（画像を要求し受信する機能）を複数同時接続可能にすることで、同時に複数のサーバ機能（要求に応じ画像を送信する機能）を有する画像送信装置１等から符号化画像圧縮データを受信し、各符号化画像圧縮データの復号化およびリサイズにより４画面合成したＮＴＳＣ信号もしくはデジタル映像信号を出力すると共に、クライアントから再配信要求によりクライアントＰＣ画面上でもその４画面合成映像を表示できるようにしてもよい。
【実施例１】
【００１９】
図１０は、実施例１に係るネットワーク映像配信システムの模式図である。本実施例１は、ネットワークデコーダ装置が再送信する際のレート制御として、特許文献４に記載の方法を用いたものである。図１０のシステムは、一つの画像送信装置１ａからの映像データをネットワークデコーダ装置（デコーダ）１６−１が中継することで、他の離れた場所のビデオモニタ８ｂおよび８ｃにおいても映像の閲覧を可能にしたものである。
【００２０】
アナログカメラ１２は、所定のフレームレート（例えば３０fps）で撮影した監視映像の信号（ＮＴＳＣ信号）を、画像送信装置１ａへ出力する。
画像送信装置１ａは、入力された映像信号を目標ビットレートになるように圧縮符号化し、符号化映像データ（ストリームデータ）を所定のプロトコルに従ってネットワークインタフェースから送信する。
デコーダ１６−１は、画像送信装置１ａから対応するプロトコルで受信した符号化映像データを復号化しアナログ映像信号として出力する（図示せず）とともに、受信した符号化映像データをバッファに格納し、所定のプロトコルに従ってネットワークインタフェースから送信する。
デコーダ１６−２、１１３−３は、デコーダ１６−１から対応するプロトコルで受信した符号化映像データを復号化しアナログ映像信号として出力する。
【００２１】
ネットワーク４−１は、画像送信装置１ａとデコーダ１６−１とを接続する任意の伝送路であり、本例では最大で３８４kbpsの通信速度を有する第３世代携帯電話網（パケット通信網）を想定する。
ネットワーク４−２は、デコーダ１６−１とデコーダ１６−２とを接続する任意の伝送路であり、５１２kbps程度の実効通信速度を有するＡＤＳＬ回線を想定する。
ネットワーク４−３は、デコーダ１６−２とデコーダ１６−３とを接続する任意の伝送路であり、２Mbps程度の実効通信速度を有するＬＡＮ(Local Area Network) を想定する。
ネットワーク４−１〜３はいずれもＩＰパケットを伝送することができる。なお、図１０ではデコーダ１６−１等が２つのネットワークに直接接続するかのように図示してあるが、ルータ機能の内蔵を意図したものではなく、デコーダ１６等は、物理インタフェースとして、Ethernet（商標）等のポートを１個備える。
【００２２】
ここで、ＭＰＥＧ方式の画像圧縮技術における基本的な事項を説明する。MPEG-2 Video（ISO/IEC 13818-2）やMPEG-4 Part2 Visual（ISO/IEC 14496-2）のエレメンタリーストリームにおける符号化画像本体は、大よそ、Intra Picture（以下、Ｉピクチャと称する）、Predictive
Picture（以下、Ｐピクチャと称する）およびBiderectionally Predictive
Picture（以下、Ｂピクチャと称する）の３種類に分類でき、ピクチャ種類毎に異なる符号化モードで圧縮されている。
Ｉピクチャとは、アナログ映像の１フレーム分全ての画像データをそのフレーム内で符号化変換されたデータである（簡単のため、インタレース走査は考えない）。従って、デコーダ１６−２等では、このＩピクチャを受信した場合、他のピクチャを参照することなくこのＩピクチャだけで１フレーム分の画像を再生することができる。
Ｐピクチャとは、符号化済みの（時間的に前の）ＩピクチャまたはＰピクチャ（以下Ｉ／Ｐピクチャと呼ぶ）から一方向のフレーム間予測を行い、予測差分のデータのみ符号化したものである。従って、デコーダ１６−２等では、受信したＰピクチャだけでは画像を再生することができず、予測時に参照したＩ／Ｐピクチャがなければ画像を再生できない（図９参照）。更に、途中のＰピクチャがなければ、誤った画像、例えば、プロック歪等が発生した画像となる。
Ｂピクチャとは、２つの符号化済みＩ／Ｐピクチャ（通常は、時間的に前のピクチャと、後のピクチャ）から２方向のフレーム間予測を行い予測差分データのみ符号化したものである。このＢピクチャは、Ｐピクチャと同様にＢピクチャだけでは元の画像を再生できない。ＰピクチャおよびＢピクチャは、前後のピクチャとの時間軸方向の冗長度を削減しているため、圧縮後の符号量を少なくできるが、それだけでは元の画像を再生できない。
【００２３】
一般的なＭＰＥＧ−２の各ピクチャの組合せの一例を、表示時刻順に示すと以下のようになる。
（Ｉ）（Ｂ）（Ｂ）（Ｐ）（Ｂ）（Ｂ）（Ｐ）（Ｂ）（Ｂ）（Ｐ）（Ｂ）（Ｂ）（Ｐ）（Ｂ）（Ｂ）（Ｉ）（Ｂ）（Ｂ）（Ｐ）・・・・・このようにＩピクチャは、１５ピクチャに１回存在し、これが繰り返される構成が一般的である。なお、ストリーム中でのデータ順はこれとは異なり、Ｂピクチャの符復号に必要なＰピクチャが、それらＢピクチャより前に符号化されトリーム中に配置される。
この１個のＩピクチャを含む複数ピクチャからなる時間的周期構造は、ビデオエレメンタリーストリームの基本単位であり、ＧＯＰ（Group of Picture）と呼ばれる。ＧＯＰには、そのＧＯＰの外のピクチャの参照が不要なクローズドＧＯＰと、参照を行うオープンＧＯＰがある。クローズドＧＯＰは、ストリーム中ではＩピクチャで始まり、次のＩピクチャの直前のＰピクチャで終わる。表示時刻順でこのＰピクチャと次のＩピクチャの間にあったＢピクチャは、次のＩピクチャのみ参照するように符号化されて、ストリーム中で次のＧＯＰのＩピクチャに続けて配置される。ＧＯＰの先頭には通常、ＧＯＰヘッダが設けられるが、必須ではない。ＧＯＰヘッダには、ＧＯＰ内の先頭ピクチャのタイムコードや、ＧＯＰがクローズドかオープンのどちらかを示すフラグ等が記述される。
実際には、ストリーム中にはＧＯＰのほか、映像の途中から復号を始められるようにするためのシーケンスヘッダが、ＧＯＰ境界等に任意の間隔で挿入されており、シーケンスヘッダには、ピクチャの縦と横のサイズ、クロマフォーマット、ピクチャレート、プロファイル、レベル、ビットレート等の各種パラメータが含まれている。
【００２４】
次に、本実施例のデコーダ１６−１の再送信動作の概要を、図１、図４、図５を用いて説明する。なお、先の説明では、ＭＰＥＧ方式のストリームデータは、Ｉピクチャ、ＰピクチャＢピクチャで構成されると説明したが、ここでは、説明の便宜上、ＩピクチャおよびＰピクチャのみで構成されるＧＯＰで説明する。本例のデコーダ１６−１は、ＧＯＰ単位でストリーム管理をし、レート制御を行うことで、デコーダ１６−２、１１３−３側で復号可能なクローズドＧＯＰを送信するようにしたものである。
【００２５】
図１は、デコーダ１６−１へのピクチャデータの流れ示す模式図である。図１において、最上段に図示されたアナログ映像１１−１、１１−２、…、１１−ｎは、映像源（アナログカメラ１２）が所定のフレームレートで生成するアナログ映像の各フレームのイメージである。その下には、上のフレームに対応して画像送信装置１ａが作成し配信する符号化映像データを図示しており、Ｉ／Ｐピクチャ１３−１、１３−２、・・・、１３−ｎ（Ｉ／Ｐピクチャ１３と総称する）である。画像送信装置１ａは、アナログ映像信号１１−１、１１−１６から、Ｉピクチャ１３−１、１３−１６をそれぞれ作成し、他のアナログ映像信号からは対応するＰピクチャをそれぞれ作成し、それがデコーダ１６−１に受信される。本例では、Ｉ／Ｐピクチャ１３が損失無く（一定レートで）デコーダ１６−１で受信され、デコーダ１６−１内部に設けられるストリームバッファ１４に格納されることを想定する。なお、本例の動作は、エレメンタリーストリームを伝送する際の下位レイヤ（プロコトル）には依存しないので、エレメンタリーストリームそのものが伝送されると考えても差し支えない。
【００２６】
ストリームバッファは、予め所定のメモリ領域を確保された要素１と要素２とからなる２面構成とし、要素選択と、要素内の格納位置選択を与えることで所望のデータの読み書きができる。一般に、一方の要素を書き込みに占有させ、他方の要素を読み出し専用にする制御方法もあるが、本例では、ＧＯＰの先頭を検出するたびに、書き込みを行う要素を交互に入れ替え、読み出しは任意の要素を指定して行えるようにする。書き込みに使用されていない要素には、現在受信中のＧＯＰの直前のＧＯＰが、完全な形で格納されている。なお、ＧＯＰサイズ（ＧＯＰに含まれる（最大）ピクチャ数）は、符号化側と復号化側の間で事前に決めておく。
【００２７】
図４は、ストリームバッファ１４への書き込み処理のフローチャートである。図４の処理は、受信プロセス（タスク）の一部であり、書き込みデータ（パケット等）を受け取るたびに或いはフレーム周期以下の所定周期で開始される。受信プロセスは、ＣＰＵの時分割共有により他のプロセスとともに実行される。
ステップ401では、受信したストリームデータに、シーケンスヘッダ、ＧＯＰ、ピクチャ等の各種スタートコードが含まれていないか探索する。
ステップ402では、格納しようとするストリームデータがＩピクチャか、Ｐピクチャかを判定し、Ｉピクチャの場合（ＧＯＰ先頭の場合）にはステップ403に進み、Ｐピクチャの場合にはステップ407に進む。
【００２８】
ステップ403では、格納位置情報をＩピクチャ位置（要素の先頭）に設定する。
ステップ404では、現在書き込みに使用中のストリームバッファ要素を判定し、現在使用中のストリームバッファ要素が要素１（図１参照）ならばステップ406に進み、要素２ならばステップ405に進む。
【００２９】
ステップ405では、格納先となるストリームバッファ要素を現在使用されていない要素１に切り替え、ステップ407に進む。
ステップ406では、格納先となるトリームバッファ要素を現在使用されていない要素２に切り替えステップ407に進む。
【００３０】
ステップ407では、ステップ405または406で切替えた現在のストリームバッファ要素、ストリームバッファ格納位置が示すストリームバッファの領域にストリームデータを格納する。
ステップ408では、ストリームバッファ格納位置を更新する。格納位置は指定形式は、要素の先頭（ＧＯＰ先頭）からのオフセットアドレスとしてもよく、ピクチャカウンタとピクチャ先頭からのオフセットアドレスの組合せでもよい。
【００３１】
図５は、ストリームバッファからの読み出し処理のフローチャートである。図４の処理は、中継送信（再配信）プロセスの一部であり、デコーダ１６−１がクライアント（デコーダ１６−１から配信を受けているデコーダであり、例えばデコーダ１６−２）からのストリームデータの送信要求を受信するたびに開始される。なお中継送信プロセスは、クライアント毎に起動され実行されているが、図４の処理は同一クライアントについて２重に開始されないように制御されることを前提とする。
まずステップ501では、画像受信装置１１３−１から受信した送信要求に含まれるＰピクチャ要求数や時刻情報を、所定の変数エリアに保存する。また、ストリームバッファの要素のうち、書込みに使用されている要素を読み出し対象として設定する。
ステップ502では、Ｐピクチャ要求数を判定し、読み出し対象の要素に格納されたストリームデータが、要求数を満たさない場合には、他方の要素（書込みに使用されていない要素）を読み出し対象として設定する。
【００３２】
ステップ503は、前回送信したＧＯＰのタイムコードを所定の変数エリアから読み出すとともに、読み出し対象要素のストリームバッファに格納されているＧＯＰのタイムコードを読み出して比較し、両者が同じでなければ（後者のタイムコードの方が時間的に後のものであれば）、ステップ504へ進む。両者が同じであれば、所定時間後に自身（図４の処理）を起動するタイマーを設定して、処理を一旦終了する。所定時間としては、Ｐピクチャ周期(約100ms)を用いても良く、読み出し対象要素のＰピクチャの（要求数に対する）不足数に応じて設定しても良い。
【００３３】
ステップ504では、読み出し対象として選択された要素のストリームバッファから、データを読み出して加工し、該要求Ｐピクチャ数分のＰピクチャを有する１個のＧＯＰを作成する。例えば、読み出し対象要素の先頭（Ｉピクチャ）に読出し位置（読出しポインタ）を設定し、順次バイトストリームとして読み出す。
ただし、図４の書込み処理の書込み位置が読出し位置に追いついたとき（これは、読み出し対象要素が、当該読み出し処理の開始後に書込み処理によって書込み対象要素に選択された場合に起こりうる）は、その時点でこのステップを終了する。
【００３４】
ステップ505では、作成したＧＯＰをデコーダ１６−２に送信する。送信の開始時に、ＧＯＰのタイムスコードを変数エリアに格納する。なお、ステップ504と505は同時進行させてもよく、或いは、ステップ504で作成したＧＯＰを送信バッファに完全に格納し終えてからステップ505に進んでもよい。
【００３５】
図２は、本実施例１のネットワーク映像配信システムの配信動作を説明する図である。図２において、図１と同じものには、同じ符号を付してある。図２の上半分は、図１と同じでありデコーダ１６−１で受信されるストリームデータ、下半分は、デコーダ１６−２で受信されるストリームデータを、共通の時間軸（横軸）でそれぞれ模式的に示したものである。
デコーダ１６−２は、任意のタイミングで送信要求１５をデコーダ１６−１に送信する。デコーダ１６−１は、ネットワーク４−２を介して送信要求１５を受信すると、自身はエンコーダではないのでそれを中継送信要求の意味に解釈し、その送信要求が示すＰピクチャ要求数（本例では１５）のＧＯＰ単位ストリームデータ１７（以後ＧＯＰ単位データと呼ぶ）が用意でき次第、デコーダ１６−２への中継送信を開始する。
デコーダ１６−２は、（送信要求１５の応答としての）ＧＯＰ単位データ１０３の受信開始を検知すると、その開始時刻を記録すると共に、必要に応じ再生バッファをクリアした後、ＧＯＰ単位ストリームデータ１０３の伸張（復号）を直ちに開始して、アナログ映像信号を順次出力する。
【００３６】
デコーダ１６−２は、Ｐピクチャ要求数分のＧＯＰ単位データ１７の受信を終えると、記録した開始時刻と現在時刻との差を算出し、その差が本来の１ＧＯＰ時間（ＧＯＰサイズに対応する）より長ければ次回の要求数を減らし、短ければ要求数を増やす。所定時間（例えば本来の２ＧＯＰ時間）内に要求数分のＧＯＰ単位データ１７の受信が終えられなかったときは、タイムアウトするとともに次回の要求数を最小値（例えば０。即ちＩピクチャのみ。）にする。その後、適宜、送信要求（図示せず）を送信する。なお、デコーダ１６−３においても同様であり、説明を省略する。或いはデコーダ１６−２が１６−３に再配信するように動作させても良い。
【００３７】
以上説明したように、本実施例１のデコーダ１６−１は、最新のＩピクチャ（例えば１３−１６）から要求のあった所定のＰピクチャの送信ピクチャ数に達するまでストリームデータを蓄積する。蓄積が達成した時点で、Ｉピクチャとこれに続く所定のピクチャ数のＰピクチャをＧＯＰ単位に加工して、画像受信装置（デコーダ１６−２）に送信することで、ネットワークの伝送速度に合わせたストリームデータ量を任意に指定することができ、画像伝送部と画像受信部のMPEG−４ストリーム遅延時間を最小限にでき、ＧＯＰ単位でＰピクチャの連続性の確保されたストリームデータを中継送信することができる。
【実施例２】
【００３８】
本実施例２は、ネットワークデコーダ装置が再送信する際のレート制御として、特許文献４に記載の方法を応用したものであり、送信要求を、ピクチャ毎に行うようにした点で先の実施例１と異なる。
図６は、本例のデコーダ１６−１に係るストリームバッファからの読出し処理のフローチャートであり、図５に代わるものである。図６の処理は、図５と同様、デコーダ１６−１が画像受信部（例えば、デコーダ１６−２、１１３−３）からのストリームデータの送信要求を受信するたびに開始される。本処理では、前回送信したピクチャが属したＧＯＰのタイムコードを変数エリアに格納して使用するので、再送信プロセスの起動時に、タイムコードを、それが取りうる最古の値などに初期化しておく。
ステップ601では、デコーダ１６−２等から受信した送信要求に含まれるＰピクチャ要求数や時刻情報を、所定の変数エリアに保存する。
ステップ602では、前回送信したピクチャが属したＧＯＰのタイムコード（前回タイムコード）を所定の変数エリアから読み出して、現在の書込み対象要素のＧＯＰのタイムコード（現在タイムコード）と比較し、前回タイムコードが現在タイムコードより古い場合、読出し対象要素を現在の書込み対象要素と同じに設定し、読出し位置をその要素の先頭に設定（初期化）する。
【００３９】
ステップ603では、読み出し対称要素の読出し位置から１ピクチャ分のストリームデータを読み出して送信する。読出し後には、読出し位置は読み出したピクチャの次のピクチャの先頭（もしあれば）を示すことになる。
なお、ステップ602における現在タイムコードとしては、単純に現在の書込み対象要素のＧＯＰのタイムコードを採用するのではなく、現在の書込み対象要素に少なくともＩピクチャが格納されている（書込み位置が２番目以降のピクチャを示している）ときにのみ採用し、それ以外のときは他方の要素のＧＯＰのタイムコードを採用するようにしてもよい。
以上説明したように、本実施例２のデコーダ１６−１は、最新のＩピクチャ１３（例えば映像取込５）から要求のあった所定のＰピクチャの送信ピクチャ数に達するまでストリームデータを蓄積する。蓄積が達成した時点で、Ｉピクチャとこれに続く所定のピクチャ数のＰピクチャをＧＯＰ単位に加工して、画像受信装置に送信することで、回線状況に合わせたストリームデータ量を任意に指定することができ、回線の効率を最大限に使用できるようにしたものである。
【００４０】
図７は、本実施例２のネットワーク映像配信システムの配信動作を説明する図である。なお、図２と同じものには、同じ符号が付されている。
デコーダ１６−２は、ネットワーク４−２を経由し、デコーダ１６−１にストリームデータの送信要求（図示せず）をする。デコーダ１６−１は、ストリームデータの要求があったデコーダ１６−２に、その時点で最新のＩピクチャであるＩピクチャ１３−１を伝送する。デコーダ１６−２は、Ｉピクチャ１３−１を受信したら即座にストリームデータの復号（伸張）を開始する。このＩピクチャ１３−１の受信に係る期間を、デコーダ１６−２の映像伸張１として図示してある。なおピクチャの受信完了から復号完了までの時間はフレーム時間に対して十分短いとみなして、受信期間と復号期間はほぼ同じとして扱う。なお、上述の「即座に復号」とは、受信中のピクチャの２つ前のピクチャを復号することは含まないが、１ピクチャ分のデータの受信完了を待って復号を開始する（つまり、１つ前のピクチャを復号する）ことまでは含む。
【００４１】
Ｉピクチャ１３−１全体の受信（或いは復号）が完了すると、デコーダ１６−２は、ネットワーク４を経由し、デコーダ１６−１に次のストリームデータの送信要求をする。デコーダ１６−１は、送信要求があったデコーダ１６−２に次のＰピクチャ１３−２を伝送する。デコーダ１６−２は、Ｐピクチャ１３−２を受信しながら即座にストリームデータの復号を開始する。以降、続くＰピクチャ１３−３、１３−４、…を同じ手順で要求し、受信し、復号する。以降、ストリームデータの要求ごとに同じ手順を繰り返す。
【００４２】
デコーダ１６−３も１６−２と同様に送信要求を行いストリームデータを受信するが、狭い伝送帯域幅（該当ピクチャ伝送時の実効的な伝送速度）により受信が遅延するため、入力映像に対する遅延時間が徐々に増大していく。図中でデコーダ１６−ｎと示したものでは、Ｉピクチャのみがかろうじて送信できている。
本例のデコーダでは、常時少なくとも１ＧＯＰ分のストリームデータが１ＧＯＰ時間以上バッファされているため、デコーダ１６−３のように少なくとも１ＧＯＰ時間（最大で２ＧＯＰ時間）を使ってＩピクチャを送信することができる。
【００４３】
以上説明したように、本実施例２によれば、送信要求をピクチャ毎に行うようにしたので、ＧＯＰの途中で伝送帯域幅が大きく低下した場合でも、次のＧＯＰの（つまり最新の）Ｉピクチャが送信可能になった以降の送信要求に対して、Ｐピクチャの送信を打ち切ってその最新Ｉピクチャを送信することができる。
【実施例３】
【００４４】
本実施例３は、ネットワークデコーダ装置が再送信する際のレート制御として、特許文献４に記載の方法を用いたものであり、送信要求を、ピクチャ毎に行うようにした点で先の実施例１と異なる。
図１３は、本実施例３のデコーダ１８のブロック図である。図１３において、画像送信装置１等からＩＰパケット化された映像データが入力端子１３０に入力される。なお映像データの符号化方式としてMPEG-4 Part2 Visualを想定する。
【００４５】
Ｌ２−Ｌ３処理部１３１は、入力端子１３０からのＩＰパケットに対し、レイヤ２及びレイヤ３の受信処理をし、レイヤ３のペイロードを出力する。即ち、出力先に対し、Socket ＡＰＩと同様の機能を提供する。レイヤ３は、ＵＤＰ（User Datagram
Protocol）もしくはＴＣＰ（Transmission Control Protocol）である。
【００４６】
ＲＴＰ処理部１３４−１は、Ｌ２−Ｌ３処理部１３１から受け取ったデータグラムについてＲＦＣ３０１６等に規定されているＲＴＰ（Real-time Transport Protocol）処理やＲＴＣＰ処理をし、ＲＴＰパケットのペイロードを連結して得られるMPEG-4 Visualのビットストリームを復号化処理部１３２及びＩ−ＶＯＰ周期バッファ１３３へ出力する。またＲＴＰ処理部１３４−１は、Ｉ−ＶＯＰ周期バッファ１３３にペイロードを出力する都度、ＲＴＰパケットヘッダの情報（後述）をＩ−ＶＯＰ周期バッファ１３３へ通知する。また、ＲＴＰヘッダ中のＭ（Marker）ビットを検査し、Ｍビットが１のパケットを検出したときに、該パケット或いはその次のシーケンスナンバーのパケットのペイロード出力時に、タイムコード（後述）をＩ−ＶＯＰ周期バッファ１３３へ通知する。
ＲＦＣ３０１６は、MPEG-4 Visualのビットストリーム（符号化データ）をMPEG-2システム等を用いずにネットワーク上で伝送するのに適したＲＴＰペイロードフォーマットを規定している。１ピクチャ（フレーム）を構成するＶＯＰ（Video Object Plane）を１乃至複数のＲＴＰパケットで伝送する場合、各ＲＴＰパケットのペイロード先頭には常にコンフィグレーション情報、ＶＯＰヘッダ、ＶＰ（Video packet）ヘッダのどれかを配置し、エラー耐性を高めている。
【００４７】
復号化処理部１３２は、必要最小限の受信バッファを備え、ＲＴＰ処理部１３４−１から受け取ったビットストリームを復号化し、外部の映像モニター１２４に出力する。
【００４８】
Ｉ−ＶＯＰ周期バッファ１３３は、少なくともＩ−ＶＯＰ（先に説明したＩピクチャに相当する。）から次のＩ−ＶＯＰの直前までの符号化データを蓄積可能な容量を有するバッファである。
【００４９】
ＲＴＰパケット処理部１３４−２〜１３４−４は、ＲＴＣＰにより取得した受信者側での受信品質に関する情報に基づいて制御される伝送レートで、Ｉ−ＶＯＰ周期バッファ１３３から読み出したビットストリームをＲＦＣ３０１６等に従いＲＴＰパケット化し、Ｌ２−Ｌ３処理部１３５へ出力する。
ＲＴＰパケット処理部１３４−１、１３４−２〜１３４−４は通常、プロセッサ（不図示）上で動作するソフトウェアにより実現され、受信ストリーム数及びクライアント数に対応する数だけそれぞれ起動される。Ｉ−ＶＯＰ周期バッファ１３３も受信ストリーム数だけ起動される。
【００５０】
Ｌ２−Ｌ３処理部１３５は、Ｌ２−Ｌ３処理部１３１と同等の機能を提供するものであり、Ｌ２−Ｌ３処理部１３１と一体に構成されても良い。
【００５１】
図８は、Ｉ−ＶＯＰ周期バッファ１３３の構成図である。Ｉ−ＶＯＰ周期バッファ１３３は、リングバッファ８１と、Ｉ−ＶＯＰタイムコードレジスタ８２と、ヘッダポインタテーブル８３とから構成される。
リングバッファ８１は、ＲＴＰパケット処理部１３４−１からのビットストリームを、書き込みポインタＷＰの示す位置から順次書き込み、読出しポインタＲＰの示す位置から順次読み出してＲＴＰパケット処理部１３４−２等に出力する。
リングバッファ８１は、１ＧＯＶ（Group of VOP)分のビットストリームを保持するのに十分な容量のＦＩＦＯ型のバッファ（リングバッファ）であり、ＷＰはＲＰより優先度が高く、ＲＰを追い越すことができる（ＲＰをＷＰの前に強制移動する）。
【００５２】
Ｉ−ＶＯＰタイムコードレジスタ８２は、最新ＧＯＶタイムコードと、読出済ＧＯＶタイムコードとを記憶する。
最新ＧＯＶタイムコードとは、リングバッファ８１にＩーＶＯＰ（図では、Ｉと表示）を書き込む都度、そのＩーＶＯＰの直前にあるＧＯＶヘッダ中のタイムコードが、ＲＴＰパケット処理部１３４−１により書き込まれるものである。
読出済ＧＯＶタイムコードとは、リングバッファ８１からＩーＶＯＰが読み出される都度、最新Ｉ−ＶＯＰタイムコードがコピーされて書き込まれるものである。
Ｉ−ＶＯＰの検出は、ＲＴＰパケット処理部１３４−１から通知されるＭビットに拠っても、或いはＧＯＶヘッダの先頭にある32bitの”group_vop_start_code”をビットストリーム中からサーチすることに拠っても良い。また、ＧＯＶヘッダ中のタイムコードの代わりにＲＴＰパケットヘッダ中のタイムスタンプを用いても良い。
【００５３】
ヘッダポインタテーブル８３は、ＲＴＰパケット処理部１３４−１がビットストリームをリングバッファ８１に書き込む際に、そのビットストリームを運んできたＲＴＰパケットのヘッダ情報（タイムスタンプやＭビット）と、ペイロード長と、リングバッファ８１上でのそのペイロード（ビットストリーム）の先頭位置を示すポインタとが対応付けられて記録される。ＷＰがＲＰを追い越しそうになったら、ＲＰを、ＲＰが示しているＲＴＰペイロードの次のペイロードの先頭位置に移動する。
【００５４】
次に、図１３と図８を参照して本例のデコーダ１８の動作を説明する。
各ＲＴＰパケット処理部１３４−２、１３４−３、１３４−４は、Ｌ２−Ｌ３処理部１３５からの伝送レートに応じたレディー信号（図１３では点線で示す信号）により、Ｉ−ＶＯＰ周期バッファ１３３から符号化データを読み出す。レディー信号とは、例えばＲＴＣＰのＲＲ（Receiver Report）である。ＴＣＰの場合、クライアント（画像受信装置やデコーダ等）からのACK(受信応答)を利用可能ではあるが、ＲＴＣＰの併用が望ましい（）。例えば、各ＲＴＰパケット処理部１３４−２等は定期的にＳＲをクライアントに送信し、クライアントから返信されるＲＲに含まれるパケット破棄率情報や最新ＳＲ受信時刻情報などを得る。この定期的な情報から、パケット破棄率がゼロとなるように（目標）送信レートを決定する。
【００５５】
具体的には、ＲＴＰパケット処理部１３４−２等は、ＲＴＰパケット送信時に、そのパケット長に送信レートを乗じて求まる時間でタイマーを設定する。そしてその時間経過後にタイマーイベント等により、次のステップ301〜304の処理を行なう。
【００５６】
まず、ステップ301として、読み出し条件の判断をする。読み出し条件の一例として、
例１：最新ＧＯＶタイムコード
＜＞ 読出しＧＯＶタイムコード
例２：ｄ秒 ＞（最新ＧＯＶタイムコード
− 読み出し対象ＶＯＰのタイムコード）
例３：ｄ秒 ＞（最新のＩ−ＶＯＰのタイムスタンプ
− 読み出し対象ＶＯＰのタイムスタンプ）
例４：ａ ＞（読出しポインタＲＰ
− 書込みポインタＷＰ）
等がある。なお、読み出し対象ＶＯＰとは読出しポインタＲＰが指す位置のＶＯＰのことであり、“＜＞”は左辺と右辺が等しくないことを意味する。ｄは、正の値であり、I-VOP周期やネットワーク伝送ジッタ（ＲＴＣＰのＲＲから得られる）に応じて適切に設定するものとする。なお、例２における、「読み出し対象ＶＯＰのタイムコード」は、ＶＯＰヘッダからは直接得られず、読出済ＧＯＶタイムコードと、ＶＯＰヘッダ内のmodulo_time_baseやvop_time_incrementとから計算する必要がある。その他の値は、ヘッダポインタテーブル８３等に格納されているものを用いる。例４はＷＰがＲＰに迫ってきていることを意味し、アドレスの差がａ未満になると真となる。
【００５７】
ステップ302として、上記読み出し条件が真ならば、読み出し対象ＶＯＰは古る過ぎると判断して、ＲＰを最新I-VOPに移動してリングバッファ８１からビットストリームを読み出し、偽ならば、ＲＰが示す通りに読み出す。読み出す量は、ヘッダポインタテーブル８３に格納されているペイロード長に従うが、次のＶＯＰかＶＰ（Video Packet）のスタートコードが検出されるまで読み出しても良い。
【００５８】
ステップ303として、読み出したビットストリームをペイロードとするＲＴＰパケットを作成する。その際、ＲＴＰパケットヘッダ中のタイムスタンプとしては、ヘッダポインタテーブル８３に格納されているタイムスタンプに適当なオフセットを加えたものを用いても良く、上述の読み出し対象ＶＯＰのタイムコードと同様の計算により、独自に作り直しても良い。
【００５９】
ステップ304として、作成したＲＴＰパケットをＬ２−Ｌ３処理部１３５に出力すると共に、次のパケット処理のため、出力したパケット長に送信レートを乗じて求まる時間でタイマーを設定する。
【００６０】
図８では、書き込みポインタＷＰでリングバッファ８１にＰ(n+1)を書き込み、読み出しポインタＲＰでＰ(３)を読み出し始める状態を示し、Ｉ−ＶＯＰタイムコードレジスタ８２には、Ｉ(０)のタイムコードが格納されている。
低レート伝送路に対しては、読み出し速度が書き込み速度より遅くなる場合がある。この場合の読み出し条件判断処理では、Ｉ−ＶＯＰタイムコードに格納されているＩ（ｎ）よりも時間の早い（タイムコードの小さい）Ｐ（３）を読み出すことになる。従って、その差分がｄ秒以上となるため、上述の読み出し条件が成立することになり、Ｉ（ｎ）に読み出しポインタＲＰを移動してＩ（ｎ）を読み出す動作となる。
【００６１】
即ち、この動作によりＰ（３）〜Ｐ（ｎ−１）の読み出しがスキップされ、Ｉ−ＶＯＰ周期バッファ１３３内部でＩ−ＶＯＰ直前のデータが破棄されたことになる。このように読み出し速度は、伝送レートに対応したものとなる。これにより伝送レート適応型パケット伝送が可能となる。
【００６２】
以上説明したように、本実施例３の各ＲＴＰパケット処理部１３４−２等は、それぞれのクライアント（画像受信装置やデコーダ等）間の伝送路の利用可能帯域（伝送速度）に従ったデータ量をＩ−ＶＯＰ周期バッファ１３３から読み出す。従って、必然的に低レート伝送路に対してはＩ−ＶＯＰ周期バッファ１３３内で画像データが破棄されることになる。このようにして自動的に伝送路の伝送速度にあわせて画像データが伝送される。
本例の伝送レート適応型パケット伝送方式は、ベストエフォートの伝送路（ネットワーク）に対して有効である。つまり、伝送レートの動的な変動に対しても自動的に適応した画像符号化データの伝送が可能となる。
【実施例４】
【００６３】
本実施例４は、映像データの符号化方式としてH.264を想定し、ＲＴＰペイロードフォーマットとしてＲＦＣ３９８４を用いた点などで先の実施例３と異なる。
H.264のエンコーダは概念的に、スライス単位で符号化データを出力するビデオ符号化レイヤ（ＶＣＬ）と、そのスライス出力をパケットネットワークでの伝送に適したＮＡＬユニットにパケット化するネットワーク抽象化レイヤとから構成される。スライスとは、１ピクチャ（フレーム）を１乃至複数に分割したものであり、１ピクチャ分のデータの集まりはＡＵ（アクセスユニット）と呼ばれる。
【００６４】
ＮＡＬユニットの先頭には、ＮＡＬユニットタイプオクテット（以後ＮＡＬヘッダと呼ぶ）が配置され、その直後にＮＡＬユニットのペイロードが続く。ＮＡＬヘッダは、そのＮＡＬユニットが壊れていることを示す１ビットの”forbidden_zero_bit”と、そのＮＡＬユニットの内容が参照ピクチャの完全性を保つのに必要か否かを示す２ビットの”nal_ref_idc”と、そのＮＡＬユニットのタイプを示す５ビットの”nal_unit_types”とからなる。
”nal_unit_types”の値は、ＮＡＬユニットの内容が、ＩＤＲピクチャ（他のピクチャに依存せずに復号可能なピクチャ。前述のＩピクチャに相当）のスライスであれば”５”になり、AU delimiter（アクセスユニットの境界を示す）であれば”９”になり、またＳＶＣ(Scalable
Video Coding)を用いたときには、それらに対応する値をとる。その他、シーケンスパラメータセット、ピクチャパラメータセット、サブセットシーケンスパラメータセット、End of sequence等のＮＡＬについても値が決められている。
H.264は、シンタックスの自由度が高いのが特徴であり、スライス（ピクチャ）の標本化／再生時刻（順序）とは異なるような、符号化順序、伝送時刻順序、復号順序が許容されている。また上述のようなＮＡＬユニット化より、従来のエレメンタリーストリーム中で使用されていたスタートコードが不要になっている。
【００６５】
本実施例４のデコーダ１５１の基本構成は、図１３に示した実施例３のデコーダ１８と同様であり、実施例３との相違点のみ説明する。
本例のＲＴＰ処理部４４−１（１３４−１に相当する）は、受信したＲＴＰパケットに対し、ＲＦＣ３９８４等に規定されているＲＴＰ処理等をして、ＲＴＰペイロードを出力する。この規定におけるＲＴＰペイロードフォーマットには、シングルＮＡＬユニットパケット、集合パケット、分割パケット等があるが、必ず、ペイロードの先頭はＮＡＬヘッダから始まるようになっている。
【００６６】
ＩＤＲ周期バッファ４３は、実施例３のＩ−ＶＯＰ周期バッファ１３３に代えて備えられるものであり、受信した最新のＩＤＲピクチャにアクセス可能なように、格納したＲＴＰペイロード（より好ましくはＮＡＬユニット）毎にその先頭位置や時刻等を管理している。１枚のＩＤＲピクチャを構成する最初のＮＡＬユニットは、AU delimiter ＮＡＬユニットの後に最初に出現したＩＤＲ−ＮＡＬ（”nal_unit_types”=5のＮＡＬユニット）として検出する。なお、AU delimiter ＮＡＬとＩＤＲ−ＮＡＬの間には、sequence
parameter set、picture parameter、SEI等のＮＡＬユニットが配置され、AU delimiter ＮＡＬの前にはEnd of sequence ＮＡＬが配置される場合があり、これらを利用して検出しても良い。１ＩＤＲピクチャ分のＩＤＲ−ＮＡＬが複数ある場合でも、それらは連続していることが通常である。
【００６７】
ＲＴＰパケット処理部４４−２〜４４−４は、実施例３のＲＴＰパケット処理部１３４−２〜１３４−４と同様の適応レート制御を行なう。そして、その送信レートでＮＡＬユニットを全て送りきれなくなったときに、”nal_ref_idc”が低いものから順次スキップを行なう。”nal_ref_idc”は”0”〜”3”の値を取るので、４段階の制御となる。ＲＦＣ３９８４には、”nal_ref_idc”として、非参照ピクチャのＮＡＬには”0”を、ＩＤＲ−ＮＡＬには”3”をセットすることが定められている。また、符号化側（画像送信装置）で、ＩＤＲピクチャのみを参照するスライス、（動きベクトルが大きいとして）Region of Interestフラグを設定したスライス、或いはイントラスライス等のＮＡＬに対し、”nal_ref_idc”に”2”を設定し、それ以外の参照ピクチャのＮＡＬに”1”を設定するようにしても良い。
或いは、もしＳＶＣを用いていれば、ＮＡＬ拡張ヘッダも参照して、重要度や他からの依存性の低いＮＡＬから送信をスキップする。拡張ヘッダには、空間、ＣＧＳ、ＭＧＳ、ＦＧＳ等のレイヤ構造においてどの階層に属するかを示す情報を含む。拡張ヘッダが無い場合、シンタックスを解釈して判別する。つまりＮＡＬペイロードの先頭には通常、スライスヘッダがあるのでそれを参照する。
【００６８】
４段の各段階間の遷移条件は、より低レートの段階への遷移としては、実施例３等のスキップ開始条件（例えば、最新のAU delimiter或いはＩＤＲ−ＮＡＬを受信してから所定時間経過したとき）と同じでよい。より高レートの段階への遷移としては、その逆（例えば、読出しポインタＲＰが書込みポインタＷＰに追いついたとき）とする。
送信レートが絞られていくと最終的に、ＶＣＬクラスのＮＡＬとしてはＩＤＲ−ＮＡＬの一部だけを送信するようになる。ただし、AU delimiter NALのような重要なｎｏｎ−ＶＣＬクラスのＮＡＬもスキップせず送信する。
本例では、ＮＡＬ（ＲＴＰパケット）のスキップにより、ＡＵの最後のＲＴＰパケットにＭビットを適切に設定できない可能性があるが、通常の伝送路上のパケットロス同様、Ｍビットだけに頼らない実装が一般的となっており、問題ない。
【実施例５】
【００６９】
本実施例５のデコーダは、ＯＮＶＩＦ（Open Network Video Interface Forum Core Specification Version 1.0
2008年11月）に準拠したネットワーク映像配信システムで使用されることを前提にした点などで先の実施例４と異なる。
ＯＮＶＩＦでは、サービス指向アーキテクチャが採用されており、ネットワーク上にある機器を発見したり、カメラ、画像送信装置（エンコーダ）、画像受信装置（デコーダ）の仕様（プロファイル）情報を交換したり、雲台を制御したりするための各種の通信は全てＷＳＤＬ（Web Service Description Language）で定義され、それらの機能はWebサービスとして提供される。ＷＳＤＬはＸＭＬの構文で記述され、ＳＯＡＰ（Simple
Object Access Protocol）のメッセージとして通信される。ＳＯＡＰのメッセージ（エンベロープ）は、更にＨＴＴＰを用いてそのBODY内に格納されて伝送される。
【００７０】
遠隔のWebサービスを発見する方法としては、非特許文献３のWS-Discoveryを用いるよう規定されている。WS-Discoveryでは、システムに参加する全機器が共通のマルチキャストアドレスに参加し、そのアドレスを通じてクライアントがサービスのProbeをし、サービス提供元がそれに応答して直接クライアントにProbe matchを返信することを基本としているが、Discovery Proxy（ＤＰ）が代わりに応答することもできる。Probeメッセージには、例えばカメラを検索する場合、カメラの設置場所や名前などがＬＤＡＰ（RFC2251等）の様式で記述される。
【００７１】
本例においては、マルチキャストアドレスを使用せずにWS-Discoveryを実現するため、システムの全ての画像送信装置（エンコーダ、ＩＰ力メラ等）のＵＲＩ（ＩＰアドレス）等を収集或いは保持するとともに、ブロードキャストされたSOAPメッセージ、或いはモニター可能なＬＡＮ上の全てのSOAPメッセージを受信し、必要に応じてＤＰとなってWS-Discovery(Remote Discovery)サービスを提供するＤＰサーバを、クライアントが存在する各ＬＡＮ（ブロードキャストドメイン）に配置する。
【００７２】
図３は、本実施例５のデコーダ３０の構成図である。デコーダ３０は、実施例４のデコーダ１５１の構成に加え更に、ＷＳＤＬの通信を行なうSOAP／HTTP処理部３１と、ＲＴＳＰ（Real Time Streaming Protocol）等のセッション管理を行なうセッション管理部３２と、主にSOAP／HTTP処理部３１を介してWebサービスを提供するWebサービス管理部３３と、復号化した映像をサイズ変換等をして再度符号化する符号化処理部３５を備えている。
【００７３】
まず、本例のSOAP／HTTP処理部３１、Webサービス管理部３３が行なうRemote DiscoveryサービスおよびMediaサービスを説明する。
本例のSOAP／HTTP処理部３１は、マルチキャストアドレスに限らず、ブロードキャストされたSOAPメッセージ、或いはLAN上のモニター可能な全てのSOAPメッセージを受信している。
もしクライアントからの映像要求である”GetStreamUriRequest”を受信すると、Webサービス管理部３３は、映像要求の対象（Media profileで特定される）が、現在デコーダ３０自身で受信しているものかどうか判断し、受信していなければその映像要求を無視し、受信していればデコーダ３０のホスト名を含むＵＲＩを含む応答”GetStreamUriResponse”を返す。ＵＲＩは、ホスト名以降のパス名として、対応するMedia profileを特定可能な文字列等が付加されて、動的に生成されうる。映像要求を無視しても、クライアントは、ＤＰサーバ等からの応答を受け取ってそのＵＲＩ（ＩＰ力メラ等のもの）を知ることができる。一方、有効な（エラーではない）応答を冗長に受け取った場合は、ＵＲＩをアドレス解決し、そのＩＰアドレスがクライアントの属するネットワークに近い方（或いはネットマスクが一致する方）を採用すればよい。
”GetStreamUriResponse”を受け取ったクライアントは、当該ＵＲＩ宛にＲＴＳＰのDESCRIBEメソッドを送信するが、デコーダ３０がそれを受信した場合、映像再配信要求と解釈して、セッションを初期化し、プレゼンテーションを開始する。つまりＲＴＰ処理部３４−２等（実施例４の４４−２等に相当する）を新たに起動し、要求対象に対応するＩＤＲ周期バッファからストリームを読み出して、要求元クライアントに配信する。
【００７４】
デコーダ３０は、自身で受信して復号化する必要がなくなった場合、全クライアントにANNOUNCEメソッドを送信した後（或いは一方的に）、映像再配信を終了することができる。クライアントは再度”GetStreamUriRequest”を行い、デコーダ３０はそれに応答しないのでＩＰカメラ等の真のＵＲＩを取得し、セッションを確立することができる。もし、クライアントがデコーダ３０のＵＲＩ宛にSETUPメソッド等を送信しても、デコーダ３０は、直前まで接続していたＩＰカメラ等のＵＲＩを含むREDIRECTメソッドを応答するので問題は無い。
【００７５】
上記の他、雲台を制御するためのPTZサービス、カメラのフォーカス等を制御するためのImagingサービス、その他のWebサービスがあるが、上記と同様である。即ち、デコーダ１５１は自身が接続中のエンコーダやＩＰ力メラ等のＵＲＩ宛のWebサービス要求等を受信した場合、ＤＰとして、或いは完全に要求先ＵＲＩのＩＰ力メラ等を装って、要求に応答する。応答に必要な情報をキャッシュしていない場合、或いは雲台制御コマンドのように要求に含まれる情報をＩＰ力メラ等に伝える必要がある場合、要求を当初のＵＲＩ宛に転送して真のＩＰ力メラ等から応答を得て、それを元の要求元に応答する。
もしクライアントが発したWebサービス要求が直接、宛先通りに真のエンコーダ等に届き、応答が両者から帰ってきた場合、クライアントは任意の一方（例えばネットマスクが一致する方）を採用すればよい。
【００７６】
次に、本例の符号化処理部３５等を利用した再配信を説明する。ＯＮＶＩＦでは、画像送信装置は、ＱＶＧＡサイズのＪＰＥＧを送信できなければならないと定めているが、そのような画像送信装置が送信可能な映像形式等は、Media Profileとして定義される。Media Profileの中には、”Video source
configuration”、”Video encoder
configuration”、”PTZ configuration”などが規定されている。
本例のデコーダ３０は、ＭＰＥＧ等の動画の形式で受信中の映像について、ＪＰＥＧで映像要求を受けたときに、処理負荷に余裕があれば、ＭＥＰＧを復号して得た映像をＪＰＥＧにトランスコードして、要求元に配信（プレゼンテーション）することもできるようにする。具体的な処理の手順は以下のようになる。
【００７７】
ステップ401として、デコーダ３０は、利用可能なMedia Profileの問い合わせを意味する”
GetProfilesRequest”を受信する。Webサービス管理部３３はそれを解釈し、Media Profileが示す映像源(Video source configuration)が、デコーダ３０が現在受信中のものと同じか否か判定し、同じでなければ、Media Profileを１つも含まない空の”GetProfilesResponse”を応答する。ステップ401において映像源が、同じであれば、符号化方式やピクチャサイズ等も同じか否かを判定する。
ステップ402として、ステップ401において映像源が同じと判定された場合、処理負荷の余裕度に応じて、１乃至複数のMedia Profileを含む”GetProfilesResponse”を応答する。即ち、余裕度があれば、現在受信中の映像の符号化方式やピクチャサイズ等と同じ”Video encoder
configuration”を規定するMedia Profileの他、符号化処理部３５で再符号化可能な他の映像形式を指定するMedia
Profileも含ませる。
ステップ403として、ステップ402の”GetProfilesResponse”を受信したクライアントから”GetStreamUriRequest”等の映像要求を受信した場合、その時点で処理負荷に余裕があれば、デコーダ３０のホスト名を含むＵＲＩを生成して応答”GetStreamUriResponse”を返すとともに、映像要求が指定するMedia Profileの示す符号化方式やピクチャサイズ等で符号化するよう、符号化処理部３５を初期化する。
ステップ404として、ステップ403の”GetStreamUriResponse” を受信したクライアントからＲＴＳＰの所定のメソッドを受信した場合、セッションを初期化し、プレゼンテーションを開始する。符号化処理部３５は、指定された符号化方式等に従い、必要に応じてフレーム間引き処理、インタレース／プログレッシブ変換処理、リサイズ処理（超解像処理によるサイズの拡大も含む）等を行なう。Media Profileとして複数のVideoSourceを指定することも可能であり、その場合、複数の映像を１画面に合成し（例えば４−ｕｐ）、１ストリームに符号化して再配信する。
【産業上の利用可能性】
【００７８】
本発明は、監視カメラシステム等に好適であるが、ビデオ会議システム、ストリーム配信サービス等で用いられる符復号化装置、セットトップボックス等にも利用できる。
【符号の説明】
【００７９】
１ａ，１ｂ 画像送信装置、 ２ ＩＰ力メラ、
３ 画像サーバ装置、 ４ ネットワーク、
５ パーソナルコンピュータ（ＰＣ）、６ 画像受信装置（従来）、
７ ＰＣ（操作専用）、 ８，８ａ ビデオモニタ、
９ 専用操作器、
１１−１〜１１−ｎ アナログ映像、 １２ アナログカメラ、
１３−１〜１３−ｎ Ｉ／Ｐピクチャ、１４ ストリームバッファ、
１６、１８、３０ ネットワークデコーダ装置（デコーダ）、
１７ ＧＯＰ単位ストリームデータ、
３１ ＳＯＡＰ／ＨＴＴＰ処理部、 ３２ セッション管理部、
３３ Ｗｅｂサービス管理部、 ３４，４４，１３４ ＲＴＰ処理部、
３５ 符号化処理部、 ４３ ＩＤＲ周期バッファ、
８１ リングバッファ、 ８２ Ｉ−ＶＯＰタイムコードレジスタ、
８３ ヘッダポインタテーブル、
１３１，１３５ Ｌ２−Ｌ３処理部、 １３２ 復号化処理部、
１３３ Ｉ−ＶＯＰ周期バッファ、 １３６ 出力端子。
【技術分野】
【０００１】
本発明は、ネットワークデコーダ装置に関し、特にネットワークを介して受信した符号化映像データを復号するとともに他の機器に再配信するネットワークデコーダ装置に関する。
【背景技術】
【０００２】
従来、監視カメラで撮影した映像を符号化し、ＩＰネットワークを介して伝送するＣＣＴＶ（Closed Circuit TeleVsion）システムが知られる。
【０００３】
図１１は、従来のＣＣＴＶシステムの模式図である。ＷＥＢサーバ機能を有する画像送信装置（画像伝送装置）１ａ、１ｂ、ＩＰ力メラ２、或いは画像サーバ装置３（以後、画像送信装置１等と呼ぶ）は、符号化（圧縮）画像デジタルデータ（以後、画像データと呼ぶ）を各種通信プ口トコルを用いてネットワーク４を経由で送信する。パーソナルコンピュータ（ＰＣ）５や画像受信装置６（これらをクライアントと総称する）は、自身宛の画像データを受信して復号化し、映像の表示或いはビデオモニタ８への映像信号の出力を行う。
【０００４】
画像受信装置６は、シリアル信号を、画像送信装置１ａ、１ｂやＩＰ力メラ２との間でネットワーク４を介して双方向通信する機能を有し、カメラ制御用のシリアル信号を、RS-485やRS-232Cケーブルで接続された専用操作器９から或いはネットワークで接続されたＰＣ７から入力されると、それをＩＰ力メラ２等に中継する。ＰＣ５も、同等の機能をソフトウェアにより実現する。
【０００５】
上述の他、映像データの中継（転送）機能を有する映像再生装置等が知られる（例えば、特許文献１及び２参照。）。また、映像データを中継或いは送信する際に、フレームの間引き（コマ落し）を行うストリームデータ配信システム等が知られる（例えば、特許文献３及び４、非特許文献１及び２参照。）。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】国際公開第０５／０５０９３１号パンフレット
【特許文献２】特開２００７−２０１９９５号公報
【特許文献３】特開２００７−１９３６９０号公報
【特許文献４】特許第４２５５６８５号公報
【非特許文献】
【０００７】
【非特許文献１】福永茂，外３名，"LANにおける分散マルチポイント画像伝送方式の検討"，1993年画像符号化シンポジウム(PCSJ93)第8回シンポジウム資料，社団法人 電子情報通信学会，1993年10月，p.83-84
【非特許文献２】笠井裕之、富永英義，"マルチプルトランスコーダ・ストリームスイッチングに基づくスケーラブルゲートウェイ方式"，電子情報通信学会論文誌. B，平成15年10月1日，J86-B，No.10，p.2229-2244
【非特許文献３】John Beatty，外１２名， “Web Services DynamicDiscovery (WS-Discovery)”，[online]，2005年4月，インターネット＜ＵＲＬ：http://specs.xmlsoap.org/ws/2005/04/discovery/ws-discovery.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【０００８】
図１１において、画像受信装置６は新たに増設されたものとし、ＰＣ５で表示している映像と同じ映像を表示させる場合を考える。このとき、画像送信装置１ａ等は、ＰＣ５と画像受信装置６のそれぞれに宛てて画像データを個別に送信するので、ネットワーク４で伝送される映像データが２倍に膨れ上がってＰＣ５または画像受信装置６が利用できる帯域幅が圧迫され、映像受信に支障をきたす場合がある。これは画像送信装置１が最大配信の能力に対しベストエフォートにて処理を行っているからであり、各クライアントに同じ条件の各画像データを配信できなくなる。
或いは、画像送信装置１ａ等の配信能力の不足によりフルフレームの映像を送ることができない場合がある。画像送信装置１ａ等において、接続クライアント数に応じて配信のための処理能力（処理時間、バッファメモリ）が分配されるが、接続数が多くなると１クライアント当たりの処理能力が十分でなくなるためである。
【０００９】
また、画像受信装置６にネットワーク４経由でアクセスしているＰＣ７は、専ら制御のためのものであり、画像送信装置１等からの映像を確認することはできない。そのため、ＰＣ７から力メラ制御する際には、ビデオモニタ８の表示映像を確認しながらＰＣ７から力メラ制御を行うこととなり、操作性が悪いという問題があった。
【課題を解決するための手段】
【００１０】
本発明のネットワークデコーダ装置（画像受信装置）は、ネットワークを利用した画像送信装置もしくはＩＰ力メラ、画像サーバ装置などからネットワークを経由して各画像データ（符号化画像デジタルデータ）を受信し、受信した画像データに復号化画像処理を行いＮＴＳＣ信号もしくはデジタル映像信号に変換出力する。それと共に、当該ネットワークデコーダ装置に対して画像要求をした他のクラアイアントへ、画像送信装置等から受信した画像データを再配信する。これにより、画像送信装置等とネットワークデコーダ装置間の伝送路に必要とされるビットレートを抑える事ができる。
また、ＷＥＢサーバ機能を有する雲台付力メラ画像送信装置もしくはＩＰ力メラ、画像サーバ装置への力メラ制御要求を、画像受信装置に直接接続された専用操作器のみならずネットワーク経由でアクセスしている各クライアントから行なえるよう、ネットワークデコーダ装置は制御要求を中継する。これにより、力メラ制御要求の宛先を映像要求のそれと同じにでき、制御を簡略化する事ができる。
また、画像送信装置からの実効受信レートと、各クライアントへの実効送信レートとは必ずしも一致しないため、受信した符号化映像データを少なくともＩピクチャ周期分格納するバッファと、符号化映像データの再配信要求を受信したときに、前記バッファから符号化映像データを順次読み出して、該再配信要求の要求元へ送信する再配信手段と、を備えて、該再送信手段が、バッファに格納された最新Ｉピクチャより古いデータを符号化映像データの送信をスキップする。
【発明の効果】
【００１１】
本発明によれば、ネットワークデコーダが受信した映像データを再配信するようにしたので、カメラ制御を行うクライアントＰＣの画面に映像を表示させ、力メラ制御の操作性を向上させることができる。また、その再配信機能により、ネットワークの負荷を過剰に増加させることなく映像を表示可能なクライアントＰＣの数を多くすることができ、システムの構築が容易になる。
【図面の簡単な説明】
【００１２】
【図１】デコーダ１６−１へのピクチャデータの流れ示す模式図（実施例１）
【図２】ネットワーク映像配信システムの配信動作を説明する図（実施例１）
【図３】デコーダ３０のブロック図（実施例５）
【図４】ストリームバッファへの書き込み処理のフローチャート（実施例１）
【図５】ストリームバッファからの読出し処理のフローチャート（実施例１）
【図６】ストリームバッファからの読出し処理のフローチャート（実施例２）
【図７】ネットワーク映像配信システムの配信動作を説明する図（実施例２）
【図８】Ｉ−ＶＯＰ周期バッファ１３３の構成図（実施例３）
【図９】Ｐピクチャのスキップを説明する図（実施例２乃至６）
【図１０】ネットワーク映像配信システムの模式図（実施例１）
【図１１】従来のＣＣＴＶシステムの模式図
【図１２】ネットワーク映像配信システムの模式図（本発明）
【図１３】デコーダ１８のブロック図（実施例３）
【発明を実施するための形態】
【００１３】
以下、本発明のネットワークデコーダ装置の一例を用いたネットワーク映像配信システムについて、図面を参照して説明する。
なお、本システムは、ネットワークデコーダ装置（画像受信装置）において、符号化映像データを受信して復号しＮＴＳＣ信号もしくはデジタル映像信号出力によりモニター画面に映像表示させる通常の機能に加え、力メラ制御を行うＰＣの画面上にも同じ映像を表示させ、該映像を確認しながら力メラ制御を行えるようにすることを意図し、下記の性能を満足することを目標にしている。
(1) 画像送信装置に対する配信負荷を増加させないこと。
(2) 画像送信装置と画像受信装置、クライアントＰＣ間のネットワーク伝送路の負荷の増加を最小限にすること。
(3) 画像送信装置と力メラ制御用の通信を行うときは、画像受信装置を経由させる事で制御の複雑さを緩和させる。
【００１４】
図１２は、ネットワーク映像配信システムの模式図である。図１１に示した従来の構成と同一の箇所には、同一の符号を付してある。
ネットワークデコーダ装置１６（以後、デコーダと呼ぶ）は、予め設定された通信プ口トコルを用いて、画像送信装置１等から目的の各画像データをネットワーク４を経由して受信する。その際、画像送信装置１等から送信されネットワーク４を伝送する画像データは、１クライアント分のトラフイック量であり、設計上の品質で支障なく伝送できる。ネットワーク４は、遠地に設置される画像送信装置等を多数接続するものであるため、ＳＯＮＥＴ（Synchronous Optical NETwork）のような高速なものから、５６Ｋｂｐｓのモデム回線まで、各種の物理層が使用されうる。
【００１５】
デコーダ１６は、受信した各画像データを復号化し、ＮＴＳＣ信号もしくはＨＤＭＩ等のデジタル映像信号に変換してビデオモニタ８ａに送信すると共に、受信した各画像データのストリームをバッファに一時蓄積し、デコーダ１６に対して映像要求をしたＰＣ５や画像受信装置６へ再送信（再配信）する。デコーダ１６とＰＣ５等とは、ネットワーク上で近距離（例えばＬＡＮ内）であるか、十分な帯域の伝送路で接続されていることを想定しており、図１２では、便宜的にネットワーク４を介せずに途中から分岐するように図示してある。
【００１６】
この再送信の通信プロコトルは、画像送信装置１等がＰＣ５に送信するときに利用可能なものと同じであり、ＨＴＴＰ、ＲＴＰ、マルチキャスト（ＲＴＰ）等から選択することができる。つまり、デコーダ１６は、従来の画像受信装置６からはあたかも画像送信装置１等のように認識される。
またトランスポート層以上の上位層において、例えば、バッファとして最新の完全な１ＧＯＰ（Group of Picture）分のデータの保存に必要な容量を備え、フレーム間引きにより適応的な送信レート制御を行うようにする。最新のＧＯＰの先頭を受信すると、継続中の直前のＧＯＰの再送信は、直ちに或いはフレームかスライスの境界で中止され、該最新のＧＯＰの再送信を開始する。これにより、モデム等を使用した低品質の回線を用いた場合でも、最低限の復号可能な（フレーム内符号化された）１ピクチャ分の映像データを再配信することができる。
【００１７】
ところで、デコーダ１６の再送信機能を使用することにより、再送信するクライアント数、通信プ口トコル、画像送信装置の符号化ビットレート量によっては、本来の復号化処理がリアルタイムに行えずこま落ちすることが懸念される。そのため、各クライアントからの要求による再送信のプライオリティを、復号化処理のプライオリティより相対的に下げるなどし、復号化処理に支障が発生しない様にする。または、画像受信装置と各クライアントが同じブロードキャストドメイン内にあるか、再送信を行う経路上のルータやＬ３スイッチ等がマルチキャストに対応している場合は、プ口トコルとしてマルチキャストを選択することもできる。
【００１８】
更には、デコーダ１６のクライアント機能（画像を要求し受信する機能）を複数同時接続可能にすることで、同時に複数のサーバ機能（要求に応じ画像を送信する機能）を有する画像送信装置１等から符号化画像圧縮データを受信し、各符号化画像圧縮データの復号化およびリサイズにより４画面合成したＮＴＳＣ信号もしくはデジタル映像信号を出力すると共に、クライアントから再配信要求によりクライアントＰＣ画面上でもその４画面合成映像を表示できるようにしてもよい。
【実施例１】
【００１９】
図１０は、実施例１に係るネットワーク映像配信システムの模式図である。本実施例１は、ネットワークデコーダ装置が再送信する際のレート制御として、特許文献４に記載の方法を用いたものである。図１０のシステムは、一つの画像送信装置１ａからの映像データをネットワークデコーダ装置（デコーダ）１６−１が中継することで、他の離れた場所のビデオモニタ８ｂおよび８ｃにおいても映像の閲覧を可能にしたものである。
【００２０】
アナログカメラ１２は、所定のフレームレート（例えば３０fps）で撮影した監視映像の信号（ＮＴＳＣ信号）を、画像送信装置１ａへ出力する。
画像送信装置１ａは、入力された映像信号を目標ビットレートになるように圧縮符号化し、符号化映像データ（ストリームデータ）を所定のプロトコルに従ってネットワークインタフェースから送信する。
デコーダ１６−１は、画像送信装置１ａから対応するプロトコルで受信した符号化映像データを復号化しアナログ映像信号として出力する（図示せず）とともに、受信した符号化映像データをバッファに格納し、所定のプロトコルに従ってネットワークインタフェースから送信する。
デコーダ１６−２、１１３−３は、デコーダ１６−１から対応するプロトコルで受信した符号化映像データを復号化しアナログ映像信号として出力する。
【００２１】
ネットワーク４−１は、画像送信装置１ａとデコーダ１６−１とを接続する任意の伝送路であり、本例では最大で３８４kbpsの通信速度を有する第３世代携帯電話網（パケット通信網）を想定する。
ネットワーク４−２は、デコーダ１６−１とデコーダ１６−２とを接続する任意の伝送路であり、５１２kbps程度の実効通信速度を有するＡＤＳＬ回線を想定する。
ネットワーク４−３は、デコーダ１６−２とデコーダ１６−３とを接続する任意の伝送路であり、２Mbps程度の実効通信速度を有するＬＡＮ(Local Area Network) を想定する。
ネットワーク４−１〜３はいずれもＩＰパケットを伝送することができる。なお、図１０ではデコーダ１６−１等が２つのネットワークに直接接続するかのように図示してあるが、ルータ機能の内蔵を意図したものではなく、デコーダ１６等は、物理インタフェースとして、Ethernet（商標）等のポートを１個備える。
【００２２】
ここで、ＭＰＥＧ方式の画像圧縮技術における基本的な事項を説明する。MPEG-2 Video（ISO/IEC 13818-2）やMPEG-4 Part2 Visual（ISO/IEC 14496-2）のエレメンタリーストリームにおける符号化画像本体は、大よそ、Intra Picture（以下、Ｉピクチャと称する）、Predictive
Picture（以下、Ｐピクチャと称する）およびBiderectionally Predictive
Picture（以下、Ｂピクチャと称する）の３種類に分類でき、ピクチャ種類毎に異なる符号化モードで圧縮されている。
Ｉピクチャとは、アナログ映像の１フレーム分全ての画像データをそのフレーム内で符号化変換されたデータである（簡単のため、インタレース走査は考えない）。従って、デコーダ１６−２等では、このＩピクチャを受信した場合、他のピクチャを参照することなくこのＩピクチャだけで１フレーム分の画像を再生することができる。
Ｐピクチャとは、符号化済みの（時間的に前の）ＩピクチャまたはＰピクチャ（以下Ｉ／Ｐピクチャと呼ぶ）から一方向のフレーム間予測を行い、予測差分のデータのみ符号化したものである。従って、デコーダ１６−２等では、受信したＰピクチャだけでは画像を再生することができず、予測時に参照したＩ／Ｐピクチャがなければ画像を再生できない（図９参照）。更に、途中のＰピクチャがなければ、誤った画像、例えば、プロック歪等が発生した画像となる。
Ｂピクチャとは、２つの符号化済みＩ／Ｐピクチャ（通常は、時間的に前のピクチャと、後のピクチャ）から２方向のフレーム間予測を行い予測差分データのみ符号化したものである。このＢピクチャは、Ｐピクチャと同様にＢピクチャだけでは元の画像を再生できない。ＰピクチャおよびＢピクチャは、前後のピクチャとの時間軸方向の冗長度を削減しているため、圧縮後の符号量を少なくできるが、それだけでは元の画像を再生できない。
【００２３】
一般的なＭＰＥＧ−２の各ピクチャの組合せの一例を、表示時刻順に示すと以下のようになる。
（Ｉ）（Ｂ）（Ｂ）（Ｐ）（Ｂ）（Ｂ）（Ｐ）（Ｂ）（Ｂ）（Ｐ）（Ｂ）（Ｂ）（Ｐ）（Ｂ）（Ｂ）（Ｉ）（Ｂ）（Ｂ）（Ｐ）・・・・・このようにＩピクチャは、１５ピクチャに１回存在し、これが繰り返される構成が一般的である。なお、ストリーム中でのデータ順はこれとは異なり、Ｂピクチャの符復号に必要なＰピクチャが、それらＢピクチャより前に符号化されトリーム中に配置される。
この１個のＩピクチャを含む複数ピクチャからなる時間的周期構造は、ビデオエレメンタリーストリームの基本単位であり、ＧＯＰ（Group of Picture）と呼ばれる。ＧＯＰには、そのＧＯＰの外のピクチャの参照が不要なクローズドＧＯＰと、参照を行うオープンＧＯＰがある。クローズドＧＯＰは、ストリーム中ではＩピクチャで始まり、次のＩピクチャの直前のＰピクチャで終わる。表示時刻順でこのＰピクチャと次のＩピクチャの間にあったＢピクチャは、次のＩピクチャのみ参照するように符号化されて、ストリーム中で次のＧＯＰのＩピクチャに続けて配置される。ＧＯＰの先頭には通常、ＧＯＰヘッダが設けられるが、必須ではない。ＧＯＰヘッダには、ＧＯＰ内の先頭ピクチャのタイムコードや、ＧＯＰがクローズドかオープンのどちらかを示すフラグ等が記述される。
実際には、ストリーム中にはＧＯＰのほか、映像の途中から復号を始められるようにするためのシーケンスヘッダが、ＧＯＰ境界等に任意の間隔で挿入されており、シーケンスヘッダには、ピクチャの縦と横のサイズ、クロマフォーマット、ピクチャレート、プロファイル、レベル、ビットレート等の各種パラメータが含まれている。
【００２４】
次に、本実施例のデコーダ１６−１の再送信動作の概要を、図１、図４、図５を用いて説明する。なお、先の説明では、ＭＰＥＧ方式のストリームデータは、Ｉピクチャ、ＰピクチャＢピクチャで構成されると説明したが、ここでは、説明の便宜上、ＩピクチャおよびＰピクチャのみで構成されるＧＯＰで説明する。本例のデコーダ１６−１は、ＧＯＰ単位でストリーム管理をし、レート制御を行うことで、デコーダ１６−２、１１３−３側で復号可能なクローズドＧＯＰを送信するようにしたものである。
【００２５】
図１は、デコーダ１６−１へのピクチャデータの流れ示す模式図である。図１において、最上段に図示されたアナログ映像１１−１、１１−２、…、１１−ｎは、映像源（アナログカメラ１２）が所定のフレームレートで生成するアナログ映像の各フレームのイメージである。その下には、上のフレームに対応して画像送信装置１ａが作成し配信する符号化映像データを図示しており、Ｉ／Ｐピクチャ１３−１、１３−２、・・・、１３−ｎ（Ｉ／Ｐピクチャ１３と総称する）である。画像送信装置１ａは、アナログ映像信号１１−１、１１−１６から、Ｉピクチャ１３−１、１３−１６をそれぞれ作成し、他のアナログ映像信号からは対応するＰピクチャをそれぞれ作成し、それがデコーダ１６−１に受信される。本例では、Ｉ／Ｐピクチャ１３が損失無く（一定レートで）デコーダ１６−１で受信され、デコーダ１６−１内部に設けられるストリームバッファ１４に格納されることを想定する。なお、本例の動作は、エレメンタリーストリームを伝送する際の下位レイヤ（プロコトル）には依存しないので、エレメンタリーストリームそのものが伝送されると考えても差し支えない。
【００２６】
ストリームバッファは、予め所定のメモリ領域を確保された要素１と要素２とからなる２面構成とし、要素選択と、要素内の格納位置選択を与えることで所望のデータの読み書きができる。一般に、一方の要素を書き込みに占有させ、他方の要素を読み出し専用にする制御方法もあるが、本例では、ＧＯＰの先頭を検出するたびに、書き込みを行う要素を交互に入れ替え、読み出しは任意の要素を指定して行えるようにする。書き込みに使用されていない要素には、現在受信中のＧＯＰの直前のＧＯＰが、完全な形で格納されている。なお、ＧＯＰサイズ（ＧＯＰに含まれる（最大）ピクチャ数）は、符号化側と復号化側の間で事前に決めておく。
【００２７】
図４は、ストリームバッファ１４への書き込み処理のフローチャートである。図４の処理は、受信プロセス（タスク）の一部であり、書き込みデータ（パケット等）を受け取るたびに或いはフレーム周期以下の所定周期で開始される。受信プロセスは、ＣＰＵの時分割共有により他のプロセスとともに実行される。
ステップ401では、受信したストリームデータに、シーケンスヘッダ、ＧＯＰ、ピクチャ等の各種スタートコードが含まれていないか探索する。
ステップ402では、格納しようとするストリームデータがＩピクチャか、Ｐピクチャかを判定し、Ｉピクチャの場合（ＧＯＰ先頭の場合）にはステップ403に進み、Ｐピクチャの場合にはステップ407に進む。
【００２８】
ステップ403では、格納位置情報をＩピクチャ位置（要素の先頭）に設定する。
ステップ404では、現在書き込みに使用中のストリームバッファ要素を判定し、現在使用中のストリームバッファ要素が要素１（図１参照）ならばステップ406に進み、要素２ならばステップ405に進む。
【００２９】
ステップ405では、格納先となるストリームバッファ要素を現在使用されていない要素１に切り替え、ステップ407に進む。
ステップ406では、格納先となるトリームバッファ要素を現在使用されていない要素２に切り替えステップ407に進む。
【００３０】
ステップ407では、ステップ405または406で切替えた現在のストリームバッファ要素、ストリームバッファ格納位置が示すストリームバッファの領域にストリームデータを格納する。
ステップ408では、ストリームバッファ格納位置を更新する。格納位置は指定形式は、要素の先頭（ＧＯＰ先頭）からのオフセットアドレスとしてもよく、ピクチャカウンタとピクチャ先頭からのオフセットアドレスの組合せでもよい。
【００３１】
図５は、ストリームバッファからの読み出し処理のフローチャートである。図４の処理は、中継送信（再配信）プロセスの一部であり、デコーダ１６−１がクライアント（デコーダ１６−１から配信を受けているデコーダであり、例えばデコーダ１６−２）からのストリームデータの送信要求を受信するたびに開始される。なお中継送信プロセスは、クライアント毎に起動され実行されているが、図４の処理は同一クライアントについて２重に開始されないように制御されることを前提とする。
まずステップ501では、画像受信装置１１３−１から受信した送信要求に含まれるＰピクチャ要求数や時刻情報を、所定の変数エリアに保存する。また、ストリームバッファの要素のうち、書込みに使用されている要素を読み出し対象として設定する。
ステップ502では、Ｐピクチャ要求数を判定し、読み出し対象の要素に格納されたストリームデータが、要求数を満たさない場合には、他方の要素（書込みに使用されていない要素）を読み出し対象として設定する。
【００３２】
ステップ503は、前回送信したＧＯＰのタイムコードを所定の変数エリアから読み出すとともに、読み出し対象要素のストリームバッファに格納されているＧＯＰのタイムコードを読み出して比較し、両者が同じでなければ（後者のタイムコードの方が時間的に後のものであれば）、ステップ504へ進む。両者が同じであれば、所定時間後に自身（図４の処理）を起動するタイマーを設定して、処理を一旦終了する。所定時間としては、Ｐピクチャ周期(約100ms)を用いても良く、読み出し対象要素のＰピクチャの（要求数に対する）不足数に応じて設定しても良い。
【００３３】
ステップ504では、読み出し対象として選択された要素のストリームバッファから、データを読み出して加工し、該要求Ｐピクチャ数分のＰピクチャを有する１個のＧＯＰを作成する。例えば、読み出し対象要素の先頭（Ｉピクチャ）に読出し位置（読出しポインタ）を設定し、順次バイトストリームとして読み出す。
ただし、図４の書込み処理の書込み位置が読出し位置に追いついたとき（これは、読み出し対象要素が、当該読み出し処理の開始後に書込み処理によって書込み対象要素に選択された場合に起こりうる）は、その時点でこのステップを終了する。
【００３４】
ステップ505では、作成したＧＯＰをデコーダ１６−２に送信する。送信の開始時に、ＧＯＰのタイムスコードを変数エリアに格納する。なお、ステップ504と505は同時進行させてもよく、或いは、ステップ504で作成したＧＯＰを送信バッファに完全に格納し終えてからステップ505に進んでもよい。
【００３５】
図２は、本実施例１のネットワーク映像配信システムの配信動作を説明する図である。図２において、図１と同じものには、同じ符号を付してある。図２の上半分は、図１と同じでありデコーダ１６−１で受信されるストリームデータ、下半分は、デコーダ１６−２で受信されるストリームデータを、共通の時間軸（横軸）でそれぞれ模式的に示したものである。
デコーダ１６−２は、任意のタイミングで送信要求１５をデコーダ１６−１に送信する。デコーダ１６−１は、ネットワーク４−２を介して送信要求１５を受信すると、自身はエンコーダではないのでそれを中継送信要求の意味に解釈し、その送信要求が示すＰピクチャ要求数（本例では１５）のＧＯＰ単位ストリームデータ１７（以後ＧＯＰ単位データと呼ぶ）が用意でき次第、デコーダ１６−２への中継送信を開始する。
デコーダ１６−２は、（送信要求１５の応答としての）ＧＯＰ単位データ１０３の受信開始を検知すると、その開始時刻を記録すると共に、必要に応じ再生バッファをクリアした後、ＧＯＰ単位ストリームデータ１０３の伸張（復号）を直ちに開始して、アナログ映像信号を順次出力する。
【００３６】
デコーダ１６−２は、Ｐピクチャ要求数分のＧＯＰ単位データ１７の受信を終えると、記録した開始時刻と現在時刻との差を算出し、その差が本来の１ＧＯＰ時間（ＧＯＰサイズに対応する）より長ければ次回の要求数を減らし、短ければ要求数を増やす。所定時間（例えば本来の２ＧＯＰ時間）内に要求数分のＧＯＰ単位データ１７の受信が終えられなかったときは、タイムアウトするとともに次回の要求数を最小値（例えば０。即ちＩピクチャのみ。）にする。その後、適宜、送信要求（図示せず）を送信する。なお、デコーダ１６−３においても同様であり、説明を省略する。或いはデコーダ１６−２が１６−３に再配信するように動作させても良い。
【００３７】
以上説明したように、本実施例１のデコーダ１６−１は、最新のＩピクチャ（例えば１３−１６）から要求のあった所定のＰピクチャの送信ピクチャ数に達するまでストリームデータを蓄積する。蓄積が達成した時点で、Ｉピクチャとこれに続く所定のピクチャ数のＰピクチャをＧＯＰ単位に加工して、画像受信装置（デコーダ１６−２）に送信することで、ネットワークの伝送速度に合わせたストリームデータ量を任意に指定することができ、画像伝送部と画像受信部のMPEG−４ストリーム遅延時間を最小限にでき、ＧＯＰ単位でＰピクチャの連続性の確保されたストリームデータを中継送信することができる。
【実施例２】
【００３８】
本実施例２は、ネットワークデコーダ装置が再送信する際のレート制御として、特許文献４に記載の方法を応用したものであり、送信要求を、ピクチャ毎に行うようにした点で先の実施例１と異なる。
図６は、本例のデコーダ１６−１に係るストリームバッファからの読出し処理のフローチャートであり、図５に代わるものである。図６の処理は、図５と同様、デコーダ１６−１が画像受信部（例えば、デコーダ１６−２、１１３−３）からのストリームデータの送信要求を受信するたびに開始される。本処理では、前回送信したピクチャが属したＧＯＰのタイムコードを変数エリアに格納して使用するので、再送信プロセスの起動時に、タイムコードを、それが取りうる最古の値などに初期化しておく。
ステップ601では、デコーダ１６−２等から受信した送信要求に含まれるＰピクチャ要求数や時刻情報を、所定の変数エリアに保存する。
ステップ602では、前回送信したピクチャが属したＧＯＰのタイムコード（前回タイムコード）を所定の変数エリアから読み出して、現在の書込み対象要素のＧＯＰのタイムコード（現在タイムコード）と比較し、前回タイムコードが現在タイムコードより古い場合、読出し対象要素を現在の書込み対象要素と同じに設定し、読出し位置をその要素の先頭に設定（初期化）する。
【００３９】
ステップ603では、読み出し対称要素の読出し位置から１ピクチャ分のストリームデータを読み出して送信する。読出し後には、読出し位置は読み出したピクチャの次のピクチャの先頭（もしあれば）を示すことになる。
なお、ステップ602における現在タイムコードとしては、単純に現在の書込み対象要素のＧＯＰのタイムコードを採用するのではなく、現在の書込み対象要素に少なくともＩピクチャが格納されている（書込み位置が２番目以降のピクチャを示している）ときにのみ採用し、それ以外のときは他方の要素のＧＯＰのタイムコードを採用するようにしてもよい。
以上説明したように、本実施例２のデコーダ１６−１は、最新のＩピクチャ１３（例えば映像取込５）から要求のあった所定のＰピクチャの送信ピクチャ数に達するまでストリームデータを蓄積する。蓄積が達成した時点で、Ｉピクチャとこれに続く所定のピクチャ数のＰピクチャをＧＯＰ単位に加工して、画像受信装置に送信することで、回線状況に合わせたストリームデータ量を任意に指定することができ、回線の効率を最大限に使用できるようにしたものである。
【００４０】
図７は、本実施例２のネットワーク映像配信システムの配信動作を説明する図である。なお、図２と同じものには、同じ符号が付されている。
デコーダ１６−２は、ネットワーク４−２を経由し、デコーダ１６−１にストリームデータの送信要求（図示せず）をする。デコーダ１６−１は、ストリームデータの要求があったデコーダ１６−２に、その時点で最新のＩピクチャであるＩピクチャ１３−１を伝送する。デコーダ１６−２は、Ｉピクチャ１３−１を受信したら即座にストリームデータの復号（伸張）を開始する。このＩピクチャ１３−１の受信に係る期間を、デコーダ１６−２の映像伸張１として図示してある。なおピクチャの受信完了から復号完了までの時間はフレーム時間に対して十分短いとみなして、受信期間と復号期間はほぼ同じとして扱う。なお、上述の「即座に復号」とは、受信中のピクチャの２つ前のピクチャを復号することは含まないが、１ピクチャ分のデータの受信完了を待って復号を開始する（つまり、１つ前のピクチャを復号する）ことまでは含む。
【００４１】
Ｉピクチャ１３−１全体の受信（或いは復号）が完了すると、デコーダ１６−２は、ネットワーク４を経由し、デコーダ１６−１に次のストリームデータの送信要求をする。デコーダ１６−１は、送信要求があったデコーダ１６−２に次のＰピクチャ１３−２を伝送する。デコーダ１６−２は、Ｐピクチャ１３−２を受信しながら即座にストリームデータの復号を開始する。以降、続くＰピクチャ１３−３、１３−４、…を同じ手順で要求し、受信し、復号する。以降、ストリームデータの要求ごとに同じ手順を繰り返す。
【００４２】
デコーダ１６−３も１６−２と同様に送信要求を行いストリームデータを受信するが、狭い伝送帯域幅（該当ピクチャ伝送時の実効的な伝送速度）により受信が遅延するため、入力映像に対する遅延時間が徐々に増大していく。図中でデコーダ１６−ｎと示したものでは、Ｉピクチャのみがかろうじて送信できている。
本例のデコーダでは、常時少なくとも１ＧＯＰ分のストリームデータが１ＧＯＰ時間以上バッファされているため、デコーダ１６−３のように少なくとも１ＧＯＰ時間（最大で２ＧＯＰ時間）を使ってＩピクチャを送信することができる。
【００４３】
以上説明したように、本実施例２によれば、送信要求をピクチャ毎に行うようにしたので、ＧＯＰの途中で伝送帯域幅が大きく低下した場合でも、次のＧＯＰの（つまり最新の）Ｉピクチャが送信可能になった以降の送信要求に対して、Ｐピクチャの送信を打ち切ってその最新Ｉピクチャを送信することができる。
【実施例３】
【００４４】
本実施例３は、ネットワークデコーダ装置が再送信する際のレート制御として、特許文献４に記載の方法を用いたものであり、送信要求を、ピクチャ毎に行うようにした点で先の実施例１と異なる。
図１３は、本実施例３のデコーダ１８のブロック図である。図１３において、画像送信装置１等からＩＰパケット化された映像データが入力端子１３０に入力される。なお映像データの符号化方式としてMPEG-4 Part2 Visualを想定する。
【００４５】
Ｌ２−Ｌ３処理部１３１は、入力端子１３０からのＩＰパケットに対し、レイヤ２及びレイヤ３の受信処理をし、レイヤ３のペイロードを出力する。即ち、出力先に対し、Socket ＡＰＩと同様の機能を提供する。レイヤ３は、ＵＤＰ（User Datagram
Protocol）もしくはＴＣＰ（Transmission Control Protocol）である。
【００４６】
ＲＴＰ処理部１３４−１は、Ｌ２−Ｌ３処理部１３１から受け取ったデータグラムについてＲＦＣ３０１６等に規定されているＲＴＰ（Real-time Transport Protocol）処理やＲＴＣＰ処理をし、ＲＴＰパケットのペイロードを連結して得られるMPEG-4 Visualのビットストリームを復号化処理部１３２及びＩ−ＶＯＰ周期バッファ１３３へ出力する。またＲＴＰ処理部１３４−１は、Ｉ−ＶＯＰ周期バッファ１３３にペイロードを出力する都度、ＲＴＰパケットヘッダの情報（後述）をＩ−ＶＯＰ周期バッファ１３３へ通知する。また、ＲＴＰヘッダ中のＭ（Marker）ビットを検査し、Ｍビットが１のパケットを検出したときに、該パケット或いはその次のシーケンスナンバーのパケットのペイロード出力時に、タイムコード（後述）をＩ−ＶＯＰ周期バッファ１３３へ通知する。
ＲＦＣ３０１６は、MPEG-4 Visualのビットストリーム（符号化データ）をMPEG-2システム等を用いずにネットワーク上で伝送するのに適したＲＴＰペイロードフォーマットを規定している。１ピクチャ（フレーム）を構成するＶＯＰ（Video Object Plane）を１乃至複数のＲＴＰパケットで伝送する場合、各ＲＴＰパケットのペイロード先頭には常にコンフィグレーション情報、ＶＯＰヘッダ、ＶＰ（Video packet）ヘッダのどれかを配置し、エラー耐性を高めている。
【００４７】
復号化処理部１３２は、必要最小限の受信バッファを備え、ＲＴＰ処理部１３４−１から受け取ったビットストリームを復号化し、外部の映像モニター１２４に出力する。
【００４８】
Ｉ−ＶＯＰ周期バッファ１３３は、少なくともＩ−ＶＯＰ（先に説明したＩピクチャに相当する。）から次のＩ−ＶＯＰの直前までの符号化データを蓄積可能な容量を有するバッファである。
【００４９】
ＲＴＰパケット処理部１３４−２〜１３４−４は、ＲＴＣＰにより取得した受信者側での受信品質に関する情報に基づいて制御される伝送レートで、Ｉ−ＶＯＰ周期バッファ１３３から読み出したビットストリームをＲＦＣ３０１６等に従いＲＴＰパケット化し、Ｌ２−Ｌ３処理部１３５へ出力する。
ＲＴＰパケット処理部１３４−１、１３４−２〜１３４−４は通常、プロセッサ（不図示）上で動作するソフトウェアにより実現され、受信ストリーム数及びクライアント数に対応する数だけそれぞれ起動される。Ｉ−ＶＯＰ周期バッファ１３３も受信ストリーム数だけ起動される。
【００５０】
Ｌ２−Ｌ３処理部１３５は、Ｌ２−Ｌ３処理部１３１と同等の機能を提供するものであり、Ｌ２−Ｌ３処理部１３１と一体に構成されても良い。
【００５１】
図８は、Ｉ−ＶＯＰ周期バッファ１３３の構成図である。Ｉ−ＶＯＰ周期バッファ１３３は、リングバッファ８１と、Ｉ−ＶＯＰタイムコードレジスタ８２と、ヘッダポインタテーブル８３とから構成される。
リングバッファ８１は、ＲＴＰパケット処理部１３４−１からのビットストリームを、書き込みポインタＷＰの示す位置から順次書き込み、読出しポインタＲＰの示す位置から順次読み出してＲＴＰパケット処理部１３４−２等に出力する。
リングバッファ８１は、１ＧＯＶ（Group of VOP)分のビットストリームを保持するのに十分な容量のＦＩＦＯ型のバッファ（リングバッファ）であり、ＷＰはＲＰより優先度が高く、ＲＰを追い越すことができる（ＲＰをＷＰの前に強制移動する）。
【００５２】
Ｉ−ＶＯＰタイムコードレジスタ８２は、最新ＧＯＶタイムコードと、読出済ＧＯＶタイムコードとを記憶する。
最新ＧＯＶタイムコードとは、リングバッファ８１にＩーＶＯＰ（図では、Ｉと表示）を書き込む都度、そのＩーＶＯＰの直前にあるＧＯＶヘッダ中のタイムコードが、ＲＴＰパケット処理部１３４−１により書き込まれるものである。
読出済ＧＯＶタイムコードとは、リングバッファ８１からＩーＶＯＰが読み出される都度、最新Ｉ−ＶＯＰタイムコードがコピーされて書き込まれるものである。
Ｉ−ＶＯＰの検出は、ＲＴＰパケット処理部１３４−１から通知されるＭビットに拠っても、或いはＧＯＶヘッダの先頭にある32bitの”group_vop_start_code”をビットストリーム中からサーチすることに拠っても良い。また、ＧＯＶヘッダ中のタイムコードの代わりにＲＴＰパケットヘッダ中のタイムスタンプを用いても良い。
【００５３】
ヘッダポインタテーブル８３は、ＲＴＰパケット処理部１３４−１がビットストリームをリングバッファ８１に書き込む際に、そのビットストリームを運んできたＲＴＰパケットのヘッダ情報（タイムスタンプやＭビット）と、ペイロード長と、リングバッファ８１上でのそのペイロード（ビットストリーム）の先頭位置を示すポインタとが対応付けられて記録される。ＷＰがＲＰを追い越しそうになったら、ＲＰを、ＲＰが示しているＲＴＰペイロードの次のペイロードの先頭位置に移動する。
【００５４】
次に、図１３と図８を参照して本例のデコーダ１８の動作を説明する。
各ＲＴＰパケット処理部１３４−２、１３４−３、１３４−４は、Ｌ２−Ｌ３処理部１３５からの伝送レートに応じたレディー信号（図１３では点線で示す信号）により、Ｉ−ＶＯＰ周期バッファ１３３から符号化データを読み出す。レディー信号とは、例えばＲＴＣＰのＲＲ（Receiver Report）である。ＴＣＰの場合、クライアント（画像受信装置やデコーダ等）からのACK(受信応答)を利用可能ではあるが、ＲＴＣＰの併用が望ましい（）。例えば、各ＲＴＰパケット処理部１３４−２等は定期的にＳＲをクライアントに送信し、クライアントから返信されるＲＲに含まれるパケット破棄率情報や最新ＳＲ受信時刻情報などを得る。この定期的な情報から、パケット破棄率がゼロとなるように（目標）送信レートを決定する。
【００５５】
具体的には、ＲＴＰパケット処理部１３４−２等は、ＲＴＰパケット送信時に、そのパケット長に送信レートを乗じて求まる時間でタイマーを設定する。そしてその時間経過後にタイマーイベント等により、次のステップ301〜304の処理を行なう。
【００５６】
まず、ステップ301として、読み出し条件の判断をする。読み出し条件の一例として、
例１：最新ＧＯＶタイムコード
＜＞ 読出しＧＯＶタイムコード
例２：ｄ秒 ＞（最新ＧＯＶタイムコード
− 読み出し対象ＶＯＰのタイムコード）
例３：ｄ秒 ＞（最新のＩ−ＶＯＰのタイムスタンプ
− 読み出し対象ＶＯＰのタイムスタンプ）
例４：ａ ＞（読出しポインタＲＰ
− 書込みポインタＷＰ）
等がある。なお、読み出し対象ＶＯＰとは読出しポインタＲＰが指す位置のＶＯＰのことであり、“＜＞”は左辺と右辺が等しくないことを意味する。ｄは、正の値であり、I-VOP周期やネットワーク伝送ジッタ（ＲＴＣＰのＲＲから得られる）に応じて適切に設定するものとする。なお、例２における、「読み出し対象ＶＯＰのタイムコード」は、ＶＯＰヘッダからは直接得られず、読出済ＧＯＶタイムコードと、ＶＯＰヘッダ内のmodulo_time_baseやvop_time_incrementとから計算する必要がある。その他の値は、ヘッダポインタテーブル８３等に格納されているものを用いる。例４はＷＰがＲＰに迫ってきていることを意味し、アドレスの差がａ未満になると真となる。
【００５７】
ステップ302として、上記読み出し条件が真ならば、読み出し対象ＶＯＰは古る過ぎると判断して、ＲＰを最新I-VOPに移動してリングバッファ８１からビットストリームを読み出し、偽ならば、ＲＰが示す通りに読み出す。読み出す量は、ヘッダポインタテーブル８３に格納されているペイロード長に従うが、次のＶＯＰかＶＰ（Video Packet）のスタートコードが検出されるまで読み出しても良い。
【００５８】
ステップ303として、読み出したビットストリームをペイロードとするＲＴＰパケットを作成する。その際、ＲＴＰパケットヘッダ中のタイムスタンプとしては、ヘッダポインタテーブル８３に格納されているタイムスタンプに適当なオフセットを加えたものを用いても良く、上述の読み出し対象ＶＯＰのタイムコードと同様の計算により、独自に作り直しても良い。
【００５９】
ステップ304として、作成したＲＴＰパケットをＬ２−Ｌ３処理部１３５に出力すると共に、次のパケット処理のため、出力したパケット長に送信レートを乗じて求まる時間でタイマーを設定する。
【００６０】
図８では、書き込みポインタＷＰでリングバッファ８１にＰ(n+1)を書き込み、読み出しポインタＲＰでＰ(３)を読み出し始める状態を示し、Ｉ−ＶＯＰタイムコードレジスタ８２には、Ｉ(０)のタイムコードが格納されている。
低レート伝送路に対しては、読み出し速度が書き込み速度より遅くなる場合がある。この場合の読み出し条件判断処理では、Ｉ−ＶＯＰタイムコードに格納されているＩ（ｎ）よりも時間の早い（タイムコードの小さい）Ｐ（３）を読み出すことになる。従って、その差分がｄ秒以上となるため、上述の読み出し条件が成立することになり、Ｉ（ｎ）に読み出しポインタＲＰを移動してＩ（ｎ）を読み出す動作となる。
【００６１】
即ち、この動作によりＰ（３）〜Ｐ（ｎ−１）の読み出しがスキップされ、Ｉ−ＶＯＰ周期バッファ１３３内部でＩ−ＶＯＰ直前のデータが破棄されたことになる。このように読み出し速度は、伝送レートに対応したものとなる。これにより伝送レート適応型パケット伝送が可能となる。
【００６２】
以上説明したように、本実施例３の各ＲＴＰパケット処理部１３４−２等は、それぞれのクライアント（画像受信装置やデコーダ等）間の伝送路の利用可能帯域（伝送速度）に従ったデータ量をＩ−ＶＯＰ周期バッファ１３３から読み出す。従って、必然的に低レート伝送路に対してはＩ−ＶＯＰ周期バッファ１３３内で画像データが破棄されることになる。このようにして自動的に伝送路の伝送速度にあわせて画像データが伝送される。
本例の伝送レート適応型パケット伝送方式は、ベストエフォートの伝送路（ネットワーク）に対して有効である。つまり、伝送レートの動的な変動に対しても自動的に適応した画像符号化データの伝送が可能となる。
【実施例４】
【００６３】
本実施例４は、映像データの符号化方式としてH.264を想定し、ＲＴＰペイロードフォーマットとしてＲＦＣ３９８４を用いた点などで先の実施例３と異なる。
H.264のエンコーダは概念的に、スライス単位で符号化データを出力するビデオ符号化レイヤ（ＶＣＬ）と、そのスライス出力をパケットネットワークでの伝送に適したＮＡＬユニットにパケット化するネットワーク抽象化レイヤとから構成される。スライスとは、１ピクチャ（フレーム）を１乃至複数に分割したものであり、１ピクチャ分のデータの集まりはＡＵ（アクセスユニット）と呼ばれる。
【００６４】
ＮＡＬユニットの先頭には、ＮＡＬユニットタイプオクテット（以後ＮＡＬヘッダと呼ぶ）が配置され、その直後にＮＡＬユニットのペイロードが続く。ＮＡＬヘッダは、そのＮＡＬユニットが壊れていることを示す１ビットの”forbidden_zero_bit”と、そのＮＡＬユニットの内容が参照ピクチャの完全性を保つのに必要か否かを示す２ビットの”nal_ref_idc”と、そのＮＡＬユニットのタイプを示す５ビットの”nal_unit_types”とからなる。
”nal_unit_types”の値は、ＮＡＬユニットの内容が、ＩＤＲピクチャ（他のピクチャに依存せずに復号可能なピクチャ。前述のＩピクチャに相当）のスライスであれば”５”になり、AU delimiter（アクセスユニットの境界を示す）であれば”９”になり、またＳＶＣ(Scalable
Video Coding)を用いたときには、それらに対応する値をとる。その他、シーケンスパラメータセット、ピクチャパラメータセット、サブセットシーケンスパラメータセット、End of sequence等のＮＡＬについても値が決められている。
H.264は、シンタックスの自由度が高いのが特徴であり、スライス（ピクチャ）の標本化／再生時刻（順序）とは異なるような、符号化順序、伝送時刻順序、復号順序が許容されている。また上述のようなＮＡＬユニット化より、従来のエレメンタリーストリーム中で使用されていたスタートコードが不要になっている。
【００６５】
本実施例４のデコーダ１５１の基本構成は、図１３に示した実施例３のデコーダ１８と同様であり、実施例３との相違点のみ説明する。
本例のＲＴＰ処理部４４−１（１３４−１に相当する）は、受信したＲＴＰパケットに対し、ＲＦＣ３９８４等に規定されているＲＴＰ処理等をして、ＲＴＰペイロードを出力する。この規定におけるＲＴＰペイロードフォーマットには、シングルＮＡＬユニットパケット、集合パケット、分割パケット等があるが、必ず、ペイロードの先頭はＮＡＬヘッダから始まるようになっている。
【００６６】
ＩＤＲ周期バッファ４３は、実施例３のＩ−ＶＯＰ周期バッファ１３３に代えて備えられるものであり、受信した最新のＩＤＲピクチャにアクセス可能なように、格納したＲＴＰペイロード（より好ましくはＮＡＬユニット）毎にその先頭位置や時刻等を管理している。１枚のＩＤＲピクチャを構成する最初のＮＡＬユニットは、AU delimiter ＮＡＬユニットの後に最初に出現したＩＤＲ−ＮＡＬ（”nal_unit_types”=5のＮＡＬユニット）として検出する。なお、AU delimiter ＮＡＬとＩＤＲ−ＮＡＬの間には、sequence
parameter set、picture parameter、SEI等のＮＡＬユニットが配置され、AU delimiter ＮＡＬの前にはEnd of sequence ＮＡＬが配置される場合があり、これらを利用して検出しても良い。１ＩＤＲピクチャ分のＩＤＲ−ＮＡＬが複数ある場合でも、それらは連続していることが通常である。
【００６７】
ＲＴＰパケット処理部４４−２〜４４−４は、実施例３のＲＴＰパケット処理部１３４−２〜１３４−４と同様の適応レート制御を行なう。そして、その送信レートでＮＡＬユニットを全て送りきれなくなったときに、”nal_ref_idc”が低いものから順次スキップを行なう。”nal_ref_idc”は”0”〜”3”の値を取るので、４段階の制御となる。ＲＦＣ３９８４には、”nal_ref_idc”として、非参照ピクチャのＮＡＬには”0”を、ＩＤＲ−ＮＡＬには”3”をセットすることが定められている。また、符号化側（画像送信装置）で、ＩＤＲピクチャのみを参照するスライス、（動きベクトルが大きいとして）Region of Interestフラグを設定したスライス、或いはイントラスライス等のＮＡＬに対し、”nal_ref_idc”に”2”を設定し、それ以外の参照ピクチャのＮＡＬに”1”を設定するようにしても良い。
或いは、もしＳＶＣを用いていれば、ＮＡＬ拡張ヘッダも参照して、重要度や他からの依存性の低いＮＡＬから送信をスキップする。拡張ヘッダには、空間、ＣＧＳ、ＭＧＳ、ＦＧＳ等のレイヤ構造においてどの階層に属するかを示す情報を含む。拡張ヘッダが無い場合、シンタックスを解釈して判別する。つまりＮＡＬペイロードの先頭には通常、スライスヘッダがあるのでそれを参照する。
【００６８】
４段の各段階間の遷移条件は、より低レートの段階への遷移としては、実施例３等のスキップ開始条件（例えば、最新のAU delimiter或いはＩＤＲ−ＮＡＬを受信してから所定時間経過したとき）と同じでよい。より高レートの段階への遷移としては、その逆（例えば、読出しポインタＲＰが書込みポインタＷＰに追いついたとき）とする。
送信レートが絞られていくと最終的に、ＶＣＬクラスのＮＡＬとしてはＩＤＲ−ＮＡＬの一部だけを送信するようになる。ただし、AU delimiter NALのような重要なｎｏｎ−ＶＣＬクラスのＮＡＬもスキップせず送信する。
本例では、ＮＡＬ（ＲＴＰパケット）のスキップにより、ＡＵの最後のＲＴＰパケットにＭビットを適切に設定できない可能性があるが、通常の伝送路上のパケットロス同様、Ｍビットだけに頼らない実装が一般的となっており、問題ない。
【実施例５】
【００６９】
本実施例５のデコーダは、ＯＮＶＩＦ（Open Network Video Interface Forum Core Specification Version 1.0
2008年11月）に準拠したネットワーク映像配信システムで使用されることを前提にした点などで先の実施例４と異なる。
ＯＮＶＩＦでは、サービス指向アーキテクチャが採用されており、ネットワーク上にある機器を発見したり、カメラ、画像送信装置（エンコーダ）、画像受信装置（デコーダ）の仕様（プロファイル）情報を交換したり、雲台を制御したりするための各種の通信は全てＷＳＤＬ（Web Service Description Language）で定義され、それらの機能はWebサービスとして提供される。ＷＳＤＬはＸＭＬの構文で記述され、ＳＯＡＰ（Simple
Object Access Protocol）のメッセージとして通信される。ＳＯＡＰのメッセージ（エンベロープ）は、更にＨＴＴＰを用いてそのBODY内に格納されて伝送される。
【００７０】
遠隔のWebサービスを発見する方法としては、非特許文献３のWS-Discoveryを用いるよう規定されている。WS-Discoveryでは、システムに参加する全機器が共通のマルチキャストアドレスに参加し、そのアドレスを通じてクライアントがサービスのProbeをし、サービス提供元がそれに応答して直接クライアントにProbe matchを返信することを基本としているが、Discovery Proxy（ＤＰ）が代わりに応答することもできる。Probeメッセージには、例えばカメラを検索する場合、カメラの設置場所や名前などがＬＤＡＰ（RFC2251等）の様式で記述される。
【００７１】
本例においては、マルチキャストアドレスを使用せずにWS-Discoveryを実現するため、システムの全ての画像送信装置（エンコーダ、ＩＰ力メラ等）のＵＲＩ（ＩＰアドレス）等を収集或いは保持するとともに、ブロードキャストされたSOAPメッセージ、或いはモニター可能なＬＡＮ上の全てのSOAPメッセージを受信し、必要に応じてＤＰとなってWS-Discovery(Remote Discovery)サービスを提供するＤＰサーバを、クライアントが存在する各ＬＡＮ（ブロードキャストドメイン）に配置する。
【００７２】
図３は、本実施例５のデコーダ３０の構成図である。デコーダ３０は、実施例４のデコーダ１５１の構成に加え更に、ＷＳＤＬの通信を行なうSOAP／HTTP処理部３１と、ＲＴＳＰ（Real Time Streaming Protocol）等のセッション管理を行なうセッション管理部３２と、主にSOAP／HTTP処理部３１を介してWebサービスを提供するWebサービス管理部３３と、復号化した映像をサイズ変換等をして再度符号化する符号化処理部３５を備えている。
【００７３】
まず、本例のSOAP／HTTP処理部３１、Webサービス管理部３３が行なうRemote DiscoveryサービスおよびMediaサービスを説明する。
本例のSOAP／HTTP処理部３１は、マルチキャストアドレスに限らず、ブロードキャストされたSOAPメッセージ、或いはLAN上のモニター可能な全てのSOAPメッセージを受信している。
もしクライアントからの映像要求である”GetStreamUriRequest”を受信すると、Webサービス管理部３３は、映像要求の対象（Media profileで特定される）が、現在デコーダ３０自身で受信しているものかどうか判断し、受信していなければその映像要求を無視し、受信していればデコーダ３０のホスト名を含むＵＲＩを含む応答”GetStreamUriResponse”を返す。ＵＲＩは、ホスト名以降のパス名として、対応するMedia profileを特定可能な文字列等が付加されて、動的に生成されうる。映像要求を無視しても、クライアントは、ＤＰサーバ等からの応答を受け取ってそのＵＲＩ（ＩＰ力メラ等のもの）を知ることができる。一方、有効な（エラーではない）応答を冗長に受け取った場合は、ＵＲＩをアドレス解決し、そのＩＰアドレスがクライアントの属するネットワークに近い方（或いはネットマスクが一致する方）を採用すればよい。
”GetStreamUriResponse”を受け取ったクライアントは、当該ＵＲＩ宛にＲＴＳＰのDESCRIBEメソッドを送信するが、デコーダ３０がそれを受信した場合、映像再配信要求と解釈して、セッションを初期化し、プレゼンテーションを開始する。つまりＲＴＰ処理部３４−２等（実施例４の４４−２等に相当する）を新たに起動し、要求対象に対応するＩＤＲ周期バッファからストリームを読み出して、要求元クライアントに配信する。
【００７４】
デコーダ３０は、自身で受信して復号化する必要がなくなった場合、全クライアントにANNOUNCEメソッドを送信した後（或いは一方的に）、映像再配信を終了することができる。クライアントは再度”GetStreamUriRequest”を行い、デコーダ３０はそれに応答しないのでＩＰカメラ等の真のＵＲＩを取得し、セッションを確立することができる。もし、クライアントがデコーダ３０のＵＲＩ宛にSETUPメソッド等を送信しても、デコーダ３０は、直前まで接続していたＩＰカメラ等のＵＲＩを含むREDIRECTメソッドを応答するので問題は無い。
【００７５】
上記の他、雲台を制御するためのPTZサービス、カメラのフォーカス等を制御するためのImagingサービス、その他のWebサービスがあるが、上記と同様である。即ち、デコーダ１５１は自身が接続中のエンコーダやＩＰ力メラ等のＵＲＩ宛のWebサービス要求等を受信した場合、ＤＰとして、或いは完全に要求先ＵＲＩのＩＰ力メラ等を装って、要求に応答する。応答に必要な情報をキャッシュしていない場合、或いは雲台制御コマンドのように要求に含まれる情報をＩＰ力メラ等に伝える必要がある場合、要求を当初のＵＲＩ宛に転送して真のＩＰ力メラ等から応答を得て、それを元の要求元に応答する。
もしクライアントが発したWebサービス要求が直接、宛先通りに真のエンコーダ等に届き、応答が両者から帰ってきた場合、クライアントは任意の一方（例えばネットマスクが一致する方）を採用すればよい。
【００７６】
次に、本例の符号化処理部３５等を利用した再配信を説明する。ＯＮＶＩＦでは、画像送信装置は、ＱＶＧＡサイズのＪＰＥＧを送信できなければならないと定めているが、そのような画像送信装置が送信可能な映像形式等は、Media Profileとして定義される。Media Profileの中には、”Video source
configuration”、”Video encoder
configuration”、”PTZ configuration”などが規定されている。
本例のデコーダ３０は、ＭＰＥＧ等の動画の形式で受信中の映像について、ＪＰＥＧで映像要求を受けたときに、処理負荷に余裕があれば、ＭＥＰＧを復号して得た映像をＪＰＥＧにトランスコードして、要求元に配信（プレゼンテーション）することもできるようにする。具体的な処理の手順は以下のようになる。
【００７７】
ステップ401として、デコーダ３０は、利用可能なMedia Profileの問い合わせを意味する”
GetProfilesRequest”を受信する。Webサービス管理部３３はそれを解釈し、Media Profileが示す映像源(Video source configuration)が、デコーダ３０が現在受信中のものと同じか否か判定し、同じでなければ、Media Profileを１つも含まない空の”GetProfilesResponse”を応答する。ステップ401において映像源が、同じであれば、符号化方式やピクチャサイズ等も同じか否かを判定する。
ステップ402として、ステップ401において映像源が同じと判定された場合、処理負荷の余裕度に応じて、１乃至複数のMedia Profileを含む”GetProfilesResponse”を応答する。即ち、余裕度があれば、現在受信中の映像の符号化方式やピクチャサイズ等と同じ”Video encoder
configuration”を規定するMedia Profileの他、符号化処理部３５で再符号化可能な他の映像形式を指定するMedia
Profileも含ませる。
ステップ403として、ステップ402の”GetProfilesResponse”を受信したクライアントから”GetStreamUriRequest”等の映像要求を受信した場合、その時点で処理負荷に余裕があれば、デコーダ３０のホスト名を含むＵＲＩを生成して応答”GetStreamUriResponse”を返すとともに、映像要求が指定するMedia Profileの示す符号化方式やピクチャサイズ等で符号化するよう、符号化処理部３５を初期化する。
ステップ404として、ステップ403の”GetStreamUriResponse” を受信したクライアントからＲＴＳＰの所定のメソッドを受信した場合、セッションを初期化し、プレゼンテーションを開始する。符号化処理部３５は、指定された符号化方式等に従い、必要に応じてフレーム間引き処理、インタレース／プログレッシブ変換処理、リサイズ処理（超解像処理によるサイズの拡大も含む）等を行なう。Media Profileとして複数のVideoSourceを指定することも可能であり、その場合、複数の映像を１画面に合成し（例えば４−ｕｐ）、１ストリームに符号化して再配信する。
【産業上の利用可能性】
【００７８】
本発明は、監視カメラシステム等に好適であるが、ビデオ会議システム、ストリーム配信サービス等で用いられる符復号化装置、セットトップボックス等にも利用できる。
【符号の説明】
【００７９】
１ａ，１ｂ 画像送信装置、 ２ ＩＰ力メラ、
３ 画像サーバ装置、 ４ ネットワーク、
５ パーソナルコンピュータ（ＰＣ）、６ 画像受信装置（従来）、
７ ＰＣ（操作専用）、 ８，８ａ ビデオモニタ、
９ 専用操作器、
１１−１〜１１−ｎ アナログ映像、 １２ アナログカメラ、
１３−１〜１３−ｎ Ｉ／Ｐピクチャ、１４ ストリームバッファ、
１６、１８、３０ ネットワークデコーダ装置（デコーダ）、
１７ ＧＯＰ単位ストリームデータ、
３１ ＳＯＡＰ／ＨＴＴＰ処理部、 ３２ セッション管理部、
３３ Ｗｅｂサービス管理部、 ３４，４４，１３４ ＲＴＰ処理部、
３５ 符号化処理部、 ４３ ＩＤＲ周期バッファ、
８１ リングバッファ、 ８２ Ｉ−ＶＯＰタイムコードレジスタ、
８３ ヘッダポインタテーブル、
１３１，１３５ Ｌ２−Ｌ３処理部、 １３２ 復号化処理部、
１３３ Ｉ−ＶＯＰ周期バッファ、 １３６ 出力端子。
【特許請求の範囲】
【請求項１】
映像送信装置からＩＰネットワークを介して符号化映像データを受信し、復号して出力するネットワークデコーダ装置において、
受信した符号化映像データを、少なくともＩピクチャ周期分格納するバッファと、
符号化映像データの再配信要求を受信したときに、前記バッファから符号化映像データを順次読み出して、該再配信要求の要求元クライアントへ送信する再配信手段と、を備え、
該再送信手段は、バッファに格納された最新Ｉピクチャより古いデータを符号化映像データの送信をスキップすることを特徴とするネットワークデコーダ装置。
【請求項２】
請求項１記載のネットワークデコーダ装置において、
該受信した符号化映像データの送信元の映像送信装置が有するサーバ機能と互換の機能を有し、前記再配信要求を受け付るサーバ手段を更に備え、
前記再配信要求は、前記映像送信装置が符号化映像データの送信に使用可能な複数のプロトコルのうちの任意の１つを指定して再配信を要求するものであり、サーバ手段は、該指定されたプロトコルを使用して再配信をするように前記再配信手段を制御することを特徴とするネットワークデコーダ装置。
【請求項３】
請求項２記載のネットワークデコーダ装置において、
サーバ手段は、前記再配信の送信先から、前記映像送信装置が送信する符号化映像データの情報源である力メラに関する制御要求を受信したとき、該制御要求を該映像送信装置に宛てて転送することを特徴とするネットワークデコーダ装置。
【請求項４】
請求項３記載のネットワークデコーダ装置において、
入力された複数の映像データを、該複数の映像が１画面内に並んで表示されるように１の映像データに合成し、該合成された１の映像データを符号化する符号化処理手段を更に備え、
映像源の異なる映像送信装置から複数の符号化映像データを受信して前記符号化処理手段に入力し、該合成された１の映像データを、クライアントからの要求に応じて再配信することを特徴とするネットワークデコーダ装置。
【請求項５】
前記ネットワークデコーダ装置は、
クライアントからサービスの探索を受信したときには、前記受信した符号化映像データの送信元の映像送信装置の代わりに該探索に応答して、該ネットワークデコーダ装置のＵＲＩを該クライアントに通知し、
該クライアントから該ＵＲＩにメディアプロファイルの問い合わせを受けたときには、前記受信した符号化映像データと同じ映像形式を規定するメディアプロファイルを含む１乃至複数のメディアプロファイルを該クライアントに通知し、
該クライアントから該メディアプロファイルに基づく映像要求を受信したときに、前記再配信を行なうことを特徴とする請求項３記載のネットワークデコーダ装置。
【請求項１】
映像送信装置からＩＰネットワークを介して符号化映像データを受信し、復号して出力するネットワークデコーダ装置において、
受信した符号化映像データを、少なくともＩピクチャ周期分格納するバッファと、
符号化映像データの再配信要求を受信したときに、前記バッファから符号化映像データを順次読み出して、該再配信要求の要求元クライアントへ送信する再配信手段と、を備え、
該再送信手段は、バッファに格納された最新Ｉピクチャより古いデータを符号化映像データの送信をスキップすることを特徴とするネットワークデコーダ装置。
【請求項２】
請求項１記載のネットワークデコーダ装置において、
該受信した符号化映像データの送信元の映像送信装置が有するサーバ機能と互換の機能を有し、前記再配信要求を受け付るサーバ手段を更に備え、
前記再配信要求は、前記映像送信装置が符号化映像データの送信に使用可能な複数のプロトコルのうちの任意の１つを指定して再配信を要求するものであり、サーバ手段は、該指定されたプロトコルを使用して再配信をするように前記再配信手段を制御することを特徴とするネットワークデコーダ装置。
【請求項３】
請求項２記載のネットワークデコーダ装置において、
サーバ手段は、前記再配信の送信先から、前記映像送信装置が送信する符号化映像データの情報源である力メラに関する制御要求を受信したとき、該制御要求を該映像送信装置に宛てて転送することを特徴とするネットワークデコーダ装置。
【請求項４】
請求項３記載のネットワークデコーダ装置において、
入力された複数の映像データを、該複数の映像が１画面内に並んで表示されるように１の映像データに合成し、該合成された１の映像データを符号化する符号化処理手段を更に備え、
映像源の異なる映像送信装置から複数の符号化映像データを受信して前記符号化処理手段に入力し、該合成された１の映像データを、クライアントからの要求に応じて再配信することを特徴とするネットワークデコーダ装置。
【請求項５】
前記ネットワークデコーダ装置は、
クライアントからサービスの探索を受信したときには、前記受信した符号化映像データの送信元の映像送信装置の代わりに該探索に応答して、該ネットワークデコーダ装置のＵＲＩを該クライアントに通知し、
該クライアントから該ＵＲＩにメディアプロファイルの問い合わせを受けたときには、前記受信した符号化映像データと同じ映像形式を規定するメディアプロファイルを含む１乃至複数のメディアプロファイルを該クライアントに通知し、
該クライアントから該メディアプロファイルに基づく映像要求を受信したときに、前記再配信を行なうことを特徴とする請求項３記載のネットワークデコーダ装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１３】
【図１１】
【図１２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１３】
【図１１】
【図１２】
【公開番号】特開２０１０−２７２９４３（Ｐ２０１０−２７２９４３Ａ）
【公開日】平成２２年１２月２日（２０１０．１２．２）
【国際特許分類】
【出願番号】特願２００９−１２０８８３（Ｐ２００９−１２０８８３）
【出願日】平成２１年５月１９日（２００９．５．１９）
【出願人】（０００００１１２２）株式会社日立国際電気 (5,007)
【Ｆターム（参考）】
【公開日】平成２２年１２月２日（２０１０．１２．２）
【国際特許分類】
【出願日】平成２１年５月１９日（２００９．５．１９）
【出願人】（０００００１１２２）株式会社日立国際電気 (5,007)
【Ｆターム（参考）】
[ Back to top ]