[mythtv] Trading CPU for disk (capture using low cpu codec?)

[Bruce Markey]

Scott and Jill Gargash wrote:
>>Bruce Markey <bjm@lvcm.com> wrote:
>>kevin thayer wrote:
>>
>>>Has anyone experimented with the trade-offs between
>>>CPU usage and disk size?
>>
>>Yes, but maybe not in the way you're thinking ;-)
>>
>>Given 500MHz CPU/mobo, a 40GB disk and $150 I believe I'd
>>get much better quality and more recording time by buying
>>a ~2GHz CPU/mobo than I would by buying a 120GB disk.
> 
> 
> But there are good reasons to use trade IO for CPU cycles beyond saving
> $$$s.  The less you need to do in real-time the better, especially if
> you don't want to have howling fans in your living room. 

I agree about the fans but I think the more you get done in
real-time the better. However, I first want to say that I
think the best solution is Linux support for tuner cards with
on-board compression. If we had v4l support for, say, the
WinTV PVR or other cards that could spit MPEG straight out
of /dev/video, we wouldn't need faster CPUs for realtime or
non-realtime compression.

My point wasn't so much about money (however, if money wasn't
an issue we wouldn't be talking about ~500MHz CPUs ;-). Raw
video files are huge so my point was that having adequate
CPU to compress is more effective than having the disk space
to store uncompressed data. My neighborhood computer stores
don't sell CPUs <1.2GHz anymore and these are fast enough to
easily encode good MPEG4 files. Maybe I should have used $100
for 1.2GHz vs 80GB as the example.

> And you can always perform a non-realtime recompression of the file to
> get better space efficiency.

I see this is still on Isaac's todo list.

> ... And many video codecs are asymetric, i.e.,
> they can require a lot more compute cycles to compress than to
> decompress.  For example, when compressing mpeg-style, computing the
> motion compensation vectors can take a long time if you're willing to
> let it.  If you're encoding is real-time, the motion vector state space
> search will be limited, while a non-realtime encoding need not be.  If
> you can get better motion vectors, you can get higher quality and/or
> better compression.  

Good stuff but if we're talking about re-encoding to do very
good motion compression wouldn't we be better off trying to
do it on CPUs faster than 500MHz? $51 buys a CPU ~3X faster
(http://www.pricewatch.com/).

> And the amount of video processing can be greater than just
> compression/decompression. Is anyone else using a progressive scan
> monitor for playback? Some deinterlacing routines can be very compute
> intensive. 

MythTV uses a linear blend filter by default that can be
turned on or off in the settings file. Look for "Deinterlace".
This uses MMX and doesn't seem to impact CPU usage very much.

--  bjm