メディア配信切替え方法、受信装置、送信装置
【課題】パケットネットワーク上でのメディア情報の伝送において、リアルタイム性伝送と非リアルタイム性伝送とが混在する伝送技術に関し、リアルタイム性伝送によるメディア情報と非リアルタイム性伝送によるメディア情報とを識別して受信可能とする。
【解決手段】要求パケット生成部／送信部は、メディア情報の配信を要求する要求パケットを生成し、送信装置に送信する。要求応答パケット受信部が、送信装置から要求パケットに対応する要求応答パケットを受信すると、要求応答解析部は、要求応答パケットに設定されている要求応答を解析する。モード判定部は、要求応答に付加されたリアルタイム性伝送と非リアルタイム性伝送のどちらの伝送を行う装置タイプであるかを示す装置タイプ情報に基づいて、リアルタイム性伝送を行う動作モードと非リアルタイム性伝送を行う動作モードとを切り替える。
【解決手段】要求パケット生成部／送信部は、メディア情報の配信を要求する要求パケットを生成し、送信装置に送信する。要求応答パケット受信部が、送信装置から要求パケットに対応する要求応答パケットを受信すると、要求応答解析部は、要求応答パケットに設定されている要求応答を解析する。モード判定部は、要求応答に付加されたリアルタイム性伝送と非リアルタイム性伝送のどちらの伝送を行う装置タイプであるかを示す装置タイプ情報に基づいて、リアルタイム性伝送を行う動作モードと非リアルタイム性伝送を行う動作モードとを切り替える。
【発明の詳細な説明】
【技術分野】
【０００１】
開示する技術は、パケットネットワーク上でのメディア情報の伝送において、リアルタイム性伝送と非リアルタイム性伝送とが混在する伝送技術に関する。
【背景技術】
【０００２】
ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワーク等のパケットネットワーク上で、送信装置と受信装置が、映像や音声等のメディア情報の通信を行う場合、リアルタイム性伝送と非リアルタイム性伝送とが混在する場合がある。
【０００３】
リアルタイム性伝送では、例えば図１３に示されるように、監視カメラ１３０５で得られる映像信号が、リアルタイム映像配信装置１３０３で符号化され、リアルタイムの動画パケットとして、リアルタイム映像受信装置１３０１に伝送されて復号、再生される。リアルタイム映像受信装置１３０１で復号、再生される映像信号のクロックを、リアルタイム映像配信装置１３０３での符号化時のクロックに同期させるために、例えばＰＣＲを使用した方式が採用される。この方式では、伝送される動画パケットにＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）と呼ばれるクロック同期用パケットが多重される。復号側では、受信されたＰＣＲデータと受信時の復号器側のシステムタイムクロック（ＳＴＣ：Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）との差分が算出される。そして、この差分値によって電圧制御水晶発振器ＶＣＸＯ（Ｖｏｌｔａｇｅ Ｃｏｎｔｒｏｌｌｅｄ Ｘｔａｌ Ｏｓｃｉｌｌａｔｏｒ）が制御されて、再生クロックが生成される。即ち、リアルタイム性伝送では、リアルタイム映像配信装置１３０３（エンコーダ）とリアルタイム映像受信装置１３０１（デコーダ）のクロックが同期させられることにより、リアルタイム映像受信装置１３０１側のパケット受信バッファのサイズが極力小さくされて映像の遅延が極力回避される。
【０００４】
一方、非リアルタイム性伝送では、例えば図１３に示されるように、サーバ配信用映像受信装置１３０２からの要求に基づき、ファイル配信サーバ１３０４内の記憶装置に蓄積された符号化された映像信号ファイルが読み出されてパケット伝送される。サーバ配信用映像受信装置１３０２は、パケット伝送されてくる映像信号ファイルを、自装置内のシステムタイムクロックに基づいて復号し再生する。非リアルタイム性伝送では、映像信号ファイルが符号化されたときのタイミングと全く同じタイミングで伝送を行うことは技術的に困難である。このため、サーバ配信用映像受信装置１３０２は、再生タイミングと伝送タイミングの差を吸収するために、フロー制御を実施する。フロー制御では、パケット受信バッファに滞留するパケットがバッファサイズを超えそうになると、サーバ配信用映像受信装置１３０２からファイル配信サーバ１３０４に送信停止要求パケットが送信され、ファイル配信サーバ１３０４が映像信号ファイルの伝送を停止する。逆に、パケット受信バッファに滞留するパケットがなくなりそうになると、サーバ配信用映像受信装置１３０２からファイル配信サーバ１３０４に送信開始要求パケットが送信され、ファイル配信サーバ１３０４が映像信号ファイルの伝送を開始（再開）する。
【０００５】
ここで、図１３に示されるリアルタイム映像受信装置１３０１は、通常はリアルタイム映像配信装置１３０３からのリアルタイム性伝送による映像信号を受信するが、装置の有効活用のために、サーバ配信用映像受信装置１３０２からの非リアルタイム性伝送による映像信号ファイルも受信できるようにしたいという要請がある。
【０００６】
このような混在受信を可能とするためには、リアルタイム映像受信装置１３０１が、非リアルタイム性伝送のためのフロー制御機能を実装する必要がある。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、リアルタイム映像受信装置１３０１が、ファイル配信サーバ１３０４からの非リアルタイム性伝送による映像信号ファイルを受信しようとした場合、リアルタイム性伝送と非リアルタイム性伝送を識別するような従来技術はなかった。このため、従来は、リアルタイム映像受信装置１３０１にフロー制御機能を実装することができなかった。
【０００８】
このため、リアルタイム映像受信装置１３０１が、図１３に示されるように、ファイル配信サーバ１３０４からの非リアルタイム性伝送による映像信号ファイルをフロー制御無しで受信した場合、再生タイミングと伝送タイミングとの差が拡大する可能性が高い。この結果、リアルタイム映像受信装置１３０１のパケット受信バッファにおいて、パケットのオーバーフロー又はアンダーフローが発生してしまい、映像信号ファイルを正常に受信できなくなってしまうという問題点を有していた。
【０００９】
そこで、本発明の１つの側面では、リアルタイム性伝送によるメディア情報と非リアルタイム性伝送によるメディア情報とを識別して受信可能とすることを目的とする。
【課題を解決するための手段】
【００１０】
態様の一例は、パケットネットワーク上での送信装置から受信装置へのメディア配信を切り替えるメディア配信切替え方法として実現され、以下の構成を有する。
まず、受信装置から送信装置にメディア情報の配信を要求する要求パケットが送信される。
【００１１】
次に、要求パケットに応答して送信装置から受信装置に、その送信装置がリアルタイム性伝送と非リアルタイム性伝送のどちらの伝送を行う装置タイプであるかを示す装置タイプ情報を付加した要求応答パケットが返信される。
【００１２】
そして、受信装置において、送信装置から受信した要求応答パケットに付加されている装置タイプ情報に基づいて、リアルタイム性伝送を行う動作モードと非リアルタイム性伝送を行う動作モードとが切り替えられて受信動作が実行される。
【発明の効果】
【００１３】
リアルタイム性伝送を実行する送信装置と非リアルタイム性伝送を時刻する送信装置とが混在するような環境において、各送信装置専用の受信装置を用意する必要がなくなり、コストダウンが可能となる。
【００１４】
配信元を意識せずにシームレスにメディア情報を受信可能な受信装置を実現することが可能となる。
【図面の簡単な説明】
【００１５】
【図１】受信装置の第１の実施形態の構成図である。
【図２】送信装置の第１の実施形態の構成図である。
【図３】受信装置の第１の実施形態の制御動作を示す動作フローチャートである。
【図４】送信装置の第１の実施形態の制御動作を示す動作フローチャートである。
【図５】受信装置及び送信装置の第１の実施形態における要求パケットのデータ構成例を示す図である。
【図６】受信装置及び送信装置の第１の実施形態における要求応答パケットのデータ構成例を示す図である。
【図７】受信装置及び送信装置の第１の実施形態の動作シーケンス図である。
【図８】送信装置の第２の実施形態の構成図である。
【図９】受信装置の第２の実施形態の制御動作を示す動作フローチャートである。
【図１０】送信装置の第２の実施形態の制御動作を示す動作フローチャートである。
【図１１】受信装置及び送信装置の第２の実施形態における要求パケットのデータ構成例を示す図である。
【図１２】受信装置及び送信装置の第２の実施形態の動作シーケンス図である。
【図１３】従来技術の説明図である。
【発明を実施するための形態】
【００１６】
以下、各実施形態について図面を参照しながら詳細に説明する。
図１の１００は、非同期かつ品質保証なしのパケットネットワーク上で、リアルタイム性伝送による映像信号と非リアルタイム性伝送による映像ファイルとを識別して受信可能な受信装置の第１の実施形態の構成図である。図２の２００は、同じく送信装置の第１の実施形態の構成図である。受信装置１００は図１３のリアルタイム映像受信装置１３０１に対応し、送信装置２００は図１３のリアルタイム映像配信装置１３０３又はファイル配信サーバ１３０４に対応する。
【００１７】
図１の受信装置１００において、要求パケット生成部１０１は、送信装置２００に対して、映像信号又は映像ファイルの配信開始又は配信停止を指示する要求パケットを生成する。要求パケット送信部１０２は、要求パケット生成部１０１が生成した要求パケットを、送信装置２００に向けて特には図示しないネットワークに送信する。
【００１８】
要求応答パケット受信部１０３は、ネットワークから自装置が送信した要求パケットに対する応答パケットである要求応答パケットを受信する。要求応答解析部１０４は、要求応答パケット受信部１０３にて受信された要求応答パケットにて指定されている要求応答の内容を解析する。モード判定部１０５は、要求応答にリアルタイムエンコーダと配信サーバのどちらの装置タイプ情報が指定されているかを判定する。そして、モード判定部１０５は、要求応答にリアルタイムエンコーダが指定されているときには、フロー制御部１０６と切替部１１５に対して、リアルタイムモードを通知する。モード判定部１０５は、要求応答に配信サーバが指定されているときには、フロー制御部１０６と切替部１１５に対して、サーバモードを通知する。
【００１９】
データパケット受信部１０９は、送信装置２００からネットワークを介して伝送されてくるデータパケットを受信する。
パケット判定部１１０は、データパケットが、ＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）が格納されたパケットであるか、それ以外の映像情報が格納されたパケットであるかを判定する。自装置がリアルタイムモードで動作するときには、パケット判定部１１０では、ＰＣＲが格納されたデータパケット又はリアルタイム映像配信装置である送信装置２００から伝送されてきた、映像信号が格納されたデータパケットが検出される。パケット判定部１１０は、映像信号が格納されたデータパケットはパケット受信バッファ１１１に書き込み、ＰＣＲデータが格納されたデータパケットはパケットをＰＣＲ制御部１１２に転送する。
【００２０】
ＰＣＲ制御部１１２は、パケット判定部１１０から転送されたパケットからＰＣＲデータを取り出し、各ＰＣＲデータと自装置内のシステムタイムクロック（ＳＴＣ：Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）との差分値を算出する。そして、ＰＣＲ制御部１１２は、その差分値に対応する電圧制御信号を生成し、それをＶＣＸＯ（電圧制御水晶発振器：Ｖｏｌｔａｇｅ Ｃｏｎｔｒｏｌｌｅｄ Ｘｔａｌ Ｏｓｃｉｌｌａｔｏｒ）に供給する。
【００２１】
リアルタイムモード時には、モード判定部１０５が切替部１１５に対してＶＣＸＯ１１３の出力を選択させる。これにより、リアルタイムモード時には、ＶＣＸＯ１１３から発振されるＰＣＲに基づいて電圧制御されたクロックが、動画復号部１１６に供給される。
【００２２】
このようにして、リアルタイムモード時には、動画復号部１１６は、パケット受信バッファ１１１に受信された映像信号パケットを、その符号化時のクロックに同期したクロックで復号し再生することができる。即ち、リアルタイムモード時には、データパケット受信部１０９、パケット判定部１１０、パケット受信バッファ１１１、動画復号部１１６、ＰＣＲ生成部２０６、ＶＣＸＯ１１３、及び切替部１１５からなる部分が、リアルタイム性伝送を行う動作モードでメディア情報を受信する第１の受信部を形成する。
【００２３】
リアルタイムモード時には、上述のように同期再生が可能であるため、パケット受信バッファ１１１の状態に応じてフロー制御を実施する必要はない。このため、リアルタイムモード時には、モード判定部１０５がフロー制御部１０６にリアルタイムモードを通知することにより、フロー制御部１０６は動作しない。
【００２４】
一方、自装置がサーバモードで動作するときには、パケット判定部１１０においては、ＰＣＲデータが格納されたパケットは無視され破棄されるため、データパケットのみがパケット受信バッファ１１１に書き込まれることになる。このデータパケットには、ファイル配信サーバである送信装置２００から伝送されてきた映像ファイルが格納されている。
【００２５】
サーバモード時には、モード判定部１０５が切替部１１５に対して自走ＯＳＣ１１４の出力を選択させる。自走ＯＳＣ（ＯＳＣ：OSCillator／発振器）１１４は、送信側のタイミングとは関係なくシステムタイムクロックを発振する。これにより、サーバモード時には、自走ＯＳＣ１１４から発振されるシステムタイムクロックが、動画復号部１１６に供給される。
【００２６】
この結果、サーバモード時には、動画復号部１１６は、送信装置２００からは独立したタイミングで自走ＯＳＣ１１４にて発振されたシステムタイムクロックに基づいて、パケット受信バッファ１１１に受信された映像ファイルパケットを復号し再生する。
【００２７】
ここで、サーバモード時には、モード判定部１０５が、フロー制御部１０６にサーバモードを通知する。この結果、フロー制御部１０６は、サーバモード時に、再生タイミングと伝送タイミングの差を吸収するために、フロー制御を実施する。
【００２８】
即ち、フロー制御部１０６は、サーバモード時に、パケット受信バッファ１１１に滞留するパケットがバッファサイズを超えそうになると、送信停止／開始要求パケット送信部１０７に第１の指示を出す。この結果、送信停止／開始要求パケット送信部１０７が、通信を行っている送信装置２００に対する送信停止要求パケットを生成し、このパケットが要求パケット送信部１０８を介してネットワークに送出される。この結果、送信装置２００において、映像ファイルが格納されたデータパケットの送出が停止され、受信装置１００で受信されるパケット量が調整される。
【００２９】
逆に、フロー制御部１０６は、サーバモード時に、パケット受信バッファ１１１に滞留するパケットがなくなりそうになると、送信停止／開始要求パケット送信部１０７に第２の指示を出す。この結果、送信停止／開始要求パケット送信部１０７が、通信を行っている送信装置２００に対する送信開始要求パケットを生成し、このパケットが要求パケット送信部１０８を介してネットワークに送出される。この結果、送信装置２００において、映像ファイルが格納されたデータパケットの送出が開始（再開）され、受信装置１００で受信されるパケット量が調整される。
【００３０】
ここで、サーバモード時には、再生タイミングと伝送タイミングの差が大きくなりがちであるため、パケット受信バッファ１１１の容量が増加させられるように制御されてもよい。
【００３１】
以上のようにして、サーバモード時には、データパケット受信部１０９、パケット判定部１１０、パケット受信バッファ１１１、動画復号部１１６、ＰＣＲ生成部２０６、自走ＯＳＣ１１４、切替部１１５、フロー制御部１０６、送信停止／開始要求パケット送信部１０７、及び要求パケット送信部１０８からなる部分が、非リアルタイム性伝送を行う動作モードでメディア情報を受信する第２の受信部を形成する。
【００３２】
次に、図２の送信装置２００において、要求パケット受信部２０１は、ネットワークを介して、受信装置１００（図１）が送出した要求パケットを受信する。
要求パケット解析部２０２は、受信された要求パケットを解析する。
【００３３】
要求パケット解析部２０２は、解析の結果、要求パケットが映像信号又は映像ファイルの配信開始又は配信停止を要求するパケットであるときには、要求応答パケット送信部２０３に対して、要求応答パケットの送出を指示する。要求応答パケット送信部２０３は、上記要求パケットを送信した受信装置１００（図１）に向けて、要求応答パケットを送信する。このとき、要求応答パケット送信部２０３は、配信開始要求に対応する要求応答パケットに、自装置がリアルタイム映像配信装置であるときには、リアルタイムエンコーダであることを示す装置タイプ情報を付加する。逆に、自装置がファイル配信サーバであるときには、要求応答パケット送信部２０３は、配信サーバであることを示す装置タイプ情報を付加する。
【００３４】
また、要求パケット解析部２０２は、解析の結果、要求パケットが映像信号又は映像ファイルの配信開始又は配信停止を要求するパケットであるときには、動画送信部２０４に対して、映像信号又は映像ファイルの配信の開始又は停止を指示する。
【００３５】
自走ＯＳＣ２０５は、システムタイムクロックを発振する。
動画送信部２０４は、配信開始後配信停止まで、自装置がリアルタイム映像配信装置なら、自走ＯＳＣ２０５が生成するクロックに基づいて、映像信号をリアルタイムで符号化して映像信号パケットを生成し、パケット送信バッファ２０７に順次書き込む。一方、自装置がファイル配信サーバなら、動画送信部２０４は、配信開始後配信停止まで、映像ファイルを特には図示しない記憶装置から読出し、映像ファイルパケットを生成し、パケット送信バッファ２０７に順次書き込む。
【００３６】
更に、自装置がリアルタイム映像配信装置なら、ＰＣＲ生成部２０６が、配信開始後配信停止まで、以下の動作を実行する。即ちＰＣＲ生成部２０６は、自走ＯＳＣ２０５が生成するクロックに基づいて、動画送信部２０４にてリアルタイム配信される映像信号のクロックに対応するＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）データが格納されたパケットを生成する。そして、ＰＣＲ生成部２０６は、そのパケットをパケット送信バッファ２０７に書き込む。
【００３７】
自装置がファイル配信サーバであるときには、ＰＣＲ生成部２０６は設置されない。
パケット送信バッファ２０７は、書き込まれたデータパケットを順次データパケット送信部２０８に転送する。データパケット送信部２０８は、データパケットを、受信装置１００（図１）に向けてネットワークに送出する。
【００３８】
ここで、自装置がファイル配信サーバである場合において、要求パケット解析部２０２は、解析の結果、要求パケットが送信停止要求パケットであるときには、パケット送信バッファ２０７に対して、データパケットの送出の停止を指示する。また、要求パケット解析部２０２は、解析の結果、要求パケットが送信開始要求パケットであるときには、パケット送信バッファ２０７に対して、データパケットの送出の開始（再開）を指示する。このようにしてフロー制御が実施される。
【００３９】
以上の構成を有する受信装置及び送信装置の第１の実施形態の動作について、以下に詳細に説明する。
図３は、図１の受信装置１００の制御動作を示す動作フローチャートである。この動作フローチャートの制御動作は、受信装置１００内の特には図示しないプロセッサが特には図示しないメモリに記憶された制御プログラムを実行する動作として実現される。
【００４０】
まず、ユーザによって指定されたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスに対して、配信開始を要求する要求パケットが送信される（ステップＳ３０１）。この動作は、前述したように、図１の要求パケット生成部１０１及び要求パケット送信部１０２によって実行される。図５は、受信装置及び送信装置の第１の実施形態における要求パケットのデータ構成例を示す図である。「ＴＹＰＥ」情報は、その値が「０ｘ０００１」であるときは配信要求を、「０ｘ０００２」であるときは配信停止を指示する。「ＰＯＲＴ１」情報及び「ＰＯＲＴ２」情報は、送受信アプリケーションのＴＣＰ／ＩＰポート番号を指定する。「ＩＤ」情報は、コネクションの識別子を指定する。「ＡＢＩＬＩＴＹ」情報は、伝送能力を示す値を指定する。「ＰＵＬＬＲＡＴＥ」情報は伝送される映像信号又は映像ファイルの品質情報（サンプルレート）を指定する。「ＳＳＲＣ」情報は、セッションを識別するために要求される値である。「ＰＲＯＧＲＡＭ」情報は、番組情報を指定する。ステップＳ３０１では、「ＴＹＰＥ」情報として配信要求を示す値「０ｘ０００１」が指定されることになる。
【００４１】
その後、指定ＩＰアドレスの送信装置２００からの要求応答パケットを３０秒間待った後（ステップＳ３０１→Ｓ３０２→Ｓ３０１の繰返し）、要求応答パケットが受信されたら、要求応答パケットにて指定されている要求応答として、リアルタイムエンコーダと配信サーバのどちらの装置タイプ情報が指定されているかが判定される（ステップＳ３０３）。この判定結果に基づいて、リアルタイムモードとサーバモードが切り替えられる（ステップＳ３０４）。以上の動作は、前述したように、図１の要求応答パケット受信部１０３、要求応答解析部１０４、及びモード判定部１０５によって実行される。
【００４２】
そして、リアルタイムモードが設定されたときには、ＰＣＲ制御に基づくデータ受信が実行される（ステップＳ３０５→Ｓ３０６）。この動作は、前述したように、図１の動画復号部１１６が、データパケット受信部１０９、パケット判定部１１０、及びパケット受信バッファ１１１を介して受信したリアルタイムの映像信号を受信する動作である。このとき、動画復号部１１６は、ＰＣＲ生成部２０６及びＶＣＸＯ１１３を介して生成される同期クロックに従って、復号、再生動作を実行する。
【００４３】
一方、サーバモードが設定されたときには、フロー制御に基づくデータ受信が実行される（ステップＳ３０５→Ｓ３０７）。この動作は、前述したように、図１の動画復号部１１６が、データパケット受信部１０９、パケット判定部１１０、及びパケット受信バッファ１１１を介して受信した映像ファイルを受信する動作である。動画復号部１１６は、自走ＯＳＣ１１４が生成するシステムタイムクロックに従って、復号、再生動作を実行する。
【００４４】
このとき、図１のフロー制御部１０６は、パケット受信バッファ１１１を逐次チェックし（ステップＳ３０８）、滞留状態に異常がなければそのままデータ受信を続行する（ステップＳ３０８→Ｓ３０７）。
一方、前述したように、フロー制御部１０６は、パケット受信バッファ１１１に滞留するパケットがバッファサイズを超えそうになると（バッファオーバ）、図１の送信停止／開始要求パケット送信部１０７に第１の指示を出す。これを受けて、送信停止／開始要求パケット送信部１０７が、指定ＩＰアドレスの送信装置２００（図２）に対する送信停止要求パケットを生成し、このパケットが図１の要求パケット送信部１０８を介してネットワークに送出される（ステップＳ３０８→Ｓ３０９）。この結果、送信装置２００において、映像ファイルが格納されたデータパケットの送出が停止され、受信装置１００で受信されるパケット量が調整される。
【００４５】
逆に、前述したように、フロー制御部１０６は、パケット受信バッファ１１１に滞留するパケットがなくなりそうになると（バッファエンプティ）、送信停止／開始要求パケット送信部１０７に第２の指示を出す。これを受けて、送信停止／開始要求パケット送信部１０７が、指定ＩＰアドレスの送信装置２００に対する送信開始要求パケットを生成し、このパケットが要求パケット送信部１０８を介してネットワークに送出される（ステップＳ３０８→Ｓ３１０）。この結果、送信装置２００において、映像ファイルが格納されたデータパケットの送出が開始（再開）され、受信装置１００で受信されるパケット量が調整される。
【００４６】
図４は、図２の送信装置２００の制御動作を示す動作フローチャートである。この動作フローチャートの制御動作は、送信装置２００内の特には図示しないプロセッサが特には図示しないメモリに記憶された制御プログラムを実行する動作として実現される。
【００４７】
まず、送信装置２００は、要求パケットの受信待ちの状態にある（ステップＳ４０１の判定の繰返し）。
要求パケットが受信されると、要求パケットの内容が解析される（ステップＳ４０２）。この動作は、前述したように、図２の要求パケット受信部２０１及び要求パケット解析部２０２によって実行される。
【００４８】
上記解析の結果、要求パケットが映像信号又は映像ファイルの配信開始を要求するパケットであるときには、上記要求パケットを送信したＩＰアドレスの受信装置１００（図１）に向けて、要求応答パケットが送信される（ステップＳ４０３）。このとき、自装置がリアルタイム映像配信装置であるときには、要求応答パケットに、リアルタイムエンコーダであることを示す装置タイプ情報が付加される。逆に、自装置がファイル配信サーバであるときには、要求応答パケットに、配信サーバであることを示す装置タイプ情報が付加される。
【００４９】
図６は、受信装置及び送信装置の第１の実施形態における要求応答パケットのデータ構成例を示す図である。「ＰＯＲＴ１」、「ＰＯＲＴ２」、「ＩＤ」、「ＡＢＩＬＩＴＹ」、「ＰＵＬＬＲＡＴＥ」の各情報は、要求パケットに付加されるものと同じである（図５参照）。「ＴＹＰＥ」情報は、配信要求に対するレスポンス値「０ｘ０１０１」又は停止要求に対するレスポンス値「０ｘ０１０２」を指示する。「ＥＲＲＯＲＣＯＤＥ」情報は、正常状態を示す値「０ｘ００００」又は異常、配信不可状態を示す値「０ｘ０００１」を指定する。「ＥＱＰＴＹＰＥ」情報は、装置タイプとして、リアルタイムエンコーダを示す値「０ｘ００００」又は配信サーバを示す値「０ｘ０００１」を指定する。この「ＥＱＰＴＹＰＥ」情報によって、受信装置１００（図１）からの要求パケットに対して、送信装置２００（図２）は、自装置の装置タイプを「ＥＱＰＴＹＰＥ」情報によって通知することができる。そして、受信装置１００は、この情報に基づいて、自装置の動作を、リアルタイムモードとサーバモードとで切り替えることが可能となる。図６において、「Ｒｓｖ．３」、「Ｒｓｖ．４」、「Ｒｓｖ．５」の各情報は、将来のために予約されている情報である。
【００５０】
その後、図２の要求パケット解析部２０２から動画送信部２０４に対して、データパケットの送信開始が指示され、送信が開始される（ステップＳ４０４）。これ以降は、要求パケットが受信されたか否かが判定されながら（ステップＳ４０５の判定の繰返し）、データパケットの送信が継続される。前述したように、データパケットの送信動作は、図２の動画送信部２０４、パケット送信バッファ２０７、及びデータパケット送信部２０８によって実行され、要求パケットの受信動作は、図２の要求パケット受信部２０１によって実行される。
【００５１】
上述の送信動作において、要求パケットが受信されると、その要求パケットの内容が解析され、その内容が判定される（ステップＳ４０５→Ｓ４０６→Ｓ４０７）。この動作は、図２の要求パケット受信部２０１及び要求パケット解析部２０２によって実行される。
【００５２】
この判定の結果が、要求パケットが配信停止の要求パケットである場合には、図２の要求パケット解析部２０２から動画送信部２０４に対して配信動作の停止が指示され、配信開始の要求パケット待ちの処理に戻る（ステップＳ４０６→Ｓ４０８→Ｓ４０１）。
【００５３】
配信停止の要求パケットでない場合には、自装置がリアルタイム映像配信装置なら、ステップＳ４０７は実行されずに、ステップＳ４０５の判定処理に戻る。
一方、配信停止の要求パケットでない場合であって、自装置がファイル配信サーバならば、ステップＳ４０７のフロー制御処理が実行される。即ち、まず要求パケットが送信停止要求パケットであるか送信開始要求パケットであるかが判定される（ステップＳ４０７−１）。送信停止要求パケットが受信された場合には、図２の要求パケット解析部２０２からパケット送信バッファ２０７に対して、データパケットの送出の停止が指示される（ステップＳ４０７−１→Ｓ４０７−２）。その後、ステップＳ４０５の判定処理に戻る。
また、送信開始要求パケットが受信された場合には、要求パケット解析部２０２からパケット送信バッファ２０７に対して、データパケットの送出の開始（再開）が指示される（ステップＳ４０７−１→Ｓ４０７−３）。その後、ステップＳ４０５の判定処理に戻る。このようにしてフロー制御が実施される。
【００５４】
以上の受信装置と送信装置の第１の実施形態の動作をまとめると、図７の動作シーケンス図で示されるようになる。
自装置がリアルタイム映像配信装置であれば、図７（ａ）に示されるように、受信装置１００からの映像配信要求に対して（図３のステップＳ３０１）、送信装置２００は、リアルタイムエンコーダの情報が付加された要求応答を返信する（図４のステップＳ４０３）。これを受けて、受信装置１００は、自装置の状態をリアルタイムモードに変更する（図３のステップＳ３０４）。その後、送信装置２００から受信装置１００にリアルタイム映像信号が伝送される（図４のステップＳ４０４、図３のステップＳ３０６）。
【００５５】
一方、自装置がファイル配信サーバであれば、図７（ｂ）に示されるように、受信装置１００からの映像配信要求（図３のステップＳ３０１）に対して、送信装置２００は、配信サーバの情報が付加された要求応答を返信する（図４のステップＳ４０３）。これを受けて、受信装置１００は、自装置の状態をサーバモードに変更する（図３のステップＳ３０４）。その後、送信装置２００から受信装置１００に映像ファイルが伝送される（図４のステップＳ４０４、図３のステップＳ３０７）。
【００５６】
以上のようにして、受信装置と送信装置の第１の実施形態によれば、受信装置１００からの配信開始の要求パケットに対して、送信装置２００は、自装置の装置タイプを「ＥＱＰＴＹＰＥ」情報によって通知することができ、受信装置１００は、この情報に基づいて、自装置の動作を、リアルタイムモードとサーバモードとで切り替えることが可能となる。
【００５７】
次に、受信装置と送信装置の第２の実施形態について説明する。
まず、受信装置の第２の実施形態の構成は、図１に示される第１の実施形態による受信装置１００の構成と同じである。
【００５８】
ただし、受信装置１００において、要求パケット生成部１０１は、まず、リアルタイムモードの配信要求モード情報が設定された要求パケットを送信装置に向けて送信する。これに対して、送信装置からリアルタイムエンコーダのモードが設定され正常を示す要求応答パケットが返信されてきたなら、受信装置１００はそのままリアルタイムモードで動作する。一方、送信装置から配信サーバのモードが設定され異常を示す要求応答パケットが返信されてきたなら、要求パケット生成部１０１は、サーバモードの配信要求モード情報が設定された要求パケットを再度送信装置に向けて送信する。これに対して、送信装置から配信サーバのモードがされ正常を示す要求応答パケットが返信されてきたなら、受信装置１００はサーバモードで動作する。
【００５９】
図８の８００は、送信装置の第２の実施形態の構成図である。
図８において、図２の第２の実施形態における送信装置２００の構成の場合と同じ番号が付された部分は、図２の場合と同じ処理を実行する。
【００６０】
図８の構成が図２の構成と異なる点は、要求モード判定部８０１が、要求パケット解析部２０２が受信した配信開始の要求パケットに、リアルタイムモードとサーバモードのどちらが設定されているかを判定する点である。
【００６１】
自装置がリアルタイム映像配信装置である場合において、配信開始の要求パケットにリアルタイムモードが設定されていれば、要求モード判定部８０１は要求応答パケット送信部２０３に対して、正常を示す要求応答パケットの返信を指示する。逆に、配信開始の要求パケットにサーバモードが設定されていれば、要求モード判定部８０１は要求応答パケット送信部２０３に対して、異常を示す要求応答パケットの返信を指示する。なお、要求応答パケットには同時に、リアルタイムエンコーダを示す装置タイプが付加される。
【００６２】
一方、自装置がファイル配信サーバである場合において、配信開始の要求パケットにリアルタイムモードが設定されていれば、要求モード判定部８０１は要求応答パケット送信部２０３に対して、異常を示す要求応答パケットの返信を指示する。逆に、配信開始の要求パケットにサーバモードが設定されていれば、要求モード判定部８０１は要求応答パケット送信部２０３に対して、正常を示す要求応答パケットの返信を指示する。なお、要求応答パケットには同時に、配信サーバを示す装置タイプ情報が付加される。
【００６３】
図９は、第２の実施形態における図１の受信装置１００の制御動作を示す動作フローチャートである。この動作フローチャートの制御動作は、受信装置１００内の特には図示しないプロセッサが特には図示しないメモリに記憶された制御プログラムを実行する動作として実現される。
【００６４】
まず、ユーザによって指定されたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスに対して、配信開始を要求する要求パケットが送信される（ステップＳ９０１）。この場合に、要求パケットには、リアルタイムモードを示す配信要求モード情報が付加される。図１１は、受信装置及び送信装置の第２の実施形態における要求パケットのデータ構成例を示す図である。「ＴＹＰＥ」、「ＰＯＲＴ１」、「ＰＯＲＴ２」、「ＩＤ」、「ＡＢＩＬＩＴＹ」、「ＰＵＬＬＲＡＴＥ」の各情報は、図５に示される第１の実施形態の場合の要求パケットのデータ構成と同じである（図５参照）。「ＲＥＣＥＩＶＥＴＹＰＥ」情報は、上述の配信要求モード情報を指定する。「ＥＱＰＴＹＰＥ」情報は、値０として、リアルタイム配信、サーバ配信の両方に対応したデコーダであることを指定する。ステップＳ９０１では、「ＴＹＰＥ」情報として配信要求を示す値「０ｘ０００１」が指定され、「ＲＥＣＥＩＶＥＴＹＰＥ」情報としてリアルタイムモードを示す値「０」が指定されることになる。この動作は、図１の要求パケット生成部１０１及び要求パケット送信部１０２によって実行される。
【００６５】
その後、指定ＩＰアドレスの送信装置２００からの要求応答パケットを３０秒間待った後（ステップＳ９０１→Ｓ９０２→Ｓ９０１の繰返し）、要求応答パケットが受信されたら、要求応答パケットにて指定されている要求応答として、リアルタイムエンコーダの装置タイプ情報が指定されているかが判定される（ステップＳ９０３）。
【００６６】
この判定がＹＥＳならば、図１のモード判定部１０５は、切替部１１５及びフロー制御部１０６に、リアルタイムモードを設定する（ステップＳ９０４）。このようにしてリアルタイムモードが設定されたときには、ＰＣＲ制御に基づくデータ受信が実行される（ステップＳ３０６）。この動作は、第１の実施形態における図３のステップＳ３０６の動作と同様である。
【００６７】
一方、ステップＳ９０３の判定がＮＯならば、モード判定部１０５は要求パケット生成部１０１にその旨を通知する。これを受けて要求パケット生成部１０１は、指定ＩＰアドレスに対して、再度配信開始を要求する要求パケットを送信する（ステップＳ９０５）。この場合に、要求パケットには、配信要求モード情報即ち「ＲＥＣＥＩＶＥＴＹＰＥ」情報として、サーバモードを示す値「１」が指定される。
【００６８】
その後、指定ＩＰアドレスの送信装置２００からの要求応答パケットを３０秒間待った後（ステップＳ９０５→Ｓ９０６→Ｓ９０５の繰返し）、要求応答パケットが受信されたら、図１のモード判定部１０５は、切替部１１５及びフロー制御部１０６に、サーバモードを設定する（ステップＳ９０７）。このようにしてサーバモードが設定されたときには、フロー制御に基づくデータ受信が実行される（ステップＳ３０７〜Ｓ３１０）。この動作は、第１の実施形態における図３のステップＳ３０７〜Ｓ３１０の動作と同様である。
【００６９】
図１２は、図８の送信装置８００の制御動作を示す動作フローチャートである。この動作フローチャートの制御動作は、送信装置８００内の特には図示しないプロセッサが特には図示しないメモリに記憶された制御プログラムを実行する動作として実現される。
【００７０】
まず、ステップＳ４０１とＳ４０２の処理は、第１の実施形態における図４のステップＳ４０１とＳ４０２の処理と同じである。
即ちまず、送信装置８００は、要求パケットの受信待ちの状態にある（ステップＳ４０１の判定の繰返し）。
【００７１】
要求パケットが受信されると、要求パケットの内容が解析される（ステップＳ４０２）。この動作は、図８の要求パケット受信部２０１及び要求パケット解析部２０２によって実行される。
【００７２】
上記解析の結果、要求パケットが映像信号又は映像ファイルの配信開始を要求するパケットであるときには、その要求パケットに設定されている配信要求モード情報が、自装置のモードと一致するか否かが判定される（ステップＳ１００１）。この動作は、図８の要求モード判定部８０１によって実行される。
【００７３】
配信開始を要求するパケットが第１回目に受信されときには、図９のステップＳ９０１により、要求パケットには、「ＲＥＣＥＩＶＥＴＹＰＥ」情報としてリアルタイムモードを示す値「０」が指定されている。従って、自装置がリアルタイム映像配信装置であればステップＳ１００１では一致が判定され、自装置がファイル配信サーバであればステップＳ１００１では不一致が判定される。
【００７４】
また、自装置がファイル配信サーバであれば、ステップＳ１００１での不一致の判定の後、図９のステップＳ９０５により、第２回目の配信開始を要求するパケットが受信される。このときには、図９のステップＳ９０１により、要求パケットには、「ＲＥＣＥＩＶＥＴＹＰＥ」情報としてサーバモードを示す値「１」が指定されている。従って、ステップＳ１００１では一致が判定される。
【００７５】
自装置がファイル配信サーバであって、配信開始を要求するパケットが第１回目に受信されることによりステップＳ１００１で不一致が判定されたときには、以下の動作が実行される。即ち、要求モード判定部８０１は要求応答パケット送信部２０３に対して、異常を示しかつ配信サーバを示す装置タイプ情報が付加された要求応答パケットの返信を指示する（ステップＳ１００２）。要求応答パケットのデータ構成例は、第１の実施形態における図６に示されるデータ構成例と同じである。ステップＳ１００２では、「ＴＹＰＥ」情報として配信要求レスポンスを示す値「０ｘ０１０１」が指定され、「ＥＲＲＯＲＣＯＤＥ」情報として異常、配信不可を示す値「０ｘ０００１」が指定される。また、「ＥＱＰＴＹＰＥ」情報として配信サーバを示す値「０ｘ０００１」が指定されることになる。その後、配信開始の要求パケット待ちの処理に戻る（ステップＳ１００２→Ｓ４０１）。
【００７６】
自装置がファイル配信サーバであって、配信開始を要求するパケットが第２回目に受信された場合、又は自装置がリアルタイム映像配信装置１４０３であって、配信開始を要求するパケットが第１回目に受信された場合には、ステップＳ１００１では一致が判定される。この場合には、要求モード判定部８０１は要求応答パケット送信部２０３に対して、正常を示しかつ自分のモード（配信サーバ又はリアルタイムエンコーダ）を示す装置タイプ情報が付加された要求応答パケットの返信を指示する（ステップＳ１００３）。即ち、図６のデータ構成例において、「ＴＹＰＥ」情報として配信要求レスポンスを示す値「０ｘ０１０１」が指定され、「ＥＲＲＯＲＣＯＤＥ」情報として正常を示す値「０ｘ００００」が指定される。また、「ＥＱＰＴＹＰＥ」情報として配信サーバを示す値「０ｘ０００１」（自装置がファイル配信サーバである場合）又はリアルタイムエンコーダを示す値「０ｘ００００」（自装置がリアルタイム映像配信装置である場合）が指定されることになる。
【００７７】
その後、図２の要求パケット解析部２０２から動画送信部２０４に対して、データパケットの送信開始が指示され、送信が開始される（ステップＳ４０４）。これ以降の動作は、第１の実施形態における図４のステップＳ４０５からステップＳ４０８までの一連の制御動作と同じである。
【００７８】
以上の受信装置と送信装置の第２の実施形態の動作をまとめると、図１２の動作シーケンス図で示されるようになる。
自装置がリアルタイム映像配信装置なら、図１２（ａ）に示されるように、受信装置１００からのリアルタイムモードが指定された映像配信要求に対し（図９のステップＳ９０１）、送信装置８００ではモード一致が判定される（図１０のステップＳ１００１）。この結果、送信装置８００は、リアルタイムエンコーダの情報が付加された正常を示す要求応答を返信する（図１０のステップＳ１００３）。これを受けて、受信装置１００は、自装置の状態をリアルタイムモードに設定する（図９のステップ９０４）。その後、送信装置８００から受信装置１００にリアルタイム映像信号が伝送される（図１０のステップＳ４０４、図３のステップＳ３０６）。
【００７９】
一方、自装置がファイル配信サーバなら、図１２（ｂ）に示されるように、受信装置１００からのリアルタイムモードが指定された映像配信要求（図３のステップＳ９０１）に対し、送信装置８００では、モード不一致が判定される（図１０のステップＳ１００１）。この結果、送信装置８００は、配信サーバの情報が付加された異常を示す要求応答を返信する（図１０のステップＳ１００２）。これを受けて、受信装置１００は、モード不一致を検出することにより（図９のステップＳ９０３）、今度はサーバモードが指定された映像配信要求（図９のステップＳ９０５）を送信する。この結果、ｌ送信装置８００ではモード一致が判定される（図１０のステップＳ１００１）。そして、送信装置８００は、配信サーバの情報が付加された正常を示す要求応答を返信する（図１０のステップＳ１００３）。これを受けて、受信装置１００は、自装置の状態をサーバモードに設定する（図９のステップ９０７）。その後、送信装置８００から受信装置１００に映像ファイルが伝送される（図１０のステップＳ４０４、図９のステップＳ３０７）。
【００８０】
以上のようにして、受信装置と送信装置の第２の実施形態によれば、受信装置１００から送信装置８００に対して、受信装置１００が期待する配信要求モードを、「ＲＥＣＥＩＶＥＴＹＰＥ」情報によって明示的に通知することができる。
【００８１】
以上説明しようにして、受信装置と送信装置の第１又は第２の実施形態によれば、監視用のリアルタイム映像配信装置とファイル配信サーバの混在環境において、各装置専用の受信装置を用意する必要がなくなり、コストダウンが可能となる。
【００８２】
そして、上記各実施形態による受信装置により、配信元を意識せずにシームレスに映像受信を行うことが可能となる。
なお、上記各実施形態では、映像信号を対象とした例について説明したが、開示した技術は、映像信号以外にも、音声信号等の様々なメディア信号に対して適用可能である。
【符号の説明】
【００８３】
１０１ 要求パケット生成部
１０２、１０８ 要求パケット送信部
１０３ 要求応答パケット受信部
１０４ 要求応答解析部
１０５ モード判定部
１０６ フロー制御部
１０７ 送信停止／開始要求パケット送信部１０７
１０９ データパケット受信部
１１０ パケット判定部
１１１ パケット受信バッファ
１１２ ＰＣＲ制御部
１１３ ＶＣＸＯ
１１４ 自走ＯＳＣ
１１５ 切替部
１１６ 動画復号部
２０１ 要求パケット受信部
２０２ 要求パケット解析部
２０３ 要求応答パケット送信部
２０４ 動画送信部
２０５ 自走ＯＳＣ
２０６ ＰＣＲ生成部
２０７ パケット送信バッファ
２０８ データパケット送信部
８０１ 要求モード判定部
【技術分野】
【０００１】
開示する技術は、パケットネットワーク上でのメディア情報の伝送において、リアルタイム性伝送と非リアルタイム性伝送とが混在する伝送技術に関する。
【背景技術】
【０００２】
ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）ネットワーク等のパケットネットワーク上で、送信装置と受信装置が、映像や音声等のメディア情報の通信を行う場合、リアルタイム性伝送と非リアルタイム性伝送とが混在する場合がある。
【０００３】
リアルタイム性伝送では、例えば図１３に示されるように、監視カメラ１３０５で得られる映像信号が、リアルタイム映像配信装置１３０３で符号化され、リアルタイムの動画パケットとして、リアルタイム映像受信装置１３０１に伝送されて復号、再生される。リアルタイム映像受信装置１３０１で復号、再生される映像信号のクロックを、リアルタイム映像配信装置１３０３での符号化時のクロックに同期させるために、例えばＰＣＲを使用した方式が採用される。この方式では、伝送される動画パケットにＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）と呼ばれるクロック同期用パケットが多重される。復号側では、受信されたＰＣＲデータと受信時の復号器側のシステムタイムクロック（ＳＴＣ：Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）との差分が算出される。そして、この差分値によって電圧制御水晶発振器ＶＣＸＯ（Ｖｏｌｔａｇｅ Ｃｏｎｔｒｏｌｌｅｄ Ｘｔａｌ Ｏｓｃｉｌｌａｔｏｒ）が制御されて、再生クロックが生成される。即ち、リアルタイム性伝送では、リアルタイム映像配信装置１３０３（エンコーダ）とリアルタイム映像受信装置１３０１（デコーダ）のクロックが同期させられることにより、リアルタイム映像受信装置１３０１側のパケット受信バッファのサイズが極力小さくされて映像の遅延が極力回避される。
【０００４】
一方、非リアルタイム性伝送では、例えば図１３に示されるように、サーバ配信用映像受信装置１３０２からの要求に基づき、ファイル配信サーバ１３０４内の記憶装置に蓄積された符号化された映像信号ファイルが読み出されてパケット伝送される。サーバ配信用映像受信装置１３０２は、パケット伝送されてくる映像信号ファイルを、自装置内のシステムタイムクロックに基づいて復号し再生する。非リアルタイム性伝送では、映像信号ファイルが符号化されたときのタイミングと全く同じタイミングで伝送を行うことは技術的に困難である。このため、サーバ配信用映像受信装置１３０２は、再生タイミングと伝送タイミングの差を吸収するために、フロー制御を実施する。フロー制御では、パケット受信バッファに滞留するパケットがバッファサイズを超えそうになると、サーバ配信用映像受信装置１３０２からファイル配信サーバ１３０４に送信停止要求パケットが送信され、ファイル配信サーバ１３０４が映像信号ファイルの伝送を停止する。逆に、パケット受信バッファに滞留するパケットがなくなりそうになると、サーバ配信用映像受信装置１３０２からファイル配信サーバ１３０４に送信開始要求パケットが送信され、ファイル配信サーバ１３０４が映像信号ファイルの伝送を開始（再開）する。
【０００５】
ここで、図１３に示されるリアルタイム映像受信装置１３０１は、通常はリアルタイム映像配信装置１３０３からのリアルタイム性伝送による映像信号を受信するが、装置の有効活用のために、サーバ配信用映像受信装置１３０２からの非リアルタイム性伝送による映像信号ファイルも受信できるようにしたいという要請がある。
【０００６】
このような混在受信を可能とするためには、リアルタイム映像受信装置１３０１が、非リアルタイム性伝送のためのフロー制御機能を実装する必要がある。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかし、リアルタイム映像受信装置１３０１が、ファイル配信サーバ１３０４からの非リアルタイム性伝送による映像信号ファイルを受信しようとした場合、リアルタイム性伝送と非リアルタイム性伝送を識別するような従来技術はなかった。このため、従来は、リアルタイム映像受信装置１３０１にフロー制御機能を実装することができなかった。
【０００８】
このため、リアルタイム映像受信装置１３０１が、図１３に示されるように、ファイル配信サーバ１３０４からの非リアルタイム性伝送による映像信号ファイルをフロー制御無しで受信した場合、再生タイミングと伝送タイミングとの差が拡大する可能性が高い。この結果、リアルタイム映像受信装置１３０１のパケット受信バッファにおいて、パケットのオーバーフロー又はアンダーフローが発生してしまい、映像信号ファイルを正常に受信できなくなってしまうという問題点を有していた。
【０００９】
そこで、本発明の１つの側面では、リアルタイム性伝送によるメディア情報と非リアルタイム性伝送によるメディア情報とを識別して受信可能とすることを目的とする。
【課題を解決するための手段】
【００１０】
態様の一例は、パケットネットワーク上での送信装置から受信装置へのメディア配信を切り替えるメディア配信切替え方法として実現され、以下の構成を有する。
まず、受信装置から送信装置にメディア情報の配信を要求する要求パケットが送信される。
【００１１】
次に、要求パケットに応答して送信装置から受信装置に、その送信装置がリアルタイム性伝送と非リアルタイム性伝送のどちらの伝送を行う装置タイプであるかを示す装置タイプ情報を付加した要求応答パケットが返信される。
【００１２】
そして、受信装置において、送信装置から受信した要求応答パケットに付加されている装置タイプ情報に基づいて、リアルタイム性伝送を行う動作モードと非リアルタイム性伝送を行う動作モードとが切り替えられて受信動作が実行される。
【発明の効果】
【００１３】
リアルタイム性伝送を実行する送信装置と非リアルタイム性伝送を時刻する送信装置とが混在するような環境において、各送信装置専用の受信装置を用意する必要がなくなり、コストダウンが可能となる。
【００１４】
配信元を意識せずにシームレスにメディア情報を受信可能な受信装置を実現することが可能となる。
【図面の簡単な説明】
【００１５】
【図１】受信装置の第１の実施形態の構成図である。
【図２】送信装置の第１の実施形態の構成図である。
【図３】受信装置の第１の実施形態の制御動作を示す動作フローチャートである。
【図４】送信装置の第１の実施形態の制御動作を示す動作フローチャートである。
【図５】受信装置及び送信装置の第１の実施形態における要求パケットのデータ構成例を示す図である。
【図６】受信装置及び送信装置の第１の実施形態における要求応答パケットのデータ構成例を示す図である。
【図７】受信装置及び送信装置の第１の実施形態の動作シーケンス図である。
【図８】送信装置の第２の実施形態の構成図である。
【図９】受信装置の第２の実施形態の制御動作を示す動作フローチャートである。
【図１０】送信装置の第２の実施形態の制御動作を示す動作フローチャートである。
【図１１】受信装置及び送信装置の第２の実施形態における要求パケットのデータ構成例を示す図である。
【図１２】受信装置及び送信装置の第２の実施形態の動作シーケンス図である。
【図１３】従来技術の説明図である。
【発明を実施するための形態】
【００１６】
以下、各実施形態について図面を参照しながら詳細に説明する。
図１の１００は、非同期かつ品質保証なしのパケットネットワーク上で、リアルタイム性伝送による映像信号と非リアルタイム性伝送による映像ファイルとを識別して受信可能な受信装置の第１の実施形態の構成図である。図２の２００は、同じく送信装置の第１の実施形態の構成図である。受信装置１００は図１３のリアルタイム映像受信装置１３０１に対応し、送信装置２００は図１３のリアルタイム映像配信装置１３０３又はファイル配信サーバ１３０４に対応する。
【００１７】
図１の受信装置１００において、要求パケット生成部１０１は、送信装置２００に対して、映像信号又は映像ファイルの配信開始又は配信停止を指示する要求パケットを生成する。要求パケット送信部１０２は、要求パケット生成部１０１が生成した要求パケットを、送信装置２００に向けて特には図示しないネットワークに送信する。
【００１８】
要求応答パケット受信部１０３は、ネットワークから自装置が送信した要求パケットに対する応答パケットである要求応答パケットを受信する。要求応答解析部１０４は、要求応答パケット受信部１０３にて受信された要求応答パケットにて指定されている要求応答の内容を解析する。モード判定部１０５は、要求応答にリアルタイムエンコーダと配信サーバのどちらの装置タイプ情報が指定されているかを判定する。そして、モード判定部１０５は、要求応答にリアルタイムエンコーダが指定されているときには、フロー制御部１０６と切替部１１５に対して、リアルタイムモードを通知する。モード判定部１０５は、要求応答に配信サーバが指定されているときには、フロー制御部１０６と切替部１１５に対して、サーバモードを通知する。
【００１９】
データパケット受信部１０９は、送信装置２００からネットワークを介して伝送されてくるデータパケットを受信する。
パケット判定部１１０は、データパケットが、ＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）が格納されたパケットであるか、それ以外の映像情報が格納されたパケットであるかを判定する。自装置がリアルタイムモードで動作するときには、パケット判定部１１０では、ＰＣＲが格納されたデータパケット又はリアルタイム映像配信装置である送信装置２００から伝送されてきた、映像信号が格納されたデータパケットが検出される。パケット判定部１１０は、映像信号が格納されたデータパケットはパケット受信バッファ１１１に書き込み、ＰＣＲデータが格納されたデータパケットはパケットをＰＣＲ制御部１１２に転送する。
【００２０】
ＰＣＲ制御部１１２は、パケット判定部１１０から転送されたパケットからＰＣＲデータを取り出し、各ＰＣＲデータと自装置内のシステムタイムクロック（ＳＴＣ：Ｓｙｓｔｅｍ Ｔｉｍｅ Ｃｌｏｃｋ）との差分値を算出する。そして、ＰＣＲ制御部１１２は、その差分値に対応する電圧制御信号を生成し、それをＶＣＸＯ（電圧制御水晶発振器：Ｖｏｌｔａｇｅ Ｃｏｎｔｒｏｌｌｅｄ Ｘｔａｌ Ｏｓｃｉｌｌａｔｏｒ）に供給する。
【００２１】
リアルタイムモード時には、モード判定部１０５が切替部１１５に対してＶＣＸＯ１１３の出力を選択させる。これにより、リアルタイムモード時には、ＶＣＸＯ１１３から発振されるＰＣＲに基づいて電圧制御されたクロックが、動画復号部１１６に供給される。
【００２２】
このようにして、リアルタイムモード時には、動画復号部１１６は、パケット受信バッファ１１１に受信された映像信号パケットを、その符号化時のクロックに同期したクロックで復号し再生することができる。即ち、リアルタイムモード時には、データパケット受信部１０９、パケット判定部１１０、パケット受信バッファ１１１、動画復号部１１６、ＰＣＲ生成部２０６、ＶＣＸＯ１１３、及び切替部１１５からなる部分が、リアルタイム性伝送を行う動作モードでメディア情報を受信する第１の受信部を形成する。
【００２３】
リアルタイムモード時には、上述のように同期再生が可能であるため、パケット受信バッファ１１１の状態に応じてフロー制御を実施する必要はない。このため、リアルタイムモード時には、モード判定部１０５がフロー制御部１０６にリアルタイムモードを通知することにより、フロー制御部１０６は動作しない。
【００２４】
一方、自装置がサーバモードで動作するときには、パケット判定部１１０においては、ＰＣＲデータが格納されたパケットは無視され破棄されるため、データパケットのみがパケット受信バッファ１１１に書き込まれることになる。このデータパケットには、ファイル配信サーバである送信装置２００から伝送されてきた映像ファイルが格納されている。
【００２５】
サーバモード時には、モード判定部１０５が切替部１１５に対して自走ＯＳＣ１１４の出力を選択させる。自走ＯＳＣ（ＯＳＣ：OSCillator／発振器）１１４は、送信側のタイミングとは関係なくシステムタイムクロックを発振する。これにより、サーバモード時には、自走ＯＳＣ１１４から発振されるシステムタイムクロックが、動画復号部１１６に供給される。
【００２６】
この結果、サーバモード時には、動画復号部１１６は、送信装置２００からは独立したタイミングで自走ＯＳＣ１１４にて発振されたシステムタイムクロックに基づいて、パケット受信バッファ１１１に受信された映像ファイルパケットを復号し再生する。
【００２７】
ここで、サーバモード時には、モード判定部１０５が、フロー制御部１０６にサーバモードを通知する。この結果、フロー制御部１０６は、サーバモード時に、再生タイミングと伝送タイミングの差を吸収するために、フロー制御を実施する。
【００２８】
即ち、フロー制御部１０６は、サーバモード時に、パケット受信バッファ１１１に滞留するパケットがバッファサイズを超えそうになると、送信停止／開始要求パケット送信部１０７に第１の指示を出す。この結果、送信停止／開始要求パケット送信部１０７が、通信を行っている送信装置２００に対する送信停止要求パケットを生成し、このパケットが要求パケット送信部１０８を介してネットワークに送出される。この結果、送信装置２００において、映像ファイルが格納されたデータパケットの送出が停止され、受信装置１００で受信されるパケット量が調整される。
【００２９】
逆に、フロー制御部１０６は、サーバモード時に、パケット受信バッファ１１１に滞留するパケットがなくなりそうになると、送信停止／開始要求パケット送信部１０７に第２の指示を出す。この結果、送信停止／開始要求パケット送信部１０７が、通信を行っている送信装置２００に対する送信開始要求パケットを生成し、このパケットが要求パケット送信部１０８を介してネットワークに送出される。この結果、送信装置２００において、映像ファイルが格納されたデータパケットの送出が開始（再開）され、受信装置１００で受信されるパケット量が調整される。
【００３０】
ここで、サーバモード時には、再生タイミングと伝送タイミングの差が大きくなりがちであるため、パケット受信バッファ１１１の容量が増加させられるように制御されてもよい。
【００３１】
以上のようにして、サーバモード時には、データパケット受信部１０９、パケット判定部１１０、パケット受信バッファ１１１、動画復号部１１６、ＰＣＲ生成部２０６、自走ＯＳＣ１１４、切替部１１５、フロー制御部１０６、送信停止／開始要求パケット送信部１０７、及び要求パケット送信部１０８からなる部分が、非リアルタイム性伝送を行う動作モードでメディア情報を受信する第２の受信部を形成する。
【００３２】
次に、図２の送信装置２００において、要求パケット受信部２０１は、ネットワークを介して、受信装置１００（図１）が送出した要求パケットを受信する。
要求パケット解析部２０２は、受信された要求パケットを解析する。
【００３３】
要求パケット解析部２０２は、解析の結果、要求パケットが映像信号又は映像ファイルの配信開始又は配信停止を要求するパケットであるときには、要求応答パケット送信部２０３に対して、要求応答パケットの送出を指示する。要求応答パケット送信部２０３は、上記要求パケットを送信した受信装置１００（図１）に向けて、要求応答パケットを送信する。このとき、要求応答パケット送信部２０３は、配信開始要求に対応する要求応答パケットに、自装置がリアルタイム映像配信装置であるときには、リアルタイムエンコーダであることを示す装置タイプ情報を付加する。逆に、自装置がファイル配信サーバであるときには、要求応答パケット送信部２０３は、配信サーバであることを示す装置タイプ情報を付加する。
【００３４】
また、要求パケット解析部２０２は、解析の結果、要求パケットが映像信号又は映像ファイルの配信開始又は配信停止を要求するパケットであるときには、動画送信部２０４に対して、映像信号又は映像ファイルの配信の開始又は停止を指示する。
【００３５】
自走ＯＳＣ２０５は、システムタイムクロックを発振する。
動画送信部２０４は、配信開始後配信停止まで、自装置がリアルタイム映像配信装置なら、自走ＯＳＣ２０５が生成するクロックに基づいて、映像信号をリアルタイムで符号化して映像信号パケットを生成し、パケット送信バッファ２０７に順次書き込む。一方、自装置がファイル配信サーバなら、動画送信部２０４は、配信開始後配信停止まで、映像ファイルを特には図示しない記憶装置から読出し、映像ファイルパケットを生成し、パケット送信バッファ２０７に順次書き込む。
【００３６】
更に、自装置がリアルタイム映像配信装置なら、ＰＣＲ生成部２０６が、配信開始後配信停止まで、以下の動作を実行する。即ちＰＣＲ生成部２０６は、自走ＯＳＣ２０５が生成するクロックに基づいて、動画送信部２０４にてリアルタイム配信される映像信号のクロックに対応するＰＣＲ（Ｐｒｏｇｒａｍ Ｃｌｏｃｋ Ｒｅｆｅｒｅｎｃｅ）データが格納されたパケットを生成する。そして、ＰＣＲ生成部２０６は、そのパケットをパケット送信バッファ２０７に書き込む。
【００３７】
自装置がファイル配信サーバであるときには、ＰＣＲ生成部２０６は設置されない。
パケット送信バッファ２０７は、書き込まれたデータパケットを順次データパケット送信部２０８に転送する。データパケット送信部２０８は、データパケットを、受信装置１００（図１）に向けてネットワークに送出する。
【００３８】
ここで、自装置がファイル配信サーバである場合において、要求パケット解析部２０２は、解析の結果、要求パケットが送信停止要求パケットであるときには、パケット送信バッファ２０７に対して、データパケットの送出の停止を指示する。また、要求パケット解析部２０２は、解析の結果、要求パケットが送信開始要求パケットであるときには、パケット送信バッファ２０７に対して、データパケットの送出の開始（再開）を指示する。このようにしてフロー制御が実施される。
【００３９】
以上の構成を有する受信装置及び送信装置の第１の実施形態の動作について、以下に詳細に説明する。
図３は、図１の受信装置１００の制御動作を示す動作フローチャートである。この動作フローチャートの制御動作は、受信装置１００内の特には図示しないプロセッサが特には図示しないメモリに記憶された制御プログラムを実行する動作として実現される。
【００４０】
まず、ユーザによって指定されたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスに対して、配信開始を要求する要求パケットが送信される（ステップＳ３０１）。この動作は、前述したように、図１の要求パケット生成部１０１及び要求パケット送信部１０２によって実行される。図５は、受信装置及び送信装置の第１の実施形態における要求パケットのデータ構成例を示す図である。「ＴＹＰＥ」情報は、その値が「０ｘ０００１」であるときは配信要求を、「０ｘ０００２」であるときは配信停止を指示する。「ＰＯＲＴ１」情報及び「ＰＯＲＴ２」情報は、送受信アプリケーションのＴＣＰ／ＩＰポート番号を指定する。「ＩＤ」情報は、コネクションの識別子を指定する。「ＡＢＩＬＩＴＹ」情報は、伝送能力を示す値を指定する。「ＰＵＬＬＲＡＴＥ」情報は伝送される映像信号又は映像ファイルの品質情報（サンプルレート）を指定する。「ＳＳＲＣ」情報は、セッションを識別するために要求される値である。「ＰＲＯＧＲＡＭ」情報は、番組情報を指定する。ステップＳ３０１では、「ＴＹＰＥ」情報として配信要求を示す値「０ｘ０００１」が指定されることになる。
【００４１】
その後、指定ＩＰアドレスの送信装置２００からの要求応答パケットを３０秒間待った後（ステップＳ３０１→Ｓ３０２→Ｓ３０１の繰返し）、要求応答パケットが受信されたら、要求応答パケットにて指定されている要求応答として、リアルタイムエンコーダと配信サーバのどちらの装置タイプ情報が指定されているかが判定される（ステップＳ３０３）。この判定結果に基づいて、リアルタイムモードとサーバモードが切り替えられる（ステップＳ３０４）。以上の動作は、前述したように、図１の要求応答パケット受信部１０３、要求応答解析部１０４、及びモード判定部１０５によって実行される。
【００４２】
そして、リアルタイムモードが設定されたときには、ＰＣＲ制御に基づくデータ受信が実行される（ステップＳ３０５→Ｓ３０６）。この動作は、前述したように、図１の動画復号部１１６が、データパケット受信部１０９、パケット判定部１１０、及びパケット受信バッファ１１１を介して受信したリアルタイムの映像信号を受信する動作である。このとき、動画復号部１１６は、ＰＣＲ生成部２０６及びＶＣＸＯ１１３を介して生成される同期クロックに従って、復号、再生動作を実行する。
【００４３】
一方、サーバモードが設定されたときには、フロー制御に基づくデータ受信が実行される（ステップＳ３０５→Ｓ３０７）。この動作は、前述したように、図１の動画復号部１１６が、データパケット受信部１０９、パケット判定部１１０、及びパケット受信バッファ１１１を介して受信した映像ファイルを受信する動作である。動画復号部１１６は、自走ＯＳＣ１１４が生成するシステムタイムクロックに従って、復号、再生動作を実行する。
【００４４】
このとき、図１のフロー制御部１０６は、パケット受信バッファ１１１を逐次チェックし（ステップＳ３０８）、滞留状態に異常がなければそのままデータ受信を続行する（ステップＳ３０８→Ｓ３０７）。
一方、前述したように、フロー制御部１０６は、パケット受信バッファ１１１に滞留するパケットがバッファサイズを超えそうになると（バッファオーバ）、図１の送信停止／開始要求パケット送信部１０７に第１の指示を出す。これを受けて、送信停止／開始要求パケット送信部１０７が、指定ＩＰアドレスの送信装置２００（図２）に対する送信停止要求パケットを生成し、このパケットが図１の要求パケット送信部１０８を介してネットワークに送出される（ステップＳ３０８→Ｓ３０９）。この結果、送信装置２００において、映像ファイルが格納されたデータパケットの送出が停止され、受信装置１００で受信されるパケット量が調整される。
【００４５】
逆に、前述したように、フロー制御部１０６は、パケット受信バッファ１１１に滞留するパケットがなくなりそうになると（バッファエンプティ）、送信停止／開始要求パケット送信部１０７に第２の指示を出す。これを受けて、送信停止／開始要求パケット送信部１０７が、指定ＩＰアドレスの送信装置２００に対する送信開始要求パケットを生成し、このパケットが要求パケット送信部１０８を介してネットワークに送出される（ステップＳ３０８→Ｓ３１０）。この結果、送信装置２００において、映像ファイルが格納されたデータパケットの送出が開始（再開）され、受信装置１００で受信されるパケット量が調整される。
【００４６】
図４は、図２の送信装置２００の制御動作を示す動作フローチャートである。この動作フローチャートの制御動作は、送信装置２００内の特には図示しないプロセッサが特には図示しないメモリに記憶された制御プログラムを実行する動作として実現される。
【００４７】
まず、送信装置２００は、要求パケットの受信待ちの状態にある（ステップＳ４０１の判定の繰返し）。
要求パケットが受信されると、要求パケットの内容が解析される（ステップＳ４０２）。この動作は、前述したように、図２の要求パケット受信部２０１及び要求パケット解析部２０２によって実行される。
【００４８】
上記解析の結果、要求パケットが映像信号又は映像ファイルの配信開始を要求するパケットであるときには、上記要求パケットを送信したＩＰアドレスの受信装置１００（図１）に向けて、要求応答パケットが送信される（ステップＳ４０３）。このとき、自装置がリアルタイム映像配信装置であるときには、要求応答パケットに、リアルタイムエンコーダであることを示す装置タイプ情報が付加される。逆に、自装置がファイル配信サーバであるときには、要求応答パケットに、配信サーバであることを示す装置タイプ情報が付加される。
【００４９】
図６は、受信装置及び送信装置の第１の実施形態における要求応答パケットのデータ構成例を示す図である。「ＰＯＲＴ１」、「ＰＯＲＴ２」、「ＩＤ」、「ＡＢＩＬＩＴＹ」、「ＰＵＬＬＲＡＴＥ」の各情報は、要求パケットに付加されるものと同じである（図５参照）。「ＴＹＰＥ」情報は、配信要求に対するレスポンス値「０ｘ０１０１」又は停止要求に対するレスポンス値「０ｘ０１０２」を指示する。「ＥＲＲＯＲＣＯＤＥ」情報は、正常状態を示す値「０ｘ００００」又は異常、配信不可状態を示す値「０ｘ０００１」を指定する。「ＥＱＰＴＹＰＥ」情報は、装置タイプとして、リアルタイムエンコーダを示す値「０ｘ００００」又は配信サーバを示す値「０ｘ０００１」を指定する。この「ＥＱＰＴＹＰＥ」情報によって、受信装置１００（図１）からの要求パケットに対して、送信装置２００（図２）は、自装置の装置タイプを「ＥＱＰＴＹＰＥ」情報によって通知することができる。そして、受信装置１００は、この情報に基づいて、自装置の動作を、リアルタイムモードとサーバモードとで切り替えることが可能となる。図６において、「Ｒｓｖ．３」、「Ｒｓｖ．４」、「Ｒｓｖ．５」の各情報は、将来のために予約されている情報である。
【００５０】
その後、図２の要求パケット解析部２０２から動画送信部２０４に対して、データパケットの送信開始が指示され、送信が開始される（ステップＳ４０４）。これ以降は、要求パケットが受信されたか否かが判定されながら（ステップＳ４０５の判定の繰返し）、データパケットの送信が継続される。前述したように、データパケットの送信動作は、図２の動画送信部２０４、パケット送信バッファ２０７、及びデータパケット送信部２０８によって実行され、要求パケットの受信動作は、図２の要求パケット受信部２０１によって実行される。
【００５１】
上述の送信動作において、要求パケットが受信されると、その要求パケットの内容が解析され、その内容が判定される（ステップＳ４０５→Ｓ４０６→Ｓ４０７）。この動作は、図２の要求パケット受信部２０１及び要求パケット解析部２０２によって実行される。
【００５２】
この判定の結果が、要求パケットが配信停止の要求パケットである場合には、図２の要求パケット解析部２０２から動画送信部２０４に対して配信動作の停止が指示され、配信開始の要求パケット待ちの処理に戻る（ステップＳ４０６→Ｓ４０８→Ｓ４０１）。
【００５３】
配信停止の要求パケットでない場合には、自装置がリアルタイム映像配信装置なら、ステップＳ４０７は実行されずに、ステップＳ４０５の判定処理に戻る。
一方、配信停止の要求パケットでない場合であって、自装置がファイル配信サーバならば、ステップＳ４０７のフロー制御処理が実行される。即ち、まず要求パケットが送信停止要求パケットであるか送信開始要求パケットであるかが判定される（ステップＳ４０７−１）。送信停止要求パケットが受信された場合には、図２の要求パケット解析部２０２からパケット送信バッファ２０７に対して、データパケットの送出の停止が指示される（ステップＳ４０７−１→Ｓ４０７−２）。その後、ステップＳ４０５の判定処理に戻る。
また、送信開始要求パケットが受信された場合には、要求パケット解析部２０２からパケット送信バッファ２０７に対して、データパケットの送出の開始（再開）が指示される（ステップＳ４０７−１→Ｓ４０７−３）。その後、ステップＳ４０５の判定処理に戻る。このようにしてフロー制御が実施される。
【００５４】
以上の受信装置と送信装置の第１の実施形態の動作をまとめると、図７の動作シーケンス図で示されるようになる。
自装置がリアルタイム映像配信装置であれば、図７（ａ）に示されるように、受信装置１００からの映像配信要求に対して（図３のステップＳ３０１）、送信装置２００は、リアルタイムエンコーダの情報が付加された要求応答を返信する（図４のステップＳ４０３）。これを受けて、受信装置１００は、自装置の状態をリアルタイムモードに変更する（図３のステップＳ３０４）。その後、送信装置２００から受信装置１００にリアルタイム映像信号が伝送される（図４のステップＳ４０４、図３のステップＳ３０６）。
【００５５】
一方、自装置がファイル配信サーバであれば、図７（ｂ）に示されるように、受信装置１００からの映像配信要求（図３のステップＳ３０１）に対して、送信装置２００は、配信サーバの情報が付加された要求応答を返信する（図４のステップＳ４０３）。これを受けて、受信装置１００は、自装置の状態をサーバモードに変更する（図３のステップＳ３０４）。その後、送信装置２００から受信装置１００に映像ファイルが伝送される（図４のステップＳ４０４、図３のステップＳ３０７）。
【００５６】
以上のようにして、受信装置と送信装置の第１の実施形態によれば、受信装置１００からの配信開始の要求パケットに対して、送信装置２００は、自装置の装置タイプを「ＥＱＰＴＹＰＥ」情報によって通知することができ、受信装置１００は、この情報に基づいて、自装置の動作を、リアルタイムモードとサーバモードとで切り替えることが可能となる。
【００５７】
次に、受信装置と送信装置の第２の実施形態について説明する。
まず、受信装置の第２の実施形態の構成は、図１に示される第１の実施形態による受信装置１００の構成と同じである。
【００５８】
ただし、受信装置１００において、要求パケット生成部１０１は、まず、リアルタイムモードの配信要求モード情報が設定された要求パケットを送信装置に向けて送信する。これに対して、送信装置からリアルタイムエンコーダのモードが設定され正常を示す要求応答パケットが返信されてきたなら、受信装置１００はそのままリアルタイムモードで動作する。一方、送信装置から配信サーバのモードが設定され異常を示す要求応答パケットが返信されてきたなら、要求パケット生成部１０１は、サーバモードの配信要求モード情報が設定された要求パケットを再度送信装置に向けて送信する。これに対して、送信装置から配信サーバのモードがされ正常を示す要求応答パケットが返信されてきたなら、受信装置１００はサーバモードで動作する。
【００５９】
図８の８００は、送信装置の第２の実施形態の構成図である。
図８において、図２の第２の実施形態における送信装置２００の構成の場合と同じ番号が付された部分は、図２の場合と同じ処理を実行する。
【００６０】
図８の構成が図２の構成と異なる点は、要求モード判定部８０１が、要求パケット解析部２０２が受信した配信開始の要求パケットに、リアルタイムモードとサーバモードのどちらが設定されているかを判定する点である。
【００６１】
自装置がリアルタイム映像配信装置である場合において、配信開始の要求パケットにリアルタイムモードが設定されていれば、要求モード判定部８０１は要求応答パケット送信部２０３に対して、正常を示す要求応答パケットの返信を指示する。逆に、配信開始の要求パケットにサーバモードが設定されていれば、要求モード判定部８０１は要求応答パケット送信部２０３に対して、異常を示す要求応答パケットの返信を指示する。なお、要求応答パケットには同時に、リアルタイムエンコーダを示す装置タイプが付加される。
【００６２】
一方、自装置がファイル配信サーバである場合において、配信開始の要求パケットにリアルタイムモードが設定されていれば、要求モード判定部８０１は要求応答パケット送信部２０３に対して、異常を示す要求応答パケットの返信を指示する。逆に、配信開始の要求パケットにサーバモードが設定されていれば、要求モード判定部８０１は要求応答パケット送信部２０３に対して、正常を示す要求応答パケットの返信を指示する。なお、要求応答パケットには同時に、配信サーバを示す装置タイプ情報が付加される。
【００６３】
図９は、第２の実施形態における図１の受信装置１００の制御動作を示す動作フローチャートである。この動作フローチャートの制御動作は、受信装置１００内の特には図示しないプロセッサが特には図示しないメモリに記憶された制御プログラムを実行する動作として実現される。
【００６４】
まず、ユーザによって指定されたＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）アドレスに対して、配信開始を要求する要求パケットが送信される（ステップＳ９０１）。この場合に、要求パケットには、リアルタイムモードを示す配信要求モード情報が付加される。図１１は、受信装置及び送信装置の第２の実施形態における要求パケットのデータ構成例を示す図である。「ＴＹＰＥ」、「ＰＯＲＴ１」、「ＰＯＲＴ２」、「ＩＤ」、「ＡＢＩＬＩＴＹ」、「ＰＵＬＬＲＡＴＥ」の各情報は、図５に示される第１の実施形態の場合の要求パケットのデータ構成と同じである（図５参照）。「ＲＥＣＥＩＶＥＴＹＰＥ」情報は、上述の配信要求モード情報を指定する。「ＥＱＰＴＹＰＥ」情報は、値０として、リアルタイム配信、サーバ配信の両方に対応したデコーダであることを指定する。ステップＳ９０１では、「ＴＹＰＥ」情報として配信要求を示す値「０ｘ０００１」が指定され、「ＲＥＣＥＩＶＥＴＹＰＥ」情報としてリアルタイムモードを示す値「０」が指定されることになる。この動作は、図１の要求パケット生成部１０１及び要求パケット送信部１０２によって実行される。
【００６５】
その後、指定ＩＰアドレスの送信装置２００からの要求応答パケットを３０秒間待った後（ステップＳ９０１→Ｓ９０２→Ｓ９０１の繰返し）、要求応答パケットが受信されたら、要求応答パケットにて指定されている要求応答として、リアルタイムエンコーダの装置タイプ情報が指定されているかが判定される（ステップＳ９０３）。
【００６６】
この判定がＹＥＳならば、図１のモード判定部１０５は、切替部１１５及びフロー制御部１０６に、リアルタイムモードを設定する（ステップＳ９０４）。このようにしてリアルタイムモードが設定されたときには、ＰＣＲ制御に基づくデータ受信が実行される（ステップＳ３０６）。この動作は、第１の実施形態における図３のステップＳ３０６の動作と同様である。
【００６７】
一方、ステップＳ９０３の判定がＮＯならば、モード判定部１０５は要求パケット生成部１０１にその旨を通知する。これを受けて要求パケット生成部１０１は、指定ＩＰアドレスに対して、再度配信開始を要求する要求パケットを送信する（ステップＳ９０５）。この場合に、要求パケットには、配信要求モード情報即ち「ＲＥＣＥＩＶＥＴＹＰＥ」情報として、サーバモードを示す値「１」が指定される。
【００６８】
その後、指定ＩＰアドレスの送信装置２００からの要求応答パケットを３０秒間待った後（ステップＳ９０５→Ｓ９０６→Ｓ９０５の繰返し）、要求応答パケットが受信されたら、図１のモード判定部１０５は、切替部１１５及びフロー制御部１０６に、サーバモードを設定する（ステップＳ９０７）。このようにしてサーバモードが設定されたときには、フロー制御に基づくデータ受信が実行される（ステップＳ３０７〜Ｓ３１０）。この動作は、第１の実施形態における図３のステップＳ３０７〜Ｓ３１０の動作と同様である。
【００６９】
図１２は、図８の送信装置８００の制御動作を示す動作フローチャートである。この動作フローチャートの制御動作は、送信装置８００内の特には図示しないプロセッサが特には図示しないメモリに記憶された制御プログラムを実行する動作として実現される。
【００７０】
まず、ステップＳ４０１とＳ４０２の処理は、第１の実施形態における図４のステップＳ４０１とＳ４０２の処理と同じである。
即ちまず、送信装置８００は、要求パケットの受信待ちの状態にある（ステップＳ４０１の判定の繰返し）。
【００７１】
要求パケットが受信されると、要求パケットの内容が解析される（ステップＳ４０２）。この動作は、図８の要求パケット受信部２０１及び要求パケット解析部２０２によって実行される。
【００７２】
上記解析の結果、要求パケットが映像信号又は映像ファイルの配信開始を要求するパケットであるときには、その要求パケットに設定されている配信要求モード情報が、自装置のモードと一致するか否かが判定される（ステップＳ１００１）。この動作は、図８の要求モード判定部８０１によって実行される。
【００７３】
配信開始を要求するパケットが第１回目に受信されときには、図９のステップＳ９０１により、要求パケットには、「ＲＥＣＥＩＶＥＴＹＰＥ」情報としてリアルタイムモードを示す値「０」が指定されている。従って、自装置がリアルタイム映像配信装置であればステップＳ１００１では一致が判定され、自装置がファイル配信サーバであればステップＳ１００１では不一致が判定される。
【００７４】
また、自装置がファイル配信サーバであれば、ステップＳ１００１での不一致の判定の後、図９のステップＳ９０５により、第２回目の配信開始を要求するパケットが受信される。このときには、図９のステップＳ９０１により、要求パケットには、「ＲＥＣＥＩＶＥＴＹＰＥ」情報としてサーバモードを示す値「１」が指定されている。従って、ステップＳ１００１では一致が判定される。
【００７５】
自装置がファイル配信サーバであって、配信開始を要求するパケットが第１回目に受信されることによりステップＳ１００１で不一致が判定されたときには、以下の動作が実行される。即ち、要求モード判定部８０１は要求応答パケット送信部２０３に対して、異常を示しかつ配信サーバを示す装置タイプ情報が付加された要求応答パケットの返信を指示する（ステップＳ１００２）。要求応答パケットのデータ構成例は、第１の実施形態における図６に示されるデータ構成例と同じである。ステップＳ１００２では、「ＴＹＰＥ」情報として配信要求レスポンスを示す値「０ｘ０１０１」が指定され、「ＥＲＲＯＲＣＯＤＥ」情報として異常、配信不可を示す値「０ｘ０００１」が指定される。また、「ＥＱＰＴＹＰＥ」情報として配信サーバを示す値「０ｘ０００１」が指定されることになる。その後、配信開始の要求パケット待ちの処理に戻る（ステップＳ１００２→Ｓ４０１）。
【００７６】
自装置がファイル配信サーバであって、配信開始を要求するパケットが第２回目に受信された場合、又は自装置がリアルタイム映像配信装置１４０３であって、配信開始を要求するパケットが第１回目に受信された場合には、ステップＳ１００１では一致が判定される。この場合には、要求モード判定部８０１は要求応答パケット送信部２０３に対して、正常を示しかつ自分のモード（配信サーバ又はリアルタイムエンコーダ）を示す装置タイプ情報が付加された要求応答パケットの返信を指示する（ステップＳ１００３）。即ち、図６のデータ構成例において、「ＴＹＰＥ」情報として配信要求レスポンスを示す値「０ｘ０１０１」が指定され、「ＥＲＲＯＲＣＯＤＥ」情報として正常を示す値「０ｘ００００」が指定される。また、「ＥＱＰＴＹＰＥ」情報として配信サーバを示す値「０ｘ０００１」（自装置がファイル配信サーバである場合）又はリアルタイムエンコーダを示す値「０ｘ００００」（自装置がリアルタイム映像配信装置である場合）が指定されることになる。
【００７７】
その後、図２の要求パケット解析部２０２から動画送信部２０４に対して、データパケットの送信開始が指示され、送信が開始される（ステップＳ４０４）。これ以降の動作は、第１の実施形態における図４のステップＳ４０５からステップＳ４０８までの一連の制御動作と同じである。
【００７８】
以上の受信装置と送信装置の第２の実施形態の動作をまとめると、図１２の動作シーケンス図で示されるようになる。
自装置がリアルタイム映像配信装置なら、図１２（ａ）に示されるように、受信装置１００からのリアルタイムモードが指定された映像配信要求に対し（図９のステップＳ９０１）、送信装置８００ではモード一致が判定される（図１０のステップＳ１００１）。この結果、送信装置８００は、リアルタイムエンコーダの情報が付加された正常を示す要求応答を返信する（図１０のステップＳ１００３）。これを受けて、受信装置１００は、自装置の状態をリアルタイムモードに設定する（図９のステップ９０４）。その後、送信装置８００から受信装置１００にリアルタイム映像信号が伝送される（図１０のステップＳ４０４、図３のステップＳ３０６）。
【００７９】
一方、自装置がファイル配信サーバなら、図１２（ｂ）に示されるように、受信装置１００からのリアルタイムモードが指定された映像配信要求（図３のステップＳ９０１）に対し、送信装置８００では、モード不一致が判定される（図１０のステップＳ１００１）。この結果、送信装置８００は、配信サーバの情報が付加された異常を示す要求応答を返信する（図１０のステップＳ１００２）。これを受けて、受信装置１００は、モード不一致を検出することにより（図９のステップＳ９０３）、今度はサーバモードが指定された映像配信要求（図９のステップＳ９０５）を送信する。この結果、ｌ送信装置８００ではモード一致が判定される（図１０のステップＳ１００１）。そして、送信装置８００は、配信サーバの情報が付加された正常を示す要求応答を返信する（図１０のステップＳ１００３）。これを受けて、受信装置１００は、自装置の状態をサーバモードに設定する（図９のステップ９０７）。その後、送信装置８００から受信装置１００に映像ファイルが伝送される（図１０のステップＳ４０４、図９のステップＳ３０７）。
【００８０】
以上のようにして、受信装置と送信装置の第２の実施形態によれば、受信装置１００から送信装置８００に対して、受信装置１００が期待する配信要求モードを、「ＲＥＣＥＩＶＥＴＹＰＥ」情報によって明示的に通知することができる。
【００８１】
以上説明しようにして、受信装置と送信装置の第１又は第２の実施形態によれば、監視用のリアルタイム映像配信装置とファイル配信サーバの混在環境において、各装置専用の受信装置を用意する必要がなくなり、コストダウンが可能となる。
【００８２】
そして、上記各実施形態による受信装置により、配信元を意識せずにシームレスに映像受信を行うことが可能となる。
なお、上記各実施形態では、映像信号を対象とした例について説明したが、開示した技術は、映像信号以外にも、音声信号等の様々なメディア信号に対して適用可能である。
【符号の説明】
【００８３】
１０１ 要求パケット生成部
１０２、１０８ 要求パケット送信部
１０３ 要求応答パケット受信部
１０４ 要求応答解析部
１０５ モード判定部
１０６ フロー制御部
１０７ 送信停止／開始要求パケット送信部１０７
１０９ データパケット受信部
１１０ パケット判定部
１１１ パケット受信バッファ
１１２ ＰＣＲ制御部
１１３ ＶＣＸＯ
１１４ 自走ＯＳＣ
１１５ 切替部
１１６ 動画復号部
２０１ 要求パケット受信部
２０２ 要求パケット解析部
２０３ 要求応答パケット送信部
２０４ 動画送信部
２０５ 自走ＯＳＣ
２０６ ＰＣＲ生成部
２０７ パケット送信バッファ
２０８ データパケット送信部
８０１ 要求モード判定部
【特許請求の範囲】
【請求項１】
パケットネットワーク上での送信装置から受信装置へのメディア配信を切り替えるメディア配信切替え方法において、
前記受信装置から前記送信装置に前記メディア情報の配信を要求する要求パケットを送信し、
該要求パケットに応答して前記送信装置から前記受信装置に、該送信装置がリアルタイム性伝送と非リアルタイム性伝送のどちらの伝送を行う装置タイプであるかを示す装置タイプ情報を付加した要求応答パケットを返信し、
前記受信装置において、前記送信装置から受信した前記要求応答パケットに付加されている装置タイプ情報に基づいて、リアルタイム性伝送を行う動作モードと非リアルタイム性伝送を行う動作モードとを切り替えて受信動作を実行する、
ことを特徴とするメディア配信切替え方法。
【請求項２】
前記受信装置から前記送信装置に前記要求パケットを送信するときに、該要求パケットに該受信装置が期待する第１の動作モードを指定する配信要求モード情報を付加して送信し、
前記送信装置は、前記要求モードに付加されている配信要求モード情報と該送信装置の動作モードとが一致した場合に、正常を示す情報が付加された前記要求応答パケットを返信し、前記要求モードに付加されている配信要求モード情報と該送信装置の動作モードとが一致しない場合に、異常を示す情報が付加された前記要求応答パケットを返信し、
前記受信装置において、前記送信装置から受信した前記要求応答パケットに正常を示す情報が付加されているときに、該要求応答パケットに付加されている装置タイプ情報に対応する動作モードで受信動作を実行し、
前記受信装置において、前記送信装置から受信した前記要求応答パケットに異常を示す情報が付加されているときに、前記第１の動作モードとは異なる動作モードを指定する配信要求モード情報を付加した要求パケットを、前記受信装置から前記送信装置に再度送信する、
ことを特徴とする請求項１に記載のメディア配信切替え方法。
【請求項３】
パケットネットワーク上で送信装置から送信されるメディア情報を受信する受信装置において、
前記メディア情報の配信を要求する要求パケットを生成する要求パケット生成部と、
前記要求パケットを送信する要求パケット送信部と、
前記送信装置から前記要求パケットに対応する要求応答パケットを受信する要求応答パケット受信部と、
前記要求応答パケットに設定されている要求応答を解析する要求応答解析部と、
前記要求応答に付加され、前記送信装置がリアルタイム性伝送と非リアルタイム性伝送のどちらの伝送を行う装置タイプであるかを示す装置タイプ情報に基づいて、リアルタイム性伝送を行う動作モードと非リアルタイム性伝送を行う動作モードとを切り替えるモード判定部と、
リアルタイム性伝送を行う動作モードで前記メディア情報を受信する第１の受信部と、
非リアルタイム性伝送を行う動作モードで前記メディア情報を受信する第２の受信部と、
を含むことを特徴とする受信装置。
【請求項４】
パケットネットワーク上で受信装置にメディア情報を送信する送信装置において、
前記受信装置から前記メディア情報の配信を要求する要求パケットを受信する要求パケット受信部と、
前記要求パケットに設定されている要求を解析する要求パケット解析部と、
前記要求に応答して該受信装置に、自装置がリアルタイム性伝送と非リアルタイム性伝送のどちらの伝送を行う装置タイプであるかを示す装置タイプ情報を付加した要求応答パケットを返信する要求応答パケット送信部を含む、
ことを特徴とする送信装置。
【請求項１】
パケットネットワーク上での送信装置から受信装置へのメディア配信を切り替えるメディア配信切替え方法において、
前記受信装置から前記送信装置に前記メディア情報の配信を要求する要求パケットを送信し、
該要求パケットに応答して前記送信装置から前記受信装置に、該送信装置がリアルタイム性伝送と非リアルタイム性伝送のどちらの伝送を行う装置タイプであるかを示す装置タイプ情報を付加した要求応答パケットを返信し、
前記受信装置において、前記送信装置から受信した前記要求応答パケットに付加されている装置タイプ情報に基づいて、リアルタイム性伝送を行う動作モードと非リアルタイム性伝送を行う動作モードとを切り替えて受信動作を実行する、
ことを特徴とするメディア配信切替え方法。
【請求項２】
前記受信装置から前記送信装置に前記要求パケットを送信するときに、該要求パケットに該受信装置が期待する第１の動作モードを指定する配信要求モード情報を付加して送信し、
前記送信装置は、前記要求モードに付加されている配信要求モード情報と該送信装置の動作モードとが一致した場合に、正常を示す情報が付加された前記要求応答パケットを返信し、前記要求モードに付加されている配信要求モード情報と該送信装置の動作モードとが一致しない場合に、異常を示す情報が付加された前記要求応答パケットを返信し、
前記受信装置において、前記送信装置から受信した前記要求応答パケットに正常を示す情報が付加されているときに、該要求応答パケットに付加されている装置タイプ情報に対応する動作モードで受信動作を実行し、
前記受信装置において、前記送信装置から受信した前記要求応答パケットに異常を示す情報が付加されているときに、前記第１の動作モードとは異なる動作モードを指定する配信要求モード情報を付加した要求パケットを、前記受信装置から前記送信装置に再度送信する、
ことを特徴とする請求項１に記載のメディア配信切替え方法。
【請求項３】
パケットネットワーク上で送信装置から送信されるメディア情報を受信する受信装置において、
前記メディア情報の配信を要求する要求パケットを生成する要求パケット生成部と、
前記要求パケットを送信する要求パケット送信部と、
前記送信装置から前記要求パケットに対応する要求応答パケットを受信する要求応答パケット受信部と、
前記要求応答パケットに設定されている要求応答を解析する要求応答解析部と、
前記要求応答に付加され、前記送信装置がリアルタイム性伝送と非リアルタイム性伝送のどちらの伝送を行う装置タイプであるかを示す装置タイプ情報に基づいて、リアルタイム性伝送を行う動作モードと非リアルタイム性伝送を行う動作モードとを切り替えるモード判定部と、
リアルタイム性伝送を行う動作モードで前記メディア情報を受信する第１の受信部と、
非リアルタイム性伝送を行う動作モードで前記メディア情報を受信する第２の受信部と、
を含むことを特徴とする受信装置。
【請求項４】
パケットネットワーク上で受信装置にメディア情報を送信する送信装置において、
前記受信装置から前記メディア情報の配信を要求する要求パケットを受信する要求パケット受信部と、
前記要求パケットに設定されている要求を解析する要求パケット解析部と、
前記要求に応答して該受信装置に、自装置がリアルタイム性伝送と非リアルタイム性伝送のどちらの伝送を行う装置タイプであるかを示す装置タイプ情報を付加した要求応答パケットを返信する要求応答パケット送信部を含む、
ことを特徴とする送信装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図８】
【図９】
【図１０】
【図１１】
【図７】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図８】
【図９】
【図１０】
【図１１】
【図７】
【図１２】
【図１３】
【公開番号】特開２０１１−１５０２０（Ｐ２０１１−１５０２０Ａ）
【公開日】平成２３年１月２０日（２０１１．１．２０）
【国際特許分類】
【出願番号】特願２００９−１５５５０３（Ｐ２００９−１５５５０３）
【出願日】平成２１年６月３０日（２００９．６．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２３年１月２０日（２０１１．１．２０）
【国際特許分類】
【出願日】平成２１年６月３０日（２００９．６．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]