Video Compression Secrets: Smaller Files, Better Quality UPDATED!

In 2012, YouTube reported that users were uploading 48 hoursof video to the service every minute. That’s over 69,000hours of video a day, every day. Today, in 2015, YouTube is reporting that 300 hours of video are uploaded every minute.That’s equal to an almost unimaginable number of petabytes of video uploadedevery day (a petabyte is a million gigabytes). YouTube has well over 10 millionservers! The only way this works is because YouTube compresses all that video whenyou upload yours. But you aren’t dealing in petabytes of video so why does thismatter to you?

Mostof us already use video in our eLearning. In the “most of us” category, you arecompressing your video whether you know it or not. While some of us use our ownservers for video rather than YouTube’s, Vimeo’s, or some other video service,we all have file-size limitations and bandwidth issues.

How you compress your video and what form you compress it tomakes a difference. But what do we know about compressing video except to usethe Adobe Media Encoder or a standalone program like Sorenson Squeeze (or DivX,Microsoft, Apple, etc.) and several other video compressors? Does the file typeyou create matter? Yes. Does the file size matter? Yes. Let’s talk about filesize first.

What affects file size?

Anytimeline-based project (Figure 1) must be compressed in order to put it onYouTube, Vimeo, your servers, or wherever you need to store and access it.Furthermore, while you can stream an uncompressed video file (AVI), it’s not easy. The bandwidth requirements are suchthat your IT department will not have anything nice to say aboutit.

Figure 1: Timeline sample

Thevideo you upload to YouTube gets compressed the way YouTube wants to compressit, no matter how you compressed it originally. Although the server sizesseemingly approach infinity at YouTube, when it comes to uploading, the onlyworry about file size is how long it might take to upload a large file. It’sthe streaming part that matters. YouTube, and a few of theother video services, also automatically deliver different video codecs todifferent platforms like iOS or Windows. If you’re delivering to multipleplatforms, it’s worth a look.

Videofile size depends on many variables: high definition (HD) vs. standard definition (SD), framerate, color depth, and even the amount of movement in the video. There arethree measurements that count for a lot in determining the final file size.

First, the actual pixel dimensions of the finished product(Figure 2). Standard video (SD) is generally 720 X 480 pixels—that equals345,600 total pixels per frame. If you can do native HD video, the dimensionsare 1,920 X 1,080, which equals 2,073,600 pixels. That’s a lot more pixels perframe to stream.

Figure 2: Standard video frame size(blue center area) vs. native HD video frame size (green outer area)

The second measurement is the length of the video. Whenanything changes on the video timeline you’re creating, the file size changesafter you render your video. Change something else on your timeline and theresulting file size changes again. And so on.

The third measurement is frame rate. Most of the video we dois about 30 frames per second (fps). If you cut the number of frames in half,the video file size will be cut in half.

There are more variables, though. Here are some of them,including the three just mentioned:

• Pixel dimensions of the video
• Frame rate (15, 24, 25, 30, or whatever)
• How frequent are your key frames (the frame where the entire frame is recorded)
• Progressive or interlaced frames
• Constant or variable bitrate streaming
• Buffer size
• Audio sample rate
• Render quality

There’s even more, if you want to dig into it. No wondervideo quality can be so variable…and it’s very confusing to have to finish yourvideo in order to stream it.

An explanation of containers and codecs

Whenit comes to your rendered video, there are two kinds of software in play. Thefirst is the development environment or format. This is a container that theserver sends to the browser. The viewer’s browser needs to have the correctdecoder add-on installed in order for viewers to see the video. There areseveral of these containers, but these days we use H.264, which is the MP4format. But there’s still a lot of QuickTime (MOV), or Windows MediaVideo (WMV) as well. Both QuickTime and Windows also use the MP4codec (see below) as well. It can be confusing, and to be sure there are more,but I’m going to keep this explanation simple to keep the complexity down.

Thesecond part of a video is the codec insidethe format. A codec consists of two parts—the encoder, which is what you usewhile you’re encoding the video from your timeline or file. The second part isthe decoder; this part resides on the viewer’s computer as an add-in to decodethe video inside the container. The codec is what actually encodes andcompresses the video when you’re rendering it.

Avery common codec is H.264. It’s called a block codecbecause it looks for differences in blocks of video as it encodes and playsback. H.264 is used for HD video compression. Now, there is no reason H.264can’t compress standard-definition video—note that this is true for all codecs.Most of my clients work in SD video or NTSC to keep streaming rates lower. Youshould also note that if your finished video is going into an Articulate Studioor Storyline project, Articulate will not show HD video…yet. In fact, thedimensions for Articulate have been 640 X 480, an unusual size that fillsthe template screen.

A second widely used codec is Windows Media. This codec canbe used with H.264 and is the standard codec for Blu-Ray discs. Really. It canhave other codecs in it besides H.264, but for purposes of this article I’mgoing to use the WMV because it is easy to encode from the timeline in PremierePro.

Conceptually speaking, compressing video is actually prettysimple. If you look at a video from one frame to the next, some pixels changeand some are exactly the same as in the frame before. Why encode a pixel that’sexactly the same as a pixel in the frame before? That’s a waste of bytes. Sothe software essentially ignores the pixels that don’t change and changes theones that do change. (If only it were that simple. There are very complexalgorithms that go along with this, but the essence is the same.)

NOTE: I took out references to Flash that were in the firstversion of this article in the above section because Flash is mostly a deadissue today. The three major browsers (Explorer [now Edge]), Chrome, andFirefox) that dominate the market no longer support Flash, and neither doesSafari. The reasons are manifold and complex, but let’s just say that the Flashtechnology didn’t keep up with today’s mobile devices and computers. Of course,there’s the (in)famous spat between Apple and Adobe, but that’s a story untoitself. The spat was the beginning of the end for Flash though and it’sbecoming a tool of the past.

Lossy vs. non-lossy codecs

Lossy is what it seems—it means just that. Some of the datain a video is lost when it’s encoded. Can you see the loss? It depends on howgood or bad your encoder is. There’s actually a lot of superfluous data in aframe of video and if some of it gets lost, so much the better for file sizebecause you can’t see it. In analog TV, there was about a 10 percent loss ofthe picture area due to “scanning” and “over-scanning” of the images. Digitalvideo doesn’t have any of the “safe area” problems that the good old analogversion had. In analog video, you had to make your screen supers fit within thesafe area, somewhat more than 10 percent of the area of the picture. If you ranthe super or information to the edge of the screen, chances are that by thetime it got to someone’s home, it looked like it got cut off…and it did!

The problem with codecs and formats

The problem with all those codecs and formats is there arejust too many of them. When you look at the dropdown menu in the Adobe MediaEncoder (Figure 3), you’ll be presented with no less than 26 media formats.

Figure 3: Adobe Media Encoderdropdown menu

Andthat’s 26 formats without all the Sorenson presets included in the dropdown. Ifyou include them, it’s over 40 formats to choose from. Everything from uncompressedAVI to Windows Media WMV is available. Depending on the format you select,you’ll either have just a few codecs and sizes to choose from (try F4V, which is a Flash video format), or you will get asecond dropdown menu with a bewildering number of codecs to select to encodeyour project (Figure 4).

Figure 4: Codec formats

But wait … there’s more. Depending on the codec you select,there are other moving targets that will make your video file size larger orsmaller, have better or worse temporal quality, or make it able to be seen byany number of devices and browsers. This is where the real problem begins fordelivery to multiple device and browser versions. Most of us know that Flashwon’t play in iOS, but mp4 will when encoded with H.264. But that codec andformat combination won’t play in older versions of Firefox or InternetExplorer. So you can be forced into a lose-lose situation when you need to playyour project across multiple devices and platforms.

Video cards

In the last few years video cards have had a great impact onvideo editing and rendering. It used to be that your video card didn’t makemuch difference when it came to editing, encoding, and compressing video, butit sure does now. The newest programs from Sorenson and Adobe make use of theGPU (graphics processing unit, aka the chip on your video card) with many videocards.

A decent video card now has about two to four gigabytes ofRAM. Three years ago, video cards weren’t used for much other than displayingvideo and rendering video games. The fact is, video cards run significantlyfaster than an Intel or AMD processor when editing or rendering. And they havemore cores. More cores means faster rendering and that means your render timesare shorter. Those cores were designed for nothing but video, unlike thegeneral purpose processors that power all the other stuff on our computers.With the launch of Creative Suite 5 (CS5) in 2010, Adobe released the Mercuryplayback engine that rendered video by using the nVidia video card hardware.What this meant to users was that in the Premiere Pro timeline there was almostreal time rendering (well, not exactly real time, but it would require anotherarticle to explain that). By using the GPU to do the heavy lifting on timelinerendering, Adobe opened the door to faster video editing and rendering. Overthe years, there have been some issues with the Mercury engine and the DynamicLink engine, which allows compositions in After Effects to be directlyconnected in Premiere Pro. But all seems to be working fine these days andthere are improvements in the 2015 version of the Creative Cloud.

Finally: the rendering process

There are two kinds of video rendering, and the kind ofrendering you’re planning on or need to do will greatly influence the tool youuse. The first (and simplest) rendering is from the timeline in AdobeCaptivate, Premiere Pro, Vegas, Final Cut Pro, or whatever timeline-basedprogram you’re using. This is direct rendering off the timeline, and you’repretty much stuck using the encoding software that came with your video editingpackage. This works well for those who are placing their video in PowerPoint,Articulate, or whatever.

When you need to render to multiple platforms, dimensions,and codecs, or you’re serving your own video directly, you’ll probably renderfrom your timeline to an AVI or uncompressed MOV file first, and then render tothe different formats using a tool like Sorenson Squeeze. There are severalproducts in the marketplace, and I don’t want to write reviews of them here,but with a separate rendering software package, you can set up a render “queue”with all the file types and dimensions you’ll need for your finished product.You can also do that with the Adobe Media Encoder, but a product like Squeezehas more options if you need them.

Methodology

Table 1 shows you the results (size, quality, andtime-to-render) that I got from a variety of format and codec combinations. Letme explain what I did before you look at the table.

After a lot of consideration, I simplified the process asmuch as I could. It was Occam’s razor. Simpler is better. There are just toomany variables. And no matter what we do, your results will be somewhatdifferent. Simplest is best … at least in this case.

The method: I used a 10-second video clip from a time-lapseproject I did a while back. The clip has some, but not complete, movement init. However, there are a lot of light changes and that (to a rendered videoanyway) is movement. We also rendered as close to 30 fps as we could (somecodecs only allowed 29.97 fps) and progressive scan. If your project doesn’thave much change or movement, 15 fps might be good enough, but apples-to-apples,we needed to pick something.

To do the rendering, I used a variety of different formatsand keyframe rates (not frames per second) so that there is some variation thatyou might be able to key in on. There are so many formats you can use that Ilimited it to five, with a two-keyframe interval where that was available as anoption. We also limited the number of codecs. It gets silly after a while, andsome of the formats can only render one codec. The temporal quality is purely ajudgment call on my part. If the video looked substantially different when Ilooked at it, I marked it down or up. When there was blocky pixilation, itreally got marked down. The size speaks for itself.

Conclusions

There are 18 versions of the 10-second video. There couldhave easily been over 100 versions. It’s difficult to make concrete conclusionsand recommendations because everyone’s video project, bandwidth allowances andneeds, and temporal qualities are different.

As a general conclusion, we would say if you can useYouTube, by all means do so. Yes, you get the frame around the picture, butYouTube can adapt to the constantly changing environment in video as well asdelivering your content to different platforms. If you’re only encoding one ortwo videos at a time, Sorenson Squeeze is not worth the money. But if you havea training department and are encoding tens or dozens of videos at one time,then it becomes a bargain. I didn’t get to test the Sorenson Server, but I’msure it’s good. The idea of encoding on the fly when there’s a lot of differentformats and devices to deliver to makes a product like Squeeze an attractivealternative to rendering and then showing.

The best codec to keep file sizes small is Windows Media (WMV)with H.264 encoding. Microsoft has done an excellent job of combining smallfile size and very good temporal quality. The format isn’t necessarily good foriOS devices, but if you can manage to get your projects on YouTube (where youcan make a video private or even have a password), you will be able to delivereverywhere. And that’s a plus, in my opinion.

If you need something to serve on almost any device today,you need a video server that can figure out what device is requesting thevideo, what the size of the screen is, how fast the user’s connection is, etc.,etc., etc. In some circumstances you might face, there are innumerable codecsand sizes for a given format. In H.264 format there are 24 presets for Androidphones and tablets and 21 presets for iDevices! Sometimes you’ve got to chooseone and just let it go.