company_banner

Кодирование видео с использованием встроенного видео Intel HD


    В этом посте речь пойдет о вопросах кодирования видео «в промышленных масштабах» с применением видеокодека h264 на GPU, интегрированном в современные процессоры Intel и о том опыте, который приобрела наша компания Inventos в процессе создания и оптимизации медиа сервера для обработки потокового видео.

    Введение

    Итак, была поставлена задача разработать медиа сервер, представляющий собой эдакий «комбайн» на все случаи жизни и умеющий следующее:
    • Кодирование/рессемплинг аудио/видео почти во все известные форматы, среди которых HLS, HDS, RTMP, mp4, etc;
    • Поддержка съема сигнала с SDI, DVB;
    • Балансировка и масштабирование серверов раздачи и кодирования;
    • Описание конфигурации кодировщика на встроенном языке;
    • Различные модули для нормализации звука, усиления, деинтерлейсинга видео и т.д.


    Этот продукт под кодовым названием «streambuilder» является бэкендом медиа платформы Webcaster.pro. Решение написано на C++ с использованием библиотек libavcodec, в которые имплементированы многие известные кодеки, такие как h264, mpeg4 и т.д. Такое решение позволяет достаточно быстро разворачивать инфраструктуру доставки контента любой сложности и является гибким в плане конфигурирования.

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



    Несмотря на то, что код библиотек libavcodec хорошо оптимизирован, он рассчитан на работу на CPU, содержащим конечное число исполнительных устройств, таком, как x86 based. Увеличение количества ядер только отчасти решает проблему, так как обходится это недешево, да и ядра всегда есть чем загрузить, помимо кодирования видео. И логичным шагом была попытка использовать возможности графических ускорителей для решения данной задачи.

    Теперь немного о самом кодировании видео. Как известно, в основе сжатия видео лежат множество алгоритмов из разных разделов математики. Это фурье — анализ, вейвлеты, операции с матрицами, векторами, вероятностные алгоритмы и т. д. Объединяет их одно — все они так или иначе работают с видео данными, которые представляют собой не что иное, как векторы и матрицы. Мы не будет углубляться в особенности сжатия конкретными видеокодеками, но следует понимать, что такие задачи крайне затратны по ресурсам в плане памяти и особенно процессорного времени. Тем более, если речь идет о промышленных масштабах кодирования. До недавнего времени процесс кодирования осуществлялся на центральных процессорах. CPU характеризуются прежде всего ограниченным числом исполнительных блоков. И даже, несмотря на то, что в современных процессорах появилось много ядер, число исполнительных блоков остается конечным. Конечно, производители процессоров добавляют элементы суперскалярной архитектуры в свои чипы (например, наборы инструкций SSExxx/AVX от Intel). Они позволяют одной инструкцией обработать несколько однотипных чисел, но всегда существуют такие задачи, как сжатие видео, когда ресурсов все равно не бывает много, особенно в свете появления новых стандартов вещания (HD, 4k, и т. д.). GPU, в свою очередь, обладают большим количеством исполнительных блоков, которые, впрочем, умеют исполнять ограниченное число инструкций. Соответственно, GPU идеально подходят для обработки однотипных данных, с использованием параллельных алгоритмов. Кроме этого, многие производители GPU добавляют в свои видео ускорители дополнительные команды для ускорения обработки мультимедиа данных.

    Решение от Intel

    В качестве эксперимента мы решили попробовать ускорить кодирование видео при помощи графических сопроцессоров Intel HD Graphics, встроенных в современные процессоры Intel. Intel любезно предоставляет свой Media SDK для кодирования, декодирования, ресемплинга и других алгоритмов видео обработки. Данный SDK, к нашей большой радости, теперь доступен и для Linux, что крайне важно для промышленного использования. Именно благодаря появлению поддержки Linux мы заинтересовались этим решением. Коллег из Intel тоже заинтересовали результаты практического использования данного SDK в условиях промышленного использования. При этом, должен отметить, на протяжении всего периода разработки сотрудники Intel нам очень сильно помогали, отвечали на вопросы (которых было много поначалу) и давали действительно ценные советы.

    В комплекте вместе с Media SDK идет хорошая документация и примеры почти на все случаи жизни. Процесс интеграции Intel Media SDK сильно упростило наличие примеров, без них он, надо сказать, покажется не самым тривиальным. Суть интеграции заключалась в замены наиболее требовательных к аппаратной части софтверных модулей кодирования/декодирования/ресемплинга на соответствующие модули, использующие аппаратные возможности Intel HD Graphics.

    Тесты

    Конфигурация нашего тестового стенда: Процессор i7-3770 3.4 GHz, память 3 Гб. Версия Intel Media SDK for Linux Servers — 16.1.0.10043. В качестве источника брались разные медиафайлы и результат усреднялся.

    Кодирование RAW видео в h264
    ffmpeg intel media sdk
    720x608, h264 RAW, 30 сек, 3000 кб/с 1.2 сек 0.24 сек

    Пример транскодирования с демуксером/муксером ffmpeg (аудио пакеты писались без транскодирования)
    ffmpeg intel media sdk
    720x608, aac+h264, 30 сек, 3000 кб/с 1.6 сек 0.32 сек

    streambuilder
    simple streambuilder with intel media sdk
    1920x800 + resize 1280x720, 3000 кб/с h264, aac, 12 минут 5.4 мин 2.3 мин

    А теперь посмотрим на результаты. Для начала мы собрали примеры, которые шли в комплекте. В кодировании RAW видео в h264 тестовая программа обогнала ffmpeg h264 encoder при схожих параметрах в 4-5 раз, при этом надо сделать поправку на время, затраченное на операции дисковых записи/чтения (то есть реальный результат немного выше). Fmpeg при этом на 100% нагружал все ядра CPU. Video decoder и аппаратное изменение размеров изображения показали сходные результаты. Мы также собрали пример транскодирования с демуксером/муксером ffmpeg. Этот пример использует особый тип памяти для работы с фреймами и в нем фреймы передаются от декодера на энкодер минуя стадию копирования данных из памяти SDK в YUV формат в системной памяти. Соответственно, здесь Intel Media SDK показал производительность в среднем в 5 раза выше, чем аналогичное транскодирование при помощи ffmpeg.

    Наш медиаконвеер совместно с аппаратными модулями кодирования показал увеличение производительности в 2-3 раза. И это ожидаемый результат, так как большая часть производительности терялась на операциях копирования памяти. Gprof показал, что 80% процессорного времени уходило на работу с памятью, что вызывало задержки при подачи фреймов на аппаратный энкодер/декодер. Однако, эту проблемы мы планируем закрыть в ближайшее время, используя напрямую структуры памяти Intel SDK при обмене пакетами между разными модулями. Мы ожидаем здесь значительного увеличения производительности.

    Итак, в качестве плюсов решения от Intel можно выделить следующее.
    • Аппаратный энкодер (для h264) более адекватно воспринял параметры кодирования, нежели софтварный (libavcodec). Например, более точно выдерживался битрейт при кодировании. Для ffmpeg API его необходимо долго и мучительно подбирать;
    • При кодировании почти не используется процессор. В наших тестах CPU использовался для транскодирования аудио потока и операций с памятью внутри конвейера. Общая загрузка была на уровне 25% (загружено было примерно одно ядро из 4-х).

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

    Что дальше

    В качестве итога могу отметить, что всю инфраструктуру продукта можно перевести на новый API примерно за 1 человеко-месяц (без учета тестирования). Кроме этого, мы использовали старый API. В новой версии SDK появилось много новых плюшек, таких как аналог двухпроходного кодирования на 100 фреймах, расчет dts кодированного пакета, увеличение качества видео и т. д. Для тестов мы использовали обычный настольный компьютер с достаточно производительным CPU. В ближайшее время мы планируем попробовать новую версию API, а также провести тесты на серверных решениях. Кроме этого, мы планируем провести расширенные тесты на различных наборах параметров для получения более полной картины, результатами которых мы поделимся в самое ближайшее время.

    UPD
    Вот два ролика: первый получен кодированием при помощи ffmpeg, второй при помощи Intel Media SDK И там и там почти все параметры по умолчанию, битрейт 8000 Кб/сек
    webcaster.pro/video1.mp4
    webcaster.pro/video2.mp4
    Intel 194,86
    Компания
    Поделиться публикацией
    Комментарии 35
    • +2
      А что с качеством получаемого видео? Вроде как разница есть и она достаточно заметная.
      • 0
        Профайл high, битрейт 3000 кб/с., HD — картинка полученная софтовым энкодером и GPU энкодером на глаз идентична. На более низких качествах разница есть, но она не существенна.
        • +3
          Ну уж не знаю, пробовал жать GPU, решениями от Intel и Nvidia, получается мыло. На FullHD с ходу конечно не заметно, но мелкие детали изрядно замыливаются. На HD заметно уже лучше, если на мониторе смотреть, еще куда ни шло, а вот на ТВ было жуткое мыло. От Intel правда качество было получше. Единственный вариант, это задирать битрейт очень высоко. Для стриминга еще терпимо, если не через WiFi глядеть в домах, где всё загажено множеством сетей. А для хранения уже нет смысла.

          >> Например, более точно выдерживался битрейт
          Ну битрейт может быть плавающим, в зависимости от динамичности сцены и к сожалению современные решения на GPU с этим никак не справляются, вот и выдерживают.
          • +2
            А что насчет размеров файла? Насколько я знаю, решение от Intel выдает приблизительно такой файл, какой выдает x264 с пресетом veryfast, а решения с использованием CUDA так вообще ultrafast, т.е. результат получается почти никакой.

            В основном, именно по этой причине решения на базе GPU так непопулярны.
            • +1
              А что насчет размеров файла?

              Так битрейт одинаковый => размеры файлов одинаковые. А вот качество — уже нет. Программный енкодер ВСЕГДА качественнее (возможны очень плохо работающие на GPU оптимизации), но нередко разница в качестве несущественна, а вот в скорости — другой разговор.

              Я для себя кодирую в x264 high/5.1 с пресетом placebo. Ну а что, спешить мне некуда. Для моих видео скорость кодирования составляет 4х, за ночь пачка файлов на пару месяцев просмотра нормально обрабатывается.
              • 0
                Да, как-то не подумал, что автор использует исключительно vbr (или подобие abr). Было бы интересно сравнить размер файла с одинаковым коэффициентом квантования в x264 и quicksync.

                с пресетом placebo

                Это вы зря.
                • 0
                  Было бы интересно сравнить размер файла с одинаковым коэффициентом квантования в x264 и quicksync.

                  Пожалуй, да. Хотя разница в качестве все равно будет.
                  Это вы зря.

                  Почему? Медленно — да (хотя 4х не так уж плохо). Самый точный motion estimation, что неплохо для весьма статичного видео. Ага, я понимаю, что по сравнению с тем же fastest выигрываю доли процента по качеству, но как я уже говорил — спешить некуда :)
                  • 0
                    Разница между veryslow и placebo минимальна, разница в скорости кодирования значительная.
                    • 0
                      Да и плевать. Ну закончит кодироваться не в 10 утра, а в 2 часа ночи. Кому-то от этого будет лучше?

                      Когда кодируешь с коэффициентом квантования 38 (если мне память не изменяет), любые мелочи заметно влияют на результат. В результате имеем видеофайл, в котором звуковой поток HE-AACv2 в 32кб/с составляет более половины размера файла, и при этом артефакты компрессии картинки заметны очень редко и никак не мешают.

                      Жду h.265 и какой-нибудь более крутой звуковой кодек.
                      • 0
                        Так это, есть же www.opus-codec.org/
                        • 0
                          Я изучал.
                          1) Он не лучше, чем HE-AACv2.
                          2) На всей моей электронике нет его аппаратного декодирования. Это очень плохо — время жизни планшета от зарядки сокращается с недели (удобно) до 3-4 дней (неудобно).
                          • 0
                            время жизни планшета от зарядки

                            Ооо. Подскажите, плиз, что за планшет, который неделю живёт (я серьёзно, мне бы пригодился).
                            • +1
                              Nexus 7 (2012). Без модификаций программных или аппаратных. Полтора-два часа видео в день, ни под какие другие задачи он не используется.
          • 0
            У того же ffmpeg или mplayer есть возможность померить качество кодирования «в попугаях». Метрика называется PSNR, нужно полистать man-ы, и можно будет качественно оценить, насколько просело качество картинки.
            • 0
              В ближайшее время планируем это сделать.
        • 0
          Ну битрейт может быть плавающим, в зависимости от динамичности сцены и к сожалению современные решения на GPU с этим никак не справляются, вот и выдерживают.

          Здесь, наверное, соглашусь. Но иногда бывает критично выдерживать постоянный битрейт. С ffmpeg подобрать такой профайл кранйе тяжело для каждого качества.
          • 0
            Надо бы добавить к минусам — требуется поддержка в самих процах. Более того, когда появятся мощные Xeon'ы с поддержкой Intel® Quick Sync Video — неизвестно.

            IMHO, топовый E3-1285L v3 не отвечает требованиям по мощности CPU, а только для транскодирования его покупать как-то не выгодно, не находите?
            • 0
              Мы планируем использовать выделенный сервер именно для транскодирования. Собрали недавно сервер с xeon, погоняем тесты на нем и обязательно выложим результаты в ближайшее время.
            • +1
              Ждем тесты со сравнением haswell/ivy bridge
              • 0
                Скажите, как ведут себя в этом плане новые видеокарты 5000 и 5100? Пробовали ли на них проводить кодирование?
                • 0
                  Пока не пробовали
                • 0
                  Использовалась технология Quick Sync?
                  А то из текста совершенно не понятно, но косвенно — по упоминанию Intel Media SDK — скорее всего Quick Sync.
                  Но насколько знаю, Интел позиционирует Quick Sync как часть процессора, а не GPU. В частности, поддержка Quick Sync отсутствует в бюджетных процессорах Пентиум и Селерон, хотя GPU там присутствует.
                  Так что хотелось бы прояснить этот момент, а то заголовок (возможно) вводит в заблуждение.
                  • 0
                    Intel Media SDK работает только на процессорах, поддерживающих Quick Sync и использует аппаратные ресурсы встроенного видео, насколько мне известно.
                    • 0
                      Нет, там отдельный аппаратный блок для исполнения специализированных инструкций — с GPU от связан постольку-поскольку. Теоретически возможно наличие поддержки Quick Sync и отсутствие GPU — например в специализированных серверных процессорах, если будет спрос на такие решения.
                      Но суть не в этом — просто название несколько вводит в заблуждение, и по тексту нигде не упоминается Quick Sync, хотя именно она используется для описанных вещей.
                  • 0
                    Сколько в итоге у вас лайв стримов реально обрабатывается на одном сервере (и на каком?)
                    • 0
                      На сервере пока не тестировали, только недавно собрали само железо. Тесты были на обычном десктопе. При этом удалось кодировать 12-14 full HD или примерно 60 потоков SD (640x320)
                      • 0
                        Я рекомендую обратиться к Ясону (рассылка libx264-devel) и попросить его помочь с настройками x264, которые выдадут такое же качество при таком же количестве потоков.

                        Возможно он что-то предоставит?

                        Ещё вопрос: чем вы mpeg2 декодировали?
                        • 0
                          Спасибо за идею, надо попробовать
                          Я декодировал udp поток, сжатый h264 кодеком, а так же сигнал SDI (там «сырые» данные)
                          Что касается libx264 и ffmpeg, то я просто не смог столько потоков физически транскодировать — банально закончилась память (причем до 60 потоков так и не дошло) Intel SDK, как выяснилось, кушает гораздо меньше памяти
                          • 0
                            *h264 декодировал так же Intel SDK
                            • 0
                              Думаю, что вы натолкнулись на какие-то проблемы именно libav.

                              У libx264 потребление памяти очень небольшое.

                              Ваш код в каком-то виде доступен? Исходники, платная программа? Или только всё закрытое?
                              • 0
                                ПО у нас закрытое. Кодировал я и при помощи ffmpeg и при помощи нашего софта, написанного с использованием этой библиотеки — результат одинаковый. При большом количестве потоков наблюдается значительное потребление памяти. Версии ffmpeg и libav мы пробовали разные. Intel SDK потребляет примерно в два раза меньше памяти для разных параметров кодирования, разных качеств и т.д.
                      • +2
                        Под ffmpeg h264 encoder вы видимо подразумеваете x264. Судя по тому как быстро он кодировал вы использовали пресет ultrafast или что-то близкое к нему. Но без сравнения качества получившихся видео в таком сравнении не очень много смысла.
                        • +1
                          Есть интересное сравнение кодеков от МГУ. Там есть сравнение x264 и Intel QuickSync (в Appendix 6, страницы 131-138). У них получилось, что между QuickSync и x264 с быстрыми пресетами нет особой разницы.
                          www.compression.ru/video/codec_comparison/h264_2012/
                        • 0
                          Добавил в статью два ролика, сжатых ffmpeg и Intel Mеdia SDK для примера.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое