Found a video scene that was (IMO anyway) a true *Codec Killer*, so ran a quick comparison between the stand alone winmedia 9 encoder and the VV4c winmedia 9 plugin. [this scene included high contrast lighting, complex, beige backgrounds, closeups & group shots, shadows from flames, panning reflections over a complex background - in other words, all sorts of stuff that codecs hate]
A quick summary:
Rendering a clip a bit over 3 minutes, 35 seconds in length with identical (peak VBR) settings took 14 min 54 sec in VV4c versus 13 min 10 sec in the stand alone encoder. Playing with the numbers, this means that a render that takes 5 hours in the MS encoder should take *roughly* 40 minutes longer in VV4c, which may or may not be the case - one would have to do several long renders with a variety of scene content in both programs to get really meaningful results, so take this for what it is.
Regarding compressed file size, the winmedia encoded version totaled 32,204,288 while encoding in VV4c resulted in a file size of 32,100,146.
Compared visually (full screen at 1024 x 768), the rendered videos had some striking differences - the Vegas encoded file bore a lot of the characteristics usually associated with RealVideo9... The Vegas encoded file had some noticeable smoothing of the foreground (facial features during closeups), with a greater degree of smoothing (& lost detail) applied to the background.
The MS encoder while retaining more detail, also exhibited quite a bit more noise, most often of the variety where you can pick up very noticeable, patterned movement of or on what should be a static surface. A matter of personal preference effecting some content more then others, it's an important consideration when deciding project workflow.
Earlier tests indicate that the encoder itself is responsible for a lot of any visual improvement with winmedia 9 versus v.8, 7.1, & the original mpg4, so this difference is to me at least very interesting. It would be interesting as well to compare output from other programs now that MS has released their wrapped wmv9 encoder that can be used by V/Dub etc... [I'll try it myself with the next release of V/Dub - if I remember. See virtualdub.org - if current version's buggy, not a good test platform.]
Other stuff I've found:
If you wanted to enable fast forward/reverse scanning when played (or in MS terms, it used to be called seekable and strideable), indexing used to be required for winmedia video files as a separate step or render setting, With the VV4c winmedia9 plugin, there is a checkbox for indexing, but it appears unnecessary. That's a good thing as it *may* have caused VV4c to hang at the end of a long render, during what appeared to be the indexing phase (Several winmedia encoder/tools go through the indexing process after a render or process is complete).
Does it happen every time? I have no idea - I was intending to check this out further, but as it appears to have no effect on the rendered file whether the box is checked or not, I've not used it since, not experienced the prob., and as far as I can tell, the rendered files have suffered no ill effects. Don't know what the benefit is or would be.
Indexing of wmv files is possible using the MS Windows Media File Editor, which works much faster then earlier versions like the Advanced Script Indexer. Unfortunately, the tool seems to be at odds with Vegas when it comes to embedded markers (assuming others are using winmedia markers - if you're not, really should check it out). It's probably due to different timing schemes, & if one prog is at fault, the error would appear to be with the MS tool rather then VV4c.
In practice, if you open & save a wmv file in the Media File Editor, any markers set during a VV4c render will be moved anywhere from a few frames to a few seconds earlier then the original. A bit of a pain if you set a marker without enough padding in Vegas (3 frames or so after the desired time or frame), as wmplayer seems to want to go to these markers a frame or so early - any adjustments have to be made with something like the MS tool or else re-rendered, meaning all markers have to be reset.
Not a huge deal, but an extra step you might not count on. And the Media File Editor may be the only way to set the quiet mode & mixdown properties of a winmedia 9 file with 5.1 audio. [If you've not played with this yet, wmplayer 9 offers automatic mixdown of 5.1 to stereo, as well as featuring a Quiet Mode; similar to the controls on some cable boxes, it sets the level of audio compression to one of two levels if activated on playback. This is not compression in the sense of mp3, but as in applying compression FX to your audio track in VV4c, compressing/lessening the range of levels from quietest to loudest.)
I mentioned in an earlier post that VV4c behaves a bit differently rendering a wmv file then the MS stand alone encoder 9: a 24p file/proj rendered at the closest option of 29.976 fps to winmedia 9 in Vegas will generate "tweener" frames not unlike what you see with something that's been telecined from 24p to 29.97i. This appears to lengthen the render time in VV4c by about half, so a 3 hour render would take about 4 1/2 hours. This is just based on 1 instance, so should not be considered any ironclad rule of thumb.
Thanks
mike
A quick summary:
Rendering a clip a bit over 3 minutes, 35 seconds in length with identical (peak VBR) settings took 14 min 54 sec in VV4c versus 13 min 10 sec in the stand alone encoder. Playing with the numbers, this means that a render that takes 5 hours in the MS encoder should take *roughly* 40 minutes longer in VV4c, which may or may not be the case - one would have to do several long renders with a variety of scene content in both programs to get really meaningful results, so take this for what it is.
Regarding compressed file size, the winmedia encoded version totaled 32,204,288 while encoding in VV4c resulted in a file size of 32,100,146.
Compared visually (full screen at 1024 x 768), the rendered videos had some striking differences - the Vegas encoded file bore a lot of the characteristics usually associated with RealVideo9... The Vegas encoded file had some noticeable smoothing of the foreground (facial features during closeups), with a greater degree of smoothing (& lost detail) applied to the background.
The MS encoder while retaining more detail, also exhibited quite a bit more noise, most often of the variety where you can pick up very noticeable, patterned movement of or on what should be a static surface. A matter of personal preference effecting some content more then others, it's an important consideration when deciding project workflow.
Earlier tests indicate that the encoder itself is responsible for a lot of any visual improvement with winmedia 9 versus v.8, 7.1, & the original mpg4, so this difference is to me at least very interesting. It would be interesting as well to compare output from other programs now that MS has released their wrapped wmv9 encoder that can be used by V/Dub etc... [I'll try it myself with the next release of V/Dub - if I remember. See virtualdub.org - if current version's buggy, not a good test platform.]
Other stuff I've found:
If you wanted to enable fast forward/reverse scanning when played (or in MS terms, it used to be called seekable and strideable), indexing used to be required for winmedia video files as a separate step or render setting, With the VV4c winmedia9 plugin, there is a checkbox for indexing, but it appears unnecessary. That's a good thing as it *may* have caused VV4c to hang at the end of a long render, during what appeared to be the indexing phase (Several winmedia encoder/tools go through the indexing process after a render or process is complete).
Does it happen every time? I have no idea - I was intending to check this out further, but as it appears to have no effect on the rendered file whether the box is checked or not, I've not used it since, not experienced the prob., and as far as I can tell, the rendered files have suffered no ill effects. Don't know what the benefit is or would be.
Indexing of wmv files is possible using the MS Windows Media File Editor, which works much faster then earlier versions like the Advanced Script Indexer. Unfortunately, the tool seems to be at odds with Vegas when it comes to embedded markers (assuming others are using winmedia markers - if you're not, really should check it out). It's probably due to different timing schemes, & if one prog is at fault, the error would appear to be with the MS tool rather then VV4c.
In practice, if you open & save a wmv file in the Media File Editor, any markers set during a VV4c render will be moved anywhere from a few frames to a few seconds earlier then the original. A bit of a pain if you set a marker without enough padding in Vegas (3 frames or so after the desired time or frame), as wmplayer seems to want to go to these markers a frame or so early - any adjustments have to be made with something like the MS tool or else re-rendered, meaning all markers have to be reset.
Not a huge deal, but an extra step you might not count on. And the Media File Editor may be the only way to set the quiet mode & mixdown properties of a winmedia 9 file with 5.1 audio. [If you've not played with this yet, wmplayer 9 offers automatic mixdown of 5.1 to stereo, as well as featuring a Quiet Mode; similar to the controls on some cable boxes, it sets the level of audio compression to one of two levels if activated on playback. This is not compression in the sense of mp3, but as in applying compression FX to your audio track in VV4c, compressing/lessening the range of levels from quietest to loudest.)
I mentioned in an earlier post that VV4c behaves a bit differently rendering a wmv file then the MS stand alone encoder 9: a 24p file/proj rendered at the closest option of 29.976 fps to winmedia 9 in Vegas will generate "tweener" frames not unlike what you see with something that's been telecined from 24p to 29.97i. This appears to lengthen the render time in VV4c by about half, so a 3 hour render would take about 4 1/2 hours. This is just based on 1 instance, so should not be considered any ironclad rule of thumb.
Thanks
mike