Windows build verification — the NVIDIA path is still unproven

[johan-bell]

12 Aug 2026: the first Windows installer was built, and it installs. The build
runs on a windows-latest GitHub runner (.github/workflows/windows-ffmpeg-verify.yml),
which produced Luminary Media Convert Setup 0.0.1.exe (156 MB, unsigned), and Johan
installed it on a real Windows PC — the installation completed without trouble. Before
this, nothing in this project had ever been built for or run on Windows.

Two Windows-only defects were found in the process, neither reproducible on macOS:
unzip/mv/file do not exist there, and fs.rename cannot cross volumes (the
runner's temp is on C: while the checkout is on D: — EXDEV). Both fixed.

Confirmed by execution on the runner, not inferred: cuda in -hwaccels,
h264_nvenc / hevc_nvenc / av1_nvenc / libx264 in -encoders, scale_cuda in
-filters, and the licence — --enable-gpl --enable-version3, so v3-or-later.

Confirmed on a real Windows PC, 12 Aug 2026: the installer runs, SmartScreen did
not warn despite being unsigned, the app opens, and the embedded binaries are in
place — resources\ holds ffmpeg.exe, ffprobe.exe, GPL-3.0.txt and
LICENSE-ffmpeg.txt. It installed under AppData\Local\Programs, no admin rights, as
perMachine: false intends. The GPL-3.0 text and no GPL-2.0 is the per-build licence
rule working in a shipped install (item 40).

The workflow now asserts this itself rather than trusting it: the packaged
win-unpacked/resources must contain both binaries, the notice and a GPL text, and the
shipped ffmpeg.exe is run to prove it is real (144 MB, n8.1.2-34-g9b6c8969e0).
electron-builder treats a missing extraResources source as a warning, so
without that step an installer could ship with no encoder and nothing would notice.

Still unverified, and each needs a Windows machine rather than a runner:

• Encoding. Blocked outside this repository: the CMS has no upload flow yet, and the
  app has no way to open a session without one. Nothing Windows-specific is suspected —
  the binaries are present and the same code path works on macOS

• Whether the encode path handles Windows paths with spaces, once it can be run at all

• luminary-convert:// protocol registration through the installer

• safeStorage (DPAPI-backed, expected to be fine) and the credential sidecar

• The resourcesPath lookup with .exe suffixes, and paths containing spaces

• NVENC encoding on real NVIDIA hardware. Done, 13 Aug 2026. Tested by Johan
  on a Windows PC with an NVIDIA GPU, using the cross-compiled binary from
  ffmpeg-build.yml:

  • h264_nvenc encoded 50/50 frames. There is no software fallback for that encoder —
    without a GPU and driver it fails to load nvEncodeAPI64.dll — so this is a real
    hardware encode.
  • The full pipeline works: -hwaccel cuda -hwaccel_output_format cuda in,
    scale_cuda to resize, h264_nvenc out, with the output reported as
    cuda(tv, progressive) — frames stayed in GPU memory the whole way. This is the
    path FfmpegService takes on an NVIDIA machine.
  • scale_cuda was the part that could not be verified anywhere else: its CUDA kernels
    are compiled by clang through --enable-cuda-llvm rather than NVIDIA's nvcc, and
    a GPU-less runner cannot say whether that produces working kernels.

  Not established: throughput. Both tests used a 320x240 two-second clip, where
  CUDA context setup and first-run kernel JIT dominate (5.17 s elapsed for 2 s of
  video). A speed comparison needs a 1080p file on local disk, not a network share

Also needed:

• Verification of the things that differ from macOS: luminary-convert:// protocol registration through the installer, safeStorage (DPAPI-backed, should be fine), the resourcesPath binary lookup with .exe suffixes, path handling with spaces (shellQuote covers the execSync probes; execFile callers are unaffected), and whether Windows Defender / SmartScreen blocks an unsigned installer outright
• Confirm the NVIDIA acceleration path end-to-end, which no developer machine in this project can currently exercise

---

---

Migrated from Todo.md item 5, which is removed as the repository is prepared to go public.

[johan-bell]

Adding a Windows check to this: does the app actually come to the front when the CMS opens a session?

#221 fixes a macOS bug where it did not — focusWindow() returned early when the app was running with no window, which on macOS is an ordinary state because closing the window does not quit. Verified fixed there.

The same PR adds a Windows branch that is reasoned but never run:

if (process.platform === 'win32') {
    win.setAlwaysOnTop(true);
    win.show();
    win.setAlwaysOnTop(false);
    win.focus();
    return;
}

Windows refuses a foreground change requested by a process that does not hold it, and this request arrives over loopback from the browser that does. win.focus() alone is expected to flash the taskbar button rather than raise the window; app.focus({ steal: true }), which the macOS path uses, is macOS-only.

What to check on a Windows machine, with the CMS on a real origin:

1. App running, window open, browser in front → does Encode raise the window?
2. App running, minimised → does it restore and raise?
3. App not running → does the luminary-convert:// link launch it, and does it land on the right session? (second-instance should carry it, since Windows has no open-url.)
4. Does the window stay above other windows afterwards? It should not — the always-on-top flag is dropped immediately.

If (1) only flashes the taskbar, the toggle is not enough and the next thing to try is a brief win.setSkipTaskbar / moveTop, or accepting the flash as the platform's answer.