Настройки кодека h 265
В данный момент идет активная разработка энкодера, но он все ещё находится в состоянии «бета»-версии. Работает медленно и не очень эффективно. Релизы новых версий выходят очень часто.
Что умеет QSV в Skylake
В Gen9 появилась полная поддержка аппаратного ускорения при кодировании и декодировании H.265/HEVC, частичная поддержка аппаратного кодирования и декодирования свободным кодеком VP9. Произведены значительные улучшения в технологии QSV. Они повысили качество и эффективность кодирования и декодирования, а также производительность фильтров в программах для транскодирования и видеоредактирования, которые используют аппаратное ускорение.
Интегрированная графика Skylake поддерживает стандарты DirectX 12 Feature Level 12_1, OpenGL 4.4 и OpenCL 2.0. Решено полностью отказаться от мониторов VGA, зато Skylake GPU поддерживают до трёх мониторов c интерфейсами HDMI 1.4, DisplayPort 1.2 или Embedded DisplayPort (eDP) 1.3.
Аппаратное ускорение декодирования видео доступно графическому драйверу через интерфейсы Direct3D Video API (DXVA2), Direct3d11 Video API или Intel Media SDK, а также через фильтры MFT (Media Foundation Transform).
В графике Gen9 поддерживается аппаратное ускорение декодирования AVC, VC1, MPEG2, HEVC (8 бит), VP8, VP9 и JPEG.
▍Аппаратное ускорение декодирования видео
Расчётная производительность декодирования видео при аппаратном ускорении составляет более 16 одновременных потоков видео 1080p. Реальная производительность зависит от модели GPU, битрейта и тактовой частоты. Аппаратное декодирование H264 SVC не поддерживается в Skylake.
Аппаратное ускорение кодирования доступно только через интерфейсы Intel Media SDK, а также через фильтры MFT (Media Foundation Transform).
▍Аппаратное ускорение кодирования видео
Кроме аппаратного ускорения кодирования и декодирования, в графике Gen9 реализовано аппаратное ускорение обработки видео, в том числе следующих функций: деинтерлейсинг, определение каденции, масштабирование видео (Advanced Video Scaler), улучшение детализации, стабилизация изображения, сжатие охвата цветовой гаммы (gamut compression), адаптивное улучшение контраста HD, улучшение оттенков кожи, контроль цветопередачи, шумоподавление в цветовой составляющей канала (chroma de-noise), преобразование SFC (Scalar and Format Conversion), сжатие памяти, LACE (Localized Adaptive Contrast Enhancement), пространственное шумоподавление, Out-Of-Loop De-blocking (для декодера AVC) и др.
Аппаратный транскодер Gen9 поддерживает следующие специфические функции транскодирования:
- Быстрый и энергоэффективный кодер AVC в реальном времени для видеоконференций
- Сжатие памяти без потерь для медиадвижка с целью уменьшения энергопотребления
- Масштабирование видео (Advanced Video Scaler)
- Энергоэффективный конвертер SFC (Scalar and Format Conversion)
Источник: 6th Generation Intel Processor Datasheet for S-Platforms
В Gen9 реализована аппаратная поддержка обработки видео с цифровых камер (Camera Processing Pipeline), в том числе отдельные функции этой обработки: баланс белого, восстановление полноцветного изображения с массива цветных фильтров на сенсоре камеры (de-mosaic), коррекция дефективных пикселей, исправление уровня чёрного, гамма-коррекция, устранение виньетирования, конвертер цветового пространства (Front end Color Space Converter, CSC), улучшение цветопередачи (Image Enhancement Color Processing, IECP).
Skylake GPU
- HD Graphics 510 (GT1, 12 EU, 950 МГц, 182,4 Гфлопс)
- HD Graphics 515 (GT2, 24 EU, 1000 МГц, 384 Гфлопс)
- HD Graphics 520 (GT2, 24 EU, 1050 МГц, 403,2 Гфлопс)
- HD Graphics 530 (GT2, 24 EU, 1150 МГц, 441,6 Гфлопс)
- Iris Graphics 540 (GT3e, 48 EU, 64 МБ eDRAM, 1050 МГц, 806,4 Гфлопс)
- Iris Graphics 550 (GT3e, 48 EU, 64 МБ eDRAM, 1100 МГц, 844,8 Гфлопс)
- Iris Pro Graphics 580 (GT4e, 72 EU, 128 МБ eDRAM, 1000 МГц, 1152 Гфлопс)
- HD Graphics P530, сервер (GT2, 24 EU, 1150 МГц, 441,6 Гфлопс)
- Iris Pro Graphics P555, сервер (GT3e, 48 EU, 128 МБ eDRAM, 1000 МГц, 768 Гфлопс)
- Iris Pro Graphics P580, сервер (GT4e, 72 EU, 128 МБ eDRAM, 1000 МГц, 1152 Гфлопс)
О проекте
Задача кодирования видео при обработке мультимедиа, будь то передача, монтаж или редактирование, хранение, возникает постоянно как при разработке приложений и сервисов, так и при их настройке в момент использования. В силу большого количества популярных видеокодеков, даже зачастую одного типа, выбрать из них оптимальный, а затем задать правильные настройки, непросто. Вероятно, руководствуясь подобными соображениями, в лаборатории компьютерной графики и мультимедиа при факультете вычислительной математики и кибернетики (ВМиК) МГУ с 2000х ведется работа над проектом сравнения видеокодеков.
В октябре 2015 года был опубликован отчет сравнения кодеков, в котором участвуют некоторые кодеки формата HEVC, а так же несколько других, активно разрабатываемых в настоящее время. В качестве «эталонного» принят компрессор x264. Одним из интересных в отчете является компрессор x265, именно его изучением и займемся.
В качестве инструмента для анализа будем использовать SolveigMM Zond 265, анализатор файлов HEVC/H.265 и AVC/H.264.
Методика сравнения кодеков и подбора параметров
Опишем методику. Сравнение в отчете проводится по критериям битрейт-качество (SSIM, PSNR)-скорость.Описанная в отчете методика для сравнения соотношения битрейт/метрика качества (пункт C.4) следующая.
Выбираем несколько значений битрейта (например, 7 значений: 1, 2, 4, 6, 8, 10 и 12 Mbps), для них считаем необходимые метрики качества для каждого кодека.
Отмечаем полученные значения на графике: метрика качества (ось абсцисс) – битрейт (ось ординат).
- Линейно интерполируем.
- Выбираем максимально большой диапазон, на котором все графики определены, и находим площади под всеми графиками на нем.
- В качестве меры качества определенного кодека (или пресета) берем отношение его площади к площади для эталонного кодека. Чем меньше полученное число, тем эффективнее кодек.
Риппинг | x265 -p veryslow --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS% |
Универсальное кодирование | x265 -p medium --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS% |
Быстрое перекодирование | x265 -p ultrafast --ref 3 --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS% |
- Кодируем файл, меняя каждый параметр пресета: от быстрого перекодирования к универсальному, от универсального к «риппингу». При этом сохраняем время кодирования.
- Вычисляем меру качества (как площадь, указанную выше) и относительное время кодирования (минимальное значение FPS кодирования для файла «пресет-измененный параметр» относительно всех выбранных значений битрейта).
- Из таблицы, состоящей из изменяемого параметра, меры качества, минимального FPS, выбираем параметры, которые можно использовать для улучшения пресетов.
Как использовать кодек HEVC
Разумеется, обычного пользователя больше интересует вопрос, чем смотреть видео в формате HEVC/H.265, нежели технические подробности реализации улучшенного стандарта.
Если не привязываться к видеоадаптеру, то самый простой вариант – это использование программных плееров. В частности, всем хорошо известного VLC. Его последняя версия гарантированно поддерживает новый формат.
Но по умолчанию поддержка HEVC здесь выключена, и чтобы смотреть видео, закодированное H.265, необходимо выполнить следующие действия:
В результате вы получите возможность просматривать на компьютере видео, сжатое новым кодеком, вне зависимости от используемой операционной системы.
Примерно таким же способом можно установить HEVC/H.265 на Windows, используя последние версии других популярных медиаплееров – Media Player Classic, KMPlayer, GOM Player и других.
Поддержка H.265 реализована и в некоторых браузерах – Microsoft Edge (начиная с 16-й версии) и Safari (от одиннадцатой версии и выше).
Что касается MacOS High Sierra, то там с новым кодеком справляется стандартное приложение «Видео», хотя если вам нравятся сторонние плееры, то все вышесказанное остаётся справедливым. Аналогичная ситуация и с мобильными девайсами, работающими под iOS 11 – здесь главное, чтобы для воспроизведения нового формата хватило производительности устройства.
Что касается смартфонов и планшетов под Android, то на сегодня получить работающий кодек HEVC/H.265 можно только в приложении MX Player с тем же условием – производительности девайса должно хватать для воспроизведения видео нового формата.
Другое дело, что видео, записанного с использованием кодека HEVC, в сети пока не так много. Остаётся надеяться, что ситуация будет постепенно улучшаться, как это было с предшественником и разрешением 4К – сегодня количество каналов, вещающих в этом формате, растёт в арифметической прогрессии.
В немалой степени проблема касается и оборудования, способного поддерживать сверхвысокие разрешения – среди компьютерных мониторов таковых практически нет, да и телевизоры с разрешением 8192×4320 пикселей – пока не столь распространённое явление. Но технический прогресс не остановить…
Микроархитектура GPU 9-го поколения
Последняя версия QSV 5.0 вышла вместе с микроархитектурой ядра шестого поколения Skylake. Данная версия GPU в официальной документации Intel классифицируется как Gen9, то есть графика 9-го поколения.
Процессор Intel Core i7 6700K для настольных компьютеров содержит 4 ядра CPU и встроенную графику 9-го поколения HD Graphics 530
С каждой новой микроархитектурой в GPU увеличивалось количество блоков выполнения команд (EU). Оно выросло с 6 в Sandy Bridge до 72 в топовой графике Iris Pro Graphics 580 на кристаллах Skylake. В том числе за счёт этого производительность GPU увеличилась десятикратно без увеличения тактовой частоты. Во всей графике последнего поколения Iris и Iris Pro имеется встроенный кэш Level 4 на 64 или 128 МБ.
▍Микроархитектура блоков выполнения команд (EU)
Базовым строительным блоком микроархитектуры Gen9 является блок выполнения команд (EU). Каждый EU сочетает в себе одновременную многопоточность (SMT) и тщательно настроенную чередующуюся многопоточность (IMT). Здесь работают арифметическо-логические устройства с одиночным потоком команд, множественным потоком данных (SIMD ALU). Они выстроены по конвейерам многочисленных тредов для высокоскоростного проведения вычислений с плавающей запятой и целочисленных операций.
Суть чередующейся многопоточности в EU состоит в том, чтобы гарантировать непрерывный поток готовых для выполнения инструкций, но в то же время ставить в очередь с минимальной задержкой более сложные операции, такие как размещение векторов в памяти, запросы семплеров или другие системные коммуникации.
Блок выполнения команд (EU)
В зависимости от нагрузки, аппаратные треды в EU могут выполнять параллельно один код от одного вычислительного ядра либо могут выполнять код от совершенно разных вычислительных ядер. Состояние выполнения в каждом треде, в том числе его собственные указатели инструкций, хранятся в его независимом ARF. На каждом цикле EU может выдавать до четырёх различных инструкций, которые должны быть от четырёх различных тредов. Специальный арбитр тредов (Thread Arbiter) отправляет эти инструкции в один из четырёх функциональных блоков для выполнения. Обычно арбитр может выбирать из разнородных инструкций, чтобы одновременно загружать все функциональные блоки и, таким образом, обеспечивать параллелизм на уровне инструкций.
Пара модулей FPU на схеме на самом деле выполняет и операции с плавающей запятой, и целочисленные вычисления. В Gen9 эти модули способы обработать за цикл не только до четырёх операций с 32-битными числами, но и до восьми операций с 16-битными. Операции сложения и умножения выполняются одновременно, то есть блок EU способен выполнить максимум до 16 операций с 32-битными числами за один цикл: 2 FPU по 4 операции × 2 (сложение+умножение).
Генерацией SPMD-кода для многопоточной загрузки EU занимаются соответствующие компиляторы, такие как RenderScript, OpenCL, Microsoft DirectX Compute Shader, OpenGL Compute и C++AMP. Компилятор сам эвристически выбирает режим загрузки тредов (SIMD-width): SIMD-8, SIMD-16 или SIMD-32. Так, в случае SIMD-16 на одном EU могут одновременно исполняться 112 (16×7) потоков.
Обмен данными в рамках одной инструкции внутри блока EU может составлять, например, 96 байтов на чтение и 32 байтов на запись. При масштабировании на весь GPU с учётом нескольких уровней иерархии памяти получается, что максимальный теоретический лимит обмена данными между FPU и GRF достигает нескольких терабайт в секунду.
▍Масштабируемость
Микроархитектура GPU обладает масштабируемостью на всех уровнях. Масштабируемость на уровне тредов переходит в масштабируемость на уровне блоков выполнения команд. В свою очередь, эти блоки выполнения команд объединятся в группы по восемь штук (8 EU = 1 subslice).
На каждом уровне масштабирования имеются локальные модули, работающие только здесь. Например, для каждой группы из 8 блоков EU предназначен свой локальный диспетчер тредов, порт данных и семплер для текстур.
Группа из 8 блоков EU (subslice)
В свою очередь группы из 8 EU объединяются в группы по 24 EU (3 sublices = 1 slice). Эти срезы по 24 блока, в свою очередь, тоже масштабируются: существующая графика Gen9 содержит 24, 48 или 72 EU.
В графике Gen9 увеличен объём кэша третьего уровня L3 до 768 КБ на каждую группу из 24 EU. У всех семплеров и портов данных свой собственный интерфейс доступа к L3, позволяющий считать и записать по 64 байта за цикл. Таким образом, на группу из 24 EU приходится три порта данных с полосой передачи данных к кэшу L3 192 байта за цикл. Если в кэше нет данных по запросу, то данные запрашиваются или направляется для записи в системную память, тоже по 64 байта за цикл.
Микроархитектура Gen9 из двух групп по 24 (3×8) EU
Такая масштабируемость позволяет эффективно снижать энергопотребление, отключая те модули, которые не задействованы в данный момент.
Графические оболочки для легкого кодирования
Что такое формат H.265 (HEVC)
High Efficiency Video Coding на сегодняшний день является самым современным и продвинутым видеокодеком. Если H.264 (AVC), основанный на кодеке MPEG, был ориентирован на воспроизведение FullHD видео, то его сменщик способен сжимать видеоряд до разрешения UHDTV, или 8К.
Что интересно, к разработке более совершенного стандарта приступили в 2004 году, то есть всего через год после начала внедрения AVC. Первоначально проект назывался H.NGVC, что расшифровывается как Next-generation Video Coding, а затем за стандартом закрепилось нынешнее эволюционное название. Перед экспертной группой VCEG стояла нелёгкая задача: повысить разрешение видео, добившись снижения битрейта, при этом не увеличивая вычислительные мощности оборудования. Требования, прямо скажем, противоречивые, поэтому в полной мере их реализовать не удалось.
И всё-таки разработчикам удалось добиться главного: увеличения максимального размера блока, основной единицы кодека, в 16 раз по сравнению с H.264, у которого он равен 16х16 пикселей. При этом была задействована технология блоков динамического размера, когда кодек во время сжатия видео сам выбирает оптимальное количество пикселей в блоке. Это и позволило новому формату легко поддерживать разрешение 8К, хотя и 4К на сегодня внедряется не такими быстрыми темпами, как хотелось бы. Добавьте сюда технологию параллельного кодирования, и вы получите кодек, способный сжимать видео до размера, на 25-50% меньше, чем у предшественника, при том же качестве.
Новый стандарт был утверждён только в 2012 году и поначалу имел ограниченное применение – в телевидении и IP камерах. Но когда в 2017 году поддержку HEVC реализовали в iOS 11, ситуация начала быстро меняться.
59 комментария на “ Как кодировать видео? ”
Помогите пожалуйста! Выходит ошибка. ( Опишите подробно все действия от А до Я и с пояснениями, т.к. я новичёк. буду очень признателен. Пишите на емайл.Очень прошу!
У меня на XP даже X32 версии 0.7 пишут «x265.exe не является приложением win32»,
что я делаю не так. Вышеуказанный пакет стоит.
Сборщикам нужно было при компиляции Platform Toolset v120_xp указывать, а не просто v120 . По-умолчнию VS2013 не собирает для XP.
The link «The details can be found here (PDF in English)» is dead (error 404).
А где ссылки на оболочки?
Скоро добавим. Если дадите ссылок на самые лучшие, то это ускорит процесс.
админы как закодить видео в 60 fps при разрешении 1280-720 при качестве исходника
Any Body Have Setting Highly Compressed Anime X265. ??
Кодирую в X265 с помощью XviD4PSP . Удобно ИМХО.
Как вообще кодировать видео в x265? я полный чайник в этом.
Какая именно ошибка?
А видео в каком формате? На вход принимаются не все форматы. В описании программы об этом написано.
открывал через программу, она видит тока формат .avi.
как перевести видео дорожку в формате YUV или Y4M?
— не принимает формат: YUV или Y4M. Можете скинуть не большой отрезок видео для теста.
— Почему в программе при нажатии на «добавить файл»: выбирая все поддерживаемые форматы — отображается только: .avi и .avs, (YUV и Y4M — не видит)?
Можете скинуть не большой отрезок видео для теста.
формат: YUY2, YV12 без сжатия, HuffYUV — тоже не видит.
Кодировать в x265 сразу из многих форматов (а не только из «.yuv») можно программами Handbrake или Avidemux. Но в них свои версии x265 встроены.
Тем, кому нравится работать с командной строкой и кто не боится читать документацию, могу посоветовать установить AviSynth (позволяет писать .avs скрипты для открытия входного файла и его предварительной обработки) и avs4x265.exe позволяющую x265 работать с файлами .avs. И/или можно установить MeGUI в настройках которой нужно включить поддержку x265. После перезапуска она предложит скачать необходимые компоненты. После загрузки компонентов у неё в подкаталоге …\tools\x265\ будут avs4x265.exe и x265.exe (у меня была версия программы 1.8 которую можно заменить на одну из скачанных отсюда версий (2+). Также в MeGUI есть кнопка «One-Click» помогающая обойтись без ручного написания скриптов.
Пример содержимого файла-скрипта 1.avs с отрезанием черных полей в верхней и нижней части кадра и с приведением размера к 960×540 пикселей:
DirectShowSource(«C:\1\1.avi»)
Crop(0,120,-0,-120)
LanczosResize(960,540)
Пример содержимого файла 1.bat для быстрого кодирования с пяти тысячного кадра по шести тысячный (при использовании ключа —ssim в конце кодирования можно будет увидеть объективную оценку качества кодирования в метрике SSIM (чем больше — тем лучше качество перекодирования)):
«C:\1\avs4x265.exe» —x265-binary «C:\1\x265.exe» —preset ultrafast —tune ssim —seek 5000 —frames 1000 —ssim —output «C:\1\1 ultrafast.hevc» «C:\1\1.avs»
Baka Encoder — не кодирует, выдает ошибку.
программа воспринимает только .avi формат?
avi — это не формат, а контейнер, и да, другие контейнеры пока не поддерживаются, хотя в планах есть добавление поддержки mkv.
Поддерживаемые форматы явно перечислены на странице программы:
PCM аудио без сжатия, RGBA, RGB, RGB48, YUY2, YV12 без сжатия, HuffYUV, Lagarith (без null frames), UT Video, MJPG, Avisynth скрипты.
Хочу спросить на рутрекере писали что количество B кадров выше 3 снижает детализацию, это правда? Какое число B кадров лучше для советских мультфильмов? время кодирования значения не имеет.
И ещё CUTree в x.265 это аналог MB-Tree x.264 или что-то новое и какое соответствие CRF между этими кодеками?
Б нужно или 8 или 9 или 10. Смотря какой лог. Ниже — снижает детализацию. Что в иксе, что в хевке.
Кутри аналог дерева (MB-Tree) из икса, чуть измененное, на анимации юзать строго противопоказано, оно экономит на статике в угоду динамике, а в анимации куча статики. Црф я использую такие же, как и на иксе, иногда чуть сильнее. 15-17 диапазон для анимации.
А можно полную командную строку? А то перекодировал ролик ~4Mbps
720p вроде как перебор по битрейту
И какой вообще типичный битрейт Мультфильма/Фильма?
P.S. А по поводу дерева я кажется где-то читал что в X.265 оно работает на оборот по сравнению с X.264 (Или же про AQ ,но сильно сомневаюсь что про AQ)
cu-tree я отключал при кодировании
малодинамичной анимации, но результат мне не понравился: всё сильно размазалось и битрейт увеличился. Вообщем, проверяйте сами на маленьких отрезках.
Насчёт командной строки:
В x264 есть —tune animation — для аниме и мультипликации:
—ref (удваивает —ref если оно больше 1) —deblock 1:1 —psy-rd 0.4: —aq-strength 0.6 —bframes (стандартный —bframes + 2)
Видел настройки BVzCoder Tuned Anime 720p, действительно помогающие для анимаций:
—preset slower —tune psnr —crf 25 —limit-tu 0 —bframes 3 —ref 3 —rc-lookahead 60 —merange 60 —aq-mode 1 —aq-strength 0.6 —psy-rd 0.52 —psy-rdoq 0.00 —rd 6 —vbv-maxrate 1500 —vbv-bufsize 1500
Я составил для себя примерно такие параметры:
—keyint 1000 -F 1 —qcomp 0.80 —bframes 10 —ref 6 —deblock=1:1 —aq-mode 1 —aq-strength 0.6 —psy-rd 0.52 —psy-rdoq 0.00 —rd 6 —vbv-maxrate 1500 —vbv-bufsize 1500
crf зависит от разрешения и исходника, не могу сказать универсальную величину.
Кто-то ещё ставит «—keyint -1» — бесконечный GOP, но не рекомендую, так как перемотка будет очень медленной.
Для плёночных (старых) мультиков следует добавлять —rc-lookahead 100
При понижении разрешения использую строку в FFmpeg «-sws_flags lanczos+accurate_rnd» для резкости, но в случаи с плёночными мультиками она не нужна.
>~4Mbps
720p вроде как перебор по битрейту
Нет, если вам жалко битрейта, вам не жалко деталей в темных сценах, которых не будет из за недостатка битрейта.
>А можно полную командную строку?
avs2yuv64 -nstdr NCED3.avs -o — | x265-10bit-x64-v2.4-icc —ref 4 —bframes 9 —bframe-bias 0 —b-pyramid —b-adapt 2 —aq-mode 3 —qg-size 16 —no-rskip —aq-strength 0.85 —ctu 32 —deblock 1:-1 —min-cu-size 8 —max-tu-size 32 —tu-intra-depth 2 —tu-inter-depth 2 —rdpenalty 0 —me 2 —no-rect —no-amp —no-fast-intra —no-tskip-fast —no-tskip —max-merge 3 —temporal-mvp —no-strong-intra-smoothing —no-constrained-intra —no-open-gop —no-cutree —no-sao —no-sao-non-deblock —no-temporal-layers —wpp —subme 4 —qblur 0 —cplxblur 0 —crf-min 12 —crf-max 16 —crf 15 —qcomp 0.72 —b-pyramid —merange 48 —limit-refs 2 —keyint 240 —signhide —no-rd-refine —weightp —weightb —rd 4 —psy-rd 2 —rdoq-level 2 —limit-modes —psy-rdoq 2 —sar 1:1 —info —colorprim bt709 —transfer bt709 —colormatrix bt709 —output «NCED3.hevc» —csv-log-level 2 —csv «NCED3.txt» —y4m —
>cu-tree я отключал при кодировании
малодинамичной анимации, но результат мне не понравился: всё сильно размазалось и битрейт увеличился. Вообщем, проверяйте сами на маленьких отрезках.
Оно как и в x264 (хоть и работает чуть по другому) работает только во вред. Пока есть хоть какой то шум в исходнике, его нельзя использовать. На 10 бит ухдбд 4к можно будет попробовать, так как там не будет зерна и шума, который добавляют для предотвращения бандинга в 8 битных бд.
Странные у вас параметры:
1.B-Adapt 2 не рекомендуется для анимации даёт артефакты.
2. Разница между параметрами деблока не должна превышать 1(2??)
По крайней мере я читал такие рекомендации для X.264.
И да будет ли выше качество если использовать
—subme 7 —max-merge 5 —rd 6
Hi, thanks for the software
I’ve downloaded your latest build from your site, I’m using win10 and it always crashes when I launch the .exe
Can you help me? just mail me.
>1.B-Adapt 2 не рекомендуется для анимации даёт артефакты.
Это и
>2. Разница между параметрами деблока не должна превышать 1(2??)
это устаревшая инфа для старых версий x264.
B-Adapt на максимум (2) когда б фрэймс значения высокие.
Деблок оно на 1 давит не сильно блоки, на -1 порог позволяет не путать на большинстве аниме детали с блоками. На высоких битрейтах такие настройки оптимальны, высоких это более 2-3 мегабит.
>И да будет ли выше качество если использовать
—subme 7 —max-merge 5 —rd 6
Качество будет чуть чуть лучше, а вот скорость много медленнее.
Только сейчас обратил внимание у вас первый —deblock 1:-1 а, потом —no-sao-non-deblock как я понял второй отменяет первый и да я обрабатываю советский мультфильм и на одну серию налагается шумок какие в этом случае будут параметры?
Извините если достал, но за ту комстроку спасибо возможно пригодится.
sao-deblock это адаптивный деблок, фишка hevc, очень любит мазать, а первое — деблок перенесенный из x264.
Для зернистого сорца советую x264, hevc еще не может в такое, пытается экономить на битрейте и мажет шум.
Если у вас стабильно все видео есть зерно (не зернистое изображение оно испортит), то можно вот так сделать в x264:
—crf 17 —force-cfr —no-fast-pskip —no-mbtree —aq-mode 1 —aq-strength 0.6 —qcomp 0.9 —qpmax 50 —deblock -2:-2 —me umh —b-adapt 2 -b 12 -r 12 -w —mixed-refs —trellis 2 —b-pyramid normal —lookahead-threads 4 —direct spatial -A all -m 10 —merange 32 —psy-rd 1.2:0.0
У меня не зерно, у меня шумок(мелкодисперсный?),но не из слабых.
Я нашёл на rutracker пресет и модифицировал его:
—crf 23.5 —fps 29970/1000 —level-idc 5 —high-tier —vbv-bufsize 50000 —vbv-maxrate 50000 —qpstep 1 —preset placebo —ref 6 —aq-mode 3 —aq-strength 0.6 —aq-motion —limit-refs 3 —no-cutree —no-sao —no-deblock —merange 25 —max-merge 5 —ctu 32 —amp —b-intra —bframes 4 —b-adapt 2 —psy-rd 2.00 —psy-rdoq 3.00 —rdoq-level 2 —ipratio 1.10 —pbratio 1.00 —subme 7 —slow-firstpass —rc-lookahead 60 —lookahead-slices 0 —no-rskip —no-early-skip —no-fast-intra —no-strong-intra-smoothing
для зерна использовать: —psy-rd 2.0 —psy-rdoq 3.0
Оба для фильмов.
закодировал им(первый вариант) вступительный ролик к игре Lost Planet(720p) и как на меня видео стало даже чётче чем в оригинале, может если что то подкрутить сгодится и здесь?
Ах да, битрейт 4135.76 kb/s, Avg QP:25.24
Для зернистого сорца советую x264, hevc еще не может в такое, пытается экономить на битрейте и мажет шум.
На свой страх и риск короче, —psy-rd 2.0 в дефолте такое.
—psy-rdoq 3.0 можно и выше, но это визуальное качество,если рассматривать скриншоты, то все одно будут небольшие косяки) Разве что 2.5 билд сейчас тестирую, оно уделывает икс по детализации фона на аниме с небольшим уровнем шума. Так что пробуйте, крутите, но 4135.76 kb/s, Avg QP:25.24 как то слишком сильно сжало, —crf 23.5 оч много для анимации. от 15 до 18 как на x264 такие значения в среднем.
Вроде разобрался, но на засыпку ещё вопрос —rect —amp качество улучшат и какими ещё ключами можно улучшить качество?
P.S. Спасибо за помощь.
Нет, они на производительность, на 2.3 и 2.4 версии они немного поганили изо, как в 2.5 не знаю.
На 2.4+14 —rect —amp немного улучшают качество не ключевых кадров, но на моём двухядерном процессоре увеличивают время кодирования вдвое.
… но 4135.76 kb/s, Avg QP:25.24 как то слишком сильно сжало, —crf 23.5 оч много для анимации. от 15 до 18 как на x264 такие значения в среднем.
почему и написал что ~4mb/s перебор, должно было хватить 0.75-1.5mb/s 3 предел,но судя по скринам по ссылке кодек ещё неготов к «минимальным» для стандарта битрейтам.
P.S. Поправил ошибки если что.
Вообще где-то читал что 2X преимущество HEVC(стандарта) получается на плавных градиентах,а на высокодетализированном видео будет меньше.
Про качество:
—me можете в максимум крутнуть, но это + 10% качества и — 100% скорости)
Настройки скинутые мной подобраны мной же для аниме\мультфильмов, сильнее не надо, только их крутить (чаще всего просто крф подбирать) или, если есть мощный, очень мощный пк, то можно все тупо в максимум поставить и пофиг на скорость.
x265.exe input.y4m —q 17 —merange 64 —frames all —ref 4 —max-merge 3 —rect —hash 2 —me 3 —b 6 —b-adapt 1 —rd 2 —rc-lookahead 60 —input-depth 16 —tu-inter-depth=3 —tu-intra-depth=3 —no-tskip —no-tskip-fast —wpp —subme 2 —s 32 —F 6 —o video.hevc
где в этих настройках указывается какой выбран пресет (fast, medium и т.д.)?
Народ, кто вообще какой пресет выбирает и в каких случаях меняете? (т.е. faster, fast, medium, slow, veryslow, placebo)
Выбирай медиум и не мучайся!
Друзья, у вас очень важная ошибка в описании
«Разработчики подготовили набор параметров для соотношений время/качество кодирования.»
Тогда как в официальной документации речь идет о СТЕПЕНИ СЖАТИЯ
Presets:
-p/—preset Trade off performance for compression efficiency. Default medium
Исходя из вашего описания и исходя из того что термин «кодирование» вы никак не раскрываете, можно подумать что эта настройка имеет отношение к качеству видео, но это не так. Уже видел на хабре целую статьищу где чувак решил что это вдруг пресеты качества и на основе этого делает тесты.
В режиме -QP и -CRF это действительно объём, но о каком объёме может идти речь в режиме —bitrate?Для него это качество!
Сергей, а никто и не утверждает что это объем. В официальной документации это степень сжатия.
Чтобы было понятнее что это такое, обратите внимание на этот же параметр в архиваторах, 7z каком нибудь. Качество там всегда 100% (сжатие без потерь), но степень сжатия может быть разная. В одном случае вообще не сжато практически, в другом случае архиватор пытается сжать максимально, затратив на это кучу времени. А что касается объема, он в случае максимального сжатия может быть почти такой же как и при среднем, пару процентов выиграете.
Для этого же этот параметр и в кодеке — если есть у вас вагон времени и/или вычислительной мощности, вы можете потратить это сделав ролик на несколько процентов меньше, чем при среднем параметре. На качество видео это не влияет никак. В том числе, с параметром —bitrate.
Текущую ситуацию в области медиакодеков, можно описать буквально несколькими словами: простые решения себя исчерпали. С каждым годом материал для кодирования становится все сложнее, а требования к качеству результата – все выше. В этих условиях, когда лобовая атака уже не дает эффекта, особое значение приобретает оптимизация как кодирования, так и воспроизведения медиа под конкретные платформы с использованием их самых современных возможностей. Чего можно добиться такой оптимизацией, мы покажем на примере перспективного кодека Н.265. В качестве целевой платформы рассмотрим серверное решение Intel — процессор Xeon.
Краткое описание H.265/HEVC
- Особые возможности для произвольного доступа и сращивания цифровых потоков. В H.264/MPEG-4 AVC цифровой поток должен всегда начинаться с блока адресации IDR, а в HEVC поддерживается произвольный доступ.
- Изображение разделяется на единицы дерева кодирования (CTU), каждая из которых содержит блоки дерева кодирования (CTB) яркости и цветности. Во всех прежних стандартах кодирования видео использовался фиксированный размер массива для выборок яркости — 16×16. HEVC поддерживает блоки CTB разного размера, который выбирается в зависимости от потребностей кодировщика с точки зрения памяти и вычислительной мощности.
- Каждый блок кодирования (СВ) может быть рекурсивно разделен на блоки преобразования (ТВ). Разделение определяется остаточным квадродеревом. В отличие от прежних стандартов в HEVC один блок ТВ может охватывать несколько блоков предсказания (РВ) для перекрестных предсказываемых единиц кодирования (CU).
- Направленное предсказание с 33 различными направлениями ориентации для блоков преобразования (TB) размером от 4×4 до 32×32. Возможное направление предсказания — все 360 градусов. HEVC поддерживает различные методики кодирования предсказания интракадров.
Проблемы производительности HEVC
- Отсутствие параллельной схемы.
- Неэффективная настройка векторизации.
Рисунок 1. Профиль проекта HM — параллельная работа потоков
Рисунок 2. Профиль проекта HM — ресурсоемкий код
-
(совместим с HM10.0, оптимизация декодера) (совместим с HM, распараллеливание и векторизация)
Рисунок 3. Нагрузка на ЦП в проекте X.265
Рисунок 4. Проект X.265 с настройкой Intel® SIMD
В проекте x265 также были использованы инструкции Intel® SIMD (автогенерация компилятором), что обеспечило повышение производительности более чем на 70%. Вместе с дальнейшей оптимизацией компиляторными опциями, компилятор Intel обеспечивает удвоение производительности на платформе IA. Тем не менее, производительность кодировщика по-прежнему существенно ниже, чем требуется для кодировщика реального времени, особенно для видео высокой четкости с разрешением 1080p.
Ниже мы покажем результаты, достигнутые китайской компанией Strongene при поддержке специалистов компании Intel на пути оптимизации созданного ей кодека H.265/HEVC под различные платформы Intel.
Оптимизация HEVC под платформу Intel® Xeon™
Основную часть самых ресурсоемких функций по обработке видео и изображений составляют интенсивные вычисления блочных данных. Для их оптимизации можно использовать инструкции векторизации Intel® SIMD. В кодировщике в составе кодека Strongene, согласно данным профилирования, с помощью инструкций Intel SSE можно провести ручную векторизацию всех наиболее ресурсоемких функций, таких как кадровая интерполяция низкой сложности с компенсацией движения; целочисленное преобразование без транспозиции; преобразование Адамара; вычисление сумм абсолютных разностей (SAD)/квадратов разности (SSD) с наименьшим избыточным использованием памяти. Мы включили инструкции Intel SSE в виде интринсик-функций, как показано на рис. 5.
Рисунок 5. Пример включения инструкций Intel® SIMD/SSE в кодеке Stongene
Разработчики Strongene переписали все ресурсоемкие функции, чтобы добиться наибольшего прироста производительности кодировщика. На рис. 6 показаны наши данные профилирования в сценарии кодирования видео стандарта 1080p с помощью HEVC. Видно, что 60% ресурсоемких функций обрабатываются инструкциями Intel SIMD.
Рисунок 6. Результаты профилирования функций кодирования Strogene
Таблица 1. Результаты реализации Intel® SSE и Intel® AVX2
Циклы ЦП | Исходный код | Intel® SSE | Intel® AVX2 |
---|---|---|---|
Запуск 1 | 98877 | 977 | 679 |
Запуск 2 | 98463 | 1092 | 690 |
Запуск 3 | 98152 | 978 | 679 |
Запуск 4 | 98003 | 943 | 679 |
Запуск 5 | 98118 | 954 | 678 |
Среднее | 98322,6 | 988,8 | 681 |
Ускорение | 1,00 | 99,44 | 144,38 |
Как видно из таблицы 1, применение инструкций Intel SSE и Intel AVX2 обеспечивает повышение производительности в 100 раз, при этом код Intel AVX2 дополнительно выигрывает еще 40% по сравнению с Intel SSE.
Как мы видели ранее, в большинстве существующих реализаций используются не все ядра многоядерных платформ. Опираясь на последнюю многоядерную архитектуру Intel Xeon с параллельной зависимостью между алгоритмами на основе CTB, разработчики Strongene предлагают заменить исходные методы OWF и WPP параллельной структурой IFW, а затем разработать трехуровневую схему управления потоками, чтобы гарантировать полное использование структурой IFW всех ядер ЦП для ускорения кодирования HEVC.
Рисунок 7. Параллельная работа потоков и использование ЦП в кодировщике Strongene
За счет применения новой параллельной структуры WHP и полной реализации инструкций Intel SIMD соответственно на уровне задач и уровне данных разработчикам кодировщика Strongene удалось добиться весьма значительного повышения производительности на процессорах x86 для видео с разрешением 1080p, используя вычислительные ресурсы всех ядер, как показано на рис. 8.
Дальнейшая настройка с использованием SMT/HT
Также представляет интерес зависимость производительности кодека от включения в системе широко распространенной на всех платформах с архитектурой Intel одновременной многопоточности (SMT), также называемой технологией гипертрединга (HT).
Таблица 2. Скорость кодирования Strongene HEVC на платформе Intel® Xeon®
Как видно из таблицы (показано желтым цветом) на платформе Ivy Bridge (процессор Intel Xeon E5-2697 v2 для отключенного SMT кодирование видео HEVC с разрешением 1080p осуществляется в реальном времени!
Добившись огромнейшего увеличения производительности, мы продолжили изучение возможностей кодирования Strongene HEVC на платформе Ivy Bridge, уделяя внимание скорости потока и вопросам качества.
Таблица 3. Сравнение производительности кодеков H.264 и H.265
В таблице 3 видно, что кодек H.265/HEVC снижает объем данных на 50% при сохранении прежнего качества видеоизображения.
H.265/HEVC, по всей видимости, станет наиболее популярным стандартом видео в ближайшее десятилетие. Во множестве приложений и продуктов мультимедиа в настоящее время реализуется поддержка HEVC. В этом документе мы реализовали основанное на ЦП полнофункциональное решение HEVC реального времени на платформах Intel с новыми технологиями IA. Наше оптимизированное решение на базе процессоров Intel развернуто в компании Xunlei, занимающейся предоставлением услуг видео через Интернет, и будет способствовать повсеместному внедрению и распространению технологии H.265/HEVC.
В октябре 2015 был выпущен очередной отчет сравнения кодеков в ВМиК МГУ, на этот раз туда вошло несколько кодеков формата HEVC.
Исходной точкой к исследованию стало то, что мы заметили разницу в пресетах в тестах для AVC и HEVC — для AVC использовался немодифицированный быстрый профиль с одним GOP, а для HEVC использовался модифицированный с несколькими GOP. При этом для единственного описанного в открытом отчете файла “Apple Tree” кодер x264 оказался лучше x265 при быстром перекодированим на графиках зависимости SSIM от битрейта без учета скорости кодирования. Сразу же возник вопрос: может, эти опции или еще какие-то другие очевидные способны изменить указанную картину.
В отчете сравниваются пресеты, но не даются рекомендации по их исправлению. В данной статье мы провели аналогичное сравнение и привели рекомендации по модификации пресетов кодера х265. Для видеопоследовательности, аналогичной исследуемой в бесплатной версии отчета, предлагаемые изменения параметров кодирования позволяют повысить эффективность сжатия, при этом они реабилитируют кодер x265 при построении графиков отчета.
Измененные пресеты не претендуют на универсальность, тестирование на большом количестве видеопоследовательностей выходит за рамки данного исследования. Однако их можно рекомендовать как отправную точку при поиске возможностей увеличения эффективности кодирования x265.
Тестирование
Ссылка для скачивания тестовой последовательности «Apple Tree» (рис. 1), используемой в бесплатной версии отчета, не указана. Выберем аналогичную, используя ее ключевую особенность – крупный план, большое количество мелких деталей. Например «big_buck_bunny_1080p_h264.mov», интервал в 338 кадров с 24 секунды:
ffmpeg -i big_buck_bunny_1080p_h264.mov -ss 00:00:24 -frames:v 338 -c:v rawvideo -pix_fmt yuv420p sample.yuv
Рисунок 1. Характеристика последовательности «Apple Tree»
Для того чтобы при реализации трех шагов плана, указанного выше, не тратить много времени на выписывание необходимых чисел из интерфейса Zond 265, удобно использовать его возможность работы в командной строке (таблица 3):
zond265_x64 %COMPRESSED_FILE% -iref %REFERENCE_420P_FILE% -nowait -report t=quality,statstream qm=SSIM o=%TARGET_CSV_FILE%
Список всех параметров, а также их подробное описание можно посмотреть на странице документации Zond 265.
Параметр | Описание |
-iref | Задание референсного YUV файла |
-report | Указание режима работы Zond 265 в командной строке |
t=quality,statstream | Здесь выбрана генерация двух отчетов: качества и статистики о видеопотоке |
qm=SSIM | Метрика качества для вычисления |
o | Путь до файла отчета в формате CSV |
-nowait | Без пауз, Zond 265 должен сам переходить от файла к файлу без задержек |
Вот два скрипта для Python 2.7: один для кодирования 266 файлов (20 настроек для первого, 18 настроек для второго пресета, для 7 значений битрейта: 1, 2, 4, 6, 8, 10, 12 Mbps), второй для составления отчета в формате CSV (файл – отношение FPS кодирования к эталонной конфигурации – отношение метрики SSIM к эталонной конфигурации).
Как видно из таблиц отчетов для фрагмента файла «big_buck_bunny_1080p_h264.mov» (таблицы 5 и 6), модифицировать конфигурации можно, например, так, как указано в таблице 4. Напомним, для улучшения эффективности значение «Мера качества» должно быть меньше единицы, а значение «Относительное время кодирования» – больше единицы.
Тест выполнен на компьютере следующей конфигурации: Intel Core i7-2600@3.4 GHz, 16 GB RAM. Наибольшее улучшение качества дает параметр «--min-cu-size 8» для конфигурации быстрого кодирования, для универсального кодирования – параметр «--rdoq-level 2» (но он же более всего замедляет кодирование).
Быстрое перекодирование | x265 -p ultrafast --ref 3 --rc-lookahead 20 --min-cu-size 8 --bframes 4 --early-skip --cutree --tune ssim --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS% |
Универсальное кодирование | x265 -p medium --weightb --bframes 8 --tu-intra-depth 3 --psy-rdoq 1.0 --b-intra --lookahead-slices 0 --tune ssim --bitrate %BITRATE_KBPS% %SOURCE_FILE% -o %TARGET_FILE% --input-res %WIDTH%x%HEIGHT% --fps %FPS% |
Таблица 5. Отчет о модификации пресета быстрого перекодирования
Таблица 6. Отчет о модификации пресета универсального кодирования
Правильность выбора опций легко проверить, запустив скрипт кодирования с измененными пресетами (таблица 7).
Конфигурация | Мера качества | Относительное время кодирования |
Быстрое перекодирование (эталон) | 1 | 1 |
Быстрое перекодирование, модифицированное | 0.69 | 0.97 |
Универсальное перекодирование (эталон) | 1 | 1 |
Универсальное перекодирование, модифицированное | 0.85 | 0.94 |
Попробуем взглянуть, на что повлияло изменение опций – откроем в Zond 265 файл, закодированный измененным пресетом при быстром перекодировании для битрейта 8 Mbps и сравним его с файлом, закодированным неизмененным пресетом. Размер максимального блока кодирования остался прежним, и равен 32x32 (область «--ctu 32»). Но размер минимального блока уменьшился с 16 до 8 (область «--min-cu-size 8»), именно этот параметр дал наибольшее увеличение качества. Увеличилось число B-кадров с 3 до 4 (область «--bframes 4»), но при этом увеличилось и максимальное число «референсных» кадров (область «--ref 4»). Областью «SSIM» выделены максимальные значения графиков SSIM/PSNR для трех компонент: яркости (Luma) и двух компонент цветности (Cb, Cr). Они увеличились с 0.9623-0.9966 до 0.9771-0.9991. Оставшиеся дополнительные параметры (--rc-lookahead 20 --early-skip --cutree) влияют на алгоритм кодирования, а не на тип получившегося видео, это отражается, главным образом, на скорости кодирования (см. табл. 5). Надо отметить, визуально картинка декодированного кадра изменилась – артефакты кодирования теперь не видно.
Рисунок 2. Скриншот Zond 265 файла, закодированным с использованием исправленной конфигурацией быстрого кодирования
Аналогично можно проверить параметры закодированного файла с измененным и неизмененным пресетом универсального кодирования (рисунок 3). Размер минимальных разбиений TU не изменился и остался равным 4x4 (область «--tu-intra-depth 3»), количество B-кадров осталось неизменным и равно 3 (область «--bframes 3»). SSIM увеличился с 0.9789-0.9994 до 0.9811-0.9992. По сравнению с конфигурацией быстрого перекодирования увеличился размер максимального блока, стал равным 64x64 (область «--ctu 64»), добавился SAO фильтр (область «--sao»).
Рисунок 3. Скриншот Zond 265 файла, закодированным с использованием исправленной конфигурацией универсального кодирования
Таким образом, на основе проведенного тестирования предложен список опций для улучшения эффективности кодирования (улучшение значения метрики SSIM при том же битрейте и скорости кодирования) для конфигураций быстрого и универсального кодирования. С использованием предложенных изменений для файла с большим количеством мелких деталей, значение интегральной «меры качества» отчета «MSU HEVC Video Codec Comparison» при быстром перекидировании улучшилось на 31%, а при универсальном – на 15%, при этом скорость кодирования изменилась несущественно. Т.к. тестирование проведено для каждой опции отдельно, то на практике можно выбирать и использовать лишь некоторые удобные опции, а не весь предложенный список.
Более шести лет назад 13 сентября 2010 года на форуме IDF компания Intel представила микроархитектуру процессоров Sandy Bridge — второго поколения процессоров Intel Core. Процессор и графическое ядро объединили на одном кристалле, а само графическое ядро значительно обновилось и увеличило тактовую частоту. Именно в Sandy Bridge появилось «секретное оружие» — технология Intel Quick Sync Video (QSV) для аппаратного ускорения кодирования и декодирования видео. Маленький участок SoC специально выделили для размещения специализированных интегральных схем, которые занимаются только видео. Это был настоящий аппаратный транскодер .
Встроенная графика 9-го поколения HD Graphics 530 в процессоре Intel Core i7 6700K с 24 блоками выполнения команд (EU), организованными в три фрагмента по 8 блоков.
Удивительно, но Intel сумела обойти и AMD, и Nvidia в реализации аппаратного ускорения кодирования видео: похожие технологии AMD Video Codec Engine и Nvidia NVENC в видеокартах AMD и Nvidia появились со значительным опозданием (алгоритмы компрессии требуют серьёзной адаптации под процессоры видеокарт). Вот почему идея и разработка QSV хранились в секрете пять лет.
Сказать, что QSV была востребована — значит, ничего не сказать. Воспроизведение (декодирование) видео с аппаратной поддержкой стало гораздо меньше отнимать ресурсов у других задач в ОС, меньше нагревать CPU и потреблять меньше электроэнергии.
К тому же, в последние годы кодирование видео стало одной из самых ресурсоёмких задач на ПК. Популярность YouTube превратила миллионы человек в операторов и режиссёров. А тут ещё и повсеместное распространение смартфонов, для которых требуется транскодирование с DVD в сжатый AVC MP4/H.264. В результате, практически каждый ПК стал видеостудией. Массово распространились IPTV и потоковые видеотрансляции в интернете. Компьютер начал выполнять роль телевизора. Видео стало вездесущим и превратилось в один из самых популярных видов контента на ПК. Оно кодируется и транскодируется постоянно и везде: на разные битрейты, в зависимости от типа устройства, размера экрана и скорости интернета. В такой ситуации возможность быстрого кодирования и декодирования видео в процессорах напрашивалась сама собой. Так в Intel GPU встроили аппаратный кодер/декодер.
Современный кодек обрабатывает каждый кадр в отдельности, но также анализирует последовательность кадров на предмет повторений во времени (между кадрами) и пространстве (внутри одного кадра). Это сложная вычислительная задача. Ниже показан пример кадра из видео, который закодирован новейшим кодеком HEVC. Для конкретного участка возле уха зайца показано, как именно были закодированы различные участки кадра. Также показано положение и тип кадра в общей структуре видеопотока. Не углубляясь в детали алгоритмов видеокомпрессии, это даёт общее представление, насколько много информации требуется анализировать, чтобы эффективно кодировать и декодировать видео.
Скриншот открытого видео в программе Elecard StreamEye, 1920×1040
Аппаратная поддержка кодирования и декодирования означает, что непосредственно в процессоре реализованы интегральные схемы, специализированные для конкретных задач кодирования и декодирования. Например, дискретное косинусное преобразования (DCT) выполняется при кодировании, а обратное дискретное косинусное преобразования — при декодировании.
За прошедшие пять лет технология Intel QSV значительно продвинулась вперёд. Добавлена поддержка свободных видеокодеков VP8 и VP9, обновлены драйверы под Linux и т.д.
Технология улучшалась с каждым новым поколением Intel Core, вплоть до нынешнего 6-го поколения Skylake.
Использование энкодера x265 из командной строки
Энкодер берет на вход файлы в формате YUV или Y4M. Размер картинки (ширина и высота), а также частота кадров (FPS) должны быть заданы. Кодирование запускается с командной строки, по аналогии с x264. Кодировать можно с постоянным битрейтом (флаг —bitrate) или с постоянным качеством (флаг —crf). Пример для постоянного битрейта:
x265.exe input.yuv --input-res 1920x1080 --fps 50 --bitrate 14000 --input-depth 8 -o output.x265
Пример для постоянного качества:
x265.exe input.yuv --input-res 1920x1080 --fps 50 --crf 17 --input-depth 8 -o output.x265
На выходе будет файл в сыром формате x265: output.x265 Разработчики подготовили набор параметров для соотношений время/качество кодирования. Эти параметры задаются с помощью флага —preset. Полный список (от самого быстрого до самого медленного): ultrafast, faster, fast, medium, slow, veryslow, placebo. По умолчанию используется пресет ‘medium’. Пример для установки пресета:
x265.exe input.yuv --input-res 1920x1080 --fps 50 --crf 17 --input-depth 8 --preset veryslow -o output.x265
Для тонкой настройки кодирования существует огромное множество различных флагов, которые можно настраивать под свои потребности. Например, строчка с дополнительными параметрами обеспечивающая более высокое качество, может выглядеть так:
x265.exe input.y4m --q 17 --merange 64 --frames all --ref 4 --max-merge 3 --rect --hash 2 --me 3 --b 6 --b-adapt 1 --rd 2 --rc-lookahead 60 --input-depth 16 --tu-inter-depth=3 --tu-intra-depth=3 --no-tskip --no-tskip-fast --wpp --subme 2 --s 32 --F 6 --o video.hevc
Подробности можно посмотреть в документации здесь (PDF на английском).
Преимущества HEVC по отношению к старым форматам
С выходом iOS 11 и macOS High Sierra Apple начала усиленно продвигать новые форматы для изображений (HEIF) и видео (HEVC). Задача упростилась в том плане, что новый кодек обеспечивал либо видео лучшего разрешения, либо меньшего размера, что в эпоху глобального обмена контентом имеет немаловажное значение – попробуйте передать по сети файл размером с 10-20 ГБ.
Использование блоков большего размера позволило также сократить время, затрачиваемое на кодирование и, что не менее важно, на декодирование, предотвращая фризы при просмотре видео.
Частично улучшения характеристик нового формата удалось добиться за счёт использования новых технологий, о которых мы уже упоминали. Но за всё нужно платить. В данном случае речь идёт о возрастании нагрузки на аппаратную часть, из чего следует вывод, что для обеспечения декодирования видео в формате HEVC потребуется более мощное оборудование. Второй негативный момент связан с тем, что соответствующие кодеки, по крайней мере, на начальном этапе распространения формата, встроены в популярные проигрыватели в ограниченном количестве. Ещё хуже обстоят дела с «железом» – только передовые модели телевизоров, медиаплееров, телевизионной техники и IP-камер умеют «переваривать» этот формат. Но это, разумеется, дело поправимое в среднесрочной перспективе. Во всяком случае, уже сейчас количество доступных аппаратных и софтверных декодеров стремительно растёт.
Что касается ПК, то поначалу H.265 поддерживали только видеокарты 970/980 от GeForce, а для кодирования среднего видео этого формата на более слабом оборудовании требовалось порядка 10 часов. Сегодня ситуация в этом плане гораздо более благоприятная, а дивиденды от использования HEVC очень даже ощутимы. Главное, что выгода будет тем больше, чем выше качество видео: для разрешения 720p, которое ещё совсем недавно было «золотым стандартом», размер файла будет примерно на 25% меньше, чем в формате H.264. Но для 4К выигрыш составит уже 50%, а если говорить о рипах Blue-ray, то здесь экономия достигается десятикратная, то есть видео такого качества вполне можно упаковать в каких-то 3-4 ГБ.
Рассмотрим основные особенности кодека HEVC с технической точки зрения:
Разумеется, это не все технологические новшества, характеризующие новый кодек. Но и перечисленного вполне достаточно, чтобы специалист смог понять, на что способен новый формат.
Что требуется?
Выберите один из методов:
- Скачайте исходники из официального репозитория и скомпилируйте энкодер x265.exe под свою систему.
- Скачайте одну из последних сборок x265.exe с нашего сайта.
- Используйте программу кодирования с графической оболочкой (см. конец страницы).
Как программы используют аппаратное ускорение
Чтобы использовать аппаратное ускорение, каждая программа должна явно реализовать поддержку специфических функций Gen9. Многие делают это. Компания Intel публикует в открытом доступе Media SDK 2.0, так что поддержку аппаратного ускорения кодирования и декодирования можно внедрить в любую программу. Кроме того, существуют готовые приложения для транскодирования лайв видео на кодеках Intel, такие как Элекард CodecWorks 990. В отличие от SDK, CodecWorks 990 не требует участия программистов для применения в реальных задачах, уже содержит наиболее популярные профили транскодирования и работать с ним инженеру-не программисту в целом гораздо проще, чем с SDK. Как работают программные транскодеры с аппаратным ускорением — мы расскажем в следующей части.
Распространённый в «нулевых» формат DVD, основанный на кодеке MPEG2, по мере появления телевизоров и мониторов с высоким разрешением уже не мог удовлетворять возросшим требованиям к качеству видео. Поэтому появление в 2003 году формата кодирования H.264 было воспринято в основном доброжелательно. Но со временем и этот стандарт перестал отвечать современным нуждам – требовался такой кодек, который бы обеспечивал меньший размер файла при том же битрейте (или увеличенный битрейт при неизменном объёме видеофайла). Так появился усовершенствованный формат H.265, именуемый также HEVC, позволивший уменьшить размеры файлов на 30-50% при сравнимом качестве. В нём реализована поддержка разрешения уровня 8К (8192×4320 пикселей). Насколько успешно продвигается этот стандарт? Давайте разбираться.
Что требуется?
Выберите один из методов:
- Скачайте исходники из официального репозитория и скомпилируйте энкодер x265.exe под свою систему.
- Скачайте одну из последних сборок x265.exe с нашего сайта.
- Используйте программу кодирования с графической оболочкой (см. конец страницы).
Читайте также: