Codec stability cache

When Construct exports video, it first asks Qt's media stack which codec/container combinations actually work on your machine. Qt's metadata answer is optimistic — it lists plugins that might work — so Construct then live-fires each candidate (opens a recorder, pushes four small frames, watches for errors) and keeps only the ones that survive. That sweep takes between half a second and thirty seconds depending on how many plugins your system has.

Running that sweep on every launch would be a tax on every render dialog. Instead, the results are cached to disk under a fingerprint that captures the things that can actually change the answer:

• Kernel name + version
• OS product type
• Qt runtime version
• GPU vendor + device id (PCI hex, read from /sys/class/drm/cardN/device/ on Linux)

On the next launch, if all four match, the cached results are loaded in microseconds and no probe runs. If any one of them differs — you upgraded Qt, the kernel patched a driver, you swapped GPUs — the cache is treated as cold and a fresh sweep starts.

Where it lives

~/.local/share/OctoMY™/OctoMY™ construct/codec-stability.json   (Linux)
~/Library/Application Support/OctoMY™/OctoMY™ construct/codec-stability.json   (macOS)
%LOCALAPPDATA%\OctoMY™\OctoMY™ construct\codec-stability.json   (Windows)

The exact path depends on your Qt build of QStandardPaths::AppDataLocation. The file is plain JSON, human-readable, and safe to delete.

When to nuke it manually

Three cases warrant a manual delete:

• Driver weirdness across reboots. If the GPU presents a different identity (rare, but happens with hot-plugged eGPUs or KVM/passthrough lifecycle changes), the fingerprint may catch one identity and miss the other. Deleting forces a fresh probe.
• Stale results after an out-of-band Qt config change. If you rebuild Qt locally with a different set of FFmpeg plugins (e.g. enabling libx264 software fallback), the runtime Qt version string may not change. The fingerprint won't catch that; delete the cache to re-discover the new working set.
• Diagnostic. If the Export dialog is missing codecs you expect, deleting the cache and relaunching gives you a clean log of what the probe is doing.

rm -f ~/.local/share/OctoMY™/OctoMY™\ construct/codec-stability.json   # Linux

There's no UI action to wipe the cache from inside Construct (yet). The file is small, single-purpose, and entirely safe to delete; the worst case is a one-launch slowdown while the probe re-runs.

What's inside

{
  "fingerprint": {
    "kernel":  "linux:6.12.88+deb13-amd64",
    "product": "debian",
    "qt":      "6.10.1",
    "gpu":     "0x1002:0x677b"
  },
  "results": [
    { "id": "h264",  "container": "mp4",  "tier": "default" },
    { "id": "vp9",   "container": "webm", "tier": "cautious" },
    { "id": "mpeg4", "container": "mp4",  "tier": "default" }
  ]
}

tier is default when the codec passed Qt's normal hardware-first probe path, or cautious when it only passed after hardware encoders were forcibly disabled (see "Modern codecs are unavailable" in the export-animation guide).

Sandboxed environments

If the gpu field is empty in your cache file, that means Construct couldn't read the PCI vendor data — usually because the process is sandboxed (Flatpak, Snap, container) and /sys/class/drm/ is hidden. The cache still works, but it can't distinguish two GPUs of the same vendor:device pair. In practice that's a corner case you'd only hit if you swap GPUs without changing kernel or driver, which is rare.