diff --git a/core/include/stplugin/session.h b/core/include/stplugin/session.h index e351e98..c2b6e5f 100644 --- a/core/include/stplugin/session.h +++ b/core/include/stplugin/session.h @@ -43,6 +43,13 @@ struct SessionConfig { bool subscribe_audio = true; + /// False for an audio-only source (the soundboard, say): the wanted + /// video track is never attached (no AttachVideo command posted), and + /// its publication is explicitly disabled server-side (RemoteTrack- + /// Publication::setEnabled(false)) so the SFU stops sending it at all -- + /// not just "decoded and discarded here", genuinely not delivered. + bool subscribe_video = true; + /// How long connect() waits for the room to come up before giving up. int connect_timeout_ms = 15000; }; diff --git a/core/src/session.cpp b/core/src/session.cpp index 0b48eb3..cce09d5 100644 --- a/core/src/session.cpp +++ b/core/src/session.cpp @@ -218,6 +218,52 @@ struct LiveKitSession::Impl : public livekit::RoomDelegate { queue_cv.notify_one(); } + // Handles the wanted video track once matched, shared by onTrackSubscribed + // (a fresh subscription) and attachExistingTracks (one already up when + // this session started watching). Two responsibilities that only make + // sense together, both keyed off the SAME publication: + // + // - subscribe_video: an audio-only source (the soundboard) never wants + // this video at all. Rather than attach it and let the OBS adapter + // discard every decoded frame, disable the publication itself + // (RemoteTrackPublication::setEnabled(false)) so the SFU stops + // sending it -- real bandwidth saved, not just wasted decode. + // - Fixed video quality: LiveKit's default subscriber behaviour lets + // the SFU switch simulcast layers per its own adaptive/bandwidth + // logic, which for a source with no rendered-size hint (this is a + // native C++ subscriber, not a sized