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 587726 - Request to add a option to disable audio recording when capturing and recording from webcam
Request to add a option to disable audio recording when capturing and recordi...
Status: RESOLVED DUPLICATE of bug 564957
Product: cheese
Classification: Applications
Component: general
2.26.x
Other All
: Low enhancement
: 2.30
Assigned To: Cheese Maintainer(s)
Cheese Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2009-07-04 05:51 UTC by bgao1
Modified: 2010-08-09 00:22 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description bgao1 2009-07-04 05:51:15 UTC
Recently I found the performance of Cheese was extremely bad (%CPU > 100%) when capturing video (and recording at ogg format) from my webcam at a 640x480 resolution. After analyzing the source code of Cheese, I found a audio capturing and recording were simultaneously done. That means vorbis audio encoding and theora video encoding are done at the same time so huge CPU resources are consumed. But some time users only want to record video from webcam, in this case, audio capturing is a CPU waste. So I suggest Cheese to add a option(i.e. a checkbox) which can disable simultaneous audio capturing if users don't want to record audio at the same time.
Comment 1 Jaap A. Haitsma 2009-07-04 15:16:38 UTC
Vorbis encoding CPU load is way lower than the theora encoding, but we could add a small microphone icon in the user interface such that users can mute their microphone
Comment 2 bgao1 2009-07-06 02:14:34 UTC
> Vorbis encoding CPU load is way lower than the theora encoding, 
I had a test on my EeePC 1000H:
$ gst-launch alsasrc ! audioconvert ! vorbisenc ! oggmux ! filesink location=./test.ogg
The %CPU is about 35%, that's remarkable!

> but we could add a small microphone icon in the user interface such that users can mute their microphone
Yes, it'll save CPU resource in case user only want to record video. Thanks you!
When you add this microphone icon, could you also add settings for audio capturing, e.g. channels, rate, bit width/depth, just like we set resolution for video capturing?

Comment 3 Filippo Argiolas 2009-07-06 07:03:55 UTC
(In reply to comment #2)
> > Vorbis encoding CPU load is way lower than the theora encoding, 
> I had a test on my EeePC 1000H:
> $ gst-launch alsasrc ! audioconvert ! vorbisenc ! oggmux ! filesink
> location=./test.ogg
> The %CPU is about 35%, that's remarkable!

Well, I'm not sure it does mean anything at all, try this two pipelines:

gst-launch-0.10 v4l2src ! video/x-raw-yuv, width=640, height=480 ! videorate ! theoraenc keyframe-force=1 ! oggmux name=m ! filesink location=test.ogg  pulsesrc ! queue ! audioconvert ! vorbisenc ! m.

gst-launch-0.10 v4l2src ! video/x-raw-yuv, width=640, height=480 ! videorate ! theoraenc keyframe-force=1 ! oggmux name=m ! filesink location=test.ogg

The first is almost the same recording pipeline we have in cheese at the moment.
The second is the same with no audio. I get 69-71% with both (on a core duo 2 1,67 GHz).

I agree that we should do something about cheese and netbooks. Live vorbis+theora encoding is simply not affordable with atom cpus.
Maybe we should provide an option to use some less resource hungry encoder? mjpeg?
Comment 4 bgao1 2009-07-06 08:47:10 UTC
> gst-launch-0.10 v4l2src ! video/x-raw-yuv, width=640, height=480 ! videorate !
> theoraenc keyframe-force=1 ! oggmux name=m ! filesink location=test.ogg 
> pulsesrc ! queue ! audioconvert ! vorbisenc ! m.
> 
> gst-launch-0.10 v4l2src ! video/x-raw-yuv, width=640, height=480 ! videorate !
> theoraenc keyframe-force=1 ! oggmux name=m ! filesink location=test.ogg
> 
> The first is almost the same recording pipeline we have in cheese at the
> moment.
> The second is the same with no audio. I get 69-71% with both (on a core duo 2
> 1,67 GHz).

I tested the pipelines above on my EeePC 1000H (Atom N270) but with widthxheighth=320x240, the result is:
for the first pipeline(with audio capture), I got 41-45%.
for the second pipeline(no audio capture),  I got 18-20%.
Obviously, vorbis encoding consumes notable CPU resource so it makes sense to add a option to disable audio capturing.

 
> I agree that we should do something about cheese and netbooks. Live
> vorbis+theora encoding is simply not affordable with atom cpus.
> Maybe we should provide an option to use some less resource hungry encoder?
> mjpeg?
Agree, but how many CPU resource mjpeg can save against theora?
Just found vorbis encoder gets especially bad performance on Atom.

Comment 5 Filippo Argiolas 2009-07-06 09:00:57 UTC
(In reply to comment #4)
> I tested the pipelines above on my EeePC 1000H (Atom N270) but with
> widthxheighth=320x240, the result is:
> for the first pipeline(with audio capture), I got 41-45%.
> for the second pipeline(no audio capture),  I got 18-20%.
> Obviously, vorbis encoding consumes notable CPU resource so it makes sense to
> add a option to disable audio capturing.

Well then it could top misreporting cpu usage with dual core cpus or just that atom performs really bad with vorbisenc.

> 
> > I agree that we should do something about cheese and netbooks. Live
> > vorbis+theora encoding is simply not affordable with atom cpus.
> > Maybe we should provide an option to use some less resource hungry encoder?
> > mjpeg?
> Agree, but how many CPU resource mjpeg can save against theora?
> Just found vorbis encoder gets especially bad performance on Atom.

With a quick test I got 60% with theoraenc and 18% with mjpeg (medium-high bitrate though since with default settings the quality is quite bad).
I've sent an email about this at gstreamer-devel list, let's wait if they come up with some good suggestion.
Comment 6 bgao1 2009-07-07 06:47:24 UTC
Hi Filippo Argiolas,

Before we have a solution for less resource hungry video encoder(e.g. mjpeg), could you please consider to add a microphone icon at first?
Comment 7 Brandon Philips 2010-03-02 00:13:51 UTC
Should this be closed as a dup of Bug #564957?
Comment 8 bgao1 2010-03-02 03:05:35 UTC
Ye, It looks to me bug #564957 covered what this bug is concerning.
Comment 9 daniel g. siegel 2010-08-09 00:22:26 UTC

*** This bug has been marked as a duplicate of bug 564957 ***