Mailing List Archive

>>>>> mythtv-dev@snowman.net writes:

> I'm trying to build a media box in one of the Cupid 2677R cases
> (nice and small); it has one (yes, 1) PCI expansion slot, and the
> motherboards available for the form factor (mFATX/mini-ITX) either
> have soldered-in too-slow processors (eg, Via C3 800 MHz, equivalent
> to a PIII-500 at best) *or* don't have TV out.

Yes, it's a pity. You really need a fast PC to do all this stuff in
software, and people mostly don't build those in tiny boxes ;(

> Therefore, the best approach seems to be to use an all-in-one video
> card to capture the TV signal and generate the TV out, with a
> motherboard that can carry a processor, say, Celeron 1.4GHz, with
> sufficient oopmh to do at least VCD-level live TV without dropping
> any frames.

The other choice is to build two systems:

- one in some room where noise doesn't matter, doing the recording

- one that's quiet, that only plays

Mythtv's structure is very, very close to providing a player-only
client: the metadata is all in a sql database, and the files - at
least if you use mpeg4 - should be playable by an otherwise idle
slower (~750MHz+?) diskless computer. You just wouldn't be able to
watch live TV without some changes to tune over the network from one
mythtv to another.

> Any advice from someone on the list with relevant experience
> building similar boxes?

I tried and tried and ended up with a bog-standard computer in the
basement. The closest thing I found was a smallish quietish Shuttle
box (SV24?) that had TV out, PCI, and took reasonable processors, but
in the end was neither silent nor very expandible.

I also looked at PISA-format SBCs, and these will nearly do it, but
PISA does not include AGP, and getting supported tv-out and a 133MHz
Althon bus on a pisa board turned looked to be expensive.

> Also, I'd love to see more reports of resolution/quality vs CPU load
> for a given processor speed!

So it's not only CPU load, it's disk speed, too. I have an Athlon
1800 and Maxtor 120GB 5400 rpm disk on a udma100 controller. This
disk is a tad slow, giving ~35MB/s sustained read, and >12ms seek per
the spec (real ide seek time is probably 30+ ms).

I can't get a jitter free experience at 640x480 or 480x480. Running
at 352x480 works well. This resolution is comparable to a VHS tape;
there's a slight fuzz, but there's never any hint of not being able to
make things out (as for lower resolution divx's off the net, say).

Other users with the same processor appear to get workable behavior at
480x480; dunno about 640x480. I suspect that given a fast enough disk
very good quality video can be used reliably with rtjpeg.

Jitter is infrequent for me using mpeg4 even at 480x480, which I would
probably use but for some bugs long since corrected in the myth cvs.
Since mpeg4 video is half the size of the rtjpeg stuff, it's fairly
clear that the problem with rtjpeg is disk performance.

It's not clear that the mpeg4 code can keep up with 640x480 video on
an Athlon 1800. The CPU appears to be pegged at 480x480, and I
beleive that jitter when using mpeg4 is mostly caused by CPU
starvation, not disk access.

Two things to investigate are:

- Dual CPU. The overall quantity of data sloshing about can be
greatly reduced by using the mpeg4 code, and it looks like that
will only be full-featured (particularly for the forthcoming pip
features) when there is substantially more CPU available. Mythtv's
coder/player threads won't split the work optimally in two, but it
should still work out better.

- Disk striping. Next month I'll get another disk, both for more
space and improved performance. Striping should be a big win.
I'll also experiment with building a large-block filesystem;
currently I use ext2 with 4K byte blocks. Conceivably the fs could
lseek faster if I used larger blocks.

Has anybody done either of these on their myth box?

--
Grant Taylor - gtaylor<at>picante.com - http://www.picante.com/~gtaylor/
Linux Printing Website and HOWTO: http://www.linuxprinting.org/

On Fri, 13 Sep 2002, Grant Taylor wrote:

> - Dual CPU. The overall quantity of data sloshing about can be
> greatly reduced by using the mpeg4 code, and it looks like that
> will only be full-featured (particularly for the forthcoming pip
> features) when there is substantially more CPU available. Mythtv's
> coder/player threads won't split the work optimally in two, but it
> should still work out better.

My box currently uses mpeg1 format (not with mythtv). It captures and
encodes to mpeg1 using about 20% of my Athlon 1.13GHz CPU. Playback
(mplayer) is very light (<5%). I generally capture at 352x288. I can
capture two sources at once at that resolution, whilst playing back one or
two at the same time.

CPU isn't a problem for 2 simultaneous 720x576 captures, but I seem to hit
PCI bus latency problems with that much data on the bus.

Disk throughput is no problem because the mpeg1 gives high compression - I
generally capture at around 1.5GB per hour.

mpeg1 is quite a bit lighter CPU-wise than mpeg4. I'd suggest mythtv
should experiment with mpeg1.

A second advantage is its simpler to get from that the (S)VCD format
disks.

Steve