What Happens to 10-bit and 4:2:2 Video: It Depends on Whether the Picture Is Re-encoded
The sentence that matters most, up front: when the picture does not need re-encoding, 10-bit and HDR information travels untouched; when it does, the delivery shape is the source bit depth, up to 10-bit, with chroma unified to 4:2:0. Which of those CineX takes is decided per file, from what is inside it — see Why some videos convert in seconds and others take longer. The extension is not the criterion.
1. Why nothing changes on the "no re-encode" path
For HEVC 10-bit (including HDR10 material) and H.264 Hi10P that a device can already read, CineX moves the stream instead of repainting it: no pixel is regenerated, so bit depth, chroma sampling and range all stay exactly as they were. Those files often finish in seconds, and the speed is a direct consequence of not recompressing.
When the picture was never repainted, "will it lose quality" is not a live question — it was not touched.
2. When it must be re-encoded, depth follows the source up to 10-bit and chroma becomes 4:2:0
If the picture has to be re-encoded - sources such as VP9, AV1 or Xvid that a device cannot play directly - bit depth is not pushed down: a 10-bit source (or one whose transfer is HDR, PQ or HLG) is delivered as 10-bit, a 12-bit source lands at 10-bit, and 4:2:2 or 4:4:4 chroma is unified to 4:2:0 while the depth stays. Only two cases come back 8-bit: the source already was 8-bit, or the file exposes no readable depth. What does change is the chroma layer - the 10-bit tonal precision stays in the pixels, the 4:2:2 sampling does not.
Why the chroma is unified and 12-bit lands at 10-bit: that is our own delivery line - the output goes only into the shape our release evidence already covers (HEVC Main 10, 4:2:0), and we do not bet on a wider one. It is a trade-off, not an oversight, and no switch overrules it, because CineX has no parameters at all.
3. HDR and Dolby Vision land differently here
The finer colour-side rules — which path HDR10 takes, how the Dolby Vision profiles differ — live in Does CineX keep HDR and Dolby Vision. The one conclusion tied directly to bit depth: a re-encode delivers the picture at its source depth, up to 10-bit. On Dolby Vision we only ever say it travels on the container-swap route; what is left of it after a re-encode has not been verified, so neither outcome is written as a promise. Colour markings (transfer function, colour primaries) are carried when the source has them and are not invented when it does not. "A flag survived" and "the effect survived" are two different statements - which is why Dolby Vision and HDR10 have to be discussed separately.
4. 10-bit does not automatically mean slow — with one exception
10-bit H.264 (Hi10P) and 10-bit HEVC are both inside the input range we have run on real devices. The case that needs time on the calendar is the extreme one: a high-frame-rate, high-resolution picture that must be fully re-encoded waits in proportion to the clip and usually longer than the clip itself. For files like that, checking whether a re-encode is needed at all usually beats switching tools.
What slows a file down is never the number 10-bit; it is whether the picture has to be drawn again. On the route that leaves it alone, the bit depth is kept as it is; on the route that re-draws it, the delivery is source depth up to 10-bit at 4:2:0 — and that is the one worth planning time for.
5. Limits worth knowing beforehand
- This describes the rules for each path. The 10-bit and HDR behaviour on the no-re-encode path is backed by real-device samples, and 12-bit and 4:2:2 each have one too (12-bit lands at 10-bit; 4:2:2 chroma becomes 4:2:0 with the depth kept). The per-sample regression on iOS is not closed yet, so 10-bit is stated here as a delivery shape, not as a selling point - if your work depends on it, test one of your own files first.
- Re-encoding changes the picture. We do not deny that, and we do not offer a "keep it as-is" option.
- Bit depth and colour are not failure signals: the output plays normally, and unified 4:2:0 chroma is the rule of that route, not damage.
- A full conversion also needs headroom — peak disk usage stays under twice the source file size, while a container swap needs room for the finished file alone — explained in Why video conversion needs extra free space.
Frequently asked questions
Will my 10-bit HEVC film be reduced to 8-bit?
No. If a device can read that picture, CineX only swaps the container and the pixels, 10-bit included, are untouched; when it must be re-encoded the depth still is not pushed down - a 10-bit source is delivered as 10-bit. The output is 8-bit only when the source already was, or when the file exposes no readable depth.
The HDR marking survived, so why does it look flat?
A flat look usually comes from how the display treats HDR-class luminance, not from a broken output. The re-encode route delivers 4:2:0 and carries colour markings from the source; "the flag is there" is not "the effect is there", so keep the original for a path that supports it.
Is there a way to keep 10-bit in the output?
Nothing to set and nothing to switch: a re-encode already follows the source depth, so a 10-bit source comes out 10-bit and an 8-bit source does not become 10-bit because you want it to. CineX is zero-parameter: no quality tier, no bit-depth choice, no target size.
Is 10-bit always slow to convert?
No. Only files that need re-encoding and are also high in frame rate and resolution take minutes rather than seconds; many 10-bit files ride the no-re-encode path and finish in seconds.
Axiom One LLC — CineX