(57)【特許請求の範囲】
【請求項１】
チャネルを介してビデオデータを送るように構成されたビデオエンコーダであって、
調整可能な圧縮係数を使用してビデオデータを圧縮するように構成された圧縮器と、
圧縮されたビデオを前記圧縮器から受信し、伝送のためにデータをキューに入れ、前記キューに入れられたデータからデータパケットを構築し、前記構築されたデータパケットを、前記チャネルを介して伝送するように構成されたパケット構築器と、
前記チャネルを介してデータパケットを伝送するのに必要な時間に基づいて前記チャネルの性能を監視するように構成された帯域幅モニタと、を備え、前記圧縮器は、少なくともキューに入れられているが未だ伝送されていないデータの量及びタイプに基づき、かつ、前記帯域幅モニタによって判定されるような前記チャネルの前記性能に応答して、前記調整可能な圧縮係数を修正するように構成され、前記パケット構築器は、前記チャネルにおける伝送のための非ビデオデータを受信するように構成され、前記帯域幅モニタは、前記チャネルの性能と前記パケット構築器によって受信された非ビデオデータの量とに応答して、前記圧縮係数を修正するよう前記圧縮器に命令するように構成される、ビデオエンコーダ。
【請求項２】
前記伝送されたデータパケットに応答して送られる受信確認をサーバーから受信するように構成された受信機を備え、前記帯域幅モニタは、データパケットの伝送に続いて、受信確認が受信されるのに必要な時間を測定するように構成される、請求項１に記載のビデオエンコーダ。
【請求項３】
前記伝送されたデータパケットに応答して送られる受信確認をサーバーから受信するように構成された受信機を備え、前記パケット構築器は、伝送されたデータパケットに対する受信確認が受信されない場合、伝送のためにデータを再度キューに入れるように構成される、請求項１又は２に記載のビデオエンコーダ。
【請求項４】
ビデオおよび非ビデオデータが、前記ビデオエンコーダ内の単一のポートとサーバー内の単一のポートとの間で伝送される、請求項１〜３のいずれか１項に記載のビデオエンコーダ。
【請求項５】
前記パケット構築器は、ビデオおよび非ビデオデータのための少なくとも１つのバッファを備える、請求項１〜４のいずれか１項に記載のビデオエンコーダ。
【請求項６】
前記帯域幅モニタは、前記バッファ内の非ビデオデータの前記存在に応答して前記圧縮係数を修正するよう前記圧縮器に命令するように構成される、請求項５に記載のビデオエンコーダ。
【請求項７】
前記チャネルは、無線セルラーリンクである、請求項１〜６のいずれか１項に記載のビデオエンコーダ。
【請求項８】
前記帯域幅モニタは、非ビデオデータが前記パケット構築器によって受信されたとき、ビデオデータの前記キューを空にし、それによって帯域幅を前記非ビデオデータに利用可能にするために前記圧縮係数を修正するように構成される、請求項１〜７のいずれか１項に記載のビデオエンコーダ。
【請求項９】
前記圧縮器は、ビデオデータのキューを避ける又は最小化するように前記調整可能な圧縮係数を増加するように構成される、請求項１〜８のいずれか１項に記載のビデオエンコーダ。
【請求項１０】
前記圧縮器は、伝送された前記ビデオデータの品質を示す前記調整可能な圧縮係数を修正するように構成される、請求項１〜９のいずれか１項に記載のビデオエンコーダ。
【請求項１１】
前記非ビデオデータは、より高い優先度のデータを含み、前記より高い優先度のデータはビデオデータの伝送に際してより高い優先度で伝送される非ビデオデータであり、
前記パケット構築器は、前記より高い優先度のデータが前記パケット構築器によって受信されたときには常に、遅延を生じることなく、前記より高い優先度のデータを伝送するように構成される、請求項１〜１０のいずれか１項に記載のビデオエンコーダ。
【請求項１２】
前記非ビデオデータは、より低い優先度のデータを含み、前記より低い優先度のデータはビデオデータの伝送に際してより低い優先度で伝送される非ビデオデータである、請求項１〜１１のいずれか１項に記載のビデオエンコーダ。
【請求項１３】
より低い優先度のデータが前記パケット構築器によって受信されたときに、前記チャネルに前記より低い優先度のデータのためのスペースを作成するために、前記調整可能な圧縮係数が修正される、請求項１２に記載のビデオエンコーダ。
【請求項１４】
前記パケット構築器は、キューに入れられたビデオデータのすべてが伝送されたときにのみ、より低い優先度のデータを伝送するように構成される、請求項１２又は１３に記載のビデオエンコーダ。
【請求項１５】
請求項１〜１４のいずれか１項に記載のビデオエンコーダと、前記チャネルを介して伝送される前記構築されたデータパケットを受信するように構成されたサーバーと、を備える伝送システム。
【請求項１６】
チャネルを介してビデオデータを送る方法であって、
キューに入れられているが未だ伝送されていないデータの量及びタイプに基づいて調整可能な圧縮係数を使用してビデオデータを圧縮するステップと、
伝送のためにビデオデータをキューに入れるステップと、
伝送のために非ビデオデータをキューに入れるステップと、
前記圧縮されたビデオと前記非ビデオデータとを含むデータパケットを構築するステップと、
前記構築されたデータパケットを、前記チャネルを介して伝送するステップと、
前記チャネルを介してデータパケットを伝送するのに必要な時間に基づいて前記チャネルの性能を監視するステップと、
前記チャネルの前記性能と前記キュー内の非ビデオデータの量とに基づいて前記圧縮係数を修正するステップと、
を含む、方法。
【請求項１７】
コンピュータプログラムがその上に記憶された、非一時的コンピュータ可読記憶媒体であって、前記コンピュータプログラムは、実行されたとき、
キューに入れられているが未だ伝送されていないデータの量及びタイプに基づいて調整可能な圧縮係数を使用してビデオデータを圧縮することと、
伝送のためにビデオデータをキューに入れることと、
伝送のために非ビデオデータをキューに入れることと、
前記圧縮されたビデオと前記非ビデオデータとを含むデータパケットを構築することと、
前記構築されたデータパケットを、チャネルを介して伝送することと、
前記チャネルを介してデータパケットを伝送するのに必要な時間に基づいて前記チャネルの性能を監視することと、
前記チャネルの前記性能と前記キュー内の非ビデオデータの量とに基づいて前記圧縮係数を修正することと、
を含む動作を実行するようにデバイスに指示するプロセッサ可読命令を備える、非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、他のデータと多重化され得る圧縮されたビデオデータを、チャネルを介して伝送するためのビデオエンコーダまたは適応ビデオマルチプレクサを含む通信システムに関する。具体的には、本発明は、少ない待ち時間（latency）でビデオが提供されることを確実にするために、チャネルにおいてデータが伝送されるレートを調整することができるビデオエンコーダに関する。
【背景技術】
【０００２】
ビデオが低帯域幅チャネルを介して伝送されることを可能にするために、さまざまな技術が開発されている。これらの技術は、ビデオ電話通話、ビデオストリーミング、および遠隔ビデオ監視を含む多数の用途を有する。
【０００３】
いくつかのアプリケーションでは、これらの低帯域幅チャンネルで「ライブ」ビデオを提供できることが重要である。「ライブ」ビデオは一般的な用語であるが、さまざまな要因が小さな遅延をもたらすので、通信システムで真に「ライブ」なビデオを提供することは実際には不可能である。これは、視聴者の画面に表示されるビデオが、普通、カメラによって取込まれたビデオと比較してわずかな遅延を有することを意味する。遅延は、伝送、圧縮／解凍、ユーザデバイスでのレンダリング、コマ落ち、およびキューイング／バッファリングによって導入され得る。一例として、伝送システムが、すぐに利用可能な帯域幅を超えるデータサイズを有するビデオフレームを伝送しようとする場合、遅延が導入され得て、これは、ビデオがセルラーリンクのような可変帯域幅を有するリンクを介して伝送される場合に起こり得る。このような状況では、大きなビデオフレームはキューに入れられバッファリングされなければならず、それは遅延してでしか受信できないことを意味する。時間が経つとこれが累積された待ち時間を作り出す可能性があり、それは視聴者の画面に表示されるビデオがリアルタイムよりいくらか遅れることを意味する。いくつかのセキュリティ監視アプリケーションでは、伝送されるビデオにおけるこのタイプの待ち時間は重大な問題となり得る。
【０００４】
ワイヤレスチャネルを介して他のタイプのデータを伝送するという圧力がある場合には、視聴者のデバイスで遅延がビデオに導入されることもある。これは、ビデオに利用可能な帯域幅を削減し、伝送前にビデオフレームがキューに入れられバッファされる必要がある可能性が高くなり得る。
【０００５】
遅延のリスクを低減するための１つの選択肢は、データレートがチャネルの平均帯域幅よりも低く維持されるようにビデオデータに対して高い圧縮率を使用することである。これにより、チャネルにおいて、帯域幅が変化するか、または追加のデータが伝送されても、ビデオデータを首尾よく伝送することができる。このアプローチの欠点は、ビデオが必要以上に圧縮される可能性があり、これは、利用可能な帯域幅が完全には利用されない可能性があることを意味する。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の目的は、ビデオが低帯域幅のチャネルを介して伝送される遅延を最小限に抑えることができる、ビデオエンコーダまたは適応ビデオマルチプレクサ、および方法を提供することである。
【０００７】
本発明によれば、チャネルを介してビデオデータを送るように構成されたビデオエンコーダであって、当該エンコーダは、調整可能な圧縮係数を使用してビデオデータを圧縮するように構成された圧縮器と、圧縮されたビデオを圧縮器から受信し、伝送のためのデータをキューに入れ、キューに入れられたデータからデータパケットを構築し、構築されたデータパケットを、チャネルを介して伝送するように構成されたパケット構築器と、伝送されたデータパケットの挙動に基づいてチャネルの性能を監視するように構成された帯域幅モニタとを備え、ビデオ圧縮器は、キューに入れられたデータの少なくとも１つの特性に基づき、かつ、帯域幅モニタによって判定されるようなチャネルの性能に応答して、圧縮係数を修正するように構成される、ビデオエンコーダが提供される。
【０００８】
このようにして、エンコーダは、チャネルにおける帯域幅の可用性に適合させることができるようにビデオデータの圧縮を最適化することができる。したがって、ビデオ伝送は、セルラーリンクのような可変帯域幅チャネルに対して最適化することができる。帯域幅モニタは、チャネルが苦労しているように、チャネルにおける利用可能な帯域幅が狭いことを検出した場合、ビデオ圧縮器により高い圧縮係数を使用するように命令してもよい。これにより、使用可能な帯域幅を超えないように、ビデオを低品質で伝送することができる。一方、帯域幅モニタがチャネルにおいて利用可能な追加の帯域幅があることを検出した場合、ビデオコンプレッサに、より低い圧縮係数を使用するよう命令してもよい。これにより、チャネルの状況によって許容される最高の品質でライブビデオデータを伝送することが可能になる。
【０００９】
調整可能な圧縮係数を、キューに入れられたデータの少なくとも１つの特性に従って変更することもできる。例えば、データが伝送のためにキューに入れられているがまだ伝送されていない場合、圧縮係数を調整することができる。これらの状況では、圧縮係数を増加させてもよい。これにより、ビデオを減少させたデータレートで送ることができる。これにより、ビデオによってチャネルに課せられた要求が減少し、キューに入れられたデータを送るためのチャネル内のスペースができる。キューに入れられたデータは、ビデオデータでも非ビデオデータでもよい。
【００１０】
帯域幅モニタは、好ましくは、チャネルを介してデータパケットを伝送するのに必要な時間を測定するように構成される。これは、チャネルの性能を示し得る。データパケットの伝送時間が長いか、または増加する場合、これは、低い帯域幅の可用性を有するチャネルを示す可能性がある。これらの状況では、伝送されたビデオのデータレート（および品質）を低下させるために圧縮係数を増加させてもよく、したがって、データのチャネルへの要求を減少させる。
【００１１】
ビデオエンコーダは、伝送されたデータパケットに応答して送られる受信確認をサーバーから受信するように構成された受信機を備え得る。好ましくは、帯域幅モニタは、データパケットの伝送に続いて、受信確認が受信されるのに必要な時間を測定するように構成される。このようにして、ビデオエンコーダは、データパケットと受信確認がサーバーとの間で送受信される往復時間を測定することができる。
【００１２】
好ましい実施形態では、キュー入れられているがまだ伝送されていないデータの量が、ビデオ圧縮器によって使用される圧縮係数を調整するために使用される。代わって、または加えて、キューに入れられたデータのタイプが適切かもしれない。一例では、圧縮係数は、キューに入れられたデータがビデオデータであるか、タイムクリティカルデータであるか、または非タイムクリティカルデータであるかに依存して調整されてもよい。キューに入れられたデータの量も影響を及ぼす可能性があり、キューに未送信データが大量にある場合、より高い圧縮係数が使用される可能性がある。
【００１３】
いくつかの実施形態では、受信確認がサーバーから受信されない場合、データは伝送のために再度キューに入れられてもよい。再度キューに入れられたデータが保留中の場合、圧縮器はより高い圧縮係数を使用することがある。これにより、ライブビデオのデータレートを低下させて、データを再送信するためにチャンネル内の空きスペースを許すことができる。これにより、ライブビデオデータの連続供給を乱すことなくデータを再送信することができる。
【００１４】
パケット構築器は、好ましくは、チャネルにおける伝送のために非ビデオデータを受信するように構成される。圧縮器は、チャネルの性能およびパケット構築器によって受信された（および伝送のためにキューに入れられた）非ビデオデータの量に応答して圧縮係数を修正することができる。非ビデオデータがパケット構築器によって受信された場合、圧縮係数を調整することによって、チャネルにおける非ビデオデータの帯域幅を解放するためにビデオ品質を低減することができる。非ビデオデータは、したがって、ライブビデオの供給に時間遅延を導入することなく、ビデオデータと一緒に、チャネル内で伝送することができる。これは視聴者の視点からほとんど目に見えないように達成することができる。もちろん、ビデオの品質はわずかに低下するだろうが、ビデオの品質はチャンネルの性能に基づいていずれにしても動的に変更されるので、視聴者はこれに気付かないであろう。
【００１５】
好ましくは、ビデオおよび非ビデオのデータは、ビデオエンコーダの単一のポートとサーバーの単一のポートとの間で伝送される。このようにして、すべてのタイプのデータを単一チャネルに多重化することができる。
【００１６】
パケット構築器は、ビデオおよび非ビデオのデータのための少なくとも１つのバッファを備えてもよい。好ましくは、帯域幅モニタは、適切なバッファにキューされた非ビデオデータの存在に応答して圧縮係数を修正するようビデオ圧縮器に命令するように構成される。このようにして、非ビデオデータを伝送について優先することができる。何かしらの非ビデオデータがバッファ内に存在する場合、これが検出され、チャネル内に非ビデオデータのためのスペースを作成するために適宜圧縮係数が調整される。
【００１７】
非ビデオデータは、それぞれ、タイムクリティカルデータおよび非タイムクリティカルデータであってもよい、より高い優先度のデータおよびより低い優先度のデータを含んでもよい。一構成では、より高い優先度のデータは、それらがパケット構築器によって受信されるときはいつでも、遅延なしで伝送される。一例において、これは、監視シナリオにおいて可能な限り早く通信されなければならないアラームのようなタイムクリティカルデータを含んでもよい。タイムクリティカルデータを即座に伝送すると、ライブビデオの供給を乱し、データがバッファ内でキューに入れられるかもしれない。キューに入れられたデータの検出は、圧縮係数の修正を促し得る。これにより、キューに入れられたデータが伝送される時間を充当するために、ライブビデオデータをより低いデータレートで伝送させることができる。
【００１８】
より低い優先度のデータは、非タイムクリティカルである可能性がある。一構成では、非タイムクリティカルデータがパケット構築器によって受信されたときに圧縮係数を調整してもよい。これにより、非タイムクリティカルデータのためにチャネル内のスペースが充当できる。
【００１９】
好ましくは、非タイムクリティカルデータのような非ビデオデータは、キューに入れられたビデオデータのすべてが伝送されたときにのみ伝送される。したがって、非タイムクリティカルデータは、ビデオバッファが空になってチャネルに利用可能な帯域幅がある場合にのみ伝送することができる。言い換えれば、ビデオデータのキューを空にし、非ビデオデータに対して帯域幅を利用可能にするために非ビデオデータがパケット構築器によって受信されるときに、圧縮係数を修正することができる。このようにして、ビデオデータに待ち時間を導入することなく非ビデオデータを伝送することができ、それは一部のセキュリティ監視アプリケーションでは必要不可欠である。圧縮係数を修正することにより、即座に、だが、ライブビデオの供給を乱すことなく非ビデオデータに対して帯域幅を利用できるようにするために若干より低い品質で、ビデオデータを伝送することができる。
【００２０】
本発明の別の態様によれば、前に定義したようなビデオエンコーダと、チャネルを介してデータパケットを受信するためのサーバーとを備える通信システムが提供される。サーバーは、インターネットチャネルを介して受信したデータパケットを視聴者に中継してもよい。好ましくは、広帯域チャネルがサーバーと視聴者との間に提供される。この広帯域チャネルは、好ましくは、サーバーとエンコーダとの間のチャネルよりもかなり広い帯域幅を有しており、それはこのチャネルにおけるデータ最適化がそれほど重要でないことを意味する。状況によっては、サーバーと視聴クライアントとの間の帯域幅に管理が必要な場合もある。一実施形態では、サーバーは、帯域幅適応プロセスの上限として使用される最大帯域幅値を低減するようにエンコーダに命令する。
【００２１】
通常、サーバーから視聴クライアントまでのチャネル帯域幅は、エンコーダとサーバーとの間のチャネル帯域幅よりも広い。これが当てはまらない場合、帯域幅を管理するために、サーバーがエンコーダに、データを生成することができる最大帯域幅を低減するように命令する、同等のメカニズムが利用され得る。
【００２２】
本発明のさらに別の態様によれば、チャネルを介してビデオデータを送る方法であって、調整可能な圧縮係数を使用してビデオデータを圧縮するステップと、伝送のためにデータをキューに入れるステップと、圧縮されたビデオを含むデータパケットを構築するステップと、構築されたデータパケットを、チャネルを介して伝送するステップと、伝送されたデータパケットの挙動に基づいてチャネルの性能を監視するステップと、チャネルの性能とキューに入れられたデータの少なくとも１つの特性に基づいて圧縮係数を修正するステップと、を含む方法が提供される。
【００２３】
本発明のさらに別の態様によれば、コンピュータプログラムがその上に記憶された、非一時的コンピュータ可読記憶媒体であって、コンピュータプログラムは、実行されたとき、調整可能な圧縮係数を使用してビデオデータを圧縮すること、伝送のためにデータをキューに入れることと、圧縮されたビデオを含むデータパケットを構築することと、構築されたデータパケットを、チャネルを介して伝送することと、伝送されたデータパケットの挙動に基づいてチャネルの性能を監視することと、チャネルの性能とキューに入れられたデータの少なくとも１つの特性とに基づいて圧縮係数を修正することと、を含む動作を実行するようにデバイスに指示するプロセッサ可読命令を備える、非一時的コンピュータ可読記憶媒体が提供される。
【００２４】
方法の特徴は、対応する装置の特徴として提供することができ、逆も同様である。
【００２５】
本発明の実施形態を、添付の図面を参照して、単なる例として以下に説明する。
【図面の簡単な説明】
【００２６】
【図１】本発明の一実施形態における伝送システムの概略図である。
【図２】本発明の一実施形態におけるエンコーダとサーバーとの間の通信アーキテクチャの概略図である。
【図３】ビデオエンコーダ内のデータの流れを示す模式図である。
【図４】ビデオエンコーダと通信しているサーバー内のデータの流れを示す模式図である。
【図５】エンコーダ内のバッファの例を示し、データブロックがどのように割り当てられ、削除されるかを説明するシナリオを描写している。
【図６】エンコーダ内のバッファの例を示し、データブロックがどのように割り当てられ、削除されるかを説明するシナリオを描写している。
【図７】エンコーダ内のバッファの例を示し、データブロックがどのように割り当てられ、削除されるかを説明するシナリオを描写している。
【図８】エンコーダ内のバッファの例を示し、データブロックがどのように割り当てられ、削除されるかを説明するシナリオを描写している。
【図９】エンコーダ内のバッファの例を示し、データブロックがどのように割り当てられ、削除されるかを説明するシナリオを描写している。
【図１０】エンコーダ内のバッファの例を示し、データブロックがどのように割り当てられ、削除されるかを説明するシナリオを描写している。
【図１１】エンコーダ内のバッファの例を示し、データブロックがどのように割り当てられ、削除されるかを説明するシナリオを描写している。
【図１２】サーバー内の受信データバッファの例を示し、データブロックがどのように割り当てられ、取り外されるかを説明するシナリオを描写している。
【図１３】サーバー内の受信データバッファの例を示し、データブロックがどのように割り当てられ、取り外されるかを説明するシナリオを描写している。
【図１４】サーバー内の受信データバッファの例を示し、データブロックがどのように割り当てられ、取り外されるかを説明するシナリオを描写している。
【図１５】エンコーダ内の帯域幅モニタの動作を示す流れ図である。
【図１６】エンコーダ内の決定ブロックを示す論理流れ図である。
【発明を実施するための形態】
【００２７】
図１は、それぞれのセルラートランシーバ６、８を有するビデオエンコーダ２とサーバー４とを含む伝送システムの概略図である。エンコーダ２は、ビデオデータ、タイムクリティカルデータおよび非タイムクリティカルデータを、セルラーリンクを介してサーバー４に送るように動作可能である。サーバー４は、タイムクリティカルデータおよび非タイムクリティカルデータを、セルラーリンクを介してエンコーダ２に送るように動作可能である。
【００２８】
サーバー４は、インターネットのような従来のネットワーク２４を介してユーザデバイス２２に接続されている。サーバー４とユーザデバイス２２との間には、低帯域幅チャネルを含めて多くの代替的な接続が使用されてもよい。サーバー４は、エンコーダ２から受信したビデオおよび／または他のデータを、インターネットを介してユーザデバイス２２に中継するように構成される。一般に、サーバー４とユーザデバイス２２との間には、サーバー４とエンコーダ２との間のセルラーリンクで可能であるよりも高い容量の接続が提供される。したがって、帯域幅の可用性が低いため、ビデオにさらなる遅延を招くことなくビデオデータをユーザデバイス２２に中継することが一般に可能である。
【００２９】
エンコーダ２はビデオカメラ１０とセキュリティセンサ１２に接続されている。セキュリティセンサ１２は、温度センサ、トリップワイヤセンサ、ひずみゲージなどを含んでもよい。センサ１２は、検出を行い、エンコーダ２内のＣＰＵ１４にデータを送ることができる。ビデオカメラ１０は、マイクロフォン１３およびラウドスピーカー１１を含む。マイクロフォン１３はサーバー４に伝送するための音声データを取込むことができ、ラウドスピーカー１１はサーバー４から受信した音声データを再生するために使用できる。
【００３０】
ビデオカメラ１０は、光景からビデオを取込み、それをエンコーダ２内の圧縮器１６に提供するように構成される。圧縮器１６は、調整可能な圧縮係数を使用してビデオを圧縮するように動作可能である。マルチプレクサ１８は、ビデオ圧縮器１６からの圧縮されたビデオを受信し、タイムクリティカルおよび非タイムクリティカルなデータもＣＰＵ１４から受信する。これらのデータは、単一チャネルに多重化され、セルラーリンクを介してサーバー４に伝送される。
【００３１】
エンコーダは、チャネルに伝送されているデータパケットの挙動を監視するように構成された帯域幅モニタ２０を含む。帯域幅モニタ２０はまた、チャネルにおける変化する状況に応じて調整可能な圧縮係数を変更するようにビデオ圧縮器１６に命令するように動作可能である。帯域幅モニタ２０の動作については、以下でさらに詳細に説明する。
【００３２】
図２は、エンコーダ２とサーバー４との間の通信アーキテクチャの概略図である。単一のＴＣＰリンクおよび単一のＵＤＰストリームを使用して、エンコーダ２とサーバー４との間でデータが転送される。すべてのＵＤＰトラフィックに対して、サーバー４およびエンコーダ２上で単一のポートが使用される。
【００３３】
動的ＩＰアドレス割り当てに備えて、エンコーダ２からサーバー４への接続を確立するために、ＴＣＰリンクが提供される。次に、ＵＤＰストリームを開始するためにこの制御チャネルが使用される。その後、エンコーダ２とサーバー４との間のリンクについてルーティングテーブルを維持することを確実にするために、周期的なキープアライブメッセージが、ＴＣＰリンク上の唯一のトラフィックとなる。
【００３４】
ＵＤＰストリームが確立されると、エンコーダ２内のマルチプレクサ１８は、エンコーダ２とサーバー４との間のデータグラムルーティングテーブルを維持するのに必要な最小の頻度でパケットを発行する。伝送に利用可能なデータがない場合、ペイロードは数バイトにすぎない。データが伝送のために生成されると、パケットレートおよびパケットサイズは最大レートに増加する。サーバー４は同様にエンコーダ２にＵＤＰパケットを戻すが、通常は受信したパケットに応答してパケットを発行するだけである。
【００３５】
ＵＤＰストリームは、交換するデータがない場合には閉じることができ、これにより「キープアライブ」データの容量が削減され、したがってデータ使用コストが削減される。ＵＤＰストリームが閉じられると、サーバー４は、通常動作を開始するためにＵＤＰストリームを再オープンするためにＴＣＰリンクを使用しなければならない。ＵＤＰストリームが閉じられている場合には、エンコーダ２は、アラーム信号などのタイムクリティカルデータを、ＴＣＰ制御リンクを介して送ることができる。
【００３６】
図３は、エンコーダ２におけるデータの流れを示す模式図である。マルチプレクサ１８は、３つのタイプのデータをそれぞれのバッファ２６、２８、３０から受信し、各タイプのデータは異なる方法で処理される。第１に、マルチプレクサ１８はビデオバッファ２６からビデオを受信する。ビデオは、ビデオ圧縮器１６によって圧縮され、結果のデータパケットはビデオバッファ２６に直接ロードされる。第２に、マルチプレクサ１８は、非タイムクリティカルデータバッファ２８から非タイムクリティカルデータを受信する。第３に、マルチプレクサ１８は、タイムクリティカルデータバッファ３０からタイムクリティカルデータを受信する。エンコーダ２内の非タイムクリティカルデータの例は、要求に応じてサーバー４に伝送することができる高解像度画像、またはエンコーダ２のデータ記憶装置からの他のデータの回収を含む。エンコーダ２内のタイムクリティカルデータの例は、センサ１２によってトリガされ得るアラームイベントまたはマイクロフォン１３からのオーディオデータを含む。
【００３７】
各バッファ２６、２８、３０は、データブロックをマルチプレクサ１８に供給する。バッファ２６、２８、３０はまた、データパケットの伝送が成功したことに応答して、サーバー４から受信確認を受信する。これらの受信確認によって、図５〜１１を参照してより詳細に説明されるように、データブロックがそれぞれのバッファから取り外されることが許される。
【００３８】
ビデオバッファ２６は、その排出レートを帯域幅モニタ２０に報告する。さらに、非タイムクリティカルデータバッファ２８は、保留中のデータブロックの数を帯域幅モニタ２０に報告する。さらに、マルチプレクサ１８は、チャネル帯域幅の推定される可用性を帯域幅モニタ２０に報告する。これにより、帯域幅モニタ２０は、チャネルにおけるデータパケットの挙動および非ビデオデータの帯域幅要件に応答して圧縮係数を調整するよう圧縮器１６に命令することができる。
【００３９】
バッファ２６、２８、３０のすべてはまた、キューに入れられたデータブロックの数を帯域幅モニタに報告する。以下でさらに詳細に説明するように、それぞれのバッファ２６、２８、３０内のキューに入れられたデータブロックのこの数は、圧縮器１６内の圧縮率を調整するためにも使用される。
【００４０】
サーバー４にデータを送るのと同様に、マルチプレクサ１８はサーバー４からもデータを受信し、データブロックを受信データバッファ３２へ供給する。このように、マルチプレクサ１８は実際にはマルチプレクサ／デマルチプレクサデバイスである。受信データは、ステアリング命令および／またはパン、チルト、ズーム（ＰＴＺ）命令を含むビデオカメラ１０のテレメトリ、ラウドスピーカー１１用のオーディオデータおよびファームウェアの更新を含むことができる。
【００４１】
図４は、サーバー４におけるデータの流れを示す模式図である。サーバー４は、非タイムクリティカルデータとタイムクリティカルデータをエンコーダ２に送るように動作可能である。サーバー４内のマルチプレクサ３６は、エンコーダ２からデータを送受信することができる（したがって、マルチプレクサとデマルチプレクサの両方である）。エンコーダ２にデータを送るとき、マルチプレクサ３６は、非タイムクリティカルデータバッファ３８およびタイムクリティカルデータバッファ４０からデータパケットを受信する。タイムクリティカルデータの例には、エンコーダ２におけるカメラテレメトリ命令および／またはラウドスピーカー１１によって繰り返されるオーディオメッセージが含まれる。非タイムクリティカルデータの例は、エンコーダ２のためのソフトウェアの更新である。これらのバッファ３８、４０からのデータは、マルチプレクサ３６において結合され、セルラーリンクおよびＵＤＰストリームを介してエンコーダ２に伝送される。バッファ３８、４０は、データブロックをマルチプレクサ３６に供給し、適切なデータパケットがエンコーダ２に首尾よく受信された場合には受信確認を受信する。一旦データブロックが正常に受信されると、そのときのみ、それらはバッファ３８、４０から削除される。
【００４２】
サーバー４はまた、エンコーダ２からデータを受信するための受信データバッファ４２を含む。もちろん、受信されたデータは、ビデオストリーム、および任意のタイムクリティカルまたは非タイムクリティカルのデータを含む。
【００４３】
サーバー４は、サーバー４とエンコーダ２との間のＴＣＰリンクを確立し制御するためのＴＣＰチャネルコントローラ４４を含む。エンコーダ２には、対応するＴＣＰチャネルコントローラ３４が設けられている。
【００４４】
エンコーダ２内のバッファ２６、２８、３０、およびサーバー４内のバッファ３８、４０におけるデータブロックの管理について、図５〜図１１を参照して以下に説明する。
【００４５】
図５には、データを割り当てることができる１６個の利用可能なブロックを有する循環バッファが示されている。一例では、１０３バイトであるメッセージＡと、３７バイトであるメッセージＢの、２つのメッセージがバッファに割り当てられる。ビデオバッファ２６の例では、メッセージＡは第１のビデオフレームに対応し、メッセージＢは第２のビデオフレームに対応することができる。この例では、バッファ内の各ブロックは３２バイトを収容できる。したがって、メッセージＡは４つのブロックに分割され、メッセージＢは２つのブロックに分割される。この例では、マルチプレクサ１８は、発行されるべき次のＵＤＰペイロード（パケットＮ）に９６バイトのデータを送ることができる。したがって、マルチプレクサ１８は、最初の３つのブロックをバッファからコピーする。これらのブロックは送られたとしてマークされるが、受信されておらず、バッファからまだ削除されない。
【００４６】
図６では、バッファに新しいメッセージが割り当てられている。メッセージは２４０バイトで、５つのブロックに割り当てられている。この例では、マルチプレクサ１８は、次のＵＤＰパケットＮ＋１のペイロードに５つのブロックを送る能力を有する。こうして、マルチプレクサ１８は、ＵＤＰパケットＮ＋１に割り当てられるべき、メッセージＡの残り、メッセージＢのすべて、およびメッセージＣの最初の２つのブロックをコピーする。
【００４７】
ＵＤＰパケットＮを受信すると、サーバー４は、ＵＤＰパケットの一部として受信確認をエンコーダ２に送り返す。この例では、サーバー４からの受信確認は、バッファ内の最初の３つのブロックが正しく送られたことを識別する。したがって、図７に示すように、これらのブロックをバッファから削除することができる。図７の例では、さらなるメッセージＤがバッファに割り当てられる。メッセージＤは１９０バイトで、６つのブロックに分割される。しかしながら、バッファには５つしか利用できるブロックがない。したがって、最後のブロックは未だバッファに割り当てることができない。マルチプレクサ１８は次いで、次のＵＤＰパケットＮ＋２を準備することができる。この例では、マルチプレクサ１８は、パケットＮ＋２に４つのブロックを送る能力を有する。これは、ブロックＣ３〜Ｃ６に対応し、マルチプレクサ１８によってコピーされ、セルラーチャネルを介してサーバー４に送られる。
【００４８】
図８では、いっぱいであるため、これ以上のブロックをバッファに割り当てることはできない。次いで、マルチプレクサ１８は、ブロックＣ７、Ｃ８、Ｄ１、Ｄ２およびＤ３を含むパケットＮ＋３を準備する。これらのブロックは、その後にサーバー４に送られるパケットＮ＋３にコピーされる。この例では、サーバー４はＵＤＰパケットＮ＋１の受信に失敗する。しかしながら、パケットＮ＋２は首尾よく受信される。図８は、対応するブロック（Ｃ３〜Ｃ６）がバッファから削除された、パケットＮ＋２の受信確認に続くこのプロセスを示す。しかしながら、パケットＮ＋１で送られたブロックはバッファに残る。次のステップは、マルチプレクサがパケットＮ＋４を準備することであり、この例では、単一のブロック（Ｄ４）が含まれる。
【００４９】
パケットＮ＋１はサーバー４によって受信されないので、再送を開始する必要があり、そうでなければデータが失われる。この例では、エンコーダ２が特定の数の後続のパケットの受信確認を受信すると、再送が開始される。加えて、または代替として、受信確認が所定の時間内に受信されない場合、再送が開始されてもよい。図９は、パケットＮ＋１の再送の開始を示し、適切なブロックが再送されるようにマークされている。これらのブロックは、バッファ内のいかなる送られていないブロックよりも優先され、後続のパケットのスペースに従って割り当てられる。したがって、パケットＮ＋１は必ずしも同じ形式で再送されない。むしろ、元のパケットＮ＋１内のブロックは、スペースの利用可能性に従って新しいパケットに配置される。この例では、マルチプレクサ１８は、パケットＮ＋５を準備する。この例では、パケットＮ＋５は３ブロック分のスペースを有し、ブロックＡ４、Ｂ１およびＢ２が配置されている。
【００５０】
図１０に示すように、パケットＮ＋６において、マルチプレクサ１８は、再送されるようマークされた、ブロックＣ１およびＣ２を配置する。パケットＮ＋６にはもう１つのブロックのためのスペースがあり、したがって送られていないブロックＤ５が配置される。図１０はまた、パケットＮ＋５が受信されたとサーバー４が受信確認することを示す。したがって、パケットＮ＋５に関連するブロックをバッファから削除することができる。こうなると、バッファに利用可能なスペースができる。図１０は、メッセージＤの残りの部分が、単一のブロックからなる新しいメッセージＥと共にバッファに書き込まれることを示す。
【００５１】
図１１は、この例についてのプロセスの最終部分を示す。この例では、マルチプレクサ１８は、Ｄ６とＥ１の２つのブロックを含むパケットＮ＋７を準備する。次いで、パケットＮ＋６についてサーバーから受信確認が受信され、対応するブロックがバッファから削除される。最後に、対応する受信確認がサーバー４から受信されなかったので、パケットＮ＋４に対応するブロックが再送されるようにマークされる。
【００５２】
上記の例における仮定は、メッセージデータの信頼性の高い伝送が必要とされるということである。したがって、受信確認がされないパケットは再送されるように慎重にマークされる。実際には、信頼できるメッセージ伝送は、オーディオ／ビデオストリームには必ずしも必要ではなく、ビデオについて変動を実装することが適切な場合がある。使用されているリンクプロファイルに基づいて、再送の回数は最大数に制限される場合がある。潜在的にはこれは、最初の送信に続いてブロックが削除されるよう、ゼロである可能性がある。
【００５３】
エンコーダ２およびサーバー４は、それぞれ受信データバッファ３２、４２を備える。これらのデータバッファ３２、４２は、順番の狂った受け取りおよびドロップされたパケットを処理するための受信したメッセージの再構築を可能にする。ただ１つの断片がＵＤＰパケットのペイロードから抽出されたとしても、完全なメッセージの長さおよびタイプについて受信者によって推論できるようにメッセージヘッダが組み立てられる。
【００５４】
図１２は、３２バイトブロックにセグメント化された循環受信データバッファ４２の一例を示す。この例では、パケットＮ、Ｎ＋２およびＮ＋３に対応する３つの不完全なメッセージが受信されている。パケットＮの情報は、メッセージＡが４つのブロックに保持されていることを指定しているので、パケットに３つしか供給されていないにもかかわらず４つのブロックが確保されている。同様に、パケットＮ＋２は、パケットに始めと終わりを含んでブロック３〜６がある、長さ８ブロックのものとしてメッセージＣを符号化している。パケットＮ＋３は、メッセージＣの最終ブロックと、長さが６ブロックであると識別されるメッセージＤの最初の３つのブロックとを提供している。いずれの場合も、適切な数のブロックが確保されている。
【００５５】
図１３は、Ｎ＋４に先立ってパケットＮ＋５を受信した結果を示す。パケットＮ＋５は、パケットＮ＋１がドロップされたときに失われた、メッセージＡからの欠損している最初の３つのブロックとメッセージＢからの２つのブロックとを提供する。メッセージＡおよびＢは、完了するにつれて、バッファから抽出される。図１４は、Ｎ＋５の後のパケットＮ＋４およびＮ＋６の受取によってシーケンスを完了する。これによりバッファから抽出されるメッセージＣが完成する。
【００５６】
データブロックの再送が発生しない状況というものがある。具体的には、ビデオデータに再送する価値がないとみなされる場合、受信バッファは部分的なメッセージを保持し、バッファが効果的にブロックされる。この設計は、既存の不完全なメッセージのせいで新しいメッセージを受信バッファに追加できない場合には、新しいメッセージのためのスペースを作成するために不完全なメッセージが削除されるということを前提としている。このようにして古いメッセージは破棄される。再送プロセスが失われたブロックを未だ回復しようとしている間は不完全なメッセージが破棄されないように、受信バッファは十分に大きくすべきである。
【００５７】
エンコーダ２における帯域幅モニタ２０の動作を、図１５の流れ図を参照して説明する。ステップ５０において、帯域幅モニタ２０は、チャネルにおける瞬時帯域幅ＢＩ（ｔ）を決定する。これは、ＵＤＰパケットの生成に続いて、下記の式に従って各エポックに対して計算される。
【数１】
0006669765.tif 000002
ここで、
ＳＮＳ（ｔ）  送信待ちのビデオバッファ内の現在のバイト数
ＳＮＳ（ｔ−１）  前回のエポックでの送信待ちのビデオバッファ内のバイト数
ＮＮＳ（ｔ）  送信待ちの非タイムクリティカルバッファ内の現在のバイト数
ＮＮＳ（ｔ−１）  前回のエポックでの送信待ちの非タイムクリティカルバッファ内のバイト数
ＳＡ（ｔ）  ビデオバッファに割り当てられている現在の総バイト数
ＳＡ（ｔ−１）  ビデオバッファに割り当てられた前回の総バイト数
ＮＡ（ｔ）  非タイムクリティカルバッファに割り当てられている現在の総バイト数
ＮＡ（ｔ−１）  非タイムクリティカルバッファに割り当てられた前回の総バイト数
Ｔ（ｔ）  現在のサンプル間隔でのミリ秒の単位での時間。
Ｔ（ｔ−１）  前回のサンプル間隔でのミリ秒の単位での時間。
ＢＡ（ｔ−１）  ビット／秒の単位での平均帯域幅の前回の推定値
ＢＥ  チャネルにおける最大許容帯域幅
ＢＩ（ｔ）  チャネルにおける瞬時帯域幅
このように、チャネルの瞬時帯域幅ＢＩ（ｔ）は、最新のＵＤＰパケットを送る際にマルチプレクサ１８によって利用される帯域幅である。
【００５８】
実際には、パケットは等しい時間間隔で伝送されない。したがって、瞬時帯域幅のよりしっかりした測定値を提供するために、下記の式に従って、Ｓ個のサンプル点で取られるスライディングウインドウにわたって測定される：
【数２】
0006669765.tif 000003
ステップ５２において、帯域幅モニタ２０は、エンコーダ２とサーバー４との間のＵＤＰパケットの往復時間（round trip time）を測定するように構成される。これは、エンコーダ２によるＵＤＰパケットの伝送に続いて、サーバー４から受信確認を受信するのにかかる時間を測定することによって達成される。測定される往復時間ＲＣ（ｔ）は、チャネルの性能のための有用な指標である。安定したチャネルでは、往復時間は低く、変動性は低い。往復時間が増加する場合、これは、チャネルにおける帯域幅利用可能性がエンコーダ２によって要求されるよりも少ないということの指示である可能性がある。
【００５９】
ステップ５４において、帯域幅モニタ２０は、往復時間の減衰された平均（damped average）ＲＢ（ｔ）を更新するように構成される。移動時間（trip time）の現在の値が減衰された平均の前回の値より大きい場合（すなわちＲＣ（ｔ）＞ＲＢ（ｔ−１））、ＲＢ（ｔ）は次の式に従って計算される。
【数３】
0006669765.tif 000004
さもなければ、ＲＢ（ｔ）は次の式に従って計算される。
【数４】
0006669765.tif 000005
これらの式において、
ＲＢ（ｔ）  現在のエポックについての往復時間の推定値
ＲＢ（ｔ−１）  ベース往復時間の前回の推定値
ＲＣ（ｔ）  ミリ秒で表した往復時間の現在の測定値
κ  適応レートを制御する減衰係数
である。往復時間の減衰された平均は、チャネルにおける変動性（volatility）が正常な限度内にない個々の結果を生じる可能性があるため、移動時間の現在値よりも有効な尺度になり得る。上記の式は、現在観測されている移動時間の値と一致するＲＢ（ｔ）の急速な下方修正を許す。しかし、ＲＢ（ｔ）の上方修正はよりゆっくりとなる。セルラーチャネルの特性によって、減衰係数κの注意深い選択が、最適な性能のために必要とされ得る。
【００６０】
ステップ５６において、帯域幅モニタ２０は、観測された往復時間に基づいて、チャネルにおける平均帯域幅の平滑化された平均ＢＡ（ｔ）を更新するように構成される。平均帯域幅は、次の式に従って計算することができる。
【数５】
0006669765.tif 000006
ここで、
ＢＡ（ｔ−１）  ビット／秒の単位での平均帯域幅の前回の推定値
ＢＡ（ｔ）  ビット／秒の単位での平均帯域幅の新しい推定値
ＢＥ  ビット／秒の単位での帯域幅の特定された上限値
Ｆ  適応レートを制御する係数
であり、
【数６】
0006669765.tif 000007
である。したがって、ＢＡ（ｔ）は、チャネルにおいて現在利用可能な帯域幅の有用な推定値を提供することができる。上記の式から、現在の移動時間が減衰された平均移動時間に対して低い（すなわちＲＣ（ｔ）＜ＲＢ（ｔ））場合、ＢＡ（ｔ）が増加することが認識できる。ＢＡ（ｔ）の最大値は、その特性に従って、チャネルの帯域幅の規定された限界であるＢＥである。逆に、現在の往復時間が減衰された平均移動時間に対して高い（すなわちＲＣ（ｔ）＞ＲＢ（ｔ））場合、ＢＡ（ｔ）は減少する。
【００６１】
ステップ５８において、帯域幅モニタ２０は、ビデオバッファ２６に割り当てられたビデオブロックの数と、非タイムクリティカルデータバッファ２８に割り当てられた非タイムクリティカルデータブロックの数を監視するように構成されるが、まだ送られてはいない（ＳＮＳ（ｔ）およびＮＮＳ（ｔ））。これらの係数は、ステップ６０において、ストリーミング帯域幅ＢＳの計算に使用することができる。
【００６２】
ステップ６０において、帯域幅モニタ２０は、ストリーミング帯域幅ＢＳを計算するように構成される。ストリーミング帯域幅は、圧縮データが圧縮器１６によって出力されるべきレートに対応する。こうして、より低いストリーミング帯域幅が必要とされる場合、圧縮器１６は入力ビデオストリームを必要な帯域幅での圧縮データに変換するために、より高い圧縮係数を使用しなければならない。逆に、より高いストリーミング帯域幅が必要とされる場合、圧縮器１６は入力ビデオストリームを圧縮するときにより低い圧縮係数を使用することができる。圧縮器１６によって行われる圧縮には損失があり、これは、より高い圧縮係数が使用されたときはより低い品質の出力が生成されることを意味する。
【００６３】
ストリーミング帯域幅ＢＳは、下記の式に従って計算される。
【数７】
0006669765.tif 000008
ここで、σは、送られたが、現在のベース往復時間に基づく許容量を超えても受信確認されないデータの量を表し、
【数８】
0006669765.tif 000009
ＳＳＵ（ｔ）  送られたが受信確認されなかったビデオバイトの現在の数
ＮＳＵ（ｔ）  送られたが受信確認されなかった非タイムクリティカルバイトの現在の数
である。
【００６４】
往復時間が往復時間の減衰された平均に比較して高いとき（すなわち、ＲＣ（ｔ）＞ ＲＢ（ｔ）のとき）、ＢＳは小さくなることが認識できる。これは、往復時間が長いときには、より低いストリーミング帯域幅が使用されることを意味し、これはチャネルの平均帯域幅がより低いことを示す。エンコーダ２は、圧縮されたビデオの品質を低下させ、圧縮係数を増加させることによって、チャネルにおいて変化する状況が検出されたとき、これらの状況に適応することができる。
【００６５】
往復時間が往復時間の減衰された平均と比較して低いとき（すなわち、ＲＣ（ｔ）＜ＲＢ（ｔ）のとき）、ＢＳの値はＢＡに向かおうとする。言い換えれば、ストリーミング帯域幅は、条件が良好であり往復時間が低いときには、チャネルにおける平均帯域幅に近い値をとる。これにより、帯域幅が利用可能であるらしいときに、圧縮器１６は、より低い圧縮率を使用し、より高品質のビデオの伝送を可能にすることができる。
【００６６】
ＢＳの計算はまた、ビデオバッファ２６内で送られるのを待機しているバイト数であるＳＮＳ（ｔ）も考慮する。具体的には、ビデオバッファ２６内にキューに入れられたビデオデータがある場合、ＢＳは低減される。これは、後続のビデオフレームを圧縮するためにより高い圧縮係数が使用されることを意味し、ビデオデータからのチャネルに対する圧力を低減する。圧縮器１６によって生成されるデータレートを低減することにより、マルチプレクサ１８は、続くエポックにおいてビデオバッファ２６をより良好にクリアすることができる。
【００６７】
一般に、データがビデオバッファ２６でキューに入れられることは普通望ましくないので、ビデオ待ち時間を最小にするためにＢＳが計算される。これらのバイトがビデオバッファ２６に累積する１つの方法は、タイムクリティカルデータがタイムクリティカルデータバッファ３０から送られる場合である。タイムクリティカルバッファ３０に割り当てられたデータは、ビデオバッファ２６および非クリティカルデータバッファ２８のデータよりも優先される。したがって、タイムクリティカルデータが送られるとき、これは、通常、データブロックをビデオバッファ２６に蓄積させる。上記の式は、これらの状況でＢＳが下方修正されることを示す。これにより、ビデオバッファ２６でキューに入れられたデータを送ることができるようにライブビデオのデータレートを低下させることができる。この設計は、タイムクリティカルデータがビデオデータよりも優先順位を付けられて、緊急の事項としてサーバー４に送られることを可能にする。監視アプリケーションでは、タイムクリティカルデータは、スイッチまたは赤外線（ＩＲ）センサをトリガすることを含み得る。これらのデータを含むアラームを、データが利用可能なときにすぐに送ることが可能である。好都合なことに、ライブビデオの供給への影響は、普通、ユーザデバイス２２での人間の視聴者には知覚できないであろう。
【００６８】
伝送の失敗もまた、ビデオバッファ２６でビデオデータをキューに入れさせる可能性がある。図５〜図１１を参照して説明したように、受信確認がサーバー２から受信されない場合、ビデオバッファ２６内で再伝送のためにブロックがアクティブにされるかもしれない。そのようなブロックがビデオバッファ２６に存在すると、これはＢＳの下方修正をもたらす可能性がある。ライブビデオのデータレートを下げることによって、関連するブロックを再伝送するためにチャネル内にスペースを作り出すことができる。
【００６９】
タイムクリティカルデータの伝送を遅延させるので、正常な動作状態ではタイムクリティカルデータバッファ３０でデータをキューに入れることは想定されていない。これは、タイムクリティカルデータの発生レートがチャネルの瞬時帯域幅ＢＩ（ｔ）よりも大きい場合にのみ起こり得る。タイムクリティカルデータの発生レートは、チャネルの帯域幅と比較して小さい可能性が高いので、ほとんどの場合これは起こりそうにない。しかしながら、それが起きると、タイムクリティカルデータバッファ３０内でキューに入れられたデータをクリアすることができるように、ビデオエンコーダ２はビデオデータを送ることをやめる。その後、ビデオデータの伝送を再開することができる。
【００７０】
ＢＳの計算はまた、非タイムクリティカルデータバッファ２８内の非タイムクリティカルデータブロックの数であるＮＮＳ（ｔ）も考慮する。上記の式から認識できるように、ＢＳの値は、非タイムクリティカルデータがバッファ２８でキュー入れられたときはいつでも減少する。これは、帯域幅を非ビデオデータに利用可能にするために、チャネルにおいてビデオファイルによって消費される帯域幅の量を減少させる。この帯域幅は、必要とされるときはいつでも、非タイムクリティカルデータを送るためにマルチプレクサ１８内で使用される。これにより、ライブの供給を中断させることなく、圧縮係数を修正することによって非タイムクリティカルデータをビデオデータと共に伝送することが可能となる。非タイムクリティカルデータは、ビデオバッファ２６が空であり、帯域幅がチャネルにおいて利用可能である場合にのみ伝送される。このようにして、ビデオデータは非タイムクリティカルデータより常に優先することができ、非タイムクリティカルデータは、一旦、チャネル内にスペースが形成され、ビデオバッファ２６が完全に空になるようにＢＳが調整されたときにのみ伝送される。これにより、ビデオデータの待ち時間を導入することなく非ビデオデータが伝送されるのを可能にすることができ、これは一部のセキュリティ監視アプリケーションでは不可欠である。
【００７１】
ステップ６２において、帯域幅モニタ２０は、ＢＳの計算結果を圧縮器１６に送る。圧縮器１６は、その後、圧縮されたビデオが所望のストリーミング帯域幅で出力されるようにするためにその圧縮係数を調整する。
【００７２】
ＢＡ（ｔ）およびＢＳの計算のための上記の式は、一部のプラットフォームでは利用できず、評価するのが複雑になる可能性がある、ｔａｎ−１ｘ関数を用いることを含む。計算速度を向上させるために、これらの計算の両方を近似することが可能である。
【００７３】
もし、ＲＢ（ｔ）≦ＲＣ（ｔ）ならば、δは次のように近似してもよい。
【数９】
0006669765.tif 000010
さもなければ、
【数１０】
0006669765.tif 000011
ＢＳの計算を簡単にするために、送信待ちの全データと、送られたがベース往復時間に基づく許容量を超えても受信確認されないデータとの、現在の往復時間とベース往復時間との比に基づいた重み付けをされた総計としてＱを定義することが可能であって、すなわち、
【数１１】
0006669765.tif 000012
すると、ストリーミング帯域幅ＢＳは、ＱおよびＢＡ（ｔ）から次のように導出することができる。
Ｑ≦ＢＡ（ｔ）ならば、
【数１２】
0006669765.tif 000013
さもなければ
【数１３】
0006669765.tif 000014
【００７４】
図１６は、エンコーダ２において取られる決定を示す論理的流れ図である。ステップ７０で、ビデオカメラ１０はビデオの録画を開始し、マルチプレクサ１８はサーバー４に送るためのＵＤＰパケットの生成を開始する。ステップ７２で、「時刻まで待つ」（wait to time）フラグが現在のシステム時間に等しくセットされる。ステップ７４で、マルチプレクサ１８は、パケットシーケンス番号をインクリメントし、ＵＤＰペイロードパケットヘッダを構築する。ステップ７６で、マルチプレクサ１８は、タイムクリティカルデータバッファ３０内にブロックが存在するかどうかを分析する。このバッファ３０に何かしらのブロックが存在する場合、それらは、ＵＤＰパケットに含めるために優先順位付けされる。したがって、ＵＤＰペイロードに空き容量がある場合（すなわち、３７バイト以上の利用可能なスペースがある場合）、タイムクリティカルデータバッファ３０からのメッセージブロックは、ステップ７８でＵＤＰペイロードにコピーされる。タイムクリティカルデータバッファ３０内にブロックがない場合、マルチプレクサ１８はＵＤＰペイロード内に空き容量があるかどうかを再び分析する。空き容量がある場合、マルチプレクサ１８は、ステップ８０で、ビデオバッファ２６に保留中のブロックがあるかどうかを分析する。何かしらのビデオブロックが存在する場合、これらはステップ８２でマルチプレクサ１８によってＵＤＰペイロードにコピーされる。ＵＤＰペイロードに空き容量がある場合、マルチプレクサ１８は、ステップ８４で、非タイムクリティカルデータバッファ２８に保留中の何かしらのメッセージブロックがあるかどうかを分析する。これらのブロックはステップ８６でＵＤＰペイロードにコピーされ、実際、ペイロードにコピーされるブロックの数は、その空き容量に依存する。ＵＤＰペイロードがいっぱいであるか、またはバッファ２６、２８、３０のいずれにもデータブロックがない場合、ＵＤＰパケットはステップ８８でサーバー４に送られる。このようにして、マルチプレクサ１８は、ＵＤＰパケットにおいてタイムクリティカルデータに優先順位を付けることができ、ビデオデータ、非タイムクリティカルデータが続く。これにより、タイムクリティカルデータが存在するときに遅延なく送ることができる。ＵＤＰパケットに使用可能なスペースがあるときはいつでも、ＵＤＰパケットを完成するために、非タイムクリティカルデータを使用することができる。これにより、ユーザデバイス２２でのライブビデオの経験を中断させることなく、非タイムクリティカルデータを長い期間にわたってダウンロードすることが可能になり、または必要に応じてタイムクリティカルデータを迅速に報告することができる。
【００７５】
ステップ９０で、マルチプレクサ１８は、サーバー４からＵＤＰパケットを受信していたかどうかを分析する。パケットが受信されていると、それはステップ９２で読み取られる。ブロックを削除することができるように、何かしらのＵＤＰパケット受信確認がステップ９４で抽出され、関連するバッファ２６、２８、３０に伝達される。次にＵＤＰパケット内のメッセージブロックはステップ９６で抽出され、受信データバッファ３２に割り当てられる。
【００７６】
ステップ９８で、エンコーダ２は、現在のシステム時間が「時刻まで待つ」フラグ以上になるまで待機する。これにより、エンコーダ２がサーバー４から期待されたＵＤＰパケットを受信するのに十分な時間が経過することが可能になる。「時刻まで待つ」期間を超えると、帯域幅モニタ２０は、図１４に提示されたプロセスに従って、ステップ１００で平均帯域幅ＢＡ（ｔ）およびストリーミング帯域幅ＢＳを計算する。そして、マルチプレクサ１８が次のＵＤＰパケットを構築し始めることができるよう、プロセスはステップ７４に戻る。
【図１】
0006669765.tif 000015
【図２】
0006669765.tif 000016
【図３】
0006669765.tif 000017
【図４】
0006669765.tif 000018
【図５】
0006669765.tif 000019
【図６】
0006669765.tif 000020
【図７】
0006669765.tif 000021
【図８】
0006669765.tif 000022
【図９】
0006669765.tif 000023
【図１０】
0006669765.tif 000024
【図１１】
0006669765.tif 000025
【図１２】
0006669765.tif 000026
【図１３】
0006669765.tif 000027
【図１４】
0006669765.tif 000028
【図１５】
0006669765.tif 000029
【図１６−１】
0006669765.tif 000030
【図１６−２】
0006669765.tif 000031
【図１６−３】
0006669765.tif 000032