At 10:03 11/18/2005 -0800, Ralph Shumaker wrote: >Barry Gershenfeld wrote: > >> I would be more likely to attend beginner sessions. This may be a >> personal preference thing, especially as I like teaching as much as >> learning. As I hinted above, I consider exploring the basics (the >> underpinnings) more worthwhile than learning too much about this or >> that new package. Rather than an in depth presentation, I think an >> appropriate overview is consumable by newbies anyway. >> >> As an example, I did learn about MythTV from the presentations, but I >> really never knew anything about it until I tried it myself. > > >Do you think I could run MythTV on seriously older hardware (PII-350) if >I'm willing to run it in resolution just adequate enough for a 2-inch >diagonal? I'm probably wrong, but I think what needs most of the >compute-cycles is all the pixels of running (either recording or >displaying) in a larger window. Eventually, I'll get some giveaway >hardware that will run circles around what I'm on. And until then, I >would be happy (I think) with a 2-inch diagonal. (I would want decent >sound from the start, although I don't need anywhere near CD quality. >Vinyl record or stereo radio quality would be good enough.) Recordings >could be done in analog format (.wav for sound and .??? for video). >(Ripping from a CD happens at nearly 4x on my hardware.) Compression to >digital formats (.mp3 and .???) could be done when no recordings are >going. (My hardware encodes .wav to .mp3 (or .ogg) at about 2x.) If my >hardware can keep up with a 3-inch diagonal, so much the better. I >currently watch TV on a 19" screen from about 12 feet away. If I were >to watch from only about 1.5' away and keep the same ratio, then 2.25" >would be roughly equivalent.
There are several portions to MythTV, each of which has its own requirements. 1) Video capture. This is the piece that grabs a video signal from either a built-in tuner, Composite video or SVIDEO (separate luminance and chrominance signals). This is accomplished by a dedicated video capture card. These video capture cards have varying levels of onboard "smarts" to help compress the signal. On the low end are simple frame-buffer capture cards that just digitize the video signal and sends it to a large buffer where it is up to the CPU to crunch it into something else like MPEG-2/4 or RTjpeg. This takes quite a bit of CPU power. The only way to know if your system can handle it is to test it. On the high end are cards that can automatically compress the signal using onboard hardware and thus offload all the work from the CPU. For example, I have a Hauppauge PVR-150 card that produces a MPEG-2 video stream that can be saved directly to disk. The CPU utilization on my system is so low that it oftentimes doesn't even show up in top, mostly 1% or less. Almost any system with a PCI bus can handle one of of these cards. There is a big warning about certain hardware interactions because of poor DMA implementations (mostly VIA chipsets) so read up first. Given a choice of video capture cards, go with the one with the onboard encoder. The $40 price difference will save you way more in time and effort later on, especially if you consider going with a split frontend/backend. 2) Backend and database. This is the software that controls the scheduling and recording functions. This doesn't take much CPU resources (a few percent on my system) and really isn't a concern. 3) Frontend. This is the part that plays back the recording (even live TV is actually a recording because of the buffer). In order to view the recording, the saved data format (MPEG-2/4, RTjpeg, etc) has to be converted to a colorspace and then played out through a videocard using a videoout function like Xv (X Windows Video), XvMC (X Windows Motion Compensation, hardware acceleration for MPEG-2 streams), a simple framebuffer, or some other alternatives. I have tried the XvMC parts with nVidia MX-440 cards in a desktop and ATI Radeon Mobility 9000 (M9) in a laptop, and they both suck. I have had the best playback with the Xv playback, but that means all the decoding and colorspace conversion are being done by the CPU. On my Athlon 1.4GHz system with an nVidia MX-440, playback takes about 30% CPU utilization. Note that the video capture, backend, and frontend can all be on different machines. They communicate over the network. A MPEG-2 stream takes about 6Mbps, so you could run over 10baseT for a single seperate frontend. >From the description of your system, recording won't be a problem if you get a card with onboard compression. Video playback might be marginal. A way to test the playback is to play a DVD (the VOB files are essentially MPEG-2) with something like Xine <http://xinehq.de/>, mplayer <http://www.mplayerhq.hu/homepage/design7/news.html>, or VideoLAN <http://www.videolan.org>. If you can play a DVD without a problem then you should be able to play back a video recording also. Gus "Watching too much TV" Wirth -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-newbie
