低遅延とは

ビデオストリーミングにおける低遅延とは、いったいどれくらいの遅延量のことを指すのでしょうか?

低遅延とは主観的な言葉で、話の内容によって変化します。現在ビデオ配信で一般的に使用されている HLS ストリーミングプロトコルの遅延は、30 〜 45 秒ですが、最近の低遅延の話題はほとんど一桁秒台の遅延についてですし、リアルタイムストリーミングにおける低遅延となった場合は、ミリ秒単位での話になります。

低遅延が必要な場面

遅延が大きくなってほしい人はいないと思いますが、では、本当に低遅延が必要なケースとは何でしょう?

ほとんどの場合、30 ~ 45 秒の遅延は問題になりません。しかし、遅延量がビジネスにとってクリティカルな検討事項になるケースがもちろんあります。

低遅延が重要となるストリーミングのケースをいくつか挙げてみます。

 

テレビとアプリ視聴

スポーツイベントなどを、テレビと一緒にセカンドスクリーンアプリでも視聴している場合、遅延の問題は即座に確認でき、ハッピーな気分にはならないでしょう。相手のカメラアングルを見たり、他のファンと意見交換できるアプリを見ているとします。テレビでは試合に勝ったスコアが流れ、数分経ってから結果がアプリに流れてきたら…。試合に勝利したプレーについて意見を交換するタイミングを失ったことになります。しかし、このケースでの遅延における重要なポイントは、後述で議論されるような超低遅延とは異なります。なぜならテレビ放送にも遅延があるためです。セカンドスクリーンアプリはテレビの遅延に合わせることが重要です。

ビデオチャット

超低遅延ストリーミングが必要になる場面です。レポーターが遠隔地にいる人にインタビューするとき、遅延によって長い沈黙になったり、お互い同時に会話を始めたりしたことを見たことがあると思います。これは双方向に遅延が発生するためです - インタビューを受ける人への質問に数秒かかったとして、レポーターへの返事が届くまでさらに 1 秒遅れることもあり得ます。すぐに会話がし辛くなるのです。本当に即時性が必要なのだとしたら、双方向の遅延の上限をおよそ 150 ミリ秒(1 / 7 秒)に留める必要があります。スムースな会話に十分な短さです。

レースやオークション

スポーツくじやオークションといったアクティビティは、その速さが刺激的です。よってリアルタイムストリーミングが求められます。例えば競馬場は、世界中の競馬場からの衛星フィードに昔からつながっており、オンラインで賭けられるようにしました。衛星の遅延とコストはどちらも高くなりがちです。超低遅延ストリーミングは遅延の問題を排除し、コストを削減します。オンラインオークションも同様にビッグビジネスで、遅延によって入札が適切に記録されない可能性があります。僅かな遅延が異なる結果の原因になり得ます。

ビデオゲーム

誰かが「このゲームはチートだ!」(もっと酷い言葉を言うかもしれません)と叫ばないために…。ゲーマーにとってタイミングが如何に致命的であるか。100 ミリ秒以下の遅延がマストの世界です。ストリーミングサービスを介してゲームをプレイしたいと思わないでしょうし、既に存在しない敵に向かって攻撃していることに気づきたくないでしょう。

低遅延のテクノロジー

低遅延ストリーミングを実現するためには、以下のことを検討しなくてはなりません。

  • エンコードプロトコルと、デバイス / プレーヤーの互換性
  • オーディエンスや配信地域、範囲
  • ビデオ解像度と複雑さ

CDN や配信サーバーへ送るためのエンコード処理、コンテンツを配信するためのトランスコードや暗号化処理、届いたデータをスクリーンに投影するためのデコード処理、品質を向上させるために解像度を大きくすれば処理時間も当然大きくなります。また、単純にデータを届ける距離も関係します。遠い場所であれば当然遅延は大きくなります。コンテンツが視聴者の目に届くまでの経路にある様々な処理や要素、ストリーミングプロトコルの仕様によって遅延が生じます。

特にストリーミングプロトコルの仕様は遅延に大きく影響します。現在、低遅延に対する様々な技術開発や標準化が進んでいます。

HTTP (HLS / MPEG-DASH)

HLS (HTTP Live Streaming)は Apple 社が開発し、その信頼性のために現在広く使用されているストリーミングプロトコルです。標準的な遅延は 30 ~ 45 秒です。

MPEG-DASH (以下 DASH: Dynamic Adaptive Streaming over HTTP)は、国際標準化機関 ISO / IEC によって規格化されたストリーミングプロトコルです。標準的な遅延は 10 ~ 20 秒です。

どちらも HTTP による ABR (アダプティブ・ビットレート)配信に対応しており、それが遅延を大きくする原因でもあります。ABR 配信をするため、一般的に 10 秒ごとのチャンク(DASH ではセグメント)にビデオストリームが分割されます。HTTP は安定且つ高速な接続ではないので、配信されたコンテンツの再生を開始する前に、予めチャンク(セグメント)をバッファします。HLS では標準で 3 つのチャンクをバッファするため 30 ~ 45 秒の遅延になります。DASH では 1 つまたは 2 つのセグメントをバッファするため 10 ~ 20 秒の遅延になります。

低遅延 HTTP ストリーミング

チャンク(セグメント)の縮小: 単純に遅延の原因であるチャンク(セグメント)サイズを縮小して低遅延の実現を目指します。HLS は 2 秒のチャンク(同様に GOP 調整も)を使って、遅延を 8 秒以下に。DASH は 1 秒のセグメントを使って、遅延を 4 秒に削減します。また、DASH MPD 属性(availabilityStartTime と minBufferTime)の最適化も有効です。ただし、チャンク(セグメント)が小さいと、視聴のバッファリングが多発する可能性が高まるので注意が必要です。

CMAF

CMAF (Common Media Application Format)は、Apple と Microsoft によって開始され(現在 Google や Netflix、Akamai など多くの企業が賛同)、HLS プレイリストと DASH マニフェストの両方を参照できる単一のメディアフォーマットを確立することを目標にして、2017 年 Q3 での ISO 国際標準化を目指しています。

CMAF はセグメント内に、さらにセグメントを用意することによって、超低遅延の実現を目指しています。

WebRTC

WebRTC (Web Real-Time CommunicationsRTMP)は、信頼性の低い接続状況でのリアルタイムビデオ・オーディオ・データ配信用に設計されました。既に多くのプラットフォームで採用され、iOS 向けに Apple がネイティブ対応する可能性が高いことが全てを物語っています。WebRTC は、Flash のない HTML 5 ベースでの低遅延配信を可能にします。

  • TCP または UDP
  • RTSP / RTP 複数のプロトコルと関連
  • 遅延: 1 秒またはそれ以下(約 200 ミリ秒)

RTMP

RTMP (Real-Time Messaging Protocol)は、Adobe 社が開発した低遅延ストリーミングを可能にしたプロトコルで、再生に Flash プレーヤーが必要になります。iOS デバイスはサポートされず、多くの Web ブラウザが近い将来で非対応になることを表明しており、視聴者へコンテンツを届けるプロトコルとしては不向きです。

ただし、RTMP に対応しているエンコーダは数多く存在するので、現場から CDN や配信サーバーへデリバリーするプロトコルとしては今でも実用的です。

  • 遅延: 1 ~ 3 秒、稀に 1 秒以下

WebSocket

ブラウザとサーバーの間に、標準化された双方向の信頼性の高い通信チャネルを提供するように設計されました。

  • TCP
  • RTMP、WebRTC、Haivision SRT、Wowza WOWZ、Aspera FASP など、他のストリーミングプロトコルで使用可能
  • 遅延: 約 200 ミリ秒)

QUIC

QUIC (Quick UDP Internet Connections)は、Google 社が開発している UDP ベースの Web 向けプロトコルです。

  • UDP (TCP フォールバック共用)
  • セキュリティと信頼性を重視
  • コネクトやラウンドトリップ時間、パケットロス、混雑制御などの削減を、インテリジェントな再送信やストレージ、情報の配信を用いて TCP に似たものにする
  • HTTP/2 ベースに構築

SRT

SRT (Secure Reliable Transport)は、インターネット経由で高品質且つセキュアな低遅延ビデオデリバリーを可能にする、Haivision 社が開発したビデオトランスポート・プロトコルです。

  • 劣悪なネットワーク状況下でベストな品質のライブビデオをデリバリーできるよう設計
  • パケットロス、ジッター、帯域幅の変化を考慮して品質を最大化

低遅延への取組

ストリーミングに関係しているベンダーの、低遅延に対する取り組みをご紹介します。

Wowza Media Systems

ストリーミング配信サーバーの業界標準「Wowza Streaming Engine」は低遅延または超低遅延に対して、以下のようなアプローチを開始しております。

THEOplayer

HTML5 動画プレイヤー「THEOplayer」は、CMAF に注目しています。

オンラインストリーミング産業にとって CMAF がどれくらい影響力を持つか(英語)

Harmonic

  • CMAF への対応を進めています

Akamai

  • Media Acceleration 機能に QUIC を採用(2017 年 3 月発表)
  • クラウド・トランスコードサービスが CMAF に対応(2016 年 11 月発表)

YouTube

YouTube ライブのストリーミング設定に”超低遅延”が追加されました。

YouTube ライブ ストリーミング設定

この超低遅延設定を使用することで、2 秒以内の遅延を可能にします(ただし HD 解像度まで、DVR 非対応)。