Re: some performance tunning opportunity of cheese

[Stefan Kost <ensonic hora-obscura de>]

Zhao, Halley wrote:
>
> Hi all:
>
> Cheese doesn’t perform well on my netbook, after some tries; I’d like
> discuss some opportunity with you.
>
>  
>
> 1. ALSA or PulseAudio
>
> Gconfaudiosrc is default to PulseAudio on my platform, however if I
> use ALSA directly, it will reduce CPU consummation.
>
> For example, for audio only recording, Gst pipeline with PulseAudio
> src consumes 50%CPU, while with ALSA src consumes 30% CPU.
>
> Should we add some options(man through UI) to let user select ALSA as
> audio src?
>
Can't you switch your GConfAudio source to alsa then 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?
>
The gstreamer project is working on a encode-bin api. When this is
getting ready camerabin will use it and cheese will probably use
camerabin. Then you can presets for the target recording format.
>
> 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.
>
> Should we add some option for it, or use 15 instead?
>
Cheese has a setting for the resolution already. This could be extended
to also have a secondary setting for the framerates. Not sure if it
should be implemented so that the framerate is set on the source, or
only via videorate on the recoding chain (so that the viewfinder remains
smooth).
>
> 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?
>
‘provide-clock’ for the source imho makes sense when recording audio.
Are you sure setting "do-timestamp" makes a difference?

> 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.
>
I don't know if there is a queue in the viewfinder path. If so the queue
could be made leaky when recording video.
>
> 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
>
How?
>
> 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
>
Since a few versions plugins can cache extra data in the registry. In
theory v4l2src could cache all the camera-hardware details in the
registry and reuse it, *if* it can easily validate the cached info.
First the data needs to be cached per device, probably easy. But then
driver updates or simply running with
LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so or
/usr/lib/libv4l/v4l1compat.so changes the capabilities of the cam
reported by v4l-info.

But I agree, I'd like to cache that info too in a way.

Stefan
>
>  
>
> Your comments are welcome
>
>  
>
> *ZHAO, Halley (Aihua)*
>
> Email: halley zhao intel com <BLOCKED::mailto:aihua zhao intel com>
>
> Tel: +86(21)61166476
>
> iNet: 8821-6476
>
> SSG/OTC/Moblin 3W038 Pole: F4
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Cheese-list mailing list
> Cheese-list gnome org
> http://mail.gnome.org/mailman/listinfo/cheese-list
>