git.sesse.net Git - x264/blob - doc/threads.txt

   1 Old threading method: slice-based
   2 application calls x264
   3 x264 runs B-adapt and ratecontrol (serial)
   4 split frame into several slices, and spawn a thread for each slice
   5 wait until all threads are done
   6 deblock and hpel filter (serial)
   7 return to application
   8 In x264cli, there is one additional thread to decode the input.
   9
  10 New threading method: frame-based
  11 application calls x264
  12 x264 runs B-adapt and ratecontrol (serial to the application, but parallel to the other x264 threads)
  13 spawn a thread for this frame
  14 thread runs encode in 1 slice, deblock, hpel filter
  15 meanwhile x264 waits for the oldest thread to finish
  16 return to application, but the rest of the threads continue running in the background
  17 No additional threads are needed to decode the input, unless decoding+B-adapt is slower than slice+deblock+hpel, in which case an additional input thread would allow decoding in parallel to B-adapt.
  18
  19
  20 Penalties for slice-based threading:
  21 Each slice adds some bitrate (or equivalently reduces quality), for a variety of reasons: the slice header costs some bits, cabac contexts are reset, mvs and intra samples can't be predicted across the slice boundary.
  22 In CBR mode, we have to allocate bits between slices before encoding them, which may lead to uneven quality.
  23 Some parts of the encoder are serial, so it doesn't scale well with lots of cpus.
  24
  25 Penalties for frame-base threading:
  26 To allow encoding of multiple frames in parallel, we have to ensure that any given macroblock uses motion vectors only from pieces of the reference frames that have been encoded already. This is usually not noticeable, but can matter for very fast upward motion.
  27 We have to commit to one frame type before starting on the frame. Thus scenecut detection must run during the lowres pre-motion-estimation along with B-adapt, which makes it faster but less accurate than re-encoding the whole frame.
  28 Ratecontrol gets delayed feedback, since it has to plan frame N before frame N-1 finishes.
  29
  30
  31 Benchmarks:
  32 cpu: 4x woodcrest 3GHz
  33 content: 480p
  34
  35 x264 -B1000 -b2 -m1 -Anone
  36 threads  speed           psnr
  37        old   new      old    new
  38 1:   1.000x 1.000x   0.000  0.000
  39 2:   1.168x 1.413x  -0.038 -0.007
  40 3:   1.208x 1.814x  -0.064 -0.005
  41 4:   1.293x 2.329x  -0.095 -0.006
  42 5:          2.526x         -0.007
  43 6:          2.658x         -0.001
  44 7:          2.723x         -0.018
  45 8:          2.712x         -0.019
  46
  47 x264 -B1000 -b2 -m5
  48 threads  speed           psnr
  49        old   new      old    new
  50 1:   1.000x 1.000x   0.000  0.000
  51 2:   1.319x 1.517x  -0.036 -0.006
  52 3:   1.466x 2.013x  -0.068 -0.005
  53 4:   1.578x 2.741x  -0.101 -0.004
  54 5:          3.022x         -0.015
  55 6:          3.221x         -0.014
  56 7:          3.331x         -0.020
  57 8:          3.425x         -0.025
  58
  59 x264 -B1000 -b2 -m6 -r3 -8 --b-rdo
  60 threads  speed           psnr
  61        old   new      old    new
  62 1:   1.000x 1.000x   0.000  0.000
  63 2:   1.531x 1.707x  -0.032 -0.006
  64 3:   1.866x 2.277x  -0.061 -0.005
  65 4:   2.097x 3.204x  -0.088 -0.006
  66 5:          3.468x         -0.013
  67 6:          3.629x         -0.010
  68 7:          3.716x         -0.014
  69 8:          3.745x         -0.018
  70