P2P Direct-Connect Live Streaming
Viewers that do not support HEVC first try to connect straight to the publisher over WebRTC NAT traversal for H.264, and a successful direct connection consumes zero edge egress. If traversal fails or the 3 P2P slots are exhausted, playback falls back to Edge with no error. HEVC-capable viewers stream from Edge directly.
How it works
Playback routing is codec-aware. HEVC-capable viewers are served the Edge HEVC stream directly. All other viewers request an H.264 P2P direct-connect first; the publisher grants it when a slot is free, otherwise the request is edge-only.
- HEVC-capable viewers stream from Edge (no P2P attempt)
- H.264 viewers try P2P first; each publisher allows up to 3 concurrent direct connections
- If P2P cannot connect or all slots are taken, playback falls back to Edge H.264
Lower egress cost
Every successful direct connection removes one edge egress stream. The higher the P2P hit rate, the lower your downstream bill — without sacrificing quality.
Failure is invisible
If NAT traversal fails (symmetric NAT, CGNAT) or the P2P slots are exhausted, playback falls back to the Edge H.264 path — never an error or black screen.
FAQ
Does enabling P2P hurt the streamer's quality?
No. P2P uses an independent send queue and bandwidth budget and is dropped first on detected uplink congestion, so the main publish path is always prioritized.
Is P2P required to use PPCDN?
No. P2P is an enhancement layered on a complete Edge CDN; streams that cannot go P2P behave exactly like a traditional CDN.
What latency should I expect?
P2P direct connections are the lowest-latency path, with end-to-end latency as low as 60ms on good networks; the console tracks P2P delay (P80 ≤ 300ms, P99 ≤ 2s) and other video metrics.
Sign up and get $10 in trial credit
Create an app to get your appId, then start publishing with ppobs.