Odd behaviour in Xvid during movement

[Mentalmummy]

I was using Koepi`s latest build but it was very blocky for some reason so I tried Nics December build.

It looks good on almost still footage (see a screenshot here (http://www.digitalsword.co.uk/low_movement.jpg) ) using the default settings with a bitrate of 700 but as soon as there is any movement in any direction it becomes blocky (see screenshot example here (http://www.digitalsword.co.uk/normal_movement.jpg) ).

I have tried the default settings and also with everything turned to best (trellis on, adaptive quantisation on, chroma optimiser, qpel).

It doesn`t make a difference using one or two pass mode either, most of the encodes end up looking like the second screenshot linked to above. The effect is slightly less pronounced at 1000 Kbps than at 700 but not much.

I have tried the ffdshow decode filter with maxed settings for quality but still same effect. I have an AMD 1.8 Ghz Athalon, 256 Mb RAM, Nics latest codec build of Xvid encoder and decoder.

I have opened a vob directly via VirtualDubMod to test the quality and this was the result, very blocky but also the same if I try with any other software such as avs2avi.

I have read the faq`s, forum posts and as far as I can see it should be working properly so is there anything I am missing? I ave no other encoders or decoders installed such as divx or ffdshow other than those windows has by default.

Is it possible to change the way it handles movement changes without bumping up the overall bitrate too much as on still pictures it is pretty good.

EDIT: I have noticed the screenshot is cropped. I took it from virtualdub full size as trying to capture screenshot in media player gave blank screen though video was displayed. The screenshots are exactly as the video is though and only a small portion of the screen is missing, neither has been blown up or shrunk.

Thanks.

[stephanV]

you might want to look into deinterlacing judging from your second picture...

dont you see a lot of horizontal lines in VirtualDubMod during scenes where there is (a lot of) movement?

[Mentalmummy]

I have deinterlaced, on this example I left it as was though so was unadulterated but effect is same whether interlaced or deinterlaced.

When deinterlaced I see no lines but many blocks as shown in the second picture. I am baffled as to why it`s doing this.

[Didée]

Originally posted by Mentalmummy
I have deinterlaced
*How* did you deinterlace?

[Mentalmummy]

In VirtualDubMod choosing the internal blend fields option but the screenshots are not deinterlaced. I tested with and without deinterlacing to see if that was the difference as some stuff I want to encode I need to keep interlaced (field sequential 3D video).

I have read about changing the rate control but haven`t been able to try that as I believe the defaults should be fine?

[Mentalmummy]

I notice that using the quantiser rather than bitrate it looks fine on movement, is there any way to equate the quantiser settings used to a constant bit rate encoding as with the quantiser it comes out as a very large filesize :(

[Ark]

Apart from deinterlacing (or not), it is me or this seems to be a simple lack-of-bitrate problem?

I mean, high motion sequences are the first to be afflicted by macroblocking due to low bitrate, so this isn't an "issue" of xvid, but more probably 700kbps isn't enough for that footage and that resolution imho.

Just my 2 eurocents...

[Koepi]

I don't quite understand the settings used (too much to rad for my little time), but from the screenshots I can see that the resolution is 768x (at least) 438. For such a resolution 700kbit is really very little.

Did you use constant bitrate? Then the moving scenes will look bad for sure.
Do a proper 2pass encode with a target file size (or there with a bitrate target) and you should be satisfied with the result. 1pass CBR uses a very primitive rate controller and is not at all recommended - avoid it if you can!

Cheers
Koepi

[pwh04]

Originally posted by Mentalmummy
I notice that using the quantiser rather than bitrate it looks fine on movement, is there any way to equate the quantiser settings used to a constant bit rate encoding as with the quantiser it comes out as a very large filesize :(

Well i use these settings (xvid 1.1 beta) and I get very nice size/brate control & nice constant quant control which I feel gives very high quality for me (Thanks XviD devs!)

Gknot for bitrate calculator/crop/resolution (I use minimum .200 bits/pixel to get resolution size and greater file size control)/ and audio encoding.

XviD Settings:
1 pass
target bitrate mode (what you get from gknot calculator)
quant zones 2-3 2-3 2-3
cqm: hvs best (important to keep size control)
chroma
vhq bframes
vhq mode: 2 3 or 4 (the higher the better for compression and quality gains but adds encode time)
packed bitstream: off
all else pretty much default..

Avs script: #undot (no undot)
Deinterlace: tomsmo
Resizer: bilinear

[Didée]

Ooops ... way OT. Changed to PM.

[Mentalmummy]

The problem was that, as suggested, the size was too big (doh!).

I resized to 352 x 576 and it was much better using Nics latest build. I tried using the latest Koepi build with same settings and much better also but still a little blockier so I think my pc doesn`t like the newest version.

Thank you all for the help, and I apologise that while I tried the different settings I forgot to change the size - how I missed the obvious I don`t know.

Also thanks to Nic and Koepi for their xvid work :)

I`m going to hide in embarrasment at missing the obvious....