Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: ffvfw versus xvid_QPEL test.... (Read 15047 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ffvfw versus xvid_QPEL test....

Reply #26 –
uuhhmm?
they discussed GMC there with very lil mention of normal MC/ME...

although there was this:
Quote
Thank you for your response, gruel! It sounds reasonable. When it comes to annoying artifacts due to poor motion compensation, it's usually in terms of moving objects in the scene (such as two fighting ladies eagerly kicking eachothers heads off), where global motion estimation doesn't have much to offer. Right? Large pans probably only exist for a few frames and won't considerably hurt the result, since it will probably end with an I frame.

by Celebrandil

also; i never used GMC in my tests....

ffvfw versus xvid_QPEL test....

Reply #27 –
No read further this is what gruel said,
Quote
Of course there are many things left to do. E.g. special B-frame ME is still very little done for. At the moment, it's more or less just the P-frame version, but searching in both reference frames.

What I also still see as challenging is the combination of ME and Mode Decision. MPEG-4 or at least XviD profits much less from INTER4V mode than I would hope for. When to use SKIP mode instead is important for encoding efficiency, too.

A big problem lies also in the nature of how we judge "quality" of a motion vector. At the quality level which XviD is most often used for, SAD or SSE is not as reliable as it could be. E.g. in very uniform background, a vector with low SAD value doesn't have to _look_ better than one with higher SAD, because the eye is very sensitive to "artificial motion" or "wobbling walls" etc.

Editing effects is another problem of ME, in particular fades or dissolves, or scenes with changing lightning (explosions), which very easily turn blocky.

ffvfw versus xvid_QPEL test....

Reply #28 –
oups,missed that;yes,you're right......

ffvfw versus xvid_QPEL test....

Reply #29 –
Quote
Xvid doesn't handle noise well, but it was optimized for clean sources. It shines there and the annoying floating background rarely occurs in that case. FFVFW and SBR are more error-tolerant, so the artifacts are less annoying, but on clean source, xvid is really better than them (and this is not assumption, but experience ), because it is specialized for encoding DVDs, while the other codecs are more for general use.

this stuff was *constantly* on my mind;i asked myself again and again:can it be that the codec that does noisy stuff well(divx3,ffvfw) will be worse(in encoding a clean source) than a codec that does noisy stuff in a lousy way(xvid).....

it didn't really clicked in my mind;expected behaviour would be to expect same or somewhat better performances from a codecs that also do noisy stuff better....

recently(10-15 days ago) i got dvb receiver,and therefore,a source of much cleaner video than analog sources.....
the signal is still capped via bt8x8 capture card(@768x576),but there's no noise to talk about anymore....

so i stacked xvid(RC4) against divx3 once more......
it is 1,8mbit/s,1pass,p-quant 2-7 comparison....
xvid has all the "advanced" options turned off(ie qpel,gmc,adaptive quant.,b-frames..etc.),highest motion search precision("6"),vhq off....
divx3 doesn't have any of these options(    )..divx3 is used via nandub,xvid used via vdub 1.4.10.....

looking at both clips at 25fps,viewer will have enormous problems in differentiating the two..i think that even experienced encoders couldn't tell these two apart....so one thing must be said;nandub encodes faster:my previous tests with xvid RC4 showed that nandub is considerably faster even if i turn off vhq and bring motion search precision to "5"......

again,my logic was ok;it would be unexpectable to see a codec that does a poor job on noisy sources to do completely opposite(ie excellent) on clean source....(because divx3 will also profit from a clean source!)

now everyone asks,wtf didn't i used advanced options of xvid?
there's only one answer;speed.....
i'm looking for fastest and best encoder....not slowest......i encode a lot of stuff and i can't afford a slow codec...
also,i already did qpel test,and i didn't convert to qpel at all....gains in quality aren't that big so qpel would pay-off.....
(i tried to employ other options too,but none of them is a magic that will make xvid look awesome....or,to say it differently, visually better than divx3)

in other words,if nandub is doing 25fps encoding,and xvid is doing 20(or less) while image quality is such that i can't differentiate the two,i will use faster encoder....
that is the simple rule i follow;if quality is equal(or differences are so small that i can't differentiate the two) i will use faster encoder...as simple as that....

in this respect xvid is not a clear winner at all;it is
1-slower than nandub
2-it doesn't produce better looking images(when we match the settings of xvid to nandub's...match it because we wanna see if xvid is faster or not)

i need either same speed(as nandub) and better image quality,or same quality(as nandub) and faster encoding....(or,offcourse,both at the same time)


i will be more than happy if someone can provide an xvid settings that will result in one of these conditions fulfillment....(one will be quite enough)

DivXc32.dll [ 01.04.2000., 5:35:06 copyright microsoft corp.1996-1999.,cracked by gej]
xvidcore.dll[ 05.04.2004., 7:36:48  copyright ???]


grab some images here
http://kotisivu.mtv3.fi/ii00i/xvid-rc4/xvid%20rc4.rar (1,16mb)

to connect this to ffvfw too(as it's in the thread subject...hehe) see this (again)
http://i4004.bizhosting.com/ffvfw_the%20quest/
 

ffvfw versus xvid_QPEL test....

Reply #30 –
Newer versions of XviD compiled from the branch which will eventually become 1.1 perform somewhat better on noise now since sysKin added a better skip detection.  So a lot of the unpleasant artifacts such as the moving walls are much less.  Also, you might think that with skipping more macroblocks less noise will be preserved; IMO this appears to not be the case.  The human eyes seem to react much more positively to sort of uniform random noise rather than unnatural noise such as the moving walls effect.  Also on a unrelated note, I am curious as to how or why XviD is slower than nandub.  But then again I never encoded with nandub much however I remember divx4 was noticably slower when it came out.  XviD with fast first pass activated should be very fast.  I can get about 30-35fps with fast first pass on p4 1.8ghz.  By turning everything off like you did, you should get about the same as fast first pass.

ffvfw versus xvid_QPEL test....

Reply #31 –
the problem with noise is such;if you master an old movie onto dvd,it has noise....so it's not like xvid can now be called "dvd-rippers codec" to full extent......that is the biggest problem i see with xvid....it's not universal codec...and after all we cannot influence our sources that much....if we have dirty sources,they still need to be encoded...me and wilbert did our best to clean some noisy source enough so that xvid likes it,but we failed.....still we saw typical xvid/divx5 problems....

i indeed believe that xvid works totally acceptable on clean sources....
in this test,i didn't notice any xvid/divx5 noise problems...(as there's no noise)

Quote
The human eyes seem to react much more positively to sort of uniform random noise rather than unnatural noise such as the moving walls effect.

i've been saying that ever since i saw my first xvid encoding...
that sort of handling noise is unnatural..i doubt this is an intentional flaw,as no one would intentionally make such mess...i see it more of an problem that stayed with xvid longer than it should of....

Quote
Also on a unrelated note, I am curious as to how or why XviD is slower than nandub

i think this can be attributed to divx3 being of microsoft origin....
back when it was written,it needed to be fast as it was run on slow machines....now it's speed just exploded....while xvid was never that heavily optimized......nandub was always faster......regarding that issue,xvid team should also learn from ffvfw,as ffvfw can be setup in a way to match nandub's speed......
(ffvfw source also holds an answer on how to handle noise properly)

speed again;in that speed test i talked about,where i set the motion search precision to "5",i was already starting to see xvid's performance deteriorate in comparison to nandub's....decreasing it further would probably result in xvid being closer and closer to nandub if we look at speed,BUT by the time it went as fast as nandub,it would look much worse.....
(in my mind already on "5" it looked worse....nandub was cca. 5fps(!) faster against such xvid setup...i was encoding some lores video;nandub went 25 and xvid 20fps...)