No results found

Zencoder's Posts

HTML5 Video and the End of Plugins

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.

Bulletproof Live Streaming

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.

What happened last night

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.

OpenSSL "Heartbleed" Security Update

OpenSSL "Heartbleed" Security Update

The engineering team at Zencoder conducted a review to assess the impact to our system of the CVE-2014-0106 vulnerability, nicknamed “Heartbleed”. This serious vulnerability would allow an attacker to reveal up to 64kB of memory to a connected client or server.

Dynamically generating video content using HLS

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.