Istnieje kilka sposobów na wyjście z „nieskompresowanego” AVI ffmpeg
, ale podejrzewam, że w rzeczywistości masz na myśli „bezstratny”. Jak widać, oba terminy mają w swoich definicjach sporo miejsca na poruszanie się.
Zamierzam zakotwiczyć tę dyskusję w wersji 720p HD Big Buck Bunny , ponieważ jest to swobodnie dostępny film, z którym wszyscy możemy przetestować i uzyskać wyniki, które możemy porównać. Surowa szybkość transmisji wideo 1280 × 720p przy 24 klatkach na sekundę jest bardzo zbliżona do deklarowanej wartości 1024 × 768 przy 29,97 klatce na sekundę, więc moje wyniki powinny być całkiem dobrym przewodnikiem po szybkościach transmisji danych, których można oczekiwać na nagraniu.
Automatyczna lista dostępnych opcji
Poniższe polecenie POSIX¹ daje listę, która w większości odpowiada² temu, co omawiamy poniżej:
$ ffmpeg -codecs 2> /dev/null | grep '^..EV..S ' | grep -vE 'bitmap|image'
Możesz uruchomić tę komendę na swoim komputerze, aby zobaczyć, co będzie wspierać twoja kompilacja FFmpeg. FFmpeg rzadko jest budowany z włączonym każdym możliwym koderem.
Omówmy teraz te opcje.
Całkowicie nieskompresowany
Jeśli definicja „nieskompresowanego” jest formą film jest w prawo, zanim to zwrócił się do fotonów przez wyświetlacz cyfrowy, najbliższa widzę w tym ffmpeg -codecs
liście są -c:v r210
, r10k
, v410
, v308
, ayuv
i v408
. Są to w zasadzie to samo, różnią się tylko w głębi kolorów , przestrzeni kolorów i alfa kanału wsparcia.
R210 i R10K mają 4: 4: 4 RGB przy 10 bitach na komponent (bpc), więc oba wymagają około 708 Mbit / s dla 720p w moich testach. (To około ⅓ TB na godzinę, przyjaciele!)
Oba te kodeki pakują 3 × 10-bitowe komponenty kolorów na piksel do wartości 32-bitowej, aby ułatwić manipulowanie przez komputery, które lubią moc 2 rozmiarów. Jedyną różnicą między tymi kodekami jest to, na którym końcu 32-bitowego słowa znajdują się dwa nieużywane bity. Ta trywialna różnica jest niewątpliwie, ponieważ pochodzą one od konkurencyjnych firm, odpowiednio Blackmagic Design i AJA Video Systems .
Chociaż są to trywialne kodeki, prawdopodobnie będziesz musiał pobrać kodeki Blackmagic i / lub AJA, aby odtwarzać pliki przy użyciu ich na komputerze. Obie firmy pozwoli Ci pobrać swoje kodeki bez kupił swój pierwszy sprzęt, ponieważ wiedzą, mogą mieć do czynienia z plikami produkowanych przez klientów, którzy zrobienia niektóre z ich sprzętu.
V410 jest zasadniczo tylko wersją R2U / R10K w wersji YUV; ich szybkości przesyłania danych są identyczne. Ten kodek może mimo to kodować szybciej, ponieważ ffmpeg
jest bardziej prawdopodobne, że istnieje przyspieszona ścieżka konwersji przestrzeni kolorów między przestrzenią kolorów ramek wejściowych a tą przestrzenią kolorów.
Nie mogę jednak polecić tego kodeka, ponieważ nie byłem w stanie uzyskać wynikowego pliku do odtworzenia w żadnym wypróbowanym oprogramowaniu, nawet z zainstalowanymi kodekami AJA i Blackmagic.
V308 to wariant V410 o 8 bitach na sekundę, więcw moich testachdochodzi do 518 Mbit / s . Podobnie jak w przypadku V410, nie udało mi się odtworzyć tych plików w normalnym oprogramowaniu odtwarzacza wideo.
AYUV i V408 są zasadniczo takie same jak V308, z tym wyjątkiem, że zawierają kanał alfa, bez względu na to, czy jest potrzebny! Jeśli Twój film nie używa przezroczystości, oznacza to, że płacisz karę za rozmiar 10 kpc R210 / R10K powyżej bez korzystania z głębszej przestrzeni kolorów.
AYUV ma jedną zaletę: jest „rodzimym” kodekiem w Windows Media, więc do odtwarzania nie wymaga specjalnego oprogramowania.
V408 ma być natywny dla QuickTime w ten sam sposób, ale plik V408 nie będzie odtwarzany w QuickTime 7 lub 10 na moim komputerze Mac.
Więc, łącząc to wszystko, jeśli twoje PNG są nazwane frame0001.png
i tak dalej:
$ 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
Zauważ, że podałem AVI w przypadku AYUV, ponieważ jest to w zasadzie kodek tylko dla systemu Windows. Inne mogą działać w QuickTime lub AVI, w zależności od tego, które kodeki znajdują się na twoim komputerze. Jeśli jeden format kontenera nie działa, wypróbuj drugi.
Powyższe polecenia - i te również poniżej - zakładają, że ramki wejściowe mają już taki sam rozmiar, jak chcesz dla wyjściowego wideo. Jeśli nie, dodaj coś podobnego -s 1280x720
do polecenia przed nazwą pliku wyjściowego.
Skompresowany RGB, ale także bezstratny
Jeśli, jak podejrzewam, masz na myśli „bezstratny” zamiast „nieskompresowany”, znacznie lepszym wyborem niż którykolwiek z powyższych jest Apple QuickTime Animation , za pośrednictwem-c:v qtrle
Wiem, że powiedziałeś, że chcesz AVI, ale faktem jest, że prawdopodobnie będziesz musiał zainstalować kodek na komputerze z systemem Windows, aby odczytać dowolny z wymienionych tutaj formatów plików AVI, podczas gdy w QuickTime istnieje szansa, że wideo wybrana aplikacja już wie, jak otworzyć plik animacji QuickTime. (Powyższy kodek AYUV to jedyny wyjątek, o którym wiem, ale jego szybkość przesyłania danych jest strasznie wysoka, aby uzyskać korzyści z AVI.)
ffmpeg
wpakuje się qtrle
do kontenera AVI, ale wynik może nie być bardzo zgodny. W moich testach QuickTime Player trochę się zastanawia nad takim plikiem, ale potem go odtwarza. Dziwne jest jednak to, że VLC go nie odtworzy, chociaż częściowo opiera się na nim ffmpeg
. Trzymałbym się kontenerów QT dla tego kodeka.
Kodek QuickTime Animation używa trywialnego schematu RLE , więc w przypadku prostych animacji powinien on działać tak samo dobrze, jak Huffyuv poniżej. Im więcej kolorów w każdej ramce, tym bardziej zbliża się do szybkości bitowej w pełni nieskompresowanych powyższych opcjach. Podczas testów z Big Buck Bunny udało mi ffmpeg
się uzyskać plik 165 Mbit / s w trybie RGB 4: 4: 4 za pośrednictwem -pix_fmt rgb24
.
Chociaż ten format jest skompresowany, będzie dawał identyczne wyjściowe wartości pikseli plikom wejściowym PNG, z tego samego powodu, dla którego bezstratna kompresja PNG nie wpływa na wartości pikseli.
ffmpeg
Realizacja QuickTime obsługuje również animacji -pix_fmt argb
, który dostaje 4: 4: 4: 4 RGB, co oznacza, że ma kanał alfa. W bardzo szorstki sposób jest to odpowiednik QuickTime -c:v ayuv
, o którym mowa powyżej. Jednak ze względu na bezstratną kompresję dochodzi tylko do 214 Mbit / s , mniej niż ⅓ szybkości transmisji danych AYUV przy zerowej utracie jakości lub funkcji.
Istnieją warianty animacji QuickTime z mniej niż 24 bitami na piksel, ale najlepiej nadają się one do stopniowego upraszczania stylów animacji. ffmpeg
wydaje się obsługiwać tylko jeden z innych formatów zdefiniowanych przez specyfikację -pix_fmt rgb555be
, co oznacza 15-bitowy big-endian RGB. Jest tolerowany w przypadku niektórych filmów i jest odpowiedni dla większości zrzutów ekranu i prostych animacji. Jeśli możesz zaakceptować dziesiątkowanie przestrzeni kolorów, może się okazać, że szybkość transmisji danych wynosi 122 Mbit / s .
Składając to wszystko razem:
$ 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
Skutecznie bezstratny: sztuczka YUV
Rzecz w RGB i 4: 4: 4 YUV polega na tym, że te kodowania są bardzo łatwe do przetworzenia przez komputery, ale ignorują fakt dotyczący ludzkiej wizji, a mianowicie to, że nasze oczy są bardziej wrażliwe na różnice czerni i bieli niż różnice kolorów .
Dlatego systemy przechowywania i dostarczania wideo prawie zawsze używają mniejszej liczby bitów na piksel dla informacji o kolorze niż dla informacji o luminancji. Nazywa się to podpróbkowaniem barwy . Najpopularniejsze schematy to 4: 2: 0 i 4: 2: 2.
Szybkość transmisji 4: 2: 0 YUV jest tylko o 50% wyższa niż w przypadku nieskompresowanego wideo czarno-białego (tylko Y) i ½ szybkość transmisji 4: 4: 4 RGB lub YUV.
4: 2: 2 jest rodzajem punktu pośredniego między 4: 2: 0 a 4: 4: 4. Jest to dwukrotność szybkości przesyłania danych w przypadku wideo tylko Y i rate szybkość transmisji danych 4: 4: 4.
Czasami widzisz także 4: 1: 1, jak w starym standardzie kamery DV . 4: 1: 1 ma tę samą nieskompresowaną szybkość transmisji danych jak 4: 2: 0, ale informacja o kolorze jest ułożona inaczej.
Chodzi o to, że jeśli zaczynasz od pliku H.264 4: 2: 0, ponowne kodowanie go do nieskompresowanego RGB 4: 4: 4 nie daje absolutnie nic ponad bezstratnie skompresowany YUV 4: 2: 0. Jest to prawdą, nawet jeśli wiesz, że Twój przepływ pracy to inaczej RGB 4: 4: 4, ponieważ jest to trywialna konwersja; sprzęt wideo i oprogramowanie rutynowo wykonują takie konwersje w locie.
Naprawdę potrzebujesz tylko 4: 4: 4, gdy podglądasz piksele lub robisz zmiany kolorów na poziomie pikseli w filmie i musisz zachować dokładne wartości pikseli. Na przykład praca z efektami wizualnymi (VFX) jest łatwiejsza w przypadku formatu 4: 4: 4 piksele, więc wysokiej klasy domy graficzne są często skłonne do tolerowania wyższych wymaganych prędkości danych.
Skutecznie bezstratny: wybory kodeków
Gdy otworzysz się na kodeki YUV z dziesiątką kolorów, również otworzą się twoje opcje. ffmpeg
ma wiele skutecznie bezstratnych kodeków.
Huffyuv
Najbardziej kompatybilną opcją jest Huffyuv . Dostajesz to przez -c:v huffyuv
.
Oryginalny kodek Windows Huffyuv obsługuje tylko dwa formaty pikseli: RGB24 i YUV 4: 2: 2. (W rzeczywistości obsługuje dwa warianty YUV 4: 2: 2, różniące się tylko kolejnością bajtów na dysku).
Starsze wersje kodeka FFmpeg Huffyuv nie zawierały obsługi RGB24, więc jeśli spróbujesz, a FFmpeg poinformuje Cię, że zamierza użyć yuv422p
formatu pikseli, musisz go zaktualizować.
FFmpeg ma również wariant kodeku Huffyuv o nazwie FFVHuff, który obsługuje YUV 4: 2: 0. Ten wariant nie jest zgodny z kodekiem Windows DirectShow Huffyuv, ale powinien zostać otwarty w każdym oprogramowaniu opartym na libavcodec
, takim jak VLC.
RGB24 - RGB 4: 4: 4 jest zasadniczo tym samym, co opcja przestrzeni kolorów RGB24 QuickTime Animation. Dwa kodeki będą się nieco różnić kompresją dla danego pliku, ale zwykle będą blisko.
Jest to w zasadzie to samo, co tryb YUV 4: 4: 4 używany przez powyższą opcję V308. Różnica przestrzeni kolorów nie ma praktycznej różnicy, ponieważ konwersja przestrzeni kolorów jest łatwa do wykonania w czasie rzeczywistym.
Dzięki bezstratnej kompresji Huffyuv udało mi się uzyskać wideo testowe do kompresji do około 251 Mbit / s w trybie RGB24, z identyczną jakością wizualną, jak w przypadku V308 lub AYUV. Jeśli AVI jest dla Ciebie absolutną koniecznością , instalacja kodeka Huffyuv jest prawdopodobnie mniej bolesna niż opłacenie 3-krotnego kosztu szybkości transmisji danych AYUV.
YUV 4: 2: 2 - Ten tryb jest o wiele bardziej praktyczny w przypadku wideo niż RGB24, co jest bez wątpienia powodem, dla którego ffmpeg
twórcy zdecydowali się na jego wdrożenie jako pierwsze. Jak można się spodziewać po teoretycznej redukcji discussed omówionej powyżej, mój plik testowy został zakodowany do 173 Mbit / s . To właściwie dokładnie ⅔, jeśli weźmie się pod uwagę fakt, że ścieżka dźwiękowa nie uległa zmianie między tymi dwoma testami.
YUV 4: 2: 0 - Ta opcja dziesiątkuje informacje o kolorze więcej niż 4: 2: 2, zmniejszając szybkość danych do 133 Mbit / s w moich testach.
Składając to wszystko razem:
$ 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
Chociaż podczas ffvhuff
pisania tego kodeku domyślnie jest ustawiony 4: 2: 0 i rzeczywiście obsługuje tylko ten format pikseli w używanej przeze mnie wersji, to się zmienia , więc powinieneś dołączyć flagę na wypadek, gdyby to się zmieniło.
Ut Video
Nowszą opcją w tym samym duchu co Huffyuv i FFVHuff jest Ut Video . Podobnie jak Huffyuv, istnieje kodek wideo systemu Windows, co oznacza, że każdy program systemu Windows, który może odtwarzać film, może odtwarzać filmy przy użyciu tego kodeka z zainstalowanym kodekiem. W przeciwieństwie do Huffyuv istnieje również kodek wideo dla komputerów Mac, więc nie jesteś ograniczony do oprogramowania opartego na FFmpeg ani libavcodec
do odczytu tych plików na komputerach Mac.
Ten kodek jest bardzo elastyczny pod względem przestrzeni kolorów, dlatego podam tylko kilka przykładów typowych przestrzeni kolorów:
4: 4: 4 RGB przez -f avi -c:v utvideo -pix_fmt rgb24
daje wyjście 178 Mbit / s
4: 4: 4 YUV przez -f avi -c:v utvideo -pix_fmt yuv444p
daje wyjście 153 Mbit / s
4: 2: 2 YUV przez -f avi -c:v utvideo -pix_fmt yuv422p
daje wyjście 123 Mbit / s
4: 2: 0 YUV przez -f avi -c:v utvideo -pix_fmt yuv420p
daje wyjście 100 Mbit / s
Podejrzewam, że 4: 4: 4 YUV radzi sobie lepiej w tym teście niż 4: 4: 4 RGB, mimo że te dwa są technicznie równoważne, ponieważ źródłowy wideo to 4: 2: 0 YUV, więc uporządkowanie danych w formacie YUV pozwala na lepszą kompresję bezstratną poprzez grupowanie częściowo redundantnych kanałów U i V w pliku.
FFV1
Inną interesującą opcją w tej przestrzeni jest własny FFV1
kodek FFmpeg . Jest to najczęściej używane jako kodek archiwalny, a nie kodek do odtwarzania lub edycji, ale ponieważ tak wiele programów opiera się na libavcodec
bibliotece stanowiącej podstawę FFmpeg lub można do niego przywiązać libavcodec
za pomocą narzędzi takich jak ffdshow
, może to być dla ciebie przydatne.
Domyślnie ffmpeg
zachowuje przestrzeń kolorów plików wejściowych podczas korzystania z elastycznego kodeka, takiego jak FFV1, dzięki czemu jeśli podasz jeden z oficjalnych plików MP4 Big Buck Bunny, które używają 4: 2: 0 YUV, to otrzymasz na zewnątrz, chyba że dasz -pix_fmt
flagę ffmpeg
. Daje to plik wyjściowy 63 Mbit / s .
Jeśli zmusisz FFV1 do korzystania z przestrzeni kolorów 4: 4: 4 YUV -pix_fmt yuv444p
, rozmiar pliku wzrośnie tylko do 86 Mbit / s , ale w tym przypadku nic nas nie kupi, ponieważ kodujemy z oryginału 4: 2: 0 . Jeśli jednak zamiast tego wprowadzisz zestaw plików PNG, tak jak w pierwotnym pytaniu, plik wyjściowy prawdopodobnie użyje przestrzeni kolorów bgra
lub bgr0
przestrzeni, które są po prostu przestawionymi wyżej argb
i rgb24
przestrzeniami kolorów.
Bezstratny H.264
Inną interesującą alternatywą jest Lossless H.264 . W chwili pisania tego jest to w zasadzie tylko x264 , ale osoby używające FFmpeg po stronie kodowania prawdopodobnie używają innego oprogramowania, które obejmuje również libx264
po stronie dekodowania , takiego jak VLC.
Najprostszym sposobem na uzyskanie takiego pliku jest:
$ ffmpeg -i frame%04d.png -c:v libx264 -qp 0 -f mp4 output.mp4
-qp 0
Flaga jest kluczem: wyższe wartości dają kompresji stratnej. (Możesz również dać, -crf 0
aby uzyskać ten sam efekt.)
Podobnie jak w przypadku FFV1, ffmpeg
spróbuję odgadnąć najlepszą wyjściową przestrzeń kolorów, biorąc pod uwagę wejściową przestrzeń kolorów, więc dla porównania z powyższymi wynikami uruchomiłem wiele przejść kodowania w pliku źródłowym Big Buck Bunny z różnymi przestrzeniami kolorów:
yuv444p : To właśnie ffmpeg
wybiera się, gdy podajesz mu strumień PNG RGB, jak w pierwotnym pytaniu, i uzyskujemy plik 44 Mbit / s z naszym plikiem testowym
yuv422p : Jest to podobna do domyślnej przestrzeni kolorów dla Huffyuv, ale w tym przypadku otrzymujemy plik 34 Mbit / s , całkiem sporo oszczędności!
yuv420p : Jest to ustawienie domyślne dla oficjalnych MP4 Big Buck Bunny, z którymi testuję , i skutkuje to plikiem 29 Mbit / s .
Strzeż się, że handlujesz dużą zgodnością, aby uzyskać tak małe rozmiary plików. Dlatego nawet nie zawracałem sobie głowy próbowaniem upchnięcia tego do kontenera AVI lub MOV. Jest tak ściśle związany z x264, że możesz równie dobrze użyć jego standardowego typu kontenera (MP4). Możesz również użyć do tego czegoś takiego jak Matroska .
Możesz zamienić część tej przepływności na krótszy czas kodowania, dodając -preset ultrafast
. Zwiększyło to szybkość transmisji mojego pliku testowego do 44 Mbit / s w trybie YUV 4: 2: 2, ale zostało zakodowane znacznie szybciej, zgodnie z obietnicą. Dokumenty twierdzą, że -preset veryslow
jest to również warte zachodu, ale spowodowało to znacznie dłuższy czas kodowania przy jednoczesnym oszczędzeniu tylko odrobiny miejsca; Nie mogę tego polecić.
Inne
ffmpeg
obsługuje także tryb tylko dekodowania dla Lagarith i tryb tylko kodowania dla Lossless JPEG . Te dwa kodeki są w rzeczywistości nieco podobne i powinny dawać pliki nieco mniejsze niż Huffyuv o tej samej jakości. Jeśli ffmpeg
deweloperzy kiedykolwiek dodają kodowanie Lagarith, byłaby to silna alternatywa dla Huffyuv. Nie mogę jednak polecić Lossless JPEG, ponieważ nie cieszy się szeroką obsługą dekodowania.
Perceptually Lossless: Lub możesz pewnie uciec z pewną stratą
Są też kodeki, które są percepcyjnie bezstratne. Jeśli nie podglądasz pikseli, prawie na pewno nie możesz powiedzieć, że dają one inne efekty wizualne niż dwie poprzednie grupy. Rezygnując z idei absolutnie zerowej zmiany między czujnikiem przechwytywania wideo a urządzeniem wyświetlającym, kupujesz znaczne oszczędności:
Apple ProRes :-c:v prores
lub-c:v prores_ks
- ProRes to kodek oparty na profilu, co oznacza, że istnieje kilka wariantów, z których każdy ma inną jakość niż kompromis kosmiczny:
ProRes 4444 koduje nasze wideo testowe z prędkością zaledwie 114 Mbit / s , ale jest to jakość VFX . Istnieją obecnie trzy różneprores*
kodeki w FFmpeg, aleprores_ks
obsługujetylkoProRes 4444, kiedy to piszę, za pomocą-profile:v 4444
opcji.
Jeśli zastanawiasz się, dlaczego zawracasz sobie głowę korzystaniem z ProRes 4444 zamiast Lossless H.264, sprowadza się to do kompatybilności, szybkości dekodowania, przewidywalności i kanału alfa.
ProRes 422 oszczędza jeszcze więcej miejsca, wymagając jedynie 84 Mbit / s, aby dać wynik, który można rozpoznać po ProRes 4444 tylko przez podglądanie pikseli. O ile nie potrzebujesz kanału alfa oferowanego przez ProRes 4444, prawdopodobnie nie ma powodu, aby nalegać na ProRes 4444.
ProRes 422 jest bliższym konkurentem do powyższej opcji Lossless H.264, ponieważ żadna z nich nie obsługuje kanału alfa. Będziesz chciał tolerować wyższą szybkość transmisji ProRes, jeśli potrzebujesz zgodności z aplikacjami wideo Apple pro, niższy narzut procesora do kodowania i dekodowania lub przewidywalną szybkość transmisji. To ostatnie jest ważne na przykład w przypadku koderów sprzętowych. Z drugiej strony, jeśli możesz poradzić sobie z problemami kompatybilności Lossless H.264, możesz skorzystać z przestrzeni kolorów 4: 2: 0, co nie jest opcją w żadnym profilu ProRes.
Wszystkie trzy kodery ProRes w FFmpeg obsługują profil ProRes 422, więc najprostszą opcją jest użycie -c:v prores
, a nie -c:v prores_ks -profile hq
lub zależenie od funkcji automatycznego profilowania, prores_ks
aby zrobić właściwą rzecz.
Istnieje jeszcze bardziej oszczędne profile ProRes, ale są one przeznaczone do filmów SD lub jako proxy dla plików w pełnej rozdzielczości.
Główny problem z ProRes polega na tym, że nie ma jeszcze szerokiego wsparcia poza światami Apple i pro video.
Avid DNxHD jest podobnym kodekiem do ProRes, ale nie jest związany ze światem pro Apple. Avid oferuje darmowe kodeki do pobrania dla Windows i Macintosh, a FFmpeg obsługuje je teraz-c:v dnxhd
.
Ponieważ DNxHD jest kodekiem opartym na profilu, takim jak ProRes, użytkownik wybiera profil ze wstępnie zdefiniowanego zestawu , który informuje kodek, jakiego rozmiaru klatki, częstotliwości klatek i szybkości transmisji należy użyć. W przypadku pliku testowego Big Buck Bunny -b:v 60M
profil jest najbardziej odpowiedni. Nic dziwnego, że wynikowy plik ma około 59 Mbit / s .
MJPEG o niskiej stracie :-vcodec mjpeg -qscale:v 1
- Jest to o wiele bardziej powszechne niż bezstratny JPEG. W rzeczywistości był to niegdyś dość powszechny kodek do edycji wideo i nadal jest często używany w takich rzeczach, jak sieciowe kamery wideo do przesyłania strumieniowego. Cała ta historia oznacza, że łatwo jest znaleźć oprogramowanie, które ją obsługuje.
Spodziewaj się dość dużej zmienności szybkości transmisji danych z tego kodeka. Test, który właśnie tutaj wykonałem, dał mi 25 Mbit / s dla wideo 720p. Jest to wystarczająco wysoki poziom kompresji, aby denerwować mnie stratami, ale dla mnie wyglądał całkiem nieźle. Opierając się na samej szybkości transmisji danych, powiedziałbym, że prawdopodobnie jest na poziomie jakości równej 12 Mbit / s MPEG-2 lub 6 Mbit / s H.264.
Składając to wszystko razem:
$ 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
Najważniejsze w tych metodach jest to, że jeśli nie robisz czegoś bardzo wymagającego, „wystarczająco dobry” naprawdę jest wystarczająco dobry.
Przypisy i dygresje
Polecenie powinno działać tak, jak podano w systemach Linux, macOS, BSD i Unix. Jeśli korzystasz z systemu Windows, możesz uzyskać wiersz polecenia POSIX za pośrednictwem Cygwin lub WSL .
Istnieje kilka powodów, dla których lista utworzona przez to polecenie nie pasuje idealnie do zestawu kodeków, które omówiłem powyżej:
Drugi grep
ma na celu odfiltrowanie nieodpowiednich koderów, takich jak bmp
kodeki, które nie są kodekami wideo, mimo że są oznaczone V
na tej liście. Chociaż technicznie możesz prawdopodobnie umieścić wiele z nich w kontenerze takim jak AVI, MP4 lub MKV, aby uzyskać wideo z jednym plikiem, plik ten prawdopodobnie nie będzie możliwy do odczytania przez nic poza programem opartym na ffmpeg
lub libavcodec
.
Jest kilka wyjątków od tego, na przykład -f avi -c:v ljpeg
daje to coś, co można nazwać „bezstratnym MJPEG”, ale z reguły nie jesteśmy zainteresowani umieszczaniem wielu zdjęć w pojemniku A / V, aby zrobić film. Chcemy tutaj powszechnie rozpoznawanych kodeków wideo, a nie semantycznych sztuczek.
Polecenie obecnie nie odfiltrowuje niektórych nieodpowiednich koderów, takich jak GIF, ponieważ nie są one obecnie opisane w ffmpeg -codecs
wyjściowych formatach bitmap
lub image
formatach plików.
GIF jest interesującym przypadkiem: obsługuje wiele ramek obrazu w jednym pliku GIF z informacjami o taktowaniu odtwarzania ruchu, ale z kilku powodów jest to całkowicie nieodpowiednie do naszej dyskusji tutaj.
Kilka opcji, które są pokazane są przestarzałe lub nigdy nie dostał dużo przyczepność, takich jak flashsv
, dirac
i snow
tak nie warto dyskutować je powyżej.
Niektóre opcje z tej listy są przeznaczone wyłącznie do stosowania w potokach między ffmpeg
instancjami lub między ffmpeg
innym programem, takich jak rawvideo
i wrapped_avframe
, i dlatego są nieodpowiednie do naszych celów tutaj.
Pod koniec powyższej dyskusji rozsądnie rozszerzam nieco zakres pytania, aby uwzględnić kilka starannie wybranych opcji stratnych, aby nie przechodzili pierwszego grep
filtra w powyższym poleceniu.
ffmpeg -i input.avi -c:v qtrle -pix_fmt rgb24 output.mov
.Skończyło się więc na tym, że moja odpowiedź była zbyt długa.
Podsumowanie TL; DR: Do bezstratnego przechowywania sekwencji obrazów użyj
libx264
lublibx264rgb
z-preset ultrafast -qp 0
. Jest prawie tak szybki jak ffvhuff, ze znacznie mniejszą przepływnością i dekoduje szybciej.huffyuv
jest znacznie szerzej obsługiwany poza ffmpeg, ale nie obsługuje tylu formatów pikseli, jakffvhuff
. To kolejny powód, aby używać h.264, zakładając, że twoje inne narzędzia mogą obsługiwaćHigh 4:4:4 Predictive
profil h.264, z którego korzysta x264 w trybie bezstratnym. x264 może wykonywać tylko wewnątrz, jeśli potrzebny jest szybki losowy dostęp do dowolnych ramek.Uważaj na błąd ffmpeg, który wpływa na libx264rgb podczas czytania z katalogu obrazów. (i kto wie, jakie inne przypadki.) Przed użyciem sprawdź, czy w konfiguracji nie ma strat. (łatwe
ffmpeg -i in -pix_fmt rgb24 -f framemd5
w źródle i bezstratnie skompresowane))edit:
utvideo
koduje i dekoduje dość szybko i jest znacznie prostszym kodekiem niż h.264. Jest to w zasadzie nowoczesnyhuffyuv
, z obsługą bardziej przydatnych przestrzeni kolorów. Jeśli kiedykolwiek masz problem z h.264, spróbuj utvideo next dla plików tymczasowych.edit2: PNG jako kodek RGB wydaje się dobrze, przynajmniej w zwiastunie Sintel.
Zobacz także moją podobną odpowiedź na podobne pytanie: https://superuser.com/a/860335/20798
W odpowiedzi Warrena Younga znajduje się wiele informacji na temat różnych surowych formatów i kodeków. Myślę, że odpowiedź byłaby bardziej przydatna, gdyby była krótsza, więc piszę nową odpowiedź. Jeśli pracujesz z oprogramowaniem, które nie obsługuje bezstratnego x264 lub ffvhuff, niektóre z tych informacji prawdopodobnie nadal są przydatne.
Najbardziej użyteczną definicją „bezstratnego” w tym kontekście jest to, że można odzyskać wejściowy bit po bicie. Bez obaw o pogorszenie jakości kodowania wideo, niezależnie od tego, co robisz.
http://en.wikipedia.org/wiki/Chroma_subsampling
Najlepiej unikać wielu konwersji przestrzeni kolorów. Błędy zaokrąglania mogą potencjalnie narastać. Jeśli zamierzasz operować na swoim filmie z filtrami, które działają w przestrzeni kolorów RGB, wówczas utrzymanie go w RGB ma sens, o ile wyższe prędkości transmisji nie stanowią problemu. Prawdopodobnie zamierzasz ostatecznie stworzyć
yuv 4:2:0
film, ale utrzymanie dodatkowej rozdzielczości barwy jest potencjalnie przydatne, w zależności od filtrów, które zamierzasz zastosować.Tak czy inaczej, bezstratny x264 i ffvhuff zarówno wsparcie RGB i YUV
4:4:4
,4:2:2
oraz4:2:0
. Sugerowałbym x264, ponieważ szybko dekoduje. Jeśli próbujesz odtwarzać wideo RGB HD w czasie rzeczywistym, spróbuj opengl zamiast xv, ponieważ xv w moim systemie akceptuje tylko wejście yuv. mplayer poświęcił więcej czasu procesorowi na konwersję przestrzeni kolorów.Źródło następujących testów kodera: https://media.xiph.org/ . https://media.xiph.org/sintel/sintel_trailer-1080-png.tar.gz Zapomnieli zgzipować pliki y4m dla przyczepy sintel, więc tarball png jest w rzeczywistości dużo mniejszy.
na przykład
Pamiętaj, że zapomniałem podać
-r 24
fps, więc nie będzie synchronizował av z dźwiękiem. (a liczby bitrate (ale nie rozmiar pliku) również będą wyłączone. ffmpeg domyślnie wynosi 25 fps). Procesor w tej maszynie to rdzeń pierwszej generacji (conroe) 2,2 GHz 2,4 GHz (E6600).wyniki:
Zauważ, że
mediainfo
nie wie o RGB h.264, nadal mówi, że pliki to YUV.Sprawdź, czy to naprawdę było bezstratne:
Możesz w ten sposób odzyskać oryginalne dane wejściowe PNG, tzn. Możesz tworzyć pliki PNG z identycznymi danymi obrazu.
Zwróć
-pix_fmt rgb24
uwagę na test x264. Dekoder h.264 ffmpeg wyprowadza wyjście gbrp (planarne, niepakowane), więc bity są takie same, ale w innej kolejności. „Kontener” framemd5 nie nakłada żadnych ograniczeń formatowania, ale dostaniesz ten sam md5 tylko wtedy, gdy bity są ułożone w ten sam sposób. Właśnie spojrzałem na to, co ffmpeg powiedział, że używa go do pix fmt, kiedy karmiłem go PNG, a następnie użyłem tego jako argumentu do-pix_fmt
dekodowania. Nawiasem mówiąc, z tego powodu vlc nie będzie odtwarzać plików RGB h.264 (do następnej wersji lub bieżących kompilacji nocnych): nie obsługuje formatu pikseli gbrp.YUV do użytku
libx264
, nielibx264rgb
. Nie musisz instalować wersji x264 RGB, rzeczywista biblioteka obsługuje obie te funkcje. Po prostu ffmpeg zaimplementował go jako dwa enkodery o różnych nazwach. Myślę, że gdyby tego nie zrobili, domyślnym zachowaniem byłoby pozostawienie wejścia rgb jako rgb i działanie bardzo wolno, przy jednoczesnym generowaniu znacznie wyższej wydajności bitrate dla tej samej jakości. (Nadal czasami musisz użyć,-pix_fmt yuv420p
jeśli chcesz420
zamiast444
wyjścia h.264.O ile nie tworzysz plików do przechowywania długoterminowego, zawsze używaj
-preset ultrafast
bezstratnego x264. Więcej ramek referencyjnych i wyszukiwania ruchu nie ma większego znaczenia dla bezstratnego, nie-animowanego materiału z dowolnym hałasem. CABAC wymaga ogromnej ilości procesora przy bezstratnej przepływności, nawet do dekodowania. Używaj tylko do celów archiwalnych, a nie do rysowania plików. (ultrafast wyłącza CABAC). CABAC zapewnia 10 do 15% oszczędności bitrate.Jeśli potrzebujesz, aby każda klatka była klatką kluczową, ustaw
-keyint 1
. Oprogramowanie do edycji wideo, które chce wycinać tylko klatki kluczowe lub w / e, nie będzie Cię ograniczać.Aby odpowiedzieć na pierwotne pytanie: Oto, co powinieneś zrobić, aby ominąć pliki tymczasowe podczas próbowania rzeczy etapami (np. Powolne usuwanie przeplotu, zapisywanie bezstratnego wyjścia przed próbowaniem innych rzeczy):
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
Jeśli naprawdę potrzebujesz danych wyjściowych w plikach graficznych, które możesz modyfikować za pomocą narzędzi do zdjęć, to koniecznie zdekoduj do formatu png. Nie stracisz nic więcej niż być może najmniej znaczącego z 8 bitów dla każdej wartości Y, Cb i Cr dla każdego piksela.
x264 wyjdzie NAPRAWDĘ dobrze, ponieważ jest tam wiele czarnych ramek z odrobiną tekstu, ściemnianie i ściemnianie oraz doskonałe podobieństwo między dużymi obszarami wielu ramek, z których udaje mu się skorzystać nawet przy
-preset ultrafast
. Podczas akcji na żywo nadal widzę x264 w rozmiarze połowy pliku ffvhuff (yuv420).Dla każdego, kto jest ciekawy: bezstratny kodowanie rgb w wysokim czasie procesora miało (rdzeń x264 144 r2525):
Zwróć uwagę na naprawdę dużą część ważonych ramek p, a także naprawdę dużą część pomijanych makrobloków. Każde przejście sceny jest zanikaniem, a nie cięciem, a x264 wykorzystuje przewagę, jeśli poświęcisz czas procesorowi, aby dowiedzieć się, jak to zrobić.
dalsze uwagi (kodeki stratne do edycji):
Do przewijania klipów do przodu / do tyłu zwykle preferowane są kodeki wewnętrzne (utvideo, ffvhuff, mjpeg, jpeg2000, pro-res, AVC-Intra). Wyobrażam sobie, że zwykłe AVC z krótkimi GOP (1/2 do 1 s) szoruje również całkiem dobrze, o ile oprogramowanie wie, co robi (dekodowanie najbliższej klatki I podczas szybkiego szorowania, dekodowanie w GOP, aby dostać się do między klatkami, jeśli jesteś wystarczająco powiększony na osi czasu, aby to było potrzebne).
Opublikowałem na ten temat kilka negatywnych rzeczy i https://video.stackexchange.com/ na temat pro-res, np. „O co chodzi, jeśli kompresja jest wolniejsza i gorsza niż bezstratny kodek”, ale ma kilka interesujących funkcji. Apple twierdzi , że może dekodować w połowie rozdzielczości, używając zaledwie 1/3 czasu procesora do dekodowania pełnej rez.
Implementacja prores ffmpeg prawdopodobnie nie jest tak zoptymalizowana pod kątem szybkości jak Apple, dlatego moje testy z ffmpeg sprawiły, że wygląda to wolniej. Prawdopodobnie nie warto go używać, jeśli masz przepływ pracy Wolnego oprogramowania z narzędziami opartymi na ffmpeg, ale warto spróbować, jeśli używasz komercyjnego oprogramowania.
Nie robię dużo edycji wideo, głównie tylko kodowania, więc nie mam pojęcia, jakie testy byłyby odpowiednie dla kodeków takich jak prory. Domyślam się, że może mjpeg byłby dobrą szybką alternatywą, jeśli short-GOP x264 nie działa dobrze. W dystrybucjach Linuksa są przyspieszone asm implementacje jpeg i jest to dość prosty kodek. Możesz w razie potrzeby zwiększyć lub zmniejszyć jakość, aby obniżyć jakość w porównaniu do rozmiaru pliku + prędkości kodowania / dekodowania. Jest starożytny, ale jeśli chcesz bardzo szybki kodek wewnątrz-wewnętrzny, może pobić x264.
W przypadku x264 spróbowałbym czegoś takiego
x264 --crf 10 --keyint=1 --preset superfast --tune fastdecode
(tylko wewnątrz, bez innych ustawionych elementów--avcintra-class
). Uwagasuperfast
(bez CABAC), lubfaster
,ultrafast
prawdopodobnie nie jest najlepszy do operacji stratnych. Myślę, że ultraszybka utrata jakości nie jest o wiele szybsza. Im niższa jakość (wyższa CRF), tym bardziej warto poświęcić nieco więcej czasu procesora na znalezienie lepszego kodowania. Jednak wiele z tego prawdopodobnie nie ma znaczenia przy rozmiarze GOP = 1.Przy rozmiarze GOP> 1, jeśli rzucasz tyle bitów w kodowanie, że lepsza inter-predykcja nie uratuje wielu bitów podczas kodowania reszt (ponieważ szum / ziarno / subtelne zmiany między ramkami są zachowywane bardzo dokładnie), to po prostu superszybki jest prawdopodobnie w porządku. W przeciwnym razie, z
--keyint=30
czymś, prawdopodobnie--preset veryfast --crf 12
byłoby interesujące.Teoretycznie jakość przy danym ustawieniu CRF powinna być stała dla wszystkich ustawień wstępnych. Jeśli szukasz mniejszych plików (szybsze dekodowanie), warto wymienić trochę jakości i trochę czasu kodowania.
źródło
Myślę, że ffmpeg faktycznie obsługuje konwersję do nieskompresowanego wideo.
Użyłem ffmpeg -i input.mp4 -vcodec rawvideo out.avi, a wynikowy .avi miał mniej więcej odpowiedni rozmiar pliku. Windows Media Player nie był w stanie poprawnie go odtworzyć, ale VirtualDub mógł go odczytać i nie zauważyłem żadnej utraty jakości obrazu.
źródło