pvrxxx recording

[Rick C. Petty]

On Fri, May 30, 2008 at 06:48:36PM -0400, Jim Stapleton wrote:
> 
> I never said or insinuated that the stepwise process is functional (or
> not minded) on my computer. I simply said cat'ing the device to the
> drive causes a video that looks acceptable (actually good).
> The stepwise process is not feasable with my current setup/situation
> due to drive space, and the length of some of the recordings I want to

Sure.  And you could probably use my (or similar) technique using named
pipes and not have to consume the disk space.  My method works for me; if
it helps you out, great.

> do. Also, having tested it out, the coversion is actually worse in the
> stepwise process.

Probable because you're decoding and reencoding a lot.  That's why I use
dvbcut and tcrequant.  Those two tools supposedly do their work with
minimal (if at all) decoding/encoding, thereby reducing artifacts.  I did
put my technique through a lot of testing before I decided it was worthy of
a script.

> Also, in the stepped process
> * all the conversions took about 4-5 seconds for a 20 second video
> * my CPU was at fairly low utilization 45-65%.

Which sounds like the conversion will lose quality.  The faster the encode,
the lower quality.

> * At the time of the conversion/recording, my disk IO was being hogged
> by a compile and backup process.

I have no problems recording two channels simultaneously with my pvr500
while doing other operations such as disk I/O or video conversion.
Granted with FreeBSD's caching algorithms, if I don't touch certain
processes (like firefox) while I'm converting, I have to wait for those
processes to swap in when I do use them again.  Video processing is highly
memory-intensive.

> Is there extra overhead to compressing something straight out of the
> tuner? Using a similarly performing algorithm, (2x on each axis, 4x
> the power, right?) should be possible real-time with the same 45-65%
> CPU utilization.

Not sure what you mean.  In my case, the video coming out of the card is
compressed.  I'm certain a standard PCI bus cannot handle the bandwidth of
raw video very well, as I've seen with my bktr cards.

-- Rick C. Petty