FFMPEG / libx264: come specificare un frame rate variabile ma con un massimo?

Invece di fornire una frequenza di fotogrammi fissa a FFMPEG / libx264 (-r / -framerate), vorrei specificare una frequenza di fotogrammi variabile con un valore MASSIMO e consentire a libx264 di ridurre la frequenza di fotogrammi come ritiene opportuno. L'idea qui è quella di ottenere una compressione extra quando c'è qualcosa come un fermo fotogramma esteso (che succede MOLTO nei miei video sorgente).

Mi rendo conto che un frame MPEG predittivo o bidirezionale si comprimerà davvero bene, ma è anche possibile che il frame rate di origine sia inferiore a quello che intendo transcodificare (eventualmente con conseguente flusso BIGGER!).

Frustrato dal fatto che non avessi trovato una risposta, stavo per rispondere almeno alle domande degli altri su come abilitare l' output VFR (non V B R) da FFMPEG.

La risposta a questa è l' -vsyncopzione dal nome strano . Puoi impostarlo su alcune opzioni diverse, ma quella che desideri è '2' o vfr. Dalla pagina man:

-vsync parametro
Metodo di sincronizzazione video. Per motivi di compatibilità, i vecchi valori possono essere specificati come numeri. I valori aggiunti di recente dovranno essere sempre indicati come stringhe.

• 0, passthrough

  • Ogni fotogramma viene passato con il suo timestamp dal demuxer al muxer.

• 1, cfr

  • I frame verranno duplicati e rilasciati per ottenere esattamente il frame rate costante richiesto.

• 2, vfr

  • I frame vengono passati con il loro timestamp o rilasciati in modo da impedire a 2 frame di avere lo stesso timestamp.

• far cadere

  • Come passthrough ma distrugge tutti i timestamp, facendo sì che il muxer generi nuovi timestamp basati sul frame rate.

• -1, auto

  • Scegli tra 1 e 2 a seconda delle capacità del muxer. Questo è il metodo predefinito.

Si noti che i timestamp possono essere ulteriormente modificati dal muxer, dopo questo. Ad esempio, nel caso in cui l'opzione di formattazione avoid_negative_ts sia abilitata.

Con -map è possibile selezionare da quale flusso devono essere presi i timestamp. Puoi lasciare video o audio invariati e sincronizzare i flussi rimanenti con quelli invariati.

Tuttavia, non ho abbastanza reputazione per pubblicare un commento per rispondere a quella "sotto-domanda" che tutti sembrano avere. Ma avevo alcune idee di cui non ero sinceramente molto ottimista ... Ma la prima che ho provato ha funzionato . Così.

Devi semplicemente combinare l' -vsync 2opzione con l' -r $maxfpsopzione, ovviamente dove sostituisci $maxfpscon il framerate massimo che desideri! E FUNZIONA! Non duplica i frame da un file sorgente, ma eliminerà i frame che causano il superamento del frame rate massimo del file!

Per impostazione predefinita, sembra che -r $maxfpsda solo causi la duplicazione / eliminazione dei frame per ottenere un framerate costante e -vsync 2da solo provoca il pull dei frame direttamente senza influenzare realmente i valori PTS.

Non ero ottimista riguardo a questo perché sapevo già che lo -r $maxfpsmette a un framerate costante. Onestamente, mi aspettavo un errore o che obbedisse a qualunque cosa fosse la prima o l'ultima o qualunque cosa. Il fatto che faccia esattamente quello che volevo mi fa abbastanza piacere con gli sviluppatori di FFMPEG.

Spero che questo ti aiuti, o qualcun altro in seguito se non hai più bisogno di saperlo.

Vorrei specificare un frame rate variabile con un valore MASSIMO, e consentire a libx264 di ridurre il frame rate come meglio crede. L'idea qui è quella di ottenere una compressione extra quando c'è qualcosa come una cornice fissa estesa

A mio avviso, ciò può essere probabilmente in un modo relativamente goffo, ma è indesiderabile per alcune ragioni complesse e controintuitive

Anche se un flusso x264 ha un framerate (s), il frame rate è più un problema a livello di contenitore che uno di codec.

In una codifica VFR passthrough, ci sarà essenzialmente un file di testo che dettaglia la frequenza dei fotogrammi rispetto a quali frame / tempi e, nella codifica di una sorgente, una funzione come tcfile-in o tcfile-out passa i timestamp alla codifica , per mappare le posizioni delle tariffe e mantenere il video soggettivamente coerente dalla fonte.

L'idea a basso framerate è logica, ma non funziona per diversi motivi. Sebbene x264 sia compatibile con VFR con alcune funzionalità, non credo che esista una funzione di analisi che varierà il framerate rispetto al movimento al fine di ridurre le dimensioni del file (in modo analogo ai numerosi controlli bitrate).

Anche la fonte è un problema: le fonti VFR per impostazione predefinita manterranno la loro variabilità del frame, ma apparentemente codificare un file CFR a bitrate variabile (una buona idea a volte, specialmente quando è necessaria la telecine) produrrà semplicemente lo stesso CFR.

Ciò significa che probabilmente dovresti riscrivere il bitrate a mano (ovvero i timestamp di scene lente combinate nel file) o ricorrere a un algoritmo di decimazione del frame come dup, dedup ed esattaDedup per avisynth . Se il tuo video ha un movimento estremamente basso, alcuni fotogrammi (anche la metà?) Verrebbero eliminati. Il problema è che questi algoritmi non sono avanzati e non fanno buone scelte con filmati "di vita reale" su ciò che contribuirà alla codifica migliore.

Inoltre, la rimozione di fotogrammi che contengono elementi come i fotogrammi I e B riduce la quantità di dettagli disponibili nel tempo, il che fa apparire il movimento "irregolare" e può interferire con gli altri parametri video di base e causare artefatti come l'aliasing.

E a causa del modo in cui funzionano i quantizzatori, x264 riduce effettivamente il bitrate in modo sproporzionato ulteriormente in queste scene di movimento lento. A meno che tu non abbia una presentazione di immagini identiche, ci sarà movimento (se solo grano e altri artefatti) e ci sarà una perdita di qualità che non sarebbe visibile senza drastiche modifiche al bitrate.

E infine, la ragione per cui non ci sono molte opzioni per fare ciò che vuoi è che x264 è davvero bravo a gestire il bitrate usando solo la compressione temporale (registrando le modifiche in frame parziali). Passare a 1/2 framerate non ridurrà la dimensione del file a metà; Il 10% è probabilmente un guadagno realistico che ci si aspetta dal movimento lento o dall'animazione.

Quindi, in breve, eliminare il bitrate delle scene statiche farà molto poco per le dimensioni del file, ma aggiungerà una serie di problemi di qualità e sincronizzazione, per non parlare dell'incompatibilità con il software di editing video.

Se vuoi provare un decimatore, potresti essere in grado di limitare il nuovo frame rate massimo usando le opzioni dei livelli , ognuna delle quali ha una risoluzione massima e framerate. Sfortunatamente, dovresti probabilmente lavorare a risoluzioni molto basse per ottenere il tipo di frame rate che desideri, usando i profili. Torna a modificare le tariffe a mano, interamente o per correggere i frame rate che ritieni siano troppo alti. Ad ogni modo, ci vorrà la giocoleria per mantenere il suono sincronizzato con i nuovi framerate se vengono apportate modifiche dopo il processo di codifica quando il file tc viene conservato.

L'aspetto positivo è che passare il tempo a ottimizzare le numerose impostazioni di bitrate produrrà molto di più in termini di gestione delle dimensioni dei file e migliorerà la qualità del video, piuttosto che causare complicazioni per un piccolo guadagno. Preservare l'FPS originale è probabilmente la migliore idea a meno che tu non stia mirando a standard di trasmissione o multimediali. I lettori sono in grado di riprodurre bitrate variabili (a differenza degli editor) e maggiore è il numero di fotogrammi nel video, più fluida è la riproduzione e forse minore è la dimensione del file, a causa di minori cambiamenti nel movimento tra i fotogrammi.

Ecco una raccolta di collegamenti a informazioni sugli standard e discussioni nel forum che dovrebbero aiutare con questo aspetto confuso della codifica:

- strumenti di decimazione avisynth

- switch fps e -r
- x264 Generale (file tc, fps)
- standard dei file timecode
- Livelli e profili
- Riepilogo delle impostazioni CFR / VFR breve e chiaro (sezione "framerate")

doom9, videohelp, ecc. discussioni teoriche
1 2 3 4 5 6 7