Comments 41
Для тех у кого мак, то можно использовать hevc_videotoolbox - так сказать аппаратный кодер от эппла. Сам лишь недавно про него узнал, до этого долго бился с перечисленными в статье, пытаясь завести их на макоси.
Использую для того чтобы ужимать видео отснятые на телефон в форматы для различных соцсетей/мессенджеров.
Как видно, при quality=10 распределение микроблоков ухудшается, что приводит к более сильному искажению геометрии по сравнению с quality=0.
никак не видно, потому что jpeg
Сжатие практически отсутствует, я своим глазом это отлично различаю. Как раз для тех у кого меньшая насмотреность, я в некоторых местах дополнительно сделал данные пометки
чтобы было просто сразу видно - png
Хорошо, вот вам более наглядно, на том же самом jpeg, что и в статье. Говорю же - дело в насмотренности.
ок, видно. но лучше сразу пнг
Из описания следует, что quality=10 должен давать лучшее качество.
Собственно, на картинках видно, что он его и дает: там, где quality=0 выдает сплошное мыло, у 10 присутствуют детали.
Тому, что эти детали, на самом деле — артефакты, вы обязаны выбором максимально убитого исходника, который до перекодировки уже представлял собой плиточную мешанину разрешения qVGA в формате 3gp.
Здравствуйте, я перепровил данный момент, и как оказывается действительно при большем значении quality, и при меньшем значении битрейта получаются результаты лучше, а при большем значении битрейта - наоборот. Исправляюсь, но то что так вышло - наверное наоборот даже хорошо, ведь при недостаточном битрейте лучше использовать quality=10, а при достаточно большом - quality=0, это будет полезной информацией. Спасибо
а еще можно разницу
Классная статья, спасибо!
Я недавно выбирал себе новый ноутбук и выбрал специально интел, т.к. на практике в давинчи резолв втройка интела гораздо лучше поддерживает аппаратное кодирование H265 на актуальных на сегодня режимах съемки (10/12bit 4:2:2)
Аппаратное кодирование работает на уровне системных библиотек? там не нужна запущенная графическая сессия с видеодрайвером X11? и работает ли это кодирование одновременно с несколькими процессами ffmpeg?
Я как то сравнивал software/nvenc по VMAF 0.6.1, и качество у nvenc заметно ниже на самом высоком его пресете, чем при кодировании cpu. И что еще интересней у nvenc не такая уж большая разница между h264/hevc/av1, большее значение имеет битрейт. Если место не проблема, то nvenc вполне себе хорош своей скоростью, но при равном битрейте проигрывает software энкодеру качеством.
Аппаратные кодеки годятся только на "грязное" пережатие очень больших исходников. К примеру, 8к в 1080р при соответствующем для обоих форматов размере. Если важен размер, например, из стандартного блюрика сделать копию для домашнего архива, сохранив адекватное качество, – тут аппаратные кодеки бесполезны, качество на выходе будет как у веб-трансляции.
GOP (Graphics Output Protocol) - вы серьезно? Даже не знаю, стоит статью с такими ошибками рассматривать всерьез
Эта статья же сгенерирована? Целиком? Страшно предположить, но сгенерированы даже картинки со сравнением результатов?
Например, GOP - это не Graphics Output Protocol (исправлено, но...), а Group of Pictures (группа кадров), она не специфична для аппаратного кодирования, а следует из идеи межкадрового сжатия ([IBBPBB]I... - вот [GOP], его длина 6 кадров aka keyframe interval), длина может настраиваться в разных энкодерах и по-разному (минимальная/максимальная/фиксированная, для поиска по ffmpeg: -g, -keyint, -keyint_min, -strict_gop), опция из статьи не существует.
Нет, серьёзно, опция не существует. Unrecognized option 'gop'. Гитхаб по repo:FFmpeg/FFmpeg /"-?gop"/ тоже говорит, что не существует (он найдёт только -header_insertion_mode gop). ffmpeg -h encoder=hevc_amf > hevc_amf.txt - пусто. Команда невалидная, но картинка с результатом есть. "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?".
ffmpeg -i "название_видео.mp4" -c:v hevc_amf -rc cqp qp_i 20 qp_P21 готовое_видео.mp4
qp_i 20 => -qp_i 20
qp_P21 => -qp_p 21
Однако до программного [аппаратного, по контексту] кодирования с доступными более чем 200 параметрами [господи, зачем?] ещё далеко.
AMF
AMF - не блок GPU, а библиотека для аппаратного энкодера VCE, который появился на кристалле в 2011, до 2016 к нему лишь получали доступ не через AMF.
в случае аппаратного кодирования даже процессор пятилетней давности будет превосходить его [...] в возможностях самих специализированных блоков
Мне не понравился не только поверхностный, но и откровенно плохой подход к теме в других статьях
Эта статья же сгенерирована? Целиком? Страшно предположить, но сгенерированы даже картинки со сравнением результатов?
Не вижу смысла рассматривать данное утверждение. Я человек и могу тоже могу ошибаться и что-то интерпритировать неправильно.
Например, GOP - это не Graphics Output Protocol (исправлено, но...), а Group of Pictures (группа кадров), она не специфична для аппаратного кодирования, а следует из идеи межкадрового сжатия (
[IBBPBB]I...- вот [GOP], его длина 6 кадров aka keyframe interval), длина может настраиваться в разных энкодерах и по-разному (минимальная/максимальная/фиксированная, для поиска по ffmpeg:-g, -keyint, -keyint_min, -strict_gop), опция из статьи не существует.Нет, серьёзно, опция не существует.
Unrecognized option 'gop'. Гитхаб поrepo:FFmpeg/FFmpeg /"-?gop"/тоже говорит, что не существует (он найдёт только-header_insertion_mode gop).ffmpeg -h encoder=hevc_amf > hevc_amf.txt- пусто. Команда невалидная, но картинка с результатом есть. "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?".
Хороший вопрос насчёт gop, я писал статью несколько месяцев назад, и абсолютно уверен что использовал gop, оттуда же и картинки, но сейчас я действительно не могу найти такой опции. Мне надо понять как так получилось. Уверенность конечно - не оправдание, но я буду очень удивлён если это окажется не так. Да и банально какой смысл мне набивать статью чем-то несуществующим и к тому же писать для этого недействительную команду в то время когда все остальные команды рабочие?
Однако до программного [аппаратного, по контексту] кодирования с доступными более чем 200 параметрами [господи, зачем?] ещё далеко.
Почему я не могу это упомянуть? Это ведь действительно так. Я кстати по вами раннее приведённой команде "ffmpeg -h encoder=" и полчуил количество параметров для аппаратных решений, а вот для программного пришлось полезть в документацию x265.
AMF - не блок GPU, а библиотека для аппаратного энкодера VCE, который появился на кристалле в 2011, до 2016 к нему лишь получали доступ не через AMF.
Да, данный момент я действительно не учёл, и на вики об этом есть информация. Я не проверил данный момент, а на гитхабе amf об этом напрямую не упомяналось. Но я нашёл самый ранний релиз там же, поэтому и не полез на вики касательно данного момента. Отталкиваясь от этой даты я нашёл и дальнейшие детали, относительно того какие линейки видеокарт тогда выходили и т. д.
в случае аппаратного кодирования даже процессор пятилетней давности будет превосходить его [...] в возможностях самих специализированных блоков
Имелось ввиду что новые алгоритмы добавляются более часто чем в аппаратных решениях, и что т.к. программный кодек един для всех прозиводителей процеесоров, то и самих возможностей у него больше, в отличие от разных аппаратных решений для того же hevc, хотя это утверждение можно трактовать как полуправду.
Я снёс блок с GOP, пока сам пытаюсь разобраться в ситуации. И спасибо за ваши правки.
Я бы теперь на вашем месте этот ответ тоже доверил ChatGPT...
И предыдущую статью из серии тоже:
На первый взгляд CRF похож на preset, но на самом деле это менее сложный инструмент, поэтому указание большего или меньшего значения CRF в большей степени зависит от скорости вашего накопителя, нежели от процессора.
Или, скажем, утверждение "я отобрал то, что действительно работает и оказывает значительное влияние на качество изображения, во всех случаях" оспаривает авторитет разработчиков x265, потому что bframes > 8 - это больше, чем в пресете placebo - то есть самом медленном из пресетов, в названии которого польза от выбранного "размена скорости на качество" сравнивается с плацебо.
А "Почти никогда не стоит поднимать планку выше 8 бит" возвращает читателя во времена до H.265. Дело в том, что в H.264 10-битность была в профиле "High 10", для которого нет аппаратных декодеров (не существует то ли вообще, то ли в потребительских устройствах) - телевизоры и приставки в софтовом декодировании захлебнутся, видео будет тормозить, зрители не будучи анимешниками такую тягу к прогрессу не оценят. С приходом H.265 разрядность в 10 бит стала доступна в профиле "Main 10", аппаратные декодеры в него смогли, все вздохнули с облегчением, жить стало лучше, появилась надежда. Проще говоря, предотвращение бандинга теперь стало возможно простым поднятием разрядности, а не дизерингом, расходующим больше битрейта.
Я снёс блок с GOP, пока сам пытаюсь разобраться в ситуации.
(а я на всякий случай в вебархив положил)
Я бы теперь на вашем месте этот ответ тоже доверил ChatGPT...
Я не использую его при написании статей. И с вашей стороны не очень хорошо пытаться принизить мой труд и прибавить себе самому веса подобными утверждениями. К тому же даже если вы действительно в этом сомневаетесь, то раннее я уже ответил на большинство из ваших вопросов где мои утверждения вам показались странными или необоснованными.
Или, скажем, утверждение "я отобрал то, что действительно работает и оказывает значительное влияние на качество изображения, во всех случаях" оспаривает авторитет разработчиков x265, потому что
bframes > 8- это больше, чем в пресетеplacebo- то есть самом медленном из пресетов, в названии которого польза от выбранного "размена скорости на качество" сравнивается с плацебо.
Возможно тут был недочёт с моей стороны, но и нельзя же утверждать что только из-за bframes пресет назван "placebo", и только из-за него в нём сильно падает скорость, просто в ходе моих экспериментов и проектов с сжатием анимации, такое значение показывало более хорошие результаты.
А "Почти никогда не стоит поднимать планку выше 8 бит" возвращает читателя во времена до H.265. Дело в том, что в H.264 10-битность была в профиле "High 10", для которого нет аппаратных декодеров (не существует то ли вообще, то ли в потребительских устройствах) - телевизоры и приставки в софтовом декодировании захлебнутся, видео будет тормозить, зрители не будучи анимешниками такую тягу к прогрессу не оценят. С приходом H.265 разрядность в 10 бит стала доступна в профиле "Main 10", аппаратные декодеры в него смогли, все вздохнули с облегчением, жить стало лучше, появилась надежда. Проще говоря, предотвращение бандинга теперь стало возможно простым поднятием разрядности, а не дизерингом, расходующим больше битрейта.
В данном случае я пришёл к выводу что 8-битность лучше, поскольку в случае с моим 4к тв, попытка воспроизведения 10-битного и 12-битного видео приводила к подсвинаям или вылетам в видеоплеере VLC. Но я знаю о очевидных плюсах 10 бит кодировании, также это было видно на приложенном изображении, но и также очевидно что его нельзя назвать универсальным параметром.
(а я на всякий случай в вебархив положил)
Опять же, я признаю что на данный момент часть с GOP кажется спорной, но я по моим воспоминаниям, точно его использовал, и точно в этих же командах не было других параметров способных повлиять на результаты, чтобы это было заметно при сравненнии картинок. Возможно что действительно gop был нерабочим параметром, но у меня это не вызывало сбоев при кодировании, что весьма странно и в этом я сейчас с вами согласен.
Выглядит как проверка хабра на прочность (которую хабр провалил), после такого возникают подозрения ко всем статьям на аккаунте.
но и нельзя же утверждать что только из-за bframes пресет назван "placebo"
Поэтому никто этого и не утверждает.
просто в ходе моих экспериментов и проектов с сжатием анимации, такое значение показывало более хорошие результаты.
Достойно и даже требовало бы отдельной статьи, потому что слишком неочевидно. Но в том же абзаце нечеловеческая ошибка при пересказе документации: "B-frames. Количество кадров, используемых алгоритмом для анализа" ("Maximum number of consecutive b-frames").
Но я знаю о очевидных плюсах 10 бит кодировании
Для меня 10-битность вне HDR/WCG неочевидна.
не очень хорошо пытаться принизить мой труд и прибавить себе самому веса подобными утверждениями
Нет, я искренне читаю и стукаюсь об стол. Насчитал 121 опцию в SvtAv1EncApp, что лишь на 5% больше, чем у HEVC NVENC в статье и не знаю, что делать с этим знанием. Представьте себе обзорную статью о компиляторах C++, которая начинается со сравнения количества флагов.
Я ценю ваш вклад и то что вы сделали, и уже внес нужные правки, где это было обоснованно(по части bframes и битности это так-то зависит от задач и личных потребностей). А дальше предлагаю фокусироваться на конструктивном диалоге, а не на обвинениях и ценить время друг друга.
Скажите, а зачем вы выделяете участки текста синим цветом? У меня рука дергается кликнуть по ним, но каждый раз оказывается, что это не ссылка. Это, видимо, подсказки для тех малообразованных читателей которые сами не догадаются на что надо бы обратить внимание в тексте?
спасибо заа статью, интересно, ну было бы здорово указать ультимативные настройки для amf, я уже если честно замучался подбирать пресеты, и как бы я не старался выходит гораздо хуже чем у нвидии, да и весит в несколько раз больше, появляются ареолы и т.д
вот пример фильм "Чёрный дождь" в оригинале весит 36 гигабайт, ужали его до 4 гигабайт, в качестве не потерял совершенно ничего, никаких ареолов, пикселей и шумов (ну или мне нужно купить очки) добиться такого с amf не получается..
прикрепил бы еще видеосравнение сжатого аниме, но здесь вроде только по ссылке (а на ютуб заливать не хочется) там вобще ужас-ужас....
Скрытый текст
занимаюсь сжатием для того чтобы наполнить свою медиаколлекцию, памяти не особо много поэтому хочется чтобы весило по минимуму но и по качеству от оригинала не отставало
На рутрекере есть отличные справочные материалы по 264 и 265.
Коротко говоря, универсальных настроек не существует. Сжатие сильно зависит, помимо прочего, от источника. Это если цель – запихать в определённый размер. Сложный источник может потребовать множества предварительных экспериментов для подбора оптимальных настроек.
Проще взять AV1 видеоряд от какого-нибудь известного забугорного релизера, где VMAF > 97 , и пересобрать с нужными аудио дорожками в mkvtoolnix. Программный кодер всегда будет лучше, потому как GPU всегда оптимизируют чтобы выдавать побольше результатов (а не получше качество).
Из опыта могу посоветовать RAV1NE, dAV1nci, rosy, DiN. Если нужно максимальное качество - UserHEVC (-UH).
8-12ГБ на полуторачасовой фильм 4К это очень неплохо. При качестве 98%-99%.
Ну и ещё аудио можно в Opus. 256кб/с для 5.1 и 320кб/с для 7.1. Экономия х2 в сравнении с АС3.
8 Гб для 4к это великолепный результат. Ещё чуть постараться, и влезет на двухслойный DVD! Оцените иронию...
Со звуком всё сложнее. Несмотря на то, что у большинства потребителей нет даже сабвуфера, не говоря уж о 5.1, зажимать 6 каналов в 256 представляется несколько авантюрой.
не подойдет AV1, держу медиацентр на rp4, а смотрю на телевизоре который не поддерживает этот самый AV1
поэтому стараюсь скачивать HEVC раздачи
Для тех у кого мак, то можно использовать hevc_videotoolbox - так сказать аппаратный кодер от эппла. Сам лишь недавно про него узнал, до этого долго бился с перечисленными в статье, пытаясь завести их на макоси.
Использую для того чтобы ужимать видео отснятые на телефон в форматы для различных соцсетей/мессенджеров.
3D графика, используемая в статье в качестве иллюстрации для артефактов сжатия, в целом жмётся на порядок проще, чем, скажем, крайне зернистый исходник из 00-ых. Который к тому же жат при релизе каким-нибудь VC1. Вот там артефакты сжатия прекрасны до безобразия.
Не претензия, просто добавление знаний.
Давно это всё есть в программе "HandBrake"!
Ищем в инете, скачиваем, устанавливаем и радуемся! Куча настроек, шустрая!
На мультике тестировать кодеки? Ну такое себе.. Если экспериментировать с разными способами кодирования, то советую в качестве исходника взять видео - водопад с брызгами на ветру и с людьми на переднем плане.
Подскажите пожалуйста, каким образом можно проанализировать сжатые видео с разными параметрами, чтобы получить график qp по каждому из них? (Включая среднее значение и медиану)?
Аппаратное кодирование HEVC в FFmpeg — как быстро вникнуть и начать уже сейчас?