XviD-21052002-1

[Koepi]

XviD-21052002-1:
- EPSZ and EPSZ^2 motions search activated
- Decoding fixed - b-frame sort order disabled.
- Added Nic's minicalc by user request
- Compiled with intel compilers for speed.


I couldn't test the binary yet since my dll's are in use by an encoding session, please verify if the nasty frame-sort-order bug is fixed!

Thanks,

regards,
Koepi

[rui]

Ok, i made a small test, using CBR mode.
In the trailer i encoded, i couldn't spot the keyframe jumping problem anymore.
Also, the problem reported by Franko30 seems to be gone.
But i still have the green bug in the start of the avi. It only shows when using media player. When using Vdub, i don't have the green bug anymore.
But would like to read othters tests also, just to be sure ;)

[Uli]

Originally posted by rui
...
But i still have the green bug in the start of the avi. It only shows when using media player.
...

Hi!

Same for me...
I think the 'green bug' is related to Nic's DSF ( no offense ;) ). If you use ffdshow there is no green start at the movie...

greetz, Uli

[Nic]

ffdshow has nothing to do with XviD decoding.....

However, Hmmmmm...Just recompiled with the latest source...& I still have the problem of the first frame being green (?!) Ill look into it.

-Nic

[N_F]

Originally posted by Nic
ffdshow has nothing to do with XviD decoding.....


What do you mean? If you have ffdshow installed and configured to decode XviD, doesn't it?

[Uli]

Originally posted by Nic
ffdshow has nothing to do with XviD decoding.....

However, Hmmmmm...Just recompiled with the latest source...& I still have the problem of the first frame being green (?!) Ill look into it.

-Nic

errmm... ??? :confused:
I did'nt mean ffmpeg, i was talking about ffdshow and that can decode XviD very well...

greetz, Uli

[Nic]

I just meant that ffdshow doesn't use the xvid decoding code....Therefore a bug in the xvid decoding, would not appear in ffdshow.

-Nic

[Uli]

@Nic:

I see... was a misunderstanding. You're right.

greetz, Uli

[Nic]

Grrr...I cant get rid of that green pic at the start ? its very peculiar...as the normal DShow filter (no post-processing) works fine? Its very weird...

-Nic

[Koepi]

It's starnge indeed.

Maybe this helps trcking that down:

When opening an XviD the green bug appears
When pressing stop, return to 0 and start over again it's gone.

It looks like at instantiation time a variable isn't initialised correctly or a buffer isn't filled or....

Well, as I wrote, just an idea.

Best regards,
Koepi

[Nic]

Thats very true....Its very weird. Good excuse to release my source, so someone else can fix it :) I thought it was because i was calling xvid_init twice, but I made the normal DShow filter call it twice & everything was fine. I took out all my post processing code & replaced it with the decoding code of the normal filter...& still got the green bug...Double Grrrrr :)

-Nic

[cult]

with ffdshow there is not that green thing.
I'd say that is not a frame,but rather a flash of green screen and then gone.I think koepi is right.there is no problem with ur movie.it has something to do with the directshow i think

[Nic]

Hmmm...Let me restate ffdshow has nothing to do with the xvid decoder.

The problem is with the way my filter is calling the decoding/init routines...But im stumped as to what im doing wrong...Im at work & too busy to look at it now really :(

-Nic

[Koepi]

Don't forget to pack up your actual sources, burn them together with the DX SDK on a CDR and take them home with ya. So there you can spend more time on looking at that problem (it should be something really simple, like a normal off-by-one error that everybody does all the time [including me of course]).

*hide*

:)

Regards,
Koepi

[Nic]

a normal off-by-one error -> You wouldnt believe how plagued I am by them :)

But the worst errors, the ones I get at work, are the "Works for about two days & then falls over" bugs...Triple Grrrr :)

-Nic

[Shayne]

Seen this green screen with ur 13 build nic. Opened it a couple of times because it baffled me. Plays just fine however n doesnt really bug me.

Maybe making a mountain out of a small mole hill Nic

[Nic]

Seeking perfection is a virtue...

-Nic

[kilg0r3]

@ Nic

Same opinion as shayne's here. poke your nose into something more enjoyable :)

[libredr]

Could it be simply a Windows Media Player bug ?
Using mplayer under Linux I have no problems. And also with some video files in other formats than mpeg4 I have sometimes a crappy image (with no colors, green bars, etc...) with WMP and a correct one with mplayer.

[Koepi]

Stupid me made some mistakes by activating the intel compilers, so fetch the brand-new codec, finally compiled with the intel compilers :)

Amazing how you can tweak a little performance out of the M$ compilers as well %)

XviD-22052002-1:
- Finally really compiled with intel compilers for speed!

Best regards,
Koepi

[rui]

Thanks :) Downloading right now.

BTW: I noticed that you guys (the Mods) have a new classy look :cool:

[rui]

WHOA!!! Talk about speed increase!
When doing my usual trailer test, in the second pass (the fastest) i never got more than 25/26 fps. With this new build, i sometimes got to 27/28 fps.
In a small trailer isn't much, but in a full movie encode, it represents a real time gain. (for example: movie with 200.000 frames; older build-> max 26 fps makes 7692 seconds or 2hours and 8 minutes;
newer build -> max 28 fps (since i noticed a diference of +/- 2 fps) makes 1 hour and 58 minutes. Less 10 minutes per pass. Since i always do 2 passes, i save 20 minutes!!


All this with just a new compilation

Great work, Koepi :)

[ookzDVD]

Yes, I think this latest Koepi's build is the fastest build
I've ever used. Thanks Koepi ;)

[wotef]

holy moly, confirmed here, too - peak 30fps in fast recompress! good work, fellas! :D

[MaTTeR]

Nice work Koepi. I peaked out here around 86FPS with simpleresize:) Before it was around 81 or 82FPS.

[Didée]

Yes, the new build is fast. But besides the speed hype ...

Last night I did a 2-pass with the 21052002 build, and had a quick check this morning before leaving to work.
I found that my settings for the (end) credits had no effect at all.
I had set quants of 22 for the credits (yes, in both passes), but the credits came out with a rate of 151 kB/s (68 MB for 8 mins of credits), where the whole movie (inclusive credits!) rates 119 kB/s.
I know there were some discussions in the last days about potential bugs in the credits handling. Could it be that the credits function is disabled in koepi´s 21052002 ???
If so, maybe it should be mentioned in the release notes ...

Or did I something wrong? (dont think so):

1.pass: MotionSearchPrecision 6 - H263 - IFrame max250 min1 - +lumi - +hints
2.pass: size 670xxx - modulated - +lumi - +hints - Imin2max4 Pmin2max12 - ACC high-high300-low60

Could anyone please confirm wether credits are working or not?

Thanks, and keep up the great work!

Didée

[kilg0r3]

Did you check ‘quantizer mode’ for ‘credits rate reduction’ and enter the relevant values in the boxes also for the FIRST pass? AFAIK this is necessary for quantizer mode to work.

[Prosper]

Wow, with Simple Resize my CPU util. hit 90% (which is a good thing on an SMP box, means one thread's not bottlenecking.) Hit 110fps

[philippas]

@Prosper
110fps That's what i call speed :D !
At what resolution you get 110fps ?

Indeed the new Xvid build is fastest one.

[avih]

isn't that amazing that the developers work so hard for optimizations (although not always for speed), and by just choosing a different compiler with good settings produces 10-15% gain??
that only means that there's so much to gain from the non-asm sections. i had the impression that the asm code takes the majority of time during execution. it also means that m$ compiler sucks badly when compared to intel's (even on amd cpus). a point to think about...

avi.

[jpl]

I tried the 22052002 build and it causes my K6-3 to crash (illegal instruction error in virtual dub) when I attempt to change compression settings. Is there a compatibility setting that is lost when switching over to the Intel compilers?

PS: 21052002 and previous build work fine.

Thanks

[Pasqui]

AFAIK, ICL compiles crash on AMD K6 series.

[kilg0r3]

hi there,
this seems to be related to the following threads:

http://forum.doom9.org/showthread.php?s=&threadid=22426&highlight=grey
http://forum.doom9.org/showthread.php?s=&threadid=18803&highlight=grey

the grey blocks strike again. now they come in blocks:eek:. it has nothing to do with the credits code, instead, the error only occurs in a combination of strong compression ( quantizers between 31 and 26 or so) plus luma masking. neither the decoder filter nor the player app makes any difference.

The attached rar (3.0!) file below contains some test clips which exhibit the problem. the number behind q in the filename shows the selcted quantizer. the clips were encoded with the latest koepi build using fixed quantizers, msp 6,Q type h.263 the rest was default. with q25 the problem nearly disappears. the applications used were dvd2avi, gknot, avisynth, vDub. no filters except sharp bicubic were applied.

wish you a good hunt

[Koepi]

As stated on other incidents concerning high quantizers occasionally, it's the well known fact that the code isn't "tweaked" with them.

Quantizers >20 are dangerous.

It's yet intentional and might be addressed in future, but for now - keep your hands away of them.

Regards,
Koepi

[Bulletproof]

The codec should never really choose a quantizer above 20 anyway right?

[Prosper]

Originally posted by philippas
@Prosper
110fps That's what i call speed :D !
At what resolution you get 110fps ?

Indeed the new Xvid build is fastest one.

480*256, encoding TV caps. SMP rocks!

[soujir0u]

Hmm, seems that the green first frame bug is still present.

[Koepi]

Ah, that's quite in-topic.

OF COURSE THIS BUG STILL EXISTS.
Would you mind reading first before posting such unhelpful c***?

Maybe you didn't understand the problem:

It's related with Nic's XviD DSF - so if that one isn't updated, it's very, very, very unlikely that something changed in that regard.

Stick with a xvid DSF from uManiacs instaBuilds.

Those don't have a green-first-frame bug - but no postprocessing either.

:stupid:

[Nic]

Im sure people can live with that first green frame for now, cant they?

Im going to re-write my source to get rid of the bug....

BTW has anyone tried the DivX 5.02 filter with MPEG quant? Tried it by accident & it seemed to work fine (might well be a fluke though). But cant remember if anyone else has tried it....

-Nic

[Koepi]

Nono, that bug isn't too bad. It's more a small glitch, but not essential.

Sorry if I sounded otherwise.

Regards,
Koepi

[Bulletproof]

Do you think it's possible to add how much of a percent of bitrate to take away when you enable luminance masking? that way maybe some people can tune it in case it produces bad results. Also, since you can cap the max bitrate, is it possible to cap the lowest bitrate usable too? or will these things break the curve? Or am I totally misunderstanding the way luminance masking is working?

[soujir0u]

I'm aware that the bug/glitch/whatever you want to call it is due to the postprocessing filter. But I was just saying that in case people thought the 22 May build fixed it. There's no need to get so uptight...