New VP6 codec - 6.0.9.2

[On2Tech]

I'm happy to announce that a new version of our VP6 codec is now available for download at www.on2.com. We've made some rather substantial improvements to two pass compression based largely on feedback we received from this forum. I'd like to encourage everyone to download the new codec and give it a try.

Improvements include:

Version 6.0.9.2 12/22/2003
=======================================
- New user's guide added to the installation
- DirectShow Decoder in the installation updated to version 6.0.7.2 (changes to the decoder settings now change the VFW post processing level in addition to the direct show post processing level)


Version 6.0.9.2 12/16/2003
=======================================
- Fixed problem with missed key frames
- Fixed problem with Keyframes that were way too big in 2 pass mode
- Improved two-pass vbr by being more agressive with quantizers
- Improved best quality
- Improved quality in slow moving sharp scenes.

You may want to refer to the new graphs posted in the folloing thread for reference:

http://forum.doom9.org/showthread.php?s=&threadid=64789

[Tommy Carrot]

I still don't like the rate-control, or at least the default settings of it. The 2-pass should deliver more or less constant quality, but it still fluctuates strongly. The low motion scenes are usually excellent, but if there are more motion, the quality degrades badly. I think the ratecontrol favors the low motion scenes too much.

What settings do you suggest for more consistent quality? Should i set variability to 100?

[Jaques]

Great, thanks!

[On2Tech]

Originally posted by Tommy Carrot
I still don't like the rate-control, or at least the default settings of it. The 2-pass should deliver more or less constant quality, but it still fluctuates strongly. The low motion scenes are usually excellent, but if there are more motion, the quality degrades badly. I think the ratecontrol favors the low motion scenes too much.

What settings do you suggest for more consistent quality? Should i set variability to 100?

The new codec should have spent far more bits on tougher sections than the old version. Did you see an improvement at least?

I think the defaults should work.

Can you post an example so we can look into what you are getting?

[Tommy Carrot]

I did a short encoding on a 4 min. long clip with xvid and VP6, and i did a frame-by-frame comparing between them. The low motion scenes are better with VP6, but in the high motion scenes the xvid clearly preserves more details (the postprocessing is off, so not it is the cause). The rate-control of the xvid proved in many cases as a rather constant one, so this is why i came to this conclusion.

BTW, i think it's improved from the previous version, but still has some fluctuations.

[slavickas]

Hi i got problem with this release every (tested only few) files makes winamp 5 decoder create file badframes.stt (it maybe bug on wa5 side) but previous codec build generated files plays ok

edit: seems the same and for avi vp6 files

[Sirber]

Why do you use Winamp 5 for playing movies?

[On2Tech]

Originally posted by slavickas
Hi i got problem with this release every (tested only few) files makes winamp 5 decoder create file badframes.stt (it maybe bug on wa5 side) but previous codec build generated files plays ok

edit: seems the same and for avi vp6 files

WinAmp includes its own version of VP6 ( ie it doesn't call the vfw codec). Does the problem occur if you try and play it back using virtual dub, windows media player or real etc?

If not I'll point out the bug to our contacts at AOL. In the meantime you might want to let them know

Winamp Forum

[slavickas]

Originally posted by On2Tech
WinAmp includes its own version of VP6 ( ie it doesn't call the vfw codec). Does the problem occur if you try and play it back using virtual dub, windows media player or real etc?

If not I'll point out the bug to our contacts at AOL. In the meantime you might want to let them know

Winamp Forum

yes problesm persist in *.avi files, if they are played by MPC,
but as i indicated files encoded with eralier codec version don't generate that file

note: quality isn't decreased but it just simply outputs that file always

for some info about troubles You can check this thread
http://forums.winamp.com/showthread....59#post1213759

[SeeMoreDigital]

I've been trying to generate some low bitrate (77KByte/s) 2pass VBR encodes using MPEGmediator.

However, to me they still don't look as good as I would have hoped. They still look about the same as 1pass CBR.

I think I can't be doing it correctly!

Cheers

[Tommy Carrot]

Originally posted by SeeMoreDigital
I've been trying to generate some low bitrate (77KByte/s) 2pass VBR encodes using MPEGmediator.

However, to me they still don't look as good as I would have hoped. They still look about the same as 1pass CBR.

I think I can't be doing it correctly!

Cheers

Same here, somehow the RC doesn't work here as it should.

[Bulletproof]

As of right now I have XviD winning in my visual tests with post processing off. I think VP6 may still have the keyframe bug because I have at least found 1 major spot where a keyframe was not inserted and looked really bad. What I'm seeing right now is that VP6 is handling gradients and hazes better while XviD is handling motion better.

EDIT: Keyframe bug definitely still exists, its crippling the quality. Either it's bugged or its decisions are bad, because I can find spots where XviD inserted a keyframe and maintains quality and in VP6 it severely blocks up because of that missed keyframe, HOWEVER I can find spots in VP6 where there is a keyframe which is not inserted in the XviD video, but it seems as there is no penalty on XviD's side because it has made a good decision. XviD's P-Frame doesn't look bad at all where a spot where a VP6 I-Frame would be.

[SeeMoreDigital]

Yes, well something is still not right.

I've been using Ch41 of StarWars 2 as my source file. Which at 6min and 17sec provides a very good indicator at how well a codec can perform.

I've got a series of encodes generated by different codecs. And different versions of the same codec. Which have all been I generated at 720x576 at around 615kbps using both 1 and 2 pass modes.

But like I say, I still can't get this new version of VP to generate 2pass encodes that look any better than the previous version!

[On2Tech]

Originally posted by slavickas
yes problesm persist in *.avi files, if they are played by MPC,
but as i indicated files encoded with eralier codec version don't generate that file

note: quality isn't decreased but it just simply outputs that file always

for some info about troubles You can check this thread
http://forums.winamp.com/showthread....59#post1213759

We've duplicated and are addressing this problem. THanks for reporting it.

[SpaceV]

ok please don't kill me for that, it's just a stupid idea
that I have to ask but is it possible the the codec was not
updated correctly? I have not upgraded since the initial release
and with what I have heard so far there is no need since the keyframe bug still exists.

If I should upgrade to 6.0.9.2, how would I make sure that
the upgrade was successful ?

thanks

[slavickas]

Originally posted by On2Tech
We've duplicated and are addressing this problem. THanks for reporting it.

if it not allways happens any workarounds? does it affects vp60 or just vp61 only?

[SeeMoreDigital]

Originally posted by On2Tech
We've duplicated and are addressing this problem. THanks for reporting it...

What a shame!

[slavickas]

Originally posted by SeeMoreDigital
What a shame!

i wouldn't say so radical, but if they released, for us hardcore tsters some prerelease versions before posting it officialy maybe somebody (=i ) would have spotted it

[On2Tech]

Originally posted by slavickas
i wouldn't say so radical, but if they released, for us hardcore tsters some prerelease versions before posting it officialy maybe somebody (=i ) would have spotted it

The problem happens for both VP60 and VP61. The bug is hard to describe. Basically we read past the end of the buffer past the end of the bitstream ( even though we didn't use those bits). Fix solves the problem.

Incidentally prior to the latest release it would happen much less frequently but could still happen. We are testing a new version that solves it. Badframes.stt was a safety check that printed out only when we tried to read a byte past t end of the buffer.

[SeeMoreDigital]

Hi On2Tech

Will we have to wait long for the revised release?

Cheers