Jak stworzyć nieskompresowany AVI z serii 1000 obrazów PNG przy użyciu FFMPEG

Jak mogę utworzyć nieskompresowany AVI z serii 1000 obrazów PNG przy użyciu FFMPEG?

Użyłem tego polecenia, aby przekonwertować input.aviplik na serię ramek PNG:

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

Teraz muszę wiedzieć, jak zrobić nieskompresowane wideo AVI ze wszystkich ramek PNG. Próbowałem tego:

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

Ale powstałe wideo traci dużo jakości w stosunku do oryginalnego AVI.

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 -codecsliście są -c:v r210, r10k, v410, v308, ayuvi 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ż ffmpegjest 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.pngi 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 1280x720do 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.)

ffmpegwpakuje się qtrledo 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 ffmpegsię 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.

ffmpegRealizacja 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. ffmpegwydaje 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. ffmpegma 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ć yuv422pformatu 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 ffmpegtwó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 ffvhuffpisania 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 libavcodecdo 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 rgb24daje wyjście 178 Mbit / s

• 4: 4: 4 YUV przez -f avi -c:v utvideo -pix_fmt yuv444pdaje wyjście 153 Mbit / s

• 4: 2: 2 YUV przez -f avi -c:v utvideo -pix_fmt yuv422pdaje wyjście 123 Mbit / s

• 4: 2: 0 YUV przez -f avi -c:v utvideo -pix_fmt yuv420pdaje 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 FFV1kodek 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 libavcodecbibliotece stanowiącej podstawę FFmpeg lub można do niego przywiązać libavcodecza pomocą narzędzi takich jak ffdshow, może to być dla ciebie przydatne.

Domyślnie ffmpegzachowuje 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_fmtflagę 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 bgralub bgr0przestrzeni, które są po prostu przestawionymi wyżej argbi rgb24przestrzeniami 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ż libx264po 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 0Flaga jest kluczem: wyższe wartości dają kompresji stratnej. (Możesz również dać, -crf 0aby uzyskać ten sam efekt.)

Podobnie jak w przypadku FFV1, ffmpegspró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 ffmpegwybiera 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 veryslowjest 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

ffmpegobsł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 ffmpegdeweloperzy 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 proreslub-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_ksobsługujetylkoProRes 4444, kiedy to piszę, za pomocą-profile:v 4444opcji.

    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 hqlub zależenie od funkcji automatycznego profilowania, prores_ksaby 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 60Mprofil 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

1. 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 .

2. 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 grepma na celu odfiltrowanie nieodpowiednich koderów, takich jak bmpkodeki, które nie są kodekami wideo, mimo że są oznaczone Vna 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 ffmpeglub libavcodec.

     Jest kilka wyjątków od tego, na przykład -f avi -c:v ljpegdaje 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 -codecswyjściowych formatach bitmaplub imageformatach 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, diraci snowtak nie warto dyskutować je powyżej.

   • Niektóre opcje z tej listy są przeznaczone wyłącznie do stosowania w potokach między ffmpeginstancjami lub między ffmpeginnym programem, takich jak rawvideoi 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 grepfiltra w powyższym poleceniu.

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 libx264lub libx264rgbz -preset ultrafast -qp 0. Jest prawie tak szybki jak ffvhuff, ze znacznie mniejszą przepływnością i dekoduje szybciej. huffyuvjest znacznie szerzej obsługiwany poza ffmpeg, ale nie obsługuje tylu formatów pikseli, jak ffvhuff. To kolejny powód, aby używać h.264, zakładając, że twoje inne narzędzia mogą obsługiwać High 4:4:4 Predictiveprofil 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 framemd5w źródle i bezstratnie skompresowane))

edit: utvideokoduje i dekoduje dość szybko i jest znacznie prostszym kodekiem niż h.264. Jest to w zasadzie nowoczesny huffyuv, 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:0film, 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:2oraz 4: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.

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

na przykład

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

Pamiętaj, że zapomniałem podać -r 24fps, 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:

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

Zauważ, że mediainfonie wie o RGB h.264, nadal mówi, że pliki to YUV.

Sprawdź, czy to naprawdę było bezstratne:

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

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 rgb24uwagę 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_fmtdekodowania. 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, nie libx264rgb. 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 yuv420pjeśli chcesz 420zamiast 444wyjścia h.264.

O ile nie tworzysz plików do przechowywania długoterminowego, zawsze używaj -preset ultrafastbezstratnego 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):

[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

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). Uwaga superfast(bez CABAC), lub faster, ultrafastprawdopodobnie 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=30czymś, prawdopodobnie --preset veryfast --crf 12był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.

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.