Fix MJPEG fallback when capture rate is below requested output - #59
Draft
steveseguin wants to merge 2 commits into
Draft
steveseguin wants to merge 2 commits into
steveseguin wants to merge 2 commits into
Conversation
|
|
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When a V4L2 camera advertises only a lower MJPEG frame rate than requested (for example, 15 fps capture and the default 30 fps output), the fallback removes the source-rate constraint but then requires fixed 30 fps output through
videorate drop-only=true. A drop-only converter cannot produce that higher cadence, so negotiation fails and video does not start.Change
Remove
drop-only=truefrom the decoded MJPEG rate fallback, preservingmax-rateand the requested output caps. Videorate can duplicate decoded frames when capture is slower and drop frames when it is faster. Adjust the diagnostic to describe rate conversion. Native H.264 passthrough remains unconstrained rather than modifying compressed frames.Add one focused regression to the existing capture-mode test module, with 15/30/60 fps synthetic MJPEG subcases. It evaluates the actual fallback fragment from
main, avoiding a duplicated implementation and any camera or signaling startup.Verification
not-negotiated (-4); fixed 15→30, 60→30 and source-supported 30→30 reach EOS.gi; the complete application test suite has not passed locally. Compatibility CI passed all 151 tests, including the added native regression, on Bullseye/Python 3.9/GStreamer 1.18, Bookworm/3.11/1.22, and Trixie/3.13/1.26 at final head0b5c4c46665be14230f0570f22b03440f043479c.Reviewed against main
4f94ca2dcfced9f67eb72acf4102518cd3ef6674. No physical camera, remote board, live media, external signaling, merge or deployment was used. Native synthetic media establishes rate negotiation only; this is not a hardware or end-to-end interoperability claim. This is independent of recording fixes #57 and #58.