Re: [PULL] cheese: overrun callback for slow machines

[Filippo Argiolas <fargiolas gnome org>]

On Fri, Sep 10, 2010 at 12:57 AM, Bastien Nocera <hadess hadess net> wrote:
>> > > > The point is that we should be able to capture directly to OGV, even if
>> > > > the machine isn't fast enough to do this real time.
>> > >
>> > > How do you capture directly to OGV if it can't encode to real time? By
>> > > definition don't you need an intermediate cache on disk in some file
>> > > format?
>> >
>> > Yes, you do.
>>
>> > But the capture shouldn't block the display,
>>
>> Hrm, what do you mean by this? When and why would capture block display?
>
> Because you don't have any queues in between the video capture and the
> encoding elements, so everything is synced together, for example.

Not sure what you mean, we have queues everywhere needed.
Please, would you show me a pipeline that does what you say just using queues?

> The point being that it should queue compression on disk, or in memory
> rather than tell people "your hardware is too slow". It's only too slow
> because Theora compression is a pig CPU wise, and that shouldn't impact
> on the user experience.

So far I haven't been able to have a single pipeline that encodes what
the cpu can afford on the fly and queues the rest (either on ram or on
disk) while displaying into a videosink at the same time. The only
option you have, as far as I know, the one Brandon is proposing, is to
save the raw video/audio into disk and start an encoding job once the
whole video is saved. This is still suboptimal, harder to implement in
a good way and easy to get wrong.

Live encoding works almost everywhere and I think changing resolution
when it doesn't is not a big issue deal for the user and surely it is
better than producing an empty video file.
I'm not sure that the user experience shouldn't be impacted if he
tries to push his hardware beyond its limits.

Lately, thanks to the work of Alexey Fisher we found that it's not
just theora that it's being a pig but there are several issues in
GStreamer with variable framerate sources, some issue with pulseaudio
and others (see the dependency tree of the involved bug) that fixed
would probably make the "warn the user" thing only a last chance
solution to mitigate an hopefully rare failure.

Anyway, I'd really be happy to stand corrected about queues magically
fixing everything. And, as always, contributions are more than
welcome!

Ciao,
Filippo