Re: [Ekiga-devel-list] [GStreamer] CPU consumption, in-video-call, is too high.

[Julien Puydt <jpuydt free fr>]

Le 29/09/2012 12:37, Genghis Khan a écrit :
> The following writings are parts of a private corespondent between
> myself and Mr. Julien Puydt.  Notes are additions and were not
> originally written in the conversation. Julien Puydt, your replies have
> been omitted.  Please post them again.
>
>
> CPU consumption, while using video, is relatively too high,
> therefore are you considering to separate tasks to separate processes
> in a similar manner to what Mozilla Firefox has done with its plugin
> system by using plugin-container?

My reply what that a container was useful for security or for easier 
threading. Now I can also add : for crash containment.


> While I use GOOM with a prevalent audio/video player or with Ekiga
> offline or activating the Screencast while Ekiga is offline (not in
> call) then the CPU won't be as high as it is (60% or 70% I need to
> check again) while Ekiga is connected to another peer.
>
> NOTE: GStreamer Video test
>        $ gst-launch videotestsrc ! ximagesink
>        8% to 11% CPU when initial is 3% to 6%
>
> Initial CPU usage is 6%
>
> Turning on Ekiga and calling in LAN:
> Moving Logo 70%
> Goom effect 100%
> Screencast  30% - 40% (freeze - invalid)
> Video test  60%
>
> NOTE: Invalid = this finding is invalid due to Screencast freeze bug.

My answer was that that might not be an indication of a problem with my 
gstreamer code, but with ekiga more generally, as the moving logo is 
already using way too much cpu.

So the subject of the thread should probably not put the guilt on 
gstreamer : there must be something in ekiga itself.

Snark