We’ve taken a hybrid approach when building webinar.net, using tightly-coupled computing services with no latency for the Presenters/Moderators, and using HTML5 and streaming technology to distribute content to attendees, which is delayed.
First and foremost - the delay does not affect the attendee experience in any way. Attendees do not notice the delay, as the slides, supporting video clips, polls, etc. are all completely synchronized with the presentation audio and video.
Note. You do not want to have the Presenter Console and Attendee Console open at the same time, or you could get feedback piped through the Presenter console.
TL;DR? We understand :)
More Information
Broadcast streaming systems like webinar.net have a number of moving parts - audio/video capture, transmission to webinar.net servers, encoding, transcoding, redistribution to attendees, decoding and displaying by the user PC/Mac/Tablet/Phone. Each of those processes takes a number of seconds.
“Why doesn’t Zoom have this?”
Zoom is architected like our Presenter Console is - it’s designed for everyone to speak at the same time. It recommends 1.5 MBPS bandwidth, whereas webinar.net is designed to work with nearly half as much available bandwidth - 800kbps.
Zoom, Gotomeeting, Webex, etc. also requires attendees to download, install, and keep their app updated. Not a great user experience and these tightly-coupled services do not scale well to large numbers of participants.