Device testing: UDP, plain RTP and RTSP multicast (#70, #72, #73) #74

Device test round for the transport work: #70 (RTSP over UDP, #67), #72 (plain RTP from Majestic outgoing, #68), #73 (RTSP multicast, #69). Device, cameras, access, adb, builds, smoke script, log lines and pitfalls are in LABORATORY.md (#77); the run format follows #53. Post each run as a comment here (build, commit, result table, findings) and tick the checklist in this body.

Rule: CI builds only, no local builds.

Builds

The three PRs are stacked: #70 → #64 (8 slots), #72 → #70, #73 → #72. Each push run of build.yml leaves an APK artifact:

B=feat/rtsp-multicast
RUN=$(gh run list -R OpenIPC/decoder -b $B -e push -L 1 --json databaseId -q '.[0].databaseId')
gh run download $RUN -R OpenIPC/decoder -n decoder-${B//\//-}

If time is short, test the feat/rtsp-multicast build only: it has all three. Check the commit hash in the menu (Exit [v…, ]).

Bench

Cameras: group A .133, .126, .53 for stream tests, group B only fills grid cells. Details, transport setting (UI and --es transport), udp:// URL forms, log lines and the socket-leak check: LABORATORY.md.

Checklist

#70: RTSP over UDP (#67)

• .133 UDP single view: video + Opus audio, playing over UDP, no packets lost on the LAN
• .126 UDP (H.265 + Opus)
• .53 XM UDP: plays; slot switch away and back, pause/resume still connect (one client only: TEARDOWN must free it)
• Latency UDP vs TCP on .133 (e.g. a stopwatch on the camera's OSD vs screen, or the jitter colour)
• 3×3 grid with all 8 slots on UDP: 8 sessions, no reconnects, UDP sockets count = 2 per track
• Auto on a working camera: stays on UDP
• Auto with UDP blocked: falls back to TCP within ~3 s and stays on TCP after resume. The device has no root; block on the camera if it has iptables (iptables -A OUTPUT -p udp --sport 1024: -j DROP, remove afterwards), else note it as not testable here
• 3× Home → resume and slot changes on UDP: thread count and /proc/<pid>/net/udp do not grow
• Camera restart (/etc/init.d/S95majestic restart) while playing on UDP: reconnects

#72: plain RTP from Majestic outgoing (#68)

• Majestic outgoing destination udp://172.17.32.144:5600 (web UI → Outgoing, or /api/v1/outgoing.json), slot udp://@:5600: video H.264
• Same with video0.codec h265; switch the codec while playing (cli -s .video0.codec h265, restart majestic): the view follows
• Join mid-stream: start the slot after the camera is already sending (picture after the next IDR)
• Camera stops sending (remove the destination): status turns disconnected, comes back by itself when it is added again (no rebind)
• Two cameras to two ports (:5600, :5602) in the grid; two slots on the same port: the second fails visibly (not silent)
• Open question: does Majestic send to a multicast group? Destination udp://239.1.2.3:5600, slot udp://@239.1.2.3:5600. Note the TTL if visible (tcpdump somewhere on the LAN)
• Multicast to the AG-216 over Ethernet; if a Wi‑Fi Android device is available, there too (multicast lock)
• Source filter: udp://<wrong ip>@239.1.2.3:5600 shows nothing, udp://172.17.32.133@… plays

#73: RTSP multicast (#69)

• .133 / .126 with Multicast: multicast SETUP failed (400), plays over TCP at once in the same connection
• .53 with Multicast: 451, plays over TCP (one client: no second connection left open)
• With a server that does RTSP multicast: none in the lab. If possible, run one on the lab host (e.g. mediamtx with multicast enabled, relaying .133) and check: joined …, playing over multicast, video, TEARDOWN on stop. Otherwise mark not testable

After the round

For each PR whose items are all done: comment on the PR with a link to the result here, take it out of draft, and remove awaiting device test. Findings that are not quick fixes get their own issues (time-box ~15 min, as in #53). Leave a build with working cameras installed on the device.