動画配信サービスとしてこの先生きのこるには
山中勇成氏（以下、山中）：僕、振り仮名振ってなかったんですけど、ちゃんと「このさきいきのこる」って読んでくれてありがとうございます。ということで、「動画配信サービスとしてこの先生きのこるには」というタイトルで発表させていただきます。スライドを作ったんですけど、けっこう技術寄りの話になってしまいました。
自己紹介なんですけど、今サイバーエージェントの新卒2年目でAbemaTVのコンテンツ配信チームにおります。
新卒2年目なんですが、いろいろなところでアルバイトした経験がこんな感じであります。
動画配信サービス、なんでもいいですけど「見てるよ」って方どのぐらいいらっしゃいますか？
（会場挙手）
ありがとうございます。その中で「中の人だよ」っていう人？
（会場挙手）
あっ、やっぱりけっこう……（笑）。たぶん3人ぐらいですね。わかりました。ちょっと技術寄りの話になっちゃうんですけど、お付き合いください。「動画配信」といっても、LIVEとVOD、ライブストリーミングの配信とビデオの配信という大まかに2通りあるんですけど、今回はライブのほうにフォーカスしてお話しします。
動画配信サービスなんですけど、いわゆる「動画元年」というのが新聞とかでいろいろ言われてきて、でもその時代はやっと過ぎて、動画配信サービスがいろんなものが出てきて加速が止まりません。
今では動画配信の専門サイトだけでなく、料理やライブコマース、ギャンブルなど、いろんなサービスで動画ライブ配信というのを取り込んで機能の1つといった感じで提供されることが多いです。
ですが、インターネットで動画配信をするのはすごいつらい。
動画配信はなぜつらいかというと、テレビの放送は帯域が電波としてある程度あるんですが、インターネットってベストエフォートなので、そのなかで配信をする必要があります。
インターネットだとなにがよくないかというと、帯域の保証ができないというのがまず1つです。もう1つが、視聴者が増えると配信する帯域も増えるという感じですね。
テレビと違ってトレードオフで犠牲になるものが多い
山中：テレビの場合は、アンテナで電波を使って帯域も保証されているし、視聴者が何人増えようと別に配信者がどうこうする必要はないんですけど、インターネットの場合は、視聴者がまた１人増えたら配信する帯域も増える、いう感じです。
さらにプロトコルやコーデックの変化が激しいということが挙げられます。たびたび効率のよいプロトコルとかコーデックが生まれているので、それに追従していかなければならない。
さらに端末による対応プロトコルとかコーデックとかに差があるので、複数サポートする必要があります。例えば「Appleだとこの方式」とか決まっているので、それをサポートしないと審査に通らなかったりということがあるので複数サポートが必要です。
今回これがとくに重要なんですけど、動画配信のトレードオフというものがあります。
低遅延・高スケーラビリティ・高品質な動画配信はすごく難しい。難易度が高いです。この3つが配信において重要です。
例えば、画質。もう一番低くていいというなら超低遅延にできるんですけど、その代わり画質が悪くなる。もしくは、視聴数100人でいいというなら低遅延にできる、みたいな感じでトレードオフがあります。
次は遅延とプロトコルの話です。この2つはけっこう関係ないように見えるんですけど、実は関係があります。
遅延はどこで生まれるかというと、いろいろなところで生まれているんですけど、映像が配信されるまでこんな感じの流れで、サーバ上だったりユーザーのパソコンのところでエンコードするのにだいたい4秒ぐらいかかります。
HLSとかでチャンクごとに区切るので、設定によると思いますけど、さらに2秒から10秒かかる。CDNで配信するのに3秒ぐらい。プレイヤーのバッファを待たなきゃいけないので10秒ぐらいかかるというのがだいたいですね。違うところはあると思いますけど、だいたいはこんな感じで配信しています。
今後の動画プロトコルについて
山中：押さえておきたい動画のプロトコルなんですけど、1つはHLSです。
これはAppleが提唱しているプロトコルです。あとMPEG-DASHで、Apple以外というとあれなんですけど、HLSをより高機能にした、HTTP上で動画ストリーミングを行う規格。
けっこう初見の方もいるかもしれませんが、SRTというプロトコルが最近出てきました。これはUDP上なんですけど、TCPのように信頼性を保つ動画ストリーミング向けのプロトコルです。
遅延とプロトコルが関係あると言ったのはこの図のとおりです。
HLSはセグメントごとに何秒何秒というファイルを作らなきゃいけないので遅延が起きやすい。対して、RTMPというプロトコルとかは遅延を短くできるので、プロトコルはすごく重要です。
低遅延の取り組みをいろいろな会社がしていますが、1つの方式として低遅延のHLSというものがあります。HTTPのChunked-Transfer-Encodingを使って配信して、チャンクサイズより細かい単位で送信する仕組みだったりとか。
あとはほかにも、圧縮コストを低減させているところがあります。これはH.264の圧縮コストの高いBフレームでの圧縮を除いてエンコードすることにより、ちょっと帯域は増えるんですけど、圧縮時間とバッファを抑えています。
これらのいろんな低遅延の取り組みだったりをするとメディアのフォーマットがけっこうバラバラになるんですけど、これらを統一しようというのがCMAFという規格です。
個人的にプロトコルの将来はこんな感じかなと思っています。
RTMPというのが今まで使われてきたんですけど、これがFlashとともにそろそろ終わるだろうと。HLSはAppleが使っているのでけっこう今後も使わなきゃいけないのかなというのとか。SRTが今後普及するとは思うんですけど、ユーザーがUDPで通信するってなるともうちょっと普及は先なのかなと思っております。
今後の押さえておきたい動画コーデック
山中：次は、次世代動画。次世代動画と言っているのは、よりよい体験にするための動画の品質のことで、次世代動画の要件ってだいたいこんな感じになっています。
例えば、4Kだったり、広帯域だったり、ダイナミックレンジが広い色だったり、フレームレートが高かったりみたいな感じです。ここでも押さえておきたい動画コーデックがありまして、動画の品質が上がるということは帯域も上がるんですけど、それを抑えるためのコーデックがあります。
1つはHEVCというコーデックで、これはH.264の後継となるコーデック。日本の4K/8K放送でも採用されているものです。もう1つがAV1というコーデックで、こちらはHEVCに対抗してオープンでロイヤリティフリーな動画コーデックになっています。最近FirefoxのNightly Buildでも見れるようになりました。
これも個人的に思う動画コーデックの今後なんですけど、こんな感じですね。
今H.264とAACというのがすごい主流なんですけど、将来的に帯域と高品質になっていく上でHEVCかAV1が流行るのではないかなと思っています。AV1はちょっと短いのは、たぶんほかのコーデックがそろそろ出てくるんじゃないかと思っております。そろそろというのは将来の中でってことですね。
まとめなんですけど、ライブストリーミングの遅延は、品質とスケーラビリティとトレードオフです。
つまり、動画配信サービスとしてこの先生きのこるには、遅延をより短くして、品質を上げつつ、スケーラビリティを確保することが必要です。タイトルに関してはここで終わりです。
以上です。ご清聴ありがとうございました。
（会場拍手）
端末への互換対応に苦しめられる要
司会者：山中さんありがとうございました。ご質問がある方は挙手をお願いいたします。どうぞ。
質問者1：品質をよくするためのコーデックにいろいろ対応していきたいとは思うんですけど、それが再生できない端末への互換が非常に大変だなという体感をしておりまして。AbemaTVはどのへんまでサポートしていこうかなとか、なにかそういうのあったりしますか？
山中：そうですね。最初に書いたとおり、やっぱりテレビと違って規格がバシッと決まっているわけじゃないので、たぶんいろんな端末があったり、H.265が出てもたぶんH.264の端末のためにサポートしなきゃいけないというのはあると思います。
どこまでというのを具体的には言えないんですけど、動画配信をやる上では、けっこう長いことをいろんな端末の対応に苦しめられるのではないかな、根気がいるんじゃないかなと思っています。
質問者1：ありがとうございます。
司会者：ほかにご質問がある方はいらっしゃいますか？
質問者2：コーデックあんまり詳しくないので教えてほしいんですけど、プロトコルとコーデックの相性ってあるんですか？
山中：基本的にプロトコルはなにかしらを伝送するための規格で、コーデックは動画の圧縮自体の仕組み。まぁ、それも規格なんですけど、基本的にはそんなにはないですね。
プロトコルによってターゲットとしているコーデックが決まっているものとか、プロトコルの中でメタとしてこの動画はなにで圧縮されているって送るんですけど、それが例えば定義されていないというと、確かにそのプロトコルでコーデックを送れなかったりということはあります。
司会者：それではお時間になりましたので、これで締め切らせていただきたいなと思います。山中さん、ありがとうございました。
（会場拍手）
