XviD 17032002-1...X ;)

[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

[omol]

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]

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]

Jupp, those files are in the CVS in the meantime :)

Regards,
Koepi

[Nic]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Bet mine's faster ;) :D

-Nic

[Nic]

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]

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]

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]

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]

Nic, the Xvid options explained pdf on my system is corrupt with your latest bundle in the nsis installer....

[Nic]

Cheers Yokem....Ill correct that soon.

-Nic

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

[wing1]

I bow to the masters :D Great stuff guys..

Now I am gonna be sleep depreviated :p

[neodivx]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

@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]

@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]

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]

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]

Thanks for that =)
*happiness abounds*

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

Maybe one day

gnoshi

[xris]

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]

: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]

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]

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]

Thats a good idea Rui :)
(I forgot about that seeing I use ABR...ill change it tonight :) )

Cheers,
-Nic

[Apo]

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]

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]

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]

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]

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]

@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]

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]

hm wicked...
but great thanks -h for your fast replies.

Apo

[saVe]

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! ;)

[drZymo]

Whoaaaaa

First of all i would like to thank you dudes for the efforts. XviD is really showing off right now. The speed at my system (p3@810MHz) has increased from 8-9 fps to about 13-14 fps. Amazing. :P

So well i tried to stress test the codec by making a movie of 1024x432 (the matrix off course ;)) But the codec causes a crash with both builds (by Nic or Koepi). So i tried some different settings, but in vain. I also tried an older version of VirtualDub, which also resulted in the same error. The previous build I tested was CVS 8/3 which worked perfect @ 1024 resolutions.

Perhaps you guys can solve the problem. Some little crash info:
The code:
0226688a: movq mm7,[002288080h]
02266891: mov eax,00000008
02266896: movq mm0,[esi]
02266899: movq mm1,[esi+1]
0226689d: movq mm2,mm0
022668a0: pavgb mm0,mm1
022668a3: pxor mm1,mm2
022668a6: movq mm2,[esi+edx]
022668aa: movq mm3,[esi+edx+1] <-- FAULT
022668af: movq mm4,mm2
022668b2: pavgb mm2,mm3
022668b5: pxor mm3,mm4
022668b8: por mm1,mm3
022668bb: movq mm3,mm0

Registers:
EAX = 00000001
EBX = 02d51df8
ECX = 00000000
EDX = 00000440
EBP = 02de1df8
DS:ESI = 0023:02b33bb8
ES:EDI = 0023:03073bb8
SS:ESP = 0023:0360f358
CS:EIP = 001b:022668aa
FS = 003b
GS = 0000
EFLAGS = 00010202

MM0 = 1213121212121110
MM1 = 020100000003011f
MM2 = 0000000000000000
MM3 = 0000000000000000
MM4 = 131212121211100f
MM5 = 000f001000110011
MM6 = 00ff00ff00ff00ff
MM7 = 0101010101010101
Crash reason: Access Violation

And i say it again. You peeps rock !! :P

[OUTPinged_]

try it with 1280x resolution, same as for HDTV.

[drZymo]

Originally posted by OUTPinged_
try it with 1280x resolution, same as for HDTV.

w00psie :stupid:

didn't test that setting, which works fine.

But well it's not 1024 :D so can someone explain what may cause the error?

[Nic]

It does crash on this celeron as well, even at 1280 with the access violation.....

-Nic

ps
This is a new core bug & has been around since the very first version of the new core Koepi sent me (ive just tried it with that binary)

pps
Just tried it with 1280x & another vertical resolution (544) & it worked....any ideas anyone.....1280x432 & 1024x432 does not work for me....

[trbarry]

I don't know enough about the architecture yet to fix it but that code looks like the interpolate_halfpel_hv_xmm code. Maybe it fell off the end of a buffer?

- Tom

[vinetu]

Hi,

Test system:
Celeron Tualatin 1200@1500
500MbRAM
winXP:
Xvid Koepi's and Nic's latest builds
1280x432 - crash!
1024x432 - crash!

win98SE:
1280x432 - crash!
1024x432 - crash!

win98SE SAVE MODE:
1280x432 - WORK as expected!!!
1024x432 - WORK as expected!!!

VGA:
ATI Rage 128 , Voodoo 3 2000 both in

Best Regards !
vinetu

[drZymo]

It's really strange. The 432 vertical resolution is a resolution which (if straight from a dvd) doesn't have to be resized. My first thought was that it's a resize prob, due to perhaps a devision by zero. But the resizing is done externally and has nothing to do with the encoding. So that shouldn't be it. :confused:

But why does Safe Mode work ?? and normal boot doesn't?? reaaaaaally wierd :D

[OUTPinged_]

maybe try removing some cpu optimisations


most stupid advices ever! amount is limited! =)

[vinetu]

It's nothing to do with "432" but with 1024 and 1280 -
a clip 1048x432 is working fine .
Unfortunately I can't give you more than this
statistics ...

[vinetu]

Hey Nic,

May be this build is using a VGA for rendering !?:D

May be I should buy a GeForce 4 Direct 3D accelerator (what about OpenGL?)?

[-h]

OK this is weird.

I'll play with cbr+lumi masking crash and this resolution crash tonight.... could be a padding problem.

-h

[Koepi]

Nic,

may you be so kind and make it sound a little less like a problem that I introduced?
I'm very confident that the error isn't on my side :P

Warm regards,
Koepi

[wing1]

Can I have another 10% increase in speed ??? :DD

[trbarry]

Can I have another 10% increase in speed ??? D

I just replaced a loop in xvid core with an unrolled loop of P4 SSE2 code. It made it about 2% slower on my 1.7G P4. I promise not to release it. ;)

At that rate we will soon have to stand and turn the crank to encode.

It has been a fairly strange day.

- Tom

[wing1]

lol...funny..very funny....frame by frame i presume :)

[Nic]

Oops! Sorry Koepi, I didn't mean it like that at all, I just meant the bug was in there even from the earliest version of the new core (& the earliest version of the core was kindly sent to me by you)

I wasn't trying to blame anyone, just trying to help with the bugtracking :)

Cheers,
-Nic

[Nic]

ps

I changed the MiniCalc program in my install, being 30kb it wasn't mini in my view, so its now 6kb (completely uncompressed :) )

You can now specify the size in bytes of the audio file, or browse for the file to get exactly the right size. (the calc also displays more information)

Cheers,
-Nic

ps
The build on my site has stayed at 17/03/02 for such a small change

[avih]

nic:

any chance for drag&drop interface for avic? :)

[edit]
could u make a version for me and call it 'avih' instead lol

[Nic]

Yup, hadn't thought of that, good idea. :)
Ill also make the calc able to accept dragged audio files. :)

Cheers,
-Nic

ps
I don't have the source for AviC here at present, so youll have to wait until tomorrow for it :(

pps
Does anyone know of a better icon I could use for my programs ???
(could someone make me one ???)

ppps
Just updated MiniCalc on my site to be able to audio drag files, to set the audio size

[avih]

>"I don't have the source for AviC here at present, so youll have to wait until tomorrow for it"

that's SO SO SO sad :(
lol thx nic

[Nic]

XviD.org have updated there news page!!!

(quite a rare occasion :) )

Cheers,
-Nic

[athos]

goody! seems we will soon see an xvid codec with b-frames, qpel, gmc, and everything so it is no doubt better than divx in every aspect! imo xvid is allready on par with divx5, but with these new features it will surpass divx totally!

[Nuro]

Hiya..

On the subject of B Frames... Can someone please explain (in basic terms), or give a url to B frames explained. I would like to know how this will benefit the avarage user? I know about Keyframes and such, but that is about it. What are it's Cons and Pro's? I have heard a lot about it but know almost nothing about it.

TIA

[Koepi]

It's even in the Q&A, please respect the forum rules and actually read the FAQ!

[-h]

On the subject of B Frames... Can someone please explain (in basic terms), or give a url to B frames explained. I would like to know how this will benefit the avarage user? I know about Keyframes and such, but that is about it. What are it's Cons and Pro's? I have heard a lot about it but know almost nothing about it.

The second post in the XviD Q&A (http://forum.doom9.org/showthread.php?s=&threadid=16935) sticky thread has some info I wrote up about B-frames a while back. It should still hold true.

B-frames don't really save you all that much space, it's just that you can quantize them heavily (DivX5 doubles the quantizer for B-frames, for example) without people noticing too easily. It also lets you seek faster, as you can skip the B-frames and only decode P-frames, to get where you want to go.

There's still a fair bit of tinkering to go before they'll be in XviD..

-h

[Nuro]

Sorry 'bout that. I only read the first 11 questions for some reason :o

Thanks.

Reading it now...

[rui]

Originally posted by -h

B-frames don't really save you all that much space, it's just that you can quantize them heavily (DivX5 doubles the quantizer for B-frames, for example) without people noticing too easily. It also lets you seek faster, as you can skip the B-frames and only decode P-frames, to get where you want to go.

There's still a fair bit of tinkering to go before they'll be in XviD..

-h

I must confess i am a little sad to read this. I must admite that latelly i am using divx5 pro in some of my tests, and was expecting xvid to have b-frames too, so it could compete and surpass divx5 pro.

But, oh well,it will be ready when it's ready ;)

[wing1]

@rui

Don't be sad, These guys are doing such a wonderful job and they will have B-frame support soon enough when it is ready just like de-interlace support :D The codec is already on par with Divx5pro without these features, and when they are there, It will be on top.

Think of it just like the commercial Heinz Ketchup ....Good things come to those who waits :D

....is there another 2-10% increase in speed in the work? hehehehe

[OUTPinged_]

lol. more speed is good but better compression comes first :P

[rui]

Well, i just want more quality. Speed comes in a distant second place.

It's easy to make such claims when you have a XP to encode :D

[MaTTeR]

@rui
In the states we would say something like...Take the Pepsi challenge and pick the winner. To be more clear, run a comparison test and then tell us if it competes. Stop looking at the specs on paper and just view the clips. Like most, I think you'll agree it already surpasses Divx5 in most areas if not all.

[Ripe73]

HI All!!

I think XviD kick's ass already now even without B-frames mm and with Ogg it is unbeatable(Oggcut is OUT!!:D ).So this codec can only be better and better

Thanks for a good job all XviD Coders out there!!!

[rui]

MaTTeR, right after divx5 pro came to surface, i conducted a number of tests, both using movie trailers and full movies, and, IMHO, divx5 pro retains a little bit more detail than xvid. I posted this both in the xvid forum and the divx5 forum.

Please, that was only my opinion.
Everybody should make their tests and judge by himself. I know that probably you and a lot more don't agree with me, and i don't want to start any battle over this.
For some time now a have been following the xvid development, and if you or anybody else look for my posts here, will see that i always tried to give my small contributions to the growth of this codec. So, i can say that i am not divx5 biased in any way. Like i said above it's only my opinion.

Currently, with the last builds, xvid has reach a great quality level and speed. Again, IMHO, it only needs a little bit more to be superior to divx5 pro.

Please, don't miss interprete my post.

[wing1]

@rui

If i am saying anything wrong in my previous post, I did not meant for it to come out like that.

I know what you mean about the detail :) However, as in any codec, I have tweaked the heck out of xvid and the associated DSfilter and I got it to perform the way i like it to be, and I am sure that you are doing the same tweaking as I have done; B-frame support would probably enhance an already great codec to a superior codec.
I am too are after details, and what I've tweaked requires a little more speed boost, whereas what you are tweaking needs alternative compression algorythm :D

I am working with capture media (real time compression with xvid + filterings), and XP or not won't help me here. Hence, like you I would like to see de-interlace support in the codec as well as B-frame support in the future releases.

The guys are doing such a great job currently on the front end optimizations, and perhaps both of these features will come later as they have promised. So we probably will have to wait until they are ready to approach those arena. Probably B-frame support will come before the de-interlace option :D

[Nic]

ps
I spotted a bug in the DSF when setting the brightness down (rather than up), ill try and fix it tomorrow.

Im doing my own big test with DivX5 & XviD, hopefully XviD will triumph....but I dont know...

-Nic

[Pasqui]

@Nic
Could you possibly add an option in your mini calc so as to calculate the video size for a ogg container movie instead of an avi file ? It would be very usefull as GKnot dos not support this function yet.

Cheers,
Pasqui.

[rui]

wing1, your post didn't have anything wrong :)

I just was under the impression that you guys thought that i was one more guy that was shouting opinions about codecs without anything to backup them up. I didn't want to be miss understood.
I can see that if you are doing tv-capturing, the most important to you is deinterlace and speed.
But maybe you could Greedy to deinterlace your source? In the few dvd's where i got interlaced sources, i always used Greedy with good results, with lost of some speed. But you could have problem with loosing speed, and not being hable to reach real time speed capturing?

Nic: I sure would like to read your impressions about both codecs ;)

[philippas]

Hey guys how about my suggestion for a calc button for the curve compression, like Nandub has ?

[rui]

Humm.. How it would work?
Instead of we defining limits like 25% high and 15% low, it would use some kind of search to discover the perfect values for that specific source?

[Teegedeck]

I suspect Foxer will come up with something sometime. My own suggestion was that you specify how much stronger the compression of big frames is, compared to small frames (like max quant big frames = max quant small frames + 2).

[sierrafoxtrot]

well, i've got to agree with rui ... divx5pro with B-frames just about edges out XviD for really demanding movies, fr'instance, a 1CD rip of moulin rouge or even that old favourite, the replacements. what i do like, however, is the fact the xvid is open-source, and although i don't code, it has certain implications for end-users like myself. plus, xvid is hell of a lot more tweakable for all those compulsive option junkies out there ;)

and the pace of development is phenomenal ... in the last three months xvid has gone from 2nd choice compared to divx3.11/nandub to top of the heap. even with divx5pro, consider how well xvid fares. and i'm all for b-frames, when they come, because that will probably sell me completely.

... right, now where's my alco-pop? ... :D

[yokem55]

Ooh....Moulin Rouge...that one has to be a toughy to do on one cd considering all of the crazy camera work in that flick.....might be a new challenge once I figure out how to do Pearl Harbor on one cd.....
(I actually do most of my rips on two cd's but try for one just for the challenge....)

[sierrafoxtrot]

@yokem55

LoL, managed to get a decent watchable 1CD rip of moulin rouge with divx5pro (as long as your sat at least a couple of feet away from the monitor), but xvid rips are less than satisfying. maybe (if) foxer manages to sort out something to mess with curve compression.

[Acaila]

@yokem55

I've done Pearl Harbor on 1 CD just to see how it would look as well. I can tell you it wasn't pretty. Not even in B&W. Not even 15 feet away from the screen...

[MaTTeR]

Sorry if this is slightly OT.

This isn't a big deal but just a slight request for sometime down the road. Would it be possible to have the "2ns pass stats" text field default to the same path as the "1st pass stats" field? This would just save some of us lazy people a few clicks;)

Thx

[Ripe73]

HI!

I wonder if it possible to have a "copy to clipboard" function so if i want to post my settings or save my settings for a movie i just push it and paste it into notepad.

Just a ide:)

Thanks

[Emp3r0r]

ripe: do you mean like the command line thing divx5?

[philippas]

@Ripe73
Just save all the settings into a vcf file with virtualdub.

For the calc button of the curve compression, that i suggested, i was thinking something like, examine the stats file after the 1st finishes and save a value for the curve compression which will be used in the second pass.
That value will be a starting point for the curve compression specific to a given source. I don't like applying curve compression blindly.
What do u think ?

[morello12]

I think a feature similiar to that found in Nandub, a guide to let you know the quality it will be based on the bitrate you enter for the second pass... a calc button, would be welcomed more than anything else. Sure, perhaps I can load it up in some third party ultility and do three or four passes and get it perfect, but nandub had a sweet implementation, where I run a first pass, and make the calc button say 10% by changing the bitrate around, and then I knew I'd hit the quality I want. With Xvid it's kinda like a guessing game for now. Render 2000 frames on the second pass, cancel, watch, raise/lower bitrate. Render 2000 frames, etc etc. A feature in the options to do what Nandub did to the stats file would be great! :)

[primitive]

Originally posted by Pasqui
@Nic
Could you possibly add an option in your mini calc so as to calculate the video size for a ogg container movie instead of an avi file ? It would be very usefull as GKnot dos not support this function yet.

Cheers,
Pasqui.

I've found that under gknot setting Interleave Overhead to "no audio" gives more or less accurate results.

-p

[Pasqui]

@primitive
Yeah, I know and use this currently. But it becomes more and more inacurate with long movies. But it is better than nothing ;)