Fix photo resolution, recording quality, and blank preview for raw-only cameras - #307
Closed
PlugMyLife wants to merge 3 commits into
Closed
Fix photo resolution, recording quality, and blank preview for raw-only cameras#307PlugMyLife wants to merge 3 commits into
PlugMyLife wants to merge 3 commits into
Conversation
Cameras that expose no image/jpeg caps (e.g. the PCIe FaceTime HD in 2015 MacBook Pros using the out-of-tree facetimehd driver) always fell back to 640x480, and photos from 16:9-only sensors were stretched to 4:3. Scan video/x-raw structures too so photos use the sensor's native resolution. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
vp8enc's defaults (256 kbps target bitrate, best-quality deadline) cannot encode HD webcam streams in real time. The encoder falls behind, the leaky preview queue drops frames, and recordings come out choppy at extremely low quality (measured ~80 kbps for 720p30). Use the realtime deadline, spread work across the available CPU cores, and scale the target bitrate with the frame size (~3.7 Mbps at 720p). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Every element in the recording path reports a missing-plugin message, but the preview sink was used unchecked. On systems without the GTK4 GStreamer plugin the preview silently stayed black while photos and recording kept working. Prompt for plugin installation and surface the existing 'Unable To View Camera' dialog instead. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Member
|
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.
What this does
Three small fixes to
CameraView.vala(20 lines total), each independent:Consider raw caps when picking photo resolution. Photo sizing only
inspected
image/jpegcapabilities. A camera that exposes only rawformats always fell through to the 640×480 default, and photos from a
16:9-only sensor were stretched to 4:3. Now
video/x-rawstructuresare scanned too, so photos use the sensor's native resolution.
Configure
vp8encfor realtime capture. The encoder was createdwith its defaults (256 kbps target, best-quality/slowest deadline),
which can't encode an HD stream in real time — the encoder falls
behind, the leaky preview queue drops frames, and recordings come out
choppy at ~80 kbps for 720p30. This sets the realtime deadline,
spreads work across the available CPU cores, and scales the target
bitrate with frame size (~3.7 Mbps at 720p).
Handle a missing
gtk4paintablesink. Every element in therecording path reports a missing-plugin message, but the preview sink
was used unchecked. Without the GTK4 GStreamer plugin the preview
silently stayed black while photos and recording kept working. This
adds the same missing-plugin handling and surfaces the existing
"Unable To View Camera" dialog.
Why
I hit all three on a 2015 MacBook Pro (MacBookPro11,4), whose FaceTime HD
webcam is a PCIe device driven by the out-of-tree
facetimehd driver and exposes
only raw (non-JPEG) formats. The bugs are general, though — any raw-only
camera hits #1 and #2, and #3 affects any host missing the GTK4 sink.
Before / after (measured on that machine)
Testing
Built against current
main(meson+ninja, compiles clean) and runon the hardware above: photos now save at native resolution, recordings
are smooth, and removing the GTK4 sink produces the error dialog instead
of a black screen.