Welche Geschwindigkeit kann ich von der Hardware-H264-Codierung erwarten?

Ich stolperte den Wikipedia-Artikel über , dass die Broadcom GPU Hardware - Unterstützung für hat kodieren , H.264 / AVC, nicht nur de kodierender.

Ich habe auch einen Artikel gefunden, in dem jemand ein Beispiel ffmpegfür die Erstellung von h264 / mp4-Videodateien gegeben hat. Ok, es ist eine Allzweck-CPU mit einer speziellen GPU, das ist also nicht wirklich die Überraschung.

Aber kann der Raspberry Pi im Vergleich zu einem Standard-Desktop-PC mit einer durchschnittlichen Grafikkarte möglicherweise noch schneller H.264 / AVC codieren ? Wenn ein Desktop-Benutzer ffmpegseinen Core-i5xxx mit einer Ati / Nvidia- Grafikkarte im Wert von 150 US - Dollar optimieren möchte, bietet diese Kombination dann irgendetwas in Bezug auf die Unterstützung von "Hardware-H.264-Codierung"? Wenn nicht, wird ein speziell angepasster Raspberry-Pi-ffmpeg noch schneller sein? Wenn ja, gibt es bereits einen Geschwindigkeitsvergleich?

Momentan scheint es noch keine stabile Software zu geben, um h264-Videos mit der Hardware zu kodieren, auch wenn offiziell angekündigt wurde, dass der Raspberry Pi die h264-Hardware-Kodierung unterstützt. So können wir nicht eine Benchmark tun , um Leistungen zu einem normalen PC zu vergleichen .

Ich weiß nicht, ob jemand an dem Thema arbeitet, aber ein Entwickler von libavscheint pessimistisch , ein solches Modul in das bestehende libavProjekt zu integrieren (siehe seine Antwort vom 2. Dezember, 09:23).

Ich mache gerne ein Benchmark, wenn eine Bibliothek oder Software dies zulässt.

Ab April 2015 unterstützt der in Raspbian enthaltene GStreamer 1.2 OpenMAX-Hardware-beschleunigte H.264-Codierung über omxh264enc.

Ich habe einige Benchmarking-Vergleiche durchgeführt:

1. MacBook Pro (Anfang 2011) Dual-Core i7-2620M 2,7 GHz (Sandy Bridge) - 4 GB RAM
2. RaspBerry Pi 2 Modell B 900 MHz Quad-Core-ARM-Cortex-A7-CPU - 1 GB RAM

Beispieldatei: 60er-Jahre-Beispiel aus dem Film Alatriste (2006). Die Originaldatei ist 1080p und benötigt 30 MB. Ich habe die Datei auf 720p umcodiert. Alle Audiospuren wurden ignoriert, um die Studie auf die Videotranscodierung zu konzentrieren.

Ergebnisse:

Bei (1) mit Handbrake (x264-Codec) habe ich mit x264-Einstellungen sehr langsam und mit einer durchschnittlichen Bitrate von 1145 kbit / s (1 Durchgang) transkodiert, was zu einer Datei mit 7,7 MB führte. Profil hoch, Stufe 4.0. Die Codierung dauerte 3 Minuten 36 Sekunden mit 4 Threads. Gesamte kumulierte CPU-Ladung der Handbremse ~ 380%. Die Videoqualität war sehr gut. Es konnten kleine Artefakte beobachtet werden und Detailverluste sind nicht leicht zu beobachten. Siehe noch unten.

Auf (2) habe ich mit GStreamer und omxh264enc (hardwarebeschleunigt) mit der Ziel-Bitrate = 1145000 (1145 kbps) die Kontrollrate = 1 (Kontrollmethode mit variabler Bitrate) transkodiert, was zu einer Datei von 6,9 MB führte. Die Codierung dauerte 7 Minuten und 4 Sekunden mit 1 Thread. Gesamte kumulierte CPU-Ladung von gst-launch-1.0 ~ 100%. Die Videoqualität verschlechterte sich merklich, da Artefakte deutlich sichtbar und Detailverluste leicht erkennbar waren. Siehe noch unten.

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

Bei Verwendung von GStreamer mit x264enc als Encoder beträgt die kumulierte CPU-Gesamtladung von gst-launch-1.0 ca. 380%, was die Tatsache unterstützt, dass omxh264enc tatsächlich die GPU verwendet. Mit x264enc in (2) geht die Zeit auch über 15 Minuten hinaus.

Fazit:

Bei einer vergleichbaren Dateigröße war der Zeitaufwand für den hardwarebeschleunigten RaspBerry Pi 2-GPU-Encoder fast doppelt so hoch wie der für den Software-x264-Encoder auf einem Dual-Core-i7-2620M. Das Addieren von Audio-Transcodierung und Multiplexing könnte diese Lücke schließen, da bei diesem Test die CPU des RaspBerry Pi größtenteils ungenutzt ist. Die Videoqualität der Software-kodierten Datei war eindeutig überlegen. Siehe Standbilder unten.

Die verfügbaren Konfigurationsoptionen für omxh264enc (verfügbar gemacht von gst-inspect-1.0) sind im Vergleich zum x264-Encoder begrenzt, aber weitere Experimente könnten eine bessere Qualität liefern.

Annektieren:

Installation von GStreamer und OpenMax aus Raspbian-Repositorys:

$ 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

QuickTime X-Standbilder von 720p-Videos, die mit HandBrake (x264) auf einem MacBook Pro transkodiert wurden (Bild öffnen oder herunterladen für alle Details):

QuickTime X-Standbilder von 720p-Videos, die mit GStreamer (Hardware-Codierung über OpenMAX) auf einem Raspberry Pi 2 transkodiert wurden (Bild öffnen oder herunterladen für alle Details):

Aktualisieren:

In Anlehnung an den Vorschlag von ecc29, die Lanczos-Skalierungsmethode zu verwenden, habe ich eine Testaddition method=lanczoszu durchgeführt videoscale. Der Kodierungsprozess hat sich zeitlich verdoppelt und ist von ungefähr 7 Minuten auf 14 Minuten und 37 Sekunden gesprungen. Das Ergebnis ist qualitativ nahezu gleichwertig mit dem ohne Methode (Standard bilinear). Tatsächlich stammen die Defekte hauptsächlich aus dem Kodierungsprozess in der Hardware. Es handelt sich eindeutig um Kompressionsartefakte.

Die GPU im RPi ist ziemlich bullig. Ich habe gelesen, dass Sie in Bezug auf die Codierung 1080p @ 30fps codieren können. Auch das Codieren mehrerer Streams ist möglich. Es wird auch angenommen, dass Sie mit dem RPi Videos on the fly kodieren können.

Aber. Moderne Grafikkarten können die gesamte Codierung auf der GPU ausführen, was eine GPU wirklich gut kann.

Wenn ich eine persönliche Meinung einschätzen müsste. Es wäre so, dass das RPi nicht schneller wäre als eine Grafikkarte mittlerer Spezifikation. Aber ich denke, es wäre viel schneller als Sie denken. Vielleicht sogar fast 75% der Geschwindigkeit.

Ich konnte nirgendwo einen Vergleich finden.