FFMPEG kullanarak 1000'lerin PNG görüntüleri dizisinden sıkıştırılmamış bir AVI oluşturma

FFMPEG kullanarak 1000'lerce PNG görüntüsünden sıkıştırılmamış bir AVI nasıl oluşturabilirim?

Bu komutu bir input.avidosyayı PNG çerçevelerine dönüştürmek için kullandım :

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

Şimdi tüm bu PNG çerçevelerinden sıkıştırılmamış bir AVI videosu yapmayı bilmem gerekiyor. Bunu denedim:

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

Ancak ortaya çıkan video, orijinal AVI'ye göre çok fazla kalite kaybediyor.

"Sıkıştırılmamış" bir AVI'yi ffmpegçıkarmanın birkaç yolu vardır , ancak aslında "kayıpsız" anlamına geldiğinden şüpheleniyorum. Her iki terimin de göreceğiniz gibi, tanımlarında oldukça kıpır kıpır bir oda var.

Bu tartışmayı Big Buck Bunny'nin 720p HD versiyonuyla birleştireceğim , çünkü herkesin test edebileceği ve karşılaştırabileceğimiz sonuçları elde edebileceği ücretsiz bir video. 24 fps'de 1280 × 720p videonun ham veri hızı, 29.97 fps hedefinde belirtilen 1024 × 768'ininkine hemen hemen eşittir, bu nedenle sonuçlarım, çekimlerinizde bekleyebileceğiniz veri hızları için oldukça iyi bir rehber olmalıdır.

Mevcut Seçeneklerin Otomatik Listelenmesi

Aşağıdaki POSIX komutu, size en çok ² aşağıda tartıştıklarımızla eşleşen bir liste sunar:

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

FFmpeg yapınızın nasıl destekleyeceğini görmek için bu komutu kendi makinenizde çalıştırmak isteyebilirsiniz. FFmpeg, her mümkün kodlayıcı etkinken nadiren oluşturulur.

Şimdi bu seçenekleri tartışalım.

Tamamen sıkıştırılmamış

"Sıkıştırılmamış" tanımın bir dijital ekran ile foton döndü edilmeden önce, video sağ olduğu biçim, ben gördüğünüz en yakın ise ffmpeg -codecsşunlardır listede -c:v r210, r10k, v410, v308, ayuvve v408. Bunların hepsi sadece renk derinliği , renk uzayı ve alfa kanalı desteğinde farklı olan esas olarak aynı şeydir .

• R210 ve R10K , bileşen (bpc) başına 10 bitte 4: 4: 4 RGB'dir , bu nedenle testimde her ikisi de720p içinyaklaşık 708 Mbit / s gerektirir. (Bu saatte ⅓ TB civarında, arkadaşlar!)

  Bu codec'lerin her ikisi de piksel başına 3 × 10 bit renk bileşenlerini 2-bit boyutlarındaki bilgisayarlar gibi manipülasyon kolaylığı için 32 bitlik bir değere paketler. Bu codec'ler arasındaki tek fark, kullanılmayan iki bitin 32 bitlik kelimenin sonunda olduğu. Bu önemsiz fark şüphesiz ki rakip firmalardan, Blackmagic Design ve AJA Video Systems'den geliyor .

  Bunlar önemsiz kodlayıcı olsalar da, muhtemelen bilgisayarınızda dosyaları kullanmak için Blackmagic ve / veya AJA kodeklerini indirmeniz gerekir. Her iki şirket onlar müşterilerimiz tarafından üretilen dosyaları ile ilgili olabilir biliyorum yana, öncelikle donanım satın almadan kendi codec indirmek izin verir yapmak onların donanım bazılarına sahip.

• V410 , R210 / R10K’nın sadece YUV versiyonudur; veri hızları aynıdır. Bu kodek yine de daha hızlı kodlayabilir, çünkü ffmpeggirdi çerçevelerinizin renk alanı ile bu renk alanı arasında hızlandırılmış bir renk alanı dönüştürme yoluna sahip olma olasılığı daha yüksektir.

  Bununla birlikte, bu kod çözücüyü öneremem, çünkü elde edilen dosyayı AJA ve Blackmagic kodekleri yüklü olsa bile, denediğim herhangi bir yazılımda oynatamadım.

• V308 , V410'un 8 bpc çeşididir, bu yüzden testimde 518 Mbit / s'ye geliyor. V410'da olduğu gibi, bu dosyaların normal video oynatıcı yazılımında oynatılmasını sağlayamadım.

• AYUV ve V408 onlar bir alfa kanalı dahil dışında gerekli olup olmadığını, esasen V308 aynı şeydir! Videonuzda saydamlık yoksa, bu, daha derin bir renk alanından faydalanmadan, yukarıdaki 10 bpc R210 / R10K kodeğinin boyut cezasını ödeyeceğiniz anlamına gelir.

  AYUV'un bir erdemi var: Windows Media'daki "yerel" bir codec bileşeni, bu yüzden oynamak için özel bir yazılım gerektirmiyor.

  V408'in aynı şekilde QuickTime'a özgü olması gerekiyordu, ancak V408 dosyası Mac'imde QuickTime 7 veya 10'da oynamıyordu.

Öyleyse, bütün bunları bir araya getirmek, eğer PNG'leriniz isimlendirilmişse frame0001.png:

$ 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

AVI’yi AYUV için belirttiğime dikkat edin, çünkü bu yalnızca Windows’a ait bir codec bileşeni. Diğerleri, makinenizde hangi kodeklerin olduğuna bağlı olarak QuickTime veya AVI'da çalışabilir. Bir kap formatı işe yaramazsa, diğerini deneyin.

Yukarıdaki komutlar - ve altındakiler de - giriş çerçevelerinizin zaten çıkış videonuz için istediğiniz boyutta olduğunu varsayalım. Değilse -s 1280x720, çıktı dosyasının adından önce komuta benzer bir şey ekleyin .

Sıkıştırılmış RGB, Ama Aynı zamanda Kayıpsız

Şüphelendiğim gibi, aslında "sıkıştırılmamış" yerine "kayıpsız" demek istiyorsan, yukarıdakilerden daha iyi bir seçenek Apple QuickTime Animation ,-c:v qtrle

Bir AVI istediğini söylediğini biliyorum, ama gerçek şu ki, burada bahsi geçen AVI tabanlı dosya biçimlerinin herhangi birini okumak için bir Windows makinesine bir kodlayıcı yüklemek zorunda kalacaksın, oysaki QuickTime ile videoya bir şans var. Seçtiğiniz uygulama zaten bir QuickTime Animation dosyasını nasıl açacağınızı biliyor. (Yukarıdaki AYUV kodeği, farkında olduğum tek istisna değil, ancak AVI'den yararlanmak için veri hızı oldukça yüksek.)

ffmpegşeyler olacak qtrlesizin için bir AVI kaba ama sonuç çok yaygın uyumlu olmayabilir. Testlerimde, QuickTime Player böyle bir dosya hakkında biraz bilgi sahibi olacaktır, ancak daha sonra oynatır. İşin garibi, kısmen de olsa, VLC çalmayacak ffmpeg. Bu codec için QT kaplarına sadık kalacağım.

QuickTime Animation codec'i önemsiz bir RLE şeması kullanır , bu yüzden basit animasyonlar için aşağıdaki Huffyuv kadar yapmalı. Her karede ne kadar fazla renk olursa, yukarıdaki tamamen sıkıştırılmamış seçeneklerin bit hızına o kadar yaklaşır. Big Buck Bunny ile yaptığım testte ffmpegbana RGB 4: 4: 4 modunda 165 Mbit / s dosya verebildim -pix_fmt rgb24.

Bu format sıkıştırılmış olmasına rağmen, PNG giriş dosyalarınıza aynı çıktı piksel değerlerini verecektir, aynı sebepten dolayı PNG'nin kayıpsız sıkıştırması piksel değerlerini etkilemez.

ffmpegAyrıca destekler QuickTime Animasyon uygulaması -pix_fmt argbsize 4 alır: 4: 4: 4 RGB, bunu anlamı bir alfa kanalı vardır. Çok kaba bir şekilde, -c:v ayuvyukarıda belirtilen QuickTime eşdeğerdir . Ancak, kayıpsız sıkıştırma nedeniyle, kalite ya da özelliklerde sıfır kayıp olan AYUV veri hızından daha az olan sadece 214 Mbit / s .

QuickTime Animation'ın piksel başına 24 bitten daha az çeşidi vardır , ancak bunlar en iyi aşamalı olarak daha basit animasyon stilleri için kullanılır. 15 bpp big-endian RGB anlamına gelen ffmpeg, spec tarafından tanımlanan diğer biçimlerden yalnızca birini destekliyor gibi görünüyor -pix_fmt rgb555be. Bazı videolar için tolere edilebilir ve çoğu ekran görüntüsü yakalama ve basit animasyonlar için uygundur. Renk alanı azaltmayı kabul edebiliyorsanız, 122 Mbit / s veri hızını çekici bulabilirsin.

Bunları bir araya getirmek:

$ 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

Etkili Kayıpsız: YUV Püf Noktası

Şimdi, RGB ve 4: 4: 4 YUV ile ilgili olan şey, bu kodlamaların bilgisayarların işlenmesi için çok kolay olduğu, ancak gözlerimizin renk farklılıklarından ziyade siyah ve beyaz farklılıklarına daha duyarlı olduğu insan görüşü hakkında bir gerçeği görmezden geliyorlar. .

Video depolama ve dağıtım sistemleri bu nedenle renk bilgisi için hemen hemen her zaman piksel bilgisi yerine piksel başına daha az bit kullanır. Buna kroma alt örnekleme denir . En yaygın kullanılan şemalar 4: 2: 0 ve 4: 2: 2'dir.

4: 2: 0 YUV veri hızı, siyah beyaz (yalnızca Y) sıkıştırılmamış videodan yalnızca% 50 daha yüksektir ve 4 4: 4: 4 RGB veya YUV veri hızı.

4: 2: 2, 4: 2: 0 ile 4: 4: 4 arasında bir tür yarım nokta. Yalnızca Y videonun veri hızının iki katı ve: 4: 4: 4 veri hızı.

Eski DV kamera standardında olduğu gibi, bazen 4: 1: 1 de görürsünüz . 4: 1: 1 4: 2: 0 ile aynı sıkıştırılmamış veri hızına sahip, ancak renk bilgisi farklı düzenlenmiştir.

Tüm bunların amacı, eğer bir 4: 2: 0 H.264 dosyasıyla başlıyorsanız, onu 4: 4: 4 olarak tekrar kodlayan, sıkıştırılmamış bir RGB, 4: 2: 0 üzerinde kesinlikle hiçbir şey satın almaz. Bu, iş akışınızın 4: 4: 4 RGB olduğunu bilseniz bile geçerlidir, çünkü önemsiz bir dönüşümdür; Video donanımı ve yazılımı bu tür dönüşümleri rutin olarak anında gerçekleştirir.

Gerçekten sadece piksel tarama yaparken veya videoda piksel düzeyinde renk değişiklikleri yaptığınızda ve tam piksel değerlerini korumanız gerektiğinde yalnızca 4: 4: 4 gerekir. Görsel efektlerin (VFX) çalışmasının 4: 4: 4 piksel formatıyla yapılması daha kolaydır, örneğin, üst seviye VFX evleri genellikle ihtiyaç duyduğu daha yüksek veri hızlarını tolere etmeye hazırdır.

Etkili Kayıpsız: Codec Seçenekleri

Kendinizi renk düşüşü ile YUV kodeklerine açtığınızda, seçenekleriniz de açılır. ffmpegBirçok vardır etkili bir kayıpsız codec.

Huffyuv

En yaygın kullanılan seçenek Huffyuv'dur . Bunu aldın -c:v huffyuv.

Orijinal Windows Huffyuv codec bileşeni yalnızca iki piksel biçimini destekler: RGB24 ve YUV 4: 2: 2. (Aslında, yalnızca diskteki bayt sırasına göre iki YUV 4: 2: 2 lezzetini destekler.)

FFmpeg Huffyuv codec'in eski sürümleri RGB24 desteğini içermiyordu, bu yüzden denerseniz ve FFmpeg size yuv422ppiksel biçimini kullanacağınızı söylerse , yükseltme yapmanız gerekir.

FFmpeg ayrıca, YUV 4: 2: 0'ı destekleyen FFVHuff adlı bir Huffyuv varyant kodeğine sahiptir. Bu değişken Windows DirectShow Huffyuv codec bileşeniyle uyumlu değildir, ancak libavcodecVLC gibi bir yazılımda açılmalıdır .

• RGB24 - RGB 4: 4: 4 aslında QuickTime Animation'ın RGB24 renk alanı seçeneğiyle aynı şeydir. İki kodlayıcı, belirli bir dosya için sıkıştırmada biraz farklılık gösterir, ancak genellikle yakın olurlar.

  Ayrıca, yukarıdaki V308 seçeneği tarafından kullanılan YUV 4: 4: 4 modu ile aynıdır. Renk alanı farkı pratik bir fark yaratmaz, çünkü renk alanı dönüşümünü gerçek zamanlı olarak yapmak kolaydır.

  Huffyuv’ün kayıpsız sıkıştırması nedeniyle , RGB24 modunda yaklaşık 251 Mbit / s’ye , V308 veya AYUV’den alacağınız görsel kalitede aynı olan bir test videosu alabildim. AVI sizin için mutlak bir zorunluluktursa , Huffyuv kodeğini yüklemek muhtemelen AYUV'un 3 × veri ücreti bedelini ödemekten daha az acı vericidir.

• YUV 4: 2: 2 - Bu mod RGB24'ten çok video için çok pratiktir; bu nedenle ffmpeggeliştiricilerin neden ilk uygulamayı seçtikleri şüphesizdir . Yukarıda tartışılan teorik azalmadan beklediğiniz gibi, test dosyam 173 Mbit / s olarak kodlandı . Bu tam olarak ⅔, ses izinin bu iki test arasında değişmediğini hesaba katarsanız.

• YUV 4: 2: 0 - Bu seçenek renk bilgisini 4: 2: 2 den daha fazla düşürerek veri hızını testimde 133 Mbit / s değerine düşürüyor .

Bunları bir araya getirmek:

$ 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

Her ne kadar ffvhuff2: 4 codec'i varsayılan 0 ben bunu yazmak ve gerçekten olarak sadece ben kullanıyorum yayımlanan sürümünde olduğu piksel biçimi destekleyen bu değişiyor ihtimaline karşı bu varsayılan değişiklikleri bayrağı içermelidir yüzden.

Ut Video

Huffyuv ve FFVHuff ile aynı ruhta daha yeni bir seçenek Ut Video . Huffyuv gibi, bir Windows video codec'i var ; bu da bir film oynatabilen herhangi bir Windows programının, bu codec bileşenini kullanarak yüklü olan codec bileşenini kullanarak video oynatabileceği anlamına geliyor. Huffyuv'dan farklı olarak, aynı zamanda bir Mac video codec bileşeni de vardır, bu nedenle FFmpeg tabanlı yazılımlarla sınırlı değil veya libavcodecbu dosyaları Mac'lerde okuyacaksınız.

Bu kodek renk uzayları açısından çok esnektir, bu yüzden birkaç ortak renk alanı örneği vereceğim:

• 4: 4: 4, RGB ile -f avi -c:v utvideo -pix_fmt rgb24verir 178 Mbit / sn çıkışı

• 4: 4: 4 YUV ile -f avi -c:v utvideo -pix_fmt yuv444pverir 153 Mbit / sn çıkışı

• 4: 2: 2 YUV ile -f avi -c:v utvideo -pix_fmt yuv422pverir 123 Mbit / sn çıkışı

• 4: 2: 0 YUV ile -f avi -c:v utvideo -pix_fmt yuv420pverir , 100 Mbit / sn çıkışı

Kaynak video 4: 2: 0 YUV olduğundan, bu ikisi teknik olarak eşdeğer olmasına rağmen 4: 4: 4 YUV'nin bu testte 4: 4: 4 RGB'den daha iyi olduğundan şüpheleniyorum, böylece verilerin YUV biçiminde düzenlenmesi daha iyi kayıpsız sıkıştırmaya izin veriyor kısmen yedekli U ve V kanallarını dosyada birlikte gruplayarak.

FFV1

Bu alandaki bir başka ilginç seçenek de FFmpeg'in kendi FFV1kodeği . Bu, çoğunlukla bir oynatma veya düzenleme kod çözücüsü yerine bir arşiv kodeği olarak kullanılır, ancak bu kadar çok yazılım libavcodecFFmpeg'in temelini oluşturan kütüphaneye dayandığından veya bu libavcodecaraçlar gibi kullanılabildiğinden ffdshow, yine de sizin için yararlı olabilir.

Varsayılan olarak, ffmpegFFV1 gibi esnek bir codec bileşenini kullanırken giriş dosyalarınızın renk alanını koruyacaktır; böylece, 4: 2: 0 YUV kullanan resmi Big Buck Bunny MP4 dosyalarından birini beslerseniz elde edersiniz. -pix_fmtbayrak vermediğiniz sürece ffmpeg. Bu 63 Mbit / s çıktı dosyasına yol açar .

FFV1'i 4: 4: 4 YUV renk boşluğu kullanmaya zorlarsanız -pix_fmt yuv444p, dosya boyutu yalnızca 86 Mbit / sn'ye kadar çıkar , ancak bu durumda bize 4: 2: 0 orijinal kodladığımız için hiçbir şey satın almaz. . Bununla birlikte, orijinal soruda olduğu gibi bir PNG kümesinde beslenirseniz, çıktı dosyasının yukarıda ortaya çıkan ve renkli alanların yeniden düzenlenmesi olan bgraveya veya bgr0renkli alanı kullanması muhtemeldir .argbrgb24

Kayıpsız H.264

Diğer ilginç bir alternatif ise Kayıpsız H.264 . Bu hemen hemen bu x264 sadece bir şey, ama kodlama tarafında FFmpeg kullananlar libx264, kod çözme tarafında da VLC gibi başka bir yazılım kullanıyor olabilir .

Böyle bir dosyayı almanın en basit yolu:

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

-qp 0Bayrak anahtarıdır: yüksek değerler kayıplı sıkıştırma verir. ( -crf 0Aynı etkiyi elde etmek için de verebilirsiniz .)

FFV1'de olduğu gibi ffmpeg, girdi renk boşluğu verilen en iyi çıktı renk boşluğunu tahmin etmeye çalışacağım, bu yüzden yukarıdaki sonuçlarla karşılaştırmak için, farklı renk boşluklarıyla Big Buck Bunny kaynak dosyasında birden fazla kod geçişi koştum:

• yuv444p : ffmpegAsıl soruda olduğu gibi, buna bir RGB PNG akışı verdiğinizde seçtiği ve test dosyamızda 44 Mbit / sn dosyasıyla sonuçlanan şey budur

• yuv422p : Bu Huffyuv için varsayılan renk uzayına benzer, ancak bu durumda 34 Mbit / sn'lik bir dosya alıyoruz , oldukça tasarruf!

• yuv420p : Bu, test ettiğim Big Buck Bunny resmi MP4'leri için varsayılan değerdir ve 29 Mbit / sn dosyasıyla sonuçlanır .

Bu kadar küçük dosya boyutları elde etmek için pek çok uyumluluk ticareti yaptığınıza dikkat edin. Bu yüzden bunu bir AVI veya MOV konteynerine doldurmaya bile zahmet etmedim. X264'e o kadar yakın bağlanmıştır ki standart konteyner türünü (MP4) de kullanabilirsiniz. Bunun için Matroska gibi bir şey de kullanabilirsiniz .

Bu bit oranının bir kısmını daha hızlı bir kodlama süresi için ekleyerek yapabilirsiniz -preset ultrafast. Bu, test dosyamın bit hızını YUV 4: 2: 2 modunda 44 Mbit / s'ye yükseltti , ancak söz verildiği gibi çok daha hızlı kodladı. Dokümanlar -preset veryslowda değerli olduğunu iddia ediyor , ancak çok küçük bir yer tasarrufu sağlarken çok daha uzun zaman kodlamasıyla sonuçlandı ; Tavsiye edemem.

Diğerleri

ffmpegayrıca Lagarith için sadece kod çözme modunu ve Kayıpsız JPEG için sadece kodlama modunu da destekler . Bu iki kodek aslında aynıdır ve aynı kalitede Huffyuv'den biraz daha küçük dosyalar vermelidir. Eğer ffmpeggeliştiriciler hiç Lagarith kodlama ekleyin, neden Huffyuv için güçlü bir alternatif olacaktır. Geniş bir kod çözme desteğinden hoşlanmadığı için Kayıpsız JPEG'i öneremem.

Algısal Olarak Kayıpsız: Ya da Muhtemelen Bazı Kayıplarla Kaçabilirsiniz

Sonra algısal kayıpsız codec vardır . Piksel dikizlemediğiniz sürece, bunların kesinlikle önceki iki gruptan farklı görsel sonuçlar verdiğini söyleyemezsiniz. Video yakalama sensörü ve ekran cihazı arasında kesinlikle sıfır bir değişiklik olması fikrinden vazgeçerek, önemli miktarda tasarruf elde edersiniz:

• Apple ProRes :-c:v proresya da-c:v prores_ks- ProRes, profil tabanlı bir kodlayıcıdır; bu, her biri farklı bir alana ve alandaki tradeoff'a sahip birkaç varyantın olduğu anlamına gelir:

  • ProRes 4444 , test videomuzu yalnızca 114 Mbit / s kullanarak kodlar, ancak VFX kalitesidir . Şu andaprores*FFmpeg'deüç farklıcodec bileşeni var, ancakprores_ksbunu-profile:v 4444seçenekolarak yazarkenyalnızcaProRes 4444'ü destekliyor.

    ProRes 4444'ü Kayıpsız H.264'e göre neden kullanmaya çalıştığınızı merak ediyorsanız, uyumluluk, kod çözme hızı, öngörülebilirlik ve alfa kanalı ile ilgilidir.

  • ProRes 422 , daha fazla alan kazandırırve ProRes 4444'ten yalnızca piksel izleme ile anlatabileceğiniz bir sonuç vermekiçin yalnızca 84 Mbit / s'ye ihtiyaç duyar. ProRes 4444 tarafından sunulan alfa kanalına ihtiyaç duymuyorsanız, ProRes 4444'te ısrar etmek için muhtemelen hiçbir neden yoktur.

    ProRes 422, hiçbiri bir alfa kanalını desteklemediğinden yukarıdaki Kayıpsız H.264 seçeneğine daha yakın bir rakiptir. Apple pro video uygulamaları ile uyumluluk, kodlama ve kod çözme için daha düşük bir CPU ek yükü veya öngörülebilir bit hızları gerekiyorsa, ProRes'in daha yüksek bit hızına katlanmak istersiniz. İkincisi, örneğin donanım kodlayıcılarda önemlidir. Öte yandan, Lossless H.264'ün uyumluluk problemleriyle başa çıkabiliyorsanız, herhangi bir ProRes profilinde bir seçenek olmayan 4: 2: 0 renk alanını kullanma seçeneğine sahip olursunuz.

    FFmpeg'deki ProRes kodlayıcıların üçü de ProRes 422 profilini desteklemektedir, bu nedenle en basit seçenek, doğru olanı yapmak için otomatik profil özelliğini kullanmak -c:v proresyerine -c:v prores_ks -profile hqveya kullanmaktır prores_ks.

  Daha ayrıcalıklı ProRes profilleri de var, ancak SD video veya tam çözünürlüklü dosyalar için proxy'ler olarak kullanılıyor .

  ProRes ile ilgili temel sorun, Apple ve pro video dünyaları dışında henüz geniş bir desteğe sahip olmamasıdır.

• Avid'in DNxHD'si ProRes'e benzer bir codec bileşenidir, ancak Apple pro video dünyasına bağlı değildir. Avid,hem Windows hem de Macintosh için ücretsiz olarak indirilebilir kodekler sunarve FFmpeg şimdi bunu desteklemektedir-c:v dnxhd.

  DNxHD, ProRes gibi bir profil tabanlı kodlayıcı olduğundan , önceden tanımlanmış kümeden profili seçersiniz ve bu kod çözücüye hangi kare boyutunu, kare hızını ve bit hızını kullanacağını söyler. Big Buck Bunny test dosyası için, -b:v 60Mprofil en uygun olanıdır. Şaşırtıcı olmayan bir şekilde, ortaya çıkan dosya yaklaşık 59 Mbit / s'dir .

• Düşük kayıplı MJPEG :-vcodec mjpeg -qscale:v 1- Bu, kayıpsız JPEG'den çok daha yaygındır. Aslında, bu bir zamanlar oldukça yaygın bir video düzenleme codec'i idi ve hala ağ bağlantılı video kameralar gibi şeyler tarafından sıkça kullanılıyor. Tüm bu geçmiş, onu destekleyen yazılımı bulmanın kolay olduğu anlamına gelir.

  Bu kodekten gelen veri oranlarında oldukça geniş bir değişkenlik bekliyoruz. Burada yaptığım bir testte 720p video için bana 25 Mbit / s verdi . Kayıplılık konusunda beni endişelendirecek kadar yüksek bir sıkıştırma, ama bana çok yakışmış görünüyordu. Yalnızca veri hızına bağlı olarak, muhtemelen 12 Mbit / s MPEG-2 veya 6 Mbit / s H.264 ile aynı kalitede olduğunu söyleyebilirim .

Bunları bir araya getirmek:

$ 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

Bu yöntemlerin alt satırında, çok zorlu bir şey yapmıyorsanız, "yeterince iyi" gerçekten yeterli.

Dipnotlar ve Dipnotlar

1. Komut Linux, macOS, BSD'ler ve Unix'te olduğu gibi çalışmalıdır. Windows kullanıyorsanız, Cygwin veya WSL aracılığıyla bir POSIX komut satırı alabilirsiniz .

2. Bu komut tarafından üretilen listenin yukarıda tartışmayı seçtiğim kodek setiyle tam olarak eşleşmemesinin birkaç nedeni vardır:

   • İkincisi grep, bu listede bmpetiketlenmiş olmasına rağmen "video" kodekleri olmayan uygunsuz kodlayıcıları filtrelemek içindir V. Teknik olarak, tek bir videoyu almak için muhtemelen bunların çoğunu AVI, MP4 veya MKV gibi bir kaba doldurmanıza rağmen, bu dosya büyük olasılıkla ffmpegveya tabanlı bir program tarafından okunamaz libavcodec.

     Bunun -f avi -c:v ljpeg“Kayıpsız MJPEG” olarak adlandırabileceğiniz bir şey vermesi gibi birkaç istisna vardır, ancak bir kural olarak, bir film yapmak için pek çok hareketsiz görüntü dosyasını bir A / V kabına doldurmakla ilgilenmiyoruz. Burada yaygın olarak tanınan video kodekleri istiyoruz, anlamsal hile yapmak değil.

   • Komut şu anda GIF gibi uygunsuz kodlayıcıları filtrelemede başarısız oluyor çünkü şu anda ffmpeg -codecsçıktıda bitmapveya imagedosya formatlarında açıklanmadı.

     GIF ilginç bir durum: tek bir GIF dosyasındaki birden fazla görüntü çerçevesini hareket oynatma için zamanlama bilgileriyle destekliyor, ancak birkaç nedenden dolayı, buradaki tartışmamız için tamamen uygun değil.

   • Gösterilir seçeneklerin Birkaç gibi gerçekten çok çekiş var eskimiş veya asla flashsv, diracve snowyukarıda bunları tartışmaya değmez yani.

   • Bu listedeki seçeneklerden bazıları yalnızca arasındaki boru hatlarında kullanmak içindir ffmpegörnekleri ya arasındaki ffmpeggibi ve başka bir program, rawvideove wrapped_avframe, ve bu yüzden burada bizim amaçlar için uygun değildir.

   • Yukarıdaki tartışmanın bitimine kadar, dikkatlice seçilmiş birkaç kayıplı seçenek içerecek şekilde sorunun kapsamını makul bir şekilde genişletiyorum, bu yüzden grepyukarıdaki komuttaki ilk filtreyi geçemiyorlar .

Böylece çok uzun bir süre kendi cevabımı verdim.
TL; DR özeti: kayıpsız görüntüler, kullanım dizisi depolamak için libx264veya libx264rgbbirlikte -preset ultrafast -qp 0. Neredeyse ffvhuff kadar hızlı, daha düşük bit hızı ile ve daha hızlı kod çözüyor. huffyuvffmpeg dışında daha yaygın olarak desteklenir, ancak birçok piksel biçimini desteklemez ffvhuff. Bu nedenle, diğer araçlarınızın High 4:4:4 Predictivex264'ün kayıpsız modda kullandığı h.264 profilini idare edebileceğini varsayarsak, h.264'ü kullanmanın bir başka nedeni de budur . x264 yalnızca rasgele çerçevelere hızlı rasgele erişime ihtiyaç duyulursa intra yapabilir.

Bir resim dizinden okurken libx264rgb'yi etkileyen ffmpeg hatalarına dikkat edin . (ve başka hangi davaları kim bilir?) Kullanmadan önce kurulumunuzdaki kayıpsızlığı test edin. ( ffmpeg -i in -pix_fmt rgb24 -f framemd5kaynağında kolay ve kayıpsız sıkıştırılmış)

edit: utvideooldukça hızlı kodlar ve kodları çözer ve h.264'ten çok daha basit bir codec bileşenidir. huffyuvDaha kullanışlı renk alanlarını destekleyen, temelde modern . H.264 ile ilgili bir problem yaşarsanız, geçici dosyalar için sonraki utvideo'yu deneyin.

edit2: Bir RGB kodeki olarak PNG, en azından Sintel fragmanında başarılı görünüyor.

Ayrıca bkz: benzer bir soruya benzer cevabım: https://superuser.com/a/860335/20798

Warren Young'ın çeşitli ham biçimler ve codec bileşenleri hakkındaki cevabında birçok bilgi var. Cevap daha kısa olsaydı daha faydalı olacağını düşünüyorum, bu yüzden yeni bir cevap veriyorum. Kayıpsız x264 veya ffvhuff'ı desteklemeyen bir yazılımla çalışıyorsanız, bu bilgilerin bazıları muhtemelen hala kullanışlıdır.

Bu bağlamda "kayıpsız" en kullanışlı tanımı bit için bit girişini kurtarabilmenizdir. Sıfır, ne yaptığınıza bakılmaksızın, video kodlamasından kalite kalitesinin düşmesi konusunda endişelenmeyin.

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

İdeal olarak, çok sayıda renk alanı dönüşümünden kaçının. Yuvarlama hataları potansiyel olarak birikebilir. Videonuzda RGB renk alanında çalışan filtrelerle çalışacaksanız, daha yüksek bit hızları sorun olmadığı sürece, RGB’yi tutmak mantıklı olacaktır. Muhtemelen nihayetinde bir yuv 4:2:0video üreteceksiniz , ancak ekstra kroma çözünürlüğünü korumak, hangi filtreleri uygulayacağınıza bağlı olarak potansiyel olarak faydalıdır.

Her iki durumda da kayıpsız x264 ve destek RGB ve YUV hem ffvhuff 4:4:4, 4:2:2ve 4:2:0. Çözülmesi hızlı olduğu için x264'i önerebilirim. RGB HD videoyu gerçek zamanlı olarak oynatmaya çalışıyorsanız, xv yerine opengl'i deneyin, çünkü sistemimdeki xv yalnızca yuvayı kabul ediyor. mplayer, renk alanı dönüşümü yapmak için fazladan CPU zamanı alıyordu.

Aşağıdaki kodlayıcı testlerinin kaynağı: https://media.xiph.org/ . https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz Sintel fragmanının y4m dosyalarını gziplemeyi unuttular, bu yüzden png tarball aslında çok daha küçük.

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

Örneğin

peter@tesla:/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

Fps belirtmeyi unuttuğumu unutmayın -r 24, böylece ses ile av eşitlenmez. (ve bit hızı (ancak dosya boyutu değil) sayıları da kapalı olacaktır. ffmpeg varsayılanları 25fps'dir). Bu makinedeki işlemci, 1. nesil (conroe) core2duo 2.4GHz'dir (E6600).

Sonuçlar:

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

Not mediainfoRGB h.264 bilmediği, hala dosyaları YUV olduğunu söyler.

Gerçekten kayıpsız olduğunu kontrol edin:

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

Böylece orijinal PNG girişini bu şekilde geri kazanabilirsiniz, yani PNG'leri içlerinde aynı görüntü verisiyle yapabilirsiniz.

-pix_fmt rgb24X264 testi için not alın . ffmpeg'in h.264 kod çözücüsü gbrp (düzlemsel, paketlenmemiş) çıktı üretir, bu nedenle bitler aynıdır, ancak farklı bir sıradadır. Framemd5 "container" herhangi bir format kısıtlaması getirmez, ancak bitler aynı şekilde düzenlenirse yalnızca aynı md5'i alırsınız. PNG'leri beslerken ffmpeg'in bir pix fmt için kullandığını söylediği şeye baktım, sonra bunu -pix_fmtçözmek için argüman olarak kullandım . Bu arada, vlc'nin RGB h.264 dosyalarını oynatmamasının nedeni budur (bir sonraki sürüme kadar veya geçerli gece oluşturma işlemine kadar): gbrp piksel biçimini desteklemez.

Yuva kullanımı için libx264değil libx264rgb. Bir x264 RGB sürümü kurmanıza gerek yok, gerçek kütüphane her ikisini de destekliyor. İki farklı kodlayıcı olarak uygulayan sadece ffmpeg. Bunu yapmamışlarsa, varsayılan davranış, rgb girişini rgb olarak bırakmak ve aynı kalite için çok daha yüksek bit hızı çıktısı üretirken gerçekten yavaş çalıştırmak olacaktır. (Hala bazen kullanımına sahip -pix_fmt yuv420pİsterseniz 420yerine 444h.264 çıktı.

Uzun süreli depolama için dosyalar oluşturmazsanız, daima -preset ultrafastkayıpsız x264 için kullanın . Daha fazla referans çerçevesi ve hareket arama özelliği, animasyonlu olmayan malzemeler için herhangi bir gürültüyle kayıpsız olarak neredeyse hiç farketmez. CABAC, şifresini çözmek için bile kayıpsız bit oranlarında büyük miktarda CPU alır. Dosyaları arşivlemek için yalnızca arşivleme amacıyla kullanın. (ultrafast CABAC'ı devre dışı bırakır). CABAC% 10-15 oranında bitrate tasarrufu sağlar.

Her karenin bir anahtar kare olması için ihtiyacınız varsa ayarlayın -keyint 1. O zaman sadece ana kareleri kesmek isteyen veya w / e yapmak isteyen video düzenleme yazılımı sizi sınırlandırmaz.

Asıl soruyu cevaplamak için: Aşamaları denerken geçici dosyaları atmak için yapmanız gereken şey budur (örn. Yavaş bir deinterlace, başka şeyleri denemeden önce kayıpsız çıktı tasarrufu):

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

Çıktınıza hareketsiz görüntü araçlarıyla değiştirebileceğiniz görüntü dosyalarında gerçekten ihtiyaç duyuyorsanız, png komutunun kodunu çıkartın. Her piksel için Y, Cb ve Cr değerlerinin her birinin 8 bitinden en az önemlisi olandan daha fazlasını hiçbir şey kaybetmeyeceksiniz.

x264 gerçekten çok iyi bir şekilde çıkıyor çünkü bir miktar metin içeren çok sayıda siyah çerçeve, bir solma ve solma ve birçok karenin büyük alanları arasında bile bundan faydalanmayı sağlayan mükemmel bir benzerlik var -preset ultrafast. Canlı-eylemde, hala ffvhuff dosyalarının yarısında x264'ü görüyorum (yuv420).

Merak eden herkes için: Yüksek cpu-zaman kayıpsız rgb kodlaması vardı (x264 çekirdek 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

Gerçekten ağırlıklı p karelerinin çok yüksek oranını ve ayrıca atlama makro bloklarının çok yüksek oranını not alın. Her sahne geçişi bir soluktur, kesim değildir ve nasıl yapılacağını anlamak için CPU zamanını verirseniz x264 avantaj sağlar.

ek notlar (düzenleme için kayıplı kodekler):

Klipler yoluyla ileri / geri fırçalamak için, sadece içi kod çözücüler genellikle tercih edilir (utvideo, ffvhuff, mjpeg, jpeg2000, pro-res, AVC-Intra). Yazılımın ne yaptığını bildiği sürece kısa GOP'lerin (1/2 ila 1 sn) normal AVC'yi iyi bir şekilde fırçalayacağını hayal ediyorum (hızlı fırçalarken en yakın I çerçevesini deşifre etmek, GOP içinde çözmek İhtiyaç duyulacak bir zaman çizelgesinde yeterince yakınlaştırılmışsanız, ara çerçeve).

Bu konuda bazı olumsuz şeyler yayınladım ve " https://video.stackexchange.com/ pro-res hakkında," kayıpsız bir kodlayıcıya göre daha yavaş ve daha kötü bir sıkıştırma varsa, sorun ne olabilir "gibi, ancak bazı ilginç özelliklere sahip. Apple, tam rez çözme işleminin 1 / 3'ü kadar küçük bir işlemle yarım çözünürlükte çözülebileceğini söylüyor .

ffmpeg'in prores uygulaması muhtemelen Apple'ın hızı kadar optimize edilmedi, bu yüzden ffmpeg ile yaptığım testler yavaş görünüyor. Ffmpeg tabanlı araçlarla bir Ücretsiz yazılım iş akışınız varsa muhtemelen kullanmaya değmez, ancak ticari yazılım kullanıyorsanız denemeye değer olabilir.

Çok fazla video düzenleme işlemi yapmıyorum, çoğunlukla sadece kodlama yapıyorum, bu yüzden prores gibi kodekler için hangi testlerin uygun olacağı konusunda hiçbir fikrim yok. Kısa GOP x264 iyi çalışmıyorsa, belki de mjpeg'in hızlı bir alternatif olabileceğini tahmin ediyorum. Linux dağıtımlarında, hızlandırılmış jpeg uygulamaları var ve bu oldukça basit bir codec bileşeni. Kaliteyi düşürmek için dosya boyutuna göre kod çözme / kod çözme hızını düşürmek için kaliteyi yukarı veya aşağı çevirebilirsiniz. Eski, ancak gerçekten hızlı olan yalnızca bir intra-codec bileşeni istiyorsanız, x264'ü yenebilir.

X264 için şöyle bir şey denerdim x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode (yalnızca Intra-yalnızca, --avcintra-classayarlayan başka hiçbir şey olmadan .) Not superfast(CABAC olmadan), ya da muhtemelen kayıplı işlem için en iyisi fasterdeğil ultrafast. Bence ultrafast bu kadar hızlı olmadan çok fazla kalite kaybeder. Ne kadar düşük kalite (yüksek crf) kullanırsanız, o kadar iyi bir kodlama bulmak için biraz daha CPU harcıyorsunuz. Bununla birlikte, bunların çoğu muhtemelen GOP büyüklüğü = 1 ile ilişkili değildir.

GOP büyüklüğü> 1 olduğunda, kodlamaya çok daha fazla bit atıyorsanız, daha iyi tahminler artıkları kodlarken daha fazla bit tasarruf etmeyecektir (çünkü çerçeveler arasındaki gürültü / tahıl / ince değişiklikler çok doğru bir şekilde korunur), sadece süper hızlı muhtemelen iyidir. Aksi takdirde, ile --keyint=30veya bir şey, muhtemelen --preset veryfast --crf 12ilginç olurdu.

Teoride, verilen bir CRF ayarındaki kalite ön ayarlarda sabit olmalıdır. Daha küçük dosyalar (daha hızlı kod çözme) arıyorsanız, bir miktar işlem yapın ve bir miktar kodlama süresi mantıklı geliyor.

Bence ffmpeg aslında sıkıştırılmamış videoya dönüştürmeyi destekliyor.
Ben ffmpeg -i input.mp4 -vcodec rawvideo out.avi kullandım ve sonuçta .avi kabaca doğru dosya boyutuna ulaştı. Windows medya oynatıcı doğru oynatamıyor gibi görünüyordu ama VirtualDub tarafından okunuyordu ve resim kalitesinde herhangi bir kayıp görmedim.