Saboteur

Первому файлу нужно сжать 402240 точек на кадр, 20 fps, получаем в секунду 8 млн точек. Видим сжатие 817 kb/sec
Второму файлу нужно сжать 921600 точек на кадр, 60 fps, получаем в секунду 55.3 млн точек. Видим 2526 kb/sec

Сравниваем 55.3 / 8 и 2526 / 817 = 6.9125 и 3.0917992656058751529987760097919

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

По поводу размера файлов, еще обращу внимание что 128 и 104 kb/s для звука - значимо влияет на размер файла. Звук вообще может занимать четверть а то и треть, ибо сжимается хуже, чем видео.

Ну собственно и все. Тут оба видео сжаты одним и тем же кодеком, и сложно предположить, что можно как-то заметно качественнее пережать, дефолтные настройки в современных кодеках обычно fits many, и какие-то кастомные настройки обычно влияют не столько на размер, сколько на адаптацию сжатия к контенту видео.

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

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

сейчас кабель это не просто кусок провода. Он должен обладать определенными характеристиками - пропускной способностью, количеством активных контактов.
Контроллер зарядки пытается определить кабель и соответственно определенному может установить мощность зарядки. Если кабель плохого качества (частично перебитый, тонкий, или контакты там не очень), то контроллер зарядки не будет пытаться по нему организовывать fast charge, для этого есть определенные стандарты.

следов входа в ssh нет, в файле /var/log/auth.log никакой активности не видно.

Значит не по ssh

Меняли пароль по ssh, но все равно хакер заходит.

Кроме пароля есть множество вариантов, как организовать себе доступ, если смог один раз на сервер залезть. А если еще и под рутом, то там вообще иногда проще переустановить.

Что делает хакер только изменяет файл на сервере и больше ничего

Так ищите другие варианты. Бэкдоры, уязвимости в вебсервере или других сервисах (удаленный мониторинг например). У каких пользователей есть доступ к фалу, от этого отталкивайтесь.

Настрой что-нибудь.

Поставь на линуксе веб сервер. Прикрути к нему php и mysql, поставь wordpress, убедись что все работает. Вот уже что-то есть. Сделай бэкап всего, поломай и восстанови из бэкапа.

Подними мониторинг, который будет что-нибудь мониторить, свободное место, нагрузку на CPU.

Настрой уведомления от твоего мониторинга на почту или в телеграм.

Ну вот уже для начала что-то будет.
Потом можно будет почитать как єто все делается другими инструментами. Или все тоже самое но в докере.

99% что у вас $PATH отличается в шелле и через крон, из-за этого не находит тот же yc
пропишите полный путь к yc или в кроне PATH настраивать надо