Difference between revisions of "Configuring HDTV"
m (→HDTV and Satellite TV)
m (→Native HDMI Capture)
|Line 47:||Line 47:|
=== Native HDMI Capture ===
=== Native HDMI Capture ===
Several options exist in Windows to capture HDCP-free HDMI signals. No
Several options exist in Windows to capture HDCP-free HDMI signals. No drivers are available for any of these cards they rely on filters for compression, and the native compression is a poor, proprietary codec. Until these hurdles are overcome, current methods of HDMI capture are impractical for MythTV. Even then, the limitations placed on the device by copy protection make this impracticable.
=== Impossible Stuff ===
=== Impossible Stuff ===
Revision as of 07:02, 24 June 2013
There are different HDTV formats for North America and Europe. Parts of this information may apply to other countries that use HDTV as well.
For information on hardware used by users to play back HD content, please see (and update) HD Playback Reports.
- 1 Understanding HDTV
- 2 North America
- 3 Europe
- 4 Hardware
- 5 Playing HD Material
- 6 Transcoding HDTV
- 7 See also
HDTV (High Definition Television) is sent as stream of binary data encoded in the radio spectrum. A digital tuner works much like a modem extracting the original digital data. Unlike analog television capture, where a hardware encoder is desirable, compression of High Definition material takes place at the provider. HD material is received as a digital stream and written directly to disk. In North America, HD material is transmitted in MPEG-2 format. In Europe, Australia, and other parts of the world using the DVB standard, some streams are available as MPEG-2, and others as h.264.
HDTV can be delivered via three mediums: Broadcast (Over the Air), Cable, and Satellite. The modulation for each is different, sometimes requiring different hardware.
MPEG-2 versus H.264
When agreeing upon standards for digital television, Europe and much of the rest of the world implemented the DVB standard, which permits broadcasters to use either MPEG-2 or H.264 codecs. In the United States, ATSC permits only MPEG-2 as the codec. Each format has its advantages. MPEG-2 is a well understood, established video format. Playback is not computationally demanding, and most modern dual-core (and many recent single core) systems can easily manage playback. H.264 is a newer standard, but improves upon MPEG-2 in several ways. H.264 can achieve identical quality to MPEG-2 at 60% of the bitrate. Accordingly, a full-channel-bitrate (17.89 Megabit/s) H.264 stream compared with an identical-bitrate MPEG-2 stream will look substantially better. This comes at a much higher computational expense. Playing 720p and 1080i H.264 streams (at full bitrate) can be difficult, even on recent systems. Playing 1080p H.264 can often be nightmarish for those unfamiliar with tweaking playback options.
Bitrate (Or, if you read nothing else, read this)
Uninformed users frequently make a point of asking whether their hardware is capable of "1080p playback." Similarly uninformed users reply that a given setup is "enough" or "not enough." In reality, resolution of the material is a relatively minor part of the playback equation. Users who get their 1080p material via bittorrent or other questionable means often think that because they are able to play back the file, their system is capable of playing back all 1080p material. This is seldom the case. Most pirated HD material has been transcoded to substantially lower bitrates, often cutting the file size/bitrate more than in half. At proportionately lower bitrates, processor requirements are also proportionately lower. In reality, a full-bitrate H.264 or MPEG-2 from a Blu-ray/HD-DVD Disk may be substantially more difficult or impossible to play back for the same machine. While "true" Blu-ray and HD-DVD material may be encoded up to 40 Megabits per second, television is broadcast in bitrates up to 17.89 Megabits per second, and many "1080p rips" found on the internet are transcoded below 10 Megabits per second. In effect, processor requirements for the "real thing" may be up to four times as high as the user expects.
In some cases, a lower bitrate file may actually be more difficult to play. This is generally due to inexperienced transcoders using options that purport to retain higher quality at lower bitrate, as well as neglecting to utilize sliced encoding. In reality, the quality retained by processor intensive encoding options is relatively small. The larger problem for linux playback is the failure to encode in so-called "slices," which render linux systems (currently) incapable of multithreading the playback. This means that a multiple core system cannot be used to fullest effect, and that playback must instead rely on the raw clock speed of a single core.
Multiplexing and Transport Streams
Central to any discussion of digital reception is the notion of multiplexes. With the advent of digital television, broadcasters and cable companies are capable of tuning the resolution, bitrate, and packaging of their channels. A 6 Mhz Channel can accommodate 17.89 Megabits per second worth of data. Television providers are now free to carve the bandwidth of a single channel up into as many Transport Streams as they like. In short, one 17.89 Mbit/s channel can be simultaneously carrying multiple Transport Streams, each of which can have multiple audio tracks. Broadcasters now commonly "multiplex," or package, many standard definition channels in the space of a single 6 Mhz channel. In current versions on MythTV, it is possible to record any number of streams from a single multiplex, assuming the user is receiving television via ATSC, QAM, or DVB. In effect, this enables the user to record multiple channels at once on a single tuner.
Antenna HDTV broadcast
This is called OTA (Over-The-Air), or ATSC. ATSC tuners capture the raw, compressed digital stream broadcast by the provider. Antenna Broadcasters sometimes include multiple subchannels, all of which are part of the same transport stream. In some areas, subchannels include encrypted pay channels.
The standard is called QAM or "ClearQAM." Many of the OTA Tuner cards like AirStar HD-5000 or PcHDTV work with Clear (unencrypted) QAM. It just takes a little bit more time and energy getting it to work. Verizon FIOS also uses QAM for its unencrypted channels.
Another popular option is FireWire capture of digital streams directly from a cable box. As with the ATSC tuners mentioned above, the CPU requirements for this capture method are minimal, as the backend machine is simply copying an MPEG-2 video stream to disk.
Another option is to use a digital tuner like the Silicondust HDHomeRun Prime that can utilize CableCARD. This will allow you to record shows that are not copy protected. These "copy freely" shows may be encrypted and inaccessible to a standard QAM tuner, but will be decrypted and made available through the HDHomeRun Prime.
HDTV and Satellite TV
All channels from Satellite sources are digital but not all of them are in HDTV Format. Most are Encrypted, but not all of them (For example LyngSat Free OTA).
Some cable and satellite boxes include a firewire port from which raw MPEG-2 streams can be captured. MythTV can record unencrypted channels from this port.
In January 2008, Hauppauge Computer Works announced the Hauppauge HD-PVR, a component capture device capable of on-the-fly H.264 hardware transcoding of material up to 15 Megabits per second at 1080i. The HD-PVR makes it possible to record HD material from any device with a component output. While there is a quality hit from the Digital->Analog->Digital conversion, the quality of the capture is still substantially higher than any Standard Definition source. See the Hauppauge HD-PVR page for more information.
Native HDMI Capture
Several options exist in Windows to capture HDCP-free HDMI signals. No Linux drivers are available for any of these cards as they rely on DirectShow filters for compression, and the native compression is a poor, proprietary codec. Until these hurdles are overcome, current methods of HDMI capture are impractical for MythTV. Even then, the limitations placed on the device by copy protection make this impracticable.
There is talk of being able to use a cable or satellite STB's RF output to capture HDTV sourced from cable or satellite. This CANNOT be done! Cable & satellite receivers for the home do not & cannot remodulate HDTV signals to ATSC/QAM. If channels are encrypted on cable/satellite - that's how they stay.
Europe uses DVB (Digital Video Broadcasting) for HDTV and digital standard definition video. The concepts of DVB transmission are identical to those of ATSC transmission. A stream is encoded and multiplexed at the television provider, and the user merely writes the stream to disk, preserving a perfect digital copy of the program.
DVB-C For Cable
DVB-T For Terrestrial (Antenna)
A good guide to capture hardware that will work well in MythTV is the Linux TV wiki at http://www.linuxtv.org/wiki/index.php/Main_Page.
CPU requirements for HD recording at minimal because no encoding takes place. Playback of HD content is far more computationally intensive.
Playing HD Material
For information on hardware used by users to play back HD content, please see (and update) HD Playback Reports. VDPAU may also be relevant to your needs, for offloading decode of difficult to play material.
There are two ways to go about playing back HDTV. One is to rely on an VDPAU capable video card with a slower CPU, the other is to use pure CPU processing (the developers are currently working on a third option, but this may not be available in the next release version).
AGP is a minimum as the PCI bus does not have the bandwidth for HDTV unless VDPAU is used. Which is a fine option for those looking to make use of an older system, but due to the hassle it can be to getting it working well it is not really recommended. onger specific to Component Output, as they can be applied to HDMI interfaces as well (for those using DVI to HDMI connections). Display (television) manuals often provide specifications for this purpose.
CPU For MPEG2
The CPU requirements for playing HDTV are significant.
Tip and Tricks
The actual minimum requirements are hard to pin down, as people have reported conflicting results. Relevant factors may include the bus speed, memory speed, CPU speed, kernel version, Linux distribution, and compiler version and optimizations.
- Use two RAM DIMM's to allow for dual channel operation which can provide a significant boost in overall system speed.
- When compiling MythTV from source, use the --enable-proc-opt configure option.
HD rips of BluRay, HD-DVD and TV shows transcoded to lower bitrates and resolutions, as well as having HD Audio formats stripped out and transcoded to AC3, are substantially easier to play on lesser hardware.
Real 1080p Rips
For more information on ripping and playing Blu-ray and HD-DVD disk formats, see High Definition Disk Formats.
Many users who believe their machine capable of HD-DVD or Blu-ray playback have only attempted to play transcoded rips which, as discussed above, often have their bitrates reduced by 50 to 75 percent.
Blu-ray and HD-DVD rips are, for feature only, generally between 17 GB and 35 GB, and up to 50 GB for the entire disc. The bitrate generally varies between approximately 20 Mbit and 40 Mbit. Most Blu-ray and HD-DVD discs now use E-AC3, mlp, or Dolby TrueHD as their only sound format. A few older discs have both the new formats and AC3 Tracks, but this is less and less common.
HDTV recordings typically consume slightly under 9GB per hour.
MythTV supports a "lossless" mpeg2 transcode method. This method will allow the user to cut commercials without losing any of the HDTV quality as only the frames necesary to be reencoded to maintain proper playback will be encoded. For commercial cutting these frames are usually all black, with a possible station logo, and so no quality loss should be seen at all. This transcode also has the added benefit of audio sync correction similar to what ProjectX does, as well as converting the MPEG2 TS stream to a PS stream with up to a possible 20% savings in file size on top of any cuts made.