18 Commits

Include renames

Author	SHA1	Message	Date
enricobuehlerandClaude Fable 5	f495b201e1	fix(encode): delete the write-only EncoderCaps::supports_hdr_metadata ... A caps field nothing reads is a contract nobody honors — and this one shipped write-only: its single reader anywhere in the workspace was a hardware-gated assertion inside pf-encode's own AMF smoke test. Both planes send the static HDR grade out-of-band unconditionally (the native 0xCE datagram per keyframe, the GameStream 0x010e control message), every first-party client reads exclusively that path, and none parse in-band SEI — so the host decision the field was reserved for (suppress out-of-band when the encoder embeds) can never validly exist. The field's doc contract had also rotted in two directions: it claimed set_hdr_meta no-ops when false (native AMF and QSV consume it regardless) and that only Windows direct-NVENC attaches in-band metadata (AMF and QSV do too). The in-band SEI/OBU emission itself is untouched — it stays a bonus for stock decoders, documented at the emit sites; the trait docs now describe the real routing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-26 10:48:07 +02:00
enricobuehlerandClaude Opus 5	9f1e648e4e	refactor(pf-encode): extract the slot-family RFI recovery policy (WP7.2) ... AMF (user-LTR bitfield), QSV (mfxExtRefListCtrl) and Vulkan Video (the app-owned DPB slot table) each hand-implemented the same loss-recovery decision: distrust every reference encoded at-or-after the loss start, anchor on the newest one strictly older. Three copies had already diverged once — the fecbec2d taint sweep reached AMF/QSV a commit before the Vulkan backend was carved out, and Vulkan shipped without it. The decision now lives once in enc/rfi.rs, pure and unit-tested (this path had zero coverage and is the loss-recovery path); every mechanism — how a force is applied, how distrust is persisted — stays in its backend. Behavior-preservation notes, each critic-verified against the shipped code: - Callers feed only currently-trusted references; taint (>= loss) and anchor (< loss) predicates are disjoint, so pre-sweep-view pick == post-sweep-table pick on every input. Tie-break preserved (first entry wins == the strict '>' all three used, ascending slot order). - plan_slot_recovery delegates its pick half to pick_anchor, which keeps both items live on every leg (pick_anchor's only external caller is Linux+vulkan-encode; dead_code is an item lint) and makes 'anchor chosen from the taint snapshot' structural. - The decline arms are deliberately NOT uniform and stay put: AMF/QSV clear an un-consumed pending_force; Vulkan leaves pending_loss armed (a stale arm re-resolves at frame-build into the healing IDR) — now pinned in comments on both sides. - Vulkan's frame-build site is a pick-only re-run by design (the arm carries the loss start, not the slot); pick_recovery_slot is deleted and its tests migrated 1:1 into the shared module. Test-count deltas are expected: the rfi tests now run on every Windows combo (amf.rs is featureless there) and on the Linux feature leg. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-26 00:08:03 +02:00
enricobuehler	b3f8803ea3	fix(encode/qsv): stop advertising intra-refresh the driver silently dropped ... `ir_active` was `cfg.intra_refresh && set.co2.is_some()` — i.e. "we asked for it", not "we got it". Both `Query` and `Init` can return MFX_WRN_INCOMPATIBLE_VIDEO_PARAM, a WARNING the open path deliberately accepts, while dropping the intra-refresh wave on the floor. That lie is not cosmetic. `ir_active` feeds `EncoderCaps::intra_refresh`, so the session advertises gradual refresh to the client; the client then stops asking for the IDRs it would otherwise request on packet loss, and a lost frame gets concealed instead of repaired. The stream degrades exactly when recovery matters. Now confirmed against the driver: a best-effort `GetVideoParam` with a CodingOption2 buffer chained on, read back for `IntRefType`. Deliberately a SEPARATE query rather than a buffer attached to the existing `BufferSizeInKB` call (which is what the audit finding suggested) — that value backs every bitstream allocation, and a runtime that disliked the chained buffer would take it down with the readback. A failure here costs only the verdict and resolves conservatively (trust the request), so the worst case is the previous behaviour. Verified on Intel UHD 750 (.42), which is where the Intel on-glass run originally caught this: with PUNKTFUNK_INTRA_REFRESH=1, H.264 now logs "silently dropped intra-refresh (GetVideoParam reports IntRefType=0)" and advertises it OFF, while H.265 on the same GPU stays ON — it is genuinely active there. Per-codec, so it could never have been decided statically. 8 live QSV tests pass. Gated on .173: clippy -D warnings at nvenc,amf-qsv,qsv (host + pf-encode --all-targets), amf-qsv without qsv, qsv alone, no-features, cargo test --features qsv, rustfmt — all green. qsv.rs is Windows-only so the Linux legs do not compile it. Closes WP3.2(c), the last Phase 3 item that was hardware-blocked.	2026-07-25 16:52:40 +02:00
enricobuehler	87863c12a9	fix(encode/windows): clear the Windows Phase 4 backlog — NVENC sticky state, QSV HDR + ABR ... Four items, gated on the RTX box (.173, all 7 Windows legs) and the Linux docker gate, with the QSV HDR one proven by an A/B on real Intel silicon (.42, UHD 750). WP4.1 — Windows NVENC sticky state. Both halves were the same mistake: a single field doing duty as both "what the session negotiated" and "what this session can actually do", so the first downgrade destroyed the negotiation. - `query_caps` clears `self.hdr` on a GPU without 10-bit encode, but `submit` re-derives the requested HDR state from every frame's pixel format and compared it against that cleared value. On such a GPU a P010 capturer therefore reported "HDR changed" on EVERY FRAME and tore down and rebuilt the whole encode session each time. The trigger now compares against `hdr_requested`, and the downgrade is latched in `hdr_unsupported` so it is remembered (and warned once) instead of rediscovered per init. - One subsampled-YUV frame cleared `chroma_444` permanently, so 4:4:4 never returned when the capturer went back to RGB. The negotiation now lives in `chroma_444_requested` and the effective value is recomputed at every init; the per-session downgrade still happens and is still reported honestly through `caps()`, it just is not destructive any more. WP4.3(a) — QSV HDR mastering luminance was divided by 10,000. The old comment justified it as "VPL wants whole cd/m²", which is true of the VIDEO-PROCESSING unit but not the encode path: the runtime passes the value straight into the ITU-T H.265 Annex D mastering-display SEI, whose unit is 0.0001 cd/m². Verified end to end on Intel UHD 750 by dumping the bitstream and reading SEI 137 with trace_headers, before and after: before: max_display_mastering_luminance = 1000 (0.1 nits) after: max_display_mastering_luminance = 10000000 (1000 nits) with `min` (500 = 0.05 nits) and both content-light-level fields unchanged. That asymmetry — a correct min beside a 10,000x-low max — was the original tell. WP4.3(b) — `reconfigure_bitrate` never re-read `BufferSizeInKB`, so an ABR step-up could hand the runtime an AU buffer sized for the old, lower bitrate. Fixed in both places it was broken: re-read the driver's answer via `GetVideoParam` after the `Reset` (mirroring `init_encode`), AND stop `take_bs` recycling pooled buffers without checking their capacity — the pool would otherwise keep serving short buffers even once `bs_bytes` was correct. WP7.8 — the `PUNKTFUNK_QSV_FFMPEG` half, finally landable now that a Windows gate exists (it sits behind `#[cfg(feature = "qsv")]`, so nothing in a Linux-only matrix compiles it — it was deliberately held back for exactly that reason). Trimmed like its siblings, and kept case-insensitive: the knob already accepted `TRUE`, and the bare house `matches!` would have silently dropped that spelling. Phase 4 of the audit is now complete, and WP7.8 with it. Verified: Windows gate on .173 — clippy -D warnings at nvenc,amf-qsv,qsv (host + pf-encode --all-targets), amf-qsv without qsv, qsv alone, no-features, `cargo test --features qsv` (34 passed), rustfmt. Linux docker gate L1-L4 green. On-glass: the QSV A/B above on .42. Owed: NVENC sticky-state on-glass on .173 (needs a live 10-bit-capable capture toggle).	2026-07-25 14:37:49 +02:00
enricobuehlerandClaude Opus 5	ef239691df	feat(encode): make cursor blending a queryable capability, not an assumption ... `open_video`'s `cursor_blend` argument was a request with no answer: lib.rs did `let _ = cursor_blend;` and only three backends ever read `CapturedFrame::cursor`. So a session could ask for a composited pointer, get a backend that silently discards it, and stream with no mouse cursor and nothing in the logs. Two separately-confirmed audit findings — the VAAPI dmabuf path and the libav-NVENC CUDA path — are symptoms of that one hole. `EncoderCaps::blends_cursor` makes it a fact each backend states. The four exhaustive `EncoderCaps { .. }` constructors mean adding the field is a compile error until every backend answers, which is the enforcement mechanism for future backends rather than a side effect. Vulkan Video answers from its ACTUAL configured source rather than statically: only the CSC path composites (`prep_cursor` feeds the compute shader), while the RGB-direct/EFC front-end and the native-NV12 source have no compositing stage at all and merely warn once that the pointer is being dropped. `open_video` warns when a session asked for blending and the opened backend cannot deliver it. A warning is deliberately all it does: `open_video` cannot re-plan capture, so refusing would trade a missing pointer for a dead session. The host owns `plan.cursor_blend` and is the only layer that can fall back to capturer-side compositing — this gives it something to base that on. Enforcement is NOT included. The reviewed design proposed refusing the client's host-composite flip to keep the client drawing its own pointer, but `CursorRenderMode` is client->host only: there is no host->client counterpart, so refusing yields no pointer at all — the same failure it claimed to prevent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 02:41:57 +02:00
enricobuehlerandClaude Opus 5	6be174dc9c	fix(encode/windows): the encode bit depth must follow the pixels, not the negotiation ... All three Windows backends derived it the same wrong way — `bit_depth >= 10 || matches!(format, P010 | Rgb10a2)` at ffmpeg_win.rs:154, amf.rs:1275 and qsv.rs:777 — so the NEGOTIATED depth could force a 10-bit encoder over an 8-bit capture. That combination is not hypothetical. A client advertises 10-bit, the handshake negotiates bit_depth=10, and then enabling advanced colour on the IDD virtual display fails — at which point the capturer says exactly that and delivers 8-bit NV12 anyway ("10-bit HDR was negotiated but enabling advanced color on the virtual display FAILED — encoding 8-bit SDR"). Every vendor then lost the session, each in its own way: - native AMF and native QSV derived `expected = P010`, saw Nv12, and bail!'d at open; - the libavcodec path accepted the open, built a P010 encoder, and then failed EVERY submit forever, because its per-frame check recomputes the depth from the frame and never matches. reset() could not help: the rebuild re-derived the same wrong depth from the same stored bit_depth. The host burned MAX_ENCODER_RESETS and ended the session. The last one is the worst of the three because it IS the fallback: native QSV correctly refuses this input at open, and lib.rs then falls back to the ffmpeg path "for robustness" — which accepted it and died per frame instead. Since the duplication was the bug, the fix is one shared `ten_bit_input()` in codec.rs that all three call, and it follows the delivered pixels. That also keeps the stream HONEST rather than merely alive: the depth selects the colour signalling (BT.2020 PQ vs BT.709) and the staging surface format, so an 8-bit capture now produces an 8-bit stream that says it is SDR — which is what the capturer already reported it was sending. It warns when the negotiated depth is discarded. The negotiated depth stays an upper bound. The session LABEL may still claim HDR; that mismatch lives in the negotiation, not in the encoder, and is not addressed here. `is_10bit_format` keeps its (now format-only) definition and is used by submit_d3d11's per-frame check, so the predicate the encoder was built from and the one it re-checks per frame cannot drift. That check can now only fire on a genuine mid-stream depth change. Verified `--all-targets -D warnings` on Windows (no features / pyrowave / qsv / nvenc,qsv; 31 tests) and Linux (default; shipped nvenc+vulkan-encode+pyrowave). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-25 00:32:37 +02:00
enricobuehlerandClaude Fable 5	428bd2519c	test(qsv): converter→ring-profile-P010→encoder live e2e (the RTV-written seam) ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 13:30:35 +02:00
enricobuehlerandClaude Fable 5	87d7eceabf	fix(encode/qsv): write the colour VUI unconditionally + Intel-lane colour diagnostics ... The native QSV encoder only attached mfxExtVideoSignalInfo on HDR sessions — an SDR stream carried no colour description at all (NVENC writes 709-limited unconditionally; qsv.rs now mirrors it). Diagnostics for the field-reported blue/magenta Intel-host colours: - hdr-p010-selftest takes an optional WxH + GPU vendor (intel|nvidia|amd) and prints which adapter it tested — 64x64 on the default GPU proved nothing on dual-GPU boxes, and the field heights (1080/1400) are not 16-aligned. - pf-capture: ignored live test running the converter at 1920x1080 pinned to the Intel adapter. - pf-encode: qsv_live_p010_1080_colorbars_dump — known P010 bars through the UNALIGNED-height ingest copy (1080 src -> align16 1088 pool, the seam no 640x480 test exercises) to Main10 HEVC, dumped for off-box decode checks. - dxgi.rs: drop the stale 'falls back to the R10 path' claim (no such path). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-21 13:30:35 +02:00
enricobuehlerandClaude Opus 4.8	b22d0da75b	fix(encode): port the RFI taint sweep to Vulkan Video, close the QSV sweep hole, bounds-check encode feedback ... Three defects from the pf-encode sweep, each adjudicated against source. - Vulkan Video never received fecbec2d's taint sweep (it was carved out one commit later). `pick_recovery_slot` accepts any resident slot whose wire is below the CURRENT loss start, but "resident and older than this loss" is not "the client decoded it": after an earlier loss [a,b] recovered at wire r, everything in [a, r-1] is undecodable at the client — the lost frames plus every frame that predicted through the gap — and those wires stay eligible until the 8-slot ring rolls them out. A later loss could therefore anchor on one and ship it tagged `recovery_anchor`, which is the client's definitive re-anchor signal (punktfunk-core/src/reanchor.rs): the host lifts the client's post-loss freeze onto a picture built from a reference it never had. Swept before anchor selection, matching AMF/QSV. `slot_wire` is blanked and `slot_poc` deliberately is NOT: `slot_poc` feeds `build_h265_rps_s0`, which must keep naming every physically-resident DPB picture or a conforming decoder evicts them and the anchor then references a picture the client already dropped. - QSV's sweep was incomplete, and in its MODAL case. `ltr_slots` mirrors the hardware DPB, but nulling an entry issues no VPL call — the frame stays marked long-term until that LongTermIdx is re-marked or an IDR flushes it (amf.rs states this verbatim). The rejection loop iterates the post-sweep mirror and only rejects `Some` slots, so it silently skipped the single entry the sweep exists to distrust, leaving the recovery frame free to predict from it. With NUM_LTR_SLOTS=2 the "exactly one slot swept" case is the common one, and the two existing tests cover only the both-survive and both-swept cases. Taint is now recorded in `ltr_tainted` with the FrameOrder left in place, so anchor selection and the queued-force guard skip it while the rejection list still names it. - `read_slot` built a slice from the driver-reported (offset, bytes-written) encode feedback with no validation against `bs_size`, so a driver reporting a range outside the bitstream buffer produced an out-of-bounds read shipped straight onto the wire. Checked in u64 (so the add cannot wrap) before `map_memory`, so the error path has no unmap to unwind. Adds `taint_sweep_excludes_slots_from_an_earlier_loss` covering the two-loss case the existing single-loss test does not reach. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 21:18:17 +02:00
enricobuehlerandClaude Opus 4.8	f9668b16a1	fix(encode): NVENC partial-init session leak + three backend-parity gaps ... All four found in the pf-encode quality sweep and verified against source. - NVENC partial-init leak (BOTH platforms, high): `init_session` publishes `self.encoder` — and on Windows charges LIVE_SESSION_UNITS — *before* its remaining fallible steps (bitstream buffers; on Linux also the input-surface alloc and `register_resource`). A failure there left a live session with `inited == false`, and every guard on the re-init path keys off `inited`, so the next submit skipped teardown and overwrote `self.encoder`: the session leaked permanently toward the driver's per-process cap, and its budget units never returned, progressively starving parallel-display admission. `teardown` already keys off `encoder.is_null()` rather than `inited`, so it cleans up exactly this half-built state — it just was never called. Now invoked on the `init_session` error path on both platforms. - `can_encode_10bit` asked the wrong backend (medium): it resolved via `linux_auto_is_vaapi`, which ignores `encoder_pref`, while `can_encode_444` and `open_video` honour it. On a host that forces a backend (e.g. `encoder_pref = "vaapi"` on an NVIDIA box) the probe answered for NVENC while the session opened VAAPI, so the negotiated bit depth — and the HDR/SDR colour label derived from it — described a backend that never ran. Now uses the same `linux_zero_copy_is_vaapi` mirror, and `linux_auto_is_vaapi` carries a warning that it resolves the `auto` case only and is not a dispatch mirror. - Linux software arm ignored SW_BITRATE_CEIL (low): the Windows arm clamped openh264 to 100 Mbps, the Linux arm passed the full negotiated rate. The constant is now module-scope so both arms share one value. - QSV/AMF env-parity (low): `PUNKTFUNK_IR_PERIOD_FRAMES` was a no-op on QSV despite the comment claiming parity with AMF, and `PUNKTFUNK_NO_QSV_LTR` / `PUNKTFUNK_INTRA_REFRESH` had dropped AMF's `trim()` and `yes`/`on` spellings, so a value with stray whitespace silently did nothing on Intel while the same value worked on AMD. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 20:47:55 +02:00
enricobuehlerandClaude Opus 4.8	04e4394ee0	fix(encode): close the two teardown memory-safety holes in the reset paths ... Both surfaced in a post-refactor quality sweep of pf-encode and were then verified against the source (and, for pyrowave, against the C side). - PyroWave (BOTH platforms): `reset()` destroyed the encoder and, when the rebuild failed, returned `false` leaving `pw_enc` pointing at the freed object — `Drop` then destroyed it a second time. `pyrowave_encoder_destroy` is a plain `delete` (pyrowave_c.cpp:1184, which also reads `encoder->device` afterwards) with no null check, so this is a real double free. The failure branch is not vacuous: the rebuild fails when the device is lost/OOM, which is exactly the state that makes the stall watchdog call `reset()` in the first place, so the host corrupts its heap on the path that runs when things are already going wrong. Now nulls `pw_enc` before the fallible create, publishes only on success, and null-guards both `Drop` and `encode_frame` (the Windows `Drop` already guarded `sync` this way). - QSV: `reset()` dropped `pending` — each entry owning the `Box<BsBuf>` the runtime writes into asynchronously — BEFORE `MFXVideoENCODE_Close` aborted those operations, so the VPL runtime could write into freed heap. The preceding drain is best-effort and bails on the first `Err`, i.e. precisely the wedged-encoder case that triggers the reset. Fixed by ordering: Close, then clear. The full-teardown path was already correct (`Inner` declares `session` before `pending`, and fields drop in declaration order). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 20:07:57 +02:00
enricobuehlerandClaude Opus 4.8	fecbec2daf	fix(encode): make LTR-RFI loss recovery sound under sustained loss ... Field report (lid-closed Intel laptop, ~6-19% sustained loss): the stream never healed — permanent macroblock soup. Three stacked bugs: - QSV answered RFI with PreferredRefList only, a reorder HINT per the VPL spec — the recovery frame could keep predicting from tainted short-term refs. Now rejects every other DPB candidate (RejectedRefList) and caps L0 at one active entry (AVC/HEVC), matching AMF's hard ForceLTRReferenceBitfield / NVENC invalidation semantics. - Neither QSV nor AMF taint-swept LTR slots across losses: a slot marked inside the client's corrupt window became the "known-good" anchor of the NEXT loss, propagating corruption through every recovery. Both now drop slots at-or-after the loss start before picking an anchor, and guard a queued force whose slot the sweep emptied (no false recovery_anchor tag). - The native plane re-anchored the FULL IDR cooldown on every successful RFI, so under sustained loss the client's escalating keyframe requests were coalesced away indefinitely (field log: dozens swallowed, one IDR per ~8 s). RFI now anchors a 300 ms echo window with a 2-swallow budget per loss episode; a client still asking past that gets its IDR. Live-validated on Arc (qsv feature): 6/6 including the new qsv_live_ltr_rfi_taint_sweep_declines (a loss covering every live mark declines the RFI and falls back to IDR recovery). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-19 17:53:48 +02:00
enricobuehlerandClaude Opus 4.8	ebd9967547	feat(pyrowave): Windows host encoder — separate-plane zero-copy D3D11→Vulkan ... Wire PyroWave into the Windows host (design/pyrowave-windows-host-zerocopy.md). Before this a macOS client + Windows host that both selected PyroWave silently ran HEVC: the host never advertised CODEC_PYROWAVE and open_video_backend bailed. Approach (zero-copy, no GPU→CPU→GPU): pyrowave owns its own Vulkan device (create_device_by_compat, by render-GPU vendor/device-id — NOT LUID, invalid in Session 0). The capturer runs a BGRA→YUV BT.709-limited CSC (matching rgb2yuv.comp) into TWO SEPARATE shareable plane textures — full-res R8 Y + half-res R8G8 CbCr — which the encoder imports into pyrowave's device. Separate single/two-component textures import reliably on NVIDIA at any size; a single planar NV12 import does NOT (the vendored interop test: "only very specific resource sizes" — confirmed on-glass: 1024² fine, 720p/1080p/1440p garbage). A shared D3D11 fence, signalled after the CSC, is imported as a Vulkan timeline semaphore so the wavelet read is ordered after it. - pf-encode: enc/windows/pyrowave.rs (Encoder impl, two-plane import + Linux-style plane views); host_wire_caps advertises CODEC_PYROWAVE on Windows when the backend isn't Software; open_video_backend routes a negotiated PyroWave session first; pyrowave-sys on the Windows target; interop confirmed at open → clean HEVC fallback. - pf-encode: shared, unit-tested enc/pyrowave_wire.rs (single source of truth for the client-facing AU framing); Linux encoder uses it too. - pf-capture: dxgi.rs BgraToYuvPlanes CSC; idd_push.rs pyrowave mode — forces the virtual display SDR (the VideoProcessor can't ingest the FP16 HDR ring), a two-plane shareable out-ring, a shared fence passed every frame (so a rebuilt encoder re-imports it). Threaded via OutputFormat::pyrowave. - pf-frame: D3d11Frame::pyro carries the CbCr plane + fence; OutputFormat::pyrowave. Verified on .173 (RTX 4090): full-host build + clippy -D warnings (nvenc,amf-qsv) + fmt --all --check; pyrowave_wire unit tests; pyrowave_win_smoke GPU test round-trips distinct Y/Cb/Cr (100/180/60) exactly at 1024²/720p/1080p/1440p; Stage-0 interop validated in the real Session-0 service context on-glass. Deployed to the box. Owed: final on-glass picture/latency confirmation. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-18 11:39:44 +02:00
enricobuehlerandClaude Fable 5	df70bf00f9	test(qsv): live on-glass matrix — HEVC, Main10+HDR, AV1 10-bit, LTR-RFI, no-IDR retarget ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 19:55:43 +02:00
enricobuehlerandClaude Fable 5	9e6ab9b94d	fix(qsv): enable D3D11 multithread protection before SetHandle (on-glass -16 on Arc) ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 19:52:44 +02:00
enricobuehlerandClaude Fable 5	0a617e7779	fix(qsv): clippy — per-block SAFETY comments, div_ceil, clamp, vec_box allow ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 19:44:16 +02:00
enricobuehlerandClaude Fable 5	75d1322b8a	fix(qsv): end the inner borrow before the retarget param rebuild ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 19:39:08 +02:00
enricobuehlerandClaude Fable 5	55e7f3fca9	feat(encode): native QSV backend — libvpl-sys + qsv.rs (Phases 0-3 of design/native-qsv-encoder.md) ... Vendored MIT VPL dispatcher (static, trimmed tree, pin 674d015b/v2.17.0) built via cmake+bindgen behind new feature 'qsv' (pf-encode + punktfunk-host forward). qsv.rs: dispatcher session on the capture adapter (LUID-matched), SetHandle D3D11, AsyncDepth=1/GopRefDist=1/VDEnc/CBR + HRD-off low-latency config, GetSurfaceForEncode + GPU CopySubresourceRegion input (zero-copy, no readback path), bounded sync-point poll, in-place reset with teardown escalation, no-IDR bitrate retarget (Reset + StartNewSequence=OFF), 10-bit P010 HEVC-Main10/AV1, HDR mastering/CLL SEI-OBU at IDR + BT.2020/PQ VSI, LTR-RFI via mfxExtRefListCtrl (AMF slot policy port, Query-gated per codec, wire-index FrameOrder pinning). Dispatch: native-first with ffmpeg fallback + PUNKTFUNK_QSV_FFMPEG hatch; probes (can_encode_10bit / windows_codec_support / windows_backend_is_probed) now answer natively for QSV. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-17 19:34:18 +02:00