DekTec logo
Conveying Transport Streams over IP  

Conveying Transport Streams over IP

DekTec offers several products for the transmission, reception and analysis of TS over IP.
We explain the technical details involved, and methods used to make the transport reliable under real-life conditions with lost packets and network jitter.

 

DekTec TS-over-IP Products

The selection of DekTec products below can help you to build and test broadcast systems that employ TS-over-IP.

PCIe Network Cards

Network cards for building PC applications with TS-over-IP input/output. Our API takes away the IP complexities so that you can concentrate on the application logic.

DTA-2160 DTA-2160
GigE + 3x ASI for PCIe
DTA-2162 DTA-2162
Dual GigE ports for PCIe,
supporting SMPTE 2022-7

DTE-Series Standalone Converters

Plug-and-play ASI to IP or IP to ASI. You can control and monitor operation of these units remotely through a web interface.

DTE-3100 DTE-3100
IP-to-ASI converter
DTA-3120 DTE-3120
ASI-to-IP converter

Bare-Board OEM Modules

Fit these units in your equipment to add ASI I/O if you have IP ports, or to add IP if you have ASI I/O.

DTM-3200 DTM-3200
ASI-to-IP or IP-to-ASI
DTM-3224 DTM-3224
Quad ASI-to-IP converter

Test & Measurement

Our industry-standard Test & Measurement applications support TS-over-IP well.

StreamXpert StreamXpert
Analysis of TS-over-IP
Xpect Xpect Mosaic
24/7 monitoring
StreamXpress StreamXpress
Generation of TS-over-IP

Why Transport Stream over IP?

With the proliferation of IP networks and computers in the video world, many companies are replacing traditional dedicated video links like satellite and microwave with IP-based transmission. One of the big advantages of IP links is that they are typically bidirectional and can use off the shelf routers and switches. For most real-time, point-to-point applications, users transmit Transport Streams over IP ("TS over IP") utilizing the SMPTE 2022 standard.

The video and audio is encoded in a compression format (MPEG-2, H.264, HEVC etc.) and packaged into an MPEG-2 Transport Stream (TS). This TS is then encapsulated in IP packets for transmission. As most Transport Streams are distributed inside the facilities over ASI, there is typically a need to convert from ASI to IP to go “outside” of the facility to the WAN.

MPEG-2 Transport Stream Encapsulation in IP Packets

Ethernet frame with 1 to 7 Transport Packets

Transmission over WAN

WAN stands for “Wide Area Network,” while LAN is a “Local Area Network.” By definition, a WAN is a network that connects two locations that are not on the same LAN. Transmitting video over WANs is different from transmitting video over LANs because users rarely have control over the complete network (like the internet); When transmitting video over a WAN some redundancy scheme must be used to ensure quality of service.

Several DekTec products support the generation of Forward Error Correction (FEC; see ‘Protecting Your Video Transmission’) on the transmission side. On the reception side DekTec offers FEC processing for recovering lost packets. As an example, a combination of a DTE-3120 ASI-to-IP converter and a DTE-3100 IP-to-ASI converter can be used to provide an IP pipe with high reliability between two ASI connections.

ASI Tunneling through a WAN Network

ASI tunneling with DTE-3100/3120

Controlling Your Video over IP for Distribution

When transmitting a real-time TS over IP over a WAN, there is no second chance. Each packet is sent once over the network with no possibility to resend, retry, or even know if the TS reaches the destination. Some companies have developed propriety ways of resending lost packets over IP for video transmission, but these are at the expense of increased bandwidth and large induced delays.

DekTec ASI-to-IP and IP-to-ASI converters provide full remote control of the encapsulation details, delays, and provide statistics over a web browser interface giving you full monitoring capabilities of your video over IP transmission.

Protecting Your Video Transmission

As video data cannot be resent through a WAN, the best way to ensure proper delivery is to protect the data as much as possible and plan for the “best chance” of delivering all the packets to the receiver. The SMPTE 2022 standard makes provisions for this by enabling the Forward Error Correction (FEC) scheme, as described in SMPTE 2022-1. FEC is a method for creating redundant information from the original stream that is temporally offset from the main video stream. If the main data stream is damaged due to the loss of a packet, FEC data can be used to reconstruct the missing or damaged packet at the receiver end. FEC is limited in the number of IP packets that it can recover — the maximum is typically 20 in a row. The receiver will indicate how many packets were lost, how many have been recovered, and how many could not be recovered. Note that FEC adds bandwidth (up to 25%) and delay (for the time to recover the packets).

Example of FEC Performance and Cost for SMPE 2022-1

FEC Bitrate Added latency vs bitrate Recovery
column/row overhead 3Mbps 30Mbps 100Mbps capabilities
XOR(5, 10) 10% 176ms 17.6ms 5.3ms 5 IP packets
XOR(10, 10) 10% 351ms 35.1ms 10.5ms 10 IP packets
XOR(20, 5) 20% 351ms 35.1ms 10.5ms 20 IP packets
XOR(8, 8) 12.5% 225ms 22.5ms 6.7ms 8 IP packets
XOR(10, 5) 20% 175ms 17.5ms 5.3ms 10 IP packets
XOR(8, 5) 20% 140ms 14ms 4.2ms 8 IP packets
XOR(4, 6) 16.7% 84ms 8.4ms 2.5ms 4 IP packets
XOR(6, 4) 25% 84ms 8.4ms 2.5ms 6 IP packets

All DekTec products with an IP interface provide enough buffer and processing power to create or recover lost packets using the FEC scheme of the SMPTE 2022-1.

Seamless Protection Switching with SMPTE 2022-7

In a broadcast system, high availability is a big part of the system design, so redundancy is quite often a consideration. FEC can correct some of the packet drops but can’t help if the outage is too long or the packet drops overwhelm the FEC recovery system. SMPTE 2022-7 offers a way to create redundancy by sending the same IP packet to the same destination via two different paths and re-creating the stream packet-per-packet at the receiving end from the two versions. In this case there is no main and backup. Each IP packet which is tagged with an ID count is identified and if it is missing or damaged, the receiving equipment will replace it by the same packet coming via a different link. The DTA-2162 supports the SMPTE 2022-7 protocol for redundant transmission and reception of TS over IP packets.

Using DTA-2162 for SMPTE 2022-7 Seamless Protection Switching

Seamless Protection with DTA-2162

Analysis of Video over IP

When sending TS-over-IP packets over a LAN, multiple problems can occur.

Dropped Packets and Bit Errors in IP Packets

Dropped packets are the enemy when transmitting your TS over IP. As there is no retransmission in UDP/RTP, any dropped packet is lost forever, unless you are using FEC. Dropped packets can come from two main sources: a discarded packet due to a bit error or a lost packet due to a buffer overflow.

If a bit in an IP packet is modified due to signal noise, the next network device the packet encounters will most likely discard that entire packet. Each network device performs a CRC calculation on the packet upon arrival, and if the CRC calculation doesn’t match the expected value, the packet will be discarded. This type of packet loss typically results in a steady packet loss rate (one packet lost once in a while). A bad cable, too long of a cable run, or faulty equipment will all create this kind of bit error.

Most network devices have small input buffers, making overflow during a traffic burst a reality. If a switch is busy with multiple tasks or is over-subscribed, it could take too long for the input data to be routed, overflowing the input buffer and resulting in dropped packets. Typically, several packets are lost at once, resulting in a burst of lost packets. DekTec products have large input buffers preventing overflow. Dropped IP packets will be detected in DekTec analysis software like StreamXpert as it translates to missing Transport Packets, showing up as continuity count errors in the software.

Network Jitter

By definition, transmission over IP will create jitter and bursts in the TS data. Each IP packet typically carries seven MPEG-2 Transport Packets, so Transport Packets will be transmitted in bursts of seven at a time, even if there is no network jitter. A delay in processing input in network equipment will create network jitter, where IP packets are not spread equally in time anymore, creating traffic bursts. The DTA-2160 and DTA-2162 PCIe cards include on-board packet schedulers to ensure that there is zero jitter at the emission of the Transport Stream over IP. Jitter is not really a huge problem by itself if the network and edge device can handle it. As the input buffers of network devices are typically fairly small, however, a network traffic burst can result in overflowing and dropped packets.

On the receiving end, edge devices need to be able to absorb traffic bursts to avoid overflow as well as underflow. As typical transport interfaces like ASI feature a constant bitrate with equally spread packets, the output of edge devices needs to be capable of having enough packets in their buffers to avoid underflow, which creates a disruption of the output signal.

DekTec products all have large input buffers and offer configurable delay in order to avoid underflow. All DekTec products can absorb jitter and are using multiple clock recovery algorithms to ensure smooth Transport Stream output to make sure downstream devices can recover the data error free.

TS-over-IP Security

Transporting TS over IP is popular and convenient especially over the internet. However, to receive the IP packets into your facility, you need to open firewall ports, expose public IP addresses which can create some security challenges. Especially now that many video facility’s internal networks run on IP, an external IP connection to the core network can be risky. Fortunately, there is a simple and cost-effective way to completely separate the internet carrying the incoming video feed from the core internal video network. The solution includes going back to ASI which is a unidirectional link of Transport Stream over coaxial and then convert back to IP on the core network. No attack can infiltrate the ASI domain because there is no processing capability within it to exploit. IP to ASI conversion at the destination can help many broadcasters avoid security risks during this transition phase more reliably and cost effectively than the alternative of IP firewalls.