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>