Log in

View Full Version : XviD 17032002-1...X ;)


Pages : [1] 2 3

Koepi
17th March 2002, 10:09
Ahoy,

first new binary for today...

XviD-17032002-1:
- Some further speedups due to -h's optimised code, should be the same as current CVS.

There's still something going on so expect some more binaries during the day. The last additions give another nice speed hit :)

Regards,
Koepi

omol
17th March 2002, 10:51
Originally posted by Koepi
Ahoy,

first new binary for today...

XviD-17032002-1:
- Some further speedups due to -h's optimised code, should be the same as current CVS.

There's still something going on so expect some more binaries during the day. The last additions give another nice speed hit :)

Regards,
Koepi

But Luma Masking is broken again.....arggghhhhH!....:(

Sorry, false alarm. The crash while enabling Luma Masking is not reproduceable. Probably something wrong at my end.



regards,
omol

uManiac
17th March 2002, 12:01
There have been 3 builds today on on my page at http://www.heimsnet.is/kg and there probebly will be more. Of course my builds don't include Nic's DS filter, just a pure CVS build. :D

uManiac

Koepi
17th March 2002, 12:08
Jupp, those files are in the CVS in the meantime :)

Regards,
Koepi

Nic
17th March 2002, 12:44
Latest is up at mine now :) Should be fastest ever :D

Cheers,
-Nic

ps
The DShow filter with brightness & full post-processing doesn't ever get above 59% on my Duron 800 :)

-h
17th March 2002, 12:50
The DShow filter with brightness & full post-processing doesn't ever get above 59% on my Duron 800 :)

Decoding should be quite a bit faster now, as interpolation is used so heavily. It was only using xmm/3dn for about 25% of interpolation requests before, should be up around 85% now (damn hv rounding, that's all that's keeping mmx in there :)).

-h

Nic
17th March 2002, 12:54
Hi -h,

Thanks for sending that ASM, ive been trying to reply to you...but my web mail won't send (receiving is fine though...weird)

(I have quite a headache from the fosters... :( )

Cheers,
-Nic

-h
17th March 2002, 13:00
Thanks for sending that ASM, ive been trying to reply to you...but my web mail won't send (receiving is fine though...weird)

Heh no probs, I committed the stuff I sent you about 20 minutes later, then added more after that. So the email wasn't much good :)

(I have quite a headache from the fosters... :( )

That is the penalty for drinking the wrong beer.

-h

sierrafoxtrot
17th March 2002, 13:53
good going guys, you got my eternal gratitude for all your effort :D all the recent builds have been pretty much as perfect as one can wish for. 5 updates to the CVS already today and it's only 1300!! woo hoo!!

@nic stick with stella mate, it's worth the hangover! LoL ;)

-h
17th March 2002, 14:05
Core has been updated again - Isibaar added some (significantly) faster hv interpolation code for xmm/3dnow. Might not make a big difference to overall speed, but the faster the better :)

-h

Nuro
17th March 2002, 14:59
Sheesh...

I can now play some really high res ( > 1024 x X) clips with all post processing features on, and not one dropped frame. The usage with post processing is now always under 50% (on a P4 1.5 Ghz). Normal playback is around 12-25%. This really kicks DivX5....

Nice work guys (and thanks).

Gerard

Nic
17th March 2002, 15:01
Latest CVS is up at: http://nic.dnsalias.com

Ive also added a very simple calculator to make knowing the file size for XviD a bit easier :)


Cheers,
-Nic

-h
17th March 2002, 15:04
I can now play some really high res ( > 1024 x X) clips with all post processing features on, and not one dropped frame. The usage with post processing is now always under 50% (on a P4 1.5 Ghz). Normal playback is around 12-25%. This really kicks DivX5....

Wow, and XviD's core doesn't even have SSE2 asm in it yet. Even the existing mmx/xmm/3dnow code can be optimised further, but P4 owners could have a good 20% or so speedup in the future.

-h

Koepi
17th March 2002, 15:16
XviD-17032002-2:
- Some of the code optimised further by Isibaar and -h.
- Should be speedwise up-to-par with Nic's binary now since i forgot to merge some core changes %)

This should be the last installer binary for some hours now, so grab it while you can :)

Regards,
Koepi

Nic
17th March 2002, 15:24
Bet mine's faster ;) :D

-Nic

Nic
17th March 2002, 16:31
Thanks to Koepi's script, mine is now a NSIS installer like Koepi's.....Makes things alot easier.

Please report any problems :)

Cheers,
-Nic

Koepi
17th March 2002, 16:38
Finally :)

So no need for me to update my binaries too often, it's now easy to install and uninstall Nic's build as well.

Nice Nic! :)

Nic
17th March 2002, 16:40
I thought it would be more difficult than it was (Ive had bad experiences with InstallShield)

Its a great script language...they couldn't of made it easier :)

Cheers,
-Nic

neodivx
17th March 2002, 18:10
hi. is that possible to find somewhere the script of the nis installation. I have try myself, but i don't know what's the registre key you change to install. Could you help me ? thanks a lot.

yokem55
17th March 2002, 18:15
Nic, the Xvid options explained pdf on my system is corrupt with your latest bundle in the nsis installer....

Nic
17th March 2002, 18:44
Cheers Yokem....Ill correct that soon.

-Nic

ps
@neo:
Search this forum for Nullsoft & then you will find the script.

wing1
17th March 2002, 18:46
I bow to the masters :D Great stuff guys..

Now I am gonna be sleep depreviated :p

neodivx
17th March 2002, 18:58
i have try, found 13 messages, but not the nis code. could you tell me more if you have time, like the message link or nis link ? i know that i ask a lot, but right now, i install the codec with the inf, witch is a little old way. hehe. thanks anyway!

Nic
17th March 2002, 19:09
There updated my site, made Koepi's pdf a seperate download....hope koepi doesn't mind :)

Cheers,
-Nic

@Neo
1) Do that search
2) goto post called: Cvs 2002-03-05
3) goto its second page

neodivx
17th March 2002, 19:17
hehe. you know so well the forum that it's embarrasing. Thanks, i have it. i will look on it. great job! by the way, what's about the dshow ? what was the problem with gnu source ? Normaly, as i know ( but i can be wrong), opendivx is a opensource as well or something different ?

Nic
17th March 2002, 19:27
OpenDivX was under the OpenDivX License, which isn't quite as "liberal" as the GPL one (actually the OpenDivX license is quite restrictive)

You can read more about these licenses in the first news item at xvid.org

Cheers,
-Nic

slavickas
17th March 2002, 20:08
Originally posted by Nic
OpenDivX was under the OpenDivX License, which isn't quite as "liberal" as the GPL one (actually the OpenDivX license is quite restrictive)

You can read more about these licenses in the first news item at xvid.org

Cheers,
-Nic

i've just remembered interisting post by Junto(probably you know where he works:

Second, what is DivX 4.0 (Beta) NOT? It is not the same as OpenDivX, and it is not released under an open source license. The source of DivX 4.0 (Beta) is not available. (The source for OpenDivX remains available, however. In fact, today we also released the OpenDivX decoder under the GPL.) Those two facts are likely to cause a little confusion and some furor, so let me address them both in more detail.

have they GPL'ed decoder or this was another bull[shudas]?

trbarry
17th March 2002, 20:18
Wow, and XviD's core doesn't even have SSE2 asm in it yet. Even the existing mmx/xmm/3dnow code can be optimised further, but P4 owners could have a good 20% or so speedup in the future.

I've been looking at adding some P4/SSE2 code. Is anybody else working on that?

And does anybody have any feel for how often the data is 16 byte aligned already? P4's sort of like that.

@-h YGM.

- Tom

athos
17th March 2002, 20:30
I tried Kopeis latest build (XviD-17032002-2). I must say it works great! Encoding speed has increased notably since Core 1.0 (I'm getting 30-40 fps now with motion precision 6. Quality is excellent. Decoding/postprocessing is also very fast, much lower cpu usage than before, even lower than divx5.

Great work all you Xvid developer guys!

Uli
17th March 2002, 21:53
@Nic:

I used your latest build with your 'MiniCalc' ;)
on the anime "Armitage III" with 2 pass internal VBR.
What should i say? Pointlanding!
Exactly 699.5 MByte for 1 CDR in really superb quality.
Great :D

Thanks to you and of course Koepi, uManiac and all the others!

greetz, Uli

BTW: I'm a C/C++ Developer too, if a had more spare time,
i would like to contribute to XviD too as i did sometimes
on LAME/Gogo. I'm a registered sourceforge user and have
CVS installed. But at the moment i'm too busy at work.
Additionally i think, i cannot compete with your speed
of new improved releases ;) Keep up the outstanding work!

Teegedeck
17th March 2002, 22:10
I haven't really a senseful contribution to make to this thread, but I think it's time for a big THANK YOU! to all of you developers! You guys are marvellous, keep it up! :)

Nic
18th March 2002, 00:08
@Teegedeck:
Sorry for being lazy (im scouring google now), but where did you quote that from...that would be quite interesting (& save me a lot of hard work :) )

Cheers,
-Nic

philippas
18th March 2002, 05:40
@Nic,Koepi,-h & uManiac

Is there any possibility for a calc function which will calculate a good value for the curve compression like nandub has ?
I remember it was a good starting point for the curve compression.
By the way how does that function works in nandub ?

gnoshi
18th March 2002, 06:19
A question for the mitey developers...
As things have progressed I noticed you were starting to use more asm to improve speed.
It that asm just hand-optimised versions of what already exists in the code, or bits being written in pure asm - no original code involved?

Basically what I am really asking is - if someone wanted to do some porting of the codec (to a mac for example), would the asm screw them trying:confused:

sorry if it is a stupid question

gnoshi

-h
18th March 2002, 07:23
It that asm just hand-optimised versions of what already exists in the code, or bits being written in pure asm - no original code involved?

Everything starts as pure c, and is asm-optimised separately. For example in the core source, there is a sad16_c function (performs SAD on a 16x16 pixel block in pure c), sad16_mmx (mmx asm, much faster) and sad16_xmm (xmm, much faster again). The asm functions are in a separate file and directory (intel_x86\sad_mmx.asm) to the pure c file (sad.c).

The only thing stopping a mac port is the lack of a mac developer :)

-h

gnoshi
18th March 2002, 08:26
Thanks for that =)
*happiness abounds*

Pity i'm not a mac developer hey.. :(

Maybe one day

gnoshi

xris
18th March 2002, 09:25
Nic,

I'm not sure which quote you're talking about, so I'll try to answer both. :-)

It's a man's life in Doom9's 52nd MPEG division.

I bet this is a derivative of Monty Python's "It's a Man's Life in the Modern Army".


"The cat sat on the mat."

I believe this is from _Dead Poet's Society_. Keating asks for a poem from each member of his class, and the slacker of the class comes up with that quote as his poem.


Chris

Nic
18th March 2002, 10:01
:D

That wasn't the quote I was referring too, although I think I asked for its meaning in the wrong thread (I was very tired last night :) )

Teegedeck (I think?) posted saying that Junto had once stated that the OpenDivX Decoder had been made GPL (which would make kinda sense, but im not sure....so I wanted to find out for myself)

(If it is GPL, then I can put the source code in the CVS straight away)

Cheers,
-Nic

Nic
18th March 2002, 10:41
Theres the GPL and DivX Decoder link, also an interesting thread for the history archives of the development of OpenDivX->DivX

http://forums.projectmayo.com/viewtopic.php?topic=2431&forum=3

Cheers,
-Nic

ps
Also the thread adds to why Gruel is such a legend :)

rui
18th March 2002, 11:54
Nic, your calculator was a very good idea.

I believe that audio bitrate assumes that one is encoding the audio at a constant bitrate, right?
Just na ideia: maybe you could place an option so one could also input the audio file size, since i believe that there are many out there that use VBR mp3.

Nic
18th March 2002, 12:03
Thats a good idea Rui :)
(I forgot about that seeing I use ABR...ill change it tonight :) )

Cheers,
-Nic

Apo
18th March 2002, 13:07
Hi guys!

I'm new here, no not realy new, I'm reading all the stuff in the boards here for quite a while but now I wanted to post something.

For a few weeks I'm interested in xvid. I'm comparing it with divx 5 and I thing from a few of quality they are practically equal but divx 5 is way faster. Since the 1703 build is supposed to be faster than build 1203, I used before, I tried it but I got no speed up. I used a aproximately 20min part of "face of" and all settings are default except motion serch precision is ultra high and I use quantification mode mpeg with 2passes. Does the speed up only affect settings I'm not using or is it too small to notice? But I doubt it ecause some people stated that their speed raised noticeable. I use a Athlon 1200Mhz.

Apo

rui
18th March 2002, 13:22
Nic, i too use ABR, but i believe that ABR is also a form of variable bitrate, correct? Because, agter doing the audio encoding, using ABR 128, i always get audio files with ~118-122 kb, depending on the movie.

Or not?

Nic
18th March 2002, 13:34
Thats true, but the difference in size is minimal & im not that big on accuracy :) But don't worry as of tommorrow ill have updated the calc :)

Cheers,
-Nic

-h
18th March 2002, 14:03
For a few weeks I'm interested in xvid. I'm comparing it with divx 5 and I thing from a few of quality they are practically equal but divx 5 is way faster. Since the 1703 build is supposed to be faster than build 1203, I used before, I tried it but I got no speed up. I used a aproximately 20min part of "face of" and all settings are default except motion serch precision is ultra high and I use quantification mode mpeg with 2passes. Does the speed up only affect settings I'm not using or is it too small to notice? But I doubt it ecause some people stated that their speed raised noticeable. I use a Athlon 1200Mhz.

To make the test fair, use H.263 quantization and search precision 5. Then XviD and DivX5 will be using the same internal options (or as close as possible). I have a K7 1200 also.

The results of the test I described:

- Quantizers fixed at 4
- XviD: H.263 quantization, motion search precision = 5
- DivX5: performance/quality = slowest

XviD took 110 seconds, DivX5 took 120.

XviD's file size was 30.4 MB, DivX5's was 34.1 MB - thus for the same quality, XviD is 10% smaller, and compresses faster too :)

-h

Apo
18th March 2002, 14:26
thx -h I will try with theses settings. If the speed is really nearly the same then I will stick to xvid.

But whats the case with the newest build it's supposed to be faster than the older one but I got no increase in speed, not even one minute with a file that needs 80 minutes to encode, why? Is the increase really less than 1-2% ?

Apo

Teegedeck
18th March 2002, 14:37
@Nic: The citation you were referring to is from slavickas (just a few post above), I believe?

@xris: Both from Monty Python, kind of. :)

-h
18th March 2002, 14:43
But whats the case with the newest build it's supposed to be faster than the older one but I got no increase in speed, not even one minute with a file that needs 80 minutes to encode, why? Is the increase really less than 1-2% ?

Can't explain that - latest build is encoding anywhere between 4% and 10% faster on my PC :)

-h

Apo
18th March 2002, 14:53
hm wicked...
but great thanks -h for your fast replies.

Apo

saVe
18th March 2002, 17:06
i'm almost sorry for posting such a small bug:

i use nic's latest build. when i select encoding mode "null - test speed" and click the advanced options button vdub crashes.

damn this is close to being nothing but it's still crashing so i thought it might be usefull in some way.

btw: speed rocks, dsf rocks, new look rocks! ;)