Scaling the Wowza transcoding in AWS
Wowza transcoding is CPU/GPU instensive and a single server is only capable of transcoding a finite number of streams, no matter how powerful. Running multiple wowza servers can get complex to manage (i.e. what stream is where?) and costly in terms of both hardware (or virtual cloud resources) and licensing. Particularily regarding licensing, you will be paying for the server count you have used at peak during a month.
The setup makes use of Dev-Pay (hourly pay-as-you-go) Wowza instances launched as needed to accomodate any number of streams.
Solution assumes you are familiar with Wowza and AWS and you have already deployed a single-server transcoder-driven Adaptive Bitrate setup that you need scaled.
Rather than building an architecture from scratch, you are to modify your application (i.e. to accomodate distributed transcoding).
HLS, MPEG-DASH and HTTP Origin are supported.
- There will be a delay between a stream being broadcast and its transcoded renditions being available; this is the time needed to start and boot an EC2 instance
- The playback URL format will change (i.e. from "ngrp:" to "amlst:")
Create the transcoder AMI
- Launch a wowza dev-pay instance - i.e.
Wowza Streaming Engine (Linux PAID)
- Change its admin password
- Create application
- Disable source security for RTMP
- Disable all streaming other than RTMP
- Set up transcoding for the
transcodeapplication, the same way it is implemented for your original application
- create an AMI (machine instance) from this instance and make note of its AMI ID
- terminate the instance
Modify your main server and application
- upload provided
- disable transcoding for your application
- add module
highschoolzoom.modules.ExternalTranscoderManagerModuleto your application
- add the following custom properties to your application
awsRegion(type String) - AWS region to deploy transcoders in (e.g.
awsAccessKey(type String) - the AWS access key of an account that has API access to EC2 (e.g.
awsSecretKey(type String) - the AWS secret key corresponding to above access key (e.g.
awsExternalTranscoderInstanceAMI(type String) - AMI of the transcoder created above (i.e.
awsExternalTranscoderInstanceKeyPair(type String) - name of the key pair to to be used for your transcoder instances (e.g.
awsExternalTranscoderInstanceSecurityGroup(type String) - name of the security group to to be used for your transcoder instances (e.g.
awsExternalTranscoderInstanceType(type String) - type of your transcoder instances (e.g.
externalTranscoderStreams(type String) - comma separated list of transcoded stream suffixes (e.g.
externalTranscoderResolutions(type String) - comma separated list of transcoded stream resolutions (e.g.
externalTranscoderBitrates(type String) - comma separated list of transcoded stream bitrates (e.g.
externalTranscoderTerminateAfterSeconds(type Integer) - how long after unpublish to wait (seconds) before terminating a transcoder instance (i.e.
- There will be a delay between publishing a stream, and it being available for playback; this is the time needed to start a transcoding instance, starting its software (Wowza included), proxying streams, starting the actual transcode, etc
- A transcoder will not be terminated immediately, instead the manager will wait for a set time for the stream to be re-publihsed; this is meant to smooth out short disconnects; delay is configurable via the
- There is a cleanup system in place that saves the list of running transcoders to disk; in case of Wowza failure (or deliberate restart) the running transcoders will be properly terminated and/or reused
- master will push and pull streams to/from transcoders via their private ip; enhanced security for the transcoders can be achieved by restricting access via their security group