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.
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. The sceencast reiterates some of what Casey talks about, so the basics of an HLS manifest, and how to go about manually editing one. We finish by writing a short script using Node.js to take in multiple manifests and concatenate them altogether before writing a new m3u8 we can watch.
We recently published a quick-start guide detailing how to publish an HLS live stream to S3 for testing purposes. If you’d like to take it a step further, you can use CloudFront as a CDN with no additional commitment. This guide assumes you’ve already gone through the Live to S3 quickstart guide and have that working.
First we need to set up our CloudFront distribution. Log into your AWS console and go to your CloudFront dashboard. Click “Create Distribution” in the top left corner.
You should now see two delivery method options. You might be tempted to select the “Streaming” option, but that’s specifically for the RTMP protocol. What we want in this case is “Download”, so make sure that’s selected and click “Continue”.
When you click the input box for “Origin Domain Name”, you will see a drop down menu of your available S3 buckets. Select the one you used in the Live to S3 quickstart guide, and the “Origin ID” field will automatically be populated. “Restrict Bucket Access” allows you to make it so people can only access your bucket through CloudFront. Because we’ll want to be able to view both for testing later, leave this disabled.
In a multi-device world, navigating the murky waters of video support can be tricky, especially when you’re trying to keep costs down and quality high.
Renditions and The Modern World
In its most basic form, online video consists of transcoding a single source file into a single output file that will play over the Web. Each of these video files is called a rendition, and an array of renditions defines how video will be delivered to end-users.
When YouTube launched in 2005, it delivered a single output rendition through a basic player. Fast forward to 2013 and the world of online video is defined by HTML5/Flash players, ad-insertion, recommendation engines, paywalls, and anywhere from a handful to a boatload of renditions at different bitrates and in various formats.
Steve Jobs once remarked: “(One should) be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.” These days it seems that everyone has caught on to Mr. Jobs’ ideal of an excellent experience. From the product design to the inner-workings of a web service API, we have high expectations for quality and user experience.
When it comes to video and audio in particular, the bar for quality is continually rising. The race among device manufacturers to produce ever-more precise displays and speakers is teaching consumers to seek out content that takes advantage of these capabilities. Apple’s new retina displays have high enough pixel density that the human eye is unable to notice pixelation at a typical viewing distance.
While some things that negatively impact user experience, such as actual device resolution or quality of available network connection, are out of a content owners control, the publisher can mitigate these issues by taking steps in the content preparation process that can significantly affect the quality of the content, creating online experiences that stand up to the best offline ones. From knowing how to best target a variety of devices to understanding effects of bitrate and codec, producing the best possible video for each viewer can be accomplished by following a few simple recommendations:
Encode video to the highest quality for each device.
Use an adequate bitrate
Use the best available encoding technology
Don’t overlook audio
Encode from high-quality content
To learn more about each of these recommendations, download our Encoding for Quality white paper, written by Zencoder video quality experts.