Difference between revisions of "Hardware Requirements"

From MythTV Official Wiki
Jump to: navigation, search
m (pywikipedia assisted cleanup -> replacing Myth Frontend with MythFrontend)
(38 intermediate revisions by 22 users not shown)
Line 1: Line 1:
= General Requirements for a MythTV setup =
+
This article gives an overview of the '''hardware''' requirements for a MythTV system.
  
I thought the Wiki might benefit from a slightly more verbose section on general hardware requirements than that found in the MythTV documentation, so here it is.
+
==Basic requirements for a MythTV setup==
 +
As you probably know, Linux will run on pretty much anything. MythTV relies on the [[FFmpeg]] codecs for any video handling, which are heavily optimized for the x86 architecture. Due to this, modern 64-bit processors from AMD and Intel are the preferred basis for a MythTV system. Older 32-bit AthlonXPs and Pentium 4s, low power VIA systems, and the increasingly common ARM systems, should be avoided.
  
As you probably know, Linux will run on pretty much anything, although at the time of writing I believe MythTV is only designed to run on x86 (and, more recently, x86-64) processors such as those made by Intel and AMD, so firstly you'll need a computer with one of those, which shouldn't be too difficult! At this point you may want to refer to the [[HardWare]]/[[Cooling Quietly How To]] which contains some information on keeping your processors cool and quiet. You'll need to make sure that the motherboard for your desired Myth box will be able to support things like large hard drives and lots of DMA traffic (some older VIA chipsets have very buggy DMA transfers which make them highly unstable when running MythTV).
+
===Video capture card===
 +
:''Main article: [[Video capture card]]''
  
Aside from that, the basic components of a MythTV setup are:
+
All recording through MythTV is performed by the backend. The backend can handle as many tuners as you can physically fit in the system, and if that is not enough, you can run multiple backends located on additional hardware to expand your capabilities. Each simultaneous recording and Live TV session requires a tuner input. If you want to have padding on back-to-back recordings, you need additional tuners. Note that only one backend is needed on the network, and additional PCs can be configured as frontends with no local capture card.
  
* [[Video Capture Card]]s<br>
+
Some users will have access to IPTV based off the [[FreeBox]] model, for which MythTV can use a virtual network tuner. Most users will need some form of digital tuner. North American users need [[ATSC]], European and Australian users need [[DVB]], and Japanese and South American users need [[DVB]]. Both IP and digital television makes use of streams compressed by the broadcaster. MythTV need merely copy this data to disk for pristine, lossless quality.
You will need as many of these as the number of shows you want to record and watch simultaneously. (That is, you can record as many shows simultaneously (or which overlap) as you have cards, '''unless''' you're using one (or two) of them to watch LiveTV.) A lot of people settle for 1 or 2 of them. Some have an on-board sound digitizer, so you don't need a loopback cable and (an extra) soundcard. [[MythFrontend]] only machines don't need one of these.
 
* [[Video Card]]s<br>
 
Depending on your needs you will want one with ''S-Video out'' (normal TV), ''SVGA'' (monitor) or ''DVI-D / DVI-I'' (projector/LCD/plasma/HDTV screens). The PVR350 has a TV-Out built in. Quite a few motherboards have TV-out on-board nowadays, though the quality varies.
 
* [[Sound Cards]]<br>
 
You need a separate one for each grabber card, if it doesn't have an on-board sound digitizer. Nowadays most motherboards have built-in sound'cards'. Be sure the card is full duplex if you want to record and playback using the same card. The PVR350 has it's own audio-out.
 
  
 +
For users with no access to digital broadcasts, or broadcasts restricted by encryption, analog capture devices are needed. Cheap capture devices are called ''framegrabbers'', and require independent capture and software encoding of audio and video. Very cheap ones cannot capture audio, meaning they must be used with a separate sound card. These are nothing but a hassle to deal with. The recommended type is a hardware encoder. These will output compressed MPEG files similarly to how the digital tuners behave.
 +
 +
===Video display (graphics) card===
 +
:''Main article: [[Video display card]], category: [[:Category:Video display cards|video display cards]]''
 +
 +
Depending on your needs you will want one with ''S-Video out'' (normal TV), ''SVGA'' (monitor/most HDTV screens) or
 +
''DVI-D / DVI-I'' (projector/LCD/plasma/HDTV screens).
 +
 +
===Sound card===
 +
:''Main article: [[Sound card]], category: [[:Category:Sound cards|Sound cards]]''
 +
 +
You need a separate one for each grabber card, if it doesn't have an on-board sound digitizer. Nowadays
 +
most motherboards have built-in sound'cards'. Be sure the card is full duplex if you want to record and
 +
playback using the same card. The PVR350 has its own audio-out.
 +
 +
==Performance issues==
 
Whilst the basic hardware configuration is simple, with this being the world of PC hardware and Linux, there are a million and one options that you may wish to take into account.
 
Whilst the basic hardware configuration is simple, with this being the world of PC hardware and Linux, there are a million and one options that you may wish to take into account.
  
Most MythTV users seem to prefer hardware capture devices such as the Hauppauge PVR-250 and 350 TV cards (or digital DVB cards), which do all of the capture and compression on board. This means your CPU doesn't have to compress the TV stream itself, making the basic CPU requirements very low indeed. (e.g. A K2/266MHz system can use a PVR-350 to record one stream while simultaneously using it to watch such a recording.)  People who use "dumb" capture cards (i.e. those without onboard compression) have to compress the TV stream in software using either MPEG-4 or RTjpeg, and so will require free CPU time in order to watch and record TV. Here are some rough guidelines taken from mythtv.org as regards software encoding:
+
Most MythTV users seem to prefer hardware capture devices such as the Hauppauge PVR-150]] and PVR-500]] TV cards (or digital DVB cards), which do all of the capture and compression on board. This means your CPU doesn't have to compress the TV stream itself, making the basic CPU requirements very low indeed. People who use "dumb" capture cards (i.e. those without onboard compression) have to compress the TV stream in software using either [[MPEG-4]] or [[RTjpeg]], and so will require free CPU time in order to watch and record TV. Here are some rough guidelines taken from mythtv.org as regards software encoding:
  
* A PIII/733MHz system can encode one video stream using the MPEG-4 codec using 480x480 capture resolution. This does not allow for live TV watching, but does allow for encoding video and then watching it later.<br>
+
* A PIII/733MHz system can encode one video stream using the [[MPEG-4]] codec using 480x480 capture resolution. This does not allow for live TV watching, but does allow for encoding video and then watching it later.
* A developer states that his AMD1800+ system can almost encode two MPEG-4 video streams and watch one program simultaneously.<br>
+
* A developer states that his AMD1800+ (~1.6Ghz) system can almost encode two [[MPEG-4]] video streams and watch one program simultaneously
* A PIII/800MHz system with 512MB RAM can encode one video stream using the RTjpeg codec with 480x480 capture resolution and play it back simultaneously, thereby allowing live TV watching.
+
* A PIII/800MHz system with 512MB RAM can encode one video stream using the [[RTjpeg]] codec with 480x480 capture resolution and play it back simultaneously, thereby allowing live TV watching.
* A dual Celeron/450MHz is able to view a 480x480 MPEG-4/3300kbps file created on a different system with 30% CPU usage.<br>
+
* A dual Celeron/450MHz is able to view a 480x480 [[MPEG-4]]/3300kbps file created on a different system with 30% CPU usage.
* A P4 2.4GHz machine can encode two 3300Kbps 480x480 MPEG-4 files and simultaneously serve content to a remote frontend.
+
* A P4 2.4GHz machine can encode two 3300Kbps 480x480 [[MPEG-4]] files and simultaneously serve content to a remote frontend.
 +
* A Pentium Celeron 600 MHz with a Hauppauge PVR-150 can record and playback [[MPEG-2]] material simultaneously.
 +
 
 +
Further information can be found at the [http://pvrhw.goldfish.org/ PVR hardware database], which is a list where users report their system configurations and performance under various conditions.
  
 
An important addendum applies to all of you wishing to use HDTV with a '''PCHDTV''' card. Playback of HDTV is *very* computationally intensive, and requires a Pentium class processor of at least 1.3GHz or equivalent in conjunction with a graphics card with accelerated drivers, according to the documents at http://www.pchdtv.com. Pretty much any system built in the last two years with an nVidia graphics card will be fine.
 
An important addendum applies to all of you wishing to use HDTV with a '''PCHDTV''' card. Playback of HDTV is *very* computationally intensive, and requires a Pentium class processor of at least 1.3GHz or equivalent in conjunction with a graphics card with accelerated drivers, according to the documents at http://www.pchdtv.com. Pretty much any system built in the last two years with an nVidia graphics card will be fine.
  
One of the most perplexing decisions facing a newcomer is the mystical frontend/backend configuration, which I'll attempt to explain here. MythTV actually comes in two parts; a backend server which handles all the complicated stuff (control of the TV cards, commercial detection, file serving to frontends, the program database) and a frontend which is the bit you (hopefully) see on your screen, which handles the display of the interface, decoding and playback of audio/video streams and user interaction (such as remote controls). Most people first opt for a combined frontend/backend, which means running the frontend and backend software on the same machine. Other configurations are a single backend and multiple remote frontends, and multiple backends connected to multiple frontends. If this all sounds confusing, read on.
+
==System architecture==
 +
One of the most perplexing decisions facing a newcomer is the mystical frontend/backend configuration, which I'll attempt to explain here. MythTV actually comes in two parts:
 +
 
 +
* [[Mythbackend|backend server]] - handles all the complicated stuff (control of the TV cards, commercial detection, file serving to frontends, the program database)
 +
* [[Mythfrontend|frontend]] - the bit you (hopefully) see on your screen, which handles the display of the interface, decoding and playback of audio/video streams and user interaction (such as remote controls).
 +
 
 +
Most people first opt for a combined frontend/backend, which means running the frontend and backend software on the same machine. Other configurations are a single backend and multiple remote frontends, and multiple backends connected to multiple frontends. If this all sounds confusing, read on.
  
'''Combined backend/frontend'''<br>
+
=== Combined backend/frontend ===
Here you run [[Myth Backend]] and [[MythFrontend]] in tandem on a single machine, to which we can also attach additional frontends. This is the simplest setup, but has a few disadvantages:
+
Here you run [[mythbackend]] and [[mythfrontend]] in tandem on a single machine, to which we can also attach additional frontends. This is the simplest setup, but has a few disadvantages:
 
* If this box is living in a social area, such as under the TV, you're probably going to have to jump through a few hoops to get it nice and quiet.
 
* If this box is living in a social area, such as under the TV, you're probably going to have to jump through a few hoops to get it nice and quiet.
 
* Again, you're probably going to want this box as appliance-like as possible, which usually means a pretty case that isn't too huge. This will limit your ability to expand the box without moving to separate frontends and backends
 
* Again, you're probably going to want this box as appliance-like as possible, which usually means a pretty case that isn't too huge. This will limit your ability to expand the box without moving to separate frontends and backends
 
* There is a limit to the number of TV cards a single computer is able to hold
 
* There is a limit to the number of TV cards a single computer is able to hold
The ideal solution to these problems is running [[Myth Backend]] and [[MythFrontend]] on separate machines.
+
The ideal solution to these problems is running [[mythbackend]] and [[mythfrontend]] on separate machines.
  
'''Separate backend and frontend'''<br>
+
=== Separate backend and frontend ===
Here, all we do is take our backend software and throw it into some box out of sight - under the stairs seems a popular location. Since [[Myth Backend]] does all the hard work, all the equipment for that hard work (TV cards, MySQL server, 30 terabyte RAID array) will also reside in this computer. In one fell swoop we've removed most of the hot and noisy components from under our TV and placed them somewhere they won't be noticed, so we can concentrate on making our frontend as pretty and as quiet as possible. All that needs to be done is that the frontend and backend need to be networked together, and a few minor configuration changes are made to the way Myth operates, and we're all set. We can also connect as many additional frontends as we have capacity for if you wish to show your recorded TV shows elsewhere in the house. Again however, there are disadvantages:
+
Here, all we do is take our backend software and throw it into some box out of sight - under the stairs seems a popular location. Since [[mythbackend]] does all the hard work, all the equipment for that hard work (TV cards, MySQL server, 30 terabyte RAID array) will also reside in this computer. In one fell swoop we've removed most of the hot and noisy components from under our TV and placed them somewhere they won't be noticed, so we can concentrate on making our frontend as pretty and as quiet as possible. All that needs to be done is that the frontend and backend need to be networked together, and a few minor configuration changes are made to the way Myth operates, and we're all set. We can also connect as many additional frontends as we have capacity for if you wish to show your recorded TV shows elsewhere in the house. Again however, there are disadvantages:
 
* Setting up two machines and networking them all up will incur additional cost and complexity
 
* Setting up two machines and networking them all up will incur additional cost and complexity
 
* We've still only got a single machine that can accept a limited number of TV cards
 
* We've still only got a single machine that can accept a limited number of TV cards
 
Which brings us on to...
 
Which brings us on to...
  
'''Multiple backends'''<br>
+
=== Multiple backends ===
Whilst most households are content with a single backend with one or two TV cards, if you want to provide TV to alot of frontends simultaneously, you're going to require a large amount of TV cards which your single backend won't be able to support. Here we simply add more backends into the fray, and again network them up in such a way that all the Myth machines can talk to one another. This essentially provides you with TV that is limited pretty much only by your wallet!
+
Whilst most households are content with a single backend with one or two TV cards, if you want to provide TV to multiple frontends simultaneously, you're going to require a large number of TV cards which your single backend won't be able to support. Here we simply add more backends into the fray, and again network them up in such a way that all the Myth machines can talk to one another. This essentially provides you with TV that is limited pretty much only by your wallet!
  
 
Of course, it is also possible to mix and match a bit. My personal setup consists of two combined backend/frontends (one runs with a PVR-250, the other with a DVB card) and a single "dumb" frontend which is primarily used for watching recorded content.
 
Of course, it is also possible to mix and match a bit. My personal setup consists of two combined backend/frontends (one runs with a PVR-250, the other with a DVB card) and a single "dumb" frontend which is primarily used for watching recorded content.
  
Advanced configurations can include making discless (as in no hard drive) frontends which can boot over the network which makes for a ''very'' quiet machine, and storing/loading content from machines that have nothing to do with MythTV whatsoever. Again to cite my own example, the [[Myth Backend]] boxes store all of the TV content, but the database lives on my Debian file server, as does all of my music and video content. Shares have been set up via NFS or Samba so that the backend machines can access the files from the file server, and pass them along to the frontends.
+
Advanced configurations can include making [[Diskless Frontend|diskless (as in no hard drive) frontends]] which can boot over the network which makes for a ''very'' quiet machine, and storing/loading content from machines that have nothing to do with MythTV whatsoever. Again to cite my own example, the [[mythbackend]] boxes store all of the TV content, but the database lives on my Debian file server, as does all of my music and video content. Shares have been set up via NFS or Samba so that the backend machines can access the files from the file server, and pass them along to the frontends.
  
 
As you can see, given enough machines to play with, MythTV can be expanded to do pretty much anything!
 
As you can see, given enough machines to play with, MythTV can be expanded to do pretty much anything!
Line 52: Line 74:
 
Now that we've covered what Myth is capable of in terms of expandability, I'll delve into the more specific questions concerning types of hardware in the following sections:
 
Now that we've covered what Myth is capable of in terms of expandability, I'll delve into the more specific questions concerning types of hardware in the following sections:
  
* /[[File Storage]]: How much disc space will I need for all this?
+
* [[File Storage]]: How much disc space will I need for all this?
* /[[Net Work]]: How much network bandwidth am I going to need?
+
* [[Network]]: How much network bandwidth am I going to need?
  
 
== Additional Customization ==
 
== Additional Customization ==
Line 59: Line 81:
 
Many people also look beyond the basic hardware for more customized and aesthetically pleasing solutions
 
Many people also look beyond the basic hardware for more customized and aesthetically pleasing solutions
  
* [[I R Blaster How To|IRBlaster]] Infared Transmitter
+
* [[I R Blaster How To|IRBlaster]] Infared Transmitter http://mythblasters.gotdns.com/
 +
 
 +
* [[Cases]]: Found a nice case that integrates with your stereo components?
 +
* [[Cooling Quietly]]: How to keep your MythTV system quiet
 +
* [[Bare Bones System|Bare Bones Systems]]: Some recommendations to get you started
 +
* [[:Category:Remote_Controls|Remote Controls]]: How to become a couch potato
 +
* [[Commercial MythTV System]]: MythTV based systems for sale as a consumer device
  
* /[[Pc Cases]]: Found a nice case that integrates with your stereo components?
+
* External Link [http://pvrhw.goldfish.org PVR Hardware Database] - Collection of user's hardware set-ups
* /[[Cooling Quietly How To]]: How to keep your MythTV system quiet
 
* /[[Bare Bones Systems]]: Some recommendations to get you started
 
* /[[Remote Controls]]: How to become a couch potato
 
* /[[Commercial MythTv Systems]]: MythTV based systems for sale as a consumer device
 
  
* External Link [http://perens.com/[[Free Software]]/gyration.html Gyration Media Center Remote ]
+
There is also [http://bit.blkbk.com/ an effort] to provide a working [[mythfrontend]] on an XBOX.
  
There is also [http://bit.blkbk.com/ an effort] to provide a working [[MythFrontend]] on an XBOX.
+
[[Category:Hardware| ]]

Revision as of 07:11, 14 November 2011

This article gives an overview of the hardware requirements for a MythTV system.

Basic requirements for a MythTV setup

As you probably know, Linux will run on pretty much anything. MythTV relies on the FFmpeg codecs for any video handling, which are heavily optimized for the x86 architecture. Due to this, modern 64-bit processors from AMD and Intel are the preferred basis for a MythTV system. Older 32-bit AthlonXPs and Pentium 4s, low power VIA systems, and the increasingly common ARM systems, should be avoided.

Video capture card

Main article: Video capture card

All recording through MythTV is performed by the backend. The backend can handle as many tuners as you can physically fit in the system, and if that is not enough, you can run multiple backends located on additional hardware to expand your capabilities. Each simultaneous recording and Live TV session requires a tuner input. If you want to have padding on back-to-back recordings, you need additional tuners. Note that only one backend is needed on the network, and additional PCs can be configured as frontends with no local capture card.

Some users will have access to IPTV based off the FreeBox model, for which MythTV can use a virtual network tuner. Most users will need some form of digital tuner. North American users need ATSC, European and Australian users need DVB, and Japanese and South American users need DVB. Both IP and digital television makes use of streams compressed by the broadcaster. MythTV need merely copy this data to disk for pristine, lossless quality.

For users with no access to digital broadcasts, or broadcasts restricted by encryption, analog capture devices are needed. Cheap capture devices are called framegrabbers, and require independent capture and software encoding of audio and video. Very cheap ones cannot capture audio, meaning they must be used with a separate sound card. These are nothing but a hassle to deal with. The recommended type is a hardware encoder. These will output compressed MPEG files similarly to how the digital tuners behave.

Video display (graphics) card

Main article: Video display card, category: video display cards

Depending on your needs you will want one with S-Video out (normal TV), SVGA (monitor/most HDTV screens) or DVI-D / DVI-I (projector/LCD/plasma/HDTV screens).

Sound card

Main article: Sound card, category: Sound cards

You need a separate one for each grabber card, if it doesn't have an on-board sound digitizer. Nowadays most motherboards have built-in sound'cards'. Be sure the card is full duplex if you want to record and playback using the same card. The PVR350 has its own audio-out.

Performance issues

Whilst the basic hardware configuration is simple, with this being the world of PC hardware and Linux, there are a million and one options that you may wish to take into account.

Most MythTV users seem to prefer hardware capture devices such as the Hauppauge PVR-150]] and PVR-500]] TV cards (or digital DVB cards), which do all of the capture and compression on board. This means your CPU doesn't have to compress the TV stream itself, making the basic CPU requirements very low indeed. People who use "dumb" capture cards (i.e. those without onboard compression) have to compress the TV stream in software using either MPEG-4 or RTjpeg, and so will require free CPU time in order to watch and record TV. Here are some rough guidelines taken from mythtv.org as regards software encoding:

  • A PIII/733MHz system can encode one video stream using the MPEG-4 codec using 480x480 capture resolution. This does not allow for live TV watching, but does allow for encoding video and then watching it later.
  • A developer states that his AMD1800+ (~1.6Ghz) system can almost encode two MPEG-4 video streams and watch one program simultaneously
  • A PIII/800MHz system with 512MB RAM can encode one video stream using the RTjpeg codec with 480x480 capture resolution and play it back simultaneously, thereby allowing live TV watching.
  • A dual Celeron/450MHz is able to view a 480x480 MPEG-4/3300kbps file created on a different system with 30% CPU usage.
  • A P4 2.4GHz machine can encode two 3300Kbps 480x480 MPEG-4 files and simultaneously serve content to a remote frontend.
  • A Pentium Celeron 600 MHz with a Hauppauge PVR-150 can record and playback MPEG-2 material simultaneously.

Further information can be found at the PVR hardware database, which is a list where users report their system configurations and performance under various conditions.

An important addendum applies to all of you wishing to use HDTV with a PCHDTV card. Playback of HDTV is *very* computationally intensive, and requires a Pentium class processor of at least 1.3GHz or equivalent in conjunction with a graphics card with accelerated drivers, according to the documents at http://www.pchdtv.com. Pretty much any system built in the last two years with an nVidia graphics card will be fine.

System architecture

One of the most perplexing decisions facing a newcomer is the mystical frontend/backend configuration, which I'll attempt to explain here. MythTV actually comes in two parts:

  • backend server - handles all the complicated stuff (control of the TV cards, commercial detection, file serving to frontends, the program database)
  • frontend - the bit you (hopefully) see on your screen, which handles the display of the interface, decoding and playback of audio/video streams and user interaction (such as remote controls).

Most people first opt for a combined frontend/backend, which means running the frontend and backend software on the same machine. Other configurations are a single backend and multiple remote frontends, and multiple backends connected to multiple frontends. If this all sounds confusing, read on.

Combined backend/frontend

Here you run mythbackend and mythfrontend in tandem on a single machine, to which we can also attach additional frontends. This is the simplest setup, but has a few disadvantages:

  • If this box is living in a social area, such as under the TV, you're probably going to have to jump through a few hoops to get it nice and quiet.
  • Again, you're probably going to want this box as appliance-like as possible, which usually means a pretty case that isn't too huge. This will limit your ability to expand the box without moving to separate frontends and backends
  • There is a limit to the number of TV cards a single computer is able to hold

The ideal solution to these problems is running mythbackend and mythfrontend on separate machines.

Separate backend and frontend

Here, all we do is take our backend software and throw it into some box out of sight - under the stairs seems a popular location. Since mythbackend does all the hard work, all the equipment for that hard work (TV cards, MySQL server, 30 terabyte RAID array) will also reside in this computer. In one fell swoop we've removed most of the hot and noisy components from under our TV and placed them somewhere they won't be noticed, so we can concentrate on making our frontend as pretty and as quiet as possible. All that needs to be done is that the frontend and backend need to be networked together, and a few minor configuration changes are made to the way Myth operates, and we're all set. We can also connect as many additional frontends as we have capacity for if you wish to show your recorded TV shows elsewhere in the house. Again however, there are disadvantages:

  • Setting up two machines and networking them all up will incur additional cost and complexity
  • We've still only got a single machine that can accept a limited number of TV cards

Which brings us on to...

Multiple backends

Whilst most households are content with a single backend with one or two TV cards, if you want to provide TV to multiple frontends simultaneously, you're going to require a large number of TV cards which your single backend won't be able to support. Here we simply add more backends into the fray, and again network them up in such a way that all the Myth machines can talk to one another. This essentially provides you with TV that is limited pretty much only by your wallet!

Of course, it is also possible to mix and match a bit. My personal setup consists of two combined backend/frontends (one runs with a PVR-250, the other with a DVB card) and a single "dumb" frontend which is primarily used for watching recorded content.

Advanced configurations can include making diskless (as in no hard drive) frontends which can boot over the network which makes for a very quiet machine, and storing/loading content from machines that have nothing to do with MythTV whatsoever. Again to cite my own example, the mythbackend boxes store all of the TV content, but the database lives on my Debian file server, as does all of my music and video content. Shares have been set up via NFS or Samba so that the backend machines can access the files from the file server, and pass them along to the frontends.

As you can see, given enough machines to play with, MythTV can be expanded to do pretty much anything!

Now that we've covered what Myth is capable of in terms of expandability, I'll delve into the more specific questions concerning types of hardware in the following sections:

  • File Storage: How much disc space will I need for all this?
  • Network: How much network bandwidth am I going to need?

Additional Customization

Many people also look beyond the basic hardware for more customized and aesthetically pleasing solutions

There is also an effort to provide a working mythfrontend on an XBOX.