Стресс-тест GPU NVidia на транскодинге живых потоков

    Ниже — подробный рассказ о том, как мы нагрузили карту от NVidia задачами транскодирования видео для его потоковой передачи. Покажем, что попробовали, что получилось, и как лучше всего использовать видеокарты для стриминга в онлайне.
    На протяжении нескольких лет наша команда разрабатывает продукты для обработки и раздачи медиа-контента в онлайне. В этой статье не так давно было расписано, зачем владельцам контента подобные решения могут быть нужны в наш век YouTube.

    Одним из наших продуктов является медиа-сервер Nimble Streamer — это серверное ПО, которое берёт на вход живые потоки и файлы и делает их доступными большому числу зрителей, попутно позволяя монетизировать контент. Это нативное приложение, написанное на С++ и портированное на все популярные ОС (Linux, Windows, MacOS) и платформы (x64, ARM). С самого начала низкая ресурсоёмкость и большая производительность были главными требованиями, и нам удаётся достигать в этом хороших показателей.

    В прошлом году мы выпустили дополнение в Нимбл Стримеру — транскодер живых потоков. Это приложение позволяет брать на вход поток видео и/или аудио в разных форматах и делать с ними различные преобразования в реальном времени. Функциональность включает в себя декодирование (как программное, так и аппаратное), преобразование видео и аудио с помощью фильтров (изменение размера, наложение и т.п.) и кодирование (энкодинг) — как программное, так и аппаратное.

    Управляется транскодер через веб-сервис WMSPanel, сценарии транскодирования создаются через drag-n-drop интерфейс, что позволяет наглядно видеть процесс. Различные сценарии можно запускать вместе — при таком подходе удобно запускать комбинации тестов, нагружая сервер в любых вариациях.
    В этих видео можно посмотреть примеры работы интерфейса.

    Декодирование каждого потока делается только один раз перед всеми дальнейшими преобразованиями… Это позволяет сэкономить ресурсы на дорогостоящей операции декодинга, это будет хорошо видно дальше по ходу тестов.

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


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

    Нам требовалось оперативно получить соответствующее железо и доступ к нему, для цикла наших экспериментов. Мы планировали уложиться в пару недель. Осталось найти, где же взять оборудование. Оптимальным вариантом было бы найти их в облаке и получить удаленный доступ. Поискав варианты выяснилось, что в AWS пока нет VM с GPU поколения Maxwell, а в облаке Azure пока только планируется начать их предоставлять в скором времени.

    1. Железо от NVidia в облаке Softlayer, настройка Nimble Streamer


    При содействии NVidia, компания IBM предоставила нам доступ к своему облаку — IBM Bluemix Cloud Platform (в прошлом Softlayer). Это большая сеть современных ЦОД-ов (около 50 на момент публикации) по всему миру, связанных общей частной сетью и предоставляющих большой выбор облачных инфраструктурных сервисов. Все ЦОД-ы унифицированы и позволяют арендовать от одного до сотен виртуальных или физических серверов требуемых конфигураций в течении нескольких часов, а также балансировщики, системы хранения, файрволы — в общем всё, что требуется чтобы построить надежную ИТ-инфраструктуру под развертываемый ИТ-сервис.

    Российское представительство IBM предоставило нам полный доступ к порталу самообслуживания для управления облачными услугами и к нужной серверной конфигурации, где мы смогли поработать с разными входными потоками и настройками нашего транскодера.

    Железо


    Сначала нам предоставили физический сервер (bare-metal) с 128 ГБ RAM и 2xGPU NVidia Tesla M60 и предустановленной ОС Ubuntu 14.04. Все параметры сервера, пароли, версии прошивок, его коммутация, выделенные IP, состояние аппаратных компонент, были видны прямо в личном кабинете, позволяющем сделать с арендованным железом требуемые манипуляции, что минимизировало необходимость взаимодействия со службой поддержки IBM. В ходе прогона тестов, выяснилось, что нам не удается оптимально нагрузить такую конфигурацию, из-за ряда ограничений при генерации контекстов.

    Нам захотелось уменьшить конфигурацию. Поскольку мы использовали облачную платформу, то потребовалось через портал самообслуживания запросить изменения в конфигурации. После согласования, данная операция заняла около 2 часов, в утвержденное окно обслуживания. В течении этого времени, технический персонал в ЦОД-е Амстердама, извлек лишние компоненты (планки RAM и 1xGPU) из предоставленного нам ранее сервера и вернул его в строй. Надо отметить, что для разработчиков такой вариант очень удобен, поскольку нет необходимости ни самим разбираться с настройками железа, ни чинить его, ни даже тратить время на установку ОС. Напомню, в данном случае не используется гипервизор поскольку нам надо выжать максимум из аппаратных ресурсов.

    По итогам наших изысканий мы остановились на следующей конфигурации сервера:
    Dual Intel Xeon E5-2690 v3 (2.60GHz)
    24 Cores
    64GB RAM
    1TB SATA

    Имеем 2 процессора по 12 ядер, а благодаря Hyper threading получаем вдвое больше, т.е. виртуально 48 ядер.

    В сценариях с графическим ускорителем использовалась карта на базе чипа GM204 — Tesla M60:
    NVIDIA Tesla M60
    1xGPU: 2 x Maxwell GM204
    Memory: 16GB GDDR5
    Clock Speed: 2.5 GHz
    NVIDIA CUDA Cores: 2 x 2048
    Memory Bandwidth: 2 x 160GB/sec

    Обращаю внимание, что на приведённом железе не делалось никакого affinity, chip tuning-а, overclocking-а и прочей магии — только неразогнанные CPU и GPU, и для GPU использовался только официальный драйвер, взятый с сайта NVidia. Если у кого-то есть подобный опыт — поделитесь в комментариях.

    Итак, мы получили доступ. Беглое ознакомление с веб-интерфейсом панели управления (там всё просто и понятно), далее доступ к серверу через SSH — и вот мы уже в привычной командной строке Ubuntu, ставим Nimble Streamer, регистрируем свежую лицензию транскодера и делаем небольшую настройку конфига.

    Nimble Streamer Transcoder


    Nimble Streamer был настроен на предварительное создание кеша контекстов GPU. Связано это с тем, что у GPU есть ограничение на максимальное число создаваемых контекстов декодинга и энкодинга, а кроме того, создание контекстов “на лету” может занимать слишком много времени.
    Более подробно о проблеме создания контекстов — в соответствующем разделе ниже.

    Настройки Нимбла на примере первой серии тестов:
    nvenc_context_cache_enable = true
    nvenc_context_create_lock = true
    nvenc_context_cache_init = 0:30:15,1:30:15
    nvenc_context_reuse_enable = true

    Более подробно про эти настройки написано в нашей статье.

    Перед запуском каждой серии тестов кеш настраивался отдельно, с учетом специфики каждой задачи.

    Создание сценариев транскодинга


    Далее работа шла в нашем сервисе WMSPanel, где и происходит настройка сценариев транскодера.

    Как уже было сказано, работа идёт через веб-интерфейс, всё предельно понятно и удобно. Мы создали ряд сценариев, сочетающих разные варианты транскодинга (CPU/GPU), разные варианты разрешений и разные параметры энкодинга (CPU/GPU, профайл, битрейт и т.п.)

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

    Вот так выглядит набор сценариев:


    Вот пример одного из сценариев:


    Декодер с GPU выглядит вот так:


    Накладываем фильтр размера изображения:


    А вот энкодер для варианта с GPU:



    В целом работу интерфейса транскодера можно посмотреть на этих видео.

    2. Транскодирование потоков FullHD 1080p


    Для начала мы опробовали сценарий с самыми большими нагрузками, чтобы узнать пределы возможностей железа. На данный момент самым “тяжёлым” из используемых на практике разрешений является FullHD 1080p.

    Для генерации исходных живых потоков был взят файл в FullHD (1920*1080) в high profile H.264. Сам контент- это видеоэкскурсия по городу, т.е. это видео со средней интенсивностью смены изображения. Нет статичных одноцветных кадров, которые могли бы облегчить работу транскодеру, но нет и слишком быстрой смены видов и цветов. Одним словом — довольно типовая нагрузка.

    На вход в Nimble Streamer подавали 36 одинаковых потоков, которые затем использовались в транскодере в разных сценариях.

    Сценарий транскодинга используется типовой — входящий поток 1080p high profile, из него делаются 720p, 480p, 360p main profile и далее потоки baseline profile: 240p, 160p. Итого, на входе 1 поток, на выходе 5. Обычно также делается pass-through (передача без изменений) исходного потока, чтобы зритель мог выбрать собственно 1080p при просмотре. Его мы не добавляли в сценарии, т.к. в нём не используется транскодинг — идёт прямая передача данных из входа на выход. Этот сценарий у нас в Нимбле оптимизирован и в реальных условиях это относительно немного увеличит потребление памяти.
    Аудио в генерируемых потоках — нет. Добавление аудио в сценарии не даст значительных нагрузок на CPU, но для чистоты эксперимента звук мы исключили.

    Тест на CPU, без GPU


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

    В результате получилось обработать только 16 потоков на вход с выдачей 80 потоков всех разрешений на выход.

    Нагрузка CPU — 4600%, т.е. было задействовано 46 ядер. Расход RAM — порядка 15Гб.

    Тест на CPU + GPU


    Кеш контекстов при запуске настроен как 0:30:15,1:30:15 — т.е. 30 контекстов на энкодинг, 15 на декодинг, у каждого GPU.

    Напомню, что на GPU у нас два ядра, что позволяет распараллеливать задачи — это нам пригодится.

    Максимальная нагрузка получилась при следующей конфигурации потоков.

    На вход декодера GPU0 и GPU1 — по 15 потоков. Таким образом мы получаем 30 декодированных потоков, готовых к дальнейшему использованию. Каждый поток декодируется только один раз, независимо от того, в скольких сценариях он в дальнейшем используется.

    На энкодеры GPU0 и GPU1 подавалось по 15 потоков для получения 720p, т.е. получилось 30 потоков 720p на выход.

    Также на энкодеры GPU0 и GPU1 давалось по 15 потоков для 480p — и так же получилось 30 потоков 480p на выход.

    Поскольку контексты энкодера были исчерпаны, энкодинг остальных разрешений был установлен на CPU. Получилось следующее:

    1. 30 потоков 360p
    2. 30 потоков 240p
    3. 30 потоков 160p

    Нагрузка получилась 2600% CPU, 75% декодер, 32% энкодер. Далее CPU был догружен 6 потоками на декодинг, для каждого настроено по 5 аналогичных разрешений, итого 30 потоков на выход.

    Итого получили на вход 36 потоков, выдали на выход — 180 потоков. Финальная нагрузка зафиксирована следующая: 4400% CPU, 75% декодер карты, 32% энкодер карты, 30Гб RAM.

    Немного деталей


    Мы решили проверить вариант, при котором мы на GPU обрабатываем самые тяжёлые задачи — декодинг 1080 и энкодинг 720 и 480, а остальное пустить на обработку через CPU.

    Сначала проверили предел работы декодера. При 22 потоках на декодинг — сказалась проблема с контекстами, они просто не могли создаться. Снизили до 21 — контексты создались, но нагрузка стала 100% и в потоке стали наблюдаться артефакты. Остановились на 20 потоках — делаем декодирование 20 потоков, энкодинг в 160p — всё работает нормально.

    Кроме того, опытным путём получилось, что данная карта с 16Гб RAM на борту может уверенно работать с 47 контекстами — и нет разницы, это контексты энкодера или декодера. Повторюсь — речь именно о данном GPU Tesla M60, на других картах это число может быть другим. Полагаем, что если бы на карте было 24Гб RAM, число контекстов могло быть другим, но это нужно тестировать.

    В итоге мы выбрали формулу создания кеша «15 контекстов декодера и 30 контекстов энкодера» — что даёт 30 потоков на вход и для каждого позволяет создать по 2 разрешения. Так что на GPU были пущены кодироваться верхние разрешения — 720 и 480, а остальные — 360, 240 и 160 — были отправлены на CPU. И поскольку CPU был после этого всё ещё свободен, мы «добили» свободные ядра новыми потоками, оставив 4 ядра на утилитарные задачи.

    3. Транскодирование потоков HD 720p


    Сценарий с типовой нагрузкой, т.к. бОльшая часть контента сейчас создается именно в HD. Даже недавний SuperBowl LI — самое рейтинговое шоу на американском рынке — передавали именно в HD, оставив FullHD на будущее.

    Для генерации исходных потоков был взят файл в HD (1280*720) в high profile. Контент — любимая серия “The Good Wife” нашего инженера, т.е. это видео со средней интенсивностью смены изображения.

    На вход в Nimble Streamer подавали 70 одинаковых потоков, которые затем использовались в транскодере в разных сценариях.

    Сценарий транскодинга используется следующий — входящий поток 720p high profile, из него делаются 480p, 360p main profile и далее потоки 240p, 160p baseline profile. Итого, на входе 1 поток, на выходе 4. Pass-through исходного потока, как и в предыдущем сценарии, не выполнялся. Аудио в генерируемых потоках — так же нет.

    Тест на CPU, без GPU


    Как и в предыдущем разделе, мы попробовали транскодинг потоков только на CPU. В результате получилось обработать только 22 потока на вход с выдачей 88 потоков всех разрешений на выход. Нагрузка CPU — 4700%, т.е. было задействовано 47 ядер. Расход RAM — порядка 20Гб.

    Тест на CPU + GPU


    Кеш контекстов при запуске настроен как 0:23:23,1:23:23 — т.е. 23 контекста на энкодинг, 23 на декодинг для каждого GPU.

    С помощью GPU были декодированы 46 потоков 720p. Там же, на GPU был сделан энкодинг 46 потоков 480p. Далее на CPU был сделан энкодинг 360p, 240p и 160p — по 46 потоков каждого.
    Зафиксирована нагрузка 2100% CPU, 61% декодера, 16% энкодера.

    В дополнение был запущен энкодинг и декодинг 24 потоков на CPU, на каждый 1 поток — по 4 выхода, как и для GPU.

    Итого получилось 70 потоков на вход, 280 потоков на выход.
    Нагрузка: 4600%, 61% декодера, 16% энкодера, 30Гб RAM.

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

    4. Проблема с созданием контекстов в NVidia GPU


    Несколько слов о проблеме, которая не позволила нам обработать больше потоков на GPU.

    В конце прошлого года мы проводили тесты совместно с командой NVidia, с несколькими картами. При работе с несколькими GPU выяснилось, что создание контекстов сильно тормозит работу сервера — создание каждого нового контекста отнимало у карты всё больше времени. Если первый контекст создавался порядка 300мс, то каждый последующий прибавлял по 200-300мс и уже на третьем десятке контекстов создание нового занимало 3-4 секунды каждый. Когда сценарий транскодинга создается пользователем, предполагается, что он начинает работать сразу и без задержек, а это новое обстоятельство сводило на нет все преимущества в скорости Нимбла и давало задержки при создании контекстов, которые приводили к задержкам старта энкодинга.

    Сначала подозрение пало на Нимбл, однако потом мы сделали тесты с использованием ffmpeg, который предоставляет клиентам сама NVidia и результат оказался ровно тем же — GPU тратит всё больше времени на создание каждого нового контекста. В условиях, когда на сервере уже идёт транскодинг и надо запускать новые потоки на обработку, это сказывается на общей производительности и делает сервер просто непригодным к работе.

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

    Кроме того, контексты мало просто создать. При большом числе контекстов при включении любого сценария транскодирования, NVENC API начинает выдавать ошибки «The API call failed because it was unable to allocate enough memory to perform the requested operation.»

    Опытным путём получилось, что один GPU может запуститься и уверенно работать с 47 контекстами — и нет разницы, это контексты энкодера или декодера. Появилось предположение, что это связано с объёмом памяти на GPU. Сейчас там 16 Гб, если поставить карту с 24 Гб, есть вероятность, что контекстов можно будет сделать больше. Но это только теория, надо проверять, как уже упоминалось ранее. Полученные данные справедливы для конкретной модели GPU, другие карты надо тестировать отдельно.

    Именно ограничение на число контекстов ставит основную преграду при работе с большими нагрузками.

    5. Выводы


    Итак, целью тестирования было изучить эффективность GPU для обозначенного круга задач и выработать рецепты его правильного использования. Что получилось в итоге?

    Экономический эффект


    Выше мы увидели как отличается число потоков, которое можно обрабатывать на CPU и на тандеме CPU+GPU. Посмотрим, что это значит с точки зрения денег. За основу возьмём всё тот же Softlayer и их цены на аренду оборудования.

    • Конфигурация без GPU обойдётся в $819 в месяц. Здесь можно подобрать машину.
    • Конфигурация с GPU будет стоить $1729 в месяц для датацентра в Амстердаме, цены можно посмотреть здесь. При использовании GPU цена аренды сервера несколько возрастает, поскольку используется больший форм-фактор корпуса 2U. Экономический эффект возможно будет выше при покупке оборудования (но это требует серьезного анализа ТСО с учетом постоянного обновления линейки GPU NVidia).

    Теперь посмотрим результаты тестирования:

    Для FullHD 1080p

    • CPU без GPU: 16 потоков на вход + 80 на выход
    • CPU + GPU: 36 потоков на вход + 180 на выход

    Преимущество при использования GPU: 2,25x.

    Выгода от использования GPU: $819*2,25 — $1729 = $113 в месяц при аренде 1 сервера c GPU.

    Для HD 720p

    • CPU без GPU: 22 потока на вход + 88 на выход
    • CPU + GPU: 70 потоков на вход + 280 на выход

    Преимущество при использования GPU: 3,18x.

    Выгода от использования GPU: $819*3,18 — $1729 = $875 в месяц при аренде 1 сервера c GPU

    То есть при варианте аренды экономия вполне заметна. Это без учета скидок — в российском офисе IBM обещают скидки на аренду ресурсов в облаке по сравнению с представленными здесь ценами.

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

    Также не забываем о трафике и ширине канала — в представленные выше тарифы они включены в определенном объёме, но вам нужно будет выбрать опции под свои задачи, исходя из количества потоков, ожидаемого числа пользователей и т.п.

    Масштабирование


    Вариант с одной графической картой на сервер нам представляется более экономически эффективным, чем вариант с двумя картами и более. Как мы видим, декодер GPU всегда загружался больше, чем энкодер, но даже он оставался недогруженным из-за проблем с использованием контекстов. Если добавить вторую карту, декодер будет использоваться ещё меньше, энкодеры мы тем более не сможем загрузить на полную мощность, и всю работу по энкодингу по-прежнему нужно будет перекладывать на CPU, что будет неоправданно по деньгам. Вариант с двумя GPU мы тоже тестировали благодаря поддержке Softlayer, но из-за слабого экономического эффекта мы не приводим в статье подробности.

    Соответственно, для масштабирования нагрузки предпочтительнее добавлять новые сервера с одной графической картой, чем добавлять карты в существующие машины.

    Если количество входящих и исходящих потоков для вашего проекта относительно невелико — скажем, десяток HD потоков с небольшим числом разрешений на выходе, с относительно небольшим объёмом фильтрации, то целесообразнее будет использовать сервер без GPU.

    Стоит также обратить внимание на то, что объём RAM для задачи преобразования потоков — не так важен, как вычислительная мощность. Так что в каких-то случаях вы сможете сэкономить ещё и за счёт уменьшения объёма памяти.

    Заключение


    Представленное аппаратное решение — сочетание CPU и GPU Tesla M60 — отлично подошло для транскодирования живых потоков под большими нагрузками. GPU берёт на себя самые ресурсоёмкие операции — декодирование потоков и их кодирование в самые большие разрешения, тогда как средние и мелкие разрешения хорошо обрабатываются на CPU.

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

    Подробнее
    Реклама
    Комментарии 41
    • +1
      Вы могли бы сравнить производительность вашей системы транскодирования с ffmpeg+libx264? Интересует режим live потока, условно непрерывного.
      • 0
        По поводу в целом сравнения с ffmpeg у нас есть вот такая статья. Общий вывод — у нас производительность как минимум не хуже.
        • 0
          А можно прямой и честный ответ, вы под капотом libav/ffmpeg используете? Я полистал разные странички на вашем сайте, в том числе про лицензии, и у меня сложилось такое впечатление.
          • 0
            Мы используем код ffmpeg для отдельных операций, в частности для фильтров, но он составляет лишь малую часть кодовой базы транскодера. Основные преимущества нашего решения связаны именно с нашими наработками. Вот здесь мы описываем, чем такой подход выгоднее.
            В исходниках же самого сервера Nimble Streamer нет кода ffmpeg.
            • +1
              работа с nvenc идет без ffmpeg-а. Сам ffmpeg используется в фильтрах между декодером и енкодером если он нужен. Работа с libx264 тоже происходит напрямую.
              Причин тому несколько. Одна из них в том, чтобы явно контролировать вставку ключевых кадров из нашего кода. Вторая в том, чтобы иметь возможность контролировать/кешировать nvenc контексы, чего с ffmpeg сделать нельзя.
              • 0
                Декодер h264 сами писали, используете от NVIDIA, из libavcodec или ещё какой нибудь? Если от NVIDIA, то как боретесь с, скажем так, неидеальным исходником, в котором встречаются некорректные операции? А демуксеры свои?
                • +1
                  Декодер используем NVIDIA или ffmpeg. Когда встречается кривой кадр, который не получается раскодировать мы его пропускаем и продолжаем работать. Такое часто бывает в mpeg2ts потоках.
                  Трансмаксеры свои.
        • +1
          Аппаратный кодек для Nvidia работает на fixed function железке в составе GPU и/или задействует ядра CUDA? Ваши фильты по обработке пытались реализовать на CUDA?
          • 0
            На сайте NVidia пишут, что это делается не на CUDA.
            По фильтрам — часть из них при желании можно перевести на GPU в качестве опции, но пока это никто не запрашивал.
            • 0
              Снизит нагрузку на CPU и шину памяти между CPU и RAM, особенно если делать фильтрацию сразу в памяти GPU, до копирования кадра в RAM.
              • 0
                Разумеется, нагрузку это снизит. Просто каждой оптимизации — своё время. :) Мы пока не дошли до острой необходимости делать подобное. Вполне может быть, что дойдём и до неё.
          • 0
            Я далек от технологий потокового видео, поэтому вопрос: вашу систему можно использовать для стриминга на площадках?
            • 0
              О каких площадках идёт речь?
              • 0
                Ну тот же твич или ютуб. Просто мой комп явно слабоват для х264, приходится пользоваться NVENC или как там ее. Но качество не очень хорошее.
                • 0
                  Да, если вы закодируете поток, то с помощью Нимбла сможете его опубликовать по RTMP на эти сервисы.
                  • 0
                    А какие будут в итоге преимущества, если для чайника на пальцах?
                    • 0
                      Не совсем понял — преимущество чего перед чем?
                      • 0
                        Нимбла перед OBS. Или все одно и без разницы?
                        • 0
                          Это несколько разные виды софта. OBS — это источник потока, него можно передавать на Twitch, YouTube и даже на Nimble Streamer. В свою очередь с Нимбла поток передавать на другие сервера, а можно раздавать аудитории большого размера (этого OBS как раз делать не умеет).
                          • 0
                            То есть Нимбл тоже как стрим-программа? Тогда стоит попробовать. Просто по описанию я подумал что связано с серверной обработкой, возможно это облегчило бы нагрузку на мой CPU.
                            • 0
                              Конечно, пробуйте, задавайте вопросы.
                  • 0
                    off после бадабума осторожно смотрю на ускорение видеокартой. Только наблюдаю. Опыт был такой же —
                    https://geektimes.ru/post/76462/
                    Все недостатки «бадабума» были налицо: «убитые» цвета, общая мутность картинки, подергивания в динамичных сценах.

                    при сравнении результатов кодирования на видео и на процессоре были заметны явные дефекты при обработке видеокартой.

                    Хотя для стрима они не существенны.
                    /off
                    • 0
                      Ничего не могу сказать про кодирование VOD, да ещё неизвестными мне утилитами, да ещё с непонятными настройками энкодера. Но по ходу наших тестов мы не увидели дефектов, хотя специально отслеживали, и особенно тщательно отсматривали на пиковых нагрузках.
                      • 0
                        да ещё неизвестными мне утилитами

                        Видимо около 2009-го года Вы не интересовались темой конвертирования видео с использованием видеокарты. В свое время утилита произвела эффект бомбы, в ответ АТИ выпустила свою. Обе как оказалось «упрощали» себе задачу и часть информации из видео отбрасывали.
                        Badaboom — одно из первых приложений, которое начало использовать при кодировании видео аппаратные средства видеокарт NVIDIA с поддержкой CUDA.

                        NVIDIA в своём рекламном ролике хочет напомнить о том, что с помощью Badaboom и ускорителя GeForce с поддержкой CUDA можно кодировать видео для iPhone в 20 раз быстрее, чем с помощью процессора и стандартного ПО iTunes.

                        Конечно, для того, чтобы достичь такого огромного прироста нужно сравнивать хорошую видеокарту класса GTX 260 со средним 2-ядерным процессором. В случае более сравнения более медленного ускорителя с мощным 4-ядерным процессором разница будет не столь впечатляющей, хотя всё равно останется ощутимой.
                        • 0
                          Я могу отвечать только за то, что сделано конкретно нами :) Проблемы других приложений я не могу комментировать. Конкретно у нас артефактов иображения не было, мы это проверяли.
                          • 0
                            Артефакты не в том смысле как это понимают обычно, а в отличиях от оригинала, При тщательно сравнении результатов я увидел отбрасывание младших бит. Неприемлемо если речь о памятных домашних видеозаписях. Но хорошее решение для публикации онлайн — теряется шум, изображение становится «гладким», уменьшается битрейт.
                            • +2
                              На днях на reddit прочитал пост одного гражданина:
                              при NVENC по сравнению с x264 либо ухудшается качество (при сравнивом битрейте), либо надо задрать битрейт, чтобы получить на выходе сравнимое качество.
                              Самому интересно узнать как и насколько различается кодирование аппаратное/программное. Жаль видеокарты подходящей нет.
                              • 0
                                При нашем тестировании подобного эффекта не обнаружилось.
                                Нужно разбираться в конкретном случае с конкретным чипом и ещё лучше конкретной картой, смотреть настройки. Ну и пробовать на картах разного уровня, чтобы понять, что подойдёт для конкретной задачи.
                                • 0
                                  Я проводил эксперименты с кодированием давно, где-то после 2010. И мое мнение совпадает с озвученным в комментариях к статье https://habrahabr.ru/post/262309/
                                  — влияет исходник. Если это сырое видео (я экспериментировал с ускорением пережатия miniDV), то были потери которые для меня не приемлемы. Хоть и miniDV это и сжатие, но относительно низкое и я видел потери.

                                  А если же пережимать фильмы, ролики, то тут как комментарии erlyvideo
                                  Сырое видео очень мало распространяется и поэтому для интернета интересны прежде всего вопросы пережатия из одних сжатых форматов в другие.


                                  В этих видео уже все «потеряно» лишнее.
                                  • 0
                                    В случае живых потоков исходные данные «ближе», т.к. идёт преобразование на первом энкодере от камеры и дальше — нередко уже только транскодер для работы на конечную аудиторию.
                • 0
                  А если всё то же самое, но не на заоблачно дорогом «профессиональном» ускорителе прошлого поколения, а на обычной потребительской видеокарте?
                  • 0
                    Насколько помню, у потребительских десктопных карт есть ограничение по числу потоков на энкодинг видео.
                    • 0
                      А мне нужен только один поток.
                      Но для наглядности мне надо преобразовать FullHD (1920*1080) в последовательность кадров JPEG,
                      А каждый кадр JPEG в кадр BMP 1920*1080
                      Затем каждый кадр BMP 1920*1080 преобразовать в кадр ВМР 1440*1080, а его в кадр ВМР 720*480
                      И все кадры вывести на экран
                      • 0
                        В этом случае обычная карта вам наверняка подойдёт. Возможно даже вам она будет не нужна и справитесь только с помощью CPU. Надо проверять, теория тут плохой помощник.
                  • +1
                    В тестировании на CPU использовался ли Intel Quick Sync Video?
                    • 0
                      Нет, не использовался. У нас есть его поддержка в транскодере, но в данном случае мы проверяли работу именно GPU.
                      • 0
                        В таком случае, не получится, что при использовании Quick Sync на CPU будет большее количество потоков?
                        Если правильно помню, у коллег, занимающихся потоковым видео, Quick Sync показывал себя даже лучше, чем GPU. Правда, это были карточки не уровня Tesla.
                        • 0
                          Я вполне допускаю, что QS покажет себя очень достойно. Но как показала практика, всё нужно тщательно тестировать. Как видите, даже на топовом GPU мы натолкнулись на ограничения непонятного для нас свойства. С чем можно столкнуться у QS на подобных же тестах — я лично не могу сказать. Надо проверять и только тогда делать выводы.
                          • +2
                            Верно подмечено. Quicksync отличная вещь, но встречается только на desktop-ах и некоторых серверных процессорах E3. На практике мы пока работали только с quicksync на десктопах.
                            Если мы говорим про quicksync и подразумеваем desktop, то самый на мой взгляд выгодный вариант такой:
                            -Вставляем nvidia GTX. Ограничений по колличеству сессий на декодинг нет. Ограничение на 2 одновременные сессии енкодинга.
                            -Весь декодинг делаем на GTX.
                            -Весь енкодинг делаем на quicksync. Quicksync умеет создавать софтовые енкодинговые сессии когда кончились хардварные так что грузим процессор по полной.
                            -Если есть куда используем 2 енкодинговые сессии, которые поддерживает GTX.
                            И дешево и производительно получается.
                      • 0
                        При кодировании видео обычно используются операции с фиксированной и плавающей точкой одинарной точности (float). А с такими операциями прекрасно справится GTX 1080, которая будет значительно дешевле Tesla. Есть хостеры, которые предоставляют хостинг с «игровыми» видеокартами.
                        • 0
                          У таких карт производительность всё-таки значительно меньше и, кроме того, есть ограничение на число кодируемых потоков. Так что если нужно кодировать много — выгоднее будет взять «большую» карту.
                          По поводу хостеров. Во-первых, они ориентируются на разные классы задач, не только живое видео. Там и транскодинг VOD, и всякие приложения и сервисы с супер-фильтрами (типа Prism), и чисто математические задачи вроде обсчёта блокчейна.
                          Во-вторых, бывают случаи, когда с помощью поломаных драйверов обходится ограничение на одновременное число кодируемых потоков — так его можно немного увеличить. Мы слишком серьёзно относимся к вопросам лицензирования (вот здесь написано всё по этому поводу), чтобы воспринимать всерьёз такой подход.

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