Apparatus and method for analyzing bitstreams

Description Submit all comments and votes

The present invention relates to an apparatus and concomitant method for measuring the parameters of received digital bitstreams. More particularly, this invention relates to an apparatus and method that evaluates bitstreams in "real time" to verify various time-elements in the bitstreams.

BACKGROUND OF THE INVENTION

The increasing demand for digital video/audio information presents an ever increasing problem of monitoring the transmission or storage of data in data communication. As the transmission bandwidth increases in response to greater demand, it becomes increasingly more difficult to monitor the enormous amount of transmitted information in real time.

Generally, the data streams (bitstreams) contain various data elements that include video, audio, timing, program specific information and control data which are packaged into various "packets". A packet is a group of binary digits that include various data elements which are switched and transmitted as a composite whole. The data elements and other information are arranged in accordance with various specific formats, e.g., ISO/IEC international Standards 11172-* (MPEG-1), 13818-* (MPEG-2), ATSC standards and Digital Video Broadcasting (DVB) specification prETS 300-468, which are incorporated herein in their entirety by reference. In general, MPEG defines a packet as consisting of a header followed by a number of contiguous bytes from an "elementary data stream". An elementary stream is simply a generic term for one of the coded video, coded audio or other coded bitstreams. More specifically, a MPEG-2 "transport stream" packet comprises a header, which may be four (4) or more bytes long with a payload having a maximum length of 184 bytes. Transport stream packets are part of one or more programs which are assembled into a transport stream. The transport stream is then transmitted over a channel with a particular transfer rate.

Important components in the transport stream include various time-elements, i.e., Program Clock Reference (PCR) data and descriptive data called Program Specific Information (PSI). It should be noted that MPEG-2 allows a separate information system to be employed with the PSI, e.g., the Service Information (SI) in accordance with the DVB specification. In brief, the PCR is a time stamp encoding the timing of the bitstream itself and is used to derive the decoder timing, where the SI provides information to the decoder concerning the array of services that are offered. The SI allows a decoder to tune automatically to particular services and allows services to be grouped into categories with relevant schedule information.

Thus, it is important to monitor and verify that these time-elements and program specific information are received properly and that they are within the constraints defined by the relevant standards. Furthermore, it is important to alert the decoding system in real time if these time-elements and program specific information are outside of the allowed tolerances. Detection of such deviations allows the decoding system to account for packet framing errors, jitters, inconsistent time base information or network wide errors that may affect a plurality of channels. Although it may be more cost effective to capture the data in the transport stream into storage and then analyze the data at a later time, the benefit of real time analysis is lost.

With respect to PCR processing, although the set of specifications 13818 contain two very general descriptions of jitter measurement, in Annex D of part one and part nine of the systems specification, these two methods leave many parameters up to the discretion of the user, contain some imperfections and are impractical in-real-time applications.

Therefore, a need exists in the art for a method and apparatus for performing real time bitstream analysis. Specifically, a need exists for a method and apparatus for detecting and verifying errors in the bitstream such as inconsistencies of time base and program specific information.

SUMMARY OF THE INVENTION

The present invention is a bitstream analyzer for detecting and verifying errors in the bitstream such as inconsistencies of time base and program specific information in real time. The present invention is premised on the fact that it is impractical to provide numerous voltage controlled oscillators in a bitstream analyzer. For example, if the present bitstream analyzer must monitor 250 PIDs (each having its own PCRs) then 250 voltage controlled oscillators must be deployed to track their frequencies.

In the present invention, frequency tracking is provided with only a single time reference, which can be, preferably, an internal 27 MHz oscillator or an external 27 MHz TTL input. Since continuous measurement of time in any PID's timebase is not required, the present invention tracks only the time of reception of the PCR and packets of that particular PID. The present invention creates individual "System Time Clocks" (STCs), which keep track of what the System Time Clock would be if a decoder were using the PCRs transmitted on any particular PID.

The time of reception of a PCR is measured using a 27 MHz internal reference counter. The time of reception is measured within 1 cycle of 27 MHz. The specification of 188 byte or 204 byte mode on the input is used in the calculation of the reception time. The measurement is actually the start-of-packet arrival time. The arrival of the PCR is calculated based on the arrival of the PCR's packet and the arrival time of the packet following that packet. The PCR arrival time is interpolated between these two values using the knowledge of which byte holds the PCR and the number of bytes between the two start-of-packet times.

The calculated time of reception of PCR n is defined as tPCR(n). This value is used to update the PID's System Time Clock (STC) when a PCR is received. The STC is modified by a factor "f.sub.pid ", as defined below. Thus, the new STC at the time of reception of PCR(n) should be updated from it's previous value by the measured time interval corrected for frequency, or:

When the System Time Clock is not set (STC(n-1) is undefined), or when the calculated value of STC(n) is very different from the PCR(n), the STC is loaded with the PCR value. If this is not a known discontinuity, an error message is issued.

In one embodiment, all events where (tPCR(n)-tPCR(n-1))>0.1 seconds are treated as discontinuities, causing an error message and reload of the STC with the received PCR value.

BRIEF DESCRIPTION OF THE DRAWING

The teachings of the present invention can be readily understood by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 illustrates a block diagram of a simplified conventional packet stream system;

FIG. 2 illustrates a bitstream analyzer of the present invention for performing real time bitstream analysis;

FIG. 3 illustrates a flowchart of a method for performing real time bitstream analysis;

FIG. 4 illustrates a flowchart of the continuous PCR processing method;

FIG. 5 illustrates a block diagram of a filter that converts error "e" into frequency offset "f";

FIG. 6 illustrates a block diagram of another embodiment of a filter that converts error "e" into frequency offset "f";

FIG. 7 illustrates a flowchart of the PCR_Jitter processing method;

FIG. 8 illustrates a flowchart of the PCR_Gap processing method;

FIG. 9 illustrates a flowchart of the non-continuous PCR processing method; and

FIG. 10 illustrates a flowchart of a method for measuring conformance of the inter-arrival time for related sections of SI in a real-time system.

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures.

DETAILED DESCRIPTION

FIG. 1 depicts a block diagram of a simplified structure of a conventional packet stream system 100. More specifically, a "transport stream" as defined in accordance with the MPEG standards is used in the packet stream system illustrated in FIG. 1. Although the present invention is described below using the MPEG transport stream as an example, those skilled in the art will realize that the present invention can be applied to any bitstreams, i.e., a MPEG "program stream" or any other packet streams in accordance with other formats.

System 100 includes a video encoder 120 for receiving and encoding video data on path 110 into an elementary video bitstream. Similarly, the system also includes an audio encoder 122 for receiving and encoding audio data on path 112 into an elementary audio bitstream. In turn, these bitstreams are sent to packetizers 130 and 132 where the elementary bitstreams are converted into packets. Information for using the packets independently of the transport stream may be added when the packets are formed in the packetizers. Thus, non-audio/video data, e.g., SI, are also packetized into transport stream, but the sources of these non-audio/video data are not shown in FIG. 1.

The packets are received and multiplexed by the transport stream multiplexor 140 to produce a transport stream on path 145. Packets constructed from elementary streams that form a program (a group of "Packet Identifiers" (PIDs) with associated video and audio data) generally share a common time base. Thus, the transport stream may contain one or more programs with one or more independent time bases, where the time bases are used for synchronized presentation. The time bases of different programs within a transport stream may be different.

The transport stream on path 145 is transmitted over a transmission channel 150, which may further incorporate separate channel specific encoder and decoder (not shown). Next, the transport stream is demultiplexed and decoded by a transport stream demultiplexor 160, where the elementary streams serve as inputs to video decoder 170 and audio decoder 190, whose outputs are decoded video signals on path 175 and audio signals on path 195 respectively.

Furthermore, timing information is also extracted by the transport stream demultiplexor 160 and delivered to clock control 180 for synchronizing the video and audio decoders with each other and with the channel. Synchronization of the decoders with the channel is accomplished through the use of the PCR in the transport stream, where the PCR is used to derive the decoder timing.

FIG. 2 illustrates a block diagram of the bitstream analyzer 200 of the present invention for monitoring and performing real time bitstream analysis on a multiplexed bitstream, such as a MPEG-2 transport stream. The bitstream analyzer 200 can be implemented before the transport stream demultiplexer 160 as a separate device or it can be integrated with the function of transport stream demultiplexer 160 as illustrated in FIG. 1. Thus, the present bitstream analyzer can be implemented within a larger decoding system that is able to provide real time bitstream analysis on a multiplexed bitstream.

The bitstream analyzer 200 serves to verify and monitor various time elements in the bitstreams, e.g., the accuracy and correctness of the PCR data and the inter-arrival time of SI. The bitstream analyzer extracts the time-base for each elementary stream and verifies that constraints on the PCR's are not violated. Similarly, the bitstream analyzer processes packets which contain SI information in the transport stream. The processing verifies that successive "sections" from the same group of types (defined below) are not occurring inside of the specified time interval, e.g., within 25 msec of each other.

Returning to FIG. 2, the bitstream analyzer 200 comprises an input buffer 210, a buffer controller 220, a counter 230, a processor 240, a memory 250 and a display 260. More specifically, the bitstream analyzer receives as an input a real-time digital bitstream on path 205, such as an MPEG transport stream, carrying clock information in the form of PCR data and an indicator of the "start of packet", e.g., MPEG provides that the first byte of each packet shall be a value of "47" (hex). This predefined value allows the decoder to detect the start of a packet.

Alternatively, the start of packet indicator can be received as a separate external signal on path 207. Depending on the specific application, a decoding system may employ additional processing such that the start of packet indicator is previously detected and extracted from the bitstream and is subsequently presented to the bitstream analyzer 200 on path 207.

The packets of the bitstream are received into a fifo (first-in, first-out) memory 210 which has a suitable capacity to store at least several packets of data. In one embodiment, the fifo is 21 packets deep.

When the start of packet is detected, the counter 230 which is running in real time, records the time of reception of the start of packet (timestamp of the start of packet) into a register 232. Namely, the real time counter 230 counts cycles of a standard clock, e.g., a clock operating at a frequency of 27 MHz. When a start of packet is detected, the current value of the counter 230 is copied into the register 232. When the register 232 is loaded, interrupt controller 234 issues an interrupt to the processor 240 to indicate that another start of packet was detected. Although the register 232 and interrupt controller 234 are illustrated within counter 230, it should be understood that they can be implemented outside of the counter 230.

In the preferred embodiment, processor 240 is a microprocessor, e.g., a TMS320C31 or "C31" microprocessor from Texas Instruments. Responsive to the interrupt from the interrupt controller 234, the processor 240 reads the register 232 and stores the register value to a timestamp storage. Namely, the processor performs a direct memory access (DMA) transfer of the timestamp in the register, which is memory mapped into the processor address space as a value in a table in the memory 250. The memory 250 contains various tables 252A and 252n which consist of the timestamp tables (list of times of receipt of packets) and other tables which are described below. When a certain number of DMAs have occurred, e.g., twenty-one (21), the processor interrupts itself, and the address pointers are reset. The processor also reads the packets out of the fifo 210, parsing the packets as they are read. Using the packet data and the timestamps indicating their arrival, the processor is able to verify the accuracy and correctness of the PCR data and the inter-arrival time of SI.

The processor can work in real-time, that is, it can process each packet of data within a fixed delay relative to the time of reception. In real time applications, the number of packets in buffer 210 can vary from time to time depending on the time required for processor 240 to process preceding packets and to perform other tasks such as refreshing display 260.

The processor reads packet data from buffer 210 and the time of reception from timestamp table 252. The software applications or methods executed in processor 240 use the values in the timestamp table 252 to process a packet's data stored in buffer 210 and evaluate its time elements in the context of its time of reception. The preferred embodiment provides for real-time operation while allowing the microprocessor to perform other tasks as long as these tasks do not delay processing of any packet for more than 21 packet times.

The fifo (buffer) controller 220 controls the fifo 210 by resetting the fifo upon restart, measuring the fullness of the fifo to prevent underflow and controlling the clocking out of data to the processor 240. Namely, due to potential memory addressing discrepancies between the processor and the fifo, the fifo controller serves as an interface between the fifo and the processor, e.g., converting a read enable signal (control signal) from the processor to the proper clock out cycle of the fifo. However, it should be understood that the functions performed by the fifo controller 220 could be implemented within the processor 240.

Finally, a display 260 is coupled to the processor to display the results from the bitstream analyzer. The display allows a user to monitor and perform real time bitstream analysis on a multiplexed bitstream.

FIG. 3 illustrates a flowchart of a method 300 for performing real time bitstream analysis. More specifically, method 300 verifies and monitors various time elements in the bitstreams, e.g., the accuracy and correctness of the PCR data and the inter-arrival time of SI. Generally, the PCR data (values) which represent the clock reference of the signal, appear regularly in the bitstream, e.g., a PCR value may appear in the bitstream approximately once every 0.1 second. In the preferred embodiment where the bitstream is an MPEG transport stream, the PCR values represent the ticks of a 27 Mhz. reference clock. The decoding system is expected to apply the PCR values to derive its "system time clock" (STC), which tracks the encoding system's time clock as represented by the PCR values. Thus, several important aspects that are monitored by the present method include the discontinuity state of the packet, the time jitter of the PCR data and the inter-arrival time of the PCR data (PCR Gap). Furthermore, the present method also monitors the inter-arrival time of SI. Each aspect is discussed in detail below.

Referring to FIG. 3, the method 300 begins at step 305 and proceeds to step 310, where method 300 queries whether packet data is received and available into the fifo 210. If the query is affirmatively answered, then method 300 notes the packet identifier (PID) of the current packet and proceeds to step 315. If the query is negatively answered in step 310, method 300 waits until a packet is received.

In step 315, the method 300 queries whether PCR data is detected in the current packet. If the query is affirmatively answered, then method 300 proceeds to step 320, where another query is made to determine whether the PCR in the received packet data is part of a continuous sequence of PCRs from the encoder, or if it represents the start of a new sequence as shown by a discontinuity_indicator bit in the stream. If the query is negatively answered, then method 300 proceeds to step 335, where another query is made to determine if the PID of the current packet correlates to a packet that carries SI.

In step 320, method 300 determines the discontinuity state for the current PCR. The PCR processing depends on the discontinuity state for the transport packet that contains the PCR field. Before the PCR processing is performed, the discontinuity state for each packet is determined by reading and interpreting the header of the packet and any adaptation field. The discontinuity state for the transport packet is reported in the adaptation field under the parameter "discontinuity_indicator". If the discontinuity state is true (discontinuity in PCR is allowed), method 300 proceeds to step 330 where the discontinuous PCR processing is performed. If the discontinuity state is not true (discontinuity in PCR is NOT allowed), method 300 proceeds to step 325 where normal, continuous PCR processing is performed.

In step 325, packet arrival times are used as basis for updating the PCR time-base for the current PID. This updating simulates the operation of a Phase Locked Loop (PLL). The difference of the PCR value and the PCR time-base for current PID (the time jitter) is used to verify that the PCR values are continuous and within specifications (PCR Jitter Test, as discussed below) and the calculated arrival time is used to test if the interval between PCR fields in the bitstream are within specifications (PCR Gap Test, as discussed below).

In step 330, the PCR processing is limited to the resetting of the various parameters in the simulated PLL operation and only the PCR GAP Test is performed. The PCR Jitter Test is not performed under the discontinuous PCR processing.

In step 335, method 300 queries whether the PID of the current packet correlates to a packet that carries SI. If the query is affirmatively answered, then method 300 proceeds to step 340 where SI processing is performed. In the preferred embodiment, the PID values that correlate to packets that carry SI are PIDs 16, 17, 18, 19 and 20 in accordance with the DVB standard. It should be understood that other PID values may carry SI in accordance with other standards, e.g., ATSC. Thus, the set of PID values associated with SI packets can be adjusted in accordance with a particular implementation.

If the query is negatively answered in step 335, then method 300 proceeds to step 350. In one embodiment, packets that do not carry PCR data or SI are simply read out of the fifo 210 and discarded.

In step 350, method 300 queries whether the next packet is received and ready for processing. If the query is affirmatively answered, then method 300 returns to step 315. If the query is negatively answered, then method 300 proceeds to optional step 360, where a background processing is performed for one "scan" (or next scan) to selectively purge one or more entries in the various tables stored in the memory 250. The background processing method can also be employed to verify PCR gaps on all successive PIDs during the PCR Gap analysis as discussed below.

For example, the PID values may range over eight thousand possible values. Such large variation of PID values requires a large capacity memory to store all the relevant parameters for each PID value. Since there may be a long delay or pause between reception of packets of the same PID value, it is more cost effective to employ a background processing to purge parameters associated with non-current PID values, thereby reducing the computational overhead of the processor and the size requirement of the memory 250.

When method 300 completes the background processing, it returns to step 350 to determine if the next packet is received. If the next packet has not been received, method 300 continues with the background processing for the next scan and so on, until the next packet is received.

FIG. 4 illustrates a flowchart of the continuous PCR processing method 325. Namely, method 325 correlates to step 325 of FIG. 3.

Referring to FIG. 4, the method 325 begins at step 405 and proceeds to step 410, where method 325 calculates the parameters associated with the PID. Namely, the parameters tPCR, dPCR_HW, and dPCR are calculated or set.

The parameter tPCR is defined as the timestamp value of the reception of the current PCR for the current packet or PID (since each packet is defined by a unique PID). Thus, tPCR can be expressed as:

where BOP.sub.CURRENT correlates to the timestamp value for the arrival time (reception time) of the beginning of the current packet. However, equation (1) is only an estimation. The parameter tPCR can be more accurately expressed as:

where (BOP.sub.LAST -BOP.sub.CURRENT) represents the amount of time necessary to receive a packet, i.e., the difference between timestamp values for the reception time of the beginning of the last packet and the beginning of the current packet. Additionally, Packet_Length represents the length of the packet, i.e., the number of bytes in the packet, e.g., 188 bytes for MPEG. Equation (2) is necessary due to the fact that MPEG defines the time of the PCR to be the time when the sixth byte of the packet is received. However, for most applications, the estimation provided by Equation (1) should be adequate. It should be understood that Equation (2) is tailored specifically for MPEG. As such Equation (2) can be adjusted or replaced completely to account for other bitstream standards.

The parameter dPCR_HW is defined as the difference between timestamp values of the reception of the current tPCR and the previous tPCR_last.sub.pid of the same PID value as stored in the memory. Thus, dPCR_HW can be expressed as:

Namely, dPCR_HW represents the difference in time (local time of the decoder) between successive receptions of PCRs of the same PID value. However, dPCR_HW does not account for any discrepancies between the decoder clock and the encoder clock.

As such, the parameter dPCR is defined as the difference between timestamp values of the reception of the current tPCR and the previous tPCR_last.sub.pid of the same PID value adjusted by a factor of "f.sub.pid ", which is a measure of the difference in rate between the encoder clock and the decoder clock. The frequency, as controlled by "f.sub.pid " is restricted to lie within the MPEG limits. Thus, "f.sub.pid " is the difference in clock frequency between local time reference and encoders' time reference.

More specifically, the frequency offset value "f.sub.pid " is unitless, expressed as the frequency represented in the incoming PCRs minus the internal reference frequency divided by the internal reference frequency. This is equivalent to the ratio of the encoder and decoder clocks, minus one. The factor "f" should be zero nominally. Thus, dPCR can be expressed as:

The term f.sub.pid is further defined below. Thus, DPCR is a "corrected" time difference between successive PCRs of the same PID value.

Returning to FIG. 4, in step 415 method 325 queries whether the calculated dPCR is less than a threshold value, e.g., 1 msec. in the preferred embodiment. If the query is negatively answered, method 325 proceeds to step 420. If the query is positively answered, method 325 proceeds to step 460, where PCR processing is not performed. Namely, in step 415, if the time interval between PCRs of the same PID is too close, method 325 simply avoids processing these PCRs to reduce the computational overhead of the processor. Depending on the computational overhead of the processor, the threshold can be adjusted for a particular implementation or tuned to the capability of the hardware.

In step 420, method 325 updates the STC.sub.pid, i.e., the system time clock for a particular PID with the dPCR. The resulting updated STC.sub.pid represents the time for the current PID.

In turn, the error parameter "e" is calculated using the updated STC.sub.pid, where the error e represents the difference between the STC.sub.pid and the actual current PCR.sub.CURRENT value, i.e., the actual numerical value of the current PCR as read from the bitstream. Thus, the error e can be expressed as:

It should be noted that the jitter of any PCR is often also defined as the value "e" measured when the PCR is received. The units of "e" are counts of the 27 MHz system clock. If e is equal to zero, then the decoder clock is synchronized with the encoder clock. However, if e is not equal to zero, then the decoder clock is not synchronized with the encoder clock and a frequency offset f.sub.pid calculated in step 425 to account for the discrepancy. Thus, f.sub.pid can be expressed as:

where k and G are constants and PLLstate.sub.pid represents an integrator.

More specifically, equation (6) can be represented by a filter 500 as illustrated in FIG. 5. The filter comprises a constant multiplier k 530, a constant multiplier G 540, a sumer 550 and an integrator 520 having a delay 522 and a sumer 524. The filter 500 which converts the values e(0) . . . e(n) on path 510 into f(0) . . . f(n) on path 590, is a variation on a PLL design. The filter 500 differs from a time-sampled filter, in that the length of time between PCRs is unknown. The values of k and G are chosen to make the filter stable for all intervals up to the maximum MPEG 2 PCR interval of 0.1 seconds. The use of a pure integrator around the delay assures that the loop will behave the same even if decoder and encoder systems have different clock frequencies for interval measurement.

It should be noted that "k" and "G" must have units of counts.sup.-1, where in one embodiment, k is set to 1/(27,000,000*0.1). The constant G is set to 0.1/(27,000,000*0.1). This filter allows the "PLL Tracking" operation to settle to 1% in less than one second. Testing of PCR Accuracy may be 20 masked for a period after each discontinuity to allow the PLL to settle. These specific constant values for k and G can be used with both MPEG 2 and MPEG 2+DVB modes. However, it should be noted that other constant values can be employed to account for different applications.

FIG. 6 illustrates a block diagram of another embodiment of a filter 600 that converts error "e" into frequency offset "f.sub.pid ". This second embodiment of the "PLL Tracking" operation is essentially the same as the embodiment illustrated in FIG. 5 with the exception of a limiter or clipper 610. The limiter is added to the integration loop to keep the frequency offset to within 810 Hz (i.e., maintaining the difference in frequency between the encoder clock and the decoder clock within 30 ppm) in accordance with the MPEG specifications.

The feed-forward portion of "f.sub.pid " (i.e., e * k) is the "time discontinuity portion", which is not clipped by the limiter in the preferred embodiment. This improves stability of the integration loop.

Furthermore, when using an external clock, it is generally assumed that the external clock's accuracy is absolute, thereby allowing the limiter 610 to be set to 30 ppm. However, when the internal clock is used (or if the accuracy of the external clock is not absolute), which only has a 30 ppm accuracy in one embodiment, the limiter 610 must be set to at least.+-.60 ppm (the sum of the local oscillator's inaccuracy and the MPEG inaccuracy). However, it should be understood that the setting of the limiter can be adjusted in accordance with a particular application to account for clock inaccuracy and the constraints dictated by the relevant standards.

In the preferred embodiment, the clipping value of the delay feedback should be such that if e=0, f.sub.pid will be no more than 60 parts per million off. Thus, the clipping threshold C can be expressed as:

Thus, if G=0.1/2700000, then C=600*2700000/1000000 or 60*27/1 or 1620.0 However, if the external clock is employed, then the value is 810.0.

Returning to FIG. 4, once f.sub.pid is calculated for the current PID, method 325 proceeds to step 430, where the current states of the various parameters associated with the current PID are updated in the memory. For example, the time of reception of the current PCR (i.e., tPCR) is now stored as the time of reception of the last PCR (i.e., tPCR_last.sub.pid). Other stored states include f.sub.pid and PLLstate.sub.pid.

Steps 410, 420, 425 and 430 can be collectively referred to as a simulated PLL operation (or frequency tracking operation) being performed for each PID. Namely, a frequency correction is calculated and tracked for each PID.

In step 435, method 325 performs the PCR_Jitter processing or testing method. The PCR_Jitter processing verifies that the PCR values for the current PID are continuous and within the constraints defined by the relevant standards. The PCR_Jitter processing is described below in FIG. 7.

In step 440, method 325 performs the PCR_Gap processing or testing method. The PCR_Gap processing verifies that the time interval (arrival time) between successive PCR values of the same PID is within the constraints defined by the relevant standards. The PCR_Gap processing is described below in FIG. 8.

Method 325 then proceeds to optional steps 445 to 455, which are employed to perform statistical analysis. Namely, in step 445, method 325 queries whether a particular PID is selected for updates of its jitter and PCR interval (e.g., dPCR) histograms in step 450. The jitter histogram contains various "bins" where each bin represents certain value of PCR jitter, which is derived from the value of "e". Similarly, the PCR interval histogram contains various "bins" where each bin represents certain value of PCR interval. If the query is affirmatively answered in step 445, then method 325 proceeds to step 450 where the histograms are updated in accordance with "x" number of last PCRs specified in step 455, e.g., the last 50 PCRs. The histograms can be recalled by a user to view the jitter and PCR interval patterns for a particular PID. Method 325 then ends in step 460.

FIG. 7 illustrates a flowchart of the PCR_Jitter processing method 435. Namely, method 435 correlates to step 435 of FIG. 4.

Referring to FIG. 7, the method 435 begins at step 705 and proceeds to step 710, where method 435 queries whether the absolute value e is greater than 0.7 sec. If the query is affirmatively answered, then method 435 proceeds to steps 715-745, where method 435 determines whether an undetected discontinuity has occurred. If the query is negatively answered, then method 435 proceeds to step 720, where method 435 determines whether the necessary number of stored PCR values of the current PID has been received to warrant the start of the PCR jitter processing.

In step 715, method 435 queries whether the "last discontinuity count" parameter ("last_discont_cnt.sub.pid ") is set to zero (0). If the "last_discont_cnt.sub.pid " is set to zero, then the current PCR value that was used to calculate "e" is the first PCR value for the present PID. Namely, if the query is affirmatively a