Log in

View Full Version : Final Release of WMV-9 VCM codec


mingcl
8th July 2003, 01:44
Dear forum members,

Today we released the final version of the Windows Media Video 9 VCM codec, designed to meet 2 important needs:

1. Legacy encoding and editing applications can now support the WMV9 codec in file containers such as AVI.

2. WMV 9 content can now reach desktops running Windows Media Player 6.4

For customers using the 6.4 player, the WMV9 VCM decoder will be automatically downloaded the first time the player attempts to play content that has been encoded in WMV-9. For installation on a PC where internet access or administrator privileges are not available, we have released a standalone installer package that can be scripted to install using any software distribution software.

The standalone package containing the codec, EULA and documentation outlining how to incorporate the VCM codec into applications is available for download at http://www.microsoft.com/windows/windowsmedia/9series/codecs/vcm.aspx

In addition to fixing bugs in the beta release, we have made this VCM dll work for Win2K, WinME, and Win98SE, in addiiton to XP.

Thanks,

Ming
Microsoft

Sgt_Strider
8th July 2003, 04:22
Ming, I started a post a while ago to ask about 2 pass encoding bitrate, but you weren't very specific. I was wondering if you can answer that now? This is the post from before:

I don't think there is a calculator that is available for
calculating the right bitrate to use for a WM9 2 pass
encode session. There is one for xvid, RV9, and divx5. Do
anyone here know a formula to determining the right
bitrate? I made a post in the doom9 forum and a microsoft
employee name MingCl mention the following:

"The way to calculate the bitrate for 2-pass VBR is
pretty much the same as CBR (except the factor of buffer
size in CBR).

However, one key factor, which we didn't seem to document
in the help of the VCM beta release (and I will make sure
that we add this in RTM), is that there is no frame
dropping allowed in the VBR mode on the encode side. That
is, if the specified bitrate is too low and the ecoder
can't meet this target even when using the lowest
quality, it will exceed the bitrate. This is documented
in WMEncoder 9, but not WMV 9 VCM beta.

But I am not sure whether this is the cause of Crabba's
issue since it is strange that the bitrate is decreased
when the key frame distance is reduced. It should be the
other way. So I do need to get Crabba's settings and
possibly source as well to repro the problem here."

I'm hoping that one of you at least have a clue in what
he's saying and clearify this for me. Thx

mingcl
8th July 2003, 21:47
Thanks for the questions.

The way we calculated the bitrate for 2-pass VBR is pretty straightforward - total number of bits used divided by the clip length. WMV 9 encode would try to meet this target in its rate control.

However, since we don't allow any frame to be dropped for VBR, the final bitrate might exceed the one users specify before encoding if the bitrate is too low and the encoder still can't meet the target bitrate using its lowest quality level to encode. But this should only happen in extreme cases.

Note that when we calculate the bitrate, we only count the bits for the video elementary stream. That is, stream without file container overhead. So the final file size will be a few percent higher than what you specify or expect.

I am not sure whether this answers your question.

Thanks,

Ming
Microsoft

bond
8th July 2003, 22:27
Originally posted by mingcl
In addition to fixing bugs in the beta release, we have made this VCM dll work for Win2K, WinME, and Win98SE, in addiiton to XP.wow wow, today a directshow filter for rv9 was released and now that...

now the heavy testing can begin :)

Sgt_Strider
9th July 2003, 00:59
Originally posted by mingcl
Thanks for the questions.

The way we calculated the bitrate for 2-pass VBR is pretty straightforward - total number of bits used divided by the clip length. WMV 9 encode would try to meet this target in its rate control.

However, since we don't allow any frame to be dropped for VBR, the final bitrate might exceed the one users specify before encoding if the bitrate is too low and the encoder still can't meet the target bitrate using its lowest quality level to encode. But this should only happen in extreme cases.

Note that when we calculate the bitrate, we only count the bits for the video elementary stream. That is, stream without file container overhead. So the final file size will be a few percent higher than what you specify or expect.

I am not sure whether this answers your question.

Thanks,

Ming
Microsoft

No it really didn't answer my question. What if I want to use the WME9 Encoder and I want to use WM9 5.1 Audio, how will I calculate the overhead and everything else?

Lobuz
9th July 2003, 02:48
One question: How can I set up the output video color space to YUY2 instead of YV12 with WMV9?

Regards
Lobuz

mingcl
9th July 2003, 06:01
Originally posted by Sgt_Strider
No it really didn't answer my question. What if I want to use the WME9 Encoder and I want to use WM9 5.1 Audio, how will I calculate the overhead and everything else?

There are rate controls in each encoder (e.g., WMV9 and WMAPro 5.1). You specify the bitrate for each stream separately in WMEncoder. Each codec will make sure it meets the target bitrate. The only thing that might be hard to project is the size (overhead) of the file container (e.g., ASF in case of using WMEncoder). However, since the percetage of this overhead is typically very small unless the bitrate for the elementary streams is very low. So the overall impact should be quite small.

Originally posted by Lobuz
One question: How can I set up the output video color space to YUY2 instead of YV12 with WMV9?


Lobuz,

You can use the VCM or the DMO codec in the DShow GraphEdit. I believe you can control the output color space from GraphEdit. And of course some of the video cards out there do not support YV12 output. In this case, the decoder would default to YUY2 if the card supports this format.

Ming
Microsoft

Sgt_Strider
9th July 2003, 06:25
Originally posted by mingcl
There are rate controls in each encoder (e.g., WMV9 and WMAPro 5.1). You specify the bitrate for each stream separately in WMEncoder. Each codec will make sure it meets the target bitrate. The only thing that might be hard to project is the size (overhead) of the file container (e.g., ASF in case of using WMEncoder). However, since the percetage of this overhead is typically very small unless the bitrate for the elementary streams is very low. So the overall impact should be quite small.

Ming
Microsoft

Alright from the 2 posts that you have provided, I get the idea that I will the encoder will never really give me the exact filesizes that I want from my choosing of the bitrate. However it'll be really close.

In the help file of the WMV-9 VCM codec, this is what I found: "The Windows Media Video 9 VCM encoder will encode the content to a stream that is as close as possible to the specified bit rate. Often, the resulting stream has a slightly higher or lower bit rate than specified.

"When you specify the bit rate for two-pass VBR, the value is the average bit rate for the entire stream, not the average over an interval determined by the buffer window."

Ok I understand that and I don't think you have answer my question about the overhead. How do I calculate that? Also how does resolution factor into the calculation of the bitrate?

snowcrash
9th July 2003, 08:13
Originally posted by bond
wow wow, today a directshow filter for rv9 was released and now that...

now the heavy testing can begin :)

What's this about a directshow filter for RV9? I can't find anything about this.

bond
9th July 2003, 09:31
@strider
i guess what ming wants to say is that you cant exactly calculate the final filesize as you cant calculate the overhead (you have to guess -> ~5mb?)

@snowcrash
what about using the search function?

wing1
9th July 2003, 14:45
now there are three contenders : xvid, wmv9, & RV9 :D Thanks for a great codec. It is really close to xvid quality. Basically a toss up between xvid or wmv9 now.

snowcrash
10th July 2003, 00:35
bond,

I searched the forum and cannot find any mention of this "directshow filter for rv9". That's why I'm asking.

celtic_druid
10th July 2003, 04:21
That would be because it isn't just for RV9. Thread is here (http://forum.doom9.org/showthread.php?s=&threadid=56940) anway.

Dark-Cracker
10th July 2003, 07:50
hum could u add the save of the parameters in the registry plz ?
thank u :)

Bye

wing1
10th July 2003, 13:02
@mingcl
what are the chance for this codec to be playable via xbox?

Vladdy
11th July 2003, 08:48
@ wing1

bwahahahahahahah

Thats just funny.. I realise you're asking a serious question, but what chance do you have of MS 'supporting' or making available a codec which well, you shouldn't really have anyway.. To be able to play anything naughty like mpg4 codecs, you'd need a modchip.. Which we all know MS's view on that one

celtic_druid
11th July 2003, 14:03
Haven't really looked into it too much, but I would think with the recent developments you could run xbmp without a modchip or even opening your XBox for that matter.

Apparently XBMP does support WMV9, although I am not sure about out of a WMV container.

amigd23
11th July 2003, 21:10
@Ming

Will there be an ACM version of Windows Audio Codec 9 ?
It seems I still can't use WMA9 for WMV9 in VirtualDUB !

Crabba
12th July 2003, 00:00
Great news indeed! Now if you could also include a decoder properties window where you can change post-processing settings that would be REALLY great! Since you might want to be able to use different postprocessing settings on different material, and going in the registry to change each time isn't too funny.

Great stuff nonetheless! I've been looking forward for this one :)

wing1
12th July 2003, 00:19
well, wmv-9 vcm codec is MS for containers other then wmv. Nevertheless, it belongs to MS. Xbox is MS PC console which is designed to use MS products....so I figure the build-in media player could be allow to play this particular codec in AVI container. Just a thought :D

Vladdy
12th July 2003, 03:57
I'd love to see some sort of player on the xbox being able to play wm9 encodes.. Infact, if they were ever able to release such a player I'd go out and buy one today. I have a few wm9 720x576 encodes on some dvd-rs with ac3 sound, but somehow I feel that the 733mhz celery in the xbox would have a hard time trying to decode that without stuttering..

len0x
12th July 2003, 10:12
Originally posted by Dark-Cracker
hum could u add the save of the parameters in the registry plz ?


I'm thinking the same thing :)
So I guess right now codec properties are not reachable via registry?

wing1
12th July 2003, 17:19
hmmm...it seems that if you choose AUTO for decoder and 55 for smooth/sharpness level, then the output produces a nice go between xvid and RV9 sharpness.

@mingcl
The reaction period is a tad off. I have tried to tweak it via the buffer option, but it is still a tad too slow. Hence, the frames after scene change suffer a little (approximately 1sec).

StoneRoses
13th July 2003, 18:57
Originally posted by celtic_druid
Apparently XBMP does support WMV9, although I am not sure about out of a WMV container.

XBMP can play Windows Media 9 in wmv container (using M$ Win32 dll). I did not test WMV9 in avi container. But I think it should play fine (if it not, the easy change in XBMP code will fix it)

Sgt_Strider
16th July 2003, 20:48
Is it still possible to code a bitrate calculator for WM9 despite WM9 VCM codec doesn't save the settings to the registry?

Crabba
18th July 2003, 17:05
After some testing with the new version, I've found a bug that was not there in the previous version. When setting the codec parameters for 2-pass the new version doesn't allow long folders & filenames with spaces for the logfile, probably especially for folders with '-' in the name, since it doesn't add any '""' around the filename. You get an error message when trying to quit the settings window and it cuts the logfile to the first space.

Some other strange behaviour noticed:

Sometimes I get lots of repeated keyframes for no apparent reason, where the image is pretty much static?! Examples include very dark, almost black scenes with a lot of keyframes after eachother even though there's hardly any motion. Another time there was a landscape shot with the sun had a lot of keyframes directly following eachother and I could hardly spot any differences between the keyframes...

Also, just a very short number of keyframes (perhaps 1-5 in an hour program) get VERY ugly and smoothed, only to be fixed by the 2-5 following frames to be fairly identical to the original...
This is sort of irritating, even though it's not visible most of the time when watching the clip at full speed.

FYI i'm using high bitrate & high resolution on very high motion material... bits/pixel in Gknot is about 0.285-0.315

Otherwise I'm really happy with the quality this codec is producing! For the material I'm encoding ATM i'm surprised I'm getting as great quality as I am. :)

wing1
21st July 2003, 04:32
too bad, ffdshow does not decode this codec. It would be great to add some grain to the playback :D I had to resort to avisynth to add grain for playback. The result is pure eye candy :p

edit: No need to use avisynth for adding noise...use ffdshow to playback instead :D

Crabba
27th July 2003, 23:16
Unfortunately it seems like WMV9 (final) has some kind of rate control problems or something?! I've noticed several times now on files I've encoded that quality is great almost all the way but in the last couple of minutes where it suddenly does a lot of smoothing on keyframes and simply a lot worse quality than the rest...

stax76
28th July 2003, 00:13
I'm thinking the same thing
So I guess right now codec properties are not reachable via registry?


I suggested saving in the registry already to the guy who announced the beta. Looks like for now we can't support this codec in GK, DVX etc.

Jeremy Duncan
10th May 2007, 04:24
Yay !
Thank you very much for the nice Codec.

zambelli
13th May 2007, 09:26
Umm... Jeremy, that thread is 4 years old. :)