So, we've made a couple of HD clips now - how about on the other end of the size spectrum? Let's talk about compressing for the Zune. As, usual, we'll use the Elephant's Dream source.
Zune.net has some reasonably detalied compression recommendations for targeting the Zune, and the settings are a little different than what we've seen before. But they're really targeted for consumers. Let's target the important constraints and work back for appropriate settings:
So, for Elephant's Dream, what does the above tell us? Our technical constraints to be able to sync (going beyond these would force a reencode) are:
- WMV with WMV9 Main Profile and WMA "Standard"
- Video at 320x180 24p
- Audio as 44.1 stereo
- Video with a peak rate of 1500 Kbps and audio peak of 192 Kbps
So, let's look at a couple of scenarios - Maximum quality, and maximized compression efficiency
- Maximimum Efficiency
- Video average 500 Kbps peak 1500 Kbps
- Audio average 96 Kbps peak 192 Kbps
- Maximized Quality
- Video average 1000 Kbps peak 1500 Kbps
- Audio 192 Kbps CBR
We could also do CBR video as well, I suppose, but that wouldn't help quality much, and would waste quite a few bits (and joules for playback).
In our previous examples, we used Windows Media Encoder session files and then WMCmd.vbs scripts. This time around, let's take the third portable example for settings files, and use .PRX files. A .PRX file defines the settings for an encode in a fashion supported by most compression tools that support the Format SDK. The "Windows Media Profile Editor" is installed along with Windows Media Encoder.
.PRX for the Maximum Efficiency Scenario:
And for Maximum Quality:
And for registry keys (set via WMV9 PowerToy, of course)? Pretty similar to last time:
We're Main Profile now, so DQuant doesn't apply. So unlike the 2 Mbps sample, I'm going to use Adaptive Deadzone to get better quality in the flat areas (before we discovered that DQuant without Perceptual was better). Since encoding at 320x180 is so fast, we can turn Chroma Search up to max. My rule of thumb is at least one thread per 64 pixels high, so we at most would want to use 2-threads. But it'll be a little more efficient to do 1.
Looking at the final results, both look and sound pretty good, with an edge to the higher bitrate, of course. More challenging content would benefit more from the higher rates, of course.
The biggest challenge in the encode is simply going from 1920x1080 down to 320x180 - that's a 36:1 reduction in pixels. The action holds up nicely, but the credits are pretty illegible due to scailng. if I was doing this content for distribution, I would have cropped the left/right more aggressively for the credits, eliminating the black bars/left right in order to keep the center of the image larger. Cropping 240 L/R and 135 T/B would do the trick, albeit eliminating some of the groovy animated graphics in the corners. But for that, I leave the proof as an exercise for the reader...
EDIT EDIT: Sorry about the bad link again - here it is fixed: Direct link to the .zip file