forked from unom/punktfunk
enricobuehler
e60fee7da6
`ZeroCopyInner` held the QSV device + frames ctx as nullable raw pointers, where null meant "AMF, which feeds D3D11 frames directly" — a convention documented in a comment and enforced by three `is_null()` checks. `Option<AvBuffer>` says it in the type, so the checks and the hand-written `Drop` both go away. The reason this one was left out of the previous commit is the aliasing. `open` built a five-element tuple whose QSV arm handed the SAME two pointers out twice: once as the encoder's `dev_ref`/`frames_ref`, once as the pair moved into `Self`. For raw pointers that is free; for an owning type it is two owners and a double-unref. Ownership and borrowing are now separated — the pair is owned in `qsv_frames`/`qsv_device`, and the encoder's arguments are `as_ptr()` views taken from whichever owner applies. `open_win_encoder` takes its own refs of what it is handed, so lending transfers nothing. Net: all 13 `av_buffer_unref` calls in this file are gone (the last two hand-written Drops with them), including the encoder-open failure arm, which collapses to `?` now that every handle releases itself. Field order pinned and commented, as with the others: QSV frames, QSV device, then `enc`, then `hw` — reproducing the old `Drop`, which ran ahead of all fields and so released the derived pair before the encoder's AddRef'd copies and the D3D11 refs. `qsv_device` picked up an `#[allow(dead_code)]`: `qsv_frames` is still read by the send path, but the device is now purely an owner (the frames ctx and the encoder each hold their own ref). Same call as the decoders — deleting it would free the device early, an underscore name would hide it. Verified on BOTH: Windows .133 `cargo check -p pf-encode --features amf-qsv --all-targets` EXITCODE=0, no dead-code warnings, and confirmed non-vacuous (log shows `Removed 23 files, 36.2MiB` then a real `Checking pf-encode`). Linux .21 `cargo check --workspace --all-targets` exit 0 / zero errors, pf-encode 33 passed / 0 failed, pf-client-core 34 passed / 0 failed, and `cuda_hw_alloc_drop_cycles` still passing on real CUDA. The QSV path itself still wants Intel silicon to exercise.