Saltar al contenido

FFMPEG / libx264: ¿Cómo especificar una velocidad de fotogramas variable pero con un máximo?

Nuestro equipo redactor ha estado mucho tiempo investigando para dar resolución a tu duda, te regalamos la respuestas así que esperamos serte de mucha ayuda.

Solución:

Frustrado de que tampoco hayas 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 eso es el nombre extraño -vsync opción. Puede configurarlo en algunas opciones diferentes, pero la que desea es ‘2’ o vfr. Desde la página del manual:

-vsyncparámetro

Método de sincronización de video. Por razones de compatibilidad, los valores antiguos se pueden especificar como números. Los valores recién agregados deberán especificarse siempre como cadenas.

  • 0, traspaso

    • Cada trama se pasa con su marca de tiempo desde el demuxer al muxer.
  • 1, cfr

    • Los fotogramas se duplicarán y eliminarán para lograr exactamente la frecuencia 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.
  • soltar

    • Como traspaso, 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, después de esto, el muxer puede modificar las marcas de tiempo. Por ejemplo, en el caso de que la opción de formato evitar_t_negativos está habilitado.

Con -map puede seleccionar de qué flujo se deben tomar las marcas de tiempo. Puede dejar el video o el audio sin cambios y sincronizar las transmisiones restantes con la que no se modificó.

Sin embargo, no tengo la reputación suficiente para publicar un comentario que solo responda a esa ‘subpregunta’ que todos parecen tener. Pero tenía algunas ideas sobre las que, honestamente, no era muy optimista … Pero la primera que probé en realidad trabajó. Entonces.

Simplemente necesita combinar el -vsync 2 opción con la -r $maxfps opción, por supuesto, donde reemplaza $maxfps ¡con la máxima velocidad de fotogramas que quieras! ¡Y funciona! No duplica los fotogramas de un archivo de origen, pero eliminará los fotogramas que hacen que el archivo supere la velocidad máxima de fotogramas.

Por defecto parece que -r $maxfps por sí solo hace que duplique / elimine fotogramas para lograr una velocidad de fotogramas constante, y -vsync 2 por sí mismo hace que tire de los fotogramas directamente sin afectar realmente los valores de PTS.

No era optimista sobre esto porque ya sabía que -r $maxfps lo pone a una velocidad de fotogramas constante. Honestamente, esperaba un error o que simplemente obedeciera lo que ocurriera primero o el último o lo que sea. El hecho de que haga exactamente lo que yo quería me hace bastante satisfecho con los desarrolladores de FFMPEG.

Espero que esto le ayude a usted, oa otra persona más adelante, si ya no necesita saberlo.

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

En mi opinión, esto puede ser posiblemente de una manera relativamente torpe, pero no es deseable por algunas razones complejas y contradictorias.

Aunque una transmisión x264 tiene una velocidad de fotogramas, la frecuencia 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 sobre 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 tarifas y mantener el video subjetivamente consistente desde la fuente.

La idea de una tasa 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 fotogramas con respecto al movimiento para reducir el tamaño del archivo (de una manera análoga a los muchos controles de velocidad de bits).

La fuente también es un problema: las fuentes VFR conservarán por defecto su variabilidad de tramas, pero aparentemente codificar un archivo CFR a una tasa 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 volver a escribir la tasa de bits a mano (es decir, marcas de tiempo de escenas lentas mezcladas en el archivo), o recurrir a un algoritmo de diezmado de fotogramas como dup, dedup y exactDedup para avisynth. Si su video tiene un movimiento extremadamente bajo, se descartarán algunos fotogramas (¿incluso la mitad?). 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, la eliminación de fotogramas que contienen elementos como fotogramas I y B reduce la cantidad de detalles disponibles a lo largo del tiempo, lo que hace que el movimiento parezca “escalonado” y puede interferir con los otros parámetros básicos de vídeo y provocar artefactos como el alias.

Y debido a la forma en que funcionan los cuantificadores, x264 en realidad disminuirá la tasa de bits desproporcionadamente aún más 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 el 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 desea es que x264 es realmente bueno para administrar la tasa de bits simplemente usando compresión temporal (registrando cambios en cuadros parciales). Ir a 1/2 fotogramas por segundo no reducirá el tamaño del archivo a la mitad; El 10% es probablemente una ganancia realista que se puede esperar de la animación o el movimiento bajo.

En resumen, reduciendo la tasa de bits de tu static Las escenas harán muy poco por el tamaño de su archivo, pero agregarán 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 decimador, es posible que pueda limitar la velocidad máxima de fotogramas nuevos utilizando el opciones de niveles, cada una de las cuales tiene una resolución máxima y una velocidad de fotogramas. Desafortunadamente, probablemente tendría que trabajar a resoluciones muy bajas para obtener el tipo de velocidad de fotogramas que desea, utilizando perfiles. Se trata de editar las velocidades a mano, ya sea por completo o para corregir las velocidades de cuadro que cree que son demasiado altas. De cualquier manera, será necesario hacer malabares para mantener el sonido sincronizado con las nuevas velocidades de fotogramas si se realizan alteraciones después del proceso de codificación cuando se conserva el archivo tc.

La conclusión es que dedicar tiempo a optimizar las muchas configuraciones de velocidad de bits producirá mucho más en la forma de administración del tamaño de archivo 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 esté apuntando a estándares de transmisión o medios. Los reproductores son capaces de reproducir velocidades de bits variables (a diferencia de los editores), y cuantos más fotogramas haya en su video, más fluida será la reproducción y quizás menor sea el tamaño del archivo, debido a cambios más pequeños en el movimiento entre fotogramas.

Aquí hay una colección de enlaces a información de estándares y discusiones en foros que deberían ayudar con este aspecto confuso de la codificación:

-avisynth herramientas de diezmado

-fps y -r conmutadores
-x264 General (archivo tc, fps)
-estándares de archivo de código de tiempo
-Niveles y perfiles
-Resumen breve y claro de la configuración de CFR / VFR (sección “velocidad de fotogramas”)

Doom9, videohelp, & c discusiones teóricas

1 2 3 4 5 6 7

Reseñas y valoraciones

Ten en cuenta dar difusión a este enunciado si te fue útil.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *