AbemaTV「通信節約モード」における品質確定プロセス

通信節約モードの品質確定プロセス

御池崇史氏（以下、御池）：よろしくお願いいたします。トラックB、最後になりますが、もうしばらくお付き合いください。通信節約モードという、いわゆるAbemaTVが持っている最低帯域のレゾリューションについて、その品質あるいはビットレート、動画に関わる要素をどうやって決めていったかをお話ししていきたいと思います。

軽く自己紹介しますと、私は動画変換、あるいは音の変換のスペシャリストでございます。これまで出てきたエンジニアの中で、ちょっと毛並みは違うんですけれども、開発本部で一緒にやらせていただいております。

私の仕事の領域は、まさにアウトプット品質の担保。動画トランスコードのパラメータを最適化することです。

そのためには、入り口から出口まで全工程を俯瞰して品質を担保しなければなりませんので、「入稿ルールを整備すること」あるいは「入ってきたデータをどのように処理するか」「どうすればどんな視聴環境にも耐えられるものが作れるのか」など、マスタリング領域としての品質の担保がメインのミッションです。

お使いになられている方もいると思いますが、「通信節約モード」がございます。

これについて詳細はWebなどで後ほど見ていただくとして、生成の経緯について説明していきたいと思います。まずは、どういうものか知っていただきたいので、動画をご覧ください。

動画：Hello！　通信節約モードってご存じですか？　見た目はほぼ変わることなく、データ通信量を約50パーセント以上も節約できちゃうんです。メニューから設定をタップ。画質設定から回線を選択。通信節約モードをタップ。以上！　それではみなさん、ごきげんよう！

御池：というものでございます。お使いになられたことのある方、いらっしゃいますか？

（会場挙手）

あ、けっこういらっしゃる。ありがとうございます。本当にありがとうございます。こういうふうに設定しておいていただけると、Wi-Fi環境から抜けたときも安心して視聴できるのではないかと思っています。

では、これを作るに至った経緯から、ご説明したいと思います。実はこれをやる前に、もともと持っているレゾリューションのSD帯の最適化とダイエット、情報量の削減を行いました。「じゃあ次は、HD帯の高画質化かな」と思っていたところ、こういう話がありました。

実はAbemaTV、開局当初は横視聴のみの対応だったんですが、これが1周年において縦にも対応いたしました。縦に対応したことを踏まえると、「縦視聴において、自分たちが持っている画素帯、レゾリューションは本当に最適なのかを、改めて考えてみようよ」というお話をいただきました。

なおかつ、「ユーザーが安心して使えるように、もっと下のレゾリューションが欲しいね」「20パーセントとか30パーセントの削減じゃ物足りない」「がっつり半減とかどうでしょうか？」とご提案をいただきまして、「や、やります」というところからのスタートでございます。これ要件を整理しますと、まず「新しいレゾリューション、画素帯を作る」ということです。

「縦視聴を意識した、最適画素を探ってください」と。

「大きな情報量削減はマスト」「ユーザーフレンドリーな機能として提供しましょう」という要件になります。じゃあやってみようということになりました。

開局当初の配信レゾリューション

こちらが開局当初からあります、5つのレゾリューションになります。

AbemaTVはフルHDから、720p、480p、360p、240pという5つのレゾリューションでスタートしました。この開局当初からの一番小さい240pを、さらに削っていこうということになります。

こういう一番下のレゾリューション、確かにニーズはあるだろうなと。じゃあ競合のサービスは、一体どういうことをしているんだろうかなどといった、外部環境の調査から始めました。

例えば、これは480p帯。どこがどことは言いませんが、一番右がAbemaTVです。比べてみますと、各社やはり同じような考え方に基づいて、ちょっとした差ありますけれども、基本的には同じようなアプローチでやっていらっしゃる。やはり、理詰めでいかねばならないなということです。

それをさらに下の領域に見ていきますと、ちょっと小さくて申し訳ないですけれども、この赤くなっている部分です。

これ持っているところと持っていないところがあったりもするんですけれども、やっぱり最低帯域にある種の役割を負わせて、準備していることになります。では、その帯域はAbemaTVも追加していきましょう。新レゾを追加する領域は、この辺りです。

じゃあ追加するにしても、「何を基準にそのビットレートやサイズといったものを決定すればいいのか」となったときに、理論値の根っこが必要になります。ちょっと数字見にくいですが今ここに出しましたのはだいたいこういうバランスで上から下まで配置されている、Tierのようなものがあって、それをベースに考えていきます。

理論値を導き出す

主力帯が、背景を赤く塗っている854×480です。

DVDで言うところのワイド画面です。それと1個上の720pくらいが、だいたい視聴数が多いということですので、ここを基準に考えていってみようというところから、理論値の当たりを付けていきました。

私の方で、映像に関するノウハウをいろいろ組み合わせまして、こういうところがいいのではないかと。ギリギリのライン削っていたときに、まず半分。半分と言うのは120kbpsという出し方です。その1個上の240pが240kbpsで提供していることもありまして、まずここの半分を狙うことになります。そのときのサイズ、320×180当たりがいいのではないかというご提案をしました。まず当たりを付けたわけです。

ここを基準に主観評価に投げていってみようということになります。計算しやすいように1280×720pから計算してみますとこういう計算になります、ということです。画素/ビットレートのバランス的には480pと同じになります。

話が前後しますが、「縦視聴」に立ち返りますとこうなります。持っている画素がどのようなカバレッジを持っているかも意識してまいりました。

例えば、720pくらいを出していると、「iPhone 6 Plus」「iPhone 7 Plus」は、こういうものでも十分dot by dot以上の高画質が保たれます。「iPhone 5」でしたら640×360くらいの画素を出していれば、実は縦視聴においては満足のいくクオリティが得られることになります。

縦視聴メインで使われている方などはこのへんを参考にしていただけると、自分が持っている端末で、「実はこのくらい出しときゃいいんだよ」というのがわかるかもしれません。

参考までにこういうふうに並べていってみますと、やはり大きな端末で見られている人ほど小さいレゾリューションに固定して見ると拡大率が上がってしまうわけですから、そのへんも意識して、自分で自分の端末でいい具合になるように調整していただければなと思います。

動画の引き伸ばしはどこまで許容できるか？

動画を長くやっていますと、やっぱり引き伸ばし作業自体に罪の意識がありますので、小さいレゾリューションを作るのはいいんだけれども、拡大倍率が大きくなりすぎてしまうと、やっぱりそれ自体がユーザーにとって不利になるのではないかという懸念もありました。ところが、いざ仮に実装して評価すると案外引き伸ばしてもいけていて。

もともとは「拡大倍率制限をした方がいいんじゃないですか？　せいぜい面積比で何倍までにした方がいいですよ」なんてことも思っていたんですが、「それはいらん」と。縦画素で、フルで見る感じになりました。

私が付けた当たりは320×180というサイズですが、本当にそれが最適かどうかもわからないわけです。ですから、1段階小さいサイズと一段解大きいサイズを用意して、ビットレートを12パターン、それぞれ用意しテスト環境に投げ込んでいきました。じゃあ、ここも動画を見ていただこうと思います。

2つ動画を見ていただきまして、1つはシンプルなもの。もう1つは、過酷なものを見ていただこうと思います。これは、音はございません。

こういうふうに、あんまり動きのあるものではないです。どうでしょうかみなさん、どこまで許せますでしょうか？（笑）。

（会場笑）

案外許せますよね。20Kで許せる人は、あんまりいないかもしれないですけれど。さすがに汚いので。じゃあ、80Kくらいで許せるという方、ちょっと挙手をお願いしたいんですけれども。

（会場挙手）

じゃあ、240Kと100Kの差がわかる方。

（会場挙手）

（会場笑）

案外いないということで（笑）。実はこれは、裏のパラメータを相当いじっていることもあって、こういうおとなしいものでは、あまり差が出ません。なんだったら、60Kとか80Kでもいけてしまうのではないかということになりました。

次の動画にいってみましょう。これは描画がものすごく負担のかかる、過酷なもので。これはちょっとだけ音が出ます。

（動画）

これはCGバリバリのものです。動きも激しいし、明滅も激しいといったもの。これはけっこう汚いんじゃないでしょうか？　ということです。要するに、こういうふうに見てみますと動画それぞれ、1つの動画だけで判断してしまってはいけないということになります。いろんな傾向を把握しながら、進めなければいけないということになります。

チューニングにおいて守らなければいけないドグマ

では、そういうものを踏まえて、こういうレゾリューション・ビットレート・フレームレート・サンプリングレートというのをコントロールしていくわけですが、さっき言いました、品質を維持するための裏の項目は多すぎるので割愛いたします。

ただし、AbemaTVは動画のチューニングをするにおいて、絶対に守らなければいけないドグマがあります。それは何か。この3つです。

全レゾリューション、上から6帯域においてフレームレートは同じでなくてはいけない。オーディオサンプリングレートは同じでなくてはいけない。キーフレームの挿入位置は完全一致しなければいけない。

つまり、動画生成における時間軸情報に最大限配慮しなければいけません。これは前のセッションでもありましたAdaptive Bitrate、あるいは、今日はネタとしてそんなに出ていないかもしれませんが、Server Side Ad Insertionを完全に実施するために絶対に外せない要件となります。

もしそういう要件を無視してよければ、画質を守るだけだったらコマを半分にしてしまえばいい。例えば、30fpsを15fpsで送り出せば画質は維持できますが、この手法は残念ながらAbemaTVにおいては使えないことになります。

品質評価のプロセス

そこから品質評価にいったんですけれども、こういう風にPSNR/SSIMなどで指標化をしてしまうと常識に縛られて理屈上の限界を突破できないので、あえて指標を使いませんでした。あくまでも主観評価でいくことになりました。

各ジャンルを用いまして、実写とアニメ、それぞれ10個くらい用意しました。

そして評価者に、こういうふうに着眼点を絞るガイド、漫然と見てはわかりませんので、「ここを見てください」と限定的に絞りまして。

それはやっぱり麻雀だったら手牌が見えなきゃ意味がないわけですから。

あるいは捨て牌も見えなければいけないですから、そういうところは気にしていこう、アニメも細かいところまでちゃんと見ていこうということです。

そういう要件を混ぜつつも、このようにさらに多数の端末でしっかり検証していき、けっこうQAの工数が膨大なことになりました。これほんの一部です。

実はここ下に、ちょっと左に文字が見えるかもしれませんが、膨大な着眼点が書いてありまして。1ファイル当たり5つの観点があると、こういうふうに検証していきました。

これはビットレートごと。そこにレゾリューションをかけて、そこにさらに検証端末をかけていくという、けっこう大変なことをしました。

結果として、私が最初に推奨しましたラインが正しく分界点であったという結論が出てきました。

この表、後ほどSpeaker Deckなどにアップされます。確かに理論値の分界点はここなんだけれど、よく見ると実は「画素はやっぱり多い方がいいよね」みたいな答えも導けたりします。

このへんは、後でじっくり見ていただけると楽しいかと思います。非常につらい検証でしたというお話です。

ファイル準備期間がほとんど無い問題

さらに、仕様が確定して「わーい」と喜んでいましたところ、なんとよく考えたら「え、準備しなきゃいけないファイル、数万ファイルに上りますよね」という相談が、エンジニアからまいりました。

「どうしよう」というところから必死に考えた結果、通常フローを踏まずに画質・音質的に十分な品質を保っているレゾリューションから新レゾを2次生成することにしました。先ほどのセッションでもありましたが、正規の手順を踏んで運用に負荷をかけるようなことをしてしまうと本当に全帯域でトランスコードされるんで、時間的に無理なんです。

なので、既存コンテンツについては完全にクラウド上の処理のみで実施したことになります。非常に大変でした。なおかつ、今出てきたようなトランスコーダーの部分で言っても、何種類ももあるんです。Liveで使っているもの、あるいは広告で使っているもの。それぞれに対して、品質のコントロールをしなければならなかったということになります。

では、そういうけっこう強引な主観評価検証をしましたが、まとめますと、動いているシステムの中で新しい要素を追加していくのは当然大変ですよね、ということです。

次に、自分はこうしたいんだけれども、その結果が正しく導かれるようにするために要目立てをするのもけっこう大変です。いかにテスト項目書を書くか、となると思います。

「工数が少ない」「時間も限られている」「何よりも、やっぱり画質を守りたい」という思いがありますので、そこと、削らなければいけないというミッションのせめぎ合い。ここが腕の見せどころだったんじゃないかなという感じはします。

あとは、やっぱりディレクターをはじめ、QAチーム、サーバーサイドのエンジニア、コンテンツを運用する人、すべてに対して説明責任がありますので、そういうところからの理解を得ながら、進めなければいけませんでした。

QAに関しては、「もっとこうすればいいんじゃないか」という案を逆にQA担当者からいただくことで、次の新しい打ち出しのときのノウハウとして生かせるといったことになります。

駆け足でしたけれども、私の発表はこれまでとなります。より詳細な情報はネットでググるなりしていただければ、何がしか出てくると思います。この後、懇親会も予定していますので、ぜひ奮ってご参加ください。今日はご参加、どうもありがとうございました。

（会場拍手）