現在、IP ベースのビデオストリーミング技術は、コンテンツ配信サービスなどの大規模なものから、1 対 1 のビデオ通話のような小規模なものまで、様々な用途の基幹技術として活用されています。
この記事では、昨今注目されているビデオストリーミングの QoS (Quality of Service : サービスの品質)技術についてご紹介したいと思います。具体的には、パケットロスやジッタと言ったエラーの訂正と回復を行い、公衆インターネット回線を使っても安定且つセキュアにビデオをデリバリーできる最先端技術です。拠点間の IP 伝送や、コンテンツ配信用のライブフィード(配信システムへの映像ソース信号の取込み)等への利用に期待されています。
この分野においてどのような技術が存在し、それらに対応する製品や最適な用途などを紹介したいと思います。
通信回線
話の本題に入る前に、通信回線について簡単に触れておきたいと思います。使用する回線によって、通信の安定性とビデオ品質、遅延量、そしてコストに大きく影響します。以下の 3 種類が存在します。
衛星回線
- コスト: 高
- 品質: 安定
通信衛星を経由した回線です。広大な範囲をカバーする通信の広域性と多数の受信局へ同時送信できる同報性、回線の安定性、速度などが強みです。火災や地震に強い面がある一方で、悪天候(豪雨)や太陽の活動によって通信品質が下がる場合があります。衛星の打ち上げやメンテナンスのコストの回収が必要になるため、料金は高額になります。
専用回線
- コスト: 高
- 品質: 安定
契約者のみが使用できる拠点間ネットワークの経路を、物理的または論理的に設けます。契約者以外のデータは一切流れないので、通信品質を高く保ちます。通信速度やバンド幅、距離、品質によって料金が異なります。複数拠点との接続や超長距離間(海外など)での利用では、衛星回線のほうが有利な場合があります。
公衆回線
- コスト: 低
- 品質: 不安定
公衆回線とはすなわち、インターネットです。世界中の膨大な数の人たちが日々利用しています。多種多様な業者とサービスが存在し、利用時間や場所など様々な要因によって、速度や安定具合が大きく変化します。日本国内は比較的安定した転送速度と品質を保てますが、業務用途のビデオストリーミング品質までは厳しい場合があります。
業務用途(スポーツや音楽などのライブ中継配信や遠隔医療、遠隔授業、警備(監視カメラ)など)のビデオストリーミングの場合、ほとんどのケースでデータ転送の安定性と、低遅延且つ高画質を要求されるため、回線の選択はシビアです。そのため、業務用途では衛星または専用回線が選択されるケースが多いと思います。しかし、衛星と専用回線のコストは高額になりがちで、画質と遅延量を予算の範囲内に収めるために四苦八苦している、と言うのもよく聞く話です。
そこで、公衆回線を使ったビデオストリーミングの安定性を高めることはできないか…?という非常にシンプルなところから発展してきたのがビデオストリーミング QoS 技術です。
TCP と UDP
公衆インターネット回線で、ビデオストリーミングを低遅延且つ安定した品質に保つことが難しいのは、インターネットで使用されるプロトコルにも原因があります。ここでいう「プロトコル」とは、デジタルデータの送受信に利用される基本的な通信規格だと思ってください。具体的には、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 リットル』を運ぶ
TCP の場合、「水」はボトルごと番号順に送られ、パケットロスが発生した場合は、その番号から順番通りに送り直します。仮に後の番号の「水」が先に到着した場合は、後の番号の「水」は破棄され、順番通り確実に元通りになるよう受信側で格納されます。正確に元と同じ「100 リットルの水」になります。
UDP で『水 100 リットル』を運ぶ
UDP の場合、「水」をとにかく受信側へ送ります。途中の経路で「水漏れ」や「水はね」でパケットロスが生じるかもしれませんが気にしません。受信側では届いた順に受け入れます。経路の状況が良ければ元と同じに近い量が格納されますが、悪ければほとんど届かない可能性もあります。
TCP と UDP プロトコルの違いが掴めたでしょうか?後述される SRT と Zixi はビデオストリーミング QoS を実現するために、どちらも UDP をベースにしています。なぜなら、上記の「水」のようにとにかくデータを素早く送ることができるためです。
QoS 技術
公衆インターネット回線や Wi-Fi のような不安定な通信回線を介したビデオストリーミングの品質(低遅延、解像度、確実性)をどうにか高められないか。そのニーズを満たすためにビデオストリーミング QoS の技術は進歩してきました。現在では海外イベントの日本向け配信に使うライブフィードに利用されるなど、少しづつ実績も増えつつあります。
ビデオストリーミング QoS は、一般的な誤り制御方法である ARQ と FEC をベースにしており、その延長線上から SRT や Zixi といったビデオストリーミングに特化した QoS 技術(製品)が誕生しました。
ARQ
Automatic Repeat reQuest : 自動再送要求
送信側と受信側とで、データが正しく届いたか否かを確認しつつ、データ転送の確実性を高める誤り制御方法のひとつです。Stop-and-wait ARQ と Go-Back-N ARQ、Selective Repeat ARQ の 3 種類があります。
Stop-and-wait ARQ
停止と待機
最も単純な自動再送要求の手法です。送信側はデータを送信後、そのデータの受信確認通知が届くかタイムアウトするまで次のデータを送りません。そのため他の手法に比べて効率が良くありません。
Go-Back-N ARQ
N 回帰
受信確認通知が届かなくても決められたサイズに達するまでデータを送信し続け、受信側は受信したデータの固有番号を含めた通知を送ります。エラーがあった場合は、最終通知番号の後から全てのデータを再送信します。
Selective Repeat ARQ
選択的再送
決められたサイズに達するまで送信側はデータを送信し続け、受信側はデータを受信し続けます。限界まで達したら、受信側は未達データの固有番号を含む通知を送信側に送り、送信側はその通知に該当するデータを再送信します。
FEC
Forward Error Correction : 前方誤り訂正
ARQ と同様に、データ転送の確実性を高める誤り制御方法のひとつです。転送するデータに冗長性を付加することで、データの再送信をすることなく誤り制御を実現できます。普通にデータを送るよりも、冗長性の分だけデータ容量が大きくなりますが、何度も同じデータを送る必要はなくなります。
FEC は遅延の原因となる再送信を必要とせずに、転送の確実性を高めることが可能です。そのためビデオストリーミングに有効な QoS 手法であり、FEC オプションを搭載している動画エンコーダも最近では珍しくありません。IPTV では ProMPEG FEC 方式が使われています。
SRT
SRT は、予測不能なネットワーク上におけるストリーミングパフォーマンスを最適化する、オープンソース・ビデオトランスポート・プロトコルであり、テクノロジースタックです。不安定な公衆インターネットを通じて、低遅延且つセキュアに、容易なファイアウォールトラバーサルでベストな品質のライブビデオを届けることを目標としています。
エンタープライズ向けビデオエンコーダを提供している Haivision 社によって SRT は開発されました。ストリーミング配信サーバーで有名な Wowza Media Syatems 社と共同で SRT Alliance (SRT アライアンス)を設立し、オープンソース化しました。
パケットロスの原因が主にランダムバーストであることから、SRT はインターネット上で最も一般的なエラーの種類を処理できる ARQ をベースにしています。SRT は ARQ の手法に加えて、高解像度のタイムスタンプをパケットに追加し、メディアストリームのタイミングを受信側の出力で正確に再構成できるようにします。これにより、ダウンストリームのデバイスが適切にデコードできるようになります。
SRT セッション中に送信されるすべてのパケットは、低オーバーヘッド、低遅延を提供するために、UDP を使用します。
SRT 動画デモ
SRT の効果を知るためのデモンストレーションビデオです。ネットワークに 2% のパケットロスを発生させた場合における画質と遅延量の違いを見て取れます。
- 左下: オリジナルのライブソース
- 左上: H.264 TS / UDP 4 Mbps
- 右上: SRT を使った H.264 4 Mbps
- 右下: SRT を使った HEVC 2.7 Mbps
Zixi
Zixi は米国を拠点として、ストリーミング QoS 技術をベースとした Zixi プラットフォーム(ソフトウェア)の開発および提供をしています。Zixi のプロトコルは様々な誤り訂正技術を駆使して、不安定なインターネット接続におけるバンド幅を最大化、距離に依存せずに安定したストリーミングを提供します。
Zixi プラットフォームはクラウド上に配備することもでき、海外からのライブストリームの中継地点にしたり、一拠点から複数拠点へストリーミングをデリバリーするためのハブに使ったり、スタジオ間など近距離での利用にも有効です。
Zixi の具体的な誤り訂正技術の内容までは公開されていません。
Zixi 動画デモ
Zixi の効果を知るためのデモンストレーションビデオです。パケットロス 10%、15%、20% の環境下における、FEC 付き RTP ストリーミングと Zixi を介したストリーミング(H.264 1080i 29.97)の画質を比較しています。
SRT vs Zixi
ビデオストリーミング QoS で、SRT と Zixi のどちらが良いか一概には言えませんが、参考までに以下のようにまとめてみました。
パケットロスへの耐性
どれくらいのパケットロスまで耐えられるか。この点では Zixi のほうが強いように思われます。ただし、パケットロスへの耐性を高めると遅延量も増えるので、設定したい遅延量によってパケットロス耐性の上限値が決まってしまいます(結果的に SRT と同じ耐性値になる可能性もあります)。
セキュリティ
どちらも互角です。両者共に暗号化によって保護されたストリーミングを実現しています。
ソリューション
SRT Alliance に加入しているいくつかの企業から SRT 対応製品が販売されています。SRT はオープンソースですので参入障壁が低く、今後対応製品が増えてくると思われます。
Zixi は自社の製品およびパートナー企業から様々な形態(OEM やオプションなど)で提供されています。現在のところは SRT よりも対応製品が多いように思います(ただし、いくつかは既に販売終了している可能性があります)。
コスト
SRT は基本無料です。対応製品で、SRT を別料金オプションにする可能性もありますが、オープンソースですので高額にはならないと思います。
Zixi はソフトウェア製品(年間契約のサブスクリプション)で、使用するデータ量によって価格が変動します。また、パートナーの対応製品の Zixi オプションは基本有償です。
用途
SRT : RTMP の置き換え、拠点間伝送、サーバー間の中継伝送プロトコルとしてなど、低コストに抑えたいストリーミングプロジェクト設備向け
Zixi : コントリビューション拠点間伝送、複数拠点伝送など、安定性重視のストリーミングインフラ設備向け
図) Haivision 製品の SRT 活用例
Wowza Media Systems (ワウザ・メディア・システムズ)社は、Haivision 社と共同で SRT Alliance を設立しました。同社製品の「Wowza Streaming Engine」は業界標準とも言えるソフトウェアです。SRT を使って様々な用途が考えられます。
ストリーミングサーバー
図) SRT を使った Wowza Streaming Engine へのインジェスト
SRT を使って、ストリームソースのインジェストからストリームの中継、SRT の出力だけでなく配信用フォーマットにトランスコードすることもできます。
Teradek 社は、ビデオストリーミング QoS オプションを同社のエンコーダ / デコーダ製品である「Cube」に搭載しました。旧 Cube 製品には Zixi オプションが用意され、最新の「Cube 700」シリーズは SRT に対応しています。
ポータブルエンコーダ / デコーダ
Teradek Cube は世界最高水準のビデオ品質で、どこでも素早く IP ビデオを配備できる堅牢且つポータブルなシャーシに収めました。エンコーダおよびデコーダには、HDMI および 3G-SDI 入出力、イーサネット / Wi-Fi 接続、および全二重 IFB が搭載されています。
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 パートナー」から対応製品を購入する形になります。
ZEN(Zixi Enabled Network)パートナー
Zixi テクノロジーを搭載したエンコーダやデコーダ、サービスなどが ZEN(Zixi Enabled Network)パートナー各社より提供されています。
Harmonic 社はデジタルビデオの配信プラットフォームにおける世界的リーダーとして、コンテンツ配信アプリケーションに完全に対応するエンドツーエンド映像インフラストラクチャーソリューションを提供しています。
コントリビューションプラットフォーム
ViBE CP6000 は Harmonic 第三世代コントリビューション・プラットフォームで、広く利用されている ViBE のモジュラー式映像処理ソリューションを基盤としています。非常に優れた動画圧縮を特長とし、最高の操作性能を意図して設計されています。エンコードとデコード能力を装備しており、様々な用途に適しています。
クラウドメディア処理サービス
VOS 360 は、SaaS (Software as a Service)として従来のビデオエンコードおよびビデオ配信を提供するサービスです。ブロードキャスト品質且つ短時間に、自身のコンテンツ配信サービスとして容易に開始することができます。