Phenom-Owners! Want 11,7% faster x264-encodes for free?

[kaid]

If yes, simply change your --threads auto or --threads 0 setting to --threads 12!

the auto setting takes 1.5x as many threads as there are cores in the system, but 6 threads don't saturate the Phenom just yet!

At least not the Phenom II 3GHz on which I found this out! ;-) It may not have the i7's Hypnothreading, but it sure as hell likes loads of threads anyway!...

[Dark Shikari]

Let me guess, you're using b-adapt 2?

It seems to benefit from more threads regardless of CPU. But we're not changing it because threaded lookahead is coming soon anyways.

[LoRd_MuldeR]

...threaded lookahead is coming soon anyways.

interesting :)

[Selur]

agree

[Sagekilla]

About how far off into the future is that DS? Exciting to hear that it's going to be threaded soon :)

[Kurtnoise]

there is already a patch available on the ML...:)

[kemuri-_9]

It's been a pretty active topic in the dev channel as of late, Dark_Shikari has been working with DaKaz to settle the issues.

Edit:
there is already a patch available on the ML...:)
don't even bother, some severe issues were found with that version that are currently in the progress of being corrected.

[IgorC]

AFAIR --threads >8 can bring tiny quality hurt. Maybe 1.5-2% with --threads 12.

[Sagekilla]

Using any number of threads can theoretically hurt quality a bit. If you have any extremely fast vertical movement, quality will suffer when you use threads. Practically, this rarely happens.

IIRC, DS said the quality dropoff is very tiny even at large numbers of threads.

[kaid]

Let me guess, you're using b-adapt 2?


Nopes. Here's my settings:
x264 -r 4 --crf 22 --threads 12 --level="4.1" --sar 1:1 --partitions all --aud --mixed-refs --bframes 3 --b-pyramid --direct auto --8x8dct --analyse all --subme 7 --me umh --weightb --trellis 1 --no-ssim --no-psnr

Using a pretty recent daily snapshot...

What is Threaded lookahead then and what does it do? 8)

[burfadel]

--bframes 2 is good :) and the speed won't hurt much at all with 3 b-frames. I'd set it to 5, as that would cover most situtations.

[plonk420]

i thought the hit to quality was like a small fraction of a percent....

[Sagekilla]

The quality hit -is- small. It would be like going from 15 refs --> 16 refs when all other settings are maxed out: Barely noticeable at all.

[Mug Funky]

wait, isn't that with slice-based multithreading? i thought x264 had a frame based multithread now?

i haven't kept up with development closely since this time last year or thereabouts, but my new TV + PC arrangement has rekindled my interest.

[Sagekilla]

I don't know about slice based MT, other than the poor scaling it had. The new frame based one we have has a very tiny drop in quality for multiple threads. IIRC though, the main issue is that each thread gets a chunk of a frame (Say first lines 0-30 for Frame 0 on thread 0, and 31-60 on Frame 1 on Thread 1, etc) and you want to have a certain height to thread ratio, which is around 40 - 50 pixels per thread I believe.

[burfadel]

How does the bit redistribution work for AQ, psy-rd and psy-trellis?

Is it all worked out as a total calculation, or are bits given to AQ and psy-rd (for example) then redistributed for a second time to psy-trellis? (or variations thereof)?

In other words, is the bit distribution only calculated once?

[Dark Shikari]

How does the bit redistribution work for AQ, psy-rd and psy-trellis?

Is it all worked out as a total calculation, or are bits given to AQ and psy-rd (for example) then redistributed for a second time to psy-trellis? (or variations thereof)?

In other words, is the bit distribution only calculated once?Bit distribution is a consequence of decisions made, not a decision in and of itself.

[IgorC]

Very little test.

Source: ftp://ftp.tnt.uni-hannover.de/pub/svc/testsequences/SOCCER_704x576_30_orig_02_yuv.zip

x264 revs 1114 (2 pass mode, same settings for both passes):
x264.exe --threads 1 --pass 1 --progress --stats "x264_stat.log" --qcomp 0.6 --bframes 16 --b-adapt 2 --weightb --subme 9 --keyint 300 --ref 16 --trellis 2 --mixed-refs --8x8dct --partitions all --direct auto --b-pyramid --bitrate 1500 --no-fast-pskip --me tesa --merange 32 --deblock -1:-1 --psy-rd 1.0:1.0 -o 1x264_1core.mp4 1.avs


Results ( x264's SSIM at 8th potency = Avisynth's SSIM plugin ):
--threads 1 : 54.181 (1,896,517 bytes)
--threads 12: 54.009 (1,898,630 bytes)
--threads 12 & +1% bitrate increase: 54.240 (1,915,683 bytes)

Conlusion for this source, for this little test:
--threads 12 implies less than 1% of bitrate increase for the same quality level of --threads 1. Something around of 0.8% of extra bitrate.