voltkit_rtc 0.6.0

Flutter SDK for VoltKit RTC: realtime audio and video rooms, in-room and standalone chat, and live broadcast publishing over WHIP.

0.6.0 (prepared; iOS preview unverified)

• Hardened Android/shared screen cleanup: cancellation during consent prevents late capture startup; partially failed foreground-service starts invoke stop; individual track/stream/service cleanup failures warn without preventing remaining cleanup or room close. Existing service callbacks stay compatible.

• Prepared an explicitly opt-in iOS ReplayKit preview: native lifecycle plugin, complete Broadcast Upload Extension template and safe app-specific preparation tool. Checks embedded extension/App Groups, handles start timeout/cancellation, system stop, pause/resume and failed-start cleanup independently of the camera.

• ScreenPublishOptions.iosBroadcastEnabled defaults to false; iosStartTimeout defaults to 60 seconds. Added onScreenSharePaused. Caller-supplied iOS captures are supported and remain caller-owned.

• Extension forwards bounded, orientation-aware video frames only; existing mic/music and Android/desktop APIs remain unchanged. Native compilation and Apple-device acceptance are unverified: see doc/IOS-SCREEN-SHARING.md.

• Paid direct-to-R2 file uploads with bounded multipart concurrency; authoritative recording policy and completed-file ID/playback/90-day expiry metadata. Android camera-only recording preview is opt-in, video-only and device-unverified; iOS recording remains unavailable.

0.5.0

• Roster moderation locks and request metadata; onParticipantMuted normalizes wire state. Reconnect preserves restrictions, rejected unmute calls remain paused, and screen restoration failures clean up the share without blocking the camera. Screen video respects per-project abuse restrictions. Receive preferences are applied before resuming the consumer.

• All qualities included: 1080p, 720p and 480p. Default policy is 1080p/60 fps; administrators can still restrict an individual project.

• New 30 fps top-layer ladder: 6 Mbps / 3 Mbps / 1.2 Mbps. Opt-in VideoPublishOptions(frameRate: 60) raises only the top layer to 9 / 4.5 / 1.8 Mbps; lower layers stay at 30 fps. maxFramerate remains compatible. Capture/device fallback reports frame-rate-fallback on onPublishWarning; sender statistics monitor sustained slow 60 fps output.

• setReceiveQuality(producerId, 'auto' | '1080p' | '720p' | '480p') uses advertised actual layer dimensions and remembers the choice by participant and source across reconnects. Missing layouts report quality-unavailable, with automatic reception still available.

• publishScreen, unpublishScreen, ScreenPublishOptions, screenSharing, screenStream, onScreenShareStarted and onScreenShareEnded: detail (15 fps, 2.5 Mbps) or motion (30 fps, 6 Mbps), both with a 600 kbps lower layer and optional separate screen-audio. Camera, mic and music remain independent. Live screen captures are republished on reconnect.

• Android requires a MediaProjection foreground service supplied by the app; desktop apps select a source through desktopCapturer. Native screen frame dimensions are measured before publishing instead of assuming a 1080p monitor. iOS is explicitly unsupported until a complete ReplayKit extension is provided. See the README for setup and native capture limitations.

0.4.0

• Sharper video: higher bitrates. layerBitrate, which sets each layer's bitrate from its size when topBitrate is unset, now gives about 4 Mbps at 1080p, 2.5 Mbps at 720p, 1.5 Mbps at 540p, 1 Mbps at 480p, 700 kbps at 360p and 400 kbps at 240p (was 2.5 Mbps, 1.8 Mbps, 1.2 Mbps, 750 kbps, 600 kbps and 250 kbps). On a 720p camera picture, 2.5 Mbps brought the encoder's quantiser down from about 64 to about 55: finer detail, most of all in motion. The default two layers at 720p are now 640x360 at 700 kbps and 1280x720 at 2.5 Mbps, about 3.2 Mbps of upload. The same table as the browser SDK 0.4.0.
• The service's per-publisher caps rose to match: 4 Mbps up to 720p, 7 Mbps with 1080p (were 3.2 and 5). An explicit topBitrate works as before.
• The other encoding defaults are unchanged: two layers, hardware H.264 preferred and MAINTAIN_RESOLUTION.
• Fix: reconnecting gives up when it should. Signaling restarted its attempt count whenever the socket opened, so a join refused with a code worth retrying (no-capacity, no-node, internal) was retried about twice a second, forever, and onClosed never said gaveUp. The count now restarts only once a join succeeds, the waits keep growing, and after maxReconnectAttempts (8) failed attempts in a row the session ends with ClosedReason.gaveUp. StreamClient and ChatClient both reconnect through it.
• Fix: a camera that is off stays off, on both ends. A track handed to publishStream switched off, or a camera, microphone or music switched off before a reconnect, made a producer paused in the app but live on the server, so viewers got black video or silence under a camera or microphone shown as on. The server is now told. And a reconnect with the camera and microphone both off took their switched-off tracks for ended ones: it asked for the devices again while still holding them, and published them switched on. It now publishes the same tracks again, still off.
• Fix: unpublish() forgets the devices. It kept the capture constraints publish() used, so after unpublish() and then publishMusic(), a reconnect asked for the camera and microphone again and published them. Music published after unpublish() now reconnects alone.
• Fix: unpublish() while a publish is still being made leaves nothing published. A producer that arrives afterwards is closed on both ends, and that publish(), publishStream() or publishMusic() fails at once with RpcError code unpublished instead of waiting out its 20 s timeout. unpublish() makes all its changes at once and only then waits, so a publish called while it still waits is not undone by it.
• Fix: a first connect() that fails at the join closes its socket, and Signaling reconnects only a session that has joined. Before, the server's join deadline closed that socket about 15 s later and started reconnecting a session that had never begun.

0.3.0

• Video quality. VideoPublishOptions(quality: VideoQuality.p1080 / p720 / p480). StreamClient.videoPolicy says what the project may publish (from the join result's new video field) and videoQuality what is being sent. 1080p needs the project to allow it (it does during the free trial); asking for more publishes the highest allowed.
• Layers follow the picture's real size. A picture too small for the layers asked for used to lose its top ones, so viewers got half the resolution; now 480p is sent as two layers and small pictures as fewer.
• Fix: publish() captures 720p by default. It asked the camera for 640x360, so the default broadcast was 360p while the docs said 720p. It now captures at the quality being published.
• topBitrate is optional: unset, it follows the picture's size (2.5 Mbps at 1080p, 1.8 Mbps at 720p, 750 kbps at 480p). Setting it works as before.
• New exports: VideoQuality, VideoPolicy, layerBitrate.

0.2.1

• onUsageLimit on StreamClient and ChatClient, with UsageLimit (reason, graceSeconds, endsAt): the project ran out of minutes or hit a daily or monthly usage limit, and the session will be ended at endsAt unless it is topped up. Show it to the user.
• A session the server ended on purpose (WebSocket close code 4003, after roomClosed or a final usageLimit) is final and is not reconnected.
• Fix: a promoted viewer now moves to a new connection with the token for its new role. Before, it kept the old connection and its viewer token, so the promotion did nothing and publishing was refused.
• Fix: after a reconnect, the client no longer subscribes to its own tracks (the room state lists them), which played a host a delayed copy of itself.
• A publisher who is demoted stops publishing and releases the camera and microphone (the server now closes a demoted publisher's tracks itself).
• After a reconnect, the client uses the fresh TURN credentials from the new join instead of the original ones, which expire after 12 hours by default.
• RpcError.isTerminal now matches the codes the server sends: no-room, wrong-tenant, quota-exhausted, daily-limit-reached and monthly-limit-reached stop reconnecting instead of retrying.

0.2.0

First release on pub.dev. The package was previously distributed by path as stream_client; only the package name changed, so migrating is the dependency line and the import.

• Works on current Flutter and Android. Built on flutter_webrtc 1.6. The mediasoup client is now included in the package with fixes that publishing from a real Android device needed: a race between the transport and its peer connection, simulcast RID parsing, a crash when an encoding has no scalability mode, and header extension IDs current libwebrtc rejected. The previous dependency on mediasoup_client_flutter 0.8.5, which no longer builds, is gone.

• micEnabled and camEnabled getters, as in the browser SDK.

• Simulcast layers send three temporal layers each (L1T3).

• Chat. StreamClient gains sendMessage, getMessages, deleteMessage, muteChat, setTyping and getChatState, with onMessage, onMessageDeleted, onChatMuted and onTyping. Direct messages, ephemeral messages and paged history are supported.

• ChatClient for chat with no media, on its own connection.

• BroadcastPublisher for publishing a live broadcast over WHIP, H.264 only so the media server never has to transcode.

• Music. Tracks now say what they carry (RemoteTrack.source: mic, music, camera, screen), so a viewer app can give music its own volume. publishMusic, setMusicEnabled and stopMusic publish music as a track of its own; setMicEnabled no longer touches it. onTrackMuted gains source.

0.1.0

Rooms, roles, moderation, exclusive slots, simulcast publishing and reconnection. Not published.