View Full Version : MeGUI x264 setting for PV/MV (Video Music)
SeiShinn
9th June 2009, 12:14
Hello...
I am newbie here..
I want to ask about x264 setting in MeGUI...
can some one help me about the best x264 setting for MV/PV (Video Music) if I want a best quality but the size still friendly?
Me here still use Intel Pentium 4 2,8 GHz...
and I recently used this setting :
program --pass 3 --bitrate 3500 --stats ".stats" --ref 11 --mixed-refs --no-fast-pskip --bframes 1 --b-adapt 2 --weightb --direct auto --deblock -2:-1 --subme 9 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me esa --merange 32 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"
and if I use this setting,one video take about 9-10hours to finish
Really hope for a help...:confused:
screenshot helps alot for me of course ^_^
Thank You!
Atak_Snajpera
9th June 2009, 12:45
and if I use this setting,one video take about 9-10hours to finish
I'm not surprised at all. What did you expect on ancient Pentium IV? Who told you to use --ref 11 , --trellis 2 , --me esa --merange 32??? You should use --ref 3 , --trellis 1 , --me umh , --merange default . I would also change --b-adapt 2 to 1 and --pass 3 to --pass 2.
BTW. You haven't read rules
can some one help me about the best x264 setting for MV/PV (Video Music) if I want a best quality but the size still friendly?
LoRd_MuldeR
9th June 2009, 12:51
In fact you don't change "--pass 3" to "--pass 2". You run the first pass with "--pass 1" and the second one with "--pass 2". There is absolutely no need to run a third pass. Really.
Nevertheless "--trellis 2" does make sense, especially when you used these ultra-slow options before. Also you should use "--bframe 4" and "--b-adapt 2" before even considering something like "--me esa".
Forteen88
9th June 2009, 12:56
What's the resolution? --no-dct-decimate shouldn't be used on size friendly (aka bitrate-starved) encodes.
SeiShinn
9th June 2009, 15:29
Thank You Atak_Snajpera,LoRd_MuldeR
Thank You for all the teaching....:thanks:
I'm not surprised at all. What did you expect on ancient Pentium IV? Who told you to use --ref 11 , --trellis 2 , --me esa --merange 32??? You should use --ref 3 , --trellis 1 , --me umh , --merange default . I would also change --b-adapt 2 to 1 and --pass 3 to --pass 2.
um..okay...will change the setting and learn why it can be like that...LoL
but,except that,is everything okay?
Forteen88 I am use 720x404
but,except that,is everything okay?
In addition to the suggestions above, remove --no-fast-pskip and perhaps use lower subme. Also, if you don't target a specific file size, use CRF instead of 2-pass encoding.
Forteen88
9th June 2009, 15:48
Forteen88 I am use 720x404Ok, then default merange (16) is good enough, as Atak_Snajpera wrote.
I'd keep --no-fast-pskip and --subme 9.
And using 1-pass CRF only, makes --direct auto less efficient.
Atak_Snajpera
9th June 2009, 15:50
I suggest to use DXVA-HD-Balanced profile in MeGUI.
SeiShinn
9th June 2009, 15:51
Forteen88 okay...that's help a lot
Atak_Snajpera I will try to see the difference if I use my own setting above (with your correction of course)
and...does bitrate 3500 help video to be more smooth?
Forteen88
9th June 2009, 16:01
and...does bitrate 3500 help video to be more smooth?
Bitrate 3500 kbps is very high for that resolution (SD) with x264, so you may keep --no-dct-decimate then. If you want to use less bitrate (~2000), then remove it.
Do you mean 'smooth' as in non-grainy?
SeiShinn
9th June 2009, 16:03
I would also change --b-adapt 2 to 1.
um...does this mean that I should change The Adaptive B-Frames from 2-Optimal to 1-Fast?
Am I right?
Forteen88 oh I understand..I already checklist the --no-dct-decimate button
Forteen88
9th June 2009, 16:06
um...does this mean that I should change The Adaptive B-Frames from 2-Optimal to 1-Fast?
Am I right?Your wish was "I want a best quality but the size still friendly", not as much a encoding-time issue, then keep --b-adapt 2.
LoRd_MuldeR
9th June 2009, 17:23
Your wish was "I want a best quality but the size still friendly", not as much a encoding-time issue, then keep --b-adapt 2.
@SeiShinn:
Using "--b-adapt 2" gives better results compared to "--b-adapt 1" and with a reasonable b-frame limit (e.g. "--bframe 4") it still should be fast enough.
Heck, you used "--me esa", "--merange 32" and three passes before! So you shouldn't worry about using "--b-adapt 2" too much...
SeiShinn
9th June 2009, 17:49
I already tested the difference about the correction that Atak_Snajpera gave...
and the result,the video looks more "pale" than before...
I am a little confused how to describe it..but,maybe I can say here that the result is more "gray in colour" than before...
but the plus factor is encoding time with this 2-pass is only 1 hour 30 minutes...
my setting before :
program --pass 3 --bitrate 3500 --stats ".stats" --ref 11 --mixed-refs --no-fast-pskip --bframes 1 --b-adapt 2 --weightb --direct auto --deblock -2:-1 --subme 9 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me esa --merange 32 --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"
my setting after Atak_Snajpera's correction :
program --pass 2 --bitrate 3500 --stats ".stats" --ref 3 --mixed-refs --no-fast-pskip --bframes 1 --b-adapt 2 --direct auto --deblock -2:-1 --subme 9 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"
LoRd_MuldeR
9th June 2009, 17:59
my setting after Atak_Snajpera's correction :
program --pass 2 --bitrate 3500 --stats ".stats" --ref 3 --mixed-refs --no-fast-pskip --bframes 1 --b-adapt 2 --direct auto --deblock -2:-1 --subme 9 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"
Remove "--partitions", the default is just fine. Increase "--bframe" to at least 3 or 4 (as long as you use "--b-adapt 1" you can even use "--bframe 16" with no speed loss).
If you can spend some more time, use "--b-adapt 2" and "--trellis 2". Also you should check whether the negative "--deblock" values are really needed...
I already tested the difference about the correction that Atak_Snajpera gave...
and the result,the video looks more "pale" than before...
I am a little confused how to describe it..but,maybe I can say here that the result is more "gray in colour" than before...
Sounds like you had two player windows open at the same time. In that case the other window may be rendered in a different way, causing a problem with PC/TV levels.
So, this problem has nothing to do with x264 settings, only your comparison method.
Atak_Snajpera
9th June 2009, 18:00
I am a little confused how to describe it..but,maybe I can say here that the result is more "gray in colour" than before...
You forgot to enable 16-235 -> 0 - 255 [SD] shader in Media Player Classic Home Cinema.
JohannesL
10th June 2009, 16:19
And use CRF, unless you need it to be exactly 3500kbps for some reason.
10L23r
11th June 2009, 05:08
And using 1-pass CRF only, makes --direct auto less efficient.
r u sure? i thought crf is equivalent to multi-pass..
LoRd_MuldeR
11th June 2009, 14:05
r u sure? i thought crf is equivalent to multi-pass..
CRF basically is equivalent to a 2-Pass encode of the same bitrate (as long as we don't use VBV), only that with CRF you can't know the resulting bitrate in advance.
But he was referring to the "--direct auto" option, which doesn't work as efficient in 1-Pass CRF mode as it would in 2-Pass mode. But it still does works, so...
vBulletin® v3.8.5, Copyright ©2000-2012, Jelsoft Enterprises Ltd.