Apple仕様のHTTP Live Streaming（HLS）をアダプティブ配信する環境をAWS（Amazon Elastic Transcoder→S3→CloudFront）で構築して、配信最適化できるか試してみた。
※Akamaiでの配信方法は以下
動画配信技術 その1 - HTTP Live Streaming(HLS) - Akamai Japan Blog
動画配信技術 その3 - Universal Streaming(HDS/HLS) - Akamai Japan Blog
HTTP Live Streamingとは、容量の大きい動画ファイルを10秒ごとに分割して、読み込みながらでも再生できる。特別なストリーミングサーバを必要とせず、通常のWEBサーバで配信ができるのも利点。iOS、Androidともに対応端末が幅広い。
Apple公式の資料
「特別なサーバソフトを使用しないオーディオとビデオの送信」
https://developer.apple.com/jp/documentation/StreamingMediaGuide.pdf
アダプティブ配信とは？
回線品質によって、読みこむファイルを切り替えながら再生する。
３G→LTE→WIFIのように通信環境が変化すると、それに応じた動画再生に切り替えられる。
S3に元動画を入れる用と、出力用の２つのバケットを準備する。
元となるMP4動画を-inの方にアップロードする。
素材はNHKのクリエイティブ・ライブラリーを引用。
わかりやすく
・高画質（飛行機）
着陸する飛行機（６）ズームイン:素材をさがす:NHKクリエイティブ・ライブラリー
・中画質（新幹線）
東北新幹線「はやぶさ」:素材をさがす:NHKクリエイティブ・ライブラリー
・低画質（船）
ベネチア 運河（１）:素材をさがす:NHKクリエイティブ・ライブラリー
としてみた。
Amazon Elastic TranscoderでMP4ファイルを
ts分割したファイルとプレイリスト（m3u8）をS3へ保存する。
Elastic Transcoderを選択
Create New Pipelineから、以下のように入力する。
今度は左のメニューでJobsを選択肢、Create New Jobを押下。
Create New Jobから高画質の場合はhighというフォルダに出力されるよう登録。
右下のCreate New Jobを押下すると、以下のようにS3の-out/high/〜に出力される。
これをmidとlowの分繰り返す。
それぞれのプレイリストの中身は以下。
10秒指定したのに、きっちり10秒で分割されるわけではない。
high.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-ALLOW-CACHE:YES
#EXT-X-TARGETDURATION:13
#EXTINF:12.078733,
high00000.ts
#EXTINF:9.009000,
high00001.ts
#EXTINF:9.009000,
high00002.ts
#EXTINF:1.768433,
high00003.ts
#EXT-X-ENDLIST
mid.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-ALLOW-CACHE:YES
#EXT-X-TARGETDURATION:13
#EXTINF:12.012000,
mid00000.ts
#EXTINF:9.009000,
mid00001.ts
#EXTINF:9.009000,
mid00002.ts
#EXTINF:12.012000,
mid00003.ts
#EXTINF:9.009000,
mid00004.ts
#EXTINF:9.009000,
mid00005.ts
#EXTINF:12.012000,
mid00006.ts
#EXTINF:9.009000,
mid00007.ts
#EXTINF:8.942267,
mid00008.ts
#EXT-X-ENDLIST
low.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-ALLOW-CACHE:YES
#EXT-X-TARGETDURATION:13
#EXTINF:12.058444,
low00000.ts
#EXTINF:8.241567,
low00001.ts
#EXT-X-ENDLIST
通信回線の状態により、これらを切り替える為にindex.m3u8を自分で作成してoutバケット直下にアップロード。
index.m3u8
#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=400000
https://d1h36s1zyfuae3.cloudfront.net/low/low.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=600000
https://d1h36s1zyfuae3.cloudfront.net/mid/mid.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1, BANDWIDTH=2000000
https://d1h36s1zyfuae3.cloudfront.net/high/high.m3u8
CloudFrontで配信するための設定。
Originも設定する。
バケットに直接アクセスされたくなく、常にCloudFrontからの配信になるよう制限したかったら、Restrict Bucket AccessをYesにする。
一通り設定完了したら、しばらく時間がかかる場合もあるが、CloudFrontでアクセスできるようになる。
URLは以下
https://d1h36s1zyfuae3.cloudfront.net/index.m3u8
AndroidのChromeで開くと、ファイルをダウンロードしてしまう。
※HTMLのAタグでリンクすると、Androidでも再生可能。
iPhoneのsafariで開くと、動画が読み込まれ再生準備になる。
再生ボタンを押下すると、標準のプレーヤーが立ち上がり、再生が開始する。
再生途中から、電車の動画に切り替わる。
index.m3u8がリクエストされて、low.m3u8の指示でtsファイルが読み込まれ、回線品質によって、mid.m3u8に切り替わって、midのtsファイルが読み込まれ始める。
iPhone端末の設定 ＞ デベロッパ ＞ NETWORK LINK CONDITIONER
から、回線品質を変更してテストすることができる。
回線が良ければ、飛行機が配信される。
まとめ
Appleの仕様なので、safariでリピート再生した場合、動画を読み込み直さないでキャッシュを上手く利用してくれるのだが、Androidのchromeだとリピートなのにtsファイルを読み込み直すので無駄がある。
↓リピート再生するたびに、low00000.ts、low00001.tsをダウンロードしてしまう。（表示は降順）
ブラウザの挙動なのでアプリで実装する場合は、上手くキャッシュを再利用すればいいが、ブラウザベースのHTML5配信でリピート再生すると、端末依存かもしれないがパケ死配慮されない残念な作りになっている。
Elastic Transcoderの設定が雑なのか、MP4ファイルを元にtsに細かく出力した場合に、元ファイルよりもファイルサイズが大きくなってしまうという本末転倒なことになってしまった。この辺をチューニングする必要があるのだろう。
S3のinputバケットにMP4の動画をアップしたら、Elastic Transcoderでhigh, mid, lowに書き出されるなど自動化することもできるようだ。
AWS便利すぎてやばい。配信コストはどうなのか？要調査。