Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
screenrecord --with-webcam: overlay locks to YUYV @5fps instead of MJPG @30fps at 1280x720
Reported by ottosilva · filed Aug 17, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- AreaOutside the audited area· Decided by agents · verified
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Decided by agents and verified by a second, independent agent — see the decision.
Original report
System details
AMD Ryzen AI 7 350 w/ Radeon 860M / AMD Radeon 860M Graphics
Omarchy 4.0.0-1
Webcam: USB2.0 FHD UVC WebCam (uvcvideo driver)
What's wrong?
omarchy screenrecord --with-webcam starts the webcam overlay via mpv with:
--demuxer-lavf-o=video_size=1280x720,framerate=30No input_format is specified, so ffmpeg's v4l2 demuxer is left to choose the pixel format on its own. On this webcam it picks YUYV (raw), which only supports 1280x720 at 5 fps on this device — even though the same resolution is available at 30 fps in MJPG. The result is a visibly choppy webcam overlay in every recording, regardless of the --webcam-size chosen.
Confirmed by querying the device directly while the overlay's mpv process has it open:
$ v4l2-ctl -d /dev/video0 --get-fmt-video
Pixel Format : 'YUYV' (YUYV 4:2:2)
$ v4l2-ctl -d /dev/video0 --get-parm
Frames per second: 5.000 (5/1)Device's own format list (v4l2-ctl --list-formats-ext -d /dev/video0) shows MJPG at 1280x720 supports 30fps, while the YUYV variant at the same resolution caps at 5fps:
[0] (MJPG-type, compressed):
1280x720 @ 30fps
[1] 'YUYV' (YUYV 4:2:2):
1280x720 @ 5fps <-- what actually gets selectedWhat's expected
The overlay should request the compressed/MJPG format explicitly so it gets the 30fps mode the hardware actually supports at that resolution, e.g. adding input_format=mjpeg to the --demuxer-lavf-o string in omarchy-capture-screenrecording's start_webcam_overlay():
--demuxer-lavf-o=video_size=1280x720,framerate=30,input_format=mjpegI tested this manually — killing the running overlay mpv process and relaunching it with input_format=mjpeg appended immediately fixes it: the device switches to MJPG and reports a real 30fps, and the overlay is visibly smooth instead of choppy.
Steps to reproduce
omarchy screenrecord --fullscreen --with-webcam(webcam with a UVC device that has a raw/YUYV mode capped at a low fps for 720p/1080p, alongside an MJPG mode that supports 30fps at the same resolution — common on USB UVC webcams)- Watch the webcam overlay bubble — it's visibly laggy/low framerate
- Confirm with
v4l2-ctl -d /dev/videoN --get-parmwhile recording — shows 5fps instead of the requested 30fps
Suggested fix
In omarchy-capture-screenrecording, add input_format=mjpeg to the capture_options built in start_webcam_overlay(), or probe v4l2-ctl --list-formats-ext for the pixel format that actually delivers the target fps at the chosen resolution before launching mpv.
View raw text
### System details AMD Ryzen AI 7 350 w/ Radeon 860M / AMD Radeon 860M Graphics Omarchy 4.0.0-1 Webcam: `USB2.0 FHD UVC WebCam` (uvcvideo driver) ### What's wrong? `omarchy screenrecord --with-webcam` starts the webcam overlay via `mpv` with: ``` --demuxer-lavf-o=video_size=1280x720,framerate=30 ``` No `input_format` is specified, so ffmpeg's v4l2 demuxer is left to choose the pixel format on its own. On this webcam it picks **YUYV** (raw), which only supports 1280x720 at **5 fps** on this device — even though the same resolution is available at **30 fps in MJPG**. The result is a visibly choppy webcam overlay in every recording, regardless of the `--webcam-size` chosen. Confirmed by querying the device directly while the overlay's `mpv` process has it open: ``` $ v4l2-ctl -d /dev/video0 --get-fmt-video Pixel Format : 'YUYV' (YUYV 4:2:2) $ v4l2-ctl -d /dev/video0 --get-parm Frames per second: 5.000 (5/1) ``` Device's own format list (`v4l2-ctl --list-formats-ext -d /dev/video0`) shows MJPG at 1280x720 supports 30fps, while the YUYV variant at the same resolution caps at 5fps: ``` [0] (MJPG-type, compressed): 1280x720 @ 30fps [1] 'YUYV' (YUYV 4:2:2): 1280x720 @ 5fps <-- what actually gets selected ``` ### What's expected The overlay should request the compressed/MJPG format explicitly so it gets the 30fps mode the hardware actually supports at that resolution, e.g. adding `input_format=mjpeg` to the `--demuxer-lavf-o` string in `omarchy-capture-screenrecording`'s `start_webcam_overlay()`: ``` --demuxer-lavf-o=video_size=1280x720,framerate=30,input_format=mjpeg ``` I tested this manually — killing the running overlay `mpv` process and relaunching it with `input_format=mjpeg` appended immediately fixes it: the device switches to MJPG and reports a real 30fps, and the overlay is visibly smooth instead of choppy. ### Steps to reproduce 1. `omarchy screenrecord --fullscreen --with-webcam` (webcam with a UVC device that has a raw/YUYV mode capped at a low fps for 720p/1080p, alongside an MJPG mode that supports 30fps at the same resolution — common on USB UVC webcams) 2. Watch the webcam overlay bubble — it's visibly laggy/low framerate 3. Confirm with `v4l2-ctl -d /dev/videoN --get-parm` while recording — shows 5fps instead of the requested 30fps ### Suggested fix In `omarchy-capture-screenrecording`, add `input_format=mjpeg` to the `capture_options` built in `start_webcam_overlay()`, or probe `v4l2-ctl --list-formats-ext` for the pixel format that actually delivers the target fps at the chosen resolution before launching `mpv`.
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Out of scopeDecided by agents · verified · 2026-10-09 04:36 UTC