The last newsletter focused on video conferencing and how it operates on an IP network. Now our study will consider the forms of video that depend directly on IP and the MPEG transport stream format. This format was first used in enterprise and carrier networks to support what has been called IPTV. However, it now includes digital signage and some forms of streaming video. While I’ll call all of these IPTV, the attribute that characterizes this video is the format of the data packets. The headers include IP/UDP/RTP/ MPEG data.
Seeing that we already considered UDP as a transport protocol, we should again mention the role of RTP (Real-time Protocol). When a receiver gets IP packets that have audio or video in them, it needs to know a minimum of at least these things:
- Is the payload audio or video?
- What source (camera, left audio, right audio)created it?
- Is this packet being received in order?
- At what time (playout time) do I need to present this to the user?
RTP provide codes that indicate the source, the payload type, a sequence number and a presentation time stamp. The MPEG transport stream format carries this same information. This means that if the engineers developing the encoder and decoder chose to, they can eliminate RTP and use the format of IP/UDP/ MPEG data. Most carriers such as Comcast and Time-Warner do that. In the AV industry there seems to be a feeling that RTP is needed but decades of carrier implementations show this not to be true.
Now, let’s consider the MPEG transport part of the video transmission. You may have read in one of our previous newsletters that the MPEG transport stream protocol ( MPTS) should not be confused with MPEG compression. MPTS is a streaming format, a way to layout the data that will be placed in the transported IP packets. Let’s start with the encoder. It ingests an audio or video stream and, if necessary, digitizes it and compresses it. Here the MPEG compression is done. The result of this process is an elementary stream. This stream is broken into 184 byte chunks of data and each has a four byte header appended to it. That’s where the data for sequencing, payload identification, and source identification is inserted. At this point we have created what is called a transport packet with a length of 188 bytes. To insert these into IP packets for distribution, we look at the standard maximum length of an Ethernet frame and find it can hold 1500 bytes. After deducting the length of the IP and UDP headers, we see there is space for 1472 bytes. The IP and UDP headers use 28 bytes. This will allow an IP packet to carry seven, but not eight, transport packets. As a result, each IP packet carries seven transport packets which may be a mix of audio or video. Considering the number of bits in a compressed video frame, this is just a small portion of what the user will view.
When IPTV video is placed on a typical enterprise network, it must be protected from loss, high jitter and interference from bursty traffic. For example, mixing system backups that use TCP for transport onto the same physical segments as IPTV can be “a recipe for disaster”. TCP applications are prone to take all the bandwidth they can get. And, they have a bursty character. The result is often high jitter that negatively affects IPTV or digital signage stream. The best bet is to put this form of video on its own VLAN, and if possible, to also avoid wireless connections.
