Repository navigation
video: MJPEG at 30 fps next to a video stream up to 1920 wide - #360
Conversation
Next to an H.264 or H.265 stream MJPEG ran at most at 27 fps (its VPSS output at 30), whatever the video size. Up to 1920 wide it now runs at 30 over a VPSS output at 33; next to a wider stream it stays at 25 over 27, where 30 over 33 measured worse. Stand, H.265 straight from capture next to MJPEG at 30: 1280x720 at 120 Hz 107-116 fps, 1920x1080 at 90 Hz 80-85 and at 60 Hz 57-60, 1920x1200 at 60 Hz 59-60 (with #358's pre-submit), about as next to MJPEG at 27. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
dormancygrace
left a comment
dormancygrace
left a comment
There was a problem hiding this comment.
Reviewed 9823918. No actionable findings. The server/native pair changes together from 27/30 to 30/33 for video up to 1920 pixels wide; the wider-stream pair stays 25/27. Lower requested screen rates and standalone MJPEG behavior are preserved. Both sides classify by the encoded video's width, and the server rate remains below the separate VPSS output rate.
Verified the combination with #358 applies cleanly. Local native source/rate contracts and Go common/stream/MJPEG tests passed; #358's native MJPEG/capture probes also passed ASan/UBSan. All 15 CI checks on this exact head succeeded, including full build/hash. No source fixes required. No device measurements by me: the documented shared-output performance trade-off and unmeasured portrait modes remain as stated by the author. Merging after #358.
1 participant
Next to an H.264 or H.265 stream, MJPEG ran at no more than 27 fps over a VPSS output at 30, whatever the video size. With this change, next to a stream up to 1920 wide it runs at 30 over 33. Next to a wider stream it stays at 25 over 27, because 30 over 33 measured worse at 2560 × 1440.
server/service/stream/mjpeg/streamer.go:mjpegNextToVideoFPS27 → 30.kvm_vision.cpp:mjpeg_next_to_video_fps30 → 33. The server rate stays below the VPSS output rate; with the order reversed, the JPEG reader waits for frames.docs/VIDEO.mdare updated.Stand measurements
H.265 straight from capture, with an MJPEG viewer, #358 pre-submit included:
H.264 1080p90 next to MJPEG at 30 ran at 83–87 fps (78–85 next to 27 in the earlier measurement).
The shared 4:2:0 output (MJPEG choice 4:2:0, H.265 1920×1080 @60) is a trade-off:
Not measured: portrait modes. Independent of #358; the measurements above were taken with it.
🤖 Generated with Claude Code