TRTC vs LiveKit: Web Video Call Quality Under Weak Networks

A video call can look equally smooth across two SDKs on a healthy network but behave very differently when packets disappear or available bandwidth drops. For developers building browser-based video calling, the question is not simply whether a WebRTC connection works. It is how many frames users actually see, at what resolution, and how quickly the video recovers once connectivity improves.

Tencent RTC (TRTC) and LiveKit were tested on the same Windows PC, using Chrome, matching target video settings, and the same 30 fps source material. Both sender-to-receiver paths passed through their respective cloud SFUs. The analysis used the browser's requestVideoFrameCallback (RVFC) presentedFrames counter to measure frames displayed at the receiver, rather than trusting a sender's configured frame-rate target.

Across four impaired-network scenarios, TRTC averaged 15.7 rendered fps versus 3.5 fps for LiveKit. Its combined frame-rate-and-resolution metric was 4.57 versus 0.71 million pixels per second, or approximately 6.4× higher. The full results, however, are more nuanced: LiveKit led the standalone 500 Kbps bandwidth-limit test, and both implementations degraded substantially under severe bandwidth pressure.

Key findings from the web SDK benchmark

MP/s denotes million rendered pixels per second, calculated from frame rate and observed frame resolution. It is a quantitative proxy for delivered video information—not a perceptual quality score such as VMAF.

Figure 1. Delivered-video-information proxy for each impairment, in million pixels per second. It captures the trade-off between displayed frame rate and observed resolution; higher is better for this metric.

How the TRTC vs LiveKit web test was conducted

The comparison was designed to keep the browser, test device, media source, target resolution, and impairment procedures consistent. A few important implementation details differed and should be considered when interpreting the results.

The codec difference matters: H.264 and VP8 are not the same encoding configuration. The benchmark therefore compares these particular deployed SDK setups, not two identical video codecs or a codec-neutral implementation of each SDK.

Test constraints

This report presents TRTC performance with the “Ensuring video smoothness” preference, i.e. the setting that prioritizes video smoothness over image clarity. This is an account-level setting that is disabled by default; to reproduce the test, contact TRTC Technical Support​ to have this setting provisioned for your account.

The five test scenarios

The reference run, S0, used a normal network for 60 seconds. Four impaired runs followed:

• S1 — 25% uplink packet loss: 30 seconds.
• S2 — 25% downlink packet loss: 30 seconds.
• S3 — 500 Kbps bandwidth cap: 30 seconds of uplink impairment, followed by another 30 seconds when downlink impairment was added.
• S4 — 500 Kbps cap plus 25% packet loss: the same two-stage procedure, combining restricted bandwidth and packet loss.

The impaired-period statistics cover the recorded and observed impairment intervals, rather than relying on a single assumed start time for both endpoints. For uplink impairment, the onset was identified using sustained receiver-frame-rate degradation relative to baseline; for downlink impairment, the test used the receiver-side wizard event markers. The complete interval was then used for the reported comparison.

1. Packet loss: TRTC maintained near-baseline displayed frame rates

Under normal network conditions, both SDKs achieved a 28.9 fps baseline. When 25% packet loss was introduced, their behavior diverged sharply.

Across these two packet-loss scenarios, TRTC averaged 27.7 fps, around 4% below its 28.9 fps baseline, whereas LiveKit averaged 1.9 fps (rounded), about 93% below baseline. TRTC also stayed at the configured 640 × 480 resolution throughout the recorded impairment samples.

LiveKit's behavior reveals an important distinction between video dimensions and playback smoothness. During downlink packet loss, it continued reporting 640 × 480 for 100% of the sampled period, but rendered only 2.0 fps on average. A resolution counter alone would not capture that loss of motion.

Figure 2. Uplink 25% packet loss. The blue line represents TRTC, purple represents LiveKit, and the shaded regions distinguish impairment and recovery.

Figure 3. Downlink 25% packet loss. LiveKit's displayed frame rate falls toward zero during the impaired phase even though the reported resolution remains at 640 × 480.

2. A 500 Kbps bandwidth cap: LiveKit delivered more rendered pixels in this scenario

Bandwidth limits created a different trade-off. In S3, the sender's target bitrate was 1,000 Kbps, but available bandwidth was limited to 500 Kbps according to the staged impairment procedure.

Both SDKs reduced frame rate and resolution substantially. TRTC averaged 4.7 fps, while LiveKit achieved 7.6 fps. The combined delivered-video-information metric favored LiveKit at 1.36 MP/s versus TRTC's 0.73 MP/s. This was the one scenario in which LiveKit clearly led on the report's composite quality measure.

The two approaches also differed in how far resolution dropped. During S3, TRTC spent approximately 87% of the impaired interval at 480 × 360, and 7% at 320 × 240. LiveKit spent approximately 53% at 480 × 360 and 33% at 320 × 240, while retaining 640 × 480 in 14% of samples versus TRTC's 6%.

That means the stronger composite result for LiveKit did not necessarily imply more consistent image dimensions. Its higher received frame rate outweighed its more frequent low-resolution periods under the report's metric.

Figure 4. Browser video frame rates during the staged 500 Kbps bandwidth-limit test, including the baseline and recovery periods.

3. Bandwidth limits plus packet loss: similar composite scores, different resolution behavior

In S4, the test combined the 500 Kbps cap with 25% packet loss. Both streams were severely affected:

• TRTC: 2.5 fps, 0.49 MP/s, with roughly 96% of impaired-period samples at 480 × 360.
• LiveKit: 2.7 fps, 0.51 MP/s, with roughly 54% of samples at 320 × 240.

The delivered-video-information scores were effectively similar at the precision reported. The resolution distribution was less similar: TRTC concentrated most of its output at 480 × 360, while LiveKit spent about half of the period at 320 × 240.

This is why comparisons based solely on one metric can be misleading. TRTC maintained a more consistent intermediate resolution in S4; LiveKit delivered slightly more rendered frames per second. Neither result makes either stream smooth under this particular combined impairment.

Figure 5. Share of sampled time at 640 × 480, 480 × 360, and 320 × 240. The chart preserves the original report's resolution measurements.

Figure 6. Combined 500 Kbps cap and 25% packet loss. Both implementations fall well below the 30 fps target during the impaired phase.

4. Network recovery: TRTC reached the baseline threshold in all four tests

A video stream's ability to restore quality when connectivity improves is just as important as its behavior while connectivity is poor.

The report defined frame-rate recovery as the time after impairment removal until receiver-rendered fps returned to at least 90% of that scenario's baseline for three consecutive seconds. Each recovery observation window lasted 30 seconds.

TRTC met the threshold in all four cases, with a mean time of approximately 1.0 second. LiveKit met the threshold within the observation window only in S2, where its measured 1.0-second recovery was faster than TRTC's 2.6 seconds.

Figure 7. Recovery time after network impairment ends. “Not recovered” means that the sustained 90%-of-baseline threshold was not observed during the 30-second window; the bars are capped at the observation boundary, not estimates of eventual recovery.

Why LiveKit's recovery needs context

In this test environment, LiveKit's sender-side rate control continued to report qualityLimitationReason=bandwidth after impairment removal. A supplementary observation after 25% uplink packet loss ran for another 90 seconds (a 30-second recovery period plus 60 seconds at baseline conditions). Its frame rate climbed from approximately 2 fps to 15 fps, then leveled off without returning to the 30 fps target during that interval.

For consistency between scenarios, the LiveKit test run republished the video stream between scenarios using the wizard's wizard:republish_* procedure. That reset was separate from—and not counted as—natural network recovery. The recovery figures above refer exclusively to the period after impairment was removed without that intervention.

These results describe the recorded SDK versions, encoding settings, and access region. Recovery behavior could differ with another route, different codec settings, or an updated SDK.

5. Full web test results

The table below reproduces the reported impairment-period values. Composite score is the time-weighted rendered-frame-rate-by-resolution proxy, expressed in millions of pixels per second; retention means the percentage of samples still at 640 × 480.

Figure 8. Receiver-side rendered fps for each weak-network scenario, using the same RVFC counting method for both SDKs.

6. What developers should take away from this benchmark

Packet-loss resilience and constrained-bandwidth behavior are different engineering problems. In this test, TRTC was notably stronger under 25% packet loss, but LiveKit delivered the higher composite result under a standalone 500 Kbps cap. A team prioritizing one type of degraded network over another should evaluate those conditions separately.

Measure delivered frames alongside resolution. A 640 × 480 signal does not necessarily mean smooth playback, as shown by LiveKit's 2.0 fps during downlink packet loss. Conversely, a higher frame rate can coexist with more time spent at a lower resolution. Together, frame rate and resolution help explain adaptation behavior, but they cannot replace perceptual-quality testing.

Include recovery tests—and distinguish recovery from reconnection or republishing. An SDK may behave well during impairment and still recover slowly after it ends. This study's 30-second observations captured a large difference between the tested implementations, but the measurement is specific to those settings and does not establish an absolute recovery guarantee.

Bottom line

In the October 19, 2026 Chrome-based comparison, Tencent RTC (TRTC) delivered substantially better results under 25% packet loss, achieved a higher average rendered frame rate and composite video-information score across the four network impairments, and reached the defined recovery threshold in all four cases. LiveKit performed better under the standalone 500 Kbps cap, and its natural recovery was faster in the downlink packet-loss scenario.

For developers evaluating a WebRTC video call SDK, this benchmark makes a case for testing TRTC when packet-loss resilience and recovery are high priorities. It also shows why a production decision should be based on the specific failure modes, codec choices, capture and rendering setup, and performance metrics that matter to your users—not a single headline number.

Appendix: Normal-network baseline trace

Both SDKs averaged 28.9 rendered fps with no network impairment, providing a comparable starting point for the weak-network comparisons.

Figure 9. Receiver-rendered frame rate during the 60-second normal-network baseline. Blue: Tencent RTC (TRTC); purple: LiveKit.