From a reliability perspective, one of the great things about VOD transcoding is the ability to simply try again. If anything goes wrong during the transcoding process, we can simply re-run the process from the beginning. The worst effect of a hiccup is a job takes a little longer, which is unfortunate, but the end result is a transcoded file is delivered to the customer and all is well.
During a live event, however, we don't have the luxury of simply trying again. Since these events are transcoded in real time, we only have one chance to deliver a perfect transcode to end-users; a blip anywhere along the way can mean an interruption. No matter how reliable the system is, you never know when something like a power supply or network card is going to fail, so redundancy is crucial for high profile events.
To account for this, we recently announced redundant transcoding for live streams. In a nutshell, if redundant_transcode is enabled, and at least one secondary_url is specified, Zencoder will transparently create a new job using any secondary URLs specified in the outputs of the original request. This job has all the same settings of the original, with the important distinction of being run in the nearest transcoding region of an entirely different cloud provider.
Let's look at an example:
{
"redundant_transcode": true,
"live_stream": true,
"region": "us-virginia",
"output": [
{
"label": "super-important-stream",
"url": "rtmp://primary.example.com/live/stream",
"secondary_url": "rtmp://backup.example.com/live/stream",
"live_stream": true
},
{
"label": "not-as-important-stream",
"url": "rtmp://primary.example.com/live/stream",
"live_stream": true
}
]
}
This will return one stream name, but 2 stream URLs, one primary and one redundant.
{
"stream_name": "as230d982389askdfsdkjf2380ejd93d93dj",
"outputs": [
{
"label": "super-important-stream",
"url": "rtmp://primary.example.com/live/stream",
"id": 260281679
},
{
"label": "not-as-important-stream",
"url": "rtmp://primary.example.com/live/stream",
"id": 260281680
}
],
"stream_url": "rtmp://live01.us-va.zencoder.io:1935/live",
"redundant_job_id": 12345678,
"redundant_stream_url": "rtmp://backup-endpoint.zencoder.io:1935/live",
"id": 98091238
}
You can then set up your encoder to stream to both simultaneously. The example below is using Flash Media Live Encoder, but most encoders support a primary and backup stream url with little additional setup.
With this setup, if Amazon East were to go down (which is unlikely, but not impossible), the backup stream would continue happily on Google Compute Engine without any problems. Assuming you're using a CDN with proper backup urls, such as Akamai, the playback URLs would continue to work as if nothing happened.
For simplicity sake, we only discussed adding a backup URL to a single encoder. This would mitigate any issues downstream of the encoder (like Amazon East getting hit by a meteor), but the stream is still at risk if the encoder is unable to publish for any reason. The backup URL, however, could be set up on a separate encoder, which could be on an entirely different network to be as safe as possible.
Notes
- Since a stream needs to be pushed to both the primary and backup endpoint, this will double the bandwidth necessary to publish a stream.
- The backup job is billed as a separate job at standard live rates.
- Akamai will attempt to align the primary and backup streams before playback, so there may be a short interruption during the transition between streams.
