GNOME Bugzilla – Bug 584075
Option to set the video quality of the OGV video file
Last modified: 2010-08-09 00:25:40 UTC
I think the OGV video (Theora in OGG) can be encoded using different quality levels (or compression levels). So, it would be nice to add an option to set the video quality of the saved OGV video file. I don't know enough about Gstreamer or its theoraenc plugin, but I think it has a quality setting. Regards, MV
At cheese_webcam_create_video_save_bin in cheese_webcam.c, after setting up the Gstream factory for the Theora encoder, when setting the keyframe-force property, like: g_object_set (video_enc, "keyframe-force", 1, NULL); g_object_set (video_enc, "quality", XX, NULL); where XX would be the quality value. However, is this run only when starting up Cheese or when starting to record? Regards, MV
> However, is this run only when starting up Cheese or when starting to record? The latter as far as I know. I'm not completely against this but first, here's a couple of questions: - What's the point of making the quality configurable? - Did you see any real gain increasing it? - Isn't webcam image quality too poor to justify a configurable quality parameter in the recorded video? - Shouldn't we try to pick the best quality (compromise between video size, cpu load, actual video quality) and not leave this choice to the user?
So, maybe I didn't explain when I filled this feature request why I think this is useful. One reason is that I didn't like it the blockiness and color-smearing in some of the videos from my webcam. The other reason is that the highest quality of 63 (or less maybe) may be useful for people who will post-process the video, for example to add text, titles, effects, etc. before uploading for distribution; or for people who want to convert it to another lossy format and want to reduce the visual artifacts. About the "apparent" difference in quality, yes, I see some difference, specially with the image details, but it is not constant and maybe not that impressive considering how noisy are the images from my webcam. The improvement is better with a daylight video (less noise/grain) vs. a dark one (more noise/graine); actually a grainy video looks better at low quality values. Maybe Cheese was designed to be simple and easy to use and I am asking to add complexity to the program. I really don't know what to answer to your question about choosing the best quality and not leaving the choice to the user. Maybe I'm too used to lot of controls and options but most users would be better with a default or very simple options. Maybe a way to implement this control is using command-line parameters or an Advanced Options dialog? Or maybe a simple Video Quality slide with Average, High, Highest? Am I too geeky requesting this? Regards, MV
I would be very grateful if this function could be implemented. This request is based on one single problem I have. Cheese works great when _not_ recording video but when I push the video record button my computer/CPU gets over-loaded and Cheese freeze/crash after a few seconds. So the record function is useless for me at the moment. If it was possible to set the video record settings to "I have a terribly weak CPU and my graphic card sucks" or something like that it would most likely solve my problem. I have a AMD Athlon Neo 64 CPU, one of those new (2009) low power net-book CPU:s, like Intel Atom but a bit more powerful (and power consuming). So I don't think I'm alone with this problem. Thanx for an othervise greate program! /Johan Andersson, Sweden
Johan, you're not alone with this issue, we are aware of this but, basing on my empiric tests the encoder quality won't solve anything... The performance gain from tweaking quality is not that much, the only way to really drop down cpu usage is to lower down the resolution of the recorded video. We'll probably support video recording at a lower resolution in the next release. Anyway, the real issue is that gstreamer doesn't help us that much here, the recording pipeline shouldn't fail that way when cpu usage is too high, it should drop frames, try to adapt to the available resources. Gstreamer 1.0 will probably have a better QoS system that will prevent faults like this. On the other hand, one could also argue that such low power cpus are not really suited for live video encoding and we're trying to fight an hardware limitation with really low chances of success.
*** This bug has been marked as a duplicate of bug 564957 ***