Quale velocità posso aspettarmi dalla codifica hardware H264?

Mi sono imbattuto sulla Wikipedia-articolo che la Broadcom GPU ha il supporto hardware per la codifica H.264 / AVC, non solo de -coding.

Ho anche trovato un articolo in cui qualcuno ha dato un esempio usando ffmpegper generare un file video h264 / mp4. Ok, è una CPU per tutti gli usi con una GPU specializzata, quindi non è proprio la sorpresa.

Ma rispetto a un PC desktop standard con una scheda grafica media, il Raspberry Pi codificherà potenzialmente H.264 / AVC forse anche più velocemente ? Se un utente desktop dovesse ottimizzare il ffmpegsuo Core-i5xxx con una scheda grafica Ati / Nvidia da $ 150 ... quella combinazione offre qualcosa nei modi del "supporto di codifica hardware H.264"? In caso contrario, un Raspberry-Pi-ffmpeg appositamente adottato sarà ancora più veloce? Se sì, esiste già un confronto di velocità?

Al momento, sembra che non ci siano ancora software stabili per codificare video h264 utilizzando l'hardware, anche se è stato annunciato ufficialmente che Raspberry Pi supporta la codifica hardware h264. Quindi, non possiamo fare un benchmark per confrontare le prestazioni con un normale PC .

Non so se qualcuno sta lavorando sull'argomento, ma uno sviluppatore libavsembra pessimista sull'integrazione di un tale modulo nel libavprogetto esistente (vedi la sua risposta il 2 dicembre, 09:23).

Sarò felice di fare un benchmark quando una libreria o un software lo consentiranno.

Ad aprile 2015 GStreamer 1.2 incluso in Raspbian supporta la codifica H.264 con accelerazione hardware OpenMAX tramite omxh264enc.

Ho fatto alcuni confronti comparativi:

1. MacBook Pro (inizio 2011) dual-core i7-2620M 2,7 GHz (Sandy Bridge) - 4 GB di RAM
2. CPU ARM Cortex-A7 quad-core 900 BHz RaspBerry Pi 2 modello B da 1 GB di RAM

File di esempio: campione degli anni '60 tratto dal film Alatriste (2006). Il file originale è 1080p e richiede 30 MB. Ho transcodificato il file a 720p. Tutte le tracce audio sono state ignorate per concentrare lo studio sulla transcodifica video.

risultati:

Su (1), usando il freno a mano (codec x264) ho transcodificato con veryslow con impostazioni x264 e bitrate medio di 1145 kbps (1 passaggio) che ha prodotto un file di 7,7 MB. Profilo alto, livello 4.0. La codifica ha richiesto 3 minuti e 36 secondi usando 4 thread. Carica totale cumulata della CPU del freno a mano ~ 380%. La qualità del video è stata molto buona. Si possono osservare piccoli artefatti e la perdita di dettagli non è facilmente osservabile. Vedi ancora sotto.

Su (2), usando GStreamer e omxh264enc (accelerazione hardware) ho transcodificato con target-bitrate = 1145000 (1145kbps), control-rate = 1 (metodo di controllo con bitrate variabile) che ha prodotto un file da 6,9 MB. La codifica ha richiesto 7 minuti e 4 secondi usando 1 thread. Carica totale cumulata della CPU di gst-launch-1.0 ~ 100%. La qualità del video è stata notevolmente degradata con artefatti chiaramente visibili e perdita di dettagli facilmente osservabile. Vedi ancora sotto.

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

Quando si utilizza GStreamer con x264enc come encoder, la carica totale cumulata della CPU di gst-launch-1.0 va a circa il 380%, il che supporta il fatto che omxh264enc utilizza effettivamente la GPU. Inoltre, con x264enc in (2), il tempo va oltre i 15 minuti.

Conclusione:

Per una dimensione del file abbastanza simile, il tempo impiegato dall'encoder GPU RaspBerry Pi 2 con accelerazione hardware era quasi il doppio di quello dell'encoder software x264 su un i7-2620M dual core. L'aggiunta di transcodifica audio e multiplexing potrebbe colmare un po 'questa lacuna a causa della CPU ampiamente inutilizzata su RaspBerry Pi durante questo test. La qualità video era chiaramente superiore nel file codificato dal software. Vedi foto qui sotto.

Le opzioni di configurazione disponibili per omxh264enc (esposte da gst-inspect-1.0) sono limitate rispetto all'encoder x264 ma ulteriori sperimentazioni potrebbero fornire una migliore qualità.

allegato:

Installazione di GStreamer e OpenMax dai repository Raspbian:

$ 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 ancora di video 720p transcodificato usando HandBrake (x264) su un MacBook Pro (apri o scarica l'immagine per i dettagli):

QuickTime X ancora di video 720p transcodificato utilizzando GStreamer (codifica hardware tramite OpenMAX) su un Raspberry Pi 2 (apri o scarica l'immagine per i dettagli):

Aggiornare:

Seguendo il suggerimento di ecc29 di usare il metodo di ridimensionamento lanczos, ho eseguito un test aggiungendolo method=lanczosa videoscale. Il processo di codifica è raddoppiato nel tempo, passando da circa 7 minuti a 14 minuti 37 secondi. Il risultato è quasi uguale in termini di qualità a quello senza metodo (default bilineare). In effetti, i difetti derivano principalmente dal processo di codifica dell'hardware. Sono chiaramente artefatti da compressione.

La GPU in RPi è piuttosto robusta. Ho letto che in termini di codifica è possibile codificare 1080p @ 30fps. È anche possibile codificare più flussi. Si ritiene inoltre che si possa codificare vidoes al volo usando l'RPi.

Ma. Le schede grafiche dei giorni nostri hanno la capacità di eseguire l'intera codifica sulla GPU, che è ciò che una GPU è davvero brava.

Se dovessi valutare un'opinione personale. Sarebbe che l'RPi non sarebbe più veloce di una scheda grafica con specifiche medie. Ma penso che sarebbe molto più veloce di quanto pensi. Forse anche vicino al 75% della velocità.

Non sono riuscito a trovare un confronto disponibile ovunque.