Как стать автором
Обновить
13
0
Stas @fpn

Streaming video engineer

Отправить сообщение

а если источник в RTMP? или у вас только WebRTC?

внутри CDN только WebRTC или SRT, от источника публикации это не зависит

у HLS и так задержка минимум несколько секунд

у Low Latency HLS (который у нас уже реализован, кстати) задержка около трех секунд, что сопоставимо с RTMP и WebRTC over TCP

Как я понимаю, у вас на Edge ведь горизонтальное масштабирование, то есть разные зрители одного стрима могут быть на разных Edge серверах?

да, это так.

но эта архитектура затачивалась под WebRTC зрителей в первую очередь. как правило, мы рекомендуем выделять в CDN отдельные Edge сервера под WebRTC и HLS зрителей, это позволяет избежать лишнего транскодинга аудио на Edge.

и мы даем не готовое решение, а конструктор. т.е. разработчик может выделить HLS Edge, и уже с него проксировать.

В данном случае HLS нарезается только на Edge серверах, а между Origin и Edge бегает WebRTC по UDP, что дает меньшую задержку по сравнению с проксированием HLS. Поэтому нет и оверхеда: Origin работает только на публикацию, Edge - только на раздачу зрителям. Можно еще и транскодирование вынести на отдельные железные сервера (транскодинг желателен для WebRTC стримов, чтобы выровнять FPS и keyframe интервал, HLS плееры к этим параметрам критичны, особенно native в Safari.

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

Вам бы доку обновить по 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 не должно быть явных проблем

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

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

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

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

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

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

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

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

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

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

В данном случае комментарий выглядит достаточным, большинству пользователей из коробки хватает диапазона медиапортов по умолчанию. На случай, если потребуется тюнинг, есть документация.
У WCS есть настройка, позволяющая использовать нечетные порты, но по умолчанию она отключена, т.к. в этом случае могут не работать SIP звонки. Если SIP не нужен, то можно задействовать весь диапазон портов
В нашей практике бывали случаи, когда клиенту приходилось разделить CDN на два сегмента по континентам, отдельно для публикаций из Америки и отдельно из Европы, иначе канала между датацентрами на континентах не хватало для толстых (4K) потоков в нужном количестве. А это уже архитектура решения.
Надеюсь, теперь достаточно ясно, почему мы отнесли и выбор технологии бродкастинга к архитектурным задачам?
Почему же?
Например, использование этих технологий снижает требования к каналу зрителя, но повышает к каналу паблишера, он должен отдать все варианты качества. А выбор каналов — это уже архитектурная часть, т.к влияет на выбор хостера/датацентра/сервера.
А если мы будем выходной поток микшера отдавать в различных вариантах качества, это опять же влияет на выбор сервера, т.к. требует более мощного процессора или GPU, смотря на чем кодировать.
FreeSwitch дает более специализированное решение и предназначен для SIP, а WCS более универсален и работает с медиапотоками, которые могут быть, при необходимости, захвачены и из SIP звонков: 1, 2
Откуда такая интересная классификация серверов?

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

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

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

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

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

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

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

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

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

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

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

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

Еще, что касается RTP пакетов, они не обязательно идут четко по времени энкодера, т.к. сеть не идеальна. Это все нормально отрабатывается буферами в 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
1

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность