Cvs 2002-02-18

[-h]

Figured I'd start a new thread.. "My XviD binaries" is getting too large.

I merged a bunch of stuff a few minutes ago, new credits modes, some of Koepi's mods (didn't get the 101-byte frame thing.. shouldn't it still be scaled down to 101 bytes instead of left as nns1->bytes?) and the quant_type modulation (requires core mod, which I think Isibaar will be committing some time soon with more mods).

Very experimental - if you download a 2002-02-18 build, you can be guaranteed that something will go wrong. You've been warned :)

I would've tested more, but I'm very tired and wanted users to test for me, ala microsoft. Ah it's a developer's life for me.

-h

[Nic]

Guess what? :)

Get at:
www.freewebz.com/xvid
or
xvid.stormpages.com

Please test & inform -h of any errors here....

-Nic

[rui]

Nic, you are faster than a speeding bullet :D

[Koepi]

Very nice :)

Now I'm a little bit in trouble:
should I once more adopt my changes to the new CVS version or stick with the old binary?
Damn, a real changelog would be so useful :rolleyes:

Since my binaries work well so far, I guess I wait until Isibaar introduces the new API?

Best regards,
Koepi

[-h]

should I once more adopt my changes to the new CVS version or stick with the old binary?

Hrm. The quant_type modulation is still useful, but I don't know Isibaar's plans yet. I have to contact him about API support for interlacing too.

There's a kind of changelog in the CVS comments, I listed everything I changed for once! Felt weird.

-h

[-h]

Well, since no one's machine has burst into flames yet (then again, how would I know if it had?), I'm off to bed.

-h

[Koepi]

Sleep well, g'night -h!

If there don't show up any error messages until tomorrow I could adopt my changes (quant_type modulation,...) to the new CVS.

Best regards,
Koepi

[rui]

I am doing a VERY small test, using again an AVI file as source file.
Again, i have some doubts that this is a valid test, so...
But here goes: the avi file is 10230 KB size, i choosed a final size of 3000 KB, and the codec gave me a file of 3032 KB. I used H.263, motion search precision 5, no lumi masking, no credits, and I-frame lock 2-6, with the smooth quantizer fluctuation enabled.

Then i did the same test using the same setings, but with no I-frame locking.
The final file size was 3024 KB. But Koepi once said that with the small size that we are dealing here, I-frame lock could create a little oversized final file

Regarding the quality, both files weren't good, because the source file was an avi already compressed (this is all i have to work right now, when in home i can make better tests).

Well, there you have it, i din't encounter any problems with this new build. For all this test is worth...

[Koepi]

once again thanks a million rui for testing so constantly :)

Warm regards,
Koepi

[rui]

I am just finishing a 1 cd rip from Independence Day.
i am still using Koepi's latest build, because i really like the modulated quantizer option.
I am doing 1 cd rip, because Gnot comp check says to me that by using a 512x... resolution i could try to put the all movie in 1 cd (i got 42%). Since my last 1 cd rip of "The Replacements" which didn't go so well, i am still trying to test XviD in 1 cd rips.

[Koepi]

Heh :)
Since I'm only doing 1CD rips as well, most of the options I introduced are most useful for such "low bitrate conditions"...

Works very, very well for me up to now. Too bad that the DivX4 DS filter sucks this big time, the movies still look better with the XviD one! :)

Just finished "the emperors new groove" and had the first high bitrate situation in my life. Tweaked around a little... but at least 1 scene is asynch. The Intraframe starting that scene is too huge... ;) I need a faster compi .
But the quality... yumm yumm! Such a glitch caused by my compi doesn't disturb me at all!
...
well, i don't want to write a biography here, so..

best regards,
Koepi

[rui]

I just finished my Independence Day 1 cd rip.
The quality, taking in consideration that the movie has 2H33m, is very good.
Much better than the movie "The Replacements" 1 cd rip. That goes with my idea that "The Replacements" just can't be done in 1 cd.
I used for 1 pass H.263, motion search 5, no lumi of course, end credits enabled. For 2 pass i enabled modulated quantization, I-frame lock 2-6 with smooth quantizer fluctuation enabled. Still no lumi (i think i will never use it again).
I targeted a final size of 572564 and got 576110. This is the biggest difference i ever encountered with XviD. Maybe is the movie, or my I-frame lock parameters weren't the best.
But when joining with the audio, i couldn't reach the 700MB.
The value i pointed to the codec (572564) was given to me by Gnot (beware that i didn't use the external 2 pass, i only used Gnot to have some value to point to the codec). I configured it by indicating the final size of the audio, then choose to calculate the interleaving & AVI overhead (1 vbr-mp3), but, in spite of getting a final video filesize bigger than expected i still didn't reach the 700MB when muxed with the audio.
Maybe something in Gnot calculations weren't right?

I want to apologize to -h, because this thread was supposed to be testing his new build, but instead i am posting results of Koepi's build :rolleyes::D

P.S. I still didn't encounter any problems with the colour, in spite of using the Div4 post processing. But i didn't saw the all movie yet, so i could still have some errors that i still haven't spotted

[wing1]

Well, I ran -h's & nic's new CVS build, and I've not seen any problem. Capture went perfect ( is it a little faster? or is it just my imagination? ). Encode also went perfect and no halucination issue either :) This is getting better and better with each build.

[-h]

Capture went perfect ( is it a little faster? or is it just my imagination? ).

Were you capturing in quality mode? If so, there was a bug in the pre-18th feb builds whereby it would always use lower quantizers, thus increasing file size and slowing itself down (due to more bitstream functions being called).

The interlacing code is "done", I just have to see if the guys like the changes I made to core.

-h

[rui]

Okay, i did a quick test with the -h and Nic latest build, using a riped chapter from a PAL movie "The Haunting", and coudn't find any problems. The final size was off only 10KB (oversized), it was only a small chpater but i don't think this represents any problems.
My settings were, as usual, first pass motion precision search 5, H.263. For the 2 pass, i choosed no lumi, and I-frame lock 2-5 with the smooth quantizer fluctuation enabled.
The quality was very good, in spite that my average video bitrate was only 600Kb.
So, i agree with wing1 words.
I believe that it's time for Koepi to step in and include his modulated quantization method :)

P.S. I am noticing that with the latest builds, i am getting the video file a little oversized. This could be because with the latest builds i am allways using the I-frame lock quantizer. In this specific test i made, it could be atributed to the small files size, but i already did some tests in full movies, and allways got a oversized files. I am using the 2-5 I-frame lock after reading a post by -h indicating this values for a 1 cd rip, and 2-3 for a 2 cd rip.

[Koepi]

Oversize up to a few 100kb is absolutely possible and natural when using iframe quant lock+quantizer smoothing.

(let's say, about 200kb oversized is well in range).

Or is it MBs we're talking about?

Regards,
Koepi

[Ripe73]

@Koepi
Do you use XviD DSfilter and if you do how do you change the brightness?
I really want to use the XviD DSfilter but its to dark, when i use Divx4 DSfilter i use brightness 58.
I have tried to change the brigtness in the Nvidia but it dont change the brightness in Mplayer2.
BTW now i get the exactly filesize,i encoded Dungeons & Dragons 108min on 1cd and did a Oggcontainer with subbs and the quality was very good(Koepis latest).

Koepi i use your statsreader will it show correct on a XviDstasfile?

Thanks

[Koepi]

The statsreader is somewhat flawed since I read the luma values in a wrong way (incompaitble data types in delphi and c++....)
But for the rest it is accurate.
I use it for determing the compression ratio (first pass filesize as shown in stats reader (and now by debug output as well ;) ) against the desired size...)

I can't change the brightness either and I'm still investigating how to add such support to the DShow project. since the class wizard isn't involved it's very hard for me to insert anything there :-(

-h must step in here again ;)

Regards,
Koepi

[Nic]

I was thinking of looking at adding brightness code to the DShow filter, it shouldn't be tooooo tricky (famous last words) :)

If no one does it by the weekend then I will give it a real try....Did -h ever get anywhere with adding postprocessing support??

-Nic

[-h]

-h must step in here again ;)

He must? ;)

I'd say Nic's your man, dshow is all voodoo to me at the moment. I can honestly say I have no idea how such a brightness control should work (overlay tweaking? internal brightness filter? SendMessage(WORKNOWDAMNIT)? )

And this interlacing stuff is fun to debug.

-h

[Nic]

Hmmm....

....I was hoping it would be simply a DShow edit, however to do it write would be to do it from inside the m_xvid_decore call...
Really I need to grab the frame in YUY2 & apply a luminance filter (probably....not the best way but it'd work :)

Although, there might be a nice easy DShow way of doing this, so ill look into it (It should be that easy.....Maybe Blacksun would know?)

-Nic

[Koepi]

-h, You MUST! ;)

Well, I would fiddle with the code, but therefore I need a control with a simple slider and a static showing the actual value.
Since I'm no windows GUI _hacker_ (I just do MFC stuff on win usually. doing linux kernel stuff is much more straight foreward and more my domain.) I can't figure out to control those things elegantly (inserting an edit box is one thing, but I didn't get the slider and the updated static controlled. and the problem, how to bind in such a property page correctly(i think i did that correctly already...) and _call_ it at all (didn't solve this one at all and went back to VfW modifications).... ;) )

So, since I don't have values to play with, I couldn't look deeper into the main thing,m how to control the brightness - which should be something like a one-liner since directX surface hasn't too many parameters ;)

Maybe I should just try google ;)

Regards,
Koepi

[Koepi]

Ah, good, ok, Nic, maybe you should do it :)

Since you are more experienced with those things it's better since I would do some major damage first before get it to run ;)

Regards,
Koepi

[rui]

Originally posted by Koepi
Oversize up to a few 100kb is absolutely possible and natural when using iframe quant lock+quantizer smoothing.

(let's say, about 200kb oversized is well in range).

Or is it MBs we're talking about?

Regards,
Koepi

Well, in my Independence Day test, i got an oversized file of 3546 KB.
This gives about 3,46 MB, right?
But, for full movie tests, this is the only one that gave such an oversized file, so maybe it is the movie. I must take in consideration that the movie had 2H33m and it was a 1 cd rip.
Hope you guys can creat the post processing soon ;)

[Koepi]

Maybe -h impemented the avi-frame overhead for first pass, while i did it for second pass, so if you mix a stats file generated by my code -h's code(CVS) would produce an oversized file.
OR did you use GKnot to create a stats file?

Well, dunno, it works so perfect for me, I can't imagine whats wrong there... If you use qunatizer lock main 2-6 and iframe quant lock 2-3 for example it could well be that the movie ends up overusing bits....

*shrug*

Sorry for not being really helpful here now,

Regards,
Koepi

[-h]

Maybe -h impemented the avi-frame overhead for first pass, while i did it for second pass, so if you mix a stats file generated by my code -h's code(CVS) would produce an oversized file.

Nope, I put the -24 in the same place you did.

@Nic - I haven't looked at post-processing at all yet.

If you guys can figure out how to edit brightness/etc. in dshow, I can whip up the gui. It'll just be a copy/paste from vfw really.

-h

[Nic]

The GUI would be easy, I make a point of not using MFC at all times if I can help it :)

Dont think there is an easy DShow way of setting the brightness (Doh!) Ill keep searching for info though :)

Cheers,
-Nic

ps
Looking through the decoder code the internal format is YUV (rather than YUY2), So now ive gotta work out how to add brightness to it quickly...hmmm :)

[sierrafoxtrot]

@-h

hi! the CVS 18/2 build gave me an undersized rip (off by about 70MB!!)final size: 604950, H263, no lumi, no Iframe lock. i'm sure i've done something obviously stupid, so i'm re-encoding it now, prolly set lumi on for both passes or something. i'll report back once i get a fix on what really happened. BTW, the quant credits option is great!

you guys are doing fantastic work, just thought i'd say.

best wishes.

[-h]

hi! the CVS 18/2 build gave me an undersized rip (off by about 70MB!!)final size: 604950, H263, no lumi, no Iframe lock. i'm sure i've done something obviously stupid, so i'm re-encoding it now, prolly set lumi on for both passes or something. i'll report back once i get a fix on what really happened. BTW, the quant credits option is great!

Sounds like a bug to me.

What options were you using? Start/end credits? Credits quantizer mode?

-h

[rui]

Originally posted by Koepi
Maybe -h impemented the avi-frame overhead for first pass, while i did it for second pass, so if you mix a stats file generated by my code -h's code(CVS) would produce an oversized file.
OR did you use GKnot to create a stats file?

Well, dunno, it works so perfect for me, I can't imagine whats wrong there... If you use qunatizer lock main 2-6 and iframe quant lock 2-3 for example it could well be that the movie ends up overusing bits....

*shrug*

Sorry for not being really helpful here now,

Regards,
Koepi

No, i didn't use Nic's build for first pass and your for second pass. Both in the case of my small test using Nic's latest build, and the Independence Day test using your build, i made both passes using the same build (sounds confusing, hope you guys got what i mean :)
I never mess with the quantizer lock, only with the I-frame lock.
The quantizer is 1-31 as default, only the i-frame lock is 2-6.

[sierrafoxtrot]

@-h
i was only using ~ 5000 frames of end credits at const quant 20. haven't had time to properly check everything, but the quality was significantly different from koepi's previous build (from the few minutes i could spend doing a once over before going to work) so it wasn't like the quantizers were jumping all over the place. the codec just seemed to be encoding for a different target filesize.

i'll get more information and run several more passes tonight, when i get home.

cheers.

[Demone]

I'd like to report something strange(probably not a new for u all).
I encoded some movies with xvid and I must say that the image quality is very similar to 3.11 and blocky backgrounds r gone (finally).
BUT...it seems that not all frames r encoded at the same quality,
I mean, looking at it, some frames r more blurry and the effect is a lost of detail. I tried it with xvid decoder and not, and the result is the same, I tried to see if in divx4 and 3.11 there is the same problem, but with these codecs all is OK. I'd like u to try it and tell me cause its a shame that much of the codec power is lost this way.To explain better it seems that 80% of the frames r reproduced with a bicubic resize and 20% with a bilinear and these alternation give the sequence of frames a sense of pulsing.

[Koepi]

Sounds like you use quant_type modulation and 80% of your frames are <quantizer 4 and 20 >quantizer 4... ;)

The overall quality should be superior to divx3(sbc)/4, at least that's my experience.

Regards,
Koepi

[Demone]

If for modulation u mean the combobox with H.***, MPEG, or MODULATION; No I DIDNT use modulation...I'M SURE. But I think I'm not at 100% of quality...but I dont think this is the problem.

[wing1]

-h

I always use 1-Pass CBR mode whether I do capture or encode. I like quality mode, but the file size can be huge at times, whereas, 1-pass quality mode yields much manageable file size and quality when u use high bitrate + 1-5 min-max quantizer in H263 motion search. Definitely, the new build is slightly faster: I get 1 to 2 fps more then the previous.

[wing1]

Ok, play around with quality mode and found a setting that will yields good quality and manageable file size. will let it captures while i am away at work. Will see how that goes when i get home :)

[Koepi]

I started looking around a little for overlay brightness control and just found stuff like:

http://www.microsoft.com/directx/dxm/help/ds/filtsamp/C_C++_Samp_Apps.htm

Look out for the overlay mixer, it seems to have something like that, we just need to interface it.

I'm not too sure though and since my compi is as mostly under heavy use I can't look into the DShow sources now :-/

Stil, I hope this helps.

Regards,
Koepi

[Baalthazaar]

This is just a question about a possible feature for X-vid. If you've gone to the trouble of doing a first pass and gotten the stats file and everything, is there any way that you could use that data for OTHER encoding methods besides the 2-pass? For instance: do a 1st pass then use the info to predict the approximate filesize in 1-pass quality mode or 1-pass quantizer mode? I ask because in cases where I could hit 85-90% quality and still stay within my filesize I'd really rather use this option than the second pass (as I think it looks more consistent).

You guys have been doing great stuff lately and I thank you for all of it. Good luck in all your future coding!

[Koepi]

Ok, I've added a property page with a brightness slider. Now I just need to control that ;)

AND I have to find how to modify the brightness then.... *search*

Regards,
Koepi

[-h]

This is just a question about a possible feature for X-vid. If you've gone to the trouble of doing a first pass and gotten the stats file and everything, is there any way that you could use that data for OTHER encoding methods besides the 2-pass? For instance: do a 1st pass then use the info to predict the approximate filesize in 1-pass quality mode or 1-pass quantizer mode? I ask because in cases where I could hit 85-90% quality and still stay within my filesize I'd really rather use this option than the second pass (as I think it looks more consistent).

It'd be nice to try, but I don't think it's "possible" (as in, without spending months trying to perfect the algorithm).

-h

[Koepi]

Too bad, there seems to be nothing like directshow colour control or anything. I might try "overlay directshow colour control" as well but since now I've been searching for hours, finding nothing useful.

It seems, colour+brightness control has to be in the codec itself by something like shifting the palette or so (you can get the whole palette with some commands - maybe that'll do the trick?).

Maybe someone with some experience can help me here.

Regards,
Koepi

[sierrafoxtrot]

@-h

still getting undersized files. this time i'm trying another first pass with H263, no lumi masking, disabled credits (would it make a difference to the stats file if i do?) and no intraframe lock. 2nd pass would be credits at quant 20, no lumi masking, H263. we'll let you know how it turns out in the morning.

happy dreams.

[-h]

still getting undersized files. this time i'm trying another first pass with H263, no lumi masking, disabled credits (would it make a difference to the stats file if i do?) and no intraframe lock. 2nd pass would be credits at quant 20, no lumi masking, H263. we'll let you know how it turns out in the morning.

There is the problem. If you're using a quantizer for the credits, you must set that option in the 1st pass as well as the 2nd, otherwise the codec will not know how much space the quantized credits require.

The other credits options (rate, size) don't have to be set in the 1st pass.

-h

[sierrafoxtrot]

@-h

gotcha! just started another 1st pass. got my fingers crossed for this ...

thanks for the quick reply.

:)

[Doom9]

desired size: 642'000KB, achieved 2 pass size: 544'394k. Needless to say that I'm not quite satisfied. The build I'm refering to is nic's 02/12 compile... off to testing the latest compiles now.

[Synth]

Just for those who might find this useful. Zoom Player (my fav media player) can be set to use an overlay filter during playback so you can manually adjust the brightness, contrast, gamma, hue and saturation to your preferences.

@ koepi: Might wanna liason with the writers of this proggie to get help in your ventures.

just a random thought.

[-h]

desired size: 642'000KB, achieved 2 pass size: 544'394k. Needless to say that I'm not quite satisfied. The build I'm refering to is nic's 02/12 compile... off to testing the latest compiles now.

Hrm. Can't really say I've seen that before.

If you're using a constant quantizer for the credits, make sure you enable the credits start/end frame and quantizer options for the 1st pass as well as the 2nd.

-h

[sierrafoxtrot]

finally! got to within 150kb of desired filesize. thanks, -h, for that wee tip about setting credits quantizer/start frame during 1st pass. has anyone ever used very low bitrate credits (ie 5-10%) before? i tend to get very smeary artifacts whenever i use this in conjunction with lumi masking ...

cheers everyone

[rui]

I have been messing around with this latest build, and the final file size always is what i expected.
But i made a test using a trailer from "The Replacements" (again this movie :), this time messing with the inter frame quantizers (2-6).
The desired avi file was 10466 and i got 17470.
I guess my settings were much too agressive. Better to mess only with the intra frames quantizer in future. :)

[sierrafoxtrot]

@rui

recently i've just stopped trying to quantize interframes too much, i use a max of 5-6 if i'm using lumi masking and i'm aware there's lots of dark scenes in the movie. other than that i leave it be.

i think that makes sense. if you are too aggresive with interframe quants, there's no way the codec can compensate except by increasing compression on the intras, and that will not be enough to stop the output from being oversized.

*but* if you force really stringent intras, then the interframes get quantised more heavily, and you can still hit desired filesize, although with crappier overall quality (nice keyframes though :p )

and i guess if you go overboard trying to constrain both inter and intrafames, you'll end up with ... don't know, fun-sized avis?

heheh

just my 2p

[Teegedeck]

I agree that it might be wise to be careful with those restrictions. Very difficult to find good values. Has anyone yet made stringent comparisons with/without restricted quantizers?

[Doom9]

@-h: nothing funny going on here.. credits option is not used (the credits are rather short and with movie action going on in the bg), and the settings are the same as I used to encode movie 1 from the series (Chinese Ghost story). Motion search precision 6, quant H.263, lumi masking on during the 2nd pass. Funny thing is that encoding CGS1 using the same settings worked just fine. Maybe I should try another build and see what I get (I redid the first and 2nd pass yesterday, with the same undersized result).

[-h]

@Doom9 - if you're still getting undersized results with the latest builds (as in, undersized by more than a few hundred KB), I'd really like to look into it further. It'd definitely be a curve generation error.

-h

[sierrafoxtrot]

i was encoding this special edition of memento where it's shown back-to-front (ie the "right" way round) where they concatenate all the black and white vignettes to the beginning of the movie. so there's this wierd situation where the end credits are at the beginnning, followed by a 20-minute bit of black and white video and then the rest of the movie. the results i got were less than satisfying, the black and white bits were really blocky and just plain annoying (watching VDubs status window showed the bitrate falling to about 300-400 kbits/s), but the rest of the movie was perfect.

i managed to get the quality up a bit by setting interframe quants at min2 max5, intraframe lock at min2 max3 with quantizer smoothing enabled (H263 and Modulated, motion search 6, no luma masking), but then it got a bit oversized.

in the end i had to use Gknot to manually scale different sections of the movie to get a reasonable rip. i think i used koepi's 16/2 build.

anyway, i was wondering if it was possible to use the credits sectioning capability at 110% as a "sort of" section-specific scaling similar to GKnot or divx4log. that way it would be able to dedicate higher bitrate for sections where the codec seems to make bad decisions. just a thought.

anyway, (just re-read your post), no i haven't done stringent tests, but changing the interframe quants can make a visual difference, but from this particular movie, by the time the blocky bits cleared, the quants were so constrained i was getting oversized files. i'm sure ideal values must be different for each movie, and that dark, or really action-rich movies may benefit slightly. but then again, i haven't devoted that much time to sort that out.

sorry. :(

hope this helps.

[-h]

i was encoding this special edition of memento where it's shown back-to-front (ie the "right" way round) where they concatenate all the black and white vignettes to the beginning of the movie. so there's this wierd situation where the end credits are at the beginnning, followed by a 20-minute bit of black and white video and then the rest of the movie. the results i got were less than satisfying, the black and white bits were really blocky and just plain annoying (watching VDubs status window showed the bitrate falling to about 300-400 kbits/s), but the rest of the movie was perfect.

Hrm that's odd, I would've thought it'd handle that ok. Ah well. You can get around this (if you really need to use the internal 2-pass mode) by setting that section as "credits", and forcing either a lower quantizer (3 or 4), or higher rate (150%, whatever). Well I haven't tested that, but I assume it'd work ;)

-h

[sierrafoxtrot]

@-h

yeah. i thought it was odd too, because the normal version of memento encoded *perfect*, which begs the question, is the order of the content important?

i haven't tried it either. it was just one of those brainwaves that occur waaaay after it ceases to be useful. maybe the next time i run into a movie i have problems with ...

:p

[rui]

Originally posted by -h
[i]
Hrm that's odd, I would've thought it'd handle that ok. Ah well. You can get around this (if you really need to use the internal 2-pass mode ...
-h

Humm.. This words made me wonder...

I always use the internal 2 pass mode. Why shouldn't i use it?
Does the 2 pass mode using Gnot to calculate the curve, any improvements that i'm not aware?

[sierrafoxtrot]

@rui

well, i've been told that if you're only using Gknot to calculate the curve from the stats file, then the internal 2-pass is exactly the same. but if there's scenes where you want better (or less) quality, you can use Gknot to set selections where the bitrate curve is calculated manually. then you use that stats file in 2-pass external. it's just something to do when you're bored :p or when you've got a movie with difficult scenes :mad:

anyway ...

hope this helps

[Ripe73]

HI,i have question about the main quantizer will it have an influence on the endcredts too.
etc
if i use min q:1 max:8 and the endcredits need quantizer 12 to keep the final size,will the codec use my max:8 and the movie will be oversized or will it not care and use whatever is necessary to keep the finalsize?
I'm glad for a quick reply because im going to test with I-frame min:2 max:5 and main min:1 and max:9 over the night for 1 cd:)

Thanks

[-h]

HI,i have question about the main quantizer will it have an influence on the endcredts too.

The quantizer you set for the credits completely overrides the 'min/max quantizer' fields.

-h

[rui]

Sierrafoxtrot, thanks for the enlighten :)

[-h]

Found the bug - it's in the bit bucket decision of whether to say (bytes2 += overflow) or (bytes2 += bytes2/2). I'm not sure why suxen_drol coded it that way, but I'll replace it with something a bit angrier, that'll make the difference between actual and desired bridge faster.

Should be committed in 4 or 5 hours, I'm at work atm.

-h