# CoreMF engineering evidence — website appendix Status as documented 2026-11-03. Historical results identify particular artifacts; they do not qualify a newer build, arbitrary configuration or public deployment. ## October 27 local Linux baseline CoreMF 0.4.0; FFmpeg 8.0.3; cpp-httplib 0.63.0. - Runtime image SHA-256: 8fd0e80dac817badc3a47b4621e2fabb43c5292efbfc55a6f33eadec8eb61d95 - Server image SHA-256: c878f5d09d8f089b084919c3f7a6a3011d1be6f88e0efd88ac86f8262af17d0d - SDK manifest: a1b0ae61443cbdf3e6643fed8fe33a696a333eb304f8859748119cc84f765c6c - 37 local media/BYO/API/browser/mount/shutdown/restart checks. - RTC CPU soak: 3,600 seconds, two rooms, four Chromium publishers and four viewers; generated 320x180/25 fps H.264 plus stereo Opus. - Eleven reconnect cycles passed using viewer recreation. Retained old-viewer SRTP continuity is unsupported. - 24–26 fps after warm-up; recorded p95/p99 frame latency 42/46 ms and p99 A/V skew 91 ms within that local fixture. No generalized end-to-end latency claim. - Median server RSS 50.02 to 51.51 MiB. - Recorded image scans: 28 medium/8 low findings per image; no high/critical or Node findings in that dated scan. No suppression file. Remaining findings and deployment conditions require their recorded disposition. These are source-document summaries, not tests rerun by the website. ## October 29 browser-effects and rebuild work The recorded R7.12 work rebuilt SDK/source and Runtime/Server packages, verified eight tier/module archives, relocated consumers, native/BYO/media/auth paths, ten served asset hashes and 18 packaging regression tests. Browser-effect verification: 120 checks at 360p/720p on four publishing pages, Linux Chrome 156/local CPU SFU. Browser effect-delivery measurements are not end-to-end RTC latency. This work does not renew the October 27 soak/security scan on the rebuilt artifacts. Broader browser/device and network scope is separate. ## Website media and application proof The site contains genuine CoreMF output from generated patterns and separately sourced CC0 waterfall and sports footage; no customer footage or fabricated screenshot is used. The homepage's 1280×720 waterfall example was processed through the Windows development runAPI with a CoreGL production compositor/shader and CoreAudio gain. It adds a color reveal, bloom, vignette, colorful sparkling bubble particles, animated zoom/detail lens and procedural titles. The 14-second input has 350 decoded frames; the 13.96-second output has 349. Both fully decode, including output audio; frame-for-frame equivalence is not claimed. Source credit, measured audio levels, runtime identities and reproduction steps: [real-footage provenance](../assets/demos/real-footage.md). The original four-second PiP example was executed on an existing Windows MSVC Debug development runtime, not the Linux commercial candidate. Media configuration, runtime identities and reproduction steps are in [the original provenance](../assets/demos/README.md). The Technology page's current four-source sports grid uses four independently recorded CC0 clips: volleyball, bouldering, lead climbing and a body-surfing viewpoint. CoreMF decodes the staged inputs, composes them with CoreGL and encodes a silent 1280×720 H.264 MP4. All 350 frames decode at 25 fps over 14 seconds. Source declarations, credits, configuration and verification: [sports-grid provenance](../assets/demos/sports-grid.md). The earlier generated 15-second CoreGL PiP/CoreAudio example has 375 decoded video frames and a measured −6.0 dB audio gain. The retired generated grid's historical recipe is also retained in [production workflow provenance](../assets/demos/production-workflows.md). ## Installed SDK plugin integration The release record documents a native ABI template compiled from the source SDK and loaded through the installed API runner to process real video. The decoded output matched the no-plugin path frame-for-frame. The binary application SDK does not include plugin-authoring headers; the matching development delivery is separate. This is recorded native-video integration evidence, not a new website test of Python/JavaScript, audio-sample processing or an AI model package. It does not qualify arbitrary customer plugins or grant source/deployment rights. ## October 30 evaluation workflow The media-workflows archive supplies CPU processing/transcoding and optional GPU filtering/composition examples using the same reviewed CC0 waterfall footage. It includes CPU encoder configuration, original scene JSON/shader, audio-gain configuration, source-rights record and a SHA-256 manifest. No CoreMF runtime, SDK header, model or customer encoder is in the archive. The runtime is supplied separately under agreed terms. RTC/gateways and frame/sample plugins have their own evaluation paths; these file examples do not demonstrate those integrations. The CPU command was executed with hardware decoding and encoding explicitly disabled. It resized to 640×360, applied audio gain and selected software AV1 encoding. A complete error-checked decode passed: 350 AV1 video frames at 25 fps, 14 seconds, plus AAC audio. No GPU node was used. An AV1-capable player and a runtime providing the configured software encoder are required. The optional GPU API-runner command was executed on a Windows x86-64 development runtime with Intel UHD 770, a real GPU renderer and automatic eligible hardware encoder selection with native GPL encoder selection disabled. The chosen video encoder was Intel hardware H.264; audio was AAC. The complete output was decoded and checked separately from the command's exit status. - Input: 14 seconds, 1280×720, 25 fps, 350 video frames and recorded audio. - Output: 349 decoded H.264 video frames at 1280×720/25 fps, approximately 13.96 seconds, with decoded AAC audio. One fewer video frame than the input; frame-for-frame equivalence is not claimed. - GPU effects: color/effects, vignette, animated particles, detail lens and titles. - The native Windows `-mft` alternative failed this workflow at encoder drain. It is not the verified command or evidence of success for that alternative. The standalone Windows SDK fixture initially failed to load without its runtime dependencies. The extracted workflow ran after development runtime dependencies were configured explicitly. This does not establish a relocatable commercial Windows package. The development runtime is not an audited commercial package. Selection flags do not relicense its dependencies. Linux/macOS, other GPU/encoder combinations and customer package qualification require their own checks. This is not an RTC, plugin, AI, latency/capacity or end-to-end GPU-residency qualification. ## October 31 evaluation limits and November 3 native verification The Linux SDK/demo candidates enforce configurable defaults of 30 days from build issuance, maximum 1280×720 input/output video and 300 seconds per graph session. Standalone SFU/meeting and LL-HLS HTTP services use a lifetime from SFU/store initialization; reconnects or requests do not reset it. Actual five-minute runs, resolution changes, active expiry and configured limits passed. Ten archives passed package checks; extracted limited and commercial SDKs each passed 15 installed-consumer checks. No public trial download or limited CoreServer container is supplied by those checks. Native Windows and macOS verification was confirmed by the product owner on November 3. This closes the native target verification task; it does not extend the dated workflow measurements above to arbitrary packages, GPUs, codecs or public-network deployments. Exact customer artifacts and supported profiles remain part of release approval. ## Scope limitations - Current commercial packaged candidate: Linux x86-64; release approval pending. - Native Windows/macOS verification is owner-confirmed; ARM64, additional GPU profiles and optional packs need separate delivery qualification. - Cloud/TURN, large rooms, dynamic MCU and HD RTC capacity are not established by the small local CPU fixture or offline composition videos. - WHIP is preview; LL-HLS and production DRM/provider/player compatibility are profile-specific. - No universal zero-copy, automatic recovery, GPU inference equivalence or native/BYO performance/latency equivalence claim. - SDK package includes no customer GPL executable or default Python AI model pack.