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

[Henk Poley]

> Van: Bruce Markey <bjm@lvcm.com>
>> 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.

<flamebait>
Hae, no-my-way-is-better discussions tend to be solved by implementing
both...

They don't 'bite' eachother either. What do you got to lose? Recompression
is a feature most people want anyways (to burn to CD). And another codec
(if we may find a good one) just adds to the compatibility/plugabilty.

Go get one!
</flamebait>

[btw, adding something to the setup/settings-dialog to automagicaly tweak
the settings might be needed. Just record 'anything' for a while with codec
X, watch frame-drops, adapt, loop...]

> 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.

I guess most of you saw the yesterday article on Slashdot, about the
"DreamBox", http://www.dream-multimedia-tv.de/ .  It uses hardware record
and playback of MPEG2 files (AFAIK). Just the price it a bit high at ~500
EUR, and it still needs a harddisk (that will make 650 EUR).  And this
device cannot play CDs/DVDs since it doesn't have a DVD-drive.

BTW, >=800MHz Ezra and Eden processors are also quite capable of _playing_
DVDs (MPEG2) and DivX, even with their bad FPU-performance.  These boxes
(mini-ITX and book-PCs) are around for 200-400 EUR, all-in most of the
time.  Misses a TV-in though, plus the harddisk that's too small, 10GB :-(

> > 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/).

My bet is still that MythTV costs more, as long as you don't want
everything. A nice looking silent MythTV-PC in the order of magnitude what
Isaac uses cost 890-1020 EUR, AFAIK. Unless you go bargainshopping all
around the internet, but that might show up not to save you that much.

I think I'll seek some more data/prices about the devices that can be
'mythicaly convergenced'...

Will fill my crappy Wiki server with this info.

> > 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.

MMX2 btw...

Wouldn't it be handy to make a general resize prog that can be piped to the
actual encoder (you know, capture at 2x the resolution you record at).
mjpeg has it built in, isn't? It might as well improve DivX compression
since the uncompressed picture would be cleaner (less 'snow'). And future
codecs will like it too.

	Henk Poley <><