logo
On this page

What are some known issues with WebRTC browsers and workaround solutions?

2023-12-14
Products / Plugins:Video Call
Platform / Framework:Web

This article introduces some known issues with WebRTC browsers and workaround solutions. Developers can refer to this article for handling during use, or contact ZEGOCLOUD Technical Support.

Chrome

Occasional video corruption when packet loss occurs after enabling hardware acceleration.

Please upgrade to Chrome 86 or above, and upgrade the SDK to the latest version. Click Download SDK.

Chrome 88 with hardware acceleration enabled, using HTMLMediaElement.captureStream to publish MP4 files, remote end sees black screen. Chrome 88 bug

  • Please upgrade to Chrome 96 or above.
  • Please disable hardware acceleration to work around this issue.

Mac Chrome 88 (88.0.4324.96) publishing camera-captured video stream, remote end sees black screen. Chrome 88 bug

Please upgrade to Chrome 88.0.4324.146 or above.

Chrome using deviceId "default" or "communications" (Windows devices have this deviceId). If a new microphone is inserted and then removed, it may cause microphone capture interruption.

Please avoid using microphone devices with deviceId "default" or "communications".

Mac Chrome with hardware acceleration enabled, calling mutePublishStreamVideo interface to turn off video and then resume, may cause publishing frame rate to drop to 2 fps and cannot recover. Chrome bug

  • Please upgrade the SDK to the latest version. Click Download SDK.
  • Please upgrade to Chrome 91 or above.

Windows Chrome 91 version, with hardware acceleration enabled, encoding resolution width and height are only half of the target resolution. Chrome bug

Please upgrade the SDK to the latest version. Click Download SDK.

Windows Chrome with hardware acceleration enabled, encoding 15fps video with encoding bitrate only half of the target bitrate. Chrome bug

Please upgrade the SDK to the latest version. Click Download SDK.

Windows Chrome being muted.

Windows Chrome has a microphone device with deviceId "communications", which is a wrapper of the real microphone by Chrome. This microphone is subject to Windows sound communication settings. If the user sets Windows sound communication settings to "Mute all other applications", and uses the "communications" microphone for capture, Chrome may be muted.

If the business side specifies a microphone for capture, avoid using the microphone with deviceId "communication".

Chrome capture no audio issue.

Chrome has a microphone device with deviceId "default", which points to the microphone Chrome considers as default. When using the microphone with deviceId "default" for calls, if a new microphone is inserted and then removed, capture interruption may occur, causing no audio capture.

Please upgrade the SDK to the latest version. Click Download SDK. When capture exception occurs, the SDK will automatically recover capture.

Some Windows computers, audio device selection "Stereo Mix", no sound.

Please avoid using "Stereo Mix" device.

Firefox

Firefox does not support setting capture frame rate, can only capture 30fps video.

Firefox selecting OBS as the publishing source, browser cannot get stream information, and there are no stream quality related callbacks during publishing.

iOS Safari

iOS Safari does not support multiple tabs getUserMedia, otherwise the previous tab will stop capturing, and the remote stream may also have black screen and no audio. webkit bug

Multiple tabs getUserMedia business scenarios generally include: during video calls, switching to a new tab for face recognition.

iOS Safari has no plans to support multiple tabs getUserMedia feature. If the business side needs to use multiple tabs getUserMedia in iOS Safari, it is recommended to stop device capture before switching to a new tab; resume device capture after switching back.

iOS Safari and Mac Big Sur

Please upgrade Mac BigSur to the latest version.

iOS 14.2 some devices and Mac Big Sur Safari, audio playback has noise. webkit bug

Please upgrade iOS devices to 14.3 or above, Mac Big Sur to the latest version.

iOS 15 Safari audio and video calls, speaker volume may be lower than iOS 14. webkit bug

Please upgrade iOS devices to 15.4 or above.

iOS 15.0 Safari audio and video calls, playing video may have black screen issue. webkit bug

Please upgrade SDK to 2.14.0 or above. Click Download SDK.

iOS 15.1 Safari and Chrome publishing, browser page may crash. webkit bug

  • Please upgrade SDK to 2.14.0 or above. Click Download SDK. The SDK uses canvas capture scheme to work around this issue, which has relatively higher performance overhead.

    For performance considerations, it is recommended to capture Profile not higher than 720p, 15fps on iOS 15.1. Please note that this scheme requires the local video stream to be in playback state. Please upgrade to the latest SDK. Fundamentally, this issue needs to be fixed by iOS releasing a new version.

  • Apple plans to fix this issue in iOS 15.2. You can upgrade to iOS 15.2 or above.

User A plays user B's audio externally, while the phone is also capturing A's audio. At this time, user B hears the sound accompanied by electrical noise, which is a side effect of iOS 14's echo cancellation feature.

  • Please use earphones for calls.
  • Please upgrade iOS devices to 15.4 or above.

iOS 15 and below versions, video stream captured by canvas.captureStream cannot be played using video tag. webkit bug

Webview

Android System Webview M79 and below versions cannot use H264 decoding. Webview bug

Please upgrade Android System Webview version to M79 or above. You need to install the corresponding version of Webview apk package.

Huawei Devices

Huawei browser and Chrome browser on Huawei devices cannot publish streams.

Due to Huawei device limitations, some versions of Huawei browser and Huawei Chrome browser do not support H264 encoding, so they cannot publish streams.

Developers can use VP8 encoding for publishing.

Xiaomi Devices

In WeChat on some Xiaomi phones, playing stream has no audio issue.

Known models include: Xiaomi 9, Xiaomi 10s, Xiaomi 11, K30 5G, etc.

This is a known MIUI issue. Xiaomi engineers are working on fixing it. WeChat has also found a workaround and is currently in gray release.

WeChat

WeChat TBS/045811 and below kernel versions, after the authorization window pops up, if the authorization button is clicked after more than 5 seconds, autoplay failure error occurs.

When autoplay error occurs, guide customers to click the page, then call the video.play() interface to resume playback.

Screen Sharing

Windows & Mac Chrome browser screen sharing an app, minimizing will cause capture to stop, fps = 0.

Windows using Chrome screen sharing, selecting application window to share to WeChat, QQ, DingTalk, WPS and other applications, may have capture black screen; or dragging the application window may have capture black screen.

It is recommended to share the entire screen.

Windows Chrome using H264 encoding, with hardware acceleration enabled, screen sharing bitrate may not reach target bitrate, resulting in image quality not as expected.

Please upgrade SDK to 2.14.0 or above. Click Download SDK.

Mac Firefox screen sharing may have video partial area misalignment. Firefox bug.

It is recommended to use Chrome or Safari browser for screen sharing.

Mac Chrome with screen recording authorized, screen sharing fails, showing "NotAllowedError: Permission denied by system" or "NotReadableError: Could not start video source" error message. Chrome bug.

Open [Settings] > Click [Security & Privacy] > Click [Privacy] > Click [Screen Recording] > Turn off Chrome screen recording authorization > Re-enable Chrome screen recording authorization > Close Chrome browser > Reopen Chrome browser.

On Windows 7 operating system, using Firefox browser for screen sharing, selecting to share the current window page, capture black screen occurs.

It is recommended to share the entire screen, or use Chrome browser for screen sharing.

Other Vendors

NetEase WebRTC SDK rewrites RTCPeerConnection.prototype.getStats method, the returned data format is inconsistent with the standard WebRTC protocol.

If both Express-Video SDK and NetEase's WebRTC SDK are introduced, Express cannot get audio and video data, causing inability to report audio and video call data to the dashboard normally.

Previous

How to understand and use SEI (Supplemental Enhancement Information)?

Next

How to handle the issue of video stuttering or audio-video out of sync when using OBS to publish and SDK to play?

On this page

Back to top