threads.txt
上传用户:hjq518
上传日期:2021-12-09
资源大小:5084k
文件大小:3k
源码类别:

Audio

开发平台:

Visual C++

  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. New threading method: frame-based
  10. application calls x264
  11. x264 runs B-adapt and ratecontrol (serial to the application, but parallel to the other x264 threads)
  12. spawn a thread for this frame
  13. thread runs encode in 1 slice, deblock, hpel filter
  14. meanwhile x264 waits for the oldest thread to finish
  15. return to application, but the rest of the threads continue running in the background
  16. 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.
  17. Penalties for slice-based threading:
  18. 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.
  19. In CBR mode, we have to allocate bits between slices before encoding them, which may lead to uneven quality.
  20. Some parts of the encoder are serial, so it doesn't scale well with lots of cpus.
  21. Penalties for frame-base threading:
  22. 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.
  23. 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.
  24. Ratecontrol gets delayed feedback, since it has to plan frame N before frame N-1 finishes.
  25. Benchmarks:
  26. cpu: 4x woodcrest 3GHz
  27. content: 480p
  28. x264 -B1000 -b2 -m1 -Anone
  29. threads  speed           psnr
  30.        old   new      old    new
  31. 1:   1.000x 1.000x   0.000  0.000
  32. 2:   1.168x 1.413x  -0.038 -0.007
  33. 3:   1.208x 1.814x  -0.064 -0.005
  34. 4:   1.293x 2.329x  -0.095 -0.006
  35. 5:          2.526x         -0.007
  36. 6:          2.658x         -0.001
  37. 7:          2.723x         -0.018
  38. 8:          2.712x         -0.019
  39. x264 -B1000 -b2 -m5
  40. threads  speed           psnr   
  41.        old   new      old    new
  42. 1:   1.000x 1.000x   0.000  0.000
  43. 2:   1.319x 1.517x  -0.036 -0.006
  44. 3:   1.466x 2.013x  -0.068 -0.005
  45. 4:   1.578x 2.741x  -0.101 -0.004
  46. 5:          3.022x         -0.015
  47. 6:          3.221x         -0.014
  48. 7:          3.331x         -0.020
  49. 8:          3.425x         -0.025
  50. x264 -B1000 -b2 -m6 -r3 -8 --b-rdo
  51. threads  speed           psnr   
  52.        old   new      old    new
  53. 1:   1.000x 1.000x   0.000  0.000
  54. 2:   1.531x 1.707x  -0.032 -0.006
  55. 3:   1.866x 2.277x  -0.061 -0.005
  56. 4:   2.097x 3.204x  -0.088 -0.006
  57. 5:          3.468x         -0.013
  58. 6:          3.629x         -0.010
  59. 7:          3.716x         -0.014
  60. 8:          3.745x         -0.018