Форум русскоязычного сообщества Ubuntu


Считаете, что Ubuntu недостаточно дружелюбна к новичкам?
Помогите создать новое Руководство для новичков!

Автор Тема: Кодирование видео без потери качества и увеличения размера [в ffmpeg]  (Прочитано 3295 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Оффлайн Karpo

  • Автор темы
  • Новичок
  • *
  • Сообщений: 26
    • Просмотр профиля
Добрый день. Имею в распоряжении каталог видео mp4 разного качества и разрешения. Видео планируется транслировать в web. Некоторые видео-файлы содержат кучу ошибок, поэтому я хотел их перекодировать. Обычное копирование без кодирования в ffmpeg не помогло. В ходе экспериментов с ffmpeg я пришел к выводу, что с помощью него нельзя перекодировать видео без потери катчества и с сохранением текущего размера файла. Более того, несмотря на то, что утилита ffmpeg выполняется из командной строки, то есть требует некоторых знаний для её использования. Тем не менее программа ведёт себя довольно странно. Вместо того, чтобы взять незаданные параметры из источника, она использует дефолтные, это осложняет пакетную обработку видео. У всех видео разные параметры кодирования. Чтобы их учесть, потребуется анализировать каждое видео в bash-скрипте.

По теме поста я не нашёл для себя подходящего решения. Пока остановился на строке:

ffmpeg input.mp4 -c:v libx264 -preset placebo -c:a aac -movflags faststart output.mp4

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

Почему меня не устраивает найденный вариант:

1. Я лишь хочу исправить ошибки в файлах, но вынужден мириться с поторей качества. Это не тот случай, когда нужно что-то кодировать и мириться с недостатками результата.
2. Я плохо справляюсь с визуальным сравнением видео до и после. Мне нужно стабильное, алгоритмически обоснованное решение, на которое я могу полагаться без субъективной оценки результата.
3. Видео много, и я даже при всё желании не смогу проверить все их.
4. Некоторые видео итак очень плохого качества. Не хотел бы ухудшать его ни на сколько.

Главный вопрос:

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

Оффлайн Виль

  • Новичок
  • *
  • Сообщений: 26
    • Просмотр профиля
Не судите строго, если неправильно догадался.

Есть такие обстоятельства:

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

Есть открытые алгоритмы сжатия, есть проприетарные. ffmpeg не факт, что умеет все способы, которымии пожаты сабжевые видио. Надо проверять. Т.е. разжимать-то оно умеет, а жмёт уже другим кодеком. Надо смотреть и проверять. (mp4 в конце файла не определяет использованный кодек, mp4 - это только контейнер, в который можно записать в разном формате)

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

Есть софт, сравнивающий изображения по внешнему виду. digiKam, например, содержит в себе такой, должен быть и отдельный софт, или (вероятно) она в ком.строке умеет сравнивать два файла. Если бы делал самопальный анализатор качества, то дёргал бы скриптом стоп кадры из прозвольных моментов времени из старого и нового видео и сравнивал таким софтом.

Резюме: да, правильно, или руками, или скриптами, пребрать видео и обработать каждое уникальным способом. Если кроме шелла знаете др. современные языки, то советую на них обратить внимание, а уже из них вызывать шелл утилиты, когда у них нет простой алтьтернативы (проще будет).

Оффлайн xradio

  • Любитель
  • *
  • Сообщений: 56
    • Просмотр профиля
Karpo, найденая подсказка верная - сверхмедленная (placebo) и crf. Непопонятно со звуком. Зачем рекодировать? Если же нужно рекодировать, то либо в aac 320 или в he-aac 128. Последняя даст двойную экономию места по звуку, при почти том же качестве.

Оффлайн бамбук

  • Активист
  • *
  • Сообщений: 541
  • Kubuntu 20.04 LTS x86_64
    • Просмотр профиля
https://www.opennet.ru/tips/3063_video_ffmpeg_gstreamer.shtml
Цитировать
если что-то работает не так то для отладки полезен параметр "export GST_DEBUG=4".
Chuwi LapBook 14.1   ревизия ноутбука-3.0

 

Страница сгенерирована за 0.051 секунд. Запросов: 25.