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 )