Kompresowanie filmów tworzy jeszcze większy plik

17

Korzystam z GUI (prawy przycisk myszy => kompresuj), aby spróbować skompresować plik .tar zawierający 3 filmy o łącznej pojemności 1,7 GB (.H264 MP4). gzip, lrzip, 7z itp. nie mają wpływu na rozmiar pliku, a skompresowany folder ma również 1,7 GB.

Następnie spróbowałem uruchomić lrzip z wiersza poleceń (na wypadek, gdyby to był problem z GUI) i użyłem flagi -z (ekstremalna kompresja), i to był mój wynik.

wprowadź opis zdjęcia tutaj

Jak pokazuje współczynnik kompresji, rzeczywisty rozmiar skompresowanego folderu jest większy niż oryginał! Nie wiem, dlaczego nie mam szczęścia, w szczególności lrzip powinien być skuteczny zgodnie z losowymi recenzjami, które przeczytałem i oficjalnymi dokumentami (pliki większe niż 100 MB, im większe, tym lepiej) - patrz https: //wiki.archlinux. org / index.php / Lrzip

Dlaczego nie mogę kompresować plików?

gzip

— Zawietrzny
źródło

2

Osobiście nie zawracam sobie głowy archiwizacją filmów MP4, ponieważ są one już skompresowane przez kodek.

— wózek

I możesz osiągnąć mniejszy rozmiar za pomocą narzędzi do konwersji / kompresji wideo, takich jak FFMpeg .

— Jet

wózek i Jet są poprawne. Jest to oczekiwane zachowanie. Próba kompresji czegoś, co już jest dobrze skompresowane, przynosi efekt przeciwny do zamierzonego. Jeśli korzystasz z narzędzi do konwersji wideo, możesz zaoszczędzić miejsce kosztem jakości wideo (pozornej lub nie). Zacznij jednak od najwyższej jakości najmniej skompresowanej kopii, którą posiadasz.

— John S Gruber,

25

Jak wspomniano powyżej w komentarzu @pram, filmy MP4 są już skompresowane, a inne formaty wideo prawdopodobnie również do pewnego stopnia wykorzystują kompresję. Dlatego próba ich skompresowania nie spowoduje niewielkiego (jeśli w ogóle) zmniejszenia rozmiaru (dotyczy to, przynajmniej częściowo, zdjęć i muzyki). W takim przypadku wygląda na to, że metadane (dla samego skompresowanego pliku) mogą powodować wzrost. Jedynym formatem kompresji, który może (i jest to silna siła) spowodować pewne zmniejszenie, jest xz.

Z drugiej strony, jeśli chcesz zmniejszyć rozmiar tych filmów, zamiast tego spróbuj ponownie zakodować filmy przy użyciu czegoś takiego jak hamulec ręczny.

— saiarcot895
źródło

3

Uważam, że webm ma ogólnie dobre wskaźniki kompresji. Znacznie mniejszy niż MP4.

— Seth

@Seth faktycznie MP4 (który jest albo AVC aka h.264 lub nowszy i lepszy h.265 aka kodek HEVC) daje mniejsze pliki o tej samej jakości (lub lepszej jakości przy tym samym rozmiarze pliku).

— David Balažic

@ DavidBalažic porównujemy tutaj jabłka i jabłka, gdy próbujemy rozmawiać o pomarańczach. mp4 i webm są kontenerami, nie mają one nic wspólnego z kompresją. Masz rację, że h.264 i h.265 są powszechnie używanymi kodekami w kontenerach mp4, ale nie można porównać h.265 z webm . h.264 jest porównywalny z kodekiem vp8 powszechnie stosowanym w kontenerach webm, podobnie jak h.265 jest porównywalny z kodekiem vp9, również zwykle zawartym w webm. tl; dr: użyj h.265 w mp4 i vp9 w webm, a uzyskasz mniej więcej tę samą jakość / wydajność.

— forresthopkinsa

13

Naprawdę fakt, że pliki są już skompresowane, nie jest kluczowym problemem. Chodzi o to: kompresja ogólnie działa tylko wtedy, gdy dane zawierają w sobie pewną nadmiarowość . Tak jest praktycznie zawsze w przypadku nieskompresowanych plików - jednak niekoniecznie jest oczywiste, czym jest nadmiarowość. Algorytmy kompresji ogólnego przeznaczenia są ukierunkowane przede wszystkim na rzeczy oczywiste w plikach tekstowych: wiele słów pojawia się nie tylko raz, ale wiele razy w identycznej formie, być może można łączyć frazy itp. Itd. Algorytmy są całkiem dobre w uogólniając to do czegokolwiek, od list numerów telefonów zakodowanych w ASCII, po chińskiej poezji, po binarny kod maszynowy, ale nie mogą one działać dla żadnego rodzaju danych. W szczególności pliki multimedialne są koncepcyjniedane analogowe w hałaśliwym odwzorowaniu cyfrowym. Oznacza to, że tak naprawdę nie ma żadnej nadmiarowości pliku tekstowego: niektóre motywy mogą się powtarzać, ale zawsze z nieco inną konfiguracją szumu czujnika. Właśnie dlatego wszystkie skompresowane formaty obrazu / AV wykorzystują sprytnie wybraną transformację jako pierwszy krok kodowania, zwykle oparty na DCT lub falkach . Te przekształcenia z grubsza przenoszą fragmenty obrazu i fragmenty szumu w różne lokalizacje, dzięki czemu można je łatwo rozdzielić, a dzięki kompresji stratnej zachowujesz tylko te informacje, które Twoim zdaniem są najważniejsze, co nie obejmuje szumu, a „ dobra informacja ”ma wiele redundancji. (Nie tak to działa, ale w pewnym sensie.)

Gdyby kompresory ogólnego zastosowania zastosowały te transformacje, efekt byłby odwrotny: większość informacji cyfrowych zostałaby błędnie zaklasyfikowana jako rodzaj szumu, ponieważ brakuje w niej „gładkiej” struktury, którą można znaleźć w sygnałach analogowych. A po stratnej kompresji wideo oczywiście nie można już znaleźć analogowej płynności ani cyfrowej rekurencji (gdyby tak było, kodeki używałyby innego stopnia bzip lub czegoś takiego!)

— po lewej stronie
źródło

12

Powodem, dla którego nie masz szczęścia, jest to, że mp4 jest już skompresowany, nie możesz go dalej kompresować. Wszystko, co robisz, to dodawanie do pliku informacji o nagłówku formatu kompresji.

Ponieważ pliki są już skompresowane i nie można ich dalej skompresować, powoduje to zwiększenie rozmiaru pliku, ponieważ wszystko, co robisz, to utrzymywanie tych samych informacji i dodawanie kilku dodatkowych bajtów informacji w nagłówku.

— terdon
źródło

5

To dobry przykład zasady szufladki .

Ponieważ plik jest już (stratny) skompresowany, nigdzie nie ma prawie żadnej redukcji, co oznacza, że masz już zerowy zysk netto. Jak wspomniano inni, sam skompresowany format ma pewną, zwykle nieznaczną utratę własnych metadanych. Wszystko to razem oznacza, że prawdopodobnie nie ma szuflady w zestawie równych lub mniejszych plików, a zatem skompresowane dane mieszczą się w zestawie większych plików.

— Livius
źródło

4

Przepraszam, ale to niewłaściwe zastosowanie tej zasady. Możesz zastosować tę samą logikę do pliku 1,7 GB pełnego zer i uzyskać niepoprawną odpowiedź. Zasada szuflady jest ogólnie stosowana do udowodnienia istnienia plików nieściśliwych, a nie do udowodnienia, że dany plik jest rzeczywiście nieściśliwy. (To ostatnie jest niepoliczalne, ponieważ funkcja złożoności Kołmogorowa nie jest funkcją obliczalną).

— nneonneo

1

@nneonneo Następnie popraw link do artykułu w Wikipedii. Istnienie niekompresowalnych plików wynika bezpośrednio z tego, a następnie dodajesz metadane kompresji i nagle masz plik większy niż oryginał. Dokładnie tak powiedziałem. Dowodem na to, że plik nie podlega dalszej kompresji w ramach danej implementacji danego algorytmu jest to, że wynik nie jest mniejszy. Oczywiście możliwe jest również, że metadane są po prostu większe niż wygrana kompresji, ale nie jestem pewien, czy opisałbym to jako skompresowane w sensie zorientowanym na użytkownika.

— Livius

@Livius Artykuł w Wikipedii jest poprawny: wykorzystuje zasadę szuflady do udowodnienia istnienia plików nieskompresowalnych dla dowolnego algorytmu kompresji bezstratnej. Ale nie można wywnioskować nieściśliwości żadnego konkretnego pliku tylko z zasady szufladki.

— David Richerby

@DavidRicherby Tak, ale fakt, że plik nie jest kompresowany przez daną implementację danego algorytmu, jest dowodem na to, że nie można go skompresować. O ile nie istnieją inne powody istnienia plików nieściśliwych, oznacza to, że brak kompresji wynika z PP. Jedynym innym możliwym powodem może być to, że dany algorytm nie widzi sposobu na zmniejszenie jego rozmiaru, co znów wydaje się być przypadkiem „przy założeniach algorytmu nie ma mniejszego pliku z tymi samymi informacjami; takie przypadki koniecznie istnieją z powodu PP ”.

— Livius

Dokładniej, PP zmusza algorytm do posiadania danych wejściowych, których obraz nie leży w przestrzeni mniejszych plików. Każda decyzja prowadząca do tego, że obraz danego pliku nie mieści się w tej przestrzeni, jest więc na pewnym poziomie zależna od PP i kompromisów, które wymusza (zakładając rozsądną definicję algorytmu kompresji). Następnie każdy plik, którego obraz nie jest mniejszy, należy do zestawu, który PP wyklucza z możliwości kompresji. Dowodem na to, że dany plik nie jest kompresowalny, jest jego brak; w szerokim znaczeniu, nieściśliwość jest zawsze wynikiem PP i jego kompromisów.

— Livius

4

Jeśli chcesz skompresować te pliki, musisz obniżyć jakość.

Nie wiedząc, jak długo i jaki format i typ zawartości tych plików trudno jest stwierdzić, czy w tych plikach jest miejsce do zmniejszenia bez widocznej utraty jakości.

BluRays z wideo 1080p jest zwykle większy niż 25 GB, więc nie jest mało prawdopodobne, że masz już optymalny stosunek jakości do rozmiaru dla H.264.

Możesz spróbować użyć ffmpeglub avconvprzekonwertować pliki.

Możesz zacząć ffmpeg -i input_file.mp4 -preset slower -crf 20 -c:a copy output_file.mp4

anconvKomenda będzie działać podobnie.

Zwiększ -crfwartość, aby zmniejszyć rozmiar i jakość pliku, nie polecam żadnych więcej niż 25.
Możesz zmienić ustawienie wstępne na slowlub mediumzwiększyć prędkość, ale rozmiar pliku ucierpi w porównaniu do, slowera nawet veryslow(jeśli jesteś bardzo cierpliwy!).
Więcej ustawień można znaleźć tutaj: http://mewiki.project357.com/wiki/X264_Settings
Polecam trzymać się z dala od większości, ponieważ ustawienia wstępne zapewniają rozsądne wartości domyślne, z -tunewyjątkiem tego.
Wypróbuj denoiser, jeśli treść jest filmem ( -vf hqdn3d) , możesz poprawić jakość wizualną w porównaniu do używania wysokiej -crfwartości.
Zmniejsz zawartość -vf scale=-1:720do 720p i -vf scale=-1:480480p, aby poprawić szybkość kodowania i utrzymać jakość.

— Daniel Hill
źródło