How to run an online event with fewer technical problems
Tech tips from George Chiesa
Translated and tweaked from his original article on LinkedIn
I attended a very good international event today, with speakers and audience from all over the world. However, the transmission had countless problems – which resulted in comments and complaints in the chat.
Halfway through the event, I created this summary of the most useful suggestions. These apply regardless of whether or not you hire an external company to help you.
- Define whether the live event will be consumed by an audience at home or at the office, since the logistics are different.
If the audience is at home, the infrastructure and logistics planning requirements are even higher, not only because the tolerances are more critical, but also because the accumulated errors make a transmission of marginal quality become less fit (or even completely useless), because participants can’t see and/or hear at all well.
- Consider how and where the speakers are transmitting from, because it is impossible to fix the audio and video signal if it arrives badly at the mixing/transmission centre.
There was a speaker that had a current low quality (band/latency) connection. I say “current” because what one buys is always specified “up to” – for example, “up to 300Mb (implicitly download). It should be measured in conditions similar to those on the day of transmission.
Home connections are rarely symmetrical, so 300Mb of download can only be 1Mb of upload. In addition, there is “sharing” or “contention”. If you have a neighbour with a torrent server, it’s just as problematic as when someone in your family has torrent on their PC.
You need to know whether the user who broadcasts (the speaker) will be able to speak and be heard clearly, if they will be able to split the screen, and whether they can send a live video image.
If you, as transmission coordinator, plan to use OBS, you need to have very good up-link capabilities. If you don’t have symmetrical fibre connection, you are unlikely to have a very smooth transmission, due to the (2x at least) requirements of OBS. This is a big issue for “live” events on LinkedIn [and others]. If you can’t up-link 30Mb/s, beware.
Use tools such as SpeedTest.net from Ookla or others, to measure both down and up speeds from the computer of the person presenting, with all the active tasks that are going to be used except the transmission tool (for example, Zoom). Verify the values of MBs, Latency, Packet Loss, Ping & Jitter from their PC to a server close to the reception point. That means measuring to the audience’s location (say, USA), not to the transmitting user’s local internet service provider in the UK.
If the values are not optimal, the speaker should use 4G from their phone, ideally with tethering via USB, or Bluetooth to the PC, or, in the last case, via wifi.
Speaking of wifi, there are urban areas where 2.4Gz spectrum pollution is unacceptable, so if you can’t use CAT-5 cable, at least use 5gz band.
Everything that is transmitted must be useful content for the user. A virtual background consumes bandwidth for the receiving user, as it makes the minimum resolution required to read it greater. (If your background is animated or moving, it’s even more demanding of bandwidth.)
Unless you have special requirements for your presentation, the camera should be at the minimum definition possible to see your most essential facial and/or hand gestures. That means it doesn’t make sense to transmit in 4k or 1080, when 720 or even less is enough.
The largest size your image will appear is in a small square in picture-in-picture mode in grid view, or in full screen speaker view.
The speaker’s screen should be configured with the minimum resolution necessary to display the content (typically 1024xxxx and not 1920×1080). Never in higher resolutions, and much less in “native retina” mode of the Mac, which is typically 4K.
If a slide is in grid view in the middle of the screen, I can’t read it at 240. To see that slide, I must view the entire screen, and raise the resolution to 480 or higher. The bandwidth consumed is proportional to that.
All speakers should mute 100% of the time they are not speaking. Also, all speakers ought to use headphones, even if they are just iPhone earbuds. This avoids feedback, echo, background noise, reverb, white noise, pink noise, and “ground noise” (50hz tone due to bad connection).
There should be one user or co-host who monitors the chat for messages and questions, and another person to deal with logistics / connection / and other technical problems.
If 4G tethering or hotspot are not enough, then tell participants to turn off their camera.
Before the meeting, all contributors should have loaded a static image of themselves into their Zoom.us profile. Then, if there are problems and you ask them to turn off the camera, their video feed which was consuming bandwidth is replaced by a static headshot, not just a plain black box with their name across it.
It’s a tiny change but makes a huge difference when contributors are at home in less professional environments (network-wise).