[pvrusb2] Preventing drop-outs while capturing video?

akp2akp2 akp2 at gmx.de
Fri Mar 4 13:12:25 CST 2011


Am 04.03.2011 15:28, schrieb 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?
> > _______________________________________________
> > pvrusb2 mailing list
> > pvrusb2 at isely.net
> > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
> >
>   
Just curious, isn't the cache ("-cache 20480" for 20MB buffer) option of
mencoder enough to get the same result?




More information about the pvrusb2 mailing list