ustreamer: reduce camera memory by ~1.6 MiB PSS at 864x480/8 FPS - #255
ustreamer: reduce camera memory by ~1.6 MiB PSS at 864x480/8 FPS#255pdscomp wants to merge 2 commits into
Conversation
Feedback from @suchmememanyskill
|
Add the CC1-targeted uStreamer memory reduction patch to the Yocto recipe. It bounds frame/thread allocations, retains only the newest JPEG, avoids the permanent blank RGB canvas, and falls back from USERPTR to MMAP when the UVC camera rejects USERPTR. Validated on the CC1 over a four-day burn-in with two clients connected and no crashes.
✅ Build ArtifactsBranch:
|
|
Thanks for the review. I agree this patch is broad and exploratory in places, so I want to clarify the goal and the risk profile. uStreamer is a non-essential printer component, and rollback is trivial: the service can be disabled or the recipe patch can be reverted without affecting printing, Klipper, or Moonraker. That makes it a reasonable place to try several narrowly targeted memory reductions while we have a reproducible CC1 workload. The common goal for every change here is reducing uStreamer’s PSS and RSS. During the investigation, the individual changes generally moved memory usage by roughly 100 KiB or more, and the combined result was:
The main finding was that uStreamer’s capture/processing pipeline retained multiple copies of frame buffers for throughput. The camera is already configured for low resolution and roughly 10 FPS, so that optimization is a poor trade on a 128 MiB appliance. The kernel/V4L2 capture path also reserves approximately 1.8 MiB per buffer even though the camera’s compressed MJPEG frames are usually only 20–30 KiB. Retaining several of those buffers therefore costs more than 3 MiB of scarce RAM for very little practical benefit. Keeping only the newest frame and allowing HTTP delivery to borrow it safely is where much of the improvement comes from. The patch also keeps the camera-specific fallback behavior: the CC1 UVC device rejects USERPTR queueing, so the implementation retries with MMAP and remains functional. Snapshots and live video were verified on the target. Based on this feedback, I reverted the 10→8 FPS change. The memory reduction patch can therefore be evaluated independently while retaining the existing 10 FPS deployment setting. If useful, I can further split the C patch into smaller commits, but the changes are all aimed at the same measurable objective: reducing uStreamer’s resident memory footprint on the CC1. |
|
Flashed and tested ustreamer is running and serving snapshots + live stream: Measured from
These are absolute numbers from the patched build |
1 participant
ustreamer: reduce camera memory by ~1.6 MiB PSS at 864x480
Split from #252.
Why this PR
uStreamer is always on. On a 128 MiB machine, cutting its resident set by a third frees real headroom for calibration and printing without losing the snapshot/live-view workflow.
Justification / measurements (isolated, live CC1, active 864x480 client)
Commit
1d791e3ustreamer: reduce camera streamer memory useRisk / rollback
Low. Config revert restores previous command line; USERPTR attempt safely falls back to MMAP on cameras that reject it (validated on the CC1 UVC camera).