CameraView: Allow to change the camera resolution and framerate

[tintou]

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

[cassidyjames]

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

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.

[jeremypw]

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]

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]

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.

[jeremypw]

Having problems resolving conflicts with master ...

[jeremypw]

Just found a bug so converting back to draft.

[danirabbit]

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]

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]

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

[jeremypw]

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

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

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

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

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

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

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