Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 1 Jun 2008 01:41:00 -0500
From:      "Rick C. Petty" <rick-freebsd@kiwi-computer.com>
To:        Jim Stapleton <stapleton.41@gmail.com>
Cc:        freebsd-multimedia@freebsd.org
Subject:   Re: pvrxxx recording
Message-ID:  <20080601064100.GB13314@keira.kiwi-computer.com>
In-Reply-To: <80f4f2b20805301548x2e5e55d2g32267504797ffcdb@mail.gmail.com>
References:  <80f4f2b20805290402w84c3f4k3f302385396b6b1c@mail.gmail.com> <20080529170858.GA70632@keira.kiwi-computer.com> <80f4f2b20805301548x2e5e55d2g32267504797ffcdb@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080601064100.GB13314>