Open2ヶ月前にコメント追加3

(ラズパイ4)ffmpeg #エンコード方式

YouTube

Raspberry Pi

ffmepg

はとりん

ラズパイのハードウエアエンコードの安定性について、ソフトウエアエンコードと比較した際の情報があれば教えて。
(gpt4o先生)

Raspberry Piのハードウェアエンコーディング（特にh264_v4l2m2m）とソフトウェアエンコーディング（libx264）の比較において、それぞれのエンコード方式には以下のような特徴とトレードオフがあります。
ハードウェアエンコーディング (h264_v4l2m2m)

特徴
低CPU負荷: ハードウェアエンコーディングは、Raspberry Piの専用ハードウェアエンコーダー（VideoCore GPU）を利用するため、CPUの使用率が非常に低く抑えられます。これにより、他のプロセスに余裕を持たせることが可能です。
電力効率: CPUをほとんど使わないため、電力消費も抑えられます。
リアルタイム性: 低遅延でリアルタイムのエンコードが可能です。これは、ライブストリーミングや監視カメラの映像など、即時性が重要なアプリケーションに向いています。


欠点
画質の柔軟性: ハードウェアエンコードはソフトウェアエンコードと比べて画質の調整に限界があり、エンコードのプリセット（圧縮効率や画質調整）が少ないため、最高画質を求める場合には不利です。

設定の柔軟性が低い: 例えば、複雑なフィルターや高度なオプションを使う場合、ハードウェアエンコーダーはソフトウェアに比べて対応できない場合があります。
エンコーディングの安定性: ハードウェアエンコードは、特定の状況下で安定性に欠けることがあります。特に、長時間の高負荷運用や複雑なエンコード設定を行う場合、フリーズやクラッシュが発生する可能性があります。h264_v4l2m2mは特に複数のフィルタ操作に弱い場合があります。

ソフトウェアエンコーディング (libx264)

特徴
高画質: libx264 は非常に高品質なエンコーディングが可能で、様々なプリセット（ultrafastからplaceboまで）が提供されており、画質や圧縮率を細かく調整することができます。
高度な設定が可能: libx264 は非常に多くのフィルターやオプションをサポートしており、特殊なエンコード設定や複雑な処理に向いています。ライブストリーミングの際にも柔軟に対応できます。
安定性: ソフトウェアエンコードは、特に長時間の安定したエンコードに向いています。Raspberry Piでも、適切な負荷管理を行えば非常に安定して動作します。


欠点
高CPU負荷: ソフトウェアエンコーディングはすべての処理をCPUで行うため、特に高解像度や高ビットレートのエンコードではCPUに大きな負荷がかかります。Raspberry Piのような低電力デバイスでは、CPUの使用率が高くなり、他のプロセスが遅延する可能性があります。
電力消費: CPUがフル稼働するため、電力消費が増加します。バッテリー駆動や電力制限のある環境では注意が必要です。
ハードウェア vs ソフトウェア エンコードの安定性
長時間の安定性: ソフトウェアエンコーディングは、適切な負荷管理を行えば長時間にわたる安定したエンコードが可能です。ハードウェアエンコーディングは、CPU負荷が低い点で優れていますが、長時間運用や複雑なフィルタ操作が絡むと、安定性がやや劣ることがあります。
複雑な処理: ソフトウェアエンコードは、複数のフィルターやテキストオーバーレイ、ビデオスケーリングなどの複雑な処理に強い一方、ハードウェアエンコーディングはこうした複雑な処理が原因で不安定になる場合があります。
負荷分散: ラズパイでの使用を考慮すると、CPUリソースを節約したい場合にはハードウェアエンコードが向いていますが、負荷がかかっても高品質な映像を安定して配信したい場合にはソフトウェアエンコードが適しています。


結論
安定性重視: 複雑なフィルタ処理や長時間配信の場合は、ソフトウェアエンコードがより安定して動作します。
リソース効率重視: リアルタイム性と低負荷を重視する場合は、ハードウェアエンコーディングが適していますが、複雑な処理を行う場合には安定性がやや劣ることがあります。


用途や環境に応じて、ハードウェアとソフトウェアのどちらを使うかを選ぶと良いでしょう。

はとりん

ストリームは続いているのに、数時間でyoutubeからユーザへの配信が止まる事象への対応。
youtube studioで「ストリームの状態　非常に良い」なのに・・。
とりあえずエンコードをソフトウエアに変更して様子見。

ハードウエアエンコード(fps=30)

-vcodec h264_v4l2m2m -pix_fmt yuv420p -b:v 8192k -maxrate 8192k -minrate 8192k -bufsize 65536k -g 60

ソフトウエアエンコード(fps=15)

-vcodec libx264 -q:v 5 -preset veryfast  -pix_fmt yuv420p -b:v 8192k -maxrate 8192k -minrate 8192k -bufsize 65536k -g 60

ラズパイ5を買えという思し召しですか・・。

はとりん

ハードウエアエンコードに変更後、ストリームについてはドが付く安定。今までの苦労は何だったのか・・。

現在の設定

nohup ffmpeg -use_wallclock_as_timestamps 1 \
       -loglevel info \
       -rtsp_transport tcp -thread_queue_size 40960 \
       -buffer_size 4096k \
       -i rtsp://192.168.XXX.XXX/rtpstream/config1=r \
       -map "0:v" -map "0:a?" \
       -vf "fps=15,scale=1920:1080,setsar=1:1,drawtext=fontfile=/usr/share/fonts/truetype/vlgothic/VL-PGothic-Regular.ttf:textfile='/home/XXX/weather.txt':reload=1000:x=20:y=h-th-20:fontsize=40:fontcolor=white:box=1:boxcolor=black@0.4" \
       -vcodec libx264 -q:v 7 -preset veryfast  -pix_fmt yuv420p -b:v 8192k -maxrate 8192k -minrate 8192k -bufsize 65536k -g 60 \
       -s 1920x1080 \
       -acodec aac -ar 8000 -ac 2 -b:a 128k \
       -af aresample=async=100 -bufsize 192k \
       -max_muxing_queue_size 4096 \
       -f flv rtmp://a.rtmp.youtube.com/live2/XXX \
       > "$LOGFILE" 2>&1 &

ただ、この設定だとやっぱりCPUの閾値超えが1日数回発生。
キーフレームによる数秒に1回発生するボケ(ピントが一瞬合ってボケて・・を繰り返す)も気になる。