I have been hosting meetings for my clients for about 9 months and decided to try the GoToMeeting Hub Virtual Background. Aside from the relatively robust hardware requirements (which I've met), I'm wondering if anyone has had Internet bandwidth issues using this feature. It is currently showing as in Beta-testing, and I had 200 Mbps down/20 Mbps upload broadband, and recently I'd had several meetings where the video/audio began breaking up. The meeting had about a dozen participants, sharing a screen and using cloud recording. I had to switch from the Chromacam virtual camera back to my physical webcam to restore continuity of the meeting I was hosting. It appears that the upstream bandwidth required to send video up to (Chromacam hosting) and back down is impairing the basic meeting functionality. I use Zoom with my other clients, and the background is locally processed rather than being a cloud service so this isn't a problem there. Hopefully others have had experiences to compare? Thanks for your feedback.
@gwtechllc This is more of a local processing issue than bandwidth, unless you're using Chromacam to share video backgrounds or similar, thereby increasing the video f/s demand. Have you checked your local processing behavior to make sure it is not approaching to 80-100%?
I had not checked this specifically, although I did not notice other symptoms of an overtaxed processor. In order to facilitate testing, would you suppose that a G2M would need to have a similar number of participants (a dozen)? I just want to clarify the use case. Thanks for the reply.
I had to reinstall ChromaCam to test this, and I'm not clear on what the results are telling me. When ChromaCam is in Preview (no meeting), it is using over 13% CPU. However, when I start it meeting and select it for Video input (using Meet Now - no participants), it uses less than 1%. In my work as a meeting facilitator, I need to be confident that the A/V quality is consistent on the cloud recording. When the A/V starts breaking up during a meeting, I need to take steps to correct the problem.
That sounds like it's working a little bit better, but I recommend hosting some test broadcasts with all the materials and webcams you plan to incorporate, while recording to the cloud to ensure the playback quality is as expected.
I had an opportunity to test the ChromaCam today, and it was actually for a (vendor's) 3rd-party conferencing App. I mention this because it appears that it is the ChromaCam App itself, rather than a dependency with GoToMeeting. The App did not appear to be pulling excessive CPU on my laptop, and it was impacted by the symptoms I had seen previously. The audio was acceptable, but the video (self-view) was delayed by almost 1 second. And this was on a 1-to-1 video call, where the previous experience with a G2M of a dozen or so people also appeared to have local audio/video artifacts impacting the remote attendees. I did upgrade my internet service late last week but have not held a G2M since that took place. Since the ChromaCam tool is still in Beta-testing, I'm wondering if it is overloaded with "testing hooks"?