ymlでビルドしているffmpegでは h264_omx コーデックが使えない 💯 ffmpegのビルド設定を変更したので h264_omx が使えるようになった ✅ h264_omx用に を書き換えれない 書き換えた -> CH3COOH/docker-mirakurun-epgstation ✅ EPGStation上からh264_omxを使ったエンコード操作ができない (0バイトのファイルができる) ❓ Dockerコンテナにログインするとh264_omxを使ったエンコードはできるがEPGStationからだと失敗してしまう ❓ 両方ともrootユーザーだったもののコンテナにログインするとrootグループ所属だった。EPGStationの録画処理を実行しているのは videoグループだから失敗したのか? 💯 動画データを保存するディレクトリの所有権を pi:pi にしたら h264_omx を使えるようになった ✅ エンコードした動画をNASに転送したい 💯 rsyncを使ってNASへ動画ファイルをコピーできるようにした -> この記事 💯 未アクセス時にはNASとの接続を切るようにした ✅ docker-mirakurun-epgstation の書き換え項目が多いので、この手順書では他人に気軽にオススメできない 💯 元リポジトリをforkしてラズパイ向けに最小限だけ変更した CH3COOH/docker-mirakurun-epgstation を作成した これらの問題は今週末あたりに片付けられたら嬉しい。 関連記事 録画サーバー構築① 先行例の調査と機材の購入 録画サーバー構築② Raspberry Pi 4の設定 録画サーバー構築③ Dockerを利用してMirakurunとEPGStationをインストールする 録画サーバー構築④ ラズパイからNASへファイルを転送する
1 LTSのRaspberry Pi 4 64ビット版になります。 v4l2m2mデバイスが存在するか まずは、v4l2m2mのデバイスが存在するか確認してみます。 /dev/video10というデバイスがあるかどうかですが。 しっかり存在しているようです。ふむふむ。ということは、カーネルドライバは実装されている感じです。(存在しているかどうかと、完成しているかは別問題として v4l2-ctlで確認 次にv4l-utilsをインストールしてみます。 sudo apt install -y v4l-utils v4ls-ctlコマンドで、フォーマットを調べてみます。 v4l2-ctl -d /dev/video10 --list-formats v4l2-ctl -d /dev/video11 --list-formats ・・・H. 264, compressedという文字を確認できます。どうやらvideo11デバイスは、H. 264の圧縮(compress)に対応している感じです。ふむふむ。 なんとなくハードウェア・エンコードが使える感じがしてきたところで。 ffmpegで実際にtsファイルをエンコードしてみました。 エンコード速度比較 実際に5分程度のtsファイルをffmpegでエンコードしてみて、コーデックごとの速度を比較しようと思います。 ソフトウェア・エンコード 64MB程度のtsファイルを作成して、ffmpegでソフトウエア・エンコードしてみます。 オプションは-c:v libx264になります。出力形式はmp4になります。 ffmpeg -i -c:v libx264 -y 4 ビットレート等をオプションで調整していませんので、単純にts→mp4の変換になります。エンコードが完了後。 mp4ファイルが作成されました。問題なく再生できます。 この場合、エンコード中のフレームレートは7. 9fps、スピードは0. 261倍、ロードアベレージは5~8のようです。 ハードウェアエンコードの場合、これらがどの程度変わるか、が問題になります。 OpenMAXエンコード オプション-c:v h264_omxですが、64ビット環境の場合、異常終了してしまいます。 ffmpeg -i -c:v h264_omx -y 4 Ubuntu 20. 04 LTS 64ビット版では、このオプションは使用できない感じです。 V4L2M2Mエンコード V4L2エンコードを試してみたいと思います。 ffmpeg -i -c:v h264_v4l2m2m -y 4 これは・・・ エンコード中のフレームレート60fps程度、スピードは1.
1標準を使用 最新バージョンのffmpegをビルド(ソースコードをコンパイルしてオブジェクトファイルを生成、リンクして実行バイナリを作成)しますが、使用するライブラリはUbuntu 20. 1標準のものを使用しました。 具体的な意味ですが、configureのオプションを既存のUbuntu 20. 1同梱のffmpeg 4. 4に合わせて新しいffmpeg 4. 3. xをビルドすることで、機能的に同じではあるもののバグが少ないffmpegにしましょう、という考え方になります。 新しいライブラリを取り入れれば機能が増えますが、作業が大変になりますので、そこは別の機会に致します。 既存のffmpeg 4. 4のconfigureオプションは下記のようです。 configuration: --prefix=/usr --extra-version=1ubuntu0.
(下記の情報を見ると、64ビット環境ではVideoCore 4も同様な問題があるような? ffmpegの問題でした ※21. 4追記: コメント欄にOさんから情報を頂きました。Pi 3B+でも同じ状況ですが、新しいffmpegを使用することで、正常にハードウェアエンコードできるそうです。詳細はコメント欄を御覧ください。 Pi 4Bについては、ffmpeg 4. 2. 4のコミット(ソースコードの統合)に問題があることが原因で、バージョン4. 3では直っているという情報があるようです。エビデンスはこのあたりです。 Hardware Accelerated Video Encoding on the Raspberry Pi 4 on Ubuntu 20.
6kbits / s dup = 22 drop = 5 speed = 0. 961x ■フルHD(1920×1080) copy(4CPU) Raspberry Pi 4BのCPU(1個)を使った無圧縮の測定結果です。単にファイルに書き込んでいるだけなので、CPUもほどんど使わず、fps=30という結果ですね。ただし、ビットレートは36, 031kbits/sとなり膨大なデータ量となります。 fps=30 CPU=5. 1% $ ffmpeg - ss 5 - f v4l2 - input_format mjpeg - s 1920x1080 - i / dev / video0 - c: v copy - framerate 30 - threads 1 / var / lib / motion / output. mp4 -- - 省略 -- - frame = 1740 fps = 30 q = - 1. 0 Lsize = 245535kB time = 00: 00: 55. 82 bitrate = 36031. 9kbits / s speed = 0. 948x ③4K動画の測定結果 いよいよ本題の4K動画の測定結果です。 ■4K(3840×2160)h264(1CPU) Raspberry Pi 4BのCPU(1個)を使ったh264動画圧縮(ソフトウェアエンコード)の測定結果です。fps=1. 0という結果となり、まったく使い物になりません。 fps=1. 0 CPU=25. 5% $ ffmpeg - ss 5 - f v4l2 - input_format mjpeg - s 3840x2160 - i / dev / video0 - c: v h264 - framerate 30 - threads 1 / var / lib / motion / output. mp4 -- - 省略 -- - frame = 167 fps = 1. 0 q = 29. 0 size = 4608kB time = 00: 00: 04. 16 bitrate = 9059. 6kbits / s dup = 137 drop = 0 speed = 0. 025x ■4K(3840×2160)h264(4CPU) Raspberry Pi 4BのCPU(4個)をフルに使ったh264動画圧縮(ソフトウェアエンコード)の測定結果です。fps=3.
1 64ビット版で動画が緑色になるのはffmpegのバグ」というエビデンスはもう1つあります。次の記事になります。 Hardware Accelerated Video Encoding on the Raspberry Pi 4 on Ubuntu 20.
98倍、ロードアベレージは2~3のようです。 ソフトウェア・エンコードと比較して、フレームレートは8倍、負荷は1/4ですね。つまり、ソフトウェアエンコードの場合、4倍の時間がかかるため、リアルタイム・エンコードは無理ですが、ハードウェアエンコードの場合、半分の時間でエンコードできるため、リアルタイム・エンコードも可能な感じです。ふむふむ。 もしかして、ハードウェア・エンコード使えるかも?と期待しながら、作成されたファイルを見てみますと。 ・・・・ あれ?ファイルサイズが随分小さいようです。 元のTSファイルは640MB。 ソフトウェアエンコードされたファイルは240MB。 ハードウェア・エンコードされたファイルは15MB・・・。 少し悪い予感がしつつ、再生してみます。 全体的に緑色の画面のようです。あれー? このような感じで、Raspberry Pi 4で64ビット版Ubuntu 20.
Raspberry Pi地デジ関連記事 2020年最終版 Raspberry Pi 4をHDDから起動して64ビットEPGStationサーバを作ってみました Raspberry Pi 4でUSB接続HDDから64ビットUbuntu 20. 04. 1を起動してみました Raspberry Pi 4で64ビットMirakurun DVRチューナサーバを動かしてみました Raspberry Pi 4で64ビットEPGStation録画環境を作ってみました ラズパイ地デジ録画環境を安定させるには Raspberry Pi 4 64ビット環境でffmpegをビルドしてハードウェアエンコードしてみました 32ビット検証 ①機材編 ②コマンドライン録画編 ③ストリーミング編 Raspberry Pi 4で地デジ4チャンネル同時録画するには Ubuntu 20. 1添付のffpmegは使ってはダメよ検証 Raspberry Pi 4で64ビットハードウェアエンコードを試してみましたが DLNA配信 Raspberry Pi 4でDLNAサーバを簡単起動するには Podman版 先日作成した64ビット版の地デジ視聴環境ですが。 ハードウェアエンコードの部分は、手を付けずにいました。 しかし、どうやら64ビット版のハードウェアエンコーダが実装されているような?されていないような? 2020年9月現在。そのあたりを確認してみようと思います。 ※21. 1. 5追記:ffmpegを自分でビルドすれば、64ビット環境でもハードウェアエンコードできることを確認しました。 上記の新しい記事でハードウェアエンコードが可能です。以下、Ubuntu 20. 1添付のffmpegではハードウェアエンコードできなかった、という検証記事になります。 64ビット環境ではOpenMAXは使用できない?
6という結果となり、はやりRaspberry Piでは4K動画をh264で扱うのは厳しいです。 fps=3. 6 CPU=84. 5% $ ffmpeg - ss 5 - f v4l2 - input_format mjpeg - s 3840x2160 - i / dev / video0 - c: v h264 - framerate 30 - threads 4 / var / lib / motion / output. mp4 -- - 省略 -- - frame = 785 fps = 3. 6 q = 29. 0 size = 7168kB time = 00: 00: 24. 53 bitrate = 2393. 5kbits / s dup = 749 drop = 0 speed = 0. 114x ■4K(3840×2160)mjpeg(4CPU) Raspberry Pi 4BのCPU(4個)をフルに使ったmjpeg動画圧縮(ソフトウェアエンコード)の測定結果です。fps=15という結果です。CPUを4つフルに使っても、防犯カメラ程度ですね。 fps=15 CPU=100% $ ffmpeg - ss 5 - f v4l2 - input_format mjpeg - s 3840x2160 - i / dev / video0 - c: v mjpeg - framerate 30 - threads 4 / var / lib / motion / output. mp4 -- - 省略 -- - frame = 1097 fps = 15 q = 24. 8 size = 145408kB time = 00: 00: 36. 43 bitrate = 32694. 8kbits / s dup = 1022 drop = 0 speed = 0. 491x ■4K(3840×2160)copy(1CPU) Raspberry Pi 4BのCPU(1個)を使った無圧縮の測定結果です。単にファイルに書き込んでいるだけなので、CPUもほどんど使わず、fps=29という結果ですね。ただし、ビットレートは108, 306kbits/sとなり、48. 6GB/時という膨大なデータ量となります。 fps=29 CPU=4. 0% $ ffmpeg - ss 5 - f v4l2 - input_format mjpeg - s 3840x2160 - i / dev / video0 - c: v copy - framerate 30 - threads 1 / var / lib / motion / output.
rootfsをアンマウントして、F2FSでファイルシステムを作成します。 cd.. sudo umount /mnt/rootfs sudo mkfs. f2fs -f -l rootfs /dev/sdc2 マウントして、先ほど作成したtarballを展開します。 sudo mount /dev/sdc2 /mnt/rootfs cd /mnt/rootfs sudo tar xzvpf ~/ fstabに書かれたファイルシステムをf2fsに変更します。 / のファイルシステムを f2fs に書き換えます。 sudo vi /mnt/rootfs/etc/fstab bootパーティションにある設定ファイルを書き換えます。 rootfstype を f2fs に書き換えます。 sudo vi /mnt/boot/ 最後にアンマウントします。 sudo umount /mnt/boot SDカードを抜き、Raspberry Piに差し、電源を入れ、無事起動されることを確認します。 起動後に df -T などのコマンドで f2fs として認識されていることを確認しておくと良さそうです。 ログの抑制 /etc/ の以下の箇所をコメントにします。 #cron. * /var/log/ #daemon. * -/var/log/ #kern. * -/var/log/ #lpr. * -/var/log/ #mail. * -/var/log/ #user. * -/var/log/ -/var/log/ /var/log/ さらにログローテーションの頻度を低くします。 /etc/logrotate. d にある各設定ファイルの rotate を 1 に、ローテーション頻度である daily や weekly と書かれた箇所を monthly にします。 log2ramの導入 を導入し、 /var/log をRAMディスクに書き込むように変更します。これによってさらにSDカードへの書き込みを減らすことができます。 echo "deb buster main" | sudo tee /etc/apt/ wget -qO - | sudo apt-key add - sudo apt update sudo apt install log2ram /etc/ の USE_RSYNC=true にします。 ここでまた reboot しておくと安心です。 FFmpegでH.