Repository navigation
Recording write queues are shared with the live path and drop ISO under disk pressure #814
Description
Activity
- added a commit that references this issue
on Oct 7, 2026 Owner ruling October 8: implement this next, per the owner's explicit instruction in the working chat. Independent recording queues are now the next code priority ahead of the remaining delivery diagnostics. Preserve Program presentation cadence and attribute any improvement with stalled-writer and real-file tests; this does not repair the separate Zoom thumbnail mutex contention in #832.
Implementation is in draft PR #833. Owner-ranked #814 remains in progress.
Candidate 815f8b0 (Release, i7-14700K / RTX 4090, Windows build 26200): two-source 1080p60 baseline and 100 ms Program/ISO stalled-writer checks passed with decoded-file mux counts, AAC and audio-start alignment, zero steady-state recording loss, and zero Program buffer underruns.
The latest eight-source / 20 s / 100 ms Program-stall run also showed zero steady-state file video/audio loss, zero Program missing frames and zero Program buffer underruns. It still FAILED overall: 86 ISO pictures were shed during startup (plus 10 dispatcher startup pictures). First ISO work reached 299–426 ms; fixed per-file byte shares of the 512 MiB raw retention bound allowed about 13 startup pictures per ISO. Startup audio allowance/drain transitions are corrected; no audio packets were shed in the latest run. Retained files decoded with mux-frame counts matching measured file counts.
The immediate startup loss mechanism is established: slow first writes fill the raw-reference byte allowance before workers catch up. The underlying encoder/driver initialization cost is not yet attributed. The next necessary design correction is to absorb or avoid that initialization burst without silently exceeding the memory bound or moving work onto the live threads. This draft must not qualify or ship as a clean eight-source recorder until that check passes.
Full native suite: 1,528 passed before subsequent focused mux/startup changes; latest recording 28 and worker 10 passed, dispatcher 38 passed. C# 2,348, preferences 31, WinUI build passed. Exact-head CI pending. Evidence and candidate SHA256 manifests are retained in the workspace artifacts/recording-write-queues-814-* files; failed runs have not been deleted. Installed meeting, Preview presentation and virtual-camera receiver qualification remain unverified. No beta release/install occurred.
Owner clarification on October 8: recording need not start at the button click. It must already be recording when the UI reports Recording.
The spec now defines requested -> Preparing -> Recording: initialize selected pipelines off live threads, establish one shared actual capture boundary, and require committed real video plus configured audio in Program and every selected ISO before publishing Recording. Duration starts at actual capture start; request-to-start delay remains explicit. Missing sources, timeout/failure and Stop during Preparing cannot yield a false Recording indication. This does not permit relabeling already lost accepted media or independently rebasing files.
The current lifecycle uses Program progress for the producing transition and therefore needs an aggregate writer-readiness/commit gate. That correction belongs to #814 / draft PR #833. The clarification permits preparation latency instead of requiring a larger raw buffer to preserve the button-click interval.
PR #833 now includes owner-approved Preparing → shared capture → committed-media Recording behavior, pushed at a24046f.
Selected ISO pipelines open before capture using actual source geometry and configured audio. Source geometry changes while preparation is pending invalidate readiness; the opened file stays fixed once ready. Media across publication of the common capture epoch is retained. Program progress cannot claim Recording until every selected file has committed video and configured audio. Missing readiness times out after 15 seconds; Stop during Preparing cannot claim Recording.
Exact candidate validation: Release native and WinUI builds passed; dispatcher 41, recording-session 28, and recording-worker 10 tests passed. Two- and eight-source baselines passed. Eight-source 1080p60 / 20-second trials with 100 ms Program and ISO (zoom:101) stalls passed, including the UI committed-media assertion, decoded mux counts, AAC and 0 ms audio-start skew. All nine file queues had zero startup and steady-state video/audio loss; Program had zero missing frames and buffer underruns. Binaries and harness hashes, snapshots, recordings and previous failures remain retained locally. An initial ISO trial used a display name instead of the source ID and correctly failed because no stall occurred; the source-ID rerun observed both stall markers and passed.
This addresses the demonstrated initialization overflow (86 ISO startup pictures on the previous candidate). Dispatcher losses before capture remain separately visible. This is recording queue/startup evidence, not full eight-source 60 fps delivery qualification: upstream source cadence varies, and Preview/virtual-camera presentation remains unverified. #832 thumbnail mutex contention and the initiating encoder-export stall remain separate unresolved work.
Parent #814 acceptance remains open. PR is draft; exact-head CI, remaining qualification and installed long-run acceptance are outstanding. No beta was installed or released.
- added a commit that references this issue
on Oct 8, 2026 PR #833 merged into main at 51d6281. Beta beta-2026-10-08-51d6281 is now published and installed on the owner's desktop, with the stable desktop and Start menu shortcuts pointing at it:
https://github.com/iamfatness/CoreVideoPro/releases/tag/beta-2026-10-08-51d6281Fresh source verification: 1,533 production native tests, 2,348 MediaCore tests, 84 Control tests, 1,606 UI tests and bridge smoke passed. Main's tree matches the tested candidate; the shell was republished with the merge commit identity. Main production CI and CodeQL passed. The shell CI initially failed because a test child held trace.txt during WaitForTraceAsync; all six app-exit tests passed again locally and the unchanged-commit hosted retry passed. The original failure remains retained and #834 tracks the unranked test race.
Package, silent install/uninstall, duplicate/invalid-marker refusal, user-file preservation, installed-byte hashes, stable shortcut targets, verified media runtime and installed startup probe passed. All six uploaded asset digests match local files; the published tag matches the installed commit. Camera registration matches its manifest; live serving identity remains for receiver validation.
The owner plans a real-meeting bake tonight. Parent #814 acceptance remains open for that long-run test. Recording should remain Preparing until selected writers are ready and committed; the timer follows actual capture. Program/Preview/multiview/webcam delivery and finalized Program/ISO sync/continuity should be observed through the bake. Short queue tests do not establish complete eight-source per-frame presentation or unlimited runtime.
Recording and live presentation share a few-frame queue. A disk stall therefore drops ISO pictures instead of absorbing the stall in the file.
Spec:
docs/reference/recording-write-queue-spec.md(commit6d7a122).Why this is a recorder gap
The approved Program presentation buffer is 2 or 3 frames (default 3) and must stay that shallow. Audio is delayed to match. That is the live contract.
vMix separates that from recording. Its Recording Memory Buffer (recommended 10) exists so a slow disk does not become a dropped frame. CoreVideo Pro does not have that split.
Current path (
docs/reference/iso-recording.md):pendingIsoVideoQueue_, capped atkMaxPendingIsoFramesPerSource = 4, then drained byrenderIsoVideoTick.AsyncEncoderSinkis one dispatcher. Each ISO file has its ownRecordingTrackWorker.Pre-roll is out of scope.
Acceptance
Owner ranks. Do not jump the Now queue until ranked.