1. Summary
Both SDKs used the identical video source, matching configurations, and the same network impairment conditions — packet loss, bandwidth limitation, and jitter — applied with a professional hardware network impairment device, and receiver-displayed frame rate was compared. TRTC was tested with the video smoothness preference “Ensuring smoothness”, which prioritizes smooth motion over image clarity. This is an account-level setting; contact technical support to have it provisioned for your account before reproducing the test (see “2. Test Conditions”).
Three metrics where TRTC came out ahead in this test
- 4.8% higher average frame rate during the impairment period — averaged across the 8 weak-network scenarios, TRTC reached 25.4 fps during the impairment period vs. 24.3 fps for Agora (a difference of 1.1 fps). Scenario by scenario, TRTC led by more than 5% in 3 scenarios, while the gap stayed within 5% in the other 5
- Slightly higher frame rate on a normal network and during recovery — TRTC measured 29.6 fps on a normal network and 29.7 fps during the recovery period, vs. 28.7 fps and 28.7 fps for Agora, a gap of about 1 fps
- Shorter total freeze duration — across the 8 scenarios, TRTC was completely frozen (below 1 fps) for 7 s in total, vs. 11 s for Agora; time at a low frame rate (below 15 fps) was 30 s for both
2. Test Conditions
Both SDKs were tested under identical controlled conditions, using the same video source, encoding parameters and receiving device, and the test cases covered the same network impairments: packet loss, bandwidth limitation, and jitter.
| Sending device | iPhone 12 Pro |
|---|---|
| Receiving device | iPhone 14 |
| SDK version | TRTC SDK 13.5.0.21355 Agora SDK 4.7.0 |
| TRTC configuration | “Ensuring smoothness” video smoothness preference — smoothness prioritized over image clarity (account-level setting, provisioned by technical support) |
| Video configuration | 640×480, 30 fps, 800 Kbps target bitrate (identical for both, using the same source video file) |
| Network impairment | Professional hardware network impairment device |
| Frame-rate measurement method | Frames actually rendered on the receiving device , rather than frame-rate values reported internally by the SDK. Any single-second sample above the configured 30 fps (frame catch-up after a freeze) is counted as 30 fps |
| How the impairment period is defined | The baseline is the average over 16–50 s of that scenario; the impairment onset is the first moment between 55 s and 65 s at which the frame rate drops below 80% of that baseline. The impairment period is the 30 s starting from that point, and everything after it is the recovery period |
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.
Test Scenarios and Timeline
| Scenario | Network Condition | Duration |
|---|---|---|
| Normal Network | Normal network conditions used as baseline | 90 s |
| Uplink 50% Packet Loss | 50% packet loss applied on the uplink | 30 s |
| Downlink 50% Packet Loss | 50% packet loss applied on the downlink | 30 s |
| Uplink 500 Kbps Cap | 500 Kbps bandwidth cap applied on the uplink | 30 s |
| Downlink 500 Kbps Cap | 500 Kbps bandwidth cap applied on the downlink | 30 s |
| Uplink 500 Kbps Cap + 25% Loss | 500 Kbps cap + 25% packet loss applied on the uplink | 30 s |
| Downlink 500 Kbps Cap + 25% Loss | 500 Kbps cap + 25% packet loss applied on the downlink | 30 s |
| Uplink 600 ms Jitter | 600 ms jitter applied on the uplink | 30 s |
| Downlink 600 ms Jitter | 600 ms jitter applied on the downlink | 30 s |
Each scenario followed the same overall sequence: establish baseline → apply network impairment → remove impairment → observe recovery. In each weak-network scenario, impairment was applied at around the 60 s mark and removed 30 s later. Because the time the impairment device actually takes effect can differ from the script timer by a few seconds, all statistics are based on the impairment onset actually detected. The first 15 s after stream start and the last 5 s before the end are excluded.
3. Frame Rate Under Weak-Network Conditions
The table below gives the average frame rate during the impairment period of each scenario (30 s from the impairment onset), together with the frame rate retention relative to the pre-impairment baseline of that scenario. Retention shows how far each SDK fell from its own baseline, and the two baselines are not identical (about 29.5–29.9 fps for TRTC and 28.6–28.9 fps for Agora), so judge smoothness by the frame rate during the impairment period and treat retention as a reference only.
| Scenario | TRTC Baseline | TRTC Impairment | TRTC Retention | Agora Baseline | Agora Impairment | Agora Retention | Result |
|---|---|---|---|---|---|---|---|
| Uplink 50% Packet Loss | 29.9 | 28.9 | 96.8% | 28.9 | 28.5 | 98.6% | Approximately equal |
| Downlink 50% Packet Loss | 29.8 | 27.1 | 91.0% | 28.6 | 24.3 | 85.1% | TRTC |
| Uplink 500 Kbps Cap | 29.9 | 27.2 | 91.0% | 28.9 | 25.5 | 88.1% | TRTC |
| Downlink 500 Kbps Cap | 29.7 | 19.2 | 64.6% | 28.8 | 19.0 | 65.9% | Approximately equal |
| Uplink 500 Kbps Cap + 25% Loss | 29.7 | 21.2 | 71.4% | 28.7 | 20.0 | 69.5% | TRTC |
| Downlink 500 Kbps Cap + 25% Loss | 29.5 | 23.4 | 79.3% | 28.7 | 22.4 | 78.0% | Approximately equal |
| Uplink 600 ms Jitter | 29.7 | 28.1 | 94.8% | 28.8 | 27.4 | 95.1% | Approximately equal |
| Downlink 600 ms Jitter | 29.9 | 28.4 | 95.1% | 28.9 | 27.3 | 94.4% | Approximately equal |
| Average | — | 25.4 | 85.5% | — | 24.3 | 84.3% |
Result criterion: a frame rate difference of more than 5% during the impairment period is recorded as a win for the SDK with the higher value; otherwise the scenario is marked “Approximately equal”. This 5% threshold is defined by this report to separate perceptible differences from test-to-test variation, and is not an industry standard.
Freeze Duration (within the impairment period; lower is better)
Freeze duration is counted from the frames actually rendered on the receiving device each second: a freeze means a rendered frame rate below 1 fps, and a low frame rate means below 15 fps (freezes included).
| Scenario | TRTC Freeze (s) | TRTC Low fps (s) | Agora Freeze (s) | Agora Low fps (s) |
|---|---|---|---|---|
| Uplink 50% Packet Loss | 0 s | 0 s | 0 s | 0 s |
| Downlink 50% Packet Loss | 0 s | 3 s | 3 s | 4 s |
| Uplink 500 Kbps Cap | 0 s | 2 s | 0 s | 5 s |
| Downlink 500 Kbps Cap | 4 s | 11 s | 4 s | 6 s |
| Uplink 500 Kbps Cap + 25% Loss | 2 s | 8 s | 3 s | 9 s |
| Downlink 500 Kbps Cap + 25% Loss | 1 s | 4 s | 1 s | 4 s |
| Uplink 600 ms Jitter | 0 s | 1 s | 0 s | 1 s |
| Downlink 600 ms Jitter | 0 s | 1 s | 0 s | 1 s |
| Total | 7 s | 30 s | 11 s | 30 s |
4. Frame Rate Curves by Scenario
Y-axis: receiver frame rate (fps). X-axis: time within scenario. Both curves are aligned to 60 s using their own detected impairment onset, so 60–90 s corresponds to the impairment period in the table above. The curves show the raw rendered frame rate (including frame catch-up, not capped), smoothed with a centered five-point moving average, with the first 15 s after stream start and the last 5 s removed.
1. Normal Network
2. Uplink 50% Packet Loss
3. Downlink 50% Packet Loss
4. Uplink 500 Kbps Cap
5. Downlink 500 Kbps Cap
6. Uplink 500 Kbps Cap + 25% Loss
7. Downlink 500 Kbps Cap + 25% Loss
8. Uplink 600 ms Jitter
9. Downlink 600 ms Jitter
5. Network Recovery
The recovery window runs from the impairment onset + 30 s to 5 s before the end of the test. 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.
| Scenario | TRTC Recovery fps | TRTC Recovery time | Agora Recovery fps | Agora Recovery time |
|---|---|---|---|---|
| Uplink 50% Packet Loss | 29.8 | 0 s | 29.2 | 0 s |
| Downlink 50% Packet Loss | 29.9 | 0 s | 29.0 | 0 s |
| Uplink 500 Kbps Cap | 29.0 | 0 s | 29.0 | 0 s |
| Downlink 500 Kbps Cap | 30.0 | 0 s | 28.4 | 0 s |
| Uplink 500 Kbps Cap + 25% Loss | 29.6 | 0 s | 27.6 | 0 s |
| Downlink 500 Kbps Cap + 25% Loss | 29.5 | 0 s | 28.1 | 0 s |
| Uplink 600 ms Jitter | 30.0 | 0 s | 29.0 | 0 s |
| Downlink 600 ms Jitter | 30.0 | 0 s | 29.1 | 0 s |
| Average | 29.7 | 28.7 |
Smoothness after recovery: TRTC averaged 29.7 fps during the recovery period, and Agora averaged 28.7 fps. In every scenario, both SDKs met the 90%-of-baseline recovery criterion at the start of the recovery window, with no visible difference in recovery speed.
6. CPU and Memory Usage
| Scenario | TRTC CPU | Agora CPU | TRTC Memory | Agora Memory |
|---|---|---|---|---|
| Normal Network | 14.1% | 11.9% | 50.2 MB | 52.0 MB |
| Uplink 50% Packet Loss | 14.9% | 12.8% | 51.1 MB | 53.1 MB |
| Downlink 50% Packet Loss | 15.4% | 13.1% | 52.7 MB | 53.6 MB |
| Uplink 500 Kbps Cap | 15.7% | 12.5% | 53.0 MB | 63.7 MB |
| Downlink 500 Kbps Cap | 14.7% | 12.6% | 51.7 MB | 53.1 MB |
| Uplink 500 Kbps Cap + 25% Loss | 14.2% | 12.4% | 51.3 MB | 53.0 MB |
| Downlink 500 Kbps Cap + 25% Loss | 14.9% | 12.6% | 52.3 MB | 53.8 MB |
| Uplink 600 ms Jitter | 16.0% | 13.0% | 53.3 MB | 52.0 MB |
| Downlink 600 ms Jitter | 16.9% | 14.6% | 53.5 MB | 52.7 MB |
| Average | 15.2% | 12.8% | 52.1 MB | 54.1 MB |
The measurement window is from 16 s to 5 s before the end of the test. The resource figures include receiver-side decoding, rendering, and demo overhead, not video encoding. CPU uses a single-core 100% reference (a six-core device can total 600%). Memory is the process phys_footprint; reported values include demo and receiver-side processing costs, so the averages help compare these measured implementations and should not be read as the exact additional CPU or RAM that either SDK would require in a different app.
All figures are based on measurements sampled on the receiving device, and the win / “Approximately equal” results follow the criterion defined in this report. These results apply specifically to the devices, SDK versions, video configuration, and network conditions described in this benchmark. Performance may vary with other devices, SDK releases, encoding settings, network routes, or application configurations.
