Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] web: remote video doesn't show on participant re-join #721

Open
holzgeist opened this issue Mar 5, 2025 · 1 comment · May be fixed by #722
Open

[bug] web: remote video doesn't show on participant re-join #721

holzgeist opened this issue Mar 5, 2025 · 1 comment · May be fixed by #722

Comments

@holzgeist
Copy link
Contributor

Describe the bug

On Flutter Web deployed Livekit applications, remote participants are not visible after leaving and re-joining a call. This is due to this line which stops the media stream track. MediaStreamTrack only has a stop() method, no start() method. So once it's stopped it stays that way. Specifically even setting enabled to true won't "resurrect" the stream.

Apparently, when the participant rejoins, it gets the same media stream track from RTCPeerConnection.onTrack here. However, it is stopped now and won't play, even when calling element.play() or setting element.autoPlay to true.

To Reproduce

  • Build and deploy the example (e.g. flutter build web && miniserve build/web)
  • launch two instances with different tokens to avoid duplicate identities
  • disconnect one of the two
  • reconnect
  • see black screen on instance which stayed in call

NB: the reconnecting instance doesn't need to be Flutter Web, I tested with Android too. The Web instance should be the one staying in the call and it will lose video from the reconnecting one.

Expected behavior

Rejoining participant should be visible

Platform information

  • Flutter version:
[✓] Flutter (Channel stable, 3.29.0, on Arch Linux 6.13.5-arch1-1, locale en_US.UTF-8) [172ms]
    • Flutter version 3.29.0 on channel stable at /home/tobias/src/3rdparty/flutter
    • Upstream repository https://github.com/flutter/flutter
    • Framework revision 35c388afb5 (3 weeks ago), 2025-02-10 12:48:41 -0800
    • Engine revision f73bfc4522
    • Dart version 3.7.0
    • DevTools version 2.42.2

[✓] Android toolchain - develop for Android devices (Android SDK version 35.0.1) [1,664ms]
    • Android SDK at /opt/android-sdk/
    • Platform android-35, build-tools 35.0.1
    • ANDROID_HOME = /opt/android-sdk/
    • ANDROID_SDK_ROOT = /opt/android-sdk
    • Java binary at: /opt/android-studio/jbr/bin/java
      This is the JDK bundled with the latest Android Studio installation on this machine.
      To manually set the JDK path, use: `flutter config --jdk-dir="path/to/jdk"`.
    • Java version OpenJDK Runtime Environment (build 21.0.5+-13047016-b750.29)
    • All Android licenses accepted.

[✓] Chrome - develop for the web [102ms]
    • Chrome at google-chrome

[✓] Linux toolchain - develop for Linux desktop [190ms]
    • clang version 19.1.7
    • cmake version 3.31.6
    • ninja version 1.12.1
    • pkg-config version 2.3.0

[✓] Android Studio (version 2024.2) [100ms]
    • Android Studio at /opt/android-studio
    • Flutter plugin version 83.0.3
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 21.0.5+-13047016-b750.29)

[✓] Connected device (3 available) [185ms]
    • FP5 (mobile)    • 6c5b0b9d • android-arm64  • Android 14 (API 34)
    • Linux (desktop) • linux    • linux-x64      • Arch Linux 6.13.5-arch1-1
    • Chrome (web)    • chrome   • web-javascript • Mozilla Firefox 136.0

[✓] Network resources [836ms]
    • All expected network resources are available.

• No issues found!

  • Plugin version: 2.4.0
  • Flutter target OS: Web (tested on Chromium and Firefox) on Arch Linux
  • Flutter target OS version: Firefox 136 and Chromium 134.0.6998.35
  • Flutter console log:
@holzgeist holzgeist linked a pull request Mar 5, 2025 that will close this issue
@holzgeist
Copy link
Contributor Author

#722 fixes the behaviour, but maybe not the actual bug.

To me it looks like the bug is that the old closed MediaStreamTrack is used for a new incoming connection. But I'm no WebRTC expert so I'm not sure 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant