.png)
En lugar de proporcionar una velocidad de fotogramas fija para FFMPEG/libx264 (-r/-framerate), me gustaría especificar una velocidad de fotogramas variable con un valor MÁXIMO y permitir que libx264 reduzca la velocidad de fotogramas como mejor le parezca. La idea aquí es obtener una compresión adicional cuando hay algo así como un fotograma fijo extendido (lo que sucedeMUCHOen mis videos fuente).
Me doy cuenta de que un fotograma MPEG predictivo o bidireccional se comprimirá muy bien, pero también es posible que la velocidad de fotogramas de origen sea menor que la que pretendo transcodificar (¡posiblemente resultando en una transmisión MÁS GRANDE!).
Respuesta1
Frustrado porque tampoco habías encontrado una respuesta, al menos iba a responder las preguntas de otras personas sobre cómo habilitar VFR (no VBR) salida de FFMPEG.
La respuesta a esto es la -vsyncopción con un nombre extraño. Puede configurarlo con algunas opciones diferentes, pero la que desea es '2' o vfr. Desde la página de manual:
-vsync parámetro
Método de sincronización de vídeo. Por razones de compatibilidad, los valores antiguos se pueden especificar como números. Los valores recién agregados siempre deberán especificarse como cadenas.
0, paso a través
- Cada cuadro se pasa con su marca de tiempo del demuxer al muxer.
1, cf.
- Los fotogramas se duplicarán y eliminarán para lograr exactamente la velocidad de fotogramas constante solicitada.
2, vfr
- Los fotogramas se pasan con su marca de tiempo o se eliminan para evitar que 2 fotogramas tengan la misma marca de tiempo.
gota
- Como transferencia, pero destruye todas las marcas de tiempo, lo que hace que el muxer genere nuevas marcas de tiempo basadas en la velocidad de fotogramas.
-1, automático
- Elige entre 1 y 2 dependiendo de las capacidades del muxer. Este es el método por defecto.
Tenga en cuenta que el muxer puede modificar aún más las marcas de tiempo después de esto. Por ejemplo, en el caso de que la opción de formatoevitar_ts_negativosestá habilitado.
Con -map puedes seleccionar de qué flujo se deben tomar las marcas de tiempo. Puede dejar el vídeo o el audio sin cambios y sincronizar las transmisiones restantes con la que no ha cambiado.
Sin embargo, no tengo suficiente reputación para publicar un comentario y responder simplemente a esa "subpregunta" que todo el mundo parece tener. Pero tenía algunas ideas sobre las que, sinceramente, no era muy optimista... Pero la primera que probé en realidadtrabajó. Entonces.
¡Simplemente necesita combinar la -vsync 2opción con la -r $maxfpsopción, por supuesto, donde reemplaza $maxfpscon la velocidad de fotogramas máxima que desee! ¡Y funciona! ¡No duplica fotogramas de un archivo fuente, pero eliminará fotogramas que hacen que el archivo supere la velocidad de fotogramas máxima!
De forma predeterminada, parece que -r $maxfpspor sí solo hace que duplique/elimine fotogramas para lograr una velocidad de fotogramas constante, y -vsync 2por sí mismo hace que introduzca los fotogramas directamente sin afectar realmente los valores de PTS.
No era optimista acerca de esto porque ya sabía que eso -r $maxfpslo coloca en una velocidad de fotogramas constante. Sinceramente, esperaba un error o que simplemente obedeciera lo que ocurriera primero o lo último o lo que fuera. El hecho de que haga exactamente lo que quería me hace estar bastante satisfecho con los desarrolladores de FFMPEG.
Espero que esto te ayude a ti o a alguien más más adelante si ya no necesitas saber esto.
Respuesta2
Me gustaría especificar una velocidad de fotogramas variable con un valor MÁXIMO y permitir que libx264 reduzca la velocidad de fotogramas como mejor le parezca. La idea aquí es obtener una compresión adicional cuando hay algo así como un fotograma fijo extendido.
Según tengo entendido, esto puede ser posible de una manera comparativamente torpe, pero no es deseable por algunas razones complejas y contraintuitivas.
Aunque una transmisión x264 tiene una velocidad de fotogramas, la velocidad de fotogramas es más un problema a nivel de contenedor que de códec.
En una codificación VFR de paso, habrá lo que es esencialmente un archivo de texto que detalla cuál es la velocidad de fotogramas en qué fotogramas/tiempos, y al codificar una fuente, una función como tcfile-in o tcfile-out pasa las marcas de tiempo a la codificación. , para mapear las ubicaciones de las tarifas y mantener el video subjetivamente consistente desde la fuente.
La idea de una velocidad de fotogramas baja es lógica, pero no funciona por varias razones. Aunque x264 es compatible con VFR con algunas capacidades, no creo que haya una función de análisis que varíe la velocidad de cuadros con respecto al movimiento para reducir el tamaño del archivo (de manera análoga a los muchos controles de velocidad de bits).
La fuente también es un problema: las fuentes VFR conservarán de forma predeterminada su variabilidad de fotogramas, pero aparentemente codificar un archivo CFR a una velocidad de bits variable (una buena idea a veces, especialmente cuando se necesita telecine) simplemente producirá el mismo CFR.
Esto significa que probablemente tendría que reescribir la tasa de bits a mano (es decir, marcas de tiempo de escenas lentas mezcladas en el archivo), o recurrir a unAlgoritmo de aniquilación de fotogramas como dup, dedup y exactitudDedup para avisynth. Si su vídeo tiene un movimiento extremadamente bajo, algunos fotogramas (¿incluso la mitad?) se descartarían. El problema es que estos algoritmos no son avanzados y no toman buenas decisiones con imágenes de la "vida real" en cuanto a lo que contribuirá a la mejor codificación.
Además, eliminar fotogramas que contienen elementos como fotogramas I y B reduce la cantidad de detalles disponibles con el tiempo, lo que hace que el movimiento parezca "escalonado" y puede interferir con otros parámetros básicos del vídeo y provocar artefactos como alias.
Y debido a la forma en que funcionan los cuantificadores, x264 en realidad disminuirá la tasa de bits de manera desproporcionada en estas escenas de bajo movimiento. A menos que tenga una presentación de diapositivas de imágenes idénticas, habrá movimiento (aunque solo sea grano y otros artefactos) y habrá una pérdida de calidad que no se vería sin cambios drásticos en la tasa de bits.
Y finalmente, la razón por la que no hay muchas opciones para hacer lo que quieres es que x264 es realmente bueno para administrar la tasa de bits simplemente usando compresión temporal (grabando cambios en fotogramas parciales). Ir a 1/2 framerate no reducirá el tamaño del archivo a la mitad; Un 10% es probablemente una ganancia realista que se puede esperar de movimientos o animaciones bajas.
En resumen, reducir la tasa de bits de sus escenas estáticas hará muy poco por el tamaño de su archivo, pero agregará una serie de problemas de calidad y sincronización, sin mencionar la incompatibilidad con el software de edición de video.
Si desea probar un diezmador, es posible que pueda limitar la velocidad máxima de fotogramas nuevos utilizando elopciones de niveles, cada uno de los cuales especifica una resolución y velocidad de fotogramas máximas. Desafortunadamente, probablemente tendrías que trabajar con resoluciones muy bajas para obtener el tipo de velocidad de cuadros que deseas, usando perfiles. Se trata de editar las velocidades a mano, ya sea por completo o para corregir las velocidades de fotogramas que cree que son demasiado altas. De cualquier manera, será necesario hacer malabarismos para mantener el sonido sincronizado con las nuevas velocidades de fotogramas si se realizan modificaciones después del proceso de codificación cuando se conserva el archivo tc.
La conclusión es que dedicar tiempo a optimizar las numerosas configuraciones de velocidad de bits producirá mucho más en la gestión del tamaño de los archivos y mejorará la calidad de su video, en lugar de causar complicaciones por poca ganancia. Preservar el FPS original es probablemente la mejor idea, a menos que busques estándares de transmisión o medios. Los reproductores están bien diseñados para manejar diferentes velocidades de bits (a diferencia de los NLE), y cuantos más fotogramas tenga el vídeo, más fluida será la reproducción y quizás más pequeño sea el tamaño del archivo, debido a los menores cambios de movimiento entre fotogramas.
Aquí hay una colección de enlaces a información sobre estándares y discusiones en foros que deberían ayudar con este aspecto confuso de la codificación:
-herramientas de aniquilación de avisynth
-interruptores fps y -r
-x264 General (archivo tc, fps)
-estándares de archivos de código de tiempo
-Niveles y perfiles
-Resumen breve y claro de configuración de CFR/VFR (sección "velocidad de fotogramas")
Respuesta3
Solución perfecta: reduzca los fotogramas repetidos muy similares y guarde la salida a una velocidad de fotogramas variable (máxima)
- Para contenido con escenas fijas largas, eliminar fotogramas duplicados puede reducir la velocidad de fotogramas de forma dinámica y significativamente baja para lograr una mayor reducción del tamaño del archivo de la que el códec y su compresión intracuadro pueden lograr.
- En mi ejemplo:
- Tamaño de archivo intermedio 100% original a 60 FPS
- 15% CR28 a una velocidad de fotogramas constante de 60 FPS
- 6% CR28 a una velocidad de fotogramas máxima de 60 FPS (¡casi un factor de 3x!)
Originales disponibles
ffmpeg -i screen-recording.mov -movflags faststart -c:v libx264 -vf mpdecimate -vsync vfr -r 120 -preset veryslow -crf 24 screen-recording-vfr.mp4
Transcodifique vídeo ya comprimido a velocidad de fotogramas dinámica sin volver a codificarlo
ffmpeg -i video-export-old.mp4 -vf mpdecimate -vsync vfr video-export-mpdecimated-without-reencoding.mp4
En detalle
Originales disponibles
ffmpeg -i screen-recording.mov -movflags faststart -c:v libx264 -vf mpdecimate -vsync vfr -r 120 -preset veryslow -crf 24 "screen-recording-vfr.mp4"
-i video-mezzanine.mov Original or your high quality rendered export as the input file.
-movflags faststart Streaming ready by putting the moov atom to the file start.
-c:v libx264 H-264 codec
-vf mpdecimate Drop frames not differing greatly from previous frame to reduce frame rate.
-vsync vfr Output as variable frame rate (vfr)! Necessary sister option to 'mpdecimate'.
- To maintain the playback speed while benefitting from the file size reduction.
-r 30 If you specify -r then in this combo it serves as the peak framerate!
I recommend to omit this option:
- Then the peak framerate IS the peak/constant rate of the source.
- Which preserves dynamic scenes fully and compresses long still sequences.
- So the best of both aspects.
- State a peak FPS if loosing FPS in dynamic scenes
is acceptable for the reduction in file size.
-crf 24 - Constant Rate Factor (constant quality at variable bitrate)
-preset veryslow - Quality effort put into the encoding
screen-recording-vfr.mp4 - Output file
Convierta videos ya exportados a una velocidad de cuadros dinámica sin volver a codificarlos
ffmpeg -i video-export-old.mp4 -vf mpdecimate -vsync vfr video-export-mpdecimated.mp4
Esta es una operación sin pérdidas. No se produce ninguna recodificación con pérdida, solo reempaquetado/referenciación.
¡Eliminará tantos fotogramas duplicados como pueda!
Ejemplo:
Presentación de diapositivas de solo 3 imágenes fijas sin transiciones * cada una con una duración de 5 segundos * a 50 FPS = 750 fotogramas
ffmpeg¡De hecho, lo reducirá a solo 3 fotogramas a 1/5 (=0,2) FPS! ¡Confirmado con mediainfo!
Análisis y aprendizajes
- Los vídeos con escenas largas de imágenes fijas pueden reducir significativamente la cantidad de fotogramas y el tamaño del archivo.
- Para ambos escenarios
- La codificación desde el archivo intermedio con el mismo CFR mantiene la calidad visual
- Pero la reducción del tamaño del archivo de velocidad de fotogramas constante a variable es del 15% al 6%.
- La reducción de la velocidad de fotogramas sin volver a codificar reduce menos el tamaño del archivo, pero aún así:
- Trae una reducción del tamaño del archivo (15% a 10%)
- La codificación desde el archivo intermedio con el mismo CFR mantiene la calidad visual
screen-recording.mov
- Frame rate mode: Variable
- Frame rate: 58.628 FPS
- Minimum frame rate: 30.000 FPS
- Maximum frame rate: 60.000 FPS
- Frame count: 732 100 %
- Size: 1675084 bytes 100 %
screen-recording CR24 fps 60.mp4
- Frame rate mode: Constant
- Frame rate: 60.000 FPS
- Frame count: 750 102 %
- Size: 255863 bytes 15 %
screen-recording CR24 mpdecimated vfr.mp4
- Frame rate mode: Variable
- Frame rate: 17.398 FPS
- Minimum frame rate: 1.132 FPS
- Maximum frame rate: 60.000 FPS
- Frame count: 214 29 %
- Size: 101860 bytes 6 %
screen-recording CR24 mpdecimated fps 30 max.mp4
- Frame rate mode: Variable
- Frame rate: 11.078 FPS
- Minimum frame rate: 1.154 FPS
- Maximum frame rate: 30.000 FPS
- Frame count: 137 17 %
- Size: 94382 bytes 5.6
screen-recording CR24 mpdecimated vfr without re-encoding faststart.mp4
- Frame rate mode: Variable
- Frame rate: 19.974 FPS
- Minimum frame rate: 1.132 FPS
- Maximum frame rate: 60.000 FPS
- Frame count: 247 33 %
- Size: 165 KB (164947 bytes) 10 %