Share your camera with another streamer
This release adds Share my feed to SHXRM Studio. Your encoder publishes to your streaming PC as usual. Your friend receives the selected camera as an OBS Media Source, then broadcasts through their own Twitch, Kick or YouTube account. You can continue broadcasting on your own channel at the same time.
Set up your friend's network access first
Read the official Tailscale guide: https://tailscale.com/docs/features/sharing
Since you already use Tailscale, share your streaming PC device with your friend's Tailscale account from the Tailscale admin console. They install/sign in to Tailscale on the PC running their OBS and accept the device share. Your device sharing/access policy must allow them to reach your streaming PC on UDP port 8890; Windows Firewall must also allow MediaMTX's SRT traffic. Creating a SHXRM feed share does not automatically create a Tailscale device invitation or change either firewall.
In Studio, open Ingests → Ingest network, enter your streaming PC's Tailscale IPv4 address (the 100.x.x.x address), and click Save network. Use this same network address for outgoing shares. The Set network address button in Share my feed opens Ingests. A reachable hostname or other network address can also be used when your routing supports it. An ordinary public IP does not work automatically behind a home router; the route still has to exist.
Two separate permissions are needed: network access to your streaming PC, and the private camera viewing URL generated by SHXRM. The friend does not need your Studio owner login, publishing key, OBS password or platform stream key.
Create a private connection
- Start MediaMTX in Connections and start your camera feed as usual.
- Open Share my feed.
- Enter your friend's name and select My IRL camera, or another connected ingest you are authorized to share.
- Click Create private share. A share can be created while its enabled camera is offline, but cannot transmit until the camera returns.
- Click OBS connection on that friend's card.
- Click Copy full instructions and send that text privately to your friend. The toolkit does not send it for you.
Each friend gets a different read-only credential and a private relay path. A share reads only its selected camera. It cannot publish a camera, view another friend's alias, operate OBS or access the Studio dashboard. You can keep up to 16 recipients in the manager; this is an app limit, not a promise that your connection can sustain 16 concurrent feeds.
In your friend's OBS
Read the official OBS receiving guide: https://obsproject.com/kb/srt-protocol-streaming-guide
- In the desired scene, choose Sources → + → Media Source and name it, for example,
Sherm IRL camera. - Uncheck Local File.
- Paste the generated SRT viewing URL into Input.
- Set Input Format to
mpegts. - Set Reconnect Delay to 2 seconds. If they need a continuous receiver even when changing scenes, leave Close file when inactive off. Available options depend on their OBS version.
- Fit the source to their canvas and check the source's audio in the OBS mixer.
- They start their own broadcast using their own platform connection. They do not put the viewing URL in OBS's stream-destination settings.
The generated connection uses caller mode, approximately one second of SRT transport latency and a five-second connection/read timeout. Total camera-to-viewer latency also includes the original phone ingest, local relay, decoding, OBS encoding and the destination platform. Their OBS should retry interrupted connections through its Media Source reconnect setting; actual OBS/Windows recovery still needs an equipment test.
What the buttons mean
| Control/state | Behavior |
|---|---|
| Create private share | Creates one recipient's private read-only camera connection. Does not start their OBS or send them a message. |
| OBS connection | Shows the viewing URL and instructions. Connection credentials disappear from the dialog when closed. |
| Disconnect | Removes this recipient's access and closes its active receiving connections. The underlying camera and other recipients continue. |
| Connect | Restores this recipient's access. Their saved URL works again unless the key was reset. |
| Reset key | Generates a new private key and closes connections using the old key. Copy the new OBS connection for your friend. |
| Remove | Deletes the recipient's share and revokes that connection. |
| Waiting for your camera | Access exists, but the source is offline. |
| Ready · waiting for friend's OBS | Source is online, but no receiver is currently connected to this share. |
| Friend receiving feed | MediaMTX reports an online relay with one or more receiving connections. This does not prove their platform is live. |
| Source disconnected | The selected ingest has been disabled. Its outgoing aliases also stop. Reconnect the source to restore an enabled share. |
| Status unavailable | Live server status is stale; the app does not claim the friend is receiving. |
If you remove an incoming guest camera that has outgoing shares, remove its shares first. This prevents orphaned connections pointing at a deleted source. Disabled shares retain their name and key for later Connect. Resetting a key while disconnected keeps the share disconnected.
What is shared
The selected camera's original video and audio are relayed without re-encoding. Your local SHXRM OBS overlays, scene changes, desktop content, BRB screen and final program output are not part of this camera share. Your friend's OBS controls what their audience sees and should have its own BRB/fallback scene for camera dropouts. SHXRM's existing protection continues to control your own OBS broadcast.
your streaming PC must be awake, MediaMTX running, and the camera publishing. Each actively receiving OBS connection uses additional upload bandwidth from your streaming PC. For example, two recipients receiving a roughly 6 Mbps camera need roughly 12 Mbps of extra upload plus protocol overhead; your own platform stream and other traffic are additional. The local camera relay is activated when a recipient connects.
Access protection
On first sharing a camera, anonymous remote reads of its original path are restricted to loopback. Existing remote direct readers are closed so they cannot bypass the new private viewing connection. Publishing permissions remain available to the original encoder; local OBS and dashboard reads continue. If you used an old anonymous remote camera URL, replace it with a managed share. The local-only anonymous read policy remains after the last share is removed. Unrelated explicitly configured authenticated MediaMTX accounts retain their existing access.
The source relay uses a separate loopback-only reader credential; recipient URLs never include that credential. Recipient passwords are hashed in MediaMTX configuration and saved in Config/ingests.json so the owner can copy them again. Keep that Windows configuration file private. The app supports the toolkit's MediaMTX internal authentication and local RTSP relay; custom external authentication and strict RTSPS-only configurations are reported as unsupported rather than overwritten.
This app does not publicly expose your dashboard, configure a cloud server, or change Tailscale policy. A copied viewing URL is a credential: anyone who has both that URL and permitted network access can receive the camera until you revoke it.
Verification
Real local MediaMTX 1.21.1 and FFmpeg tests verified two simultaneous recipients decoding video and audio, read-only isolation, wrong-key rejection, independent disconnect/connect/reset/remove, coexistence with private incoming guests, source disablement and persistence across a MediaMTX restart. Chromium checked all sharing buttons, clipboard copy and desktop/mobile layouts. Your friend's real OBS, Tailscale path, Windows firewall and end-to-end platform broadcast still need a test on your equipment.
Official protocol reference: https://mediamtx.org/docs/read/srt
Download this guide as text