Log in

View Full Version : Xvid Q=2 what Q value is same quality in x264?


Zep
4th June 2006, 02:47
Just wondering what Q value in x264 = Q2 in Xvid quality wise.

I use MeGui and i am looking at the logs for 2 pass stuff right now and trying to figure out when x264 does a well enough job to exceed Xvid Q2 quality so i can back off options to speed up the x264 encode time to a Xvid Q2 level.

It is very hard to tell just by looking at side by side shots since some things look better and others worse :) and when i did a fast encode with every option off VS a full sharktooth profile HQ-slowest, i didn't see much of a Q drop in logs that i thought i would get with such a slow down in encode speed.

HDTV 720p resize to 624 x 352


Everything off: (91 FPS pass1 and 108 FPS. yup faster on pass 2)

I=19.14
P=22.05
average = 20.595
final rate factor= 23.36
(why is final rate factor so high?)


HD-Slowest: (51 FPS pass1 and 12 FPS pass 2)

I=17.88
P=19.97
B=21.22
average = 19.69
final rate factor = NONE LISTED


thoughts?


thanks

Audionut
4th June 2006, 03:47
This depends on alot of things.

For filesize comparison it's q18, when using the mpeg matrix in xvid.
Quality wise, use your eyes or a metric test.


Notice that the I quant drops from 19.14 to 17.88.
Try ipratio 1.25 and pbratio 1.33

edit. try the ce-highprofile in megui. Adjust deblocking if needed and change b-frame mode to auto.

Audionut
4th June 2006, 03:59
i didn't see much of a Q drop in logs that i thought i would get with such a slow down in encode speed.


This next quote should be a sticky.;)

it's not a obligation to use 16 ref, RDO, high profil ... etc etc etc with H264. H264 can be very fast codec too ... ;-)

GodofaGap
4th June 2006, 08:12
Formula is QPavc = 6*log2(QPasp) + 12

So ASP QP=2 equals AVC QP = 18.

BTW, your averages make no sense as they are not weighted.

Morte66
4th June 2006, 08:44
Sharktooth's MeGUI profiles include a couple of Xvid q2 "equivalent" profiles, one of which is constant quantizer and the other constant quality.

CQ-ASP_Q2_eqiv (const quant):
--qp 18 --ref 16 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -1,-1 --subme 6 --trellis 1 --analyse all --8x8dct --me umh --progress --no-psnr --output "" ""

CQ-ASP_Q2_eq(crf) (const qual):
--crf 18 --ref 16 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -1,-1 --subme 6 --trellis 1 --analyse all --8x8dct --me umh --progress --no-psnr --output "" ""

For more info, stop by Sharktooth's MeGUI custom profiles (http://forum.doom9.org/showthread.php?t=101813) thread.

Personally, FWIW, I think you need to change deblocking to -2,-2 to make x264 look like Xvid. I would also go for --no-fast-pskip if you've got any sky shots.

Zep
4th June 2006, 11:38
Formula is QPavc = 6*log2(QPasp) + 12

So ASP QP=2 equals AVC QP = 18.

BTW, your averages make no sense as they are not weighted.


OK COOL and yes i know they are not weighted but i was not sure Xvid status was either so i went with the basics and besides it would be tuff to weigh them since the the super fast encode had NO b-frames and the HD-slowest did so right there you are comparing apples to oranges since b-frames are automatically higher Q and 3 to 1 ratio to p frames so a straight up comparison is tuff since that is 2 data sets VS 3 and the third purposely Q+2 or more which then brings quality back into the picture. i.e. does the b-frames really look as good as the lower Q p frames.

Still the drop was no where NEAR are much as I feel it should have been given the MASSIVE slow down in encode speed. And the quality increase was barely noticeable and why i posted to begin with. :)

I guess my next test will be to cut final file size way down and see what happens.


thanks for you input!

Zep
4th June 2006, 11:45
Sharktooth's MeGUI profiles include a couple of Xvid q2 "equivalent" profiles, one of which is constant quantizer and the other constant quality.

CQ-ASP_Q2_eqiv (const quant):
--qp 18 --ref 16 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -1,-1 --subme 6 --trellis 1 --analyse all --8x8dct --me umh --progress --no-psnr --output "" ""

CQ-ASP_Q2_eq(crf) (const qual):
--crf 18 --ref 16 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --filter -1,-1 --subme 6 --trellis 1 --analyse all --8x8dct --me umh --progress --no-psnr --output "" ""

For more info, stop by Sharktooth's MeGUI custom profiles (http://forum.doom9.org/showthread.php?t=101813) thread.

Personally, FWIW, I think you need to change deblocking to -2,-2 to make x264 look like Xvid. I would also go for --no-fast-pskip if you've got any sky shots.

ahhh thanks. Good info. I will read that stuff at that link also. Basically I'm in what I feel is x264 over kill as my encodes are awesome but taking so long to encode so I'm trying to find options i can turn off to speed up the encode but keep the quality at about Xvid Q=2 single pass constant rate quality.

thanks for you help!

Zep
4th June 2006, 11:46
This depends on alot of things.

For filesize comparison it's q18, when using the mpeg matrix in xvid.
Quality wise, use your eyes or a metric test.


Notice that the I quant drops from 19.14 to 17.88.
Try ipratio 1.25 and pbratio 1.33

edit. try the ce-highprofile in megui. Adjust deblocking if needed and change b-frame mode to auto.


ok will give those tweaks a shot also.

thanks!

GodofaGap
4th June 2006, 11:48
Still the drop was no where NEAR are much as I feel it should have been given the MASSIVE slow down in encode speed.
Then maybe your instincts are not as good as you think. :p

Not every setting that slows down encoding improves quality and not every setting that improves quality slows down encoding. Using x264 at slowests settings is incredible overkill, just like the profile posted above by Morte66. And I think trying to excede ASP at Q2 is pointless too. Can you post samples where XviD at Q2 fails miserably?

Morte66
4th June 2006, 12:01
ahhh thanks. Good info. I will read that stuff at that link also. Basically I'm in what I feel is x264 over kill as my encodes are awesome but taking so long to encode so I'm trying to find options i can turn off to speed up the encode but keep the quality at about Xvid Q=2 single pass constant rate quality.

A lot of that going round at the moment. ;)

Try --crf 22 --ref 2 --no-fast-pskip --bframes 2 --weightb --direct auto --filter -2,-2 --analyse all --8x8dct --ipratio 1.25 --pbratio 1.33 --qcomp 0.75 --thread-input --progress --no-psnr --output "" "" [And --threads 2 if appropriate.]

That seems to give a good speed vs size tradeoff at constant quality (thanks Sagittaire) and it looks like high bitrate Xvid, instead of the slightly softer look that seems popular for x264 at Doom9.

Try it also with -- crf 20 and -- crf 18, for increased quality. I ran some fairly difficult test material yesterday and in "normal viewing" I only noticed a mild difference between quality 22 and 18 for about 3 seconds out of 2 minutes, but the crf 18 encode was twice the size and half the speed.

Zep
5th June 2006, 08:23
Then maybe your instincts are not as good as you think. :p?

Maybe your reading comprehension is not as good as you think since my original post was to GET DATA from others to find out why my instinct was not as good as i hoped and i even said, "i didn't see much of a Q drop in logs that i thought i would get"

and you STILL missed the point :D

WHOOOOSHHHH is the sound made as the main point goes way over your head :)

Not every setting that slows down encoding improves quality and not every setting that improves quality slows down encoding.

Hello Mr. Obvious ;)


Using x264 at slowests settings is incredible overkill,

Which I said already... "Basically I'm in what I feel is x264 overkill"



Can you post samples where XviD at Q2 fails miserably?

Where did you come up with such a Twilight Zone thing to ask since i want Xvid Q2 quality level because it is good and has not failed miserably for me.

Zep
5th June 2006, 08:39
A lot of that going round at the moment. ;)

Try --crf 22 --ref 2 --no-fast-pskip --bframes 2 --weightb --direct auto --filter -2,-2 --analyse all --8x8dct --ipratio 1.25 --pbratio 1.33 --qcomp 0.75 --thread-input --progress --no-psnr --output "" "" [And --threads 2 if appropriate.]

That seems to give a good speed vs size tradeoff at constant quality (thanks Sagittaire) and it looks like high bitrate Xvid, instead of the slightly softer look that seems popular for x264 at Doom9.

Try it also with -- crf 20 and -- crf 18, for increased quality. I ran some fairly difficult test material yesterday and in "normal viewing" I only noticed a mild difference between quality 22 and 18 for about 3 seconds out of 2 minutes, but the crf 18 encode was twice the size and half the speed.

ahhh very nice. Some good stuff there. I tried a few quick runs and i agree Q22 and Q18 are not that far apart. Sure i can tell the difference but when size and speed are factored in things become very interesting indeed :)

The main thing i have noticed in my most recent tests is that the higher the rez, the easier it is to spot Q18 from Q22 so where as 624 x 352 at Q22 is fine for me, at a full 720p it is not.

If I just had a QUAD core AMD I would just max everything and the heck with testing :)

GodofaGap
5th June 2006, 08:58
Sorry, I find it very hard to gather from your posts what your point actually is.

In your first post you say you want to exceed XviD q2 quality, so you can back down on options to speed x264 up and bring it back to XviD q2 quality. I just wondered how you would get useable results from this, because XviD q2 is near perfect in quality.

Next time please ignore my posts.

Morte66
5th June 2006, 10:38
The main thing i have noticed in my most recent tests is that the higher the rez, the easier it is to spot Q18 from Q22 so where as 624 x 352 at Q22 is fine for me, at a full 720p it is not.

You'll also find that it depends on the display, and on the other qualities (not just resolution) of the material.

When I first tried out x264 to decide on some DVD backup settings I started out at crf 26, which is the x264 default, and didn't like it at all. So I went to crf 24, and thought yeah this is ok on the clip I'm using. I decided to use crf 22 "to be safe". Six months later I replaced my 8 year old 21" CRT with a razor sharp 1920x1200 LCD, and boy was I glad I used 22 instead of 24.

As for material, I know crf 22 is not quite perfect but I think that in practice its imperfections are dwarfed by those in a MPEG2 source. I even made a mock BluRay encode (MPEG2 16000kbps ABR) the other day from uncompressed 1080p, which looked very good for MPEG2, and I'd happily back it up with x264 crf 22.

You mentioned that you're using MeGUI. Make sure you try out the options in the AviSynth creation window for DGindex's MPEG2 deblocking and the ColorMatrix() filter. Those two improve a DVD/(H)DTV signal far more than crf 22 degrades it, so I get backups that look better than the originals.

You should also try out denoisers on noiser source, I'm partial to FluxSmoothST(), but be careful because sometimes the noise is the only thing hiding the blocking...

If I just had a QUAD core AMD I would just max everything and the heck with testing :)

Yup.

Suggestion: walk away from your encodes for a couple of days, then come back and just watch them as regular viewing rather than encoder testing. This may save you an awful lot of encoder time in future.

{edit: Also note that you will tend to prefer the second version in any A-B comparison, because your memory of the first helps your brain to process the second. This factor has screwed about a zillion hi-fi-/Tv/encoder comparisons over the years. So you need to go A-B-B-A or something like that. Whoever thought a certain Swedish supergroup would launch a comeback at Doom9?}

OvejaNegra
6th June 2006, 00:22
well:
After looking various encoded samples in different displays, i´m ok with Q22. It looks like XvidQ2, but using some psnr tools, q18 is more closer. But in the end your eyes are the judges.
I´m using q22 and 20 in the "special material" and the filesizes are very small compared with XVId. Of course, this is only my personal test.

Good luck
sorry for my english!!!

asarian
3rd June 2008, 02:33
I hope this is the right forum.

I've been experimenting with RipBot264 a bit, which uses x264. And I ran a transcoding of "2001, A Space Odyssy" (Bluray, VC-1) at is highest settings; most notably, a CRF of 18. To my shock, however, I noticed that certain black squares (outer space) get real 'blocky', like you're watching something run through DVDShrink, or a bad MPEG2 encoding. In fact, the whole file is < 10G! (which could be possible, as motion in this movie is rather slow, lol).

Is it possible I overdid it? I mean, is it possible to overdo it at all? I thought a CRF of 18 was always better. But elsewhere I read that this is just the case with real good source material. But could some spots really detetiorate that badly from having CRF = 18? That's awful!

Perhaps I'm still not undestanding the process in full (likely, as I'm as good as new to this). But I would appreciate some insight on the matter.

Thanks.

Dark Shikari
3rd June 2008, 03:10
I hope this is the right forum.

I've been experimenting with RipBot264 a bit, which uses x264. And I ran a transcoding of "2001, A Space Odyssy" (Bluray, VC-1) at is highest settings; most notably, a CRF of 18. To my shock, however, I noticed that certain black squares (outer space) get real 'blocky', like you're watching something run through DVDShrink, or a bad MPEG2 encoding. In fact, the whole file is < 10G! (which could be possible, as motion in this movie is rather slow, lol).

Is it possible I overdid it? I mean, is it possible to overdo it at all? I thought a CRF of 18 was always better. But elsewhere I read that this is just the case with real good source material. But could some spots really detetiorate that badly from having CRF = 18? That's awful!

Perhaps I'm still not undestanding the process in full (likely, as I'm as good as new to this). But I would appreciate some insight on the matter.

Thanks.Might I suggest you try Psy RDO (http://forum.doom9.org/showthread.php?t=13829)? One of its most powerful effects is eliminating blocking/banding in flat/dark backgrounds when encoding at the same bitrate.