How peer-assisted live delivery works
Live viewers often request the same channel segments within a short time window. If another authorized viewer has a compatible segment and the network permits a connection, the SDK can obtain that segment from the peer instead of downloading it again from your CDN.
- Create a playback session using your SDK key and live media URL.
- Use a stable channel content ID when signed URLs vary between viewers. Only group compatible content within the intended authorization boundary.
- The SDK coordinates peer discovery and segment requests; your player continues to handle playback.
- When a peer is unavailable, too slow, or disallowed by policy, the SDK uses the CDN path.
For session and delivery details, read how P2P delivery works.
When P2P CDN is worth evaluating
Start with channels where multiple viewers watch the same content at similar playback positions. An event or scheduled broadcast is a candidate for testing, rather than proof that a particular offload rate is achievable.
| Condition | What to check |
|---|---|
| Same-content concurrency | Do viewers request overlapping segments, or are they spread across different channels and renditions? |
| Network reachability | Can real viewer devices establish peer connections under their NAT, firewall, and upload constraints? |
| Live latency budget | Is there enough time to obtain a segment without increasing stalls? Validate the actual player and segment settings. |
| Browser and platform support | Check the SDK path on each target device, including Safari and Service Worker requirements. |
Single-viewer channels, non-overlapping playback, restricted networks, or very tight latency budgets can limit sharing. Keep CDN capacity for cold starts and periods with little usable peer supply. P2P does not create spare CDN capacity or guarantee zero rebuffering.
Integrate with your existing player and CDN
The player remains responsible for manifest parsing, adaptive bitrate selection, DRM, decoding, and rendering. MeshStream handles the session and accelerated delivery path; it does not replace your origin authorization or your CDN contract.
- Web SDK: HLS/DASH integration and browser capability guidance.
- Android SDK: use the playback session URL with your player and release the session when playback ends.
- iOS/macOS SDK: AVPlayer/HLS integration and native lifecycle handling.
- Windows SDK: native session and fallback integration.
Protocol and browser support vary by SDK. Start with the relevant platform guide and the quickstart, rather than assuming every playback path supports the same acceleration mode.
Validate playback, fallback, and CDN offload
- Establish CDN-only playback on the target devices and record startup time, stalls, errors, and delivered bytes.
- Enable P2P for a limited cohort of real devices watching the same channel. Record warm-up separately from stable concurrency.
- Measure peer download and CDN download bytes for the same time window, platform, and stream.
- Disable P2P while keeping CDN connectivity available. Verify continued playback, then close sessions and check resource release.
- Compare similar cohorts and playback quality before expanding. Do not combine live and VOD results into a single success figure.
Use the video CDN cost and offload guide to distinguish peer-delivered bytes from actual bill savings.
Common questions
Does P2P CDN replace the CDN?
No. Your CDN supplies segments when peers cannot help. If the CDN or origin is also unavailable, P2P alone cannot guarantee playback continuity.
Does WebRTC mean this is a real-time video calling system?
No. A WebRTC peer connection can carry media segments without replacing your HLS/DASH player or turning the stream into a conferencing system. Test your actual latency requirements.
What offload percentage should I expect?
There is no fixed percentage. Concurrency, segment overlap, reachability, device capabilities, and playback policy all affect the result. Measure a representative workload before budgeting savings.