Teletext / Videotext is popular in Europe and provides both informational pages and captions or subtitles to television programs. In 1992, teletext was provided in 18 countries.
TV capture chipsets implement teletext and closed captioning in different ways, and the free software code to support text capture is still missing or incomplete for some chipsets.
- 1 Analog television
- 2 Digital television (DTV)
- 3 Devices Usable With Text
- 4 Applications
- 5 Technical background
The vertical blanking interval (VBI) is an interval in a television signal that temporarily suspends transmission of the signal for the electron gun to move back up to the first line of the television screen to trace the next screen field. The vertical blanking interval can be used to carry data, since anything sent during the VBI would naturally not be displayed; various test signals, closed captioning, and other digital data can be sent during this time period.
In the PAL standard, Teletext and Caption data is digitally encoded in the VBI on lines 17 through 20.
In North America, which follows the NTSC standard, closed captioning uses line 21 of the VBI.
Digital television (DTV)
The European standards ETSI EN 300 472 "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and ETSI EN 301 775 "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams".
The DVB standard transmits sliced VBI data in a separate elementary stream.
The A/53 ATSC Digital Television Standard covers Closed Caption transport and the "digital" Closed Caption standard EIA 708-B. See the EIA-708 Wikipedia entry and Digital Television Closed Captioning FAQfor details.
EIA-708 specifies the transmission of CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex from there. A freestanding CC capture application would still need to tune in and choose a program ID. To complicate matters further, EIA-708 allows both old style EIA-608-compatible closed caption data as well as the newer DTVCC.
Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."
Devices Usable With Text
Cards based on the bt8x8 chip (cf. bttv devices (bt848, bt878) have excellent text capture capability for both PAL/SECAM and NTSC.
Commandline output is provided by both ntsc-cc and the test/capture utility in zvbi.
The latest improvements on vbi support for cx88-based cards, aside from kernel-related stuff and modules reorganization, were made by Tom Zoerner in March of 2004. The README.cx88 still says: "some code present. Doesn't crash any more, but also doesn't work yet ..."
However, Tim sketched out exactly what needs to be done in this 22 May 2004 e-mail.
As of Kernel 2.6.16-r7, the cx88 driver (as tested with a pcHDTV 3000 card), captures some VBI data, which is unusable for NTSC closed captioning as only 1150 or so bytes per line of VBI data have valid values and the rest of the 2048 byte line contains unchanging garbage data. There is a patch being discussed on the video4linux mailing list that likely solved this problem. While the feature is not documented, closed captioning on cx88 most likely works with current (2.6.19) kernels.
In the meantime, nxtvepg (which uses vbi information) is working on cx88 PAL tuners, cf. system requirements.
The latest test with kernel 22.214.171.124, NTSC closed caption is working, with a small patch published by Rafael Diniz in a 22 October 2008 email. This patch hopefully will be applied soon.
IVTV provides generic VBI data via a VBI Linux device. As EIA-608 closed caption data is among the VBI data, you can get it from the VBI device. IVTV provides the VBI data in two different formats -- raw and sliced. the raw mode is all of the VBI lines, with 720 luminosity samples line. The sliced format has it decoded into data bytes, with selectable VBI lines.
In addition, IVTV can embed VBI data in the MPEG stream you get from the video Linux device. It embeds it in Private Stream 1 of the MPEG stream. This is not a standard format; it is an IVTV invention. A few programs, including mythtv and ccextractor know the IVTV embedded VBI format with respect to EIA-608 closed captioning. Bryan Henderson (firstname.lastname@example.org) has a patch (May 2008) for Mplayer that makes it do so also.
The README.vbi in a current ivtv release has lots of details.
With a PVR-250, IVTV provides the VBI device and controls to put it in either raw mode or sliced CC. (Based on my own experimentation - Bryan Henderson).
Older IVTV (Before version 0.10) crashes when you read the VBI device if you put the device into sliced mode and you load IVTV with the autoload=0 option. Bryan Henderson (email@example.com) has a fix for this divide by zero bug.
This exchange on the IVTV mailing list suggests it can provide CC, VPS and WSS data with the PVR-350, but that hardware limitations prevent teletext.
In Linux v2.6.14-rc2, Mauro Carvalho Chehab submitted an "experimental Sliced VBI API support for v4l" patch, which apparently uses the hardware bit slicer in the ivtv driver. I take it this means text capture is now improved for the Hauppauge PVR150/250/350/500 cards.
Cards based on saa713x chips (cf. saa713x devices) have excellent text capture capability under PAL/SECAM. Support for NTSC closed captioning is now available in libzvbi, including the freestanding zvbi-ntsc-cc from libzvbi 0.2.17, a drop-in replacement for xawtv's ntsc-cc.
The CVS version of ntsc-cc in xawtv that includes the libzvbi patch is still not released, pending some final quality tests.
AleVT is a teletext/videotext decoder and browser for the bttv driver (/dev/vbi) and X11.
ccextractor can extract closed captions from a variety of kinds of input streams and render the information in various forms. It understands as input DVB and IVTV format, and can produce as output SRT or SAMI (standard subtitle file formats) or raw captions in DVB format.
ccextractor is also excellent for extracting the closed captioning from DVDs and DVD images (such as the cdr images created by OSX's DiskImage utility) or ts files. The software is still in beta and the developers are active, so help them improve the application.
The application GStreamer works with closed captioning (they also mention some tweaks for Canadian English and French television); see Freedesktop's repository.
Scott Larson has (23 September 2005) written a patch for mplayer to display EIA-708 closed captioning (e.g. from a digital TV broadcast). Specifically, the patch uses the EIA-608 compatible subformat; it cannot use the DTVCC data. See the pchdtv forum for more information.
Bryan Henderson (firstname.lastname@example.org) has (May 2008) written a patch for mplayer to make it do closed captioning based on IVTV MPEG embedded VBI (EIA608) data in its MPEG input.
A teletext (PAL) browser with a Motif-based GUI and a console mode. In Debian, mtt is part of the motv package.
MythTV's native player can display closed captions encoded into an MPEG-2 stream in the IVTV format.
The Nextview EPG decoder and browser is an Electronic TV Programme Guide for the analog domain (as opposed to the various digital EPGs that come with most digital broadcasts). It allows you to decode and browse TV programme listings for most of the major networks in Germany, Austria, France and Switzerland. The EPG information is read from /dev/vbi.
The application ntsc-cc handles closed captioning on bttv devices (bt848, bt878) only, because it implements only the old v4l API. The saa7134 chip uses other sample rates.
For ntsc-cc to work, you typically need to be running an application for viewing or recording television, such as xawtv and mencoder. If no such application is running, ntsc-cc tends to produce garbled output.
An updated version of ntsc-cc is included in zvbi; see zvbi-ntsc-cc below.
The video recording software VDR can display teletext, if extended by osdteletext-plugin. The pvrinput-plugin serves here as stream source to the application, delivering a MPEG TS from a ivtv or pvrusb2 supported analog tv card, in which the teletext data is embedded. The osdteletext plugin can also display DVB embedded teletext standalone, if delivered from an oldstyle full-featured DVB card.
XdTV interacts with AleVT for Teletext and Nxtvepg for NextView.
In addition, Zapping provides subtitle overlay through the closed captioning decoder built into libzvbi.
The zvbi library offers functions to capture and decode raw VBI data. It works with all drivers using the V4L or V4L2 raw VBI API, the FreeBSD BKTR driver, Linux DVB drivers, and it can read VBI data from a VBI proxy to share V4L and V4L2 VBI devices between multiple applications. As of version 0.2.32 ATSC is also supported. I don't know if the V4L2 sliced API is supported yet (please add if you know).
Higher level functions such as to display or record Teletext and Closed Caption, or to extract network names from Teletext and XDS are also included.
The zvbi library understands the European standards ETSI EN 300 472 "Specification for conveying ITU-R System B Teletext in DVB bitstreams" and ETSI EN 301 775 "Specification for the carriage of Vertical Blanking Information (VBI) data in DVB bitstreams". The European DVB standard transmits sliced VBI data in a separate elementary stream. Current drivers in libzvbi provide full support.
It can read VBI PES packets from Linux DVB devices and extract Teletext, VPS, WSS and Caption data. A demultiplexer is available to extract VBI data from DVB MPEG-2 program streams and a multiplexer to convert sliced VBI data, e. g. captured from analog devices, to DVB format. For details see the zvbi documentation. The test/capture utility in the source tarball can demonstrate these capabilities.
The zvbi library currently does not understand the American standard ATSC A/53 "ATSC Digital Television Standard" which also covers Closed Caption transport and the "digital" Closed Caption standard EIA 708-B.
Michael Schimek writes that A/53 specifies the transmission of "CC bytes in a user data field following a picture header, inside the video elementary stream. If the driver doesn't extract CC data on its own, and the "broadcast flag" permits this, one could perhaps read video packets from the device, or a complete MPEG-2 program stream from disk, and demultiplex in software. Libzvbi does something similar for DVB, so it shouldn't be hard to implement, if it hasn't been done already to extract DVD caption. A freestanding CC capture application would still need to tune in and choose a program ID; that's beyond the scope of libzvbi.
To complicate matters further A/53 may transmit old style caption EIA-608 as well as the newer "digital caption" EIA-708. I don't have enough information to properly implement EIA-708 caption overlay (nor is it useful for me until Zapping goes digital) but to write an ntsc-dtvcc it might suffice."
However, Scott Larson writes that "stations are required to pass both EIA-608 (VBI) and EIA-708 (DTVCC) data. Why? Because If an ATSC receiver is connected to an NTSC TV (which is a likely occurance in the transition to digital broadcasting), the receiver is required to generate the old VBI Line 21 captions from the ATSC stream so the old TV will still have closed captions."
- Included in libzvbi 0.2.17 onwards (in Debian, it's it the zvbi package). Is built on and preserves the functionality of xawtv's ntsc-cc, but also handles closed captioning for cards based on saa713x chips (cf. saa713x devices).
- Unlike ntsc-cc, zvbi-ntsc-cc does not require you to run another application for viewing or recording.
- Libzvbi 0.2.32 added an improved version of zvbi-ntsc-cc which can record EIA-608 and EIA-708 caption from ATSC devices.
Displaying captured text
To get formatted output for overlay on the television image, Michael Schimek's decoder (part of libzvbi) works like a terminal emulator, printing caption into virtual screen memory. As long as you have "pop on" style caption, streaming is easy. For "roll up" caption it needs a more character or line oriented interface. Perhaps it would suffice to call the client and clear the screen before any vertical cursor motions and scrolling.
Recommended applications for testing under PAL/SECAM are mtt, zapping/zapzilla and alevt/d.
For lower-level testing, use the utilities in the test/ directory of the zvbi tarball, available on zvbi's project page; these are actively maintained.
The test/capture utility currently just dumps printable characters on stdout. This output needs to be "sliced". Sliced VBI is the data transmitted on each scan line. It still contains multiple logical streams, parity bits and control codes. In libzvbi "formatting" takes one stream, converts characters to Unicode and interprets control codes, giving one page of text for display. An export function would convert the text to ASCII.
You may also use test/capture utility from the zvbi library to display printable closed caption data.
To visualize the Vertical Blanking Interval on NTSC, issue
ntsc-cc -d /dev/vbi -c -w -r 11
Both bttv and saa7134 cards show orderly signals, and cx88 (as of Kernel 2.6.16-r7) shows valid data for the first part of the line, with noise on the rest of the line.
In the zvbi test/ suite, osc similarly visualizes. The test/osc utility is more useful, since it displays which row and line are being graphed and lets you change rows with the arrow keys. NTSC closed captioning should appear on row 11, line 21.