In Appium, how does the live MJPEG screen stream differ on Android and iOS?

## What the MJPEG stream is for A screenshot is a moment and a recording is a file you read afterwards. The **MJPEG stream** sits between them: the driver serves a continuous sequence of JPEG frames over HTTP, and anything that can render a motion-JPEG feed — an inspector window, a dashboard, a capture process — can watch a cattle-auction bidding session as it happens. It is the "live" leg of screen capture, and it is the leg where the two platforms diverge most quietly, because the configuration keys look identical. ## One capability name, two mechanisms `appium:mjpegServerPort` is declared by the UiAutomator2 driver and by the XCUITest driver, and both drivers' parallel-run guidance treats it as a per-session value. That much looks like portability. It is not: - On **Android**, it is a **host-forwarded port**. The frames originate on the device, and the port is the forwarded path from your host machine onto that device-side server. - On **Apple platforms**, it is **WebDriverAgent's own broadcast port** — the agent already running on the device serves the stream directly. So the same capability name configures two different plumbing arrangements. `appium:mjpegScreenshotUrl` is shared in exactly the same way and carries exactly the same caveat. This is the archetype of what platform divergence means on the Appium tree: the token verifies on both sides, and the mechanism behind it does not match. | Concern | Android (UiAutomator2) | Apple (XCUITest) | |---|---|---| | `appium:mjpegServerPort` | host-forwarded port onto the device-side server | WebDriverAgent's own broadcast port | | `appium:mjpegScreenshotUrl` | declared, same forwarding shape | declared, served by the agent | | Shared settings | `mjpegServerFramerate`, `mjpegScalingFactor`, `mjpegServerScreenshotQuality` | the same three names | | Platform-only setting | `mjpegBilinearFiltering` | `mjpegFixOrientation` | | Related capture command | `mobile: startScreenStreaming` | `mobile: startScreenRecording` (ffmpeg over the stream) | ## The settings that tune it, and who owns each The stream's quality and cost are driven by driver settings rather than capabilities, and the overlap is partial: 1. `mjpegServerFramerate` — how many frames per second the stream emits. Declared on both. 2. `mjpegScalingFactor` — how far each frame is scaled down before transmission. Declared on both. 3. `mjpegServerScreenshotQuality` — the JPEG compression applied per frame. Declared on both. 4. `mjpegBilinearFiltering` — smoothing applied when Android frames are scaled. UiAutomator2's, and it does not appear in XCUITest's settings reference. 5. `mjpegFixOrientation` — corrects frame orientation on Apple platforms. XCUITest's, and it does not appear in UiAutomator2's list. XCUITest's settings reference also carries `screenshotQuality`, `screenshotOrientation` and `webScreenshotMode`, which govern the still image rather than the stream. Keeping the still-image settings and the stream settings apart is worth doing deliberately, because three of the MJPEG names read like still-image settings and are not. ## Where the stream is consumed The stream is not only for a human watching a window: - The Android drivers declare `mobile: startScreenStreaming`, a live broadcast command on that side. - XCUITest's `mobile: startScreenRecording` / `mobile: stopScreenRecording` pair is an **ffmpeg capture taken over the MJPEG stream** — a recording built from the live feed rather than from XCTest's own recorder. - An inspector or dashboard can simply point a viewer at the served endpoint while the run continues. That third bullet is why the Apple side has two recorders at all: one is XCTest-native (`mobile: startXCTestScreenRecording`) and one is derived from the stream. If you tune the stream down to save bandwidth and then record through the stream-based path, you have also tuned your video down — a coupling that surprises people. ## Choosing between a still, a stream and a recording Each costs something different, and the choice is a mechanism question before it is a policy question: - A **still** is one `GET /session/:sessionId/screenshot` call, cheap, and identical on both platforms. - A **stream** is continuous and its cost is ongoing for the whole session, tuned by framerate, scaling and quality. - A **recording** is a discrete artefact whose command names differ per platform and whose payload arrives from the stop call. A suite that wants to watch a long cattle-auction bidding run live wants the stream; a suite that wants an artefact attached to a failing case wants a still, a recording, or both. The mistake worth avoiding is assuming that because `appium:mjpegServerPort` reads the same in both capability sets, the thing behind it is the same on both devices. It is not.