буфер для WebRTC

KonstantinK · Aug 9, 2018

подскажите есть ли возможность добавить буфер для WebRTC ? у нас часто бывает ситуация что можно пожертвовать Real Time ради качества

Max · Aug 10, 2018

Уточните, пожалуйста, следующее:
1. Какая версия WCS используется?
2. Что является источником стрима, как организована трансляция?

Max · Aug 10, 2018

WebRTC в браузере не дает настроить буфер и работает адаптивно.
Поэтому нужно смотреть как именно идет трафик чтобы предложить какие-то способы сглаживания.

KonstantinK · Aug 10, 2018

1) Web Call Server 5 v. 0.5.28.2747 - 5.0.3300
2) мы захватываем камеру и десктоп в браузере и передаем через ваше js API
у нас построен вебинар в котором транслируется на много клиентов (до 500) и если модераторы понимают что им нужен стабольный канал и как то за этим следят, то не у всех клиентов хороший канал, и провалы приводят к зависанию изображения, на камерах еще не так часто происходит из-за небольшего количества данных, а с десктопом все гараздо хуже.
предыдущая версия у нас была построена на Wowza и RTMP и за счет буфера эта проблема сглаживалась,
если можно настроить буфер на сервере для того что бы сгладить проблему у клиентов, нам это очень помогло бы, по крайней мере можно было бы подстроить и найти оптимальное соотношение между RealTime и стабильностью стрима

Max · Aug 13, 2018

Для того, чтобы найти решение, давайте будем двигаться по пути уточнения Вашего сценария. Правильно ли мы понимаем, что:
1. Модератор (ведущий вебинара) публикует на сервере по WebRTC изображение с камеры и со своего экрана (итого 2 потока). Модератор один или их может быть несколько?
2. Клиенты забирают поток с сервера по WebRTC, каждый по два потока. Публикует ли что-то (видео, аудио) сам клиент, или только получает?
3. Какое именно API используется? RoomApi (чат-комнаты), или клиенты подписываются на поток?

Max · Aug 14, 2018

Нам нужно воспроизвести проблему в тестовом окружении.
Например:
1. Опубликовать два потока на сервер, имитируя 2 ведущих.
2. Используя нагрузочный pulling, подключить 500 зрителей к этим двум потокам.
3. Опубликовать один поток на сервер (поток участника вебинара) и раздать его на эти 500 зрителей.
Здесь нам важно понимать какие настройки, кодеки, разрешения вы используете для ведущих и для зрителей.
Какие настройки на стороне сервера.
Например, если у вас все 500 зрителей вебинара публикуют поток, то у сервера может просто не хватить входящей полосы.
Или если участник публикует поток 720p, а канал у него позволяет максимум 320x240.
Возможно поможет уменьшение битрейта для участников или что-то еще.
Нужно понимать пошагово как работает ваше приложение.

KonstantinK · Aug 14, 2018

1) количество модераторов мы не ограничиваем, обычно от 1 до 4 модераторов могум вещать видео с веб камеры, и один из них может транслировать десктоп, у нас вся работа идет через браузер поэтому мы используем flashphoner.js для управления потоками на медиа сервер и от медиасервера к клиентам. Клиентов (гостей) может быть до 500 (в прошлой версии на Wowza + RTMP у нас были такие пакеты, в новой версии у нас было до 350).
2) клиенты забирают с сервера все потоки, еоторые там есть для его вебинара по WebRTC в браузере через тот же Flashphoner.js, у нас клиенты тоже могут вещать камеру.
3) у нас backend хранит всю информацию необходимую для вебинара а клиенты просто получают список id потоков, и на каком сервере они находятся и сами идут за потокоами (да, клиенты подписываются на поток).
Некоторые из наших давних клиентов, которые пользовались версией на Wowza, иногда жалуются что "изображение с камеры зависает, а в старой версии такого не было", но звук продолжает воспроизводиться.
Эта проблема возникает, когда резко увеличивается потеря пакетов, если с камерой это еще не так часто происходит, то с десктопом вообще не получается добиться более менее стабильной работы даже на 5-7 FPS, Экран захватываем с помощью плагина "Flashphoner Screen Sharing".

KonstantinK · Aug 14, 2018

пока канал стабильный, работает хорошо, но как только канал проседает и резко растет потеря пакетов, то поток проседает и после этого медленно восстанавливается.
Подобную ситуацию удалось улучшить для модератора при отправке потока на сервер с помощью установок min/max bitrate в constraints, в этом слечае браузер держит канал и не дает опуститься ниже минимального битрейта - следовательно не приходится потом его долго подымать, и не подниматься выше максимального - не держит канал больше чем нужно для передачи потока, есть ли возможность указать mix/max bitrate для клиентов, может это сгладит провалы и долгое восстановление потока.

Max · Aug 15, 2018

Попробуйте указать желаемый битрейт и разрешение видео в constraints для клиентов (см описание примера Media Devices), например:

Code:

    previewStream = session.createStream({
        name: streamName,
        constraints: {
             audio: true,
             video: {
                   width: 320,
                   height: 240,
                   bitrate: 100
             }
        }
        ...
    });
    previewStream.play();

При этом на сервере включится транскодинг, что несколько увеличит нагрузку на сам сервер, пропорционально количеству подключенных клиентов.

Max · Aug 16, 2018

Включение транскодинга на сервере при большом количестве клиентов сильно увеличит нагрузку. Поэтому будем дальше искать возможные решения.
Вы ограничивали битрейт в constraints для публикующих клиентов (как мы понимаем, их мало, но они есть)? Т.е. задавать ограничения нужно для всех, кто публикует потоки, а не только для модераторов.
Еще уточните, пожалуйста:
1. Какой кодек Вы используете?
2. Каков объем оперативной памяти на сервере?
3. Версию сервера Вы указали ранее. Не пробовали ли Вы обновиться до последней версии в ветви 5.0, или до 5.1?
Есть предположение, что в Вашем случае на работу сервера может влиять сборщик мусора (Garbage Collector) JVM, в результате его работы, например, UDP-пакеты могут теряться в очередях. Чтобы мы могли понять, как работает GC на Вашем сервере, приложите, пожалуйста, здесь или отправьте на почту logs@flashphoner.log:
1. Файл настроек WCS_HOME/conf/wcs-core.properties.
2. Логи WCS_HOME/log/gc_core.log, желательно в то время, когда у клиентов резко падает качество.

KonstantinK · Aug 16, 2018

да мы пробовали включать транскодинг, и получалось что транскодинг одного потока съедал примерно одно ядро (или пол физического ядра), многовато.
у нас скрипт, который вещет, один для всех, поэтому для сервера не имеет значения кто вещает, приходящий на сервер поток всегда ограничен max/min битрейтом. Сейчас пробую добавить max/min битрейт для получателей потоков.
1) мы используем h264, VP8, VP9 вроде в чем-то лучше работали, но нам приходится стримать на Windows, Mac, iOS, Android. И в нашем случае h264 + udp работает более предсказуемо.
2) у нас в кластере 5 серверов на каждом из них стоит наши приложения и Flashphoner:

*node 01*
CPU model : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
Number of cores : 16
Total amount of Mem : 32159 MB
----------------------------------------------------------------------

*node 02*
----------------------------------------------------------------------
CPU model : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
Number of cores : 16
Total amount of Mem : 32159 MB
----------------------------------------------------------------------

*node 03*
----------------------------------------------------------------------
CPU model : Intel(R) Xeon(R) CPU X5560 @ 2.80GHz
Number of cores : 16
Total amount of Mem : 32159 MB
----------------------------------------------------------------------

*node 04*
----------------------------------------------------------------------
CPU model : Intel(R) Xeon(R) CPU X5560 @ 2.80GHz
Number of cores : 16
Total amount of Mem : 32159 MB
----------------------------------------------------------------------

*node 05*
----------------------------------------------------------------------
CPU model : Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz
Number of cores : 24
Total amount of Mem : 32124 MB
----------------------------------------------------------------------

3) да есть в планах обновиться до последней версии 5.1 , но у нас 1 из серверов используется как миксер аудио потоков и 5.0 у вас в отдельной DEV ветке был миксинг потоков, вот эту ветку мы и используем, я видел что 5.1 уже тоже может миксить звук и на нашем dev кластере я уже это пробовал и миксинг работал, но прежде чем обновить на production кластере, хочу убедиться что все работает правильно в 5.1

KonstantinK · Aug 16, 2018

Логи

Max · Aug 16, 2018

Есть несколько настроек wcs-core.properties, которые нуждаются в тюнинге:

Code:

#Disable heuristic rules
-XX:+UseCMSInitiatingOccupancyOnly

#Reduce Old Gen threshold
-XX:CMSInitiatingOccupancyFraction=70

# Use System.gc() concurrently in CMS
-XX:+ExplicitGCInvokesConcurrent

# Disable System.gc() for RMI, for 10000 hours
-Dsun.rmi.dgc.client.gcInterval=36000000000
-Dsun.rmi.dgc.server.gcInterval=36000000000

Задача - исключить или минимизировать количество запусков Full GC.

Code:

126006.563: [Full GC (System.gc())  617083K->27626K(4142528K), 0.4038967 secs]

Памяти нужно выделить больше.

Code:

-Xmx8g -Xms8g

или даже

Code:

-Xmx16g -Xms16g

При стриминге аллоцируется и уничтожается много объектов с данными.
Рекомендуемый объем heap 16g.

Кроме этого можно попробовать включить настройку

Code:

webrtc_cc2_twcc=true

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

Еще можно сделать тюнинг буферов UDP сокетов

Code:

rtp_receive_buffer_size=13107200
rtp_send_buffer_size =13107200

https://forum.flashphoner.com/threads/wcs-cpu-high.11176/#post-14627

Тюнинг системных очередей

Code:

ip link set txqueuelen 2000 dev eth0

Отслеживание сбросов UDP пакетов

Code:

dropwatch -l kas
>start

Если у вас не используются REST Hooks, можно отключить manager настройкой

Code:

disable_manager_rmi=true

для оптимизации работы с памятью.

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

Микшер может помочь в том плане, что результирующий битрейт смикшированного потока будеи меньше, чем если бы пользователь получал 2-3 разных потока.
В 5.1. микшер работает как с аудио так и с видео.

KonstantinK · Aug 17, 2018

огромное спасибо, подстрою согласно вашим рекомендициям

буфер для WebRTC

KonstantinK

New Member

Max

Administrator

Max

Administrator

KonstantinK

New Member

Max

Administrator

Max

Administrator

KonstantinK

New Member

KonstantinK

New Member

Max

Administrator

Max

Administrator

KonstantinK

New Member

KonstantinK

New Member

Attachments

Max

Administrator

KonstantinK

New Member