Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Draft
wants to merge 23 commits into
base: main
Choose a base branch
from

Conversation

tintou
Copy link
Member

@tintou tintou commented Jan 27, 2022

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
Copy link
Contributor

cassidyjames commented Feb 3, 2022

@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.

Copy link
Collaborator

@jeremypw jeremypw left a comment

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
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
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
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
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
Copy link
Collaborator

jeremypw commented May 2, 2022

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
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
Copy link
Collaborator

jeremypw commented May 2, 2022

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
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
Copy link
Collaborator

jeremypw commented Jun 3, 2022

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
Copy link
Collaborator

jeremypw commented Jun 3, 2022

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

@jeremypw
Copy link
Collaborator

jeremypw commented Jun 5, 2022

@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
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
Copy link
Collaborator

jeremypw commented Jun 6, 2022

@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
Copy link
Collaborator

jeremypw commented Aug 8, 2022

@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
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
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
Copy link
Collaborator

jeremypw commented Feb 9, 2023

@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