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

Estoy con AJ. A menos que conozca las características de cada jugador que podría ver esto, no sería prudente confiar en una pequeña muestra de los resultados de las pruebas. El uso de una velocidad de fotogramas estándar como 24 fps con un intervalo de fotogramas clave de 24 fotogramas 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 largo de fotogramas clave. 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 (ningún) cambio entre cuadros. No estoy seguro de que realmente obtenga suficientes ahorros al reducir la velocidad de fotogramas para que valga la pena perder el control sobre cuándo puede realizar un cambio en el fotograma.

Lo mejor sería probarlo con sus medios y ver los resultados. La compresión depende en gran medida del contenido y la mejor calidad y compresión para cualquier 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 un poco convirtiendo 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. Recibí algunas respuestas útiles sobre las implicaciones técnicas de esto de los desarrolladores x264 en doom9. Por ejemplo, fuerce a x264 a no usar marcos B para esto, porque las imágenes no muy relacionadas necesitarán muchos macrobloques I, y codificarlos en marcos B es más costoso.

El comportamiento del reproductor de software con video de bajo fps no es ideal, en el pasado. Creo que un jugador mayor solo comprobaba la entrada del teclado cuando mostraba un cuadro. Entonces 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 fragmentos realmente grandes (¡2 minutos más o menos!) si no reduce el intervalo de fotogramas clave. x264 no insertará IDR (límites GOP) por todas partes si las imágenes están relacionadas entre sí.

uso x264 -tune stillimage_ Aumenta las optimizaciones de psy , porque la estabilidad temporal no es un problema para este caso de uso. Más resultados de búsqueda: de google .

Estoy de acuerdo con otras sugerencias de tener algunos marcos duplicados, para aumentar el FPS a 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 videos de FPS variable, ya que generalmente graban de esa manera cuando los niveles de luz bajan. Dado que los videos de FPS variable de los teléfonos ahora están disponibles, se debe esperar la compatibilidad con el reproductor de hardware para ellos. No esperaría problemas, pero tampoco me sorprendería si al menos hay algunos reproductores de hardware antiguos que no lo manejan bien.

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

Sin embargo, hay una desventaja de compresión en la duplicación de 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 hará que sea más difícil para el codificador encontrarlo y explotarlo.

Según la configuración de codificación, el codificador solo conservará una cierta cantidad de fotogramas antiguos como posibles referencias para fotogramas nuevos 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 de primer plano se mueva frente a algún detalle de fondo, el codificador puede ahorrar 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 marco de referencia, pero aún es algo dañino para la eficiencia de compresión y una pérdida de energía / vida útil de la batería / tiempo de CPU en el lado de la descompresión para copiar la memoria alrededor de la decodificación y mostrar marcos 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 descarta fotogramas similares. Puede establecer límites sobre la cantidad de fotogramas seguidos que puede soltar. Con un umbral de similitud ajustado, debe hacer que solo elimine los 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.mkv, cae hasta 9 fotogramas seguidos, y solo si el bloque más diferente era diferente en "400" y (predeterminado): no más del 33% de los bloques eran diferentes en "320" unidades. IIRC, es básicamente un SAD de 8x8 en componentes de píxeles.

(Sin embargo, FFmpeg tiene como valor predeterminado CFR para .mp4las salidas, así que utilícelo para la salida -vsync 2de velocidad de fotogramas variable.mp4 . Creo que es seguro: Problemas con la velocidad de fotogramas 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 de cuánto tiempo desea que aparezca en la línea de tiempo, suponiendo que haya establecido las propiedades del proyecto en alguna velocidad de cuadro estándar, como 30 fps o 24 fps, etc.

En Vegas Pro, puedo configurar el tiempo 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 fotogramas 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á usando.