What is peer-to-peer video streaming?

Most video you watch on the internet comes from a server: you click play, the server sends the bytes, everyone watching that video pulls from the same central copy. Peer-to-peer video streaming does the opposite — the devices involved send the media directly to each other, and no server stores or forwards the file. This post explains how it works and when it's the right tool.

Client-server vs. peer-to-peer, in one picture

In a client-server setup there are two kinds of machines: one (or a few) servers with the content, and many clients that request it. Every stream is a download from that server. The server necessarily holds a copy of everything it serves.

In a peer-to-peer (P2P) setup, the machines are symmetric peers. The device that has the file sends it directly to the device that wants it. The connection is between the two devices; a third party isn't required to carry the data.

How modern P2P video actually works

Real-world P2P video streaming leans on WebRTC, the browser standard for real-time communication:

1. Signaling. The peers need to find each other first. A small relay exchanges connection details — a few kilobytes — then gets out of the way. This is the only server a P2P design needs, and it never carries media.
2. NAT traversal. Devices behind home routers aren't directly reachable by default. STUN lets a peer discover its public address; TURN relays packets as a last resort when direct connection is blocked.
3. Encrypted transport. The media travels in a WebRTC connection encrypted end to end (DTLS-SRTP). Even a TURN relay in the middle forwards only encrypted bytes it can't read.
4. Direct delivery. The sender streams the file — often starting playback before the whole file has crossed the link — and the receiver plays it locally.

Why "no server" is the point

Removing the server removes everything that comes with it:

• No upload. The sender doesn't push a copy into someone else's storage first.
• No server-side copy. There's no file on a datacenter disk, so there's no retention policy, no cache, nothing to delete later.
• No account dependency. A P2P session can work with nothing more than a pairing code — no profile, no quota, no terms-of-service risk to your files.

When P2P is the right choice

P2P shines when the sender and receiver are both devices you control and the job is "get this file from here to there right now": casting a video from your phone to your TV, sharing a screen recording with a colleague, or playing a local movie on a bigger display. The source device holds the file; the destination is reachable; the only missing ingredient was connection setup.

It's less suited to things P2P was never designed for: serving a million simultaneous viewers (that's what CDNs do) or making your library available when the source device is offline. If the source device isn't running, there's nothing to stream from.

P2P in practice: Chusko

Chusko is a browser-based P2P casting tool built on exactly this model. A Projector streams local media files directly to a Screen over WebRTC; the only server is a signaling relay that handles the handshake and nothing else. The screen stores the received bytes on-device and plays them with its native demuxer, so any format the browser supports works — no remuxing, no fragmentation requirement, no size ceiling. Playback controls (play, pause, seek, volume) live on the projector and are executed on the screen.

Want the full mechanics? See how Chusko casts video peer-to-peer, or start with the FAQ.