Here are some words from Screenlight founder Chris Potter on the technology behind their service.

Want to be featured in a blog post?  Hit us up at info@zencoder.com and let us know what you’re up to

What do you do at Screenlight?

Screenlight offers a private video sharing and collaboration platform that makes it easy for video producers & editors to securely review videos with clients, get their feedback, and get video projects approved. The service solves communication and platform compatibility issues that people experience when using DVDs, email, FTP, YouTube, and custom solutions to review and approve videos.

ScreenLight provides a private online hub where video producers can upload and share videos with teams and clients. Video projects are password protected, and people will only see projects they have been invited to participate in. Project communication is kept in one place with blog-style comments that can be entered for each video. The service can accept virtually any input video format, and videos are automatically encoded for playback on desktops, advanced smartphones, and the new Apple TV.

Whereas most online video platforms are about mass distribution of video, Screenlight is about private viewing with invite only groups of participants. Video production is an inherently collaborative process, but until now, there have been few mass market online tools to make it easy and affordable for video producers editors to collaborate with clients outside the edit suite.

How are trends in the marketplace effecting your technology decisions?

Our customers needs are constantly changing and we work to evolve the platform and keep them happy. Customers want to review and collaborate on video production anywhere, anytime, anyplace (much how they want to watch television). This need to review video on the go (especially on the iPad) was a major factor that drove our decision to automatically encode client videos for cross-platform delivery. Customers can now review videos “outside the edit suite” on mobile devices without having worry about codecs, encoding specs, HTML5 vs. Flash, or the delivery method that is used.

What types of encoding solutions did you look at? What led you to choose Zencoder?

We looked at several alternatives and how they would stack up in terms of quality, encoding speed, scalability and reliability.

• Quality: Video quality is the livelihood of our customers. We absolutely had to deliver high quality video that would look fantastic on different devices.

• Encoding speed: Our value proposition to customers is that we can help them can save time with video review and approval. If videos take too long to encode, then we can’t deliver on our promise.

• Scalability: The volume of uploads that we process each day is highly variable. We wanted a solution that would easily handle our peak demand without videos getting stuck in a queue. The ability to simultaneously encode video into multiple formats was also an important component of this.

• Reliability: Encoding is a tricky business, and we wanted a solution that would meet our customer needs in terms of uptime and successful video encodes.

Rolling our own solution in a way that would meet the requirements above would have been costly and time consuming. A big concern with this option was that there would be encoding bottlenecks and that we would have to manage spinning up and spinning down a bunch of servers to manage peaks and troughs in our daily encoding volume.

We looked at alternatives that charged per dedicated encoder. The issue with this model is that it forces you to make the choice between buying the number of encoders that you need during peak times, or provisioning for your average capacity and accepting that videos will have to sit in a queue during peak periods. Neither choice was acceptable to us.

Since we started using Zencoder we have had fewer video playback problems, the quality pleases even the most discerning eye, we can support playback on iPhones / iPads, and customers appreciate not having to think too much about the settings for the video they upload. In short we have a more reliable service and happier customers since we integrated with Zencoder.

What’s your favorite Zencoder feature?

It might sound strange, but two of our favorite Zencoder features (and ones that helped swing us towards Zencoder) were the API documentation and the per-minute pricing model.

The documentation was really important because it provided a signal about the quality of the customer experience that we could expect. Since documentation is usually an afterthought, your clear documentation was a sign that you put a tremendous amount of care into the service. It made integration easy and totally frictionless. We didn’t need to call on customer support or use forums for help.

The pricing model was important because it provided predictable costs that were easy to model. I think this model does a much better job of showcasing Zenconder’s value compared to charging by file size (data transfer in and out).

Please share a recent company milestone.

We are excited about having completed a full overhaul of the look and feel of the application in December and a revamp of the marketing site in January. We’ve added automatic video encoding, support for playback on iPhones/iPads, and a much larger video player (960*540) that puts customer videos front and center on the desktop. We also started the year off by significantly increasing the amount of storage in all of our plans. We expect that 2012 is going to be a game changer!

What’s the most exciting trend in online video at the moment?

I find it really exciting to see how innovation in the video industry is being driven by a continual reduction in the cost and complexity of making and distributing great video. As video moves beyond the television and the desktop onto mobile devices it will shape our lives in a pretty profound way. Online video is changing how we learn, how we tell stories, how we entertain ourselves, how companies market themselves, etc. It’s a really exciting place to be!

In recognition of the importance of content in advancing the online video industry, we’re highlighting our partner Concrete Interactive and the amazing product that they’ve built for HitRECord.   HitRECord, founded by actor Joseph Gordon-Levitt, not only facilitates the creation of high quality Internet video but is also unique in that it’s democratizing, and bringing real innovation to, the process of content creation.

Founded in 2005, HitRECord has established itself as a unique destination for video artists, filmmakers, writers, animators, musicians, and videographers to collaborate and interact with Gordon-Levitt and others on a wide variety of creative endeavors.  HitRECord’s library has grown to over 20,000 complete videos.  Almost 1,000 contributors have used HitRECord to create films and video, which are available in the “TheRecord Store”. Thousands more have contributed to films shown at HitRECord’s live shows. When a production makes money, there’s a 50/50 revenue split between HitRECord and the co-creators.

Even though we didn’t get to hobnob with the stars in Park City, we were excited to hear of the successful showcase of HitRECord’s works, which were featured last week at the prestigious Eccles Theater as part of the 2012 Sundance Film Festival.  Joseph Gordon-Levitt emceed a sold-out screening, presenting films that were developed on HitRECord.

A few factors are making this explosion of Internet content possible.  First, it’s getting cheaper and cheaper to create content.  The cost of HD cameras and powerful editing suites have fallen rapidly, making it possible to create professional content on a small budget.  On the distribution end, highly efficient software and cloud-based infrastructure make it possible to rapidly deploy Internet video applications with a relatively small upfront investment.

To build HitRECord, Concrete Interactive, the San Francisco-based boutique web application development firm, used technologies such as Rubyon Rails, Heroku, Amazon S3, JQuery, New Relic, Splunk, Airbrake, and Kissmetrics. They use Zencoder, and relied on our industry-leading performance to encode HitRECord’s library. They were able to convert tens-of-thousands of videos into web and mobile outputs overnight, for playback across a variety of devices.

Most importantly, the end product is a very high performance platform that facilitates the creative output of its users.  Joseph Gordon-Levitt, or “RegularJoe” on HitRECord, said, “Since working with Concrete Interactive and Zencoder, HitRECord’s video upload process has been smoother, the quality is excellent and processing times are really quick.”

Encoding for iOS is a little tricky, though. iOS devices have gone through several generations of technical capabilities, and the ideal video settings for the iPhone 4 are not ideal for the iPhone 3GS or for the iPad. Fortunately, with just a few encoding profiles, you can stream high quality video to every iOS device, from the first iPhone to the iPad 2, and even prepare for future generations of mobile hardware. We’ve written about this before but our previous guide only described how to ensure mobile compatibility – not how to find the best settings.

This article is the first in a series of encoding recommendations. At Zencoder, we get asked for encoding recommendations all the time, and we end up recommending the same (or similar) settings over and over. We’re going to start publishing our recommendations to our blog and to our docs in an effort to help Zencoder customers (and non-customers) make good decisions about how to encode video for a wide range of targets: mobile devices, Flash, Silverlight, HTML5, connected devices, and more.

(For deeper information on HLS and iOS video, be sure to download our guide to iOS video, which goes into more detail about HTTP Live Streaming and iOS video delivery.)

General settings

Like most video today, use H.264 video and AAC audio when targeting iOS. On the audio side, consider using HE-AAC at <64kbps, for App Store compliance. HE-AAC sounds reasonably good at these bitrates, even for complex audio. On the video side, use multiple profiles to target each device. iPhone 3GS and earlier only support H.264 Baseline profile, level 3.0 (and some support a more constrained version than that), whereas newer devices support Main and High profile.

For the best user experience, HTTP Live Streaming is a must. Apple requires it of any video app in the App Store that plays content longer than 10 minutes, and it is the only true streaming format supported by iOS. HLS is also being adopted by Android (version 3+), Roku, and a range of other destinations. Zencoder fully supports HLS, and does so better than anyone else in the cloud.

General approach

Why these recommendations?

• These are just recommendations. Different resolutions and bitrates are perfectly valid, and may actually be preferable in some circumstances. For example, extremely complex content may warrant higher bitrates.
• 720p is the largest video playable on iPad 1 and iPhone 4, and iPad 2/iPhone 4S play anything up to 1080p. But since the native display is only 1024 pixels wide, going all the way to 720p or 1080p isn’t critical. Unless, of course, you want to reuse a video somewhere else – 720p is a great resolution for fullscreen web playback, and 1080p is entirely appropriate for connected TVs. Future iPads, by the way, are rumored to have 4x the resolution of the current iPad, so consider adding 720p for future-proofing.
• H.264 profile is important. iPad 1 and iPhone 4 both support Main profile. iPad 2/iPhone 4S support High profile, which is marginally better than Main, but given the tens of millions of iPad 1 devices in the world, it is probably better to stick to Main profile. Of course, for truly optimal device targeting, encode to both Main and High.
• These 6 resolutions and bitrates provide reasonably good coverage of varying bandwidth. You could certainly do more – Apple recommends 8 – so add or subtract resolutions and profiles as desired.
• Legacy iPhone/iPod Touch users will have three streams available to them, including a reasonably high quality 480×320 video (the screen resolution of these devices). iPad and iPhone 4 users will be able to make use of all six streams.
• The resolution scaler on the iPad is pretty good, so videos that are rescaled will generally look good.
• As much as possible, these settings allow for resolution dimensions divisible by 16. This makes for more efficient compression. The efficiency gains are small, especially at high resolutions, but at lower resolutions they start to make a difference.
• Be sure to keep the audio identical across each video. If the audio specifications change from one version to another, the user may hear pops and clicks during playback when switching streams.

Other settings

• Speed: set this based on desired turnaround time. For these recommendations, we’re going to use Speed 2, which improves compression a bit over the baseline but is still reasonably fast.
• Peak limiting: ensure that each segment is roughly the same size by using a peak bitrate_cap of 150% of the target bitrate, but within a long buffer_size (e.g. 5 seconds, or 5x the bitrate_cap).
• Zencoder automatically chooses proper keyframe placement when you set the type to “segmented”. If you’re encoding to MP4 for separate segmenting to HLS, set “forced_keyframe_rate” to “0.2″ or “0.1″ (for 5 or 10 second keyframe intervals, respectively).
• If you can accept slightly unpredictable bitrates, add quality to the mix, and change video_bitrate to max_video_bitrate to optimize for file size. The encoder will use the max bitrate when needed, and will use a lower bitrate when it can achieve the desired quality with fewer bits.
• Set the max_frame_rate to 30 and the max_audio_sample_rate to 48000.
• The first generation if iOS devices only allow 1 H.264 reference_frame, so enable this on the Baseline streams for max compatibility.

For more information…

The Zencoder guide to HLS encoding – Best Practices for Encoding Video for iOS Devices – goes into more detail on the HLS standard, App Store requirements, advanced HLS features, and provides six tips for expert HLS encoding.

Already the most widely downloaded open source HTML5 video player, the new version of Video.js offers significant feature enhancements and the easiest way to reach consumers on multiple devices and browsers.

Here are some words from VidCaster founders Ray Pawulich and Kieran Farr on what they’re up to, and how they use Video.js.

What does VidCaster do?

VidCaster is an online video platform — but unlike traditional online video platforms, which offer what we call a “player-only” solution, VidCaster powers entire video websites. In the same way that companies use platforms like WordPress and Tumblr to power their blogs, companies like Airbnb, Zendesk, and Turnstone Furniture are using VidCaster to power their own branded video websites.

What prompted you to transition to HTML5 video?

Our clients rely on our technology to deliver videos that drive their business goals, so making sure those videos are available in a consistent experience not only on desktop PCs but also on mobile devices is absolutely critical for our business. HTML5 is the only video delivery method that can truly deliver on that promise today.

What challenges do you face in the transition?

VidCaster users have the ability to connect to a wide variety of third-party video services that haven’t quite made the switch to HTML5 yet. Overhauling our system in such a way that still retained compatibility with those services was definitely a challenge — but one we were happy to take on.

How did you decide to use Video.js, and how did it help you meet your goals?

Without a doubt, Video.js is the leading HTML5 player. Not only is it fast and reliable but its appearance is easily customizable using CSS. For VidCaster users, it was an obvious choice.

What are your favorite features of the new Video.js?

The fact that Video.js overlays the same HTML5 controls on top of the Flash version of the player is really cool. It’s literally seamless so our users may never even detect a difference but it’s one of those technical details about online video delivery that we obsess about so our users don’t have to.

What is the most promising trend in Internet video right now?

Well, we’re very bullish about video sites! Users increasingly want full control over how their videos are presented online so there are many synergies between the video site movement and the rise of HTML5 video — with our new Video.js-based player we’re excited to help bring those trends together.

Want to be featured in a blog post?  Hit us up at info@zencoder.com and let us know what you’re up to.

So how do you manage this complexity? What are the best practices for encoding large volumes of video?

As the leader in the cloud encoding space, Zencoder knows more about high volume video encoding than just about anyone. We encode millions of videos each month for hundreds of customers, and provide hands-on support to these customers whenever needed. So we have seen just about every approach to high volume video encoding, and we know what works well and what doesn’t.

Over the last few months, we’ve reflected on what we’ve learned, and have distilled a list of 12 rules or patterns for successful high-volume video encoding. Here is the basic list, along with a brief summary of each pattern. More discussion will follow.

1. Focus on total library size. The right approach to bitrate can reduce library size by 30% or more, with no effect on perceived quality. At large volumes, this can mean enormous savings.

2. Make your video beautiful. There is no excuse anymore for less-than-perfect video. Take the time to find the encoding settings that make your video look great.

3. Target more than one device with each output. The same file can often be repurposed for multiple target devices – web, mobile, TV, and beyond.

4. Use adaptive bitrate streaming. Without this, you can’t ensure a good user experience, your CDN bill will suffer, and you can’t deliver video to certain devices at all.

5. Eliminate bandwidth bottlenecks. At large volumes, data transfer becomes a bigger problem than transcoding. Choose hosting and transfer approaches that eliminate this problem.

6. Use elastic transcoding resources. Video transcoding loads are enormously variable. Encoding is a perfect candidate for cloud computing resources.

7. Demand 100% success. Transcoding shouldn’t fail due to codec incompatibility, scalability problems, or random instability.

8. Use the same system for large batches and for daily workflow. These are two sides of the same problem, not two separate problems.

9. Stay above board with licensing. Legal, properly licensed video publishing isn’t really that difficult.

10. Don’t wait for others. Or for yourself. Keep queue times miniscule and predictable, at any scale.

11. Choose your speed. Some video encoding should happen near-instantly, while other encoding isn’t needed for hours.

12. Keep a transparent quality copy for archiving. In the constantly changing world of video publishing, proper archiving is critical.

We’ll be writing more about these patterns in depth over the next few months, explaining each pattern and describing why it matters. Each pattern will be backed up by real-world examples, data, and recommendations.

And while we’re obviously biased towards some approaches, these rules are applicable to anyone doing large-scale transcoding, whether you’re using a cloud encoding service like Zencoder, running in-house encoding software or hardware, or rolling your own. We’ll be up front about our opinions, and we will even recommend some things that run counter to the way Zencoder works. And remember that if we weren’t opinionated, and didn’t care about finding the best approach to high volume encoding, we would never have grown to become the market leader.

The original Zencoder API (V1), used for the majority of API requests made to Zencoder, has been at https://app.zencoder.com/api/. It is now at https://app.zencoder.com/api/v1/.

The new Zencoder API (V2) is at https://app.zencoder.com/api/v2/.

Note the “v1″ and “v2″ in the URLs, indicating the version of the API used.

For the next 6 months, until June 1st, 2012, API requests to https://app.zencoder.com/api will continue to work as they do today (ie V1). Starting June 1st any requests that do not specify a version will use Zencoder’s edge (under development) API, which will be discussed in a later post.

Additionally, on June 1st, 2012, API V1 will be removed. At this point all users will have to switch to API V2 or another version, if one is available.

The Flixcloud API will be removed at this time as well, on June 1st, 2012. Any Flixcloud users who migrated to Zencoder when it was shut down will need to switch over to use the Zencoder API now. As always you can contact support with any questions you have as you make the transition.

What’s New in API V2?

There’s a lot of great new features available in V2 that make working with Zencoder even better.

Rich Notifications

Rich notifications is one of the most common feature requests we get. In V2, notifications now include all metadata about the input, the output, and the job, in addition to the state that was sent in V1. Read more in the docs.

Backup Storage

Sometimes servers go down, or are unaccessible. This used to mean your job would fail, but now if we’re unable to connect to your server we’ll save the file on Amazon S3 for 24 hours instead. If this happens your POST notifications will contain an extra parameter called “backup_url_used”, and it’ll be set to true. Additionally, the URL for the output file will be changed to the S3 URL where your file is being held. You, or your application, can then download the file to your server at your convenience. Read more in the docs.

More Progress APIs

In V1 it was possible to use the API to request progress of outputs, but not inputs or jobs. We’ve now added progress for both of them, so you can return more information back to your users about the state of their files. Read more about input progress and jobs progress in the docs. Additionally, output progress has changed to include more information about what’s happening.

Reporting and Grouping

Some users have a single Zencoder account handling their video encoding for multiple clients or departments and want to know how usage is spread across them. Grouping creates collections of jobs whose usage can be retrieved via the new reporting API. Read more in the docs.

Dependent and Transfer-only Outputs

Outputs can be created that won’t run until another has finished, allowing you to create a single output and transfer it to multiple servers. Read more in the docs about dependent outputs and transfer-only outputs.

Aspera Transfers

Aspera supports high speed file transfer over UDP rather than HTTP, which means Zencoder can transfer larger files quickly from your Aspera server, getting your videos transcoded and back to you faster than before. Read more in the docs.

Conditional Outputs

Accepting user generated content means you never know what you might get. Converting a 320×240 video to 720p just leaves you with a poor video or multiple copies of your output at the same resolution. Conditional outputs let you skip an output if it the input file is too large, too small, too long, or too short, rather than going through the hassle of inspecting the file on your own or submitting multiple jobs. Read more in the docs.

New API Request Methods

We’ve changed the HTTP method used for a few of our less used API methods. Canceling jobs and resubmitting jobs now use PUT instead of POST requests, and PUT requests are required for changing account integration mode.

Updating Existing Code To Use The New API

If you’ve written your own code for interacting with Zencoder then switching to the versioned API is as easy as changing the URLs you use to make requests. If you are using a library to interact with Zencoder it’s pretty easy to switch those too. Along with the new functionality in the Zencoder API we’ve updated our Ruby and PHP libraries, and some of our users have updated their libraries as well.

The Zencoder Ruby library has been updated to default to use V2. This update includes other significant changes, so check out the ReadMe for more information on what it does and how to implement it.

If you are unable to upgrade to the latest version of the Ruby library, you can add Zencoder.base_url = "https://app.zencoder.com/api/v2" in your initializer where you set your API key to start using V2.

The Zencoder PHP library has been updated to default to use V2. This update includes some significant changes, so check out the ReadMe for more information on what it does and how to implement it.

If you are unable to upgrade to the latest version of the PHP library you can make requests to any URL using the general API request method discussed in the ReadMe. You can also edit a single line in Zencoder.php and change it to https://app.zencoder.com/api/v2, which will make all requests use the V2 URL.

In the Zencoder Python library V2 is now the default in version 0.4 of the library.

As the Zencoder libraries created by some of our fantastic users are updated to support versioning and V2 we will add instructions on how to update them as well. If you have any questions about updating your library, contact us.

Versioning Makes Things Better

Versioning is going to let us move forward with new features more aggressively because we can add new features and options that aren’t backwards compatible without worrying about impacting users who are currently relying on them. We will do our best to keep versions alive as long as it makes sense for us to support them and will give plenty of notice before removing any API version. This is our first step for versioning, and we’re still figuring out some of the details as we go, but we plan to follow this convention as we release new versions of the API. We welcome your feedback as we continue making Zencoder better.

All of this video – like most mobile video today – was delivered using HTTP Live Streaming (HLS), an Apple-created, HTTP-based format for streaming H.264 and AAC video in an MPEG-TS container. HTTP Live Streaming works by segmenting a long video into short pieces, typically 10 seconds, and then providing a M3U manifest that lists each segment. The player reads the manifest and determines when to pull each segment in order to ensure seamless playback.  (If you want more in-depth info on HLS, check out our guide on best practices for iOS encoding.)

The problem is that MPEG-TS is an inefficient format, especially at low bitrates. The MPEG-TS format can easily introduce 10%-15% of unnecessary overhead to a file compared to a format like MP4, which increases costs and decreases picture quality, MB-for-MB. And if you’re deploying a video application to the App Store, HLS isn’t optional – it’s mandatory if you want to display video longer than 10 minutes. Apple has rejected countless applications from the App Store for not complying with this policy.

The good news for PBS and other Zencoder customers is that we have recently released major optimizations to our own custom HTTP Live Streaming segmenter. Our optimizations result in major file size improvements compared with many mainstream transcoding providers, and have the potential to save PBS 10% or more of their CDN and storage bill each month.

Here are some results. Notice that the overhead is significantly higher, as a percentage, on low bitrate content. Of course, mobile video delivery is usually done at low bitrates.

These numbers were taken from Apple’s Media Stream Validator tool. We ran the same file through each system using the same settings: H.264, AAC, 320p resolution, 64kbps audio, 300kbps/800kbps video, and asked for HLS output with 10 second segments. Notice that the overhead goes down as bitrates increase, so at high bitrates, TS overhead is not as important. (If you’re interested in running some tests to verify the results, get in touch – after you run the tests, so we can’t manipulate them – and we’ll give you a service credit to cover the processing.)

How is this possible?

The MPEG-TS format is an older container format that is widely used in the broadcast world, for everything from satellite broadcast transmission to Blu-Ray discs. When the MPEG-TS standard was designed, long ago, it was used by resource-constrained devices who were more sensitive to processing power than bandwidth. Because it is designed for old networks, and because of the small packet size (188 bytes), MPEG-TS can introduce more file overhead than a format like MP4. That was an appropriate trade-off in 1995 – inefficient, but simple, packet placement allowed for early 90′s hardware to decode MPEG-TS, and MPEG-TS was rarely used for low-bitrate transmission before HLS came around. A bit of padding overhead doesn’t really matter on a 15Mbps 1080p stream. But now that MPEG-TS is used in a low-bitrate context, and today’s mobile devices have more processing power than supercomputers of a few decades ago, the situation has reversed, and bandwidth-efficient (but more complex) MPEG-TS is much preferable.

HLS doesn’t require the simplified padding (and increased overhead) of the MPEG-TS format, and so Apple has actually optimized its proprietary HLS tools to reduce overhead. The reductions can be significant.

We’ve done the same at Zencoder. By combing through the MPEG-TS format at the TS and PES packet level, we’ve been able to achieve a similar level of optimization to Apple’s own tools. We’ve done this through the same approach Apple takes: more efficient placement of PES packets which allows for the removal of unnecessary padding.

Why not just use Apple’s tools?

Some people already see this level of optimization, by using Apple’s proprietary segmenter (mediafilesegmenter). And if you want to deploy to Apple hardware, this is a reasonable way to go. But Zencoder runs on Linux, in the cloud, and a large-scale deployment of Apple hardware just isn’t practical for us. A heterogenous environment is hard to manage. It takes significant devops to run a cloud service, and each additional platform – hardware, operating system, software stack, security model, monitoring, scaling – adds significant complexity. We also get better performance by locating our transcoding and HLS segmenting together in the same system, obviously.

But more importantly, HLS is not just an Apple standard anymore. Many devices are starting to support HLS – Roku, Android, and a number of upcoming platforms are embracing HLS as a streaming standard. So locking ourselves down to Apple’s implementation may not be the right decision long-term. What happens if Apple’s mediafilesegmenter tool doesn’t support everything supported by Roku, or one HLS implementation starts to deviate from another? Without access to the source code, we would be out of luck. HTTP Live Streaming is becoming important enough that we need a flexible implementation that will work well with every implementation, on any device, both now and in the future.

• Our transcoding volume is more than 1% of YouTube’s volume. We’re doing a few percent, in fact. We think that’s pretty cool.
• Over the last 12 months, we’ve grown by 15x. Since our launch 18 months ago, we’ve grown by more than 20% month-over-month.
• Based on public information, we believe we’re the largest cloud-based encoding service around. By about 2x.

Before we get ahead of ourselves, we’re still small, all things considered. We’re operating in a competitive, quickly changing industry. In other words, we’re still at the beginning of the marathon.

But now that we’ve been operating for 18 months, it’s interesting to stop and reflect on what has contributed to our growth, for better or for worse. Looking back, here are the three things that most contributed to our success.

The most important thing you can do

When we started Zencoder, we had a huge advantage: we’d been in the cloud transcoding space before. In 2008-2009, we built Flix Cloud, an early cloud encoding service, as a partner product with On2 Technologies. Through that process, we were able to talk to dozens of real-world customers.

Talking to customers isn’t optional. It’s the most important thing you can do as a startup founder. We’re big fans of Steve Blank and Customer Development, and one of his central themes is that startups actually don’t know anything. Startups have hypotheses, not facts. If startups had facts, they wouldn’t be startups anymore – they’d be mature companies executing on proven business models. But in reality, in any emerging industry, most things are unknown, and the answers aren’t in the founder’s head – they’re outside the office, in actual user behavior.

Before we wrote the first line of code, we talked to dozens of customers. We cold-emailed video publishers and bought them lunch. We did Skype calls with friendly contacts at media companies. And, of course, we had the benefit of talking to customers during the Flix Cloud days. This gave us deep insight into the needs of our customer base.

Love your customers

Early on, we decided to focus on selling to engineers. We did this for two reasons.

First, we had a theory that the right way to build a cloud-based service over the long run was to focus on making developers happy, not making VPs happy. Our model was AWS: Amazon Web Services grew from the bottom up, not the top down. There were 100,000 passionate Ruby and Python hackers talking about AWS before the first VP said “We need a cloud strategy” (whatever that means). We figured that we would have an easier time getting into the enterprise through the Engineering department than through Business Development.

In retrospect, this was often true, but not always, and we’ve since revised this hypothesis a bit. And we don’t only sell to developers – we now work with large enterprises, major media companies, and broadcasters. But even with enterprise customers, our approach is that of a technology company. Zencoder is great technology first, and slick enterprise sales second.

Second, we’re engineers ourselves, and so we know how engineers think. This made it easier for us to sell to them. Engineers like well-designed APIs, responsive support, and products that Just Work. Engineers don’t like buggy software, “Call for Pricing”, and marketing BS.

When you’re a developer, selling to developers is awesome, and we love doing it. It’s always easier to sell to yourself than to someone else. What’s more, developers on the whole are a good bunch. They’re smart, honest, and fair. When you screw up, they tell you, and when you do well, they tell everyone else.

Know your DNA

A startup can’t do everything well. Time and resources are finite, and we all have to prioritize some things over others. These choices become the DNA of a product.

Apple’s priority is design. It’s not that Microsoft, Dell, and Google think that design isn’t important – all things considered, everyone wants good design. But design is at the core of Apple’s DNA in a way that is true of very few companies. This affects every product Apple makes. Apple’s products aren’t always the fastest, the most advanced, or the most feature-rich. But without fail – almost – Apple’s products are brilliantly designed, and their competitors feel clumsy by comparison.

Google is still young, but I think its DNA is engineering brilliance. Oracle’s DNA is sales. Wal-Mart’s DNA is low prices. Microsoft’s DNA is in flux.

At Zencoder, we decided early on to emphasize customer happiness. We don’t just want to transcode videos. We want to transcode videos so well that customers notice, get excited, and tell their friends.

This has two components to it. First is performance: things like processing speed, reliability, and video/audio quality. If we’re slow, if we can’t handle a certain file, and if our output looks bad, our customers won’t be happy.

Second is customer support. We tapped one of our core engineers early on to focus on support, and this was one of the best decisions we made. He’s a real engineer who knows the Zencoder stack from top to bottom, and he usually answers customer email within minutes, not hours. No matter how well our product performs, if customers have problems and encounter a support black hole, they won’t be happy.

Focusing on customer happiness has precedent. For example, Zappos showed that customer happiness is powerful marketing driver. Customer Development teaches that startups should spend serious time talking to customers. And if Y Combinator’s unofficial motto is “Make Something People Want”, the First Derivative of that motto is “Make Users Happy.”

This focus has several benefits. First, happy customers are good marketing. When customers like something, they tell their friends. Second, it focuses product development in the right direction. In any startup, there are always a dozen important things that need to be done. If you choose between them by asking “What would make customers happiest?”, you’ll generally make a good decision. And third, making customers happy makes a team happy too. Employees are generally motivated by significance and recognition, even more than by simple things like money. And when users are happy, a team receives recognition and work feels significant.

What’s next

While 2011 has been a great year, and we’re excited to be the leader in cloud-based encoding, this is really just the beginning. Our industry is changing quickly, and if we get complacent and stop innovating, we’ll be overtaken before 2012 is out. So in 2012, look for four things from Zencoder. First, major feature improvements that let us take cloud transcoding to places where it hasn’t gone before. Second, fundamental changes to the structure of API-based media processing that have huge benefits. Third, complimentary products that our current customers are asking for. And fourth, a continued focus on performance, reliability, and quality, such that our 2012 product makes our 2011 product look weak by comparison.