Three formats, three sets of requirements
"Live classes" covers three different products. Treating them as one feature with a switch leads to a provider that suits one format and strains under the others.
| Format | Shape | What it needs |
|---|---|---|
| One-to-one | Two publishers, no moderation | Low latency, reliable reconnection, a simple join |
| Group | One host and a limited group of participants | Host controls (mute, remove, admit), several simultaneous publishers, enforced roles |
| Broadcast | One publisher and hundreds or thousands of viewers | Fan-out at a low cost per viewer, chat, tolerance for several seconds of latency |
Interactive formats suit a real-time communications provider built for many publishers in one room with fine-grained roles. Broadcast at scale suits a one-to-many streaming service, which is engineered and priced for large audiences. Before assuming a streaming service can also back many small interactive rooms, its quotas on room or stage creation and on concurrent publishers need to be checked.
Participant roles and permissions
In production, live-class failures are seldom about video quality. They come from the role model: participants who join with publish rights they should not have, a teacher who sees "waiting for host" because the room does not know who the host is, or an administrator who enters through a name prompt as an unrecognised guest.
Reliable behaviour comes from a few decisions made early:
- Define the roles first. Host, co-host, participant and viewer each get an explicit permission set (publish, subscribe, moderate, record) before any interface is designed.
- Map roles to the provider's own model (templates, privileges or token claims), and verify the mapping by inspecting the provider's configuration instead of assuming defaults.
- Carry identity in the join credential. A signed token that names the user and the role removes the name prompt at the door and the impersonation it allows.
- Make the class format an explicit field. It decides the room type, the roles and the recording strategy, so that those three cannot drift apart.
Recording pipeline
A recording passes through capture, composition, upload, confirmation and playback, and each stage can fail independently. A recording stuck at "uploading 0%" for hours usually has one of two causes: nothing was captured, because no participant held recording rights or the recorder never joined; or the upload finished but was never confirmed.
Two design choices reduce the exposure. Recording sits behind an adapter that yields a single composite file whatever the provider, and the confirmation step is explicit, retried and monitored. A recording that stays pending beyond a threshold raises an alert, and the teacher sees an honest state ("processing", "failed, retry") rather than an indefinite spinner.
Cost per participant-hour
Providers should be compared at the shape of each format, not at headline rates. A one-to-one lesson has two participants for an hour; a group class has a dozen or more; a broadcast has a few publishers and a large audience billed at a lower per-viewer rate. Multiplying participants by duration by unit price for each format gives the figure to compare. The cost structure of an education platform explains why interactive video needs a meter and a ceiling.
Selection principles
- Select the provider per format, not per brand.
- Price per participant-hour at the real audience shape of each format.
- Check regional coverage where the learners are, not where the provider is strongest.
- Design the roles before the interface, and verify them in the provider's configuration.
- Treat recording as a monitored pipeline with an explicit confirmation step.
Jversity offers all three formats: one-to-one, batch and broadcast live classes.