Log in

View Full Version : Test Results - XviD vs H.264 vs x264 vs RealVideo 10


Pages : 1 [2]

foxyshadis
19th September 2006, 02:11
Oops, I was just going from memory of the last page when posting, sorry. Edited.

Seraphic-
19th September 2006, 07:58
Xvid Settings:
Quantization-H.263
Qpel-on
AQ-on
3 bframes - no offset, multiplier of 1.62
VHQ 4, VHQ for Bframes-on
MSP-6

X264 Settings:
subpixel refinement-6, Hex motion search, turbo enabled
All Bframes options, 3bframes, No Bprediction
High Profile, All partitions, cqm used, -2:-4 inloop, 5 mixed refs
min IDR Frame interval 48, max 240
No Fast P-Skip, and No DCT Decimation enabled

2500 Kbps:
Xvid (http://download.yousendit.com/7EB2431216C6E72C)
X264 (http://download.yousendit.com/7FB362BD10A44918)

5000 Kbps
Xvid (http://download.yousendit.com/1F2FDEE846ED7B9E)
X264 (http://download.yousendit.com/9C2F4E771ECB253E)

The files are bigger/lower quality since this sample was made from only the very dificult 999 frame sample. Xvid Files are smaller because of Xvids not-so-great ratecontrol, and my laziness in not doing multiple encodes to get it right.

Hi,

For x264, did you use a base setting of HQ-Insane then make the changes listed above? Also, what kind of encode time are we talking here per minute?

*.mp4 guy
19th September 2006, 13:33
Those changes were made to the default settings, not that it really matters, I changed almost everything. It should run significantly faster then HQ insane. No Idea on encode time per minute, its about 2/3rds as fast as Xvid with the settings I used for it, so its reasonably fast for H.264 encoding.

Sharktooth
19th September 2006, 13:39
the HQ-Insane in the new MeGUI profiles (v32) is now really insanely slow...
however there's no need to use that profile for comparative tests coz it really uses settings that hardly any user will choose for encoding...

elguaxo
20th September 2006, 22:27
the HQ-Insane in the new MeGUI profiles (v32) is now really insanely slow...
however there's no need to use that profile for comparative tests coz it really uses settings that hardly any user will choose for encoding...

Can those 'insane' settings hurt the quality of an encode or are they just insanely slow?

Sharktooth
21st September 2006, 12:53
They're insanely slow trying to squeeze the maximum compression.
Usually more compression = less filesize... that leads to a better quality at a predefined bitrate, but sometimes trying to compress too much can kill some fine details (an example is VHQ-1/VHQ-2 vs VHQ-4 in xvid).
That happens when using high bitrates (btw in that case you dont need the maximum compression).

elguaxo
21st September 2006, 20:44
They're insanely slow trying to squeeze the maximum compression.
Usually more compression = less filesize... that leads to a better quality at a predefined bitrate, but sometimes trying to compress too much can kill some fine details (an example is VHQ-1/VHQ-2 vs VHQ-4 in xvid).
That happens when using high bitrates (btw in that case you dont need the maximum compression).

Thanks for the hint!

Prettz
22nd September 2006, 04:40
They're insanely slow trying to squeeze the maximum compression.
Usually more compression = less filesize... that leads to a better quality at a predefined bitrate, but sometimes trying to compress too much can kill some fine details (an example is VHQ-1/VHQ-2 vs VHQ-4 in xvid).
That happens when using high bitrates (btw in that case you dont need the maximum compression).
What kind of bitrates are you talking about? Does that possibility also apply to regular/HQ/both quant matrices? I just want to make sure I don't need to take a second look at one of my DVD rips (which was all about preserving every last fine detail), as I haven't heard any complaints about VHQ-4 until now actually.

Sharktooth
22nd September 2006, 12:40
The bitrate, as usual, depends on the source, so there's no magic treshold...
VHQ-2 usually preserves fine details better than VHQ-4 at high bitrates, and yes, it's true even when using CMQs.
The more you tell the codec to compress and to optimize for R/D the more the chances it kills details in favour of PSNR (or other metrics).
So when you have enough bitrate, "overcompressing" is not healty...