Amazon IVSの設定による遅延の違いを確認してみた

Amazon Interactive Video Serviceでのライブ配信時の遅延について、Video latency設定の違いを中心に確認してみます。案内されているとおりの超低遅延なライブ配信が簡単にできてビックリしました!
2020.09.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

清水です。簡単にライブ配信が行えることを重視しながらも超低遅延配信を謳っているAmazon Interactive Video Service(Amazon IVS)、チャンネル設定に「Ultra-low latency」と「Standard latency」の設定項目がありますが、それぞれの設定でどのぐらいの遅延でのライブ配信ができるのかを確認してみました。

IVSのChannel設定のVideo latencyについて

Amazon IVSでChannel作成時、「Custom configuration」にするとVideo latencyとして「Ultra-low latency」と「Standard latency」の2つが選択できます。マネジメントコンソールのInfoによると、「Ultra-low latency」では5秒未満、「Standard latency」では10秒ほど、と記されています。またこの設定の違いで料金に違いはないようですが、「Standard latency」を使うことで「特定のリージョンでは信頼性が改善される」とのことです。

遅延とリージョンの選択について

Amazon IVS、現在のところ対応リージョンとしてリストアップされるのはアイルランド(eu-west-1)、バージニア(us-east-1)、オレゴン(us-west-2)の3つですが、サービスとしてはグローバル対応しており、配信ならびに視聴において、そのデバイスに最も近いPoP(Point of Presence)が自動的に選択されるようになっており、このため日本にも対応しているとのことです。(Amazon IVSローンチセミナーより)ということで、使用リージョンにおける遅延については大きく考慮しなくて良さそうですね。ここはIVSが専用のCDNと統合しているというところの利点ではないかと思います。本エントリではIVSのリソースはオレゴン(us-west-2)に作成し、東京都内で検証を行いました。

Latency設定の違いによる遅延の比較

では実際にLatency設定の違いによる遅延を比較してみます。IVSのChannelは「Ultra-low latency」と「Standard latency」で2つ作成しました。リージョンはオレゴン(us-west-2)、Channel typeはStandard、プライベートチャンネル機能は無効としています。

配信ページについて

配信ページはAmazon IVS Player SDK for Webを用いて作成しました。htmlファイルをチャンネルごと作成し、S3でホスティングします。htmlコードはそれぞれ以下となります。(ドキュメントデモページなどを参考に、最小限の要素で作成してみました。音声がデフォルトでミュートされるようなので、ミュート解除のためにcontrolを表示させるようにしています。そのためライブ配信では不要なシークバーが表示され見てくれが少し微妙になっていますが、私がコーディング不得手なため、とりあえずはこれで検証を進めてみます。)

こちらが「Ultra-low latency」に設定したChannelの配信ページです。(title部分は以前使ったものから変更し忘れてしまいました。private-channelとなる設定はしていません。)

<html>
  <head>
    <title>ivs-private-channel</title>
    <style>
      video {
          height: 100%;
          width: 100%;
          left: 0;
          top: 0;
          position: fixed;
      }
    </style>
  </head>
  <body>
    <video id="video-player" playsinline controls></video>
    <script src="https://player.live-video.net/1.0.0/amazon-ivs-player.min.js"></script>
    <script>
      var PLAYBACK_URL = "https://XXXXXXXXXXXX.us-west-2.playback.live-video.net/api/video/v1/us-west-2.123456789012.channel.YYYYYYYY40oe.m3u8";
      if (IVSPlayer.isPlayerSupported) {
          const player = IVSPlayer.create();
          player.attachHTMLVideoElement(document.getElementById('video-player'));
          player.load(PLAYBACK_URL);
          player.play();
      }
    </script>
  </body>
</html>

こちらが「Standard latency」に設定したChannelの配信ページです。「Ultra-low latency」とPLAYBACK_URL以外は変わりありません。(こちらもtitleタグは直し忘れています。)

<html>
  <head>
    <title>ivs-private-channel</title>
    <style>
      video {
          height: 100%;
          width: 100%;
          left: 0;
          top: 0;
          position: fixed;
      }
    </style>
  </head>
  <body>
    <video id="video-player" playsinline controls></video>
    <script src="https://player.live-video.net/1.0.0/amazon-ivs-player.min.js"></script>
    <script>
      var PLAYBACK_URL = "https://XXXXXXXXXXXX.us-west-2.playback.live-video.net/api/video/v1/us-west-2.123456789012.channel.ZZZZZZZZRgMl.m3u8";
      if (IVSPlayer.isPlayerSupported) {
          const player = IVSPlayer.create();
          player.attachHTMLVideoElement(document.getElementById('video-player'));
          player.load(PLAYBACK_URL);
          player.play();
      }
    </script>
  </body>
</html>

Streaming Softwareについて

Streaming Softwareについては、iPhone 6sでZixi ONAIRを使用しました。設定は以下としています。

エンコーダ設定についてはAmazon IVSのドキュメントにも記載があるので、こちらを参照すると良いかと思います。(上記のZixi ONAIRの設定については、私がいつも使っているものをベースにしているので、細かな点などはドキュメントの推奨値と異なる点などがあるかもしれません。)

実際の遅延の比較

実際に遅延を比較した結果が以下となります。再生環境はmacOS上でChromeブラウザを使用しました。iPhone 6sのカメラで手前のSEIKO製の時計を撮影、そのライブ配信映像を後方のモニタ(SONY製のテレビ)で映しています。今回はあくまで設定による遅延の大まかな違いを確認することを目的としているため、秒未満の計測はせず、おおよそでの遅延を確認することとしています。

まず「Ultra-low latency」で設定したChannelです。以下のようにおよそ3秒未満の遅延でのライブ配信が確認できました。先日のAmazon IVSローンチセミナーでは、ネットワークが安定していれば遅延は概ね3秒未満とのことでしたので、この通りになりましたね。

続いて「Standard latency」で設定したChannelです。こちらはおよそ8秒未満、マネジメントコンソールに記載があった10秒ほどの遅延に収まっています。

ということで、Video latency設定の違いとしては「Ultra-low latency」では5秒未満(条件などがよければ3秒未満)の遅延、「Standard latency」ではおよそ10秒の遅延、ということが実際に確認できました。

おまけ: Playerの違いによる遅延の比較

Amazon IVSでのライブ配信、払い出されるPlayback URLをHLSにネイティブ対応しているSafariやVideo.js(videojs-http-streaming:VHS)などを使っても再生自体は可能です。ただし遅延については意図した通りにならない(想定よりも多くの遅延が発生してしまう)場合があるので注意しましょう。以下は「Ultra-low latency」で設定したChannelをVideo.js(videojs-http-streaming:VHS)で再生してみた例です。20秒近くの遅延(18秒未満ほどでしょうか)が発生していることが確認できます。またChannelを「Standard latency」で設定した場合でも、同様の遅延が発生していました。

IVS Player自体が超低遅延配信向けに最適化していると言われています。またIVSが具体的にどのような方式で超低遅延を実装しているかは公表されていなかったかと思いますが、例えばre:Invent2019でも紹介されていたフジテレビさんのAWS Elemental MediaStoreとAmazon CloudFrontで超低遅延配信を実現した事例では、プレイヤーの準備も必要という文言がありました。IVSについても同様に、プレイヤー側で対応していなければ超低遅延配信ができないのだろうと推測しています。

まとめ

Amazon Interactive Video Service(Amazon IVS)でのライブ配信時の遅延について、Video latency設定の違いを中心に確認してみました。まずは「Ultra-low latency」に設定した場合に、公称値の3秒未満の遅延でのライブ配信が最も簡単にできることにほんとうに驚きです!「Standard latency」の設定でも案内されているとおり10秒ほどの遅延に治ることが確認できました。私個人的には、HLSなどHTTPベースの配信であればある程度(数十秒から1分ぐらい)の遅延はしかたがないもの、という考えで、遅延を少なくするには方式を変えたり(例えばWebRTCを使う)、細かにチューニングをする必要がある。そもそもHLSなどは擬似的なストリーミングであり、HTTP CDNのキャッシュが利用できてスケールできる分、遅延の面はあきらめる必要があるのでは、などと考えていたのですが。こんなに簡単に超低遅延なライブ配信ができてしまうとは思っていませんでした。すごいですね、Amazon IVS!