rPman

jitsi meet - не p2p но серверную инфраструктуру запускают у себя. Между клиентами связь прямая. На основе webrtc

У тебя очевидно не хватает производительности железа - либо сетевой канал перегружен (т.е. буквально больше 9 видео с выбранным битрейтом забивают весь канал), либо процессор и видеоускоритель, через который браузер декодирует видео.

Т.е. прежде чем что то решать, нужно четко понять, что именно является узким местом. Убедись что у тебя процессор не на 100% нагружен. Оцени нагрузку на сеть.

Варианты решения:
* уменьшить битрейт, уменьшить разрешение видео, уменьшить fps видео - это поможет как с сетью так и нагрузкой на процессор
* проверить наличие драйверов на видеокарту, бывает что идущие с операционной системой поддерживают ускорение на базовом уровне и его не хватает для декодирования 16 видео (это очень высокая нагрузка даже с низким разрешением видео)
* установить более мощную видеокарту (кстати этот вриант потребует исследований)
* поставить промежуточный сервер декодер (на базе того же ffmpeg, у него есть ограниченная поддержка gpu) который будет собирать твои видео в матрицу и выдавать единое видео, как частный случай не все 16 а по 4 видео. Дело в том что одно видео с высоким битрейтом и разрешением потребует меньше ресурсов чем несколько видео с суммарно таким же битрейтом и разрешением (если считать по количеству пикселов)... там зависимость нагрузки не линейная.
Как частный случай, просто перекодируя поток из тяжелого высокоэффективного кодека в какой-нибудь mjpeg можно неплохо снять нагрузку с итоговой машины (советую поперебирать кодеки), но высоких fps такой подход не даст.

Вложенные подключения (используй дополнительного пользователя windows), т.е. подключаешься к серверу по rdp дополнительным пользователем, а затем в этой сессии запускаешь подключение к целевому пользователю и в ней запускаешь нужную тебе программу, затем отключаясь от первой сессии, вторая остается подключенной.

При использовании терминального сервера так можно делать много одновременно работающих приложений

Самое простое - torrent
vlc умеет их скачивать и проигрывать, даже на лету (есть плагин есть сторонние версии, можно не vlc наконец). Так же никто не мешает загружать торент отдельным приложением.

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

Достоинство torrent - максимально эффективный способ копирования большого файла на огромное (тысячи и сотни тысяч компьютеров) с учетом проблем провайдеров и т.п.

p.s. webtorrent, расширение протокола (добавлено в libtorrent), поддерживается нормальными торент клиентами, в т.ч. консольными (те что можно запускать на сервере без GUI, точнее с веб-интерфейсом типа deluge), позволяет не только загружать и просматривать торенты в браузере, само собой поддерживается проигрывание на лету

Попробуй настроить wireless display receiver linux и подключить к нему свое устройство, транслирующее на этот монитор твой 4k контент.

например https://github.com/albfan/miraclecast и пиши изображение со своего монитора.

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

Так же есть аппаратные hdmi энкодеры, используй их

Может ли OBS так делать? - да, в потоке есть место куда сложить отпечаток.
Делает ли? - не знаем, и чтобы ответить на вопрос нужно будет реверсить код и анализировать трафик.

НО задайся вопросом, зачем им это делать? случайно так не получится, необходимо чтобы стриминговая платформа как то договорилась с разработчиками OBS об этом.

p.s. исходники программы открыты

поднимай свой сервер на основе какого-нибудь опенсорс проекта
гуглить: opensource webrtc rtmp

легко не будет

настраиваешь свой сервер, который будет обрабатывать push notification запросы от гугла
https://developers.google.com/youtube/v3/guides/pu...

В центре снизу есть 'Микшер аудио' это буквально смешиватель звука, позволяет смешивать звуки от разных источников - микрофона и звуков, генерируемых системой.

obs смотрит включенные источники звука в системе, включай и отключай нужные в панели управления - звуки

Самое 'простое', установить на сервере ffmpeg и используя простую публиковать видеопоток в нужном формате
гуглить ffmpeg webcam video streaming
например вот

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

я в похожей ситуации делал 4х4 экран, еще и рулил ими, скриптом менял когда надо на что.

p.s. железо не справляется, а какой битрейт у потока?

Не пользоваться windows media player, на столько же ужасной программы еще поискать нужно...

Рекомендация, установи k-light mega codec pack в поставке с которым идет media player classic

Универсально - только запись с экрана

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

Протокол собственный

все зависит от его реализации

Кодирование потока надеюсь у вас специализированные железки или ip-камеры, потому как иначе такой поток не всякий сервер сможет обработать (можно сколхозить на базе nvidia gpu что-нибудь).

Все остальное не добавляет никаких особых требований, настоятельно рекомендую собрать и протестировать уменьшенную версию решения с 1-2 камерами, скорее всего каждая будет требовать десяток другой ram и процент от ядра процессора.

300+10 потоков умножаете на битрейт, плюс 30% получаете требования к дисковой системе. Обычные дешевые hdd дадут порядка 100мбайт/сек (помним что линейная скорость у hdd дисков не равномерная и кратно падает при нелинейном доступе, т.е. во время просмотра роликов, и то, если оттюнить файловую, к примеру увеличить параметр read-ahead), т.е. при 8мбит/с на камеру к примеру позволит на диск писать не больше 100 потоков а если одновременно и читать, то в разы меньше. Я видел системы, сколхозенные на windows машинах, они захлебывались на паре десятков потоков на диск. Так что рекомендую linux,

Можно добавить промежуточный ssd буфер, на который будет производиться запись с камер, а уже с него паралелельным скриптом чанки видео переносятся на hdd, при просмотре роликов во временном интервале, пока они влезают на ssd, особого замедления не будет, и да скорость работы с ssd нужно брать в худшем (делить на 2 от худшей скорости записи на синтетических тестах, после полной записи всего объема на диск и помнить о быстрой выработки ресурса записи в таком режиме)

Если просмотр роликов из истории не носит регулярный характер, можно промежуточный диск использовать обычный hdd, в этом случае на время просмотра роликов скорость переноса с буферного диска на основные может не поспевать за скоростью всего потока, так что размер этого буферного диска определит, как долго можно смотреть эти ролики (нужен соответствующий софт, следящий за этим и останавливающий просмотр чтобы не потерять данные).

raid0 дополнительную нагрузку на процессор не дает, и позволит примерно в sqrt(n) раз ускорить работу итогового устройства (n - количество дисков, и да, хоть на синтетических тестах линейная скорость возрастает n-крат, случайный доступ при просмотре роликов убьет весь этот бонус)

raid5-6 может добавить требований к процессору, но незначительно, один 100мбит поток примерно кушает половину нагрузки ядра средней современной машинки

raid0 - - mirror нагрузки не создает, т.е. если внезапно скорости процессора будет не хватать, можно будет за счет уменьшения эффективности хранения освободить чуток процессора от raid5

Теперь самое главное, с вашей нагрузкой по сети выходите за границы гигабита (порядка 2.5гбит), что заметно повышает стоимость железа (10гбит сетевые карты кратно выше в цене как на стороне сервера так и вся сетевая инфраструктура), поэтому вполне возможно что 2-3 независимых сервера, даже размещенных в разных помещениях (очень может оптимизировать физически сеть) позволят оптимизировать итоговую стоимость решения, по сравнению с очень мощным, размещенным в одном месте.

никак

p.s. в obs можно в качестве источника указать конкретное окно приложения
так же можно собрать экран источника из нескольких экранов, определив их размер и положение

таким образом можно записать на видео сразу несколько окон приложений, размещенных например мозайкой.

Когда то достаточно давно в пределах локальной сети управлял двумя плеерами (один запускался ради звука, другой ради изображения - вот такой изврат был) mplayer с помощью его api (тогда это было что то типа отправки команд в пайп, я кидал одной командой локально и по ssh старт и паузу, правда чтобы нивелировать проблемы с рассинхронизацией из-за разной скорости машин, дополнительно отправлял seek на начало сразу после запуска на обеих машинах)ю

Сейчас у того же VLC есть http api, есть куча утилит для remote control и прочее, к тому же не думаю что запустить два curl на разные машины в локальной сети или через ssh большая проблема.

30fps без gpu ускорения сможет потянуть не каждый сервер, либо разрешение экрана будет очень низким, и ни о каких HD, FullHD и тем более 4к вообще речи не будет идти.

Чтобы не изобретать огород, используйте безголовые xserver, как минимум пара реализаций уже давно существуют, а дальше по накатанной, стримьте готовыми инструментами экран.

Что значит вылетает проигрыватель? если он завершает свою работу, ну так запускайте его в бесконечном цикле

Я видел в каком то автобусе сделали, если приложение трансляции рекламы вылетело - идет перезагрузка (там тупо gentoo была, даже картинку не вставили шел чистый linux лог), на ребут уходило 30 секунд (полагаю так решили именно аппаратную проблему).

p.s. не обязательно пытаться следить именно за экраном, у работающего проигрывателя есть типичная нагрузка на процессор и диск, если она на долго сильно меняется - вот вам сигнал на перезапуск.