とにかく、RaspberryPi3にx264のエンコードを任せて、メインPCは快適に使えないかと思い、やってみました。
材料
RaspberryPi3RASPBIAN STRETCH WITH DESKTOP June 2018
OSのダウンロード、インストールはRaspberryPi3のHPを参照
ffmpegのインストール
raspberryPi3にffmpegをインストールします>sudo apt-get install ffmpeg
Blenderのレンダリング出力を用意
詳しくは書きませんが、まずBlenderのアニメーションを実行し動画ファイルを得ます。0001-0360.mkv
お試しなので24fps360フレームの動画を用意。ってか昨日レンダリングしたアレ。
RaspberryPi3へファイルを送る
WinSCPなどを使い、RaspberryPi3に動画ファイルを転送します。ffmpegを試す
>cd Desktop>ffmpeg -i 0001-0360.mkv
ちゃんと読めてるみたい。コンテナはmkvで中身はすでにh264になっていますが、もうすこし小さくなるかもしれないので、圧縮してみます。
>ffmpeg -i 0001-0360.mkv -c:v libx265 test264.mp4
0001-0360.mkvがソースファイル、test264.mp4が出力です
驚異的な遅さ。これならわざわざRaspPiに送らなくてもメインPCでエンコードしたほうがマシです。
ffmpegのハードウェアエンコードを試す
ソフトウェアエンコードがあまりにも使えないので、ハードウェアエンコードを試してみます。違いはlibx264 が h264_omxに変わったところ。>ffmpeg -i 0001-0360.mkv -c:v h264_omx test264omx.mp4
speed=2.91x
これならまぁ使えそう
エンコードの結果
ファイルサイズが妙に小さいです。これはいやな予感がします
上：libx264 下:h264_omx
これは酷いちゃんと設定してハードウェアエンコードを試す
予想通り酷い結果でしたので、ちゃんと設定してハードウェアエンコードを試します>ffmpeg -i 0001-0360.mkv -c:v h264_omx -b:v 600k test3.mp4
このへんのオプション指定の仕方は正しいのかどうかわかりませんが、crfオプションは無意味でしたのでb:vオプションでビットレートを指定しています。また、libx264で変換した場合のビットレートが600kくらいでしたので、omxでも600kを指定していますが、実際には1000kあたりを指定したほうがいいかもしれません。
結果は御覧の通り。なかなか良いです。
テスト用に使った元動画はこちら
もうすこし長い動画を試す
360フレームでは短すぎるので、3分ほどの動画で試してみます。入力に使った動画は、適当なものがなかったので、アレをソレしています。お察し下さい。>ffmpeg -i org3min.mp4 -map 0:0 -c:v h264_omx -b:v 1000k test3min.mp4
org3min.mp4がおよそ3分の入力動画
音声トラックを除外するためにmapオプションをつけています
なかなかの速度です。画質もいい具合にエンコードできてます。1200kくらいがいいかな？
で、使えるのか？
うちのi7-3770（HTTオフ）で同様のエンコードすると、speed=5xくらいなので、エンコード速度は十分だと思います。エンコード中の消費電力は電源が５V２Aなのでせいぜい１０W程度。おそらくそれ以下です。変換に時間がかかるので電力効率がいいかは分かりませんが、WindowsPCより効率よさそうです。
ただしファイルを転送したりの手間があるので、総合的に見て使えるかどうかは微妙。RaspPi3のネットワークは致命的にしょぼいので。
ただ、多数の動画を同時にエンコードしたい場合とか、特定の用途ではひょっとしたら使えるかも？
まとめると、RaspPi3によるh264エンコードは‥
- 新たにエンコード用PCを用意するより安価
- たぶん変換にかかる電力効率は良い
- 変換速度はそれなり =3.45倍速
- ファイル転送が面倒
でした。
もし興味があったら、RaspPi3を100個くらい積み重ねてh264エンコードクラスタとか作ってみては如何でしょうか。
0 件のコメント:
コメントを投稿