¿Qué algoritmo de control de velocidad conserva mejor el movimiento rápido?

Reuní que los siguientes algoritmos de control de velocidad se usan comúnmente al codificar formatos de video modernos como h264, HEVC o VP9.

  • Con un cuantificador constante ( -qpen términos de ffmpeg) todos los fotogramas se codifican con la misma relación de compresión. Cualquier cuadro fijo que se extraiga del video resultante debe tener la misma calidad visual, independientemente de cuán intenso sea el movimiento o cuán compleja sea la escena.
  • Un factor de velocidad constante (el -crfparámetro) aplica más compresión a las partes complejas para, a su vez, dejar las escenas simples relativamente sin comprimir. Por lo tanto, se introducen más artefactos en, por ejemplo, tomas de movimiento rápido, que en la aplicación común son menos perceptibles para el ojo humano, logrando una buena calidad subjetiva mientras se ahorra en el tamaño del archivo.
  • La tercera variante es apuntar a un tamaño de archivo específico con dos pases de tasa de bits variable ( -b). El primer pase recopila datos en cada cuadro, de modo que el segundo pase puede asignar más bits a las partes del video que, de lo contrario, son difíciles de mantener en calidad. Esto efectivamente hace lo contrario de CRF, asignando más calidad a escenas complejas.

Estoy buscando una estrategia para archivar videos en los que las escenas con mucho movimiento son realmente las más importantes, incluso pueden detenerse, ampliarse y analizarse en busca de detalles, mientras que el contenido lento o estático es menos interesante. ¿Hago bien en buscar VBR de dos pasos para lograr la mejor codificación en este sentido?

Si mi comprensión de cualquiera de los métodos anteriores es engañosa en primer lugar, no dude en corregirme. También se agradecen otros consejos para codificar el movimiento con buena calidad. No estoy especialmente seguro de si la tasa de bits variable de dos pases realmente conduce a una distribución más pesada de la tasa de bits hacia escenas rápidas y agradecería que alguien pudiera confirmar esto con alguna documentación.

Respuestas (1)

Aquí está mi comprensión de FFMPEG, hay 4 configuraciones para VQ, y son "codec", "crf", "preset" y "tune". Para el "códec", FFMPEG no funciona bien en VP9; los otros son H.264 y H.265. Para la "melodía", prefiero "película" para H.264 y "grano" para H.265. "crf" y "preset" pueden hacer que el VQ sea excelente, pero hay inconvenientes: tiempo de codificación prolongado y tamaño de archivo grande (tasa de bits)

El "códec" se encarga de la tasa de bits, H.265 tiene un tamaño de archivo más pequeño (tasa de bits) que retiene el mismo nivel de VQ pero un tiempo de transcodificación más largo.

"crf" se encarga de la cuantificación y la tasa de bits, cuanto menor sea el crf, mejor será la calidad del video, pero mayor será el tiempo de transcodificación y mayor el tamaño del archivo.

"preestablecido" se encarga de la tasa de bits, cuanto más lento sea el preajuste, menor será el tamaño del archivo (tasa de bits), pero mayor será el tiempo de transcodificación

Vuelva a su escenario: el video de movimiento rápido, nos preocupamos por el contenido de alta frecuencia. No queremos ver imágenes en bloques; por lo tanto, necesitamos una tasa de bits más alta, pero queremos un tiempo de transcodificación razonable.

Por lo tanto, prefiero el "códec" H.265 y el grano "sintonizado". Luego, debemos modificar el "crf" y el "preajuste" en función de los resultados de SSIM y PSNR. Había hecho algunos experimentos en el flujo de muestra de MainConcept (contenido de 1080p)

  • Predeterminado) códec=h.264 crt=23, preestablecido=medio, la transcodificación tomó 27.9s , tasa de bits= 3118kb/s , SSIM= 0.994413 , PSNR= 48.644
  • Configuración 1) codec=H.265, crt=23, preset=medium, tune=grain, la transcodificación tomó 130s, la mordida 3949kb/s, SSIM=0.99487, PSNR=50.894298
  • Configuración 2) códec=H.265, crt=1, preset=medium, tune=grain, la transcodificación tomó 202.37s, tasa de bits= 60883kb/s , SSIM= 0.999738 , PSNR= 65.497223
  • Configuración 3) códec=H.265, crt=23, preset=slow, tune=grain, la transcodificación tardó 329,36 s, tasa de bits= 4338 kb/s , SSIM= 0,9952 , PSNR= 51,452838

La configuración 3) tiene un mejor rendimiento de VQ con inconvenientes aceptables o puede seguir ajustando "crt" y "preset" para llegar al punto que alcanza su tiempo de transcodificación aceptable y los resultados de la tasa de bits.

¡Buena suerte!

El tiempo no importa: puedo ejecutar todas las codificaciones con -preset veryslow. Aprecio la idea de que -tune grainpodría mejorar las escenas rápidas y experimentaré con eso. Además, me interesaría mucho saber cómo puedo configurar una codificación de tasa de bits variable que distribuya más tasa de bits o marque la calidad en escenas rápidas. Tal vez usted o alguien más pueda dar más detalles sobre esto.
Esos comandos son vbr, Secuencias sin movimiento: sin vectores de movimiento y residuales: tasa de bits baja Secuencias con movimiento: sí, vectores de movimiento y residuales: tasa de bits alta ¿No está seguro de lo que quiere lograr aquí?