MPEG Transport Stream

The MPEG-2 standard is defined by ISO/IEC 13818 as "the generic coding of moving pictures and associated audio information." It combines lossy video compression and lossy audio compression to comply with bandwidth requirements. The basic structure of all MPEG compression systems is asymmetric because the encoder is always more sophisticated than the decoder.

MPEG encoders are always algorithmic. The better ones are also adaptive, using a feedback path. MPEG decoders are not adaptive and perform a fixed function. This works well for applications like broadcasting, where the number of expensive complex encoders is few and the number of simple inexpensive decoders is enormous.

The MPEG standard provides little information about how encoder processes and operation. Rather, MPEG-2 specifies how a decoder interprets metadata in a bit stream. The metadata tells the decoder the rate the video was encoded, defines the audio coding, and identifies channels and other vital stream information.

A decoder that successfully deciphers MPEG streams is called compliant. The beauty of MPEG is that it allows different encoder designs to evolve simultaneously. Generic low-cost and proprietary high-performance encoders and encoding schemes all work because they are all designed to communicate with the compliant decoder base.

Stream Structures
An MPEG-2 stream can be either an Elementary Stream (ES), a Packetized Elementary Stream (PES) or a Transport Stream (TS). The ES and PES begin with and are stored as files. Individual ESs are essentially endless because the length of an ES is as long as the program itself.

Starting with analog video and audio content, individual ESs are created by applying MPEG-2 compression algorithms to the source content in the MPEG-2 encoder. This process is typically called ingest. The encoder creates an individual compressed ES for each audio and video stream. An optimally functioning encoder will appear transparent when decoded in a set-top box and displayed on a professional video monitor.

A good ES depends on several factors, beginning with the quality of the original source material, and the care used in monitoring and controlling audio and video variables when material is ingested. The better the baseband signal, the better the quality of the digital file. Also influencing ES quality is the encoded stream bit rate and how well the encoder applies its MPEG-2 compression algorithms within the allowable bit rate.

MPEG-2 has two main compression components: intraframe spatial compression and interframe motion compression. Encoders use a variety of techniques, some proprietary, to maintain the maximum allowed bit rate while at the same time allocating bits to both compression components. This balancing act can sometimes be unsuccessful. It is a tradeoff between allocating bits for detail in a single frame and bits to represent frame to frame motion changes.

Researchers are still investigating what constitutes a good picture. Presently, there is no direct correlation between the data in the ES and subjective picture quality. For now, the best way of checking encoding quality is with the human eye, after decoding.

The Packetized ES
Each ES is broken into variable-length packets. The result is a PES containing a header and payload bytes. The header includes information about the encoding process required by the MPEG decoder to decompress the ES.

Each individual ES results in an individual PES. At this point, audio and video information still resides in separate PESs. The PES is primarily a logical construct and is not actually intended to be used for interchange, transport and interoperability. The PES also serves as a common conversion point between TSs and PSs.

Both the TS and PS are formed by packetizing PES files. During the formation of the TS, additional packets, containing tables needed to demultiplex the TS, are inserted. These tables are collectively called PSI and will be addressed in detail later.

Some packets contain timing information for their associated program, called the program clock reference (PCR). The PCR is inserted into one of the optional header fields of the TS packet. Recovery of the PCR allows the decoder to synchronize its clock to the rate of the original encoder clock.

Null packets, containing a dummy payload, may also be inserted to fill the intervals between information-bearing packets.

TS packets are fixed in length at 188 bytes with a minimum 4-byte header and a maximum 184-byte payload. Key fields in the minimum 4-byte header are the sync byte and the Packet ID (PID). The sync byte's function is indicated by its name. It is a long digital word used for defining the beginning of a TS packet.

The PID
The PID is a unique address identifier. Every video and audio stream as well as each PSI table needs a unique PID. The PID value is provisioned in the MPEG multiplexing equipment. Certain PID values are reserved or specified by organizations such as the Digital Video Broadcasting Group (DVB) and the Advanced Television Systems Committee (ATSC) for electronic program guides.

In order to reconstruct a program from all its video, audio and table components, it is necessary to ensure that the PID assignment is done correctly and that there is consistency between PSI table contents and the associated video and audio streams. This is one of the more critical points in a MPEG-2 stream.

There are four other important fields in the TS header. One is the continuity counter. It is a 4-bit field that repeatedly increments zero through 15 for each PID. It’s used to determine if packets are lost or repeated PCR. Second is the discontinuity indicator. It indicates a time base (PCR) and continuity counter discontinuity, which allows the decoder to handle such discontinuities. Third is the random access indicator. It indicates that the next PES packet in the PID stream contains a video-sequence header or the first byte of an audio frame. Fourth is the splice countdown. It indicates the number packets of the same PID number to the splice point when a new PES packet begins.

PSI
During the formation of the TS, additional packets, containing tables needed to demultiplex the TS, are inserted. These tables are collectively called PSI. PSI is part of the TS. PSI is a set of tables required for demultiplexing and sorting out which PIDs belong to which programs.

To identify which audio and video PIDs contain the content of a particular program, a Program Map Table (PMT) must be decoded. Each program requires its own PMT with a unique PID value.

In order to determine which PID contains the desired program's PMT, the Program Allocation Table (PAT) must be decoded. The PAT is the master PSI table with PID value always equal to zero (PID = 0). If the PAT cannot be found and decoded in the TS, then no programs can be found, decompressed, or viewed.

For a set-top box or ATSC tuner to successfully perform the program recovery and decompression process, the PSI tables must be sent periodically and with a fast enough repetition rate that it doesn’t delay channel-surfing viewers. Thus, checking the PSI tables for correct syntax and repetition rate is a vital part of MPEG testing.

Testing PSI involves verifying the accuracy and consistency of PSI contents. As programs change or multiplexer provisioning is modified, some problems may occur. One problem would be unreferenced PID. Packets with a PID value are present in the TS but are not referenced in any table.

If there are no packets with the PID value referred to in a PSI table present in the TS, the problem could be a missing PID.

Another useful PSI test is a check of program content. Just because there are no unreferenced or missing PIDs indicated does not mean that the viewer is receiving the correct program. There may also be a mismatch of the audio content from one program being delivered with the video content from another program. Because MPEG allows multiple audio channels for multiple languages, an air-check can ensure that viewers are receiving the correct language.

It is possible to use a set-top box and television to do the air check, but a better way would be to use an MPEG test set that incorporates all the PSI table checks plus a built-in decompressor with picture and audio display. This would allow you to correlate PSI contents and actual program content as well as allow a quick visual and aural check of ES.

By Ned Soseman, Broadcast Engineering

JPEG 2000

JPEG 2000 has caught the attention of the professional media world for good reason. First, it closely matches some workflows, where the production process operates on each frame of a video stream as a discrete unit. This is different from MPEG-2 and MPEG-4 AVC Long-GOP flavors, where, during the reconstruction process, algorithms reference frames before and after the frame being reconstructed.

The ability to compress each frame as a free-standing unit has made it popular in the digital intermediate space in Hollywood. JPEG 2000 is also of interest to those who want lossless compression. It can provide a bit-perfect reconstruction of the original compressed image, although at a cost in terms of bandwidth. Also, the wavelet compression used in JPEG 2000 provides some unique opportunities that are not available in other compression methods.

The wavelet transform separates the image into four sub-bands. The first sub-band is a lowpass horizontal and lowpass vertical (LL). Images that have gone through this separation are basically lower-resolution images of the original. The other sub-bands are as follows: lowpass horizontal and highpass vertical (LH); highpass horizontal and lowpass vertical (HL); and highpass horizontal and highpass vertical (HH).

Using wavelet transforms and some clever thinking, implementers can do some interesting things. For example, they can send only the LL image, if they know that they are feeding a low-resolution display. Or they can send the LL sub-band in a highly-protected stream, in order to ensure the original image arrives intact. That said, they can then send the higher-resolution sub-bands unprotected since a momentary loss of these sub-bands is not likely to be noticed.

Given JPEG 2000's popularity, it is not surprising there have been some developments that make it particularly interesting for professional applications. First, the ITU has created an amendment (1) that outlines specific configurations for broadcast contribution applications. These configurations are intended to establish interoperability points for those implementing JPEG 2000 in professional applications. This is important because, until the amendment was released, there were so many variables in the compression tool set that interoperability was unlikely. The second important development, Amendment 5 to the MPEG 2 standard (2), provides a mapping of the JPEG 2000 Program Elementary Stream (PES) onto the MPEG-2 Transport Stream (TS).

Finally, some time ago, the Pro-MPEG Forum started to develop a standardized way to transport MPEG-2 TS over IP networks. The Video Services Forum picked up on this work and continued to develop it, finally submitting a draft for standardization within the SMPTE. This standard, SMPTE 2022-2 (3), describes a method for mapping MPEG-2 Transport Streams onto IP networks using RTP and UDP. The document was approved in 2007 and is the most common standard deployed today for professional video transport applications.

So these three developments — development of broadcast profiles; a mapping of JPEG 2000 Program Elementary Streams to MPEG 2 Transport Streams; and wide availability of MPEG-2 TS over IP transport equipment — mean now it is possible to transport JPEG 2000 over IP networks.

JPEG 2000 over IP relies on three critical developments:
broadcast contribution profiles, JPEG 2000 PES to MPEG-2 mapping,
and SMPTE 2022-2 for MPEG-2 transport over IP networks.

Starting with a video source, the image is compressed using a compression engine. This engine is configured to one of the Broadcast Contribution profiles in ITU-T Amendment 3. The compression engine produces a JPEG 2000 PES. This stream is then fed to an MPEG-2 encapsulator. The encapsulator uses the mapping rules established in the MPEG-2 specification, Amendment 5, to map the PES onto an MPEG-2 TS. This MPEG-2 TS is fully compliant with MPEG-2 specifications because, from the outside, it looks just like a normal MPEG-2 Transport Stream. As such, the output of the MPEG-2 encapsulator can be fed into a SMPTE 2022-2 compliant video transport device. This device encapsulates the MPEG-2 TS in standard RTP and UDP packets, and then those packets are wrapped in IP packets. These IP packets can now be fed into an IP network.

You might wonder why we take a relatively new compression algorithm such as JPEG 2000 and encapsulate it in MPEG-2. There are several reasons for this. First and foremost, there are already a number of specifications for how to encapsulate a number of different audio formats into MPEG-2 Transport Streams. Remember: JPEG 2000 says nothing about audio. Using MPEG-2 TS allows us to transport and present the audio alongside the JPEG 2000 compressed video using well-known audio standards. Also, this approach allows us to leverage the existing SMPTE 2022-2 MPEG-2 TS over IP standard. Finally, there are no technical issues in MPEG-2 TS that need to be fixed in this application space, so re-use of Transport Streams rather than inventing something entirely new seems like a good solution.

So, the good news is that the time is ripe for development of an interoperable, open solution for the transport of JPEG 2000 video and audio over IP networks. The standards exist, and there is a clear path forward. But, there are a few issues that need addressed.

JPEG 2000 has been around for quite some time. As such, some proprietary JPEG 2000 over IP transport solutions have already been created. Of course, these were developed in response to customer demand, so existing implementations may need to be changed. Another issue is that while the broadcast contribution profiles in Amendment 3 go a long way toward interoperability in the JPEG 2000 PES space, recent analysis suggests, without further definition, implementations based upon these profiles will not be interoperable. Finally, until the industry actually tries to connect devices from different manufacturers together, interoperability cannot be assured.

Fortunately, the industry is becoming aware of these issues, and steps are being taken to begin work in earnest on interoperable, open transport of professional JPEG 2000 images over IP networks. I would expect to see some developments around this in the first half of the coming year.

Footnotes:

1. “Profiles for Broadcast Applications” ISO/IEC 15444-1:2004 Amd.3-2010 (ISO/IEC, Geneva, Switzerland: 2010) |Rec. ITU-T T.800 Amd.3 (06/2010) (ITU, Geneva, Switzerland:2010)
2. Amendment 5: Transport of JPEG 2000 Part 1 (ITU-T Rec T.800 | ISO/IEC 15444-1) video over ITU-T Rec H.222.0| ISO/IEC 13818-1
3. SMPTE ST20 22-2:2007 “Unidirectional Transport of Constant Bit Rate MPEG-2 Transport Streams on IP Networks”

By Brad Gilmer, Broadcast Engineering

Transport Streams 101

A Transport Stream (TS) is comprised of one or more packetized and multiplexed compressed video signals and their associated audio, along with program descriptors and other data. In broadcast DTV, there are two essential parts to the final Transport Stream.

First is the actual packetized compressed audio and video data as well as the tables and other data required to locate and extract them. The second major part is called Program and System Information Protocol (PSIP), which is required by the DTV receiver.

The PSIP data is what enables the receiver to know what channel is being received as well as what analog channel is associated with it and the names of the major and minor channels. PSIP also carries viewer information such as program guides, time of day and ratings for the programs.

Packetized Elementary Stream
To combine or multiplex the various data streams that make up the TS, they need to be packetized. The Elementary Streams (ES) such as MPEG-2 video or AAC audio are encapsulated into defined serialized data bytes called Packetized Elementary Streams (PES). Once the elementary streams are packetized, they can be combined and multiplexed into a single data stream known as a TS. Each packet is 188B, or 1504b, long.

Packet Identifiers
With several different packets used for each program (e.g. MPEG-2 video, one or more AAC audio channels, metadata, etc.) and one or more programs, the number of packets can increase quickly. Because the individual streams are no longer separate but combined as packets, this requires a system to identify and sort through the packets to extract the correct program.

Packet Identifiers (PIDs) are used for this function and are attached to each packet in the TS. PID numbering is arranged to keep associated packets grouped together. For example, the MEPG-2 video would be PID 65, while the associated AC-3 audio is PID 68; another program has its MPEG-2 at PID 81 and AC-3 at PID 84.

Program Map Table
The Program Map Table (PMT) is a list of the PIDs used for each program and what they are; there is one PMT for each program within a TS. The PMT also has a PID and it is always the first (lowest number) PID for the program. In the above example, the program with PIDs 65 and 68 has a PMT with a PID 64, and the program with PIDs 81 and 84 has a PMT with a PID 80. The information contained within the PMT lists the PIDs for all the packets and a description of what the packet is (e.g. MPEG-2, AAC, AC-3, data, etc.).

Program Association Table
The Program Association Table (PAT) is a list of all programs contained within the TS. This is where the PIDs for the PMTs are found and is the first step in extracting the desired program from the stream.

Program Clock Reference
Program Clock Reference (PCR) is used to lock the local 27MHz clock to the one used to create the encoded stream. There is a PCR for each program within the TS, and it can share the same PID as one of the PES. The PCR is a time stamp and its value is derived from a counter, running at the encoder, taken at the moment the packet leaves the multiplexer.

Differences between the received time stamps and the local clock are seen as errors, and the local clock is adjusted or reset. If there is a fault with the PCR, then a number of errors can occur, such as loss of lip sync, picture freeze and dropped frames. The PCR is developed at the encoder from either the horizontal sync of an analog signal or the bit rate of an SDI input.

The PCR is a component of the TS and is used to keep the local 27MHz clock locked to the originating encoder’s clock. The encoder’s 27MHz clock is derived from the input video, either SDI or analog video. This means that the stability of the input video will determine the stability of the 27MHz clock and, therefore, the accuracy of the PCR for that program.

The Presentation Time Stamp (PTS) is part of the coded audio and video streams; this tells the decoder when this particular video or audio must be presented to the viewer. The time stamps are derived and compared to the 27MHz clock. The PTS is what keeps and locks the audio and video together and maintains lip sync.

Errors in the PCR can be introduced by the encoder/multiplexer or in the transmission path, including remultiplexers and network transmission errors. The tolerance for PCR is 500ns.

Program and System Information Protocol
Program and System Information Protocol (PISP) is the last item added to the TS. It provides much of the glue that holds the disparate elements of the stream together. PSIP contains the Terrestrial Virtual Channel Table (TVCT), Master Guide Table (MGT), Rating Region Table (RRT), System Time Table (STT) and Event Information Tables (EIT).

All of these provide for an easier user interface as well as tuning and channel branding:

• The TVCT indicates which DTV channels are associated with which analog TV channels and what frequencies and modulation modes are used. It also provides channel names and tuning information.
  
  
• The MGT lists all the other tables available in PSIP.
  
  
• RRT is where various types of program ratings are located for all the programs in the TS.
  
  
• STT provides time of day information referenced to UTC.
  
  
• EIT contains lists of TV programs and their start times contained in the TS.

Once the decoder is locked onto the data stream and the packets sorted, PSIP can begin to populate the receiver with its information. This information for the viewer consists of the System Time Table (STT), which supplies the current date and time from the station (the program guide is based on this clock time, so any offset or error can cause viewers to miss programs); the Region Rating Table (RRT), which supplies ratings of the programs within the TS so different types of program ratings can be transmitted (e.g. MPA, FCC, etc.); and the Event Information Tables (EIT) 0-3, which list the next 12 hours of programming.

The Terrestrial Virtual Channel Table (TVCT) contains a list of all the channels that are or will be online, plus their attributes. This includes the major and minor channel numbers and their names. Channel 6 analog also has Channel 35 digital, so the major channel is six for both analog and digital, and the minor channels are 0 for analog, one for the first digital channel, and so on. The minor channels do not have to be sequential and can be any number from one to 999. Stations might do this to denote different programming sources. Major and minor channel names also come from the PSIP, such as WREY for the major channel, and each minor channel has its own name as long as it fits in seven spaces.

A major component of PSIP is the Master Guide Table (MGT) that lists all the other tables within the PSIP as well as sizes and version numbers, so tables can be updated.

Demultiplexing the Stream
The multiplexer combines all the PES and the associated data packets into one continuous serial bit stream. To extract the PES and view it, we need to first demultiplex the stream to separate out the individual PES and convert them into Elementary Streams (ES) of compressed video and audio. From there, they can be decompressed, converted to analog and monitored.

To begin the demultiplexing process, the decoder’s 90kHz clock must be synchronized with the multiplexer’s, and to do that, the sync byte must be found in the TS. Every packet contains a sync byte at its start. The sync byte comprises 8 bits, and because all packets are 188 bytes long, the next sync word comes around in another 188 bytes. This repetition makes it easier to find the sync byte and lock to it.

Once the demultiplexer has seen the sync byte at least five times, it then knows it has a good lock on the clock and can examine the rest of the stream. Then the individual packets can be clocked in and their Packet Identifiers (PIDs) can be read and sorted.


Once the decoder is locked to the TS, the Program Association Table (PAT) is used to find all the data elements within it. The PAT holds a list, or table, of all the PIDs and what they are for in the TS. When the viewer selects minor Channel 3, which is listed as “sports” (all this data comes from the TVCT), the PAT directs the decoder to PID 80, which is where the Program Map Table (PMT) is located, and lists the PIDs for the PES — in this case, they are PID 81 for MPEG-2 video, PID 84 for AC-3 audio (English) and PID 90 for AC-3 audio (Spanish).

These packets are then converted (this is where the PCR comes in) into a Program Stream (PS), and from there into their original Elementary Streams (ES) with the help of the system clock reference (i.e. individual serial data for the MPEG-2 video and the AC-3 audio). They are decompressed then supplied to the outputs for display and monitoring.


Source: Broadcast Engineering

MPEG-2 Basic Training

The MPEG-2 standard is defined by ISO/IEC 13818 as "the generic coding of moving pictures and associated audio information." It combines lossy video compression and lossy audio data compression to fulfill bandwidth requirements. The foundation of all MPEG compression systems is asymmetric because the encoder is more sophisticated than the decoder.

MPEG encoders are always algorithmic. Some are also adaptive, using a feedback path. MPEG decoders are not adaptive and perform a fixed function. This works well for applications like broadcasting, where the number of expensive complex encoders is few and the number of simple inexpensive decoders is huge.

The MPEG standards provide little information about encoder process and operation. Rather, it specifically defines how a decoder interprets metadata in a bit stream. MPEG metadata tells the decoder what rate video was encoded at, and it defines the audio coding, channels and other vital stream information.

A decoder that successfully deciphers MPEG streams is called compliant. The genius of MPEG is that it allows different encoder designs to evolve simultaneously. Generic low-cost and proprietary high-performance encoders and encoding schemes all work because they are all designed to talk to compliant decoders.

Before SDI
Asychronous Serial Interface (ASI) is a serial interface signal where a start bit is sent before each byte, and a stop signal is sent after each byte. This type of start-stop communication without the use of synchronized fixed time intervals was patented in 1916 and the key technology making teletype machines possible. Today, an ASI signal is often the final product of MPEG video compression, ready for transmission to a transmitter, microwave or fiber. Unlike uncompressed SDI, an ASI signal can carry one or multiple compressed SD, HD or audio streams. ASI transmission speeds are variable and depend on the user's requirements.

There are two transmission formats used by the ASI interface, a 188-byte format and a 204-byte format. The 188-byte format is the more common. If Reed-Solomon error correction data is included, the packet can grow an extra 16 bytes to 204 bytes total.

Making MPEG-2
An MPEG-2 stream can be either an Elementary Stream (ES), a Packetized Elementary Stream (PES) or a Transport Stream (TS). The ES and PES are files.

Starting with analog video and audio content, individual ESs are created by applying MPEG-2 compression algorithms to the source content in the MPEG-2 encoder. This process is typically called ingest. The encoder creates an individual compressed ES for each audio and video stream. An optimally functioning encoder will look transparent when decoded in a set-top box and displayed on a professional video monitor for technical inspection.

A good ES depends on several factors, such as the quality of the original source material, and the care used in monitoring and controlling audio and video variables upon ingest. The better the baseband signal, the better the quality of the digital file. Also influencing ES quality is the encoded stream bit rate, and how well the encoder applies its MPEG-2 compression algorithms within the allowable bit rate.

MPEG-2 has two main compression components: intraframe spatial compression and interframe motion compression. Encoders use various techniques, some proprietary, to maintain the maximum allowed bit rate while at the same time allocating bits to both compression components. This balancing act can sometimes be unsuccessful. It is a tradeoff between allocating bits for detail in a single frame and bits to represent the changes (motion) from frame to frame.

Researchers are currently investigating what constitutes a good picture. Presently, there is no direct correlation between the data in the ES and subjective picture quality. For now, the only way of checking encoding quality is with the human eye, after decoding.

The Packetized Elementary Stream
Individual ESs are essentially endless because the length of an ES is as long as the program itself. Each ES is broken into variable-length packets to create a PES, which contains a header and payload bytes.

The PES header is data about the encoding process the MPEG decoder needs to successfully decompress the ES. Each individual ES results in an individual PES. At this point, audio and video information still reside in separate PESs. The PES is primarily a logical construct and is not really intended to be used for interchange, transport and interoperability. The PES also serves as a common conversion point between TSs and PSs.

Transport Streams
Both the TS and PS are formed by packetizing PES files. During the formation of the TS, additional packets containing tables needed to demultiplex the TS are inserted. These tables are collectively called PSI. Null packets, containing a dummy payload, may also be inserted to fill the intervals between information-bearing packets. Some packets contain timing information for their associated program, called the Program Clock Reference (PCR). The PCR is inserted into one of the optional header fields of the TS packet. Recovery of the PCR allows the decoder to synchronize its clock to the rate of the original encoder clock.

The Transport Stream is defined by the syntax and structure of the TS header

TS packets are fixed in length at 188 bytes with a minimum 4-byte header and a maximum 184-byte payload. The key fields in the minimum 4-byte header are the sync byte and the Packet ID (PID). The sync byte's function is indicated by its name. It is a long digital word used for delineating the beginning of a TS packet.

The PID is a unique address identifier. Every video and audio stream, as well as each PSI table, needs to have a unique PID. The PID value is provisioned in the MPEG multiplexing equipment. Certain PID values are reserved and specified by organizations such as the Digital Video Broadcasting Group (DVB) and the Advanced Television Systems Committee (ATSC) for electronic program guides and other tables.

In order to reconstruct a program from all its video, audio and table components, it is necessary to ensure that the PID assignment is done correctly and that there is consistency between PSI table contents and the associated video and audio streams.

Program Specific Information
Program Specific Information (PSI) is part of the Transport Stream (TS). PSI is a set of tables needed to demultiplex and sort out PIDs that are tagged to programs. A Program Map Table (PMT) must be decoded to find the audio and video PIDs that identify the content of a particular program. Each program requires its own PMT with a unique PID value.

The master PSI table is the Program Association Table (PAT). If the PAT can’t be found and decoded in the Transport Stream, no programs can be found, decompressed or viewed.

PSI tables must be sent periodically and with a fast repetition rate so channel-surfers don’t feel that program selection takes too long. A critical aspect of MPEG testing is to check and verify the PSI tables for correct syntax and repetition rate.

Another PSI testing scenario is to determine the accuracy and consistency of PSI contents. As programs change or multiplexer provisioning is modified, errors may appear. One is an “Unreferenced PID,” where packets with a PID value are present in the TS that are not referred to in any table. Another would be a “Missing PID,” where no packets exist with the PID value referenced in the Transport Stream PSI table.

Good broadcast engineers never forget common sense. Just because there aren’t any unreferenced or missing PIDs doesn’t guarantee the viewer is necessarily receiving the correct program. There could be a mismatch of the audio content from one program being delivered with the video content from another.

Because MPEG-2 allows for multiple audio and video channels, a real-world “air check” is the most common-sense test to ensure that viewers are receiving the correct language and video. It’s possible to use a set-top box with a TV set to do the air check, but it’s preferable to use dedicated MPEG test gear that allows PSI table checks. It’s also handy if the test set includes a built-in decoder with picture and audio displays.

By Ned Soseman, Broadcast Engineering

Monitoring MPEG in an IP Network

The cost and ease-of-use advantages of moving video using IP have been welcomed in cable, IPTV and satellite applications around the world. For the most part, IP remains a rarity in most of today's television studios. However, these same benefits will eventually make the approach more prevalent in the broadcast market. Signal monitoring throughout the video delivery chain is essential to ensuring the viewer's quality of experience (QoE), and for this reason, broadcasters will benefit from having a thorough understanding of what is required to effectively deploy IP and accurately monitor IP content.

IP's Usefulness in Broadcast
While a broadcast facility may never have a fully deployed IP network backbone in the studio, IP links are set to replace ASI interconnects between equipment in many applications.

Encoders, multiplexers and other equipment located at the broadcaster's headend are already IP-capable devices, likely linked by ASI in most environments. Moving forward, IP networks with high-end switches or routers at the center will feed multiple pieces of equipment within the broadcast operation and become increasingly common as organizations begin recognizing the benefits of this technology. Benefits include relatively low-cost, facilitated transmission of signals to multiple destinations (multicasting) and ease of signal monitoring.

The use of IP in a variety of broadcast applications is becoming more common.
Another likely location for the imminent incursion of IP into the broadcaster's world is the connection between the studio and the transmitter. A transmitter is typically linked to the studio by microwave; however, some broadcasters are already considering replacing this link via an IP connection. Leasing fiber eliminates both the expense and uncertainty of microwave systems, which are subject to weather and other interference.

How Video Over IP Works
Digital video is packetized data — ones and zeros moving 188 bytes at a time in a transport stream. IP transmits data from one point to another, and because digital video is essentially data, it can also be arranged in Ethernet frames and transmitted. However, IP does pose fundamental problems as a video transfer scheme, most of them stemming from the nature of IP. IP was developed some 30 years ago as a way to move data quickly and efficiently from Point A to Point B. In traditional data transfers, timing and sequence do not matter very much. For example, when sending or viewing a Web page or e-mail, the order in which the data components arrive is unimportant as long as the content appears correctly once loading is complete. Should data be lost or corrupted in transit, the content can easily be retransmitted and loaded without the end user ever knowing the difference.

Transmitting live video is entirely different. The frames containing the data — typically MPEG — must arrive synchronized, on time and in sequence if the footage is going to appear as intended to the viewer. In a video application, retransmission of lost or corrupt data is nearly impossible because the appropriate moment for display has passed.

When MPEG-compressed video travels on an IP network, the content is typically arranged in groups of seven data packets, each wrapped in an Ethernet frame. These frames each contain source and destination addresses so that the data is routed appropriately within the network. As the frame arrives at the receiver-decoder (or other device), the MPEG packets are extracted and treated the same as they would have had they arrived by ASI.


Ethernet frames carry the compressed MPEG video information.
In an IP network that has been properly designed to carry video, the switches and routers are configured to prioritize video data. If the integrity of the video is to be maintained at a high level, then IP infrastructure must also be maintained and a monitoring solution put in place that addresses the problems unique to IP infrastructure — specifically jitter and dropped, lost or out-of-order data packets.

How Video Over IP is Monitored
In the cable and satellite industries where video delivery over IP is common, effective monitoring techniques have been tried and proven. Typically, a monitoring device performs multiple tests continuously on all inputs. Because almost all of these tests are based on the timing within the data transmission, the monitor's most fundamental job is to keep track of packet arrival times with a high degree of accuracy. Within the MPEG signal, the monitoring device assesses the timing to ensure that it meets a predetermined standard, such as ETSI TR 101 290 in Europe. The timing standard — designed to ensure QoE for the viewer — codifies acceptable arrival timing for the component parts of the stream and the Program Clock Reference (PCR), which contributes to timing accuracy. The component parts are audio and video data, as well as the tables that enable the consumer's television to perform decoding, display the image on the screen, and properly represent auxiliary items like a program guide and subtitles.

Effective monitoring of an IP-based system requires timestamping every Ethernet frame so that the rate and sequence can be tested. The first test that must be performed is for jitter, which is a measure of the cadence of the packets in the line. The packets should arrive at regular intervals, without bursts or prolonged gaps. To some extent, the buffer in the receiver-decoder can compensate for these issues, but if they become extreme, the buffer is overwhelmed and viewer experience suffers.

The second test is for dropped or out-of-order packets. These can be hard to recognize because the IP stream typically lacks both indicators of packet order and a means of notifying the network that a packet has been lost. To get around this, a monitoring device can penetrate the packet, scrutinize the MPEG packets within and use continuity counters to determine whether all the packets are present. This is the same kind of MPEG test that is conducted for an ASI or other traditional broadcast signal. With IP transport, the Ethernet frame adds another layer of complexity to the address with monitoring.

Monitoring devices typically incorporate slots for one or two cards that can perform either IP or ASI monitoring, depending on the needs of the system. In a traditional broadcast station, a monitor with four ASI inputs might be implemented to cover all the necessary streams at the headend or studio. One of IP's advantages over ASI is that a single IP input can simultaneously monitor all the traffic on the network — hundreds of IP multicasts — rendering multiple monitor inputs unnecessary and ultimately saving the broadcaster money. In fact, the number of IP transport streams is limited only by overall network capability.

Once the Ethernet frame is removed from the MPEG layer, the monitoring process is the same as for transport streams carried over any other physical medium. The monitor assesses the timing of elements such as PAT and PMT tables to ensure their rates meet the predetermined standard (ie: ETSI TR 101 290). The time-checks also reveal gaps between packets that contain video and audio. Beyond that, the monitor scrutinizes the accuracy of the PCR.

Because timing really is everything for optimal video delivery, the accuracy of the monitoring device is also important; even a small degree of inaccuracy distorts the information gained from the monitoring process. Some monitors unintentionally introduce delay and inaccuracy because they rely on an off-the-shelf network interface card to input the video streams and disregard the specialized requirements of delicate IP-based transport streams. Because these cards must subsequently pass the data through the operating system's software IP stack, much of the timing information's granularity is inevitably lost to processing delays.

A more effective technique is for a proprietary network interface card to timestamp the Ethernet frames at the time of input — without injecting processing delays. This can be accomplished by using specialized hardware on the input card to separate Ethernet frames carrying transport stream packets from those containing general IP traffic. The general traffic data can be passed through the operating system's normal IP stack while the frames containing transport stream packets are timestamped and passed directly to the analysis software, bypassing the IP stack.

The Ethernet frame timestamping is done using a highly accurate clock reference (such as an oven-controlled crystal oscilator), and then the frame timestamps can be inferred and transferred to the transport packets inside the frames by referencing the physical link speed on the Ethernet interface. This methodology yields more accurate data for subsequent reference and analysis by the specialized software. In fact, timestamping techniques like this have been proven effective and are common with single stream ASI inputs. In an IP network, where there may be hundreds of IP multicasts, it is less common but even more useful and necessary.

Conclusion
As digital television becomes the global standard, delivering video from source to home becomes an increasingly complex process that relies on multiple transport techniques. Each of these techniques — and each combination of them — is accompanied by a potential for error that can diminish the quality of the video signal being delivered. If signal quality deteriorates or is interrupted, viewers may change channels, switch providers, or even turn off the television set altogether. IP-based signal transmission schemes are not yet as familiar to broadcast engineers as their more traditional ASI and RF counterparts. However, as the use of IP-based signals increases, their effective and accurate monitoring becomes commensurately important to the viewer's quality of experience.

By Seth Vermulm, Broadcast Engineering