From a technological perspective, streaming with a couple of seconds delay is a world of difference from streaming with sub-second latency. You can account for network dynamics with more buffers, encode in higher quality, even using multiple passes, transcode to multiple targets etc.

“Chaturbate is the best video chatting product” is a catchy line. Has anyone done a comparison post?

Zoom getting the music audio through mic sounds like the real problem. You should be aiming to stream the audio from digital source. Then you could have the song titles overlaid on video. There's definitely licensing issues though. The instructors are probably already not using legit licenses for their classes though.

Also a lot of audio codecs are tuned towards speech and filter out high frequencies. You should pick one meant for music.

We thought about suggesting spotify playlists while zoom classes are live... and zoom manages to screw with other app's audio sources as well somehow.

Give it a try.

Start playing any form of music through your phone.... mp3... youtube... spotify app... and then open a zoom meeting.

It distorts the sound of the music so much and I can't figure out why they would do that or what purpose it serves.

Probably just poor coding.

Most of the steaming platforms use HTTP Live Streaming (HLS) because it avoids all the networking NAT headaches that come with p2p connections and it handles variable quality better because each client fetches the best quality for their bandwidth. As far as I know, with WebRTC the sender degrades quality to satisfy the slowest peer.

That said, the downsides of HLS are potentially higher infrastructure costs required to transcode video to the different qualities and somewhat related is the higher latency to live. With proper tweaking you might get 2-3 seconds of latency, but it might be too much for your use case.

If there is voice interaction between the yoga instructor and their students the HLS delay will certainly be noticeable.

> WebRTC the sender degrades quality to satisfy the slowest peer

No, WebRTC is 1 to 1. Each connection is adapted independently. But, you can build services that have rooms with more participants, then it's up to you to shape the traffic as you want. If you use a central server (SFU), it can just send each peer the best they can receive, each independently from one another. It's a property of the service, not the technology.

Any luck with Jitsi meet ? https://github.com/jitsi/jitsi-meet

I looked into that but it's not ideal mainly because we don't need a video conferencing system.

I suppose I could dig through the code and disable anyone but the host's video feeds but I don't have a lot of time to dedicated to this project unfortunately.

I just try to help them out when I can.

Isn't your usecase just a one-to-many stream, like e.g. Youtube, Twitch, Periscope, etc. all provide? That should be easier than a proper n-way meeting.

They all do that, but showing youtube advertisements to paying clients isn't ideal.

Also youtube makes it difficult to restrict who can and cannot see the video.

Without a pay wall there is little incentive to make payment.

Some studios have done OK with a donation/pay what you can model but those donations and rapidly dwindling now in the third month of Covid.

While the video streaming isn’t that great on zoom, my experience is the audio quality piped through their custom audio thing for maxis is pretty good.

I think Zoom's audio filtering (which in my experience is pretty good) is designed only for speech, and so other sounds like music can get messed up.

Have you tried the share using the internally piped audio option? The quality Is good.

It is a truism that porn always pushes the Internet’s state of the art forward.

One way streaming can be prerecorded and shared as video.