Esistono diversi modi per ottenere un AVI "non compresso" ffmpeg, ma sospetto che in realtà tu voglia dire "senza perdita di dati". Entrambi i termini hanno un bel po 'di spazio nelle loro definizioni, come vedrai.
Ancorerò questa discussione con la versione HD a 720p di Big Buck Bunny , dal momento che è un video liberamente disponibile che tutti possiamo testare e ottenere risultati che possiamo confrontare. La velocità dati grezzi di video 1280 × 720p a 24 fps è quasi uguale a quella del tuo obiettivo dichiarato 1024 × 768 a 29,97 fps, quindi i miei risultati dovrebbero essere una guida abbastanza buona alle velocità dati che puoi aspettarti dal tuo filmato.
Elenco automatico delle opzioni disponibili
Il seguente comando POSIX¹ ti dà un elenco che per lo più² corrisponde a ciò che discutiamo di seguito:
$ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image'
Potresti voler eseguire quel comando sul tuo computer per vedere cosa supporterà la tua build di FFmpeg. FFmpeg è raramente realizzato con ogni possibile codificatore abilitato.
Ora parliamo di quelle opzioni.
Completamente non compresso
Se la tua definizione di "non compresso" è la forma il video è in diritto prima che sia rivolto a fotoni da un display digitale, il più vicino vedo nella ffmpeg -codecslista sono -c:v r210, r10k, v410, v308, ayuve v408. Questi sono tutti sostanzialmente la stessa cosa, differiscono solo per profondità di colore , spazio colore e alfa canale di supporto.
R210 e R10K sono 4: 4: 4 RGB a 10 bit per componente (bpc), in modo che entrambi richiedono circa 708 Mbit / s per 720p nel mio test. (Sono circa ⅓ TB all'ora, amici!)
Questi codec racchiudono entrambi i componenti di colore 3 × 10 bit per pixel in un valore di 32 bit per facilitare la manipolazione da parte dei computer, che amano le dimensioni di potenza di 2. L'unica differenza tra questi codec è la fine della parola a 32 bit in cui si trovano i due bit inutilizzati. Questa banale differenza è senza dubbio perché provengono rispettivamente da aziende concorrenti, Blackmagic Design e AJA Video Systems .
Sebbene si tratti di codec banali, probabilmente dovrai scaricare i codec Blackmagic e / o AJA per riprodurre i file utilizzandoli sul tuo computer. Entrambe le aziende vi permetterà di scaricare i loro codec senza aver comprato il loro hardware di prima, poiché sanno che si può avere a che fare con i file prodotti da clienti che fare avere alcuni dei loro hardware.
V410 è essenzialmente solo la versione YUV di R210 / R10K; le loro velocità di trasmissione dei dati sono identiche. Questo codec può tuttavia codificare più velocemente, poiché ffmpegè più probabile che abbia un percorso di conversione dello spazio colore accelerato tra lo spazio colore dei frame di input e questo spazio colore.
Non posso raccomandare questo codec, tuttavia, poiché non sono stato in grado di riprodurre il file risultante in alcun software che ho provato, anche con i codec AJA e Blackmagic installati.
V308 è la variante a 8 bpc di V410, quindinel mio testarriva a 518 Mbit / s . Come con V410, non sono stato in grado di riprodurre questi file nel normale software di riproduzione video.
AYUV e V408 sono essenzialmente la stessa cosa di V308, tranne per il fatto che includono un canale alfa, che sia necessario o no! Se il tuo video non usa la trasparenza, ciò significa che paghi la penalità di dimensione dei codec R210 / R10K a 10 bpc sopra senza ottenere il vantaggio dello spazio colore più profondo.
AYUV ha una sola virtù: è un codec "nativo" in Windows Media, quindi non richiede software speciali per giocare.
V408 dovrebbe essere nativo di QuickTime allo stesso modo, ma il file V408 non potrebbe essere riprodotto in QuickTime 7 o 10 sul mio Mac.
Quindi, mettendo tutto insieme, se i tuoi PNG sono nominati frame0001.pnge così via:
$ ffmpeg -i frame%04d.png -c:v r10k output.mov
...or... -c:v r210 output.mov
...or... -c:v v410 output.mov
...or... -c:v v408 output.mov
...or... -c:v v308 output.mov
...or... -c:v ayuv output.avi
Si noti che ho specificato AVI nel caso di AYUV, poiché è praticamente un codec solo per Windows. Gli altri potrebbero funzionare in QuickTime o AVI, a seconda dei codec presenti sul tuo computer. Se un formato contenitore non funziona, provare l'altro.
I comandi sopra - e anche quelli sotto - presumono che i tuoi frame di input abbiano già le stesse dimensioni che desideri per il tuo video di output. In caso contrario, aggiungi qualcosa di simile -s 1280x720al comando, prima del nome del file di output.
RGB compresso, ma anche senza perdite
Se, come sospetto, intendi effettivamente "senza perdita di dati" anziché "non compresso", una scelta molto migliore di una qualsiasi delle precedenti è Apple QuickTime Animation , tramite-c:v qtrle
So che hai detto che volevi un AVI, ma il fatto è che probabilmente dovrai installare un codec su un computer Windows per leggere uno dei formati di file basati su AVI menzionati qui, mentre con QuickTime c'è una possibilità che il video l'app di tua scelta sa già come aprire un file di animazione QuickTime. (Il codec AYUV sopra è l'unica eccezione di cui sono a conoscenza, ma la sua velocità di dati è terribilmente alta, solo per ottenere il vantaggio di AVI.)
ffmpegverrà qtrleinserito in un contenitore AVI per te, ma il risultato potrebbe non essere molto compatibile. Nei miei test, QuickTime Player si preoccuperà un po 'di questo file, ma lo riprodurrà. Stranamente, però, VLC non lo riprodurrà, anche se si basa in parte su ffmpeg. Attaccherei ai contenitori QT per questo codec.
Il codec di animazione QuickTime utilizza uno schema RLE banale , quindi per le animazioni semplici, dovrebbe fare così come Huffyuv di seguito. Più colori in ogni fotogramma, più si avvicinerà al bit rate delle opzioni completamente non compresse sopra. Nei miei test con Big Buck Bunny, sono stato in grado di ffmpegdarmi un file da 165 Mbit / s in modalità RGB 4: 4: 4, tramite -pix_fmt rgb24.
Sebbene questo formato sia compresso, fornirà valori di pixel di output identici ai file di input PNG, per lo stesso motivo per cui la compressione senza perdita di PNG non influisce sui valori di pixel.
L' ffmpegimplementazione di Animazione QuickTime supporta anche -pix_fmt argb, che ti dà 4: 4: 4: 4 RGB, il che significa che ha un canale alfa. In un modo molto approssimativo, è l'equivalente di QuickTime di -c:v ayuvcui sopra. A causa della compressione senza perdita, tuttavia, si arriva a soli 214 Mbit / s , meno di rate la velocità di trasmissione dati di AYUV senza perdita di qualità o funzionalità.
Esistono varianti di Animazione QuickTime con meno di 24 bit per pixel, ma sono utilizzate al meglio per stili di animazione progressivamente più semplici. ffmpegsembra supportare solo uno degli altri formati definiti dalla specifica -pix_fmt rgb555be, ovvero RGB big-endian da 15 bpp. È tollerabile per alcuni video e va bene per la maggior parte delle catture di screencast e animazioni semplici. Se riesci ad accettare la decimazione dello spazio colore, potresti trovare attraente la sua velocità dati di 122 Mbit / s .
Mettendo tutto questo insieme:
$ ffmpeg -i frame%04d.png -c:v qtrle -pix_fmt rgb24 output.mov
...or... -pix_fmt argb output.mov
...or... -pix_fmt rgb555be output.mov
Senza perdite: il trucco YUV
Ora, la cosa su RGB e 4: 4: 4 YUV è che queste codifiche sono molto facili da elaborare per i computer, ma ignorano un fatto sulla visione umana, che è che i nostri occhi sono più sensibili alle differenze in bianco e nero rispetto alle differenze di colore .
I sistemi di archiviazione e consegna video quindi utilizzano quasi sempre meno bit per pixel per le informazioni sul colore che per le informazioni sulla luminanza. Questo si chiama chroma subsampling . Gli schemi più comuni sono 4: 2: 0 e 4: 2: 2.
La velocità dati di 4: 2: 0 YUV è solo del 50% superiore a quella per i video non compressi in bianco e nero (solo Y) e ½ la velocità dati di 4: 4: 4 RGB o YUV.
4: 2: 2 è una specie di punto a metà strada tra 4: 2: 0 e 4: 4: 4. È il doppio della velocità dati del video solo Y e ⅔ la velocità dati di 4: 4: 4.
A volte vedi anche 4: 1: 1, come nel vecchio standard della videocamera DV . 4: 1: 1 ha la stessa velocità dati non compressa di 4: 2: 0, ma le informazioni sul colore sono disposte in modo diverso.
Il punto di tutto ciò è che se stai iniziando con un file H.264 4: 2: 0, ricodificandolo in RGB non compresso 4: 4: 4 non avrai assolutamente nulla su YUV compresso senza perdita di 4: 2: 0. Questo è vero anche se sai che il tuo flusso di lavoro è altrimenti 4: 4: 4 RGB, poiché è una conversione banale; l'hardware e il software video eseguono tali conversioni al volo di routine.
Hai davvero bisogno di 4: 4: 4 quando fai capolino dai pixel o stai facendo cambiamenti di colore a livello di pixel sul video e devi preservare i valori esatti dei pixel. Il lavoro sugli effetti visivi (VFX) è più facile da svolgere con un formato di pixel 4: 4: 4, ad esempio, quindi le case VFX di fascia alta sono spesso disposte a tollerare le velocità di dati più elevate richieste.
Senza perdite: scelte di codec
Una volta che ti apri ai codec YUV con la decimazione dei colori, anche le tue opzioni si aprono. ffmpegha molti codec effettivamente senza perdita di dati .
Huffyuv
L'opzione più ampiamente compatibile è Huffyuv . Puoi ottenerlo tramite -c:v huffyuv.
Il codec Windows Huffyuv originale supporta solo due formati di pixel: RGB24 e YUV 4: 2: 2. (In realtà, supporta due versioni di YUV 4: 2: 2, che differiscono solo nell'ordine dei byte sul disco.)
Le versioni precedenti del codec FFmpeg Huffyuv non includevano il supporto RGB24, quindi se lo provi e FFmpeg ti dice che utilizzerà il yuv422pformato pixel, devi eseguire l'aggiornamento.
FFmpeg ha anche un codec variante Huffyuv chiamato FFVHuff, che supporta YUV 4: 2: 0. Questa variante non è compatibile con il codec Windows DirectShow Huffyuv, ma dovrebbe aprirsi in qualsiasi software basato su libavcodec, come VLC.
RGB24 - RGB 4: 4: 4 è essenzialmente la stessa cosa dell'opzione di spazio colore RGB24 di QuickTime Animation. I due codec differiranno leggermente nella compressione per un determinato file, ma saranno generalmente vicini.
È essenzialmente la stessa cosa della modalità YUV 4: 4: 4 utilizzata dall'opzione V308 sopra. La differenza di spazio colore non fa alcuna differenza pratica, poiché la conversione dello spazio colore è facile da eseguire in tempo reale.
Grazie alla compressione senza perdita di Huffyuv, sono stato in grado di ottenere un video di prova da comprimere a circa 251 Mbit / s in modalità RGB24, con identica qualità visiva a quella che otterresti da V308 o AYUV. Se AVI è un must assoluto per te, l'installazione del codec Huffyuv è probabilmente meno dolorosa del pagamento del costo della velocità dati 3 × di AYUV.
YUV 4: 2: 2 - Questa modalità è molto più pratica per i video rispetto a RGB24, il che è senza dubbio il motivo per cui gli ffmpegsviluppatori hanno scelto di implementarla per prima. Come ci si aspetterebbe dalla riduzione teorica discussed discussa sopra, il mio file di test codificato a 173 Mbit / s . È praticamente esattamente ⅔, se si tiene conto del fatto che la traccia audio è rimasta invariata tra questi due test.
YUV 4: 2: 0 : questa opzione consente di decimare le informazioni sul colore più di 4: 2: 2, riducendo la velocità dei dati a 133 Mbit / s nei miei test.
Mettendo tutto questo insieme:
$ ffmpeg -i frame%04d.png -c:v huffyuv -pix_fmt rgb24 output.avi
...or... -pix_fmt yuv422p output.avi
...or... -c:v ffvhuff -pix_fmt yuv420p output.avi
Anche se il ffvhuffcodec viene impostato automaticamente su 4: 2: 0 mentre scrivo questo, e in effetti supporta solo quel formato di pixel nella versione di rilascio che sto usando, questo sta cambiando , quindi dovresti includere il flag nel caso in cui questa impostazione predefinita cambi.
Ut Video
Un'opzione più recente nello stesso spirito di Huffyuv e FFVHuff è Ut Video . Come Huffyuv, esiste un codec video Windows che significa che qualsiasi programma Windows in grado di riprodurre un film può riprodurre video utilizzando questo codec con il codec installato. A differenza di Huffyuv, esiste anche un codec video per Mac, quindi non sei limitato al software basato su FFmpeg o libavcodecper leggere questi file su Mac.
Questo codec è molto flessibile in termini di spazi colore, quindi fornirò solo alcuni esempi di spazi colore comuni:
4: 4: 4 RGB via -f avi -c:v utvideo -pix_fmt rgb24fornisce un'uscita di 178 Mbit / sec
4: 4: 4 YUV via -f avi -c:v utvideo -pix_fmt yuv444pfornisce un'uscita di 153 Mbit / sec
4: 2: 2 YUV tramite -f avi -c:v utvideo -pix_fmt yuv422pfornisce output a 123 Mbit / sec
4: 2: 0 YUV via -f avi -c:v utvideo -pix_fmt yuv420pfornisce un'uscita di 100 Mbit / sec
Sospetto che 4: 4: 4 YUV faccia meglio di 4: 4: 4 RGB in questo test nonostante questi due siano tecnicamente equivalenti perché il video sorgente è 4: 2: 0 YUV, quindi organizzare i dati in formato YUV consente una migliore compressione senza perdita di dati raggruppando i canali U e V parzialmente ridondanti nel file.
FF video codec 1
Un'altra opzione interessante in questo spazio è proprio FFmpeg FFV1codec . Questo è principalmente usato come un codec di archiviazione piuttosto che un codec di riproduzione o modifica, ma poiché così tanto software è basato sulla libavcodeclibreria alla base di FFmpeg o può essere attaccato libavcodectramite strumenti come ffdshow, può esserti utile comunque.
Per impostazione predefinita, ffmpegmanterrai lo spazio colore dei tuoi file di input quando utilizzi un codec flessibile come FFV1, in modo che se lo carichi uno dei file MP4 Big Buck Bunny ufficiali, che utilizzano 4: 2: 0 YUV, ecco cosa otterrai a meno che tu non dia una -pix_fmtbandiera a ffmpeg. Ciò si traduce in un file di output a 63 Mbit / s .
Se imponi a FFV1 di utilizzare uno spazio colore YUV 4: 4: 4 -pix_fmt yuv444p, la dimensione del file sale solo a 86 Mbit / sec , ma in questo caso non ci sta acquistando nulla poiché stiamo codificando da un originale 4: 2: 0 . Tuttavia, se si inserisce invece un set di PNG, come nella domanda originale, è probabile che il file di output utilizzi lo spazio colore bgrao bgr0, che sono solo riarrangiamenti degli spazi colore argbe rgb24indicati in precedenza.
H.264 senza perdite
Un'altra alternativa interessante è Lossless H.264 . Questa è praticamente una cosa solo x264 al momento della stesura di questo documento, ma quelli che usano FFmpeg sul lato della codifica probabilmente useranno altri software che includono anche libx264sul lato della decodifica , come VLC.
Il modo più semplice per ottenere un tale file è:
$ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4
La -qp 0bandiera è la chiave: valori più alti danno una compressione con perdita. (Puoi anche dare -crf 0per ottenere lo stesso effetto.)
Come con FFV1, ffmpegproverò a indovinare il miglior spazio colore di output dato lo spazio colore di input, quindi per confronto con i risultati sopra, ho eseguito più passaggi di codifica sul file sorgente Big Buck Bunny con diversi spazi colore:
yuv444p : Questo è ciò che ffmpegsceglie quando gli dai un flusso PNG RGB, come nella domanda originale, e genera un file 44 Mbit / sec con il nostro file di test
yuv422p : Questo è simile allo spazio colore predefinito per Huffyuv, ma in questo caso otteniamo un file da 34 Mbit / sec , un bel risparmio!
yuv420p : questa è l'impostazione predefinita per gli MP4 ufficiali di Big Buck Bunny con cui sto testando e genera un file di 29 Mbit / sec .
Ricorda che stai commerciando molta compatibilità per ottenere file di dimensioni così ridotte. Ecco perché non mi sono nemmeno preoccupato di riporlo in un contenitore AVI o MOV. È così strettamente legato a x264 che potresti anche usare il suo tipo di contenitore standard (MP4). Puoi anche usare qualcosa come Matroska per questo.
Puoi aggiungere un po 'di quel bit rate per un tempo di codifica più veloce aggiungendo -preset ultrafast. Ciò ha aumentato il bit rate del mio file di test a 44 Mbit / s in modalità YUV 4: 2: 2, ma è stato codificato molto più velocemente, come promesso. I documenti sostengono che -preset veryslowvale anche la pena, ma ha comportato un tempo di codifica molto più lungo risparmiando solo un po 'di spazio; Non posso raccomandarlo.
Altri
ffmpegsupporta anche la modalità di sola decodifica per Lagarith e la modalità di sola codifica per Lossless JPEG . Questi due codec sono in realtà un po 'simili e dovrebbero dare file un po' più piccoli di Huffyuv con la stessa qualità. Se gli ffmpegsviluppatori aggiungessero mai la codifica Lagarith, sarebbe una forte alternativa a Huffyuv. Non posso raccomandare Lossless JPEG, tuttavia, poiché non gode di un ampio supporto di decodifica.
Percettivamente senza perdita: o, probabilmente, puoi cavartela con qualche perdita
Poi ci sono i codec che sono percettivamente senza perdita. A meno che tu non stia sbirciando i pixel, quasi sicuramente non puoi dire che questi danno risultati visivi diversi rispetto ai due precedenti gruppi. Rinunciando all'idea di un cambiamento assolutamente nullo tra il sensore di acquisizione video e il dispositivo di visualizzazione, si acquista un notevole risparmio:
Apple ProRes :-c:v proresoppure-c:v prores_ks- ProRes è un codec basato sul profilo, il che significa che ci sono diverse varianti, ognuna con una qualità diversa rispetto allo spazio:
ProRes 4444 codifica il nostro video di prova usando solo 114 Mbit / s , ma è di qualità VFX . Attualmente ci sono tre diversiprores*codec in FFmpeg, maprores_kssupportasoloProRes 4444, mentre scrivo questo, tramite l'-profile:v 4444opzione.
Se ti stai chiedendo perché dovresti preoccuparti di utilizzare ProRes 4444 su Lossless H.264, si tratta di compatibilità, velocità di decodifica, prevedibilità e canale alfa.
ProRes 422 consente di risparmiare ancora più spazio, richiedendo solo 84 Mbit / s per dare un risultato che si può dire da ProRes 4444 solo facendo capolino dai pixel. A meno che non sia necessario il canale alfa offerto da ProRes 4444, probabilmente non c'è motivo di insistere su ProRes 4444.
ProRes 422 è un concorrente più vicino all'opzione Lossless H.264 di cui sopra, poiché nessuno dei due supporta un canale alfa. Ti consigliamo di tollerare la velocità in bit più elevata di ProRes se hai bisogno di compatibilità con le app video professionali Apple, un sovraccarico della CPU inferiore per la codifica e decodifica o velocità in bit prevedibili. Quest'ultimo è importante con gli encoder hardware, ad esempio. D'altra parte, se riesci a far fronte ai problemi di compatibilità di Lossless H.264, avrai la possibilità di utilizzare lo spazio colore 4: 2: 0, che non è un'opzione da nessun profilo ProRes.
Tutti e tre gli encoder ProRes in FFmpeg supportano il profilo ProRes 422, quindi l'opzione più semplice è quella di utilizzare -c:v prores, piuttosto che -c:v prores_ks -profile hq, o dipendere dalla funzione di profilo automatico prores_ksper fare la cosa giusta.
Esistono profili ProRes ancora più parsimoniosi, ma sono pensati per video SD o come proxy per file a risoluzione piena.
Il problema principale con ProRes è che non ha ancora un ampio supporto al di fuori dei mondi video Apple e Pro.
Il DNxHD di Avid è un codec simile a ProRes, ma non è legato al mondo dei video pro di Apple. Avid offre codec scaricabili liberamente per Windows e Macintosh e FFmpeg ora lo supporta tramite-c:v dnxhd.
Poiché DNxHD è un codec basato su profilo come ProRes, si sceglie il profilo dall'insieme predefinito e indica al codec quali dimensioni, frequenza e bit rate del frame usare. Per il file di test di Big Buck Bunny, il -b:v 60Mprofilo è più appropriato. Non sorprende che il file risultante sia di circa 59 Mbit / s .
MJPEG a bassa perdita :-vcodec mjpeg -qscale:v 1- Questo è molto più comune del JPEG senza perdita di dati. In realtà, questo era un tempo un codec di editing video abbastanza comune, ed è ancora spesso usato da cose come videocamere di streaming in rete. Tutta quella storia significa che è facile trovare software che la supporti.
Aspettati una variabilità piuttosto ampia delle velocità dei dati da questo codec. Un test che ho appena fatto qui mi ha dato 25 Mbit / s per video a 720p. È una compressione abbastanza alta da rendermi nervoso per la perdita, ma mi è sembrato abbastanza buono. Basandomi solo sulla velocità dei dati, direi che è probabilmente alla pari della qualità a 12 Mbit / s MPEG-2 o 6 Mbit / s H.264.
Mettendo tutto questo insieme:
$ ffmpeg -i frame%04d.png -c:v prores_ks -profile:v 4444 output.mov
...or... -c:v prores_ks -profile:v hq output.mov
...or... -c:v prores output.mov
...or... -c:v dnxhd -b:v 60M output.mov
...or... -c:v mjpeg -qscale:v 1 output.avi
La linea di fondo su questi metodi è che a meno che tu non stia facendo qualcosa di molto impegnativo, "abbastanza buono" è davvero abbastanza buono.
Note a piè di pagina e digressioni
Il comando dovrebbe funzionare come indicato su Linux, macOS, BSD e Unix. Se sei su Windows, puoi ottenere una riga di comando POSIX tramite Cygwin o WSL .
Esistono diversi motivi per cui l'elenco prodotto da quel comando non corrisponde perfettamente all'insieme di codec che ho scelto di discutere sopra:
Il secondo ha lo grepscopo di filtrare codificatori inappropriati come quelli bmpche non sono codec "video", nonostante siano stati taggati Vin questo elenco. Anche se tecnicamente potresti probabilmente mettere molti di questi in un contenitore come AVI, MP4 o MKV per ottenere un video a file singolo, quel file probabilmente non sarà leggibile da nulla se non da un programma basato su ffmpego libavcodec.
Ci sono alcune eccezioni a questo, come quella che -f avi -c:v ljpegdà qualcosa che potresti chiamare "Lossless MJPEG", ma di regola non siamo interessati a mettere qui molti file di immagini fisse in un contenitore A / V per fare un film. Vogliamo codec video ampiamente riconosciuti qui, non inganno semantico.
Il comando attualmente non riesce a filtrare alcuni codificatori inappropriati come GIF perché non sono attualmente descritti ffmpeg -codecsnell'output come bitmapo nei imageformati di file.
La GIF è un caso interessante: supporta più frame di immagini in un singolo file GIF con informazioni di temporizzazione per la riproduzione in movimento, ma per diversi motivi, è del tutto inappropriato alla nostra discussione qui.
Alcune delle opzioni che vengono visualizzati sono obsoleti o mai veramente avuto molta trazione, come ad esempio flashsv, dirace snow, quindi non vale la pena discuterne sopra.
Alcune delle opzioni in quell'elenco sono pensate solo per l'uso in pipeline tra ffmpegistanze o tra ffmpegun altro programma, come rawvideoe wrapped_avframe, e quindi non sono appropriate per i nostri scopi qui.
Verso la fine della discussione di cui sopra, esplogo con giudizio un po 'l'ambito della domanda per includere alcune opzioni con perdita selezionate con cura, in modo che non passino il primo grepfiltro nel comando sopra.
ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.mov.