-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect orientation of a remote video track's dimensions #1377
Comments
@lukasIO Is this closed or open? :) Any idea why it happens and whether you plan to work on it anytime soon? |
This is also something we bumped into. We took the track from the Our current workaround is to look for import type { TrackPublication } from 'livekit-client'
const getVideoDimensions = (videoPub: TrackPublication) => {
const mediaTrackSettings =
videoPub?.videoTrack?.mediaStreamTrack?.getSettings()
return {
width: mediaTrackSettings?.width || videoPub?.dimensions?.width,
height: mediaTrackSettings?.height || videoPub?.dimensions?.height
}
} Would love to get rid of this convoluted piece of code anytime though :) |
For context: The best way I've found to get actual dimensions of the currently subscribed video is to read from It sounds unexpected to me that the dimensions of the original publication are flipped though, but relying on the workaround I mentioned should yield the desired results without any flipping |
Describe the bug
What I'm expecting
Our testing mobile clients send video tracks in portrait mode, so we expect to receive
dimensions: { width: 720, height: 1280 }
and video tiles to display using the 'portrait' orientation logic.What happens instead
Our testing mobile clients send the video tracks correctly. In WebRTC debugging tools (about://webrtc-internals) I can see the dimensions and orientation are correct under
inbound-rtp
(width: 720, height: 1280), as expected.However, when I console.log the remote track, I see
dimensions: { width: 1280, height: 720 }
, as if LiveKit SDK flipped them.Reproduction
Logs
System Info
Severity
annoyance
Additional Information
No response
The text was updated successfully, but these errors were encountered: