I believe that compiling x265 with the 3 patches just makes it possible to encode 8-bit as usual, as well as the additional encode possibilities of 10-bit and 12-bit. That is all that is affected with what we have just been calling "multibit", i.e.:

  1. encode ONLY

  2. x265 ONLY

  3. 8-bit basically the same as without the patches

  4. 10-bit and 12-bit additional options for encoding

These particular patches were provided by Andrew-R who most likely located the possibility from information found on the internet and created the modset as required specifically for CinGG.

CinX build was based on a previous and totally different change.  In February 2018, per the release notes, x265 had 10-bit incorporated into the code so a special 10-bit version was no longer needed. It can be deleted from the Manual.

Andrey, I was just going to checkin the 3 patches so that you will not have to do anything different in your builds but since there was so much feedback, I will re-read all of it, do some more tests, and hopefully still check them in a little later.

- Andrea reported: If it is limited to the encoder then I noticed a small difference (in my tests: 8-bit: 22 fps; multibit: 19 fps).

- My results mirror Andrea's.  A simple low resolution 1 minute/31 second video when encoded using the regular just 8-bit x265 version had an fps of 112.831 / 104.545 / 113.859 in 3 separate runs.That same video when encoded using the multibit compiled version 8-bit render format had an fps of 114.026 / 112.817 in 2 separate runs.

- Results rendering a 4K video (this 1 had no audio) that was a little over 2 minutes were fps=2.757 on the 8-bit compiled version and fps=2.762 on the multibit compiled version.  Basically no difference.