Screen share: deliberate control over multiple streams and their audio #91

Open
opened 2026-10-07 19:22:54 +00:00 by robocub · 0 comments
Member

Today Vommet allows one screen share at a time (fix/screenshare-one-at-a-time): sharing again switches the source, and Stop ends the share. Before that, each press of Share quietly added another stream, and Stop removed only one of them.

Several streams at once can be genuinely useful, e.g. a movie in one stream and a game in another. Ideas to explore, with deliberate controls instead of the old accident:

  • How many streams: one (default) or several, each started and stopped on its own (Stop asks which one, or there is a Stop on each tile).
  • What a stream shows: one monitor, all monitors combined into one stream, one stream per monitor, or one window/app.
  • Which audio goes with which stream: per stream, None / all apps / one app / several apps (checkboxes: include or exclude lists). The capture layer already supports include/exclude lists; only UI is missing.
  • How viewers see them: label each stream (window/app name, stream number) so viewers can tell them apart and pick which to watch.

Technical notes:

  • The Linux per-app audio capture (our flutter-webrtc fork, PulseLoopbackCapturer) runs one capture per app instance; several simultaneous streams with audio need one capturer per stream.
  • On Wayland the system portal picks the video; whether it can hand out several sources (or "all monitors") depends on the portal (COSMIC/KDE/GNOME differ).
  • LiveKit's setScreenShareEnabled(false) only unpublishes the first screen-share track, so several streams need our own bookkeeping per stream.

Upstream Commet: nothing on multiple streams. Related: commetchat/commet#854 (KDE portal duplicate dialogs), commetchat/commet#969 (screen share with audio).

Follow-up of #4.

Today Vommet allows **one screen share at a time** (`fix/screenshare-one-at-a-time`): sharing again switches the source, and Stop ends the share. Before that, each press of Share quietly added another stream, and Stop removed only one of them. Several streams at once can be genuinely useful, e.g. a movie in one stream and a game in another. Ideas to explore, with deliberate controls instead of the old accident: - **How many streams**: one (default) or several, each started and stopped on its own (Stop asks which one, or there is a Stop on each tile). - **What a stream shows**: one monitor, all monitors combined into one stream, one stream per monitor, or one window/app. - **Which audio goes with which stream**: per stream, None / all apps / one app / **several apps** (checkboxes: include *or* exclude lists). The capture layer already supports include/exclude lists; only UI is missing. - **How viewers see them**: label each stream (window/app name, stream number) so viewers can tell them apart and pick which to watch. Technical notes: - The Linux per-app audio capture (our flutter-webrtc fork, `PulseLoopbackCapturer`) runs one capture per app instance; several simultaneous streams with audio need one capturer per stream. - On Wayland the system portal picks the video; whether it can hand out several sources (or "all monitors") depends on the portal (COSMIC/KDE/GNOME differ). - LiveKit's `setScreenShareEnabled(false)` only unpublishes the first screen-share track, so several streams need our own bookkeeping per stream. Upstream Commet: nothing on multiple streams. Related: commetchat/commet#854 (KDE portal duplicate dialogs), commetchat/commet#969 (screen share with audio). Follow-up of #4.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
nether/vommet#91
No description provided.