"status": "NOT_ENOUGH_BANDWIDTH",

Max

Administrator
Staff member
В соседней теме есть этот же вопрос
Это событие инициируется если на канале между WCS сервером и зрителем обнаружено 5% и более потерь.
Можно повысить этот порог настройкой (приводится значение по умолчанию)
Code:
webrtc_cc2_bitrate_overuse_event_threshold=0.05
 

pride

Member
При частых попытках просмотреть стрим (Эмитируем так: Клиент пытается получить стрим, мы проверяем кастом поля, и рубим его через terminate), на сервере возникает вот такое "status": "STOPPED". И висит некоторое время , потом прибивается. Но у клиента. не возникает событие FAILD или STOPED .
В чем может быть проблема?
 

Max

Administrator
Staff member
Клиент пытается получить стрим, мы проверяем кастом поля, и рубим его через terminate
Это не совсем удачная реализация.
Так как вы даете стриму запуститься, инициализироваться и в это же время его убиваете. Возможно в процессе инициализации, когда уже идет ICE и DTLS.
Лучше сразу реджектить стрим на этапе запроса stream.play().
В новой документации по REST-методам показано как это сделать и есть примеры здесь.

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

Кстати, мы выпустили вторую версию REST API. Там более упорядочены методы и есть документация с примерами:
https://flashphoner.com/docs/wcs5/wcs_docs/html/ru/wcs-rest-api
 

pride

Member
Ок. Спасибо будем ждать. Но нам неудобно рубить пользователя на стадии stream.play(). Ибо с NodeJS будет идти запрос на стороний сервер который будет пытаться снять со счета пользователя средства. И если вдруг после stream.play() в streamStatusEvent придет ошибка (по какой либо причине). Мы не в состоянии вернуть средства пользователю.

ПЫСЫ: так же хотел задать вопрос по поводу DEV лицензии, имеется ли такая ? Ибо обновлять каждые 14 дней, сертификат еще и с строгой привязкой к корпоративному домену , не очень удобно.
В процессе разработки, не удобно использовать сервер продакшена)
 

Max

Administrator
Staff member
Ибо с NodeJS будет идти запрос на стороний сервер который будет пытаться снять со счета пользователя средства. И если вдруг после stream.play() в streamStatusEvent придет ошибка (по какой либо причине). Мы не в состоянии вернуть средства пользователю.
Понятно. Значит в вашем случае вы сначала убеждаетесь что стрим у пользователя появился и только после этого снимаете деньги.
В этом случае действительно поможет terminate.
Обойти terminate в этом случае можно, отправив пользователю команду, по которой он вызовет stream.stop()
Но после этого все равно придется вызывать terminate на случай, если пользователь заблокировал stream.stop(), что маловероятно, но возможно.
При частых попытках просмотреть стрим (Эмитируем так: Клиент пытается получить стрим, мы проверяем кастом поля, и рубим его через terminate)
Т.е. для воспроизведения проблемы нужно сделать stream.play(), а потом быстро сделать terminate(). Верно? Как это можно быстрее всего воспроизвести?
так же хотел задать вопрос по поводу DEV лицензии, имеется ли такая ? Ибо обновлять каждые 14 дней, сертификат еще и с строгой привязкой к корпоративному домену , не очень удобно.
Напишите письмо на sales@flashphoner.com
Мы планируем ввести dev-лицензии и когда будет готово, сообщим по почте.
Сейчас триалы доступны 30 дней и не лимитированы доменом. Поэтому триал тоже вариант.
 

Max

Administrator
Staff member
Еще вопрос. Какой у вас номер билда?
 

pride

Member
Code:
Понятно. Значит в вашем случае вы сначала убеждаетесь что стрим у пользователя появился и только после этого снимаете деньги.
В этом случае действительно поможет terminate.
Обойти terminate в этом случае можно, отправив пользователю команду, по которой он вызовет stream.stop()
Но после этого все равно придется вызывать terminate на случай, если пользователь заблокировал stream.stop(), что маловероятно, но возможно.
Так и реализовано, перед terminate пользователь по команде APP_DATA пытается сам себя закрыть. Но все равно получается глюк с статусом STOPED.
Code:
Т.е. для воспроизведения проблемы нужно сделать stream.play(), а потом быстро сделать terminate(). Верно? Как это можно быстрее всего воспроизвести?
Именно так. Мы реализовали это на NodeJS.
Code:
Еще вопрос. Какой у вас номер билда?
5.0.2158
 

pride

Member
Подскажите, возможно ли штатными средствами в WEB sdk , если нет возможности использовать WEBRTC публиковать и смотреть с помощью Flash ?
 

Max

Administrator
Staff member
Подскажите, возможно ли штатными средствами в WEB sdk , если нет возможности использовать WEBRTC публиковать и смотреть с помощью Flash ?
Да, можно. Стандартные примеры используют Flash в браузере IE.
Просьба оформлять логически разные вопросы отдельными темами на форуме.
В этой теме отпишем по проблеме с terminate, когда будут результаты.
 

Max

Administrator
Staff member
Относительно REST terminate.
Мы провели тесты и обнаружили, что такое поведение получается только в тех случаях, когда одновременно вызывается stream.stop() и REST terminate.
Если
1) Дождаться StreamStatusEvent STOPPED и сделать REST terminate после этого события, то все работает корректно.
2) Не делать stream.stop(), а сделать только REST terminate, то тоже все работает корректно.
Т.е. попробуйте просто не вызывать stream.stop() и REST terminate одновременно или не вызывать stream.stop() совсем.
 
Top