FFmpeg и общий кодирования видео тред №13 /ffmpeg/
Аноним (Microsoft Windows 10: Chromium based)
28/04/25 Пнд 13:58:55
№
1
В прошлый раз мы чуть не утонули в бамплимите из-за прокрастинации ОПа.
FFmpeg - мощнейший видео-комбайн с открытым исходным кодом подо все существующие в наблюдаемой части нашей галактики платформы. 99% бесплатного и платного графического конвертероговна используют его в качестве бек-энда, так что давай-ка заканчивай пользоваться интерфейсными зондами и осваивай сам инструмент напрямую. Вебмки для двача тоже сжимают итт.
https://www.youtube.com/watch?v=chOgKT3aHBE
https://www.youtube.com/watch?v=9kaIXkImCAM
Скачать тут: https://www.ffmpeg.org/download.html
Для первичного ознакомления с тем, что тут происходит, прочитай это: https://www.ffmpeg.org/ffmpeg.html - тебе будет много непонятно, но основные термины тебе зацепятся за ухо, позже разберёшься что к чему.
Полная документация по самому конвертеру и всем встроенным кодекам: https://www.ffmpeg.org/ffmpeg-all.html - можно пользоваться как справочником и подглядывать, когда что-то забыл.
Более прикладная и полезная для бытовых целей официальная вики: http://trac.ffmpeg.org/wiki - здесь ты найдёшь детальные методички с пошаговыми инструкциями для решения типовых задач типа склейки нескольких видео в одно, наложения звуков, хардсаба и т.д. Очень полезная для того, чтобы набить руку с параметрами.
Также на очень много вопросов отвечено на стековерфло и неожиданно в предыдущих тредах.
Подробный разбор режимов кодирования основных кодеков читай тут: https://slhck.info/posts/ - там всего несколько постов, но они очень крутые, чтобы понять, что происходит внутри этой адской машины.
Вики WebM-треда (частично устарело): https://github.com/pituz/webm-thread/wiki
и https://hive.blasux.ru/webm/s
Актуальный гайд по кодированию от анона из треда №5 (принимается критика, её было много в предыдущих тредах): https://github.com/megapro17/FFmpeg-Guide/blob/master/FFmpeg%20кодирование%20гайд.md
ИТТ выбираем идеальные режимы кодирования, тестируем нереализованные параметры и просвещаем неофитов ffmpeg.
P.S. Для проверки отображения на дваче вашего нестандартного медиаконтента специально существует аж целая доска: https://2ch.hk/test/ Просьба проводить тесты там, а не ИТТ.
Тред №0: https://2ch.hk/s/arch/2020-08-05/res/2591244.html
Тред №1: https://2ch.hk/s/arch/2021-02-25/res/2816778.html
Тред №2: https://2ch.hk/s/arch/2021-09-23/res/2979843.html
Тред №3: https://2ch.hk/s/arch/2021-11-13/res/3029626.html
Тред №4: https://2ch.hk/s/arch/2022-03-10/res/3056070.html
Тред №5: https://2ch.hk/s/arch/2022-06-29/res/3101682.html
Тред №6: https://2ch.hk/s/arch/2022-09-16/res/3144406.html
Тред №7: https://2ch.hk/s/arch/2022-11-14/res/3181555.html
Тред №8: https://2ch.hk/s/arch/2023-04-27/res/3205384.html
Тред №9: https://2ch.hk/s/arch/2023-07-25/res/3239508.html
Тред №10: https://2ch.hk/s/arch/2023-12-08/res/3301315.html
Тред №11: https://2ch.hk/s/arch/2024-06-09/res/3365343.html
Тред №12: https://2ch.hk/s/res/3441805.html
>>3600898 →
Я не знаю что ты там делаешь, но порядок действий в твоем случае такой:
1)Качаем видео с Youtube.
2)Качаем субтитры оттуда же.
3)Кодируем видео для снижения битрейта если нужно, параллельно пришивая к нему субтитры.
Команда:
>ffmpeg -i Input.mp4 -vf subtitles=Sub.srt -c:v libsvtav1 -preset 5 -pix_fmt yuv420p10le -crf 35 -svtav1-params enable-qm=1:qm-min=0:qm-max=8:irefresh-type=1 -c:a libopus -b:a 48k Output.webm
Тестировал на том трейлере с прошлого треда, сжатие более чем вдвое, субтитры пришиты, VMAF 93.25.
Нужно понимать что видео с Youtube уже пожато и если ты перекодируешь его с настройками на лучшее качество это повысит битрейт, но не вернет качество, потерянное при изначальном кодирровании.
Твоя команда для пришивания субтитров
>ffmpeg -i input_video.mp4 -vf subtitles=input_subtitle.srt output_video.mp4
не просто их пришивает, а перекодирует видео целиком. Ну а поскольку ты не указал кодек и параметры - используются значения по умолчанию (вроде libx264 crf 28, звук aac с хрен знает каким битрейтом). Думаю раздувание размера файла растет отсюда.
1 - просто умеренно пожатое видео с качественного оригинала.
2 - зашакалил в говно видео 1.
3 - пережал видео 2 на настройках даже лучше чем при получении видео 1.
Как видно размеры видео 1 и 3 почти не отличаются, однако лютые шакалы от сжатия на втором этапе никуда не делись.
> -pix_fmt yuv420p10le
Зачем 10bit, на ютубе все равно yuv420p только
>И ничего не перематывается, зато хорошо сжал, молодец.
Все перематывается, скачай и проверь. В браузере перед перемоткой он сначала должен загрузить его целиком. Ну а поскольку двач хостится на мусорном ведре и регулярно лагает - видео может в принципе не грузиться и перемотка будет меньшей из проблем.
Ну и перемотка не моментальная, а на 2-3 секунды нагружает процессор и вызывает подвисание видео. Лично я не вижу в этом ничего криминального, в конце концов шебм не для того нарезаются чтобы анон ползунок дрочил. Если включить и смотреть проблем никаких.
>Одиннадцать минут видео
>Не перематывается — это нормально
>это же шебем — скачал и перематывай
>не вижу в этом ничего криминального
Пчёл...
Когда двач не лагает - видео подгрузится и можно перематывать прямо в браузере. Когда лагает ты его в принципе не посмотришь.
>Одиннадцать минут видео
Здесь должна быть шутка про зумеров и тиктоки.
Еще раз - видео перематывается, просто не моментально.
Да я без понятия че там у них за формат, кодек создавался в первую очередь для 10-битного кодирования поэтому использую его.
1,чтобы можно было читать текст без особого напряга, но, в принципе, мне ж не книгу читать, так что можно не идеально четко (допустим это поучительные видео про компик и там кто-то вбивает команды)\
2,вообще максимум ужания, но чтобы при этом можно было видеть лица с метров с пяти хотя бы, когда допустим кто-то снимал камерой улицу пока ходил ногами (ну, или это запись геймплея обливиона, где хочется лица видеть (купи облу, кстати))
конечно решает битрейт, но... по большей части можно совет по разрешениям в этих ситуациях? 320 на 240 — это вообще доннище и не вариант.
можно конечно и править соотношения сторон, но мне лучше для 21:9, хотя моник 21:10 тоже есть
Для текста тебе нужно частоту кадров понижать. Статичный текст и в 0 FPS вообще-то читается, консольки хватит 10 допустим. Тогда ты сможешь битрейт высоким оставить и кадры чёткими.
Но если у тебя там не только текст, но все перемешано, то нужна переменная частота и это уже не так просто, но в целом можно. VFR обычно называется.
Разрешение – последнее что важно.
Ну, не знаю даже. Не с пустого же места обывалы пикабушного уровня компетенций создают картиночки а-ля графики битрейта для качественного видео в разных разрешениях, типа: "для 720 нужно 3000 битов, а вот для 1080 нужно 4000, для 480 можно и 2000...".
Смотрю, что придется осваивать ffmpeg как ни крути. Ведь ни одна программа (мне известны все, буквально любую я попробовал) не может в адекватный и автоматический переменный битрейт. Ни в одной проге нет полной настройки всех характеристик, и ни одна не способна адекватно юзать видеокарту. Но, как же в падлу пользовать консоль.
Правда ли что ваш ffmpeg не будет трогать те характеристики видео и музыки, которые не упомянуты в команде?
>не будет трогать характеристики
Хотя, да. стало очевидным, что не будет.
>Не с пустого же места обывалы пикабушного уровня компетенций создают картиночки а-ля графики битрейта для качественного видео в разных разрешениях, типа: "для 720 нужно 3000 битов, а вот для 1080 нужно 4000, для 480 можно и 2000...".
Это не константа. Какой битрейт тебе нужен для получения определенного уровня качества зависит от используемого кодека, его настроек, частоты кадров и сложности самого видео.
К слову эту утилиту собирал из исходников, а файл wav мне приходится в Audacity переделывать в mp3.
>ffmpeg -i Input.mp4 -codec:a libmp3lame -qscale:a 2 output.mp3
https://trac.ffmpeg.org/wiki/Encode/MP3
Эффект от настроек проявлялся на всех тестовых видео, чем сильнее сжимал - тем больше был прирост VMAF.
Как уже писал в прошлом треде:
enable-qm=1:qm-min=0:qm-max=8 - падение скорости кодирование на 5-10%
irefresh-type=1 - кратковременное подвисание видео при перемотке
Стоит ли оно (несколько десятых VMAF) того судите сами. Других полезных настроек не нашел.
Зумерская шутеечка про то что карты типа слабые — не смешна, ибо на 1080 часовое видео в hevc конвертится за 5 минут при том, что даже половинной загрузкой этим карты не пахнет, и пароли десятые карты подбирают со скоростью 200к в секунду при щадящем режиме без нагрева. Что за брух, где умельцы? Был бы я гоем, влил бы деньги не в зумзум-говно карту, а в жесткие диски по 6гб, чтобы всё в лослесс хранить на кодеке mpeg2, лааал бля.
Там же отдельный чип для кодировки видосов. Если он не поддерживает, то и не будет
Libmp3lame тоже компилить придётся?
Я уже скомпилированный качал отсюда
https://github.com/AnimMouse/ffmpeg-autobuild/releases
но полагаю что надо компилировать с ключом --enable-libmp3lame.
>неужели это убер-сложно
Да. Для этого надо вслепую раскурить аппаратную часть и обойти все её защиты, буквально хакинг.
>>3601538
Ну, то есть, дожили -- да? Упираемся в то, что чипированы неправильным чипом, а чтобы воспользоваться базовыми правами каждого человека на оптимизацию своего дискового пространства, нам нужно заплатить соцрейтинговые монетки с виртуальной карты барену, приобретая новый чип. Охуенно.
Нет, ничего не мешает конвертить vvc/AV1 на gtx1080. Вообще ничего, кроме указки барина, не выделившего тимки из трех челиков на создание простецкого (по меркам конгломерата) драйвера.
Пакет ogv поддерживает формат контейнеров Ogg, в котором обычно используется видеокодек Theora (в паре со звуком Vorbis). Theora, разработанный в начале 2000-х годов, является открытым кодеком, не требующим лицензионных отчислений. Хотя он менее эффективен, чем современные кодеки типа H.264 (AVC1), некоторые пользователи предпочитают его артефакты сжатия, которые могут выглядеть более плавными и менее блочными по сравнению с MPEG2 или AVC1 с низким битрейтом. Однако сжатие Theora устарело по сегодняшним меркам - современные альтернативы, такие как VP9 или AV1, предлагают более высокую эффективность и визуальное качество, но требуют большей вычислительной мощности.
>>3601571
Во-первых это не софтовая проблема, а железная. Нельзя просто взять и написать драйвер, чтобы у тебя железо новое из воздуха появилось.
Во-вторых твои базовые хуман райтс реализуют простые честные прямые процессорные мощности. Хоть и не обязаны, делают это только из доброты душевной. Не хочешь полагаться на милость — спонсируй свободный софт и свободное железо. Пора бы уже отказаться от идеализма, понимаешь?
Я на Linux скомпилил, как там с битрейтом работать?
Ну я же скидывал выше ссылку. Либо -q:a для переменного битрейта (диапазон 0-9, чем ниже тем лучше качество), либо -b:a для постоянного (допустимые значения 8k/16k/24k/32k/40k/48k/64k/80k/96k/112k/128k/160k/192k/224k/256k/320k).
добавляю пиксель и всё good
буквально..
а ещё кто знает это баг винды или чего, когда ты в батник копируешь путь к файлу, даже если он полностью на английском, консолька ругается и пишет типа у меня там иероглифы и пока ты ручками не перепишешь ничего не поможет это видимо редкий случай когда между дисками\системами переносишь файлы
Ширина и высота видео должны быть кратны 2 по нескольким причинам, связанным с тем, как кодек обрабатывает и сжимает видео.
1. Проверка на четность: Многие видеоформаты и кодеки, включая x264, используют блоки пикселей для обработки. Эти блоки часто имеют размеры 2x2, 4x4 и т.д. Если ширина или высота нечетные, это может привести к проблемам с выравниванием блоков, что затрудняет обработку и может снизить эффективность сжатия.
2. Сжатие и кодирование: Кодеки, такие как x264, используют различные алгоритмы сжатия, которые работают с блоками пикселей. Если размеры видео не кратны 2, это может привести к необходимости дополнительных вычислений для обработки краевых пикселей, что может снизить производительность и увеличить размер файла.
3. Совместимость: Некоторые устройства и плееры могут не поддерживать видео с размерами, не кратными 2, что может привести к проблемам с воспроизведением.
4. Четность для субдискретизации: В H.264 часто используется субдискретизация цветовой информации (например, 4:2:0), где цветовая информация кодируется с меньшим разрешением, чем яркостная. Это также требует, чтобы размеры были четными, чтобы правильно выровнять данные.