Entries tagged with wma pro - Channel 10

Silverlight 2 Beta 2 is out!

benwaggoner — Sat, 07 Jun 2008 14:39:00 GMT

After months of hard work, Silverlight 2 Beta 2 and its SDK are now available for download!

The best overall description of what's in it is in this post from Scott Guthrie.

Media Features in Silverlight 2 Beta 2

Of course, my focus is on the media features. New to Beta 2 is:

Hooks to enable adaptive streaming

Beta2 adds client support for "adaptive streaming" - which enables managed code to be able to pull in media files and streams from arbitrary URLs, and then reassemble them and pass them off to the video and audio decoders. This can enable a whole lot of different ways to address how to make media available, including supporting seamless streaming switching between content encoded at different bitrates. And since this is all running inside managed code, a CDN or content provider can tune the heuristics used to get the optimal content from the optimum server.

While the API is in place, we don't have any full end-to-end demos for how this works at the moment; you'll be seeing a variety of ways to use this technology down the road. Since our API is so flexible, I imagine customers and partners will find all kinds of fun things to do with it.

Content Protection

Beta2 includes client sideWindows Media DRM 10 and PlayReady DRM support. Both work cross browser and cross platform. Note that WMDRM10 will require a PlayReady license server (available in the coming weeks); existing content will work with Silverlight, but with the new license server.

Server Side Playlists

Beta2 adds improved support for server side playlists on Windows Media Services (previous releases only supported client-side playlists). That's still a feature in development (we are still a beta), so if you have server-side playlists that aren't working as you expect, it'd be great if you could put a link in comments, or email them directly to me so we can see what's going on. Note that web playlists from the IIS 7.0 Media Pack have always been fully supported.

Quality and Performance improvements

While there's no API change here, Beta 2 includes a variety of improvements to both performance and quality (particularly scaling quality) during media playback. Full-screen playback in particular is improved.

Windows Media Audio 10 Professional

And don't forget that Silverlight 2 adds support for the WMA 10 Pro codec. This isn't changed from Beta 1, but it's a big improvement compared to the stock WMA in Silverlight 1. WMA 10 Pro in the 32-96 Kbps range is what we call the "LBR" or Low Bit Rate mode, which is up to 2x as efficient as classic WMA. Audio is quite understandable at 32 Kbps, danceable at 48, an flawless at 64-96. Expression Encoder 2 supports the new modes, and Windows Media Player 11 can play them back as well.

For Silverlight 2-only projects, WMA 10 Pro is the codec of choice for any kind of bandwidth constrained content. And, of course, it's supported in Expression Encoder 2.

Also, note that, like WMA, WMA 10 Pro also supports 2-pass VBR encoding, which can help quality further when doing progressive download. 48 Kbps average 96 Kbps peak can sound pretty great.

I'll try to get up some A/B comparison demos in the next few days.

Elephant's Dream 720p @ 2 Mbps file now posted

benwaggoner — Mon, 18 Jun 2007 20:55:00 GMT

UPDATE: Didn't work. Try this link

Sorry this took so long, but here it is:

The link from this page instead

Click to play, right-click to download.

Comments appreciated.

Elephant's Dream 720p @ 2 Mbps!

benwaggoner — Mon, 11 Jun 2007 06:29:00 GMT

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