Back to blog

Gallery / P1 · CineX

Why CineX Is Instant for Some Videos and Slower for Others: It Checks the Codec First

CineX does not decide how to convert a video from its filename or from an extension such as .mkv or .mp4. It first reads the codec information inside the file. If the video is already suitable for the target MP4, CineX can usually change the container without recompressing the picture. If the picture itself has to be rebuilt, CineX uses a full conversion path instead. That is why two files with the same extension can finish very differently: one may take only a few seconds, while another can take minutes.

That decision is not a promise that every familiar-looking file will take the fast path. Video parameters can still fall outside the compatible range, and some high-frame-rate, high-bit-depth material takes substantially longer. A file that requires full conversion but contains no audio track is also rejected in the current version. This article is only about how CineX chooses a conversion path, not about treating an extension as a speed label.

1. CineX checks the codec first, then decides whether the picture has to change

When CineX receives a video, the important question is not what the filename ends with. The important question is what kind of video is actually stored inside the container and whether that picture can already fit the target MP4 without being rebuilt.

That produces two outward-facing paths. On the faster path, CineX keeps the existing picture data and changes the container as needed. On the slower path, CineX performs a full conversion of the picture. These are not user-selectable speed modes; they are different responses to the file CineX has been given. For the general technical distinction between those two operations, see container changes versus full re-encoding.

CineX decides from the codec inside the file, not from the extension outside it. Two files named .mkv or .mp4 do not automatically follow the same conversion path.

2. The first step is to find out what is actually inside the file

An extension tells CineX what kind of container it is opening, but it cannot answer the more important question: what codec carries the picture? CineX reads that codec information first and uses it to decide whether the existing video can be kept for the output MP4.

For example, H.264 8-bit and HEVC 8/10-bit video can take the faster path when the rest of the picture parameters are compatible. Video encoded as Xvid, VP9, or AV1 requires full conversion. Even a familiar codec name is not an unconditional guarantee, because picture parameters outside the compatible range can still push the file onto the full-conversion path.

3. The faster path: if the picture can stay as it is, CineX does not recompress it

When the video is already suitable for the target MP4, CineX prefers to change the container without recompressing the picture frame by frame. In device tests, files on this path finished in seconds. That makes “a few seconds” a useful description of this class of file, but not a promise for every conversion.

Audio is considered separately. Compatible audio can be kept, while incompatible audio is converted to AAC. That does not force CineX to recompress an already compatible picture. The practical rule is narrower and more precise: CineX avoids reworking the video when the video itself does not need to be reworked.

The fast result is conditional. CineX is fast here because the existing picture can be carried into the target MP4 without being recompressed, not because a particular extension receives special treatment.

4. The slower path: CineX performs a full conversion when the picture cannot be used directly

If the video cannot be carried into the target MP4 as it stands, CineX has to rebuild the picture. That is a fundamentally larger job than changing the container, so the time scale changes from seconds to minutes.

A full conversion moves into minutes, usually longer than the clip itself. Once a file reaches this path, the dominant fact is that the picture must be processed again, not whether the filename says MKV, AVI, MP4, or TS. Full conversion also has explicit image-quality boundaries: 10-bit/HDR material becomes 8-bit, and Dolby Vision metadata is not retained. Those details are covered separately in how CineX handles HDR and Dolby Vision.

5. Why two .mkv files can have completely different timings

This is the easiest place to draw the wrong conclusion from a filename. Take two .mkv files. If the first contains compatible H.264 video, CineX may only need to adjust the container, leaving the picture untouched. If the second contains Xvid video, CineX has to perform a full conversion. The extension is identical; the codec inside is not.

So the question “How long does MKV to MP4 take?” cannot be answered from the extension alone. CineX reads the codec first and only then chooses the path. For the MKV-specific case where the goal is to keep the existing picture whenever possible, see when MKV can become MP4 without recompressing the video.

The same .mkv extension can lead to two very different outcomes. An H.264 file may finish in seconds, while an Xvid file may take minutes, because the codec—not the three letters in the extension—determines the path.

6. What pushes a file onto the slower path

The clearest trigger is a video codec that cannot be used directly for the target MP4. But the codec name is not the whole decision. If the actual picture parameters fall outside the compatible range, CineX uses full conversion even when the codec family itself looks familiar. There is no single public threshold that can accurately reduce this to “below this number is fast, above it is slow.”

High-frame-rate, high-bit-depth material shows the difference clearly. In current testing, 120 fps high-bit-depth video runs at about real time: a 10-minute source takes about 12 minutes to convert. That figure is useful as an example of a file that genuinely needs waiting time, not as a universal rate for every full conversion.

7. Boundaries: the decision logic is not a universal pass

8. The useful expectation is simple: codec first, timing second

The most useful way to read CineX timing is to start with the codec decision, not the filename. CineX first determines whether the existing picture can be kept. If it can, the conversion may finish in seconds. If it cannot, CineX performs a full conversion and the time moves into the minute range.

That is also why CineX does not expose a “fast” or “slow” quality tier for the user to choose. The path comes from the file's codec and picture parameters, not from a paid speed switch or a manual preset. CineX always produces MP4, but the work required to get there depends on what is actually inside the source file.

Common questions

How long does a CineX conversion actually take?

There is no fixed time that can be predicted from the extension alone. When the picture can be kept, the faster path is usually a matter of seconds. When the picture requires full conversion, expect minutes rather than seconds.

Why does one MKV finish in seconds while another takes much longer?

Because CineX does not choose a path from the .mkv extension. It reads the codec inside the file. Compatible H.264 can use a container-only path, while Xvid requires full conversion, so two MKV files can have completely different timings.

How does CineX decide which path to use?

CineX reads the codec information inside the file and considers the actual picture parameters. If the video can already fit the target MP4, CineX keeps the picture and adjusts the container. If the picture has to be rebuilt, CineX performs a full conversion.

Can a common codec still end up on the full-conversion path?

Yes. The codec name is not the only condition. If the actual picture parameters are outside the compatible range, CineX still uses full conversion. CineX does not publish those internal thresholds as a fixed public cutoff.

If a conversion is slow, does that mean CineX chose the wrong path?

Not necessarily. Minute-scale processing is expected when the video itself has to be rebuilt. In current testing, one demanding example—120 fps high-bit-depth video—runs at about real time, with a 10-minute source taking about 12 minutes.

Axiom One LLC — CineX. Figures current as of 24 September 2026.