Как декодировать видео процессором
Небольшая заметка на тему кодирования видео файлов. Как то пару месяцев назад мне потребовалось перекодировать DVD со свадьбой в рип меньшего размера, для просмотра на TV с флешки. Последний раз я занимался конвертированием DVD в DVD rip лет 9-10 назад, на пеньке 4, что занимало у меня довольно много времени (порядка 5-8 часов). В то время скорость интернета была еще далека от нужной, для скачивания рипов, поэтому особо любимые фильмы конвертировались в рип и записывались на CD… Но с тех пор много воды утекло, и столкнувшись с необходимостью быстро рипн.
Небольшая заметка на тему кодирования видео файлов. Как то пару месяцев назад мне потребовалось перекодировать DVD со свадьбой в рип меньшего размера, для просмотра на TV с флешки. Последний раз я занимался конвертированием DVD в DVD rip лет 9-10 назад, на пеньке 4, что занимало у меня довольно много времени (порядка 5-8 часов). В то время скорость интернета была еще далека от нужной, для скачивания рипов, поэтому особо любимые фильмы конвертировались в рип и записывались на CD… Но с тех пор много воды утекло, и столкнувшись с необходимостью быстро рипнуть DVD, я провел некоторое время для поиска нужной программы. Важным фактором была простота использования и готовые настройки. Немного поискав я остановился на Xilisoft DVD Ripper , с помошью которого, (перепробовав пару тройку готовых пресетов) я выполнил нужное мне преобразование. Также поискав еще немного я обнаружил еще одну программу для конвертирования видео – Xilisoft Video Converter . Важным достоинство обеих программ – поддержка ускорения видео средствами GPU (как amd так и nvidia). Не буду расписывать сами программы, а просто поделюсь небольшим тестом, который я провел ради интереса. Целью было сравнить скорость обработки видео с помощью CPU без ускорения GPU и с ускорением GPU, а также посмотреть, будет ли разница в изображении при кодировании с использованием GPU AMD и Nvidia.
Процессор: Intel Core i5-2500K, 4200 MHz
Материнская плата: Gigabyte GA-P67A-UD3P-B3
Оперативная память: Hynix 8176 МБ (DDR3-1333 DDR3 SDRAM) (4+4)
Монитор: Dell U2311H – 1920-1080
Жесткий диск: WDC WD1002FAEX-00Y9A0 ATA Device (1000 МБ, 7200 RPM, SATA-III)
Видеодрайвер: Nvidia – 320.18, ATI – 13.4
реклама
Видеокарты: HD 7950 и GTX 670.
Первая часть теста создание DVD рипа из оригинального DVD (пресет AVI), вторая создание HD рипа 720 из оригинала HD 1080 (пресет mp4 youtube 264 hd video)
Привет! Эта статья продолжение моей статьи FFmpeg начало работы Visual Studio. Здесь мы приступим к аппаратному декодированию RTSP-потока FULL HD. Заранее скажу, что с данной задачей легко справится даже Intel ATOM Z8350.
Задача: аппаратное декодирование и запись до 4-х кадров в оперативную память для последующей параллельной обработки (четырьмя ядрами процессора) с IP-камеры RTSP h.264. Обработанные кадры отображаю с помощью функций WinAPI. Как итог мы получим быстродействующую систему для компьютерной обработки RTSP-потока в параллельном режиме. Далее можно подключать алгоритмы Компьютерного зрения для обработки кадров Real Time.
Вступление
Зачем нужно аппаратное декодирование? Вы хотите слабым и дешевым процессором декодировать видео реал-тайм или хотите максимально разгрузить процессор, тогда пора знакомиться с аппаратным декодированием.
DirectX Video Acceleration (DXVA) — это API для использования аппаратного ускорения для ускорения обработки видео силами графических процессоров (GPU). DXVA 2.0 позволяет перенаправлять на GPU большее количество операций, включая захват видео и операции обработки видео.
После написания предыдущей статьи мне было задано не мало вопросов: «почему использован именно FFmpeg?» Начну с проблематики. Основная сложность аппаратного декодирования состоит в записи раскодированного кадра в ОЗУ. Для Full HD это 1920 х 1080 х 3 = 6 220 800 байт. Даже с учетом того что кадр хранится в формате NV12 – это тоже немало 1920 x 1080 x 1.5 = 3 110 400 байт. Перезаписывать 75 Мбайт в секунду серьезная задача для любого процессора. Для решения этой задачи Intel добавила команды SSE 4, которые позволяют переписывать данные без участия процессора. К сожалению, не во всех библиотеках это реализовано. Мной были опробованы следующие библиотеки:
OpenCV – для работы с потоком RTSP использует FFmpeg, поэтому решено работать без посредников, т.е. использовать библиотеку FFmpeg. К тому же FFmpeg, который установлен по умолчанию, в OpenCV собран без аппаратного декодирования.
FFmpeg – показала хорошие, на мой взгляд результаты, работает стабильно. Единственный недостаток не реализована работа с WEB-камерами для версии X86 (X64 вроде позволяет работать) в Windows.
Что умеет QSV в Skylake
В Gen9 появилась полная поддержка аппаратного ускорения при кодировании и декодировании H.265/HEVC, частичная поддержка аппаратного кодирования и декодирования свободным кодеком VP9. Произведены значительные улучшения в технологии QSV. Они повысили качество и эффективность кодирования и декодирования, а также производительность фильтров в программах для транскодирования и видеоредактирования, которые используют аппаратное ускорение.
Интегрированная графика Skylake поддерживает стандарты DirectX 12 Feature Level 12_1, OpenGL 4.4 и OpenCL 2.0. Решено полностью отказаться от мониторов VGA, зато Skylake GPU поддерживают до трёх мониторов c интерфейсами HDMI 1.4, DisplayPort 1.2 или Embedded DisplayPort (eDP) 1.3.
Аппаратное ускорение декодирования видео доступно графическому драйверу через интерфейсы Direct3D Video API (DXVA2), Direct3d11 Video API или Intel Media SDK, а также через фильтры MFT (Media Foundation Transform).
В графике Gen9 поддерживается аппаратное ускорение декодирования AVC, VC1, MPEG2, HEVC (8 бит), VP8, VP9 и JPEG.
▍Аппаратное ускорение декодирования видео
Расчётная производительность декодирования видео при аппаратном ускорении составляет более 16 одновременных потоков видео 1080p. Реальная производительность зависит от модели GPU, битрейта и тактовой частоты. Аппаратное декодирование H264 SVC не поддерживается в Skylake.
Аппаратное ускорение кодирования доступно только через интерфейсы Intel Media SDK, а также через фильтры MFT (Media Foundation Transform).
▍Аппаратное ускорение кодирования видео
Кроме аппаратного ускорения кодирования и декодирования, в графике Gen9 реализовано аппаратное ускорение обработки видео, в том числе следующих функций: деинтерлейсинг, определение каденции, масштабирование видео (Advanced Video Scaler), улучшение детализации, стабилизация изображения, сжатие охвата цветовой гаммы (gamut compression), адаптивное улучшение контраста HD, улучшение оттенков кожи, контроль цветопередачи, шумоподавление в цветовой составляющей канала (chroma de-noise), преобразование SFC (Scalar and Format Conversion), сжатие памяти, LACE (Localized Adaptive Contrast Enhancement), пространственное шумоподавление, Out-Of-Loop De-blocking (для декодера AVC) и др.
Аппаратный транскодер Gen9 поддерживает следующие специфические функции транскодирования:
- Быстрый и энергоэффективный кодер AVC в реальном времени для видеоконференций
- Сжатие памяти без потерь для медиадвижка с целью уменьшения энергопотребления
- Масштабирование видео (Advanced Video Scaler)
- Энергоэффективный конвертер SFC (Scalar and Format Conversion)
Источник: 6th Generation Intel Processor Datasheet for S-Platforms
В Gen9 реализована аппаратная поддержка обработки видео с цифровых камер (Camera Processing Pipeline), в том числе отдельные функции этой обработки: баланс белого, восстановление полноцветного изображения с массива цветных фильтров на сенсоре камеры (de-mosaic), коррекция дефективных пикселей, исправление уровня чёрного, гамма-коррекция, устранение виньетирования, конвертер цветового пространства (Front end Color Space Converter, CSC), улучшение цветопередачи (Image Enhancement Color Processing, IECP).
Skylake GPU
- HD Graphics 510 (GT1, 12 EU, 950 МГц, 182,4 Гфлопс)
- HD Graphics 515 (GT2, 24 EU, 1000 МГц, 384 Гфлопс)
- HD Graphics 520 (GT2, 24 EU, 1050 МГц, 403,2 Гфлопс)
- HD Graphics 530 (GT2, 24 EU, 1150 МГц, 441,6 Гфлопс)
- Iris Graphics 540 (GT3e, 48 EU, 64 МБ eDRAM, 1050 МГц, 806,4 Гфлопс)
- Iris Graphics 550 (GT3e, 48 EU, 64 МБ eDRAM, 1100 МГц, 844,8 Гфлопс)
- Iris Pro Graphics 580 (GT4e, 72 EU, 128 МБ eDRAM, 1000 МГц, 1152 Гфлопс)
- HD Graphics P530, сервер (GT2, 24 EU, 1150 МГц, 441,6 Гфлопс)
- Iris Pro Graphics P555, сервер (GT3e, 48 EU, 128 МБ eDRAM, 1000 МГц, 768 Гфлопс)
- Iris Pro Graphics P580, сервер (GT4e, 72 EU, 128 МБ eDRAM, 1000 МГц, 1152 Гфлопс)
Немного о формате NV12
Итак, мы получили кадр в структуру sw_frame. Полученный кадр хранится в формате NV12. Данный формат был придуман Microsoft. Он позволяет хранить информацию о пикселе в 12 бит. Где 8 бит интенсивность, а 4 битами описывается цветность (вернее цветность сразу описывается для 4-х рядом стоящих пикселей 2х2). Причем, sw_frame.data[0] – хранится интенсивность, а в sw_frame.data[1] – хранится цветность. Для перевода из NV-12 в RGB можете воспользоваться следующей функцией:
Хотя работа с NV12 позволяет ускорить выполнение таких процедур, как размывка, Retinex и получение изображения в оттенках серого (просто отбросив цветность). В моих задачах я не перевожу формат NV12 в RGB, так как это занимает дополнительное время.
И так мы научились аппаратно декодировать видеофайлы и выводить их в окно. Познакомились в форматом NV12 и как его преобразовывать в привычный RGB.
Как программы используют аппаратное ускорение
Чтобы использовать аппаратное ускорение, каждая программа должна явно реализовать поддержку специфических функций Gen9. Многие делают это. Компания Intel публикует в открытом доступе Media SDK 2.0, так что поддержку аппаратного ускорения кодирования и декодирования можно внедрить в любую программу. Кроме того, существуют готовые приложения для транскодирования лайв видео на кодеках Intel, такие как Элекард CodecWorks 990. В отличие от SDK, CodecWorks 990 не требует участия программистов для применения в реальных задачах, уже содержит наиболее популярные профили транскодирования и работать с ним инженеру-не программисту в целом гораздо проще, чем с SDK. Как работают программные транскодеры с аппаратным ускорением — мы расскажем в следующей части.
прогресс не стоит на месте. растет мощность CPU, GPU и специализированных процессоров, увеличиваются объемы магнитных и оптических дисков, дешевеют TFT панели. эти факторы и стремление к совершенству медленно, но верно приближает HD видео к простым людям.
уже сейчас обладатели 19" мониторов могут почувствовать разницу между HD и SD видео. это как раз тот случай, когда лучше один раз увидеть, чем 100 раз услышать. если у вас есть хороший монитор, то безусловно вы сможете найти хотя бы маленький отрывок видео в HD качестве, чтобы заглянуть в будущее домашнего видео.
техническая справка - основные форматы HD видео:
720p - 1280x720 при 25 кадров
1080i - 1440x1080 при 50 кадров черезстрочно (основной формат HD видеокамер)
1080i (full HD) - 1920x1.
уже сейчас обладатели 19" мониторов могут почувствовать разницу между HD и SD видео. это как раз тот случай, когда лучше один раз увидеть, чем 100 раз услышать. если у вас есть хороший монитор, то безусловно вы сможете найти хотя бы маленький отрывок видео в HD качестве, чтобы заглянуть в будущее домашнего видео.
техническая справка - основные форматы HD видео:
720p - 1280x720 при 25 кадров
1080i - 1440x1080 при 50 кадров черезстрочно (основной формат HD видеокамер)
1080i (full HD) - 1920x1080 при 50 кадров черезстрочно
1080p (full HD) - 1920x1080 при 25 кадров
характеристики впечатляют. более того, чтобы все это увидеть нужно иметь дорогой широкоформатный монитор или HD телевизор. к примеру, мой 19" монитор за 360 евро полностью готов только к 720p.
чтобы уместить 1.5 часа в таком качестве в разумный объем файла нужны эффективные кодеки. в индустрии используют либо MPEG2 с битрейтами 10-50 Мбит/c, либо MPEG4 AVC (он же MPEG4 Main Profile, он же H264) 5-25 Мбит/c. последний эффективнее MPEG2 и любого MPEG4 ASP вроде DivX, Xvid и т.п. эффективнось сжатия получается через усложнение алгоритма и соответственно значительно возросший объем вычислений, как при кодировании, так и при декодировании.
поговорим подробно о декодировании H264. обычно пишут требования вроде P4 3.6 или P4 2.8 (2 ядра). насколько все это правда? я нашел отрывок видео в качестве 720p 6 Мбит/с из научно-познавательного фильма Microcosmos ( http://rapidshare.com/files/12068082/Microcosmos_HDTV_sample.mkv 41 Мб) и попробовал воспроизвести его на своих домашних компьютерах.
PC1 - AMD A64-3000 AM2 (1800@2400MHz) + nVIDIA 7600GS (GPU 450 MHz)
PC2 - Intel Celeron-M 360 1400 MHz + Intel 855GM (встроенная UMA видеокарта)
видеокарты nVIDIA, начиная с 6xxx и ATI с X1xxx имеют аппаратное ускорение декодирования H264, т.ч. PC1 имеет приемущество
используемый софт:
кодеки:
ffdshow (21.8.2006)
CoreAVC 1.2
Cyberlink из PowerDVD 7.2 (поддержка аппаратного ускорения декодирования H264 видеокартой)
проигрыватели:
BSPlayer
Media Player Classic
PowerDVD 7.2
методика:
клип имеет длительность 53 секунды, будем с помощью task manager измерять время CPU, затраченное проигрывателем на воспроизведение клипа. далее нормируем на 53 секунды и получаем среднюю загрузку CPU.
PC1:
Player\Codec | ffdshow | CoreAVC | Cyberlink |
---|---|---|---|
BSPlayer | 34 (64%) | 25 (47%) | 15 (28%) |
MPC | 35 (66%) | 26 (49%) | 15 (28%) |
PowerDVD | 15 (28%) |
Причем BSPlayer + Cyberlink сначала дает 27 секунд, но после переключения с Overlay на VMR9 в настройках BSPlayer проблема решается.
PC2:
Player\Codec | ffdshow | CoreAVC |
---|---|---|
BSPlayer | 50 (94%) | 41 (77%) |
ffdshow работает на пределе, скорее всего на активных сценах идет пропуск кадров, а CoreAVC проигрывает нормально.
какие же будут выводы?
самый первый и главный, аппаратное ускорение со стороны видеокарты значительно снижает нагрузку на процессор. такой помощи со стороны видеокарты не было со времен появления Overlay. второй вывод, CoreAVC явно лучше ffdshow справляется с декодированием. по крайней мере пока.
любопытно, что в статье на ixbt http://www.ixbt.com/video2/video_dec.shtml автор получает, что декодирование с аппаратным ускорением видеокарты оказывается медленнее, чем чисто программный CoreAVC.
теперь займемся подсчетами. попытаемся оценить какой процессор будет достаточен для проигрывания видео. фиксируем среднюю загрузку CPU на 85%, чтобы был запас на динамичных сценах. тогда простые расчеты с использованием полученных данных показывают, что в случае CoreAVC для 720p достаточно процессора C-M (P-M) около 1300 MHz и A64 той же частоты. используя хорошо известный эмпирический коэффициент 1.4 получаем 1800 MHz для P4. т.е. видео 720p можно запустить на почти любом более-менее современном компьютере.
для 1080p и 1080i full HD нагрузка увеличится в 1.5-2 раза и тогда уже нам потребуется A64 с частотой около 2400 MHz или P4 3400, либо многоядерный процессор. очевидно, что не каждый компьютер готов к 1080p. однако, если использовать ускорение видеокарты, то достаточно будет CPU с частотой 1000 MHz для A64 или P4 1400. правда, востребованность видео такого качества будет под вопросом пока не появятся относительно дешевые 21+" мониторы, способные отображать такое разрешение. а там глядишь и апгрейд
Подпишитесь на наш канал в Яндекс.Дзен или telegram-канал @overclockers_news - это удобные способы следить за новыми материалами на сайте. С картинками, расширенными описаниями и без рекламы.
Аппаратное декодирование видео — это просто
На самом деле аппаратное декодирование с помощью библиотеки FFmpeg — не сложнее программного. Настройки проекта такие же, как и для программной реализации, блок-схема осталась без изменений.
Вывести на экран список поддерживаемых FFmpeg методов аппаратного декодирования можно
Первое, что нам нужно сделать — это сообщить FFmpeg с помощью какого аппаратного декодера Вы хотите декодировать видео. В моем случае Windows10 + Intel Atom Z8350 оставляют только DXVA2:
Вы же в качестве аппаратного декодера можете выбрать CUDA, D3D11VA, QSV или VAAPI (только Linux). Соответственно у вас должно быть данное аппаратное решение и FFmpeg должен быть собран с его поддержкой.
Получаем информацию о видеопотоке:
Данная функция переписывает декодированный файл в ОЗУ:
Dll аппаратного декодирования
Кадры FFmpeg выдает через 40 мс (при 25 кадрах в секунду). Как правило, обработка кадра Full HD занимает значительно больше времени. Для этого требуется организовать многопоточность, для максимальной загрузки всех 4-х ядер процессора. Я на практике один раз запускаю 6 потоков и больше их не снимаю, что значительно упрощает работу и увеличивает надежность работы программы. Схема работы приведена на рис. 1
рис.1 Схема построения многопоточной программы с FFmpeg
Я написал свой декодер в виде *.dll (FFmpegD.DLL) для включения в свои проекты. Это позволяет сократить код-проекта, что повышает понимание кода и включать в любые языки программирования, вплоть до Ассемблера (проверено:) ). С помощью нее мы напишем свой проигрыватель RTSP-потока с IP-камеры.
Для начала работы с DLL нужно передать указатель массив int[13], HANDLE события поступления нового кадра, HANDLE начала обработки нового пакета данных с камеры и массив char адрес камеры.
Структура массива дана в таблице 1.
Перед вызовом необходимо обнулить номера кадров 1-4.
DLL выполнит все необходимые действия по инициализации FFmpeg и будет записывать указатели и номера кадров. После установит событие «Поступление нового кадра». Нужно только обрабатывать поступающие кадры и вместо номера кадра записывать 0 (это значит кадр обработан и больше не используется).
Ниже Вы найдете пример проигрывателя с исходным кодом. За основу взят пример ShowDib3 Charles Petzold.
ИТОГ: аппаратный детектор движения FFmpeg даже на Intel Atom Z8350 декодирует h264 Full HD в реальном времени с загрузкой процессора до 20% с подключенный детектором движения.
Пример работы детектора движения на Intel ATOM Z8350. Первые 30 сек идет подсчет фона. После работает детектор движения по методу вычитания фона.
В этом посте мы публикуем ответы эксперта Intel Дмитрия Серкина на заданные вами ранее вопросы по обработке видео на CPU и GPU. Приносим свои извинения за некоторое опоздание — оно связано с большой разницей во времени между нами и Дмитрием.
Как обычно, для удобства поиска вопросы снабжены хабра-именем автора.
Вопрос Maratyszcza
Появятся ли в процессорах Intel аппаратные блоки для других (не видео) алгоритмов сжатия, например deflate?
Не думаю. Существует оптимизация для конкретных процессоров. Intel Integrated Performance Primitives, содержит оптимизацию ZLIB, DEFLATE, и GZIP семейства функций на уровне алгоритмики и инструкций.
Если мы говорим только о кодировании, то H.264, MPEG-2, MJPEG, and MVC for stereoscopic 3D support. На подходе еще несколько широко известных.
Если мы говорим о пресетах (настроек кодирования) на качество, то никогда не догонит. С каждой новой платформой качество кодирования улучшается, так как появляется больший ресурс на стороне железа и, как результат, возможность улучшить алгоритмы, например, оценки движения (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.
Самый частый пример – это кодирование для мобильных устройств. Если вы хотите за несколько минут транскодировать серию сериала в формат поддерживаемый мобильным устройством, а не ждать полчаса, то QuickSync вам в помощь.
Прошу прощения, но не обладаю такой информацией. Но тема горячая судя по форумам.
Имеется ввиду 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 с использованием именно аппаратного декодирования (если при этом программный код будет в идеале максимально оптимизирован) для последующего вывода на экран? На сколько при этом будут задействованы ресурсы других блоков процессора?
Хороший вопрос. Количество потоков физически упирается только в графическую память. До тех пор пока памяти достаточно для выделения поверхностей все должно работать. Другой вопрос производительность. Зависит от контента, который вы собираетесь декодировать. Другими — словами, в зависимости от того как стримы были закодированы – это занимает разное кол-во времени и ресурсов. Принимая во внимание все эти факторы (и многие другие) моя грубая оценка из головы составляет до 20 реал тайм сессий одновременно.
Более шести лет назад 13 сентября 2010 года на форуме IDF компания Intel представила микроархитектуру процессоров Sandy Bridge — второго поколения процессоров Intel Core. Процессор и графическое ядро объединили на одном кристалле, а само графическое ядро значительно обновилось и увеличило тактовую частоту. Именно в Sandy Bridge появилось «секретное оружие» — технология Intel Quick Sync Video (QSV) для аппаратного ускорения кодирования и декодирования видео. Маленький участок SoC специально выделили для размещения специализированных интегральных схем, которые занимаются только видео. Это был настоящий аппаратный транскодер .
Встроенная графика 9-го поколения HD Graphics 530 в процессоре Intel Core i7 6700K с 24 блоками выполнения команд (EU), организованными в три фрагмента по 8 блоков.
Удивительно, но Intel сумела обойти и AMD, и Nvidia в реализации аппаратного ускорения кодирования видео: похожие технологии AMD Video Codec Engine и Nvidia NVENC в видеокартах AMD и Nvidia появились со значительным опозданием (алгоритмы компрессии требуют серьёзной адаптации под процессоры видеокарт). Вот почему идея и разработка QSV хранились в секрете пять лет.
Сказать, что QSV была востребована — значит, ничего не сказать. Воспроизведение (декодирование) видео с аппаратной поддержкой стало гораздо меньше отнимать ресурсов у других задач в ОС, меньше нагревать CPU и потреблять меньше электроэнергии.
К тому же, в последние годы кодирование видео стало одной из самых ресурсоёмких задач на ПК. Популярность YouTube превратила миллионы человек в операторов и режиссёров. А тут ещё и повсеместное распространение смартфонов, для которых требуется транскодирование с DVD в сжатый AVC MP4/H.264. В результате, практически каждый ПК стал видеостудией. Массово распространились IPTV и потоковые видеотрансляции в интернете. Компьютер начал выполнять роль телевизора. Видео стало вездесущим и превратилось в один из самых популярных видов контента на ПК. Оно кодируется и транскодируется постоянно и везде: на разные битрейты, в зависимости от типа устройства, размера экрана и скорости интернета. В такой ситуации возможность быстрого кодирования и декодирования видео в процессорах напрашивалась сама собой. Так в Intel GPU встроили аппаратный кодер/декодер.
Современный кодек обрабатывает каждый кадр в отдельности, но также анализирует последовательность кадров на предмет повторений во времени (между кадрами) и пространстве (внутри одного кадра). Это сложная вычислительная задача. Ниже показан пример кадра из видео, который закодирован новейшим кодеком HEVC. Для конкретного участка возле уха зайца показано, как именно были закодированы различные участки кадра. Также показано положение и тип кадра в общей структуре видеопотока. Не углубляясь в детали алгоритмов видеокомпрессии, это даёт общее представление, насколько много информации требуется анализировать, чтобы эффективно кодировать и декодировать видео.
Скриншот открытого видео в программе Elecard StreamEye, 1920×1040
Аппаратная поддержка кодирования и декодирования означает, что непосредственно в процессоре реализованы интегральные схемы, специализированные для конкретных задач кодирования и декодирования. Например, дискретное косинусное преобразования (DCT) выполняется при кодировании, а обратное дискретное косинусное преобразования — при декодировании.
За прошедшие пять лет технология Intel QSV значительно продвинулась вперёд. Добавлена поддержка свободных видеокодеков VP8 и VP9, обновлены драйверы под Linux и т.д.
Технология улучшалась с каждым новым поколением Intel Core, вплоть до нынешнего 6-го поколения Skylake.
Микроархитектура GPU 9-го поколения
Последняя версия QSV 5.0 вышла вместе с микроархитектурой ядра шестого поколения Skylake. Данная версия GPU в официальной документации Intel классифицируется как Gen9, то есть графика 9-го поколения.
Процессор Intel Core i7 6700K для настольных компьютеров содержит 4 ядра CPU и встроенную графику 9-го поколения HD Graphics 530
С каждой новой микроархитектурой в GPU увеличивалось количество блоков выполнения команд (EU). Оно выросло с 6 в Sandy Bridge до 72 в топовой графике Iris Pro Graphics 580 на кристаллах Skylake. В том числе за счёт этого производительность GPU увеличилась десятикратно без увеличения тактовой частоты. Во всей графике последнего поколения Iris и Iris Pro имеется встроенный кэш Level 4 на 64 или 128 МБ.
▍Микроархитектура блоков выполнения команд (EU)
Базовым строительным блоком микроархитектуры Gen9 является блок выполнения команд (EU). Каждый EU сочетает в себе одновременную многопоточность (SMT) и тщательно настроенную чередующуюся многопоточность (IMT). Здесь работают арифметическо-логические устройства с одиночным потоком команд, множественным потоком данных (SIMD ALU). Они выстроены по конвейерам многочисленных тредов для высокоскоростного проведения вычислений с плавающей запятой и целочисленных операций.
Суть чередующейся многопоточности в EU состоит в том, чтобы гарантировать непрерывный поток готовых для выполнения инструкций, но в то же время ставить в очередь с минимальной задержкой более сложные операции, такие как размещение векторов в памяти, запросы семплеров или другие системные коммуникации.
Блок выполнения команд (EU)
В зависимости от нагрузки, аппаратные треды в EU могут выполнять параллельно один код от одного вычислительного ядра либо могут выполнять код от совершенно разных вычислительных ядер. Состояние выполнения в каждом треде, в том числе его собственные указатели инструкций, хранятся в его независимом ARF. На каждом цикле EU может выдавать до четырёх различных инструкций, которые должны быть от четырёх различных тредов. Специальный арбитр тредов (Thread Arbiter) отправляет эти инструкции в один из четырёх функциональных блоков для выполнения. Обычно арбитр может выбирать из разнородных инструкций, чтобы одновременно загружать все функциональные блоки и, таким образом, обеспечивать параллелизм на уровне инструкций.
Пара модулей FPU на схеме на самом деле выполняет и операции с плавающей запятой, и целочисленные вычисления. В Gen9 эти модули способы обработать за цикл не только до четырёх операций с 32-битными числами, но и до восьми операций с 16-битными. Операции сложения и умножения выполняются одновременно, то есть блок EU способен выполнить максимум до 16 операций с 32-битными числами за один цикл: 2 FPU по 4 операции × 2 (сложение+умножение).
Генерацией SPMD-кода для многопоточной загрузки EU занимаются соответствующие компиляторы, такие как RenderScript, OpenCL, Microsoft DirectX Compute Shader, OpenGL Compute и C++AMP. Компилятор сам эвристически выбирает режим загрузки тредов (SIMD-width): SIMD-8, SIMD-16 или SIMD-32. Так, в случае SIMD-16 на одном EU могут одновременно исполняться 112 (16×7) потоков.
Обмен данными в рамках одной инструкции внутри блока EU может составлять, например, 96 байтов на чтение и 32 байтов на запись. При масштабировании на весь GPU с учётом нескольких уровней иерархии памяти получается, что максимальный теоретический лимит обмена данными между FPU и GRF достигает нескольких терабайт в секунду.
▍Масштабируемость
Микроархитектура GPU обладает масштабируемостью на всех уровнях. Масштабируемость на уровне тредов переходит в масштабируемость на уровне блоков выполнения команд. В свою очередь, эти блоки выполнения команд объединятся в группы по восемь штук (8 EU = 1 subslice).
На каждом уровне масштабирования имеются локальные модули, работающие только здесь. Например, для каждой группы из 8 блоков EU предназначен свой локальный диспетчер тредов, порт данных и семплер для текстур.
Группа из 8 блоков EU (subslice)
В свою очередь группы из 8 EU объединяются в группы по 24 EU (3 sublices = 1 slice). Эти срезы по 24 блока, в свою очередь, тоже масштабируются: существующая графика Gen9 содержит 24, 48 или 72 EU.
В графике Gen9 увеличен объём кэша третьего уровня L3 до 768 КБ на каждую группу из 24 EU. У всех семплеров и портов данных свой собственный интерфейс доступа к L3, позволяющий считать и записать по 64 байта за цикл. Таким образом, на группу из 24 EU приходится три порта данных с полосой передачи данных к кэшу L3 192 байта за цикл. Если в кэше нет данных по запросу, то данные запрашиваются или направляется для записи в системную память, тоже по 64 байта за цикл.
Микроархитектура Gen9 из двух групп по 24 (3×8) EU
Такая масштабируемость позволяет эффективно снижать энергопотребление, отключая те модули, которые не задействованы в данный момент.
Читайте также: