ビデオストリーミング QoS 〜ストリーミング技術最前線〜 | DPSJ

現在、IP ベースのビデオストリーミング技術は、コンテンツ配信サービスなどの大規模なものから、1 対 1 のビデオ通話のような小規模なものまで、様々な用途の基幹技術として活用されています。

この記事では、昨今注目されているビデオストリーミングの QoS （Quality of Service ：サービスの品質）技術についてご紹介したいと思います。具体的には、パケットロスやジッタと言ったエラーの訂正と回復を行い、公衆インターネット回線を使っても安定且つセキュアにビデオをデリバリーできる最先端技術です。拠点間の IP 伝送や、コンテンツ配信用のライブフィード（配信システムへの映像ソース信号の取込み）等への利用に期待されています。

この分野においてどのような技術が存在し、それらに対応する製品や最適な用途などを紹介したいと思います。

衛星回線

コスト：高
品質：安定

通信衛星を経由した回線です。広大な範囲をカバーする通信の広域性と多数の受信局へ同時送信できる同報性、回線の安定性、速度などが強みです。火災や地震に強い面がある一方で、悪天候（豪雨）や太陽の活動によって通信品質が下がる場合があります。衛星の打ち上げやメンテナンスのコストの回収が必要になるため、料金は高額になります。

公衆回線

コスト：低
品質：不安定

公衆回線とはすなわち、インターネットです。世界中の膨大な数の人たちが日々利用しています。多種多様な業者とサービスが存在し、利用時間や場所など様々な要因によって、速度や安定具合が大きく変化します。日本国内は比較的安定した転送速度と品質を保てますが、業務用途のビデオストリーミング品質までは厳しい場合があります。

業務用途（スポーツや音楽などのライブ中継配信や遠隔医療、遠隔授業、警備（監視カメラ）など）のビデオストリーミングの場合、ほとんどのケースでデータ転送の安定性と、低遅延且つ高画質を要求されるため、回線の選択はシビアです。そのため、業務用途では衛星または専用回線が選択されるケースが多いと思います。しかし、衛星と専用回線のコストは高額になりがちで、画質と遅延量を予算の範囲内に収めるために四苦八苦している、と言うのもよく聞く話です。

そこで、公衆回線を使ったビデオストリーミングの安定性を高めることはできないか…？という非常にシンプルなところから発展してきたのがビデオストリーミング QoS 技術です。

公衆インターネット回線で、ビデオストリーミングを低遅延且つ安定した品質に保つことが難しいのは、インターネットで使用されるプロトコルにも原因があります。ここでいう「プロトコル」とは、デジタルデータの送受信に利用される基本的な通信規格だと思ってください。具体的には、TCP と UDP という 2 種類のプロトコルが存在します。

TCP と UDP のどちらもビデオストリーミングに使うことが可能ですが、これらのリスクが伴うため低遅延且つ安定した品質を保つことが難しいです。

TCP ：大きな遅延やバッファ不足によって再生が停止する
UDP ：データ未達やジッターによって、映像・音声ノイズが発生する

TCP

Transmission Control Protocol ：トランスミッションコントロールプロトコル

インターネットで閲覧される Web ページや電子メールなどのデータ転送に使用される、基本的なプロトコルです。TCP は、データをパケット単位に分割して転送し、受信側で元の形へ再構築します。転送中にパケットの一部が損失（パケットロス）した場合は、受信側からの受信通知（ACK: Acknowledge）が確認されるまで同じパケットを再送信し続けます。

図） TCP 上でのパケット送受信プロセス概略図

このような方式で TCP は確実なデータ転送を確保していますが、パケットロスによってデータ転送の遅延が発生します。不安定なネットワーク（公衆インターネット回線や WiFi など）ではパケットロスが増え、遅延も増加します。その結果としてビデオストリーミングで利用した場合に、大きな遅延やバッファ不足によってビデオの再生が停止する場合もあります。低遅延を要求されるビデオストリーミングの用途には不向きなプロトコルなのです。

余談ですが、コンテンツ配信で現在主流のストリーミングフォーマット HLS と MPEG-DASH は、TCP を使っています。HLS、MPEG-DASH 共に約 30 ～ 45 秒（一般的なセグメントの場合）の遅延を予め設けているのは、TCP による遅延を許容するためです。

UDP

User Datagram Protocol ：ユーザーデータグラムプロトコル

TCP と同様にデータをパケット単位に分割して転送しますが、非常に簡素に且つ高速にデータの送受信を行えるプロトコルです。パケットロスの際の再送要求や、ジッタ（データ転送時にパケットが到着するまでの時間間隔が均一でないために生じる問題）防止機能がない信頼性の低いプロトコルです。そのため、DNS や DHCP、 NTP などの小サイズで応答性が重要視される通信で使用されています。

UDP は信頼性の低いプロトコルであり、不安定なネットワーク（公衆インターネット回線や Wi-Fi など）ではパケットロスが増え、その結果としてデータ未達によって映像や音声にノイズが発生する場合があります。

TCP と UDP の大まかな違いをイメージしていただくため、分かりやすい例えとして「100 リットルの水」を TCP と UDP で運ぶとどんな違いがあるのかを図にしてみました。

TCP で『水 100 リットル』を運ぶ

UDP の場合、「水」をとにかく受信側へ送ります。途中の経路で「水漏れ」や「水はね」でパケットロスが生じるかもしれませんが気にしません。受信側では届いた順に受け入れます。経路の状況が良ければ元と同じに近い量が格納されますが、悪ければほとんど届かない可能性もあります。

TCP と UDP プロトコルの違いが掴めたでしょうか？後述される SRT と Zixi はビデオストリーミング QoS を実現するために、どちらも UDP をベースにしています。なぜなら、上記の「水」のようにとにかくデータを素早く送ることができるためです。

公衆インターネット回線や Wi-Fi のような不安定な通信回線を介したビデオストリーミングの品質（低遅延、解像度、確実性）をどうにか高められないか。そのニーズを満たすためにビデオストリーミング QoS の技術は進歩してきました。現在では海外イベントの日本向け配信に使うライブフィードに利用されるなど、少しづつ実績も増えつつあります。

ビデオストリーミング QoS は、一般的な誤り制御方法である ARQ と FEC をベースにしており、その延長線上から SRT や Zixi といったビデオストリーミングに特化した QoS 技術（製品）が誕生しました。

FEC

Forward Error Correction ：前方誤り訂正

ARQ と同様に、データ転送の確実性を高める誤り制御方法のひとつです。転送するデータに冗長性を付加することで、データの再送信をすることなく誤り制御を実現できます。普通にデータを送るよりも、冗長性の分だけデータ容量が大きくなりますが、何度も同じデータを送る必要はなくなります。

FEC は遅延の原因となる再送信を必要とせずに、転送の確実性を高めることが可能です。そのためビデオストリーミングに有効な QoS 手法であり、FEC オプションを搭載している動画エンコーダも最近では珍しくありません。IPTV では ProMPEG FEC 方式が使われています。

SRT は、予測不能なネットワーク上におけるストリーミングパフォーマンスを最適化する、オープンソース・ビデオトランスポート・プロトコルであり、テクノロジースタックです。不安定な公衆インターネットを通じて、低遅延且つセキュアに、容易なファイアウォールトラバーサルでベストな品質のライブビデオを届けることを目標としています。

エンタープライズ向けビデオエンコーダを提供している Haivision 社によって SRT は開発されました。ストリーミング配信サーバーで有名な Wowza Media Syatems 社と共同で SRT Alliance （SRT アライアンス）を設立し、オープンソース化しました。

パケットロスの原因が主にランダムバーストであることから、SRT はインターネット上で最も一般的なエラーの種類を処理できる ARQ をベースにしています。SRT は ARQ の手法に加えて、高解像度のタイムスタンプをパケットに追加し、メディアストリームのタイミングを受信側の出力で正確に再構成できるようにします。これにより、ダウンストリームのデバイスが適切にデコードできるようになります。

SRT セッション中に送信されるすべてのパケットは、低オーバーヘッド、低遅延を提供するために、UDP を使用します。

Zixi は米国を拠点として、ストリーミング QoS 技術をベースとした Zixi プラットフォーム（ソフトウェア）の開発および提供をしています。Zixi のプロトコルは様々な誤り訂正技術を駆使して、不安定なインターネット接続におけるバンド幅を最大化、距離に依存せずに安定したストリーミングを提供します。

Zixi プラットフォームはクラウド上に配備することもでき、海外からのライブストリームの中継地点にしたり、一拠点から複数拠点へストリーミングをデリバリーするためのハブに使ったり、スタジオ間など近距離での利用にも有効です。

Zixi の具体的な誤り訂正技術の内容までは公開されていません。

ビデオストリーミング QoS で、SRT と Zixi のどちらが良いか一概には言えませんが、参考までに以下のようにまとめてみました。

パケットロスへの耐性

どれくらいのパケットロスまで耐えられるか。この点では Zixi のほうが強いように思われます。ただし、パケットロスへの耐性を高めると遅延量も増えるので、設定したい遅延量によってパケットロス耐性の上限値が決まってしまいます（結果的に SRT と同じ耐性値になる可能性もあります）。

セキュリティ

どちらも互角です。両者共に暗号化によって保護されたストリーミングを実現しています。

ソリューション

SRT Alliance に加入しているいくつかの企業から SRT 対応製品が販売されています。SRT はオープンソースですので参入障壁が低く、今後対応製品が増えてくると思われます。

Zixi は自社の製品およびパートナー企業から様々な形態（OEM やオプションなど）で提供されています。現在のところは SRT よりも対応製品が多いように思います（ただし、いくつかは既に販売終了している可能性があります）。

コスト

SRT は基本無料です。対応製品で、SRT を別料金オプションにする可能性もありますが、オープンソースですので高額にはならないと思います。

Zixi はソフトウェア製品（年間契約のサブスクリプション）で、使用するデータ量によって価格が変動します。また、パートナーの対応製品の Zixi オプションは基本有償です。

用途

SRT ： RTMP の置き換え、拠点間伝送、サーバー間の中継伝送プロトコルとしてなど、低コストに抑えたいストリーミングプロジェクト設備向け

Zixi ：コントリビューション拠点間伝送、複数拠点伝送など、安定性重視のストリーミングインフラ設備向け

Zixi には Zixi プラットフォーム（Zixi Feeder / Zixi Broadcaster / Zixi Receiver）と、複数拠点にある Zixi の統合管理を行う ZEN Master があります。

Zixi Feeder ：入力されたストリームを Zixi プロトコルに変換して、Zixi Broadcaster または Zixi Receiver へ送ります
Zixi Broadcaster ： Zixi Feeder から届いたストリームを単体または複数の Zixi Receiver へ送る、汎用フォーマットに変換して任意のロケーションに出力します
Zixi Receiver ： Zixi Feeder または Zixi Broadcaster から届いたストリームを、用途に合ったフォーマットに変換して出力します

Zixi Broadcaster ユーザーは Zixi Feeder と Receiver をフリーで利用できますが、Zixi Feeder と Receiver だけを利用したい場合は、以下の「ZEN パートナー」から対応製品を購入する形になります。