Сжатие видео и декодирование | Проверка качества аппаратного декодирования
С транскодированием трудно разобраться, потому что в нём участвует различное оборудование для декодирования. Хотя такие программы, как Windows Media Player 12 или PowerDVD могут использовать практически универсальные API-вызовы для DXVA (используемые для аппаратного ускорения декодирования), оборудование, реально занимающееся обработкой, устроено по-разному. Только по этой причине мы уделим особое внимание выходу после декодирования.
Есть целый ряд проблем, с которыми нам предстоит справиться. Когда вы проигрываете видео, для сравнения разных вариантов вам надо взять одинаковое количество кадров. Два последовательных кадра в одном клипе могут сильно отличаться друг от друга, поэтому вам надо быть абсолютно уверенным, что вы сравниваете один и тот же кадр на разных платформах. Используя VLC, это просто сделать, поскольку вы чётко фиксируете время и снимаете скриншоты с помощью специальной встроенной функции. Но это означает, что вы ограничены декодером VLC, который использует только часть декодирования в конвейере. Он не использует компенсации движения или преобразование частоты, даже когда вы используете аппаратное декодирование. Более того, не поддерживаются решения Intel, значит с программным декодированием будут сражаться только решения AMD и nVidia.
Поэтому нам надо найти способ использовать нечто вроде WMP12 и получать кадры из видео рендеринга. Это достаточно простое решение. WMP12, PowerDVD и другие современные видео-плейеры – все используют новый компонент MediaFoundation под названием Enhanced Video Renderer (EVR). Обычно, когда вы берёте скриншот с экрана WMP12, то ничего не получаете, поскольку он используется в режиме наложения. Если вы загрузите DirectX 11 SDK, там есть установки на панели управления, которые позволяют делать мгновенный снимок с экрана, что решает проблему тестирования аппаратного декодирования. Снятие картинки с экрана делается с помощью старой программы DirectDraw, но это происходит после её рендеринга с помощью EVR. В этот момент видео останавливается на паузу и не передаётся больше в виде потока данных. DirectDraw позволяет нам захватить изображение на экране. И то, что мы захватили, представляет собой именно то, что мы видим каждый момент на экране.
Проблему захвата конкретных сцен можно решить через незащищенное копирование сегмента workingprint на базе Blu-ray из Iron Man. Перед завершением любой кинокартины ее издатели используют этот "сырой" вариант, чтобы накладывать на него спецэффекты, анимацию, добавлять и убирать отснятые сцены, менять озвучивание. Workingprint содержит информацию о времени кадра с точностью до сотой доли секунды. Это очень важно, чтобы извлекать для нашего тестирования одни и те же кадры. Сделать это совсем не просто, вам придётся максимально повысить уровень внимания и много часов кликать мышью, взбадривая себя бесчисленными чашками кофе. Только тогда вы сможете проанализировать всё, что хотите.
Последняя тема, о которой хочется поговорить – это масштабирование. Когда вы смотрите диск Blu-ray на экране с разрешением больше или меньше 1920х1080, поток видео данных должен пройти через масштабирование, чтобы соответствовать большему разрешению. Чтобы минимизировать эффект масштабирования, мы проигрываем видео на "родном" экране 1920х1080. "Умные" декодеры не будут выполнять масштабирование для "родного" разрешения. Но не все декодеры разумны, тем не менее – именно в процессе масштабирования качество изображения может быть улучшено. Более того, декодеры различаются по способу получения данных. Некоторые предпочитают блоки 8х8, другие – иной размер. Для нас важнее всего – конечный результат. Только так можно зафиксировать реальное различие.
Сжатие видео и декодирование | Везде ли качество декодирования одинаково?
В тех местах, где задействована работа с цветами, модуль от AMD активно их меняет в процессе проигрывания. На транскодирование видео это не влияет, поскольку вы реально не проигрываете видео, то есть – не посылаете поток данных на рендеринг. В nVidia и Intel цветовой профиль определяется в приложении по умолчанию. Для AMD мы оставили возможность его корректировки, чтобы вы могли заметить разницу.
 |
 |
 |
Если забыть о насыщенности картинки, UVD 3 выглядят хуже, чем Intel Clear Video HD (CVT) и четвёртое поколение PureVideo (VPDAU4). Это особенно заметно вокруг лопастей вертолета в правой части картинки. У краев лопастей нет искажений, а фигуры рабочих на грузовике менее смазаны – это означает, что алгоритмы компенсации движения Intel и nVidia копируют движение камеры более аккуратно.
 |
 |
 |
Следующая сцена относится к концу фильма, когда один из героев – Родс – едет к месту сражения Обидая и Тони. Здесь движение очень активное, поэтому эти три кадра было труднее всего получить. Очень сложно определить, как сработали Intel и nVidia. AMD сработала не очень хорошо: видно как яркий свет порождает эффект "гало" вокруг ламп на улице. Если даже отключить возможность манипуляций с цветом, то у переднего бампера машины видна зернистость.
 |
 |
 |
Даже с возможностью манипуляции цветом в тёмных сценах мы вынуждены отметить некоторое отставание AMD. А в общем – все три компании демонстрируют гораздо более согласованные результаты. Единственное, что мы заметили, это то, что в версии nVidia машина выглядит чуть светлей, чем у Intel. У AMD всё ярче, но этого можно было ожидать.
 |
 |
 |
В сценах с хорошим освещением сложнее различить качество UVD 3 пока вы не отключите возможность манипуляций с цветом. После того, как это сделано, вы замечаете, что решения от nVidia и AMD передают изображение офицера на заднем фоне немного гранулировано. Даже после того, как управление цветом передано приложению, вы можете видеть, что некоторые манипуляции с цветом всё же присутствуют. Если пристально сравнивать изображения nVidia и Intel, то nVidia чуть светлее.
 |
 |
 |
На последних изображениях, камера медленно наплывает на Гвинет. Цветовое насыщение от AMD в этом случае имеет большое значение, поскольку сцена более живая. Правда, надо отметить, что яркость в ней настолько агрессивна, что затуманивает многие детали. nVidia представляет сцену более чётко. Вы видите больше деталей, но, в общем, в картинке можно заметить гранулярность. А вот Intel удаётся достичь оптимального сообщения между чёткостью и детализацией.
Сжатие видео и декодирование | Программное декодирование
Программное декодирование – совсем другое дело. Пока мы работаем с одними и теми же исходными данными, мы получаем одинаковый результат, независимо от того, кто производитель оборудования.
Когда вы используете аппаратный декодер, видеоданные проходят "конвейер", который использует DXVA API для аппаратно-ускоренного декодирования. Поток данных может обрабатываться по-разному в различных устройствах с использованием одного и того же декодера. Пользователи могут не знать, сколько конвейеров DVXA используется. Именно поэтому аппаратное декодирование на WMP12 и PowerDVD может создавать разные картинки, хотя в обоих случаях используется EVR и аппаратно-ускоренное декодирование.
Для программного декодирования мы используем FrameShots, чтобы обрабатывать выбранные кадры. Поскольку в этом случае используются программные декодеры, мы не можем проделать с их помощью первую часть нашего анализа. Более того: мы не можем сравнить результаты с картинками, полученными с помощью аппаратно-ускоренного декодирования WMP12. Почему? Потому что эта программа не использует EVR. Она использует Video Mixing Renderer 9 (VMR9). По этой причине мы можем сравнивать программные кодеки только друг с другом.
FrameShots использует обычный фильтр DirectShow, который производит обработку после видео-декодера, но до рендеринга. Это означает, что мы до некоторой степени устраняем рендеринг видео из параметров, влияющих на качество, этого нельзя сделать с WMP12. Различие теперь в том, что используется DS-фильтр для получения конкретных блоков видеоданных.
 |
 |
Различие в изображениях трудно заметить, но если вы посмотрите на границы объектов, например, на нос белого самолёта справа, чуть большие искажения возникают при использовании декодера ffdshow. В обоих случаях используется одна картинка, но искажения встречаются в различных её частях. Поэтому выбрать одну лучшую из двух картинок сложно. Неровная линия остаётся неровной линией.
 |
 |
И эти два изображения выглядят практически неотличимыми. Есть лишь два заметных различия. При использовании ffdshow вы можете видеть больше деталей в отражённом свете на крыше автомобиля. Очень странно, что декодер (или рендеринг) как-то смазывает верхнюю часть двоеточия в показании времени слева вверху.
 |
 |
Перейдём к изображению актрисы Гвинет Пэлтроу. Здесь тоже можно заметить различия. MainConcept показывает меньше деталей и выглядит чуть более ровно, если рассматривать изображение пиксель за пикселем. После ffdshow волосы Гвинет выглядят чуть более резко, но в общем картинка выглядит и более гранулировано. Как это ни странно, но MainConcept удалил половину двоеточия из показателя времени.
 |
 |
Посмотрим, насколько качественно изображаются взрывы. Оказывается, что при стремительном движении, картинки выглядят очень похоже. Гораздо больше различий можно заметить в более статичных сценах. Мы хотели показать скриншоты взрыва при аппаратном декодировании, но из-за высокого разрешения картинок мы не смогли выложить их на наш сервер. Поэтому они , желающие могут с ними ознакомиться самостоятельно.
В заключение, когда вы используете FrameShots, не установив ffdshow, то это будет сделано по умолчанию следующим декодером. У нас это был Н.264 декодер из нашей референсной установки MainConcept v2.0.0.1555. Эта версия декодера нам неизвестна, поэтому мы использовали её "втемную", отключив аппаратно-ускоренное декодирование в нашем сравнении качества декодера MainConcept H.264. Мы знаем, что в ffdshow недавно добавили ограниченную поддержку DXVA, но этот элемент ещё не входит в последние стабильные сборки.
На рынке есть целый ряд программных декодеров. Мы использовали только некоторые отладочные варианты ffdshow (сборка 3154) и MainConcept для сравнения; все программные декодеры различны.
После этого уместно продемонстрировать интересный график. Оказывается даже с одинаковыми программными декодерами можно получить различные результаты. Когда проигрывается незащищённое видео Н.264 в PowerDVD (сборка 10.0.2325.21), результаты для аппаратно-ускоренного декодирования показывают спад использования процессора до 5% для всех трёх графических конфигураций.
Нечто странное происходит, когда отключается аппаратно-ускоренное декодирования. Теоретически, всё должно происходить на процессоре Core i5-2500K. При работе только с программным декодированием происходит совсем иное. Снижение активности в GeForce GTX 580 приводит к снижению уровня использования процессора (не забывайте, декодирование происходит на процессоре). При использовании интегрированной графики Intel загрузка возрастает незначительно. Вероятно, это результат использования ресурсов HD Graphics, которые в другом случае были бы высвобождены для ядер процессора. А вот добавление карты Radeon HD 6970 повышает уровень загрузки процессора более значительно. Если вы посмотрите на график, то увидите всплески производительности, которые происходят в тех местах, где программный декодер работает с обработкой сцен, требующих большую производительность.
Скорее всего это была проблема в Cyberlink. Мы запросили у Corel копию WinDVD. Результаты говорят сами за себя. Независимо от того, какой GPU вы используете, загрузка CPU должно быть одинаковой при условии, что вы используете один и тот же программный декодер.
![Сжатие видео и декодирование - обсуждение в Клубе экспертов THG [ 29 отзывов]](/forum/images/icons/icon5.gif){kind=icon}
