My XVid binaries

[Nic]

Thanks for the info :) Once you've re-encoded without 3DNow! perhaps you could post your results of how it went here & at www.videocoding.de :)

Cheers,
-Nic

[wing1]

Nic,

The result got worst. Now the purple is more prevelent then the pink. The discoloration issue can be seen in the character's faces more pronounce. My processor is an Athalon 1900+ XP. MMX, SSE integer, SSE , and SSE2 are the only thing that's on. I've turned off both 3Dnow and 3Dnow2 off. Again Divx4.12 filters and Xvid were used (remove Divx4.12 codec from system to use Xvid only).

[rui]

Originally posted by wing1
Nic,

The result got worst. Now the purple is more prevelent then the pink. The discoloration issue can be seen in the character's faces more pronounce. My processor is an Athalon 1900+ XP. MMX, SSE integer, SSE , and SSE2 are the only thing that's on . I've turned off both 3Dnow and 3Dnow2 off. Again Divx4.12 filters and Xvid were used (remove Divx4.12 codec from system to use Xvid only). [/i]

You are choosing manually the cpu optimizations, correct?
Don't choose SSE2, if you have an AMD Athlon XP, because it doesn't support those.

[Nic]

Hopefully all problems will be solved very soon, also post very detailed accounts at www.videocoding.de to help the developers.

Also when you post a problem could people post what quantizer they are using (i.e. MPEG or H.263). Thank you very much.

Unfortunatly if a fix does come out, I wont be able to update the site until first thing monday morning (im a bit ill at present :-(

Cheers,
-Nic

[NoLogo]

First, excuse my poor english, not my mother tongue :(

There seems to be a problem with XviD: with some videos, XviD allows too many keyframes, which look much worse than P-frame, and I didn't find how i can configure this in VDub.
My question is: can this be solved, and if yes, will it be in the future ?

Second: I heard that DivX 4.5 is going to use P-Frame and B-Frame (KPPBBKPP), a soltion which is lighter than KPPPPKPP), will it be used with XviD too ?

PS: Great job :)

[rui]

Originally posted by NoLogo
First, excuse my poor english, not my mother tongue :(


I wish i could type in english the way you typed that :)
I have to use MS Word's dictionary to correct some errors ;)

[-h]

There seems to be a problem with XviD: with some videos, XviD allows too many keyframes, which look much worse than P-frame, and I didn't find how i can configure this in VDub.

What kind of source are you encoding from? XviD's keyframe decision kicks in when more than half of the image changes. I've noticed many keyframes that it misses with this criteria..

Second: I heard that DivX 4.5 is going to use P-Frame and B-Frame (KPPBBKPP), a soltion which is lighter than KPPPPKPP), will it be used with XviD too ?

B-frame decoding is working, but the encoding is much more complex than I-P only. Disable B-frames in TMPGEnc to see the kind of speed hit it will bring.

-h

[NoLogo]

-h:

I encode from an .avs (given by GKnot, but first from .vob), but it doesn't occur everytime. Maybe the video is too complex and forces VDub to use so many KF...:confused:
Maybe i'll post a pic of my frame graph, so that you can see what i mean.
But i don't now exactly where it comes from, not a true specialist at all :(
Wouldn't it be possible to have, with XviD, the same correction for KF than in NanDub, which allow to correct the problem by the "min kf interval" command ?

rui:

I use a dictionnary too ! ;)

[-h]

But, is it anime? High-action video clips?

The sad fact is, I-frames are more compact than P-frames in certain situations.

There are going to be further enhancements to motion estimation (for fades, etc.) so this may not be an issue forever. I guess a min-kf-interval could be implemented as a temporary measure.. but usually the codec knows best. If half the blocks in an image are being coded as intra, odds are the frame is better off as intra.

-h

[rui]

Is there any difference between Nic's and uManiacs XviD builds??
Are they compiled using the same software, and the same optimisations? I mean could be that one of them uses a compiler that makes better use of Intel processors than AMD ones?

P.S. Last night i went to the local cinema see a movie called Black Hawk Down . The movie has 2H25 duration, but about 1H30 is all war, with fast combat images, both during day and night period. It will be a real hard test to XviD or Divx when the DVD comes out ;)

[Nic]

Have you noticed a difference between our builds? (when they are done on the same day of course)

Both me & uManiac use VC6 + DX8. I dont if he has the VC SP5 + latest ProPack installed, but I do.

Ill try compiling in VC7 next week, see if that helps/hurts speed & stability.

Cheers,
-Nic

[Koepi]

EDIT:

Question:
Hm. What do I need next to the DirectX8.1 C++ SDK to compile XviD?

Answer:
Nothing. Add following dir to "Extra"-"Options" - "(Include) Directories"

E:\Programme\Microsoft Visual Studio\Common\DXSDK\samples\Multimedia\DirectShow\BaseClasses
Or wherever you installed the DX 8.1 SDK.

I hope this helps :)

Regards,
Koepi

[NoLogo]

-h:

The movie was an action one, called "Warriors" (it's about UNO soldiers in Bosnia), with some fast scenes but also slow ones.

Other fact: I tried to recompress with the binary from the 7/2, et I got superb pink uniforms, what didn't occurs with the former binaries (not with the 30/7). I have a PIII, so I used detected optimization (MMX, SSE, integer SSE). Everything's nice but pink...

[rui]

I can confirm NoLogo words.
I just finished an encoding using the 7/02 Nic' build, the movie is Independence Day. I used H.263 quantization, motion precision search 5 and luma in the second pass. I used the internal second pass.
I got pink colours right in the beginning of the movie, when the alien space ship is passing the moon.
I am returning to the 2/2 build (i believe that this build and the 30/1 one are the same, just 30/1 was compile by uManiacs and the 2/2 was compiled by Nic), because with this one i made 3 movies with no problems.
Hope you guys can fix this pink problem.

Nic: No, i didn't notice any differences between your build and uManiac's build. Just wanted to know if could be possible that you two choose different kinds of optimisations.
The question first came to my mind after seeing this site :
http://www.geocities.com/avihpit/xvid/cpu-opt.html
This site was posted by avih in this thread : http://forum.doom9.org/showthread.php?s=&threadid=15798

[Nic]

Thanks for the links rui! Interesting stuff....

@Koepi:
Didn't quite know what you were on about :) If you were trying to help people compile the xvid dshow filter then great. :) (obviously I already knew how to do that)

Ill put up a new build on Monday, hopefully things will be better, if not ill also put up a link to the 2/2 build on the site for now.

Cheers,
-Nic

[Koepi]

Nobody warned me that I'm dealing with C here instead of C++... well, just a last thing to figure out (how to read out the value of a radio-button correctly) and I've finished what I wanted to do first.

Until now I've done only very easy things:

In 2pass mode I cleaned up the debug output. It now shows something like "string:value string:value..." so that it's possible to mark intra-frames with debugview :)
Another thing I'm still fiddling with is a radio-button with which you can choose whether the FourCC of the encoded movie should be DivX or XviD... nothing where we don't ave tools for, but I thought it's a nice gimmick :)

Maybe I'll put up binaries later, it's a snapshot from tonight (9.2.2002, ~3:30h CET) (just if there is interest...).

Regards,
Koepi

[cofferscuffs]

An interest is here....

[Koepi]

@Nic:

Sorry, that wasn't meant to offend you. It's just a general thing I found out now ;) And I think there might be some other people trying to compile XviD themselfes and maybe they get stuck in the same corner.

(before editing it was just a question, I wanted to indicate that I found the solution).

Best regards,
Koepi

[NoLogo]

I got my pink colors with:
MPEG quantization, motion precision search 5, no luma in second pass.
But I use DivX4 to decode XviD, maybe there is a dedicated decoder for XviD ?

[Koepi]

Ok, I've put up my first own binaries, fetch them at

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

The changelog is there as well. The modified sources are included as well.

Have fun!

Best regards,
Koepi

[cofferscuffs]

Yummie. Thanks 10x Koepi!!!

[NoLogo]

Koepi, which sources did you use ? I mean date.

EDIT: the URL doesn't seem to work :(

[cofferscuffs]

The URL does work.

09.02.2002: I did compile my own version of the XviD decoder/encoder today. The sources are from 09.02.2002, ~3:30h CET (CVS).

[NoLogo]

Well, big mystery...does work now...:confused:
Maybe my firewall is guilty...
Thx cofferscuffs.

[Koepi]

sorry for the trouble with that link. We have trouble in our MAN / VLAN here regarding a central DNS, even our mailers are affected. Should be more stable in some hours (hopefully)...

Regards,
Koepi

[-h]

@Koepi:

Haven't tried your changes, but the registry issue is known (we're just too lazy to separate every config setting into registry keys). In config.h I've been updating the value of XVID_REG_NAME to get around this (beautiful).

Just wondering, why'd the additions to xvid.h have to be global? ;)

I'd just commit it all to CVS, no one really worries about non-core stuff that gets merged. I wish there was a global changelog though..

-h

[Koepi]

@-h:

Oopsi, did I make changes global? ;)

To tell you the trueth, these were points that gave me a real itch to scratch and so I just started coding blindly. I'll recheck if I really did something messy, but since I'm not really a C freak I have my problems with it, and I'm glad that I made it work at least - maybe I get closer to C and can revisit my changes and clean them up. Using the class manager is so much easier ;)

What gives me a real headache is my plan with adding overlay support to dshow - in C++ it isn't too easy, but now in C?

Well, I want to learn that and I'll find a way ;)

Thanks for looking at my changes!!! :)

Best regards,
Koepi

[-h]

The stuff in xvid.h couild be in codec.c, just under the "int bytes" declaration, that's all :)

How would one go about adding overlay support? I was hoping that the dshow framework did that for us, and all we managed was decompression. Why can't you use C++?

-h

[Koepi]

Mixing C with C++ is a BIG no no! It results in unmaintainable sources and I'm not even sure if it would compile correctly.

Just because my hack was "global" (compiler complained about unreferenced variables so I moved both declarations to the header, problem solved...) doesn't mean that my style is bad in all ways ;)

Regards,
Koepi

[-h]

Mixing C with C++ is a BIG no no! It results in unmaintainable sources and I'm not even sure if it would compile correctly.

Oh I thought you were talking about only being able to use C to add overlay support to the dshow filter. I got a bit lost seeing as it's already CPP :)

I'm merging some vfw stuff tonight, so I can add yours in with it if you want. I'm moving a lot of the tab content around (finally making a 2-pass tab) so it might be cleaner that way.

-h

[Koepi]

@-h:
I didn't look into dshow sources yet, I just compiled those. Since vfw is in C I assumed dshow is in C as well.
If it's a C++/MFC project then I'm more than glad because I can help there way better :)

Regards,
Koepi

P.S.: you may of course incorporate my changes (as long as you don't sell them as yours ;) ) - didn't you want to upload those into CVS?

[-h]

If it's a C++/MFC project then I'm more than glad because I can help there way better :)

Yep, don't think it's actually possible to write dshow code in pure C. The dshow code is very 'clean' at the moment.

I merged a whole bunch of vfw stuff a few minutes ago, credits, fourcc, tab moves etc. All kinds of stuff people are going to complain about.

But.. I'm going to bed, so I'll miss all the bug reports for a while :)

-h

PS. forgot to do the extra 2-pass output, might add it tomorrow.

[Koepi]

Thanks mate, I'll re-checkout the sources tomorrow then... extra debug-output? I simply commented out the original output (were just 2 lines ;) ) and added some, it's meant as a substitution - else you'd get 2 lines of output for every frame ;)

G'night, sleep well!

Regards,
Koepi

[Ripe73]

HI!
I try to change the FourCC to Xvid DSfiler with Ogg like this.
Open video in FourCC
FourCC Description Code:q
FourCC Used Codec:XVID
Apply
but the movie cant be played after that,someone know how to change to XviD DS filter with Ogg?

I hope
;)

EDIT:I must be genius:D i changed the FourCC before i mux
I think i will beat Einstein(maybe only with my penislenght)

[Nic]

Latest build 11/02/02 is now at:

Main:
www.freewebz.com/xvid

Mirror:
xvid.stormpages.com

Changes:
The pink & green bugs should be alot better,
Now has a Koepi's check button to select the FourCC used.

Cheers,
-Nic

[rui]

Hey, we now have three codec supliers: Nic, uManiac and Koepi. :)

We the users must urry, i was just starting to test Koepi,'s build, and now we have a fresh new one from Nic. I can't keep up the pace :D :D

[Nic]

I think mine & Koepi's will be somewhat similar :)

-Nic

[Koepi]

Ahoy :)

No offense nic, but please test your binary - first pass always uses quant 16 (or whatever quantizer you put in for the credits). While adding the credits stuff there went something wrong. (Damn, if i weren't that keen on a little debug output I would never've figured that out!)

I fixed that bug.

My binary+modified sources is available at http://www.roeder.goe.net/~koepi/

Changelog is inside the zip and on that page.

I forgot to add that the values get screwed due to the registry stuff... So just enter the default values (or whatever you like) and then close the configuration interface. After reopening it the values should be in range again.

I hope this helps,

Best regards,
Koepi

[Franko30]

Just as I posted a few minutes ago

http://forum.doom9.org/showthread.php?s=&postid=82094#post82094


Frank


P.S.: Thanks Koepi for fixing it that fast!

[rui]

Well, some time ago i placed here a question about the diferent XviD builds we have. My question was about the possibility of having diferent compilation optimizations.
I've read an article over Ace's Hardware about this:
http://www.aceshardware.com/read.jsp?id=40000189
I read in the XviD org forums that you guys are having dificulties introducing SSE2 optimizations, but this article says that by using Intel's c++ compiler, SSE2 code is generated automatically: http://www.aceshardware.com/Spades/read.php?article_id=40000192
http://www.aceshardware.com/Spades/read.php?article_id=40000193

Humm. I forgot that this applies to floating point, but this encoding thing uses integer most, correct?

[Franko30]

to Koepi:

Hi again,

I just installed and tested your fixed binaries with my before mentioned 1 minute test clip, using H.263/Motion Search 5/2pass/2ndpass int./desired filesize 6651.

But there's still a bug when using "credits start 0". 1st pass finishes OK but the second pass produces the error message "Credits larger than desired file size" directly after starting.

Frank

[Koepi]

Uh, really?

I'm still stuck in my first pass (>6h to go from now...), so I've just tested first pass yet.
I'll try to find the wrong part. Btw., I didn't fix it that fast, I just checked out the changes that -h applied to the CVS and ran into the same trouble as you :)

But maybe now I'll be fixing that fast ;)

Regards,
Koepi

[Koepi]

Let's see if this is fast...

You're absolutely right. -h introduced a range-check for the credits (if they are within the movie...). But as the codec can't know the size of the movie this is simply impossible.
I removed that check, hopefully it works now.
Updated binaries are in the same place again ;)

Thanks for your report Frank,

best regards,
Koepi

[Franko30]

Deleted my message that I do it a second time to be sure, as you found the error faster than I could do a second try...

Frank

[Koepi]

Can you please try to confirm that it works now?
And don't use credits out of range of the movie, there is _no_ check at all now ;)

Regards,
Koepi

[Nic]

It isn't really my job to test the binaries is it? If someone puts silly mistakes into the CVS, im supposed to find them am I?

Well fine then,

Site Closed.

-Nic

[-h]

You're absolutely right. -h introduced a range-check for the credits (if they are within the movie...). But as the codec can't know the size of the movie this is simply impossible.

I only merged enough to fix encoding with the CVS just then - the sources on my side seem to be a mess (yuck).

Why can't the range check work? codec_2pass_init() just adds the total of all the credits frames in the .stats file - if that value is larger than the desired file size, there's no way the movie will reach the proper size since the credits aren't being rescaled (they're the same size in the first and second passes). I know it isn't terribly likely, but at least it's the start of some (much needed ;)) error checking in the frontend.

I still can't believe I committed the wrong code.. looks like it's missing some other stuff I had done too. Heh oh well.

-h

[Koepi]

Can you please addin my changes then as well? I guess it's unneccessary to add that every VFW change in CVS again ;)

Do you like the idea of a dropdownlist? It makes the GUI more uniform...

Just my 2 € cent...

And nic, nope, you're not supposed to check if it works, as I wrote, no offense in that!

i appreciate your work. My codebase can be totally flawed as well and then it's necessary to have your binaries directly from CVS.
So please, reopen your site!

Regards,
Koepi

[Nic]

Nope.

Tell Doom9 to link to your binaries from his guide.

-Nic

[Franko30]

to Koepi:


I did the test encodings of my one minute clip again:

Settings: H.263/Motion Search 5/2 pass int./Credit Quant 16/Desired filesize 6651/luma masking off

Credits start 0: resulting filesize is 1382, awfully blocky

Credits start 1000 (out of 1497): resulting filesize 1344, awfully blocky

I uninstalled the XVID codec again, reinstalled your fix1 binaries, double checked, same, blocky results. :(


So far, Nic's binaries work best (when not choosing "0" as credits start).

Frank