intel qsv что это
Sony Vegas и Intel Quick Sync
Продолжаем тестировать использование технологии Intel Quick Sync Video в программе видеомонтажа Sony Vegas Pro, начало было положено здесь. А также сравним что изменилось в плане производительности при использовании Intel Quick Sync Video следующих версий программ: Sony Vegas Pro 12.0 Build 770 x64, Sony Vegas Pro 13.0 Build 310 и Sony Vegas Pro 13.0 Build 444.
Что такое Intel Quick Sync Video? Технология Intel Quick Sync Video, встроенная непосредственно в процессор Intel Core с технологией Intel Graphics, использует специальные возможности обработки мультимедийных данных по технологии Intel Graphics, что ускоряет и упрощает создание и преобразование видео. С ее помощью можно оперативно создавать DVD- или Blu-ray диски, редактировать видеоролики в формате 3D, преобразовывать видеофайлы из формата 2D в 3D, преобразовывать видеофайлы для портативного проигрывателя мультимедиа и загрузке в любимые социальные сети.
При широковещании или сохранении на жесткие диски, DVD-диски, видеокамеры и сотовые телефоны видео обычно сжимается и кодируется в конкретный формат. Для воспроизведения такого контента его необходимо записать на диск DVD или Blu-ray либо скопировать в телефон. Но сначала его необходимо декодировать, а затем повторно закодировать в новый формат. Этот процесс отнимает много ресурсов и времени. Intel Quick Sync Video использует специальные возможности обработки мультимедийных данных по технологии Intel Graphics для значительного ускорения декодирования и кодирования, позволяя процессору параллельно выполнять другие задачи, повышая общую производительность и быстродействие ПК.
Intel Quick Sync Video — это технология аппаратного декодирования и кодирования видеоконтента в форматах H.264/MPEG-4 AVC, VC-1 и MPEG-2, реализованное во встроенных GPU процессоров Intel. Во встроенных GPU Intel помимо исполнительных устройств общего назначения (Execution Units или просто EU), имеется специальный аппаратный модуль, Multi-Format Codec Engine (MFX), реализующий декодирование и кодирование видео.
Версия технологии Quick Sync 2.0 (которая используется в процессорах третьего поколения и выше) на 56% эффективнее предыдущей версии решения и даёт возможность получать изображение лучшего качества (поддержка кодирования видео с разрешением до 4К).
Итак, на следующей рабочей станции, работающей на операционной системе Windows 7 (без SP1), предустановлена версия программы видеомнтажа Sony Vegas Pro 12 (сборка 770) и драйвера Intel HD Graphics 9.18.10.3071.
Запускаем программу Sony Vegas Pro, создаем новый проект File > New (Ctrl+N) с характеристиками источника видео.
Далее, импортируем в проект видео DSLR 1080p25 длительностью 1 минута и 3 секунды, с большой подвижностью в кадре (ребенок энергично машет мечом и стреляет из бластера). Для этого выполняем команду: File > Import > Media. В окне Import Media выбираем видео и нажимаем на кнопку: Открыть.
Выполняем команду: Options > Preferences > Video и там выбираем в GPU acceleration of video processing из выпадающего списка пункт: Intel(R) Corporation (Intel(R) HD Graphics 4000):
Для экспорта видео, выполняем команду: File > Render As. Далее, в окне Render As вводим имя файла, выбираем директорию сохранения и в разделе Output Format выбираем пресет. Нас интересует шаблон с поддержкой технологии Intel Quick Sync Video, поэтому выбираем: Sony AVC/MVC > Internet 1920×1080-30p. Для доступа к настройкам шаблона, выделяем его и нажимаем на кнопку: Customize Template.
В закладке Video, выставляем частоту кадров как у источника и выбираем Encode mode: Intel Quick Sync Video (quality).
Переключаемся на закладку: System и там нажимаем на кнопку: Check GPU, если драйвера и железо поддерживают Intel Quick Sync Video, то получим следующий отклик: QSV is available.
Нажимаем на кнопку: ОК. Затем на кнопку: Render. Загрузка GPU доходит до 100%.
Загрузка центрального процессора (CPU) минимальна в районе 1%, при этом два потока из восьми деактивированы.
Итоговое время просчета, составило: ровно 7 минут. Размер итогового файла : 121 Мбайт.
Теперь выбираем Encode mode: Intel Quick Sync Video (speed).
Но этот режим отказался работать, просто счетчик убежал на 1 час просчета, и окно было закрыто:
Следующий режим Encode mode: Render using CPU only.
Загрузка GPU в этом режиме все равно присутствует и равна 15%.
Загрузка восьми потоков центрального процессора составила: 54% и 2,59 Гбайта оперативной памяти.
Итоговое время рендеринга только силами центрального процессора: 1 минута и 10 секунд.
Размер файла : 111 Мбайт. Читаем далее.
Перекодирование видео с Intel Quick Sync Video — сделай это по-быстрому
В русском написании аббревиатура Intel QSV выглядит как «ИКСВ», что привносит еще больше неизвестности — «икс», да еще и «в»? Поэтому (и не только поэтому) название лучше просто перевести.
Полный перевод — «Быстрая Синхронизация Видео». Что такое «видео» — вы, наверное, знаете сами. «Синхронизация» — это возможность конвертирования видео из исходных «десктопных», т.е. высокого разрешения форматов, в форматы, поддерживаемые мобильными устройствами и видеохостингами. Хотя, это далеко не единственное возможное использование QSV.
Прилагательное «быстрая» здесь отражает то, что по всем независимым тестам транскодирования видео QSV значительно, в разы, выигрывает не только у программного кодирования на CPU, но и у hi-end GPU!
Intel Quick Sync Video — это маркетинговый термин, обозначающий аппаратное декодирование и кодирование видеоконтента в форматах H.264/MPEG-4 AVC, VC-1 и MPEG-2 (пока только декодирование), реализованное во встроенных GPU процессоров Intel — от ультрабуков до серверов, начиная со второго поколения микроархитектуры Core (Sandy Bridge).
То есть, можно перекодировать видео с DVD или Blu-Ray.
Во встроенных GPU Intel помимо исполнительных устройств общего назначения (Execution Units или просто EU), имеется специальный аппаратный модуль, Multi-Format Codec Engine (MFX), реализующий декодирование и кодирование видео: 
Подобное фиксированное аппаратное решение не только ускоряет обработку видео, но и разгружает CPU, а также снижает энергопотребление системы.
При этом, декодирование целиком осуществлено в упомянутом аппаратном модуле,
а кодирование происходит в два этапа: один на исполнительных устройствах GPU, второй — аппаратно.
На приведенном слайде из презентации на Intel Developer Forum видно, какие стадии кодирования где делаются. Еще раз подчеркну, что все происходит на GPU, т.е. в железе, а «Гибридное HW/SW решение» обозначает только факт использования программируемых EU блоков GPU. 
Надо отметить, что эти две стадии кодирования хорошо конвееризуются, т.е. пока MFX аппаратно обрабатывает один кадр,
EU, закончившие свою часть работы над этим кадром, уже обрабатывают следующий, чтобы передать его аппаратной части,
что, естественно, повышает общую производительность системы.
В процессорах Ivy Bridge, то есть, во второй версии Quick Sync, аппаратные модули Sandy Bridge были доработаны — повышена скорость и качество кодирования, добавлена поддержка сверхвысоких разрешений вплоть до 4K Видео. Система даже способна декодировать несколько Quad HD video потоков одновременно.
Найти бы еще соответствующий монитор.
Тестов работы с подобным QuadHD разрешением не нашлось, зато обычных тестов, показывающих скорость работы Quick Sync больше, чем достаточно для статистики.
Например, прошлогодний опыт vilianov Счастлив с Quick Sync.
А вот относительно недавняя информация — Anandtech обозревает Intel Ivy Bridge (Core i7 3770K с HD Graphics 4000, Quick Sync второй версии) и сравнивает скорость перекодирования Blu-Ray исходника на iPad:
Измерение идет в кадрах в секунду, а производительность QSV Ivy Bridge сравнивается не только со внешними GPU, но и с Core i7 2000K (Sandy Bridge с первым поколением QuickSync — Intel HD Graphics 3000 на борту), а также Handbrake – программным решением с открытым кодом, не использующим QuickSync.
Также отметим, что преимущество QuickSync особенно заметно при перекодировании в низкие разрешения: 
При этом, анекдот «печатаю со скоростью 1000 знаков в минуту, но такая фигня получается» здесь неуместен — качество кодирования, хотя и немного уступает чисто софтовому, но всегда выигрывает, или, в худшем случае, идет вровень с любым другим GPU кодированием. Пруфлинков с обсуждением качества можно привести много (вот хороший пример на русском), отметим только что качество почти всегда оценивается субъективно, «на глаз», и, кроме того, оно существенно зависит от конкретной программы кодирования.
Доступ к аппаратной видеообработке QSV осуществляется через драйвер Intel HD graphics, интерфейс к нему непубличен, прежде всего, потому, что он непостоянен — зависим от конкретного железа и версии драйвера. Хотя, отдельные немногочисленные компании-разработчики, при необходимости, по специальному соглашению с Intel, получают доступ к заветному API.
Все остальные компании, желающие использовать преимущества Quick Sync Video, могут сделать это (и делают, конечно) с помощью специального SDK — Intel Media SDK, который предоставляет фиксированный интерфейс для работы с видео. При этом, автоматически, «за кулисами», MSDK использует все возможности аппаратного ускорения Intel для каждой данной системы: Quick Sync при его наличии, иначе – оптимизированные для конкретного CPU программные библиотеки.
В общем, штука отличная. Да еще и бесплатная.
Поэтому в списке компаний, использующих MSDK, можно найти такие известные компании, как MainConcept, Nero, Corel, CyberLink…
Но, не все приложения одинаково полезны, т.е. производительны (сами понимаете, из одних и тех же кирпичей можно построить разные дома). Вот интересное и полезное сравнение производительности от того же vilianov — «Быстрее есть куда»
Итак, если вы хотите, чтобы столь же быстро видео перекодировалось и у вас, то для этого требуется:
1. Наличие в процессоре интегрированного GPU с поддержкой Quick Sync.
Как уже было сказано, CPU должен быть не старше, чем второе поколение микроархитектуры Core (Sandy Bridge).
Кроме того, его встроенная графика должна быть также второго поколения — начиная с Intel HD Graphics 2000. Это важно, так как начальные модели Sandy Bridge, продаваемые под маркой Pentium, имеют «безномерную» Intel HD Graphics, которая не поддерживает Quick Sync.
На сегодняшний день поддержка Quick Sync для мобильных и десктопных компьютеров присутстует в Intel HD Graphics 2000, 2500, 3000 и 4000, а для серверов – в моделях P3000 и P4000.
3. Поддержка видеодрайвером.
На сегодняшний день QSV поддерживается драйверами Windows 7, Windows 8 и Mac OS Mountain Lion.
Также возможно поставить соответствующие драйвера Windows 7 на Windows Server 2008 (при установленной компоненте Desktop Experience).
Свежие драйвера для Intel HD Graphics (кстати, не только для упомянутых выше систем) можно найти здесь.
Чтобы убедиться в том, что у вас актуальный драйвер, правильно понимающий ваше железо, проверьте наличие в системе библиотеки вида libmfxhw*.dll. Если она нашлась, например, libmfxhw64-s1.dll в случае 64-битной системы с процессором Sandy Bridge, все ОК.
4. Поддержка софтом.
Актуальный список рекомендованных Intel коммерческих приложений для Windows, использующих Quick Sync посредством MSDK находится здесь.
Также существует и приложение с открытым кодом – Quick Sync Decoder, использующее Quick Sync декодирование H.264, MPEG2 и VC-1 видео через фильтр ffdshow.
В OS X Mountain Lion QSV поддерживают AirPlay Mirroring и QuickTime X.
Но, во-первых, приложений для обработки видео в природе имеется на порядок больше, чем в приведенном списке. И какие-то из них вполне могут использовать QSV, не сообщая об этом из скромности. А во-вторых, заявленная поддержка QSV и его реальное задействование вашей задачей – это две большие разницы. Во многих приложениях для активации QSV надо выставить галочку в совершенно неожиданном месте или поменять какую-то неочевидную настройку, которую, возможно, стоит поискать, если QSV почему-то не работает.
Все это приводит нас к задаче – проверить, было ли реально использовано аппаратное ускорение при обработке вашего видео.
Как все сложно … а проще нельзя? Можно. Во всех ультрабуках Quick Sync Video работает изначально по определению, а используя бесплатный Intel MSDK вы можете легко самостоятельно написать приложение, задействующее QSV по умолчанию.
Повышение производительности мультимедиа приложений с помощью аппаратного ускорения
Вычислительная архитектура: от суперскалярной до разнородной
Чтобы оценить важность развития ГП, давайте начнем с истории совершенствования архитектуры ЦП.
Вернемся в девяностые годы. Первый серьезный этап в развитии — появление суперскалярной архитектуры, в которой была достигнута высокая пропускная способность за счет параллельной обработки на уровне инструкций в пределах одного процессора.
Рисунок 1. Суперскалярная архитектура
Рисунок 2. Многоядерная архитектура
Современная разнородная архитектура
В разнородной архитектуре может быть несколько процессоров, использующих общий конвейер данных, которые можно оптимизировать для отдельных функций кодирования, декодирования, преобразования, масштабирования, применения чересстрочной развертки и т. д.
Другими словами, благодаря этой архитектуре мы получили ощутимые преимущества как в области производительности, так и в области потребления электроэнергии, недоступные ранее. На рис. 3 показано развитие ГП за пять последних поколений: графические процессоры приобретают все более важное значение. И при использовании h.264, и при переходе на самые современные кодеки h.265 графические процессоры предоставляют значительную вычислительную мощность, благодаря которой обработка видео с разрешением 4K и даже с более высоким разрешением не только становится возможной, но и выполняется достаточно быстро.
Рисунок 3. Развитие разнородной архитектуры
Поколения производительности ГП
На рис. 4 показано резкое повышение вычислительной мощности всего за несколько поколений, в которых графические процессоры конструктивно размещались на одном кристалле с ЦП. Если в вашем приложении используется обработка мультимедиа, необходимо задействовать разгрузку на ГП, чтобы добиться ускорения в 5 раз или более (в зависимости от возраста и конфигурации системы).
Рисунок 4. Усовершенствование обработки графики в каждом поколении процессоров Intel
Приступая к программированию ГП
На шаге 1 обычно измеряется производительность H.264, чтобы можно было в дальнейшем оценивать изменение производительности по мере доработки кода. FFmpeg часто используется для измерения производительности и для сравнения скорости при использовании аппаратного ускорения. FFmpeg — очень мощный, но при этом достаточно простой в использовании инструмент.
На шаге 2 проводится тестирование с разными кодеками и в разных конфигурациях. Можно включить аппаратное ускорение, просто заменив кодек (замените libx264 на h264_qsv) на использующий Intel Quick Sync Video.
На шаге 3 добавлено использование Intel Media SDK.
Примечание. В этой публикации рассматривается использование этих инструментов в операционной системе Windows*. Если вас интересует реализация для Linux*, см. Доступ к Intel Media Server Studio для кодеков Linux с помощью FFmpeg.
▍Кодирование и декодирование FFmpeg
Начните с H.264 (AVC), поскольку h264: libx264 является программной реализацией в FFmpeg по умолчанию и выдает высокое качество исключительно программными средствами. Создайте собственный тест, затем снова измерьте производительность, сменив кодек с libx264 на h264_qsv. Позднее мы поговорим о кодеках H.265.
Если вы хотите поэкспериментировать с Quick Sync Video в FFmpeg, необходимо добавить libmfx. Самый простой способ установить эту библиотеку — использовать версию libmfx, упакованную разработчиком lu_zero.
Пример кодирования с аппаратным ускорением Quick Sync Video:
Кодек h264_qsv работает очень быстро, но видно, что даже самый медленный режим работы с аппаратным ускорением значительно быстрее только программного кодирования при самом низком качестве и самой высокой скорости.
При тестировании с кодеками H.265 вам потребуется либо получить доступ к сборке с поддержкой libx265, либо собрать собственную версию согласно инструкциям в Руководстве по кодированию для FFmpeg и H.265 или в документации X265.
Пример H.265:
Использование Intel Media SDK (sample_multi_transcode)
Рисунок 5. Примеры характеристик производительности H264 по отношению к целевому использованию
Используйте другие программные средства Intel
Для дальнейшей доработки кода можно использовать средства оптимизации и профилирования Intel, в том числе Intel Graphics Performance Analyzer (GPA) и Intel VTune Amplifier. Кроме того, инструменты Intel Video Pro Analyzer и Intel Stress Bitstreams and Encoder помогут добиться высокого качества видео и поточной передачи, улучшить работу кодировщиков и декодеров, а также ускорить проверку, чтобы можно было быстрее выпускать решения на рынок.
Заключение
Компьютерная архитектура претерпела значительные изменения за последние 20 лет, причем ее развитие лишь в течение последних пяти лет дало существенный рост производительности. Теперь ЦП Intel могут обрабатывать мультимедиа непосредственно на ГП, благодаря чему становятся доступными новые модели использования как для конечных потребителей, так и для компаний.
Вы можете самостоятельно измерить повышение производительности с помощью FFmpeg, а также дополнительно оптимизировать код с помощью бесплатных интерфейсов API Intel Media SDK. Переход от программной обработки к аппаратному ускорению повышает производительность системы и снижает расход электроэнергии (и затраты), а также предоставляет дополнительные вычислительные ресурсы, достаточные, чтобы со временем перейти на семейство кодеков H.265.
Мгновенное создание, редактирование и публикация видеоматериалов
Видео в формате Ultra HD используется повсеместно, и его создание и просмотр стали очень важны. Редактируйте, конвертируйте и публикуйте видео дома и через сеть за несколько минут, а не за несколько часов. Теперь ваше видео будет ждать вас, а не наоборот.
Что такое Intel® Quick Sync Video?
Intel® Quick Sync Video 1 использует специальные возможности обработки мультимедийных данных графических технологий Intel® для ускорения декодирования и кодирования, позволяя процессору параллельно выполнять другие задачи и повышая быстродействие системы.
Принцип работы
При широковещании или сохранении на жесткие диски, DVD-диски, видеокамеры и сотовые телефоны видео обычно сжимается и кодируется в конкретный формат. Для воспроизведения такого контента его необходимо загрузить в Интернет либо скопировать на телефон. Но сначала его необходимо декодировать, а затем повторно закодировать в новый формат. Этот процесс требует большого количества ресурсов и времени. Intel® Quick Sync Video использует специальные возможности обработки мультимедийных данных графических технологий Intel® для ускорения декодирования и кодирования, позволяя процессору параллельно выполнять другие задачи и повышая быстродействие системы.
«Благодаря большей доступности камер для записи видео с разрешением 8K с более высокой (4:2:2 по сравнению с 4:2:0) цветовой субдискретизацией мы наблюдаем растущую потребность создателей контента в возможности воспроизведения такого видеоконтента высокой четкости и иного управления им. Наше сотрудничество с Intel дало нам возможность оптимизировать приложение DaVinci Resolve 17.1, которое теперь позволяет использовать разработанную Intel встроенную специализированную аппаратную технологию Quick Sync Video в новейших процессорах 11-го поколения для предоставления нашим клиентам расширенных мультимедийных возможностей без ущерба для производительности. Благодаря планомерной разработке корпорацией Intel архитектур будущего и нашему тесному партнерству мы намерены продолжать поддерживать сообщество создателей контента с помощью самых передовых, интуитивно-понятных и эффективных решения, оптимизированных для центральных процессоров Intel».
— Рохит Гупта (Rohit Gupta), директор отдела разработки программного обеспечения DaVinci в Blackmagic
Трансляция h264 видео без перекодирования и задержки
Не секрет, что при управлении летательными аппаратами часто используется передача видео с самого аппарата на землю. Обычно такую возможность предоставляют производители самих БПЛА. Однако что же делать, если дрон собран своими руками?
Перед нами и нашими швейцарскими партнёрами из компании Helvetis встала задача транслировать видео в режиме реального времени с web-камеры с маломощного embedded-устройства на дроне по WiFi на Windows-планшет. В идеале бы нам хотелось:
Этот подход оказался (почти) работающим. В качестве приложения для просмотра можно было использовать любой web-браузер. Однако мы сразу заметили, что частота кадров была ниже ожидаемой, а уровень загрузки CPU на Minnowboard был постоянно на уровне 100%. Embedded-устройство просто не справлялось с кодированием кадров в режиме реального времени. Из плюсов данного решения стоит отметить очень небольшую задержку при передаче 480p видео с частотой не более 10 кадров в секунду.
В ходе обыска была обнаружена web-камера, которая помимо несжатых YUV-кадров могла выдавать кадры в формате MJPEG. Было решено воспользоваться такой полезной функцией, чтобы уменьшить нагрузку на CPU и найти способ передать видео без перекодирования.
FFmpeg / VLC
Первым делом мы попробовали всеми любимый open-source комбайн ffmpeg, позволяющий, среди прочего, считывать видео-поток с UVC-устройства, кодировать его и передавать. После небольшого погружения в мануал были найдены ключи командной строки, которые позволяли получить и передать сжатый MJPEG видеопоток без перекодирования.
Уровень загрузки CPU был невысок. Обрадовавшись, мы с нетерпением открыли поток в плеере ffplay… К нашему разочарованию, уровень задержки видео был абсолютно неприемлемым (около 2 — 3 секунд). Попробовав все отсюда и прошерстив Интернет, мы так и не смогли добиться положительного результата и решили отказаться от ffmpeg.
После провала с ffmpeg пришла очередь медиаплеера VLC, а точнее консольной утилиты cvlc. VLC по умолчанию использует кучу всяких буферов, которые с одной стороны помогают добиться плавности изображения, но с другой дают серьезную задержку в несколько секунд. Изрядно помучавшись, мы подобрали параметры, с которыми стриминг выглядел достаточно сносно, т.е. задержка была не очень большой (около 0.5 с), не было перекодирования, и клиент показывал видео достаточно плавно (пришлось, правда, на клиенте оставить небольшой буфер в 150 мс).
Так выглядит итоговая строка для cvlc:
К сожалению, видео работало не вполне стабильно, да и задержка в 0.5 с была для нас неприемлема.
Mjpg-streamer
Наткнувшись на статью о практически нашей задаче, решили попробовать mjpg-streamer. Попробовали, понравилось! Абсолютно без изменений получилось использовать mjpg-streamer для наших нужд без существенной задержки видео на разрешении 480p.
На фоне предыдущих неудач мы довольно долго были счастливы, но потом мы захотели большего. А именно: чуть меньше забивать канал и повысить качество видео до 720p.
H264 стриминг
Чтобы уменьшить загрузку канала, мы решили поменять используемый кодек на h264 (найдя в наших запасах подходящую web-камеру). Mjpg-streamer не имел поддержки h264, так что было решено его доработать. Во время разработки мы использовали две камеры со встроенным кодеком h264, производства Logitech и ELP. Как оказалось, содержимое потока h264 у этих камер существенно различалось.
Камеры и структура потока
Поток h264 состоит из пакетов NAL (network abstraction layer) нескольких типов. Наши камеры генерировали 5 типов пакетов:
Non-IDR — пакет, содержащий кодированное изображение, содержащее ссылки на другие кадры. Декодер не в состоянии восстановить изображение по одному Non-IDR кадру без наличия других пакетов.
Помимо IDR-кадра, декодеру нужны пакеты PPS и SPS для декодирования изображения. Эти пакеты содержат метаданные об изображении и потоке кадров.
Основываясь на коде mjpg-streamer, мы воспользовались API V4L2 (video4linux2) для считывания данных от камер. Как выяснилось, один “кадр” видео содержал несколько NAL пакетов.
Именно в содержимом “кадров” обнаружилось существенное различие между камерами. Мы воспользовались библиотекой h264bitstream для парсинга потока. Существуют standalone-утилиты, позволяющие просмотреть содержимое потока.
Поток кадров камеры Logitech состоял в основном из non-IDR кадров, к тому же разделенных на несколько data partition. Раз в 30 секунд камера генерировала пакет, содержащий IDR picture, SPS и PPS. Так как декодеру нужен IDR пакет для того, чтобы начать декодировать видео, нас эта ситуация сразу не устроила. К нашему сожалению, оказалось, что нет адекватного способа установить период, с которым камера генерирует IDR пакеты. Поэтому нам пришлось отказаться от использования этой камеры.
Камера производства ELP оказалась существенно удобнее. Каждый получаемый нами кадр содержал в себе пакеты PPS и SPS. К тому же, камера генерировала IDR пакет раз в 30 кадров (период
1с). Это нас вполне устраивало и мы остановили свой выбор на этой камере.
Реализация сервера вещания на основе mjpg-streamer
За основу серверной части решено было взять вышеупомянутый mjpg-streamer. Его архитектура позволяла легко добавлять новые плагины ввода и вывода. Мы начали с добавления плагина для считывания потока h264 с устройства. В качестве плагина вывода выбрали уже имеющийся плагин http.
В V4L2 достаточно было указать что мы хотим получать кадры в формате V4L2_PIX_FMT_H264, чтобы начать получать поток h264.Так как для декодирования потока необходим IDR-кадр, мы парсили поток и ожидали IDR-кадр. Приложению-клиенту поток отправлялся по HTTP начиная с этого кадра.
На клиентской части решили воспользоваться libavformat и libavcodec из проекта ffmpeg для чтения и декодирования потока h264. В первом тестовом прототипе получение потока по сети, разбиение его на кадры и декодирование было возложено на ffmpeg, конвертирование получаемого декодированного изображения из формата NV12 в RGB и отображение было реализовано на OpenCV.
Первые тесты показали, что данный способ транслирования видео работоспособен, но имеется существенная задержка (около 1 секунды). Наше подозрение пало на протокол http, поэтому было решено использовать для передачи пакетов UDP.
Так как у нас не было необходимости поддержки существующих протоколов вроде RTP, мы реализовали свой простейший велосипед протокол, в котором внутри UDP-датаграмм передавались NAL-пакеты потока h264. После небольшой доработки принимающей части мы были приятно удивлены малой задержкой видео на настольном ПК. Однако первые же тесты на мобильном устройстве показали, что программное декодирование h264 — не конёк мобильных процессоров. Планшет просто не успевал обрабатывать кадры в режиме реального времени.
Так как процессор Atom Z3740, используемый на нашем планшете, поддерживает технологию Quick Sync Video (QSV), мы попробовали использовать QSV h264 декодер из libavcodec. К нашему удивлению, он не только не улучшил ситуацию, но и увеличил задержку до 1.5 секунд даже на мощном настольном ПК! Однако этот подход действительно существенно снизил нагрузку на CPU.
Перепробовав различные варианты конфигурации декодера в ffmpeg, было решено отказаться от libavcodec и использовать Intel Media SDK напрямую.
Первым сюрпризом для нас стал ужас, в который предлагается погрузиться человеку, решившему разрабатывать используя Media SDK. Официальный пример, предлагаемый разработчикам, представляет из себя мощный комбайн, который умеет всё, но в котором трудно разобраться. К счастью, на форумах Intel мы нашли единомышленников, также недовольных примером. Они нашли старые, но более легкоусвояемые туториалы. На основе пример simple_2_decode мы получили следующий код.
После реализации декодирования видео при помощи Media SDK мы столкнулись с аналогичной ситуацией — задержка видео составила 1.5 секунды. Отчаявшись, мы обратились к форумам и нашли советы, которые должны были снизить задержку при декодировании видео.
Декодер h264 из состава Media SDK накапливает кадры прежде чем выдавать декодированное изображение. Было обнаружено, что если в структуре данных, передаваемых в декодер (mfxBitstream), установить флаг “конец потока”, то задержка снижается до
Далее экспериментальным путем было обнаружено, что декодер держит 5 кадров в очереди, даже если установлен флаг окончания потока. В итоге нам пришлось добавить код, который симулировал “окончательное окончание потока” и заставлял декодер выдавать кадры из этой очереди:
После этого уровень задержки опустился до приемлемого, т.е. незаметного взглядом.
Выводы
Приступая к задаче трансляции видео в режиме реального времени, мы очень рассчитывали использовать существующие решения и обойтись без своих велосипедов.
Нашей главной надеждой были такие гиганты работы с видео, как FFmpeg и VLC. Несмотря на то, что вроде бы они умеют делать то, что нам надо (передавать видео без перекодирования), нам не удалось убрать получающуюся при передаче видео задержку.
Практически случайно наткнувшись на проект mjpg-streamer, мы были очарованы его простотой и четкой работой в деле трансляции видео в формате MJPG. Если вам вдруг понадобится передавать именно этот формат, то мы категорически рекомендуем его использовать. Неслучайно, что именно на его основе мы и реализовали свое решение.
В результате разработки мы получили достаточно легковесное решение для передачи видео без задержки, не требовательное к ресурсам ни передающей, ни принимающей стороны. В задаче декодирования видео нам сильно помогла библиотека Intel Media SDK, пусть и пришлось применить немного силы, чтобы заставить отдавать ее кадры без буферизации.