Short answer A position is shared, corrected past about half a second of drift, and refused when a player is not ready for it.
Synchronising two video players sounds like a solved problem: send the position, set the position, done. It is not, and the reason is that a video player is not a variable you can assign. It is a state machine with opinions — about whether it has data, whether it is allowed to move, and whether the number you just gave it is reachable at all.
The loop, in plain terms
Each side watches its own player and reports meaningful changes to the room: a play, a pause, a jump, a rate change. The other side receives that and asks: given what I know, where should I be right now?
The answer is not just the number that arrived. A message takes time to travel, and the sender kept playing while it was in flight — so the position you were sent is already stale by the time you read it. It has to be projected forward by roughly how long it took to arrive, or every correction would nudge you slightly backwards. Do that a hundred times over a film and you would be a minute behind.
Why the tolerance is about half a second
A correction is applied when the two sides are more than roughly 0.55 seconds apart. That number is a compromise between two failure modes, and it is worth understanding why neither extreme works:
| If the tolerance were | What would happen |
|---|---|
| Zero | Constant micro-seeks. Every seek makes a player re-buffer slightly, so a party that chases perfection stutters permanently. |
| Half a second | Imperceptible in practice — nobody notices half a second of offset in a film — and corrections stay rare. |
| Five seconds | You would visibly be watching different scenes, and a jump home would be jarring. |
Half a second is also comfortably above normal network jitter, which means ordinary variation does not trigger a correction at all. The party is mostly idle, which is the property you want.
The interesting part: refusing to apply a position
Here is where the naive implementation breaks. A player that has just navigated will happily tell you it has a duration and some metadata, and will then quietly discard the position you write — or, on Prime Video, fail with an error and stop.
So before any correction, the question is whether the player will actually honour one. The floor is metadata plus a real duration. Some players need more than that: the Prime adapter additionally requires real buffered data, refuses during an ad break entirely, and spaces consecutive jumps about a second apart, because Prime tolerates one seek and errors on a rapid run of them.
When a correction is refused, it is not lost. The caller checks whether the position actually landed, and asks again shortly after if it did not. That retry ladder is why a join sometimes resolves a second late instead of failing.
A position outside what a player can reach is never a correction — assigning it either does nothing or drops the player into an error state. So every target is pinned to the seekable window first.
Why there is no host
Many tools nominate a host whose player is the truth, and everyone else follows. It is simpler to build and worse to use: the host cannot go and make tea, and handing over control becomes a feature you have to design.
Here, either side can drive. Whoever acts most recently is the truth, which means the rule is temporal rather than positional. That has one consequence worth knowing: Sync now is deliberately one-directional. It means put me where they are, never drag them to me. If it were symmetric, two people pressing it would fight.
What happens when the video changes
A video change is the case that breaks most implementations, because a position from the old video is meaningless in the new one — and applying it is what makes a joining viewer jump to the wrong place in the wrong thing.
Handled properly it is three ordered steps: the tab reports the new video, the other tab navigates to it without tearing down the room, and both sides discard the previous video's positions before re-syncing. Plus one guard that matters: a change is never followed twice, and a video the tab has just followed is not followed again — otherwise two tabs politely following each other navigate in a loop.
Ads, buffering, and the limits
Two things are genuinely outside the party's control, and pretending otherwise is how tools get a reputation for being flaky:
- Ads are inserted per viewer. During a break the two of you are honestly at different points. The adapters read each player's own ad state where it exposes one, so an ad is not mistaken for a jump, and the party re-converges when the break ends.
- Buffering is local. If a player cannot reach a position because it has not downloaded that part yet, no protocol fixes that. Lowering quality on the stalling side does.
And the hard limit: live streams cannot be synchronised. There is no shared position to converge on, because each viewer's edge server hands them a different point in the stream.
Common questions
How far apart can the two players get before it corrects?
About 0.55 seconds. Below that it leaves both players alone, because correcting constantly makes players re-buffer and stutter.
Who is in charge in a party?
Nobody. Whoever acted most recently is the truth, so either person can pause, play or scrub.
Why does a correction sometimes take a second?
Because a player that is not ready to accept a position is asked again rather than forced. Forcing it is what produces errors on some services.
Does the party send my video anywhere?
No. It sends a position and a play state. The video is streamed by each side from the service, as normal.
Why can live streams not be synced?
A live stream has no shared timeline — each viewer is handed a different point in the stream, so there is no position to agree on.
One link. Same second. No screen sharing.
Watch Peak Party keeps YouTube, Netflix, Prime Video, Crunchyroll, Disney+, Hulu, HBO Max and JioHotstar in sync — with chat, voice and video built in.
Add to Chrome
