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

[Filippo Argiolas]

On Tue, Jul 7, 2009 at 1:03 AM, David Schleef<ds at entropywave.com> wrote:
> 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.)

Thank you for clearing this. You're totally right, real time recording
just works if the cpu can handle it but silently fails, sometimes
outputting empty files, sometimes just freezing, etc. when the power
is not enough. At least now I can blame for sure gstreamer when it
happens ;-)
A base class for encoding with some kind of Quality of Service would
be really great.

> 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.

That would probably be an overkill for a simple application like
Cheese, both from an implementation point of view (i.e. we need more
manpower to add advanced features like raw/intermediate codec
recording + delayed transcoding) and from a use target (it's just an
application that takes photos and little videos for fun... you cannot
expect it to behave professionally) point of view.

Thank you,

Filippo