[vibesoftwarecoder]

What this adds

A second window for a second video stream. The session, the pairing and the connection stay the same. The host sends two pictures, and the client shows the second one in a window of its own. The second picture is one of two things:

• A window on the host, picked by its title.
• A whole display that the host makes, like an extra monitor. Windows dragged onto it in the main window show up in the second one.

It needs an ApolloVibe host with second_video_stream = enabled (ApolloVibe PR 16). Against any other host the client drops the request and carries on with one window. With the setting off, which is the default, nothing about a stream changes.

What the user sees

• Settings has a new "Second Window" section, after Basic Settings. It starts with a check box, "Show a second window". The rest is hidden until it is on:
  • What to show: a window, or a whole display. For a window, a title field.
  • Resolution (720p to 4K) and frame rate (30 or 60).
  • Show it on this display: which screen the second window opens on. Automatic picks a screen the main window is not on.
  • Open the second window in full screen (on by default). F11 switches between full screen and a window.
  • A note that a whole display needs the console host, and a seat can only show a window.
• Starting a stream from the app tile now asks for the second window when the check box is on. The title and the choices are saved.
• The main window can also be placed on a chosen display ("Stream window display").
• Closing the second window stops only the second picture on the host. The main window keeps streaming.
• Command line: --second-window <title>, --second-window-source window|display, --second-window-resolution WxH, --second-window-fps N, --second-window-display N, --second-window-fullscreen / --no-second-window-fullscreen, --window-display N.
• The README is rewritten for the second window, USB forwarding and the current settings.

How it works

• SecondaryStreamWindow (new, app/streaming/secondarystream.*) owns the second SDL window and its decoder. The first window's code is unchanged except where noted below.
• The decoder is made through the existing Session::chooseDecoder, so the second window gets the same renderer choices as the first. Each decoder asks the connection for the frames of its own stream, through new per-stream calls in moonlight-common-c-mic. Before that, one decoder received frames from both streams and crashed.
• Pointer input in the second window is mapped onto its own picture. The client tells the host which picture the following pointer events refer to.
• The second window opens without taking focus, and the first window is raised when it is shown. A second window that took focus made the first one capture the mouse for the wrong window, so the pointer could not leave the second window.
• Focus and pointer-leave events of the second window no longer reach the first window's mouse-capture code, for the same reason.
• The library change (moonlight-common-c-mic, pinned here) gives each video stream its own depacketizer, socket and threads, adds stream-scoped keyframe requests and an input-target call, asks the host to stop one stream, and drops a request for a display when the host says it cannot make one.

Testing

Tested by hand on one Windows client (a handheld with an AMD Radeon 890M on ethernet) against an ApolloVibe console host:

• A window as the second picture: both windows decode and update, clicks reach the right window, the second window opens on the other display.
• A whole display: the extra display appears on the host when the stream starts, windows dragged onto it show in the second window, and closing the second window removes the display.
• Settings: the section hides and shows, the drop-downs fill in, the title and the check boxes are still set after closing and reopening the app.
• Resolution and frame rate options, full screen on open, F11, and the pointer moving freely between the windows.
• The Windows build passes in CI on this branch.

Not tested, and known limits

• macOS and Linux were not built or run with this branch. The Windows workflow is the only one run on it. The pull request runs the generic build; it is the first time the other platforms see this code. The second window uses SDL and the existing decoder code, but nothing here is Windows-only that I know of.
• Only the D3D11VA renderer ran in the tests. The software, libplacebo and other renderers should work through the same decoder choice but were not tried.
• Only two displays were tried for placing the windows.
• Against a host without the feature, I checked the code path by reading it. I did not stream from one.
• The second window uses absolute pointer positions only, with no relative mouse mode.
• The first seconds after connecting can show some mouse lag. The same happens with one stream, a little shorter, so it is not only this feature.
• A host window that is not 16:9 shows black bars in the second picture.
• Starting both streams takes a bit longer than starting one.

Merging

• Please use a merge commit. The branch has 21 commits, and its history shows how the library change was built up.
• The moonlight-common-c submodule moves to 02525db, which is on the feat/second-video-stream branch of moonlight-common-c-mic and not yet on its master. Before this merges, that fork's master needs to be fast-forwarded to 02525db, so the pinned commit stays reachable once the branch is deleted.
• app/version.txt is still 6.3.11. A release of this needs a version bump and a tag.

🤖 Generated with Claude Code