Sync 1080p60: bounded camera frame acquisition
12 September 2026 · Research report · Revision 2 · Web and desktop receiver measurements
Decision: retain the bounded Sync camera receiver queue in Noisedeck 9fec698233ed36e3f95826614065a558947d0812. Two web comparisons measured increases of 12.689 and 14.045 unique final frames/s. Desktop comparisons measured +4.950 and −0.447 frames/s. The candidate increased mean marker age in all four pairs. These short comparisons support the implemented delivery change but do not establish sustained 60 unique frames/s or long-session stability. E1
The primary comparison is ordinary HTMLVideoElement texture selection versus independent acquisition of owned camera frames followed by bounded FIFO consumption. This report distinguishes paired measurements collected on 11 September, candidate-only verification on 12 September, and instrumented timing diagnostics. It updates the 11 September research plan; the measurement datasets have not changed in this editorial revision.
1. Question and design
The question is whether retaining ownership of arriving camera frames reduces repeated or missed selection at the receiver's periodic texture-update boundary. The baseline updates the media texture from a mutable video element. The candidate obtains frames through MediaStreamTrackProcessor, converts each accepted timestamp to an owned ImageBitmap, and consumes a bounded queue from the existing media animation loop.
Each platform has one baseline-first pair and one candidate-first pair. Each arm contains approximately 20 s of final-pixel measurement. Runs were serial on one Apple Silicon host. Neither the measurements nor their temporal ordering constitute a continuous endurance run. E1
Table 1. Experimental configuration
| Parameter | Configuration |
|---|---|
| Product path | Noisedeck A → Sync → Sync Camera → Noisedeck B media effect → final rendered pixels |
| Resolution and effects | 1920 × 1080; A: testPattern(pattern: 0, gridSize: 4); B: media(); output o0 |
| Process isolation | Disjoint producer and consumer main, renderer and GPU process trees, verified before and after measurement |
| Web runtime | Chrome 152 |
| Desktop runtime | Electron 42.3.0 / Chromium 148.0.7778.180; application source entry, not packaged-installer acceptance |
| Controlled source change | Receiver media manager and Sync camera queue. The producer and native camera path were held fixed within each comparison. |
| Source revisions | Producer: b7c0cb0a. Receiver timing base: 0cc43a7ebef09337c71594b532842599e38d898d, with the recorded candidate source applied. The delivered manager and queue are byte-identical to the measured candidate. |
2. Measurement contract as applied
Unique final delivery rate is the number of distinct ordered source identities decoded from final rendered pixels divided by the measurement duration: f_unique = N_distinct / T. Render-loop entries, camera callbacks and successful native enqueues are not substituted for this measurement.
Complete-second counts assign first observations to start-relative 1000 ms buckets. Partial endpoint buckets are retained separately. The dataset includes duplicate captures, complete seconds below 50 frames, zero-delivery seconds and the longest consecutive interval below 50. A count of 61 in one bucket can reflect boundary timing and does not imply a source rate above 60 frames/s.
Marker age is the interval between marker insertion and observer capture, estimated from unadjusted same-host browser epoch clocks. These values are not independently calibrated cross-process latency or physical display latency. The marker-age comparisons in Table 2 retain that clock limitation.
Full 1920 × 1080 RGBA equality, deliberate one-pixel failure controls and a texture-poisoning recovery check preceded timing. Effects, camera selection, source module identity and process isolation were checked again after timing. Observer acceptance and cleanup checks passed in the retained comparisons. Observer work can affect scheduling; the numerical results apply to this measurement configuration. E1 E2
3. Receiver implementation
- Acquisition uses one track processor with
maxBufferSize: 1. Conversion is serial; acquisition can continue while an asynchronous texture upload is in flight. - The pending-bitmap FIFO is bounded at three entries. Initial consumption and refill wait for two entries. An additional arrival closes and removes the oldest pending bitmap.
- The existing media animation loop consumes at most one pending bitmap per tick. Uploads do not overlap. The bitmap remains owned until the upload result is available and is then closed.
- A per-track timestamp watermark rejects duplicate timestamps and survives reader stop/start on the same track. Invalid or decreasing timestamps fail the owner rather than reset that watermark.
- Camera replacement, pending acquisition, pause and control rebuilds use generation checks and cleanup barriers. Stale completion cannot publish replacement-camera metadata or overlap an earlier texture owner.
- Physical cameras and browsers without the required APIs retain ordinary video-element uploads. An active owned-frame path that fails reports an error and requires a new camera acquisition for recovery.
The semantics are at most one consumption per accepted track timestamp. This is not exactly-once end-to-end delivery. Overflow is allowed to discard frames, the renderer may display its prior texture again, and a camera timestamp is not a verified unique Sync source-picture identity. E3
4. Paired results
Table 2. Retained integrated-product comparisons, 11 September 2026
Slash-separated values are baseline / candidate. Relative change is 100 × (candidate FPS / baseline FPS − 1). “Reverse order” means candidate first, then baseline.
| Comparison | Duration, s | Unique frames | Unique FPS | Δ FPS | Relative change | Mean marker age, ms | p95 marker age, ms |
|---|---|---|---|---|---|---|---|
| Web, first order | 20.023 / 20.005 | 946 / 1199 | 47.246 / 59.935 | +12.689 | +26.86% | 35.10 / 62.41 | 49.40 / 63.80 |
| Web, reverse order | 20.003 / 20.004 | 901 / 1182 | 45.043 / 59.088 | +14.045 | +31.18% | 36.15 / 62.96 | 49.70 / 65.90 |
| Desktop, first order | 20.002 / 20.002 | 1096 / 1195 | 54.795 / 59.744 | +4.950 | +9.03% | 35.88 / 50.94 | 50.90 / 52.30 |
| Desktop, reverse order | 20.002 / 20.001 | 1193 / 1184 | 59.644 / 59.197 | -0.447 | -0.75% | 34.25 / 50.78 | 35.40 / 52.40 |
The observed web increase repeated in reverse order: +26.86% and +31.18%. Desktop showed +9.03% in the first pair and −0.75% in the reverse pair. Mean marker age increased by approximately 27 ms on web and 15–17 ms on desktop. The results therefore contain a throughput–age tradeoff and a mixed desktop result, not a uniform improvement across all runs. E1
Figure 1. Upper panel: the four paired comparisons. Lower panel: complete-second counts from the candidate-only checks described in section 5. All partial endpoints remain in the measurement dataset. Full-size figure.
5. Current product verification
The exact candidate was restored to the product checkout and checked on 12 September. These runs had no contemporaneous baseline arm and are not new before/after comparisons.
Table 3. Candidate-only verification, 12 September 2026
| Runtime | Duration, s | Unique frames | Captures | Unique FPS | Minimum complete-second count | Complete seconds below 50 | Longest consecutive interval below 50, s |
|---|---|---|---|---|---|---|---|
| Web | 20.003 | 1068 | 1200 | 53.392 | 48 | 4 | 2 |
| Desktop | 20.003 | 1197 | 1200 | 59.841 | 59 | 0 | 0 |
The web check contained four complete seconds below 50 frames, with a two-second consecutive interval and a minimum of 48. Desktop contained no complete seconds below 50 and had a minimum of 59. The web result demonstrates remaining temporal variation despite the higher rates in the earlier paired tests. E2
Both checks passed exact-pixel, effect-selection, real-camera and process-isolation controls. Both producer and consumer exited with no surviving processes or unsaved-change prompts. The local Node suite passed 896 tests, with one skip and no failures; changed-file lint, deployment CI and production health checks passed. The served manager and queue hashes match the tested source. This verification does not certify a newly packaged desktop installer. E3
6. Frame selection timing
The later native timing traces attributed all 4,802 whole-window public texture-upload invocations to one native current-frame query each. Frame versions with no invocation-attributed query had complete lifetimes strictly between consecutive queries. Median unqueried lifetimes were approximately 11–13 ms; attributed-query intervals were approximately 16.7 ms. E4
Let a native frame version remain current over I_j = [s_j, s_(j+1)), and let upload selection occur at times q_i. If no q_i lies in I_j, that version is never selected by those uploads. Equality of average acquisition and upload frequencies does not exclude this condition when inter-arrival intervals vary. These traces identify selection opportunities; they do not establish an exact join from every native timestamp to a decoded source-picture identity.
Callback traces also recorded changed selections without intervening callbacks and callback metadata differing from the next upload selection. Callback notification therefore did not provide frame ownership in these runs. The corrected desktop clock diagnostic retained this finding after a prior clock-tolerance failure. A completed socket write addresses an earlier boundary; it does not establish which frame the later camera upload selects. The retained queue addresses ownership at acquisition. No higher-frequency producer or callback-only gate was qualified by this delivery. E4
7. Related diagnostic results
Table 4 records the other completed screens and the unfinished renderer prototype from the same investigation. Instrumented rates are not treated as product performance improvements. The underlying decision receipts are hash-bound in the public findings dataset. E4
Table 4. Diagnostic findings and implementation disposition
| Cycle and mechanism | Finding and disposition |
|---|---|
| A2: Extension consume cycle | Empty consume calls completed promptly: median 0.253 and 0.267 ms. Immediate rearming would risk polling. Instrumentation neutrality was not established; the 4 ms wait was left unchanged. |
| B: Bounded camera queue | Owned frame acquisition plus a three-bitmap FIFO produced repeatable web gains. Desktop signs differed. This exact integrated candidate is now retained and delivered as a measured progress improvement. |
| C: Native enqueue notification | Initial web and desktop final-pixel comparisons had opposite signs. The notification wake candidate was not retained. |
| E: Export buffer usage hint | The web delivery sign reversed in reverse-order confirmation. The shared STREAM_DRAW candidate was not retained. |
| F–G: Provider cost and idle Syphon work | Provider-cost diagnostics motivated an idle-client skip. Its camera screen was inconclusive after endpoint clock problems; no product optimization was retained. |
| H: Measurement windows | Receiver-local monotonic measurement windows and bounded callback tail accounting were retained in later diagnostic helpers. They are measurement corrections, not product frame-rate improvements. |
| I–J: Independent export polling | Passive queries observed ready fences before the ordinary poll. A fixed 4 ms independent poll then reduced web delivery, increased source-pressure refusals and worsened low-rate intervals. It was rejected. |
| K–L: Arrival versus actual texture selection | In instrumented runs, track clones contained pictures missing from final samples. Those pictures were not observed in the ordinary texture uploads; selected final callbacks matched the latest uploaded picture. Upload observation itself reduced rates. |
| M–O: Video callback subscription | A public callback subscription alone did not establish a consistent benefit. Invalid setup evidence was retained separately and corrected runs were not promoted into a product claim. |
| P–Q: Renderer payload identity | Exact loaded core provenance was established. The receiver-core comparison did not establish a consistent improvement. |
| R–S: Observer overhead | State queries dominated observer wall time. Removing one alignment query mostly moved its wait to the next query; a small average gain came with worse low-rate intervals. No product change was retained. |
| N, T–U: WebGPU export correctness | A vertical orientation defect was corrected and tested in upstream source and a corrected engine fixture. The subsequent backend comparison had mixed build results. The correctness work is separate from this delivery; a global WebGPU switch was not shipped. |
| V–W: Native upload-call attribution | All 4,802 whole-window public upload calls contained one native current-frame query. Unqueried frame lifetimes fell between consecutive upload queries; their medians were about 11–13 ms against query intervals around 16.7 ms. This is direct evidence of missed selection opportunities. |
| X–Y: Callback freshness and clock model | Web and corrected desktop traces showed selection changes without intervening callbacks, and callback metadata that differed from the next upload. Callback notification does not pin a frame. Native timestamps and decoded picture IDs were not joined per picture. |
| Z: Owned-frame renderer prototype | VideoFrame upload component checks passed 108 cases across WebGL2/WebGPU and Chrome/Electron. The full frame-driven renderer remained unfinished and had review findings. No camera delivery gain was measured for it; its experimental changes were archived outside product checkouts. |
8. Decision
The original queue qualification withheld retention because the two desktop comparison signs differed. The implemented decision retains the repeated web gain as measured progress while reporting the desktop variation and buffering cost. The queue policy and source bytes were not changed between the retained candidate and this delivery.
The delivered change is in Noisedeck commit 9fec698233ed36e3f95826614065a558947d0812, included in production merge 84e0f2a4e5a1156d666783825a3033b13fcad362. Native camera-extension timing, transport policy, the separate upstream WebGPU orientation correction and the unfinished frame-driven renderer were not included in this change. E3
9. Limits
- Four short sequential pairs on one host do not estimate long-session reliability or population-level effects. Sustained 60 unique frames/s remains unestablished.
- The candidate-only verification runs cannot establish a fresh relative performance gain. The web verification includes low-rate intervals.
- The controlled checkerboard path does not qualify representative shader content, 4K, Windows camera behavior or newly packaged desktop installers.
- Web and desktop Chromium versions differ. Cross-build differences do not isolate the desktop shell.
- Observer work and instrumented callbacks can alter scheduling. Native timestamps, callback metadata, accepted uploads and decoded final picture identities remain separate populations unless explicitly joined.
- Marker-age estimates lack independent cross-process clock calibration. Whole-host power observations cannot attribute watts to the camera extension.
10. Reproducibility
The public dataset preserves each paired arm's duration, frame and capture counts, complete and partial seconds, low-rate intervals, marker-age percentiles and original receipt digest. Candidate source hashes, producer and receiver revisions, native test-daemon digest and software verification are recorded separately. Raw logs and private machine paths remain in the experiment archive.
This revision changes the title, exposition and layout to the established research-report format. The measurement JSON, diagnostic findings JSON, source-identity JSON and figure are byte-identical to the first publication.
Evidence references
- E1. Paired integrated receiver measurements,
pairedComparisons. Four baseline/candidate pairs, 11 September 2026, with source receipt digests. - E2. Candidate-only product verification,
currentCandidateOnlyChecks. Web and desktop measurements, 12 September 2026. - E3. Source identity and software verification. Delivered revisions, source hashes, native test-daemon digest, test outcomes and startup-check scope.
- E4. Diagnostic findings. Consume-cycle, export, provider, observer, frame-selection, callback-clock and owned-frame prototype results, with private decision-receipt digests.
- E5. Sync 1080p60: next research plan, 11 September 2026. Original measurement definitions, research order and qualification limits.