DebugView analyzer for XviD Codec v0.11

[MoonWalker]

New version :

v0.11
Added the possibility of arguments to dbg.exe
Added to graph.txt display of the I-Frames and the number of consecutive I-Frames
Fixed the broken "prevention" of the steeply rising of the quantizers
Fixed another bug I can't remember :p

NOTE
Since v0.11 dbg can take arguments.So if you saved your file i.e logview.txt just type dbg logview.txt and enter :)
The old way still remains(I prefer it, cause you only have to do a double click :) ).If you save your file as dbg.log and put it together with dbg.exe, you can just execute(or double click) dbg.exe

As usuall you can get it following the link in my signature..

MoonWalker

[TheUnforgiven]

just downloaded it..
great work.

[Kyo]

thanks MoonWalker great work :)

really nice page :D

[MoonWalker]

Originally posted by Kyo
really nice page :D

Yes I know..I have put many hours of effort in this :D :D

MoonWalker

[Sigmatador]

thx good job :D :D

[Didée]

I posted a suggestion in the PerfectXvid thread: http://forum.doom9.org/showthread.php?s=&postid=173132#post173132

If it is considered as useful, it would also be nice to have in your tool, MoonWalker.

Another suggestion, of which I think it could be quite useful:

A counter of how often the quants switched from 3 to 4 and from 4 to 3.

Koepi made a post lately, in which he mentioned that every switch from h.263 to mpeg quantizers - and vice versa - costs 140 byte extra!
(Man! I wasn´t aware of this - was it ever mentioned before?)

So, if we knew from 1st pass how often such switching happens, we would have some hint if, for the actual encoding, modulated quants are worth it, or if it would do more harm then good.

I´m no coder, so I can´t estimate how complicated (or easy) this calculation would be.
But the more info one can get, the better ...

[MoonWalker]

So, if we knew from 1st pass how often such switching happens, we would have some hint if, for the actual encoding, modulated quants are worth it, or if it would do more harm then good.


This is impossible to know cause at the stats file all frames all stored with quant2..So we don't know until the actuall encoding(or the simulation) finishes the 3-4 jump..It's easy to code but, I can't see any obvious usefullness :)

MoonWalker

[Didée]

Well, it seems yesterday I forgot to take my brains with me.

[Slapping myself for being stupid]

[HellSpawn]

Thank you Master Moonwalker for this glorious program.It is indeed what the users of Xvid needed.Altough I still encode using DivX 3.11:D
Always a humble survant Master!Altough I kick your $%$# in Marvel Vs Capcom:D
See you on September 1st.

[ookzDVD]

@Moonwalker,

I think your v0.11 is not working with the latest Koepi's build,
I got negative (-) size for the 1st pass size.

Thank you.

[MoonWalker]

Originally posted by HellSpawn
Thank you Master Moonwalker for this glorious program.It is indeed what the users of Xvid needed.Altough I still encode using DivX 3.11:D
Always a humble survant Master!Altough I kick your $%$# in Marvel Vs Capcom:D
See you on September 1st.

Hmm..Will see about the :D :devil: :devil: :D

MoonWalker

[MoonWalker]

Originally posted by ookzDVD
@Moonwalker,

I think your v0.11 is not working with the latest Koepi's build,
I got negative (-) size for the 1st pass size.

Thank you.

Hmm..Never have found this? Which movie are you analyzing? Anyway, I am waiting MarcFD to return to release v0.12..It's almost rewritten and should correct all the problems :) :cool:

MoonWalker

[pt7]

The negative first size is a problem with an integer overflow from the debugger. It reaches 2^31 and then rolls to -2^31.

Look at the detailed debugger log file.

The simple fix for DebugView would be to adjust to the correct value if the final size reported is negative. [EDIT: Add 2x2^31] Alternatively Debugview could add up the individual frame sizes. Not much code (but I am not writing it) and it would increase the processing time (again not much).

I was suprised at this problem but then realized it was only because I was experimenting with resolution scaling.

@Moonwalker
Thanks for the useful tool.

-PT

[MoonWalker]

Originally posted by pt7
The negative first size is a problem with an integer overflow from the debugger. It reaches 2^31 and then rolls to -2^31.

Look at the detailed debugger log file.

The simple fix for DebugView would be to adjust to the correct value if the final size reported is negative. [EDIT: Add 2x2^31] Alternatively Debugview could add up the individual frame sizes. Not much code (but I am not writing it) and it would increase the processing time (again not much).

I was suprised at this problem but then realized it was only because I was experimenting with resolution scaling.

@Moonwalker
Thanks for the useful tool.

-PT

Actually it was something in the output string..I fixed it and I'll release as soon as MarcFD gets back from holidays :)..Many Many changes..Just wait :D ..

MoonWalker