Работа с roomApi через CDN

[Artem]

Мы начинаем трансляцию через origin создавая комнату через roomApi, и пытаемся подключится к этой же комнате через edge, но комната на edge пустая(её не существует). Как сделать так что бы комнаты с origin были видны на edge?

 

[Max]

Добрый день.
RoomApi использует встроенный бэкенд WCS, поэтому работает только в пределах одного сервера. Чтобы использовать обмен сообщениями между пользователями в CDN, необходимо реализовать собственный бэкенд с обработкой /OnDataEvent и рассылкой статусов и сообщений пользователям при помощи /data/send

 

[vasyap]

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

 

[Max]

Пожалуйста, поясните еще раз ваш сценарий:
- на Origin серверах организуются видеоконференции
- на Edge серверах пользователи смотрят потоки этих конференций
При таком сценарии лучше использовать не RoomApi, а MCU микшер, по микшеру на комнату на Origin серверах. Разумеется, мощность Origin серверов придется выбрать, исходя из требований микширования: 1 ядро CPU на кодирование 3 выходных потоков 480p или 2 потоков 720p или 0,75 потока 1080p, памяти от 64 Гб.
Тогда пользователи на Edge просто запрашивают выходные потоки микшеров для просмотра. Список микшеров ведется на Вашем собственном бэкенде, REST хуки при этом тоже выглядят необязательными.

 

[vasyap]

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

 

[Max]

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

В последних сборках, начиная с 5.2.645, возможности настройки микшера реального времени были расширены. Посмотрите, возможно, вас это устройит.
Если Вам необходима более тонкая кастомизация, тогда от микшера придется отказаться, но это создаст большую нагрузку на каналы зрителей, поскольку каждый зритель будет играть все потоки выбранной конференции. Также увеличится нагрузка на бэкенд, поскольку необходимо будет вести списки всех опубликованных потоков, сопоставлять те потоки, которые относятся к одной конференции (по именам или кастомным данным), и передавать на фронтенд зрителям, чтобы те могли запрашивать воспроизведение потоков. Использование RoomApi нецелесообразно, т.к. оно не предусматривает кастомный бэкенд и работает только со встроенным бэкендом сервера.

 

[vasyap]

В последних сборках, начиная с 5.2.645, возможности настройки микшера реального времени были расширены. Посмотрите, возможно, вас это устройит.
Если Вам необходима более тонкая кастомизация, тогда от микшера придется отказаться, но это создаст большую нагрузку на каналы зрителей, поскольку каждый зритель будет играть все потоки выбранной конференции. Также увеличится нагрузка на бэкенд, поскольку необходимо будет вести списки всех опубликованных потоков, сопоставлять те потоки, которые относятся к одной конференции (по именам или кастомным данным), и передавать на фронтенд зрителям, чтобы те могли запрашивать воспроизведение потоков. Использование RoomApi нецелесообразно, т.к. оно не предусматривает кастомный бэкенд и работает только со встроенным бэкендом сервера.

Этих настроек нам не достаточно.

По поводу нагрузки на каналы пользователей - у нас просто иначе устроен наш плеер MCU, там один большой плеер (для говорящего в настоящий момент) и несколько маленьких по бокам. По идее, потоки в маленькие плееры можно попробовать запускать через транскодер, для понидения качества и fps, чтобы разгрузить канал пользователя.

 

[Max]

По поводу нагрузки на каналы пользователей - у нас просто иначе устроен наш плеер MCU, там один большой плеер (для говорящего в настоящий момент) и несколько маленьких по бокам. По идее, потоки в маленькие плееры можно попробовать запускать через транскодер, для понидения качества и fps, чтобы разгрузить канал пользователя.

В этом случае Вам в CDN потребуются транскодеры. Профили транскодирования необходимо настроить на Edge серверах. Отметим, что fps фильтр рассчитан прежде всего на стабилизацию и повышение fps, успешные внедрения для случаев понижения fps нам клиенты пока не описывали. Большинство клиентов для снижения нагрузки на каналы пользователей понижают разрешение и битрейт. Например, если на Origin заходит поток 1080p с битрейтом 2500 кбит/с, профиль транскодирования для разрешения 240p выглядит примерно так

 -240p:
  video:
    height : 240
    bitrate : 300
    gop : 50
    codec : h264
    codecImpl : FF

Отметим, что при смене отображения (говорил один участник, затем говорит другой) придется либо запрашивать оригинальный поток, что даст определенную задержку на проключение, либо заранее запросить на клиента как оригинальные, так и транскодированные потоки всех участников, что резко снижает эффект от транскодирования. Можно предложить такой вариант: транскодировать потоки с высоким качеством, например, по профилю Main с пресетом fast

 -240p:
  video:
    height : 240
    bitrate : 300
    gop : 50
    codec : h264
    codecImpl : FF
    profile : 77
    preset : fast

Это потребует мощных физических серверов для транскодинга, но качество транскодированных потоков будет достаточным, чтобы масштабировать их в браузере в большой video элемент. Тогда на клиента можно запрашивать только транскодированные потоки и тем самым уменьшить нагрузку на канал.
В любом случае, на клиенте необходимо знать имена всех запрашиваемых потоков и названия профилей. Таким образом, настройка клиента также ложится на бэкенд.

 

[vasyap]

успешные внедрения для случаев понижения fps нам клиенты пока не описывали

Я уже настроил для обычной One-2-Many видеоконференции, все работает отлично, fps (а вместе с ним и битрейт) вполне ок понижать до 15 (а на превью и до 10) фпс без особой потери качества для наших случаев.

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

 

[Max]

Добрый день.

Интересно, можно ли наколхозить собственный MCU микшер, например, в виде запущенного в Puppeteer (безголовый хром) кастомного плеера, который играет нужные потоки и прямо сам из себя захыватает и перепубликует на Origin финальный поток, будет ли смысл копаться в этом направлении?

Можно опубликовать потоки на канвас и этот канвас затем захватывать, но:
1. Это потребует ресурсов системы, где выполняется браузер (фактически транскодинг переносится в браузер в этом случае)
2. Невозможно управлять битрейтом и разрешением захваченного потока: разрешение будет всегда соответствовать размерам канваса, битрейт можно крутить только на стороне сервера
3. Могут быть сложности с переключением стримов главный/второстепенные
Похожим путем пытались идти в этой теме, и пришли в результате к микшеру

 

[Max]

Кстати, можете попробовать реализовать собственное размещение картинок в микшере, написав плагин на Java. Главный поток можно определять по фиксированному префиксу/суффиксу/подстроке в имени, имена потоков передаются в функцию computeLayout()

 

[Max]

Добрый день
В сборке 5.2.710 добавлена возможность настройки размещения картинки экрана в микшере, в том числе и по центру

mixer_desktop_align=CENTER

(большая картинка в центре и маленькие по бокам). Документация по этой возможности здесь.