Search results

Поток с сервера начнет проигрываться не раньше, чем перейдет в статус PUBLISHING. Такова последовательность выполнения операций. Поэтому это ожидаемое поведение.

На этом шаге сервер перестает получать ответы на пинги, отправленные в сторону клиента. Как видно из скриншота, сервер отправляет пинги в сторону клиента через вебсокет соединение. Периодичность отправки 5 секунд. Клиент отвечает. Если на 10 пингов не будет получено ответа, сервер считает что...

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

Здравствуйте. 1. При переключении с мобильного интернета на wifi поменяется IP адрес. Автоматически сервер такое не отработает. Поэтому потерю соединения можно обработать только путем полного реконнекта, который займет несколько секунд. Т.е. при получении ошибки, нужно попробовать...

Good day. Please update WCS to the latest build 5.2.2107. If the problem still persists, please collect a report as described here and send it using this form.

Good day. We raised the ticket WCS-4257 to add the field to /connection/find response.

This depends on publishing resolution and bitrate. For example, you'll need 10 Mbps upload/download channel to publish or play FullHD (1080p) stream, 20 Mbps to publish or play 2K stream. If yuo have only 1 Mbps channel, you can publish or play 320X240 stream only with acceptable quality.

Seems like the problem is in your client code. Please tweak Two Way Streaming example code minimally to reproduce the issue and send us the code modified using this form.

Please answer these two questions: 3. Is the problem reproducing in example applications (Two Way Streaming etc)? 4. Is the problem reproducing with our demo server: https://demo.flashphoner.com:8444/client2/examples/demo/streaming/two_way_streaming/two_way_streaming.html

Good day. Since WebSDK build 2.0.251, a room Websocket connection control options are available: Room connection control options

There is no such Flashphoner WebSDK version. The latest actual version is 2.0.252. Please update and check. Also you should test in example applications and demo server a we supposed above.

Good day/ Please clarify the following: 1. What WCS version do you use? 2. What Web SDK version do you use? 3. Is the problem reproducing in example applications (Two Way Streaming etc)? 4. Is the problem reproducing with our demo server...

Добрый день. К сожалению, нам не удается воспроизвести проблему в Win Firefox 131.0.3 как с последней сборкой WebSDK 2.0.251 и WCS 5.2.2096, так и на демо сервере (2.0.248 и 5.2.2071 соответственно). Проверьте, пожалуйста, на демо сервере в примере Media Devices...

Good day. Since WebSDK build 2.0.250 a media devices labels are URI encoded to prevent a possible parsing issues at backend side for non-latin characters. Please update WebSDK and check.

Hello Please check the pricing page WCS is a self-hosted software. The number of connections is limited by network bandwidth and hardware of your VPS or physical server. There is no program limitation. Rough calculation. 1 stream 720 p = 2 Mbit per second 250 streams will utilize 500 Mbit per...

Please try one of the following approaches: 1, 2, 3

Hello The issue is confirmed on our end. According our tests it does not parse this character properly ó We are working on a fix. Will keep you informed.

Hello What is the server port where TLSv1 in use? WCS default secure ports 8444 HTTPS 8443 WSS (Websocket SSL) Nginx secure ports 443 (?) If you are using Nginx as a reverse proxy Browser > [TLSv1] > Nginx 443 > [HTTP not encrypted] > WCS 8080 Then the TLSv1 issue is on Nginx end. To fix...

A possible problem may be in non-latin characters in camera or microphone device name Predeterminado - Micrófono de los auriculares con micrófono (2- Jabra EVOLVE 20 MS). We raised the ticket WCS-4249 to encode such characters before sending them to server for debug purposes. As workaround, try...

This is not the same error: Seems like the camera is captured correctly, but WebRTC connection failed. We can't reproduce this on Windows 11 with Video Chat and Screen Sharing example in MS Edge 129 on our demo server...