Velocidad de fotogramas de trabajo mínima para el códec H264

Al hacer un video a partir de archivos de imágenes individuales, mientras que cada archivo de imagen debe estar visible durante aproximadamente un segundo, tiene sentido codificar un video con una velocidad de cuadro extremadamente baja, como 1 cuadro por segundo. Para este tipo de aplicación, cada velocidad de cuadro mayor que esta sería un desperdicio de recursos.

Me pregunto si el códec H264 (o cualquier implementación específica, como x264) en sí tiene algún límite inferior para la velocidad de fotogramas por debajo del cual se trata de problemas técnicos o algún tipo de inestabilidades. En caso de que no haya problemas con la codificación, ¿podemos esperar que los reproductores de video manejen adecuadamente una velocidad de fotogramas tan inusual?

¡Gracias por compartir tu experiencia!

Estoy con AJ A menos que conozca las características de cada jugador que pueda ver esto, no sería prudente confiar en una pequeña muestra de resultados de la prueba. El uso de una velocidad de cuadro estándar como 24 fps con un intervalo de fotogramas clave de 24 cuadros le dará esencialmente lo mismo sin comprometer la compatibilidad. Los cuadros intermedios serán mínimamente pequeños porque no habrá cambios detectables para codificar.

No estoy seguro de cómo se comportará a velocidades de cuadro muy bajas, pero vale la pena señalar que esto también limitaría sus opciones sobre cómo y cuándo podría cambiar los cuadros, ya que tendrían que seguir los ciclos del reloj. Lo que es más probable que funcione en este caso es un intervalo de fotogramas clave largo. La mayoría de los cuadros en una compresión como H.264 solo almacenan los cambios del cuadro anterior. En el caso de una imagen fija, las relaciones de compresión serán enormes porque se produce muy poco (no) cambio entre fotogramas. No estoy seguro de que realmente obtenga un ahorro suficiente al reducir la velocidad de cuadros para que valga la pena perder el control sobre cuándo puede hacer un cambio en el marco.

La mejor opción sería probarlo con sus medios y ver los resultados. La compresión depende mucho del contenido y la mejor calidad y compresión para un clip en particular dependerá mucho de la naturaleza de ese clip, por lo que la prueba sigue siendo la mejor manera de probarlo.

He jugado a convertir un montón de fotos fijas en una presentación de diapositivas h.264, principalmente para comparar la eficiencia de compresión de JPG frente a h.264. Tengo algunas respuestas útiles acerca de las implicaciones técnicas de este desde x264 desarrolladores en doom9. por ejemplo, forzar a x264 a no usar cuadros B para esto, porque las imágenes no muy relacionadas necesitarán muchos macrobloques I, y codificarlos en cuadros B es más costoso.

El comportamiento del reproductor de software con video de baja fps no era ideal, en el pasado. Creo que un jugador mayor solo verificó la entrada del teclado cuando mostraba un cuadro. Así que hubo un retraso entre la entrada del usuario y la respuesta del jugador. mplayer2 y mpv no tienen este problema. Además, los jugadores que solo pueden buscar fotogramas clave buscarán en bloques realmente grandes (¡2 minutos más o menos!) Si no reducen el intervalo de fotogramas clave. x264 no insertará IDR (límites GOP) en todo el lugar si las imágenes están algo relacionadas entre sí.

Uso x264 -tune stillimage. Se manivelas de las optimizaciones psy , debido a la estabilidad temporal no es un problema para este caso de uso. Resultados de búsqueda adicionales: de google .

Estoy de acuerdo con otras sugerencias para tener algunos fotogramas duplicados, para aumentar el FPS hasta al menos 5 o algo así, en caso de malos jugadores. Sin embargo, los teléfonos inteligentes / tabletas no deberían tener problemas para reproducir video FPS variable, ya que generalmente graban de esa manera cuando los niveles de luz caen. Dado que los videos de FPS variable de los teléfonos ya están disponibles, se debe esperar el soporte del reproductor de hardware para ellos. No esperaría problemas, pero tampoco me sorprendería si hubiera al menos algunos reproductores de hardware antiguos que no lo manejen bien.

Un marco de todos los macrobloques "omitidos" solo toma alrededor de 20bytes a 1080p, IIRC. Sin embargo, una razón por la que no me gustan los cuadros duplicados es que interfiere con un solo paso para recorrer las imágenes manualmente.

Sin embargo, hay una desventaja de compresión para duplicar cuadros : si hay mucha redundancia entre las diferentes imágenes (es decir, sigue siendo un video, no una presentación de diapositivas), el relleno con imágenes idénticas dificultará que el codificador encuentre y explote eso.

Dependiendo de la configuración de codificación, el codificador solo mantendrá cierto número de fotogramas antiguos como posibles referencias para nuevos fotogramas, y solo podrá buscar dentro de un GOP (por ejemplo, 250 fotogramas predeterminados para x264). Si todos esos candidatos son la misma imagen, eso no le da múltiples opciones para encontrar una mejor referencia para cada bloque.

Por ejemplo, después de que un objeto en primer plano se mueva delante de algún detalle de fondo, el codificador puede guardar bits haciendo referencia a cómo se veía en un marco anterior antes de que se oscureciera. h.264 puede elegir marcos de referencia por bloque. Este es un efecto relativamente pequeño; Los buenos codificadores h.264 funcionan bien con solo 1 fotograma de referencia, pero todavía es algo dañino para la eficiencia de compresión y una pérdida de energía / duración de la batería / tiempo de CPU en el lado de la descompresión para copiar la memoria alrededor de la decodificación y la visualización de fotogramas adicionales.

La recuperación de VFR después de un NLE obliga a todos sus clips a una velocidad de fotogramas alta:

FFmpeg tiene un mpdecimatefiltro que elimina cuadros similares. Puede establecer límites sobre la cantidad de cuadros en una fila que puede soltar. Con un estrecho umbral de similitud, debe hacer que solo elimine duplicados reales.

por ejemplo, ffmpeg -i input.mp4 -vf mpdecimate=max=9:hi=400 -c:a copy -c:v libx264 -preset veryslow -tune film output_vfr.mkvcae hasta 9 cuadros seguidos, y solo si el bloque más diferente era diferente en "400", y (por defecto): no más del 33% de los bloques eran diferentes en unidades "320". IIRC, es básicamente un SAD 8x8 en componentes de píxeles.

(Sin .mp4embargo, FFmpeg está predeterminado en CFR para las salidas, así que úselo -vsync 2para .mp4salida de velocidad de cuadro variable . Creo que es seguro: problemas con la velocidad de cuadro en la conversión de video usando ffmpeg con libx264 )

La mayoría de los NLE le permitirán importar una imagen fija en la forma en que desea que aparezca en la línea de tiempo, suponiendo que haya configurado las propiedades del proyecto a una velocidad de cuadro estándar, como 30 fps o 24 fps, etc.

En Vegas Pro puedo configurar el tiempo en que debe aparecer una imagen fija en la línea de tiempo, desde una fracción de segundo hasta varios segundos. Si configuro esto en 1 segundo, cuando arrastre y suelte una imagen fija en la línea de tiempo, Vegas generará suficientes cuadros para satisfacer mi solicitud. Usualmente edito con videos de 30 fps, y cuando agrego una imagen fija, estoy mezclando una línea de tiempo con un video de 30 fps que ya está allí (AVCHD 1080p).

Para darle una respuesta específica, necesitaría saber qué NLE está utilizando.