You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: bridge/README.md
+10-12Lines changed: 10 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,5 +1,7 @@
1
1
# LiveKit Bridge
2
2
3
+
# **WARNING: This library is deprecated, use the base sdk found in src/**
4
+
3
5
A simplified, high-level C++ wrapper around the [LiveKit C++ SDK](../README.md). The bridge abstracts away room lifecycle management, track creation, publishing, and subscription boilerplate so that external codebases can interface with LiveKit in just a few lines. It is intended that this library will be used to bridge the LiveKit C++ SDK into other SDKs such as, but not limited to, Foxglove, ROS, and Rerun.
4
6
5
7
It is intended that this library closely matches the style of the core LiveKit C++ SDK.
@@ -98,44 +100,41 @@ Your Application
98
100
99
101
**`BridgeAudioTrack` / `BridgeVideoTrack`** -- RAII handles for published local tracks. Created via `createAudioTrack()` / `createVideoTrack()`. When the `shared_ptr` is dropped, the track is automatically unpublished and all underlying SDK resources are freed. Call `pushFrame()` to send audio/video data to remote participants.
100
102
101
-
**`BridgeRoomDelegate`** -- Internal (not part of the public API; lives in `src/`). Listens for `onTrackSubscribed` / `onTrackUnsubscribed` events from the LiveKit SDK and wires up reader threads automatically.
102
-
103
103
### What is a Reader?
104
104
105
105
A **reader** is a background thread that receives decoded media frames from a remote participant.
106
106
107
-
When a remote participant publishes an audio or video track and the bridge subscribes to it (auto-subscribe is enabled by default), the bridge creates an `AudioStream` or `VideoStream` from that track and spins up a dedicated thread. This thread loops on `stream->read()`, which blocks until a new frame arrives. Each received frame is forwarded to the user's registered callback.
107
+
When a remote participant publishes an audio or video track and the room subscribes to it (auto-subscribe is enabled by default), `Room` creates an `AudioStream` or `VideoStream` from that track and spins up a dedicated thread. This thread loops on `stream->read()`, which blocks until a new frame arrives. Each received frame is forwarded to the user's registered callback.
Reader threads are managed entirely by the bridge. They are created when a matching remote track is subscribed, and torn down (stream closed, thread joined) when the track is unsubscribed, the callback is unregistered, or `disconnect()` is called.
114
+
Reader threads are managed by `Room` internally. They are created when a matching remote track is subscribed, and torn down (stream closed, thread joined) when the track is unsubscribed, the callback is unregistered, or the `Room` is destroyed.
115
115
116
116
### Callback Registration Timing
117
117
118
-
Callbacks are keyed by `(participant_identity, track_source)`. You can register them **before** the remote participant has joined the room. The bridge stores the callback and automatically wires it up when the matching track is subscribed.
118
+
Callbacks are keyed by `(participant_identity, track_source)`. You can register them **after connecting** but before the remote participant has joined the room. `Room` stores the callback and automatically wires it up when the matching track is subscribed.
119
119
120
120
> **Note:** Only one callback may be set per `(participant_identity, track_source)` pair. Calling `setOnAudioFrameCallback` or `setOnVideoFrameCallback` again with the same identity and source will silently replace the previous callback. If you need to fan-out a single stream to multiple consumers, do so inside your callback.
121
121
122
122
This means the typical pattern is:
123
123
124
124
```cpp
125
-
// Register first, connect second -- or register after connect but before
// When robot-1 joins and publishes a mic track, my_callback starts firing.
132
131
```
133
132
134
133
### Thread Safety
135
134
136
135
-`LiveKitBridge` uses a mutex to protect the callback map and active reader state.
137
136
- Frame callbacks fire on background reader threads. If your callback accesses shared application state, you are responsible for synchronization.
138
-
-`disconnect()` closes all streams and joins all reader threads before returning -- it is safe to destroy the bridge immediately after.
137
+
-`disconnect()`destroys the `Room`, which closes all streams and joins all reader threads before returning -- it is safe to destroy the bridge immediately after.
139
138
140
139
## API Reference
141
140
@@ -226,9 +225,8 @@ The human will print periodic summaries like:
226
225
## Testing
227
226
228
227
The bridge includes a unit test suite built with [Google Test](https://github.com/google/googletest). Tests cover
229
-
1.`CallbackKey` hashing/equality,
230
-
2.`BridgeAudioTrack`/`BridgeVideoTrack` state management, and
0 commit comments