ライブ配信を支える技術と知識

こんにちは、IT 基盤部の高橋です。
DeNA が提供するエンタメ系やヘルスケア系のサービスのインフラを見ています。
大規模ライブ配信を支える技術については DeNA TechCon で弊社漢が紹介しています ( 2017 , 2018 ) が、今回は大規模ライブ配信を支える技術をさらに支えるライブ配信の基礎知識について紹介します。

通信プロトコルの種類

映像を届けるためのプロトコルには数多くの種類がありますが、弊社では主に以下の二つを利用しています。

RTMP (Real Time Messaging Protocol)
- その名の通りリアルタイムにメッセージをやり取りするために開発されたプロトコル
- Flash Player での利用を想定されている、映像や音声を通信させることができる
- 持続接続のプロトコルで、状態を持つ
- 映像は JPEG/H.263/VP6/AVC(H.264) のコーデック、音声は Linear PCM/ADPCM/MP3/AAC/speex のコーデックに対応
HLS (HTTP Live Streaming)
- HTTP を通してストリーミング配信をできるようにしたもの
- 配信される映像を記録したプレイリスト (m3u8) とメディアセグメント (ts) を使って、映像を届ける
- マスタプレイリストにメディアプレイリスト含めることで複数のビットレートを扱うことが出来たり、DRM 対応などもできる
- HTTP なので Apache や Nginx からでもライブ配信することが出来る (= CDN と親和性が高い)

映像コンテナの種類

映像コンテナ (マルチメディアコンテナ) には以下のようなものがあります。これらは動画や音声を格納することができます。

MPEG-2 TS (mpegts/mpeg2ts)
- 地上波デジタルや Blu-ray/DVD などで使われるコンテナ
- 188 バイトの固定長パケットに映像や音声、プログラム情報を記録する形式となっている (TS パケット)
- PID が同一のデータを集めることで音声や映像を復元することができる
MP4 (quicktime mov)
- QuickTime の mov が元となって作られたコンテナ
- 複数トラックを記録させることやメタデータの記録も可能となっているため多重化できるコーデックなら記録できる
- Movie Fragment という 3GPP 規格もあり分割された映像として記録もできる
flv (rtmp)
- FlashVideo で利用できるコンテナ
- 映像・音声以外にもファイルやスクリプトも埋め込める
- rtmp の形式とほぼ同じであるためストリーミングで使える
- 格納できる映像コーデックが VP6/H.264/On2、音声コーデックが MP3/AAC/Speex など

コーデックの種類

映像や音声の圧縮形式で、分かりやすい例だと zip 圧縮か rar 圧縮かの違いです。 tar.gz をコンテナとコーデックとして表現すると、映像や音声を tar コンテナでまとめて gz コーデックで圧縮していると表現できます。

H.264 (AVC = Advanced Video Coding)
- 動画圧縮形式、フレーム間予測やエントロピー符号化方式など高い圧縮率をもつ
- プロファイルによって利用目的に応じて適切な値を定義できるようになっている
- 4K までの映像を扱うことができる
H.265 (HEVC = High Efficiency Video Coding)
- H.264 の後継、H.264 におけるブロックノイズの低減や同ビットレートでも 40 %近い圧縮率を出せる
- 8K 映像やスーパースローのような高 fps も扱うことができる
VP6/VP8/VP9
- On2 のビデオコーデックの一つ、VP6 は H.264 よりも高い圧縮率とデコードが早い
- ライセンス問題で H.264 よりも普及しそうでしていない

Mux/Demux について

コンテナにデータを入れることを Mux
コンテナからデータを取り出すことを Demux
と呼びます。
Mux は Multiplexing のことで多重化とも呼んでいます。

フレームとフレームレートについて

30 fps の映像とは、1 秒につき 30 枚の画像に分割している映像のことです。
分割された画像はフレームと呼ばれます。
フレーム数が多いほどより滑らかに映像は表現されるが、フレーム数が増えるためデータサイズが増えます。
そこで動画では分割したフレームを I フレーム・P フレーム・B フレームに分類し映像の差分だけを記録するようにしています。 I フレーム・P フレーム・B フレームの集まりのことを GOP (Group Of Picture) と呼びます。

I フレーム
- 元となるピクチャのこと
- ほぼ全ての情報が格納された映像フレームで、データサイズが一番大きい
- キーフレームとも言う
P フレーム
- フレーム間の差分ピクチャのこと
- 差分映像フレームで、データサイズは小さめ
B フレーム
- 補正フレーム
- ベクトル差分の補正を行うフレーム、次のフレームまでの補正差分を持つ、データサイズは最も小さい

画素数について

1920x1080 や 1280x720 などの幅x高を示す単位です。
FullHD だと 1920x1080 の画素数で HD だと 1280x720 の画素数となります。
いずれも16:9が基準となっています。
また、表現にもいくつかあるため、

1080p と表記がある場合は 1920x1080 のプログレッシブ画像である
1080i と表記がある場合は 1920x1080 のインタレース画像である
1080p60 または 1080p/60 と表記がある場合は 1080p の 60 fps 映像である

ビットレートについて

画質の良さに比例する単位で、3Mbps や 500Kbps のように bps (bits per second) で表現します。
転送量に密接に関わってくる数値となります。
配信側も視聴側もこの帯域が利用できるようになっている必要があります。

プロファイルについて

映像コーデックによっては映像の種類に応じてプロファイルと、エンコード強度 (符号化) レベルなどを定義されています。
それぞれビットレートや処理負荷に影響します。
下記はH.264のプロファイルの一例です。

baseline
- I + P フレームのみ
main
- I + P + B フレーム
high
- main + 高ビットレート

映像を届けるための仕組み

用語の定義

Origin
- Origin サーバ、映像を受け付けるサーバのこと
- Publisher から映像を受取り、このサーバで受け付けた映像は配信するための形式に変換され、Edge サーバから取り出され Viewer に届けられる
- 必要に応じて Publisher から受け取ったストリームを変換することもある (transcode)
Edge
- Edge サーバ、映像を配信するサーバのこと
- 映像は Origin サーバから取り出して配信を行う
- 多数の Viewer が接続する、そのため同じストリームの接続は束ねられ複数の Viewer が居ても Origin への接続数を減らす役割を持っている (offload)
- Viewer の利用するプロトコルに応じて Edge は映像の届け方を変えている
Publisher
- 映像の配信元、配信者のこと
- カメラやマイクから受け取った映像・音声データは Publisher 側でエンコードし、映像データとして Origin に送信している
Viewer
- 映像を見る端末、視聴者のこと
- 視聴者には利用環境に応じて、視聴形態が違う

ストリームについて

RTMP を例にすると、RTMP 内では Video パケットと Audio パケットがパケットとして流れています。
それぞれのパケットには時間が記録されているので、Video パケットと Audio パケットの時間を同期しながら再生させることで音ズレせずに映像が流れます。

Publisher から Origin に届くまで

配信者はエンコーダを使いながら、ビデオカメラやマイクから拾った映像・音声を適切に変換しながら Origin にストリームを流しています。
エンコーダには FMLE や OBS などがよく利用されます。

Origin から Edge に届くまで

Origin ではある程度の映像パケットを受信したら、Edge サーバで利用可能な形式のパケットに変換します。
例えば 2 秒チャンクを生成し、Edge へは 2 秒チャンクを配信します。
この 2 秒チャンクを生成するためには、H.264 などの映像では I フレーム (キーフレーム) が記録されていないと映像を構成することが出来ないためある程度のバッファが必要になります。
つまりフレームレートとキーフレーム挿入間隔によって I フレームでの分割を行いつつ Edge にデータを転送しています。(= 遅延時間)

Edge から Viewer に届くまで

Edge では Origin から受け取った映像データを繋ぎに来ている Viewer 全てに同じデータを配信する作業を行います。
ただし、Viewer によっては視聴タイミングが違ったりするため、一時的なキャッシュを行う (= chunk size) ことがあります。
また、Viewer 側でもある程度のバッファを積むことがあります。それはネットワークの帯域が一定でない場合に数秒間バッファ積む事で映像の乱れを防いでいるものです。(NetStream#BufferTime など)
RTMP などのリアルタイムストリームについてはそのまま届けることができますが、遅延が発生する場合はこの部分である可能性が高いです。