Чем закончилось дело
Была собрана на двух камнях xeon E5-2690v4 (28 ядер с HP * 2 = 56 ядер при частоте
2.6) + Nvidia Quadro P2000 + плата Blackmagic Duo 2 на 4 SDI
По изначальным планам мы хотели поставить туда Windows 10, распилить по RDP на 4 машины. Пока все настраивалось пришли к выводу вытащить камни 2690 и использовать их в другом месте, а взамен поставили 2 камня младшие 2630v4 (20 ядер с HP * 2 = 40 частота
2.2)
Сначала все было хорошо, но уперлись в неприятную проблему. При подключении по RDP пользователю есть выбор как передавать аудио. Либо играть на устройстве которое подключено, либо играть на устройстве основном. Если выбрать на котором подключено, то аудио-драйвера не отображаются в программах вещательных. Т.е что-то типа стандартное устройство бла-бла-бла. Если выбрать на основном начинается беда с тем, что можно случайно все сломать. Много чего перепробовали, правили реестр и искали решение, в итоге плюнули т.к посчитали что это уже костыльный костыль, притом насколько это стабильно будет вообще не понятно.
Пока все это тестилось, я провел стресс тест кодирования. Основной вопрос был потянет ли и сколько потоков. После этого стресс теста собственно и принято решение поставить камни помладше. Результаты:
Один поток 1080p@60
slow High keyframe 1 h.264 (на одном процессоре Xeon 2630v4) дает загрузку 8%
Один поток 1080p@60 High keyframe 1 Nvenc (на видеокарте quadro p2000) дает загрузку 10%
Отвечая на свой вопрос в самом начале, потянет Macpro или нет – потянет. Я выделил режим кодирования slow. Обычно все кодируем в формате veryfast. Т.е переводя на русский язык ОДИН процессор xeon 2630v4 может перемолоть 1080p@60 в режиме slow 10 потоков. В режиме veryfast там загрузка дай бог 1-2%. А нам в задаче вообще нужно 30 кадров в секунду и не такие сцены, которые стоит обрабатывать в slow режиме
Теперь дальше. Решили использовать метод которые многие сочтут неадекватным, но он для нас оказался решающим. Мы поставили Vmware Esxi 6.5 и в режиме Passthrought VGA пробросили карту на VM Windows. Я делал это сам и удивлен, насколько все просто. Все же я не технарь, но за 1 час по инструкциям все поставил.
На этом месте хочу пояснить чем обусловлен выбор карты Quadro P2000 (типа можно было обойтись Geforce картой)
Во-первых тут речь шла о более чем одном потоке nvenc, есть вот такая табличка:
https://developer.nvidia.com/video-encode-decode-g...
Выбрана была самая дешевая карта с Unlimited и более менее свежая.
Во-вторых обращали внимание на то что она занимает один слот. Есть куча костылей обойти лимит на игровых картах Geforce. Но все эти костыли не для продакшена.
В третьих есть еще вопрос энергопотребления. Мы платим за электричество. Тоже самое на Geforce нам бы обошлось в дополнительные деньги на блок-питание + около 42тыс в год в деньгах на электричество. Да мы тут взяли на досуге и посчитали ;)
С учетом изменившейся схемы, а именно установки гипервизора и распилом машины на 4 части с выбором видяхи мы прогадали только в том, что можно было купить более младшую модель P400. Ну, да ладно.
Подведем итоги, как все выглядит и что получилось.
Сервер: Dual Xeon E5-2630V4 + 64RAM ECC Reg + Blackmagic Duo 2 + 3 видеокарты Nvidia Quadro P400 + 1 видеокарта P2000
Базовая операционка Vmware Esxi 6.5
4 Windows 10 Pro c Passthroght VGA. У каждой своя видеокарта в монопольном доступе.
1 Ubuntu 16.04 c Passthrought Blackmagic. Операционке отдана карта Blackmagic полностью, там собран ffmpeg который порты SDI конвертирует в NDI (это довольно свежий стандарт без потери качества для передачи по сети). Потом NDI ловят машины на Windows 10 Pro и уже дальше переваривают. Линукс потому что надо танцевать с бубнами чтобы собрать ffmpeg + NDI под видной. На linux это делается одной командой, на винде надо курить мануал. Очень удобно то, что операционки сидят на одном виртуальном интерфейсе. Там действительно задержки нет.
Все это обошлось в сумме по деньгам в 200к рублей (с винтами, корпусом). По итогу имеем 4 машины полноценные в одной, точнее 3 рабочих станции для вещания которые 4K60 потянут при желании. Жрет это все когда включаешь кодирование на всех с загрузкой 25% на оба камня – 520 ватт.
Сейчас последние всякие стресс тесты делаем, для запуска в продакшен. Хотя многие оно уже прошло. Порадовало на гипервизоре перезагрузка без зависание PCI-e видяхи. Реально спасение
Старое до сборки, но актуальное
Я напишу ответ. Ночь сиденья с людьми дало свои плоды и в принципе мы нашли решения. А мысли будут может полезны по этой теме кому-то
1. Мы пытались выбрать комплектующие под машину с двумя зионами (Xeon). Оказалось это реально не тривиальная задача. Нам нужна была плата с двумя камнями + ATX корпус (т.к видяха должна встать) + нужны в определенном количестве PCIe 4x слоты. Таких плат подходящих пот v3/v4 процессоры мало. v3/v4 выбираются потому что память под более старые модели тупо придется по блошиным рынкам собирать. Уже с такой частотой низкой памяти не взять. Плат нашли всего 3 по подходящим условиям, сидели фотки смотрели чтобы точно вошла видяха и остальные платы. Дополнительное усложнение – некоторые PCI меняют режим работы при определенных условиях. Вообщем жопа со всем этим. Машина с двумя камнями у нас получилась 189 тыс рублей, бенч общий 26к. Т.е выше был диалог на эту тему и я был прав. Но я все равно рад что диалог состоялся, т.к в нем родилась идея найти возможность перенести все на GPU
2. Сегодня-Завтра на тестовой слабой машине i5 + Nvidia с core Pascal мы прогоним тест. Самое ресурсоемкое и что может ввести любой процессор в пике - изначальное кодирование HDMI/SDI RAW сигнала с карты захвата в что-то типа h.264 со всеми плюшками. Конкретно OBS делать это не умеет на базе видяхи, а вот ffmpeg кушает nvec на милую душу. Тут сразу возникает нюанс – сколько конкретная карта может вытягивать потоков. C ffmpeg все довольно просто – в крайнем случае можно задать конкретно какую видео-карту использовать, но в изначальной задаче был риалтайм обработка (графика / скэлинг) и посути мы должны получить 2 разных потока по содержанию. Один чистый, другой с обработкой.
Тут на беглый вид рисуется схема:
=> ffmpeg nvidia => ( RTMP для деления )
1. ffmpeg отправляет сразу на сервер без сжатия откуда всё уходит по сервисам с нужным сжатием
2. Забираем поток софтом vMix, накладываем эффекты/скэлинг и дальше на тот же сервер
vMix тоже умеет работать с nvidia (ну, он собственно делает тоже самое что ffmpeg). Софтина платная, но для этих задач вроде не так дорого, а гибкость зашкаливает
В итоге получается 2 чистых кодирования на машине куда подключена камера
И да все на базе винды.
Остается момент с тем, что vMix насколько я понял умеет выбирать видео карту которую надо использовать. Но это последняя миля. Т.е ты не можешь запустить на одной машине больше vMix. И встает проблема, что либо собирать маломощные машины с 1 видяхой, либо рисовать костыль формата 3 видяхи в одном + карта захвата и каким-то чудесным образом все выруливать. Можно вырулить еще 2-мя машинами в каждом по две видяхи. Но опять же по тому же сайту vMix i7 простой + nvidia 1080 вытягивают 4 входящих потока
3. И не могу не вспомнить про macpro. Эта же схема через ffmpeg и нвидиа видяхи. Она будет стоить чуть дороже, но будет работать. Две видяхи через Thunderbold box (1000баксов), но можно и макпро взять на эту штуку дешевле.
пока считаем и думаем что будет менее нагромождено по оборудованию. У macpro не будет конечно vMix, но OBS точно зацепит. Их всего 3 понадобиться. Общие видяхи вытянут webgl, проц вытянет поток уже сжатого ffmpeg на видео потока. Вообщем сейчас на винде прокатим и будем думать, как жить.