Raspberry Pi 4で64ビットハードウェアエンコードを試してみましたが

Raspberry Pi地デジ関連記事


先日作成した64ビット版の地デジ視聴環境ですが。

ハードウェアエンコードの部分は、手を付けずにいました。

しかし、どうやら64ビット版のハードウェアエンコーダが実装されているような?されていないような?

2020年9月現在。そのあたりを確認してみようと思います。


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も同様な問題があるような?


付加情報

VideoCore関連情報

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地デジ関連記事

スポンサーリンク

フォローする

スポンサーリンク