After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 522200 - Have preference window to select/switch video device and select resolution
Have preference window to select/switch video device and select resolution
Status: RESOLVED FIXED
Product: cheese
Classification: Applications
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: Cheese Maintainer(s)
Cheese Maintainer(s)
: 514448 524668 526356 (view as bug list)
Depends on: 512342
Blocks:
 
 
Reported: 2008-03-13 10:15 UTC by Sjoerd Simons
Modified: 2008-09-03 08:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proof of concept preferences dialog (with basic resolution changing) (75.40 KB, patch)
2008-04-13 07:11 UTC, James Liggett
committed Details | Review
Webcam select combo box patch (28.39 KB, patch)
2008-06-18 22:51 UTC, Ryan Zeigler
committed Details | Review

Description Sjoerd Simons 2008-03-13 10:15:43 UTC
My box has various video devices: a tv card, mpeg encoder card and from time to time a webcam.

It would be nice if i could easily switch between those. Editting gconf isn't very user-friendly :)
Comment 1 Jaap A. Haitsma 2008-03-13 10:25:22 UTC
Making the bug broader

A preference dialog that has
1) A selection of the camera you want to use
2) Resolution for taking a photo
3) Framerate for taking photo
4) Resolution for shooting videos
5) Framerate for shooting videos
6) An option to horizontally flip the video 
7) An option to vertically flip the video 
8) Option to set the video format, when we have that option in cheese webcam

Work on selecting resolution is already going on in bug 512342
Comment 2 Sjoerd Simons 2008-03-13 10:36:49 UTC
Framerate for taking photos is a bit odd.. I guess you mean display framerate.

What i'm personally more looking for is something to switch quickly between cameras without being bother too much with other details.

One of the nasty decisions for a bigger dialog is imho which things should be camera specific and which global.. for example my webcam might not be able to do the framerate/resolution my tv-card has
Comment 3 daniel g. siegel 2008-03-13 12:27:02 UTC
jaap, i think thats just too much.

in my opinion we just would need:

1) A selection of the camera you want to use
2) Resolution for taking a photo
4) Resolution for shooting videos
8) Option to set the video format, when we have that option in cheese webcam

maybe the flip too...
Comment 4 James Liggett 2008-03-13 23:21:21 UTC
(In reply to comment #3)
> jaap, i think thats just too much.
I'm afraid I agree with Daniel here; we should keep this as simple as possible.


> in my opinion we just would need:
> 
> 1) A selection of the camera you want to use
> 2) Resolution for taking a photo
> 4) Resolution for shooting videos
> 8) Option to set the video format, when we have that option in cheese webcam
> 
> maybe the flip too...
Don't we have a video effect for that? Why duplicate the effort? 

Comment 5 Jaap A. Haitsma 2008-03-27 21:44:02 UTC
*** Bug 524668 has been marked as a duplicate of this bug. ***
Comment 6 Jaap A. Haitsma 2008-03-27 21:52:40 UTC
Frame rate for pictures was indeed a mistake. Not really needed we can just select the highest available upto say 30Hz

Framerate for video should be selectable in my opinion because it's a very important parameter for quality.

The idea for the flipping arose in some conversation because we had some bug reports about cameras doing flipping by mistake. This way you can correct it. But we can leave it out.
Comment 7 daniel g. siegel 2008-03-31 16:44:22 UTC
*** Bug 514448 has been marked as a duplicate of this bug. ***
Comment 8 Michael Monreal 2008-04-06 19:44:12 UTC
+1 for flipping as a preference. I actually filed a request for this in bug 526356.
Comment 9 daniel g. siegel 2008-04-12 16:27:17 UTC
*** Bug 526356 has been marked as a duplicate of this bug. ***
Comment 10 James Liggett 2008-04-13 07:11:04 UTC
Created attachment 109162 [details] [review]
Proof of concept preferences dialog (with basic resolution changing)

This is a simple proof of concept patch to demonstrate the ideas that I laid out in my RFC to cheese-list on this topic. It should be enough to serve as a base to do all that we want to do with this; we just have to create the proper widget synching classes and extend other parts of cheese to support things like multiple devices, etc. 

Some notes:
- Right now I only support one resolution type. However, I have laid the groundwork here to support separate ones for photos and videos, at least from the perspective of the preferences dialog itself. To actually make this work, we are going to need to make extensive changes to CheeseWebcam, most of which I probably don't even know about yet. :) We should discuss how we're going to do this...

- Notice that I maintain the GtkBuilder UI description for the dialog in its own file. Unlike libglade, it doesn't seem you can specify a root widget when building your UI with builder, unless I missed something here. 

- Extending the system is a relatively simple process:
  1. Add the needed properties to CheeseGConf and edit the GConf schema file as needed. 

  2. If needed, derive a new class from CheesePrefsWidget to synchronize your widget with GConf. See CheesePrefsResolutionCombo for an example of how to do this. For anything that needs its own data model, like combo boxes or tree views, you'll probably need to create a specialized class. But for simple things like check boxes and text entries, one class should be enough. 

  3. Instantiate your class in cheese_prefs_dialog_setup_widgets in cheese-prefs-dialog.c. Connect to the "changed" signal to listen for changes made to the widget by the user so that you can do what needs to be done to change the option (like messing with webcam settings or whatever else.)

  4. Add your instance to CheesePrefsDialogWidgets by calling cheese_prefs_dialog_widgets_add. This container will make sure that your widget gets synchronized when the dialog gets created. It will also automatically destroy your wrapper class when it's no longer needed. 

Test this and let me know how it goes. 

Thanks.
Comment 11 daniel g. siegel 2008-04-19 12:00:40 UTC
awesome patch, you just forgot to put yourself into the AUTHORS file. ;)

do you mind adding the missing options to the preference window?

good job!
Comment 12 James Liggett 2008-04-21 07:01:08 UTC
(In reply to comment #11)
> awesome patch, you just forgot to put yourself into the AUTHORS file. ;)
Thanks!
> 
> do you mind adding the missing options to the preference window?
I don't mind doing it. Thing is, I don't have much time for this stuff right now. I'd have to squeeze it in between lots of other stuff I'm doing, and it would take me quite a while to do all of this. :( And, maintaining this patch is getting to be a little unwieldy. It would be easier on us all if this were committed now so that we could take smaller steps, especially if others would like to work on it. ;)

So, could you please commit this? Even it it's on a separate branch for now, I think that's better than jut having it float around here...

Thanks.
Comment 13 daniel g. siegel 2008-04-21 15:41:52 UTC
everybody is doing as much as he can, no need to have an excuse ;)

i am rolling a development release today. after that i will add your patch to trunk, so that we can actually work on it.

thanks!
Comment 14 daniel g. siegel 2008-04-21 16:37:25 UTC
commited to trunk, thanks again, james!
Comment 15 Ryan Zeigler 2008-06-18 22:51:36 UTC
Created attachment 113014 [details] [review]
Webcam select combo box patch

I have attached a patch that adds a combo box in the preferences dialog to select from the list of detected webcams. This settings is stored to gconf and when cheese starts, it should restore the previously selected webcam if it is available.
Comment 16 daniel g. siegel 2008-06-19 21:37:03 UTC
ryan, thanks for your awesome patch! i just committed it into trunk
Comment 17 Hans de Goede 2008-09-02 18:34:03 UTC
I'm just tuning into this bug, so sorry for the late reply, I would like to make some remarks here which I believe are relevant.

I'm an co-author of the v4l2 rewrite of the gspca camera driver, as well as author of the libv4l video format conversion library and leader of an effort
in Fedora to improve webcam support under Linux see:
https://fedoraproject.org/wiki/Features/BetterWebcamSupport
http://hansdegoede.livejournal.com/3636.html


(In reply to comment #6)
> Framerate for video should be selectable in my opinion because it's a very
> important parameter for quality.

Framerate for webcams is equivalent to exposure time, almost all webcams use relatively cheap cmos image sensors, which work poor in low lightconditions . Low ligt in this context means any light which is not full daylight really. A brightly artificial lit room at night is very dark compared to daylight.

This means that many webcams need to have an exposure time of 0.25 seconds or even more to get a not completely dark picture in these lighting conditions. If each frame needs to be exposed for 0.25 seconds the framerate cannot be higher then 4 fps.

Now most cams have either hardware or software auto exposure which is a must for them to work acceptable at a wide range of lighting conditions. This autoexposure will change the framerate, and may even do so during the shooting of a video! So trying to set a framerate with a webcam is best described as naive, webcams framerates depend upon a number of factors (resolution, exposure, choosen compression, number of other devices on the same usb-root, etc.) and are not configurable as a seperate setting.

So what does this mean when you want to make a 15 fps avi? It means that you either need to throw away frames, or duplicate frames to keep the avi data at 15 fps.

Note above I only gave the very dark example, but it goes visa versa too, on some cams changing the sensorclock and with that the framerate is the only way to control exposure, if you have bright daylight, you really want the cam to be running at 30 fps (or even more) otherwise the picture will get highly overexposed.

> The idea for the flipping arose in some conversation because we had some bug
> reports about cameras doing flipping by mistake. This way you can correct it.
> But we can leave it out.

Please do not add flip controls to fix this, instead ask users to report this
on video4linux-list@redhat.com . We (driver authors) really need to know about cams which exhibit any kind of issues so that we can fix them in the driver, where things like this should be fixed. Papering over these bugs in the application (and needing to redo this in every application) is not the answer.

Comment 18 Filippo Argiolas 2008-09-03 08:13:51 UTC
(In reply to comment #17)
> (In reply to comment #6)
> > Framerate for video should be selectable in my opinion because it's a very
> > important parameter for quality.
> 
> Framerate for webcams is equivalent to exposure time, almost all webcams use
> relatively cheap cmos image sensors, which work poor in low lightconditions .
> Low ligt in this context means any light which is not full daylight really. A
> brightly artificial lit room at night is very dark compared to daylight.

Framerate that Jaap is talking about here (IMHO) is not the one we set on v4l/v4l2src caps, that I think we should just remove given that gstreamer already uses the maximum one if nothing is set.
I think he's talking about framerate in recorded video. 
That makes sense, we already have a videorate element in the video recording pipeline needed to have a perfect stream to feed theoraenc (bug , setting framerate caps after that element would only affect recorded video rate and quality with no relation with the real webcam framerate.
Comment 19 Filippo Argiolas 2008-09-03 08:16:39 UTC
I forgot the (In reply to comment #18)
> pipeline needed to have a perfect stream to feed theoraenc (bug , setting

I forgot the bug link: bug #542014