Ci sono solo alcune frequenze di fotogrammi video standard?

Nei moderni video digitali, un file video può essere contrassegnato con una frequenza di fotogrammi arbitraria? Oppure sono supportati solo alcuni frame rate specifici? Per "moderno" intendo i giocatori software come Quicktime, VLC, Roku, console di gioco, ecc. Sono curioso sia di sapere che cosa dicono gli standard video stessi sia di frame rate sia di ciò che effettivamente funziona in pratica.

Comprendo che 24 fps, 25 fps, 30 fps, 50 fps e 60 fps sono standard ampiamente supportati. HandBrake offre anche 5, 10 e 15; sono quelle opzioni standard? Posso usare qualsiasi numero FPS che desidero? E i tassi non interi come 23.976 e 29.97; sono effettivamente trattati in modo diverso da software rispetto a 24 e 30? Vedo anche riferimenti a "frame rate variabile" nei flussi H.264; funziona davvero e, in tal caso, cosa lo utilizza?

La mia domanda specifica è quale sia il modo migliore per codificare alcune scansioni di pellicole da 8 mm. La fonte è di 16 fps, lo standard di pellicola da 8 mm. In questo momento sto raddoppiando ogni altro fotogramma per portarlo a 24 fps che funziona bene, ma mi chiedo perché non posso semplicemente contrassegnare il video come 16 fps. FWIW Ho prodotto file H.264 MP4 con freno a mano a 15 fps e ho scoperto che venivano riprodotti correttamente solo in VLC. Mac Quicktime li ha riprodotti troppo velocemente, probabilmente a 24 fps.

Esistono diversi frame rate "standard", ma ce ne sono così tanti che il supporto di framerate arbitrari è più semplice rispetto al supporto specifico di molti frame specifici. Ciò è particolarmente vero per i lettori di software, come VLC.

Esiste sempre più supporto per i fps VARIABILI. (VFR, frame rate variabile). Questo è dove l'intervallo tra i fotogrammi all'interno dello stesso video non è una costante. Molti formati di file contenitore video (come Matroska ( .mkv) o MPEG-4 ( .mp4, strettamente correlati a quelli di Apple .mov)) non memorizzano nemmeno un numero FPS, ma piuttosto una base dei tempi (ad es. 1/30 di secondo) e quindi ogni fotogramma ha un timestamp come multiplo di tale base dei tempi. Accade solo che l'intervallo tra ciascun fotogramma sia uno o un piccolo numero intero di unità della base dei tempi in un video CFR (frame rate costante).

Le riprese di telecamere di sicurezza con frame quasi duplicati rilasciati sarebbero un ovvio caso d'uso per VFR. Anche più se viene compresso con un codec video semplicistico che non sfrutta bene la ridondanza temporale (con frame inter (p e b)). (giocaci con ffmpeg -vf mpdecimateper eliminare i frame near-dup. Usa -vsync 2se trasmetti a mp4, perché per qualche motivo non è il default per quel muxer, ma è per mkv.)

Un altro caso sono gli smartphone moderni. Ad esempio, la Moto G (2a generazione) di mio fratello registra video VFR. Riduce la frequenza dei fotogrammi quando il sensore necessita di più luce. Parte dell'output di mediainfo su un mp4 creato dal software del telefono, registrato al chiuso:

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 riproduzione di un singolo flusso video VFR non è difficile. Il software appena pronto per la visualizzazione del fotogramma successivo, dorme fino a quando non dovrebbe essere visualizzato, quindi si sveglia e lo visualizza.

Le cose diventano un po 'più complicate se si tiene conto del fatto che gli umani possono vedere i fotogrammi video solo quando un monitor li visualizza. I monitor VFR esistono, ma sono ancora rari. (google per g-sync freesync).

La modifica dell'immagine visualizzata mentre viene scansionata sul monitor provoca una brutta lacerazione del video (comunemente visto quando si gioca con vsync disattivato). Ciò limita un giocatore a cambiare l'immagine visualizzata a 50 o 60Hz. (I CRT supportano frequenze vrefresh arbitrarie, all'interno di un intervallo, ma è complicato cucinare le modalità con tutti i tempi corretti, quindi la maggior parte delle persone ha usato solo alcune frequenze di aggiornamento fisse. E ora le persone hanno LCD che supportano comunque solo una frequenza di aggiornamento fissa. Fino a i monitor freesync sono comunque molto più diffusi. Non vedo davvero l'ora. :)

Pertanto, con frequenze di fotogrammi video che non sono un multiplo o un fattore della frequenza di aggiornamento del monitor, alcuni fotogrammi verranno visualizzati per 3 aggiornamenti del monitor e alcuni per 2, ad esempio, anche se il video deve essere a 25FPS costanti (su un monitor da 60Hz).

Le cose si complicano quando si desidera lavorare con più clip e sfumare tra loro, Picture-in-Picture o vari altri effetti. Scrivere un software di editing video è MOLTO più semplice se si può presumere che tutte le clip abbiano un nuovo fotogramma contemporaneamente. (Forzano l'allineamento della clip per scattare a interi fotogrammi).

Questo è il motivo per cui gli NLE (come kdenlive o pitivi, per scegliere esempi casuali di software libero), hanno maggiori probabilità di forzarti a un FPS fisso e di rilasciare / duplicare i frame dai clip per farli corrispondere a quel frame rate. Il CFR scelto può essere arbitrario, ma in genere deve essere costante per l'intero "progetto".

(Gli NLE funzionano completamente con i clip VFR e producono in questo caso un output VFR?)

Quindi, in sintesi, una volta che abbiamo monitor e sistemi operativi a sincronizzazione variabile, l'unica cosa che ci trattiene sarà l'editing video, immagino. E la radiodiffusione, poiché a quanto pare anche il CFR è un grosso problema per questo?

Nel caso ti stia chiedendo, i fastidiosi frame rate non interi di 29.970 (in realtà 30000/1001) e 23.976 (in realtà 24000/1001, da telecine) sono colpa del colore NTSC. cerca 1.001 . Se solo fossero stati disposti a rischiare che alcuni set B&W non fossero in grado di gestire una frequenza aggiuntiva dello 0,1% per la sottoportante audio, al mondo sarebbe stata risparmiata questa assurdità. (Penso di aver visto un altro articolo da qualche parte che lo faceva sembrare più simile a molti set sarebbe andato bene, ma non erano sicuri della perfetta compatibilità. Wikipedia lo fa sembrare che nessun set avrebbe gestito una sottoportante audio dello 0,1% più alta. IDK fatti.)

Tuttavia, i fastidiosi frame rate sono uno dei peccati minori della trasmissione. È davvero un intreccio che è stata la rovina della qualità video su schermi moderni (tutti i pixel accesi contemporaneamente) e che non sarebbe cambiato. Non capisco ancora perché l'interlacciamento sia stato mantenuto per l'HDTV. Perché è stato mai definito 1080i60, invece di usare 720p60 per ottenere la stessa risoluzione temporale per sport e cose? È simile a 1920x540p60, ma con uno stupido offset verticale tra i campi pari e dispari che richiede un sacco di calcoli sull'estremità di ricezione per renderlo non orribile.

modificare:

Per il tuo caso d'uso, suggerirei assolutamente di archiviare l'FPS nativo. Non gettare alcuna informazione facendo cadere i frame. Non duplica i frame e ingrandisci i tuoi file (o fai passare più tempo al tuo codificatore h.264 notando i duplicati e producendo un frame pieno di macroblocchi skip che richiede solo 20 byte per l'intero frame).

In futuro, quando speriamo che tutti abbiamo schermi freesync in grado di riprodurre qualsiasi framerate, vorrai annullare il tuo pullup a 24fps in modo che il tuo video venga riprodotto in modo più fluido! O se il freesync in qualche modo non prende piede, o il display che viene dopo LCD è CFR, allora la conversione della velocità è probabilmente meglio se eseguita al momento della riproduzione. Non è che i 24fps vengano riprodotti perfettamente anche su un monitor a 60Hz. (Non noto visivamente il fatto che alcuni fotogrammi vengono visualizzati per 3 * 1 / 60th mentre alcuni vengono visualizzati per 2 * 1 / 60th, ma è vero).

Se riscontri problemi con Quicktime, IDK. Forse assicurati che Handbrake stia creando file con il giusto framerate impostato nel bitstream h.264, così come nel contenitore. (Sì, le intestazioni h.264 possono apparentemente memorizzare una frequenza dei fotogrammi, separata da ciò che dice il contenitore. Vedi i documenti per mkvmerge --fix-bitstream-timing-information. E provare a usarlo con --default-duration 16fpsper creare un file mkv. Quindi reindirizzarlo a mp4 e vedere se questo risolve il problema di quicktime? ) O forse c'è un modo per farlo con gli strumenti mp4 in primo luogo. Vedi ad esempio: /ubuntu/370692/how-to-change-the-framerate-of-a-video-without-reencoding

Posso garantire che il frame rate arbitrario mp4 è valido e che anche il framerate variabile mp4 è valido. Se Quicktime non funziona correttamente, potrebbe essere colpa di Quicktime. O forse colpa del freno a mano per aver sbagliato il file. Di solito uso direttamente ffmpeg, perché sono un ninja della riga di comando.

Per rispondere alla tua domanda: sì, puoi generalmente codificare un file video in qualsiasi frame rate desideri. (Sebbene alcuni software possano scegliere di limitare l'utente per semplificare il software.) La domanda è: il formato di consegna scelto lo supporterà e il dispositivo di riproduzione lo supporterà?

Se hai una pellicola da 8 mm a 16 fps, la codificherei a 16 fps se sapessi che i dispositivi di riproduzione che volevo supportare potevano gestirla. In caso contrario, probabilmente utilizzerei un software che supportava il flusso ottico (a volte chiamato stima del movimento) per codificarlo a 24 fps, che è probabilmente il frame rate più vicino che potrebbe essere supportato dal software di codifica, dal software di decodifica e dalla maggior parte dell'hardware di riproduzione.

Il software (o hardware) che supporta il flusso ottico genererà fotogrammi intermedi in base al movimento degli oggetti nel video. Invece di ripetere un fotogramma o persino di fondere 2 fotogrammi, genera un nuovo fotogramma che di solito è abbastanza vicino a quello che sarebbe stato effettivamente registrato se si fosse registrato alla frequenza dei fotogrammi di output.

Secondo la storia, 24 FPS provengono da Kino (film). Il film era in fototape e la velocità è stata selezionata per rendere più fluidi i movimenti.

25 FPS provengono dalla frequenza di alimentazione in Europa, 50 Hz (50 FPS provengono dalla stessa fonte, ma in realtà raddoppiano). In realtà la TV in Europa era di 50 FPS ma a mezzo frame, sono intrecciati

30 FPS provengono dalla frequenza di alimentazione negli Stati Uniti, 60 Hz (60 FPS provengono dalla stessa fonte, ma in realtà raddoppiano). In realtà la TV negli Stati Uniti era di 60 FPS ma a metà fotogrammi, sono intrecciati

16 FPS non è così diffuso come standard per scopi professionali, quindi forse è per questo che non è in uso nella maggior parte dei software attuali. Inoltre, tali FPS non "livelleranno" abbastanza il movimento rapido. Ho una pazza idea di come puoi fare 16 FPS per abbinare meglio 24. Le juts ottengono tutti i fotogrammi pari e dispari e fanno qualcosa di simile tra loro :)

Esistono standard video televisivi e cinematografici conformi alla maggior parte dei video. Un computer può spesso visualizzare video da più framerate, tuttavia alcuni televisori potrebbero avere problemi con i frame rate della palla dispari in quanto potrebbero utilizzare circuiti di visualizzazione più specializzati. Anche su un computer, la frequenza dei fotogrammi effettivamente visualizzata potrebbe non corrispondere a quella del file video, a seconda delle frequenze di aggiornamento supportate del monitor.

Sì, i frame rate non interi vengono visualizzati in modo diverso. Sono conosciuti come drop frame ed esistono principalmente per motivi legacy. Durante la riproduzione, un fotogramma viene eliminato (dal codice temporale) ogni tanto per compensare la differenza di tempo e i fotogrammi vengono distribuiti alla velocità corretta per mantenerlo uniforme. Questo ha più a che fare con la sincronizzazione di cose in formati legacy e prevenire problemi di sincronizzazione che non sono più rilevanti.

È possibile utilizzare frame rate non standard e dovrebbe essere riprodotto correttamente sui PC, ma non sarà conforme al video standard per cose come Bluray e potrebbe non essere riprodotto correttamente su alcuni televisori. (E anche su quelli su cui funziona, probabilmente farà un pull down in tempo reale per conformarsi a un frame rate standard, dove come un pulldown fatto in anticipo si tradurrebbe probabilmente in una migliore qualità.)

La tua domanda non riguarda le tariffe comuni, ma le tariffe da utilizzare per digitalizzare il tuo film. La risposta: se possibile, è necessario utilizzare la velocità originale, poiché si desidera preservare la fonte in forma digitale. Quindi è possibile convertirlo in qualsiasi frame rate necessario per la visualizzazione. Nei tempi antichi, di solito significava 24 fps per la presentazione teatrale e 29,97 fps, intrecciati per il video. Oggi puoi fare quasi tutto, ma devi avere una buona fonte, che corrisponda all'originale nel modo più pulito possibile.

Alcune altre note. Innanzitutto, 48 fps stanno diventando più popolari e comuni grazie a The Hobbit e ora il supporto di YouTube per il framerate. In secondo luogo, 30 fps sono in genere 29,97 fps e 60 sono in genere circa 59,94.