ビデオ通話のような小規模なものまで、様々な用途の基幹技術として活用されています。サービスの品質)技術についてご紹介したいと思います。具体的には、パケットロスやジッタと言ったエラーの訂正と回復を行い、公衆インターネット回線を使っても安定且つセキュアにビデオをデリバリーできる最先端技術です。伝送や、コンテンツ配信用のライブフィード(配信システムへの映像ソース信号の取込み)等への利用に期待されています。この分野においてどのような技術が存在し、それらに対応する製品や最適な用途などを紹介したいと思います。話の本題に入る前に、通信回線について簡単に触れておきたいと思います。使用する回線によって、通信の安定性とビデオ品質、遅延量、そしてコストに大きく影響します。通信衛星を経由した回線です。広大な範囲をカバーする通信の広域性と多数の受信局へ同時送信できる同報性、回線の安定性、速度などが強みです。火災や地震に強い面がある一方で、悪天候(豪雨)や太陽の活動によって通信品質が下がる場合があります。衛星の打ち上げやメンテナンスのコストの回収が必要になるため、料金は高額になります。契約者のみが使用できる拠点間ネットワークの経路を、物理的または論理的に設けます。契約者以外のデータは一切流れないので、通信品質を高く保ちます。通信速度やバンド幅、距離、品質によって料金が異なります。複数拠点との接続や超長距離間(海外など)での利用では、衛星回線のほうが有利な場合があります。公衆回線とはすなわち、インターネットです。世界中の膨大な数の人たちが日々利用しています。多種多様な業者とサービスが存在し、利用時間や場所など様々な要因によって、速度や安定具合が大きく変化します。日本国内は比較的安定した転送速度と品質を保てますが、業務用途のビデオストリーミング品質までは厳しい場合があります。(監視カメラ)など)のビデオストリーミングの場合、ほとんどのケースでデータ転送の安定性と、低遅延且つ高画質を要求されるため、回線の選択はシビアです。そのため、業務用途では衛星または専用回線が選択されるケースが多いと思います。衛星と専用回線のコストは高額になりがちで、画質と遅延量を予算の範囲内に収めるために四苦八苦している、と言うのもよく聞く話です。UDP公衆インターネット回線で、ビデオストリーミングを低遅延且つ安定した品質に保つことが難しいのは、インターネットで使用されるプロトコルにも原因があります。ここでいう「プロトコル」とは、デジタルデータの送受信に利用される基本的な通信規格だと思ってください。種類のプロトコルが存在します。どちらもビデオストリーミングに使うことが可能ですが、これらのリスクが伴うため低遅延且つ安定した品質を保つことが難しいです。ページや電子メールなどのデータ転送に使用される、基本的なプロトコルです。データをパケット単位に分割して転送し、受信側で元の形へ再構築します。Acknowledge)が確認されるまで同じパケットを再送信し続けます。確実なデータ転送を確保していますが、パケットロスによってデータ転送の遅延が発生します。)ではパケットロスが増え、遅延も増加します。その結果としてビデオストリーミングで利用した場合に、大きな遅延やバッファ不足によってビデオの再生が停止する場合もあります。低遅延を要求されるビデオストリーミングの用途には不向きなプロトコルなのです。よる遅延を許容するためです。同様にデータをパケット単位に分割して転送しますが、非常に簡素に且つ高速にデータの送受信を行えるプロトコルです。パケットロスの際の再送要求や、ジッタ(データ転送時にパケットが到着するまでの時間間隔が均一でないために生じる問題)防止機能がない信頼性の低いプロトコルです。小サイズで応答性が重要視される通信で使用されています。)ではパケットロスが増え、その結果としてデータ未達によって映像や音声にノイズが発生する場合があります。運ぶとどんな違いがあるのかを図にしてみました。場合、「水」はボトルごと番号順に送られ、パケットロスが発生した場合は、その番号から順番通りに送り直します。仮に後の番号の「水」が先に到着した場合は、後の番号の「水」は破棄され、順番通り確実に元通りになるよう受信側で格納されます。リットルの水」になります。場合、「水」をとにかく受信側へ送ります。途中の経路で「水漏れ」や「水はね」でパケットロスが生じるかもしれませんが気にしません。受信側では届いた順に受け入れます。経路の状況が良ければ元と同じに近い量が格納されますが、悪ければほとんど届かない可能性もあります。上記の「水」のようにとにかくデータを素早く送ることができるためです。)をどうにか高められないか。技術は進歩してきました。現在では海外イベントの日本向け配信に使うライブフィードに利用されるなど、少しづつ実績も増えつつあります。技術(製品)が誕生しました。受信側とで、データが正しく届いたか否かを確認しつつ、データ転送の確実性を高める誤り制御方法のひとつです。単純な自動再送要求の手法です。送信側はデータを送信後、そのデータの受信確認通知が届くかタイムアウトするまで次のデータを送りません。そのため他の手法に比べて効率が良くありません。受信確認通知が届かなくても決められたサイズに達するまでデータを送信し続け、受信側は受信したデータの固有番号を含めた通知を送ります。エラーがあった場合は、最終通知番号の後から全てのデータを再送信します。決められたサイズに達するまで送信側はデータを送信し続け、受信側はデータを受信し続けます。限界まで達したら、受信側は未達データの固有番号を含む通知を送信側に送り、送信側はその通知に該当するデータを再送信します。同様に、データ転送の確実性を高める誤り制御方法のひとつです。転送するデータに冗長性を付加することで、データの再送信をすることなく誤り制御を実現できます。普通にデータを送るよりも、冗長性の分だけデータ容量が大きくなりますが、何度も同じデータを送る必要はなくなります。遅延の原因となる再送信を必要とせずに、転送の確実性を高めることが可能です。オプションを搭載している動画エンコーダも最近では珍しくありません。方式が使われています。予測不能なネットワーク上におけるストリーミングパフォーマンスを最適化する、オープンソース・ビデオトランスポート・プロトコルであり、テクノロジースタックです。不安定な公衆インターネットを通じて、低遅延且つセキュアに、容易なファイアウォールトラバーサルでベストな品質のライブビデオを届けることを目標としています。アライアンス)を設立し、オープンソース化しました。手法に加えて、高解像度のタイムスタンプをパケットに追加し、メディアストリームのタイミングを受信側の出力で正確に再構成できるようにします。これにより、ダウンストリームのデバイスが適切にデコードできるようになります。効果を知るためのデモンストレーションビデオです。パケットロスを発生させた場合における画質と遅延量の違いを見て取れます。プラットフォーム(ソフトウェア)の開発および提供をしています。プロトコルは様々な誤り訂正技術を駆使して、不安定なインターネット接続におけるバンド幅を最大化、距離に依存せずに安定したストリーミングを提供します。プラットフォームはクラウド上に配備することもでき、海外からのライブストリームの中継地点にしたり、一拠点から複数拠点へストリーミングをデリバリーするためのハブに使ったり、スタジオ間など近距離での利用にも有効です。具体的な誤り訂正技術の内容までは公開されていません。効果を知るためのデモンストレーションビデオです。29.97)の画質を比較しています。どちらが良いか一概には言えませんが、参考までに以下のようにまとめてみました。パケットロスへの耐性どれくらいのパケットロスまで耐えられるか。ほうが強いように思われます。同じ耐性値になる可能性もあります)。セキュリティどちらも互角です。両者共に暗号化によって保護されたストリーミングを実現しています。対応製品が販売されています。オープンソースですので参入障壁が低く、今後対応製品が増えてくると思われます。オプションなど)で提供されています。対応製品が多いように思います(ただし、いくつかは既に販売終了している可能性があります)。別料金オプションにする可能性もありますが、オープンソースですので高額にはならないと思います。ソフトウェア製品(年間契約のサブスクリプション)で、使用するデータ量によって価格が変動します。オプションは基本有償です。対応する製品をいくつかご紹介します。組み込んだ製品などを提供しています。普及活動を率先して行っています。Engine」は業界標準とも言えるソフトウェアです。使って様々な用途が考えられます。出力だけでなく配信用フォーマットにトランスコードすることもできます。デコーダ製品である「Cube」に搭載しました。ビデオを配備できる堅牢且つポータブルなシャーシに収めました。