À quelle vitesse puis-je m'attendre de l'encodage matériel H264?

Je suis tombé sur l'article de Wikipédia que le GPU Broadcom a un support matériel pour encodage H.264 / AVC, non seulement de -coding.

J'ai également trouvé un article où quelqu'un a donné un exemple en utilisant ffmpegpour générer des fichiers vidéo h264 / mp4. Ok, c'est un CPU à usage général avec un GPU spécialisé, donc ce n'est pas vraiment la surprise.

Mais par rapport à un PC de bureau standard avec une carte graphique moyenne, le Raspberry Pi encodera-t-il potentiellement H.264 / AVC peut - être encore plus rapidement ? Si un utilisateur de bureau était d'optimiser son ffmpegà son Core-i5xxx avec 150 $ Ati / Nvidia carte graphique ... est - ce que quoi que ce soit offre combinée dans les voies de « support matériel d'encodage H.264 »? Sinon, un Raspberry-Pi-ffmpeg spécialement adopté sera-t-il encore plus rapide? Si oui, existe-t-il déjà une comparaison de vitesse?

Pour le moment, il semble qu'il n'y ait toujours pas de logiciel stable pour coder la vidéo h264 à l'aide du matériel, même s'il a été officiellement annoncé que le Raspberry Pi prend en charge le codage matériel h264. Donc, nous ne pouvons pas faire de benchmark pour comparer les performances à un PC classique .

Je ne sais pas si quelqu'un travaille sur le sujet, mais un développeur de libavsemble pessimiste quant à l'intégration d'un tel module dans le libavprojet existant (voir sa réponse du 2 décembre 09:23).

Je serai heureux de faire un benchmark lorsqu'une bibliothèque ou un logiciel le permettra.

Depuis avril 2015, GStreamer 1.2 inclus dans Raspbian prend en charge le codage H.264 accéléré par le matériel OpenMAX via omxh264enc.

J'ai fait des comparaisons comparant:

1. MacBook Pro (début 2011) double cœur i7-2620M 2,7 GHz (Sandy Bridge) - 4 Go de RAM
2. Processeur RaspBerry Pi 2 modèle B 900 MHz ARM quad-core ARM Cortex-A7 - 1 Go de RAM

Fichier d'exemple: échantillon des années 60 du film Alatriste (2006). Le fichier d'origine est 1080p et prend 30 Mo. J'ai transcodé le fichier en 720p. Toutes les pistes audio ont été ignorées pour concentrer l'étude sur le transcodage vidéo.

Résultats:

Le (1), en utilisant Handbrake (codec x264), j'ai transcodé avec des paramètres x264 très lents et un débit binaire moyen de 1145 kbps (1 passe), ce qui a donné un fichier de 7,7 Mo. Profil Élevé, niveau 4.0. L'encodage a pris 3min 36s en utilisant 4 threads. Charge totale cumulée du processeur du frein à main ~ 380%. La qualité vidéo était très bonne. De petits artefacts ont pu être observés et la perte de détails difficilement observable. Voir encore ci-dessous.

Le (2), en utilisant GStreamer et omxh264enc (accélération matérielle), j'ai transcodé avec un débit binaire cible = 1145000 (1145 kbit / s), un débit de contrôle = 1 (méthode de contrôle du débit binaire variable), ce qui a donné un fichier de 6,9 ​​Mo. L'encodage a pris 7min 4s en utilisant 1 thread. Charge totale cumulée du processeur de gst-launch-1.0 ~ 100%. La qualité vidéo a été sensiblement dégradée avec des artefacts clairement visibles et une perte de détails facilement observable. Voir encore ci-dessous.

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

Lorsque vous utilisez GStreamer avec x264enc comme encodeur, la charge totale cumulée du processeur de gst-launch-1.0 atteint environ 380%, ce qui confirme le fait que omxh264enc utilise réellement le GPU. De plus, avec x264enc dans (2), le temps dépasse 15 minutes.

Conclusion:

Pour une taille de fichier assez similaire, le temps passé par l'encodeur GPU RaspBerry Pi 2 à accélération matérielle était presque le double de celui de l'encodeur logiciel x264 sur un i7-2620M dual core. L'ajout de transcodage audio et de multiplexage pourrait combler un peu cet écart en raison du processeur largement inutilisé sur le RaspBerry Pi pendant ce test. La qualité vidéo était clairement supérieure sur le fichier encodé par logiciel. Voir les photos ci-dessous.

Les options de configuration disponibles pour omxh264enc (exposées par gst-inspect-1.0) sont limitées par rapport à l'encodeur x264, mais une expérimentation supplémentaire pourrait fournir une meilleure qualité.

Annexe:

Installation de GStreamer et d'OpenMax à partir des référentiels 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 encore de vidéo 720p transcodé à l'aide de HandBrake (x264) sur un MacBook Pro (ouvrir ou télécharger l'image pour plus de détails):

QuickTime X encore de la vidéo 720p transcodée en utilisant GStreamer (encodage matériel via OpenMAX) sur un Raspberry Pi 2 (ouvrir ou télécharger l'image pour plus de détails):

Mise à jour:

Suite à la suggestion de ecc29 d'utiliser la méthode mise à l' échelle lanczos I a effectué un test en ajoutant method=lanczosà videoscale. Le processus d'encodage a doublé dans le temps, passant d'environ 7 min à 14 min 37 s. Le résultat est presque égal en qualité à celui sans méthode (bilinéaire par défaut). En effet, les défauts proviennent principalement du processus d'encodage dans le matériel. Ce sont clairement des artefacts de compression.

Le GPU du RPi est assez costaud. J'ai lu qu'en termes d'encodage, vous pouvez encoder 1080p @ 30fps. Le codage de plusieurs flux est également possible. On pense également que vous pouvez encoder des vidéos à la volée à l'aide du RPi.

Mais. Les cartes graphiques modernes ont la capacité d'exécuter tout l'encodage sur le GPU, ce qui est vraiment bon pour un GPU.

Si je devais jauger une opinion personnelle. Ce serait que le RPi ne serait pas plus rapide qu'une carte graphique de spécification moyenne. Mais je pense que ce serait beaucoup plus rapide que vous ne le pensez. Peut-être même près de 75% de la vitesse.

Je n'ai trouvé aucune comparaison disponible nulle part.