XviD-08032003

[Koepi]

Hello all,

new build up. Based upon CVS HEAD since dev-api-3 is dead now ;)

Changelog:

XviD-08032003-1:
- Fresh CVS checkout.
- Added Box for setting the bframe threshold (-110 is minimum, 0 is default)

A/V-synch issues are gone now, too. They were caused by the core, it didn't send those 0x7f-frames anymore, so virtualdub didn't drop the pad frames properly.
Also included is Nic's decoder.

Enjoy!

Koepi

[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.

- 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.

Happy testing,
Radek

[birdy]

Originally posted by sysKin


- 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.



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?

[NeVeRLiFt]

this build is slow :( :confused:

[kastro68]

Hi,

thanks for new build.

Somebody already mentioned this request, I can't remember who though... The request was for independent encoding settings for the opening and closing credits.

It would make anime encoding more efficient. :p

I guess it is not essential, but it would be nice if it can be implemented some time in the future.

Cheers.

[Shinobu]

@everlift

this build have the same speed of encoding that the build of the 17/02/2003

I encode at about 40 fps (MP=6,h263,VHQ1,qpel,cm,bf(3/150/100/0) with avisynth 2.51 (bicubic resize + telecine + mpegdec3 cpu=4)

this buil works perfectly but I have some difficult to understand the setting of bf....max bf oki but how works the thresold ???? I don't understand so I use it with the 0 value....

thank to all xvid dev , I think this codec is not far from V 1.0 ^^ and I've test it with VHQ, bf, qpel & cm on some movie of max 90 min (640*480) at quatitiser 2 and it always give me a file under 630 mo (=> 70 mo for sound in ogg is enouth)

PS: just a little advice or question ; i've a lot of tests on animes and if you encode with Quant 2 or 3 and set the postprocessing of ffdshow (or nic dec) to the minimum you don't have the "flashy block" effect you have with postpros at 4 or more ..... why i don't know ; but at a such quantitizer i'm not alble to see macroblock => if you don't like the "flashy block" when you watch animé just put the postprocessing to zero ^^

++

[mikeson]

@kastro68:
The request was for independent encoding settings for the opening and closing credits.

Why? It is not necessary to let XviD to do it IMHO. Why don't you just use 2 (or more) AviSynth scripts with trim command and then do whatever you want with these parts?

Just my 2 cents. ;)

[zulu]

Originally posted by mikeson
@kastro68:


Why? It is not necessary to let XviD to do it IMHO. Why don't you just use 2 (or more) AviSynth scripts with trim command and then do whatever you want with these parts?

Just my 2 cents. ;)

hmm...what was the name of the avisynth filter that restricts quant ranges? ;)

[wing1]

@birdy

confirmed with the reverting back to 0 setting in the new B-frame option.

@syskin

confirmed with the filesize increase, but that is not really that bad. The quality is way better! What is the threshold represent for this new option? If you need to calculate what value to put into this option, what do you recommend to use?

[Koepi]

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

Regards
Koepi

[zulu]

Originally posted by Koepi
Not confirmed, set to 50, rebooted and everything, stays 50.

Regards
Koepi

yepp, positive values work, but try to enter -50 :D

[mikeson]

@zulu:
what was the name of the avisynth filter that restricts quant ranges?
AFAIK when you're doing 2 separate encodings with 2 different AviSynth scripts, you can use whatever settings you want in each encoding (including quantizer restriction).

Or maybe we just don't understand each other. :)

[zulu]

ok, i haven't noticed that you mentioned 2 scripts. :p
but anyway, it's still harder to setup.

[mikeson]

@zulu:
it's still harder to setup
I don't think so. But anyway, you can reencode end credits to achieve desired filesize again without reenconding whole movie... ;)

I know, you can do it by cutting and appending in VDub, but this way is more 'elegant' IMHO. And you needn't to bother with setting start frame and end frame of end credits in VDub when you have 2 scripts (one for movie and one for end credits). ;)

At least it works for me. :)

But this is going to be offtopic, we should aim to testing new great Koepi's build.

[wing1]

@koepi

my fault for not being more specific.

1. If a negative value is used, this B-frame option will have the previous used positive value retained in its setting.
2. If a positive value is used, then that value will remain unchanged.

I.E. xvid was configured to default value of 0 previously, then re-configured to a negative value -50: The next configuration setting will retained the value 0 in this option. likewise, if a positive value of 50 existed previously, then re-configured to a value of -50; The next re-configuration will have that previous positive value of 50 remained there. However, using a positive value will always remain unchanged. Reboot or load default does not change the negative values from reverting back to the previously set positive values.

[HarryM]

Koepi: Can you make, please, any build version with simple CVS DS decoder too?
Nic's decoder is good, but his quality isn't 100%(!). I observe any smearing at q-peled videos still... :(

Nic: Can you eliminate this smearing in your decoder, please? The quality isn't identical as with simple decoder. I see on background (sky, etc) any smearing...

[shirka]

I didn't download this new build. But before installing it, do you if I can use GMC with this build ?

[majerle]

sse2 optimization is still buggy on p4 with vhq :(


Thanks anyway

Andres

[jarthel]

it's slow :(

[NeVeRLiFt]

@hinobu

Its slow for me.
Have installed it on two different PC's and its slow on both them.
One is a P3 1.4ghz Tualatin and the other is a AthlonXP 1.5ghz ;)
No ideal whats up.... I will stick with Nic's build for now.

[jarthel]

me too neverlift. same settings as Nic's Feb-16 build. Nic is faster by around 4 to 5 fps.

jayel

[Didée]

@ NeVeRLiFt & jarthel

You aren't testing with lumi masking on, are you?

[MoonWalker]

I can't help it noy to post...

You get a new release with all these goodies and better quality and you are whining about speed..I can't understand that..It will be always quality vs speed..And you will have to decide which of the two you want..Speed?? Make an avs with just crop and resize and encode in XviD with no B-Frames,no "fancy" stuff, H.263 and you will get speed(I get about 34 fps)..Quality? Make an avs with crop+filters(i.e Convolution3D)+resize and encode with B-Frames,CM and all the "fancy" stuff you want and you will get quality(I get about 10fps)..

It's all a matter of taste..

Regards,
MoonWalker

P.S Don't consider my post "evil", it's just a remark with good intends;)

[Big_Berny]

But if you want speed, I think that you should use DivX. Because DivX is faster at the same quality, but with xvid you'll have better quality if you've enough time.

Big_Berny

[wing1]

@jarthel and Neverlift

I am seeing about the same speed on my XP2100+ as the previous built from Koepi. all i use is chroma motion estimation & B-frame with the new option parameter. I get around 13-16fps on both builts when encoding with my filters rich avs script @640x480 resolution. I used 1-pass CBR or Quality mode mostly so at least the speed in that part does not change for me.

[BoNz1]

Originally posted by Big_Berny
But if you want speed, I think that you should use DivX. Because DivX is faster at the same quality, but with xvid you'll have better quality if you've enough time.

Big_Berny

Lol, I don't think so. If you really want to see which codec is faster just enable the features that DXN supports don't enable things like chroma motion etc. I think you will find that xvid is much faster using h263 quantization, bframes, 1/4 pixel, and gmc than divx5 is using the same features plus the quality is much better IMO. Most of us here put a much greater emphasis on quality though, I typically encode at about ~5fps and it doesn't really bother me I usually encode during the night anyway. But anyway, I can hardly wait to try out this new build. Thank you Koepi.

[TheXung]

It's slower because there are more p-frames which are being brute forced by VHQ.

[BoNz1]

It's slower because there are more p-frames which are being brute forced by VHQ.

How can you compare using VHQ when divx5 doesn't even support VHQ? If you compare speed you must compare using the same features for both codecs. Like moonwalker said before:

Speed?? Make an avs with just crop and resize and encode in XviD with no B-Frames,no "fancy" stuff, H.263 and you will get speed(I get about 34 fps)..

I can do about the same in xvid usually well over 30fps with no fancy stuff as described above. In divx is is usually about 25fps. Syskin made a poll a couple weeks ago about this very issue, http://forum.doom9.org/showthread.php?s=&threadid=45455. Nobody seemed to have a problem with slow speeds then, why now? I really don't understand. Please lets end this discussion now, it is really pointless.

[jarthel]

My comment is only about having the same settings using Koepi's 8-Mar build and Nic's 16-FEb build but Koepi's latest build is slower.

Setting used in Xvid are:

2pass
luma masking=on, vhq=1. quarter pixel=on. gmc=on.
all other options are default.

on the avs side( I can't post the script now as I'm at work)
--------------
avisynth2.5 (March 6 build)
mpeg2dec3 v1 (with parameters idct=5,cpu=6,ipp=1)
crop
feilddeinterlace (decomb)
temporalsoften
convolution3dyv12
lanczosresize
----------------------

And for the people who commented that I only prefer speed, that wasn't the case. As you can see, my avs script has filters that slows down the process slot. Also as stated above, I was just saying Nic's build is faster than Koepi's using the same settings and on the same avs script.

Jayel

[jarthel]

Originally posted by TheXung
It's slower because there are more p-frames which are being brute forced by VHQ.

An explanation like this is a helpful reply other than bashing me for saying Koepi's build is slow.

[TheXung]

Originally posted by BoNz1
How can you compare using VHQ when divx5 doesn't even support VHQ? If you compare speed you must compare using the same features for both codecs.

You people are missing the point of the argument. Comments were being about this new build running slower than older builds. Nothing was ever said about DivX 5.

At first glance, there are no new "fancy" things about this build over the previous one that would lead one to think that it should be slower. But it is a little slower and I offered an explanation why.


Geez, why must everyone take comments/complaints as a XviD vs. DviX war?

[BoNz1]

Originally posted by TheXung
You people are missing the point of the argument. Comments were being about this new build running slower than older builds. Nothing was ever said about DivX 5.


Yes, you didn't but others did. I thought thats what you were saying. Sorry, I misunderstood you.


At first glance, there are no new "fancy" things about this build over the previous one that would lead one to think that it should be slower. But it is a little slower and I offered an explanation why.


Geez, why must everyone take comments/complaints as a XviD vs. DviX war?

Thats, fair enough. I hate Xvid vs. Divx wars too. :)

[ookzDVD]

How if you disable the SSE2 manually, is it still slow ?

I get the same speed with the 17022003 build, B-frame, ChromaME,
VHQ=1.

Thank you.

[jarthel]

with my Xvid settings if I have the optimizations on "auto-detect", vdbumod crashes. If I disable SSE2, vdubmod continues with 1st pass.

[Gazza]

Has anyone tested the new feature and would be able to provide their results or impressions on improved/diminished quality against values (+/- 50, +/-100, 0)?

Cheers

Gazza

[Edit] sysKin - before this facility arrived what did xvid do? Did xvid use a threshold value that was hardcoded? Does zero mean that xvid sets the value of the threshold as per previous recent versions of xvid?

[TheXung]

Originally posted by ookzDVD
How if you disable the SSE2 manually, is it still slow ?

I don't believe any SSE2 code has been commited since koepi's last build.

Just to clear something up. I don't think this slowness is a bug. People shouldn't switch back to an older build just because this one is slower.

It takes longer to encode a p-frame than a b-frame when VHQ is enabled because p-frames can have 1 motion vector blocks or 4 motion vector blocks. So there's more motion vectors that have to be searched for. I don't think b-frames have that, although sysKin can answer that more correctly. To sum it up, p-frames take a little longer to encode than b-frames and the effect is more noticeable with the higher the level of VHQ used. Because the new p/b decision favors more p-frames, encoding should take a little longer. Still clips where there use to be a lot of b-frames but have more p-frames now will have a more noticeable effect.

This slower encoding may not be noticeable in some clips and it may be very noticeable in other clips. This is by no means a bug, it is the effect of a more correct i/b/p decision (hopefully). We need as many people testing this build as possible and doing a quality comparison to the older build.

[Koepi]

jarthel,

DON'T USE GMC AND VHQ TOGETHER - IN CURRENT STATE THEY DON'T MIX.

Read the threads a few "scrolls of your mousewheel" down this page.

[kastro68]

Originally posted by mikeson
@kastro68:


Why? It is not necessary to let XviD to do it IMHO. Why don't you just use 2 (or more) AviSynth scripts with trim command and then do whatever you want with these parts?

Just my 2 cents. ;)


I don't mind using multiple scripts for a few encodes... but we are talking anime here. Anime series usually come with many episodes, anywhere from 13 to 52, or maybe more.

It is tedious to make the scripts, and then encode the credits first so that you may allocate the remaining space to the main video (body)... and then join the credits to the body.

[jarthel]

Originally posted by Koepi
jarthel,

DON'T USE GMC AND VHQ TOGETHER - IN CURRENT STATE THEY DON'T MIX.

Read the threads a few "scrolls of your mousewheel" down this page.

I browsed my encode last night of nadesico episode 1. It looks good to me. Settings used are as stated above. :)

Jayel

[mikeson]

@kastro68:

I think it is a matter o taste... ;)

But as I've said before, we should move to AviSynth section with this discussion.

[sysKin]

Originally posted by jarthel
](...)Koepi's 8-Mar build and Nic's 16-FEb build but Koepi's latest build is slower.

Setting used in Xvid are:

(...)
luma masking=on
(...)Now come on, really.........
Someone actually asked you if you used lumimasking... do you wanna guess why?

Btw, as for speed in general: Pframes are coded faster. It has nothing to do with one vector versus four (btw four vector search isn't any slower thanks to some tricks). B-frames are motion estimated much slower.
HOWEVER, if VHQ is used, it's the other way around. This is because VHQ is so slow, it makes P-frames coding take more time. B-frames become fast now.
As I said, this build puts less bframes than the old one, so it's faster without VHQ and slower with high VHQ.

Radek

[jarthel]

Originally posted by sysKin
Now come on, really.........
Someone actually asked you if you used lumimasking... do you wanna guess why?
Radek

Is there something I need to know? I answered the person who asked but I didn't get a reply.

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

Is there something wrong with Nic's build? All this perceived opposition (maybe it's just me) to Nic's build being faster makes me wonder if there are divisions within the xvid developers.

[JimiK]

Is there something I need to know?
Well, yes I guess there is. Although I cannot be 100% sure that ReferenceDivX's lumi masking was not checked into CVS. His lumi masking is slower and Koepi is using it in his builds, so it's normal that this build with lumi masking will be slower than Nic's with lumi masking, because Nic is using CVS code. Hope this is still correct.
Best regards,
JimiK

[Didée]

Originally posted by jarthel
Is there something I need to know? I answered the person who asked but I didn't get a reply.
I am around in this forum as much as my time permits, and alas, that's often not so much.

Sorry for having a real life also ;)

But yes, I was aiming for ReferenceDivX's slower lumimasking code, that for my knowledge still is merged by hand in Koepi's builds.

Regards

"The person" Didée

[Nic]

All this perceived opposition (maybe it's just me) to Nic's build being faster makes me wonder if there are divisions within the xvid developers

lol, there are no divisions at all, my build is just that bit older and there have been changes as well as the lumi masking code koepi uses that makes mine faster at present. If I update my build, it will be as slow as everyone elses :)

Cheers,
-Nic

[birdy]

I still could not understand about and use negative values with the new b-frame threshol option!
No one else seem to care about this! So probably I missed something or it is only my problem!
Can someone confirm being able to use negative value with this new option and if yes tell me what you did?

[kastro68]

Originally posted by mikeson
@kastro68:

I think it is a matter o taste... ;)

But as I've said before, we should move to AviSynth section with this discussion.

I disagree. I think it has more to do with efficiency (or my laziness), rather than taste. Furthermore, I don't think it is appropriate to put requests for xvid features in the avisynth forum.

I'm not a proficient coder yet, so I have to rely on people like Koepi, Nic or Sys to implement these changes. All I can do is help test and suggest possible changes.

No hard feelings :)

[ffroms]

Originally posted by Nic
lol, there are no divisions at all, my build is just that bit older and there have been changes as well as the lumi masking code koepi uses that makes mine faster at present. If I update my build, it will be as slow as everyone elses :)

Cheers,
-Nic

I can confirm that problem. Same thing here. When ever I set - value I've got returned to previous + value. And could someone explain treshold to me (what -50 or +50 means for Bframe)?

FFS

[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

[ffroms]

Sorry! I've just read it (must be that I overlooked it before). I'm not beginer with Xvid but there is still problem of not being able to put - value.
Please don't remove that option. It can be realy helpfull.
FFS

[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?

[sungey]

they are as compatible as h263 as far as i know ... ^^ ...

[terwin]

At first, the new b-frame decision works perfectly for me. MSP=6,h263,VHQ4,qpel,cm,bf(3/100/200/0)

Only a short question. Can I change the b-frame threshold in the 2nd pass?

cu terwin

[JimiK]

@Arcon
I'm not sure who's xvid.ax is in CVS as I don't build this dsfilter. But I thought it would not be Nic's. Koepi is using Nic's filter as decoder in his latest build. The "normal" dsfilter should be smaller and you can't select postprocessing in it's properties, but have to set it in the properties of the dll config dialog. Of course you should believe Nic that he's doing no postprocessing if you don't select it.
What do you mean with "old dsfilter that has no built in postprocessing"? If I'm not completely wrong, then there is pp when using the "small" xvid.ax for quite some time now.
Maybe I'm really wrong, would be nice if somebody could clear this up for me.
Best regards,
JimiK

[Arcon]

Originally posted by JimiK
What do you mean with "old dsfilter that has no built in postprocessing"?
the XviD-17022003-1 build had a smaller xvid.ax that had only an info-dlg as properties, no postprocessing settings. the new xvid.ax from the current build has all of nic's pp-options. it might well be that the old filter did pp too, but at least it wasn't obvious to me :)

[Assault]

@Arcon

With the XviD-17022003-1 build you can choose both luma deblocking and chroma deblocking in the xvid configuration under decoder options. ;)

Regards
Assault

[sungey]

anyone has trouble with Nic's dshow filter included in 16/03 build ? it doesnt work on my pc .. if i use ffdshow alpha with xvid.dll decoding .. my Explorer.exe crashed.. using xvid.ax yield errorneous output (probably overlay since in vdub with Directshowsource() it works) .. only vfw works for me now ...

im using winXP and mplayer2.exe

[Nic]

Please read the sticky entitled "when posting bugs...". Saying "yields errorneous output" is never going to help get your problem solved.

Try running dbgview and tell me if any output comes out when using my filter, also do all movies produce "errorneous output"? Could you describe: "errorneous output"? (is the screen green, multi-colored scrambled stuff, black, etc)

Cheers for any info,
-Nic

[sungey]

oops sorry bout that Nic ... it was my graphic card driver which is outdated ... :( .. now it runs correctly :)

The output was scrambled and has many horizontal lines ....

[gino25]

I have the images green. Full green. Why? With nic 17/02/2003 all ok.


I' ve tried nic decoder, and ffdshow, and the decoder in koepi' s package

[ookzDVD]

@forum,

hmmm.... this thread has been spread into playback problem :(

[((( atom )))]

i really don't know what exactly went wrong in this thread, but i want to ask everybody involved to calm down a little bit, please.

when i turn my tv on, there is a war already going on wich is very unneccesary and my wish can only be that there is at least peace amongst people, that all follow their HOBBY here together.

it sometimes is of great help not to take to seriously in what way people react and it sometimes is of great help to say, that it wasn't meant this way, etc.

no more to add.

[Koepi]

I'm perfectly calm :confused: but anyways, this seems to show my point perfectly.

Let's close this thread, and focus on xvid again.

Regards
Koepi

[bond]

peace ;)

anyways there already is a new build up on uManiac´s site, perhaps someone wants to start a new thread about it?

[pandv]

Yes new Umaniac's build, and

max iframe interval works again

Testing this night.

Pandv

[NeVeRLiFt]

@Koepi

I dont have any respect for you know more. You really do give this forum a bad name... even with all you do, your personality and attitude sucks big hairy goat balls and you my friend are a smartass asshole thats needs to get off their high horse.

I will keep using Nic's and uManiac's builds since there not as buggy and seem to work better and give me better quality and less weird problems. Hell no wonder Standalone DVDunits are moving to support DivX3.11a, cause your to busy acting a fool and not making a better XviD build. Instead of adding these weird features and breaking stuff... why dont you fix whats already there bro?


Keep it real Koepi.... I used to be your biggest fan :p



Long live Nandub :sly:



/me yawns and goes back to test 1pass encodes with Nic's newest build and keeps getting blown away at the size and quality of these 1pass encodes :D


Thank you and have a nice day!

[Koepi]

Sorry neverlift, but you know the rules - as you're _again_ violating them I took the freedom to "abuse my powers" once more (strike for rule 4 violation).

If you have a personal problem with me (like birdy), then do what the rules suggest: mail doom9 and other mods.

Your accusations of me producing bad xvid builds: well, I have some fancy features activated which straight CVS builds don't use - but _you_ know these builds are unstable and alpha and there is a clear warning in the releasenotes which exactly mentions this.

They don't produce worse results than other builds, you're mumbling weird stuff there. It's an attempt to make me look bad which I won't accept. Blend in here or leave (I suggest that you directly follow the second option as you're again just trying to make trouble as you did before your last suspension and thus don't show any progress towards the first).

Focus on XviD again: uManiacs build has no real changes in core. The difference is an updated build/makefile for unix-platforms which doesn't have any impact on quality or performance.

Koepi

[ookzDVD]

@forum,

I notice that Nic's released new build dated 16-03-2003, and his DSF
is updated.

Thank you.

[Mel Maconoo]

@ Koepi


i will let you know this.. your the one makin' the build and let no one tell you off.. if they don't like it so be it.. you said "unstable build".. i will support your progress programers do have problems.. but you don't have to talk mad noise to them just say what YOU think is wrong.. Koepi keep releasing your builds i have had very few problems with them and Nic also.. I do understand they are unstable but i prefer the unstable cause of the new features.. thank you and keep up the good work.. >_<

[Didée]

Nic's build 16-03-2003: Problems

I hardly dare to disturb all that urgent personal flaming above.
Nevertheless, back to the topic VIDEO.

With Nic's current build, some technical bugs appear to me:

1. As soon as I mark an *.ogm file (with any XviD inside) in explorer, my complete shell crashes down after 2-3 seconds! (Explorer restarts). That's not very nice.

2. When enqueuing two jobs in Vdub (1st + 2nd pass), the second pass crashes immediately if Vdub's status window was opened. Without status window, second pass starts fine.

Hadn't time to elaborate this very much, but I could definetly nail it down to that certain build. Deinstalled Nic's 16032003, installed Koepi's 08032003-1, and everything was fine again. De-installed 08032003-1, installed 16032003 again - and everything crashes again :(

System is WinXP + Athlon XP.

Anyone else having similar problems?

[Koepi]

Can you try the updated decoder-only installer from my site please and tell if that decoder (nic's latest ;) ) is causing that in conjunction with my build?

Thanks,
Koepi

[Nic]

It will be the DShow filter causing it, does it happen when clicking on XviD AVI files as well or only OGM contained ones ?
As _always_ all/as much info is needed when posting bugs.

Thanks alot & ill try to do a new compile tonight to see if that helps :)

Cheers,
-Nic

[ookzDVD]

@forum,

Nic's 16-03-2003 build is working very well on my machine.

[Didée]

Sorry for providing not so awful much information. As I noted, there was not enough time for playing around.

Koepi: No, Nic's decoder from 23-02 has proven to work well with your 08-03 build. IF it is the decoder, then it is the new one from 16-03 that's causing the probs.
However, I'm not sure that the decoder is the (only) culprit. There is also the thing with VdubMod crashing on start of 2nd-pass if the status window is active - I never experienced something like that before.

Nic: nope, no problems with highlighting any AVI files, the crashing only occurs with OGM. With all OGMs lying around on my HD.

After all, it looks funny :) : imagine double-clicking an OGM file, the movie starts (and keeps) playing perfectly, and in the background Windows goes down in flames and restarts itself (okay, its only the shell) ... hihi!

[Nic]

Thanks for the info! :) Ill look into it tonight :)

Cheers,
-Nic

[jarthel]

/me is also using Nic's build :)

though it seems to suddenly crashed but when I ran first pass again, it works.

/me scratches his head

/me thinks I need a reformat :(

jayel

[Defiler]

Sorry for the long post. Please bear with me.

I wasn't going to mention this, since I presumed that I was doing something wrong.. However, recently I've been getting dramatically worse results with XviD than I am used to. I'm mentioning it in this thread because perhaps it is related to the recent XviD (developer) builds.

Previously, I had no difficulty creating XviD files that far surpassed what I could do with DivX.. In the last week or two, this hasn't been the case.
I was encoding Macross - Do You Remember Love?, trying to get the optimal one-CD output. I'm not at home, so I can't refer to my exact settings, but as you will see, I'm not sure they are vital to the discussion. My final goal was to do a two-CD version, but I sometimes like to tune the settings with lower target filesizes in order to make the differences more obvious.

First, I did two-pass XviD (tried this with Nic's 03-16 build, and with the one immediately prior.. can't recall the date right now..) using only "old-school" options. I often do this, just to check the validity of my Avisynth script, etc. Therefore, I used H.263, precision=6, no qpel, chroma motion, GMC, b-frames, or VHQ.
Using Avisynth 2.51 beta, mpeg2dec3, Decomb, Crop, and LanczosResize, and Con3D in "AnimeHQ" mode. (very simple 6-line script)
VirtualDubMod 1.4.13.1, Windows XP Pro SP1, dual Xeon 2.8/533.

(The following images are JPEG quality 95, about 70KB each)

The encode worked fine, but the quality was nasty.
http://hellninjacommando.com/temp/dyrl/type1.jpg

I was a little shocked by this, since the input looks pretty clean prior to compression:
http://hellninjacommando.com/temp/dyrl/original.jpg

Next, I went the other direction with XviD, and enabled GMC, qpel, chroma motion, and lumi-masking. Basically, all of the options that do not have interaction issues (I know not to use GMC and VHQ together, etc.)
This didn't change the output by much:
http://hellninjacommando.com/temp/dyrl/type2.jpg

Just for grins, I reinstalled DivX 5.03 Pro (I purchased DivX 5 when it came out, but I haven't used it recently, thanks to the amazing quality of XviD.), and did an "n-pass" encode with an identical target filesize, GMC, Qpel, and B-frames enabled. The XviD and DivX files differ by only around 100KB in size.
Amazingly, the quality was much better. This is the opposite of what I was expecting.
http://hellninjacommando.com/temp/dyrl/divx-1cd.jpg

Am I possibly experiencing an SSE2-related bug? I haven't had the opportunity to retest with any significantly older XviD builds, or with SSE2 disabled. The reason it didn't leap immediately to mind is that I've had good results with XviD since upgrading to the Xeons, as you can see here: (13MB)
http://hellninjacommando.com/temp/hook.ogm


Any comments? If this is the wrong thread to discuss this in, I will happily move it elsewhere.

[sungey]

NiC 16032003 prob ...

When i enable "use Xvid.dll" in ffdshow alpha and then play an Xvid clip (mplayer2.exe) .....movie plays fine but my Explorer crashed... im using Athlon Thunderbird and WinXP ...

it doesnt bother me much .. i always use NiC dshow decoder .. just giving some info .. :) .. if noone can reproduce the same result with ffdshow alpha ... i will just assume my WinXp is screwed :) .. ehehehe

[ssjkakaroto]

isnt anyone getting artifacts like the ones in the 14022003-1 build when using vhq 4, cm and bframes?? with either koepis or nics build

[sam_b]

@Defiler

I assume that you have tried lots of different playback filters and they all give a sub-optimal result? Lots of people having playback issues at the moment. Including me. What happens when you throw your old-skool encode into the divx5 decoder?

[Bulletproof]

Defiler, my personal opinion is that XviD does not do well with low contrast images, I had the same problem 2 weeks ago. The solution that I tried is to use the Lumafilter option within MPEG2DEC3 (This only does a minor improvement for me, but better than none), then I also changed the resize to Bilinear, and use only STABLE version settings, that means no Q-pel, no B-frames, no VHQ, no Luma Masking. The only thing I had enabled was Chroma motion. Then look at the encode again and it should be alot better. BTW, I think that DivX5 picture you posted has post processing on it.

[Didée]

Some more about Nic's 16-03-2003

In the meantime, I found that above described chrashes on my system are only related to xvid.dll, and have nothing to do with the dshow filter:

"Vdub-2nd-pass-crash" and "Hilighting-ogm-crash" behave as follows:

Koepi's 08-03-2003: no crashes, with every kind of dshow filter
Nic's 16-03-2003: crashes ever for me, with all dshow filters
Insta-build 20032003: no crashes at all (so far).

I tested with Nic's standalone dshow filters from 23-02 and 16-03, and with vanilla, dll-dependand CVS decoders from Koepi's 17-02-2003 and Umaniac's Insta-20-03-2003.

The pattern seems clear to me now.
However, if there are no, or very little, other reports of that behaviour, I would simply suggest:
Let it be, and invest your time more useful (go out, drink a beer ...)
It could be some interaction of {a very particular detail in my system setup} and {a very particular detail in the core of that day}.
I will check again with the next build.
Thanks for all efforts

Didée

[Defiler]

Originally posted by Bulletproof
Defiler, my personal opinion is that XviD does not do well with low contrast images, I had the same problem 2 weeks ago. The solution that I tried is to use the Lumafilter option within MPEG2DEC3 (This only does a minor improvement for me, but better than none), then I also changed the resize to Bilinear, and use only STABLE version settings, that means no Q-pel, no B-frames, no VHQ, no Luma Masking. The only thing I had enabled was Chroma motion. Then look at the encode again and it should be alot better. BTW, I think that DivX5 picture you posted has post processing on it. Yeah, I tried the "stable" settings only, MPEG2DEC3, etc.. I didn't enable any DivX 5 post-processing, so unless it does some without telling me (other than what is inherent in H.263), then it shouldn't have any. To me, it looks closer to "original.jpg" than the others.

sam_b: I haven't tried an extensive number of decoders, but I'm pretty sure this isn't a playback issue. When I get home, I'll try running it through the DivX 5 decoder, etc.

Thanks for the replies, both of you.

[kilg0r3]

@ Defiler

The settings including compression ratio or average quant would certainly help. Waiting until you get home ...

I have seen similar frames when experimentig with custom matrices. Btw is therer a 'anime matrix'?

[kastro68]

This is just my experience, but I am almost certain that the 17-2-2003 build gives better results than the 8-03-2003 build.

Cheers.

[kilg0r3]

Originally posted by kastro68
This is just my experience, but I am almost certain that the 17-2-2003 build gives better results than the 8-03-2003 build.


I'd appreciate, if someone could take the time to make a little frame-by frame comparison :)

[sysKin]

Originally posted by kastro68
This is just my experience, but I am almost certain that the 17-2-2003 build gives better results than the 8-03-2003 build.
Quick question: with bframes, or maybe the effect is there even without bframes?
New bframe decision is strictly experimental and comments like this are exactly what I want to hear. (well not necessarly bad comments ;) but if it's bad than tell me)

sysKin

[kilg0r3]

@ Syskin

I can't imagine the question which bframe decision mode is working better, being resolved without systematic tests. Any suggestions for a setup? E.g., what bframe settings would suggest for such a test, and, which compression ratio?

Tonight I encoded 'About a Boy' and it fit onto one cd with full resolution. I don't know the quant distribution, yet, since the first pass size was about 831 and the target size 695. The highest quant i spotted was an occasional 6 of a bframe. Visually, the result was very good. Yet, I used the hvs(what does hvs mean btw)-good-picture matrix. I put the settings and my script at the end of this post.

Another thing I am currently compiling a list of bugs/non-bugs/fixed bugs on my place. I would appreciate any input; also from the side of developers.

Settings for XviD (08.03.2003)

Mode: 2 Pass - 2nd pass Int. - Desired Size: 700000KB

I-frame Boost: 0%
Below I-frame Distance: 10% - I-frame Bitrate Reduction: 20%
Curve Compression: Payback proportionally - Bitrate Payback Delay: 250frames

Motion Search Precision: 6 Ultra - Quantization Type: MPEG Custom
FourCC Used: XVID - VHQ Mode: 1 - Mode Decision
Max I-frame Interval: 300 - Min I-frame Interval: 10
Lumimasking: OFF - Quarterpel: OFF - GMC: OFF - Chroma Motion: ON - Chroma Optimizer: OFF

Max B-frames: 3 - B-frames Quantizer Ratio: 126%
B-frames Quantizer Offset: 100 - Packed Bitstream: OFF
DX50 B-VOP Compatibility: ON

Min I-frame Quantizer: 2 - Max I-frame Quantizer: 31
Min P-frame Quantizer: 2 - Max P-frame Quantizer: 31

Start Credits 0-1350, End Credits: 138620-145563
Encode credits in greyscale: OFF
Credits I-frame Quantizer: 20 - Credits P-frame Quantizer: 20


AVS Script

LoadPlugin("C:\Programme\Avs\Mpeg2Dec3.dll")
LoadPlugin("C:\Programme\Avs\Unfilter.dll")
LoadPlugin("C:\Programme\Avs\Convolution3dYV12")

#H-RES MOVIE
a = 704
#V-RES MOVIE
b = 288
#H-RES CREDITS
c = (a/4)
#H-LEFT-EXT BORDERS CREDITS
f = 16
#H-RIGHT-EXT BORDERS CREDITS
e = (a-c)
e = (e-f)

Source = Mpeg2Source("Z:\Rip\Rip2\Source.d2v", cpu2="xxxxox", moderate_h=30, moderate_v=55)

Cred1 = Trim(Source,0,1350). greyscale()
Cred1 = Crop(Cred1,8,80,704,424). BicubicResize(c,b,0,0.5). AddBorders(f,0,e,0)

Movie = Trim (Source,1351,138619)
Movie = Crop(Movie,8,80,704,424). BicubicResize(a,b,0,0.5)
Movie = Convolution3d(Movie,0,3,8,5,8,2.8,0). Unfilter(3,3)

Cred2 = Trim(Source,138620,0). greyscale()
Cred2 = Crop(Cred2,8,80,704,424). BicubicResize(c,b). AddBorders(f,0,e,0)

Return Cred1 + Movie + Cred2

[Sigmatador]

@syskin
compressibility of the 08032003 build with b-frames threshold at 100 is very similar to the 17022003 build. But dark areas are a bit better :D

[Defiler]

Originally posted by kilg0r3
The settings including compression ratio or average quant would certainly help. Waiting until you get home ...I just performed the following test:

MPEG2Source("dyrl.d2v",cpu=0,iPP=true)
Telecide(guide=1,debug=false,chroma=true)
Decimate(cycle=5,mode=2,quality=3)
Crop(32,26,656,432)
BicubicResize(640,360)
Convolution3d(preset="animeHQ")
Trim(83500,84500)

I made three output files.. two using the 03-16-2003 XviD build.
The first used none of the "extended" options, just VHQ 1 with SSE2 disabled in the Debug tab. Target filesize is 4MB, 1001 frames, 23.976fps, 41.750 seconds, 785kbps.
Next, I simply added Qpel, Lumi-masking and Chroma Motion to the prior XviD options.
Finally, I used DivX 5.03 Pro with a 785kbps target, GMC, B-frames, and Qpel enabled. All other options at default.

The first XviD file is 4106KB, the second is 4104KB, and the DivX file is 4034KB.

In this test, the difference is much more subtle. The XviD versions are slightly worse than DivX, particularly during scene transitions.. but not as bad as what I was seeing when I encoded the whole movie. To me, this suggests that the problem might lie in the decisions XviD is making as to where to allocate bits in the second pass. This is a very low-contrast, low-motion scene. Because I've trimmed it out, it's not having to compete with the ridiculous number of dogfight scenes in this movie. Heh.

[kastro68]

Originally posted by sysKin
Quick question: with bframes, or maybe the effect is there even without bframes?




It was with B-frames. I haven't tried any comparisons without B-frames. For longer movies (2hrs or more) and movies that are hard to compress, the results are very apparent. However, I left the 8-03-2003 codec at the default settings... maybe if I told it to use more b-frames (which to my understanding, can be done by increasing the b-frame threshold) the result may be different.

However, it is easier to get undersized files using the 17-2-2003 build and vhq4... which just means I have to use a larger reso or sharper resize filter.