Change BitBuf into uint64_t on 64-bit x86. This means we need to flush the buffer less often, which is a significant speed win. All other platforms, including all 32-bit ones, are unchanged. Output bitstream is the same. All API constraints are kept in place, e.g., you still cannot put_bits() more than 31 bits at a time. This is so that codecs cannot accidentally become 64-bit-only or similar. Benchmarking on transcoding to various formats shows consistently positive results: dnxhd 25.60 fps -> 26.26 fps ( +2.6%) dvvideo 24.88 fps -> 25.17 fps ( +1.2%) ffv1 14.32 fps -> 14.58 fps ( +1.8%) huffyuv 58.75 fps -> 63.27 fps ( +7.7%) jpegls 6.22 fps -> 6.34 fps ( +1.8%) magicyuv 57.10 fps -> 63.29 fps (+10.8%) mjpeg 48.65 fps -> 49.01 fps ( +0.7%) mpeg1video 76.41 fps -> 77.01 fps ( +0.8%) mpeg2video 75.99 fps -> 77.43 fps ( +1.9%) mpeg4 80.66 fps -> 81.37 fps ( +0.9%) prores 12.35 fps -> 12.88 fps ( +4.3%) prores_ks 16.20 fps -> 16.80 fps ( +3.7%) rv20 62.80 fps -> 62.99 fps ( +0.3%) utvideo 68.41 fps -> 76.32 fps (+11.6%) Note that this includes video decoding and all other encoding work, such as DCTs. If you isolate the actual bit-writing routines, it is likely to be much more. Benchmark details: Transcoding the first 30 seconds of Big Buck Bunny in 1080p, Haswell 2.1 GHz, GCC 8.3, generally quantizer locked to 5.0. (Exceptions: DNxHD needs fixed bitrate, and JPEG-LS is so slow that I only took the first 10 seconds, not 30.) All runs were done ten times and single-threaded, top and bottom two results discarded to get rid of outliers, arithmetic mean between the remaining six. Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>pull/345/head
parent
c63c303a1f
commit
88d80cb975
2 changed files with 25 additions and 7 deletions
Loading…
Reference in new issue