¿Hay solo unas pocas velocidades de fotogramas de video estándar?

En el video digital moderno, ¿se puede marcar un archivo de video con una velocidad de cuadro arbitraria? ¿O solo se admiten ampliamente algunas velocidades de cuadro específicas? Por "moderno" me refiero a los reproductores de software como Quicktime, VLC, Roku, consolas de juegos, etc. Tengo curiosidad por saber qué dicen los estándares de video sobre las velocidades de fotogramas permitidas y luego qué funciona realmente en la práctica.

Entiendo que 24 fps, 25 fps, 30 fps, 50 fps y 60 fps son estándares ampliamente admitidos. HandBrake también ofrece 5, 10 y 15; son esas opciones estándar? ¿Puedo usar cualquier número de FPS que quiera? ¿Y qué pasa con las tasas no enteras como 23.976 y 29.97; ¿son realmente tratados de manera diferente por el software que 24 y 30? También veo referencias a "velocidad de cuadro variable" en secuencias H.264; ¿eso realmente funciona y si es así, qué lo usa?

Mi pregunta específica es cuál es la mejor manera de codificar algunos escaneos de película de 8 mm. La fuente es de 16 fps, el estándar de película de 8 mm. En este momento estoy duplicando cada dos cuadros para llevarlo a 24 fps, lo que funciona bien, pero me pregunto por qué no puedo marcar el video como 16 fps. FWIW He producido archivos mp4 H.264 con Handbrake a 15 fps y descubrí que solo se reproducían correctamente en VLC. Mac Quicktime los jugó demasiado rápido, probablemente a 24 fps.

Hay varias velocidades de cuadro "estándar", pero cada vez son más las que admiten velocidades de cuadros arbitrarias más fáciles que las específicas. Esto es especialmente cierto para los reproductores de software, como VLC.

Existe cada vez más soporte para VARIABLE fps. (VFR, frecuencia de cuadro variable). Aquí es donde el intervalo entre cuadros dentro del mismo video no es constante. Muchos formatos de archivo de contenedor de video (como Matroska ( .mkv) o MPEG-4 ( .mp4estrechamente relacionado con Apple .mov)) ni siquiera almacenan un número FPS, sino una base de tiempo (por ejemplo, 1/30 de segundo), y luego cada cuadro tiene una marca de tiempo como múltiplo de esa base de tiempo. Sucede que el intervalo entre cada cuadro es uno o un número entero pequeño de unidades de la base de tiempo en un video CFR (velocidad de cuadro constante).

Las imágenes de cámaras de seguridad con fotogramas casi duplicados descartados serían un caso de uso obvio para VFR. Incluso más si se está comprimiendo con un códec de video simplista que no aprovecha la redundancia temporal (con cuadros inter (p y b)). (juegue con ffmpeg -vf mpdecimatepara soltar cuadros near-dup. Úselo -vsync 2si sale a mp4, porque por alguna razón no es el valor predeterminado para ese silenciador, pero es para mkv).

Otro caso son los teléfonos inteligentes modernos. Por ejemplo, el Moto G (segunda generación) de mi hermano graba videos VFR. Reduce la velocidad de fotogramas cuando el sensor necesita más luz. Algunos de los resultados de ejecutar mediainfo en un mp4 creado por el software del teléfono, grabado en interiores:

Bit rate                                 : 9 999 Kbps
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Rotation                                 : 90°
Frame rate mode                          : Variable
Frame rate                               : 16.587 fps
Minimum frame rate                       : 14.985 fps
Maximum frame rate                       : 30.030 fps

La reproducción de una sola transmisión de video VFR no es difícil. El software simplemente prepara el siguiente cuadro listo para mostrar, duerme hasta que se debe mostrar, luego se despierta y lo muestra.

Las cosas se vuelven un poco más complicadas cuando se tiene en cuenta el hecho de que los humanos solo pueden ver cuadros de video cuando un monitor los muestra. Existen monitores VFR, pero aún son raros. (google para g-sync freesync).

Cambiar la imagen mostrada mientras se escanea al monitor da como resultado un desgarro feo del video (comúnmente visto cuando se juega un juego con vsync desactivado). Esto limita a un jugador a cambiar la imagen mostrada a 50 o 60Hz. (Los CRT admiten velocidades de actualización arbitrarias, dentro de un rango, pero es complicado cocinar modos con todos los tiempos correctos, por lo que la mayoría de la gente solo usó algunas frecuencias de actualización fijas. Y ahora las personas tienen pantallas LCD que solo admiten una frecuencia de actualización fija de todos modos. Hasta Los monitores freesync están más extendidos de todos modos. Estoy ansioso por eso. :)

Por lo tanto, con velocidades de fotogramas de video que no son múltiples o un factor de la frecuencia de actualización del monitor, algunos fotogramas se mostrarán para 3 actualizaciones de monitor, y algunos para 2, por ejemplo, incluso si el video está destinado a una velocidad constante de 25 FPS (en un monitor de 60Hz).

Las cosas se vuelven más complicadas cuando quieres trabajar con múltiples clips y se desvanecen entre ellos, o imagen en imagen, o varios otros efectos. Es MUCHO más fácil escribir un software de edición de video si puede suponer que todos los clips tienen un nuevo marco al mismo tiempo. (Forzan la alineación del clip para que se ajuste a fotogramas completos).

Esta es la razón por la cual los NLE (como kdenlive o pitivi, para elegir ejemplos aleatorios de software libre), tienen más probabilidades de forzarlo a un FPS fijo y soltar / duplicar fotogramas de sus clips para que coincidan con esa velocidad de fotogramas. El CFR que elija puede ser arbitrario, pero generalmente tiene que ser constante para todo el "proyecto".

(¿Funciona algún NLE con clips VFR y produce salida VFR en ese caso?)

En resumen, una vez que tengamos monitores y sistemas operativos de sincronización variable, supongo que lo único que nos detendrá será la edición de videos. Y la transmisión, ya que aparentemente CFR también es un gran problema para eso.

En caso de que se lo pregunte, las 29.970 (en realidad 30000/1001) y 23.976 (en realidad 24000/1001, desde la telecomunicación) molestas velocidades de fotogramas no enteros son culpa del color NTSC. buscar 1.001 . Si solo hubieran estado dispuestos a arriesgarse a que algunos conjuntos en blanco y negro no pudieran manejar una frecuencia adicional de 0.1% para la subportadora de audio, el mundo se habría librado de esta tontería. (Creo que vi otro artículo en algún lugar que lo hizo sonar como si muchos conjuntos hubieran estado bien, pero no estaban seguros de una compatibilidad perfecta. Wikipedia hace que parezca que ningún conjunto podría manejar una subportadora de audio 0.1% más alta. hechos.)

Sin embargo, las molestas velocidades de cuadros son uno de los pecados menores de la transmisión. Realmente el entrelazado ha sido la ruina de la calidad de video en las pantallas modernas (todos los píxeles iluminados a la vez), y eso no habría cambiado. Todavía no entiendo por qué se mantuvo el entrelazado para HDTV. ¿Por qué alguna vez se definió 1080i60, en lugar de usar 720p60 para obtener la misma resolución temporal para deportes y otras cosas? Es similar a 1920x540p60, pero con un estúpido desplazamiento vertical entre campos pares e impares que requiere muchos cálculos en el extremo receptor para que no se vea horrible.

editar:

Para su caso de uso, sugeriría absolutamente archivar en el FPS nativo. No deseche ninguna información soltando cuadros. No duplique los marcos y haga que sus archivos sean más grandes (o haga que su codificador h.264 pase más tiempo notando los duplicados y generando un marco lleno de macrobloques omitidos que solo toma 20 bytes para todo el marco).

En el futuro, cuando esperamos que todos tengan pantallas de sincronización libre que puedan reproducir cualquier velocidad de cuadros, querrás deshacer tu pullup a 24 fps para que tu video se reproduzca sin problemas. O si freesync de alguna manera no se enciende, o la pantalla que viene después de las pantallas LCD es CFR, entonces la conversión de velocidad probablemente sea mejor en el momento de la reproducción de todos modos. No es que 24 fps incluso se reproduzca perfectamente en un monitor de 60Hz. (No noto visualmente el hecho de que algunos cuadros se muestran para 3 * 1/60, mientras que otros se muestran para 2 * 1/60, pero es cierto).

Si tiene problemas con Quicktime, entonces IDK. Tal vez asegúrese de que Handbrake esté haciendo archivos con el framerate correcto establecido en el flujo de bits h.264, así como el contenedor. (Sí, los encabezados h.264 aparentemente pueden almacenar una velocidad de fotogramas, aparte de lo que dice el contenedor. Consulte los documentos mkvmerge --fix-bitstream-timing-information. E intente usarlo --default-duration 16fpspara hacer un archivo mkv. Luego, ¿debe volver a mp4 y ver si eso soluciona el tiempo rápido? ) O tal vez hay una manera de hacerlo con herramientas mp4 en primer lugar. Ver por ejemplo: /ubuntu/370692/how-to-change-the-framerate-of-a-video-without-reencoding

Puedo garantizar que la velocidad de fotogramas arbitraria mp4 es válida, e incluso la velocidad de fotogramas variable mp4 es válida. Si Quicktime juega mal, bien podría ser culpa de Quicktime. O tal vez la culpa de Handbrake por hacer el archivo incorrecto. Por lo general, solo uso ffmpeg directamente, porque soy un ninja de línea de comandos.

Para responder a su pregunta, sí, generalmente puede codificar un archivo de video en cualquier velocidad de fotogramas que desee. (Aunque algunos programas pueden optar por limitarlo para simplificar el software). La pregunta es si el formato de entrega que elija lo admitirá y ¿lo admitirá el dispositivo de reproducción?

Si tiene una película de 8 mm a 16 fps, la codificaría a 16 fps si supiera que los dispositivos de reproducción que quería admitir podrían manejarlo. Si no, probablemente usaría un software que admitiera flujo óptico (a veces llamado estimación de movimiento) para codificarlo a 24 fps, que es probablemente la velocidad de fotogramas más cercana que probablemente sea compatible con el software de codificación, el software de decodificación y la mayoría del hardware de reproducción.

El software (o hardware) que admite flujo óptico generará cuadros intermedios en función del movimiento de los objetos en su video. En lugar de repetir un fotograma o incluso mezclar 2 fotogramas, genera un nuevo fotograma que generalmente es bastante cercano a lo que realmente se habría grabado si hubiera grabado a la velocidad de fotogramas de salida.

Según la historia, 24 FPS provienen de kino (películas). La película estaba en cinta de video y se seleccionó la velocidad para que los movimientos fueran suaves.

25 FPS provienen de la frecuencia de energía en Europa, 50 Hz (50 FPS es de la misma fuente, pero en realidad la duplica). En realidad, la televisión en Europa era de 50 FPS, pero la mitad de cuadros, están entrelazados

30 FPS provienen de la frecuencia de potencia en EE. UU., 60 Hz (60 FPS es de la misma fuente, pero en realidad la duplica). En realidad, la televisión en EE. UU. Tenía 60 FPS, pero la mitad de los fotogramas estaban entrelazados

16 FPS no está tan extendido como estándar para fines profesionales, por lo que quizás esa sea la razón por la que no se usa en la mayoría del software actual. Además, tales FPS no "suavizarán" suficientemente el movimiento rápido. Tengo una idea loca de cómo puedes hacer que 16 FPS coincidan mejor 24. Los juts obtienen cada fotograma par e impar y hacen algo así como promedio entre ellos :)

Existen estándares establecidos para la televisión y los videos de películas que la mayoría de los videos cumplen. Una computadora a menudo puede mostrar video de múltiples cuadros por segundo, sin embargo, algunos televisores pueden tener problemas con los cuadros por segundo, ya que pueden usar circuitos de pantalla más especializados. Incluso en una computadora, la velocidad de fotogramas realmente mostrada puede no coincidir con la del archivo de video, dependiendo de las velocidades de actualización compatibles del monitor.

Sí, las velocidades de cuadro no enteras se muestran de manera diferente. Se conocen como drop frame y existen principalmente por motivos heredados. Cuando se reproduce, se suelta un fotograma (del código de tiempo) de vez en cuando para compensar la diferencia horaria y los fotogramas se distribuyen a la velocidad adecuada para mantenerlo suave. Sin embargo, esto tiene más que ver con cosas de sincronización en formatos heredados y evitar problemas de sincronización que ya no son relevantes.

Puede usar velocidades de cuadro no estándar y debería reproducirse bien en las PC, pero no se ajustará al video estándar para cosas como Bluray y puede que no se reproduzca bien en algunos televisores. (E incluso en aquellos en los que trabaja, es probable que haga un pulldown en tiempo real para ajustarse a una velocidad de fotogramas estándar, donde un pulldown hecho de antemano probablemente resultaría en una mejor calidad).

Su pregunta no es sobre las tasas comunes, sino sobre la tasa que debe usar para digitalizar su película. La respuesta: debe usar la tasa original si es posible, porque desea preservar la fuente en forma digital. Luego puede convertirlo a la velocidad de fotogramas que necesita para ver. En los viejos tiempos, generalmente significaba 24 fps para presentación teatral y 29,97 fps, entrelazados para video. Hoy en día puede hacer casi cualquier cosa, pero necesita tener una buena fuente, que coincida con el original de la manera más limpia posible.

Algunas otras notas. Primero, 48 fps se está volviendo más popular y común gracias a The Hobbit y ahora al soporte de YouTube para la velocidad de fotogramas. En segundo lugar, 30 fps suele ser de 29,97 fps y 60 suele ser de 59,94.