[Video Streaming] 動画配信の仕組みをまとめました

今更ながら動画配信（ライブストリーミング配信中心）に関してまとめます。前半は動画配信の基礎、後半にライブ配信の遅延のミニマイズ、画質の最大化に関してまとめました。

#配信（視聴）方法

動画の配信（と視聴）には下記のパターンがあります

- ダウンロード
- プログレシブダウンロード
- ストリーミング
- アダプティブストリームング

##ダウンロード
通常の通信（http,https)通信を介して動画ファイルをダウンロードする仕組み

##プログレシブダウンロード
通常の通信（http,https)通信を介して動画ファイルをチャンクでダウンロードする仕組み

##ストリーミング
パケット通信をしながら、動画ファイルを構成し視聴する仕組み。

##アダプティブストリームング
ストリームング配信の中でも視聴者の環境に合わせた形式で配信する仕組み。低めのビットレートで配信をはじめ、まだ余裕があると（プレイヤーが）判断するとさらに上のビットレートで配信していき、その環境で正常に視聴できる最高品質の映像を配信します。

大きく分けると、ダウロード型とストリーミング側になります。

#ストリーミング配信

HTTP/HTTPSに限らずともストリーミング配信が可能ですが、最近では通常のアプリやブラウザーで視聴する場合、HTTP/HTTPSを介してストリーミングするのが一般的です。そして、そのストリーミング配信の中にもいくつかの形式があります。

- HLS (Http Live Streaming)
- HDS
- Smooth Streaming
- MPEG-DASH

MPEG-DASHが機能的にはいいのですが、Apple社はHLS推し、MSはSmooth Streamingを推しています。

MPEG-DASHの詳細はこちらからを参照
:point_right: https://qiita.com/gabby-gred/items/c1a3dbe026f83dd7e1ff
:point_right: https://qiita.com/STomohiko/items/740f47f798f5762b03cc

##ストリーミングのフロー

キャプチャーされた映像・音声データはエンコーディング（圧縮）や暗号化（DRM）などが行われ、指定されたビットレート（チャンク）ごとに配信されていきます。

#エンコーディング

まずキャプチャーされた映像はエンコーディングされます。

元となる動画ファイルはファイルサイズが大きいためネットで視聴するためにはそのファイルを圧縮する必要があります。この圧縮するプロセスをエンコーディングと呼びます。

動画ファイルとは映像データと音声データを組み合わせています。プレイヤーによってこの二つの組み合わせ方や圧縮の方法で再生できるもの、できないものがあります。エンコーディグの役割は各環境で正常に再生できる様にすることもあります。

エンコーディング時にフレームレート、解像度、ビットレートを指定します。この3つで配信時のファイルサイズが決まります。


##フレームレート(fps)
フレームレートとは、１秒間に何コマ静止画像を使っているか、を示す単位です。なので、フレーム数を増やせばよりスムーズな動画になるのと同時にファイルサイズも上がります。

*人間の目は60fpsまで認識できるそうです。一般的に、テレビやDVDは30fpsぐらい。映画は24fps、ワンセグテレビが15fpsとのことです。15fpsが底辺と考えておけばいいかと思います。

##解像度

解像度とは１画角「dpi」の中の粒度の数になります。「dpi」は「ドット・パー・インチ（Dots Per Inch）」の略で、1インチ（2.54センチ）の幅の間にどれだけのドットを表現できるかを表します。

- ワンセグ（300px × 180px） 
- SD（720px × 480px） 
- HD（1280px × 720px）
- フルHD（1920px × 1080px）
- 地上デジタル（1440px × 1080px) 
- 4K UHD（3840px × 2160px） 
- 8K UHD（7680px × 4320px） 

##ビットレート

ビットレートは1秒間にどれだけの動画情報を保持するかを指定します。ビットレートについては映像と音声を別に設定します。ビットレートは解像度やフレームレートに合わせて適切ものを設定します。ビットレートだけあげても無駄に負荷が大きくなるだけとなります。

| 解像度(画質)　/　フレームレート | フレームレート29.97fps以下 | フレームレート30fps以上 |
|:--|:--|:--|
| ワンセグ　(360px × 180px/240px) | 0.75Mbps～ | 1.00Mbps～ |
| SD　(720px × 480px) | 2.50Mbps～ | 4.00Mbps～ |
| HD　(1280px × 720px) | 5.00Mbps～ | 7.50Mbps～ |
| フルHD　(1920px × 1080px) | 8.00Mbps～ | 12.00Mbps～ |
| 2K　(2560px × 1440px) | 16.00Mbps～ | 24.00Mbps～ |
| 4K　(3840px × 2160px) | 45.00Mbps～ | 68.00Mbps～ |
| 8K　(7680px × 4320px) | 130.00Mbps～ | 200.00Mbps～ |

参考資料
:point_right: [動画のフレームレート、解像度、ビットレート](https://itskillmap.com/menu2_29/)


#ライブ配信の遅延をミニマイズ

ライブ配信をする場合、やっかいなのが遅延。せっかくライブなので遅延がないのがベスト。ただ、ライブ配信方式(http/httpsを介して配信)には限界があり、5秒、10秒はどうしても遅れてしまいます。　それを許せない、という場合は通信のプロトコール自体を変える必要があります。

ライブ配信の遅延の要素は

|||
|:--|:--|
|カメラとディスプレイのラグ|90ms|
|エンコード・デコード|30ms|
|エンコード・デコード|30ms〜|
|ネットワーク通信（上下）|30ms〜|
|クライアント側の処理|30ms〜|
|バッファリング|10ms〜|

:point_right: [ライブストリーミング低遅延化の取り組み @ DeNA](https://www.slideshare.net/akirahiguchi/dena-112412583)

カメラとディスプレイの遅延に関しては、また今度カバー。今日はエンコーディング、とネットワーク通信での遅延を最小限にするところを見てみます。エンコーディングはエンコーディングソフトの設定やエンコーディングする機材そのもののアップグレード。あとは配信ファイルの最小化があります。またCDNもライブ配信用に設定をチューンアップすることもできます。

## キーフレーム

通常複数のフレームを表示するさいに、すべてのフレームで完全な絵を表示するのでなく、前のフレームとの差分だけを情報として持ち、変更部分を表示するという仕組みを使うことによって、1フレームでもつ情報量を最小化しています。　ただ、ある一定期間ごとに完全な絵を送ってあげないと途中から見たいときに完全な絵がない状態となってしまいます。ここで完全な絵を持たせる周期をキーフレーム周期と呼びます。

ライブ配信ではTSファイルをダウンロードして再生しています、なので遅延をできるだけ短くしたい場合はできるだけ細かなファイル粒度で配信指定いく必要があります。Apple推奨は1TSファイル10秒とのことです。なので、遅延を通常よりも少なくしてほしい、と言われたら、10秒以下に設定しています。

では具体的のどうやってTSファイルを10秒以下に設定するのかというと、キーフレームの指定を短くする設定します。TSファイルはキーフレームの周期指定によって生成されるため、キーフレームが10秒以上のファイルで10秒以下のTSファイルを生成することができません。

:point_right:  [社内勉強会で HLS と Key frame について改めて解説した](https://hori-ryota.com/blog/study-hls-keyframe-20170808/)

#次

次は映像のDRMに関してまとめたいと思います。