B-Frames and XviD statsfile error in GK

[kaitsuburi]

I tried searching for this, but I couldn't find anything. I am dead scared of posting in the XviD forum, so I decided to post here :confused:

Trying to perform a compressibility check, I have two identical .avs scripts with SelectRangeEvery(280,14) at the end and identical XviD setup (using koepi's 05042003 build) for 1st Pass (h263, chroma, qpel, vhq 1, all else default) except for the B-frames setting in my second attempt (3,150,100,0). When I load the .stats file generated after 1st Pass in XviD, in the case without B-frames Gknot produces the compressibility numbers as usual; in the case with B-frames it gives this error: "Floating point division by zero."

Has anyone experienced this problem? Why might this be happening?

TIA,

-kaitsuburi

ps. I've just tried with Gknot 0.28 alpha 10 but the problem persists.

[zulu]

Has anyone experienced this problem? Why might this be happening?

http://forum.doom9.org/showthread.php?s=&threadid=46874&highlight=knot+division+by+zero

[manono]

Hi-

I am dead scared of posting in the XviD forum

Gee, I wonder why that is. ;) You are correct, with B-Frames enabled, you can't get results in the Compress Test by doing the usual Load. However, you can get inaccurate results by opening the stats file in the Nandub Files Tab. They're inaccurate because, unlike the usual way of doing it which takes into account the fact that a keyframe is set every 14 frames (by deleting those frames), opening it in the Nandub Files Tab doesn't take that into account. As a result, the percentage is lower than it should be. But I don't know how much lower it is. According to johnny's manual method of getting compress test results when using DivX 5.03, found Here (http://forum.doom9.org/showthread.php?s=&threadid=44414), when using B-Frames in DivX 5.03, it's around 10-15% lower. Maybe the XviD results are similar.
So at the moment, with B-Frames enabled with XviD, there is no way to get an accurate compress test result. But that will change any day now, as jonny will release his Enc. for XviD very soon. Stay tuned.

Edit: zulu beat me to it. But as I said, I don't believe those results to be accurate.

[len0x]

Originally posted by kaitsuburi
I tried searching for this, but I couldn't find anything. I am dead scared of posting in the XviD forum, so I decided to post here :confused:


wrong again :)
GK development is the forum if you're using alpha versions...

Originally posted by kaitsuburi

Trying to perform a compressibility check, I have two identical .avs scripts with SelectRangeEvery(280,14) at the end and identical XviD setup (using koepi's 05042003 build) for 1st Pass (h263, chroma, qpel, vhq 1, all else default) except for the B-frames setting in my second attempt (3,150,100,0). When I load the .stats file generated after 1st Pass in XviD, in the case without B-frames Gknot produces the compressibility numbers as usual; in the case with B-frames it gives this error: "Floating point division by zero."

Has anyone experienced this problem? Why might this be happening?
ps. I've just tried with Gknot 0.28 alpha 10 but the problem persists.

GK didn't support XVID before 0.28, and starting with 0.28 alpha 9 it supports it but _does not_ work with stats file from XVID. In fact the only stats file GK will ever work with will be DIVX3(Nandub). We are now using statistics generated from VirtualDubMode (/log option), not codecs statistics...

[hakko504]

Originally posted by len0x
GK development is the forum if you're using alpha versions... Thread moved.

[Acaila]

GK didn't support XVID before 0.28, and starting with 0.28 alpha 9 it supports it but _does not_ work with stats file from XVID.Why did you remove XviD stats file support for the beta versions? The old GKnot versions (<0.28) DID work correctly with the stats file, I always use it to check the compressibility of my 1st pass. If you keep DivX 3 stats compatibility around, why not keep XviD stats compatibility as well?

Ps.
XviD uses DivX 3's method of calculating bitrate, i.e. 1 kbit = 1024 bits. DivX 5 uses 1 kbit = 1000 bits. Right now you have XviD using DivX 5's method.

[len0x]

Originally posted by Acaila
Why did you remove XviD stats file support for the beta versions? The old GKnot versions (<0.28) DID work correctly with the stats file, I always use it to check the compressibility of my 1st pass. If you keep DivX 3 stats compatibility around, why not keep XviD stats compatibility as well?


I actually didn't touch that part :)
I just didn't know GK supports them...

Originally posted by Acaila

Ps.
XviD uses DivX 3's method of calculating bitrate, i.e. 1 kbit = 1024 bits. DivX 5 uses 1 kbit = 1000 bits. Right now you have XviD using DivX 5's method.

Wow, I got exactly the opposite information from Doom9 about it - he said xvid is the same as divx5...

[manono]

Hi-

but _does not_ work with stats file from XVID.

As the original poster stated, it works fine with XviD stats files as long as B-Frames aren't enabled (the pre-0.28 versions anyway). I had been getting compress test results, and sometimes modifying the stats file, for months before I started using B-Frames.

[Acaila]

Originally posted by len0x
I actually didn't touch that part
I just didn't know GK supports them...Well, it did support them up until beta 8 or 9 or so, but it doesn't work on 10 anymore.
To be more specific. To load an XviD stats file you first have to click on DivX 3, otherwise it gives an "unable to find log" error. Is there any way to have both the stats and logfile ways work for XviD?

Originally posted by len0x
Wow, I got exactly the opposite information from Doom9 about it - he said xvid is the same as divx5...Hmm, that's strange, I could've sworn... But either way it's irrelevant, because XviD only uses target filesize anyway, not the bitrate :).

[len0x]

Originally posted by Acaila
Well, it did support them up until beta 8 or 9 or so, but it doesn't work on 10 anymore.
To be more specific. To load an XviD stats file you first have to click on DivX 3, otherwise it gives an "unable to find log" error. Is there any way to have both the stats and logfile ways work for XviD?


I'll have a look. I never checked that loading code before...
(I didn't explicitly change anything there)

Originally posted by Acaila

Hmm, that's strange, I could've sworn... But either way it's irrelevant, because XviD only uses target filesize anyway, not the bitrate :).

Yep, true :)

[len0x]

I see the solution (to be able to load stats files while in XVID mode).
Will be in the next alpha...

[Acaila]

Great :). Thanks.

[kaitsuburi]

@len0x:

Thanks for all your efforts! I am looking forward to trying out the new alpha.

@manono:

Thanks for your advice. I will give Nandub a try. I finished two encodes with b-frames last night so I will compare the actual compressibility percentages to the ones Nandub reports when I get home tonight and will post my results.

This is probably a moronic question, but given that identical avisynth scripts are used, could a GK compressibility test done in DivX 5.03 Pro serve as an approximate guide to compressibility with XviD? In other words, is the difference in compressibility between the two codecs (with a certain settings for each, encoding the same material) likely to exhibit some sort of constancy?

-kaitsuburi

[manono]

Hi-

Well, DivX 5.03 uses an H.263 matrix, whereas with XviD you can use H.263, MPEG or any one of a number of other Custom Matrices. In addition, depending on the B-Frame settings and the other stuff (VHQ, Q-PEL, GMC, etc.), the results of compress tests may be more or less comparable.

But it's all academic now anyway. Jonny's Enc., which allows you to do compress tests using just about any codec, is out now. For more information, please see This Thread (http://forum.doom9.org/showthread.php?s=&threadid=50714).

[dwrbudr]

I also think XVid uses 1K = 1024
and thats wrong implemented in gknot 0.28.

I encoded the very first VOB from LOTR 1 Extended version DVD1/4
with DivX 5 and with XVID (only video in both)
and wanted file size was 110MB.
In DivX 5.02 (pro corp) the produced file size was 110MB
In XVid (koepi 03/22/2003) = 108MB

[len0x]

Originally posted by dwrbudr
I also think XVid uses 1K = 1024
and thats wrong implemented in gknot 0.28.


Nothing regarding bitrate is implemeted regading XviD at all...
So it cannot be wrong :)

Size problem exists, but it's not a bitrate problem...

Can you try only video and no audio and see if the size will be correct or not?

[dwrbudr]

As I mentioned above this was *only* video test (no audio at all)
Maybe this is a Xvid problem :)