少し嬉しいサプライズがあった。
ラズパイでのh264_v4l2m2mを使用したHWエンコードが使えるものになっていたのである。
致命的な問題が有ったのだが、fixされていたようだ。
下手にネット記事だけを頼りにしていたので、気が付かなかった。
kodi v19リリース当初、使用するffmpeg4.4はダメダメだった。
そのときは、条件に関係無く緑色に潰れた動画が生成されるばかりだった。
後に、本家より取得したffmpegで試したものの、特定サイズ（1440*1028）のエンコードが出来なかった。
残念、あともう少しなのに。
ただ、これに関してリサイズすれば正しく生成されるのだが、それだとHWエンコードの優位性が損なわれてしまう。
現在、使用するTVサーバーはラズパイ4。
もしラズパイ3なら、h264_omxを使えるのだが。
先日の事。
普段使用するkodiクライアントのラズパイ3をMatrixの最新に更新した。
ラズパイ3で使用するNexusは何かと問題があるので、今もメインはMatrixである。
そのついでに、ffmpegも入れ直すことにした。
そう言っても、関連モジュールのパッチをあてるのが面倒なので、使っていたソースをビルドし直しただけ。
プラスアルファとしては、omxを用いたHWエンコードを使えるようにオプションを追加した。
とは言っても、クライアントであるラズパイ3を用いてエンコードすることはない。
無用の長物である。
ラズパイ4のTVサーバーから使えればなぁ．．．
そんなふうに思いを巡らせていたのだが、どうにもこうにもならない。
ちなみに、ラズパイ4でOpenMAXは使えない。
現在、TVサーバーにはNexusで使用されているjc-kynesim版ffmpeg5.1.2を入れている。
少し前に、意味なく更新したものだ。
そう言えば、これを用いては一度もエンコードをした事がない。
以前、テストしていたh264_v4l2m2mを用いたスクリプトはEPGStationに置いたままになっているはず。
録り溜めた録画も増えてきているので、試しにフルHDのものをEPGStationからエンコードしてみた。
HWエンコードを用いても、このサイズなら問題ないはず。
エンコード速度は1.x倍程度。
そして、そろそろエンコードが終了する頃に、ハッと気がついた。
録画ソースを確認すると1440*1028．．．やらかした。
四の五の言っても仕方がない。
キャンセル。。。いやいや、念のために確認しよう。
そのときに限って、第六感が働いた。
出来上ったものを確認すると、何故か問題無く再生出来る！
もしかして、pvrアドオン上から間違えて録画ソースを再生したのかも？
念のため、直接mp4ファイルを再生したのだが、やはり問題無い。
いつの間にか問題は解決していたようだ。
そもそも、HWエンコードが使えることが、どれほど喜ばしいことなのか。
EPGStationにあるスクリプトのテンプレートではlibx264が使用されている。
素直に、そのまま使用するればHWエンコードなんて不要だろ？
いやいや、ラズパイをTVサーバーとしている方なら理解して頂けると思う。
ソフトウェアのエンコードが、いかに忌避されているかを、、、
まず、エンコードにCPUパワーが占有されてしまう事。
そして、エンコードに長い時間を要する事。
まさしく、その間はエンコード専用機と化してしまうのである。
ちなみに現在、自身のエンコードの工程はこんな具合である。
1.録画ファイルをPCのSmartRenderで前後CMを削除する。
2.HandBrakeでh264にエンコード。
3.出来上ったmp4ファイルをTVサーバーの録画用HDへ戻す。
更に言えば、これら工程はノートpcからリモードデスクトップで行っているのだ。
HWエンコードさえ使えれば、この苦行から開放されるのである。
例えばpvrアドオンに、そのトリガーさえ与えてやれば、
TV視聴中だろうが、気兼ねなくいつでもポチッとエンコードができる。
この恩恵は少なくないはず。
そんな訳で、HWエンコードが使える今、
pvrアドオンのコンテキストメニューに「エンコード」を実装してみた。
ただ、HWエンコードではlibx264の様な細かいオプションが無い。
そう、痒い所に手が届かないのである；
まぁ、凝りだすときりがないのも事実。
これ位が丁度良いのかもしれない．．．。