Как я освободил более 400 ГБ места на диске обработав видео используя StaxRip

Однажды посмотрев на папку с видео курсами я понял, мне нужно с этим что-то делать, ибо 633 ГБ даже на HDD занимают значительный объем, о переносе видео на SSD объемом 480 ГБ и речи быть не может...

Конечно, когда в ПК есть полноценные HDD то хранение таких объемов информации не создает сложностей, но я не могу полноценные HDD впихнуть в компактный самодельный корпус, да и внешний HDD тоже не резиновый...

Папка на 633 Гб с видео курсами от НОУ "ИНТУИТ", они покупались на внешнем HDD, и мне не хотелось бы удалять их, как минимум потому что они достались не бесплатно:

На самом деле изначальный объем видео был немного больше, часть я уже преобразовал в HEVC и не записывал сколько точно там было, потому в качестве точки отсчета я возьму 633 ГБ.

Попутно я экспериментировал и на видео из других источников, 1.82 ГБ оптимизировал в 363 МБ, более чем существенно учитывая что это сделано без значительных потерь качества.

Экспериментируя с разными параметрами конвертации я заметил, что пережатое видео порой имеет выше качество чем оригинал, а причина тому подавление артефактов сжатия во время конвертирования.

На следующем скриншоте наверняка многие не поймут где оригинал, а где пережатое в HEVC видео:

Да, пережатое в HEVC оказалось слева, а оригинал справа...

К текущему моменту я уже сэкономил ~200 ГБ места на диске просто конвертируя видео из старых форматов в гораздо более современный HEVC.

Где взять StaxRip

Конечно же в основном источнике, я предпочитаю скачивать софт только из первоисточников и официальных сайтов, просто потому что мне неприятно ковыряться в помойках с кучей фальшивых кнопок "скачать" и прочими вредоносными скриптами так и навязывающими пользователю всевозможные вирусы.

Я использую немного более старую версию StaxRip, ибо она у меня уже есть и работает исправно, потому я не бегу за новой версией без необходимости в этом.

-

--

Как я конвертирую

Прежде всего покажу настройки, по умолчанию x265, качество 18 (Medium), пресет средний (Medium), звук просто копирует без обработки...

Я же выставляю пресет Very Fast, качество 28 (Extreme Low), аудио Opus ~80 KB/s, причем на обе дорожки аудио, ибо в файле аудио может быть на второй дорожке и тогда оно просто будет скопировано если оставить Copy/Mux по умолчанию.

Так как в заготовках нет Opus ~80 KB/s, я создал вручную профиль на основе стандартного Opus ~250 KB/s, ничего сложного в этом нет, если знать куда нажимать:

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

Ужасный момент интерфейса StaxRip это порядок работы, прослеживается некоторая "линуксоидность", когда все шиворот-навыворот, зато "бесплатно" (платит пользователь временем и нервами)...

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

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

* - Вместо "прыгайте" я хотел было написать одно матерное слово, но не стоит так делать в статьях, хотя очень хотелось...

Так или иначе конвертация пошла, но алгоритмы конвертации видео, как правило, не способны задействовать большое количество потоков, особенно с "легкими" настройками, потому у моего R7 2700X хоть и задействованы все ядра во время конвертации видео, но не весь вычислительный ресурс процессора.

В моем случае видна адекватная работа планировщика ЦП, к сожалению последний адекватный планировщик ЦП различающий потоки и ядра был в Windows 7, ни в Windows 10, ни тем более в Windows 11 / Linux нет адекватного планировщика, что был бы способен правильно распределить нагрузку используя максимум ресурсов ядер при активной технологии HT/SMT.

И так как у процессора остался незадействованный конвертером ресурс, я просто запущу вторую конвертацию в отдельном окне StaxRip.

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

Пока я возился с настройками и скриншотами, планировщик Windows 7 перераспределил нагрузку от первого конвертера между потоками оставив поток последнего ядра незадействованным, чтобы главный поток данного ядра выполнял свою работу не растрачивая ресурс на обслуживание второстепенного потока.

После запуска второго конвертера производительность первого немного поубавилась, но общая производительность при этом значительно выше стала (~90 FPS вместо ~61), теперь планировщик Windows 7 распределил задачи по всем потокам и ресурс процессора задействован почти полностью, именно в таком состоянии мой ПК проводит основную часть времени пока не обработаю все видео.

Особенно плохая многопоточность когда исходные файлы в низком разрешении, например 720x576, при работе с такими файлами можно в три окна конвертировать чтобы полностью задействовать ресурс процессора R7 2700X.

Хоть процессор у меня и нагружен под завязку порой, но это не мешает мне использовать 3 браузера, а так же играть в некоторые игры.

Конечно, в более-менее технически сложные игры не очень приятно играть ввиду низкого качества "fps", но играть возможно, хотя со старыми играми времен одноядерных процессоров проблем совершенно никаких.

Я фотографирую сейчас только по одной причине, скриншоты в разрешении 2560x1440 просто будут пережаты при вставке в статью, фото выглядит гораздо лучше, чем пережатые скриншоты...

И да, не смотрите на "мощность" процессора, сейчас у меня материнская плата от Asus, и она занижает показания выдавая 110-120 Вт, на самом деле процессор потребляет 130-140 Вт (XFR Boost).

Я хоть и играл одной рукой держа камеру другой, но даже так, моя команда оказалась... Ладно, хватит...

А еще есть быстрый доступ к рабочему столу, при этом у меня нет лишних задержек ввода и потерь производительности по вине композиции рабочего стола, она у меня просто отключена, Windows 7 позволяет это делать, как и ряд DE в Linux, но в Windows 10/11 такое не прокатит, увы...

-

--

---

Результаты

По поводу качества я не испытываю никаких проблем, да, качество звука немного хуже, чем в оригиналах, но это не критично учитывая тип контента, а к качеству видео у меня нет никаких претензий:

Разница в размере файла очевидна, и это далеко не лучший пример, ведь некоторые видео имеют размер после конвертации в 5-15 раз меньше чем у оригинала, при этом без значительных потерь в качестве, даже несмотря на профиль 28 (Extreme Low).

Конечно, когда оригинал содержит большое количество артефактов сжатия, то эти артефакты и на пережатом видео будут, и я не просто так профиль качества 28 (Extreme Low) выставил, ибо при таком профиле артефакты сжатия оригинального видео частично или полностью подавляются.

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

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

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

И еще пример хорошего сжатия, конечное видео в 14 раз меньше занимает места чем оригинал, но качество при этом сильно не пострадало, где-то немного подмылило, но это абсолютно не мешает никак, все самое важное отлично видно.

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

-

--

---

Заключение

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

В итоге я преобразовал 2638 файлов, и 283 файла осталось в исходном формате, т.е. есть еще что сжимать.

А теперь посмотрим на изменение размера папки с видео, файлов слегка поубавилось на последнем скриншоте, но сейчас я не конвертирую ничего и временных папок/файлов от конвертера нет внутри.

Итого я освободил 403 ГБ места за счет перевода видео в более современный формат HEVC, при этом часть файлов осталась в оригинальном формате, и я могу еще ~30 ГБ освободить обработав эти остатки.

В среднем получилось сжатие в 3 раза, какие-то файлы сжимались в 10-20 раз, какие-то в 1.5-2 раза, но в среднем при большом объеме получилось сжатие в ~3 раза, что весьма неплохо.

Можно было конечно сжимать сильнее, но моя цель была сжать без потери содержимого, и эта цель достигнута.

Почему я выбрал именно HEVC формат вместо AV1? Очень просто, для AV1 нужно городить огород чтобы оно выполнило мою задачу (я не нашел уже готовых инструментов пригодных к использованию), возможно AV1 сжал бы в ~4 раза при идентичном качестве, но было проще взять StaxRip и прогнать в пакетном режиме файлы...

По сути ситуация как с Windows и Linux, первое дает пользователю несколько вполне понятных кнопок для решения задачи, а второе заставляет насиловать терминал неизвестными заклинаниями без подсказок вместо того, чтобы решить задачу пользователя...

Но если сказать по существу, StaxRip вполне рабочий инструмент, есть свои недостатки, а порой вообще можно словить вылет с ошибкой если видео повреждено или "неправильное", но в целом это все можно "осилить", в отличие от систем на основе Linux, где "осиливать" толком нечего порой, нормальные драйверы видеокарт AMD например, невозможно осилить то, чего нет...

Чтобы вдруг никто не подумал что я выставляю конвертер как идеальный вариант для любого человека... Сами разработчики StaxRip говорят что это не типичный конвертер, для его использования следует почитать хотя бы документацию и начать экспериментировать, чтобы освоить конвертер.

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

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

И да, почему я не кодировал "аппаратно" видеокартой, а вместо этого якобы "программно" кодировал процессором? Но сразу предостерегу, никакой "программной" работой центральный процессор не занимается и не занимался никогда, ЦП всегда все делает аппаратно, и не иначе.

Есть программа, она либо исполняется вычислительной единицей (ЦП, ГП, МК, и т.п.), либо нет, если кто-то скажет что процессор "программно" умеет рисовать картинку в играх, нет, он это делает аппаратно, в таком случае программа использует ядра ЦП для вычислений вместо ГП... Иначе можно было бы сказать что видеокарта рисует картинку в играх "программно"...

Я не использую видеокарты для кодирования видео потому что блоки кодирования/декодирования в видеокартах "дубовые", как производитель их сделал, так они и работают, нет никакой гибкости... По этой причине видеокарты делают свою работу всегда хуже, чем это может сделать ЦП, так было всегда, и будет так всегда до тех пор, пока видеокарта не станет такой же полноценной вычислительной единицей как центральный процессор.

Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.