PDA

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.

Nic
17th July 2003, 13:39
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 :)

Nic
17th July 2003, 15:08
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 :|

Ewi
26th July 2003, 21:08
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)).

Ewi
26th July 2003, 22:47
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...

Nic
27th July 2003, 01:52
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.

Ewi
27th July 2003, 08:28
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...