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

David Schleef ds at entropywave.com
Tue Jul 7 01:03:23 CEST 2009


On Mon, Jul 06, 2009 at 10:57:30AM +0200, Filippo Argiolas wrote:
> Hey all,
> I need some suggestion from you video encoding experts.
> Recently we received several reports in bugzilla about Cheese not
> being able to do live video recording on low power cpus (like atom and
> in general netbooks). At the moment we record videos with a pretty
> standard pipeline, theoraenc, vorbisenc, oggmux.
> 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).
> I did a quick test with several encoders and it seems that ffenc_mjpeg
> with a medium-high bitrate consumes at least 60% less than theoraenc
> with default settings. Could it be a good alternative? Any other idea?

We don't currently have the infrastructure for enforcing real-time
encoding -- you either have enough CPU and it Just Works, or you
don't, and it silently fails.  Encoder libraries are starting to
get features for controlling this.  libtheora allows you to mark
the next several frames as identical, thereby skipping frames when
the encoder gets behind.  Schroedinger has a similar mechanism, but
it's not yet exposed in the API.  I'll probably add some support
in GstBaseVideoEncoder for catching QoS messages (which have not
been defined yet) to connect up to the encoder features.  (You know,
in that magical day in the future when I get back to BaseVideo
hacking.)

In general, prefessional capture apps encode to an intermediate
codec like AIC, ProRes422, DNxHD, or DiracPro, since the CPU usage
is very predictable and quite low.  But that requires large bit
rates and off-line transcoding to whatever long-gop format you
actually want.



dave...





More information about the gstreamer-devel mailing list