ANSI INCITS ISO IEC 13818-9-1996 Information technology - Generic coding of moving pictures and associated audio information - Part 9 Extension for real time interface for systems .pdf

1、INTERNATIONAL STANDARD ISO/IEC 13818-g First edition 1996-l 2-l 5 Information technology - Generic coding of moving pictures and associated audio information - Part 9: Extension for real time interface for systems decoders Technologies de /information - Codage g. l real-time constraints are imposed

2、on the values of PCR in relation to their arrival time in the RTD; l the buffer sizes defined in the T-STD are different in the RTD; and l there is an extra requirement on the Transport Buffer occupancy (see the end of 2.4). 2.2 Clock Frequency Requirements The requirements on the system clock with

3、respect to frequency and frequency slew given in ISO/IEC 138 18-1,2.4.2.1 are also mandatory for the Real-Time Interface. 2.3 PCR Accuracy Requirements This subclause defines a single constraint on the relationship between the arrival time of all the bytes containing the last bit of a program-clock-

4、reference-base field for a single program of a Transport Stream, and the value carried in the corresponding program clock references. Specifically, l let system-clock-counter(t) be a counter that counts cycles of a system clock that satisfies the frequency requirements specified in 2.2 above, where

5、t represents time; l let i” be the index of a byte containing the last bit of a program-clock-reference-base field; l let t(i”) be the time at which byte i” arrives in the RTD; and l let PCR(i”) be the value of the program clock reference associated with byte i”; then there shall exist such a system

6、 clock-counter(t), a sequence of times e(i”), and a constant tjitter (see ISO/IEC 13 8 18- 1 Annex J) that satisfy PCR(i”) = system-clock-counter(t(i”) + e(i”)%(300 x 233), and - tjitterl:! I e(F) I tjitter/2. 2.4 Buffer Requirements The buffers in the RTD have the same names as those in the T-STD,

7、but are denoted with a “-r” suffix. Their sizes are: TBS-r, = TBS, + (tjitter x Rx”) + 188 bytes TB Srrsys = TBS, + ( tjitter x Rxn) + 188 bytes sb-size-r = sb-size + ( tjitter x sb-leak-rate) + 188 bytes It should be noted that the use of the smoothing buffer (see ISO/IEC 138 18-l) 2.6.30) is optio

8、nal for this part of ISO/IEC 13818, as it is in ISO/IEC 13818-1. 2 0 ISO/I EC ISO/IEC 13818-9:1996(E) The multiplex buffer (for video) and the decoder buffer (for audio and systems data) in the RTD have the sizes: MBS-r, = MBS, + (2x tjitter X Rx,), BS-r, = BS, + (2 x tjitter x Rxn), and BS-r, = BS,

9、 + (2 x tjitter X Rx,), respectively. Note that in all these equations, Rx, which is identical in definition to the same variable in the T-STD, is expressed in bytes/second for convenience. Given the RTD buffers as defined above, and a system clock that fulfils the above requirements, the RTD impose

10、s that all the buffer constraints imposed by the T-STD in ISO/IEC 138 18- 1 be complied with. In addition, the buffer state of the buffer TB-r, in the RTD at the arrival of the first byte of any Transport Stream packet shall be no more than the size of that buffer minus 188 bytes. 2.5 Real-Time Inte

11、rface for Low Jitter Applications This subclause specifies the Real-Time Interface for Low Jitter Applications (RTI-LJ). For a bitstream and its byte delivery schedule to comply with the RTI-LJ, they must obey all of the compliance tests in clause 3 below with tjitter equal to 50 microseconds. For a

12、 decoder to comply with the RTI-LJ, the decoder shall be capable of operating correctly when fed by any such bitstream and byte delivery schedule. 2.6 Other Applications Applications other than those described in 2.5 may use this part of ISO/IEC 13818 to specify interoperability constraints on bitst

13、ream delivery and bitstream decoders. In such usage, compliance with this part of ISO/IEC 13 8 18 shall be stated relative to a specified value for tjitter. For example, a decoder may be called “RTI-compliant for tjitter equals x”. 3 Compliance Testing for RTI 3.1 Objectives The objectives of a test

14、ing procedure for this part of ISO/IEC 138 18 are the following: 1. Test for compliance with the system clock frequency accuracy specification, 2. Test for compliance with the system clock slew rate specification, 3. Test for compliance with the PCR jitter specification in this part (tjitter), and 4

15、. Test for compliance with the buffer requirements in this part. For some Transport Streams, e.g. very short streams or streams with frequent PCR discontinuities, it may be impossible to verify all of these requirements. In streams with many closely spaced PCR discontinuities it is not possible to d

16、istinguish between system clock inaccuracy and jitter. Streams need to have a minimum duration of continuous PCRs for accurate determination of system clock frequency error. The duration of continuous PCRs must be sufficient so that the random component of arrival time inaccuracy due to jitter is mu

17、ch smaller than the steadily increasing arrival time inaccuracy caused by system clock frequency error. 3 ISO/IEC 13818-9:1996(E) 0 ISO/IEC 3.2 Testing System Clock Frequency Accuracy, System Clock Slew Rate, and PCR Jitter The compliance test is carried out for one program at a time. The procedure

18、uses a plot of PCR values (which represent the system clock time at which the data was transmitted) against PCR arrival times, as illustrated in Figure 2. The arrival times are plotted on the X axis and represent accurate time at the receiver. The PCR values are plotted on the Y axis. Time PCR Value

19、 (converted to time) PCR Arrival Time Decoder Time Figure 2 - Plot of PCR values versus Arrival Time If the PCR values are converted to system clock time values, this plot has the following properties: l If there is no system clock frequency error and no jitter, the plot will be a straight line with

20、 unity slope. l If there is jitter in the arrival times, the average slope will remain unity but the points will be scattered to the left and right of the best fit unity slope line. The jitter of each arriving value is the horizontal distance between the average line and the plotted point. l If ther

21、e is frequency error in the system clock, the slope of the plotted points is no longer unity. The frequency error can be determined from the slope of the line (the first derivative). l If the system clock frequency is changing (slewing), then the plot will no longer be a straight line. The rate of c

22、hange of the system clock frequency (amount of slew) can be determined from the rate of change of the slope (the second derivative). In general, there will be system clock frequency error and slew as well as jitter. As noted above, separating these three to the desired level of accuracy may not alwa

23、ys be possible, depending on the amount of arrival time jitter and how often PCR discontinuities occur. The basic procedure is described for one program called P: 1. For each byte that carries the last bit of a PCR field for P, the arrival time of that byte and the value of the corresponding PCR its

24、elf are noted. These values are called t(i) and PCR(i), respectively. PCR(i) can be converted to a system clock time value. (In what follows, rollover of the PCR register is ignored.) 2. When all PCR values in the segment of stream to be tested have been noted, their values are plotted against their

25、 arrival times. 0 I SO/I EC ISO/IEC 13818-9:1996(E) The stream is compliant if a curve can be drawn such that everywhere its slope is compliant with the system clock frequency accuracy requirement, its second derivative everywhere does not exceed the maximum system clock frequency slew rate, and its

26、 horizontal distance to any of the points (t(i), PCR(i) is not greater than tjitter/2 in any case. A stream is compliant whenever such a graph can be found, and a stream is not proven non-compliant until it can be proven that no such graph exists. This can be proven in some cases by for example taki

27、ng a suspect point (t(i), PCR(i) and drawing a region which includes all other permissible points in the bitstream. If another point falls outside that region, the stream is non-compliant. A stream shall be assumed to be compliant unless it can be proven to be non-compliant. 3.3 Approximate Tests fo

28、r System Clock Frequency Accuracy and PCR jitter In cases which are nearly compliant, finding such a curve, as discussed above, will sometimes prove to be difficult. Presented below are two tests which provide approximate solutions to this problem. Since the allowed system clock slew is small (10 pp

29、rn/hour), and in practice system clock slew is unlikely to be a problem, short sections of Transport Stream data can be tested by ignoring system clock slew, i.e. assuming the system clock frequency is constant. 3.3.1 Diverging Lines Test The test of permissible points described at the end of 3.2 ca

30、n be approximated by assuming zero slew, and drawing two straight lines. 1. The first starts (tjitter) to the left of the starting point and has slope corresponding to a system clock running 30 ppm fast. 2. The second starts (tjitter) to the right of the starting point and has slope corresponding to

31、 a system clock running 30 ppm slow. The increasing width area enclosed by these lines to the right of and above the starting point should contain all subsequent plotted points from the stream under test (until the next PCR discontinuity). This test can be done on each point plotted, and the full se

32、t of tests approximately tests the stream for compliance with system clock frequency accuracy and tjitter. 3.3.2 Parallel Lines Test This test of a section of a Transport Stream with continuous PCRs and no system clock slew is also based on the plot of PCR(i) versus t(i) described in 3.2. The stream

33、 is compliant if it is possible to find two parallel straight lines, with horizontal separation of (tjitter), and with slope corresponding to a frequency error of less than 30 ppm, with all the plotted points contained between the lines. 3.4 Buffer Compliance Testing The buffer compliance test shall

34、 be performed exactly as the corresponding test for the T-STD (ISO/IEC 13818-1,2.4.2), except for obvious changes due to different arrival times and buffer sizes, as well as the extra requirement for TB-r, occupancy at the arrival of the first byte of a Transport Stream Packet. 5 ISO/IEC 13818-9:1996(E) o ISOAEC ICS 35.040 Descriptors: data processing, moving pictures, image processing, video recording, sound recording, video data, audio data, data converting, coding (data conversion). decoders, computer Interfaces. Price based on 5 pages