[0.0.11] - 2026.09.26
Fixed
- Callbacks could still be running after
rtc_destroyreturned: previouslyrtc_destroyonly cleared the callbacks without waiting for callbacks already in progress, so freeingcontextafter it could crash the caller.rtc_destroynow waits for all in-flight callbacks to return before it returns, after whichcontextcan be freed safely - Keyframe callbacks still fired after a local track was destroyed:
rtc_destroy_local_tracknow removes the keyframe callback and waits for in-flight callbacks to return - Calling
rtc_destroyin the disconnect callback deadlocked: you can now destroy the instance from any of its callbacks - When an instance is destroyed before an asynchronous join (
rtc_join_channel) completes, it no longer stays in the channel indefinitely without leaving
The functions and struct layouts are identical to 0.0.10, so you can replace the library files directly. Code that waited a fixed time (sleep) after destroying to work around the issues above can be removed after upgrading.
[0.0.10] - 2026.09.26
Changed
- Debug symbols are stripped from the library files, reducing the size of the Linux
librtc.soby about 27% (17.6 MB → 12.8 MB). Functions and behavior are unchanged, and crash stack traces still print function names and line numbers
The interface is identical to 0.0.9; programs compiled against the 0.0.9 header can replace the library files directly.
[0.0.9] - 2026.09.26
Added
rtc_get_last_error: get the specific error code and reason after a function returnsRTC_ERROR/RTC_TIMEOUT, without digging through the logsrtc_set_disconnected_callback: reports the disconnect reason (removed from the channel / replaced by another session with the same uid / heartbeat timeout / channel destroyed) when the connection finally ends, with theRTC_DISCONNECT_*macrosrtc_get_local_user_info: get the local uid / sidrtc_get_channel_info/rtc_free_channel_infoand thertc_channel_info_tstruct- Added the macOS Apple Silicon platform (
librtc.dylib)
Fixed
- Joining a channel is about 3 seconds faster: previously every join waited idly for about 3 seconds before starting to establish the signaling connection; it now connects immediately (measured join time 3.4 s → 0.4 s). The reconnect interval after a disconnect is unchanged
- Fixed an issue where the runtime treated the instance handle as an invalid pointer at certain moments and terminated the process
- When the channel’s media streaming engine configuration is unknown, the SDK falls back to the default engine instead of failing to join
Breaking changes
- Removed the
rtc_user_info_t.link_idfield (it was always 0 and had no actual meaning)
The callback
context must be a real pointer (or NULL). Don’t cast small integers to pointers to use as IDs; see Instance and channel · Callback registration.