Come creare un AVI non compresso da una serie di 1000 di immagini PNG usando FFMPEG

Come posso creare un AVI non compresso da una serie di 1000 di immagini PNG utilizzando FFMPEG?

Ho usato questo command per convertire un file input.avi in una serie di frame PNG:

 ffmpeg -y -i input.avi -an -vcodec png -s 1024x768 pic%d.png` 

Ora devo sapere come fare un video AVI non compresso da tutti quei frame PNG. Ho provato questo:

 ffmpeg -i pic%d.png -y -f avi -b 1150 -s 1024x768 -r 29.97 -g 12 -qmin 3 -qmax 13 -ab 224 -ar 44100 -ac 2 test.avi 

Ma il video risultante perde una grande qualità rispetto all'originale AVI.

Ci sono diversi modi per get un AVI "non compresso" da ffmpeg , ma sospetto che tu effettivamente significa "senza perdita". Entrambi i termini hanno un bel po 'di stanza di wiggle nelle loro definizioni, come vednetworking.

Sto per ancorare questa discussione con la versione HD 720p di Big Buck Bunny , dato che è un video liberamente disponibile che tutti possiamo testare e get risultati che possiamo confrontare. Il tasso di dati grezzo del video da 1280 × 720p a 24 fps è quasi uguale a quello del tuo dichiarato 1024 × 768 a 29,97 fps objective, quindi i miei risultati dovrebbero essere una guida abbastanza buona per i tassi di dati che ci si aspetta sul tuo filmato.

Elenco automatico delle opzioni disponibili

Il seguente command POSIX¹ fornisce un elenco che corrisponde principalmente a quello che viene descritto di seguito:

 $ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image' 

Potresti voler eseguire quel command sulla propria macchina per vedere che cosa supporterà la tua build di FFmpeg. FFmpeg è raramente costruito con each ansible encoder abilitato.

Ora discutiamo di quelle opzioni.

Completamente non compresso

Se la tua definizione di "non compresso" è la forma in cui il video è in giusto prima di essere girato a fotoni da un display digitale, il più vicino che vedo nell'elenco dei ffmpeg -codecs sono -c:v r210 , r10k , v410 , v308 , ayuv e v408 . Queste sono tutte sostanzialmente la stessa cosa, che differiscono solo nella profondità di colore , nello spazio colore e nel supporto al canale alfa .

  • R210 e R10K sono 4: 4: 4 RGB a 10 bit per componente (bpc), quindi entrambi richiedono circa 708 Mbit / s per 720p durante i miei test. (Si tratta di & frac13; TB all'ora, amici!)

    Questi codec compongono entrambi i componenti di colore a 3 × 10 bit per pixel in un valore a 32 bit per facilitare la manipolazione da parte dei computer, come le size di potenza di 2. L'unica differenza tra questi codec è che fine della parola a 32 bit i due bit inutilizzati sono accesi. Questa differenza banale è senza dubbio perché provengono da aziende concorrenti, Blackmagic Design e AJA Video Systems rispettivamente.

    Anche se questi sono codici banali, probabilmente dovrai scaricare i codec Blackmagic e / o AJA per riprodurre i file utilizzandoli sul tuo computer. Entrambe le aziende ti permettono di scaricare i propri codec senza aver acquistato il loro hardware in primo luogo, in quanto sappiamo che si tratti di file prodotte da clienti che dispongono di alcuni dei loro hardware.

  • V410 è essenzialmente la versione YUV di R210 / R10K; le loro tariffe sono identiche. Questo codec può comunque essere codificato più velocemente, perché ffmpeg maggiori probabilità di avere un path 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 ho potuto get il file risultante per giocare in qualsiasi software che ho provato, anche con i codec AJA e Blackmagic installati.

  • V308 è la variante 8 bpc di V410, quindi viene a 518 Mbit / s durante i miei test. Come per V410, non sono riuscito a riprodurre questi file nel normale software di riproduzione video.

  • AYUV e V408 sono essenzialmente la stessa cosa di V308, tranne che includono un canale alfa, se necessario o no! Se il tuo video non utilizza la trasparenza, significa che paghi la dimensione dei codec di 10 bpc R210 / R10K sopra senza get il vantaggio dello spazio colore più profondo.

    AYUV ha una virtù: è un codec "nativo" in Windows Media, quindi non richiede un software speciale da riprodurre.

    V408 dovrebbe essere nativo a QuickTime allo stesso modo, ma il file V408 non sarebbe in grado di riprodurre in QuickTime 7 o 10 sul mio Mac.

Quindi, mettendo insieme tutto questo, se i tuoi PNG sono chiamati frame0001.png e 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 

Notare che ho specificato AVI nel caso di AYUV, dato che è praticamente un codec solo per Windows. Gli altri possono funzionare in QuickTime o AVI, a seconda di quali codecs sono presenti sulla macchina. Se un formato del contenitore non funziona, prova l'altro.

I comandi sopra elencati – e quelli inferiori – suppongono che i frame di input siano già la stessa dimensione desiderata per il video in output. In caso contrario, aggiungi qualcosa come -s 1280x720 al command, prima del nome del file di output.

Compresso RGB, ma anche senza perdita

Se, come sospetto, in realtà significa "lossless" invece di "non compresso", una scelta molto migliore di qualsiasi altra è l' animation Apple QuickTime , tramite -c:v qtrle

So che hai detto che volevi un AVI, ma il fatto è che probabilmente dovrai installare un codec su una macchina Windows per leggere uno qualsiasi dei formati di file AVI qui citati, mentre con QuickTime c'è una possibilità che il video app di tua scelta già sa come aprire un file di animation QuickTime. (Il codec AYUV sopra è l'exception solitaria che io conosco, ma la sua velocità di trasmissione è terribilmente alta, solo per get il beneficio di AVI.)

ffmpeg farà roba qtrle in un contenitore AVI per te, ma il risultato potrebbe non essere molto ampiamente compatibile. Durante i miei test, QuickTime Player smentirà un po 'di questo file, ma lo riproduce. Stranamente, però, la VLC non lo giocherà, anche se è basato in parte su ffmpeg . Vorrei attaccare ai contenitori QT per questo codec.

Il codec di animation QuickTime utilizza un banale schema RLE , per cui per le animazioni semplici, dovrebbe fare circa così come Huffyuv di seguito. Più colors in each fotogramma, più si avvicinerà al bit rate delle opzioni completamente non compresse sopra. Nel mio test con Big Bunny Buck, ho potuto get ffmpeg per farmi un file da 165 Mbit / s in modalità RGB 4: 4: 4, via -pix_fmt rgb24 .

Anche se questo formato è compresso, darà valori identici di pixel di output ai file di input PNG, per la stessa ragione che la compressione lossless di PNG non influenza i valori dei pixel.

L'implementazione di QuickTime Animazione ffmpeg support anche -pix_fmt argb , che ottiene 4: 4: 4: 4 RGB, il che significa che ha un canale alfa. In una maniera molto ruvida, è l'equivalente di QuickTime a -c:v ayuv , menzionato in precedenza. A causa della compressione lossless, però, arriva a soli 214 Mbit / s , less di & frac13; il tasso di dati di AYUV con zero perdita di qualità o caratteristiche.

Ci sono varianti di QuickTime Animation con less di 24 bit per pixel, ma sono utilizzabili meglio per gli stili di animation progressivamente più semplici. ffmpeg sembra supportre solo uno degli altri formati definiti dalla specifica, -pix_fmt rgb555be , il che significa 15 bpp big-endian RGB. È tollerabile per alcuni video e va bene per la maggior parte delle acquisizioni di screencast e delle semplici animazioni. Se è ansible accettare la decimazione dello spazio colore, è ansible che la velocità di trasmissione di 122 Mbit / s sia estrema.

Mettendo insieme tutto questo:

 $ 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 

Effettivamente senza perdita: il trucco YUV

Ora, la cosa su RGB e 4: 4: 4 YUV è che queste codifiche sono molto semplici per elaborare 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 sisthemes di archiviazione e distribuzione dei video quindi utilizzano quasi sempre bit per pixel per informazioni di colore rispetto alle informazioni sulla luminanza. Questo si chiama sottofinizione di cromatura . I programmi più comuni sono 4: 2: 0 e 4: 2: 2.

La velocità di trasmissione di 4: 2: 0 YUV è solo del 50% superiore rispetto al video non compresso in bianco e nero (solo Y) e ½ la velocità di trasmissione di 4: 4: 4 RGB o YUV.

4: 2: 2 è una sorta di metà tra 4: 2: 0 e 4: 4: 4. È il doppio del tasso di dati del solo video Y e & frac23; il tasso di dati è di 4: 4: 4.

A volte vedi anche 4: 1: 1, come nel vecchio standard della telecamera DV . 4: 1: 1 ha la stessa velocità di printing non compressa come 4: 2: 0, ma le informazioni sui colors sono disposte in modo diverso.

Il punto di tutto questo è che se si inizia con un file H.264 di 4: 2: 0, la codifica a 4: 4: 4 non compressa RGB non acquista assolutamente niente oltre il 4: 2: 0 YUV senza perdite di compressione. Questo è vero anche se sai che il tuo stream di lavoro è altrimenti 4: 4: 4 RGB, dato che è una conversione banale; video hardware e software fanno tali conversioni in volo in modo ordinario.

In realtà hai bisogno solo di 4: 4: 4 quando stai guardando il pixel o stai effettuando modifiche di colore a livello pixel nel video e devi mantenere valori pixel esatti. L'effetto Visual Effects (VFX) è più facile da fare con un formato di 4: 4: 4 pixel, per esempio, quindi le case high-end VFX sono spesso disposte a tollerare le velocità di trasmissione più elevate che richiede.

Effettivamente perdita: Codec Choices

Una volta che si apre su codec YUV con decimazione a colors, le opzioni si aprono anche. ffmpeg ha molti codecs efficaci senza perdite .

Huffyuv

L'opzione più ampia è Huffyuv . Si ottiene questo via -c:v huffyuv .

Il codec originale Huffyuv di Windows support solo due formati di pixel: RGB24 e YUV 4: 2: 2. (In realtà, support due sapori di YUV 4: 2: 2, che differiscono solo nell'ordine dei byte sul disco.)

Le versioni precedenti del codec di Huffyuv FFmpeg non includevano il supporto RGB24, quindi se provalo e FFmpeg ti dice che userà il formato di pixel yuv422p , devi aggiornare.

FFmpeg ha anche un codec di variante Huffyuv chiamato FFVHuff, che support YUV 4: 2: 0. Questa variante non è compatibile con il codec di Windows DirectShow Huffyuv, ma dovrebbe aprire in qualsiasi software basato su libavcodec , ad esempio VLC.

  • RGB24 – RGB 4: 4: 4 è sostanzialmente la stessa cosa dell'opzione spaziale RGB24 di QuickTime Animation. I due codec diventeranno un po 'in compressione per un determinato file, ma in genere saranno vicini.

    È anche 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, in quanto la conversione dello spazio colore è facile da fare in tempo reale.

    A causa della compressione senza perdita di Huffyuv, ho potuto get un video di prova da compresso a circa 251 Mbit / s in modalità RGB24, con identica qualità visiva di quello che si otterrebbe da V308 o AYUV. Se AVI è un must assoluto per te, l'installazione del codec Huffyuv è probabilmente less doloroso di quello di pagare il costo di 3 × dei dati di AYUV.

  • YUV 4: 2: 2 – Questa modalità è molto più pratica per il video di RGB24, senza dubbio perché gli sviluppatori di ffmpeg hanno scelto di attuarlo in primo luogo. Come ci si aspetterebbe dal teorico & frac23; riduzione discussa sopra, il mio file di prova codificato a 173 Mbit / s . Questo è piuttosto esattamente & frac23 ;, se si tiene conto del fatto che la traccia audio non è stata modificata tra questi due test.

  • YUV 4: 2: 0 – Questa opzione decimizza le informazioni di colore più di 4: 2: 2, lasciando cadere la velocità di dati a 133 Mbit / s durante i miei test.

Mettendo insieme tutto questo:

 $ 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 codec di ffvhuff predefinito a 4: 2: 0 mentre scrivo, e support solo il formato di pixel nella versione di rilascio che sto usando, questo sta cambiando , pertanto dovresti includere la bandiera nel caso in cui questo cambiamento di default.

Ut Video

Un'opzione più recente nello stesso spirito di Huffyuv e FFVHuff è Ut Video . Come Huffyuv, c'è un codec video di 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, c'è anche un codec video Mac, per cui non si è limitati a software basato su FFmpeg o libavcodec per leggere questi file su Mac.

Questo codec è molto flessibile in termini di spazi di colore, quindi mi darò solo alcuni esempi di spazi comuni di colore:

  • 4: 4: 4 RGB via -f avi -c:v utvideo -pix_fmt rgb24 fornisce -f avi -c:v utvideo -pix_fmt rgb24 178 Mbit / sec

  • 4: 4: 4 YUV via -f avi -c:v utvideo -pix_fmt yuv444p fornisce -f avi -c:v utvideo -pix_fmt yuv444p da 153 Mbit / sec

  • 4: 2: 2 YUV via -f avi -c:v utvideo -pix_fmt yuv422p fornisce -f avi -c:v utvideo -pix_fmt yuv422p 123 Mbit / sec

  • 4: 2: 0 YUV via -f avi -c:v utvideo -pix_fmt yuv420p fornisce -f avi -c:v utvideo -pix_fmt yuv420p 100 Mbit / sec

Sospetto che il 4: 4: 4 YUV sia migliore di 4: 4: 4 RGB in questo test, nonostante questi due siano tecnicamente equivalenti perché il video sorgente è 4: 2: 0 YUV, per cui la disposizione dei dati in formato YUV consente una migliore compressione lossless raggruppando i file U e V parzialmente ridondanti nel file.

FF video codec 1

Un'altra opzione interessante in questo spazio è il proprio codec FFV1 FFmpeg. Questo è utilizzato principalmente come codec di archiviazione piuttosto che un codec di riproduzione o di modifica, ma poiché tanto software è basato sulla libavcodec support FFmpeg o può essere collegato a libavcodec tramite strumenti come ffdshow , può essere utile a te comunque.

Per impostazione predefinita, ffmpeg conserverà lo spazio colore dei file di input quando si utilizza un codec flessibile come FFV1, in modo che se lo si alimenta uno dei file Big Buck Bunny MP4, che utilizzano 4: 2: 0 YUV, è quello che devi uscire a less che non dia un flag di -pix_fmt a ffmpeg . Ciò comport un file di output di 63 Mbit / s .

Se forzate FFV1 per utilizzare uno spazio colore YUV da 4: 4: 4 con -pix_fmt yuv444p , la dimensione del file sale solo a 86 Mbit / sec , ma in questo caso non ci acquista nulla in quanto codiciamo da un 4: 2 : 0 originale. Tuttavia, se si alimenta in un insieme di PNG invece, come nella domanda originale, il file di output è probabile che utilizzi lo spazio colore bgra o bgr0 , che sono solo i riordinamenti degli spazi di colore argb e rgb24 sopra.

H.264 senza perdita

Un'altra interessante alternativa è Lossless H.264 . Ciò è praticamente una cosa solo di x264 di questa scrittura, ma coloro che utilizzano FFmpeg sul lato di codifica sono probabilmente utilizzando altri software che includono anche libx264 sul lato di decodifica , come VLC.

Il modo più semplice per get un file è:

 $ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4 

Il flag -qp 0 è la chiave: i valori più alti danno la compressione lossy. (Puoi anche dare -crf 0 per get lo stesso effetto.)

Come per FFV1, ffmpeg cercherà di get il miglior spazio colore in output data lo spazio colore di input, per cui, per confronto con i risultati sopra, ho eseguito più passaggi di codifica sul file sorgente Big Buck Bunny con diversi spazi di colore:

  • yuv444p : questo è ciò che ffmpeg sceglie quando gli assegni un stream di PNG RGB, come nella domanda originale e si traduce in un file di 44 Mbit / sec con il nostro file di prova

  • yuv422p : Questo è simile allo spazio di colore predefinito per Huffyuv, ma in questo caso abbiamo un file 34 Mbit / sec , un risparmio molto!

  • yuv420p : Questo è l'impostazione predefinita per i MP4 ufficiali di Big Buck Bunny che stanno provando con un file di 29 Mbit / sec .

Attenzione che si sta commerciando molto compatibilità per get tali size di file di piccole size. Ecco perché non mi preoccupavo nemless di provare a immagazzinare in un contenitore AVI o MOV. È così strettamente legato a x264 che potresti anche utilizzare il suo tipo di contenitore standard (MP4). Potresti anche usare qualcosa come Matroska per questo.

È ansible scambiare un po 'di quel bit rate per un tempo di codifica più veloce aggiungendo -preset ultrafast . Questo ha aumentato il bit rate del file di prova a 44 Mbit / s in modalità YUV 4: 2: 2, ma codificato molto più velocemente, come promesso. I docs affermano che anche il " -preset veryslow vale la pena, ma ha provocato un tempo di codifica molto più lungo, pur risparmiando un po 'di spazio; Non posso consigliarlo.

Altri

ffmpeg support anche la modalità di decodifica solo per la modalità Lagarith e la codifica solo per il JPEG Lossless . 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 sviluppatori di ffmpeg aggiungono sempre la codifica di Lagarith, sarebbe una valida alternativa a Huffyuv. Non posso raccomandare il JPEG senza perdita, però, in quanto non godono di un ampio supporto di decodifica.

Perceptually Lossless: Oppure, si può probabilmente get via con qualche perdita

Poi ci sono i codec che sono percepiti senza perdite. A less che tu non sia il picco di pixel, quasi certamente non puoi sapere che questi forniscono risultati visivi diversi dai precedenti due gruppi. Abbandonando l'idea di un cambiamento assolutamente zero tra il sensore di cattura video e il dispositivo di visualizzazione, si acquistano notevoli risparmi:

  • ProRes di Apple : -c:v prores o -c:v prores_ks – ProRes è un codec a base di profili, il che significa che esistono diverse varianti, ognuna con una diversa qualità rispetto allo spazio:

    • Il ProRes 4444 codifica il nostro video di prova usando solo 114 Mbit / s , eppure è la qualità VFX . Ci sono attualmente tre diversi prores* in FFmpeg, ma solo prores_ks support ProRes 4444, come scrivo, tramite l'opzione -profile:v 4444 .

      Se vi state chiedendo perché si preoccupasse di andare con ProRes 4444 su H.264 senza perdita, si arriva alla compatibilità, alla velocità di decodifica, alla prevedibilità e al canale alfa.

    • ProRes 422 consente di risparmiare ancora di più spazio, richiedendo solo 84 Mbit / s per dare un risultato da ProRes 4444 solo da pixel-peeping. A less che non sia necessario il canale alfa offerto da ProRes 4444, non c'è probabilmente alcun motivo per insistere su ProRes 4444.

      ProRes 422 è un concorrente più vicino all'opzione Lossless H.264 sopra, in quanto non support un canale alfa. Vorresti tollerare il tasso di bit superiore di ProRes se hai bisogno di compatibilità con le app video Apple pro, un basso livello di CPU per la codifica e la decodifica o tassi di bit prevedibili. Quest'ultimo è importnte per esempio con encoder hardware. D'altra parte, se si è in grado di affrontare i problemi di compatibilità di Lossless H.264, è ansible utilizzare lo spazio colore 4: 2: 0, che non è un'opzione di qualsiasi profilo ProRes.

      Tutti e tre i codificatori ProRes in FFmpeg supportno 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 funzionalità di profilo automatico di prores_ks da fare la cosa giusta.

    Ci sono ancora profili parsimoni di ProRes, ma sono destinati sia per video SD, sia come proxy per i file full-res.

    Il problema principale con ProRes è che non ha ancora ampio supporto al di fuori dei mondi Apple e pro video.

  • Avid's DNxHD è un codec simile a ProRes, ma non è legato al mondo pro video Apple. Avid offre codecs liberamente scaricabili per Windows e Macintosh e FFmpeg lo support via -c:v dnxhd .

    Poiché DNxHD è un codec basato su un profilo come ProRes, si sceglie il profilo dal set predefinito e che indica il codec quale dimensione del fotogramma, la frequenza del fotogramma e il bitrate da utilizzare. Per il file di prova Big Bunny Buck, il profilo -b:v 60M è 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 di JPEG senza perdita. Infatti, questa era una volta un comune codec di modifica video, ed è ancora spesso utilizzato da cose come videocamere in streaming in networking. Tutta quella storia significa che è facile trovare software che lo supporti.

    Si aspetta una variablestà abbastanza larga nelle velocità di trasmissione da questo codec. Un test che ho fatto qui mi ha dato 25 Mbit / s per 720p video. Quella compressione è abbastanza alta da farmi nervosa della perdita, ma mi è sembrata piuttosto buona. Sulla base del tasso di dati da sola, direi che è probabilmente a par qualità per 12 Mbit / s MPEG-2 o 6 Mbit / s H.264.

Mettendo insieme tutto questo:

 $ 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 methods è che, a less che non si sta facendo qualcosa di molto esigente, "abbastanza bene" è veramente abbastanza buono.


Note a piè di pagina e digressioni

  1. Il command dovrebbe funzionare come dato su Linux, macOS, BSD e Unix. Se sei in Windows, puoi get una row di command POSIX tramite Cygwin o WSL .

  2. Ci sono diversi motivi per cui l'elenco prodotto da quel command non corrisponde perfettamente al set di codec che ho scelto per discutere sopra:

    • Il secondo grep serve a filtrare codificatori inappropriati come bmp che non sono codec "video", nonostante siano contrassegnati con V in questa list. Mentre tecnicamente si potrebbe probabilmente rovinare molti di questi in un contenitore come AVI, MP4 o MKV per get un video di un singolo file, quel file non sarà probabilmente leggibile da niente ma un programma basato su ffmpeg o libavcodec .

      Esistono poche eccezioni a questo proposito, come quella -f avi -c:v ljpeg fornisce qualcosa che potresti call "MJPEG senza perdita", ma di regola non siamo interessati a riempire molti file image in -f avi -c:v ljpeg / V container qui per fare un film. Vogliamo qui codec video ampiamente riconosciuti, non truffamenti semantici.

    • Il command non riesce a filtrare alcuni encoder inappropriati come GIF perché non sono attualmente descritti ffmpeg -codecs come formati bitmap o file di image .

      GIF è un caso interessante: support più fotogrammi di immagini in un unico file GIF con informazioni di temporizzazione per la riproduzione del movimento, ma per diversi motivi è completamente inappropriato per la nostra discussione qui.

    • Alcune delle opzioni mostrate sono obsolete o non hanno mai avuto molta trazione, come flashsv , flashsv e snow , quindi non vale la pena di discutere sopra.

    • Alcune delle opzioni di tale elenco sono intese solo per essere utilizzate in condutture tra istanze ffmpeg o tra ffmpeg e un altro programma, ad esempio rawvideo e wrapped_avframe , e quindi sono inadatti ai nostri scopi qui.

    • Vicino alla fine della discussione di cui sopra, ho diligentemente espandere la portta della domanda un po 'per includere alcune opzioni scrupolosamente scelte perdite, in modo da non passare il primo filter grep nel command di cui sopra.

Così ho finito per fare la mia risposta troppo a lungo.
TL: sintesi di DR: per la memorizzazione senza perdita di una sequenza di immagini, utilizzare libx264 o libx264rgb con -preset ultrafast -qp 0 . È quasi veloce come ffvhuff, con molto bitrate più bassi e decodifica più velocemente. huffyuv è molto più ampiamente supportto al di fuori di ffmpeg, ma non support molti formati pixel come ffvhuff . Quindi è un altro motivo per utilizzare h.264, supponendo che i tuoi altri strumenti possano gestire il profilo High 4:4:4 Predictive h.264 High 4:4:4 Predictive che x264 utilizza in modalità lossless. x264 può fare intra-solo se è necessario un accesso random veloce a canvasi arbitrari.

Attenzione a un bug di ffmpeg che riguarda libx264rgb quando si legge da una directory di immagini. (e chissà quali altri casi.) Prova la perdita di perdita nel tuo setup prima di utilizzare. (facile con ffmpeg -i in -pix_fmt rgb24 -f framemd5 sulla fonte e senza perdite di compressione))

modifica: utvideo codifica e decodifica abbastanza veloce ed è un codec molto più semplice di h.264. È fondamentalmente un huffyuv moderno, con supporto per colors più utili. Se hai mai un problema con h.264, prova ad utvideo successivamente per i file temporanei.

edit2: PNG come codec RGB sembra fare bene, alless sul rimorchio Sintel.

Vedere anche la mia risposta simile a una domanda simile: https://superuser.com/a/860335/20798

C'è molta informazione nella risposta di Warren Young su vari formati e codec raw. Penso che la risposta sarebbe più utile se fosse più breve, quindi sto facendo una nuova risposta. Se stai lavorando con un software che non support x264 o ffvhuff senza perdita, alcune di quelle informazioni sono probabilmente ancora utili.

La definizione più utile di "lossless" in questo context è che è ansible recuperare il bit-per-bit di input. Zero si preoccupa di un degrado di qualità dalla codifica video, a prescindere da quello che fai.

http://en.wikipedia.org/wiki/Chroma_subsampling

Idealmente, evitare conversioni di colors multipli. Gli errori di arrotondamento possono potenzialmente accumulare. Se aginetworking sul tuo video con i filtri che funzionano nello spazio dei colors RGB, mantenerlo RGB ha senso, a patto che i bitrate più alti non siano un problema. Probabilmente sarà in ultima analisi prodotta un video yuv 4:2:0 , ma mantenendo la risoluzione extra di chroma è potenzialmente utile, a seconda di quali filtri si intende applicare.

In entrambi i casi, x264 e ffvhuff senza perdita di peso supportno sia RGB che yuv 4:4:4 , 4:2:2 e 4:2:0 . Suggerisco x264, perché è veloce da decodificare. Se stai cercando di riprodurre video RGB HD in tempo reale, prova a opengl invece di xv, poiché xv sul mio sistema accetta solo l'ingresso yuv. mplayer stava prendendo tempo aggiuntivo per eseguire una conversione dello spazio colore.

Fonte per i seguenti test di encoder: https://media.xiph.org/ . https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz Hanno dimenticato di gzip i file y4m per il trailer sintel, quindi il tarball png è in realtà molto più piccolo.

 ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac \ -c:a copy -c:v libx264rgb -preset ultrafast -qp 0 \ frompng.sintel.264rgb.mkv 

per esempio

 [email protected]:/mnt/GP1TB/p/encoder-sample/sintel$ time ffmpeg -i 1080/sintel_trailer_2k_%4d.png -i sintel_trailer-audio.flac -c:a copy -c:v libx264rgb -preset ultrafast -qp 0 frompng.sintel.264rgb.mkv ffmpeg version N-67983-g2b358b4 Copyright (c) 2000-2015 the FFmpeg developers built on Jan 10 2015 05:32:37 with gcc 4.8 (Ubuntu 4.8.2-19ubuntu1) configuration: --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-ffserver --enable-libx264 --enable-libx265 --enable-libmp3lame --enable-libopus --enable-libwebp --enable-libvpx --disable-outdev=oss --disable-indev=oss --disable-encoder=vorbis --enable-libvorbis --enable-libfdk-aac --disable-encoder=aac --disable-decoder=jpeg2000 libavutil 54. 16.100 / 54. 16.100 libavcodec 56. 20.100 / 56. 20.100 libavformat 56. 18.100 / 56. 18.100 libavdevice 56. 3.100 / 56. 3.100 libavfilter 5. 7.100 / 5. 7.100 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 1.100 / 1. 1.100 libpostproc 53. 3.100 / 53. 3.100 Input #0, image2, from '1080/sintel_trailer_2k_%4d.png': Duration: 00:00:50.12, start: 0.000000, bitrate: N/A Stream #0:0: Video: png, rgb24, 1920x1080 [SAR 72:72 DAR 16:9], 25 fps, 25 tbr, 25 tbn, 25 tbc Input #1, flac, from 'sintel_trailer-audio.flac': Duration: 00:00:52.00, start: 0.000000, bitrate: 721 kb/s Stream #1:0: Audio: flac, 48000 Hz, stereo, s16 File 'frompng.sintel.264rgb.mkv' already exists. Overwrite ? [y/N] y No pixel format specified, rgb24 for H.264 encoding chosen. Use -pix_fmt yuv420p for compatibility with outdated media players. [libx264rgb @ 0x2770760] using SAR=1/1 [libx264rgb @ 0x2770760] using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle [libx264rgb @ 0x2770760] profile High 4:4:4 Predictive, level 4.0, 4:4:4 8-bit [libx264rgb @ 0x2770760] 264 - core 144 r2525+2 6a4fca8 - H.264/MPEG-4 AVC codec - Copyleft 2003-2014 - http://www.videolan.org/x264.html - options: cabac=0 ref=1 deblock=0:0:0 analyse=0:0 me=dia subme=0 psy=0 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=0 cqm=0 deadzone=21,11 fast_pskip=0 chroma_qp_offset=0 threads=3 lookahead_threads=1 sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 constrained_intra=0 bframes=0 weightp=0 keyint=250 keyint_min=25 scenecut=0 intra_refresh=0 rc=cqp mbtree=0 qp=0 Output #0, matroska, to 'frompng.sintel.264rgb.mkv': Metadata: encoder : Lavf56.18.100 Stream #0:0: Video: h264 (libx264rgb) (H264 / 0x34363248), rgb24, 1920x1080 [SAR 72:72 DAR 16:9], q=-1--1, 25 fps, 1k tbn, 25 tbc Metadata: encoder : Lavc56.20.100 libx264rgb Stream #0:1: Audio: flac ([172][241][0][0] / 0xF1AC), 48000 Hz, stereo (16 bit) Stream mapping: Stream #0:0 -> #0:0 (png (native) -> h264 (libx264rgb)) Stream #1:0 -> #0:1 (copy) Press [q] to stop, [?] for help frame= 1253 fps= 18 q=-1.0 Lsize= 834790kB time=00:00:51.96 bitrate=131592.5kbits/s video:830198kB audio:4575kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.002025% [libx264rgb @ 0x2770760] frame I:6 Avg QP: 0.00 size:612470 [libx264rgb @ 0x2770760] frame P:1247 Avg QP: 0.00 size:678787 [libx264rgb @ 0x2770760] mb I I16..4: 100.0% 0.0% 0.0% [libx264rgb @ 0x2770760] mb P I16..4: 50.3% 0.0% 0.0% P16..4: 12.0% 0.0% 0.0% 0.0% 0.0% skip:37.6% [libx264rgb @ 0x2770760] coded y,u,v intra: 71.1% 68.2% 70.0% inter: 22.8% 22.8% 23.2% [libx264rgb @ 0x2770760] i16 v,h,dc,p: 50% 48% 1% 1% [libx264rgb @ 0x2770760] kb/s:135693.94 

Notare che ho dimenticato di specificare -r 24 fps, in modo da non mantenere av sync con l'audio. (e il bitrate (ma non il numero di file) numbers saranno distriggersti, troppo. ffmpeg default a 25fps). La CPU in questa macchina è un 1 ° gen (conroe) core2duo 2.4GHz (E6600).

i risultati:

 4.5M sintel_trailer-audio.flac # this is muxed in to every mkv 948M 1080 # the directory of PNGs 940M /var/tmp/dl/sintel_trailer-1080-png.tar.gz 7434M sintel.y4m # yuv444, uncompressed. mplayer gets the colors wrong? 2342M qtrle.mkv # encode went at 16fps, so qtrle is slower and worse filesize 2105M sintel.huff.mkv # ffvhuff with default options, rgb pix fmt 1228M sintel.utvideo.mkv # muxed without audio, I should update the others this way 946M png-copy.mkv # -codec copy makes a MPNG stream. Use -codec png for non-png sources, but it won't make PNGs as small. Decodes very fast 824M lossy.prores_ks.mov # yuv444p10le extremely slow to encode (2.3fps), and worse bitrate. 816M frompng.sintel.264rgb.mkv 735M sintel.x264rgb.medium.nocabac.mkv # encode went at 3.3 fps instead of 18. Better gain than for live-action, though 626M sintel_trailer.rgb.lossless.veryslow.mkv # 1.1fps. With CABAC, 16 ref frames, etc. etc. 512M lossy.prores.mov # yuv422p10le, 12fps 341M sintel.yuv420.x264.lossless.mkv 21M lossy.rgb.crf26.preset=medium.mkv 13M lossy.yuv420.crf26.preset=medium.mkv # remember this is WITH 4.5MB audio 

Si noti che la mediainfo non conosce RGB h.264, ancora dice che i file sono YUV.

Controllare che sia stato veramente perduto:

 ffmpeg -i 1080/sintel_trailer_2k_%4d.png -f framemd5 png.framemd5 ffmpeg -i fromhuff.sintel.264rgb.mkv -an -sn -pix_fmt rgb24 -f framemd5 x264rgb.framemd5 diff -s *.framemd5 Files png.framemd5 and x264rgb.framemd5 are identical 

In questo modo è ansible recuperare l'input originale PNG in questo modo, cioè si potrebbe fare PNG con dati di image identici in esse.

Si noti il -pix_fmt rgb24 per il test x264. Il decodificatore h.264 di ffmpeg emette l'output gbrp (planare, non compresso), in modo che i bit siano gli stessi, ma in un ordine diverso. Il contenitore "framemd5" non impone alcun tipo di restrizione di formato, ma avrai solo lo stesso md5 se i bit sono disposti nello stesso modo. Ho appena guardato ciò che ffmpeg ha detto che stava usando per un pix fmt quando ho alimentato PNGs, quindi usato come arg per -pix_fmt per decodificare. Per inciso, questa è la ragione per cui vlc non riproduce i file h.264 di RGB (fino alla prossima release o alle costruzioni notturne correnti): non support il formato pixel gbrp.

Per yuv utilizzare libx264 , non libx264rgb . Non è necessario installare una versione RGB di x264, la libreria effettiva support entrambi. È solo ffmpeg che lo ha implementato come due encoder diversamente denominati. Penso che se non lo avessero fatto, il comportmento predefinito sarebbe quello di lasciare l'input rgb come rgb e funzionare veramente lentamente, producendo un'output bitrate molto più elevata per la stessa qualità. (a volte è necessario utilizzare -pix_fmt yuv420p se si desidera 420 anziché 444 h.264 output.

Unless you are making files for long-term storage, always use -preset ultrafast for lossless x264. More reference frames and motion search barely makes any difference for lossless, for non-animated material with any noise. CABAC takes a huge amount of CPU at lossless bitrates, even to decode. Only use for archival purposes, not scratch files. (ultrafast disables CABAC). CABAC gives 10 to 15% bitrate savings.

If you need every frame to be a keyframe, set -keyint 1 . Then video editing software that only wants to cut on keyframes or w/e will not limit you.

To answer the original question: This is what you should do for throwing around temporary files while trying things in stages (eg a slow deinterlace, saving lossless output before trying other things):

ffmpeg -i dv-video-source.ts -vf yadif=2:1,mcdeint=3:1:10 -c:a copy -c:v libx264 -preset ultrafast -qp 0 deinterlaced.mkv

If you really need your output in image files that you can modify with still-image tools, then sure, decode to png. You're not going to lose anything more than maybe the least significant of the 8 bits of for each of the Y, Cb, and Cr values for each pixel.

x264 comes out REALLY well in this because there are a lot of black frames with a bit of text, a fade-in and fade-out, and perfect similarity between big areas of many frames, which it manages to take advantage of even with -preset ultrafast . On live-action, I still see x264 at half the filesize of ffvhuff (yuv420).

For anyone curious: The high-cpu-time lossless rgb encode had (x264 core 144 r2525):

 [libx264rgb @ 0x35b97a0] frame I:27 Avg QP: 0.00 size:604367 [libx264rgb @ 0x35b97a0] frame P:1226 Avg QP: 0.00 size:517512 [libx264rgb @ 0x35b97a0] mb I I16..4..PCM: 46.3% 38.1% 15.7% 0.0% [libx264rgb @ 0x35b97a0] mb P I16..4..PCM: 24.3% 5.4% 4.5% 0.0% P16..4: 10.5% 3.3% 5.7% 0.0% 0.0% skip:46.3% [libx264rgb @ 0x35b97a0] 8x8 transform intra:17.3% inter:46.1% [libx264rgb @ 0x35b97a0] coded y,u,v intra: 81.6% 77.5% 80.0% inter: 28.0% 27.7% 28.1% [libx264rgb @ 0x35b97a0] i16 v,h,dc,p: 35% 64% 1% 0% [libx264rgb @ 0x35b97a0] i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 49% 13% 2% 1% 1% 1% 1% 1% [libx264rgb @ 0x35b97a0] i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 37% 5% 5% 6% 5% 5% 4% 3% [libx264rgb @ 0x35b97a0] Weighted P-Frames: Y:41.1% UV:40.7% [libx264rgb @ 0x35b97a0] ref P L0: 74.5% 4.2% 9.1% 4.1% 2.1% 1.7% 1.2% 0.8% 0.6% 0.5% 0.3% 0.2% 0.2% 0.2% 0.2% 0.1% [libx264rgb @ 0x35b97a0] kb/s:99721.66 

Note the really high fraction of weighted p frames, and also the really high fraction of skip macroblocks. Every scene transition is a fade, not a cut, and x264 takes advantage if you give it the CPU time to figure out how.

further notes (lossy codecs for editting):

For scrubbing forwards/backwards through clips, intra-only codecs are usually favoured (utvideo, ffvhuff, mjpeg, jpeg2000, pro-res, AVC-Intra). I'd imagine regular AVC with short GOPs (1/2 to 1 sec) would scrub pretty well, too, as long as the software knew what it was doing (decode nearest I frame when scrubbing fast, decode within the GOP to get to an inter frame if you're zoomed in enough on a timeline for that to be needed).

I've posted some negative things on this and https://video.stackexchange.com/ about pro-res, like "what's the point if it's slower and worse compression than a lossless codec", but it does have some interesting features. Apple says that it can decode at half-resolution using as little as 1/3 the CPU time of decoding full rez.

ffmpeg's prores implementation is probably not as optimized for speed as Apple's either, which is why my testing with ffmpeg has made it look slow. It's probably not worth using if you have a Free software workflow with tools based on ffmpeg, but it might be worth trying if you're using commercial software.

I don't do a lot of video editting, mostly just encoding, so I don't have a good sense of what tests would be appropriate for codecs like prores. I'd guess that maybe mjpeg would be a good fast alternative, if short-GOP x264 doesn't work well. There are asm-accelerated implementations of jpeg in Linux distros, and it's a pretty simple codec. You can turn the quality up or down as needed to trade off quality vs. filesize + encode/decode speed. It's ancient, but if you want an intra-only codec that's really fast, it might beat x264.

For x264, I'd try something like x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode (Intra-only, without any of the other stuff that --avcintra-class sets.) Note superfast (without CABAC), or faster , not ultrafast is probably best for lossy operation. I think ultrafast loses a lot of quality without being that much faster. The lower quality (higher crf) you use, the more it's worth spending a bit more CPU time finding a better encode. A lot of this probably isn't relevant with GOP size = 1, though.

With GOP size > 1, if you're throwing so many bits at the encode that better inter-prediction won't save many bits when encoding the residuals (because noise / grain / subtle changes between frames are getting preserved very accurately), then just superfast is probably fine. Otherwise, with --keyint=30 or something, probably --preset veryfast --crf 12 would be interesting.

In theory, quality at a given CRF setting should be constant across presets. If you're looking for smaller files (faster decodes), trading off some quality and some encode time makes sense.

I think ffmpeg actually does support converting to uncompressed video.
I used ffmpeg -i input.mp4 -vcodec rawvideo out.avi and the resulting .avi was roughly the right filesize. Windows media player didn't seem to be able to play it correctly but it could be read by VirtualDub and I did not see any loss in picture quality.