My XVid binaries

[MaTTeR]

Originally posted by Synth
Just a random idea...check the "About" section in the codec..check if the date is the 16th.

Thanks for the changer link man. I just tried a 2nd ps without Lumi and still got the colored block bug. However, it appears the artifact doesn't happen as much as when I was using Lumi. The plot thickens...

Oddly enough the about box is showing the 16th of Feb. What's this? I know I downloaded and installed these from Koepi's site today. Downloaded the file again just now and it's named "XviD-16022002-1.zip" and sure enough the about box is showing the 16th:confused:

I have some screenshots if anyone is interested in me emailing them or uploading them somewhere.

[Nic]

The date is controlled by the date that codec.c was last changed, this is controlled by __TIMESTAMP__ if I remember correctly.....

I suggested using __TIME__ or similar instead which would show the last compililation date........

-Nic

[Teegedeck]

@MaTTer: To verify what decoder you're using, check out the 'properties' of your movie while watching it. In WMP, you'll find the properties in the 'file' menue (look for the XviD DSF among the 'filters'), in BSPlayer you'll see the XviD-DSF immediately if you right-click in the picture and select 'properties', for example. Hope this helps

[Teegedeck]

@-h, Koepi: The credits features are very nice, by now - congratulations to you guys! I guess the functionality can't get much better. Maybe time for some GUI-improvements?

I got some idea to annoy you, want to hear it? :devil:
Personally, I'm looking forward to the return of a 'fixed quantizers'-encoding mode for the credits, but I'd like it even more if I coud set a _filesize_ for the credits. I know I could calculate that myself, but I never liked these %-thingies. Just not very intuitive. BTW, you should have discussed all this in a 'credits'-thread - moderators these days... ;)

[-h]

I'm going to put fixed quantizer (easy) and credits file size (easier) back into the vfw tree. Seeing as we've got an arbitrary dialog to play with now, I may as well fill it up :)

I've actually spent the day looking through the MoMuSys code for hints on how to handle interlacing etc. Didn't get much accomplished, but it made me realise how much better XviD's source is than anything else out there.

-h

[Koepi]

Well, from my side you still don't get fixed quantizers or filesize for credits, just a few bugfixes/cosmetical changes:

- Interframe quantizer lock doesn't get applied on the credits
- Frames don't get scaled when the result is < 101 bytes. This doesn`'t change anything but debug output, since this still adds to ovrflow ;)

Fetch it as usual at

http://roeder.goe.net/~koepi/

Regards,
Koepi

[Ripe73]

HI!
Koepi's XviD-17022002-1
161787 frames
2pass Int.
M.Search 5
H:263
I-frame Min:2Max:6
Smooth.Quant
No L.Masking
Endcredit function

Well,the movie was 3mb undersized with these settings.
Just want to report;)

EDIT
Someone know why the movie is undersized,first time under/oversized with XviD

[Foxer]

First of all XVID is turning out to be a 'great' codec to use :)

Though it doesn't handle extremely low quality encoding as well as divx4(very blocky in one area while ok in another), starting from about 35-40% quality(desired filesize / quant2 filesize), it just 'stomps' it :)

The features are coming along nicely though there are a few I'd love to see implemented and that's specifiable I-Frame spacing, I-Frame threshold and 'possibly' even forced I-Frame threshold.

Also, I've noticed that XVID tends to use too low quantizers for I-Frames usually resulting in keyframes which are ~30% larger than what they were to be scaled to though I've seen them reach almost 2x what they were to be scaled to.. Even when it's overflow is very large ( < -50k) from many consequtive I-Frames it still doesn't raise the quantizer. So, to remedy this, I must manually set the min IF quantizer to correspond with the desired quality and any adjustments I've done in GKnot. The only problem with this is that the keyframe quantizer is larger than it needs to be in some parts of the movie which make it look a little worse than it would've been.

Other than these problems, I see absolutely no reason to not use this codec and hope that this speedy development continues on thru B-Frame implementation :)

Shoot.. I'd even filter to huffyuv and then encode using a specialized little program & XVID lol

[rui]

I have to agree with Foxer here.
I just made some experiments with XviD and a very hard movie "The Replacements" http://forum.doom9.org/showthread.php?s=&postid=85629#post85629 and I too believe that with much too low bitrates, divx4 could be a little better.
But for the rest XviD all the way :)

[Koepi]

As I wrote in the above mentioned thread, try again please with luma masking disabled. It raises the quantizers on very dark scenes and may result in "shit" (nandub terms ;) ).

Btw., thanks for all your testing!

Best regards,
Koepi

[rui]

ok, boss. :D

[Ripe73]

@Koepi
Do you think a statsfile with XviD-16022002-1(Koepi) and the second pass with XviD-17022002-1 cause undersized on two of my movies with 3mb?

Thanks

EDIT:I used Fast Deinterlace too never used it on the other movies with XviD

[Synth]

Speaking of stats file...can I use a nandub generated stats file as the second pass with xvid?

[Koepi]

Originally posted by DarkLord73
@Koepi
Do you think a statsfile with XviD-16022002-1(Koepi) and the second pass with XviD-17022002-1 cause undersized on two of my movies with 3mb?

Thanks

Could be - if you accidently choose luma masking for the first pass this could be the case.

Regards,
Koepi

[Koepi]

Originally posted by Synth
Speaking of stats file...can I use a nandub generated stats file as the second pass with xvid?

Definatly NO. Since XviD compresses the frames to another size as DivX3... it's not comparable, it's rule no.1 of (not only anymore ;) ) nandub that takes command here:
If you change something changing the picture quality/compressability, redo the first pass.

Regards,
Koepi

[Ripe73]

HI!

Well,i did a 2 pass encoding again with XviD-17022002-1(Koepi) and this time with statsfile from the same build and final size was 1429782kb=1396,271mb ,aiming for 1400mb and i use GKnot to calculate and set bitrate from the videosizebox in kb.
Other Gknotsettings used
Calculate Frame-Overhead(enabled)
AC3 (2 frames)
Calculate Average Bitrate(enabled)
Divx3(enabled)
I also used Smart.Deinterlaced(not on my previous XviDmovies)

Is it somethingwrong with this settings?
4mb undersize is not so big problem but it seems like rest of you got the exactly filesize.

I will try to do a second pass with the 16-02 build and see what happens.:)

EDIT:i'm sure i did not use L.Masking

[Koepi]

Ah, now there's light...
You use GKnot to modify your stats file.

Why do you blame us for any error?
In external 2 pass mode the codec gets controlled by the modified stats file.

So it's YOUR fault that you use GKnot and THEREFORE get those troubles.
(Sometimes it's really obvious that I hate that proggi, isn't it? ;) )

Use internal 2pass and be prepared to hit the limit within a few kb.

Regards,
Koepi

[Koepi]

Ah, you can still use GKnot.

I just read your edit:
DON'T USE CALCULATE FRAME OVERHEAD:

XviD takes care of this. This are exactly those 4 MB to less yu're talking about.

[Ripe73]

HI Koepi!!

No i just calculate the bitrate not the statsfile:)
I use the intern statscurve

ohh i now i read your edit ppl are really fast here:D
that was stupid off me but i have that checked(calculate Frame-Overhead) on my previus encodings too and they were exactly in size.

[Koepi]

That was correct for my builds until... 16.2. or so, read the releasenotes - I introduced to take care of it by the VfW interface :)
Dunno when -h commits this to CVS or if it's already commited...

Regards,
Koepi

[Ripe73]

Thank you!!!
I try to read all the readmefiles but sometimes idont understand all the "encodingwords" but know i feel like a better man;)

[Ripe73]

@Kopei

I have one question about the I-frames(keyframes)sometimes i have lots of keyframe in a row is that normal?

example from the debugview

[2516] [XviD-2nd] Quant:4 .h263 Inter Stats1:329 ScaledTo:227 Actual:104 Overflow:-167
[2516] [XviD-2nd] Quant:2 .h263 INTRA Stats1:2994 ScaledTo:2074 Actual:2994 Overflow:-1111
[2516] [XviD-2nd] Quant:2 .h263 INTRA Stats1:3777 ScaledTo:2617 Actual:3777 Overflow:-2295
[2516] [XviD-2nd] Quant:2 .h263 INTRA Stats1:4198 ScaledTo:2908 Actual:4198 Overflow:-3609
[2516] [XviD-2nd] Quant:3 .h263 Inter Stats1:5712 ScaledTo:3957 Actual:3975 Overflow:-3651

Three keyframes in a row and i can see this (K) in V-dub too.
Its with your lates build
thanks

[Ripe73]

HI!
Can someone please explain my above reply i need to understand.I need the keyframes in a scenechange or around every 10sec,right?

thanks

[Foxer]

ATM, XVID doesn't have intra frame spacing and inserts intra frames whenever half of the image has changed.

I have implemented intra frame spacing, hardcoded to only allow 1 every 24 frames(I'm not that great with GUIs heh), proportional bitrate redistribution (greatly aids quantizer choice accuracy to maintain desired quality) and put in a form of curve compression.

You can message me with your e-mail if you want my DLL.
It's based off of the 17th's CVS + Koepi's mods.

[-h]

I have implemented intra frame spacing, hardcoded to only allow 1 every 24 frames

Just wondering, what is the gain in doing this? You'd probably get better results from just raising INTER_BIAS to 0.6 or 0.7.

proportional bitrate redistribution (greatly aids quantizer choice accuracy to maintain desired quality) and put in a form of curve compression.

What's the proportional redist. do?

-h

[Foxer]

Intra frame spacing can help with compressibility in some cases. Like helping to not put a slew of intra frames in quick succession in flashy scenes where not all of the frame needs to be updated. And with intelligent intra frame spacing, possible mosquito noise caused by lack of an intra frame at a scene change doesn't linger but up to a second.

Proportional bitrate reditribution was a fancy name for scaling the overflow according to the target frame size in relation to the average frame size (overflow * bytes2 / AvgFramesize) heh

The above calc is done in double precision for best results.

With this, mid-sized frames aren't obliterated or grow too much by large overflows.

[-h]

Intra frame spacing can help with compressibility in some cases. Like helping to not put a slew of intra frames in quick succession in flashy scenes where not all of the frame needs to be updated. And with intelligent intra frame spacing, possible mosquito noise caused by lack of an intra frame at a scene change doesn't linger but up to a second.

Due to the current state of XviD's inter/intra macroblock decision, in such cases the I-frames are normally smaller than the P-frames forced into existence. Many anime action scenes exhibit this (I-frames smaller than surrounding P-frames).

Proportional bitrate reditribution was a fancy name for scaling the overflow according to the target frame size in relation to the average frame size (overflow * bytes2 / AvgFramesize) heh

I take it this is used in the quant decision code? I'm just not getting how it fits in with the overall picture :)

-h

[Foxer]

Due to the current state of XviD's inter/intra macroblock decision, in such cases the I-frames are normally smaller than the P-frames forced into existence. Many anime action scenes exhibit this (I-frames smaller than surrounding P-frames).

I have noticed this in normal video :)
The increase in bitrate consumption with this enabled with normal video seems to be marginal (about 0.1%).
Anyway.. I just put it in just in case heh

I take it this is used in the quant decision code? I'm just not getting how it fits in with the overall picture

It influences the quant decision code's result quite a bit.

The overflow variable being scaled as described before it's clamped onto the target frame size stabalizes it a great deal. Apply it and see :)

Calculate AvgFramesize using a double for best precision and then add this code right before the overflow's clamped onto the target frame size in codec.c

overflow = (int)((double)overflow * bytes2 / AvgFramesize);