XviD 06042002-1

[Koepi]

Ahoy,

since there were some small changes in CVS, I updated my binary:

XviD-06042002-1:
- EPSZ and EPSZ^2 activated.
- Fresh CVS checkout


Best regards,
Koepi

[rui]

I have been reading some posts stating that by using MV hints, the quality is a little lower.
By any chance does this build brings anything new to that? I for one am prepared to wait a little longer for my rip if i know that it will have more quality.
But on the other hand, i certainly see that we don't have all the same objectives, so MV hints is a GREAT feature to have. :)

Another thing that has been in my mind:
I remember when i first tried xvid, i enabled lumi masking. But when i watched the resulting avi, the most darker scenes in the movie were a little to the bad side. Much has evolved since then, but i never used lumi masking again.

I was thinking that maybe lumi masking could implement some sort of levels, like the psicovisual from divx5 (which is broken, by the way ;).
So people like me, who don't want a too strong effect, could choose, lets say level 1.
People that already use lumi masking could choose level 2 or maybe a level 3.
Just an idea, i don't really know if his makes sense (to me it does, but to a developer could be just a shitty idea).

[CavalloPazzo]

I founded that using Hinted ME increase quality...
With a fixed quantizer the size grow up a little using hinted motion vector but the image is very cleaner with much less artifact !!!
Try by yourself !

[canadian_fbi]

with the same quants using the same build of xvid, how could the quality be any different? were you using the same quant type in both encodes?

and i have to agree with rui... after thinking about it i think i'm willing to take the few extra minutes for now just to squeeze every bit of quality out as possible. though i greatly appreciate the option of the hint file and all the other options -h has put in, even if i don't use them myself :)

[wing1]

What has changed since 4/5/2002 to CBR mode?

This build produces very sharp video and less macroblock; However, CBR mode has slow down considerably. Normally, I can capture at around 30%-45% CPU and max at ~85% (high motion), now it uses 100% CPU most of the time: This is using the same settings from previous build.

[-h]

1with the same quants using the same build of xvid, how could the quality be any different? were you using the same quant type in both encodes?

Because in one pass we're using motion vectors generated "on the fly", and in the other we're reusing vectors from a different encoding session.

and i have to agree with rui... after thinking about it i think i'm willing to take the few extra minutes for now just to squeeze every bit of quality out as possible. though i greatly appreciate the option of the hint file and all the other options -h has put in, even if i don't use them myself :)

I personally didn't believe I'd use hinted ME, but here's what got to me - PMVFAST (by its nature) has a habit of "moving" static surfaces in order to make the vector map more compressible - unfortunately this has the extremely annoying side effect of say, the walls around a person's head moving when they turn their face.

By using the vectors from the 1st pass (i.e. quant=2), the added detail that the codec must store forces the vectors to better reflect "actual" motion, not "compressible" motion (two very different concepts), and the static surface movement is greatly decreased.

But then again, I rarely encode anything at all, so it's not all that big a deal :)

-h

[Foxer]

@wing1
I didn't remove my modification to keyframe spacing (i enforce keyframe spacing in cbr and qual/quant modes in my own builds) before sending the sources to -h to post.

I have no idea why it would make such an impact on your system since, surely, your captures aren't so motion intensive that all the frames would be i-frames without spacing..

Try reducing the min i-frame interval to 1 and see if that clears it up.

[canadian_fbi]

@-h: does this apply to EPSZ and EPSZ^2 at all? the static surface movement, and mv hints decreasing it, that is.

[libredr]

Personnaly, I do not care a lot about encoding speed, since I encode 1h30 to 3 hours movies and it takes about 6 to 8 hours. I do the encoding during a whole night then, so it would take 4 or 5 hours it would be the same. Thus I prefer to advantage quality.
However, this could be interesting for people encoding short movies.
It is important to have the choice.

Great job !

[wing1]

@Foxer

That works. I reduced the min I-Frame Interval from 2 to 1, and everything is back to normal CPU % usage.

I always used the same settings on previous versions and no matter how much motion are going on on the scenes ( car chases, bomb exploded, kung-fu-ing :D ) CPU % usage will max out at best at 85%, and most of the time it is running at 30-45%. Now all the person has to do is wave his arm in the scene and the CPU % usage shot up to 100% and stay there for almost 30 seconds or more. If a scene is panning left or right, the CPU % usage went to 100% and stay there almost forever. Now that I reduced the min I-frame interval to 1, the percent went down to normal as before. Is there a fix for this or is it going to be that way?

[Foxer]

@wing1
how odd..
there's no discernable difference in performance with normal cbr encoding with and without spacing..

oh well.. I'll go ahead and upload codec.c with spacing only applied to 2pass 1st pass again..

I guess I could make a page for the build with it enforced in cbr & qual/quant modes.. if anyone wants it.

so strange.. but you said you liked the results in the encode heh

[wing1]

@foxer

Well, can you give it an option button to enable/disable it instead of two different builds? I do like the encoding part of it. Perhaps in the future when I upgrade my CPU once again to 2100+ or something to that nature or dual CPU for that matter, then it would not be an issue anymore :D. For now, I will live if CPU is at 100%, it is not going to die anytime soon, because i've abused it plenty already before xvid :D. The alternative is to use older version for capture.

[-h]

@-h: does this apply to EPSZ and EPSZ^2 at all? the static surface movement, and mv hints decreasing it, that is.

I haven't tried the new EPSZx code yet, as from what I've read it has quite a bit of room for improvement.

-h

[CavalloPazzo]

Here's the link for 2 files encoded with 2 pass, MPEG quant, quant min=max=minI=maxI=5

http://spazioweb.inwind.it/fantacalciosim/test-hmv.avi (128 kb)
]http://spazioweb.inwind.it/fantacalciosim/test-nohmv.avi (120 kb)
(look in virtualdub the last frame)

The file with HME looks much better and the temporal smooth effect is quite gone.

Sometimes in long scenes p frames begin look very bad so when a Keyframe is inserted you can see the difference (Doom9 also noted this into his latest comparison). As for me p frames look better with hinted ME, this effect is much less visible.

[rui]

Well, i must agree with CavalloPazzo, at least judging for his samples.
The non HME avi has a little trailer, when Bruce Willis head moves around. The HME avi doesn't show that trailer so much.
I have just made a rip from the movie The Haunting, using the HME option, and i must say it looks very very good. The only comparison i can make is with a divx5 pro rip, and xvid looks better.
But i will try to compare xvid with and without HME, in smaller clips.

I guess my idea of a configurable lumi masking is no good?

[-h]

Well, i must agree with CavalloPazzo, at least judging for his samples.

I must say I prefer the hinting results at the moment. However motion estimation is going to be overhauled by the sounds of things, so it may fix the problem on its own.

I guess my idea of a configurable lumi masking is no good?

Have you tried it lately? It's quite different to the old builds, and should look better. Making it configurable shouldn't be too hard.

-h

[rui]

No, i must confess that i haven't used lately.
But i will. I will start a new second pass on the movie The Haunting, which is a perfect movie for testing lumi masking because it has many dark scenes.
Thanks

O.K. Starting 2 pass right now

[Koepi]

rui,

don't forget that luma masking seems to break MV hints ;)

Regards,
Koepi

[rui]

Really? Shit, i must stop the second pass then, and iniciate a new one without HME.:rolleyes:

[rui]

Well, i didn't stop the 2 pass after all. I thought "what the heck, now lets see what will happen".

And it already finished, and i can confirm that using HME and lumi masking is a No Go.

The movie got all messed up, collors changing, a lot of waves efects, the best way i can describe this ones is: imagine that the picture is water and someone drops a rock in it. :D

[Swede]

As usual I'm a bit late but I had to make sure it wasn't my fault :)
But (I think) the effect of Hints and Luma is more like if you replace one frame with a dead one, artifacts and block sort of 'stick' and then 'drags'. If you get it...

[Koepi]

That's why we repeat over and over again:

use MV hints only WITHOUT luma masking and use the same quantization type for first and second pass. In _no_ way use modulated quant type.

:P

Koepi

[-h]

Yeah I'll try to fix lumi / modulated stuffups tonight, along with Foxer's max bitrate code.

Modulated should be a quick fix, lumi masking will be harder..

Actually no it won't. I've been thinking about this, and we really shouldn't be "only" applying lumi masking in the 2nd pass. I dare say doing it in both passes would work equally well (or better, since it won't wreak havoc with the overflow), and it'd fix the hinting problem.

-h

[trbarry]

Nifty discovery. That will make life simpler in many ways.

- Tom