Pull to refresh
12
Karma
0
Rating
Stas @fpn

Streaming video engineer

  • Followers 12
  • Following

Превращаем RTSP в WebRTC: сколько камер потянет сервер?

Ваш вариант немного более читабелен, да. Поправили, заодно добавили sudo там, где его не хватало

Превращаем RTSP в WebRTC: сколько камер потянет сервер?

Вам бы доку обновить по node_exporter-у https://docs.flashphoner.com/pages/viewpage.action?pageId=14256163И я вам помогу с этим https://gist.github.com/denisgolius/f9bebf21dd126391effab9fb5a992388 то, чем пользуюсь я, но некоторые флаги возможно лишние конечно.

Не видно принципиальной разницы, кроме версии (которая в документации приведена для примера) и явного перечисления флагов (которые и так включены по умолчанию https://github.com/prometheus/node_exporter#enabled-by-default)

Еще я бы советовал попробовать victoriametrics single инстанс которой может в разы больше, чем пара prometheus инсталяций

Поскольку этот инструмент декларирует совместимость с форматом Prometheus, со сбором метрик WCS не должно быть явных проблем

Превращаем RTSP в WebRTC: сколько камер потянет сервер?

Дело в том, что этот объем можно определить исключительно опытным путем, т.к. потребление ресурсов в зависимости от количества публикаций и количества подписчиков на каждый из опубликованных потоков растет нелинейно. Без транскодинга видео (то есть опубликовали H264 и забрали H264 в том же разрешении) будет транскодироваться только звук, если он есть в потоке, и если камера отдает звук не в PCMA/PCMU и Opus, но основную нагрузку при использовании WebRTC дает шифрование трафика.

Для простоты можно считать, что минимально рекомендуемая конфигурация (1 CPU, 2 Гб RAM, из них 1 Гб Java heap) гарантированно способна принять один RTSP поток и отдать его одному подписчику.

Нагрузочный тест для WebRTC микшера

Умеет, но пока не для продакшна. Поэтому пока рекомендуем использовать MCU микшер.

Кроме того, микширование больше грузит сервер, но меньше - каналы пользователей.

Мониторинг WebRTC стримов с помощью Prometheus и Grafana

Подскажите, а у вас стримы WebRTC всегда идут через сервер?

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

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

Можете уточнить какие метрики вы собираете непосредственно с клиента?

Непосредственно с клиента не собираются никакие метрики, только на стороне сервера.

Practical uses of WebRTC Canvas streaming

Спасибо за замечание. Поправили на более универсальный вариант.

WebRTC скриншаринг с авторизацией и плюшками

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

WebRTC скриншаринг с авторизацией и плюшками

У WCS есть настройка, позволяющая использовать нечетные порты, но по умолчанию она отключена, т.к. в этом случае могут не работать SIP звонки. Если SIP не нужен, то можно задействовать весь диапазон портов

Как сделать многоточечную WebRTC-конференцию MCU с записью и демонстрацией экрана в браузере

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

Как сделать многоточечную WebRTC-конференцию MCU с записью и демонстрацией экрана в браузере

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

Как сделать многоточечную WebRTC-конференцию MCU с записью и демонстрацией экрана в браузере

FreeSwitch дает более специализированное решение и предназначен для SIP, а WCS более универсален и работает с медиапотоками, которые могут быть, при необходимости, захвачены и из SIP звонков: 1, 2

Как сделать многоточечную WebRTC-конференцию MCU с записью и демонстрацией экрана в браузере

Откуда такая интересная классификация серверов?

Уточните, пожалуйста, где именно Вы видите классификацию серверов? В статье приведен список технологий. И да, эти технологии могут быть использованы совместно, но это усложнит примеры реализации, а статья предназначена, как писали раньше, «для широкого круга читателей»

Как сделать многоточечную WebRTC-конференцию MCU с записью и демонстрацией экрана в браузере

Правда нормальное API до сих пор не стандартизовано

Именно поэтому нельзя считать, что технология поддерживается. Пока нет четкого стандарта, ничто не мешает Google с успехом сломать однажды все предыдущие решения. В последних сборках Canary, например, они опять сломали аппаратное кодирование H264, на этот раз при захвате с канваса. Починят, конечно, но вопросы у клиентов появляются.
Вот, правда, что из этого поддерживает WCS — я не в курсе. Думаю, есть SFU которые умеют в vp9.

WCS уже умеет в ядре simulcast получать и раздавать для VP8 (полноценно) и H264 (тут с некоторыми ограничениями). Сейчас работаем над API и заготовками интерфейса, поскольку большинство клиентов хотят свой Zoom с фишками, но без лишнего труда. Скорее всего, в этом году будем выводить в продакшн.

Автоматизируй это, или Контейнерные перевозки Docker для WebRTC

Спасибо за ссылку.

Там обозначены две проблемы:

1. При разделении ресурсов CPU между контейнерами через cgroups, софт внутри контейнера может выбирать квоту, установленную планировщиком,
в результате чего возникает jitter, который негативно влияет на воспроизведение RTP потока.

2. Проблема с таймингами. В нашем случае не актуальна, т.к. RTP поток у нас не привязан к времени сервера.

Проблема с разделением CPU и Jitter действительно существует и не только в докерах. Гипервизоры также могут влиять.

Поэтому при запуске Docker-контейнера, мы назначаем контейнеру конкретные ядра CPU. В этом случае контейнеры не конфликтуют, нет упоминаемых квот. Сейчас проводим серию нагрузочных тестов докер контейнеров и они показывают хорошие результаты. Планируем выложить статью с результатами тестов. Судя по ним, докер вполне подходит для продакшена.

Jitter бывает и на железных машинах. В случае WebRTC он гасится адаптивным jitter-буфером, который работает на клиенте достаточно в широком диапазоне (до 1000 мс).

По поводу NAT. Можно просто выделить каждому контейнеру свой IP адрес. Тогда проблема с маппингом портов отпадает.

Автоматизируй это, или Контейнерные перевозки Docker для WebRTC

тайминги при обработке RTP могут поехать

Вот получили SRTP пакет от Chrome, например с timestamp 111222333. Далее передали этот пакет дальше по сети. Это тот тайминг, про который идет речь? Может ли он куда-то поехать?

Возможно вы имеете ввиду проблему видео энкодера, который при 30 FPS обязан выдавать не менее 30 фреймов в секунду и при просадках в производительности CPU/GPU начинает не успевать. Но это опять же не проблема Докера, а проблема производительности железа и ее надо обязательно мониторить чтобы не допускать таких просадок на каждом отдельном стриме.

Еще, что касается RTP пакетов, они не обязательно идут четко по времени энкодера, т.к. сеть не идеальна. Это все нормально отрабатывается буферами в WebRTC. Опять же, не важно в Докере или нет.

Automatize it, or Docker container delivery for WebRTC

Server can be used for:
— recording
— conversion from/to other protocols: RTMP, RTSP, HLS, MSE, VOD, SIP
— central stream management (admin can manage all streams going through the server)
— PNG slicing
— Transcoding
— Mixing
— Video frames interception and analyzing
— Injecting one stream to another
— Re-streaming from/to other servers

Автоматизируй это, или Контейнерные перевозки Docker для WebRTC

Для WebRTC транспорт по умолчанию — UDP (хотя и TCP можно, но это дает задержку и сводит на нет преимущества протокола), причем, в отличие от однопортовых RTMP и RTSP, заранее неизвестно, на какой именно порт подключится клиент. Отсюда и танцы сложности в настройке.

Автоматизируй это, или Контейнерные перевозки Docker для WebRTC

Это разумно. Но бывают и те, кто любит микросервисы, и, соответственно, используют докер для WebRTC и в продакшне. Для того и сделана пометка: одна чат-комната — один контейнер.

Автоматизируй это, или Контейнерные перевозки Docker для WebRTC

Не совсем так. Статья про WebRTC в докере. И да, на примере WebCallServer, хотя с той же Wowza проблемы с настройкой сети в докере будут ровно теми же, так что рекомендации можно применить к любому медиасерверу с поддержкой этого протокола.
1

Information

Rating
Does not participate
Date of birth
Registered
Activity