pion/webrtc-bench — Gitpedia

<h1 align="center"> <a href="https://pion.ly"><img src="./.github/pion-gopher-webrtc.png" alt="Pion WebRTC" height="250px"></a> <br> WebRTC Bench <br> </h1> <h4 align="center">WebRTC Server that generates usage reports, Web/CLI Clients included!</h4> <p align="center"> <a href="https://pion.ly"><img src="https://img.shields.io/badge/pion-webrtc-gray.svg?longCache=true&colorB=brightgreen" alt="Pion webrtc"></a> <a href="https://discord.gg/PngbdqpFbt"><img src="https://img.shields.io/badge/join-us%20on%20discord-gray.svg?longCache=true&logo=discord&colorB=brightblue" alt="join us on Discord"></a> <a href="https://bsky.app/profile/pion.ly"><img src="https://img.shields.io/badge/follow-us%20on%20bluesky-gray.svg?longCache=true&logo=bluesky&colorB=brightblue" alt="Follow us on Bluesky"></a> <br> <a href="LICENSE"><img src="https://img.shields.io/badge/License-MIT-yellow.svg" alt="License: MIT"></a> </p> <br>

webrtc-bench is a WebRTC server that plays a video file from disk, and then re-distributes via WebRTC. It generates performance metrics including CPU usage, peer connection counts, and detailed latency measurements for connection setup phases.

This repo contains a CLI WebRTC Client that will connect and perform the load test. This is done via a REST API hosted on :8080/doSignaling. You can also watch the video/load test via the web UI at :8080/,
it connects via the same REST API as the CLI.

Running

git clone https://github.com/pion/webrtc-bench.git
cd webrtc-bench/server
ffmpeg -i $INPUT_FILE -g 30 -b:v 2M input.ivf
go run main.go

You can then access the Web UI at http://localhost:8080. This requires a browser that supports H264, this repo doesn't do any error handling around signaling failures.

You can also use the provided WebRTC CLI

cd webrtc-bench/client
go run main.go localhost:8080

Output Files

The benchmark generates three CSV files with performance data:

report.csv (Server)

System-level metrics collected every 3 seconds:

timestamp, peerConnectionCount, cpuUsage, droppedLatencyMeasurements
2020-12-15T13:59:23-08:00, 1, 17.878028, 0
2020-12-15T13:59:26-08:00, 0, 35.101254, 0
2020-12-15T13:59:29-08:00, 1, 12.565718, 0

server-latencies.csv (Server)

Detailed WebRTC connection setup timing from server perspective:

timestamp,type,latencyMs
2026-01-02T19:33:57.714Z,signaling_processing,13.391
2026-01-02T19:33:57.714Z,sdp_offer_processing,6.587
2026-01-02T19:33:57.714Z,sdp_answer_creation,0.365
2026-01-02T19:33:57.715Z,ice_gathering,0.255
2026-01-02T19:33:57.825Z,ice_connection,122.588
2026-01-02T19:33:57.979Z,dtls_handshake,153.612

Server Metrics:

signaling_processing: Total signaling time (offer → answer)
sdp_offer_processing: SDP offer parsing time
sdp_answer_creation: SDP answer generation time
ice_gathering: ICE candidate gathering time
ice_connection: Time from connection start to ICE connected
dtls_handshake: DTLS handshake completion time

client-latencies.csv (Client)

Connection setup timing from client perspective:

timestamp,type,latencyMs
2026-01-02T11:33:57.706Z,ice_gathering,5001.234
2026-01-02T11:33:57.706Z,signaling_rtt,72.456
2026-01-02T11:33:57.811Z,ice_connection,5183.789
2026-01-02T11:33:57.916Z,dtls_handshake,104.123
2026-01-02T11:33:57.916Z,media_ready,5287.912

Client Metrics:

ice_gathering: ICE candidate gathering time
signaling_rtt: Round-trip time for signaling exchange
ice_connection: Total time to ICE connected
dtls_handshake: DTLS handshake completion time
media_ready: Total connection setup time

All latency measurements are recorded with sub-millisecond precision.

Results

The following graph was generated from the results.csv that was generated by the server. The client was run from another EC2 instance in the same VPC.
The Y Axis is the CPU Usage, and the X Axis is the count of PeerConnections. This was run on a m4.2xlarge (Intel(R) Xeon(R) CPU E5-2686 v4 @ 2.30GHz)

FAQ

What codec/bitrate was being distributed

This is controlled by what video you use. You can go as high (or low) as you want.

What SRTP Cipher was used

SRTP_AEAD_AES_128_GCM

What Congestion Control/Feedback is used

None, on purpose.

Pion by design allows the user to specify what they want. We are distributing a video feed that is already encoded, and has a very small keyframe-interval so these things don't help us.

When setting up the PeerConnection you have full control of the RTP/RTCP pipelines, so users can add TWCC/NACK/FEC in a way that works for them.