TRTC vs LiveKit: Mobile Video Call Quality Comparison

A video call can look perfect on a fast connection and still fall apart when someone switches to mobile data, enters an elevator, or moves through a crowded network. For developers choosing a real-time video SDK, performance under imperfect conditions can matter just as much as performance on a clean connection.

To see how two popular approaches compare, this test evaluated Tencent RTC (TRTC) and Livekit in a one-to-one video call between iPhones. Both were tested with the same sender and receiver models, video settings, and types of simulated network impairment. Rather than relying on SDK-reported frame-rate counters, the evaluation measured frames actually presented on the receiving device.

The results were substantial within this test setup: TRTC averaged 27.5 displayed frames per second across eight impaired-network scenarios, compared with 9.1 fps for LiveKit. TRTC also retained the configured 640 × 480 resolution in every valid sample during the impairment windows. That is a useful result—but understanding what was measured, and what it does not prove, is essential.

Key findings at a glance

The average frame-rate difference amounts to approximately 202% higher fps for TRTC in the eight impaired-network scenarios. These are results from one defined comparison, not a claim about every device, network, or application.

How we tested TRTC and LiveKit

The test used an iPhone 12 Pro as the sender and an iPhone 14 as the receiver. Each SDK was configured for 640 × 480 video at 30 fps, with a target bitrate of 800 Kbps. The tested versions were TRTC 13.5.0.21355 and LiveKit 2.17.0.

A hardware network impairment device introduced controlled conditions, including 25% packet loss, a 500 Kbps bandwidth cap, 600 ms jitter, and combinations of packet loss and bandwidth restrictions. The LiveKit impairment scenarios were confirmed by the test operator.

For each of the eight impaired-network runs, the timeline was:

• 0–60 seconds: normal network, used to establish the baseline.
• 60–90 seconds: network impairment applied.
• From 90 seconds onward: impairment removed, with recovery observed for approximately 30 seconds.

A separate 90-second normal-network run established a reference. To reduce the effect of transitions, the main impaired-period comparison used seconds 65–84, excluding the first and last five recorded points from the impairment phase. Scenario averages were weighted equally. The frame-rate traces shown below use a centered five-point moving average for readability; smoothing does not change the reported summary values.

Importantly, resolution retention refers to the percentage of valid samples reporting the configured 640 × 480 output size. It is not an objective visual-quality score: a frozen frame can still retain its last recorded dimensions.

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.

1. Frame rate: TRTC remained smoother under all eight impairments

Frame rate is a straightforward way to assess the smoothness of a received call. In the eight weak-network tests, TRTC led in displayed fps in every scenario, although the size of the gap varied depending on the impairment.

Figure 1. Receiver-displayed frame rate during the steady impairment window (65–84 s). Higher is smoother. Values are rounded to one decimal place.

Packet loss: 25% of packets dropped

With 25% uplink packet loss, the receiving iPhone displayed 29.3 fps with TRTC versus 9.4 fps with LiveKit. Under 25% downlink packet loss, the observed rates were 30.1 fps and 8.4 fps, respectively.

These results matter because packet loss can occur on either side of the call. In this specific setup, TRTC maintained close-to-baseline displayed frame rates in both directions, while LiveKit's receiving-side smoothness declined noticeably.

Figure 2. Uplink 25% packet loss. White indicates the baseline; peach indicates impairment; pale green indicates the recovery phase. Blue is TRTC and orange is LiveKit.

Bandwidth caps: a 500 Kbps ceiling

The configured target video bitrate was 800 Kbps, but the impairment device limited the affected direction to 500 Kbps. Under the uplink cap, TRTC measured 31.4 fps, while LiveKit measured 13.3 fps. Under the downlink cap, the values were 23.6 fps and 9.3 fps.

TRTC's downlink result was lower than its other single-impairment results. Even so, its displayed frame rate remained above LiveKit's in this run. The trace below makes the contrast visible over time.

Figure 3. Downlink bandwidth capped at 500 Kbps between 60 and 90 seconds. The lines use a centered five-point moving average.

When bandwidth restrictions and packet loss happen together

The combined tests paired a 500 Kbps cap with 25% packet loss. With both impairments on the uplink, TRTC delivered 21.4 fps and LiveKit 9.8 fps. With both on the downlink, TRTC delivered 25.1 fps and LiveKit 11.2 fps.

Combined impairments are especially useful for testing whether a video connection remains usable when network conditions deteriorate in more than one way. These particular results favor TRTC on displayed frame rate, but they do not by themselves quantify end-to-end latency, frozen-frame duration, or human-perceived video quality.

Figure 4. A 500 Kbps downlink cap combined with 25% downlink packet loss.

Jitter: 600 ms of delay variation

Jitter can make packets arrive at uneven intervals, creating challenges for real-time playback. With 600 ms uplink jitter, TRTC maintained 29.3 fps, compared with 4.7 fps for LiveKit. The 600 ms downlink jitter run yielded 29.4 fps for TRTC and 6.6 fps for LiveKit.

Within the measured impairment window, these were among the largest frame-rate separations in the test. In both jitter scenarios, TRTC's measured frame rate remained close to the normal-network reference.

Figure 5. Uplink 600 ms jitter. The blue line stays near baseline after an initial fluctuation; the orange line remains much lower during the impairment.

2. Resolution retention: does the call stay at 640 × 480?

Smooth motion is only part of the picture. When conditions worsen, a video SDK may reduce the output resolution to keep the call running. In this test, TRTC recorded 640 × 480 in 100% of valid impairment-period resolution samples across all eight weak-network scenarios.

LiveKit showed a more variable pattern: it retained 640 × 480 in 85% of samples under a 500 Kbps downlink cap, but in 0% under the combined 500 Kbps downlink cap and 25% downlink packet loss. Across the eight impaired scenarios, its equally weighted average retention was 36.9%.

Figure 6. Percentage of valid impairment-period samples reported at the configured 640 × 480 resolution. Higher indicates better resolution retention, but not necessarily better perceptual quality or fewer freezes.

The distinction matters. Frame-rate data tells us how many frames reached the display. Resolution retention tells us what size was reported. Neither metric alone is a substitute for assessing perceptual sharpness, stalling, latency, or audio-video synchronization. Used together, however, they provide a more informative picture of how each implementation behaved.

3. Network recovery: what happens after conditions improve?

Real networks rarely stay bad forever. As a device reconnects to a stronger signal, a useful question is how quickly its video stream returns to baseline.

The recovery test began at 90 seconds, when the impairment was removed. A frame-rate recovery was counted when the receiver reached at least 90% of that scenario's baseline fps for three consecutive 1 Hz samples. A reported 0 s means the first qualifying three-sample sequence started at the recovery boundary; it does not mean an instantaneous recovery was observed.

Under this rule, TRTC registered 0 s in all eight scenarios. LiveKit reached the criterion in 2 s after downlink 25% packet loss and 15 s after the 500 Kbps uplink cap; it did not sustain the threshold in the other six scenarios within the observed 30-second recovery window.

Figure 7. Steady recovery-period averages across the eight impairment scenarios, computed separately from the time-to-recovery threshold.

These recovery measurements suggest that TRTC better preserved both motion and configured resolution after network conditions returned to normal in this particular test. They should not be interpreted as guaranteeing identical restoration times in production deployments.

4. CPU and memory: a more balanced trade-off

Video quality is not the only engineering consideration on mobile. Apps also need to control processing overhead and memory consumption.

Across the normal-network baseline plus eight impaired scenarios, TRTC averaged 15.1% CPU usage, compared with 16.1% for LiveKit. That is a 1.0-percentage-point advantage for TRTC under the recorded measurement method. However, LiveKit used less memory on average: 56 MB versus TRTC's 62 MB.

Figure 8. Resource averages across all nine scenarios. CPU uses a single-core 100% reference (a six-core device can total 600%). Memory is process phys_footprint; reported values include demo and receiver-side processing costs.

The resource figures include receiver-side decoding, rendering, and demo overhead, not video encoding. The memory metric is the process's phys_footprint and does not subtract I420 conversion-buffer accounting. The reported averages therefore help compare these measured implementations, but should not be read as the exact additional CPU or RAM that either SDK would require in a different app.

5. Full weak-network results

For readers who want the complete numerical comparison, the table below reproduces the eight impaired-network scenario results. The resolution column is the share of valid impairment-period samples at 640 × 480.

6. What these benchmarks mean for your video app

The comparison suggests three practical lessons for teams evaluating mobile video calling SDKs.

Test the network failures your users actually encounter. A clean-network demo is a starting point, not a resilience test. Packet loss, insufficient throughput, and jitter should be simulated separately and together, on both uplink and downlink.

Measure on the receiver, not only inside SDK diagnostics. Receiver-displayed fps and observed resolution can tell a different story from a sender's nominal encoding configuration or internal counters. For a fuller evaluation, pair these with freeze duration, end-to-end delay, audio continuity, and subjective video quality assessments.

Look at recovery and resource costs alongside steady-state quality. Network resilience includes how the call behaves after interference ends. And a higher video-quality result does not automatically make one SDK preferable on every memory, power, or integration constraint.

Bottom line

In this iOS 1:1 video-call benchmark, Tencent RTC (TRTC) delivered 27.5 fps versus LiveKit's 9.1 fps across eight weak-network conditions, kept the configured 640 × 480 resolution in every valid impairment-period sample, and showed stronger measured recovery. TRTC also averaged slightly lower CPU use, while LiveKit had the lower average memory footprint.

For an app where smooth video calling over unreliable mobile connections is a key requirement, TRTC's results in this controlled comparison make it worth testing against your own workloads. The right production choice still depends on your app's devices, encoder settings, bandwidth profile, feature requirements, and independently verified real-world quality.