MY WEBCAM TEST GUIDE

How to troubleshoot frozen WebRTC video

Find out why WebRTC video freezes during a call, which checks separate camera, network and device causes, and which fixes to try first.

The short answer

Frozen video in a WebRTC call means new frames stopped reaching the screen while the call itself stayed connected. The cause can be at one of four points: the camera stopped delivering frames (capture), the network dropped or delayed video packets (transport), the receiving device could not decode or display frames fast enough (playback), or the calling app paused or reconfigured the video stream. WebRTC is the real-time audio and video technology built into web browsers and many calling apps.

The fastest way to narrow it down is to find out whose video is frozen and where. If your own self-view freezes, start with the camera. If your self-view keeps moving but other people see you frozen, start with your upload connection or your computer's processing load. If you see someone else frozen, the problem is on their side, on your download connection, or in your device's playback.

Frozen video is a different symptom from a black or blank video tile. A frozen frame means the camera was detected, access was granted, and video was flowing before it stopped. A black tile from the start more often points to blocked permission, a privacy shutter, or the wrong camera being selected. The checks below apply to frozen video only, and they do not cover microphone problems. Audio travels on a separate track, so continued sound does not show that the video path is healthy.

Which check will narrow down the cause

Do the checks below in order. Each one tests a specific part of the path, and a pass or fail rules in or rules out only that part.

1. Find out whose video is frozen

What you observe | Most likely area | Check next
Your own self-view freezes | Camera capture on your device | Check 2 (camera in another app)
Your self-view moves, but others say you are frozen | Your upload network or your device's encoding load | Checks 4 and 5
One remote person is frozen, others are fine | That person's camera, device or connection | Ask them to run these checks
Every remote video freezes for you | Your download network or your device's playback | Checks 4 and 5
Video freezes but audio continues | Video-specific path (camera, video bandwidth or decoding) | Continue with the checks that match the row above

Scope: this check only tells you which side of the call to look at. It does not identify the component at fault. Many calling services reduce or pause video before audio when the connection gets tight, so continued audio fits a bandwidth problem as well as a camera problem.

2. Test the camera outside the call

If your self-view froze, open the camera in a different app, such as your operating system's built-in camera app, and leave it running for a few minutes. If the preview also freezes there, the problem is in the camera, its cable or port, its driver, or another program using it. If the preview stays smooth, the camera hardware is probably fine and the problem is more likely in the browser or calling app.

Scope: this test checks local capture only. It says nothing about your network or about how the other person's device receives your video. A camera that works in a local app can still look frozen to others.

3. Check for camera conflicts and connection issues

  • Close other apps and browser tabs that might be using the camera, including virtual-camera or effects software. On some systems a second app taking over the camera can interrupt the first app's stream.
  • For an external USB camera, watch for a disconnect sound or a notification when the freeze happens. A brief disconnect suggests a cable, port, hub or power problem rather than a network problem.
  • In the calling app's settings, confirm which camera is selected. A virtual camera or a different physical camera may be active instead of the one you expect. A frozen virtual camera points to the virtual-camera software, not the hardware.

4. Separate network problems from device problems

Repeat the call on a different connection. For example, switch from Wi-Fi to a wired connection, move closer to the router, or temporarily use a phone hotspot. Pause large uploads, downloads, cloud backups and streaming on the same network. If the freezing stops on the other connection, the original network is the likely cause.

Next, keep the network the same and change the device or browser. Join from another browser or another computer. If the freezing follows the device, look at that device's load and settings. If it follows the network, focus on the network.

Scope: one clean test call shows the problem did not appear during that window. It does not prove the network is reliable, because congestion can come and go.

5. Check processing load during the freeze

Open your operating system's task or activity monitor while the call is running. Very high processor or graphics usage during freezes suggests the device cannot keep up with encoding your video or decoding everyone else's. Background blur, virtual backgrounds, high-resolution video, many video tiles, and power-saving modes can all add to this load or limit available performance.

6. Read the call's statistics (optional, more technical)

Major browsers include a built-in WebRTC diagnostics page that shows live statistics for active calls. Chromium-based browsers have an internal WebRTC page, and Firefox has a WebRTC page in its about pages. The exact layout and the available fields differ by browser and version. These fields, defined in the WebRTC statistics specification, are the most useful for freezes:

  • Frames decoded and frames per second on incoming video: if they stop climbing during a freeze, frames are not arriving or not being decoded.
  • Packets lost: rising loss during freezes points to the network.
  • Freeze count and total freeze duration, where supported: these confirm that the receiver detected freezes and show how often they happen.
  • PLI count (picture loss indication): repeated requests for a fresh full frame suggest the receiver lost data and had to wait for a recovery frame.
  • Quality limitation reason on outgoing video: a value of cpu or bandwidth shows what the sender's browser reports is holding back your video.

If you are building or debugging a WebRTC app, you can log the same fields from code. The snippet below assumes an existing RTCPeerConnection named pc. Fields your browser does not support will show as undefined.

const stats = await pc.getStats();
stats.forEach(report => {
  if (report.type === 'inbound-rtp' && report.kind === 'video') {
    console.log('inbound video', {
      framesDecoded: report.framesDecoded,
      framesPerSecond: report.framesPerSecond,
      packetsLost: report.packetsLost,
      freezeCount: report.freezeCount,
      pliCount: report.pliCount
    });
  }
  if (report.type === 'outbound-rtp' && report.kind === 'video') {
    console.log('outbound video', {
      framesEncoded: report.framesEncoded,
      qualityLimitationReason: report.qualityLimitationReason
    });
  }
});

On the sending side, you can also check the local camera track. A track whose readyState is ended has stopped for good, for example because the device was unplugged or access was revoked. A track that fires a mute event is temporarily not receiving frames from its source. Either result points to capture, not the network.

Scope: statistics show what one browser observed on its end of the call. Receiver statistics describe incoming video, and sender statistics describe outgoing video, so compare both ends before deciding where the fault is. No reliable threshold values were available for this guide, so read the numbers by watching how they change during a freeze, not against a fixed target.

What to change, and how to know it worked

Make one change at a time, starting with the ones that are easy to undo. After each change, repeat the same kind of call for about as long as it usually takes the freeze to appear. The fix worked if your self-view stays smooth, the other person confirms your video stays live, and, if you are watching statistics, frames decoded keep rising and freeze count stops increasing.

If the camera or capture is the cause

  • Close other apps that use the camera, then rejoin the call or reload the page.
  • In the calling app, switch to a different camera and back again. This often restarts the video stream.
  • Plug the USB camera directly into the computer instead of through a hub, and try a different port. If you use several USB cameras or other high-bandwidth devices, try spreading them across different ports.
  • Disable or remove virtual-camera software for a test call to see whether it is involved.

If the network is the cause

  • Use a wired connection or move closer to the router.
  • Pause other heavy traffic on the same network during calls.
  • Lower the video quality or resolution in the calling app, if it has that option, so the stream needs less bandwidth.
  • If freezes happen only on one network, such as a workplace or school network, contact that network's administrator. Firewalls and network policies can affect real-time media.

If device load or playback is the cause

  • Turn off background blur, virtual backgrounds and other video effects.
  • Close unneeded apps and browser tabs.
  • Plug in a laptop and turn off power-saving modes during the call.
  • Reduce the number of video tiles shown, if the app allows it.
  • Update the browser to its current version.
  • As a test, change the browser's hardware acceleration setting. This setting affects how the browser uses your graphics hardware for all pages, not only calls, and usually requires a browser restart. Switch it back if it does not help.

Driver, firmware and reset steps

Consider these only after the steps above. Follow the official instructions from your camera maker, computer maker or operating system vendor, because the right method depends on your hardware and system version. Be aware of the side effects: driver updates may need a restart and can occasionally introduce new problems that require rolling back. Interrupting a firmware update can leave a device unusable. Resetting a site's camera permissions in the browser means you will need to grant access again the next time you join.

When to stop and escalate

If the camera also freezes in local apps after you have tried a different port, a direct connection and an updated driver, the camera hardware or its driver is the likely cause. Contact the camera or computer maker's support.

If the camera works locally and the freezes happen only in one calling service, across different browsers and networks, contact that service's support. Include what you observed: whose video froze, whether your self-view also froze, which browser and operating system versions you used, and any statistics you recorded during a freeze.