RE: Some performance tunning opportunity of cheese

["Zhao, Halley" <halley zhao intel com>]

Argiolas , Really appreciate your prompt response
.
I will use the git tree for creating patch, and create separated patches for each feature step by step.

1. For your suggestion of use bugzilla, I understand it as file a bug for each feature and attach the patch, right?

2. We will re-investigate the device capability probe patch against the git tree which has move from hal to udev.

3. gconf vs UI configuration, when I engage with customer, they think end-user has few knowledge of fps, pulse/alsa, vorbis/flac. Then they suggest to create gconf key,and OEM/OSV can deliver configuration through gconf, advance user can also change it through gconf-editor. Do you think it is a reasonable solution?

4. vorbis/flac. From my experience, most recently netbook is delivered with 160G or 250G HD, recorded file size doesn't matter now.

5. alsa/pulse gconf key. I try to create another gconf key specified for cheese because I don’t' expect this option impact other application. For example, audio only recording goes through pulseaudio is still suggested.

 


-----Original Message-----
From: filippo argiolas gmail com [mailto:filippo argiolas gmail com] On Behalf Of Filippo Argiolas
Sent: 2010年1月29日 18:05
To: Zhao, Halley
Cc: cheese-list gnome org; Holmes, Iain; Lespiau, Damien; Rob Bradford; Guo, Young
Subject: Re: Some performance tunning opportunity of cheese

2010/1/29 Zhao, Halley <halley zhao intel com>:
> Hi All:
> I created one patch for your basic/quick review.
> You can give me some guide line how to process it.

Hi, sorry for the late reply, I must have skipped your mail while I
was really busy and forgot about it then...
First of all, thanks for looking into this thing, I know cheese
performs badly on netbooks and I'm really open to anything that could
improve the current situation.

I have a few preliminary concerns about the patch:
1. Why are you working with cheese 2.28?
We changed a lot of things in the way cheese does device detection and
capability probing during the 2.29 cycle
(http://mail.gnome.org/archives/gnome-announce-list/2010-January/msg00039.html):
we dropped hal in favor of udev, we improved a lot startup times (so
far we accessed the device twice for streaming during startup, now we
only open it for streaming when we're really going to display stuff),
and we do caps probing in a IMHO saner way.
So, could you please rewrite the patch to apply on git master?

2. Could we please move this discussion on bugzilla? It's a lot easier
to review patches there.

> Details:
> Cheese doesn’t perform well on my netbook, after some tries; I’d like discuss some opportunity with you.
>
> 0. Rob suggest me use gconf key for customized options, it has been reflected in the attached patch.
>
> 1. ALSA or PulseAudio
> Should we add some options(man through UI) to let user select ALSA as audio src?

gconfaudiosrc is there just for that, you can switch to alsa using
gstreamer-properties.

> 2. Vorbis vs FLAC
>   If I use flacenc instead of vorbisenc, %CPU could decrease to 8% based on ALSA
>   Should we add flac as a option for audio recording?

We considered in the past to let the user choose an encoding profile
different from the default theora+vorbis one.
I don't think it makes sense to just add the ability to use a
different audio encoder through gconf. This change should come with a
proper UI to make it easily configurable from users. If you are going
to work on this I'll be glad to review your patches.

Regarding FLAC, by the way, are we really sure it is suited for
netbooks? it is surely better for cpu performance but the same is not
true for disk usage and that's a precious resource for netbooks (my
dell mini has 8GB, 7 of which full most of the time).

> 3. (max) fps, cheese always try to use the highest fps (no higher than 30) of camera.
>
> However, it doesn’t make sense for most web-camera, you can’t see difference of 15fps or 30fps.

I planned to make this configurable anyway, so this change is more
than welcome (if you rewrite it for git master, it should even be a
lot easier to implement there).

> 4. cheese on my netbook lack of a/v sync,
>
> but when I add ‘do-timestamp’ for both audio and video src, and let audio src ‘provide-clock’. It will be ok for a/v sync.
>
> Do you think it is a valid change?
>
> 5. there is also some preview latency on my netbook.
>
>   When I add queue in the audio/video encode pipeline, it will be much better.
>
> 6. video sink ‘sync=false’
>
>   Set ‘sync=false’ of video sink also benefits preview latency.

Seem fine to me, didn't test those changes yet though.

> 7. video effect is insteresting, it also add some startup time for pipeline status change.
>
> When there is no video effect selected, we can optimize pipeline to reduce ~3s for Gst pipeline startup.
>
> When there is only rgb or yuv based effect, we can also optimized pipleline to reduce ~3s pipeline startup

I believe 3 seconds is overestimated but ok.

> 8. cheese will query camera capability during each launch time.
>
>    However, in most case we don’t change the device, if we try to add some policy to save the capability for once (when the hw changed), and load the capabiltiy when hw hasn’t changed, it could reduce launch time ~3s

Again, another thing I wanted to implement but never had enough time
to. 3 seconds seem much here too, especially now that we open the
device in READY state for capability probing. Anyway, I'd love to see
this in cheese.

> Your comments are welcome

So far it seems that the most significant change is to use flac. I
doubt the other tweaks (do-timestamp, two queues, sync-false) make a
big difference as most of the cpu usage is caused by theoraenc and
vorbisenc anyway, but as I said I have to test those yet.
The other changes improve startup time and that's surely good and
welcome but I don't think that's really the issue with netbooks. I
mean you can probably wait some second more for cheese to startup but
you cannot accept video recording failing miserably as it does now if
the cpu cannot stand the load.
So I think the only sane way to fix this is to allow the user to
configure some way the encoding profile. It would be great as I said
to do this properly, adding the needed UI in the preferences dialog,
would you like to work on it?

Thank you again,
Best Regards,

Filippo Argiolas