Клиенты отваливаются через 10-30 секунд

[Max]

В последних версиях такие настройки (даны значения по-умолчанию)
1. Включить вторую версиюуправления адаптивным битрейтом.

webrtc_cc2 = true

2. Включить зависимость битрейта паблишера от зрителей.

webrtc_cc2_сс = false

3. Инициировать событие NOT_ENOUGH_BANDWIDTH если превышен порог потерь в сторону зрителя (5% по умолчанию).

webrtc_cc2_bitrate_overuse_event_threshold=0.05

4. Ограничить максимальный битрейт, до которого может разогнаться паблишер (10 Mbps).

webrtc_cc_max_bitrate = 10000000

5. Ограничить минимальный битрейт, до которого может упасть паблишер (30 kbps).

webrtc_cc_min_bitrate = 30000

Таким образом, при включении webrtc_cc2 = true вы не будете зависеть от зрителей. Просто переключитесь на новый алгоритм, который в последних сборках должен работать более стабильно.

 

[alexanderY]

Значит сейчас у нас отключена зависимость от зрителей? Если так, то ок, значит событие NOT_ENOUGH_BANDWIDTH в нашем случае было вызвано реально плохим каналом на стороне нескольких юзеров?

Есть ли мысли по второму вопросу? Нужно ли больше логов? Вижу такое впервые, воспроизвести не могу, но факт - юзер до сих пор в комнате. Я понимаю, что перезагрузка решит эту "проблему", но нам сейчас важнее понять, как избежать этого в будущем, и почему вообще такое произошло.

 

[Max]

Поправил настройку, влияющую на NOT_ENOUGH_BANDWIDTH

webrtc_cc2_bitrate_overuse_event_threshold = 0.05

Значит сейчас у нас отключена зависимость от зрителей?

Начиная с билда 2146, мы отключили это поведение по-умолчанию, с помощью
webrtc_cc2_сс = false
Так как на тестах с хромом увидели ложные срабатывания.

Если так, то ок, значит событие NOT_ENOUGH_BANDWIDTH в нашем случае было вызвано реально плохим каналом на стороне нескольких юзеров?

Вызвано потерями более 5% на канале.
Если вы не контролируете верхнюю планку битрейта
webrtc_cc_max_bitrate = 10000000
То паблишер может развивать битрейты, которые зрители не способны забрать. В этом случае могут идти потери и NOT_ENOUGH_BANDWIDTH

Есть ли мысли по второму вопросу? Нужно ли больше логов? Вижу такое впервые, воспроизвести не могу, но факт - юзер до сих пор в комнате. Я понимаю, что перезагрузка решит эту "проблему", но нам сейчас важнее понять, как избежать этого в будущем, и почему вообще такое произошло.

Мы исправляли похожую проблему в сборке 2157. Какой у вас билд?

 

[alexanderY]

Если установлено webrtc_cc2_сс = false, то параметры webrtc_cc_max_bitrate и webrtc_cc_min_bitrate игнорируются?

У нас билд 2158.

 

[Max]

Если установлено webrtc_cc2_сс = false, то параметры webrtc_cc_max_bitrate и webrtc_cc_min_bitrate игнорируются?

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

 

[alexanderY]

Ok, хорошо. webrtc_cc2_сс у нас отключено (т.к. не прописано), но минимальный и максимальный битрейт установлены в 300000 и 400000 соответственно.

 

[Виктор Сухов]

Протестируем этот кейс на своем хостинге. Проверим, что получается.
Сейчас мы занимаемся битрейтами и сделали в последних билдах 2122 следующее.
События о проблемах в получении стрима
1. Зритель автоматически отдаёт серверу информацию о том, какой битрейт он в состоянии получить.
2. Сервер постоянно измеряет битрейт Стримера
3. Если битрейт, который Зритель может получить, ниже текущего битрейта Стримера на 10% и более, то на клиента высылается событие StreamStatusEvent (последниие версии Web SDK).
Выглядит это так:
View attachment 140
Т.е. будет высылаться событие, которое говорит о том, что у зрителя недостаточный канал для принятия потока, который генерирует Стример.
Корректировка стримера зрителями
Допустим два и более Зрителей смотрят одного Стримера.
Зритель 1 - может забирать поток 200 kbps
Зритель 2 - может забирать поток 400 kbps
Стример отдает поток 500 kbps
Сервер настроен по-умолчанию:

webrtc_cc2_min_remb_bitrate_bps =100000

В этом случае WCS потребует от Стримера уменьшить битрейт до 200 kbps, равняясь на самого слабого зрителя. Но не будет понижать битрейт Стримера ниже порога в настройке webrtc_cc2_min_remb_bitrate_bps View attachment 141 Таким образом, если зрители начнут испытывать проблемы со стримом, WCS потребует от Стримера ужать полосу, но не ниже порога. Надеемся, что это может оперативно разгрузить сеть и предотвратить сбои.
Настройки и тестирование
Мы тестируем эти изменения с последними сборками и кодеком H.264 в приоритете.

codecs=opus,alaw,ulaw,g729,speex16,g722,mpeg4-generic,telephone-event,h264,vp8,flv,mpv
webrtc_cc2_min_remb_bitrate_bps =100000

Вот эта информация актуальна по поводу уменьшения битрейта Стримера за счёт медленных зрителей?

 

[Max]

Добрый день.

Вот эта информация актуальна по поводу уменьшения битрейта Стримера за счёт медленных зрителей?

Мы рекомендуем использовать для управления битрейтом на сервере настройки (значения указаны только для примера)

webrtc_cc_min_bitrate=2000000
webrtc_cc_max_bitrate=7000000

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