Repository navigation
Companion App #656
Unanswered
d4rkside76
asked this question in
Feature requests
Companion App
#656
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Service
F1 TV
What's your idea?
Feature Request: Remote Display / Android TV Companion Mode
Summary
Add a lightweight Remote Display / Companion mode that allows Android TV devices to display MultiViewer layouts configured and managed from the existing Desktop application.
The goal is not to port the full MultiViewer application to Android TV.
Instead, the Desktop application would remain the main control and orchestration point, while an Android TV Companion client would act primarily as a remote display endpoint.
This would make it possible to configure a MultiViewer setup once on the Desktop and then assign that setup to one or more TVs or Android TV-based devices available on the same LAN.
Motivation
MultiViewer already provides a powerful Desktop experience for:
However, there is currently no equivalent client for Android TV.
A common use case would be to create and manage the desired MultiViewer layout from a PC, but display it on a large TV without having to physically connect that TV as a Desktop monitor.
For example:
The Desktop application should remain the source of truth, while Android TV devices behave as lightweight remote displays.
Proposed Concept
The MultiViewer Desktop application would expose a Companion / Remote Display service over the local network.
The Desktop side would remain responsible for:
The Android TV Companion would be responsible only for:
Conceptually:
Reuse of Existing MultiViewer Concepts
This feature appears to fit naturally with functionality that already exists in MultiViewer.
MultiViewer already has concepts such as:
Because of this, a Remote Display implementation may not require introducing an entirely new configuration model.
A saved Desktop setup could effectively become the description of what a remote display should render.
For example:
{ "setup": "Main Race", "canvas": { "width": 1920, "height": 1080 }, "players": [ { "stream": "International Feed", "x": 0, "y": 0, "width": 1280, "height": 720 }, { "stream": "Driver 1", "x": 1280, "y": 0, "width": 640, "height": 360 }, { "stream": "Driver 2", "x": 1280, "y": 360, "width": 640, "height": 360 } ] }The Companion could scale those coordinates to the actual TV resolution while preserving the Desktop-defined layout.
Suggested User Flow
From MultiViewer Desktop:
On Android TV:
Manual IP configuration could also be supported as a fallback if automatic LAN discovery is not available.
Multiple Remote Displays
One Desktop instance should ideally support multiple Companion devices.
Each display could independently receive a different saved setup.
Example:
This would turn MultiViewer into a small multi-display orchestration platform, rather than limiting it to displays physically connected to the Desktop machine.
Synchronization
An important capability would be keeping the Companion playback aligned with MultiViewer's existing synchronization model.
The Desktop could remain authoritative for playback timing and target latency, while Companion clients follow the corresponding state.
This would help keep:
aligned across different remote displays.
Media Transport
The exact media transport should probably remain an implementation decision.
The main purpose of this request is to propose the Remote Display architecture, rather than require a specific streaming mechanism.
Possible implementations could include:
I would specifically avoid requiring the Desktop application to capture and transcode the final layout into HLS, as that would introduce additional GPU/CPU usage, latency, quality loss and potential DRM/HDCP issues.
Ideally, the Companion should render the streams natively while the Desktop provides the configuration, orchestration and synchronization layer.
Possible Companion API
Conceptually, the Desktop could expose something similar to:
or expose equivalent functionality through the existing API layer.
Automatic discovery could optionally use something such as mDNS:
so that Companion devices can find available Desktop instances without requiring manual IP configuration.
Scope of the Android TV Application
The Android TV application should intentionally remain small.
It would not need:
Those actions would stay on Desktop.
The Companion would primarily require:
This should significantly reduce the complexity of supporting Android TV compared with building a complete native MultiViewer client.
Potential Future Extension
Although Android TV is the immediate use case, the same architecture could potentially support other remote display targets later:
This could make Remote Displays a generic MultiViewer capability rather than an Android-specific workaround.
Expected Benefit
This feature would allow users to:
The main concept is:
A lightweight Companion / Remote Display mode could therefore provide Android TV support while reusing as much of the existing MultiViewer architecture as possible.
All reactions