Difference between revisions of "Choosing Frontend Hardware"
m (→Network Requirements: grammar)
(→XvMC: XvMC support is still present in 0.24, but is being dropped as of 0.25)
|Line 78:||Line 78:|
==== [[XvMC]] ====
==== [[XvMC]] ====
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 MPEG2 video, allowing HD MPEG2 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.
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 MPEG2 video, allowing HD MPEG2 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., and use is not recommended for any version prior to that.
==== [[Hauppauge_PVR-350|PVR-350]] ====
==== [[Hauppauge_PVR-350|PVR-350]] ====
Revision as of 18:18, 8 May 2011
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. 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. 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 recommended minimum network for use with MythTV is wired 10/100 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. 5GHz wireless gear like 802.11a and 802.11n will be better than 2.4GHz 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 1GB. 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. While SSDs may seem ideal for quiet, low power frontends, the only advantage they will provide is a slightly faster bootup, and are simply not worth the cost.
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 GT430 is currently the only card capable of bit-streaming high definition audio codecs, as found on Bluray 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 MPEG2 content will range from 1-2Mbps digital recordings, to 6-7Mbps DVDs. All of which can be handled by late model P3s or better. MPEG4 Nuppelvideo recordings and DVD transcodes should be fine with similar CPU requirements. H264 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 18Mbps, and will typically be closer to 14-16Mbps. 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 H264 as well as the older MPEG2. H264 is considerably more intensive than MPEG2, 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 14Mbps 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 H264. 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.6GHz, is recommended for decoding content at the full 13.5Mbps 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 (>3GHz) or Core 2 (>2.6Ghz)
This media will be the most difficult to handle in MythTV. Bluray disks contain MPEG2, H264, or VC-1 video at up to 40Mbps, but more typically between 25-30Mbps. An Athlon 64 X2 of at least 3Ghz, or Core 2 Duo of at least 2.6GHz, is recommended for viewing of this content. Triple and quad core versions of these processors can give some additional headroom.
- Athlon 64 X2 (>3GHz) or Core 2 Duo (>2.6GHz)
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 MPEG2, H264, 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.
These are interfaces that are either not yet supported, or have been removed from MythTV.
This decode API is currently in use by AMD and Intel for use on their graphics hardware. There is a ticket open in trac and considerable amount of effort spent on supporting this, however at current the only cards reliably usable are nVidia cards using the VAAPI backend. The AMD and Intel drivers were both determined too immature for proper support, and the nVidia cards already have more capability through VDPAU than VAAPI can offer.
This decode API is used on Windows.
This decode API is used on OSX.
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 MPEG2 video, allowing HD MPEG2 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 MPEG2 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.
These are systems that are recommended against for use as frontends, either due to lack of power or lack of memory to properly run a frontend.
- HP t5720 / t5725 thin client
- Playstation 3
- Apple TV
MythTV offers a UPnP server running on the backend that will stream any recording, video, or music content to compliant UPnP clients. UPnP clients can be purchased as a separate device, can be found in newer DVD players, in Bluray players, and even in some higher end TVs. This 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.