Unstable quality not as good as stable?

[verloren]

I use xvid to distribute copies of home movies to relatives, putting about an hour of footage on a 700MB CD. The quality from the last stable build Koepi provides is surprisingly good - reasonably crisp images, with an acceptable amount of 'jpeg-like' artifacting. I've used many of the unstable builds produced since then, and none have matched the quality of the stable version - the output always looks much more grainy, rather like I was watching through a mesh (not a great description I know!)

I've tried switching on or off all manner of settings (qpel etc) and nothing seems to get the unstable close to stable for quality. Yet on the forum I read comments about how close the quality is to a 1.0 release. I'm not at all dissatisfied with the quality from stable, just puzzled as to what I might be doing wrong (a search here and through google hasn't shown me my mistake).

All comments gratefully received!

Cheers, Paul

[TelemachusMH]

Originally posted by verloren
... putting about an hour of footage on a 700MB CD.
I think there is your answer. If you are putting only an hour of video on a cd the bitrate would be somewhere around 2000kbps. Xvid is designed more for compressing into lower bitrate 600 - 1500kps usually and the 'unstable' options in the builds are designed to allow for better videos at the lower end and since the stable version does not have these, it does not have the compression artifacts that they produce either.

Try making a test by putting two hours of video in 700mb of space and I think you'll see a difference.

TelemachusMH

[TheXung]

Perhaps there is an issue with interlacing on the unstable builds. Most people don't use it here so it could have gone by for a while untested.

[sam_b]

I don't know how verloren captured his 'home movies', but most camera footage, whether captured or via DVB tend to head towards the 2-3Mbit side of things. 1st pass can often be 4-5mbits at 640x480 ish resolutions, so 1 hour of most footage in 1 CD I would say is a medium bitrate for Xvid, and would have thought that B-frames would definately help. At high resolutions Qpel tends to be more trouble than it's worth for me.

Can you assure me that you have not just ticked every box in koepi's latest and tell us your build, settings and AVS?

Oh, and The Xung's idea is probably true if you sending interlaced stuff to XviD.

[verloren]

I tried doing an encode at lower (though still not very low - 10000kbps Max) bitrates, giving me a file of 420MB (including audio). The quality was as suggested by TeleMachusMH - quite similar to the unstable build, though still not quite as good. The biggest problem is around moving edges, where if someone for example moves their arm there is a 'cloud' of background that moves with the arm (again, a poor description!) I'm currently experimenting with lowering the max i-frame interval, as this seems to 'reset' the cloud back to insignificant levels with each i-frame.

Given the 'requirement' for relatively low bitrates for Xvid to do its thing, would it be better to do full DV resolution (currently use 360x240)? I'll try it anyway.

For the record, my settings are:
Source: De-interlaced Canopus DV (from a Sharp camera) converted to a DV type virtualdub will understand (type 1?)
Res: 360x240 (previously 2:1 HQ filtered in vdub)
Motion Search: 6
Quant: H263
FourCC: Xvid
Max I-frame: 300 (to start)
Min I-frame: 1
Qpel: on (everything else (gmc etc.) off)
B-frames: -1
Quant: 2/31
Max Bitrate: 10000
Max overflow: 60%/60%
No credits change, no chroma

Use 2-pass processing on an Athlon 1500+ with 512MB Memory (about 30fps) using virtualdub 1.5.1

Thanks for the advice so far, and if you have any other suggestions let me know!

Cheers, Paul

[thejho]

Enabling B-frames will probably help (better compressibility),chroma motion, from what I understand, may also be helpful.
But DON'T use qpel, it's really buggy in the latest build from koepi.
Anyway you'd better use nic's, it's supposed to fix a good deal of problems.:cool:
You could also try VHQ, but at this bitrate I think it's going too much for compressibilty, you'll have more artefacts:sly: ...

BTW, use the 700MB : p
Good luck

thejho

[sam_b]

OK, a few points:

Please use MOD 16 resolutions if you can. MOD8 tends to work but MOD16 is usually better. Do you really want 3:2 aspect?
I would suggest that you move up from 360x240 at this bitrate for DV. Possibly try 528x352 or 480x320? I would not use sharp bicubic for DV, as it tends to ring (edge enhancement) quite a bit anyway in my experience. Can you use avisynth? It tends to be pretty good at these things.

I much prefer MPEG for DV, but I would suggest you give it a go.

You are using default 2-pass scaling aren't you?

It sound like you have an old build without VHQ. Download latest and try VHQ 1. DO NOT use GMC with VHQ. I would suggest leaving qpel off for the moment, it sounds like the main source of your problems. Chroma motion tends to help so I suggest you enable it.

Try B-frames 1/150/100 for a start and see what you think. Leave the checkboxes at default. Also try 2/125/75 or something if you like.

Is there a reason you are only aiming for 420mb? 700mb would be much better I would think.

[verloren]

So I tried an encode at full DV res, but it was very jerky, so I guess there weren't *enough* bits for that :)

To answer some questions:

I only used 420MB to make the file smaller, as someone suggested that Xvid would actually look better at lower rates (odd, but seems to be true). Normally I'd allow up to 700MB.

I don't know what MOD16/MOD8 resolution means - any more detail (quick googling didn't shed any light)

I don't want a particular ratio, I'm just keeping it the same ratio it came in as, so stepping up a bit would probably work (full res being too much!)

MPEG - will try

default scaling - yes

Used VHQ (1) for the unstable builds, haven't examined it closely enough to tell any difference

Will try other suggestions (qpel, b-frames etc).

Appreciate all the help!

Cheers, Paul

[Jon Ingram]

I don't know what MOD16/MOD8 resolution means - any more detail (quick googling didn't shed any light)

He means -- use resolutions that are divisible by 16, not just divisible by 8.

[sam_b]

I have never come across any encoding that looked better at a lower bitrate. Someone was on something when they told you that. Sorry, I should have explained MOD16/8 better. Thanks Jon. If the encode was jerky it normally means your computer is too slow to decode it properly. Full D1 takes quite a bit ot decode.

I'm a bit puzzled as to why you don't want a particular ratio? D1 res (NTSC) is flattened vertically when viewed on a monitor. You need to resize to a 4:3 size. Search google for aspect ratios. Please try the resolutions I suggested.

[Owen]

Can anyone advise me which build is best for Maximum Quality at high bit rate (up to 9mbps or more).
I use Xvid for real-time capture at a fixed quant of 2 for 720x576 PAL.
I set motion search to 5, Interlace ON, everything else at default.
I am hoping for DVD quality at DVD bit rates
I DO NOT want to recompress.
I find that quality is unacceptable at bit-rates less than about 5-6mbps or about 2.6 Giga Bytes per hour. I was expecting better.
Any info on settings and build would be helpful.

Thanks,

Owen

[sam_b]

Interlacing seems a bit wrong at the moment in dev builds. Suggest a stable build with this (http://forum.doom9.org/showthread.php?s=&threadid=46579&highlight=andreas) matrix. Look for wotef's post a bit down. Should give you nice big quant 2 files.

[Owen]

sam_b,
Thanks, I've downed the zip and will test.
Is there any disadvantage in encoding interlaced video with Xvid interlace support off?

Thanks again,

Regards,

Owen

[sam_b]

Yeah, big. Don't do it. Oh, I meant the 78ers matrix from the zip BTW.

[verloren]

Originally posted by sam_b
I have never come across any encoding that looked better at a lower bitrate. Someone was on something when they told you that.

And the odd thing is, it did look better. Objectively I think there were bigger flaws in it, but it didn't have the constant foreground 'fuzziness' that really detracts from the image (IMHO).

I understand the mod16 thing now, thanks! Sad thing about having a too-slow computer (Athlon 1500+), but as it's targeted for slower computers that's not an option anyway.

I understand too about the aspect ratio thing - I'd forgotten about the whole rectangular pixel thing :(

I'll put this into practice tonight!

[sam_b]

Xp 1500+ should be fine unless your running the mother of all post-processing on something other than ffdshow. Something else might be up there.

[kilg0r3]

Originally posted by verloren
the output always looks much more grainy, rather like I was watching through a mesh

... constant foreground fuzzyness ...

This mesh look can also be an effect caused by higher setting of convolution3d or similar denoisers. At higher quants (=worse quality) you wont see these fine structures anymore.

IMO, partially, these statements about worse quality are caused by the improved quality which causes that artefacts in the source are accurately represented in the encode.:)