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.