Стиснення відео створює ще більший файл

17

Я використовую графічний інтерфейс (клацніть правою кнопкою миші => стиснути), щоб спробувати стиснути .tar, що містить 3 відео загальною сумою 1,7 ГБ (.H264 MP4). gzip, lrzip, 7z і т. д. всі не роблять нічого до розміру файлу, а стискана папка також становить 1,7 гб.

Потім я спробував запустити lrzip з командного рядка (на випадок, якщо це проблема з gui), і використав прапор -z (екстремальне стиснення), і це було моїм результатом.

введіть тут опис зображення

Як показує коефіцієнт стиснення, фактичний розмір стислої папки більший за оригінальний! Я не знаю, чому мені не пощастило, зокрема, lrzip повинен бути ефективним згідно з прочитаними випадковими оглядами та офіційними документами (файли більше, ніж 100 Мб, чим більше, тим краще) - див. Https: //wiki.archlinux. org / index.php / Lrzip

Чому я не можу стискати свої файли?

gzip

— Лі
джерело

2

Особисто я не буду турбувати архівування mp4 відео, оскільки ці відео вже стиснуті кодеком.

— дитяча коляска

А ви можете домогтися менших розмірів, використовуючи відеоконвертер / компресорні інструменти, такі як FFMpeg .

— Jet

дитяча коляска і Jet правильні. Це очікувана поведінка. Контрпродуктивно намагатися стиснути щось, що вже добре стиснене. Якщо ви використовуєте засоби перетворення відео, ви, можливо, зможете заощадити місце за рахунок якості відео (явне чи ні). Однак почніть з найвищої якості, яка має найменше стиснуту копію.

— John S Gruber

25

Як сказано вище @pram в коментарі, mp4 відео вже стиснуті, а інші відеоформати, ймовірно, також певною мірою використовують стиснення. Тому намагання стиснути їх не призведе до невеликого (якщо є) зменшення розміру (це також стосується, принаймні частково, зображень та музики). У цьому випадку, схоже, метадані (для самого стисненого файлу) можуть викликати збільшення. Єдиний формат стиснення, який може (і це сильна сила) призведе до деякого зменшення - xz.

З іншого боку, якщо ви хочете зменшити розмір цих відео, погляньте замість цього на повторне кодування відео, використовуючи щось на кшталт Handbrake.

— saiarcot895
джерело

3

Я вважаю, що webm має хороші показники стиснення в цілому. Набагато менший за mp4.

— Сет

@Seth насправді MP4 (це або AVC aka h.264, або новіший і кращий h.265 aka HEVC кодек) дає менші файли однакової якості (або кращої якості при тому ж розмірі файлу).

— Девід Балажич

@ DavidBalažic ми порівнюємо яблука та яблука тут, коли ми намагаємось поговорити про апельсини. mp4 і webm - це контейнери, вони не мають нічого спільного зі стисненням. Ви маєте рацію, що h.264 та h.265 обидва кодеки, що часто використовуються, в контейнерах mp4, але ви не можете порівняти h.265 з webm . h.264 можна порівняти з кодеком vp8, який зазвичай використовується в контейнерах webm, подібно до того, як h.265 можна порівняти з кодеком vp9, який зазвичай міститься в webm. tl; dr: використовуйте h.265 в mp4 і vp9 в webm, і ви отримаєте приблизно однакову якість / ефективність.

— forresthopkinsa

13

Дійсно, той факт, що файли вже стиснуті, не є вирішальною проблемою. Це так: стиснення в цілому може працювати лише в тому випадку, якщо в даних є якась надмірність . Це практично завжди відбувається для нестиснених файлів - однак, це не обов'язково очевидно, що таке надмірність. Алгоритми стиснення загального призначення в основному націлені на те, що очевидно в текстових файлах: багато слів з’являються не один раз, а багато разів в однаковій формі, можливо, фрази слів можна поєднувати і т. Д. Тощо. Алгоритми досить непогані узагальнюючи це на що завгодно, від списків телефонних номерів, кодованих ASCII, у китайській поезії до двійкового машинного коду, але вони не можуть працювати для будь -яких даних. Зокрема, медіафайли - це концептуальноаналогові дані в галасливому цифровому зображенні. Це означає, що насправді взагалі не існує жодного виду скорочення текстових файлів: деякі мотиви можуть повторюватися, але завжди з дещо іншою конфігурацією шуму датчика. Ось чому всі стислі формати зображення / AV використовують певно вибране перетворення як перший крок кодування, як правило, заснований на DCT або вейвлетах . Ці перетворення, грубо кажучи, переміщують частини зображення та частини шуму в різні місця, тому вони можуть бути добре відокремлені, і при стисненні втрат ви зберігаєте лише ту інформацію, яку ви вважаєте найбільш важливою, яка не включає шум, тоді як " хороша інформація "має багато надмірності. (Це насправді не так, як це працює, але начебто.)

Якби компресори загального призначення використовували ці перетворення, ефект був би протилежним: більшість цифрових відомостей насправді було б класифіковано як якийсь шум, оскільки йому не вистачає «гладкої» структури, яку ви знайдете в аналогових сигналах. А після стиснення відео з втратами, очевидно, ні аналогової гладкості, ні цифрового повторення не знайти більше (якби це було, кодеки використовували б інший етап bzip або щось таке!)

— ліворуч
джерело

12

Причина, що вам не пощастило, полягає в тому, що mp4 вже стиснутий, ви не можете його додатково стискати. Все, що ви робите, - додавати у файл інформацію заголовка формату стиснення.

Оскільки файли вже стиснуті і ви не можете їх більше стискати, це призводить до збільшення розміру файлу, оскільки все, що ви робите, - це зберігання тієї ж інформації та додавання ще кількох байтів інформації заголовка.

— тердон
джерело

5

Це приємний приклад принципу голуби .

Оскільки файл уже (втрачений) стиснутий, майже ніде не буде скорочення, а це означає, що ви вже з нульовим чистим посиленням. Як згадували інші, сам стислий формат має певні, як правило, незначні втрати у власних метаданих. Все це разом означає, що, мабуть, у наборі рівних чи менших файлів не залишилося жодної голубини, і, таким чином, ваші стислі дані потрапляють у набір великих файлів.

— Лівій
джерело

4

Вибачте, але це неправильне застосування зазначеного принципу. Ви можете застосувати ту саму логіку до файлу потужністю 1,7 ГБ, повного нулів, і отримати неправильну відповідь. Принцип голубої дуги використовується, як правило, для доказу існування файлів, що не стискаються, а не для підтвердження того, що якийсь конкретний файл насправді є нестислимим. (Останнє є незаперечним, оскільки функція складності Колмогорова не є обчислювальною функцією).

— nneonneo

1

@nneonneo Тоді сміливо виправляйте пов’язану статтю у Вікіпедії. Існування нестислимих файлів випливає безпосередньо з нього, а потім ви додаєте метадані стиснення і раптом у вас є файл, більший за оригінал. Це саме те, що я сказав. Доказом того, що файл не можна додатково стискати за заданої реалізації заданого алгоритму, є те, що вихід не менший. Звичайно, можливо також, що метадані просто більше, ніж виграш при стисненні, але я не впевнений, що описав би це як стиснене в користувальницькому сенсі.

— Лівій

@Livius Стаття у вікіпедії правильна: вона використовує принцип «голуби», щоб довести існування нестислимих файлів для будь-якого заданого алгоритму стиснення без втрат. Але ви не можете отримати нестислимість будь-якого конкретного файлу лише за принципом «gogeonhole».

— Девід Річербі

@DavidRicherby Так, але той факт, що файл не стискається заданою реалізацією заданого алгоритму, є доказом того, що він не стисливий. Якщо немає інших причин існування некомпресивних файлів, то випливає, що неспроможність стискати зумовлена ПП. Єдиною іншою можливою причиною було б те, що даний заданий алгоритм не бачить можливості зменшити його розмір, що, як видається, є випадком "під припущеннями алгоритму, немає меншого файлу з однаковою інформацією; такі випадки обов'язково існують через ПП ".

— Лівій

Точніше, ПП змушує алгоритм мати входи, зображення яких не лежать у просторі менших файлів. Кожне рішення, яке призводить до того, що зображення певного файлу не вміщується в цьому просторі, таким чином, знаходиться на деякому рівні, керованому ПП та компромісами, які він змушує (припускаючи, що це чітке визначення алгоритму стиснення). Тоді будь-який файл, зображення якого не менший, належить до набору, який ПП виключив із стискання. Доказом того, що певний файл не є стисливим, є його неспроможність стискати; у широкому розумінні, незготованість завжди є результатом ПП та його компромісів.

— Лівій

4

Якщо ви хочете стиснути ці файли, вам доведеться знизити якість.

Не знаючи, як довго і в якому форматі та типі вмісту ці файли важко визначити, чи є у цих файлів можливість скорочення без особливих видимих втрат якості.

BluRays з відео 1080p, як правило, перевищує 25 Гб, тому навряд чи ви вже в оптимальному співвідношенні якості та розміру для H.264.

Ви можете спробувати використовувати ffmpegабо avconvконвертувати файли.

Ви можете почати з ffmpeg -i input_file.mp4 -preset slower -crf 20 -c:a copy output_file.mp4

anconvКоманда буде працювати так само.

Збільште -crfзначення, щоб зменшити розмір і якість файлу, я не рекомендую більше 25.
Ви можете змінити налаштування на slow або mediumзбільшити швидкість, але розмір вашого файлу буде страждати порівняно з slowerрівним або навіть veryslow(якщо ви дуже терплячі!).
Більше налаштувань можна знайти тут: http://mewiki.project357.com/wiki/X264_Settings
Я рекомендую триматися подалі від більшості, оскільки попередньо встановлені налаштування забезпечують нормальні параметри за замовчуванням -tune за винятком.
Спробуйте позначати, якщо вміст є фільмом ( -vf hqdn3d) ви можете покращити візуальну якість порівняно з високим -crfзначенням.
Зменшіть вміст -vf scale=-1:720до 720p та -vf scale=-1:480480p для покращення швидкості кодування та підтримки якості.

— Даніель Хілл
джерело