Investigate camera SoftAP multicast / multi-client live view

[erik-sutton95]

Investigate whether more than one client can watch Pocket live view at once — camera SoftAP multicast, or a phone-side relay.

Settings already say: “A second-screen watcher relay is not in this build. One phone talks to one Pocket.”

Related: Live streaming · Connection reliability audit · roadmap index

What we know

• Live media is unicast UDP 9004 to 192.168.2.1, pktType 0x02
• One UDP 5-tuple; the camera has no second media port (docs/connection-reliability-plan.md)
• 0x09/0xa8 is live-start and the only PLI — a second client spamming enable will reset the GOP and black both feeds
• No multicast / NDI / SRT / Bonjour code in this repo

Investigation (do this before any UI)

• Two phones on the camera AP: does a second 0x09/0xa8 steal or duplicate the stream?
• Packet capture: multicast/broadcast destination, or strictly unicast to the first client?
• If unicast-only: can the operator phone re-encapsulate HEVC/AVC to a watcher on another interface (personal hotspot / Ethernet / LAN) without leaving the camera AP?
• iOS dual-interface reality: joining SoftAP usually drops cellular. Document the actual backhaul options (Android may be easier here)
• Passcode / control-request stubs in Operator Setup → Sharing already exist as “not in this build” — keep them parked until the path is real

Likely outcomes

1. Camera will not multicast — close camera-LAN multi-client as won't-do
2. Phone-as-encoder relay — separate architecture (operator stays on SoftAP, watchers on another network). That is not camera multicast.
3. Keep 1:1 until feed watchdog is boring on a single client

Do not

• Send 1 Hz live-enable from a second client “to try”
• Tear UDP because a SET timed out
• Promise NDI/SRT in the same breath as this investigation

Done when

docs/protocol-notes.md has a short “one client vs many” note with capture evidence, and we either file a relay follow-on or mark camera multicast won't-do.

Concrete threads: YouTube/Twitch · reliability audit

[erik-sutton95]

Tracked as maintainer spike #86.