View Full Version : Need a tip - which matrix is the best for 1000-1500kbps bitrate?
Fr4nz
7th October 2004, 09:26
Hi guys!
I'm relatively new to the XviD world. One thing that I like of XviD is its high grade of customization and the amount of detail given to the picture (IMHO more than DivX :) ).
I was playing with some custom matrices last night in order to find which is better @ 1000-1500kbps (so mid-low bitrates). I found that H.263 performs really well but there is also a matrix made by Sharktooth, EQM V3LR, which gives very good results to my eyes.
I tried also Didèes 6of9 matrices, but I wasn't happy with the quality they gave me.
So, could anyone suggest me some matrices that are good at these bitrates??
Thanks for any answer!
Teegedeck
7th October 2004, 11:01
When you ask something like that giving the resolution you use, too, is a very good idea! :)
AND the kind of material you encode.
Fr4nz
7th October 2004, 11:47
Oh sorry..well usually I encode at 720x304 or 720x4xx (I remove the black bars).
The material I encode depends on the film I encode ;)
Usually I go from action films, passing thru mixed action/quiet films, to very quiet films :D
Teegedeck
7th October 2004, 12:26
Hm, at that kind of resolution, SixOfNine-HVS looks best to me... but that's only me and my eyes - and using all features up to GMC. Maybe you would fare better with HVS-best-picture or the standard MPEG-matrix? Or possibly EQM V3LR really is the best of bunch already? Test it and have fun!
Fr4nz
7th October 2004, 12:36
I don't use GMC or QPEL because I want to preserve the compatibility with my stand-alone player (a kiss 450 :D ).
I tried also 6of9-HVS yesterday. IMHO it was good but not as good as EQM V3LR or H.263. Obviously we know that thse kind of things are really subjective! :)
Anyway I have another question: we know that MPEG matrix is good for preserving details but effective at high bitrates...so why you suggest me to use it at 1000-1500 kbps? Do you think it can give good results?
Didée
7th October 2004, 14:01
Ah. Doodads, bells'n'whistles not available for the sake of premature chipsets/firmwares ...
It could be that you're indeed better of with EQM-V3LR. Listen to the story.
Firstly, both 6of9 matrices will result in quantizers almost twice as big as when using EQM-V3LR. That's right and okay, but you definetly should use VHQ4 in XviD to compensate for that (because of some motion-search internals of XviD). What VHQ level *did* you use?
Secondly, 6of9's were designed for qpel usage ... I can tell nothing about how they perform w/out qpel, since I use qpel in 99% of all cases.
Thirdly. The 6of9 matrices keep some more high frequencies in places where HVS matrices already throw away. Of course that forces (a little) higher bitrate - or higher quantizers for a given target bitrate. Some people like that behaviour, in order to keep noise and grain intact at high enough bitrate.
But my original intention was another one. I mostly encode with slow & careful denoising, plus some slow & careful sharpening afterwards. Thusly, the stream to encode is >sharp<, and (almost) without any noise. In this case, the preferences of "which frequencies to keep, which to throw away" is a little shifted from average needs. In conventional encoding, targeting mediocre bitrates without (or with only weak) denoising, there's no chance anyways to keep noise|grain, and high frequencies are more safe to be cancelled, since keeping them would force way too much bitrate due to the noise. But on a very clean source, there is close to none bitrate penality from the noise (since there is none), and keeping the high frequencies becomes more important for producing a really sharp representation of what was fed into the encoder.
Hope that gives some ideas of what's going on.
BTW1: As long as you watch your final encodings on a phosphor TV, everything will look more or less equal, anyways ...
BTW2: EQM-V3LR should perform almost identical to the good old "HVS-better" matrix. The differences are only academic. ( ;) )
olavitur
7th October 2004, 16:09
You can also try Soulhunters V3.
JarrettH
7th October 2004, 17:35
I'd use SixOfNine=20 for that.:cool:
Teegedeck
7th October 2004, 18:30
*This is reminder that VHQ=4 is indeed the most important thing to use for lower-bitrate encodings.* :)
As mentioned above.
Why don't you do several first passes, using different matrices and then let the second-passes just go through the first two minutes or something of the movie and compare the results? (You do know that the first pass with SixOfNine(-HVS) should be done at quant=3?)
Fr4nz
7th October 2004, 18:54
Originally posted by Teegedeck
*This is reminder that VHQ=4 is indeed the most important thing to use for lower-bitrate encodings.* :)
Do you think that bitrates less than 1500 but more than 1100 kbps need a VHQ=4??
Usually I encode with VHQ=2 (in the official XviD guide is even suggested to use VHQ=1 for these bitrates...)
Why don't you do several first passes, using different matrices and then let the second-passes just go through the first two minutes or something of the movie and compare the results? (You do know that the first pass with SixOfNine(-HVS) should be done at quant=3?)
Ok, I'll try some more matrices to see which is better for my eyes! :D
PS: Do you think it is useful to use "trellis quantization"? Usually I use it...
Teegedeck
7th October 2004, 18:59
Originally posted by Fr4nz
Do you think that bitrates less than 1500 but more than 1100 kbps need a VHQ=4??
Usually I encode with VHQ=2 (in the official XviD guide is even suggested to use VHQ=1 for these bitrates...)
'Need', as everything else, is purely subjective... ;) The official guide is totally outdated (I know, I know; it's a shame...).
Fr4nz
7th October 2004, 19:26
Originally posted by Teegedeck
'Need', as everything else, is purely subjective... ;) The official guide is totally outdated (I know, I know; it's a shame...).
I read this guide: http://ronald.vslcatena.nl/docs/xvidfaq.html#A6
It was updated on the 25th September 2004, so it's quite recent :D
Teegedeck
7th October 2004, 19:56
OK, so I don't go along with Crusty on that one. :D
I bet he opted for VHQ=1 because of the speed penalty.
JarrettH
7th October 2004, 20:19
Maybe this is outdated news, but wasn't having a VHQ above 1 proven to be ineffective and a waste of time if your concern is quality?
I'll try to find the thread again.
PiXuS
7th October 2004, 20:20
Originally posted by Teegedeck
OK, so I don't go along with Crusty on that one. :D
I bet he opted for VHQ=1 because of the speed penalty.
I think Crusty's FAQ is great (I managed to grab the september 25th update too). I made tests for about a month using Doom9 guides and the recommendations from an older than 2004-09-25 Crusty's FAQ revision and came to the following conclusion:
The FAQ's and Guides are aimed at newbies who would like a fail-safe path to XviD encoding.
For example, in Crusty's FAQ it is written:
-Always use two-pass encoding. Don't mess with settings between passes, keep them the same for both passes.
I simply don't agree. 1-pass encoding with fixed quant gives better results picture quality wise. For exemple, SixOfNine @ q=4 kicks ass. Though, a newbie sure would like to be able to fix the file size and for that, 2-pass is a must.
-Only use target size, not target bitrate or quantizers.
Sure, for a 2-pass encode.
-VHQ: Use VHQ 1 on everything, possibly higher settings if you want 1 CD rips. VHQ 4 is perfectly safe, just slow.
Crusty says to use a high VHQ for low-bitrates. I sure do agree with that! Maybe Fr4nz considers 1500kbps high bitrate? Depends of the resolution of course... but he said he encodes @ 720x304. I don't think 1500kbps @ 720x304 is high-bitrate!
-Quantization Type: use H.263 for a softer image, or MPEG for a sharper image (at the expense of bitrate, not recommended for a 1CD rip). Either way, use the same one for both passes.
In the FAQ, the CQM are considered quasi-evil. Maybe it should be said that if one wishes to experiment, some CQM can do marvels (SixOfNine comes to mind!)
-B-frames are good, but don't go above 2 Maximum B-frames (so put the number 2 in the Maximum B-frames box (putting in 1 will result in the same as DivX's Max number of B-frames)). Keep all other B-frame settings at default.
I'll probably get blasted for saying that but until an official XviD 1.1 with VHQ for b-frames is released, I won't use 'em for backups.
-Don't mess with Interlaced encoding, greyscale, Debug settings, Curve compression, overflow treatment, GMC, Reduced Resolution, and Aspect Ratios. These settings are simply not for newbies; you need to understand them to use them properly.
I agree. Teegeedeck, I know you will tell me GMC is fine and all. I don't trust it. Sue me. ;-)
-Qpel is safe but slow. Always use it if you get undersized files, it will increase quality.
I agree. I always use QPel
-Use Gordian Knot to configure your rip and build your Avisynth files. Do not use Gordian Knot to do your encoding; Gordian Knot has no support for the new settings interface (yet; it's work in progress).
Also, do not use the compressibility test with Gordian Knot and XviD RC4; it doesn't work (properly).
Is this still relevant?
-When Encoding with XviD make sure the encoding program uses Resize values that are divisible by 16. That means that the end result has to have both a width and a height that are divisible by 16. For instance 640x480 = (40 x 16) x (30 x 16). Using anything else is not for newbies and could be Evil(tm).
I know mod16xmod16 res. are now considered pretty much safe, but I still only use mod32xmod16 res. for my own encodes.
Maybe this should be moved somewhere else....
PiXuS
JarrettH
7th October 2004, 20:24
It could have been a post by Didée; I've always found his explanations clear and insightful.:p
Fr4nz
7th October 2004, 20:29
Originally posted by PiXuS
Crusty says to use a high VHQ for low-bitrates. I sure do agree with that! Maybe Fr4nz considers 1500kbps high bitrate? Depends of the resolution of course... but he said he encodes @ 720x304. I don't think 1500kbps @ 720x304 is high-bitrate!
Maybe we could call it "medium bitrate" ? :D
JarrettH
7th October 2004, 20:30
I won't bother hunting for the topics, but it has been shown in recent comparisons where VHQ1 produced a better image than VHQ4 which produced a smearing effect. I wouldn't mind the speed penalty myself if the results actually looked better.
stephanV
7th October 2004, 20:35
Originally posted by JarrettH
I won't bother hunting for the topics, but it has been shown in recent comparisons where VHQ1 produced a better image than VHQ4 which produced a smearing effect. I wouldn't mind the speed penalty myself if the results actually looked better.
that was a bug in trellis IIRC... its fixed now.
Teegedeck
7th October 2004, 21:57
About two months ago, I once again compared VHQ=1 against VHQ=4 and the latter very clearly looked better. Me thinks, this feature works as it should. ;)
As a matter of fact, there's not many featues which I have doubts about right now. Perhaps I have doubts about the usefulness of greyscale and reduced resolution (which belongs to a different profile and shouldn't be used at all, anyway). But apart from that I can honestly say that I think these XviD devels are doing a pretty good job with XviD 1.1.
JarrettH
8th October 2004, 01:17
Can you link me, Teegedeck?
JarrettH
8th October 2004, 01:27
Here's something done on May 28, 2004 where VHQ1 looks better...
http://forum.doom9.org/showthread.php?s=&threadid=76974&highlight=vhq+compare
Is what you're talking about more recent?
Teegedeck
8th October 2004, 07:27
As I said 'about two months ago'; yes it was.
But I also did a quick test of the trellis fix back then. It is on the second page of that thread if you read on.
The detail you see on page two was encoded with VHQ=4 before and after the trellis fix. I think you notice that the smoothing, which affected Trelis + VHQ4, was gone after it. Subsequent private tests seem to show me a superiority of VHQ=4 over VHQ=1.
Sharktooth
8th October 2004, 09:06
I always use VHQ4. ALWAYS. :D
Sharktooth
8th October 2004, 09:17
Doh! i have missed this one:
Originally posted by Didée
BTW2: EQM-V3LR should perform almost identical to the good old "HVS-better" matrix. The differences are only academic. ( ;) )
Well, academic or not, they make some differences.
LR stays between HVS-better and HVS-best but with a better intra-frame quantization.
Fr4nz
8th October 2004, 09:41
Originally posted by Sharktooth
I always use VHQ4. ALWAYS. :D
It's very slow :(
I know, less speed for better quality....but at bitrates > 1300, with b-frames, trellis, chroma, etc., do you see the differences between VHQ=1 and VHQ=4?
Sharktooth
8th October 2004, 10:20
Well, i never used VHQ 1 so... uhm... i can't tell the differences.
Didée
8th October 2004, 11:11
Originally posted by Sharktooth
LR stays between HVS-better and HVS-best but with a better intra-frame quantization.
With a *lower* quantization for intra *blocks*.
(Intra quantization is not only for I-frames, but also for intra blocks in P-frames. Don't underestimate that - this block type is used quite frequently.)
Well, the argument "give a bonus to I-frames, so that the following P-frames benefit from a higher quality reference" has been given often enough. And it even made its way into XviD in form of the "I-frame boost" parameter.
Personally, I doubt that there are noticeable benefits from that strategy.
Regarding intra blocks in P-frames - these appear e.g. in regions with contradicting motion, like the borderline between "foreground-moving-right" and "background-moving-left". Here, it is likely that regions requiring I-blocks are present in not only one single frame, but over a sequence of frames instead. It is questionable if lower quantization on a intra-intra-intra-intra-... block sequence helps quality much. But for sure it is costing bits, raises overall bitrate, and consequently forces higher overall quantization on those sequences.
Mental note: perhaps it should be considered to take intra blocks into account as targets for adaptive quantization, too?
Regarding normal I-frames: the case is similar. Sure, lower quantization will provide a higher quality reference for the following P-frames. But alas, at the same time, there are less bits available to transport that higher quality over time ... better I's, worse P's.
Now I agree that this alone won't create any real drop of quality, since the additional bits for such a "better" I-frame probably will be compensated by only very few P-frames getting quantized stronger. However, it might result in a more pronounced "I-frame pumping" effect.
But there's another issue: Imagine a sequence with loads of I-frames, like in scenes with flashing lights. (Recently I encoded a music concert, where the whole stream contained almost 10% I-frames (!) ).
If such sequences occur, they might draw a good amount of additional bitrate due to the "better" quantization, but without producing a _perceptually_ better quality, therefore hurting the stream's overall quality by reducing available bits for the more easy parts.
(And don't say XviD's "I-frame reduction" option comes to a rescue - from _my_ experience, this feature is not working since a long time. It's just a NOP, sitting there, looking good, doing nothing.)
Conclusion:
Personally, I prefer to have equal quantization for both intra and inter blocks. If more bits for I-frames are required, they can still be forced by "I-frame boost". That way, the decision whether to throw more bits at the I-frames or not, is still up to the user, and not "hard forced" by the matrix. For me, the decision is "no."
Chainmax
9th October 2004, 02:16
What does the 1.1 branch need in order to warrant a public release?
Sharktooth
11th October 2004, 16:19
@Didée: Oh well, i didnt underestimate that.
I'm the one who trusts numbers (eheh) but i'm enaugh wise take my eyes into consideration.
I've read so much threads about HVS matrices where one stands "HVS Best is the best" and the other "HVS Better is better than HVS Best"...
I just made a "in between" matrix and i compensated a little glitch (lack of details in certain situations) with a slightly better intra frame quantization (not that much... look at the coefficients).
However i had a lot of positive feedback and im quite happy i could produce something usefull.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.