“Hello friends. I have a very simple question but can’t find an answer. How do I make two incoming streams from different encoders go to the same target at the same time? The goal is to make backups for my PCs and automatically switch between streams if one of them fails. Simply manually starting and stopping the second encoder is not an option because it’s critical for me to have no interruptions in the data feed to the streaming platforms. More than that, I would like to use the transcoding option for different platforms. I would very much appreciate any suggestions on this question.”
Hello,
I would like to clarify the point that you can achieve the Scaling of your Wowza server in two ways, which I guess was a bit confusing in your workflow.
Option A :
We do have an option in the edge server to switch between primary and backup origin servers:
https://www.wowza.com/docs/how-to-configure-a-live-stream-repeater
Your encoder has to push two RTMP streams to the primary and backup server at a time. We do have a property called cupertinoCalculateChunkIDBasedOnTimecode is typically used to allow you to keep HLS chunks in sync across Wowza instances. You have to configure this property on both primary and backup origin server. Also, make sure the cupertinoChunkDurationTarget value should be same on both the server.
Note: Timecodes are generated by the encoder providing the live stream. So make sure your encoder is capable of publishing to both this origin servers at a time.
We have outlined about the property in this part of the article. I would recommend you to review it:
https://www.wowza.com/docs/how-to-configure-apple-hls-packetization-cupertinostreaming#enable-custom-hls-cupertino-properties-for-live-streams3
cupertinoCalculateChunkIDBasedOnTimecode – Turns on chunk ID numbering based on incoming packet time. When enabled, the chunk ID equals the quotient of the timecode divided by the cupertinoChunkDurationTarget value.
Note: Only use cupertinoCalculateChunkIDBasedOnTimecode with encoders that send synchronized timecodes to Wowza Streaming Engine. Synchronized timecodes synchronize to UTC or some other time base so that they advance at a constant rate. If cupertinoCalculateChunkIDBasedOnTimecode is used with an encoder that doesn’t send synchronized timecodes, when the stream restarts, the chunk IDs will restart at 0 or, in some cases, at a random value. This is particularly problematic with HTTP origin live streams that are ingested from primary and backup servers. In these cases, the proxy may return old chunks to players.
- On the application page Properties tab, click Custom in the Quick Links bar.
- In the Custom section, click Edit .
- Click Add Custom Property and specify the following:
- Path - Select /Root/Application/LiveStreamPacketizers .
- Name - Enter cupertinoCalculateChunkIDBasedOnTimecode .
- Type - Select Boolean .
- Value - To start Apple HLS chunk IDs at 0 , enter false . To calculate Apple HLS chunk IDs based on the incoming live stream timecodes, enter true . Use this mode to synchronize chunk IDs between two servers that packetize the same live stream.
- Click Add , click Save , and then restart the application.
Also, configured the stream Timeout property in the edge server to drop the buffering when switching between one origin to another origin server.
MediaCaster/Properties property streamTimeout when used on a Live Edge application can reduce the time between switching from the “Primary Origin URL” to the “Secondary Origin URL”.
Path: /Root/Application/MediaCasterName: streamTimeoutType: Integer Value: 1000
You can have multiple edge servers based on your requirements with the same set of origin and backup servers and you can configure this with your Google Loadbalancer and manage to scale. This option literally means that you have created your CDN network so YOu don’t have to configure a CDN here.
Option B:
Similar to option A, Your encoder has to push two RTMP streams to the primary and backup server at a time. Make sure you configure cupertinoCalculateChunkIDBasedOnTimecode on the primary origin and backup server. Also, make sure the cupertinoChunkDurationTarget value should be same on both servers.
Note: Timecodes are generated by the encoder providing the live stream. So make sure your encoder is capable of publishing to both this origin servers at a time.
In this method, you can have an HLS playlist that has both streams from the primary and backup origin server.
You can use SMIL for playback. You will need to specify the absolute path in the URI or DOMAIN cupertino tags.
Here’s an example SMIL file:
<smil> <head> </head> <body> <switch> <video src="mp4:sample.mp4" system-bitrate="300000" width="424" height="240"> <param name="videoCodecId" value="avc1.66.30" valuetype="data"/> <param name="audioCodecId" value="mp4a.40.2" valuetype="data"/> <param name="cupertinoTag.URI" value="http://test1.wowza.com:1935/vod/mp4:sample.mp4/chunklist.m3u8" valuetype="data"/> </video> <video src="mp4:sample.mp4" system-bitrate="300000" width="424" height="240"> <param name="videoCodecId" value="avc1.66.30" valuetype="data"/> <param name="audioCodecId" value="mp4a.40.2" valuetype="data"/> <param name="cupertinoTag.URI" value="http://test2.wowza.com:1935/vod/mp4:sample.mp4/chunklist.m3u8" valuetype="data"/> </video> </switch> </body></smil>
Here’s an example manifest generated:
#EXTM3U#EXT-X-VERSION:3#EXT-X-STREAM-INF:BANDWIDTH=300000,CODECS="avc1.66.30,mp4a.40.2"http://test1.wowza.com:1935/vod/mp4:sample.mp4/chunklist.m3u8#EXT-X-STREAM-INF:BANDWIDTH=300000,CODECS="avc1.66.30,mp4a.40.2"http://test2.wowza.com:1935/vod/mp4:sample.mp4/chunklist.m3u8
When testing with actual content with JWPlayer, and when the first URL is disabled the player correctly downloaded chunks from the second URI.
The Origin-Edge configuration is possible as well, but may not be as easy as the SMIL file approach. Finally, you can use a CDN to deliver playback.
In this case, the load balancer is not required as CDN does scaling.
Regarding your question on the number of edge servers and backup servers required. That totally depends on the number of streams connected to the server at a time and the number of playback requests coming to the origin, also bandwidth limitations on the server should also be considered. This totally depends on your load and your requirements. So we couldn’t recommend on it.
Hope the above-mentioned information is helpful for you.
Regards,
Kishore Kumar
Sr. Technical Support Engineer
Hello,
are you using Wowza to push live stream to a number of streaming platforms and it is important not to interrupt publishing in case of primary encoder failure ?
I can suggest to try extension module which was developed exactly for such scenario with primary and secondary encoders https://pwi.dev/eng/products/view/pwi-stream-monitor-addon-for-wowza-streaming-engine .
With regards,
PWI Team
