Amazon's Elastic Transcoder: Clearing the Cloud Confusion

Amazon's Elastic Transcoder: Clearing the Cloud Confusion

“Should we do it in the cloud?”

I get this question a lot. And with good reason – cloud computing has turned massive computational tasks into simple clicks on an interface or calls to an API. So when you’re building out a data management infrastructure, you absolutely need to ask this question.

Last week Amazon announced Elastic Transcoder, a cloud-based video transcoding addition to Amazon Web Services. This touched off a new round of cloud-questioning – but with that comes a lot of confusion and misinformation.

I’m not going to go into the details of how the service works – there’s an excellent walkthrough here, if you’re interested. I’d just like to touch on a few things that I feel are being glossed over or downright misreported.

Elastic Transcoder is not a product

First, let’s be crystal clear: Elastic Transcoder is not an end-user product. It is a backend transcoding service meant to be called by a frontend that you build. So if you’re not willing to code something (or pay somebody to code something), you can move along. The only GUI-based control you have is the submission of a single source file for transcoding into a single output file – and even then, uploading that source file is a separate and manual process. Don’t think you’re going to set up massive watch folders with a few clicks.

Codecs? What codecs?

One of the most important features of any transcoding product is its codec support: what kind of files it will take as input and create as output. Most products have very detailed, extensive lists – like this one from cloud transcoder Zencoder. In contrast, Amazon’s is a bit simpler:

Q: What input formats do you support?
We support popular web, consumer and professional media formats. Examples include 3GP, AAC, AVI, FLV, MP4 and MPEG-2. If there is a format that you’ve found does not work, please let us know through our forum.
Q: Why do you only support H.264/AAC/MP4 output?
We asked customers which format they are most interested in transcoding to and the majority wanted H.264/AAC/MP4.


Now some articles, like this one from StudioDaily, have taken this to mean that other input formats are not supported. That’s incorrect. Mr. Potter specifically states that Avid’s DNxHD and Microsoft’s WMV codecs are not supported for input – except I’ve personally transcoded both DNxHD 145 and WMV9 without a problem. (They’ve since corrected the article – thanks guys!)

So AWS’s platform (probably) supports a much wider range of input formats – but they haven’t documented it, and I’m way too lazy to spend days throwing files at it. However, here’s some formats I’ve tried:

  • Avid DNxHD 145 1080i59.94 – Works
  • Avid DNxHD 145 1080p25 – Works
  • DVCProHD 1080i50 – Works
  • WMV9 – Works
  • ProRes HQ – FAILED

You still have to get your content up to that cloud

This is probably the most overlooked step when considering cloud vs local transcoding: ingest. In a lot of post workflows, you finish your cut, export a master file, then compress from that file. In the case of DNxHD and ProRes, that file is 1GB+ per minute.

Just for kicks, I did a non-scientific test: transfer 1 minute of DNxHD 145 to our local transcode server, then transfer that same file to my S3 bucket.

Results? The transfer to S3 was 50% slower (191 seconds versus 96). I’m on the University of Texas campus; can you imagine how much slower it would be from my home studio? So were I considering cloud transcoding as an alternative to local servers, I’d have to weigh that speed hit against any performance gains.

The tool for the job

Cloud transcoding is amazing, and has enabled companies like YouTube and Netflix (and even my own PBS) to provide services that millions enjoy. But it’s not a magic bullet solution for everyone. As with anything in production: carefully consider your needs, then choose the right tool for your specific job.

And take everything you read with a grain of salt. Even this.