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?

[snorre]

Originally posted by dbzgundam
How would I go about installing snorre's build?

Simply overwrite the existing RCx files?

To do it properly, uninstall any XviD codec you allready have. Double-check your \windows\system32\ folder that there are NO xvid*.* files left. Unpack my .rar anywhere, right-click on the .inf file and select INSTALL.

(I give NO warranties against anything, my RC*.rar comes without an uninstaller (but installing another XviD-binary like Koepi's will overwrite the files). Use at your own risk! If you phuk up, I'll only laugh in your general direction, as this build was made for ME, with no intention to make it public etc.)

[Koepi]

snorre:

did i get this right, you did a plain compile with MS VC '98 compilers? No additional optimization switches used etc.?

Thanks for the info,

regards
Koepi

[snorre]

Originally posted by Koepi
did i get this right, you did a plain compile with MS VC '98 compilers? No additional optimization switches used etc.?

MSVC6.

I DL'ed the source, opened the xvidcore.dsw in WordPad and saved, opened the xvidcore.dsw in MSVC6, set the Active Config to "libxvidcore - Win32 Release" and compiled.

I have removed my binary untill you have had a look. If you don't have it, PM me.

Snorre

[Koepi]

snorre:

No need to remove it. That's where I started off with xvid some years ago :-)

It's really weird, the optimizations we currently use (me means Nic too) proved to be superiour to standard compiles for months now - cruncher kept doing speed tests with several compiling switches on his machine and what we use was always faster than standard M$ compilers.

I can't imagine where this comes from, or if that is just a special case you're experiencing.

Thanks for your support anyways,

regards
Koepi

[snorre]

Originally posted by Koepi
snorre:

No need to remove it. That's where I started off with xvid some years ago :-)

OK then, I'll just rename the RC3 build back to what it was (I'll remove the RC1 and 2's since they're outdated).

It's really weird, the optimizations we currently use (we means Nic too) proved to be superiour to standard compiles for months now - cruncher kept doing speed tests with several compiling switches on his machine and what we use was always faster than standard M$ compilers.

I can't imagine where this comes from, or if that is just a special case you're experiencing.

Thanks for your support anyways,

Don't ask me. I'm not very familiar with MSVC6 (we're starting with C++ at school next year).

What OS and compiler do you use? (I've been thinking about trying a cross-compile on Linux (just for the fun of it)).

So you're NOT keeping the troll-bell ready? ;)

Snorre

[Koepi]

The troll-bell was in close distance for the case you wouldn't try to help, I would have assumed a false alarm then. We sometimes have people around here telling the nicest tales about their speed gains without any proof or anything. (I.e. there was a guy including AMD's memcpy routines [not GPL'ed code] and stated it's much much faster than our normal stuff. We tested it, even coded own optimized memtransfer/copy routines - the speed gain was exactly 0.0000%.)

So, don't feel offended, I just have seen too much of such FUD I mentioned above. My apologies.

Btw., if you'd test a full-length movie encode (full 2pass) - once with plain MS VC compile, once with my build - you'll most likely get a chance to see the difference, the ICL should optimize quite a bit.

Regards
Koepi

[snorre]

Originally posted by Koepi
So, don't feel offended, I just have seen too much of such FUD I mentioned above. My apologies.

Btw., if you'd test a full-length movie encode (full 2pass) - once with plain MS VC compile, once with my build - you'll most likely get a chance to see the difference, the ICL should optimize quite a bit.

Regards
Koepi

No prob. I was a bit annoyed then, but now it's OK (especially since I've manage to do something by accident that might help you).

In fear of sounding stupid; what's ICL?

And where's the VDM log that shows actual time used to encode?

I'll get on with the full movie test with my 5th Element Superbit Edition tonight. Get back to you tomorrow morning.

[Prettz]

Originally posted by snorre

In fear of sounding stupid; what's ICL?

Intel's C/C++ compiler. Definitely the best compiler available for producing fast x86 programs. Also, it's made to be specifically compatible with VC++.

[fl0]

I'm using Koepi's binaries and wonder about are they compiled with icl...

if icl used, besides SSE2 optimizations (both Intel Pentium 4 & Athlon 64 benefits)is Hyper-Threading support enabled @ the compiling level for Koepi's binaries ? (must say that i've got p4 2.4C HT)

E D I T: Yep i forgot that SSE2 support is present, so i changed the post :)

i also read an article about the newest intel compiler (8.0) that it can boost performance up to between %5-10 in certain sceneraios. so in the near future could there be a chance to compile XviD with it ?

a free boost for encoding will be nice if possible :)

thanks 4 your answers :cool:

[clearwind]

wow..
the title is pretty sweet Koepi
thanks for the work yaha!

[Lobuz]

Originally posted by 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.

So what about that? Anyone can confirm that bug with mod8 height? BTW with mod16 640x352 is ok.

Regards
Lobuz

edit: "width" -> "height"

[snorre]

Originally posted by Prettz
Intel's C/C++ compiler. Definitely the best compiler available for producing fast x86 programs. Also, it's made to be specifically compatible with VC++.

Ah, but will make VERY Intel-optimized progs and less AMD-friendly, or is it unbiased?

[frodoontop]

Thanks for this great release. The decoder speed has improved greatly :) . Now I can finally watch some video instead of a slide show :D .

[WhipHubley]

no more jerky playback - thankyou!!!

whatever you fixed in this release to stop jerky playback, please keep it in :-)

[iago]

Originally posted by Lobuz
Anyone can confirm that bug with mod8 width?Yep. Same here. Green line at the bottom with UV deblocking. But I guess you mean mod8 "height" (such as 640*360). It seems ok with mod8 width (such as 648*352). :)

[mikeX]

another fine example of this green line can be found on my post here (http://forum.doom9.org/showthread.php?threadid=68025&highlight=green)
(it also comes with a picture :) )

[crusty]

No sign yet of green lines..quality is excellent.

A clip of 512x384 makes mplayer classic use about 38-40% CPU on my system.

[Rash]

Originally posted by Koepi
If you're using a plain MS VC compile it's ~10-15% _slower_ than my build on your computer.
Sorry for the OT. Could you tell me which compiler do you use Koepi? Thank you very much.

[EDIT] I've read Koepi uses ICL for compiling his builds, sorry for asking.

Have you guys heard of Intel's Performance Libraries? It seems they were developed for this kind of application specifically.

-> http://www.intel.com/software/products/perflib/index.htm?iid=ipp_software+libraries&

Too bad they are not free. Well, I don't get why Intel doesn't provide its compilers and optimized libraries for free... anyway, that's offtopic and I believe that most people here don't care since they have AMD processors that shoudn't benefit from those optimizations.

[mikeX]

i'm around 40-50% with a 640x352 clip with Q-Pel
i can use YUV deblocking && RGB32 cs conversion without stuttering (80-9x% cpu)

@Rash

i think he is using ICL 8.0

[Joe Fenton]

Originally posted by snorre
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).

Yeah. I just read this from the changes.txt:

both XviD and DivX pass settings are now correctly picked up from default to avoid resetting when dealing with different version of codecs, like XviD 1.0 for instance (now whatever was saved as default will not be overwritten on encoding window)

So it looks like as long as you set it up in the default page and don't change anything in the encoder page, it works now. That's good... I can stop quitting GK to encode. :)

[Dr_Colossus]

Interesting thing about the Intel compiler. Seems there are some Intel "specific" otimizations that will refuse to run on AMD processors because they aren't genuine Intel. However someone modified a binary compiled with the Intel specific optimizations and was able to run the program fine with a 22% boost in performance on an AMD FX51. Might be something worth looking into. Here's the article (http://www.warp2search.net/modules.php?name=News&file=article&sid=16416).

[Malevolent]

@ XviD team:

Great work! Keep it up ;)
No problems with this build whatsoever.

@ mikeX & crusty:

How on earth is your CPU usage so high???
I'm running 1.2Ghz Athlon OC:ed to 1.3Ghz & 512x384 uses about 20%-25% CPU,
which is pretty much the same as earlier builds.
(No Qpel or GMC)

[celtic_druid]

I have been compliling XviD with ICL8.0 since it came out and haven't really noticed any performance gain (over 7.1), but then I run an AthlonXP.

[sdsalsero]

RC3 has the same playback bug as RC1 and RC2, i.e., beta3 was ok.

When playing-back anamorphic video, e.g. a 2.35:1 movie recorded straight from DVD as 720x368, the Aspect Ratio feature in Zoom Player etc no longer works. I reported this in more detail during the RC2 thread.

[dragongodz]

"Interesting thing about the Intel compiler. Seems there are some Intel "specific" otimizations that will refuse to run on AMD processors because they aren't genuine Intel."
an example of how newer versions of the compiler get faster for intel cpus while slower for amd have a read here.
_http://www.hydrogenaudio.org/index.php?showtopic=18230&

[Koepi]

Originally posted by sdsalsero
RC3 has the same playback bug as RC1 and RC2, i.e., beta3 was ok.

When playing-back anamorphic video, e.g. a 2.35:1 movie recorded straight from DVD as 720x368, the Aspect Ratio feature in Zoom Player etc no longer works. I reported this in more detail during the RC2 thread.

We set an aspect ratio which is defined in the container. So this might be the point of disturbance.

Blight, please look into that :)

NB, that's not really a bug. It's changed behaviour - and since other players can resize correctly it must be a special mode of zoomplayer which prevents that. (I think it's the code which should help AR correction via "media_changed" messages)

Regards
Koepi

[sysKin]

Originally posted by sdsalsero
RC3 has the same playback bug as RC1 and RC2, i.e., beta3 was ok.

When playing-back anamorphic video, e.g. a 2.35:1 movie recorded straight from DVD as 720x368, the Aspect Ratio feature in Zoom Player etc no longer works. I reported this in more detail during the RC2 thread. It's not a bug but a limitation of zoomplayer. Or, in other words, xvid supports its own aspect ratio which zoomplayer respects (kinda wrong, ask them to fix it).

Anyway, just activate "compatibility renderer" and restart your video.

[Koepi]

Originally posted by dragongodz
"Interesting thing about the Intel compiler. Seems there are some Intel "specific" otimizations that will refuse to run on AMD processors because they aren't genuine Intel."
an example of how newer versions of the compiler get faster for intel cpus while slower for amd have a read here.
_http://www.hydrogenaudio.org/index.php?showtopic=18230&

Ok, i'll switch back to older ICLs ;)

I'll announce a silent update of the installer maybe this evening.

Thanks all for pointing this out!

Regards
Koepi

PS:
Silent update, new binary online. Core + VfW are ICL7 compiles, DShow refuses to compile with that so it's still ICL8, but it shouldn't have measurable impact there. Happy re-downloading!

[mazzo]

My first experience is that this new version encodes slower than the previous one with same settings, up to 1.5 times slower.

[Koepi]

Subjective speed doesn't count. Take a stopwatch and do a proper test (same file, same settings - both with old and new build).

After that we can use the result, this now is a no-use post :-/

Please, if your time allows for this, do a proper speedtest. I'm sure you switched between VHQ=1 and =4 or something, it _can't_ be 1.5 times slower, that's impossible.

Thank you.

Regards
Koepi

[Lobuz]

@iago
Yep. Same here. Green line at the bottom with UV deblocking. But I guess you mean mod8 "height" (such as 640*360). It seems ok with mod8 width (such as 648*352).
Yeah. I meant height. :o

@mikeX
another fine example of this green line can be found on my post here (http://forum.doom9.org/showthread.php?threadid=68025&highlight=green)
That's that thing, and I hope it will be fixed in final.

Regards
Lobuz

[mazzo]

OK, maybe I was too fast, but with RC2 the second pass usually took about five hours for a one cd avi (GK-made avs, no deinterlacing), yesterday I tried the new RC, and when I went to work today, I saw in the status window that it was scheduled to approx 9 hrs. I'll check my settings more thoroughly and come back.

[Koepi]

mazzo:

ah i c, you compare rc2 and rc3. Shouldn't be any speed difference _except_ you downloaded the silent update from 4 hours ago (7:45h MET) which I compiled with ICL7 since it seems that ICL8 is too slow on AMD processors now (sorry P4 HT pals).

Regards
Koepi

[mazzo]

OK, you mean I SHOULD install this new silent update?

[mazzo]

Is there a way to make the bitrate calculator see how long the movie is, so that we don't have to enter the numbers manually?

And, when I go from the calculator box back to the encoder settings, the bitrate figure will always be 4 lower than the calculated one. I don't know if that is a bug. I.e: The calculator gives me a bitrate of 1111. The encoder then says 1107.

[Koepi]

That is just the overhead calculation - the values should be correct.

Regards
Koepi

[jared1999]

Originally posted by Koepi
mazzo:

ah i c, you compare rc2 and rc3. Shouldn't be any speed difference _except_ you downloaded the silent update from 4 hours ago (7:45h MET) which I compiled with ICL7 since it seems that ICL8 is too slow on AMD processors now (sorry P4 HT pals).

Being a P4 HT user it would be nice with a P4 version too :) (Unless there isn't any substantial difference). Has benchmarking been done between ICL 7 and 8 Xvid binaries on P4 HT cpu's? If not I could give it a try.

[Koepi]

jared:

go for it please! compare rc2 (=icl8) vs. updated rc3 (=icl7) please!

thanks,

Koepi

[dragongodz]

"seems that ICL8 is too slow on AMD processors now"
well i wouldnt say too slow yet since it really needs proper benchmarking as the speed difference would be different than comparing the Lame compiles as found in the link i gave. if ic8 adds an extra 2 minutes on a 2 hour encode then it is not really so big a deal and i am sure we AMD users could live with it. :)

[Boost]

If it's not too much trouble (i.e. if you can script it) why not supply three binaries in the installer. One überoptimized for the latest Intels (with HT and all), one with as much optimization that still is compatible with AMDs and one general maybe less optimized that should run on all platforms (ie i386 compatibles). Detect CPU at installtime and offer the user a choice of which binary to install and and preselect the one that matches the detected CPU.

This way everyone should be happy except those downloading the binary via an acoustic 300 baud modem.

[dragongodz]

Boost - load xvid settings window. press the "advanced options" button. go to the "debug" tab. select "force optimizastions". untick all options. now if you can find a cpu that that doesnt work on then you have found a bug or something that xvid is still using that the cpu doesnt support. no need for a "general" compile as xvid already is. we are talking about if the intel compiler version is making much speed difference for xvid aswell.

so actually some testing/benchmarking by both Pentium and AMD users would be good.

[mf]

There is no such thing as a 32-bit x86 binary that won't run on all 32-bit i386-compatibles (given they have a FPU of course). So you'd only need 2 binaries, one that's Intel-biased and one that's AMD-biased.

[sbp]

Hi, I just want to report that I have a problem with the latest installer. Previously I was using beta 3, but now wanted to jump on the waggon. I uninstalled the latest version, then installed 1.0-RC3 (with the silent update) - it installed OK, but it doesn't show up in my encoder list within my capture program.

I can reach the encoder and the decoder from the XVID-group in the program list and everything is OK. BUT I can't get my capture program "see" the XVID encoder, so I can't choose it for my capture.

I have tried to re-install twice - but without success.
What have I done wrong?
Thanks
Steen

[Prettz]

Originally posted by Boost
If it's not too much trouble (i.e. if you can script it) why not supply three binaries in the installer. One überoptimized for the latest Intels (with HT and all), one with as much optimization that still is compatible with AMDs and one general maybe less optimized that should run on all platforms (ie i386 compatibles). Detect CPU at installtime and offer the user a choice of which binary to install and and preselect the one that matches the detected CPU.

This way everyone should be happy except those downloading the binary via an acoustic 300 baud modem.
There's no point in optimizing for anything but Athlon/Athlon64/P4. The next step down would be P3, and there's probably not enough people using a slow P3 to do heavy duty video encoding.

[snorre]

Originally posted by Prettz
There's no point in optimizing for anything but Athlon/Athlon64/P4. The next step down would be P3, and there's probably not enough people using a slow P3 to do heavy duty video encoding.

I agree. Strictly speaking, there should be four versions:

P4 w/ HT
Intel 64
Athlon
AMD 64

But then again, maybe there isn't much to gain in making an architecture-optimized build.

Koepi: I'm done with my full-feature test. I ran my MS XP Pro in safe-mode to keep unwanted progs from occupying mem etc. (Not sure how this may have affected speed though.)

I encoded 2010 (R2)

My RC3 build:
1st pass: 55m
2nd pass: 89m

Your RC3 build:
1st pass: 54m
2nd pass: 73m

I might have made a few blunders with some settings (lousy short term memory made me forget wether I used GMC in either encoding, so I might have turned it on in one and off in another). I'll do a quick-and-dirty one of a Futurama episode now just to test again.

Another thing I noticed: Your .dlls are ~200k larger than mine...

[alexnoe]

But then again, maybe there isn't much to gain in making an architecture-optimized build.?
The critical parts are implemented several times (once for each CPU you want to have a special version for), the CPU is identified at runtime, and then you set function pointers depending on the CPU you use.
There is absolutely no point in different builds. XVID is not made in a primitive pseudo-language like Visual Basic...

[celtic_druid]

@sbp, been posted plenty of times before so I guess you already tried this but check and remove empty vidc entries from: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32 and then reinstall.

[crusty]

@ mikeX & crusty:
How on earth is your CPU usage so high???
I'm running 1.2Ghz Athlon OC:ed to 1.3Ghz & 512x384 uses about 20%-25% CPU,
which is pretty much the same as earlier builds.
(No Qpel or GMC)
Well, I guess it depends from system to system. Currently my memory is running a bit slow (debugging some weird issue with my pc) so that could matter. I also used no Qpel or GMC, but I did use more than 1 B-frame. B-frames also require (a little) extra cpu power.
Beside, I measure CPU utilization by the task manager. Is there another way?
mazzo:
I saw in the status window that it was scheduled to approx 9 hrs.
Mazzo, that could be pure coincidence. Status window usually calculates the ETA by the current speed, and the encoding process slows when it's working on a difficult part of the clip. You could have looked just while it was encoding such a complex scene.

This way everyone should be happy except those downloading the binary via an acoustic 300 baud modem.
All who still use a 300 baud modem please raise your hands right now...
:D :D :D
(damn, those things are prehistoric)

@sbp:
Be a little more specific...what program are you using?
What was the last XviD version that DID show up?
Intel 64
Well, apart from rumours that current PIV's have some (not yet enabled) 64-bits extensions, the very few Itaniums that are around hardly make it worth while to use Intels 64-bits stuff.
XVID is not made in a primitive pseudo-language like Visual Basic...
Auch! If it would then testing would probably be a generation game...'look grandpa, your computer died on 99% of the encoding process!'. :)

A technical question:
Does AMD's 3D Now extensions help encoding? I think I read somewhere that 3D Now isn't exactly helping a lot for codec optimizations (both Audio and Video codecs).

[sbp]

Thanks for you suggestion,
I checked HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32.- but had nothing about XVID there. However, I did find some other traces of XVID in the Reg - I deleted those. Rebooted and re-installed the latest XVID.


But still no XVID encoder to find in my capture program (TV-plugin for myHTPC), but it is also missing in my other programs, where I can encode video like DVDx. It seems like this install somehow is "invisible" from inside other applications.

I hope you can help me on this.

PS:My latest working XVID was 1.0 beta 3.

Thanks
Steen

[Th3-S4int]

I did a short Speed Test with the old and the new build of RC3. On my AMD 64 was no speed difference. I will test a little bit more soon.

[snorre]

Did a final test between my RC3 and Koepi's RC3 (29th Feb. 2004) on Futurama S01E01. Now I'm annoyed:

The difference is 0 minutes (maybe some seconds, but I can't find a VDubMod log that gives detailed encoding-time).

This time I wrote down all settings to make sure the two vids were encoded exactly the same.

AS @ L5
GMC
B-VOP
Packed Bitstream
Closed GOV

Advanced Options
MSP 6
VHQ 1
Chroma Motion
Cartoon Mode

1st pass
Discard First Pass

2nd pass
Target Size 176784

[angerjas]

Some time ago I did some tests for ghostscript ver 8.13 on my Athlon XP1600. My observations:
1. Icl builds with /G7 (or /G6) and /O2 (or /O3) _without_ /Q_ipo switch were not faster than MSVC6 builds.
2. After adding /Q_ipo and creating a representative profiling database, icl builds were consistently faster by ca 10%.

My conclusion was that using icl does make sense only when a good profiling database can be created, together with /Q_ipo switch.
For xvid, creating a profiling database will take some time, but should be possible.

[albertgasset]

I've done a test to compare the firt RC3 build and the RC3 silent update and I notice no speed difference.

My system: Pentium4 2.40 GHz (no HT), 512MB DDR, Windows XP Prof.

Source video: a Simpsons episode, res. 512x384, 31190 frames, encoded with Xvid RC1 at 1000kbps. Decoder with postprocessing disabled.

Xvid settings: defaults except Max. I-frane interval set to 250 and Cartoon Mode enabled. Bitrate: 1000 kbps.

RC3 First pass: 7 min 52 sec
RC3 Second pass: 11 min 55 sec
RC3 silent-update First pass: 7 min 53 sec
RC3 silent-update Second pass: 11 min 54 sec

[mikeX]

@sbp
but had nothing about XVID there.
don't look for something about xvid, look for empty entries (usually 3ivx) and delete them, but come to think of it, some xvid entry should be there, right? (something like 'vidc.XVID xvidvfw.dll')

@koepi
i'm making a few tests with the two rc3 builds but so far i don't see any speed difference, will post the detailed results later

[sbp]

Thank you for your answer, but I don't quite understand: why do I only have problems with this new version of XVID - from my point of view it seems like it doesn't install fully - as it is invisble from inside other applications?
And why has this something to do with empty entries for other codexs?

The reason for not finding anything about XVID might be that I uninstalled XVID before I checked the reg-file?

So what do you think I should do?

Steen

[Malevolent]

Originally posted by crusty
Well, I guess it depends from system to system. Currently my memory is running a bit slow (debugging some weird issue with my pc) so that could matter. I also used no Qpel or GMC, but I did use more than 1 B-frame. B-frames also require (a little) extra cpu power.
Beside, I measure CPU utilization by the task manager. Is there another way?
My memory always runs slow, as i have 384 of 100Mhz SDRAM :rolleyes:
I too used B-frames (10 with sensitivity of 10),
and task manager was used here too.


@ Koepi:

A quick test between RC3 old & new showed exactly 0% speedup on my Athlon 1.2Ghz.

All settings default
448x336 5153 frames
RC3 = pass-1 1min.57s., pass-2 3min.12s.
RC3 Silent Update = pass-1 1min.58s., pass-2 3min.12s.

[clas]

Shouldn't Xvid be able to decode DivX movies; DX50?

I have this DivX movie in a OGM file, and when I tried to play it with only the Xvid codec installed
(enabled decoding options under installation) then player crashed and said that there was an error in xvidcore.dll.

Is this a bug? Or does it have something to do with OGM?

----
Clas
----

[Proff]

nt :)

Seems on the code generation in C++ settings, the run-time library must be Multithreaded DLL for ICL8, instead of Multithreaded. This was in the .dsp file of the source code :(

[crusty]

Hi clas,
Welcome to the forum. Please read the sticky on top of this thread list called:
"(READ THIS!) What You Must Do When Posting Bugs/Problems!..."
...and file a proper bug report. We can't help you properly if you don't provide any details.

some hints:
-list the XviD decoder version you used
-list your OS and hardware (even better: put it in your undersign)
-list the media player(s) you tried
-list the codecs and other filters you installed
-read the sticky properly to rule out any errors in your setup.

HTH
Crusty

[clas]

Hi crusty, sorry I didn't read it.

I installed Koepi's XviD-1.0-RC3-29022004 (enabling the decoding options under installation)

It seems that the players crash due to a problem in the xvidcore.dll, and this only happens with files i OGM format. The video stream in the OGM files is DX50. I checked that with VirtualDub.
The codec only behaves this way with my two OGM files from the same movie.

My PC is a AMD XP 2100+ with Windows XP SP1, Geforce 4 Ti 4200 Leadtek A280 Graphics Card.

Both Windows Media Player and BSPlayer 0.86 crashes when I try to play both files.

Other codecs installed:
Ogg Vorbis Direct Show
Radium MP3 codec v1.263

Error signature:
AppName: bplay.exe AppVer: 0.8.6.493 ModName: xvidcore.dll
ModVer: 0.0.0.0 Offset: 0004c85f

----
clas
----

[sdsalsero]

Originally posted by sysKin
It's not a bug but a limitation of zoomplayer. Or, in other words, xvid supports its own aspect ratio which zoomplayer respects (kinda wrong, ask them to fix it).

Anyway, just activate "compatibility renderer" and restart your video.
hmm, that fixed it! But what consequence is there to using this "Compatibility renderer"?

P.S. This 'issue' also affected Media Player Classic.

P.P.S. I posted in the Software Players forum re ZP.

[Rash]

Is there an AMD Compiler or something? Because I got the impression that the 3DNow! instructions get used only if you do write ASM code for them, am I right?

I don't have an AMD processor, but I think it would be cool to do a comparison between AMD's optimized 3Dnow! instructions and P4 SSE/SSE2.

Of course, sorry for the OT again. ;)

[sysKin]

Originally posted by sdsalsero
hmm, that fixed it! But what consequence is there to using this "Compatibility renderer"?Heh, you would never guess - Aspect Ratio does not work :D (for exaple in matroska, but also in AVI if you have a proper AVI with proper header, which you don't have 'cause it's a secret).

:D

[Koepi]

Originally posted by Rash
Is there an AMD Compiler or something? Because I got the impression that the 3DNow! instructions get used only if you do write ASM code for them, am I right?

I don't have an AMD processor, but I think it would be cool to do a comparison between AMD's optimized 3Dnow! instructions and P4 SSE/SSE2.

Of course, sorry for the OT again. ;)

There are 3dn/3dne optimized asm files in the xvid sources. They get compiled and chosen on the respective platforms automatically.

You're so wrong, it's so damn uninteresting seeing the difference between those two. Just a hint: on AthlonXP (=AMD, not Intel), mostly IntelSSE gets used - simply because ti's faster than 3dn/3dne.

Koepi

[olnima]

The Version after the silent update for me (Athlon XP 2000+) is SLOWER than the first RC3 with the newer compiler.

Greetz
Olnima

[Dr_Colossus]

There might be a workaround to ICL8.0 binaries only running on Intel CPUs when using /QxN. It apparently only does the CPU check when compiling main() so if you compile everything but main() using /QxN and then compile main() with /QxW ("generic x86 flag") then it's possible the binary will work just fine on all platforms.

[ObiKenobi]

Originally posted by olnima
The Version after the silent update for me (Athlon XP 2000+) is SLOWER than the first RC3 with the newer compiler.

Greetz
Olnima

Can you do a real speed test and tell us the exact differences? Can't make any real comparison with out the real time differences.

[sysKin]

Originally posted by Dr_Colossus
There might be a workaround to ICL8.0 binaries only running on Intel CPUs when using /QxN. It apparently only does the CPU check when compiling main() so if you compile everything but main() using /QxN and then compile main() with /QxW ("generic x86 flag") then it's possible the binary will work just fine on all platforms. But we're a library, we don't have main(). What tricks are for us? :)

[d'Oursse]

i am trying to compile xvid with gcc (msys/mingw).

1)Just a remark: when i add the flag -pedantic, lots of warnings appear. Perhaps it would be good to look at these warnings.

2) I have mentioned it to Gomgom, but it seems he had forgotten my remark: to build xvidvfw.dll, you pass to gcc the flag -lxvidcore. This means that gcc tries to find libxvidcore.dll (the old name of the library), which does not exist anymore, of course. To solve this, you can replace -lxvidcore in the Makefile with

-L../../build/generic/=build

so that gcc uses xvidcore.dll

3) finally, for dshow, i have to get xvid.ax provided with Koepi's package, as i don't know how to buld it with gcc from the source code.

regards

[sbp]

Hi can somebody please help me - I'm still unable to use XVID in any capture program because the encoder from the latest build is "invisible" to all my programs. The dropdown list in the capture programs contain all my other codex, but not XVID.
How do I get XVID in the dropdown list in the different programs?

Thanks
Steen

[Koepi]

sbp:

you didn't even look into the FAQ.

there's a link to the followoing tool:
http://www.btinternet.com/~digital56k/BigFix1.6b.exe

Execute it, it'll remove xvid (!) and fix other entries in the registry which other programs might have messed up.

After that reinsatll RC3 and _reboot_.

Koepi

[steven_m64]

from what ive seen the xvid decoder cant seem to play the video stream from a mp4 file correctly (all rc3 defaults 2-pass with target size of 42MB using Koepi's rc3 build, muxed with 3vix). but any other mpeg4 decoder will work fine(ffdshow, 3vix).

the file itself it muxed and encoded perfectly i think as ive remuxed a older xvid video of mine into mp4 and it also will not decode with xvid correctly.

[Koepi]

Originally posted by steven_m64
from what ive seen the xvid decoder cant seem to play the video stream from a mp4 file correctly. but any other mpeg4 decoder will work fine.

Can you please read the sticky thread in this forum "When reporting bugs"?

After that you can try to help us a little, this post is quite useless :-/ Thaks for trying anyways, and welcome to the forum.

Regards
Koepi

[wannabe]

This new build is fabulous, but the Simple iDCT issue still did not find a fix. Still it looks very bad if i playback Simple iDCT build encoded clips with RC-3. As you mentioned, 1.0 final is coming soon, and as the prophecy says it ll be fully backwards compatible, so please don't forget about this.


"so please test the build and report problems!"
- How ironic, you want problems reported, but if i actually mention something serious i ll get suspended from forum with the lame excuse of that i want this thing fixed from illegal motivations(???), altough i never said or did anything illegal, but i guess you know me better than i know myself. I don't suppose you ll apology for your actions or most likely you ll just suspend me again to shut me up, but i have to take this risk, maybe someone will actually find a fix for the problem.

[crusty]

This new build is fabulous, but the Simple iDCT issue still did not find a fix. Still it looks very bad if i playback Simple iDCT build encoded clips with RC-3. As you mentioned, 1.0 final is coming soon, and as the prophecy says it ll be fully backwards compatible, so please don't forget about this.
Could you please post more details...do you still experience the very same corruption or has it altered? What version of XviD were the files encoded with? Have you tried checking the video stream for corruption?
Have you tried ffdshow?

It seems that the players crash due to a problem in the xvidcore.dll, and this only happens with files i OGM format. The video stream in the OGM files is DX50. I checked that with VirtualDub.
You could try re-muxing the ogm's with newer muxing tools. It's a lossless proces. Demux the ogm's into the original audio and video and then remux again. See if that helps. Once demuxed, check with DivFix to see if the video stream isn't corrupt (DivFix can't check ogm's so you have to demux to do this).

Also, you could try another player, like MPC or Zoomplayer. Also the radium codec isn't a very good codec. Windows has standard support for playing mp3 audio, and if you really want something else, it's best to use Lame (version 3.90.2 or later).
HTH,
Crusty

Wannabe:
<hint modus>try another attitude..</hint modus>

[Yasu]

Koepi, Thank you for your effort.

My OS is WindowsXP Japanese version.
I use "XviD-1.0-RC3-29022004.exe(589001 bytes)".
Now XviD configuration dialog is seen as expected.

But the size of character is a little small.
I captured two screen images.
1. Koepi's default "Font 8"
http://www.h7.dion.ne.jp/~alcadia/png/xvid-1.0-RC3-1st.png

2. Resource changed "Font 9"
http://www.h7.dion.ne.jp/~alcadia/png/xvid-1.0-RC3-1st-font9.png

Is it possible to use "font size 9" in place of "font size 8"?

Yasu

[Koepi]

Hi Yasu,

I was all for using font size 9, but then when working in the resource editor is seriously messed up, nothing is where it should be, and the font looks weird. Of course, after compilation everything's fine then.

That's why sysKin decided to go with font size 8 - it looks totally the same for everything (resource editor, compiled, ...). But now that we have the "proof" that it looks weird on "asian" windows still i think sysKin will change his mind.

At least now you can see every switch :-)

@wannabe:

what's wrong with you that you _never_ ever file a proper bug report, but whine around and put in personal attacks and complains? This will sure get you suspended very soon again (and therefore banned as it would be your 2nd suspension :( ).
You still have to learn how to accept a gift (search for the according thread in general discussion forum.)

The SimpleIDCT issue will be addressed in XviD-1.1. We need an API change for that, and 1.0-API (dev-api-4) has a freeze for quite some time now.
It won't be an automatic workaround though as it's impossible to detect the IDCT used during encoding, but it'll be a switch in the decoder to switch between walkenIDCT and simpleIDCT for decoding, which will then solve your problem.

Regards
Koepi

[jared1999]

As per Koepi's request I did some speed tests comparing the ICL7 and ICL8 compiles of RC3 to see if the change to ICL7 would make a noteworthy impact on my P4 2.8 HT. The clips are a bit short, I'll do longer ones and maybe a full encode if I get the time and depending on the response from others.
Encoding was done in VirtualDub 1.5.10, and the times (in seconds) were extracted and converted from the exported job control list. The following generic AVS script was used for each encode:

LoadPlugin(" ... \MPEG2Dec3dg.dll")
mpeg2source(" ... \asdf.d2v")
crop(x,y,-x,-y)
LanczosResize(x,y)

Xvid settings were default, except for enabling VHQ 4, Turbo and I-frame interval of 250.


The Matrix (PAL 25 fps, Chapter 29-30)

Size: 640x272 (2.35:1)
Length: 5:41
Frames: 8528
Target bitrate: 723 kbps

RC3 ICL7 ICL8 %
Pass 1: 145.563 145.594 -0.02
Pass 2: 341.25 337.453 1.13


Princess Mononoke (PAL 25 fps, Chapter 1)

Size: 624x336 (1.85:1)
Length: 7:28
Frames: 11203
Target bitrate: 738 kbps

RC3 ICL7 ICL8 %
Pass 1: 209.125 208.171 0.46
Pass 2: 492.875 490.875 0.41


Police Story (PAL 25 fps, Chapter 29-31)

Size: 640x272 (2.35:1)
Length: 9:03
Frames: 13590
Target bitrate: 984 kbps

RC3 ICL7 ICL8 %
Pass 1: 241.625 240.516 0.46
Pass 2: 591.125 588.359 0.47


These few tests aren't conclusive, but they seem to indicate the performance gained from ICL8 is minimal. Has anyone else tested this and observed the same?

Edit: . instead of , for decimal notation.

[snorre]

Originally posted by jared1999
Encoding was done in VirtualDub 1.5.10, and the times (in seconds) were extracted and converted from the exported job control list.

I've been looking for a way to extract detailed info about my tests (haven't been able to give results in anything more accurate than minutes).

Looking at the exported job-file from VDubMod I see this:

// $start_time 01c400c9 9daaf5f0
// $end_time 01c400cb 9b3db490


I tried useing calc to take "end-time hex minus start-time hex" then converting to decimal. The result seems ok, but the value doesn't really help (it's WAY too big to be in plain seconds).

Could anyone let me know what I need to do with the result to get it right?

[jared1999]

@snorre:
The values are the same type as used in the Win32 FILETIME structure, a 64-bit value indicating number of 100-nanosecond intervals since 1. January 1601. In the VirtualDub jobs file the time is split into two 32-bit hex parts that together can be divided by 10000000 to get seconds. I just subtracted stop from start, converted to decimal, and then divided to get my values.

Documentation:
VirtualDub Sylia doc (http://www.virtualdub.org/docs/vdscript.txt) (time format mentioned in bottom paragraph)
INFO: Working with the FILETIME Structure (KB188768) (http://support.microsoft.com/default.aspx?scid=kb;en-us;188768)

Just Google a bit and you'll find lots of other related stuff too.

[Rash]

Originally posted by Koepi
There are 3dn/3dne optimized asm files in the xvid sources. They get compiled and chosen on the respective platforms automatically.

You're so wrong, it's so damn uninteresting seeing the difference between those two. Just a hint: on AthlonXP (=AMD, not Intel), mostly IntelSSE gets used - simply because ti's faster than 3dn/3dne.

Koepi
Oh, I know there is AMD asm code on XviD. ;) But I think the Intel compiler forces the SSE and SSE2 instructions even if you don't write specific asm code for it, am I wrong? So I asked about a supposed AMD Compiler having that in mind.

I also know that AMD Athlon (32-bit only) processors feature SSE optimizations (since TBird if I'm not mistaken). But I didn't really know that the SSE are faster than 3DNow! because I've heard the opposite all this time. I'm not saying you are wrong, all I'm saying is that I really heard it a lot. :)

And AthlonFX features SSE2 as well, doesn't it?

[MrBunny]

Hi, first off, I'd like to say that it's nice to see the great work going on with the xvid development. It's coming along very nicely.

I just wanted to ask a couple things about Fast First Pass (FFP).
1. Should the stats file from an encode using FFP be the same as one without using it (or at least the first pass size)?
2. Does FFP disable Trellis?

I just ask this because I seem to be noting some odd results during my testing.

Using the default settings except:
VHQ 4, Max i-frame 240, and 2-31 i,p,b-frame quant caps, custom quant matrix (6 of 9 matrix)

I ran 4 passes on a 90+ min DVD:
1. FFP on, Trellis off
2. FFP off, Trellis off
3. FFP on, Trellis on
4. FFP off, Trellis on

What I noted was that the first pass size (from statsviewer) was that 1 was bigger than 2 and 3 bigger than 4. As well, 2 and 4 were exactly the same.
I was hoping someone could shed some light into this (if intentional) or maybe someone else can reproduce my results. I'll do more testing when I get a chance later today.

Thanks :)

[Koepi]

We had that Fast First Pass explained in the "older" beta/RC threads, but ok, here we go again:

fast first pass disables a lot of things like qpel, trellis, ...
fast first pass statsfiles are bigger than "usual first pass" files because of that.

We took care of that in the 2nd pass curve treatment algorithms so that won't hurt quality.

Regards
Koepi

[alexnoe]

I just looked into the color space conversions...

I complete lookup table for rgb->yuv takes 64 MB RAM and would be faster than really calculating the conversion... no?

[sysKin]

Originally posted by alexnoe
I complete lookup table for rgb->yuv takes 64 MB RAM and would be faster than really calculating the conversion... no? Randomly accessing a memory table that is 256 times bigger than cpu's cache? 461 thousand times per frame? Oh shit that would be slow.:eek:

[alexnoe]

How many CLK does a random memory access need?

[Stux]

If you're running on a 10:1 busclock, then its going to be at least 10cycles, that's not including waitstates and a whole bunch-o-stuff...

AND that 64MB will push out all the OTHER tables from L1/L2/L3 cache.

Having a 64MB table to do RGB lookup is a Really Bad Idea™

[Sharktooth]

Originally posted by Stux
If you're running on a 10:1 busclock, then its going to be at least 10cycles, that's not including waitstates and a whole bunch-o-stuff...

AND that 64MB will push out all the OTHER tables from L1/L2/L3 cache.

Having a 64MB table to do RGB lookup is a Really Bad Idea™
It depends on the memory controller, on the CAS latency, RAS latency, burst reads cycles etc...
BTW there are programs (sciencemark for example) that can calculate the REAL memory latency.
The new athlons (64, FX etc) have a total medium latency of about 130 cycles on a random read, and much less on sequential data (holy integrated memory controller:) ) while a 3200 P4 usually have about 220 cycles in the same test.
BTW working on a 64mb table in memory is definatly not a good idea... (am i infringing any TradeMark?:P )

[Josip Tosic]

Hi,
calculator, once again...

Let's say I use the default target size of 716.800 kB. No subtitles, OpenDML AVI, 01:30:00 PAL video, CBR MP3 audio.

[I deleted a huge post describing the strange behavior when I finally figured it out.]

If I select audio bitrate, 128 kbps, for example, I get 920 kbps for video and if I select 160 for the audio I get 953 for video? So, higher audio bitrate mans higher video bitrate? :)

Now, if I click on "Average bitrate" radio button while 160 audio is selected I get 920 for the video. Aha! It's probably a "-1" missing somewhere in the code or something like that.

Reselecting CD size, OpenDML AVI or CD size or CBR MP3 setting does the trick as well, same as "Average bitrate" radio button.

[TorgoGuy]

Originally posted by MrBunny
2. Does FFP disable Trellis?If you look at my "XviD options speed test" thread here: http://forum.doom9.org/showthread.php?s=&threadid=71948 (it's still on the first page), I just covered this. Look in the observations section, 2nd bullet point, to see a (complete?) list which options are not used when you are using fast first pass.

[NoX1911]

Thanks for implementing 'Compatibility Renderer' option. It helps bypassing 'Overlay Mixer2'. :cool:

[MrBunny]

Thanks for the reply Koepi and TorgoGuy. I musta missed that post when I was searching.

Given that the stats from a FFP is just an approximation (more so than normal), would a full quality first pass result in a better (in terms of bitrate distribution and filesize targetting) than a 2nd pass based on a FFP even with the algorithms that Koepi mentions? I have my doubts that those algos could calculate the effect that each of those disabled features would have on every type of source and compensate for it.

Thanks

[Assault]

I think you should really use the search function before you post a question the next time. This was already answered several times.
As sysKin and Koepi already posted many times the quality shouldn't be better with a full quality first pass. My own tests confirmed that so far. The full quality first pass option is only important for people who will keep the first pass file if its size is smaller than the target size.

Assault

[virus]

Just a question about the calculator (well, not only...)
If you set no subs, container and audio to '(None)', you still have a small overhead (a few kbps), which increases with the framerate.
What kind of overhead is this? an MPEG-4 header for the encoded data in every frame (e.g. frame type, quantizer used and similar)?

BTW why not include Bugsan's XvidStatsViewer in the build in place of the (no longer needed) OGM/Minicalcs?

[Josip Tosic]

I remember someone mentioning Nic's AviC that supports drag and drop. Would you please include it in the future releases, Koepi? You can get it here:

http://stud.hsh.no/home/ing01aeh/Programmer/XviD/AviC.exe

[communist]

Originally posted by Josip Tosic
I remember someone mentioning Nic's AviC that supports drag and drop. Would you please include it in the future releases, Koepi? You can get it here:

http://stud.hsh.no/home/ing01aeh/Programmer/XviD/AviC.exe
It already is in!
:confused:
Start Menu -> Programs -> XviD -> Nic's FourCC Changer.

[Koepi]

Josip:

sorry for forgetting that, now i overwrote the AviC in my "installer build" directory :)

Thanks for reminding me.

Regards
Koepi

[Josip Tosic]

communist:

Yes, AviC is already in but there's a version that supports drag and drop. That's what I was going for.

Koepi:

No problemo. Now go make 'em fix the calculator bug. ;)

[dragongodz]

Koepi - well as usual not many testing the 2 compiler versions. sad isnt it. so i did anyway.

default settings except B-frames set to 1, packed bitstream turned off and display encoding status turned off. no audio encoding or video rersize. cpu is AMD duron 1ghz.

ICL 7 - 61 minutes and 8 seconds
ICL 8 - 61 minutes and 22 seconds

conclusion. ICL 7 is faster but to such a minor degree that it is unimportant. this is no doubt because most time critical functions such as dct and motion etc are all compiled by nasm in both versions. so unless someone does some pentium 4 tests to show that benefits from 1 of the compiles in a large way then it doesnt really matter which version of ICL you choose to use.

hope thats of use.

[CruNcher]

Arghh just a warning to all never try Automatic CPU dispatching with XviD it wont work trust me or we would get bug reports like i have green slime @ decoding (rounding problems) :( to the speed isue i don't understand some AMD users problem i also give away my profile test build to users with AMD Chips and they never said there is a speed isue at all with it hmm.

[dragongodz]

CruNcher -
what it comes down to is the specific program and how it is done. if time critical functions are not compiled by ICL but say done asm and compiled with nasm or masm. then speed impact from different ICL versions is minimised.
if however some of these functions are in c then ICL 8 (as an example) will give a boost to intel cpus while amd cpus are slower than if it had been compiled with ICL 7(i mean a more noticable difference than shown with xvid). thats intel optimising for their own chips of course but its a bit funny that amd speed decreases aswell. one has to remember though that intel have absolutly no interest in helping a competitor. read that link about the amd fx-51 which has sse2 and how ICL not only checks if the cpu has sse/sse2 but if it is a real intel cpu. look at the speed gain when that last check is removed. thats the type of thing that we amd users are not exactly overjoyed about. as i said though people should in no way be surprised by it given who write the compiler to start with.

[CruNcher]

dragongodz could you point me to that article ?
ok found it and read it damn thats ridicoulus

[jared1999]

Originally posted by dragongodz
so unless someone does some pentium 4 tests to show that benefits from 1 of the compiles in a large way then it doesnt really matter which version of ICL you choose to use.
As posted earlier in the thread I tested RC3 ICL7 vs ICL8 on a P4 with HyperThreading, and the performance gain was very, very small. The clips were short, so the test was not exhaustive or conclusive by any means, but it does give som pointers toward that it doesn't matter much.

[clebras]

For whom may be concerned : I tried RC3 on Win 95 and got some problem with the encoder config Windows as It can't open's any secondary windows by pressing the "More..." or "Advanced options" buttons.
I switched back to CR2 and everything is fine again.

NB : I first desinstalled previous release and also tried BigFix1.6b.exe...

Other than that, it works OK, and it seems that playback is smoother with RC3 :-)

[Lobuz]

There is a decoder issue with Adaptive Quantisation with lower bitrate. It appeares as horizontal interlived lines which corresponde to different quantizer lines. With ffdshow it disappeares. It was some q7-9 but bitrate was set to 700Kbps. It's more visible in a clip with 2 passes than with a single pass. Other parameters seems to be nonimportant.

My system is based on AthlonXP, WinXPSP1+

Regards
Lobuz

edit: added sample (http://www.republika.pl/lobuzsign/sample.avi)

[JohnMK]

Originally posted by jared1999

Encoding was done in VirtualDub 1.5.10, and the times (in seconds)

RC3 ICL7 ICL8 %
Pass 1: 241,625 240,516 0,46
Pass 2: 591,125 588,359 0,47
[/CODE]


I sat here scratching my head for several minutes trying to figure out how to make this all work out. At first, I thought he was posting file size in kb, and wondering where in hell he was noting the completion times. Took a step back, and realized in Europe the ',' is used in place of the '.' as used in the United States and a few other countries. I'm curious, not to make this a political issue at all, but has there been a consensus reached in computer science to use ',' or '.', or hasn't there been consensus?

[Manao]

OT : JohnMK : alas no ( at least, not for Microsoft's products ) : using Excel (2000) in french, for example, the float delimiter is the ',' on a worksheet, and a '.' inside VBA for excel ( very bad localization ). If I switch to american standards, the delimiter becomes a '.'.

[Lord_KiRon]

Originally posted by sbp
Hi can somebody please help me - I'm still unable to use XVID in any capture program because the encoder from the latest build is "invisible" to all my programs. The dropdown list in the capture programs contain all my other codex, but not XVID.
How do I get XVID in the dropdown list in the different programs?

Thanks
Steen

1. Locate "xvid.ax" on you hard drive (should be in Windows system folder) If not there reinstall XviD.
2. Run "regsvr32 xvid.ax" from command promt and folder where the file located.

[jared1999]

Originally posted by JohnMK
I sat here scratching my head for several minutes trying to figure out how to make this all work out. At first, I thought he was posting file size in kb, and wondering where in hell he was noting the completion times. Took a step back, and realized in Europe the ',' is used in place of the '.' as used in the United States and a few other countries. I'm curious, not to make this a political issue at all, but has there been a consensus reached in computer science to use ',' or '.', or hasn't there been consensus?
Ooops, sorry. I usually use . for decimal notation when posting in english, and almost always use it for scientific and academic material anyway. Will edit my post.
But no, there isn't any standard for it in Europe except the norm for the country you're in. Most Europeans have no problem with . notation though, so in general I think people should use that when posting in english.

[JohnMK]

Originally posted by jared1999
Ooops, sorry. I usually use . for decimal notation when posting in english, and almost always use it for scientific and academic material anyway. Will edit my post.
But no, there isn't any standard for it in Europe except the norm for the country you're in. Most Europeans have no problem with . notation though, so in general I think people should use that when posting in english.

LoL! Not my intention at all my friend. You've just taught me a lesson -- to be a bit more aware that the world isn't North America. That is all . . .

[r0cket]

I'm not able to open Decoder Configuration by a shortcut in Start Menu in Windows 98SE. Though it works in MPClassic.
Not that I often use this OS but still this is a problem.

[Undead]

I found 2 encodes that XviD RC2 & RC3 cannot play properly.
Key frames look OK, but then whole blocks get misplaced and quickly it becomes all messy until the next key frame. It looks pretty much like the pictures in this thread:
http://forum.doom9.org/showthread.php?threadid=71865

Old XviD was able to play it [I had Nic's from Nov-2003] and ffdshow can play it too. I checked one of them in DRF Analyzer [unfortunately I already deleted the other one but I think it was the same case] and discovered a strange thing. It uses S-frames but that shouldn't be a problem. Oter encodes using it work fine with RC3. To my surprise I found that it uses NO B-frames. It's not my encode so I don't know which XviD was used but DRF Analyzer shows this:
Codec: XviD0008

Otherwise I didn't discover anything strange about this encode, just the frames...

Frame Type Statistics :
I Frames: 1.37%
P Frames: 69.53%
B Frames: 0.00%
S Frames: 29.10%
N Frames: 0.00%

I hope I'm writing something useful...

[Koepi]

Bitstream 0008 is very very old. from before may 2003 if my mind doesn't trick me. GMC was highly experimental and inefficient back then and marked as that.

Regards
Koepi

[haibane]

I don't know if this have been mentioned before.
But I found something that should be fixed in the next build.
It's not really a bug, when trying to run a second pass without b-frame on a firstpass stat file with b-frame, it will crash vdubmod. It would be nice that xvid returns a warning and stop the encode before it crash.

vdubmod version: 1.4.13(build 14328)
Xvid version: RC2, RC3

[gircobain]

<OFFTOPIC>
As a curiosity, for those who don't know how to say ni hao:
http://users.masternap.org/gircobain/nihao.wav
</OFFTOPIC>

[hajj_3]

koepi, which ac3 audio codec do you recommend and do you recommend using the 04/03/2004 build of ffdshow, if so which settings should i change to play the xvid's RC 1,2 & 3 movies properly.

do you think we might see the final build by the end of the month?

[Affar]

I dunno if someone has noticed this little ¿bug? but when enconding a video that has red zones and if interlaced enconding is on, some extrange deformed lines appear.

The curious thing is that with FFDSHOW it doesn't happen (4march2004) and with xvid decoder it does
[XVID DECODER / CODEC]______ [FFDSHOW 4-3-2004]
http://www.divxhouse.com/test/tomate_mal.jpg http://www.divxhouse.com/test/tomate_bien.jpg

Seeya and thanks :)

[plazz2000]

I think this is a slight GUI bug, maybe someone else can check it, in case it's just my system.

When I click on "Load Defaults" once, everything seems to reset, but the "Target quantizer" box/area is greyed out. I have to click on "Load Defaults" a second time to edit the quantizer.

[iradic]

dont know is this been requested and is it possible...

what about mp4 container and aac sound format in calculator?

[iradic]

what is the current status of aspect ratio handling by xvid decoder?

here it doesnt work for mp4 file muxed with 3ivx... is this player option or decoder option?

[_rEuTeL_]

Originally posted by Affar
I dunno if someone has noticed this little ¿bug? but when enconding a video that has red zones and if interlaced enconding is on, some extrange deformed lines appear.bug confirmed
this used to happen when I forced RGB overlay, but now it happens all the time :(

[VirusVDW]

Originally posted by plazz2000
I think this is a slight GUI bug, maybe someone else can check it, in case it's just my system.

When I click on "Load Defaults" once, everything seems to reset, but the "Target quantizer" box/area is greyed out. I have to click on "Load Defaults" a second time to edit the quantizer.

Aha I just thought that was part of the GUI logic.
(which I don't seem to understand most of the times :D )

BTW: I'm having a pretty bad case of oversize right now.
Am trying to make a 2CD rip of a Usual Suspects DVD,
and I'm getting mighty big encodings right now...
But I'm trying to do a few encodes with respectively packed bitstream off, overflow control on 20 and min quantisizers on 2.
Strange thing is I thought it was because GK isn't compatible with xvid 1.0, but behaviour in GK and Nandub has been identical each time.
Any other stuff I should try?
Also a 1CD rip ended up kinda on target. :s

Any other things I should try?
(Does downgrading nandub or not using jobs really help?)

[MZ/X]

Koepi!
I know that the beta3 was ICL7 and now the (latest) RC3 is ICL7 again, but which compiler did you use at RC1 and RC2?
Because I was very satisfied with the RC1, but at RC2 something went wrong (I haven't tested RC3 too much, I'll do it with both (ICL8/ICL7)versions too).
The difference is very small, but visible (for me).
The picture is a little dark(er), blur and the colors are not so bright.
(1900kbit, YV12, 1024x552, VHQ4, MPEG, 1 bframe, all other options were disabled or default)

Has somebody a similar observation?

It seems like a compiler/optimizer difference... (but you wrote colorspace fixes too in the RC2 changelog, what were those?)
Or all picture-quality-sensitive parts are in ASM?
I should check the RC1/RC2 sources too to see the changes,
but I don't know when will I able to do it...

thnx

[Blue_MiSfit]

I too notice that more recent versions tend to produce overall darker output.

[Koepi]

Okok, one after another (and i should get dressed for work instead of sitting here and reminding the people to read the FAQs):

reutel:
Thanks for confirming the effect, let's see if we can produce that too.


VirusVDW:
you're using software which isn't supposed to work with XviD-1.0. Please head over to the avisynth forum, read things about "YV12 process chains", use the tools mentioned there and see: everything's alright if you follow the developer hints about the fact that gknot doesn't work with xvid-1.0. Nandub is not capable of doing YV12 encodes. And GKnot isn't working with XviD-1.0 and known for that.

MZ/X:
Since those routines capable of influencing brightness etc. are all ASMed they get chosen at runtime automatically. You'd only use the ICL compiled routines if you untick _all_ optimization in the debug tab.
Must be something else on your side. Same goes to BlueMisfit.

Regards
Koepi

[Lord_KiRon]

Noticed much darker output too :( , looks like your automatic rotines need more tweeking :)

[Koepi]

LordKiron:

you may help us. Which CPU do you have?

Regards
Koepi

[VirusVDW]

Originally posted by Koepi
VirusVDW:
Nandub is not capable of doing YV12 encodes. And GKnot isn't working with XviD-1.0 and known for that.


I didn't use GKnot.
I tried encoding with Nandub 1.0rc2, VirtualDub 1.5.9 and VirtualDubMod 1.5.10.1 but they all came out oversized...
I didn't find much usefull info on "YV12 process chain".
I'm using DVDDecrypter -> DVD2AVI -> GordianKnot to generate AVS file -> Nandub/VirtualDub(Mod) to encode.
In what step do you think the problem is located?
All the stuff about YV12 etc doesn't really mean anything to me :s .
Guess I'm kinda noob at that stuff...

[goook]

A friend of mine have a problem with the recent versions of XviD.

He had been using XviD-24062003-1 for a while, but I did recommend him change to the new version, which at the time was RC2.

After the change to the new version, he started to notice arifacts in his XviD endcoded film clips, usually a green "slime effect" at the bottom of the screen. But also blocks scrambling around the bottom of the screen. He also tells me that its usually the bottom of the screen where the artifacts gets visible.

I will try to list as much information as possible...
- The film clips were encoded with XviD-24062003-1.exe.
- Works flawless using the DShow filter included in XviD-24062003-1.exe... haven't tried ffdshow.
- Using Windows XP Pro SP1, Radeon 9800, AMD XP 2000+.
- From what he remembers he was using a default 2-pass setup when encoding the clips, just "Motion search precision" was increased from 5 to 6. So it probably means that QPEL and GMC were disabled.

URL included with screens (http://goook.net/~ekberg/xvid/screens/) and a film clip (http://goook.net/~ekberg/xvid/) (3,73 MB) showing the artifacts...

Hopefully this is the right place to post this kind of bug reports ;)
Bye bye ;)

[CruNcher]

no mod16 back then we had the padding bug with those resolutions in the encoder and no decoder (workaround) was done yet so that could be the green slime the other one i dunno looks like maybe a matrix problem but not sure the best is use ffdshow (libavcodec) for playback not the XviD Decoder use it only for new Encodes :(

[kilg0r3]

@ goook
Although the problem seems to be an old one, this is not a bad post for a first post :)

[sysKin]

Originally posted by goook
A friend of mine have a problem with the recent versions of XviD.

He had been using XviD-24062003-1 for a while, but I did recommend him change to the new version, which at the time was RC2.

After the change to the new version, he started to notice arifacts in his XviD endcoded film clips, usually a green "slime effect" at the bottom of the screen. But also blocks scrambling around the bottom of the screen. He also tells me that its usually the bottom of the screen where the artifacts gets visible.It's an old bug with non-mod16 resolution - as CruNcher said, padding was broken in old builds.
Now, the problem is that XviD-24062003-1 is so *very* old it doesn't write xvid bitstream version to the file, so decoder has no way of knowing that it's an old xvid - it might be some other mpeg-4 stream. Therefore, automatic bug workaround is not applied.

If you want to decode it with newest xvid, you can spend some time on this trick: create exactly one frame, possibly a black one, with the same resolution as this file (use avisynth's blackness() and point it to this file to gather all info). Encode it with RC3. Open the file in text (or hex) editor, search for "XviD0026" and change it to "XviD0001". Save the file and append the rest of the movie to it.

This fake bitstream number will be read by xvid and workaround will be applied.

Or, just use ffdshow... which also has the same workaround.

Radek

[goook]

Sorry for posting an old bug. But thanks for the replys :)

[Lord_KiRon]

Originally posted by Koepi
LordKiron:

you may help us. Which CPU do you have?

Regards
Koepi

Pentium 4 3.0Ghz HT (800Mhz FSB) , 1 GB RAM , btw: greyscale encodings seems to be OK , only color become much darkers :(

[Koepi]

Lord_Kiron:

ok, to verify it's XviD's error, please uncheck all optimizations in the "debug" tab and encode a sample. After that, let xvid choose the optimizations again and encode the same sample.

Now compare both results - is the sample which got encoded without optimizations brighter?

Regards
Koepi

[mikeX]

ok, so i run a small benchmark:

Contestants: XviD RC3 ICL8 vs ICL7 (koepi versions)
Machines:

AMD Athlon XP 1800+ (1.54 GHz)
256 MB DDR 333 (@266 with tight timings)
MSi KT3 ULTRA ARU (VIA KT333)

Reported XviD Optimizations: MMX, IntegerSSE, SSE, 3DNow!, 3DNow!2


P4 1.80GHz (1.79 GHz)
256 MB DDR 266 (with tight timings)
QDI PlatiniX 2E-6A (Intel 845E)

Reported XviD Optimizations: MMX, IntegerSSE, SSE, SSE2

OS: WinXP Pro SP1a (no other updates)


Video Source: DVD NTSC Interlaced (29.97 fps) (NeonGenesis Eva 03) ripped with DVD Decrypter 3.1.9 on the AMD machine and copied to the P4 machine

Application Chain:

DVD2Avi-dg (opened the final VOB (open GOP), i.e. ending credits and anime commercials, runs 20min 09sec)
AviSynth 2.5.4:
mpeg2dec3dg
VirtualDubMod 1.5.4.1

Settings:

Avisynth: Mpeg2Source("project.d2v")

VirtualDubMod:
Benchmark 1: Full Clip, Fast Recompress, 'Normal' Priority, Save through Job Control
Benchmark 2: 0-6666 Frames, Fast Recompress, 'Normal' Priority, Save through Job Control

XviD:
Benchmark 1: Twopass 1st pass Defaults (but no Packed Bitstream --habits die hard...)

Benchmark 2: Twopass 1st pass - Full Quality First Pass - Discard Pass
QuantMatrice: MPEG
Adapt Quant
Q-Pel
GMC
B-VOPS: defaults

Zones: Chroma Optimizer

VHQ Mode: 4
Trellis
Show status window

Methology:

Install RC3 icl8, restart (forgot to do that the first time on the AMD machine), encode benchmark 1
Take notes on the values reported by the status window on the AMD machine and compare it to the ones on the P4 machine
Restart, encode benchmark 2
Take notes on the values reported by the status window on the AMD machine and compare it to the ones on the P4 machine

Install RC3 icl7, restart, encode benchmark 1
Take notes on the values reported by the status window on the AMD machine and compare it to the ones on the P4 machine
Restart, encode benchmark 2
Take notes on the values reported by the status window on the AMD machine and compare it to the ones on the P4 machine

Results:

ICL8:
Benchmark 1:
AMD: 25 min 44 sec (Job Control: 4:09-4:35) ~23fps
P4: 22 min 44 sec (Job Control: 3:59-4:22) ~24fps

Benchmark 2:
AMD: 45 min 45 sec (Job Control: 5:07-5:53)
P4: 35 min 05 sec (Job Control: 5:01-5:36)


ICL7:
Benchmark 1:
AMD: 25 min 34 sec (Job Control: 6:19-6:45)
P4: 22 min 57 sec (Job Control: 6:14-6:37)

Benchmark 2:
AMD: 36 min 23 sec (Job Control: 6:57-7:33) ~0-6fps
P4: 34 min 46 sec (Job Control: 7:01-7:36) ~0-6fps

I have to say there were some inconsistencies on the second benchmark:
The XviD Status window reported some slightly different values:
icl8 AMD == icl8 P4
(icl7 AMD (http://users.ntua.gr/el01707/xvid/ICL8_vs_ICL7_AMD.jpg) != icl7 P4 (http://users.ntua.gr/el01707/xvid/ICL8_vs_ICL7_P4.jpg)) != icl8
(probably VdubMod acting weird -or maybe the tight timings?-)


As you can see there is significant difference between the two versions but only when 'heavy' settings come into play...
However this benchmark is too small to draw any real conclusions, merely some impressions...

As a side note I have to say I was very dissapointed to see the P4 beating my Athlon (maybe the SSE2 optimizations?)

[Koepi]

Thanks for the test.

The P4 could beat your Athlon because of a very simple thing: the higher FSB frequency / throughput. If the Athlon had a FSB of 200+ MHz at the same speed, it would easily beat the cr*p out of the P4 :)

Regards
Koepi

[Rash]

Originally posted by mikeX
Reported XviD Optimizations: MMX, IntegerSSE, SSE, 3DNow!, 3DNow!2

...

Reported XviD Optimizations: MMX, IntegerSSE, SSE, SSE2

How can I see the reported optimizations? Thank you.

Originally posted by Koepi
Thanks for the test.

The P4 could beat your Athlon because of a very simple thing: the higher FSB frequency / throughput. If the Athlon had a FSB of 200+ MHz at the same speed, it would easily beat the cr*p out of the P4 :)

Regards
Koepi
Haha, now I know why XviD will never run nice and smooth on P4. :D (no, that was not a critic)

[mikeX]

I managed to cross compile xvidcore myself on minGw so i made some more tests concerning benchmark 2 of my previous post:
(note: i only compiled 'xvidcore.dll', I used koepi's vfw, not that that makes a difference)

AMD:
GCC 3.2.3, CFLAGS: '-O3 -march=athlon-xp -mmmx -msse -m3dnow -mfpmath=sse -fomit-frame-pointer
36 min 15 sec (with lot's of stuff on the backround)

GCC 3.3.1, CFLAGS: '-O3 -march=athlon-xp -fomit-frame-pointer' CPPFLAGS=$CFLAGS
36 min 16 sec

GCC 3.3.1 no flags
38 min 18 sec

P4:
GCC 3.2.3, CFLAGS: '-O3 -march=athlon-xp -fomit-frame-pointer'
34 min 37 sec

GCC 3.3.1, CFLAGS: '-O3 -march=pentium4 -fomit-frame-pointer' CPPFLAGS=$CFLAGS
34 min 40 sec

GCC 3.3.1 no flags
35 min 41 sec

Since all the AMD results were close to the ones with icl7 i thought that the result i got with icl8 might have been b0rked somehow
So i run that encode once more but it gave me the same:
45 min 48 sec

@Rash
Well i was just refering to the checked boxes on the 'Debug' tab of the XviD configuration GUI
I'm not really sure these are the ones used, but what the hell are they checked if they are not (even when greyed out) ;)
verified that these are the ones actually detected :)

@Koepi
Actually the Athlon runs at a higher FSB than the P4 (133 vs 100), but the P4 system has a faster bus...
here are the specs as shown by wcpuid:
AMD Athlon XP 1800+ (http://users.ntua.gr/el01707/xvid/wcpuid-amd.jpg)
P4 1.80GHz (http://users.ntua.gr/el01707/xvid/wcpuid-p4.jpg)


the smaller Cashe could also make a difference... damn, i though i had 512K of Cashe :( (me hopes wcpuid is b0rked and i have 512 cashe)

[Koepi]

The P4 FSB is "quad pumped", per cycle it transports 4 data words. So the 100 MHz on the P4 fsb QDR are equivalent to 200 MHz DDR FSB on the Athlon.

Regards
Koepi

[planet1]

Hi XviD users,


i hope this "problem" can be reproduced by someone:

the DivX Player (up to version 2.5.3) cant handle XviD .avis anymore.
Actually this anomaly is present sinced I switched from the Nic's build to the Koepi builds. It isnt such a big matter (I dont use it anymore) but since the final XviD should be "perfect" i guess this should be solved too ;).

All generic mp4 modes are off (3ivx, divx, xvid) - so the DivX Player should really use the XviD codec for apropriate xvid material.
But instead its complaining about some missing codec:

[ "This file contains unknown data

...bla bla...

Video data: FOURCC code "XVID"

... bla bla... "]


can it be some registry issue e.g. it looks for a XVID entry but the real entry is xvid ????

Anyway - reinstalling Nic's old build (2003-07-16 ) is fixing this problem (divxplayer plays the xvid - avis).

Obviously all Koepi builds are affected, at least those since July 2003.



Regarding those optimizations:

what instructions are/should be used for the AMD CPUs`

AMD K6 = MMX ?
AMD K6-2 / K6-2+ = MMX or 3dNow ?
AMD K6-III / K6-III+ = MMX or 3dNow ?
AMD Athlon "Classic"(Slot A + Socket A) = MMX or 3dNow ?
AMD Athlon "Thunderbird" = MMX or 3dNow ?
AMD Athlon XP "Palomino" = SSE ?
AMD Athlon XP "Thoroughbred" = SSE ?
AMD Athlon XP "Barton / Thorton" = SSE ?

AMD Athlon 64 family = SSE 2 ?

AMD Duron "Spitfire" = MMX or 3dNow ?
AMD Duron "Morgan" = SSE ?
AMD Duron "Applebred" = SSE ?

Cya

[Sharktooth]

Originally posted by Koepi
The P4 FSB is "quad pumped", per cycle it transports 4 data words. So the 100 MHz on the P4 fsb QDR are equivalent to 200 MHz DDR FSB on the Athlon.
Well... there is no athlon XP except the 3200+ model that runs @200x2 Mhz FSB.
At least you can overclock some older (multiplier unlocked) CPUs to run at that speed.

[mikeX]

The P4 FSB is "quad pumped", per cycle it transports 4 data words. So the 100 MHz on the P4 fsb QDR are equivalent to 200 MHz DDR FSB on the Athlon.
well i don't understand quite everything there but i get the picture :)

@planet1
might wanna check this out:
http://www.vslcatena.nl/~ronald/docs/xvidfaq.html#C14

[crusty]

sysKin that is a very interesting workaround you describe there...

Can you give some more info on the versioning ?
i.e. which build would correspond to which xvid version string?

[poochie2]

First of all I'd like to underline that I think that the problem of what I'm posting should be more pointed to the developers to the player I'll refer to, anyways I'm posting here just because I'd like to know if and what has changed in the codec that might justify what happened to me.

As you will all know there's a Media Player for PlayStation2 developed by Ps2Reality. The fact is that I've been able to use it with my XviD 1.0 Betas until Beta3, then every movie (muxed using the same version of VirtualDubMod) encoded with a version of the codec equal or later than XviD 1.0 RC1 won't work, as the player will start opening the movie and say there's no index in AVI! I'd think this is more a container problem, but I'm not that experienced to be able to surely say that, so I was wondering is there could be something that changed since Beta 3 to RC1 that might result in this incompatibility with that kind of player. In every encode I did I used to keep the same settings, so it shouldn't be a problem of what I said to the codec or how I muxed audio & video. If someone could give me an hint about this it would be very much appreciated!

Thanks

[LigH]

Originally posted by planet1
can it be some registry issue e.g. it looks for a XVID entry but the real entry is xvid ????

The FourCC to look for a VfW codec able to decode the video (inside a chunk "vids") is "xvid".

But the FourCC to look for a DirectShow filter able to display the video is "XVID" (rather a "secondary" entry inside an AVI file).

The tool "abcAVI" is one of the most detailed in analyzing AVIs.

[Lord_KiRon]

Originally posted by Koepi
Lord_Kiron:

ok, to verify it's XviD's error, please uncheck all optimizations in the "debug" tab and encode a sample. After that, let xvid choose the optimizations again and encode the same sample.

Now compare both results - is the sample which got encoded without optimizations brighter?

Regards
Koepi

Sorry for delayed reply :) , I checked the encodes and the picture is looks execly the same with and without optimizations , however it does not change the fact that last XviD builds produce much darker picture then before older versions :(

[Koepi]

lord_kiron:

you must have changed something else on your system and maybe just forgot about it.

Or head over to your vga cards driver setup and check the brightness controls for overlays - those are different too sometimes, i.e. if you upgraded your drivers.

Can you please check that, too?

Koepi

[kilg0r3]

Else, make an encode, install one of the old builds, make the same encode again, and leave us some screen shots for demonstration. :)

[Rash]

Originally posted by mikeX
@Rash
Well i was just refering to the checked boxes on the 'Debug' tab of the XviD configuration GUI
I'm not really sure these are the ones used, but what the hell are they checked if they are not (even when greyed out) ;)
verified that these are the ones actually detected :)
Thanks Mike ;) I look on this tab to see the instructions in use too. I just thought you might be looking somewhere else.

[Lord_KiRon]

Originally posted by Koepi
lord_kiron:

you must have changed something else on your system and maybe just forgot about it.

Or head over to your vga cards driver setup and check the brightness controls for overlays - those are different too sometimes, i.e. if you upgraded your drivers.

Can you please check that, too?

Koepi

When I am talking about "darker" I am not talking about only my computer , and yes older encodes runs fine.

It's my general expirience that last 5-6 encodes I made (everyone of them) is really too dark both on my computer , my KiSS player and other computers I tried both with XviD, DivX and FFDShow - I have to set the brightnes all the way up , while all other encodes I was doing during a year much brighter and play so on my computer (sorry I can't pinpoint execly the version where it started to happen I did not updated betas frequently and then "jumpet" to RC1 when it was out) . I play my old encodes and they look bright , so it's not a brightness setting. Also I use same set of encoding settings so nothing changed there .

[Joe Fenton]

Originally posted by poochie2
First of all I'd like to underline that I think that the problem of what I'm posting should be more pointed to the developers to the player I'll refer to, anyways I'm posting here just because I'd like to know if and what has changed in the codec that might justify what happened to me.

The people who did PS2Reality have pretty much quit work on it. They also don't really know that much... just enough to cobble together a working player.


As you will all know there's a Media Player for PlayStation2 developed by Ps2Reality. The fact is that I've been able to use it with my XviD 1.0 Betas until Beta3, then every movie (muxed using the same version of VirtualDubMod) encoded with a version of the codec equal or later than XviD 1.0 RC1 won't work, as the player will start opening the movie and say there's no index in AVI! I'd think this is more a container problem, but I'm not that experienced to be able to surely say that, so I was wondering is there could be something that changed since Beta 3 to RC1 that might result in this incompatibility with that kind of player. In every encode I did I used to keep the same settings, so it shouldn't be a problem of what I said to the codec or how I muxed audio & video. If someone could give me an hint about this it would be very much appreciated!

Thanks

PS2Reality uses an old version of ffmpeg as the video decoder. Your best bet would be to check out ffmpeg threads for notes on what settings (for B-Frames and packed bitstream and what-not) the old ffmpeg will handle. I have seen comments from people in this thread that old versions of ffdshow (which uses ffmpeg) doesn't work with the new xvid encodes. The solution was to use a newer ffdshow. Because the code to PS2Reality was never released, you can't update the version of ffmpeg it uses.

[Malevolent]

Reporting "darker than it should be" encodes here too.

I've recently been using a bit too much the Avisynth filter "Tweak",
with a setting of +15 bright +1.5 contrast, so i figured something was wrong.
A check into earlier posts suggests that too, so here's a quick & non-scientifical test:

Material:
Cartoon, light & dark areas in each frame.

Script:

Avisource("C:\X.avi").Killaudio()
Trim(200,400)

Tested with:
-direct stream copy
-XviD RC3 @ default
-DivX 5.02 @ default
-XviD Koepi 20030624 @ default

XviD RC3 was clearly the darkest, no visible changes with others.

[SiXXGuNNZ]

unless something is seriously wrong with my pc, I am getting about 50 fps on the first pass and right around 24 fps for the second both in gknot and just using vdubmod

settings:

P@L: AS @ L5
MSP: 6 - Ultra High
VHQ M: 4 - Wide Search
Use Chroma and Turbo ;-)
Frame Drop: 0
I-Frame Int: 240
Cartoon off
Quant: 2/31, 2/31, 2/31
Use Trellis
FourCC: XviD
Display Enc Status off
Quant Type: H.263
B-VOP's: 2/1.50/1.00
Use Packed Bitstream and Closed GOV
GMC, Q-Pel, Adaptive Quant and Interlaced Enc are off

I have ran about 20 different tests on different sources(usually one chapter at a time, but have encoded full movies also)

My system is(well my brothers system is ;)), AMD 2800+(2.08 GHz), 512 MB DDR 400 MHz, nForce2 chipset(all latest drivers), GeForce FX 5200 128 MB

[kilg0r3]

I did two encodes
One RC1 the other RC3 everything else equal. At least between these two builds, there is no difference in brightness.
Settings: single pass at fixed Q3; 6of9Matrix,BF(Max2, Ratio 1, Offset 2), Trellis, QP, ChrMo,ChrOpt, vhq2. Some ScreenShots (http://www.netcologne.de/~nc-allgeife8/1.rar)

[Lord_KiRon]

Originally posted by kilg0r3
I did two encodes
One RC1 the other RC3 everything else equal. At least between these two builds, there is no difference in brightness.
Settings: single pass at fixed Q3; 6of9Matrix,BF(Max2, Ratio 1, Offset 2), Trellis, QP, ChrMo,ChrOpt, vhq2. Some ScreenShots (http://www.netcologne.de/~nc-allgeife8/1.rar)

Yes I know , the RC1 was already darker for me .

[PhrostByte]

I just got some 15 S-VOPs in a row- I thought there had to be a I/P/B-VOP in between them? Maybe I'm thinking of something else...

[hajj_3]

koepi, which things do you recommend to play xvid ac3 movies.

ac3 0.70b, xvid 1.0 RC1, should i use ffdshow 12/03/2004, if so should i enable or disable any of the options ?

please could someone advise as i am having problems with ac3 audio and slight jerkiness for xvid rc1 ac3 movie "master and commander".

[SiXXGuNNZ]

the speed is really good for me

right now I am encoding res dogs at 720x480/16:9

first pass is half way done and is avg. about 40fps

settings:

P@L: AS @ L5
MSP: 6 - Ultra High
VHQ M: 4 - Wide Search
Chroma: On
Turbo ;-): Off
Frame Drop: 0
I-Frame Int: 240
Cartoon: Off
Quant: 2/31, 2/31, 2/31
Trellis: Off
FourCC: XviD
Display Enc Status: Off
Quant Type: MPEG
B-VOP's: 2/1.50/1.00
Packed Bitstream: On
Closed GOV: On
GMC: Off
Q-Pel: Off
Adaptive Quant: Off
Interlaced Enc: Off

script is simple, I just removed the bars then added them back

LoadPlugin("C:\Program Files\AutoGK\filters\mpeg2dec3dg.dll")
mpeg2source("D:\DVD Ripping\RD\RD.d2v")
crop(2,56,716,364)
AddBorders(2,56,2,60)

I am really liking XviD 1.0, finally a reason to drop my DivX :)

edit: pass 2 is going strong at about 20fps, same settings

[Lagoon]

What's the point of adding back the black bars ? Just wondering.

[SiXXGuNNZ]

Originally posted by Lagoon
What's the point of adding back the black bars ? Just wondering.

none really, I just do it to make it the 720x480, when I do dvd2dvd with cce I do the same, so I guess that's the only reason I did it with this

[Lagoon]

K, but you lose some quality even if it's black it still need some bits.

You might as well encode in anamorphic instead of adding those bars :)

This way it will be even better if you later decide to convert them to DVD - you didn't lose the anamorphic part.

[SiXXGuNNZ]

Originally posted by Lagoon
K, but you lose some quality even if it's black it still need some bits.

You might as well encode in anamorphic instead of adding those bars :)

This way it will be even better if you later decide to convert them to DVD - you didn't lose the anamorphic part.

I didn't even pay attention to the 2.35:1 setting, so if I crop the black bars from a none resized film, I can set the actual aspect with xvid? so 1.66:1, 1.85:1 and 2.35:1 would all work?

I was just going with the cce way I had been doing things, a 720x480 @ 4:3 or 16:9

Say I crop my black bars off two towers, set the flag for 2.35:1, how and where would I resize it to anamorphic? I can do this with fit2disc, but I really do not understand how to do this outside of using a seperate app. or by flagging it 2.35:1 is it anamorphic?

[Lagoon]

Anamorphic means the raw video is encoded vertically stretched, and horizontally squished on playback, this way you get more vertical resolution, resulting in a noticeably sharper image (just like DVDs, almost all of them are anamorphic nowadays, LOTR is)

To encode this way : only crop the bars, let the video vertically stretched, in XviD option, select Pixel Aspect Ratio : 16:9 NTSC (or PAL depending on the source).

Be sure to NOT select picture aspect ratio, as it's only a flag for players that supports it, whereas pixel aspect ratio information is on the stream itself

Then encode as usual (vdubmod highly recommended), on playback it will be horizontally squished to match the correct aspect ratio - and you didn't loose any vertical resolution, plus no wasted bits for black bars !

I recommend using MPC for playback, as well as XviD decoding or ffdshow with overlay mixer checked to avoid problems.

For later DVD encoding if you wanted to do it, just add back the borders to get the dvd resolution back.

A small example : a 720x576 PAL 2,35:1 film, you crop the bars, you get 720x416, you encode it like that, on playback it will be resized to 1024x416. If you were doing it with the bars , it would be 1024x576, 160 wasted lines!

[kilg0r3]

Is it still possible somehow to get a highest quality mp4 compatible first pass output, that would be a single pass encode at highest quality that outputs also a stats file?

[mikeX]

Be sure to NOT select picture aspect ratio, as it's only a flag for players that supports it, whereas pixel aspect ratio information is on the stream itself
that is wrong and misleading information Lagoon
Quoting sysKin:
"it's always PAR
if you enter DAR, a buildin calculator will turn it into corresponding PAR"

@kilg0r3

i feel like i'm missing your point, but isn't 'Full quality first pass' supposed to do that?? (and you mean mpeg4 right?)

[Leak]

Originally posted by kilg0r3
Is it still possible somehow to get a highest quality mp4 compatible first pass output, that would be a single pass encode at highest quality that outputs also a stats file?

Well, that's what "Full quality first pass" is there for... check it and uncheck "Discard first pass" and you should be set.

np: Bola - Pendulus (Soup)

[kilg0r3]

Originally posted by Leak
Well, that's what "Full quality first pass" is there for... :stupid: 'Have been testin with RC1 and forgot to reinstall RC3. RC1 didn't have this ceckbox.

I guess however that I am right in suspecting that Full-Quality-First-Pass does not work correctly when 'turbo' is enabled?

[sysKin]

Originally posted by kilg0r3
I guess however that I am right in suspecting that Full-Quality-First-Pass does not work correctly when 'turbo' is enabled? Any reason for that?

[mikeX]

@kilg0r3
Turbo has nothing to do with 'fast first pass'
Judging from the fact that 'turbo' can also be enabled during the second pass I would say it is MPEG-4 compliant and thus safe to use with 'full quality first pass'
You can see for yourself: compare the speed difference between 'fast first pass' and 'full quality first pass' with 'turbo'
You should notice that 'turbo' does not have such a dramatic effect on speed ;)

[kilg0r3]

/staring at the screen in silent embarassement

[SiXXGuNNZ]

Originally posted by Lagoon
Anamorphic means the raw video is encoded vertically stretched, and horizontally squished on playback, this way you get more vertical resolution, resulting in a noticeably sharper image (just like DVDs, almost all of them are anamorphic nowadays, LOTR is)

To encode this way : only crop the bars, let the video vertically stretched, in XviD option, select Pixel Aspect Ratio : 16:9 NTSC (or PAL depending on the source).

Be sure to NOT select picture aspect ratio, as it's only a flag for players that supports it, whereas pixel aspect ratio information is on the stream itself

Then encode as usual (vdubmod highly recommended), on playback it will be horizontally squished to match the correct aspect ratio - and you didn't loose any vertical resolution, plus no wasted bits for black bars !

I recommend using MPC for playback, as well as XviD decoding or ffdshow with overlay mixer checked to avoid problems.

For later DVD encoding if you wanted to do it, just add back the borders to get the dvd resolution back.

A small example : a 720x576 PAL 2,35:1 film, you crop the bars, you get 720x416, you encode it like that, on playback it will be resized to 1024x416. If you were doing it with the bars , it would be 1024x576, 160 wasted lines!

nice, thanks for the heads up, it is now testing time :D

[Movie Maniac®]

Hi
I've got a TV cards by Terratec, which has only wdm drivers.
Virtualdub doesn't seem to like my card, so I'm trying to use VirtualVCR to acquire some TV programs.
I've tried to use Xvid 1.0 RC3 to compress the video, but the result is an almost unplayable video file.
Every player (except VLC that can read also stones!!!) crashes on certain frames, and even virtualdub(mod) crashes if i try to open ane edit the file.
The error seems to be the same we discussed ome times ago for the xvid 1.0 RC2 (the player tryes to read more data than what is really stored into the frame).

Did someone else had this problem?
Or it sounds completely new to your ears?

[Malevolent]

It'd be nice to get some "official" feedback on this darker encodes issue...
Koepi? Syskin?

[Daranduil]

Profile Level AS @ L4 says Maxbitrate 3000 kbps, but under this, it's writen "informative only, Xvid's ratecontrol will not respect this values".


Will XviD-1.0-RC4 come with a maxbitrate option?

[dapipa]

anybody alive?or...i'm afraid to ask :eek: ...is everyone turned into nuts,or something?
p.s.i've noticed that 'will turn developers into nuts' statement disappeared from sysKin's signature:does it mean 1.0 final is going to be released anytime soon?
man,i just wanna get my hands(or should i say my computer's decision making piece of silicon)on it!
:)

[mellon]

I cannot confirm this impression.

I encoded the same clip with XviD-1.0-RC3-29022004 and XviD-24062003-1. Configuration was on closest match. (same bitrate etc.) I decoded both clips with both release's VFW and DShow decoders and compared some I-Frames and P-Frames with the histogram function of PaintShopPro.
Average luminance was always the same on all images. Peak luminance differed less than 1% of the value.

[k4y]

I've got a xvid movie, its fourcc tag is "xvid-yv12" (!) ..
No matter what xvid codec (incl. ni hao),
it simply wont play in windows xp. :(
Manually cleaning the system for codecs, even reinstalling xp after low-level formatting doesnt help either.

With Linux, the movie started right away in MandrakeMove and Mandrake 10.0 Community.

[communist]

Originally posted by k4y
I've got a xvid movie,
dcn-medallion,
Read the rules!
No warez talk!

[k4y]

sorry :(

[MoonWalker]

About the brightess issue :

Using ffdshow-20040329 and MPC 6.4.8.2.

Using Overlay Mixer the image is a little darker than using WMR9(changed from within MPC)..Don't know if anyone has noticed this..

MoonWalker

[jared1999]

Brightness issue:
Remember that overlay (usually) has separate settings from VMR9 (VMR9 is same as desktop color settings in many drivers), and so both must be calibrated. You'll most likely end up with them looking very similar.
Personally I've always had trouble getting overlay properly calibrated (both on ATI and nVidia drivers), so I just use VMR9 as much as possible.

[Heini011]

Hi,

i use dividee's six-of-nine hvs matrix and have setting the min-quantisizers up to 3 for first and second pass, because i get a 3 gb file in fist pass when i encode my film with default-value 2.

problem: within the statfile i- and p-frame quantisizers are 2 instead of 3.

@devs: it is possible to fix this problem?

greeting, Heini011.

[GalFisk]

Hi, I have a problem playing back some clips I encoded some time ago, with the latest XviD builds. Unfortunately I don't recall which build I used when the files were encoded, it was one of Nic's builds and was done in october-november 2003. It says XviD0009 in the AVI files if that helps...

Options used, as I recall:
2-pass (2nd pass int)
Motion search precision 6
Quant: MPEG-custom (used custom cartoon quantizer matrix)
4CC: XVID
VHQ: not sure, but I think it was off
Lumi masking, Q-pel, Chroma motion, GMC enabled.
Max b-frames: 1
Min b/p quantizer was 1 or 2
Credits at 20%/greyscale
Chroma optimizer may have been enabled
Picture size: 640x480

When there is much motion in the picture, especially on pans and zooms, the picture gets smeared, it looks like the blocks don't move quite correctly, and pieces are left behind and/or misaligned. The video often plays correctly if most of the picture is static.
This happens in all clips I encoded at the time, with that build and those settings. They played back correctly at the time, they also work in the new ffdshow builds (except when using the XVID 4 decoder in ffdshow).

I use Media Player Classic (6.4.7.5) on windows XP, I have an Athlon XP 2600+ CPU and ATI Radeon 9700pro video card.
There is a clip that shows the problem at http://home.no.net/galfisk/testclip.avi (2.98MB)
It would be nice if this would work in 1.0 final (or if that's not possible, if/how I can fix the files).
Edit: looks like some of the same that Undead posted here: http://forum.doom9.org/showthread.php?s=&threadid=71803&perpage=20&pagenumber=9 (2nd post from the top)
Edit2: Several other people have reported the same problems with these clips as well, the new (200403xx) versions of ffdshow as well as old XviD builds seem to work for them too.

[communist]

Have you tried ffdshow? IIRC the XviD team will work on workarounds for decoding old xvid streams after 1.0.

In the mean time try to decode with ffdshow and see if that helps:
http://www.ligh.de/software/mirrors.phtml

[lordadmira]

Originally posted by GalFisk
When there is much motion in the picture, especially on pans and zooms, the picture gets smeared, it looks like the blocks don't move quite correctly, and pieces are left behind and/or misaligned.

I know exactly what the problem is. I've seen it dozens of times. The video stream is corrupted. You probably had some hard drive corruption taking place when u encoded them. Those artifacts are classic. I had the exact same problem when my RAID was dieing and corrupting my files.

P.S. There's no way to fix this.

[Arcon]

Originally posted by GalFisk
Hi, I have a problem playing back some clips I encoded some time ago, with the latest XviD builds.
[...]
When there is much motion in the picture, especially on pans and zooms, the picture gets smeared
you probably made them with an older build that was using another idct method. try playing the clips with ffdshow and try the different idct methods offered under misc (at least in the older builds of ffdshow it's there, might have been relocated in the newer builds).

[GalFisk]

Originally posted by communist
IIRC the XviD team will work on workarounds for decoding old xvid streams after 1.0.
Interesting to know. It seems to be a problem with GMC, since it only affects scenes where large portions of the picture are moving. The annoying thing is that it works in older XviD builds and ffdshow, but not in the newest XviD builds. I think it started a little before RC1, seems like something was either broken or an old bug was fixed...
In ffdshow it plays back correctly with any iDCT, and the built-in libavcodec or XviD decoder, but not the XviD 4 decoder. It works without enabling any of the encoder bug workarounds.

[Arcon]

Originally posted by GalFisk
In ffdshow it plays back correctly with any iDCT, and the built-in libavcodec or XviD decoder, but not the XviD 4 decoder.
does it play back ok if you watch the video in virtualdubmod? as far as i remember vdubmod uses the xvid.dll for decoding while normal movieplayers use the ds-filter xvid.ax. maybe only one of them has this problem you described?

[Lobuz]

So once again the same clip (http://www.republika.pl/lobuzsign/sample.avi) . It's with adaptive quantization which makes strange efect -> horizontal lines with xvid decoder but not with ffdshow. With new version of ffdshow when switching different idct works it appeared again with xvid(walken) IDCT. With simple IDCT the picture is ok. So it looks like the xvid idct is guilty here.

Regards
Lobuz

[GalFisk]

Originally posted by Arcon
does it play back ok if you watch the video in virtualdubmod? as far as i remember vdubmod uses the xvid.dll for decoding while normal movieplayers use the ds-filter xvid.ax. maybe only one of them has this problem you described?
Just tested, the clips play normally in vdubmod and vdub.