予告していたとおりZenfone3での記事の一つです。動画再生ではバッテリに負荷がかかることがわかっていたので電池持ちがどれくらいかを調べた後に充電状態でテストを行うことでバッテリの充電回数を少なくすることを目的としたためにこんなタイミングになりました。Nexus7(2013)の時とは調べる範囲が変わっているのでまた違った結果となっています。
動画再生の検証条件
手元にある動画で確認するために条件を微妙に限ってチェックしています。チェック条件は以下の通りです。
- 動画コンテナ形式 : mp4 (共通)
- ビデオライン圧縮形式 : H.264およびH.265
- サウンドライン圧縮形式 : AAC 2ch 192kbps (共通)
- プロファイル(H.264) : High4.2、 High5.1、 High10@4.2、 High10@5.1
- プロファイル(H.265) : Main 8bit、 Main 10bit、 Main 12bit
- 画像解像度 : 1280×720 (HD)、 1920×1080 (FullHD)、 2560×1440 (WQHD)
- フレームレート : 23.976fps (24000/1001 fps)、 59.94fps (60000/1001 fps)
今回は映像側のみに注目したテストになっています。なお、ビデオリソースはAviUtlおよび拡張QSV出力/拡張x264出力/拡張x265出力を組み合わせてとある元動画を様々な形式で再エンコードを行いテストをしています。しかしテスト素材を作るためとはいえH.265のエンコードにかなりの時間がかかりました。私のPCではQSVでx265が出力できないのでソフトウェアエンコードになるのですがこれが時間がかかること…。
また、再生環境はハードウェア支援あり(付属のギャラリーにて再生)およびソフトウェア再生(MXPlayerを使用。コーデックもインストール済み)で再生できる/できないおよびコマ落ちがどのくらいかを目視で確認しています。ソフトウェア再生ではすべての形式で再生はできていますがあまりにコマ落ちがひどく再生に堪えない場合は再生できないとしていますので注意してください。また、2560×1440のチェックが一部抜けています。(リソースを作るための時間が…)
で、結果は?
下の表のような状態となりました。
圧縮形式(映像部) | プロファイル | フレームレート | 解像度 | 再生状態(ハードウェア) | 再生状態(ソフトウェア) |
H.264 | High 4.2およびHigh5.1 | 23.976fps | 1280×720 | OK | OK |
1920×1080 | OK | OK | |||
2560×1440 | OK | OK | |||
59.94fps | 1280×720 | OK | OK | ||
1920×1080 | OK | OK | |||
2560×1440 | OK | OK | |||
High10@4.2およびHigh10@5.1 | 23.976fps | 1280×720 | NG | OK | |
1920×1080 | NG | OK | |||
2560×1440 | NG | OK | |||
59.94fps | 1280×720 | NG | OK | ||
1920×1080 | NG | Drop Frame (Level 1) | |||
2560×1440 | Not Checked | Not Checked | |||
H.265 | Main 8bit | 23.976fps | 1280×720 | OK | OK |
1920×1080 | OK | OK | |||
2560×1440 | OK | Drop Frame (Level 1) | |||
59.94fps | 1280×720 | OK | OK | ||
1920×1080 | OK | Drop Frame (Level 1) | |||
2560×1440 | OK | Drop Frame (Level 2) | |||
Main 10bit | 23.976fps | 1280×720 | NG | OK | |
1920×1080 | NG | Drop Frame (Level 2) | |||
2560×1440 | NG | Drop Frame (Level 3) | |||
59.94fps | 1280×720 | NG | Drop Frame (Level 1) | ||
1920×1080 | NG | Drop Frame (Level 2) | |||
2560×1440 | Not Checked | Not Checked | |||
Main 12bit | 23.976fps | 1280×720 | NG | Drop Frame (Level 1) | |
1920×1080 | NG | NG | |||
2560×1440 | NG | NG | |||
59.94fps | 1280×720 | NG | NG | ||
1920×1080 | NG | NG | |||
2560×1440 | Not Checked | Not Checked |
NotCheckedとなっている部分が一部ありますがなんとなく結果は想定できると思います。この表より簡単に状態をまとめると
- ハードウェア再生はH.264の8bitおよびH.265の8bitで利用可能。10bit以上となると利用できない。
- ディスプレイの解像度(Zenfone3だと1920×1080)を超えていても再生が可能となる形式がある。
- ハードウェア再生では高解像度(今回のテストではWQHD)でもコマ落ちすることなく再生可能。
- ソフトウェア再生では特にH.265でビット数が高いものほどコマ落ちが発生しやすくなる。フレームレートが高い動画は特に注意。
となりました。再生でハードウェア支援がないとCPUがフルに動作することとなり使用する電力量がかなり多くなるのでバッテリ持ちも悪くなることからもしZenfone3で動画再生を行う場合はH.264の8bitかH.265の8bitとなるように動画を変換するとよいようです。互換性重視ならH.264、サイズ重視ならH.265でしょうか。また一時的に見るのであればソフトウェア再生でもコーデックがちゃんとなっていればそれなりの速度で再生可能ですのでそれでなんとかすることもできる、というところでしょうか。
H.265がハードウェア支援で再生できるようになったのね
Nexus7の時は確かチェックしていないはずです。まだH.265がそこまで大きく出回っていた時期ではなかったですからね…。H.265が部分的にでもハードウェア支援が利くようになったのであれば保存時にH.265も検討対象にしてもよいのかもしれません。ちなみにチェックのために作った動画の最高解像度(H.265、2560×1440)ですが、私のPCでの再生時だとハードウェア支援がないためソフトウェア再生となってしまい、一部の場面でCPU使用率が100%に達してしまいコマ落ちが発生する羽目に…。それほど非力なCPUではないはずなのですが、そう考えるとハードウェア支援がいかに強力かがよくわかりますね。
結果は端末依存
この結果はあくまでAndroid6.0+Zenfone3での結果です。そのためOSが変わったり端末の能力が変わることによって結果が変化しますので自分の端末でどれくらいできるか?というのは必要であれば動画をエンコードして調べておいた方がよいかと思います。詳細にチェックしなくても端末で再生する可能性がある形式に近いものを一度再生させてみて…は必要になると思います。UPnP経由で動画を再生するというときでもこれを知っておけば再生できないということはなくなるでしょうし、必要であればソフトウェア再生可能なアプリをインストールしておくことでCPUやバッテリが大変なことになりますが完全に再生できないよりまし、という場面に出会うかもしれませんからね。
ピンバック: 全画面背景動画をスマホでも自動再生させる方法を考える。 | yama-log