We're rolling out some awesome new audio processing features this week at Zencoder, and we'll be releasing more soon. These features aren't for everyone, we know; most of our customers won't have to to worry about audio gain or highpass filters or equalization. But others will, and we hope to power some cool things with features like this. Here is a quick rundown of the new audio settings.
EDIT: We've posted an updated guide on HTML5 video formats. Go check it out! The <video> tag in HTML5 is a great thing. It enables native video playback in all current browsers, rather than relying on a plugin like Flash. It opens the door to web video on devices that don't support Flash. And it enables codecs that previously weren't web playable. But if you're publishing video content, this can be confusing. To really support web video, how many output versions do you need to create? WebM, Ogg, and MP4? What about iPhone or Android? What about low/medium/high bitrate versions? There isn't a single answer to this question, so here is a short guide to picking outputs for HTML5 video.
The bad news first. There are hundreds of mobile devices out there, and it's basically impossible to support 100.0% of them. The good news is that mobile devices are getting better. Gone are the days when 176x144 3GP was synonymous with mobile video. Modern smartphones can actually play high quality video, and smartphone use is increasing. That's not to say that 3GP is over, or that everyone has a smartphone. But smartphone use is growing (at a 64% annualized rate as of Q2 2010), and, not surprisingly, smartphone users are more likely to watch video on their phones than their, er, dumb-phone-using friends. So if you want to support 90%+ of mobile devices, you need at least two video types: 3GP + MPEG-4 for less sophisticated devices, and H.264 + MP4 for smartphones. That's good news, really. One output video can cover all of your smartphone users - iPhone/iPad/iPod, Android, and (for the most part) Blackberry too. Toss in PSP, PS3, and Xbox 360 for good measure. (If you want to learn more about encoding for iOS specifically, check out our comprehensive iOS encoding guide.)
Zencoder, a growing startup funded by Y Combinator and top angel investors, is looking for a sales professional to drive growth of our video encoding service to web and enterprise customers. T
Zencoder does video encoding, as a service, in the cloud. While we solve hard technical problems - blazingly fast encoding, handling corrupt videos, massive scalability - we also care deeply about user experience.
The stereotype of a Y Combinator founder goes something like this. Programmer. Smart and driven. Went to MIT or Stanford, or else skipped college altogether. Able to live on a ridiculously low salary. Enjoys working 90 hour weeks. And of course: young. Early-to-mid 20s. I almost didn't apply for Y Combinator last year because I thought I was too old. I was 31 at the time. The application asks for age, and I figured they would just ignore anyone who wasn't in their 20s. But friends of mine made it in to the summer class, and they were older than I was, so I thought I'd try. Granted, it can be more difficult to do YC when you're advanced in years, like myself. I have a wife, two kids, and a mortgage. But there are advantages to being a bit older too. Since applications are open for the Winter 2011 class right now, I thought I'd share my experience. Here is a quick guide to doing Y Combinator in your 30s.
A few weeks ago, Zencoder published a new SLA. By SLA standards, we think it's pretty good: if our service isn't available 99.9% of a given month, we issue a service credit of 10%, and for every additional 1% of downtime, we issue another 10% credit, up to 100% of your monthly bill. Frankly, though, we feel a little ambivalent about offering an SLA. Most SLAs are worthless. They often have so many caveats and carve-outs that no one will ever see a single dime. And even when they're strong, they're marginally beneficial at best; for most people, service uptime is far more valuable than the money paid for the service. Think about it this way. If you're paying Rackspace $500/month for a server, and your server is down for 7 days, how much does that cost you? $500? Obviously not. The downtime might cost you $10,000, or even run you out of business. A service credit for downtime is a weak remedy at best. SLAs are redundant too. It would be odd for a service provider to be motivated to stay up by an uptime SLA, because with or without an SLA, an unreliable service provider is in trouble. So at least when it comes to uptime and availability, SLAs aren't a big motivator. So why offer an SLA at all?