MPlayerのCPU使用率~動画再生支援と早見再生~
執筆日時:2014/06/24
はじめに
近年、動画の再生をコンピュータで行う割合が高まっている。コンピュータの性能の向上に伴い、個人用のものでもDVDやBDの映像を再生することが可能であり、またインターネットからも多数の動画をダウンロードしたり、あるいはストリーミングによって再生したりすることができる。一方、映像の高解像度化や高圧縮化により、ローエンドのマシンでは現在でもCPUのみによる映像のデコードが十分に行えない場合がある。そのため、GPUを使った動画再生支援により、映像のデコードをGPUに任せることで、CPUへの負荷を軽減する技術が一般的になっている。Linuxにおいても、対応するハードウェアにおいて、GPUによる動画再生支援を利用することが可能であり、実際様々なレポートがなされている。しかしながら、動画再生支援を利用することで、動画の再生時にどの程度CPU負荷が軽減するかについては、「CPU負荷が30%ぐらいだったのが5%ぐらいになった」といった曖昧なレポートが主であり、連続する動画再生状況においてCPUの負荷がどのように変動するのか詳細に報告したものは少ない。
そこで今回は、Linux環境下においてプレイヤーにはMPlayerを用い、動画再生支援を利用した場合としなかった場合とで、動画を再生したときのCPU使用率の変動を、動画の尺全体に渡って調べることとした。また筆者は再生速度を上げて動画を観る機会が多いため、音声ありの早見再生を行ったときのCPU使用率についても同時に調べた。
環境
Hardware: [HP Pavilion dm1] AMD E1-1200 APU (1.4GHz Dual-core + Radeon HD 7310)
OS: Ubuntu 14.04 LTS 64bit, Kernel 3.13.0-24-generic
Software: MPlayer 1.1-4.8
詳細は省くが、今回使用したHP Pavilion dm1はメモリを8GBに増強、ストレージはSSDにしてある。
動画再生支援にはVDPAU方式を用い、グラフィックドライバはオープンなものを使用している。動画再生支援を導入する方法については、
自由なソフトウェアのグラフィックドライバ使用時の動画再生支援について(AMDとNVIDIA向け・Ubuntu 14.04時点) - 試験運用中なLinux備忘録 (外部サイト)
を参照して欲しい。基本的には"mesa-vdpau-drivers"をインストール、/etc/environmentに環境変数を記述、mplayerにオプション追加、で行える。上手く行かない場合には、何らかの拍子にプロプライエタリなグラフィックドライバを導入している可能性があるので確認した方がいい。
材料
調査のため使用した動画は以下の4つである。Music Videoとして(1)と(2)を、Animationとして(3)と(4)を用意した。
(1) fhana「tiny lamp」(TVアニメ「ぎんぎつね」OP主題歌)Music Video (5:36)
video:1280x720px H264 24fps 2880Kb/s, audio:AAC 2ch 191Kb/s 44.1KHz
http://youtu.be/ZZ2IkhhXAEo
以下、"tiny lamp"
(2) fhana「ケセラセラ」(TVアニメ「有頂天家族」ED主題歌)Music Video (4:48)
video:1920x1080px H264 24fps 2660Kb/s, audio:AAC 2ch 191Kb/s 44.1KHz
http://youtu.be/ZZ2IkhhXAEo
以下、"ケセラセラ"
(3) 『ANISAVA(アニサバ)』 第4話 (5:05)
video:1280x720px H264 30fps 1199Kb/s, audio:AAC 2ch 191Kb/s 44.1KHz
以下、"ANISAVA"
(4) GO!GO!575 #01「この街全部、抱きしめて。」 (3:30)
video:640x360px H264 24fps 707Kb/s, audio:AAC 2ch 125Kb/s 48KHz
http://www.nicovideo.jp/watch/1389290371
以下、"GO!GO!575"
方法
mplayerを用いた再生には以下のコマンドとオプションを使用した。なお、今回使用した動画はすべてffh264vdpauのコーデックで再生可能である。
A. default (支援無)
# mplayer [file]
B. default130 (支援無、再生速度1.3倍)
# mplayer -speed 1.3 -af scaletempo [file]
C. vdpau (支援有)
# mplayer -vo vdpau -vc ffh264vdpau [file]
D. vdpau130 (支援有、再生速度1.3倍)
# mplayer -vo vdpau -vc ffh264vdpau -speed 1.3 -af scaletempo [file]
CPU使用率の測定は、再生開始前に
# top | grep "mplayer" > [logfile]
を別のターミナルで実行、再生終了後に
# killall top
とすることで、行った。今回の環境においてはtopコマンドのデフォルト更新間隔は3sなので、3秒毎にmplayerのCPU使用率が記録される。同時にmplayerのプロセスを複数立ちあげたりしていなければ、こんな原始的な方法でもCPU使用率の変動を記録することができる。
結果1 (Music Video)
・Figure 1
("tiny lamp", 5:36, video:1280x720px H264 24fps 2880Kb/s, audio:AAC 2ch 191Kb/s 44.1KHz)
default: 67.67±0.79 S.E. (79.6)
vdpau: 6.37±0.08 S.E. (14.2)
映像出力をvdpauにした際、defaultと比較して明らかにCPUの使用率が下がっていることが分かる。
・Figure 2
("ケセラセラ", 4:58, video:1920x1080px H264 24fps 2660Kb/s, audio:AAC 2ch 191Kb/s 44.1KHz)
default: 79.77±0.56 S.E. (%)
vdpau: 6.62±0.14 S.E. (%)
vdpau130: 12.69±0.14 S.E. (%)
defaultのCPUデコードでは映像処理が追いつかず、音声と映像のずれも広がったため、defaultではvdpauより計測時間が伸びている。vdpauでは1.3倍速も計測したが、vdpauと比較して2倍程度のCPU使用率となっていた。
結果2 (Animation)
・Figure 3
("ANISAVA", 5:05, video:1280x720px H264 30fps 1199Kb/s, audio:AAC 2ch 191Kb/s 44.1KHz)
default: 48.32±0.87 S.E. (76.7)
default130: 63.74±0.70 S.E. (76.6)
vdpau: 7.00±0.09 S.E. (15.9)
vdpau130: 13.37±0.05 S.E. (16.2)
こちらはdefault130も計測したが、多少コマ落ちや音声と映像のズレが目立った。defaultやdefault130でCPU使用率の変動が大きいのと比較すると、動画再生支援有の方では再生開始直後を除き、非常に変動が少ない様子が見てとれる。
・Figure 4
("GO!GO!575", 3:30, video:640x360px H264 24fps 707Kb/s, audio:AAC 2ch 125Kb/s 48KHz)
default: 22.04±0.73 S.E. (30.0)
default130: 32.23±0.99 S.E. (50.3)
vdpau: 6.03±0.15 S.E. (15.9)
vdpau130: 12.74±0.08 S.E. (16.6)
こちらはdefault130でもコマ落ちやズレは目立たなかった。このグラフでは、defaultとdefault130の間でCPU使用率の変動パターンが共通であることが確認できる (つまり、映像のなかで処理負荷が高まる場所があるということ)。
まとめ
1. 動画再生支援は確かに効いている。図を見れば明らかなので改めて数値を書いたりはしない。
2. vdpauでの平均CPU負荷率は、いずれの動画でも6~7%の間に収まっており、defaultでの負荷率が20~80%と動画間で大きく異なるのに比べると明らかにバラツキが小さい。これは、映像の処理をほとんど全てGPUに託せていることを示していると考えられる。
3. 早見再生をするとCPU負荷は高まる。当然といえば当然 (-af scaletempoをしているため、音声の処理にもそれなりの負荷が予想される)。
4. 動画再生支援を用いたときのCPU使用率は安定しており、もっとも高い値が記録されるのは決まって再生開始直後である。一方、動画再生支援無の場合は再生中常に負荷が変動している。
CPU負荷の絶対値や、再生したときのコマ落ち状況などから考えると、E1-1200の処理能力ではMPlayerにおいてCPUだけで720pもしくは1080pのh264動画を再生するのは厳しく、動画再生支援の利用は必須と言える。
今回の結果からは消費電力について論じることができないため、"GO!GO!575"のようにCPUによるデコードでも問題なく早見再生できる動画については、動画再生支援を使用するのがbetterなのか判断できない。今後の追加調査が期待される。