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. |
|
|
Thread Tools | Search this Thread | Display Modes |
8th October 2009, 17:53 | #2421 | Link | |
Registered User
Join Date: Apr 2006
Posts: 1,008
|
Quote:
|
|
8th October 2009, 18:13 | #2422 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
2. MB-Tree RC redefined the CRF scale and generally reduces the bitrate requirement (that is: it retains better quality at same bitrate, or same quality at lower bitrate). Maybe you are comparing a MB-Tree RC encode to an old encode that was done without MB-Tree ???
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
8th October 2009, 18:23 | #2423 | Link | |
Registered User
Join Date: Apr 2006
Posts: 1,008
|
Quote:
The Source incldues a lot of Scenes with heavy Grain so i was suprised that the average Bitrate/Filesize is so low with crf 18. Yes, some old encdes without MBtree have higher Bitrate/Size at CRF 18 so i cant compare it with ne MBtree encodes. Maybe i should go down to crf 16 or 17 THX for your help |
|
8th October 2009, 18:27 | #2424 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Nobody can tell you what CRF values give acceptable quality for you, because this is highly subjective!
Simply use the highest possible CRF value that still gives good results for your eyes. If CRF 18 looks good for you, then no need to go any lower. But if it looks bad for you, don't hesitate to try CRF 17 or 16
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
8th October 2009, 18:42 | #2425 | Link | |
Registered User
Join Date: Apr 2006
Posts: 1,008
|
Quote:
I want the same Quality/Size. CRF was only a thought because it works faster. I will test it . THX |
|
8th October 2009, 18:57 | #2426 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
So you should adjust the CRF value until you get the desired quality instead of modifying it until you hit a specific bitrate. For the latter case we have 2-Pass mode
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
9th October 2009, 21:14 | #2427 | Link |
Registered User
Join Date: Aug 2008
Location: Minsk, Belarus
Posts: 235
|
Hey, guys, gcc-miscompiling-saga again...
I have tested unpatched builds again and found the following results: Code:
1281 builds: x264.nl gcc 3.4.6 -- OK BugMaster gcc 4.3.3 TDM -- OK BugMaster gcc 4.3.4 20090220 (prerelease) (x32.generic.Komisar) (not profiled) -- OK Komisar gcc 4.3.4 (x86_64.core2.Komisar) -- OK Komisar gcc 4.3.4 (x86.generic.Komisar) -- OK Komisar gcc 4.4.1 (x86.core2.Komisar) -- FAILURE JEEB gcc 4.3.4 20090220 (prerelease) (x64.generic.Komisar) -- FAILURE techouse gcc 4.4.1 (x86_64.core2.Komisar) -- FAILURE rack04 (patched build) gcc 4.3.4 (x86.core2.Komisar) -- FAILURE Last edited by komisar; 9th October 2009 at 22:13. |
9th October 2009, 22:12 | #2428 | Link |
もこたんインしたお!
Join Date: Jan 2008
Location: Finland / Japan
Posts: 512
|
Oh nice~
Thank you for your information, I'll get to building a new GCC and a new x264 as soon as I'll get home :/ Kind of hatin' the whole miscompilation stuff. In short: *censored* (Holy Hanyuu I hate these cases)
__________________
[I'm human, no debug]
|
9th October 2009, 23:16 | #2430 | Link |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Komisar, how exactly do you test the builds? And does "FAILURE" mean crash, bad output or what? How would I realize?
BTW: Did anybody else test GCC 4.4.1 TDM-2 yet?
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 10th October 2009 at 01:07. |
10th October 2009, 12:11 | #2432 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
1. Unexpected crash -> easy to detect and easy to fix (re-build until it stops crashing) 2. Bad output -> hard to detect, unless the output is broken so bad that it causes obvious artifacts Since (1) does happen with my GCC 4.4.1 TDM-2 builds and there also is no obvious indication for (2), I'd assume these builds are okay. But there may be a more subtle problem. So how do I check properly ???
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
10th October 2009, 16:10 | #2434 | Link |
Registered User
Join Date: Jul 2007
Posts: 552
|
LoRd_MuldeR, techouse
If you were at x264dev IRC yesterday you would know that it doesn't cause obvious artifacts. It is caused by used addressing in x264 and gcc. The quick workaround is replacing of all dct2x2[0][coeff] with dct2x2[coeff>>1][coeff&1] in macroblock.c |
10th October 2009, 16:12 | #2435 | Link |
Registered User
Join Date: Aug 2008
Location: Minsk, Belarus
Posts: 235
|
Test made by "%x% --threads 1 --ssim -o %x%.264 TestVideo.y4m"
"FAILURE" mean BIG difference (above 5 kilobytes) (FAILURE) with x264.nl x32 build... Raw stream of "OK"-bulds is identical with x264.nl x32 build... |
10th October 2009, 16:24 | #2436 | Link |
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
we discussed the issue on #x264dev last night and discovered the discrepancy in the output and the underlying cause in the code.
the underlying code was found in x264_mb_optimize_chroma_dc within encoder/macroblock.c the problem with the output not being bitwise equivalent is that the chroma macroblocks can be slightly different from what they should be. the visual difference is generally unnoticeable and there's a slight bitrate difference when encoding in CRF mode. the method to test if your build has this issue: 1. take a build that was listed as 'OK' by komisar and use it as a reference 2. ./x264_reference --qp 24 --ipratio 1 -o a1.h264 <input> 3. ./x264_reference --qp 25 --ipratio 1 -o a2.h264 <input> 4. ./x264_your_own --qp 24 --ipratio 1 -o b1.h264 <input> 5. ./x264_your_own --qp 25 --ipratio 1 -o b2.h264 <input> if your build has problems then a1.h264 & b1.h264 should be different a2.h264 & b2.h264 should be bitwise equivalent the problem has only been reported for mingw as of yet, so it's either only affecting mingw or no one's just tested for other platforms. |
10th October 2009, 19:04 | #2437 | Link |
Registered User
Join Date: May 2008
Posts: 41
|
dct2x2[2][2] could also be changed into dct2x2[4] instead (after adjusting all relevant code), at least that seems to do the trick for me and should theoretically be faster than doing some bit manipulation. The same probably holds for all other DCT arrays.
|
10th October 2009, 19:12 | #2438 | Link | ||
Compiling Encoder
Join Date: Jan 2007
Posts: 1,348
|
Quote:
Quote:
|
||
11th October 2009, 12:56 | #2439 | Link | |
Strictly Rhythm
Join Date: Jul 2007
Location: Ljubljana, Slovenia
Posts: 166
|
Quote:
EDIT: x264_x64_r1281_fix_unpatched | MD5 GCC 4.4.1 20090803 (x64.core2.Komisar), unpatched, generic, fprofiled Patches used: the quick GCC 4.4.x workaround ________________________________________________________________________________ x264_x86_r1281_fix_techouse | INFO GCC 4.4.1 20090803 (x86.core2.Komisar), fprofiled, -march=core2 x264_x64_r1281_fix_techouse | INFO GCC 4.4.1 20090803 (x86_64.core2.Komisar), fprofiled, -march=core2 Patches used: x264_win_zone_parse_fix_06.diff x264_hrd_pd_interlace.16_r1281.diff the quick GCC 4.4.x workaround
__________________
Last edited by techouse; 11th October 2009 at 19:27. Reason: Fixed patched builds. Links remain the same, the binaries on the server have changed, so please RE-download them. |
|
Tags |
h.264, x264, x264 builds, x264 patches, x264 unofficial builds |
Thread Tools | Search this Thread |
Display Modes | |
|
|