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.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 8th October 2009, 17:53   #2421  |  Link
ACrowley
Registered User
 
Join Date: Apr 2006
Posts: 1,008
Quote:
Originally Posted by LoRd_MuldeR View Post
Why do you complain about too low bitrate? You can't expect a specific bitrate from a specific CRF value, because CRF highly depends on the source.

So if the quality is okay at CRF 18 and 6-8 Mbps, then be happy

And if the quality is not okay for you at CRF 18, simply use an even lower CRF value. The CRF should be chosen by target quality, not by target bitrate.

For target bitrate encodes there is 2-Pass mode ...
im not complainig. I just wondering because i was expecting higher Bitrate with CRF 18. I usually encode 1080p with 8-15Mbps.
ACrowley is offline   Reply With Quote
Old 8th October 2009, 18:13   #2422  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by ACrowley View Post
im not complainig. I just wondering because i was expecting higher Bitrate with CRF 18. I usually encode 1080p with 8-15Mbps.
1. As said before, CRF highly depends on the source. So your current source may simply need fewer bits to look good.

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 🇺🇦✊
LoRd_MuldeR is offline   Reply With Quote
Old 8th October 2009, 18:23   #2423  |  Link
ACrowley
Registered User
 
Join Date: Apr 2006
Posts: 1,008
Quote:
Originally Posted by LoRd_MuldeR View Post
1. As said before, CRF highly depends on the source. So your current source may simply need fewer bits to look good.

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 ???
Its latest encode from Xmen Origins Wolferine Bluray.
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
ACrowley is offline   Reply With Quote
Old 8th October 2009, 18:27   #2424  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by ACrowley View Post
Maybe i should go down to crf 16 or 17
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 🇺🇦✊
LoRd_MuldeR is offline   Reply With Quote
Old 8th October 2009, 18:42   #2425  |  Link
ACrowley
Registered User
 
Join Date: Apr 2006
Posts: 1,008
Quote:
Originally Posted by LoRd_MuldeR View Post
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
Im very satisfied with my 2pass VBR encodes which are mostly around 10-12Mbps average Bitrate.

I want the same Quality/Size. CRF was only a thought because it works faster. I will test it .
THX
ACrowley is offline   Reply With Quote
Old 8th October 2009, 18:57   #2426  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by ACrowley View Post
Im very satisfied with my 2pass VBR encodes which are mostly around 10-12Mbps average Bitrate.

I want the same Quality/Size. CRF was only a thought because it works faster. I will test it .
THX
Again: If you use CRF mode, then choose your CRF value with a specific level of quality in mind, not with a specific target bitrate in mind!

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 🇺🇦✊
LoRd_MuldeR is offline   Reply With Quote
Old 9th October 2009, 21:14   #2427  |  Link
komisar
Registered User
 
komisar's Avatar
 
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
gcc sucks again...
__________________
..::[I am live here]..::..[My x264 CLI/VFW builds and tools]::..

Last edited by komisar; 9th October 2009 at 22:13.
komisar is offline   Reply With Quote
Old 9th October 2009, 22:12   #2428  |  Link
JEEB
もこたんインしたお!
 
JEEB's Avatar
 
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]
JEEB is offline   Reply With Quote
Old 9th October 2009, 22:58   #2429  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
what is the problem that is occurring in x264 with these 'broken' builds?
and what is the issue in gcc that's causing them
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 9th October 2009, 23:16   #2430  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
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.
LoRd_MuldeR is offline   Reply With Quote
Old 10th October 2009, 06:35   #2431  |  Link
MythCreator
Registered User
 
Join Date: Dec 2007
Location: Beijing,China
Posts: 92
My build is compile by TDM GCC。。。And what things are failure on 4.4.X?
MythCreator is offline   Reply With Quote
Old 10th October 2009, 12:11   #2432  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by MythCreator View Post
My build is compile by TDM GCC。。。And what things are failure on 4.4.X?
That's what I wonder too. There are basically two things that can happen:

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 🇺🇦✊
LoRd_MuldeR is offline   Reply With Quote
Old 10th October 2009, 14:03   #2433  |  Link
techouse
Strictly Rhythm
 
techouse's Avatar
 
Join Date: Jul 2007
Location: Ljubljana, Slovenia
Posts: 166
Yea, I wanna know that too. :/
__________________
techouse is offline   Reply With Quote
Old 10th October 2009, 16:10   #2434  |  Link
MasterNobody
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
MasterNobody is offline   Reply With Quote
Old 10th October 2009, 16:12   #2435  |  Link
komisar
Registered User
 
komisar's Avatar
 
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...
__________________
..::[I am live here]..::..[My x264 CLI/VFW builds and tools]::..
komisar is offline   Reply With Quote
Old 10th October 2009, 16:24   #2436  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
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.
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 10th October 2009, 19:04   #2437  |  Link
tph
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.
tph is offline   Reply With Quote
Old 10th October 2009, 19:12   #2438  |  Link
kemuri-_9
Compiling Encoder
 
kemuri-_9's Avatar
 
Join Date: Jan 2007
Posts: 1,348
Quote:
Originally Posted by tph View Post
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.
that's the plan of attack as it already stands:
Quote:
Originally Posted by #x264dev@irc.freenode.net
<kemuri-_9> so what is going to be done to fix the issue?
<pengvado> eliminate multidimensional arrays in any context that needs to iterate over multiple dimensions
<pengvado> if the standard doesn't allow that feature to work, then we can't use it
<pengvado> you know, most of the time it's not actually useful to treat dct as 2d...
__________________
custom x264 builds & patches | F@H | My Specs
kemuri-_9 is offline   Reply With Quote
Old 11th October 2009, 12:56   #2439  |  Link
techouse
Strictly Rhythm
 
techouse's Avatar
 
Join Date: Jul 2007
Location: Ljubljana, Slovenia
Posts: 166
Quote:
Originally Posted by MasterNobody View Post
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
OK, I'll use this quick workaround and post 3 builds in a few minutes.

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.
techouse is offline   Reply With Quote
Old 11th October 2009, 13:21   #2440  |  Link
burfadel
Registered User
 
Join Date: Aug 2006
Posts: 2,229
Is this issue still present in the GCC 4.5.0 beta?

Using the latest ffdshow and mpc-hc from xvidvideo.ru both of which are compiled with gcc 4.5.0, they seem to work fine...
burfadel is offline   Reply With Quote
Reply

Tags
h.264, x264, x264 builds, x264 patches, x264 unofficial builds

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 12:45.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.