DivX4Log and Adusting Quantizers - Is this worth looking into?

[BluDChyLD]

Up until now, i've always use gordian knot to encode my movies with divx 4 and 2-pass encoding.

I've read that in between the first and second pass it's worth using divx4log and tweaking the log file the first pass makes. Is this hard to do and are the end results really worth it?
Thanks,
BluDChyLD

[MxxCon]

oh look, a link (http://forum.doom9.org/showthread.php?s=&threadid=13988)
also everwicked did a divx4/gknot guide that uses divx4log, try it out and see results for yourself

[rui]

Thanks for the link.
But i would like to know the opinion of somebody that already tried divx4log. I am in the same situation that BluDChyLD is, and before trying, i would like to read some people opinions if it is worth the trouble.
Yes, i know i am being lazy :D

[UHT]

personally i dont think its worth it, not for me anyway...

[rui]

Well, for now i am perfectly happy with the Gnot divx4 quality.
But i was searching for a way of getting rid of the little noise around sharp contrasts.
Doom9 demonstrated this in the first matrix screenshot, in his codec comparison.
If somebody has any ideas please post here.
Thanks

[UHT]

use gknot's low noise filter
or use one of sasami2k's playback smoothers

[rui]

Thanks for the quick reply. I will try that.
You are an EXCELENT moderator ;)
Long live the Queen. :)

[UHT]

well thankyou very much, nice to be appreciated :)

[Doom9]

a couple of thoughts.. now that I have played around with the tool a little (not encoded anything yet).. I think it would be most useful in a 3 pass process. First you do your 2 passes as usual, then you review the clip, and where you see room for improvement you note the framenumbers, then have a look at the analyze log, go to divx4log and adjust the quantizers for that region... but I don't think that works just as this.. it works in gknot but for divx4log we don't have an already scaled curve that we can just adapt to our needs.. in my example I got a basic bitrate of 350kbit/s.. took a lot of tinkering to just get it up.. I think it should work the other way round.. divx4log should calculate a basic set of quantizers that fill up the space.. and then give you the option to modify them.. just my 2cents (funny.. now europeans can say the same and it actually makes sense;)

[b0b0b0b]

I think it would be cool if someone would write a utility that scanned an avi for blocks in the output. I think that images are composed of 8x8 blocks. They should be pretty easy to find.

Blocks really annoy me.

[Doom9]

the problem is.. it's not the DCT blocks that are the problem.. it's how they are arranged in the picture... you see blockyness if the different DCT blocks in a certain area of the picture "don't go along"... now try to put "don't go along" into a formula

[b0b0b0b]

My formula is if there is high contrast on the 8x8 grid on the picture.

One lame way of calculating this would be for each side of each 8x8 block, average those pixels and compare that average against the average on the adjacent boundary. If all four sides of one 8x8 box exhibits some significant difference from their neighbors' sides, then you have a block problem and this frame should be flagged (the rest of this frame need not be processed).

Of course I can't write windows code and I am lame and program in java so I will probably never write this or anything like it.

[trbarry]

It's an interesting question. I'm probably missing a lot of it here but it seems it could be done efficiently in assembler in real time by just comparing the average vertical (only) contrast on interblock boundaries to the average of intrablock boundaries. It wouldn't be exact but probably a good indicator of blockiness and fast to compute.

But I don't know what you would do with it then.

- Tom

[b0b0b0b]

I would flag blocky frames for me to look at and apportion more bits to.

I could imagine coding some kind of iterative program that would find ranges of frames with blocks, give them more bits, and re-encode. Of course sometimes you just don't have enough bits to go around and this situation would have to be dealt with.

Edit: I think this would be a special case, smart anti-shit.

[yokem55]

I'ven been thinking some, and it seems that the next quality jump is going to come from adding third or even fourth pass to the whole process....or, what about having the first pass of a two pass system to be like the divx4 quality based single pass...ie, no settings other than a subjective quality level, and then the second pass then tries to scale the quanitizers down so that the film fits into a specified average bitrate, or even better, specified file size, in the second pass...

[-h]

Re: block noise - yes you can solve it by throwing more bits at certain macroblocks, but then you take bits from other macroblocks, which become blocky in return :)

Something like TMPGEnc's soften block noise will probably make its way into XviD eventually, smoothing the image slightly to alleviate block noise, during preprocessing.

-h

[MxxCon]

re block noise
i'm not really familiar with math involved in all these things but here i think it would be better to have block detecting algo during playback and then 2 pixel wide smoothing to hide obvious difference between block boundaries.

[-h]

i'm not really familiar with math involved in all these things but here i think it would be better to have block detecting algo during playback and then 2 pixel wide smoothing to hide obvious difference between block boundaries.

That's what the directshow filters for DivX 3.11 / DivX 4.x do as part of their post-processing filter. However, post-processing isn't a part of the MPEG4 spec, it slows down decoding, and can adversely affect (blur) the image.

It'd be much neater to have built-in correction during encoding, just like pre-echo artifacts in MP3 encoders (blockiness and pre-echo are actually both the result of quantizing DCT coefficients).

-h