- Перевод
Текущую ситуацию в области медиакодеков, можно описать буквально несколькими словами: простые решения себя исчерпали. С каждым годом материал для кодирования становится все сложнее, а требования к качеству результата – все выше. В этих условиях, когда лобовая атака уже не дает эффекта, особое значение приобретает оптимизация как кодирования, так и воспроизведения медиа под конкретные платформы с использованием их самых современных возможностей. Чего можно добиться такой оптимизацией, мы покажем на примере перспективного кодека Н.265. В качестве целевой платформы рассмотрим серверное решение Intel - процессор Xeon.
Краткое описание H.265/HEVC
Стандарт H.265/HEVC (High-Efficiency Video Coding - высокоэффективное кодирование видео) - это самый последний стандарт видеокодека, разработанный совместно Международным союзом электросвязи ITU-T и ISO/IEC. Цель этого стандарта - повысить эффективность сжатия и снизить потери данных. H.265/HEVC, по сравнению с предыдущим стандартом H.264/AVC, обладает вдвое более высокой степенью сжатия при равном субъективном качестве изображения. Технология HEVC позволяет поставщикам видео передавать высококачественные видеоматериалы с меньшей нагрузкой на сеть.Отметим основные функциональные новшества, примененные в Н.265:
- Особые возможности для произвольного доступа и сращивания цифровых потоков. В H.264/MPEG-4 AVC цифровой поток должен всегда начинаться с блока адресации IDR, а в HEVC поддерживается произвольный доступ.
- Изображение разделяется на единицы дерева кодирования (CTU), каждая из которых содержит блоки дерева кодирования (CTB) яркости и цветности. Во всех прежних стандартах кодирования видео использовался фиксированный размер массива для выборок яркости - 16×16. HEVC поддерживает блоки CTB разного размера, который выбирается в зависимости от потребностей кодировщика с точки зрения памяти и вычислительной мощности.
- Каждый блок кодирования (СВ) может быть рекурсивно разделен на блоки преобразования (ТВ). Разделение определяется остаточным квадродеревом. В отличие от прежних стандартов в HEVC один блок ТВ может охватывать несколько блоков предсказания (РВ) для перекрестных предсказываемых единиц кодирования (CU).
- Направленное предсказание с 33 различными направлениями ориентации для блоков преобразования (TB) размером от 4×4 до 32×32. Возможное направление предсказания - все 360 градусов. HEVC поддерживает различные методики кодирования предсказания интракадров.
Проблемы производительности HEVC
Существующий проект HEVC Test Model (HM) реализует только основную функциональность стандарта; фактическая производительность по-прежнему далека от необходимой в реальной среде. Два основных недостатка этого проекта:- Отсутствие параллельной схемы.
- Неэффективная настройка векторизации.
Рисунок 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™
Основную часть самых ресурсоемких функций по обработке видео и изображений составляют интенсивные вычисления блочных данных. Для их оптимизации можно использовать инструкции векторизации Intel® SIMD. В кодировщике в составе кодека Strongene, согласно данным профилирования, с помощью инструкций Intel SSE можно провести ручную векторизацию всех наиболее ресурсоемких функций, таких как кадровая интерполяция низкой сложности с компенсацией движения; целочисленное преобразование без транспозиции; преобразование Адамара; вычисление сумм абсолютных разностей (SAD)/квадратов разности (SSD) с наименьшим избыточным использованием памяти. Мы включили инструкции Intel SSE в виде интринсик-функций, как показано на рис. 5.
Рисунок 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
| Циклы ЦП | Исходный код | 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.
20.11.2013
За прошедшие четыре года доминирующим видеокодеком в отрасли безопасности стал Н.264, но в последнее время ряд производителей и экспертов принялись весьма интенсивно «продавливать» Н.265. В связи с приходом нового кодека возникает ряд вопросов. Прежде всего общественность интересуется двумя: когда HEVC станет общеупотребительным и надолго ли всё это. Однако редакцию интересуют чуть более глубоко зарытые вещи: например, кто получит основные выгоды от перехода на новый стандарт кодирования, и не является ли это очередным маркетинговым трюком, позволяющим сдвинуть рыночный баланс в сторону определённых игроков. Несомненно, с технической стороны новый формат отличается от своих предшественников. Просто хотелось бы убедиться в том, что все резервы «старого» Н.264 уже исчерпаны. Ведь смена формата — это, по сути, революция. Для успеха которой, как говорил дедушка Ленин, необходимо, чтобы «низы не хотели, а верхи не могли».
Заявляемые ключевые маркетинговые отличия — или, говоря простым языком, «фишка» кодека, называемого одновременно HEVC и H.265, состоят в том, что при том же самом качестве изображения видеопоток H.265 имеет вдвое меньший битрейт, чем поток, сжатый кодеком H.264. К примеру, если для передачи сжатого кодеком Н.264 видеопотока разрешением 1080p с частотой кадров 30 кадров в секунду битрейт составляет примерно 4 мегабита в секунду, то у изображения эквивалентного качества, сжатого новым кодеком Н.265, битрейт упадёт до 2 мегабит в секунду. Выглядит привлекательно, однако, как всегда, возникает вопрос о цене этого перехода.
Стоит ли овчинка выделки — решать, к сожалению, не нам с вами. Позиция редакции Security News известна. Мы выступаем за создание специализированного кодека, который учитывал бы все особенности и специфические требования, накладываемые на передачу видеоданных в системах безопасности. Удивительно, но, несмотря на «мультимедийное» происхождение кодека Н.265, кое-что из «наших» потребностей здесь оказалось учтено (об этом читайте ниже). Последнее слово, как водится в серьёзных отраслях, всегда — за крупными производителями оборудования и систем. А «киты» индустрии безопасности вовсе не торопятся прибавлять единичку к имени кодека: с одной стороны, не так высока маневренность производственных мощностей, а с другой — слишком много средств в последние годы было инвестировано в раскрутку Н.264. Не пропадать же добру...
Технические отличия Н.265
Более высокая производительность нового кодека по сравнению с предшественниками обусловлена несколькими значительными структурными улучшениями. Определяющими из них являются три — изменение максимального размера блока, введение параллельного декодирования и реализация произвольного доступа к изображениям внутри видеопотока.
Максимальный размер блока в стандарте H.264 составляет 256 пикселов (16 x16), а в стандарте H.265 он может быть в 16 раз больше (4096 = 64 x 64). Интересно, что в стандарте Н.265 размер блока выбирается самим алгоритмом в процессе кодирования в зависимости от содержания кодируемого изображения. По утверждениям сторонников нового стандарта, изменяемый размер блоков и увеличение максимального предела этого размера позволят более эффективно обрабатывать изображения с высоким разрешением. Кстати, новый стандарт поддерживает пиксельные разрешения вплоть до 8192 х 4320 (35 мегапикселов) — самого высокого из современных телевизионных стандартов, также называемого 8К.
Возможность параллельного декодирования, предусмотренная в декодерах H.265, позволяет раздельно и одновременно обрабатывать различные части одного и того же кадра. Такая обработка может существенно ускорить воспроизведение и предоставляет возможность воспользоваться преимуществами многоядерных процессоров, завоевавших сегодня большую популярность на IT-ориентированных рынках. Кодек H.264 таких возможностей не предусматривал.
В новом стандарте предусмотрен произвольный доступ к изображениям (Clean Random Access). Это означает, что декодирование произвольно выбранного кадра видеопоследовательности производится без необходимости декодирования каких-либо предшествующих ему в потоке изображений. Для мультимедиа произвольный доступ не является критичным, а вот для видеонаблюдения, в особенности мониторинга в реальном времени, такая возможность весьма желательна: переключившись на определённый видеопоток из соображений оперативной необходимости, оператор должен мгновенно получить изображение на своём экране: в охранных приложениях одна-две секунды могут иметь решающее значение. Опустив сложные технические подробности того, как это реализовано в новом кодеке, стоит упомянуть, что здесь не требуется обязательная вставка в видеопоток промежуточных опорных кадров (I-frames), за счёт которых заметно увеличивается битрейт.
С точки зрения технических характеристик кодируемого видеосигнала, его «верхний» профиль Main 10 обеспечивает более высокое качество цветопередачи, поскольку предусматривает 10-битное цветовое кодирование, в то время как все существующие стандарты, включая «нижний» профиль Main 8 самого H.265, отводят на цветовой атрибут пиксела всего 8 бит.
В стандарте предусмотрены средства автоматического определения типа развёртки, однако, в отличие от предшественников, кодек изначально ориентирован на обработку видеоизображений, полученных путём прогрессивного сканирования. Но это не означает, что H.265 неспособен работать с чересстрочной развёрткой — разработчики учли тот факт, что достаточно большое количество находящихся в эксплуатации систем генерируют кадры из двух полей.
А вот чего существенно не хватает кодеку H.265: масштабируемого кодирования. Его планировалось реализовать ещё в H.264, однако по каким-то причинам сделать этого не удалось ни в одном из этих стандартов. Наличие масштабирования позволило бы без лишних затрат вычислительной мощности на дополнительную обработку передавать изображения клиентам, использующим относительно медленные подключения к сети. В какой-то степени масштабирование способствует и более рациональному использованию средств хранения видеоданных в системах. В настоящее время масштабируемое кодирование стоит в ряду плановых расширений стандарта. По мнению экспертов, требование масштабируемости во многом продиктовано начинающимся бумом облачных технологий хранения и обработки данных.
Общие сведения о стандарте HEVC (H.265)Стандарт HEVC (High Efficiency Video Coding, «высокоэффективное кодирование видеосигнала») определяет формат сжатия видеоизображений, предназначенный для замены ранее принятого стандарта H.264/MPEG-4 AVC (Advanced Video Coding, «продвинутое кодирование видеосигнала»), совместно разработанного экспертной группой по видеоизображениям Moving Picture Experts Group (MPEG) Международной организации по стандартизации ISO и экспертной группой по кодированию видеосигнала Video Coding Experts Group (VCEG) Международного союза по телекоммуникациям. Первая группа разработчиков дала стандарту внутреннее название ISO/IEC 23008-2 MPEG-H, часть 2, а вторая — H.265. Утверждается, что стандарт HEVC позволяет вдвое увеличить степень сжатия цифровых видеоданных по сравнению со своим предшественником либо существенно повысить качество изображения при сохранении показателя плотности потока данных. Новый алгоритм сжатия поддерживает стандарт сверхвысокой чёткости 8K и пиксельные разрешения изображений до 8192 х 4320. Областями применения стандарта являются вещательное телевидение, мультимедиа, промышленное ТВ и видеонаблюдение. Дата официальной публикации первой версии стандарта — 13 апреля 2013 года. Ряд позиций, предполагавшихся к внедрению в стандарте, на момент его выпуска остался нереализованными, и в настоящее время объединённая команда экспертов работает над дальнейшими расширениями стандарта, самыми важными из которых являются масштабируемое кодирование и трёхмерное видео. |
Что способствует повышению качества изображения
Большое количество производителей IT-продукции преподносят формат сжатия H.265 как средство повышения качества изображений. Следует отметить, что это в определённой мере является лукавством. В реальности у изображений, сжатых кодером H.265, качество ничуть не выше, чем у обработанных алгоритмом H.264, который, в свою очередь, с точки зрения качества ничуть не лучше, чем MPEG-4. Поскольку во всех упомянутых кодеках предусмотрена возможность произвольно устанавливать степень сжатия, качество сжатой картинки зависит лишь от предпочтений пользователя. Другое дело — вписать видеоизображение в реалии технического окружения. Прежде всего это касается ресурсов пропускной способности сетей.
Если пропускная способность вашей сети передачи данных достаточна для передачи изображений, сжатых по стандарту H.264, то переход на компрессию H.265 не повлечёт за собой каких-либо улучшений в качестве изображения. Такой переход может лишь снизить битрейт, то есть несколько разгрузить вашу сеть. Единственный случай, когда переход на новый кодек будет способствовать повышению качества изображений — если из соображений экономии битрейта изображения сжимались кодеком Н.264 заведомо чрезмерно, и артефакты компрессии мешали эффективному считыванию деталей операторами и видеоаналитикой.
Сомнения и ограничения
Как и большинство современных видеокодеков, Н.265 максимально эффективен (то есть способен подтвердить маркетинговые ожидания) в относительно несложных сценах наблюдения, где отсутствуют резкие перепады контрастности и не наблюдается интенсивных перемещений объектов и фона. Обещанная экономия битрейта/объёма средств хранения в 50% прежде всего касается именно таких сцен. То есть в реальных условиях — на оживлённом перекрёстке или в торговом зале супермаркета — цифры экономии окажутся существенно меньшими.
Кроме этого, на сегодняшний день толком не востребованы все «экономические» преимущества кодека-предшественника. Большинство производителей оборудования и систем, в частности, так и не осуществили переход на более продвинутые варианты профилей H.264. В видеонаблюдении чаще всего используются три профиля этого стандарта. Базовый профиль (Baseline) — это минимальная экономия полосы пропускания и минимальная нагрузка на вычислительные ресурсы. В последние несколько лет он приобрёл наибольшую популярность у вендоров. Главный профиль (Main) обеспечивает, согласно результатам независимых тестов, 10-30% улучшение показателей по сравнению с базовым. В последние несколько месяцев производители проявляют всё больший интерес именно к этому профилю. Высокий профиль (High) предоставляет ещё более существенные преимущества, однако на сегодняшний день вендоров, которые обеспечили совместимость с этим профилем, можно буквально пересчитать по пальцам.
Иными словами, производителям и без нового кодека есть куда развиваться, при этом не испытывая лишних рисков и двигаясь по относительно накатанному пути. Поскольку отрасль с переходом на IP-видео всё в большей степени становится «айтишной», здесь начинают работать соображения, свойственные сисадминам: то, что нормально работает, лучше не менять и вообще не трогать.
В данный момент идет активная разработка энкодера, но он все ещё находится в состоянии «бета»-версии. Работает медленно и не очень эффективно. Релизы новых версий выходят очень часто.
Что требуется?
Выберите один из методов:
- Скачайте исходники из официального репозитория и скомпилируйте энкодер x265.exe под свою систему.
- Скачайте одну из последних сборок x265.exe с нашего сайта.
- Используйте программу кодирования с графической оболочкой (см. конец страницы).
Использование энкодера 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
В данной статье мы попытаемся понять, отвечает ли видеокодек нового поколения возлагаемым на него надеждам?
Видеокодек нового поколения High Efficiency Video codec (HEVC), известный также как H.265, стал важной вехой видеоиндустрии 2013 года. В течение последних 12 месяцев было много сказано о H.265 и новых технологиях кодирования видео, однако сегодня впервые можно просто сесть и внимательно изучить этот самый кодер нового поколения (хоть и существующий лишь в версии, предшествующей альфа-тестированию), а также протестировать его качества в плане работы с видео. Мы рассмотрим в едином ключе качество отображения видео и размеры сжатия потока нового кодека, сравнив его с предыдущим — H.264, а также изучим производительность в Sandy Bridge-E, Ivy Bridge и Haswell.
Преимущества H.265
Кодек H.264 был вполне успешным проектом. Это весьма гибкий кодек, который получил широкое применение в сетях распространения потокового видео, на спутниковых платформах, а также при записи Blu-ray дисков. Он весьма хорош для масштабирования, благодаря чему он был предложен в качестве стандарта для 3D с частотой кадров 48-60 в секунду, и даже для 4К. И он вполне справляется с этими задачами. Стандарт, принятый для Blu-ray дисков, пока не включает в себя каких-либо рекомендаций относительно данных технологий, однако кодек H.264 сам по себе способен их поддерживать.
Проблема кодека H.264 заключается в том, что будучи в принципе способным кодировать видео в этих форматах, он не может обеспечить степень сжатия, которая бы сделала размеры получаемых файлов приемлемыми. Потребовался новый стандарт, который бы смог существенно уменьшить размеры получаемых после сжатия файлов и тем самым заслужил бы международное признание в качестве средства продвижения новых форматов видео. Так и появился на свет H.265. Он был разработан таким образом, чтобы используя новые технологии сжатия и более умную модель кодирования/декодирования, наиболее экономно использовать пропускные ресурсы канала.
В отличие от H.264, который хоть и может быть использован для поддержки 4К-телевидения, всё же он не создавался для этого формата, а H.265 разрабатывался с учётом всех особенностей 4К, включая поддержку 10-битового видео и высокой частоты кадров. Это только начало, и нынешняя, зародышевая версия кодека имеет некоторые ограничения. Она поддерживает 8-битовый цвет и даёт цветовую модель YUV, однако и данную тестовую версию много кому хотелось бы увидеть в работе. Поэтому группа исследователей, вооружившись только скомпилированным энкодером и несколькими тестовыми клипами, решила проверить – на что же способен новый кодек?
Первое, что их интересовало – это размеры файлов. Исследователи решили сравнить размеры элементарных видеопотоков. При этом следует учесть, что речь шла исключительно о видео – звук не кодировался ни в одном из случаев.
Размеры кодирования определялись настройками квантователя, где более низкие 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.264, H.265 требует большего количества «лошадиных сил» для кодирования и декодирования. Впрочем, разработчики обещают усилить роль параллельных вычислений при кодировании и декодировании, чтобы ускорить эти процессы. Подразумевается, что поддержка OpenCL станет реальной рано или поздно, а это значит, что предложения вроде HAS от AMD могут получить дополнительные очки от поддержки x265 в этом году.
В настоящее время исследователи были ограничены в выборе процессора, однако представитель MultiCoreWare Том Воган уверил их, что команда разработчиков активно работает над многопоточностью. Группа исследователей решила испытать возможности тестового декодера, используя Sandy Bridge-E, Ivy Bridge и Haswell. Исследователи экспериментировали с несколькими различными уровнями параллелизации, однако в итоге решили остановиться на числе физических ядер в системе (6, 4 и 4). Была задействована функция гипер-поточности, но установка параллелизации в 12/8 потока лишь не намного ускорила процесс кодирования.
Параллелизация показала неплохие результаты производительности. Sandy Bridge-E с его шестью ядрами опережает четырёхядерный Ivy Bridge. Ivy Bridge также уступает модели Haswell благодаря поддержке последней AVX2 и лучшим характеристикам производительности. Если сравнивать время кодирования с x264, даже при самых медленных установках, кодирование при помощи x265 идёт намного больше. К примеру, файл, который Ivy Bridge 3770K кодировал в H.264 за 129 секунд, в H.265 кодировался на протяжении 247 секунд. Впрочем, не забывайте о том, что речь идёт о самой-самой первой тестовой версии.
Не менее интересным для исследователей был и вопрос качества. Насколько качество видеофайла, кодированного в H.265, будет отличаться от исходного некомпрессированного видео? Для изучения вопросов, связанных с качеством, исследователи решили выбрать фрагмент баскетбольного матча. Файл, записанный с частотой 50 кадров в секунду, был полон моментов, демонстрирующих быстрые движения, которые очень часто приводят к зависаниям процессоров или «дёрганию» картинки. Согласитесь, если эта «болезнь» будет также свойственна H.265, то его возможность создавать относительно небольшие видео-файлы будет нивелирована плохим качеством.
Elmedia Player для Мак поддерживает h.264 и h.265 кодеки.
Итак, вашему вниманию представлены скриншоты оригинального некомпрессированного YUV видео, а также видео, кодированного в H.265 при показателях q=24, и видео, кодированного в H.264 при показателях q=24.
Как мы видим, разница здесь минимальна. Деревянный пол под прыгающим игроком немного менее размыт в H.264 варианте, однако качество H.265 варианта – феноменально, при том, что размер этого файла примерно вдвое меньше. А как на счёт установок с меньшим качеством? Вот скриншоты видео, кодированного в H.265 и H.264 с показателем q=30. Первым идёт скриншот видео, сжатого в H.265.
При установке квантователя q=30 (размеры файлов соответственно 6.39 Мб и 10.87 Мб) показатели качества потокового видео при использовании кодека H.265 оказались лучшими, чем у потока, кодированного в H.264. Разумеется, группа исследователей, проводившая данные опыты, не собирается возводить полученные результаты в абсолют – как всегда, большое значение имеют параметры кодирования, которые требуют настройки. Однако после более года ожидания, «джинн» по имени H.265, наконец, вышел из бутылки, и уже очевидно, что новый стандарт компрессии сможет оправдать возложенные на него ожидания.
Тем временем поддержка кодирования/декодирования уже очень скоро будет доступна во многих изделиях. Современные процессоры более чем готовы к декодированию H.265 при наличии соответствующего программного обеспечения. Поддержка OpenCL ожидается в ближайших итерациях. А аппаратная поддержка от производителей графических процессоров – таких, как AMD, Intel и Nvidia – дело ближайшего будущего. Возможно, она и не появится в ближайших моделях, которые вот-вот выйдут на рынок, но определённо появится в недалёком будущем. Эти три компании уже включили в свои изделия поддержку дополнительных источников видеоинформации, как отмечается в презентации H.265, поскольку видео становится обычным явлением в любых устройствах.
В долгосрочной перспективе H.265, скорее всего, заменит H.264 в качестве главного решения для расширенной обработки видео. Впрочем, всё будет зависеть ещё и от того, насколько сильнее будет разряжать батареи процесс обработки H.265 видео по сравнению с H.264. Мы сможем об этом узнать только тогда, когда появится полноценное «железо» для работы с этим стандартом, однако пока предположения весьма оптимистичны. Параллельная модель H.265 кодирования, несомненно, должна хорошо показать себя на фоне многоядерных устройств будущего.
Удивительно, но факт - стандарту сжатия видео 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 выглядит поприличнее.
