Search results

So you need to capture RTSP stream in codec H265 and play it as WebRTC in H264 codec (because H265 is not supported for WebRTC). In this case, transcoding H265->H264 will need on server. Please note that transcoding requires a lot of server CPU resources (1 CPU core to encode 2 720p streams, or...

Good day. In latest WCS builds, we've added publishing/playback support for a multiple audio/video tracks in one WebRTC connection: SFU functions with Simulcast We've allso added some example applications to use SFU SDK in browser: SFU Player SFU Two Way Streaming This may help to publish a...

Добрый день. В последних сборках WCS мы добавили функции публикации/проигрывания нескольких потоков в одном WebRTC соединении: Функции SFU с поддержкой Simulcast Также мы добавили несколько примеров использования SFU SDK в браузере: SFU Player SFU Two Way Streaming Этот функционал позволяет...

Добрый день. Мы воспроизвели проблему и создали тикет WCS-3442 для ее решения. Отпишем здесь по результатам.

There is no difference. Either if you balance publishers or players, the Publisher or Player should establish Websocket connection first (i.e. when you connect to wss://demo.flashphoner.com:8443). This is the point of balancing. Flow: Publish 1. Establish Websocket connection to LB > to...

Hello Please provide a bit of context. - What is the page? - How this page is linked with WCS server? - How do you test and reproduce unresponsive behavior?

Hello Actually you balance Websocket connection between two or more servers. Once Websocket session is established, all further interactions work directly with connected server. Here you can find the docs how to setup load balancing using HA Proxy...

Hello Internal ticket is already raised WCS-3106. We will report into this thread once we have any progress. Please note. We do not provide any ETA on forum-support level. Similar voting thread. Regarding H.265 implementation. Please tell us more about your case. For example, browsers do not...

Good day. Please take a look to the Player and Embed Player samples with automatic reconnect (since WebSDK build 2.0.189). You can also try Streaming Auto Restore example (since WebSDK build 2.0.209).

Hello, Please provide more information - iOS version - is there an issue with publishing using one of the iOS SDK demo examples If the issue is not reproducible with a demo example (e.g., TwoWayStreaming), please modify an example to reproduce it and send using this form.

Seems like Huawei Cloud exposes AWS-like API. In this case, admin password is set to instanceId, which can be retrieved as follows curl http://169.254.169.254/latest/meta-data/instance-id Also, it can be displayed somewhere in cloud console. Example fow AWS:

We've checked your server. Seems like license server connection was broken occasionally. We restarted the server systemctl restart webcallserver then it works correctly:

Good day. We have not tested WCS in Huawei Elastic Cloud yet. Please provide SSH access to the instance using this form.

Good day. Seem like some streams are publishing with video. To chek how streams are publishing on server side, please set up Prometheus and Grafana to collect server monitoring data as described in this article 10 Important WebRTC Streaming Metrics and Configuring Prometheus + Grafana...

Возможно, ответ есть в документации по ReplayKit.

Please download latest build 5.2.1133, then unpack it. The default database.yml file is in FlashphonerWebCallServer-5.2.1133/server/conf folder.

We checked your server. Seems you have an instance in DO, with build 5.2.780 out-of-the-box So the examples opened directly from server are working, but a newer examples may not. We recommend you to update WCS (with WebSDK included) to the latest build 5.2.1133 as described here.

Hello What is your server version? Example: Our demo server: https://demo.flashphoner.com Server: 5.2.1131 Web SDK: 2.0.212 view-source:https://demo.flashphoner.com/client2/examples/demo/streaming/video-chat/video-chat.html flashphoner-room-api.js used You can download latest server...

Good day. Screen sharing with a native screen resolution (1080p and above) requires a good channel quality like for 4K broadcasting: 20 Mbps bandwidth with a zero loss. If the user has such a good channel, you can use UDP transport which reduces a latency. Otherwise, you have to use TCP...

Good day. Seem like your server does not respond on port 8443. Please provide SSH access to the server using this private form.