En el video digital moderno, ¿se puede marcar un archivo de video con cualquier velocidad de cuadro arbitraria? ¿O solo se admiten ampliamente algunas velocidades de fotogramas específicas? Por "moderno" me refiero a reproductores de software como Quicktime, VLC, Roku, consolas de juegos, etc. Tengo curiosidad tanto por lo que los estándares de video dicen que son velocidades de cuadro permitidas como por lo que realmente funciona 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 fotogramas variable" en flujos H.264; ¿Eso realmente funciona y, de ser así, qué lo usa?
Mi pregunta específica es cuál es la mejor manera de codificar algunos escaneos de películas de 8 mm. La fuente es de 16 fps, el estándar de película de 8 mm. En este momento, estoy duplicando cada otro cuadro para subirlo a 24 fps, lo que funciona bien, pero me pregunto por qué no puedo marcar el video como 16 fps. FWIW Produje archivos H.264 mp4 con Handbrake a 15 fps y descubrí que solo se reproducían correctamente en VLC. Mac Quicktime los reprodujo demasiado rápido, probablemente a 24 fps.
Hay varias velocidades de fotogramas "estándar", pero cada vez hay tantas que admitir velocidades de fotogramas arbitrarias es más fácil que admitir específicamente muchas. Esto es especialmente cierto para los reproductores de software, como VLC.
Cada vez hay más soporte para fps VARIABLES. (VFR, velocidad de fotogramas variable). Aquí es donde el intervalo entre cuadros dentro del mismo video no es una constante. Muchos formatos de archivo de contenedor de video (como Matroska ( .mkv) o MPEG-4 ( .mp4, estrechamente relacionado con el de Apple .mov)) ni siquiera almacenan un número de FPS, sino una base de tiempo (por ejemplo, 1/30 de segundo), y luego cada cuadro tiene una marca de tiempo como un múltiplo de esa base de tiempo. Da la casualidad de que el intervalo entre cada cuadro es uno o un pequeño número entero de unidades de la base de tiempo en un video CFR (velocidad de cuadro constante).
Las imágenes de la cámara de seguridad con fotogramas casi duplicados caídos serían un caso de uso obvio para VFR. Más aún si se está comprimiendo con un códec de video simplista que no aprovecha bien la redundancia temporal (con cuadros inter (p y b)). (Juegue con ffmpeg -vf mpdecimatepara soltar cuadros casi duplicados. Úselo -vsync 2si se envía a mp4, porque por alguna razón no es el predeterminado para ese muxer, pero es para mkv).
Otro caso son los smartphones modernos. Por ejemplo, el Moto G de mi hermano (2da generación) graba videos VFR. Disminuye 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, grabados 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 un solo flujo de video VFR no es difícil. El software solo prepara el siguiente cuadro para mostrarlo, duerme hasta que debería mostrarse, luego se activa y lo muestra.
Las cosas se complican un poco más cuando se tiene en cuenta el hecho de que los humanos solo pueden ver cuadros de video cuando los muestra un monitor. Los monitores VFR existen, pero todavía son raros. (google para g-sync freesync).
Cambiar la imagen que se muestra mientras se escanea en el 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 60 Hz. (Los CRT admiten tasas de actualización arbitrarias, dentro de un rango, pero es complicado preparar modos con todos los tiempos correctos, por lo que la mayoría de las personas solo usaban algunas tasas de actualización fijas. Y ahora las personas tienen LCD que solo admiten una tasa de actualización fija de todos modos. Hasta Los monitores freesync están más extendidos de todos modos. Estoy deseando que llegue. :)
Por lo tanto, con velocidades de cuadro de video que no son un múltiplo o un factor de la frecuencia de actualización del monitor, algunos cuadros se mostrarán para 3 actualizaciones de monitor y otros para 2, por ejemplo, incluso si el video debe estar a 25 FPS constantes. (en un monitor de 60 Hz).
Las cosas se complican más cuando desea trabajar con varios clips y desvanecerse entre ellos, o imagen en imagen, u otros efectos. Es MUCHO más fácil escribir un software de edición de video si puedes asumir que todos los clips tienen un nuevo marco al mismo tiempo. (Obligan a la alineación del clip a ajustarse a fotogramas completos).
Esta es la razón por la que es más probable que los NLE (como kdenlive o pitivi, para elegir ejemplos aleatorios de software gratuito) lo fuercen a un FPS fijo y eliminen o dupliquen fotogramas de sus clips para que coincidan con esa velocidad de fotogramas. El CFR que elija puede ser arbitrario, pero normalmente tiene que ser constante para todo el "proyecto".
(¿Algún NLE funciona completamente con clips VFR y produce salida VFR en ese caso?)
Entonces, en resumen, una vez que tengamos monitores y sistemas operativos de sincronización variable, lo único que nos detendrá será la edición de video, supongo. ¿Y la transmisión, ya que aparentemente CFR también es un gran problema para eso?
En caso de que te lo estés preguntando, las molestas velocidades de fotogramas no enteros de 29,970 (en realidad 30000/1001) y 23,976 (en realidad 24000/1001, de telecine) son culpa del color NTSC. busque 1.001 . Si tan solo hubieran estado dispuestos a arriesgarse a que algunos equipos en blanco y negro no pudieran manejar una frecuencia adicional del 0,1 % para la subportadora de audio, el mundo se habría ahorrado esta tontería. (Creo que vi otro artículo en alguna parte que hacía que pareciera que muchos conjuntos hubieran estado bien, pero no estaban seguros de la compatibilidad perfecta. Wikipedia hace que suene como si ningún conjunto hubiera manejado una subportadora de audio 0.1% más alta. IDK the hechos.)
Sin embargo, las velocidades de cuadro molestas 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 esas cosas? Es similar a 1920x540p60, pero con un estúpido desplazamiento vertical entre los campos pares e impares que requiere mucho cálculo en el extremo receptor para que no se vea horrible.
Para su caso de uso, sugeriría absolutamente archivar en el FPS nativo. No deseche ninguna información eliminando fotogramas. No duplique cuadros y haga que sus archivos sean más grandes (o haga que su codificador h.264 dedique más tiempo a notar los duplicados y generar un cuadro lleno de macrobloques de salto que solo toman 20 bytes para el cuadro completo).
En el futuro, cuando esperemos que todos tengamos pantallas de sincronización libre que puedan reproducir cualquier velocidad de fotogramas, ¡querrá deshacer su pullup a 24 fps para que su video se reproduzca sin problemas! O si freesync de alguna manera no se pone de moda, o si la pantalla que viene después de las pantallas LCD es CFR, entonces probablemente la conversión de velocidad se realice mejor en el momento de la reproducción de todos modos. No es que 24 fps se reproduzca perfectamente en un monitor de 60 Hz. (No noto visualmente el hecho de que algunos cuadros se muestran en 3 * 1/60 mientras que otros se muestran en 2 * 1/60, pero es cierto).
Si tiene problemas con Quicktime, entonces IDK. Tal vez asegúrese de que Handbrake esté creando archivos con la velocidad de fotogramas correcta establecida en el flujo de bits h.264, así como en el contenedor. (Sí, los encabezados h.264 aparentemente pueden almacenar una velocidad de fotogramas, aparte de lo que dice el contenedor. Consulte los documentos para mkvmerge --fix-bitstream-timing-information. E intente usarlo --default-duration 16fpspara crear un archivo mkv. Luego, mux eso de nuevo a mp4 y vea si eso soluciona Quicktime? ) O tal vez haya una manera de hacerlo con herramientas mp4 en primer lugar. Ver por ejemplo: https://askubuntu.com/questions/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 lo interpreta mal, bien podría ser culpa de Quicktime. O tal vez la culpa de Handbrake por hacer mal el archivo. Por lo general, solo uso ffmpeg directamente, porque soy un ninja de la línea de comandos.
Por historia, 24 FPS provienen de kino (películas). La película estaba en fotocinta 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 son de la misma fuente, pero en realidad el doble). En realidad, la televisión en Europa era de 50 FPS, pero la mitad de los cuadros, están entrelazados.
30 FPS provienen de la frecuencia de alimentación en EE. UU., 60 Hz (60 FPS provienen de la misma fuente, pero en realidad el doble). En realidad, la televisión en EE. UU. Era de 60 FPS, pero la mitad de los cuadros, están entrelazados.
16 FPS no está tan extendido como estándar para fines profesionales, por lo que tal vez esa sea la razón por la que no se usa en la mayoría del software actual. Además, tal FPS no "suavizará" lo suficiente el movimiento rápido. Tengo una idea loca de cómo puedes hacer que 16 FPS coincidan mejor con 24. Solo tienes que obtener todos los fotogramas pares e impares y hacer algo así como el promedio entre ellos :)
Para responder a su pregunta, sí, generalmente puede codificar un archivo de video en cualquier velocidad de cuadro que desee. (Aunque algunos programas pueden optar por limitarlo para hacerlo más simple). La pregunta es: ¿el formato de entrega que elija lo admitirá y el dispositivo de reproducción lo admitirá?
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 quiero admitir pueden manejarlo. De lo contrario, probablemente usaría un software compatible con el 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) compatible con el flujo óptico generará fotogramas intermedios en función del movimiento de los objetos del vídeo. En lugar de repetir un cuadro o incluso combinar 2 cuadros, genera un nuevo cuadro que generalmente es bastante similar a lo que realmente se habría grabado si hubiera grabado a la velocidad de cuadro de salida.
Existen estándares de video de cine y televisión establecidos a los que se ajustan la mayoría de los videos. Una computadora a menudo puede mostrar video de múltiples velocidades de cuadro, sin embargo, algunos televisores pueden tener problemas con velocidades de cuadro extrañas, ya que pueden usar circuitos de visualización más especializados. Incluso en una computadora, es posible que la velocidad de fotogramas que se muestra en realidad no coincida con la del archivo de video, según las frecuencias de actualización admitidas por el monitor.
Sí, las velocidades de cuadro no enteras se muestran de manera diferente. Se conocen como drop frame y existen principalmente por razones heredadas. Cuando se reproduce, se elimina un cuadro (del código de tiempo) de vez en cuando para compensar la diferencia de tiempo y los cuadros se distribuyen a la velocidad adecuada para mantener la fluidez. Sin embargo, esto tiene más que ver con cosas de sincronización en formatos heredados y con la prevención de 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 es posible que no se reproduzca bien en algunos televisores. (E incluso en aquellos en los que funciona, es probable que realice un despliegue en tiempo real para ajustarse a una velocidad de fotogramas estándar, mientras que un despliegue realizado con anticipación probablemente resulte en una mejor calidad).
Su pregunta no se trata de tarifas comunes, se trata de qué tarifa debe usar para digitalizar su película. La respuesta: debe usar la tarifa original si es posible, porque desea conservar la fuente en forma digital. Luego puede convertirlo a cualquier velocidad de cuadro que necesite para verlo. En los viejos tiempos, normalmente significaba 24 fps para presentaciones teatrales y 29,97 fps, entrelazados para video. Hoy en día puedes hacer casi cualquier cosa, pero necesitas tener una buena fuente, que coincida con el original lo más limpiamente posible.
Ahora cuando tenemos VRR (G-sync y Freesync) no es tanto problema (funciona en mpv de forma nativa), pero sí, hay frame rates estándar usados por DCI (Digital Cinema Initiatives), es 24000/1001, 24.000, 60000/1001, 60.000, 50 PAL entrelazado, 30000/1001, 30.000, 120.000 y 120000/1001. Eso es todo. Ahora, por supuesto, debe conservar la velocidad de fotogramas original. Pero, ¿estás seguro de que realmente es lo que crees que es?
Algunas otras notas. Primero, 48 fps se está volviendo más popular y común gracias a El Hobbit y ahora al soporte de YouTube para la velocidad de fotogramas. En segundo lugar, 30 fps suele ser en realidad 29,97 fps y 60 suele ser alrededor de 59,94.
nelson