XviD-01082002-1 [Archive]

tomy601k

2nd August 2002, 12:42

I did a test with America's Sweethearts. I set the size to 800 MB since I'm using XCD and I set the audio bitrate to 128 Kbit/s. Hence that the DVD is R2 PAL Which is 10-20% less quality than R1 NTSC DVD's. I choosed 640X272 for the resoultion and used this build of XVID. I didn't change much of the settings, almost the same as Doom9 suggested.

I already got the Vite's ripping for this movie so that I can compare it. Vite set the resolution to 576X256 and they used divx3.11 SBC.

Now, When I finished everything I choosed 3 of my friends for testing. I invited each one alone and showed both movies to them and asked them what they think. They all agreed that XVID version is much better (Note : they don't know about XVID and Divx), and one of them said that he can see more details on the faces and the colors are much brightful in the XVID version.

On overall I think that XVID now officially beat divx (not that it didn't beat divx before :) ) and I can understand why Vite group choosed to rip their movies now using XVID :D

Great Work Koepi, My regards to Foxer also :)

Koepi

2nd August 2002, 13:34

Hehe, thanks for your thumbs up, it's nice to see that you like the latest additions.

Now I only need to get my hands on a matrix and SPR DVD to tweak around with the settings so doom9 can see that, too ;)

Regards,
Koepi

rui

2nd August 2002, 13:40

Originally posted by tomy601k
I ..Hence that the DVD is R2 PAL Which is 10-20% less quality than R1 NTSC DVD's...

Why? because of the fps? (pal - 25; ntsc - 29,97). I thought that the ntsc frame rate was made that way because of the tv system over there, but it didn't meant better quality, sice the original picture was made at 24 fps (see last quote).

I got the following quote here: http://nickyguides.digital-digest.com/interlace.htm

NTSC

The TV industry is dominated by two main standards for TV design: PAL and NTSC. NTSC is one of my pet hates basically because of it's rather low quality and use of weird framerates. NTSC stands for the National Television Systems Committee, it is the colour video standard used in North America, Canada, Mexico and Japan. Some engineers have said it should stand for Never Twice Same Color because no two NTSC pictures look alike :). Due to the electric system used in the US it was decided to scan the lines across the NTSC TV screen at about 60Hz (or 60 half frames per second) which produced 30 whole pictures every second. NTSC resolution is about one sixth less than that of PAL. This may not seem so bad, but divide a sheet of paper into six even parts and chop one off of the bottom and you will have a lot of detail lost. NTSC uses 525 horizontal lines of which only about 487 make up the active picture.

PAL

PAL stands for Phase Alternating Line, it is the TV standard used for Europe, Hong Kong and the Middle East. It was a new standard based on the old NTSC system but designed to correct the NTSC colour problems produced by phase errors in the transmission path. PAL resolution is 625 horizontal lines but only about 540 of these are used for the picture. PAL is higher quality than NTSC, it keeps a sharper picture and remains closer to the original format produced by motion picture cameras. Due to the European electric standards it was decided to interlace PAL lines every other line at 50Hz producing 25 whole frames every second.

Also this:

As I have already mentioned, a motion picture camera captures its images at 24 frames every second. Each frame is a full image. An NTSC television, however, must play 30 frames per second, and these frames must be interlaced into two fields both top and bottom! So basically what we are saying is we must play 60 half frames (or fields) every second. The only way we are going to be able to play a 24 fps motion picture on NTSC television is to change it from 24 fps to 30 fps and interlace these frames into two fields making 60 half frames per second. This transformation process is done with a machine called a Telecine. A Telecine machine does something called pulldown, which, in its simplest explanation, "pulls down" an extra frame every fourth frame to make five whole frames instead of four!

I am not trying to start anything here, just want to know if you are correct or not.

tomy601k

2nd August 2002, 14:16

@rui

I am not trying to start anything here, just want to know if you are correct or not.

Yeah I know what you mean :)

Actually when I said that R1 NTSC DVD's are 10-20% better in quality than R2 PAL DVD's ... I was refering to my personal experience. I ripped many movies from both regions. Sometime the same movie. I noticed that the compressibility of NTSC DVD's are better than PAL in the range of 10-20%. In addition to that I can notice that NTSC DVD's are better quality than PAL DVD's when I watch them on my PC. It is only based on a personal experience and point of view.

By the way do you know what happened to Nicky? His articles and guides used to be one of the best.

rui

2nd August 2002, 14:29

Well, if you say so, i believe you :)

It appears that Nicky got so busy that he ended the updates on his site :(
I too liked his guides a lot. I started in this xvid/divx "thing" there.

But you can have a look here:http://www.lukesvideo.com/
This guy has some very good guides too.

Koepi

2nd August 2002, 14:35

I know a real good site with brilliant guides and all the stuff you need, too:

http://www.doom9.net/

*caugh* if you'd stop advertising for other sites as if "they are better" now it would be very kind.

Regards,
koepi

Marc FD

2nd August 2002, 14:38

NTSC better than PAL ?? when it's not interlaced at least...
on the paper PAL is much better than NTSC.
but if a PAL DVD is masterised from NTSC, you'll off course have less quality. Maybe due to noise too. PAL could have less compressibility because it's too accurate, and gets more noise.
Have you tried to use very soft filtering settings ??

PS : you can't compare quality of 2 different sources encoded with the same settings. Have you tried to compare the DVDs directly ??

But all this is of course theorical and off-topic :D

EDIT : Warning : "Koepi is watching you" ;)

rui

2nd August 2002, 14:49

Originally posted by Koepi
I know a real good site with brilliant guides and all the stuff you need, too:

http://www.doom9.net/

*caugh* if you'd stop advertising for other sites as if "they are better" now it would be very kind.

Regards,
koepi

Sorry. :(

I will strike myself from the forum for one entire day, as punishment.

Koepi

2nd August 2002, 15:30

Hu? that wasn't my intention. It's just so that doom9 has many good guides ;)

Stay here, enjoy hangin' around! (I just did mention that linking to two different sites and stating they're sooo good might not be the best thing to do ;) )

Regards,
Koepi

Razor04

2nd August 2002, 17:41

Great to see a new feature added. I will have to test this some later after work. I think that it would be cool though if you could activate Greyscale on the credits only like LoKi128 mentioned. I don't know if this would benefit them at all, but it can't make them worse.

spyder

2nd August 2002, 18:00

The guides on Lukes' Video are much more capture related anyway so you really weren't in the wrong IMHO.

bob0r

2nd August 2002, 18:32

Nice work Koepi ur added in http://base2091.com Multi Media Essentials

This install is for:
3ivx 3.5 (quicktime & media player)
AC3
DivX 3.11 Alpha
DivX 4.12
DivX 5.02 PRO
MP3 (320kbps) (+lame)
MP3 PRO
MPEG 4 v1 v2 v3
QuickTime 6.0
Sigma Designs MPEG-4
SmR
SVCD
Windows Media 8
XviD

-NEW Base 2091 codec pack v4.1:

XViD 01 augustus 2002 added

Base 2091 codec pack v4.0:

XViD 27 july 2002 added

.bs2 = rar

great work!

grug2k

3rd August 2002, 06:00

Originally posted by tomy601k
In addition to that I can notice that NTSC DVD's are better quality than PAL DVD's when I watch them on my PC. It is only based on a personal experience and point of view.

Agreed, it all depends on your point of view, but I fail to see how you can find a PAL DVD with 20% more resolution than an NTSC DVD to look worse.

soulfx

3rd August 2002, 06:18

DOH! :p

I just finished an encoding and then noticed the 01082002-1 build. Oh well, I've got plenty more encodes to do, just wanted to say nice work and all on everything.

Also, I second the idea of using greyscale mode in credit encoding (possibly the best way to cut down on credits would be to OCR them and then just have a blank video, soundtrack, and subs *but thats another thread)

--Edit: Well I was thinking... (this can be trouble sometimes) what's the difference between enabling greyscale mode in XviD and turning the Saturation down before it even hits XviD. Would there be a difference between the two methods of greyscaling a video? Possibly using the saturation adjustment one could set a trim value on the credits an AVS script and sat=0.0. I could run some tests I guess :)

Peace,
SoulFX

Koepi

3rd August 2002, 06:34

Uh, and there we go:

XviD-03082002-1:
- Speed optimized
- New curve treatment, finally in CVS (doesn't work with bframe packed bitstream!).
- New greyscale mode - good for unclean b/w content (also commited to CVS)

EDIT: this build uses PMVfast as I wanted to check if there really are those errors which EPZS should have. BUT: PMVfast is inferiour, it tends to produce "blocky" output very early, EPZS is way better in this arena.

I'll upload a new build soon.

Mates, you're all over-estimating b/w mode as it just cuts off 5-10% of bitrate. I'll try to hack that in later, but it sounds like you're expecting wonders which this code _can't_ fullfill! XviD is extreme advance compression technology, the drop in bitrate used isn't that remarkable.

Best regards,
Koepi

manono

3rd August 2002, 08:19

Hi-

...but I fail to see how you can find a PAL DVD with 20% more resolution than an NTSC DVD to look worse.

I don't understand. Where's the 20% more resolution come from? Do you mean the 25fps vs the 30fps? But that's not correct, as NTSC movies are stored on the DVD at 24fps.

DeXT

3rd August 2002, 10:39

PAL DVD resolution: 720x576
NTSC DVD resolution: 720x480

It seems to me that PAL has a 20% higher resolution isn't it? ;)

soulfx

3rd August 2002, 11:23

Sometime the same movie.
PAL and NTSC are not released under the same transfer process. Each can undergo a different low-pass, EE, and other "enhancements". As it seems sometimes NTSC films get released later then PAL (which can be very anoying *cough* Futurama S01 *cough*) it might be NTSC gets more processing and attention then PAL (the "first realease").

I noticed that the compressibility of NTSC DVD's are better than PAL in the range of 10-20%.
This might have to do with PAL's higher resolution (PAL's have about 10-20% more info, thus will not compress as easily as NTSC). Also could attribute to different transfer processing.

In addition to that I can notice that NTSC DVD's are better quality than PAL DVD's when I watch them on my PC.
The EE used in the transfer process might differ between PAL and NTSC. This will result in a higher precieved quality.

What we have here is a comparison between "quality" (lol, Zen and the Art of ... err, never mind) and hard mathmatical data.

PAL resolution > NTSC = true
PAL quality (aka perceived detail) > NTSC = maybe, maybe not (transfer process, EE)
PAL compressibilty > NTSC = no (more data is harder to compress)

wow, man...
XviD-01082002-1 <-- original topic

Peace,
SoulFX

tomy601k

3rd August 2002, 14:32

Originally posted by soulfx
wow, man...
XviD-01082002-1 <-- original topic

I agree :) . If I know that my statement would cause all that argument then I wouldn't say it in the first place (becausse it is not the right place to discuss such things ... Look at the topic ;) ).

Besides if you look at what I said

Originally posted by tomy601k

Actually when I said that R1 NTSC DVD's are 10-20% better
in quality than R2 PAL DVD's ... I was refering to my personal experience.

You can see that it is my point of view, I've ripped many DVD's from both Regions and I think that it not easy to have both DVD Regions in your hand to make such judgement (We have R2 DVD's here, but I'm a regular buyer for DVD's from e-bay and all the DVD's I bought are R1 DVD's). Most of guys who replied about this are talking theoritacally ... and they are right ... PAL DVD's suppose to be higher in qaulity than NTSC DVD's, but in reality it is different. Again it is just my point of view depending on my personal experience ... You can take it or you can leave it. It is up to you :)

Now let us end this discussion and let Koepi continue his marvelous work. The great thing about XVID now is that you don't need any magic formula to make high quality rips like it was before when you needed to tweak the codec for optimum quality.

Regards to everyone,
Tomy.

spyder

3rd August 2002, 17:56

I have encountered a really big problem in this build. Either that or I have lost my mind one. Both are possible. Anyway, I enocded this movie(1hr 17min) with MPEG quantizers and Alt. CC switched off with a desired size of 1348608 kbytes. The file has come out WAY undersized and I don't mean a few hundred MBs even, I mean REALLY undersized. The outout file is only 311MB. I am re running this to make sure I didn't accidentally select Modulated Quants on the first pass for some reason. If anyone else has seen this, you could save me a lot of time by posting here.

Koepi

3rd August 2002, 18:34

It is a known problem that occurs when second pass size is bigger choosen than first pass size.

Regards,
Koepi

spyder

3rd August 2002, 19:56

No i don't think this is the problem. The output file is only 311MB and this is a noisy file. There is no way it is that comperssible. If so, I would just make a 1CD rip as I can fit the AC3 with 311MB on a 700MB CD.

Koepi

3rd August 2002, 20:37

Did you choose to make your second pass bigger as the first pass?

I'm quite sure you did, this is the only thing where this happens.

Koepi

3rd August 2002, 20:50

XviD-03082002-2:
- EPZS motion search reactivated.
- "first frame green bug" is fixed.

spyder

3rd August 2002, 20:53

Koepi,

The first pass stats file is reported in GKnot to use 0.429 bits per pixel. The projected output size is 0.404 bits per pixel. This means that the second pass will have to be at least 0.404 bits per pixel and slightly smaller than the first pass. I have never seen a movie which was 1hr and 17 minutes and able to be fully compressed at 300MB with the highest quality. This is indeed a strange case. I ran the second pass again with your new CC enabled and it appears to be working fine. I will try without the first pass again without discarding the video and see what it's size is. I have done this before in which cases the encoder just produced a file equivalent to the first pass file, not smaller.

spyder

3rd August 2002, 21:03

OK, now I understand what you are saying. Must be a new thing this undersizing as I have relied on it before to reproduce the 1st pass file if it couldn't reach the desired size. I'm running it now keeping the first pass. No reason it should be only 311MB.

spyder

4th August 2002, 00:35

I tried this again without discarding the first pass and the resulting file was 1.33GB. After seeing this, I lowered the size for the second pass to ~1150MB(problems in my original calculations, I really didn't need the file as big as I was trying for. Be quiet Acaila). It too comes out very small. I'm on to you Koepi. I know about your little conspiracy. Who do you think you are trying to force me to make 1CD rips?? LOL, just kidding.

In the meantime: i have switched to Acaila's Fabulously Great builds which Koepi hasn't touched. :) I don't know where the bug is, or if there is a bug but I will wait for a new release.

Koepi

4th August 2002, 00:42

Maybe you should try alt. curve compression, if i read correctly you used the "old" version of CC code.

This happens very seldom and I duno where it comes from, you should ask foxer, I think he had some ideas.

Acaila has builds too? Wow, didn't know that.

spyder

4th August 2002, 00:51

I tried both CCs and still get the problem. I am using Acaila's Fabulously Great build now.

MaTTeR

4th August 2002, 00:58

Acaila's builds now have the older lumi code which helped compressiblity.

gldblade

4th August 2002, 05:06

Maybe I'm missing something, but where are Acaila's builds?

Acaila

4th August 2002, 09:23

It's nothing fancy really. I just wanted the new CC code with the old Lumi Masking code together, since the new Lumi Masking doesn't help compressibility one bit (I had been using Koepi's 22-05 build for a long time because that was the last one with the old code, but I was getting behind on features).
I'm just starting out with learning how to compile, and I haven't got any webspace to store it on.

I'll attach the dll here so if anyone is interested they can try it out.

- CVS version 03-08-02
- EPZS and EPZS^2 ME enabled
- Old Lumi Masking code thrown in
- Added a nice properties page ;)
- NOT ICL optimized or anything, if you want that get Koepi's ;)

Ps. This was originally intended as a private project, so please don't kill me for it :D

Marc FD

4th August 2002, 11:05

But the new lumi algo gives better quality, no ??
(i don't see why the old one would be better than the new...weird)

Acaila

4th August 2002, 11:15

Maybe, but I've never seen any difference between the two codes in quality. Except that the old increases compression and the new does not, which is why I prefer the old.

Marc FD

4th August 2002, 11:42

have you tested on a TV ??

Acaila

4th August 2002, 12:23

No, and I don't need to because I only watch on my monitor anyway. I don't care how it looks on TV.
It did mention I started this for my own preferences, if you don't want it, don't use it.

Marc FD

4th August 2002, 12:52

I don't know which algo is better, if you say the old one gives good results, i trust you (i don't have time to test myself...)
I think we should ask to the creator of the new algo what's the improvements. He should be lurking on XviD.org

MoonWalker

4th August 2002, 13:03

Well if you want some info about the new lumi masking you can read this http://forum.doom9.org/showthread.php?s=&threadid=28129 Has some usefull info..

EDIT : Just downloaded the XviD-03082002-2.exe and it seems that the "Broken GUI" isn't fixed(I thougth it was, maybe I was wrong :) )

MoonWalker

Koepi

4th August 2002, 13:26

I didn't fix the boxes again (they're "broken" in CVS) because I wanted that binary to get out as fast as possible. Who cares anyways?

MaTTeR

4th August 2002, 13:36

Since I only view my rips on a analog TV then I can testify that I see no visual difference between Acaila's build with the old Lumi and a recent build with the new Lumi code. I've ripped about 4 moves in the last 3 days with Acaila's build...Jade, Clockwork Orange, Dont Say A Word and X-Men. A good portion of these movies were somewhat dark, depending on the movie the old Lumi code gave me an extra 5-9% compression in the end. So since I see no visual difference with my eyes, I'll stick with the better compressibility for now:)

Koepi

4th August 2002, 13:49

I don't remember who added the new lumi code, but it has to be tweaked, the hardcoded values don't do much. I think it's mentioned in the thread linked above.

Regards,
Koepi

Nic

4th August 2002, 15:01

(yay...chemn did the green bug fix) :D

-Nic

Koepi

4th August 2002, 15:02

const float DarkThres = 0.25;
const float DarkAmpl = 7.0;

const float BrightThres = 4.0;
const float BrightAmpl = 5.0;

const char LowestVal = 10;

const float GlobalBrightThres = 220.0;
const float GlobalDarkThres = 20.0;
float global_quant = 1.0;

If someone has some better values which I should hardcode (and please, not too strong, it should not produce artefats), I would gladly set them for the next build.

Any ideas?

Regards,
Koepi

Koepi

4th August 2002, 15:07

Hehe, yeah, that's nice :)

Btw., welcome back Nic!

Regards,
Koepi

MaTTeR

4th August 2002, 15:12

@Koepi

Might it be possible to have a few fields to allow the user to tweak the values? It sounds cool but I'm not a coder so I don't know what would be involved for such a beast. Just a thought.

Koepi

4th August 2002, 15:15

Matter,

this would make a change of the XviD API necessary which the core developers really, really badly dislike.

So either you come up with better values or you have to use acaila's xvid builds. ;)

Regards,
Koepi

Acaila

4th August 2002, 15:31

Well, unless someone knows what all those variables do, all we users can give you is a guess. And that wouldn't be very helpful. Is there no way we can tweak those values (temporary vfw interface?) without each new value requiring a new build?
My solution was only meant to be temporary anyway.

Koepi

4th August 2002, 15:37

I sent out an email if some developers already have found better values or if they agree on an API change.

Regards,
Koepi

MoonWalker

4th August 2002, 18:47

I saw that the values have changed now...

const float DarkAmpl = 14 / 2;
const float BrightAmpl = 10 / 2;
const float DarkThres = 70;
const float BrightThres = 200;

const float GlobalDarkThres = 60;
const float GlobalBrightThres = 170;

const float MidRangeThres = 20;
const float UpperLimit = 200;
const float LowerLimit = 25;

But I can't compile it to know if they are better :(, so I am waiting for a build :)...

MoonWalker

Koepi

4th August 2002, 19:07

Well, that's the old luma masking code.

The new one seems to really f*** up in some situations (maybe those in SPR?), so I'd say just wait a little... There is some action amongst the xvids devels going on, let's see what happens.

Regards,
Koepi

Koepi

4th August 2002, 19:36

XviD-04082002-1:
- EPZS motion search reactivated.
- Old luma masking code is back, new one was buggy.

Let's see if this helps it.

soulfx

4th August 2002, 20:05

There shoudn't be any problems arising becuase of enabling luma masking in both passes, right? I remember this got fixed, as that is why in first pass mode luma isn't greyed out anymore.

BTW, to test my encodes I use my laptop since it's screen (as is the nature of LCD) provides a better way to see any blocking or artifacts.

And as a side note: I've got SPR sitting right here next to me, if anyone want's me to run some tests or something.

MoonWalker

4th August 2002, 20:11

:rolleyes: I haven't seen how the old lumi was, so I supposed it was the new one :)...

@Koepi
And a request for a simple hint :)

How to you activate the EPZS and/or EPZS^2 code??The current configuration is

/nologo /ML /W3 /GX /O2 /Ob2 /D "NDEBUG" /D "ARCH_X86" /D "WIN32" /D "_MBCS" /D "_LIB" /Fp"Release/core.pch" /YX /Fo"Release/" /Fd"Release/" /FD /c

I suppose you add a /D switch...

Thanks in advance,
MoonWalker

Koepi

4th August 2002, 20:14

Yes please, try "load defaults" with this new build, enable luma, search precision 6, the stats file, and maybe even MVH. Use h263 for first pass please.

For second pass choose doom9's size, using modulated quantizer, maybe raise alt curve high/low to 500(!). Limit iframe-quantizers between 2 and 6 and pframe quantizers between 2 and 31 (or 16, it's up to you here ;) ).

The credits should be 15% (dunno the credits range though).

Thanks for offering! I'd be glad to hear if in the first scenes in the second pass the quantizer still gets aroun 8-12 or even higher...

Best regards,
Koepi
Regards,
Koepi

Psyche

4th August 2002, 20:21

In which way was the new lumi-masking buggy? I have not seen a word about it in xvid.org forums (at least I don't remember) and Isibaar only states in CVS "back to the old lumi-masking". In fact, I thought the new algos for adaptive quant were better than the old ones.
Do you know the reason for that change, Koepi?

EDIT: disabled signature, showed up wrong here and made the post unreadable.

Koepi

4th August 2002, 20:34

Originally posted by MoonWalker
How to you activate the EPZS and/or EPZS^2 code??The current

It's not that easy.

Since it is experimental code, you have to define it in the core (motion.h, comment out PMVfast and remove comments from EPSZ), in VFW you have to add some line to codc.c (you need in frame.general an additional XVID_ME_EPZS and for the search you must add PMV_USESQUARES16 to the search precision flags for 6-ultra high.

Marc FD

4th August 2002, 22:00

@Koepi

I think making 2 builds :
- XviD Basic with some default settings choice, no SMP, no Bframes, no Qpel, no Alt-CC = nothing experimental, BUT a little bit pre-processing (it's easy to trick newbies, see the interest for RV9, the more filtering-user encoder in the world, or DivX 5, who blurs data to avoid blocking ...)
-XviD Pro (without any ad-ware !!) with all settings, lumi-masking setings, optionnal Bframes/SMP/Qpel support and tweakable pre-processing

Is getting somehow the best solution, no ?

BTW for me you can't get the best of XviD without filtering because it's an "honest" codec who will not blurs-them-all, and try to keep the a result close to the original (original noise i mean -sic-).
It's why i'm trying to improve filtering (as an avisynth filter coder)
I think XviD is far better than some codecs (---- 5 --9) when used with the right filter-chain (i mean HQ filter-chain, not something who wash out the video)

PS : What's making me the more laughing are the comments of doom9 on RV9 :
"the picture just seemed the most visually appealing to the eye"
yep, you got it, that's what filtering is designed for :)

EDIT : Okay now i've censored myself :) . I'm back to normal ;)

Koepi

4th August 2002, 22:30

Marc,

hm, maybe you want to edit that post.

Doom9 tried to help where he could without biasing the results. If there is broken luma code in CVS, he can't do anything against it (and I was in the believe that this code really works "better" whilst it works _different_. I.e. look at SPR, it totally fucked up there. I.e. matrix - it did quantise some things away without really gaining bitrate, I'm redoing matrix now and it seems to be better the old way.)
Btw., SPR in that resolution really needs luma masking to somehow still look ok, it's a classical 3 or even 4 CD movie...

Psyche,

the "new" code was working wrong in that way that it simply quantised away when e.g. a bright area had small dark spots or a dark area has "light spots". Isibaar has a nice example, a car where you can see the lights in the night. The only detail attracting your eyes are these lights, and those now get heavily quantised, resulting in a bad quality. The "old" code is a little more sophisticated and takes care of such situations (to speak a little untechnically), it just quantises higher in a overall "medium brightness" range.
Still, the old code gives a real impact in bitrate usage without sacrifycing too much quality, whilst the "new" code was quantising heavily obviously without giving a noticable bitrate gain.
EDIT: so much for the theory, I'm finishing my matrix-test tonight qt ~4a.m. and then we'll see...

Regards,
Koepi

Psyche

4th August 2002, 22:35

OK, thanks for the explanation, I guess it's been talked about in IRC, isn't it?

BTW, I've removed my signature now, I've had enough of "it shows bad". But I'm not blaming you. It's mozilla's fault, not mine.
BTW2, my signature was a DeCSS written in perl.

MaTTeR

4th August 2002, 22:44

I thought it was agreed upon by a few regular posters here awhile back that lumi wasn't the best option for a 2CD(1400MB) rip. Am I wrong?

Marc,

Calm down man. You made some valid points though about how honest the codec really is :-) Clearly the people in this forum knows what sort of results Xvid can provide compared to the "others". I had no idea the lumi code was broken in that build from the 27th, I used that build several times without issue until switching to Acaila's. Disappointing but who really cares in the end...always other comparisons down the road.

Koepi

4th August 2002, 22:46

Matter,

for SPR it is necessary to enable luma masking to put it on a 2CD, I often read that in the past. It's simply too demanding.

Regards,
koepi

Bartjess

5th August 2002, 00:33

it rox

ookzDVD

5th August 2002, 07:58

@Koepi,

I think your latest build (04-08-2002) have GUI bug,
the Alt.CC tab and Credits tab.

Thank you.

BiaTch 5.0

5th August 2002, 09:17

Originally posted by soulfx
There shoudn't be any problems arising becuase of enabling luma masking in both passes, right? I remember this got fixed, as that is why in first pass mode luma isn't greyed out anymore.

BTW, to test my encodes I use my laptop since it's screen (as is the nature of LCD) provides a better way to see any blocking or artifacts.

And as a side note: I've got SPR sitting right here next to me, if anyone want's me to run some tests or something.

I'm a newbie but IMO use it in the second pass only I encoded From Hell XviD-27072002-1 & I got some pinky background frames with lumi both passes.

rui

5th August 2002, 09:22

WHO!

A guy spends a few days away from the forum, and when he returns, all the "encoding world" is turned upside down. :D

We have new builds, with new (old) lumi, new speed improvements, new codec comparison tests, etc., etc. :p

It's good to have you back Nic. I hope that my fellow countrie men, and women, have treated you well. :)

rui

5th August 2002, 12:01

Originally posted by BiaTch 5.0

I'm a newbie but IMO use it in the second pass only I encoded From Hell XviD-27072002-1 & I got some pinky background frames with lumi both passes.

Well, i made 3 small tests using the latest koepi's build, all with default parameters except for motion search precision 6 and HME.
The 1st using no lumi at all, the 2nd using lumi in 2nd pass only, and the 3rd using lumi in both 1st and 2nd pass.

I must say that the one using lumi on both passes was better than the one using lumi in the 2nd pass only.
Of course that BiaTch 5.0 opinion is a valid one, i just wanted to express the results i got.

I have made some movie encodings using lumi in both passes and didn't got any problems till today. But i also have to admit that test with no lumi was the best looking.

After having read the codecs test made by doom9, i was a bit surprised, because i didn't experienced any problems with the new lumi code. I didn't test for compression gains, but i didn't got the problems he mentions in the comparison, either.

But i didn't encode SPR, maybe that movie in particulary is problematic :confused:

soulfx

5th August 2002, 12:28

I've got this thing running through a SPR encode right now. I'll test it on my laptop and look for anything unusual.

SPR is a really hard movie to compress. I've ran Jonny's compression check... first with your run of the mill 640'ish resolution; result 36.47%. Then set the resolution a bit lower and had it at 45.63%. Those are some low hitting results for something going for a 2 cd backup (it seems SPR may be more suitable for a 3 CD backup), but with 2 CD's one can sure see how a Codec does under some heavy situations.

I've setup two encodes, one with luma mask only in the second pass and the other with luma mask in both passes. Um, yeah, it's going to be a while.

Koepi

5th August 2002, 13:29

Please use luma masking (if you use it) in boith passes. The curve compression works better and this helps getting better results (in terms of "constant quality", if you just use it on 2nd pass, you'll have somwhere unpredictable bits over, which get used _later_ instead in the scene where you could use them).

Regards,
Koepi

Koepi

5th August 2002, 19:45

Changelog:

XviD-05082002-1:
- Separated greyscale for main movie and credits.

Well, and some other changes... gruel was so nice to include them into CVS very fast.

Another point, I switched back to PMVfast for testing as I think I saw something whcih _could_ be produced by an incorrect implementation of EPZS, it is somewhat "shifting the wrong details through the picture", resulting in a "line" where it doesn't belong.
But since I can't know for sure I'm redoing the encoding now with the PMVfast code and hope to see a difference.

So far a small status report from my side ;)

Best regards,
Koepi

int 21h

5th August 2002, 23:20

Currently I achieve better quality with the 6-28 build available on Nic's page than any of the recent builds.. but I'm sure it will be sorted out soon.

soulfx

6th August 2002, 01:45

Allright, well the SPR encode has finished.

XviD-04082002-1 was used to encode and luma masking was set in both passes. Motion Search was 6, Modulated Quants were used, I-frame Min/Max 2/6, P-frame Min/Max 2/16, Alt CC used at Default Medium settings. Credits were trimed. Target size used was: 1519618 (2x800MB XCD). Resolution output was 512x288. Cropped 3 off left and right. SimpleResize2 Algo.

I know these settings differ from Doom9's, but I wanted to get one done using the settings I would use.

I made a bunch of framegrabs at the same spots Doom9 did his (or as close as I could get it) that you can check out below:
http://members.cox.net/soul.fxpro/sprtest/clip1.jpg
http://members.cox.net/soul.fxpro/sprtest/clip2.jpg
http://members.cox.net/soul.fxpro/sprtest/clip3.jpg
http://members.cox.net/soul.fxpro/sprtest/clip4.jpg
http://members.cox.net/soul.fxpro/sprtest/clip5.jpg
http://members.cox.net/soul.fxpro/sprtest/clip6.jpg
http://members.cox.net/soul.fxpro/sprtest/clip7.jpg
http://members.cox.net/soul.fxpro/sprtest/clip8.jpg

I also put together a sampleclip from all the locations used in the framegrabs.
http://members.cox.net/soul.fxpro/sprtest/sampleclips.avi

I am sorry to report, but in my hurry out the door after setting the encode to start I must have closed out Dbgview. :( So I don't have a report to generate.

It would have been nice to see what kind of output Doom9 was getting (even though it was crappy) from his SPR encode. That way we could all know how bad it actually was.

Peace,
SoulFX

Koepi

6th August 2002, 01:57

Thank you very much for you efforts, SoulFX :) I really appreciate it!

Well, with these settings it seems to be watchable if the screenshots are representative IMHO.

Best regards,
Koepi

yokem55

6th August 2002, 02:52

The difference though is that Doom9 encoded SPR at 640x352....a much higher resolution. Your test may not be representative of what Doom9 got from his encode...also watching the video, I wasn't that impressed that with 200mb extra space and 20% less resolution it would look better than it did....very fuzzy and blurry, but this is likely due to the reduced resolution and the simple resize filter (which isn't known for quality).

cult

6th August 2002, 03:06

doom9 says he used BicubicResize(640,352,0,0.5) for spr and targeted for 1400mb.
Your settings were simple resize 512x288 and aimed for 2x800cds
A little bit unfair for the other codecs.Dont know how much it affects the results but I am sure that it does.
Anyway,imho r9 is even more blurry than divx5.I wouldnt use it for any serious ripping(i dont rip anime).I mean,come on guys,look at the screenshots,there is no detail at all.If u like to watch such a movie well be mu guest.My choise-xvid.I use it for the 1st time to encode a "from here to eternity".A nasty 4:3 b&w movie full of noise.Divx4 couldnt make with it but xvid(a late february build),made a perfect encoding.I use it since then.
Xvid is the king of the hills.It rox
A big thank to all the guys out there for your great work.

BiaTch 5.0

6th August 2002, 08:46

Using; 04082002-1 I got some grey blocks in credits the movies where; The Hole, & Cobra(both Pal/interlaced/field resize), using; quant 31.

rui

6th August 2002, 08:46

Well, at least from my point of view, the night scenes aren't that bad. Yes, you used a low resolution, but maybe the new (old) lumi code is making the diference. Like i said earlier, i never had problems with the old (new) code,(man, this is getting confusing :D), but i never encoded SPR.

I think that soulfx deserves the a big thanks from all of us for his hard work :)

At least he made the test, not like me who only do "small" tests (working in a p2-350 can be a trouble). ;)

Koepi

6th August 2002, 08:54

Originally posted by BiaTch 5.0
Using; 04082002-1 I got some grey blocks in credits the movies where; The Hole, & Cobra(both Pal/interlaced/field resize), using; quant 31.

You sure just forgot that quantizers >20 are a little buggy, right?

Regards,
Koepi

rui

6th August 2002, 09:15

Originally posted by Koepi
Changelog:

XviD-05082002-1:
- Separated greyscale for main movie and credits.

Great!

Originally posted by Koepi

Another point, I switched back to PMVfast for testing as I think I saw something whcih _could_ be produced by an incorrect implementation of EPZS, it is somewhat "shifting the wrong details through the picture", resulting in a "line" where it doesn't belong.
But since I can't know for sure I'm redoing the encoding now with the PMVfast code and hope to see a difference.

Well, i hope that you find out that EPZS didn't have anything to do with it, because it would be a shame. :(
I really noticed a diference in details when making a encode using uManiac's builds (PMVfast) and your/Nic's builds (EPZS).

Koepi

6th August 2002, 09:47

Well, I fell over a bug which can't be cleared up easily (EPZS isn't approved to work with adaptive quant.[luma masking] etc), so for now I'll stay with PMVfast, the impact isn't _that_ huge. I redid my encodings and they look fine (and bugfree ;) ).

Regards,
Koepi

iago

6th August 2002, 10:20

@Koepi

I'm about to start a test encode with the 05082002-1 build. Should I use the default values for Max I-frame/Min I-frame intervals (300/1) in the first and the second pass?
(Otherwise, I'm considering to change them to 240/4)

Other values will be (as you suggested):
UltraHigh/H.263/LumiMasking enabled for the first pass.
UltraHigh/Modulated/LumiMasking enabled/Min-Max I-frame:2-6/Min-Max P-frame:2-16/AltCC:default and all the rest with default values for the second pass.

Movie: Fight Club (2:19 hr)
Resolution/Resize: 576*240/Bilinear
VideoSize: 614000 kb

Thanks in advance and best regards,
iago

ookzDVD

6th August 2002, 10:20

@rui

I really noticed a diference in details when making a encode using uManiac's builds (PMVfast) and your/Nic's builds (EPZS).

so... which one is more details ?

@Koepi
Thank you for the test ;)
so... starting the latest build (05-08-2002),
you will use the PMVFast until EPZS bug fixed ?

Thank you.

Koepi

6th August 2002, 10:23

Originally posted by iago
@Koepi

I'm about to start a test encode with the 05082002-1 build. Should I use the default values for Max I-frame/Min I-frame intervals (300/1) in the first and the second pass?
(Otherwise, I'm considering to change them to 240/4)

Please, leave them as-is. The new code is handling consecutive keyframes very gracefully.

Other values will be (as you suggested):
UltraHigh/H.263/LumiMasking enabled for the first pass.
UltraHigh/Modulated/LumiMasking enabled/Min-Max I-frame:2-6/Min-Max P-frame:2-16/AltCC:default and all the rest with default values for the second pass.

Movie: Fight Club (2:19 hr)
Resolution/Resize: 576*240/Bilinear
VideoSize: 614000 kb

Thanks in advance and best regards,
iago

Settings look good, but fightclub is a very compressable movie.
I'd suggest you use simple resize or neutral bicubic, heading for 640x272. Let XviD do it's magic :)

Regards,
Koepi

Koepi

6th August 2002, 10:27

Originally posted by ookzDVD
@rui

so... which one is more details ?

EPZS should deliver more details of course. But in the moment the risk for getting some broken images is high. So it should be better and more safe to use PMVfast.
I think about adding another search option for search precision 6, but i need approval first (and I just do it if i get approval that it may help something).

@Koepi
Thank you for the test ;)
so... starting this momemt, you will use the PMVFast for your build
until EPZS bug fixed ?
Thank you.

Well, kind of. There's some new ME in the queue again, so I'd say let's stay with safe code for now and switch over later (even at run time selectable possibly).

Regards,
Koepi

iago

6th August 2002, 10:30

@Koepi

Absolutely! Tweaking the settings to 640*272 and neutral bicubic immediately... :) (so that Xvid can do its magic :))

Thanks a lot for the immediate reply regarding Min-Max I-frame intervals,

iago

Gannjunior

6th August 2002, 11:39

Originally posted by Koepi

EPZS should deliver more details of course. But in the moment the risk for getting some broken images is high. So it should be better and more safe to use PMVfast.
I think about adding another search option for search precision 6, but i need approval first (and I just do it if i get approval that it may help something...

Could you explain me the mean of EPZS and PMVfast,please?
Checking "enable greyscale" what do I obtain?i have to use it in 1st and 2nd pass?
I'm going to encode Platoon. Which could be the best settings for alt curve? 500-90?if you have some experimental settings that you like to test and that could be ok for Platoon, i'm happy to test them.After I could post results with debugview.

thx

ciao :D

iago

6th August 2002, 16:16

@Koepi and everybody,

Koepi's 05082002-1 build - Test Encode:

Fight Club (2:19)
640*272
Simple Resize
Aimed Video Size: 623800 kb

First pass is finished with a Gnot quality/compressibility value of 56.4 and the Bits/(Pixel*Frame) value was 0.147, both of which are very critical imho. So we really need Xvid do its magic :).

When the second pass is finished (and after I watch the most likely-to-be-problematic parts of the movie) I'll post the results in detail.

So long,
iago

Koepi

6th August 2002, 16:42

Thx iago,

you will be surprised. GKnot's defaults are clearly "too high" for XviD, that's what I saw sometimes here with some encodes the people made.

But wait until I can verify my actual build to work correctly.
Should be another quality gain...

You'd need another 2pass then ;)

But I'm confident that it works out nicely now already.

Best regards,
Koepi

Mechannibal

6th August 2002, 18:33

Originally posted by Koepi
Well, I fell over a bug which can't be cleared up easily (EPZS isn't approved to work with adaptive quant.[luma masking] etc), so for now I'll stay with PMVfast, the impact isn't _that_ huge. I redid my encodings and they look fine (and bugfree ;) ).

Regards,
Koepi

EPZS isnt approved to work with "adaptive quant.[luma masking] etc)", but would previous builds that had EPZS enabled work fine if I did not use lumi masking or other adaptive quant.?

Originally posted by Koepi
EPZS should deliver more details of course. But in the moment the risk for getting some broken images is high. So it should be better and more safe to use PMVfast.

In your tests were the broken images because you used lumi masking with EPZS?

Also, what are the other types of adaptive quant.?

Thanks, I am trying to determine if some of my recent encodes (07272002) are ok.

Mechannibal

Gannjunior

6th August 2002, 19:19

@Koepi
have you seen my post?(before Iago)
thx
ciao

iago

6th August 2002, 20:24

@Koepi and everybody

Koepi's 05082002-1 build Test Results:

Movie: Fight Club (2:19 hr)
Resolution: 640*272
Resize: Simple Resize
Aimed Video Size: 623800 kb

First Pass setup:

6.UltraHigh
H.263
Max I-frame interval: 300 (default)
Min I-frame interval: 1 (default)
Lumi masking enabled
No Hinted ME

Second Pass setup:

6.UltraHigh
Modulated
Max I-frame interval: 300 (default)
Min I-frame interval: 1 (default)
Lumi masking enabled
No Hinted ME
Min-Max I-frame quant: 2-6
Min-Max P-frame quant: 2-16
AltCC with default parameters
All the rest with default values

-------------------------------------------------------
Results:
-------------------------------------------------------

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

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

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 2429 Times, Percentage Used : 1.24%
Quant 3 Used : 125567 Times, Percentage Used : 64.06%
Quant 4 Used : 66422 Times, Percentage Used : 33.89%
Quant 5 Used : 1584 Times, Percentage Used : 0.81%
Quant 6 Used : 13 Times, Percentage Used : 0.01%

Average Quantizer Used for Movie : 3.343

Quantizers Used For Credits :
--------------------------------
Quant 31 Used : 4187 Times.

MPEG Quantization Type Used 132183 timed, Percentage Used : 66.02%

H.263 Quantization Type Used 68019 timed, Percentage Used : 33.98%

Quantizers prevented from rising too steeply 0 times

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

Movie
-------
Quant 2 Used : 4 Times, Percentage Used : 0.16%
Quant 3 Used : 2229 Times, Percentage Used : 91.43%
Quant 4 Used : 192 Times, Percentage Used : 7.88%

Credits
---------
Quant 31 Used : 13 Times, Percentage Used : 0.53%

Number Of Consecutive I-Frames : 174

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

Movie
-------
Quant 2 Used : 2425 Times, Percentage Used : 1.23%
Quant 3 Used : 123338 Times, Percentage Used : 62.37%
Quant 4 Used : 66230 Times, Percentage Used : 33.49%
Quant 5 Used : 1584 Times, Percentage Used : 0.80%
Quant 6 Used : 13 Times, Percentage Used : 0.01%

Credits
---------
Quant 31 Used : 4174 Times, Percentage Used : 2.11%

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

Number Of Intra-Frames (Key-Frames) : 2438
Number Of Inter-Frames (P-Frames) : 197764
Total Number Of Frames : 200202

1.22% of the Movie is Intra-Frames (Key-Frames)
98.78% of the Movie is Inter-Frames (P-Frames)

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

1-Pass Size : 1133919433 Bytes or 1107343 KBytes
Scaled Size : 633962737 Bytes or 619104 KBytes
Actual Size : 634056440 Bytes or 619195 KBytes
Compressibility : 55.92%
Quality of XviD avi : 59.83%

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

And, last but not least, I would like to state my own comments after watching certain parts of the movie.

First of all, there is a green bar at the right side of the screen throughout the movie, independent from ffdshow filter. After uninstalling ffdshow and watching the movie in three different players besides checking in vdub, the green bar is still there :(.

Secondly, ffdshow filter produces lots of strange artifacts (pink blocks floating especially at the right side of the screen) both in simple and xvid IDCT. Guess we urgently need Nic's decoder filter :).

And finally, the visual quality of the encoded movie is unfortunately very poor (or at least worse than any of my previous SBC encodes for testing purposes, whatever the resolution or the resize filter is), with a blurry image with many blocks and floating surfaces all over the movie :(.

(My eyes can't deceive me this much, so I even dismissed the idea of attaching some screenshots :()

That's all for now; but I guess there IS something going wrong, though "I" don't know what :confused:. Perhaps the altCC settings?.

Waiting for your opinions and comments.

Best wishes and my best regards,
iago

Koepi

6th August 2002, 20:52

Iago,

it sounds like your avisynth script isn't correct. XviD has no "green line" bugs or even pink blocks floating around, those problems derive from anywhere else. I'm certain with this, my encodes look pretty good.

iago

6th August 2002, 21:03

@Koepi,

Thanks for the reply and your support. I'll try encoding again after I check the avisynth script. You're absolutely right; all of these are really really weird. It's the first time I encounter such problems, and I'll do the encode again with the same first pass and second pass settings after I check and correct the avisynth script.

Best wishes,
iago

BiaTch 5.0

6th August 2002, 21:32

Koepi do you want results for any movies?, here is The Hole PAL/interlaced/field/neutral bicubic;

First Pass

6.Ultra High
H.263
lumi mask
Max I-frame interval: 300
Min I-frame interval: 6 (forgot)
No Hinted ME

Second Pass

6.UltraHigh
Modulated
Lumi mask
Min-Max I-frame quant: 2-6
Min-Max P-frame quant: 2-16
Alt Curve off

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

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

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 6525 Times, Percentage Used : 4.65%
Quant 3 Used : 106678 Times, Percentage Used : 76.04%
Quant 4 Used : 26594 Times, Percentage Used : 18.96%
Quant 5 Used : 441 Times, Percentage Used : 0.31%
Quant 6 Used : 44 Times, Percentage Used : 0.03%
Quant 7 Used : 10 Times, Percentage Used : 0.01%
Quant 8 Used : 1 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 3.151

No credits encoding!!

MPEG Quantization Type Used 113203 timed, Percentage Used : 80.69%

H.263 Quantization Type Used 27090 timed, Percentage Used : 19.31%

Quantizers prevented from rising too steeply 180 times

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

Movie
-------
Quant 2 Used : 1210 Times, Percentage Used : 95.65%
Quant 3 Used : 51 Times, Percentage Used : 4.03%
Quant 4 Used : 4 Times, Percentage Used : 0.32%

Credits
---------

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

Movie
-------
Quant 2 Used : 5315 Times, Percentage Used : 3.82%
Quant 3 Used : 106627 Times, Percentage Used : 76.69%
Quant 4 Used : 26590 Times, Percentage Used : 19.13%
Quant 5 Used : 441 Times, Percentage Used : 0.32%
Quant 6 Used : 44 Times, Percentage Used : 0.03%
Quant 7 Used : 10 Times, Percentage Used : 0.01%
Quant 8 Used : 1 Times, Percentage Used : 0.00%

Credits
---------

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

Number Of Intra-Frames (Key-Frames) : 1265
Number Of Inter-Frames (P-Frames) : 139028
Total Number Of Frames : 140293

0.90% of the Movie is Intra-Frames (Key-Frames)
99.10% of the Movie is Inter-Frames (P-Frames)

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

1-Pass Size : 1181303681 Bytes or 1153616 KBytes
Scaled Size : 755348954 Bytes or 737645 KBytes
Actual Size : 755359714 Bytes or 737655 KBytes
Compressibility : 63.94%
Quality of XviD avi : 63.48%

iago

6th August 2002, 21:50

@Koepi,

I found that the problem was indeed due to the avisynth script, in fact arising from simple resize, though I dunno why.

First, I checked my current avisynth script in Vdub, and the green bar was there at the right side of the screen. Then I produced the avisynth script again (with the same resoluion and using simple resize again, checked it one more time, and the green bar was still there.

When I generated the avisynth script with the same resolution but with neutral bicubic this time, everything was OK and there was no green line.

Then I encoded a small part of the movie using the new avisynth script with neutral bicubic. Ffdsow filter displayed no problems and the pink blocks were happily gone :).

I guess it's pointless to discuss the simple resize-avisynth issue here in this thread, and it's nice to have the main problem solved.

Time to head for another two pass :).

Many thanks and best regards,
iago

MoonWalker

6th August 2002, 22:12

@iago

There __WAS__ a known bug with simple resizer,but trbarry has corrected it..Browse the avisynth forum to find the new version

MoonWalker

cult

6th August 2002, 22:18

thats right,with the old simpleresize had to be multiple of 4.
The new version is fixed.When using simpleresize alwyas check with the preview button.It will show u if the green line is there.Its that simple.

iago

6th August 2002, 22:36

@MoonWalker

Thanks a lot. I've updated it. Also thanks for the new DebugView Analyzer v0.9 for Xvid that provides info about the consecutive I-frames :).

iago

trbarry

6th August 2002, 22:37

Both input & output of SimpleResize now only have to be multiples of 2 pixels, but I only fixed it a week or two ago. Please get the newest copy and let me know if there is still a problem.

www.trbarry.com/SimpleResize.zip

- tom

iago

6th August 2002, 22:49

@trbarry

Thanks a lot. I've updated it again :).
I've just checked it and there were no problems (no green line) at all.

Best regards,
iago

trbarry

6th August 2002, 23:08

I've updated it again

iago -

Actually my comment above was a crossed post. ;)

But I"m glad it works now.

- Tom

Gannjunior

7th August 2002, 00:48

@Koepi
I'm going to do Platoon. Have you got any "experimetal" settings you want to test to give me for this film?So I could post the results after the encoding.In particular, could I try,about the alt. curve,an high -low distance of 500-90 ?

thx

ookzDVD

7th August 2002, 03:25

@Koepi,

I want to confirm that the _line_ bug has gone since I use
the 05-08-2002 build (with PMVFast enabled). ;)

Btw, I just saw the CSV

7.8.2002 01:20:
U vfw/src/codec.c (rev.1.23) Isibaar:
- use advanced diamond for quality 5 and square search for quality 6

...what do you thing ?

@trbarry,
...thanks for your _simpleresize_ but I hope someday it will no
restriction (div 2) ;).... but it's just kidding ;)

Thank you.

Koepi

7th August 2002, 04:09

well, the code inserted by isibaar an foxer is "mine" since i don't have CVS write access.

And for platoon - try hitting "load defaults" while you're passing by it. Set search precision=6.

Regards,
Koepi

ookzDVD

7th August 2002, 04:44

@Koepi,

sorry, I don't know if it's you ;)
thank you for the fast action ;)

iago

7th August 2002, 09:14

@Koepi and all

This time, xvid really did its magic! :D The quality is pretty good and really impressing.

05082202-1 build test (redone) results:

Fight Club (2:19)
640*272
Neutral Bicubic
Aimed Video Size: 624000 kb

1st pass:

UltraHigh
H.263
Max-Min I-frame interval: 300-1
Lumi masking enabled
No Hinted ME

2nd pass:

UltraHigh
Modulated
Max-Min I-frame interval: 300-1
Lumi masking enabled
No Hinted ME
Min-Max I-frame quant: 2-6
Min-Max P-frame quant: 2-16
AltCC: Low/225/75 (here, i cheated a bit :))
All the rest with default values

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

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

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 3543 Times, Percentage Used : 1.81%
Quant 3 Used : 112670 Times, Percentage Used : 57.48%
Quant 4 Used : 76830 Times, Percentage Used : 39.20%
Quant 5 Used : 2923 Times, Percentage Used : 1.49%
Quant 6 Used : 51 Times, Percentage Used : 0.03%

Average Quantizer Used for Movie : 3.404

Quantizers Used For Credits :
--------------------------------
Quant 31 Used : 4187 Times.

MPEG Quantization Type Used 120400 timed, Percentage Used : 60.14%

H.263 Quantization Type Used 79804 timed, Percentage Used : 39.86%

Quantizers prevented from rising too steeply 0 times

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

Movie
-------
Quant 3 Used : 2230 Times, Percentage Used : 90.76%
Quant 4 Used : 214 Times, Percentage Used : 8.71%

Credits
---------
Quant 31 Used : 13 Times, Percentage Used : 0.53%

Number Of Consecutive I-Frames : 184

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

Movie
-------
Quant 2 Used : 3543 Times, Percentage Used : 1.79%
Quant 3 Used : 110440 Times, Percentage Used : 55.85%
Quant 4 Used : 76616 Times, Percentage Used : 38.74%
Quant 5 Used : 2923 Times, Percentage Used : 1.48%
Quant 6 Used : 51 Times, Percentage Used : 0.03%

Credits
---------
Quant 31 Used : 4174 Times, Percentage Used : 2.11%

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

Number Of Intra-Frames (Key-Frames) : 2457
Number Of Inter-Frames (P-Frames) : 197747
Total Number Of Frames : 200204

1.23% of the Movie is Intra-Frames (Key-Frames)
98.77% of the Movie is Inter-Frames (P-Frames)

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

1-Pass Size : 1198214458 Bytes or 1170131 KBytes
Scaled Size : 634170511 Bytes or 619307 KBytes
Actual Size : 634263604 Bytes or 619398 KBytes
Compressibility : 52.93%
Quality of XviD avi : 58.75%

so long,
iago

rui

7th August 2002, 09:17

Sorry to be a little OT, but if i am not mistaken, since now EPZS is disabled, there isn't any diferences between Koepi's and uManic's builds, correct?

ookzDVD

7th August 2002, 09:29

@iago,
Glad to hear your result ;)
...so I think it's time for me to rip Lord Of The Ring into 1CD ;)

@rui,
I think so, now only Nic's build use the EPZS.

BiaTch 5.0

7th August 2002, 09:39

@Koepi, should we be using, AltCC low/high 500, or off?.

soulfx

7th August 2002, 13:18

@BiaTch 5.0, I don't think there is anything wrong with Alt CC so there shouldn't be any reason to disable it. But I'll let Koepi answer that one.

I did another run with SPR with the latest Koepi build and get some new results. I also made sure not to close Dbgview this time.

Same settings as before, just with the latest build:
http://members.cox.net/soul.fxpro/sprtest/compare.htm

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

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

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 1474 Times, Percentage Used : 0.63%
Quant 3 Used : 25517 Times, Percentage Used : 10.96%
Quant 4 Used : 94258 Times, Percentage Used : 40.47%
Quant 5 Used : 84567 Times, Percentage Used : 36.31%
Quant 6 Used : 25072 Times, Percentage Used : 10.76%
Quant 7 Used : 1921 Times, Percentage Used : 0.82%
Quant 8 Used : 107 Times, Percentage Used : 0.05%
Quant 9 Used : 2 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 4.483

No credits encoding!!

MPEG Quantization Type Used 26991 timed, Percentage Used : 11.59%

H.263 Quantization Type Used 205927 timed, Percentage Used : 88.41%

Quantizers prevented from rising too steeply 0 times

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

Movie
-------
Quant 3 Used : 1 Times, Percentage Used : 0.06%
Quant 4 Used : 1608 Times, Percentage Used : 89.53%
Quant 5 Used : 16 Times, Percentage Used : 0.89%
Quant 6 Used : 171 Times, Percentage Used : 9.52%

Credits
---------

Number Of Consecutive I-Frames : 150

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

Movie
-------
Quant 2 Used : 1474 Times, Percentage Used : 0.64%
Quant 3 Used : 25516 Times, Percentage Used : 11.04%
Quant 4 Used : 92650 Times, Percentage Used : 40.09%
Quant 5 Used : 84551 Times, Percentage Used : 36.58%
Quant 6 Used : 24901 Times, Percentage Used : 10.77%
Quant 7 Used : 1921 Times, Percentage Used : 0.83%
Quant 8 Used : 107 Times, Percentage Used : 0.05%
Quant 9 Used : 2 Times, Percentage Used : 0.00%

Credits
---------

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

Number Of Intra-Frames (Key-Frames) : 1796
Number Of Inter-Frames (P-Frames) : 231122
Total Number Of Frames : 232918

0.77% of the Movie is Intra-Frames (Key-Frames)
99.23% of the Movie is Inter-Frames (P-Frames)

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

1-Pass Size : -112135463 Bytes or 4084796 KBytes
Scaled Size : 1550470785 Bytes or 1514131 KBytes
Actual Size : 1550470913 Bytes or 1514131 KBytes

Usefull Statistics
------------------
Compressibility : -1382.68%
Relative Quality of XviD avi : 44.62%
Absolute Quality of XviD avi : 92.55%

Marc FD

7th August 2002, 15:42

@soulfx
i must say it's a good idea to reencode it (to see if XviD is bugfree)
BUT i think your encode would be more, more valuable if you could use EXACTLY the same settings than doom9. resolution & size is very important. If you would do that i would really enjoy to compare XviD to others codecs (if you gives snapshots like the first time)
but if the resolution is not the same and you use XCD, you can't compare at all, it would be ugly cheating.

Could try to encode a reference encode ? (with doom9-like settings) Just if you have time to spend of course (i don't haveSPR :( )

Koepi

7th August 2002, 16:10

Hm, but to be fair you should use my latest build, I put it online now as it works like charme for me (hehe, well, in fact it's already in CVS ;) ).

XviD-06082002-1:
- Advanced search modes, helping quality.
- Further GUI cleanup (MV hints file box properly dis/enabled).

It's the same search mode used back with EPZS for search precision 6, this is important.
Search precision 5 needs some research so, if it's faster, better, both of that, none of that.

Regards,
Koepi

Peters

7th August 2002, 18:00

Koepi, you go too fast.
Are you working day and night? :)

Congratulations for your (very) nice work

Marc FD

7th August 2002, 18:17

lol :)

@Koepi

you used PMVFast^2 with advdiamond for motion search 5, right ??
if you've done so, i think i would make some tests
(on small clips, because of my lack of CPU-power)

it would be great to directly compare EPZS^2 and PMVfast^2 with the same build. It would gives good reference results.

Could you fast confirm? Thx.

Koepi

7th August 2002, 18:46

it would be great to directly compare EPZS^2 and PMVfast^2 with the same build. It would gives good reference results.

Could you fast confirm? Thx.

you can compare EPZS^2 and PMVfast^2 now when using a build with corrcted luma masking code and EPZS activated vs. the 06/08/02 build.

I hope this is what you want to have confirmed.

But as reference results? Well, not really. EPZS isn't correctly implemented, period.

Regards,
Koepi

Marc FD

7th August 2002, 18:55

no, no : using ONE build only

Originally posted by Koepi

It's the same search mode used back with EPZS for search precision 6, this is important.
Search precision 5 needs some research so, if it's faster, better, both of that, none of that.

sm 6 : EPZS^2 and other generic stuff (1/2pel,ect...)
sm 5 : PMVFast^2 and other generic stuff (1/2pel,ect...)

right ?? (that was wy i need to be confirmed)

i know EPZS is buggy (gruel claims it often enough ;) )
BUT we must admit it sometimes does magic !

when i say ref encode i want to say something serious :cool: with the same protocol and just a PMVfast/EPZS trigger.
so i need ONE build :)

If not it would be kind to send me the CVS. i would compile the stuff myself :cool:

Koepi

7th August 2002, 19:02

Nope, I don't have any EPZS code activated in that binary.

I just changed search precision to include different approaches.

Marc FD

7th August 2002, 19:10

Originally posted by Marc FD
If not it would be kind to send me the CVS. i would compile the stuff myself :cool:

EDIT : i don't need XviD.ax at all, right ? (don't have M$DXSDK )

EDIT2 : I don't want to disturb you and i'll try to load it myself.

Keep working :)

iago

7th August 2002, 23:29

Yes, Koepi is really fast :).

So I'm going for another test encode with the new 06082002-1 build, this time with (hard to compress!) Natural Born Killers (114 min), 640*352, neutral bicubic, 2CDs (with AC3 sound), aimed video size: 1102000 kb.

first pass:

ultrahigh
h.263
no lumi masking
no hinted ME
credits: 31 quant
all the rest default

Considering to use modulated quantizers, altCC with Low aggression/High300/Low100 (rest untouched), and capping Min-Max I-frames 2-4 and Min-Max P-frames 2-8, with no lumi again, for the second pass. Comments for the (prospective):) second pass settings (maybe regarding automatic strength, etc.)?

(I disabled lumi masking for this test to see the visual difference in very dark/very bright scenes (especially the dark ones) compared to when it's enabled. Sometimes I can't help feeling that too many bits are shaved off these scenes when it is enabled :))

Thanks in advance,
iago

MaTTeR

7th August 2002, 23:39

@iago

H.263 for a 2CD rip? Hrm..that might be a little soft on my eyes but I see your using Neutral Bicubic so maybe it is sharp enough.

@Koepi

This is certainly one of the better builds I've used in a long time in my opinion. Actually, I'm using a build that Acails compiled with the latest CVS but he enabled EPZS(PMVFast^2 moves a little too much on static backgrounds for me). So far I've only done a few 1CD rips today using the defaults with a payback rate of 500. I've yet to see one macroblock in any of the bright or dark scenes using lumi-masking in both passes at an average bitrate of 885kbps. Motion Search 6 used of course:) Great work man!

Edit- Modulated both passes and MVH wasn't used.

Marc FD

8th August 2002, 01:17

Some preleminary results of my tests :
EPZS wins 2% when there is much movement (over your Q6 setting)
but loose 10% speed (30 fps down to 27)
anyway, you say Q5 should be tested. i think it's because of ADVANCEDDIAMOND16, right ?
if so, disabling EXTSEARCH16 is really not fair :)
adv. diamond rocks ! especially ADVANCEDDIAMOND8 against HALFPELDIAMOND8
i will do more test on more cuts (crazy action, very calm)
I should add all my test are ONLY done on anime.

@MaTTeR
>PMVFast^2 moves a little too much on static backgrounds for me

what ?? maybe EPZS^2 is better than PMVFast, but if you test it seriously, you'll see that EPZS ME is overestimating movement (and is better when there is alot of movement)

Koepi

8th August 2002, 01:23

well, you demanded it, so here we go:

XviD-08082002-1:
- Added a scene change detection threshold control.
- Trying EPZS(^2) motion estimation algorithm again.

(modified sources vs CVS are included, and I forgot to set the special build correctly ;) )

@Marc:

do you think I should swap around the flags a little more? ;)

Regards,
Koepi

MaTTeR

8th August 2002, 01:32

Originally posted by Marc FD

@MaTTeR
>PMVFast^2 moves a little too much on static backgrounds for me

what ?? maybe EPZS^2 is better than PMVFast, but if you test it seriously, you'll see that EPZS ME is overestimating movement (and is better when there is alot of movement)

Marc,

The 2 movies I encoded today were low motion for the most part. I can't tell you how refreshing it was to not see pictures on walls moving or frames jumping:D However, I haven't tried any action flix yet so I'll do that with Koepi's latest. That scene detection threshold sounds very appealing, especially for an upcoming X-Men rip.

soulfx

8th August 2002, 03:44

Allright, another SPR (and yes it's using doom9's settings).

Settings used are the same as doom9's for AVS script wise so if you need the settings check his comparison. The XviD settings are same as mentioned before, just with the XviD-06082002-1 build. Target size was: 1276028

http://members.cox.net/soul.fxpro/sprtest/compare.htm

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

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

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 2468 Times, Percentage Used : 1.01%
Quant 3 Used : 2627 Times, Percentage Used : 1.08%
Quant 4 Used : 14729 Times, Percentage Used : 6.04%
Quant 5 Used : 38842 Times, Percentage Used : 15.93%
Quant 6 Used : 62028 Times, Percentage Used : 25.44%
Quant 7 Used : 59449 Times, Percentage Used : 24.39%
Quant 8 Used : 40085 Times, Percentage Used : 16.44%
Quant 9 Used : 16569 Times, Percentage Used : 6.80%
Quant 10 Used : 5137 Times, Percentage Used : 2.11%
Quant 11 Used : 1282 Times, Percentage Used : 0.53%
Quant 12 Used : 438 Times, Percentage Used : 0.18%
Quant 13 Used : 118 Times, Percentage Used : 0.05%
Quant 14 Used : 13 Times, Percentage Used : 0.01%
Quant 15 Used : 2 Times, Percentage Used : 0.00%
Quant 16 Used : 4 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 6.549

No credits encoding!!

MPEG Quantization Type Used 5095 timed, Percentage Used : 2.09%

H.263 Quantization Type Used 238696 timed, Percentage Used : 97.91%

Quantizers prevented from rising too steeply 0 times

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

Movie
-------
Quant 3 Used : 1 Times, Percentage Used : 0.05%
Quant 4 Used : 2 Times, Percentage Used : 0.10%
Quant 5 Used : 3 Times, Percentage Used : 0.15%
Quant 6 Used : 1944 Times, Percentage Used : 99.69%

Credits
---------

Number Of Consecutive I-Frames : 0

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

Movie
-------
Quant 2 Used : 2468 Times, Percentage Used : 1.02%
Quant 3 Used : 2626 Times, Percentage Used : 1.09%
Quant 4 Used : 14727 Times, Percentage Used : 6.09%
Quant 5 Used : 38839 Times, Percentage Used : 16.06%
Quant 6 Used : 60084 Times, Percentage Used : 24.84%
Quant 7 Used : 59449 Times, Percentage Used : 24.58%
Quant 8 Used : 40085 Times, Percentage Used : 16.57%
Quant 9 Used : 16569 Times, Percentage Used : 6.85%
Quant 10 Used : 5137 Times, Percentage Used : 2.12%
Quant 11 Used : 1282 Times, Percentage Used : 0.53%
Quant 12 Used : 438 Times, Percentage Used : 0.18%
Quant 13 Used : 118 Times, Percentage Used : 0.05%
Quant 14 Used : 13 Times, Percentage Used : 0.01%
Quant 15 Used : 2 Times, Percentage Used : 0.00%
Quant 16 Used : 4 Times, Percentage Used : 0.00%

Credits
---------

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

Number Of Intra-Frames (Key-Frames) : 1950
Number Of Inter-Frames (P-Frames) : 241841
Total Number Of Frames : 243791

0.80% of the Movie is Intra-Frames (Key-Frames)
99.20% of the Movie is Inter-Frames (P-Frames)

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

1-Pass Size : 1362398975 Bytes or 1330467 KBytes
Scaled Size : 1300791847 Bytes or 1270304 KBytes
Actual Size : 1300799195 Bytes or 1270311 KBytes

Usefull Statistics
------------------
Compressibility : 95.48%
Relative Quality of XviD avi : 30.54%
Absolute Quality of XviD avi : 86.35%

Koepi

8th August 2002, 03:51

Thanks for testing soulfx!

But somethings very wrong. With that 1st Pass to 2nd Pass size relation you should end up with a 2+3 quantizer rip...

Doom9 was encoding credits at 15% bitrate btw., so this still is a little different :-/

Best regards,
koepi

soulfx

8th August 2002, 04:03

Agh! I give up. I've lost too much time doing tests. If everyone want's a Doom9 comparision, your looking at the wrong person here. The last time I checked I was SoulFX. As much as I would like to try to help I can't be a hard core tester.

I appriciate everyone's help and thank everyone for there comments and suggestions. I wish I could be of more help, but I've got stuff I need to encode.

Regrets,
SoulFX

ookzDVD

8th August 2002, 04:25

@Koepi,
about the 08082002 build with EPZS enabled,
is that EPZS improved or just the same like the old one ?

@soulfx,
sure, take your time, I think we don't push you that much ;)
sometimes re-encoding is very-very boring since you'll watch
the same movie, again and again.
Personally I test the build with the trailer, it's only about
3 minutes long.

Koepi

8th August 2002, 05:22

EPZS code wasn't touched for at least 3 months now...

ookzDVD

8th August 2002, 05:44

@Koepi,
Thank you for the confirmation, better I'll try to encode a trailer later.

PS. how about "the scene change detection threshold control"
any hints ? for drama movie ? for action movie ?

BiaTch 5.0

8th August 2002, 08:47

@Koeepi

Shoud we be using any new settings for the new build or same old.

Marc FD

8th August 2002, 11:38

@ Koepi :
I wasn't saying that EPZS(^2) are better : there are not !!!
full EPZS(^2) gave me the bigger filesizes !!

I'm making my tests now. You would see the results in 1/2 hours :)

Koepi

8th August 2002, 12:09

Well, Matrix first pass size went down for me:

PMVfast^2 1.305MB, EPZS^2 1.303MB.

It shouldn't make a difference, but I'll try second pass without MVhints this time. I'd love to see more stable, unmoving backgrounds. They're too much "on the run" with PMVfast :-/ (but still better than anything else ;) )

Regards,
Koepi

rui

8th August 2002, 12:14

Well, i just made a small test, using the latest uManiac’s build (PMVFast, or is it the diamond??) against Koepi’s latest build (EPZS). Both had the exact same settings (motion search 6) but in Koepi’s i choosed the new motion parameter at 65%.

uManiac’s gave me an average quantizer of 7, 071, and 138 I-frames.

Koepi gave me a average quantizer of 7,102, and 114 i-frames. This last value susrprsed me a little, because i increased the motion detection to 65, against the default (uManiac) of 50.

In the rest of the report, they both got very similar results, but koepi’s used quant 14 1 time, uManiacs didn’t used it. But 1 time isn’t significant.

Visual comparing, it was noticeable that uManiac’s build was a little more smoothed out, but the diference was very small.

Koepi

8th August 2002, 12:28

Well, if you'd see the tooltip coming up above the box...

it states

"percentage of intra MBs in a frame to force a keyframe".

If you set it to 66, you get less keyframes.
if you set it to 33, you get more keyframes.

Regards,
Koepi

rui

8th August 2002, 13:34

sorry. :(
My mistake :o :stupid:

iago

8th August 2002, 14:04

Natural Born Killers (114 min)
640*352
Neutral Bicubic
Aimed Video Size: 1102000 kb (2CD with AC3 audio)

First Pass:
UltraHigh
MPEG
No Lumi
No Hinted ME
the rest: default

Second Pass:
UltraHigh
MPEG
No Lumi
No Hinted ME
altCC Low/High300/Low100 (the rest untouched)
Min-Max I-frames 2-4
Min-Max P-frames 2-8

credits: 31 quant

Results:
(watchable, nice encode, in spite of the compressibility values in GKnot (first pass stats: 33.7) and DebugView Analyzer.)

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

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

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 709 Times, Percentage Used : 0.43%
Quant 3 Used : 17048 Times, Percentage Used : 10.22%
Quant 4 Used : 66165 Times, Percentage Used : 39.67%
Quant 5 Used : 62012 Times, Percentage Used : 37.18%
Quant 6 Used : 17216 Times, Percentage Used : 10.32%
Quant 7 Used : 2419 Times, Percentage Used : 1.45%
Quant 8 Used : 1205 Times, Percentage Used : 0.72%

Average Quantizer Used for Movie : 4.540

Quantizers Used For Credits :
--------------------------------
Quant 31 Used : 4325 Times.

MPEG Quantization Type Used 171099 timed, Percentage Used : 100.00%

Quantizers prevented from rising too steeply 0 times

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

Movie
-------
Quant 4 Used : 3454 Times, Percentage Used : 99.11%

Credits
---------
Quant 31 Used : 31 Times, Percentage Used : 0.89%

Number Of Consecutive I-Frames : 16

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

Movie
-------
Quant 2 Used : 709 Times, Percentage Used : 0.42%
Quant 3 Used : 17048 Times, Percentage Used : 10.17%
Quant 4 Used : 62711 Times, Percentage Used : 37.41%
Quant 5 Used : 62012 Times, Percentage Used : 37.00%
Quant 6 Used : 17216 Times, Percentage Used : 10.27%
Quant 7 Used : 2419 Times, Percentage Used : 1.44%
Quant 8 Used : 1205 Times, Percentage Used : 0.72%

Credits
---------
Quant 31 Used : 4294 Times, Percentage Used : 2.56%

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

Number Of Intra-Frames (Key-Frames) : 3485
Number Of Inter-Frames (P-Frames) : 167614
Total Number Of Frames : 171099

2.04% of the Movie is Intra-Frames (Key-Frames)
97.96% of the Movie is Inter-Frames (P-Frames)

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

1-Pass Size : -940936129 Bytes or 3275421 KBytes
Scaled Size : 1124271714 Bytes or 1097921 KBytes
Actual Size : 1124234895 Bytes or 1097885 KBytes

Usefull Statistics
------------------
Compressibility : -119.48%
Relative Quality of XviD avi : 44.05%
Absolute Quality of XviD avi : 92.38%

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

I'll repeat the test with 08082002 build, using H.263 for the first pass and Modulated for the second, and with lumi masking in both passes, to increase compressibility and reach a lower average quant. I'll leave the other settings as above.

iago

Koepi

8th August 2002, 14:25

Nice, thanks for testing iago! :)

Marc FD

8th August 2002, 15:37

@Koepi
when you use EPZS^2 for search16, what do you use for search8 ??

here are the results of my test :

XviD Motion Estimation test with CVS 07.08.2002 (custom debug builds)
ME used :

1 ) EPZS_16 EPZS_8 : full EPZS(^2) (EPZS is not a good choise for search8)
PMV_EARLYSTOP16 | PMV_HALFPELREFINE16 | PMV_EXTSEARCH16 | PMV_USESQUARES16 |
PMV_EARLYSTOP8 | PMV_HALFPELREFINE8 | PMV_HALFPELDIAMOND8 |

2 ) EPSZ_16 PMVfast_8 : Best EPZS(^2) (mix between EPZS and PMVfast)
PMV_EARLYSTOP16 | PMV_HALFPELREFINE16 | PMV_EXTSEARCH16 | PMV_USESQUARES16 |
PMV_EARLYSTOP8 | PMV_HALFPELREFINE8 | PMV_HALFPELDIAMOND8

3 ) PMVfast_16 PMVfast_8 : PMVFast^2 (current Q6 ME in Koepi's build)
PMV_EARLYSTOP16 | PMV_HALFPELREFINE16 | PMV_EXTSEARCH16 | PMV_USESQUARES16 |
PMV_EARLYSTOP8 | PMV_HALFPELREFINE8 | PMV_HALFPELDIAMOND8

4 ) PMVfast_16 PMVfast_8 : PMVfast AdvDiamond (Advanced Diamond)
PMV_EARLYSTOP16 | PMV_HALFPELREFINE16 | PMV_EXTSEARCH16 | PMV_ADVANCEDDIAMOND16 |
PMV_EARLYSTOP8 | PMV_HALFPELREFINE8 | PMV_HALFPELDIAMOND8

Tested on anime content ONLY.(ME is critical on amime)
test clips :
1) Full Motion (a very fast scene with motion on the entire frame) (83 frames)
2) Moves (some scenes with motion on a still background) (536 frames)
3) Travellings/Zooms (551 frames)

All parameters others than ME to defaults
source : MPEG2 / VDub Fast Recompress
Constant quant 2 encode

Results : (sizes in Ko, min/avg/max I-frame in bytes)
Quant 2 :
clip 1) Full Motion
ME# | size | min/avg/max I-frames
1) 4302 48243/52388/57950
2) 4298 48246/52352/57381
2*) 4278 47713/52106/56938
3) 4384 48760/53421/58821
4) 4382 48904/53395/58786

2* : 2) with ADVANCEDDIAMOND8 instead of HALFPELDIAMOND8. No speed hit.

clip 2) Moves
ME# | size | min/avg/max I-frames
1) 4906 2139/8908/28966
2) 4900 2104/8896/28769
3) 4902 2073/8902/28855
4) 4902 2086/8900/28768

clip 3) Travellings/Zooms
ME# | size | min/avg/max I-frames
1) 5610 1333/10106/34231
2) 5600 1348/10089/33789
3) 5612 1360/10111/33935
4) 5608 1361/10103/33833

PSNR :
The PSNR results were always very close, less than 0,02 dB difference.

Speed :
PMVfast^2 and PMVfast advdiamond are the faster
mixed EPZS 5% slower
full EPZS 10% slower

Conclusion :

the best ME in term of compression is :
EPSZ_16 PMVfast_8
PMV_EARLYSTOP16 | PMV_HALFPELREFINE16 | PMV_EXTSEARCH16 | PMV_USESQUARES16 |
PMV_EARLYSTOP8 | PMV_HALFPELREFINE8 | PMV_ADVANCEDDIAMOND8

To avoid EPZS (buggy with luma masking??), best ME is :
PMVfast_16 PMVfast_8
PMV_EARLYSTOP16 | PMV_HALFPELREFINE16 | PMV_EXTSEARCH16 | PMV_ADVANCEDDIAMOND16 |
PMV_EARLYSTOP8 | PMV_HALFPELREFINE8 | PMV_ADVANCEDDIAMOND8

08.08.2002 @15h32GMT / by MarcFD / marc.fd#libertysurf.fr (#=@)

Hope it helps :)

rui

8th August 2002, 17:09

Originally posted by Marc FD
To avoid EPZS (buggy with luma masking??), best ME is :
PMVfast_16 PMVfast_8
PMV_EARLYSTOP16 | PMV_HALFPELREFINE16 | PMV_EXTSEARCH16 | PMV_ADVANCEDDIAMOND16 |
PMV_EARLYSTOP8 | PMV_HALFPELREFINE8 | PMV_ADVANCEDDIAMOND8

08.08.2002 @15h32GMT / by MarcFD / marc.fd#libertysurf.fr (#=@)
[/CODE]

Hope it helps :)

So, if i got this right, this corresponds to the advanced diamond in uManiac's builds, motion search precision 5, correct?

What about motion search 6, corresponding to square search quality? I must confess that i am begining to fell a little lost here :)

Isibaar

8th August 2002, 17:10

@soulfx:
there's nothing wrong with your SPR results: As I told Koepi already, I also did a SPR encoding using doom9's settings and I got similar results to yours.
There seems to be something wrong with the calculated 1st pass size of the DebugView Analyzer (I guess an overflow happens). I didn't discard the first pass and so I know it was about 4 GB in reality. An average quant of around 6 for the second pass is no big surprise then...

I did yet another encoding yesterday and tried to test some things out and to tweak doom9's settings (well, basically I used MPEG quantisation and limited the p-frame quants to a range of 4-8), and this encoding seems to be a bit better than my earlier one (at least in my opinion, but you know, the MPEG<->h.263 quant choice is more or less a matter of personal taste).

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

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

Quantizers Used For Movie :
------------------------------
Quant 4 Used : 24299 Times, Percentage Used : 9.97%
Quant 5 Used : 49307 Times, Percentage Used : 20.23%
Quant 6 Used : 60739 Times, Percentage Used : 24.92%
Quant 7 Used : 45236 Times, Percentage Used : 18.56%
Quant 8 Used : 64191 Times, Percentage Used : 26.33%

Average Quantizer Used for Movie : 6.311

No credits encoding!!

MPEG Quantization Type Used 243772 timed, Percentage Used : 100.00%

Quantizers prevented from rising too steeply 0 times

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

Movie
-------
Quant 5 Used : 1750 Times, Percentage Used : 100.00%

Credits
---------

Number Of Consecutive I-Frames : 0

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

Movie
-------
Quant 4 Used : 24299 Times, Percentage Used : 10.04%
Quant 5 Used : 47557 Times, Percentage Used : 19.65%
Quant 6 Used : 60739 Times, Percentage Used : 25.10%
Quant 7 Used : 45236 Times, Percentage Used : 18.69%
Quant 8 Used : 64191 Times, Percentage Used : 26.52%

Credits
---------

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

Number Of Intra-Frames (Key-Frames) : 1750
Number Of Inter-Frames (P-Frames) : 242022
Total Number Of Frames : 243772

0.72% of the Movie is Intra-Frames (Key-Frames)
99.28% of the Movie is Inter-Frames (P-Frames)

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

1-Pass Size : 586191439 Bytes or 572452 KBytes
Scaled Size : 1300794945 Bytes or 1270307 KBytes
Actual Size : 1300775578 Bytes or 1270288 KBytes

Usefull Statistics
------------------
Compressibility : 221.90%
Relative Quality of XviD avi : 31.69%
Absolute Quality of XviD avi : 87.07%

AndyP

8th August 2002, 18:23

Results for 06082002-1 build
(Sorry, I know there is a later build but these run last night)

Encoding Lord of the Rings (2h 51m)
Aiming for 1568858KB (2x850MB CD). This was supposed to include credits, but they didn't encode (argh!)
[Is this the fix by foxer in changelog on 7/8]

AVS settings:
crop(0,76,720,424)
SimpleResize(672,272)

Settings:
MPEG quant first pass
Modulated quant second pass
MinKF 1, MaxKF 250
Lumi-masking and MVHints enabled
Iframes limited to 2-3
Pframes limited to 2-8
Iframe boost 20%, Below Iframe dist. 10, bit reduction 50%
Alt CC Low aggression, High dist 200%, Low dist 50%
Credits set for fixed quant 12 with greyscale - DIDN'T HAPPEN!
All else default

Two encodes done - first with motion search 6, second with 5.

Both sized 1568976KB (no credits)

MOTION SEARCH 6 Analysis

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

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 74545 Times, Percentage Used : 30.35%
Quant 3 Used : 166186 Times, Percentage Used : 67.67%
Quant 4 Used : 4847 Times, Percentage Used : 1.97%
Quant 5 Used : 2 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 2.716

No credits encoding!!

MPEG Quantization Type Used 240731 timed, Percentage Used : 98.03%

H.263 Quantization Type Used 4849 timed, Percentage Used : 1.97%

Quantizers prevented from rising too steeply 0 times

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

Movie
-------
Quant 2 Used : 3347 Times, Percentage Used : 94.12%
Quant 3 Used : 209 Times, Percentage Used : 5.88%

Credits
---------

Number Of Consecutive I-Frames : 57

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

Movie
-------
Quant 2 Used : 71198 Times, Percentage Used : 29.42%
Quant 3 Used : 165977 Times, Percentage Used : 68.58%
Quant 4 Used : 4847 Times, Percentage Used : 2.00%
Quant 5 Used : 2 Times, Percentage Used : 0.00%

Credits
---------

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

Number Of Intra-Frames (Key-Frames) : 3556
Number Of Inter-Frames (P-Frames) : 242024
Total Number Of Frames : 245580

1.45% of the Movie is Intra-Frames (Key-Frames)
98.55% of the Movie is Inter-Frames (P-Frames)

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

1-Pass Size : -2067523839 Bytes or 2175237 KBytes
Scaled Size : 1600604196 Bytes or 1563090 KBytes
Actual Size : 1600608464 Bytes or 1563094 KBytes

Usefull Statistics
------------------
Compressibility : -77.42%
Relative Quality of XviD avi : 73.63%
Absolute Quality of XviD avi : 97.85%

MOTION SEARCH 5 ANALYSIS

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

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 77101 Times, Percentage Used : 31.40%
Quant 3 Used : 163949 Times, Percentage Used : 66.76%
Quant 4 Used : 4528 Times, Percentage Used : 1.84%
Quant 5 Used : 2 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 2.704

No credits encoding!!

MPEG Quantization Type Used 241050 timed, Percentage Used : 98.16%

H.263 Quantization Type Used 4530 timed, Percentage Used : 1.84%

Quantizers prevented from rising too steeply 0 times

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

Movie
-------
Quant 2 Used : 3279 Times, Percentage Used : 94.63%
Quant 3 Used : 186 Times, Percentage Used : 5.37%

Credits
---------

Number Of Consecutive I-Frames : 54

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

Movie
-------
Quant 2 Used : 73822 Times, Percentage Used : 30.49%
Quant 3 Used : 163763 Times, Percentage Used : 67.64%
Quant 4 Used : 4528 Times, Percentage Used : 1.87%
Quant 5 Used : 2 Times, Percentage Used : 0.00%

Credits
---------

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

Number Of Intra-Frames (Key-Frames) : 3465
Number Of Inter-Frames (P-Frames) : 242115
Total Number Of Frames : 245580

1.41% of the Movie is Intra-Frames (Key-Frames)
98.59% of the Movie is Inter-Frames (P-Frames)

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

1-Pass Size : -2061941988 Bytes or 2180688 KBytes
Scaled Size : 1600604041 Bytes or 1563089 KBytes
Actual Size : 1600607470 Bytes or 1563093 KBytes

Usefull Statistics
------------------
Compressibility : -77.63%
Relative Quality of XviD avi : 73.95%
Absolute Quality of XviD avi : 97.89%

I also did a divx5 encode and will visually compare all 3 and report back
(are you still interested as I know there is another build out)

Seems that Search 5 gives more quant 2 overall (but fewer quant 2 i frames)
Both give 2 frames with quant 5
Pretty saturated I guess so maybe not the best test....

Andy

AndyP

8th August 2002, 18:37

Sorry for another post. :) Am I correct in saying that a diamond search pattern or a square pattern can be applied to either PMVFast or EPZS algorithms (so in effect there are 4 combinations to test between the 6/8 and 8/8 builds with motion search 5 and 6)?? :confused:

Andy

dread

9th August 2002, 08:33

I've encoded Gladiator R2 yesterday... here are my results:

Headed for 2*700mb + MP3 128kbit.
Codecs: Divx 5.02 Pro and Xvid 08082002.

For divx5 I used Gknot defaults, pro features off
For xvid:
Motion Search: 6 Ultra High
Min/Max i-frame interval: 1/250
H263 for 1stpass and Modulated 2ndpass
SCD threshold: 50%
Min/Max i-frame quantizer: 2/4
Min/Max p-frame quantizer: 2/8
Alt Curve: Low Aggression - Low/High 100/200
lumi masking off
hinted ME off

Credits in both codecs encoded with quant 30.

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 18222 Times, Percentage Used : 8.54%
Quant 3 Used : 161489 Times, Percentage Used : 75.66%
Quant 4 Used : 32926 Times, Percentage Used : 15.43%
Quant 5 Used : 796 Times, Percentage Used : 0.37%
Quant 6 Used : 10 Times, Percentage Used : 0.00%

Average Quantizer Used for Movie : 3.076

Quantizers Used For Credits :
--------------------------------
Quant 30 Used : 9414 Times.

MPEG Quantization Type Used 189125 timed, Percentage Used : 84.86%

H.263 Quantization Type Used 33732 timed, Percentage Used : 15.14%

Quantizers prevented from rising too steeply 0 times

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

Movie
-------
Quant 2 Used : 2450 Times, Percentage Used : 93.19%
Quant 3 Used : 137 Times, Percentage Used : 5.21%
Quant 4 Used : 1 Times, Percentage Used : 0.04%

Credits
---------
Quant 30 Used : 41 Times, Percentage Used : 1.56%

Number Of Consecutive I-Frames : 72

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

Movie
-------
Quant 2 Used : 15772 Times, Percentage Used : 7.16%
Quant 3 Used : 161352 Times, Percentage Used : 73.27%
Quant 4 Used : 32925 Times, Percentage Used : 14.95%
Quant 5 Used : 796 Times, Percentage Used : 0.36%
Quant 6 Used : 10 Times, Percentage Used : 0.00%

Credits
---------
Quant 30 Used : 9373 Times, Percentage Used : 4.26%

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

Number Of Intra-Frames (Key-Frames) : 2629
Number Of Inter-Frames (P-Frames) : 220228
Total Number Of Frames : 222857

1.18% of the Movie is Intra-Frames (Key-Frames)
98.82% of the Movie is Inter-Frames (P-Frames)

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

1-Pass Size : -2136428247 Bytes or 2107948 KBytes
Scaled Size : 1302181967 Bytes or 1271662 KBytes
Actual Size : 1301937534 Bytes or 1271423 KBytes

Usefull Statistics
------------------
Compressibility : -60.94%
Relative Quality of XviD avi : 65.01%
Absolute Quality of XviD avi : 96.77%

Used quantizers in movie: 2-6 for xvid and 2-5 for divx5.

My impressions ?

Most of the scenes were identical... of course xvid in many many scenes is much more detailed, look at these screens: xvid (http://free.polbox.pl/d/dread/xvid/xvid1.jpg) and divx5 (http://free.polbox.pl/d/dread/xvid/divx1.jpg). This is an i-frame with quant 2 in both codecs.

Next scene - for xvid, i-frames were encoded in most cases with quant 2 or 3, for divx5 it's 3 or 4, some i-frames were even encoded with quantizer 5. Results ? Look at that: xvid-q2 (http://free.polbox.pl/d/dread/xvid/xvid3.jpg) vs divx5-q4 (http://free.polbox.pl/d/dread/xvid/divx3.jpg).

Next scene - for xvid i-frame gets quant2 for divx5 quant4, this is a screenshot 10 frames after i-frame:xvid-q3 (http://free.polbox.pl/d/dread/xvid/xvid4.jpg) vs divx5-q3 (http://free.polbox.pl/d/dread/xvid/divx4.jpg).

Divx5 not always recognize scene changes - number of i-frames: 2629 (xvid) and 1957 (divx). This is the scene where divx5 didn't put an i-frame - xvid-q2 (http://free.polbox.pl/d/dread/xvid/xvid2.jpg) vs div5x-q2 (http://free.polbox.pl/d/dread/xvid/divx2.jpg).

Unfortunately imo divx5 produces much more pleasing eyes quality with high quantized p-frames. Some scenes with quant 4-5 are very blocky with xvid - xvid-q4 (http://free.polbox.pl/d/dread/xvid/xvid5.jpg) vs divx5-q4 (http://free.polbox.pl/d/dread/xvid/divx5.jpg) and xvid-q4 (http://free.polbox.pl/d/dread/xvid/xvid6.jpg) vs divx5-q5 (http://free.polbox.pl/d/dread/xvid/divx6.jpg).

Koepi if u could do something with that xvid would be outstanding. This is not a big problem - there are only 15% of frames with quant <4, and about 10-15% of them looks very ugly, but...

serbersan

9th August 2002, 09:08

Okay, I've done several rips of Shallow Hall 1:45min without credits at all.

I can't put the whole analyze.txt of the movies only some values. The rips I made are done with two builds:
1.- PMVFast (uManiac's XviD.Alpha.07.08.2002.1020)
2.- EPZS (with new (old) lumi masking)

The same setting for both:
Lumi in both passes (sorry I know is buggy with epzs but the movie is difficult to fit in 1 CD with acceptable quality)
1 pass:
H.263, ME = 6
2 pass:
Modulated, ME = 6
All other default values.

Resolution 576x304.

1.- 1378Mb (first pass size)
52.64 Relative Xvid Quality
Average quantizer 3.78
final size 645.xxx kb
2.- 1379Mb (first pass size)
52.67 Relative Xvid Quality
Average quantizer 3.80
final size 646.xxx kb

I don't have more information at the moment I'm at work.

About visual quality:
I think the quality isn't good or at least for my taste the quality isn't "constant".
Many blocks in motion zones of the scene in both builds, but in general I prefer EPZS results, at least the backgrounds are less blocky more real.

Other thing that I've seen is what I have said, some scenes have pretty decent quality but others don't have nothing.

I've attached some images to compare between PMV and EPZS. See and compare yourself.

Marc FD

9th August 2002, 09:30

If the quantizers are the same, you wouldn't see differences between PMVfast and EPZS. It's ME , not quantization...

rui

9th August 2002, 14:03

I made some small tests again, trying to compare the motion search engines.

I used Koepi's latest to represent EPZS, and uManiac's latest, in motion serach 5 to represent advanced diamond, and motion search 6 to represent square search.
All configs were equal between builds (all default except motion search 6 in the 1st two tests, and lumi enable, using default cc., h.263 for 1st pass and modulated for 2nd), except in Koepi's i used his motion detection treshold with a value of 35% (more key-frames, like Koepi said above, correcting my mistake :))

Koepi - average quantizer- 7,095 - 143 i-frames representing 4,01% of the test.

uManics with motion 6 - average quantizer - 7,068 - 138 i-frames, representing 3,87% of the test.

uManic's with motion 5 - average quantizer - 6,972 - 138 i-frames, representing also 3,87% of the test.

So, in theory, koepi should be the best, at least with the subject material. In practice, i can also confirm that Koepi's avi was a tiny bit more detailed, but the diference between EPZS and square motion search ins't so big like it used to be. Motion 5 (advanced diamond) on the other hand can't compete with the other two, IMHO. The resulting avi was noticeable more smoothed than the other two.

This, of course, comparing freezed frames, in motion would be very dificult to see any diference. ;)

I end this saying that i still have to experience any incompatibilities using lumi with EPZS. Maybe in my next test they will appear, but for now...

EDIT: I made another small test, using Koepi's build, with the same settings as above, but this time choosing the treshold at 65% (less keyframes). The average quantizer was 7,099 (better), and the number of keyframes decresead from 143 to 114. In theory, this latest config was the best.

This makes me think: the subject material was a fast trailer (from the movie The Replacements), with lots of scene changings. So, in the config were i tried to decrease the number of keyframes inserted at scene changes, was the best.

So, the scene treshold was created to prevent the increase of keyframes in movies with lots of scene changes, correct? I mean, assuming that my conclusion is correct, in a movie with lots of scene changes, is best to increase the scene treshold, correct?

What you guys think?

int 21h

9th August 2002, 17:18

I think the keyframes at scene changes currently aren't inserted enough, and this exhibits itself by frames of blockiness after a scene change or fade out/fade in (<-- something I talked about a long time ago).

soujir0u

10th August 2002, 09:29

I just encoded a shot clip (Chage & Aska - On Your Mark) with Koepi's latest build (08082002-1), and the results were incredible! Of course, I used a pretty high bitrate, so that was to be expected. :D

Avisynth filters used (before resize): TemporalSmoother(2,1)
Resolution: 608,328 (Neutral Bicubic)

Motion search precision: 6
Both passes: MPEG quantizer
Max I-frame interval: 240
I and P frame quantizers: Min 2 Max 4
Other values at default
No credits encoding

Quantizers Used For Movie :
------------------------------
Quant 2 Used : 3376 Times, Percentage Used : 35.06%
Quant 3 Used : 5988 Times, Percentage Used : 62.19%
Quant 4 Used : 265 Times, Percentage Used : 2.75%

Average Quantizer Used for Movie : 2.677

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

Movie
-------
Quant 2 Used : 113 Times, Percentage Used : 83.09%
Quant 3 Used : 23 Times, Percentage Used : 16.91%

Number Of Consecutive I-Frames : 5

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

Movie
-------
Quant 2 Used : 3263 Times, Percentage Used : 34.37%
Quant 3 Used : 5965 Times, Percentage Used : 62.84%
Quant 4 Used : 265 Times, Percentage Used : 2.79%

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

Number Of Intra-Frames (Key-Frames) : 136
Number Of Inter-Frames (P-Frames) : 9493
Total Number Of Frames : 9629

1.41% of the Movie is Intra-Frames (Key-Frames)
98.59% of the Movie is Inter-Frames (P-Frames)

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

1-Pass Size : 190198249 Bytes or 185740 KBytes
Scaled Size : 132781598 Bytes or 129669 KBytes
Actual Size : 132783553 Bytes or 129671 KBytes

Usefull Statistics
------------------
Compressibility : 69.81%
Relative Quality of XviD avi : 74.71%
Absolute Quality of XviD avi : 97.97%