ffmpeg- ¿Cuál es la diferencia entre "NN000/1000 fps" y "NN000/1001 fps"?

Estoy tratando de seleccionar las opciones de captura correctas ffmpegy estoy confundido por este tipo de lista:

[decklink @ 00000000010564c0]   17      3840x2160 at 24000/1001 fps
[decklink @ 00000000010564c0]   18      3840x2160 at 24000/1000 fps
[decklink @ 00000000010564c0]   19      3840x2160 at 25000/1000 fps
[decklink @ 00000000010564c0]   20      3840x2160 at 30000/1001 fps
[decklink @ 00000000010564c0]   21      3840x2160 at 30000/1000 fps

Basado en el hecho de que 24 y 30 tienen dos entradas y 25 solo tiene una, asumo que las dos opciones de 24 son 24 fps y 23,9 fps reales, y las dos opciones de 30 son 30 fps y 29,97 fps reales.

¿Pero cuál es cuál? ¿Y por qué se utiliza este tipo de notación?

Respuestas (3)

Sí, 24000/1000es de 24 fps y 24000/1001es de 23.976 fps. Algunos se refieren a las velocidades de fotogramas de X/1001 como "desplegable" (como "descendente del número entero"), pero esto es fácil de confundir con "pull down", que a menudo se refiere a la cadencia de los fotogramas cuando se ajusta a 24 o 25 fps. material en un programa de 30 fps.

También puede pensar en estas notaciones como 24,000 divided by 1,000 equals 24y 24,000 divided by 1,001 equals 23.976023976 repeating. Esta notación también es exactamente lo mismo que decir 24 divided by 1 equals 24y 24 divided by 1.001 equals 23.976023976 repeating. Por supuesto, es bastante ridículo articular los valores decimales periódicos.

Las 1001opciones y la notación resultante son un legado de los sistemas de televisión en color analógicos. Como señala Mulvya, "es porque ese es el conjunto más pequeño de números que representan el valor como números enteros". Estos estándares todavía existen hoy en día principalmente por compatibilidad con versiones anteriores (con televisores en blanco y negro) y porque así es como creció la televisión. Antes de la televisión en color, la velocidad de fotogramas NTSC era en realidad exactamente treinta fotogramas por segundo.

En cuanto a la notación 30000/1000y 30000/1001, proviene del estándar de video NTSC. "30" fps NTSC en realidad muestra 30/1,001 fotogramas por segundo (a veces denominado "29,97" o "30DF" para abreviar, pero para ser precisos 29,97002997... fotogramas repetidos por segundo). Debido a esta ligera diferencia (0,01 %), NTSC utiliza el conteo de código de tiempo Drop-Frame (DF) o Non Drop-Frame (NDF). Drop-Frame "cae" los recuentos de fotogramas en un patrón tal que cada diez minutos la duración del código de tiempo corresponderá a la duración real de la reproducción. No se eliminan cuadros de imagen y esto fue principalmente una consideración para las emisoras que ajustaban sus programas con cortes comerciales. Non Drop-Frame, por otro lado, representa con mayor precisión un conteo del número total de fotogramas en un programa (para aquellos que disfrutan contando en base 24:60:

En cuanto a 25000/1000que no hay un estándar de 25/1,001 fps porque 25 fps es un estándar PAL y los sistemas de video PAL se diseñaron con una potencia de CA de 50 Hz que no tuvo los mismos problemas que NTSC cuando surgió el color.

Usted mencionó 50 Hz CA. ¿Está diciendo que estas velocidades de cuadro no enteras se usaron para evitar interferencias con la frecuencia de la fuente de alimentación de CA?
@VioletGiraffe tanto NTSC (29,97 fps) como PAL (25 fps) se diseñaron para su uso con la red eléctrica de CA. Las características del estándar estadounidense con AC (60Hz) llevaron a la implementación de video color NTSC con 29.97 (30/1.001). La implementación del color PAL con el estándar AC europeo (50 Hz) no requirió las mismas consideraciones de ingeniería. Este blog explica algunas de las consideraciones históricas/de ingeniería para los estándares no enteros. 24/1.001 provino de la adaptación de película (24 fps) a NTSC. Adaptar una película de 24 fps a un video de 25 fps (PAL) es mucho más fácil
@ Mr.Kennedy, las velocidades de fotogramas no enteras son "drop frame ", no desplegables.
@MichaelLiebman "drop frame" se refiere específicamente al código de tiempo, "algunos" se refieren a la velocidad de fotogramas no enteros como "desplegable", es decir, bajar la velocidad de fotogramas del entero, por ejemplo, 30 desplegables es la velocidad de fotogramas de NTSC & drop frame salta de 00;09;59;28 a 00;10;00;00. Este era el lenguaje común a finales de los noventa y principios de los 2000 antes de la ubicuidad de los estándares digitales.
En toda mi carrera en la televisión, que comenzó a mediados de los 90 en los EE. UU., nunca escuché el término velocidad de fotogramas "desplegable". No pude encontrar ninguna referencia a ese término en la revista SMPTE.
@MichaelLiebman "algo", no "SMPTE", también ha trabajado profesionalmente en películas de video para televisión y CG desde 1987. "Drop Frame" es una convención de código de tiempo, no una velocidad de cuadro. Si desea seguir discutiendo el problema, podemos iniciar una conversación, ya que esto no agrega nada para responder la pregunta del OP.
"Encajar una película de 24 fps en un video de 25 fps (PAL) es mucho más fácil". Tengo que discrepar con el hecho de que acelerar su video un 4% y hacer que todos suenen un poco como ardillas listadas es "más fácil".

Esos son números racionales. Entonces, 24000/1000 = 24.000y 24000/1001 = 23.976. De hecho, estas son las representaciones exactas, es decir, 23,976 es una aproximación, pero 24000 dividido por 1001 no lo es.

En cuanto a por qué 24000/1001y no 24/1.001, es porque ese es el conjunto más pequeño de números que representan el valor como enteros . De lo contrario, se necesitaría una variable de punto flotante para el denominador.

Con respecto a su último párrafo, ¿está seguro de que los tipos de datos enteros son la razón por la que se representa en miles? Mi comprensión de la programación es que si hace operaciones matemáticas con tipos de datos enteros que dan como resultado decimales, los decimales simplemente se truncan en su resultado. Si esto es cierto, entonces ciertamente no puede ser la razón por la que los representan en miles.
Para el almacenamiento en archivos. Siempre puede convertir las variables durante las operaciones.
De ffmpeg's rational.h: " Si bien los números racionales se pueden expresar como números de punto flotante, el proceso de conversión tiene pérdidas, al igual que las operaciones de punto flotante. Por otro lado, la naturaleza de FFmpeg exige un cálculo muy preciso de las marcas de tiempo " . almacenado como una estructura AVRational que tiene dos enteros: uno para el numerador y otro para el denominador.
@Mulvya Lo siento, pero no entiendo muy bien. ¿Cómo puede una estructura de datos tener pérdidas? Todavía tienes que hacer los cálculos en el numerador y el denominador. Y si solo hay un número finito de frecuencias de cuadro que se utilizan, ¿por qué no se pueden enumerar?
No dije ni cité nada sobre "una estructura de datos con pérdida". Los números de coma flotante tienen una precisión limitada por el espacio dedicado a su almacenamiento. Un representante racional puede mantener una mayor precisión porque en el código que implica la manipulación de la velocidad de fotogramas, ffmpeg utiliza rutinas personalizadas que mantienen el valor en forma de número/den, es decir, no se colapsa en un único resultado de punto flotante o entero.

La velocidad de fotogramas original para la transmisión de televisión era de 60 campos (la mitad de un fotograma) por segundo en los EE. UU., y el tiempo se basaba en la oscilación de la alimentación de CA (por lo que, claramente, la televisión europea necesitaba una velocidad de fotogramas diferente con la tecnología más antigua).

Sin embargo, cuando se agregó color a NTSC, la señal de color interfirió en la señal de audio. En ese momento, se disponía de medios de sincronización más avanzados, por lo que la solución rápida fue reducir la velocidad de fotogramas muy ligeramente. El color se realizó de forma ligeramente diferente en PAL y este ajuste no fue necesario, por lo que no hay 25000/1001.

ffmpeg- ¿Cuál es la diferencia entre "NN000/1000 fps" y "NN000/1001 fps"?
RespuestasAquíPolítica de privacidad1y, 0v