AWS is cheaper as terpua mentioned... but Zencoder has been awesome for us. Easy to set up and our video processes have been running with zero problems.
Most people underestimate the cost of handling FFmpeg and all it's particularities and the complexities inherent to each video format. Especially if you support "any" format on the input you quickly end up spending a lot of time dealing with heuristics (which evolve with each FFmpeg release). Development and learning time might be a bigger cost than the potential savings.
The target format is also really important. WebM is around twice as slow to encode than h264 for the same resolution. And HD doubles the encoding time as well.
Now if you look at the Spot instance market, you can have a c1.xlarge for $0.07 / hour. Given that you can encode ~6 h264 SD videos in near real-time on that instance, it would cost you ~0.0002 / minute of video (if you don't need other infrastructure services). This is the bottom-line.
FFMPEG is great for personal use but unlikely to be used in production systems.
1. Its not "enterprisy". By that mean there is company behind the codecs who can provide support 24x7 on quality issues, robustness, warrenties etc..
2. The ugly word - Patent covered. A lot of video technology has licensing and patenting. The moment sometime as big as Amazon tries to use a codec, the sharks will line up unless they have the right license.
We're not talking about broadcasting but transcoding, which is a very different workload.
FFmpeg is used by Youtube, Vimeo, ZenCoder, Transload-it and PandaStream (where I'm working at) to transform the videos. Hardware encoders are great for a specific target but FFmpeg just supports most the rubbish video formats that customers like to throw at us.
given that sites tend to only encode to a few formats, and given decoding is cheap cpu wise: couldn't you pipe the output of the ffmpeg decoder into a hardware encoder and get the best of both worlds?
When I worked at ClearChannel, it was the other way around...live feeds (e.g. Rush Limbaugh's HD video feed) came out of a bank of MOTU livestream encoders and was then fed through ffmpeg to be downsampled to web and mobile.
You mean the worst of both worlds? Hardware encoders are both more expensive and less elastic; software can just run on the existing EC2 infrastructure.
With video transcoding you push batch jobs that can be processed at any time. The video is taken from a S3 bucket and the result is put back in another place. When transforming the video you might use some heuristics on the whole file (because some formats have the metadata at the end). You can also implement fallbacks when the transcoding fails.
With live streaming you need to acquire a streaming video source, transform it in real-time and forward the stream without too much latency and without failure. Then you need to push that stream to the N connected people possibly fanning-out the traffic to multiple servers to dispatch the load.
