Cara membuat AVI tanpa kompresi dari serangkaian 1000-an gambar PNG menggunakan FFMPEG

Bagaimana saya bisa membuat AVI tanpa kompresi dari serangkaian 1000-an gambar PNG menggunakan FFMPEG?

Saya menggunakan perintah ini untuk mengonversi input.avifile ke serangkaian bingkai PNG:

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

Sekarang saya perlu tahu cara membuat video AVI yang tidak terkompresi dari semua frame PNG itu. Saya mencoba ini:

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

Tetapi video yang dihasilkan kehilangan banyak kualitas relatif terhadap AVI asli.

Ada beberapa cara untuk mengeluarkan AVI "tidak terkompresi" ffmpeg, tetapi saya menduga Anda sebenarnya bermaksud "lossless." Kedua istilah memiliki sedikit ruang gerak dalam definisi mereka, seperti yang akan Anda lihat.

Saya akan jangkar diskusi ini dengan versi HD 720p dari Big Buck Bunny , karena ini adalah video yang tersedia secara bebas dan kita semua dapat menguji dan mendapatkan hasil yang dapat kita bandingkan. Kecepatan data mentah video 1280 × 720p pada 24 fps sangat hampir sama dengan yang Anda katakan 1024 × 768 pada tujuan 29,97 fps, jadi hasil saya harus menjadi panduan yang cukup bagus untuk kecepatan data yang dapat Anda harapkan pada rekaman Anda.

Daftar Otomatis dari Opsi yang Tersedia

Perintah POSIX berikut¹ memberi Anda daftar yang sebagian besar² cocok dengan apa yang kita bahas di bawah ini:

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

Anda mungkin ingin menjalankan perintah itu di mesin Anda sendiri untuk melihat apa yang akan didukung oleh FFmpeg Anda. FFmpeg jarang dibuat dengan setiap encoder yang memungkinkan diaktifkan.

Sekarang mari kita bahas opsi-opsi itu.

Sepenuhnya Terkompresi

Jika definisi Anda tentang "terkompresi" adalah bentuk video tersebut di tepat sebelum itu berpaling ke foton oleh tampilan digital, yang paling dekat saya lihat dalam ffmpeg -codecsdaftar yang -c:v r210, r10k, v410, v308, ayuvdan v408. Ini semua substansial hal yang sama, hanya berbeda dalam kedalaman warna , ruang warna , dan alpha channel dukungan.

• R210 dan R10K adalah 4: 4: 4 RGB pada 10 bit per komponen (bpc), sehingga keduanya membutuhkan sekitar 708 Mbit / s untuk 720p dalam pengujian saya. (Itu sekitar ⅓ TB per jam, teman-teman!)

  Kedua codec ini mengemas komponen warna 3 × 10 bit per piksel ke dalam nilai 32-bit untuk kemudahan manipulasi oleh komputer, yang menyukai ukuran power-of-2. Satu-satunya perbedaan antara codec ini adalah pada akhir kata 32-bit di mana dua bit yang tidak digunakan berada. Perbedaan sepele ini tidak diragukan lagi karena mereka berasal dari perusahaan pesaing, Blackmagic Design dan AJA Video Systems .

  Meskipun ini adalah codec sepele, Anda mungkin harus mengunduh codec Blackmagic dan / atau AJA untuk memutar file menggunakan mereka di komputer Anda. Kedua perusahaan akan membiarkan Anda men-download codec mereka tanpa membeli hardware pertama mereka, karena mereka tahu Anda mungkin berurusan dengan file yang dihasilkan oleh pelanggan yang melakukan memiliki beberapa perangkat keras mereka.

• V410 pada dasarnya hanya versi YUV dari R210 / R10K; kecepatan data mereka identik. Namun codec ini dapat mengkodekan lebih cepat, karena ffmpeglebih cenderung memiliki jalur konversi ruang warna yang dipercepat antara ruang warna frame input Anda dan ruang warna ini.

  Saya tidak bisa merekomendasikan codec ini, karena saya tidak bisa mendapatkan file yang dihasilkan untuk diputar di perangkat lunak apa pun yang saya coba, bahkan dengan codec AJA dan Blackmagic yang diinstal.

• V308 adalah varian 8 bpc dari V410, jadi ia datang ke 518 Mbit / s dalam pengujian saya. Seperti halnya V410, saya tidak bisa mendapatkan file-file ini untuk diputar dalam perangkat lunak pemutar video normal.

• AYUV dan V408 pada dasarnya hal yang sama dengan V308, kecuali bahwa mereka menyertakan saluran alfa, apakah itu diperlukan atau tidak! Jika video Anda tidak menggunakan transparansi, ini berarti Anda membayar penalti ukuran dari 10 bpc R210 / R10K codec di atas tanpa mendapatkan manfaat dari ruang warna yang lebih dalam.

  AYUV memang memiliki satu kelebihan: itu adalah codec "asli" di Windows Media, sehingga tidak memerlukan perangkat lunak khusus untuk bermain.

  V408 seharusnya asli untuk QuickTime dengan cara yang sama, tetapi file V408 tidak akan diputar di QuickTime 7 atau 10 di Mac saya.

Jadi, kumpulkan semua ini, jika PNG Anda diberi nama frame0001.pngdan sebagainya:

$ 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

Perhatikan bahwa saya telah menentukan AVI dalam kasus AYUV, karena ini adalah codec khusus Windows. Yang lain dapat bekerja di QuickTime atau AVI, tergantung pada codec mana yang ada di mesin Anda. Jika satu format wadah tidak berfungsi, coba yang lain.

Perintah di atas - dan yang di bawah juga - mengasumsikan frame input Anda sudah memiliki ukuran yang sama seperti yang Anda inginkan untuk video output Anda. Jika tidak, tambahkan sesuatu seperti -s 1280x720pada perintah, sebelum nama file output.

RGB Terkompresi, Tapi Juga Tanpa Rugi

Jika, seperti yang saya duga, Anda sebenarnya berarti "lossless" daripada "uncompressed," pilihan yang jauh lebih baik daripada yang di atas adalah Apple QuickTime Animation , melalui-c:v qtrle

Saya tahu Anda mengatakan Anda menginginkan AVI, tetapi kenyataannya Anda mungkin harus menginstal codec pada mesin Windows untuk membaca format file berbasis AVI yang disebutkan di sini, sedangkan dengan QuickTime ada kemungkinan video aplikasi pilihan Anda sudah tahu cara membuka file Animasi QuickTime. (Codec AYUV di atas adalah satu-satunya pengecualian yang saya ketahui, tetapi kecepatan datanya sangat tinggi, hanya untuk mendapatkan manfaat dari AVI.)

ffmpegakan qtrlememasukkan barang ke dalam wadah AVI untuk Anda, tetapi hasilnya mungkin tidak terlalu kompatibel. Dalam pengujian saya, QuickTime Player akan sedikit mengeluh tentang file seperti itu, tetapi kemudian memainkannya. Namun anehnya, VLC tidak akan memainkannya, meskipun sebagian berdasarkan ffmpeg. Saya akan tetap menggunakan wadah QT untuk codec ini.

Codec QuickTime Animation menggunakan skema RLE sepele , jadi untuk animasi sederhana, itu harus dilakukan serta Huffyuv di bawah ini. Semakin banyak warna di setiap frame, semakin mendekati bit rate dari opsi yang sepenuhnya tidak terkompresi di atas. Dalam pengujian saya dengan Big Buck Bunny, saya bisa ffmpegmemberi saya file 165 Mbit / s dalam mode RGB 4: 4: 4, via -pix_fmt rgb24.

Meskipun format ini dikompresi, ini akan memberikan nilai piksel output yang identik ke file input PNG Anda, karena alasan yang sama bahwa kompresi lossless PNG tidak mempengaruhi nilai piksel.

The ffmpegpelaksanaan QuickTime Animation juga mendukung -pix_fmt argb, yang membuat Anda 4: 4: 4: 4 RGB, yang berarti memiliki alpha channel. Dalam cara yang sangat kasar, ini adalah setara dengan QuickTime -c:v ayuv, yang disebutkan di atas. Karena kompresi lossless, meskipun, itu hanya 214 Mbit / s , kurang dari ⅓ data rate AYUV dengan nol kehilangan kualitas atau fitur.

Ada varian QuickTime Animation dengan kurang dari 24 bit per piksel, tetapi mereka paling baik digunakan untuk gaya animasi yang semakin sederhana. ffmpegtampaknya mendukung hanya satu dari format lain yang ditentukan oleh spesifikasi -pix_fmt rgb555be,, yang berarti 15 bpp big-endian RGB. Ini lumayan untuk beberapa video, dan bagus untuk sebagian besar tangkapan layar screencast dan animasi sederhana. Jika Anda dapat menerima penipisan ruang warna, Anda mungkin menemukan kecepatan data 122 Mbit / s yang menarik.

Menyatukan semua ini:

$ 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

Secara efektif Lossless: Trik YUV

Sekarang, hal tentang RGB dan 4: 4: 4 YUV adalah bahwa pengkodean ini sangat mudah untuk diproses oleh komputer, tetapi mereka mengabaikan fakta tentang penglihatan manusia, yaitu bahwa mata kita lebih sensitif terhadap perbedaan hitam dan putih daripada perbedaan warna. .

Penyimpanan video dan sistem pengiriman karena itu hampir selalu menggunakan lebih sedikit bit per pixel untuk informasi warna daripada informasi luminance. Ini disebut chroma subsampling . Skema yang paling umum adalah 4: 2: 0 dan 4: 2: 2.

Laju data 4: 2: 0 YUV hanya 50% lebih tinggi daripada untuk video yang tidak dikompresi hitam putih (hanya Y) dan ½ laju data 4: 4: 4 RGB atau YUV.

4: 2: 2 adalah semacam titik setengah antara 4: 2: 0 dan 4: 4: 4. Ini dua kali lipat kecepatan data video Y-only dan ⅔ kecepatan data 4: 4: 4.

Anda juga terkadang melihat 4: 1: 1, seperti pada standar kamera DV lama . 4: 1: 1 memiliki laju data yang tidak terkompresi yang sama dengan 4: 2: 0, tetapi informasi warnanya diatur secara berbeda.

Inti dari semua ini adalah bahwa jika Anda mulai dengan file H.264 4: 2: 0, encoding ulang menjadi 4: 4: 4 RGB terkompresi membeli Anda benar-benar tidak lebih dari 4: 2: 0 YUV terkompresi tanpa kehilangan. Ini benar bahkan jika Anda tahu alur kerja Anda adalah 4: 4: 4 RGB, karena ini adalah konversi sepele; perangkat keras dan perangkat lunak video melakukan konversi seperti itu secara rutin.

Anda benar-benar hanya membutuhkan 4: 4: 4 saat Anda mengintip piksel atau melakukan perubahan warna level-pixel pada video, dan Anda perlu mempertahankan nilai piksel yang tepat. Pekerjaan efek visual (VFX) lebih mudah dilakukan dengan format piksel 4: 4: 4, misalnya, sehingga rumah VFX kelas atas sering bersedia untuk mentolerir kecepatan data yang lebih tinggi yang diperlukannya.

Tanpa Rugi Secara Efektif: Pilihan Codec

Setelah Anda membuka diri Anda hingga codec YUV dengan penipisan warna, opsi Anda juga terbuka. ffmpegmemiliki banyak codec efektif lossless .

Huffyuv

Opsi yang paling banyak kompatibel adalah Huffyuv . Anda mendapatkan ini melalui -c:v huffyuv.

Codec Windows Huffyuv asli hanya mendukung dua format piksel: RGB24 dan YUV 4: 2: 2. (Sebenarnya, ini mendukung dua rasa YUV 4: 2: 2, hanya berbeda dalam urutan byte pada disk.)

Versi lama dari FFmpeg Huffyuv codec tidak termasuk dukungan RGB24, jadi jika Anda mencobanya dan FFmpeg memberi tahu Anda bahwa itu akan menggunakan yuv422pformat piksel, Anda perlu memutakhirkan.

FFmpeg juga memiliki codec varian Huffyuv yang disebut FFVHuff, yang mendukung YUV 4: 2: 0. Varian ini tidak kompatibel dengan codec Windows DirectShow Huffyuv, tetapi harus terbuka pada perangkat lunak apa pun yang berbasiskan libavcodec, seperti VLC.

• RGB24 - RGB 4: 4: 4 pada dasarnya sama dengan opsi ruang warna RGB24 QuickTime Animation. Kedua codec akan sedikit berbeda dalam kompresi untuk file yang diberikan, tetapi mereka biasanya akan ditutup.

  Ini pada dasarnya juga sama dengan mode YUV 4: 4: 4 yang digunakan oleh opsi V308 di atas. Perbedaan ruang warna tidak membuat perbedaan praktis, karena konversi ruang warna mudah dilakukan secara real time.

  Karena kompresi lossless Huffyuv, saya bisa mendapatkan video uji untuk kompres menjadi sekitar 251 Mbit / s dalam mode RGB24, dengan kualitas visual yang identik dengan apa yang Anda dapatkan dari V308 atau AYUV. Jika AVI adalah keharusan mutlak bagi Anda, menginstal codec Huffyuv mungkin lebih tidak menyakitkan daripada membayar biaya data rate 3 × dari AYUV.

• YUV 4: 2: 2 - Mode ini jauh lebih praktis untuk video daripada RGB24, yang tidak diragukan mengapa para ffmpegpengembang memilih untuk mengimplementasikannya terlebih dahulu. Seperti yang Anda harapkan dari pengurangan ⅔ teoritis yang dibahas di atas, file tes saya dikodekan ke 173 Mbit / s . Itu persis persis ⅔, jika Anda memperhitungkan fakta bahwa trek audio tidak berubah di antara dua tes ini.

• YUV 4: 2: 0 - Opsi ini menghilangkan informasi warna lebih dari 4: 2: 2, menurunkan kecepatan data ke 133 Mbit / s dalam pengujian saya.

Menyatukan semua ini:

$ 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

Meskipun ffvhuffcodec default menjadi 4: 2: 0 saat saya menulis ini, dan memang hanya mendukung format piksel dalam versi rilis yang saya gunakan, ini berubah , jadi Anda harus menyertakan bendera jika perubahan default ini terjadi.

Ut Video

Opsi yang lebih baru dengan semangat yang sama dengan Huffyuv dan FFVHuff adalah Ut Video . Seperti Huffyuv, ada codec video Windows yang berarti setiap program Windows yang dapat memutar film dapat memutar video menggunakan codec ini dengan codec diinstal. Tidak seperti Huffyuv, ada juga codec video Mac juga, jadi Anda tidak terbatas pada perangkat lunak berbasis FFmpeg atau libavcodecmembaca file-file ini pada Mac.

Codec ini sangat fleksibel dalam hal ruang warna, jadi saya hanya akan memberikan beberapa contoh ruang warna umum:

• 4: 4: 4 RGB via -f avi -c:v utvideo -pix_fmt rgb24memberikan output 178 Mbit / detik

• 4: 4: 4 YUV via -f avi -c:v utvideo -pix_fmt yuv444pmenghasilkan keluaran 153 Mbit / detik

• 4: 2: 2 YUV via -f avi -c:v utvideo -pix_fmt yuv422pmemberikan output 123 Mbit / detik

• 4: 2: 0 YUV via -f avi -c:v utvideo -pix_fmt yuv420pmemberikan output 100 Mbit / detik

Saya menduga 4: 4: 4 YUV lebih baik dari 4: 4: 4 RGB dalam tes ini meskipun keduanya secara teknis setara karena sumber video adalah 4: 2: 0 YUV, jadi mengatur data dalam format YUV memungkinkan kompresi lossless yang lebih baik dengan mengelompokkan saluran U dan V yang sebagian berlebihan bersama dalam file.

FFV1

Pilihan lain yang menarik di ruang ini adalah FFV1codec FFmpeg sendiri . Ini sebagian besar digunakan sebagai codec arsip daripada pemutaran atau mengedit codec, tetapi karena begitu banyak perangkat lunak baik didasarkan pada libavcodecpustaka yang menopang FFmpeg atau dapat diikat dengan libavcodecalat seperti ffdshow, mungkin tetap berguna bagi Anda.

Secara default, ffmpegakan mempertahankan ruang warna file input Anda saat menggunakan codec fleksibel seperti FFV1, sehingga jika Anda memberinya salah satu file MP4 Big Buck Bunny resmi, yang menggunakan YUV 4: 2: 0, itulah yang akan Anda dapatkan keluar kecuali Anda memberi -pix_fmtbendera untuk ffmpeg. Ini menghasilkan file output 63 Mbit / s .

Jika Anda memaksa FFV1 untuk menggunakan ruang warna YUV 4: 4: 4 dengan -pix_fmt yuv444p, ukuran file hanya naik hingga 86 Mbit / detik , tetapi tidak ada gunanya bagi kami dalam hal ini karena kami menyandikan dari yang asli 4: 2: 0 . Namun, jika Anda memberi makan dalam satu set PNG sebagai gantinya, seperti dalam pertanyaan asli, file output cenderung menggunakan ruang bgraatau bgr0warna, yang hanya penataan ulang argbdan rgb24ruang warna yang dibawa di atas.

Rugi H.264

Alternatif lain yang menarik adalah Lossless H.264 . Ini cukup banyak hal x264-hanya pada tulisan ini, tetapi mereka yang menggunakan FFmpeg di sisi pengkodean kemungkinan akan menggunakan perangkat lunak lain yang termasuk libx264di sisi decoding juga, seperti VLC.

Cara paling sederhana untuk mendapatkan file seperti itu adalah:

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

The -qp 0bendera adalah kunci: nilai yang lebih tinggi memberikan kompresi lossy. (Anda juga bisa memberi -crf 0untuk mendapatkan efek yang sama.)

Seperti FFV1, ffmpegakan mencoba menebak ruang warna keluaran terbaik yang diberi ruang warna masukan, jadi untuk perbandingan dengan hasil di atas, saya menjalankan beberapa lintasan penyandian pada file sumber Big Buck Bunny dengan ruang warna berbeda:

• yuv444p : Ini yang ffmpegdipilih ketika Anda memberikan aliran PNG RGB, seperti pada pertanyaan awal, dan menghasilkan file 44 Mbit / detik dengan file pengujian kami

• yuv422p : Ini mirip dengan ruang warna default untuk Huffyuv, tapi kami mendapatkan file 34 Mbit / detik dalam kasus ini, cukup penghematan!

• yuv420p : Ini adalah default untuk MP4 Big Buck Bunny resmi yang saya uji, dan menghasilkan file 29 Mbit / detik .

Berhati-hatilah karena Anda memperdagangkan banyak kompatibilitas untuk mendapatkan ukuran file sekecil itu. Itu sebabnya saya bahkan tidak repot-repot mencoba memasukkan ini ke dalam wadah AVI atau MOV. Ini sangat terkait erat dengan x264 sehingga Anda mungkin juga menggunakan tipe kontainer standar (MP4). Anda juga bisa menggunakan sesuatu seperti Matroska untuk ini.

Anda dapat menukar sebagian dari bit rate tersebut untuk waktu penyandian yang lebih cepat dengan menambahkan -preset ultrafast. Itu meningkatkan bit rate file uji saya menjadi 44 Mbit / s dalam mode YUV 4: 2: 2, tetapi disandikan lebih cepat, seperti yang dijanjikan. The docs mengklaim bahwa -preset veryslowini juga bermanfaat, tetapi menghasilkan banyak waktu encode lagi sementara hanya menyimpan sedikit ruang; Saya tidak bisa merekomendasikannya.

Lainnya

ffmpegjuga mendukung mode decode-only untuk Lagarith dan mode encode-only untuk Lossless JPEG . Kedua codec ini sebenarnya agak mirip, dan seharusnya memberikan file sedikit lebih kecil dari Huffyuv dengan kualitas yang sama. Jika ffmpegpengembang pernah menambahkan pengkodean Lagarith, itu akan menjadi alternatif yang kuat untuk Huffyuv. Saya tidak bisa merekomendasikan JPEG Lossless, karena tidak menikmati dukungan decoding yang luas.

Tanpa Persepsi Lossless: Atau, Anda Mungkin Bisa Pergi Dengan Beberapa Kehilangan

Lalu ada codec yang secara persepsi lossless. Kecuali jika Anda mengintip piksel, Anda hampir pasti tidak dapat mengatakan bahwa ini memberikan hasil visual yang berbeda dari dua grup sebelumnya. Dengan menyerah pada gagasan perubahan nol mutlak antara sensor video capture dan perangkat layar, Anda membeli penghematan yang cukup besar:

• Apple ProRes :-c:v proresatau-c:v prores_ks- ProRes adalah codec berbasis profil, artinya ada beberapa varian, masing-masing dengan kualitas yang berbeda vs tradeoff ruang:

  • ProRes 4444 mengkodekan video uji kami hanya menggunakan 114 Mbit / s , namun kualitas VFX . Saat ini ada tigaprores*codecberbedadi FFmpeg, tetapi hanyaprores_ksmendukung ProRes 4444, ketika saya menulis ini, melalui-profile:v 4444opsi.

    Jika Anda bertanya-tanya mengapa Anda repot-repot pergi dengan ProRes 4444 lebih dari Lossless H.264, itu turun ke kompatibilitas, kecepatan decoding, prediktabilitas, dan saluran alpha.

  • ProRes 422 bahkan menghemat lebih banyak ruang, hanya membutuhkan 84 Mbit / s untuk memberikan hasil yang dapat Anda katakan dari ProRes 4444 hanya dengan pixel-mengintip. Kecuali Anda membutuhkan saluran alfa yang ditawarkan oleh ProRes 4444, mungkin tidak ada alasan untuk memaksa ProRes 4444.

    ProRes 422 adalah pesaing yang lebih dekat dengan opsi H.264 Lossless di atas, karena tidak ada yang mendukung saluran alpha. Anda ingin mentolerir bit rate ProRes yang lebih tinggi jika Anda membutuhkan kompatibilitas dengan aplikasi video pro Apple, overhead CPU yang lebih rendah untuk encoding dan decoding, atau bit rate yang dapat diprediksi. Yang terakhir ini penting dengan encoders perangkat keras, misalnya. Di sisi lain, jika Anda dapat mengatasi masalah kompatibilitas Lossless H.264, Anda mendapatkan opsi untuk menggunakan ruang warna 4: 2: 0, yang bukan merupakan pilihan dari profil ProRes mana pun.

    Ketiga encoder ProRes di FFmpeg mendukung profil ProRes 422, jadi opsi paling sederhana adalah menggunakan -c:v prores, daripada -c:v prores_ks -profile hq, atau bergantung pada fitur profil otomatis prores_ksuntuk melakukan hal yang benar.

  Bahkan ada lebih banyak profil ProRes yang pelit, tetapi mereka dimaksudkan untuk video SD atau sebagai proksi untuk file resolusi penuh.

  Masalah utama dengan ProRes adalah bahwa ia belum memiliki dukungan luas di luar dunia video Apple dan pro.

• DNxHD Avid adalah codec yang mirip dengan ProRes, tetapi tidak terikat dengan dunia video pro Apple. Avid menawarkan codec yang dapat diunduh secara bebas untuk Windows dan Macintosh, dan FFmpeg sekarang mendukungnya-c:v dnxhd.

  Karena DNxHD adalah codec berbasis profil seperti ProRes, Anda memilih profil dari set yang telah ditentukan , dan itu memberi tahu codec yang ukuran frame, frame rate, dan bit rate untuk digunakan. Untuk file uji Big Buck Bunny, -b:v 60Mprofilnya paling tepat. Tidak mengejutkan, file yang dihasilkan sekitar 59 Mbit / s .

• Low-loss MJPEG :-vcodec mjpeg -qscale:v 1- Ini jauh lebih umum daripada JPEG lossless. Bahkan, ini pernah menjadi codec pengeditan video yang cukup umum, dan masih sering digunakan oleh hal-hal seperti kamera video streaming jaringan. Semua riwayat itu berarti mudah untuk menemukan perangkat lunak yang mendukungnya.

  Harapkan variabilitas yang cukup luas dalam kecepatan data dari codec ini. Sebuah tes yang baru saja saya lakukan di sini memberi saya 25 Mbit / s untuk video 720p. Kompresi yang cukup tinggi membuat saya gugup tentang kehilangan, tetapi itu terlihat cukup baik bagi saya. Berdasarkan data rate saja, saya akan mengatakan itu mungkin setara kualitas untuk 12 Mbit / s MPEG-2 atau 6 Mbit / s H.264.

Menyatukan semua ini:

$ 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

Intinya pada metode ini adalah bahwa kecuali Anda melakukan sesuatu yang sangat menuntut, "cukup baik" benar-benar cukup baik.

Catatan Kaki dan Digesti

1. Perintah harus bekerja seperti yang diberikan pada Linux, macOS, BSDs, dan Unix. Jika Anda menggunakan Windows, Anda bisa mendapatkan baris perintah POSIX melalui Cygwin atau WSL .

2. Ada beberapa alasan mengapa daftar yang dihasilkan oleh perintah itu tidak cocok dengan set codec yang saya pilih untuk dibahas di atas:

   • Yang kedua grepdimaksudkan untuk menyaring encoders yang tidak pantas seperti bmpyang bukan "video" codec, meskipun ditandai Vdalam daftar ini. Meskipun secara teknis Anda mungkin bisa memasukkan banyak dari ini ke dalam wadah seperti AVI, MP4, atau MKV untuk mendapatkan video satu file, file itu kemungkinan tidak akan dapat dibaca oleh apa pun selain program yang didasarkan pada ffmpegatau libavcodec.

     Ada beberapa pengecualian untuk ini, seperti yang -f avi -c:v ljpegmemberikan sesuatu yang bisa Anda sebut "Lossless MJPEG," tetapi sebagai aturan, kami tidak tertarik memasukkan banyak file gambar diam ke wadah A / V di sini untuk membuat film. Kami ingin codec video yang dikenal luas di sini, bukan tipuan semantik.

   • Perintah saat ini gagal untuk menyaring beberapa encoders yang tidak pantas seperti GIF karena mereka saat ini tidak dijelaskan dalam ffmpeg -codecsoutput sebagai bitmapatau imageformat file.

     GIF adalah kasus yang menarik: mendukung banyak bingkai gambar dalam satu file GIF dengan informasi waktu untuk pemutaran gerak, tetapi karena beberapa alasan, itu sepenuhnya tidak pantas untuk diskusi kita di sini.

   • Beberapa opsi yang ditampilkan usang atau tidak pernah benar-benar mendapat banyak daya tarik, seperti flashsv, dirac, dan snow, sehingga tidak layak membahas mereka di atas.

   • Beberapa opsi dalam daftar itu dimaksudkan hanya untuk digunakan dalam saluran pipa antara ffmpeginstance atau antara ffmpegdan program lain, seperti rawvideodan wrapped_avframe, dan karenanya tidak sesuai untuk tujuan kita di sini.

   • Menjelang akhir diskusi di atas, saya dengan bijaksana memperluas lingkup pertanyaan sedikit untuk memasukkan beberapa opsi lossy yang dipilih dengan hati-hati, sehingga mereka tidak melewati grepfilter pertama dalam perintah di atas.

Jadi saya akhirnya membuat jawaban sendiri terlalu lama.
Ringkasan TL; DR: Untuk menyimpan secara berurutan urutan gambar, gunakan libx264atau libx264rgbdengan -preset ultrafast -qp 0. Ini hampir secepat ffvhuff, dengan bitrate jauh lebih rendah, dan menerjemahkan lebih cepat. huffyuvjauh lebih banyak didukung di luar ffmpeg, tetapi tidak mendukung format piksel sebanyak ffvhuff. Jadi itulah alasan lain untuk menggunakan h.264, dengan asumsi alat Anda yang lain dapat menangani High 4:4:4 Predictiveprofil h.264 yang digunakan x264 dalam mode lossless. x264 dapat melakukan intra-saja jika akses acak cepat ke frame sewenang-wenang diperlukan.

Waspadalah terhadap bug ffmpeg yang memengaruhi libx264rgb saat membaca dari direktori gambar. (dan siapa yang tahu kasus apa lagi.) Tes untuk losslessness dalam pengaturan Anda sebelum menggunakan. (mudah dengan ffmpeg -i in -pix_fmt rgb24 -f framemd5sumber dan lossless-kompresi))

sunting: utvideomenyandikan dan menerjemahkan dengan cukup cepat, dan merupakan codec yang lebih sederhana daripada h.264. Ini pada dasarnya modern huffyuv, dengan dukungan untuk ruang warna yang lebih berguna. Jika Anda pernah memiliki masalah dengan h.264, coba utvideo selanjutnya untuk file sementara.

sunting2: PNG sebagai RGB codec tampaknya berfungsi dengan baik, setidaknya di trailer Sintel.

Lihat juga jawaban saya yang mirip dengan pertanyaan serupa: https://superuser.com/a/860335/20798

Ada banyak info dalam jawaban Warren Young tentang berbagai format dan codec mentah. Saya pikir jawabannya akan lebih berguna jika lebih pendek, jadi saya membuat jawaban baru. Jika Anda bekerja dengan perangkat lunak yang tidak mendukung x264 lossless atau ffvhuff, maka beberapa info itu mungkin masih berguna.

Definisi yang paling berguna dari "lossless" dalam konteks ini adalah Anda dapat memulihkan input bit-for-bit. Nol khawatir tentang penurunan kualitas dari penyandian video, apa pun yang Anda lakukan.

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

Idealnya, hindari beberapa konversi spasi warna. Kesalahan pembulatan berpotensi menumpuk. Jika Anda akan beroperasi pada video Anda dengan filter yang berfungsi di ruang warna RGB, maka pertahankan RGB masuk akal, selama bitrate yang lebih tinggi tidak menjadi masalah. Anda mungkin pada akhirnya akan menghasilkan yuv 4:2:0video, tetapi menjaga resolusi kroma ekstra berpotensi berguna, tergantung pada filter apa yang akan Anda terapkan.

Either way, lossless x264 dan ffvhuff baik dukungan RGB dan YUV 4:4:4, 4:2:2, dan 4:2:0. Saya sarankan x264, karena cepat untuk memecahkan kode. Jika Anda mencoba memutar video RGB HD secara realtime, coba buka bukan xv, karena xv pada sistem saya hanya menerima input yuv. mplayer membutuhkan waktu CPU ekstra untuk melakukan konversi ruang-warna.

Sumber untuk tes enkoder berikut: https://media.xiph.org/ . https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz Mereka lupa untuk gzip file y4m untuk trailer sintel, sehingga tarball png sebenarnya jauh lebih kecil.

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

misalnya

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

Perhatikan bahwa saya lupa menentukan -r 24fps, sehingga av tidak akan tetap menyinkronkan dengan audio. (dan angka bitrate (tetapi bukan ukuran file) juga akan mati. ffmpeg default ke 25fps). CPU dalam mesin ini adalah 1st-gen (conroe) core2duo 2.4GHz (E6600).

hasil:

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

Catatan yang mediainfotidak tahu tentang RGB h.264, masih mengatakan bahwa file tersebut adalah YUV.

Periksa apakah benar-benar lossless:

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

Jadi Anda dapat memulihkan input PNG asli dengan cara itu, yaitu Anda dapat membuat PNG dengan data gambar yang identik di dalamnya.

Perhatikan -pix_fmt rgb24untuk tes x264. dekoder h.264 ffmpeg menghasilkan keluaran gbrp (planar, tidak dikemas), sehingga bitnya sama, tetapi dalam urutan yang berbeda. Framemd5 "container" tidak mengenakan batasan format apa pun, tetapi Anda hanya akan mendapatkan md5 yang sama jika bit-bitnya disusun dengan cara yang sama. Saya baru saja melihat apa yang dikatakan ffmpeg digunakan untuk pix fmt ketika saya memberinya PNG, kemudian menggunakannya sebagai argumen -pix_fmtuntuk decode. Kebetulan, inilah alasan vlc tidak akan memutar file RGB h.264 (sampai rilis berikutnya, atau build malam hari ini): Ini tidak mendukung format gbrp pixel.

Untuk Anda gunakan libx264, bukan libx264rgb. Anda tidak perlu menginstal versi RGB x264, pustaka yang sebenarnya mendukung keduanya. Hanya ffmpeg yang mengimplementasikannya sebagai dua encoders yang dinamai berbeda. Saya pikir jika mereka tidak melakukan itu, perilaku default adalah meninggalkan input rgb sebagai rgb, dan berjalan sangat lambat sambil menghasilkan output bitrate yang jauh lebih tinggi untuk kualitas yang sama. (Anda kadang-kadang masih harus menggunakan -pix_fmt yuv420pjika Anda ingin 420bukannya 444h.264 output.

Kecuali Anda membuat file untuk penyimpanan jangka panjang, selalu gunakan -preset ultrafastuntuk x264 lossless. Lebih banyak frame referensi dan pencarian gerakan hampir tidak membuat perbedaan untuk lossless, untuk materi non-animasi dengan noise apa pun. CABAC mengambil sejumlah besar CPU pada bitrate lossless, bahkan untuk memecahkan kode. Hanya digunakan untuk keperluan arsip, bukan file awal. (ultrafast menonaktifkan CABAC). CABAC memberikan penghematan bitrate 10 hingga 15%.

Jika Anda membutuhkan setiap bingkai untuk menjadi bingkai kunci, atur -keyint 1. Maka perangkat lunak pengeditan video yang hanya ingin memotong frame kunci atau jika tidak akan membatasi Anda.

Untuk menjawab pertanyaan awal: Inilah yang harus Anda lakukan untuk melempar file-file sementara sambil mencoba berbagai hal secara bertahap (misalnya deinterlace lambat, menyimpan output lossless sebelum mencoba hal-hal lain):

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

Jika Anda benar-benar membutuhkan hasil dalam file gambar yang dapat Anda modifikasi dengan alat gambar-diam, maka yakinkan, decode ke png. Anda tidak akan kehilangan apa pun lebih dari mungkin yang paling signifikan dari 8 bit untuk masing-masing nilai Y, Cb, dan Cr untuk setiap piksel.

x264 keluar BENAR-BENAR baik dalam hal ini karena ada banyak bingkai hitam dengan sedikit teks, fade-in dan fade-out, dan kesamaan sempurna antara area besar dari banyak frame, yang berhasil memanfaatkan bahkan dengan -preset ultrafast. Pada live-action, saya masih melihat x264 di setengah filesize dari ffvhuff (yuv420).

Untuk siapa pun yang penasaran: Encode rgb lossless waktu-cpu tinggi waktu (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

Perhatikan fraksi p frame tertimbang yang sangat tinggi, dan juga fraksi skip makroblock yang sangat tinggi. Setiap transisi adegan memudar, bukan potongan, dan x264 mengambil keuntungan jika Anda memberikan waktu CPU untuk mencari caranya.

catatan lebih lanjut (codec lossy untuk diedit):

Untuk menggosok maju / mundur melalui klip, codec intra-only biasanya disukai (utvideo, ffvhuff, mjpeg, jpeg2000, pro-res, AVC-Intra). Saya membayangkan AVC biasa dengan GOP pendek (1/2 hingga 1 dtk) akan menggosok dengan cukup baik, asalkan perangkat lunak tahu apa yang dilakukannya (decode bingkai I terdekat saat menggosok cepat, dekode dalam GOP untuk sampai ke bingkai antar jika Anda memperbesar cukup pada timeline untuk itu diperlukan).

Saya telah memposting beberapa hal negatif tentang ini dan https://video.stackexchange.com/ tentang pro-res, seperti "apa gunanya jika kompresi lebih lambat dan lebih buruk daripada codec lossless", tetapi ia memiliki beberapa fitur menarik. Apple mengatakan bahwa ia dapat memecahkan kode dengan resolusi setengah menggunakan hanya 1/3 waktu CPU decoding rez penuh.

Implementasi ffmpeg mungkin tidak dioptimalkan untuk kecepatan seperti Apple juga, itulah sebabnya pengujian saya dengan ffmpeg membuatnya terlihat lambat. Mungkin tidak layak digunakan jika Anda memiliki alur kerja perangkat lunak bebas dengan alat-alat yang berbasis pada ffmpeg, tetapi mungkin patut dicoba jika Anda menggunakan perangkat lunak komersial.

Saya tidak melakukan banyak pengeditan video, sebagian besar hanya penyandian, jadi saya tidak memiliki perasaan yang baik tentang tes apa yang cocok untuk codec seperti prores. Saya kira mungkin mjpeg akan menjadi alternatif cepat yang baik, jika x264 GOP pendek tidak bekerja dengan baik. Ada implementasi asp-accelerated jpeg di distro Linux, dan ini adalah codec yang cukup sederhana. Anda dapat mengubah kualitas ke atas atau ke bawah sesuai kebutuhan untuk menukar kualitas vs kecepatan file + encode / decode. Ini kuno, tetapi jika Anda ingin codec intra-only yang sangat cepat, mungkin mengalahkan x264.

Untuk x264, saya akan mencoba sesuatu seperti x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode (Intra-only, tanpa ada hal-hal lain yang --avcintra-classmengatur.) Catatan superfast(tanpa CABAC), atau faster, ultrafastmungkin bukan yang terbaik untuk operasi lossy. Saya pikir ultrafast kehilangan banyak kualitas tanpa menjadi jauh lebih cepat. Semakin rendah kualitas (crf lebih tinggi) yang Anda gunakan, semakin layak menghabiskan sedikit lebih banyak waktu CPU untuk menemukan penyandian yang lebih baik. Banyak dari ini mungkin tidak relevan dengan ukuran GOP = 1.

Dengan ukuran GOP> 1, jika Anda melempar begitu banyak bit pada encode sehingga inter-prediksi yang lebih baik tidak akan menghemat banyak bit saat menyandikan residu (karena perubahan noise / grain / halus antar frame semakin terpelihara dengan sangat akurat), maka hanya supercepat mungkin baik-baik saja. Kalau tidak, dengan --keyint=30atau sesuatu, mungkin --preset veryfast --crf 12akan menarik.

Secara teori, kualitas pada pengaturan CRF yang diberikan harus konstan di seluruh pengaturan awal. Jika Anda mencari file yang lebih kecil (decode lebih cepat), menukar kualitas dan waktu penyandian masuk akal.

Saya pikir ffmpeg sebenarnya mendukung konversi ke video yang tidak terkompresi.
Saya menggunakan ffmpeg -i input.mp4 -vcodec rawvideo out.avi dan .avi yang dihasilkan kira-kira merupakan filesize yang tepat. Windows media player tampaknya tidak dapat memainkannya dengan benar tetapi bisa dibaca oleh VirtualDub dan saya tidak melihat adanya kerugian dalam kualitas gambar.