company_banner

Серверное решение для кодирования видео с использованием встроенного видео Intel HD Graphics


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

    Тестирование

    Для тестирования нашего ПО был выбран 1U сервер в следующей конфигурации:
    M/B Supermicro X10SLH-F
    Процессор Intel® Xeon® CPU E3-1225 v3 @ 3.20GHz
    Память 16 Гб
    Версия OS на сервере Ubuntu 12.04.4 LTS 3.8.0-23-generic. Главным условием работы Quick Sync является наличие строки С226 в спецификации чипсета. Только чипы с такой маркировкой умеют работать с аппаратным кодированием видео. Кроме этого, желательно отсутствие встроенного видео на материнской плате, в противном случае могут возникнуть проблемы с определением, а значит, и использованием Intel GPU средствами Intel Media SDK.
    Материнская плата, описанная выше, имеет интегрированную графику (встроенное видео) на борту, и нам пришлось повозиться для того, что бы заставить работать SDK на этом железе. При установке SDK на новый сервер скрипт установки Media SDK не увидел ID устройства. При этом, нам не удалось включить встроенную в процессор графику из BIOS. Поиск решения привел к необходимости обновить BIOS. После этого в BIOS появился заветный пункт. Однако, пришлось еще отключить встроенное на материнской плате видео путем переключения перемычки. В такой конфигурации не работает IPMI и выход на монитор, но мы работаем с сервером через SSH и это не так критично.
    Кроме этого, есть некоторые ограничения на используемое в системе ядро Linux. Для серверов это Ubuntu 12.04 LTS с ядрами 3.2.0-41 и 3.8.0-23 или SUSE Linux Enterprise Server 11 с ядром SP3 3.0.76-11.

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

    В качестве тестового ролика выступало видео 1920x800, H264, продолжительностью 12 минут. Выходное видео: 1920x800, high, H264, 8Мб/с. В случае ffmpeg параметры были по умолчанию (profile high). Тестовая утилита из Intel Media SDK sample_full_transcode также кодировала с параметрами по умолчанию (profile high). Streambuilder с поддержкой QuickSync кодировал со следующими параметрами: profile high, RateControlMethod cbr, level avc 4.2. Параметр target usage (влияет на качество/скорость кодирования) во всех случаях balanced.
    Результаты тестов иллюстрирует следующая таблица.

    Процессор: E3-1225 V3, 16 Гб ОЗУ, Intel® HD Graphics P4600
    ffmpeg sample_full_transcode streambuilder (no optimization) streambuilder (optimization)
    time 8 мин. 42 с 1 мин. 19 с 2 мин.19 с 1 мин. 40 с
    cpu (max) 750% 55% 125% 50%
    mem (max) 3,3% 4,6% 0.5% 0.4%
    PSNR 48,107 46,68
    Average PSNR 51,204 49,52
    SSIM 0,99934 0,9956
    MSE 1,623 2,969

    Процессор: I7-3770, 3 Гб ОЗУ, Intel® HD Graphics 4000
    ffmpeg sample_full_transcode streambuilder (no optimization) streambuilder (optimization)
    time 8 мин. 48 с 1 мин. 24 с 2 мин. 31 с 1 мин. 23 с
    cpu (max) 750% 19% 150% 45%
    mem (max) 18% 20% 2.8% 2.3%
    PSNR 48,107 46,495
    Average PSNR 51,204 49,27
    SSIM 0,99934 0,991
    MSE 1,623 3,036

    Процессор E3-1285 v3, 16 Гб, Intel® HD Graphics P4700
    ffmpeg sample_full_transcode streambuilder (no optimization) streambuilder (optimization)
    time 8 мин. 1 с 1 мин. 11 с 2 мин. 11 с 1 мин. 34 с
    cpu (max) 750% 55% 130% 55%
    mem (max) 3,3% 4,6% 0.5% 0,4%
    PSNR 48,107 46,68
    Average PSNR 51,204 49,52
    SSIM 0,99934 0,9956
    MSE 1,623 2,969

    Анализ результатов

    Метрики для streambuilder соответствуют полученным метрикам для тестовой утилиты sample_full_transcode и я их опустил.
    Из этих таблиц видно, что серверные процессоры с Intel® HD Graphics P4700/P4600 в данном эксперименте работают быстрее и дают лучшее качество кодирования, чем I7-3770, Intel® HD Graphics 4000. Однако этот тезис не всегда верен, так как Intel совершенствует качество кодирования с каждой новой версией чипа и SDK и скорость на новых чипах может быть меньше. При этом нагрузка на CPU у первых немного больше. С чем это связано, пока непонятно.
    Кроме этого, оптимизация работы с памятью дала прирост примерно в 2 раза в плане производительности.

    Качество кодирования на Intel® HD Graphics P4700 получилось таким же, как и на Intel® HD Graphics P4600, но E3-1285 v3 работает быстрее примерно на 14% при той же загрузке ресурсов. Кроме этого, E3-1285 v3 быстрее E3-1225 V3 в кодировании при помощи ffmpeg примерно на 10%.
    Сервер с установленным streambuilder с поддержкой Quick Sync позволяет кодировать один источник в 12 качеств Full HD (1080p), 24 качества HD (720p) и 46 качеств SD (480p) с нарезкой в HLS. Если это съем «сырого» сигнала с SDI, то число одновременно кодируемых качеств немного больше.
    Поэкспериментировать со streambuilder (пока только libavcodec based версия) можно скачав его отсюда. С ним в комплекте идет стандартный конфиг, позволяющий записывать в формат HLS любой источник.

    Итоги

    Технология Intel Quick Sync позволяет собрать сравнительно недорогой производительный сервер для кодирования видео с приемлемым качеством. В процессе внедрения этой технологии мы столкнулись с некоторыми техническими проблемами, связанными с наличием интегрированного в материнскую плату видео, которые, впрочем вполне решаемы. ( Напомним, главное при выборе железа для этих целей — это чип со спецификацией С226 и материнская плата без интегрированного видео, так как с ним может не работать IPMI и VGA выход).
    Плюсы такого решения, на мой взгляд, это то, что почти не задействован CPU, а также небольшое потребление памяти. При этом, свободные ресурсы можно использовать для других задач или для кодирования средствами CPU.

    В ближайших планах у нас поиграться с VPP (video post processing = постобработка видео) функциями Intel Media SDK (denoise, crop, resize, frame rate conversion, deinterlacing и т.д.). Пока мы реализовали crop, resize и deinterlacing, и эти операции выполняются так же быстрее, чем их чисто программные аналоги. В Intel Media SDK довольно много параметров кодирования, и мы продолжаем делать тесты и сравнивать с нашим профайлами. О результатах экспериментов с VPP, производительностью/качеством и сравнении 2-pass кодирования ffmpeg/h264 с технологией LookAhead Intel HD Graphics, я думаю, мы еще напишем.
    Intel 194,92
    Компания
    Поделиться публикацией
    Комментарии 50
    • +2
      А что на счет кодеков vp8/vp9 и h265? Они поддерживается аппаратно?
      • 0
        Насколько мне известно, поддерживается h265 (HEVC)
        • +3
          Уточнил, аппаратной поддержки нет, SDK поддерживает h265 только софтварно
          • 0
            Жаль, просто h264 кодируется очень быстро(даже на cpu) по сравнению с h265 и тем более с vp9. Даже на вашем примере 12 мин видео закодировалось за 8 мин. Недавно, я кодировал vp9 с помощью последнего ffmpeg и скорость была ужасной, около 0.01fps, т.е. чтобы закодировать 12 мин видео мне нужно было кодировать 25 суток(600 часов или 36000 мин). Это было двухпроходное кодирование FullHD видео с максимальным качеством.
            • 0
              Когда много стримов (100 и больше) этот выигрыш ~10 раз может играть определенную роль. Скажем, один сервер с ускорителем на борту кодирует так же как и 5 — 6 таких серверов.
              Мы так же двух проходное кодирование ffmpeg сравнивали с LookAhead от Intel. Разница в 10 раз, при том, что на глаз не сразу и увидишь разницу (считали метрики)
        • 0
          Ну как-то технических подробностей маловато. Каким получился выходной размер файла во всех случаях, или средний битрейт? Одинаковые ли были настройки, хотя бы, motion estimator, b/p-frames?
          • 0
            Во всех случаях выходной размер получился примерно 700 МБ и средний битрейт, соответственно 8 Мб/с
            Настройки в ffmpeg по умолчанию, задан только выходной битрейт
          • +1
            А что с качеством результата? Обычно, проблема аппаратного кодирования в том, что он хоть и быстрее, но дает существенный проигрыш в качестве, особенно, на низком битрейте (если сравнивать кодирование на nvidia tesla/видеокартах и ffmpeg). В этом и состоит основная проблема его использования.
            • 0
              Качество для live вполне приемлемое и это видно по метрикам. Можете сами глянуть результат — inventos.ru/video/v1.mp4 — это фрагмент, закодированный при помощи ffmpeg, а это inventos.ru/video/v2.mp4 при помощи Quick Sync, при одинаковых параметрах. Если сравнивать с 2-pass кодированием ffmpeg, то разница видна конечно, но надо сильно присматриваться.
              • +1
                Ну такое, у первого видео мало того, что битрейт 13 Мбит, так еще и в полтора раза больше второго. Конечно первое будет круче, а если второе сделать с таким-же битрейтом, то разница будет не заметной.

                Вы не могли бы сделать примеры с одинаковым битрейтом, мегабита по 4? А то матери с таким чипсетом нету, ради теста покупать не охота, а аппаратное кодирование с достаточно хорошим качеством это очень актуально!
                • 0
                  Так это фрагмент же большого видео (700 Мб), у которого _средний_ битрейт 8 Мб/с. На разных участках эти кодеры по-разному жали. Просто все видео тяжелое довольно.
                  • 0
                    Ниже выложил фрагменты по 1 минуте из тестового ролика, там битрейт примерно одинаковый. Как вариант, можете выслать ваш контент с рекомендациями по настройкам сжатия и я его попробую транскодировать
                  • 0
                    так выложили бы и исходный файл? :) чтобы было с чем сравнивать
                    • 0
                      Перекодировал фрагмент 1 мин. Исходник — inventos.ru/video/v.mp4
                      Это результат ffmpeg inventos.ru/video/test1.mp4
                      Это результат Quick Sync — inventos.ru/video/test2.mp4

                      (На длинных роликах ffmpeg лучше соблюдает средний битрейт и здесь он получился немного больше)
                      • 0
                        А почему у закодированного фрагмента размер почти в 2 раза больше чем у исходника? В чем физический смысл кодирования с таким задранным битрейтом? :)
                        • 0
                          Это тест синтетический, просто попался файл нужного мне размера. На других файлах и битрейтах ситуация похожая.
                          • 0
                            В таком случае теряется смысл объективных тестов :) «исходник» сам по себе замыленный и с кучей артефактов. Т.е. суть статьи сводится ко фразе «на глаз вроде бы ничего так» :)
                            А для настоящих тестов лучше было бы воспользоваться уже ставшим стандартным 22-х секундным отрывком брызги-дерево-туман из Автара. Там бы сразу стало ясно по скриншотам что из себя представляет какой-либо из типов кодирования.
                            Если интересно, то вот этот отрывок на яндекс диске (40Мб)
                            yadi.sk/i/lcSv-PTMWGeTf
                            • 0
                              Пожал Ваш файл, вот здесь результат ffmpeg inventos.ru/video/avatar1.mp4, вот здесь Quick Sync inventos.ru/video/avatar2.mp4 Битрейт сделал 20 Мб/с, чуть ниже, чем у исходника
                              • +1
                                Спасибо и теперь можно посравнивать :) В принципе все как я и думал — качество Quick Sync сравнимо с самым быстрым пресетом софтверного x264 и еще не факт кто из них окажется быстрее :)
                                Для иллюстрации сравнение скриншотов — Quick Sync 20 Мб/c с медленным x264 битрейтом в 2 раза ниже. Вот с этим
                                yadi.sk/i/SDQIG2dXWHhrC
                                Очевидно что у x264 в 2 раза меньшего размера качество заметно выше
                                screenshotcomparison.com/comparison/82845
                                И до кучи сравнение с исходником
                                screenshotcomparison.com/comparison/82846
                                • 0
                                  качество Quick Sync сравнимо с самым быстрым пресетом софтверного x264 и еще не факт кто из них окажется быстрее

                                  Очень спорно. Я так и не смог найти пресет, когда ffmpeg обогнал бы Quick Synck
                                  Для иллюстрации сравнение скриншотов — Quick Sync 20 Мб/c с медленным x264 битрейтом в 2 раза ниже

                                  С каким пресетом Вы сжимали? Я просто хочу обратить внимание на метрики PSNR и SSIM. Среднее значение метрики для ffmpeg и Quick Sync не сильно отличается, но я видел флуктуации как в ffmpeg, так и в Quick Sync на некоторых кадрах. Про «заметно выше» тоже очень спорно. В ffmpeg скрине хорошо заметны шумы, которые в Quick Sync слегка замылены. кроме этого в Quick Sync использовался «пресет» balanced и это не совсем корректно сравнивать с медленными пресетами ffmpeg.
                                  • +1
                                    А сколько времени заняло кодирование отрывка из Аватара в Quick Sync? Попытаюсь набросать командную строчку для x264 со сравнимым качеством за сравнимое время.
                                    И дался вам этот ffmpeg :) Он в 264 кодировал всегда по принципу побыстрее-посмешнее. И в замыленности как раз все и дело — в результате пропадает большая часть мелких деталей.
                                    • 0
                                      Кодировал 3,3 секунды
                                      • 0
                                        Хм… 3.3 сек не получилось, но у меня и процессор попроще. Быстрее 7.3 сек не смог, но так думаю что x264 на Ксеноне с параметрами
                                        --ref 2 --me dia --subme 2 --analyse none --bframes 1 --no-b-adapt --no-chroma-me
                                        
                                        будет быстрее 5 сек
                                        Вот мой семисекундный лог
                                        x264 [info]: profile High, level 4.1
                                        x264 [info]: frame I:8     Avg QP:18.30  size:202347
                                        x264 [info]: frame P:264   Avg QP:20.06  size:130896
                                        x264 [info]: frame B:260   Avg QP:21.64  size: 65315
                                        x264 [info]: consecutive B-frames:  2.3% 97.7%
                                        x264 [info]: mb I  I16..4:  5.5% 55.4% 39.1%
                                        x264 [info]: mb P  I16..4: 35.8%  0.0%  0.0%  P16..4: 63.3%  0.0%  0.0%  0.0%  0.0%    skip: 0.9%
                                        x264 [info]: mb B  I16..4: 14.6%  0.0%  0.0%  B16..8: 41.0%  0.0%  0.0%  direct:
                                        30.0%  skip:14.4%  L0:28.9% L1:31.1% BI:39.9%
                                        x264 [info]: 8x8 transform intra:3.2% inter:64.3%
                                        x264 [info]: coded y,uvDC,uvAC intra: 84.6% 79.8% 30.4% inter: 69.2% 52.3% 6.3%
                                        x264 [info]: i16 v,h,dc,p: 13% 43% 29% 15%
                                        x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 30% 27%  3%  5%  3%  5%  4% 13%
                                        x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 15% 20% 12%  9% 10%  8%  9%  7% 10%
                                        x264 [info]: i8c dc,h,v,p: 48% 32% 16%  4%
                                        x264 [info]: Weighted P-Frames: Y:0.4% UV:0.0%
                                        x264 [info]: kb/s:19165.41
                                        
                                        encoded 532 frames, 73.38 fps, 19165.69 kb/s
                                        
                                        И сравнение скриншотов, из которого видно что x264 оставляет намного больше деталей и дает намного меньше мыла
                                        screenshotcomparison.com/comparison/82905
                                        И даже если сжать битрейт в 2 раза x264 все еще выглядит сравнимо
                                        screenshotcomparison.com/comparison/82908

                                        Так что в результате можно сказать что Quick Sync с битрейтом на 70% выше обеспечивает качество сравнимое с x264 при выигрыше во времени кодирования от 70 до 150%

                                        PS. Файлы с результатами быстрого кодирования с помощью x264 вот тут
                                        yadi.sk/i/YKJY-0c_WKh5B
                                        yadi.sk/d/Cgmin8rNWKh9o
                                        • 0
                                          ffmpeg -i Avatar.Remux.1080p.enc.stress-test-sample4.mkv -an -vcodec libx264 -x264-params ref=2:me=dia:subme=2:analyse=none:bframes=1:no-b-adapt=1:no-chroma-me=1 -b:v 20000000 -f mp4 avatar3.mp4

                                          У меня 12 секунд получилось
                                          Можете всю командную строку показать?
                                          По качеству, повторюсь вопрос дискуссионный, особенно когда речь про live идет )
                                          Качество можно повысить, использую preset quality, тогда время кодирования будет примерно 4-5 сек
                                          • +1
                                            а я через AviSynth и x264 :) Поэтому 2 файла.
                                            Первый — mkv-source.avs:
                                            FFVideoSource("D:\Video\test4\Avatar.Remux.1080p.enc.stress-test-sample4.mkv")
                                            

                                            и второй — x264-fast.cmd:
                                            "D:\x264\x264.exe" "D:\Video\test4\mkv-source.avs" --force-cfr --crf 19 --crf-max 24  --level 4.1 --ref 1 --me dia --subme 2 --analyse none --bframes 1 --no-b-adapt --no-chroma-me --output "D:\Video\test4\video_fast.mkv"
                                            pause
                                            
                                • 0
                                  Но ведь это просто ужасно, или я чего-то не понимаю.
                                  • 0
                                    Это вообще на испорченный кадр похоже, посмотрю в чем дело. Следующий кадр буквально уже нормальный
                                    • +1
                                      Там минимум 4 таких испорченных «кадра» за 20 секунд видео — при каждой смене сцены, начиная с самых первых кадров. Даже для потокового видео это издевательство.
                                      • 0
                                        Честно говоря, первый раз с таким столкнулся, доберусь до железа, попробую еще раз. Перед этим, наверное, 2 десятка роликов сжал, просматривая при этом по кадрам.
                                        • 0
                                          Да, похоже штатный парсер h264 фреймов затупил. Я пережал сначала ffmpeg-ом в валидный формат, а потом средствами SDK и артефактов не было. Кстати, при сжатии ffmpeg ругался. В общем это не глюк кодека, похоже. Спасибо за внимательный анализ
                                          • +1
                                            Для чистоты эксперимента сначала распаковал в raw yuv, а затем пожал средствами SDK — inventos.ru/video/avatar3.mp4
                      • +1
                        А можно параллельно несколько потоков кодировать?
                        • 0
                          Да, у нас в софте именно так
                          • 0
                            Вероятно, имелось в виду параллельное кодирование с использованием аппаратного ускорителя. Когда два разных потока используют ускоритель одновременно.

                            В rtgraph обычно использовались однопоточные Tee фильтры, и вся программа работала в один поток, а головы проца напрягал сторонний кодировщик кадров. Из-за этого нельзя было одновременно кодить много потоков, потому что они кодились поочередно и могли теряться кадры. При использовании TeeThreaded картина кардинально менялась.

                            Так что вопрос — если второй экземпляр программы запустить, какова будет производительность?
                            • 0
                              Только вот вопрос увидел. Сейчас мы почти прекратили поддержку rtgraph, вместо этого — новый продукт — streambuilder. Там все кодировщики в графе в отдельном потоке и нет разницы — два экземпляра запущены или один с множеством потоков. А производительность почти линейно зависит только от количества видеостримов, которые идут на GPU.
                        • 0
                          Baseline и main тоже поддерживаются? (в статье только high упоминается)
                          • 0
                            Да, поддерживаются, мы просто в основном с high эксперементировали.
                          • 0
                            Вы ребята, конечно даёте.

                            Пока туда-сюда, 1226 уже больше не поддерживаются.
                            • 0
                              Упс, а можно ссылку на это?
                              • 0
                                в референсе на Intel Media SDK написано, что нужно 128x процессоры. Т.е. не по $150, а по $700

                                Пока что свежий SDK запустить не получилось. Честно говоря у меня руки опускаются от того, что я вижу =(
                                • 0
                                  Вообще мне говорили что ВСЕ хасвелы будут поддерживаться. Если нет, то это плохо чуть более, чем полностью. Завтра проверим в связке CentOS + 1225 работоспособность 2015R3.
                                  • 0
                                    показания расходятся.

                                    Я написал Нине, поскольку больше писать попросту некому. Сотрудникам интела на intel.com веры нет =)

                                    Напишите потом, какие будут результаты. Будет очень обидно, если нам прийдется деградировать до центоса для того, что бы заработал долбаный квиксинк =(
                                    • 0
                                      Пока сервер решили не трогать в плане установки Centos. Написал вопрос сотрудникам Intel в московском офисе, жду ответ. Но, насколько мне известно 2015 R3 точно только на Centos работает. Вроде как следующую версию можно будет на другие OS портировать.
                                      • 0
                                        Запустили наш софт на centos с 1225. Релиз СДК 2015 R4.
                                        • 0
                                          А без центоса не?
                                          • 0
                                            Пока нет. Там нетривиальная процедура портирования на убунту, но вроде как возможно. Еще один момент — на десктопных материнках с Xeon не работает вообще никак, что странно, ибо ядро процессора одно и тоже по идее. А i7 вроде как работает.
                                            • 0
                                              ядро, да?

                                              Это очень грустно и смешно. Надо ехать в датацентр и опоганивать сервера проклятым центосом. Спасибо соотечественникам, блин.
                                              • 0
                                                Как вариант — попробовать процедуру портирования на убунту (ядро 3.14.5, если не ошибаюсь). Можно у сотрудников Интел уточнить про это.

                                                Кстати, хотел спросить. У вас на серверах загрузка какая? Были случаи GPU hang, или полного зависания системы на ubuntu?
                                                • 0
                                                  мы не запустили ещё квиксинк в продакшн под нормальные нагрузки. Я вообще не готов никому из клиентов рекомендовать квиксинк как продакшн решение, потому что это всё пока что большая веселая бета.

                                                  Когда кому-то из Нижнего в очередной раз зачешется левая нога и прийдет в голову решение отказаться от поддержки очередной ОС и клиенту надо будет объяснять, что надо всё пересетапливать… Не, парни, это всё не более чем веселое поделие.
                                  • 0
                                    software.intel.com/sites/default/files/managed/12/a9/media_server_studio_getting_started_guide_linux.pdf

                                    For Xeon processors only the
                                    E3-128Xv3 family with C226 chipset is supported.

                                    У меня нет цензурных слов на этот счёт. На форуме мне опять говорят, что я не так понял и всё поддерживается: software.intel.com/en-us/forums/topic/543042 но учитывая что в интеле этому media sdk не уделяют внимания, возможно действительно втихаря «забыли» включить media sdk для «дешевых нищебродских» процессоров.

                                    Не исключено, что надо будет удалять всю систему, возвращаться обратно на Media SDK 2014 и больше никогда не обновляться =(

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

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