On Thu, 2010-08-26 at 08:41 +0200, 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 > > > 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? queue2 won't work with live streams, for queue2 you have to have a static stream, such as a movie file. for live streams, queue is the only thing we can use. > > >> 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 > _______________________________________________ > cheese-list mailing list > cheese-list gnome org > http://mail.gnome.org/mailman/listinfo/cheese-list -- this mail was sent using 100% recycled electrons ================================================ daniel g. siegel <dgsiegel gnome org> http://www.dgsiegel.net gnupg key id: 0x6EEC9E62 fingerprint: DE5B 1F64 9034 1FB6 E120 DE10 268D AFD5 6EEC 9E62 encrypted email preferred
Attachment:
signature.asc
Description: This is a digitally signed message part