Zencoder's Posts

This post originally appeared on the Brightcove blog.This summer, sports fans around the world hit pause on their daily lives to tune into the 2014 World Cup Brazil™.

Recording, uploading and transcoding video straight from the browser Video on the web continues to grow by leaps and bounds. If you want a cheap-but-good analogy, it's about a tween: it already knows a lot, but still has substantial growth ahead. It's becoming too cool for plugins like Flash and Silverlight, but a lot of the shiny and exciting APIs on the edge of the spec still need to mature a little. Last year at WebExpo I gave a talk about the future of video on the web, as well as a brief foray into new and exciting features that were on the way. Some of the things I talked about, like Encrypted Media Extensions, were, for the most part, still a pipe dream with few to no working implementations. Now, just a year later, nearly all of the things discussed in that talk have meaningful implementations in most modern browsers. I recently gave a talk at Developer-Week about how the future of video on the web has arrived. During the talk we walked through real world examples of each "future" feature and, amazingly, talked about how each of the features could be (cautiously) used in the wild today. One of those features was WebRTC and using the APIs individually. We built a simple example of using getUserMedia to request a user's webcam and display it in a video element. To take this a step further, let's take that example and use it to save, then transcode content directly from the browser.

From a reliability perspective, one of the great things about VOD transcoding is the ability to simply try again. If anything goes wrong during the transcoding process, we can simply re-run the process from the beginning. The worst effect of a hiccup is a job takes a little longer, which is unfortunate, but the end result is a transcoded file is delivered to the customer and all is well. During a live event, however, we don't have the luxury of simply trying again. Since these events are transcoded in real time, we only have one chance to deliver a perfect transcode to end-users; a blip anywhere along the way can mean an interruption. No matter how reliable the system is, you never know when something like a power supply or network card is going to fail, so redundancy is crucial for high profile events. To account for this, we recently announced redundant transcoding for live streams. In a nutshell, if redundant_transcode is enabled, and at least one secondary_url is specified, Zencoder will transparently create a new job using any secondary URLs specified in the outputs of the original request. This job has all the same settings of the original, with the important distinction of being run in the nearest transcoding region of an entirely different cloud provider.

Last night, at 6:08pm EDT, the Zencoder service went offline due to a database failure. We began working on the problem immediately, but unfortunately our primary approach to solving the problem was unsuccessful, and the secondary approach took an extended period to implement. In total, the service was unavailable for six hours and 18 minutes. Here is a detailed description of what happened, why, and why it will never happen again.

Today, we are excited to unveil our support for advanced encoding formats. Zencoder will now support HEVC, MPEG-TS, JPEG 2000 and AVC-Intra, bringing the power of cloud encoding to broadcast and professional workflows. Additionally, Zencoder will also support MXF container for conformity with DPP guidelines for European broadcasters.

If you missed it, Casey Wilms did a three part series on the blog called Manifest Destiny. I liked it so much I started playing around with hacking together manifests programmatically and decided to do a screencast on the basics.