stapleton.41 at gmail.com
Fri May 30 22:48:37 UTC 2008
On Thu, May 29, 2008 at 1:08 PM, Rick C. Petty
<rick-freebsd at 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
> 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
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
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%
More information about the freebsd-multimedia