[pvrusb2] Preventing drop-outs while capturing video?

[Andrew Munkres]

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?