Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
18th October 2005, 12:06 | #42 | Link |
frying subs
Join Date: Jan 2003
Location: ch-2500
Posts: 891
|
What surprised me a bit is that the adaptive quantisation seems to work by "upping" the quality on bright areas (as compared to lower the quality in dark areas like i thought XviD did it).
I suspected this after doing a CQ (21) test with and without AQ. And while the one withou came out at 800 kbit/s the AQ one was 1400kbit/s (!). So i played the file and set ffdshow to show quantizers - and no longer surprisingly - a P frame supposed to be Q21 has the highest quantizer at 21 and the lowest one 12. A I frame (supposedly 18) even had blocks with quant 10 (that is the lowest allowed by the set Q range!). [edit] Encoding with CQ 26 and AQ gave me a file with almost the same bitrate as Q21 and no AQ (800.52 vs 800.75 kbit/s). Interestingly the one with out AQ has a mean PNSR almost 1dB higher and global PSNR ~1.2dB higher than the one with AQ. Also AQ seems to considerably raise the number of direct B macroblocks (2%->14%) and lower the number of skip B macroblocks (72%->42%). This is comparing the encodes with the same CQ (the one with adapted CQ 26 has 12% direct and 62% skip). [/edit]
__________________
-nyo Last edited by unmei; 18th October 2005 at 12:41. |
18th October 2005, 14:19 | #43 | Link |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
one word: multipass.
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! Last edited by Sharktooth; 18th October 2005 at 14:39. |
18th October 2005, 18:03 | #44 | Link |
frying subs
Join Date: Jan 2003
Location: ch-2500
Posts: 891
|
i know that word
But would you elaborate a bit more.. will AQ only work correctly in a multipass scenario? Because this seems not to be the case.. Of course in CQ with AQ the file size becomes kind of even less predictable, but from what i saw so far, CQ with AQ also seems to be an option when i raise the "constant" quant to compensate for the lower quants in some macroblocks.
__________________
-nyo |
19th October 2005, 08:56 | #46 | Link |
Moderator, Ex(viD)-Mascot
Join Date: Oct 2001
Posts: 2,564
|
AQ seems to work fine for strong compression. I tested with various constant-quantizer encodings of the same clip and found that encoding at quantizer=27 without AQ yielded a filesize just above that produced by quant=29 + AQ. The encode at quant=27 without AQ exhibited extensive blocking (deblock=-1) while the one with AQ didn't and thus looked very acceptable, I daresay 'good'.
This should mean AQ makes the higher quantizers in x264 really worthwhile for the first time - because with AQ it's not necessary anymore to use strong deblocking that turns the whole picture into jelly. Well done, Haali!
__________________
It's a man's life in Doom9's 52nd MPEG division. "The cat sat on the mat." ATM I'm thoroughly enjoying the Banshee - a fantastic music player/ripper for Linux. Give it a whirl! |
21st October 2005, 22:02 | #47 | Link |
Registered User
Join Date: Apr 2004
Posts: 1,315
|
--chroma-qp-offset <integer> QP difference between chroma and luma.
I couldn't fine any information about it. When it's usefull to use this feature? At low bitrates? What are admissible integers numbers of interval --chroma-qp-offset [x,y]? |
22nd October 2005, 11:41 | #49 | Link |
frying subs
Join Date: Jan 2003
Location: ch-2500
Posts: 891
|
Maybe this is totally obvious to anyone but me, but since it was not for me i thought i would mention it: Adaptive Quantisation will not only produce quantisers in the set QP range (QPmin, QPmax).
Probably i just had the wrong concept of these and they do not represent the actual quantizer limits but the limits of average quantizer in P frames (or something along that line). I'm currently playing with the AQ and CQ vs CRF settings and let the QP range at default [10,51]. What i found so far are Q8 blocks in all frame types (I,P,B) ..and they are not rare at all, they might make up like a third of the frame. Note that this is not a complaint, just a statement So far i really like the one movie i did completely with AQ and CQ 26 and as long as the result looks good i am not "against" low quantised blocks. Tho i might turn down the AQ strength a bit for the next movie (0.3 maybe), that is i do these tests right now to get a feeling of the AQ parameters.
__________________
-nyo |
29th October 2005, 21:58 | #50 | Link |
Registered User
Join Date: Mar 2005
Location: Ontario, Canada
Posts: 23
|
And here goes the first complaining about x264... When i pressed x264 uninstall it started deleting all my system32 dll files and the windows recovery thing showed up, next thing i restart windows is not working or shit. Fix this issue, i don't intend to reinstall windows for this.
|
8th November 2005, 01:57 | #52 | Link | |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
Quote:
But it seems to only work with "I Frames". Is that correct?
__________________
http://www.7-zip.org/ |
|
8th November 2005, 02:35 | #54 | Link |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
Well it's just that when encoding I always get psnr return figures of say,
Y=45 U=48 V=50. So I tried increasing the Chroma-qp-offset to 12. From memory it only seemed to greatly affect the I frames. P,B Frames still had larger psnr values for chroma. I'm in the middle of a large encode ATM, so it will be 2-3 hours before I can confirm.
__________________
http://www.7-zip.org/ |
8th November 2005, 02:46 | #55 | Link |
x264 developer
Join Date: Sep 2004
Posts: 2,392
|
What was the qp? Above qp=28, chroma_qp doesn't increase as fast as luma_qp, and it maxes out at luma_qp=51, chroma_qp=39. chroma_qp_offset is added to the lumna_qp before converting it to the chroma scale, so no amount of chroma_qp_offset will reduce chroma quality beyond 39.
|
8th November 2005, 05:58 | #56 | Link |
Registered User
Join Date: Nov 2003
Posts: 1,281
|
I just tried another encode, ensuring low quants.
And Chroma-qp-offset made an impact on PSNR. Pass1. Code:
C:\Program Files\x264>x264.exe --pass 1 --bitrate 2000 --stats "F:\2pass.log" --bframes 2 --b-pyramid --weightb --analyse p8x8,b8x8,i4x4 --chroma-qp-offset 12 --threads 2 --progress --frames 2000 --output NUL "F:\test.avs" avis [info]: 704x288 @ 25.00 fps (7063 frames) x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 x264 [info]: slice I:47 Avg QP:15.06 size: 23452 PSNR Mean Y:49.06 U:45.86 V:46.75 Avg:47.88 Global:47.48 x264 [info]: slice P:1225 Avg QP:17.51 size: 12292 PSNR Mean Y:46.29 U:44.57 V:45.45 Avg:45.78 Global:45.47 x264 [info]: slice B:728 Avg QP:18.87 size: 5991 PSNR Mean Y:45.13 U:44.46 V:45.02 Avg:44.95 Global:44.54 x264 [info]: mb I I16..4: 17.3% 0.0% 82.7% x264 [info]: mb P I16..4: 11.3% 0.0% 26.5% P16..4: 24.1% 21.2% 11.2% 0.0% 0.0% skip: 5.7% x264 [info]: mb B I16..4: 2.4% 0.0% 5.3% B16..8: 50.1% 5.0% 10.9% direct: 5.9% skip:20.3% x264 [info]: PSNR Mean Y:45.930 U:44.562 V:45.326 Avg:45.529 Global:45.139 kb/s: 2052.16 encoded 2000 frames, 18.22 fps, 2053.30 kb/s Code:
C:\Program Files\x264>x264.exe --pass 2 --bitrate 2000 --stats "F:\2pass.log" --bframes 2 --b-pyramid --weightb --analyse p8x8,b8x8,i4x4 --chroma-qp-offset 12 --threads 2 --progress --frames 2000 --output "f:\test1.mkv" "F:\test.avs" avis [info]: 704x288 @ 25.00 fps (7063 frames) x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 x264 [info]: slice I:47 Avg QP:15.66 size: 21978 PSNR Mean Y:48.69 U:45.71 V:46.50 Avg:47.61 Global:47.37 x264 [info]: slice P:1225 Avg QP:17.49 size: 12149 PSNR Mean Y:46.29 U:44.60 V:45.46 Avg:45.80 Global:45.59 x264 [info]: slice B:728 Avg QP:18.97 size: 5666 PSNR Mean Y:45.08 U:44.40 V:44.88 Avg:44.90 Global:44.66 x264 [info]: mb I I16..4: 18.2% 0.0% 81.8% x264 [info]: mb P I16..4: 11.6% 0.0% 25.7% P16..4: 25.2% 21.2% 10.4% 0.0% 0.0% skip: 6.1% x264 [info]: mb B I16..4: 2.2% 0.0% 5.4% B16..8: 50.4% 3.8% 8.3% direct: 6.8% skip:23.2% x264 [info]: PSNR Mean Y:45.905 U:44.553 V:45.271 Avg:45.513 Global:45.263 kb/s: 2004.07 encoded 2000 frames, 20.34 fps, 2005.21 kb/s
__________________
http://www.7-zip.org/ |
8th November 2005, 19:38 | #57 | Link | |
<The VFW Sheep of Death>
Join Date: Dec 2004
Location: Deathly pasture of VFW
Posts: 1,149
|
Quote:
I'm terribly sorry for your loss (of Windows, time, and respect for the x264 package).
__________________
Recommended all-in-one stop for x264/GCC needs on Windows: Komisar x264 builds! |
|
9th November 2005, 11:18 | #58 | Link | |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
Quote:
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
|
9th November 2005, 18:41 | #60 | Link |
Mr. Sandman
Join Date: Sep 2003
Location: Haddonfield, IL
Posts: 11,768
|
Well... something screwed your registry then. The uninstaller only removes the x264 installation dir that's stored in a registry key... if "something" (virus,program,whatever) modified the path in that registry key or if your windows registry is screwed than it's not my fault.
__________________
MPEG-4 ASP Custom Matrices: EQM V1(old), EQM AutoGK Sharpmatrix (aka EQM V2), EQM V3HR (updated 01/10/2004), EQM V3LR, EQM V3ULR (updated 04/02/2005), EQM V3UHR (updated 17/12/2004) and EQM V3EHR (updated 05/10/2004) Info about my ASP matrices. MPEG-4 AVC Custom Matrices: EQM AVC-HR Info about my AVC matrices My x264 builds. Mooo!!! |
|
|