Raspberry Piでテレビ録画環境を作っている人はそこそこいるみたいです。RPi 4Bは非常に高性能になり、様々なことが平行してできるようになりました。ですが、エンコードという重い作業は平行してできるのでしょうか。少し負荷が軽めなハードウェアエンコーダを用いて検証してみました。TS形式のファイルは非常に大きなファイルなので平行してエンコードしてサイズを下げることができれば実用性が大きく向上します。では検証していきます。
目次
測定環境
はじめに測定した環境や、使用した機材は以下のようになっています。
- Raspberry Pi 4B 4GB
- アルミケース（ファンなし）
- Raspbian 32bit
- OSはmicroSDに書き込み
- PX-W3PE4+ライザーカード+電源供給
- 録画データはNASへ(HDDはWD40EZRZ)
- NASは有線接続(1000BASE-T)
- EPGStationを使用
- 室温27.7°C
アルミケースに関しては過度な発熱を防止するために使用しています。あまり写真とかは掲載していないのですが、ケースの性能に関しては以下の記事から確認できるので気になる方はそちらをご覧ください。
このケースは上記の記事にも書いていますが、夏場でも発熱による悪影響を受けていなったので、今回の検証では発熱が結果に影響する可能性は低いと考えれます。
他にはOSをmicroSDに書き込んでいるため中間データがmicroSDに書き込まれるとなるとこの部分が速度的にボトルネックになっている可能性があります。そのせいでCPU使用率が低下する可能性もあるということをあらかじめお断りしておきます。基本的には中間ファイルは録画ファイルと同じパスに生成されているようなので問題はないと私は考えています。
検証方法
今回はEPGStation上からあらかじめ録画してあるTSファイルに対してシェルスクリプトによってエンコードを行うように指示します。さらに今回はffmpegによるエンコードだけではなく、join_logo_scpによるCMカットとロゴ消しを行いエンコードを行います。また今回のエンコード対象となるのは30分のアニメの録画ファイルです。
join_logo_scpのインストール方法についてはARM Linux環境限定ですが以下の記事に書いてあります。事前にこのセットアップを行っていないとこの記事の検証は行えません。
また自動エンコードについてはこちらの記事に設定方法をまとめています。必要であれば参照ください。
実行するシェルスクリプトは以下のようになっています。
#!/bin/bash
export HOME="HOMEDIRECTORY"
jlse -i "$1" -e -t cutcm_logo -o " -c:v h264_omx -vf pullup=jb=54 -preset veryfast -acodec aac -ab 320K -b:v 4M -aspect 16:9 -r 24000/1001 -bsf:a aac_adtstoasc -tune animation" -rffmpegに投げるオプションはアニメ用にチューンしています。特筆することは、フィルタに逆テレシネ変換フィルタのpullupを採用しています。一般に用いられるインターレース解除フィルタのyadifは2コアを使い切るぐらいの重いフィルタ（Raspberry Piにとっては）ですが、pullupはそれよりも極めて高速で1個あの60％ほどしか使っていないようです。また、速さと品質のバランスをとってpresetはveryfastを採用しています。エンコーダにはハードウェアエンコーダh264_omxを採用しています。
また測定するのはCPU温度、使用率、動作周波数の3つの項目について測定し、評価を行います。各データについてはtmchkを利用します。tmchkがどんなことができるかやインストール方法については以下のページに掲載しています。
録画についてはtmchkの実行後、エンコードをスタートし、その直後より地デジ2ch+BS2chの同時録画をスタート、2800秒付近でBSx2と地デジx1の録画がいったん終了し、3330秒付近で計測の終わりまで再び地デジx2ch+BSx2chの同時録画を始めます。これによってドロップの発生がないかなどを計測します。ドロップやエラーの確認についてはEPGStationの機能として提供されているドロップチェックの機能を利用します。
またこの検証の意図としては、HDDやネットワークの負荷によって問題が発生しないかを確認するという意図もあります。
測定結果
測定結果を以下に示します。
CPU使用率に関しては100%に張り付いたりしていません。結構上下しているのは気になりますが、問題はなさそうです。
CPU温度に関しても60度前後を推移しているので問題ないと考えられます。サーマルスロットリングは80度からなので温度に関してもCPU使用率と同様に十分に余裕があることがうかがえます。
CPU動作周波数は1500MHz張り付きかなと思っていたのですが最初の方に一か所下がっているところがありますが、CM解析などでエンコードの重い作業をしていなかったと考えられます。後半の下がっている部分はエンコードが終了して負荷が下がっていることがCPU使用率からうかがえます。実際エンコードが終わったのが4670秒付近だったので計測結果と一致しています。
また録画したデータですが、ドロップは一つもありませんでした。録画データを書き込みながらエンコードを行っても私の設定だとI/O負荷、CPU使用率に関して問題がなかったと言えます。
エンコードは実用的か
どこまで画質で妥協できるかで実用的かは変わってくると思います。h264_omxを用いたハードウェアエンコードの画質で問題ない場合は実用的だと言えますし、ソフトウェアエンコードでないと画質的に満足できない場合はあまりおすすめはできないとです。
また私はアニメをエンコードする設定を用いたため、特にyadifを使っていないため負荷が小さいという面もあるのでyadifを使うともう少し結果は変わってきます。ただし、I/O負荷的には問題はなかったのでCPUがどこまでかつかつにならないで動いてくれるかで変わってきます。CPUリソースを使い切ってしまうと録画データがドロップを起こしてしまう原因にもなるからです。
アニメをエンコードするなら私の設定でも十分なのでこれに関しては実用的でおすすめできます！ただし、画質は自分で確かめたほうがいいですよ。
画質さえ納得できればエンコードしながら録画をしてもドロップがなかったことを踏まえると、エンコードしながらの4ch同時録画は可能だと言えます。
まとめ
join_logo_scpを併用したハードウェアエンコードは設定によっては十分実用的です。そしてエンコードしながら4ch同時録画してもドロップはしなかったため実用的だと言えます。私はこれで自動エンコードの環境を整えていこうと思っています。ドロップもないことが分かったので、安心してエンコードを平行してできます。
みなさんもよいDTVライフを！お読みいただきありがとうございました。