Getting Started

First you’ll need to install the NPM module.

npm install zencoder

This will install the package in the directory node_modules. You can then require the package in your application.

var Zencoder = require('zencoder');

Now instantiate a new client.

var client = new Zencoder('abcdefg1234qwert9302sdfjki30kfi9');

This will create a new client using the API key abcdefg1234qwert9302sdfjki30kfi9. If no API key is set, then the library will check for a ZENCODER_API_KEY environment variable. By default, the library uses v2 of the Zencoder API, but you can pass in a different base url when creating a client if need be.

var client = new Zencoder('abcdefg1234qwert9302sdfjki30kfi9', 'https://app.zencoder.com/api/v1')

Now you’re ready to start interacting with the API! The library follows RESTful conventions as closely as possible, so if you’re familiar with our API already you can hit the ground running.

Let’s create a basic application that will submit a job for us, then return the job ID if successful. Start by creating a new app called zentest.js and set up a new client as we detailed above, then use that client to submit a job.

var Zencoder = require('zencoder');

var client = new Zencoder('abcdefg1234qwert9302sdfjki30kfi9');

client.Job.create({
  input: 'http://s3.amazonaws.com/zencodertesting/test.mov',
  outputs: [{
    url: 's3://zen-tests/awesome-movie.mp4'
  }]
}, function(err, data){
  if (err) { console.log("OH NO! There was an error"); return err; }
  console.log('Job created!\nJob ID: ' + data.id);
});

Save the file and run it using $ node zentest.js. You should see output like this:

$ node zentest.js
Job created!
Job ID: 1234567

Now instead of just logging the creation, let’s change our app to poll for progress after a successful request so we can get progress updates. We’ll use a poll function and timeouts to query the API for progress every 5 seconds until the job is finished.

var Zencoder = require('./')
  , readline = require('readline');

var client = new Zencoder('abcdefg1234qwert9302sdfjki30kfi9');

// We'll use readline to update progress so we don't get have to see a bajillion console.logs
var rl = readline.createInterface({
  input: process.stdin,
  output: process.stdout
});

client.Job.create({
  input: 'http://s3.amazonaws.com/zencodertesting/test.mov',
  outputs: [{
    url: 's3://zen-tests/awesome-movie.mp4'
  }]
}, function(err, data){
  if (err) { console.log("OH NO! There was an error"); return err; }
  console.log('Job created!\nJob ID: ' + data.id);
  poll(data.id); // start polling... polling will continue to call itself until finished.
});

function poll(id) {
  setTimeout(function(){
    client.Job.progress(id, function(err, data) {
      if (err) { console.log("OH NO! There was an error"); return err; } // blargh!
      if (data.state == 'waiting') {
        if (!this.status || this.status != 'waiting') {
          rl.write('Waiting'); // display waiting
          this.status = 'waiting'; // set status to waiting so we can start adding dots.
        } else {
          rl.write('.'); // keep adding '.' until we start processing
        }
        poll(id);
      } else if (data.state == 'processing') {
        var progress = Math.round(data.progress * 100) / 100; // round to nearest decimal places.
        rl.write(null, {ctrl: true, name: 'u'}); // clear the current status so we can update progress
        rl.write('Processing: ' + progress + '%');
        this.status = 'processing'; // not important, but makes sure we don't display waiting again
        poll(id);
      } else if (data.state == 'finished') {
        rl.write(null, {ctrl: true, name: 'u'}); // clear the current status
        console.log('Job finished!'); // finished!
        process.exit(0); // exit
      }
    }, 5000);
  })
}

Now run $ node zentest.js again. You should see a notice that the job was created, followed by an updated percentage until the job is complete. In a web application, you would most likely query for progress in the client, and handle job completion with a notification on the server. We’ll go into more detail on using notifications in a series on building applications around Zencoder with Node.

The GitHub repository includes a comprehensive test suite, so if you’d like to see more usage examples that’s a great place to start. If you have any other questions or comments, feel free to reach out! @matt_mcclure

We wrote some preliminary thoughts about GCE a year ago when it launched at I/O.  In the interim we’ve found that the GCE team has continued to execute on some features that really distinguish it from competitors– especially disk I/O, boot times and machine consistency, and global network performance.  We’re excited to talk about how these attributes further bolster a high-performance service like Zencoder and deliver tangible benefits to end users.

If you’re going to be at the conference, hit us up on Twitter @zencoderinc, or just stop by the Sandbox to say hello!

You can read the entire blog post here.

4.0 Major Feature Summary:

Improved performance through an 18% size reduction using Google Closure Compiler in advanced mode

• Greater stability through an automated cross-browser/device test suite using TravisCI, Bunyip, and Browserstack.
• New plugin interface and plugin listing for extending Video.js
• New default skin design that uses font icons for greater customization
• Responsive design and retina display support
• Improved accessibility through better ARIA support
• Moved to Apache 2.0 license
• 100% JavaScript development tool set including Grunt

Improved Performance

With version 4.0, performance was our top priority, and a major factor of performance is the time it takes to load the library. What would seem to be minor size reductions can have a big impact, especially when a library will be loaded millions of times a month all over the world. We chose to use Google’s Closure Compiler because its “advanced mode” currently provides the most aggressive options for code minification, and so far we’ve seen an 18% reduction in code size, with the potential for more.

Closure Compiler also claims to rewrite code for better runtime performance, though we haven’t had a chance to benchmark this yet.

Some preliminary load-time benchmarking* shows:

• Player load times in under 50 milliseconds
• Playback start times in under 150 milliseconds
• Actual video playback seen in under 0.5 seconds (using a CDN hosted MP4)

*Initial tests used Chrome with an empty cache on a modern MacBook Pro with a Wi-Fi connection. More formal testing to follow.

Greater Stability

Automated cross-browser, cross-device testing is the Holy Grail of testing for a JavaScript library. While building version 4.0, we’ve been able to reach that goal through the use of a number of tools, including:

• TravisCI – Automatically runs unit tests through PhantomJS on every pull request made to the Video.js source code
• Bunyip + Browserstack – Allows us to run tests in cloud-hosted instances of any browser from IE6 to the latest Chrome, and also a wide range of iOS and Android devices.

This ability to easily run tests across environments before any new release will give us more protection against regressions, and can allow for a faster feature release cycle.

New Plugin Interface

The new plugins API allows developers to more easily add custom features to Video.js. The API works similarly to the jQuery plugin interface, giving developers access to add to or overwrite any piece of Video.js. Once a plugin has been created, it can be shared on the Video.js plugin list page on the wiki.

New Default Skin

With help from the Brightcove UX team, we’ve created a new default skin that’s simpler, more polished, and more customizable. One of the most interesting features is that we’ve moved from using images for icons to font icons. The use of font icons allows you to change the color and size of the icons simply by changing a CSS value. You can see an example of this on the Video.js homepage.

Improved Accessibility

Greg Kraus, a Video.js community member from NCSU.edu, did some great work testing and improving Video.js accessibility through better use of ARIA roles. The changes make it so keyboard-only users, screen reader users, and voice-interface users will be able to interact with the video player.

Moved to Apache 2.0 License

Earlier versions of Video.js were released under the LGPLv3 license. LGPL often gets confused with its stricter sibling, GPL, which requires that all code the software touches must also be open source. Video.js is meant to be open and free to use in all contexts, and we want that to be clear, so version 4.0 is now released under Apache 2.0, the same license Twitter Bootstrap is released under.

100% JavaScript Tool Set

Previously Video.js used Ruby for development tools, including Rake for deployment tasks, and zenflow–an internal Zencoder tool that builds on gitflow for development process workflow. With 4.0 we’ve moved to Grunt for tasks and we’re building out a tool similar to zenflow in Node.js.

Videojs.com Now Open Source

As part of this release we’ve also made the Videojs.com website open source. So if you see something that should be added or fixed, fork it.

One of the big winners of the day, taking home prizes from more than 3 categories, was TV Time, an app that allows children to earn the right to watch certain TV shows and movies by answering educational questions. The top prize of Best in Show went to 17 year old Jen Lamere for her application built around the Klout API that allows users to hide tweets that can be potential spoilers, then play them back after they’ve watched the show or event.

The winner of the Zencoder prize, along with “Best Use of Multiple APIs”, was Who Am I, which allows people to record an impersonation of a TV or movie character, then get their friends to guess who. Other cool hacks included a betting application that allows friends to place bets on things happening in television shows and engage with others watching the same thing and a sports knowledge application that allows viewers to get real time information on events that they don’t necessarily engage in regularly.

If you’re going to be at RailsConf, we’re hosting a party with SendGrid at Ground Kontrol from 7:30 – 9:30 on Monday night (4/29). If we’re not enough of a reason to come, all of the games will be free-play and we’ll have a tab, so we’d love to see you there. Please RSVP on Eventbrite, but keep in mind that even if you RSVP, entry is first-come, first-serve if we reach capacity.

A Quick Recap

For years, there were two basic models of Internet streaming: server-based proprietary technology such as RTMP or progressive download.  Server-based streaming allows the delivery of multi-bitrate streams that can be switched on demand, but it requires licensing expensive software. Progressive download can be done over Apache, but switching bitrates requires playback to stop.

The advent of HTTP-based streaming protocols such as HLS and Smooth Streaming meant that streaming delivery was possible over standard HTTP connections using commodity server technology such as Apache; seamless bitrate switching became commonplace and delivery over CDNs was simple as it was fundamentally the same as delivering any file over HTTP. HTTP streaming has resulted in nothing short of a revolution in the delivery of streaming media, vastly reducing the cost and complexity of high-quality streaming.

When designing a video platform there are countless things to consider; however, one of the most important and oft-overlooked decisions is how to treat HTTP-based manifest files.

A Static Manifest File

In the physical world, when you purchase a video, you look at the packaging, grab the box, head to the checkout stand, pay the cashier, go home and insert it into your player.

Most video platforms are structured pretty similarly; fundamentally, a group of metadata (the box) is associated with a playable media item (the video). Most video platforms start with the concept of a single URL that connects the metadata to a single mp4 video. As a video platform becomes more complex, there may be multiple URLs connected to the metadata representing multiple bitrates, resolutions, or perhaps other media associated with the main item such as previews or special features.

Things become more complicated when trying to extend the physical model to an online streaming world that includes HTTP-based streaming protocols such as HLS. HLS is based on many fragments of a video file linked together by a text file called a manifest. When implementing HLS, the most straightforward method is to simply add a URL that links to the manifest, or m3u8 file. This has the benefit of being extremely easy, basically fitting into the existing model.

The drawbacks are that HLS is not really like a static media item. For example, an MP4 is very much like a video track on a DVD; it’s a single video at a single resolution and bitrate.  The HLS manifest consists, most likely, of multiple bitrates, resolutions, and thousands of fragmented pieces of video. HLS has the capacity to do so much more than an MP4, so why treat it the same?

The HLS Playlist

An HLS playlist includes some metadata that describes basic elements of the stream, and an ordered set of links to fragments of the video.  By downloading each fragment, or segment of the video and playing them back in sequence, the user is able to watch what appears to be a single continuous video.

EXTM3U
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-TARGETDURATION:10
#EXTINF:10,
file-0001.ts
#EXTINF:10,
file-0002.ts
>#EXTINF:10,
file-0003.ts
#EXTINF:10,
file-0003.ts
#EXT-X-ENDLIST

Above is a basic m3u8 playlist. It links to four video segments. To generate this data programmatically, all that is needed is the filename of the first item, the target duration of the segments (in this case, 10), and the total number of segments.

The HLS Manifest

An HLS manifest is an unordered series of links to playlists. There are two reasons for having multiple playlists: to provide various bitrates and to provide for backup playlists.  Here is a typical playlist where each of the .m3u8’s is a relative link to another HLS playlist:

#EXTM3U
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2040000
file-2040k.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1540000
file-1540k.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1040000
file-1040k.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=640000
file-640k.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=440000
file-440k.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=240000
file-240k.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=64000
file-64k.m3u8

The playlists are of varying bitrates and resolutions in order to provide smooth playback regardless of the network conditions. All that is needed to generate a manifest are the bitrates of each playlist and their relative paths.

Filling in the Blanks

There are many other important pieces of information that an online video platform should be capturing for each encoded video asset: video codec, audio codec, container, and total bitrate are just a few. The data stored for a single video item should be meaningful to the viewer (description, rating, cast), meaningful to the platform (duration, views, engagement), and meaningful for applications (format, resolution, bitrate). With this data, you enable a viewer to decide what to watch, the system to decide how to program, and the application to decide how to playback.

By capturing the data necessary to programmatically generate a playlist, a manifest and the codec information for each of the playlists, it becomes possible to have a system where manifests and playlists are generated per request.

Example – The First Playlist

The HLS specification determines that whichever playlist comes first in the manifest will be the first chosen to playback. In the previous section’s example, the first item in the list was also the highest quality track. That is fine for users with a fast, stable Internet connection, but for people with slower connections it will take some time for playback to start.

It would be better to determine whether the device appeared to have a good Internet connection then customize the playlist accordingly. Luckily, with dynamic manifest generation, that is exactly what the system is set up to accomplish.

For the purposes of this exercise, assume a request for a manifest is made with an ordered array of bitrates. For example, the request [2040,1540,1040,640,440,240,64] would return a playlist identical to the one in the previous section. On iOS, it’s possible to determine if the user is on WiFi or a cellular connection. Since data has been captured about each playlist including bitrate, resolution, and other such parameters, an app can intelligently decide how to order the manifest.

For example, it may be determined that it’s best to start between 800-1200kbps if the user is on WiFi and between 200-600kbps if the user is on a cellular connection.  If the user were on WiFi, the app would request an array that looks something like:  [1040,2040,1540,640,440,240,64]. If the app detected only a cellular connection, it would request [440,2040,1540,1040,640,240,64].

Example – The Legacy Device

On Android, video support is a bit of a black box. For years, the official Android documentation only supported the use of 640×480 baseline h264 mp4 video, even though certain models were able to handle 1080p. In the case of HLS, support is even more fragmented and difficult to understand.

Luckily, Android is dominated by a handful of marquee devices. With dynamic manifests, the app can target not only which is the best playlist to start with, but can exclude playlists that are determined to be incompatible.

Since our media items are also capturing data such as resolution and codec information, support can be targeted at specific devices. An app could decide to send all of the renditions:  [2040,1540,1040,640,440,240,64]. Or, an older device that only supports up to 720p could remove the highest rendition:  [1540,1040,640,440,240,64]. Furthermore, beyond the world of mobile devices, if the app is a connected TV, it could remove the lowest quality renditions: [2040,1540,1040,640].

Dynamic or Static?

Your favorite compressionist’s post on concatenation was focused on a single benefit of dynamic manifest generation; the ability to generate different combinations of clips to create an almost limitless number of videos. This post has been focused on the other benefits: targeted delivery to devices, optimized start times, and wider support for devices.

Choosing a static manifest model is perfectly fine. Some flexibility is lost, but there is nothing wrong with simplicity. Many use cases, especially in the user-generated content world, do not require the amount of complexity dynamic generation involves; however, dynamic manifest generation opens a lot of doors for those willing to take the plunge.

How manifests are treated will have a significant impact on the long-term flexibility of a video platform, and it is something that should be discussed with your resident compressionist.

Streaming high-quality, live video over the web is a difficult problem that generally requires expensive hardware and considerable skill to set up and operate. Recent years have shown an increase in the number of streaming formats available combined with an explosion in internet connected consumer devices, making the job of content providers even harder.

Over the last three years, Zencoder has offered the fastest, most scalable, and highest quality file transcoding in the cloud. We’re bringing the same approach to live video, with a focus on performance, features, and API usability. Our initial release is simple, straightforward, and powerful.

The web service will accept RTMP input streams, and transcode to RTMP and HLS in multiple bitrates for adaptive bitrate playback. Thanks in no small part to all of the great participants in the beta, we’re proud to present a product that we think will change the world of live event streaming online.

Cloud-based VOD transcoding has enabled a lot of really cool products – certainly more than we could dream up.  The costs and complexity of live video can discourage experimentation, so we’re now putting powerful live transcoding at every developer’s fingertips.  We can’t wait to see the results.

Cloud transcoding for live video offers some major efficiencies:

Eliminate outbound bandwidth bottlenecks. Outbound bandwidth can be a major bottleneck for distributing live video.  Encoding on-premise limits the number and bitrates of streams to the outbound throughput, leading to tough decisions between device support and providing the best user experience with technologies like adaptive bitrate playback.  With Live Cloud Transcoding, content providers publish just one RTMP stream, and transcode to other formats and bitrates.

Use inexpensive (or free) encoders at the event. Simply use an off-the-shelf laptop and a software encoder like Flash Media Live Encoder, XSplit, OBS or Wirecast, and you’re ready to rock.  Of course, you can still use a hardware encoder such as Elemental and achieve bandwidth efficiences.

Transparently scales to handle any number of input streams. Broadcasting multiple camera angles or several simultaneous events is simple and minimizes upfront investments in expensive hardware or software.

Scale to handle numerous output streams. Output streams can be gated not only by bandwidth, but also by processing power.  The cloud provides instant access to powerful computing resources and in the initial launch, we’ll allow up to 20 output streams per live input stream.

Simplify Live -> File workflow. Event streams are easily archived and immediately made available as a file.

Usage-based pricing. Users pay only for what they use, and never over provision..

Ready to give it a try?

• Everyone that signs up and activates a PAYG account will get access to 120 minutes of Live transcoding.
• Check out our Live transcoding guide and recommendations.

Enter Filepicker.io

Filepicker.io makes file upload easy. Like, really easy. You’re not just limited to just local files either; they support a wide range of sources, from Dropbox and Google to even recording a video directly from your webcam. The best part is, you can do all of this without ever leaving the front-end.

Before we do anything else, you’ll need to sign up for a Filepicker.io account. Once you’ve done so, create a new App in your dashboard if one doesn’t exist. Take note of the API key you see, we’ll be using that later. Filepicker.io is nice enough to provide an S3 bucket for getting started, but take a second to set up a destination S3 bucket for your uploads.

Let’s start on the same page with a basic HTML5 template. We’re going to use jQuery to make things simple, so we’ll include that with our boilerplate along with the Filepicker.io library.

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>Zencoder Dropzone</title>

    <!-- jQuery Include -->
    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>

    <!-- Filepicker.io Include -->
    <script type="text/javascript" src="//api.filepicker.io/v1/filepicker.js"></script>
</head>

<body>
    <div id="content">
        <h1>Upload all the things!</h1>
    </div>
</body>
</html>

Now we can use the Filepicker.io JavaScript API to allow our users to select a file and save it to our S3 bucket. We’ll also need to associate this with a link in the body so the user has something to click. Add this below the Filepicker.io JavaScript include.

First let’s add the upload link. Since we already have a big, prominent h1 tag, let’s just add the link to that.

<h1><a href="#" id="upload-link">Upload all the things!</a></h1>

Now we want to use that link to trigger filepicker.pickAndStore when clicked. This is where we’ll use the API key you made note of earlier. Place this snippet below the Filepicker.io JavaScript include in the head of the page.

<script type="text/javascript">
    $(function() {
      filepicker.setKey('The_Key_From_Your_Dashboard');

      $('a').click(function(e) {
        e.preventDefault(); // This keeps the normal link behavior from happening

        filepicker.pickAndStore({},{location: 's3'},function(fpfiles){
            console.log(JSON.stringify(fpfiles));
        });
      });
    });
</script>

You’ll need to use some sort of web server to serve up the HTML or else you won’t be able to load the external JavaScript files. You can use something like http-server, but there’s a basic Node application that will serve static files in the GitHub repository. Your page should look pretty unimpressive at this point. You should just see a big link and a lot of white space.

If you click the link, though…

Choose any file (might want to pick something relatively small) and upload it. Right now, a successful upload just logs the fpfiles object to the console, so after you upload a file take a look at the console. If everything went according to plan, you should have an object with some information about your newly uploaded file.

Congratulations! You just uploaded a file from your computer with just 27 total lines of code, including simple HTML markup. Just uploading files and leaving them there isn’t useful though, so let’s make it so users can upload videos and encode them.

Adding some Zencoder to the mix

First, let’s alter our uploader to only accept video files. Filepicker allows us to restrict by mimetype, so if you’re like me you may be tempted to try {mimetype: 'video/*'}. This will work just fine in Chrome, but your Safari users will see a much smaller subset of files that they can upload. For video, it’s much more reliable to restrict by extension, so let’s take that route.

$('a').click(function(e) {
  e.preventDefault(); // This keeps the normal link behavior from happening
  var acceptedExtensions = ['3g2','3gp','3gp2','3gpp','3gpp2','aac','ac3','eac3','ec3','f4a','f4b','f4v','flv','highwinds','m4a','m4b','m4r','m4v','mkv','mov','mp3','mp4','oga','ogg','ogv','ogx','ts','webm','wma','wmv'];
  filepicker.pickAndStore({extensions: acceptedExtensions},{location: 's3'},function(fpfiles){
      console.log(JSON.stringify(fpfiles));
  });
});

You can restrict this set of accepted files or add more, but I took the easy way out and just used the list of valid output formats from the Zencoder format documentation. This includes some audio files, but since Zencoder supports audio-only encoding we can leave them in there.

Now if you click the link and browse your local files, you should notice that you can only select files with an extension on the list. If you try to drag and drop an unnacceptable file, you’ll get an error.

Great! Now that we know we’ll only be uploading files Zencoder can support, let’s make it so a successful upload sends that file to Zencoder for encoding. Before we can do that, we’ll need to set our Zencoder API key. You can just include this right below your Filepicker key.

filepicker.setKey('The_Key_From_Your_Dashboard');
var zenKey = 'Zencoder_API_Key';

Now we’ll use jQuery’s $.ajax to send our API request to Zencoder upon successful upload.

filepicker.pickAndStore({extensions: acceptedExtensions},{location: 's3'},function(fpfiles){
  // This is the simplest Zencoder API call you can make. This will output an h.264 mp4 with AAC audio and
  // save it to Zencoder's temporary storage on S3.
  var request = {
    "input": fpfiles[0].url
  }
  // Let's use $.ajax instead of $.post so we can specify custom headers.
  $.ajax({
      url: 'https://app.zencoder.com/api/v2/jobs',
      type: 'POST',
      data: JSON.stringify(request),
      headers: { "Zencoder-Api-Key": zenKey },
      dataType: 'json',
      success: function(data) {
        $('body').append('Job created! <a href="https://app.zencoder.com/jobs/'+ data.id +'">View Job</a>')
      },
      error: function(data) {
        console.log(data);
      }
  });
});

Now refresh your page and upload a video. If everything has gone according to plan you should see a success message with a link to your newly created job.

There you go! 47 lines of code later you have a web page that will allow you to upload a video and send it off for encoding.

Notes and warnings

It is a BAD IDEA to put your Zencoder API key in plain text inside of JavaScript. Just to repeat that one more time, do not use this in code that other people could possibly access.

Nothing would stop people from taking your API key and encoding all the video they wanted.

A much better idea would be to use Filepicker.io as described, but actually make the Zencoder API call in your back end where your API key is safe from prying eyes.

Just to take things a step further…

I think drag and drop is really cool, so I wanted to make a whole page that uses Filepicker.io’s makeDropPane. Users have to put their API key in before doing anything and it’s not stored in the code, so the demo is safe to put online.

Aaand even further…

Just to officially take the demo too far, this version validates the API key, includes a history of your recent Zencoder jobs and allows you to modify the request template. All of these settings are saved in your browser’s localStorage so you don’t lose everything on a refresh. I tried to over-comment, so feel free to take a look through the source!

I would love to hear what you think! You can find me on Twitter as @matt_mcclure if you have any questions or comments.

The following is a quick Q&A with Sibme co-founder Dave Wakefield on how they use video, and how they use Zencoder.

Tell us about more about the work that you do at Sibme.

Sibme is a private video collaboration and professional development platform for teachers, instructors, and instructional support staff. Video is a powerful way to train and provide instructional feedback to educators.  The problem has always been that it has never been that easy or efficient to implement in schools and institutions. While athletes like Peyton Manning spend a lot of time reviewing game tape to improve their performance, teachers rarely have enough time in the day to think about professional development.  There are no reason teachers or instructors should not be doing the same.  Sibme allows for more meaningful and frequent observation in schools in a private and secure environment. Many teachers are willing to use video to collaborate with their peers and improve their craft if they trust and respect the reviewer’s opinion.

How do the needs of your customers and their consumers affect how you use video?

Our video tools have also been designed specifically for educators.   For example, if your instructional coach notices that you missed an opportunity to compliment a student’s answer at time 5:34 in the video, she can flag that exact moment and add a comment.  Or you can upload a document with the lesson plan you were following, so your coach can follow along as you go.  Our intention as educators was to design a product that had all the necessary features but remained simple, flexible and customizable to suit the needs of a small department, large school, or even a large institution.

What challenges did you face with video, and how did Zencoder help?  Why did you choose Zencoder over other methods of encoding?

When we first imagined our service we thought about using public video services such as YouTube and Vimeo. However, most schools and districts do not want sensitive and private information like classroom video on public sites like YouTube and Vimeo, even when using their privacy settings.

Once we decided that we weren’t going to use one of the video services available on the web, we knew that we needed to encode videos ourselves. We explored the idea of creating an encoding server on a LAMP stack using FFMPEG, the leading open source video encoding solution. What we found was that the knowledge and resources required to build the encoding server and keep it up and running reliably was well beyond what we could achieve with our limited resources.  It just wasn’t worth the time or effort, since our focus is on improving teaching and learning.

Zencoder is an API-based service.  How did you integrate with us?

Our application uses a Java based uploader that uploads files directly to Zencoder. Once encoded, the video is uploaded to S3 and appears in the account that it was uploaded from.  We have also developed an iPhone app that allows for more efficient uploading to supplement the java uploader.

What’s your favorite thing about Zencoder?

Our favorite thing about Zencoder is how reliable it is.  We’ve tried out some competitors but their encoding times and failure rates were not as good as Zencoders.  Educators don’t have enough time in the day to deal with encoding failures. We love its reliability, compression speed and the fact that we can seamlessly integrate the encoding process with our application.

What excites you most about the future of online video?

Online video can be used in a variety of ways, not solely for entertainment or advertisements.  We’re very excited to see how video is transforming the web in a variety of industries, and we think it is going to transform the way we currently do things, especially when it comes to professional development in education.  Zencoder will play a big role in making this process even more efficient.

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.

It may sound like a confusing mess, and it can be, but there are strategies that can simplify your approach to delivering video, shrink costs, and improve the viewer’s experience. It all starts with renditions.

Climb the Ladder

Imagine the world of devices as a wall. At the bottom of the wall are the least capable, most painful-to-use feature-phones with 3G connections and a tiny screen. At the top of the wall, we have a brand new, HDTV with a fast Internet connection. Between the bottom and the top of the wall is a range of devices, each having different processors, GPUs, network connections and screen sizes.

The height of the wall is determined by average content duration; the longer the duration, the higher the wall. Renditions are like ladders that help us start anywhere along the wall and climb up or down smoothly. If the wall is high, there needs to be more rungs on the ladder to ensure users can smoothly climb up and down. If the wall is short, we can get away with only a couple rungs and still provide a good experience

Step 1:  The First Ladder

The first step is to decide on a base format. The base format should be playable on a wide range of devices. It might not always be the best choice on every device, but it should always be playable. The goal of online video is to get in front of everybody.

Zencoder supports a wide swath of the most important output formats for Web, mobile and connected TVs. Valid use cases exist for each of these formats; but, for the vast majority, MP4 is the best option due to its ubiquity across the widest range of devices.  The first ladder we build will be based on the MP4 format.

Step 2:  Bitrates – Creating the Ladder’s Rungs

Now that we have decided which ladder to create first, we can begin constructing the rungs.