Skip to content

CameraView: Allow to change the camera resolution and framerate - #224

Draft
tintou wants to merge 23 commits into
mainfrom
tintou/caps-choice
Draft

CameraView: Allow to change the camera resolution and framerate#224
tintou wants to merge 23 commits into
mainfrom
tintou/caps-choice

Conversation

@tintou

@tintou tintou commented Jan 27, 2022

Copy link
Copy Markdown
Member

Add a popover to the camera view to change the resolution and framerate.

Add a popover to the camera view to change the resolution and framerate.
@tintou
tintou force-pushed the tintou/caps-choice branch from 5f795d6 to c711567 Compare January 27, 2022 23:29
@cassidyjames

cassidyjames commented Feb 3, 2022

Copy link
Copy Markdown
Contributor

@tintou this seems functional to start. I think UI-wise it would make sense to move it to the existing Settings menu. I'm not sure what the least-bad way to present all those options (that most people shouldn't have to change!) is. My initial thought to not overwhelm the popover is a combobox but I don't love it.

@jeremypw jeremypw left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Recent changes to master conflict with this PR as it stands. In particular, secondary clicking on the view now takes a photo - it does not trigger the resolution popover. So either that change must be reverted or the resolution menu be added to the AppMenu button (or its own button?) instead.

When I disabled taking a photo with a secondary click then the popover showed as expected. Clicking on most options changed the resolution of the view as expected but did not close the popover so the effect was partially obscured by the popover. I think it would be better to close the popover after resolution selection but that is a UX decision.

I noticed that some entries appeared duplicate (presumably some other capability was different) and at least one of the lower resolution options consistently caused the view to freeze after which changing the resolution back did not restart the pipeline.

@jeremypw

Copy link
Copy Markdown
Collaborator

For now I have put the resolution menu in a separate headerbar button as I am uncertain of the best way to include a fairly long list of resolutions in the AppMenu popover. I have removed most of the duplicates by showing only video capabilities but I notice from the screenshot that there is still one apparent duplicate. Investigating.

CameraResolutionHeaderBar

@jeremypw

Copy link
Copy Markdown
Collaborator

Using gst-device-monitor-1.0 in a terminal there appears to be two identical structures in my cameras video capabilities:

Device found:

	name  : Video Capture 3
	class : Video/Source
	caps  : video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)720, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction){ 10/1, 10/1 };
	        video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)720, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction){ 10/1, 10/1 };
	        video/x-raw, format=(string)YUY2, width=(int)640, height=(int)480, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1;
	        video/x-raw, format=(string)YUY2, width=(int)640, height=(int)360, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1;
	        video/x-raw, format=(string)YUY2, width=(int)352, height=(int)288, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1;
	        video/x-raw, format=(string)YUY2, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1;
	        video/x-raw, format=(string)YUY2, width=(int)176, height=(int)144, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1;
	        video/x-raw, format=(string)YUY2, width=(int)160, height=(int)120, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1;
	        image/jpeg, width=(int)1280, height=(int)720, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction){ 30/1, 30/1 };
	        image/jpeg, width=(int)1280, height=(int)720, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction){ 30/1, 30/1 };
	        image/jpeg, width=(int)640, height=(int)480, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1;
	        image/jpeg, width=(int)640, height=(int)360, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1;
	        image/jpeg, width=(int)352, height=(int)288, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1;
	        image/jpeg, width=(int)320, height=(int)240, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1;
	        image/jpeg, width=(int)176, height=(int)144, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1;
	        image/jpeg, width=(int)160, height=(int)120, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)30/1;
	properties:
		udev-probed = true
		device.bus_path = pci-0000:00:14.0-usb-0:8:1.0
		sysfs.path = /sys/devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/video4linux/video0
		device.bus = usb
		device.subsystem = video4linux
		device.vendor.id = 04f2
		device.vendor.name = "Chicony\\x20Electronics\\x20Co.\\x2cLtd."
		device.product.id = b59e
		device.product.name = "Video\ Capture\ 3"
		device.serial = Chicony_Electronics_Co._Ltd._Chicony_USB2.0_Camera_200901010001
		device.capabilities = :capture:
		device.api = v4l2
		device.path = /dev/video0
		v4l2.device.driver = uvcvideo
		v4l2.device.card = "Video\ Capture\ 3"
		v4l2.device.bus_info = usb-0000:00:14.0-8
		v4l2.device.version = 331027 (0x00050d13)
		v4l2.device.capabilities = 2225078273 (0x84a00001)
		v4l2.device.device_caps = 69206017 (0x04200001)

Should these be de-duplicated?

@jeremypw
jeremypw marked this pull request as draft February 15, 2022 10:39
@jeremypw

Copy link
Copy Markdown
Collaborator

The last commit makes the preview resolution independent of the photo capture resolution but follows the video capture resolution when in video mode.

When in photo mode, the preview resolution framerate is kept to at least a minimum (currently set to 10fps).

@jeremypw
jeremypw marked this pull request as ready for review February 17, 2022 14:36
@jeremypw
jeremypw dismissed their stale review February 17, 2022 14:37

Changes made

@jeremypw

Copy link
Copy Markdown
Collaborator

I think this is ready for functional review now. Final UX to be decided. Tbh I think the code could be improved by moving most control functions into MainWindow to make it easier to coordinate the view and the headerbar. But I do not want to increase the diff further in this PR.

@danirabbit
danirabbit removed the request for review from cassidyjames April 26, 2022 22:27
@jeremypw
jeremypw requested a review from a team May 1, 2022 17:21
@jeremypw
jeremypw marked this pull request as draft May 2, 2022 08:10
@jeremypw

jeremypw commented May 2, 2022

Copy link
Copy Markdown
Collaborator

Having problems resolving conflicts with master ...

@jeremypw
jeremypw marked this pull request as ready for review May 2, 2022 17:24
capsfilter.get_static_pad ("src").add_probe (Gst.PadProbeType.EVENT_BOTH, (pad, info) => {
unowned Gst.Event? event = info.get_event ();
if (event.type == Gst.EventType.CAPS) {
//TODO Find correct resolution index and update action state.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have inserted a placeholder here as the existing code did not seem to be working and I am not sure under what circumstances this event would get triggered other than through user interaction with the app (which is already catered for).

@jeremypw
jeremypw marked this pull request as draft May 2, 2022 17:40
@jeremypw

jeremypw commented May 2, 2022

Copy link
Copy Markdown
Collaborator

Just found a bug so converting back to draft.

@jeremypw
jeremypw marked this pull request as ready for review May 2, 2022 18:21
@danirabbit danirabbit mentioned this pull request Jun 3, 2022
# Conflicts fixed in:
#	src/Widgets/CameraView.vala
@jeremypw
jeremypw requested a review from danirabbit June 3, 2022 17:42
@danirabbit

Copy link
Copy Markdown
Member

This seems to work as expected, but I can't really confirm a noticeable improvement in performance here. I'm still getting stuttering even at low resolutions. Is that something you're experiencing @jeremypw ?

@jeremypw

jeremypw commented Jun 3, 2022

Copy link
Copy Markdown
Collaborator

I have regarded and tested this as mainly aiming at providing different resolutions of the saved photo or video. Maybe problems with stuttering can be dealt with separately?

@jeremypw

jeremypw commented Jun 3, 2022

Copy link
Copy Markdown
Collaborator

I can't say I I've noticed significant stuttering. Is this something this PR introduced?

@jeremypw

jeremypw commented Jun 5, 2022

Copy link
Copy Markdown
Collaborator

@danrabbit I can confirm that video stutters using master so this does not seem to be related to this PR (which does not claim to fix this issue).

@danirabbit

Copy link
Copy Markdown
Member

@jeremypw yeah as far I understand the goal of selecting a different camera resolution was to improve performance, especially with higher resolution cameras which were basically unusable. I'm not really sure of the value of reducing the resolution of the saved photo or video outside of that context?

@jeremypw

jeremypw commented Jun 6, 2022

Copy link
Copy Markdown
Collaborator

@danrabbit I was thinking that maybe e.g. for posting on the web a lower resolution/framerate might be desirable (not such a problem these days I guess). The poor performance seems to be related to something else since this PR does not fix it.

@jeremypw

jeremypw commented Aug 8, 2022

Copy link
Copy Markdown
Collaborator

@danrabbit Is this PR of sufficient value as is to be merged, or do you want it to fix the performance issue as well?

@tintou Would welcome your input as I have amended your original PR somewhat.

@danirabbit

Copy link
Copy Markdown
Member

@jeremypw I'm not sure what the point of lowering the camera frame rate or resolution would be if it doesn't improve performance. I don't think anybody had requested that as a feature. My understanding is that this branch was an attempt at resolving performance issues, so since it doesn't do that it's probably not worth merging imo

@jeremypw

Copy link
Copy Markdown
Collaborator

@danrabbit OK, I'll look into the performance issue more closely. I am a bit surprised that choosing a high frame-rate mode over a low frame-rate mode does not improve performance though.

@jeremypw
jeremypw marked this pull request as draft August 10, 2022 18:26
@jeremypw

jeremypw commented Feb 9, 2023

Copy link
Copy Markdown
Collaborator

@tintou I do not really want to pursue this PR any further. Maybe better start afresh with a focus on performance improvement, which seems to be key and which this PR does not solve. I'll leave it to you to close it if you do not want to pursue either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants