motionからの派生でffmpegも少しづつ触り始めて入るのですが、いかんせんよくわからないことだらけ。
知ってる知識は音や映像はかならずコーデックと呼ばれるデータ圧縮/伸張機能があって、処理としては、エンコード、デコードという手順を行うコーデックの事をエンコーダ、デコーダと呼ばれている。基本的にはコーデックは圧縮伸張機能を有しているが、実際には片側だけのものもある。この辺はオープンソースとか特許とか、いろいろしがらみがあるっぽい感じ。
まぁこのぐらいの薄っぺらな知識ぐらいしかない。
とは言え、実際に色々と扱ってはいるので、その範囲内なら癖はわかる。が、最近？かな？のh264とかh265の実情はあまりよくわからないまま、ちょっと触った感じだと、h265のエンコードって少し頑張ればリアルタイムでも使えるかも？と勘違いするぐらいしかmotionで使てみたぐらいです。
h264はDVDとかで見られる感じの基本的な感じ方はjpegっぽい感じが強い印象。データ量が足りなくなると途端ににじみやブロックノイズが激しくなる。
h265はごく短時間(数秒から数十秒)の動画の場合でもそれなりに圧縮率が高いのですが、動画時間が長くなればなるほど前処理に時間がかかり書き込み始めるまで時間がかかるように。さらに、ソフトウェアだと書き出しもかなり遅いです。試しにタイムラプスの雲動画の半分ぐらいの長さの物(１半分ぐらい？)をraspberry pi 3bでlibx265を使ってmpgから変換してみましたが、 １時間半ほどかかったうえ、後から温度グラフ見たこともない温度になってました…ファンついてるヒートシンクだけど、回してないのでｗ
ただ、圧縮がかなり効いていてmpgの単体のソースが107MBぐらいのものが5.6MBぐらいに…パラメータは-q 20ぐらいであとはそのまま。まぁ白いモヤモヤがモヤモヤしてるだけの動画で時間軸で圧縮が行われるとかなり圧縮できそうではありますが。ちなみにh264_v4l2m2mやh264_omxで圧縮すると、何をやっても固定ビットレートになってしまうようで参考になりませんが、libx264で同様のパラメータで出来上がったものは70MB程度と、なりました。圧縮時間はソフトウェアなので、1280x960のサイズの動画で10分程度かかってる感じでした。（グラフを見ると13時に大きな山がありますがこれがlibx265で処理している山で、70度まで上がってスロットリングが発生している気がします。その手前の山はlibx264で処理した状態だと思います。）
raspberry piの処理速度を考えると、motionで扱う場合、画像サイズは640x480程度で限界を超えていてフレームレートを落とす必要があったりします。ただ監視用途ではそこまでFPSが必要と言うわけではないので、あとは用途によってバランスを考える感じでしょうか。
4bではメモリーも増えて処理速度も上がってはいるのですが、その分排熱もかなり高く、単独で放置するのはちょっと気が引ける感じです。室内温度が上がる部屋だとちょっと危ない感じにはなりますが、その点3bplusぐらいまでならなんとか大丈夫かな？
で、結局こんなことを何でやったのかと言うと、raspberry piのハードウェアエンコーダでもうすこし綺麗でファイルサイズも小さくならないかな？と期待してみたのですが、先にも書きましたが、どうもハードウェアエンコードは固定ビットレートしか対応していないようで、どうも期待通りにパラメータが機能してくれませんでした。色々と見ると -passで2パスにするという手が使えるらしいのですが、手持ちの環境ではエラーではじかれてしまいました。
監視用に使っているのは640x480なのでもしかしたらh265でも行けそうな気はする。しかし、タイムラプスのファイルサイズを小さくするためにボード温度が危険域に入ってしまうのはとても危険と判断。昨日今日はたまたま涼しい感じになっているからこれで済んでいるが…
ちなみに、raspberry pi でh265のハードウェアエンコードは実装されていないようです。デコードはできそうな気がする。
youtubeにアップすると漏れなくブロックノイズが激しい…アップ前にもうちょっと何かしてあげないとだめなのかな？
0 件のコメント:
コメントを投稿