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

fix: Properly handle broadcast capture state #705

Merged
merged 9 commits into from
Feb 18, 2025

Conversation

ladvoc
Copy link
Contributor

@ladvoc ladvoc commented Feb 12, 2025

Summary of changes

  • When using the broadcast capturer on iOS, the broadcast extension now drives whether or not screen sharing is enabled, publishing a screen sharing track when the extension begins broadcasting upon user approval.
  • The new BroadcastManager class gives developers control over the broadcast state and track publication for advanced use cases.
  • Since the broadcast state is now managed within the library, the boilerplate required in the user's implementation is reduced; the example app has also been updated to reflect this.

Fixes

Minor breaking changes

  • Enabling screen sharing with setScreenShareEnabled or setSourceEnabled on LocalParticipant currently returns a LocalTrackPublication representing the newly published screen share track. After this change, when using the broadcast capturer on iOS, this method will return null, as the track will be published asynchronously pending user approval. Developers should treat enabling screen share as a request that might not be fulfilled and should not interpret null return values from these methods as errors.
  • Since track publication is now asynchronous, capture options must be set as room defaults rather than being passed to setSourceEnabled when enabling screen sharing.

Additional context

Outstanding items

Mirrors API of the same class from the native Swift SDK.
Unneeded functionality has been omitted.
This is necesary to allow using the Combine framework. Since the minimum deployment target is iOS 13 according to the Podspec, this should not cause any issues.
Same solution as implemented in PR livekit#551 for the native Swift SDK.
Sets the `deviceId` constraint to `broadcast-manual`, ensuring the broadcast picker isn't presented a second time when publishing a screen share track.
Removes boilerplate for iOS broadcast state management now handled internally by the library.
@ladvoc ladvoc marked this pull request as draft February 12, 2025 02:36
@ladvoc ladvoc marked this pull request as ready for review February 12, 2025 18:59
Copy link
Contributor

@cloudwebrtc cloudwebrtc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lg!

@cloudwebrtc
Copy link
Contributor

The corresponding flutter-webrtc has been released
https://pub.dev/packages/flutter_webrtc/versions/0.12.9

@cloudwebrtc
Copy link
Contributor

hey @ladvoc, There is a small issue preventing CI from passing, can you try running dart run import_sorter:main --no-comments locally and then committing the sorted import changes?

@cloudwebrtc cloudwebrtc merged commit b782436 into livekit:main Feb 18, 2025
6 of 7 checks passed
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 this pull request may close these issues.

[bug]The user did not click "Start Broadcast",but the isScreenShareEnabled() method returns true on iOS
2 participants