“Hey Bruce, can I run your software in the cloud?”, said one of our customers while I was traveling the other week. “Sure”, I replied, “what do you mean by cloud?”.

“Erm, well, you know the cloud. Like the Amazon thing”.

“Why would you want to do that?”, I asked.

“Because, well – it will be cheaper it’s the cloud isn’t it!”.

The conversation continued with an exchange of Amazon price lists and AmberFin price lists, an estimate of conversion volumes and growth rates. We didn’t stop there. We then realized we needed to take into account input bandwidth to the cloud and output bandwidth to retrieve the file, amortization rates that apply to owned and operated hardware, set up costs and a whole host of other operational figures. The result was a little surprising. Over the lifespan of the transcoder, it’s still cheaper to own  a transcode farm than to rent one that sits on the cloud. Moreover the cloud solution ended up with the cloud provider earning a lot of money and the poor transcoder vendor earning a lot less money.

I must confess that sounded like bad news to me, but it also sounded like bad news for my customer. It would mean that the poor transcode vendor had less cash to invest in new codecs, new workflows, new wrappers, QC functionality, metadata mark-up and all those other elements of the workflow puzzle that my customers rely on to turn the humble transcoder into an enterprise class revenue generator.

We then reflected on the future. It seemed inevitable that in a decade or so, transcoding will be a service that you subscribe to in some sort of cloud. The BIG question is how do we get there from here. We decided that the first step was to adjust the customer’s workflow so that the transcode function was less of a desktop application and more of an enterprise service within their facility.