[gst-devel] Cheese, netbooks and resource hungry encoders

[Filippo Argiolas]

On Mon, Jul 6, 2009 at 12:49 PM, Axel
Philipsenburg<axel.philipsenburg at hobnox.com> wrote:
> Hi there,
>
> Filippo Argiolas wrote:
>> Do you have any suggestion about less cpu avid encoders? We used those
>> ones because they are free but if they don't work it could be worth
>> adding other options (ideally we'd add DeviceProfiles support when
>> it'll be in a good enough shape).
> Did you check the parameters on theoraenc ?
> There is the "speed-level" parameter that could
> limit the motion vector search, which is a very
> time consuming process.

I've tried fiddling with theoraenc parameters, speed-level included,
but I wasn't able to drop cpu load significantly (in the best case it
dropped from 105% to 99% but recording failed anyway).
Also I believe vorbisenc has a great part, it seems it doesn't perform
quite well on atom.

> On the other hand, did you use a queue in the pipeline? If
> I remember correctly, Atom CPUs (used in many
> Netbooks) have Hyperthreading. Thus allowing the
> pipeline to multithread might improve the performance
> a bit.

Sure the pipeline we use is roughly like:
gst-launch-0.10 v4l2src ! tee name=t ! queue ! xvimagesink t. ! queue
! theoraenc ! oggmux name=m ! filesink location=test.ogg  pulsesrc !
queue ! audioconvert ! vorbisenc ! m.

> I agree with Erik that using a lower resolution will help a lot
> too. Scaling the image down with a simple filter such as
> bilinear is way faster than the encoding the larger picture.

Sure, lowering the resolution can really drop cpu load (even 40-50%
less) but that unfortunately depends on the user choice. I could write
a FAQ item telling them to lower down recording resolution but that
wouldn't prevent the issue to come up if they don't do it.
Maybe I could look for a way to guess the available cpu power and
lower down recording resolution by default if it's not enough.

Thanks

Filippo