description: HEVC and P2P save bandwidth, local transcoding on the publisher removes the cloud transcoding fee, and P2P plus the right ingest protocol cut latency: how much each of the three savings is, and under what conditions it holds.¶

EP20: PPCDN brings you 30%–50% savings in bandwidth & cost & latency!¶

Recap	EP19 "Load-testing methodology: from a single box to global load"
Next	Series finale (end of Module 5)

0. Goals of this episode¶

By the end, the viewer should be able to do four things:

Say where each of the three savings comes from: bandwidth is saved by "HEVC's lower bitrate + P2P bypassing Edge", cost by "getting ABR without transcoding on the network side", and latency by "P2P direct connection + choosing the right ingest protocol".
Compute their own numbers: every saving comes with a formula — plug in your own bill share, device share and room size instead of copying this episode's numbers.
See when it does not hold: HEVC viewers do not use P2P, P2P is capped at 3 connections per publisher, and uplink bandwidth is the publisher's own resource.
Tell three kinds of numbers apart: measured, modeled and unverified. Every number in this episode is labeled with which kind it is.

1. Three savings on one page¶

	What is saved	Magnitude	Basis
Bandwidth	Edge → viewer downlink bandwidth	HEVC compresses about 30%~50% better than H264; with 1v1 and small-scale concurrency, P2P can bring Edge downlink close to 100% zero	HEVC coding efficiency + P2P direct connection bypassing Edge
Cost	Cloud transcoding fees	This is the largest item: in scenarios that use ABR, transcoding traffic can account for 50%	ppobs simulcast + local-compute transcoding + free uplink ingest; PPCDN's transcoding fee is 0
Latency	End-to-end latency (including playback buffer)	P2P ≤ 110ms, about 42% lower than WHIP (190ms); WHIP is about 47% lower than SRT (360ms)	Measured in this project

The three savings are not all fully collected by the same viewer: HEVC viewers save bitrate; H264 viewers have a chance at P2P to save downlink and latency; the transcoding fee is the one saving shared by all viewers.

2. Bandwidth savings¶

2.1 HEVC: compresses about 30%~50% better than H264¶

At the same picture quality, HEVC needs a lower bitrate than H264, and the range commonly quoted in the industry is 30%~50%. This path saves each viewer's downlink bitrate, so the more viewers, the more it saves. Terminals that support HEVC decoding are becoming more common, and the share of viewers who can use HEVC keeps rising.

This episode doesn't just quote the industry claim — we also measured it ourselves. Method: take the same reference source, encode it along each of the H264 and HEVC bitrate ladders, score each against the reference with offline VMAF, and compare the bitrate at the same VMAF (the method from EP10). Encoder settings are aligned to ppobs's real-time scenario: CBR, no B-frames, keyframe interval 60, low latency.

Encoder	Content	HEVC saving vs H264 at same VMAF
Software x264/x265 (medium, zerolatency)	1080P material	44.4%
Software x264/x265	Portrait 1080×1920	34.2%
Software total (8 comparison points)		mean 39.3%, range 13.9%~50.4%
NVENC (RTX 4060, p4 low latency)	1080P material	24.0%
NVENC	4K scaled to 1080P	15.8%
NVENC	Portrait 1080×1920	2.0%
NVENC total (11 comparison points)		mean 15.0%, range −4.8%~29.5%

Things to note when reading this table:

Software encoding (including slower presets) lands in the 30%~50% range, consistent with the industry claim;
The gain of a GPU hardware real-time profile (NVENC) is clearly smaller, with a mean of about 15%. ppobs commonly uses NVENC, so "30%~50%" should be read as the upper range under certain encoder conditions, not an unconditional promise;
It varies with content: portrait material has almost no gain under NVENC;
Small sample: 3 clips of 10 seconds each, 1 GPU — not a promise for your content; redo it with your own content before going live.

2.2 P2P: what it saves is downlink bandwidth¶

When a P2P direct connection succeeds, the publisher's picture goes straight to the viewer, and this stream's Edge downlink (egress) bandwidth is 0 (EP13). There are two limits:

Only H264 viewers can use P2P: HEVC viewers go directly to Edge and do not take part in P2P;
Each publisher defaults to at most 3 direct connections (maxP2PSessions).

So P2P's benefit depends on room size: in 1v1 and small-scale concurrent businesses, every viewer has a chance at a direct connection, and the share saved can be very high; in large rooms, the 3-connection cap leaves only a small fraction that can be diverted.

2.3 Putting them together¶

Let h = share of HEVC viewers, f = HEVC's bitrate saving rate, q = the fraction of H264 viewers that get a P2P hit:

Edge downlink saving = f × h + (1 − h) × q
q ≤ min(1, 3 ÷ number of H264 viewers)

Model examples (modeled, not measured):

Scenario	h	f	q	Edge downlink saving
All viewers support HEVC, software encoding	100%	39%	—	39%
All viewers support HEVC, f taken at the industry upper bound	100%	50%	—	50%
All viewers support HEVC, NVENC	100%	15%	—	15%
Large room of 100, 60% HEVC, software encoding	60%	39%	3÷40 = 7.5%	about 26%
Small room of 3, all H264, P2P hits all	0%	—	100%	100%
1v1, H264, P2P hit	0%	—	100%	100%

Large rooms: mainly rely on HEVC, and the magnitude depends on the encoder, 15%~50%;
1v1 and small-scale concurrency: after a P2P hit, downlink drops straight to zero — the scenario with the largest saving;
HEVC and P2P do not stack on the same viewer: a viewer goes either HEVC, or H264 + P2P.

3. Cost savings: ABR without transcoding on the network side¶

3.1 Why ABR needs transcoding¶

ABR (adaptive bitrate) needs multiple picture-quality renditions to choose from. In traditional cloud streaming, the publisher sends only one stream, and the multiple renditions are generated by cloud-side transcoding: the cloud decodes first, then re-encodes for each output rendition, billed separately per output rendition. In scenarios that use ABR, transcoding traffic can account for 50% of total traffic, so using a service such as Tencent Cloud Live incurs a large transcoding bill (the exact share depends on your own bill).

flowchart LR
    subgraph before["Traditional cloud streaming (ABR)"]
        T1["Transcoding fee<br/>up to 50% of traffic"]
        B1["Downlink bandwidth"]
    end
    subgraph after["PPCDN"]
        T2["Transcoding fee = 0<br/>transcoded locally on the publisher"]
        B2["Downlink bandwidth<br/>further reduced by HEVC / P2P"]
    end
    before --> after

3.2 How PPCDN does it¶

ppobs supports simulcast over three protocols: WHIP / SRT / ERTMP: the publisher uses its own local compute to encode multiple renditions in one pass, and can publish both an H264 and an HEVC track at the same time. The server only does RTP passthrough, with no decoding and no transcoding, so ABR adaptive bitrate is supported without transcoding on the network side — this is the largest cost saving in the whole scheme.

Ingest protocol	How multiple tracks are sent	Layer cap
WHIP	One WebRTC session each for H264 and HEVC	H264 ≤ 4 layers, HEVC ≤ 3 layers
SRT	One SRT connection each for H264 and HEVC (MPEG-TS multi-ES)	Same
ERTMP	One Enhanced RTMP connection each for H264 and HEVC, multi-track	Same

This accounting holds because of two things:

Transcoding on the publisher's local compute: encoding uses the publishing machine's own GPU/CPU and takes no cloud compute;
Free uplink ingest: this is common industry practice, and PPCDN also charges no uplink traffic fee, so the transcoding fee is 0.

The bandwidth/traffic savings in Section 2 above are in essence also cost savings: less downlink traffic means a smaller usage-based bill.

The cost-saving formula (replace t with the real share of transcoding-related fees in your bill):

cost saving ≈ t (transcoding fee share) + (1 − t) × bandwidth saving rate

3.3 The costs, not hidden¶

Uplink is the publisher's own resource: free doesn't mean unlimited. Dual-track simulcast takes the sum of two sets of streams on the uplink; a WHIP publishing sample on a hosted node on 2026-10-24 came to about 4.5~4.7 Mbps (H264 three layers about 3.1~3.5 Mbps, HEVC three layers about 1.2 Mbps); in EP10, a single uplink rising from 2.87 Mbps to 5.35 Mbps produced 3.6%~4.7% packet loss. Measure uplink headroom before launching simulcast.
Encoding compute is also a cost: multiple renditions + two codecs means running several more encoders.

4. Latency savings¶

All four numbers below are end-to-end latency including the playback buffer:

Path	End-to-end latency	vs WHIP
P2P direct	≤ 110ms	about 42% lower
ERTMP ingest	about 150ms	about 21% lower
WHIP ingest	190ms	baseline
SRT ingest	about 360ms	about 89% higher

P2P direct |███████████                       ≤110
ERTMP      |███████████████                    150
WHIP       |███████████████████                190
SRT        |████████████████████████████████████ 360

P2P is lower than Edge·WHIP by (190−110)/190 ≈ 42%, and lower than SRT by about 69%;
WHIP is lower than SRT by (360−190)/360 ≈ 47%; the gap mainly comes from the fixed receive window at the SRT ingest end, a protocol trade-off between "weak-network resilience ↔ latency", not a difference in encoding format;
ERTMP's about 150ms is the number on a clean network: it runs on TCP, and any packet loss causes head-of-line blocking (EP07), so don't count on this value on a weak network;
Not transcoding leaves the server path with only the forwarding overhead of RTP passthrough; how much latency transcoding adds in traditional solutions depends on the vendor's implementation, this project has no like-for-like measurement, and no number is given.

These numbers are including the playback buffer, and are not the same measurement as the 70ms / 108ms / 386ms baselines cited in EP01, EP02, EP12 and EP13, nor is the measurement basis entirely the same (see EP12 for the measurement conditions of that baseline set). Don't compare the two sets of numbers against each other, and when citing them, state the measurement basis.

5. Putting the three savings together¶

flowchart TD
    P["Publisher ppobs: WHIP/SRT/ERTMP simulcast<br/>local transcoding, multiple renditions × H264 + HEVC"] --> O["Origin / Edge: RTP passthrough, no transcoding"]
    O --> V1["HEVC viewer: direct to Edge<br/>lower bitrate"]
    O --> V2["H264 viewer: try P2P first"]
    V2 -->|"hit"| V3["P2P direct<br/>Edge downlink = 0, latency ≤ 110ms"]
    V2 -->|"miss / slots full"| V4["Fall back to Edge·H264"]
    P -. "shared by all viewers" .-> C["Transcoding fee = 0, uplink not billed"]

Viewer type	Bandwidth	Latency	Cost
HEVC viewer	Lower bitrate	Depends on ingest protocol (WHIP 190ms, etc.)	Transcoding fee zeroed
H264 viewer, P2P hit	Edge downlink 0	≤ 110ms	Transcoding fee zeroed
H264 viewer, fall back to Edge	Baseline	Depends on ingest protocol	Transcoding fee zeroed

6. Boundaries and costs, not hidden¶

"HEVC saves 30%~50%" depends on the encoder: software / slow-profile encoding lands in this range, while the NVENC real-time profile measured a mean of about 15%; change the content or the preset, and the result changes.
Transcoding at 50% is a scenario assumption: it holds only for businesses that use ABR and transcode in the cloud — verify it against your own bill; if your bill has no transcoding fee to begin with, this item is 0.
Uplink is the publisher's own resource: dual-track simulcast takes about 4.5~4.7 Mbps, so measure uplink headroom first.
P2P hit rate and byte-split share lack production data: in large rooms, bound by the 3-connection cap, the benefit is limited; 1v1 and small rooms are the main scenario.
ERTMP runs on TCP: about 150ms is the value on a clean network, and on a weak network it will be dragged down by head-of-line blocking.
The latency numbers have a measurement basis: including playback buffer; limited sample size, not an SLA; they will differ across measurement dates and networks.
Billing caliber: PPCDN's billing design is no transcoding fee and no uplink fee, charged by downlink traffic and recording storage; but production currently actually runs a flat daily fee, and there is no confirmed deployment record of whether the usage-based billing switch has been turned on, so what can be confirmed as "savings" today is on the cost side; the customer-bill side has to wait until the billing scheme actually takes effect.
No comparison with other vendors: as EP12 explained, there is no like-for-like raw data from other vendors, so this episode draws no better-or-worse conclusion about any vendor; the cloud-vendor transcoding billing mentioned is used only to illustrate the fee structure.

7. Three kinds of numbers — don't treat the latter two as the first¶

① Measured¶

Latency: P2P ≤ 110ms, ERTMP about 150ms, WHIP 190ms, SRT about 360ms (including playback buffer).
HEVC same-VMAF bitrate saving: software encoding mean 39.3%, NVENC mean 15.0% (this episode, small sample).
Dual-track simulcast uplink about 4.5~4.7 Mbps (a single WHIP publishing sample on 2026-10-24).

② Modeled¶

Transcoding traffic at 50% when using ABR (a scenario assumption, to be replaced with your bill).
h and q in the bandwidth formula f × h + (1 − h) × q (the values are examples).
The composition of the three savings' magnitudes (Section 1).

③ Not yet verified¶

P2P's production hit rate and byte-split share.
HEVC saving rate on your own content set.
The real change on the customer bill once usage-based billing takes effect.

8. How to compute your own numbers¶

Cost: open the cloud vendor bill, find the share of the total taken by transcoding-related items, and plug it into the formula in Section 3.2.
Bandwidth (HEVC): with your representative content, do an H264/HEVC same-VMAF bitrate comparison using the EP10 method, switching to the encoder and preset you actually use.
Bandwidth (P2P): gather your room-size distribution and H264 viewer share, and estimate the upper bound with q ≤ 3 ÷ number of H264 viewers; after launch, replace it with the production P2P byte share.
Latency: use EP08's SEI timestamps to measure P50/P95 in your own network; don't look only at the average (EP09), and state whether the playback buffer is included.
Uplink: measure the publisher's uplink headroom to decide how many layers and how many codecs to publish.

9. Series finale¶

That's the whole course. We started from episode one's "interactive-video dilemma" and went through protocol choices, weak networks, observability, quality, P2P, node pools, scaling, bursts, deployment, recording and load testing, and finally came back to the money.

If one sentence sums up how PPCDN saves: use ppobs to transcode locally on the publisher and simulcast over three protocols, get ABR without transcoding on the network side and drive the cloud transcoding fee to 0; then use HEVC to lower the downlink bitrate, and use P2P to bypass Edge and bring end-to-end latency under 110ms. All three savings land in the neighborhood of 30%~50%, but each has conditions under which it holds — don't treat one number as a universal promise.

The system's code is open source — go deploy it, load-test it, and fill in the "not yet verified". That is the real sequel to this course.