Mailing List Archive

Trading CPU for disk (capture using low cpu codec?)
Has anyone experimented with the trade-offs between
CPU usage and disk size?

I have a dual celeron setup, at 500mhz each, they
aren't terribly powerful, but I have heard tales of
people using inefficient codecs and getting decent
performance out of their slow pcs using a "really
light weight encoder" (RAW?) and then compresing it
during off hours.

I'd be interested in seeing a ranking of software
codecs by how much cpu they use. Anyone knowlegable in
that area?

Can anyone comment on the feasability of using a
really space-inefficient but cpu friendly codec to do
time-shifting tv watching (pause/ff/etc live tv)?
(would disk throughput become *the* factor?)

What would rock is a table of codecs and max seamless
record/watch resolution for various cpu's.. That's a
TALL order though :)

This may be a dumb question, but using software, can
you specify an arbitrary resolution and thereby
squeeze the maximum SOFTWARE performance out of your
cpu? (ie. increase the size till it chokes) I know
there is a size setting, but not sure how configurable
it is.

Can you use other (untested?) codecs for
record/playback by changing that line of the config
file to other libavcodec supported codecs?

Thanks!
-Kevin

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
Re: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
On Tue, Dec 10, 2002 at 01:53:48AM -0800, kevin thayer wrote:
> Has anyone experimented with the trade-offs between
> CPU usage and disk size?
>
> I have a dual celeron setup, at 500mhz each, they
> aren't terribly powerful, but I have heard tales of
> people using inefficient codecs and getting decent
> performance out of their slow pcs using a "really
> light weight encoder" (RAW?) and then compresing it
> during off hours.

Rtjpeg which is already supported by Myth is pretty light weight so if you
can get the quality you want from that.... There are also lossless
compression codecs out there which should have equivalent quality to raw yuv
but I have no idea what the speed is like. IMHO doing uncompressed capture
isn't worth it due to the massive storage space and storage bandwidth
required. I know disk space is cheap but it isn't THAT cheap, especially
compared to cpu.

Personally, I think a better question is which compression codecs will hurt
quality least if you want to do manipulations of the resulting files
(denoising, commercial cutting, etc). My gut feeling is that frame based
compressors such as rtjpeg/mjpeg/dv? would be best but it really depends on
what tools are out there to do the manipulations and formats it works with.

--
Ray
Re: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
On Tuesday 10 December 2002 04:53 am, kevin thayer wrote:
> Can anyone comment on the feasability of using a
> really space-inefficient but cpu friendly codec to do
> time-shifting tv watching (pause/ff/etc live tv)?
> (would disk throughput become *the* factor?)

Disk speed pretty quickly becomes a factor then, yeah, at least with watching
live-tv.

> What would rock is a table of codecs and max seamless
> record/watch resolution for various cpu's.. That's a
> TALL order though :)
>
> This may be a dumb question, but using software, can
> you specify an arbitrary resolution and thereby
> squeeze the maximum SOFTWARE performance out of your
> cpu? (ie. increase the size till it chokes) I know
> there is a size setting, but not sure how configurable
> it is.

It'll only capture to what the tuner card will output.. Doing any
cropping/resizing in software is relatively expensive, so I don't think you'd
see any gains by doing it.

> Can you use other (untested?) codecs for
> record/playback by changing that line of the config
> file to other libavcodec supported codecs?

Yup. I've tested with their mjpeg and huffyuv encoders.. I don't think that
using the mpeg1 encoder works right, though.

Isaac
Re: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
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.

Hope that helps,

-- bjm
Re: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
On Tue, 2002-12-10 at 19:02, Bruce Markey 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.
>
> Hope that helps,
>
> -- bjm
>
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev@snowman.net
> http://www.snowman.net/mailman/listinfo/mythtv-dev

Following this thread made me think of another negative side effect of
using less compressed files. The seek times tend to be longer. Like
ffwd through a recording, rewinding during live tv. Mythtv becomes less
responsive say when I use the rtjpeg over the mpeg4. Also changing
screens like from live tv to program guide, tends to crawl some, actual
see the screen drawing coming down for the EPG. I'm thinking it has to
do with available ram, with those big files ram seems to be busy
caching.
Re: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
> 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.

And you can always perform a non-realtime recompression of the file to
get better space efficiency. 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.

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.

Scott
Re: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
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
Re: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
> Bruce Markey wrote:
> > Scott and Jill Gargash wrote:
> >
> > 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.

We may just have to agree to disagree, but demanding realtime
performance from an application when running on an arbitrary end-user
system with a non-realtime OS seems risky. This doesn't mean you
wouldn't like to try to get as much done in real-time as possible, but
you shouldn't require it. And even with an RTOS, you still like to keep
as much out of the realtime domain as possible. It makes it much easier
to get right and to validate.

It doesn't mean you don't want to run as fast as possible, which might
even be real-time, but it would be nice to require as little true
realtime operation as possible. I don't like dropped frames, and I'd
like to be able to use my computer for other things while it's capturing
video.

Of course, it's not like this is a medical dvice or anything. A dropped
frame won't kill anyone.

> However, I first want to say that I
> think the best solution is Linux support for tuner cards with
> on-board compression.

I waver on this. Certainly at any particular point in time, custom hw
will be more efficient, but as soon as a new codec comes out (DIVX vs
MPEG-2) all of the custom hardware is useless. Software can be
upgraded.

FWIW, the general consensus by the HTPC people (avsforum.com) is that if
you have the CPU, software decoding of DVDs gives better image quality
that HW decoding.

> My neighborhood computer stores
> don't sell CPUs <1.2GHz anymore and these are fast enough to
> easily encode good MPEG4 files.

Have you seen the new micro-itx motherboards with the built-in ~900 MHz
low power processor? They don't require any cooling. Very neat, and
they would make a perfect settop box, but they don't have the CPU to do
high quality realtime encoding and decoding. They should have the CPU
to do high quality decoding in realtime.


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

Processing always expands to fill the time available. You can always
use more cycles. And, to put it another way, if I record 4 hours of TV
a day, that still gives me 20 hours of idle CPU time. Regardles of the
speed of my processor, why not use that time to try to get the best
quality for a given amount of space? And if you're going to reencode,
you'll want the source material (now 1 generation removed from the
actual source) to be as close to the origianl as possible. And I can
easily imagine an acausal compression algorithm. You can't do that in
real-time regardless of how fast your CPU is.

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

Check out deinterlace.sourceforge.net. It may have improved in
efficiency since I last tried it (about ~1 year ago), but back then I
couldn't get the higher quality deinterlacing routines to run in
realtime on a (windows-based) P800 doing nothing but the deinterlace
code. That certainly seemed expensive.

Scott
Re: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
> 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 <><
Re: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
On Thursday 12 December 2002 12:42 pm, Henk Poley wrote:
> 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.

Nope. It uses a dvb card to grab the satellite stream, and so is only useful
in Europe.

> 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 :-(

From the benchmarks I've seen, those boxes, even the new 933MHz ones, can
barely playback divx files.

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

About US$200 for the CPU, motherboard, and RAM to get something faster than
what I have. Figure $50 for a decent tuner card, another $50 for an older
gf2 with a tv out, $50 for a cheap desktop case, and $100 for 80GB of
harddrive space. Not terribly expensive.

I think I spent about $80 getting the fan noise down to acceptable levels --
quieter than my ps2 and gamecube, at least.

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

I dunno, I'd think that resizing in software when you can just ask the capture
card for the lower resolution would be fairly silly. I doubt you'd get any
better picture quality out of doing that.

Isaac
Re: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
Henk Poley wrote:
...
> <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>

OUCH! I didn't intend a my-way-is-better stance at all.
My apologies if it seemed that way. I acknowlege that
recompression is on the todo list and it's a good thing
and I don't oppose it.

The original question had to do with the trade-offs between
CPU usage and disk size. My only point is that adequate CPU
is a good investment.

-- bjm
Re: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
> Van: Bruce Markey <bjm@lvcm.com>
>
> My only point is that adequate CPU is a good investment.

I understood :-)

Henk Poley <><
Re: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
> Van: Isaac Richards <ijr@po.cwru.edu>
>
>> On Thursday 12 December 2002 12:42 pm, Henk Poley wrote:
>> 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.
>
> Nope. It uses a dvb card to grab the satellite stream, and so is only
> useful in Europe.

I happen to live there. It can also record normal cable TV. And, "nope" to
what?

>> 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 :-(
>
> From the benchmarks I've seen, those boxes, even the new 933MHz ones,
> can barely playback divx files.

Hmmm, must be the mostly-emulated FPU...

But anyways, PC Intern about the ECS i-Note IN22 (VIA C3 GigaPro):
"Trotzdem meisterte der i-Note auch Multimediaaufgaben wie das Abspielen
von Filmen oder Musik ohne problemen"

In English: "The I-Note even does multimedia-playback like video or music
quite nicely". Though that doesn't say anything about DivX in special...
They ran it on Win2k.

>> 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.
>
> About US$200 for the CPU, motherboard, and RAM to get something faster
> than what I have. Figure $50 for a decent tuner card, another $50 for an
> older gf2 with a tv out, $50 for a cheap desktop case, and $100 for 80GB
> of harddrive space. Not terribly expensive.
>
> I think I spent about $80 getting the fan noise down to acceptable levels
> -- quieter than my ps2 and gamecube, at least.

Athlon XP 1800+ : 89.00
256MB DDR333-CL3 : 85.00
(..alternate..)

Adds to 174 EUR, pretty sloppy motherboard for ~40 euros. Cheapest ('good'
one) I see are ~85 EUR. btw, 10 EUR more and you have faster DDR266-CL2.
And off coarse SDRAM is about half the price per MB.

No offence meant, but $50 for a case would probably buy you one you _need_
to put in a closet, I guess. In my case ;) a desktop model won't fit (not
enough space near TV).

>> 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.
>
> I dunno, I'd think that resizing in software when you can just ask the
> capture card for the lower resolution would be fairly silly. I doubt
> you'd get any better picture quality out of doing that.

Someone told quite recently on the list that he experienced this.

Henk Poley <><
Re[2]: Trading CPU for disk (capture using low cpu codec?) [ In reply to ]
Hello Henk,
http://www.directron.com/blackdesktop.html is a case I own
that is both fairly nice and cheap at US$44. Guess everything's just a
little more expensive comparatively where you are.
Friday, December 13, 2002, 7:15:06 AM, you wrote:

>> Van: Isaac Richards <ijr@po.cwru.edu>
>>
>>> On Thursday 12 December 2002 12:42 pm, Henk Poley wrote:
>>> 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.
>>
>> Nope. It uses a dvb card to grab the satellite stream, and so is only
>> useful in Europe.

HP> I happen to live there. It can also record normal cable TV. And, "nope" to
HP> what?

>>> 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 :-(
>>
>> From the benchmarks I've seen, those boxes, even the new 933MHz ones,
>> can barely playback divx files.

HP> Hmmm, must be the mostly-emulated FPU...

HP> But anyways, PC Intern about the ECS i-Note IN22 (VIA C3 GigaPro):
HP> "Trotzdem meisterte der i-Note auch Multimediaaufgaben wie das Abspielen
HP> von Filmen oder Musik ohne problemen"

HP> In English: "The I-Note even does multimedia-playback like video or music
HP> quite nicely". Though that doesn't say anything about DivX in special...
HP> They ran it on Win2k.

>>> 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.
>>
>> About US$200 for the CPU, motherboard, and RAM to get something faster
>> than what I have. Figure $50 for a decent tuner card, another $50 for an
>> older gf2 with a tv out, $50 for a cheap desktop case, and $100 for 80GB
>> of harddrive space. Not terribly expensive.
>>
>> I think I spent about $80 getting the fan noise down to acceptable levels
>> -- quieter than my ps2 and gamecube, at least.

HP> Athlon XP 1800+ : 89.00
HP> 256MB DDR333-CL3 : 85.00
HP> (..alternate..)

HP> Adds to 174 EUR, pretty sloppy motherboard for ~40 euros. Cheapest ('good'
HP> one) I see are ~85 EUR. btw, 10 EUR more and you have faster DDR266-CL2.
HP> And off coarse SDRAM is about half the price per MB.

HP> No offence meant, but $50 for a case would probably buy you one you _need_
HP> to put in a closet, I guess. In my case ;) a desktop model won't fit (not
HP> enough space near TV).

>>> 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.
>>
>> I dunno, I'd think that resizing in software when you can just ask the
>> capture card for the lower resolution would be fairly silly. I doubt
>> you'd get any better picture quality out of doing that.

HP> Someone told quite recently on the list that he experienced this.

HP> Henk Poley <><
HP> _______________________________________________
HP> mythtv-dev mailing list
HP> mythtv-dev@snowman.net
HP> http://www.snowman.net/mailman/listinfo/mythtv-dev



--
Best regards,
Wayne mailto:bigman1@alltel.net