Raspberry Pi地デジ関連記事
- 2020年最終版
- 32ビット検証
- Ubuntu 20.04.1添付のffpmegは使ってはダメよ検証
- Raspberry Pi 4で64ビットハードウェアエンコードを試してみましたが
- DLNA配信
ハードウェアエンコードの部分は、手を付けずにいました。
しかし、どうやら64ビット版のハードウェアエンコーダが実装されているような?されていないような?
2020年9月現在。そのあたりを確認してみようと思います。
※21.1.5追記:ffmpegを自分でビルドすれば、64ビット環境でもハードウェアエンコードできることを確認しました。
上記の新しい記事でハードウェアエンコードが可能です。以下、Ubuntu 20.04.1添付のffmpegではハードウェアエンコードできなかった、という検証記事になります。
目次
64ビット環境ではOpenMAXは使用できない?
たとえば32ビット版のRaspbianでは、h264_omxというオプションで、OpenMAXのハードウェアエンコーダが使用できました。
32ビット環境では問題なく使用できましたが、64ビット環境で実行すると。このようなエラーが表示されて、ffmpegが異常終了してしまいます。libOMX_Core.so、libOmxCore.soが無いよエラーが表示されています。
該当の共有ライブラリが入っていると思われる、libomxil-bellagio-bin, libomxil-bellagio0をインストールしてみましたが、エラーは解消されませんでした。
というわけで、別の実装を探してみます。
64ビット版V4L2 M2Mの実装状況を調べてみる
Raspberry Pi 4のハードウェア・エンコーダについての情報は、ずばり下記にわかりやすくまとめられていました。
こちらの情報をもとに、ハードウェア・エンコードが可能かどうか確認してみようと思います。
使用するRaspberry PiとOS
Raspberry Pi 4を使用しました。GPUはVideoCore VIになります。
確認対象のOSは、先日録画環境の構築に使用した、Ubuntu 20.04.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 test.ts -c:v libx264 -y test_libx264.mp4
ビットレート等をオプションで調整していませんので、単純にts→mp4の変換になります。エンコードが完了後。 mp4ファイルが作成されました。問題なく再生できます。 この場合、エンコード中のフレームレートは7.9fps、スピードは0.261倍、ロードアベレージは5~8のようです。
ハードウェアエンコードの場合、これらがどの程度変わるか、が問題になります。
OpenMAXエンコード
オプション-c:v h264_omxですが、64ビット環境の場合、異常終了してしまいます。
ffmpeg -i test.ts -c:v h264_omx -y test_omx.mp4
Ubuntu 20.04 LTS 64ビット版では、このオプションは使用できない感じです。
V4L2M2Mエンコード
V4L2エンコードを試してみたいと思います。
ffmpeg -i test.ts -c:v h264_v4l2m2m -y test_v4l2m2m.mp4
これは・・・
エンコード中のフレームレート60fps程度、スピードは1.98倍、ロードアベレージは2~3のようです。
ソフトウェア・エンコードと比較して、フレームレートは8倍、負荷は1/4ですね。つまり、ソフトウェアエンコードの場合、4倍の時間がかかるため、リアルタイム・エンコードは無理ですが、ハードウェアエンコードの場合、半分の時間でエンコードできるため、リアルタイム・エンコードも可能な感じです。ふむふむ。
もしかして、ハードウェア・エンコード使えるかも?と期待しながら、作成されたファイルを見てみますと。・・・・
あれ?ファイルサイズが随分小さいようです。
元のTSファイルは640MB。
ソフトウェアエンコードされたファイルは240MB。
ハードウェア・エンコードされたファイルは15MB・・・。
少し悪い予感がしつつ、再生してみます。全体的に緑色の画面のようです。あれー?
このような感じで、Raspberry Pi 4で64ビット版Ubuntu 20.04.1 LTSを動かして。
V4L2M2Mのハードウェア・エンコード機能を使ってみました。
デバイス/dev/video10, /dev/video11は存在していますが。
ffmpegで実際にエンコードしてみると、いまのところ微妙な感じです。
ちなみに、v4l2m2mの他のオプションとして
- -c:v h263_v4l2m2m
- -c:v hevc_v4l2m2m
- -c:v mpeg4_v4l2m2m
- -c:v vc1_v4l2m2m
- -c:v vp8_v4l2m2m
- -c:v vp9_v4l2m2m
も存在するようですが、Raspberry Pi 4でハードウェア・アクセラレーションが実装されているコーデックはh264のみのようです。
もしかして、色空間の変換の問題なのかと一瞬考えたのですが、ソフトウェア・エンコーダは問題なく動いていますので、やはりドライバの問題な感じもします(私の勝手な推測です
64ビット環境はまだまだ発展途上。Raspberry Pi 4のハードウェア・エンコードは時期尚早ですが、tsファイルの保存は安定して動作しておりますので。もう少し動向を見させて頂きながら、いまのところソフトウェア・エンコードを使用するほうが良いかもしれませんね。
ちなみに、Raspberry Pi 3はVideoCore 4を搭載していて、Video Core VIのPi 4と状況が違うようです。こちらでハードウェアエンコードを試したほうが現実的かもしれません?(下記の情報を見ると、64ビット環境ではVideoCore 4も同様な問題があるような?
ffmpegの問題でした
※21.1.4追記:
コメント欄にOさんから情報を頂きました。Pi 3B+でも同じ状況ですが、新しいffmpegを使用することで、正常にハードウェアエンコードできるそうです。詳細はコメント欄を御覧ください。
Pi 4Bについては、ffmpeg 4.2.4のコミット(ソースコードの統合)に問題があることが原因で、バージョン4.3では直っているという情報があるようです。エビデンスはこのあたりです。
※21.1.5追記:ffmpegを自分でビルドすれば、64ビット環境でもハードウェアエンコードできることを確認しました。
ffmpegの問題で結論が出た感じです。(私の中で
というわけで、ffmpegを入れ直してハードウェアエンコードしましょう。
付加情報
VideoCore関連情報
- BCM2711 – Raspberry Pi Documentation
- VideoCore VIは32ビット・ハードウェアなのですね
- BCM2711 ARM Peripherals
- Documentation for VC6 – Raspberry Pi Forums
- Pi 4 – full specification of VideoCore 6 – Raspberry Pi Forums
- OMX H.265-HEVC support · Issue #1168 · raspberrypi-firmware · GitHub
- H265はサポートされないようです
- Support arm64 compilation · Issue #314 · raspberrypi-userland · GitHub
- こちらを拝見すると、64ビット環境ではPi 3も同様なのでしょうか
- How to correctly set up v4l2 (m2m) under 64-bit kernel – 64-bit userland- – Raspberry Pi Forums
- ffmpegではなく、GStreamer?
GStreamerでエンコードしてみても微妙?
# gstreamer1.0インストール
list=$(apt-cache --names-only search ^gstreamer1.0-* | awk '{ print $1 }' | grep gstreamer1.0-plugins)
sudo apt install -y gstreamer1.0-tools $list gstreamer1.0-omx-bellagio-config gstreamer1.0-omx-generic gstreamer1.0-omx-generic-config libomxil-bellagio0 libomxil-bellagio-bin libomxil-bellagio-dev libomxil-bellagio0-components-base gstreamer1.0-libav
# エンコードしてみても無反応?
gst-launch-1.0 -v filesrc location=test.ts ! progressreport ! \
tsdemux ! mpegvideoparse ! avdec_mpeg2video ! videoconvert ! \
v4l2h264enc output-io-mode=dmabuf-import ! h264parse ! mp4mux ! filesink location=test_gstreamer.mp4
Raspberry Pi地デジ関連記事
- 2020年最終版
- 32ビット検証
- Ubuntu 20.04.1添付のffpmegは使ってはダメよ検証
- Raspberry Pi 4で64ビットハードウェアエンコードを試してみましたが
- DLNA配信
コメント
コメント失礼します。
海外のフォーラムを見ていたところaptでインストールできるffmpeg4.2.xだとh264_v4l2m2mでエンコードした動画が緑色になるバグがあるそうです。
ffmpeg公式サイトよりarm64用のffmpeg4.3.xをダウンロードしてh264_v4l2m2mエンコードした所正常に再生できることが確認できました。(Raspberry Pi3B+で確認)
Oさん はじめまして。
コメント頂きありがとうございます。
64ビットのハードウェアエンコードにつきまして、情報を頂き、誠にありがとうございます。
ffmpegを入れ替えることで、h264_v4l2m2mエンコードができたというお話で、大変素晴らしいです!
具体的には、海外フォーラムから情報を得たり、ご自身でffmpegを入れ替えて試されたり、具体的・現実的な行動から、Oさんが素晴らしい技能をお持ちだと窺い知れます。
Pi3B+でご確認されたということですが、Oさんもお考えかと思いますが、Pi4Bでも同じ状況かと思います。
理由ですが
Hardware Accelerated Video Encoding on the Raspberry Pi 4 on Ubuntu 20.04 64-bit
このあたりに、Pi 4でもffmpeg入れ替えで直るという状況が報告されているようですね。
Oさんに背中を押して頂いた感じがしますので、なにかffmpegを簡単に入れ替えられる方法を探してみて、Pi 4でも確認してみようと思います。
(普通に入れ替えると独自性が無いものですから