X264 trading some speed for more quality?

[Cyber-Mav]

hi all got a question about getting some more quality if possible from my encodes.

2 main questions i have:

i am using megui and the dxva-hd-hq profile with a few tweaks. encoding my blueray disk of casino royale to a dvd5 it takes my machine 12 hours 30 mins to do at a rez of 1360x560.

changes to the profile i have made is : subpixel refinement set to 9 and using 9 reference frames too.

question is, which of these settings will cause the biggest slowdown in encoding:

setting ME Algorithm to SATD Exhaustive with ME range increased to 32 from 16.

or

turning off the TURBO option??

which one will have bigger impact on speed and quality? thanks.

forgot to add, i tried the dxva-hd-insame profile first and i know it disables the TURBO option and uses SATD with 32ME range and encode time was doubled. was wondering which option caused the huge increase in encode time, was it disabling TURBO or was it the SATD with 32ME range?
suppose i could do test encodes but would also like the input of you guys too.

[Fishman0919]

You can increase ME Range to 64 with SATD Exhaustive :eek:

But anyone would be real HARD hard pressed to see any difference. psnr score are all most the same

Subpixel Refinement seems to have most of an impact on quality. And you already have it set to 9. Maybe you can find a build that has a setting of 11 :cool:

From the tests I've done... I think anything over ME Algorithm Multi Hex is just wasted time. And at 1360x560 res ... real not needed

[nurbs]

setting ME Algorithm to SATD Exhaustive with ME range increased to 32 from 16.

or

turning off the TURBO option??

All of those will have a huge speed impact with minimal quality gain.

I would drop the number of reference frames to somewhere between three and five, each further reference frame has a constant impact on speed but only gives a fraction of the last one in terms of quality gained.

[Cyber-Mav]

ahh i also forgot to add that i used level 4.2 insted of 4.1

i decided to encode all my blurays to keep on my hard drive insted. and since my screen has a rez of 1360x768 i though why use 1280x720 when i can grab a bit more resolution detail from encoding at my screens native rez. encoding at 1080p no good since my screen doesnt have that many pixels so its just scaled down when i watch it.

so ME greater than Multi Hex is no point so thats sorted out now i will leave it at multi hex and 16 range.

any comments on the TURBO option? is it the same with that? leave it enabled since turning turbo off will just slow down the encode for next to nothing in gained quality?

[Cyber-Mav]

All of those will have a huge speed impact with minimal quality gain.

I would drop the number of reference frames to somewhere between three and five, each further reference frame has a constant impact on speed but only gives a fraction of the last one in terms of quality gained.

ahh cool i do have a time target for my encodes, usually leave them to encode overnight so my current settings on the casino royal film which was 2hour 24 mins long inc credits took 12 hours 30 mins to do which is acceptable for me and the quality was fantastic, i personally couldnt tell the difference between my 34.7gb transport stream and the resulting 4.5gb mkv created by x264.
however since i dont have a 1080p screen its probably why i cant tell the difference but either way im quite happy with it.

was wondering if there was any other option i could use to probably add around 2 more hours to the encode to get bit more quality from it.

also level 4.2 with 9 ref frames works fine with the western digital TV hd media player too and i still have hardware acceleration working on my 8800gt too. if i cant do much else to get bit more quality was wondering if i should up the reference frames to something like 12 or 13?

[Fishman0919]

ahh i also forgot to add that i used level 4.2 insted of 4.1

i decided to encode all my blurays to keep on my hard drive insted. and since my screen has a rez of 1360x768 i though why use 1280x720 when i can grab a bit more resolution detail from encoding at my screens native rez. encoding at 1080p no good since my screen doesnt have that many pixels so its just scaled down when i watch it.

so ME greater than Multi Hex is no point so thats sorted out now i will leave it at multi hex and 16 range.

any comments on the TURBO option? is it the same with that? leave it enabled since turning turbo off will just slow down the encode for next to nothing in gained quality?

4.2 ???? LINK (http://en.wikipedia.org/wiki/H.264#Levels) Only difference is the number of macroblocks per second.... and at 1360x768, it wouldn't be noticable.

4.0, maybe 3.2 would probably be fine with that res. I use 4.0 with 1920x1080 and it looks fine on a 62 HD to me. I can't see any difference between it and the Org BluRay

"TURBO option" will speed up the 1st pass quite a bit with minimal loss in overall quality.

[Cyber-Mav]

thanks for the replies so far.

ahh that explains why the 1st pass of my encode usually takes around 2 hours or so, i have turbo enabled all the time. the 2nd pass takes the longest 9hours or more depending on video length.

couple of questions about turbo though, i noticed 2nd pass hammers all 4 of my cpu cores to the max they usually over 95% all the time during the 2nd pass. but during the first pass cpu usage is usually around 40-46% like its not using all the cores? dunno if that is normal.

also if i disable turbo how much slower will the first pass become? and would the first pass then use all 4 cores?

thanks to eveyone who has replied so far in this thread.

[Fishman0919]

also if i disable turbo how much slower will the first pass become? and would the first pass then use all 4 cores?


By turning off turbo for the 1st pass, it would most likely be slow then the 2nd pass. Enabling Turbo turns off any CPU heavy calculations, make it much faster. Disabling Turbo leaves them all on... same as the 2nd pass.
All of the decisions for the encoding and B-Frame decision is done in the 1st pass. How much slower B-Frame decision is depends on what you set "Adaptive B-Frame" to... 1-Fast or 2-Optimal... 2 being the slowest.

[Cyber-Mav]

adaptive b frame is set to 2 i believe. i believe i have all the info i need now. i will try out an experiment with turbo disabled to see how much slower it is on my system.

next thing i need to try and do is to see if i can get the 64bit version of x264 working in megui.

thanks to everyone who replied in this thread. i appreciate all the help.

[deets]

if your target is quality and not a set file size, try using CRF mode.

and 64 bit via megui is a pain, ripbot will use the 64 bit codec, but its aims are simpler

[Cyber-Mav]

ahh thanks for the reply, i will for-go 64bit at the moment and wait till haali has a 64bit splitter out and there is native 64bit mode support added to megui. deets, i would have used CRF mode but i need to hit target file sizes so 2 pass vbr is what i got to stick to.

thanks to everyones help here i have a good starting point on how to progress further. i will probably fiddle around a bit more with some options and do some trial encodes on small test clips. one thing for sure encoding with x264 is a lot better in the end results compared to using xvid.

[turbojet]

Checking P4x4 in macroblock which is --partitions all gives a little increase in quality with a little slowdown.
Checking b-pyramid gives a little quality boost to some frames but if you are planning on playing these outside of a computer drop reference frames from 4 to 3 if using --b-pyramid.
Setting psy-trellis strength to 0.1-1.0 will produce a sharper look, I suggest 0.2-0.4 but your mileage may vary.

[Forteen88]

Checking P4x4 in macroblock which is --partitions all gives a little increase in quality with a little slowdown.akupenguin wrote: "p4x4 doesn't hurt, it just doesn't help. At large resolutions, individual objects in the movie are bigger than 4x4 pixels, so there's no point in partitioning mvs that small. Typically it might be enabled in 0.5% of macroblocks, and improve compression by 0.1%, making it one of the worst compression-per-cpu tradeoffs.", "I don't use p4x4 even at 480p".

[Cyber-Mav]

hmm mixed opinions from above. i suppose i could run a test with p4x4 enabled and see how much it slows down the encode. if its something small like 30mins more or so then i guess i can leave it enabled for that 0.1% increase in compression lol. after searching the forums some more going on what fishman0919 said about there being a Subpixel Refinement 11 version of x264 it turns out that Subpixel Refinement 11 could be what im looking for just to gain that extra bit of compresssion without too much sacrifice in speed.

i encode using a intel q6600. was thinking of getting a q9550 which has sse4. clock for clock how much difference would there be between a non sse4 and a sse4 enabled cpu?

[ash925]

x264 doesn't use SSE4, but you will see huge gains going to core i7 system but that again isn't related to SSE4.

[Dark Shikari]

x264 doesn't use SSE4That would be news to me.

./checkasm --bench | grep "sse4"

hadamard_ac_8x8_sse4: 689
hadamard_ac_8x16_sse4: 1269
hadamard_ac_16x8_sse4: 1264
hadamard_ac_16x16_sse4: 2461
integral_init4h_sse4: 365
integral_init8h_sse4: 551
quant_4x4_sse4: 133
quant_4x4_dc_sse4: 129
quant_8x8_sse4: 412
sa8d_8x8_sse4: 815
sa8d_16x16_sse4: 2914
satd_4x4_sse4: 297
satd_4x8_sse4: 520
satd_8x4_sse4: 431
satd_8x8_sse4: 645
satd_8x16_sse4: 1099
satd_16x8_sse4: 1177
satd_16x16_sse4: 2080

[J_Darnley]

I was about to say that if that is true what are these: http://git.videolan.org/?p=x264.git&a=search&h=HEAD&st=commit&s=[Ss][Ss][Ee]4&sr=1

[ash925]

Sorry about that ,the post was based on what I remembered (incorrectly).

[burfadel]

You remembered correctly, just going back a while when the usefulness of SSE4 as based on documentation and not tested in reality.

You will notice some speed difference between a q6600 and q9550. Not only has the q9550 run at a faster stock speed, it also has more cache, is higher clocked, and based on a modified quad design to improve bandwidth issues (so I am lead to believe).

Running 4 distinct parallel apps on a q6600 is said to be 50 percent faster than running 2 distinct parallel apps on a q6600 (then running the other two afterwards). I'm not sure of the efficiency of the q9550 but it is faster. The efficiency can be further improved by clocking the bus at 400mhz (at least) which the 333mhz fsb q9550 can easily accomplish on stock voltages.

Value for money wise, a q9400 can be better value for money as the extra cache supplied by the q9550 becomes less important the higher the fsb is clocked.