The library actually driving the MS5 turned out to be libWifiCamera.so, part of a protocol family

called i4season ("Suear") — used not just for microscopes but for a whole range of cheap WiFi
otoscopes and endoscopes sold under many brands. That mattered a lot, because it meant I wasn't
starting from zero: Sean Pesce had already written and open-sourced
Suear-Web-Viewer, a clean client for the same
library targeting a different device (a Suear ear-cleaner). His work decoded most of the wire
framing already — the shift from "guessing" to "confirming and adapting" started here.

First proof it applied to the MS5: sending a raw GetDeviceInfo request to UDP :10005 got a real
reply, identifying the camera as vendor MKL, product MS5, firmware ver1221. The camera was
alive and speaking this exact protocol — the earlier "dead device" reading from the bad pcap was
simply wrong.

Then came the wall. Sending the OpenVideo command — the one that's supposed to start the stream —
got a clean acknowledgement every time, and not one video packet ever showed up. An ack with no
data is one of the more annoying failure modes to debug, because it rules out almost nothing:
wrong parameters, licensing, timing, session state, all still on the table.

The answer came from disassembling proOpenVideo itself (arm64) inside libWifiCamera.so: the
client is expected to announce its own UDP receive port inside the OpenVideo request — bind an
ephemeral port, read it back, and send those two bytes as the payload. Skip that step and the
camera acks happily and then has, quite literally, nowhere to send the video. It's not documented
anywhere; it only shows up by reading the code that builds the request. That one detail is what the
whole project hinged on.

Sending OpenVideo with the port produced an immediate 1280×720 MJPEG stream. The first reassembler
had a bug — it grouped chunks by the wrong byte — but once frames were grouped correctly, whole
valid JPEGs came out the other end.