View Full Version : How useful is VHQ4 in your encodes?
JohnMK
27th May 2004, 21:52
If you've compared the file size of your encodes in VHQ4 vs. 1, and have the results handy in % difference, please post here. I'm trying to determine generally how useful VHQ4 is for other people.
My anecodte:
VHQ4/1: 1058MB vs. 1089MB
Hollywood-style movie, modern, clean, 2 hours long. GMC, QPel, low quants (2's and 3's mostly), hvs-best custom matrix, turbo mode, 2 b-frames with default settings, anything else pertinent that I'm forgetting?
This is a 3% reduction in file size for about a 50% reduction in encoding speed on my machine (P4 HT).
Tommy Carrot
27th May 2004, 22:05
VHQ4 in my experience reduces the ringing artifacts quite nicely (or at least i imagine it :)), so for this reason i use it defaultly, as i find ringing very irritating.
Blue_MiSfit
27th May 2004, 22:38
i see it like this:
I usually let the comp encode all night. VHQ4 seems to enhance the quality of the video quite a bit for me. It really minimizes blocking and haloing. as such it is definatley worth it to me. Turning it off wont make me wake up earlier if you know what i mean.
RadicalEd
27th May 2004, 22:41
[edit]Redid test.
Settings are now default minus bframes, still quant 2.Since I guess it's relevant to speed optimizations, I'm on an old Athlon tbird. 1Ghz and decoding from a helix yv12 encoded avi, for further speed info.
VHQ|Speed (s)|Size (bytes)|__% time_____________|% compression
0____6________3,907,584_______100%_______________0%
1____8________3,745,792_______133%_______________4.14%
2___12________3,717,120_______200%(150%)_________4.87%(0.77%)
3___16________3,708,928_______267%(130%)_________5.08%(0.22%)
4___21________3,700,736_______350%(131%)[263%]___5.29%(0.22%)[1.20%]
Parenthensese are the percentages against the previous level (normal % are against 0). The bracketed values under VHQ 4 are percents against VHQ1.
aketon
27th May 2004, 23:54
I have noticed some artifacts when I use VHQ4! I encoded "GLADIATOR" once with VHQ1 and then with VHQ4! After a very closer look in some action scenes, I saw that VHQ4 produced more artifacts than VHQ1! I know that this thing sounds a little bit crazy, but I couldn't believe it either! The most funny part is that when I used both VHQ1 and trellis, I had much better quality than VHQ4! That's my opinion although!
temporance
28th May 2004, 03:56
I have a related question: There are seven motion search precision settings and five VHQ modes. That makes 35 permutations. Add in other settings such as chroma mode, turbo, trellis and you have more than 100 permutations.
I would like to decide on a few (say four) permutations which give good performance and represent a good spread over the encoding speed / quality spectrum.
Does anyone have any favorite combinations of these settings?
TIA
Jawor
28th May 2004, 08:31
I can't post any numbers here, since I made no such comparison lately, but at a fixed target size I can clearly see the difference between VHQ=1 and VHQ=4. VHQ=4 is terribly slow on a Celeron 1200 MHz :( , but I use it anyway - it RULEZ!
JasonFly
28th May 2004, 08:55
I have a question about the use of VHQ.
I have an .avs which is so slow that I change my mind between the 2 XviD pass and decided to switch between VHQ1(in 1st pass) and VHQ4(in 2nd).
Regarding the speed optimizations in the first pass(i suppose they had something to do with vhq, qpel, gmc and some other slow calculations), does the VHQ number has an importance in 1st pass?
If this wasn't clear enougth, i reformulate:
Can I switch/change VHQ between two pass?
Didée
28th May 2004, 09:56
> Can I switch/change VHQ between two pass?
Yes. It's not 100% optimal, but the difference is minor.
1st pass is there to get the framesizes & frametypes for the 2nd pass. Since the actual size difference between VHQ1 and VHQ 4 is not that big, you can rely on XviD's rate control to compensate for it.
If you do so, it might be a good idea to alter the overflow settings a little:
1st=VHQ1, 2nd=VHQ4 - leave "degradation" at [your setting], and bump up "improvement" & "strength" by 50%.
In the opposite case, 1st=VHQ4, 2nd=VHQ1 (why ever do that? "Oh, 2nd-pass takes too long, but I have to get that train!"), do the opposite: leave "improvement", and bump "degradation" and "strength".
Personally, I won't recommend the "20/20/20" thingie - but that's just my picky preferences ;)
- Didée
sysKin
28th May 2004, 10:14
Originally posted by JasonFly
Can I switch/change VHQ between two pass? VHQ is automatically disabled in first pass - so don't worry if it was enabled in 1st pass or not, pass was identical.
Radek
Didée
28th May 2004, 10:33
Originally posted by sysKin
VHQ is automatically disabled in first pass - ...
... unless your 1st-pass was set up to be a zone using a fixed quantizer.
But admittedly, I was thinking within the (un-)restrictions of my usual methods, and forgot a little about the default behaviour :o
Sorry, Jason.
Syskin, thanks for clearing up that half-nonsense I produced.
- Didée
JimiK
28th May 2004, 12:12
Originally posted by sysKin
VHQ is automatically disabled in first pass ...
...if you don't choose a full quality first pass :) I do it at full quality, because when the file is not too big, I just keep it to burn it to DVD.
O.K., what I really wanted to ask is: can anybody confirm aketons observation? I can't imagine being that true, because there was a lot of testing and debugging going on, before Xvid was labeled 1.0. I use VHQ4, because I think it reduces swimming in the background. (Did not yet have the time to test the improvements of version 1.1 yet, but I'm rather curious about the results)
Best regards,
JimiK
stephanV
28th May 2004, 12:25
Originally posted by JimiK
O.K., what I really wanted to ask is: can anybody confirm aketons observation?
aketon has seen it, so he can post screen-shots no? would be helpful for everybody...
Teegedeck
28th May 2004, 12:26
Screenshots! Screenshots!:)
Seriously, when anyone claims to have discovered something startling it would be most useful if he/she posted screensots, avs-file and XviD setup.
aketon, can you please encode a clip at constant quantizer, once with trellis and vhq=1 and once with trellis and vhq=4? Then, please load the results into VDub and do some snapshots where you discover artefacts or other interesting differences.
Alternatively, if you still have both your Gladiator encodes, load them via avs ("directshowsource") so we can view the frame quantizers, too, with ffdshow's 'OSD' function. Would be greatly appreciated.
gatormac
28th May 2004, 14:34
Originally posted by sysKin
VHQ is automatically disabled in first pass - so don't worry if it was enabled in 1st pass or not, pass was identical.
Radek
If it is disabled for 1st pass is it disabled for single pass as well?
sysKin
28th May 2004, 15:07
Originally posted by gatormac
If it is disabled for 1st pass is it disabled for single pass as well? No, just 1st pass - and just like everyone pointed out, I should have said "1st pass that is not full quality and uses weight zone".
@aketon - when was that? I don't believe that was any 1.0.x.
@all - when you compare VHQ1 vs VHQ4, don't look at filesize. I could easly re-tune VHQ to produce quite a big range of filesizes - current tuning is for maximum PSNR and it just so happens that this setting reduces bitrate at fixed quant by such a fraction. Could make it equal.
Radek
kilg0r3
28th May 2004, 15:18
Originally posted by sysKin
current tuning is for maximum PSNR Which makes me nagging for a retuning of VHQ for maximum SSIM or - which would be even better - for maximaly positive subjective experience. :D For this we would only have to set up a test that equals Roberto's audio tests. A collection of clips encoded with different tunings of VHQ and here we go! Don't you say this would too much of a hassle ;)
aketon
28th May 2004, 15:19
OK! I don't have "GLADIATOR" right now (he had an accident:( ), but I had done some tests with "INTOLERABLE CRUELTY", and after at some tests I still see vhq-1 and trellis to preserve more quality than vhq-4 and trellis! The codec I used to encode "GLADIATOR" was Xvid 1.0 RC4 !!!
Does anybody know how to post some the pictures???
stephanV
28th May 2004, 15:23
you can upload them here (http://www.imageshack.us/) and then provide links or use the image tags. :)
(go easy on the JPG-compression or use png if you can ;) )
aketon
28th May 2004, 16:20
HERE IS MY TEST!!!!!!
Codec: XviD 1.0 final Koepi
---------------------------
Settings:
---------
VHQ-1 clip:
default settings
quantizer 8
VHQ 1
trellis on
VHQ-4 clip:
default settings
quantizer 8
VHQ 4
trellis on
-----------
MY IMAGES:
sCREENSHOT 1:
ORIGINAL
http://img11.imageshack.us/img11/3308/first-original-coded.png
VHQ-1 TRELLIS ON
http://img11.imageshack.us/img11/4097/first-vhq-1-coded.png
VHQ-4 TRELLIS ON
http://img11.imageshack.us/img11/7271/first-vhq-4-coded.png
If you look carefully at the trees, you will see that VHQ-4 smooths
much more than vhq-1!
Imagin now the same smoothing on a wall with a lot of detail (from stones)!
In "GLADIATOR" the differnces were even more bigger! VHQ-1 keeped all the
details in most of the action scenes in the arena on the walls, where VHQ-4 smoothed
everything!
SCREENSHOT 2:
ORIGINAL
http://img11.imageshack.us/img11/5811/second-original-coded.png
VHQ-1 TRELLIS ON
http://img11.imageshack.us/img11/8626/second-vhq-1-coded.png
VHQ-4 TRELLIS ON
http://img11.imageshack.us/img11/9696/second-vhq-4-coded.png
Look at the trees near the sky again! VHQ-4 smoothes much more than VHQ-1!
Look at the grass the details! The original picture has a white thing in
the middle of the grass! In VHQ-1 is a little bit smoother! In VHQ-4 the
white thing dissapears!
sysKin
28th May 2004, 16:28
Trellis is b0rked!
Unfortunately (fortunately?) after 1.0.0 was out, many smart people started looking at its code and some bugs were found. Most is minor, but unfortunately one is big - in trellis.
:(
Radek
hmmm..what really stands out imho is that patch on the grass.
it's nearly gone in the last vhq4 frame.
stephanV
28th May 2004, 16:38
@aketon:
if it is not too much trouble, could you do the same test with trellis off then? (since it is broken!) :rolleyes:
thank you vey much in advance! :)
aketon
28th May 2004, 17:21
I have noticed something even more strange now with trellis off!
For example:
Let's say that I am at frame 100 of the avs script in virtualdub! At the same frame the encoded video with vhq-1 seems to preserve much more detail than vhq-4!
In the next frame 101, vhq-4 preserves more quality than vhq-1! In frame 102 vhq-1 preserves again more quality than vhq-4! And so on!
It is really strange, I can't understand why this thing is happening! I think that b-frames might getting involved in this!
I hope that I am not the only one who see this!
aketon
28th May 2004, 17:51
I've just made some tests with trellis and b-frames off! The results are as I expected to be! VHQ-1 preserves more quality than VHQ-4! In some cases VHQ-4 eat details and produce more blockiness! Please do some tests with quantizer 8! You are going to see too many strange things between VHQ-1 and VHQ-4!
bye!
JasonFly
28th May 2004, 17:51
Syskin, sorry to bother you again:
As you said that trellis was borked, can I disable it for the second pass if it has been enable for the first :D
sysKin
28th May 2004, 18:32
Originally posted by JasonFly
Syskin, sorry to bother you again:
As you said that trellis was borked, can I disable it for the second pass if it has been enable for the first :D Yes you can, trellis was not really enabled in the first anyway.
JohnMK
28th May 2004, 19:03
Should we use trellis quantization?
Teegedeck
28th May 2004, 19:06
Originally posted by sysKin
Trellis is b0rked!
Unfortunately (fortunately?) after 1.0.0 was out, many smart people started looking at its code and some bugs were found. Most is minor, but unfortunately one is big - in trellis.
:(
Radek
Owwwww; so it really was something grave? And just recently I said 'on the use of trellis, I blindly trust sysKin'. :D
Anyway, it still had a positive effect, and it's nice to hear that it will gett better. :) (Now, why do other people say I always look on the dark side of things?)
gatormac
28th May 2004, 19:38
@ aketon
Please post some of your non-trellis frames that you talk about. In your trellis enabled encodes I see the smoothing effect, but I also notice more blockiness in your VHQ1 encode resulting in a poorer image than the VHQ4 encode regardless of the smoothing (everyone has their preferences).
Also, could this just be an issue at low bitrates? I wouldn't encode a video for my dog to watch at a constant quantizer of 8.
aketon
28th May 2004, 22:08
In higher bitrates, I can't really say that I see so much difference between VHQ-1 and VHQ-4! But I have seen VHQ-4 producing strange artifacts in some movies, but I can't prove it right now! Sorry for not helping you much! As I can't prove you something without pictures, then only thing I can tell you right now is, to be carefull where you use VHQ-4!!!
Prettz
29th May 2004, 23:38
aketon: In both of your example screenshots I thought that the VHQ-4 pic looked much better overall. True there was a tiny bit more smoothing, but the overall picture impression was far better for me with the VHQ-4 version.
JohnMK
30th May 2004, 01:31
Wow, I quite disagree. I like highly detailed images. If I want a smoothing effect I'll hire a filter specifically for that purpose.
OUTPinged_
30th May 2004, 09:58
@sysKin
So, a bigfix release of xvid is nearby?
JohnMK
30th May 2004, 10:27
It's already done, you just have to wait for somebody to be nice enough to compile it for us. Check out Cruncher's thread.
Didée
30th May 2004, 16:56
Regarding aketon's screenshots on page 1:
I would bet some money that the VHQ1-frames are P-frames, and the VHQ4-frames are B-frames.
- Didée
lordadmira
31st May 2004, 13:11
This whole discussion has me somewhat confused since VHQ has nothing to do with compression. It physically can't result in the kinds of artifacts being talked about. VHQ involves motion vector scenarios. The higher the VHQ setting the more scenarios it tries to find the best one. Am I wrong? I think this whole thing is actually about the trellis bug.
LA
Arcon
1st June 2004, 01:46
Originally posted by sysKin
Most is minor, but unfortunately one is big - in trellis.
is there any chance that a rip made with trellis wont be b0rked? or is this bug always present regardles of the other options and leading to a suboptimal result if you enable trellis (which i did for the last 4 encodes i did with xvid 1.0.0 :()?
sysKin
1st June 2004, 02:04
Originally posted by Arcon
is there any chance that a rip made with trellis wont be b0rked? or is this bug always present regardles of the other options and leading to a suboptimal result if you enable trellis (which i did for the last 4 encodes i did with xvid 1.0.0 :()? It seems that trellis still helps, just not as much and as well as it should.
Don't worry about the results too much - they could be better without the bug, but, well, you can see them with your eyes - not *horribly* wrong are they? ;)
Trellis was shown to help in the past, and it has had this bug all the way before 1.0 was even available. This is not specific to 1.0.0 final.
Radek
Arcon
1st June 2004, 02:29
Originally posted by sysKin
It seems that trellis still helps, just not as much and as well as it should.
somehow this sounds much better to me than "UGLY TRELLIS BUG" :)
Originally posted by sysKin
Trellis was shown to help in the past, and it has had this bug all the way before 1.0 was even available.
so even all the rc's had it? then i really dont care :D
sysKin
1st June 2004, 03:17
Originally posted by Arcon
somehow this sounds much better to me than "UGLY TRELLIS BUG" :)Well it is ugly (from the code's point ov view), it is in trellis, and it is a bug :D
so even all the rc's had it? then i really dont care :D Yes, it's a bug that still made xvid won the codec comparison 5 months ago. It all just simply means, xvid will get even better soon (or now, if you d/l fixed version).
:D Radek
RadicalEd
1st June 2004, 03:50
Can you go into specifics about the bug? I know it's probably on the ML or something, but I haven't checked my email in months and I'm afraid to try :|
sysKin
1st June 2004, 05:28
Originally posted by RadicalEd
Can you go into specifics about the bug? I know it's probably on the ML or something, but I haven't checked my email in months and I'm afraid to try :| Okay. When (and only when) trellis does find optimized coefficients, it is re-constructing a block of DCT data, using the best path found. When doing so, it also calculates the sum of all coefficients, which is needed later.
It was forgetting the last coefficient in the sum.
The sum is in fact only used for one thing - to test if block contains data (sum != 0) or does not. If there are many coefficients, sum is not zero, regardless of the fact it isn't correct. No problem there.
If, however, there was only one coefficient (which was also the last), the sum was zero even if trellis had decided that this coefficient is important. Such block would not be coded. Sure this would save some bits, but if trellis says that this coefficient should not be dropped - the quality cost is bigger than bitrate saving.
Note that this coefficient might in fact have a really high magnitude - if it's alone, it is dropped by the buggy code. This means an artifact.
So, expect slightly bigger filesize at fixed quantizer after the fix, with a quality gain that outweights it.
Radek
Teegedeck
1st June 2004, 07:30
In fact the fix really has visible effects. Quite a bit sharper (better detail preservation). In consequence you might also be able to spot MB boundaries better - but only when zooming the picture, so I don't deem it important.
old
http://img52.photobucket.com/albums/v158/Teegedeck/old_trellis.png
new
http://img52.photobucket.com/albums/v158/Teegedeck/new_trellis.png
JohnMK
1st June 2004, 08:05
I don't see any difference there . . .
Teegedeck
1st June 2004, 08:36
Open both pics in an instance of an image viewer like irfanview, then switch between the instances with alt-tab. Need I mention that you don't have to worry about such things if you don't watch your stuff on a TFT? ;)
JohnMK
1st June 2004, 17:36
Does MPEG-4 look worse on LCD monitors vs. CRTs?
RadicalEd
1st June 2004, 23:05
Actually, it looks deceptively better ¬_¬
That's only applicable to shadow mask CRTs, of course. I could plot pixels on this beautiful apeture grille of mine :D
Teegedeck
2nd June 2004, 07:58
The sharpness of a TFT makes good encodings look better, bad encodings look worse. Consequently, it makes it easier to distinguish between these two.
kurt
15th June 2004, 12:40
back to the trellis bug: the latest 1.1 build is fixed now? i found nothing about this in the changelogs...
so should i turn trellis off in the meantime? :confused:
Arcon
15th June 2004, 12:53
Originally posted by kurt
the latest 1.1 build is fixed now? i found nothing about this in the changelogs...
Changelog:
XviD-1.0.1-05062004:
- (core) small trellis bug which probably reduced sharpness of the image,
but possibly even produced artifacts
kurt
15th June 2004, 13:13
ok, xvid 1.0 is fixed, but what about the latest gamrdev-build (1.1)?
(http://xvid.gamrdev.com/)
communist
15th June 2004, 16:42
If it is fixed in 1.0.1 why should it not be fixed in '1.1'? :confused:
Jawor
16th June 2004, 15:54
The code from CVS head isn't actually XviD 1.1 yet.
AFAIK Trellis code is only in src/utils/mbtransquant.c and it looks identical in release-1_0-branch and in CVS head (14.06.2004), so Trellis should be fixed in my CVS head builds from 14.06.2004 (VBV disabled) and 15.06.2004 (VBV enabled).
Teegedeck
16th June 2004, 16:57
My two screenshots - before trellis-fix, after trellis-fix - were from a CVS-head build. So definitely something was fixed and I'd bet it's trellis. ;)
kurt
16th June 2004, 21:40
this is, what i wanted to know :D :D
vBulletin® v3.8.4, Copyright ©2000-2009, Jelsoft Enterprises Ltd.