I need a Wowza/AWS Engineer to reduce costs
Live transcoding is never easy. Doing it yourself from scratch may be way too complex, running it off a cloud service looks like a rip off. Middle ground solutions still involve a lot of decision making.
It gets worse if you run non-24h streams and their number fluctuates. The optimal strategy depends a lot on how many streams you are running and the dynamics of these. As they’re rarely predictable, yet tend to peak at various times of day or week, provisioning enough capacity for all is definitely a waste.
Wowza has long had transcoding built-in, but as they’re promoting the cloud they document no way of scaling the server product. And if you’ve customized a bit of it, the cloud may no longer be compatible. Not to mention costly.
Customer was running a single Wowza server in AWS, capable of transcoding a handful of simultaneous streams. It was good enough at the time but as the portal grew in popularity it would require more and more resources, up to the point where even the most powerful AWS instance would no longer be good enough. Furthermore, given the nature of the business, most events would run at the same time of day or week and the ever pricier single server would sit idle for most of the time.
The proposed solution was quite simple and them knowing exactly what they wanted helped a lot. The existing Wowza would stay in place and be turned into a “master”. It would do no transcoding on its own but instead spin up ephemeral transcoder workers in independent EC2 instances. Upon a new stream getting published to the “master”, it would start a transcoder instance, push the unprocessed stream to that, and pull the transcoded streams back from it. Very little would change for the application layer as broadcasting and playback would stay almost the same.
There’s a a downside to the approach, the processed (transcoded) feed would only be available some 1-2 minutes after it had started, this being the time needed for the instance to initialize. Yet, given the scheduled nature of streams, this would not be a problem.
They courteously agreed to share the solution with the world and here it is, complete with some instructions. Do make sure it fits your needs.
Does it scale?
Not fully. Although not doing any transcoding, there’s a limit to how many streams the single “master” can handle. But rest assured that number’s pretty high, I have a client running more than 700 streams on a common Wowza configuration.
There are ways to programatically make this a multiple-‘master’ setup so that it scales all the way. If ever needed.
Is it stable?
I would say so. It’s been running since January and I’ve had no complaints.
Is it worth it?
It depends 🙂 It sure has for them and still can’t think of a better setup to fit their needs. But again, this was a very particular use case to start with.
Unmentioned, they had customized the transcoder to display some nice scoreboard overlays. Unless ready to recreate that, the solution had to stay within the Wowza confines.
The transcoder instances management could have been set up at some other level (i.e. Lambda) but we decided to just build it into the ‘master’ Wowza as it would be compact to deploy and easy to grasp by the team in place, since they already had some exposure with coding Java for Wowza.
Not least, they had already invested in wowza licensing long term. And it would pay out as they’d continue to use it on the ‘master’ (which has to run 24/7 anyway as it’s also serving VOD) while paying by-the-hour to for the transcoders’ licensing.
Even if any of these is your case, it may still be viable. Especially if you come from a Wowza background and don’t want to spend much time looking around for options.
