Stations wanting to convert to ATSC 3.0 have had trouble finding an ATSC 1.0 home for their high-definition (HD) and standard-definition (SD) streams. Using MPEG-4 (AVC) for ATSC 1.0 has been tried but created problems for viewers with older TV sets or old “coupon” converter boxes. I’ll suggest some options that might work, if the FCC allows it.
Finding Space for Homeless ATSC 1.0 Program Streams
There is much support for ATSC 3.0, including recent interest from the U.S. government, which is studying the standard’s Broadcast Positioning System utility as a backup for GPS. New features are being added, including standards based (DRM) radio. Work has started on developing ways for 3.0 to work with 3GPP wireless technology.
While LG is no longer selling ATSC 3.0 TV sets, other manufacturers such as Sony, Samsug, Hisense and now TCL are offering them, and consumers now have a variety of inexpensive set-top box receivers to choose from. Features like virtual channels (delivered by internet to the TV rather than over-the-air) and broadcaster applications that provide additional content and the ability to restart programs (using the internet) will make 3.0 even more attractive to viewers.
Attempts to use MPEG-4 have resulted in complaints that the program had audio but no video from viewers with older TVs or NTIA coupon set-top boxes."
However, spectrum and data bandwidth for ATSC 3.0 are limited. Converting existing stations to 3.0 requires finding a home for their ATSC 1.0 programs on the stations remaining on 1.0. The popularity of ATSC 1.0 “diginets” has made it difficult to find a space for a new 3.0 host’s streams. One obvious solution is to improve the efficiency of the existing ATSC 1.0 capacity by using MPEG-4 video, which has roughly twice the efficiency of MPEG-2.
By The Numbers
Table 1 shows an example of average bandwidth allocation for a station carrying two HD streams and four SD streams in their 19.392 Mbps ATSC 1.0 stream. The HD streams are assumed to have a primary 5.1 audio and a secondary stereo audio stream for audio description or second language.
Extra bandwidth is allowed for null packets and PSIP data. Quality will vary depending on program content and use of aggressive statistical multiplexing is required to give an HD stream more bandwidth when needed and let the SD streams have more bandwidth when the HD streams don’t need it.
Early tests used MPEG-4 (AVC) encoding on one or more SD streams. Table 2 shows the result of converting all the SD streams in Table 1 to MPEG-4, keeping the same audio bit rates and reducing the video bit rate to 650 kbps.
That allows equal or greater video quality than a 1,000 kbps MPEG-2 stream. This configuration provides an extra 1,400 kbps of bandwidth, which could be used for one more MPEG-4 SD streams. Reducing the MPEG-4 SD bit rate to 50% of the MPEG-4 bit rate would allow two additional MPEG-4 SD streams at the lower rate.
Unfortunately, attempts to use MPEG-4 have resulted in complaints that the program had audio but no video from viewers with older TVs or NTIA coupon set-top boxes. If there was a way to hide the MPEG-4 content from the older TVs, it would likely eliminate the complaints, but I haven’t found a way to do that. As a result, use of MPEG-4 by full power stations has been limited.
There is a way to add significantly more capacity to lighthouse stations without leaving any viewers behind—transmit the HD content in MPEG-4 with a simulcast in SD in MPEG-2—leave all existing SD diginets in MPEG-2. Viewers with older TVs would not lose any programs, but the main program would be in SD on those sets. This would not matter for anyone using the NTIA coupon set-top boxes as their output is SD only.
Table 3 shows the bandwidth allocation for MPEG-4 only HD and MPEG-2 SD, assuming a 50% reduction in bandwidth for the HD streams compared to MPEG-2. Audio is 5.1 for the MPEG-4 HD streams and stereo for the SD MPEG streams, with room for a stereo secondary audio on the SD simulcasts. This scenario provides over 3,600 kbps of extra bandwidth, enough for three more MPEG-2 SD streams with stereo audio.
Simulcast Issues
If you’re interested in this approach, take some time to build a spreadsheet and test other scenarios. Consider dropping one of the MPEG-2 SD diginets—that would provide enough bandwidth for another MPEG-4 HD and its companion MPEG-2 SD. Another option would be to use stereo audio on the MPEG-4 HDs and a 96-kbps mono secondary audio tracks. With a small reduction in video bandwidth that would also allow an additional HD and companion SD.
Encoder experts may notice a potential problem with the simulcast approach. Statistical multiplexing allocates bandwidth based on stream content and priority. If two streams are airing complex content requiring extra bandwidth at the same time it may limit the bandwidth available to other streams. However, if the HD and SD companion streams can share the same audio (5.1 main and stereo secondary) the bandwidth gained could offset that effect and perhaps work better than delaying the video one of the streams.
The FCC has made it clear they want no viewers left behind. Allowing conversion of HD streams to MPEG-4 while providing an SD stream (with secondary audio and audio description) to viewers with older sets is one way to accomplish that goal. It will require approval from the FCC and likely negotiations with cable companies, if the SD MPEG-2 stream alone remains the “primary stream.”
Ideally, the FCC would consider both streams, MPEG-2 and MPEG-4, if both were identical, as “primary” for regulatory purposes.
Updates
I’ve received emails from readers interested in building the Pi-OTA DTV monitor I described in my November 2023 column at I’ve put all the files and instructions on how to build it on Github at https://github.com/DougLung2000/OTA-Pi-Monitor .
Since publishing the article I’ve made the web server more robust by adding the gunicorn WSGI and modifying the way the displayed data is updated. I also have tested it on the Raspberry Pi 5.
Long time readers will recall that “Kaffeine” was my favorite application for viewing and recording DTV broadcasts on my Linux laptop. Linux distributions are moving from X.org to the Wayland desktop server and Kaffeine does not work under Wayland.
Now I use “w_scan” (available in most Linux distributions) to scan for available channels wherever I happen to be and save them as a VLC “xspf” playlist file. An improved version, “w_scan2”, is available at https://github.com/stefantalpalaru/w_scan2. You can edit the source code to stop it from scanning UHF channels above 36. Load the xspf file into VLC to view the programs and program guides.
VLC allows recording, but I found it easier to install “tvheadend”, also available in most Linux distributions, for recording. It runs in the background as a systemd process and thus I don’t miss as many recordings as I did with Kaffeine.
As always, your comments and questions are welcome. Email me at dlung@transmitter.com.
