The Challenges Of Sending IP Video Over A WAN

One of the big advantages of Ethernet links is that they are bi-directional and much less expensive to deploy. This allows a content distributor to use their forward channel for sending the video and audio while the reverse path is used to monitor the receiver site. For most real-time, point-to-point applications (e.g., live telecasts), a transport stream (TS) is sent over a SMPTE 2022 compliant IP connection. The video and audio is encoded in a compression format (MPEG-2 H.264, H.265, JPEG2000 etc.) and packaged into yet another (MPEG-2 TS) format. The TS is then encapsulated over IP/Ethernet for transmission.

Configuring Transmissions Over A WAN

By definition, a wide area network (WAN) connects two locations that are not on the same local area network (LAN). They are often separated by a great distance and may be in different cities, states, or even countries. A WAN is then used to connect multiple LANs together. There are private WANs where the Ethernet lines are reserved for a company or a group of people, and there are public WANs. A public WAN is the Internet as we know it. Private WANs are more like long-distance LANs with data traveling across reserved lines between them.

Transmitting video over WANs is different than transmitting video over LANs because users rarely have control over the complete network; typically they only control the end point that belongs to each of the LANs and the WAN trying to connect them.

When transmitting real-time streams over IP from point to point over a WAN, there is no second chance when following the SMPTE 2022 standard. The data is sent once over the network with no possibility to resend, retry, or even know if the TS reaches the destination. We refer to this as “fire and forget” because we send (“fire”) content over the network and forget about it. The delivery pass can’t be altered. In the past some companies have promoted proprietary ways of resending lost packets over IP for video transmission, but these are at the expense of increased bandwidth and large induced delays. [The Video Services Forum has recently announced new standards that facilitate retransmission without delay.] This has forced content providers to purchase end-to-end equipment from a single supplier.

However, what happens if some (or all) packets don’t arrive at the desired destination? A single Ethernet packet can carry up to seven MPEG-2 TS packets. If a packet is lost in the transmission, it will affect the output stream and could affect the picture. (It is difficult to say for sure what the impact of the lost packet will be, as it depends on the actual packet lost.)

For example, if the lost Ethernet packet only contains information pertaining to a corner of the picture—affecting only one or two pixels—the result might be a barely noticeable artifact on the decoded picture. If, on the other hand, the missing packet pertains to the start of the audio frame, it could result in a very loud pop. Another issue is that the loss of packets over a WAN is unpredictable and none of the network equipment is aware of the content that is being transmitted... Read the full article in The Broadcast Bridge