ライブネットワーク映像監視の遅延

IP映像監視におけるライブストリーミングのプロセスは、カメラでビデオをキャプチャーし、パッケージ化してネットワーク経由で伝送し、レシーバーで解凍して表示するという構成になります。これらの各ステップは、多かれ少なかれ遅延を加算します。

• カメラ側で生じる遅延。 ビデオのキャプチャーの後には、画像処理、圧縮、パッケージ化が続きます。各ステップで遅延が生じますが、全体的に見ると、カメラ内の処理はエンドツーエンド遅延全体のごく一部に過ぎません。

• ネットワークで生じる遅延。 これは非常に大きい場合も小さい場合もあり、エンドツーエンド遅延の「方程式」の中で最も予測不可能な要素です。優れたネットワークソフトウェアとハードウェアに投資することで、予測可能性を高めることができます。ネットワーク遅延は、データと帯域幅の比率に大きく依存します。カメラが生成するデータ量を減らすように設定することで、ネットワーク経由で送信する必要があるパケット量を減らすことができます。

• クライアント側で生じる遅延。 クライアント側では、データが受信され、バッファされ、ソートされてから、グラフィックカードとモニターにキューイングされます。この遅延はクライアントの受信バッファによる影響が最も大きく、数秒に及ぶこともあります。大きなバッファがないと、ビデオストリームが均等に再生されないリスクがあります。

遅延の低減は、常にコストとの相談になります。ネットワークとクライアント側のハードウェアとソフトウェアを改善することで、最大限の成果を収めることができます。

映像監視において遅延とは、フレームがキャプチャーされてから同じフレームがディスプレイされるまでの時間のことです。これはエンドツーエンド遅延またはセンサーツースクリーン遅延とも呼ばれます。カメラセンサーからディスプレイモニターにフレームを伝送するプロセスには、複数のステップからなる長いパイプラインがあります。

このホワイトペーパーでは、総遅延の原因となる、さまざまなステップについて概説します。また、どのようにすれば遅延を短縮できるかについても説明します。

遅延の定義は文脈によって異なります。ネットワーク技術において遅延とは、ある情報が送信元から送信されてから、同じ情報が最終目的地で受信されるまでに生じる遅れとして一般的に認識されています。

本稿では、ネットワーク映像監視システムにおける遅延について説明します。ここでは遅延を、画像がカメラでキャプチャーされてからビデオディスプレイに表示されるまでの遅れと定義します。その期間に、画像がキャプチャーされ、圧縮され、送信され、解凍され、そして表示されます。各ステップでの遅れが加算されて全体の遅延になります。簡単に言うと、エンドツーエンド遅延は次の3つの主要な段階から構成されると認識できます。

• カメラで生じる遅延（画像処理遅延、圧縮遅延）

• ネットワークで生じる遅延（伝送遅延）

• 受信側で生じる遅延（クライアントバッファ、解凍遅延、表示遅延）

映像監視システムの遅延目標を満たすには、ビデオソリューションの設計時にこうした遅延をそれぞれ考慮する必要があります。

遅延は通常、秒またはミリ秒（ms）という時間単位で表されます。カメラとディスプレイ装置のクロックを正確に同期させる必要があるため、正確な遅延を測定するのは非常に困難です。簡単な方法（正確な値からのずれを最小限に抑える方法）の1つとして、タイムスタンプオーバーレイテキスト機能を使う方法があります。この方法では、映像監視システムのエンドツーエンド遅延、つまり、レンズで1つの画像フレームをキャプチャーしてから、同じフレームが監視装置でレンダリングされるまでの時間差を測定します。

この方法では、最大1フレーム間隔の誤差が生じる可能性があることに注意してください。これは、遅延の計算に使用されるタイムスタンプがフレームキャプチャー時にのみ取得されるという事実によるものです。したがって、フレームレートの単位でしか遅延を計算できません。すなわち、フレームレートが25fpsの場合、遅延は40msの倍数として計算できます。フレームレートが1fpsの場合、遅延は1秒の倍数として計算できます。したがって、この方法はフレームレートが低い場合には推奨されません。

タイムスタンプオーバーレイテキスト機能を使用して遅延を測定するには:

1. （%T:%f）を使用してオーバーレイのタイムスタンプをオンにします。

2. カメラを所定の角度で設置し、カメラ自体のライブストリーム出力をキャプチャーできるようにします。

3. ライブストリーム出力のスナップショットを撮り、元のテキストオーバーレイに表示された時間と画面ループに表示された時間との時間差を比較します。

総遅延は、カメラ、ネットワーク、クライアント側で生じる遅延の合計です。

各フレームの露出時間は約1/30秒で、その後、画像のスケーリングとエンコードに短い時間がかかります。エンコードされた画像は切り刻まれてパッケージ化され、33msごとに1枚ずつネットワークに出力されます。カメラ内でこの処理にかかる時間は50ms以下になる可能性もありますが、数百msであることが一般的です。この数値は、カメラ（PTZは除く）や、フレームがIフレームかPフレームかによって若干異なります。

ビデオカメラの内部を見てみましょう。カメラのイメージセンサーは、ピクセルと呼ばれる何百万もの光検出器（感光部）で構成されています。センサーは、1回の露出インターバルを通じてピクセルに光をキャプチャーし、その後で、記録された光エネルギーを電子信号に変換します。これにより、ピクセルが空になり、次の露出の準備ができます。センサーが時間単位当たりに提供する露出回数、つまりカメラが秒あたりにキャプチャーできるフレーム数がセンサーのキャプチャーレートを定義します。

キャプチャー遅延はキャプチャーレートに依存します。キャプチャーレートを30fpsに設定した場合、つまりイメージセンサーが1/30秒ごとに1枚の画像をキャプチャーする場合は、キャプチャー遅延が最大33.3msになります。

キャプチャーされた各フレームは、デインターレース、スケーリング、画像回転などの画像処理ステップのパイプラインを通過するため、遅延が生じます。処理が増えるほど、カメラで生じる遅延が増えます。しかしながら、カメラでの処理はデータの生成量に影響するため、処理量はネットワーク上でデータが転送される際のネットワーク遅延にも影響します。

遅延に影響するパラメーターには以下が含まれます。

• 画像の回転。ビデオストリームを90度または270度回転させると、エンコードプロセッサへの負荷が増えます。ピクセルを再配置してバッファリングする必要があるため、いくらかの遅延が生じます。

• 解像度。解像度が高いということは、プロセッサがエンコードするピクセル数が多いことを意味します。低解像度と比較して高解像度の処理時間の増加は、高解像度カメラの高速処理ユニットで挽回できるため、通常は軽微です。しかしながら、解像度が高いほど、フレームあたりのデータ量が多くなるので、伝送されるパケット量が増える結果となります。帯域幅が限られたネットワークでは、伝送時に遅延が発生する可能性があります。その結果、受信側でより大きなバッファが必要になるので、遅延が長くなる原因となります。

• ノイズフィルタリング。高度なノイズフィルタリングには複数フレームのバッファリングが必要になり、これがさらなる遅延を生じさせます。

• プライバシーマスク機能。AXIS LivePrivacy Shieldなどの高度なプライバシーマスク機能は、さらなる遅延をもたらす可能性があります。これは、正しいプライバシーマスクを正しいタイミングで適用するのにバッファリングが必要になるためです。

ビデオは、転送前にデータを圧縮するためにエンコードされます。圧縮には、画像データを削除する1つまたは複数の数学的アルゴリズムが関与します。これには、処理するデータ量によって多少時間がかかります。このステップで生じる圧縮遅延は、次のような圧縮の側面に影響されます。

• 圧縮アルゴリズムの複雑さ

  H.264とH.265は、MJPEGよりも高度な圧縮方式です。ただし、Axisカメラは、MJPEG圧縮を使用した場合よりも、H.264やH.265圧縮に大きな容量を使用できるのが普通であるため、H.264やH.265の圧縮遅延が必ずしも大きくなるわけではありません。一方、デコードサイトでは遅延が大きくなる可能性があります。Axisカメラが生成するH.264およびH.265データストリームでは、デコーダが少なくとも1フレームをバッファする必要がありますが、MJPEGデコードではバッファが不要です。さらに、Zipstreamストレージプロファイルでは、最大2フレームの遅延が追加されます。つまり、30fpsのビデオでは66.7msになります。

• 圧縮方式の有効性

  Axisカメラで最も一般的に使用されているエンコード方式は、MJPEG、H.264、H.265です。こうした方式は、いずれもカメラに遅延を生じさせます。H.264とH.265は、MJPEGと比べてビデオスループットを小さく抑えるため、少ないデータパケットでネットワークから送信し、解凍して、レシーバー側でレンダリングできます。これにより、総遅延が短縮されます。

• ビットレートの選択

  ビデオ圧縮はビデオデータサイズを低減します。ただし、圧縮後にすべてのフレームが同じサイズになるわけではありません。圧縮データのサイズはシーンによって異なる可能性があります。言い換えると、元になる圧縮データは可変ビットレート（VBR）のストリームで構成されており、結果的には可変ビットレートがネットワークに出力されことになります。ネットワーク帯域幅の制限など、利用可能なネットワークの制約を考慮する必要があります。通常は、ストリーミングビデオシステムの帯域幅制限に基づき、伝送ビットレートを調整する必要があります。エンコーダによっては、VBRと最大ビットレート（MBR）を選択できます。MBRを選択すると、データ量を制限してネットワーク受信することが保証されます。ネットワークへの過負荷を避けることで、ネットワーク遅延を減らし、システムのレシーバー側で必要になるバッファがあまり大きくならないようにします。

  Axisカメラでは、H.264とH.265エンコーダがVBRとMBRを選択できます。ただし、一般的な場合、シーンコンテンツに合わせてリアルタイムで品質を調節するネットワークビデオには、VBRの使用を推奨します。MBRビデオを配信するカメラは、危機的な状況で重要な証拠能力の高い高精細映像を消去せざるを得ない可能性があるため、一般的なストレージ削減ツールとして、またはネットワーク接続が弱い場所の固定用として常時MBRを使用することは推奨されません。

  カメラでZipstreamを使うとビットレートが下がります。これによってデータ量を抑え、ネットワーク遅延を短縮することができます。

• ストリーム数:カメラから複数の種類のストリーム（異なるフレームレートまたは解像度）が要求された場合は、すべてのストリームを同じプロセッサでエンコードする必要があるため、追加された種類のストリームを処理するのに遅延が生じます。

圧縮方法を選択する際は、こうした点をすべて考慮する必要があります。高度なエンコードアルゴリズムは、エンコードとデコードに時間がかかる一方で、インターネットを通じて送信されるデータ量を減らせる側面もあり、結果的にはトランジションの遅延が小さくなり、受信バッファのサイズを低減できます。

ビデオは1フレームずつ処理されるため、一度に圧縮できるデータ量は限られます。処理段階の間で短期バッファが必要になることがあり、カメラの遅延の一因となります。

ビデオストリームには音声が伴う場合もあります。音声エンコーダは、音声のエンコードを開始するブロックが利用可能になるまで、一定のサンプル数を待つ必要があり、カメラ側での遅延が増えます。音声エンコーダのアルゴリズムが異なると、サンプルレートとブロックサイズが異なります。

画像をキャプチャー、処理、圧縮した後、映像データはネットワークを経由してから、レンダリングのためにクライアント側に到達します。ネットワークが遅延にどのような影響を与えるかを理解するには、まずビデオネットワーキングの基本概念であるビットレート、帯域幅、スループットを理解する必要があります。ネットワーク遅延はビットレートに比例し、帯域幅に反比例します。

• ビットレートとは、単位時間当たりに処理されるデータ量（ビット数）のことを指します。映像監視において、ビットレートは単位時間あたりにネットワークを通じて送信するカメラ生成データの量として定義されます。ビットレートは多くの要因に依存し、撮影シーン、カメラの実行処理、ビデオストリームの設定に大きく左右されます。カメラが送信するデータ量が多い場合は、帯域幅が限られていると、ネットワーク遅延が大きくなることが予想されます。

• 帯域幅とは、カメラとモニター間のネットワークが処理できる可能性のあるデータ量のことです。リンクの最大能力を示します。帯域幅は、リンクの長さとインフラストラクチャー（スイッチ、ルーター、ケーブル、プロキシーなど）によって異なります。ネットワークの容量を増やせば、より多くのデータが通過できるようになり、遅延の低減につながります。

• スループットとは、実際に達成されたデータ転送の速度（ビット/秒）を指します。他の人とリンクを共有しているかどうかや、リンク内のケーブルの電磁干渉で異なります。また、ポートに設定されたQoS（Quality of Service）設定によって、スループットに上限が設けられることもあります。

ネットワークにおける総遅延は、カメラとビデオ表示装置間のリンクのインフラストラクチャー（帯域幅を決定する）、カメラによって生成されるデータ量（ビットレートを決定する）、および伝送プロトコルの選択という3つの主な要素によって決まります。

ネットワークはエンドツーエンド遅延の最も予測不可能な発生源です。スイッチ、ルーター、ケーブル、プロキシーといった、送信側と受信側の間にあるネットワーク内のあらゆるものが、総遅延に影響を与えます。LANの場合は、ネットワーク内の遅延がわずか数ミリ秒と非常に短いため、無視できます。しかし、ビデオストリームがインターネットで不特定の経路を使用して伝送される場合は、ネットワーク遅延の予測が困難になり、多くの場合、エンドツーエンド遅延の主な因子になる可能性があります。

慎重なネットワーク管理と帯域幅の割り当てにより、ネットワーク遅延の予測不可能な因子を予測しやすくすることができます。カメラと表示装置間のリンクは、スループットが保証されている必要があります。

LANでは、リンク内のホップをできるだけ少なくすることで可能になります。リンクは、Voice over IP (VoIP)、デフォルトでビデオよりも優先される他のプロトコル、またはリンクを過負荷にする他の要求の厳しいサービスなどの他のトラフィックと共有しないでください。

リンクがWAN (ワイドエリアネットワーク) を介している場合は、ルーターとスイッチなどの各ホップでQoSを保証する必要があります。これは、ローカルインターネットプロバイダーを介してポイントツーポイントルートをリースすることによっても実現できます。

スループットに影響を与える設定可能な要素：

• パッケージのオーバーヘッド（プロトコル依存例: VLANヘッダー）

• プロキシーとファイアウォール

• ルート全体の各リンクのQoS

• バーストモードの有無（有効にする —> 高速化）

• MTU - ビデオペイロードのサイズ

スループットに影響を与えるコスト関連の要素：

• スイッチとルーターのプロセッサスピードとポートバッファ

• ケーブル（またはワイヤレス）のタイプ

カメラの画像処理と圧縮方式の選択は、生成される映像データの量に影響するため、ネットワーク遅延に影響します。データ量が少なければ、当然ながら送信時間も短くなります。

カメラからのビデオフレームはトランスポートプロトコルアプリケーション（通常はRTPまたはHTTP）に渡されます。レンダリングクライアントへの伝送はIPネットワーク経由で行われます。この伝送は、失われたデータパケットの再送信が可能な信頼性の高いコネクション型プロトコルであるTCP、またはデータの到達を保証せず、失われたパケットの再送信機能を持たないUDPのいずれかを介して行われます。

Axisカメラでは、エンコードされたデータストリームを伝送用としてカプセル化する際に、以下のオプションがあります。

通常、TCPを介したパケットの伝送は、追加の接続設定、確認メッセージ、およびパケット損失検出時の再送信が必要なため、UDPを介するよりも時間がかかります。一方、UDPの場合は、パケットが途中で失われると、ビデオストリームにアーティファクトや中断が生じます。TCPはパケット損失時にジッターを発生させますが、UDPはパケット損失時にアーティファクトや中断を発生させます。データ損失や一時的な品質劣化を許容できるのであれば、帯域幅の狭いネットワークではUDPを選択できます。

TCPを使用する場合は、送信されるパケット数が多くなり、これをサポートするために帯域幅を大きくする必要があります。ネットワークが混雑していることが分かっている場合は、伝送プロトコルとしてUDPを選択すべきです。パケット損失が許容されるため、パケット損失に起因する画質の低下も同時に生じます。

WebRTCとアダプティブビットレートを使用すると、ネットワークに合わせて映像が調節されるので、TCPで起こりうるような制御不能な遅延スパイクを避けることができます。

ビデオシステムのクライアント側でビデオを受信した後、解凍、並べ替え、デコードが行われ、メディアプレーヤーがビデオのレンダリングに使用されます。各ステップがクライアント側で発生する総遅延に寄与し、コンピューター自体が重要な役割を果たします。CPU容量、OS、ネットワークカード、グラフィックカードが遅延に影響します。通常、MJPEGは、タイムコードがなく、データ到着時に画面に描画できるため、デコードと表示の遅延が最も少ない方式です。H.264やその他のビデオ圧縮規格では、各画像にタイムコードを割り当て、それに従ってレンダリングする必要があります。

多くの場合、実際のネットワークは非常に大きく複雑であり、バーストトラフィック挙動やパケット到着順序の入れ替わりが生じます。ネットワークトランスポートによる変動を補正するために、クライアント側でバッファが使用されます。このバッファは再生バッファまたはジッターバッファとも呼ばれ、パケットが正しい順序になるようにし、デコーダが「枯渇」しないように十分なデータをバッファリングすることで、ビューアに均一なフレームレートが表示されるようにします。

このバッファは、比較的大きな遅延をもたらします。ビューアアプリケーションによって再生バッファサイズは異なり、ほとんどのビューアはバッファサイズを変更できます。ただし、バッファを減らすとジッターが増加することにも注意してください。すなわち、ジッターと許容できる遅延のバランスを見つける必要があります。

再生において、音声ストリーミングは、ビデオストリーミングよりも、障害や遅延の影響を受けやすくなります。音声パケットが1つ遅延すると、サウンドトラックに耳障りな途切れが生じます。また、音声はビデオとリップシンクしなければなりません。このような理由から、ビデオに音声が伴う場合は、大きな再生バッファを設定する必要があり、当然遅延が大きくなります。

解凍処理に要する時間は、どのエンコード方式を使用するかによって異なります。デコード遅延は、グラフィックカードがサポートするハードウェアデコーダに大きく依存します。ハードウェアでのデコードは通常、ソフトウェアでのデコードよりも高速です。一般的に、H.264はMJPEGよりもデコードに時間がかかります。H.264でデコードする場合、遅延はエンコードの段階で選択したプロファイルにも依存します。ベースが最も簡単にデコードでき、メインとハイの場合は処理時間が長くなります。Axisビデオ製品によって生成されたH.264データストリームは、デコーダが少なくとも1フレームをバッファする必要があります。

ディスプレイ装置も、転送時間、リフレッシュレート、応答時間を通じて遅延に影響します。

転送時間とは、デコーダからケーブル（HDMIなど）を通って、デコードされた映像データがモニターに送信されるまでの時間です。転送時間はケーブルの速度とモニターの解像度によって異なります。標準的なHDMIケーブルで接続されたFHDモニターの場合、約10msの遅延が加算されます。

ディスプレイ装置のリフレッシュ周波数も遅延に影響します。コンピューターモニターの場合、リフレッシュレートは約17～20msですが、特別なゲーミングモニターのリフレッシュレートは4～5msです。

応答時間とは、モニターのピクセルの値の変更にかかる時間です。これは変更の大きさにもよりますが、値が大きく変わる場合は5～20msの遅延が加算される可能性があります。

低遅延の目標を達成するシステムを設計するには、その他のトレードオフが必要になります。許容できる遅延を決め、画質と監視システムのコストのバランスを見つける必要があります。本章では、エンドツーエンド遅延を低減するために、カメラ側、ネットワーク側、クライアント側に関するいくつかの簡単な推奨事項を示します。

• 解像度: 可能であれば低い解像度を選択します。解像度が高いほど、エンコードするデータ量が多くなり、遅延が大きくなる可能性があります。

• 画像処理: 回転、インターレース解除、拡大縮小などの画像処理を減らします。画像処理を使用すると、遅延が増加する可能性があります。

• 低遅延モード: プレイン設定で低遅延モードをオンにすることで、ライブストリームの画像処理時間を最適化できます。ライブストリームの遅延は最小限に抑えられますが、画質は通常より低下します。

• プライバシーマスク機能： プライバシーマスク機能は遅延を増加させるため、使用しないことを検討してください。

• エンコーディング: システムが求める遅延レベルを管理できるエンコーダであることを確認してください。データ量とネットワークインフラストラクチャーの容量のバランスをとる必要があります。ビデオを帯域幅の限られたネットワーク経由で送信する場合は、エンコード方式としてH.264またはH.265を選択します。これにより圧縮率が高くなるため、ビットレートが低くなります。ネットワークがビットレートを管理できる場合は、ベースラインプロファイルを選択してください。ベースラインの方がエンコードとデコードが簡単になるためです。

• Zipstreamのストレージプロファイル: ストレージプロファイルは遅延を増加させるため、使用しないことを検討してください。

• ストリーム数: カメラの設定を変えてストリーム数を制限します。解像度、フレームレート、圧縮レベルといった設定の組み合わせごとに、個別のエンコード処理が必要となるため、プロセッサに負荷がかかり、遅延の原因になります。

• ビットレート: 低いビットレートを使用するようにしてください。カメラの遅延を減らすには、生成されるデータ量を減らす必要があります。ビットレートは、圧縮レベル、解像度、フレームレートだけでなく、光条件、シーンのタイプなど、多くの要素に影響されます。

• フレームレート: できるだけ高いフレームレートを使用します。フレームは一度に1フレームずつエンコードおよびデコードされるので、バッファは少なくとも1フレーム遅延します。フレームレートが上がれば、バッファで発生する遅延は減少します。30fpsのストリームの場合は、各フレームのキャプチャーに1/30秒かかります。バッファでは最大33msまでの遅延を予想できます。25fpsの場合は、遅延が最大40msになります。

• キャプチャーモード: できるだけ解像度が低く、フレームレートが高いキャプチャーモードの使用を検討してください。解像度が低いほど処理するピクセル数が少なくなり、フレームレートが高いほどバッファ遅延が減少します。

• 音声: 音声を使わないことを検討してください。ビデオと同期する必要がある音声は、より大きな再生バッファを必要とするため、遅延が増加します。

カメラ側に関する推奨事項の多くは、ネットワークで送信される総データ量を制限することを目的としています。ほとんどの場合、ネットワーク上の制限がエンドツーエンド遅延の最大の因子です。ネットワークの容量が大きければ、上記の推奨事項の多くは必要ありません。ネットワークのQoS（Quity of Service）が良好であること、およびネットワーク内のすべてのホップがビデオの需要に合わせて設定されていることを確認してください。カメラからのデータ出力を配信できるように、ネットワーク上のビットレートが保証されていることを確認してください。

クライアント側の改善はエンドツーエンド遅延に大きな影響を与えます。通常、改善できることは多数あります。

プロセッサとグラフィックカード: CPUはクライアント側の遅延において中心的な役割を果たします。ビデオストリームを処理し、同時に他の要求も処理するのに十分な容量のある優れたプロセッサを使用してください。最新のソフトウェアでアップデートされている、デコード対応の優れたグラフィックカードを使用しましょう。

ビューア/VMS: ビューアの再生バッファが不必要に長くならないことを確認すべきですが、ビデオジッターとのトレードオフに注意してください。

ディスプレイ: できるだけリフレッシュレートの速いディスプレイを使用します。快適なライブ閲覧を実現するには（ただし、遅延には影響を与えない）、画面の周波数をカメラのキャプチャーフレームレートの倍数に調整します。たとえば、30fpsモードの場合は60Hz、25fpsモードの場合は50Hzとなります。