-
Notifications
You must be signed in to change notification settings - Fork 22
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
Video store rules all #654
Video store rules all #654
Conversation
…same stream source
Good catch! |
9fceac3
to
366fefe
Compare
Fixed. |
366fefe
to
fa31936
Compare
I forgot to test the recording widget stuff. I'll make the review tomorrow =) |
It initially has the configuration of the allowed ICE IPs.
We don't have Secure Context right now, so it does not have value.
fa31936
to
68db7a1
Compare
68db7a1
to
699f90b
Compare
Thanks for the quick approval @patrickelectric! I will only wait to see if there's something from @joaoantoniocardoso before we merge it. @ES-Alexander I'm going to merge it without the docs changes as it's a critical bug fix and the changes on docs are small. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested. All seems fine!
It also helps #633, fixing the error "2".
With this patch, the video store begins being responsible for internally routing available video streams.
Screen.Recording.2023-12-15.at.17.59.36.mov
Instead of having each video stream consumer (e.g.: VideoPlayer, MiniVideoRecorder) taking full control of the stream it is consuming, we delegate that to the video store, with the widget solely requesting (to the store) the stream it needs. The video store them checks if the requested stream is already being consumed, and if so, routes the same stream, instead of opening a new one with the WebRTC server, which was causing unnecessary usage of both bandwidth and computer resources, to the point of causing system failures or video stuttering.
In resume, with this patch one can add as many widgets as it wants for a same stream and only one connecting will be made to consume it.
I explicitly followed a non-reactive interval-based approach, as I'm not fully confident on the reactive behavior of the WebRTC composable yet. I think we still have an opportunity in the future to improve this code, making it completely reactive, but as it is the performance footprint is very small, and we benefit from having this patch sooner, fixing a critical problem being experienced by our beta testers.
Fix #360
Fix #602
Helps #633.
PS: