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

[Brandon Philips <brandon ifup org>]

On 08:41 Thu 26 Aug 2010, Filippo Argiolas wrote:
> On Thu, Aug 26, 2010 at 2:31 AM, Brandon Philips <brandon ifup org> wrote:
> > 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?
> 
> I was thinking more about several simultaneous encoding jobs so a
> semaphore was not enough, we'd need a more complex api that abstract
> async jobs, makes them cancellable, allows us to query and get
> notified about their status, probably gio has some infrastructure for
> that or maybe just gstreamer is enough. And we would need a good ui
> around that.
>
> Everything becomes more simple if you block for each encoding job as
> you suggest

I really think starting simple is the right thing to do. I am trying to
get from locking up application -> working and the fastest/simplest way
to get there is ideal.

How about a configuration option such as:

"Use x% of disk space as a video queue?" And then present the user with
an info bar while recording that tells them they have approximately X
minutes/seconds remaining before recording will stop based on their
queue option.

Would that be workable?

Thanks,

	Brandon