Investigate different segment range packing

[nfrechette]

Currently, segment samples are normalized and thus the range values are also normalized. We currently encode the range as [min, extent] where max = min + extent. This allows us to represent the full range of [0.0, 1.0].

An alternative could be to store it as [centre, half extent]. This has the benefit that we need 1 bit less for the half extent encoding because we need both +- values. The down side is that we can only represent [0.0, 1.0). This might be a good fit for bit shifting float coercion where we just line up the mantissa. This boundary condition can also be handled by the clip range since we already pad it to handle rounding.

If we drop the number of bits for the extent portion, we can save up to 8 bits per component. However, because segments have ~16 samples, if the bit rate increases by 1 bit as a result, we'll end up with a net loss of 8 bits. We'd only win if we can maintain the same bit rate.

If the range bounds aren't tight, it leaves room for sample values to encode values that are out of the possible range of values. As such, we'd have a portion of our sample encoded range that would be unused. This would decrease the percentage used.

We could add fixed padding to the extent and use fewer bits.

We could also leverage the fact that segment ranges are packed in groups of 4 sub-tracks. We current store 12+12 bytes for [min, extent]. We could do 12+8, or 12+9, etc.

Can we leverage the group as well? Sort by min/centre and reduce the range of possible values that way? Store the sub-track order on 4-6 bits (2 bits per sub-track, last one can be dropped and reconstructed). Can we do something clever with this? This would still allow for fast single track decompression.

Can we bucket ranges?

If we need to, we could add metadata etc but ideally we have to keep the decompression path lean and simple.