Describe the bug
On iOS, screen-share tracks never report their dimensions: mediaStreamTrack.getSettings() returns only deviceId, groupId, and frameRate there is no width/height.
Because of this, every screen-share publish through livekit-client logs the error could not determine track dimensions, using defaults, and the track is published with default 1280×720 encodings instead of the actual screen resolution.
Camera tracks on iOS and all track types on Android do report width/height in their settings but the iOS screen capture appears to be the only path that doesn't.
To Reproduce
- iOS app with
@livekit/react-native, connected to a room
- Start a screen share (
localParticipant.setScreenShareEnabled(true) with the broadcast extension)
- Observe the console:
could not determine track dimensions, using defaults logged by livekit-client
- Inspect the publish: track dimensions / encodings are for 1280×720 rather than the device screen size
Expected behavior
getSettings() on an iOS screen-share track reports the capture dimensions, like camera tracks do. livekit-client's waitForDimensions() then resolves during publish with no error logged, and encodings are computed for the real screen resolution.
Screenshots
N/A
Device Info:
- Device: any iPhone (reproduced on iPhone 12–16 range in production)
- OS: iOS 17 / 18
Dependencies Info (please reference your package-lock.json or yarn.lock file, not just your package.json):
- @livekit/react-native: 2.10.2
- livekit-client: 2.18.9
- @livekit/react-native-webrtc: 137.0.3 - however this issue is still present on master
Additional context
I've applied this patch locally:
CGSize screenSize = [UIScreen mainScreen].nativeBounds.size;
return @{
@"deviceId" : self.deviceId,
@"groupId" : @"",
@"frameRate" : @(30),
@"width" : @((NSInteger)screenSize.width),
@"height" : @((NSInteger)screenSize.height)
};
I used [UIScreen mainScreen].nativeBounds because ReplayKit captures the full device screen at native pixel resolution so the broadcast frames arrive with matching Buffer-Width/Buffer-Height in ScreenCapturer.m. It's a static portrait snapshot (doesn't follow rotation), which seemed acceptable since the camera controller similarly reports its selected format rather than live dimensions.
It's been working well, the error is gone and screen-share encodings now match the screen resolution but I'm not sure it's the best approach, so flagging the issue rather than opening a PR directly. Happy to put one up if this direction (or another) makes sense to you.
Thanks!
Describe the bug
On iOS, screen-share tracks never report their dimensions:
mediaStreamTrack.getSettings()returns onlydeviceId,groupId, andframeRatethere is nowidth/height.Because of this, every screen-share publish through livekit-client logs the error
could not determine track dimensions, using defaults, and the track is published with default 1280×720 encodings instead of the actual screen resolution.Camera tracks on iOS and all track types on Android do report width/height in their settings but the iOS screen capture appears to be the only path that doesn't.
To Reproduce
@livekit/react-native, connected to a roomlocalParticipant.setScreenShareEnabled(true)with the broadcast extension)could not determine track dimensions, using defaultslogged by livekit-clientExpected behavior
getSettings()on an iOS screen-share track reports the capture dimensions, like camera tracks do. livekit-client'swaitForDimensions()then resolves during publish with no error logged, and encodings are computed for the real screen resolution.Screenshots
N/A
Device Info:
Dependencies Info (please reference your package-lock.json or yarn.lock file, not just your package.json):
Additional context
I've applied this patch locally:
I used
[UIScreen mainScreen].nativeBoundsbecause ReplayKit captures the full device screen at native pixel resolution so the broadcast frames arrive with matchingBuffer-Width/Buffer-HeightinScreenCapturer.m. It's a static portrait snapshot (doesn't follow rotation), which seemed acceptable since the camera controller similarly reports its selected format rather than live dimensions.It's been working well, the error is gone and screen-share encodings now match the screen resolution but I'm not sure it's the best approach, so flagging the issue rather than opening a PR directly. Happy to put one up if this direction (or another) makes sense to you.
Thanks!