Latest Gknot with Xvid 1.0 stats files

[Zerox20]

I know I feel very very stupid for even posting this, but I have been doing some searches after I upgraded to the new Gknot to the latest version, because my Xvid 1.0 stats file would not load in the old version for my First pass /video Size box. I am just wondering where I do this in the new versiont to get the % value in that box again. I am probably just missing it, or looking over something very obvious. I have always liked gknot and its breakdown of stats over the xvid stats reader and because of the % compressability rating it gives for the first pass video size. Any help would be grateful!

[Tuning]

Hi Zerox20,

Its normal, what you getting of with GK. The reason is GKnot is not currently supporting XviD 1.0b. len0x has already mentioned that, as XviD become stable, he will implement its support. For time being we have to use old XviD. This is because, with new XviD registry settings and stats file have changed. Wait until a stable build is released.

[Zerox20]

I figured as much I was more or less confirming, Just Koepi's stats reader is nice but doesn't give as detailed. Are there any alternatives?

[kxy]

DVX support latest xvid beta

http://www.planetdvb.net/

[Zerox20]

That will read in my first pass stats file? I am having trouble finding where it does this at. I see where it does m2v etc.

[bond]

XviD 1.0b1 is not ready for regular encoding!

[Angelus]

I was able to use Xvid 1.0 on a section of a capture I did of 24 from last Tuesday night. Everything turned out fine, even though I'm not that well informed about all the settings in Xvid.

[len0x]

I'm not planning to support those even when XviD gets stable.
Stats files are not used internally by GK (for comp test for instance). So I see no real reasons for it.

Note: ability to read xvid stats file came from divx3.11 support. I never written any stats logs parsers for xvid and have very little desire to do so...

[gurabli]

XviD 1.0b1 is not ready for regular encoding!

I think it is a stupid question, but what about the new beta 2?

Gurabli

[Zerox20]

Right but GK was the best ever for that compressability test XD, please make it work again! for us!! ^_^

[len0x]

Originally posted by Zerox20
Right but GK was the best ever for that compressability test XD, please make it work again! for us!! ^_^

do not confuse compressibility test with stats loading. Compressibility test will always work OK, but I can almost promise you that you will not be able to load raw stats from new XviD. (unless someone else writes parser, coz I won't do it)

[Zerox20]

::looks around:: anyone? anyone?

[LigH]

If you want to do a CompCheck with XviD 1.0 / dev4api, set it up to "Twopass, 1st pass", and disable the option "Discard 1st pass": Because the frame sizes are written from the finished AVI file into a file called "VDENC.LOG", it would contain "0 bytes size" statistics on each frame if you discarded the output to drop frames (as it is usual for regular first passes to save hard disk space) -- GKnot 0.28.x is obviously unable to properly calculate the bitrate distribution based on "0 bytes size for each frame".

[len0x]

Originally posted by LigH
If you want to do a CompCheck with XviD 1.0 / dev4api, set it up to "Twopass, 1st pass", and disable the option "Discard 1st pass"

why, there is no more single pass quality-based encoding in 1.0 ???

P.S. /nowrite option of VDubMod was supposed to solve the issue, but it seem not working in latest vdubmod...

[LigH]

It is possible that there are better ways of reaching a useable result for the CompCheck which I do not yet know -- so if you have another idea, please tell me: Many users in the german doom9/Gleitz forum miss a solution.

At least I'm quite sure that a 1st-pass always uses quantizer 2 for I and P frames (and a QF according to the B-frames offsets, usually around 4, for B frames), so this was the best approach for me currently. But any better ideas are welcome (please also in the XviD forum here...).

[len0x]

I thought everybody uses 100% quality 1 pass for comp test, no ?

[LigH]

Some users even don't understand how the "Compresssibility check" shall work - they just complain that it doesn't work for them.

I'll try both ways and compare if they bring any remarkable difference. Theoretically, both "1st of 2 passes" and "1 pass at 100%" shall clamp the I/P quantizers at value 2.

It's just so: With DivX 5.0.2, it didn't matter because GordianKnot up to 0.27 seemed to read the DivX log files, and the log files contained the frame sizes of the 1st pass even if the AVI just contained drop frames. Now since 0.28, the AVI must contain true frames that GordianKnot can measure the size of each frame.

That's the difference: GK up to 0.27 was able to request the sizes which would have been written from the log or stats files; GK since 0.28 reads the sizes which had been written into the AVI file. And many users who still believe in the GK 0.27 guides don't know about that difference, set up XviD to "1st pass (+ discard)", get an AVI full of drop frames, and the CompCheck reports nonsense.

Some people just switch their brains off as soon as they have a guide to ignore (if they just would read them... but often they only want to follow them without thinking).

[jggimi]

But DivX 5.05, 100% = Quant 1, and 98% = Quant 2. That can certainly throw off results, if 100% were used rather than Q=2.

[len0x]

Originally posted by jggimi
But DivX 5.05, 100% = Quant 1, and 98% = Quant 2. That can certainly throw off results, if 100% were used rather than Q=2.

I don't believe that's true. I recall some test I've done a while ago:
with quant=1 I was getting almost twice size as with quant=2

anyway it doesn't matter for xvid where 100% = quant 2 for sure.

[jggimi]

@len0x,

It may be academic if for all codecs the compression test is set to a constant quantizer, and all codecs are treated the same (eg: Q=2). But if using a "percentage" value rather than a quantizer, those values no longer map to the same quantizers after 5.04.

[LigH]

In my humble opinion... I would rather try my best to ensure as similar circumstances as possible. That means to me "constant quantizer" for compressibility check. If a codec provides a mode which ensures CQ, I would prefer that mode over any other (like quality percentage).