I did the same sort of thing on a *ix system many, many moons ago (around 20 years??), when I noticed how inefficient even 'dd' was - wrote a very simple stdin-to-stdout copy utility using non-blocking read/write into/out_of a circular buffer. It's amazing what a performance impact it had, yet I wouldn't be surprised to find that today's Linix system utilities (dd, cp, et al) STILL don't make use of this facility...
-Charles ________________________________ From: Andrew Munkres <[email protected]> To: [email protected] Sent: Fri, March 4, 2011 9:28:53 AM Subject: [pvrusb2] Preventing drop-outs while capturing video? Hello all, I was trying to use a PVR USB2 to capture some fairly long VHS tapes. I noticed that there were some small discontinuities in the captured video where a split-second was missing. I was initially doing the capture with mencoder, like this: mencoder -ovc copy -oac copy -o output.avi /dev/video0 I think I might have also tried mplayer, doing something like this: mplayer -dumpstream -dumpfile output.mpeg /dev/video0 I also tried cat, something like this: cat < /dev/video0 > output.mpeg (I might have also tried dd.) I got video drop-outs regardless of which program I used. However, one time I did the capture sort of like this (I don't remember exactly): mkfifo fifo mencoder -ovc copy -oac copy -o fifo /dev/video0 & ssh remotehost 'cat - > out.avi' < fifo & (The purpose of that was to store the video on another system with more free disk space.) That time, I didn't get any drop-outs. Unlike in the earlier examples, in this one, the program reading from /dev/video0 isn't directly writing to a regular file on disk. So, I'm guessing that the trouble happened because the (blocking) writes to the disk were delaying the reads from /dev/video0. If that's the case, then it seems like a solution would be to do non-blocking reads from /dev/video0 into a large circular buffer, and then have a separate process (or thread) which moves the data from the circular buffer to a regular file. (That way, the reader process can still do reads even when the writer process is blocked waiting for a write to finish, as long as the buffer isn't full.) I wrote a small program which can do that; it does non-blocking reads from stdin into a 16 MB circbuf, non-blocking writes from the circbuf to stdout, and then you pipe its stdout to another program which does the (blocking) writes to a file on disk. I named this program "flywheel". For example, it can be used to capture video like this: chrt -r 99 flywheel < /dev/video0 | cat > capture.mpeg (In that example, flywheel runs with real-time priority but cat does not. That's because it should be ok for the cat process to have fairly high latency, since that just means that flywheel's circbuf will temporarily become more full.) Then I redid one of the failed VHS captures using flywheel, and it worked on the first try. (Also, I've previously had similar drop-out problems when doing audio capture from my computer's "line in", with arecord. So I tried piping the output from arecord to flywheel, and it seemed to help there too.) In case anyone else would find this program useful, I've now set up a public git repository for flywheel, here: http://gitorious.org/flywheel So, does anyone here know whether my guess about the cause of the drop-outs is correct or not? Any other comments? _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
