Proto commits in livekit/rust-sdks

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-08-10

Merge remote-tracking branch 'origin/main' into ladvoc/livekit-capture

Clock source Also extract render infra shared with pattern source.

Logo pattern

other_sdks (#1317) Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

The documentation is generated from this commit.

2026-08-08

Pattern source Supersedes shader and demo source

2026-08-07

Make demo source shader backed

other_sdks for specifying sdk info beyond client-sdk-*

The documentation is generated from this commit.

2026-08-05

other_sdks

The documentation is generated from this commit.

2026-08-03

Device facade

Uniform source construction - No default impls for config - Uniform constructor naming

2026-07-30

Merge remote-tracking branch 'origin/main' into ladvoc/livekit-capture

2026-07-29

Expose capture over FFI

2026-07-28

Data streams v2 (#1192) ### Overview This change introduces data streams v2, a set of major updates to data streams to add three things: 1. Single packet data streams for short (< 15kb), finite length payloads 2. DEFLATE compression, when both the sender and all receivers support compression/decompression 3. A maximum 15kb size for data stream attributes to close this as a DOS vector For information about important decisions made in data streams v2, [see the spec](https://github.com/livekit/client-sdk-js/blob/data-streams-v2/DATA_STREAMS_SPEC.md). In particular, parts 1-5 provide a good high level overview of data streams v1 + v2, what these protocol improvements are aiming to acheive, and why certain choices were made when designing the protocol. Also maybe of interest is [the corresponding web sdk pull request](https://github.com/livekit/client-sdk-js/pull/1985). These updates are fully backwards compatible - the sdk will fall back to data streams v1 whenever an old participant is in the room. There is also a significant amount of new test coverage to data streams (both v1 and v2). There were some small bugs I found along the way which I fixed as well. --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

Started manual work to add protos

2026-07-27

Data track schema metadata (#1159) Adds support for associating schema metadata with a published data track and storing/retrieving schema definitions. Schema storage is built on-top of data blobs, a general purpose mechanism for storing large (in the order of KBs), arbitrary data blobs in a room: - Protocol: https://github.com/livekit/protocol/pull/1595 - SFU implementation: https://github.com/livekit/livekit/tree/raja_async_attributes Protocol additions for schema metadata: - https://github.com/livekit/protocol/pull/1553 Closes BOT-368 --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-07-23

feat: add temporary flag to disable advertising data streams v2 support The node and python sdks today have their own data streams implementations. If this branch were merged today, then it would mean that the new client_protocol=2 would be advertised, and these pre-existing implementations would receive data stream v2 messages, not v1 (ie, single packet data streams, compression, etc). So for now, add a flag which can be set in livekit-ffi to disable advertising the new client protocol so this can be merged. Once merged, node and python can be updated to pass this flag. Then, once data streams v2 is done on both node + python and both are updated, this flag can be removed by reverting this commit.

feat: add support for data stream trailer attributes via livekit-ffi

feat: add RoomDataStreamOptions to livekit-ffi This allows configuring the data stream max payload size value when constructing a room.

feat: add ability to override data stream sender identity This is required for the python / node sdks to adopt the standardized data stream implementation, since it uses this feature for (I think) avatars

feat: allow data stream compress option to be toggled via livekit-ffi

2026-07-17

Expose custom encoding identifiers over FFI

Expose data track fields over FFI

Expose over FFI

2026-07-10

Fix existing issues

2026-07-09

feat: allow data stream compress option to be toggled via livekit-ffi

2026-07-08

feat: allow data stream compress option to be toggled via livekit-ffi

2026-07-06

feat: allow data stream compress option to be toggled via livekit-ffi

2026-07-01

feat: allow data stream compress option to be toggled via livekit-ffi

Merge remote-tracking branch 'origin/main' into ladvoc/schema-metadata

2026-06-30

fix: correct DegradationPreference docstrings to match WebRTC semantics The docstrings for MaintainFramerate and MaintainResolution were swapped. Per the W3C WebRTC spec: - MaintainFramerate: Degrade resolution to maintain framerate (prioritize smooth motion) - MaintainResolution: Degrade framerate to maintain resolution (prioritize image clarity) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

chore: remove deprecated DEGRADATION_PREFERENCE_DISABLED from proto (#1201) ## Summary - Remove the deprecated `DEGRADATION_PREFERENCE_DISABLED` (value 3) from the `DegradationPreference` enum in `room.proto` - Update the conversion code in `room.rs` to remove the `Disabled` match arm ## Rationale The `Disabled` value was deprecated in favor of `MAINTAIN_FRAMERATE_AND_RESOLUTION` which provides the same behavior. Since `DegradationPreference` is a new feature being added to the FFI protocol, there's no backwards compatibility concern - no existing clients are using the `Disabled` value. This aligns the proto enum with the Rust `libwebrtc::rtp_parameters::DegradationPreference` enum which only has: - `Balanced` - `MaintainFramerate` - `MaintainResolution` - `MaintainFramerateAndResolution` ## Test plan - [x] `cargo check -p livekit-ffi` passes 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com> Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

chore: remove deprecated DEGRADATION_PREFERENCE_DISABLED from proto Remove the deprecated DEGRADATION_PREFERENCE_DISABLED (value 3) from the DegradationPreference enum in room.proto. This value was deprecated in favor of MAINTAIN_FRAMERATE_AND_RESOLUTION which provides the same behavior. Since DegradationPreference is a new feature being added to the FFI protocol, there's no backwards compatibility concern - no existing clients are using the Disabled value. This aligns the proto enum with the Rust libwebrtc::rtp_parameters::DegradationPreference enum which only has: Balanced, MaintainFramerate, MaintainResolution, and MaintainFramerateAndResolution. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

feat: add MaintainFramerateAndResolution to DegradationPreference enum (#1200) ## Summary Aligns the DegradationPreference enum with WebRTC M144 changes: - Add `MAINTAIN_FRAMERATE_AND_RESOLUTION` as the new recommended value - Deprecate `DISABLED` (maps to `MAINTAIN_FRAMERATE_AND_RESOLUTION` for backwards compatibility) Reference: https://github.com/webrtc-sdk/webrtc/blob/m144_release/api/rtp_parameters.h#L125 ## Changes - **room.proto**: Add `DEGRADATION_PREFERENCE_MAINTAIN_FRAMERATE_AND_RESOLUTION` enum value - **webrtc-sys**: Rename `Disabled` to `MaintainFramerateAndResolution` in the repr(i32) enum - **libwebrtc**: Add `MaintainFramerateAndResolution` variant, deprecate `Disabled` as a const alias - **livekit-ffi**: Update conversion to handle both old `DISABLED` and new `MAINTAIN_FRAMERATE_AND_RESOLUTION` proto values ## Backwards Compatibility - Existing code using `DISABLED` will continue to work (mapped to `MaintainFramerateAndResolution`) - FFI clients can use either value, both map to the same internal behavior ## Test plan - [x] `cargo build -p livekit-ffi` passes - [x] `cargo build -p livekit` passes - [x] `cargo test -p livekit --lib -- degradation` passes 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com> Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

Fix initial video quality blurriness for all codecs (#1197) Summary Fixes initial video quality blurriness by: 1. Applying x-google-start-bitrate SDP hint for all video codecs (VP8, VP9, AV1, H264, H265) 2. Defaulting DegradationPreference to MaintainResolution for all video tracks Problem Users report video starting blurry for 5-15 seconds before reaching full quality (https://www.loom.com/share/9a34ae565f6949b891a155a436b3d573). This happens because: 1. Slow bandwidth ramp-up: x-google-start-bitrate was only set for VP9/AV1, so VP8/H264 streams start at WebRTC's conservative default (~300 kbps) and ramp up slowly. 2. Resolution degradation: Default DegradationPreference was Balanced, causing the encoder to reduce resolution during the ramp-up period. Changes livekit/src/rtc_engine/peer_transport.rs - Extended x-google-start-bitrate SDP munging to all video codecs (VP8, VP9, AV1, H264, H265) - Updated tests libwebrtc/src/rtp_parameters.rs - Added DegradationPreference enum - Added set_degradation_preference() and degradation_preference() methods to RtpParameters livekit/src/room/options.rs - Added degradation_preference field to TrackPublishOptions - Added get_default_degradation_preference() that defaults to MaintainResolution - Re-exported DegradationPreference for users livekit/src/room/participant/local_participant.rs - Apply degradation preference to video tracks after creating the transceiver Behavior │ Setting │ Before │ After │ │ x-google-start-bitrate │ VP9/AV1 only │ All video codecs │ │ DegradationPreference │ Not set (WebRTC default) │ MaintainResolution │ Users can override degradation_preference in TrackPublishOptions if they prefer Balanced or MaintainFramerate. Testing - Added unit tests for DegradationPreference defaults - Updated x-google-start-bitrate tests for all codecs - Manual testing with local_video example --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-06-29

added ffi changes

2026-06-24

add user_data trailer type (#1180)

Expose custom encoding identifiers over FFI

harden reconnect behaviour (#1148) ### Before you submit your PR Make sure the following is true before submitting your PR: - [ ] I have read the [contributing guidelines](https://github.com/livekit/rust-sdks/blob/main/CONTRIBUTING.md) and validated that this PR will be accepted. - [ ] I have read and followed the principles regarding breaking changes, testing, and code quality. ### PR description Describe the changes in this PR. Explain what the PR is meant to solve and how to reproduce the issue in the first place. ### Breaking changes If this PR introduces breaking changes, list them here and document the rationale for introducing such a change. ### MSRV If the PR modifies the crate's MSRV (Minimum Supported Rust Version), document it here. ### Testing Ideally, unit test the code you add, but ensure you're not repeating existing test cases. Use as many already written scaffolding, utilities as possible; write your own, when needed. If external services, APIs, tokens are required (e.g., running an LK server instance), provide the necessary information. Make sure your tests perform useful, context-aware assertions and do not simply emulate "happy paths". ### Async We want the project to be runtime-agnostic, so please reuse what's already in [livekit-runtime](https://github.com/livekit/rust-sdks/blob/main/livekit-runtime/) and feel free to add anything missing. It's ok to use Tokio directly, when writing unit tests, if necessary. When testing, do not use artificial delays for the state to "catch up"; instead, respect the event flow and subscribe properly using channels or other mechanisms. --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-06-23

Merge remote-tracking branch 'origin/main' into ladvoc/schema-metadata

2026-06-20

add user_data trailer type

rename Packet Trailer to Frame Metadata (#1179) - rename the PacketTrailerFeatures enum to FrameMetadataFeatures for clarity

2026-06-19

add user_data trailer type

rename all Packet Trailer to Frame Metadata

Add DisconnectSignalOnResume scenario to FFI variants

2026-06-17

Expose data track fields over FFI

2026-06-16

reliable data track experiment

2026-06-11

webrtc-sys: cache and auto-prepend H.264/H.265 parameter sets Encoded track source now scans incoming frames for SPS/PPS (H.264) or VPS/SPS/PPS (H.265), caches the latest seen set, and prepends them to any keyframe that arrives without inline params. This makes hardware encoders and camera feeds that only emit parameter sets on stream start usable as-is, without requiring producers to replicate them on every IDR. Producers still get a clear warning if the very first keyframe has no parameter sets and the cache is empty. The caller-supplied has_sps_pps flag becomes a hint only; the scanner is the source of truth so double-prepending is impossible. Also fix a stale `src->get()` reference left over from the SetRates refactor in PassthroughVideoEncoder::Encode. examples: H.264, H.265, VP8, AV1. VP9 not supported yet

livekit: publish encoded video tracks Dispatch RtcVideoSource::Encoded through the new PCF path in LocalVideoTrack, and normalize TrackPublishOptions for encoded sources in LocalParticipant::publish_track — simulcast is forced off and the codec is pinned to the source's codec, with warnings on override.

2026-06-10

Expose over FFI

platform_audio: add device-selection capability + explicit mobile no-op Device selection is only meaningful on desktop; on iOS/Android the OS owns audio routing (AVAudioSession / AudioManager). Previously the "no-op on mobile" was accidental — a fallback in the native layer selected index 0 whenever a GUID didn't match — which also silently swallowed a real desktop error (a saved device that no longer exists). - proto: add PlatformAudioInfo.device_selection_supported. - PlatformAudio::supports_device_selection() — false on iOS/Android, true on desktop. Lets clients hide device-picker UI where selection has no effect. - set_/switch_ recording/playout device short-circuit to Ok(()) on mobile before touching native, so the no-op is explicit rather than dependent on native device-reporting quirks (iOS RecordingDeviceName -1; Android empty GUID). - ffi server populates the new field from the accessor. - webrtc-sys: drop the index-0 fallback in set_*_device_by_guid so an unknown GUID returns false -> DeviceNotFound on desktop; mobile never reaches it. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

2026-06-03

adding support to setting preferred encoder on video track publication (#1126) - Add field to `TrackPublishOptions` that allows the user to set a preferred video encoder when there are multiple options. - Options can be `auto`, `software`, `hardware`, `nvenc`, `vaapi`, `videotoolbox`. --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

Add max round trip latency (#1127) Adds a new `max_round_trip_latency` field to `PerformRpcData`, adding similar behavior as was added to the corresponding [swift](https://github.com/livekit/client-sdk-swift/pull/1023) and [android](https://github.com/livekit/client-sdk-android/pull/953) pull requests. Note that this is a **breaking api change**. Per @ladvoc's guidance, this was deemed to be ok because there isn't really a great way to add this new field to the `PerformRpcData` struct in a backwards compatible way. Given this is a breaking change, I opted to break it in a way where if we have to add _more_ fields in here in the future, it could be done in a non breaking way by making `PerformRpcData` use a builder pattern. That results in something that looks like: ```rust let output = caller_room.local_participant().perform_rpc( PerformRpcData::new("identity", "method") // <-- New builder .with_payload("payload") .with_response_timeout(Duration::from_secs(5)) ).await?; ``` --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: lukasIO <mail@lukasseiler.de>

2026-05-30

Merge branch 'main' into dc/feature/track_encoder_option

2026-05-29

bump protocol to v1.46.4 and expose client_protocol via FFI (#1121) ### PR description - bumps the protocol to v1.46.4 and adds the `livekit_analytics.proto` messages to the generated stubs. - exposes participant `client_protocol` via FFI - Adds a `remove_participant_with_options` method that allows to pass new remove options to the API without a previous `remove_participant` call breaking. ### Breaking changes for the `livekit-api` crate I've added a `derive(default)` and an additional (option) field to the EgressListOptions struct. I don't see a good way around this though. Open for suggestions. --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-05-28

adding support to setting preferred encoder on video track publication

2026-05-26

rename to video_encoder

add API to select video encoder

2026-05-21

fix Android PlatformAudio (#1104) ### Before you submit your PR Make sure the following is true before submitting your PR: - [x] I have read the [contributing guidelines](https://github.com/livekit/rust-sdks/blob/main/CONTRIBUTING.md) and validated that this PR will be accepted. - [x] I have read and followed the principles regarding breaking changes, testing, and code quality. ### PR description ⏺ Android PlatformAudio: Problems & Solutions Problem 1: ADM Creation Failed Symptom: CreateAudioDeviceModule returned nullptr Failed to initialize PlatformAudio Root Cause: WebRTC's CreateAndroidAudioDeviceModule internally calls GetAppContext() to get the Android application context. But GetAppContext() returns null unless ContextUtils.initialize(context) was called first. CreateAndroidAudioDeviceModule() └── GetAppContext() └── Returns null ❌ (ContextUtils not initialized) Solution: Pass the Android Context from Unity to Rust, then call ContextUtils.initialize(context) before any WebRTC audio initialization. Unity Rust/C++ ───── ──────── GetApplicationContext() ──────► livekit_ffi_initialize_android_context() │ ├── do_android_init(vm) // JVM init └── ContextUtils.initialize(context) // Now GetAppContext() works! Files changed: - livekit-ffi/src/cabi.rs - Added livekit_ffi_initialize_android_context() - webrtc-sys/src/android.cpp - Added init_android_context() - client-sdk-unity/.../FFIClient.cs - Calls the init with context - client-sdk-unity/.../NativeMethods.cs - P/Invoke declaration --- Problem 2: Wrong ADM Factory Function Symptom: AdmProxy: All Android audio layers failed! Root Cause: The code was using the generic CreateAudioDeviceModule() which doesn't work properly on Android. Android requires CreateAndroidAudioDeviceModule() from the Android-specific header. Solution: Changed adm_proxy.cpp to use the correct function: // Before (wrong): #include "modules/audio_device/include/audio_device.h" platform_adm_ = webrtc::AudioDeviceModule::Create(...); // After (correct): #include "sdk/android/native_api/audio_device_module/audio_device_android.h" platform_adm_ = webrtc::CreateAndroidAudioDeviceModule(...); File changed: - webrtc-sys/src/adm_proxy.cpp --- Problem 3: Empty GUID Validation Failed Symptom: Recording device at index 0 has no GUID Root Cause: Unity SDK threw an exception when device GUID was empty. But on Android, devices don't have GUIDs - WebRTC returns empty strings. Solution: Allow empty GUIDs and pass them to native code, which falls back to index 0: // Before: if (string.IsNullOrEmpty(deviceId)) throw new InvalidOperationException("has no GUID"); // After: SetRecordingDevice(deviceId ?? ""); // Empty string triggers fallback File changed: - client-sdk-unity/.../PlatformAudio.cs --- Problem 4: Device Not Found with Empty GUID Symptom: Failed to set recording device: Device not found Root Cause: Native code searched for a device matching the empty GUID string, found nothing. Solution: Added fallback in C++ - if GUID is empty and devices exist, use index 0: bool AudioDeviceController::set_recording_device_by_guid(rust::String guid) const { int16_t count = adm_proxy_->RecordingDevices(); // Android fallback: empty GUID → use index 0 if (guid.empty() && count > 0) { return adm_proxy_->SetRecordingDevice(0) == 0; } // ... normal GUID lookup for desktop } File changed: - webrtc-sys/src/audio_device_controller.cpp ### Breaking changes N/A ### MSRV N/A ### Testing Tested with Unity ### Async N/A --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-05-20

Improved data tracks depacketizer to support mutliple in flight packets (#1101) Equivalent to the implementation in: https://github.com/livekit/client-sdk-js/pull/1923 Closes BOT-342 --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-05-19

WIP wiring up for flushing Rust logs

FFI room events: only sent after receiving ReadyForRoomEventRequest after initial connection (#1068) Resolves BOT-344 --------- Co-authored-by: Stephen DeRosa <stephen.derosa@livekit.io> Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-05-18

Return EOS event from data track stream read request (#1093) Resolves BOT-347 --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

change the sample rate and num of channel optional in the proto (#1097) ### Before you submit your PR Make sure the following is true before submitting your PR: - [x] I have read the [contributing guidelines](https://github.com/livekit/rust-sdks/blob/main/CONTRIBUTING.md) and validated that this PR will be accepted. - [x] I have read and followed the principles regarding breaking changes, testing, and code quality. ### PR description change the sample rate and num of channel optional in the proto Those fileds are not needed by the PlatformAudio source ### Breaking changes No ### MSRV N/A ### Testing CI ### Async N/A --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-05-14

get webrtc adm into rust (#1037) Summary This PR implements Platform Audio support for the LiveKit Rust SDK, enabling WebRTC's built-in audio device handling with microphone capture and speaker playout. The implementation introduces a handle-based PlatformAudio API that coexists with the existing NativeAudioSource for manual audio pushing. Key Features - Two Audio Source Types: - RtcAudioSource::Native (default): Manual audio push via NativeAudioSource for TTS, file streaming, agents - RtcAudioSource::Device: WebRTC handles mic capture & speaker playout with echo cancellation (AEC) - Handle-based API: Create PlatformAudio instances that enable ADM recording; drop to release - Reference Counting: Multiple PlatformAudio instances share the same underlying ADM - Device Enumeration & Selection: List and select recording/playout devices - Hot-swap Device Switching: switch_recording_device() / switch_playout_device() for changing devices during active sessions - Audio Processing Configuration: AEC, AGC, NS with hardware/software preference - WebRTC Patching: external_audio_source.patch prevents audio mixing conflicts between device and manual sources Design Document See docs/ADM_PROXY_DESIGN.md for full architecture details including: - Recording gate pattern - WebRTC patching explanation - FFI API documentation API Overview use livekit::prelude::*; // Create PlatformAudio instance (enables ADM recording) let audio = PlatformAudio::new()?; // Enumerate and select devices for i in 0..audio.recording_devices() as u16 { println!("Mic [{}]: {}", i, audio.recording_device_name(i)); } audio.set_recording_device(0)?; // Connect and publish let (room, _) = Room::connect(&url, &token, RoomOptions::default()).await?; let track = LocalAudioTrack::create_audio_track("mic", audio.rtc_source()); room.local_participant().publish_track(LocalTrack::Audio(track), opts).await?; // Cleanup - just drop the handle room.close().await?; drop(audio); // ADM recording disabled when all handles released Testing Run Standalone Tests (no LiveKit server required) # Set custom WebRTC build path export LK_CUSTOM_WEBRTC="/path/to/webrtc-sys/libwebrtc/mac-arm64-debug" # Run standalone PlatformAudio tests cargo test -p livekit --test platform_audio_test test_platform_audio_standalone -- --nocapture # Run FFI request handler tests cargo test -p livekit-ffi requests::tests -- --nocapture Run E2E Integration Tests (requires LiveKit server) # Start a local LiveKit server first, then: LIVEKIT_URL=ws://localhost:7880 \ LIVEKIT_API_KEY=devkey \ LIVEKIT_API_SECRET=secret \ cargo test -p livekit --test platform_audio_test --features __lk-e2e-test -- --nocapture Test Coverage Category │ Tests │ Description │ Standalone - Creation │ 1 │ PlatformAudio creation, device enumeration Standalone - Ref Counting │ 1 │ Clone, sharing, drop behavior Standalone - Device Selection │ 1 │ Set devices, invalid index handling Standalone - Processing │ 1 │ AEC/AGC/NS configuration, hardware availability Standalone - Reset │ 1 │ reset_platform_audio() function Standalone - Lifecycle │ 1 │ Full create→configure→use→release cycle FFI - Handlers │ 6 │ NewPlatformAudio, GetDevices, SetDevice, handle lifecycle E2E - Room Connection │ 4+ │ Platform audio with room, two participants, device switching All tests handle missing audio devices gracefully (CI-friendly). Run the Example List Audio Devices cargo run -p basic_room -- --list-devices Connect with Platform Audio (microphone capture) LIVEKIT_URL=wss://your-server.livekit.cloud \ LIVEKIT_API_KEY=your-key \ LIVEKIT_API_SECRET=your-secret \ cargo run -p basic_room -- --platform-audio Connect with File Audio cargo run -p basic_room -- --file path/to/audio.raw Connect with Both Platform Audio and File cargo run -p basic_room -- --platform-audio-and-file path/to/audio.raw WebRTC Build Requirements The external_audio_source.patch must be applied to WebRTC. The patch is automatically applied by all platform build scripts: - build_macos.sh - build_ios.sh - build_linux.sh - build_android.sh - build_windows.cmd For local development, set LK_CUSTOM_WEBRTC to point to your patched WebRTC build. Known Limitations Limitation │ Description Process-global │ Audio configuration affects all rooms in the process Device indices │ May change on hot-plug; match by name for persistence Single device track │ One device audio track per ADM (use NativeAudioSource for additional streams) --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-05-12

feat: add scalability mode for AV1/VP9. (#1076) Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-05-11

chore: add LocalTrackRepublished event for FFI clients (#1072) during a reconnect, all published tracks will be republished and receive new TrackID. there is currently no way for FFI to learn about the new TrackID. --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-05-10

support SimulateScenario through FFI to improve testing (#1069) also fixed a few edge cases with connection resumption. added tests --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-05-08

Merge remote-tracking branch 'origin/main' into dc/local_video_metal

2026-05-07

Expose data track subscribe error message for FFI (#1057) Exposes the previously unused `SubscribeDataTrackError` message added in #981 and clarifies behavior for FFI implementors. Resolves BOT-341 --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-04-28

add metal zero copy rendering pipeline & test pattern generator

2026-04-21

Add support for frame level user timestamp (#890) - Add support to attach/parse frame level timestamps to VideoTracks as a custom payload trailer. --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: stavied <40528896+stephen-derosa@users.noreply.github.com>

2026-04-17

wire up rtp timestamp

wip

2026-04-14

rename user_timestamp to user_timestamp_us for consistency w/ data tracks

2026-04-02

Merge branch 'main' into dc/feature/user_timestamp

Data tracks FFI interface (#905) Initial support for data tracks over FFI.

2026-04-01

Merge branch 'main' into dc/feature/user_timestamp

2026-03-31

use the bounded buffer for video stream (#956) Before this PR, it uses an unbounded buffer for video stream, that will cause multiple problems: 1, video will be lagged behind if rendering is slow or just wake up from background 2, it will be out of sync with audio

Merge branch 'main' into dc/feature/user_timestamp

user_timestamp FFI (#980) Expose user_timestamp for video frames to the FFI

2026-03-29

feat: expose participant active event, state, and joined at (#978) Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Jacob Gelman <3182119+ladvoc@users.noreply.github.com>

2026-03-23

add frame ID to ffi

Merge branch 'main' into dc/feature/user_timestamp

2026-03-20

E2EE: allow setting key_ring_size and key_derivation_algorithm (#921) * Allow setting keyring-size from Rust * Implement using HKDF as the KDF. * Reexport KeyDerivationAlgorithm, use const for default KeyDerivationAlgorithm. * Update webrtc * Add changeset * Don't wrongly to m144 change, update webrtc to webrtc-24f6822-2

2026-03-18

add disconnect reason to Room::close (#925)

add bounded buffer to audio_stream, and use 10 frames as the default (#945) * add bounded buffer to audio_stream, and use 10 frames as the default * run cargo fmt * switched over to rtrb and added some tests * Create add_bounded_buffer_to_audio_stream_and_use_10_frames_as_the_default.md added change msg

2026-03-04

adding the PayloadTrailerFeatures to the ffi protos

2026-02-16

turn single peerconnection off by default (#897)

2026-02-15

add is_screencast to VideoSource (#896)

ensure signal connections times out properly and retries (#895) * ensure signal connections times out properly and retries * generated protobuf --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-02-14

added Single Peer Connection support to Rust (#888) * added Single Peer Connection support to Rust * fix the code to make it work for both v0 and v1 (single peerconnection) signaling, add tests * fix the README and make the tests run with localhost, as it will fallback to V0 * cargo fmt * addressed the comments * some improvements on corner cases and added more tests * fix the tests on CIs, as the CIs are running local server, which does not support v1 by default * fix the tests * generated protobuf --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>

2026-02-09

add simulcast support

add can_manage_agent_session permission (#870)

2026-02-08

h264 tcp ingest

2026-02-02

Format

2026-02-01

Upgrade protocol to v1.44.0 (#857)

2026-01-31

Initial prototype

Integrate

2026-01-28

Expose participant's permission to ffi layer (#824) * Expose participant's permission to ffi layer * Init participant's permission

2026-01-23

Add a request_async_id to the async requests (#842) * Add a request_async_id to the async requests * remove the unnedded clone() * revert the livekit-protocol/protocol changes * revert livekit-protocol/protocol * a try to fix the node generate protobuf job * generated protobuf --------- Co-authored-by: github-actions <41898282+github-actions[bot]@users.noreply.github.com>