[pvrusb2] Preventing drop-outs while capturing video?

[Charles Green]

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 <amunkres at nyx.net>
To: pvrusb2 at isely.net
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
pvrusb2 at isely.net
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2