International organisation for standardisation organisation internationale de normalisation
|
|  Yüklə 1.39 Mb.
|
K.3 Example decoder implementationsK.3.1 Network adapter followed by an MPEG-2 decoderIn this implementation a network adapter conforming to the network compliance specification is connected to an MPEG-2 decoder conforming to the real-time interface specification. K.3.2 Integrated decoderThe example presented in K.4.1 requires two stages of processing. The first stage is necessary to dejitter the network's output; the second stage, recovering the STC by processing PCRs or SCRs, is required for STD decoding. The example presented in this section is a decoder that integrates the dejittering and decoding functions in a single system. The STC clock is recovered directly using the jittered PCR or SCR values. For presenting this example, an MPEG-2 transport stream will be assumed. Figure K-3 illustrates the operation of the integrated decoder. The stream of network packets input to the decoder is assumed to be the same as the one shown in Figure K-2. 
Figure K-3 -- Integrated dejittering and MPEG-2 decoding The incoming network packets are reassembled into MPEG-2 transport stream data by the NXP and NDP decode functions. The jittered ITU T Rec. H.222.0†|†ISO/IEC 13818 1 Transport Stream packets are then filtered to extract packets with the desired PID. For the case illustrated, the PID being decoded is also carrying the PCRs. The PCR values are sent to a PLL to recover the STC. Entire packets for the selected PID are placed in the integrated buffer. A positive value of J/2 seconds is subtracted from the STC to obtain the delayed STC, STCd. Again, J is the peak-to-peak jitter the network-savvy decoder can accommodate. The delay is introduced to guarantee that all the data required for an access unit has arrived in the buffer when the PTS/DTS of the access unit equals the current value of the STCd. Ignoring implementation details such as the speed of the STC clock recovery loop and the spectral purity of the STC 
where, Bj = Rmax J and Rmax the maximum rate at which data is input to the PID filter. Depending on the implementation, the integrated memory could be broken into two components as in the transport STD. Annex L(Informative.) Splicing Transport Streams L.0 IntroductionFor the purpose of this annex, the term 'splicing' refers to the concatenation performed on the Transport level of two different elementary streams, the resulting Transport Stream conforming totally to this Recommendation | International Standard. The two elementary streams may have been generated at different locations and/or at different times, and were not necessarily intended to be spliced together when they were generated. In the following we will call the 'old' stream a continuous elementary stream (video or audio), which has been superseded by another stream (the 'new' one) from a certain point on. This point is called the splice. It is the boundary between data belonging to the 'old' stream and data belonging to the 'new' one. A splice can be seamless or non seamless:
Splicing is allowed to be performed at any transport stream packet boundary, since the resulting stream is legal. But in a general case, if nothing is known about the location of PES packet starts and access unit starts, this constraint imposes that not only the Transport layer is parsed, but also the PES layer and the Elementary Stream layer, and may in some cases, make some processing on the payload of Transport Stream packets necessary. If such complex operations are wished to be avoided, splicing should be performed at locations where the Transport Stream has favorable properties, these properties being indicated by the presence of a splicing point. The presence of a splicing point is indicated by the splice_flag and splice_countdown fields (refer to 2.4.3.4 of this Specification for the semantics of these fields). In the following, the Transport Stream packet in which the splice_countdown field value reaches zero will be called 'splicing packet'. The splicing point is located immediately after the last byte of the splicing packet. L.1 The different types of splicing pointA splicing point can be either an ordinary splicing point or a seamless splicing point: L.1.1 Ordinary splicing pointsIf the seamless_splice_flag field is not present, or if its value is zero, the splicing point is ordinary. The presence of an ordinary splicing point only signals alignment properties of the Elementary Stream: the splicing packet ends on the last byte of an Access Unit, and the payload of the next Transport Stream packet of the same PID will start with the header of a PES packet, the payload of which will start with an Elementary Stream Access Point (or with a sequence_end_code() immediately followed by an Elementary Stream Access Point, in the case of video). These properties allow 'Cut and Paste' operations to be performed easily on the Transport level, while respecting syntactical constraints and ensuring bit stream consistency. However, it does not provide any information concerning timing or buffer properties. As a consequence, with such splicing points, seamless splicing can only be done with the help of private arrangements, or by analyzing the payload of the Transport Stream Packets and tracking buffer status and time stamp values. L.1.2 Seamless splicing pointsIf the seamless_splice_flag field is present and its value is one, information is given by the splicing point, indicating some properties of the 'old' stream. This information is not aimed at decoders. Its primary goal is to facilitate seamless splicing. Such a splicing point is called a seamless splicing point. The available information is:
Note that a seamless splicing point can be used as an ordinary splicing point, by discarding this additional information. This information may also be used if judged helpful to perform non seamless splicing, or for purposes other than splicing. L.2 Decoder behavior on splicesL.2.1 On non seamless splicesAs described above, a non seamless splice is a splice which results in a decoding discontinuity. It shall be noted that with such a splice, the constraints related to the decoding discontinuity (section 2.7.6 of this Recommendation | International Standard) shall be fulfilled. In particular:
In theory, since they introduce decoding discontinuities, such splices result in a non continuous presentation of presentation units (i.e. a variable length dead time between the display of two consecutive pictures, or between two consecutive audio frames). In practice, the result will depend on how the decoder is implemented, especially in video. With some video decoders, the freezing of one or more pictures may be the preferred solution. See Part 4 of this Recommendation | International Standard. L.2.2 On seamless splicesThe aim of having no decoding discontinuity is to allow having no presentation discontinuity. In the case of audio, this can always be ensured. But it has to be noted that in the case of video, presentation continuity is in theory not possible in cases 1. and 2. below: 1. The 'old' stream ends on the end of a low delay sequence, and the 'new' stream begins with the start of a non low delay sequence. 2. The 'new' stream ends on the end of a non low delay sequence, and the 'new' stream begins with the start of a low delay sequence. The effects induced by such situations is implementation dependent. For instance, in case 1, a picture may have to be presented during two frame periods, and in case 2, a picture may have to be skipped. However, it is technically possible that some implementations support such situations without any undesirable effect. In addition, referring to 6.1.1.6 of ITU T Rec. H.262†|†ISO/IEC 13818-2, a sequence_end_code() shall be present before the first sequence_header() of the 'new' stream, if at least one sequence parameter (i.e. a parameter defined in the sequence header or in a sequence header extension) has a different value in both streams, with the only exception of those defining the quantization matrix. As an example, if the bit rate field has not the same value in the 'new' stream as in the 'old' one, a sequence_end_code() shall be present. Thus, if the splicing packet does not end on a sequence_end_code, the 'new' stream shall begin with a sequence_end_code followed by a sequence_header. According to the previous paragraph, a sequence_end_code will be mandatory in most splices, even seamless ones. It has to be noted that ITU T Rec. H.262†|†ISO/IEC 13818-2 specifies the decoding process of video sequences (i.e. data comprised between a sequence_header() and a sequence_end_code()), and nothing is specified about how to handle a sequence change. Thus, for the behavior of the decoders when such splices are encountered, refer to part 4 of this Recommendation | International Standard. L.2.3 Buffer OverflowEven if both elementary streams obey the T-STD model before being spliced, it is not necessarily ensured that the STD buffers do not overflow with the spliced stream in the time interval during which bits of both streams are in these buffers. In the case of constant bit rate video, if no particular conditions have been applied to the 'old' stream, and if no particular precautions have been taken during splicing, this overflow is possible in the case where the video bit rate of the 'new' stream is greater than the video bit rate of the 'old' one. Indeed, it is certainly true that the buffers MBn and EBn of the T-STD do not overflow if bits are delivered to the T-STD at the 'old' rate. But if the delivery rate is switched to a higher value at the input of TBn before 'old' bits are completely removed from the T-STD, the fullness of the STD buffers will become higher than if the 'old' stream had continued without splicing, and may cause overflow of EBn and/or MBn. In the case of variable bit rate video, the same problem can occur if the delivery rate of the 'new' stream is higher than the one for which provision was made during the creation of the 'old' stream. Such a situation is forbidden. However, it is possible for the encoder generating the 'old' stream to add conditions in the VBV buffer management in the neighborhood of splicing points, so that provision is made for any 'new' video bit rate lower than a chosen value. For instance, in the case of a seamless splicing point, such additional conditions can be indicated by a 'splice_type' value to which entries correspond in table 2-7 through table 2-16 for 'splice_decoding_delay' and 'max_splice_rate'. In that case, if the video bit rate of the 'new' stream is lower than 'max_splice_rate', it is ensured that the spliced stream will not lead to overflow during the time interval during which bits of both streams are in the T-STD buffer. In the case where no such constraints have been applied, this problem can be avoided by introducing a dead time in the delivery of bits between the 'old' stream and the 'new' one, in order to let the T-STD buffers get sufficiently empty before the bits of the 'new' stream are delivered. If we call tin the time at which the last byte of the last access unit of the 'old' stream enters the STD, and tout the time at which it exits the STD, it is sufficient to ensure that no more bits enter the T-STD the time interval [tin, tout] with the spliced stream than if the 'old' stream had continued without splicing. As an example, in the case where the 'old' stream has a constant bit rate Rold, and the 'new' one a constant bit rate Rnew, it is sufficient to introduce a dead time Td satisfying the following relations to avoid this risk of overflow: Td ³ 0 and Td ³ (tout - tin) x (1 - Rold/Rnew) 1Constant delay as indicated for the entire system is required for correct synchronizaton; however some deviations are possible. Network delay is discussed as being constant; slight deviations may be tolerated, and network adaptation may allow greater variations of network delay. Both of these are discussed later. |