rs/libmoq/src/video.rs (added in #2145, NVDEC hardware decode) does not compile on macOS: moq_video::decode::Consumer holds a VecDeque<moq_video::decode::Frame> whose moq_video::frame::macos::Surface wraps a CoreVideo CFRetained<CVBuffer>, which is !Send. RawVideoConsumer::consume (video.rs:106) holds that consumer across an await inside tokio::spawn, so the future is !Send and fails to compile:
error: future cannot be sent between threads safely
--> rs/libmoq/src/video.rs:106:3
= help: within `objc2_core_video::...::CVBuffer`, the trait `Send` is not implemented for `*const UnsafeCell<()>`
...
= note: required because it appears within `moq_video::decode::Consumer`
This is unrelated to the moq-net API review; it's a pre-existing gap because CI builds libmoq on Linux only, and the NVDEC decode path's macOS build was never exercised (see the "moq-nvenc vendored" / "NOT runtime-tested macOS" notes).
Options: give the decode task a spawn_local/single-thread path on macOS, wrap the CVBuffer surface in a Send newtype at the FFI boundary if the CoreVideo handle is actually thread-safe to move (it generally is; VideoToolbox already does unsafe impl Send), or gate moq_consume_video_raw off on macOS until decode is Send there. Add a macOS libmoq compile job to CI so this can't regress silently.
(Written by Claude Fable 5)
rs/libmoq/src/video.rs(added in #2145, NVDEC hardware decode) does not compile on macOS:moq_video::decode::Consumerholds aVecDeque<moq_video::decode::Frame>whosemoq_video::frame::macos::Surfacewraps a CoreVideoCFRetained<CVBuffer>, which is!Send.RawVideoConsumer::consume(video.rs:106) holds that consumer across an await insidetokio::spawn, so the future is!Sendand fails to compile:This is unrelated to the moq-net API review; it's a pre-existing gap because CI builds libmoq on Linux only, and the NVDEC decode path's macOS build was never exercised (see the "moq-nvenc vendored" / "NOT runtime-tested macOS" notes).
Options: give the decode task a
spawn_local/single-thread path on macOS, wrap the CVBuffer surface in a Send newtype at the FFI boundary if the CoreVideo handle is actually thread-safe to move (it generally is; VideoToolbox already doesunsafe impl Send), or gatemoq_consume_video_rawoff on macOS until decode is Send there. Add a macOS libmoq compile job to CI so this can't regress silently.(Written by Claude Fable 5)