View Full Version : Nic 16/07/03 build
Selur
17th July 2003, 08:30
just thought I start a thread about this build,..
(so we don't have to overrun the "Quarterpel" (http://forum.doom9.org/showthread.php?s=&threadid=57219) thread.
@Nic: Thx for the build
Cu Selur
madman_looney
17th July 2003, 09:13
What's the difference between Nic's build and Keopi's build?
Selur
17th July 2003, 09:19
As far as I can tell:
Nic used another compiler, and another branch of the cvs. His build doesn't include the new bframe threshold and trellis quantisation.
So, it does include Nics newest DShow Decoder. :)
XVID - 16/07/03
Changes:
HEAD build (old Dev3-Api)
Intel Compiler 7.1 Compiled
DShow Updated
from: Nics side (http://nic.dnsalias.com/xvid.html)
Cu Selur
JasonFly
17th July 2003, 11:37
@Nic:
Could you add a date to the Decoder build? This will be better to know the build that we are dowloading.
On your site, I don't know if the Xvid Standalone decoder is an old build or a new.
I heard from Koepi, he said that sysKin had backported the trellis code to dev-api-3, and thats what koepi uses. So thats why he's got trellis and I havent.
@JasonFly: I always update the decoder if I update the build. But ill make it more obvious on my site.
Let me know if the decoder works better on the new material :)
-Nic
Th3-S4int
17th July 2003, 14:34
@Nic
Can you may say what you change in the decoder? (Because i use only your dshow filter, because FFDshow is for me to complex, there are to many settings i can change and i have no idea for what they are)
P.S. My english is bad but i will practice :)
I didn't change any of its source code but it now uses the latest libxvidcore, which is the xvid en/decoding library. i.e. it now uses the walken idct rather than simpleidct
RadicalEd
17th July 2003, 21:30
some quick avisynth psnr readings:
1 mbps, default + VHQ 4, chroma motion, 2/180/100 bframe, chroma opt
Koepi 6/24/03: 36.4389
Koepi 6/24/03 w/ trellis: 36.3964
Umaniac 6/26/03: 36.2124
Umaniac 7/17/03: 36.2388
Nic 7/16/03: 36.2388
I havent bothered doing an in depth visual comparison yet because I'm pretty sure it would be near impossible to tell the difference between them :/
fixed psnr readings :\
overall rankings are still the same though
iago
17th July 2003, 21:30
Might sound a bit off topic but in order to decode XviD content encoded with gmc, qpel, and high-bitrate custom matrices without any problems, currently xvid decoder is the way to go. Libavcodec exhibits problems with all the stuff mentioned above.
Well, regarding the xvid-decoder side of things... ;)
regards,
iago
Sagittaire
18th July 2003, 03:44
@ RadicalEd
Koepi 6/24/03: 26.1907
Koepi 6/24/03 w/ trellis: 26.1515
Umaniac 6/26/03: 26.0579
Umaniac 7/17/03: 26.0824
Nic 7/16/03: 26.0824
Very small mesure ... !!?
Dimension?
Bitrate?
Please ... ;)
sysKin
18th July 2003, 11:21
Originally posted by Sagittaire
Very small mesure ... !!?
Dimension?
Bitrate?
Very very small. Was it quant 30 - or maybe you just forgot to trim first frame out of the b-frame video?
RadicalEd
18th July 2003, 12:01
I mentioned the bitrate was 1 mbps but I didn't mention that it's 640x480 23.976fps. First pass bitrate was around 3.5 mbps. I suppose the material was kind of hard to compress :/
Yeah I trimmed the B-frame warning dealie in all of those :0
.. wait
I also trimmed the first frame in the source :|
crap :|
yeah.. I fixed that
JasonFly
19th July 2003, 02:08
Originally posted by sysKin
Very very small. Was it quant 30 - or maybe you just forgot to trim first frame out of the b-frame video?
I have alvo made this mistake whith my first psnr measures.
One frame has a psnr of 7,xx db.
I looked the frame in the two clips but it wasn't the same.
saeed
19th July 2003, 10:27
What about encoding speed?? Are they the same??
With such close PSNR results, I guess encoding speed could decide.
RadicalEd
20th July 2003, 02:59
sorry, I didn't pay attention to the speed :|
I get crashes in the Dshow part of this build when closing the player (IIRC I had the same crashes with the old build too, but did not look after it). When and how often it happens please have a look at 6.).
Of course I'm talking about the build from the 16.7.03.
1.) At first I thought it is zoomplayer related; so I started MPC. Result: I crashes in both players. Samples:
http://www.stw-bonn.de/~z25525/public/error_xvid_mpc.gif
http://www.stw-bonn.de/~z25525/public/error_xvid_zoomplayer.gif
(Error messages are in german; if you want me to translate, say so...)
The first adress in the mpc screenshot changes each time; the second seems to be constant. For zoomplayer I can't confirm this behaviour cause the error message is displayed for a 1/4 second and I'm lucky to have this one screenshot.
2.) Then I thought it is Reclock related: After disabling Reclock and doing a restart I get the same crashes
3.) I'm not using ffdshow so it is not related to it
4.) I get no crashes with any other Dshow Filter. With the Dshow filter coming with Koepis lastest build (XviD-24062003-1.exe) I get no crashes.
5.) It is not related to the XviD Version used to encode the movie. It is not related to the virtualdub version used to encode/mux. It is not related to a specific group of file (i.e. it's the same with all XviD files I have)
6.) It happens only from time to time and is hard to reproduce exactly but I think I found a reasoning:
When I start up zoomplayer and play my file everything is fine when closing; when I play my file and seek everything is fine.
But if I play the file and close the player while the seeking is in progress (i.e. while the decoder is doing a fast forward to get to the correct frame), it crashes in many cases.
If it crashes one time it crashes in 1 of 2 cases after that; i.e. it crashes then even if I wait until the seeking is done with its fast-forwarding.
Don't know if this is the correct reasoning but it's the only one I found.
If you would like me to get any other information I will do so
(System is AthlonXP 1700+ (not overclocked), 256MB RAM (Infinion), WinXP SP1 with all actual patches and updates; overall I have a very stable system (I did around 20 CCE encodes (10 hours) and never had a crash; around 30 XviD/DivX encodes without any crash)).
I think I found the reason. I'm using these postprocessing options:
* all deblocking on/deringing complete off
* brightness one tick higher
* everything else is on default
I think the brightness control is causing my problems. I reset the options, then I reactivated deblocking options and after a restart I could not produce a crash so far with the procedures described above. If I reactivate brightness (one step higher) I can see my crashes again.
I'm not totally sure but I think it's the brightness...
I've been meaning to change the brightness function...ill release a new one soon, and see if that helps matters
-Nic
dragongodz
27th July 2003, 06:43
thanks Nic. its good to see your releases back.
OK, thank you...
I will try it when it is available...
Ewi
2nd September 2003, 10:21
It's over a month now. Only a short question: Will we see a new decoder build only after a devapi4 build is ready?
(I don't want to demand anything; would be nice to know)
Nic
2nd September 2003, 15:14
sorry ewi, I havent had time for much recently...and won't have for a little while. :(
Ewi
2nd September 2003, 16:55
no reason to excuse :) Thank you for your answer...
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.