はじめに
こんにちは、IT 本部 IT 基盤部第一グループの横田です。 IT 基盤部では、組織横断的に複数のサービスのインフラ運用を行っており、インフラの安定的な稼働やコスト削減に取り組んでいます。
今回は、ライブ配信基盤のためのマネージドサービスである Tencent Cloud の Tencent Real-Time Communication (TRTC) と Cloud Streaming Services (CSS)、AWS の Amazon Interactive Video Service (IVS) について、利用可能な配信プロトコルと配信遅延の比較結果をご紹介します。
比較するサービスの概要
Tencent Real-Time Communication (TRTC)
TRTC は、リアルタイムで映像と音声によるコミュニケーションを行うための機能を提供するサービスです。 ルームと呼ばれる 1 つのセッションの中で、ビデオ通話のような相互通信が可能で、ユースケースとしてライブ配信も想定されています。
Cloud Streaming Services (CSS)
CSS は、配信者の映像と音声を多数の視聴者に配信するためのライブ配信サービスです。 配信者がサーバーに送信した映像と音声は、CDN を経由して視聴者に配信されます。 また、CDN relayed live streaming という機能を使用することで、TRTC の映像と音声を CSS 経由で配信することができます。
Amazon Interactive Video Service (IVS)
IVS は、CSS と同様、配信者の映像と音声を多数の視聴者に配信するためのライブ配信サービスです。 AWS の他のサービスと親和性が高く、Simple Storage Service (S3) への録画の保存や、Identity and Access Management (IAM) による統一された権限管理を行うことができます。
なぜ比較するのか
私の所属する IT 基盤部第一グループでは、Pococha というライブ配信サービスのインフラ運用を担当しています。 Pococha では、全ての配信で IVS を使用しており、可用性向上のためマルチクラウド化を検討しています。 マルチクラウド化のメリットとしては、AWS の基盤障害時に別のクラウドに切り替えられることや、サービスのポータビリティ向上が挙げられます。
マルチクラウド化を検討する上で、コストや利用可能な配信プロトコルの観点から Tencent Cloud の TRTC と CSS が候補となりました。 また、TRTC と CSS は下り方向の通信において、IVS※ で使用される HLS よりも一般に配信遅延が小さい WebRTC などのプロトコルにも対応しているため、ユーザー体験の向上が期待されます。 今回の比較では、TRTC と CSS の利用を検討する上で、IVS と同じ性能で配信ができるかという点だけでなく、配信遅延の減少といった付加的なメリットも含めて調査しました。
※ IVS Low-Latency Streaming の場合
利用可能な配信プロトコルの比較
配信サービスで使用されるプロトコルには、配信者が映像と音声をサーバーに送信するための上り方向のプロトコルと、視聴者がサーバーから映像と音声を受信するための下り方向のプロトコルがあります。 この比較では、TRTC と CSS、IVS のそれぞれで利用可能な上り方向と下り方向の配信プロトコルをまとめています。 また、下表では、CDN relayed live streaming による TRTC と CSS の組み合わせを TRTC+CSS と表記しています。
上り方向の配信プロトコル
上り方向の配信プロトコルは、いずれも RTMP に対応しており、その他に TRTC は TRTC 独自プロトコル、CSS は WebRTC と SRT に対応しています。 TRTC+CSS は、配信者が TRTC のサーバーに映像と音声を送信するため、TRTC のみの場合と同じプロトコルに対応しています。 IVS※ は、RTMP の他に WebRTC にも対応しています。
| プロトコル | TRTC | CSS | TRTC+CSS | IVS※ |
|---|---|---|---|---|
| TRTC 独自プロトコル | ⚪︎ | - | ⚪︎ | - |
| RTMP | ⚪︎ | ⚪︎ | ⚪︎ | ⚪︎ |
| WebRTC | - | ⚪︎ | - | ⚪︎ |
| SRT | - | ⚪︎ | - | - |
※ IVS Low-Latency Streaming の場合
下り方向の配信プロトコル
下り方向の配信プロトコルは、TRTC が TRTC 独自プロトコルと RTMP、CSS が RTMP と WebRTC、HLS、HTTP-FLV に対応しています。 TRTC+CSS は、視聴者が CSS 経由で映像と音声を受信するため、CSS のみの場合と同じプロトコルに対応しています。 IVS※ は、HLS のみ対応しています。
| プロトコル | TRTC | CSS | TRTC+CSS | IVS※ |
|---|---|---|---|---|
| TRTC 独自プロトコル | ⚪︎ | - | - | - |
| RTMP | ⚪︎ | ⚪︎ | ⚪︎ | - |
| WebRTC | - | ⚪︎ | ⚪︎ | - |
| HLS | - | ⚪︎ | ⚪︎ | ⚪︎ |
| HTTP-FLV | - | ⚪︎ | ⚪︎ | - |
※ IVS Low-Latency Streaming の場合
配信遅延の比較
TRTC と CSS、IVS のそれぞれで利用可能な配信プロトコルの組み合わせについて、以下の条件で配信遅延を計測し、結果を比較しました。
- HD 画質 (1280x720)
- フレームレート：30 fps
- ビットレート：4,500 kbps
- IVS Basic のみ最大ビットレートである 3,500 kbps を設定
- 配信者と視聴者は 1 人ずつ
- 配信側と視聴側で同時にタイムスタンプを撮影し、タイムスタンプの差を配信遅延として、3 回の平均を計算
- TRTC 独自プロトコルによる配信と視聴には、 Tencent Cloud 公式の TUIPusher と TUIPlayer を使用
- RTMP による配信には
OBS
を使用し、エンコーダ設定はレート制御 CBR、バッファサイズ 0、キーフレーム間隔 1 秒、CPU 使用のプリセット ultrafast、プロファイル baseline、チューン zerolatency、映像エンコーダ x264、x264 オプション
threads=1を指定 - WebRTC による CSS と IVS の配信には、それぞれ Tencent Cloud 公式の Web Push と AWS 公式の Web Broadcast SDK を使用
- CSS と IVS の視聴には、それぞれ
Tencent Cloud 公式のプレーヤー
と
AWS 公式のプレーヤー
を使用
- CSS の下り方向で HLS を使用する場合のみ、Tencent Cloud 公式のプレーヤーにシークバーと早送り機能がないため、 hls.js を使用
- CSS と IVS ともに、HLS は Low-Latency HLS (LHLS) を使用
- TRTC の Region は Global (excluding Chinese mainland) を設定
- CSS の Region は Global もしくは Outside Chinese mainland を設定
- IVS の Region は ap-northeast-1 を設定
- 配信と視聴の実行元（ローカル）は東京で、回線速度は上り下り 50 Mbps 以上（有線接続）
TRTC
| 上り方向 | 下り方向 | ビットレート | 遅延 |
|---|---|---|---|
| TRTC 独自プロトコル | TRTC 独自プロトコル | 4,500 kbps | 181 ms |
| RTMP | TRTC 独自プロトコル | 4,500 kbps | 1,250 ms |
CSS
- HLS latency は Low を設定
- RTMP and FLV latency は Low を設定
| 上り方向 | 下り方向 | ビットレート | 遅延 |
|---|---|---|---|
| WebRTC | WebRTC | 4,500 kbps | 178 ms |
| WebRTC | HLS | 4,500 kbps | 2,481 ms |
| WebRTC | HTTP-FLV | 4,500 kbps | 725 ms |
| RTMP | WebRTC | 4,500 kbps | 1,221 ms |
| RTMP | HLS | 4,500 kbps | 5,033 ms |
| RTMP | HTTP-FLV | 4,500 kbps | 1,390 ms |
TRTC+CSS
- HLS latency は Low を設定
- RTMP and FLV latency は Low を設定
| 上り方向 | リレー※ | 下り方向 | ビットレート | 遅延 |
|---|---|---|---|---|
| TRTC 独自プロトコル | RTMP | WebRTC | 4,500 kbps | 334 ms |
| TRTC 独自プロトコル | RTMP | HLS | 4,500 kbps | 4,807 ms |
| TRTC 独自プロトコル | RTMP | HTTP-FLV | 4,500 kbps | 2,134 ms |
| RTMP | RTMP | WebRTC | 4,500 kbps | 566 ms |
| RTMP | RTMP | HLS | 4,500 kbps | 5,328 ms |
| RTMP | RTMP | HTTP-FLV | 4,500 kbps | 1,570 ms |
※ CDN relayed live streaming による TRTC から CSS への配信のリレーには RTMP が使用されます。
IVS Basic
- Video latency は Low を設定
| 上り方向 | 下り方向 | ビットレート | 遅延 |
|---|---|---|---|
| WebRTC | HLS | 3,500 kbps | 2,438 ms |
| RTMP | HLS | 3,500 kbps | 2,432 ms |
IVS Standard
- Video latency は Low を設定
| 上り方向 | 下り方向 | ビットレート | 遅延 |
|---|---|---|---|
| WebRTC | HLS | 4,500 kbps | 2,368 ms |
| RTMP | HLS | 4,500 kbps | 2,567 ms |
IVS Advanced-HD
- Transcode preset は Higher bandwidth delivery を設定
- Video latency は Low を設定
| 上り方向 | 下り方向 | ビットレート | 遅延 |
|---|---|---|---|
| WebRTC | HLS | 4,500 kbps | 2,565 ms |
| RTMP | HLS | 4,500 kbps | 2,010 ms |
比較結果
TRTC 独自プロトコルや WebRTC を上り方向と下り方向の両方で使用した場合に、配信遅延が最も小さい結果となりました。 また、下り方向で HLS を使用すると、いずれの場合も配信遅延が 2,000 ms 以上という結果でした。 この結果から、上り方向で WebRTC や RTMP を使用した場合に、下り方向で TRTC 独自プロトコルや WebRTC を使用すると数百ミリ秒の配信遅延しか発生しないのに対し、HLS を使用すると数秒の配信遅延が発生してしまうことが分かります。 これは、数秒ごとに分割された映像のチャンクをバッファする HLS の仕様によるものと考えられます。
おわりに
今回は、Tencent Cloud の TRTC と CSS、AWS の IVS について、利用可能な配信プロトコルと配信遅延の比較結果をご紹介しました。 結論として、下り方向の配信プロトコルにおいて IVS Low-Latency Streaming で唯一利用可能な HLS を使用するよりも、TRTC や CSS で利用可能な TRTC 独自プロトコルや WebRTC を使用した方が、小さい遅延で配信できることが分かりました。
また、他の観点として、それぞれのコストや、アーカイブ保存機能、最大視聴者数なども比較してマルチクラウド化を検討しています。 ライブ配信基盤における各クラウドベンダーのサービスを比較する際に、ご参考になれば幸いです。
参考
最後まで読んでいただき、ありがとうございます！
この記事をシェアしていただける方はこちらからお願いします。