We have been using the streaming cloud platform webrtc for a while now. We built the browser streaming end off of your https://www.wowza.com/webrtc/publish example.
However, as usage has gone up we’ve noticed users streams will often end up significantly worse in terms of choppiness or outright stalling compared to some other webrtc streaming application (IE Zoom).
We’ve done some minor work on optimaztion but only at a surface level and have not seen much improvements comparitevely. Do you have documents (I looked but didnt seem to find them) regarding optimizing webrtc streaming on Wowza Streaming Cloud? I’ve not had success finding general solutions that seem to work here.
Hi @Julian_Ridley, how many viewers are connected when you start to experience the choppy video? WebRTC through Wowza will only scale well for a certain number of viewers and isn’t meant for large audiences as Zoom is. You’ll typically start to see playback issues over 300 connections. For more than that, we suggest transcoding to HLS for playback.
If you had far less connections than that, well you may want to adjust the bitrate, frame rate from the encoder or by clicking on the settings gear icon in the webrtc playback page. (Upper right corner)
Since the webrtc > webrtc stream is not transcoded to provide an adaptive bitrate to support slower connection speeds, it’s worth testing with the lowest bitrate that provides you the quality of stream you are looking for.
Webrtc does not like B-frames and that is something that can be disabled in the encoder settings. If you encode with H.264 Main or High profile, the stream will contain B - frames .WebRTC protocol which is developed for low latency would not be able to handle B-frames which are dependent to other later frames and it will cause jittering.
WebRTC sacrifices B-frames from the GOP structure to enable real-time delivery, which can impact quality.
Lastly, keep in mind that In Cloud Webrtc playback, Cloud uses only TCP and Firefox requires UDP. So Firefox in Cloud is not possible.
Firefox can be used in Engine with WebRTC, where you can enable both TCP and UDP as Ice Candidate.
Thanks for the reply. We only have about 10 veiwers maximum connected to the webrtc stream to see things in “real time”, we then have 100s more connected to an HLS stream output of that stream as the delay for them is fine. I assume people hitting the transcoded HLS stream shouldn’t effect the webrtc connected users.
I will experiment with lowering the bitrate. Would the B-frame options be relevant here assuming the streaming is done through the browser like yuor publish page? Or are the b-frame settings you mention in the transcoder/stream setup on the cloud?
