my (small) tests showed that it doesnt preserve sharpness as xvid does, it was only a small test, but enough to drop the idea of using it

but imho the capture is simply noise,

Another thing I noticed about your ffvfw clip is that the first frame is bad.

i4004, those ME problems you claim to have spotted - you know that nobody ever managed to reproduce them.

Otherwise please stop spreading that rumour of an 'XviD-ME problem' on this forum, too.

Your statements on the quality of diverse codecs seem very poorly rooted in facts and thus I personally think it is a shame if you doubt Doom9's painstakingly accurate way of conducting his tests.

Also, I can't tell them apart in a "blind test."

I there are a couple of things that exhibit bad performance for ME in all mpeg4 codecs that I have seen.

At any rate almost all the noise gets removed and consequently a lot of detail.

I tend to believe though that it is not a ME problem though and certainly ffvfw does a little bit better on this kind of material than XviD does.

If you are going to be doing a lot of encoding to ffvfw, the standalone ffmpeg might be a better choice since it doesn't have this issue. If you like a can provide you with a build, just PM me

Usually (and sensibly) one applies a noise-filter.

Surely you haven't been banned from doom9.org for no reason.

Hey I was sugesting it simply because you gave me nothing to go on. And they do produce exactly the same swimmy effect. But you still have yet to prove it is a bug rather than simply a different way of doing ME. Simply say you do not preffer the effect that is fine and respectable. Before you call it a bug outright you need a good deal more proof.

"It doesn't. You have problems with Xvid. Xvid is fine. Though I must say I am very pleased by recent ffvfw builds. Very nice."

this is my experience;
I HAVE SEEN "swimmy effect " on ffvfw when b-frames were on!
it was a scene in music video and (funnily enough) the sea was "swimming"..i have the clip,and i can easily show this,and reproduce this....
it was a aug.16 2003 build,and i'm NOT satisfied with interlaced encoding efficiency either....mpeg2 beats it in that respect....(on same bitrate)
i hope these two issues are improved upon (but really,i can't be checking every release of every codec....i hope he solved it already,as you hinted...at least "b-frames swimming"....but if you do toons only,then don't consider that you checked it....also,i usually use MPEG quant.matrix....but as with xvid,h263 had swimming too....)

you didn's saw this
"don't inform me how ffvfw does a max. quantizer on 1st frame..i know about it,i don't mind that..."

if neo-neko saw it,didee saw it,i saw it,who are you to discredit our findings?
(perhaps it's only indicative that all of us (ie.neko,didee,and i) do tv-capturing...perhaps not....i know how xvid acts on my tv-rips ,and i'm not pleased with it..)

es,i agree..neither can i!
so then,i have done my part!
you can't tell which is which and therefore you can't say which is xvid,ergo,you can't say which is better.....!!!

neko called it "swimmy effect",and that's a good choice of words too!
i believe we talked about same sort of artefacts....(it seems he saw it on encoding manga,as he does toons..)

i completely disagree on this one;you should investigate what "quantizer" settings do for a codec!my dust/smoke looks OK...low-light scenes look OK here too...

should i test xvid on moto-racing?
yes or no?

Sometimes a wall is static but moves (because of prediction or because of luminance changes), but sometimes a wall actually moves. Current ME has no way of distinguishing between the two...

My idea of detection: if total high-frequecy energy in a block is lower than total high-frequency error, the block is "bad" (ie block is flat in original, but appears "noisy" after motion compensation, with total noise bigger than total texture).

Quote

(i4004 @ Sep 7 2003, 02:45 AM)
.....and that's real easy to see.....ME problems go ON TOP of that....

Seriously where? I am not blind. But I have never seen it.

The burden of proof is on you man. So ante up. If you can even remotely prove half of what you claim I would be surprised and interested.

Buggy meaning that it is not a bug as you call it but simply that you do not preffer it. You have yet to even point finger one at any sort of bug.

"In your mind". IE not any sor of solid proof. Because in my mind it is exactly the opposite. That is the funny thing with minds.

The swimmyness was rather uniform but the image over all did retain it's shape nicely. Anyhow chalk it up to early MPEG quant implementation.

Quote

(i4004 @ Nov 9 2003, 01:24 PM)
see,THAT is a lie.....i have proved to you that xvid has issues

Does it? Last I checked you simply preffered MSMPEG4's more static ME with the risk of texture smearing to that of Xvid which can have a slight swimmy effect in large solid color areas when datarate dips. Is it really wrong? Or do you simply just not like it?

Ok first of all, lets not make this discussion personal

The XviD team is extremely receptive to finding ways to make the codec better.

Yes, I can't say which is better so yes I suppose you have accomplished what you wanted to.

You will also notice that I agreed whole heartedly later in the thread.

Ok, I can encode at constant quant 2 and it will still look very bad IMO, quant 1 is better of course.

The trouble is that we simply do not know if it is a ME bug or anything.

Absolutely, if there is something wrong we want to know about it.

Concerning Didée agreeing with you (in that thread): He does not. What he his talking about is known as 'moving walls effect'. Its probable reasons and possible cures were summed up by sysKin in an answer to Didée in that same thread:

3.
"Tearing motion":
Imagine you have a pretty dark scene. Something in the foreground is in focus, the background is almost flat colored (black sky, e.g.).
Now, if the thing in the foreground starts moving, the background starts moving also (!), as if it was "teared" by the foreground object.
This should be resolveable by a more sophisticated creation of motion vectors (don't create and trust predictors too blindly). However, that's faaar beyond my horizon.

The look that you don't like about XviD is the effect of extreme noise in a static are which cannot be distinguished from motion and also quantizes very badly.

(don't create and trust predictors too blindly).

The only sane thing is to use spatial/temporal noise-filters because they can and should distinguish between noise and motion.

And MPEG4 by its layout does not do prefiltering or in-loop filtering, either.

What Didée and sysKin talk about is a flat-coloured (preferably dark, as Didée describes it), still area which seems to move around the contours of a moving foreground-object.

The floating is more pronounced with ffdshow than with xvid.ax.

If you had properly noise-filtered your source and that 'tearing motion' would have appeared, you could attribute it to that 'moving walls'-effect. Try it and we shall talk again.

Note that MPEG1, MPEG2 and mpeg4 are very close. MPEG4 gives only
marginal improvements to MPEG1 (10 or 20%).

I respect that you don't like how XviD treats noise but I cannot let it pass if you wrongly call it a 'bug' of its motion estimation. Simply because it is not. Full stop.

something to be improved, not something broken.

Though the difference is just a gradual one: whether something goes wrong absolutely (inverted-luminance macroblocks should never happen) or just has a tendency to look wrong (sometimes XviD has difficulties distinguishing luminance fluctuations from motion).[/

More importantly, you use references to strengthen your point that actually weaken it. In the threads you link to, Neo Neko did not agree with you.

QUOTE 
The swimmyness was rather uniform but the image over all did retain it's shape nicely. Anyhow chalk it up to early MPEG quant implementation.


I whole-heartedly agree with Neo Neko here.

Neo Neko does not talk about ME at all but rather about not having the time to talk about it. And the same goes for the continuation of that thread.

This is what makes for the high level of discussions on forum.doom9.org and enforcing a fact-based argumentation is what keeps doom9.org a place for these users.

Your way of incoherent argumentation

And we won't have that.

Last not least it is a disgrace that you should misuse the reputation of people like Neo Neko.

thanks!i appreciate it!(also,you can't tell nandub apart from others,can't you?  )

nope,it isn't.....nic said(way back) that "they will fix it if they find it to be a problem" (ie. he says xvid is essentially ok,and i'm essentially a nut...  )

but why don't u use ffmpeg's motion estimation engine?blow to xvid team's pride?well......i would give up if i can't make something work in what...2-3 years?

i did wmv9 and it's obvious it has inloop stuff...so i'm eager to see h.264..it has been said it has it too,but i hope it can be turned off manually!

i do too(about "early implementation) i don't agree that "shape is retained"...it's not,it's messed,background is swimming heavily,and it's tearing(if this is his comment about xvidME clip....)!

most certainly WON'T!
you fail to grasp the most important thing;read my lips:
FFVFW AND NANDUB DON'T EXHIBIT SUCH POOR BEHAVIOUR ON MOTION!!!
OK?

i WON'T ASK OF YOU TO TELL ME IF SOMETHING IS LOOKING GOOD OR NOT!be aware of it!i have eyes too,you know....

who's "we"?are you a mod here too?
let me telly ya,buddy;i'm not afraid of you and i'm not afraid of your threats;i will be only glad to be thrown out from the forum that is threatening because i don't like some of the xvid's stuff!!!
ONLY GLAD!!!
keep you mod threats for doom9..they are well thought of there!

remember..the codec that does *noisy* video well can do anything!

I would suggest that you use a denoiser for your next test (BTW, what Peachsmoother settings are you using?), so the codecs are tested under more "normal" (as you would use them "everyday") conditions.

#peachsmoother(readout = true, dot = true)  #noise estimation

#noisy novatv
#peachsmoother(noiselevel=7.876,baseline=6.101,NoiseReduction = 60, Stability = 30, Spatial = 100)
#poor vhs 3rd rock
#peachsmoother(noiselevel=4.138,baseline=2.761,NoiseReduction = 60, Stability = 30, Spatial = 100)
#vhs ep+blends
#peachsmoother(noiselevel=4.201,baseline=2.813,NoiseReduction = 60, Stability = 30, Spatial = 100)
#vhs ep big one
#peachsmoother(noiselevel=4.286,baseline=3.141,NoiseReduction = 60, Stability = 30, Spatial = 100)

#peachsmoother(noisereduction = 75, stability = 20, spatial = 85)

I think there was a clear difference in your arte-screenshots (linked in another thread) between Xvid and ffvfw, I would like to see a clip more like that, i.e. that shows the same deficiency.

tommy,any wavelet style codec acts as blur filter(vp6,rv9,rududu) so noisy stuff gets to be denoised...