ni hao! (XviD-1.0-RC3)

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