ni hao! (XviD-1.0-RC3)

[Koepi]

Ni hao everyone!

We are proud to release XviD-1.0-RC3, hopefully the last version before going final.
We need proper bugreports now ("It's black! I don't see anything!" or "This sucks, it's jerky." is not a proper bug report!), so please read the thread "how to report bugs" and follow the guidelines. Thanks :)

Changelog:
XviD-1.0-RC3-29022004 (ni hao!):
- Bitrate calculator fixes
- Status window fixes (-> GMCed frames get counted)
- Decoder fixes
- Workaround for dev-api-3 non-mod16 encodes
- Mod4 / YV12 resolutions encoding fixed
- Multilanguage installer
-> IMPORTANT: we need proper feedback and testing now - we want 1.0 to be final soon!

ATTENTION: Since I lost all my data, I switched to another installer system.
(Since XviD-1.0-RC1.)
If you used the old NSIS installer, please uninstall it manually
before upgrading with these new installers.
If you have done that already, upgrading with these new installers
works like you expect it.
Also, Win9x support is better now with this installer.


Thanks for your support!

Best regards
Koepi

[RexManning]

<totally unhelpful comment>
Whooooo-hooooooo, RC3! Go XviD-Team! \o/
</totally unhelpful comment>

[Manao]

Thank's a lot Koepi and all XviD's devs !

[OBcecado]

Another RC :D
Thanks for giving us tools to play with in the dvd-backup world.




Greetz.

[vinkes]

@ xvid team, thanx for the new release.
I immediately started encoding 'indiana jones and the last crusade' PAL.

avs settings:
704x288
neutral bicubic
no filtering

xvid settings:
profile level unrestricted
2pass
motion precision: 6
vhq : 1
turbo mode: on
chroma motion: on
frame drop ratio: 0
i-frame interval: 300
unrestricted quantizers (1-31)
trellis quantization: on

decoder options:
deblocking u & uv: on
compatibility mode: on

I ended with a firstpass (full quality) filesize of 1.735.906kb.
The first pass is completed now. Quality looks excellent, i did a quick look, i could not detect any visual artifacts.
I had no probs encoding or decoding. Running second pass now.

[communist]

Cool :)


Oh a sidenote could you please check your pm Koepi?

[virus]

well, the only problems I found are GUI-related, and they're almost the same as RC1 & RC2... some tooltips still missing (chroma optimizer, bvop sensitivity, reduced resolution) plus that nasty "jump" of the weight zone slider (set it to 1.15 and you'll see... can someone confirm it anyway?)

I hope not to get bashed for reporting these 2 times, but I think now it's time to worry about these "small" things ;)

thx for all your work :)
virus

[communist]

Yep when you slide to 1.15 and release mouse button it jumps to 1.13. Setting it manually to 1.15 changes it to 1.14, manually set it to 1.16 and then it was 1.15. Is it just reporting wrong number or is that number actually being used?

There is more:
If you choose 'Single Pass', switch to 'Target quant', enter any value between 1.13 and 1.16 and keep switching between 'Target quant' and 'Target Bitrate' it will incrementally drop the Target quant to 1.12 with each switching.

Just went through Target Quant again with the keyboard there seem to be a lot more values that are simply not 'allowed':
2.01 2.03 2.05 2.07 2.26
and more...
Values not allowed for Weight:
0.29 0.57 0.58 1.12-1.16
Also if you enter 1.16 in weight / quant (Zone options) and then switch to the other method and hit ok / enter it will decrease the value too.

To the devels:
Are these values not allowed and are there for being skipped?

[Koepi]

That jumping slider issue is (hooray!) yet again a M$ bug. We need to look into that (i.e. remove the slider completele).

@communist:

Your PM was regarding Reduced Resolution: it's not broken, but it's not meant for the mainstream usage. It's there for streaming media (therefore a rule 1 strike, it's gotten explained many times) over the internet. We have now the profile "ASP level 5" as default which prevents the usage of reduced resolution.

Regards
Koepi

[communist]

Originally posted by Koepi
it's not broken,
Ok thats all I wanted to know :)
Thx for clarifying.

[crusty]

@communist:
It's not broken, it's simply of not much use.
AFAIK it's not broken or buggy, but the proper use of it requires a dynamic implementation of RRV which isn't implemented (yet) in XviD.
Basically that means it's pretty much useless.
Use the search, there's a post by sysKin which pretty much explains it.

[snorre]

No fair! I've been a fan of your binary since I started using XviD, but lately I've been compiling my own XviD codecs (better CPU optimization I think, gains ~20% speed over Koepi's binary).

I can't find RC3 for download on xvid.org!!!

[atreya2011]

http://koepi.roeder.goe.net/

get it from Koepi's site then....

[snorre]

Originally posted by atreya2011
get it from Koepi's site then....

I have, but as you can read in my post, I prefer to compile myself, so I need the sourcecode, not a precompiled binary.

[Episode]

You can get the source code from here. (http://ed.gomez.free.fr/projects/xvid-1.0.0-rc3/) :p

[snorre]

Thanks!

[communist]

Originally posted by crusty
Use the search, there's a post by sysKin which pretty much explains it.
Exactly. This is the post I was refering to :
http://forum.doom9.org/showthread.php?s=&threadid=64924
Originally posted by sysKin
There is a big chance it's even broken completely. I haven't tested it for ages... And if it is, I have no idea if it's decoder or encoder that has it broken (or both).
Thats why I wanted to know if its broken or not.

[Koepi]

Originally posted by snorre
optimization I think, gains ~20% speed over Koepi's binary).

a) For which CPU are you optimizing?

b) 20% gain is quite unrealistic. Retest with your compile of rc3 and my build. (Do a proper speed test, exactly the same setup, fresh restarted system etc.). You can squeeze out max. 5% more as a rough guess from optimizing for a special CPU.

Koepi

[Selur]

If 20% turns out to be true, I'll start compiling my own builds too, but I guess Koepi is right normally 5% is more realistic. ;)

Cu Selur

Ps.: are there any plans to change the GUI up to 1.0? (otherwise I'll update my 'Wissenswertes rund um Xvid' next weekend)

[crusty]

Yes, I'd love to know that as well...I'm planning to include screenshots of vfw GUI in my FAQ.

BTW, haven't tried RC3 yet, but have started encoding again with RC2 and must say that not only quality is excellent, but speed is A-OK as well.
20-25 fps on NTSC version of Disney's alice in wonderland using Undot, Dup, and Fluxsmooth is quite neat! (Settings: VHQ 4 (!) B-fr 2/1.5/1, H.263, Chroma Optimizer, Trellis). I was especially surprised about the speed i get with VHQ=4.

(As a sidenote: I found that Alice in Wonderland animation is in fact often only 12 FPS. Only when there's a lot of motion in the clip it's true 24FPS. I guess they were kinda lazy over at Disney's..) :)

[snorre]

Originally posted by Koepi
a) For which CPU are you optimizing?

b) 20% gain is quite unrealistic. Retest with your compile of rc3 and my build. (Do a proper speed test, exactly the same setup, fresh restarted system etc.). You can squeeze out max. 5% more as a rough guess from optimizing for a special CPU.

Koepi

It's an AMD XP3200+. I did the same episode of Futurama with my own compilation and then with you build. With my build, I got ~40-50fps when encoding, with your build I got ~20-30fps.

I'll do a proper test and relay the result...

[Koepi]

So you are talking about a 100% speedup - very unlikely. You might have done a first pass with your compile and a 2nd pass with mine. Then the results look correct... (you know about fast first pass which is default and should be set in both encodes if you want to compare speed?)

Eagerly waiting for the results,

Koepi

[Alxemi]

snorre:
And the resulting files were exactly the same? (size at least)

[snorre]

Originally posted by Koepi
So you are talking about a 100% speedup - very unlikely. You might have done a first pass with your compile and a 2nd pass with mine. Then the results look correct... (you know about fast first pass which is default and should be set in both encodes if you want to compare speed?)

Eagerly waiting for the results,

Koepi

1: I did not do a 1st pass with mine then a 2nd pass with yours, I did two FULL 2-pass'ers, one with each. But I see now with my RC3, that the speed is NOT 40-50fps any more.

(Checking to see if I use fast first-pass) Nope, Turbo is OFF.

Noticed something else though.
I use the AS @ L5 profile, and it has VHQ set to Mode 1 (I've allways used Mode 4). Will I much of anything by forcing Mode 4?

2: As for speed, I have compiled the xvid-source on my XP using MSVC++6 using default settings (if anything is REALLY optimized, it's thanks to MS (wich I doubt).

I'll get back to you tomorrow morning on the actual speeds of the 1st and 2nd passes with my build and install your build to test it.

[Koepi]

trubo != fast first pass.

in the options you get when you hit "more..." after selecting "first pass" in the main dialog, there you can disable fast firstpass.

If you're using a plain MS VC compile it's ~10-15% _slower_ than my build on your computer.
What you're observing is a range in your clip where's very little motion - xvid will speed up like hell then. But it'll speed up _more_ with my build in the same place.

Take a stop watch, start it when you start encoding, stop it when that finishes - do that with both builds.

After that you'll see i'm right.

Do you think we checked the optimizations with toast instead of brain?

/me thinks about ringing the troll bell.

[poochie2]

I always had playback problems since RC1, and I'm happy of saying that after testing the RC3 the playback was absolutely flawless! Good work!

:)

[snorre]

Originally posted by Koepi
trubo != fast first pass.

in the options you get when you hit "more..." after selecting "first pass" in the main dialog, there you can disable fast firstpass.

If you're using a plain MS VC compile it's ~10-15% _slower_ than my build on your computer.
What you're observing is a range in your clip where's very little motion - xvid will speed up like hell then. But it'll speed up _more_ with my build in the same place.

Take a stop watch, start it when you start encoding, stop it when that finishes - do that with both builds.

After that you'll see i'm right.

Do you think we checked the optimizations with toast instead of brain?

/me thinks about ringing the troll bell.

Hey, I said "Turbo is OFF", not "I can't find it".

I don't need to use a stopwatch, I just read the encoding-log in GK.

And to please your curiosity, here are the results from MY 2-pass (please note I had a few other programs running that might have slowed things a bit (but not that much (Overnet in particular)):

1st pass: 26.394fps
2nd pass: 17.116fps

(With my RC2 I got 46.something and 3something.something with the same clip)

Don't treat like some dimwit n00b just because I got a different result than what you expected.

[seewen]

(With my RC2 I got 46.something and 3something.something with the same clip)


I love the "my rc2" :D

[Blight]

Koepi:
You mention fixes to the decoder, are those the fixes included in the post RC2 semi-silent update on your page?

If these are new fixes, what was fixed?

[Prettz]

Have there been any improvements or tweaks to the encoder in this version? Just curious.

[ChronoReverse]

(Checking to see if I use fast first-pass) Nope, Turbo is OFF.

This shows that you didn't seem to realize that Turbo != fast first pass


>.>

[atreya2011]

Originally posted by crusty
20-25 fps on NTSC version of Disney's alice in wonderland using Undot, Dup, and Fluxsmooth is quite neat! (Settings: VHQ 4 (!) B-fr 2/1.5/1, H.263, Chroma Optimizer, Trellis). I was especially surprised about the speed i get with VHQ=4.

(As a sidenote: I found that Alice in Wonderland animation is in fact often only 12 FPS. Only when there's a lot of motion in the clip it's true 24FPS. I guess they were kinda lazy over at Disney's..) :)

24 FPS you say? Well, I recently encoded Sinbad-Legend of the Seven Seas, I got 20 FPS avg in VDubMod with VHQ=1 and 8 FPS!!! with VHQ=4
How did you get 20-25 on VHQ=4? I thought VHQ=4 will be slow :confused:

[sysKin]

Originally posted by snorre
(With my RC2 I got 46.something and 3something.something with the same clip)I am pretty sure somethig was b0rked then. Maybe you didn't "Load Defaults" after copying your build (as there was no installer to do that for you)? I remember people having such weird speeds when they installed dev-api-4 over dev-api-3 and didn't erase configuration. Or when they used GKnot which has the same effect of writing old configaration info.

Anyway, 30..40fps is not possible with vhq4 (and hardly possible with vhq0 with b-frames) at modern computers.

Radek

[fengtao]

"ni hao" means "hello" :)

You can read it "ni hau".

[Joe Fenton]

Originally posted by snorre
I don't need to use a stopwatch, I just read the encoding-log in GK.

Uh, last I checked, GK didn't support xvid 1.0 and the author said he had no intention of fixing it anytime soon. The change from dev-3 to dev-4 changed the registry settings xvid uses to control the passes, so GK does funky things with the new xvid... including making it APPEAR as if you were running faster. You cannot do encoding inside GK. Save the AVS, then quit GK and go into VirtualDub(Mod) and set up the encoding passes.

[ookzDVD]

@snorre,

if you don't mind,
can you provide some download links for your own build,
lemme try :)

thank you.

[snorre]

Originally posted by sysKin
I am pretty sure somethig was b0rked then. Maybe you didn't "Load Defaults" after copying your build (as there was no installer to do that for you)? I remember people having such weird speeds when they installed dev-api-4 over dev-api-3 and didn't erase configuration. Or when they used GKnot which has the same effect of writing old configaration info.

I know. I had trouble getting GK to give me a result when I did a pre-comp, so I searched this forum and found that I should reset the XviD config and choose NOT to discard the first-pass info when testing. So resetting to default was something I did VERY early.

I agree that something must have borked badly, because I got the same results with several movies (wich I'll have to re-do now to make sure they are good quality).


Anyway, 30..40fps is not possible with vhq4 (and hardly possible with vhq0 with b-frames) at modern computers.

Radek

OK, When I reset to default I did not tinker with settings, so that means VHQ has been Mode 1 all along (I allways used VHQ Mode 4 with 0.9.x).

I've put my xvidcore.dll on my web-server for those interested in looking for them selves.

www.asylet.org/rc1.rar
www.asylet.org/rc2.rar

I'm a bit unsure if it was RC1 or RC2 no (when I scanned the RC2 folder I found no WfW stuff (wich is strange), so I quickly compiled one.

[communist]

Just did a quick test with a 32sec clip 640x480 (653 frames).
First I removed xvid RC3. Checked windows\system32 to make sure its uninstalled.

Testing procedure:
Installed RC1-Snorre. Reboot. Load test clip in VDM (1.5.1.1a). Fast Recompress, Load defaults for XviD - only change VHQ1 -> VHQ4.
After encoding removed RC1-Snorre and checked again in win\sys32 ... installed RC2-Snorre, reboot etc.

Results:
Read minutes : seconds . 1/100 seconds
RC1-Snorre: 01:16.06
RC2-Snorre: 01:16.93
RC1-Koepi: 01:22.31
RC2-Koepi: 01:22.16
RC3-Koepi: 01:21.28

Quality wise they all looked identical - did no PSNR check.

[mf]

Originally posted by fengtao
"ni hao" means "hello" :)

You can read it "ni hau".
We know :). All XviD 1.0 betas have been named after "Hello" in a certain language. Previous builds were named: Aloha, Ciao, Selam, Niltze, and Jambo :).

[olnima]

Is it possible for You to compile a "snorre-build" with RC3 and put it on your server to compare them??

Thanks in advance

Olnima

[snorre]

Originally posted by communist
First I removed xvid RC3. Checked windows\system32 to make sure its uninstalled.

Testing procedure:
Installed RC1-Snorre. Reboot. Load test clip in VDM (1.5.1.1a). Fast Recompress, Load defaults for XviD - only change VHQ1 -> VHQ4.
After encoding removed RC1-Snorre and checked again in win\sys32 ... installed RC2-Snorre, reboot etc.

Results:
Read minutes : seconds . 1/100 seconds
RC1-Snorre: 01:16.06
RC2-Snorre: 01:16.93
RC1-Koepi: 01:22.31
RC2-Koepi: 01:22.16
RC3-Koepi: 01:21.28

Quality wise they all looked identical - did no PSNR check.

Interesting... My build is marginally faster... Oh well, I won't bother making an installer for mine (I'll leave that for Koepi) ;). Well, I'm finished doing my tests, and I found (as Koepi expected) very little difference.

With Koepi's RC3 I got 37.609/32.560fps (1st/2nd pass).
With my own RC3 I got 37.363/32.873fps. VERY little difference.

I installed Koepi's RC3, did the test with minimal progs running.
Like communist, I uninstalled Koepi's RC3, checked /Windows/system32 (dang, my time with linux is starting to show) for leftovers (none found), installed mine, rebooted, killed everything not needed and ran the test again.

Joe Fenton: If GK really made my build look as if it ran faster then it should have done that with Koepi's too. I thought XviD worked with GK if you did some stuff to the codec settings (as suggested by others in the GK forum).

[snorre]

Originally posted by olnima
Is it possible for You to compile a "snorre-build" with RC3 and put it on your server to compare them??

Thanks in advance

Olnima

www.asylet.org/rc3.rar

(I don't really see why I'm doing this, as my own findings seem to indicate a difference so marginal there's no point in NOT using Koepi's build.)

[MeteorRain]

ni hao~ÄãºÃ~
it has still some problems when i play XVID avi file using newest ffdshow 2004.2.25 version.
i set xvid in ffdshow as LIBAVCODEC, it show me the video with wrong color(very serious, red -> black):rolleyes:
when i set to XVID, the color became correct but when i drag the slide bar to postion, it always returns a broken image until it meet a KeyFrame and it works again.
i think you should(or may ^_^) have a communicate with the developer of the ffdshow, for ffdshow is a very common decoder pack:D :cool:

still i will say, good job!¼ÓÓÍ£¡£¡

(i'm just a chinese senior student and may not very good at english, so if you can't understand me, e~~~~ hehe, just say sorry~)


[PS:if you find this some strange charcter, right click the page, choose ENCODE and then GB2312(Chinese), and you may see some chinese words, even you can't understand, wahaha]

[MeteorRain]

i suddenly found that i had made a mistake...

the situation above was not happen on decoding XVID, but on using XVID to decode the DIVX video...:scared: :scared: :scared:

[iago]

Hello everyone and congratulations to the XviD team that advances towards perfection with their great work.

I guess there are still some minor issues with the calculator in RC3:

"448" which is a very common bitrate for ac3 files is not included in the slidedown menu, whereas imho it should.

Moreover, when you enter the bitrate (448) manually it doesn't match the actual filesize of the 448 kbps ac3 audio file, and hence calculations are done with some error I guess, which in my case corresponds to sth. like ~ 9-10 mb miscalculation (undersize) in the video file size.

best regards,
iago

[Heini011]

Hi,

@devs: thank you very much for your great work!!


no jerky playback anymore, with and without compatibility renderer! (strange, what was it??)

a little note for the gui:

profile @ level -> level ->
MaxFrameRate and MaxProcessingRate

the unit name is mbs, but i think it must be mb.

has these values any impact now ? can i encode big resolutions with AS @ L5 Level too or is the bitrate limited here ?

greetings, Heini011.

[Lobuz]

There's a small problem with UV deblocking while decoding 640x360 clip. It's a green line (fluctuating few pixels wide) at the bottom of the screen. When there are Bframes it disappeare after first. Without Bframes it's all the time.

Regards
Lobuz

[crusty]

Well, I guess I had to be more complete with my speed report....
With VHQ=4 the speed was between 20 and 24 fps in the FIRST pass.
In the second it was somewhere between 12 and 18, centering around 16 fps.
Still, that's a lot more than 8 fps :)
(New install btw)

EDIT:
@Heini011
"has these values any impact now ? can i encode big resolutions with AS @ L5 Level too or is the bitrate limited here?"

AFAIK the implementation for this is rather complex, so I guess it's not something that is changed between Release candidates...

[GreatLord]

it is first version for long time that working fine agein for me

All test I have done are only single pass.

B-frame
I have test B-frame for x-card and other hard/software player
no of these have problem to play xvid b-frame any longre
even no packet stream and packet stream :)

Speed
The speed have incress from 18-25 frames to 23-30 frame on my test computer

Picture
The picture qualite have been improve alot from version 0.9x to 1.0RC3, But not equal good as you can get with memcoder or ffmpeg from www.mplayerhq.hu, If you guys suess to gain bettre picture qualite at same bitrate 810 and 4-bframe as ffmpeg/memcoder have.

TV Reslution
I have not test 4:3 or 16:9 reslution encoding yet in xvid
But i will when I get more time.



nice work and good improvment in xvid as encoder :)

[dbzgundam]

How would I go about installing snorre's build?

Simply overwrite the existing RCx files?