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

[Filippo Argiolas <fargiolas gnome org>]

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

> A simple solution would be to block recording until encoding is
> finished.
>
>> 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.

I'll look at it. Daniel probably it could be interesting for the
project you're working on too, right?

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

I'm leaving for some vacation tomorrow morning so don't expect
anything before two weeks. If everybody else wants to work on it,
please do.

Ciao,
Filippo