[pvrusb2] Preventing drop-outs while capturing video?
Andrew Munkres
amunkres at nyx.net
Fri Mar 4 08:28:53 CST 2011
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?
More information about the pvrusb2
mailing list