Search results

It was the bug. The watermark must be applied to transcoder output stream, not to the transcoder source stream. The bug was fixed, so you should change your flow: a viewers should play transcoder output stream, but not the original stream.

We checked the server. You have an issues with server settings 1. Server CPU load is too high for a couple of streams The server has 24 cores (actually it is 12c/24t). But you've set a twice more threads in all the thread pools: So you really have 48 threads which are just consume CPU but does...

The better channel quailty and bandwidth between publisher and server, the less its stream latency. It's applcable to player too. The longer the channel, the worse quality and bandwidth. in this case you should have US origin and Indian edge.

Please provide SSH access to the server using this form for our engineers to test.

Good day. We confirm the issue. The ticker WCS-4370 is raised. But webcallserver update command still works.

You can't achive an equal latency via a different publisher channels. So you will have a 1.5-2 secinds latency when publishing form India to US. Please consider a CDN with origin closer to publishers and edges closer to players. A simple configuration explained in this article, a technical...

We checked the server by credentials provided. Seems like the server too far from a clients. The instanse is in us-west AWS region, but you`re probably testing from India. In this case a minimal server ping will be 200 ms and more (from our test PC ping is 222 ms to intermediate hosts)...

Seems like you are continiously injecting the same file to the same stream: when file reaches the end (every 30 seconds), you make another /stream/inject2/startup call with the same parameters. According to video attached, the original stream has static picture. So when injected stream ends, and...

Please see the IP address to allow SSH connections here: Providing support engineer access to your server We do not arrange any remote sessions.

Good day. Watermark may be applied to the transcoded stream only. It can't be applied to an original stream. Please read the docs:

Please provide SSH access to the server where issue is reproducing. Use this form to send a credentials.

Please reproduce the issue, collect a report using a special script Getting logs with report.sh script (preferable) and send using this form.

We can't reproduce the issue in the latest build 5.2.2201. Please check if both streams have a same audio and video codecs: Known limits. Please check also if you set all the parameters needed in the REST APi query /stream/inject2/startup If the issue still persists, reproduce the issue, then...

Good day. Please provide a more detaled description: 1. WCS version used 2. Stream publishing method: WebSDK (browser), Android/iOS SDK (mobile), RTMP (OBS), etc 3. How do you change video: switch source at publisher side, publish two streams and inject one into another using REST API, etc

Good day. You can't capture audio or video when application is in background. This is iOS limitation.

Good day. Please set the following parameters in /usr/local/FlashphonerWebCallServer/conf/flashphoner.properties file periodic_fir_request=true periodic_fir_request_interval=2000 The initial delay should be no more than 2 seconds in this case.

Yes, IPv6 does not work with WebRTC TCP transport now. That's the issue. We already testing the fix.

We fixed the issue in WCS build 5.2.2197. Please update and check.

Добрый день. Выглядит так, что не проходит DTLS соединение Проверьте, что сервер также обновлен до последней сборки 5.2.2197. Также проверьте, воспроизводится ли проблема с примерами Android SDK из архива сборки 1.1.0.68. К сожалению, нет, поддержка ARM32 процессоров убрана Google из WebRTC...

You don't need external internet while using the software under Standalone License. However you would need internet connection at least one time during activation. Once license is activated, conf/flashphoner.license will be recorded. Then you will be able to disable external internet connection...