Tutorial: WebRTC Known Issues and Solutions

WebRTC Known Issues and Solutions

Chrome

  1. When hardware acceleration is enabled, the screen is occasionally corrupted if there is packet loss.
    Workaround:
    • update to Chrome 86 or above and use v4.6.6 or a later version of the TRTC SDK for web.
  2. On Chrome 88, when hardware acceleration is enabled and an MP4 file is published using HTMLMediaElement.captureStream, remote users see a black screen when playing the stream. For details, please see Chrome 88 bug.
    Workaround:
    • Update to Chrome 96 or above.
    • Disable hardware acceleration.
  3. On Chrome 88 (88.0.4324.96) for macOS, when hardware acceleration is disabled and the video stream captured by the camera is published, remote users see a black screen when playing the stream. For details, please see Chrome 88 bug.
    Workaround:
    • Update to Chrome 88.0.4324.146 or above.
    • Enable hardware acceleration (Chrome enables hardware acceleration by default).
  4. On Chrome, if deviceId is default or communications (on Windows), after a new mic is plugged and unplugged, mic capturing may stop.
    Workaround:
    • Do not use the mic whose deviceId is default or communications.
  5. On Chrome for macOS, when hardware acceleration is enabled, if you call LocalStream.muteVideo and then LocalStream.unmuteVideo, the publishing frame rate may drop to 2 fps and cannot be recovered. For details, please see Chrome bug.
    Workaround:
    • Update to TRTC SDK 4.8.0 or above.
    • Update to Chrome 91 or above.
  6. On Chrome 91 for Windows, when hardware acceleration is enabled, the encoding aspect ratio is only half the target. For details, please see Chrome bug.
    Workaround:
    • Update to TRTC SDK 4.8.0 or above.
  7. On Chrome for Windows, when hardware acceleration is enabled and the capturing frame rate is set to 15 fps, the encoding bitrate is only half the target. For details, please see Chrome bug.
    Workaround:
    • Update to TRTC SDK 4.8.0 or above.
  8. In Windows Chrome, there will be a microphone device with a deviceId of 'communications'. This microphone is packaged by Chrome based on a real microphone, which will be limited by Windows's Sound/Communications settings. If the user sets the Communications settings to "Mute all other sounds" and uses the 'communications' microphone to capture, the Chrome may be muted.
    Workaround:
    • Update to TRTC SDK 4.11.9 or above.
  9. In Chrome, there will be a microphone device with a deviceId of 'default'. When using a microphone with a deviceId of 'default', if a new microphone is plugged in and then unplugged, the audio capture may be interrupted. Submitted [issue] (https://bugs.chromium.org/p/chromium/issues/detail?id=1277465) to Chrome.
    Workaround:
    • Update to TRTC SDK 4.11.4 or above.

Firefox

  1. On Firefox, you cannot specify the capturing frame rate and can only capture video at 30 fps.
  2. The first installation of Firefox will dynamically install the H.264 codec while connected to the Internet. SDK connot publish and subscribe stream until the installation is completed. Suggestions:
    • Use TRTC.checkSystemRequirements API, if it detects that H264 codec is not supported in Firefox, guide the user to open the address: about:addons in Firefox and check the installation of OpenH264 in the Plugin. Wait for the installation to complete before making the call.

Safari

  1. On Safari for iOS, if stream.stop and stream.play are called frequently, remote streams may have no audio sometimes, but the statistics are all normal. For details, please see WebKit bug.
    Workaround:
    • There isn’t an ideal solution to the issue yet. We recommend that you avoid calling stream.stop and stream.play frequently.
  2. On Safari for iOS, if you have called getUserMedia once and call it again in a new tab, capturing in the previous tab will stop, and remote streams may have neither video nor audio. For details, please see WebKit bug.
    Workaround:
    • Safari for iOS has no immediate plans to support multi-tab getUserMedia calls. If you need to use this feature, we recommend that you manually stop capturing in a tab before calling getUserMedia in a new tab and resume capturing after switching back.
      A common scenario that requires multi-tab getUserMedia calls is when you switch to a new tab for facial recognition during a video call.
  3. A user on Safari for iOS experiences video stutter and frame rate drop when playing the stream of a user on Safari for macOS Big Sur.
    Workaround: no solution yet
  4. On some devices with iOS 14.2 or macOS Big Sur, audio playback stutters. For details, please see WebKit bug.
    Workaround:
    • Update iOS to 14.3 or above and macOS Big Sur to the latest version.
  5. When making an iOS 15 Safari audio / video call, the sound from the speaker may be lower than that of iOS 14. issue has been submitted to Webkit.
    Workaround:
    • Update iOS to 15.4 or above
  6. When making a video call in iOS 15, the video playback may goes black. Webkit bug.
    Workaround:
    • Update SDK version to 4.11.8 or above.
  7. When making a video call in iOS 15.1, the page wll crash. Webkit but.
    Workaround:
    • Update SDK version to 4.11.8 or above.
    • Apple will fixed this bug in iOS 15.2.
  8. Connecting a Bluetooth headset may cause iOS 15 Safari to play a very weird sound.webkit bug. No workaround.
  9. When user A plays out user B's voice and the phone is capturing A's voice, user B will hear a noise-like sound as a side effect of the iOS 14 echo cancellation feature.
    Workaround:
    • Update iOS to 15.4 or above.
    • Using a headset for calls.
  10. The video stream captured by canvas.captureStream cannot be played by video element in iOS versions below 15. webkit bug.
  11. With iOS 15.2、15.3、15.4, the muted attribute of HTMLMediaElement fails in some cases, resulting in sound playback. This can lead to sound playback. webkit bugwebkit bug
    Workaround:
  • Update SDK version to 4.12.2 or above.
  1. Can't encode videos with resolutions higher than 720p in iOS 13 and 14. Workaround:
  • Update SDK version to 4.12.3+, SDK will not capture video at resolutions higher than 720p in iOS versions 13 and 14.
  1. With iOS 15, when your page has Audio tags that play non-MediaStream, the Audio tab may play less loudly after the page gets the microphone and turns it off in some devices. webkit bug .

Webview

  1. H264 decoder is not available on Android System Webview, version before 79. webview bug.
    Workaround:
    • Guide user to upgrade Android System Webview to version 79 or above. It needs user to install webview apk package.

Huawei

  1. You cannot publish streams on Huawei Browser or Chrome on Huawei devices because the browsers do not support H.264 encoding.

Xiaomi

  1. In some Xiaomi phones, you may cannot hear voice from remote peer if you are using SDK on Wechat. This is a MIUI issue, and it will be fixed in future updates. Wechat engineers are also trying to fix it.

WeChat

  1. For WeChat TBS/045811 and below versions, if user click the authorization button more than 5s after the authorization window pops up, an autoplay failure error will be thrown when calling LocalStream.play(). This is a known issue for TBS, and will be fixed on next TBS version. Workaround:

    • You can refer to the Solution two of tutorials Suggested Solutions for Autoplay Restrictions. Guide user to click page when an autoplay failure error is thrown on LocalStream.play(), then use LocalStream.resume() to resume playback.

WeCom

  1. iOS WeCom WebView opens and the authorization popup box may not appear after getting the media device method.
    Workaround:
    • Update WeCom version to 4.0.6 or above.

Screen Sharing

  1. On Chrome for Windows and macOS, when a shared application is minimized, capturing stops and the frame rate drops to 0.
  2. On Chrome for Windows, when WeChat/QQ/WPS is selected as the application to share during WebRTC screen sharing, users may see a black screen. There isn’t a workaround to this issue yet.
  3. On Chrome for Windows, when hardware acceleration is enabled and H.264 is used for encoding, the screen sharing bitrate may be lower than the target, resulting in lower-than-expected video quality. To avoid this, you can update to TRTC SDK 4.8.0 or above.
  4. On Firefox for Mac OS, the encoded screen sharing video content may be misaligned, Firefox bug. No workaround, it is recommended to use Chrome or Safari for screen sharing.
  5. On Chrome for Mac OS, screen sharing fails with "NotAllowedError: Permission denied by system" or "NotReadableError: Could not start video source" error message when screen recording is authorized, Chrome bug. Solution: Open [Settings] > Click [Security & Privacy] > Click [Privacy] > Click [Screen Recording] > Turn off Chrome Screen Recording license > Turn on Chrome Screen Recording license again > Turn off Chrome > Turn on Chrome again.

Other Vendors

  1. In NetEase’s WebRTC SDK, the RTCPeerConnection.prototype.getStats method is rewritten, and the format of data returned is different from that in standard WebRTC SDKs. If you integrate both the TRTC SDK and NetEase’s WebRTC SDK into your project, TRTC will fail to get audio/video statistics and cannot report statistics to the dashboard.

Vue 3 Reactivity and Proxy

When using Vue 3, developers should note that Vue 3 implements reactivity based on Proxy. Please use Vue markRaw to set SDK instances such as TRTC, Client, LocalStream, and RemoteStream as non-reactive attributes. If you add a Proxy to the SDK instance, it may cause SDK exceptions.