ni hao! (XviD-1.0-RC3)

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