Сжатие видео создает еще больший файл

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

Затем я попытался запустить lrzip из командной строки (в случае, если это была проблема gui), и использовал флаг -z (экстремальное сжатие), и это был мой вывод.

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

Почему я не могу сжать мои файлы?

1
задан 12 May 2014 в 23:05

4 ответа

Причина, по которой вам не повезло, заключается в том, что mp4 уже сжат, вы не можете сжать его дальше. Все, что вы делаете, это добавление информации заголовка формата сжатия в файл.

Поскольку файлы уже сжаты, и вы не можете их сжать дальше, это приведет к увеличению размера файла, поскольку все, что вы делаете, это сохранить ту же информацию и добавить еще несколько байтов информации заголовка ,

12
ответ дан 24 May 2018 в 08:35

Действительно, тот факт, что файлы уже сжаты, не является решающей проблемой. Это так: сжатие вообще может работать только в том случае, если данные имеют некоторую избыточность в нем. Это практически всегда относится к несжатым файлам - однако не обязательно очевидно, что такое избыточность. Алгоритмы сжатия общего назначения в основном нацелены на то, что очевидно в текстовых файлах: многие слова появляются не только один раз, но и много раз в одинаковой форме, возможно, фразы слов могут быть объединены и т. Д. И т. Д. Алгоритмы довольно хороши в обобщая это на что-либо из ASCII-кодированных номеров телефонов по китайской поэзии на двоичный машинный код, но они не могут работать для каких-либо данных. В частности, медиафайлы являются концептуально аналоговыми данными в шумном цифровом представлении. Это означает, что на самом деле нет какого-либо типа перераспределения textfile: некоторые мотивы могут повторяться, но всегда с немного иной конфигурацией шумов датчиков. Вот почему все сжатые форматы изображений / AV используют какое-то умное преобразование в качестве первого шага кодирования, обычно на основе DCT или всплесков. Эти преобразования, грубо говоря, перемещают части изображения и шумовые части в разные местоположения, поэтому они могут быть разделены и с компрессией с потерей вы сохраняете только самую важную информацию, которая, по вашему мнению, является «важной», которая не включает шум, хорошая информация "имеет много избыточности. (Это не так, как это работает, но вроде.)

Если компрессоры общего назначения использовали эти преобразования, эффект был бы обратным: большинство сжатия вообще могут работать, только если данные некоторая избыточность в ней информации фактически была бы неправильно классифицирована как некоторый шум, потому что ей не хватает «гладкой» структуры, которую вы находите в аналоговых сигналах. И после потери сжатия видео, очевидно, не может быть найдена ни аналоговая гладкость, ни цифровое повторение (если бы это было так, кодеки использовали бы другой этап bzip или что-то сами!)

11
ответ дан 24 May 2018 в 08:35

Это хороший пример принципа голубинки.

Поскольку сжатый файл уже (с потерями) сжат, практически нет сокращения, которое должно быть где угодно, а это значит, что вы уже достигли нулевой чистой прибыли. Как отмечали другие, сжатый формат сам по себе имеет определенную, обычно незначительную потерю в своих собственных метаданных. Все это объединяется, означает, что в наборе равных или меньших файлов, по-видимому, нет ни одной дырочки, и, следовательно, ваши сжатые данные попадают в набор более крупных файлов.

5
ответ дан 24 May 2018 в 08:35
  • 1
    Извините, но это неправильное применение указанного принципа. Вы можете применить ту же логику к 1,7-гигабайт-файлу с нулями и получить неверный ответ. Принцип пигментной скважины обычно используется для доказательства существования существования несжимаемых файлов, а не для доказательства того, что любой конкретный файл на самом деле несжимаем. (Последнее невыполнимо, так как функция сложности Колмогорова не является вычислимой функцией). – nneonneo 26 April 2014 в 23:28
  • 2
    @nneonneo Тогда не стесняйтесь исправить связанную статью Википедии. Существование несжимаемых файлов следует непосредственно из него, а затем вы добавляете метаданные сжатия, и вдруг у вас есть файл больше оригинала. Это именно то, что я сказал. Доказательство того, что файл не сжимается при заданной реализации данного алгоритма , состоит в том, что результат не меньше. Конечно, также возможно, что метаданные просто больше, чем победа в сжатии, но я не уверен, что описал это как сжатое в пользовательском смысле. – Livius 26 April 2014 в 23:37
  • 3
    @Livius. Статья в Википедии верна: она использует принцип pigeonhole для доказательства существования существования несжимаемых файлов для любого заданного алгоритма сжатия без потерь. Но вы не можете получить несжимаемость какого-либо конкретного файла только из принципа pigeonhole. – David Richerby 27 April 2014 в 17:36
  • 4
    @DavidRicherby Да, но тот факт, что файл не сжимается данной реализацией данного алгоритма, является доказательством того, что он не сжимается. Если нет других причин существования несжимаемых файлов, то из этого следует, что отказ от сжатия связан с ПП. Единственная возможная причина может заключаться в том, что данный алгоритм не видит способа уменьшить его размер, что, опять же, похоже на случай «в условиях алгоритма», нет меньшего файла с той же информацией; такие случаи обязательно существуют из-за PP ". – Livius 27 April 2014 в 18:13
  • 5
    Точнее, PP заставляет алгоритм иметь входы, изображение которых не лежит в пространстве меньших файлов. Каждое решение, которое приводит к изображению заданного файла, не подходящего в этом пространстве, таким образом, находится на некотором уровне, управляемом ПП и компромиссами, которые он создает (при условии правильного определения алгоритма сжатия). Тогда любой файл, изображение которого не меньше, принадлежит множеству, исключаемому из сжимаемого ПП. Доказательство того, что данный файл не сжимается, - это его срыв сжатия; в широком смысле, несжимаемость всегда является результатом ПЗ и его компромиссов. – Livius 27 April 2014 в 18:20

Если вы хотите сжать эти файлы, вам придется уменьшить качество.

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

BluRays с видео 1080p имеет тенденцию превышать 25 ГБ, поэтому вряд ли вы уже достигли оптимального отношения качества к размеру для H.264.

Вы можете попробовать использовать ffmpeg или avconv для преобразования файлов.

Вы можете начать с ffmpeg -i input_file.mp4 -preset slower -crf 20 -c:a copy output_file.mp4

Команда anconv будет работать аналогично. [!d6 ] Увеличьте значение -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:480 для 480p, чтобы улучшить скорость кодирования и поддерживать качество.

3
ответ дан 24 May 2018 в 08:35

Другие вопросы по тегам:

Похожие вопросы: