ni hao! (XviD-1.0-RC3)

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