XviD-08032003

[birdy]

Originally posted by Koepi
@birdy, ffroms:
READ syskin's post. I mean it. (It's the 2nd post in this thread. Right on the first page. I hope I don't need to guide you to the small "1" link next to that "page"-word?)

I'm not going to write a huge rant now - USE the search, train to use it.

Some rant made it into this post - no need for that, deleted.

@all:
Since some people don't care to read what's written about the bframes threshold thingy and THEN even start complaining about it, I'll try to remove it ASAP. One more unpleasant example of why XviD is still not where it should be - if we want to test things and it's visible und usable for everyone, there are always clueless newbies which are trying to use things which they should leave their hands off.

Regards
Koepi

What's the problem with you man?!
Do you understand english? do you get my question or SHOULD I guide you to the small "1" link next to that "page"-word?
Go read it yourself and tell me what it says!
Here is a part of that message:

"- there is an extra value which controls the decision. Default is zero. Set to negative to have less bframes, positive to have more.
The value of about -100 will remove all bframes. There is no maximum, it all depends on the number of bframes you want to have. "

Dose it say yes or no that we can use negative values to have less bframes???

Well when I enter any negative value it dose not work and it gets reset to last positive value! Is this normal?

I wonder why you have to be agresive a rude everytime I ask a question?!
If this is an open source program and you have a public board then act the way you should and if you think that newbies should take of there hands from your work then don't damn make it public! Sit at home work with your own builds and enjoy your high iq and inteligence!

[Assault]

@Birdy

originally posted by Birdy
What's the problem with you man?!
Do you understand english? do you get my question or SHOULD I guide you to the small "1" link next to that "page"-word?
Go read it yourself and tell me what it says!
Here is a part of that message:

"- there is an extra value which controls the decision. Default is zero. Set to negative to have less bframes, positive to have more.
The value of about -100 will remove all bframes. There is no maximum, it all depends on the number of bframes you want to have. "

Dose it say yes or no that we can use negative values to have less bframes???

I think YOU didn't understand the text correctly because Koepi wrote
Set to negative to have less bframes and that means that if you set it to -30 you'll have less b-frames than if you set it to 0 and if you set it to -60 you'll have less b-frames than if you set it to -30. I don't think that it's very hard to understand.

Regards
Assault

P.S.: I can understand Koepi's reaction because even in a "public board" you can expect that people read the complete threads in which they post. If you read the thread you would know that it's simply a bug that negative values get reset to the last positiv value.

[birdy]

@ Assault,
Thats exactly what I understood and said! I understood that setting negative points ment less b-frames and as I was the 3rd person to reply to this topic, I reported this bug for the first time.

All I was saying is that I got the point about this setting. But it's not working with negative values! So I never asked what dose this option do or anything like this!

But from the first posting that I reported the bug I am beeing somehow criticised and ignored on this subject!

Here is my first posting on this subject:

"I am not sure if this part is working ok (at least for me! )
I set the b-frame threshol value to -50 and tried to do an encode.
But it was reset to "0" when I open xvid. Can you guys please test and see if same thing happens for you?"

Do you see anything stupid I said???

And here is the first Koepi reply to it:

"Not confirmed, set to 50, rebooted and everything, stays 50. " !!!!

[ffroms]

That is the same thing here. I readed that you have to use negative value to have less Bframes but it does not stay negative no matter what you do. So there is still no answer to that question. Maybe Koepi did overreacted to our question but again he didn't have to replay to it.

FFS

[Koepi]

@birdy:
If you'd stay on topic it would be very helpful, but you want personal action? Gotcha, strike for rule no. 4. Finally learn to behave please.

You brought that problem to our attention, and the next release will fix it. So what's YOUR problem? Is it THAT important to use less bframes? It's something to play with, sure, but I seriously doubt that it's this important that you need to be suspended for it as you're on a cruise battle there for it.

Koepi

[ookzDVD]

@Forum,

Yes, I can confirm that too,
entering a "negative" value to the threshold, it will be changed to the last positive value.

[Koepi]

ookz,

lemme guess, you want to provoke me too?

A simple yes or no suffices.

[kilg0r3]

Actually, I wanted to write something that would help everybody chill a bit. But now I can't think of anything. :( Just do it guys.

The current build seems to be great though :)

[NeVeRLiFt]

Hmmm :sly:

Just stated the build was slow.... slower, did not say nothing else.
I assume they already knew this.

As for XviD and quality, I feel XviD has great quality already and has better sharper IQ than DivX5 ;) it had this for a while now.

This is besides the point... but this build does not work for videocapturing either.


Just goes to show how people think around here... :eek:

[Shinobu]

This build is a good build, I've no bug with it other than the negative threshold.

There's a bug.... and what ?... this is not xivd 1.0, this is an alpha build, if you want no bug and can only be speed, stop using xvid!

Thank to man as koepi (and other xvid devel , don't forget them) xvid codec upgragre as often as possible, don't be speed, a good soft (codec or other) need to be made step by step or you will a poor soft.

I understand koepi, he work freelly on the world best free video codec (and the best of the best for me), and I think it's busy to only have complain form no devellopers users.

Remember there's a difference between help to find bugs and complain about bugs ...


GREAT JOB KOEPI ! might you continue to dev the xvid codec.

[sungey]

hmm i havent tried that bframe threshold yet ... but its hot in here ...

*pours water on everyone* ;)

from what i understand ... this build lets u use less bframe in still scene. Since bframe usually has higher quant than P and I frame... this will make still picture looks better (dark still pictures with 2-3 consecutive bframes suffers quite a big quality drop when the bframe quant is around 6-7, in my experience).

p/s : this is probably off-topic .. if the bframe formula yields 3.3 or 3.5 or 3.7 ... which quant will bframe be?

[NeVeRLiFt]

Originally posted by Shinobu
This build is a good build, I've no bug with it other than the negative threshold.

There's a bug.... and what ?... this is not xivd 1.0, this is an alpha build, if you want no bug and can only be speed, stop using xvid!

Thank to man as koepi (and other xvid devel , don't forget them) xvid codec upgragre as often as possible, don't be speed, a good soft (codec or other) need to be made step by step or you will a poor soft.

I understand koepi, he work freelly on the world best free video codec (and the best of the best for me), and I think it's busy to only have complain form no devellopers users.

Remember there's a difference between help to find bugs and complain about bugs ...


GREAT JOB KOEPI ! might you continue to dev the xvid codec.

LOL

/me hands hinobu a towel to clean his nose off with :D

[jarthel]

/me don't want less b frames. :D

[ookzDVD]

Originally posted by Koepi
ookz,

lemme guess, you want to provoke me too?

A simple yes or no suffices.

No.

I know sometimes people are just pushing the developer too much.
And sometimes people are too lazy too search the forum.

I apreciate kilg0r3's updating his page with found bug for the
current build.

PS. I just finish encoding 2 movies, with B-Frame 3/100/200,
Threshold=0, ChromaME, VHQ=1, and I'm really happy with result,
the wall is quite stable. :)

[sprit]

Originally posted by sungey
p/s : this is probably off-topic .. if the bframe formula yields 3.3 or 3.5 or 3.7 ... which quant will bframe be? From what I can see (from this post (http://forum.doom9.org/showthread.php?s=&threadid=45477)), the B-frame quantizer is calculated as:

((((past_quant + future_quant) * bquant_ratio) / 2) + bquant_offset)/100

where all variables are of the type integer. When doing calculations in C using integers, the fractional part is dropped -- 3/2 gives 1, 7/3 gives 2. In this particular calculation the fractional part gets chopped off at both divisions.

Example using "past VOP quant"=3, "future VOP quant"=4, ratio=150, offset=100:
3+4=7, 7*150=1050, 1050/2=525, 525+100=625, 625/100=6

[sungey]

ic ... i have seen that thread before ... but i was wondering if the results of that equation is rounded up or down using ceil() or floor() function... thanks for the reply.. :)

[leo_fischer]

If my understanding is correct, the variables involved are all integers, so when the calculations are performed, all fractional components are automatically dropped by the C Language as part of the calculation (as spirit pointed out, this is done with EVERY sub calculation, according to the precedence rules for the language.)

I assume that the complier will translate into an integer divide /multiply instruction, which will drop the fractional components (well, actually store the remainder in a separate register. )

The end result is like floor().

[Arcon]

i've just encoded something with this build. the result looks very good, but i've got a problem during playback: i can see keyframes. the colors seem to get darker at some keyframes.

this effect is not visible if i use virtualdubmod to decode these frames. but ffdshow and nic's latest(23022003) ds-filter give me the same results.

now i'd like to know if i might have done something wrong (no b-frames, but gmc+qpel, vhq=0) or if i just have to wait for a later build from nic.

edit:

i tried some different builds and it seems that only the ds-filter from XviD-17022003-1 is free of this effect. since this filter is pretty small, i assume that it uses xvid.dll for decoding. the strange thing is that i get a correct display even with the older codec from XviD-17022003-1 but not with the newer ds-filter XviD-Dec-230203 from nic, which should be at least as compatible as the 17022003 build from Koepi?

if anyone wants a sample or some more infos about my codec-settings before he can tell me to RTFM, please tell me ;)

[Koepi]

It's the effect of qpel+simple idct.
qpel can only be done correctly with simpleidct, which is why i use it in my builds. Decoding with the old xvid-idct can result in what you see.

That's why decoding with xvid.dll works correctly. Did you setup ffdshow to use simple idct?

Regards
Koepi

[Arcon]

>Did you setup ffdshow to use simple idct?

it happens with all idct's ffdshow 20030103 has to offer. since i find it hard to describe the problem, i'll post 4 pics, 2 called original_* which show the way xvid decodes it and 2 pics that are taken from nic's dsfilter output. if you switch between both pairs you'll see what i mean.

original_before.png (http://home.wtal.de/nagel/xvid/original_before.png)
original_after.png (http://home.wtal.de/nagel/xvid/original_after.png)

before.png (http://home.wtal.de/nagel/xvid/before.png)
after.png (http://home.wtal.de/nagel/xvid/after.png)

sorry for the large png-files.

[Bulletproof]

It seems koepi's latest build has something wrong with Qpel, however I'm not sure whether its on the decoding or encoding side. I'm seeing alot of smearing. I'm not using FFDshow, I'm just using the decoder included with koepi's release.

[Koepi]

(...which is Nic's decoder btw., and not the CVS decoder which uses xvid.dll.)

Regards
Koepi

[Menion2k]

This build crashes or hangsup the system for me. The try is with, VirtualDubmod latest CVS, Avisynth 2.5.1 official beta, MPEG2 stream imported with all 3 MPEG2 decoder plugins (MPEG2Dec, MPEG2dec3, MPEGDecoder) Qpel, Chroma, Bframes (tried several settings), VHQ=1, Quality=6, and several matrix. Bye!

[kilg0r3]

Originally posted by Menion2k
This build crashes or hangsup the system for me.

If you have a P4, first disable the sse2 optimizations in the debug tab of the encoder settings. then kick yourself for not having read the thread before posting.

If the the above does not apply, you might have found a bug, but, for crashing, cpu type, os, etc. are relevant info, which you haven't provided.

[Menion2k]

I read all, and yes, I manually sets up the correct ASM code extension. Sorry for missing information:

CPU: Athlon 2700+
S.O. WinXP Pro+SP1
RAM: 512Mb DDR 333Mhz
Mobo: Gigabyte GA-7VAXP

Bye!

[Arcon]

Originally posted by Bulletproof
It seems koepi's latest build has something wrong with Qpel

i get the same effect if i encode that scene without gmc and without qpel :(

edit:

and i also get this if i encode it with the older XviD-17022003-1 build. the only way around this effect seems to be to use koepis xvid.ax instead of nics.

and with the older decoder from nic (XviD-Dec-291202) it looks even more extreme:

played with XviD-Dec-291202 (http://home.wtal.de/nagel/xvid/oldernics.png)

one can see that there is a smearing effect during the camera movement that changes colors. at the keyframe the picture gets reset to the normal colors, therefore the visible break. in the newer build of nics ds-filter this effect isn't that extreme so that one can still see the keyframe but not the smearingprocess itself.

[bond]

Hi guys!

i found out that koepis 080303 build results in a very low compressibility compared to previous builds (~20% lower if i load the .stats files in gknot)

settings:
msp: 6
quant. type: h.263
vhq: 4
lumi, qpel, cm
max. b-frames: 3
everything else on default...

i guess this has something to do with this:

Originally posted by sysKin
- it doesn't put as many bframes (with default setting). I think that it's much more safe, and _should_ produce better overal quality. BUT it also means that size of first pass, or average quant reported by debug info, will be _bigger_. Please don't complain about it, but check final quality instead.if i analyse the .stats files with xvid stats viewer koepis 080303 build uses ~1700 b-frames less than older ones on my 5 min test clip - with no visible in/decrease in quality (although i always loved to have a compressibility rate of 80% for a 1cd encode of "matrix" :( )

just wanted to share my experiences

[Nic]

I updated my build and dshow on my site: http://nic.dnsalias.com

Hope this helps,
-Nic

[Arcon]

>Hope this helps

sorry, but it's still there. no difference to the XviD-Dec-230203.

in contrary to koepi's ds-filter, you do some postprocessing even if none of the checkboxes is selected, right?

since i don't get the effects even with the older xvid.dll together with koepis ds-filter, it might be a result of the post-processing.

[unplugged]

Yes Nic, your build fixes A LOT,

I haven't tried more but most smearing effect (I think all) is gone, there should be some big problem with Koepi's 08/03 build... don't kwow what, only devs can say...

Update:
08/03 build's smearing is visible with its xvid.ax decoder and ffdshow-20030103 without xvid.dll decoding option (simple iDCT).
Smearing is not visible in VirtualDub and anyway when decoding works with its xvid.dll.
BUT, after uninstalling this build and installing Nic's 16/03 build, test clips made with 08/03 show smearing in any situation, even with VirtualDub.
The latter build with its produced clips doesn't produce smearing with its bundled xvid.ax and with VirtualDub (xvid.dll).
(ffdshow-20030103 with simple-iDCT and without xvid.dll checked always shows smearing with these builds)

I have tested XviD with QPel, chroma motion, BF=-1, VHQ 0 and 4.

What hell is happening? :scared:
Which decoder can we trust to test these damn clips and check how encoder works??
ffdshow(simple-iDCT) / ffdshow(xvid.dll) / xvid.dll / xvid.ax / mpeg4-player /... ?

[Arcon]

Originally posted by unplugged
I haven't tried more but most smearing effect (I think all) is gone, there should be some big problem with Koepi's 08/03 build...
since i get this also with the older xvid-build, i'm still not convinced that it's koepi's build who causes the problems instead of nic's ds-filter...

[kilg0r3]

I did some short tests with vhq and qpel with fixed quantizer 4. I was inspired to do this test because of moving wall/sky artefacts in a two pass encode with Qpel and VHQ4 which i recently did.

In short: VHQ 2-4 create moving wall/sky artefacts with and without qpel. However, Qpel seems to amplify the effect.

I don't know if this can be tuned or not but it would surely be nice.

@unplugged

keep calm boy. it is tyring to read through this emotional outbreaks, and, they don't help.

[BoNz1]

@kilg0r3, I did a rip today of Signs onto one cd and the effect that you described I am getting as well. The first time I did the movie I used vhq4, 1/4 pixel, b-frames 3,150,100,0, and luma masking. I always watch the first pass, because if it is bad, what is the point in doing another? Anyhow, the mosquito noise was really bad, unwatchable and this is the first pass I am talking about. What I ended up doing is using vhq4, h.263 quantizers, and b-frames 3,150,100,0. This seemed to combat the bad mosquito noise and blocking I experienced pretty well. I encoded a couple short clips and the effect is definitely worse with 1/4 pixel. Anyhow, I was pretty impressed the second time I did this movie, it looks good now.

[Arcon]

Originally posted by unplugged
Update:
08/03 build's smearing is visible with its xvid.ax decoder and ffdshow-20030103 without xvid.dll decoding option (simple iDCT).
[...]
Which decoder can we trust to test these damn clips and check how encoder works??
ffdshow(simple-iDCT) / ffdshow(xvid.dll) / xvid.dll / xvid.ax / mpeg4-player /... ?

did you try the combination of the actual xvid.dll and koepi's older xvid.ax (the small one, ~60kb instead of ~350)?

edit:

i just read that you tried it with ffdshow with xvid.dll-option which should do the same as the combination i mentioned above (if i'd seen this option earlier it would have saved me some time).

[Bulletproof]

I just downgraded to the last version (without the extra B-frame tuning option) and the smearing is gone for me. Koepi already said that it was Nic's older DS filter that was causing the smearing (which is used in koepi's latest release), I have not tried the updated one from Nic yet or tried replacing the current build's decoder with this one. But in any case the B-frames tuning is bugged (already known) so downgrading to this version doesn't set me back, and since its working fine I'll just stick to this one until the next build comes out.

BTW, if you're finding that the encoder isn't using enough B-frames then use the new tuning option, that's what it's for. I like using less B-frames.

However I'm still not sure how the tuning works exactly, currently XviD uses an intelligent method if inserting B-frames where they can be used with the least amount of consequence (I think), if you increase the new option, will this just force B-frames?

[PowerMacG4]

Today I did a rip of Memento. I freshly reinstalled Windows XP, fully updated it, and grabbed GKnot/Avisynth 2.51 beta/Koepi Xvid latest build. I use VirtualDubMod with newest exe. I know what I am doing, and I read this forum often.

However Xvid decided to ignore my settings. I have noticed that before, but I have never complained. First I loaded defaults. Then changed VHQ to Level 1, turned on Chroma motion, and changed nothing else. Bframes were set to -1 (yes, it was the correct field. and i did not change it). Now when I encode, I get b-frames even though it is disabled. (immediately after the encoding finished, i checked the configuration optinos, and bframes were still 'disabled'). There needs to be a more secure way of making sure the encoder listens to the vfw settings.


However, the rip looks excellent :-), I just do not like b-frames because I like playing movies on my 400mhz G4 in my room after I encode them on my PC.

[BoNz1]

@ PowerMacG4, try setting the b-frame threshold to -110 like described earlier in the thread.

[Didée]

Originally posted by unplugged
Update:
08/03 build's smearing is visible with its xvid.ax decoder and ffdshow-20030103 without xvid.dll decoding option (simple iDCT).
Smearing is not visible in VirtualDub and anyway when decoding works with its xvid.dll.
BUT, after uninstalling this build and installing Nic's 16/03 build, test clips made with 08/03 show smearing in any situation, even with VirtualDub.
The latter build with its produced clips doesn't produce smearing with its bundled xvid.ax and with VirtualDub (xvid.dll).
(ffdshow-20030103 with simple-iDCT and without xvid.dll checked always shows smearing with these builds)

I have tested XviD with QPel, chroma motion, BF=-1, VHQ 0 and 4.

What hell is happening? :scared:
Which decoder can we trust to test these damn clips and check how encoder works??
ffdshow(simple-iDCT) / ffdshow(xvid.dll) / xvid.dll / xvid.ax / mpeg4-player /... ?

unplugged, what happens the other way round?
I mean, it's not so surprising that the older core can't properly decode stuff produced by the newer core. I haven't tested much yet in that area, but acc. to some point shots, it seems xvid.dll/08032003 is decoding properly all clips produced by the older core. Therefore, it seems to me we are getting closer to the solution. Oh, BTW, ffdshow's 'simple IDCT' feature has never been a correct implementation of simple IDCT (in fact, I don't know that - but the results speak for themselves).
So, I have hope that the smearing is going to get solved soon.
What bugs me much more is the "speckling" that is still often produced by qpel with bframes. That thing is destroying faces quite often - its even enhanced with mpeg quants, but also present with h.263 - and I have not seen one single step (or pixel) forward on that matter. It's a big dilemma for me: I really love the improvement of the 'overall impression' that qpel brings - BUT THE FACES :(

[Bulletproof]

PowerMacG4, what way are you using to check if it inserted B-frames? are you using FFDshow? That's pretty weird that you had B-frames set to -1 and it still inserted B-frames..

bonz1, you can't set the tuner to a negative value, it's bugged.

The speckling with Qpel isn't exclusive to B-frames, Qpel alone causes some noise, however I think that's normal. This is just pure guessing, but I guess the extra motion search from Qpel is causing more variations in the DCT, and a side-effect is noise(?). I've never tried DivX5's Qpel so I don't know if that noise is normal or not, I'm just guessing.

[unplugged]

I'm just reporting my experience, about that hell words don't feel too seriously my tone... please

about older core and newer core
BUT, after uninstalling this build and installing Nic's 16/03 build, test clips made with 08/03 show smearing in any situation, even with VirtualDub
So what I meant is mainly that after installing Nic's 16/03 build, 08/03 build clips weren't valid anymore showing clearly the smearing artifact (even under VirtualDub).

Plus:
08/03 xvid.ax bundled decoder does show smearing with 08/03 clips coded with QPel, and a little color fluctuation with clips without QPel.
So I know that I'm insisting, but for me 08/03 has problems right with its created clips.

Again, I just only reporting, don't attack.
(although I don't mean that I felt attacked :p)

[Nic]

@Arcon: No my filter doesn't do any post-processing when there aren't any checkboxes checked. So it isn't the post-processing.

-Nic

[kilg0r3]

1.
Originally posted by Didée

What bugs me much more is the "speckling" that is still often produced by qpel with bframes. That thing is destroying faces quite often ... It's a big dilemma for me: I really love the improvement of the 'overall impression' that qpel brings - BUT THE FACES :(

And, I thought it were my eyes! For me, this means that I will have to wait to use Qpel until it has been resolved. And, I am sure, this fabulous coder team will squash this bug too. Yeah!

It seems, however, to be quantizer realted to, I never noticed this in frames coded with quantizer 2 or 3

Anybody desiring to see the effect can download some samples (http://www.mynetcologne.de/~nc-allgeife8/test.rar).

2. Could somebody confirm that the 'Min-Iframe-Interval' value is now taken into account. Or, is it just that the iframe decision algo has changed. I have a lot less but still some consecutive iframes, it seems.

[unplugged]

Originally posted by kilg0r3
Anybody desiring to see the effect can download some samples (http://www.mynetcologne.de/~nc-allgeife8/test.rar).
kilg0r3, I have seen the smearing even with sample made with QPel disabled, all show this artifact with or without using xvid.ax decoder.

But, should be mentioned that in my PC I have installed the latter build, Nic's 16/10...
Which build did you have used to encode this clips?

My test clips encoded with Nic's 16/10 build jointly with QPel, does produce very small smearing (beware, tested only quant. 2) when decoded with same core, whatever I using VirtualDub (xvid.dll core) or player (latest xvid.ax).
03/08 build instead has noticeable smearing problems just at quant. 2 and with all decoding ways.

[kastro68]

I don't know if I should mention this or not since so many ppl have already mentioned it in earlier posts.

I still get the freckle face syndrome when qpel is used... I think Kill Gore was right when he said that it is more obvious at higher quantizers. I didn't notice it last time because the video encoded last time had a first pass size of about 700megs, a really compressible movie, so small quants would be used very frequently.

However, with the latest koepi build, I also get some smearing as a keyframe is approached. You can almost tell each time you hit a keyframe.

Just posting my experience, I'm not complaining.

Cheers

[kilg0r3]

[QUOTE]Originally posted by unplugged
[B]kilg0r3, I have seen the smearing even with sample made with QPel disabled, all show this artifact with or without using xvid.ax decoder.

Of course, as the file anme indicates, the clip is coded with vhq4, which also causes this effect. the combination of qpel and vhq4 makes it worse of course.

Quant 2 will not have such visible 'smearing'in recent builds.

@kastro68
Nothing against Gore. In these days I have been wondering more than one time, where we would be without a Bushy President.

[sungey]

Originally posted by sysKin
Please test and share your revelations about new B-frame decision.
It's different than old one, because:

- it doesn't put as many bframes (with default setting). I think that it's much more safe, and _should_ produce better overal quality. BUT it also means that size of first pass, or average quant reported by debug info, will be _bigger_. Please don't complain about it, but check final quality instead.

- it tries not to put any bframes in still-motion scenes. This is where the artifacts, such as dark blocks, were mostly visible. Older code used to put plenty bframes there.


I see Nic's latest build (16/03) doesnt has b-frame threshold option.. i wonder if this build still behave the way syskin stated as above .. anyone knows ? (NiC perhaps)

[Arcon]

Originally posted by Nic
@Arcon: No my filter doesn't do any post-processing when there aren't any checkboxes checked.
hm, strange. if you decode the frames with the same routines as the xvid.dll, the results should be the same. therefore i thought it might happen later during processing. now i have absolutely no clue, but that doesn't mean anything :)

btw: if i can decode the movie correctly with the actual build of xvid.dll, does this mean that future version of xvid will still be compatible and able to decode it that way or should i archivate the xvid.dll used for encoding with the movie, as long as i use cvs-versions? right now i worry that the smearing i get might be corrected by a new xvid-build that won't be able to decode my (possibly buggy) movie anymore.

[JimiK]

Hi Arcon,
what do you mean with "the same routines as the xvid.dll"? Do you refer to decoding in VirtualDubMod? When you're talking about the looks you get with the CVS xvid.ax, then it could be that this one uses postprocessing. Should that be the case, you could check if it uses deblocking by open the xvid configuration and there is a button called "Decoder options..." where you have checkboxes for horizontal and vertical deblocking.
Your other question: I would burn the xvid.dll on the same CD or store it elsewhere. After so many people said they get bad pictures when not using the build the encoded with. I got pretty many builds on my HD, but I decode with ffdshow and had no problems so far.
To all others having problems: who uses qpel anyways? ;)
Best regards,
JimiK

[Arcon]

>what do you mean with "the same routines as the xvid.dll"? Do you refer to decoding in VirtualDubMod?

for example. or use the old xvid.ax that doesn't have the decode-functions build-in.

>When you're talking about the looks you get with the CVS xvid.ax, then it could be that this one uses postprocessing.

since the xvid.ax in the latest build is nic's ds-filter and he said he wouldn't do something like this if i haven't selected it (see the post above), i believe him ;)

[JasonFly]

Just to say that vhq1 is great.Good quality with size reduction, thats perfect.

In the latter month I have only used h263 quantizer and I'm wondering if mpeg quantizer is compatible with bframes and others options like vhq and qpel?