72f8c05aa3
Moonlight now reconstructs lost video shards from our parity (verified live: under induced packet loss the picture recovers cleanly instead of failing with "network connection too bad"; 0% added loss in normal operation). The decisive finding: Moonlight's nanors uses a CAUCHY generator matrix (M[j][i] = inv[(m+i)^j], GF(2^8) poly 0x1d), while reed-solomon-erasure is Vandermonde — so its parity was NOT Moonlight-decodable, despite the old gf8.rs comment claiming equivalence. lumen-core: - Swap the GF(2^8) backend from reed-solomon-erasure to a vendored fec-rs (vendor/fec-rs, BSD-2), which builds the byte-identical Cauchy matrix. Pure Rust, no FFI — keeps the "one core" hot path. This makes both lumen's own protocol and the GameStream parity nanors-compatible. - Lock it with a regression test against real nanors vectors (k=4,m=2 [10,20,30,40] -> parity [136,0]) + an independent matrix-derived cross-check + an erase/recover round-trip. Existing FEC/loopback tests stay green, so lumen's own protocol is unaffected. lumen-host video.rs: - Generate m = ceil(k*pct/100) parity shards per FEC block via Gf8Coder; stamp fecInfo with the recomputed wire pct (100*m/k) so the client derives the same count; cap per-block data to 255*100/(100+pct) so k+m <= 255. - CRITICAL byte-exactness: RS runs over the whole `blocksize` shard (Moonlight decodes packetSize+16 bytes from the datagram start and PACKET_RECOVERY_FAILUREs on a bad reconstructed `flags` byte). So the NV header fields RS must reproduce (streamPacketIndex/frameIndex/flags/multiFec*) are written into data shards BEFORE encode, and only the transport fields (RTP header/seq/timestamp + fecInfo) are stamped AFTER — leaving the flags byte RS-covered. Matches Sunshine stream.cpp. Unit-tested incl. flags recovery. - fec_percentage wired from stream.rs (Sunshine default 20, LUMEN_FEC_PCT override; 0 = data-only). LUMEN_VIDEO_DROP injects loss to test recovery. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
47 lines
1.8 KiB
TOML
47 lines
1.8 KiB
TOML
[package]
|
|
name = "lumen-core"
|
|
description = "lumen shared protocol/transport/FEC core, exposed over a stable C ABI"
|
|
version.workspace = true
|
|
edition.workspace = true
|
|
rust-version.workspace = true
|
|
license.workspace = true
|
|
authors.workspace = true
|
|
repository.workspace = true
|
|
|
|
[lib]
|
|
name = "lumen_core"
|
|
# `lib` — so lumen-host / lumen-client-rs / tools link it as a normal Rust crate.
|
|
# `staticlib` — `liblumen_core.a` for the C test harness and static embedding.
|
|
# `cdylib` — `liblumen_core.{so,dylib}` for Swift/Kotlin clients via the C ABI.
|
|
crate-type = ["lib", "cdylib", "staticlib"]
|
|
|
|
[features]
|
|
default = []
|
|
# Control-plane QUIC (pairing, config, reverse audio). tokio is permitted ONLY here,
|
|
# never on the per-frame hot path. Off by default so the core stays runtime-free.
|
|
quic = ["dep:quinn", "dep:tokio"]
|
|
|
|
[dependencies]
|
|
reed-solomon-simd = "3.1" # GF(2^16) Leopard-RS, SIMD, O(n log n) — the wall-breaker (P2)
|
|
# Vendored fork of fec-rs: GF(2^8) classic RS with the *Cauchy* generator matrix
|
|
# (M[j][i] = inv[(m+i)^j]) — byte-identical to the `nanors` library Moonlight uses, so our
|
|
# parity is decodable by a stock Moonlight client. (reed-solomon-erasure is Vandermonde and is
|
|
# NOT interoperable.) See vendor/fec-rs/LICENSE (BSD-2-Clause).
|
|
fec-rs = { path = "vendor/fec-rs" }
|
|
aes-gcm = "0.10" # AES-128-GCM session crypto, matches GameStream
|
|
zerocopy = { version = "0.8", features = ["derive"] }
|
|
bytes = "1"
|
|
thiserror = "2"
|
|
tracing = { version = "0.1", default-features = false, features = ["std"] }
|
|
rand = "0.9"
|
|
zeroize = "1"
|
|
|
|
quinn = { version = "0.11", optional = true }
|
|
tokio = { version = "1", optional = true, features = ["rt-multi-thread", "net", "sync", "macros"] }
|
|
|
|
[dev-dependencies]
|
|
proptest = "1"
|
|
|
|
[build-dependencies]
|
|
cbindgen = "0.29"
|