On Fri, Aug 6, 2010 at 12:30 PM, Richard A. Smith <rich...@laptop.org> wrote: > Whats the qualifications on that? I assume its raw RGB video?
No, it's compressed vid + uncompressed audio to be stitched later. I have a confession to make: Many years ago I worked in video mixing with mid-range gear (avid and media100, I *don't* miss you) and with cheapskates PC-based rigs (which where hell on wheels compared to avid and media100). My take is that our CPU is perfectly capable of capturing and compressing vid and audio and putting it down to disk, even on a 2MB/s-capable disk, helped a bit by (limited) linux kernel buffering. Most importantly, we need to capture audio + vid together, or at least timestamp them together. Otherwise drift is inevitable. I also think our vm.dirty_* settings are wrong and likely causing our current fill-buffer-and-stutter behaviour. We are using the defaults and those are for spinning harddrives, with a significant cost to spinning up the disk on a laptop -- hence long expire_centisecs and writeback_centisecs and the assumption that once you've started writing, it'll be written out fast. We have zero seek costs, zero "spin disk up" costs, but slowish writes -- we have to start writing buffers out ASAP. But that's my (naive?) take. I haven't delved into the gstreamer madness. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel