Re: RFC: [PATCH] camera: encode in a seperate thread

[Brandon Philips <brandon ifup org>]

On 13:15 Wed 25 Aug 2010, Filippo Argiolas wrote:
> On Tue, Aug 24, 2010 at 3:31 AM, Brandon Philips <brandon ifup org> wrote:
> > What do you think of this patch? There are probably bugs since I am not
> > extremely familiar with gtk or gstreamer.
> >
> > On slow machines it is often not possible to record and encode in real
> > time particularly at high framerates.
> >
> > So, instead record to the disk with no compression and then after
> > recoding has stopped start encoding to vorbis/theora and remove the
> > temporary uncompressed version.
> 
> Don't have the time to do a proper review right now but I believe this
> could be the definitive solution to this annoying bug.

> It poses some new issue though and it's a lot harder to get right:
> - keeping track of current encoding jobs

Just increment a semaphore. What else do we need to track?

> - what to do if cheese exits while recording

Warn the user if the semaphore is greater than 0?

> - disk usage monitoring: with some rough estimate I'd say 30 seconds
> of raw rgb data is around 500 GB, if the user records several
> subsequent videos and encoding is slow you could very much fill the
> whole disk, especially if almost full.

A simple solution would be to block recording until encoding is
finished.

I don't know how to present to the user information about disk usage of
recording in a HIG compliant way.

> I'd also like to see this implemented as some sort of disk queue, so
> that you can start encoding (maybe with some low priority so it
> doesn't block everything else) immediately instead of waiting for the
> whole raw file to be written to disk.

Right, that would be another way of doing it. And actually gstreamer
tries to provide a solution with GstQueue2:
 http://www.gstreamer.net/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-queue2.html

But, I couldn't get queue2 to actually work. Maybe someone else could
give it a shot.

> The underrun patch instead is a fine workaround that can be applied
> easily and soon with current code base and allows us to not fail badly
> as we do now.

I agree.

> I'll try to review everything as soon as I can.

Thanks.

Cheers,

	Brandon