Digital Television
By Peter Knaggs
Sorry to start off with such a bunch of alphabet soup, but it seems unavoidable, when trying to make sense of the subject of digital television. In the USA, terrestrial digital video broadcasts are transmitted in 8VSB-modulated ATSC-encoded MPEG-2 transport streams, containing high-definition content in progressive 720p (1280x720) and interlaced 1080i (1920x1080) formats. I'm still not even sure what the official name for this stuff is, so let's just call it HDTV.
So How Can I Get This HDTV Stuff?
There are two aspects to consider. The first is your antenna, and the second is the card to use in your Linux box. It may strike you as unusual, in these modern times, for me to suggest that the most economical way of upgrading the quality of your TV reception is not to subscribe to some new-fangled "digital cable", but rather to use an old-fashioned antenna, the kind you probably used to have up on the roof of the house when you were a kid.
Antenna Considerations
You can check what sort of antenna you're likely to need by going to Antenna Web, and also by looking up the particular stations you find there in the FCC database, to get an idea of their transmission power (ERP) and height above the terrain (HAAT). The FCC provide the antenna locations, in terms of latitude and longitude. You can find the entire table of stations in this directory, in the following files: table1.pdf table2.pdf table2a.pdf. For example, doing a search for Zip code CA94065, you'll find plenty of stations that can be received with nothing more than a regular indoor TV antenna (i.e., a plain piece of wire, nothing special). Since the digital TV transmitters tend to have been installed on the same towers used by analog TV transmitters, apparently a fairly good indicator of whether or not you'll be able to receive digital TV is to see what sort of analog TV reception you currently get with just a basic VHF antenna. If you can get even a few "snowy" channels with analog TV, your chances are good for digital TV.
The PC Card
As of March 2005, there seem to be only three HDTV cards for use in Linux PCs, the pcHDTV, the Air2PC card, and the FusionHDTV card. I've tried the pcHDTV card.
Initial Results
Back in March 2005, to get going and to see what the pcHDTV card was capable of, I installed one pcHDTV HD-3000 card into a Dell Dimension XPS, and one into an ASUS Barebone. I installed the KnoppMyth distribution from KnoppMythR5A12, then built and installed the xine-hd sources provided by pcHDTV on their accompanying CD, and followed the advice in the very amazing, accompanying three-page printed handout to use the command:
dtvscan /dev/dtv > $HOME/.xine/channels.atsc
This created a file with the following contents (using only a wire antenna):
KNTV-HD: :11.1 :12: 4:0 NBC Wea: :11.2 :12: 5:0 KNTV-HD: :11.1 :12: 4:0 NBC Wea: :11.2 :12: 5:0 KGO-DT : : 7.1 :24: 3:0 KGO-DT : : 7.2 :24: 4:0 KTSF D1: :26.1 :27: 2:0 KTSF D2: :26.2 :27: 3:0 KPIX DT: : 5.1 :29: 1:0 KQED-HD: : 9.1 :30: 3:0 ENCORE : : 9.2 :30: 4:0 KMTP-DT: :32.1 :33: 3:0 KCNS : :38.1 :39: 3:0 KCSM : :43.1 :43: 2:0 JazzTV : :43.2 :43: 3:0 KBHK-DT: :44.1 :45: 1:0 KSTS-DT: :48.1 :49: 3:0 KNTV-DT: :48.2 :49: 4:0 KTEH-DT: :54.1 :50: 1:0 KDTV-DT: :14.1 :51: 1:0 KICU-HD: :36.1 :52: 3:0 : :56.1 :56: 2:1 KRON-SD: : 4.1 :57: 3:0 KRON-HD: : 4.2 :57: 4:0
After that, to view HDTV channels, it was only a matter of
configuring xine-hd to use the "xine-hd skin" (by
clicking on the little spanner, and, in the "gui" tab, selecting
"xine-hd" for the "gui skin theme" drop-down box), then launching
xine-hd, using:
xine dtv://
Recording is done by selecting the number from the second numeric column corresponding to the channel. For example, to record from KQED-HD, use the command:
getatsc /dev/dtv0 30 > filename.mpg
To play back such recordings, just use either
xine-hd (which is a version of xine patched by pcHDTV for viewing HDTV
streams) or mplayer. It seems that, oftentimes, multiple program
streams are recorded within the MPEG transport, due to the
transmitting station making use of multicasting.
Multicasting is a process whereby a station that is not
broadcasting in HDTV can provide multiple Standard DTV channels.
So what does that mean for us? Essentially, it means that we'll
need to read up in the manuals for our video playback tools, for
info on how to go about selecting the right program stream. For
mplayer, it turns out that the flag to use is
-tsprog followed by the program number. For xine,
use the channel number from the middle column followed by a dot,
followed by the stream number from the third column, and use this
with the uppercase -C flag — according to the pcHDTV
documentation. Depending on when you initiate the recording, one
or other stream may become the default stream played back by xine
or mplayer. For example, to playback substream number 3 from your
recording of channel 30 (KQED-HD in the list above), use the
following:
xine -C 30.3 filename.mpg mplayer -tsprog 3 filename.mpg
So what's this I hear about surround sound?
Some of the digital channels, for example, KTVUHD (channel 56, program stream 3) and KPIX (channel 29, program stream 1), transmit audio using an A/52 5.1 channel 48000 Hz stream.
Essentially, this means that the audio stream contains five regular audio channels (center, front left, front right, side left, and side right) plus one low-frequency effects channel (subwoofer). It's the same sort of audio stream commonly used for DVD movies.
If you have an external audio decoder (for example, I tried this using a Pioneer VSX-D711 receiver), and your sound card supports AC3 pass-through, then you can simply connect up the digital output from the sound card to the digital input of the receiver, and let the receiver do all the work of decoding the audio.
To select AC3 pass-through with xine, just go into
setup, pick the Audio tab, and select AC3
passthrough from the list, then restart xine. Pressing
Ctrl-I in xine will show the info on the audio
stream you're tuned to, and, if it shows A/52 5.1 48000
Hz, then your receiver should indicate that it's decoding a
surround sound stream, usually by lighting up an indicator
displaying the message "Dolby Digital". Most channels transmit
audio in stereo, and xine will indicate this when
you press Ctrl-I with the message A/52 2.0
(stereo) 48000 Hz.
To get mplayer to do AC3 passthrough, use the
-ao alsa -ac hwac3 flags, for example:
mplayer -ao alsa -ac hwac3 -tsprog 3 filename.mpg
Is there a command-line tool for scheduling recordings?
Inkling's pchdtvr is probably what you've been looking for. It's an amazing console application.
Here's a screen shot of pchdtvr in action, showing
the program guide received from off-the-air:
Because full ATSC streams eat up large amounts of disk space,
you'll be happy to see that Inkling's latest release, pchdtvr 1.0-rc7, allows you to select which program
stream to record. Program streams are called Virtual Channels in
the ATSC spec. Inkling also developed atscut, which
you can use to cut out commercials and other junk from your
recordings, to save space and make them more convenient for later
viewing. It can also be used for far more than that, though.
With pchdtvr you can schedule recordings of specific
program streams using a timer. E.g., to record channel 30 virtual
channel 3 (KQED-HD) for thirty minutes every Monday, use an entry
in your /etc/pchdtvr.0.conf like this:
C30:KQED:PBS T30:20:00:030:0100000:PBS.3
If your machine is a Pentium 4, please turn off
hyperthreading in the BIOS, before recording using
pchdtvr on 2.6 kernels: I'm not sure yet why, but,
while running with hyperthreading enabled, the system would always
lock up shortly after pchdtvr started recording. With
hyperthreading turned off, everything works fine.
Now, with pchdtvr 1.0-rc7, you can enable the use of GNU
screen using pchdtvr -i0 -w, so that,
when you run pchdtvr on the console, you'll still be
able to view it and control it from within X11, without worrying
about X11 crashing and messing up your recording session. Even if
X11 should happen to crash, the screen session will
still be running completely unaffected, and you'll be able to
re-attach to it and resume control using pchdtvr -i0
-R. It also allows you to conveniently control
pchdtvr remotely over ssh.
Electronic Program Guide
In case you've still not quite gotten around to setting up MythTV, Andy Balaam's
freeguide is a nifty Java tool that can download XML
program guides, parse them, and display them in a nice
human-readable channel guide format. On Debian unstable,
freeguide is even available as a package. For the USA, freeguide will
download the program guides from Zap2it. You can create yourself
an account at Zap2it Labs. The freeguide tool displays
the "Certificate Code" needed to create your Zap2it account, or,
if you prefer, you could use the Certificate Code from the
EFF's MythTV Guide.
These ATSC files are huge. Can I squash them?
Recorded ATSC streams tend to have
the occasional error in them, and, for many video transcoding
tools, this causes them to error out, and stop. One method to get
around this is to use mencoder (from the
mencoder-586 package). The following recipe seems to
work relatively reliably to compress single program-stream video
files recorded using Inkling's pchdtvr, as described above. It uses
the lavc mpeg4 codec, and does two-pass encoding at
a very high 5000 bitrate. This high bitrate is
needed only if you really want to preserve the high resolution. To
determine the resolution of the stream you're viewing, use the
Ctrl-I key with xine-hd. This recipe
also preserves the original audio stream (which could be 5.1
channel), rather than compressing it using lame to
mp3. Some folks may not have lame
support built into their mencoder. Compressing the
audio to mp3 at a low bitrate of 96kbps
would provide quite significant space saving: see the
mencoder manual page for an explanation of the
options to use.
mencoder -oac copy -ovc frameno -o frameno.avi ABC.3.ts mencoder -sws 2 \ -oac copy \ -ovc lavc -lavcopts \ vcodec=mpeg4:vhq:vbitrate=5000:vpass=1 \ -vf pp=hb/vb/dr/al/lb \ -vop scale=1280:720,crop=1280:720:0:0 -o ABC.3.avi ABC.3.ts mencoder -sws 2 \ -oac copy \ -ovc lavc -lavcopts \ vcodec=mpeg4:vhq:vbitrate=5000:vpass=2 \ -vf pp=hb/vb/dr/al/lb \ -vop scale=1280:720,crop=1280:720:0:0 -o ABC.3.avi ABC.3.ts
Extracting the audio track
Sometimes, the video itself is of little interest, but
the audio track is worth preserving. So far, the only way I've
found that works to extract the A52 audio stream from ATSC
recordings is to use mplayer's -dumpaudio flag. This
extracts the A52 audio channel (also known as AC3 audio) into a
file called stream.dump, suitable for processing
with a52dec and lame into an
mp3, as follows:
mplayer -dumpaudio input.atsc a52dec -o wav stream.dump | lame - output.mp3
Strangely, using extract_a52, as one would
normally expect to use for this purpose in place of mplayer
-dumpaudio, usually results in audio that plays at the
wrong speed. To hear what it sounds like, use:
mplayer -frames 0 input.atsc 2>&1 |grep "AUDIO A52" # The mplayer output line we're interested in will look something like this: # # VIDEO MPEG2(pid=49)...AUDIO A52(pid=52) NO SUBS (yet)! PROGRAM N. 3 # # Convert the pid=52 into hex, and give it as "-t 0x34" parameter to extract_a52: extract_a52 -t 0x34 input.atsc | a52dec -o wav | lame - output.mp3
Multiple monitors
Using two monitors at the same time turns
out to be very convenient when viewing digital TV, as your
primary monitor can be used for other stuff, while keeping the TV
output running on the secondary monitor. For recent ATI graphics
cards, I try to explain the required configurations here. The way KDE makes the virtual desktops
twice as wide, when the MergedFB setting is used,
makes it possible to switch virtual desktops on one monitor while
leaving xine running on your other monitor, as long
as you right-click on xine and select the "To Desktop -> All
Desktops" setting. That way, xine will still be there when you
switch desktops.
Experience with various Linux distros
The pcHDTV drivers for the HD3000 card built from the pcHDTV-1.6/kernel-2.6.x/driver module sources work with:
- Debian Testing (installed from Sarge Netinst)
- Novell SUSE Linux Desktop 9
- Novell SUSE SLES-9 SP1, which has kernel 2.6.5-7.139.
- Novell SUSE Linux 9.2 professional (the shrink-wrap bundle, also installable by ftp, using SUSE's mini-installation boot CD).
- Fedora Core 3 (First remove the line
/sbin/modprobe bttvfrom theminstallscript when building thepcHDTV-1.6/kernel-2.6.x/drivermodules for the HD-3000 card, as otherwise thecx8800module won't work properly). - Red Hat RHEL4, which has kernel 2.6.9-5.EL.
- Debian Unstable, with kernel 2.6.12.3 (see below).
The Air2PC card
According to the Myth TV project documentation, the Air2PC is an ATSC card manufactured by BBTI, which makes nothing but digital TV capture cards. They are the maker of the SkyStar2 card (one of the best DVB cards available for sale currently). It uses a 4th generation NXT2002 demodulator. The Air2PC is supported by the linuxtv-dvb driver set. Support for the pcHDTV cards has also recently been added (see below). This driver set has been used for many years, and is designed for Digital TV. The Air2PC driver should be included in the 2.6.11 kernel, when it comes out. The Air2PC supports hardware filtering of the transport stream, which relieves the PCI bus of the entire transport stream, thus making the burden on your computer less when recording. The Air2PC card also supports QAM, which allows it to receive unencrypted digital cable.
ATSC is used for over-the-air (terrestrial) broadcast of TV, as well as for most digital cable TV in North America (USA, Canada, and Mexico).
The Air2PC card cannot be used to receive European DVB, although it does use drivers that are commonly used for European DVB, hence the confusion.
The Air2PC cannot work with a satellite receiver, because the Air2PC only accepts 8VSB or QAM-modulated input. This means you can hook up only a TV antenna or cable TV wire to the Air2PC and get it to work. Satellite HDTV tends to use QPSK modulation, rather than 8VSB or QAM modulation.
At the time of writing, March 2005, the Air2PC card was around $169.95, although it is out of stock until July 2005. More details may be found on the following pages: Mythic TV and Cyberstore
The pcHDTV Card
The Linux folks at pcHDTV supply two HDTV cards with Linux drivers, the HD-2000 and HD-3000 cards. The HD3000 is an NTSC (analog capture) and ATSC (digital) card for HDTV in North America. The HD3000 uses a 2nd generation Oren demodulator. The HD3000 is supported by a modified bttv driver that will probably not be included in the mainline Linux kernel, as well as by the new DVB driver, which has been included starting from kernel 2.6.12-rc1. The HD3000 does not support hardware filtering, and the entire raw transport stream is sent over the PCI bus. The HD3000 in theory could support QAM for digital cable, and there have been some success reports on the pcHDTV forums of doing this using the new DVB drivers. The HD-3000 card has one RF input, one S-Video input, one Composite Video/Audio input, and one Stereo Audio output for NTSC. The HD-3000 card is not a universal PCI card. The HD-3000 card is a PCI 2.2-compliant 5-Volt card. That means there may be motherboards (that accept only 3.3 Volt cards) that the HD-3000 cannot be used with, so check that the PCI slot on your mother-board has a 5V key/riser toward the center of the motherboard and not a 3.3V-only key/riser toward the connector-end of the motherboard.
In March 2005, the HD3000 card was $169.98 plus shipping, with a volume discount, e.g., you get a $9.96 discount if you buy two, from pchdtv. Mythic TV also sells them at $172.50 with free shipping.
For driver support, see the pcHDTV HD-2000 and HD-3000 driver wiki. There's also a fledgling page on the LinuxTV Wiki.
So What's the difference between the Air2PC card and the pcHDTV card?
There's a comparison here.
Video Card Considerations
Playback of HDTV streams uses quite a lot of
CPU resources. One possible way to get around the issue of HDTV
playback on slower machines is to use XvMC to
offload the MPEG-2 decoding task to the video card itself.
Apparently, some video cards support XvMC,
have DVI outputs, and work in Linux. For a more
in-depth discussion, check out the Linux HTPC HOWTO.
More Antenna Considerations
The frequencies for the channels used for ATSC broadcasts tend to be higher, so the UHF antennas used for HDTV reception tend to be physically a lot smaller than the VHF antennas used for NTSC analog reception, because the wavelength of the signal is shorter.
If the signal strength at your location is high enough, you
may be able to receive HDTV just fine using a plain loop of wire
hooked up to a piece of coaxial feed line. To get an idea of the
frequencies corresponding to the mysterious FCC channel numbers,
refer to the following list. This list of channels allotted by the FCC for digital
television may also be of interest. Either use the
TAB key followed by several presses on the
w key in Inkling's pchdtvr to display the wavelength, or
use this handy little calculator. (Ideally, the antenna loop diameter
should match the wavelength of the channel you want to
receive.)
If you are planning to really go all-out and design an antenna, it may be best to start by having a professional spectrum analysis performed at your location. Most satellite installation technicians will have the equipment to do this, and it will help to know whether you need to consider multipathing (reflections) of the received signals in your design.
Redistribution Control Descriptor
The Redistribution Control Descriptor, also known
as the broadcast flag, is described on page 79 of the ATSC
Standard A_65B. To check whether the transport stream you are
receiving has this 0xAA flag set, you can build the NIST DASE ATSC/MPEG2 parser, which will print
out Content_Protect_Copy_Mngt_descr when it sees the
0xAA flag set in the stream. Inkling's pchdtvr, now
at rc7, conveniently strips the RC flag from single VC captures,
and the atscut tool can display its setting and can
also strip the flag from existing captures. During capture,
pchdtvr indicates the RC flag's setting by causing
the packet statistics display PMT to turn an ominous
glowing red color. If statistics are not switched on, then the
presence of the RC flag is indicated by a red R
appearing in the bottom line of the display, to the left of the
TEVM summary display. For more info on the RC flag,
how it may affect your rights, and what you can do before the 1st
of July 2005 deadline, see the EFF.
Update: The U.S. Court of Appeals in Washington ruled in May 2005 that the FCC does not have the authority to require manufacturers to implement the broadcast flag.
DVB with the pcHDTV HD3000
The DVB driver for the pcHDTV HD2000 and HD3000 card is now in kernels 2.6.12-rc1 and up. This guide tries to explain the steps to using this new DVB driver. The initial thread about DVB driver support in kernel 2.6.12-rc1 in the pcHDTV forums is here, and the Linuxtv folks also have this page about it. But let's go slow, and I'll try to explain all the steps in detail as best I can.
For a similar guide showing how to configure the Air2PC card, see here instead.
Build kernel 2.6.12.3
I built
kernel 2.6.12.3, downloaded on July 30,2005,
using this .config file on this machine, and booted it with great optimism.
The module to load for terrestrial digital HDTV (8VSB ATSC) is
cx88-dvb, and the module to load for analog NTSC is
cx8800. More on how to load the modules and what to
expect later, first let's look at what needs to be configured in
the kernel .config file to build them.
When compiling your kernel, DVB_OR51132 needs to
be set to "m". If that gives you the following
problem when you boot:
cx88_dvb: Unknown symbol cx22702_attach
then it means you're missing the DVB_CX22702
from your .config file. Also,
CONFIG_VIDEO_CX88 and
CONFIG_VIDEO_CX88_DVB both need to be set to
"m" for the analog (NTSC) driver cx8800
to be built.
The config make gconfig graph goes like this:
Device-drivers -> Multimedia devices -> [-] Video for Linux -> Video for Linux -> Video Adapters [-] Conexant 2388x (bt878 successor) support (CONFIG_VIDEO_CX88=m) [-] DVB support for cs2388x based TV Cards (CONFIG_VIDEO_CX88_DVB=m) Digital Video Broadcasting Devices -> [-] DVB for Linux (DVB=m) [-] DVB Core Support (DVB_CORE=m) Customise DVB Frontends -> [-] Conexant cx22702 demodulator (OFDM) (DVB_CX22702=m) [-] OR51132 based (pcHDTV HD3000 card) (DVB_OR51132=m)
Build the kernel however you usually build your kernel. On
Debian, I used Manoj Srivastava's amazing make-kpkg
tool, as follows:
tar jxvf linux-2.6.12.3.tar.bz2 cd linux-2.6.12.3 make gconfig fakeroot make-kpkg --initrd kernel_image modules_image
This produces a file called
kernel-image-2.6.12.3_10.00.Custom_i386.deb in the
directory containing linux-2.6.12.3 (i.e., the parent
directory). I installed it using apt-get as follows:
apt-get install kernel-image-2.6.12.3_10.00.Custom_i386.deb
During installation, the initial RAMdisk is created. The
contents of the initrd.img-2.6.12.3 can be viewed by
loopback-mounting it, to check it has all the modules you expect or
to edit the /mnt/test/loadmodules script to change the
sequence the modules will be loaded in, as follows:
mount -t cramfs -o loop initrd.img-2.6.12.3 /mnt/test
For more details on how to decide which modules will be included, and the order they'll be loaded, see here. If you need to remove the kernel package, because you have rebuilt it and want to try with a new one, use:
dpkg -r kernel-image-2.6.12.3 dpkg --purge kernel-image-2.6.12.3
Probably all these details will seem excessive if you're already familiar with Debian, but this is one the first kernels I've built since I've been using Debian, so it's still fairly new to me.
Download the Firmware
If you're
behind an HTTP application proxy firewall, set up your
$HOME/.wgetrc with your proxy as follows:
http-proxy=http://your-proxy.your-domain:80
Download the firmware using the scripts contained in the
Linux kernel sources Documentation/dvb directory,
e.g.:
cd ~/linux-2.6.12.3/Documentation/dvb perl ./get_dvb_firmware or51132_qam perl ./get_dvb_firmware or51132_vsb
You can also download the firmware files from here on the pcHDTV downloads page. Now copy the files
dvb-fe-or51132-vsb.fw and
dvb-fe-or51132-qam.fw to either
/lib/firmware or
/usr/lib/hotplug/firmware/ (depending on your hotplug
version). For Debian, I copied them as follows:
cp dvb-fe-or51132-vsb.fw /usr/lib/hotplug/firmware/ cp dvb-fe-or51132-qam.fw /usr/lib/hotplug/firmware/
Sometimes, even though the firmware is present in the correct location, it still doesn't get uploaded by the hotplug system. If this is the case for you, it may be because of the same problem as described here and here.
The fix I used on Debian was to add the following line to my
/etc/udev/udev.rules file:
ENV{UDEVD_EVENT}=="1", RUN+="/sbin/udev_run_hotplugd"
I then restarted udev using:
/etc/init.d/udev restart
Load the DVB Kernel module
To load the module for digital over-the-air 8VSB ATSC,
use the following sequence of commands. The reason for all the
"remove" commands is that, after a reboot, you may find that some
modules you don't want have been loaded. It's safest to
really clean things up, before loading the cx88-dvb
module, as follows:
modprobe -rv cx88_blackbird modprobe -rv cx88-dvb modprobe -rv cx8800 modprobe -v cx88-dvb
This should cause the device directory
/dev/dvb/adapter0 to appear. It should contain the
following devices: demux0, dvr0,
frontend0 and net0. The list would be
as follows (this is for two pcHDTV HD3000 cards), showing the
major/minor numbers and permissions like this:
crw-rw---- 1 root video 212, 4 2005-07-31 22:42 /dev/dvb/adapter0/demux0 crw-rw---- 1 root video 212, 5 2005-07-31 22:42 /dev/dvb/adapter0/dvr0 crw-rw---- 1 root video 212, 3 2005-07-31 22:42 /dev/dvb/adapter0/frontend0 crw-rw---- 1 root video 212, 7 2005-07-31 22:42 /dev/dvb/adapter0/net0 crw-rw---- 1 root video 212, 68 2005-07-31 22:42 /dev/dvb/adapter1/demux0 crw-rw---- 1 root video 212, 69 2005-07-31 22:42 /dev/dvb/adapter1/dvr0 crw-rw---- 1 root video 212, 67 2005-07-31 22:42 /dev/dvb/adapter1/frontend0 crw-rw---- 1 root video 212, 71 2005-07-31 22:42 /dev/dvb/adapter1/net0
To unload the cx88-dvb driver (this also
conveniently unloads all of the modules it depends on), use:
modprobe -rv cx88-dvb
Output of the load command modprobe -v cx88-dvb
should be as follows:
insmod /lib/modules/2.6.12.3/kernel/drivers/media/dvb/frontends/dvb-pll.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/dvb/frontends/cx22702.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/video-buf.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/dvb/dvb-core/dvb-core.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/video-buf-dvb.ko insmod /lib/modules/2.6.12.3/kernel/drivers/base/firmware_class.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/dvb/frontends/or51132.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/videodev.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/tveeprom.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/btcx-risc.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/common/ir-common.ko insmod /lib/modules/2.6.12.3/kernel/drivers/i2c/algos/i2c-algo-bit.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/cx88/cx88xx.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/dvb/frontends/mt352.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/cx88/cx8802.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/cx88/cx88-dvb.ko
Output of the unload command modprobe -rv
cx88-dvb should be as follows:
rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/cx88/cx88-dvb.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/cx88/cx8802.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/dvb/frontends/mt352.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/cx88/cx88xx.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/i2c/algos/i2c-algo-bit.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/common/ir-common.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/btcx-risc.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/tveeprom.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/videodev.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/dvb/frontends/or51132.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/base/firmware_class.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/video-buf-dvb.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/dvb/dvb-core/dvb-core.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/video-buf.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/dvb/frontends/cx22702.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/dvb/frontends/dvb-pll.ko
Using the DVB kernel modules
Get the latest dvb-apps from the
linuxtv
CVS, using:
cvs -z3 -d ':pserver:[email protected]:/cvs/linuxtv' co -P dvb-apps
If you're behind an HTTP application proxy firewall, you'll need to add the proxy to the command like this:
cvs -z3 -d ':pserver;proxy=your-proxy.your-domain;proxyport=80:[email protected]:/cvs/linuxtv' co -P dvb-apps
Some distributions include a dvb-utils package
that has tzap. Don't use tzap; it is
not a replacement for azap. If you can't find
azap, it probably means you have an old version of
the dvb-apps, so just build the
dvb-apps from CVS, and use them locally, as shown in
the examples here.
Build the dvb-apps by running make
in the top directory.
Go into the util/scan directory, and run the following example:
cd dvb-apps/util/scan && ./atscscan atsc/us-NTSC-center-frequencies-8VSB
The kernel module will try to load the firmware for the HD3000 card, at this point. Check your "dmesg" output. If you see this in "dmesg", then the firmware isn't being uploaded by the hotplug subsystem:
or51132: Waiting for firmware upload(dvb-fe-or51132-vsb.fw)... or51132: No firmware uploaded(timeout or file not found?)
As described in the section above, even though the firmware is present in the correct location, it may still not get uploaded by the hotplug system. Please try the fix described in that section.
Once the firmware loads successfully, dmesg will
show the following message:
or51132: Waiting for firmware upload(dvb-fe-or51132-vsb.fw)... or51132: Version: 10001134-19430000 (113-4-194-3) or51132: Firmware upload complete.
Once the firmware is loaded, the atscscan runs as
follows. The reason to include the full output is to give an idea of what to
expect. This is for area code 94065 (for which the
atsc/us-CA-SF-Bay-Area file might be a better choice
for scanning with, but I didn't notice it until just now). Please
scroll on down to the end, where the summary of the run is
output: that's the part we use to make our
$HOME/.azap/channels.conf file, as it contains the
PIDs for the audio and video subchannels.
cd dvb-apps/util/scan && ./atscscan atsc/us-NTSC-center-frequencies-8VSB
The full output of the above command is here, but only the summary section
dumping lists at the end is what we're interested
in:
dumping lists (26 services) KNTV-HD :207000000:8VSB:65:68:4 NBC Wea :207000000:8VSB:81:84:5 KBWB-HD :503000000:8VSB:49:52:3 KBWB-SD :503000000:8VSB:65:68:4 KGO-DT :533000000:8VSB:49:52:3 KGO-DT :533000000:8VSB:65:68:4 KTSF-D2:551000000:8VSB:49:68:4 KTSF-D1:551000000:8VSB:49:52:3 KPIX DT:563000000:8VSB:49:52:1 KQED-HD:569000000:8VSB:49:52:3 ENCORE:569000000:8VSB:65:68:4 KMTP Digital Television:587000000:8VSB:49:52:3 Telefutira:593000000:8VSB:49:52:3 KCNS-DT:623000000:8VSB:49:52:3 KKPX Faith:635000000:8VSB:97:100:6 KKPX Worship:635000000:8VSB:81:84:5 KKPX Pax East:635000000:8VSB:65:68:4 KKPX Digital Television:635000000:8VSB:49:52:3 KCSM-TV:647000000:8VSB:33:36:2 Jazz-TV:647000000:8VSB:49:52:3 KBHK-DT:659000000:8VSB:49:52:1 KTVUHD:725000000:8VSB:49:52:3 KTVU-DT:725000000:8VSB:65:68:4 KRON-SD:731000000:8VSB:49:52:3 KRON-HD:731000000:8VSB:65:68:4 KTNC DIGITAL TELEVISION:767000000:8VSB:49:52:3 Done.
Creating the
$HOME/.azap/channels.conf
Put the last section
from the above output from atscscan into
$HOME/.azap/channels.conf. (You may need to edit the
first column to remove spaces and unusual characters, as you'll
need to pass the contents of the first column as a command-line
parameter.) Use the "-r" option to
./dvb-apps/util/szap/azap to tune to a terrestrial
8VSB ATSC channel:
./dvb-apps/util/szap/azap -r KNTV-HD
This will show output something like the following. The thing
to look for is the FE_HAS_LOCK, which means that the
frontend kernel module has tuned to the channel.
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 207000000 Hz video pid 0x0041, audio pid 0x0044 status 00 | signal 3999 | snr cd37 | ber 00000000 | unc 00000000 | status 1f | signal cb84 | snr f8cf | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal cb84 | snr f8b3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
While azap is running in one terminal, you can
launch mplayer on /dev/dvb/adapter0/dvr0 to watch
the stream. This will display the video without de-interlacing
(not pretty), and output the audio using AC3 passthrough. Remove
the -ac hwac3 flag, if you're not using an external
Dolby decoder.
mplayer -ac hwac3 /dev/dvb/adapter0/dvr0
To save the individual stream to the hard drive, one way is to use:
cat /dev/dvb/adapter0/dvr0 > $HOME/test.mpg
To save the full ATSC stream, see below.
You can playback $HOME/test.mpg with
mplayer, or use xine.
Viewing the PIDs
When a channel is tuned using azap, you
can view the PIDs multiplexed within that channel using
./dvb-apps/util/dvbtraffic/dvbtraffic by just
running it and watching which PIDs it shows having a lot of
bandwidth associated with them:
-PID--FREQ-----BANDWIDTH-BANDWIDTH- 0000 9 p/s 1 kb/s 14 kbit 0040 10 p/s 1 kb/s 16 kbit 0041 9659 p/s 1773 kb/s 14527 kbit 0044 280 p/s 51 kb/s 422 kbit 0050 10 p/s 1 kb/s 16 kbit 0051 2146 p/s 393 kb/s 3227 kbit 0054 280 p/s 51 kb/s 422 kbit 1d00 5 p/s 0 kb/s 8 kbit 1d02 2 p/s 0 kb/s 4 kbit 1e00 7 p/s 1 kb/s 11 kbit 1e02 1 p/s 0 kb/s 2 kbit 1e80 0 p/s 0 kb/s 1 kbit 1ffb 40 p/s 7 kb/s 60 kbit 1fff 442 p/s 81 kb/s 665 kbit 2000 12901 p/s 2368 kb/s 19403 kbit
For example, with KNTV-HD tuned using azap, the
PIDs 0x0041 and 0x0044 (65 and 68 decimal) as well as the PIDs
0x0051 and 0x0054 (81 and 84 decimal) show a lot of
bandwidth.
You can also find the PIDs by running
./dvb-apps/util/scan -c while the channel is tuned,
which may be easier than viewing the dvbtraffic
output especially if your signal is somewhat noisy.
These PIDs can be seen in your
$HOME/.azap/channels.conf in columns four and five.
They correspond to the audio and video PIDs for the two
"stations" (actually referred to as virtual channels, or VCs in
the ATSC spec) being transmitted with the 207000000
frequency, as follows:
KNTV-HD:207000000:8VSB:65:68:4 NBC Wea:207000000:8VSB:81:84:5
The 4 and 5 in the last column at
the end are the subchannel numbers, which can be selected using the
mplayer option -trprog. E.g., to play subchannel 4,
use:
mplayer -tsprog 4 -ac hwac3 /dev/dvb/adapter0/dvr0
In the avsforum, the post by JarginAU is well worth checking out, as it provides additional insight to using the DVB tools.
Recording a full ATSC stream
Although it's possible to dump the output from
/dev/dvb/adapter0/dvr0 to the hard drive, sometimes
you want to save the entire raw ATSC stream. To do this, use
./dvb-apps/test/test_dvr as follows:
./dvb-apps/util/szap/azap -r KTVUHD BUF_SIZE=1925120 ./dvb-apps/test/test_dvr $HOME/test.mpg 0x2000
Or, to record from a second HD3000 card (if you're using two in the same machine), use:
./dvb-apps/util/szap/azap -a 1 -f 0 -r KQED-HD DEMUX=/dev/dvb/adapter1/demux0 DVR=/dev/dvb/adapter1/dvr0 BUF_SIZE=1925120 ./dvb-apps/test/test_dvr $HOME/test2.mpg 0x2000
Playback using xine
The regular xine-ui package
with Debian is able to play back full ATSC recorded streams. E.g.,
to playback the stream recorded above, you'd use:
xine $HOME/test.mpg
There's also a tempting-looking "DVB" button in the
xine GUI. Jack Kelliher recently posted this
patch to the xine-devel mailing
list. It has a small typo in the following line, where the second
(") should be replaced with a single quote
('), but otherwise it applies fairly cleanly:
+ _("input_dvb: dvbc mrl specified but the tuner doesn"t appear to be QAM (DVB-C)\n"));
To apply Jack's patch to xine-lib, proceed
something like this:
wget http://easynews.dl.sourceforge.net/sourceforge/xine/xine-lib-1.1.0.tar.gz wget http://easynews.dl.sourceforge.net/sourceforge/xine/xine-ui-0.99.4.tar.gz tar zxvf xine-lib-1.1.0.tar.gz ln -s xine-lib-1.1.0 xine-lib wget http://www.penlug.org/twiki/pub/Main/DigitalTelevisionDVB/jack_kelliher_xine_lib_input_dvb_patch cat jack_kelliher_xine_lib_input_dvb_patch | patch -p0 >patch.out 2>patch.err
The magical result of Jack's patch is that, once you copy your
channels.conf file into your $HOME/.xine
directory, and launch xine, now, when you press the
"DVB" button in the GUI, it actually plays the first channel it
finds. It works great on standard-definition DTV channels, and on
1280x720 channels.
With the default xine settings, the HDTV
1920x1080 channels had a lot of breakup and glitches, which can
be fixed by increasing the setting for Number of video
buffers under the engine tab in the
xine configuration dialog box. (First, make sure you
have selected the Master of the known universe
setting on the gui tab, then click the right-arrow
at the top of the dialog box to reveal the engine
tab.)
Pressing the KP9 (keypad "9"/"PgUp") and KP3 (keypad
"3"/"PgDn") keys in xine will switch channels to
whatever you have in your $HOME/.xine/channels.conf.
You can also tune directly to a channel by giving the channel
name (from the first column of your
$HOME/.xine/channels.conf, like this:
xine dvb://KQED-HD
It's a little bit slow to switch channels, but it's far more
reliable than with the non-DVB drivers, which tended to lose audio
or get into a sort of slow-video mode when changing channels, so
this is a very useful patch for xine, and well worth
trying out. It's fairly short, so it's well worth reading, with a
view to patching other applications for the American/Canadian ATSC
market.
Compiling xine-hd
The only "gotcha" with plain
xine is that you can't select the subchannel in the
way mplayer can (using its -tsprog
flag). The pcHDTV folks provide a patched version of xine called
"xine-hd" which can select the subchannel using the "-C" option,
e.g.:
xine -C 52.4 $HOME/test.mpg
The xine-hd download provided by pcHDTV hasn't yet been
patched to compile with gcc4, nor for ATSC DVB support (yet), so,
if your system is using gcc4 by default, it's easiest to just
compile xine-hd using gcc3 instead. Set your PATH to
pick up gcc3 first.
You may run into the following compile problem with building
the xine-hd library:
input_dtv.c: In function `dtv_plugin_set_channel': input_dtv.c:266: error: `VIDEO_MODE_ATSC' undeclared (first use in this function)
The above is what happens if you try to compile
xine-hd and haven't yet patched your
videodev.h file as it says in the pcHDTV readme file
within the pcHDTV 2.6.12 extras (04/09/05). Look in the
pcHDTV-extras/v4l2-driver directory, and notice that
the make install target of the Makefile in that
directory does the following:
mkdir -p /usr/include/linux; cp -v videodev2.h videodev.h /usr/include/linux patch -Np0 /usr/include/linux/videodev2.h <videodev2-patch
Don't install the
/lib/modules/2.6.12.3/v4l2/cx88-atsc.ko driver,
though, because, if it gets loaded, it will crash the 2.6.12.3
kernel!
The pcHDTV version of xine has the
-C option for selecting which subchannel to playback
from full ATSC stream captures. For example:
./dvb-apps/util/szap/azap -r KQED-HD BUF_SIZE=1925120 ./dvb-apps/test/test_dvr $HOME/test.mpg 0x2000 xine -C 52.4 $HOME/test.mpg
How about good old Analog (NTSC) with these new DVB drivers?
The "cx8800" module implements the V4L2 driver, used for analog NTSC reception with the pcHDTV HD3000 card. It seems to be safest to first clean things up, before loading it, so I use the following sequence:
modprobe -rv cx88_blackbird modprobe -rv cx88-dvb modprobe -rv cx8800 modprobe -v cx8800
It works very fine with the tvtime application,
to view local analog NTSC broadcasts. To get sound in
tvtime, apparently one is supposed to use the special
proprietary magical cable provided by pcHDTV (just kidding; any
cable will work) to connect the HD3000's line-out to the line-in on
one's sound card, but I haven't tried that yet. In
tvtime, use the up/down arrows to change the TV
channel, to see if all of your usual broadcast NTSC channels are
there.
The difference in the "dmesg" output is that loading the
cx8800 module gives:
cx2388x v4l2 driver version 0.0.4 loaded
Whereas, the ATSC DVB module cx88-dvb gives:
cx2388x dvb driver version 0.0.4 loaded
The output of the load command
modprobe -v cx8800for the NTSC
cx8800 module is as follows:
insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/videodev.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/btcx-risc.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/v4l2-common.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/v4l1-compat.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/tveeprom.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/common/ir-common.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/video-buf.ko insmod /lib/modules/2.6.12.3/kernel/drivers/i2c/algos/i2c-algo-bit.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/cx88/cx88xx.ko insmod /lib/modules/2.6.12.3/kernel/drivers/media/video/cx88/cx8800.ko
When the cx8800 module is loaded, the major/minor
numbers and permissions of the devices created are like this:
crw-rw---- 1 root video 81, 64 2005-07-31 22:46 /dev/radio0 crw-rw---- 1 root video 81, 65 2005-07-31 22:46 /dev/radio1 crw-rw---- 1 root video 81, 224 2005-07-31 22:46 /dev/vbi0 crw-rw---- 1 root video 81, 225 2005-07-31 22:46 /dev/vbi1 crw-rw---- 1 root video 81, 0 2005-07-31 22:46 /dev/video0 crw-rw---- 1 root video 81, 1 2005-07-31 22:46 /dev/video1
The output of the unload command
modprobe -rv cx8800
for the "cx8800" module is:
rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/cx88/cx8800.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/cx88/cx88xx.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/i2c/algos/i2c-algo-bit.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/video-buf.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/common/ir-common.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/tveeprom.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/v4l1-compat.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/v4l2-common.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/btcx-risc.ko rmmod /lib/modules/2.6.12.3/kernel/drivers/media/video/videodev.ko
Credits
Thanks to Tony Godshall (of Bay Area Debian) for organising and hosting an EFF PVR Build-In.Links
- pcHDTV HD-2000 and HD-3000 driver support wiki.
- LinuxTV Wiki page for the pcHDTV HD-3000.
- Transcode Wiki
![[BIO]](../gx/authors/knaggs.jpg)
I studied engineering at Université de Liège for a year, then at Trinity
College Dublin for four more (and where I wish I had paid more attention
during the networking lectures). I've always been curious about audio and
video on computers, and Linux has been truly an amazing platform for learning
about these areas.
