…better to be quicker to market and optimize later
We’ve examined the topic before, just that this time it’s not about Wowza. There are many ways to approach live transcoding and each best fits a particular context.
For this one we’re once again in the nasty case of mostly short-lived broadcasts and ever-fluctuating, unpredictable broadcaster count.
Between cloud transcoding and doing it yourself, I will advise anyone starting up to boldly go with the former, smoothly set their streaming venture in motion, and perhaps consider investing in a custom monster transcoder later. There’s a lot to learn from running at scale, so you may not get it right from the start anyway.
Even the cloud solution is not trivial, it requires manual (read programmatic) starting and stopping of transcoding threads, and finding a smart way to balance cost vs availability. As there’s a cost for keeping a transcoder up, even if idle/unused, and it can take a minute or 2 to start one, the way to go about instantly processing new feeds will be to maintain a pool of idle, “on standby” workers. Logic of how many at a certain time can be improved over time, we’ll start with letting that be a fixed number (i.e. 1 or 2 or 5, easily adjustable manually).
AWS MediaLive was chosen for this architecture, and cost has been the decisive factor. Unlike other providers they charge per input/output and differentiate HD from SD in pricing each. Final price tag ended up being some $1.2/hour for on demand transcoding, and down to under $0.4 by using reservations.
Here’s the open-sourced solution, courtesy of yet another anonymous benevolent client. Some details have been altered to protect their interests.
Does it scale?
Like a charm. AWS transparently allocates transcoding resources for as much as you’d need. Note that there’s a default limit of 5 MediaLive channels and 5 inputs, which is mostly in place to prevent you (i.e. your test scripts) from creating too many by mistake and max out your bill. You can easily raise the limit via AWS Support.
Is it fast?
It depends. And I’m talking about how fast after requesting a transcoder thread you’d get it to actually output transcoded content. And that’s 2-3 seconds if you have one in standby or 1-2 minutes if you don’t. Deciding how many to keep in standby to trade speed vs cost is the key issue here, and while you’ll be good with a fixed amount for starters, the algorithm can be later improved with “rush hour” variations or even smartly adjusted based on stats or machine learning. The coding of that is deliberately decoupled so that it can be easily improved upon.
Is it worth it?
It has been for this project. Rather uncommonly, it only needed live transcoding to 3 SD resolutions from a HD source. May it have to also need HD outputs in the future, that will raise the MediaLive cost to $2.5-3 per hour, so still competitive as compared to Wowza Cloud at $3.5-6 or Azure Media Services at $2.5-3.5
Note that setting up a home-grown solution can bring the price down to $.2 for CPU transcoding and $.1 for GPU. This does however require extra software, skill, maintenance and infrastructure.
One thought on “Affordable live transcoding at scale”
Interesting article. You might be interested to take a look at the Livepeer project which is focused on providing lower cost transcoding infrastructure. Our pricing just went live and provides 5 outputs (1080p, 720p, 480p, 360p and 240p) for $0.005 USD / min ($0.30 USD / hour for a fully managed service available on demand)