lib-jitsi-meet: The remoteTrack.videoType is undefined for camera tracks
This Issue tracker is only for reporting bugs and tracking code related issues.
Before posting, please make sure you check community.jitsi.org to see if the same or similar bugs have already been discussed. General questions, installation help, and feature requests can also be posted to community.jitsi.org.
Description
because of the change to JitsiConference.js in https://github.com/jitsi/lib-jitsi-meet/commit/d73723dae68ccbda83b529ed30c2c3340d9f3e0d , the videoType of a remote track is undefined when received, if the type is in fact ‘camera’.
this causes compatibility problems if 1) the client relies on videoType for rendering logic, 2) mixed client lib versions in the same room (e.g. current stable to next stable)
Current behavior
the videoType from a newly received remote camera track is undefined.
Expected Behavior
videoType to be camera when it is a camera track.
Possible Solution
always send ‘videoType’ in presence as before - revert the change in JitsiConference.js
Steps to reproduce
2 person join beta.meet with camera on, inspect the videoType of remote video tracks
Environment details
meet unstable
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15 (6 by maintainers)
@damencho maybe then the field should be initialized to camera instead of being
undefined?No the fix just sets a default and that default is sometimes wrong. You still need to listen for the video type change event to rectify that if a wrong video type was set
Isn’t that fixed with https://github.com/jitsi/lib-jitsi-meet/commit/79afa717178c8e79390af2178870358bbf17759d
I researched and it seems like the newly documented
TRACK_VIDEOTYPE_CHANGEDis what I was looking for. I can listening to it and adapt as needed if the videoType is undefined