кодирование видео видеокартой или процессором

Обработка видео на CPU и GPU. Ответы эксперта

В этом посте мы публикуем ответы эксперта Intel Дмитрия Серкина на заданные вами ранее вопросы по обработке видео на CPU и GPU. Приносим свои извинения за некоторое опоздание — оно связано с большой разницей во времени между нами и Дмитрием.
Как обычно, для удобства поиска вопросы снабжены хабра-именем автора.

Вопрос Maratyszcza

Появятся ли в процессорах Intel аппаратные блоки для других (не видео) алгоритмов сжатия, например deflate?

Не думаю. Существует оптимизация для конкретных процессоров. Intel Integrated Performance Primitives, содержит оптимизацию ZLIB, DEFLATE, и GZIP семейства функций на уровне алгоритмики и инструкций.

Какие кодеки поддерживает аппаратное сжатие CPU?

Если мы говорим только о кодировании, то H.264, MPEG-2, MJPEG, and MVC for stereoscopic 3D support. На подходе еще несколько широко известных.

Можно ли ожидать того, что QuickSync по качеству результирующей картинки сравнится с x264?

Если мы говорим о пресетах (настроек кодирования) на качество, то никогда не догонит. С каждой новой платформой качество кодирования улучшается, так как появляется больший ресурс на стороне железа и, как результат, возможность улучшить алгоритмы, например, оценки движения (motion estimation) и паковки битстрима. x264 использует очень хорошие алгоритмы (не быстрые, но влиящие на качество), в том числе RDO. Все это крайне плохо ложится на конвеерную архитектуру в железе. Если говорить про средние пресеты, то вполне бьет. Все, конечно, упирается в конечные настройки кодека, коих множество. Нужно понимать, что качество и скорость не идут рука об руку. Цель QuickSync кодировать быстро с хорошим для 99% пользователей качеством. И технология это делает. Тем временем работа по увеличению dB идет каждый день.

Сильно ли отличается по производительности HD 4000 и новая HD 5000? Можете ли привести какие-то примеры с современными играми?

Согласно недавним пресс релизам скорость возросла до 3х раз, энергопотребление уменьшилось в 2 раза. Публичных бэнчмарков по играм я не видел. Они должны появится за несколько недель до запуска Haswell в продажу. Насколько я помню, он состоится в июне. К сожалению, примеры привести не могу, так как я не в этой теме, я занимаюсь кодеками.

1. Имеются ли планы по поддержке аппаратного декодирования многобитного видео, например Hi10P из H264 или «старших» профилей HEVC?

Не имею такой информации. Планы вещь изменчивая. Если эти профили массово используются, то с очень большой вероятностью они будут поддержаны.

2. Помнится, что некоторое время назад были попытки диалогов с разработчиками свободных кодеков на предмет того, чего им хотелось бы от новых процессоров Intel. Как сейчас обстоит дела в этом направлении? Влияют ли девелоперы открытого ПО на Intel и оказывает ли Intel им какую-либо поддержку?

Скорее на уровне приложений, а не разработчиков. Недавний анонс о том, что HandBrake поддерживает QuickSync – одно из таких событий. Это вклад Intel в свободный продукт. Такие активности будут происходить все чаще и чаще, так как развитие QuickSync на Linux и его производных (Android) в самом разгаре.
Что касается того, чтобы дать прямой доступ к драйверу и железу, то о таких активностях я не слышал. Кроме того, я считаю их бесмысленными, так как работа эта довольно нетривиальная. Кроме того, существует Media SDK, он предоставляет примитивы более высокого уровня.

3. На данный момент в принципе не существует хороших реализаций кодирования на GPU (их всего несколько, и все не отличаются качеством или особым преимуществом в скорости). Почему так происходит и имеются ли какие-то положительные подвижки в этой области?

Я нахожу QuickSync очень удачным решением, которое обладает и скоростью и хорошим (относительно этой скорости) качеством. Что касается решений от AMD или Nvidia, то их провал можно объяснить отличной от Intel архитектурой. Все их решения основаны на execution units и многопоточности, которую сложно использовать в кодеках (некоторые краеугольные алгоритмы не ложатся на многопоточность). QuickSync же это комбинация EU и fixed function (алгоритмические блоки «запаянные» в железо). Такая комбинация позволяет получить отличный прирост производительности и качества.

4. Не секрет, что производительность недавно вышедших HEVC и VP9 сейчас за гранью разумного. Какова ваша оценка, как скоро появится процессор/ПО, способные обрабатывать (хотя бы декодировать) HD-видео этих форматов в реальном времени?

Я полагаю, что через пару лет такая возможность появится.

5. Насколько широко в мультимедийных продуктах Intel используется рукописный асм, или больше полагаетесь на оптимизацию компилятором? Используете ли С++, или только старый добрый С? Сколько вообще времени уходит на оптимизацию производительности в сравнении с реализацией непосредственно нового функционала?

На войне все средства хороши 🙂 Используем все выше перечисленное на уровне драйверов и ниже. Специфичный асм, конечно, генерируется из C-подобного кода для его последующей ручной оптимизации. Времени на все уходит много. Много исследований как в области качества, так и производительности, но на все есть дедлайн. Точной пропорции не скажу, но исследования, конечно, потребляют больше времени.

6. Насколько большая команда в Intel занимается мультимедийным направлением? Как сложно к вам попасть? 🙂

От железа, драйверов до различных SDK – это тысячи человек. Смотря на какую позицию вы метите 😉 В России (Москва и Нижний Новгород) есть большая команда, которая занимается Intel Media SDK. У них периодически появляются вакансии.

Тут скорее всего в драйвере. На Windows – это известная проблема некоторых ограничений на уровне ОС. Но она решаема. Более доступно и подробно я писал здесь.

Будет ли аппаратная colorspace конвертация для большинства популярных форматов? Что насчет аппаратного деинтерлейсинга?

Все это есть. Планарные и упакованные форматы. Дальше будет больше. Деинтерлейсинг также поддерживается.

Как известно, осенью прошлого года Эппл выпустили 13-дюймовый Макбук про с ретиной. В нём нет дискретной видеокарты и вся графика работает на Intel HD4000. Есть отзывы, что этой платформы просто не хватает для полноценной поддержки. Что Intel планирует, чтобы не уступать в плане графики хотя бы Айпаду с ретиной?

Я думаю, что графика развивается достаточно быстро и мощно. Intel Iris должен расставить все точки над i.

Расскажите пример кодирования видео на GPU в домашних условиях.

Самый частый пример – это кодирование для мобильных устройств. Если вы хотите за несколько минут транскодировать серию сериала в формат поддерживаемый мобильным устройством, а не ждать полчаса, то QuickSync вам в помощь.

Будут ли 64 битные драйвера для intel 3650?

Прошу прощения, но не обладаю такой информацией. Но тема горячая судя по форумам.

1. Есть ли в процессорах Intel что то похожее на KUDA?

Имеется ввиду Nvidia CUDA? Ответ — Intel OpenCL.

2. Какие необходимы библиотеки для использования графических возможностей процессора Intel, в частности: кодирования\декодирования h.264?

Все, что вам нужно – это Intel Media SDK.

3. Хватит ли производительности процессора Intel i7-3517UE для одновременного декодирования и кодирования видео разрешения 960*720 в H.264?

Да, безусловно. И даже в несколько потоков.

4. У меня проблема с процессором Intel Atom(tm) N2800. Может вы сможете мне помочь. Я декодирую с помощью ffmpeg H.264 с камеры Logitech C920, разрешение видео 960*720. После декодирования я получаю формат кадра YUYJ420. С таким разрешением я могу декодировать 2 потока по 24 кадра в секунду с вышеуказанным разрешением, но если я переворачиваю видео после декодирования на 270 градусов, то упираюсь в ограничения КЭШа (как я понимаю), и в итоге могу использовать только 20 кадров в секунду и один поток, если увеличить количество кадров, то видео разваливается на квадратики и жутко тормозит. Подскажите пожалуйста в чем может быть проблема? точно это КЭШ?

Скорее всего вы упираетесь в общую производительность системы. Все операции происходят на цетральном процессоре и с двумя потоками плюс постпроцессинг он уже не справляется. Чтобы отыграть задержки ffmpeg начинает скипать фреймы, поэтому вы наблюдаете артефакты. Какой CPU usage при этом?
Я не совсем понял какой формат на выходе. YUV420? В зависимости от формата необходим разный набор операций для поворота. Ну и кэша там мало, а он, как известно, влияет на скорость.

Меня интересует каков потенциал встроенной в процессоры Intel Core 2-го и 3-го поколения логики при аппаратном декодировании h.264? То есть сколько, например, потоков h.264 в режиме реального времени с разрешением 1280 x 720 (1920 x 1080) / 25 кадров в секунду сможет обработать процессор Intel i7-3770 с использованием именно аппаратного декодирования (если при этом программный код будет в идеале максимально оптимизирован) для последующего вывода на экран? На сколько при этом будут задействованы ресурсы других блоков процессора?

Источник

QuickSync против NVENC: сравнение кодирования на GPU

Для начала определимся с графикой, которую будем сравнивать. Рассмотрим только стабильные решения для работы в режиме 24/7 — в телевещании иначе нельзя. Со стороны Intel возьмем процессор последнего поколения Intel Xeon E-2246G (семейство Coffee Lake) со встроенной графикой Intel UHD Graphics P630. Со стороны NVIDIA выберем Quadro RTX 4000 — серверный аналог потребительской видеокарты GeForce RTX 2070 Super. В отличие от последней, она не имеет официальных ограничений в одновременной обработке больше трех потоков. Это ограничение можно снять, установив неофициальный патч, но мы все же рассмотрим только проверенные и официальные решения. Более ранние версии видеокарт мы отмели сразу: они проигрывают при работе с кодеком HEVC, так как не имеют возможности кодирования B-кадров.

Теперь подберем платформы с выбранными графическими решениями (см. таблицу 1).

Максимальное количество транскодируемых каналов

Для начала проведем нагрузочный тест на максимально возможное количество транскодируемых каналов (режим fastest) на одном сервере. В этом сравнении решение NVIDIA оказалось в два раза производительнее разработки Intel при транскодировании средствами кодека AVC и практически не уступило в кодировании средствами HEVC (см. таблицу 2).

Цена за канал с учетом затрат на сервер

Теперь мы знаем максимально возможное количество каналов разрешения Full HD (FHD, 1920×1080 точек) на один сервер со встроенной графикой Intel и видеокартой NVIDIA, а значит, сможем вычислить цену одного канала FHD.

Получается, что для AVC в цене разницы нет (см. таблицу 3). В случае c HEVC решение NVIDIA гораздо дороже по цене за канал на платформу, если рассчитывать максимальное количество каналов (то есть использовать самые быстрые алгоритмы кодирования, жертвуя качеством).

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

Качество выходного потока по сравнению с исходным

Рассмотрим качество сжатия видео, ведь нет никакого смысла в количестве каналов, если их невозможно смотреть. Ниже представлен график сравнения качества по метрике PSNR (Peak Signal-to-Noise Ratio — пиковое отношение сигнала к шуму, — прим. ред.): Intel AVC с исходным потоком (синяя линия) и NVIDIA AVC с исходным потоком (красная линия).

На графике видно, что качество получаемых потоков близко по значению PSNR.

Теперь давайте сравним с помощью метрики VMAF (Video Multimethod Assessment Fusion — субъективная мультиметодная оценка видео, разработана при участии Netflix, — прим. ред.).

В следующем графике сравним Intel HEVC с исходным потоком (синяя линия) и NVIDIA HEVC с исходным потоком (красная линия).

Из графика видно, что наше сравнение было не совсем корректным, так как максимальное количество кодируемых каналов NVIDIA равно 14, и их качество почти на 2 дБ выше, чем у 13 каналов на Intel. Поэтому мы провели дополнительные измерения, и при максимально возможном качестве на NVIDIA и на Intel в режиме GAcc (GPU Accelerated — когда кодирование происходит не только средствами графического ускорителя, но и центрального процессора) получили следующий результат. Intel HEVC GAcc с исходным потоком (синяя линия) по сравнению с NVIDIA HEVC с исходным потоком (красная линия):

Качество кодирования практически совпало, но производительность обеих систем упала в разы. Теперь NVIDIA кодировала всего четыре канала FHD HEVC, а Intel — всего 2. Пересчитаем цену одного канала исходя из новых данных: 114,2 тыс. рублей/2 = 57,1 тыс. рублей за один транскодируемый HEVC-канал на Intel; 228,5 тыс. рублей/4 = 57,1 тыс. рублей за один транскодируемый HEVC-канал на Nvidia. Таким образом, мы получили то же соотношение по цене за канал, что и в ситуации с кодеком AVC.

Энергопотребление при равной нагрузке

Рассмотрим еще один важный момент при обслуживании рабочей системы — потребляемая мощность платформы. Из наших тестов при максимальной нагрузке платформ транскодированием мы получили следующие значения: потребление платформы с NVIDIA около 200 Вт, потребление платформы с Intel около 75 Вт. Поскольку на платформе Intel каналов в два раза меньше, умножим значение на 2 — итого около 150 Вт. Получается, что при той же работе платформа NVIDIA потребляет на 50 Вт больше.

Занимаемое место в серверной стойке

При больших объемах транскодируемых каналов часто возникает вопрос размещения серверов. Для решения Intel предусмотрены специальные платформы-лезвия, где в одном сервере формфактора 3 U (юнита) умещается от 8 до 14 лезвий (полноценных серверов измененного формфактора). В одной 3U-платформе можно транскодировать до 168 каналов FHD с кодеком AVC. Если же использовать не сервер-лезвие, а обычный стоечный сервер, то на такое количество каналов понадобится высота 14 U.

Решение NVIDIA в этом плане немного сложнее: сами видеокарты занимают дополнительное место в платформе. Можно размещать по одной видеокарте в 1U-сервер, тогда занимаемое место на тоже количество каналов будет составлять 7 U. Можно на одной платформе разместить несколько видеокарт, что позволяет сэкономить на цене платформы, но выиграть место вряд ли получится: чтобы разместить 2-3 графических ускорителя, потребуется платформа 3 U, а то и 4 U.

Решение специфических задач

Помимо транскодирования видео, существуют такие задачи, как декодирование видео для визуального мониторинга и кодирование с карты захвата SDI/NDI. В таких случаях решение Intel подходит лучше: эти задачи зачастую не объемные, а значит, и использовать все ресурсы NVIDIA не получится. Даже если нужно кодировать SDI, скорее всего, это будет несколько каналов — сложно найти проект, где требуется кодировать до 24 сигналов. Кроме того, в 1U-платформу довольно сложно уместить SDI-карту захвата с интерфейсом PCI и видеокарту с той же шиной — нужно выбирать либо платформу с другой высотой, либо с достаточным местом для двух карт, что встречается довольно редко.

Есть и техническое ограничение. Процесс декодирования менее затратный, чем транскодирование, и в теории на решении NVIDIA можно визуально мониторить больше 24 каналов FHD AVC. На самом деле количество каналов ограничено 8, так как невозможно передать больший объем декодированного (несжатого) видео через шину PCI. В случае же с решением Intel такой проблемы нет, так как графика встроена в процессор.

Справедливости ради отметим, что решение NVIDIA более привлекательно для транскодирования контента сверхвысокого (UHD) разрешения, поскольку на одной видеокарте можно развернуть многопрофильное транскодирование. Встроенный графический ускоритель Intel не может транскодировать UHD-контент в несколько профилей на одном графическом ядре, и приходится включать систему распределения потока между серверами — такое решение называется распределенным транскодированием.

Для выбора важно, как реализовано использование инструментов, предлагаемых компаниями Intel и NVIDIA, какие дополнительные функции сможет выполнять программно-аппаратный комплекс

Выводы

После сравнения частного кейса можно выделить основные преимущества обоих решений. Решение Intel занимает меньше серверной высоты за счет компактности серверов-лезвий, имеет меньшее энергопотребление, оптимально подходит для декодирования и кодирования видео. Решение NVIDIA обеспечивает более высокоплотное кодирование на одно графическое ядро, позволяет сэкономить бюджет, если подобрать соответствующую видеокарту и разместить нескольких видеокарт в платформе.

Сравнив графические решения по всем интересующим нас параметрам, можно сделать вывод, что они близки по характеристикам и сложно однозначно выделить фаворита. Решающим фактором при выборе аппаратного комплекса для транскодирования может стать поставщик программного обеспечения. Для выбора важно, как реализовано использование инструментов, предлагаемых компаниями Intel и NVIDIA, какие дополнительные функции сможет выполнять программно-аппаратный комплекс (ПАК). Играют роль и такие факторы, как цена за ПАК, функции ПО, гарантия, успешные реализованные проекты, возможность доработки решения под конкретную задачу, возможность обеспечения уровня качества обслуживания, компетенции сопровождающих инженеров и т. д. Например, зачастую ПАК с NVIDIA включает в себя не программную реализацию инструментов, предоставленную этим разработчиком, а встроенный в ПО тестовый образец или же открытую реализацию. С одной стороны, это неплохо, с другой — в случае с проектом open source невозможно добавить функции или исправить выявленный баг, поскольку техническая поддержка у таких реализаций отсутствует.

Автор: Вадим Блинов, менеджер продукта CodecWorks, компания Elecard

Подпишитесь на канал «Телеcпутника» в Telegram: перейдите по инвайт-ссылке или в поисковой строке мессенджера введите @telesputnik, затем выберите канал «ТелеСпутник» и нажмите кнопку +Join внизу экрана.

Источник

Давид и Голиаф: GPU против CPU в обработке видео

Поделитесь в соцсетях:

Обработка и кодирование видео по праву считается одной из наиболее ресурсоемких задач, и потому производители CPU при выходе новых продуктов не зря постоянно делают упор на уменьшение затрат времени на подобную работу. Однако недавно появилась возможность переложить отдельные тяжелые операции с центрального процессора на GPU, вычислительная мощность которого значительно превосходит показатели любых CPU.

Благодаря принципу, положенному в основу создания современных графических процессоров (массив из очень большого числа относительно примитивных вычислительных блоков), выполнение ряда задач проходит намного быстрее – за счет параллельного запуска на исполнение десятков, а то и сотен одновременных потоков. В результате при использовании соответствующим образом написанного и адаптированного ПО GPU достигают уровней производительности, ранее доступных только в суперкомпьютерах и кластерах. Например, наиболее мощные на сегодня графические процессоры NVIDIA и ATI обеспечивают около 1 TFLOPs при одинарной точности. Естественно, было бы удивительно, если бы разработчики ПО, требующего значительных ресурсов процессора, не обратили внимания на такие возможности. Среди них не последнее место занимают и продукты для работы с видео.

Технология AMD Stream имеет значительные преимущества над NVIDIA CUDA: она основана на открытом языке Brook+, над развитием которого работают несколько университетов и крупных организаций, поддерживает новый индустриальный стандарт OpenCL, призванный объединить и заменить собой OpenGL и OpenAL. Но на данный момент, несмотря на заметно превосходящую конкурента вычислительную мощь GPU ATI RV770, программ, способных использовать их для расчетов посредством технологии AMD Stream, почти нет. Ситуация должна измениться в течение полугода, так как в ближайшее время выйдет новая версия Stream SDK и транскодер AVIVO Video Converter. Это будет бесплатный, ориентированный сугубо на домашнее применение пакет, способный быстро преобразовывать видеофайл практически любого формата в подходящий по битрейту и разрешению для воспроизведения на различных устройствах, вроде портативных проигрывателей или домашних ТВ-приставок. Кроме того, в I квартале 2009 г. обновления своих пакетов для работы с видео выпустят Cyberlink и Arcsoft, а в дальнейшем – и другие компании, специализирующиеся на соответствующем ПО.

В теории

Загрузка ядер CPU Intel Core i7 3,8 ГГц в TMPGEnc XPress 4.6 без использования CUDA и с ним

NVIDIA уже обзавелась значительным арсеналом программ для собственной реализации GP-GPU, называемой CUDA, однако подавляющее большинство продуктов – это научные, технические и медицинские пакеты для визуализации данных. Но и кодирование видео также не осталось в стороне – NVIDIA спонсирует скандинавскую Elemental Technologies, пытающуюся разработать кодек стандарта H.264, использующий GP-GPU. На сегодня Elemental уже выпустила два продукта (правда, фактически это одно и то же, но в разной «упаковке»). Первый – транскодер Badaboom Media Converter, аналогичный вышеупомянутому AVIVO. Второй – плагин RapiHD для Adobe Premiere Pro. Недостаток обоих в том, что на данный момент они поддерживают только Baseline-профиль H.264, не реализующий основное достоинство этого кодека – высокое качеством кодирования при сравнительно низком битрейте. Существующая разработка Elemental не поддерживает ни CABAC, ни CAVLC, что не позволяет использовать ее для какой-либо серьезной работы с видео, в отличие от существующих кодировщиков на базе CPU. В частности, бесплатный кодек x.264 обеспечивает значительно лучшее изображение при одинаковом размере конечного файла и со сравнимой производительностью.

Проблема при переводе кодировщиков на обработку посредством GPU состоит в том, что для высокого качества итогового видео необходимо разбивать кадр на множество макроблоков и в каждом из них проводить ряд ресурсоемких операций, таких как определение движения и энтропийное кодирование. Центральный процессор при этом просто последовательно обрабатывает все макроблоки, анализируя поток, а потом на основе полученных векторов движения сжимает кадры, обеспечивая в результате высококачественное видео. Для обработки же с помощью GPU придется либо заменить анализ кадра по блокам на покадровый (однопотоковое вычисление, нуждающееся в большом объеме кэша для хранения и анализа), либо пожертвовать углубленным анализом и итоговым соотношением битрейт/качество в угоду скорости кодирования. Именно вторым путем пока идет Elemental.

Реализовать же комплексный алгоритм кодирования с помощью GPU очень сложно. Каждому из вычислительных блоков (Stream Multiprocessors по терминологии NVIDIA) придется постоянно обмениваться данными о векторах движения с другими, а всему GPU – с центральным процессором, что в условиях высокой латентности и малых объемов кэшей в GPU может оказаться попросту неэффективным. Возможно, ситуация изменится с появлением так называемых APU – комплексных вычислительных блоков, состоящих из CPU и GPU на одном кристалле, вроде AMD Fusion, так как там будет устранена причина латентности – шина PCI Express.

Кроме того, создание ПО, оперирующего большим количеством исполняемых потоков одновременно, – задача нетривиальная даже при наличии хорошо документированного SDK, такого как NVIDIA CUDA, и поддержки со стороны его разработчика. По отзывам одного из создателей x.264, на реализацию их продукта для GPU придется затратить очень много усилий и средств, так как даже при C-подобном синтаксисе потоковая модель CUDA сложна в освоении и реализации. Фактически речь идет не о портировании существующего кода или написании для него некого транслятора, а об абсолютно новом кодировщике под принципиально иное аппаратное обеспечение, не совместимое с x86. В этом плане весьма перспективным представляется Larrabee – проектируемый Intel графический процессор, состоящий из большого числа x86-совместимых ядер. Однако если обратить внимание на довольно неспешное развитие ПО, использующего многопоточность даже на CPU, вряд ли стоит ждать какого-либо прорыва в ближайшее время.

На практике

Впрочем, работа с видео не сводится только к кодированию. Внимание акцентируется именно на сопутствующих основной обработке операциях: наложении фильтров и эффектов, монтаже и т. п. Так, первая серьезная заявка на участие GPU в этом процессе сделана в новой версии продукта Pegasys – TMPGEnc XPress 4.6. Этот программный пакет позволяет перекодировать исходный видеофайл как в подготовленный к записи образ диска VCD, DVD или Blu-ray, так и в отдельный файл с использованием большого числа кодеков и форматов. Новая версия отличается тем, что в ней реализована возможность исполнения некоторых ресурсоемких фильтров посредством CUDA (сама компрессия все же исполняется на CPU). Кроме того, декодирование файлов HD также можно перенести на графический процессор, что уменьшает суммарное время обработки при слабом CPU. Поддерживаются все видеокарты NVIDIA, начиная с GeForce 8800, необходимо лишь установить свежую версию драйверов и в настройках программы активировать CUDA.

Мы решили проверить, насколько эффективна подобная реализация, благо лицензионная версия утилиты входит в комплект поставки тестируемых видеокарт GeForce GTX 260 и GTX 280 производства MSI. Сразу отметим, что для чистоты эксперимента имитировалась довольно тяжелая нагрузка – кодирование 5-минутного отрезка HD-видео формата 1920×1080i, 29,97 fps (битрейт 16 Мб/с). Ролик преобразовывался в формат 1280×720p MPEG-4/ AVC с помощью H.264-кодека Mainconcept с профилем High, алгоритмом энтропийного кодирования CABAC посредством двухпроходной компрессии со средним битрейтом 6 Мб/с. Для оценки эффективности CUDA были активированы три фильтра: преобразование развертки в прогрессивную, устранение шумов на видео с максимальным диапазоном и адаптивная подстройка резкости. Мы намеренно использовали HD-контент, так как при преобразовании в форматы для портативных устройств с сильным снижением разрешения фильтры в принципе не нужны – на маленьком экране огрехи не заметны, а на большом при сжатии в низкое разрешение они не спасут. Для сравнения с традиционной системой, использующей для вычислений центральный процессор, мы собрали тестовый стенд на базе разогнанного до 3,8 ГГц Intel Core i7.

Обработка каждого кадра перед его сжатием занимает много процессорного времени, в итоге при выполнении всей задачи силами CPU одно ядро оказывается загруженным на 100%, а три других (или семь виртуальных, в случае Core i7 с активным Hyper-Threading) работают над непосредственным сжатием потока примерно с 30%-ной загрузкой. Разумеется, назвать это эффективным никак нельзя – скорость не поднимается выше 3–4 кадров в секунду, а весь процесс занимает почти два часа. Учитывая, что некоторые фильтры попросту не поддаются параллелизации, зачастую четырехъядерный CPU оказывается бесполезным, и можно обойтись двухъядерным: пока одно ядро обрабатывает кадр фильтром, второе успеет сжать предыдущую порцию.

Выводы

Общее впечатление от TMPGEnc XPress 4.6, первой серьезной утилиты для обработки видео, использующей NVIDIA CUDA, весьма положительное. Почти трехкратная разница в быстродействии между системой с CUDA и вариантом без нее – впечатляющее зрелище. Это свидетельствует о том, что не за горами время, когда любая видеокарта среднего класса сможет обеспечить достаточное ускорение для обработки и рендеринга видео в домашних условиях. Остается надеяться на то, что разработчики кодеков все же преодолеют трудности и реализуют качественные режимы сжатия посредством GPU, и мы получим возможность справляться за час с задачами, на которые ранее требовалось несколько часов.

Источник