Repository navigation
Prepare shared-memory capture fallback away from Program (#517) #797
Description
Activity
Execution evidence for #797 / PR #800, parent #517. Production Release core
421902508d1bf9ab0c9b8c92521e104df42e76c8; maintained harness, same mixed synthetic sources, 1080p60, two-frame buffer, Program MP4. Three pairs of two measured minutes, order AB/BA/AB, ten-second warmup. No build or other heavy QA ran during these trials. All failed trials are retained privately with raw snapshots, stderr, recordings and binary/harness hashes.Pair / mode Buffer underruns Scheduled deadline misses Recorded missing frames Render wakeup misses Mean Program work ms 1 inline 5 2 5 185 5.310 1 isolated 0 0 0 11 1.241 2 isolated 0 0 0 1 1.297 2 inline 0 0 0 133 4.656 3 inline 0 0 0 43 4.316 3 isolated 0 0 0 1 1.386 All three isolated trials pass aggregate buffer and recording judges, with zero audio sample loss, skipped production slots, output sequence gaps, worker failures or monitor replacements. Inline pair 1 fails; the harness correctly exits 1 for the retained control failure. Render wakeup misses remain diagnostic when absorbed by the buffer.
The earlier exact installed core (
77bac0c, hasha0f1e91d9d3041f01975cc6de72a69dbea7bee8bc3916e961f58764771f7f5f0) had isolated underruns 4/0/38 and mean Program work 6.898/6.603/7.582 ms. The native source before #797 is identical to that baseline (git diff 77bac0c a3e980d -- nativeis empty). Coarse two-second CPU stage windows after warmup show capture poll averaging 4.687–5.444 ms in the old isolated trials versus 0.047–0.084 ms after preparation moved off Program. This is measured stage evidence for the identified dependency, not GPU-query attribution of each residual miss.The preparation owner reports two active sources, no retirement backlog, zero admission/copy/pool failures and a stable logical resource charge of 115,200,032 bytes, below 512 MiB. Torn publisher writes are rejected and counted; upstream input-frame continuity remains unverified.
This is not release qualification. Physical WGC/UVC and real SDK acquisition, GPU/export completion, actual display/receiver identities, decoded A/V, total process/GPU memory and lower-tier hardware remain MISSING_EVIDENCE. Isolation and GPU ingress defaults remain unchanged. Review subsequently restored the legacy delivery-time stamp independently of the immutable capture observation and retained the last named refusal after recovery. The integrated head is being rebuilt/tested and will repeat the matched run; this table describes the exact earlier executable, not that newer head.
- added a commit that references this issue
on Oct 7, 2026 Integrated #797 evidence is complete for PR #800. Native build source
ddfb09806b55045760da29b8794e54d3e95a5fc4, production Release hashd8c9178b2f0a269d1bff052dfeaf39c559042d8d6b19644443ad5e83e63ddab2. Final PR head5691513b55ef7465d49c11fe375f92cbcbd42b9cadds only the support-bundle consumer and intake documentation; native and maintained harness source are identical to the measured build. All hosted gates pass that final head; 34 focused native regressions, 27 bundle tests and full 2,324-test MediaCore suite pass locally.Three repeated two-minute pairs (AB/BA/AB, ten-second warmup, same eight 1080p30 synthetic Zoom plus 1080p/1440p BGRA captures, 1080p60 Program/Preview/multiview, two-frame buffer, Program MP4):
Pair / mode Buffer underruns Scheduled deadline misses Recorded missing frames Render wakeup misses Mean Program work ms 1 inline 2 0 2 45 4.322 1 isolated 0 0 0 0 1.291 2 isolated 0 0 0 47 1.413 2 inline 0 0 0 1 4.459 3 inline 10 1 10 237 5.545 3 isolated 0 0 0 1 1.815 All isolated trials have zero skipped slots, sequence gaps, lost audio, monitor replacements or worker failures. Preparation stays ready with two sources and stable 115,200,032-byte logical charge, no refusal/pool/copy failures or retirement backlog. Torn writes remain counted/rejected. Coarse isolated capture-poll stage averages are 0.068–0.089 ms, versus 4.687–5.444 ms in the earlier installed-core trials. Both comparison runs preserve every failure and correctly exit 1 for failing inline controls. No build or heavy QA competed during their measured windows.
Additional owned camera diagnostic: a separate candidate executable beside the installed beta used its existing protected camera runtime, with synthetic Program counter markers, recording and actual OS MF receiver. Two measured native minutes pass buffer/recording/publisher checks, zero publisher replacement or exception deltas. Receiver after 30-second warmup passes 3,601 decoded 1080p60 samples over 59.999687 seconds: no invalid/repeated/missing/reordered identities, maximum interval 18.088 ms. Independently decoded recording passes 6,019 measured pixel identities after 30-second warmup with no counter or PTS gaps/repeats/reordering. The initial probe's immediate
startingassertion was corrected to wait boundedly for asynchronous readiness; that invalid attempt is retained. The owned test executable was removed and installed core SHA256 remains the originala0f1e91….The per-user camera alias was found pointing to October 4 while the machine owner was October 5; it was backed up and aligned only after verifying both CoreVideo ownership and the protected runtime hash. This remains #781's camera-ownership family, without attributing the drift to an installer absent a reproduction. Registered runtime hash is verified; service module inspection remains unverified.
#517 remains open. Real SDK/WGC/UVC acquisition, actual monitor display, decoded A/V synchronization, stream destination, full installed duration/fleet and serving-module provenance are not qualified by these diagnostic runs. Isolation and GPU ingress defaults remain disabled. Source-scoped monitor admission (#801) and worker-prepared selected BGRA/I420 uploads (#802) are the next approved engineering dependencies.
- added a commit that references this issue
on Oct 7, 2026
Parent #517; approved completion-plan boundary: prepare CPU fallback inputs away from Program.
Code audit of the mixed-source residual path: MediaCore::renderTick calls ICaptureDevice::deliverVideo; that invokes WinUiCaptureDeviceAdapter::captureVideoTick synchronously. For every new registered BGRA mapping the adapter allocates and copies the entire frame (1080p and 1440p in the maintained harness) under its mapping mutex before Program composition. This runs even when those capture sources are used only by multiview. Monitor isolation therefore removes optional compositing/export but still leaves this CPU ingress work on the Program deadline. The first two-minute isolated A/B trial still lost four buffer slots and one deadline; the next isolated trial lost none. Code establishes the remaining synchronous dependency, but does not assign every residual miss to this copy without controlled stage/fault evidence.
Implement off-Program bounded preparation and immutable completed-frame handoff through the existing adapter/source-bus seams. Preserve quality, identity/epoch, latest good frame and source capture time. Program must neither copy mapping pixels nor wait on the preparation/mapping lock. Registration/unregistration, resize/reconnect and shutdown must reject stale completed generations and release mappings on their owner. Keep queues/residency bounded and explicit on refusal. Do not silently enable GPU ingress.
Done when: real mapping pixels and lifecycle tests, 25ms blocked preparation/reader fault test with nonblocking Program consume, measured stage-cost comparison, maintained mixed-source A/B and memory/lifecycle accounting pass. Lower-tier/real capture qualification remains parent work. This slice follows #796; no independent ranking change.