> Early on, we decided to focus on selling to engineers.
This shows in their documentation. I am working with their API, and everything is very well documented.
This also shows in their support. Being able to jump into a Campfire room with the same people who commit to their github repos makes for quickly resolved issues.
Switching to Zencoder was the best decision my company made to handle video uploads. They seriously are the best, by far. They even support full HD and audio only, and there are just a few file formats they don't yet support (like GoToMeeting).
If you need video encoding, use Zencoder. Don't even try to figure out your own ffmpeg or related solution, it's not worth the effort.
I wanted to encourage our customers to upload screencast style video demos of their apps to be presented within a product shot of an iPhone or iPad on their website (e.g. http://aeirtalk.com/ and http://homemarks.limelightapp.com/). In order to present the videos using HTML 5, it turned out we must encode the videos into three different formats (H.264, Ogg Theora, WebM.) Zencoder's API request builder made this a total breeze! I don't think I ever read the API documentation. Furthermore, I never have to worry about what format our customers are uploading.
We don't do a ton of video encoding, so our bill is never more than a few bucks a month. It's better than free when you consider how much time we didn't waste maintaining a server with ffmpeg on it. :)
One feature Zencoder still doesn't have (AFAIK?) that I find invaluable is allowing users to upload directly to the encoding service, bypassing your server entirely.
Thankfully, Transloadit (no, not affiliated, just a happy customer) does offer that service- it means that we don't have to worry about handling user uploads as well as not worrying about video encoding.
The solution is to pair Zencoder up with something like Amazon S3. We run on Heroku, so we must allow our customers to bypass our server when uploading videos. (Heroku has a 10 MB upload limit.) In Rails I use the s3_swf_upload gem to allow folks to upload directly to our S3 buckets. When uploading is done between the browser and S3, a JavaScript callback method hits our server and tells it where the upload is so that the app can keep track of the file and tell Zencoder to do it's thing on the file. If you decide to do this, let me know if you need any help.
Zencoder looks good. I'm curious on how their billing process works, or how billing works for PaaS. Does customer prepay to buy credit or do they invoice a customer monthly?
Any estimate as to the time of transcoded content? Also, does the term "video" mean # movies in, or # of streams (movie at certain bitrate/width/etc) out?
Strange business. Professional encoding tools are about $5-6K, so they cater to folks who have large needs, but not large enough to warrant a $6K investment.
Our business isn't professional encoding vs. [unprofessional encoding?]. It's cloud vs. non-cloud. We do what the "professional" non-cloud tools do, but in the cloud, and we have many customers who are investing more than $6,000.
(We're also entirely API-based for programmatic high-volume encoding, so if you're thinking of things like video editing and manual post-production, that's not really what we do.)
> We're also entirely API-based for programmatic high-volume encoding
So why wouldn't folks use the API on (say) Rhozet's tool and maintain control of the flow?
> We do what the "professional" non-cloud tools do, but in the cloud,
Yes, I assume that you have a "professional" engine since you have a team of only 20 people.
> and we have many customers who are investing more than $6,000.
Kudos. Now when they find out that they can take the transcoding API in house for about that much money, what financial incentive will they have to stay with Zencoder?
Capital expenditure. Video encoding is bursty; you either carry a shitload of capacity that stands idle 90% of the time, in order to guarantee SLAs for clients at peak times; or you don't, and you get to explain to the EVP at e.g. Paramount why their content is falling behind.
FULL DISCLOSURE: I worked pro video at Apple and am now a very happy employee of Zencoder.
> you either carry a shitload of capacity that stands idle 90% of the time
But costs less. THAT is the point. (A quad-core is almost there, dual hex xeons will provide 10x capacity. Not enough? Add more cores. At $2000/mo, the payoff is pretty easy in less than a year.)
Look: You guys have a business which is not yet breaking even. Perhaps that will fix itself with a bunch more customers. But as with all businesses, once your invoices start showing up on the CFO's screen, he is going ask to design you out. He will walk down to the office of his head IT geek, who is always trying to justify his salary, and say: What does it cost to take this in-house?
You think the IT geek is going to say: Oh no. We need to have that in the cloud.
I think perhaps you underestimate the magnitude of the difference between the lower and upper bounds of the capacity demands placed on a video transcoding service, and the difficulty of building one in the first place.
Software only. Determine your need for the number of processors and add that on.
I'm looking at their $2000/mo plan for 100,000 minutes of video. Compare: Modern hardware does HD faster than real time, there are 43,000 minutes in a month. So for a quad core machine, you already have a comfortable margin.
This assumes that you can evenly distribute your transcoding load over the course of a month. For most customers, transcoding needs are severely peaky - 10x or more from peak-to-average. So you either buy for the peaks and your hardware goes idle 90% of the time, or buy for the average and see long queue times. For most video publishers, each on-premise machine ends up using only a small fraction of 43,000 minutes each month.
> This assumes that you can evenly distribute your transcoding load over the course of a month.
No it does not.
A low priced quad core is already in excess of their highest listed service, for less money.
Put a dual hex xeon into service and you have at least 10x the capacity (remember that even HD transcodes at faster than real time), and it pays off in less than a year.
Aha, salt consumed. I didn't connect it with the other comment above. I've deleted some of my other comments, we might as well make people do their own research on this.
Cost of bare hardware is not what makes companies move to the cloud.
Hardware / software licenses is an investment, cloud is opex (operational expense): it means you don't invest much upfront (Zencode, Amazon, etc. made that investment for you), but you pay over time. If your treasury is low you may not even have a choice between investing or using the cloud to begin with.
So you are going to say: in the long run, opex is more expensive than a wise investment that pan out well.
That's called risk management, and is the main reason many companies choose cloud services over in-house. You might invest in the wrong hardware, the wrong licenses in the case of encoding audio/video, or the wrong Linux/*BSD/Windows administrators. Switching away from Zencoder is comparatively easy and cheap.
It's a trade off, you are basically paying a premium to reduce your risks.
That was posted few weeks ago. It's from zencoder's site, comparing to other 3 competitors (probably biased), but shows that there is already competition:
Sorry, but I can't help but feel that it wouldn't be that difficult to get similar performance by setting up a free AMI for people to do exactly this sort of thing using their own EC2 instance. What kind of value does zencoder actually add vs. running an ec2 instance with ffmpeg handling the transcoding?
That doesn't really answer my question (and I am a potential customer). How exactly does zencoder add value to justify their additional costs? Converting video with ffmpeg is trivial in my experience. What exactly does zencoder do that's better than anyone else? Has zencoder actually extended ffmpeg in a deeply meaningful way--e.g. modified the codebase to handle new codecs, new containers, or transcode much, much faster than a basic ffmpeg install? The website is not particularly helpful in that regard and strikes me as a bunch of smoke and mirrors surrounding a pedestrian ffmpeg implementation running in the "cloud."
In my experience it is far more efficient to transcode very high resolution files (4k or even 1080p) locally, and then upload a real deliverable (at much greater speed now that it has been compressed).
As a short answer, though, we're actually quite cheap for most customers. Major internet publishers use Zencoder for a few hundred dollars/month. Large-volume providers use us for less than the cost of a full-time engineer - and the alternative to Zencoder at large scale is a team, not a single engineer. Mission-critical encoding requires a lot of engineering and operations, even when starting from the excellent open-source libraries available.
Beyond that, we generally do things faster, more reliably, and at higher quality than "default" encoding systems, especially around the edges. That's what happens when you throw >10,000 hours of engineering at this problem. Again, get in touch if you want specifics.
Just to compare/contrast, we do more video/minute at Zencoder than the iTunes video ingest system could handle, with many fewer engineers, a far smaller budget, and a much broader set of capabilities.
To a certain extent, this is an apples and oranges comparison, but the service model really seems to fit precisely with video encoding (or I wouldn't be here).
I find it a little strange that they even mention their competitors, it feels like they're so far in front in terms of product that it may be unnecessary.
We've offered a cloud transcoding service since before Zencoder was spun out. But we don't really market it, it's normally an consultative add on for our VDN customers (we interview about reqs then configure transcoding profiles for customers not interested in having to know), though you can buy it alone.
That said, love what Zencoder's doing. Very good for the industry.
This shows in their documentation. I am working with their API, and everything is very well documented.
This also shows in their support. Being able to jump into a Campfire room with the same people who commit to their github repos makes for quickly resolved issues.
Keep up the good work Zencoder!