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?
fuente
Respuestas:
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 ellibavproyecto 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.
fuente
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:
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.
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:
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=lanczosavideoscale. 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.fuente
gst-launch-1.0 -e videotestsrc pattern=zone-plate kx2=80 ky2=45 num-buffers=1 ! video/x-raw, width=1920, height=1080 ! videoconvert ! videoscale method=lanczos ! video/x-raw, width=1280, height=720 ! avimux ! filesink location=lanczos_1280.avilanczosmétodo de escala.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.
fuente