ハードウェアH264エンコーディングに期待できる速度はどれくらいですか？

Broadcom GPUには、デコーディングだけでなくH.264 / AVC エンコーディングのハードウェアサポートがあるというウィキペディアの記事を見つけました。

また、誰かがffmpegh264 / mp4ビデオファイルの生成に使用する例を挙げた記事も見つけました。わかりました、特殊なGPUを備えた汎用CPUなので、それは驚くことではありません。

しかし、平均的なグラフィックスカードを搭載した標準的なデスクトップPCと比較して、Raspberry PiはH.264 / AVCをさらに高速にエンコードする可能性がありますか？デスクトップユーザーが150ドルのAti / Nvidiaグラフィックカードでffmpeg自分のCore-i5xxxを最適化した場合、その組み合わせは「ハードウェアH.264エンコーディングサポート」の方法で何かを提供しますか？そうでない場合、特別に採用されたRaspberry-Pi-ffmpegはさらに高速になりますか？はいの場合、すでに速度の比較はありますか？

現時点では、Raspberry Piがh264ハードウェアエンコーディングをサポートしていることが公式に発表されていても、ハードウェアを使用してh264ビデオをエンコードする安定したソフトウェアはまだないようです。そのため、パフォーマンスを通常のPCと比較するベンチマークを行うことはできません。

誰かがこのテーマに取り組んでいるかどうかはわかりませんが、開発者はそのlibavようなモジュールを既存のlibavプロジェクトに統合することに悲観的です（12月2日、09：23の彼の回答を参照）。

ライブラリまたはソフトウェアで許可されている場合は、ベンチマークを実行できてうれしいです。

Raspbianに含まれる2015年4月の時点で、GStreamer 1.2はomxh264encによるOpenMAXハードウェアアクセラレーションH.264エンコーディングをサポートしています。

私はいくつかのベンチマークを比較しました：

1. MacBook Pro（Early 2011）デュアルコアi7-2620M 2.7GHz（Sandy Bridge）-4GB RAM
2. RaspBerry Pi 2モデルB 900MHzクアッドコアARM Cortex-A7 CPU-1GB RAM

サンプルファイル：映画Alatriste（2006）の60年代のサンプル。元のファイルは1080pで、30MB必要です。ファイルを720pにトランスコードしました。ビデオトランスコーディングの研究に専念するため、すべてのオーディオトラックは無視されました。

結果：

（1）で、Handbrake（x264コーデック）を使用して、x264設定が非常に遅く、平均ビットレート1145kbps（1パス）でトランスコードした結果、7.7MBのファイルになりました。プロファイル高、レベル4.0。エンコードには4つのスレッドを使用して3分36秒かかりました。ハンドブレーキの合計累積CPUチャージ〜380％。ビデオの品質は非常に良かった。アーチファクトはほとんど観察されず、細部の損失は容易に観察できませんでした。以下を参照してください。

（2）では、GStreamerとomxh264enc（ハードウェアアクセラレーション）を使用して、target-bitrate = 1145000（1145kbps）、control-rate = 1（可変ビットレート制御方式）でトランスコードし、6.9MBのファイルを作成しました。エンコードは、1スレッドを使用して7分4秒かかりました。gst-launch-1.0〜100％の合計累積CPUチャージ。ビデオの品質が著しく低下し、アーティファクトが明確に表示され、簡単に観察できるディテールが失われました。以下を参照してください。

gst-launch-1.0 -v filesrc location=sample-1080p.mp4 ! decodebin ! videoconvert ! \
videoscale ! video/x-raw,width=1280,height=688 ! omxh264enc control-rate=1 \
target-bitrate=1145000 ! h264parse ! mp4mux ! \
filesink location=sample-720p-OMX-1145kbps.mp4

GStreamerをエンコーダーとしてx264encと共に使用すると、gst-launch-1.0の合計CPUチャージは約380％になります。これは、omxh264encが実際にGPUを使用するという事実をサポートします。また、（2）のx264encでは、時間が15分を超えています。

結論：

かなり類似したファイルサイズの場合、ハードウェアアクセラレートされたRaspBerry Pi 2 GPUエンコーダーが費やす時間は、デュアルコアi7-2620M上のソフトウェアx264エンコーダーの時間のほぼ2倍でした。オーディオトランスコーディングと多重化を追加すると、このテスト中にRaspBerry PiのCPUがほとんど使用されないため、このギャップを少し縮めることができます。ビデオ品質は、ソフトウェアでエンコードされたファイルで明らかに優れていました。以下の静止画を参照してください。

omxh264enc（gst-inspect-1.0で公開）で利用可能な構成オプションは、x264エンコーダーと比較して制限されていますが、さらなる実験により品質が向上する可能性があります。

別館：

RaspbianリポジトリからのGStreamerおよびOpenMaxのインストール：

$ apt-get install libgstreamer1.0-0 libgstreamer1.0-0-dbg libgstreamer1.0-dev liborc-0.4-0 liborc-0.4-0-dbg liborc-0.4-dev liborc-0.4-doc gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0 gstreamer1.0-alsa gstreamer1.0-doc gstreamer1.0-omx gstreamer1.0-plugins-bad gstreamer1.0-plugins-bad-dbg gstreamer1.0-plugins-bad-doc gstreamer1.0-plugins-base gstreamer1.0-plugins-base-apps gstreamer1.0-plugins-base-dbg gstreamer1.0-plugins-base-doc gstreamer1.0-plugins-good gstreamer1.0-plugins-good-dbg gstreamer1.0-plugins-good-doc gstreamer1.0-plugins-ugly gstreamer1.0-plugins-ugly-dbg gstreamer1.0-plugins-ugly-doc gstreamer1.0-pulseaudio gstreamer1.0-tools gstreamer1.0-x libgstreamer-plugins-bad1.0-0 libgstreamer-plugins-bad1.0-dev libgstreamer-plugins-base1.0-0 libgstreamer-plugins-base1.0-dev
$ gst-launch-1.0 --version
gst-launch-1.0 version 1.2.0
GStreamer 1.2.0

MacBook ProでHandBrake（x264）を使用してトランスコードされた720pビデオのQuickTime X（詳細は画像を開くかダウンロードしてください）：

Raspberry Pi 2でGStreamer（OpenMAXを介したハードウェアエンコーディング）を使用してトランスコードされた720pビデオのQuickTime X（詳細は画像を開くかダウンロードしてください）：

更新：

以下のecc29の提案、私は追加の試験を行っ法スケーリングランチョスを使用するmethod=lanczosにはvideoscale。エンコードプロセスは時間で2倍になり、約7分から14分37秒にジャンプしました。結果の品質は、メソッドを使用しない場合とほぼ同等です（デフォルトの双線形）。実際、欠陥は主にハードウェアでのエンコード処理に起因しています。それらは明らかに圧縮アーチファクトです。

RPiのGPUはかなり強化されています。エンコードの観点から、1080p @ 30fpsをエンコードできることを読みました。また、複数のストリームのエンコードも可能です。また、RPiを使用してオンザフライでビデオをエンコードできると考えられています。

しかし。現代のグラフィックスカードには、GPUでエンコード全体を実行する機能があります。これはGPUの優れた点です。

個人的な意見を評価しなければならなかった場合。RPiは中スペックのグラフィックスカードよりも高速ではないでしょう。しかし、私はあなたが思うよりもずっと速いだろうと思います。たぶん75％近くの速度です。

どこでも利用可能な比較を見つけることができませんでした。