Detecting media rate for measuring network jitter

#Digital multimedia content (e.g. video and/or audio data) must be transported across communication networks in a reliable and timely manner to the end user. Streaming video services (e.g. Internet Protocol television (IPTV), video conferencing, video-on-demand, etc.) are especially sensitive to delay, jitter, or data loss, which can all negatively impact the quality of the end user's experience. Typically, digital multimedia content is encoded prior to transmission across the network. Part 1 (Systems) of the Moving Pictures Expert Group (MPEG-2) standard defines a Transport Stream (TS) for encoding and transporting multimedia content across somewhat unreliable mediums such as broadcast channels, internet protocol networks, etc. The Transport Stream consists of packets that carry video or audio data in their payload. The TS packets are received and decoded to reconstruct the original multimedia content. The Transport Stream protocol is also specified in International Standard ISO/IEC13818-1.

#Determining the performance of a network that carries digital multimedia content is an important element to the successful design and operation of such a network. One measure of a network's performance is known as the Media Delivery Index (MDI). The MDI has two components: the delay factor (DF) and the media loss rate (MLR). The MDI is expressed as two numbers separated by a colon: DF:MLR.

#The DF component of the MDI is the maximum difference, observed at the end of each network packet, between the arrival of media data and the drain of media data. DF is indicative of the packet jitter. A high value for DF indicates that a larger buffer depth is required to minimize the effects of packet jitter. To calculate DF, consider a virtual buffer VB used to buffer received packets of a stream. Each time a packet Pi, where i>0, arrives during a measurement interval, compute two VB values, VB(i,pre) and VB(i,post) as follows:

#FIG. 1 shows a block diagram of a system for sending a transport packet stream across a network.

#FIG. 2 shows an exploded view of an exemplary transport packet stream having N transport stream packets.

#FIG. 3 shows a plot of an exemplary transport packet stream against a timeline as it arrives at the receiver.

#FIG. 1 shows a block diagram of a system for sending a transport packet stream 21 across a network 22. The transport packet stream consists of Transport Stream (TS) packets, encoded according to the ISO/IEC 13818-1 MPEG-2 standard. A transmitter 24 inserts Program Clock Reference (PCR) timestamps into selected TS packets according to the ISO/IEC 13818-1 MPEG-2 standard, and transmits the transport packet stream 21 across the network 22 to a receiver 26. For a variable bit rate (VBR) transmission, the stream rate is defined to be constant between successive PCRs. As will be described below, the calculation for DF can be simplified by using these PCR timestamps that are already included within the TS packets.

#FIG. 2 shows an exploded view of the transport packet stream 21, having N TS packets. (It should be noted that if network 22 is an internet protocol (IP) network, seven TS packets 23 are normally grouped together into an Ethernet frame for transmission). Each TS packet 23 has a header 25 and a payload 27. The header 25 in FIG. 2 contains an adaptation field 29, although this field is optional. Within the adaptation field 29 is the Program Clock Reference 31 (PCR), which is a timestamp from a system clock within an MPEG-2 encoder in the transmitter 24 that is inserted at the time the packet is transmitted. The PCR 31 is 48 bits long and consists of 2 sections. The first section is 33 bits wide, and includes a 90 kHz clock. The second section is 9 bits wide, and is a 27 MHz clock. The remaining 6 bits are reserved.

#The PCR 31 is recovered by the receiver 26 and used as a reference for two other timestamps within the transport stream layer: the decoding timestamp (DTS) and the presentation timestamp (PTS). The DTS and PTS specify the time instants at which the packet should be decoded and presented, respectively. The PCR 31 is a necessary field because the DTS and PTS use it as a reference base—without the PCR 31, the TS packets 23 could not be decoded at the proper time. The MPEG-2 standard requires that the PCR 31 be provided at least once every 100 milliseconds (although the PCR 31 could be included more often), but not every TS packet 23 needs to include a PCR 31. The standard also requires that the value of the PCR be accurate to within 500 nanoseconds of the actual scheduled transmission time.