x264 multi-core (4+) threading optimization

[morph166955]

@aku
so seeing as thread_pool_03 is faster then (or at least equal too) whats in the svn now, any chance we can get that to be committed to the svn or do you still want to do more testing of some sort?

[ATT]

how does this translate to real world

2 hour 1080i/p HD movie MPEG2 to XH264 does it still get 120FPS or 200FPS im sure that's on SD right :)
with a quadcore/octcore system does it still take 2 days or more ?

right now i am sitting on a X24400 Noobish attempts doing some encoding a first pass on some anime: @ 6.20FPS

CLI: --pass 1 --stats .stats --bitrate 2000 --sar 1:1 -A all --aud --level 4.1 --ref 3 --mixed-refs --bframes 3 --direct auto --analyse none --me dia --subme 1 --threads 2 --no-ssim --no-psnr --progress
avis [info]: 1920x1088 @ 23.98 fps (150945 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2 3DNow!

basically for PS3 the second pass going to take 21 hours last time i tried. ( i had an error and i lost everything just minutes before it was about to finish)

has anyone done before and after of 1-2 hour film an have before and after times ? dualcore/quadcore/octcore :sly:

[morph166955]

Hows this...I'll let ya know! The system has been "down" while I've been working on my custom linux distro on it for the past week or so. I've got a nice long 1080p movie that I'm planning on testing it on overnight tonight. While it doesn't run 200fps, it does run what one would expect it to run being that the size of the image is different. For example, I've been running the tests on a cropped dvd image thats 848x352. Lets assume for math purposes that it ran exactly 200fps. Lets also assume for a moment that I was maxing out the CPU's which I'm not currently able to do. For a 1080p image you wouldn't expect 200fps since the 1920x1080 image is ~7 times larger then the 848x352 is. However, you would expect it to be around 200/7 which is ~28.5. When I was running some very quick tests on it (5000 frames max), I was seeing frame rates in the low 20's. While its not perfect scaling, it was adequate enough for my tastes considering that most current systems doing full 1080p run below 5fps if even that. I do remember at one point saying "wow I'm encoding 1080p in insane quality in real time" so I must assume that since it was a 24000/1001 frame rate that I was getting around 24-25fps for that block.

I'm recompiling x264 tonight to work on this and I'll run some tests once thats all done and I've gotten a few other small things tweaked. So as I said before, I'll let ya know!

[708145]

i just ran a test to see what would happen if i loaded 4 ram buffers with 500 frames each, and then simultaniously forked 4 x264 (vanilla r655 build) threads running @ threads=2 (i also tried @ threads=3 the effect was negligible) , i was able to run the system at >90% cpu usage since each x264 thread was using 185-190% cpu of the 200% max it should be able to do. each thread ran at around 105fps giving me a total of about 420fps.

With just 8 cores I think 3 GOPs with 4threads will result in the same speedup with less memory usage. With more cores you'd want to find a better sweet spot (For 16 cores probably 5 GOPs with 5 threads each... I need to check this).

If you want to use GOP level encoding be aware that the main problem is not scaling performance but to get I frame positions right (as you already do) and also get the bit distribution right. Both x264farm and ELDER (my pet) come very close in that respect ;)

bis besser,
T0B1A5

[morph166955]

In case anyone is still wanting to play around with this I have created a new diff based on the current svn. There were some things moved from common.h to osdep.h so I have fixed that as well as altered version.sh to generate a version that has "_THREADPOOL04" at the end (eg mine is now 0.56.669_THREADPOOL04). I just ran a two pass on some 1080p stuff and it gave me a gooooooood boost in speed.

Just to note, there is nothing different functionality-wize between this and the tp03 patch, I just fixed it to work with the current svn (r670).

http://www.benswebs.com/x264_thread_pool.04a.r670.diff

EDIT: oops uploaded it to the wrong place, link works now

[morph166955]

Thread pool patch was updated to r678 and moved to http://www.benswebs.com/public/x264/x264_thread_pool.04b.r678.diff

Post #1 updated to have new link also

[delacroixp]

It's always nice to see some movement in the world of multi-core threading optimization... especially in light of AMD plans to release a triple core (http://seekingalpha.com/article/47473-amd-to-launch-triple-core-cpu-in-early-2008) in early 2008 and the need for a multi-core killer app (http://seekingalpha.com/article/47912-amd-needs-a-multi-core-killer-app?source=feed) ...

" Most of the software in the market cannot take advantage of multi-core chips, so why buy machines that boast to have them and pay the extra price ? " ( Sramana Mitra (http://seekingalpha.com/article/47912-amd-needs-a-multi-core-killer-app?source=feed)).


:):devil::D
Pascal

[708145]

especially in light of AMD plans to release a triple core (http://seekingalpha.com/article/47473-amd-to-launch-triple-core-cpu-in-early-2008) in early 2008.

Ah finally. A Tri-Athlon ;)
The fitting CPU for the best sport in the world :D

But on-topic: There are apps around AI that definitely benefit from more cores. Think "decision helpers", "memory expanders" and "information filters" that adjust to your preferences. Video encoding is already as parallel as it need to be.

[squid_80]

" Most of the software in the market cannot take advantage of multi-core chips, so why buy machines that boast to have them and pay the extra price ? " ( Sramana Mitra (http://seekingalpha.com/article/47912-amd-needs-a-multi-core-killer-app?source=feed)).
Doesn't this guy ever run more than one program at once?

[Sharktooth]

she is an idiot. she did a very superficial analysis and draw even some false conclusions.

[lexor]

quick question, I see that Cef's page lists this patch (and others), but does Cef's build actually have this patch? (or any of the ones in patch directory?)

[Adub]

Yeah, I believe Cef is fullfilling that hole that is Sharktooth in his absence.

Aka. He is building x264 with patches.

[morph166955]

well considering that the current revision of the patch wont apply cleanly to r680 i'm not sure how yes doing it. I'm going to update the patch this weekend to work with r680's naming conventions.

[Cef]

Well I just added "x264_" here and there to compile with r680. I'm not even sure what's this patch suppsoed to do though, so I don't know if it's actually done right. diff is here (http://mirror05.x264.nl/Cef/force.php?file=./patches/x264_thread_pool.r680.diff)

[burfadel]

Cef, separate issue, but will you be adding the --me-prepass patch in future builds? its a great option! Its good now, in another post it was talked that it will be modified to reduce its performance impact (which is not excessive at the moment).

[Dark Shikari]

Cef, separate issue, but will you be adding the --me-prepass patch in future builds? its a great option! Its good now, in another post it was talked that it will be modified to reduce its performance impact (which is not excessive at the moment).I need to fix a few things about it--Aku noticed a few problems with it that may both reduce its speed and its effectiveness below what it could be.

[burfadel]

I know :) maybe if the performance impact with the modifications is reduced enough it can be enabled by default, and then have an option of --nome-prepass or something?

Also, isn't imh supposed to replace umh? and also 'subme 8' replacing 'subme 7'?

[morph166955]

My patch is updated and uploaded to work with r680. Link on the main page has been updated.

[NaturalThoughts]

I have query regarding QP in case of multithreading enabled.

As in the case of single thread, each next frame QP is calculated based upon previous frame stats.

IPPPP.... case
e.g. 0th Frame (QP =26)
1st frame (QP modifies based on 0th frame stats),
2st frame (QP modifies based on 1th frame stats)
and so on......
But in the case of more than one thread, how QP is assigned for next frame as present frame or previous frame is being encoded.

0th Frame (QP =26)
1st frame (QP = ?),
2st frame (QP = ?)
and so on......

Thanks in advance.

[akupenguin]

1pass CRF/CQP: completely ignore previous frames' stats.
1pass ABR/2pass: QP adapts by stats from whichever frames have finished encoding. Any sane number of threads makes little difference, as the adaption time scale is much longer than the threading latency.
VBV: latency is important, so QP adapts by stats from whichever portions of each frame have finished encoding.

[NaturalThoughts]

1pass CRF/CQP: completely ignore previous frames' stats.
1pass ABR/2pass: QP adapts by stats from whichever frames have finished encoding. Any sane number of threads makes little difference, as the adaption time scale is much longer than the threading latency.


Ok I got it.
1) So Can I assume that for 1 pass CQP : Irrespective of number of threads (1,2,4,8,...) PSNR and output bit rate will be same, or that is a little chance of penalty with threads and PSNR and output bit rate may change....

2) 1 pass ABR : definitely there will be penalty in terms of PSNR and output bit rate by increasing number of threads.

[akupenguin]

With CRF/CQP there is a small threading penalty, due to the limitation on mvs.
With 1pass ABR there is an additional penalty due to the slightly less accurate distribution of bits.

[LoRd_MuldeR]

For any reasonable number of threads the penalty will be so small that it doesn't matter. In reality you probably won't be able to see the difference...

[NaturalThoughts]

With CRF/CQP there is a small threading penalty, due to the limitation on mvs.

you mean it will be because of this

h->param.analyse.i_mv_range_thread = r2;
of x264_validate_parameters() of encoder.c

With 1pass ABR there is an additional penalty due to the slightly less accurate distribution of bits.

Could u explain this a little bit......

[NaturalThoughts]

I feel that due to lines of code shown below........

h->param.analyse.i_mv_range_thread = r2;

and

h->mb.mv_max_spel[1] = X264_MIN( h->mb.mv_max_spel[1], thread_mvy_range*4 );

As motion vector search range will change, so penalty will there for both the case CQP/ABR . Am i right???

What will be the reason for additional penalty in ABR and how???

Thanks in advance.

[NaturalThoughts]

A dig a little bit more..... here is my understanding as of now.......

Ratecontrol module in the case of ABR and 2 threads.... (1pass only)
rce.blurred_complexity = f (current frame SATD)
q = f (rcc->wanted_bits_window, rcc->cplxr_sum) (e.g x= f(y))

So QP will be
0th frame:
rc->qp = Based on current frame complexity (based on SATD)

1st frame:
rc->qp = Based on current frame complexity (based on SATD) as 0th frame still not finished

2nd frame:
modify rcc->wanted_bits_window (number of frame done and fps), rcc->cplxr_sum (based on 0th frame bits consumed) .
rc->qp = Based on current frame complexity (based on SATD) with modified rcc->wanted_bits_window, rcc->cplxr_sum

3rd frame:
modify rcc->wanted_bits_window (number of frame done and fps), rcc->cplxr_sum (based on 1st frame bits consumed) .
rc->qp = Based on current frame complexity (based on SATD) with modified rcc->wanted_bits_window, rcc->cplxr_sum

4th frame:
modify rcc->wanted_bits_window (number of frame done and fps), rcc->cplxr_sum (based on 2nd frame bits consumed) .
rc->qp = Based on current frame complexity (based on SATD) with modified rcc->wanted_bits_window, rcc->cplxr_sum

and so on.........

Is it correct or am I missing something???

And if my understanding is correct then can I say in the case of threading enabled QP calculation is done without previous frame bits consumption data, so there will be chance of deviation from the desired average bit rate. So how x264 handle this to achieve ABR ???

And also can I say penalty increasing linearly with number of threads for ABR....

[akupenguin]

so there will be chance of deviation from the desired average bit rate. So how x264 handle this to achieve ABR?
x264's ABR accuracy is measured in percentage points of the total filesize anyway. A few extra frames of inaccuracy is nothing compared to even the nonthreaded tolerance. Which I said before: adaption time scale is much longer than the threading latency.

[NaturalThoughts]

Ok...
could u tell me about rcc->rate_tolerance....

how this affect final bit rate ???
I found this in common.c , function x264_param_default()
param->rc.f_rate_tolerance = 1.0;

And later in x264_ratecontrol_new() in ratecontrol.c

rc->rate_tolerance = h->param.rc.f_rate_tolerance;
and then
double abr_buffer = 2 * rcc->rate_tolerance * rcc->bitrate;

SO if rcc->rate_tolerance is 1.0 then abr_buffer is just double of the desired bitrate... :scared:

Can I vary it to 0.6 or 0.5 so it will be close to final bit rate.....???