Re: [PULL] cheese: overrun callback for slow machines
- From: Bastien Nocera <hadess hadess net>
- To: Brandon Philips <brandon ifup org>
- Cc: cheese-list gnome org
- Subject: Re: [PULL] cheese: overrun callback for slow machines
- Date: Thu, 09 Sep 2010 23:57:13 +0100
On Thu, 2010-09-09 at 15:53 -0700, Brandon Philips wrote:
> On 23:12 Thu 09 Sep 2010, Bastien Nocera wrote:
> > On Thu, 2010-09-09 at 10:33 -0700, Brandon Philips wrote:
> > > On 11:26 Wed 25 Aug 2010, Bastien Nocera wrote:
> > > > On Wed, 2010-08-25 at 12:23 +0200, Alexey Fisher wrote:
> > > > > Am Mittwoch, den 25.08.2010, 09:50 +0100 schrieb Bastien Nocera:
> > > > > > On Mon, 2010-08-23 at 18:07 -0700, Brandon Philips wrote:
> > > > > > > Hello-
> > > > > > >
> > > > > > > This is one half of my solution to slow netbooks running cheese and
> > > > > > > trying to encode videos[1]. The basic idea here is to detect a pipeline
> > > > > > > stall and inform the user that their machine is too slow to encode video
> > > > > > > in real time. It suggests that lowering the resolution might help.
> > > > > >
> > > > > > I would much rather that the uncompressed video was queued to disk, and
> > > > > > compression finished when we stop the capture.
> > > > > >
> > > > > > Cheers
> > > > >
> > > > > Probably cheaper for cpu and hdd will be mjpeg than raw.
> > > >
> > > > Right, or as close as possible to whatever is handed by the camera,
> > > > although libv4l will probably do conversion anyway.
> > > >
> > > > 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.
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]