WebRTC workflows in Wowza Streaming Cloud

This article describes the supported WebRTC functionality and workflows in Wowza Streaming Cloud™.

About WebRTC


Web Real-Time Communication (WebRTC) is an open-source project to enable real-time communication of audio, video, and data in web browsers and native apps. WebRTC eliminates the need to install plug-ins or download third-party software.

With Wowza Streaming Cloud, you can ingest and deliver WebRTC streams with all major desktop and mobile browsers that support WebRTC APIs. Wowza Streaming Cloud also provides hosted pages that allow you to publish and play back WebRTC streams with minimal setup required.

Note: The WebRTC hosted pages are supported on the latest versions of Chrome and Safari, as well as Edge version 79 and later.

WebRTC workflows in Wowza Streaming Cloud


Ingest a WebRTC stream and deliver it to viewers for HLS playback

Wowza Streaming Cloud ingests a single-bitrate WebRTC source stream, transcodes the stream into multiple output renditions, and then delivers the stream through a CDN for playback over HLS. This workflow is best suited for live stream broadcasts with large numbers of viewers that exceed the WebRTC playback viewer limit of 300. For more information, see the following articles:

Ingest a WebRTC stream and deliver it to viewers for WebRTC playback

Wowza Streaming Cloud ingests a single-bitrate WebRTC source stream, and then delivers the stream for playback directly off the transcoder. This workflow is best suited for live stream broadcasts with fewer than 300 viewers where latency is a primary concern. For more information, see the following articles:

Choosing a workflow


When choosing how to deliver your WebRTC stream to viewers, consider the following questions:

  • How much of a concern is cost?
  • Am I worried about latency?
  • How large is my audience?

Cost

Egress costs for WebRTC playback are typically greater than the costs associated with delivering streams to viewers via HLS through a CDN. Because viewers connect directly to the transcoder, egress is incurred per viewer. With CDN delivery, egress is incurred for the stream sent to the CDN and then CDN bandwidth, typically less expensive than egress, delivers the stream to viewers.

For more information, see the terms of your Cloud subscription for details on the associated costs.

Latency

Latency refers to the time it takes from the moment content is encoded by the source until it appears for a viewer in the player. HLS latency often exceeds 10+ seconds. This is in contrast to WebRTC where expected latency is less than two seconds.

Note: WebRTC latency can vary depending on bitrate, location, and available network bandwidth. For large audiences, we recommend stream distribution through a CDN, not direct playback through the transcoder.

Viewer limits

By default, WebRTC playback is limited to 10 viewers. This number can be increased to allow additional viewers. The maximum number of viewers a transcoder can support varies depending on configuration options you selected when you set up the transcoder. Generally, adaptive bitrate transcoders are larger and support more viewer connections (up to 300) while passthrough transcoders are smaller and support fewer viewer connections.

There are no viewer limits when delivering a stream through a CDN.