Казалось бы, довольно простой вопрос: «Чем сжать видео?». На ум сразу приходят Handbrake, Movavi Converter или ещё что-нибудь пострашнее. Однако когда речь заходит о более гиковском подходе с упором на максимальное качество и экономию места, такие программы сложно назвать инструментами. Равно как и для обратной ситуации, когда картинку нужно сильно сжать и сохранить в целостности большую часть полезной информации. Все эти программы только лишь предоставляют набор наиболее общих конфигов для обычной съёмки и 2D.
В этой статье мы изучим, как при помощи самого большого сборника свободных библиотек FFmpeg научиться кодировать видео самому именно под ваши задачи.
Содержание
- Кодеки
- Логика кодирования на примере видео
- Cамые базовые параметры, которые необходимо знать
- Базовые настройки кодирования
- Продвинуты настройки(-x265-params)
- Аппаратное кодирование
- Заключение
Кодеки
Даже сам вопрос о том, что такое кодек, ставит многих в тупик. Можно легко услышать ответ: «.avi, .mkv, .mp4...», но это лишь контейнеры, которые в большинстве случаев содержат видео, аудио и другие данные. А кодек — это преобразователь видео/аудиосигнала.
Существует три основных кодека для домашних устройств: HEVC (H265), H264 и AV1. Какой выбрать? Самый продвинутый — это HEVC: в нём много различных алгоритмов сжатия и самая тонкая настройка. Но есть минус, который может перечеркнуть все плюсы — его поддержка устройствами. Обязательно убедитесь, что устройства, на которых вы планируете смотреть контент, поддерживают этот кодек.
H264 — воспроизводится без проблем практически везде, но имеет оскорбительно плохую эффективность в сжатии видео в сравнении с другими актуальными кодеками. AV1 — открытый кодек, который сжимает видео более эффективно, чем HEVC, но требует значительно больше ресурсов как для кодирования, так и для декодирования, что, несмотря на его свободу от лицензий, делает его непригодным для использования за пределами таких онлайн-кинотеатров, как Netflix или Amazon Prime, которыми как раз и поддерживается его развитие.
Теоретически, видео размером 100 МБ при минимальных потерях при сжатии кодек HEVC уменьшит на 50%, H264 — на 30-35%, а AV1 — на 60%. Конечно, учитываются идеальные условия; в реальности эти значения обычно ниже на 10-15%.
В данной статье наш выбор падает на HEVC. Если же вам интересно, как настроить H264, который даже на микроволновке запустится, то на Хабре уже присутствует много статей о нём.
Логика кодирования на примере видео
Видео — это не просто набор картинок одна за другой. Видео — это смесь базового представления и алгоритмов для сжатия этой информации. Например, на экране шарик скачет из одного угла в другой всего за 24 кадра в секунду.
Вместо показа множества картинок кодек может сжать эту информацию. Один из алгоритмов отслеживает движение только мячика на картинке и вырезает его из общего изображения, а затем, выстраивая векторы движения, перемещает уже статичную картинку по нужным позициям. То есть, если бы раньше это был просто поток картинок, каждая из которых весит 1 МБ, то итоговый размер составил бы 24 МБ, но алгоритм разрезает нашу первую картинку весом в 1 МБ на 800 КБ фона и 200 КБ шарика. Фон остаётся неподвижным, поэтому информация о нём не будет обновляться в каждом кадре — она появится только один раз в самом начале. А единственным фактором увеличения веса видео будет шарик, для которого алгоритм записывает информацию о его отдельных позициях в каждом кадре.Эту информацию можно значительно сжать при помощи простой математики. Вместо перечисления чисел 1, 2, 3, 4… 9 можно записать это как функцию: 1+x, где x < 9.
Соответственно, логику можно усложнить, применяя всё более продвинутые методы и создавая очень эффективные алгоритмы сжатия. Использование проекции векторов, расчёт размера секторов кадра и т. п. Однако за это приходится платить: алгоритмам сложно находить такие закономерности, поэтому видео с хорошим сжатием кодируются довольно долго. Хотя итоговое воспроизведение видео занимает минимальные ресурсы.
Базовые настройки
Ни для кого не секрет, что FFmpeg — это программа с интерфейсом командной строки, а значит, мы оказываемся в среде, которая не слишком дружелюбна к обычному пользователю.
Самое простое — указание исходного и итогового видео.
ffmpeg -i "название видео.mp4" -c:v libx265 -с:a copy "название итогового видео.mkv"Из этого примера мы можем понять, что FFmpeg использует простые в понимании аббревиатуры: -i — input, -c:v — codec for video, -c:a — codec for audio (в нашем случае мы не указали кодек, и все аудио будут перенесены без изменений), и в этом нет ничего сложного. Далее будут приведены основные базовые настройки. Это лишь часть возможностей данного кодека, так как я опущу те, что могут быть не нужны для большинства задач. Все команды, приведённые в статье, работают как на Linux, так и на Windows.
Cамые базовые параметры, которые необходимо знать
▍ Rate
Начнём с параметра -r, который задаёт значение FPS (кадров в секунду) видео.
ffmpeg -i input.mp4 -c:v libx265 -r 60 output.mp4Если вам необходимо установить классические киношные 23.976 FPS, то используйте следующее значение:
ffmpeg -i input.mp4 -c:v libx265 -r 24000/1001 output.mp4
▍ Scale
Разрешение видео. FFmpeg масштабирует видео до указанного разрешения. Если мы вместо одной из координат укажем -1, то FFmpeg сам выставит необходимое значение, и изображение масштабируется правильно, без растягивания по одной из осей.
ffmpeg -i input.mp4 -c:v libx265 -scale 1920:1080 output.mp4Параметры
-ss и -to: используются для указания начала и конца обрезки видео в секундах.ffmpeg -i input.mp4 -c:v libx265 -ss 10 -to 60 output.mp4
▍ Crop
Кадрирование (обрезка) видео. Задаётся в формате: ширина: высота:x:y. X и Y — координаты верхнего левого угла обрезанной области относительно исходного видео. В данном примере мы обрезаем видео в разрешении 1920:1080 на 400 пикселей сверху, снизу и справа. Здесь вы можете сами понять логику, как делать правильный синтаксис команды.
ffmpeg -i input.mp4 -c:v libx265 -vf "crop=1120:280:400:400" output.mp4
Базовые параметры для кодирования
▍ Preset
Крайне важный параметр. От него напрямую зависит скорость выполнения кодирования и его качество.
Градация: 100% — условная единица измерения от максимальной скорости, которую вы можете получить при кодировании. Чем больше это число — тем медленнее будет кодирование.
0. ultrafast 100%
1. superfast ~110-130%
2. veryfast ~130-160%
3. faster ~160-200%
4. fast ~200-250%
5. medium ~250-350%
6. slow ~350-500%
7. slower ~500-700%
8. veryslow ~700-1000% >=
9. placebo ~2000-3000% >=
Говоря по сути, крайними значениями желательно не пользоваться — либо только в тех случаях, когда вам до самой крайности это надо. Наиболее целесообразным выбором для большинства процессоров, например, уровня 9100f и ниже, будет fast. Для остальных же уже середнячков и получше определённо стоит опускаться на более низкие значения, вплоть до slow. После slow скорость выполнения падает значительно, примерно в 6 раз; точнее, я даже не совсем смог выявить рамки падения скорости. Placebo я вообще ума не приложу, для каких сценариев он предназначен.
▍ Tune
Есть дополнительная поднастройка
-tune, которая оптимизирует кодирование для конкретного типа входных данных. Есть пресеты psnr, ssim, grain, zero-latency, fast-decode, animation. Для общего понимания, что поднастройка делает с видео, обратимся к -tune animation. Кодек оптимизирует кодирование для анимации, которая часто имеет большие участки однотонных областей, резкие края и повторяющиеся детали. То есть алгоритм адаптирован так, что уменьшается количество шума и число артефактов на краях линий объектов. Он также выделяет меньше ресурсов для обработки однотонных участков, тем самым уменьшая вес. Эту задачу решает и базовый пресет — fast, который выставляется автоматически, но делает это менее эффективно.ffmpeg -i input.mp4 -c:v libx265 -preset fast -tune animation output.mp4
▍ Bitrate
Битрейт на человеческом языке — это довольно абстрактное понятие. Количество выделяемого веса (битов) на одну секунду видео. Чем выше значение, тем лучше качество, но и вес тоже больше. Топорный инструмент, но нужный в случае жёсткого ограничения по весу видео. Например, для создания видеостикеров в Telegram может пригодиться.
ffmpeg -i input.mp4 -c:v libx265 -b:v "значение в кб" output.mp4Ещё более грубый подход, если говорить о видео, — это кодирование в два прохода:
-pass 1 и -pass 2. В первый проход собирается информация об участках видео, а во второй на основе этой информации распределяется битрейт. Это более эффективно сжимает видео до определённого веса. Но это уже смахивает на помешательство на самом процессе и обычно не имеет смысла этим пользоваться.ffmpeg -i input.mkv -c:v libx265 -b:v 5000k -pass 1 -an -f null NUL && ffmpeg -i input.mkv -c:v libx265 -b:v 5000k -pass 2 output.mkv
▍ CRF
Это инструмент, перекочевавший из кодека H264. По сути, это просто указание уровня качества видео, что значительно проще, чем работа с
-bitrate. Чем выше значение CRF, тем ниже битрейт видео и его размер. На первый взгляд CRF похож на preset, но на самом деле это менее сложный инструмент, поэтому указание большего или меньшего значения CRF в большей степени зависит от скорости вашего накопителя, нежели от процессора. Однако с помощью других настроек можно компенсировать высокое значение CRF. Можно провести аналогию: выгоднее передавать ценную информацию, чем лишние данные. Информацию можно упаковать значительно более качественно, если задействовать больше времени.ffmpeg -i input.mp4 -c:v libx265 -crf 20 output.mp4Рекомендованных значений не существует. Вам необходимо вручную сравнить, какое значение будет удовлетворительным для вашего материала. Для этого мы можем вырезать небольшой фрагмент из вашего видео, чтобы процесс занимал меньше времени.
ffmpeg -i input.mp4 -ss 00:00:05 -to 00:00:06 -c copy output.mp4*ss — stream start или же начало видео **to — до.
▍ Scale
При неправильном назначении разрешения (scale) могут возникнуть серьёзные проблемы с отображением видео на различных устройствах. Кодеки часто не обрабатывают значения, не являющиеся кратными двум, и даже при ошибке не сообщают, что причина именно в этом. Чтобы избежать подобных ситуаций, важно указывать корректные значения и придерживаться стандартных разрешений. Кроме того, многие Smart TV телевизоры с разрешением UHD, независимо от их стоимости, не поддерживают видео с разрешением, превышающим 4000 пикселей по ширине или высоте. Чтобы избежать проблем с воспроизведением, нужно внимательно выбирать параметры фильтров и настройки в процессе обработки.
ffmpeg -i input.mp4 -c:v libx265 -vf "scale=x:y" output.mp4*-vf — video filter, соответственно все необходимые видеофильтры записываем после него в кавычки и разделяем разные фильтры запятой, без пробела.
▍ Cropdetect
Обнаружение рамок для кадрирования. Иногда необходимо обрезать тёмные полосы по краям видео. Для этого существует специальная команда — cropdetect. Однако она только находит нужные значения. Чтобы передать их в FFmpeg, можно использовать простую команду с конвейером.
Пример команды для PowerShell:
ffmpeg -i input.mp4 -vf cropdetect -ss 0 -t 600 -f null - 2>&1 | findstr "crop" > temp.txt && for /f "tokens=" %j in (temp.txt) do set crop=%j && ffmpeg -i input.mp4 -vf "%crop%" output.mp4*-ss 0 -t 600 — мы можем применить данный параметр для сокращения времени обработки видео, так он будет собирать данные только с этого участка видео (от 0 до 600 секунд), а не со всего файла.
И аналогичная команда для Linux (bash):
video="your_video.mp4"; crop=$(ffmpeg -i "$video" -vf cropdetect -ss 0 -t 600 -f null - 2>&1 | awk '/crop/ { print $NF }' | tail -1); ffmpeg -i "$video" -vf "$crop" "${video%.*}_cropped.mp4"
Продвинутые настройки(-x265-params).
Этот сегмент уже значительно сложнее и требует больше внимания. Выбор подходящего пресета требует значительного времени на перебор всех вариантов. Потратив много времени на изучение документации, я отобрал то, что действительно работает и оказывает значительное влияние на качество изображения, во всех случаях.
▍ B-frames
Количество кадров, используемых алгоритмом для анализа. Чем больше кадров, тем медленнее происходит обработка, потому что здесь происходит расчёт векторов движения и выполняется более сложная работа. Максимальное значение — 16. но это не означает, что алгоритм всегда будет брать для анализа 16 кадров; он выберет самые оптимальные участки для расчётов, чтобы добиться наиболее эффективного сжатия информации. Значение 16 обычно считается заоблачным, но я не заметил значительного падения производительности, по крайней мере в случае с анимацией. На иллюстрации работа представлена в упрощённом виде, но она показывает основной принцип.
ffmpeg -i input.mp4 -c:v libx265 -x265-params bframes=12 output.mp4
▍ ME и subME
ME (motion estimation) — алгоритм оценки движения объектов. Может показаться, что это похоже на работу B-frames, однако это разные процессы. Если B-frames используют информацию о движении объекта в кадре, то ME определяет, какие объекты движутся, а какие нет, подсказывая кодеку при кодировании. Так можно избежать лишней информации о сдвигах на видео, тем самым уменьшив его вес. Эти алгоритмы не заменяют друг друга, а работают отдельно.
Значения
me=2 в целом хватает для большинства сценариев, но если вы пытаетесь чересчур сэкономить вес на видео, если в видео с высоким разрешением много мелких движущихся объектов, то вероятно значение 3 или 4 будет лучше. То есть, при недостаточном значении движущиеся мелкие объекты на фоне будут содержать артефакты. Однако повышение значения ME сильно снижает производительность.У ME есть дополнительный параметр — subME, он управляет точностью самого ME. Чтобы не запутаться: ME на каждом значении (1, 2, 3… 7) имеет совершенно разные алгоритмы нахождения движения, и они становятся всё сложнее и сложнее. Получается, что subME условно ставит количество циклов выполнения ME в одном и том же месте. Оптимальное значение subMEпри
me=2 — это 7 или меньше. Более высокие значения subME снова очень сильно влияют на производительность.ffmpeg -i input.mp4 -c:v libx265 -x265-params bframes=12:me=2:subme=7 output.mp4*Все дополнительные параметры в
-x265-params разделяются двоеточием.
▍ Pix format и Profile
Как правило, обычному пользователю рекомендуется оставлять стандартные настройки. Profile определяет глубину цветности и формат цветового пространства YUV (яркость и цветоразностные компоненты). Оба параметра очень сильно влияют на сложность воспроизведения конечного видео на устройстве. Почти никогда не стоит поднимать планку выше 8 бит и YUV420. Битность экрана у большинства устройств не превышает 8 бит. Вы в большинстве случаев просто усложните кодирование и воспроизведение видео до непригодного для использования уровня. Но лучше не трогать значение YUV. Вы можете выбрать профили main, main-10 или main-12.ffmpeg -i input.mp4 -c:v libx265 -profile main10 output.mp4Однако если вы хотите гарантированно иметь определённые значения YUV (что я и советую делать), то лучше воспользоваться параметром -pix_fmt
ffmpeg -i input.mp4 -c:v libx265 -pix_fmt yuv420 output.mp4*Чтобы указать значение битности (по умолчанию 8, если не указана), то после
yuv420 надо добавить ваше значение p10 или p12, как пример — yuv420p10.▍ HDR
HDR отвечает за то, будет ли картинка в HDR-качестве. Если оригинальная картинка не снята в HDR, включение этой функции не имеет смысла. Но по умолчанию она всегда отключена, поэтому стоит упомянуть о ней.
Пример с HDR10:
ffmpeg -i input.mp4 -c:v libx265 -pix_fmt yuv420p10le -x265-params colorprim=bt2020:colormatrix=bt2020nc:transfer=st2084:hdr10=1 output.mp4
Аппаратное кодирование
Помимо кодирования процессором, HEVC предлагает блок, предназначенный для гораздо более быстрого кодирования с использованием ГПУ. Для этого вам достаточно иметь установленные драйверы видеокарты с нужным тулкитом, а также указать одну из библиотек вместо libx265, hevc_nvenc, hevc_amf или hevc_qsv. Первая библиотека предназначена для NVIDIA, вторая — для AMD, и третья — для Intel. Скорость кодирования видео значительно вырастет, но, как всегда, есть особенность: будут заблокированы все более сложные настройки кодека, такие, как параметр -x265-params. А это, по сути, единственный параметр, который может повысить качество при меньшем размере видео после CRF и preset.
ffmpeg -i input.mp4 -c:v hevc_amf -rc cqp -qp_i 12 -qp_p 13 output.mp4*-qp_i и -qp_p играют роль аналога -crf, при этом
-qp_p всегда должно быть на 1 больше, чем -qp_i.Заключение
Надеюсь, что CLI-интерфейс FFmpeg открылся для вас с новой стороны. Даже такое неглубокое погружение, как в моей статье, дало многим из вас базис для почти любого сценария кодирования видео. Помните, что в видеосжатии не существует универсального решения. Каждый проект требует индивидуального подхода, и FFmpeg предоставляет безграничные возможности для экспериментов и оптимизации. Не бойтесь пробовать разные настройки и комбинации параметров, чтобы добиться наилучшего результата, соответствующего вашим требованиям.
Telegram-канал со скидками, розыгрышами призов и новостями IT ?
Комментарии (101)
Javian
29.09.2024 13:17+1Чем выше значение, тем лучше качество, но и вес тоже больше.
Была еще одна альтернатива - зафиксировать качество кадра. Позволяло избежать многопроходового кодирования и не рисковать, что установленный битрейт будет недостаточным для сцен с быстрыми движениями.
voldemar_d
29.09.2024 13:17+9Теоретически, видео размером 100 МБ при минимальных потерях при сжатии кодек HEVC уменьшит на 50%, H264 — на 30-35%, а AV1 — на 60%.
А если видео размером не 100 МБ, то проценты будут другими? И "при минимальных потерях" - это каких? На каком видеоматериале это оценивалось, по какой методике? Откуда взяты цифры, и почему "теоретически"?
Все эти проценты зависят от сложности кодируемого видео.
Realife Автор
29.09.2024 13:17+1Эта часть не требует уточнения в данной статье. Даже если усложнять этот абзац, то придем к одним и тем же выводам, так что я сразу сжал данную информацию в таком выводе.
voldemar_d
29.09.2024 13:17+1Да просто непонятно, зачем тут мегабайты вообще, если дальше всё в процентах. Тогда и пишите что-нибудь вроде: "видео размером 100 МБ при минимальных потерях при сжатии кодек HEVC уменьшит до 50 МБ, H264 — на ... мегабайт" и т.д.
Насчет "не требует уточнения" - дело Ваше. Просто все рассуждения о качестве при оценке кодирования видео обычно сопровождаются хоть какими-то оценками или измерениями. Откуда взяты все эти проценты, на основании чего эти числа написаны в статье?
voldemar_d
29.09.2024 13:17+10Битрейт на человеческом языке — это довольно абстрактное понятие. Количество выделяемого веса (битов) на одну секунду видео.
Битрейт - величина потока данных, измеряется в битах в секунду. С каких пор это вдруг стало абстрактным понятием?
SergeevSkvo
29.09.2024 13:17+3С тех пор, как битрейт (CBR) стал VBR;)
voldemar_d
29.09.2024 13:17+3Скорость движения бывает постоянной, а бывает переменной. Тогда и скорость, внезапно - абстрактное понятие?
SergeevSkvo
29.09.2024 13:17+1Верно, сама скорость не становится абстрактной, став переменной. Думаю, имеется в виду, что битрейт как качественная или количественная оценка кодирования не такая явная, как те параметры, которые передаются кодеку в командной строке в процессе кодирования.
voldemar_d
29.09.2024 13:17+1Скорость бывает мгновенной, бывает средней. С битрейтом примерно так же.
Как раз для оценки кодирования измерение битрейта подходит лучше, чем параметры, которые передаются кодеру. В зависимости от характера видео (сложности, наличия мелких деталей в кадре), одни и те же параметры кодирования могут выдать разный результат.
SergeevSkvo
29.09.2024 13:17Вот именно, анализ полученного битрейта говорит о характеристиках самого видео, но не параметров кодирования, а вот анализ значений параметров кодирования позволяет судить о применяемых алгоритмах кодирования и оценивать качество кодирования применительно к конкретному видео (те самые сложность, мелкие детали, движения, переходы). Ниже было хорошо сказано, что при кодировании блокбастеров потребуется большое число проходов, и оценить сложность и качество кодирования одним лишь полученным битрейтом - и есть, как мне кажется, весьма абстрактная задача, делающая битрейт абстрактным параметром. В отличии от того-же количества проходов.
voldemar_d
29.09.2024 13:17оценить сложность и качество кодирования одним лишь полученным битрейтом
Никто и не предлагал оценивать сложность и качество кодирования одним лишь полученным битрейтом. Речь о том, что битрейт сам по себе - не абстрактное понятие, а вполне конкретное и измеряемое. Какое при этом за ним стоит качество - это уже другой вопрос. Особенно, если для понятия "качество" никаких других метрик не предлагается.
В отличии от того-же количества проходов
Количество проходов - это количество проходов. И как, по-вашему, можно количеством проходов оценить сложность и качество кодирования? Просто "чем больше проходов - тем выше качество"? А само качество как и чем измеряется?
SergeevSkvo
29.09.2024 13:17Качество можно, например, оценивать чисто визуально, замыленностью стоп-кадров при просмотре. Но согласен, битрейт сам по себе лишь лишь техническая характеристика потока, лишённая абстрактности. А вот при просмотре конечного видео с одинаковым (похожим) битрейтом но разным кодированием (с разным тем-же числом проходом) может дать разные по субъективной оценке качества результаты.
voldemar_d
29.09.2024 13:17Для оценки качества существуют вполне объективные, т.е. измеряемые метрики, а не только визуальная оценка, что субъективно.
Многопроходное кодирование само по себе не факт, что позволит значительно повысить качество при одном и том же битрейте. Это, опять-таки, зависит от сложности кодируемого материала.
SergeevSkvo
29.09.2024 13:17+1Всё верно, для оценки качества кодирования лично я ориентируюсь именно на визуальную, априори субъективную, оценку полученного материала. Подскажите, какие есть объективные, измеряемые метрики оценки качества? Битрейт прошу не предлагать;) (шутка) - я действительно не знаю, как оценивать качество материала цифрами, на ум приходит разрешение, кадров в секунду, и ... почему-то, больше ничего:(
voldemar_d
29.09.2024 13:17Оценивать можно разницу между исходным и перекодированным видео. Кое-что об этом написано здесь.
SergeevSkvo
29.09.2024 13:17Спасибо, весьма познавательная статья! Цитата: "...результирующее значение (метрик) характеризует лишь количественное отличие от оригинала без оценки его качества в привычном понимании...." Таким образом, оцениваются соотношение сигнал/шум, искажения цветности, яркости, контрастности, движения и т.п. с разной степенью корреляции метрики с субъективной оценкой качества человеком, с малой в оценке PSNR (вероятно, самой быстрой) и с большой в VMAF (вероятно, самой ресурсоёмкой). Предлагаю оставить отнесение битрейта к абстрактной величине на усмотрение автора.
Javian
29.09.2024 13:17+2Название программы я не помню, но была в 2000-х программа которая покадрово сравнивала исходник и пережатый файл и цифрах и картинках показывала проблемные места, где артефакты были выше установленного пользователем минимума. Кажется @3Dvideo имел к разработке этой программы отношение.
PS https://compression.ru/video/codec_comparison/introduction_en.html
nikolau
29.09.2024 13:17+2Раньше думал, что кодеков видео очень много, типа divx, Xvid, mpeg 1...4 и и.д.. Приходилось ставить codec pack, ато какие-то видео не запускались и требовали установить кодек. А сейчас, оказывается, всего 3 осталось. А что с другими стало, они просто не актуальны стали? Или это те же кодеки, только новые версии?
Realife Автор
29.09.2024 13:17+5Можно считать их мертвыми на данный момент. Они устарели. Конечно никто никуда не пропадал, но ими вне специфичных задач, нету смысла пользоваться. Есть ещё всякие prores от apple, но у меня не про это статья.
А что касается запуска видео, то ну просто установите VLC и бед знать не будете.
Loco2k
29.09.2024 13:17Их и сейчас много, но они узкоспециализированные.
Из потребительских остались только MPEG, они же h264/265/266, они же AVC/HEVC/VVC, и свободные кодеки от Гугла и ко VP/AV1
Отдельное место в аду заготовлено для китайских хакнутых кодеков mpeg, которые любят пихать в камеры наблюдения и т.п.
voldemar_d
29.09.2024 13:17+1MPEG - это не название конкретного кодека. Есть MPEG1 и MPEG2, например.
MountainGoat
29.09.2024 13:17В камеры наблюдения пихают MJPEG который перечисленным даже не родственник. Отличается хорошим соотношением сложности закодирования к сжатию, почему и применяется в камерах.
Loco2k
29.09.2024 13:17Уже давно не пихают mjpeg, сильно устарел.
MPEG и JPEG соседние группы в рамках одной организации по стандартизации. Грубо говоря, I-frame кодируется как jpeg-картинка, а остальные кадры как изменения относительно этой картинки. Сейчас к этому добавили более хитроумные методы кодирования, ну и jpeg на месте не стоит.
saege5b
29.09.2024 13:17+5Для качества нужно переменный битрейт и минимум два прохода. А если есть резкие переходы от статичной картинки к динамическим сценам с перепадами яркости, то можно и три прохода.
Кстати, за это профили/пресеты и отвечают. По возможности, "для себя", лучше не стесняться. Что бы потом, не было мучительно больно за криво пожатое с удалённым оригиналом.
ПС. Эх, были времена... 0,3 к/с... :)
CaptGg
29.09.2024 13:17+9Для максимального качества, как самоцели, используется тот же CRF, это самый современный алгоритм для переменного битрейта.
Два прохода кодирования нужны исключительно когда необходимо получить максимальное качество при заранее известном конечном размере файла. Чтобы максимально точно вписаться в размер какого-то носителя.
Во всех остальных случаях CRF даст лучшее качество, но не особо предсказуемый размер.
saege5b
29.09.2024 13:17+11/2 Проход создаёт карту битрейта по динамике сцен, так как кодировщик не знает, когда что случится.
Особенно это заметно по первым кадрам перехода статичной сцены, в ультрадинамичную, или на стыке резкого перехода яркости (очень ярко - очень темно, или наоборот). Особенно подобные косяки вылезают на ультрабольших экранах с диагональю метра полтора и выше.
Немного качеству помогают и разные опорные кадры, для правильного раставления которых, опять же необходимо знать расположение сцен.
Если выводить техническую информацию, то в фильмах с большим количеством подобного добра, карта битрейта устаканивается к 5-7 проходу.
Дальнейшее улучшение можно добиться индивидуальной матрицей квантизации.
CaptGg
29.09.2024 13:171/2 Проход создаёт карту битрейта по динамике сцен, так как кодировщик не знает, когда что случится.
Кодировщик знает, что происходит прямо сейчас и этого достаточно. Что будет дальше не имеет абсолютно никакого значения, если у вас не стоит цели ограничить битрейт, чтобы уместиться в заданный размер файла.
CRF дает наилучшее качество всегда. В этом суть алгоритма использующего фактор постоянного оценивания. Не обращать внимание какой битрейт требуется для сцены, а использовать такой, чтобы получить заданный уровень качества. Карта битрейта для него бесполезна.
Loco2k
29.09.2024 13:17Самый продвинутый это h266 :)
Исходить при выборе кодека нужно из возможностей аппаратного декодера устройства воспроизведения. Если брать первые умные телики как образец, то там и h264 может не завестись при некоторых настройках.
Если кодировать архив хоумвидео для уменьшения места, то нужно брать аппаратный AV1 или HEVC и кодировать с переменным битрейтом. Чем выше разрешение, тем круче кодек разумнее использовать.
B-фреймы я бы большими не делал, как и GOP, т.к. это выйдет боком в случае битовых ошибок.
Realife Автор
29.09.2024 13:17Имелось ввиду что h265 самый продвинутый среди представленных ранее в статье вариантов. И не в плане качества кодирования, а количества параметров кодирования и их влияния на картинку, то есть он более гибкий чем остальные варианты.
Loco2k
29.09.2024 13:17У вас критериев нет по которым выбирать. Я вообще с трудом представляю бытовой кейс кодирования видео. Архив домашнего видео? Тогда лучше оставить кодек с исходника. Кассеты оцифровывать? Тут нет смысла использовать крутые кодеки, разрешение маленькое.
Realife Автор
29.09.2024 13:17Извините, но я не понимаю что вы от меня хотите. Я не вижу в целом смысла в поднятии данного вопроса в данном случае.
Loco2k
29.09.2024 13:17Среди представленные вами в статье вариантов самый продвинутый AV1. Он появился позже и умеет всё тоже самое, что и HEVC плюс новые фичи, например, film grain, и прочие перечисленные в статье опции.
От вас я бы хотел меньше логических ошибок в изложении статьи.
brute11k
29.09.2024 13:17+1Аппаратный AV1 не подходит для уменьшения веса, т.к. профили в нём зафиксированы. Для качества и низкого размера нужно использовать процессорные svt-av1, svt-av1-psy, Av1an.
Сам пока остановился на Av1an, как наиболее продвинутом варианте с разбиением видео на несколько сцен и обработкой в параллельном режиме. Так же там сейчас разработчик пилит возможность распределённого кодирования (по сети), что позволяет ускорить кодирование во много раз: разбиваем файлы на сцены и каждая сцена кодируется на отдельной машине. Кодирование фильмов и стримов многочасовых можно в 10-100 раз ускорить.
Javian
29.09.2024 13:17Периодически пробуют кодирование видео по сети. Только мало кому оно необходимо.
Loco2k
29.09.2024 13:17Профили в каком-то софте вы имеете ввиду?
Я тестил на утилите nvenc с videohelp. Вполне рабочие основные опции.
У меня получается 500 фпс с 2pass full и 600 фпс без мультипрохода на транскодинге CRF с AVC 1080р25.
Alexey_U
29.09.2024 13:17Подскажите, пожалуйста, какой кодек качественнее передаёт детали при плохом освещении и при каких настройках? Исходная запись h.264 с видеорегистратора, видно что идёт человек в брюках, распознать можно метров с 20, после перекодирования в h.265 VBR с CRF даже с минимальным значением этот же человек появляется без ног, которые появляются где-то уже метрах в 7. Приложение MediaCoder для Windows. Остановился на CBR с битрейтом 1350, чтобы не увеличивать размер файла. Детализация ну так себе, но хотелось бы укладываться в объем 1- слойного DVD. Может как-то можно улучшить качество (при плохом освещении) при том же объёме видео на выходе?
С AV1 как-то не получается. Вообще.
Loco2k
29.09.2024 13:17Скорее всего у вас изначальное разрешение и битрейт низкие. Любое транскодирование ухудшает качество. Для начала попробуйте такие же настройки как и в оригинале, но с другим кодеком.
Javian
29.09.2024 13:17+1Для хорошей работы кодека надо подготовить картинку - отфильтровать шумы.
Например фильтром Neat либо чем-то подобном, что доступно в используемом ПО.
В самом простом варианте в видеоредакторе может выглядеть так. Alexey_U
29.09.2024 13:17Спасибо. Никогда не задумывался об этом. Возможно я что-то не так раньше делал с фильтрами, просто пропадали детали.
Javian
29.09.2024 13:17+1Пробуйте Neat - простой и аккуратный фильтр.
например в этой статье есть пример результата
В ходе моего недавнего проекта я вручную обработал 124 серии из разных мультфильмов в качестве Blu-ray с помощью алгоритма устранения шума (Neat Video)
ArkadiyMak
29.09.2024 13:17+1С 10-битным цветом не пробовали сжимать?
Alexey_U
29.09.2024 13:17+1Пробовал. Лучше. Но VLC не нравится, а пока только он у меня 10-битный цвет воспроизводит.
voldemar_d
29.09.2024 13:17+2Откуда в видеорегистраторе возьмётся 10 бит в исходном видео?
ArkadiyMak
29.09.2024 13:17Ниоткуда. И с 8битным исходником может выйти лучшее качество за счет другого квантования.
voldemar_d
29.09.2024 13:17Хотелось бы увидеть реальный пример, на котором видна существенная разница. А то и в обсуждаемой статье на изрядной части картинок разницы либо вовсе нет, либо я не пойму, где её увидеть предлагается.
MountainGoat
29.09.2024 13:17+1Увидеть предлагается в тёмной темноте, где 8битный цвет даёт различимые полосы, а 10битный цвет за счёт размешивания краёв этих полос делает их труднозаметными.
voldemar_d
29.09.2024 13:17Обычно "увидеть" - это про картинку, а не слова.
MountainGoat
29.09.2024 13:17
voldemar_d
29.09.2024 13:17Я не вижу разницы, честно.
Javian
29.09.2024 13:17+1
Тут нагляднее Больше ступеней яркости - равномернее градиенты. На 8 битах будут заметны ступеньки.
voldemar_d
29.09.2024 13:17А может, при кодировании в 10 бит какая-то дополнительная фильтрация работает?
Да и тоже, разница видна, но если на нее явно не показать, неспециалисту заметить её сложно.
e-zig
29.09.2024 13:17А вот пресет это отдельный параметр или он устанавливает значения других описанных параметров?
VADemon
29.09.2024 13:17Устанавливает другие параметры, зависит от версии кодировщика, что именно он вставит. Поэтому крутить параметры вручную надо только очень хорошо понимая разницу и ограничения профилей (чтобы не было "у меня на ТВ не воспроизводится, а на компе норм").
edogs
29.09.2024 13:17+3Отдельное спасибо за cropdetect, не знали.
Иногда перекодируем старое видео, которое уже сложно найти, почти всегда с полосами.
Еще из двух спасительных фильтров для старых видео это - деблокинг (убирает квадраты которые почти всегда есть в старых видео) и автоуровни (обычно старые видосы почему-то пересветлены). pp=al/hb/vb в командной строке. Правда не знаем (может кто в курсе?) совместимы ли они с либами кодинга на nvidia (кодируем обычно на проце).
moscowman
29.09.2024 13:17Делал для домашней коллекции переконвертацию 4К видео в h264 (VerySlow) и h265 (placebo) с тем-же разрешением с максимальным качеством видео на выходе.
Так вот, на фильме "Дрожь земли" на стоп-кадре невооружённым взглядом видно, что h264 выдаёт более качественную картинку, а h265 её нещадно мылит.voldemar_d
29.09.2024 13:17Всё зависит от кодера, его настроек и битрейта.
moscowman
29.09.2024 13:17+2Для ffmpeg
h264: -vcodec libx264 -preset VerySlow
h265: -vcodec libx265 -preset placebovoldemar_d
29.09.2024 13:17+3ffmpeg - лишь один из кодеров. В нём же самом можно кодировать аппаратно на GPU от NVidia и Intel, например, и они дают разные результаты.
MountainGoat
29.09.2024 13:17Если это всё, то вы с сильно разным CRF кодировали.
moscowman
29.09.2024 13:17Тогда прошу подсказать "правильные" параметры для h265, которые дадут качество хотя-бы такое-же как h264.
Я использовал самые качественные пресеты и там и там.
В итоге самый качество от h264 оказался гораздо более лучше, чем у вышедшего позднее h265. Не говоря уже о времени кодирования.Realife Автор
29.09.2024 13:17для правильного сравнения именно качества кодеков, вам необходимо было сравнивать их с данными параметрами:
h264: -vcodec libx264 -preset veryslow -b:v 2000k (можете указать своё значение)
h265: -vcodec libx265 -preset veryslow -b:v 2000k
Только в таких равных условиях, мы можем говорить о качественной разнице самих кодеков. У кого будет меньше артефактов и искажений - тот и будет качественнее.moscowman
29.09.2024 13:17Т.е. вы ограничиваете битрейт потока, но не качество?
Факт того, что качество h264 будет выше при отсутствии такого ограничения Вы отвергаете?
Другими словами, Вы почему-то апеллируете к потоку, когда я изначально говорил, что h265 откровенно мылит, если мы стремимся к качеству исходника.Или всё-таки при таком-же качестве полученного видео у h265 уже не будет преимущества в размере файла?
Если не сложно, давайте изучим качество, на примере "Дрожь земли".
Для h264: -vcodec libx264 -preset VerySlow
Для h265 вы постараетесь указать параметры, где видео будет не хуже.
Больше интересуют фрагменты с развевающимися волосами героев на фоне прерий.
P.S. Второй раз редактирую ответ, извините. Но для меня реально это интересно, фильмотека занимает довольно много места и заявленная экономия h265, если она реально есть, меня очень даже выручит.
Думаю что все мы скажем Вам ОГРОМАДНОЕ спасибо за науку.edogs
29.09.2024 13:17+2Не являемся специалистами, сразу оговорим.
Лично у нас h264 показывает ощутимо лучшие результаты на видео плохого качества. То есть если изначально качество видео было оцифровка vhs или небольшое разрешение или жесткая пережатка в квадраты или еще что-то, то h265 делает из видосов плавающую кашу (мало того, что детали теряются, так еще и изображение плавать начинает), а h264 картинку почти не портит. При это размер получается примерно одинаковый.А вот если речь про современное видео без сильной пережатки (оригинал с гоупро или телефона), то h265 отлично уменьшает размер почти не теряя детали, а вот h264 проигрывая в уменьшении размера жестко теряет четкость.
crf (или как там его) используем 20/24 - под настроение (кстати дефолтовый в h265 вроде 20, а вот в h264 24), режим slow.
okda4ok
29.09.2024 13:17А может кто знает с каким кодеком рутуб работает? Ресурс жрет как не в себя. Яндекс.Станция макс (2021 год) захлебывается при воспроизведении видео с рутуба, просто перестает реагировать на голос, с 10 раза удается докричаться. Старенький айпад вообще не воспроизводит.
Youtube на голову выше в этом, везде работает… К сожалению, о минусах рутуба с технической стороны маловато написано.
CaptGg
29.09.2024 13:17+1В плеере Рутуба в браузере доступна весьма подробная техническая информация:
Техническая информация
Video Id:1ba709634e43fa0f1621814ad8e9e4ef Bandwidth:82 mbps Codecs:avc1.640029 | mp4a.40.2 Buffer:(0, 0), (0, 212) | 13 | 212 Screen Resolution:1920x1080 Video Quality:1280x720 | 1670 kb Edge | Dive:river-3-331.rutube.ru | undefined isLive | isDVR:false | false Auto Quality Enabled:true Current Quality:4 Playback Position:29 / 1665.2149999999897 Last Ad Name: Volume | Muted:41% | false Current Domain:https://rutube.ru Player Version:1.65.0-wdp Date:Mon Sep 30 2024 11:27:49 GMT+0300 (Москва, стандартное время) User Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 YaBrowser/24.7.0.0 Safari/537.36 ScreenO Lock API:falseИспользуется самый распространенный и поддерживаемый всюду H.264.
Но вот битрейт для видео судя по всему Рутуб так сурово как YouTube не ограничивает. В итоге если автор видео загрузил его с битрейтом выше чем у фильма на Blu-Ray диске, но все еще в поддерживаемом формате - вашей колонке придется это как-то воспроизводить.
Вероятно в приложении Рутуба стоит реализовать более щадящий автоматический выбор качества, а не крутить 2К на всём подряд.
erazor
29.09.2024 13:17Перекодировал давеча домашнюю библиотеку, хотел добиться универсального формата для воспроизведения на всех моих устройствах. Т.е. это веб-браузеры на основе хрома(Android+windows+chromecast) ну и нативное воспроизведение через VLC. В итоге пришел к тому, что видео нужно x264, звук mp3/aac. Всё это в контейнере mp4. + в довесок выяснил, что chromecast не дружит с 6-канальным звуком, пришлось принудительно "добавить" стерео дорожку, там где ее нет... В общем не знаю как там будет с i-устройствами, но пока что результат меня устраивает.
mpa4b
29.09.2024 13:17Автор, расскажите о том, как заставить libx265 использовать полностью все доступные треды. Сейчас при 32 тредах (16-ядерный рызен) один инстанс ффмпега при кодировании в x265 жрёт тредов сильно меньше 32х, да и те что жрёт -- не на 100%. Для макс. использования процессора приходится стартовать несколько инстансов. Но хотелось бы наоборот -- 100% загрузки всех тредов одним инстансом.
svpcom
29.09.2024 13:17Вот только в реализации h265 декодера в ffmpeg (а так же в остальных open-source, так как они используют одну и ту же библиотеку) есть очень досадный баг: http://github.com/strukturag/libde265/issues/423 который убивает напрочь любой live streaming с ними
Realife Автор
29.09.2024 13:17Даже не углубляясь в вопрос, я не рассматриваю в статье какой-либо live streaming с ffmpeg.
SergeevSkvo
29.09.2024 13:17+1Не только же в live streaming кодируется поток, в приложениях OverTheTop весь поток транскодируется, и при доставке контента потребителю через интернет пакеты могут теряться... А в целом, спасибо за статью, я по-другому начал смотреть на видеокодеки! :)
svpcom
29.09.2024 13:17+1Проблема в том, что opensource реализация h265 декодера только одна и ее используют все (в том числе gstreamer и vlc). На данный момент в линуксе этому багу не подвержены только аппаратные кодеки от nvidia и рокчипа.
tempart
29.09.2024 13:17указание большего или меньшего значения CRF в большей степени зависит от скорости вашего накопителя, нежели от процессора
Какое отношение уровень качества видео имеет к скорости накопителя? Вообще никакого.
В худшем случае, от скорости накопителя будет зависеть скорость кодирования, но никак не CRF.В целом, статья совсем не убедила перейти с Handbrake или StaxRip на предложенную командную строку
Loco2k
29.09.2024 13:17В хендбрейке те же опции, что и в статье, только через ГУИ.
При CRF-кодировании ограничение битрейта нужно для того чтобы новая порция данных успевала считаться с диска или загрузиться по сети, а также учитывается размер буфера на плеере. Без ограничений на сложной сцене битрейт может так сильно скакнуть, что слабый плеер не успеет подгрузить фрагмент и будет фриз.tempart
29.09.2024 13:17+1В хендбрейке те же опции, что и в статье, только через ГУИ.
Ну, у автора же посыл, что к чёрту все эти удобные штуки, побежали в командную строку, там всё гораздо интереснее
При CRF-кодировании ограничение битрейта нужно для того чтобы новая порция данных успевала считаться с диска или загрузиться по сети, а также учитывается размер буфера на плеере
Мы же говорим про кодирование, а не про воспроизведение?
Каким образом я, перекодируя видео, могу предвидеть, какой там буфер у заранее неизвестного плеера и какие там скорости будут у совершенно мне неведомого носителя?В общем, я впервые слышу, что при выборе CRF надо учитывать параметры носителя и плеера. Возможно, для специальных случаев, но явно не "для дома, для семьи". Не могу представить, чтобы HDD даже 10-15 летней давности (SATA-II, правильно помню?) не тянули полноценный блюрей, не говоря уже о пожатых видео
Loco2k
29.09.2024 13:17Я вам говорю для чего эта технология сделана, как человек, который это настраивает на практике для широкого круга девайсов.
Домашние кейсы у всех разные, у автора об этом ни слова. Для разных случаев будут разные кодеки и настройки. Просто для архива лучше взять новейших кодек и кодировать в CRF с максимальным качеством. Если нужно крутить это из домашнего облака на разных умных теликах и телефонах, нужно выбирать соответственно, то что поддерживается и уже думать про буферы\битрейты.
Я не нашёл на что вы отвечали в изначальном комментарии, просто решил написать о технологии.Realife Автор
29.09.2024 13:17+1Вы название статьи читали?
А также данный абзац?
H264 — воспроизводится без проблем практически везде, но имеет оскорбительно плохую эффективность в сжатии видео в сравнении с другими актуальными кодеками. AV1 — открытый кодек, который сжимает видео более эффективно, чем HEVC, но требует значительно больше ресурсов как для кодирования, так и для декодирования, что, несмотря на его свободу от лицензий, делает его непригодным для использования за пределами таких онлайн-кинотеатров, как Netflix или Amazon Prime, которыми как раз и поддерживается его развитие.
Исходя из названия статьи, ну чисто логически же можно было понять что основной упор идет на hevc и я не буду рассказывать о чем-либо кроме него. Так и вот в цитате и самой статье я ни один раз упоминал что hevc это не центр вселенной и мироздания. Что для ваших "домашних кейсов" есть разные кодеки тоже упомянуто в цитате.
Серьёзно, ваши сообщения уже больше подходят на спам. Вы уже ни один раз игнорировали доводы из статьи, хотя вроде её и читали...
Loco2k
29.09.2024 13:17Говоря о спаме, вы оставляете комментарий в ветке где мы обсуждаем CRF... Или вы за мной по всему Хабру будете ходить?
Скажу прямо, ваше вступление про кодеки малосодержательное и спорное по большинству утверждений. О чем вам тут неоднократно написали разные люди.
Если бы вы написали: вот мой перевод к опциям кодирования ffmpeg применительно к HEVC, подобных комментариев бы не было.
S1re10k_4f99
29.09.2024 13:17+1Если вы не знали, кодированное в помощью crf может иметь пики битрейта в разы больше, чем исходный blu-ray. В Blu-ray битрейт ограничен на 62.5 Мбит, уровнем 4.1. В crf я получал и по 200 мбит пики, когда средний битрейт на видео был меньше 10 мбит.
Конечно жёсткий диск это тянет, а вот если вы решите записать на DVD, то увидите, что в местах пиков у вас фризы, диск не тянет 200 мбит.
Но главное тут, что аппаратный декодер может не тянуть, если аппаратный декодер только до уровня 4.1, то он так же спокойно может фризить на этих пиках. Хорошо когда аппаратный декодек поддерживает уровни 5 или 5.2, тогда он это спокойно переварит.
Zip1337
29.09.2024 13:17+1Даже сам вопрос о том, что такое кодек, ставит многих в тупик. Можно легко услышать ответ: «.avi, .mkv, .mp4...», но это лишь контейнеры, которые в большинстве случаев содержат видео, аудио и другие данные. А кодек — это преобразователь видео/аудиосигнала.
В рамках улучшения статьи, где даны краткие справки о HEVC, h264 и других кодеков, можно было бы добавить также и этимологию слова "кодек". Мне стало интересно, как оно образовано и пришлось заглянуть в вики:
Ко́дек (англ. codec, от coder/decoder — шифратор/дешифратор — кодировщик/декодировщик или compressor/decompressor, слово «кодек» образовано по тому же принципу, что и слово «модем») — устройство или программа, способная выполнять преобразование данных или сигнала.
takezi
Самый продвинутый - AV1, к тому же не требующий лицензирования в отличие от HEVC. Единственный минус: за качество придется заплатить скоростью кодирования.
equeim
SVT-AV1 довольно близок к libx265 по скорости кодирования (на современном процессоре).
voldemar_d
Тот, кто минусует, может объяснить, за что именно? AV1 действительно разрабатывался как ещё более эффективный по сравнению с HEVC. Но по вычислительной нагрузке он ещё более "тяжёлый", примерно на порядок.
saege5b
Если 264/265 зарядить исключительно "софтово" - то там даже декодирование будет унылым на базовых профилях, а уж на всяких Ультра - черепашьим.
Нужно иметь весьма шустрый сильно многоядерно-многопоточный проц, с кучей шустрой оперативы, чтобы не было слайдшоу.
Вот и в АВ умеют далеко не многие.