全レゾリューション、上から6帯域においてフレームレートは同じでなくてはいけない。オーディオサンプリングレートは同じでなくてはいけない。キーフレームの挿入位置は完全一致しなければいけない。動画生成における時間軸情報に最大限配慮しなければいけません。Insertionを完全に実施するために絶対に外せない要件となります。いう要件を無視してよければ、画質を守るだけだったらコマを半分にしてしまえばいい。30fpsを15fpsで送り出せば画質は維持できますが、この手法は残念ながらAbemaTVにおいては使えないことになります。品質評価のプロセスそこから品質評価にいったんですけれども、こういう風にPSNR/SSIMなどで指標化をしてしまうと常識に縛られて理屈上の限界を突破できないので、あえて指標を使いませんでした。主観評価でいくことになりました。各ジャンルを用いまして、実写とアニメ、それぞれ10個くらい用意しました。評価者に、こういうふうに着眼点を絞るガイド、漫然と見てはわかりませんので、「ここを見てください」と限定的に絞りまして。それはやっぱり麻雀だったら手牌が見えなきゃ意味がないわけですから。捨て牌も見えなければいけないですから、そういうところは気にしていこう、アニメも細かいところまでちゃんと見ていこうということです。いう要件を混ぜつつも、このようにさらに多数の端末でしっかり検証していき、けっこうQAの工数が膨大なことになりました。実はここ下に、ちょっと左に文字が見えるかもしれませんが、膨大な着眼点が書いてありまして。1ファイル当たり5つの観点があると、こういうふうに検証していきました。これはビットレートごと。そこにレゾリューションをかけて、そこにさらに検証端末をかけていくという、けっこう大変なことをしました。結果として、私が最初に推奨しましたラインが正しく分界点であったという結論が出てきました。Deckなどにアップされます。確かに理論値の分界点はここなんだけれど、よく見ると実は「画素はやっぱり多い方がいいよね」みたいな答えも導けたりします。このへんは、後でじっくり見ていただけると楽しいかと思います。非常につらい検証でしたというお話です。ファイル準備期間がほとんど無い問題さらに、仕様が確定して「わーい」と喜んでいましたところ、なんとよく考えたら「え、準備しなきゃいけないファイル、数万ファイルに上りますよね」という相談が、エンジニアからまいりました。「どうしよう」というところから必死に考えた結果、通常フローを踏まずに画質・音質的に十分な品質を保っているレゾリューションから新レゾを2次生成することにしました。先ほどのセッションでもありましたが、正規の手順を踏んで運用に負荷をかけるようなことをしてしまうと本当に全帯域でトランスコードされるんで、時間的に無理なんです。既存コンテンツについては完全にクラウド上の処理のみで実施したことになります。今出てきたようなトランスコーダーの部分で言っても、何種類ももあるんです。Liveで使っているもの、あるいは広告で使っているもの。それぞれに対して、品質のコントロールをしなければならなかったということになります。いうけっこう強引な主観評価検証をしましたが、まとめますと、動いているシステムの中で新しい要素を追加していくのは当然大変ですよね、ということです。次に、自分はこうしたいんだけれども、その結果が正しく導かれるようにするために要目立てをするのもけっこう大変です。テスト項目書を書くか、となると思います。「工数が少ない」「時間も限られている」「何よりも、やっぱり画質を守りたい」という思いがありますので、そこと、削らなければいけないというミッションのせめぎ合い。ここが腕の見せどころだったんじゃないかなという感じはします。あとは、やっぱりディレクターをはじめ、QAチーム、サーバーサイドのエンジニア、コンテンツを運用する人、すべてに対して説明責任がありますので、そういうところからの理解を得ながら、進めなければいけませんでした。QAに関しては、「もっとこうすればいいんじゃないか」という案を逆にQA担当者からいただくことで、次の新しい打ち出しのときのノウハウとして生かせるといったことになります。駆け足でしたけれども、私の発表はこれまでとなります。詳細な情報はネットでググるなりしていただければ、何がしか出てくると思います。この後、懇親会も予定していますので、ぜひ奮ってご参加ください。今日はご参加、どうもありがとうございました。Conferenceに関する記事をまとめています。Conferenceに関する新着記事が公開された際に、通知を受け取ることができます。