Date: Fri, 30 May 2008 18:48:36 -0400 From: "Jim Stapleton" <stapleton.41@gmail.com> To: rick-freebsd@kiwi-computer.com Cc: freebsd-multimedia@freebsd.org Subject: Re: pvrxxx recording Message-ID: <80f4f2b20805301548x2e5e55d2g32267504797ffcdb@mail.gmail.com> In-Reply-To: <20080529170858.GA70632@keira.kiwi-computer.com> References: <80f4f2b20805290402w84c3f4k3f302385396b6b1c@mail.gmail.com> <20080529170858.GA70632@keira.kiwi-computer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 29, 2008 at 1:08 PM, Rick C. Petty <rick-freebsd@kiwi-computer.com> wrote: > On Thu, May 29, 2008 at 07:02:48AM -0400, Jim Stapleton wrote: >> OK, I got my pvrxxx problems fixed (I apparantly had my ffmpeg line wrong). >> >> I'm having trouble getting a decent recording though. The uncompressed >> stream is too large for comfort. > > Uncompressed, it should be. > >> $ cat /dev/cxm0 | ffmpeg -i - -vcodec $v -acoded $a -f $f out.mpeg >> $ ffmpeg -i /dev/cxm0 -vcodec $v -acoded $a -f $f out.mpeg > > So you're fine with a multi-step process? BTW, you might get better > performance if your first command is: > > ffmpeg -i /dev/cxm0 -vcodec $v ... > >> Note: 'cat /dev/cxm0 > out.mpeg' works fine, and looks great - it's >> just huge (3-4GB/hr). > > That's not that huge. > >> Does anyone know of a format that should work well? The computer is a >> Optron 185 (dual core, 2.4Ghz), with 3GB memory, and a 7200RPM hard >> drive. > > Your computer is too slow to do a live decode/encode of an MPEG2 stream. > Since you don't mind a multi-step process, why don't you record at the > standard bitrate and do a post-process step? That's what I do. I actually > have my own cxm_record program which calls the setchannel command and then > performs a cat(1) equivalent. After the recording is finished, I use > multimedia/avidemux to select cut/edit points and a custom script to > convert the avidemux project to a multimedia/dvbcut project. I've found > dvbcut does a better job of cutting the MPEG2 streams and does a minimum > recoding process (only at the edit points). From there I run a custom > script to furthur compress the MPEG2 stream and turn it into a DVD VOB. > This script may be of interest to you and your issue, so I'll describe it > here. 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 do. Also, having tested it out, the coversion is actually worse in the stepwise process. the 720x488 image looks fairly decent for the most part doing on-the-fly encoding. The problem is, if there is much motion, the portions of the screen with motion tend to look like they are are appropriate for the image being in 72x49 resolution, rather than 720x488. The remain sections of the screen look like I would expect from, say, 360x244 (1/2 x 1/2), scaled to the player's size. When I have a stepped process (I cat my sample video to a file, then ffmpeg the file), I end up with something that looks like it's appropriate for a 180x122 (1/4 x 1/4 image), throughout the picture, but motion degredation is barely noticable. it's still too low for my comfort. The original file appears to be full quality. 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%. * At the time of the conversion/recording, my disk IO was being hogged by a compile and backup process. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?80f4f2b20805301548x2e5e55d2g32267504797ffcdb>