XviD-05042003-1

[iago]

Hello Koepi (and all),

I have finished my second encode with the 05042003-1 build, using very plain avs scripts for both encodes including only UnDot() and Limiter(), and aiming for 1CD with ogg audio. I am really glad with the results I have got with the following encoding parameters, though it takes a damn long time on my poor system using all those amazing advanced features:

h263
vhq1
cm
qpel
b-frames 3/150/100/0
chroma optimizer

Using ffdshow latest to decode and it's great not to have the qpel smearing anymore.

best regards,
iago

[Koepi]

Thanks for your test iago! Nice to see that you're back on xvid-track again ;)

I've new settings which usually give very nice results:

in the avs script, i use LumaFilter(), UnFilter(values depending on the source), UnDot() and on noisy DVDs Convolution3d(values depending on the movie). LanczosResize() if possible, else bicubic(..,..,0,0.5).

I nearly always use the hvs-good-picture-matrix.

bframes: 2/150/100/255 (!)

I found that 3 bframes harm quality considerably, maybe you want to retest with 2 bframes, iago :)

Chroma ME

(seldom qpel, helps (de-)ringing a lot)

VHQ1

linear scaling, payback proportional (looks better to me in the meantime)

The secret is to tune the avs-script so that ringing and noise gets reduced. With this procedure, my encodes look really amazing.

I think i'll set those values as default in my next builds ;)

Best regards
Koepi

[iago]

Hehe, heya mate, thanks a lot for sharing your settings. ;)

b-frame threshold: 255

Wow! Though I really like the quality of b-frames in the latest build, it is really a quite heavy b-frame setting, isn't it? Still, the possible drawbacks are perhaps compensated with the use of 2 b-frames instead of 3, as you have mentioned. However, I really like the p-b frame decision in this build with the default threshold of 0 ;).

payback proportional

That's what I had always recommended in my previous posts, but it was you then who had discouraged me, insistently suggesting payback with bias! ;)

vhq1 - cm - linear scaling

Yeah, I guess these three are already commonly agreed upon feaures, aren't they?

q-pel

As long as it doesn't pose smearing (seems that the problem is finally resolved in the latest ffdshow together with the use of simple idct in your builds), I won't give up on it.

And, for 1CD encodes, I usually prefer to stay within the limits of BicubicResize, not more than (..,..,0,0.5), unless the movie is "very" compressible.

Finally, yeah, fine tuning the avs scripts with LumaFilter, UnFilter, etc. has always been a great pleasure for me too! ;)

Thanks a lot one more time for all your effort and great work, my friend (and of course, all other developers of XviD).

ciao,
iago

edit: and the good old h263 is still my favourite for 1CD encodes, though I agree with you that hvs-good-matrix produces pretty nice results as well.

[manono]

Hi-

b-frame threshold: 255

Wow!

Yes, that one surprised me also. I really like having the threshold feature, and I'm very conservative with the B-Frames (I only use 1, with thresh=10). But it was good to see Koepi's preferred settings. Thanks! Now you've got no more secrets to hide. :)

And it's really nice to see you around more often, iago.

[kastro68]

Can I ask what the default B-frame threshold for Koepi's 17-02-2003 build is.

Because I tried the 5-04-2003 build with a B-threshold of 50 and still liked the 17th build more.

[iago]

Koepi,

You are definitely not only a great "coder" but also a great "encoder", my friend! Yeah, now I really like using b-frames (2-150-100) to its full extent with a threshold of 255! And yes, quality is still there! ;)


Heya manono,

Yes, it's really nice to be with all the great people around here again. Btw, you should try this setting as well! ;)

best regards,
iago

[PerCIVaL]

I was meaning to ask this,

The hvs-good-picture-matrix, what are the benefits of this matrix?

can anyone explain? I usually go with the standard h263 or modulated hq matrices of xvid.

Ow, and where can I get it?

[iago]

PerCIVaL,

You can find it here:
http://forum.doom9.org/showthread.php?threadid=34493&highlight=hvs+matrix

And imho it's better to try yourself and do your own comparison to see the differences.

iago

[PerCIVaL]

thanks iago,

I'm trying it now.

[corigan]

And I always thought GKnot setups VDub via the joblist because that's what it's there for.

Please take a look at the vdub forum and see if it is somewhere mentioned (some internal variables changed versus original vdub, thus it might be that gknot messes with the wrong ones).

And: do your encoding properly, without one-click-and-go-tools. As you can see, they aren't adopted to the new builds of the used tools and can't unleash the full features available, or mess up otherwise.

Still no xvid bug. It's gknot or vdubmod which are failing.

----------------

I have used the 0504 codec a few times without crashes and no problems. I use gknot just to make the simple avs script, cropping, and bitrate calc. Then I go and edit the avs scripts by hand and add in all the features I want that gknot doesn't offer. I then go and encode by hand in vdub/vdubmod. I installed the new gknot rip-pack/codec 1.1 pack two nights ago (0.28) and low and behold I now crash right after the first pass like previously stated in this thread. This definately shows me that it indeed isn't an xvid problem with the codec since I had used the new 0504 for encodes a few time with no problems (previous to install of rippack/codec pack) . Unfortunately this is just damn annoying with the crash right after the first pass. With virtualdub 1.51 I couldn't even go back in and do the 2nd pass by hand via the job control. I did go in with vdubmod and just do a flat out 2nd pass and use the stats file (that was created from the first pass before the crash) and it worked (not via the job control). I wonder if this has something to do with the job control, and my question would be what was re-installed/installed by the new gknot packs that is making this error occur. I know it's not anything that would deal with your codec koepi, just thought I would post my findings here and see if anybody else has any idea how to get rid of this error. Gknot also did not overwrite the specific build of vdubmod or vdub that I use (I keep them in seperate directories away from gknot) but now both seem to be plauged with this problem. Oh well, Hope someone can figure this out, I'm off to do some more testing to see if I can figure out a solution on my own.

Corigan

[corigan]

I'm lame, looks like it's ffvfw that is causing the crash due to B-Frames. I assume everyone else who is experiencing this crash has ffvfw installed and was trying to use b-frames in their encodes. I removed ffvfw and the crash on the 2nd pass (with bframes) and another error I was recieving (when selecting the compression menu, an err with WMVcore.dll) have both gone away. I guess it would help if I would read the first post of the ffvfw thread (you know, the one that says b-frames don't work in 2 pass mode yet.. :P) Oh well, sorry to spam your thread koepi, but this indeed does prove it's not a problem with your codec.

Corigan

[Menion2k]

what is ffvfw???

[Siku]

@Forum
I've made a dozen ecodes with this build and I've got pretty good results. I especially liked the result when I tested Koepi's suggestion of using b-frames 2/150/100/255.

@Menion2k
Check this (http://forum.doom9.org/showthread.php?s=&threadid=42710) out.

@Koepi
Is there coming a new build soon? :)

Regards,
Siku

[Menion2k]

weel i dind't install ffvfw, so my crashes between first and second pass is due to another cause. Bye!

[Rober2D2]

Just to make a bit more noise . Cuold somebody explain me what a message 'BrokenB-Frame, TPP=0 TBP=2' means. I get it when seeking frame-by-frame in a stream encoded with the above mentioned settings.

I have had this same problem, but only when I use Packed Bitstream. It appears a few times during a film. Problem seems to be solved in Umaniac's build from 14/04/2003, although I must make more test before assuring this.

[sungey]

Using Koepi 5-4-2003

Motion Precision = 6
Quantization Type = h.263
FourCC = DX50
VHQ = 1
Chroma ME = ON
Max-Min I frame = Default

Max B frame = <varies>
Bframe ratio/offset = default
Bframe threshold = 255

DX50 compatibility = ON

<Config> <First pass size>
Using 2 bframe = 207 mb
Using 3 bframe = 204 mb
Using 4 bframe = 204 mb
Using 5 bframe = 206 mb
Using 6 bframe = 207 mb

Note the changes of filesizes .. anyone know why is it like that ?

[Koepi]

The "usual" I/P motion detection gets less effective (remember, bframes derive from I/P-frames, but nothing derives from bframes) due to the fact that the frames are further distance which it has to work on.

Koepi