Я использую GUI (щелчок правой кнопкой мыши => компресс), чтобы попытаться сжать .tar, содержащий 3 видео общим 1,7 гб (.H264 MP4). gzip, lrzip, 7z и т. д. ничего не делают с размером файла, а сжатая папка также 1,7 ГБ.
Затем я попытался запустить lrzip из командной строки (в случае, если это была проблема gui), и использовал флаг -z (экстремальное сжатие), и это был мой вывод.
Как показывает коэффициент сжатия, фактический размер сжатой папки больше оригинала! Я не знаю, почему мне не повезло, в частности, lrzip должен быть эффективным в соответствии со случайными просмотрами, которые я прочитал, и официальными документами (файлы размером более 100 МБ, чем больше, тем лучше) - см. Https: //wiki.archlinux. org / index.php / Lrzip
Почему я не могу сжать мои файлы?
Причина, по которой вам не повезло, заключается в том, что mp4 уже сжат, вы не можете сжать его дальше. Все, что вы делаете, это добавление информации заголовка формата сжатия в файл.
Поскольку файлы уже сжаты, и вы не можете их сжать дальше, это приведет к увеличению размера файла, поскольку все, что вы делаете, это сохранить ту же информацию и добавить еще несколько байтов информации заголовка ,
Действительно, тот факт, что файлы уже сжаты, не является решающей проблемой. Это так: сжатие вообще может работать только в том случае, если данные имеют некоторую избыточность в нем. Это практически всегда относится к несжатым файлам - однако не обязательно очевидно, что такое избыточность. Алгоритмы сжатия общего назначения в основном нацелены на то, что очевидно в текстовых файлах: многие слова появляются не только один раз, но и много раз в одинаковой форме, возможно, фразы слов могут быть объединены и т. Д. И т. Д. Алгоритмы довольно хороши в обобщая это на что-либо из ASCII-кодированных номеров телефонов по китайской поэзии на двоичный машинный код, но они не могут работать для каких-либо данных. В частности, медиафайлы являются концептуально аналоговыми данными в шумном цифровом представлении. Это означает, что на самом деле нет какого-либо типа перераспределения textfile: некоторые мотивы могут повторяться, но всегда с немного иной конфигурацией шумов датчиков. Вот почему все сжатые форматы изображений / AV используют какое-то умное преобразование в качестве первого шага кодирования, обычно на основе DCT или всплесков. Эти преобразования, грубо говоря, перемещают части изображения и шумовые части в разные местоположения, поэтому они могут быть разделены и с компрессией с потерей вы сохраняете только самую важную информацию, которая, по вашему мнению, является «важной», которая не включает шум, хорошая информация "имеет много избыточности. (Это не так, как это работает, но вроде.)
Если компрессоры общего назначения использовали эти преобразования, эффект был бы обратным: большинство сжатия вообще могут работать, только если данные некоторая избыточность в ней информации фактически была бы неправильно классифицирована как некоторый шум, потому что ей не хватает «гладкой» структуры, которую вы находите в аналоговых сигналах. И после потери сжатия видео, очевидно, не может быть найдена ни аналоговая гладкость, ни цифровое повторение (если бы это было так, кодеки использовали бы другой этап bzip или что-то сами!)
Это хороший пример принципа голубинки.
Поскольку сжатый файл уже (с потерями) сжат, практически нет сокращения, которое должно быть где угодно, а это значит, что вы уже достигли нулевой чистой прибыли. Как отмечали другие, сжатый формат сам по себе имеет определенную, обычно незначительную потерю в своих собственных метаданных. Все это объединяется, означает, что в наборе равных или меньших файлов, по-видимому, нет ни одной дырочки, и, следовательно, ваши сжатые данные попадают в набор более крупных файлов.
Если вы хотите сжать эти файлы, вам придется уменьшить качество.
Не зная, как долго и какой формат и тип содержимого эти файлы трудно определить, есть ли у этих файлов пространство для сокращения без видимых потерь качества.
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, чтобы улучшить скорость кодирования и поддерживать качество.