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