Live stream repeater (origin/edge) configurations for Wowza Streaming Engine™ media server software let you scale your deployment when you need to make live streams available from multiple Wowza Streaming Engine servers at the same time. They can be used to pull in streams from a remote server or to create a cluster of servers to make live streams available to a larger audience.
Contents
How live stream repeaters work
Live stream repeater operation modes
More resources
How live stream repeaters work
In its simplest form, a live stream repeater system consists of one origin server and one edge server. A live stream is published directly to the origin server from an encoder. The origin can also be a dedicated server that's used for re-encoding the live stream using Transcoder. Client players connect to the edge server to retrieve the stream.
In a live stream repeater configuration, there's only a single connection per stream for each player type between the origin and edge. This dramatically reduces the load on the origin server.
An existing single server configuration can easily be extended to use live stream repeater functionality with no other modifications to the original Wowza Streaming Engine live application. Edge servers are simply added to the configuration as required. If multiple edge servers are used, then some form of load balancing will most likely be required.
For more information, see Configure a live stream repeater in Wowza Streaming Engine.
Note: Additional configuration is required for CMAF stream repeating. For more information, see Stream using a CMAF live stream repeater in Wowza Streaming Engine.
Live stream repeater operation modes
Wowza live stream repeater has two basic modes of operation: On demand mode, the default, determines how the edge server is configured. Persistent mode is used when the edge application is configured as a regular live application.
On demand mode
On demand mode is the default mode used when Wowza Streaming Engine configures a Live Edge application. In this mode, the edge application only makes a connection to the origin server application after a stream is actually requested, and it automatically shuts down the connection when there are no more requests for the stream. Each different player type makes a separate connection to the origin application to retrieve its own stream. Separate connections are made for RTMP streams and for each of the HTTP protocols, as required. Each HTTP protocol requires a different stream format, which requires a separate connection back to the origin server.The edge applications are designed to repeat only the stream from the origin application. Therefore, HTTP streams must be packetized on the origin application.
Because the streams are loaded on-demand, recording and transcoding on the edge application won't work as expected. If your workflow warrants it, use the origin server or another dedicated server to record and transcode.
Furthermore, direct encoder connections to the edge application won't work because Live Edge applications are designed to connect automatically to an origin application for any requested stream. Wowza Streaming Engine provides easy setup with edge application(s) that are configured with a default set of origin server URLs to connect to. This means that Wowza Streaming Engine doesn't need to be aware of the streams that are running on the origin application; it tries to make a connection and request any stream name that's requested by the player. The Stream Files feature in Wowza Streaming Engine can be used to configure specific settings per stream.
Persistent mode
Persistent mode is used when the edge application is configured as a regular Live application. Connections are made to the origin server application by using the built-in Stream Files feature or by using Java API methods. The connections can also be made to start automatically when Wowza Streaming Engine starts by adding them to the Startup Streams list.For all players, there's only a single connection to the origin server application, and the stream must be connected before any player can receive it.
Because the edge application is a regular Live application, any streams that are requested but not actually running will cause an error in the player. HTTP streams must be packetized on the edge application and recording, transcoding, and direct encoder connections are possible only because it's a regular Live application.
With both repeater modes, the edge application continuously tries to reconnect to the origin server application if it's disconnected. If multiple origin URLs are defined (either in the Origin URL setting for On demand mode or Stream Files in either mode), then the edge application tries to connect to each URL in turn, until it locates the stream.
On demand mode is the easiest to configure and scale quickly. If the origin server application is up and running, it's normally just a case of creating a Live Edge application, configuring it to connect to the origin server application, and then directing the players to connect to it. In contrast, Persistent mode requires each of the streams to be configured and started.
When players connect to HTTP streams in On demand mode, each edge server application receives identical stream segments. This occurs because the streams are packetized on the origin application, and this condition makes it possible for a player to migrate seamlessly from one edge server to another. In Persistent mode, each edge server may have a different segment sequence, so a player migrating from one edge server to another may experience a playback interruption.
Because On demand mode makes separate connections for each player protocol type, it may use more bandwidth than Persistent mode, initially. However, over a long period of time, On demand mode uses less bandwidth because the streams will disconnect when they aren't being watched or requested. If multiple protocols are requested consistently, then Persistent mode is more likely to use less bandwidth.
