-
Notifications
You must be signed in to change notification settings - Fork 477
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
Streams can get mixed up or blank when using simulcast #1805
Comments
Thanks for the report. Do you have any reproductions with logs enabled? If not do you have a call ID with an approximate timestamp? I don't think that issue linked would caused swapped streams, but I have been looking into logic in the transceiver controller to see if a certain order of adding and removal could cause the mapping to get out of order. Lastly, wanted to confirm:
|
A possible fix is in #1831 but it is hard to be sure without aforementioned logs and answers. |
#1841 has also been submitted to fix the aforementioned github issue. For testing if truly desired you could combine with #1831 (on chrome, or use the special branch linked there for firefox), or just #1841 . As #1831 was blocked on backend delay, we have had to push it to the release after the one this week. |
Pardon the delay. #1831 was finally merged, will be included in 2.26 and hopefully makes this issue impossible. Please let us know if you still see it after picking up that change. I will close this issue on 2.26 release. |
Argh...so sorry about all of this. I had finally gotten #1831 in close to us wanting to release 2.26 and it turns out there was an additional regression that I hadn't caught (or maybe some new interaction with some change over the past 2 months), so I am just reverting in #1965 to unblock. I will get it in 2.27 though. Note that #1937 was included in 2.26 and fixes the more common 'blank' video with simulcast. I have not been able to reproduce the mixed up frames so its possible those are fixed too, #1831 was mainly for #1807 but it has the other benefit of making mixed up streams nearly impossible. |
Shipped in current release. Please open a new issue with logs if seen again. |
What happened and what did you expect to happen?
Attendee 1 renders stream of attendee 2 and attendee 2 appears blank.
The issue is random, happens only locally for some attendee(s), does not revert to its initial state no matter what change (except browser refresh) any attendee makes (whether local or remote), and only happens when simulcast is active.
Upon further testing, it seems that the issue does not happen with simulcast disabled.
Mentions:
Default attendee broadcast quality: 180p at max/100Kbps
When made speaker/spotlight attendees will have their local stream stopped and then re-started in order to broadcast with a higher quality: 960p. Quality is reverted to 180p when an attendee is no longer in spotlight.
Screen-sharing is not affected and remains the only stream that is broadcast at 1080p without bandwidth restrictions
Streams are rendered using RemoteVideo from
amazon-chime-sdk-component-library-react
What we'd like to know if this mixup can happen because of this issue #1448.
Also we tried applying the patch from the comment and while it did improve things, it seems that the mixup can still happen.
Have you reviewed our existing documentation?
Reproduction steps
Join meeting, start/stop cameras or just wait.
Amazon Chime SDK for JavaScript version
2.21.1
What browsers are you seeing the problem on?
Chrome
Browser version
96.0.4664.45
Meeting and Attendee ID Information.
No response
Browser console logs
We were not able to reproduce the issue with logs enabled.
The text was updated successfully, but these errors were encountered: