Elephant's Dream 720p @ 2 Mbps!

Rumor has it that ABC.com is going to be offering a 2 Mbps HD download service. I don't know about that rumor, but it sparked some conversations about what kind of quality can be delivered in 2 Mbps. Back again with Elephant's Dream, I took a whack at it. I hope y'all don't get sick of this source - there's not much that's widely available as source to the general public, and I like to use examples that readers and replicate and play around with on their own. I'll probably keep working with this clip until people tell me they're sick of it.

So, to mix things up a bit, we'll use Alex Zambelli's WMCmd.vbs script for encoding this time. The nice thing about the script is that I can script all the encoding parameters instead of having to juggle WMV9 PowerToy and a compression tool. The script I wound up using was:

cscript "C:\Program Files\Windows Media Components\Encoder\WMCmd.vbs" -input "G:\Elephant's Dream\ED Lag 1280x720.avi" -output "G:\Elephant's Dream\ED 720p 2M.wmv" -a_codec WMAPRO -a_mode 4 -a_peakbitrate 384000 -a_setting 128_44_6_16 -v_codec WVC1 -v_mode 4 -v_keydist 6 -v_bitrate 1863000 -v_peakbitrate 8000000 -v_peakbuffer 4000 -v_performance 80 -v_bframedist 2 -v_dquantoption 2 -v_dquantstrength 4 -v_loopfilter 1 -v_overlap 1 -v_mmatch 0 -v_mslevel 2 -v_msrange 0 -v_numthreads 1

So, what does the above mean?

-a_codec WMAPRO -a_mode 4 -a_peakbitrate 384000 -a_setting 128_44_6_16: This specifies the WMA Pro codec is used, in peak limited 2-pass VBR mode, 5.1 44.1 KHz 16-bit, with 128 Kbps average and a peak bitrate of 384 Kbps. I think WMA Pro is one of the overlooked parts of Windows Media - it might not has as many knobs to twirl, but WMA Pro is an extremely good codec, letting us deliver 5.1 audio at bitrates that would be low for stereo MP3. One of the unique features of WMA is that it supports 2-pass encoding modes for CBR and VBR, while most other codecs are 1-pass only. That lets us use a full 2-pass VBR for download, which is much more efficient than using CBR for audio, by shifting bits away from silent or simple passages to the hardest passages. 384K CBR typically sounds very good, so I used that as the peak.

-v_codec WVC1 -v_mode 4 -v_keydist 6 -v_bitrate 1863000 -v_peakbitrate 8000000 -v_peakbuffer 4000: WMV9 Advanced Profile in peak limited 2-pass VBR mode, with an average bitrate of 1863 Kbps and a peak of 8000 Kbps, over a buffer of 4 seconds, and a keyframe at least every 6 seconds. I picked the datarate so that + the 128 Kbps for audio + 9 Kbps of file overhead would be exactly 2000K. And yes, it's a little confusing to have peakbuffer duration be in milliseconds and keyframe rate to be in seconds. I chose a keydist of 6 seconds to save a few bits over the 4 seconcds I used for 1080p - lower data rate and frame size means you need fewer keyframes to provide the same random access latency. The peakbitrate and peakbuffer set the maximum bitrate - this means any 4 seconds of the file can be at most 8 Mbps average. I wanted to give the codec enough headroom to spend a lot of bits on the hardest scenes (especially running through the cables). I don't like to use -v_mode 3 (2-pass VBR without peaks) since it's hard to predict how playable the file would be.

-v_performance 80: The optimal high quality, slow encode mode. It's the same as picking encoder complexity one less than maximum in Windows Media Encoder
 
-v_bframedist 2: After talking about how 1 B-frame is the optimal mode, in playing around with this clip, I found that using 2 actually looked better in the hardest parts. This isn't surprising with animation, where large sections of adjoining frames are really identical, so you don't need a new P-frame as often. Since there's lots of occlusion (an object covering and then uncovering another object), B-frames can save a lot of bits, since the B-frame can predict itself based on either the previous or next I or P frame, hopefully one of which won't have the occlusion.
 
-v_dquantoption 2 -v_dquantstrength 4: Same as before - Differential Quantization on I and P frames (but not B), in Regular mode. DQuant can increase bit utilization, so more B-frames reduces that hit . But since many shots are static, having every third frame look really good lets the B-frames reference those high-quality images and look good themselves. Note I'm NOT using Adaptive Deadzone in this encode. In testing, at these low rates Adaptive Deadzone wound up hurting quality, especially in the big cable running scene. This makes sense - Adaptive Deadzone emphasizes smooth detail over high freqency parts of the image, and those cables are just a big bunch of sharp edges.
 
-v_loopfilter 1 -v_overlap 1: In-loop deblocking and overlap filters on. We always use Loop, since it helps quality in all scenarios. Since this clip still gets blocky in spots even with all the best practices, we use overlap as well. Both do increase CPU decode requirements a bit, but it's well worth it in this case (it's amazing how 720p playback has become a yawner).

-v_mmatch 0 -v_mslevel 2 -v_msrange 0 -v_numthreads 1: These are my general quality-over-render-time defaults, and are all safe to use with all content. That gives us macroblock adaptive SAD/Hadmard matching and motion search range. Chroma search is locked to full precision. And in order to eke out a last little bit of efficiency, I turned the codec to be single-threaded. Our VC-1 codec slices the image horizontally when using multiple threads. This is just fine for most content, since most video doesn't have that much vertical motion. But Elephant's Dream has a fair amount, so we can get another few percentages of bits out of it. For most real-world content, I would use the mmatch and msrange modes, but leave mslevel at 4 (macroblock adapative true) and threads alone. That's a good 3-4x faster on my quad AMD box, and looks identical with most content. I didn't try for this clip, since I was rendering overnight and didn't really care how long it was going to take.

Edit Take 2: Try here:

The link from this page instead

Tags:

Follow the Discussion

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums,
or Contact Us and let us know.