Choosing Frontend Hardware
The goal of this page is to outline the options available for dedicated frontend hardware based on the realities of television and retail video content at the beginning of 2011. The separated nature of the MythTV frontend/backend system allows for some interesting design choices, allowing for small, compact playback devices.
- 1 System Considerations
- 2 Software Playback
- 3 Hardware Playback
- 4 Prebuilt Systems
- 5 UPnP Playback
MythTV has been designed to operate on x86 based computers. While it will compile and run on other architectures such as PPC and ARM, they will neither be as heavily tested, nor will the decoding libraries be as heavily optimized. For new purchases, modern mainstream processors such as the Athlon II, Phenom, Core 2, and Core i3/5 lines are recommended.
MythTV is intended to run dedicated on standard PC hardware, and has never been designed to be particularly miserly with memory. For standard definiton output and a lightweight theme, consider 256MB of memory to be an absolute minimum. Beyond that, the system is going to start swapping heavily, and usability will plummet. For high definition frontends, 512MB is a minimum, and 1GB if using a theme that uses artwork heavily.
nVidia has long been providing reliable hardware and drivers for using on Linux. The recommended video hardware for use with MythTV is anything nVidia 8-series or better. If you need analog television output, only the 8 and 9 series support such, while the GT or later series do not. ATI/AMD has improved significantly over the past years, but they have a very poor track record for stable Linux support, and should not be considered. The Intel graphics available on the Core i3 and i5 processors is generally sufficient, while older Intel graphics will not have sufficient power for the OpenGL video renderer. However, note that they do not have the same amount of flexibility in dealing with odd resolutions and misbehaving TVs as can be found in the nVidia graphics.
The recommended minimum network for use with MythTV is wired 100 Mbps Ethernet. Gigabit Ethernet is not needed, but can provide better responsiveness while seeking during video playback. Powerline networking generally has sufficient bandwidth, and is decently reliable, but suffers from the fact that it is a broadcast architecture, and multiple frontends will quickly saturate the system. Further, there are problems with many homes using split phase wiring that will effectively cut the network in half.
Wireless networks are not recommended. 802.11b is completely unusable. 802.11g has marginally enough bandwidth for broadcast digital content, but suffers from unreliability and periodic dropouts. MythTV is designed to run on reliable networks, and in order to cut down on latency for live playback, is not sufficiently buffered to handle such dropouts. 802.11n has enough bandwidth, but it suffers from the same dropouts as other forms of wireless, and it is still a broadcast architecture, that will limit the number of simultaneous frontends that can be used. 5 GHz wireless gear like 802.11a and 802.11n will be better than 2.4 GHz gear, because the available spectrum is much larger and relatively unused, however there are plenty of ways to route and disguise wired ethernet even if cutting into walls is not an option.
The disk requirements for a dedicated frontend are very minimal. A normal Linux installation including MythTV will take 2-3GB. Stripped down builds can be done for under 1 GB. Frontends can be booted over the network, from USB, from flash drives, 2.5" desktop laptop drives, or normal 3.5" drives. Beyond startup, the only needs MythTV will have are for system logging and image cache. If you have a lot of MythVideo content with artwork, and a graphically intensive theme, the image cache can grow very large, easily into the several GB range. Pairing an SSD for the system drive (OS) with a large conventional HDD for mass storage make for quiet, low power frontend / backend.
There are three primary routes for audio output in MythTV: analog, digital SPDIF, or digital HDMI. For analog audio, there is perceivable benefit to using a discrete audio card, as they offer much better isolation than onboard sound codecs, and will result in reduced noise. For digital audio, onboard versus discrete will make no difference.
Modern videos cards support HDMI, as well as using audio over HDMI. The nVidia 8 and 9 series cards provide a 2-pin header to allow passthrough from a SPDIF source. Motherboards with integrated 8 or 9 series video, as well as the GT series, will expose an HDA HDMI device to use directly. The GT 430 is currently the only card capable of bit-streaming high definition audio codecs, as found on Blu-ray discs.
Software decoding of video content is entirely dependent on the CPU, so the content you want to play will determine how much or how little you need.
Standard definition content will all be fairly trivial to handle. Standard definition MPEG-2 content will range from 1-2 Mbps digital recordings, to 6-7 Mbps DVDs. All of which can be handled by late model P3s or better. MPEG-4 Nuppelvideo recordings and DVD transcodes should be fine with similar CPU requirements. H.264 content from digital recordings and transcoded DVDs may require a bit more power.
- Athlon XP, Pentium 4, or higher end Pentium 3
The biggest problem dealing with digital recordings is that MythTV records them, unaltered, as they are broadcast. MythTV has no control over the resolution, quality, or bitrate, so if you are recording digital, you must size your frontend to allow for whatever the broadcaster may send. ATSC content in North America will top out around 18 Mbps, and will typically be closer to 14-16 Mbps. Any non-mobile Athlon 64 or Core 2 processor will be sufficiently fast for decoding this content. Higher end Athlon XPs and Pentium 4s can handle this content as well. Atom processors will likely be too slow to manage. Older Core and Pentium M processors were generally only found on slower, mobile systems, and may be too slow as well.
- Athlon 64 or Core 2
DVB broadcasters are allowed to use H.264 as well as the older MPEG-2. H.264 is considerably more intensive than MPEG-2, however it offers a concept called 'slicing', wherein a video frame is cut into multiple discrete regions that can be encoded and decoded separately. It allows multi-threaded decoding, allowing multi-core processors to be used more efficiently. HD DVB content under 14 Mbps should be usable by any non-mobile Athlon 64 X2 or Core 2 Duo. Higher bitrate may need faster chips beyond the base model. Slower Atoms, Core Duos, and Pentium Ds will struggle with this content.
- Athlon 64 X2 or Core 2 Duo
The HD-PVR is a capture device capable of recording HD component video to H.264. Unlike DVB broadcasts, the output of this device will be single sliced, meaning only one processor core can be used to decode it, presenting a more difficult challenge. An Athlon 64 processor of at least 3GHz, or Core 2 of at least 2.6 GHz, is recommended for decoding content at the full 13.5 Mbps the HDPVR can output. Since the video is encoded by the device, this bitrate can be reduced in the Recoding Profiles to allow use on slower hardware.
- Athlon 64 (>3 GHz) or Core 2 (>2.6 Ghz)
This media will be the most difficult to handle in MythTV. Blu-ray Discs contain MPEG-2, H.264, or VC-1 video at up to 40 Mbps, but more typically between 25-30 Mbps. An Athlon 64 X2 of at least 3 GHz, or Intel Core 2 Duo of at least 2.6 GHz, is recommended for viewing of this content. Triple and quad core versions of these processors can give some additional headroom.
- Athlon 64 X2 (>3 GHz) or Core 2 Duo (>2.6 GHz)
MythTV currently supports two hardware playback APIs that offer the ability to offload decoding from the CPU to another device. While these devices can be used to breathe life into an otherwise underpowered system, hardware decoders will never be as robust or flexible as software decoders, and it is recommended one chose a system with enough CPU power that it can be fallen back on if needed.
This API is available on any nVidia card, 8 series or newer. It supports full offloading of MPEG-2, H.264, and VC1. The availability of this allows older and slower systems, notably the ION platform, to remain useful with video content that far exceeds the capability of the processor.
This API is used on a series of Broadcom MiniPCIe and ExpressCard adapters for use in laptops and small form factor systems. These devices offer similar capabilities to VDPAU, but exist for decoding only. A separate video card will need to be used for output.
This decode API is currently in use by AMD and Intel for use on their graphics hardware. Support for this was recently added to the development branch, to be available with the upcoming release of 0.25. Decoding capability using this should be comparable to VDPAU, however the nVidia solution is still preferred due to its maturity, as well as the post processing features it offers.
This decode API is used on Windows. Support for this was recently added to the development branch, to be available with the upcoming release of 0.25.
This decode API is used on OSX. Support for this was recently added to the development branch, to be available with the upcoming release of 0.25.
These are interfaces that are either not yet supported, or have been removed from MythTV.
This API is an old interface previously used by nVidia, supported by Intel and Via hardware, and promised but never delivered for AMD hardware. This interface would only offer partial offload of MPEG-2 video, allowing HD MPEG-2 playback on low end Athlon XPs and Pentium 4s, as well as some high end Pentium 3s. The limitations of this interface, and severe restrictions it places on the OSD, resulted in support for this being dropped in MythTV 0.25, and use is not recommended for any version prior to that.
This API is an old interface used by the Hauppauge PVR-350 tuner card. It offered standard definition MPEG-2 decode, and basic framebuffer output. The video it was capable of decoding was usable on even midrange Pentium 3s. Support for this was dropped from MythTV 0.23, and use is not recommended for any version prior to that.
Below are several examples of commercial systems available for users who do not want to build their own frontends.
ASRock Vision 3D
The ASRock Vision 3D is a small-form-factor, pre-built system that comes with mobile Intel Core i CPUs and VDPAU-compatible nVidia GeForce graphics. The mobile Core i CPU is a very efficient processor that has sufficient headroom to allow software based decoding or transcoding or commercial flagging when necessary, but idles at low power. The VDPAU support allows offloading most video decoding and presentation for playback to the video card. Additional information is available at the Vision 3D Series Manufacturing page.
Generally, only worthwhile if you can find an older model with a VDPAU-compatible nVidia GPU.
The nVidia ION platform bundles a CPU and nVidia GPU together. The CPU may be of the ATOM variety, while low power is also very sluggish for general UI interactions. The nVidia GPU is able to provide full HD playback using the VDPAU libraries with high quality deinterlacing.
As of Mythtv version 0.28, Raspberry Pi (Model Pi 2 or better) is supported as a front end, using the built in OpenMAX acceleration, and an MPEG2 license, which is purchased from the Raspberry Pi foundation for £2.00, or around $2.65.
The Raspberry Pi 3 is capable of running an SD frontend without the additional cost or complexity of purchasing a licence. It may manage HD too at a pinch.
The following are not recommended for use as frontends, either due to lack of power or lack of memory to properly run a frontend.
- Apple TV
- HP t5720 / t5725 thin client
- Playstation 3
MythTV offers a UPnP server running on the backend that will stream video or music content to UPnP compliant clients. UPnP clients can be purchased as a separate device, can be found in newer DVD/Blu-ray players, and even in most TVs. UPnP playback does come with limitations:
- Clients can only access pre-recorded content and cannot use live tv.
- Clients can access in-progress recordings, but most will only play up to the point that was recorded at the time playback was started, requiring one to repeatedly exit and re-enter playback.
- Clients cannot use the commercial skiplist or cutlist.
- Mythbackend cannot perform live transcodes of content for streaming to UPnP clients. The content will have to exist on disk in a format the client can play directly.