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 bttv from the minstall script when building the pcHDTV-1.6/kernel-2.6.x/driver modules for the HD-3000 card, as otherwise the cx8800 module won't work properly).
• Red Hat RHEL4, which has kernel 2.6.9-5.EL.

I've tried the newer DVB drivers for the pcHDTV HD3000 card only with:

• 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:anonymous@cvs.linuxtv.org:/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:anonymous@cvs.linuxtv.org:/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 cx8800

for 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

 

---

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.