View Full Version : XviD-17052002-1
Koepi
18th May 2002, 08:45
Ahoy,
no big changes... BUT:
Changelog:
XviD-17052002-1:
- the same as 13052002-1 but compiled with intel compilers for performance tweaking.
My tests have given me ~15% higher fps (strange but true).
Enjoy!
Regards,
Koepi
Wow...That is a speed up. Time to dig up my copy of intel compiler :)
-Nic
Koepi
18th May 2002, 10:24
Heya Nic,
yupp, that sounds like a good idea. I'm using the latest compilers from intels website, they should give most speedup.
And if I'd understand those compiler flags of intel a bit better (didn't look into the docs yet), it should be possible to tweak it even more, I'm now just using highest optimisation settings (entered manually into the release-setup of the dsw).
PM me if you want a "copy'n'paste" of my settings :)
Regards,
Koepi
Bulletproof
18th May 2002, 10:32
Will this make a difference for AMD CPUs? and when I install a new version of XVID do I have do deinstall the old one? Thanks.
While im asking that question I might as well ask you two other ones that have been on my mind. Is Luma masking supposed to be done on the first or second pass only? and does MV hints work with modulated quantizers? Thanks again.
Koepi
18th May 2002, 10:42
Bulletproof,
you seriously should use the search function (or go 1-2 pages back in this forum).
a) I'm developing using a duron700.
b) on my site I clearly state that you have to uninstall previous builds.
c) Luma masking is a matter of taste - -h suggested using it on both passes, I thought using it only on second pass is better.
I'm using it on both passes sometimes and it doesn't harm the encodings I make.
d) the MV hints and modulated quantizer setting hasn't been fixed yet, there's no announcement regarding this.
Koepi, i made some tests with MV hints and modulated quantization and didn't had any problems.
-h also, in replying to a post of mine, said that he believed that it was fixed.
The thread http://forum.doom9.org/showthread.php?s=&threadid=24469&highlight=hints+modulated
Look for the 6º post
Koepi
18th May 2002, 15:34
Thanks rui for pointing this out, -h really missed to tell me that he finally did it. He just mentioned that he tried to fix it but never reported success in this matter (have to follow that thread though, I might have missed a post ;) )
Thanks,
Regards,
Koepi
PS: fine to have modulated quantizers back :)
Bulletproof
19th May 2002, 02:17
Ok, one more thing, do we still have to pick H.263 for the first pass to do modulated quantizers or can you now just pick modulated for both passes?
Koepi
19th May 2002, 10:35
Bullet,
now you're REALLY wasting my nerves.
Did you EVER read (or better: THINK) about the concept of modulated quantizers?
USE WHATEVER YOU WANT IN FIRST PASS.
See, scroll up this page to the top.
To the right you see a field called "Search:"
Enter "modulated quantizer first pass" in the field and hit the grey button next to it.
Happy reading!
Koepi
19th May 2002, 10:36
Ah, I forgot:
it's hadnled in the XOE and in the HELP file as well.
You surely should learn researching on your own.
The People's Elbow
19th May 2002, 13:14
@Koepi: While using your latest build (17052002-1) I found out that Lumi Masking and MVH are buggy (for me!).
When I encode the 2nd pass with a mvh-file the picture quality is really crappy, all the time macroblocks appear and disappear without any sense.
And with Lumi Masking switched on at the 2nd pass the result is an unplayable AVI file which forces mplayer2.exe to crash :confused:
I don't know if I'm the only one having these probs lately or if they are already known bugs... just wanted to mention that something is wrong in the newest build (though these bugs appeared in earlier may-builds already!)
I tried it on a win2k and a winme machine - same results.
EDIT: False Alarm regarding the mvh-file I guess, the problem is caused by the end credits settings I used, but they should work anyway. Then maybe sth. with the Credits code isn't working right.
I set the end credits to 6144KB desired Filesize... don't really know why the rest of the movie gets messed up.
EDIT2: lol! False Alarm regarding Lumi Masking, either! All those bugs don't appear anymore, if I switch off the end credits stuff...
Then only this part of the code may have some errors (regarding credits encoding) ;)
greetz, Elbow!
Koepi
19th May 2002, 19:10
I did some test clips yesterday with luma masking in 1 and/or both passes, MV hints, and all combinations with modulated quantizer type - result: all encodings look nice and don't seem to have any problems.
Elbow,
nice that you could reduce the problem to something with the end credits code, I could take a look into it, but I'm waiting some hours until the situation clears up a little...
The People's Elbow
20th May 2002, 12:05
I did some further testings regarding the end credits problem:
I encoded the movie heartbreakers (about 98 mins and really hard to compress, because of heavy noise and crappy picture quality, but this isn't important...) with enabled mvh-file and Lumi Masking and set end credits % to 33 - it worked as it should! Average Bitrate was 803!
-----
Then I encoded an Episode of Love Hina (Anime, about 21 and a half mins and hard to compress, either)
I used the same settings and what happened: When the 1st credit frame starts the whole thing crashs! Average Bitrate here was 895!
... I set the end credits % to 50, but that didn't change anything!
Thats weird I think :eek:
greetz, Elbow!
i have a problem
i am encodin darkman and in certain frames i get awful pixelation.I tried alot of settings,even ripped again vobs to my hd.The strange thing is that it gets visuable when i am doing thw whole 2pass encoding.If I start 1pass ,quit it and go to 2nd pass then it doesnt show(at least to my eyes).But in vdub i get a screen which is half ok,half in sort of b@w.Encoded the same movie with divx4 and everything is fine.Whats going on??Happened again in past with 2-3 movies.
I go for 2cd,used koepis 17/5 version and also 13/5 version
no luma,6-utlrahigh,fourcc xvid,quantization-mpeg,used hinted me,curve:medium,high:150,low:95,automatic strenght:50.used option for start and and credits.
Franko30
20th May 2002, 12:28
@ Koepi:
Hi, I'm back - I've been lurking for quite some time, as everything went ahead at a great pace, but no bugs I did notice occured on my system.
But now, after reinstalling my WinXP system, I noticed a tiny bug:
The builds are Koepis build XVID 17052002-1 and XVID-13052002-1.
Encoding is just fine as ever. But when loading the clip in Nadub (the version that came with Gordian Knot 0.23) and searching within the clip with the "snap to keyframes" option (left or right with shift pressed) the image sort of doesn't catch up with the frames.
I know it sounds odd, but when snapping to a keyframe and then pressing the right arrow to get the frame after the supposed keyframe, a frame from somewhere else gets displayed. So, when using Nandub to cut within the movie you don't exactly know where you are... When pressing the right arrow 2-3 times again, the actual display seems to catch up and frame after frame get shown instead of "jumping" somewhere else.
This doesn't happen when uninstalling this build and reinstalling the Koepi Build of 02052002-1 - video snaps correctly to keyframes and frame by frame stepping doesn't jump around.
Hope I explained this odd thing in a way you can understand what's happening.
It's no severe issue - I just can't take advantage of the speed optimizations. ;)
Cheers
Frank
same happens here,I just thouht it was my pc but now i see it happens to other people also
manono
20th May 2002, 13:18
I'm glad you mentioned that Franko30. Just as cult mentioned, I thought something had screwed up with my PC. But with me, it's with Nic's 5-13 build.
Koepi
20th May 2002, 13:40
The b-frame decoding stuff inserted into CVS by chenm001 will be responsible for this behaviour. So you can safely use that build for encoding and "normally watching" - just for editing you should switch back to an older build.
Try it again with vdub 1.4.10 and see if the situation gets better - or it might be that this support is just enabled for DivX5, Avery wrote something about "enabling it at compile time for xvid".
That's one of the drawbacks when it comes to the b-frame stuff...
For example all my files start with a green picture since that code got inserted.
I'll post about this matter in the xvid forums.
Thanks for the report - I didn't really think of it as a problem, but now that you point me to it, it surely is ;)
Best regards,
Koepi
I just tried with Vdub 1.4.10, and it doesn't improve. That bug is still there. I noticed also that if i jump from keyframe to keyframe, they don't stay the same.
For example: in the test i made with a trailer, i jump to a keyframe (nº462) and here i have a certain scene. Then i jump to the next keyframe(503) and i have another scene. But if i make it back to the previous keyframe (462) the scene isn't the same that was when i first got there. Confused? :D In the first time i got to keyframe nç 462, i had an image of Keanu Reeeves, but when i got there again backward from keyframe nº503, the scene wasn't Keanu anymore ;)
Koepi
20th May 2002, 14:34
Head over to http://www.virtualdub.org/virtualdub_news
and see what Avery writes about b-frames...
Maybe this sounds familiar when you read it. *g* :)
Belgabor
20th May 2002, 14:45
Originally posted by rui
I just tried with Vdub 1.4.10, and it doesn't improve. That bug is still there. I noticed also that if i jump from keyframe to keyframe, they don't stay the same.
For example: in the test i made with a trailer, i jump to a keyframe (nº462) and here i have a certain scene. Then i jump to the next keyframe(503) and i have another scene. But if i make it back to the previous keyframe (462) the scene isn't the same that was when i first got there. Confused? :D In the first time i got to keyframe nç 462, i had an image of Keanu Reeeves, but when i got there again backward from keyframe nº503, the scene wasn't Keanu anymore ;)
Gosh! And I though I started seeing things! This makes it quite a pain to select the right timecode for the chapters for ogm :(
Franko30
20th May 2002, 14:56
Originally posted by Koepi
The b-frame decoding stuff inserted into CVS by chenm001 will be responsible for this behaviour. So you can safely use that build for encoding and "normally watching" - just for editing you should switch back to an older build.
Best regards,
Koepi
Thanks for the answer, Koepi, and thanks to the others letting me know I'm not alone with the problem.
But, after all, this seems to be the end for newer XVID versions for me until this issue is solved somehow. Installing and uninstalling the codec about 3-4 times a day, just in order to be able to use the speedup and the ability to edit precisely eats up the time gained by the speedups...
So, I'm going back to spending some "quality lurking time" in this forum again :D
Cheers
Frank
ah yes,forgot about the opening green screen.This time I thought it was my settings for opening credits with 31 qu.:):D
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.