GNOME Bugzilla – Bug 512342
Cheese should allow user to select resolution for photos and video
Last modified: 2008-05-02 14:34:55 UTC
Cheese should allow users to use any resolution that their cameras support, instead of just the highest one for photos and 320x240 for video. This was originally discussed here: http://mail.gnome.org/archives/cheese-list/2008-January/msg00033.html.
Daniel: In your message, when you say that it doesn't work with videotestsrc, are you talking about a segfault? When I unplug my camera I get one in cheese_webcam_get_video_formats. It seems that this is because there's no device data if we don't get anything from HAL. So what we probably want to do is create a fake device structure and have CheeseWebcam probe for resolutions. While I'm delighted that you want to get this in for GNOME 2.22, I'm not sure this is going to be a simple workaround. What kind of timetable do I have here? Thanks.
yeah, i get a segfault, as the videotestsrc doesnt feature any resolutions. well, we have to request a feature freeze break anyway, so the earlier the better ;)
Created attachment 103941 [details] [review] Implement resolution selection (take 2) Daniel: This patch fixes all the problems with the last one, including: - The video test source now works. For this I just created a fake video format, 320x240 @ 30 Hz. - Selection moved to menu (under Edit/Resolution) - Video capture is disabled for resolutions greater than 1024x768. As my camera works at this or lower, I thought it would be a good threshold. Enjoy, James
Oh, and that last bit should probably say "recording," not "video capture." :)
ok, we will test that patch and if everything is fine asking for a freeze break. thanks a lot!
(In reply to comment #5) > ok, we will test that patch and if everything is fine asking for a freeze > break. thanks a lot! What's the status on this? Thanks.
James, I'd prefer having this in a preference dialog. It's not a setting that a user would change often. Jaap
hmm.. maybe we could add this setting in gconf? this wouldnt need a freeze break... the resolution seem to be working here, great job!
(In reply to comment #7) > I'd prefer having this in a preference dialog. It's not a setting that a user > would change often. Is this one option worth the expense of building a whole preferences dialog? I would think so if we had more options to set, but for just the resolution this seems like overkill to me. Even then, I'd still like to have the resolutions at hand, as I change resolution pretty often, usually at least once per session. I like that I don't have to interrupt my workflow just to flip between say, 640x480 for video and 1600x1200 for pics. I designed this patch and the previous version (with the combo box below the screen) precisely for this purpose, where I could change it in a click or two, instead of having to go through another step.
(In reply to comment #8) > hmm.. maybe we could add this setting in gconf? this wouldnt need a freeze > break... Why not? It's still a feature that's added in, wouldn't that outdate the docs, and maybe the translations? Also, what would happen if the user switched cams to one that doesn't support the resolution that the key was set to? And, speaking of the feature freeze break, are they going to let this in or what? > the resolution seem to be working here, great job! Excellent! Thanks for testing. :-)
James, The preference dialog should contain more than just resolution. In my opinion it should contain. 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 Because you can set the resolution for video and photo separately also your use case gets covered.
james, would it be able for you to enhance your patch using gconf to store the used resolution? in my opinion we could leave that as a hidden option, as probably most users wouldnt want to change their resolution
(In reply to comment #12) > james, would it be able for you to enhance your patch using gconf to store the > used resolution? Yes, I could do this, but I will have to make even more changes to CheeseWebcam to make sure that the currently connected camera can handle that format if for example the user changes cameras. Just off the top of my head, I'll probably have to at least need to put the CheeseVideoFormats in a hashtable to do this, and maybe some other stuff I haven't thought of yet. ;-) > in my opinion we could leave that as a hidden option, as probably most users > wouldnt want to change their resolution Well, I change this setting a lot and having it just as a hidden setting would be a real pain. I would really like to have some kind of UI for doing this. Besides, this strikes me as a hack to hurry it in before the release, which we really don't want to do. That said, I'd like to know what direction I should go in here. First it was put it in a menu, then Jaap says he wants a prefs dialog, and now its just a gconf key. Personally, I think that a menu, maybe with a gconf key, is the best option. But, as long as my use cases get covered, I'm not necessarily opposed to a prefs dialog. However, if we decide to go that route, I would prefer to do it right, and come up with a proper prefs backend to support it and all of the other things that Jaap has proposed. In this case it would be best if we just forgot about getting this into 2.22 and just get it done for the next release. Maybe we should just forget about the release anyway--guess my timing just really sucks. With any of these proposals, I'd have to make substantial changes to my existing patch, and I don't think I can do all of it before the release.
(In reply to comment #13) > (In reply to comment #12) > > james, would it be able for you to enhance your patch using gconf to store the > > used resolution? > Yes, I could do this, but I will have to make even more changes to CheeseWebcam > to make sure that the currently connected camera can handle that format if for > example the user changes cameras. Just off the top of my head, I'll probably > have to at least need to put the CheeseVideoFormats in a hashtable to do this, > and maybe some other stuff I haven't thought of yet. ;-) go ahead ;) > > > in my opinion we could leave that as a hidden option, as probably most users > > wouldnt want to change their resolution > Well, I change this setting a lot and having it just as a hidden setting would > be a real pain. I would really like to have some kind of UI for doing this. > Besides, this strikes me as a hack to hurry it in before the release, which we > really don't want to do. > > That said, I'd like to know what direction I should go in here. First it was > put it in a menu, then Jaap says he wants a prefs dialog, and now its just a > gconf key. > > Personally, I think that a menu, maybe with a gconf key, is the best option. > But, as long as my use cases get covered, I'm not necessarily opposed to a > prefs dialog. However, if we decide to go that route, I would prefer to do it > right, and come up with a proper prefs backend to support it and all of the > other things that Jaap has proposed. In this case it would be best if we just > forgot about getting this into 2.22 and just get it done for the next release. > > Maybe we should just forget about the release anyway--guess my timing just > really sucks. With any of these proposals, I'd have to make substantial changes > to my existing patch, and I don't think I can do all of it before the release. > gconf setting for sure, as we need to save that somewhere. i would go for a preference window or just a submenu entry. if you want to include your patch into gnome 2.22, i think a submenu entry would be far better. maybe edit->camera resolution->resolutions...
> gconf setting for sure, as we need to save that somewhere. +1 > > i would go for a preference window or just a submenu entry. if you want to > include your patch into gnome 2.22, i think a submenu entry would be far > better. maybe edit->camera resolution->resolutions... How about we go with a menu, like my current patch does, for 2.22, and work on the prefs dialog for the next version so that it's robust as possible? For now I'll just add gconf support to my current patch and submit that for inclusion, and then work on the prefs system in the meantime. Is that OK for everybody?
(In reply to comment #15) > > gconf setting for sure, as we need to save that somewhere. > +1 > > > > > i would go for a preference window or just a submenu entry. if you want to > > include your patch into gnome 2.22, i think a submenu entry would be far > > better. maybe edit->camera resolution->resolutions... > How about we go with a menu, like my current patch does, for 2.22, and work on > the prefs dialog for the next version so that it's robust as possible? For now > I'll just add gconf support to my current patch and submit that for inclusion, > and then work on the prefs system in the meantime. Is that OK for everybody? > of course! just be sure, to add the menu entry to the cheese menu on the top, maybe under "edit", ok?
Created attachment 105946 [details] [review] Resolution selection with gconf key
james, thanks for your slavery work ;) unfortunately we are way to late to get this patch into cheese as it isnt critical. i will add it to our development version after releasing the stable version. do you want to help as in the future with the "preference dialog" (in whatever form it will be)?
(In reply to comment #18) > james, thanks for your slavery work ;) unfortunately we are way to late to get > this patch into cheese as it isnt critical. i will add it to our development > version after releasing the stable version. That sucks...:( But it won't kill us, will it? > do you want to help as in the future with the "preference dialog" (in whatever > form it will be)? Absolutely! I've got some very rough ideas in my head, plus I'm inundated with bugfixing some other gnome apps I work on, so I'd like to refine my ideas some more then discuss them after the release, at which time I'll send my stuff to the list then file a bug. All that aside, I'm glad this will finally get in, even if it's later than we'd hoped ;-).
trunk is now open for development. as this will go into 2.24, i would say that we could create a preference window, where we put your patch. is that ok?
this has been fixed in trunk, further development goes on in bug #522200