Ask the room.
At the moment
you asked it.
Polls, quizzes and Q&A carried inside the video. Every viewer sees the question at the point in the stream where it was asked — whether they are at the live edge or thirty seconds behind it.
- Concurrent
- 200k+
- Cue accuracy
- 1 segment
- Extra encode
- None
A question sent over a socket arrives at the wrong time.
Live viewers are never in the same place. Buffering, bitrate and distance leave them seconds apart. Push a question to everyone at once and the ones running behind are asked about something that, for them, has not happened yet.
Ask something. Watch it land.
The left is what a broadcaster sees. The right is what the audience sees. Write your own question, send it, then answer it yourself.
Nothing on screen. Ask a question on the left.
The question travels with the picture.
A cue is written into the media itself, so it arrives with the frames it belongs to. There is nothing to fetch at the moment a question appears, and nothing to go wrong if a connection drops.
- 01 — Ask
One API call
The question is written down, then handed to the encoder packaging your broadcast. It goes into every rendition, so a viewer stepping down to a lower bitrate never loses it.
- 02 — Carry
Inside the segments
The whole question rides in the media as timed metadata — prompt, options and all. Your player reads it from the stream it is already downloading.
- 03 — Answer
Counted once
Answers return over a socket built for the shape of a live room: one vote per viewer, tallies coalesced, results written down when the question closes.
Built for the moment everyone answers at once.
A poll's traffic does not arrive evenly. It arrives in the four seconds after the question appears, from everybody, at the same time.
So a room is not one process. It is a tree: the audience is spread across shards that each hold their own slice of the connections and fold what happened into one report per second. What reaches the centre scales with the number of shards, not the number of viewers.
- Concurrent viewers
- 200,000+
- Shard growth
- Automatic
- Tally freshness
- ~1s
- Added encode cost
- None
Per room, before adding shards.
Capacity is added before shards fill, not after.
Merged across every shard.
Cues are packaged, not re-encoded.
The recording stays interactive.
Every question is stored with the second of the broadcast it was asked at. Play the recording back and they arrive at the same points, in the same order.
Answers from the recording are counted separately from the live result, and never merged into it. A broadcast is a record of a moment; a recording collects answers for as long as anyone watches it, and letting the two mix would quietly rewrite what the live audience said.
Our player, or yours.
The hosted player draws the overlay for you. If you have your own front end, the SDK gives you the events and you draw whatever you like.
Everything the dashboard can do is on the public API too, reachable with an environment-scoped key — so a customer running their own dashboard and their own player is not a second-class user of this product.