What is PCR anyway ?  Let's find out.

To answer that question, we need to go back in time a little, to the very early days of IP Video, and perhaps even before the use of networking for video transport....

The MPEG Transport Stream is a very mature and very complex standard for carriage of audio, video and metadata over a digital data stream.  Dating back to 1997, it was originally designed to run on data connections including ASI (which runs data point to point on a video-style coax cable), but later become widely used on IP based network connections.

Back in 1997 it would have been mostly a hardware based standard, connecting together hardware encoders and decoders (IRDs) to pass video between them, sometimes over long distances, and certainly between different physical buildings.  Here is where PCR comes in - within a single building all the video equipment would have used a single common genlock reference, and probably a house timecode - and in doing so everything moved in lock-step.

However - when you feed a stream between buildings - which may have completely independent genlock and timecodes, you could run into a problem when attempting to decode a transport stream from another building on a locally genlocked SDI output - since the long term clocking speed of the 2 systems may be different.  PCR is a self contained clock running inside the transport stream which is used to steer a derived genlock at the receiver.  PCR also contains a running time clock, which is also critically important for the decoding process as we will discuss next.

It's important here to differentiate a fundamentally 'real time' system like SDI with a pseudo-real time mechanism like an MPEG Transport stream.  They are both designed to deliver 1 x speed video and audio, but they do it in very different ways.  In SDI pictures and sound arrive on the cable and are (more or less) instantly presented to the viewer as they arrive - imagine the original analog TV where the signal literally moved a cathode ray across a screen as it modulated.  Whilst there might be small scale line buffers (or even a complete frame buffer) in an SDI device, that's pretty much as far as it goes in terms of buffering, but in modern video streaming, and certainly in MPEGTS, there is a deliberate disconnect between the incoming data stream, and the final video+audio presented to the viewer.

Within MPEGTS, video and audio data arrives ahead of time, allowing plenty of time to decode the data before its required to presented to the viewer. Every piece of media carries 2 timestamps - the decode timestamp and the presentation timestamp, and these are times with respect to the running PCR clock.  In a crude example, If the PCR Clock currently stands at 1 hour, you might expect data arriving at the same time to be targeted for decoding at 1 hour and 1 second, and presenting at 1 hour and 2 seconds - this ensures that when the PCR clock strikes 1 hour and 2 seconds, the video frame  is decoded and ready to pump out to the viewer.  This mechanism allows for unpredictable time taken to decode video, and also to provide a clock to drive the final SDI video hardware.  All very clever 1990's technology.

Its 2023 - why do we still care so much about PCR  ?

As we have learned, PCR has two main functions - to communicate absolute time with respect to the timeline for decoding and presenting media (this is effectively timecode), but also to infer a longer term speed of the clock, since no two clocks ever run at exactly the same speed (this is effectively genlock).  In modern software based systems, genlock is far less important, although the timecode part is still needed.

PCR is a periodic time signal embedded in the MPEG Transport stream, and you can imagine that hardware based systems which are deriving their SDI clocks from the PCR will expect that PCR clock to be very steady, and its here that we introduce the concept of PCR jitter - which is the variability of the ticking of the clock.  If messages arrive (for example) once every 40 milliseconds - bang on 40 mSec intervals, you might say you have 0% PCR jitter - however, if your PCR messages are delayed a bit here and there by any number of influences, you will get non-zero PCR jitter.  Software typically doesnt care too much about this, since there is usually a fairly soft link between stream timecode and locally actioned time - but existing hardware devices still care passionately about PCR jitter since it has such a big effect on their (relatively inflexible) concept of time.

So, in software, we can generally accommodate high PCR jitter, but for hardware decoders we can not, and that is why we still need to pay attention to PCR Jitter. If your software generated MPEG TS is aimed at decoding with a hardware decoder (often called an IRD), you will find that too much PCR jitter means the decoder will fail to properly output the video stream over SDI.

Measurement of PCR Jitter is an important component in the ETSI TR 101 290 DVB compliance standard which is generally used to evaluate the validity or correctness of an MPEG Transport stream.

That all sounds very complicated - how are we supposed to measure any of this  ?

Great question.  This whole topic is what drove the development of the MPEG TS Visualiser in the Sienna ND Processing Engine.

Rather than presenting streams of data which are hard to interpret, the Sienna TS Visualiser shows a graph based display of data, along with a re-imagining of the traditional SDI eye-pattern to give an at-a-glance conclusion of PCR Jitter.

Let's take a look at what the Sienna TS Visualiser shows us :

Figure 2: Sienna TS Visualiser showing perfect traffic-shaped CBR Stream from Haivision Makito

The TS Visualiser has 6 sections, showing different characteristics of the transport stream.

1) Network DataRates : This shows the stream in terms of data rate on the wire - ie, the actual pace of bytes arriving in time at the NIC.  This reveals the effect the network delivery has on the linearity of the basic data stream.

NB: This is not the same as  :

2) Stream DataRates : This is not based on the wire speed, but the data vs time within the data stream construct itself - even if its just stored in a file on disk. This shows the basic linearity of encoding and multiplexing.

In both 1 and 2 we see the Video data rate shown in purple, overlaid with audio data rate in yellow at the bottom.  In CBR data streams, which must result in a constant data rate, the practice in MPEG TS is to add Null Padding data during multiplexing which fills in the variable encoded data with as many null packets as required to maintain a constant output data rate.  The 1) Red and 2) Green top lines show the overall data rate.

Whilst this perfect example shows the 2 data rates as the same - this is generally not true in many cases where network jitter and buffering often disrupt the encoded stream with additional delivery jitter.

3) PCR Jitter and Accuracy: We know that a good transport stream will have regular PCR clock messages embedded within the audio and video packets.  The PCR Jitter in green shows the variability in the arrival time of PCR clocks, regardless of the position in the multiplexed data - so this is affected both by the encoding and the delivery of the stream.   The PCR Accuracy in red shows the linearity of PCR messages in terms of the stream data rate - for example, one PCR message per 100 TS Packets (each TS Packet is 188 bytes).  The PCR Accuracy reveals more about the nature of the stream but doesn't necessarily cause problems in the way that PCR Jitter can.

4) PCR Jitter and Accuracy Eye Pattern: This is another visualisation of the same data shown in 3) using an eye-pattern to give a quick-look overview of the stream giving an instant diagnosis of PCR.

5) Stream General Info: This shows information like the Service metadata, along with more specific PCR data.

6) Elementary Media Stream Info: This shows data about the primary video and audio found in the stream.

Figure 3: Sienna TS Visualiser showing raw Stream from Haivision Makito without traffic shaping

When encoding video in real time (ie, without a non real time 2 pass encode), it almost impossible to create a constant data rate over a given future window, since you can't predict what will happen in future video frames. Consequently most video encoders produce a somewhat variable data rate, which is conformed over time to a more constant rate - for example a constant average rate over a GOP of 1 second, rather than a constant data rate per frame.  In the picture above we see the Makito encoder's data in CBR mode - where CBR is over a complete group of pictures.  As you can see the data rate is quite variable, peaking at each keyframe where the GOP begins, so it looks a bit like a VBR stream.  With all this moving around, its not suprising to see that the measured PCR Jitter is much more variable now.

This type of variable stream is generally fine for software based decoders which are less sensitive to PCR jitter, but may not be compatible with some more traditional hardware MPEG TS decoders.  Figure 2 shows what this same stream (figure 3) looks like when Makito applies CBR Traffic Shaping to clean up the stream and make it TR 101 standards compatible.  The traffic shaper in Figure 3 is turned off (called VBR mode in Makito's shaper, but it really means Bypass).  The traffic shaped in Makito adds about 500mSec of latency as it buffers and tidies up the stream, so you would only enable it when you need to feed a traditional decoder which needs the rigid CBR construct.

Figure 4: Sienna TS Visualiser showing raw Stream from Haivision Makito with CVBR traffic shaping

Makito has a third traffic shaping algorithm called CVBR which is a half way house between pass through "VBR" and fully clean up "CBR".   The "CVBR" mode doesn't attempt to create a truly CBR output - so its not inserting null padding like CBR shaping mode, but it does pay close attention to the pacing of the PCR clocks to ensure they go out on time, every time, regular as clockwork.  That results in the picture shown above, where the data rate is fluctuating considerably, but the PCR jitter is very low, even though the PCR accuracy is variable.

The 3 diagrams really illustrate the value of the Sienna TS Visualiser since it would by extremely hard to understand the difference in these modes, or uncover the issues in other streams without this clear visual picture.

Figure 5: Sienna TS Visualiser showing Stream with specific issues

The image above shows a CBR transport stream with specific issues, which are revealed by the TS Visualiser. Specifically, the mux rate, or padded CBR data rate is too close the video encoding target data rate, which can cause a "Mux Overflow" condition where there is too much video data, and it blows the limit on the padding algorithm.  This could cause video data to be removed, likely leading to image tearing, often at the bottom of the image.    The second issue is a problem with network delivery - the CBR fixed data rate encoded and mutiplexexed stream is fed via the NIC and the network NIC is applying buffering, perhaps a nagle algorithm or other buffer, which means that the 5.22 mBit data stream is emitted, at higher, then lower data rates, resulting in a considerable disruption in the delivery of the CBR data stream.  As you can see in the bottom section of the above image, this then yields high PCR jitter since the clocks which were linear in the data stream, end up coming out lumpy on the wire.

Figure 6: Sienna TS Visualiser showing Improved Stream with parameter changes.

After diagnosing the problems in Figure 6, the Transport Stream encoder parameters were changed, to give a wider headroom between the target video data rate and the padding mux rate, which solves the Mux Overflow issue.  Also, another parameter in the encoder, UDP Rate was set to enforce throttling and rate control on the UDP data output, to ensure that the CBR data was clocked out of the NIC more steadily, improving the Network Jitter.   The result of these 2 changes, delivers massively improved PCR jitter and avoiding any data loss due to overflows.

As you have seen, diagnosing and characterising issue with Transport Streams can be very complex, and without a tool like the Sienna ND Processing Engine TS Visualiser, can be very difficult to resolve.

In conclusion - for any sort of SRT or Transport Stream based workflows, the Sienna ND Processing Engine Advanced, with the TS Visualiser are an essential tool for broadcasters.

Follow Us