¿Qué velocidad puedo esperar de la codificación hardware-H264?

Tropecé con el Artículo de Wikipedia que la GPU Broadcom tiene soporte de hardware para la codificación H.264 / AVC, no sólo de -coding.

También encontré un artículo donde alguien dio un ejemplo usando ffmpegpara generar archivos de video h264 / mp4. Ok, es una CPU de uso general con una GPU especializada, por lo que no es realmente la sorpresa.

Pero en comparación con una PC de escritorio estándar con una tarjeta gráfica promedio, ¿Raspberry Pi codificará potencialmente H.264 / AVC tal vez incluso más rápido ? Si un usuario de escritorio fue optimizar su ffmpega su Core-i5xxx con US $ 150 ATI / Nvidia tarjeta gráfica ... hace que la combinación ofrece nada en los caminos de "hardware de codificación H.264 de apoyo"? Si no es así, ¿un Raspberry-Pi-ffmpeg especialmente adoptado será aún más rápido? En caso afirmativo, ¿ya hay una comparación de velocidad?

Por el momento, parece que todavía no hay un software estable para codificar video h264 usando el hardware, incluso si se ha anunciado oficialmente que Raspberry Pi admite la codificación de hardware h264. Por lo tanto, no podemos hacer un punto de referencia para comparar el rendimiento con una PC normal .

No sé si alguien está trabajando en el tema, pero un desarrollador de libavparece pesimista sobre la integración de dicho módulo en el libavproyecto existente (vea su respuesta el 2 de diciembre, 09:23).

Estaré encantado de hacer un punto de referencia cuando una biblioteca o software lo permita.

A partir de abril de 2015, GStreamer 1.2 incluido en Raspbian admite la codificación H.264 acelerada por hardware OpenMAX a través de omxh264enc.

He hecho algunas comparaciones comparativas:

1. MacBook Pro (principios de 2011) dual-core i7-2620M 2.7GHz (Sandy Bridge) - 4GB RAM
2. CPU RaspBerry Pi 2 Modelo B 900MHz quad-core ARM Cortex-A7 - 1GB RAM

Archivo de muestra: muestra de los años 60 de la película Alatriste (2006). El archivo original es 1080p y ocupa 30MB. Transcodifiqué el archivo a 720p. Se ignoraron todas las pistas de audio para concentrar el estudio en la transcodificación de video.

Resultados:

En (1), usando Handbrake (códec x264) transcodifiqué con x264-settings veryslow y bitrate promedio 1145kbps (1 paso) que resultó en un archivo de 7.7MB. Perfil alto, nivel 4.0. La codificación tomó 3 minutos y 36 segundos con 4 subprocesos. Carga de CPU total acumulada del freno de mano ~ 380%. La calidad del video fue muy buena. Se pueden observar pequeños artefactos y la pérdida de detalles no es fácilmente observable. Ver todavía a continuación.

En (2), usando GStreamer y omxh264enc (acelerado por hardware) transcodifiqué con una tasa de bits objetivo = 1145000 (1145 kbps), tasa de control = 1 (método de control de tasa de bits variable) que resultó en un archivo de 6.9 MB. La codificación tomó 7min 4s usando 1 hilo. Carga total acumulada de la CPU de gst-launch-1.0 ~ 100%. La calidad del video fue notablemente degradada con artefactos claramente visibles y pérdida de detalles fácilmente observables. Ver todavía a continuación.

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

Cuando se usa GStreamer con x264enc como codificador, la carga total acumulada de la CPU de gst-launch-1.0 es aproximadamente del 380%, lo que respalda el hecho de que omxh264enc realmente usa la GPU. Además, con x264enc en (2), el tiempo supera los 15 minutos.

Conclusión:

Para un tamaño de archivo bastante similar, el tiempo empleado por el codificador de GPU RaspBerry Pi 2 acelerado por hardware fue casi el doble que el del codificador x264 de software en un i7-2620M de doble núcleo. Agregar la transcodificación de audio y la multiplexación podría cerrar un poco esta brecha debido a la CPU en gran parte sin usar en el RaspBerry Pi durante esta prueba. La calidad del video fue claramente superior en el archivo codificado por software. Ver fotos abajo.

Las opciones de configuración disponibles para omxh264enc (expuestas por gst-inspect-1.0) son limitadas en comparación con el codificador x264, pero la experimentación adicional podría proporcionar una mejor calidad.

Anexo:

Instalación de GStreamer y OpenMax desde los repositorios de 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 todavía de video 720p transcodificado usando HandBrake (x264) en un MacBook Pro (abra o descargue la imagen para más detalles):

QuickTime X todavía de video 720p transcodificado usando GStreamer (codificación de hardware a través de OpenMAX) en una Raspberry Pi 2 (abrir o descargar la imagen para más detalles):

Actualizar:

Siguiendo la sugerencia de ecc29 de usar el método de escalado de lanczos, realicé una prueba agregando method=lanczosa videoscale. El proceso de codificación se duplicó en el tiempo, saltando de aproximadamente 7 minutos a 14 minutos y 37 segundos. El resultado es casi igual en calidad que sin método (bilineal predeterminado). De hecho, los defectos provienen principalmente del proceso de codificación en hardware. Son claramente artefactos de compresión.

La GPU en el RPi es bastante robusta. He leído que en términos de codificación puedes codificar 1080p @ 30fps. También es posible codificar múltiples flujos. También se cree que puedes codificar vidos sobre la marcha usando el RPi.

Pero. Las tarjetas gráficas modernas tienen la capacidad de ejecutar toda la codificación en la GPU, que es en lo que una GPU es realmente buena.

Si tuviera que evaluar una opinión personal. Sería que el RPi no sería más rápido que una tarjeta gráfica de especificaciones medias. Pero creo que sería mucho más rápido de lo que piensas. Quizás incluso cerca del 75% de la velocidad.

No pude encontrar una comparación disponible en ningún lado.