XviD-17082002-1

[Koepi]

XviD-17082002-1.exe (401kb)
Changelog:
- Removed scene change detection threshold control, it wasn't helping.
- Activated EPZS(^2) motion estimation algorithm.
- Added a patch from syskIn which gains 0.1dB in PSNR.
- Added Nic's newest DSF as the API version is compatible again.

Test it! I recommand hitting "load defaults" after deinstalling your old build and installing this build, I added "better" defaults which should improve your encoding quality a little more.

Best regards,
Koepi

[iago]

@Koepi

So nice, I was expecting this for a while :). Will give it a test try tonight immediately with the defaults.

Thanks,
iago

[Koepi]

merhaba iago,

don't expect too much from it, it's just defaulting to the curve values I gave on the other thread.

Off-topic:
Funny, you're physically closer to my GF than I am, she's in turkey ATM, visiting her family (ok, ATM she's in Istanbul, visiting some friends of us... :) )

Serefe,
Koepi

[iago]

@Koepi,

Off-topic:

Þerefe, dostum! ;)

sevgiler,
iago

:)

[Koepi]

Ok, a new package with the same Name is up. I modified the installer a little so that it (should do so at least!) an existing XviD Uninstaller before installing the new version. This was requested on a german forum as feature, and I hope it doesn't break anything :)

Best regards,
Koepi

[iago]

Hi again,

The installation of the new package/17082002-1 build is done in two stages (not automatically). First it uninstalls the existing build. Then you run it again, and it installs the new build, without any problems :).

Will give it a try tonight with my headache Blues Brothers, aiming for 646000 kb video size with 512*272/neutral bicubic resize :) (though I know that it is difficult to put this movie on even 2CDs with decent quality when you keep the AC3 audio). However, this is only a test encode without filtering and using the new :) default parameters (except motion search: 6 and lumi masking enabled in both passes and 1stpass/2nd pass: h.263/modulated quantization type).

After all, why not give it a go? ;)

so long,
iago

[Sigmatador]

go testing ^^ (and never sleep ;p), i'm going to test with matrix and austin power 2 (as usual :D )

[Schultz]

Originally posted by Koepi
Ok, a new package with the same Name is up. I modified the installer a little so that it (should do so at least!) an existing XviD Uninstaller before installing the new version. This was requested on a german forum as feature, and I hope it doesn't break anything :)

Best regards,
Koepi

Hum don't get me wrong i just don't see the logic why someone would want this. Since you are overwriting the same files so why go through the extra step of uninstalling the old one when it don't need config changes or anything like some other programs do..

[HarryM]

Originally posted by Koepi
merhaba iago,

don't expect too much from it, it's just defaulting to the curve values I gave on the other thread.

Off-topic:
Funny, you're physically closer to my GF than I am, she's in turkey ATM, visiting her family (ok, ATM she's in Istanbul, visiting some friends of us... :) )

Serefe,
Koepi


Doom9 use (doom9's test of codecs) default for alt-curve-values too. It's wrong, using default values?

[Neo Neko]

I have been jonsing for a new build. I am using it to graple with a capture I did Friday night ATM. I'll be sure to update on any nasties that crop up. ;)

Originally posted by Koepi
Off-topic:
Funny, you're physically closer to my GF than I am, she's in turkey ATM, visiting her family (ok, ATM she's in Istanbul, visiting some friends of us... :) )

O/T again. But I just could not resist! :D

<begin lyrics>
Istanbul was Constantinople
Now it's Istanbul, not Constantinople
Been a long time gone, Constantinople
Now it's Turkish delight on a moonlit night

Every gal in Constantinople
Lives in Istanbul, not Constantinople
So if you've a date in Constantinople
She'll be waiting in Istanbul

Even old New York was once New Amsterdam
Why they changed it I can't say
People just liked it better that way

So take me back to Constantinople
No, you can't go back to Constantinople
Been a long time gone, Constantinople
Why did Constantinople get the works
That's nobody's business but the Turks
<end lyrics>

[Nic]

(when it comes to the installation of filters, explorer.exe, when loading an XviD avi, grabs the xvid.ax dshow filter & doesnt let it go (as it does to all filters). So I do recommend restarting your computer before installing each new xvid build)

(Just thought id mention it, had been meaning to for a while ;) )

-Nic

[iago]

@Neo Neko

O/T again :):

Names don't matter that much bro; as long as you consider yourself as a "world citizen", all the cities in the world are still yours ;)...

deepest greetings,
iago

[Sigmatador]

what's new with the nic's DSF ?

[Koepi]

XviD-18082002-1.exe (401kb)
Changelog:
- Activated EPZS(^2) motion estimation algorithm.
- Modified the patch from syskIn - it was removing too many details
- The installer now first trys to uninstall old installations of xvid.

[Nic]

(my filter no longer has the "first frame green" bug)

-Nic

[Koepi]

Yay, your filter rocks again Nic! :)

@all:
A modified binary without filename change is up, I set the block-skip threshold to 1 now again. This code still is "more efficient" since there are some other dropping conditions checked, but not as noticable (in terms of removing details ;) ) as before.

[iago]

So it's time to start the delayed test with the new build (after my current try using a filter chain for the first time is finished :).

iago

[Koepi]

I'm sorry :-/ but if there's something odd and can be fixed, I feel like i have to do it ;)

Best regards,
Koepi

[iago]

@Koepi

Oh, thanks a lot! :) There's nothing odd except my "outdated" filter chain according to what Marc FD said (many thanks to him, btw) in the related avisynth thread :).

So I stopped torturing myself (for the time being) with an ever-crashing filtering/encoding try :), though I keep my eyes on avisynth threads for filtering in cases of much troublesome and uncompressible movies (like Blues Brothers - old version) :). I'll try some other filters discussed over there, but later...

And now, I won't torture your build either with almost-impossible tries :), and I've already started the first pass of a more reasonable and compressible movie: 2001: A Space Odyssey (2hr 22min/25fps/16:9) with 640*288, neutral bicubic, 6.UltraHigh, H.263, lumi masking enabled and with max I-frame distance: 250. :)

Hope to report back the results soon.

Thanks for your interest and support,
iago

[HBK]

Iago, Koepi - I just wondered what settings you guys use for quants. I know Koepi you've said to "Load Defaults" and go with those settings to acheive good quality, but I've been led to believe for 1 CD rips its best to use (2,4 I frame) and (2,8 P frame). Does that sound right ? If so what you you suggest using for 2 CD rips ?

Thanks in advance.

[Koepi]

I suggest for 1 CD:

iframe: 2-6
pframe: 2-16

for 2 CDs:

iframe: 2-5
pframe: 2-16

As usual, the massive amount of different movies makes it impossible to give proper recommendations here. It depends on the movie, on the first pass size, on the bit consumption of action scenes,...

Regards,
Koepi

[HBK]

Thanks for the speedy reply Koepi. I appreciate it :D

[iago]

Well, 1st pass ("2001: A Space Odyssey"/2hr-22min/640*288/neutral bicubic) with the above mentioned parameters gave me a compressibility value of 59.4 in GKnot, (which is good and should be even higher with XviD,) with an initial 0.133 Bits/(Pixel*Frame) value.

Aiming for 641000kb video size, started the second pass with:
6.UltraHigh
Modulated
Lumi masking enabled
Max I-frame: 2-6
Max P-frame: 2-16
AltCC with default parameters (which I had already been using after Koepi's suggestion in one thread and getting good results with)
all the rest (:)) default

I'll post the results and comments when finished.

so long,
iago

[Koepi]

hehehe :)

I appreciate it, iago.

It seems I messed up my system seriously because when I try to encode some DVD stuff I only get _trash_ now.

Well, that's life, after i finally d/l'ed Mandrake 9.0b3 (uh. and this from me. you can't use mandrake before a *.2 release... and my GenToo just works perfectly fine...ok, I can't print as there some scripts _seriously_ f***ed up the system, but else...) and burned it, I'll reinstall my win2ksp3 _again_.

Hopefully this helps that annoying situation.

But I think your encoding can end up fine, iago (to get in-topic again), but I'd like to know the first pass file size, too, so I know the compression ratio between first and second pass (until now I can only give the "rule of thumb" that a 1st pass-to-2nd pass ratio shouldn't be bigger than 2.5:1 as higher than that you will suffer severe image degradatiuon.)

Best regards,
Koepi

[iago]

@Koepi

Sorry if it's stupid question but I'm too lost now to reason properly :). I didn't keep the 1st pass debugview log file (of course I'm keeping the second pass). How can I know/calculate the 1stpass-to-2ndpass ratio?

iago

[Koepi]

send me an email address where you have ~32kb of spare place and I'll send you a first prototype of a stats analyser.

Open the stats file produced during first pass with it, and just write down the "size" number it spits out ;)

regards,
Koepi

[iago]

@Koepi

Just tick on my nick and go to my profile ;). The e-mail address is there.

thanks a lot,
iago

[iago]

@Koepi

OK, received it :).

thanks,
iago

[iago]

@Koepi

Tried it a couple of times, but seems that unfortunately it didn't like "my" system :(.

iago

[iago]

Hi again,

Finally I tried NandubStatsReader-v0.6, which works fine and gives a first pass size of 1054mb. So, aiming for 641000kb (626 mb), 1stpass/2ndpass (1054/626): 1.68 for the above mentioned test rip, which is good (less than 2.5:1), isn't it? ;).

regards,
iago

[Koepi]

That should almost look perfect :)

Regards,
Koepi

[iago]

Hi again,

And yes, the movie came out really good, with the formerly mentioned encoding parameters, and generating the following report:


DebugView analyzer for XviD codec v0.10 by MoonWalker
e-mail : s_ilias@gmx.net

Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 8271 Times, Percentage Used : 4.09%
Quant 3 Used : 160338 Times, Percentage Used : 79.34%
Quant 4 Used : 33252 Times, Percentage Used : 16.45%
Quant 5 Used : 216 Times, Percentage Used : 0.11%
Quant 6 Used : 7 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 3.126

Quantizers Used For Credits :
--------------------------------
Quant 20 Used : 12050 Times.

MPEG Quantization Type Used 180659 timed, Percentage Used : 84.37%

H.263 Quantization Type Used 33475 timed, Percentage Used : 15.63%

Quantizers prevented from rising too steeply 0 times


Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 34 Times, Percentage Used : 2.88%
Quant 3 Used : 1068 Times, Percentage Used : 90.36%
Quant 4 Used : 32 Times, Percentage Used : 2.71%

Credits
---------
Quant 20 Used : 48 Times, Percentage Used : 4.06%

Number Of Consecutive I-Frames : 22

Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 8237 Times, Percentage Used : 3.87%
Quant 3 Used : 159270 Times, Percentage Used : 74.79%
Quant 4 Used : 33220 Times, Percentage Used : 15.60%
Quant 5 Used : 216 Times, Percentage Used : 0.10%
Quant 6 Used : 7 Times, Percentage Used : 0.00%

Credits
---------
Quant 20 Used : 12002 Times, Percentage Used : 5.64%



Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 1182
Number Of Inter-Frames (P-Frames) : 212952
Total Number Of Frames : 214134

0.55% of the Movie is Intra-Frames (Key-Frames)
99.45% of the Movie is Inter-Frames (P-Frames)


Size Analysis
----------------

1-Pass Size : 1104722016 Bytes or 1078830 KBytes
Scaled Size : 651242163 Bytes or 635978 KBytes
Actual Size : 651332342 Bytes or 636066 KBytes

Usefull Statistics
------------------
Compressibility : 58.96%
Relative Quality of XviD avi : 63.98%
Absolute Quality of XviD avi : 96.62%
---------------------------------------------------------------------

And after a long while, it's really nice to have Nic's XviD Decoder filter back :).

so long,
iago

[ookzDVD]

@Koepi,


But I think your encoding can end up fine, iago (to get in-topic again), but I'd like to know the first pass file size, too, so I know the compression ratio between first and second pass (until now I can only give the "rule of thumb" that a 1st pass-to-2nd pass ratio shouldn't be bigger than 2.5:1 as higher than that you will suffer severe image degradatiuon.)


So... in other word :
"The Compressibility is better not below 40%" ??

Thank you.

[Koepi]

EDIT:

was too bad written.

2.5:1 is the same as
1:0.4

which you could describe as

5:2

Compressability 40% is wrong and would be weak. it's 60%.

But i don't know how these numbers, which all mean the same, help if put in another way?

[ookzDVD]

@Koepi,

Sorry for asking that _stupid_ question :(

_but_ imho speaking the compressibility is more common than
1-pass/2-pass ;)

[Marc FD]

just wanted to do some observations :

Originally posted by iago
Hi again,

And yes, the movie came out really good, with the formerly mentioned encoding parameters, and generating the following report:


DebugView analyzer for XviD codec v0.10 by MoonWalker
e-mail : s_ilias@gmx.net

Quantizers Analisis
---------------------

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 8271 Times, Percentage Used : 4.09%
Quant 3 Used : 160338 Times, Percentage Used : 79.34%
Quant 4 Used : 33252 Times, Percentage Used : 16.45%
Quant 5 Used : 216 Times, Percentage Used : 0.11%
Quant 6 Used : 7 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 3.126

seems to me that you don't need to clip the I-frame quants at all, because even with max = 6, you only got 7 quant 6 frames...

Quantizers Used For Credits :
--------------------------------
Quant 20 Used : 12050 Times.

MPEG Quantization Type Used 180659 timed, Percentage Used : 84.37%

H.263 Quantization Type Used 33475 timed, Percentage Used : 15.63%

Quantizers prevented from rising too steeply 0 times


Intra-Frame (Key-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 34 Times, Percentage Used : 2.88%
Quant 3 Used : 1068 Times, Percentage Used : 90.36%
Quant 4 Used : 32 Times, Percentage Used : 2.71%

strange... @Koepi : wouldn't it be better to have more Quant 2 I-frames, even if the following frame receive bigger quants ??
Maybe there is something to tweak/change with the compression curve algo ?

Credits
---------
Quant 20 Used : 48 Times, Percentage Used : 4.06%

Number Of Consecutive I-Frames : 22

Whow !!! 22 I-frames in a row !!! you should seriously take a look at this !! i don't see how I-frames could be better than P/B-frames over more than 20 frames...or maybe some flashing in the dark ?

Inter-Frame (P-Frame) Quantizers
------------------------------------

Movie
-------
Quant 2 Used : 8237 Times, Percentage Used : 3.87%
Quant 3 Used : 159270 Times, Percentage Used : 74.79%
Quant 4 Used : 33220 Times, Percentage Used : 15.60%
Quant 5 Used : 216 Times, Percentage Used : 0.10%
Quant 6 Used : 7 Times, Percentage Used : 0.00%

Credits
---------
Quant 20 Used : 12002 Times, Percentage Used : 5.64%



Frame Analisis
----------------

Number Of Intra-Frames (Key-Frames) : 1182
Number Of Inter-Frames (P-Frames) : 212952
Total Number Of Frames : 214134

0.55% of the Movie is Intra-Frames (Key-Frames)
99.45% of the Movie is Inter-Frames (P-Frames)


Size Analysis
----------------

1-Pass Size : 1104722016 Bytes or 1078830 KBytes
Scaled Size : 651242163 Bytes or 635978 KBytes
Actual Size : 651332342 Bytes or 636066 KBytes

Usefull Statistics
------------------
Compressibility : 58.96%
Relative Quality of XviD avi : 63.98%
Absolute Quality of XviD avi : 96.62%

abs quality = 96.62% !! (with avg quant 3!)
somhow meaningless :
a avg quant of 6 (beurk) would give you 86% (big)
but i know moon like to align stats values (that don't hurt after all ;) )

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

And after a long while, it's really nice to have Nic's XviD Decoder filter back :).

yep :)
How could i find Nic's DShow filter source ??
I'm totally unable to compile M$ DShow s*t, but i would like to see the algos used :)

so long,
iago

[AndyP]

< Whow !!! 22 I-frames in a row !!! you should seriously take a look at this !! i don't see how I-frames could be better than P/B-frames over more than 20 frames...or maybe some flashing in the dark ? >

I might be horribly wrong, but I thought this meant that there were 22 instances in the whole file where 2 or more iframes were in close proximity (I think somewhere defined as two iframes within 10 frames was considered consecutive), not there were 22 consecutive iframes. But as I say, I could be wrong.

Your second point is interesting. Is it better to have more iframes with quant 2 than 3. I usually fix iframes q2-3 and pframes 2-8 but I will encode something tonight with both i2-3 and i2-2 and post results as I have often wondered the same thing.

Kind Regards,
Andy

PS Don't burn me too much if I am wrong. I am still learning.

:)

[canadian_fbi]

Originally posted by AndyP
< Whow !!! 22 I-frames in a row !!! you should seriously take a look at this !! i don't see how I-frames could be better than P/B-frames over more than 20 frames...or maybe some flashing in the dark ? >

I might be horribly wrong, but I thought this meant that there were 22 instances in the whole file where 2 or more iframes were in close proximity (I think somewhere defined as two iframes within 10 frames was considered consecutive), not there were 22 consecutive iframes. But as I say, I could be wrong.
that's what i thought too. that is, that there weren't 22 i-frames all in a row, but 22 times that i-frames were consecutive.

Your second point is interesting. Is it better to have more iframes with quant 2 than 3. I usually fix iframes q2-3 and pframes 2-8 but I will encode something tonight with both i2-3 and i2-2 and post results as I have often wondered the same thing.
well, as far as this particular example was concerned, the avg. quant was over 3, so quant 2 for all i-frames probably would have been too big a jump (i.e. all i-frames are quant 2, but then the quality is destroyed by big quants on p-frames). or perhaps the i-frames were excessively detailed and it needed quant 3 to lighten the impact or something. but this is what the i-frame boost % is for, i thought (if you really want to give your i-frames unconditionally lower quants, simply boost them more).

[iago]

Originally posted by canadian_fbi

the avg. quant was over 3, so quant 2 for all i-frames probably would have been too big a jump (i.e. all i-frames are quant 2, but then the quality is destroyed by big quants on p-frames). or perhaps the i-frames were excessively detailed and it needed quant 3 to lighten the impact or something. but this is what the i-frame boost % is for, i thought (if you really want to give your i-frames unconditionally lower quants, simply boost them more). That's how I understand the issue too: most possibly "not to hurt the p-frames quality too much with excessive use of quant2 i-frames" (after the introduction of consecutive i-frames treatment). I got similar results (eg. "no" i-frames with quant2, but "all" i-frames with quant3-4) with other good compressible (avg. quant ~3) movies as well, supporting this approach.

best regards,
iago

[Marc FD]

for the 22 frames, it's very possible i misunderstood.
dunno what it really means :rolleyes:

Quant 2 or 3 I-frame, it's just a matter of taste.
Do a quant 2 I-frame followed by quant 3 P-frames look better than a quant 3 I-frame followed by quant 2 I-frames ?? i can't tell.

[ookzDVD]

@Koepi,


Compressability 40% is wrong and would be weak. it's 60%.


Thank you for the confirmation.
At least I could understand now that 40% is the lowest limit
which should be avoid and the 60% is the good one.

[Koepi]

I don't work with tools like GKnot, so I don't know what the values it spits out mean.

But compressability usually means the space saved, and not the space something takes up.

regards,
Koepi

[droolian01]

Hi there.

I know this is extending the thread further off topic but i would like some comments on the way i handle 'compressibility'.

Koepi mentions the 1stpass size:2nd pass size ratio - this has to be the gold standard in determining how good an encode is likely to turn out. This doesn't help with determining the correct frame size which is what Gordian Knot comp test is for.
(N.B. never actually used GordianKnot i only encode captures!)

UK tv caps often have differing aspect ratios other than 4:3 (widescreen experiments etc...) and when i first started capping i discovered a useful trick to help decide the right frame resize.

Decide how large the video is going to be (i fit 2x45 min episodes on one 700mb cdr) so in this case usually c. 300mb. Run these numbers in a bitrate calculator to give you an average bitrate (c.955kbit/s with 128 cbr mp3). Now divide your desired framesize X and Y co-ordinates by 16 then multiply these numbers to give you the number of macroblocks. e.g. 512x384 (4:3 ratio) divided by 16 = 32x24 giving 768 macroblocks. I found that artifact free encodes are usually assured when the macroblock number is about 75% of the bitrate (as shown earlier). Its certainly not ment to be a precise science, but i usually scale down my target framesize when these two numbers are roughly the same, and certainly if the macroblock number is bigger than the bitrate number.

If this is totally stupid - be kind - it seemed like a good idea months ago. It does sort of make sense to relate how the bitrate is to be spread over the macroblocks.

Comments appreciated
Thanks.

[droolian01]

Hi Koepi!
Just did an encode of another buffy capture (its being screened daily on sky one) and this build (17082002 modified 2nd one) seems to produce more background 'crawlies' than the previous build (the one with the option to select scene change threshold - I liked setting that at 30 - could we have it back p;ease???).

This increase in background crawlies is very subtle, but i still feel it significant enough to mention.

Thanks for all the brilliant work,
xvid is cool!

[MoonWalker]

About the CC Keyframes..Well this in alpha stage yet, but it actually means how many kay frames are concecutive...ie

I-P-P-I-I-I-I-P-P-P-P-I-I-I
0 0 1 2 3 3 4 5

Like that :)

About the quality values, from readme.txt

NOTE:

About the Absolute/Relative quality :

Relative quality is 200/average quant of the movie(not including the credits).
It's relative cause with quant 31 you don't get 0% quality.

Absolute quality is (average quant of the movie)*(-100/29)+(3100/29).In other words it's how close
you are at quant 2(100% quality is quant 2, 0% is quant 31)

MoonWalker

[ookzDVD]

@Koepi,


I don't work with tools like GKnot, so I don't know what the values it spits out mean.

But compressability usually means the space saved, and not the space something takes up.


Yes, I could understand that.

I think the "compresibility" term which produced by GKnot (and
adopted by DbgView's MoonWalker) is wrong, the more compresibility value... should mean the smaller 2-nd pass size, but with Gknot's term... it should be larger the 2-nd pass size :(

[bob0r]

Hello Anyone have XviD-18082002-1.exe ? Please send it to bin@dircd.com i know the xvid issue, but i really want to test this version, i have been out for a while.

Thanks in advance,
bob

EDIT:
I have the FILE now! (Thank you scott)

/me wishes XVID good luck

[MoonWalker]

Originally posted by ookzDVD
Yes, I could understand that.

I think the "compresibility" term which produced by GKnot (and
adopted by DbgView's MoonWalker) is wrong, the more compresibility value... should mean the smaller 2-nd pass size, but with Gknot's term... it should be larger the 2-nd pass size :(

In my prog the compresibility is calculated by this 2-pass size*100/1-pass size..And it's always smaller than 100%..XviD doesn't allow to have a 2-pass file bigger than the first pass..

MoonWalker