WebRTC: an actual local video pipeline

Uses generated video only. No camera, microphone, remote signaling service or external STUN/TURN server. Start is explicit; Stop closes the media session.

Actual browser measurements

No connection yet.

No connection yet.

Send actual generated video through two peers

Start local session creates two RTCPeerConnection objects in this page. The source canvas supplies a video track, the sender encodes and transmits it, and the receiver decodes it into the second video panel. Offer, answer and ICE candidates are exchanged in local JavaScript; no external signaling service or STUN/TURN server is configured. This is a real browser media connection using fictional moving shapes, not a sequence of labels claiming a frame arrived. The browser may use local interfaces while establishing the path. No camera, microphone, customer recording or account is requested.

Set the source before starting

Source width chooses three hundred twenty or six hundred forty pixels; height preserves a sixteen-to-nine shape. Requested capture FPS selects five, fifteen or thirty frames per second. Those two settings apply when you start a new session; changing them during a run does not silently resize the active track. The browser and machine can deliver fewer frames than requested. Maximum sender bitrate is entered in kilobits per second and applied after negotiation. Use Apply bitrate during a run to request a new encoding cap. An accepted cap is visible in the evidence panel, while actual measured rate can be lower and may vary over time.

Control source motion without pretending to speed up the network

Shapes controls how many moving rectangles the source draws. Source movement selects half, normal or double movement per generated frame. Both affect source content rather than WebRTC’s clocks. Pause source stops drawing new canvas frames, leaving the connection and statistics active; Resume source continues movement. Already queued media can still arrive after pausing. Step one frame pauses continuous drawing and submits one new source image. The receiver video has separate native playback controls: pausing that display is not the same as pausing the source or stopping transmission. The session keeps running until Stop or a new session closes it, allowing a full minute or longer of observation.

Trace evidence through the pipeline

Watch the generated-frame label change on the source, then look for it in the received video. The browser statistics report encoded and decoded frame counts, packet counters and negotiated codec when available. A connected transport alone is not proof of rendered media; confirm that decoded frames and the receiver image progress. Source-generated, encoded and decoded counts need not match at every observation because capture, encoding and display run asynchronously. The diagrams are the actual source and receiver images, not a simulated prediction of what they should contain. Unsupported or missing statistics remain unavailable rather than becoming fabricated zeros.

Compare two bitrate caps on the same source

Start with width three hundred twenty, fifteen requested frames per second, twelve shapes and a five-hundred-kilobit cap. Wait for both peers to connect and for several encoded and decoded frames. Record the measured RTP rate over several samples. Enter one hundred and choose Apply bitrate. Confirm that the accepted maximum changes in the evidence, then compare actual rates over multiple observations. Increase source shapes or movement and inspect how the browser adapts. Do not expect a simple proportional relationship or an instant equal-rate result: rate control, content complexity, keyframes and available implementation choices all affect this local run.

Read timing measurements narrowly

RTP payload bitrate is calculated from the change in outbound bytes between report timestamps; it excludes transport overhead outside that counter. Encode time per new frame uses the difference in cumulative encoding time divided by newly encoded frames. The candidate-pair round trip is a transport measurement, not the delay from source drawing to receiver display. Receiver jitter is another reported transport statistic, not the chosen playout-buffer duration. Missing reports, repeated timestamps, a replaced stream or counters moving backwards leave interval metrics unavailable. This page does not claim a universal typical latency or infer end-to-end latency by adding unrelated averages.

Stop, restart and handle unsupported environments

Stop closes both peers and ends every source track, while leaving the last measured evidence available for inspection. Start local session also closes an earlier session before negotiating a fresh one. Restore defaults stops the connection and restores source settings. Hidden tabs pause source drawing to avoid unnecessary animation; returning does not automatically resume it. A failed connection, rejected bitrate request or blocked autoplay is reported without inventing successful media. Use the native receiver Play control if autoplay was blocked. Browser or network policy can prevent local peer connectivity; the guide and source visualization remain available, but an unavailable connection is not replaced with fake counters.

What this local experiment cannot establish

Both peers share a browser and machine. The page does not emulate WAN loss, relay costs, mobile radio behavior, an SFU, simulcast negotiation, congestion under competing traffic, audio echo cancellation or production authentication. No media is uploaded to a remote channel and no raw SDP, candidate address or complete statistics report is shown or saved. The evidence is a small selected projection. The generated shapes are not a video-quality test corpus, and no VMAF, PSNR or perceptual-quality score is computed. Run representative end-to-end tests on real devices and networks before using these observations for deployment decisions.

API references: Peer connection, sender parameters and WebRTC statistics definitions.