Wowza Community

Is the webRTC via the publish/play pages peer to peer?

I’m looking into Wowza cloud as a way to stream low latency video to a small number of users and then less low latency video to an audience of 1000+.

After I start a stream, if I go to and is that just using the wowza cloud as a means of establishing the peer to peer connection for webrtc? I notice that if I select low latency, it is very close to real time. but if I don’t its quite far behind. This doesnt really make sense to me as that should not effect the peer to peer conneciton.

So whats going on here? Is it just using the Wowza Cloud as the signaling server for these webrtc interactions? Or is the webrtc being ingested and then spit back out in a “normal” streaming fashion on the /play url?

If this IS establishing a direct connection, why does the latency setting matter?

Welcome to the forums @Julian_Ridley. :grinning:

First of all I’d like to explain that in Streaming Cloud, you can connect a WebRTC source and it is transcoded to HLS for playback. It is not yet WebRTC playback in Cloud, but coming very soon!

Second, when using WebRTC with either Wowza Streaming Engine or Cloud, we are the server in the middle and it is not peer-to -peer. We act as the middle man:

At its core, WebRTC was designed for peer-to-peer communication between a limited number of browsers. But by adding a media server to their WebRTC streaming solutions, content distributors can enhance the framework’s out-of-the-box capabilities and broadcast live streams to any destination.

Read full blog here.

Third, as far as latency option in Cloud, because Cloud is converting the WebRTC stream to HLS for playback, with HLS there is a standard latency of about to 30 to 45 seconds which for some workflows is acceptable. (Video segments or chunks are usually 10 seconds each in typical HLS.)

If, however, your workflow requires lower latency, you can select “Enable Low-Latency Streaming” and Cloud will create smaller segments of 2 seconds each.
(Three segments are required for HLS playback, so this will reduce your latency to around 6 to 8 seconds)

Depends on your use case and latency requirements.

Lastly, if you need closer to real-time playback in Streaming Engine, you have the option to ingest a non-WebRTC source like RTMP and Engine will play that back in WebRTC or the WebRTC ingest with WebRTC playback is also available in Engine.

Once again, we will be supporting WebRTC ingest and WebRTC playback in Streaming Cloud in very near future and I’ll be sure to let you know when that is official.

Hope this helped clear things up a bit.

Thank you for the information. I still don’t quite understand what is going on in that case. When I go to [redacted] and enter the info I get a video stream that is very far ahead of what is on my cloud account playback page for the stream (or if I bring the hls stream to a 3rd party video player). I am not sure how that is the case.

Regardless, do you have a slightly more specific eta for the direct peer to peer on the cloud? Before I go further I need to know if we will have that capability before 2021 or not. Even just a “yes most likely before 2021” or no would be immensly helpful.

We’re in final testing and looking to announce by the end of October, but yes for sure 100% before 2021. We will never be direct peer-to-peer, so I want to be clear on that language. Wowza is a media server that plays a role in the signaling and webrtc connection. You’d need to research the role of a media server in WebRTC. We will be able to support WebRTC ingest with WebRTC playback

Will you submit a support ticket? That is very odd and unexpected behavior and certainly not we’re used to seeing. I’ll ask the Cloud engineers how that could happen.

The Cloud thumbnail does not refresh that often so that is why you may see the playback page be several seconds ahead- according to our Cloud engineer.

OK thats good to know thanks.

Ah i did not mean the thumbnail. if I go to the playback tab, which has a video player on it linking to the HLS stream you provide, I get the expected delay you mentioned. However, if I go to I get nearly 0 latency. There is no “issue” so to speak, I am just confused as to how that is happening if that page is not using webrtc.

Also, that Carbyne implementation from the blog link is nearly exactly what I was looking to implement. So that is helpful.