Bezstratny uniwersalny format wideo

Próbuję znaleźć najbardziej odpowiedni bezstratny format wideo dla wideo 1280 x 720 25 klatek na sekundę. Film ma 4 minuty. Dźwięk będzie wynosił 320 kb / s mp3, to nie jest wielka sprawa. Idealne warunki:

Bezstratny (może być percepcyjnie bezstratny)
Kontener + kodek można odtwarzać na większości platform
Kontener + kodek można odtwarzać na nowoczesnych odtwarzaczach DVD (obsługujących inne formaty niż DVD)
Rozmiar jest mniejszy niż 700 MB

Czy to w ogóle możliwe? Walczyłem już trzy dni, bez żadnych satysfakcjonujących rezultatów, nawet otrzymując pliki 12 GB (wydaje się dużo - 3 GB / minutę).

video ffmpeg video-editing

— mrkva
źródło

Dla porównania patrz en.wikipedia.org/wiki/List_of_codecs#Lossless_compression

— artistoex

Przykro mi, ale praktycznie nie można uzyskać (wizualnie) bezstratnego wideo 720p z 4 minutami skompresowanymi do mniej niż 700 MB (przyjąłem tutaj Megabyte, a nie „mb”, co oznaczałoby „bit”). Dlaczego masz takie ograniczenie? Czy wideo nie może być zakodowane w formacie h.264?

— slhck 11.10.12

tak, MB, przepraszam za zamieszanie. Muszę zmieścić około 5 filmów x 4 minuty w 4 GB (średnie ograniczenia).

— mrkva,

Ponieważ otrzymujesz pliki 12GiB, zakładam, że używasz głębi kolorów 24Bit. Nieskompresowany strumień danych wideo wynosi około 4 GiB na minutę. To ogromna ilość danych. Co chcesz, to około 170 MB na minutę. Niezależnie od wybranego kodeka możesz to osiągnąć tylko przy statycznej scenie bez większego ruchu. Obawiam się, że musisz rozluźnić ograniczenie, aby być bezstratnym, zmniejszyć liczbę klatek lub tolerować większy rozmiar pliku.

— Marco,

Czy możesz wyjaśnić, że „Koder-kontener + może być odtwarzany na nowoczesnych odtwarzaczach DVD (obsługujących inne formaty niż DVD)”?

— llogan

Odpowiedzi:

Najlepszym faktycznym, matematycznie bezstratnym formatem, jaki znam, jest huffyuv, ale spowoduje to zabawnie ogromne pliki i nie będzie z nimi kompatybilny. Dla przypomnienia, ffmpeg może to zrobić za pomocą:

ffmpeg -i input -c:v huffyuv -c:a libmp3lame -b:a 320k output.avi

X264, koder h.264 typu open source, ma tryb bezstratny. To może wejść do kontenera MP4 i powinno być kompatybilne z większością sprzętu wyprodukowanego w ciągu ostatnich kilku lat. Pierwsze polecenie da dużą szybkość kodowania, ale duży plik; drugie polecenie zajmie znacznie więcej czasu, ale plik powinien mieć około połowy rozmiaru szybko zakodowanego (jednak nadal będzie dość duży):

ffmpeg -i input -c:v libx264 -crf 0 -preset ultrafast -c:a libmp3lame -b:a 320k output.mp4

ffmpeg -i input -c:v libx264 -crf 0 -preset veryslow -c:a libmp3lame -b:a 320k output.mp4

Jeśli to nie da ci wystarczająco małego pliku, CRF 18 jest ogólnie uważany za „wizualnie bezstratny”:

ffmpeg -i input -c:v libx264 -crf 18 -preset veryfast -c:a libmp3lame -b:a 320k output.mp4

Zasadniczo polecam bardzo szybki zestaw do kodowania z x264, z mojego doświadczenia wynika, że oferuje najlepszą kompromis między szybkością a rozmiarem (istnieje duży spadek wielkości pliku między superszybkim i bardzo szybkim, wolniejszym niż to i jest bardziej przyrostowy). Ogólna rada to używanie najwolniejszego ustawienia wstępnego, jakie można obsłużyć, są to: ultraszybkie, superszybkie, bardzo szybkie, szybsze, szybkie, średnie, wolne, wolniejsze, bardzo wolne.

Patrz tutaj dla przewodnika bardziej dogłębnej do kodowania x264.

— zła
źródło

Nie sugeruj veryfastjako dobrego domyślnego dla stratnego x264. mediumto dobry środek, ale zwykle używam veryslowdo ostatecznego kodowania czegokolwiek. Nie huffyuvjest nawet bardzo szybki, nie polecałbym go do niczego innego niż kompatybilność.

— Peter Cordes,

ffmpeg ma również kilka innych bezstratnych kodeków, które mogą być warte wypróbowania [przychodzi na myśl FFv1]. GL!

— rogerdpack

Nie libx264 obniża próbkowania dwóch kanałów kolorów (w YUV UV) o połowę w obu kierunkach, nawet jeśli używasz CRF równego 0, więc nie jest to naprawdę bezstratne. Ponadto przy błędach zaokrąglania nie jest gwarantowane, że dane po bicie kompresji x264 są indentyczne „bit po bicie”.

— Adisak

W moich eksperymentach z ffmpeg 3.4.1 libx264 używał formatu pikseli yuv444, gdzie „444” oznacza „nie próbkuj w dół części U, V”. I OP wyraźnie nie ma nic przeciwko błędom zaokrąglania: „może być percepcyjnie bezstratny”. Tak więc, @Adisak, twoje obawy są uzasadnione, ale nie dotyczą tej odpowiedzi.

— Jim DeLaHunt

ffmpeg i libx264 w trybie YUV będą negocjować format pikseli YUV na podstawie danych wejściowych. Jeśli więc wejściem jest YUV 4: 2: 0, to format wyjściowy pikseli również. Jeśli wejściem jest YUV 4: 4: 4 lub RGB, wówczas wyjściem jest YUV 4: 4: 4.

— Gyan

Obecnie lubię webm :

ffmpeg -i input.avi -c:v libvpx-vp9 -lossless 1 output.webm

Aby konwertować szybciej, z procesorami wielordzeniowymi, przeczytałem, że zaleca się użycie o jeden mniej wątku niż w prawdziwych rdzeniach. Tak więc, z 8 rdzeniem możesz określić 7 wątków takich jak to:

ffmpeg -i input.avi -c:v libvpx-vp9 -threads 7 -lossless 1 output.webm

— LonnieBest
źródło

Lubię używać zmiennej środowiskowej% NUMBER_OF_PROCESSORS%, aby określić liczbę wątków do użycia. Jeśli liczba wynosi 1 lub 2, użyłem wszystkich procesorów. Jeśli liczba wynosi 3 lub 4, używam wszystkich procesorów oprócz jednego. A jeśli liczba jest wyższa, używam wszystkich procesorów oprócz dwóch do liczenia wątków.

— Adisak

Jako wyrażenia DOS wygląda to tak: jeśli „% ADJUSTED_CPUCOUNT%„ EQU ”” (jeśli% NUMBER_OF_PROCESSORS% EQU 1 (ustaw ADJUSTED_CPUCOUNT = 1) inaczej, jeśli% NUMBER_OF_PROCESSORS% EQU 2 (ustaw ADJUSTED_CPUCOUNT = 2)%, jeśli% EQU 3 (ustaw ADJUSTED_CPUCOUNT = 2) jeszcze jeśli% NUMBER_OF_PROCESSORS% EQU 4 (ustaw ADJUSTED_CPUCOUNT = 3) jeszcze (ustaw / A ADJUSTED_CPUCOUNT =% NUMBER_OF_PROCESSORS% -2))

— Adisak

superuser.com/questions/155305/... mówi, że ffmpeg już wybiera optymalną liczbę wątków

— Boris,

Lepszym wyborem niż webm (obecnie) jest być może format av1 .

— LonnieBest,

-1

# POJEMNIK

Aby mieć pełną kompatybilność z odtwarzaczami DVD, musisz użyć formatu MPEG-2, kontenera, ograniczeń, kodeków. Sądzę, że „nowoczesne odtwarzacze” oznaczają zgodność z „mp4”, czyli w zasadzie odtwarzacz plików mp4 - H.264, MPEG-4, AVC => libx264
czytaj więcej: https://de.wikipedia.org/wiki /H.264

# WIDEO

Zajrzyj na https://trac.ffmpeg.org/wiki/Encode/H.264 , szczególnie w części dotyczącej „profilu” i „poziomu”, w celu zapewnienia zgodności
Korzystanie -profile:v high -level 4.0powinno to zrobić

# AUDIO

Unikaj ponownego kodowania ścieżek audio za pomocą stratnych kodeków - każdy format mp3 jest stratny, nawet 320 kb / s.
Użyj -c:a copyzamiast tego.

Do tej pory wykonał dla mnie całkiem dobrą robotę. brak problemów z synchronizacją.
Strumienie audio nie są powiązane z klatkami kluczowymi. Możliwe są dokładne cięcia.
Jeśli twoja ścieżka audio jest nagrywana z częstotliwością próbkowania 44 kHz, użyj max. 256 kb / s

Użyj stratnych kodeków tylko do ostatecznego kodowania wideo, jeśli chcesz spełnić określone wymagania.

Słyszałem o niektórych problemach z synchronizacją dźwięku, ale wygląda na to, że głównym problemem był chroniony materiał (!).

# Wreszcie

Wolałbym coś takiego:
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4

— d'oh
źródło

Opcja „-poziom 4.0” nie jest potrzebna. Poziom w x264 jest określany na podstawie rozdzielczości i FPS, więc zwykle nie ma sensu ustawiać go ręcznie, to niczego nie poprawi. O ile wiem, ffmpeg może automatycznie ustawić poprawny poziom, więc jeśli nie masz bardzo dobrego powodu, aby go wymusić i w pełni rozumiesz, jak wybrać poziom na podstawie FPS i rozdzielczości, nie powinieneś używać opcji „-level”. Jeśli zależy Ci na najwyższej kompatybilności, użyj profilu „bazowego” zamiast „wysokiego”.

— Lissanro Rayen,