Удивительно, но факт - стандарту сжатия видео High Efficiency Video Coding (HEVC) уже более трех лет. Существуют не только программные, но и аппаратные решения для кодирования и даже бытовые медиаплееры с поддержкой этого формата. Интернет завален рекламными хвалебными восторженными отзывами и обзорами, причем обозреватели, в зависимости от наглости безграмотности доверчивости, обещают улучшение сжатия на 30-50% по сравнению с h.264 при том же качестве картинки. Теоретически оно наверняка так и есть и я совершенно ничего не имею против самого стандарта, всей этой высшей математики, множественности профайлов и объективной оценки субъективного восприятия психофизиологических параметров с помощью PSNR. Побудительным мотивом для написания этой антинаучной статьи послужила чистая недоверчивость, желание самостоятельно пощупать имеющиеся на данный момент свободные реализации кодировщиков видео в этот формат (x265) и сравнить результаты со старым добрым x264.

Чтобы понять масштаб проблемы и степень моей недоверчивости, отмечу, что я не верю в аппаратное кодирование в h.264/AVC (а точнее уверен, что с той же и скоростью при лучшем качестве может работать и чисто программный x264.exe), не верю в кодирование видео с помощью CUDA и DXVA и считаю все реализации таких «кодировщиков» чистым шарлатанством и не верю в магические двухкнопочные программы, которые могут «закодировать быстро и хорошо». Еще я не верю в демократию, антивирусы и современное высшее образование, но это уже чисто мои проблемы не имеющие отношения в кодированию видео:)
А теперь, зарядившись изрядной долей скептицизма возьмем один из скомпилированных вариантов свободного кодировщика x265 , а точнее восьмибитовую GCC сборку 1.7+286 и все дальнейшие действия будем производить с ней.
В этом пункте, кстати, моя недоверчивость опять взбрыкнула и пришлось потратить около 6 часов для сравнения 11 разных сборок с разных сайтов чтобы ее успокоить. Оказалось что результаты кодирования с аналогичными параметрами были идентичны до степени смешения, а время кодирования отличалось не больше чем на 5-6 процентов.
Для начала, возьмем в качестве исходника упомянутый выше отрывок из Аватара брызги-дерево-туман и чтобы исключить тормоза декодера, сохраним 100 кадров и из него в виде несжатого YUV4MPEG2 файла, который в дальнейшем и будет кодироваться. В x265 по умолчанию применяется CRF метод сжатия с постоянным качеством, поэтому закодируем и в x264 тоже в режиме CRF с показателем качества 17.2. Цифра взята не с потолка, а опытным путем выяснено что любое увеличение этой цифры ведет к понижению и битрейта и качества картинки на выходе, а уменьшение только повышает битрейт без какого-либо заметного увеличения качества. Конечно же остальные параметры кодирования были тоже на максимуме и в результате получился сжатый файл с битрейтом 17.6 Mb/s (что почти в 2 раза ниже исходных 31 Mb/s на BD диске). Время кодирования 100 кадров - 40 секунд . Качество картинки получилось почти идентичным по сравнению с исходником и даже не стоит выкладывать сравнение. В дальнейшем мы будем сравнивать 12-й В-кадр файла x264-17.2.mkv с разными вариантами кодирования в HEVC.

А вот тут пора вспомнить что пресет placebo использует далеко не самые максимально возможные параметры . Наиболее важные здесь --me star (при максимальном значении full) и --subme 5 (при максимальном 7). Попробуем ужесточить условия и вручную сказать
"E:\Video\x265\x265_64-8.exe" "E:\Video\avatar\raw.y4m" --preset placebo --me full --subme 7 --psy-rd 0.5 --psy-rdoq 0.5 --output "E:\Video\avatar\x265-test1.mkv" Сразу же становится понятным почему разработчики не рискнули вставить в «максимальный» профайл максимальные значения параметров. Время кодирования увеличилось более чем в 10 раз


И стоил ли результат этих жертв? не уверен…
Итак попытка #3, crf 20, -me full --subme 7, битрейт 9045 kb/s - 77 минут кодирования

И тут же сравнение результатов пресета placebo с вручную заданными -me full --subme 7

Выкидываем вручную заданные me, subme и ползем дальше.
Попытка #4, crf 18, битрейт 12922 kb/s - почти хорошо, но x264 пока лучше

Теперь посмотрим что будет если закодировать в x265 с тем же битрейтом что и x264 и с максимальными параметрами.
Этого же битрейта удалось достичь при значении crf 16.2. В этот раз кодирование заняло 90 минут.
Ссылка на файл

Результаты очень близки, но все же x264 сохранил чуть больше деталей и добавил чуть меньше мыла.
Вывод: Текущие реализации x265 проигрывают по качеству x264 на высоких битрейтах.

Вот мы и подошли к основному посылу всей статьи. Форматы сжатия видео вместе со всем остальным миром катятся в сторону упрощения и отупления населения. Никому не интересно иметь потребителя, который разглядывает скриншоты сравнений, борется за каждый лишний пиксель искажений, вчитывается в параметры кодирования и т.д. Все затачивается на максимально быстрые и смешные профайлы кодирования с минимальными битрейтами. Наверняка на низких битрейтах x265 будет иметь значительное преимущество над x264. Хотя и там и там будет масса искажений и мыла, но у x264 будет больше. Проверим.
Попытка #5, x265 5371 kb/s, x264 5374 kb/s

А вот и не отгадали:) Даже на родном для x265 битрейте x264 выглядит поприличнее.

В данный момент идет активная разработка энкодера, но он все ещё находится в состоянии «бета»-версии. Работает медленно и не очень эффективно. Релизы новых версий выходят очень часто.

Что требуется?

Выберите один из методов:

1. Скачайте исходники из официального репозитория и скомпилируйте энкодер x265.exe под свою систему.
2. Скачайте одну из последних сборок x265.exe с нашего сайта.
3. Используйте программу кодирования с графической оболочкой (см. конец страницы).

Использование энкодера 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

• Перевод

Текущую ситуацию в области медиакодеков, можно описать буквально несколькими словами: простые решения себя исчерпали. С каждым годом материал для кодирования становится все сложнее, а требования к качеству результата – все выше. В этих условиях, когда лобовая атака уже не дает эффекта, особое значение приобретает оптимизация как кодирования, так и воспроизведения медиа под конкретные платформы с использованием их самых современных возможностей. Чего можно добиться такой оптимизацией, мы покажем на примере перспективного кодека Н.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 - ресурсоемкий код

Этот кодек HEVC потребляет, по сравнению с H.264, в 100 раз больше ресурсов ЦП на стороне сервера и в 10 раз больше - на стороне клиента.
Кодек H.265/HEVC привлек внимание множества компаний и организаций во всем мире, что повлекло оптимизацию его производительности и фактическую разработку. Существует несколько проектов с открытым исходным кодом.

• OpenHEVC (совместим с HM10.0, оптимизация декодера)
• x265 (совместим с HM, распараллеливание и векторизация)

Рисунок 4. Проект X.265 с настройкой Intel® SIMD

В проекте x265 также были использованы инструкции Intel® SIMD (автогенерация компилятором), что обеспечило повышение производительности более чем на 70%. Вместе с дальнейшей оптимизацией компиляторными опциями, компилятор Intel обеспечивает удвоение производительности на платформе IA. Тем не менее, производительность кодировщика по-прежнему существенно ниже, чем требуется для кодировщика реального времени, особенно для видео высокой четкости с разрешением 1080p.
Ниже мы покажем результаты, достигнутые китайской компанией Strongene при поддержке специалистов компании Intel на пути оптимизации созданного ей кодека H.265/HEVC под различные платформы Intel.

Оптимизация HEVC под платформу Intel® Xeon™

Рисунок 5. Пример включения инструкций Intel® SIMD/SSE в кодеке Stongene

Разработчики Strongene переписали все ресурсоемкие функции, чтобы добиться наибольшего прироста производительности кодировщика. На рис. 6 показаны наши данные профилирования в сценарии кодирования видео стандарта 1080p с помощью HEVC. Видно, что 60% ресурсоемких функций обрабатываются инструкциями Intel SIMD.

Рисунок 6. Результаты профилирования функций кодирования Strogene

Инструкции Intel AVX2 с вычислением 256-разрядных целочисленных значений обладают вдвое более высокой производительностью по сравнению с прежним кодом Intel SSE, работающим со 128-разрядными значениями. Набор инструкций Intel AVX2 поддерживается платформой
Intel Xeon (Haswell), выпуск которой начат в 2014 году. Для оценки производительности встроенных функций Intel AVX2 мы используем распространенное вычисление сумм абсолютных разностей для блока 64*64.

Таблица 1. Результаты реализации Intel® SSE и Intel® AVX2

Рисунок 7. Параллельная работа потоков и использование ЦП в кодировщике Strongene

За счет применения новой параллельной структуры WHP и полной реализации инструкций Intel SIMD соответственно на уровне задач и уровне данных разработчикам кодировщика Strongene удалось добиться весьма значительного повышения производительности на процессорах x86 для видео с разрешением 1080p, используя вычислительные ресурсы всех ядер, как показано на рис. 8.

Дальнейшая настройка с использованием 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.

x265 - это открытая реализация нового стандарта кодирования видео H.265 HighEfficiencyVideoCoding (HEVC). Стандарт H.265 является логическим продолжением H.264 и характеризуется более эффективными алгоритмами сжатия. Стандарт предполагает примерно двукратное уменьшение размера файла при одинаковом визуальном качестве, по сравнению с H.264 и поддержку высоких разрешений вплоть до 8K UHD (8192×4320).

Преимущества H.265

Гибкий кодек H.264 получил широкое применение в сетях распространения потокового видео, на спутниковых платформах, а также при записи Blu-ray дисков. Он весьма хорош для масштабирования, благодаря чему он был предложен в качестве стандарта для 3D с частотой 48-60 кадров в секунду, и даже для 4К (хотя кодек не создавался для данного формата). H.264 вполне справляется с этими задачами. Стандарт, принятый для Blu-ray дисков, пока не включает в себя каких-либо рекомендаций относительно данных технологий, однако кодек H.264 сам по себе способен их поддерживать.

Особенность кодека H.264 заключается в том, что при способности кодировать видео в этих форматах, он не может обеспечить степень сжатия, которая бы сделала размеры получаемых файлов меньше.

Новый стандарт в кодеке H.265 смог существенно уменьшить размеры сжатых файлов и тем самым заслужил международное признание в качестве средства продвижения новых форматов видео. В H.265 использованы новые технологии сжатия и «умная» модель кодирования/декодирования, что позволяет экономно использовать пропускные ресурсы канала. Кодек разрабатывался с учётом всех особенностей 4К (поддержку 10-битового видео, высокую частоту кадров).

Размеры кодирования определяются настройками квантователя (цифрового преобразователя), где более низкие q-показатели соответствуют более высокому качеству (и большему размеру файлов). Базовый кодированный файл состоит из 500 кадров, его размер – 1,5 Гб, YUV 4:2:0, частота кадров – 50 в секунду. Для сравнения использован элементарный размер потокового файла, он отображает то, что передаётся на декодер для создания изображения на выходе. Исследованы элементарные потоки, размер декодируемого файла всегда составляет 1,5 Гб, вне зависимости от уровня качества, выбранного при его создании.

Основное преимущество H.265 в сравнении с H.264: экономия пропускной способности канала до 50%. При установке q=24 в преобразователе мы получаем файл размером 57% от созданного в H.264, при установке q=30 – 59%, а q=40 даёт 47%. При установке q=40 финальный файл далёк от совершенства, однако он позволяет экономить пропускную полосу более чем вдвое.

Производительность и качество изображения

H.265 требует большей производительности процессора для кодирования и декодирования в сравнении с H.264.
Функция гипер-поточности и установка параллелизации в 12/8 потока немного ускоряют процесс кодирования. Возможности тестового декодера с процессорами на базе SandyBridge-E (6 физических ядер) и Haswell (4 физических ядра, поддержка последней AVX2 и лучшим характеристикам производительности) опережают IvyBridge (4 физических ядра).
Кодирование при помощи x265 идёт дольше, чем кодирование с x264. Например, IvyBridge 3770K кодирует в H.264 файл за 129 секунд, в H.265 - за 247 секунд.

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

На изображении представлено оригинальное некомпрессированное YUV видео

На изображении представлено видео, кодированное в H.265 при показателях q=24, и видео, кодированного в H.264 при показателях q=24.

Разница между изображениями минимальна. Деревянный пол под прыгающим игроком менее размыт в H.264 варианте, однако качество H.265 варианта отличное, при том, что размер этого файла примерно вдвое меньше.

На изображении представлено видео, кодированное в H.265 и H.264 с показателем q=30.

При установке преобразователя q=30 (размеры файлов соответственно 6.39 Мб и 10.87 Мб) показатели качества потокового видео при использовании кодека H.265 оказались лучшими, чем у потока, кодированного в H.264.

Поддержка кодирования/декодирования доступна во многом оборудовании. Современные процессоры более чем готовы к декодированию H.265 при наличии соответствующего программного обеспечения. В долгосрочной перспективе H.265, скорее всего, заменит H.264 в качестве главного решения для расширенной обработки видео. Параллельная модель H.265 кодирования должна хорошо показать себя на фоне многоядерных устройств.
Внедрение нового формата для высокоэффективной обработки видео может оказать огромное влияние на рынок видеонаблюдения уже в ближайшие годы. Главное преимущество нового стандарта кодирования (H.265/HEVC) в сравнении с H.264/MPEG4 - это снижение битрейта примерно на 40%, качество получаемого изображения остается таким же.

IP-камеры с кодеком H.265 обеспечивают высококачественное изображение и снижают нагрузку сети и хранилища данных на 40%. Внедрение нового стандарта H.265 позволит увеличить количество эффективных мегапикселей у сетевых камер (10,15,20 Мп), а также снизить цифровые шумы и более четко отрабатывать функции WDR (Wide Dynamic Range).

Ассортимент оборудования Optimus активно пополняется современными моделями с кодеком сжатия H.265.

Видео 4K занимает тонну пространства, что затрудняет загрузку и потоковое вещание в лучшем качестве. К счастью, одна технология меняет это, и она известна как High Efficiency Video Coding (HEVC) или H.265 .

Потребуется много времени, чтобы эта новая технология стала вездесущей, но это происходит: 4K UHD Blu-ray использует HEVC, VLC 3.0 воспроизводить 4K с помощью надежного HEVC, а iPhone может даже сохранить записанное видео в HEVC для экономии памяти.

Но как это работает, и почему так важно для видео 4K?

Текущий стандарт: AVC/H.264

Когда вы смотрите диск Blu-ray, видео на YouTube или фильм из iTunes, все они имеют идентичный исходный файл, который был получен в студии редактирования. Чтобы разместить этот фильм на диске Blu-ray или сделать его достаточно маленьким, чтобы удобно загружать из интернета, видео должно быть сжато .

AVC также использует межкадровое сжатие , которое рассматривает несколько кадров и отмечает, какие части кадра меняются, а какие нет. Алгоритм сжатия также развивает фрейм на макроблоки и говорит: «Знаешь что? Эти куски не меняются 100 кадров подряд, поэтому давайте просто отображать их снова, вместо того, чтобы хранить все части изображения 100 раз». Это может значительно уменьшить размер файла.

Это всего лишь два упрощенных примера использования методов AVC/H.264 . Но, они позволяют сделать видеофайл более эффективным, не ставя под угрозу качество.

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

HEVC/H.265 сжимает видео более эффективно

Высокоэффективное видеокодирование, также известное как HEVC или H.265 , является следующим шагом в этой эволюции. В нем реализовано множество методов, используемых в AVC/H.264, чтобы сделать сжатие видео еще более эффективным .

Например, когда AVC просматривает несколько кадров на наличие изменений, макроблоки могут иметь несколько разных форм и размеров, максимум до 16×16 пикселей. С HEVC эти фрагменты могут быть размером до 64×64, что намного больше, чем 16×16, это означает, что алгоритм может запоминать меньшее количество фрагментов, тем самым уменьшая размер общего видео.

Опять же, в HEVC используются другие методы, но это одно из самых больших улучшений – оно позволяет HEVC сжимать видео вдвое сильнее, чем AVC, при том же уровне качества. Это особенно важно для видео 4K , которое занимает огромное пространство с AVC. HEVC делает 4K видео намного более удобным для потоковой передачи, загрузки или копирования на ваш жесткий диск.

HEVC медленнее без аппаратного декодирования

HEVC является утвержденным стандартом с 2013 года, так почему его не используют во всех видео?

Алгоритмы сжатия H.265 сложны – для вычисления этого процесса на лету требуется очень много «математики». Существует два основных способа, которыми компьютер может декодировать это видео: программное декодирование , при котором он использует процессор компьютера для выполнения этих расчетов, и аппаратное декодирование , при котором он переносит нагрузку на графическую карту (или интегрированный графический чип на процессоре). Графическая карта намного эффективнее, если у нее есть встроенная поддержка кодека видео, которое вы пытаетесь воспроизвести.

Таким образом, хотя многие ПК и программы могут пытаться воспроизвести видео HEVC, оно может «заикаться» или быть очень медленным без аппаратного декодирования. Таким образом, HEVC не принесёт много пользы, если у вас нет видеокарты и видеопроигрывателя, которые поддерживают аппаратное декодирование HEVC .

Это не проблема для автономных устройств воспроизведения. 4K проигрыватели Blu-ray, в том числе Xbox One, уже сконструированы с учетом HEVC. Но когда дело доходит до воспроизведения видео HEVC на компьютере, всё становится сложнее.

Вашему устройству потребуется одно из следующих аппаратных средств для быстрого декодирования видео HEVC:

• Intel 6-го поколения «SkyLake» или более новые процессоры
• AMD 6-го поколения «Carizzo» или более новые APU
• NVIDIA GeForce GTX 950, 960 или более новые видеокарты
• AMD Radeon R9 Fury, R9 Fury X, R9 Nano или более новые графические карты

Вам также понадобится использовать операционную систему и видеоплеер, который поддерживает не только видео HEVC, но и аппаратное декодирование HEVC, – этот момент немного «мутный». Многие приложения имеют поддержку аппаратного декодирования HEVC, но в некоторых случаях оно может работать только с некоторыми фишками из списка выше. Возможно, вам придётся включить аппаратное ускорение в вашем плеере, чтобы он работал правильно.

С течением времени большее количество компьютеров сможет обрабатывать видео такого типа, и больше плееров будут поддерживать H.265. Для этого может потребоваться некоторое время, чтобы стандарт стал повсеместным, и до этого Вам придётся хранить свои 4K видео в AVC/H.264 при больших размерах файлов (или сжимать их больше и терять качество изображения). Но чем шире будет поддерживаться больше HEVC/H.265, тем лучше будет видео.