Crispness in XviD

[snw]

Sorry if this has been discussed before, couldnt find it...
I've for a long time used Nandub to encode my rips and I'm very pleased with the detailed result I get there. I just did some testing in XviD and I just can't the detailes that I can in Nandub. Any suggestions for settings? I've tried to enable/disable most things and comparing the result. I'm always doing 2cd rips with a high bitrate. In Nandub I set the crispness modulation to 0. Any similiar function in XviD that I missed?
Thanx

[Jan Marijniszoon]

I had the same problem in the begining. I stayed loyal to Nandub SBC too because of the great details. Only drawback is the blockiness in backgrounds and stuff.

To achieve the same crispiness (or even better to my opninion) I can give you the following tips:

Use a custom mpeg matrix...

the "HVS BEST PICTURE"-matrix gives very good results to my eyes.
Compression is still good too. About the same amount as DivX3 and the default mpeg-matrix.

If the second pass-file is 80% - 100% of the first pass-file, then you should enable qpel. This gives amazing sharp results with only one drawback: strange moving artifacts in some area's.
But if your bitrate is high enough you won't almost notice any of these artifacts, but the crispiness gain is amazing to my opninion.
So that's why I advise 80% and up or else it will look like a mess.
If you use ffdshow for playback, be sure to REALLY use XviD for decoding. ffdshow (3 januari build) does not deal with qpel so well.

Some other tips:

Always use ultra high on motion search and always enable chroma motion.

Cut the keyframe range to 2 - 3
Cut the P-fame range to 2 - 3 (from 75%), 2 - 4 (from 70%) or 2 - 5 (from 65%)

Try to avoid b-frames.
If you use them, keep it to 2/100/100 for a 2 CD-rip.
Enable VHQ mode 4; it's slow, but more quality!

[EDIT]Sorry I was wrong about this. VHQ 4 is only good for more compression versus a little more quality degration. I think it is usefull for heavy 1 CD-rips. For crispiness use no VHQ or VHQ mode 1.
Thanx Kyo for correcting me![EDIT]

Do not use GMC!

Hope this helps. It works for me most of the time.
This is just my opinion, so people don't get mad if you disagree ;-)

Greetings,
Jan.

[Kyo]

Enable VHQ mode 4; it's slow, but more quality!

If I have remember well, VHQ 4 doesn't give more quality it increase te search for aditional MV and so a image degradation will happen, also the thread for VHQ conclude that the most "safe" value is 1

Correct me if I'm wrong....

[kilg0r3]

Originally posted by Jan Marijniszoon
If the second pass-file is 80% - 100% of the first pass-file, then you should enable qpel. This gives amazing sharp results with only one drawback: strange moving artifacts in some area's.

At the moment i would not recommend using qpel unless you are sure that do not have any fog, smoke, underwater scenes or the like. For the simply do not look good even at high bitrates.


Regarding the quantization matrices, I read that there can be dequantization errors in ffdshow.

[mf]

Originally posted by Kyo
If I have remember well, VHQ 4 doesn't give more quality it increase te search for aditional MV and so a image degradation will happen, also the thread for VHQ conclude that the most "safe" value is 1

Correct me if I'm wrong....

You're right. VHQ causes very obvious "false ME", which occurs in panning walls and skies. A good description of the artifacts caused by VHQ might be "motion occurring in the wrong direction (up and down when the actual motion is horizontal) in large undetailed (flat or gradient) surfaces".

[Selur]

Strange, the flowting walls problem was kind of fixed for me with the latest build from Nic,.. tested some clips and encoded two movies without any problem,..

So is it still a problem? :confused:

Cu Selur

[kilg0r3]

@Selur

My tests were done with the 08032003 Koepi build. So, it might well be that VHQ > 1 no longer causes this problem. However, looking at the changelogs of the instant builds on my site, it looks like, the earliest changes to VHQ have been done only yesterday (2003.04.08).

Could you check that again with the latest Koepi build? I'd love to add another entry to the category of squashed vermin for the latest Koepi build :D

edges/sharpness
In another thread Emp3r0r mentioned a color shift by one or two pixels, which seems due to the currently available decoders. So, once this is fixed we will probabely get even sharper pictures. :)

[Selur]

I used Nic's (30/03/03) build for my test and encodes, but I'll do a swift test with uManiacs latest build,.. (in 30 min)

The test:
0. I tested the scene of 'The Matrix' where Agent Smith questions Neo. With earlier versions in this scene the flowting wall problem was perfectly visible.
1. in DVD2AVI I use the iDCT "64-bit Floting Point"
2. I used this avsscript:

LoadPlugin("C:\PROGRA~1\GORDIA~1\mpeg2dec3.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\decomb.dll")
mpeg2source("D:\Test\u.d2v")
Telecide(guide=1).Decimate(5)
crop(0,60,718,356)
LanczosResize(704,288)

3. I activated the following features of Xvid:
qpel+vhq4+chroma motion+chroma optimizer and I used the MPEG quantizer and 1pass with quantizer 2

After 13min encoding (got 7fps) I watched the clip with the BsPlayer and uManiacs current build (09.04.2003.1220) and the clip was fucked up,.. (using another version for decoding didn't help)

So, questioning my eyes and mind I did a test with Nic's (30/03/2003)build and ... the flowting wall was there too,.. so I watched my 2pass encode I did with vhq4 and the flowting wall wasn't there,.. so I'm going to do some tests and report later,... (and I'm sure I used vhq 4 on my 2pass encode,.. otherwise I wouldn't understand the speed slow down ;) )

Cu Selur

Ps.: seems to be Qpel
After disabling qpel the flowting wall isn't there,..

Did some more test and it seems like vhq+qpel is buggy but each on it's own works fine,... :D

Little question about the hvs best matrix, did you test what's the minimum bitrate/quantizer to use it?

[Emp3r0r]

just to chime in here on crispness. all my recent encodes are looking pretty good with XviD as long as I change the fourcc to DX50 and use the DivX decoder for playblack. this avoids the color shift problem and coincides with a more crisp picture. all the movies I encode are either big hollywood movies or jacki chan / jet lee movies so they are 1.5 to 2 hours. i shoot for either 730 megs or 1100 megs depending on wether I keep AC3 sound or not. i usually go for a standard width resolution of 640 unless I have more bits to spare (ie: highly compressable movies) and adjust my resize filter accordingly. I think less filters is better, unless the situation demands otherwise. here are the settings I use with XviD to get good looking (crisp) movies:

http://jvance.com/files/XviDSettings.html

ps: remember, XviD decoder and ffdshow have an error in colorspace conversions which causes a loss in crispness

[kilg0r3]

@Emp3r0r

Wasn't there a way to temporarily associate the Divx filter with the xvid fourcc?

[Nic]

@Emp3r0r:
"remember, XviD decoder and ffdshow have an error in colorspace conversions which causes a loss in crispness" ?? Are you sure its colorspace causing the problem.

Could you do me a favour and try to play an avi with my decoder with dbgview running and then save inital output as a text file and post (a link) here. That way I can see what colorspace your using (hopefully).

Does this "loss of crispness" occur no matter what settings you use?

Cheers,
-Nic

[Emp3r0r]

Are you sure its colorspace causing the problem. No, but thats what I gathered from this thread (http://forum.doom9.org/showthread.php?s=&threadid=50309)Could you do me a favour and try to play an avi with my decoder with dbgview running and then save inital output as a text file and post (a link) hereI never could get dbgview to work, but it has been years since I tried... I'll try again when I get home.
[update] ok: i got home and ran dbgview (too simple) and here is what it said after opening 3 XviD movies, and the 4th one with fourcc changed to DX5000000000 0.00000000 [2080] quartz.dll(tid a90) 94261 : Created 3 surfaces of type YV12 @0XB4E8700
00000001 32.32499075 [1732] Direct3D7: (WARN) :Executing processor detection code (benign first-chance exception possible)
00000002 32.32977152 [1732] Direct3D7: (INFO) :MMX detected
00000003 32.51969762 [1732] quartz.dll(tid f18) 625 : Created 3 surfaces of type YV12 @0X6504500
00000004 44.99784302 [3532] Direct3D7: (WARN) :Executing processor detection code (benign first-chance exception possible)
00000005 45.00277577 [3532] Direct3D7: (INFO) :MMX detected
00000006 45.18748640 [3532] quartz.dll(tid ea8) 281 : Created 3 surfaces of type YV12 @0X6513500
00000007 60.06248029 [3380] Direct3D7: (WARN) :Executing processor detection code (benign first-chance exception possible)
00000008 60.06672021 [3380] Direct3D7: (INFO) :MMX detected
00000009 60.33877462 [3380] quartz.dll(tid d7c) 375 : Created 3 surfaces of type YUY2 @0X663CD00 Does this "loss of crispness" occur no matter what settings you use? Err, I need to do more testing. I'll check the last stable build.

[sh0dan]

DivX might be using YUY2 for overlay - and perhaps your hardware has problems upscaling YV12.

[Nic]

Thats what im thinking too sh0dan...Im thinking of the easiest way to know the output colorspace of any filter when playing a video.

Does any one know a simple solution (that newbie's could use, i.e. not graphedit with dxsdk installed). Otherwise ill write some code to do it.

-Nic

[Nic]

Well I just wrote this up quick:
http://nic.dnsalias.com/ColorspaceTest.exe

Run that, enter in an AVI file and then hit get colorspace. It will play the video for a second and then tell you what colorspace it was using to display it.
(cool huh? ;) )

Cheers,
-Nic

[Jan Marijniszoon]

Originally posted by Selur

Little question about the hvs best matrix, did you test what's the minimum bitrate/quantizer to use it?

Not really. It depends on the source you want to encode.
Base it upon the first pass size I would say.

I personally would not go further than quant 5 with this matrix.

[kilg0r3]

@Nic

I get 'unknown color space' as result. ??

[Nic]

Download it again ( http://nic.dnsalias.com/ColorspaceTest.exe ) and now it will probably still say unknown colorspace but it will also give me the GUID to find out what colorspace it is. (what decoder are using ? ffdshow im guessing ? )

Cheers,
-Nic

[kilg0r3]

@Nic

When forcing nothing in Your decoder i get:

GUID: 32595559-0000-0010-8000-00aa00389b71

When forcing YUY2 i get:

GUID: 32595559-0000-0010-8000-00aa00389b71

So, it is YUY2 :)

YV12 does not work for me because the matrox g400 does not support it when dual head is enabled.

[kilg0r3]

@Nic

When forcing nothing in Your decoder i get:

GUID: 32595559-0000-0010-8000-00aa00389b71

When forcing YUY2 i get:

GUID: 32595559-0000-0010-8000-00aa00389b71

So, it is YUY2 :)

YV12 does not work for me because the matrox g400 does not support it when dual head is enabled.

Btw, I was just testing your little app; not testing colorspace conversion routines.

Another btw, would it be possible to integrate a chroma optimizer for the decoder that interpolates color values when converting to yuy2 for playback. I just can't stand these color jaggies you get with boundaries of solid colors. Despite the tone, this is no complaint just a suggestion.

[Nic]

Lol, like the idiot I am, the only colorspace I wasn't testing for was yuy2, dont know how I missed that. doh.
New version up detects YUY2 just fine :)
( http://nic.dnsalias.com/ColorspaceTest.exe )

(well it should work, lol, if not then just write the GUID here and ill look it up, for those with the dxsdk its in the uuids.h file)

-Nic

[kilg0r3]

nope. same message.

[Prettz]

Can this colorspace program help explain why on my system divx/xvid files look very crappy using mediaplayer2 and zoom player, but look great using bsplayer? Would this have to do with the colorspace the players choose to output to, or how they handle resizing the output?

[ssjkakaroto]

Prettz can you by any chance be using a geforce card? a friend of my experienced a similar thing and the problem was that everytime he switched to tv output his desktop went to 16bit and all videos looked like crap with most players but with bsplayer (don't know why), but when he discovered it and swithed back to 32bit all the videos were ok again

[celeron]

nop same prob. in here the encode its in yuy2 and its says that its yuy12.

Here its what i get i dont now if it helps.

Colorspace Being Used For Output: YV12
GUID: 32315659-0000-0010-8000-00aa00389b71

[ssjkakaroto]

nic all my yv12 videos report:
Colorspace Being Used For Output: RGB32
GUID: e436eb7e-524f-11ce-9f53-0020af0ba770
is this because of my video card (gf2)? or is it a filter problem(ffdshow 01/03/2003)?

[Nic]

ive got a geforce2 mx at work and it came out as YV12 all the time unless I tried to play raw yuy2 in which case it couldn't overlay it so used rgb565 which looked really bad. The colorspace my tester outputs is the same as would be used if you were using media player.

@celeron: What do you mean "its in yuy2", if it says its outputting yv12 then its outputting yv12 ?? If you mean you encoded the clip in yuy2 then that has no bearing on the output colorspace

@ssjkakaroto: Thats not good, rgb32 output wont look as nice. Are you sure what decoder your using, 3ivx's decoder tends to display xvid with rgb32 output

@Prettz: Yes it might do, try to find out using my app what mplayer2 would be using to output, and then try and find out what bsplayer forces the output colorspace to.

-Nic

[ssjkakaroto]

nic, i'm pretty sure it's using ffdshow since it's the only decoder i have besides xvid itself cuz i never even downloaded 3ivx :p but ffdshow doesnt report it as yv12 neither but yuy2 so i thought your program would report it too instead of rgb32, if it did i wouldnt even have posted cuz i would think thats the normal thing but now you're saying that it reports yv12 to you so i'm starting to get worried :scared:

[Emp3r0r]

Using DivX Decoder (by changing fourcc)
Colorspace Being Used For Output: YUY2
GUID: 32595559-0000-0010-8000-00aa00389b71
Using Nic's XviD Decoder
Colorspace Being Used For Output: YV12
GUID: 32315659-0000-0010-8000-00aa00389b71
Using Nic's XviD Decoder (during second try)
Colorspace Being Used For Output: YUY2
GUID: 32595559-0000-0010-8000-00aa00389b71

Yet dbgview still says when I open the same movie
[2200] Direct3D7: (WARN) :Executing processor detection code (benign first-chance exception possible)
[2200] Direct3D7: (INFO) :MMX detected
[2200] quartz.dll(tid a5c) 13000 : Created 3 surfaces of type YV12 @0X642F100

odd stuff

I'll reboot now.

<edit> I was also opening the video from inside OGM (nic's opened the OGM's too)</edit>

[Prettz]

Originally posted by Nic
@Prettz: Yes it might do, try to find out using my app what mplayer2 would be using to output, and then try and find out what bsplayer forces the output colorspace to.

ffdshow says YV12 for divx3 and xvid in zoom player, and YUY2 for divx3 and xvid in bsplayer.
Your colorspace program says YV12 for divx3 and YUY2 for xvid.

The thing about the quality with zoom player and mediaplayer2 is that it's only noticeable when I enlarge the window or go full screen. Then it almost looks like the wrong resize method is being used, or the resize method has problems. I guess it could best be described as making all the edges in the video appear stretched and pixelated, and the colors appear to have bled together. I wish I could post screenshots but I haven't seen a way to screencap DD surfaces or overlays after resize; they only cap at the video's original resolution.

edit: @ssjkakaroto: I have a Hercules 3D Prophet III Geforce3, and I'm using Hercules' latest Win98SE drivers. Because there's a more recent version of the drivers that's only for XP/2k, I've always suspected it might be the driver's color conversion or resize methods that are at fault.

[Nic]

@emp3ror: What does (second try) mean? And did it look better (like the divx5 decoder) when doing the "second try" or did it look the same as my decoder doing YV12?
(well spotted about the OGMs, it does any format (i.e. mpeg-2, etc))

@ssjkakaroto: Thats very bizzare, if your feeling confident, try doing a render media in GraphEdit, if there is another filter between ffdshow and the video renderer, then you've got problems. But otherwise your probably ok, Dont know how my prog could say the wrong colorspace though?? (if theres a filter inbetween ffdshow and the video renderer then something is taking ffdshows output then converting it to rgb32 before displaying, which should look real bad)

-Nic

[mf]

I think Nic's decoder has a colorspace force option, and ffdshow has as well. If you use ffdshow, unchecking all colorspaces in "Codecs" except "RGB32" and unchecking "Use Overlay Mixer" might solve the problem. In Nic's, just try forcing RGB32. I'm not satisfied with my overlay resize method, so I use DDraw non-overlay display, which works like a charm. But it might run slow on older computers. Overlay problems may also be solved by installing newer display drivers.

[wotef]

i'm sure blight could shed some light on this - i believe bsplayer is unique as it doesn't render overlay in the same way as zoomplayer, and i recall that one of the differences is due to the usage of a particular directdraw function via software (not hardware) in bsplayer

[ssjkakaroto]

ok i'll try it when i get home, but i used graphedit one of these days to render a ogm file and i don't remember anything between ffdshow and video renderer, there was indeed two filters (dvobsub and tobias subtiltle filter) between ogg splitter and ffdshow but since the files i tested were avi's those filters shouldnt be there (i think? :confused: ), oh and for some reason they don't look bad to me (maybe cuz i never seen a yv12 output :p ) but anyway i'll test it later, cya

[kilg0r3]

AFAIK bsplayer only outputs yuy2

[celeron]

forget Nic, mistake of mine, 2 many filters that im geting lost!

Soz about that!

[sungey]

hmm i just tried the colorspace tool .. i tested on an xvid encode..
2 copies of this encode is made.. DX50 and xvid fourcc each.

Encode D = xvid using DX50 fourCC
Encode X = xvid using XVID fourcc

With Divx503 and xvid.ax in Umaniac 5/4/2003 build

D followed by X - first one is YV12 .. second one is YUY2
X followed by D - first one is YV12 .. seconds one is YUY2

With Divx503 and Nic Decoder (no force)..

D followed by X - first one is YV12 .. second one is YUY2
X followed by D - first one is YV12 .. seconds one is YUY2

With Divx503 and Nic Decoder (forced YV12)..

D followed by X - first one is YV12 .. second one is RGB32 :(
X followed by D - first one is YV12 .. seconds one is YUY2

Seems like my graphic card cant do 2 YV12 overlays at once. Using GeForce3 here.

[ssjkakaroto]

:eek:
bah, nic there are two filters between ffdshow and video renderer:
Subtitle Mixer and AVI Decompressor
they're probably the ones converting to rgb32
if i delete those two and try to link ffdshow directly to video renderer they automatically popup, the only thing i can do is delete Subtitle Mixer and link: ffdshow->avi decompressor->video renderer
when i do that ffdshow reports as YV12 :) but can i really trust that?
and can i disable subtile mixer without unistalling it?

[Emp3r0r]

What does (second try) mean? And did it look better (like the divx5 decoder) when doing the "second try" or did it look the same as my decoder doing YV12? the second try means I checked the colorspace a second time with your tool (which by the way leaves the original video open). apparently it is impossible to do two YV12 overlays so the second is output as YUY2. The YUY2 output did look better than the YV12 output using your decoder.

ps: i'm on geforce 3 hardware

[Jan Marijniszoon]

Originally posted by kilg0r3
At the moment i would not recommend using qpel unless you are sure that do not have any fog, smoke, underwater scenes or the like. For the simply do not look good even at high bitrates.

Maybe before...not now...
I made some rips with Qpel enabled, b-frames enabled and VHQ 1.
Just looks amazing with qpel! even scenes with smoke, water and very dark areas.

With the new ffdshow build from 18 april it just looks superb.

In some areas if you look good enough, you might still discover some floating artifacts (also called 'smearing'). But that is a small price for the sharpness-gain you are getting!

Greetings,
Jan.