Does EncoX Keep HDR and Dolby Vision? It Depends on Whether the Picture Is Re-encoded
EncoX can retain HDR and Dolby Vision information when it only changes the video container. On that path, the picture is not recompressed, HDR10 static metadata passes through, and the Dolby Vision information travels with it. If EncoX has to re-encode the picture, the output is delivered at the source bit depth, up to 10-bit, with chroma sampling unified to 4:2:0 - and what is left of Dolby Vision after a re-encode has not been verified on that route, so neither outcome is promised. The decisive question is what EncoX has to do to the picture, not whether the file ends in MKV or MP4. Those paths have substantially different consequences for preservation.
This distinction matters if you are preparing a viewing copy but also care about preserving the characteristics of a particular HDR master. EncoX creates an MP4 better suited to opening on iPhone, iPad, and Mac. It does not promise that a file requiring full conversion will retain every feature of its source picture. Here is what each processing path means specifically for HDR10 and Dolby Vision, without trying to predict the fate of an untested file.
1. The outcome follows the picture, not the file extension
“Convert to MP4” describes the destination, not necessarily the journey. EncoX may have little to do to the video picture: it can move an already compatible picture into a different container without compressing it again. Or it may need to rebuild that picture before writing the new MP4. These paths have different consequences for HDR. If you want the broader explanation of why they differ, see container changes versus re-encoding.
Two videos can both be named MKV and still contain different video encodings or parameters. Likewise, two files can both be labeled HDR but require different work inside EncoX. Neither the extension nor the badge is a reliable shortcut to the outcome. For this question, look past the outside of the file and ask whether its picture can be carried over as it is.
In EncoX, keeping HDR and Dolby Vision depends on the picture-processing path. A container-only change preserves the eligible picture and its metadata; full re-encoding delivers the source bit depth up to 10-bit at 4:2:0, while the Dolby Vision statement only covers the container-swap route.
2. HDR10 and Dolby Vision: keep the picture and its metadata separate
You do not need a technical specification to make sense of the difference. Think of the video picture as one part of the file and the information accompanying that picture as another. HDR10 includes static metadata. Dolby Vision carries its own metadata. When you ask whether EncoX “keeps HDR,” you might be asking about the pixels, the information accompanying them, or both. Those are related questions, but they are not interchangeable.
That is why “it is still an MP4” is not an adequate answer. An MP4 is the resulting file type; it tells you nothing by itself about whether EncoX recompressed the picture or carried over the HDR10 and Dolby Vision information. Nor does successful playback, on its own, establish that the resulting picture has all the characteristics of the original. The distinction matters particularly when the goal is preservation, not merely obtaining a file that opens.
3. Container-only conversion: the picture stays intact and metadata can travel with it
When EncoX can use the picture already in the file, it only changes the container. The video picture is not recompressed, so neither its bit depth nor its chroma sampling changes. HDR10 static metadata is passed through, and the Dolby Vision information travels with the picture. This describes the container-swap route - it is not a blanket promise about every Dolby Vision file, because which path an individual file takes is settled by the job itself.
Keeping metadata and avoiding picture recompression are distinct benefits. The first describes information associated with the video; the second describes what happens to the picture itself. Together, they explain why a container-only conversion may suit someone who wants a more directly usable MP4 without having EncoX remake an already compatible HDR picture. They should not be stretched into a claim that every input carrying an HDR label will take this path.
When EncoX only changes the container, it does not recompress the picture: bit depth and chroma sampling stay as they were, HDR10 static metadata passes through, and the Dolby Vision information travels with the picture.
4. Full re-encoding: what the picture becomes, and how far our Dolby Vision statement reaches
When EncoX needs to re-encode the picture, the output follows the source bit depth, up to 10-bit, with chroma unified to 4:2:0 - a 10-bit source is delivered as 10-bit, a 12-bit source lands at 10-bit, and 4:2:2 or 4:4:4 chroma is not kept in the pixels. What happens to Dolby Vision dynamic metadata after a re-encode is something we have only checked on the no-repaint route, so we state neither loss nor survival here. If the purpose of your copy is to hold on to the source’s Dolby Vision information, do not send that file down the re-encoding route.
HDR10 requires equally precise wording, but not the same wording as Dolby Vision. On a container-only path, HDR10 static metadata passes through. On a full re-encoding path, the picture is rebuilt, so you should not expect an unchanged copy of the source’s HDR10 static metadata. It would be misleading to compress these different outcomes into either “all HDR survives” or “every piece of HDR information disappears.” The documented change to the picture is specific: chroma sampling becomes 4:2:0.
Bit depth is not a review of how a particular scene will look. It tells you something concrete about the resulting video, not how much you will personally like the image. What is clear is that a re-encoded picture at 4:2:0 is not the same as a 4:2:2 source. For an archival or production workflow that requires those source characteristics, the full conversion path is not an equivalent replacement.
Full re-encoding delivers the source bit depth up to 10-bit at 4:2:0 chroma. The Dolby Vision statement exists only for the container-swap route, and HDR10 static metadata should not be expected to pass through unchanged as it does during a container-only conversion.
5. Why we leave the unmeasured step out of the promise?
Full conversion changes the picture itself. Information attached to the original picture may no longer describe the newly processed picture accurately. Carrying it across simply to leave an HDR label in place could create a mismatch between that label and what the file actually contains - so on that step we draw no conclusion and let you check your own output. Bit depth does not depend on this kind of trade-off: it follows the source, up to 10-bit. This is a boundary of the processing, not an intermittent bug.
Read it as a clear product boundary rather than as a pleasant way of describing something we have not measured. EncoX converts files into MP4s that are easier to open directly; preserving every HDR characteristic of the source is not part of what the full-conversion route delivers. If that conflicts with what you need from a copy, the useful moment to know it is before converting, not after discovering the picture had already been remade.
6. There is another bit-depth boundary: 12-bit, 4:2:2, and 4:4:4
Even if your file does not advertise Dolby Vision, its picture may have characteristics you want to preserve. Our delivery line is explicit about the rest: 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 bit depth is kept. Do not reduce the preservation question to checking for a Dolby Vision label. What happens to the picture is at least as important as what happens to its accompanying metadata.
It also helps to distinguish the purpose of the new file from the purpose of the original. A video that opens in the intended viewing environment is not automatically an untouched copy of the source. EncoX creates a new MP4 rather than replacing the original file, so the source remains separate. That is useful, but it does not make the newly converted picture equivalent to the one you started with.
7. Can I tell which path my particular HDR file will take?
The relevant clues are the video encoding and parameters inside the file. If the picture is already of a type the device can play directly and its parameters are within the compatible range, EncoX may be able to change only the container. If the encoding or parameters fall outside that range, EncoX needs full conversion. That distinction is what determines whether the HDR10 and Dolby Vision information can travel with the picture or encounters the full-conversion limits described above.
Do not turn that rule of thumb into certainty about an individual file. A 10-bit label, a Dolby Vision badge, or an MKV extension does not settle the question. And even on the container-only path, the Dolby Vision metadata statement has exceptions. The actual processing result is what establishes what happened to a specific file. For the decision process itself, see how EncoX chooses a conversion path; this article focuses on the HDR consequences after that choice.
8. Limits: what this article cannot promise
- If a file requires full re-encoding, the output is delivered at its source bit depth up to 10-bit with 4:2:0 chroma; there is no reading for what Dolby Vision information survives that route, and HDR10 pass-through is only verified on the container-swap path.
- An extension or HDR badge cannot tell you in advance exactly what will happen to every part of a particular file. An individual outcome has to be established from actual processing.
- A 12-bit, 4:2:2 or 4:4:4 picture should not be treated as an identical copy in the output: 12-bit lands at 10-bit and chroma is unified to 4:2:0, while the bit depth itself is not pushed down.
- EncoX does not process DRM-protected content.
The practical question is therefore not merely “Does EncoX support HDR?” It is: “Will this file require re-encoding, and if it does, can I accept 4:2:0 chroma and a Dolby Vision outcome we have not measured?” That framing gives you a more useful basis for deciding what to do with this particular source.
Frequently asked questions
If I make an MP4, will Dolby Vision still be there?
On a container-only change, the Dolby Vision information travels with the picture. On a full re-encoding, we have no reading for that route, so nothing is promised in either direction. The MP4 extension alone does not answer the question.
Does the same thing happen to HDR10?
Not quite. HDR10 static metadata passes through on a container-only path, and the picture is not recompressed. On the full conversion path the picture is rebuilt, delivered at the source bit depth up to 10-bit with 4:2:0 chroma, and the metadata should not be expected to match the untouched source.
Why does a re-encode stop at 10-bit?
That is our own delivery line: the output only goes into the shape our release evidence already covers (HEVC Main 10, 4:2:0), so a 12-bit source lands at 10-bit and the depth is not pushed any further down. It is a deliberate boundary, not an intermittent bug. Once the picture is rebuilt we also avoid carrying metadata that may no longer match it - and that route has no measurement, so we do not claim it either way.
My file says Dolby Vision. Can I know the result before converting?
Not from that label alone. The deciding factors are the video encoding and parameters inside the file, and a specific outcome depends on actual processing. See how EncoX chooses a conversion path.
Is changing the container the same as re-encoding the picture?
No. With a container-only change, EncoX does not recompress the picture: bit depth and chroma sampling both stay. Full conversion rebuilds the picture, delivering its source bit depth up to 10-bit at 4:2:0. The two paths should not be described as having the same picture-preservation outcome.
Axiom One LLC — EncoX