freezes (but only when WCS output is UDP)

[richard-vd]

My stream often freezes for a few seconds, while audio continues uninterrupted. It only happens when WCS outputs UDP, either directly using UDP WebRTC or even indirectly using the internal TURN server (in that case the only use of UDP is between TURN and WCS!). The same stream over TCP WebRTC or MSE does not freeze.

I need to use TURN to support clients behind corporate firewalls but the freezes are problematic. Any help is appreciated.

 

[Max]

Good day.

My stream often freezes for a few seconds, while audio continues uninterrupted.

Please clarify how do you publish the stream: from webcam via WebRTC, from RTMP pulisher, or RTSP stream pulling from IP camera?

It only happens when WCS outputs UDP, either directly using UDP WebRTC or even indirectly using the internal TURN server (in that case the only use of UDP is between TURN and WCS!). The same stream over TCP WebRTC or MSE does not freeze.

Please check publisher and player channel quality as described here. If the channel is not perfect try to use lower resolution/bitrate to publish the stream until freezes are gone.
If publisher channel is good but player is not, try to transcode stream to lower resolution/bitrate to eliminate freezes for subscribers with lossy channels. Also, you can enable TCP transport per client, not per server.

I need to use TURN to support clients behind corporate firewalls but the freezes are problematic. Any help is appreciated.

You can use MSE for clients behind corporate firewalls, this technology uses Websocket port only to transfer media traffic (8443 by default), this port should be enabled even TURN server is used.

 

[richard-vd]

Please clarify how do you publish the stream: from webcam via WebRTC, from RTMP pulisher, or RTSP stream pulling from IP camera?

The source is an HDMI to H.264 encoder device via RTSP (TCP).

Also, you can enable TCP transport per client, not per server.

If I enable TCP transport client side, then TURN won't work at all. It is the same as when I set ice_tcp_transport=true in flashphoner.properties. It seems the TURN server can only use UDP internally. Can the TURN server be configured to use TCP internally?

You can use MSE for clients behind corporate firewalls, this technology uses Websocket port only to transfer media traffic (8443 by default), this port should be enabled even TURN server is used.

I would like to offer TURN as an alternative because it requires a single TCP port and latency is similar to TCP WebRTC (<0.5 sec). Using MSE the latency is around 3 seconds.

Also MSE is not stable on Safari:

• sometimes 100% CPU usage
• the video playback progress indicator in the MacBook Pro Touch Bar slowly creeps to the right, and when it hits the far right side playback is paused and won't resume. This always happens sooner or later. It doesn't happen with any other playback method.

 

[Max]

The source is an HDMI to H.264 encoder device via RTSP (TCP).

Can you change encoder settings? If yes, try to set up lower resolution/bitrate on encoder side.

If I enable TCP transport client side, then TURN won't work at all. It is the same as when I set ice_tcp_transport=true in flashphoner.properties. It seems the TURN server can only use UDP internally. Can the TURN server be configured to use TCP internally?

Unfortunately, no. The most TURN servers supports RTP over UDP only.

I would like to offer TURN as an alternative because it requires a single TCP port and latency is similar to TCP WebRTC (<0.5 sec). Using MSE the latency is around 3 seconds.

In this case, you have two options to reduce freezes:
1. Change encoder settings to lower resolution/bitrate
2. Transcode stream to play with lower resolution/bitrate. Please read here about stream transcoding. You can request the desired resolution and bitrate like this

session.createStream({name:"stream1", constraints:{audio:true, video:{width:640,height:360,bitrate:500}}}).play();

Note that transcoding requires a lot of CPU resources (approx 1 CPU core per 2 720p streams encoded).

 

[richard-vd]

The freezes were caused by wrong buffer management in the encoder. The I-frames were sometimes too big and therefore arrived too late (buffer underrun situation), causing the browser to freeze the video for the duration of the whole GOP. It was fixed by new firmware from the encoder manufacturer and different settings to decrease the I-frame size.